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
11 months, 1 week
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
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
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...
1 year, 11 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.
1 year, 12 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
Enabled some openQA desktop tests on aarch64
by Adam Williamson
Hey folks! Just a heads up that I merged a branch I've had lying around
for weeks that enables *some* of the openQA desktop tests on the
aarch64 Workstation image.
I left out some with known issues. desktop_notifications_postinstall
needs to boot to runlevel 3, which is actually a bit tricky because of
UEFI - we don't get the boot menu with a usable timeout and the trick
we use to work around that on x86_64 (where we run the tests on BIOS)
doesn't work on UEFI because the setting is in the UEFI vars which are
not part of the main disk image.
To fix this I think I need to have the 'image deploy' test upload its
UEFI vars disk image and have the desktop_notifications_postinstall
test attach that as well as the main disk image, but I need to look
into the ins and outs of that a bit and this is my last work day of the
year, so I'll do it next year.
The desktop_login test is generally fragile (things tending to get
stuck or time out), but if it gets that far, it *always* fails when it
tests locking the screen; on aarch64 this seems to cause the VM to
permanently stop updating the display, or something. Again I haven't
had time to look into this, and I want to enable the other tests
without waiting for it.
The desktop_browser test is also failing, but I left that in because
it's not a test bug, it's a distro bug. Firefox builds have just been
disabled on aarch64 since 2020-11-20, so current composes don't have
Firefox in them on aarch64 at all. There's a bug related to this:
https://bugzilla.redhat.com/show_bug.cgi?id=1897675
which I just gave a bit of a bump, because it shouldn't really be
acceptable to just turn off our default browser's build on one of our
primary arches for weeks at a time :(
This also breaks several of the other tests which use Firefox, like the
Cockpit and FreeIPA browser tests.
The tests should run on openQA prod from the next compose. The branch
has been deployed on openQA lab (staging) for weeks (including the
broken tests), so you can see how it's been behaving there.
Thanks folks!
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
2 years
Do Fedora only keep latest package on repo? How to get verbose/debug
output of dnf history
by Robbi Nespu
Do fedora only keep latest package version on repository?
When i tried undo/downgrade, it not working. I also reported on
https://bugzilla.redhat.com/show_bug.cgi?id=1911753 which I assume maybe
thus required older packager version not available
are there is someway to see verbose/debug of `dnf history` ? I tried
with `-v` but nothing much
$ sudo dnf history undo last -v
Loaded plugins: builddep, changelog, config-manager, copr, debug,
debuginfo-install, download, generate_completion_cache,
needs-restarting, playground, repoclosure, repodiff, repograph,
repomanage, reposync
DNF version: 4.5.2
cachedir: /var/cache/dnf
User-Agent: constructed: 'libdnf (Fedora 33; generic; Linux.x86_64)'
repo: using cache for: fedora-cisco-openh264
fedora-cisco-openh264: using metadata from Wed 26 Aug 2020 03:10:34 AM +08.
repo: using cache for: updates
updates: using metadata from Wed 30 Dec 2020 09:28:11 AM +08.
repo: using cache for: fedora
fedora: using metadata from Tue 20 Oct 2020 07:27:19 AM +08.
Last metadata expiration check: 0:47:53 ago on Thu 31 Dec 2020 09:18:49
AM +08.
Completion plugin: Generating completion cache...
Undoing transaction 15, from Thu 31 Dec 2020 09:31:29 AM +08
Upgrade icecat-78.6.0-2.rh1.fc33.x86_64 @updates
Upgraded icecat-78.5.0-2.rh2.fc33.x86_64 @@System
No package icecat-78.5.0-2.rh2.fc33.x86_64 available.
Error: no package matched
--
Email: robbinespu[(a)]fedoraproject[.]org | PGP key:
https://keybase.io/robbinespu/pgp_keys.asc
2 years, 1 month
