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, 7 months
kwallet not unlocking on login
by Jan Drögehoff
After the Fedora 34 update on tuesday kded5 has been nagging me to unlock my KDE wallet which is strange considering it should be unlocked by SDDM usind the pam module.
After asking around on irc and finding this [1] Ask Fedora post this seems to be more than a one time occurance but I haven't been able to found out why this happens.
Can anyone shed a light on this?
2 years, 5 months
Session Selection
by Ed Greshko
I just upgraded from F33 to F34 and everything went well.
Had an issue with the kwallet but "magically" fixed it.
One problem has me scratching my head. I use sddm and in F33 there was a selection
at the bottom of the screen for running either "Plasma Wayland" or "Plasma".
My session of choice has been "Plasma". But now there is no box at the bottom
of the screen to make a selection.
The good news is my previous selection is remembered an I'm running "Plasma".
But I would like to continue to test "Plasma Wayland" but don't see a way to
choose.
Any ideas? These files exist.
/usr/share/wayland-sessions/:
plasma.desktop
/usr/share/xsessions/:
plasmax11.desktop
--
Remind me to ignore comments which aren't germane to the thread.
2 years, 5 months
copy/paste wayland
by Ed Greshko
I'm testing F34 in a VM trying to accept wayland. I've run into an issue which I hope is
covered, but can't seem to find a solution.
I want to copy/paste text from a konsole window into an email being written under
thunderbird. I though, maybe, running thunderbird-wayland was the solution but
it seems not the case. What I highlight in a konsole window doesn't show up
in the clipboard on the systray. So, unable to paste in the email.
Is there a solution for this?
--
Remind me to ignore comments which aren't germane to the thread.
2 years, 5 months
Handling of sessions in F34
by José Abílio Matos
Hi,
in F34 the session does not seems to be restored as it used before.
In the "Desktop Session" settings I have the option "When logging in:
Restore previous saved session" yet when I login the windows forget their
location both in terms of the virtual desktop as well as the screen (I use an
external screen).
Looking into the ~/.config/ksmserverrc I see that file has the same date as
the last logout (as I would expect).
This is annoying because on start I have to manually restore the applications
location.
FWIW I am running Plasma on X11.
Is this known?
Best regards,
--
José Abílio
2 years, 5 months
Another dostro with same KDE, to test bugs?
by Mikhail Ramendik
Hello,
I currently have two KDE bugs open for a few weeks but getting no attention:
- https://bugzilla.redhat.com/show_bug.cgi?id=1945192
- https://bugzilla.redhat.com/show_bug.cgi?id=1947973
Three more are likely to come once I do more reproduction testing.
I do understand the Fedora KDE team is very small so might not be able to
get to all bugs, and that the bugs are likely to be from the upstream
anyway. But I can't really raise them on bugs.kde.org unless I am sure they
*are* upstream. And I would guess this would mean checking them in another
distro, but the distro should have the same latest KDE version as Fedora
has.
Could anyone please advice which distro this would be? I don't really want
to go building Plasma from source.
Ideally I'd want a distro with a live boot of KDE, but if that is not
possible, I do have a testing machine where I can install one. But which
one should it be? Arch? Gentoo? Kubuntu?
--
Yours, Mikhail Ramendik
Unless explicitly stated, all opinions in my mail are my own and do not
reflect the views of any organization
2 years, 5 months