Hi On 05-08-2024 14:03, Reinhard Tartler wrote:
I need some help to understand how skipped tests lead to delaying the package migration to testing. My naive understanding is that this flag would rather allow issues to go through to testing?
What skipping means isn't up to autopkgtest to determine, but up to the consumers of the test results. For migration to testing, that britney2 that's owned by the Release Team. We, the Release Team, want britney2 to prevent migration: a) the autopkgtest of a package doesn't fail in testing, but the test fails with $something from unstable (regression). That $something should be blocked. b) the test is new to testing, but it fails (weird definition of regression).
My question is basically: what needs to be done so that https://tracker.debian.org/pkg/rust-event-listener <https://tracker.debian.org/pkg/rust-event-listener> can actually migrate testing?
Good question. It seems that britney2 did schedule some combination "correctly", but not all. That is probably due to the order in which packages were uploaded. I.e. if a package needs some other package, britney2 will schedule the test for both triggers and if it passes, it counts for both. However, if the dependent-on package is later updated again, britney2 doesn't see the relation and will not schedule the combination. If the test than fails, the package is blocked. If there would be a versioned Breaks (not sure if the package is really broken, or merely the test, then a Breaks is a bit overkill), than britney2 would again trigger the combination.
Does this help to tell the right answer? If this is only a test issue, and not really a versioned Breaks missing, I'm willing to manually trigger the right test combination. But then people need to hold off with uploading, otherwise the results might come too late.
Paul
OpenPGP_signature.asc
Description: OpenPGP digital signature