Comments

196 Comments

@ptonsokov: After your botched transactions, I would try to fix your system like this:

su -
dnf remove kwin-x11
dnf distro-sync
dnf install kwin
dnf --enablerepo=updates-testing install kwin-x11
dnf install plasma-workspace-x11

(the dnf install kwin is to be sure that all the dependencies of kwin-x11 are installed from the stable repository, not the testing one – if kwin is already installed, it should not do anything at all) and if it then still does not boot, then there is a genuine bug (but probably in FEDORA-2025-141558bd16 and not in this update!) – if it boots fine, then the issue was what you did to your system and the above fixed it.

Or, as I had already pointed out, the other possibility is that the bug you are seeing is a regression from Qt 6.8 or some other update in the mix that (considering that the other 2 testers have not hit it) is somehow specific to your hardware. In that case, withholding this rebuild of kwin-x11 is not going to really fix the problem either, just indirectly preventing users from hitting it by preventing them from upgrading Qt (which has undesirable side effects, as you have noticed yourself). But it is impossible to tell given how you have messed up your installation with those --allowerasing transactions.

The thing is: 1. this update cannot plausibly be the cause of your error, and 2. two people tested it and reported it to work fine.

Before installing this update, you ran 2 DNF transactions with --allowerasing, downgrading several packages to the 9 months old versions that originally shipped with Fedora 40, and maybe also removing some needed packages. That was entirely the wrong way to deal with the broken dependencies in the stable updates. (Instead, you should just have let DNF hold back the update and waited for the fix provided by this update. If at all, update with --skip-broken, which is what the GUI tools default to for a reason, never with --allowerasing.) Given that you are the only user who reported issues allegedly caused by this update, I can only assume that your failure to boot was due to those transactions, or due to how you then installed this update, for which you have not posted any logs, so I do not know how DNF resolved the dependencies coming from the broken state into which you had previously put your system. (Hint: It is generally assumed that you have installed, and not downgraded in the meantime, all previous updates before this testing update.)

@ptsonkov: 5 days already that the dependencies are needlessly still broken because of your invalid -1 vote.

@ptsonkov: Or it is possible that you just messed up your system with those dnf --allowerasing operations, removing some essential packages, or having a weird mix of ancient (not just old, as in, the previous updates, but ancient, as in, the packages Fedora 40 was originally released with months ago, because previous updates are NOT available from the mirrors to downgrade to, so downgrading from the mirrors is almost always a bad idea) and new packages installed. The right thing to do in case of dependency issues is to just wait until they are fixed (and to give a +1, not a -1, to the updates that fix them).

(Or it might be caused by some lower-level package, e.g., kernel.)

This is just not helpful. This update is urgently needed to fix broken dependencies. (The current package is not installable at all.) With your -1 vote, you just manage to delay the fix longer and make the distribution sit with broken dependencies for longer.

Whatever is causing your issue, it is for surely NOT this update, which is only a rebuild for broken dependencies with no other changes. My guess is that your issue is probably a regression from FEDORA-2025-141558bd16.

The Qt update breaks kwin-x11: https://bugzilla.redhat.com/show_bug.cgi?id=2341705 I have rebuilt it and am pushing an update now.

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.