[Bug 1942394] Re: [MIR] mdevctl 1.0.0 (rust switch)

Tue Jul 12 14:40:24 UTC 2022

** Description changed:

  This template uses the new proposed format that covers Rust packages, submitted
  through https://github.com/canonical/ubuntu-mir/pull/1

  [Availability]

  The package mdevctl is already in main via LP: #1889248, but Version 1.0
  switched from the most simple (shell) to the least easy supportable (rust) =>
  https://github.com/mdevctl/mdevctl/releases/tag/v1.0.0

  The latest version of mdevctl available in Debian unstable was changed to adapt
  to the MIR rules, as proposed in
  https://code.launchpad.net/~athos-ribeiro/ubuntu/+source/mdevctl/+git/mdevctl/+merge/425351.

  The package builds and works for all supported architectures, and is available
  at
  https://launchpad.net/~athos-ribeiro/+archive/ubuntu/mdevctl-vendored-plus-lockfile/+packages.

  The original (shell based) package is available at
  https://launchpad.net/ubuntu/+source/mdevctl.

  [Rationale]

  This has 3 reasons:
  1. it is a very nice tool to handle meidiated devices in general.
-    It more and more becomes the one tool people refer to (other than fully
-    manual working through sysfs)
+    It more and more becomes the one tool people refer to (other than fully
+    manual working through sysfs)
  2. it is a Recomments for libvirt-daemon-system, which is in main.
  3. the previous (shell based) version of the package is already in main.

  It would be great to have mdevctl in Ubuntu main for kinetic, to avoid more
  gaps between Ubuntu and Debian unstable, which could potentialy hinder the
  merge processes, but there is no definitive deadline.

  [Security]

  No CVEs/security issues in this software in the past;
  No `suid` or `sgid` binaries;
  No executables in `/sbin` and `/usr/sbin`;
  The package does not install services, timers or recurring jobs;
  The package does not open privileged ports (ports < 1024); and
  The package does not contain extensions to security-sensitive software
  (filters, scanners, plugins, UI skins, etc).

  [Quality assurance - function/usage]

  The package works well right after install. It is composed of a single binary
  file, a manpage and documentation.

  [Quality assurance - maintenance]
  The package is maintained well in Debian/Ubuntu and has not too many and long
  term critical bugs open.

  Ubuntu https://bugs.launchpad.net/ubuntu/+source/mdevctl/+bug

  Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=mdevctl

  At the moment this was written, the only Ubuntu bug open was this MIR one.
  Debian has 2 open bugs, as described below:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013551
  This has been fixed in salsa through
  https://salsa.debian.org/debian/mdevctl/-/merge_requests/3 and will be
  available in the next debian release. It is also already included in the
  proposed merge in the PPA at
  https://salsa.debian.org/debian/mdevctl/-/merge_requests/3, which is what we
  intend to upload to Ubuntu once this MIR is accepted.

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003777
  This is valid, but can be fixed in Debian first and then pushed to Ubuntu. The
  next upstream version will improve the error message as per
  https://github.com/mdevctl/mdevctl/commit/1b880042683879db524c0d74b48bfdf533bda996.
  On top of that, we should ensure that /etc/mdevctl.d/ is part of this package.

  [Quality assurance - testing]
- RULE: - The package must include a non-trivial test suite
- RULE:   - it should run at package build and fail the build if broken
- TODO-A: - The package runs a test suite on build time, if it fails
- TODO-A:   it makes the build fail, link to build log TBD
- TODO-B: - The package does not run a test at build time because TBD
- 
- RULE:   - The package should, but is not required to, also contain
- RULE:     non-trivial autopkgtest(s).
- TODO-A: - The package runs an autopkgtest, and is currently passing on
- TODO-A:   this TBD list of architectures, link to test logs TBD
- TODO-B: - The package does not run an autopkgtest because TBD
- 
- RULE: - existing but failing tests that shall be handled as "ok to fail"
- RULE:   need to be explained along the test logs below
- TODO-A: - The package does have not failing autopkgtests right now
- TODO-B: - The package does have failing autopkgtests tests right now, but since
- TODO-B:   they always failed they are handled as "ignored failure", this is
- TODO-B:   ok because TBD
- 
- RULE: - If no build tests nor autopkgtests are included, and/or if the package
- RULE:   requires specific hardware to perform testing, the subscribed team
- RULE:   must provide a written test plan in a comment to the MIR bug, and
- RULE:   commit to running that test either at each upload of the package or
- RULE:   at least once each release cycle. In the comment to the MIR bug,
- RULE:   please link to the codebase of these tests (scripts or doc of manual
- RULE:   steps) and attach a full log of these test runs. This is meant to
- RULE:   assess their validity (e.g. not just superficial)
- TODO: - The package can not be tested at build or autopktest time because TBD
- TODO:   to make up for that here TBD is a test plan/automation and example
- TODO:   test TBD (logs/scripts)
- 
- RULE: - In some cases a solution that is about to be promoted consists of
- RULE:   several very small libraries and one actual application uniting them
- RULE:   to achieve something useful. This is rather common in the go/rust space.
- RULE:   In that case often these micro-libs on their own can and should only
- RULE:   provide low level unit-tests. But more complex autopkgtests make no
- RULE:   sense on that level. Therefore in those cases one might want to test on
- RULE:   the solution level.
- RULE:   - Process wise MIR-requesting teams can ask (on the bug) for this
- RULE:     special case to apply for a given case, which reduces the test
- RULE:     constraints on the micro libraries but in return increases the
- RULE:     requirements for the test of the actual app/solution.
- RULE:   - Since this might promote micro-lib packages to main with less than
- RULE:     the common level of QA any further MIRed program using them will have
- RULE:     to provide the same amount of increased testing.
- TODO: - This package is minimal and will be tested in a more wide reaching
- TODO:   solution context TBD, details about this testing are here TBD
+ 
+ The package runs a test suite on build time, if it fails it makes the
+ build fail.
+ 
+ You can verify that at https://launchpad.net/~athos-
+ ribeiro/+archive/ubuntu/mdevctl-vendored-plus-lockfile/+build/24166000
+ 
+ The package does not run an autopkgtest because the rust tooling does
+ not provide an out-of-the-box manner to run the test suite for packages
+ with vendorized code as it does for packages without vendorized code.
+ This is something we should pursue in the mid/long term.

  [Quality assurance - packaging]

  debian/watch is present and works. It levarages the support for Multiple
  Upstream Tarballs (MUT) to pull in the vendored sources. This process is
  described in debian/README.source.

  debian/control defines a correct Maintainer field.

  This package does not yield massive lintian Warnings, Errors
  A recent build log of the package is available at
  https://launchpad.net/~athos-ribeiro/+archive/ubuntu/mdevctl-vendored-plus-lockfile/+build/24120829

  A no comprehensive "lintian --pedantic" output (without --no-tag-
  display-limit) follows:

  E: mdevctl source: unpack-message-for-orig mdevctl_1.1.0.orig-vendor.tar.gz ar failed for vendor/winapi-i686-pc-windows-gnu/lib/libwinapi_mincore.a
  E: mdevctl source: unpack-message-for-orig mdevctl_1.1.0.orig-vendor.tar.gz ar failed for vendor/winapi-i686-pc-windows-gnu/lib/libwinapi_mincore_downlevel.a
  E: mdevctl source: unpack-message-for-orig mdevctl_1.1.0.orig-vendor.tar.gz ar failed for vendor/winapi-i686-pc-windows-gnu/lib/libwinapi_onecore.a
  E: mdevctl source: unpack-message-for-orig ... use --no-tag-display-limit to see all (or pipe to a file/program)
  P: mdevctl source: update-debian-copyright 2020 vs 2022 [debian/copyright:10]
  P: mdevctl source: very-long-line-length-in-source-file vendor/aho-corasick/.cargo-checksum.json line 1 is 2574 characters long (>512)
  P: mdevctl source: very-long-line-length-in-source-file vendor/ansi_term/.cargo-checksum.json line 1 is 1075 characters long (>512)
  P: mdevctl source: very-long-line-length-in-source-file vendor/anyhow/.cargo-checksum.json line 1 is 3038 characters long (>512)
  P: mdevctl source: very-long-line-length-in-source-file ... use --no-tag-display-limit to see all (or pipe to a file/program)

  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 not be installed by default. Still, it does not ask debconf
  questions.

  Packaging is more complex than avarage due to the source vendoring
  process, which differs to Debian. This should be ok because
  debian/README.source clearly describes the process.

  [UI standards]

  No end user UI
  Just a few CLI bits used by admins and parsable output used by tools.

  [Dependencies]

  No further depends or recommends dependencies that are not yet in main. Do note
  that this package includes vendored Rust code.

  [Standards compliance]

  This package correctly follows FHS and Debian Policy. Do note that it does
  include embedded copies of otehr software (vendorized rust code), which is
  discouraged by
  https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copies.
  This is done to the current state of the rust stack/support.

  [Maintenance/Owner]

  The Server Team is already subscribed to the package and maintains it in Debian
  and Ubuntu.

  The Server Team 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 Server Team 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
  package (at /usr/share/doc/mdevctl/Cargo.lock.gz - gz compressed),
  refreshing that code is outlined in debian/README.source This package uses
  vendored code, refreshing that code is outlined in debian/README.source.

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

  The package was test rebuilt in a PPA, as pointed out above.

  The latest version of mdevctl available in Debian unstable was changed to adapt
  to the MIR rules, as proposed in
  https://code.launchpad.net/~athos-ribeiro/ubuntu/+source/mdevctl/+git/mdevctl/+merge/425351.

  The package builds and works for all supported architectures, and is available
  at
  https://launchpad.net/~athos-ribeiro/+archive/ubuntu/mdevctl-vendored-plus-lockfile/+packages,
  where one can check the build logs for all supported architectures.

  [Background information]

  The Package description explains the package well:

  Mediated device management utility for Linux mdevctl is a utility for managing
  and persisting devices in the mediated device framework of the Linux kernel.
  Mediated devices are sub-devices of a parent device (ex. a vGPU) which can be
  dynamically created and potentially used by drivers like vfio-mdev for
  assignment to virtual machines.

  Upstream Name is mdevctl, and is available at
  https://github.com/mdevctl/mdevctl

  Note that, for the former MIR process, jq and libonig were included in main
  because mdevctl < 1 depends on those packages. This is no longer true for
  mdevctl >= 1 and their demotion should be evaluated.

  [Former Bug Description - NO LONGER PART OF MIR DOCS]

  This is in main via bug 1889248 already, but Version 1.0 switched from the most simple (shell) to the least easy supportable (rust)
  => https://github.com/mdevctl/mdevctl/releases/tag/v1.0.0

  This worked fine in Debian
  => https://launchpad.net/debian/+source/mdevctl/1.0.0-1

  But for Ubuntu the Server team isn't gonna own the full rust toolchain just because of this helper.
  IMHO that needs a discussion how we want to handle rust in general and then the long MIR road for all the way too many dependencies.
  I'll start the discussion internally ...

  This bug is meant to be a reference from the sync avoidance override as
  well as the component mismatches - so that everyone can re-check here
  what the current state is.

  Right now it is *intentionally* incomplete and has no full MIR template
  here.

-- 
You received this bug notification because you are a member of Ubuntu
Package Archive Administrators, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1942394

Title:
  [MIR] mdevctl 1.0.0 (rust switch)

To manage notifications about this bug go to:
https://bugs.launchpad.net/mdevctl/+bug/1942394/+subscriptions