[Pkg-utopia-maintainers] Bug#1025532: ostree: often FTBFS on s390x: tests/test-sysroot.js:96: deploymentPath.query_exists(null) should be false

[Simon McVittie]

Source: ostree
Version: 2021.5-1
Severity: important
Tags: ftbfs help
X-Debbugs-Cc: debian-s390 at 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