Source: autopkgtest
Version: 5.42
Severity: serious
User: debian...@lists.debian.org
Usertags: flaky
X-Debbugs-Cc: debian...@lists.debian.org
autopkgtest has several tests that attempt to set a timeout such that the
copy of autopkgtest under test will fail, by timing out at a specified
point in the build (ideally while the test is still running sleep(1)).
Unfortunately, the riscv64 workers on ci.debian.net are sufficiently slow
that they often fail these tests "too soon", timing out before autopkgtest
has reached the part of the test that we have made artificially slow; and
as a result it fails "in the wrong way" and the overall test fails.
We could in principle address this by making the arbitrary timeouts very
long, and extending the sleep(1) to match, but that would make running
the test suite even slower, even on fast architectures. It is already
painfully slow for development (reasonably complete test coverage on my
laptop takes 3½ hours, #1020699) so I don't really want to do this.
Because this is all architecture-independent code, I think it would be
sufficient test coverage if we only run these test-cases on "fast"
architectures (x86 and maybe arm64), and skip them elsewhere.
smcv
