KDE Plasma 6.7.3
Updates may require up to 24 hours to propagate to mirrors. If the following command doesn't work, please retry later:
sudo dnf upgrade --refresh --advisory=FEDORA-2026-9d3152048cPlease log in to add feedback.
| 0 | 1 | Test Case bluedevil |
| 0 | 0 | Test Case upgrade plasma-discover current kde |
This update's test gating status has been changed to 'waiting'.
This update has been submitted for testing by bodhi.
This update's test gating status has been changed to 'failed'.
Works for me..
Nothing is broken after few hours of heavy use, so lgtm
This is failing in the same openQA test as the Rawhide update, but weirdly, in a totally different way.
On F44 the test gets much further than on Rawhide, where plasma-login-manager crashes on the first logout we do and we wind up at a console instead of the login screen.
On F44 we fail much later, during the 'switch user' portion of the test. We're logged in as 'jim' after testing various other things (the last thing we tested previously was screen locking). As jim, we launch a konsole using the ctrl-alt-t shortcut. We then open the kicker, click Session, and click Switch User. We click on the 'jack' user and enter jack's password. We wait to reach a desktop, then use ctrl-alt-t to launch a konsole as jack. In the konsole, we run
[ $(whoami) = "jack" ]and check its exit code to ensure we are, in fact, jack. We then open the kicker, click Session, and click Switch User again, and switch back to jim. In jim's desktop, we run the same whoami check -[ $(whoami) = "jim" ]this time, of course - to make sure we're jim. Then we hitalt-f4, intending to close the konsole - but instead it switches us to tty4. i.e. it acts like we hitctrl-alt-f4.Notably this only happens at this, late point in the test. There are three points earlier in the test where we similarly open a konsole with
ctrl-alt-t, run thewhoamicheck, then hitalt-f4to close the konsole, and it works. I can only think that, somehow, KDE now loses track of the state of thectrlkey during the user switches?The failures are consistent and repeatable - the test failed the same way across three tries each on aarch64 and x86_64, on both prod and staging, for a total of 12 identical failures. The test does not fail with previous or subsequent updates, indicating the failure really is caused by this update.
Bodhi is disabling automatic push to stable due to negative karma. The maintainer may push manually if they determine that the issue is not severe.
Can't reproduce this in a local VM, annoyingly. Could be related to how exactly os-autoinst sends key events or something. I also tried adding a press of 'ctrl' before the 'alt-f4' to see if that changed anything, but it didn't...
Interestingly, this can be fixed in the same way as the crash bug that affects the Rawhide update: by reverting b49a7c471e05f7c5f098c0e16461ca5133380d08 , the backport to 6.7.3 of https://invent.kde.org/plasma/plasma-login-manager/-/merge_requests/151 .
So reverting that patch fixes all the problems openQA hits in 6.7.3 on both F44 and Rawhide. With that patch reverted, all tests pass on both F44 and Rawhide.
This update has been pushed to testing.
all is working
farchord edited this update.
New build(s):
Removed build(s):
Karma has been reset.
This update has been submitted for testing by farchord.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'passed'.
farchord edited this update.
New build(s):
Removed build(s):
Karma has been reset.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'passed'.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'passed'.
farchord edited this update.
farchord edited this update.
This update has been submitted for stable by farchord.
This update has been pushed to stable.
plasma-login-manager-6.7.3-4.fc44 is OK