test July 2023

test@lists.fedoraproject.org

15 participants
15 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

DNF5 ~ How to "sudo dnf remove --oldinstallonly"
by Ian Laurie 12 Aug '23

12 Aug '23

In DNF5 how do you do this DNF4 style command? sudo dnf remove --oldinstallonly I'm guessing there must be a way but it's eluding me so far. -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney

2 2

Not seeing "check" in dnf5
by Onyeibo Oku 27 Jul '23

27 Jul '23

Greetings I am getting kernel panics after recent updates. Strangely, lots of things are also broken (e.g. Python 3.12 getting mixed up with 3.11, virtual environments, etc.). I suspect the update did not conclude properly because dnf5 tends to stop midway when it encounters an issue. So, I ran a "dnf check". What do you know? "check" command appears to be absent in dnf5. I think my local repo (RPMs) are in a bad state. I am running Rawhide. Any ideas? Regards Onyeibo

2 4

Rawhide update gating: mass rebuild issues
by Adam Williamson 25 Jul '23

25 Jul '23

Hi folks! Just wanted to drop a note for anyone who noticed their Rawhide updates stuck in gating for an unusually long time yesterday/today. This is mainly due to the mass rebuild. Merging it in (which was done without sending anything in it through openQA testing) resulted in two separate problems: 1. Some GNOME packages were inadvertently bumped to 45-alpha early, as the changes were checked into git but had not been built; this caused dependency issues, then when we tried building the remaining packages at version 45-alpha to see if things would work OK with a consistent set of packages, we found a bug which made the tests fail and necessitated untagging everything back to 44: https://gitlab.gnome.org/GNOME/mutter/-/issues/2918 . 2. The rebuilt PackageKit was broken because of a change in glib, and needed a backport of https://github.com/PackageKit/PackageKit/pull/643 to work properly again. These were complicated by a third problem showing up in the middle: a new build of brltty had some internal dependency issues, and needed to be untagged. All of these issues caused test failures for *every* Rawhide update tested after the mass rebuild was merged (in the first case) or the brltty update landed (in the third case). It took several hours to get them all unpicked and the fixed PackageKit landed, then I re-scheduled the failed tests on all other updates (but I did this a bit wrong for some of them, so they failed again, and I had to re-run them again an hour or so ago). I'm also fighting a bit with Koji giving 404 responses for the f39- build repo more often than it usually does, but I hope to have tests for all updates passing (assuming the update itself has no problems) within the next hour or two. For the next go-round, it might be good to use the relatively new ability we have to schedule openQA tests on a side tag to test the mass rebuild *before* it's merged, I'll check with releng if that is feasible. This is also the second or third time gating has been disrupted by a broken update that wasn't in the critical path and so didn't go through gating itself. I'm considering rejigging the critpath/bodhi/greenwave/openqa industrial complex (again) so we also/instead test everything that goes into the environments openQA tests (Server, Workstation, and KDE), even if it's not "important" in itself. Bad deps in *anything* in the environment can break the tests because they prevent `dnf update` from succeeding at all, so the updated packages never get installed (I actually think dnf-5 may be being more 'strict' than dnf here, too, and exposing problems that were previously not causing test failures, but I'd have to check that). This would be some fairly major surgery, though (and increase the load on openQA). -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@fosstodon.org https://www.happyassassin.net

1 0

2023-07-24 @ 15:00 UTC - Fedora QA Meeting
by Adam Williamson 24 Jul '23

24 Jul '23

# Fedora Quality Assurance Meeting # Date: 2023-07-24 # Time: 15:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.libera.chat Greetings testers! We didn't meet for some time due to travel and holidays and suchlike, apologies for that. Let's get back on track tomorrow! If anyone has any other items for the agenda, please reply to this email and suggest them! Thanks. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 39 status 3. Flock plans 4. Test Day / community event status 5. Open floor -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@fosstodon.org https://www.happyassassin.net

2 1

dnf5 What replaces repomanage?
by Robert McBroom 22 Jul '23

22 Jul '23

keep local repo of rpm to use on multiple machines. Use the command dnf repomanage --old . |xargs rm -rf to clear rpms that have been updated. The plugin repomanage does not seem to be in dnf5. Is there a replacement that I don't see?

1 0

PROPOSAL to remove Modularity tests from openQA
by Lukas Ruzicka 20 Jul '23

20 Jul '23

Hello, based on this ( https://pagure.io/fedora-comps/c/38890fd54281a3dc2dd64439de8955637ca6f2a7?b…) I am proposing to put the Modularity tests on hold for some time (modular features are currently not supported in DNF5 anyway) and potentially remove them from openQA. -- 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>

3 5

Kernel 6.4.3 is now available for testing in koji
by Sumantro Mukherjee 16 Jul '23

16 Jul '23

Hey Folks, We are currently running the Fedora Kernel Test Week before we rebase 6.4. There is a new build 6.4.3 is fresh and you can now provide feedback! Thanks a lot to all for making the test weeks so successful. The links for test weeks can be found here[0]. Results can be submitted here[1] and the new build is [2] Happy Testing! [0] http://fedoraproject.org/wiki/Test_Day:2023-07-09_Kernel_6.4_Test_Week [1] https://testdays.fedoraproject.org/events/160 [2] https://koji.fedoraproject.org/koji/buildinfo?buildID=2230199 -- //sumantro Fedora QE TRIED AND PERSONALLY TESTED, ERGO TRUSTED

3 3

Rawhide ~ kernel-6.5.0 doesn't allow VirtualBox shared folders
by Ian Laurie 14 Jul '23

14 Jul '23

I'm not able to mount VirtualBox shared folders in Rawhide since kernel-6.5 began. Works fine up to kernel-6.4.0-59.fc39.x86_64. My mount commands look like this: sudo mount -t vboxsf -o rw,uid=$UID,gid=$(id -g) share_name local_mnt Is this a bug, or am I doing something wrong for 6.5? Ian -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney

2 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

test July 2023