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.
So I think I managed to find the right combination of packages.
Basically, we need all of
- rust-async-channel
- rust-async-process
- rust-event-listener
- rust-async-broadcast