Dear maintainers,

I ran into this issue for the second time now. When I uploaded the gtk-rs
crates to experimental the CI passes for most crates. But some just fail with
"crate directory not found" :

====

208s Removing autopkgtest-satdep (0) ...
208s autopkgtest [19:41:32]: test librust-rustix-dev:: /usr/share/cargo/bin/cargo-auto-test rustix 0.38.9 --all-targets --no-default-features
208s autopkgtest [19:41:32]: test librust-rustix-dev:: [-----------------------
208s crate directory not found: /usr/share/cargo/registry/rustix-0.38.9
208s autopkgtest [19:41:32]: test librust-rustix-dev:: -----------------------]
208s autopkgtest [19:41:32]: test librust-rustix-dev::  - - - - - - - - - - results - - - - - - - - - -
208s librust-rustix-dev:  FLAKY non-zero exit status 1
208s autopkgtest [19:41:32]: @@@@@@@@@@@@@@@@@@@@ summary
208s rust-rustix:@        FLAKY non-zero exit status 1
208s librust-rustix-dev:all-apis FLAKY non-zero exit status 1
208s librust-rustix-dev:cc FLAKY non-zero exit status 1
208s librust-rustix-dev:compiler_builtins FLAKY non-zero exit status 1
208s librust-rustix-dev:core FLAKY non-zero exit status 1
208s librust-rustix-dev:default FAIL non-zero exit status 1

====

====
111s autopkgtest [09:47:48]: test librust-pango-dev:: /usr/share/cargo/bin/cargo-auto-test pango 0.18.0 --all-targets --no-default-features
111s autopkgtest [09:47:48]: test librust-pango-dev:: [-----------------------
111s crate directory not found: /usr/share/cargo/registry/pango-0.18.0
111s autopkgtest [09:47:48]: test librust-pango-dev:: -----------------------]
111s autopkgtest [09:47:48]: test librust-pango-dev::  - - - - - - - - - - results - - - - - - - - - -
111s librust-pango-dev:   FAIL non-zero exit status 1

====

- 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.

best,

Matthias


- -- System Information:
Debian Release: 12.1
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.4.12-surface (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CRAP
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages autopkgtest depends on:
ii  apt-utils       2.6.1
ii  libdpkg-perl    1.21.22
ii  procps          2:4.0.2-3
ii  python3         3.11.4-1
ii  python3-debian  0.1.49

Versions of packages autopkgtest recommends:
ii  autodep8  0.28
ii  fakeroot  1.31-1.2

Versions of packages autopkgtest suggests:
pn  docker.io            <none>
pn  fakemachine          <none>
pn  lxc                  <none>
pn  lxd                  <none>
ii  ovmf                 2022.11-6
pn  ovmf-ia32            <none>
pn  podman               <none>
ii  python3-distro-info  1.5
ii  qemu-efi-aarch64     2022.11-6
ii  qemu-efi-arm         2022.11-6
pn  qemu-system          <none>
ii  qemu-utils           1:7.2+dfsg-7+deb12u1
ii  schroot              1.6.13-3+b2
ii  util-linux           2.38.1-5+b1
ii  vmdb2                0.27+really.0.26-1
pn  zerofree             <none>

- -- no debconf information
-----BEGIN PGP SIGNATURE-----

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmUHGVcVHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1plkQAJP5UBtfVDut8goSUToOd7fP7yP6
pJ62nOzrpYaQG0RkfZ5eHg7GQrR7xtaeM3ASZCLKBH67Z9x0CxnRDP8rmvgyqkhq
udyi8TCyblg37aZZvXG4c8MmiKioaXvMVar3HMpzLpgC323l74O5i+D+oAiZVGvO
7zWntNJAxKRupKOuxHUxKiHMNchxXSghEQlusCbNOazGm/I/EOD1WKFsh2QsC8bX
RKcifAGtuZeUcdZTaEpK5wA2VB/lb5kq9vQQgnIWpjy3Y2uDCHWOow+kL7xVaNex
W5+Nu+MSNLM9heqRCVprf/YaeUVAUF4IoKm8p8PSDFusNCz4U4sexUxd92luSg11
X9dBm1LNS5NcQJcCaQq/nJmIS24x+pvqGlsTHUQ3VolMXycqqfyiWWd0FFKnv5a7
d8a6l9oK8in8cV3qzN9upAVBIX81BJm1srQgJfjRDjm4uoNebQSktqPyPBamoTQB
Uw4g9yg4xQcA/Tayg6XGR6741YbnNf7ecaJEtgYp76U4+owilyariQa9Jld0qzOI
USM2D/iWiF6Ygknk4xqcd8tWJLZvY5UuCulPx6ycHVTAk9ZddxmHbeKs5VKj1RhV
ApZVjnDLrFGjK5Ed4RJ5QgwgbCmwiVUwV/VihnODeMiT/y8Xgy1vA/WjJoowHbAD
uSCj6Mrw+HiUAW5w
=EqvW
-----END PGP SIGNATURE-----

Matthias Geiger <werdahias@riseup.net> writes:
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

My bad.

I think we probably have to treat this as a bug in "larger" infrastructure
(debci? britney?) that is blocked by an autopkgtest feature request, rather
than an autopkgtest bug in itself.

It's clearly wrong that we were aiming to test 1.12.0-3 but
ended up running its tests against 1.13.0-2; but at the same time,
autopkgtest doesn't know that it's unacceptable to install binaries
from rust-async-executor at a version other than 1.12.0-3 unless someone
says so.

To avoid this, I think it would have to grow a new command-line
option to tell it something like: "pin all binary packages from
src:rust-async-executor to source version 1.12.0-3, at a high priority".

A complicating factor is that the version number of binary packages is
not always trivially derivable from the version number of the source.
Consider binNMUs, but also packages like libreoffice where source package
libreoffice_4:24.2.5-1 builds binary package
fonts-opensymbol_4:102.12+LibO24.2.5-1 (note the version prefix).

    smcv

Quoting Reinhard Tartler (2024-08-05 14:52:28)

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

294s error: no matching package named `async-std` found
294s location searched: registry `crates-io`
294s required by package `async-mutex v1.4.0 (/usr/share/cargo/registry/async-mutex-1.4.0)`

Message produced by cargo. Somehow confusing, yes.

async-mutex dev-depends on async-std, so it's in the Depends of d/tests/control:

Depends: dh-cargo (>= 18), librust-async-std-1+default-dev (>= 1.12-~~), [...]

However interesting is that autopkgtest didn't install it, seen in the debci
log.

Quoting Reinhard Tartler (2024-08-05 15:05:42)

No harm done - I even think that it is proper (british?) english:

I read "everything but obvious" as meaning "not obvious even if maybe
lots of other things".


 - Jonas

Hi,

I thought we were doing that *until* the fallback lifts all pinning.
Rest assured that in the past I worked [1, 2] to prevent the fallback,
because I consider it wrong, but it helped in quite some cases where the
outcome is acceptable in the end. The price was that if it still fails,
it more confusing to figure out.

I have good hopes that the version 3 solver of apt is going to improve
things, I'm not sure if it would have helped in this case. But maybe it
will enable us to disable the fallback again.

Paul

[1] https://salsa.debian.org/ci-team/autopkgtest/-/commit/d83497c0
[2] https://lists.debian.org/deity/2018/06/msg00034.html

I think solver3 could allow us to stop using the fallback, at least when
the apt version on the testbed is new enough. When testing on stable
releases the fallback is likely not that useful, as the packages to test
are likely to be minor updates not requiring to relax pinning in most
cases, so my hope is that we'll be able to drop it.

This said, I think we should still make autopkgtest do some stricter
pinning on the package under test, as Simon mentioned, but I hope that
is doable without growing a new command line option.

Hi

What do you mean here? That during the fallback, we still ensure that at
least the package under test doesn't switch versions?

Paul

never relaxed, even during the fallback run.

Hello,

Bug #1052119 in autopkgtest reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/ci-team/autopkgtest/-/commit/d0d0610e573567d3977ba6f71b5021c7c8e10713
------------------------------------------------------------------------
Turn test deps from package under test into versioned dependencies

Closes: #1052119
------------------------------------------------------------------------

(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1052119

We believe that the bug you reported is fixed in the latest version of
autopkgtest, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1052119@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Simon McVittie <smcv@debian.org> (supplier of updated autopkgtest package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Wed, 12 Feb 2025 14:47:41 +0000
Source: autopkgtest
Architecture: source
Version: 5.44
Distribution: unstable
Urgency: medium
Maintainer: Debian CI team <team+ci@tracker.debian.org>
Changed-By: Simon McVittie <smcv@debian.org>
Closes: 1052119 1078205 1093161 1093275 1093546 1094634
Changes:
 autopkgtest (5.44) unstable; urgency=medium
 .
   [ Simon McVittie ]
   * tests: Normally only test timeouts on known-fast architectures.
     We cannot make these test-cases reliable on slower machines like riscv64
     without making the test suite take a long time even on faster machines.
     (Closes: #1093275)
   * virt-podman: Don't crash if the selected image has no labels
     (Closes: #1093546)
   * virt-podman(1): Mention how to generate images locally
   * build-podman(1): Consistently use podman in examples
   * virt-podman(1): Document that full systemd functionality needs
     CAP_SYS_ADMIN, how to obtain it, and the security considerations that
     mean it is not the default (Closes: #1078205)
   * d/control: Remove obsolete alternative dependency on pep8
     (Closes: #1093161)
   * d/README.source: Mention some apt features that we cannot use yet
   * build-docker(1): Clarify the relationship between --tarball and --image.
     In particular clarify the circumstances under which a base image
     for use inside the container environment will be downloaded from a
     third-party container registry.
 .
   [ Paride Legovini ]
   * Turn test dependencies from package under test into strictly versioned
     dependencies (Closes: #1052119)
   * d/t/schroot: use eatmydata in the test schroot to speed up testing
   * autopkgtest(1): clarify usage of virt servers, suggest qemu
   * virt-schroot(1): add warning regarding lack of isolation
 .
   [ Ural Tunaboyu ]
   * buildvm-ubuntu-cloud: Don't exclude documentation
 .
   [ Jochen Sprickerhof ]
   * Add test dependency on apt to make it reproducible
   * virt-unshare: Keep apt lists when bootstrapping
 .
   [ Florent 'Skia' Jacquet ]
   * buildvm-ubuntu-cloud: Use server image for riscv64 testbeds, since
     no minimal image is available
 .
   [ Ian Jackson ]
   * virt-*: Exit with an error if stdin is in non-blocking mode
   * virt-*: Exit on EOF (Closes: #1094634)
   * virt-*: Warn on (invalid) leading whitespace in the
     virtualization protocol
   * virt-*: Reject empty commands
Checksums-Sha1:
 4ad713e8c10d05df83019d57678eda2fa730c593 2595 autopkgtest_5.44.dsc
 4c7edd810aa888547c027fb8145a20550f6a4595 247632 autopkgtest_5.44.tar.xz
 564b8f975b0ae1d79a25c099f762079ce7b4cf5d 6453 autopkgtest_5.44_source.buildinfo
Checksums-Sha256:
 6c1eb27c6b5eafb5cd69c36cecb66798359673358b23dad68ca5defb5e9577c2 2595 autopkgtest_5.44.dsc
 5d66cad7e0e69dd7156f3560a7e24b68c298e03bc2caa9ef6708f5ef76f26ead 247632 autopkgtest_5.44.tar.xz
 14106cba334355b659dd2db26847d59164ed9bd53530b77b0d50d070e72d5878 6453 autopkgtest_5.44_source.buildinfo
Files:
 6cb9d94921bfcb83304111af7325f049 2595 devel optional autopkgtest_5.44.dsc
 c3e76328780d95af6abeddb071306ae1 247632 devel optional autopkgtest_5.44.tar.xz
 7e2daad6ffdd366edd1fa8a993b225ef 6453 devel optional autopkgtest_5.44_source.buildinfo
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEegc60a5pT6Jb/2LlI1wJnT6zMHYFAmes9p0ACgkQI1wJnT6z
MHbmvhAAvGNIWK2YdbxivV/vyHxHnydYByjCnVgPyU+F3kQlgXGVW4jHqCtrRXn9
Co8zATn7BqFBkmAhAMSPPGEb5s+Y2l0E4LfWOMhPdEumCj0Wixf802NtJ03iWCr0
YGTWmm87Q45U5wpLkSbV2bpYawdbb20NHzRW8yZBFn8TthI2wSiy5OaodulQZx2a
ZNnNrYekjAjsaDm01vIfwE3zparAbj2yOpZAnbOV0XIQB3a/vU9GZVAjh+o2o4E2
FQT7SUltLXNzf3K/7jXpLNP6Vr4PYxW/LZ7UNVswyf1vc6JSbUE7BBvAF4TYGAp4
U0bS708KZWZtvIOx8NemxMnPa2CeDRRS4fhkSHWLMG30ZszS+9KvxF5wL/mrwtLn
5YR9ePMl+fOpSRx2H6Gk5llSY+dXlqkTvEPpszcb5j+EcOQ+G69RXx6qICb1ANl2
yNsEJn6YVwWEcDvP5CKHH4ynvZ6bF6e9TerZyKmYUaroN6I5G0hrhmo3q0BCy+92
DMh8X3gpU5tWj/EAcf08AzHjvJPgfOXP/xbI453oSQ0sF9lOCXbl7gG0q+82iNxV
Qvq57vR2wO0Qv6+JBR5o6Bptnq5R71J9nFVh8I9A2ntrLxuROex4ugLMJVtRzVIW
GETepvg+ckKH3p5CVfPB4gvaazD2Ijc86xS2i1iM2hrVMtU2IG0=
=om/g
-----END PGP SIGNATURE-----

The fix got reverted in 5.45 as it was preventing some transitions to
happen as usual. We'll have to rethink how we approach this problem, and
likely also work on the britney side.