gstreamer-vaapi 1.20.1-1ubuntu1 can't be installed

Bug #1983042 reported by Gabriel de Perthuis
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
gstreamer-vaapi (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

The "Depends: libgstreamer-plugins-bad1.0-0 (>= 1.20.3)" kept when backporting gstreamer-vaapi 1.20.3 isn't matched by such a backported version of the libgstreamer-plugins-bad1.0-0 package.
See https://bugs.launchpad.net/ubuntu/+source/totem/+bug/1970013/comments/18

I'm not sure if the other package should be backported or if the dependency metadata change should be reverted.

Looking at the upstream bug, the fix does interact with the bad plugins by giving them higher priority. Not sure if either option has been sufficiently tested.

https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2459

Tags: jammy
affects: totem (Ubuntu) → gstreamer-vaapi (Ubuntu)
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gstreamer-vaapi (Ubuntu):
status: New → Confirmed
Revision history for this message
Robie Basak (racb) wrote :

libgstreamer-plugins-bad1.0-0 1.20.3-0ubuntu1 was released earlier (bug 1980239).

What's the user story that's broken here for which you're claiming a regression please? Is it just that the update you want wasn't available yet, or is there something that actually breaks for users due to the skew in release times between the two updates?

tags: added: jammy
Revision history for this message
Alexander Browne (elcste) wrote :

I'm not the bug creator, but I marked it as affecting me because when I update normally with `sudo apt update; sudo apt upgrade` I get the message

The following packages have been kept back:
  gstreamer1.0-vaapi

If I try to update it manually, it fails with the dependency problem:

$ sudo apt install gstreamer1.0-vaapi
[...]
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 gstreamer1.0-vaapi : Depends: libgstreamer-plugins-bad1.0-0 (>= 1.20.3) but 1.20.1-1ubuntu2 is to be installed
E: Unable to correct problems, you have held broken packages.

$ sudo apt install libgstreamer-plugins-bad1.0-0
[...]
libgstreamer-plugins-bad1.0-0 is already the newest version (1.20.1-1ubuntu2).

$ apt -a list libgstreamer-plugins-bad1.0-0
Listing... Done
libgstreamer-plugins-bad1.0-0/jammy-updates 1.20.3-0ubuntu1 amd64
libgstreamer-plugins-bad1.0-0/jammy,now 1.20.1-1ubuntu2 amd64 [installed]

I got it to work then with

$ sudo apt install libgstreamer-plugins-bad1.0-0=1.20.3-0ubuntu1
$ sudo apt upgrade

Is this a phased updates thing?

Revision history for this message
Gabriel de Perthuis (g2p) wrote :

The issue was that Apt complained about uninstallable updates, packages weren't being released at the same time or in the right order, but it was in fact temporary and is already fixed for me.

> libgstreamer-plugins-bad1.0-0 1.20.3-0ubuntu1 was released earlier (bug 1980239).

> What's the user story that's broken here for which you're claiming a regression please? Is it just that the update you want wasn't available yet, or is there something that actually breaks for users due to the skew in release times between the two updates?

Changed in gstreamer-vaapi (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
Robie Basak (racb) wrote :

Thanks for the update!

> The issue was that Apt complained about uninstallable updates, packages weren't being released at the same time or in the right order, but it was in fact temporary and is already fixed for me.

I think this is expected, normal behaviour. We don't have much of anything to ensure that we release SRUs in a particular order. We rely on apt to understand the dependencies and not break users' systems. It sounds like it did the right thing in this case.

With apt phasing, I believe we rely on this even if we were to have released the SRU in the "correct" order.

If I'm wrong and there really was a problem, then I'd appreciate someone providing the detail of how users were broken, because we need to address it in our SRU release process.

Otherwise, since this wasn't a bug, I'll remove the regression-updates tag since it's not a historical regression. Technically the bug status should be Invalid then, but I'll leave that as it might help with future searches.

tags: removed: regression-update
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.