test October 2023

test@lists.fedoraproject.org

25 participants
29 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

Heads up: another F39 compose is incoming
by Adam Williamson 31 Oct '23

31 Oct '23

Hey folks! Just a heads up - a new F39 candidate will be appearing in a few hours. The main difference to RC-1.4 is that it will include Firefox 119 to address an important CVE - https://bugzilla.redhat.com/show_bug.cgi?id=2247311 . We've also taken the opportunity to tweak things a bit in releng to try and fix some images that failed the RC-1.4 compose, especially Kinoite and Silverblue on aarch64 and ppc64le. Most RC-1.4 results should remain valid for the new compose, of course as much testing as we can do on it would be great. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@fosstodon.org https://www.happyassassin.net

1 0

F39 candidate composes coming - here's the plan
by Adam Williamson 26 Oct '23

26 Oct '23

Hey folks! Just to keep everyone in the loop regarding F39 plans. As you may have noticed, we've slipped once or twice already (depending on whether you count the "early target date") and are in danger of slipping again. The go/no-go meeting is scheduled for tomorrow (2023- 10-26). The outstanding blockers are all Raspberry Pi-related, aside from the shim one we've been waiving for several releases and intend to waive again. Matthew Miller, Kevin Fenzi and I came up with this plan: we're going to run a compose right now without fixes for the two outstanding Pi blockers (2241252 and 2244305). If QA can get sufficient testing on this done by the go/no-go meeting, we can discuss the possibility of shipping it and noting that there are known issues with Raspberry Pi that are taking time to resolve, and Pi users should not install or upgrade to F39 until they're resolved (or something like that). If at any point a fix for 2241252 shows up, we'll run another compose with the fix included. If that gets sufficient testing by the time of the meeting, we can also consider that as a candidate to ship. If ARM team decide to attempt a fix for 2244305 we'd also pull that in, but if not, we think it's reasonable to consider revoting or waiving that bug, as it seems not to happen very commonly or consistently and the proposed "fix" apparently comes with tradeoffs of some kind. So, QA folks, please stand ready to test one or two candidate composes soon. If we wind up with two, we will consider most test results to apply to both, as the only difference should be uboot-tools; we would want to run ARM hardware tests, at least, on both composes if possible. The usual announcement mails will be sent for the completed composes. Thanks folks! -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@fosstodon.org https://www.happyassassin.net

1 1

Re: Fedora Linux 39 Final blocker status summary #3
by Adam Williamson 26 Oct '23

26 Oct '23

On Wed, 2023-10-25 at 22:02 +0000, Zbigniew Jędrzejewski-Szmek wrote: > On Fri, Oct 20, 2023 at 04:55:57PM -0700, Adam Williamson wrote: > > 6. distribution - https://bugzilla.redhat.com/2242759 - NEW: anyone at > > all to come up with a genius fix, otherwise we'll likely have to > > document this > > Happy to oblige ;--] Genius located! Thanks, Zbigniew :) -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@fosstodon.org https://www.happyassassin.net

2 2

Self-introduction: Osama Albahrani
by Osama Albahrani 26 Oct '23

26 Oct '23

Hello everyone, I am in my last year as a Computer Science undergraduate student as North Carolina State University and the Treasurer of the Linux Users' Group at NC State. And I am from Saudi Arabia. I have some experience with the command line through a couple classes I've taken and using different Linux distros on my free time through dual booting and using containers. At school, I liked learning C and operating systems, and developed an interest in how operating systems work and how they compare to one another. I am also interested performance and optimizations and how software can better communicate with the hardware. I look forward to learning more about package management and becoming a maintainer as well as learning how to write kernel code in the near future. So, I would like to be more involved and help with Fedora testing! I wanted to mark that I was able to successfully perform https://fedoraproject.org/wiki/QA:Testcase_dualboot_with_macOS using the Fedora 39 rc 1.1 but not sure how. Here is what I tried so far: $ relval report-results /usr/lib/python3.12/site-packages/pkg_resources/__init__.py:121: DeprecationWarning: pkg_resources is deprecated as an API warnings.warn("pkg_resources is deprecated as an API", DeprecationWarning) /usr/lib/python3.12/site-packages/pkg_resources/__init__.py:2870: DeprecationWarning: Deprecated call to `pkg_resources.declare_namespace('paste')`. Implementing implicit namespace packages (as specified in PEP 420) is preferred to `pkg_resources.declare_namespace`. See https://setuptools.pypa.io/en/latest/references/keywords.html#keyword-names… declare_namespace(pkg) Traceback (most recent call last): File "/usr/bin/relval", line 8, in <module> sys.exit(main()) ^^^^^^ File "/usr/lib/python3.12/site-packages/relval/cli.py", line 815, in main args, site = parse_args() ^^^^^^^^^^^^ File "/usr/lib/python3.12/site-packages/relval/cli.py", line 390, in parse_args site = setup_site(args) ^^^^^^^^^^^^^^^^ File "/usr/lib/python3.12/site-packages/relval/cli.py", line 85, in setup_site site.login() File "/usr/lib/python3.12/site-packages/wikitcms/wiki.py", line 338, in login self.site_init() File "/usr/lib/python3.12/site-packages/mwclient/client.py", line 142, in site_init info = self.get('query', meta='userinfo', uiprop='groups|rights') ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3.12/site-packages/mwclient/client.py", line 234, in get return self.api(action, 'GET', *args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3.12/site-packages/mwclient/client.py", line 285, in api info = self.raw_api(action, http_method, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3.12/site-packages/mwclient/client.py", line 437, in raw_api res = self.raw_call('api', data, retry_on_error=retry_on_error, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3.12/site-packages/mwclient/client.py", line 409, in raw_call stream.raise_for_status() File "/usr/lib/python3.12/site-packages/requests/models.py", line 1021, in raise_for_status raise HTTPError(http_error_msg, response=self) requests.exceptions.HTTPError: 401 Client Error: Unauthorized for url: https://fedoraproject.org/w/api.php?meta=userinfo%7Cuserinfo&uiprop=groups%… (I also tried to manually edit https://fedoraproject.org/wiki/Test_Results:Fedora_39_RC_1.1_Desktop but I get the "your account must have at least one non cla* group to be able to login and edit" message) Best, Osama Albahrani

1 0

Fedora Linux 39 Final blocker status summary #3
by Adam Williamson 26 Oct '23

26 Oct '23

Hi folks! We're still trying to get F39 done, so time for another status update... Action summary ============== Accepted blockers ----------------- 1. kexec-tools - https://bugzilla.redhat.com/2243068 - VERIFIED: releng to push the fix stable 2. mutter - https://bugzilla.redhat.com/2241632 - ASSIGNED: desktop team (and adamwill) to keep trying to come up with a fix 3. shim - https://bugzilla.redhat.com/2113005 - NEW: assume this will be waived 4. uboot-tools - https://bugzilla.redhat.com/2241252 - ASSIGNED: ARM team (pbrobinson) to fix it 5. uboot-tools - https://bugzilla.redhat.com/2244305 - ASSIGNED: ARM team to evaluate and fix if possible, ARM/QA to test on more systems if possible 6. distribution - https://bugzilla.redhat.com/2242759 - NEW: anyone at all to come up with a genius fix, otherwise we'll likely have to document this Bug-by-bug detail ================= Accepted blockers ----------------- 1. kexec-tools - https://bugzilla.redhat.com/2243068 - VERIFIED kdump is enabled by default on desktops This is basically fixed, just waiting to be pushed stable. 2. mutter - https://bugzilla.redhat.com/2241632 - ASSIGNED Netinstall ISO renders a black screen when using kickstart install (bare metal and VM) Well, we kinda had a fix for this, but it turns out to break something even worse (now anaconda isn't visible on the Workstation live image). So we're still stuck trying to find a perfect fix, unfortunately. Desktop team plus me to keep cranking away on it. 3. shim - https://bugzilla.redhat.com/2113005 - NEW Live image made with BOOTX64.EFI from latest shim-x64-15.6-2 fails to boot on some boards Let's just assume this is gonna be waived. 4. uboot-tools - https://bugzilla.redhat.com/2241252 - ASSIGNED Fedora-Workstation-39_Beta-1.1 boots to a black screen on Raspberry Pi 4 Peter says "So we've basically got to the bottom of the problem and worked out the issue, I now just need to come up with a fix.", so that's what we're waiting on. 5. uboot-tools - https://bugzilla.redhat.com/2244305 - ASSIGNED Fedora Server 39 does not boot on Raspberry Pi 4 (RPi4) from microSD card slot This one's also waiting on ARM team (i.e. Peter), but seems somewhat less clear-cut of a blocker, so we're kinda waiting for his take on that, plus testing from other Raspberry Pi owners would be useful. 6. distribution - https://bugzilla.redhat.com/2242759 - NEW dnf system-upgrade fails on some RPi4 due to system boot date that pre- dates gpg key We're still kinda kicking around ideas for "fixing" this, but I think if push comes to shove, we'll wind up revoting or waiving it as not practically fixable. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@fosstodon.org https://www.happyassassin.net

2 1

Self-Presentation Niccolo' to QA Team
by Niccolò Zuccolo 24 Oct '23

24 Oct '23

Hello Fedora QA Team Members, My name is Niccolo' and it is my pleasure to introduce myself as a new member interested in contributing to your Quality Assurance team. Fedora is a community and project that I have long admired, and I am eager to put my skills and passion at your service. In the past, I have worked in the supercomputing field as an IT supporter and have had several experiences with linux and server/clients operating systems. I have always enjoyed the operating system and the Fedora Philosophy. Although I do not have much direct experience in the field of Quality Assurance, I am eager to learn and apply my skills. Kind regards, Niccolo' Zuccolo

2 1

F39-beta Live OS: Mouse stops working after changing Display Orientation in Settings.
by Rob Lahaye 24 Oct '23

24 Oct '23

Hi, I start the Live OS of F39 (Fedora-Workstation-Live-x86_64-39_Beta-1.1.iso) on a system that requires a display orientation of "Portrait Right". As soon as I change the display orientation, the mouse stops working. When I do the same with the Live OS of Fedora 38, all works fine. Hence, I consider this an F39 beta bug. -RL.

3 2

Some apps are opening in transparent windows after recent dnf update. (Mostly apps which does not use wayland windowing system)
by Neil Chetty 21 Oct '23

21 Oct '23

I have disabled fractional scaling and i use 200 percent as default scaling option. https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/… After a recent dnf update which updated following packages. Whenever i open apps all jetbrain products, spotify, edge etc. they open in a transparent window. ( https://ibb.co/X38kqV7 ) Please see this image. i assume it is related to wayland and xorg windowing system. Please tell if any fix exists Transaction ID : 157 Begin time : Saturday 21 October 2023 12:09:35 PM Begin rpmdb : 4682356a9b494d842210beaf50bb32a58b9ad5c5228151f75445e6741707d8b1 End time : Saturday 21 October 2023 12:10:20 PM (45 seconds) End rpmdb : e9996776d61d752c88bb9ec8060f7e5bfbfc0278467cb7a88b1d9d089528c894 User : Super User <root> Return-Code : Success Releasever : Command Line : Comment : Packages Altered: Install kernel-6.5.8-300.fc39.x86_64 @updates-testing Install kernel-core-6.5.8-300.fc39.x86_64 @updates-testing Install kernel-modules-6.5.8-300.fc39.x86_64 @updates-testing Install kernel-modules-core-6.5.8-300.fc39.x86_64 @updates-testing Install kernel-modules-extra-6.5.8-300.fc39.x86_64 @updates-testing Upgrade glibc-2.38-9.fc39.i686 @updates-testing Upgrade glibc-2.38-9.fc39.x86_64 @updates-testing Upgrade glibc-all-langpacks-2.38-9.fc39.x86_64 @updates-testing Upgrade glibc-common-2.38-9.fc39.x86_64 @updates-testing Upgrade glibc-devel-2.38-9.fc39.x86_64 @updates-testing Upgrade glibc-gconv-extra-2.38-9.fc39.i686 @updates-testing Upgrade glibc-gconv-extra-2.38-9.fc39.x86_64 @updates-testing Upgrade glibc-headers-x86-2.38-9.fc39.noarch @updates-testing Upgrade glibc-langpack-en-2.38-9.fc39.x86_64 @updates-testing Upgrade libnsl-2.38-9.fc39.i686 @updates-testing Upgrade libnsl-2.38-9.fc39.x86_64 @updates-testing Upgrade mutter-45.0-10.fc39.x86_64 @updates-testing Upgrade mutter-common-45.0-10.fc39.noarch @updates-testing Upgrade ostree-2023.7-2.fc39.x86_64 @updates-testing Upgrade ostree-libs-2023.7-2.fc39.x86_64 @updates-testing Upgrade pam-1.5.3-3.fc39.x86_64 @updates-testing Upgrade pam-libs-1.5.3-3.fc39.x86_64 @updates-testing Upgrade rclone-1.64.2-1.fc39.x86_64 @updates-testing Upgraded kernel-6.5.5-300.fc39.x86_64 @@System Upgraded kernel-core-6.5.5-300.fc39.x86_64 @@System Upgraded kernel-modules-6.5.5-300.fc39.x86_64 @@System Upgraded kernel-modules-core-6.5.5-300.fc39.x86_64 @@System Upgraded kernel-modules-extra-6.5.5-300.fc39.x86_64 @@System Upgraded glibc-2.38-7.fc39.i686 @@System Upgraded glibc-2.38-7.fc39.x86_64 @@System Upgraded glibc-all-langpacks-2.38-7.fc39.x86_64 @@System Upgraded glibc-common-2.38-7.fc39.x86_64 @@System Upgraded glibc-devel-2.38-7.fc39.x86_64 @@System Upgraded glibc-gconv-extra-2.38-7.fc39.i686 @@System Upgraded glibc-gconv-extra-2.38-7.fc39.x86_64 @@System Upgraded glibc-headers-x86-2.38-7.fc39.noarch @@System Upgraded glibc-langpack-en-2.38-7.fc39.x86_64 @@System Upgraded libnsl-2.38-7.fc39.i686 @@System Upgraded libnsl-2.38-7.fc39.x86_64 @@System Upgraded mutter-45.0-9.fc39.x86_64 @@System Upgraded mutter-common-45.0-9.fc39.noarch @@System Upgraded ostree-2023.6-1.fc39.x86_64 @@System Upgraded ostree-libs-2023.6-1.fc39.x86_64 @@System Upgraded pam-1.5.3-2.fc39.x86_64 @@System Upgraded pam-libs-1.5.3-2.fc39.x86_64 @@System Upgraded rclone-1.64.0-1.fc39.x86_64 @@System

2 3

[Fedora Rawhide][x86 MacBook] Can’t boot after dnf system-upgrade 39 to Rawhide
by Osama Albahrani 21 Oct '23

21 Oct '23

Hi! I wanted to test Fedora Rawhide so I ran `dnf system-upgrade download --releasever rawhide --exclude=sdubby` (as per https://bugzilla.redhat.com/show_bug.cgi?id=2243872#c12) to upgrade from Fedora 39 and it finished successfully. However after I ran `dnf system-upgrade reboot` and got a black screen after the system upgrade progress bar. And I can no longer boot into the Fedora partition and only get a black screen. Before that, I was able to use Fedora 39 alongside macOS just fine. Has anyone been able to run Rawhide on an x86 MacBook Pro (2016) or a similar x86 Mac* device? And what can I do to further investigate the boot issue? Note: I noticed that after the upgrade, the name in the mac boot menu changed from “Fedora” to “UEFI Boot” and the symbol is still the Fedora logo, not sure what this means. So could it be the efibootmgr-related bug that was recently fixed in the Fedora 39 nightly ISO ( https://bugzilla.redhat.com/show_bug.cgi?id=2239316)? Note 2: I also couldn't go past the initial menu when I used the Fedora Rawhide ISO a few days ago (around Oct 10 iirc), not sure if this is related. Best, Osama

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

test October 2023