kde February 2023

kde@lists.fedoraproject.org

13 participants
12 discussions

Plan / proposal: enable openQA update testing and potentially gating on Rawhide updates
by Adam Williamson 09 Jun '23

09 Jun '23

Hi folks! We've had openQA testing of updates for stable and branched releases, and gating based on those tests, enabled for a while now. I believe this is going quite well, and I think we addressed the issues reported when we first enabled gating - Bodhi's gating status updates work more smoothly now, and openQA respects Bodhi's "re-run tests" button so failed tests can be re-triggered. A few weeks ago, I enabled testing of Rawhide updates in the openQA lab/stg instance. This was to see how smoothly the tests run, how often we run into unexpected failures or problems, and whether the hardware resources we have are sufficient for the extra load. So far this has been going more smoothly than I anticipated, if anything. The workers seem to keep up with the test load, even though one out of three worker systems for the stg instance is currently out of commission (we're using it to investigate a bug). We do get occasional failures which seem to be related to Rawhide kernel slowness (e.g. operations timing out that usually don't otherwise time out), but on the whole, the level of false failures is (I would say) acceptably low, enough that my current regime of checking the test results daily and restarting failed ones that don't seem to indicate a real bug should be sufficient. So, I'd like to propose that we enable Rawhide update testing on the production openQA instance also. This would cause results to appear on the Automated Tests tab in Bodhi, but they would be only informational (and unless the update was gated by a CI test, or somehow otherwise configured not to be pushed automatically, updates would continue to be pushed 'stable' almost immediately on creation, regardless of the openQA results). More significantly, I'd also propose that we turn on gating on openQA results for Rawhide updates. This would mean Rawhide updates would be held from going 'stable' (and included in the next compose) until the gating openQA tests had run and passed. We may want to do this a bit after turning on the tests; perhaps Fedora 37 branch point would be a natural time to do it. Currently this would usually mean a wait from update submission to 'stable push' (which really means that the build goes into the buildroot, and will go into the next Rawhide compose when it happens) of somewhere between 45 minutes and a couple of hours. It would also mean that if Rawhide updates for inter-dependent packages are not correctly grouped, the dependent update(s) will fail testing and be gated until the update they depend on has passed testing and been pushed. The tests for the dependent update(s) would then need to be re- run, either by someone hitting the button in Bodhi or an openQA admin noticing and restarting them, before the dependent update(s) could be pushed. In the worst case, if updated packages A and B both need the other to work correctly but the updates are submitted separately, both updates may fail tests and be blocked. This could only be resolved by waiving the failures, or replacing the separate updates with an update containing both packages. All of those considerations are already true for stable and branched releases, but people are probably more used to grouping updates for stable and branched than doing it for Rawhide, and the typical flow of going from a build to an update provides more opportunity to create grouped updates for branched/stable. For Rawhide the easiest way to do it if you need to do it is to do the builds in a side tag and use Bodhi's ability to create updates from a side tag. As with branched/stable, only critical path updates would have the tests run and be gated on the results. Non-critpath updates would be unaffected. (There's a small allowlist of non-critpath packages for which the tests are also run, but they are not currently gated on the results). I think doing this could really help us keep Rawhide solid and avoid introducing major compose-breaking bugs, at minimal cost. But it's a significant change and I wanted to see what folks think. In particular, if you find the existing gating of updates for stable/branched releases to cause problems in any way, I'd love to hear about it. Thanks folks! -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net

1 2

Plasma logout oddness possible systemd-homed involvement
by Ian Malone 28 Feb '23

28 Feb '23

I'm not motivated to investigate this further, but in case anyone else is having a similar problem. After recent updates (currently plasma-desktop-5.27.1-1.fc37.x86_64 sddm-0.19.0^git20230201.3ee57e9-2.fc37.x86_64) I had a number of issues, the most annoying of which was inability to log out on Plasma+X11. First the login screen only showed a password dialogue, white background and a small (apparently power) icon at the bottom right, user selection was not possible, no response to Esc key, power icon not clickable. Login via password for my normal user worked. This appears to have been fixed by using system settings to change the login screen. Second wallpaper setting was lost, but as this frequently happens with Plasma upgrades recently it may be unconnected. More unusually the lock screen background has changed to black, which I have not seen before. Lastly, as in the subject, logging out became an issue. Both Plasma+X11 and Plasma+Wayland sessions simply hung on log out, whether or not the logout screen option was selected. Without logout screen this happened immediately on clicking logout, with logout screen it happened after confirming logout. Whether the display blanked or just froze appeared variable. Restarting and shutdown were fine. I was unable to find any particularly noteable journal messages, however there was a mention of systemd-homed being unable to find home for sddm user and my account (Not a user managed by systemd-homed: No home for user sddm known). On a whim I tried stopping systemd-homed during a frozen logout (from a virtual terminal) then stopping graphical.target and starting it again. After this I was able to log out successfully from Plasma, and this has persisted across reboots despite systemd-homed still running. Prior to this I had tried an .autorelabel (without success) and, as mentioned, both X11 and Wayland sessions had the same issue. -- imalone http://ibmalone.blogspot.co.uk

1 0

[Fedocal] Reminder meeting : KDE SIG
by ngompa＠fedoraproject.org 26 Feb '23

26 Feb '23

Dear all, You are kindly invited to the meeting: KDE SIG on 2023-02-27 from 13:00:00 to 14:00:00 US/Eastern At https://meet.kde.org/b/ale-swq-39j The meeting will be about: Regular meeting for the KDE SIG Current Topics: https://pagure.io/fedora-kde/SIG/issues?status=Open&tags=meeting More information available at: [https://fedoraproject.org/wiki/SIGs/KDE](https://fedoraproject.org/wiki/SIG… Source: https://calendar.fedoraproject.org//meeting/9876/

1 0

welcome dialog on a Live image?
by Kamil Paral 23 Feb '23

23 Feb '23

There's a new Welcome dialog in KDE on F38. However, it's also started on a Live image. Some part of it makes sense (basic info about the desktop), but some part doesn't (usage collection request, online accounts configuration). I wonder if it's supposed to start on a Live image or not?

4 7

KDE Plasma (Fedora 37) performance on Raspberry Pi 4
by Syam Krishnan 23 Feb '23

23 Feb '23

Hi I got a Raspberry Pi 4 board with 8 GB RAM today, and tried both KDE Plasma and Fedora Workstation images on it. While the workstation (with Gnome) works pretty well, the Plasma desktop is quite sluggish when it comes to graphics. Moving windows around a bit fast, tool-tip popups on taskbar elements etc. are noticeably sluggish and have significant response delays. Gnome desktop does not have any such issues. Both are running the same kernel versions. But they are two different images (both downloaded from Fedora website), so I don't know if there are any relevant differences in the pre-installed packages. Any ideas on how to rectify this? I was on KDE/X11 most of the time, and during a brief testing with KDE/Wayland, it didn't fare any better. Thanks, Syam

4 5

[Fedocal] Reminder meeting : KDE SIG
by ngompa＠fedoraproject.org 19 Feb '23

19 Feb '23

Dear all, You are kindly invited to the meeting: KDE SIG on 2023-02-20 from 13:00:00 to 14:00:00 US/Eastern At https://meet.kde.org/b/ale-swq-39j The meeting will be about: Regular meeting for the KDE SIG Current Topics: https://pagure.io/fedora-kde/SIG/issues?status=Open&tags=meeting More information available at: [https://fedoraproject.org/wiki/SIGs/KDE](https://fedoraproject.org/wiki/SIG… Source: https://calendar.fedoraproject.org//meeting/9876/

1 0

Window moving virtual desktop
by Mark ＠ GMail 18 Feb '23

18 Feb '23

Now (since F37, I think), clicking on a URL in an email (in Evolution, 3.46.3-1.fc37) moves my browser (FireFox) to the same virtual desktop that Evolution is in. It didn't used to do this, and it's not what I want, but I can see some might want that, so is it an option somewhere? If so, where? Many thanks, Mark Fedora Linux 37, Workstation KDE Plasma 5.26.5 KDE Frameworks 5.102.0 Qt 5.15.8 Kernel 6.1.10-200.fc37.x86_64 Graphics Platform X11

2 5

Dolphin not saving state
by Patrick O'Callaghan 13 Feb '23

13 Feb '23

For years I've had a fixed set of three Dolphin windows opened (in a saved session) when I log in, each of them in a specific directory, two with split panels and one with a single panel. The single-panelled one also has the terminal pane open. Since installing dolphin-22.12.2-1.fc37.x86_64 this no longer works. I still get the three windows in the right places, but they are all showing my home directory and a single panel. None has the terminal pane open. Where does Dolphin store its session state? Or is this a wider problem? I'm on X11 because of general issues with session restore on Wayland, but this looks like a regression. poc

1 0

[Fedocal] Reminder meeting : KDE SIG
by ngompa＠fedoraproject.org 12 Feb '23

12 Feb '23

Dear all, You are kindly invited to the meeting: KDE SIG on 2023-02-13 from 13:00:00 to 14:00:00 US/Eastern At https://meet.kde.org/b/ale-swq-39j The meeting will be about: Regular meeting for the KDE SIG Current Topics: https://pagure.io/fedora-kde/SIG/issues?status=Open&tags=meeting More information available at: [https://fedoraproject.org/wiki/SIGs/KDE](https://fedoraproject.org/wiki/SIG… Source: https://calendar.fedoraproject.org//meeting/9876/

1 0

Screen locker fails after update to F37
by Tim Landscheidt 12 Feb '23

12 Feb '23

Hi, I use a plain black screen as the screen locker in KDE/Way- land, and I have "linger" enabled in systemd for my user. I updated from F35 to F37 three days ago; there are parts of my KDE configuration that are a decade old. Whenever the time comes for the screen to lock up, a trans- lated message appears on the screen instead informing that the screen locker is broken and that I should use "loginctl unlock-session $nr" in a plain shell (which works). I searched for this error, and one suggestion was to exe- cute: | [tim@vagabond ~]$ /usr/libexec/kscreenlocker_greet --testing | kscreenlocker_greet: Lockscreen QML outdated, falling back to default | kf.kirigami: Failed to find a Kirigami platform plugin | Speicherzugriffsfehler (Speicherabzug geschrieben) | [tim@vagabond ~]$ (last line meaning core dumped). So I went to the KDE "Systemeinstellungen" (system set- tings?) to rewrite any relevant configuration in the current format, disabled the lock screen, applied the configuration, enabled it again, applied the configuration, no luck. Re- booted, no luck. There is a package kf5-kirigami2-5.102.0-1.fc37.x86_64 installed, and with https://api.kde.org/frameworks/kirigami/html/ using "plat- form" as referring to "Plasma Mobile, Desktop Linux, An- droid, iOS and Windows", I don't see another package that could be expected to provide a "Kirigami platform plugin". On a whim, I also installed kf5-kirigami-1.1.0-18.fc37.x86_64 because the error message only referred to "Kirigami", not "Kirigami2", but this does not change the failure. So I would appreciate any ideas where to start looking for a solution. Is "kscreenlocker_greet --testing" supposed to work in Fedora? Fedora 37? Fedora 37 with Wayland? TIA, Tim

1 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

kde February 2023