[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#993079: release.debian.org: autopkgtest scheduling does not seem to understand virtual packages correctly.



Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: britney

Rust packaging makes heavy use of versioned virtual packages to allow
multiple versions of a crate to coexist if needed (though this functionality
is only occasionally actually used).

Britney now seems to understand versioned virtual packages (at least in simple
cases) for the main migration and for auto removals, but it still does not
seem to properly understand them for testing migration.

For example at the time of writing this bug report (though probablly not for
long afterwards as I intend to upload a workaround) this can be seen with
rust-datetime and rust-zoneinfo-compiled.

librust-zoneinfo-compiled-dev 0.4.8-1 in bookworm depends on
librust-datetime-0.4+default-dev (>= 0.4.7-~~) which is provided by
librust-datetime-dev 0.4.7-2

librust-zoneinfo-compiled-dev 0.5.1-2 in sid depends on
librust-datetime-0.5-dev (>= 0.5.2-~~) which is provided by
librust-datetime-dev 0.5.2-3

rust-datetime shows

> Migrates after: rust-exa, rust-iso8601, rust-zoneinfo-compiled
> Migration status for rust-datetime (0.4.7-2 to 0.5.2-3): BLOCKED: Rejected/violates migration policy/introduces a regression
> Issues preventing migration:
> autopkgtest for rust-datetime/0.5.2-3: amd64: Pass, arm64: Pass, armhf: Pass, i386: Pass, ppc64el: Pass
> autopkgtest for rust-zoneinfo-compiled/0.4.8-1: amd64: Regression ♻ (reference ♻), arm64: Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), i386: Regression ♻ (reference ♻), ppc64el: Regression ♻ (reference ♻)
> Too young, only 4 of 5 days old
> Build-Depends(-Arch): rust-datetime rust-iso8601
> Depends: rust-datetime rust-iso8601
> Implicit dependency: rust-datetime rust-exa
> Implicit dependency: rust-datetime rust-zoneinfo-compiled
> Additional info:
> Piuparts tested OK - https://piuparts.debian.org/sid/source/r/rust-datetime.html
> Not considered

While rust-zoneinfo-compiled shows

> Migration status: Blocked. Can't migrate due to a non-migratable dependency. Check status below.
> Blocked by: rust-datetime
> Migrates after: rust-exa
> Migration status for rust-zoneinfo-compiled (0.4.8-1 to 0.5.1-2): BLOCKED: Cannot migrate due to another item, which is blocked (please check which dependencies are stuck)
> Issues preventing migration:
> Build-Depends(-Arch): rust-zoneinfo-compiled rust-datetime (not considered)
> Depends: rust-zoneinfo-compiled rust-datetime (not considered)
> Invalidated by build-dependency
> Invalidated by dependency
> Implicit dependency: rust-zoneinfo-compiled rust-exa
> Additional info:
> Piuparts tested OK - https://piuparts.debian.org/sid/source/r/rust-zoneinfo-compiled.html
> autopkgtest for rust-zoneinfo-compiled/0.5.1-2: amd64: Pass, arm64: Pass, armhf: Pass, i386: Pass, ppc64el: Pass
> Required age reduced by 3 days because of autopkgtest
> 5 days old (needed 2 days)
> Not considered

We see that when it comes to excuses britney understands that these packages
need to go in togehter, rust-datetime is shown as having an implicit dependency
on rust-zoneinfo-compiled and rust-zoneinfo-compiled is shown as having
a dependency and build-dependency on rust-datetime.

However when it comes to the autopkgtest britney is refusing to migrate
rust-datetime based on an autopkgtest of the old rust-datetime. When
we look at the log we see the regular dependency installation fails

> autopkgtest: WARNING: package librust-zoneinfo-compiled-dev is not installed though it should be
> autopkgtest: WARNING: Test dependencies are unsatisfiable with using apt pinning. Retrying with using all packages from unstable

It then goes into the fallback dependency installation, this succeeds but it
installs the version of librust-zoneinfo-compiled-dev from sid. Autopkgtest
then tries to run the tests from testings rust-zoneinfo-compiled against
the librust-zoneinfo-compiled-dev from sid which fails with a crate directory
not found error.

I belive this has been worked around in newer versions of debcargo by marking
the tests as skip if uninstallable which prevents autopkgtest from heading
down the fallback dependency solving rabbit hole, but it still seems less than
ideal for britney to be behaving like this and we still have packages created
with older versions of debcargo in the archive.

-- System Information:
Debian Release: 10.5
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldoldstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 4.19.0-10-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Reply to: