[pkg-apparmor] Bug#954655: apparmor autopkgtest doesn't work nice on ci.d.n infrastructure

[intrigeri]

Hi,

Paul Gevers (2020-03-22):
> I'm not sure what's going on, but I wanted to at least inform you that
> the apparmor autopkgtest is not working smoothly on the ci.debian.net
> infrastructure. Something in the test is very often preventing
> autopkgtest (the binary) from stopping and cleaning up the lxc container
> within the 600 seconds it gets to do that, which leads to a tmpfail for
> the apparmor autopkgtest and a still running lxc container on the
> worker. Obviously there's a bug somewhere in either lxc and/or
> autopkgtest, as you shouldn't be able to break the infrastructure in
> this way, but maybe you have a clue what could be the cause of this and
> help us to fix the underlying issue. Your autopkgtest itself normally
> passes before causing the issue.

Thanks for letting me know — sorry for the delay in answering.

I don't really have a clue at this stage.

My approach would be to first figure out which one, among the 2 tests
(compile-policy and test-installed), is causing the breakage.
And if the problem lies in compile-policy, I'd like to check
if the problem comes from a specific Depends of that test.

Ideally I would do that without doing uploads to sid merely for
bisection purposes. I'm willing to do test uploads to experimental.

In the debci self-service interface, it seems I could force debci to
install all packages built from src:apparmor from experimental,
which looks like what I need.

Now, to run those tests, I would need apparmor to be temporarily
removed from the blacklist, and some coordination so that a ci.d.n
maintainer can clean up whatever mess the tests create while the
package is temporarily un-blacklisted.

I would be happy to book some time to work on this in
a coordinated manner.

Does this approach make sense to you?
Is there a better way for me to investigate?

> One thing that may be required in your test if the test itself doesn't
> get updated is to mark it as isolation-machine

I agree this would be a better outcome than fully disabling all
testing of this package on debci (which is, understandably, the
current situation).

> although I'd like to understand the issue a bit better to know
> for sure.

Same!