** Description changed: [Availability] - The package pdfio is already in Ubuntu universe. - The package pdfio build for the architectures it is designed to work on. - It currently builds and works for architectures: amd64, arm64, armhf, ppc64el, riscv64, s390x - Link to package https://launchpad.net/ubuntu/+source/pdfio - Request for packaging at Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1093735 [Rationale] PDFio is a PDF file handling library, like QPDF but written in regular C, not in C++. Like QPDF it can read, dissect, and assemble PDF files. libcupsfilters currently uses QPDF for PDF file manipulation, a library written in C++. C++ has the disadvantage that ABIs are not stable and then when creating Debian packages from libraries containing C++ code the sysmbol table (debian/*.symbols file) gets cluttered with a lot of ghost symbols and these often differ between the different architectures. This is the main reason, and the relevant one for Ubuntu, for switching libcupsfilters upstream from using QPDF to PDFio. In addition, PDFio is much more lightweight than QPDF, so libcupsfilters can more easily be used on low-resource devices, for example adapter boxes which make legacy printers driverless. For these reasons Michael Sweet, author of CUPS has created PDFio, and he uses it for libcups of CUPS version 3.x The pull request for switching libcupsfilters from QPDF to PDFio and make it free of C++ this way is here: https://github.com/OpenPrinting/libcupsfilters/pull/71/ The PR is shortly before completion and so the next feature release (2.2.0) of libcupsfilters will use PDFio, making PDFio needed in Ubuntu 25.10. As soon as we switch over to CUPS 3.x (Ubuntu 25.10 at the earliest) PDFio is also needed by libcups. --> PDFio needed by libcupsfilters 2.2.0 in Ubuntu 25.10 PDFio needed by CUPS 3.x in Ubuntu 25.10 or later [Security] - https://cve.mitre.org/cve/search_cve_list.html 3 CVEs for PDFio, last in 2024, all fixed https://www.cve.org/CVERecord?id=CVE-2024-42358 https://www.cve.org/CVERecord?id=CVE-2023-28428 https://www.cve.org/CVERecord?id=CVE-2023-24808 - 'site:www.openwall.com/lists/oss-security pdfio' and https://security-tracker.debian.org/tracker/source-package/pdfio Nothing found. - https://ubuntu.com/security/cve?package=pdfio Search facility not working, gives error 500 ("cups" gives also Error 500) - 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 (library) is used by print filters (libcupsfilters, cups-filters). Print filters are started by the system daemon CUPS but ar run as non- privileged user "lp". - Seems to not contain deprecated algorithms, as it uses only libpng, libz, libm, libc (according to "ldd"). Source code has no occurences of "ssl" and "tls". [Quality assurance - function/usage] - The package is a library, so it will not be interacted with by end users. Functions will be called by libcupsfilters and later also by libcups3 - For writing programs using this library there is a man page describing the API and documentation/examples in /usr/shere/doc/pdfio, so all what a developer needs. - There is no post-install configuration needed. [Quality assurance - maintenance] - PDFio is actively maintained and developed upstream by Michael Sweet, author of CUPS, with the main intention to use it as PDF manipulation library for CUPS 3.x. https://github.com/michaelrsweet/pdfio - Upstream issue tracker: https://github.com/michaelrsweet/pdfio/issues - Practically all entries are feature requests, bugs seem to get quickly fixed. - No critical bugs open. + Practically all entries are feature requests, bugs seem to get quickly fixed. + No critical bugs open. - Ubuntu tracker: https://bugs.launchpad.net/ubuntu/+source/pdfio/+bugs - Debian tracker: https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=pdfio - Downstream bug lists are still empty, as pdfio is freshly added to Ubuntu a few days ago and still not yet added to Debian - The package is a general PDF manipulator, so it is completeky independent of the hardware it is running on or where the resulting PDF is for. So everybody can work on it and we have fully automatic testing on our build/test servers [Quality assurance - testing] - The package runs a test suite on build time ("make test"), if it fails - it makes the build fail, link to build log - - - 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 + it makes the build fail, link to build log + https://launchpadlibrarian.net/783787354/buildlog_ubuntu-plucky-amd64.pdfio_1.5.0+dfsg-0ubuntu2_BUILDING.txt.gz + - The package also contains non-trivial autopkgtest(s), the same tests + as the build tests but a few individual tests removed as they do not + work with the installed, dynamically linked library. The test passes on amd64, arm64, armhf, ppc64el, s390x (all architectures where it gets tested on) + https://autopkgtest.ubuntu.com/packages/p/pdfio/plucky/amd64 + https://autopkgtest.ubuntu.com/packages/p/pdfio/plucky/arm64 + https://autopkgtest.ubuntu.com/packages/p/pdfio/plucky/armhf + https://autopkgtest.ubuntu.com/packages/p/pdfio/plucky/ppc64el + https://autopkgtest.ubuntu.com/packages/p/pdfio/plucky/s390x 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 [Quality assurance - packaging] RULE: - The package uses a debian/watch file whenever possible. In cases where RULE: this is not possible (e.g. native packages), the package should either RULE: provide a debian/README.source file or a debian/watch file (with RULE: comments only) providing clear instructions on how to generate the RULE: source tar file. TODO-A: - debian/watch is present and works TODO-B: - debian/watch is not present, instead it has TBD TODO-C: - debian/watch is not present because it is a native package RULE: - The package should define the correct "Maintainer:" field in RULE: debian/control. This needs to be updated, using `update-maintainer` RULE: whenever any Ubuntu delta is applied to the package, as suggested by RULE: dpkg (LP: #1951988) TODO: - 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 TODO: - This package does not yield massive lintian Warnings, Errors TODO: - Please link to a recent build log of the package <TBD> TODO: - Please attach the full output you have got from TODO: `lintian --pedantic` as an extra post to this bug. TODO-A: - Lintian overrides are not present TODO-B: - Lintian overrides are present, but ok because TBD RULE: - The package should not rely on obsolete or about to be demoted packages. RULE: That currently includes package dependencies on Python2 (without RULE: providing Python3 packages), and packages depending on GTK2. TODO: - This package does not rely on obsolete or about to be demoted packages. TODO: - This package has no python2 or GTK2 dependencies RULE: - Debconf questions should not bother the default user too much TODO-A: - The package will be installed by default, but does not ask debconf TODO-A: questions higher than medium TODO-B: - The package will not be installed by default RULE: - The source packaging (in debian/) should be reasonably easy to RULE: understand and maintain. TODO-A: - Packaging and build is easy, link to debian/rules TBD TODO-B: - Packaging is complex, but that is ok because TBD [UI standards] TODO-A: - Application is not end-user facing (does not need translation) TODO-B: - Application is end-user facing, Translation is present, via standard TODO-B: intltool/gettext or similar build and runtime internationalization TODO-B: system see TBD TODO-A: - End-user applications that ships a standard conformant desktop file, TODO-A: see TBD TODO-B: - End-user applications without desktop file, not needed because TBD [Dependencies] RULE: - In case of alternative the preferred alternative must be in main. RULE: - Build(-only) dependencies can be in universe RULE: - If there are further dependencies they need a separate MIR discussion RULE: (this can be a separate bug or another task on the main MIR bug) TODO-A: - No further depends or recommends dependencies that are not yet in main TODO-B: - There are further dependencies that are not yet in main, MIR for them TODO-B: is at TBD TODO-C: - There are further dependencies that are not yet in main, the MIR TODO-C: process for them is handled as part of this bug here. [Standards compliance] RULE: - Major violations should be documented and justified. RULE: - FHS: https://refspecs.linuxfoundation.org/fhs.shtml RULE: - Debian Policy: https://www.debian.org/doc/debian-policy/ TODO-A: - This package correctly follows FHS and Debian Policy TODO-B: - This package violates FHS or Debian Policy, reasons for that are TBD [Maintenance/Owner] RULE: The package must have an acceptable level of maintenance corresponding RULE: to its complexity: RULE: - All packages must have a designated "owning" team, regardless of RULE: complexity. RULE: This requirement of an owning-team comes in two aspects: RULE: - A case needs to have a team essentially saying "yes we will own that" RULE: to enter the MIR process. Usually that is implied by team members RULE: filing MIR requests having the backup by their management for the RULE: long term commitment this implies. RULE: - A community driven MIR request might be filed to show the use case, RULE: but then, as a first step, needs to get a team agreeing to own RULE: it before the case can be processed further. RULE: If unsure which teams to consider have a look at the current mapping RULE: http://reqorts.qa.ubuntu.com/reports/m-r-package-team-mapping.html RULE: In that case (you are not a representative of the team who will RULE: gain the long term committment to this) please ask a representative RULE: of that team to comment on the bug acknowledging that they are ok to RULE: own it. RULE: - The package needs a bug subscriber before it can be promoted to main. RULE: Strictly speaking that subscription can therefore wait until the RULE: moment of the actual promotion by an archive admin. But it is RULE: strongly recommended to subscribe early, as the owning team will get RULE a preview of the to-be-expected incoming bugs later on. RULE: - Simple packages (e.g. language bindings, simple Perl modules, small RULE: command-line programs, etc.) might not need very much maintenance RULE: effort, and if they are maintained well in Debian we can just keep them RULE: synced. They still need a subscribing team to handle bugs, FTBFS and RULE: tests RULE: - More complex packages will usually need a developer or team of RULE: developers paying attention to their bugs, whether that be in Ubuntu RULE: or elsewhere (often Debian). Packages that deliver major new headline RULE: features in Ubuntu need to have commitment from Ubuntu developers RULE: willing to spend substantial time on them. TODO-A: - The owning team will be TBD and I have their acknowledgement for TODO-A: that commitment TODO-B: - I Suggest the owning team to be TBD TODO-A: - The future owning team is already subscribed to the package TODO-B: - The future owning team is not yet subscribed, but will subscribe to TODO-B: the package before promotion RULE: - Responsibilities implied by static builds promoted to main, which is RULE: not a recommended but a common case with golang and rust packages. RULE: - the security team will track CVEs for all vendored/embedded sources in main RULE: - the security team will provide updates to main for all `golang-*-dev` RULE: packages RULE: - the security team will provide updates to main for non-vendored RULE: dependencies as per normal procedures (including e.g., RULE: sponsoring/coordinating uploads from teams/upstream projects, etc) RULE: - the security team will perform no-change-rebuilds for all packages RULE: listing an CVE-fixed package as Built-Using and coordinate testing RULE: with the owning teams responsible for the rebuilt packages RULE: - for packages that build using any `golang-*-dev` packages: RULE: - the owning team must state their commitment to test RULE: no-change-rebuilds triggered by a dependent library/compiler and to RULE: fix any issues found for the lifetime of the release (including ESM RULE: when included) RULE: - the owning team must provide timely testing of no-change-rebuilds RULE: from the security team, fixing the rebuilt package as necessary RULE: - for packages that build with approved vendored code: RULE: - the owning team must state their commitment to provide updates to RULE: the security team for any affected vendored code for the lifetime of RULE: the release (including ESM when included) RULE: - the security team will alert the owning team of issues that may RULE: affect their vendored code RULE: - the owning team will provide timely, high quality updates for the RULE: security team to sponsor to fix issues in the affected vendored code RULE: - the owning team will use a minimal set of vendored code (e.g., Rust RULE: packages are unlikely to need `*_win` crates to build) RULE: - if subsequent uploads add new vendored components or dependencies RULE: these have to be reviewed and agreed by the security team. RULE: - Such updates in the project might be trivial, but imply that a RULE: dependency for e.g. a CVE fix will be moved to a new major version. RULE: Being vendored that does gladly at least not imply incompatibility RULE: issues with other packages or the SRU policy. But it might happen RULE: that this triggers either: RULE: a) The need to adapt the current version of the main package and/or RULE: other vendored dependencies to work with the new dependency RULE: b) The need to backport the fix in the dependency as the main RULE: package will functionally only work well with the older version RULE: c) The need to backport the fix in the dependency, as it would imply RULE: requiring a newer toolchain to be buildable that isn't available RULE: in the target release. RULE: - The rust ecosystem currently isn't yet considered stable enough for RULE: classic lib dependencies and transitions in main; therefore the RULE: expectation for those packages is to vendor (and own/test) all RULE: dependencies (except those provided by the rust runtime itself). RULE: This implies that all the rules for vendored builds always RULE: apply to them. In addition: RULE: - The rules and checks for rust based packages are preliminary and might RULE: change over time as the ecosystem matures and while RULE: processing the first few rust based packages. RULE: - It is expected rust builds will use dh-cargo so that a later switch RULE: to non vendored dependencies isn't too complex (e.g. it is likely RULE: that over time more common libs shall become stable and then archive RULE: packages will be used to build). RULE: - The tooling to get a Cargo.lock that will include internal vendored RULE: dependencies is described at: RULE: https://github.com/canonical/ubuntu-mir/blob/main/vendoring/Rust.md RULE: - An example of how Rust dependency vendoring can be automated is RULE: "s390-tools", isolating crates in a .orig-vendor.tar.xz tarball: RULE: * https://git.launchpad.net/ubuntu/+source/s390-tools/tree/debian/rules RULE: Other examples include "authd" (for a native package, combined with RULE: Golang vendoring) and "gnome-snapshot" (using debian/missing-sources): RULE: * authd: RULE: https://github.com/ubuntu/authd/blob/main/debian/rules RULE: * gnome-snapshot: RULE: https://salsa.debian.org/ubuntu-dev-team/snapshot/-/blob/ubuntu/latest/debian/README.source RULE: - All vendored dependencies (no matter what language) shall have a RULE: way to be refreshed TODO-A: - This does not use static builds TODO-B: - The team TBD is aware of the implications by a static build and TODO-B: commits to test no-change-rebuilds and to fix any issues found for the TODO-B: lifetime of the release (including ESM) TODO-A: - This does not use vendored code TODO-B: - The team TBD is aware of the implications of vendored code and (as TODO-B: alerted by the security team) commits to provide updates and backports TODO-B: to the security team for any affected vendored code for the lifetime TODO-B: of the release (including ESM). TODO-A: - This does not use vendored code TODO-B: - This package uses vendored go code tracked in go.sum as shipped in the TODO-B: package, refreshing that code is outlined in debian/README.source TODO-C: - This package uses vendored rust code tracked in Cargo.lock as shipped, TODO-C: in the package (at /usr/share/doc/<pkgname>/Cargo.lock - might be TODO-C: compressed), refreshing that code is outlined in debian/README.source TODO-D: - This package uses vendored code, refreshing that code is outlined TODO-D: in debian/README.source TODO-A: - This package is not rust based TODO-B: - This package is rust based and vendors all non language-runtime TODO-B: dependencies 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 [Background information] RULE: - The package descriptions should explain the general purpose and context RULE: of the package. Additional explanations/justifications should be done in RULE: the MIR report. RULE: - If the package was renamed recently, or has a different upstream name, RULE: this needs to be explained in the MIR report. TODO: The Package description explains the package well TODO: Upstream Name is TBD TODO: Link to upstream project TBD TODO: TBD (any further background that might be helpful
** Description changed: [Availability] - The package pdfio is already in Ubuntu universe. - The package pdfio build for the architectures it is designed to work on. - It currently builds and works for architectures: amd64, arm64, armhf, ppc64el, riscv64, s390x - Link to package https://launchpad.net/ubuntu/+source/pdfio - Request for packaging at Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1093735 [Rationale] PDFio is a PDF file handling library, like QPDF but written in regular C, not in C++. Like QPDF it can read, dissect, and assemble PDF files. libcupsfilters currently uses QPDF for PDF file manipulation, a library written in C++. C++ has the disadvantage that ABIs are not stable and then when creating Debian packages from libraries containing C++ code the sysmbol table (debian/*.symbols file) gets cluttered with a lot of ghost symbols and these often differ between the different architectures. This is the main reason, and the relevant one for Ubuntu, for switching libcupsfilters upstream from using QPDF to PDFio. In addition, PDFio is much more lightweight than QPDF, so libcupsfilters can more easily be used on low-resource devices, for example adapter boxes which make legacy printers driverless. For these reasons Michael Sweet, author of CUPS has created PDFio, and he uses it for libcups of CUPS version 3.x The pull request for switching libcupsfilters from QPDF to PDFio and make it free of C++ this way is here: https://github.com/OpenPrinting/libcupsfilters/pull/71/ The PR is shortly before completion and so the next feature release (2.2.0) of libcupsfilters will use PDFio, making PDFio needed in Ubuntu 25.10. As soon as we switch over to CUPS 3.x (Ubuntu 25.10 at the earliest) PDFio is also needed by libcups. --> PDFio needed by libcupsfilters 2.2.0 in Ubuntu 25.10 PDFio needed by CUPS 3.x in Ubuntu 25.10 or later [Security] - https://cve.mitre.org/cve/search_cve_list.html 3 CVEs for PDFio, last in 2024, all fixed https://www.cve.org/CVERecord?id=CVE-2024-42358 https://www.cve.org/CVERecord?id=CVE-2023-28428 https://www.cve.org/CVERecord?id=CVE-2023-24808 - 'site:www.openwall.com/lists/oss-security pdfio' and https://security-tracker.debian.org/tracker/source-package/pdfio Nothing found. - https://ubuntu.com/security/cve?package=pdfio Search facility not working, gives error 500 ("cups" gives also Error 500) - 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 (library) is used by print filters (libcupsfilters, cups-filters). Print filters are started by the system daemon CUPS but ar run as non- privileged user "lp". - Seems to not contain deprecated algorithms, as it uses only libpng, libz, libm, libc (according to "ldd"). Source code has no occurences of "ssl" and "tls". [Quality assurance - function/usage] - The package is a library, so it will not be interacted with by end users. Functions will be called by libcupsfilters and later also by libcups3 - For writing programs using this library there is a man page describing the API and documentation/examples in /usr/shere/doc/pdfio, so all what a developer needs. - There is no post-install configuration needed. [Quality assurance - maintenance] - PDFio is actively maintained and developed upstream by Michael Sweet, author of CUPS, with the main intention to use it as PDF manipulation library for CUPS 3.x. https://github.com/michaelrsweet/pdfio - Upstream issue tracker: https://github.com/michaelrsweet/pdfio/issues Practically all entries are feature requests, bugs seem to get quickly fixed. No critical bugs open. - Ubuntu tracker: https://bugs.launchpad.net/ubuntu/+source/pdfio/+bugs - Debian tracker: https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=pdfio - Downstream bug lists are still empty, as pdfio is freshly added to Ubuntu a few days ago and still not yet added to Debian - The package is a general PDF manipulator, so it is completeky independent of the hardware it is running on or where the resulting PDF is for. So everybody can work on it and we have fully automatic testing on our build/test servers [Quality assurance - testing] - The package runs a test suite on build time ("make test"), if it fails it makes the build fail, link to build log https://launchpadlibrarian.net/783787354/buildlog_ubuntu-plucky-amd64.pdfio_1.5.0+dfsg-0ubuntu2_BUILDING.txt.gz - The package also contains non-trivial autopkgtest(s), the same tests - as the build tests but a few individual tests removed as they do not - work with the installed, dynamically linked library. The test passes on amd64, arm64, armhf, ppc64el, s390x (all architectures where it gets tested on) - https://autopkgtest.ubuntu.com/packages/p/pdfio/plucky/amd64 - https://autopkgtest.ubuntu.com/packages/p/pdfio/plucky/arm64 - https://autopkgtest.ubuntu.com/packages/p/pdfio/plucky/armhf - https://autopkgtest.ubuntu.com/packages/p/pdfio/plucky/ppc64el - https://autopkgtest.ubuntu.com/packages/p/pdfio/plucky/s390x - - 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 + as the build tests but a few individual tests removed as they do not + work with the installed, dynamically linked library. The test passes on amd64, arm64, armhf, ppc64el, s390x (all architectures where it gets tested on) + https://autopkgtest.ubuntu.com/packages/p/pdfio/plucky/amd64 + https://autopkgtest.ubuntu.com/packages/p/pdfio/plucky/arm64 + https://autopkgtest.ubuntu.com/packages/p/pdfio/plucky/armhf + https://autopkgtest.ubuntu.com/packages/p/pdfio/plucky/ppc64el + https://autopkgtest.ubuntu.com/packages/p/pdfio/plucky/s390x + - The package does have not failing autopkgtests right now [Quality assurance - packaging] RULE: - The package uses a debian/watch file whenever possible. In cases where RULE: this is not possible (e.g. native packages), the package should either RULE: provide a debian/README.source file or a debian/watch file (with RULE: comments only) providing clear instructions on how to generate the RULE: source tar file. TODO-A: - debian/watch is present and works TODO-B: - debian/watch is not present, instead it has TBD TODO-C: - debian/watch is not present because it is a native package RULE: - The package should define the correct "Maintainer:" field in RULE: debian/control. This needs to be updated, using `update-maintainer` RULE: whenever any Ubuntu delta is applied to the package, as suggested by RULE: dpkg (LP: #1951988) TODO: - 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 TODO: - This package does not yield massive lintian Warnings, Errors TODO: - Please link to a recent build log of the package <TBD> TODO: - Please attach the full output you have got from TODO: `lintian --pedantic` as an extra post to this bug. TODO-A: - Lintian overrides are not present TODO-B: - Lintian overrides are present, but ok because TBD RULE: - The package should not rely on obsolete or about to be demoted packages. RULE: That currently includes package dependencies on Python2 (without RULE: providing Python3 packages), and packages depending on GTK2. TODO: - This package does not rely on obsolete or about to be demoted packages. TODO: - This package has no python2 or GTK2 dependencies RULE: - Debconf questions should not bother the default user too much TODO-A: - The package will be installed by default, but does not ask debconf TODO-A: questions higher than medium TODO-B: - The package will not be installed by default RULE: - The source packaging (in debian/) should be reasonably easy to RULE: understand and maintain. TODO-A: - Packaging and build is easy, link to debian/rules TBD TODO-B: - Packaging is complex, but that is ok because TBD [UI standards] TODO-A: - Application is not end-user facing (does not need translation) TODO-B: - Application is end-user facing, Translation is present, via standard TODO-B: intltool/gettext or similar build and runtime internationalization TODO-B: system see TBD TODO-A: - End-user applications that ships a standard conformant desktop file, TODO-A: see TBD TODO-B: - End-user applications without desktop file, not needed because TBD [Dependencies] RULE: - In case of alternative the preferred alternative must be in main. RULE: - Build(-only) dependencies can be in universe RULE: - If there are further dependencies they need a separate MIR discussion RULE: (this can be a separate bug or another task on the main MIR bug) TODO-A: - No further depends or recommends dependencies that are not yet in main TODO-B: - There are further dependencies that are not yet in main, MIR for them TODO-B: is at TBD TODO-C: - There are further dependencies that are not yet in main, the MIR TODO-C: process for them is handled as part of this bug here. [Standards compliance] RULE: - Major violations should be documented and justified. RULE: - FHS: https://refspecs.linuxfoundation.org/fhs.shtml RULE: - Debian Policy: https://www.debian.org/doc/debian-policy/ TODO-A: - This package correctly follows FHS and Debian Policy TODO-B: - This package violates FHS or Debian Policy, reasons for that are TBD [Maintenance/Owner] RULE: The package must have an acceptable level of maintenance corresponding RULE: to its complexity: RULE: - All packages must have a designated "owning" team, regardless of RULE: complexity. RULE: This requirement of an owning-team comes in two aspects: RULE: - A case needs to have a team essentially saying "yes we will own that" RULE: to enter the MIR process. Usually that is implied by team members RULE: filing MIR requests having the backup by their management for the RULE: long term commitment this implies. RULE: - A community driven MIR request might be filed to show the use case, RULE: but then, as a first step, needs to get a team agreeing to own RULE: it before the case can be processed further. RULE: If unsure which teams to consider have a look at the current mapping RULE: http://reqorts.qa.ubuntu.com/reports/m-r-package-team-mapping.html RULE: In that case (you are not a representative of the team who will RULE: gain the long term committment to this) please ask a representative RULE: of that team to comment on the bug acknowledging that they are ok to RULE: own it. RULE: - The package needs a bug subscriber before it can be promoted to main. RULE: Strictly speaking that subscription can therefore wait until the RULE: moment of the actual promotion by an archive admin. But it is RULE: strongly recommended to subscribe early, as the owning team will get RULE a preview of the to-be-expected incoming bugs later on. RULE: - Simple packages (e.g. language bindings, simple Perl modules, small RULE: command-line programs, etc.) might not need very much maintenance RULE: effort, and if they are maintained well in Debian we can just keep them RULE: synced. They still need a subscribing team to handle bugs, FTBFS and RULE: tests RULE: - More complex packages will usually need a developer or team of RULE: developers paying attention to their bugs, whether that be in Ubuntu RULE: or elsewhere (often Debian). Packages that deliver major new headline RULE: features in Ubuntu need to have commitment from Ubuntu developers RULE: willing to spend substantial time on them. TODO-A: - The owning team will be TBD and I have their acknowledgement for TODO-A: that commitment TODO-B: - I Suggest the owning team to be TBD TODO-A: - The future owning team is already subscribed to the package TODO-B: - The future owning team is not yet subscribed, but will subscribe to TODO-B: the package before promotion RULE: - Responsibilities implied by static builds promoted to main, which is RULE: not a recommended but a common case with golang and rust packages. RULE: - the security team will track CVEs for all vendored/embedded sources in main RULE: - the security team will provide updates to main for all `golang-*-dev` RULE: packages RULE: - the security team will provide updates to main for non-vendored RULE: dependencies as per normal procedures (including e.g., RULE: sponsoring/coordinating uploads from teams/upstream projects, etc) RULE: - the security team will perform no-change-rebuilds for all packages RULE: listing an CVE-fixed package as Built-Using and coordinate testing RULE: with the owning teams responsible for the rebuilt packages RULE: - for packages that build using any `golang-*-dev` packages: RULE: - the owning team must state their commitment to test RULE: no-change-rebuilds triggered by a dependent library/compiler and to RULE: fix any issues found for the lifetime of the release (including ESM RULE: when included) RULE: - the owning team must provide timely testing of no-change-rebuilds RULE: from the security team, fixing the rebuilt package as necessary RULE: - for packages that build with approved vendored code: RULE: - the owning team must state their commitment to provide updates to RULE: the security team for any affected vendored code for the lifetime of RULE: the release (including ESM when included) RULE: - the security team will alert the owning team of issues that may RULE: affect their vendored code RULE: - the owning team will provide timely, high quality updates for the RULE: security team to sponsor to fix issues in the affected vendored code RULE: - the owning team will use a minimal set of vendored code (e.g., Rust RULE: packages are unlikely to need `*_win` crates to build) RULE: - if subsequent uploads add new vendored components or dependencies RULE: these have to be reviewed and agreed by the security team. RULE: - Such updates in the project might be trivial, but imply that a RULE: dependency for e.g. a CVE fix will be moved to a new major version. RULE: Being vendored that does gladly at least not imply incompatibility RULE: issues with other packages or the SRU policy. But it might happen RULE: that this triggers either: RULE: a) The need to adapt the current version of the main package and/or RULE: other vendored dependencies to work with the new dependency RULE: b) The need to backport the fix in the dependency as the main RULE: package will functionally only work well with the older version RULE: c) The need to backport the fix in the dependency, as it would imply RULE: requiring a newer toolchain to be buildable that isn't available RULE: in the target release. RULE: - The rust ecosystem currently isn't yet considered stable enough for RULE: classic lib dependencies and transitions in main; therefore the RULE: expectation for those packages is to vendor (and own/test) all RULE: dependencies (except those provided by the rust runtime itself). RULE: This implies that all the rules for vendored builds always RULE: apply to them. In addition: RULE: - The rules and checks for rust based packages are preliminary and might RULE: change over time as the ecosystem matures and while RULE: processing the first few rust based packages. RULE: - It is expected rust builds will use dh-cargo so that a later switch RULE: to non vendored dependencies isn't too complex (e.g. it is likely RULE: that over time more common libs shall become stable and then archive RULE: packages will be used to build). RULE: - The tooling to get a Cargo.lock that will include internal vendored RULE: dependencies is described at: RULE: https://github.com/canonical/ubuntu-mir/blob/main/vendoring/Rust.md RULE: - An example of how Rust dependency vendoring can be automated is RULE: "s390-tools", isolating crates in a .orig-vendor.tar.xz tarball: RULE: * https://git.launchpad.net/ubuntu/+source/s390-tools/tree/debian/rules RULE: Other examples include "authd" (for a native package, combined with RULE: Golang vendoring) and "gnome-snapshot" (using debian/missing-sources): RULE: * authd: RULE: https://github.com/ubuntu/authd/blob/main/debian/rules RULE: * gnome-snapshot: RULE: https://salsa.debian.org/ubuntu-dev-team/snapshot/-/blob/ubuntu/latest/debian/README.source RULE: - All vendored dependencies (no matter what language) shall have a RULE: way to be refreshed TODO-A: - This does not use static builds TODO-B: - The team TBD is aware of the implications by a static build and TODO-B: commits to test no-change-rebuilds and to fix any issues found for the TODO-B: lifetime of the release (including ESM) TODO-A: - This does not use vendored code TODO-B: - The team TBD is aware of the implications of vendored code and (as TODO-B: alerted by the security team) commits to provide updates and backports TODO-B: to the security team for any affected vendored code for the lifetime TODO-B: of the release (including ESM). TODO-A: - This does not use vendored code TODO-B: - This package uses vendored go code tracked in go.sum as shipped in the TODO-B: package, refreshing that code is outlined in debian/README.source TODO-C: - This package uses vendored rust code tracked in Cargo.lock as shipped, TODO-C: in the package (at /usr/share/doc/<pkgname>/Cargo.lock - might be TODO-C: compressed), refreshing that code is outlined in debian/README.source TODO-D: - This package uses vendored code, refreshing that code is outlined TODO-D: in debian/README.source TODO-A: - This package is not rust based TODO-B: - This package is rust based and vendors all non language-runtime TODO-B: dependencies 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 [Background information] RULE: - The package descriptions should explain the general purpose and context RULE: of the package. Additional explanations/justifications should be done in RULE: the MIR report. RULE: - If the package was renamed recently, or has a different upstream name, RULE: this needs to be explained in the MIR report. TODO: The Package description explains the package well TODO: Upstream Name is TBD TODO: Link to upstream project TBD TODO: TBD (any further background that might be helpful -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2103648 Title: [MIR] pdfio To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pdfio/+bug/2103648/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
