kde August 2020

kde@lists.fedoraproject.org

23 participants
17 discussions

Release criteria proposal: networking requirements
by Adam Williamson 01 Mar '22

01 Mar '22

Hi folks! So at this week's blocker review meeting, the fact that we don't have explicit networking requirements in the release criteria really started to bite us. In the past we have squeezed networking-related issues in under other criteria, but for some issues that's really difficult, notably VPN issues. So, we agreed we should draft some explicit networking criteria. This turns out to be a big area and quite hard to cover (who'd've thought!), but here is at least a first draft for us to start from. My proposal would be to add this to the Basic criteria. I have left out some wikitext stuff from the proposal for clarity; I'd add it back in on actually applying the proposed changes. It's just formatting stuff, nothing that'd change the meaning. Anyone have thoughts, complaints, alternative approaches, supplements? Thanks! === Network requirements === Each of these requirements apply to both installer and installed system environments. For any given installer environment, the 'default network configuration tools' are considered to be those the installer documents as supported ways to configure networking (e.g. for anaconda-based environments, configuration via kernel command line options, a kickstart, or interactively in anaconda itself are included). ==== Basic networking ==== It must be possible to establish both IPv4 and IPv6 network connections using DHCP and static addressing. The default network configuration tools for the console and for release-blocking desktops must work well enough to allow typical network connection configuration operations without major workarounds. Standard network functions such as address resolution and connections with common protocols such as ping, HTTP and ssh must work as expected. Footnote titled "Supported hardware": Supported network hardware is hardware for which the Fedora kernel includes drivers and, where necessary, for which a firmware package is available. If support for a commonly-used piece or type of network hardware that would usually be present is omitted, that may constitute a violation of this criterion, after consideration of the [[Blocker_Bug_FAQ|hardware-dependent- issues|normal factors for hardware-dependent issues]]. Similarly, violations of this criteria that are hardware or configuration dependent are, as usual, subject to consideration of those factors when determining whether they are release-blocking ==== VPN connections ==== Using the default network configuration tools for the console and for release-blocking desktops, it must be possible to establish a working connection to common OpenVPN, openconnect-supported and vpnc-supported VNC servers with typical configurations. Footnote title "Supported servers and configurations": As there are many different VPN server applications and configurations, blocker reviewers must use their best judgment in determining whether violations of this criterion are likely to be encountered commonly enough to block a release, and if so, at which milestone. As a general principle, the more people are likely to use affected servers and the less complicated the configuration required to hit the bug, the more likely it is to be a blocker. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

4 7

How to set default session type to Plasma for sddm
by Roderick Johnstone 29 Oct '21

29 Oct '21

Hi How do I set the default session type for sddm to offer to be Plasma? I'm currently getting Gnome Classic? This is F22. Thanks Roderick Johnstone

7 13

KDE on RHEL 8
by Syam Krishnan 22 Oct '20

22 Oct '20

Hi What is the recommended method to install KDE on RHEL 8? I tried adding EPEL repo and did: yum groupinstall "KDE Plasma Workspaces" But this fails with: ================ Error: Problem 1: conflicting requests - nothing provides xmessage needed by plasma-workspace-5.18.4.1-2.el8.x86_64 Problem 2: package sddm-breeze-5.18.4.1-2.el8.noarch requires plasma-workspace = 5.18.4.1-2.el8, but none of the providers can be installed - conflicting requests - nothing provides xmessage needed by plasma-workspace-5.18.4.1-2.el8.x86_64 Problem 3: package plasma-desktop-5.18.4.1-2.el8.1.x86_64 requires plasma-workspace >= 5.18, but none of the providers can be installed - conflicting requests - nothing provides xmessage needed by plasma-workspace-5.18.4.1-2.el8.x86_64 Problem 4: package kde-print-manager-19.12.3-2.el8.x86_64 requires plasma-workspace, but none of the providers can be installed - conflicting requests - nothing provides xmessage needed by plasma-workspace-5.18.4.1-2.el8.x86_64 ================ Do I need to do anything else to install KDE off EPEL? or is there another source? Thanks Syam

4 14

Plasma + sddm
by Frédéric 25 Sep '20

25 Sep '20

Hi, I'm running Plasma + sddm on F31. Since a week, I try to use the computer with multiple users and then I log off before the other user logs in. When I log off, the screen just freezes. I can switch to a console screen with Ctrl+Alt+F2 and kill all processes of the first user (systemd, agent, sddm_helper) until I get the login screen again. Very annoying. Is there a way to make it work? Kind regards, F

4 5

Future of shared-mime-info in Fedora
by Miro Hrončok 28 Aug '20

28 Aug '20

Hello Fedorans, Bastien, I have noticed that the shared-mime-info package was orphaned couple days ago. Bastien, AFAIK you were the primary point of contact in Fedora and I also see you are the RHEL 8 default bugzilla assignee. Considering the following commit: https://gitlab.freedesktop.org/xdg/shared-mime-info/-/commit/6f4947b01 I've disregarded the idea the the package was orphaned by accident. I also see that GNOME mime types have been moved away from the package (on rawhide only): https://src.fedoraproject.org/rpms/shared-mime-info/c/da05922d10 https://src.fedoraproject.org/rpms/gnome-desktop3/c/9909d22b I always considered shared-mime-info an important package, however I don't see it in comps. Maybe it is no longer that important? A repoquery reveals ~50 packages that require it including PackageKit, Thunar (Xfce), some NetworkManager packages, kdelibs (KDE)... A recursive repoquery yields ~ 6650 packages. I've taken the orphaned package for now to avoid any disruption (and a totally unreadable orphans report), but I don't really understand the Fedora package, it has a manually created source without any comment explaining where is this from: https://src.fedoraproject.org/rpms/shared-mime-info/blob/master/f/mimeapps.… Bastien, could you please give me a hint about this file? Thanks --------- The package technically has 8 co-maintainers and a sig, but I don't put much hopes into the crowd there considering they haven't touched the package in years. Are there any interested Fedora packages that understand mime info better than I do --------- PS There is an interesting file-ownership problem reported in Bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=1486468 - I plan to discuss this later on the packaging mailing list as well. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

2 3

Re: Proposal to Add: Log In/Out Blocker Criteria
by Kamil Paral 26 Aug '20

26 Aug '20

On Wed, Aug 12, 2020 at 4:25 PM Kamil Paral <kparal(a)redhat.com> wrote: > I'd accept the criterion as proposed (because we need it now), and do the > reorganization later (possibly when this cycle is over and we have more > time to bikeshed about best criterion layout). I'm fine with either adding > to the existing criterion (mine version) or creating a standalone criterion > (Geoff's version), just note that the standalone version would still need > to get tweaked (remove "multiple user accounts", etc). > In accordance with the discussion during the last QA meeting, I've put my proposed changes live: https://fedoraproject.org/w/index.php?title=Fedora_33_Beta_Release_Criteria…

1 0

dnfdragora icon update
by Ed Greshko 25 Aug '20

25 Aug '20

Just a comment. I was a bit surprised today when dnfdragora and dnfdragora-updater were updated and the icon has been changed. I'm sure I'll get used to it, but I wish a color other than red was chosen. I'm predisposed to think that red is an indication that something is amiss or needs attention. -- The key to getting good answers is to ask good questions.

1 0

"Software updates" Plasma notifications not hiding
by Iñaki Ucar 21 Aug '20

21 Aug '20

Hi, It turns out that "Software updates" notifications are the only ones that do not hide after 5 seconds in my system, and it's quite annoying. Does anyone else have this problem? Any idea on how to fix this? Thanks, -- Iñaki Úcar

4 6

A question about konsole.
by George R Goffe 18 Aug '20

18 Aug '20

Hi, I'm having a little trouble with konsole and filename completion and am looking for information on how konsole shows alarms. Specifically, when attempting to use filename completion on a file that doesn't exist. I'm not seeing any flashing or hearing any bells (audio system is broken). Any help/hints/tips/suggestions would be greatly appreciated. Thanks in advance. Best regards, George...

1 0

Authorization supplicant timed out errors
by S Bob 18 Aug '20

18 Aug '20

All; I am having my wifi connection reset throughout the day. I get a popup message that says : *Wireless interface (wlp82s0)* *Authorization supplicant timed out* This happens every 2 - 4 hours, it's new but I'm not sure I can point to a specific update Thanks in advance

1 0

Libreoffice cannot export PDF documents
by Klaus Kolle 18 Aug '20

18 Aug '20

Hi list, At some point over the summer my LibreOffice has stopped being able to export to PDF. I get at document, but with no text like the attached, which is a text document with a table. I tried to downgrade to the previous version but with no luck. What could be the reason for this behaviour? |< PS: Running Fedora 32 KDE spin. PPS: Another laptop can export OK as seen last week. -- Med venlig hilsen Klaus Kolle Teknikumingeniør, B.Sc.EE., e-mail : klaus(a)kolle.dk Master of IT www : www.kolle.dk Asger Jorns Vej 17 Telephone : +4522216044 DK-8600 Silkeborg, Denmark "Man skal ikke tilskrive til sammensværgelser hvad der tilstrækkeligt kan forklares af inkompetence" Poul Henning Kamp Planlægning er tanker om noget man agter at gøre en gang i fremtiden, hvis omstændighederne tillader det. Klaus Kolle 2006 Perfection is achieved not when nothing more to add, but when there is nothing more left to take away. Antoine de Saint-Exupery

5 25

laptop semi-freezing frequently
by S Bob 11 Aug '20

11 Aug '20

All; I'm running Fedora 31 KDE spin on a Thinkpad P73 Every few days the system seems to sort of lock up, I can still move the mouse and open apps but I move the mouse and waith 30seconds for it to move, type a command and wait 15seconds for it to show up, etc Last time this happened I managed to open a konsole window and run top, and then I took a picture of it with my phone, you can see it here: http://50.243.150.89:8001/owncloud/index.php/s/1KYrzWz37DcO6Mz Usually my only option at this point is to power off Can someone help me debug this? Thanks in advance

3 3

Re: Proposal to Add: Log In/Out Blocker Criteria
by Kamil Paral 10 Aug '20

10 Aug '20

On Tue, Aug 4, 2020 at 8:50 AM Geoffrey Marr <gmarr(a)redhat.com> wrote: > At today's blocker review meeting[0], we ran across a bug[1] that we > believe is bad enough to warrant blocker status, but as the criteria > currently stand, does not violate any particular criterion. The bug in > question has to do with logging out of one user account and logging into > another account that has already been accessed before during that boot. The > criterion listed in the bug[2] doesn't seem to fit, as it is more focused > on what happens after the system is booted (which does work in the case of > this bug). There is a Final criterion[3] that covers switching between two > accounts, where the data in the account switched out of is retained, but > that is not the case presented here (as this bug has to do with "logging > in/out" of accounts, not "switching" as they are defined technically). > Intellectually, we believe this type of bug should violate the criteria, as > it seems a common use-case, and so we are bringing it up as a possible > addition as there is nothing that currently covers this kind of bug. > > The new criterion could look something like "A system with multiple user > accounts must be able to log in and out of said accounts as presented by > all release-blocking desktops in their default configuration." > Actually, I'd make this even simpler. We already have a Beta criterion related to logging out (among others): https://fedoraproject.org/wiki/Fedora_33_Beta_Release_Criteria#Shutdown.2C_… So let's just include logging in as well, and we're done: "Shutting down, rebooting, logging in and logging out must work using standard console commands and the mechanisms offered (if any) by all release-blocking desktops." We'd also update the "Work?" footnote: "Similar to the Basic criterion for shutting down, shutdown and reboot mechanisms must take storage volumes down cleanly and correctly request a shutdown or reboot from the system firmware. Logging in must transfer the user from the login screen/prompt to his/her working environment, and logging out must return the user to the environment from which they logged in, working as expected." This sufficiently covers the discussed bug and seems to fit naturally into the existing criterion. One unclear area might be what the console console used for logging in is. We can either explicitly say that for logging in we don't require any specific console command, or we can note that the most likely command to get covered by this is "su". We can also not define it and leave that up to blocker discussion, if such a situation occurs in the future. I'd lean towards the last option, but all sound fine to me. Thoughts?

3 2

Re: Proposal to Add: Log In/Out Blocker Criteria
by Adam Williamson 05 Aug '20

05 Aug '20

On Tue, 2020-08-04 at 00:49 -0600, Geoffrey Marr wrote: > At today's blocker review meeting[0], we ran across a bug[1] that we > believe is bad enough to warrant blocker status, but as the criteria > currently stand, does not violate any particular criterion. The bug in > question has to do with logging out of one user account and logging into > another account that has already been accessed before during that boot. The > criterion listed in the bug[2] doesn't seem to fit, as it is more focused > on what happens after the system is booted (which does work in the case of > this bug). There is a Final criterion[3] that covers switching between two > accounts, where the data in the account switched out of is retained, but > that is not the case presented here (as this bug has to do with "logging > in/out" of accounts, not "switching" as they are defined technically). > Intellectually, we believe this type of bug should violate the criteria, as > it seems a common use-case, and so we are bringing it up as a possible > addition as there is nothing that currently covers this kind of bug. > > The new criterion could look something like "A system with multiple user > accounts must be able to log in and out of said accounts as presented by > all release-blocking desktops in their default configuration." > > We would appreciate feedback on this idea and the wording of the criterion. > Should this be a beta or a final blocker? If nothing is heard in a > reasonable amount of time (before next week's blocker review meeting), we > will assume there is no issue with the proposal and add it to the criteria > at that time. There's a sort of technical argument to be made that this is covered by https://fedoraproject.org/wiki/Fedora_33_Beta_Release_Criteria#desktop-shut… . That says "Shutting down, logging out and rebooting must work using standard console commands and the mechanisms offered (if any) by all release-blocking desktops", with a footnote "Logging out must return the user to the environment from which they logged in, working as expected." Arguably the environment from which they logged in is not "working as expected" if you can't then log in as someone else. Adding a more explicit requirement wouldn't hurt, though, I guess. I sort of feel like it would be nice to somehow combine and rationalize all these related requirements somehow... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

2 1

Font size for Gajim
by S Bob 04 Aug '20

04 Aug '20

Hi all; I'm running Gajim on KDE, Fedora 31. Anyone know how to modify the font size for Gajim's chat and group chat text? Thanks in advance

1 0

Crashes
by Steve Grubb 04 Aug '20

04 Aug '20

Hello, I was curious about something. KDE has its own crash handling system. How does this community track any metrics around code stability if upstream gets reports? Kontact has segfaulted 20 times on me today. Each time it says it cannot generate a bug report. Abrtd does not seem to pick up anything. Shouldn't it? How does this community track when a recent update suddenly starts making things crash? Kontact was fine 3 weeks ago. I updated today (3 weeks of patches) and its crashing all the time to the point its unusable. It won't generate a bug report, abrtd seems not to notice either. -Steve

1 1

cgit.kde.org seems to have been switched off
by Tim Landscheidt 01 Aug '20

01 Aug '20

Hi, I was looking (randomly) at the description of F31's kwrited ("KDE Write Daemon") and wanted to find out more about what a "KDE Write Daemon" is, so I followed the link listed as URL (https://cgit.kde.org/kwrited.git) That server (cgit.kde.org) was down. On https://community.kde.org/Sysadmin/GitKdeOrgManual#Overview_of_facilities, cgit was listed as an active facility with multiple men- tions, but further googling led to https://www.reddit.com/r/kde/comments/h0ea9h/is_httpscgitkdeorg_down/ and https://about.gitlab.com/blog/2020/06/29/welcome-kde/. So cgit seems to have been switched off for good and "re- placed" by invent.kde.org. There is a large number of references to cgit.kde.org in spec files and the invent.kde.org URLs are more "complicat- ed": | [tim@passepartout ~]$ fgrep cgit.kde.org .cache/rpm-specs/*.spec | wc -l | 299 | [tim@passepartout ~]$ fgrep invent.kde.org .cache/rpm-specs/*.spec | .cache/rpm-specs/ikona.spec:URL: https://invent.kde.org/KDE/%{name} | .cache/rpm-specs/kio-fuse.spec:URL: https://invent.kde.org/system/kio-fuse | .cache/rpm-specs/kuserfeedback.spec:URL: https://invent.kde.org/libraries/%{name} | .cache/rpm-specs/latte-dock.spec:URL: https://invent.kde.org/plasma/%{name} | .cache/rpm-specs/latte-dock.spec:Source0: https://invent.kde.org/plasma/%{name}/-/archive/v%{version}/latte-dock-v%{v… | .cache/rpm-specs/plasma-wayland-protocols.spec:URL: https://invent.kde.org/libraries/%{name}.git | [tim@passepartout ~]$ So maybe a mapping can be obtained from KDE and the URLs up- dated en masse. Tim

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

kde August 2020