Comments

187 Comments

Note: My severity rating "urgent" is because previous versions of Merkaartor are basically not usable at all any longer because OpenStreetMap server changes have made them read only. Uploads require (and have always required) authentication, and since 2024-07-01, authentication has only been allowed through OAuth2, which was not supported by Merkaartor prior to the version 0.20.0 shipped by this update.

Note: My severity rating "urgent" is because previous versions of Merkaartor are basically not usable at all any longer because OpenStreetMap server changes have made them read only. Uploads require (and have always required) authentication, and since 2024-07-01, authentication has only been allowed through OAuth2, which was not supported by Merkaartor prior to the version 0.20.0 shipped by this update.

Note: My severity rating "urgent" is because previous versions of Merkaartor are basically not usable at all any longer because OpenStreetMap server changes have made them read only. Uploads require (and have always required) authentication, and since 2024-07-01, authentication has only been allowed through OAuth2, which was not supported by Merkaartor prior to the version 0.20.0 shipped by this update.

@erentar, thanks, but the update was already pushed to stable approximately 16 minutes before your +1, so now it is just a matter of the mirrors syncing the update (and, depending on how you update, of your local updater refreshing the repository metadata). I cannot do anything to make that happen any faster.

Why does it not recognize the software codec (openh264) on its own, only if you also install the hardware acceleration? Depending on various factors (CPU speed, screen resolution, etc.), software encoding may well be good enough.

Thanks! Should now be heading directly to stable in the next update push.

I cannot submit this to stable before it reaches testing, whereas Bodhi itself can with autokarma, which is inconsistent and backwards. (If anything, pushing something to stable before it reaches testing should always require manual confirmation.) I have enabled autokarma now, but I think it will need another +1 before Bodhi does anything.

X11 support update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-73dd3543c5 – please test (and give positive karma if it works for you).

plasma-workspace-x11 update is missing here

Because this was rushed to stable less than 8 hours after it was submitted. No time for me to build the missing packages. (I usually manage to build them at the same time as the chainbuild, but this time this was not possible for personal reasons.)

Plasma upgrades should NOT have autokarma enabled. Especially not upgrades from 6.n to 6.n+1. And independently of whether -x11 packages are already built or not. There is no way to catch all regressions in less than 8 hours, without the update even having ever hit the testing repository.

Breaks plasma-workspace-x11. See bug #2284237.

You folks have to notify me for EVERY kwin or plasma-workspace update, not only for the big updates of all of Plasma for which you have automation set up right now. Even if it is a 4th digit bump like this, or even just a backported patch that breaks the ABI like the recent KWin patch that caused bug #2280899.

The new build should fix applying the patch, please retest.

Please retry with kile-2.9.94-2.fc40, I fixed the bad Requires.

Grrr, not understandable why they do not have a versioned Provides for konsole-part anymore, since it is clear that the different major versions are not interchangeable. I am going to fix the Requires, but it is really the konsole package that is broken.

KParts need to be shipped for the different major versions. The KDE SIG is no longer doing that. They dropped the kdelibs4 and KF5 KonsolePart and are shipping only the KF6 one, which breaks applications. And they do not even include a versioned Provides so the application cannot even state which version it requires, so when Plasma 7 will hit, this will silently break as we have already seen with the OkularPart.

This was an attempt at getting this build into F41/Rawhide without a rebuild. As you can see, it confused Bodhi, which wanted to push it to F40 updates despite it already being in F40 GA. Hence I unpushed it.

python3-qt5-base is not installable, seems to be missing a python-pyqt5-sip update: https://bugzilla.rpmfusion.org/show_bug.cgi?id=6877#c2

Also, qt5-qtwebengine-5.15.16-2.fc38 breaks the upgrade path to Fedora 39, should be built as qt5-qtwebengine-5.15.16-1.fc38.1.

IMHO, it is unacceptable to deliberately push to stable an update known to break an application. It defeats the very purpose of the update testing process to knowingly push regressions reported here to stable.

At this point, we are not even talking about a development branch anymore, but about a 0-day update to a stable release. There ought to be a minimum quality standard for such an update. There is also no deadline to hit given that the release is already in Final Freeze.

I am retagging all the packages in this update into f39-updates-candidate.

This looks like kdepim-runtime-libs should have an Obsoletes: kf5-kmailtransport-akonadi < 23.08.

I have blogilo building in f40-build-side-74444 now: I have built the following packages there:

  • ktextaddons-1.5.1-1.fc40 (built by @marcdeop, not by me)
  • kf5-kpimtextedit-23.08.1-3.fc40
  • kf5-pimcommon-23.08.1-2.fc40
  • kf5-messagelib-23.08.1-2.fc40
  • blogilo-17.08.3-28.fc40

Can we push that side tag to Rawhide stable or are there more packages that should be rebuilt first?

If everything is good, we need these 5 packages rebuilt in f39-build-side-74302 so that they are included in this update.