Hi all, first off, yes, this is no problem with autopkgtest but a problem with the mmdebstrap testsuite. Thanks for re-assigning!
Quoting Simon McVittie (2021-02-22 10:35:27) > On Mon, 22 Feb 2021 at 09:15:49 +0900, Ryutaroh Matsumoto wrote: > > I report yet another testbed difference between lxc and qemu, > > affecting mmdebstrap 0.7.5-1 testsuite. > > Please note that differences between the testbed backends do not > *necessarily* indicate a bug in autopkgtest. If we could guarantee that > the behaviour of each backend would be the same in all respects, then we > would not need multiple backends, or the isolation-machine and > isolation-container restrictions. > > We have multiple backends *because* they are different. On top of that, even those definitions are not precise enough for a package like mmdebstrap because depending on the virtualization or the type of container, you can do different stuff in it. > > On lxc testbed, the testsuite always return > > testsuite SKIP exit status 77 and marked as skippable > > This appears to have happened because the test runs make_mirror.sh with > a 20 minute timeout, but that operation timed out and was terminated. > > I think it would be useful if this made use of a configured http proxy > in the testbed (if any) - that would probably make testing a lot faster > in the case where something like apt-cacher-ng is used. > > It would probably also be useful if the time actually taken for mirroring > could be shown in the logs, to be able to assess whether the 20 minute > timeout is enough. If anybody could tell me a reliable way to download packages via apt on ci.debian.net and salsaci, that would be greatly appreciated. As things are, apt often times out and to prevent this from becoming a FAIL, I introduced this timeout and then marked the test result as "neutral". Without that, the test was quite flaky as apt would sometimes stall for a long time during network access. That's also why I retry the initial downloading step three times. That way, even if there is a network error, it will succeed in the next try and thus the whole test run will be successful despite the initial network timeout. > > while on qemu it always return > > testsuite FAIL non-zero exit status 1 > > > > testsuite-stderr on qemu ends as: > > + capsh --drop=cap_sys_admin -- -c exec "$@" exec mmdebstrap --mode=root > > --variant=apt testing /tmp/debian-chroot http://127.0.0.1/debian > > E: root mode requires mount which requires CAP_SYS_ADMIN > > + ret=25 > > + [ 25 = 0 ] > > + rm -r /tmp/debian-chroot > > rm: cannot remove '/tmp/debian-chroot': No such file or directory > > test.sh failed > > This looks more like a bug in mmdebstrap (or a bug in mmdebstrap's > tests?) being detected by the test. I can reproduce this locally in > 0.7.5-2 (I used autopkgtest-build-qemu and autopkgtest directly, rather > than using debci). That's a bug in mmdebstrap's testsuite which I fixed three days ago: https://gitlab.mister-muffin.de/josch/mmdebstrap/commit/5fd1ca62d98a9de8ea6a446f934d821027febdaa > It's possible that this is only detectable on backends with full > machine isolation such as qemu or null, because the lxc backend doesn't > necessarily have enough privileges to be able to exercise this part. Yes, the lxc backend cannot do this test. That's why the test is skipped when executed under lxc. > > In addition to the above, the newest test result of mmdebstrap 0.7.5-1 on > > ci.debian.net is "PASS", > > which is different from both of the above. > > From the debci logs, it looks as though in some runs the 20 minute > timeout to run make_mirror.sh is sufficient (resulting in tests being run), > and in some runs it is not (resulting in further testing being skipped). > This probably depends on how heavily-loaded the underlying machine is and > how much else it's running in parallel. Maybe. The problem with increasing this timeout is, that I then run into problems because I retry this step of package downloading up to three times. So if the timeout for each retry is too large, it will hit the global timeout for the whole test run. I have to retry multiple times because of the aforementioned transient network problems when downloading packages via apt on salsaci or debci. Thanks! cheers, josch
signature.asc
Description: signature
