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, 9 months
NVIDIA Question
by David St.Clair
This may be a dumb question, but why can't Redhat distribute NVIDIA binary
drivers?
In NVIDIA's licence (http://www.nvidia.com/object/nv_swlicense.html) it
says:
"2.1.2 Linux Exception. Notwithstanding the foregoing terms of Section
2.1.1, SOFTWARE designed exclusively for use on the Linux operating system
may be
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?
Thanks,
--
David St.Clair
dstclair(a)cs.wcu.edu
1 year, 10 months
Mouse goes crazy
by Jonathan Villa
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.
Any ideas?
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.
???
1 year, 10 months
Proposal to modify: Working Sound Beta Release Criterion
by Lukas Ruzicka
Hello friends of Fedora,
I have been thinking about a proposal to modify the %subj. I have tried
several version and I did not like any, so finally I am proposing this text:
*Working sound*
*The installed system must be able to play back and record audio.*
This is a very short and general version, but I believe it supports the
following:
1. Playback and recording must work (which we want)
2. You can test on any application you like (The recording test case
will recommend Audacity)
3. It does not say that all applications must work, so we should be fine
if *some do*
What do you think?
--
Lukáš Růžička
FEDORA QE, RHCE
Red Hat
<https://www.redhat.com>
Purkyňova 115
612 45 Brno - Královo Pole
lruzicka(a)redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. <https://redhat.com/trusted>
2 years, 9 months
criterion proposal: prevent services timing out on system shutdown
by Kamil Paral
*Why*
The recent spice-vdagent update causes all virtual machines to take 90
seconds longer on every shutdown/reboot:
https://bugzilla.redhat.com/show_bug.cgi?id=1813667
The service hangs when systemd tries to stop it, and systemd then kills it
after a 90 second timeout expires.
This is a recurring pattern, I saw services blocking shutdown/reboot in the
past, and so far we haven't been able to do anything about it from a
blocker perspective. I think that for cases where the problem occurs very
frequently or every time, we should have a way to block the release until
it's fixed. I find it a very poor experience to wait 90+ seconds for
machine reboot/shutdown. Much poorer than, say, a crashing desktop
application (which we block on), because that application can be replaced
with a different one. System services mostly can't be replaced, and
certainly not by a general user.
*Proposal*
So I propose to amend the "System services" criterion [1]:
```
All system services present after installation with one of the
release-blocking package sets must start properly, unless they require
hardware which is not present.
```
with something like this:
```
All system services present after installation with one of the
release-blocking package sets must start properly, unless they require
hardware which is not present.
*All system services present after installation with one of the
release-blocking package sets must not time out frequently or regularly
when they are being stopped during system reboot/shutdown.*
```
The way it is written, the mentioned bug would be a conditional violation
of that criterion (applies only to VMs) and we'd need to use our judgement
to determine whether it's a blocker.
Thoughts?
[1]
https://fedoraproject.org/wiki/Fedora_32_Final_Release_Criteria#System_se...
2 years, 9 months
Proposal to Modify: Testcase dualboot with macOS
by Geoffrey Marr
Hi all,
I have spent the last two days experimenting with Fedora 33 on a 2017 12"
Macbook (Macbook10,1). Unlike some previous Macs I have installed Fedora
on, out-of-the box peripheral support is fantastic. I didn't have to
install a single driver myself, everything was included. /praise over
After reviewing our "dualboot with macOS" testcase [0], I noticed that the
testcase says it's based on a Mac running macOS 10.12 Sierra. At this point
in time, macOS Sierra is almost 5 years old. I would like to update this
testcase to reflect that it supports *any* OS from macOS 10.12 Sierra to
macOS 11 Big Sur. I have tested these myself for compatibility and find
that they all provide the necessary means for a dualboot install.
On a side note, I would also like to include a small notice within the
testcase that mentions that Fedora is *not* supported on the new Apple
Silicon M1 computers and that this testcase only applies to Intel-based
Macs.
I have made these changes as I see them to my own wiki page [1]. Please
review the page and propose any suggestions here. Feedback is welcome. If I
don't hear any major squawks in a week or so, I will merge the changes into
the official Fedora QA wiki.
Geoff Marr
IRC: coremodule
[0] https://fedoraproject.org/wiki/QA:Testcase_dualboot_with_macOS
[1]
https://fedoraproject.org/wiki/Coremodule/QA:Testcase_dualboot_with_macOS
2 years, 9 months
Respins for OEM preloads
by Matthew Miller
A large computer vendor with whom we have a friendly relationship would like
to update the image they're shipping on their systems so that 1) new users
don't have quite so many updates immediately and 2) auiu newer kernel helps
with some upcoming things *vague vague handwavy vague*.
I can think of four possibilities:
1. Sure, use the live-respins!
2. The live-respins are unofficial, but we have run [this specific
workstation iso] through our standard validation tests and we
recommend it for your use.
3. Use the netinstall and choose "apply updates" (or whatever that option is
called) when making your distribution image.
4. Uh, sorry, we got nothin'.
In all cases, they will run through their own internal testing and
validation. And, because of calendar things, they'd really love an answer
before the 26th of this month, which I know is short notice.
Of the above, I think #2 is the best, but requires someone other than me to
do significant work. Sooooo, I'm raising it here. :)
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
2 years, 9 months
Fedora SOAS 33 Beta Startup Goes Straight to Login Screen
by Chihurumnaya Ibiam
I just tried testing the Fedora SOAS 33 beta and after starting it it goes straight to a login screen when I haven't setup any accounts, the image is supposed to boot into the sugar desktop startup screen, the installation was done in a vm.
2 years, 10 months
F33 testing request: bluetooth mice
by Adam Williamson
Hi folks!
A new proposed blocker bug showed up today:
https://bugzilla.redhat.com/show_bug.cgi?id=1874082
the issue is that if you have a bluetooth mouse working, then suspend
the system, when you resume the bluetooth mouse will not be working any
more. You have to go into the GNOME Bluetooth settings applet to get it
to work again.
So far we have two reports, but they happened to have the exact same
mouse. Can other folks who have bluetooth mice (and even, perhaps,
other bluetooth hardware - keyboards, headsets?) - ideally different
ones! - please test this and report their findings either here or to
the bug? It's important to know what range of hardware this affects.
Thanks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
2 years, 10 months
