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

Reply via email to