** Description changed: [Availability] The package papers is already in Ubuntu universe. The package papers build for the architectures it is designed to work on. It currently builds and works for architectures: every Ubuntu release architecture except for i386 and armhf. armhf is not an Ubuntu Desktop architecture. There is a Rust toolchain issue on armhf affecting some apps like papers. Link to package https://launchpad.net/ubuntu/+source/papers [Rationale] There must be a certain level of demand for the package - The package papers is required in Ubuntu main for - The package papers will generally be useful for a large part of our user base - Package papers covers the same use case as evince, but is better because it is much more actively maintained than evince and GNOME is switching from evince to papers, thereby we want to replace evince. - There is no other/better way to solve this that is already in main or should go universe->main instead of this. - The binary package papers needs to be in main to achieve providing the best maintained and integrated standalone PDF viewer in Ubuntu - The package papers is required in Ubuntu main for Ubuntu 25.04. Obviously it won't make it in before Feature Freeze so we'll file a Feature Freeze Exception later. [Security] - Had multiple security issues in the past https://security-tracker.debian.org/tracker/source-package/evince https://ubuntu.com/security/cve?package=evince I am linking to evince because papers is a fork of evince. - 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: + apparmor profile copied from evince - Packages does not open privileged ports (ports < 1024). - Package does not expose any external endpoints - Packages does not contain extensions to security-sensitive software Papers is expected to be able to frequently parse and view untrusted PDFs, although poppler is the library that should be doing most of that work. [Quality assurance - function/usage] - The package works well right after install [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/papers + Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=papers + Upstream https://gitlab.gnome.org/GNOME/Incubator/papers/-/issues - The package does not deal with exotic hardware we cannot support [Quality assurance - testing] - 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 package does not run a test at build time because the app is a GUI + frontend for poppler. There aren't mature frameworks for testing GTK4 + apps. - 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 all + architectures it is built for (all Ubuntu architectures except for i386 + and armhf) - 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 + https://autopkgtest.ubuntu.com/packages/papers - 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 + - The package does have not failing autopkgtests right now - 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 can not be well tested at build or autopkgtest time + because it is a GUI PDF app. To make up for that, we created a manual + test plan + + https://wiki.ubuntu.com/DesktopTeam/TestPlans/Papers + + We will execute that test plan on-uploads regularly (for every SRU and + when uploading new major versions to the Ubuntu development release) [Quality assurance - packaging] - debian/watch is present and works - 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 + - This package does not yield massive lintian Warnings, Errors + - Please link to a recent build log of the package + https://launchpad.net/ubuntu/+source/papers/48~beta-3ubuntu1 + + - Please attach the full output you have got from `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 be installed by default, but does not ask debconf questions - 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 - - https://salsa.debian.org/gnome- - team/papers/-/blob/debian/latest/debian/rules + - Packaging and build is easy, link to debian/rules + https://salsa.debian.org/ubuntu-dev-team/papers/-/blob/ubuntu/latest/debian/rules [UI standards] - Application is end-user facing, Translation is present, via standard intltool/gettext or similar build and runtime internationalization system - End-user application that ships a standard conformant desktop file [Dependencies] - No further depends or recommends dependencies that are not yet in main [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 + - This package correctly follows FHS and Debian Policy [Maintenance/Owner] - The owning team will be Desktop Packages and I have their acknowledgement for that commitment - The future owning team is not yet subscribed, but will subscribe to the package before promotion - 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) + - The team Ubuntu Desktop 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) - 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). + - The team Ubuntu Desktop 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). - 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 + - This package uses vendored rust code tracked in Cargo.lock, refreshing + that code is outlined 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 + NOTE: The MIR documentation says that Cargo.lock was expected to be + shipped with the package. Is that something we need or is that handled + by the XS-Vendored-Sources-Rust field? - 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 + - This package is rust based and vendors all non language-runtime + dependencies + + - The package has been built within the last 3 months in the archive + https://launchpad.net/ubuntu/+source/papers/48~beta-3ubuntu1 [Background information] The Package description explains the package well Upstream Name is Papers Link to upstream project https://gitlab.gnome.org/GNOME/Incubator/papers Papers was forked from Evince around May 2024. The Papers developers were frustrated that their efforts to improve Evince with merge requests to switch to GTK4 and switch some code from C to rust had been ignored for too long. After the fork, Evince has had minimal development, while Papers has had rapid development with a much larger pool of contributors. GNOME is expected to switch from Evince to Papers for GNOME Core for GNOME 49 (September 2025 release). The tracking bug for that is https://gitlab.gnome.org/Teams/Releng/AppOrganization/-/issues/24 Compared to Evince, these features have been removed: - support for DVI, PostScript and XPS formats. Evince had disabled support for Postscript by default after a security vulnerability years ago but Ubuntu and most distros overrode that behavior change. Microsoft abandoned XPS years ago. - screen reader support isn't working yet (because of the GTK4 port) but this is being worked on and Firefox is able to read PDFs well. Evince's screen reader support is awkward to use. This feature has been added: - menu item to digitally sign a document with certificates such as those present in the national ID for Spain. And some verification of signed documents. Evince or Papers also provides the Print Preview feature for the GTK print dialog. + + I attempted to use cargo-vendor-filterer but the build failed because + there were a large number of required Rust crate dependencies that were + excluded by cargo-vendor-filterer. This presents a burden not just for + this MIR but for every major upload in the future. Assistance is + requested by someone who has more experience with Rust crate + dependencies to fix this issue. Maybe the Papers Cargo.toml files are + insufficient for this use case and needs to specify more requirements + explicitly.
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2097727 Title: [MIR] papers To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/papers/+bug/2097727/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
