Package: glib2.0 / 2.42.1-1
Metadata
Package | Version | Patches format |
---|---|---|
glib2.0 | 2.42.1-1 | 3.0 (quilt) |
Patch series
view the series filePatch | File delta | Description |
---|---|---|
01_gettext desktopfiles.patch | (download) |
glib/gkeyfile.c |
71 71 + 0 - 0 ! |
add some description |
02_gettext desktopfiles ubuntu.patch | (download) |
glib/gkeyfile.c |
20 20 + 0 - 0 ! |
provide backwards compatibility for 01_gettext-desktopfiles.patch for x-{debian,ubuntu}-gettext-domain # UbuntuSpecific: 01_gettext-desktopfiles.patch was changed to use X-GNOME-, so this is necessary until all our .desktop files are converted |
03_disble_glib_compile_schemas_warning.patch | (download) |
gio/glib-compile-schemas.c |
6 4 + 2 - 0 ! |
disable confusing (to users) warning about deprecated schema paths |
04_homedir_env.patch | (download) |
docs/reference/glib/running.xml |
18 18 + 0 - 0 ! |
handle the g_home environment variable to override the passwd entry This will allow to fix various kinds of build failures due to restricted build environments. |
06_thread_test_ignore_prctl_fail.patch | (download) |
glib/tests/thread.c |
6 4 + 2 - 0 ! |
do not fail the /thread/thread4 test if prctrl() fails. this happens on the debian buildds. |
07_disable_tests_on_slow_archs.patch | (download) |
gio/tests/gdbus-threading.c |
2 2 + 0 - 0 ! |
disable tests on slow architectures which keep failing the tests. |
10_kfreebsd_issetugid_prototype.patch | (download) |
glib/gutils.c |
6 6 + 0 - 0 ! |
--- |
11_kfreebsd_pthread_condattr_setclock_prototype.patch | (download) |
glib/gthread-posix.c |
6 6 + 0 - 0 ! |
--- |
13_sparc_prlimit_prototype.patch | (download) |
configure.ac |
3 3 + 0 - 0 ! |
--- |
61_glib compile binaries path.patch | (download) |
gio-2.0.pc.in |
4 2 + 2 - 0 ! |
adjust path to glib-compile-schemas in the pkg-config file This is because gio-querymodules and glib-compile-schemas have been put in a private, versioned directory in libglib2.0-0 to avoid a dependency loop. |
90_gio modules multiarch compat.patch | (download) |
gio/giomodule.c |
2 2 + 0 - 0 ! |
--- |
skip brokwn dbus appinfo test.patch | (download) |
gio/tests/Makefile.am |
1 0 + 1 - 0 ! |
the dbus-appinfo test hangs in a build environment (with no x server) |
Do not attempt to autolaunch a session dbus daemon w.patch | (download) |
gio/gdbusaddress.c |
7 7 + 0 - 0 ! |
[patch] 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 |
gdbus Let the pending read finish before closing the.patch | (download) |
gio/gdbusprivate.c |
75 38 + 37 - 0 ! |
[patch] gdbus: let the pending read finish before closing the connection This prevents the GIOStream from being closed with a read pending on the input substream. g_io_stream_close_async() is actually supposed to fail in this case; see https://bugzilla.gnome.org/show_bug.cgi?id=707912 Bug: https://bugzilla.gnome.org/show_bug.cgi?id=723719 Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738290 |
gdbus tests wait up to 60s for gdbus testserver to t.patch | (download) |
gio/tests/gdbus-connection-loss.c |
3 1 + 2 - 0 ! |
[patch] gdbus tests: wait up to 60s for gdbus-testserver to take its bus name 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 |
gdbus connection wait up to 10s to actually send a m.patch | (download) |
gio/tests/gdbus-connection.c |
14 12 + 2 - 0 ! |
[patch] gdbus-connection: wait up to 10s to actually send a message We previously waited 0.25s, which should be enough even on slow machines, but you never know; but we also now wait in 0.1s increments, so this test should actually be faster now. Bug: https://bugzilla.gnome.org/show_bug.cgi?id=724113 |
81 skip monitor test on non linux.patch | (download) |
gio/tests/monitor.c |
2 2 + 0 - 0 ! |
--- |
0001 timer test use volatile for locals.patch | (download) |
glib/tests/timer.c |
4 2 + 2 - 0 ! |
[patch] timer test: use 'volatile' for locals GCC seems to be failing to follow the letter of the C spec by allowing extra precision in floating point values to persist across assignments which are optimised away. Force its hand by using 'volatile' on the locals in question. https://bugzilla.gnome.org/show_bug.cgi?id=722604 |
skip broken timer test.patch | (download) |
glib/tests/timer.c |
2 1 + 1 - 0 ! |
skip test which performs some unreliable floating point comparisons |
regex if PCRE is 8.34 or later disable auto possessi.patch | (download) |
glib/gregex.c |
122 89 + 33 - 0 ! |
[patch 4/4] 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.patch | (download) |
glib/tests/regex.c |
3 3 + 0 - 0 ! |
[patch 3/4] 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 .patch | (download) |
glib/tests/regex.c |
6 5 + 1 - 0 ! |
[patch 2/4] 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 |