Heads up: another F39 compose is incoming
by Adam Williamson
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(a)fosstodon.org
https://www.happyassassin.net
1 month, 1 week
F39 candidate composes coming - here's the plan
by Adam Williamson
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(a)fosstodon.org
https://www.happyassassin.net
1 month, 2 weeks
Self-introduction: Osama Albahrani
by Osama Albahrani
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-nam...
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=group...
(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 month, 2 weeks
Fedora Linux 39 Final blocker status summary #3
by Adam Williamson
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(a)fosstodon.org
https://www.happyassassin.net
1 month, 2 weeks
Self-Presentation Niccolo' to QA Team
by Niccolò Zuccolo
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
1 month, 2 weeks
F39-beta Live OS: Mouse stops working after changing Display
Orientation in Settings.
by Rob Lahaye
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.
1 month, 2 weeks
Some apps are opening in transparent windows after recent dnf update.
(Mostly apps which does not use wayland windowing system)
by Neil Chetty
I have disabled fractional scaling and i use 200 percent as default scaling option.
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.or...
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
1 month, 2 weeks
[Fedora Rawhide][x86 MacBook] Can’t boot after dnf system-upgrade 39 to Rawhide
by Osama Albahrani
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
1 month, 2 weeks
Session defaults to X11 after reboot in the 39 beta.
by Scott Lembcke
So I just put a fresh install of the F39 beta on a Ryzen 7840U laptop (Framework 14). Everything is up to date as of Oct 20th.
The issue: after booting the laptop and logging in, it defaults to an X11 session even though "Gnome" is selected from the gear menu in the lower right. To get a Wayland session, all I need to do is log out and immediately log back in. It only seems to do this after a fresh boot.
I don't know enough about GDM to debug this any further and make a proper bug report. Is there a particular log file I should look into?
1 month, 3 weeks
