Merge tag '2.42.1' into update_to_2.42.1_upstream

Update from upstream to 2.42.1 source

Conflicts:
	NEWS
	build/win32/Makefile.am
	configure.ac
	gio/gioerror.c
	gio/gthreadedresolver.c
	gio/tests/socket.c
	glib/gutils.c
	gobject/gtype.h
	po/ca.po
	po/cs.po
	po/da.po
	po/de.po
	po/el.po
	po/eu.po
	po/hu.po
	po/id.po
	po/sl.po
	po/sr.po
	po/sr@latin.po
03_disble_glib_compile_schemas_warning
04_homedir_env
10_kfreebsd_issetugid_prototype
11_kfreebsd_pthread_condattr_setclock_prototype

Add a prototype for pthread_condattr_setclock() when building
on kFreeBSD since the prototype there is missing. The glibc bug
to add the missing prototype is http://bugs.debian.org/703545,
we can remove this hack when that is fixed.
13_sparc_prlimit_prototype
Do not attempt to autolaunch a session dbus-daemon with no DISPLAY

The two known use-cases for autolaunching are:

* X-forwarding: "ssh -Y myhost myapp" resulting in a
  session bus on myhost but an X server on the original host

* Legacy desktop environments on OSs without D-Bus integration:
  e.g. running a single GNOME or KDE app under fvwm or something,
  without a session dbus-daemon being started by either systemd,
  gnome-session, or OS integration scripts analogous to Debian's
  /etc/X11/Xsession.d/75dbus_dbus-launch

In either case, an X11 DISPLAY is also needed.

"dbus-launch --autolaunch" doesn't do anything useful when unable
to connect to an X11 display; this has been the case since the feature
was added in 2006, and is useful to avoid "split brain" situations in
which two processes that ought to be part of the same session end up
on separate session buses. Since dbus commit 407c111 in 2011,
libdbus hasn't even attempted to run "dbus-launch --autolaunch"
unless getenv("DISPLAY") returns non-null in the parent: this avoids
doing a relatively complicated fork-and-exec that is clearly not
going to lead to success. This commit gives GDBus the same policy.

In Debian, I've encountered GLib test failures in
gio/tests/gapplication.c which appear to be related to the
fork-and-exec for dbus-launch (Debian bug #737380). Specifically,
one test-case ends by calling g_test_dbus_unset(), and the next
test-case tries to access the session bus with DBUS_SESSION_BUS_ADDRESS
unset, resulting in an attempt to autolaunch. Checking for DISPLAY
avoids this attempt to autolaunch, since g_test_dbus_unset() also
unsets DISPLAY. It seems likely that there is some orthogonal bug here,
perhaps involving g_spawn_sync() in the GDBus thread racing with
g_spawn_async_with_pipes() in the main thread, but GApplication is
probably not the ideal place to debug that.

In my opinion as D-Bus maintainer, "dbus-launch --autolaunch" should
be considered to be an X11 feature, and any future D-Bus enhancements
(e.g. kdbus) or successors for X11 (e.g. Wayland, Mir) should obtain
a session bus address by other means - either a session manager
such as "systemd --user", gnome-session or Upstart, or a wrapper
for the user session like dbus-run-session(1).

Related to dbus bug <https://bugs.freedesktop.org/show_bug.cgi?id=19997>.

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=723506
Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737380
regex: if PCRE is 8.34 or later, disable auto-possessification for DFA

Normally, recent PCRE behaves as if certain patterns were replaced
by a more "possessive" pattern that gives the same answer for normal
regex matching, but is more efficient. However, the modified pattern
produces fewer results under DFA. If we want the full set of results
we have to apply PCRE_NO_AUTO_POSSESS, and that's a compile-time flag.

This currently only affects a system PCRE, but would also work fine for
an internal PCRE 8.34 or later if the embedded copy is updated.

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=733325
regex test: do not assert that system PCRE allows "(?P<1>)"

Perl >= 5.18, and PCRE >= 8.34, disallow this.

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=733325
regex test: do not assert that system PCRE still has an 8.31 bug

This was fixed in 8.32.

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=733325
[PATCH] gdbus tests: wait up to 60s for gdbus-testserver to take its bus name

Had to manually apply parts of the patch since it wouldn't do it cleanly

Original patch details below:

Previously, we waited up to 0.5s, but that can fail on slow
architectures like ARM; now we wait up to 60s in 0.1s increments.

Patch originally by Simon McVittie <simon.mcvittie@collabora.co.uk>,
modified by Iain Lane to be called earlier, to catch all testcases in a
particular test.

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