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

Athos Ribeiro 1942394 at bugs.launchpad.net
Tue Jul 12 13:52:56 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)
+ 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
+ 
+ [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

More information about the ubuntu-archive mailing list