test October 2022

test@lists.fedoraproject.org

25 participants
25 discussions

reversible dual-boot test station
by Chris Murphy 23 Feb '24

23 Feb '24

Hi, I mentioned this in a QA meeting, and have given it enough testing that I think it's broadly usable. If desired it can be copied out of my user account and put up somewhere where QA folks will see it and can modify it as issues or improvements are discovered. What is it? The idea is to produce a system that can confidently be used for baremetal testing, without risking the primary operating system. While VM's are a great way to test, it's also a really idealized environment that tends to not expose an assortment of bugs that affect particular hardware. But then quite a lot of folks reasonably don't want to upgrade their daily use hardware early on, because they don't want to always have to debug things, or have to figure out how to undo the upgrade if it really goes badly. Therefore, I present a dual-boot setup offering: * no re-partitioning; * no installation step, instead system upgrade is used; * reversibility, or undoability, i.e. with just a few steps you can delete the "test OS". https://fedoraproject.org/wiki/User:Chrismurphy/Draft/dualboot_teststation -- Chris Murphy

2 5

Re: Thoughts welcome: interface between automated test gating and the "critical path"
by Adam Williamson 16 Aug '23

16 Aug '23

On Fri, 2022-09-02 at 08:37 +0000, Zbigniew Jędrzejewski-Szmek wrote: > > > > Now, because I glued openQA to the critpath because it was handy, there > > are two sets of consequences to a package being in critical path: > > > > 1. Tighter Bodhi requirements > > 2. openQA tests are run, and results gate the update (except Rawhide) > > > > So, one of the implicit questions here is, is it OK to keep twinning > > these two sets of consequences, or should we split them up? Splitting > > them up kinda implies answer 2) from my original mail: "Keep the > > current "critical path" concept but define a broader group > > of "gated packages" somewhere". Because we would then need some new > > concept that isn't "critical path". As I said, that's more *work* - > > it'd require us to write new code in several places[0]. Even if we > > decide it'd be nice to do this, is it nice *enough* to be worth doing > > that work? > > I'd still vote for keeping a single critpath list and using it as > "the list of packages that require extra care and testing". > > As you describe, the original meaning of critpath has shifted, but > it's because the way we do updates and QA has also shifted. Doing > gating tests for a package seems much more useful than just keeping > it longer in 'updates-testing' in hope that somebody discovers an > important regresion in the second week. Well, there's a caveat there - openQA doesn't test everything. On the whole we cover quite a lot with the set of tests that gets run on updates, but there's certainly lots of potential for there to be important bugs it misses, that a human tester might catch. So I think there is still a case for the higher karma requirements too. > > So yeah, I don't think it makes sense to do the extra work to split > the concepts. Also because we have way too many concepts and processes > in Fedora already. On the whole, though, I agree with you. I just don't trust my own opinion because it's obviously biased by what's convenient for me. :D > > If we don't think it's worth doing that work, then we're kinda stuck > > with openQA glomming onto the critpath definition to decide which > > updates to test and gate, because I don't have any other current viable > > choices for that, really. And we'd have to figure out a critpath > > definition that's as viable as possible for both purposes. > > > > > > BTW, one other thought I've had in relation to all this is that we > > could enhance the current critpath definition somewhat. Right now, it's > > built out of package groups in comps which are kinda topic-separated: > > there's a critpath-kde, a critpath-gnome, a critpath-server, and so on. > > But the generated critical path package list is a monolith: it doesn't > > distinguish between a package that's on the GNOME critpath and a > > package that's on the KDE critpath, you just get a big list of all > > critpath packages. It might be nice if we actually did distinguish > > between those - the critpath definition could keep track of which > > critpath topic(s) a package is included in, and Bodhi could display > > that information in the web UI and provide it via the API. That way > > manual testers could get a bit more info on why a package is critpath > > and what areas to test, and openQA could potentially target its test > > runs to conserve resources a bit, though this might require a bit more > > coding work on the gating stuff now I think about it. > > That sounds useful. We only need a volunteer to figure out the details > and do the work ;) I actually did a huge rewrite of the thing that generates the critpath data this week, and it probably wouldn't be tooooo much work, honestly. The most annoying bit would be the Bodhi frontend stuff, but that's because I'm bad at frontend dev in general. :P But yeah, this is definitely off in sky-castle land. I'll add it to my ever-growing list of sky-castle projects to do when I get a couple of years of spare time... -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net

3 4

Plan / proposal: enable openQA update testing and potentially gating on Rawhide updates
by Adam Williamson 09 Jun '23

09 Jun '23

Hi folks! We've had openQA testing of updates for stable and branched releases, and gating based on those tests, enabled for a while now. I believe this is going quite well, and I think we addressed the issues reported when we first enabled gating - Bodhi's gating status updates work more smoothly now, and openQA respects Bodhi's "re-run tests" button so failed tests can be re-triggered. A few weeks ago, I enabled testing of Rawhide updates in the openQA lab/stg instance. This was to see how smoothly the tests run, how often we run into unexpected failures or problems, and whether the hardware resources we have are sufficient for the extra load. So far this has been going more smoothly than I anticipated, if anything. The workers seem to keep up with the test load, even though one out of three worker systems for the stg instance is currently out of commission (we're using it to investigate a bug). We do get occasional failures which seem to be related to Rawhide kernel slowness (e.g. operations timing out that usually don't otherwise time out), but on the whole, the level of false failures is (I would say) acceptably low, enough that my current regime of checking the test results daily and restarting failed ones that don't seem to indicate a real bug should be sufficient. So, I'd like to propose that we enable Rawhide update testing on the production openQA instance also. This would cause results to appear on the Automated Tests tab in Bodhi, but they would be only informational (and unless the update was gated by a CI test, or somehow otherwise configured not to be pushed automatically, updates would continue to be pushed 'stable' almost immediately on creation, regardless of the openQA results). More significantly, I'd also propose that we turn on gating on openQA results for Rawhide updates. This would mean Rawhide updates would be held from going 'stable' (and included in the next compose) until the gating openQA tests had run and passed. We may want to do this a bit after turning on the tests; perhaps Fedora 37 branch point would be a natural time to do it. Currently this would usually mean a wait from update submission to 'stable push' (which really means that the build goes into the buildroot, and will go into the next Rawhide compose when it happens) of somewhere between 45 minutes and a couple of hours. It would also mean that if Rawhide updates for inter-dependent packages are not correctly grouped, the dependent update(s) will fail testing and be gated until the update they depend on has passed testing and been pushed. The tests for the dependent update(s) would then need to be re- run, either by someone hitting the button in Bodhi or an openQA admin noticing and restarting them, before the dependent update(s) could be pushed. In the worst case, if updated packages A and B both need the other to work correctly but the updates are submitted separately, both updates may fail tests and be blocked. This could only be resolved by waiving the failures, or replacing the separate updates with an update containing both packages. All of those considerations are already true for stable and branched releases, but people are probably more used to grouping updates for stable and branched than doing it for Rawhide, and the typical flow of going from a build to an update provides more opportunity to create grouped updates for branched/stable. For Rawhide the easiest way to do it if you need to do it is to do the builds in a side tag and use Bodhi's ability to create updates from a side tag. As with branched/stable, only critical path updates would have the tests run and be gated on the results. Non-critpath updates would be unaffected. (There's a small allowlist of non-critpath packages for which the tests are also run, but they are not currently gated on the results). I think doing this could really help us keep Rawhide solid and avoid introducing major compose-breaking bugs, at minimal cost. But it's a significant change and I wanted to see what folks think. In particular, if you find the existing gating of updates for stable/branched releases to cause problems in any way, I'd love to hear about it. Thanks folks! -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net

3 4

F37 Final blocker status update
by Ben Cotton 04 Nov '22

04 Nov '22

Fedora Linux 37 Final freeze begins Tuesday 4 October. Action summary ==================== Accepted blockers ----------------- 1. anaconda — Custom partitioning with 2 drives selected, bootloader fails to install due to one drive not having a BIOS Boot partition — ON_QA ACTION: QA to verify FEDORA-2022-c20d42f3bc 2. gnome-contacts — When a single contact is edited, it results in multiple contacts of the same name. — ON_QA ACTION: QA to verify FEDORA-2022-acbfee2ce8 3. gnome-initial-setup — Unable to set up enterprise account with gnome-initial-setup, clicking continue does not join the domain — ASSIGNED ACTION: dgilmore to test https://koji.fedoraproject.org/koji/taskinfo?taskID=92037333 4. gnome-shell — GNOME Initial Setup uses the English keyboard, instead of the default keyboard — ASSIGNED ACTION: Upstream to diagnose and resolve issue 5. gnome-shell — Attempting to disconnect VPN connection from system menu does nothing — VERIFIED ACTION: (none) 6. gnome-software — Can't install a local rpm package anymore, Install button missing (for certain RPMs) — VERIFIED ACTION: (none) 7. greenboot — greenboot-grub2-set-counter.service fails on 38 IoT with "cannot open `/boot/grub2/grubenv.new`: No such file or directory." — NEW ACTION: Maintainers to diagnose issue 8. grub2 — Windows with bitlocker enabled can't be booted, needs to use bootnext instead of chainloader — NEW ACTION: Maintainers to diagnose issue or provide status update 9. mesa — totem: nouveau_pushbuf_data(): totem killed by SIGABRT — NEW ACTION: Maintainers to update mesa with fixes for F37 10. uboot-tools — Regression booting Fedora on rockchip devices installed on PCIe NVME drives — ON_QA ACTION: QA to verify FEDORA-2022-c1d9e8daa9 Proposed blockers ----------------- 1. chrome-gnome-shell — Project name and source repository changed to gnome-browser-connector — NEW ACTION: Reviewer to approve new gnome-browser-connector package. 2. gnome-shell — screencast doesn't record the top layer — NEW ACTION: QA to verify if behavior still exists 3. gnome-shell-extension-background-logo — Update gnome-shell-extension-background-logo to 43.0 — NEW ACTION: Maintainer to update package 4. systemd — Czech qwerty layout configured in anaconda, but qwertz layout used in disk unlock and in VT console — NEW ACTION: kbd maintainers to reconsider the -legacy subpackage split Bug-by-bug detail ============= Accepted blockers ----------------- 1. anaconda — https://bugzilla.redhat.com/show_bug.cgi?id=2088113 — ON_QA Custom partitioning with 2 drives selected, bootloader fails to install due to one drive not having a BIOS Boot partition When using custom partitioning on two drives with /boot on a RAID 1 device, the installer only creates one BIOS boot. grub2-install is run against both drives, but the second fails because it has no BIOS boot partition. FEDORA-2022-c20d42f3bc contains a candidate fix. 2. gnome-contacts — https://bugzilla.redhat.com/show_bug.cgi?id=2111003 — ON_QA When a single contact is edited, it results in multiple contacts of the same name. Editing a contact results in the contact being properly updated, but an empty contact is created with the same name. FEDORA-2022-acbfee2ce8 contains a candidate fix. 3. gnome-initial-setup — https://bugzilla.redhat.com/show_bug.cgi?id=2123494 — ASSIGNED Unable to set up enterprise account with gnome-initial-setup, clicking continue does not join the domain Initially the buttons were missing. Update FEDORA-2022-50e585b456 fixed that issue, however clicking the button does not joing the domain. Instead, the user is returned to the domain credentials screen, resulting in an endless loop. https://koji.fedoraproject.org/koji/taskinfo?taskID=92037333 contains a backport of upstream's change which may fix it. 4. gnome-shell — https://bugzilla.redhat.com/show_bug.cgi?id=2121110 — ASSIGNED GNOME Initial Setup uses the English keyboard, instead of the default keyboard Regardless of the default keyboard setting, g-i-s uses the English keyboard. Relatedly, new users have the English keyboard selected, even though another language is shown as the default. FEDORA-2022-52cdfc7920 failed to fix this issue. 5. gnome-shell — https://bugzilla.redhat.com/show_bug.cgi?id=2125252 — VERIFIED Attempting to disconnect VPN connection from system menu does nothing Disabling a VPN doesn't disable the VPN. Fixed in FEDORA-2022-50e585b456. 6. gnome-software — https://bugzilla.redhat.com/show_bug.cgi?id=2124869 — VERIFIED Can't install a local rpm package anymore, Install button missing (for certain RPMs) What it says on the tin. Fixed in FEDORA-2022-b6246d02fa. 7. greenboot — https://bugzilla.redhat.com/show_bug.cgi?id=2121944 — NEW greenboot-grub2-set-counter.service fails on 38 IoT with "cannot open `/boot/grub2/grubenv.new`: No such file or directory." greenboot service fails on a file-not-found error. This also results in rebase tests failing because of conflicts with the rebase triggered by the greenboot failure. 8. grub2 — https://bugzilla.redhat.com/show_bug.cgi?id=2049849 — NEW Windows with bitlocker enabled can't be booted, needs to use bootnext instead of chainloader Dual-booting recent Windows 10 system with TPM 2.0 fails because bitlocker can't be unsealed by the TPM. This was waived to F37 under the "difficult to fix" exception. No additional updates have been provided. 9. mesa — https://bugzilla.redhat.com/show_bug.cgi?id=2123274 — NEW totem: nouveau_pushbuf_data(): totem killed by SIGABRT totem plays ~1 second of video and then crashes. This appears to happen with all video formats. This appears to be an issue in multithreading support in the nouveau driver, which is fixed upstream. The fix is large and may not be suitable for backporting, but would be available in a mesa-22.3 update. 10. uboot-tools — https://bugzilla.redhat.com/show_bug.cgi?id=2124127 — ON_QA Regression booting Fedora on rockchip devices installed on PCIe NVME drives uboot-tools introducted a regression when used with 5.19.x kernels. FEDORA-2022-c1d9e8daa9 contains a candidate fix. Proposed blockers ----------------- 1. chrome-gnome-shell — https://bugzilla.redhat.com/show_bug.cgi?id=2106868 — NEW Project name and source repository changed to gnome-browser-connector Upstream has split this into two packages. Package review pending for renamed package: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2127314 2. gnome-shell — https://bugzilla.redhat.com/show_bug.cgi?id=2125439 — NEW screencast doesn't record the top layer Typing and popup windows don't show when recording a screencast. This may be fixed in pipewire-gstreamer-0.3.57-1. 3. gnome-shell-extension-background-logo — https://bugzilla.redhat.com/show_bug.cgi?id=2127192 — NEW Update gnome-shell-extension-background-logo to 43.0 The Fedora logo is not displayed and the package is not compatible with gnome-shell 43. 4. systemd — https://bugzilla.redhat.com/show_bug.cgi?id=2121106 — NEW Czech qwerty layout configured in anaconda, but qwertz layout used in disk unlock and in VT console The wrong keymap is used when unlocking disks or virtual terminals. It looks like this may have never worked. It looks like an issue with how layouts are mapped between console and xkb. Adam is thinking about how to approach this: https://bugzilla.redhat.com/show_bug.cgi?id=2121106#c24 -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

2 8

Proposal: make meetings officially every other week
by Adam Williamson 02 Nov '22

02 Nov '22

Hey folks! The more attentive among you may have noticed I've had a kinda unofficial policy of holding the QA meetings every other week for a while. We just don't seem to have as much to discuss/debate as maybe we did five or six years ago. I choose to see this as a positive sign that everything is working smoothly, but maybe others disagree? I dunno. Anyway, it seems a bit silly that we still notionally schedule a meeting every week but I almost always cancel half of them. So I'm proposing we make it official that we only meet every *other* week. This would save sending out cancellation notices and manually canceling the event in the calendar every other week. What do folks think? Makes sense? Or would you rather we really do meet every week and find more things to argue about? Or do you hate meetings and wish we only did one a year? :D -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net

7 6

Is KDE Plasma 5.26 going to make it into F37 final?
by Scott Beamer 29 Oct '22

29 Oct '22

Greetings, I've been using it for several days now (I have the updates-testing repo enabled) in F37 and it seems to be running pretty smoothly. However, I just installed the F37 KDE spin in a VM by itself to see what was up, and Plasma hasn't been updated to 5.26 yet. KDE released it on 11 October. Just wondering... Scott

3 3

Re: [Test-Announce] 2022-10-31 @ 16:00 UTC - Fedora 37 Blocker Review Meeting
by Adam Williamson 29 Oct '22

29 Oct '22

On Sat, 2022-10-29 at 02:37 +0000, Gary Buhrmaster wrote: > On Sat, Oct 29, 2022 at 12:44 AM Adam Williamson > <adamwill(a)fedoraproject.org> wrote: > > > > # F36 Blocker Review meeting > > If this was a test to see if anyone noticed the title being > wrong, I am afraid I have failed that test for the entire > cycle. Aaaand so did I! https://media.giphy.com/media/uhv7KzWW3OWYM/giphy.gif I swear I proofread these things. Just apparently not hard enough. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net

1 0

dnf processing causes oom-kill
by George R Goffe 29 Oct '22

29 Oct '22

Hi, I've been seeing this problem for a few days now. I start a "normal" dnf upgrade that fails to complete because something in dnf or perhaps a script that triggers an oom-kill event. I have seen this in a VM host (8G swap) and in a VM guest (2G swap)... both FC38. I wrote a bug on the bugzilla for this... https://bugzilla.redhat.com/show_bug.cgi?id=2138369 Has anyone seen this? Is there info that would be needed to discover just why this is happening? Please let me know. Best regards, George...

2 1

Install matrix update - more coverage for the Basic Video Driver testcase
by Kamil Paral 27 Oct '22

27 Oct '22

Just a heads up that I updated the Install matrix and extended the Basic Video Driver testcase coverage. This is because the basic video driver is a frequent cause of problems, and the limited coverage could often overlook issues, like our latest proposed blocker: https://bugzilla.redhat.com/show_bug.cgi?id=2137600 Before (2 test runs were enough to completely fill it out): https://fedoraproject.org/wiki/Test_Results:Fedora_37_RC_1.4_Installation#U… After (4 test runs are necessary to completely fill it out): https://fedoraproject.org/wiki/Template:Installation_test_matrix#User_inter… Diff: https://fedoraproject.org/w/index.php?title=Template%3AInstallation_test_ma… Any new release validation matrices (new RC, new nightly) should get the updated table.

2 3

KDE Live can be installed without creating a regular user - correct/wrong?
by Kamil Paral 26 Oct '22

26 Oct '22

KDE Live can be installed without creating a regular user, only root. All you need to do is to not create a regular user in anaconda (only root), and then not create a regular user in the first boot utility (just click Finish). In SSDM, it is then possible to log in using the root account (not a good idea in general, to be sure). Is this intentional, or a bug? Should KDE require creating a regular user, similarly to Workstation?

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

test October 2022