commit 3f5a78a248406611c3eb7096a72749c892d47653
Author: Matthias Clasen <mclasen@redhat.com>
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 <danw@gnome.org>
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 <rosslagerwall@gmail.com>
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 <jstpierre@mecheye.net>
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 <drawoc@darkrefraction.com>
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 <drawoc@darkrefraction.com>
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 <danw@gnome.org>
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 <fanchunwei@src.gnome.org>
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 <chpe@gnome.org>
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 <desrt@desrt.ca>
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 <aruiz@gnome.org>
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 <kmaraas@gnome.org>
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 <lars.uebernickel@canonical.com>
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 <amigadave@amigadave.com>
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 <reklov@live.com>
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 <swilmet@gnome.org>
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 <swilmet@gnome.org>
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 <fanchunwei@src.gnome.org>
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 <danw@gnome.org>
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 <danw@gnome.org>
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 <rosslagerwall@gmail.com>
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 <rosslagerwall@gmail.com>
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 <rosslagerwall@gmail.com>
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 <danw@gnome.org>
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 <otaylor@fishsoup.net>
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(-)