Comments
kkofler
For Blogilo, another build attempt is now running in Rawhide, also depending on ktextaddons-1.1.1-2.
This is now built in Rawhide as blogilo-17.08.3-26.fc39, but we need an fc38 build included here, too.
To fix the accessibility regression, first ktextaddons-1.1.1-2 and then kf5-kpimtextedit-23.04.0-2 (which depends on the former) need to be built in a side tag and included here.
For Blogilo, another build attempt is now running in Rawhide, also depending on ktextaddons-1.1.1-2.
Actually, it looks like ktextaddons was recently imported (without the kf5- prefix, which is why I have not found it at first – this is going to be a problem when there will be a separate kf6 version), but it is not built with text to speech support:
-- The following OPTIONAL packages have not been found: * Qt5TextToSpeech, Add support for text to speech
So you need to build ktextaddons with Qt5TextToSpeech and then kpimtextedit with ktextaddons to fix the accessibility regression.
kf5-kpimtextedit is missing text-to-speech support, which is a regression in this update.
Previously, this functionality was shipped with KPimTextEdit. But as of:
https://invent.kde.org/pim/kpimtextedit/-/commit/d1208e340a7328147037b1c23639c0a176319af5
it has been moved to a separate ktextaddons package which is not packaged in Fedora yet. As a result, the functionality is missing:
-- Could NOT find KF5TextEditTextToSpeech (missing: KF5TextEditTextToSpeech_DIR)
Unfortunately, Blogilo requires this support to build:
https://kojipkgs.fedoraproject.org//work/tasks/8694/100858694/build.log
/builddir/build/BUILD/blogilo-17.08.3/composereditorwebengine/src/composerwebengine.cpp:24:10: fatal error: kpimtextedit/texttospeech.h: No such file or directory
24 | #include "kpimtextedit/texttospeech.h"
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
I would patch it to use ktextaddons instead (it seems to be basically the same API, just in a different namespace), but I cannot because it is not packaged in Fedora.
But even if you do not care about Blogilo, this accessibility regression must be fixed before the kdepim update can be pushed to a stable Fedora release.
Still breaks Blogilo.
I am trying right now to get it to build in Rawhide, then in F38.
The way kdepim has broken backwards compatibility is really a PITA. Especially in the KF5 branch that should really be in maintenance mode. They should have left the breaking changes for the Qt6/KF6 port!
The changes are not only incompatible, but also include some fun screwups:
- They have installed backwards compatibility CMake modules for libkdepim and kpimtextedit, but NOT kwebengineviewer.
- For kpimtextedit, if you do the exact replacements the deprecation message tells you to do, it does NOT work, because it was actually renamed to KPim5TextEdit and NOT KPim5PimTextEdit as the deprecation message claims.
See also https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#philosophy : "ABI changes in general are very strongly discouraged".
I shall also note that this ABI break was not even announced for Rawhide as far as I can tell. The first time I heard about it for Rawhide was from those FTI bugs, and the first time I hear this is being backported to F38 is from the comments on this update.
The incompatible changes in KDE PIM libraries (already mentioned in a comment) are also going to break Blogilo and Trojitá: * https://bugzilla.redhat.com/show_bug.cgi?id=2182704 * https://bugzilla.redhat.com/show_bug.cgi?id=2182714
The packages also do not rebuild as is, see: * https://bugzilla.redhat.com/show_bug.cgi?id=2182704#c3 * https://bugzilla.redhat.com/show_bug.cgi?id=2171741#c1
The file conflicts you are seeing are https://bugzilla.rpmfusion.org/show_bug.cgi?id=6612
As a quick hack to work around the bad header, try:
#define throw(...) /**/
#include <OpenEXR/ImathVec.h>
#undef throw
Well, then I guess we should try rebuilding the old kio-extras against the current Qt5 from RHEL8 and the current KF5 from this build. Because a rebuild seems clearly needed.
(By the way, for a long time, there used to be a glitch in Bodhi where it would have been possible to first click "Push to stable" and then edit in the new build, bypassing the check, but I believe this has unfortunately been fixed at some point, either automatically canceling the stable push request or locking the update to prevent adding builds unless the request is manually canceled first.)
kio-extras is a separate package, it can in principle be pushed separately. But of course the versions should match. In the end, @tdawson will have to decide whether to edit the update with the new build, resetting the karma and time counters, or push a followup update.
(This is one of the cases where the current Fedora update policy just fails us. Without those Bodhi-enforced rules, we could just edit the update with the added build and queue it directly to stable anyway, because 99.7% of the builds in it would still have been tested sufficiently, and the one added build is a regression fix. But unfortunately, the EPEL steering committee wants those annoying rules even more than Fedora FESCo does, and FESCo already wants them a lot.)
kf5-kio is build with gcc-toolset-9 which is already EOL.
Why does that matter? As far as I can tell, it does not have any runtime dependencies on the toolset.
For the weather widget issue, note that it does not apply to the Weather plasmoid that ships with Plasma, but only to the third-party Weather Widget plasmoid (https://github.com/kotelnik/plasma-applet-weather-widget).
KWrite used to be a UI shell around the KatePart, now the UI shell code is also mostly shared and KWrite is just a kind of a skin for the Kate UI. The developers figured it does not make sense to maintain 2 completely separate shells (Kate and KWrite) for the same editor component (KatePart).
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.)
Does disabling systemd user sessions (
kwriteconfig5 --file startkderc --group General --key systemdBoot false– as your regular user, NOT as root) fix it?