test December 2020

test@lists.fedoraproject.org

27 participants
207 discussions

Release criteria proposal: networking requirements
by Adam Williamson 01 Mar '22

01 Mar '22

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

6 18

NVIDIA Question
by David St.Clair 17 Jan '22

17 Jan '22

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

10 20

Mouse goes crazy
by Jonathan Villa 17 Jan '22

17 Jan '22

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. ???

8 7

criterion proposal: prevent services timing out on system shutdown
by Kamil Paral 22 Feb '21

22 Feb '21

*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_serv…

9 18

Fedora SOAS 33 Beta Startup Goes Straight to Login Screen
by Chihurumnaya Ibiam 06 Feb '21

06 Feb '21

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.

5 7

F33 testing request: bluetooth mice
by Adam Williamson 02 Feb '21

02 Feb '21

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

7 14

Enabled some openQA desktop tests on aarch64
by Adam Williamson 20 Jan '21

20 Jan '21

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 2

heads up: nss 3.59 breaks firefox add-ons
by Kevin Fenzi 08 Jan '21

08 Jan '21

If you upgrade in f33 or rawhide to nss 3.59, all your firefox add-ons will stop working. Worse they will appear corrupted, so you will have to remove them and re-install them (after downgrading nss). For now, downgrade nss or avoid updating to it until things can get sorted out. https://bugzilla.redhat.com/show_bug.cgi?id=1908018 kevin

5 5

Do Fedora only keep latest package on repo? How to get verbose/debug output of dnf history
by Robbi Nespu 03 Jan '21

03 Jan '21

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

6 8

Fedora-IoT-34-20201231.0 compose check report
by Fedora compose checker 31 Dec '20

31 Dec '20

Missing expected images: Iot dvd x86_64 Iot dvd aarch64 Failed openQA tests: 1/16 (x86_64), 5/15 (aarch64) ID: 749232 Test: x86_64 IoT-dvd_ostree-iso base_services_start URL: https://openqa.fedoraproject.org/tests/749232 ID: 749241 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/749241 ID: 749243 Test: aarch64 IoT-dvd_ostree-iso podman@uefi URL: https://openqa.fedoraproject.org/tests/749243 ID: 749244 Test: aarch64 IoT-dvd_ostree-iso podman_client@uefi URL: https://openqa.fedoraproject.org/tests/749244 ID: 749246 Test: aarch64 IoT-dvd_ostree-iso base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/749246 ID: 749250 Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_overlay@uefi URL: https://openqa.fedoraproject.org/tests/749250 Soft failed openQA tests: 1/16 (x86_64) (Tests completed, but using a workaround for a known bug) ID: 749225 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/749225 Passed openQA tests: 14/16 (x86_64), 10/15 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

test December 2020