test September 2023

test@lists.fedoraproject.org

23 participants
30 discussions

Fedora Linux 39 Beta is GO
by Adam Williamson 14 Sep '23

14 Sep '23

The Fedora Linux 39 Beta-1.1 compose is GO and will be shipped live on Tuesday, 19 September 2023. For more information please check the Go/No-Go meeting minutes[1] or log[2]. [1] https://meetbot.fedoraproject.org/fedora-meeting/2023-09-14/f39-beta-go_no_… [2] https://meetbot.fedoraproject.org/fedora-meeting/2023-09-14/f39-beta-go_no_… -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@fosstodon.org https://www.happyassassin.net

1 0

[Now Playing] Toolbx Test Day 2023-09-14
by Sumantro Mukherjee 14 Sep '23

14 Sep '23

Hey Folks, Toolbx as a blocker for Fedora Workstation was declared as part of Fedora Linux 39 changes process. The idea for test week is for testers is to install latest version of Toolbx and install Fedora and any other OS as well. The wiki[0] has all the necessary details. Come join us and make Fedora better! [0] https://fedoraproject.org/wiki/Test_Day:2023-09-14_Toolbx -- //sumantro Fedora QE TRIED AND PERSONALLY TESTED, ERGO TRUSTED

3 2

Fedora Linux 38 Beta Go/No-Go meeting today (2023-09-14)
by Adam Williamson 14 Sep '23

14 Sep '23

The Fedora Linux 39 Beta Go/No-Go[1] meeting is scheduled for Thursday 14 September at 1700 UTC in #fedora-meeting on libera.chat[2]. At this time, we will determine the status of the F39 Beta for the 19 September target date #1[3]. For more information about the Go/No-Go meeting, see the wiki[4]. Please note the IRC<->Matrix bridge is down at present, so you must join IRC to attend the meeting, using a native client or the webchat link below. [1] https://calendar.fedoraproject.org/meeting/10583/ [2] https://web.libera.chat/#fedora-meeting [3] https://fedorapeople.org/groups/schedule/f-39/f-39-key-tasks.html [4] https://fedoraproject.org/wiki/Go_No_Go_Meeting -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@fosstodon.org https://www.happyassassin.net

1 0

Is this number ok?
by Alessio 12 Sep '23

12 Sep '23

I know about this accepted change: https://fedoraproject.org/wiki/Changes/Color_Bash_Prompt But what is this number that appears time to time in the prompt? user@host:~$ ^C user@host:~130$ ^C user@host:~$ foo bash: foo: command not found user@host:~127$ An exit code I suppose? Ciao, A.

2 1

Fedora Linux 39 Beta blocker status summary #1
by Adam Williamson 10 Sep '23

10 Sep '23

Hi folks! Sorry for not sending these sooner, but better late than never: here's a blocker bug status summary for Fedora 39. We're currently targeting a go/no-go meeting this Thursday (September 14) and release the following Tuesday (September 19). Action summary ============== Accepted blockers ----------------- 1. anaconda - webUI: cannot install to encrypted software RAID partition - POST: anaconda team to send new release/build 2. kernel - /dev/tpm* is missing with new kernels - VERIFIED: releng and I to push the fix stable 3. shim - Live image made with BOOTX64.EFI from latest shim-x64-15.6-2 fails to boot on some boards - NEW: likely waive again at go/no-go Proposed blockers ----------------- 1. anaconda - Anaconda webUI can't handle two volumes with the same LABEL, writes into a different partition than indicated - NEW: anaconda team to investigate and fix 2. edk2 - Fedora 39 fails to boot on qemu VM using OVMF_CODE.secboot.fd firmware - NEW: QA to isolate the bug more precisely, kraxel to investigate and fix 3. fedora-repos - updates-testing is not enabled when it should be - VERIFIED: releng and I to push the fix stable 4. python-blivet - blivet-gui creates different volumes with the same name, confusing anaconda webUI - ASSIGNED: blivet team to investigate and fix Bug-by-bug detail ================= Accepted blockers ----------------- 1. anaconda - webUI: cannot install to encrypted software RAID partition - POST There is a fix for this which has been verified. We need a new anaconda build with it included (anaconda team). 2. kernel - /dev/tpm* is missing with new kernels - VERIFIED This just needs to be pushed to stable (me and releng). 3. shim - Live image made with BOOTX64.EFI from latest shim-x64-15.6-2 fails to boot on some boards - NEW It seems that, unfortunately, we may have to waive this *again*. There is definite movement upstream but it probably hasn't moved far enough to let us fix it for Beta. We're hoping to finally have this resolved for Final. Proposed blockers ----------------- 1. anaconda - Anaconda webUI can't handle two volumes with the same LABEL, writes into a different partition than indicated - NEW It's possible to have multiple btrfs volumes with the same label, which confuses anaconda/blivet and can result in data getting written to a different place than indicated. Seems likely to be accepted as a blocker, we need anaconda/blivet folks to look at fixing this (anaconda team). 2. edk2 - Fedora 39 fails to boot on qemu VM using OVMF_CODE.secboot.fd firmware - NEW This was initially filed and proposed on the basis that VM boot didn't work at all, but then we discovered it was specific to the Secure Boot- enabled UEFI firmware configuration. That may not be important enough to merit blocker status, but we should definitely look into exactly what the trigger is between host and guest, and get the edk2 maintainers to look into this (kraxel). 3. fedora-repos - updates-testing is not enabled when it should be - VERIFIED It's an interesting question whether the criteria do or should cover this, but the fix is already accepted as an FE and queued for stable, so it will be pushed shortly (me and releng). 4. python-blivet - blivet-gui creates different volumes with the same name, confusing anaconda webUI - ASSIGNED This is kinda a companion to 1: not only can multiple btrfs volumes with the same label exist, but blivet actually creates them this way at present unless you explicitly set a label. There's a question whether resolving this would be enough to make 1. not a blocker, or whether we should still block on 1. because other tools could potentially create the same situation. Either way, we want blivet devs to fix this, ideally (vtrefny). -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@fosstodon.org https://www.happyassassin.net

1 0

Kernel 6.5 Test Week 2023-09-10 to 2023-09-17
by Sumantro Mukherjee 10 Sep '23

10 Sep '23

Hey All, I would like to invite all of you to participate in the Kernel 6.5 Test week is happening from 2023-09-10 to 2023-09-17. It's fairly simple, head over to the wiki [0] and read in detail about the test week and simply run the test case mentioned in[1] and enter your results. As usual, the Fedora QA team will hangout at #fedora-test-day(a)libera.chat for questions and discussion. [0] http://fedoraproject.org/wiki/Test_Day:2023-09-10_Kernel_6.5_Test_Week [1] https://testdays.fedoraproject.org/events/166 -- //sumantro Fedora QE TRIED AND PERSONALLY TESTED, ERGO TRUSTED

1 0

[PSA] Toolbx is now marked as crit-path by Workstation
by Sumantro Mukherjee 08 Sep '23

08 Sep '23

Hey All, As a part of the changeset[0] we had infra help us out with Images and QA help us out with criterion [1] and OpenQA test[2]. As a final step, we have finally added Toolbx as a crit-path under "workstation" [3] . We have a Toolbx Test day on 2023-09-14 [4] , come and help us iron out any rough edges before release Thanks to Infra and Rel-eng for all the help here :) [0] https://fedoraproject.org/wiki/Changes/ToolbxReleaseBlocker [1] https://fedoraproject.org/wiki/Fedora_39_Beta_Release_Criteria#Toolbx_Funct… [2] https://pagure.io/fedora-qa/os-autoinst-distri-fedora/blob/main/f/tests/too… [3] https://pagure.io/fedora-comps/pull-request/885 [4] https://testdays.fedoraproject.org/events/167 -- //sumantro Fedora QE TRIED AND PERSONALLY TESTED, ERGO TRUSTED

1 0

F38: GNOME on XORG: Some apps have Windows titlebar with Minimize/Maximize Buttons
by Dario Lesca 07 Sep '23

07 Sep '23

I use "GNOME on Xorgs", today I have try to update f38 to f39. Like occur on F38, also into f39 some apps, like Firefox or Libreoffice, have top bar size different from gnome native apps like gnome-terminal or nautilus. Also the Middle-Click mouse button set to "lower" click on top bar do not work on the apps with different top bar You can try this problem also use the last F39 Workstation live version (Fedora-Workstation-Live-x86_64-39-20230907.n.0.iso), if you set password to liveuser then logoff and logon with "GNOME on Xorgs" you can see this problem. If you use default GNOME on Wayland, lower function work on all top bar type I have also fill this bug: https://bugzilla.redhat.com/show_bug.cgi?id=2192180 See also In GNOME 44, window top bar doesn't work properly under Xorg https://www.reddit.com/r/gnome/comments/12ubuya/in_gnome_44_window_top_bar_… There is a workaround to resolve this annoying issue? Many thanks -- Dario Lesca (Inviato dal mio Linux Fedora 38 Workstation) _______________________________________________ users mailing list -- users(a)lists.fedoraproject.org To unsubscribe send an email to users-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/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- Dario Lesca (Inviato dal mio Linux Fedora 38 Workstation)

1 0

freeze exceptions for FTI bugs
by Kamil Paral 05 Sep '23

05 Sep '23

Lately we've seen a surge of FTI (fails to install) bugs being proposed as freeze exceptions [1] [2]. We generally grant them, because we want the base repo to be in a consistent and buildable state. However, I wonder, isn't this approach mostly relevant for the Final release? Does it make sense to also have this approach for Beta? The reason why I'm thinking about this is because of course there's some work connected with granting and processing these freeze exceptions (FEs). But at the same time, updates-testing is enabled by default, so users can get the fixed versions immediately, and the fixes can be pushed stable right after the Beta freeze is over. Is the extra FE-related work justified? One reason I can think of is when the package A in question needs to be used for rebuilding/installing another package B. In that case, if package A is not pushed stable, you can't prepare an update for package B into updates-testing (or can you? Can you build several inter-connected packages together and make a Bodhi update for them? What if you have access rights to just package B but not A?). I do understand that in this case waiting until the freeze lifts might be inconvenient. What if we granted FEs for Beta just in these justified cases but not in general, in order to decrease the processing-work? Is that a good/bad idea? Or perhaps we can grant FTI FEs automatically? Either always, or in some cases? What are your thoughts on this? Thanks, Kamil [1] https://qa.fedoraproject.org/blockerbugs/milestone/39/beta/buglist [2] https://pagure.io/fedora-qa/blocker-review/issues?status=all&search_pattern…

4 7

Re: Donate 1 minute of your time to test upgrades from F38 to F39
by Luna Jernberg 04 Sep '23

04 Sep '23

Did this on my Thinkpad Edge a couple of days ago, and it went fine :) Den ons 23 aug. 2023 kl 20:23 skrev Miroslav Suchý <msuchy(a)redhat.com>: > > Do you want to make Fedora 39 better? Please spend 1 minute of your time and try to run: > > # Run this only if you use default Fedora modules > # next time you run any DNF command default modules will be enabled again > sudo dnf module reset '*' > > dnf --releasever=39 --setopt=module_platform_id=platform:f39 \ > --enablerepo=updates-testing \ > $(rpm -q fedora-repos-modular >/dev/null && echo --enablerepo=updates-testing-modular) \ > --assumeno distro-sync > > > This command does not replace `dnf system-upgrade`, but it will reveal potential problems. > > You may also run `dnf upgrade` before running this command. > > > The `--assumeno` will just test the transaction, but does not make the actual upgrade. > > > In case you hit dependency issues, please report it against the appropriate package. > > Or against fedora-obsolete-packages if that package should be removed in Fedora 39. Please check existing reports against fedora-obsolete-packages first: > > https://red.ht/2kuBDPu > > and also there is already bunch of "Fails to install" (F39FailsToInstall) reports: > > https://bugzilla.redhat.com/buglist.cgi?bug_id=2168845&bug_id_type=anddepen… > > > Two notes: > > * you may want to run the same command with dnf5 to help test new dnf. > > * this command found zero issues on my personal system - great work all everybody! > > > Thank you > > Miroslav > _______________________________________________ > 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 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

test September 2023