** Description changed: [Availability] - This package rust-hwlib is published to the PPA: https://launchpad.net/~nhutsko/+archive/ubuntu/hwcert, it'is NOT part of the universe. We have an exception to publish it directly to main, since this library will help the development of solutions that affect Canonical customers directly. Please check with ~paelzer for more information. - The package rust-hwlib build for the architectures it is designed to work on. - It currently builds and works for architectures: riscv64, arm64, armhf, amd64 - Link to package: https://launchpad.net/~nhutsko/+archive/ubuntu/hwcert/+packages [Rationale] - This package rust-hwlib is part of the [hardware-api](https://github.com/canonical/hardware-api) project, owned and developed by Canonical Certification team. It will be used by Ubuntu pro-client to retrieve information about the machine and check its certification status. - The package rust-hwlib will generally be useful for a large number of users who use Ubuntu and want see what components have been tested and certified and for which Ubuntu releases - There is no other/better way to solve this that is already in main or should go universe->main instead of this. - The package rust-hwlib is required in Ubuntu main no later than April 2025 due to 25.04 release date, so users and Canonical customer can install it for the latest Ubuntu release [Security] - No CVEs/security issues in this software in the past - no `suid` or `sgid` binaries - no executables in `/sbin` and `/usr/sbin` - Package does not install services, timers or recurring jobs - Packages does not open privileged ports (ports < 1024). - Package does not expose any external endpoints - Packages does not contain extensions to security-sensitive software [Quality assurance - function/usage] - The package works well right after install [Quality assurance - maintenance] - The package is maintained well in Upstream and does not have too many, long-term & critical, open bugs - Upstream's bug tracker: https://github.com/canonical/hardware-api/issues - 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://launchpad.net/~nhutsko/+archive/ubuntu/hwcert/+build/28642997/+files/buildlog_ubuntu-oracular-amd64.rust-hwlib_0.0.1~ppa1_BUILDING.txt.gz + it makes the build fail, link to build log: https://launchpad.net/~nhutsko/+archive/ubuntu/hwcert/+builds?build_text=&build_state=built - 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 + - The package runs an autopkgtest, and is currently passing on + riscv64, arm64, armhf, amd64 architectures, link to test logs: + * oracular: https://autopkgtest.ubuntu.com/results/autopkgtest-oracular-nhutsko-hwcert/ + * noble: https://autopkgtest.ubuntu.com/results/autopkgtest-noble-nhutsko-hwcert/ + * jammy: https://autopkgtest.ubuntu.com/results/autopkgtest-jammy-nhutsko-hwcert/ + * focal: https://autopkgtest.ubuntu.com/results/autopkgtest-focal-nhutsko-hwcert/ - 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). - RULE: If possible such things should stay in universe. Sometimes that is - RULE: impossible due to the way how features/plugins/dependencies work - RULE: but if you are going to ask for promotion of something untestable - RULE: please outline why it couldn't provide its value (e.g. by splitting - RULE: binaries) to users from universe. - RULE: This is a balance that is hard to strike well, the request is that all - RULE: options have been exploited before giving up. Look for more details - RULE: and backgrounds https://github.com/canonical/ubuntu-mir/issues/30 - RULE: Just like in the SRU process it is worth to understand what the - RULE: consequences a regression (due to a test miss) would be. Therefore - RULE: if being untestable we ask to outline what consequences this would - RULE: have for the given package. And let us be honest, even if you can - RULE: test you are never sure you will be able to catch all potential - RULE: regressions. So this is mostly to force self-awareness of the owning - RULE: team than to make a decision on. - TODO: - The package can not be well tested at build or autopkgtest time - TODO: because TBD. To make up for that: - TODO-A: - We have access to such hardware in the team - TODO-B: - We have allocated budget to get this hardware, but it is not here - TODO-B: yet - TODO-C: - We have checked with solutions-qa and will use their hardware - TODO-C: through testflinger - TODO-D: - We have checked with other team TBD and will use their hardware - TODO-D: through TBD (eg. MAAS) - TODO-E: - We have checked and found a simulator which covers this case - TODO-E: sufficiently for testing, our plan to use it is TBD - TODO-F: - We have engaged with the upstream community and due to that - TODO-F: can tests new package builds via TBD - TODO-G: - We have engaged with our user community and due to that - TODO-G: can tests new package builds via TBD - TODO-H: - We have engaged with the hardware manufacturer and made an - TODO-H: agreement to test new builds via TBD - TODO-A-H: - Based on that access outlined above, here are the details of the - TODO-A-H: test plan/automation TBD (e.g. script or repo) and (if already - TODO-A-H: possible) example output of a test run: TBD (logs). - TODO-A-H: We will execute that test plan - TODO-A-H1: on-uploads - TODO-A-H2: regularly (TBD details like frequency: monthly, infra: jira-url) - TODO-X: - We have exhausted all options, there really is no feasible way - TODO-X: to test or recreate this. We are aware of the extra implications - TODO-X: and duties this has for our team (= help SEG and security on - TODO-X: servicing this package, but also more effort on any of your own - TODO-X: bug triage and fixes). - TODO-X: Due to TBD there also is no way to provide this to users from - TODO-X: universe. - TODO-X: Due to the nature, integration and use cases of the package the - TODO-X: consequences of a regression that might slip through most likely - TODO-X: would include - TODO-X: - TBD - TODO-X: - TBD - TODO-X: - TBD - - 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 does have not failing autopkgtests right now [Quality assurance - packaging] - debian/watch is not present because it is a native package - debian/control defines a correct Maintainer field - Lintian overrides are not present - - This package only has minor lintian pedantic warnings. + - This package only has minor lintian pedantic warnings. The warning regarding Vendor-Sources-Rust + header is expected, since it's required for Rust packages that use vendored dependencies. # lintian --pedantic rust-hwlib_0.0.1\~ppa2_source.changes W: rust-hwlib source: unknown-field Vendored-Sources-Rust P: rust-hwlib source: package-uses-old-debhelper-compat-version 12 P: rust-hwlib source: uses-debhelper-compat-file [debian/compat] - 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://github.com/canonical/hardware- api/blob/main/client/hwlib/debian/rules [UI standards] - Application is not end-user facing [Dependencies] - No further depends or recommends dependencies that are not yet in main [Standards compliance] - This package correctly follows FHS and Debian Policy [Maintenance/Owner] - The owning team will be ~hardware-certification and I have their acknowledgement for that commitment - The future owning team is already subscribed to the package - This does not use static builds - The Canonical Hardware Certification team (~canonical-hw-cert) 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 in the repo: https://github.com/canonical/hardware-api/blob/main/Cargo.lock - This package is rust based and vendors all non language-runtime dependencies - The package has been built within the last 3 months in PPA - Build link on launchpad: https://launchpad.net/~nhutsko/+archive/ubuntu/hwcert/+packages [Background information] - The Package description explains the package well - Upstream Name is hwlib - - Link to upstream project https://github.com/canonical/hardware-api/tree/main/client/hwlib + - Link to upstream project https://github.com/canonical/hardware-api/tree/main/client/hwlib/
** Description changed: [Availability] - This package rust-hwlib is published to the PPA: https://launchpad.net/~nhutsko/+archive/ubuntu/hwcert, it'is NOT part of the universe. We have an exception to publish it directly to main, since this library will help the development of solutions that affect Canonical customers directly. Please check with ~paelzer for more information. - The package rust-hwlib build for the architectures it is designed to work on. - It currently builds and works for architectures: riscv64, arm64, armhf, amd64 - Link to package: https://launchpad.net/~nhutsko/+archive/ubuntu/hwcert/+packages [Rationale] - This package rust-hwlib is part of the [hardware-api](https://github.com/canonical/hardware-api) project, owned and developed by Canonical Certification team. It will be used by Ubuntu pro-client to retrieve information about the machine and check its certification status. - The package rust-hwlib will generally be useful for a large number of users who use Ubuntu and want see what components have been tested and certified and for which Ubuntu releases - There is no other/better way to solve this that is already in main or should go universe->main instead of this. - The package rust-hwlib is required in Ubuntu main no later than April 2025 due to 25.04 release date, so users and Canonical customer can install it for the latest Ubuntu release [Security] - No CVEs/security issues in this software in the past - no `suid` or `sgid` binaries - no executables in `/sbin` and `/usr/sbin` - Package does not install services, timers or recurring jobs - Packages does not open privileged ports (ports < 1024). - Package does not expose any external endpoints - Packages does not contain extensions to security-sensitive software [Quality assurance - function/usage] - The package works well right after install [Quality assurance - maintenance] - The package is maintained well in Upstream and does not have too many, long-term & critical, open bugs - Upstream's bug tracker: https://github.com/canonical/hardware-api/issues - 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://launchpad.net/~nhutsko/+archive/ubuntu/hwcert/+builds?build_text=&build_state=built + it makes the build fail, link to build log: + https://launchpad.net/~nhutsko/+archive/ubuntu/hwcert/+builds?build_text=&build_state=built - The package runs an autopkgtest, and is currently passing on - riscv64, arm64, armhf, amd64 architectures, link to test logs: - * oracular: https://autopkgtest.ubuntu.com/results/autopkgtest-oracular-nhutsko-hwcert/ - * noble: https://autopkgtest.ubuntu.com/results/autopkgtest-noble-nhutsko-hwcert/ - * jammy: https://autopkgtest.ubuntu.com/results/autopkgtest-jammy-nhutsko-hwcert/ - * focal: https://autopkgtest.ubuntu.com/results/autopkgtest-focal-nhutsko-hwcert/ + riscv64, arm64, armhf, amd64 architectures, link to test logs: + * oracular: https://autopkgtest.ubuntu.com/results/autopkgtest-oracular-nhutsko-hwcert/ + * noble: https://autopkgtest.ubuntu.com/results/autopkgtest-noble-nhutsko-hwcert/ + * jammy: https://autopkgtest.ubuntu.com/results/autopkgtest-jammy-nhutsko-hwcert/ + * focal: https://autopkgtest.ubuntu.com/results/autopkgtest-focal-nhutsko-hwcert/ - The package does have not failing autopkgtests right now [Quality assurance - packaging] - debian/watch is not present because it is a native package - debian/control defines a correct Maintainer field - Lintian overrides are not present - This package only has minor lintian pedantic warnings. The warning regarding Vendor-Sources-Rust - header is expected, since it's required for Rust packages that use vendored dependencies. + header is expected, since it's required for Rust packages that use vendored dependencies. # lintian --pedantic rust-hwlib_0.0.1\~ppa2_source.changes W: rust-hwlib source: unknown-field Vendored-Sources-Rust P: rust-hwlib source: package-uses-old-debhelper-compat-version 12 P: rust-hwlib source: uses-debhelper-compat-file [debian/compat] - 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://github.com/canonical/hardware- api/blob/main/client/hwlib/debian/rules [UI standards] - Application is not end-user facing [Dependencies] - No further depends or recommends dependencies that are not yet in main [Standards compliance] - This package correctly follows FHS and Debian Policy [Maintenance/Owner] - The owning team will be ~hardware-certification and I have their acknowledgement for that commitment - The future owning team is already subscribed to the package - This does not use static builds - The Canonical Hardware Certification team (~canonical-hw-cert) 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 in the repo: https://github.com/canonical/hardware-api/blob/main/Cargo.lock - This package is rust based and vendors all non language-runtime dependencies - The package has been built within the last 3 months in PPA - Build link on launchpad: https://launchpad.net/~nhutsko/+archive/ubuntu/hwcert/+packages [Background information] - The Package description explains the package well - Upstream Name is hwlib - Link to upstream project https://github.com/canonical/hardware-api/tree/main/client/hwlib/ ** Description changed: [Availability] - This package rust-hwlib is published to the PPA: https://launchpad.net/~nhutsko/+archive/ubuntu/hwcert, it'is NOT part of the universe. We have an exception to publish it directly to main, since this library will help the development of solutions that affect Canonical customers directly. Please check with ~paelzer for more information. - The package rust-hwlib build for the architectures it is designed to work on. - It currently builds and works for architectures: riscv64, arm64, armhf, amd64 - Link to package: https://launchpad.net/~nhutsko/+archive/ubuntu/hwcert/+packages [Rationale] - This package rust-hwlib is part of the [hardware-api](https://github.com/canonical/hardware-api) project, owned and developed by Canonical Certification team. It will be used by Ubuntu pro-client to retrieve information about the machine and check its certification status. - The package rust-hwlib will generally be useful for a large number of users who use Ubuntu and want see what components have been tested and certified and for which Ubuntu releases - There is no other/better way to solve this that is already in main or should go universe->main instead of this. - The package rust-hwlib is required in Ubuntu main no later than April 2025 due to 25.04 release date, so users and Canonical customer can install it for the latest Ubuntu release [Security] - No CVEs/security issues in this software in the past - no `suid` or `sgid` binaries - no executables in `/sbin` and `/usr/sbin` - Package does not install services, timers or recurring jobs - Packages does not open privileged ports (ports < 1024). - Package does not expose any external endpoints - Packages does not contain extensions to security-sensitive software [Quality assurance - function/usage] - The package works well right after install [Quality assurance - maintenance] - The package is maintained well in Upstream and does not have too many, long-term & critical, open bugs - Upstream's bug tracker: https://github.com/canonical/hardware-api/issues - 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://launchpad.net/~nhutsko/+archive/ubuntu/hwcert/+builds?build_text=&build_state=built + it makes the build fail, link to build log: + https://launchpad.net/~nhutsko/+archive/ubuntu/hwcert/+builds?build_text=&build_state=built - The package runs an autopkgtest, and is currently passing on riscv64, arm64, armhf, amd64 architectures, link to test logs: * oracular: https://autopkgtest.ubuntu.com/results/autopkgtest-oracular-nhutsko-hwcert/ * noble: https://autopkgtest.ubuntu.com/results/autopkgtest-noble-nhutsko-hwcert/ * jammy: https://autopkgtest.ubuntu.com/results/autopkgtest-jammy-nhutsko-hwcert/ * focal: https://autopkgtest.ubuntu.com/results/autopkgtest-focal-nhutsko-hwcert/ - The package does have not failing autopkgtests right now [Quality assurance - packaging] - debian/watch is not present because it is a native package - debian/control defines a correct Maintainer field - Lintian overrides are not present - This package only has minor lintian pedantic warnings. The warning regarding Vendor-Sources-Rust header is expected, since it's required for Rust packages that use vendored dependencies. # lintian --pedantic rust-hwlib_0.0.1\~ppa2_source.changes W: rust-hwlib source: unknown-field Vendored-Sources-Rust P: rust-hwlib source: package-uses-old-debhelper-compat-version 12 P: rust-hwlib source: uses-debhelper-compat-file [debian/compat] - 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://github.com/canonical/hardware- api/blob/main/client/hwlib/debian/rules [UI standards] - Application is not end-user facing [Dependencies] - No further depends or recommends dependencies that are not yet in main [Standards compliance] - This package correctly follows FHS and Debian Policy [Maintenance/Owner] - The owning team will be ~hardware-certification and I have their acknowledgement for that commitment - The future owning team is already subscribed to the package - This does not use static builds - The Canonical Hardware Certification team (~canonical-hw-cert) 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 in the repo: https://github.com/canonical/hardware-api/blob/main/Cargo.lock - This package is rust based and vendors all non language-runtime dependencies - The package has been built within the last 3 months in PPA - Build link on launchpad: https://launchpad.net/~nhutsko/+archive/ubuntu/hwcert/+packages [Background information] - The Package description explains the package well - Upstream Name is hwlib - - Link to upstream project https://github.com/canonical/hardware-api/tree/main/client/hwlib/ + - Link to upstream project: https://github.com/canonical/hardware-api/tree/main/client/hwlib/ -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2072561 Title: [MIR] rust-hwlib To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+bug/2072561/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
