** Description changed: [Introduction] The current structure of gst-plugins-bad1.0 presents several challenges for its wholesale inclusion in main, particularly concerning its dependencies and the ongoing difficulties upstream in categorising GStreamer elements. This proposal seeks to address these issues by creating a new binary package, gstreamer1.0-plugins-extra, to house a targeted subset of components currently residing in the gst-plugins-bad1.0 source package. Upstream GStreamer development has consistently struggled with the classification and reorganisation of its elements. Attempts to split elements, such as those detailed in [1], or reorganise release tarballs [2], have frequently stalled. Similarly, proposals to move smaller, stable components from -bad to -good, even when championed by experienced upstream maintainers, have met with similar delays [3, 4]. While upstream wants to promote plugins from -bad to -good, it is not a high priority for them, and promises to do so have frequently slipped from release to release. Despite these upstream challenges, a significant driver for this proposal is the presence of hard dependencies on gst-plugins-bad1.0 components from existing main packages. To date, workarounds for these dependencies have involved unsustainable practices, including: - - Vendoring an obsolete playback library within GTK4. - - Patching gstreamer1.0-plugins-good (a main package) with elements - that originate from gstreamer1.0-plugins-bad (a universe package). + - Vendoring an obsolete playback library within GTK4. + - Patching gstreamer1.0-plugins-good (a main package) with elements + that originate from gstreamer1.0-plugins-bad (a universe package). These workarounds not only bypass essential security reviews but also introduce a considerable maintenance burden due to the need to perpetually update these patches. This often results in users unknowingly relying on outdated and potentially vulnerable versions of these patched components. Further details and discussion regarding this proposed split can be found in the Launchpad bug report [5]. Therefore, to resolve these issues and establish a more future-proof solution, this MIR proposes creating a new binary package, gstreamer1.0-plugins-extra, from the existing gst-plugins-bad1.0 source package. This naming convention aligns with prior upstream discussions and agreements regarding element nomenclature [2]. This split will allow essential GNOME-related dependencies to reside in a main eligible package, facilitating proper security review and reducing the maintenance overhead currently imposed by the workarounds. [1] https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6130 [2] https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3320 [3] https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1758 [4] https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2386 [5] https://bugs.launchpad.net/ubuntu/+source/gst-plugins-bad1.0/+bug/2027594 [Availability] The package gst-plugins-bad1.0 is already in Ubuntu universe. The package gst-plugins-bad1.0 build for the architectures it is designed to work on. It currently builds and works for architectures: amd64, arm64, armhf, i386, riscv64 s390x Link to package https://launchpad.net/ubuntu/+source/gst-plugins-bad1.0 [Rationale] RULE: There must be a certain level of demand for the package A subset of the package gst-plugins-bad1.0 is required in Ubuntu main for the reasons outlined in the introduction. The subset of gst-plugins-bad1.0 will generally be useful for a large part of our user base. RULE: Sometimes there are other/better ways, often are achieved by using a RULE: library with similar functionality that is more commonly used and RULE: thereby already in main or a better candidate to promote. RULE: Reducing the set of supported software in Ubuntu helps to focus on the RULE: right things, otherwise Ubuntu developers will be consumed by updating RULE: many variations of the same - wasting valuable time that could be better RULE: spent elsewhere. RULE: If there are other packages in the archive that are close, but unable to RULE: address the problem you might spend some time explaining what exists and RULE: why it isn't a sufficient alternative. There is no other/better way to solve this that is already in main or should go universe->main instead of this if we wish to be in line with GNOME. RULE: If the package previously was in main (use rmadison to check), RULE: and the previous MIR content is still applicable and not ancient, RULE: just add a new release-task instead of creating a new MIR. RULE: Otherwise, continue with this MIR and link to the previous MIR. This is the first time package will be in main RULE: You truly need to understand the difference between main and universe RULE: in general and in the context of changed rules (build-depends) and RULE: constraints (Ubuntu Pro made it less of a difference in many cases). RULE: We have seen requests that were mostly based on old "I said supported (a RULE: weakly defined term to begin with) in a contract, so it has to be in main" RULE: feelings, but with sometimes no true reason - neither technically nor RULE: helping the user base of Ubuntu. Hence we need to ask for that clearly. The binary package gst-plugins-extra1.0 needs to be in main to achieve basic media functionality in the existing desktop package set. All other binary packages built by gst-plugins-bad1.0 should remain in universe. 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 prioritization 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 The package gst-plugins-extra1.0 is required in Ubuntu main no later than 26.04 due to the desktop moving from Totem to Showtime, and to ensure the other dependents of gst-plugins-extra1.0 can stop vendoring / patching. [Security] In terms of new code to review, the shared objects proposed for inclusion are, gstreamer1.0-plugins-extra_1.26.4-1ubuntu2_amd64.deb -rw-r--r-- root/root 92888 2025-08-04 11:44 ./usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstcamerabin.so -rw-r--r-- root/root 576024 2025-08-04 11:44 ./usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstva.so libgstreamer-plugins-extra1.0-0_1.26.5-1ubuntu2_amd64.deb -rw-r--r-- root/root 31048 2025-08-18 15:54 ./usr/lib/x86_64-linux-gnu/libgstbasecamerabinsrc-1.0.so.0.2605.0 -rw-r--r-- root/root 859520 2025-08-18 15:54 ./usr/lib/x86_64-linux-gnu/libgstcodecparsers-1.0.so.0.2605.0 -rw-r--r-- root/root 231752 2025-08-18 15:54 ./usr/lib/x86_64-linux-gnu/libgstcodecs-1.0.so.0.2605.0 -rw-r--r-- root/root 39080 2025-08-18 15:54 ./usr/lib/x86_64-linux-gnu/libgstphotography-1.0.so.0.2605.0 -rw-r--r-- root/root 145736 2025-08-18 15:54 ./usr/lib/x86_64-linux-gnu/libgstplay-1.0.so.0.2605.0 -rw-r--r-- root/root 90064 2025-08-18 15:54 ./usr/lib/x86_64-linux-gnu/libgstva-1.0.so.0.2605.0 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: https://cve.mitre.org/cve/search_cve_list.html I did not see any CVEs for the plugins / libraries we're proposing to be moved over. RULE: - check OSS security mailing list (feed into search engine RULE: 'site:www.openwall.com/lists/oss-security <pkgname>') Nothing found here either. RULE: - Ubuntu CVE Tracker RULE: https://ubuntu.com/security/cve?package=<source-package-name> - "The security API is down. An error occurred while fetching security data" RULE: - Debian Security Tracker RULE: https://security-tracker.debian.org/tracker/source-package/<source-package-name> Had 8 security issues in the past. All were in the codecparsing component. - - https://security-tracker.debian.org/tracker/TEMP-0000000-C6AAE1 - - https://security-tracker.debian.org/tracker/CVE-2025-6663 - - https://security-tracker.debian.org/tracker/CVE-2025-3887 - - https://security-tracker.debian.org/tracker/CVE-2023-50186 - - https://security-tracker.debian.org/tracker/CVE-2023-44429 - - https://security-tracker.debian.org/tracker/CVE-2023-40475 - - https://security-tracker.debian.org/tracker/CVE-2021-3185 - - https://security-tracker.debian.org/tracker/CVE-2016-9809 (since refactored into codecparsers) + - https://security-tracker.debian.org/tracker/TEMP-0000000-C6AAE1 + - https://security-tracker.debian.org/tracker/CVE-2025-6663 + - https://security-tracker.debian.org/tracker/CVE-2025-3887 + - https://security-tracker.debian.org/tracker/CVE-2023-50186 + - https://security-tracker.debian.org/tracker/CVE-2023-44429 + - https://security-tracker.debian.org/tracker/CVE-2023-40475 + - https://security-tracker.debian.org/tracker/CVE-2021-3185 + - https://security-tracker.debian.org/tracker/CVE-2016-9809 (since refactored into codecparsers) All were handled properly, but this is a significant risk. Codec parsing is notorious for security issues across platforms, and applications using this component absolutely should be sandboxed. RULE: - Check for security relevant binaries, services and behavior. RULE: If any are present, this requires a more in-depth security review. RULE: Demonstrating that common isolation/risk-mitigation patterns are used RULE: will help to raise confidence. For example a service running as root RULE: open to the network will need to be considered very carefully. The same RULE: service dropping the root permissions after initial initialization, RULE: using various systemd isolation features and having a default active RULE: apparmor profile is much less concerning and can speed up acceptance. RULE: This helps Ubuntu, but you are encouraged to consider working with RULE: Debian and upstream to get those security features used at wide scale. RULE: - It might be impossible for the submitting team to check this perfectly RULE: (the security team will), but you should be aware that deprecated RULE: security algorithms like 3DES or TLS/SSL 1.1 are not acceptable. RULE: If you think a package might do that it would be great to provide a RULE: hint for the security team like "Package may use deprecated crypto" RULE: and provide the details you have about that. no `suid` or `sgid` binaries no executables in `/sbin` and `/usr/sbin` Package does not install services, timers or recurring jobs TODO: - Security has been kept in mind and common isolation/risk-mitigation TODO: patterns are in place utilizing the following features: TODO: TBD (add details and links/examples about things like dropping TODO: permissions, using temporary environments, restricted users/groups, TODO: seccomp, systemd isolation features, apparmor, ...) I believe it would be the applications using these media elements to ensure appropriate isolation/risk-mitigation measures are in place. Package does not open privileged ports (ports < 1024). Package does not expose any external endpoints Package does not contain extensions to security-sensitive software (filters, scanners, plugins, UI skins, ...) RULE: The package should not use deprecated security algorithms like 3DES or RULE: TLS/SSL 1.1. The security team is the one responsible to check this, RULE: but if you happen to spot something it helps to provide a hint. RULE: Provide whatever made you suspicious as details along that statement. RULE: Or remove the following lines entirely if you did not spot anything. [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. The package works well right after install [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. 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/gst-plugins-bad1.0/+bug - - Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=gst-plugins-bad1.0 - - Upstream's bug tracker - https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/ + - Ubuntu https://bugs.launchpad.net/ubuntu/+source/gst-plugins-bad1.0/+bug + - Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=gst-plugins-bad1.0 + - Upstream's bug tracker + https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/ Due to the ubiquitous nature of GStreamer within the FOSS stack, there are many reported and open bugs. However, there's also an active maintainer-ship, and critical bugs are addressed quickly. The package does not deal with exotic hardware we cannot support RULE: This is about confidence to be able to maintain the package, therefore RULE: any option (the examples or anything else you add) is "valid", but it RULE: depends on the case if that is then considered sufficient. RULE: The following examples are in descending order in regard to how "ok" they RULE: likely will be. [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 The package runs a test suite on build time, if it fails it makes the build fail, link to build log https://launchpadlibrarian.net/808473923/buildlog_ubuntu-questing-amd64.gst-plugins-bad1.0_1.26.4-1ubuntu1_BUILDING.txt.gz RULE: - The package should, but is not required to, also contain RULE: non-trivial autopkgtest(s). The package does not run an autopkgtest because no one has had time to do so. There's also a large bug surface specific to physical hardware, which would make tests running on virtualized platforms less useful. RULE: - existing but failing tests that shall be handled as "ok to fail" RULE: need to be explained along the test logs below The package does have not failing autopkgtests right now RULE: - If no build tests nor autopkgtests are included, and/or if the package RULE: requires specific hardware to perform testing, the subscribed team RULE: must provide a written test plan in a comment to the MIR bug, and RULE: commit to running that test either at each upload of the package or RULE: at least once each release cycle. In the comment to the MIR bug, RULE: please link to the codebase of these tests (scripts or doc of manual RULE: steps) and attach a full log of these test runs. This is meant to RULE: assess their validity (e.g. not just superficial). RULE: If possible such things should stay in universe. Sometimes that is RULE: impossible due to the way how features/plugins/dependencies work RULE: but if you are going to ask for promotion of something untestable RULE: please outline why it couldn't provide its value (e.g. by splitting RULE: binaries) to users from universe. RULE: This is a balance that is hard to strike well, the request is that all RULE: options have been exploited before giving up. Look for more details RULE: and backgrounds https://github.com/canonical/ubuntu-mir/issues/30 RULE: Just like in the SRU process it is worth to understand what the RULE: consequences a regression (due to a test miss) would be. Therefore RULE: if being untestable we ask to outline what consequences this would RULE: have for the given package. And let us be honest, even if you can RULE: test you are never sure you will be able to catch all potential RULE: regressions. So this is mostly to force self-awareness of the owning RULE: team than to make a decision on. - TODO: - The package can not be well tested at build or autopkgtest time - TODO: because TBD. To make up for that: - TODO-A: - We have access to such hardware in the team - TODO-B: - We have allocated budget to get this hardware, but it is not here - TODO-B: yet - TODO-C: - We have checked with solutions-qa and will use their hardware - TODO-C: through testflinger - TODO-D: - We have checked with other team TBD and will use their hardware - TODO-D: through TBD (eg. MAAS) - TODO-E: - We have checked and found a simulator which covers this case - TODO-E: sufficiently for testing, our plan to use it is TBD - TODO-F: - We have engaged with the upstream community and due to that - TODO-F: can tests new package builds via TBD - TODO-G: - We have engaged with our user community and due to that - TODO-G: can tests new package builds via TBD - TODO-H: - We have engaged with the hardware manufacturer and made an - TODO-H: agreement to test new builds via TBD - TODO-A-H: - Based on that access outlined above, here are the details of the - TODO-A-H: test plan/automation TBD (e.g. script or repo) and (if already - TODO-A-H: possible) example output of a test run: TBD (logs). - TODO-A-H: We will execute that test plan - TODO-A-H1: on-uploads - TODO-A-H2: regularly (TBD details like frequency: monthly, infra: jira-url) - TODO-X: - We have exhausted all options, there really is no feasible way - TODO-X: to test or recreate this. We are aware of the extra implications - TODO-X: and duties this has for our team (= help SEG and security on - TODO-X: servicing this package, but also more effort on any of your own - TODO-X: bug triage and fixes). - TODO-X: Due to TBD there also is no way to provide this to users from - TODO-X: universe. - TODO-X: Due to the nature, integration and use cases of the package the - TODO-X: consequences of a regression that might slip through most likely - TODO-X: would include - TODO-X: - TBD - TODO-X: - TBD - TODO-X: - TBD + + The package can not be well tested at build or autopkgtest time + because CI environments are not well suited to testing GStreamer beyond what is tested already at build time and by the upstream. Hardware configurations are particularly of relevance for the regressions likely to crop up in GStreamer. + + To make up for that, a test plan has been drafted as is available for + review in https://wiki.ubuntu.com/DesktopTeam/TestPlans/GStreamer - the + desktop team have committed to execute this on new package uploads and + releases. 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. This doesn't apply here. [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. debian/watch is present and works 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) 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 - This package does not yield massive lintian Warnings, Errors + This package does not yield massive lintian Warnings or Errors Find results of `lintian --pedantic` attached to this bug. Lintian overrides are not present 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. This package does not rely on obsolete or about to be demoted packages. This package has no python2 or GTK2 dependencies RULE: - Debconf questions should not bother the default user too much The package will be installed by default, but does not ask debconf questions higher than medium RULE: - The source packaging (in debian/) should be reasonably easy to RULE: understand and maintain. Packaging is complex, but that is ok because there's no alternative. GStreamer is a complex project. [UI standards] Application is end-user facing, Translation is present, via standard intltool/gettext [Dependencies] RULE: - In case of alternatives, the first alternative must be in main. RULE: Depends: concrete-package-in-main | metapackage 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) The dependencies for gst-plugins-extra1.0 are, libc6 (>= 2.14) libdrm2 (>= 2.4.98) libglib2.0-0t64 (>= 2.81.1) libgstreamer-plugins-base1.0-0 (>= 1.26.0) libgstreamer-plugins-extra1.0-0 (>= 1.26.4) libgstreamer1.0-0 (>= 1.26.0) libva-drm2 (>= 1.8) libva2 (>= 2.21.0) Which are all in main. check-mir doesn't work for proposed packages. [Standards compliance] RULE: - Major violations should be documented and justified. RULE: - FHS: https://refspecs.linuxfoundation.org/fhs.shtml RULE: - Debian Policy: https://www.debian.org/doc/debian-policy/ This package correctly follows FHS and Debian Policy [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. Only a selected set of Launchpad teams can own a package RULE: in main, you can find this list here: RULE: https://git.launchpad.net/ubuntu-archive-tools/tree/lputils.py#n46 RULE: This requirement of an owning-team comes in two aspects: RULE: - A case needs to have a team essentially saying "yes we will own that" RULE: to enter the MIR process. Usually that is implied by team members RULE: filing MIR requests having the backup by their management for the RULE: long term commitment this implies. RULE: - A community driven MIR request might be filed to show the use case, RULE: but then, as a first step, needs to get a team agreeing to own RULE: it before the case can be processed further. RULE: If unsure which teams to consider have a look at the current mapping RULE: http://reqorts.qa.ubuntu.com/reports/m-r-package-team-mapping.html RULE: In that case (you are not a representative of the team who will RULE: gain the long term committment to this) please ask a representative RULE: of that team to comment on the bug acknowledging that they are ok to RULE: own it. RULE: - The package needs a bug subscriber before it can be promoted to main. RULE: Strictly speaking that subscription can therefore wait until the RULE: moment of the actual promotion by an archive admin. But it is RULE: strongly recommended to subscribe early, as the owning team will get RULE a preview of the to-be-expected incoming bugs later on. RULE: - Simple packages (e.g. language bindings, simple Perl modules, small RULE: command-line programs, etc.) might not need very much maintenance RULE: effort, and if they are maintained well in Debian we can just keep them RULE: synced. They still need a subscribing team to handle bugs, FTBFS and RULE: tests RULE: - More complex packages will usually need a developer or team of RULE: developers paying attention to their bugs, whether that be in Ubuntu RULE: or elsewhere (often Debian). Packages that deliver major new headline RULE: features in Ubuntu need to have commitment from Ubuntu developers RULE: willing to spend substantial time on them. The owning team will be desktop-packages and I have their acknowledgment for that commitment The future owning team is already subscribed to the package (the source package, yes, the binary package is yet to be created) 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 RULE: - All vendored dependencies (no matter what language) shall have a RULE: way to be refreshed This does not use static builds This does not use vendored code This package is not rust based 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. The package has been built within the last 3 months in the archive 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 Build link on launchpad: https://launchpad.net/ubuntu/+source/gst- plugins-bad1.0/1.26.4-1ubuntu1 [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. The Package description explains the package well Upstream Name is GStreamer Link to upstream project: https://gstreamer.freedesktop.org/ I have uploaded a PPA for the new -bad package here: https://launchpad.net/~charles05/+archive/ubuntu/ppa/+sourcepub/17509973/+listing- archive-extra The corresponding -good package (which drops the manually vendoring now proposed for -extra): https://launchpad.net/~charles05/+archive/ubuntu/ppa/+sourcepub/17509971/+listing- archive-extra
** Attachment added: "Output of lintian -i --pedantic" https://bugs.launchpad.net/ubuntu/+source/gst-plugins-bad1.0/+bug/2121050/+attachment/5904330/+files/lintian_gst_bad.txt -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gst-plugins-bad1.0 in Ubuntu. https://bugs.launchpad.net/bugs/2121050 Title: [MIR] gstreamer-plugins-extra1.0 Status in gst-plugins-bad1.0 package in Ubuntu: In Progress Bug description: [Introduction] The current structure of gst-plugins-bad1.0 presents several challenges for its wholesale inclusion in main, particularly concerning its dependencies and the ongoing difficulties upstream in categorising GStreamer elements. This proposal seeks to address these issues by creating a new binary package, gstreamer1.0-plugins-extra, to house a targeted subset of components currently residing in the gst-plugins-bad1.0 source package. Upstream GStreamer development has consistently struggled with the classification and reorganisation of its elements. Attempts to split elements, such as those detailed in [1], or reorganise release tarballs [2], have frequently stalled. Similarly, proposals to move smaller, stable components from -bad to -good, even when championed by experienced upstream maintainers, have met with similar delays [3, 4]. While upstream wants to promote plugins from -bad to -good, it is not a high priority for them, and promises to do so have frequently slipped from release to release. Despite these upstream challenges, a significant driver for this proposal is the presence of hard dependencies on gst-plugins-bad1.0 components from existing main packages. To date, workarounds for these dependencies have involved unsustainable practices, including: - Vendoring an obsolete playback library within GTK4. - Patching gstreamer1.0-plugins-good (a main package) with elements that originate from gstreamer1.0-plugins-bad (a universe package). These workarounds not only bypass essential security reviews but also introduce a considerable maintenance burden due to the need to perpetually update these patches. This often results in users unknowingly relying on outdated and potentially vulnerable versions of these patched components. Further details and discussion regarding this proposed split can be found in the Launchpad bug report [5]. Therefore, to resolve these issues and establish a more future-proof solution, this MIR proposes creating a new binary package, gstreamer1.0-plugins-extra, from the existing gst-plugins-bad1.0 source package. This naming convention aligns with prior upstream discussions and agreements regarding element nomenclature [2]. This split will allow essential GNOME-related dependencies to reside in a main eligible package, facilitating proper security review and reducing the maintenance overhead currently imposed by the workarounds. [1] https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6130 [2] https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3320 [3] https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1758 [4] https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2386 [5] https://bugs.launchpad.net/ubuntu/+source/gst-plugins-bad1.0/+bug/2027594 [Availability] The package gst-plugins-bad1.0 is already in Ubuntu universe. The package gst-plugins-bad1.0 build for the architectures it is designed to work on. It currently builds and works for architectures: amd64, arm64, armhf, i386, riscv64 s390x Link to package https://launchpad.net/ubuntu/+source/gst-plugins-bad1.0 [Rationale] RULE: There must be a certain level of demand for the package A subset of the package gst-plugins-bad1.0 is required in Ubuntu main for the reasons outlined in the introduction. The subset of gst-plugins-bad1.0 will generally be useful for a large part of our user base. RULE: Sometimes there are other/better ways, often are achieved by using a RULE: library with similar functionality that is more commonly used and RULE: thereby already in main or a better candidate to promote. RULE: Reducing the set of supported software in Ubuntu helps to focus on the RULE: right things, otherwise Ubuntu developers will be consumed by updating RULE: many variations of the same - wasting valuable time that could be better RULE: spent elsewhere. RULE: If there are other packages in the archive that are close, but unable to RULE: address the problem you might spend some time explaining what exists and RULE: why it isn't a sufficient alternative. There is no other/better way to solve this that is already in main or should go universe->main instead of this if we wish to be in line with GNOME. RULE: If the package previously was in main (use rmadison to check), RULE: and the previous MIR content is still applicable and not ancient, RULE: just add a new release-task instead of creating a new MIR. RULE: Otherwise, continue with this MIR and link to the previous MIR. This is the first time package will be in main RULE: You truly need to understand the difference between main and universe RULE: in general and in the context of changed rules (build-depends) and RULE: constraints (Ubuntu Pro made it less of a difference in many cases). RULE: We have seen requests that were mostly based on old "I said supported (a RULE: weakly defined term to begin with) in a contract, so it has to be in main" RULE: feelings, but with sometimes no true reason - neither technically nor RULE: helping the user base of Ubuntu. Hence we need to ask for that clearly. The binary package gst-plugins-extra1.0 needs to be in main to achieve basic media functionality in the existing desktop package set. All other binary packages built by gst-plugins-bad1.0 should remain in universe. 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 prioritization 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 The package gst-plugins-extra1.0 is required in Ubuntu main no later than 26.04 due to the desktop moving from Totem to Showtime, and to ensure the other dependents of gst-plugins-extra1.0 can stop vendoring / patching. [Security] In terms of new code to review, the shared objects proposed for inclusion are, gstreamer1.0-plugins-extra_1.26.4-1ubuntu2_amd64.deb -rw-r--r-- root/root 92888 2025-08-04 11:44 ./usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstcamerabin.so -rw-r--r-- root/root 576024 2025-08-04 11:44 ./usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstva.so libgstreamer-plugins-extra1.0-0_1.26.5-1ubuntu2_amd64.deb -rw-r--r-- root/root 31048 2025-08-18 15:54 ./usr/lib/x86_64-linux-gnu/libgstbasecamerabinsrc-1.0.so.0.2605.0 -rw-r--r-- root/root 859520 2025-08-18 15:54 ./usr/lib/x86_64-linux-gnu/libgstcodecparsers-1.0.so.0.2605.0 -rw-r--r-- root/root 231752 2025-08-18 15:54 ./usr/lib/x86_64-linux-gnu/libgstcodecs-1.0.so.0.2605.0 -rw-r--r-- root/root 39080 2025-08-18 15:54 ./usr/lib/x86_64-linux-gnu/libgstphotography-1.0.so.0.2605.0 -rw-r--r-- root/root 145736 2025-08-18 15:54 ./usr/lib/x86_64-linux-gnu/libgstplay-1.0.so.0.2605.0 -rw-r--r-- root/root 90064 2025-08-18 15:54 ./usr/lib/x86_64-linux-gnu/libgstva-1.0.so.0.2605.0 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: https://cve.mitre.org/cve/search_cve_list.html I did not see any CVEs for the plugins / libraries we're proposing to be moved over. RULE: - check OSS security mailing list (feed into search engine RULE: 'site:www.openwall.com/lists/oss-security <pkgname>') Nothing found here either. RULE: - Ubuntu CVE Tracker RULE: https://ubuntu.com/security/cve?package=<source-package-name> - "The security API is down. An error occurred while fetching security data" RULE: - Debian Security Tracker RULE: https://security-tracker.debian.org/tracker/source-package/<source-package-name> Had 8 security issues in the past. All were in the codecparsing component. - https://security-tracker.debian.org/tracker/TEMP-0000000-C6AAE1 - https://security-tracker.debian.org/tracker/CVE-2025-6663 - https://security-tracker.debian.org/tracker/CVE-2025-3887 - https://security-tracker.debian.org/tracker/CVE-2023-50186 - https://security-tracker.debian.org/tracker/CVE-2023-44429 - https://security-tracker.debian.org/tracker/CVE-2023-40475 - https://security-tracker.debian.org/tracker/CVE-2021-3185 - https://security-tracker.debian.org/tracker/CVE-2016-9809 (since refactored into codecparsers) All were handled properly, but this is a significant risk. Codec parsing is notorious for security issues across platforms, and applications using this component absolutely should be sandboxed. RULE: - Check for security relevant binaries, services and behavior. RULE: If any are present, this requires a more in-depth security review. RULE: Demonstrating that common isolation/risk-mitigation patterns are used RULE: will help to raise confidence. For example a service running as root RULE: open to the network will need to be considered very carefully. The same RULE: service dropping the root permissions after initial initialization, RULE: using various systemd isolation features and having a default active RULE: apparmor profile is much less concerning and can speed up acceptance. RULE: This helps Ubuntu, but you are encouraged to consider working with RULE: Debian and upstream to get those security features used at wide scale. RULE: - It might be impossible for the submitting team to check this perfectly RULE: (the security team will), but you should be aware that deprecated RULE: security algorithms like 3DES or TLS/SSL 1.1 are not acceptable. RULE: If you think a package might do that it would be great to provide a RULE: hint for the security team like "Package may use deprecated crypto" RULE: and provide the details you have about that. no `suid` or `sgid` binaries no executables in `/sbin` and `/usr/sbin` Package does not install services, timers or recurring jobs TODO: - Security has been kept in mind and common isolation/risk-mitigation TODO: patterns are in place utilizing the following features: TODO: TBD (add details and links/examples about things like dropping TODO: permissions, using temporary environments, restricted users/groups, TODO: seccomp, systemd isolation features, apparmor, ...) I believe it would be the applications using these media elements to ensure appropriate isolation/risk-mitigation measures are in place. Package does not open privileged ports (ports < 1024). Package does not expose any external endpoints Package does not contain extensions to security-sensitive software (filters, scanners, plugins, UI skins, ...) RULE: The package should not use deprecated security algorithms like 3DES or RULE: TLS/SSL 1.1. The security team is the one responsible to check this, RULE: but if you happen to spot something it helps to provide a hint. RULE: Provide whatever made you suspicious as details along that statement. RULE: Or remove the following lines entirely if you did not spot anything. [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. The package works well right after install [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. 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/gst-plugins-bad1.0/+bug - Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=gst-plugins-bad1.0 - Upstream's bug tracker https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/ Due to the ubiquitous nature of GStreamer within the FOSS stack, there are many reported and open bugs. However, there's also an active maintainer-ship, and critical bugs are addressed quickly. The package does not deal with exotic hardware we cannot support RULE: This is about confidence to be able to maintain the package, therefore RULE: any option (the examples or anything else you add) is "valid", but it RULE: depends on the case if that is then considered sufficient. RULE: The following examples are in descending order in regard to how "ok" they RULE: likely will be. [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 The package runs a test suite on build time, if it fails it makes the build fail, link to build log https://launchpadlibrarian.net/808473923/buildlog_ubuntu-questing-amd64.gst-plugins-bad1.0_1.26.4-1ubuntu1_BUILDING.txt.gz RULE: - The package should, but is not required to, also contain RULE: non-trivial autopkgtest(s). The package does not run an autopkgtest because no one has had time to do so. There's also a large bug surface specific to physical hardware, which would make tests running on virtualized platforms less useful. RULE: - existing but failing tests that shall be handled as "ok to fail" RULE: need to be explained along the test logs below The package does have not failing autopkgtests right now 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. The package can not be well tested at build or autopkgtest time because CI environments are not well suited to testing GStreamer beyond what is tested already at build time and by the upstream. Hardware configurations are particularly of relevance for the regressions likely to crop up in GStreamer. To make up for that, a test plan has been drafted as is available for review in https://wiki.ubuntu.com/DesktopTeam/TestPlans/GStreamer - the desktop team have committed to execute this on new package uploads and releases. 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. This doesn't apply here. [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. debian/watch is present and works 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) 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 This package does not yield massive lintian Warnings or Errors Find results of `lintian --pedantic` attached to this bug. Lintian overrides are not present 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. This package does not rely on obsolete or about to be demoted packages. This package has no python2 or GTK2 dependencies RULE: - Debconf questions should not bother the default user too much The package will be installed by default, but does not ask debconf questions higher than medium RULE: - The source packaging (in debian/) should be reasonably easy to RULE: understand and maintain. Packaging is complex, but that is ok because there's no alternative. GStreamer is a complex project. [UI standards] Application is end-user facing, Translation is present, via standard intltool/gettext [Dependencies] RULE: - In case of alternatives, the first alternative must be in main. RULE: Depends: concrete-package-in-main | metapackage 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) The dependencies for gst-plugins-extra1.0 are, libc6 (>= 2.14) libdrm2 (>= 2.4.98) libglib2.0-0t64 (>= 2.81.1) libgstreamer-plugins-base1.0-0 (>= 1.26.0) libgstreamer-plugins-extra1.0-0 (>= 1.26.4) libgstreamer1.0-0 (>= 1.26.0) libva-drm2 (>= 1.8) libva2 (>= 2.21.0) Which are all in main. check-mir doesn't work for proposed packages. [Standards compliance] RULE: - Major violations should be documented and justified. RULE: - FHS: https://refspecs.linuxfoundation.org/fhs.shtml RULE: - Debian Policy: https://www.debian.org/doc/debian-policy/ This package correctly follows FHS and Debian Policy [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. Only a selected set of Launchpad teams can own a package RULE: in main, you can find this list here: RULE: https://git.launchpad.net/ubuntu-archive-tools/tree/lputils.py#n46 RULE: This requirement of an owning-team comes in two aspects: RULE: - A case needs to have a team essentially saying "yes we will own that" RULE: to enter the MIR process. Usually that is implied by team members RULE: filing MIR requests having the backup by their management for the RULE: long term commitment this implies. RULE: - A community driven MIR request might be filed to show the use case, RULE: but then, as a first step, needs to get a team agreeing to own RULE: it before the case can be processed further. RULE: If unsure which teams to consider have a look at the current mapping RULE: http://reqorts.qa.ubuntu.com/reports/m-r-package-team-mapping.html RULE: In that case (you are not a representative of the team who will RULE: gain the long term committment to this) please ask a representative RULE: of that team to comment on the bug acknowledging that they are ok to RULE: own it. RULE: - The package needs a bug subscriber before it can be promoted to main. RULE: Strictly speaking that subscription can therefore wait until the RULE: moment of the actual promotion by an archive admin. But it is RULE: strongly recommended to subscribe early, as the owning team will get RULE a preview of the to-be-expected incoming bugs later on. RULE: - Simple packages (e.g. language bindings, simple Perl modules, small RULE: command-line programs, etc.) might not need very much maintenance RULE: effort, and if they are maintained well in Debian we can just keep them RULE: synced. They still need a subscribing team to handle bugs, FTBFS and RULE: tests RULE: - More complex packages will usually need a developer or team of RULE: developers paying attention to their bugs, whether that be in Ubuntu RULE: or elsewhere (often Debian). Packages that deliver major new headline RULE: features in Ubuntu need to have commitment from Ubuntu developers RULE: willing to spend substantial time on them. The owning team will be desktop-packages and I have their acknowledgment for that commitment The future owning team is already subscribed to the package (the source package, yes, the binary package is yet to be created) 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 RULE: - All vendored dependencies (no matter what language) shall have a RULE: way to be refreshed This does not use static builds This does not use vendored code This package is not rust based 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. The package has been built within the last 3 months in the archive 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 Build link on launchpad: https://launchpad.net/ubuntu/+source/gst- plugins-bad1.0/1.26.4-1ubuntu1 [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. The Package description explains the package well Upstream Name is GStreamer Link to upstream project: https://gstreamer.freedesktop.org/ I have uploaded a PPA for the new -bad package here: https://launchpad.net/~charles05/+archive/ubuntu/ppa/+sourcepub/17509973/+listing- archive-extra The corresponding -good package (which drops the manually vendoring now proposed for -extra): https://launchpad.net/~charles05/+archive/ubuntu/ppa/+sourcepub/17509971/+listing- archive-extra To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gst-plugins-bad1.0/+bug/2121050/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
