kde February 2020

kde@lists.fedoraproject.org

30 participants
19 discussions

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

30 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

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

Revamping the Release Readiness meeting
by Ben Cotton 05 Mar '20

05 Mar '20

(Posting to many mailing lists for visibility. I apologize if you see this more times than you'd like.) You may have already seen my Community Blog post[1] about changing the Release Readiness meeting process. The meeting has questionable value in the current state, so I want to make it more useful. We'll do this by having teams self-report readiness issues on a dedicated wiki page[2] beginning now. This gives the community time to chip in and help with areas that need help without waiting until days before the release. I invite teams to identify a representative to keep the wiki page up to date. Update it as your status changes and I'll post help requests in my weekly CommBlog posts[3] and the FPgM office hours[4] IRC meeting. The Release Readiness meeting will be shortened to one hour and will review open concerns instead of polling for teams that may or may not be there. We will use the logistics mailing list[5] to discuss issues and make announcements, so I encourage representatives to join this list. [1] https://communityblog.fedoraproject.org/fedora-program-update-2020-08/ [2] https://fedoraproject.org/wiki/Release_Readiness [3] https://communityblog.fedoraproject.org/category/program-management/ [4] https://apps.fedoraproject.org/calendar/council/#m9570 -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

3 3

Dolphin autostarting
by Patrick O'Callaghan 03 Mar '20

03 Mar '20

A thread on the Fedora Users list (see: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org…) mentioned an instance of Dolphin being started without the user configuring it as an Autostart item. I do use Autostart to fire up several Dolphin windows at login, but lately I've been noticing an extra one that I haven't asked for. A little research shows it apparently being started by systemd. Anyone know what's going on? poc

9 34

Support for Q4Wine, compiler issues related to Qt
by Kevin Degeling 27 Feb '20

27 Feb '20

Hey everyone, Q4Wine is a KDE based application, to manage wine prefixes (bottles) and to make easy use of tools that wine offers. It's being developer outside of Fedora, but in the past it was well maintained and it saw regular updates. Sadly, the maintainer has been unable to contribute further, causing Q4Wine to miss some updates. As of writing, builds fails on Koji because of a QtCore related issue. Since my knowledge of these technologies is limited, I figured it would be best to turn to those who are most experienced with Qt. I hope this is not the wrong place to ask. If it were possible for any of you to take a look at this precious program, then that would be much appreciated. Kevin "Eonfge" Degeling Related links: https://q4wine.brezblock.org.ua/ https://src.fedoraproject.org/rpms/q4wine https://github.com/brezerk/q4wine

1 0

knotes, kaddressbook, korganizer
by Walter Cazzola 27 Feb '20

27 Feb '20

Dear Fedora Experts, I've just completed the migration of my Linux box from Fedora 23 to 31 but I still have some problems in "importing" my old korganizer, knotes and kaddressbook data. I usually use the akonadi to import all of them through the akonadi applet I was used to find in my system tray (aknoaditray, I suppose) but it seems that it is not there anymore. At least in my fresh installed Fedora 31. Do I missed to install something or something has changed with the newest version? Currently what it is installed about akonadi is:  rpm -qa | grep -i akonadi kf5-akonadi-server-mysql-19.04.3-4.fc31.x86_64 kf5-pimcommon-akonadi-19.04.3-2.fc31.x86_64 kf5-akonadi-server-19.04.3-4.fc31.x86_64 akonadi-1.13.0-114.fc31.x86_64 kf5-akonadi-search-19.04.3-2.fc31.x86_64 kf5-mailimporter-akonadi-19.04.3-2.fc31.x86_64 akonadi-import-wizard-19.04.3-2.fc31.x86_64 kf5-akonadi-contacts-19.04.3-2.fc31.x86_64 kf5-akonadi-calendar-19.04.3-2.fc31.x86_64 kf5-akonadi-notes-19.04.3-2.fc31.x86_64 kf5-libkdepim-akonadi-19.04.3-2.fc31.x86_64 kdepimlibs-akonadi-4.14.10-34.fc31.x86_64 kf5-kmailtransport-akonadi-19.04.3-2.fc31.x86_64 kf5-akonadi-mime-19.04.3-2.fc31.x86_64 Any idea? Walter --

2 3

proposal: Default application functionality criterion reduction
by Kamil Paral 24 Feb '20

24 Feb '20

Yesterday I sent out a QA-related proposal that directly affects the release criteria for KDE x86_64 and Workstation x86_64 and (probably) aarch64 images. The proposal is attached below and also available in the test list (including some follow-ups which are recommended to read): https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/… Can you please review that proposal and post your thoughts, if you have any? (Responding to test list is preferred, so that we can discuss it in a single place, but responding here is fine as well). Thank you. ---------- Forwarded message --------- From: Kamil Paral <kparal(a)redhat.com> Date: Mon, Feb 17, 2020 at 3:20 PM Subject: proposal: Default application functionality criterion reduction To: test <test(a)lists.fedoraproject.org> This proposal intends to reduce the scope of the “*Default application functionality*” release criterion [0]: All applications that can be launched using the standard graphical > mechanism of a release-blocking desktop after a default installation of > that desktop must start successfully and withstand a basic functionality > test. > *= Background =* The area which QA is responsible for has been growing and growing in recent years. We used to have just a single Fedora release with two blocking desktops (GNOME and KDE). Then Editions got introduced and we started testing Workstation, Server, Cloud and the KDE Spin. Additional architectures were introduced (fortunately i386 got obsolete) and we started testing and blocking on specific images on armhfp and aarch64. Currently there are 13 release blocking deliverables mentioned on the ReleaseBlocking page [1]. That list is not complete, though. Fedora CoreOS became an official edition lately, and even though its release cycle is not tied to traditional Fedora release cycle (and that’s why it’s not mentioned on that wiki page), as an official edition QA should care about it as well. It is the same story with Fedora IoT, another recent release-blocking addition [2]. Desktop testing is one of the most time-consuming jobs with the most frequent bug occurrence. Right now, we’re supposed to be fully testing and blocking on GNOME, KDE and XFCE (although XFCE might get dropped in favor or aarch64 Workstation [3]). We cannot test all of this and honestly claim that we verified basic functionality of all the included apps on all these desktops. I believe we need to adjust the criterion and align it closer with reality. In my eyes, it’s better to have a narrower scope and perform it well than having a large scope and perform it poorly. *= Proposal =* Change the criterion to something along these lines: All applications that can be launched using the standard graphical > mechanism after a default installation of Fedora Workstation on x86_64 > architecture must start successfully and withstand a basic functionality > test. > > For other release-blocking desktops (on any architecture), the > requirements only apply to the following types of applications: > > * web browser (e.g. firefox) [4] > > * file browser (e.g. nautilus) > > * package manager (e.g. gnome-software) > > * image viewer (e.g. eog) > > * document viewer (e.g. evince) > > * text editor (e.g. gedit) > > * archive manager (e.g. file-roller) > > * terminal emulator (e.g. gnome-terminal) [4] > > * problem reporter (e.g. abrt) > > If there are multiple applications of the same type (e.g. several web > browsers), only one of them needs to satisfy the requirements. > As you can see, the original criterion was kept for Fedora’s flagship desktop edition, the one that is most prominent on https://getfedora.org and probably the one that most newcomers download. We would still verify everything on Fedora Workstation on x86_64. But any other desktop (including Workstation on aarch64) would get just reduced criteria, because we simply can’t ensure the same quality bar for the smaller desktop editions/spins. There are some high-profile types of applications that I considered including in the list above, but didn’t in the end: * word editor (e.g. libreoffice-writer) * spreadsheet editor (e.g. libreoffice-calc) * video player (e.g. totem) * help viewer (e.g. yelp) I’d like to hear your thoughts on whether they should be included or not. Of course from an end-user point of view, it would be beneficial. But the question is whether we as QA can promise their testing. And also whether we want to block the release e.g. if Gnumeric is broken on armhfp XFCE or if totem doesn’t work on aarch64. Yes, it’s unpleasant, but people using alternative desktops and architectures are usually far from beginners. It’s usually not difficult to install a different application. Also note that the apps included in x86_64 Workstation will be thoroughly tested so they should be very likely to work well even on other architectures (minus some arch-specific issues). I’d like to target Fedora 32 with this proposal, which means we should decide on this proposal fast. (I wanted to propose it much sooner, but I was waiting on clarifications about new release-blocking images and also on some fesco tickets [3], some of which is still not clarified; so I’m sorry about a late proposal). Please comment, thanks. [0] https://fedoraproject.org/wiki/Fedora_32_Final_Release_Criteria#Default_app… [1] https://fedoraproject.org/wiki/Releases/32/ReleaseBlocking [2] https://pagure.io/fedora-iot/issue/23 [3] https://pagure.io/fesco/issue/2339 [4] These two are required to work even in Basic release criteria [5], but I decided to include them anyway to avoid confusion (“why is the web browser missing?”), and to make it clear that they need to satisfy the basic functionality (whereas for Basic release criteria just the barebone functionality might be deemed enough) [5] https://fedoraproject.org/wiki/Basic_Release_Criteria#Required_applications

6 8

Energy Saving and 5.5.5-200 kernel
by Ed Greshko 23 Feb '20

23 Feb '20

An issue seems to have cropped up with the recent update to kernel 5.5.5-200. I have the setting for Screen Energy Saving, Switch off after 4 min. The switch off occurs just fine. However when I move the mouse the screen does come to life but there is no cursor and things appear frozen. After a few more seconds the screen blinks off/on and everything is OK. Anyone else seeing this? -- The key to getting good answers is to ask good questions.

2 3

Konsole - full border?
by S.Bob 21 Feb '20

21 Feb '20

Hi All; I would like a full border around my Konsole windows, as opposed to the latest look. I have not found an option to do this, anyone know how to do this? Thanks in advance

2 1

Logging out and in again creates an every-increasing number of sessions
by Patrick O'Callaghan 13 Feb '20

13 Feb '20

As part of an ongoing thread on the Evolution list: https://mail.gnome.org/archives/evolution-list/2020-February/msg00041.html it turns out that logging into KDE creates a new session (in the sense of loginctl(1)) but logging out doesn't terminate it. Thus every time you log out and in again the number of sessions increases. You can verify this by running 'loginctl --list-sessions'. Is this a bug? poc

4 13

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

kde February 2020