test August 2023

test@lists.fedoraproject.org

11 participants
21 discussions

Post 38 to 39 upgrade cannot launch QEMU/KVM VMs via virt-manager
by Ian Laurie 19 Aug '23

19 Aug '23

I upgraded a 38 workstation/server from 38 to 39. The only casualty so far seems to be that virt-manager can no longer launch VMs. Trying to do so results in this: ============================================ Error starting domain: Failed to connect socket to '/var/run/libvirt/virtnetworkd-sock': No such file or directory Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/asyncjob.py", line 72, in cb_wrapper callback(asyncjob, *args, **kwargs) File "/usr/share/virt-manager/virtManager/asyncjob.py", line 108, in tmpcb callback(*args, **kwargs) File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 57, in newfn ret = fn(self, *args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/share/virt-manager/virtManager/object/domain.py", line 1402, in startup self._backend.create() File "/usr/lib64/python3.12/site-packages/libvirt.py", line 1373, in create raise libvirtError('virDomainCreate() failed') libvirt.libvirtError: Failed to connect socket to '/var/run/libvirt/virtnetworkd-sock': No such file or directory ============================================ Can anyone offer some insight before I create a BZ for this? I suspect it is an upgrade issue maybe? Thanks, Ian -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney

2 4

Preliminary Fedora Workstation Live image with installer Web UI
by Martin Kolman 17 Aug '23

17 Aug '23

Hi! As the final switch of the Fedora Workstation Live image to using the new Anaconda Web UI by default[0] draws closer, we now have finally most of the building blocks in place & have created a test image, that should represent quite well how the actual Workstation Live image will look like after the switch: https://fedorapeople.org/groups/anaconda/webui/temp/Fedora-Workstation_GIS.… The installation flow is quite different from how it was on <=F38: - the image boots into a Gnome Initial Setup running in a minimal Gnome Shell session[1] - this GIS will ask the user to select language and keyboard, then provides an option to either install Fedora or try the Fedora desktop - if the Install option is selected, the Anaconda Web UI will be started - if the "try desktop" option is selected, the selected keyboard and language should be used for the desktop (on this image, only keyboard is used for some reason) - using the Web UI, the user can configure partitioning & Fedora will be installed on the target system afterwards - quitting the installer after successful installation will reboot the Live environment to the new system - then Gnome Initial setup will start again, as usual during regular Fedora Workstation installations - it will asks user to configure the remaining bits, like user, timezone or online accounts - it will also ask again for language & keyboard - this is a known issue in process of being fixed Some testing of this image will be much appreciated! :) Issues that are identified & fixed thanks to this can hopefully make the transition & overall F39 release into a smoother ride. :) Please fill any issues you spot into Bugzilla, under the regular Fedora product and anaconda component & mark you new bugs as blocking on bug 2231339. Bug 2231339[2] is the main tracking bug for the F39 WebUI effort & marking any relevant bugs as blocking on this bug will help us keep track of them. You can also check the bugs blocking the tracker bugs to see if your issue has perhaps been already reported. Thanks in advance & looking forward to your bug reports and general feedback. :) Best Wishes Martin Kolman [0] https://fedoraproject.org/wiki/Changes/AnacondaWebUIforFedoraWorkstation [1] https://pagure.io/fedora-workstation/issue/362 [2] https://bugzilla.redhat.com/show_bug.cgi?id=2231339

2 1

DNF 5 Test Week starts today!
by Sumantro Mukherjee 17 Aug '23

17 Aug '23

Hey Folks, DNF 5 landed in rawhide sometime back and has now been taken off F39 schedule. DNF 5 awaits testing and feedback before it can be considered stable for Fedora users. DNF and Fedora Quality are hosting a week-long testing period from Friday, August 11th through Thursday, August 17th. The wiki[0] contains all information and the results can be submitted by the test days app[1] [0] http://fedoraproject.org/wiki/Test_Day:2023-08-11_Fedora_39_DNF_5 [1] https://testdays.fedoraproject.org/events/163 Happy Testing! -- //sumantro Fedora QE TRIED AND PERSONALLY TESTED, ERGO TRUSTED

3 6

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

Podman issue might be breaking toolbx anytime now
by Sumantro Mukherjee 16 Aug '23

16 Aug '23

Hey Folks! This is to flag that there is an issue in Podman [0] which will break Toolbx's basic functionality in F37 and F38. Toolbx is currently release blocking and is a part of FCOS and Workstation ISO. We are tracking the issue in [0] and request folks to test updates when fixes are available. [0] https://github.com/containers/podman/issues/19634 -- //sumantro Fedora QE TRIED AND PERSONALLY TESTED, ERGO TRUSTED

1 0

Failing jobs for Rawhide (and F39?) in Fedora CI due to use of old mock configs
by Adam Williamson 12 Aug '23

12 Aug '23

I've seen several folks report that jobs (usually scratch build tests) are failing in Fedora CI, e.g. this one: https://osci-jenkins-1.ci.fedoraproject.org/job/fedora-ci/job/dist-git-buil… the failures all seem to have a common cause. You'll note these lines: DEBUG: The GPG keys listed for the "fedora" repository are already installed but they are not correct for this package. DEBUG: Check that the correct key URLs are configured for this repository.. Failing package is: curl-8.2.1-2.fc40.x86_64 DEBUG: GPG Keys are configured as: file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-39-primary, file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-39-primary, file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-38-primary DEBUG: Public key for fedora-gpg-keys-40-0.1.noarch.rpm is not installed. Failing package is: fedora-gpg-keys-40-0.1.noarch ...for several packages. If you look carefully, you'll see it's using the wrong GPG keys: it's using the keys for F38 and F39, trying to validate a package from Rawhide. Obviously that will fail. This is happening because CI is running EL 8, and the EPEL 8 mock/mock- core-configs update for F39 branching is not yet stable: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-a5c155a6c0 the current stable mock-core-configs for EPEL 8 still thinks Rawhide is F39, so that's why it tries to use the F39 and F38 GPG keys to validate Rawhide packages. It needs the newer version of mock-core-configs that knows Rawhide is now F40. I've tried pinging CI folks about this to see if they can pull mock in from updates-testing, but so far no response. I guess it would help if folks running EPEL 8 can test mock, confirm it works, and up-karma the update. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@fosstodon.org https://www.happyassassin.net

1 0

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

DNF5 is in a bad state.
by Onyeibo 09 Aug '23

09 Aug '23

Good Morning I ran an update on a second rawhide machine of mine (DNF5 broke the other one and I have not reinstalled Fedora there). After this last update, I get the following behaviour when I attempt another update: # dnf update bash: /usr/bin/dnf: No such file or directory What I find most aggravating about DNF5 is the silence when it encounters an issue. It moves with other things, giving the impression that all is fine. It does not print any hint when it encounters an issue until it finishes. When it is done, the user discovers a huge mess. This trend is frustrating for those wishing to file a report. What do we say is wrong? Finally ... which Rawhide image is reliable these days? I might need to grab an image before I poweroff this laptop. I have little faith that this update will allow my machine to boot. Afterall, there is no telling at what stage DNF5 lost its way.

4 3

F39 Branching and update gating status
by Adam Williamson 09 Aug '23

09 Aug '23

Hey folks! Just a quick update on the state of update gating wrt Branching. First, distro-wide gating (that's gating on the openQA tests, effectively) is not currently enabled for Rawhide. This is an artifact of how gating works, but I'm leaving it that way for now as we know not all tests are passing. I'll turn it on tomorrow. Please, uh, don't submit anything broken. :D Most tests should pass on Rawhide updates, but a few will fail, this cannot be resolved till we can build branched-39 base images. Second, F39 is gated, and many update tests currently don't pass. This is known, and can't be resolved until the Branched compose is synced to the mirror system and mirror manager includes f39 entries. I was hoping to get that cleared up before going to bed but it looks like it'll have to be in the morning now. (I'm also writing a guide so others can do this in future, but it's a bit tricky as this is the first cycle where we had Rawhide gating enabled going in, which changes things a bit). If you have an F39 update that's stuck in gating, please just hang tight and I'll make sure it gets sorted tomorrow somehow. Thanks! On a related note, trying to deal with some updates that got stuck caused me to find some more bugs in Bodhi test result display and failure waiving: https://pagure.io/fedora-qa/fedora_openqa/issue/107 https://pagure.io/waiverdb/issue/431 I've written fixes for both, but didn't want to push the result reporting one out yet in case it has unexpected consequences, and the waiverdb one will have to wait on a waiverdb admin to review it. Once that is fixed, waiving failed tests that have chained dependencies should work properly. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@fosstodon.org https://www.happyassassin.net

1 0

Re: [Test-Announce] Proposal to CANCEL: 2023-08-07 Fedora QA Meeting
by Luna Jernberg 07 Aug '23

07 Aug '23

Hey Won't attend today having too much headache and needs a relax day, will try to attend next time Den sön 6 aug. 2023 kl 19:48 skrev Adam Williamson <adamwill(a)fedoraproject.org>: > > Hi folks! I'm proposing we cancel the QA meeting tomorrow. It's a > holiday in Canada and some folks may still be recovering from Flock. > If anyone thinks we should have a meeting and wants to run it instead > of me, please go ahead and send out an agenda and plan to run the > meeting - see https://fedoraproject.org/wiki/QA:SOP_IRC_meeting_process > > Thanks folks! > -- > Adam Williamson (he/him/his) > Fedora QA > Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@fosstodon.org > https://www.happyassassin.net > > > > _______________________________________________ > test-announce mailing list -- test-announce(a)lists.fedoraproject.org > To unsubscribe send an email to test-announce-leave(a)lists.fedoraproject.org > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/test-announce@lists.fedorapro… > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue > _______________________________________________ > devel mailing list -- devel(a)lists.fedoraproject.org > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

test August 2023