| 2018-02-06 21:04:03 |
Till Kamppeter |
bug |
|
|
added bug |
| 2018-02-06 21:04:43 |
Till Kamppeter |
cpdb-libs (Ubuntu): importance |
Undecided |
High |
|
| 2018-02-06 21:05:04 |
Till Kamppeter |
bug |
|
|
added subscriber MIR approval team |
| 2018-06-07 19:05:47 |
Matthias Klose |
cpdb-libs (Ubuntu): status |
New |
Incomplete |
|
| 2018-06-22 17:15:30 |
Till Kamppeter |
cpdb-libs (Ubuntu): status |
Incomplete |
In Progress |
|
| 2018-09-13 13:48:06 |
Matthias Klose |
cpdb-libs (Ubuntu): status |
In Progress |
Incomplete |
|
| 2018-10-17 20:53:20 |
Till Kamppeter |
bug |
|
|
added subscriber Didier Raboud |
| 2018-10-18 20:54:13 |
Till Kamppeter |
bug watch added |
|
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911335 |
|
| 2023-01-03 17:22:45 |
Till Kamppeter |
description |
[Availability]
Already in universe
Built for all supported architectures
[Rationale]
The Common Printing Dialog Backends (CPDB) project of OpenPrinting is about separating the print dialogs of different GUI toolkits and applications (GTK, Qt, LibreOffice, ...) from the different print technologies (CUPS/IPP, Google Cloud Print, ...) so that they can get developed independently and so always from all applications one can print with all print technologies and changes in the print technologies get supported quickly.
If one opens the print dialog, the dialog will not talk directly to CUPS, Google Cloud Print, or any other printing system. For this communication there are the backends. The dialog will find all available backend and sends commands to them, for listing all available printers, giving property/option lists for the selected printers, and printing on the selcted printer. This communication is done via D-Bus. So the backends are easily exchangeable and for getting support for a new print technology only its backend needs to get added.
[Security]
No known security issues, no CVEs for cpdb-libs known.
The backends are triggered via session D-Bus and always run as the same user as the calling print dialog, so they do not introduce additional security problems.
The separation of the communication with individual print technologies makes this code only be needed once (in the appropriate backend) instead of in each print dialog. This simplifies the security maintenance.
[Quality assurance]
- The Ubuntu Printing Team is subscribed.
https://bugs.launchpad.net/ubuntu/+source/cpdb-libs
https://github.com/OpenPrinting/cpdb-libs/issues
No upstream tests or autopkgtests.
[Dependencies]
CUPS, Glib, D-Bus -> all in main.
[Standards compliance]
The package meets the FHS and Debian Policy standards (4.1.0)
[Maintenance]
- Actively developed upstream. Last release was 1.1.0
https://github.com/OpenPrinting/cpdb-libs/commits/master |
[Availability]
Already in universe
Built for all supported architectures
[Rationale]
The Common Printing Dialog Backends (CPDB) project of OpenPrinting is about separating the print dialogs of different GUI toolkits and applications (GTK, Qt, Firefox, Chromium, LibreOffice, ...) from the different print technologies (CUPS, print to file, cloud printing services, ...) so that they can get developed independently and so always from all applications one can print with all print technologies and changes in the print technologies get supported quickly.
If one opens the print dialog, the dialog will not talk directly to CUPS, a cloud printing service, or any other printing system. For this communication there are the backends. The dialog will find all available backends and sends commands to them, for listing all available printers, giving property/option lists for the selected printers, and printing on the selected printer. This communication is done via D-Bus. So the backends are easily exchangeable and for getting support for a new print technology only its backend needs to get added.
Backends can even be packaged as Snaps, because they communicate only by D-Bus with the frontend, so a cloud printing provider could put their backend into the Snap Store.
[Security]
No known security issues, no CVEs for cpdb-libs known.
The backends are triggered via session D-Bus and always run as the same user as the calling print dialog, so they do not introduce additional security problems.
The separation of the communication with individual print technologies makes this code only be needed once (in the appropriate backend) instead of in each print dialog. This simplifies the security maintenance.
[Quality assurance]
- The Ubuntu Printing Team is subscribed.
https://bugs.launchpad.net/ubuntu/+source/cpdb-libs
https://github.com/OpenPrinting/cpdb-libs/issues
No upstream tests or autopkgtests.
[Dependencies]
CUPS, libcupsfilters, Glib, D-Bus -> all in main.
[Standards compliance]
The package meets the FHS and Debian Policy standards (4.1.0)
[Maintenance]
- Actively developed upstream. Last release was 2.0b1
https://github.com/OpenPrinting/cpdb-libs/commits/master |
|
| 2023-01-10 23:37:47 |
Till Kamppeter |
bug |
|
|
added subscriber Thorsten Alteholz |
| 2023-01-10 23:37:51 |
Till Kamppeter |
removed subscriber Didier Raboud |
|
|
|
| 2023-01-16 15:57:37 |
Till Kamppeter |
description |
[Availability]
Already in universe
Built for all supported architectures
[Rationale]
The Common Printing Dialog Backends (CPDB) project of OpenPrinting is about separating the print dialogs of different GUI toolkits and applications (GTK, Qt, Firefox, Chromium, LibreOffice, ...) from the different print technologies (CUPS, print to file, cloud printing services, ...) so that they can get developed independently and so always from all applications one can print with all print technologies and changes in the print technologies get supported quickly.
If one opens the print dialog, the dialog will not talk directly to CUPS, a cloud printing service, or any other printing system. For this communication there are the backends. The dialog will find all available backends and sends commands to them, for listing all available printers, giving property/option lists for the selected printers, and printing on the selected printer. This communication is done via D-Bus. So the backends are easily exchangeable and for getting support for a new print technology only its backend needs to get added.
Backends can even be packaged as Snaps, because they communicate only by D-Bus with the frontend, so a cloud printing provider could put their backend into the Snap Store.
[Security]
No known security issues, no CVEs for cpdb-libs known.
The backends are triggered via session D-Bus and always run as the same user as the calling print dialog, so they do not introduce additional security problems.
The separation of the communication with individual print technologies makes this code only be needed once (in the appropriate backend) instead of in each print dialog. This simplifies the security maintenance.
[Quality assurance]
- The Ubuntu Printing Team is subscribed.
https://bugs.launchpad.net/ubuntu/+source/cpdb-libs
https://github.com/OpenPrinting/cpdb-libs/issues
No upstream tests or autopkgtests.
[Dependencies]
CUPS, libcupsfilters, Glib, D-Bus -> all in main.
[Standards compliance]
The package meets the FHS and Debian Policy standards (4.1.0)
[Maintenance]
- Actively developed upstream. Last release was 2.0b1
https://github.com/OpenPrinting/cpdb-libs/commits/master |
[Availability]
TODO: The package TBDSRC is already in Ubuntu universe.
TODO: The package TBDSRC build for the architectures it is designed to work on.
TODO: It currently builds and works for architetcures: TBD
TODO: Link to package [[https://launchpad.net/ubuntu/+source/TBDSRC|TBDSRC]]
[Rationale]
RULE: There must be a certain level of demand for the package
TODO: - The package TBDSRC is required in Ubuntu main for TBD
TODO-A: - The package TBDSRC will generally be useful for a large part of
TODO-A: our user base
TODO-B: - The package TBDSRC will not generally be useful for a large part of
TODO-B: our user base, but is important/helpful still because TBD
TODO: - Additional reasons TBD
TODO: - Additionally new use-cases enabled by this are TBD
TODO: - Package TBDSRC covers the same use case as TBD, but is better
TODO: because TBD, thereby we want to replace it.
TODO: - The package TBDSRC is a new runtime dependency of package TBD that
TODO: we already support
RULE: Reviews will take some time. Also the potential extra work out of review
RULE: feedback from either MIR-team and/or security-team will take time.
RULE: For better priorization it is quite helpful to clearly state the
RULE: target release and set a milestone to the bug task.
RULE: When doing so do not describe what you "wish" or "would like to have".
RULE: Only milestones that are sufficiently well-founded and related to
RULE: major releases will be considered
TODO-A: - The package TBDSRC is required in Ubuntu main no later than TBD
TODO-A: due to TBD
TODO-B: - It would be great and useful to community/processes to have the
TODO-B: package TBD in Ubuntu main, but there is no definitive deadline.
[Security]
RULE: The security history and the current state of security issues in the
RULE: package must allow us to support the package for at least 9 months (120
RULE: for LTS+ESM support) without exposing its users to an inappropriate level
RULE: of security risks. This requires checking of several things:
RULE: - Search in the National Vulnerability Database using the PKG as keyword
RULE: http://cve.mitre.org/cve/search_cve_list.html
RULE: - check OSS security mailing list (feed into search engine
RULE: 'site:www.openwall.com/lists/oss-security <pkgname>')
RULE: - Ubuntu CVE Tracker: https://ubuntu.com/security/cve?package=<source-package-name>
TODO-A: - Had #TBD security issues in the past
TODO-A: - TBD links to such security issues in trackers
TODO-A: - TBD to any context that shows how these issues got handled in
TODO-A: the past
TODO-B: - No CVEs/security issues in this software in the past
RULE: - Check for security relevant binaries and behavior.
RULE: If any are present, this requires a more in-depth security review.
TODO: - no `suid` or `sgid` binaries
TODO-A: - no executables in `/sbin` and `/usr/sbin`
TODO-B: - Binary TBD in sbin is no problem because TBD
TODO-A: - Package does not install services, timers or recurring jobs
TODO-B: - Package does install services, timers or recurring jobs
TODO-B: TBD (list services, timers, jobs)
TODO-C: - Package does install services, timers or recurring jobs
TODO-C: TBD (list services, timers, jobs)
TODO-C: Those have the following security features: TBD (add details like
TODO-C: reduced permissions, temp envronment, restricted users/groups,
TODO-C: seccomp, apparmor, ...)
TODO: - Packages does not open privileged ports (ports < 1024)
TODO: - Packages does not contain extensions to security-sensitive software
TODO: (filters, scanners, plugins, UI skins, ...)
[Quality assurance - function/usage]
RULE: - After installing the package it must be possible to make it working with
RULE: a reasonable effort of configuration and documentation reading.
TODO-A: - The package works well right after install
TODO-B: - The package needs post install configuration or reading of
TODO-B: documentation, there isn't a safe default because TBD
[Quality assurance - maintenance]
RULE: - To support a package, we must be reasonably convinced that upstream
RULE: supports and cares for the package.
RULE: - The status of important bugs in Debian, Ubuntu and upstream's bug
RULE: tracking systems must be evaluated. Important bugs must be pointed out
RULE: and discussed in the MIR report.
TODO: - The package is maintained well in Debian/Ubuntu and has not too many
TODO: and long term critical bugs open
TODO: - Ubuntu https://bugs.launchpad.net/ubuntu/+source/TBDSRC/+bug
TODO: - Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=TBDSRC
TODO: - The package has important open bugs, listing them: TBD
TODO-A: - The package does not deal with exotic hardware we cannot support
TODO-B: - The package does deal with exotic hardware, it is present at TBD
TODO-B: to be able to test, fix and verify bugs
[Quality assurance - testing]
RULE: - The package must include a non-trivial test suite
RULE: - it should run at package build and fail the build if broken
TODO-A: - The package runs a test suite on build time, if it fails
TODO-A: it makes the build fail, link to build log TBD
TODO-B: - The package does not run a test at build time because TBD
RULE: - The package should, but is not required to, also contain
RULE: non-trivial autopkgtest(s).
TODO-A: - The package runs an autopkgtest, and is currently passing on
TODO-A: this TBD list of architectures, link to test logs TBD
TODO-B: - The package does not run an autopkgtest because TBD
RULE: - existing but failing tests that shall be handled as "ok to fail"
RULE: need to be explained along the test logs below
TODO-A: - The package does have not failing autopkgtests right now
TODO-B: - The package does have failing autopkgtests tests right now, but since
TODO-B: they always failed they are handled as "ignored failure", this is
TODO-B: ok because TBD
RULE: - If no build tests nor autopkgtests are included, and/or if the package
RULE: requires specific hardware to perform testing, the subscribed team
RULE: must provide a written test plan in a comment to the MIR bug, and
RULE: commit to running that test either at each upload of the package or
RULE: at least once each release cycle. In the comment to the MIR bug,
RULE: please link to the codebase of these tests (scripts or doc of manual
RULE: steps) and attach a full log of these test runs. This is meant to
RULE: assess their validity (e.g. not just superficial)
TODO: - The package can not be tested at build or autopktest time because TBD
TODO: to make up for that here TBD is a test plan/automation and example
TODO: test TBD (logs/scripts)
RULE: - In some cases a solution that is about to be promoted consists of
RULE: several very small libraries and one actual application uniting them
RULE: to achieve something useful. This is rather common in the go/rust space.
RULE: In that case often these micro-libs on their own can and should only
RULE: provide low level unit-tests. But more complex autopkgtests make no
RULE: sense on that level. Therefore in those cases one might want to test on
RULE: the solution level.
RULE: - Process wise MIR-requesting teams can ask (on the bug) for this
RULE: special case to apply for a given case, which reduces the test
RULE: constraints on the micro libraries but in return increases the
RULE: requirements for the test of the actual app/solution.
RULE: - Since this might promote micro-lib packages to main with less than
RULE: the common level of QA any further MIRed program using them will have
RULE: to provide the same amount of increased testing.
TODO: - This package is minimal and will be tested in a more wide reaching
TODO: solution context TBD, details about this testing are here TBD
[Quality assurance - packaging]
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 d/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-B: 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: - [[https://refspecs.linuxfoundation.org/fhs.shtml|FHS]]
RULE: - [[http://www.debian.org/doc/debian-policy/|Debian Policy]]
TODO-A: - This package correctly follows FHS and Debian Policy
TODO-B: - This package violates FHS or Debian Polciy, 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, which is set as a package bug contact. This is not a
RULE: requirement for the MIR team ACK, but for the package to be promoted
RULE: by an archive admin. Still, it is strongly suggested to subscribe,
RULE: as the owning team will get a preview of the to-be-expected incoming
RULE: 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: - Owning Team will be TBD
TODO-A: - Team is already subscribed to the package
TODO-B: - Team is not yet, but will subscribe to 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: - 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 ecosytem 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: - Right now that tooling to get a Cargo.lock that will include internal
RULE: vendored dependencies isn't in place yet (expect a dh-cargo change
RULE: later). Until it is available, as a fallback one can scan the
RULE: directory at build time and let it be generated in debian/rules.
RULE: An example might look like:
RULE: d/rules:
RULE: override_dh_auto_test:
RULE: CARGO_HOME=debian /usr/share/cargo/bin/cargo test --offline
RULE: d/<pkg>.install:
RULE: Cargo.lock /usr/share/doc/<pkg>
RULE: d/config.toml
RULE: # Use the vendorized sources to produce the Cargo.lock file. This
RULE: # can be performed by pointing $CARGO_HOME to the path containing
RULE: # this file.
RULE: [source]
RULE: [source.my-vendor-source]
RULE: directory = "vendor"
RULE: [source.crates-io]
RULE: replace-with = "my-vendor-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 shiped 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: - if there has been an archive test rebuild that has occurred more recently
RULE: than the last upload, the package must have rebuilt successfully
TODO-A: - The package has been built in the archive more recently than the last
TODO-A: test rebuild
TODO-B: - The package successfully built during the most recent test rebuild
TODO-C: - The package was test rebuilt in PPA or sbuild recently (provide link/logs)
[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
============================================================
Original, old-generation MIR description
[Availability]
Already in universe
Built for all supported architectures
[Rationale]
The Common Printing Dialog Backends (CPDB) project of OpenPrinting is about separating the print dialogs of different GUI toolkits and applications (GTK, Qt, Firefox, Chromium, LibreOffice, ...) from the different print technologies (CUPS, print to file, cloud printing services, ...) so that they can get developed independently and so always from all applications one can print with all print technologies and changes in the print technologies get supported quickly.
If one opens the print dialog, the dialog will not talk directly to CUPS, a cloud printing service, or any other printing system. For this communication there are the backends. The dialog will find all available backends and sends commands to them, for listing all available printers, giving property/option lists for the selected printers, and printing on the selected printer. This communication is done via D-Bus. So the backends are easily exchangeable and for getting support for a new print technology only its backend needs to get added.
Backends can even be packaged as Snaps, because they communicate only by D-Bus with the frontend, so a cloud printing provider could put their backend into the Snap Store.
[Security]
No known security issues, no CVEs for cpdb-libs known.
The backends are triggered via session D-Bus and always run as the same user as the calling print dialog, so they do not introduce additional security problems.
The separation of the communication with individual print technologies makes this code only be needed once (in the appropriate backend) instead of in each print dialog. This simplifies the security maintenance.
[Quality assurance]
- The Ubuntu Printing Team is subscribed.
https://bugs.launchpad.net/ubuntu/+source/cpdb-libs
https://github.com/OpenPrinting/cpdb-libs/issues
No upstream tests or autopkgtests.
[Dependencies]
CUPS, libcupsfilters, Glib, D-Bus -> all in main.
[Standards compliance]
The package meets the FHS and Debian Policy standards (4.1.0)
[Maintenance]
- Actively developed upstream. Last release was 2.0b1
https://github.com/OpenPrinting/cpdb-libs/commits/master |
|
| 2023-01-16 16:09:28 |
Till Kamppeter |
description |
[Availability]
TODO: The package TBDSRC is already in Ubuntu universe.
TODO: The package TBDSRC build for the architectures it is designed to work on.
TODO: It currently builds and works for architetcures: TBD
TODO: Link to package [[https://launchpad.net/ubuntu/+source/TBDSRC|TBDSRC]]
[Rationale]
RULE: There must be a certain level of demand for the package
TODO: - The package TBDSRC is required in Ubuntu main for TBD
TODO-A: - The package TBDSRC will generally be useful for a large part of
TODO-A: our user base
TODO-B: - The package TBDSRC will not generally be useful for a large part of
TODO-B: our user base, but is important/helpful still because TBD
TODO: - Additional reasons TBD
TODO: - Additionally new use-cases enabled by this are TBD
TODO: - Package TBDSRC covers the same use case as TBD, but is better
TODO: because TBD, thereby we want to replace it.
TODO: - The package TBDSRC is a new runtime dependency of package TBD that
TODO: we already support
RULE: Reviews will take some time. Also the potential extra work out of review
RULE: feedback from either MIR-team and/or security-team will take time.
RULE: For better priorization it is quite helpful to clearly state the
RULE: target release and set a milestone to the bug task.
RULE: When doing so do not describe what you "wish" or "would like to have".
RULE: Only milestones that are sufficiently well-founded and related to
RULE: major releases will be considered
TODO-A: - The package TBDSRC is required in Ubuntu main no later than TBD
TODO-A: due to TBD
TODO-B: - It would be great and useful to community/processes to have the
TODO-B: package TBD in Ubuntu main, but there is no definitive deadline.
[Security]
RULE: The security history and the current state of security issues in the
RULE: package must allow us to support the package for at least 9 months (120
RULE: for LTS+ESM support) without exposing its users to an inappropriate level
RULE: of security risks. This requires checking of several things:
RULE: - Search in the National Vulnerability Database using the PKG as keyword
RULE: http://cve.mitre.org/cve/search_cve_list.html
RULE: - check OSS security mailing list (feed into search engine
RULE: 'site:www.openwall.com/lists/oss-security <pkgname>')
RULE: - Ubuntu CVE Tracker: https://ubuntu.com/security/cve?package=<source-package-name>
TODO-A: - Had #TBD security issues in the past
TODO-A: - TBD links to such security issues in trackers
TODO-A: - TBD to any context that shows how these issues got handled in
TODO-A: the past
TODO-B: - No CVEs/security issues in this software in the past
RULE: - Check for security relevant binaries and behavior.
RULE: If any are present, this requires a more in-depth security review.
TODO: - no `suid` or `sgid` binaries
TODO-A: - no executables in `/sbin` and `/usr/sbin`
TODO-B: - Binary TBD in sbin is no problem because TBD
TODO-A: - Package does not install services, timers or recurring jobs
TODO-B: - Package does install services, timers or recurring jobs
TODO-B: TBD (list services, timers, jobs)
TODO-C: - Package does install services, timers or recurring jobs
TODO-C: TBD (list services, timers, jobs)
TODO-C: Those have the following security features: TBD (add details like
TODO-C: reduced permissions, temp envronment, restricted users/groups,
TODO-C: seccomp, apparmor, ...)
TODO: - Packages does not open privileged ports (ports < 1024)
TODO: - Packages does not contain extensions to security-sensitive software
TODO: (filters, scanners, plugins, UI skins, ...)
[Quality assurance - function/usage]
RULE: - After installing the package it must be possible to make it working with
RULE: a reasonable effort of configuration and documentation reading.
TODO-A: - The package works well right after install
TODO-B: - The package needs post install configuration or reading of
TODO-B: documentation, there isn't a safe default because TBD
[Quality assurance - maintenance]
RULE: - To support a package, we must be reasonably convinced that upstream
RULE: supports and cares for the package.
RULE: - The status of important bugs in Debian, Ubuntu and upstream's bug
RULE: tracking systems must be evaluated. Important bugs must be pointed out
RULE: and discussed in the MIR report.
TODO: - The package is maintained well in Debian/Ubuntu and has not too many
TODO: and long term critical bugs open
TODO: - Ubuntu https://bugs.launchpad.net/ubuntu/+source/TBDSRC/+bug
TODO: - Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=TBDSRC
TODO: - The package has important open bugs, listing them: TBD
TODO-A: - The package does not deal with exotic hardware we cannot support
TODO-B: - The package does deal with exotic hardware, it is present at TBD
TODO-B: to be able to test, fix and verify bugs
[Quality assurance - testing]
RULE: - The package must include a non-trivial test suite
RULE: - it should run at package build and fail the build if broken
TODO-A: - The package runs a test suite on build time, if it fails
TODO-A: it makes the build fail, link to build log TBD
TODO-B: - The package does not run a test at build time because TBD
RULE: - The package should, but is not required to, also contain
RULE: non-trivial autopkgtest(s).
TODO-A: - The package runs an autopkgtest, and is currently passing on
TODO-A: this TBD list of architectures, link to test logs TBD
TODO-B: - The package does not run an autopkgtest because TBD
RULE: - existing but failing tests that shall be handled as "ok to fail"
RULE: need to be explained along the test logs below
TODO-A: - The package does have not failing autopkgtests right now
TODO-B: - The package does have failing autopkgtests tests right now, but since
TODO-B: they always failed they are handled as "ignored failure", this is
TODO-B: ok because TBD
RULE: - If no build tests nor autopkgtests are included, and/or if the package
RULE: requires specific hardware to perform testing, the subscribed team
RULE: must provide a written test plan in a comment to the MIR bug, and
RULE: commit to running that test either at each upload of the package or
RULE: at least once each release cycle. In the comment to the MIR bug,
RULE: please link to the codebase of these tests (scripts or doc of manual
RULE: steps) and attach a full log of these test runs. This is meant to
RULE: assess their validity (e.g. not just superficial)
TODO: - The package can not be tested at build or autopktest time because TBD
TODO: to make up for that here TBD is a test plan/automation and example
TODO: test TBD (logs/scripts)
RULE: - In some cases a solution that is about to be promoted consists of
RULE: several very small libraries and one actual application uniting them
RULE: to achieve something useful. This is rather common in the go/rust space.
RULE: In that case often these micro-libs on their own can and should only
RULE: provide low level unit-tests. But more complex autopkgtests make no
RULE: sense on that level. Therefore in those cases one might want to test on
RULE: the solution level.
RULE: - Process wise MIR-requesting teams can ask (on the bug) for this
RULE: special case to apply for a given case, which reduces the test
RULE: constraints on the micro libraries but in return increases the
RULE: requirements for the test of the actual app/solution.
RULE: - Since this might promote micro-lib packages to main with less than
RULE: the common level of QA any further MIRed program using them will have
RULE: to provide the same amount of increased testing.
TODO: - This package is minimal and will be tested in a more wide reaching
TODO: solution context TBD, details about this testing are here TBD
[Quality assurance - packaging]
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 d/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-B: 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: - [[https://refspecs.linuxfoundation.org/fhs.shtml|FHS]]
RULE: - [[http://www.debian.org/doc/debian-policy/|Debian Policy]]
TODO-A: - This package correctly follows FHS and Debian Policy
TODO-B: - This package violates FHS or Debian Polciy, 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, which is set as a package bug contact. This is not a
RULE: requirement for the MIR team ACK, but for the package to be promoted
RULE: by an archive admin. Still, it is strongly suggested to subscribe,
RULE: as the owning team will get a preview of the to-be-expected incoming
RULE: 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: - Owning Team will be TBD
TODO-A: - Team is already subscribed to the package
TODO-B: - Team is not yet, but will subscribe to 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: - 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 ecosytem 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: - Right now that tooling to get a Cargo.lock that will include internal
RULE: vendored dependencies isn't in place yet (expect a dh-cargo change
RULE: later). Until it is available, as a fallback one can scan the
RULE: directory at build time and let it be generated in debian/rules.
RULE: An example might look like:
RULE: d/rules:
RULE: override_dh_auto_test:
RULE: CARGO_HOME=debian /usr/share/cargo/bin/cargo test --offline
RULE: d/<pkg>.install:
RULE: Cargo.lock /usr/share/doc/<pkg>
RULE: d/config.toml
RULE: # Use the vendorized sources to produce the Cargo.lock file. This
RULE: # can be performed by pointing $CARGO_HOME to the path containing
RULE: # this file.
RULE: [source]
RULE: [source.my-vendor-source]
RULE: directory = "vendor"
RULE: [source.crates-io]
RULE: replace-with = "my-vendor-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 shiped 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: - if there has been an archive test rebuild that has occurred more recently
RULE: than the last upload, the package must have rebuilt successfully
TODO-A: - The package has been built in the archive more recently than the last
TODO-A: test rebuild
TODO-B: - The package successfully built during the most recent test rebuild
TODO-C: - The package was test rebuilt in PPA or sbuild recently (provide link/logs)
[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
============================================================
Original, old-generation MIR description
[Availability]
Already in universe
Built for all supported architectures
[Rationale]
The Common Printing Dialog Backends (CPDB) project of OpenPrinting is about separating the print dialogs of different GUI toolkits and applications (GTK, Qt, Firefox, Chromium, LibreOffice, ...) from the different print technologies (CUPS, print to file, cloud printing services, ...) so that they can get developed independently and so always from all applications one can print with all print technologies and changes in the print technologies get supported quickly.
If one opens the print dialog, the dialog will not talk directly to CUPS, a cloud printing service, or any other printing system. For this communication there are the backends. The dialog will find all available backends and sends commands to them, for listing all available printers, giving property/option lists for the selected printers, and printing on the selected printer. This communication is done via D-Bus. So the backends are easily exchangeable and for getting support for a new print technology only its backend needs to get added.
Backends can even be packaged as Snaps, because they communicate only by D-Bus with the frontend, so a cloud printing provider could put their backend into the Snap Store.
[Security]
No known security issues, no CVEs for cpdb-libs known.
The backends are triggered via session D-Bus and always run as the same user as the calling print dialog, so they do not introduce additional security problems.
The separation of the communication with individual print technologies makes this code only be needed once (in the appropriate backend) instead of in each print dialog. This simplifies the security maintenance.
[Quality assurance]
- The Ubuntu Printing Team is subscribed.
https://bugs.launchpad.net/ubuntu/+source/cpdb-libs
https://github.com/OpenPrinting/cpdb-libs/issues
No upstream tests or autopkgtests.
[Dependencies]
CUPS, libcupsfilters, Glib, D-Bus -> all in main.
[Standards compliance]
The package meets the FHS and Debian Policy standards (4.1.0)
[Maintenance]
- Actively developed upstream. Last release was 2.0b1
https://github.com/OpenPrinting/cpdb-libs/commits/master |
[Availability]
The package cpdb-libs is already in Ubuntu universe.
The package cpdb-libs build for the architectures it is designed to work on.
It currently builds and works for architetcures: amd64, arm64, armhf, ppc64el, riscv64, s390x
Link to package [[https://launchpad.net/ubuntu/+source/cpdb-libs|cpdb-libs]]
[Rationale]
The Common Printing Dialog Backends (CPDB) project of OpenPrinting is about separating the print dialogs of different GUI toolkits and applications (GTK, Qt, Firefox, Chromium, LibreOffice, ...) from the different print technologies (CUPS, print to file, cloud printing services, ...) so that they can get developed independently and so always from all applications one can print with all print technologies and changes in the print technologies get supported quickly.
If one opens the print dialog, the dialog will not talk directly to CUPS, a cloud printing service, or any other printing system. For this communication there are the backends. The dialog will find all available backends and sends commands to them, for listing all available printers, giving property/option lists for the selected printers, and printing on the selected printer. This communication is done via D-Bus. So the backends are easily exchangeable and for getting support for a new print technology only its backend needs to get added.
Backends can even be packaged as Snaps, because they communicate only by D-Bus with the frontend, so a cloud printing provider could put their backend into the Snap Store.
All packages providing a print dialog will get modified (upstream) to support CPDB with this library and then these packages will depend on cpdb-libs.
These packages are:
- GUI toolkits: GTK, Qt
- GUI applications with their own print dialogs: Firefox/Thunderbird,
Chromium/Chrome, LibreOffice, ...
The coding of the CPDB support in GTK and Qt got already done in GSoC 2022 and currently merge requests are worked on to be included upstream. Once they are upstream (and already before the next upstream releases) they will get added to Ubuntu as distro patches.
See
https://github.com/TinyTrebuchet/gsoc22/
RULE: There must be a certain level of demand for the package
TODO: - The package TBDSRC is required in Ubuntu main for TBD
TODO-A: - The package TBDSRC will generally be useful for a large part of
TODO-A: our user base
TODO-B: - The package TBDSRC will not generally be useful for a large part of
TODO-B: our user base, but is important/helpful still because TBD
TODO: - Additional reasons TBD
TODO: - Additionally new use-cases enabled by this are TBD
TODO: - Package TBDSRC covers the same use case as TBD, but is better
TODO: because TBD, thereby we want to replace it.
TODO: - The package TBDSRC is a new runtime dependency of package TBD that
TODO: we already support
RULE: Reviews will take some time. Also the potential extra work out of review
RULE: feedback from either MIR-team and/or security-team will take time.
RULE: For better priorization it is quite helpful to clearly state the
RULE: target release and set a milestone to the bug task.
RULE: When doing so do not describe what you "wish" or "would like to have".
RULE: Only milestones that are sufficiently well-founded and related to
RULE: major releases will be considered
TODO-A: - The package TBDSRC is required in Ubuntu main no later than TBD
TODO-A: due to TBD
TODO-B: - It would be great and useful to community/processes to have the
TODO-B: package TBD in Ubuntu main, but there is no definitive deadline.
[Security]
RULE: The security history and the current state of security issues in the
RULE: package must allow us to support the package for at least 9 months (120
RULE: for LTS+ESM support) without exposing its users to an inappropriate level
RULE: of security risks. This requires checking of several things:
RULE: - Search in the National Vulnerability Database using the PKG as keyword
RULE: http://cve.mitre.org/cve/search_cve_list.html
RULE: - check OSS security mailing list (feed into search engine
RULE: 'site:www.openwall.com/lists/oss-security <pkgname>')
RULE: - Ubuntu CVE Tracker: https://ubuntu.com/security/cve?package=<source-package-name>
TODO-A: - Had #TBD security issues in the past
TODO-A: - TBD links to such security issues in trackers
TODO-A: - TBD to any context that shows how these issues got handled in
TODO-A: the past
TODO-B: - No CVEs/security issues in this software in the past
RULE: - Check for security relevant binaries and behavior.
RULE: If any are present, this requires a more in-depth security review.
TODO: - no `suid` or `sgid` binaries
TODO-A: - no executables in `/sbin` and `/usr/sbin`
TODO-B: - Binary TBD in sbin is no problem because TBD
TODO-A: - Package does not install services, timers or recurring jobs
TODO-B: - Package does install services, timers or recurring jobs
TODO-B: TBD (list services, timers, jobs)
TODO-C: - Package does install services, timers or recurring jobs
TODO-C: TBD (list services, timers, jobs)
TODO-C: Those have the following security features: TBD (add details like
TODO-C: reduced permissions, temp envronment, restricted users/groups,
TODO-C: seccomp, apparmor, ...)
TODO: - Packages does not open privileged ports (ports < 1024)
TODO: - Packages does not contain extensions to security-sensitive software
TODO: (filters, scanners, plugins, UI skins, ...)
[Quality assurance - function/usage]
RULE: - After installing the package it must be possible to make it working with
RULE: a reasonable effort of configuration and documentation reading.
TODO-A: - The package works well right after install
TODO-B: - The package needs post install configuration or reading of
TODO-B: documentation, there isn't a safe default because TBD
[Quality assurance - maintenance]
RULE: - To support a package, we must be reasonably convinced that upstream
RULE: supports and cares for the package.
RULE: - The status of important bugs in Debian, Ubuntu and upstream's bug
RULE: tracking systems must be evaluated. Important bugs must be pointed out
RULE: and discussed in the MIR report.
TODO: - The package is maintained well in Debian/Ubuntu and has not too many
TODO: and long term critical bugs open
TODO: - Ubuntu https://bugs.launchpad.net/ubuntu/+source/TBDSRC/+bug
TODO: - Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=TBDSRC
TODO: - The package has important open bugs, listing them: TBD
TODO-A: - The package does not deal with exotic hardware we cannot support
TODO-B: - The package does deal with exotic hardware, it is present at TBD
TODO-B: to be able to test, fix and verify bugs
[Quality assurance - testing]
RULE: - The package must include a non-trivial test suite
RULE: - it should run at package build and fail the build if broken
TODO-A: - The package runs a test suite on build time, if it fails
TODO-A: it makes the build fail, link to build log TBD
TODO-B: - The package does not run a test at build time because TBD
RULE: - The package should, but is not required to, also contain
RULE: non-trivial autopkgtest(s).
TODO-A: - The package runs an autopkgtest, and is currently passing on
TODO-A: this TBD list of architectures, link to test logs TBD
TODO-B: - The package does not run an autopkgtest because TBD
RULE: - existing but failing tests that shall be handled as "ok to fail"
RULE: need to be explained along the test logs below
TODO-A: - The package does have not failing autopkgtests right now
TODO-B: - The package does have failing autopkgtests tests right now, but since
TODO-B: they always failed they are handled as "ignored failure", this is
TODO-B: ok because TBD
RULE: - If no build tests nor autopkgtests are included, and/or if the package
RULE: requires specific hardware to perform testing, the subscribed team
RULE: must provide a written test plan in a comment to the MIR bug, and
RULE: commit to running that test either at each upload of the package or
RULE: at least once each release cycle. In the comment to the MIR bug,
RULE: please link to the codebase of these tests (scripts or doc of manual
RULE: steps) and attach a full log of these test runs. This is meant to
RULE: assess their validity (e.g. not just superficial)
TODO: - The package can not be tested at build or autopktest time because TBD
TODO: to make up for that here TBD is a test plan/automation and example
TODO: test TBD (logs/scripts)
RULE: - In some cases a solution that is about to be promoted consists of
RULE: several very small libraries and one actual application uniting them
RULE: to achieve something useful. This is rather common in the go/rust space.
RULE: In that case often these micro-libs on their own can and should only
RULE: provide low level unit-tests. But more complex autopkgtests make no
RULE: sense on that level. Therefore in those cases one might want to test on
RULE: the solution level.
RULE: - Process wise MIR-requesting teams can ask (on the bug) for this
RULE: special case to apply for a given case, which reduces the test
RULE: constraints on the micro libraries but in return increases the
RULE: requirements for the test of the actual app/solution.
RULE: - Since this might promote micro-lib packages to main with less than
RULE: the common level of QA any further MIRed program using them will have
RULE: to provide the same amount of increased testing.
TODO: - This package is minimal and will be tested in a more wide reaching
TODO: solution context TBD, details about this testing are here TBD
[Quality assurance - packaging]
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 d/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-B: 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: - [[https://refspecs.linuxfoundation.org/fhs.shtml|FHS]]
RULE: - [[http://www.debian.org/doc/debian-policy/|Debian Policy]]
TODO-A: - This package correctly follows FHS and Debian Policy
TODO-B: - This package violates FHS or Debian Polciy, 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, which is set as a package bug contact. This is not a
RULE: requirement for the MIR team ACK, but for the package to be promoted
RULE: by an archive admin. Still, it is strongly suggested to subscribe,
RULE: as the owning team will get a preview of the to-be-expected incoming
RULE: 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: - Owning Team will be TBD
TODO-A: - Team is already subscribed to the package
TODO-B: - Team is not yet, but will subscribe to 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: - 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 ecosytem 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: - Right now that tooling to get a Cargo.lock that will include internal
RULE: vendored dependencies isn't in place yet (expect a dh-cargo change
RULE: later). Until it is available, as a fallback one can scan the
RULE: directory at build time and let it be generated in debian/rules.
RULE: An example might look like:
RULE: d/rules:
RULE: override_dh_auto_test:
RULE: CARGO_HOME=debian /usr/share/cargo/bin/cargo test --offline
RULE: d/<pkg>.install:
RULE: Cargo.lock /usr/share/doc/<pkg>
RULE: d/config.toml
RULE: # Use the vendorized sources to produce the Cargo.lock file. This
RULE: # can be performed by pointing $CARGO_HOME to the path containing
RULE: # this file.
RULE: [source]
RULE: [source.my-vendor-source]
RULE: directory = "vendor"
RULE: [source.crates-io]
RULE: replace-with = "my-vendor-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 shiped 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: - if there has been an archive test rebuild that has occurred more recently
RULE: than the last upload, the package must have rebuilt successfully
TODO-A: - The package has been built in the archive more recently than the last
TODO-A: test rebuild
TODO-B: - The package successfully built during the most recent test rebuild
TODO-C: - The package was test rebuilt in PPA or sbuild recently (provide link/logs)
[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
============================================================
Original, old-generation MIR description
[Availability]
Already in universe
Built for all supported architectures
[Rationale]
The Common Printing Dialog Backends (CPDB) project of OpenPrinting is about separating the print dialogs of different GUI toolkits and applications (GTK, Qt, Firefox, Chromium, LibreOffice, ...) from the different print technologies (CUPS, print to file, cloud printing services, ...) so that they can get developed independently and so always from all applications one can print with all print technologies and changes in the print technologies get supported quickly.
If one opens the print dialog, the dialog will not talk directly to CUPS, a cloud printing service, or any other printing system. For this communication there are the backends. The dialog will find all available backends and sends commands to them, for listing all available printers, giving property/option lists for the selected printers, and printing on the selected printer. This communication is done via D-Bus. So the backends are easily exchangeable and for getting support for a new print technology only its backend needs to get added.
Backends can even be packaged as Snaps, because they communicate only by D-Bus with the frontend, so a cloud printing provider could put their backend into the Snap Store.
[Security]
No known security issues, no CVEs for cpdb-libs known.
The backends are triggered via session D-Bus and always run as the same user as the calling print dialog, so they do not introduce additional security problems.
The separation of the communication with individual print technologies makes this code only be needed once (in the appropriate backend) instead of in each print dialog. This simplifies the security maintenance.
[Quality assurance]
- The Ubuntu Printing Team is subscribed.
https://bugs.launchpad.net/ubuntu/+source/cpdb-libs
https://github.com/OpenPrinting/cpdb-libs/issues
No upstream tests or autopkgtests.
[Dependencies]
CUPS, libcupsfilters, Glib, D-Bus -> all in main.
[Standards compliance]
The package meets the FHS and Debian Policy standards (4.1.0)
[Maintenance]
- Actively developed upstream. Last release was 2.0b1
https://github.com/OpenPrinting/cpdb-libs/commits/master |
|
| 2023-01-16 16:18:59 |
Till Kamppeter |
description |
[Availability]
The package cpdb-libs is already in Ubuntu universe.
The package cpdb-libs build for the architectures it is designed to work on.
It currently builds and works for architetcures: amd64, arm64, armhf, ppc64el, riscv64, s390x
Link to package [[https://launchpad.net/ubuntu/+source/cpdb-libs|cpdb-libs]]
[Rationale]
The Common Printing Dialog Backends (CPDB) project of OpenPrinting is about separating the print dialogs of different GUI toolkits and applications (GTK, Qt, Firefox, Chromium, LibreOffice, ...) from the different print technologies (CUPS, print to file, cloud printing services, ...) so that they can get developed independently and so always from all applications one can print with all print technologies and changes in the print technologies get supported quickly.
If one opens the print dialog, the dialog will not talk directly to CUPS, a cloud printing service, or any other printing system. For this communication there are the backends. The dialog will find all available backends and sends commands to them, for listing all available printers, giving property/option lists for the selected printers, and printing on the selected printer. This communication is done via D-Bus. So the backends are easily exchangeable and for getting support for a new print technology only its backend needs to get added.
Backends can even be packaged as Snaps, because they communicate only by D-Bus with the frontend, so a cloud printing provider could put their backend into the Snap Store.
All packages providing a print dialog will get modified (upstream) to support CPDB with this library and then these packages will depend on cpdb-libs.
These packages are:
- GUI toolkits: GTK, Qt
- GUI applications with their own print dialogs: Firefox/Thunderbird,
Chromium/Chrome, LibreOffice, ...
The coding of the CPDB support in GTK and Qt got already done in GSoC 2022 and currently merge requests are worked on to be included upstream. Once they are upstream (and already before the next upstream releases) they will get added to Ubuntu as distro patches.
See
https://github.com/TinyTrebuchet/gsoc22/
RULE: There must be a certain level of demand for the package
TODO: - The package TBDSRC is required in Ubuntu main for TBD
TODO-A: - The package TBDSRC will generally be useful for a large part of
TODO-A: our user base
TODO-B: - The package TBDSRC will not generally be useful for a large part of
TODO-B: our user base, but is important/helpful still because TBD
TODO: - Additional reasons TBD
TODO: - Additionally new use-cases enabled by this are TBD
TODO: - Package TBDSRC covers the same use case as TBD, but is better
TODO: because TBD, thereby we want to replace it.
TODO: - The package TBDSRC is a new runtime dependency of package TBD that
TODO: we already support
RULE: Reviews will take some time. Also the potential extra work out of review
RULE: feedback from either MIR-team and/or security-team will take time.
RULE: For better priorization it is quite helpful to clearly state the
RULE: target release and set a milestone to the bug task.
RULE: When doing so do not describe what you "wish" or "would like to have".
RULE: Only milestones that are sufficiently well-founded and related to
RULE: major releases will be considered
TODO-A: - The package TBDSRC is required in Ubuntu main no later than TBD
TODO-A: due to TBD
TODO-B: - It would be great and useful to community/processes to have the
TODO-B: package TBD in Ubuntu main, but there is no definitive deadline.
[Security]
RULE: The security history and the current state of security issues in the
RULE: package must allow us to support the package for at least 9 months (120
RULE: for LTS+ESM support) without exposing its users to an inappropriate level
RULE: of security risks. This requires checking of several things:
RULE: - Search in the National Vulnerability Database using the PKG as keyword
RULE: http://cve.mitre.org/cve/search_cve_list.html
RULE: - check OSS security mailing list (feed into search engine
RULE: 'site:www.openwall.com/lists/oss-security <pkgname>')
RULE: - Ubuntu CVE Tracker: https://ubuntu.com/security/cve?package=<source-package-name>
TODO-A: - Had #TBD security issues in the past
TODO-A: - TBD links to such security issues in trackers
TODO-A: - TBD to any context that shows how these issues got handled in
TODO-A: the past
TODO-B: - No CVEs/security issues in this software in the past
RULE: - Check for security relevant binaries and behavior.
RULE: If any are present, this requires a more in-depth security review.
TODO: - no `suid` or `sgid` binaries
TODO-A: - no executables in `/sbin` and `/usr/sbin`
TODO-B: - Binary TBD in sbin is no problem because TBD
TODO-A: - Package does not install services, timers or recurring jobs
TODO-B: - Package does install services, timers or recurring jobs
TODO-B: TBD (list services, timers, jobs)
TODO-C: - Package does install services, timers or recurring jobs
TODO-C: TBD (list services, timers, jobs)
TODO-C: Those have the following security features: TBD (add details like
TODO-C: reduced permissions, temp envronment, restricted users/groups,
TODO-C: seccomp, apparmor, ...)
TODO: - Packages does not open privileged ports (ports < 1024)
TODO: - Packages does not contain extensions to security-sensitive software
TODO: (filters, scanners, plugins, UI skins, ...)
[Quality assurance - function/usage]
RULE: - After installing the package it must be possible to make it working with
RULE: a reasonable effort of configuration and documentation reading.
TODO-A: - The package works well right after install
TODO-B: - The package needs post install configuration or reading of
TODO-B: documentation, there isn't a safe default because TBD
[Quality assurance - maintenance]
RULE: - To support a package, we must be reasonably convinced that upstream
RULE: supports and cares for the package.
RULE: - The status of important bugs in Debian, Ubuntu and upstream's bug
RULE: tracking systems must be evaluated. Important bugs must be pointed out
RULE: and discussed in the MIR report.
TODO: - The package is maintained well in Debian/Ubuntu and has not too many
TODO: and long term critical bugs open
TODO: - Ubuntu https://bugs.launchpad.net/ubuntu/+source/TBDSRC/+bug
TODO: - Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=TBDSRC
TODO: - The package has important open bugs, listing them: TBD
TODO-A: - The package does not deal with exotic hardware we cannot support
TODO-B: - The package does deal with exotic hardware, it is present at TBD
TODO-B: to be able to test, fix and verify bugs
[Quality assurance - testing]
RULE: - The package must include a non-trivial test suite
RULE: - it should run at package build and fail the build if broken
TODO-A: - The package runs a test suite on build time, if it fails
TODO-A: it makes the build fail, link to build log TBD
TODO-B: - The package does not run a test at build time because TBD
RULE: - The package should, but is not required to, also contain
RULE: non-trivial autopkgtest(s).
TODO-A: - The package runs an autopkgtest, and is currently passing on
TODO-A: this TBD list of architectures, link to test logs TBD
TODO-B: - The package does not run an autopkgtest because TBD
RULE: - existing but failing tests that shall be handled as "ok to fail"
RULE: need to be explained along the test logs below
TODO-A: - The package does have not failing autopkgtests right now
TODO-B: - The package does have failing autopkgtests tests right now, but since
TODO-B: they always failed they are handled as "ignored failure", this is
TODO-B: ok because TBD
RULE: - If no build tests nor autopkgtests are included, and/or if the package
RULE: requires specific hardware to perform testing, the subscribed team
RULE: must provide a written test plan in a comment to the MIR bug, and
RULE: commit to running that test either at each upload of the package or
RULE: at least once each release cycle. In the comment to the MIR bug,
RULE: please link to the codebase of these tests (scripts or doc of manual
RULE: steps) and attach a full log of these test runs. This is meant to
RULE: assess their validity (e.g. not just superficial)
TODO: - The package can not be tested at build or autopktest time because TBD
TODO: to make up for that here TBD is a test plan/automation and example
TODO: test TBD (logs/scripts)
RULE: - In some cases a solution that is about to be promoted consists of
RULE: several very small libraries and one actual application uniting them
RULE: to achieve something useful. This is rather common in the go/rust space.
RULE: In that case often these micro-libs on their own can and should only
RULE: provide low level unit-tests. But more complex autopkgtests make no
RULE: sense on that level. Therefore in those cases one might want to test on
RULE: the solution level.
RULE: - Process wise MIR-requesting teams can ask (on the bug) for this
RULE: special case to apply for a given case, which reduces the test
RULE: constraints on the micro libraries but in return increases the
RULE: requirements for the test of the actual app/solution.
RULE: - Since this might promote micro-lib packages to main with less than
RULE: the common level of QA any further MIRed program using them will have
RULE: to provide the same amount of increased testing.
TODO: - This package is minimal and will be tested in a more wide reaching
TODO: solution context TBD, details about this testing are here TBD
[Quality assurance - packaging]
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 d/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-B: 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: - [[https://refspecs.linuxfoundation.org/fhs.shtml|FHS]]
RULE: - [[http://www.debian.org/doc/debian-policy/|Debian Policy]]
TODO-A: - This package correctly follows FHS and Debian Policy
TODO-B: - This package violates FHS or Debian Polciy, 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, which is set as a package bug contact. This is not a
RULE: requirement for the MIR team ACK, but for the package to be promoted
RULE: by an archive admin. Still, it is strongly suggested to subscribe,
RULE: as the owning team will get a preview of the to-be-expected incoming
RULE: 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: - Owning Team will be TBD
TODO-A: - Team is already subscribed to the package
TODO-B: - Team is not yet, but will subscribe to 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: - 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 ecosytem 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: - Right now that tooling to get a Cargo.lock that will include internal
RULE: vendored dependencies isn't in place yet (expect a dh-cargo change
RULE: later). Until it is available, as a fallback one can scan the
RULE: directory at build time and let it be generated in debian/rules.
RULE: An example might look like:
RULE: d/rules:
RULE: override_dh_auto_test:
RULE: CARGO_HOME=debian /usr/share/cargo/bin/cargo test --offline
RULE: d/<pkg>.install:
RULE: Cargo.lock /usr/share/doc/<pkg>
RULE: d/config.toml
RULE: # Use the vendorized sources to produce the Cargo.lock file. This
RULE: # can be performed by pointing $CARGO_HOME to the path containing
RULE: # this file.
RULE: [source]
RULE: [source.my-vendor-source]
RULE: directory = "vendor"
RULE: [source.crates-io]
RULE: replace-with = "my-vendor-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 shiped 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: - if there has been an archive test rebuild that has occurred more recently
RULE: than the last upload, the package must have rebuilt successfully
TODO-A: - The package has been built in the archive more recently than the last
TODO-A: test rebuild
TODO-B: - The package successfully built during the most recent test rebuild
TODO-C: - The package was test rebuilt in PPA or sbuild recently (provide link/logs)
[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
============================================================
Original, old-generation MIR description
[Availability]
Already in universe
Built for all supported architectures
[Rationale]
The Common Printing Dialog Backends (CPDB) project of OpenPrinting is about separating the print dialogs of different GUI toolkits and applications (GTK, Qt, Firefox, Chromium, LibreOffice, ...) from the different print technologies (CUPS, print to file, cloud printing services, ...) so that they can get developed independently and so always from all applications one can print with all print technologies and changes in the print technologies get supported quickly.
If one opens the print dialog, the dialog will not talk directly to CUPS, a cloud printing service, or any other printing system. For this communication there are the backends. The dialog will find all available backends and sends commands to them, for listing all available printers, giving property/option lists for the selected printers, and printing on the selected printer. This communication is done via D-Bus. So the backends are easily exchangeable and for getting support for a new print technology only its backend needs to get added.
Backends can even be packaged as Snaps, because they communicate only by D-Bus with the frontend, so a cloud printing provider could put their backend into the Snap Store.
[Security]
No known security issues, no CVEs for cpdb-libs known.
The backends are triggered via session D-Bus and always run as the same user as the calling print dialog, so they do not introduce additional security problems.
The separation of the communication with individual print technologies makes this code only be needed once (in the appropriate backend) instead of in each print dialog. This simplifies the security maintenance.
[Quality assurance]
- The Ubuntu Printing Team is subscribed.
https://bugs.launchpad.net/ubuntu/+source/cpdb-libs
https://github.com/OpenPrinting/cpdb-libs/issues
No upstream tests or autopkgtests.
[Dependencies]
CUPS, libcupsfilters, Glib, D-Bus -> all in main.
[Standards compliance]
The package meets the FHS and Debian Policy standards (4.1.0)
[Maintenance]
- Actively developed upstream. Last release was 2.0b1
https://github.com/OpenPrinting/cpdb-libs/commits/master |
[Availability]
The package cpdb-libs is already in Ubuntu universe.
The package cpdb-libs build for the architectures it is designed to work on.
It currently builds and works for architetcures: amd64, arm64, armhf, ppc64el, riscv64, s390x
Link to package [[https://launchpad.net/ubuntu/+source/cpdb-libs|cpdb-libs]]
[Rationale]
The Common Printing Dialog Backends (CPDB) project of OpenPrinting is about separating the print dialogs of different GUI toolkits and applications (GTK, Qt, Firefox, Chromium, LibreOffice, ...) from the different print technologies (CUPS, print to file, cloud printing services, ...) so that they can get developed independently and so always from all applications one can print with all print technologies and changes in the print technologies get supported quickly.
If one opens the print dialog, the dialog will not talk directly to CUPS, a cloud printing service, or any other printing system. For this communication there are the backends. The dialog will find all available backends and sends commands to them, for listing all available printers, giving property/option lists for the selected printers, and printing on the selected printer. This communication is done via D-Bus. So the backends are easily exchangeable and for getting support for a new print technology only its backend needs to get added.
Backends can even be packaged as Snaps, because they communicate only by D-Bus with the frontend, so a cloud printing provider could put their backend into the Snap Store.
All packages providing a print dialog will get modified (upstream) to support CPDB with this library and then these packages will depend on cpdb-libs.
These packages are:
- GUI toolkits: GTK, Qt
- GUI applications with their own print dialogs: Firefox/Thunderbird,
Chromium/Chrome, LibreOffice, ...
The coding of the CPDB support in GTK and Qt got already done in GSoC 2022 and currently merge requests are worked on to be included upstream. Once they are upstream (and already before the next upstream releases) they will get added to Ubuntu as distro patches.
See
https://github.com/TinyTrebuchet/gsoc22/
The dialogs of the browsers and LibreOffice will be worked on in GSoC 2023:
https://wiki.linuxfoundation.org/gsoc/google-summer-code-2023-openprinting-projects#cpdb_support_for_application_s_print_dialogsfirefox_chromium_libreoffice
This is also needed for the upcoming New Architecture of printing, where we go all-IPP and do not use PPD files any more. The CUPS backend for the CPDB (cpdb-backend-cups) is already designed to not handle PPD files any more.
The New Architecture is introduced as standard part of the distro in Ubuntu 23.10 at the latest. Therefore cpdb-libs NEEDS to be in main before Feature Freeze 23.10, ideally some weeks before.
There are very good chances that the changes on GTK and Qt already land in 23.04. In this case we need cpdb-libs in Main already by Feature Freeze of 23.04. This way the CPDB-based print dilaog will be tested more before the switchover into the New Architecture will take place.
[Security]
RULE: The security history and the current state of security issues in the
RULE: package must allow us to support the package for at least 9 months (120
RULE: for LTS+ESM support) without exposing its users to an inappropriate level
RULE: of security risks. This requires checking of several things:
RULE: - Search in the National Vulnerability Database using the PKG as keyword
RULE: http://cve.mitre.org/cve/search_cve_list.html
RULE: - check OSS security mailing list (feed into search engine
RULE: 'site:www.openwall.com/lists/oss-security <pkgname>')
RULE: - Ubuntu CVE Tracker: https://ubuntu.com/security/cve?package=<source-package-name>
TODO-A: - Had #TBD security issues in the past
TODO-A: - TBD links to such security issues in trackers
TODO-A: - TBD to any context that shows how these issues got handled in
TODO-A: the past
TODO-B: - No CVEs/security issues in this software in the past
RULE: - Check for security relevant binaries and behavior.
RULE: If any are present, this requires a more in-depth security review.
TODO: - no `suid` or `sgid` binaries
TODO-A: - no executables in `/sbin` and `/usr/sbin`
TODO-B: - Binary TBD in sbin is no problem because TBD
TODO-A: - Package does not install services, timers or recurring jobs
TODO-B: - Package does install services, timers or recurring jobs
TODO-B: TBD (list services, timers, jobs)
TODO-C: - Package does install services, timers or recurring jobs
TODO-C: TBD (list services, timers, jobs)
TODO-C: Those have the following security features: TBD (add details like
TODO-C: reduced permissions, temp envronment, restricted users/groups,
TODO-C: seccomp, apparmor, ...)
TODO: - Packages does not open privileged ports (ports < 1024)
TODO: - Packages does not contain extensions to security-sensitive software
TODO: (filters, scanners, plugins, UI skins, ...)
[Quality assurance - function/usage]
RULE: - After installing the package it must be possible to make it working with
RULE: a reasonable effort of configuration and documentation reading.
TODO-A: - The package works well right after install
TODO-B: - The package needs post install configuration or reading of
TODO-B: documentation, there isn't a safe default because TBD
[Quality assurance - maintenance]
RULE: - To support a package, we must be reasonably convinced that upstream
RULE: supports and cares for the package.
RULE: - The status of important bugs in Debian, Ubuntu and upstream's bug
RULE: tracking systems must be evaluated. Important bugs must be pointed out
RULE: and discussed in the MIR report.
TODO: - The package is maintained well in Debian/Ubuntu and has not too many
TODO: and long term critical bugs open
TODO: - Ubuntu https://bugs.launchpad.net/ubuntu/+source/TBDSRC/+bug
TODO: - Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=TBDSRC
TODO: - The package has important open bugs, listing them: TBD
TODO-A: - The package does not deal with exotic hardware we cannot support
TODO-B: - The package does deal with exotic hardware, it is present at TBD
TODO-B: to be able to test, fix and verify bugs
[Quality assurance - testing]
RULE: - The package must include a non-trivial test suite
RULE: - it should run at package build and fail the build if broken
TODO-A: - The package runs a test suite on build time, if it fails
TODO-A: it makes the build fail, link to build log TBD
TODO-B: - The package does not run a test at build time because TBD
RULE: - The package should, but is not required to, also contain
RULE: non-trivial autopkgtest(s).
TODO-A: - The package runs an autopkgtest, and is currently passing on
TODO-A: this TBD list of architectures, link to test logs TBD
TODO-B: - The package does not run an autopkgtest because TBD
RULE: - existing but failing tests that shall be handled as "ok to fail"
RULE: need to be explained along the test logs below
TODO-A: - The package does have not failing autopkgtests right now
TODO-B: - The package does have failing autopkgtests tests right now, but since
TODO-B: they always failed they are handled as "ignored failure", this is
TODO-B: ok because TBD
RULE: - If no build tests nor autopkgtests are included, and/or if the package
RULE: requires specific hardware to perform testing, the subscribed team
RULE: must provide a written test plan in a comment to the MIR bug, and
RULE: commit to running that test either at each upload of the package or
RULE: at least once each release cycle. In the comment to the MIR bug,
RULE: please link to the codebase of these tests (scripts or doc of manual
RULE: steps) and attach a full log of these test runs. This is meant to
RULE: assess their validity (e.g. not just superficial)
TODO: - The package can not be tested at build or autopktest time because TBD
TODO: to make up for that here TBD is a test plan/automation and example
TODO: test TBD (logs/scripts)
RULE: - In some cases a solution that is about to be promoted consists of
RULE: several very small libraries and one actual application uniting them
RULE: to achieve something useful. This is rather common in the go/rust space.
RULE: In that case often these micro-libs on their own can and should only
RULE: provide low level unit-tests. But more complex autopkgtests make no
RULE: sense on that level. Therefore in those cases one might want to test on
RULE: the solution level.
RULE: - Process wise MIR-requesting teams can ask (on the bug) for this
RULE: special case to apply for a given case, which reduces the test
RULE: constraints on the micro libraries but in return increases the
RULE: requirements for the test of the actual app/solution.
RULE: - Since this might promote micro-lib packages to main with less than
RULE: the common level of QA any further MIRed program using them will have
RULE: to provide the same amount of increased testing.
TODO: - This package is minimal and will be tested in a more wide reaching
TODO: solution context TBD, details about this testing are here TBD
[Quality assurance - packaging]
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 d/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-B: 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: - [[https://refspecs.linuxfoundation.org/fhs.shtml|FHS]]
RULE: - [[http://www.debian.org/doc/debian-policy/|Debian Policy]]
TODO-A: - This package correctly follows FHS and Debian Policy
TODO-B: - This package violates FHS or Debian Polciy, 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, which is set as a package bug contact. This is not a
RULE: requirement for the MIR team ACK, but for the package to be promoted
RULE: by an archive admin. Still, it is strongly suggested to subscribe,
RULE: as the owning team will get a preview of the to-be-expected incoming
RULE: 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: - Owning Team will be TBD
TODO-A: - Team is already subscribed to the package
TODO-B: - Team is not yet, but will subscribe to 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: - 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 ecosytem 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: - Right now that tooling to get a Cargo.lock that will include internal
RULE: vendored dependencies isn't in place yet (expect a dh-cargo change
RULE: later). Until it is available, as a fallback one can scan the
RULE: directory at build time and let it be generated in debian/rules.
RULE: An example might look like:
RULE: d/rules:
RULE: override_dh_auto_test:
RULE: CARGO_HOME=debian /usr/share/cargo/bin/cargo test --offline
RULE: d/<pkg>.install:
RULE: Cargo.lock /usr/share/doc/<pkg>
RULE: d/config.toml
RULE: # Use the vendorized sources to produce the Cargo.lock file. This
RULE: # can be performed by pointing $CARGO_HOME to the path containing
RULE: # this file.
RULE: [source]
RULE: [source.my-vendor-source]
RULE: directory = "vendor"
RULE: [source.crates-io]
RULE: replace-with = "my-vendor-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 shiped 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: - if there has been an archive test rebuild that has occurred more recently
RULE: than the last upload, the package must have rebuilt successfully
TODO-A: - The package has been built in the archive more recently than the last
TODO-A: test rebuild
TODO-B: - The package successfully built during the most recent test rebuild
TODO-C: - The package was test rebuilt in PPA or sbuild recently (provide link/logs)
[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
============================================================
Original, old-generation MIR description
[Availability]
Already in universe
Built for all supported architectures
[Rationale]
The Common Printing Dialog Backends (CPDB) project of OpenPrinting is about separating the print dialogs of different GUI toolkits and applications (GTK, Qt, Firefox, Chromium, LibreOffice, ...) from the different print technologies (CUPS, print to file, cloud printing services, ...) so that they can get developed independently and so always from all applications one can print with all print technologies and changes in the print technologies get supported quickly.
If one opens the print dialog, the dialog will not talk directly to CUPS, a cloud printing service, or any other printing system. For this communication there are the backends. The dialog will find all available backends and sends commands to them, for listing all available printers, giving property/option lists for the selected printers, and printing on the selected printer. This communication is done via D-Bus. So the backends are easily exchangeable and for getting support for a new print technology only its backend needs to get added.
Backends can even be packaged as Snaps, because they communicate only by D-Bus with the frontend, so a cloud printing provider could put their backend into the Snap Store.
[Security]
No known security issues, no CVEs for cpdb-libs known.
The backends are triggered via session D-Bus and always run as the same user as the calling print dialog, so they do not introduce additional security problems.
The separation of the communication with individual print technologies makes this code only be needed once (in the appropriate backend) instead of in each print dialog. This simplifies the security maintenance.
[Quality assurance]
- The Ubuntu Printing Team is subscribed.
https://bugs.launchpad.net/ubuntu/+source/cpdb-libs
https://github.com/OpenPrinting/cpdb-libs/issues
No upstream tests or autopkgtests.
[Dependencies]
CUPS, libcupsfilters, Glib, D-Bus -> all in main.
[Standards compliance]
The package meets the FHS and Debian Policy standards (4.1.0)
[Maintenance]
- Actively developed upstream. Last release was 2.0b1
https://github.com/OpenPrinting/cpdb-libs/commits/master |
|
| 2023-01-16 16:43:40 |
Till Kamppeter |
description |
[Availability]
The package cpdb-libs is already in Ubuntu universe.
The package cpdb-libs build for the architectures it is designed to work on.
It currently builds and works for architetcures: amd64, arm64, armhf, ppc64el, riscv64, s390x
Link to package [[https://launchpad.net/ubuntu/+source/cpdb-libs|cpdb-libs]]
[Rationale]
The Common Printing Dialog Backends (CPDB) project of OpenPrinting is about separating the print dialogs of different GUI toolkits and applications (GTK, Qt, Firefox, Chromium, LibreOffice, ...) from the different print technologies (CUPS, print to file, cloud printing services, ...) so that they can get developed independently and so always from all applications one can print with all print technologies and changes in the print technologies get supported quickly.
If one opens the print dialog, the dialog will not talk directly to CUPS, a cloud printing service, or any other printing system. For this communication there are the backends. The dialog will find all available backends and sends commands to them, for listing all available printers, giving property/option lists for the selected printers, and printing on the selected printer. This communication is done via D-Bus. So the backends are easily exchangeable and for getting support for a new print technology only its backend needs to get added.
Backends can even be packaged as Snaps, because they communicate only by D-Bus with the frontend, so a cloud printing provider could put their backend into the Snap Store.
All packages providing a print dialog will get modified (upstream) to support CPDB with this library and then these packages will depend on cpdb-libs.
These packages are:
- GUI toolkits: GTK, Qt
- GUI applications with their own print dialogs: Firefox/Thunderbird,
Chromium/Chrome, LibreOffice, ...
The coding of the CPDB support in GTK and Qt got already done in GSoC 2022 and currently merge requests are worked on to be included upstream. Once they are upstream (and already before the next upstream releases) they will get added to Ubuntu as distro patches.
See
https://github.com/TinyTrebuchet/gsoc22/
The dialogs of the browsers and LibreOffice will be worked on in GSoC 2023:
https://wiki.linuxfoundation.org/gsoc/google-summer-code-2023-openprinting-projects#cpdb_support_for_application_s_print_dialogsfirefox_chromium_libreoffice
This is also needed for the upcoming New Architecture of printing, where we go all-IPP and do not use PPD files any more. The CUPS backend for the CPDB (cpdb-backend-cups) is already designed to not handle PPD files any more.
The New Architecture is introduced as standard part of the distro in Ubuntu 23.10 at the latest. Therefore cpdb-libs NEEDS to be in main before Feature Freeze 23.10, ideally some weeks before.
There are very good chances that the changes on GTK and Qt already land in 23.04. In this case we need cpdb-libs in Main already by Feature Freeze of 23.04. This way the CPDB-based print dilaog will be tested more before the switchover into the New Architecture will take place.
[Security]
RULE: The security history and the current state of security issues in the
RULE: package must allow us to support the package for at least 9 months (120
RULE: for LTS+ESM support) without exposing its users to an inappropriate level
RULE: of security risks. This requires checking of several things:
RULE: - Search in the National Vulnerability Database using the PKG as keyword
RULE: http://cve.mitre.org/cve/search_cve_list.html
RULE: - check OSS security mailing list (feed into search engine
RULE: 'site:www.openwall.com/lists/oss-security <pkgname>')
RULE: - Ubuntu CVE Tracker: https://ubuntu.com/security/cve?package=<source-package-name>
TODO-A: - Had #TBD security issues in the past
TODO-A: - TBD links to such security issues in trackers
TODO-A: - TBD to any context that shows how these issues got handled in
TODO-A: the past
TODO-B: - No CVEs/security issues in this software in the past
RULE: - Check for security relevant binaries and behavior.
RULE: If any are present, this requires a more in-depth security review.
TODO: - no `suid` or `sgid` binaries
TODO-A: - no executables in `/sbin` and `/usr/sbin`
TODO-B: - Binary TBD in sbin is no problem because TBD
TODO-A: - Package does not install services, timers or recurring jobs
TODO-B: - Package does install services, timers or recurring jobs
TODO-B: TBD (list services, timers, jobs)
TODO-C: - Package does install services, timers or recurring jobs
TODO-C: TBD (list services, timers, jobs)
TODO-C: Those have the following security features: TBD (add details like
TODO-C: reduced permissions, temp envronment, restricted users/groups,
TODO-C: seccomp, apparmor, ...)
TODO: - Packages does not open privileged ports (ports < 1024)
TODO: - Packages does not contain extensions to security-sensitive software
TODO: (filters, scanners, plugins, UI skins, ...)
[Quality assurance - function/usage]
RULE: - After installing the package it must be possible to make it working with
RULE: a reasonable effort of configuration and documentation reading.
TODO-A: - The package works well right after install
TODO-B: - The package needs post install configuration or reading of
TODO-B: documentation, there isn't a safe default because TBD
[Quality assurance - maintenance]
RULE: - To support a package, we must be reasonably convinced that upstream
RULE: supports and cares for the package.
RULE: - The status of important bugs in Debian, Ubuntu and upstream's bug
RULE: tracking systems must be evaluated. Important bugs must be pointed out
RULE: and discussed in the MIR report.
TODO: - The package is maintained well in Debian/Ubuntu and has not too many
TODO: and long term critical bugs open
TODO: - Ubuntu https://bugs.launchpad.net/ubuntu/+source/TBDSRC/+bug
TODO: - Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=TBDSRC
TODO: - The package has important open bugs, listing them: TBD
TODO-A: - The package does not deal with exotic hardware we cannot support
TODO-B: - The package does deal with exotic hardware, it is present at TBD
TODO-B: to be able to test, fix and verify bugs
[Quality assurance - testing]
RULE: - The package must include a non-trivial test suite
RULE: - it should run at package build and fail the build if broken
TODO-A: - The package runs a test suite on build time, if it fails
TODO-A: it makes the build fail, link to build log TBD
TODO-B: - The package does not run a test at build time because TBD
RULE: - The package should, but is not required to, also contain
RULE: non-trivial autopkgtest(s).
TODO-A: - The package runs an autopkgtest, and is currently passing on
TODO-A: this TBD list of architectures, link to test logs TBD
TODO-B: - The package does not run an autopkgtest because TBD
RULE: - existing but failing tests that shall be handled as "ok to fail"
RULE: need to be explained along the test logs below
TODO-A: - The package does have not failing autopkgtests right now
TODO-B: - The package does have failing autopkgtests tests right now, but since
TODO-B: they always failed they are handled as "ignored failure", this is
TODO-B: ok because TBD
RULE: - If no build tests nor autopkgtests are included, and/or if the package
RULE: requires specific hardware to perform testing, the subscribed team
RULE: must provide a written test plan in a comment to the MIR bug, and
RULE: commit to running that test either at each upload of the package or
RULE: at least once each release cycle. In the comment to the MIR bug,
RULE: please link to the codebase of these tests (scripts or doc of manual
RULE: steps) and attach a full log of these test runs. This is meant to
RULE: assess their validity (e.g. not just superficial)
TODO: - The package can not be tested at build or autopktest time because TBD
TODO: to make up for that here TBD is a test plan/automation and example
TODO: test TBD (logs/scripts)
RULE: - In some cases a solution that is about to be promoted consists of
RULE: several very small libraries and one actual application uniting them
RULE: to achieve something useful. This is rather common in the go/rust space.
RULE: In that case often these micro-libs on their own can and should only
RULE: provide low level unit-tests. But more complex autopkgtests make no
RULE: sense on that level. Therefore in those cases one might want to test on
RULE: the solution level.
RULE: - Process wise MIR-requesting teams can ask (on the bug) for this
RULE: special case to apply for a given case, which reduces the test
RULE: constraints on the micro libraries but in return increases the
RULE: requirements for the test of the actual app/solution.
RULE: - Since this might promote micro-lib packages to main with less than
RULE: the common level of QA any further MIRed program using them will have
RULE: to provide the same amount of increased testing.
TODO: - This package is minimal and will be tested in a more wide reaching
TODO: solution context TBD, details about this testing are here TBD
[Quality assurance - packaging]
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 d/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-B: 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: - [[https://refspecs.linuxfoundation.org/fhs.shtml|FHS]]
RULE: - [[http://www.debian.org/doc/debian-policy/|Debian Policy]]
TODO-A: - This package correctly follows FHS and Debian Policy
TODO-B: - This package violates FHS or Debian Polciy, 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, which is set as a package bug contact. This is not a
RULE: requirement for the MIR team ACK, but for the package to be promoted
RULE: by an archive admin. Still, it is strongly suggested to subscribe,
RULE: as the owning team will get a preview of the to-be-expected incoming
RULE: 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: - Owning Team will be TBD
TODO-A: - Team is already subscribed to the package
TODO-B: - Team is not yet, but will subscribe to 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: - 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 ecosytem 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: - Right now that tooling to get a Cargo.lock that will include internal
RULE: vendored dependencies isn't in place yet (expect a dh-cargo change
RULE: later). Until it is available, as a fallback one can scan the
RULE: directory at build time and let it be generated in debian/rules.
RULE: An example might look like:
RULE: d/rules:
RULE: override_dh_auto_test:
RULE: CARGO_HOME=debian /usr/share/cargo/bin/cargo test --offline
RULE: d/<pkg>.install:
RULE: Cargo.lock /usr/share/doc/<pkg>
RULE: d/config.toml
RULE: # Use the vendorized sources to produce the Cargo.lock file. This
RULE: # can be performed by pointing $CARGO_HOME to the path containing
RULE: # this file.
RULE: [source]
RULE: [source.my-vendor-source]
RULE: directory = "vendor"
RULE: [source.crates-io]
RULE: replace-with = "my-vendor-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 shiped 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: - if there has been an archive test rebuild that has occurred more recently
RULE: than the last upload, the package must have rebuilt successfully
TODO-A: - The package has been built in the archive more recently than the last
TODO-A: test rebuild
TODO-B: - The package successfully built during the most recent test rebuild
TODO-C: - The package was test rebuilt in PPA or sbuild recently (provide link/logs)
[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
============================================================
Original, old-generation MIR description
[Availability]
Already in universe
Built for all supported architectures
[Rationale]
The Common Printing Dialog Backends (CPDB) project of OpenPrinting is about separating the print dialogs of different GUI toolkits and applications (GTK, Qt, Firefox, Chromium, LibreOffice, ...) from the different print technologies (CUPS, print to file, cloud printing services, ...) so that they can get developed independently and so always from all applications one can print with all print technologies and changes in the print technologies get supported quickly.
If one opens the print dialog, the dialog will not talk directly to CUPS, a cloud printing service, or any other printing system. For this communication there are the backends. The dialog will find all available backends and sends commands to them, for listing all available printers, giving property/option lists for the selected printers, and printing on the selected printer. This communication is done via D-Bus. So the backends are easily exchangeable and for getting support for a new print technology only its backend needs to get added.
Backends can even be packaged as Snaps, because they communicate only by D-Bus with the frontend, so a cloud printing provider could put their backend into the Snap Store.
[Security]
No known security issues, no CVEs for cpdb-libs known.
The backends are triggered via session D-Bus and always run as the same user as the calling print dialog, so they do not introduce additional security problems.
The separation of the communication with individual print technologies makes this code only be needed once (in the appropriate backend) instead of in each print dialog. This simplifies the security maintenance.
[Quality assurance]
- The Ubuntu Printing Team is subscribed.
https://bugs.launchpad.net/ubuntu/+source/cpdb-libs
https://github.com/OpenPrinting/cpdb-libs/issues
No upstream tests or autopkgtests.
[Dependencies]
CUPS, libcupsfilters, Glib, D-Bus -> all in main.
[Standards compliance]
The package meets the FHS and Debian Policy standards (4.1.0)
[Maintenance]
- Actively developed upstream. Last release was 2.0b1
https://github.com/OpenPrinting/cpdb-libs/commits/master |
[Availability]
The package cpdb-libs is already in Ubuntu universe.
The package cpdb-libs build for the architectures it is designed to work on.
It currently builds and works for architetcures: amd64, arm64, armhf, ppc64el, riscv64, s390x
Link to package https://launchpad.net/ubuntu/+source/cpdb-libs
[Rationale]
The Common Printing Dialog Backends (CPDB) project of OpenPrinting is about separating the print dialogs of different GUI toolkits and applications (GTK, Qt, Firefox, Chromium, LibreOffice, ...) from the different print technologies (CUPS, print to file, cloud printing services, ...) so that they can get developed independently and so always from all applications one can print with all print technologies and changes in the print technologies get supported quickly.
If one opens the print dialog, the dialog will not talk directly to CUPS, a cloud printing service, or any other printing system. For this communication there are the backends. The dialog will find all available backends and sends commands to them, for listing all available printers, giving property/option lists for the selected printers, and printing on the selected printer. This communication is done via D-Bus. So the backends are easily exchangeable and for getting support for a new print technology only its backend needs to get added.
Backends can even be packaged as Snaps, because they communicate only by D-Bus with the frontend, so a cloud printing provider could put their backend into the Snap Store.
All packages providing a print dialog will get modified (upstream) to support CPDB with this library and then these packages will depend on cpdb-libs.
These packages are:
- GUI toolkits: GTK, Qt
- GUI applications with their own print dialogs: Firefox/Thunderbird,
Chromium/Chrome, LibreOffice, ...
The coding of the CPDB support in GTK and Qt got already done in GSoC 2022 and currently merge requests are worked on to be included upstream. Once they are upstream (and already before the next upstream releases) they will get added to Ubuntu as distro patches.
See
https://github.com/TinyTrebuchet/gsoc22/
The dialogs of the browsers and LibreOffice will be worked on in GSoC 2023:
https://wiki.linuxfoundation.org/gsoc/google-summer-code-2023-openprinting-projects#cpdb_support_for_application_s_print_dialogsfirefox_chromium_libreoffice
This is also needed for the upcoming New Architecture of printing, where we go all-IPP and do not use PPD files any more. The CUPS backend for the CPDB (cpdb-backend-cups) is already designed to not handle PPD files any more.
The New Architecture is introduced as standard part of the distro in Ubuntu 23.10 at the latest. Therefore cpdb-libs NEEDS to be in main before Feature Freeze 23.10, ideally some weeks before.
There are very good chances that the changes on GTK and Qt already land in 23.04. In this case we need cpdb-libs in Main already by Feature Freeze of 23.04. This way the CPDB-based print dilaog will be tested more before the switchover into the New Architecture will take place.
[Security]
RULE: The security history and the current state of security issues in the
RULE: package must allow us to support the package for at least 9 months (120
RULE: for LTS+ESM support) without exposing its users to an inappropriate level
RULE: of security risks. This requires checking of several things:
RULE: - Search in the National Vulnerability Database using the PKG as keyword
RULE: http://cve.mitre.org/cve/search_cve_list.html
RULE: - check OSS security mailing list (feed into search engine
RULE: 'site:www.openwall.com/lists/oss-security <pkgname>')
RULE: - Ubuntu CVE Tracker: https://ubuntu.com/security/cve?package=<source-package-name>
TODO-A: - Had #TBD security issues in the past
TODO-A: - TBD links to such security issues in trackers
TODO-A: - TBD to any context that shows how these issues got handled in
TODO-A: the past
TODO-B: - No CVEs/security issues in this software in the past
RULE: - Check for security relevant binaries and behavior.
RULE: If any are present, this requires a more in-depth security review.
TODO: - no `suid` or `sgid` binaries
TODO-A: - no executables in `/sbin` and `/usr/sbin`
TODO-B: - Binary TBD in sbin is no problem because TBD
TODO-A: - Package does not install services, timers or recurring jobs
TODO-B: - Package does install services, timers or recurring jobs
TODO-B: TBD (list services, timers, jobs)
TODO-C: - Package does install services, timers or recurring jobs
TODO-C: TBD (list services, timers, jobs)
TODO-C: Those have the following security features: TBD (add details like
TODO-C: reduced permissions, temp envronment, restricted users/groups,
TODO-C: seccomp, apparmor, ...)
TODO: - Packages does not open privileged ports (ports < 1024)
TODO: - Packages does not contain extensions to security-sensitive software
TODO: (filters, scanners, plugins, UI skins, ...)
[Quality assurance - function/usage]
RULE: - After installing the package it must be possible to make it working with
RULE: a reasonable effort of configuration and documentation reading.
TODO-A: - The package works well right after install
TODO-B: - The package needs post install configuration or reading of
TODO-B: documentation, there isn't a safe default because TBD
[Quality assurance - maintenance]
RULE: - To support a package, we must be reasonably convinced that upstream
RULE: supports and cares for the package.
RULE: - The status of important bugs in Debian, Ubuntu and upstream's bug
RULE: tracking systems must be evaluated. Important bugs must be pointed out
RULE: and discussed in the MIR report.
TODO: - The package is maintained well in Debian/Ubuntu and has not too many
TODO: and long term critical bugs open
TODO: - Ubuntu https://bugs.launchpad.net/ubuntu/+source/TBDSRC/+bug
TODO: - Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=TBDSRC
TODO: - The package has important open bugs, listing them: TBD
TODO-A: - The package does not deal with exotic hardware we cannot support
TODO-B: - The package does deal with exotic hardware, it is present at TBD
TODO-B: to be able to test, fix and verify bugs
[Quality assurance - testing]
RULE: - The package must include a non-trivial test suite
RULE: - it should run at package build and fail the build if broken
TODO-A: - The package runs a test suite on build time, if it fails
TODO-A: it makes the build fail, link to build log TBD
TODO-B: - The package does not run a test at build time because TBD
RULE: - The package should, but is not required to, also contain
RULE: non-trivial autopkgtest(s).
TODO-A: - The package runs an autopkgtest, and is currently passing on
TODO-A: this TBD list of architectures, link to test logs TBD
TODO-B: - The package does not run an autopkgtest because TBD
RULE: - existing but failing tests that shall be handled as "ok to fail"
RULE: need to be explained along the test logs below
TODO-A: - The package does have not failing autopkgtests right now
TODO-B: - The package does have failing autopkgtests tests right now, but since
TODO-B: they always failed they are handled as "ignored failure", this is
TODO-B: ok because TBD
RULE: - If no build tests nor autopkgtests are included, and/or if the package
RULE: requires specific hardware to perform testing, the subscribed team
RULE: must provide a written test plan in a comment to the MIR bug, and
RULE: commit to running that test either at each upload of the package or
RULE: at least once each release cycle. In the comment to the MIR bug,
RULE: please link to the codebase of these tests (scripts or doc of manual
RULE: steps) and attach a full log of these test runs. This is meant to
RULE: assess their validity (e.g. not just superficial)
TODO: - The package can not be tested at build or autopktest time because TBD
TODO: to make up for that here TBD is a test plan/automation and example
TODO: test TBD (logs/scripts)
RULE: - In some cases a solution that is about to be promoted consists of
RULE: several very small libraries and one actual application uniting them
RULE: to achieve something useful. This is rather common in the go/rust space.
RULE: In that case often these micro-libs on their own can and should only
RULE: provide low level unit-tests. But more complex autopkgtests make no
RULE: sense on that level. Therefore in those cases one might want to test on
RULE: the solution level.
RULE: - Process wise MIR-requesting teams can ask (on the bug) for this
RULE: special case to apply for a given case, which reduces the test
RULE: constraints on the micro libraries but in return increases the
RULE: requirements for the test of the actual app/solution.
RULE: - Since this might promote micro-lib packages to main with less than
RULE: the common level of QA any further MIRed program using them will have
RULE: to provide the same amount of increased testing.
TODO: - This package is minimal and will be tested in a more wide reaching
TODO: solution context TBD, details about this testing are here TBD
[Quality assurance - packaging]
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 d/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-B: 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: - [[https://refspecs.linuxfoundation.org/fhs.shtml|FHS]]
RULE: - [[http://www.debian.org/doc/debian-policy/|Debian Policy]]
TODO-A: - This package correctly follows FHS and Debian Policy
TODO-B: - This package violates FHS or Debian Polciy, 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, which is set as a package bug contact. This is not a
RULE: requirement for the MIR team ACK, but for the package to be promoted
RULE: by an archive admin. Still, it is strongly suggested to subscribe,
RULE: as the owning team will get a preview of the to-be-expected incoming
RULE: 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: - Owning Team will be TBD
TODO-A: - Team is already subscribed to the package
TODO-B: - Team is not yet, but will subscribe to 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: - 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 ecosytem 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: - Right now that tooling to get a Cargo.lock that will include internal
RULE: vendored dependencies isn't in place yet (expect a dh-cargo change
RULE: later). Until it is available, as a fallback one can scan the
RULE: directory at build time and let it be generated in debian/rules.
RULE: An example might look like:
RULE: d/rules:
RULE: override_dh_auto_test:
RULE: CARGO_HOME=debian /usr/share/cargo/bin/cargo test --offline
RULE: d/<pkg>.install:
RULE: Cargo.lock /usr/share/doc/<pkg>
RULE: d/config.toml
RULE: # Use the vendorized sources to produce the Cargo.lock file. This
RULE: # can be performed by pointing $CARGO_HOME to the path containing
RULE: # this file.
RULE: [source]
RULE: [source.my-vendor-source]
RULE: directory = "vendor"
RULE: [source.crates-io]
RULE: replace-with = "my-vendor-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 shiped 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: - if there has been an archive test rebuild that has occurred more recently
RULE: than the last upload, the package must have rebuilt successfully
TODO-A: - The package has been built in the archive more recently than the last
TODO-A: test rebuild
TODO-B: - The package successfully built during the most recent test rebuild
TODO-C: - The package was test rebuilt in PPA or sbuild recently (provide link/logs)
[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
============================================================
Original, old-generation MIR description
[Availability]
Already in universe
Built for all supported architectures
[Rationale]
The Common Printing Dialog Backends (CPDB) project of OpenPrinting is about separating the print dialogs of different GUI toolkits and applications (GTK, Qt, Firefox, Chromium, LibreOffice, ...) from the different print technologies (CUPS, print to file, cloud printing services, ...) so that they can get developed independently and so always from all applications one can print with all print technologies and changes in the print technologies get supported quickly.
If one opens the print dialog, the dialog will not talk directly to CUPS, a cloud printing service, or any other printing system. For this communication there are the backends. The dialog will find all available backends and sends commands to them, for listing all available printers, giving property/option lists for the selected printers, and printing on the selected printer. This communication is done via D-Bus. So the backends are easily exchangeable and for getting support for a new print technology only its backend needs to get added.
Backends can even be packaged as Snaps, because they communicate only by D-Bus with the frontend, so a cloud printing provider could put their backend into the Snap Store.
[Security]
No known security issues, no CVEs for cpdb-libs known.
The backends are triggered via session D-Bus and always run as the same user as the calling print dialog, so they do not introduce additional security problems.
The separation of the communication with individual print technologies makes this code only be needed once (in the appropriate backend) instead of in each print dialog. This simplifies the security maintenance.
[Quality assurance]
- The Ubuntu Printing Team is subscribed.
https://bugs.launchpad.net/ubuntu/+source/cpdb-libs
https://github.com/OpenPrinting/cpdb-libs/issues
No upstream tests or autopkgtests.
[Dependencies]
CUPS, libcupsfilters, Glib, D-Bus -> all in main.
[Standards compliance]
The package meets the FHS and Debian Policy standards (4.1.0)
[Maintenance]
- Actively developed upstream. Last release was 2.0b1
https://github.com/OpenPrinting/cpdb-libs/commits/master |
|
| 2023-01-16 18:07:45 |
Till Kamppeter |
description |
[Availability]
The package cpdb-libs is already in Ubuntu universe.
The package cpdb-libs build for the architectures it is designed to work on.
It currently builds and works for architetcures: amd64, arm64, armhf, ppc64el, riscv64, s390x
Link to package https://launchpad.net/ubuntu/+source/cpdb-libs
[Rationale]
The Common Printing Dialog Backends (CPDB) project of OpenPrinting is about separating the print dialogs of different GUI toolkits and applications (GTK, Qt, Firefox, Chromium, LibreOffice, ...) from the different print technologies (CUPS, print to file, cloud printing services, ...) so that they can get developed independently and so always from all applications one can print with all print technologies and changes in the print technologies get supported quickly.
If one opens the print dialog, the dialog will not talk directly to CUPS, a cloud printing service, or any other printing system. For this communication there are the backends. The dialog will find all available backends and sends commands to them, for listing all available printers, giving property/option lists for the selected printers, and printing on the selected printer. This communication is done via D-Bus. So the backends are easily exchangeable and for getting support for a new print technology only its backend needs to get added.
Backends can even be packaged as Snaps, because they communicate only by D-Bus with the frontend, so a cloud printing provider could put their backend into the Snap Store.
All packages providing a print dialog will get modified (upstream) to support CPDB with this library and then these packages will depend on cpdb-libs.
These packages are:
- GUI toolkits: GTK, Qt
- GUI applications with their own print dialogs: Firefox/Thunderbird,
Chromium/Chrome, LibreOffice, ...
The coding of the CPDB support in GTK and Qt got already done in GSoC 2022 and currently merge requests are worked on to be included upstream. Once they are upstream (and already before the next upstream releases) they will get added to Ubuntu as distro patches.
See
https://github.com/TinyTrebuchet/gsoc22/
The dialogs of the browsers and LibreOffice will be worked on in GSoC 2023:
https://wiki.linuxfoundation.org/gsoc/google-summer-code-2023-openprinting-projects#cpdb_support_for_application_s_print_dialogsfirefox_chromium_libreoffice
This is also needed for the upcoming New Architecture of printing, where we go all-IPP and do not use PPD files any more. The CUPS backend for the CPDB (cpdb-backend-cups) is already designed to not handle PPD files any more.
The New Architecture is introduced as standard part of the distro in Ubuntu 23.10 at the latest. Therefore cpdb-libs NEEDS to be in main before Feature Freeze 23.10, ideally some weeks before.
There are very good chances that the changes on GTK and Qt already land in 23.04. In this case we need cpdb-libs in Main already by Feature Freeze of 23.04. This way the CPDB-based print dilaog will be tested more before the switchover into the New Architecture will take place.
[Security]
RULE: The security history and the current state of security issues in the
RULE: package must allow us to support the package for at least 9 months (120
RULE: for LTS+ESM support) without exposing its users to an inappropriate level
RULE: of security risks. This requires checking of several things:
RULE: - Search in the National Vulnerability Database using the PKG as keyword
RULE: http://cve.mitre.org/cve/search_cve_list.html
RULE: - check OSS security mailing list (feed into search engine
RULE: 'site:www.openwall.com/lists/oss-security <pkgname>')
RULE: - Ubuntu CVE Tracker: https://ubuntu.com/security/cve?package=<source-package-name>
TODO-A: - Had #TBD security issues in the past
TODO-A: - TBD links to such security issues in trackers
TODO-A: - TBD to any context that shows how these issues got handled in
TODO-A: the past
TODO-B: - No CVEs/security issues in this software in the past
RULE: - Check for security relevant binaries and behavior.
RULE: If any are present, this requires a more in-depth security review.
TODO: - no `suid` or `sgid` binaries
TODO-A: - no executables in `/sbin` and `/usr/sbin`
TODO-B: - Binary TBD in sbin is no problem because TBD
TODO-A: - Package does not install services, timers or recurring jobs
TODO-B: - Package does install services, timers or recurring jobs
TODO-B: TBD (list services, timers, jobs)
TODO-C: - Package does install services, timers or recurring jobs
TODO-C: TBD (list services, timers, jobs)
TODO-C: Those have the following security features: TBD (add details like
TODO-C: reduced permissions, temp envronment, restricted users/groups,
TODO-C: seccomp, apparmor, ...)
TODO: - Packages does not open privileged ports (ports < 1024)
TODO: - Packages does not contain extensions to security-sensitive software
TODO: (filters, scanners, plugins, UI skins, ...)
[Quality assurance - function/usage]
RULE: - After installing the package it must be possible to make it working with
RULE: a reasonable effort of configuration and documentation reading.
TODO-A: - The package works well right after install
TODO-B: - The package needs post install configuration or reading of
TODO-B: documentation, there isn't a safe default because TBD
[Quality assurance - maintenance]
RULE: - To support a package, we must be reasonably convinced that upstream
RULE: supports and cares for the package.
RULE: - The status of important bugs in Debian, Ubuntu and upstream's bug
RULE: tracking systems must be evaluated. Important bugs must be pointed out
RULE: and discussed in the MIR report.
TODO: - The package is maintained well in Debian/Ubuntu and has not too many
TODO: and long term critical bugs open
TODO: - Ubuntu https://bugs.launchpad.net/ubuntu/+source/TBDSRC/+bug
TODO: - Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=TBDSRC
TODO: - The package has important open bugs, listing them: TBD
TODO-A: - The package does not deal with exotic hardware we cannot support
TODO-B: - The package does deal with exotic hardware, it is present at TBD
TODO-B: to be able to test, fix and verify bugs
[Quality assurance - testing]
RULE: - The package must include a non-trivial test suite
RULE: - it should run at package build and fail the build if broken
TODO-A: - The package runs a test suite on build time, if it fails
TODO-A: it makes the build fail, link to build log TBD
TODO-B: - The package does not run a test at build time because TBD
RULE: - The package should, but is not required to, also contain
RULE: non-trivial autopkgtest(s).
TODO-A: - The package runs an autopkgtest, and is currently passing on
TODO-A: this TBD list of architectures, link to test logs TBD
TODO-B: - The package does not run an autopkgtest because TBD
RULE: - existing but failing tests that shall be handled as "ok to fail"
RULE: need to be explained along the test logs below
TODO-A: - The package does have not failing autopkgtests right now
TODO-B: - The package does have failing autopkgtests tests right now, but since
TODO-B: they always failed they are handled as "ignored failure", this is
TODO-B: ok because TBD
RULE: - If no build tests nor autopkgtests are included, and/or if the package
RULE: requires specific hardware to perform testing, the subscribed team
RULE: must provide a written test plan in a comment to the MIR bug, and
RULE: commit to running that test either at each upload of the package or
RULE: at least once each release cycle. In the comment to the MIR bug,
RULE: please link to the codebase of these tests (scripts or doc of manual
RULE: steps) and attach a full log of these test runs. This is meant to
RULE: assess their validity (e.g. not just superficial)
TODO: - The package can not be tested at build or autopktest time because TBD
TODO: to make up for that here TBD is a test plan/automation and example
TODO: test TBD (logs/scripts)
RULE: - In some cases a solution that is about to be promoted consists of
RULE: several very small libraries and one actual application uniting them
RULE: to achieve something useful. This is rather common in the go/rust space.
RULE: In that case often these micro-libs on their own can and should only
RULE: provide low level unit-tests. But more complex autopkgtests make no
RULE: sense on that level. Therefore in those cases one might want to test on
RULE: the solution level.
RULE: - Process wise MIR-requesting teams can ask (on the bug) for this
RULE: special case to apply for a given case, which reduces the test
RULE: constraints on the micro libraries but in return increases the
RULE: requirements for the test of the actual app/solution.
RULE: - Since this might promote micro-lib packages to main with less than
RULE: the common level of QA any further MIRed program using them will have
RULE: to provide the same amount of increased testing.
TODO: - This package is minimal and will be tested in a more wide reaching
TODO: solution context TBD, details about this testing are here TBD
[Quality assurance - packaging]
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 d/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-B: 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: - [[https://refspecs.linuxfoundation.org/fhs.shtml|FHS]]
RULE: - [[http://www.debian.org/doc/debian-policy/|Debian Policy]]
TODO-A: - This package correctly follows FHS and Debian Policy
TODO-B: - This package violates FHS or Debian Polciy, 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, which is set as a package bug contact. This is not a
RULE: requirement for the MIR team ACK, but for the package to be promoted
RULE: by an archive admin. Still, it is strongly suggested to subscribe,
RULE: as the owning team will get a preview of the to-be-expected incoming
RULE: 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: - Owning Team will be TBD
TODO-A: - Team is already subscribed to the package
TODO-B: - Team is not yet, but will subscribe to 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: - 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 ecosytem 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: - Right now that tooling to get a Cargo.lock that will include internal
RULE: vendored dependencies isn't in place yet (expect a dh-cargo change
RULE: later). Until it is available, as a fallback one can scan the
RULE: directory at build time and let it be generated in debian/rules.
RULE: An example might look like:
RULE: d/rules:
RULE: override_dh_auto_test:
RULE: CARGO_HOME=debian /usr/share/cargo/bin/cargo test --offline
RULE: d/<pkg>.install:
RULE: Cargo.lock /usr/share/doc/<pkg>
RULE: d/config.toml
RULE: # Use the vendorized sources to produce the Cargo.lock file. This
RULE: # can be performed by pointing $CARGO_HOME to the path containing
RULE: # this file.
RULE: [source]
RULE: [source.my-vendor-source]
RULE: directory = "vendor"
RULE: [source.crates-io]
RULE: replace-with = "my-vendor-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 shiped 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: - if there has been an archive test rebuild that has occurred more recently
RULE: than the last upload, the package must have rebuilt successfully
TODO-A: - The package has been built in the archive more recently than the last
TODO-A: test rebuild
TODO-B: - The package successfully built during the most recent test rebuild
TODO-C: - The package was test rebuilt in PPA or sbuild recently (provide link/logs)
[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
============================================================
Original, old-generation MIR description
[Availability]
Already in universe
Built for all supported architectures
[Rationale]
The Common Printing Dialog Backends (CPDB) project of OpenPrinting is about separating the print dialogs of different GUI toolkits and applications (GTK, Qt, Firefox, Chromium, LibreOffice, ...) from the different print technologies (CUPS, print to file, cloud printing services, ...) so that they can get developed independently and so always from all applications one can print with all print technologies and changes in the print technologies get supported quickly.
If one opens the print dialog, the dialog will not talk directly to CUPS, a cloud printing service, or any other printing system. For this communication there are the backends. The dialog will find all available backends and sends commands to them, for listing all available printers, giving property/option lists for the selected printers, and printing on the selected printer. This communication is done via D-Bus. So the backends are easily exchangeable and for getting support for a new print technology only its backend needs to get added.
Backends can even be packaged as Snaps, because they communicate only by D-Bus with the frontend, so a cloud printing provider could put their backend into the Snap Store.
[Security]
No known security issues, no CVEs for cpdb-libs known.
The backends are triggered via session D-Bus and always run as the same user as the calling print dialog, so they do not introduce additional security problems.
The separation of the communication with individual print technologies makes this code only be needed once (in the appropriate backend) instead of in each print dialog. This simplifies the security maintenance.
[Quality assurance]
- The Ubuntu Printing Team is subscribed.
https://bugs.launchpad.net/ubuntu/+source/cpdb-libs
https://github.com/OpenPrinting/cpdb-libs/issues
No upstream tests or autopkgtests.
[Dependencies]
CUPS, libcupsfilters, Glib, D-Bus -> all in main.
[Standards compliance]
The package meets the FHS and Debian Policy standards (4.1.0)
[Maintenance]
- Actively developed upstream. Last release was 2.0b1
https://github.com/OpenPrinting/cpdb-libs/commits/master |
[Availability]
The package cpdb-libs is already in Ubuntu universe.
The package cpdb-libs build for the architectures it is designed to work on.
It currently builds and works for architetcures: amd64, arm64, armhf, ppc64el, riscv64, s390x
Link to package https://launchpad.net/ubuntu/+source/cpdb-libs
[Rationale]
The Common Printing Dialog Backends (CPDB) project of OpenPrinting is about separating the print dialogs of different GUI toolkits and applications (GTK, Qt, Firefox, Chromium, LibreOffice, ...) from the different print technologies (CUPS, print to file, cloud printing services, ...) so that they can get developed independently and so always from all applications one can print with all print technologies and changes in the print technologies get supported quickly.
If one opens the print dialog, the dialog will not talk directly to CUPS, a cloud printing service, or any other printing system. For this communication there are the backends. The dialog will find all available backends and sends commands to them, for listing all available printers, giving property/option lists for the selected printers, and printing on the selected printer. This communication is done via D-Bus. So the backends are easily exchangeable and for getting support for a new print technology only its backend needs to get added.
Backends can even be packaged as Snaps, because they communicate only by D-Bus with the frontend, so a cloud printing provider could put their backend into the Snap Store.
All packages providing a print dialog will get modified (upstream) to support CPDB with this library and then these packages will depend on cpdb-libs.
These packages are:
- GUI toolkits: GTK, Qt
- GUI applications with their own print dialogs: Firefox/Thunderbird,
Chromium/Chrome, LibreOffice, ...
The coding of the CPDB support in GTK and Qt got already done in GSoC 2022 and currently merge requests are worked on to be included upstream. Once they are upstream (and already before the next upstream releases) they will get added to Ubuntu as distro patches.
See
https://github.com/TinyTrebuchet/gsoc22/
The dialogs of the browsers and LibreOffice will be worked on in GSoC 2023:
https://wiki.linuxfoundation.org/gsoc/google-summer-code-2023-openprinting-projects#cpdb_support_for_application_s_print_dialogsfirefox_chromium_libreoffice
This is also needed for the upcoming New Architecture of printing, where we go all-IPP and do not use PPD files any more. The CUPS backend for the CPDB (cpdb-backend-cups) is already designed to not handle PPD files any more.
The New Architecture is introduced as standard part of the distro in Ubuntu 23.10 at the latest. Therefore cpdb-libs NEEDS to be in main before Feature Freeze 23.10, ideally some weeks before.
There are very good chances that the changes on GTK and Qt already land in 23.04. In this case we need cpdb-libs in Main already by Feature Freeze of 23.04. This way the CPDB-based print dilaog will be tested more before the switchover into the New Architecture will take place.
[Security]
No CVEs/security issues in this software in the past
RULE: - Check for security relevant binaries and behavior.
RULE: If any are present, this requires a more in-depth security review.
- 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)
- Packages does not contain extensions to security-sensitive software
TODO: (filters, scanners, plugins, UI skins, ...)
[Quality assurance - function/usage]
RULE: - After installing the package it must be possible to make it working with
RULE: a reasonable effort of configuration and documentation reading.
TODO-A: - The package works well right after install
TODO-B: - The package needs post install configuration or reading of
TODO-B: documentation, there isn't a safe default because TBD
[Quality assurance - maintenance]
RULE: - To support a package, we must be reasonably convinced that upstream
RULE: supports and cares for the package.
RULE: - The status of important bugs in Debian, Ubuntu and upstream's bug
RULE: tracking systems must be evaluated. Important bugs must be pointed out
RULE: and discussed in the MIR report.
TODO: - The package is maintained well in Debian/Ubuntu and has not too many
TODO: and long term critical bugs open
TODO: - Ubuntu https://bugs.launchpad.net/ubuntu/+source/TBDSRC/+bug
TODO: - Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=TBDSRC
TODO: - The package has important open bugs, listing them: TBD
TODO-A: - The package does not deal with exotic hardware we cannot support
TODO-B: - The package does deal with exotic hardware, it is present at TBD
TODO-B: to be able to test, fix and verify bugs
[Quality assurance - testing]
RULE: - The package must include a non-trivial test suite
RULE: - it should run at package build and fail the build if broken
TODO-A: - The package runs a test suite on build time, if it fails
TODO-A: it makes the build fail, link to build log TBD
TODO-B: - The package does not run a test at build time because TBD
RULE: - The package should, but is not required to, also contain
RULE: non-trivial autopkgtest(s).
TODO-A: - The package runs an autopkgtest, and is currently passing on
TODO-A: this TBD list of architectures, link to test logs TBD
TODO-B: - The package does not run an autopkgtest because TBD
RULE: - existing but failing tests that shall be handled as "ok to fail"
RULE: need to be explained along the test logs below
TODO-A: - The package does have not failing autopkgtests right now
TODO-B: - The package does have failing autopkgtests tests right now, but since
TODO-B: they always failed they are handled as "ignored failure", this is
TODO-B: ok because TBD
RULE: - If no build tests nor autopkgtests are included, and/or if the package
RULE: requires specific hardware to perform testing, the subscribed team
RULE: must provide a written test plan in a comment to the MIR bug, and
RULE: commit to running that test either at each upload of the package or
RULE: at least once each release cycle. In the comment to the MIR bug,
RULE: please link to the codebase of these tests (scripts or doc of manual
RULE: steps) and attach a full log of these test runs. This is meant to
RULE: assess their validity (e.g. not just superficial)
TODO: - The package can not be tested at build or autopktest time because TBD
TODO: to make up for that here TBD is a test plan/automation and example
TODO: test TBD (logs/scripts)
RULE: - In some cases a solution that is about to be promoted consists of
RULE: several very small libraries and one actual application uniting them
RULE: to achieve something useful. This is rather common in the go/rust space.
RULE: In that case often these micro-libs on their own can and should only
RULE: provide low level unit-tests. But more complex autopkgtests make no
RULE: sense on that level. Therefore in those cases one might want to test on
RULE: the solution level.
RULE: - Process wise MIR-requesting teams can ask (on the bug) for this
RULE: special case to apply for a given case, which reduces the test
RULE: constraints on the micro libraries but in return increases the
RULE: requirements for the test of the actual app/solution.
RULE: - Since this might promote micro-lib packages to main with less than
RULE: the common level of QA any further MIRed program using them will have
RULE: to provide the same amount of increased testing.
TODO: - This package is minimal and will be tested in a more wide reaching
TODO: solution context TBD, details about this testing are here TBD
[Quality assurance - packaging]
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 d/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-B: 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: - [[https://refspecs.linuxfoundation.org/fhs.shtml|FHS]]
RULE: - [[http://www.debian.org/doc/debian-policy/|Debian Policy]]
TODO-A: - This package correctly follows FHS and Debian Policy
TODO-B: - This package violates FHS or Debian Polciy, 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, which is set as a package bug contact. This is not a
RULE: requirement for the MIR team ACK, but for the package to be promoted
RULE: by an archive admin. Still, it is strongly suggested to subscribe,
RULE: as the owning team will get a preview of the to-be-expected incoming
RULE: 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: - Owning Team will be TBD
TODO-A: - Team is already subscribed to the package
TODO-B: - Team is not yet, but will subscribe to 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: - 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 ecosytem 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: - Right now that tooling to get a Cargo.lock that will include internal
RULE: vendored dependencies isn't in place yet (expect a dh-cargo change
RULE: later). Until it is available, as a fallback one can scan the
RULE: directory at build time and let it be generated in debian/rules.
RULE: An example might look like:
RULE: d/rules:
RULE: override_dh_auto_test:
RULE: CARGO_HOME=debian /usr/share/cargo/bin/cargo test --offline
RULE: d/<pkg>.install:
RULE: Cargo.lock /usr/share/doc/<pkg>
RULE: d/config.toml
RULE: # Use the vendorized sources to produce the Cargo.lock file. This
RULE: # can be performed by pointing $CARGO_HOME to the path containing
RULE: # this file.
RULE: [source]
RULE: [source.my-vendor-source]
RULE: directory = "vendor"
RULE: [source.crates-io]
RULE: replace-with = "my-vendor-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 shiped 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: - if there has been an archive test rebuild that has occurred more recently
RULE: than the last upload, the package must have rebuilt successfully
TODO-A: - The package has been built in the archive more recently than the last
TODO-A: test rebuild
TODO-B: - The package successfully built during the most recent test rebuild
TODO-C: - The package was test rebuilt in PPA or sbuild recently (provide link/logs)
[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
============================================================
Original, old-generation MIR description
[Availability]
Already in universe
Built for all supported architectures
[Rationale]
The Common Printing Dialog Backends (CPDB) project of OpenPrinting is about separating the print dialogs of different GUI toolkits and applications (GTK, Qt, Firefox, Chromium, LibreOffice, ...) from the different print technologies (CUPS, print to file, cloud printing services, ...) so that they can get developed independently and so always from all applications one can print with all print technologies and changes in the print technologies get supported quickly.
If one opens the print dialog, the dialog will not talk directly to CUPS, a cloud printing service, or any other printing system. For this communication there are the backends. The dialog will find all available backends and sends commands to them, for listing all available printers, giving property/option lists for the selected printers, and printing on the selected printer. This communication is done via D-Bus. So the backends are easily exchangeable and for getting support for a new print technology only its backend needs to get added.
Backends can even be packaged as Snaps, because they communicate only by D-Bus with the frontend, so a cloud printing provider could put their backend into the Snap Store.
[Security]
No known security issues, no CVEs for cpdb-libs known.
The backends are triggered via session D-Bus and always run as the same user as the calling print dialog, so they do not introduce additional security problems.
The separation of the communication with individual print technologies makes this code only be needed once (in the appropriate backend) instead of in each print dialog. This simplifies the security maintenance.
[Quality assurance]
- The Ubuntu Printing Team is subscribed.
https://bugs.launchpad.net/ubuntu/+source/cpdb-libs
https://github.com/OpenPrinting/cpdb-libs/issues
No upstream tests or autopkgtests.
[Dependencies]
CUPS, libcupsfilters, Glib, D-Bus -> all in main.
[Standards compliance]
The package meets the FHS and Debian Policy standards (4.1.0)
[Maintenance]
- Actively developed upstream. Last release was 2.0b1
https://github.com/OpenPrinting/cpdb-libs/commits/master |
|
| 2023-01-16 18:44:35 |
Till Kamppeter |
description |
[Availability]
The package cpdb-libs is already in Ubuntu universe.
The package cpdb-libs build for the architectures it is designed to work on.
It currently builds and works for architetcures: amd64, arm64, armhf, ppc64el, riscv64, s390x
Link to package https://launchpad.net/ubuntu/+source/cpdb-libs
[Rationale]
The Common Printing Dialog Backends (CPDB) project of OpenPrinting is about separating the print dialogs of different GUI toolkits and applications (GTK, Qt, Firefox, Chromium, LibreOffice, ...) from the different print technologies (CUPS, print to file, cloud printing services, ...) so that they can get developed independently and so always from all applications one can print with all print technologies and changes in the print technologies get supported quickly.
If one opens the print dialog, the dialog will not talk directly to CUPS, a cloud printing service, or any other printing system. For this communication there are the backends. The dialog will find all available backends and sends commands to them, for listing all available printers, giving property/option lists for the selected printers, and printing on the selected printer. This communication is done via D-Bus. So the backends are easily exchangeable and for getting support for a new print technology only its backend needs to get added.
Backends can even be packaged as Snaps, because they communicate only by D-Bus with the frontend, so a cloud printing provider could put their backend into the Snap Store.
All packages providing a print dialog will get modified (upstream) to support CPDB with this library and then these packages will depend on cpdb-libs.
These packages are:
- GUI toolkits: GTK, Qt
- GUI applications with their own print dialogs: Firefox/Thunderbird,
Chromium/Chrome, LibreOffice, ...
The coding of the CPDB support in GTK and Qt got already done in GSoC 2022 and currently merge requests are worked on to be included upstream. Once they are upstream (and already before the next upstream releases) they will get added to Ubuntu as distro patches.
See
https://github.com/TinyTrebuchet/gsoc22/
The dialogs of the browsers and LibreOffice will be worked on in GSoC 2023:
https://wiki.linuxfoundation.org/gsoc/google-summer-code-2023-openprinting-projects#cpdb_support_for_application_s_print_dialogsfirefox_chromium_libreoffice
This is also needed for the upcoming New Architecture of printing, where we go all-IPP and do not use PPD files any more. The CUPS backend for the CPDB (cpdb-backend-cups) is already designed to not handle PPD files any more.
The New Architecture is introduced as standard part of the distro in Ubuntu 23.10 at the latest. Therefore cpdb-libs NEEDS to be in main before Feature Freeze 23.10, ideally some weeks before.
There are very good chances that the changes on GTK and Qt already land in 23.04. In this case we need cpdb-libs in Main already by Feature Freeze of 23.04. This way the CPDB-based print dilaog will be tested more before the switchover into the New Architecture will take place.
[Security]
No CVEs/security issues in this software in the past
RULE: - Check for security relevant binaries and behavior.
RULE: If any are present, this requires a more in-depth security review.
- 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)
- Packages does not contain extensions to security-sensitive software
TODO: (filters, scanners, plugins, UI skins, ...)
[Quality assurance - function/usage]
RULE: - After installing the package it must be possible to make it working with
RULE: a reasonable effort of configuration and documentation reading.
TODO-A: - The package works well right after install
TODO-B: - The package needs post install configuration or reading of
TODO-B: documentation, there isn't a safe default because TBD
[Quality assurance - maintenance]
RULE: - To support a package, we must be reasonably convinced that upstream
RULE: supports and cares for the package.
RULE: - The status of important bugs in Debian, Ubuntu and upstream's bug
RULE: tracking systems must be evaluated. Important bugs must be pointed out
RULE: and discussed in the MIR report.
TODO: - The package is maintained well in Debian/Ubuntu and has not too many
TODO: and long term critical bugs open
TODO: - Ubuntu https://bugs.launchpad.net/ubuntu/+source/TBDSRC/+bug
TODO: - Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=TBDSRC
TODO: - The package has important open bugs, listing them: TBD
TODO-A: - The package does not deal with exotic hardware we cannot support
TODO-B: - The package does deal with exotic hardware, it is present at TBD
TODO-B: to be able to test, fix and verify bugs
[Quality assurance - testing]
RULE: - The package must include a non-trivial test suite
RULE: - it should run at package build and fail the build if broken
TODO-A: - The package runs a test suite on build time, if it fails
TODO-A: it makes the build fail, link to build log TBD
TODO-B: - The package does not run a test at build time because TBD
RULE: - The package should, but is not required to, also contain
RULE: non-trivial autopkgtest(s).
TODO-A: - The package runs an autopkgtest, and is currently passing on
TODO-A: this TBD list of architectures, link to test logs TBD
TODO-B: - The package does not run an autopkgtest because TBD
RULE: - existing but failing tests that shall be handled as "ok to fail"
RULE: need to be explained along the test logs below
TODO-A: - The package does have not failing autopkgtests right now
TODO-B: - The package does have failing autopkgtests tests right now, but since
TODO-B: they always failed they are handled as "ignored failure", this is
TODO-B: ok because TBD
RULE: - If no build tests nor autopkgtests are included, and/or if the package
RULE: requires specific hardware to perform testing, the subscribed team
RULE: must provide a written test plan in a comment to the MIR bug, and
RULE: commit to running that test either at each upload of the package or
RULE: at least once each release cycle. In the comment to the MIR bug,
RULE: please link to the codebase of these tests (scripts or doc of manual
RULE: steps) and attach a full log of these test runs. This is meant to
RULE: assess their validity (e.g. not just superficial)
TODO: - The package can not be tested at build or autopktest time because TBD
TODO: to make up for that here TBD is a test plan/automation and example
TODO: test TBD (logs/scripts)
RULE: - In some cases a solution that is about to be promoted consists of
RULE: several very small libraries and one actual application uniting them
RULE: to achieve something useful. This is rather common in the go/rust space.
RULE: In that case often these micro-libs on their own can and should only
RULE: provide low level unit-tests. But more complex autopkgtests make no
RULE: sense on that level. Therefore in those cases one might want to test on
RULE: the solution level.
RULE: - Process wise MIR-requesting teams can ask (on the bug) for this
RULE: special case to apply for a given case, which reduces the test
RULE: constraints on the micro libraries but in return increases the
RULE: requirements for the test of the actual app/solution.
RULE: - Since this might promote micro-lib packages to main with less than
RULE: the common level of QA any further MIRed program using them will have
RULE: to provide the same amount of increased testing.
TODO: - This package is minimal and will be tested in a more wide reaching
TODO: solution context TBD, details about this testing are here TBD
[Quality assurance - packaging]
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 d/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-B: 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: - [[https://refspecs.linuxfoundation.org/fhs.shtml|FHS]]
RULE: - [[http://www.debian.org/doc/debian-policy/|Debian Policy]]
TODO-A: - This package correctly follows FHS and Debian Policy
TODO-B: - This package violates FHS or Debian Polciy, 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, which is set as a package bug contact. This is not a
RULE: requirement for the MIR team ACK, but for the package to be promoted
RULE: by an archive admin. Still, it is strongly suggested to subscribe,
RULE: as the owning team will get a preview of the to-be-expected incoming
RULE: 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: - Owning Team will be TBD
TODO-A: - Team is already subscribed to the package
TODO-B: - Team is not yet, but will subscribe to 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: - 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 ecosytem 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: - Right now that tooling to get a Cargo.lock that will include internal
RULE: vendored dependencies isn't in place yet (expect a dh-cargo change
RULE: later). Until it is available, as a fallback one can scan the
RULE: directory at build time and let it be generated in debian/rules.
RULE: An example might look like:
RULE: d/rules:
RULE: override_dh_auto_test:
RULE: CARGO_HOME=debian /usr/share/cargo/bin/cargo test --offline
RULE: d/<pkg>.install:
RULE: Cargo.lock /usr/share/doc/<pkg>
RULE: d/config.toml
RULE: # Use the vendorized sources to produce the Cargo.lock file. This
RULE: # can be performed by pointing $CARGO_HOME to the path containing
RULE: # this file.
RULE: [source]
RULE: [source.my-vendor-source]
RULE: directory = "vendor"
RULE: [source.crates-io]
RULE: replace-with = "my-vendor-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 shiped 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: - if there has been an archive test rebuild that has occurred more recently
RULE: than the last upload, the package must have rebuilt successfully
TODO-A: - The package has been built in the archive more recently than the last
TODO-A: test rebuild
TODO-B: - The package successfully built during the most recent test rebuild
TODO-C: - The package was test rebuilt in PPA or sbuild recently (provide link/logs)
[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
============================================================
Original, old-generation MIR description
[Availability]
Already in universe
Built for all supported architectures
[Rationale]
The Common Printing Dialog Backends (CPDB) project of OpenPrinting is about separating the print dialogs of different GUI toolkits and applications (GTK, Qt, Firefox, Chromium, LibreOffice, ...) from the different print technologies (CUPS, print to file, cloud printing services, ...) so that they can get developed independently and so always from all applications one can print with all print technologies and changes in the print technologies get supported quickly.
If one opens the print dialog, the dialog will not talk directly to CUPS, a cloud printing service, or any other printing system. For this communication there are the backends. The dialog will find all available backends and sends commands to them, for listing all available printers, giving property/option lists for the selected printers, and printing on the selected printer. This communication is done via D-Bus. So the backends are easily exchangeable and for getting support for a new print technology only its backend needs to get added.
Backends can even be packaged as Snaps, because they communicate only by D-Bus with the frontend, so a cloud printing provider could put their backend into the Snap Store.
[Security]
No known security issues, no CVEs for cpdb-libs known.
The backends are triggered via session D-Bus and always run as the same user as the calling print dialog, so they do not introduce additional security problems.
The separation of the communication with individual print technologies makes this code only be needed once (in the appropriate backend) instead of in each print dialog. This simplifies the security maintenance.
[Quality assurance]
- The Ubuntu Printing Team is subscribed.
https://bugs.launchpad.net/ubuntu/+source/cpdb-libs
https://github.com/OpenPrinting/cpdb-libs/issues
No upstream tests or autopkgtests.
[Dependencies]
CUPS, libcupsfilters, Glib, D-Bus -> all in main.
[Standards compliance]
The package meets the FHS and Debian Policy standards (4.1.0)
[Maintenance]
- Actively developed upstream. Last release was 2.0b1
https://github.com/OpenPrinting/cpdb-libs/commits/master |
[Availability]
The package cpdb-libs is already in Ubuntu universe.
The package cpdb-libs build for the architectures it is designed to work on.
It currently builds and works for architetcures: amd64, arm64, armhf, ppc64el, riscv64, s390x
Link to package https://launchpad.net/ubuntu/+source/cpdb-libs
[Rationale]
The Common Printing Dialog Backends (CPDB) project of OpenPrinting is about separating the print dialogs of different GUI toolkits and applications (GTK, Qt, Firefox, Chromium, LibreOffice, ...) from the different print technologies (CUPS, print to file, cloud printing services, ...) so that they can get developed independently and so always from all applications one can print with all print technologies and changes in the print technologies get supported quickly.
If one opens the print dialog, the dialog will not talk directly to CUPS, a cloud printing service, or any other printing system. For this communication there are the backends. The dialog will find all available backends and sends commands to them, for listing all available printers, giving property/option lists for the selected printers, and printing on the selected printer. This communication is done via D-Bus. So the backends are easily exchangeable and for getting support for a new print technology only its backend needs to get added.
Backends can even be packaged as Snaps, because they communicate only by D-Bus with the frontend, so a cloud printing provider could put their backend into the Snap Store.
All packages providing a print dialog will get modified (upstream) to support CPDB with this library and then these packages will depend on cpdb-libs.
These packages are:
- GUI toolkits: GTK, Qt
- GUI applications with their own print dialogs: Firefox/Thunderbird,
Chromium/Chrome, LibreOffice, ...
The coding of the CPDB support in GTK and Qt got already done in GSoC 2022 and currently merge requests are worked on to be included upstream. Once they are upstream (and already before the next upstream releases) they will get added to Ubuntu as distro patches.
See
https://github.com/TinyTrebuchet/gsoc22/
The dialogs of the browsers and LibreOffice will be worked on in GSoC 2023:
https://wiki.linuxfoundation.org/gsoc/google-summer-code-2023-openprinting-projects#cpdb_support_for_application_s_print_dialogsfirefox_chromium_libreoffice
This is also needed for the upcoming New Architecture of printing, where we go all-IPP and do not use PPD files any more. The CUPS backend for the CPDB (cpdb-backend-cups) is already designed to not handle PPD files any more.
The New Architecture is introduced as standard part of the distro in Ubuntu 23.10 at the latest. Therefore cpdb-libs NEEDS to be in main before Feature Freeze 23.10, ideally some weeks before.
There are very good chances that the changes on GTK and Qt already land in 23.04. In this case we need cpdb-libs in Main already by Feature Freeze of 23.04. This way the CPDB-based print dilaog will be tested more before the switchover into the New Architecture will take place.
[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)
- Packages does not contain extensions to security-sensitive software
The backends are triggered via session D-Bus and always run as the same user as the calling print dialog, so they do not introduce additional security problems.
The separation of the communication with individual print technologies makes this code only be needed once (in the appropriate backend) instead of in each print dialog. This simplifies the security maintenance.
[Quality assurance - function/usage]
- The package works well right after install
Every package containing a print dialog using the CPDB installs this library as a dependency. The installed backends are auto-discovered via D-Bus, no configuration or setup needed.
To assure that at least one backend is installed we can
- TODO - Let the libcpdb-libs-frontend1 recommend cpdb-backend-file
- TODO - Let the cupsd package recommend cpdb-backend-cups
[Quality assurance - maintenance]
- The package is maintained well in Debian/Ubuntu and has not too many
and long term critical bugs open
- Ubuntu https://bugs.launchpad.net/ubuntu/+source/cpdb-libs/+bug
- Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=cpdb-libs
- Upstream https://github.com/OpenPrinting/cpdb-libs/issues
TODO: - The package has important open bugs, listing them: TBD
TODO-A: - The package does not deal with exotic hardware we cannot support
TODO-B: - The package does deal with exotic hardware, it is present at TBD
TODO-B: to be able to test, fix and verify bugs
[Quality assurance - testing]
RULE: - The package must include a non-trivial test suite
RULE: - it should run at package build and fail the build if broken
TODO-A: - The package runs a test suite on build time, if it fails
TODO-A: it makes the build fail, link to build log TBD
TODO-B: - The package does not run a test at build time because TBD
RULE: - The package should, but is not required to, also contain
RULE: non-trivial autopkgtest(s).
TODO-A: - The package runs an autopkgtest, and is currently passing on
TODO-A: this TBD list of architectures, link to test logs TBD
TODO-B: - The package does not run an autopkgtest because TBD
RULE: - existing but failing tests that shall be handled as "ok to fail"
RULE: need to be explained along the test logs below
TODO-A: - The package does have not failing autopkgtests right now
TODO-B: - The package does have failing autopkgtests tests right now, but since
TODO-B: they always failed they are handled as "ignored failure", this is
TODO-B: ok because TBD
RULE: - If no build tests nor autopkgtests are included, and/or if the package
RULE: requires specific hardware to perform testing, the subscribed team
RULE: must provide a written test plan in a comment to the MIR bug, and
RULE: commit to running that test either at each upload of the package or
RULE: at least once each release cycle. In the comment to the MIR bug,
RULE: please link to the codebase of these tests (scripts or doc of manual
RULE: steps) and attach a full log of these test runs. This is meant to
RULE: assess their validity (e.g. not just superficial)
TODO: - The package can not be tested at build or autopktest time because TBD
TODO: to make up for that here TBD is a test plan/automation and example
TODO: test TBD (logs/scripts)
RULE: - In some cases a solution that is about to be promoted consists of
RULE: several very small libraries and one actual application uniting them
RULE: to achieve something useful. This is rather common in the go/rust space.
RULE: In that case often these micro-libs on their own can and should only
RULE: provide low level unit-tests. But more complex autopkgtests make no
RULE: sense on that level. Therefore in those cases one might want to test on
RULE: the solution level.
RULE: - Process wise MIR-requesting teams can ask (on the bug) for this
RULE: special case to apply for a given case, which reduces the test
RULE: constraints on the micro libraries but in return increases the
RULE: requirements for the test of the actual app/solution.
RULE: - Since this might promote micro-lib packages to main with less than
RULE: the common level of QA any further MIRed program using them will have
RULE: to provide the same amount of increased testing.
TODO: - This package is minimal and will be tested in a more wide reaching
TODO: solution context TBD, details about this testing are here TBD
[Quality assurance - packaging]
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 d/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-B: 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: - [[https://refspecs.linuxfoundation.org/fhs.shtml|FHS]]
RULE: - [[http://www.debian.org/doc/debian-policy/|Debian Policy]]
TODO-A: - This package correctly follows FHS and Debian Policy
TODO-B: - This package violates FHS or Debian Polciy, 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, which is set as a package bug contact. This is not a
RULE: requirement for the MIR team ACK, but for the package to be promoted
RULE: by an archive admin. Still, it is strongly suggested to subscribe,
RULE: as the owning team will get a preview of the to-be-expected incoming
RULE: 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: - Owning Team will be TBD
TODO-A: - Team is already subscribed to the package
TODO-B: - Team is not yet, but will subscribe to 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: - 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 ecosytem 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: - Right now that tooling to get a Cargo.lock that will include internal
RULE: vendored dependencies isn't in place yet (expect a dh-cargo change
RULE: later). Until it is available, as a fallback one can scan the
RULE: directory at build time and let it be generated in debian/rules.
RULE: An example might look like:
RULE: d/rules:
RULE: override_dh_auto_test:
RULE: CARGO_HOME=debian /usr/share/cargo/bin/cargo test --offline
RULE: d/<pkg>.install:
RULE: Cargo.lock /usr/share/doc/<pkg>
RULE: d/config.toml
RULE: # Use the vendorized sources to produce the Cargo.lock file. This
RULE: # can be performed by pointing $CARGO_HOME to the path containing
RULE: # this file.
RULE: [source]
RULE: [source.my-vendor-source]
RULE: directory = "vendor"
RULE: [source.crates-io]
RULE: replace-with = "my-vendor-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 shiped 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: - if there has been an archive test rebuild that has occurred more recently
RULE: than the last upload, the package must have rebuilt successfully
TODO-A: - The package has been built in the archive more recently than the last
TODO-A: test rebuild
TODO-B: - The package successfully built during the most recent test rebuild
TODO-C: - The package was test rebuilt in PPA or sbuild recently (provide link/logs)
[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
============================================================
Original, old-generation MIR description
[Availability]
Already in universe
Built for all supported architectures
[Rationale]
The Common Printing Dialog Backends (CPDB) project of OpenPrinting is about separating the print dialogs of different GUI toolkits and applications (GTK, Qt, Firefox, Chromium, LibreOffice, ...) from the different print technologies (CUPS, print to file, cloud printing services, ...) so that they can get developed independently and so always from all applications one can print with all print technologies and changes in the print technologies get supported quickly.
If one opens the print dialog, the dialog will not talk directly to CUPS, a cloud printing service, or any other printing system. For this communication there are the backends. The dialog will find all available backends and sends commands to them, for listing all available printers, giving property/option lists for the selected printers, and printing on the selected printer. This communication is done via D-Bus. So the backends are easily exchangeable and for getting support for a new print technology only its backend needs to get added.
Backends can even be packaged as Snaps, because they communicate only by D-Bus with the frontend, so a cloud printing provider could put their backend into the Snap Store.
[Security]
No known security issues, no CVEs for cpdb-libs known.
The backends are triggered via session D-Bus and always run as the same user as the calling print dialog, so they do not introduce additional security problems.
The separation of the communication with individual print technologies makes this code only be needed once (in the appropriate backend) instead of in each print dialog. This simplifies the security maintenance.
[Quality assurance]
- The Ubuntu Printing Team is subscribed.
https://bugs.launchpad.net/ubuntu/+source/cpdb-libs
https://github.com/OpenPrinting/cpdb-libs/issues
No upstream tests or autopkgtests.
[Dependencies]
CUPS, libcupsfilters, Glib, D-Bus -> all in main.
[Standards compliance]
The package meets the FHS and Debian Policy standards (4.1.0)
[Maintenance]
- Actively developed upstream. Last release was 2.0b1
https://github.com/OpenPrinting/cpdb-libs/commits/master |
|
| 2023-01-16 21:17:19 |
Till Kamppeter |
description |
[Availability]
The package cpdb-libs is already in Ubuntu universe.
The package cpdb-libs build for the architectures it is designed to work on.
It currently builds and works for architetcures: amd64, arm64, armhf, ppc64el, riscv64, s390x
Link to package https://launchpad.net/ubuntu/+source/cpdb-libs
[Rationale]
The Common Printing Dialog Backends (CPDB) project of OpenPrinting is about separating the print dialogs of different GUI toolkits and applications (GTK, Qt, Firefox, Chromium, LibreOffice, ...) from the different print technologies (CUPS, print to file, cloud printing services, ...) so that they can get developed independently and so always from all applications one can print with all print technologies and changes in the print technologies get supported quickly.
If one opens the print dialog, the dialog will not talk directly to CUPS, a cloud printing service, or any other printing system. For this communication there are the backends. The dialog will find all available backends and sends commands to them, for listing all available printers, giving property/option lists for the selected printers, and printing on the selected printer. This communication is done via D-Bus. So the backends are easily exchangeable and for getting support for a new print technology only its backend needs to get added.
Backends can even be packaged as Snaps, because they communicate only by D-Bus with the frontend, so a cloud printing provider could put their backend into the Snap Store.
All packages providing a print dialog will get modified (upstream) to support CPDB with this library and then these packages will depend on cpdb-libs.
These packages are:
- GUI toolkits: GTK, Qt
- GUI applications with their own print dialogs: Firefox/Thunderbird,
Chromium/Chrome, LibreOffice, ...
The coding of the CPDB support in GTK and Qt got already done in GSoC 2022 and currently merge requests are worked on to be included upstream. Once they are upstream (and already before the next upstream releases) they will get added to Ubuntu as distro patches.
See
https://github.com/TinyTrebuchet/gsoc22/
The dialogs of the browsers and LibreOffice will be worked on in GSoC 2023:
https://wiki.linuxfoundation.org/gsoc/google-summer-code-2023-openprinting-projects#cpdb_support_for_application_s_print_dialogsfirefox_chromium_libreoffice
This is also needed for the upcoming New Architecture of printing, where we go all-IPP and do not use PPD files any more. The CUPS backend for the CPDB (cpdb-backend-cups) is already designed to not handle PPD files any more.
The New Architecture is introduced as standard part of the distro in Ubuntu 23.10 at the latest. Therefore cpdb-libs NEEDS to be in main before Feature Freeze 23.10, ideally some weeks before.
There are very good chances that the changes on GTK and Qt already land in 23.04. In this case we need cpdb-libs in Main already by Feature Freeze of 23.04. This way the CPDB-based print dilaog will be tested more before the switchover into the New Architecture will take place.
[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)
- Packages does not contain extensions to security-sensitive software
The backends are triggered via session D-Bus and always run as the same user as the calling print dialog, so they do not introduce additional security problems.
The separation of the communication with individual print technologies makes this code only be needed once (in the appropriate backend) instead of in each print dialog. This simplifies the security maintenance.
[Quality assurance - function/usage]
- The package works well right after install
Every package containing a print dialog using the CPDB installs this library as a dependency. The installed backends are auto-discovered via D-Bus, no configuration or setup needed.
To assure that at least one backend is installed we can
- TODO - Let the libcpdb-libs-frontend1 recommend cpdb-backend-file
- TODO - Let the cupsd package recommend cpdb-backend-cups
[Quality assurance - maintenance]
- The package is maintained well in Debian/Ubuntu and has not too many
and long term critical bugs open
- Ubuntu https://bugs.launchpad.net/ubuntu/+source/cpdb-libs/+bug
- Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=cpdb-libs
- Upstream https://github.com/OpenPrinting/cpdb-libs/issues
TODO: - The package has important open bugs, listing them: TBD
TODO-A: - The package does not deal with exotic hardware we cannot support
TODO-B: - The package does deal with exotic hardware, it is present at TBD
TODO-B: to be able to test, fix and verify bugs
[Quality assurance - testing]
RULE: - The package must include a non-trivial test suite
RULE: - it should run at package build and fail the build if broken
TODO-A: - The package runs a test suite on build time, if it fails
TODO-A: it makes the build fail, link to build log TBD
TODO-B: - The package does not run a test at build time because TBD
RULE: - The package should, but is not required to, also contain
RULE: non-trivial autopkgtest(s).
TODO-A: - The package runs an autopkgtest, and is currently passing on
TODO-A: this TBD list of architectures, link to test logs TBD
TODO-B: - The package does not run an autopkgtest because TBD
RULE: - existing but failing tests that shall be handled as "ok to fail"
RULE: need to be explained along the test logs below
TODO-A: - The package does have not failing autopkgtests right now
TODO-B: - The package does have failing autopkgtests tests right now, but since
TODO-B: they always failed they are handled as "ignored failure", this is
TODO-B: ok because TBD
RULE: - If no build tests nor autopkgtests are included, and/or if the package
RULE: requires specific hardware to perform testing, the subscribed team
RULE: must provide a written test plan in a comment to the MIR bug, and
RULE: commit to running that test either at each upload of the package or
RULE: at least once each release cycle. In the comment to the MIR bug,
RULE: please link to the codebase of these tests (scripts or doc of manual
RULE: steps) and attach a full log of these test runs. This is meant to
RULE: assess their validity (e.g. not just superficial)
TODO: - The package can not be tested at build or autopktest time because TBD
TODO: to make up for that here TBD is a test plan/automation and example
TODO: test TBD (logs/scripts)
RULE: - In some cases a solution that is about to be promoted consists of
RULE: several very small libraries and one actual application uniting them
RULE: to achieve something useful. This is rather common in the go/rust space.
RULE: In that case often these micro-libs on their own can and should only
RULE: provide low level unit-tests. But more complex autopkgtests make no
RULE: sense on that level. Therefore in those cases one might want to test on
RULE: the solution level.
RULE: - Process wise MIR-requesting teams can ask (on the bug) for this
RULE: special case to apply for a given case, which reduces the test
RULE: constraints on the micro libraries but in return increases the
RULE: requirements for the test of the actual app/solution.
RULE: - Since this might promote micro-lib packages to main with less than
RULE: the common level of QA any further MIRed program using them will have
RULE: to provide the same amount of increased testing.
TODO: - This package is minimal and will be tested in a more wide reaching
TODO: solution context TBD, details about this testing are here TBD
[Quality assurance - packaging]
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 d/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-B: 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: - [[https://refspecs.linuxfoundation.org/fhs.shtml|FHS]]
RULE: - [[http://www.debian.org/doc/debian-policy/|Debian Policy]]
TODO-A: - This package correctly follows FHS and Debian Policy
TODO-B: - This package violates FHS or Debian Polciy, 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, which is set as a package bug contact. This is not a
RULE: requirement for the MIR team ACK, but for the package to be promoted
RULE: by an archive admin. Still, it is strongly suggested to subscribe,
RULE: as the owning team will get a preview of the to-be-expected incoming
RULE: 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: - Owning Team will be TBD
TODO-A: - Team is already subscribed to the package
TODO-B: - Team is not yet, but will subscribe to 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: - 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 ecosytem 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: - Right now that tooling to get a Cargo.lock that will include internal
RULE: vendored dependencies isn't in place yet (expect a dh-cargo change
RULE: later). Until it is available, as a fallback one can scan the
RULE: directory at build time and let it be generated in debian/rules.
RULE: An example might look like:
RULE: d/rules:
RULE: override_dh_auto_test:
RULE: CARGO_HOME=debian /usr/share/cargo/bin/cargo test --offline
RULE: d/<pkg>.install:
RULE: Cargo.lock /usr/share/doc/<pkg>
RULE: d/config.toml
RULE: # Use the vendorized sources to produce the Cargo.lock file. This
RULE: # can be performed by pointing $CARGO_HOME to the path containing
RULE: # this file.
RULE: [source]
RULE: [source.my-vendor-source]
RULE: directory = "vendor"
RULE: [source.crates-io]
RULE: replace-with = "my-vendor-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 shiped 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: - if there has been an archive test rebuild that has occurred more recently
RULE: than the last upload, the package must have rebuilt successfully
TODO-A: - The package has been built in the archive more recently than the last
TODO-A: test rebuild
TODO-B: - The package successfully built during the most recent test rebuild
TODO-C: - The package was test rebuilt in PPA or sbuild recently (provide link/logs)
[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
============================================================
Original, old-generation MIR description
[Availability]
Already in universe
Built for all supported architectures
[Rationale]
The Common Printing Dialog Backends (CPDB) project of OpenPrinting is about separating the print dialogs of different GUI toolkits and applications (GTK, Qt, Firefox, Chromium, LibreOffice, ...) from the different print technologies (CUPS, print to file, cloud printing services, ...) so that they can get developed independently and so always from all applications one can print with all print technologies and changes in the print technologies get supported quickly.
If one opens the print dialog, the dialog will not talk directly to CUPS, a cloud printing service, or any other printing system. For this communication there are the backends. The dialog will find all available backends and sends commands to them, for listing all available printers, giving property/option lists for the selected printers, and printing on the selected printer. This communication is done via D-Bus. So the backends are easily exchangeable and for getting support for a new print technology only its backend needs to get added.
Backends can even be packaged as Snaps, because they communicate only by D-Bus with the frontend, so a cloud printing provider could put their backend into the Snap Store.
[Security]
No known security issues, no CVEs for cpdb-libs known.
The backends are triggered via session D-Bus and always run as the same user as the calling print dialog, so they do not introduce additional security problems.
The separation of the communication with individual print technologies makes this code only be needed once (in the appropriate backend) instead of in each print dialog. This simplifies the security maintenance.
[Quality assurance]
- The Ubuntu Printing Team is subscribed.
https://bugs.launchpad.net/ubuntu/+source/cpdb-libs
https://github.com/OpenPrinting/cpdb-libs/issues
No upstream tests or autopkgtests.
[Dependencies]
CUPS, libcupsfilters, Glib, D-Bus -> all in main.
[Standards compliance]
The package meets the FHS and Debian Policy standards (4.1.0)
[Maintenance]
- Actively developed upstream. Last release was 2.0b1
https://github.com/OpenPrinting/cpdb-libs/commits/master |
[Availability]
The package cpdb-libs is already in Ubuntu universe.
The package cpdb-libs build for the architectures it is designed to work on.
It currently builds and works for architetcures: amd64, arm64, armhf, ppc64el, riscv64, s390x
Link to package https://launchpad.net/ubuntu/+source/cpdb-libs
[Rationale]
The Common Printing Dialog Backends (CPDB) project of OpenPrinting is about separating the print dialogs of different GUI toolkits and applications (GTK, Qt, Firefox, Chromium, LibreOffice, ...) from the different print technologies (CUPS, print to file, cloud printing services, ...) so that they can get developed independently and so always from all applications one can print with all print technologies and changes in the print technologies get supported quickly.
If one opens the print dialog, the dialog will not talk directly to CUPS, a cloud printing service, or any other printing system. For this communication there are the backends. The dialog will find all available backends and sends commands to them, for listing all available printers, giving property/option lists for the selected printers, and printing on the selected printer. This communication is done via D-Bus. So the backends are easily exchangeable and for getting support for a new print technology only its backend needs to get added.
Backends can even be packaged as Snaps, because they communicate only by D-Bus with the frontend, so a cloud printing provider could put their backend into the Snap Store.
All packages providing a print dialog will get modified (upstream) to support CPDB with this library and then these packages will depend on cpdb-libs.
These packages are:
- GUI toolkits: GTK, Qt
- GUI applications with their own print dialogs: Firefox/Thunderbird,
Chromium/Chrome, LibreOffice, ...
The coding of the CPDB support in GTK and Qt got already done in GSoC 2022 and currently merge requests are worked on to be included upstream. Once they are upstream (and already before the next upstream releases) they will get added to Ubuntu as distro patches.
See
https://github.com/TinyTrebuchet/gsoc22/
The dialogs of the browsers and LibreOffice will be worked on in GSoC 2023:
https://wiki.linuxfoundation.org/gsoc/google-summer-code-2023-openprinting-projects#cpdb_support_for_application_s_print_dialogsfirefox_chromium_libreoffice
This is also needed for the upcoming New Architecture of printing, where we go all-IPP and do not use PPD files any more. The CUPS backend for the CPDB (cpdb-backend-cups) is already designed to not handle PPD files any more.
The New Architecture is introduced as standard part of the distro in Ubuntu 23.10 at the latest. Therefore cpdb-libs NEEDS to be in main before Feature Freeze 23.10, ideally some weeks before.
There are very good chances that the changes on GTK and Qt already land in 23.04. In this case we need cpdb-libs in Main already by Feature Freeze of 23.04. This way the CPDB-based print dilaog will be tested more before the switchover into the New Architecture will take place.
[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)
- Packages does not contain extensions to security-sensitive software
The backends are triggered via session D-Bus and always run as the same user as the calling print dialog, so they do not introduce additional security problems.
The separation of the communication with individual print technologies makes this code only be needed once (in the appropriate backend) instead of in each print dialog. This simplifies the security maintenance.
[Quality assurance - function/usage]
- The package works well right after install
Every package containing a print dialog using the CPDB installs this library as a dependency. The installed backends are auto-discovered via D-Bus, no configuration or setup needed.
To assure that at least one backend is installed we can
- TODO - Let the libcpdb-libs-frontend1 recommend cpdb-backend-file
- TODO - Let the cupsd package recommend cpdb-backend-cups
[Quality assurance - maintenance]
- The package is maintained well in Debian/Ubuntu and has not too many
and long term critical bugs open
- Ubuntu https://bugs.launchpad.net/ubuntu/+source/cpdb-libs/+bug
- Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=cpdb-libs
- Upstream https://github.com/OpenPrinting/cpdb-libs/issues
- No open bugs at all, only this MIR ...
- The package does not deal with exotic hardware we cannot support (it deals with interfacing between app and printing system, not printing system and printer)
[Quality assurance - testing]
- The package does not run a test at build time because it does not contain upstream "make check" or "make test".
- The package runs an autopkgtest (debian/tests/text-frontend-vs-cups-backend), and is currently passing on all architectures mentioned above under [Availability]
- The package does have not failing autopkgtests right now
[Quality assurance - packaging]
- debian/watch is present and works
- debian/control defines a correct Maintainer field
- Please link to a recent build log of the package: https://launchpadlibrarian.net/645903010/buildlog_ubuntu-lunar-amd64.cpdb-libs_1.2.0-2_BUILDING.txt.gz
- This package does not yield massive lintian Warnings, Errors:
E: cpdb-libs changes: bad-distribution-in-changes-file unstable
W: cpdb-libs source: newer-standards-version 4.6.2 (current is 4.6.1.0)
W: libcpdb-libs-tools: no-manual-page [usr/bin/print_frontend]
P: cpdb-libs source: very-long-line-length-in-source-file 537 > 512 [README.md:10]
- Lintian overrides are not present
Missing man page for usr/bin/print_frontend: This is only an example/development/debugging helper, not intended to be used by end users
very-long-line-length-in-source-file in README.md: Is only doc file, not beig parsed when using the package.
newer-standards-version 4.6.2: Standards version too new? Seems that something needs to get updated somewhere else in Ubuntu ...
- This package does not rely on obsolete or about to be demoted packages.
Depends only on libc6, libglib2.0, libcups2
- The package will be installed by default, but does not ask debconf
questions higher than medium
No debconf questions at all, AFAIK.
- Packaging and build is easy, link to d/rules
https://salsa.debian.org/printing-team/cpdb-libs/-/blob/debian/main/debian/rules
[UI standards]
- Application is not end-user facing (does not need translation)
- End-user applications without desktop file, not needed because this is a library, so not started by end users.
[Dependencies]
- No further depends or recommends dependencies that are not yet in main
Depends only on libc6, libglib2.0, libcups2
[Standards compliance]
- This package correctly follows FHS and Debian Policy
[Maintenance/Owner]
- Owning Team will be Ubuntu Printing Team - ubuntu-printing
- Team is already subscribed to the package
- This does not use static builds
- This does not use vendored code
- This package is not rust based
- The package has been built in the archive more recently than the last
test rebuild
[Background information]
The Package description explains the package well
Upstream Name is cpdb-libs (unchanged)
Link to upstream project https://github.com/OpenPrinting/cpdb-libs
============================================================
Original, old-generation MIR description
[Availability]
Already in universe
Built for all supported architectures
[Rationale]
The Common Printing Dialog Backends (CPDB) project of OpenPrinting is about separating the print dialogs of different GUI toolkits and applications (GTK, Qt, Firefox, Chromium, LibreOffice, ...) from the different print technologies (CUPS, print to file, cloud printing services, ...) so that they can get developed independently and so always from all applications one can print with all print technologies and changes in the print technologies get supported quickly.
If one opens the print dialog, the dialog will not talk directly to CUPS, a cloud printing service, or any other printing system. For this communication there are the backends. The dialog will find all available backends and sends commands to them, for listing all available printers, giving property/option lists for the selected printers, and printing on the selected printer. This communication is done via D-Bus. So the backends are easily exchangeable and for getting support for a new print technology only its backend needs to get added.
Backends can even be packaged as Snaps, because they communicate only by D-Bus with the frontend, so a cloud printing provider could put their backend into the Snap Store.
[Security]
No known security issues, no CVEs for cpdb-libs known.
The backends are triggered via session D-Bus and always run as the same user as the calling print dialog, so they do not introduce additional security problems.
The separation of the communication with individual print technologies makes this code only be needed once (in the appropriate backend) instead of in each print dialog. This simplifies the security maintenance.
[Quality assurance]
- The Ubuntu Printing Team is subscribed.
https://bugs.launchpad.net/ubuntu/+source/cpdb-libs
https://github.com/OpenPrinting/cpdb-libs/issues
No upstream tests or autopkgtests.
[Dependencies]
CUPS, libcupsfilters, Glib, D-Bus -> all in main.
[Standards compliance]
The package meets the FHS and Debian Policy standards (4.1.0)
[Maintenance]
- Actively developed upstream. Last release was 2.0b1
https://github.com/OpenPrinting/cpdb-libs/commits/master |
|
| 2023-01-16 21:24:06 |
Till Kamppeter |
cpdb-libs (Ubuntu): status |
Incomplete |
In Progress |
|
| 2023-01-16 21:24:17 |
Till Kamppeter |
cpdb-libs (Ubuntu): status |
In Progress |
Confirmed |
|
| 2023-01-16 21:24:42 |
Till Kamppeter |
bug |
|
|
added subscriber Sebastien Bacher |
| 2023-01-16 21:30:03 |
Till Kamppeter |
description |
[Availability]
The package cpdb-libs is already in Ubuntu universe.
The package cpdb-libs build for the architectures it is designed to work on.
It currently builds and works for architetcures: amd64, arm64, armhf, ppc64el, riscv64, s390x
Link to package https://launchpad.net/ubuntu/+source/cpdb-libs
[Rationale]
The Common Printing Dialog Backends (CPDB) project of OpenPrinting is about separating the print dialogs of different GUI toolkits and applications (GTK, Qt, Firefox, Chromium, LibreOffice, ...) from the different print technologies (CUPS, print to file, cloud printing services, ...) so that they can get developed independently and so always from all applications one can print with all print technologies and changes in the print technologies get supported quickly.
If one opens the print dialog, the dialog will not talk directly to CUPS, a cloud printing service, or any other printing system. For this communication there are the backends. The dialog will find all available backends and sends commands to them, for listing all available printers, giving property/option lists for the selected printers, and printing on the selected printer. This communication is done via D-Bus. So the backends are easily exchangeable and for getting support for a new print technology only its backend needs to get added.
Backends can even be packaged as Snaps, because they communicate only by D-Bus with the frontend, so a cloud printing provider could put their backend into the Snap Store.
All packages providing a print dialog will get modified (upstream) to support CPDB with this library and then these packages will depend on cpdb-libs.
These packages are:
- GUI toolkits: GTK, Qt
- GUI applications with their own print dialogs: Firefox/Thunderbird,
Chromium/Chrome, LibreOffice, ...
The coding of the CPDB support in GTK and Qt got already done in GSoC 2022 and currently merge requests are worked on to be included upstream. Once they are upstream (and already before the next upstream releases) they will get added to Ubuntu as distro patches.
See
https://github.com/TinyTrebuchet/gsoc22/
The dialogs of the browsers and LibreOffice will be worked on in GSoC 2023:
https://wiki.linuxfoundation.org/gsoc/google-summer-code-2023-openprinting-projects#cpdb_support_for_application_s_print_dialogsfirefox_chromium_libreoffice
This is also needed for the upcoming New Architecture of printing, where we go all-IPP and do not use PPD files any more. The CUPS backend for the CPDB (cpdb-backend-cups) is already designed to not handle PPD files any more.
The New Architecture is introduced as standard part of the distro in Ubuntu 23.10 at the latest. Therefore cpdb-libs NEEDS to be in main before Feature Freeze 23.10, ideally some weeks before.
There are very good chances that the changes on GTK and Qt already land in 23.04. In this case we need cpdb-libs in Main already by Feature Freeze of 23.04. This way the CPDB-based print dilaog will be tested more before the switchover into the New Architecture will take place.
[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)
- Packages does not contain extensions to security-sensitive software
The backends are triggered via session D-Bus and always run as the same user as the calling print dialog, so they do not introduce additional security problems.
The separation of the communication with individual print technologies makes this code only be needed once (in the appropriate backend) instead of in each print dialog. This simplifies the security maintenance.
[Quality assurance - function/usage]
- The package works well right after install
Every package containing a print dialog using the CPDB installs this library as a dependency. The installed backends are auto-discovered via D-Bus, no configuration or setup needed.
To assure that at least one backend is installed we can
- TODO - Let the libcpdb-libs-frontend1 recommend cpdb-backend-file
- TODO - Let the cupsd package recommend cpdb-backend-cups
[Quality assurance - maintenance]
- The package is maintained well in Debian/Ubuntu and has not too many
and long term critical bugs open
- Ubuntu https://bugs.launchpad.net/ubuntu/+source/cpdb-libs/+bug
- Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=cpdb-libs
- Upstream https://github.com/OpenPrinting/cpdb-libs/issues
- No open bugs at all, only this MIR ...
- The package does not deal with exotic hardware we cannot support (it deals with interfacing between app and printing system, not printing system and printer)
[Quality assurance - testing]
- The package does not run a test at build time because it does not contain upstream "make check" or "make test".
- The package runs an autopkgtest (debian/tests/text-frontend-vs-cups-backend), and is currently passing on all architectures mentioned above under [Availability]
- The package does have not failing autopkgtests right now
[Quality assurance - packaging]
- debian/watch is present and works
- debian/control defines a correct Maintainer field
- Please link to a recent build log of the package: https://launchpadlibrarian.net/645903010/buildlog_ubuntu-lunar-amd64.cpdb-libs_1.2.0-2_BUILDING.txt.gz
- This package does not yield massive lintian Warnings, Errors:
E: cpdb-libs changes: bad-distribution-in-changes-file unstable
W: cpdb-libs source: newer-standards-version 4.6.2 (current is 4.6.1.0)
W: libcpdb-libs-tools: no-manual-page [usr/bin/print_frontend]
P: cpdb-libs source: very-long-line-length-in-source-file 537 > 512 [README.md:10]
- Lintian overrides are not present
Missing man page for usr/bin/print_frontend: This is only an example/development/debugging helper, not intended to be used by end users
very-long-line-length-in-source-file in README.md: Is only doc file, not beig parsed when using the package.
newer-standards-version 4.6.2: Standards version too new? Seems that something needs to get updated somewhere else in Ubuntu ...
- This package does not rely on obsolete or about to be demoted packages.
Depends only on libc6, libglib2.0, libcups2
- The package will be installed by default, but does not ask debconf
questions higher than medium
No debconf questions at all, AFAIK.
- Packaging and build is easy, link to d/rules
https://salsa.debian.org/printing-team/cpdb-libs/-/blob/debian/main/debian/rules
[UI standards]
- Application is not end-user facing (does not need translation)
- End-user applications without desktop file, not needed because this is a library, so not started by end users.
[Dependencies]
- No further depends or recommends dependencies that are not yet in main
Depends only on libc6, libglib2.0, libcups2
[Standards compliance]
- This package correctly follows FHS and Debian Policy
[Maintenance/Owner]
- Owning Team will be Ubuntu Printing Team - ubuntu-printing
- Team is already subscribed to the package
- This does not use static builds
- This does not use vendored code
- This package is not rust based
- The package has been built in the archive more recently than the last
test rebuild
[Background information]
The Package description explains the package well
Upstream Name is cpdb-libs (unchanged)
Link to upstream project https://github.com/OpenPrinting/cpdb-libs
============================================================
Original, old-generation MIR description
[Availability]
Already in universe
Built for all supported architectures
[Rationale]
The Common Printing Dialog Backends (CPDB) project of OpenPrinting is about separating the print dialogs of different GUI toolkits and applications (GTK, Qt, Firefox, Chromium, LibreOffice, ...) from the different print technologies (CUPS, print to file, cloud printing services, ...) so that they can get developed independently and so always from all applications one can print with all print technologies and changes in the print technologies get supported quickly.
If one opens the print dialog, the dialog will not talk directly to CUPS, a cloud printing service, or any other printing system. For this communication there are the backends. The dialog will find all available backends and sends commands to them, for listing all available printers, giving property/option lists for the selected printers, and printing on the selected printer. This communication is done via D-Bus. So the backends are easily exchangeable and for getting support for a new print technology only its backend needs to get added.
Backends can even be packaged as Snaps, because they communicate only by D-Bus with the frontend, so a cloud printing provider could put their backend into the Snap Store.
[Security]
No known security issues, no CVEs for cpdb-libs known.
The backends are triggered via session D-Bus and always run as the same user as the calling print dialog, so they do not introduce additional security problems.
The separation of the communication with individual print technologies makes this code only be needed once (in the appropriate backend) instead of in each print dialog. This simplifies the security maintenance.
[Quality assurance]
- The Ubuntu Printing Team is subscribed.
https://bugs.launchpad.net/ubuntu/+source/cpdb-libs
https://github.com/OpenPrinting/cpdb-libs/issues
No upstream tests or autopkgtests.
[Dependencies]
CUPS, libcupsfilters, Glib, D-Bus -> all in main.
[Standards compliance]
The package meets the FHS and Debian Policy standards (4.1.0)
[Maintenance]
- Actively developed upstream. Last release was 2.0b1
https://github.com/OpenPrinting/cpdb-libs/commits/master |
[Availability]
The package cpdb-libs is already in Ubuntu universe.
The package cpdb-libs build for the architectures it is designed to work on.
It currently builds and works for architetcures: amd64, arm64, armhf, ppc64el, riscv64, s390x
Link to package https://launchpad.net/ubuntu/+source/cpdb-libs
[Rationale]
The Common Printing Dialog Backends (CPDB) project of OpenPrinting is about separating the print dialogs of different GUI toolkits and applications (GTK, Qt, Firefox, Chromium, LibreOffice, ...) from the different print technologies (CUPS, print to file, cloud printing services, ...) so that they can get developed independently and so always from all applications one can print with all print technologies and changes in the print technologies get supported quickly.
If one opens the print dialog, the dialog will not talk directly to CUPS, a cloud printing service, or any other printing system. For this communication there are the backends. The dialog will find all available backends and sends commands to them, for listing all available printers, giving property/option lists for the selected printers, and printing on the selected printer. This communication is done via D-Bus. So the backends are easily exchangeable and for getting support for a new print technology only its backend needs to get added.
Backends can even be packaged as Snaps, because they communicate only by D-Bus with the frontend, so a cloud printing provider could put their backend into the Snap Store.
All packages providing a print dialog will get modified (upstream) to support CPDB with this library and then these packages will depend on cpdb-libs.
These packages are:
- GUI toolkits: GTK, Qt
- GUI applications with their own print dialogs: Firefox/Thunderbird,
Chromium/Chrome, LibreOffice, ...
The coding of the CPDB support in GTK and Qt got already done in GSoC 2022 and currently merge requests are worked on to be included upstream. Once they are upstream (and already before the next upstream releases) they will get added to Ubuntu as distro patches.
See
https://github.com/TinyTrebuchet/gsoc22/
The dialogs of the browsers and LibreOffice will be worked on in GSoC 2023:
https://wiki.linuxfoundation.org/gsoc/google-summer-code-2023-openprinting-projects#cpdb_support_for_application_s_print_dialogsfirefox_chromium_libreoffice
This is also needed for the upcoming New Architecture of printing, where we go all-IPP and do not use PPD files any more. The CUPS backend for the CPDB (cpdb-backend-cups) is already designed to not handle PPD files any more.
The New Architecture is introduced as standard part of the distro in Ubuntu 23.10 at the latest. Therefore cpdb-libs NEEDS to be in main before Feature Freeze 23.10, ideally some weeks before.
There are very good chances that the changes on GTK and Qt already land in 23.04. In this case we need cpdb-libs in Main already by Feature Freeze of 23.04. This way the CPDB-based print dilaog will be tested more before the switchover into the New Architecture will take place.
[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)
- Packages does not contain extensions to security-sensitive software
The backends are triggered via session D-Bus and always run as the same user as the calling print dialog, so they do not introduce additional security problems.
The separation of the communication with individual print technologies makes this code only be needed once (in the appropriate backend) instead of in each print dialog. This simplifies the security maintenance.
[Quality assurance - function/usage]
- The package works well right after install
Every package containing a print dialog using the CPDB installs this library as a dependency. The installed backends are auto-discovered via D-Bus, no configuration or setup needed.
To assure that at least one backend is installed we can
- TODO - Let the libcpdb-libs-frontend1 recommend cpdb-backend-file
- TODO - Let cpdb-backend-cups get seeded. Letting cupsd recommending it
will only work temporarily, as in Ubuntu 23.10 we want to switch to
the CUPS Snap.
[Quality assurance - maintenance]
- The package is maintained well in Debian/Ubuntu and has not too many
and long term critical bugs open
- Ubuntu https://bugs.launchpad.net/ubuntu/+source/cpdb-libs/+bug
- Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=cpdb-libs
- Upstream https://github.com/OpenPrinting/cpdb-libs/issues
- No open bugs at all, only this MIR ...
- The package does not deal with exotic hardware we cannot support (it deals with interfacing between app and printing system, not printing system and printer)
[Quality assurance - testing]
- The package does not run a test at build time because it does not contain upstream "make check" or "make test".
- The package runs an autopkgtest (debian/tests/text-frontend-vs-cups-backend), and is currently passing on all architectures mentioned above under [Availability]
- The package does have not failing autopkgtests right now
[Quality assurance - packaging]
- debian/watch is present and works
- debian/control defines a correct Maintainer field
- Please link to a recent build log of the package: https://launchpadlibrarian.net/645903010/buildlog_ubuntu-lunar-amd64.cpdb-libs_1.2.0-2_BUILDING.txt.gz
- This package does not yield massive lintian Warnings, Errors:
E: cpdb-libs changes: bad-distribution-in-changes-file unstable
W: cpdb-libs source: newer-standards-version 4.6.2 (current is 4.6.1.0)
W: libcpdb-libs-tools: no-manual-page [usr/bin/print_frontend]
P: cpdb-libs source: very-long-line-length-in-source-file 537 > 512 [README.md:10]
- Lintian overrides are not present
Missing man page for usr/bin/print_frontend: This is only an example/development/debugging helper, not intended to be used by end users
very-long-line-length-in-source-file in README.md: Is only doc file, not beig parsed when using the package.
newer-standards-version 4.6.2: Standards version too new? Seems that something needs to get updated somewhere else in Ubuntu ...
- This package does not rely on obsolete or about to be demoted packages.
Depends only on libc6, libglib2.0, libcups2
- The package will be installed by default, but does not ask debconf
questions higher than medium
No debconf questions at all, AFAIK.
- Packaging and build is easy, link to d/rules
https://salsa.debian.org/printing-team/cpdb-libs/-/blob/debian/main/debian/rules
[UI standards]
- Application is not end-user facing (does not need translation)
- End-user applications without desktop file, not needed because this is a library, so not started by end users.
[Dependencies]
- No further depends or recommends dependencies that are not yet in main
Depends only on libc6, libglib2.0, libcups2
[Standards compliance]
- This package correctly follows FHS and Debian Policy
[Maintenance/Owner]
- Owning Team will be Ubuntu Printing Team - ubuntu-printing
- Team is already subscribed to the package
- This does not use static builds
- This does not use vendored code
- This package is not rust based
- The package has been built in the archive more recently than the last
test rebuild
[Background information]
The Package description explains the package well
Upstream Name is cpdb-libs (unchanged)
Link to upstream project https://github.com/OpenPrinting/cpdb-libs
============================================================
Original, old-generation MIR description
[Availability]
Already in universe
Built for all supported architectures
[Rationale]
The Common Printing Dialog Backends (CPDB) project of OpenPrinting is about separating the print dialogs of different GUI toolkits and applications (GTK, Qt, Firefox, Chromium, LibreOffice, ...) from the different print technologies (CUPS, print to file, cloud printing services, ...) so that they can get developed independently and so always from all applications one can print with all print technologies and changes in the print technologies get supported quickly.
If one opens the print dialog, the dialog will not talk directly to CUPS, a cloud printing service, or any other printing system. For this communication there are the backends. The dialog will find all available backends and sends commands to them, for listing all available printers, giving property/option lists for the selected printers, and printing on the selected printer. This communication is done via D-Bus. So the backends are easily exchangeable and for getting support for a new print technology only its backend needs to get added.
Backends can even be packaged as Snaps, because they communicate only by D-Bus with the frontend, so a cloud printing provider could put their backend into the Snap Store.
[Security]
No known security issues, no CVEs for cpdb-libs known.
The backends are triggered via session D-Bus and always run as the same user as the calling print dialog, so they do not introduce additional security problems.
The separation of the communication with individual print technologies makes this code only be needed once (in the appropriate backend) instead of in each print dialog. This simplifies the security maintenance.
[Quality assurance]
- The Ubuntu Printing Team is subscribed.
https://bugs.launchpad.net/ubuntu/+source/cpdb-libs
https://github.com/OpenPrinting/cpdb-libs/issues
No upstream tests or autopkgtests.
[Dependencies]
CUPS, libcupsfilters, Glib, D-Bus -> all in main.
[Standards compliance]
The package meets the FHS and Debian Policy standards (4.1.0)
[Maintenance]
- Actively developed upstream. Last release was 2.0b1
https://github.com/OpenPrinting/cpdb-libs/commits/master |
|
| 2023-01-17 15:38:47 |
Christian Ehrhardt |
cpdb-libs (Ubuntu): assignee |
|
Christian Ehrhardt (paelzer) |
|
| 2023-01-18 12:29:31 |
Christian Ehrhardt |
cpdb-libs (Ubuntu): assignee |
Christian Ehrhardt (paelzer) |
Ubuntu Security Team (ubuntu-security) |
|
| 2023-01-18 19:54:50 |
Steve Beattie |
tags |
|
sec-1605 |
|
| 2023-02-21 07:41:14 |
Till Kamppeter |
bug |
|
|
added subscriber Jeremy Bícha |
| 2023-05-26 01:11:44 |
Mark Esler |
cpdb-libs (Ubuntu): assignee |
Ubuntu Security Team (ubuntu-security) |
|
|
| 2023-05-26 01:11:51 |
Mark Esler |
cpdb-libs (Ubuntu): status |
Confirmed |
In Progress |
|
| 2023-05-26 01:11:59 |
Mark Esler |
bug |
|
|
added subscriber Mark Esler |
| 2023-05-26 09:45:51 |
Sebastien Bacher |
cpdb-libs (Ubuntu): status |
In Progress |
Fix Released |
|
