Package: glib2.0 / 2.48.0-1~bpo8+1

Metadata

Package Version Patches format
glib2.0 2.48.0-1~bpo8+1 3.0 (quilt)

Patch series

view the series file
Patch File delta Description
01_gettext desktopfiles.patch | (download)

glib/gkeyfile.c | 71 71 + 0 - 0 !
glib/gkeyfile.h | 3 3 + 0 - 0 !
2 files changed, 74 insertions(+)

 add some description
02_gettext desktopfiles ubuntu.patch | (download)

glib/gkeyfile.c | 20 20 + 0 - 0 !
1 file changed, 20 insertions(+)

 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 !
1 file changed, 4 insertions(+), 2 deletions(-)

 disable confusing (to users) warning about deprecated schema paths
04_homedir_env.patch | (download)

docs/reference/glib/running.xml | 18 18 + 0 - 0 !
glib/gutils.c | 10 9 + 1 - 0 !
2 files changed, 27 insertions(+), 1 deletion(-)

 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 !
1 file changed, 4 insertions(+), 2 deletions(-)

 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 !
gio/tests/socket.c | 2 2 + 0 - 0 !
glib/tests/mainloop.c | 4 4 + 0 - 0 !
glib/tests/timeout.c | 2 2 + 0 - 0 !
4 files changed, 10 insertions(+)

 disable tests on slow architectures which keep failing the tests.
61_glib compile binaries path.patch | (download)

gio-2.0.pc.in | 4 2 + 2 - 0 !
1 file changed, 2 insertions(+), 2 deletions(-)

 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 | 3 3 + 0 - 0 !
1 file changed, 3 insertions(+)

 gio: add fallback directory for pre-multiarch compatibility
Date: Sat, 16 Jul 2011 13:12:48 -0700

skip brokwn dbus appinfo test.patch | (download)

gio/tests/Makefile.am | 1 0 + 1 - 0 !
1 file changed, 1 deletion(-)

 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 !
1 file changed, 7 insertions(+)

 [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

81 skip monitor test on non linux.patch | (download)

gio/tests/monitor.c | 2 2 + 0 - 0 !
1 file changed, 2 insertions(+)

 skip the monitor test on non-linux as it currently hangs

0001 timer test use volatile for locals.patch | (download)

glib/tests/timer.c | 4 2 + 2 - 0 !
1 file changed, 2 insertions(+), 2 deletions(-)

 [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 !
1 file changed, 1 insertion(+), 1 deletion(-)

 skip test which performs some unreliable floating point comparisons
0001 Fix trashing on overlayfs.patch | (download)

gio/glocalfile.c | 15 14 + 1 - 0 !
1 file changed, 14 insertions(+), 1 deletion(-)

 [patch] fix trashing on overlayfs

In order to determine whether to trash a file to the home directory, we
compare its st_dev to our home directory's st_dev field.

This is the wrong thing to do on overlayfs when deleting files, because
st_dev contains the ID of the filesystem providing the file (which can
be the lower or upper filesystem), but directories always return the ID
of the overlayfs. Thus the comparison fails and we are unable to trash
the file.

Fix this by checking st_dev of the parent directory when we are deleting
a file.

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