kde February 2022

kde@lists.fedoraproject.org

7 participants
11 discussions

time to orphan/retire unmaintained uncommon kde4 language bindings?
by Rex Dieter 07 May '25

07 May '25

Looking over some broken deps reports, I came across some old packages: kdebindings smokeqt smokekde qyoto (csharp/mono) kimono (csharp/mono) ruby-qt ruby-korundum perl-Qt Of these, the only one that's not a pure leaf package is perl-Qt (debconf- kde depends on it). any comment or objection to considering orphaning most (all minus smokeqt/perl-Qt) or all of these ? -- Rex

4 3

Logitech mouse
by Emmett Culley 08 Apr '22

08 Apr '22

I have a logitech mouse that has been working well for a long time. Except that every once in a while it suddenly won't scroll one line at a time and instead requires multiple turns of the wheel to move a page. I've been putting up with this as I am able to fix it by running solaar and toggling scroll wheel resolution off then on again. Only a couple of mouse clicks. Now it seems to have gotten worse, or I am finally tired of having to stop my workflow to fix it. It seems to be related to the mouse going to sleep during inactivity, though it is random enough so I cannot be sure. I am on the latest fedora 34 code, and I have been seeing issue since before 32. Any ideas where to look for a solution? Emmett

5 11

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

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

27 Feb '22

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

Khelpcenter for non-KDE apps
by Patrick O'Callaghan 25 Feb '22

25 Feb '22

I've had some recent trouble using Evolution (Gnome) under KDE/Plasma. The issue is that Evolution would give me a KDE error when trying to open its Help docs. I tried reporting this the KDE BZ but was rebuffed, then took it up on the Evolution BZ. You can see the discussion here: https://bugzilla.redhat.com/show_bug.cgi?id=2057454 Although the immediate problem is solved by using a gio setting (Gnome again), Milan Crha, the main Evolution maintainer, has some suggestions as to why this happened and what can be done about it in general. It might be worth someone's time to take a look from the KDE side and see what they think. I have no strong opinions either way, but this may not be an isolated case. poc

2 1

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

20 Feb '22

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

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

13 Feb '22

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

new release criterion proposal: Graphical package managers
by Kamil Paral 08 Feb '22

08 Feb '22

In blocker discussions during the F35 cycle, there were multiple arguments about what exactly is and is not the required functionality of a graphical package manager, and it was decided that we'd like to have an explicit criterion covering those apps in detail. You can find a proposal for this criterion below, and I'd like to hear your thoughts/concerns. This proposal was already discussed (and fine-tuned) on the test list, so you can read the existing discussion there [1] (and even an older one from November as well [2]). Please note that we already have package management partly covered in the Basic criteria [3] and Beta criteria [4]. Please read those first, including footnotes. The following new criterion is proposed against the Final milestone: ~~~~~~~~~~~~~~~~~~~~ The default graphical package manager for a given software type must appropriately: * Install, remove and update software * List locally-installed software coming from the official Fedora repositories * List available software (possibly in categories, a curated list, etc) * Display metadata relevant to the selected software (e.g. the description, screenshots, the size) * Start the selected installed software * Configure software sources by enabling/disabling pre-defined official repositories and then adjust the available software pool accordingly * Notify the user when system updates are available (taking into account the intended frequency of such notifications) The following must hold true: * When multiple operations (covered by this criterion) are requested, all of them must finish correctly. (It's also valid to inform the user that a certain operation is not available at that moment, see the "Supported functionality and design decisions" note). * The displayed state of software or software sources must not differ from their actual state. (E.g. an RPM package must not be shown as installed when it is not, a repository must not be shown as disabled or missing when it is enabled, etc). * Usual GUI interactivity must not break operations covered by this criterion. (E.g. when the GUI allows the user to click some buttons while an operation is running, it must not break that operation). * The package manager must never make the system enter an inconsistent or unbootable state. (E.g. damage the local software database, remove wrong system files, break the bootloader, etc). Note: Supported functionality and design decisions All requirements apply only if such a functionality is supported by the package manager; it does not imply that the package manager must support all this functionality. The requirements don't apply if some functionality is intentionally modified as a design decision (e.g. if some software sources can't be disabled as an intentional precaution to users breaking their system). If there is a bug violating the design decisions in one of the covered areas (e.g. a software source which is supposed to be always enabled can be disabled), it's up to the blocker review team to consider whether this bug makes the user experience or system safety considerably worse. Note: Systems in an inconsistent state While the package manager must not be the primary cause for breaking a system (unbootable, invalid internal structures, etc), it doesn't have to '''prevent''' these events from happening. So if there's e.g. a power outage during its operation or a package with harmful scriptlets is installed, which breaks the system, this is not the fault of the package manager and the criteria above are not considered violated. Similarly, when the package manager operates on an already broken system (e.g. with an inconsistent rpm database), the correct behavior cannot be guaranteed, and therefore the criteria also don't apply. Note: Refer to Basic footnotes The footnotes for the [similar Basic criterion covering console tools][3] regarding software types, 'appropriate' behavior, scope and so on are all generally applicable to this criterion also. ~~~~~~~~~~~~~~~~~~~~ Please tell me if this sounds reasonable to you. Thank you. [1] https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/… [2] https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/… [3] https://fedoraproject.org/wiki/Basic_Release_Criteria#software-install-remo… [4] https://fedoraproject.org/wiki/Fedora_35_Beta_Release_Criteria#Installing.2…

1 0

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

06 Feb '22

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

KDE critical path barely defined
by Adam Williamson 03 Feb '22

03 Feb '22

I noticed today that openQA KDE tests for F34 updates were failing. After a bit of investigation I found the bug had been filed and is in the process of being fixed: https://bugzilla.redhat.com/show_bug.cgi?id=2049560 However, ideally, the bug should never have made it to stable. If openQA tests had run on the initial update, they would have failed and gating would have prevented the update going stable. openQA didn't run on the broken update because the package - qt5- qtwayland - is not marked as critical path. We only run openQA tests on critical path updates at present due to capacity limitations. I've sent a PR to add qt5-qtwayland to the critpath definition: https://pagure.io/fedora-comps/pull-request/710 but in so doing I noticed the critical-path-kde group is almost empty. This means when other KDE components are updated, we're not running the openQA tests and so we won't catch if they break. It would be much better if someone could come up with a list of critical KDE packages and populate the group, so that we would properly test and gate updates with a decent chance of breaking KDE. Can someone help produce such a list? Thanks! -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

kde February 2022