kde March 2020

kde@lists.fedoraproject.org

15 participants
11 discussions

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

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

pkg review: pulseaudio-qt
by Rex Dieter 30 Mar '20

30 Mar '20

New pkg review help needed, https://bugzilla.redhat.com/show_bug.cgi?id=1818985 It's a new dependency for latest kde-connect release, can't update without it. -- Rex

2 1

FYI: Dolphin Bookmarks
by Colin J Thomson 27 Mar '20

27 Mar '20

Hi, I read in another thread saying Dolphin does not have bookmarks well actually it does now. I am having trouble getting a screenshot to post here so here is some info on userbase: https://userbase.kde.org/Dolphin/File_Management#Bookmarks_and_Places It was added to Dolphin around the middle of last year I think.. Colin -- Fedora 31 (Thirty One)

2 1

Konqueror does not start on the latest compose
by Lukas Ruzicka 26 Mar '20

26 Mar '20

Hello KDE folks, our application start stop test has revealed that Konqueror cannot be started from the menu by typing "konqueror" and hitting enter. Instead, an application to set "Locations" is started. Please let me know if - removing Konqueror is a purpose - or if this is a bug - if so, I will report it for you to be able to track it. Thanks a lot -- Lukáš Růžička FEDORA QE, RHCE Red Hat <https://www.redhat.com> Purkyňova 115 612 45 Brno - Královo Pole lruzicka(a)redhat.com TRIED AND PERSONALLY TESTED, ERGO TRUSTED. <https://redhat.com/trusted>

2 2

issues with kopete joining a group chat (room)
by S.Bob 25 Mar '20

25 Mar '20

All; I have a client that uses xmpp for chatting. They setup a group room for me to join but kopete crashes every time I try to join the group chat I'm running Fedora 31 KDE spin Here's my steps to reproduce start kopete click on the 'hidden icons' in the taskbar right click on kopete highlight my account id --> Join Groupchat change the Server (they use talk.company.com for chat and conference.company.com for the group rooms) click query and the room I want shows up then I double click the room or simply type the room name in the room field kopete immediately crashes and I see this in /var/log/messages: Mar 25 13:46:40 Fedora31Host kopete[13366]: kf5.kxmlgui: cannot find .rc file "historychatui.rc" for component "kopete" Mar 25 13:46:40 Fedora31Host plasmashell[1446]: QQuickItem::stackAfter: Cannot stack StatusNotifierItem_QMLTYPE_310(0x55e40a6d0d30, parent=0x55e402974420, geometry=0,0 0x0) after StatusNotifierItem_QMLTYPE_310(0x55e40a2d3270), which must be a sibling Mar 25 13:46:40 Fedora31Host plasmashell[1446]: QQuickItem::stackAfter: Cannot stack StatusNotifierItem_QMLTYPE_310(0x55e40710de30, parent=0x55e4052f4fd0, geometry=0,0 0x0) after StatusNotifierItem_QMLTYPE_310(0x55e40e35ca00), which must be a sibling Mar 25 13:46:40 Fedora31Host wpa_supplicant[1171]: wlo1: WPA: Group rekeying completed with f8:7b:8c:9f:3a:6b [GTK=TKIP] Mar 25 13:46:42 Fedora31Host kwin_x11[1440]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 4526, resource id: 174063623, major code: 15 (QueryTree), minor code: 0 Mar 25 13:46:42 Fedora31Host kwin_x11[1440]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 4531, resource id: 174063623, major code: 18 (ChangeProperty), minor code: 0 Mar 25 13:46:45 Fedora31Host kwin_x11[1440]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 8092, resource id: 35652928, major code: 20 (GetProperty), minor code: 0 Mar 25 13:46:45 Fedora31Host kwin_x11[1440]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 8093, resource id: 35652928, major code: 15 (QueryTree), minor code: 0 Thanks in advance

1 0

Call for testing: 4K displays and/or resolution scaling on X11 (especially AMD adapters)
by Adam Williamson 23 Mar '20

23 Mar '20

Hi folks! We have a proposed F32 blocker bug: https://bugzilla.redhat.com/show_bug.cgi?id=1809717 which reports issues with 4K displays when using X11 (not Wayland). Initial indications suggest this may be specific to AMD graphics adapters: the reporter has an AMD adapter, and a couple of our team in Brno have been able to reproduce issues on an AMD adapter but not an Intel adapter. It's also suggested that the issue might actually be in display scaling (which is used on small high-resolution displays by default, hence the association with 4K, but can be enabled on any display for testing). So, to help us figure out the shape of this bug, can we ask folks to test on whatever hardware you have available? The actual bug is that only 1/2 or 1/4 of the display is lit up, the rest of it is black, like in this image: https://bugzilla.redhat.com/attachment.cgi?id=1667282 1. Run a GNOME-on-Wayland session, and see if the bug happens: 1. a) out-of-the-box 1. b) with display scaling manually enabled if it was not auto-enabled (go to 'Displays' and change the 'Scale' setting to 200% if it is at 100% by default; you may have to log out and back in after changing the setting, not sure) 2. Run a GNOME-on-X11 session, and see if the bug happens: 2. a) out-of-the-box 2. b) with display scaling manually enabled if it was not auto-enabled (go to 'Displays' and change the 'Scale' setting to 200% if it is at 100% by default; you may have to log out and back in after changing the setting, not sure) 3. Run a KDE-on-X11 session, and see if the bug happens: 3. a) out-of-the-box 3. b) with display scaling manually enabled if it was not auto- enabled (go to 'Display Configuration' and change 'Global scale' to 200% , then log out and back in) Please report back your results with info on the graphics card and display used for testing. If you do hit the bug, you can also add a comment to the bug report noting which configuration(s) produced the bug and including the same info on the graphics card and display used. Thanks very much! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

2 3

KDE Touchpad System Settings Disabled, Possible regressions in Xorg support
by pv.bugzilla+fedora＠gmail.com 23 Mar '20

23 Mar '20

System: Fedora 30 KDE and Xorg. [Wayland-GNOME is unstable; was crashing soon after boot on trivial activities; these crashes were duly reported.] Some of the radio buttons on tabs 1,2,5 work, but everything else is greyed out. I have a vague memory that there was more functionality when F30 KDE first installed. I believe I installed this from a F30 KDE spin; dnf history userinstalled does not list any kde or KDE packages. Any ideas? A google search suggests the possibility that Wayland support may have caused regressions in the Xorg support. I just now tried dnf install xorg-x11-drv-synaptics-legacy closed and reopened the settings and nothing changed. Do I need to do other steps? Do I need to explicitly disable certain Wayland support components to allow Xorg to work better? Thank you.

1 0

Re: proposal: Default application functionality criterion reduction
by Kamil Paral 12 Mar '20

12 Mar '20

On Mon, Feb 17, 2020 at 3:20 PM Kamil Paral <kparal(a)redhat.com> wrote: > 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 > > > I haven't received much feedback on this proposal. On test list and kde list, there was a short follow-up regarding the list of release-blocking applications. On kde list, Kevin disagreed because it lowers the guaranteed quality bar for KDE, but he didn't continue discussing it with me. I haven't received any alternative proposals either. On desktop list, there was silence, but Chris Murphy gave me a thumbs up on IRC. I'll give it a few more days, and unless somebody yells hard (and ideally also provides some constructive ways how to optimize desktop testing, because we need to cut it down /somehow/), I'll put the change into effect. I'll also probably move the help viewer into the list of release-blocking applications, based on the discussion I saw. Thanks, Kamil Fedora QA

2 4

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

kde March 2020