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
Hello friends of Fedora,
I would like to propose a new release covering criterion that was suggested
on the yesterday's Blocker Review Meeting. Please let me know, what you
think about it and perhaps suggest improvements.
*Proposal 1 (conservative criterion)*
*On computers with dual video cards (or with external video output) the
system must be able to display the video content on each connected device.
Any release blocking desktop must provide ways to set up various display
modes (mirroring, extension), scaling, resolution, frequency, and
*Proposal 2 (bold criterion)*
*On computers with dual video cards (or with external video output), as
well as with multiple video cards, the system must be able to display the
video content on each connected device. Any release blocking desktop must
provide ways to set up various display modes (mirroring, extension),
scaling, resolution, frequency, and orientation).*
FEDORA QE, RHCE
612 45 Brno - Královo Pole
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. <https://redhat.com/trusted>
I know I'm the one who always runs the old PCs, but I recently decided I
should have one new one in the mix. The one I got has an ASUS Z590-A
motherboard and an Intel i5-10400 processor. Well Fedora won't run a
Wayland session on it. It will only run a Gnome-xorg session. I even
had to run the install from Basic Graphics mode. I asked about it on
AskFedora. I have no useful response yet, but another person wrote about
a similar experience, but different motherboard; the processor was
different, but the same gen and also a UHD type. This needs to be
addressed as all the Intel processors have been UHD for quite a while
now. I'm thinking I should be writing a bug against mutter. Please let
me know if you think I've got something wrong.
Have a Great Day!
My alias is TheEvilSkeleton, but you can also call me Tesk,
TheEvilSkely, Skelly, Proprietary Chrome-chan or anything close to it.
I'm really excited to be part of QA! I first tried GNU/Linux 3 years
ago, from Ubuntu to Manjaro, Arch, Gentoo, Pop!_OS, etc. and finally
Fedora Silverblue, and I started using it as my daily OS since then.
Personally, I don't think I have much experience with Linux, since I
have been using it for around three years. I do think that I have more
knowledge in such topic than an average Linux user, but not as much as
say, a system administrator. I try my best to learn as much as I can so
I can contribute back what I've learned. I mostly contribute to
documentation, since it's one of the places where free and open source
software (FOSS) falls behind, but also because it's where I am very
good at. I also experiment; I play around a lot with distributions,
containers, VMs and more, hence me trying out many Linux distributions
in the past. I often break stuff because, well, I play around things a
lot and I'm very experimental.
I also have some knowledge with Flatpak. I maintain 6 Flatpak packages
currently. I am currently writing an introduction to Flatpak for those
that have little knowledge in Flatpak and want to learn its technical
side. I've been working for around a month, and I've spent plenty of
days for research, so I hope I'm going to give a very accurate and
user-friendly introduction to beginners. With that knowledge, I'm going
to take advantage of it to contribute to Flatpak's documentation.
On a more personal note, I'm a 19 year old "student". I'm quoting
"student", since I stopped attending to classes because I couldn't
concentrate anymore due to stress and heavy pressure from college
because of COVID. Instead of doing nothing during the time, I decided
to join QA to contribute more to FOSS and collaborating with people
around the world, and be part of the Year of the Linux Desktop™. I'm
a male, but you are free to use the pronoun you desire.
Thank you so much for accepting me in the project! I'm really excited
for this. Fedora is very open for contributions and is transparent,
which is the type of project I love.
If you want to contact me:
My nick is TheEvilSkeleton at irc.freenode.chat ;My Matrix user is
Have a nice day everyone, and thank you again for accepting me!
Hello, I have an HP TouchSmart tx2 Notebook PC. I'm running Fedora 34, with
Gnome running Wayland, and I can't get the gestures to work.
Well, not just the gestures, but the multi-touch feature itself on my
touchpad. It could be a hardware limitation, but I don't think that it is.
Any feedback would be helpful.
we have updated the main Python from 3.8.7 to 3.8.8 in Fedora 32, but since this
never went trough rawhide or Fedora 33 (already at 3.9), I wanted it to receive
some karma before pushing the update.
However, after 14 days, it only gained +2.
If you run Fedora 32, please update Python from updates-testing and after a few
days, report back via karma if your system is fully functional. Thanks.
I'm very glad to join the team. I'm a newbie to open source and have always
wanted to make contributions.
My name is Okwuidegbe Emmanuel. I live in Lagos, Nigeria. I love working
but very excited and willing to learn more about the project and contribute
to the #fedora-qa team.