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
Virtual desktops panel
by Patrick O'Callaghan
I'm using the latest Plasma and am generally quite pleased with it,
especially with one long-standing bugbear that has now been sorted out:
when using Save Session, Plasma now correctly remembers which desktop
all the windows should be on, even those belonging to non-KDE apps
(though it still doesn't get the actual window positioning right, even
for Plasma apps).
Anyway, on the same subject of virtual desktops, I find the panel to be
rather visually confusing, so I'd like to show only the name of each
desktop without the tiny wire-frame copies of each window inside it.
I'm pretty sure this used to be possible but can't seem to find the
right incantation.
The rectangles representing each desktop are also too wide, which looks
like an actual bug. Can anyone confirm this?
poc
1 year, 5 months
Hold Plasma version
by Mikhail Ramendik
Hello,
The situation with the big Plasma version update in KDE has been
discussed a lot. For me, the mid-release-cycle major version update
caused significant issues before.
So I have a question: is it possible to just hold the Plasma version
in Fedora, entirely preventing updates of any Plasma packages? I would
enter such a freeze a few days before the new Plasma hits, then
unfreeze a month or two after, hoping that any glitches in the fedora
Fedora were ironed out in the meantime.
I would not want to freeze all other updates though.
So I would very much appreciate it if people could tell me how to do
this. Is there a list of packages I need to use "dnf versionlock" on?
--
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, 5 months
Display resolution changing
by Patrick O'Callaghan
I'm having a strange problem with my display resolution. This doesn't
happen with Gnome, so I assume it's KDE-related in some way.
Briefly, I have an HP Pavilion 23xi monitor connected via HDMI to an
HDMI switch, which in turns connect to two GPUs. One of these is an
Intel 915 on the motherboard and is what I normally use for Linux. The
other is an Nvidia GTX1050 which I use only for Windows gaming using a
KVM/QEMU VM with VFIO passthrough. What this means is that the Nvidia
card is masked (blacklisted) from Linux and is only visible to the VM.
In fact neither of the Nvidia nor Nouveau kernel modules are even
loaded.
I now find that when I switch the monitor inputs from the Nvidia to the
i915, my display resolution is being reset to 1280x720 instead of its
normal 1920x1080. This happens *even when I'm not running the VM*. I
have to manually reconfigure the resolution using the KDE Settings
widget. This never used to happen, and I can see no reason for it to be
happening now, but it has started since I updated to Plasma 5.20. Even
if I'm running the Windows VM, the display is always set to the same
1920x1080, so I don't know where the lower resolution is even coming
from.
Any thoughts on this would be welcome.
poc
1 year, 6 months
keyboard language in rawhide
by Mattia Verga
I'm running Fedora rawhide (plasma-wayland) in a libvirt VM and I see
the keyboard language setting is always English even if I set an other
language in the IBus language changer in the tray.
I wonder whether to report this bug against IBus or some other plasma or
KDE component...
1 year, 6 months
