Updated Russian translation
GUnixMount: port unmount to GSubprocess

The existing code is buggy and now that we have GSubprocess, we should just use
it instead, allowing for some substantial reduction in complexity.

https://bugzilla.gnome.org/show_bug.cgi?id=724916
GUnixVolume: port to GSubprocess

Do the same as we just did for GUnixMount, for GUnixVolume too.

https://bugzilla.gnome.org/show_bug.cgi?id=724916
GUnixVolume: implement _finish functions

The _finish functions for GUnixVolume _mount and _eject functions were
never implemented, having been simply stubbed out as 'return TRUE;'.

Implement them.

https://bugzilla.gnome.org/show_bug.cgi?id=724916
Updated Portuguese translation
Update config.h.win32.in

Make the entries of config.h.win32.in match those that are being checked
in config.h.in.
gsettingsbackend: a minor simplification

Change the order of the arguments on the (internal) keys_changed callback in
GSettingsListenerVTable.

This means that all functions in the table now fit the following signature:

  void (* f) (GObject             *target,
              GSettingsBackend    *backend,
              const gchar         *name_or_path,
              gpointer             origin_tag,
              const gchar * const *names);

allowing the possibility of arguments ignored at the end.

This allows us to simplify our dispatch-to-thread code in GSettingsBackend,
making it a bit less generic.

So far, this should be a straight refactor.

https://bugzilla.gnome.org/show_bug.cgi?id=710367
GSettingsBackend: fix a nasty race condition

In the event that a GSettings object is being destroyed just as a change
signal is being delivered, the destroying thread will race with the
dconf worker thread for acquiring the lock on the GSettingsBackend.

If the signalling thread gets there first then the destroying thread
will block on the lock.  The signalling thread adds a reference to the
GSettings object that is being destroyed and releases the lock.  The
idea is that this should prevent the GSettings object from being
destroyed and thus maintain its entry in the list.  Unfortunately, the
weak reference notify function is already running and as soon as we
release the lock, the list entry is removed.

The signalling thread crashes.

This bug is indicative of a serious problem encountered in many
situations where GObject instances are touched from multiple threads.
Ideally, we will move to a place where g_object_ref() is not called at
all on the GSettings object from the dconf worker thread and instead, a
dispatch will be done without holding a reference (similar to how
GAppInfoMonitor presently works).  This would also prevent the
unfortunate case of someone dropping what they assume to be the last
reference on a GSettings object, only to have an already-pending signal
delivered once they return to the mainloop, crashing their program.

Making this change for GSettings (with multiple instances per thread,
the possibility of multiple backends and each instance being interested
in different events) is going to be extremely non-trivial, so it's not a
change that makes sense at this point in the cycle.

For now, we can do a relatively small and isolated tweak so that we
never access the list except under a lock.  We still perform the bad
pattern of acquiring a ref in a foreign thread which means that we still
risk delivering a signal to a GSettings object that the user has assumed
is dead (unless they explicitly disconnect their signal handler).  This
is a problem that we already had, however.

https://bugzilla.gnome.org/show_bug.cgi?id=710367
Updated French translation
GLib 2.39.92
update Punjabi Translation 17March2014: Alam
gbinding: warn on failed value transformation

GBinding warned if g_value_transform() returned FALSE, but it didn't
warn if there was no transformation available at all. Fix that and
test it.

https://bugzilla.gnome.org/show_bug.cgi?id=726574
Updated Serbian translation
Updated Danish translation
Clarify expectations with error codes like G_IO_ERROR_FAILED

If an error code enumeration is expected to be extended in the future,
people shouldn't compare explicitly against its generic "FAILED" value.

https://bugzilla.gnome.org/show_bug.cgi?id=726775
gio/tests/socket: skip IPv6 tests on IPv6-less machines

https://bugzilla.gnome.org/show_bug.cgi?id=667468
Updated Hungarian translation
Update Czech translation
socketclient: Fix leak

https://bugzilla.gnome.org/show_bug.cgi?id=726611
gio: fix two more g_task_return_error_if_cancelled() leaks

https://bugzilla.gnome.org/show_bug.cgi?id=726611