[Bug 2100266] Autopkgtest regression report (rustc-1.91/1.91.1+dfsg~24.04-0ubuntu0.24.04.3)

Ubuntu SRU Bot 2100266 at bugs.launchpad.net
Wed May 13 12:16:01 UTC 2026 

All autopkgtests for the newly accepted rustc-1.91 (1.91.1+dfsg~24.04-0ubuntu0.24.04.3) for noble have finished running.
The following regressions have been reported in tests triggered by the package:

rustc-1.91/1.91.1+dfsg~24.04-0ubuntu0.24.04.3 (arm64)


Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://ubuntu-archive-team.ubuntu.com/proposed-
migration/noble/update_excuses.html#rustc-1.91

[1] https://documentation.ubuntu.com/project/SRU/howto/autopkgtest-
failure/

Thank you!

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to rustc-1.76 in Ubuntu.
Matching subscriptions: rustc-1.93
https://bugs.launchpad.net/bugs/2100266

Title:
  Versioned cargo wrapper script points to default cargo

Status in rustc-1.76 package in Ubuntu:
  Invalid
Status in rustc-1.77 package in Ubuntu:
  Invalid
Status in rustc-1.78 package in Ubuntu:
  Invalid
Status in rustc-1.79 package in Ubuntu:
  Invalid
Status in rustc-1.80 package in Ubuntu:
  Invalid
Status in rustc-1.81 package in Ubuntu:
  In Progress
Status in rustc-1.82 package in Ubuntu:
  In Progress
Status in rustc-1.83 package in Ubuntu:
  In Progress
Status in rustc-1.84 package in Ubuntu:
  In Progress
Status in rustc-1.85 package in Ubuntu:
  In Progress
Status in rustc-1.88 package in Ubuntu:
  In Progress
Status in rustc-1.91 package in Ubuntu:
  Fix Released
Status in rustc-1.92 package in Ubuntu:
  New
Status in rustc-1.93 package in Ubuntu:
  Fix Released
Status in rustc-1.76 source package in Focal:
  New
Status in rustc-1.77 source package in Focal:
  New
Status in rustc-1.78 source package in Focal:
  New
Status in rustc-1.79 source package in Focal:
  New
Status in rustc-1.80 source package in Focal:
  New
Status in rustc-1.76 source package in Jammy:
  New
Status in rustc-1.77 source package in Jammy:
  New
Status in rustc-1.78 source package in Jammy:
  New
Status in rustc-1.79 source package in Jammy:
  New
Status in rustc-1.80 source package in Jammy:
  New
Status in rustc-1.76 source package in Noble:
  New
Status in rustc-1.77 source package in Noble:
  New
Status in rustc-1.78 source package in Noble:
  New
Status in rustc-1.79 source package in Noble:
  New
Status in rustc-1.80 source package in Noble:
  New
Status in rustc-1.81 source package in Noble:
  New
Status in rustc-1.82 source package in Noble:
  New
Status in rustc-1.83 source package in Noble:
  New
Status in rustc-1.84 source package in Noble:
  New
Status in rustc-1.85 source package in Noble:
  In Progress
Status in rustc-1.91 source package in Noble:
  Fix Committed
Status in rustc-1.80 source package in Oracular:
  Won't Fix
Status in rustc-1.81 source package in Oracular:
  Won't Fix
Status in rustc-1.81 source package in Plucky:
  Won't Fix
Status in rustc-1.82 source package in Plucky:
  Won't Fix
Status in rustc-1.83 source package in Plucky:
  Won't Fix
Status in rustc-1.84 source package in Plucky:
  Won't Fix
Status in rustc-1.85 source package in Questing:
  In Progress
Status in rustc-1.88 source package in Questing:
  New
Status in rustc-1.88 source package in Resolute:
  In Progress

Bug description:
  [ Impact ]

   * If you use the Cargo wrapper script provided by a versioned
     cargo package, e.g. /usr/lib/rust-1.85/share/cargo/bin/cargo,
     it will invoke /usr/bin/cargo rather than
     /usr/lib/rust-1.85/bin/cargo.

   * This means that users expecting a particular Cargo version are
     actually invoking the rust-defaults Cargo version behind the
     scenes.

   * Additionally, if the rust-defaults Cargo version isn't
     installed, the versioned Cargo wrapper script doesn't work at
     all (because it's trying to invoke the nonexistent default).

   * As stated in the comments of this bug report, this is blocking
     the update of authd's Rust dependencies.

   * This upload fixes the bug by making the Cargo wrapper script
     invoke the versioned Cargo instead.

  [ Test Plan ]

   * To ensure the fix is comprehensive, all documented usages of the
     wrapper script must be performed without installing any
     rust-defaults packages. That way, if the system attempts to use
     any default cargo functionality, we will get a hard "missing file"
     error rather than a silent usage of default cargo.

   * Install the versioned cargo and a basic Rust library dependency:
     - # apt install -y cargo-1.91 librust-anyhow-dev dpkg-dev

   * Create a new Rust project:
     - $ cargo-1.91 new hello
     - $ cd hello

   * Add the library dependency to the project:
     - $ echo 'anyhow = "1"' >> Cargo.toml

   * Edit ./src/main.rs to use anyhow:
     - $ echo 'fn main() -> anyhow::Result<()> { Ok(()) }' >src/main.rs

   * Download the makefile which runs all the different wrapper script
     functions:
     - $ wget 'https://drive.google.com/uc?export=download&id=1qv1n2WwCN26O1YLHF60pRR71xzWH9Inm' -O Makefile

   * Run the Makefile, setting the expected Rust version:
     - $ RUST_VERSION='1.91' make test

   * The script should fail when it tries to invoke /usr/bin/cargo.

   * To test the fixed version, enable proposed and install the fixed
     cargo-1.91:
     - # apt update
     - # apt install -y cargo-1.91

   * Running the Makefile once more should succeed:
     - $ RUST_VERSION='1.91' make test

  [ Where problems could occur ]

   * This upload changes the toolchain version which is invoked by the
     versioned Cargo wrapper. As a result, applying this SRU means that
     packages will be built with a different Rust version. The regression
     risk depends on the difference between the default Rust version and
     the patched Rust version for the given series. For example, on
     Noble, patching rustc-1.91 will mean that when running cargo-1.91,
     Rust 1.91 is used instead of the default of 1.75 on Noble. This
     means that anything that is built by the versioned rustc/cargo has
     a risk of FTBFS if they need to be rebuilt for whatever reason.

   * Since Rust upstream is committed to backwards compatibility, risk
     of FTBFS from upstream changes is minimal.

   * No Rust packages which build using the default non-versioned
     Rust (the overwhelming majority) will be affected at all.

   * Most FTBFS risk stems from packaging changes from the default
     version to the backported version. For instance, newer cargo
     packages add a key to packages' Cargo.tomls during preconfiguration.
     If a package already includes that key in its Cargo.toml, that
     package will FTBFS.

   * Luckily, in practice, regression risk is very low because very few
     packages opt-in to using the backported versioned toolchains over the
     default version. For instance, not a single package in the archive is
     currently built by rustc-1.91 on Noble:
     - $ ./checkrdepends --include-provides --no-ports --suite noble \
           --archive-base 'http://archive.ubuntu.com/ubuntu' rustc
         [empty output]

   * To further verify that FTBFSs will be rare, I rebuilt some packages in
     a PPA[1]. They all built without issue except for lace, which failed
     due to the aforementioned duplicate Cargo.toml key issue. (I have
     submitted a fix for the issue[2].)

  [ Other Info ]

   * The uploads fix the bug by replacing the old, non-versioned cargo path
     in debian/bin/cargo.in with the CARGO_PATH constant. CARGO_PATH
     contains the substring @RUST_VERSION@, which gets overwritten with the
     actual cargo version during the preconfiguration step of the package
     build.

   * There is an autopkgtest in which the Rust toolchain tries to bootstrap
     itself. On backports specifically, this process includes the
     compilation of the vendored LLVM, dramatically increasing the time and
     resources required and making the autopkgtest flaky. The current Rust
     team policy is to disable this selfbuild autopkgtest on backports[3],
     so backport uploads fixing this bug will disable this autopkgtest too.

  [1]: https://launchpad.net/~maxgmr/+archive/ubuntu/lp2100266-2/+packages
  [2]: https://github.com/canonical/lace/pull/41
  [3]: https://documentation.ubuntu.com/project/maintainers/niche-package-maintenance/rustc/backport-rust/#disabling-autopkgtest-self-build-test

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rustc-1.76/+bug/2100266/+subscriptions

More information about the foundations-bugs mailing list