kde June 2021

kde@lists.fedoraproject.org

20 participants
27 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

Problems after upgrade to Fedora-34
by Jonathan Ryshpan 01 Jul '21

01 Jul '21

A recent upgrade from Fedora-33 to Fedora-34 has introduced these problems: * Dragging a window icon in the pager from one desktop to another no longer moves the related window from that desktop to the other. (Or possibly there is some option that needs to be set?) * The new system to select which desktop to move a window between desktops to is not a good one. To move a window one has to select Top-Decoration->Desktops and tick the (additional) desktop that the window should be on, then do this again to untick the current desktop. * If Firefox is quitted and then restarted, it no longer restores its windows to the desktops that they were on before it was quitted. * Discover no longer gives much info about packages being upgraded. For my current upgrade it simply reports "System Upgrade / 62 packages to upgrade". This is not useful in getting info about unfamiliar packages or finding out whether a reboot is desirable. * Some .jpg files are not previewed on the Desktop. I have no idea about why some are previewed and others are not. Platform: Fedora-34 KDE Plasma: 5.22.2 KDE Framework: 5.83.0 Graphics: Wayland -- Sincerely Jonathan Ryshpan <jonrysh(a)pacbell.net> A train station is where the train stops. A bus station is where the bus stops. On my desk is a workstation......

3 7

Fedora website - revamp
by Pawel Zelawski 28 Jun '21

28 Jun '21

Dear team, we decided it's time to rethink our needs and redesign Fedora main website from scratch. I would like to encourage your team to take a part in this initiative and work on this together as we need to make sure that we have everybody on board and all needs are taken into consideration. Based on initial input I gather from Fedora forum and meeting with Matthew I prepared one page with summary of what we are going to do and it's available here https://fedoraproject.org/wiki/Websites/Fedora_Website_Revamp It's possible I'll move it to other place in the future but for now it will be our workspace. As a short term strategy I would like you to choose one representative from your team for upcoming kick-off meeting with other stakeholders and send me directly details like name, Feroda ID and e-mail address. It will be much easier for me to contact chosen person having this. Please try to do this by 30th June. I'm aware holiday period started and probably not everyone will be available but let's try to do our best and push forward this exciting initiative :) When I have all participants gathered I'll try to find common slot to organize session for us. Agenda will be included in invitation. Main goal of this kick-off will be to discuss known facts, go through goals, assumptions and requirements and also plan next steps for next couple of weeks. I'll propose long term strategy, approach and wider plan after meeting with all of you. Please read in advance https://fedoraproject.org/wiki/Websites/Fedora_Website_Revamp and if you already have some requests, suggestion please send it to your representative and then each person can send it to me before kick-off. Taking into consideration we will have huge amount of stakeholders I don't see other way to work on this than having one person from each team, I hope you understand. Looking forward to work with all of you. Stay safe! -- Pawel Zelawski

2 2

Warning on kontact/kmail
by José Abílio Matos 28 Jun '21

28 Jun '21

Hi, when using kontact/kmail, since yesterday I get a warning titled "List of languages": An error occurred attempting to load the list of available languages: Error transferring https://languagetool.org/api/v2/languages - server replied: Forbidden Does anyone else see this? Best regards, PS: naturally that I had this problem when writing this message so I would expect this message to be considered a MWE (minimal working example). :-D -- José Abílio

2 2

Native KDE app mouse select is off by 1 line and 1 char under Wayland
by Barry Scott 27 Jun '21

27 Jun '21

I'm running F34 in a VMWare VM. With F34 KDE Konsole and Kwrite mouse selection is off by a line and a char. It select 1 line above and back 1 character. This does not happen under X11. Anyone else seeing this? I have some PyQt5 apps that do not show this problem. Barry

1 0

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

27 Jun '21

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

Re: [EPEL-devel] Re: help request: libksysguard build failure on Stream 8
by Troy Dawson 25 Jun '21

25 Jun '21

On Thu, Jun 24, 2021 at 8:31 PM Yaakov Selkowitz <yselkowi(a)redhat.com> wrote: > On Thu, 2021-06-24 at 15:40 -0700, Troy Dawson wrote: > > On Wed, Jun 23, 2021 at 9:25 AM Yaakov Selkowitz <yselkowi(a)redhat.com> > > wrote: > > > > > On Wed, 2021-06-23 at 08:56 -0700, Troy Dawson wrote: > > > > I'm updating/ rebuilding KDE Plasma Desktop on CentOS Stream 8, for > the > > > > updated qt5 that is there. I am using what is in F34 for the update. > > > > I've got all the qt5 5.15.2 and kf5 5.83.0 packages built and in the > > > > buildroot. > > > > For libksysguard I believe I have all other dependencies built and > in the > > > > buildroot. > > > > But it just keeps failing, despite everything I've tried.[1][2] > > > > I get the same error on all arches. The same error on version > 5.22.1, > > > > 5.22.2 and even 5.21.4. > > > > I've tried passing build parameters that I thought went along with > the > > > > error, but nothing changed. > > > > > > > > I think this is the critical error, but it's possible I'm wrong > > > > > > > > CMakeFiles/processcore.dir/cgroup_data_model.cpp.o: In function > > > > `KSysGuard::CGroupDataModel::update(KSysGuard::CGroup*) [clone > > > > .localalias.209]': > > > > /usr/include/c++/8/bits/fs_path.h:185: undefined reference to > > > > `std::filesystem::__cxx11::path::_M_split_cmpts()' > > > > CMakeFiles/processcore.dir/cgroup_data_model.cpp.o: In function > > > > `KSysGuard::CGroupDataModel::update(KSysGuard::CGroup*) [clone > > > > .localalias.209]': > > > > /usr/include/c++/8/bits/fs_dir.h:371: undefined reference to > > > > > > > > `std::filesystem::__cxx11::directory_iterator::directory_iterator(std::files > > > ys > > > > tem::__cxx11::path > > > > const&, std::filesystem::directory_options, std::error_code*)' > > > > CMakeFiles/processcore.dir/cgroup_data_model.cpp.o: In function > > > > `KSysGuard::CGroupDataModel::update(KSysGuard::CGroup*)': > > > > /builddir/build/BUILD/libksysguard- > > > > 5.22.2.1/processcore/cgroup_data_model.cpp:447: > > > > undefined reference to > > > > `std::filesystem::__cxx11::directory_iterator::operator*() const' > > > > /builddir/build/BUILD/libksysguard- > > > > 5.22.2.1/processcore/cgroup_data_model.cpp:447: > > > > undefined reference to > > > > `std::filesystem::__cxx11::directory_iterator::operator++()' > > > > CMakeFiles/processcore.dir/cgroup_data_model.cpp.o: In function > > > > `KSysGuard::CGroupDataModel::update(KSysGuard::CGroup*) [clone > > > > .localalias.209]': > > > > /usr/include/c++/8/bits/fs_dir.h:260: undefined reference to > > > > `std::filesystem::status(std::filesystem::__cxx11::path const&)' > > > > collect2: error: ld returned 1 exit status > > > > > > std::filesystem was originally added as an experimental extension to > C++, > > > and > > > at first required explicitly linking with -lstdc++fs. GCC 9 removed > the > > > requirement for the additional link library [1], but RHEL 8's default > > > compiler > > > is GCC 8. Therefore, for EPEL 8, you would have to create a patch > which > > > adds > > > stdc++fs to the target_link_libraries of the processcore target. > > > > > > [1] https://gcc.gnu.org/gcc-9/changes.html > > > > > > HTH, > > > > > > > My cmake skills are not up to snuff. A little more help is needed. > > I seems -lstdc++fs needs to be added at the end of the compile command > > /usr/bin/c++ <options and other stuff> -lstdc++fs > > instead of at the beginning or middle of the options > > /usr/bin/c++ -lstdc++fs <options and other stuff> > > > > I can do that manually, and it compiles correctly. > > > > But getting cmake to do it, I'm clearly missing something. > > Is there a cmake command line option to put -lstdc++fs at the end? > > There are several cmake and cmake.in files. Would I put it in one, and > if > > so, what is the syntax? > > Add stdc++fs to the end of this list: > > > https://github.com/KDE/libksysguard/blob/master/processcore/CMakeLists.txt#… > That did it. Thank you very much. Not only am I unblocked, but my cmake skills are a little bit better. Troy

1 0

Re: [EPEL-devel] Re: help request: libksysguard build failure on Stream 8
by Troy Dawson 24 Jun '21

24 Jun '21

On Wed, Jun 23, 2021 at 9:25 AM Yaakov Selkowitz <yselkowi(a)redhat.com> wrote: > On Wed, 2021-06-23 at 08:56 -0700, Troy Dawson wrote: > > I'm updating/ rebuilding KDE Plasma Desktop on CentOS Stream 8, for the > > updated qt5 that is there. I am using what is in F34 for the update. > > I've got all the qt5 5.15.2 and kf5 5.83.0 packages built and in the > > buildroot. > > For libksysguard I believe I have all other dependencies built and in the > > buildroot. > > But it just keeps failing, despite everything I've tried.[1][2] > > I get the same error on all arches. The same error on version 5.22.1, > > 5.22.2 and even 5.21.4. > > I've tried passing build parameters that I thought went along with the > > error, but nothing changed. > > > > I think this is the critical error, but it's possible I'm wrong > > > > CMakeFiles/processcore.dir/cgroup_data_model.cpp.o: In function > > `KSysGuard::CGroupDataModel::update(KSysGuard::CGroup*) [clone > > .localalias.209]': > > /usr/include/c++/8/bits/fs_path.h:185: undefined reference to > > `std::filesystem::__cxx11::path::_M_split_cmpts()' > > CMakeFiles/processcore.dir/cgroup_data_model.cpp.o: In function > > `KSysGuard::CGroupDataModel::update(KSysGuard::CGroup*) [clone > > .localalias.209]': > > /usr/include/c++/8/bits/fs_dir.h:371: undefined reference to > > > `std::filesystem::__cxx11::directory_iterator::directory_iterator(std::filesys > > tem::__cxx11::path > > const&, std::filesystem::directory_options, std::error_code*)' > > CMakeFiles/processcore.dir/cgroup_data_model.cpp.o: In function > > `KSysGuard::CGroupDataModel::update(KSysGuard::CGroup*)': > > /builddir/build/BUILD/libksysguard- > > 5.22.2.1/processcore/cgroup_data_model.cpp:447: > > undefined reference to > > `std::filesystem::__cxx11::directory_iterator::operator*() const' > > /builddir/build/BUILD/libksysguard- > > 5.22.2.1/processcore/cgroup_data_model.cpp:447: > > undefined reference to > > `std::filesystem::__cxx11::directory_iterator::operator++()' > > CMakeFiles/processcore.dir/cgroup_data_model.cpp.o: In function > > `KSysGuard::CGroupDataModel::update(KSysGuard::CGroup*) [clone > > .localalias.209]': > > /usr/include/c++/8/bits/fs_dir.h:260: undefined reference to > > `std::filesystem::status(std::filesystem::__cxx11::path const&)' > > collect2: error: ld returned 1 exit status > > std::filesystem was originally added as an experimental extension to C++, > and > at first required explicitly linking with -lstdc++fs. GCC 9 removed the > requirement for the additional link library [1], but RHEL 8's default > compiler > is GCC 8. Therefore, for EPEL 8, you would have to create a patch which > adds > stdc++fs to the target_link_libraries of the processcore target. > > [1] https://gcc.gnu.org/gcc-9/changes.html > > HTH, > My cmake skills are not up to snuff. A little more help is needed. I seems -lstdc++fs needs to be added at the end of the compile command /usr/bin/c++ <options and other stuff> -lstdc++fs instead of at the beginning or middle of the options /usr/bin/c++ -lstdc++fs <options and other stuff> I can do that manually, and it compiles correctly. But getting cmake to do it, I'm clearly missing something. Is there a cmake command line option to put -lstdc++fs at the end? There are several cmake and cmake.in files. Would I put it in one, and if so, what is the syntax? Thanks Troy

1 0

help request: libksysguard build failure on Stream 8
by Troy Dawson 23 Jun '21

23 Jun '21

I'm updating/ rebuilding KDE Plasma Desktop on CentOS Stream 8, for the updated qt5 that is there. I am using what is in F34 for the update. I've got all the qt5 5.15.2 and kf5 5.83.0 packages built and in the buildroot. For libksysguard I believe I have all other dependencies built and in the buildroot. But it just keeps failing, despite everything I've tried.[1][2] I get the same error on all arches. The same error on version 5.22.1, 5.22.2 and even 5.21.4. I've tried passing build parameters that I thought went along with the error, but nothing changed. I think this is the critical error, but it's possible I'm wrong CMakeFiles/processcore.dir/cgroup_data_model.cpp.o: In function `KSysGuard::CGroupDataModel::update(KSysGuard::CGroup*) [clone .localalias.209]': /usr/include/c++/8/bits/fs_path.h:185: undefined reference to `std::filesystem::__cxx11::path::_M_split_cmpts()' CMakeFiles/processcore.dir/cgroup_data_model.cpp.o: In function `KSysGuard::CGroupDataModel::update(KSysGuard::CGroup*) [clone .localalias.209]': /usr/include/c++/8/bits/fs_dir.h:371: undefined reference to `std::filesystem::__cxx11::directory_iterator::directory_iterator(std::filesystem::__cxx11::path const&, std::filesystem::directory_options, std::error_code*)' CMakeFiles/processcore.dir/cgroup_data_model.cpp.o: In function `KSysGuard::CGroupDataModel::update(KSysGuard::CGroup*)': /builddir/build/BUILD/libksysguard-5.22.2.1/processcore/cgroup_data_model.cpp:447: undefined reference to `std::filesystem::__cxx11::directory_iterator::operator*() const' /builddir/build/BUILD/libksysguard-5.22.2.1/processcore/cgroup_data_model.cpp:447: undefined reference to `std::filesystem::__cxx11::directory_iterator::operator++()' CMakeFiles/processcore.dir/cgroup_data_model.cpp.o: In function `KSysGuard::CGroupDataModel::update(KSysGuard::CGroup*) [clone .localalias.209]': /usr/include/c++/8/bits/fs_dir.h:260: undefined reference to `std::filesystem::status(std::filesystem::__cxx11::path const&)' collect2: error: ld returned 1 exit status Any help would be appreciated. Troy [1] - https://koji.fedoraproject.org/koji/taskinfo?taskID=70653878 [2] - https://kojipkgs.fedoraproject.org//work/tasks/3890/70653890/build.log

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

kde June 2021