Matthias Geiger <werdah...@riseup.net> writes: > - From my limited observation this only happens in experimental for rust > crates. I don't know what causes this. The autopkgtest ran fine when I > built the packages before uploading.
I believe this problem is much more widespread in testing than experimental and is holding up the migration of tons of packages. Let me illustrate an example that jochensp helped me understand on #debian-release: Consider https://ci.debian.net/packages/r/rust-async-executor/testing/amd64/49994925/ Note that this test was triggered to test rust-async-executor 1.12.0-3 (!!) Here, we see in the part "test rust-async-executor-1:@: preparing testbed" (one has to manually expand this, I didn't notice at first): 31s The following packages have unmet dependencies: 31s librust-async-lock-dev : Depends: librust-event-listener-2+default-dev 31s E: Unable to correct problems, you have held broken packages. 31s autopkgtest: WARNING: Test dependencies are unsatisfiable with using apt pinning. Retrying with using all packages from unstable So basically we have uninstallable dependencies. What is worse, however, is that the test infrastructure happily continues with installing dependencies, all from unstable, *including* the package that triggered this test: 35s Get:166 http://deb.debian.org/debian unstable/main amd64 librust-async-executor-dev all 1.13.0-2 [20.0 kB] Basically the infrastructure was asked to test one thing (i.e., rust-async-executor 1.12.0-3), but ended up testing something different (i.e., librust-async-executor-dev_1.13.0-2), and then declaring the test failed because: 48s autopkgtest [05:08:04]: test rust-async-executor-1:@: [----------------------- 49s crate directory not found: /usr/share/cargo/registry/async-executor-1.12.0 49s autopkgtest [05:08:05]: test rust-async-executor-1:@: -----------------------] I note that this particular rust package did not specify the restriction "skip-not-installable": https://sources.debian.org/src/rust-async-executor/1.12.0-3/debian/tests/control/#L12 Would we expect the package to be marked as "SKIPPED" if it had specified that restriction? What's the likely cause of this mess is that the following packages (both maintained by Jonas) had major version upgrades: - https://tracker.debian.org/pkg/rust-async-channel (1.9.0 --> 2.3.1) - https://tracker.debian.org/pkg/rust-event-listener (2.5.3 --> 5.3.1) In both cases, we would expect major API changes and thus breakage in downstream packages. In neither cases any Breaks were specified: - https://sources.debian.org/src/rust-async-channel/2.3.1-7/debian/control/ - https://sources.debian.org/src/rust-event-listener/5.3.1-6/debian/control/ In Jonas' defence, it is everything but obvious on what exactly to declare the Breaks relationships. Can we somehow improve the autopkgtest output to give better diagnostics to make this bug less confusing and easier to action on? Best, -rt