Quoting Reinhard Tartler (2024-08-05 14:52:28) > Matthias Geiger <werdahias@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? It seems that at https://ci.debian.net/packages/r/rust-async-mutex/testing/riscv64/49981801/ something makes the tests depend on a bogus package "async-std" (notice the lack of leading "librust-" and trailing "-dev".) Or am I misreading those error messages and they are mean "crate" when they say "package"? Perhaps that's a clue to what concrete goes wrong? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private
Attachment:
signature.asc
Description: signature