I now have a script that can take a snapshot of (hopefully) all the things I need to create a test case for the britney2 test suite. Can you warn me again when a similar case happens?
I can try.
I have some hope that it got improved by some of my recent changes.
Just how recent were these changes? If they were very recent I may not have had enough time to notice them. The situation over the last year or two seems to be that the autopkgtest scheduler has some understanding of versioned provides, but only *after* all builds are complete, if builds are missing the changes in versioned provides are ignored. This often results in britney scheduling a "stupid" autopkgtest initially, then following up with a "sensible" one when it retrys after slow architectures catch up. There are also problems in more complex scenarios. Based on my obvervarions of britney's behaviour and the assumption that the first package in the "trigger" list is the one that actually triggered the test. the simplest scenario which I'm pretty sure fails (or at least failed as-of a few weeks ago) is where you have packages like. * A depends on B through a versioned provides * A depends on C through a versioned provides * B depends on C through a versioned provides C removes a versioned provides and adds a new one (usually as a result of a rust semver bump). A and B are adapted to the new version of C but A's dependency on B remains unchanged. Once all the builds are in A and C will trigger autopkgtests of A with the new versions of A and C but not the new version of B. This will likely trigger the fallback depsolver in debci but will generally pass. B on the other hand will trigger the autopkgtest of A with only the new version of B. This will trigger the fallback depsolver and cause a package/test mismatch. The package/test mismatch in turn will often lead to a "crate directory not fonud" error. A more subtle variant.of this comes if A bumps it's dependecy on B as part of the update. In this case the autopkgtest of A triggered by A correctly includes all three packages and passes. but the autopkgtests of A triggered by B and C are still "wrong". If no follow up updates are needed this doesn't matter, the autopkgtest triggered by A overrides but if follow-up uploads are needed this can become a problem.
