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

[Andrew Hayzen]

Hi Simon,

Thank you for responding it is much appreciated and provided us with
useful information.


tl;dr; We have marked test-unused.sh as flaky and are ignoring fails on
s390x, this has allowed flatpak to migrate successfully - we hope to
submit the diff back to Debian once things have settled so that
autosyncing can continue.


One of the KDE Ubuntu developers needed a change in flatpak for plasma-
discover to migrate, so they were able to assist. (I believe the same
changes you just added to 1.10.1-3 :-D )


Firstly, the arm64 failure of test-unused.sh, that you have also seen
failing, we have marked as flaky to allow arm64 to migrate.

Secondly, after the change for plasma-discover was made and the tests
were re-run on s390x the ldd errors disappeared (maybe due to other
transitions happpening in the archive) but some other tests were still
failing. We have taken the decision that it is unlikely there are many
flatpak users on s390x, so fails are ignored on this platform now.

Thirdly, after this change and the flaky test marked, ppc64el started
passing again.

Fourthly, there is a new glib2.0 in proposed that makes flatpak
autopkgtests break on all archs (and curiously also libsoup), so we are
going to see if that results in any changes being made to flatpak or
libsoup or if it'll be accepted this cycle.  If changes are made to
flatpak we'll submit any diff back to Debian as well :-)


And regarding Ubuntu infrastructure, I *think* that virtual
autopkgtests are run inside lxd [0] - but I'm not totally sure I would
have to ask. And I believe "nova" is related to OpenStack.


Thanks for your help as always,

Andrew

0 -
https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Worker_service_in_the_cloud

On Wed, 2021-02-24 at 18:38 +0000, Simon McVittie wrote:
> 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