RPMFusion update conflicts on Silverblue

rpm-ostree update has been failing for the past few days with:

error: Could not depsolve transaction; 2 problems detected:
 Problem 1: package libavdevice-free-6.1.1-12.fc40.x86_64 from @System requires libavcodec-free(x86-64) = 6.1.1-12.fc40, but none of the providers can be installed
  - conflicting requests
 Problem 2: package ffmpeg-free-6.1.1-12.fc40.x86_64 from @System requires libavfilter-free(x86-64) = 6.1.1-12.fc40, but none of the providers can be installed
  - conflicting requests

These packages from RPMFusion keep causing these conflicts and blocking upgrades for weeks. Any workaround, or other repo I can use instead of relying on RPMFusion?

This will likely be resolved in a few days or so, looks like a sync issue

Added ffmpeg

We would need the output of rpm-ostree status to be able to help. There are also a lot of thread around here about how to remove/replace the right amount of packages for codec support.

1 Like

You should be blaming the way silverblue does it’s updates, this issue doesn’t occur if your using non-silverblue.

The list of errors has grew:

error: Could not depsolve transaction; 3 problems detected:
 Problem 1: package libavdevice-free-6.1.1-12.fc40.x86_64 from @System requires libavcodec-free(x86-64) = 6.1.1-12.fc40, but none of the providers can be installed
  - conflicting requests
 Problem 2: package ffmpeg-free-6.1.1-12.fc40.x86_64 from @System requires libavfilter-free(x86-64) = 6.1.1-12.fc40, but none of the providers can be installed
  - conflicting requests
 Problem 3: package mesa-va-drivers-freeworld-24.0.5-1.fc40.i686 from rpmfusion-free requires mesa-filesystem(x86-32) = 24.0.5, but none of the providers can be installed
  - conflicting requests
  - mesa-filesystem-24.0.5-1.fc40.i686 from fedora  does not belong to a distupgrade repository
  - package mesa-va-drivers-freeworld-24.0.5-1.fc40.x86_64 from rpmfusion-free requires mesa-filesystem(x86-64) = 24.0.5, but none of the providers can be installed
  - package mesa-va-drivers-freeworld-24.0.7-1.fc40.x86_64 from rpmfusion-free-updates requires mesa-filesystem(x86-64) = 24.0.7, but none of the providers can be installed
  - cannot install both mesa-filesystem-24.0.5-1.fc40.x86_64 from fedora and mesa-filesystem-24.0.8-1.fc40.x86_64 from @System
  - cannot install both mesa-filesystem-24.0.7-1.fc40.x86_64 from updates-archive and mesa-filesystem-24.0.8-1.fc40.x86_64 from @System
  - cannot install both mesa-filesystem-24.0.7-3.fc40.x86_64 from updates-archive and mesa-filesystem-24.0.8-1.fc40.x86_64 from @System
  - nothing provides mesa-filesystem(x86-32) = 24.0.7 needed by mesa-va-drivers-freeworld-24.0.7-1.fc40.i686 from rpmfusion-free-updates

This is the status of the latest deployment:

â—Ź fedora:fedora/40/x86_64/silverblue (index: 0)
                  Version: 40.20240517.0 (2024-05-17T00:38:18Z)
               BaseCommit: 85e0f165c79529e57a753d59153f2ea221297e38fc8d4bfdf74547dd58481f9c
                           ├─ repo-0 (2024-04-14T18:51:11Z)
                           ├─ repo-1 (2024-05-17T00:16:22Z)
                           └─ repo-2 (2024-05-17T00:21:18Z)
                   Commit: f9b366b7ff4eccff70a9831ff94589c085a94e00f97d852cbdc72398dfc452b0
                           ├─ copr:copr.fedorainfracloud.org:solopasha:hyprland (2024-05-17T03:32:14Z)
                           ├─ fedora (2024-04-14T18:51:11Z)
                           ├─ fedora-cisco-openh264 (2023-12-11T14:43:50Z)
                           ├─ firefoxpwa (2024-05-01T16:09:43Z)
                           ├─ rpmfusion-free (2024-04-20T12:11:51Z)
                           ├─ rpmfusion-free-updates (2024-05-16T20:58:05Z)
                           ├─ rpmfusion-nonfree (2024-04-20T12:18:23Z)
                           ├─ rpmfusion-nonfree-updates (2024-05-16T21:18:42Z)
                           ├─ tailscale-stable (2024-05-16T21:03:35Z)
                           ├─ updates (2024-05-17T01:03:53Z)
                           └─ updates-archive (2024-05-17T01:23:05Z)
                   Staged: no
                StateRoot: fedora
             GPGSignature: 1 signature
                           Signature made Fri 17 May 2024 01:39:42 BST using RSA key ID 0727707EA15B79CC
                           Good signature from "Fedora <fedora-40-primary@fedoraproject.org>"
      RemovedBasePackages: libavfilter-free libavformat-free libpostproc-free libswresample-free libavutil-free libswscale-free libavcodec-free 6.1.1-12.fc40 mesa-va-drivers 24.0.7-3.fc40 nano-default-editor 7.2-7.fc40
          LayeredPackages: blueman ddccontrol distrobox docker docker-compose dunst ffmpeg firefoxpwa foot fuzzel hypridle hyprland hyprlock hyprnome hyprpicker hyprshot langpacks-en_GB libavcodec-freeworld libvirt
                           liquidctl mesa-va-drivers-freeworld network-manager-applet pavucontrol polkit-gnome printer-driver-brlaser python3-pyudev restic rofi-themes rofi-wayland rpmfusion-free-release
                           rpmfusion-nonfree-release steam-devices swaybg swaylock system-config-printer thunar thunar-archive-plugin vim-default-editor virt-manager waybar waypaper xwaylandvideobridge zsh

The mesa conflict is to be expected as the fedora mesa maintainers refuse to coordinate with rpmfusion.
It isn’t reasonable to expect rpmfusion to respond to such quick non-critical updates, 21 hours from submission to stable.

https://bodhi.fedoraproject.org/updates/FEDORA-2024-7f13e65730

It’s the only valid conflict currently

$ sudo repoclosure  --check rpmfusion-free --check rpmfusion-nonfree --check rpmfusion-free-updates --check rpmfusion-nonfree-updates
Last metadata expiration check: 0:00:14 ago on Fri 24 May 2024 09:56:27 BST.
package: mesa-va-drivers-freeworld-24.0.7-1.fc40.i686 from rpmfusion-free-updates
  unresolved deps (1):
    mesa-filesystem(x86-32) = 24.0.7
package: mesa-va-drivers-freeworld-24.0.7-1.fc40.x86_64 from rpmfusion-free-updates
  unresolved deps (1):
    mesa-filesystem(x86-64) = 24.0.7
package: mesa-vdpau-drivers-freeworld-24.0.7-1.fc40.i686 from rpmfusion-free-updates
  unresolved deps (1):
    mesa-filesystem(x86-32) = 24.0.7
package: mesa-vdpau-drivers-freeworld-24.0.7-1.fc40.x86_64 from rpmfusion-free-updates
  unresolved deps (1):
    mesa-filesystem(x86-64) = 24.0.7
Error: Repoclosure ended with unresolved dependencies (4) across 4 packages.

Well, I haven’t been able to update since May 17 because of this. Which is unfortunate because I need to update another package, and the only workaround is unlayer the entire rpmfusion package set, update and when this is fixed, add it back again.

Do we have a rough ETA of how long the rpmfusion stays out of sync? If it’s another week, I’ll go through with it.

The ffmpeg conflict issue should be reported against rpm-ostree, it’s a fedora problem.
I signed and pushed the rpmfusion update today, this is done about once a week.

Did you try this?

https://rpmfusion.org/Howto/OSTree?highlight=(\bCategoryHowto\b)#Software_codecs

Yes, that’s how I installed all the RPMFusion codecs in the first place.

Still unable to update. I reckon I should look into ublue as they deal with all this codec packaging nonsense… too bad they have redesigned their website and it’s impossible to find the URL to rebase to.

The Rpmfusion founders made some basic rules when they formed the repo.
The non package replacement policy is now dated since fedora started shipping it’s crippled versions.
Using package replacement would be much easier for users.

rpm-ostree override remove libavcodec-free libavfilter-free libavformat-free libavutil-free libpostproc-free libswresample-free libswscale-free libavdevice-free --install ffmpeg

Did you try with adding libavdevice-free?

@1player

I am having the same issue. This is probably more of an answer your looking for: [Silverblue] RPM Fusion codec instructions not working

I just migrated to vanilla Universal Blue that deals with this RPMFusion packaging nonsense itself.

As no one seems to take responsibility for this interaction (also opened an issue on the Silverblue repo, which was closed because rpmfusion ain’t their problem), any time there’s a ffmpeg update there’s gonna ostree update issues. Worth looking into ublue (which is pretty much just Silverblue with codecs and extra goodies included) if it happens again.

2 Likes

Was it difficult?

With vanilla uBlue, do you mean their " main " image, this one?

I noticed just rebasing didn’t work, some error messages, but the documentation of uBlue indicates you should start with a fresh Silverblue first then rebase, so I’ll do that just in case.
If you have any other related recommendations please share.