Public bug reported: [Availability] The package rust-gst-plugin-gtk4 is already in Ubuntu universe. The package rust-gst-plugin-gtk4 build for the architectures it is designed to work on. It currently builds and works for all Ubuntu architectures except for i386 Link to package https://launchpad.net/ubuntu/+source/rust-gst-plugin-gtk4
[Rationale] - The package gstreamer1.0-gtk4 (built from source rust-gst-plugin-gtk4) is required in Ubuntu main for gnome-snapshot - The package gstreamer1.0-gtk4 will generally be useful for a large part of our user base - The package gstreamer1.0-gtk4 is a new runtime dependency of package gnome-snapshot that we already support - There is no other/better way to solve this that is already in main or should go universe->main instead of this. - The binary package gstreamer1.0-gtk4 needs to be in main to achieve keeping gnome-snapshot up-to-date and supported. - The package gstreamer1.0-gtk4 is required in Ubuntu main no later than February 20 due to Ubuntu 25.04 Feature Freeze Practically, we will likely need a Feature Freeze Exception for this. [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 [Quality assurance - function/usage] - The package works well right after install [Quality assurance - maintenance] - The package is maintained well in Debian/Ubuntu/Upstream and does not have too many, long-term & critical, open bugs + Ubuntu https://bugs.launchpad.net/ubuntu/+source/rust-gst-plugin-gtk4 + Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=rust-gst-plugin-gtk4 + Upstream https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues (upstream uses a monorepo; the relevant bugs for this package are the ones that involve gtk4) - The package does not deal with exotic hardware we cannot support [Quality assurance - testing] RULE: - The package must include a non-trivial test suite RULE: - it should run at package build and fail the build if broken TODO-A: - The package runs a test suite on build time, if it fails TODO-A: it makes the build fail, link to build log TBD TODO-B: - The package does not run a test at build time because TBD RULE: - The package should, but is not required to, also contain RULE: non-trivial autopkgtest(s). TODO-A: - The package runs an autopkgtest, and is currently passing on TODO-A: this TBD list of architectures, link to test logs TBD TODO-B: - The package does not run an autopkgtest because TBD RULE: - existing but failing tests that shall be handled as "ok to fail" RULE: need to be explained along the test logs below TODO-A: - The package does have not failing autopkgtests right now TODO-B: - The package does have failing autopkgtests tests right now, but since TODO-B: they always failed they are handled as "ignored failure", this is TODO-B: ok because TBD RULE: - If no build tests nor autopkgtests are included, and/or if the package RULE: requires specific hardware to perform testing, the subscribed team RULE: must provide a written test plan in a comment to the MIR bug, and RULE: commit to running that test either at each upload of the package or RULE: at least once each release cycle. In the comment to the MIR bug, RULE: please link to the codebase of these tests (scripts or doc of manual RULE: steps) and attach a full log of these test runs. This is meant to RULE: assess their validity (e.g. not just superficial). RULE: If possible such things should stay in universe. Sometimes that is RULE: impossible due to the way how features/plugins/dependencies work RULE: but if you are going to ask for promotion of something untestable RULE: please outline why it couldn't provide its value (e.g. by splitting RULE: binaries) to users from universe. RULE: This is a balance that is hard to strike well, the request is that all RULE: options have been exploited before giving up. Look for more details RULE: and backgrounds https://github.com/canonical/ubuntu-mir/issues/30 RULE: Just like in the SRU process it is worth to understand what the RULE: consequences a regression (due to a test miss) would be. Therefore RULE: if being untestable we ask to outline what consequences this would RULE: have for the given package. And let us be honest, even if you can RULE: test you are never sure you will be able to catch all potential RULE: regressions. So this is mostly to force self-awareness of the owning RULE: team than to make a decision on. TODO: - The package can not be well tested at build or autopkgtest time TODO: because TBD. To make up for that: TODO-A: - We have access to such hardware in the team TODO-B: - We have allocated budget to get this hardware, but it is not here TODO-B: yet TODO-C: - We have checked with solutions-qa and will use their hardware TODO-C: through testflinger TODO-D: - We have checked with other team TBD and will use their hardware TODO-D: through TBD (eg. MAAS) TODO-E: - We have checked and found a simulator which covers this case TODO-E: sufficiently for testing, our plan to use it is TBD TODO-F: - We have engaged with the upstream community and due to that TODO-F: can tests new package builds via TBD TODO-G: - We have engaged with our user community and due to that TODO-G: can tests new package builds via TBD TODO-H: - We have engaged with the hardware manufacturer and made an TODO-H: agreement to test new builds via TBD TODO-A-H: - Based on that access outlined above, here are the details of the TODO-A-H: test plan/automation TBD (e.g. script or repo) and (if already TODO-A-H: possible) example output of a test run: TBD (logs). TODO-A-H: We will execute that test plan TODO-A-H1: on-uploads TODO-A-H2: regularly (TBD details like frequency: monthly, infra: jira-url) TODO-X: - We have exhausted all options, there really is no feasible way TODO-X: to test or recreate this. We are aware of the extra implications TODO-X: and duties this has for our team (= help SEG and security on TODO-X: servicing this package, but also more effort on any of your own TODO-X: bug triage and fixes). TODO-X: Due to TBD there also is no way to provide this to users from TODO-X: universe. TODO-X: Due to the nature, integration and use cases of the package the TODO-X: consequences of a regression that might slip through most likely TODO-X: would include TODO-X: - TBD TODO-X: - TBD TODO-X: - TBD RULE: - In some cases a solution that is about to be promoted consists of RULE: several very small libraries and one actual application uniting them RULE: to achieve something useful. This is rather common in the go/rust space. RULE: In that case often these micro-libs on their own can and should only RULE: provide low level unit-tests. But more complex autopkgtests make no RULE: sense on that level. Therefore in those cases one might want to test on RULE: the solution level. RULE: - Process wise MIR-requesting teams can ask (on the bug) for this RULE: special case to apply for a given case, which reduces the test RULE: constraints on the micro libraries but in return increases the RULE: requirements for the test of the actual app/solution. RULE: - Since this might promote micro-lib packages to main with less than RULE: the common level of QA any further MIRed program using them will have RULE: to provide the same amount of increased testing. TODO: - This package is minimal and will be tested in a more wide reaching TODO: solution context TBD, details about this testing are here TBD [Quality assurance - packaging] - debian/watch is present and works - debian/control defines a correct Maintainer field - This package does not yield massive lintian Warnings, Errors - Lintian overrides are not present - This package does not rely on obsolete or about to be demoted packages. - This package has no python2 or GTK2 dependencies - The package will be installed by default, but does not ask debconf questions - Packaging and build is easy, link to debian/rules https://salsa.debian.org/rust-team/debcargo-conf/-/blob/master/src/gst-plugin-gtk4/debian/rules [UI standards] - Application is not end-user facing (does not need translation or .desktop file) [Dependencies] - No further depends or recommends dependencies that are not yet in main [Standards compliance] - This package correctly follows FHS and Debian Policy [Maintenance/Owner] - The owning team will be Desktop Packages and I have their acknowledgement for that commitment - The future owning team is not yet subscribed, but will subscribe to the package before promotion - This does not use static builds 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-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-B: - This package is rust based and vendors all non language-runtime TODO-B: dependencies - The package has been built within the last 3 months in the archive - Build link on launchpad: https://launchpad.net/ubuntu/+source/rust-gst-plugin-gtk4/0.13.3-2 [Background information] The Package description explains the package well Upstream Name is rust-gst-plugin-gtk4 Link to upstream project https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/tree/main/video/gtk4 rust-gst-plugin-gtk4 will also be needed for Showtime, GNOME's new video player. GNOME is expected to switch from totem to showtime for GNOME 49 (September 2025). Specifically, we only need the binary package gstreamer1.0-gtk4 in main. It is a gstreamer plugin so it's a runtime dependency of some apps. ** Affects: rust-gst-plugin-gtk4 (Ubuntu) Importance: Undecided Assignee: Jeremy Bícha (jbicha) Status: Incomplete ** Changed in: rust-gst-plugin-gtk4 (Ubuntu) Status: New => Incomplete ** Changed in: rust-gst-plugin-gtk4 (Ubuntu) Assignee: (unassigned) => Jeremy Bícha (jbicha) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2097804 Title: [MIR] rust-gst-plugin-gtk4 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rust-gst-plugin-gtk4/+bug/2097804/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
