** Description changed: lintian depends on "plzip | lzip-decompressor" in Debian. - We have lzip in main. plzip is a parallel version. We should switch to - it. + We have lzip in main. plzip is a concurrent implementation. We should + switch to it. + + (Note: plzip has received a new 1.13-2 version in Debian with enabled + tests and a general refresh of the packaging which I will mostly + reference here, but it is not yet synced to Ubuntu. Should this MIR be + processed and accepted before final freeze I can file a proper sync + request. Both versions build fine.) [Availability] - The package TBDSRC is already in Ubuntu universe. - The package TBDSRC build for the architectures it is designed to work on. - It currently builds and works for architectures: TBD + The package plzip is already in Ubuntu universe. + The package plzip build for the architectures it is designed to work on. + It currently builds and works for architectures: Yes Link to package https://launchpad.net/ubuntu/+source/plzip/1.13-1 [Rationale] - The package TBDSRC is required in Ubuntu main as lintian (in main) depends on plzip | decompressor and we would like to get rid of the Ubuntu delta on that package. + The package plzip is required in Ubuntu main as lintian (in main) depends on plzip | lzip-decompressor and we would like to get rid of the Ubuntu delta on that package. - Switching to the parallel decompression version should give a speedup - for lzip decompression for all workloads using this archive format. + Switching to the parallel decompression version should also give a + speedup for lzip decompression for all workloads using this archive + format. This is the first time package will be in main The binary packages plzip needs to be in main to achieve the above stated purpose, the source package does not build other binary packages (except the -dbgsym) so there is no split to consider. It would be great and useful to community/processes to have the package plzip in Ubuntu main, but there is no definitive deadline. [Security] No CVEs/security issues in this software in the past which I was able to find via the Debian, Ubuntu or mitre database. - no `suid` or `sgid` binaries - no executables in `/sbin` and `/usr/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: - Package uses the standard hardening=+all flags - Packages does not open privileged ports (ports < 1024). - 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 and has man and info pages [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/plzip/+bug - Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=plzip - Upstream's bug tracker: https://lists.nongnu.org/mailman/listinfo/lzip-bug - The package does not deal with exotic hardware we cannot support [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 + - The latest 1.13-2 version runs a test suite on build time, if it fails + it makes the build fail, link to build log: https://launchpadlibrarian.net/877536420/buildlog_ubuntu-stonking-amd64.plzip_1.13-2~ppa1_BUILDING.txt.gz (the output is quite terse, but the underlying testsuite is extensive) - 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). - 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 not run an autopkgtest because of no specific + technical reason. I already talked to the Debian maintainer that I will + contribute those to Debian soon. Notably lzip which plzip is supposed to + replace also doesn't have autopkgtests. [Quality assurance - packaging] - A mechanism to detect and fetch new upstream versions is present and works (debian/watch) - debian/control defines a correct Maintainer field - RULE: - It is often useful to run `lintian --pedantic` on the package to spot - RULE: the most common packaging issues in advance - RULE: - Non-obvious or non-properly commented lintian overrides should be - RULE: explained - This package does not yield massive lintian Warnings, Errors - Please link to a recent build log of the package: https://launchpadlibrarian.net/862202942/buildlog_ubuntu-stonking-amd64.plzip_1.13-1_BUILDING.txt.gz - TODO: - Please attach the full output you have got from - TODO: `lintian --pedantic` as an extra post to this bug. - 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 - - Packaging and build is easy, link to debian/rules TBD + - Packaging and build is easy, link to debian/rules: https://git.launchpad.net/ubuntu/+source/plzip/tree/debian/rules [UI standards] - Application is not end-user facing (does not need translation) [Dependencies] - There are further dependencies that are not yet in main, the MIR process for them is handled as part of this bug here. The dependencies are the binaries liblz1/libzl-dev from the lzlib source package. They have the same upstream maintainer and lzlib is practically the encoder from lzip extracted into a standalone package. [Standards compliance] - This package correctly follows FHS and Debian Policy - Based on a reasonable review of information available at the time of this report, no expiry, time-limited grants, or obvious legal encumbrances have been identified that would be expected to affect promotion [Maintenance/Owner] - I Suggest the owning team to be debcrafters, as they already own lzip and lintian - The future owning team is not yet subscribed, but will subscribe to the package before promotion - This does not use static builds - This does not use vendored code - This package is not rust based - RULE: - Some packages build and update often, in this case everyone can just - RULE: check the recent build logs to ensure if it builds fine. - RULE: But some other packages are rather stable and have not been rebuilt - RULE: in a long time. There no one can be confident it would build on e.g. - RULE: an urgent security fix. Hence we ask if there has been a recent build. - RULE: That might be a recent build that has been done anyway as seen on - RULE: https://launchpad.net/ubuntu/+source/<source>, a reference to a recent - RULE: archive test rebuild (those are announced on the ubuntu-devel mailing - RULE: list like https://lists.ubuntu.com/archives/ubuntu-devel-announce/2024-January/001342.html), - RULE: or a build set up by the reporter in a PPA with all architectures - RULE: enabled. - TODO-A: - The package has been built within the last 3 months in the archive - TODO-B: - The package has been built within the last 3 months as part - TODO-B: of a test rebuild - TODO-C: - The package has been built within the last 3 months in PPA - TODO-D: - The package has been built within the last 3 months in sbuild as it - TODO-D: can not be uploaded yet - RULE: - To make it easier for everyone, please provide a link to that build so - RULE: everyone can follow up easily e.g. checking the various architectures. - RULE: Example https://launchpad.net/ubuntu/+source/qemu/1:8.2.2+ds-0ubuntu1 - TODO: - Build link on launchpad: TBD + - The package has been built within the last 3 months as part + of a test rebuild (1.13-1): https://launchpad.net/ubuntu/+archive/test-rebuild-20260624-stonking/+sourcepub/18519816/+listing-archive-extra + - The package has been built within the last 3 months in PPA (1.13-2): https://launchpad.net/~finnrg/+archive/ubuntu/mir-plzip/+sourcepub/18743262/+listing-archive-extra - RULE: A few times we had packages that seemed fine for the package itself, but - RULE: caused quite some fallout and effort in related teams. We'd ask you to - RULE: think who else might be affected by promoting this package(s) and to - RULE: please coordinate with them upfront so they have time, understanding and - RULE: sympathy available. - RULE: Examples of the past which we admit could have been better (grows by - RULE: painful lessons learned): - RULE: - changing to rust coreutils forced us to update any apparmor profiles - RULE that referred to these paths - TODO-A: This change will not impact other teams - TODO-B: This change will impact other teams TBD[, TBD] and they are - TODO-B: aware due to TBD + - This change will not impact other teams as far as I know [Background information] - The Package description explains the package well - Upstream Name is plzip - Link to upstream project http://www.nongnu.org/lzip/plzip.html - - TODO: TBD (any further background that might be helpful + - The Package description explains the package well + - Upstream Name is plzip + - Link to upstream project http://www.nongnu.org/lzip/plzip.html
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2154054 Title: [MIR] plzip To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lzlib/+bug/2154054/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
