- Oct 12, 2016
-
-
- Mar 10, 2014
-
-
- Feb 05, 2014
-
-
Shankar Prasad authored
-
- Jan 30, 2014
-
-
Shantha kumar authored
-
- Sep 10, 2013
-
-
Milo Casagrande authored
-
- Aug 26, 2013
-
-
Balázs Úr authored
-
- Aug 21, 2013
-
-
Chun-wei Fan authored
The RunDLL command call during get_session_address_dbus_launch() was expecting _g_win32_run_session_bus@16 and g_win32_run_session_bus on Win32 and Win64 respectively at least when GLib is compiled with MSVC, not g_win32_run_session_bus@16, which caused annoying RunDLL error dialogue boxes to show up during the use of GtkApplication (such as when running gtk3-demo-application on Windows), prevented GtkApplication items from being run for more than one time during the lifespan of the program, and this also interfered with some GTK+ tests, causing them to fail. Update accordingly to address the issue.
-
- Aug 18, 2013
-
-
Dimitris Spingos authored
-
- Aug 07, 2013
-
-
Allison Karlitskaya authored
-
- Aug 05, 2013
-
-
Chun-wei Fan authored
-
- Aug 04, 2013
-
-
Yuri Myasoedov authored
-
- Aug 01, 2013
-
-
Dan Winship authored
If the default route is via a device rather than a particular IP address, then neither RTA_DST nor RTA_GATEWAY will be present in the RTM_NEWROUTE message, and so GNetworkMonitorNetlink would ignore it, and then think there was no default route. (This could happen with certain kinds of VPNs, if they were set to route all traffic through the VPN.) Fix this by recognizing routes that specify RTA_OIF ("output interface") instead of RTA_GATEWAY. https://bugzilla.gnome.org/show_bug.cgi?id=701609 (cherry picked from commit c08ef6c1)
-
- Jul 23, 2013
-
-
Sandeep Sheshrao Shedmake authored
-
- Jul 14, 2013
-
-
Christian Kirbach authored
-
- Jul 05, 2013
-
-
Gil Forcada authored
-
- Jul 02, 2013
-
-
Andika Triwidada authored
-
- Jun 28, 2013
-
-
Rafael Ferreira authored
-
- Jun 25, 2013
-
-
Мирослав Николић authored
-
- Jun 20, 2013
-
-
Colin Walters authored
We didn't actually do any real-world testing of this, and unsurprisingly it turns out to break in at least one widely-used configuration (Fedora 19 x86_64, ext4 on LVM). This reverts commit 9d0c17b5. https://bugzilla.gnome.org/show_bug.cgi?id=701560
-
Chun-wei Fan authored
Build and "install" the gio-querymodules and gdbus utility programs so that the Visual Studio builds of GLib is more comprehensive. The Python scripts for the GDBus codegen will be added to "installation" later.
-
Chun-wei Fan authored
Make all projects settings use the MultiByte character set when building GLib to improve consistency.
-
- Jun 14, 2013
-
-
A S Alam authored
-
- Jun 13, 2013
-
-
Matej Urbančič authored
-
Daniel Mustieles García authored
-
- Jun 12, 2013
-
-
Aurimas Černius authored
-
- Jun 11, 2013
-
-
Shankar Prasad authored
-
- Jun 10, 2013
-
-
Marek Černocký authored
-
Piotr Drąg authored
-
Nilamdyuti Goswami authored
-
Fran Diéguez authored
-
Matthias Clasen authored
-
- Jun 09, 2013
-
-
Matthias Clasen authored
-
Matthias Clasen authored
-
Kind of a gratuitious gaping hole in the docs... https://bugzilla.gnome.org/show_bug.cgi?id=701680
-
When parsing an address, we need to re-set "len" between IPv4 and IPv6, since WSAStringToAddress() might set it to sizeof(struct sin_addr) when trying to parse the string as IPv4, even if it fails. Also, we need to make sure to not pass strings to WSAStringToAddress() that it will accept but that we don't want it to. When stringifying an address, we need to clear the sockaddr before filling it in, so we don't accidentally end up with an unwanted scope_id or the like. https://bugzilla.gnome.org/show_bug.cgi?id=701401
-
Previously, g_file_copy() would (on Unix) create files with the default mode of 644. For applications which might at user request copy arbitrary private files such as ~/.ssh or /etc/shadow, a world-readable copy would be temporarily exposed. This patch is suboptimal in that it *only* fixes g_file_copy() for the case where both source and destination are instances of GLocalFile on Unix. The reason for this is that the public GFile APIs for creating files allow very limited control over the access permissions for the created file; one can either say a file is "private" or not. Fixing this by adding e.g. g_file_create_with_attributes() would make sense, except this would entail 8 new API calls for all the variants of _create(), _create_async(), _replace(), _replace_async(), _create_readwrite(), _create_readwrite_async(), _replace_readwrite(), _replace_readwrite_async(). That can be done as a separate patch later. https://bugzilla.gnome.org/show_bug.cgi?id=699959
-
Previously, we called g_file_query_info() *again* on the source at the very end of the copy. This has the lame semantics that if the source happened to be deleted, we would fail to apply attributes to the destination. This could even be a security flaw. This commit changes things so that we query info from the source *stream* after opening - i.e. on Unix we use the proper fstat() and friends. That way we operate more atomically. https://bugzilla.gnome.org/show_bug.cgi?id=699959
-
ext3 and ext4 (for quite some time) with default mount options don't need fsync() to ensure safety of replace-by-rename. Stop doing that for these filesystems. Note: this patch also impacts ext2, which is probably not safe, but I don't know of any way to check ext2. vs the others because they all have the same magic numbers (short of opening /proc/mount). This patch assumes that if BTRFS_SUPER_MAGIC is defined then so will be EXT3_SUPER_MAGIC. https://bugzilla.gnome.org/show_bug.cgi?id=701560
-
Use fallocate() instead of posix_fallocate() so that we just fail instead of getting the emulated version from the libc. https://bugzilla.gnome.org/show_bug.cgi?id=701560
-
CI FTW.
-