Recently, I made an ostree change to get live-streams working on Kinoite. I would’ve like to stay in my immutable bubble, but I don’t think there was any way around it if I wanted the right codec support.
Now, when I try to update System Software: Fedora Kinoite 39.20240120.0 normally through Discover, I’m met with this error code:
rpm-ostree transaction failed with:
error: Could not depsolve transaction; 1 problem detected:
Problem: package mesa-va-drivers-freeworld-23.2.1-2.fc39.i686 from rpmfusion-free requires mesa-filesystem(x86-32) = 23.2.1, but none of the providers can be installed
- conflicting requests
- mesa-filesystem-23.2.1-2.fc39.i686 from fedora does not belong to a distupgrade repository
- package mesa-va-drivers-freeworld-23.2.1-2.fc39.x86_64 from rpmfusion-free requires mesa-filesystem(x86-64) = 23.2.1, but none of the providers can be installed
- package mesa-va-drivers-freeworld-23.3.3-1.fc39.x86_64 from rpmfusion-free-updates requires mesa-filesystem(x86-64) = 23.3.3, but none of the providers can be installed
- cannot install both mesa-filesystem-23.2.1-2.fc39.x86_64 from fedora and mesa-filesystem-23.3.4-1.fc39.x86_64 from @System
- cannot install both mesa-filesystem-23.3.3-1.fc39.x86_64 from updates-archive and mesa-filesystem-23.3.4-1.fc39.x86_64 from @System
- nothing provides mesa-filesystem(x86-32) = 23.3.3 needed by mesa-va-drivers-freeworld-23.3.3-1.fc39.i686 from rpmfusion-free-updates
Is this something I’ll have to fix, or do you think I can just wait it out with an update? Everything else updates fine, just not the system software package.
Yes, if you have layered the mesa-freeworld packages, you’ll have this problem every time Fedora updates mesa.
I would strongly recommend not doing that on rpm-ostree systems. With a conventional installation, only mesa is held back; with rpm-ostree, you can’t update anything.
Do you also have the i686 version layered or is libdnf just getting creative? I’d even more strongly recommend not layering i686 packages.
I’ll be honest, I have no idea. I just followed guides on the internet to get livestreams working and hoped for the best, so I may have accidentally added i686 by mistake.
Do you know of any way I might fix this while still keeping the ability to watch streams on twitch or youtube?
One thought I have is to reset the ostree changes somehow and just use the Flathub version of Firefox instead of the default Kinoite-bundled Firefox, because I heard that one actually has H.264 codec support built-in.
Yes, using Flathub version should work. You may also want to flatpak install org.freedesktop.Platform.ffmpeg-full//23.08. Mozilla’s Firefox flatpak will use that, but it won’t install it by default for legal reasons. There’s a good chance it gets installed by another app, but it’s not guaranteed.
If you want to undo the changes to you system, please share rpm-ostree status
To remove the override, you can use rpm-ostree override reset mesa-va-drivers. You might need to add --uninstall mesa-va-drivers-freeworld to that; I’m not sure.
Alternatively, you can leave it alone, and you should be able to update within a day or two. This will probably happen again though.
And, no, there’s nothing identifying in there. It just describes the contents of /usr. It would look the same for any system with the same overrides and layered packages.
Thank you! My problem seems to be gone, so I’ll go ahead make your reply the solution.
The first line gave me an error, but adding the second line to it and trying again (as you mentioned may be required) did the trick.
After rebooting, I was able to update through Discover with no errors. Although I’m not exactly sure what changed because I’m still able to watch livestreams on default Firefox, and the rpm-ostree status report looks mostly the same as before…
Regardless, the Discover update issue is fixed, so I thank you! I’m not worried about it anymore, but if it does happen again I’ll just make a new post. Thank you!
That mesa-freeworld package adds hardware acceleration for patented codecs (for AMD only). For software decoding in non-flatpaks, you only need libavcodec-freeworld, which you have also layered.
Ohh ok. So hypothetically, if it were working, would it be better for me to have the mesa layer since I’m only using amd hardware? Or is there really not a difference between it and the software decoding option?