[Pkg-utopia-maintainers] Flatpak 1.10.1-2 autopkgtests failing on Ubuntu preventing migration

[Simon McVittie]

On Thu, 18 Feb 2021 at 00:24:51 +0000, Andrew Hayzen wrote:
> I know this is not Debian specific but wondered if you had any ideas as
> the packaging is currently synced between Ubuntu and Debian.
> 
> The autopkgtest's for flatpak 1.10.1-2 are currently failing for arm64,
> ppc64el, and s390x in Ubuntu and are preventing auto migration into
> 21.04 [0].

I'm sorry, I don't know how Ubuntu infrastructure is set up. All I can
tell you is that before each upload, I run tests on autopkgtest-virt-qemu
on amd64, and if they fail I consider that to be an upload blocker.

In general, the test logs are an absolute nightmare to read. Sorry - I've
done my best to improve the tests upstream, but the amount of time I can
spend on Flatpak is limited (packaging it is not my day job).

Because Flatpak is a container framework, some of its tests will not
work when already running in a container. I make sure they're skipped
appropriately under at least lxc. However, if Ubuntu infrastructure is
using something like lxd, then that might behave differently enough that
some tests are attempted but then fail.

These tests seem to be running under something called nova. I don't know
what this is or what it's based on - is this a virtual machine, or a
container, or what? How would a developer replicate a similar system
(ideally an exact match) locally?

You linked to the same arm64 log twice and the s390x log once, so I
don't have access to a ppc64el log.

The arm64 failure might well just be a flaky test, unfortunately. I think
I've seen test-unused.sh failing sometimes.

> Furthermore it looks like a lot of the [s390x] failures have this
> line (or similar) shortly before the failure:
> bwrap: execvp bash: No such file or directory

The s390x failures, or at least a lot of them, seem to be because
tests/make-test-repo.sh relies on running ldd(1) to find the shared
library dependencies of some basic executables (bash, ls, cat, echo,
readlink and socat), but in the s390x log we can see

    not a dynamic executable

printed 6 times. I think this might mean that ldd isn't working? Can you
get a shell on an Ubuntu s390x machine and investigate that?

Debian does not have any infrastructure where I can run these tests on
s390x (the porterbox uses schroot, and bubblewrap is known not to work
in a schroot environment) so I have never tried these tests on that
architecture.

    smcv