[Bug 2111815] Re: [MIR] rust-coreutils

Thu Sep 4 06:14:16 UTC 2025

Great, thanks Hlib!

Security Ack is in.

MIR ack was with conditions

Required TODOs:

1. The package has not documented how to refresh vendored code. Please
document it.

It was not mentioned, but I see it in debian/README.Debian in the most recent version.
It isn't perfect, but it explaines how to update the whole tree to a new rust coreutils.
Furthermore d/rules has a vendor-tarball target which mostly matches https://canonical-ubuntu-project.readthedocs-hosted.com/MIR/mir-rust/

2. The package does not have autopkgtest.

This was discussed in comment #4.
Due to the way when rust builds and not linking late the build test is covering more than usual.

It was mentioned that a good compromise might be to have gnu coreutils Test-Depends on rust-coreutils - I assume to run the gnu tests of behavior against the partial rust-coreutils system.
But I've not seen that in the changelog of src:coreutils
I'd ask you to track and add that, but would not consider it blocking for 25.10 (but early 26.04 please)

3. Please address the translation issue.

Explained in comment #4 , I think there is nothing more we can do there in a hurry.
It is and will be transalated, but not in a compatible format.

4a. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1097827

False positive

4b. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1107270

Fixed in https://bugs.launchpad.net/ubuntu/+source/rust-
coreutils/+bug/2112445 aling with various other similar "oh we need to
fix this remaining mismatch of behavior"

5. There quite a few open Ubuntu bugs, please address them
   https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bugs

Until addressed mitigated by a mix and match with GNU coreutils as
explained in comment #5

6. Review upstream issues and assess which of them are likely to
   cause problems.
and

We can't consider it done, but uploads like
https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bug/2112445 do
exactly that. As long as you are willing and comitted to continue on
that this is no more gating. Getting it into 25.10 is our chance to know
what else is nice to have or very important.

I think the recommended todo will continue to be true for a while which said "Address as many as possible of the upstream bugs triaged in (6)."
Just the same applies for some topics out of the discussions by the security review.

I think thereby the remaining aspects of #2,#5,#6,#7 are all on the "recommended level".
Those are all about "more testing" (2) and Fixing more bugs (5,6,7) to make it replace coreutils with less friction.
I highly encourage you follow up on these, but as mentioned getting it into the questing release will open up more feedback and allow us to fill and prioritize the queues for #5 #6 #7 better.

This is hereby ready for promotion (with the big ask to continue on this more intense than usual, allocate time for it I'm sure it will be needed).
It is in component mismatches already - setting state accordingly.
I'll leave the actual promotion move to Seb in case there is more to coordinate.

** Changed in: rust-coreutils (Ubuntu)
       Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to rust-coreutils in Ubuntu.
https://bugs.launchpad.net/bugs/2111815

Title:
  [MIR] rust-coreutils

Status in rust-coreutils package in Ubuntu:
  Fix Committed

Bug description:
  [Availability]
  The package rust-coreutils is already in Ubuntu universe.
  The package rust-coreutils build for the architectures it is designed to work on.
  It currently builds and works for architectures: (all of them)
  Link to package https://launchpad.net/ubuntu/+source/rust-coreutils

  [Rationale]
  - The package rust-coreutils is required in Ubuntu main for 
    strengthening product security, resilience, and safety by adopting
    memory-safe replacements for core functionalities as outlined in
    Jon Seager's post:

    https://discourse.ubuntu.com/t/carefully-but-purposefully-oxidising-
  ubuntu/56995

  - The package rust-coreutils will generally be useful for a large part of
    our user base as it will become the new default coreutils

  [Security]
  - No CVEs/security issues in this software in the past
  - no `suid` or `sgid` binaries
  - no executables in `/sbin` and `/usr/sbin`
    [chroot used to be in sbin]

  - Package does not install services, timers or recurring jobs
  - Security has been kept in mind and common isolation/risk-mitigation
    patterns are in place utilizing the following features:
    This is using a memory-safe language, eliminating most memory safety
    issue.
  - Package does not expose any external endpoints
  - Packages does not contain extensions to security-sensitive software
    (filters, scanners, plugins, UI skins, ...)

  [Quality assurance - function/usage]
  - The package works well right after install

    Particularly, when installing coreutils-from-uutils, which is to be the
    default. On its own, this provides a single coreutils binary.

  [Quality assurance - maintenance]
  - The package is maintained well in Debian/Ubuntu/Upstream and does
    not have too many, long-term & critical, open bugs
    - Ubuntu https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bug
    - Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=rust-coreutils
    - Upstream's bug tracker, e.g., GitHub Issues
  - The package has important open bugs, listing them:
    - Lots of coreutils still have some breakage which prevents the default
      switch, I won't list them individually.
  - The package does not deal with exotic hardware we cannot support

  [Quality assurance - testing]
  - The package runs a test suite on build time, if it fails
    it makes the build fail, link to build log 
            https://launchpadlibrarian.net/797298944/buildlog_ubuntu-questing-amd64.rust-coreutils_0.0.30-2ubuntu2_BUILDING.txt.gz

  - The package does not run an autopkgtest because there are no additional
    tests. It does trigger a whole bunch of packages; and of course the GNU
    coreutils test suite gets triggerd by coreutils-from with coreutils-from-uutils
    as the default coreutils provider.

  [Quality assurance - packaging]
  - debian/watch is not present, instead it has "cargo magic"
  - debian/control defines a correct Maintainer field

  - Please link to a recent build log of the package https://launchpadlibrarian.net/797298944/buildlog_ubuntu-questing-amd64.rust-coreutils_0.0.30-2ubuntu2_BUILDING.txt.gz
  - Please attach the full output you have got from
    `lintian --pedantic` as an extra post to this bug:

    it's just:

      W: rust-coreutils: bad-whatis-entry [usr/share/man/man1/rust-coreutils.1.gz]
      W: rust-coreutils: debian-changelog-line-too-long [usr/share/doc/rust-coreutils/changelog.Debian.gz:9]
      W: rust-coreutils: no-manual-page [usr/bin/coreutils]

    aka rust-coreutils is the manpage for coreutils and it's a bit
  weird.

  - Lintian overrides are not present

  - This package does not rely on obsolete or about to be demoted packages.
  - This package has no python2 or GTK2 dependencies

  - The package will be installed by default, but does not ask debconf
    questions
  - Packaging and build is easy, link to debian/rules 
    https://git.launchpad.net/ubuntu/+source/rust-coreutils/tree/debian/rules?h=ubuntu/questing-devel
    The vendoring is the most part :D

  [UI standards]
  The situation is a bit more complex than the template allows for; coreutils
  are *somewhat* user interfacing - for terminal users.

  Translation support is being added, but sadly it uses "Fluent" which is
  not compatible with Launchpad's translation service, which is going to need
  some more work to see how we can translate from ftl to pot, produce po and
  then translate back to ftl such that we can ship translations in language
  packs.

  [Dependencies]
  - No further depends or recommends dependencies that are not yet in main
    [Rust dependencies are vendored per Rust MIR policy]

  [Standards compliance]
  - This package correctly follows FHS and Debian Policy

  [Maintenance/Owner]
  - The owning team will be foundations-bugs and I have their acknowledgement for
    that commitment
  - I Suggest the owning team to be debcrafters-packages starting 26.10

  - The team foundations is aware of the implications by a static build and
    commits to test no-change-rebuilds and to fix any issues found for the
    lifetime of the release (including ESM)

  - The team foundations is aware of the implications of vendored code and (as
    alerted by the security team) commits to provide updates and backports
    to the security team for any affected vendored code for the lifetime
    of the release (including ESM).

  - This package uses vendored rust code tracked in Cargo.lock as shipped,
    in the *source* package (it produces a single binary, no crates), refreshing
    that code is outlined in debian/README.source
    [FIXME: I don't have a README.source]

  - This package is rust based and vendors all non language-runtime
    dependencies

  - The package has been built within the last 3 months in the archive
  - Build link on launchpad: https://launchpad.net/ubuntu/+source/rust-coreutils/0.0.30-2ubuntu2

  [Background information]
  The Package description explains the package well
  Upstream Name is coreutils (same as GNU one)
  Link to upstream project https://github.com/uutils/coreutils

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bug/2111815/+subscriptions