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
2 months, 3 weeks
Freezing Plasma in Fedora?
by Mikhail Ramendik
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
1 year, 4 months
KDE update/stability policy on Fedora
by Mikhail Ramendik
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...
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
1 year, 4 months
Re: F34 Change proposal: Wayland by Default for KDE Plasma Desktop
(System-Wide Change)
by Adam Batkin
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
1 year, 4 months
Request for help: dead keys with qt5
by José Abílio Matos
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
1 year, 5 months
gnome-keyring and plasma-wayland
by Mattia Verga
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
1 year, 5 months
