Package: surf Version: 2.1+git20240324-1 Severity: serious Justification: Preventing migrations in ci.d.n
Hi. I'm working on src:autopkgtest. Currently, we're having a problem with testing migration because the 2nd listed autopkgtest is failing in ci.debian.net. That's the one with the command timeout -v 10m xvfb-run debian/tests/test_http.py Here's the logs for one such run: https://ci.debian.net/packages/s/surf/testing/riscv64/59960211/ This test apparently passed in the baseline but failed when run in the migration test for autopkgtest 5.48. But, autopkgtest.deb is not used by that particular test case ("command2"). It's not even installed by the CI test runner. The migration test was triggered by the existence of the 3rd test case, which *does* depend on autopkgtest, and also fails with similar looking error messages. That 3rd test case is marked flaky so isn't a regression. That test uses some files from autopkgtest's doc directory as test cases. That seems to be the only connection to autopkgtest.ceb. Note: it is important to distinguish the two autopkgtests in this scenario: 1. src:autopkgtest whose possible testing migration triggered this test run, and its autopkgtest.deb which is installed in the flaky surf test case. This is the autopkgtest that the test appears to impugn, but which I think cannot be implicated in the blocking test failure. 2. The outer autopkgest used by ci.d.n to run all these tests. ci.d.n uses a fixed version of autopkgtest, not the version under test. Looking at tracker.d.o the failure seems to be arch-specific, only occurring on riscv64. I think, probably, the test is simply flaky. Please would you mark this 2nd test flaky too. In the meantime I will probably end up asking the release team to override it. Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
