Hi Steve, On 24.02.19 16:12, Steve Langasek wrote: > I see that since 1.6-3, keyutils now tries to split its autopkgtests between > those that do require machine isolation, and those that do not.
Just for clarification: I messed this up a bit, the net result was that both tests were identical in 1.6-3. This was fixed shortly after in 1.6-4. But I see from the link below that you tested 1.6-4 as well. > This means that for the first time, Ubuntu is able to run these tests > on armhf, an architecture for which we only have container runners, > not VMs; and these tests now show a test failure on armhf:> > +++ ADD ONE ARG > Running with session keyring RHTS/keyctl/2648 > keyutils version: keyctl from keyutils-1.6 (Built 2019-02-22) > === > /tmp/autopkgtest.K1pALO/autopkgtest_tmp/tests/keyctl/padd/useradd/test.out === This is one of the (few) tests requiring root to run, as it has the potential to change /proc/sys/kernel/keys/root_maxbytes. We skip these tests at build time, which would explain why the buildds didn't trigger the issue... > +++ ADD USER KEY > +++ PRINT PAYLOAD > +++ UPDATE USER KEY > +++ PRINT UPDATED PAYLOAD > +++ UNLINK KEY> +++ ADD LARGE USER KEY > FAILED > Unparsable key: 'no' > make: *** [Makefile:41: run] Error 1 > FAILED > +++ CLEAR KEYRING > > (http://autopkgtest.ubuntu.com/packages/k/keyutils/disco/armhf)> > Since the Debian autopkgtest runners also use containers instead of VMs, and > this test passes there, it is plausible that this is a bug in the package > onchange > armhf rather than a wrong restriction on this subtest. It's really hard to say because this package is notoriously hard to test, as it's just the userspace tooling for a kernel feature... On the Debian buildds, I've also run into everything from architecture-specific kernel bugs to version-specific kernel bugs to buildd-specific kernel config issues. The logs don't offer that much, so I was planning to upload a 1.6-5 soon that also saves away all the test artifacts for analysis (it still FTBFS on alpha, for example). Could I ping you for a re-test on armhf, or will that even be triggered automatically? I do intend to set up VMs for various architectures to test this locally, but I'm afraid I won't get to that until March... Thanks for the report! Christian
