Re: Bug#1052119: autopkgtest in experimental: sometimes just fails for rust libraries with "crate directory not found"
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?
Best,
-rt
Reply to: