Updated Serbian translation
Update URLs library.gnome.org -> developer.gnome.org
gresource: Use GError in more places

The API gives us an error message, lets use it.
gresource: Make extract work better

When no section is specified, look for the resource to extract
in all sections - previously, we would stop after the first
section.
GVariant: say that serialized form needs an out-of-band length

This confused me for a while, because it isn't the same as D-Bus.
Like GVariant, the D-Bus serialization needs an out-of-band
endianness and type indicator, but unlike GVariant, serialized
D-Bus objects encapsulate their own length (often by starting with
a byte-count). This does come at some redundancy cost, so I can see
why the more efficient GVariant format does this the way it does;
but it's a difference between D-Bus and GVariant that seems worth
calling out.

It's also relevant for the designers of file or message-framing
formats: with D-Bus serialization it would be feasible to say "the file
starts with a little-endian D-Bus variant, followed by...",
but in GVariant you wouldn't be able to deserialize the variant
unless you either assume that it extends to end-of-file, or have
an explicit length.

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=736975
Reviewed-by: Ryan Lortie
gsource: clarify restrictions on non-existant IDs

Document that one must not use the "by id" source APIs with non-existent
IDs.  The real justification behind this restriction is that the reuse
of source ids makes it unsafe to call these functions unless you're
absolutely sure that the source exists and it belongs to you.  If you
call one of these functions on a source that may already have been
removed then you run the risk of finding someone else's source (with
your reused id).

This also bails us out of a slightly tricky situation with respect to
the threadsafety of g_main_context_find_source_by_id().  The fact that
this function doesn't return a reference implies that its return value
cannot be safely accessed unless we already know for sure that a
reference is being held elsewhere (by example, by the main context
itself if we know that the source has not been removed).  The function
itself, however, performs an access to the value, which could result in
a crash.

If we mandate that it is only valid to call this function on
known-to-exist source IDs then we dodge this problem.

https://bugzilla.gnome.org/show_bug.cgi?id=736683
gmain: improve g_source_set_name thread safety

Step up thread safety on g_source_set_name() to the same standard as all
other GSource functions: after we are attached to a main context, this
function should be threadsafe.

https://bugzilla.gnome.org/show_bug.cgi?id=736683
Updated Danish translation
update zh_CN translation
update zh_CN translation
Revert "update zh_CN translation"

Add wrong po file
This reverts commit ee3d55573ff3731b2f92deb5e35decc316d53475.
Updated Hindi translation
update Punjabi Translation for 3.14 release
GLib 2.42.0
gtask: Fix a signed/unsigned integer comparison

The GSource times assigned to creation_time are always signed.

https://bugzilla.gnome.org/show_bug.cgi?id=736806
gtask: Document signal handler reference counting

Explain why the signal handler holds a reference to the GTask, even
though that causes a reference loop at first glance.

https://bugzilla.gnome.org/show_bug.cgi?id=736806
gtask: Ignore errors from g_thread_pool_push()

g_thread_pool_push() only returns an error if it fails to spawn a new
thread. However, it unconditionally adds the task to its worker queue,
so:
 • if _any_ threads exist in the pool, the task will eventually be
   handled; and
 • if _no_ threads exist in the pool, the task will be handled if one
   is eventually successfully spawned.
If no more threads are ever spawned, the process probably has bigger
problems than a single GTask which is taking forever to complete.

https://bugzilla.gnome.org/show_bug.cgi?id=736806
Updated Bengali (India) translation
Include <stdint.h> in glib/valgrind.h

This ensures the uintptr_t type is defined on mingw-w64.

Fixes compile error:

make[4]: Entering directory
`/home/abuild/rpmbuild/BUILD/glib-2.42.0/gobject'
  CC       libgobject_2_0_la-gtype.lo
In file included from gtype.c:24:0:
../glib/valgrind.h: In function 'VALGRIND_PRINTF':
../glib/valgrind.h:5601:4: error: unknown type name 'uintptr_t'
    uintptr_t _qzz_res;
    ^

https://bugzilla.gnome.org/show_bug.cgi?id=737143
Updated Telugu translation