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 installations on drives providing installation source This is at -3, +1 in voting currently. Needs more votes. If it happens to be accepted, anaconda team would have to decide on a fix. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@xxxxxxxxxxxxx https://www.happyassassin.net _______________________________________________ arm mailing list -- arm@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to arm-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/arm@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
