Release criteria proposal: networking requirements
by Adam Williamson
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
1 year, 9 months
Problems after upgrade to Fedora-34
by Jonathan Ryshpan
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......
2 years, 5 months
Fedora website - revamp
by Pawel Zelawski
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 years, 5 months
Warning on kontact/kmail
by José Abílio Matos
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 years, 5 months
Native KDE app mouse select is off by 1 line and 1 char under Wayland
by Barry Scott
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
2 years, 5 months
Re: [EPEL-devel] Re: help request: libksysguard build failure on
Stream 8
by Troy Dawson
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.tx...
>
That did it. Thank you very much.
Not only am I unblocked, but my cmake skills are a little bit better.
Troy
2 years, 5 months
Re: [EPEL-devel] Re: help request: libksysguard build failure on
Stream 8
by Troy Dawson
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
2 years, 5 months
help request: libksysguard build failure on Stream 8
by Troy Dawson
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
2 years, 5 months
