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.

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

Works as desired, thanks!

@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).

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

@kkofler: Please clarify, what I suppose to do here/now? Why invalid -1?! It is not right place to argue or to blame anyone, but above fix from testing repo break my distro which hangs on blank screen on boot, I had to recover/rollback it in single user console, and you expect to give +1 to unblock this changes to go to PROD? This is not OK for me. Whoever is happy with it is free to give missing +1 to unblock it. I do not plan to apply any other testing fixes, investigate regressins, or anything else, because I do not have more time to play laboratory mouse and to recover my system again (most probably). It is not crucial for me to work with outdated kwin-x11 until official fix.

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.)

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.

@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.

@kkofler: Thanks for prompt update. Suggested procedure was applied to my personal laptop and works fine, but not tested on my workstation, because I can't risk to block my tasks, so I can't confirm if the fix will work on intact system (it was not affected by all this upgrades/downgrades). In this case I'll give +1 and sorry for the all the mess above. Anyway, it will be good to know, that there is some more general issue with package management and especially when do rollback, which somehow should be addressed. Thanks again.