GIO trash test sometimes fails: test_trash_symlinks: 'target_mount' should not be NULL
gio/tests/trash.c
fails on Ubuntu's Launchpad autobuilders:
1..2
# Start of trash tests
# Bug Reference: https://gitlab.gnome.org/GNOME/glib/issues/251
# File: /tmp/test-trashRH6RUZ (parent st_dev: 64769)
# Home: /<<PKGBUILDDIR>>/debian/build (st_dev: 64769)
ok 1 /trash/not-supported # SKIP The file has to be on another filesystem than the home trash to run this test
# Bug Reference: https://gitlab.gnome.org/GNOME/glib/issues/1522
**
GLib-GIO:ERROR:../../../gio/tests/trash.c:113:test_trash_symlinks: 'target_mount' should not be NULL
Bail out! GLib-GIO:ERROR:../../../gio/tests/trash.c:113:test_trash_symlinks: 'target_mount' should not be NULL
This is a regression between 2.58.1 and 2.58.2, possibly caused by 57cfbc93.
These autobuilders build GLib in a chroot; I'm not sure whether its root is a mount point itself, or a subdirectory of a mount point, or what. On Debian's very similar autobuilders this test works fine.
I get the same test failure (possibly for unrelated reasons) on my laptop, which happens to use btrfs. Minimal reproducer (all subvolumes mentioned are on the same LVM volume):
>>> from gi.repository import Gio
>>> def t(path):
... entry = Gio.unix_mount_for(path)[0]
... if entry is None:
... return '(none)'
... else:
... return Gio.unix_mount_get_mount_path(entry)
# / has btrfs subvolume '@' mounted on it
>>> t("/")
'/'
# /home has btrfs subvolume 'home' mounted on it
>>> t("/home")
'/'
# /home/smcv is a subvolume 'home/smcv' that exists inside /home, but is not
# mounted separately (does not appear in /proc/self/mounts)
>>> t("/home/smcv")
'(none)'
# /home/smcv/.local is just a subdirectory
>>> t("/home/smcv/.local")
'(none)'
# /var is just a subdirectory of the root
>>> t("/var")
'/'
# /var/tmp is a subvolume 'var/tmp' that exists inside @/var, but is not
# mounted separately (does not appear in /proc/self/mounts)
>>> t("/var/tmp")
'/'
# /var/tmp/smcv is just a subdirectory
>>> t("/var/tmp/smcv")
'(none)'
The test says "The test assumes that ~/.local always exists" which seems like a wrong assumption and should probably be fixed (in a minimal autobuilder/test environment it's possible that this test is the first thing to try to use that directory). However, creating .local is not sufficient to fix this.
As a short term solution I've written a patch to skip this test if the mount for target
or tmp
cannot be determined, but that's probably masking a more fundamental problem here?