commit 3f5a78a248406611c3eb7096a72749c892d47653 Author: Matthias Clasen Date: Mon Nov 24 13:07:22 2014 -0500 2.43.1 NEWS | 27 +++++++++++++++++++++++++++ configure.ac | 2 +- 2 files changed, 28 insertions(+), 1 deletion(-) commit e784a4ba326e939b74578f417202833d3231c7ac Author: Dan Winship Date: Sun Nov 23 12:33:01 2014 -0500 gio/tests: add a socket-listener test Add a GSocketListener test program. Currently the only test is a regression test for bug 712570 (based on a standalone bug reproducer provided by Ross Lagerwall). gio/tests/.gitignore | 1 + gio/tests/Makefile.am | 1 + gio/tests/socket-listener.c | 166 ++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 168 insertions(+) commit 9a6e01ea5bde908e2bcce4dc66d89483e84fd837 Author: Ross Lagerwall Date: Tue Oct 28 21:16:50 2014 +0000 gio: Prevent hang when finalizing GThreadedSocketService If all users of a GThreadedSocketService release their references to the service while a connection thread is running, the thread function will release the last reference to the service which causes the finalize to deadlock waiting for all threads to finish (because it's called from the thread function). To fix this, don't wait for all threads to finish in the service's finalize method. Since the threads hold a reference to the service, finalize should only be called when all threads are finished running (or have unrefed the service and are about to finish). https://bugzilla.gnome.org/show_bug.cgi?id=712570 gio/gthreadedsocketservice.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) commit 91802bbf2bfd336aec640c9412f955b1df8f80ae Author: Jasper St. Pierre Date: Tue Oct 28 13:45:34 2014 -0700 gparam: Make the documentation clearer for CONSTRUCT_ONLY properties It's not that the properly will only be set on construction, it's that it *can* only be set upon construction. gobject/gparam.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) commit 89e663107ecefd6db7ea24d2ffdf935020222947 Author: Michael Henning Date: Wed Nov 5 01:20:25 2014 -0500 gio: Implement g_win32_app_info_launch_uris for windows. gio/gwin32appinfo.c | 48 +++++++++++++++++++++++++++++++----------------- 1 file changed, 31 insertions(+), 17 deletions(-) commit 90f0eb101f108ee4096b5b3ef2d570ce588abb64 Author: Michael Henning Date: Wed Nov 5 01:18:25 2014 -0500 gio: Implement g_app_info_get_default_for_uri_scheme for windows. gio/gwin32appinfo.c | 22 ++++++++++++++++------ 1 file changed, 16 insertions(+), 6 deletions(-) commit 7f5c862e166a6f288d8d0ec2622685316f64b87c Author: Dan Winship Date: Sat Nov 22 10:54:41 2014 -0500 GTlsClientConnection: loosen the semantics of "use-ssl3" If SSL 3.0 has been disabled (at the host, application, or library level), then the "use-ssl3" property becomes a "fail-immediately" property. Despite the name, the point of the property wasn't really specifically to use SSL 3.0; it was to allow fallback when talking to broken servers that do SSL/TLS negotiation incorrectly and break when they see unexpectedly-high version numbers. So if we can't fall back to SSL 3.0, then the "use-ssl3" property should fall back to TLS 1.0 instead (since there are hosts that will reject a TLS 1.2 handshake, but accept a TLS 1.0 one). glib-networking is being updated to implement that behavior, so update the documentation here. https://bugzilla.gnome.org/show_bug.cgi?id=738633 gio/gtlsclientconnection.c | 19 ++++++++++++------- 1 file changed, 12 insertions(+), 7 deletions(-) commit f6bbd19beb41aeb52426ba96b3c39c1b09f6bc17 Author: Chun-wei Fan Date: Thu Nov 20 18:34:21 2014 +0800 GSettings Registry Backend: Init cache_lock Earlier In commit 8ff5668, we are subscribing the GSettings backend later, but this meant that we need to initialize cache_lock earlier, as we might try to use that lock before a change notification is issued to subscribe the backend, which would then cause an access violation if we are trying to read GSettings values, as that lock is used to access the Windows Registry. Initialize cache_lock once we initialize the GSettings Registry backend, and delete it upon finalize, so that g_settings_read_from_backend() can proceed normally, even if the GSettings backend is not yet subscribed. https://bugzilla.gnome.org/show_bug.cgi?id=740413 gio/gregistrysettingsbackend.c | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) commit 5c68fc9f93ee3d3cdb94cda2be5565584dfbb908 Author: Christian Persch Date: Tue Sep 23 10:46:53 2014 +0200 gsettingsschema: Print the string that failed to parse When parsing a translated value fails, print the actual string that failed to parse instead of the 'domain\004string' untranslated string. https://bugzilla.gnome.org/show_bug.cgi?id=737150 https://bugzilla.gnome.org/show_bug.cgi?id=737160 gio/gsettingsschema.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) commit 8ff5668a458344da22d30491e3ce726d861b3619 Author: Ryan Lortie Date: Sat Jul 26 17:16:37 2014 +0200 GSettings: delay backend subscription GSettings objects begin watching for changes as soon as they are created in order that they can emit the "changed" signal. In the case of dconf, if we want to be able to emit the changed signal, we need to go on the bus and add some match rules. This requires creating the dconf helper thread and also requires initialising GDBus (which creates another thread). Some users of GSettings are never interested in the "changed" signal. One of these users is the glib-networking code that gets run every time a new network connection is created. Some users are reporting that they are annoyed that simply establishing a network connection would spawn two extra threads and create a D-Bus connection. In order to avoid doing unnecessary work for these simple uses, delay the subscription until we know that we will actually need to do it. We do this in a simple way, using a simple argument: in order for the user to care that a value changed then they must have: 1) watched for a change signal; and then 2) actually read a value If the user didn't actually read a value then they cannot possibly be interested in if the value changed or not (since they never knew the old value to begin with and therefore would be unable to observe that it ever changed, since they have nothing to compare the new value with). This really is a behaviour change, however, and it does impact at least one user: the 'monitor' functionality of the GSettings commandline tool, which is interested in reporting changes without ever having known the original values. We add a workaround to the commandline tool in order to ensure that it continues to function properly. It's also possible to argue that it is completely valid to have read a value and _then_ established a change signal connection under the (correct) assumption that it would not have been possible to miss a change signal by virtue of not having returned to the mainloop. Although this argument is true, this pattern is extremely non-idiomatic, and the problem is easily avoided by doing things in the usual order. We never really talked about change notification in the overview documentation for GSettings, so it seems like now is a good time to add some discussion, including the new rules for when one can expect change signals to be emitted. https://bugzilla.gnome.org/show_bug.cgi?id=733791 gio/gsettings-tool.c | 13 +++++++++++++ gio/gsettings.c | 47 +++++++++++++++++++++++++++++++++++++++++++---- 2 files changed, 56 insertions(+), 4 deletions(-) commit 6c080721fc1879d8c92176fe630e00122110ea2e Author: Alberto Ruiz Date: Tue Nov 18 14:43:41 2014 +0000 glib: Improve documentation for g_strfreev() Fixes #740309. glib/gstrfuncs.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) commit 61e125a57783422e25bb0e9616c9115f68641426 Author: Kjartan Maraas Date: Sat Nov 15 18:31:40 2014 +0100 Updated Norwegian bokmål translation. po/nb.po | 340 ++++++++++++++++++++++++++++++++------------------------------- 1 file changed, 171 insertions(+), 169 deletions(-) commit 021c4ad050f979e5b36c34474d5fbb189278acdf Author: Lars Uebernickel Date: Sat Nov 15 10:30:41 2014 +0100 gapplication: enable --help when app has options This should already work according to the documentation, but doesn't because main_options is consumed before the check in g_application_parse_command_line(). Fix by moving the check for main_options up. https://bugzilla.gnome.org/show_bug.cgi?id=740157 gio/gapplication.c | 28 ++++++++++++++-------------- gio/tests/gapplication.c | 45 +++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 59 insertions(+), 14 deletions(-) commit 61cecd5a68743542baf685b47e8a4a5f4a98d205 Author: David King Date: Thu Nov 13 17:49:31 2014 +0000 docs: Add missing opening parenthesis https://mail.gnome.org/archives/gnome-web-list/2014-November/msg00003.html glib/gmem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) commit 1edd463137067ccb7533f3a1e072dc516bb32d86 Author: Volker Sobek Date: Fri May 23 22:45:30 2014 +0200 docs: Update GParamFlags docs. Remove reference to G_PARAM_READWRITE from GParamFlags' description, since commit 6c395244a5db added G_PARAM_READWRITE to GParamFlags. https://bugzilla.gnome.org/show_bug.cgi?id=726037 gobject/gparam.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) commit 20f6cc2a10ba26860e7a6d27c100deadb5497772 Author: Sébastien Wilmet Date: Wed Nov 5 14:00:45 2014 +0100 Simplify code that uses g_queue_insert_before() and insert_after() g_queue_insert_before() and g_queue_insert_after() now accept a NULL sibling. https://bugzilla.gnome.org/show_bug.cgi?id=736620 glib/gqueue.c | 5 +---- glib/tests/sequence.c | 16 +++------------- 2 files changed, 4 insertions(+), 17 deletions(-) commit 8a90f5e9f6da778743aaec365ee4ceb62b717130 Author: Sébastien Wilmet Date: Wed Nov 5 14:03:30 2014 +0100 GQueue: accept a NULL sibling for insert_before() and insert_after() It simplifies a little bit some code that inserts data relative to a GList location, that might be NULL for the tail of the queue. A NULL sibling is probably less useful for insert_after(), so it's more for consistency with insert_before(). https://bugzilla.gnome.org/show_bug.cgi?id=736620 glib/gqueue.c | 35 ++++++++++++++++++++++++----------- glib/tests/queue.c | 2 ++ 2 files changed, 26 insertions(+), 11 deletions(-) commit 012c9dcd820f9679784181568f97c0e1e6b5e37f Author: Chun-wei Fan Date: Mon Nov 3 10:09:14 2014 +0800 gnetworking.h.win32: Move "#undef interface" This is a follow-up commit due to the fix in gnetworking.h.in in commit 7103484 (gnetworking.h.in: move "#undef interface"). gio/gnetworking.h.win32 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) commit 7103484017ff000d01ed94567539d37fa09b32b2 Author: Dan Winship Date: Sun Nov 2 09:36:14 2014 -0500 gnetworking.h.in: move "#undef interface" The win32 headers do: #define interface struct which is just evil and breaks other code that assumes it can use "interface" as a variable name. gnetworking.h was supposed to be doing "#undef interface" after including the win headers, but it did it too soon, resulting in it getting redefined by a later include. Fix this. https://bugzilla.gnome.org/show_bug.cgi?id=738551 gio/gnetworking.h.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) commit 982d0e11d702ff49f69cb90cb65dd71ebd3df54d Author: Dan Winship Date: Tue Oct 28 15:08:43 2014 -0400 GTlsCertificate: fix loading of bad certificate chains g_tls_certificate_new_from_file() was only loading the complete chain if it was fully valid, but we only meant to be validating that it formed an actual chain (since the caller may be planning to ignore other errors). https://bugzilla.gnome.org/show_bug.cgi?id=729739 gio/gtlscertificate.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) commit 0728e62be8bf247f9d097822efd26312367ff133 Author: Ross Lagerwall Date: Mon Sep 8 21:09:08 2014 +0100 doc: Clarify documentation regarding g_file_replace and etags Clarify that with g_file_replace, a non-NULL etag is only checked if the file already exists. https://bugzilla.gnome.org/show_bug.cgi?id=736286 gio/gfile.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) commit 226c292b6ab95014648e9fc0a082bb6c26eeccc8 Author: Ross Lagerwall Date: Wed Oct 29 22:12:39 2014 +0000 gio: Prevent hang writing to a large GMemoryBuffer Fix a hang due to overflow by using unsigned numbers and explicitly checking if the number overflows to zero. This also fixes the previous logic which assigned an int which may be negative to an unsigned number resulting in sign extension and strange results. Use gsize rather than int to allow for large buffers on 64 bit machines. https://bugzilla.gnome.org/show_bug.cgi?id=727988 gio/gdbusmessage.c | 18 ++++++++---------- 1 file changed, 8 insertions(+), 10 deletions(-) commit 5a6f13d16f38ea0a6c9d48332b7e3932b7f3b7d4 Author: Ross Lagerwall Date: Wed Oct 29 22:05:32 2014 +0000 gio: Prevent hang writing to a large GMemoryOutputStream Fix a hang due to overflow by using unsigned numbers and explicitly checking if the number overflows to zero. This also fixes the previous logic which assigned an int which may be negative to an unsigned number resulting in sign extension and strange results. Use gsize rather than int to allow for large streams on 64 bit machines. https://bugzilla.gnome.org/show_bug.cgi?id=727988 gio/gmemoryoutputstream.c | 18 ++++++++---------- 1 file changed, 8 insertions(+), 10 deletions(-) commit b3e3ed73864143e732c4d65441eaec086a3ab83e Author: Dan Winship Date: Tue Mar 13 11:43:38 2012 -0400 gmain: don't pass the same fd to g_poll() multiple times If a given fd is being polled by multiple sources, we used to pass it multiple times to g_poll(), which is technically illegal (and not supported by the select()-based fallback implementation of poll() in gpoll.c), and also made it more likely that we'd exceed the maximum number of pollfds. Fix it to merge together "duplicate" GPollFDs. The easiest way to do this involves re-sorting context->poll_records into fd order rather than priority order. This means we now have to walk the entire pollrec list for every g_main_context_query() and g_main_context_poll(), rather than only walking the list up to the current max_priority. However, this will only have a noticeable effect if you have tons of GPollFDs, and we're already too slow in that case anyway because of other O(n) operations that happen too often. So this shouldn't change much (and the new poll API will eventually let us be cleverer). Remove some win32-specific code which did the same thing (but was O(n^2)). https://bugzilla.gnome.org/show_bug.cgi?id=11059 glib/gmain.c | 86 ++++++++++++++++----------- glib/gpoll.c | 35 ++++------- glib/tests/mainloop.c | 161 ++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 222 insertions(+), 60 deletions(-) commit 66fc112c742f56f85fc34b458325e87df4cd78d0 Author: Owen W. Taylor Date: Thu Oct 9 14:40:45 2014 -0400 GDBusInterfaceVTable: clarify memory handling for the method() virtual function There are two consistent interpretations that could be taken for memory handling of the 'invocation' parameter passed to the method_call() virtual function of GDBusInterfaceVTable - A reference is passed (transfer full) to the method_call() virtual function, and that reference is then passed (transfer full) to the return_value/error functions on GDBusMethodInvocation. - An internal reference is retained from the point where method_call() is called until the return_value/error function is called. Since the return_value/error functions were already marked (transfer full), we use the first interpretation, annotate the invocation parameter of method call as (transfer full) and describe this in the documentation, along with the idea that you are always supposed to call one of the return_value/error functions. See bug 738122 for the leak this caused in GJS. https://bugzilla.gnome.org/show_bug.cgi?id=738259 gio/gdbusconnection.h | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-)