Source: ostree
Version: 2021.5-1
Severity: important
Tags: ftbfs help
X-Debbugs-Cc: debian-s...@lists.debian.org
Forwarded: https://github.com/ostreedev/ostree/issues/2527
Since ostree 2021.5-1, one build-time test has regularly been failing
on the s390x buildds, and since 2022.7-1 it seems to be failing every
time (3/3 attempts failed in this way). I cannot reproduce this on the
s390x porterbox zelenka (2/2 attempts built successfully) or on other
architectures.
Is there something different about the schroot available on the
non-developer-accessible official buildds zani and zandonai, other than
lack of interactive access? Perhaps different hardware, or a different
kernel, or a different filesystem?
The failing test shows up like this:
> (gjs:2405872): Gjs-CRITICAL **: 00:36:37.701: JS ERROR: Error: assertion
> failed true == false
> assertEquals@/<<PKGBUILDDIR>>/tests/test-sysroot.js:26:8
> @/<<PKGBUILDDIR>>/tests/test-sysroot.js:96:13
...
> ERROR: tests/test-sysroot.js - too few tests run (expected 1, got 0)
> ERROR: tests/test-sysroot.js - exited with status 133 (terminated by signal
> 5?)
For context for porters, libostree is like git, but for OS binaries rather
than source code. This particular test is using its JavaScript bindings
to "deploy" a particular commit (analogous to `git checkout` or
`git worktree add`), assert that it appears at the expected path
(line 87, successful), remove all deployments (line 92, analogous to
`git worktree remove`), and then assert that the deployment path has
been deleted (line 96, which is where we are failing).
87: assertEquals(deploymentPath.query_exists(null), true);
88:
89: print("OK one deployment");
90:
91: /// TEST: We can delete the deployment, going back to empty
92: sysroot.write_deployments([], null);
93:
94: print("OK empty deployments");
95:
96: assertEquals(deploymentPath.query_exists(null), false); <--
There are several places this could be going wrong: it could be
a portability problem in gjs or mozjs102 (which would explain why
similar tests in C pass), or it could be that GLib's use of statx() or
faccessat() or some similar syscall to implement g_file_query_exists()
is going wrong on these particular machines, or it could be genuinely
a problem with libostree.
I think the "sysroot" referred to here is dealing with the root filesystem
of a machine or container that is managed by deploying pre-prepared root
filesystem snapshots via libostree rather than using apt/dpkg directly,
which is not something we really promote in Debian (although some
derivatives like EndlessOS use it to upgrade appliance-style machines).
libostree is still (believed to be) useful on s390x for its use in
Flatpak, even if this particular feature doesn't work, so I intend to
make this bug non-RC by disabling this particular test on s390x. Anyone
who particularly wants to use libostree to manage stateless pre-prepared
root filesystem snapshots on s390x is very welcome to look into what is
going on here.
smcv
