Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • G GLib
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 862
    • Issues 862
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 41
    • Merge requests 41
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GNOMEGNOME
  • GLib
  • Issues
  • #1643
Closed
Open
Issue created Jan 08, 2019 by Simon McVittie@smcvMaintainer

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?

Assignee
Assign to
Time tracking