Source: openmsx Version: 20.0+dfsg-1.2 Severity: important Justification: https://release.debian.org/testing/rc_policy.txt ยง6a User: [email protected] Usertags: flaky Control: affects -1 + src:libsdl2
The autopkgtest for openmsx intermittently fails on ci.debian.net, especially on slower architectures: https://ci.debian.net/packages/o/openmsx/testing/armhf/ https://ci.debian.net/packages/o/openmsx/testing/riscv64/ but also occasionally on fast architectures: https://ci.debian.net/packages/o/openmsx/testing/amd64/ (2025-08-13 02:35:57 UTC) https://ci.debian.net/packages/o/openmsx/testing/arm64/ (2025-08-13 19:09:33 UTC) Looking at the logs, 'unit' seems to be generally reliable, and it's 'run' that intermittently fails. The testing migration infrastructure assumes this is a regression in a package that was upgraded, preventing packages like libsdl2 from migrating to testing until the openmsx autopkgtest is retried. I'm reporting this as non-RC for now because it isn't *that* bad (certainly not as bad as uqm, which I have to retry on riscv64 for basically every libsdl2 upload), but it's likely to be escalated to RC if it becomes a practical problem for migrations. If this test is expected to be unreliable, please mark it with "Restrictions: flaky" so that it isn't used to gate migrations from unstable to testing: Tests: run Depends: ... Restrictions: allow-stderr, flaky Or it could be marked with the "skippable" restriction: Tests: run Depends: ... Restrictions: allow-stderr, skippable and do its own logic to classify its results into three buckets, using an exit status convention borrowed from Autotools: * success: exit 0 * skipped, expected/ignorable failure or other neutral status: exit 77 * failure: any other exit status Thanks, smcv
