kde June 2022

kde@lists.fedoraproject.org

19 participants
17 discussions

KDED causing long delay on shutdown?
by Patrick O'Callaghan 18 Jul '22

18 Jul '22

This has been happening for IIRC) several months now at least: $ journalctl --boot=-1 --reverse ... May 01 10:44:26 Bree systemd[1210]: plasma-kded.service: Consumed 18.380s CPU time. May 01 10:44:26 Bree systemd[1210]: Stopped KDE Daemon. May 01 10:44:26 Bree systemd[1210]: plasma-kded.service: Failed with result 'timeout'. May 01 10:44:26 Bree systemd[1210]: plasma-kded.service: Main process exited, code=killed, status=9/KILL May 01 10:44:26 Bree systemd[1210]: plasma-kded.service: Killing process 1791 (ProfilesWatcher) with signal SIGKILL. May 01 10:44:26 Bree systemd[1210]: plasma-kded.service: Killing process 1722 (kded5) with signal SIGKILL. May 01 10:44:26 Bree systemd[1210]: plasma-kded.service: State 'stop-sigterm' timed out. Killing. <-----------------------* May 01 10:43:03 Bree systemd[1]: Unmounted /run/user/0. May 01 10:43:03 Bree systemd[1]: run-user-0.mount: Deactivated successfully. May 01 10:43:03 Bree systemd[1]: Unmounted /run/user/990. May 01 10:43:03 Bree systemd[1]: run-user-990.mount: Deactivated successfully. May 01 10:43:03 Bree systemd[1]: Stopped Network Manager Wait Online. ... Any idea why? I see some apparently related BZ entries dating back a couple of years, but nothing recently. poc

5 11

Restore session fix upstream (should be out with 2.25.2)
by José Abílio Matos 01 Jul '22

01 Jul '22

The major pain point, when using kde, for has been the session handling. I use session restore, that means that the windows, with all the associated properties, are remembered and restored on login. The issue we had was the windows were remembered correctly but not its placement and other properties. This has happened for some time, since Fedora 33. Now finally the issue was identified and a solution should come to plasma 5.25.2: https://bugs.kde.org/show_bug.cgi?id=442380 It will be nice to have this fixed, finally. :-) -- José Abílio

2 3

How to set active title bar color?
by Jonathan Ryshpan 28 Jun '22

28 Jun '22

I have just upgraded to Fedora-36. Now the active window has a title bar colored dark gray and other windows have title bars colored light gray. I want to change the color of the title bar of the active window to something more visible, say blue. How can this be done? Sysetm settings: Operating System: Fedora Linux 36 KDE Plasma Version: 5.24.5 KDE Frameworks Version: 5.94.0 Qt Version: 5.15.3 Kernel Version: 5.18.6-200.fc36.x86_64 (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-4790K CPU @ 4.00GHz Memory: 15.4 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 4600 -- Sincerely Jonathan Ryshpan <jonrysh(a)pacbell.net> Political language ... is designed to make lies sound truthful and murder respectable, and to give an appearance of solidity to pure wind. -- George Orwell

3 3

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

22 Jun '22

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 1

Removing knode removes akonadi
by HF 22 Jun '22

22 Jun '22

Greetings, i tried to `dnf remove knode` because it is unmaintained and i do not need it, but this also removes akonadi and some kdepimlibs, which i think are required for other KDE applications to work. Is this a dependency problem that needs a bug report, is my system messed up, or is it save to remove akonadi thanks

4 3

What is this icon/widget?
by John Horne 22 Jun '22

22 Jun '22

Hello, Unfortunately it seems that picture attachments are not accepted, but the text of my message was: ==== I use KDE/plasma/wayland, and have recently upgraded my laptop from Fedora 35 to Fedora 36. What I have noticed is an odd icon/widget has appeared on the desktop - see attached screen snapshot, the icon/widget is between the 'U' and 'X' characters and appears as a thin white line. I have no idea what it is, or how to remove it. I can move the icon/widget around the desktop, but a left or right mouse click, or pressing the return or escape key, does nothing. At the moment I have moved it as far as possible into one of the desktop corners, so that it does interfere with anything else on the desktop. Anyone any idea what it is? ==== Obviously a picture would help, but as said it is basically a thin white line, a couple of inches long, with a short grey bit in the middle. If anything it looks a slider of some sort but it doesn't 'slide'. Thanks, John. -- John Horne | Senior Operations Analyst | Technology and Information Services University of Plymouth | Drake Circus | Plymouth | Devon | PL4 8AA | UK ________________________________ [http://www.plymouth.ac.uk/images/email_footer.gif]<http://www.plymouth.ac.uk/worldclass> This email and any files with it are confidential and intended solely for the use of the recipient to whom it is addressed. If you are not the intended recipient then copying, distribution or other use of the information contained is strictly prohibited and you should not rely on it. If you have received this email in error please let the sender know immediately and delete it from your system(s). Internet emails are not necessarily secure. While we take every care, University of Plymouth accepts no responsibility for viruses and it is your responsibility to scan emails and their attachments. University of Plymouth does not accept responsibility for any changes made after it was sent. Nothing in this email or its attachments constitutes an order for goods or services unless accompanied by an official order form.

2 3

Dolphin with fish
by Emmett Culley 19 Jun '22

19 Jun '22

Today I attempted to adjust a webserver configuration using dolphin to connect to fish://root@server/etc. Connection worked as usual and I found I was looking at a listing of the /etc directory. All good and expected. Then I clicked on httpd which switched to listing the /etc/httpd directory. I then clicked on conf.d and got this message at the top of dolphin: "The file fish://server/etc/httpd/conf.d could not be loaded, as it was not possible to read from it. Check if you have read access to this file." And in a pop up dialog I saw this: "Could not read file fish://server/etc/httpd/conf.d." On closer inspection I saw that there was no > next to the directory conf.d, which usually means it is not a directory, but the permissions showed drwxr-xr-w. So I logged into that server via ssh and was able to enter /etc/httpd/conf.d without a problem, and from there edit or view any of the apache config files. Then I tried renaming the conf.d directory to conf_d from the dolphin fish connection. Then I was able click on conf_d to descend into that directory and edit any of the apache config files there. I tried renaming the directory to conf.d and after that was able to descend into that directory from that dolphin session. Closing dolphin, opening it again and connectin to that server via fish again, I was again not able to get into the/etc/httpd/conf.d directory. Turns out this happens no matter which server I connect, some of which are Rocky Linux, most are CentOS Stream 8, and two are CentOS 7. All do the same. That is, any directory named *.d cannot be decended into via fish on dolpin. I just upgraded to Fedora 36, and this was not a problem before the upgrade. I use dolphin multiple times a day to connect to the servers I manage, and this is the first time I saw this. So my question is, is it possible there is a configuration setting I am missing. I will fils a bug regardless, but I was hoping there might be a work around. Emmett

1 2

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

19 Jun '22

Dear all, You are kindly invited to the meeting: KDE SIG on 2022-06-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

Re: Plan / proposal: enable openQA update testing and potentially gating on Rawhide updates
by Adam Williamson 17 Jun '22

17 Jun '22

On Fri, 2022-06-17 at 19:33 +0000, Dan Čermák wrote: > Sounds like a great addition Adam! > > Just to double check: if you have not enabled gating, then openQA will not be run at all? No, the two are separable. We can enable the tests before we turn on gating. Right now, the tests are already running, but only on the stg/lab instance of openQA - https://openqa.stg.fedoraproject.org/group_overview/2 (that shows all update tests, not just Rawhide ones). We can turn them on in production without turning on gating. Although when we don't gate, there can be an effect where an update that makes the tests fail gets pushed stable, and then *all* subsequent updates start failing the same way - this happened recently with the 389-ds-base update that broke FreeIPA deployment, after that was pushed stable, all Rawhide updates failed the FreeIPA tests until the fixed 389-ds-base reached a compose yesterday. This is one big reason I would like to enable gating. :D Without gating, I have to run around cleaning up cases like that manually - getting the issues fixed as fast as possible and then re- running failed tests once the fix lands. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net

1 0

Taskbar Icons
by Jonathan Ryshpan 17 Jun '22

17 Jun '22

The Icons Only Task Manager highlights (if this is the right word) the icons in the taskbar which represent running programs in light gray. Is it possible to highlight them in s more distictive color or mark them with a tag? If so, how? -- Sincerely Jonathan Ryshpan <jonrysh(a)pacbell.net> Dance, as if nobody's watching, Love, as if you've never been hurt, Sing, as if no one can hear you, Work, as if you don't need the money, Live, as if heaven is on earth. -- Rumi

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

kde June 2022