kde December 2020

kde@lists.fedoraproject.org

19 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 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

Freezing Plasma in Fedora?
by Mikhail Ramendik 16 Jan '21

16 Jan '21

Hello, I had to leave Fedora a year ago because of breaking KDE Plasma updates mid-cycle (even on "current minus one" Fedora). I have since learned that this problem is unavoidable because of the Plasma release cycle, when the previous (non-LTS) release immediately stops being supported; this forces an update mid-cycle to a new Plasma and glitches can happen. I am looking at trying again, but can I somehow freeze all Plasma packages, while not disabling updates for all other stuff? I know what "dnf versionlock" is, but how do I create a correct list for it? The idea would be to freeze Plasma packages in advance of a Plasma version update and unfreeze a month after the new version goes into Fedora, watching for critical security issues in the meantime. -- Yours, Mikhail Ramendik Unless explicitly stated, all opinions in my mail are my own and do not reflect the views of any organization

3 8

KDE update/stability policy on Fedora
by Mikhail Ramendik 06 Jan '21

06 Jan '21

Hello, I would really like to understand the policy of the schedule of major KDE component version updates in Fedora. I know of the Plasma release schedule problem. But this is bigger apparently. The bug that forced me to leave Fedora a year ago was https://bugzilla.redhat.com/show_bug.cgi?id=1746465 . This bug was caused by a version update of KDE Frameworks, affected usability, and took over a month to fix. Following this list, I see that breaking updates to KDE are kind of a regular occurrence: https://lists.fedoraproject.org/archives/list/kde@lists.fedoraproject.org/t… I would guess that the component version updates mid-cycle cause the breaking updates. I would really appreciate some explanation of what the version update policy is. Also is there *any way at all* to have a reliable KDE environment on Fedora, apart from not updating the entire system? -- Yours, Mikhail Ramendik Unless explicitly stated, all opinions in my mail are my own and do not reflect the views of any organization

6 14

Re: F34 Change proposal: Wayland by Default for KDE Plasma Desktop (System-Wide Change)
by Adam Batkin 29 Dec '20

29 Dec '20

On Mon, Dec 28, 2020 at 5:55 AM Sérgio Basto <sergio(a)serjux.com> wrote: > > On Mon, 2020-09-14 at 00:46 +0200, Kevin Kofler wrote: > > Ben Cotton wrote: > > > https://fedoraproject.org/wiki/Changes/WaylandByDefaultForPlasma > > > > Can we revert this decision, seems almost all the people have the same > opinion ... that Plasma on Wayland is not ready for production. > IMHO, try run it in wayland should be a optin . > > We have been aware of the wayland induced issues for a couple of years. > The fedora kde/qt team are aware of the issues wayland causes and just > blame the apps. What's the best way to test KDE/Plasma on Wayland these days? I now have a few PCs that I'd like to test on, all of which are currently running F33. And ideally I can reliably see what life under Wayland would feel like in F34 without having to run Rawhide or something like that: * Dual-monitor desktop with NVidia and proprietary drivers having been upgraded through many Fedora releases over the years * Single-monitor desktop with AMD RX 5600 XT and all OSS drivers and is a fresh install * Laptop (Dell XPS 13 from ~4 years ago) with Intel video I'm then happy to compile a list of things that don't work (hopefully the list is empty), and we can throw that into a table on the a wiki somewhere with tracking bugs and workarounds (possibly such a page already exists?) which will both help evaluate whether Wayland-by-default will be a successful change, but also serve as a starting point for any additional work that may be needed to make Plasma-on-Wayland better. (I did try the default Fedora/Gnome for a couple weeks on the AMD-based system and gave up in frustration when a bunch of things didn't work, especially CopyQ, my Clipboard Manager which is a dealbreaker for me) Thanks, -Adam Batkin

2 1

Fwd: Re: F34 Change proposal: Wayland by Default for KDE Plasma Desktop (System-Wide Change)
by Sérgio Basto 28 Dec '20

28 Dec '20

the gnome-keyring and plasma-wayland problem ? -------- Forwarded Message -------- From: Vitaly Zaitsev via devel <devel(a)lists.fedoraproject.org> Reply-To: Development discussions related to Fedora < devel(a)lists.fedoraproject.org> To: devel(a)lists.fedoraproject.org Cc: Vitaly Zaitsev <vitaly(a)easycoding.org> Subject: Re: F34 Change proposal: Wayland by Default for KDE Plasma Desktop (System-Wide Change) Date: Mon, 28 Dec 2020 12:26:37 +0100 On 28.12.2020 11:54, Sérgio Basto wrote: > Also, I'm against add workarounds on desktop files like this one [1] > forcing apps running with QT_QPA_PLATFORM=xcb , because is just > hidden > the real problem. Instead of patching, Qt5 maintainers should drop this patch[1]. [1]: https://src.fedoraproject.org/rpms/qt5-qtbase/blob/master/f/qtbase-use-wayl… [2]: https://fedoraproject.org/wiki/Changes/Qt_Wayland_By_Default_On_Gnome [3]: https://bugreports.qt.io/browse/QTBUG-88293 -- Sincerely, Vitaly Zaitsev (vitaly(a)easycoding.org) _______________________________________________ devel mailing list -- devel(a)lists.fedoraproject.org To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Sérgio M. B.

2 1

[Fedocal] Reminder meeting : KDE SIG
by ngompa＠fedoraproject.org 27 Dec '20

27 Dec '20

Dear all, You are kindly invited to the meeting: KDE SIG on 2020-12-28 from 18:00:00 to 19:00:00 UTC 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://apps.fedoraproject.org/calendar/meeting/9875/

2 1

Request for help: dead keys with qt5
by José Abílio Matos 23 Dec '20

23 Dec '20

Hi, I am requesting help to fix an issue with dead keys with qt5. The history is simple there is a Fedora user who uses lyx that has problems with dead keys (they do not work at all). Jorge uses Mate but the problem also persists with gnome. In private exchanges Jorge confirmed that the problem occurs with other qt5 applications and thus it is not lyx specific. Also according to OP message the problem also occurs in other distributions. The SOLVED part of the message title is because the dead keys work if lyx is compiled with qt4 (that is also supported). We could provide both versions but it seems to much work for one single bug and in particular the qt5 port is better in other regards. At the same time after the next stable (due for some time :-) ) version is released the qt4 port will be removed. Does anyone has some advice on how to debug this issue? Best regards, -- José Abílio

3 9

gnome-keyring and plasma-wayland
by Mattia Verga 22 Dec '20

22 Dec '20

I'm a bit concerned about F34 Plasma default switching to Wayland. I've started trying plasma-wayland after the upgrade to F33 and I run into problems with apps which uses gnome-keyring to store credentials. From https://gitlab.gnome.org/GNOME/gnome-keyring/-/issues/19 it seems gnome-keyring is not working under plasma-wayland. I think this might be a blocker because it would cause a lot of pain to users... Mattia

2 1

[Fedocal] Reminder meeting : KDE SIG
by ngompa＠fedoraproject.org 13 Dec '20

13 Dec '20

Dear all, You are kindly invited to the meeting: KDE SIG on 2020-12-14 from 18:00:00 to 19:00:00 UTC 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://apps.fedoraproject.org/calendar/meeting/9837/

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

kde December 2020