Public bug reported: [Availability] The package showtime is already in Ubuntu universe. The package showtime build for the architectures it is designed to work on. It currently builds and works for architectures: all except i386 Link to package https://launchpad.net/ubuntu/+source/showtime
[Rationale] - The package showtime is required in Ubuntu main as a default video player for Ubuntu Desktop. - The package showtime will generally be useful for a large part of our user base - Package showtime covers the same use case as totem, but is better because it is more actively maintained and has improved UI/UX, thereby we want to replace it. GNOME Core officially switched from totem to showtime for GNOME 49 and we want to do that swap too. - 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 - The binary package showtime needs to be in main to achieve a better video player for Ubuntu Desktop. - All binary packages built by showtime need to be in main. (There is only one binary package.) - It would be great and useful to community/processes to have the package showtime in Ubuntu main, but there is no definitive deadline. Specifically, although Loupe and Ptyxis were mentioned in Ubuntu Desktop 25.10 plans, Showtime was not; therefore Showtime is a lower priority than those other apps. https://discourse.ubuntu.com/t/ubuntu-desktop-25-10-the-questing-quokka-roadmap/61159 [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). - 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 Debian/Ubuntu/Upstream and does not have too many, long-term & critical, open bugs - Ubuntu https://bugs.launchpad.net/ubuntu/+source/showtime - Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=showtime - Upstream https://gitlab.gnome.org/GNOME/showtime/-/issues - The package does not deal with exotic hardware we cannot support [Quality assurance - testing] The package runs a few trivial metadata validation tests on build time, if it fails it makes the build fail, link to build log https://launchpad.net/ubuntu/+source/showtime/49~alpha-2/+latestbuild/amd64 It does not run more extensive tests because build time tests wouldn't do a very good job of testing this app's specific functionality. The app is mostly a frontend to gstreamer which does have a stronger testing story. - The package does not run an autopkgtest because it is a GUI video player app and autopkgtest isn't a good fit for this kind of package 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-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 [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 - Please link to a recent build log of the package https://launchpad.net/ubuntu/+source/showtime/49~alpha-2/+latestbuild/amd64 - Please attach the full output you have got from `lintian --pedantic` as an extra post to this bug. - Lintian overrides are not present - This package does not rely on obsolete or about to be demoted packages. - This package has no python2 or GTK2 dependencies - The package will be installed by default, but does not ask debconf questions - Packaging and build is easy, link to debian/rules https://salsa.debian.org/gnome-team/showtime/-/blob/debian/latest/debian/rules [UI standards] - Application is end-user facing, Translation is present, via standard gettext - End-user applications that ships a standard conformant desktop file, see https://salsa.debian.org/gnome-team/showtime/-/blob/debian/latest/data/org.gnome.Showtime.desktop.in [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 debcrafters-packages and I have their acknowledgment 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 - This does not use vendored code - This package is not rust based - The package has been built within the last 3 months in the archive - Build link on launchpad: [Background information] - The Package description explains the package well - Upstream Name is showtime (user-visible name is Video Player) - Link to upstream project https://gitlab.gnome.org/GNOME/showtime GNOME does not currently have a video thumbnailer solution. Our current plan is to split totem's thumbnailer to a separate binary package. The totem, totem-plugins, gir1.2-totem-1.0 and libtotem-dev binary packages would be demoted to universe while libtotem0, totem-common, and the new thumbnailer binary packages would stay in main. We expect GNOME to recommend a thumbnailer solution, but we can't guarantee that it will be ready in time for Ubuntu 26.04 LTS. https://gitlab.gnome.org/Teams/Releng/AppOrganization/-/issues/35 ** Affects: showtime (Ubuntu) Importance: Undecided Status: Incomplete ** Changed in: showtime (Ubuntu) Status: New => Incomplete ** Description changed: [Availability] The package showtime is already in Ubuntu universe. The package showtime build for the architectures it is designed to work on. It currently builds and works for architectures: all except i386 Link to package https://launchpad.net/ubuntu/+source/showtime [Rationale] - The package showtime is required in Ubuntu main as a default video player for Ubuntu Desktop. - The package showtime will generally be useful for a large part of our user base - Package showtime covers the same use case as totem, but is better because it is more actively maintained and has improved UI/UX, thereby we want to replace it. GNOME Core officially switched from totem to showtime for GNOME 49 and we want to do that swap too. - 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 - The binary package showtime needs to be in main to achieve a better video player for Ubuntu Desktop. - All binary packages built by showtime need to be in main. (There is only one binary package.) - It would be great and useful to community/processes to have the package showtime in Ubuntu main, but there is no definitive deadline. Specifically, although Loupe and Ptyxis were mentioned in Ubuntu Desktop 25.10 plans, Showtime was not; therefore Showtime is a lower priority than those other apps. https://discourse.ubuntu.com/t/ubuntu-desktop-25-10-the-questing-quokka-roadmap/61159 [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). - 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 Debian/Ubuntu/Upstream and does not have too many, long-term & critical, open bugs - Ubuntu https://bugs.launchpad.net/ubuntu/+source/showtime - Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=showtime - Upstream https://gitlab.gnome.org/GNOME/showtime/-/issues - The package does not deal with exotic hardware we cannot support [Quality assurance - testing] The package runs a few trivial metadata validation tests on build time, if it fails it makes the build fail, link to build log https://launchpad.net/ubuntu/+source/showtime/49~alpha-2/+latestbuild/amd64 It does not run more extensive tests because build time tests wouldn't do a very good job of testing this app's specific functionality. The app is mostly a frontend to gstreamer which does have a stronger testing story. - The package does not run an autopkgtest because it is a GUI video player app and autopkgtest isn't a good fit for this kind of package 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-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 [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 - Please link to a recent build log of the package https://launchpad.net/ubuntu/+source/showtime/49~alpha-2/+latestbuild/amd64 - Please attach the full output you have got from `lintian --pedantic` as an extra post to this bug. - Lintian overrides are not present - This package does not rely on obsolete or about to be demoted packages. - This package has no python2 or GTK2 dependencies - The package will be installed by default, but does not ask debconf questions - Packaging and build is easy, link to debian/rules https://salsa.debian.org/gnome-team/showtime/-/blob/debian/latest/debian/rules [UI standards] - Application is end-user facing, Translation is present, via standard gettext - End-user applications that ships a standard conformant desktop file, see https://salsa.debian.org/gnome-team/showtime/-/blob/debian/latest/data/org.gnome.Showtime.desktop.in [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 debcrafters-packages and I have their acknowledgment 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 - This does not use vendored code - This package is not rust based - The package has been built within the last 3 months in the archive - Build link on launchpad: [Background information] - The Package description explains the package well - Upstream Name is showtime (user-visible name is Video Player) - - Link to upstream project TBD + - Link to upstream project https://gitlab.gnome.org/GNOME/showtime - Notably, GNOME does not currently have a video thumbnailer solution. Our - current plan is to split totem's thumbnailer to a separate binary - package. The totem, totem-plugins, gir1.2-totem-1.0 and libtotem-dev - binary packages would be demoted to universe while libtotem0, totem- - common, and the new thumbnailer binary packages would stay in main. + GNOME does not currently have a video thumbnailer solution. Our current + plan is to split totem's thumbnailer to a separate binary package. The + totem, totem-plugins, gir1.2-totem-1.0 and libtotem-dev binary packages + would be demoted to universe while libtotem0, totem-common, and the new + thumbnailer binary packages would stay in main. - We expect GNOME to recommend a thumbnailer solution, but we can't - guarantee that it will be ready in time for Ubuntu 26.04 LTS. + We expect GNOME to recommend a thumbnailer solution, but we can't guarantee that it will be ready in time for Ubuntu 26.04 LTS. https://gitlab.gnome.org/Teams/Releng/AppOrganization/-/issues/35 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2115912 Title: [MIR] showtime To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/showtime/+bug/2115912/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
