** Description changed: [Availability] TODO: The package gst-thumbnailers is already in Ubuntu universe. Not yet, https://bugs.launchpad.net/bugs/2137704 is tracking that. The package gst-thumbnailers builds for the architectures it is designed to work on. It currently builds and works for architectures: amd64, amd64v3, arm64, armhf, ppc64el, riscv64, s390x https://launchpad.net/~charles05/+archive/ubuntu/gst-thumbnailers [Rationale] - RULE: There must be a certain level of demand for the package The package gst-thumbnailers is required in Ubuntu main for GNOME desktop integration. gst-thumbnailers is the now officially recommended solution for thumbnailing, superceeding the Totem thumbnailers. See: https://gitlab.gnome.org/Teams/Releng/AppOrganization/-/issues/35 The package gst-thumbnailers will generally be useful for a large part of our user base. Package gst-thumbnailers covers the same use case as totem-video-thumbnailer, but is better because it's written in a memory-safe programming language, thereby we want to replace it. There is no other/better way to solve this that is already in main or should go universe->main instead of this. This is the first time package will be in main All binary packages built by gst-thumbnailers need to be in main to achieve consistency with GNOME. It would be great and useful to community/processes to have the package gst-thumbnailers in Ubuntu main, but there is no definitive deadline. [Security] No CVEs/security issues in this software in the past due to the project not seeing widespread adoption yet. no `suid` or `sgid` binaries no executables in `/sbin` and `/usr/sbin` Package does not install services, timers or recurring jobs Package does install services, timers or recurring jobs While GStreamer decoding functions are not isolated, and process untrusted inputs, the image encoding functions are isolated via Bubblewrap using libglycin. It's generally the responsibility of the thumbnailing frontend (e.g. GNOME Files) to run the thumbnailing engine in isolation. Packages does not open privileged ports (ports < 1024). Packages open privileged ports (ports < 1024), but they have a reason to do so (TBD) Package does not expose any external endpoints Packages does not contain extensions to security-sensitive software [Quality assurance - function/usage] The package works well right after install [Quality assurance - maintenance] The package is maintained well in Upstream and does not have too many, long-term & critical, open bugs Upstream's bug tracker: https://gitlab.gnome.org/GNOME/gst- thumbnailers/-/issues [Quality assurance - testing] The package runs a test suite on build time, if it fails it makes the build fail, link to build log https://launchpad.net/~charles05/+archive/ubuntu/gst-thumbnailers/+build/32133876 The package runs an autopkgtest, and is currently passing on this TBD list of architectures, link to test logs TBD See, https://salsa.debian.org/ubuntu-dev-team/gst-thumbnailers/-/tree/ubuntu/latest/debian/tests?ref_type=heads TODO: Awaiting initial upload to the archive to get an autopkgtest link. 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 - TODO: - Please link to a recent build log of the package: + Recent build log of the package: https://launchpadlibrarian.net/842965163/buildlog_ubuntu-resolute-amd64.gst-thumbnailers_1.0~alpha.1-1ubuntu1~ppa4_BUILDING.txt.gz Lintian overrides are present to disable nags about missing manual pages and an unknown field Vendored-Sources-Rust. This is OK because Lintian hasn't been taught about Rust vendoring, it seems. This package does not rely on obsolete or about to be demoted packages. The package will be installed by default, but does not ask debconf questions higher than medium Packaging and build is easy, link to debian/rules: - https://salsa.debian.org/ubuntu-dev-team/gst-thumbnailers/-/blob/ubuntu/latest/debian/rules?ref_type=heads + https://salsa.debian.org/ubuntu-dev-team/gst-thumbnailers/-/blob/ubuntu/latest/debian/rules?ref_type=heads [UI standards] Application is not end-user facing (does not need translation) [Dependencies] Used check-mir from ubuntu-dev-tools to validate all dependencies or recommends are in main. [Standards compliance] This package correctly follows FHS and Debian Policy [Maintenance/Owner] - The owning team will be ubuntu-desktop and I have their acknowledgment for - that commitment + I suggest the owning team will be ~desktop-packages - RULE: - Responsibilities implied by static builds promoted to main, which is - RULE: not a recommended but a common case with golang and rust packages. - RULE: - the security team will track CVEs for all vendored/embedded sources in main - RULE: - the security team will provide updates to main for all `golang-*-dev` - RULE: packages - RULE: - the security team will provide updates to main for non-vendored - RULE: dependencies as per normal procedures (including e.g., - RULE: sponsoring/coordinating uploads from teams/upstream projects, etc) - RULE: - the security team will perform no-change-rebuilds for all packages - RULE: listing an CVE-fixed package as Built-Using and coordinate testing - RULE: with the owning teams responsible for the rebuilt packages - RULE: - for packages that build using any `golang-*-dev` packages: - RULE: - the owning team must state their commitment to test - RULE: no-change-rebuilds triggered by a dependent library/compiler and to - RULE: fix any issues found for the lifetime of the release (including ESM - RULE: when included) - RULE: - the owning team must provide timely testing of no-change-rebuilds - RULE: from the security team, fixing the rebuilt package as necessary - RULE: - for packages that build with approved vendored code: - RULE: - the owning team must state their commitment to provide updates to - RULE: the security team for any affected vendored code for the lifetime of - RULE: the release (including ESM when included) - RULE: - the security team will alert the owning team of issues that may - RULE: affect their vendored code - RULE: - the owning team will provide timely, high quality updates for the - RULE: security team to sponsor to fix issues in the affected vendored code - RULE: - the owning team will use a minimal set of vendored code (e.g., Rust - RULE: packages are unlikely to need `*_win` crates to build) - RULE: - if subsequent uploads add new vendored components or dependencies - RULE: these have to be reviewed and agreed by the security team. - RULE: - Such updates in the project might be trivial, but imply that a - RULE: dependency for e.g. a CVE fix will be moved to a new major version. - RULE: Being vendored that does gladly at least not imply incompatibility - RULE: issues with other packages or the SRU policy. But it might happen - RULE: that this triggers either: - RULE: a) The need to adapt the current version of the main package and/or - RULE: other vendored dependencies to work with the new dependency - RULE: b) The need to backport the fix in the dependency as the main - RULE: package will functionally only work well with the older version - RULE: c) The need to backport the fix in the dependency, as it would imply - RULE: requiring a newer toolchain to be buildable that isn't available - RULE: in the target release. - RULE: - The rust ecosystem currently isn't yet considered stable enough for - RULE: classic lib dependencies and transitions in main; therefore the - RULE: expectation for those packages is to vendor (and own/test) all - RULE: dependencies (except those provided by the rust runtime itself). - RULE: This implies that all the rules for vendored builds always - RULE: apply to them. In addition: - RULE: - The rules and checks for rust based packages are preliminary and might - RULE: change over time as the ecosystem matures and while - RULE: processing the first few rust based packages. - RULE: - It is expected rust builds will use dh-cargo so that a later switch - RULE: to non vendored dependencies isn't too complex (e.g. it is likely - RULE: that over time more common libs shall become stable and then archive - RULE: packages will be used to build). - RULE: - The tooling to get a Cargo.lock that will include internal vendored - RULE: dependencies is described at: - RULE: https://github.com/ubuntu/ubuntu-project-docs/blob/main/docs/MIR/mir-rust.md - RULE: - An example of how Rust dependency vendoring can be automated is - RULE: "s390-tools", isolating crates in a .orig-vendor.tar.xz tarball: - RULE: * https://git.launchpad.net/ubuntu/+source/s390-tools/tree/debian/rules - RULE: Other examples include "authd" (for a native package, combined with - RULE: Golang vendoring) and "gnome-snapshot" (using debian/missing-sources): - RULE: * authd: - RULE: https://github.com/ubuntu/authd/blob/main/debian/rules - RULE: * gnome-snapshot: - RULE: https://salsa.debian.org/ubuntu-dev-team/snapshot/-/blob/ubuntu/latest/debian/README.source + The future owning team is not yet subscribed, but will subscribe to + the package before promotion. - RULE: - All vendored dependencies (no matter what language) shall have a - RULE: way to be refreshed - TODO-A: - This does not use static builds - TODO-B: - The team TBD is aware of the implications by a static build and - TODO-B: commits to test no-change-rebuilds and to fix any issues found for the - TODO-B: lifetime of the release (including ESM) + The team ~ubuntu-desktop is aware of the implications by a static build and + commits to test no-change-rebuilds and to fix any issues found for the + lifetime of the release (including ESM) - TODO-A: - This does not use vendored code - TODO-B: - The team TBD is aware of the implications of vendored code and (as - TODO-B: alerted by the security team) commits to provide updates and backports - TODO-B: to the security team for any affected vendored code for the lifetime - TODO-B: of the release (including ESM). + The team ~ubuntu-desktop is aware of the implications of vendored code + and (as alerted by the security team) commits to provide updates and + backports to the security team for any affected vendored code for the + lifetime of the release (including ESM). - TODO-A: - This does not use vendored code - TODO-B: - This package uses vendored go code tracked in go.sum as shipped in the - TODO-B: package, refreshing that code is outlined in debian/README.source - TODO-C: - This package uses vendored rust code tracked in Cargo.lock as shipped, - TODO-C: in the package (at /usr/share/doc/<pkgname>/Cargo.lock - might be - TODO-C: compressed), refreshing that code is outlined in debian/README.source - TODO-D: - This package uses vendored code, refreshing that code is outlined - TODO-D: in debian/README.source + This package uses vendored rust code tracked in Cargo.lock as shipped, + in the package (at /usr/share/doc/<pkgname>/Cargo.lock - might be + compressed), refreshing that code is outlined in debian/README.source - TODO-A: - This does not use vendored code - TODO-B: - This package uses vendored code, the debian/copyright has been - TODO-B: updated to cover the vendored content + This package uses vendored code, refreshing that code is outlined + in debian/README.source - TODO-A: - This package is not rust based - TODO-B: - This package is rust based and vendors all non language-runtime - TODO-B: dependencies + This package uses vendored code, the debian/copyright has been + updated to cover the vendored content - RULE: - Some packages build and update often, in this case everyone can just - RULE: check the recent build logs to ensure if it builds fine. - RULE: But some other packages are rather stable and have not been rebuilt - RULE: in a long time. There no one can be confident it would build on e.g. - RULE: an urgent security fix. Hence we ask if there has been a recent build. - RULE: That might be a recent build that has been done anyway as seen on - RULE: https://launchpad.net/ubuntu/+source/<source>, a reference to a recent - RULE: archive test rebuild (those are announced on the ubuntu-devel mailing - RULE: list like https://lists.ubuntu.com/archives/ubuntu-devel-announce/2024-January/001342.html), - RULE: or a build set up by the reporter in a PPA with all architectures - RULE: enabled. - TODO-A: - The package has been built within the last 3 months in the archive - TODO-B: - The package has been built within the last 3 months as part - TODO-B: of a test rebuild - TODO-C: - The package has been built within the last 3 months in PPA - TODO-D: - The package has been built within the last 3 months in sbuild as it - TODO-D: can not be uploaded yet - RULE: - To make it easier for everyone, please provide a link to that build so - RULE: everyone can follow up easily e.g. checking the various architectures. - RULE: Example https://launchpad.net/ubuntu/+source/qemu/1:8.2.2+ds-0ubuntu1 - TODO: - Build link on launchpad: TBD + This package is rust based and vendors all non language-runtime + dependencies - RULE: A few times we had packages that seemed fine for the package itself, but - RULE: caused quite some fallout and effort in related teams. We'd ask you to - RULE: think who else might be affected by promoting this package(s) and to - RULE: please coordinate with them upfront so they have time, understanding and - RULE: sympathy available. - RULE: Examples of the past which we admit could have been better (grows by - RULE: painful lessons learned): - RULE: - changing to rust coreutils forced us to update any apparmor profiles - RULE that referred to these paths - TODO-A: This change will not impact other teams - TODO-B: This change will impact other teams TBD[, TBD] and they are - TODO-B: aware due to TBD + The package has been built within the last 3 months in PPA + + Build link on launchpad: + https://launchpad.net/~charles05/+archive/ubuntu/gst-thumbnailers + + This change will not impact other teams [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 + + The Package description explains the package well + + Upstream Name is gst-thumbnailers + + Link to upstream project: https://gitlab.gnome.org/GNOME/gst- + thumbnailers
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2137712 Title: [MIR] gst-thumbnailers To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+bug/2137712/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
