Comments

144 Comments

This should really have been taken to the public rpmfusion-devel mailing list, not just discussed behind closed doors with one person, who was clearly not aware of the implications on FFmpeg's consumers.

In addition, in order to support WebRTC with H.264, QtWebEngine (and Chromium too, I suppose) needs to link against OpenH264 at compile time. Dlopening it, as Firefox apparently does, is not supported. As I understand it, this is also not allowed in Fedora. qt5-qtwebengine-freeworld is linked against a bundled copy of OpenH264 which is ripped out of the tarball in the Fedora qt5-qtwebengine. Hence, qt5-qtwebengine-freeworld cannot go away even if we link it against system FFmpeg.

So the swappable FFmpeg just makes a mess for Chromium and QtWebEngine and does not help at all.

There is no way this can work properly for Chromium and QtWebEngine because Chromium hardcodes the list of supported codecs at compile time, based on whether the use_proprietary_codecs (where by "proprietary", they really mean patent-encumbered) flag is set at compile time or not. (And this is a boolean toggle between 2 hardcoded lists, there is no attempt at determining what codecs the linked FFmpeg actually supports, neither at compile time, nor at runtime.) So if you sneakily swap the FFmpeg used at build time for another one at runtime, you end up with websites getting told a wrong list of supported codecs, leading to broken websites.

So I see building both qt5-qtwebengine and qt5-qtwebengine-freeworld with bundled FFmpeg (whereas previously, -freeworld was built with system FFmpeg from RPM Fusion) as the only way forward. (It is currently the only thing that will build anyway, because FFmpeg 5 is not supported. But even if that is fixed, using swappable FFmpeg will break things.)

How is this going to work with both packages having the same RPM Name? RPM Fusion packages normally cannot have the same Name as Fedora packages, for good reasons.

karma

I am not convinced that this is a useful thing to ship in Fedora. It is only going to make the work for RPM Fusion more complicated and provides no real value. The F36 package also "upgrades" the RPM Fusion version (which is FFmpeg 4.4) to FFmpeg 5 (a source- and binary-incompatible version) with crippled codec support, breaking almost all packages in RPM Fusion.

RPM Fusion has FFmpeg 5 only in Rawhide so far, not F36 (and several things do not yet build against FFmpeg 5, so they are also working on a compatibility package). There was also no discussion whatsoever about moving the RPM Fusion package to ffmpeg-freeworld. I consider it entirely unacceptable to squat the name of probably the most high-profile third-party-repository package without even talking to that repository's mailing list about it first.

The one-week delay would have expired in 79 minutes anyway, but thanks for the karma. :-)

I am just going to send this forward to stable. For -freeworld users, the versioned dependencies will hold it back until RPM Fusion is ready (or until they install the -freeworld build manually as you did) anyway.

Hmmm… I would have loved to give RPM Fusion a chance to push the -freeworld build at least to testing before this goes out to stable in Fedora, and the F34 update is also still stuck with no karma. On the other hand, this fixes 64 security vulnerabilities, so I do not want to sit on it for too long.

Note that this was fixed in 20.04.2, but the kdepim stack was never upgraded from 19.12.2 (which is now almost 1 year old, it was released on 2020-02-04) in F32.

I am building kf5-messagelib-19.12.2-2.fc32 with a backported fix now and will edit it into this update.

Looks like we need this backported in the PIM Messagelib for KMail: https://invent.kde.org/pim/messagelib/-/commit/1f2548805df60707ffba2bba27d35d441232d140 I am going to look into this.

Indeed, F33 does not need an update. The F32 update only backports a fix from 5.15.1 to 5.14.2. F33 already has the fix because it is on 5.15.2. The upgrade path is not broken.

https://koji.rpmfusion.org/koji/buildinfo?buildID=17745

Looks like it is still stuck in the RPM Fusion queue.

I am now building qt5-qtwebengine-5.15.2-8.fc33 which adds a versioned Conflicts to the Fedora update to force -freeworld to be upgraded as well, and I will edit this update with that.

In addition, I have also set the "suggest logout" flag on the update.

Please: 1. Close all applications using QtWebEngine. If you are unsure, just restart your session (log out and back in) or reboot altogether. Rationale: QtWebEngine forks background processes from a "zygote" process. If the "zygote" process is old, it may still be built against the bundled ICU and look for the bundled data file, which is gone now that we switched back to the system ICU. 2. If you have qt5-qtwebengine-freeworld installed, upgrade it to qt5-qtwebengine-freeworld-5.15.2-2.fc33. Rationale: -2 is the corresponding version, built against the system ICU as well. -1 was built against the bundled ICU and wants the data file from the non-freeworld package.

Does that fix your issue?

This update has backported the incompatible %cmake_kf5 RPM macro changes to Fedora 32!

(Disregard the comment about F32, that one was intended to go onto the F32 update. This is the F31 update and hence breaks only F31.)

This update has backported the incompatible %cmake_kf5 RPM macro changes to Fedora 32!

This update has backported the incompatible %cmake_kf5 RPM macro changes to Fedora 31!

Several of the builds are missing the epel8-testing-candidate tag. They need to be tagged with that before the push can proceed.