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
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.
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
This may be a dumb question, but why can't Redhat distribute NVIDIA binary
In NVIDIA's licence (http://www.nvidia.com/object/nv_swlicense.html) it
"2.1.2 Linux Exception. Notwithstanding the foregoing terms of Section
2.1.1, SOFTWARE designed exclusively for use on the Linux operating system
copied and redistributed, provided that the binary files thereof are not
modified in any
way (except for unzipping of compressed files)."
So, what's keeping RedHat from putting the drivers in the distribution? If
it's a GPL
thing, would it be easy to just download it during installation or at
least give the option to the user?
Ok, I have had Yarrow working well for a while now, but yesterday I
started experiencing some odd issues with my mouse. All of a sudden it
stops working correctly. The only thing that seems to fix is to kill X
and run mouse-test, then restart.
Also, I have FC 1 running on a desktop which is hooked up to a KVM
switch. Whenever I go to another PC, and return, the same thing
happens, the mouse goes crazy.
In the wake of the BZ 1924808 discussion in Thursday's Go/No-Go
meeting, I am proposing an addition to the Basic Release
Criteria. This would go into Post-Install Requirements -> Expected
installed system boot behavior -> First boot utilities (appended after
the existing sentence):
> If a utility for creating user accounts and other configuration is configured to launch, it must be visible within 10 seconds of the first boot reaching the launch point.
Why 10 seconds? Why not? That sort of feels like the maximum length of
time someone could reasonably be expected to wait. A shorter time
might be better.
I don't particularly love the wording here, but I wanted to make it
clear that it's not 10 seconds from power on, but 10 seconds from the
time the boot up reaches the state where we expect gnome-initial-setup
or its counterparts to appear.
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
I wonder if we couldn't add in some (re)testing of upgrades after a release
is 'go' but before it's actually released. We hit at least two issues I
am aware of with f34 due to multilib. ;(
pipewire.i686 is in the base x86_64 repo and users had/have it installed.
pipewire.i686 is pulled into the x86_64 base repo by mutter (mutter.i686
is there and requires pipewire.i686).
In any case it is not in the updates repo, so once an update of them
is pushed (which it has been), upgrades fail due to the missing
I have modified the updates pungi config to whitelist pipewire for
multilib and it's in f34-updates now.
There's still an issue with iptables.
basically the version in the base repo has a 'iptables' package.
The one in updates Obsoletes this for a iptables-compat, but yet it's
not doing things correctly as users are getting dnf errors.
Anyhow, I think it might be good to perhaps schedule some re-resting of
upgrades after the 0 day updates repo is populated to try and catch
these and fix them before release day.
We can't test this fully before there is an updates repo (I mean we kind
of can with updates-testing, but it's not the exact same repo).
I'm running kernel-5.11.17-200.fc33.x86_64 with my F33, and I
tried to upgrade from F33 tp F34. I performed all adviced steps
the last download step "sudo dnf system-upgrade download --releasever=34".
But nothing special happens when calling the last step "sudo dnf
The system is booted without any message into F33 again, and I dont
Anybody has an idea what to do for getting some important infos?
Fedora release 33 (Thirty Three)
Joachim Backes <joachim.backes(a)rhrk.uni-kl.de>