Re: [fedora-arm] Re: Fedora Linux 39 Final blocker status summary #3
On Wed, 2023-10-25 at 20:51 -0400, Jeffrey Walton wrote: > On Wed, Oct 25, 2023 at 7:33 PM Adam Williamson > wrote: > > > > On Wed, 2023-10-25 at 22:02 +, 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 :) > > Be careful of this solution. Time functions were formerly returning an > error until the RTC was set to an accurate time. The new behavior is > to return a fake/incorrect time without an error. I don't think it's a > good idea to misreport something time system wide without error. > > You might want to consider other ways to get beyond signature checks > that are less intrusive, and not system wide. There isn't any new behaviour. We're just doing a new systemd build for F38 so the already-existing behaviour (set the clock to the time the package was built) will give a later time than previously. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: Fedora Linux 39 Final blocker status summary #3
On Wed, 2023-10-25 at 22:02 +, 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: @ad...@fosstodon.org https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: Fedora Linux 39 Final blocker status summary #3
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 ;--] Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: Fedora Linux 39 Final blocker status summary #3
On Fri, Oct 20, 2023, 16:56 Adam Williamson wrote: > 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. How about something of the form of an ExecStartPre expression (or script) that tests the date and if less than then (say) 2023-01-01 sets the date to the expected release date of F39 (via timedatectl)? Not quite right, but it would likely pass the gpg tests It can (hopefully) be replaced by something better in the future. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: Fedora Linux 39 Final blocker status summary #3
On Sat, Oct 21, 2023 at 4:08 PM Chris Adams wrote: > Certainly - I was just looking for a more general solution to non-RTC > systems going forward. Ideally, there could be something triggered by a > lack of an RTC, but it looks like systemd path units cannot work based > on a path (e.g. /dev/rtc) _not_ existing. That's unfortunate, that > would make it easy. I believe negation works (not tested) as in: ConditionPathExists=!/dev/rtc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: Fedora Linux 39 Final blocker status summary #3
Once upon a time, Gary Buhrmaster said: > Personally, I have been using systemd-timesyncd for > quite some time on the vast majority of my systems > and am quite satisfied with it, but I believe that > changing from chrony to systemd-timesyncd was > considered too big of a last minute change since > we are in the final blocker stage of a release. Certainly - I was just looking for a more general solution to non-RTC systems going forward. Ideally, there could be something triggered by a lack of an RTC, but it looks like systemd path units cannot work based on a path (e.g. /dev/rtc) _not_ existing. That's unfortunate, that would make it easy. -- Chris Adams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: Fedora Linux 39 Final blocker status summary #3
On Sat, Oct 21, 2023 at 8:12 AM Adam Williamson wrote: > > On Sat, 2023-10-21 at 11:34 +0200, Tomasz Torcz wrote: > > On Fri, Oct 20, 2023 at 08:40:43PM -0500, Chris Adams wrote: > > > Once upon a time, Adam Williamson said: > > > > 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. > > > > > > Not adding to the ticket (because "me too" is not useful there), but... > > > I think Fedora should include SOME type of "fake hwclock"-type thing for > > > systems with no RTC (make a systemd service depend on /dev/rtc not > > > existing?), as other RPi-targeted distros do. This isn't RPi-specific, > > > a number of the small boards have no RTC. I do typically add an RTC to > > > my Pis, but not always (for various reasons). > > > > We already have systemd-timesyncd. On startup, it syncs the time to > > the mtime of: > > - /var/lib/systemd/timesync/clock file; or > > - /usr/lib/clock-epoch file; or > > - a time derived from the source tree at build time > > > > timesyncd is mentioned in the bug, but I didn't read everything. > > There are several ways we could certainly address the bug going > forward. Say, starting with a Fedora 40 Change. But it seems less clear > how we could safely fix it for upgrades from F37 or F38 to F39, without > pushing a level of change that is inappropriate for a stable release. Could we initialize the time with the timestamp of the initrd and then update the timestamp to the current time after that? That should work around this specific problem, I think? -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: Fedora Linux 39 Final blocker status summary #3
On Sat, 2023-10-21 at 11:34 +0200, Tomasz Torcz wrote: > On Fri, Oct 20, 2023 at 08:40:43PM -0500, Chris Adams wrote: > > Once upon a time, Adam Williamson said: > > > 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. > > > > Not adding to the ticket (because "me too" is not useful there), but... > > I think Fedora should include SOME type of "fake hwclock"-type thing for > > systems with no RTC (make a systemd service depend on /dev/rtc not > > existing?), as other RPi-targeted distros do. This isn't RPi-specific, > > a number of the small boards have no RTC. I do typically add an RTC to > > my Pis, but not always (for various reasons). > > We already have systemd-timesyncd. On startup, it syncs the time to > the mtime of: > - /var/lib/systemd/timesync/clock file; or > - /usr/lib/clock-epoch file; or > - a time derived from the source tree at build time > > timesyncd is mentioned in the bug, but I didn't read everything. There are several ways we could certainly address the bug going forward. Say, starting with a Fedora 40 Change. But it seems less clear how we could safely fix it for upgrades from F37 or F38 to F39, without pushing a level of change that is inappropriate for a stable release. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: Fedora Linux 39 Final blocker status summary #3
On Sat, Oct 21, 2023 at 9:35 AM Tomasz Torcz wrote: > We already have systemd-timesyncd. On startup, it syncs the time to > the mtime of: > - /var/lib/systemd/timesync/clock file; or > - /usr/lib/clock-epoch file; or > - a time derived from the source tree at build time > > timesyncd is mentioned in the bug, but I didn't read everything. Personally, I have been using systemd-timesyncd for quite some time on the vast majority of my systems and am quite satisfied with it, but I believe that changing from chrony to systemd-timesyncd was considered too big of a last minute change since we are in the final blocker stage of a release. I believe that a change proposal (for F40) to change to systemd-timesyncd, or fake-hwclock (or some other agreed upon solution) by default should be created so the non-RTC systems will work properly at future upgrades (converting existing systems from chrony to systemd-timesyncd can be complicated if the systems has modified the default chrony config or is not a (pure) client, so that may only be a longer term fix). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: Fedora Linux 39 Final blocker status summary #3
On Fri, Oct 20, 2023 at 08:40:43PM -0500, Chris Adams wrote: > Once upon a time, Adam Williamson said: > > 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. > > Not adding to the ticket (because "me too" is not useful there), but... > I think Fedora should include SOME type of "fake hwclock"-type thing for > systems with no RTC (make a systemd service depend on /dev/rtc not > existing?), as other RPi-targeted distros do. This isn't RPi-specific, > a number of the small boards have no RTC. I do typically add an RTC to > my Pis, but not always (for various reasons). We already have systemd-timesyncd. On startup, it syncs the time to the mtime of: - /var/lib/systemd/timesync/clock file; or - /usr/lib/clock-epoch file; or - a time derived from the source tree at build time timesyncd is mentioned in the bug, but I didn't read everything. -- Tomasz Torcz There exists no separation between gods and men: to...@pipebreaker.pl one blends softly casual into the other. — Frank Herbert ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: Fedora Linux 39 Final blocker status summary #3
Once upon a time, Adam Williamson said: > 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. Not adding to the ticket (because "me too" is not useful there), but... I think Fedora should include SOME type of "fake hwclock"-type thing for systems with no RTC (make a systemd service depend on /dev/rtc not existing?), as other RPi-targeted distros do. This isn't RPi-specific, a number of the small boards have no RTC. I do typically add an RTC to my Pis, but not always (for various reasons). -- Chris Adams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Fedora Linux 39 Final blocker status summary #3
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: @ad...@fosstodon.org https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Fedora Linux 39 Final blocker status summary #2
Hi folks! We're still trying to get F39 done, so time for another status update... Action summary == Accepted blockers - 1. curl - https://bugzilla.redhat.com/2243182 - ON_QA: QA to test and karma https://bodhi.fedoraproject.org/updates/FEDORA-2023-0f8d1871d8 2. distribution - https://bugzilla.redhat.com/2243034 - ASSIGNED: maintainers to try and squeeze out any possible space savings, FESCo to consider https://pagure.io/fesco/issue/3082 3. ghostscript - https://bugzilla.redhat.com/2241112 - ON_QA: QA to test and karma https://bodhi.fedoraproject.org/updates/FEDORA-2023-c2665a9ff3 4. initial-setup - https://bugzilla.redhat.com/2241274 - ON_QA: QA (and pwhalen, who reported the bug) to test and karma https://bodhi.fedoraproject.org/updates/FEDORA-2023-133bdc4283 5. mutter - https://bugzilla.redhat.com/2241632 - ASSIGNED: desktop team to investigate and fix, now this is well triaged 6. shim - https://bugzilla.redhat.com/2113005 - NEW: stakeholders to consider waiving again at go/no-go 7. uboot-tools - https://bugzilla.redhat.com/2241252 - ASSIGNED: ARM team to investigate and fix 8. distribution - https://bugzilla.redhat.com/2242759 - NEW: stakeholders to consider whether any 'fix' is realistic, implement if so Proposed blockers - 1. anaconda - https://bugzilla.redhat.com/2243206 - POST: blocker voters to vote, anaconda team to fix if accepted Bug-by-bug detail = Accepted blockers - 1. curl - https://bugzilla.redhat.com/2243182 - ON_QA CVE-2023-38545 curl: a heap based buffer overflow in the SOCKS5 proxy handshake [fedora-all] The fix for this is in updates-testing and just needs testing and karma. 2. distribution - https://bugzilla.redhat.com/2243034 - ASSIGNED Fedora 39: Server boot aarch64 image exceeds maximum size This image is oversize because of increases in the size of qualcomm firmware. (The sizes of aarch64 and x86_64 images differ somewhat because they include different firmware packages; x86_64 is fine ATM). We can't drop the new firmware files (says pbrobinson) and I couldn't see any obvious other place to save 6M when I looked at this. In any case, the 700M size limit makes no practical sense for aarch64 (700M is set as the limit because it's the size of a CD; hands up if you have an aarch64 device with a CD-but-not-DVD drive!), and we are probably reaching the limits of its usefulness as a protection against "bloat", since linux-firmware is constantly increasing in size even if we don't introduce any new "bloat" to the installer environment. So I've proposed https://pagure.io/fesco/issue/3082 to bump the size limit to 1G for the aarch64 image at least. If FESCo goes for that proposal, this would be addressed. 3. ghostscript - https://bugzilla.redhat.com/2241112 - ON_QA CVE-2023-43115 ghostscript: GhostPDL can lead to remote code execution via crafted PostScript documents [fedora-all] The fix for this is in updates-testing and just needs testing and karma. 4. initial-setup - https://bugzilla.redhat.com/2241274 - ON_QA initial-setup text fails on hardware The fix for this is in updates-testing and just needs testing and karma. Especially it'd be great if pwhalen could test and confirm as he reported the issue. 5. mutter - https://bugzilla.redhat.com/2241632 - ASSIGNED Netinstall ISO renders a black screen when using kickstart install (bare metal and VM) I've managed to narrow this down to a specific mutter pull request which caused the problem, and found a small change (discovered by someone from upstream to address a different symptom) that avoids this bug. Now up to the desktop team to decide what the best real fix is. 6. 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 Sadly we will probably have to waive this one more time, at this point in the cycle it's not realistic to start backporting kernel changes. 7. uboot-tools - https://bugzilla.redhat.com/2241252 - ASSIGNED Fedora-Workstation-39_Beta-1.1 boots to a black screen on Raspberry Pi 4 pbrobinson has said he's working on this, unless anyone else expert in uboot-tools stuff wants to help, not much more to be done. 8. 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 seem to have developed a pretty good understanding of this one now, but based on that understanding, it may not be realistically possible to "fix" it - the only interventions proposed so far that might "fix" it seem rather too radical to introduce as updates to a stable release (F38), which is where they'd have to go. Unless anyone has a bright idea, we might just have to accept that this isn't realistically fixable and waive it to be addressed with documentation. Proposed blockers - 1. anaconda - https://bugzilla.redhat.com/2243206 - POST anaconda should allow installa
Fedora Linux 39 Final blocker status summary
Hi folks! We're into Final freeze, so it's time for a blocker status mail. The current Final target date is 2023-10-17, meaning we'd need a release candidate by, er, Monday, so get your skates on everyone :) Action summary == Accepted blockers - 1. anaconda - https://bugzilla.redhat.com/2239213 - MODIFIED: anaconda team to submit update with fix 2. anaconda - https://bugzilla.redhat.com/2241632 - ASSIGNED: anaconda team to work out a fix and submit an update with it 3. fedora-release - https://bugzilla.redhat.com/2242437 - POST: sgallagh (or me/Kevin) to merge PRs and do builds 4. firefox - https://bugzilla.redhat.com/2242454 - MODIFIED: adamwill to submit update when the build is done 5. firefox - https://bugzilla.redhat.com/2242523 - NEW: adamwill to submit update when the build is done 6. initial-setup - https://bugzilla.redhat.com/2241274 - POST: mkolman to merge the fix and do a build/update 7. kernel - https://bugzilla.redhat.com/2240859 - MODIFIED: QA to test/karma https://bodhi.fedoraproject.org/updates/FEDORA-2023-c3bb819677 8. mesa - https://bugzilla.redhat.com/2238711 - ON_QA: QA to test/karma https://bodhi.fedoraproject.org/updates/FEDORA-2023-86e10b6cae 9. mutter - https://bugzilla.redhat.com/2239128 - MODIFIED: QA to test/karma https://bodhi.fedoraproject.org/updates/FEDORA-2023-fd2feee3b7 10. shim - https://bugzilla.redhat.com/2113005 - NEW: Maintainers (kraxel / jforbes / pbrobinson) to clarify if there's any chance to get the kernel stuff backported and a new shim built for F39, otherwise we'll have to waive this again 11. uboot-tools - https://bugzilla.redhat.com/2241252 - ASSIGNED: maintainers to investigate and fix 12. xdg-desktop-portal - https://bugzilla.redhat.com/2240211 - VERIFIED: QA to test and karma https://bodhi.fedoraproject.org/updates/FEDORA-2023-a34ccfc45b Proposed blockers - 1. blivet-gui - https://bugzilla.redhat.com/2241761 - MODIFIED: QA to test/karma https://bodhi.fedoraproject.org/updates/FEDORA-2023-e9198d932d 2. kbd - https://bugzilla.redhat.com/2242287 - MODIFIED: QA to test/karma https://bodhi.fedoraproject.org/updates/FEDORA-2023-fa617966c7 3. kernel - https://bugzilla.redhat.com/2239807 - NEW: stakeholders to vote at https://pagure.io/fedora-qa/blocker-review/issue/1359 , reporter to check if 6.5.6 happens to fix it 4. librepo - https://bugzilla.redhat.com/2242115 - POST: stakeholders to vote at https://pagure.io/fedora-qa/blocker-review/issue/1375 , jrohel to build an update with the fix Bug-by-bug detail = Accepted blockers - 1. anaconda - https://bugzilla.redhat.com/2239213 - MODIFIED anaconda should use localed layout conversion when setting default console layout We just need anaconda team to merge the fix for this and do a build. 2. anaconda - https://bugzilla.redhat.com/2241632 - ASSIGNED Netinstall ISO renders a black screen when using kickstart install (bare metal and VM) Anaconda team is working on figuring out the cause of this at present. 3. fedora-release - https://bugzilla.redhat.com/2242437 - POST updates-testing should be disabled, fedora-release should have release >= 1 This is trivial and just needs a couple of merges/builds, I guess Kevin and I are giving the official maintainers time but if it isn't done soon we'll do it. 4. firefox - https://bugzilla.redhat.com/2242454 - MODIFIED DBusActivatable is not implemented correctly The build to fix this is running right now, then I need to submit an update. 5. firefox - https://bugzilla.redhat.com/2242523 - NEW Too many firefox launchers are preinstalled Same as #4. 6. initial-setup - https://bugzilla.redhat.com/2241274 - POST initial-setup text fails on hardware There's a PR that's confirmed to fix this, we just need it merged and an official build done. 7. kernel - https://bugzilla.redhat.com/2240859 - MODIFIED amdgpu crash: kernel 6.5.x ([drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx_low timeout) The update that should fix this is created: https://bodhi.fedoraproject.org/updates/FEDORA-2023-c3bb819677 . Just need folks to test and karma it. 8. mesa - https://bugzilla.redhat.com/2238711 - ON_QA GDM crashes on Intel Iris Plus graphics - crash in gnome-shell cogl_gl_create_timestamp_query Update is in testing: https://bodhi.fedoraproject.org/updates/FEDORA-2023-86e10b6cae . Just needs karma. 9. mutter - https://bugzilla.redhat.com/2239128 - MODIFIED pop-up screen is stuck when try to format a partition Update is created: https://bodhi.fedoraproject.org/updates/FEDORA-2023-fd2feee3b7 . Just needs testing and karma. 10. 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 This is the infamous one that we've been waiving for several releases due to the lack of nx support in the kernel meaning we can't get a new shim signed by Microsoft, even though we know the fix for the bug. The kernel p
