On Friday, 10 February 2023 15:11:19 CET Marc Deop i Argemí wrote: Just for your information, I have built KDE Plasma 5.27.0 (which includes kwin) on sidetag f38-build-side-63172. I am uncertain if I should trigger an update on F38 now. Thoughts? Best regards, Marc Deop

On Fri, Feb 10, 2023 at 5:52 PM Adam Williamson <awilliam(a)redhat.com&gt; wrote: You'll find out with tomorrow's compose as linux-firmware-20230210-147.fc38 has my upstreamed changes.

Once upon a time, Kevin Kofler via devel <devel(a)lists.fedoraproject.org&gt; said: Can you stop grinding your axe against a decision you don't agree with? You're just "guessing" with zero evidence. If you look at the bugs, they date back well before the mass rebuild, so there's no justification to guess it's the frame pointer change. -- Chris Adams <linux(a)cmadams.net&gt;

Chris Adams wrote: I have also seen zero evidence of the contrary (i.e., that the size change is *not* significant), which should have been a prerequisite for accepting the change. All the talk in the FESCo ticket was only about speed, and my requests for size data have been ignored (not even turned down, just ignored altogether!), which makes it look to me like somebody has something to hide. We need to be much stricter on size increases! In Fedora 9 (when the xz compression for live images was introduced, which made it smaller than Fedora 7 or 8), the x86_64 KDE Spin was 729272320 bytes. In Fedora 38 Branched, it is now 2418429952 bytes. That is about 3.32 times as much! I can tell you my justification: I have experience with the TIGCC cross toolchain. Enabling -fomit-frame-pointer by default was one of the changes that helped decrease the size of basically all executables there. (It turns out that the handful extra stack adjustment instructions added up to much less code overall than all the unnecessary link/unlk instructions for the frame pointer.) Of course, that was m68k and we are talking about x86_64 here, which is why I was asking for data on Fedora on x86_64. But the guess is NOT completely out of the blue. And the analysis of the Python performance regression on Fedora x86_64 also pointed to a size increase of a function (overflowing some cache line) as the likely cause. So that, too, is evidence of size increases. Vít Ondruch wrote: So that is at least SOME data. Thanks for that. Though it does not include the packages that had already been rebuilt between when the frame pointer change was introduced and the mass rebuild. Several frequently updated packages (and some that just happened to be updated in that time window) are in that boat. I do not see what else it would be if not frame pointers. Kevin Kofler

On Mon, 13 Feb 2023 at 11:28, Kevin Kofler via devel < devel(a)lists.fedoraproject.org&gt; wrote: I did a check on some.. I only downloaded 3 isos so this isn't a complete set. # Fedora KDE Live Sizes Fedora-7-KDE-Live-x86_64.iso 2007-05-25 831M Fedora-8-Live-KDE-x86_64.iso 2007-11-02 805M Fedora-9-x86_64-Live-KDE.iso 2008-05-08 695M F10-x86_64-Live-KDE.iso 2008-11-19 684M Fedora-11-x86_64-Live-KDE.iso 2009-06-04 693M Fedora-12-x86_64-Live-KDE.iso 2009-11-09 685M Fedora-13-x86_64-Live-KDE.iso 2010-05-13 700M Fedora-14-x86_64-Live-KDE.iso 2010-10-21 687M Fedora-15-x86_64-Live-KDE.iso 2011-05-13 692M 1064 pkgs 2.4 GB uncompressed Fedora-16-x86_64-Live-KDE.iso 2011-11-03 696M 1125 pkgs 2.7 GB ump Fedora-17-x86_64-Live-KDE.iso 2012-05-22 692M Fedora-18-x86_64-Live-KDE.iso 2013-01-09 831M Fedora-Live-KDE-x86_64-19-1.iso 2013-06-27 878M Fedora-Live-KDE-x86_64-20-1.iso 2013-12-12 928M Fedora-Live-KDE-x86_64-21-5.iso 2014-12-03 953M Fedora-Live-KDE-x86_64-22-3.iso 2015-05-21 1.1G Fedora-Live-KDE-x86_64-23-10.iso 2015-10-29 1.2G Fedora-KDE-Live-x86_64-24-1.2.iso 2016-06-14 1.3G Fedora-KDE-Live-x86_64-25-1.3.iso 2016-11-15 1.3G Fedora-KDE-Live-x86_64-26-1.5.iso 2017-07-05 1.4G Fedora-KDE-Live-x86_64-27-1.6.iso 2017-11-05 1.5G Fedora-KDE-Live-x86_64-28-1.1.iso 2018-04-25 1.8G Fedora-KDE-Live-x86_64-29-1.2.iso 2018-10-25 1.8G Fedora-KDE-Live-x86_64-30-1.2.iso 2019-04-26 1.8G Fedora-KDE-Live-x86_64-31-1.9.iso 2019-10-23 1.7G Fedora-KDE-Live-x86_64-32-1.6.iso 2020-04-22 1.8G Fedora-KDE-Live-x86_64-33-1.2.iso 2020-10-19 1.8G 1705 pkgs 5.1 GB Fedora-KDE-Live-x86_64-34-1.2.iso 2021-04-23 2.0G Fedora-KDE-Live-x86_64-35-1.2.iso 2021-10-26 2.0G Fedora-KDE-Live-x86_64-36-1.5.iso 2022-05-04 2.1G The 20 largest packages on 15 is: [root@ssmoogen-rh /]# rpm -qa --qf='%{SIZE} %{NAME}\n' | sort -n | tail -n 20 22089642 kdenetwork 22148990 kipi-plugins 23597199 amarok 23750667 hugin-base 23805685 kdeedu-marble 24864336 python-libs 25621700 PyKDE4 26997652 oxygen-icon-theme 27055555 foomatic-db-ppds 28157021 opencv 28565722 digikam 29756278 mysql 32095877 kdebase-workspace 33988848 qt-x11 34693072 mesa-dri-drivers 43929551 mysql-server 44714663 perl 47397440 kdelibs 110104945 kernel 112442467 glibc-common The 20 largest packages on 33 is: 32294003 libkdegames 32371175 python3-libs 34121537 libicu 38648170 qt-x11 39173022 mariadb 47955205 qt5-qtwebkit 60158710 webkit2gtk3 62712603 geolite2-city 68540278 mesa-dri-drivers 76958332 foomatic-db-ppds 77983261 kernel-core 84432783 gcc 87571216 llvm-libs 95909527 mariadb-server 115301235 iwl7260-firmware 136611853 google-noto-sans-cjk-ttc-fonts 165482197 qt5-qtwebengine 227552812 glibc-all-langpacks 271515808 firefox 286752620 linux-firmware -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren

On Mon, 13 Feb 2023 at 13:56, Kevin Kofler via devel < devel(a)lists.fedoraproject.org&gt; wrote: The following is from the F38 image from last week? dnf remove qt5-qtwebengine Error: Problem: The operation would result in removing the following protected packages: plasma-desktop -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren

On Mon, 13 Feb 2023 at 15:56, Kevin Kofler via devel < devel(a)lists.fedoraproject.org&gt; wrote: My apologies. I should have double checked before sending. [root@fedora ~]# dnf remove qt5-qtwebkit-5.212.0-0.72alpha4.fc38.x86_64 Dependencies resolved. ==================================================================================================================================== Package Architecture Version Repository Size ==================================================================================================================================== Removing: qt5-qtwebkit x86_64 5.212.0-0.72alpha4.fc38 @anaconda 46 M Removing dependent packages: kaccounts-providers x86_64 22.12.2-1.fc38 @anaconda 384 k kio-gdrive x86_64 22.12.2-1.fc38 @anaconda 419 k kwebkitpart x86_64 1.4.0-0.13.20190110.fc38 @anaconda 1.2 M Removing unused dependencies: kf5-kdewebkit x86_64 5.103.0-1.fc38 @anaconda 213 k signon-ui x86_64 0.15-19.fc38 @anaconda 293 k Transaction Summary ==================================================================================================================================== Remove 6 Packages -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren

Neal Gompa wrote: Well, the way the Anaconda web UI is currently packaged, it hardcodes a requirement on a specific browser or engine. As for Firefox, it should be gone from the Spin to begin with. It is consistently one of the largest packages on the entire Spin and it is entirely redundant. QtWebEngine cannot go away (since even Plasma itself depends on it, but also, e.g., KMail/Kontact), so what needs to go to remove the duplication is clearly Firefox. Kevin Kofler

On 2/13/23 16:10, Neal Gompa wrote: And is kept up to date, unlike QtWebEngine. QtWebEngine is invariably behind on security patches. I blame Google for not making embedded Chromium a first-class citizen. -- Sincerely, Demi Marie Obenour (she/her/hers)

As a browser maintainer itself, I'm very supportive of the Falkon project. I consider it to be KDE's equivalent of Epiphany, sort of a sister project, more or less. On Tue, Feb 14 2023 at 03:44:06 AM +0100, Kevin Kofler via devel <devel(a)lists.fedoraproject.org&gt; wrote: I looked into this a couple months ago and if I remember correctly, they *are* impressively backporting quite a few CVE fixes, but I don't think they are *comprehensively* doing so? My suspicion is that if a fix does not apply cleanly, or looks difficult, they probably move on to the next one? It's really hard just to determine whether a fix is still required. (Disclaimer: I'm not looking at the git repo right now or cross-referencing to a list of Chromium CVEs. May be wrong. Don't treat this as gospel.) Additionally, I don't know about Chromium, but in WebKit I recently estimated that only about 5% of issues flagged as fixing security vulnerabilities receive CVEs. (Maybe Chromium does better at this?) And it is impossible to know what percentage of security fixes get flagged as such, but my guess is that percentage is itself pretty low. I'd further guess that the situation with Chromium is similar. So even if you backport fixes for every single CVE, you will not be in good shape. My conclusion was that QtWebEngine was that the Qt 5 version is too old. I think QtWebEngine should adopt the same strategy that WebKitGTK and Firefox ESR use: regularly rebase to latest upstream version. WebKitGTK does that twice per year. Firefox does it every 9 months. Backports are an appropriate way to fill the gap between rebases, but they are NOT a substitute for regular rebases. Michael

Neal Gompa wrote: At least that is an answer, unlike the complete radio silence on: https://bugzilla.redhat.com/show_bug.cgi?id=1920298 Still does not explain why Firefox has to be the default though. But the thing is, this inevitably leads to: * unnecessarily including a redundant web engine on the Spin (because, as I explained, QtWebEngine cannot go away), a huge package increasing the download size for all users of the Spin, whether they want Firefox or not, * a non-native browser experience (with controls/widgets based on the XUL implementation and the GTK look&feel) instead of a native Qt/KDE one, and * a hindrance in getting critical QtWebEngine showstoppers fixed in time for the release, because they are not considered Blockers if they do not affect the default browser: https://bugzilla.redhat.com/show_bug.cgi?id=2001261#c7 That is arguable, considering that Chromium is also Open Source (*) and that there are many users of Chromium derivatives (though not necessarily Open Source (*) ones). But either way, it is not a KDE browser. The KDE Spin should be about shipping KDE applications wherever possible. So is QtWebEngine. Chromium gets a lot of development, and Qt backports security fixes and important bug fixes to the stable QtWebEngine branches. Even the LTS releases of QtWebEngine are publicly available under the LGPL from git.qt.io. So "well-liked" that it has a fraction of the market share of Chrome and other Chromium-based browsers nowadays. I think there need to be more objective criteria for picking a default browser than allegedly being "well-liked by the community". "Most things on the Internet" will also accept any Chromium-based browser, such as Falkon. The latest QtWebEngine is in fact more standards-compliant than Firefox, see the evidence under: https://bugzilla.redhat.com/show_bug.cgi?id=1920298 Falkon even works for some sites that only officially support Chrome and do not work with Firefox. (E.g., the Microsoft Teams web interface. Last I checked, when I tried it with Firefox, it offered me only to download the desktop client. With Falkon, I can connect in the browser just fine.) Now, admittedly, one issue is that Falkon is currently stuck on QtWebEngine 5, hence on 5.15 LTS, which gets security backports, but not feature backports, so a handful websites are now causing problems with it. (It is unfortunate that the web has evolved to such a moving target that web developers are unwilling to support even supported LTS versions of browsers. They are also complaining about having to support Safari iOS branches, Firefox ESR, etc.) For Falkon, that issue should be solved as soon as a Qt 6 port of Falkon is released. QtWebEngine works on all architectures for which a Fedora KDE deliverable is actually shipped: * The KDE Spin is shipped only for x86_64 on the main mirrors. * On alt.fedoraproject.org, the KDE Spin is shipped only for aarch64. * Kinoite is shipped only for x86_64 and aarch64. So the KDE Spin needs to support only x86_64 and aarch64, both of which are fully supported by QtWebEngine (and we also build -freeworld for both of them at that other repository nowadays, I fixed that a couple years ago). Kevin Kofler (*) I personally prefer the term "Free Software", but since you talked about the "premier open source browser", I am replying with your terms.

Peter Robinson wrote: If and when that was decided, that was without involving the maintainers of the Spins. I know because I was directly involved with maintaining the KDE Spin at the time. And it is already the case that some Spins use a non-Firefox default browser that fits better into that Spin's environment (and IMHO that is a good thing). I want those off the Spin as well. They should stay in the repos for the users who need applications using them, but qt5-qtwebkit is a legacy compatibility library that should not be installed by default on any Spin, and webkit2gtk3 is a GTK-based library that should not be installed by default on a Qt-based Spin. Blame Akonadi for that. It can theoretically work without MariaDB, but the performance of the SQLite backend is poor (due mainly to locking/concurrency issues inherent to file-based databases), so it is not recommended. I think the way Akonadi is designed is broken and needs to be fixed (and the above is one of the reasons), but KDE has been sticking to that design since 4.x days and is not interested in a major redesign. Dropping Akonadi would probably be possible, but it would mean losing some Plasma features, and it is not clear what mail program would be shipped then. At least as long as Trojitá depends on the legacy QtWebKit, see above. Shipping Akonadi with SQLite could be a compromise, but that too would IMHO need at least a replacement for KMail (which is the most performance- critical Akonadi user) to be viable. And that is just my view as a Trojitá user who heavily dislikes Akonadi due to past awful experiences with KMail. The current KDE SIG members will probably be even less interested than me in replacing or nerfing (by using SQLite instead of MariaDB) Akonadi. Huh? The KDE Spin now installs the GCC toolchain by default? Since when? It did not back when I helped maintain the Spin, nor more recently when I based the Kannolo Fedora Remix on it. Is that for akmod/DKMS/… kernel modules? KDE Plasma definitely does not (mandatorily) require a toolchain at runtime. For the database server, see above: users of Akonadi are using a per-user instance of it behind the scenes, often without knowing it. For the GCC toolchain, you may be right, though users of kernel modules from RPM Fusion are forced to use it these days because they (sadly) no longer ship binary kmod packages. (Even for blobs like the NVidia driver, the glue code is always recompiled from an akmod and no completely binary kmod is shipped.) I agree that there are other components that should not be on the Spin (only in the repository), but the redundant browser as a leaf application surely is the lowest-hanging fruit. Kevin Kofler

Adam Williamson wrote: Well, as you point out yourself: what was decided back then was NOT that "all desktops would have some Fedora similarities, backgrounds, browser etc.", but that AT THAT TIME (which was BEFORE QtWebEngine entered Fedora! The strict bundling rules that prevented it from passing review were loosened only a few months later), the KDE Spin would ship with Firefox. That is different because that decision was not a categorical decision that the KDE Spin, or even ALL Spins, would always ship Firefox (which is something at least the KDE SIG had never agreed to), but a momentaneous decision for Fedora 23 that could be revisited later. In fact, there was a later vote for Fedora 25: https://meetbot-raw.fedoraproject.org/fedora-meeting/2016-08-09/kde-sig.2... which proposed switching to QupZilla/Falkon, vote which turned out much closer than the 2015 vote where KWebKitPart had started to age and there had been no viable alternative in Fedora other than Firefox. In discussions after that vote, I was told that the decision could be reconsidered again under some conditions, but unfortunately, said conditions kept changing. As had been the case already in the time leading to the 2016 vote. For F24, first the excuse was that QupZilla was not packaged, then that it was version 1.9.99 and not 2.0.0, then that it was too late in the release cycle (but the switch to Firefox for F23 had happened *during Final Freeze*!). But I had expected it to be pretty much a given that we would switch to QupZilla for F25, also based on the discussions immediately prior to the 2016 vote, and then it surprisingly still did not get a majority, and there were again new excuses being brought up. And that continued again and again. Kevin Kofler

On Sat, 2023-02-11 at 18:38 +0100, Kevin Kofler via devel wrote: No, it isn't. The images have been oversize for some time now. The immediate trigger that most recently pushed them from being just- undersize to being just-oversize was changes to the kernel and webkit. See https://bugzilla.redhat.com/show_bug.cgi?id=2151497#c5 amd #c6. The images grew another 12M between 0111 and 0121; I haven't looked at what caused that. Since then they've been fairly stable. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org https://www.happyassassin.net

On Fri, 2023-02-17 at 14:45 -0500, Ben Cotton wrote: This went under the limit for like two days when the linux-firmware change landed, but then bounced back over it recently. I didn't yet get time to check out why, too much fire. I actually fixed this a few days ago, we can probably close it. I've done that. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org https://www.happyassassin.net

The current target release date is the early target date (2023-03-14). The Go/No-Go meeting will be Thursday! Action summary ==================== Accepted blockers ----------------- 1. distribution — Workstation boot x86_64 image exceeds maximum size — POST ACTION: gdb maintainers to remove the 'Recommends' for gcc-gdb-plugin from gdb 2. crypto-policies — Insecure installed RPMs (like Google Chrome) prevent system updates in F38, can't be removed — NEW ACTION: Upstream to implement MR #129 Proposed blockers ----------------- 1. gnome-session — reboot/poweroff/logout from GNOME are 60 seconds delayed without 3D acceleration — NEW ACTION: Maintainers to diagnose issue 2. gnupg2 — revert the RFC4880bis from defaults — NEW ACTION: Maintainers to revert inclusion of RFC4880bis 3. initial-setup — User creation and root password setting do not work on minimal install, so cannot log into installed system — NEW ACTION: Maintainers to diagnose issue 4. kernel — Black screen when amdgpu started during 6.2-rc1 boot with AMD IOMMU enabled — NEW ACTION: Maintainers to package update which includes upstream patches 5. mutter — XWayland apps steal focus — NEW ACTION: Maintainers to build update with upstream merge request 6. sddm — Virtual keyboard (on-screen) not working at sddm-wayland-plasma — NEW ACTION: Maintainers to diagnose issue Bug-by-bug detail ============= Accepted blockers ----------------- 1. distribution — https://bugzilla.redhat.com/show_bug.cgi?id=2149246 — POST Workstation boot x86_64 image exceeds maximum size Changes to linux-firmware briefly brought the Worktation image below the limit. Removing the recommendation (in gdb) of gcc-gdb-plugin, which is "largely broken", should reduce the image size below limits. 2. crypto-policies — https://bugzilla.redhat.com/show_bug.cgi?id=2170878 — NEW Insecure installed RPMs (like Google Chrome) prevent system updates in F38, can't be removed Some third-party repos (including Google Chrome) that sign packages with SHA-1 cannot be uninstalled, which breaks upgrades. This was designated a blocker by FESCo. Work is in progress upstream to allow RPM to permit SHA-1 in the default policy while third-party repos update to a supported hash function: https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/merge_requests/129 Proposed blockers ----------------- 1. gnome-session — https://bugzilla.redhat.com/show_bug.cgi?id=2174753 — NEW reboot/poweroff/logout from GNOME are 60 seconds delayed without 3D acceleration On machines (physical and virtual) without 3D acceleration, clicking the reboot/poweroff/logout buttons has no apparent effect for 60 seconds. A second click or using command line commands works immediately. 2. gnupg2 — https://bugzilla.redhat.com/show_bug.cgi?id=2175155 — NEW revert the RFC4880bis from defaults GnuPG 2.4.0 made a potentially-incompatible change. A PR is pending to revert this: https://src.fedoraproject.org/rpms/gnupg2/pull-request/15 3. initial-setup — https://bugzilla.redhat.com/show_bug.cgi?id=2175244 — NEW User creation and root password setting do not work on minimal install, so cannot log into installed system On the Minimial image only, initial-setup silently fails to create a user. This results in a system with no usable user account. 4. kernel — https://bugzilla.redhat.com/show_bug.cgi?id=2156691 — NEW Black screen when amdgpu started during 6.2-rc1 boot with AMD IOMMU enabled Kernel 6.2.0 introduced an issue that causes the system to hang when booting with amdgpu. There are upstream patches targeted for 6.2.2 that contain a candidate fix. 5. mutter — https://bugzilla.redhat.com/show_bug.cgi?id=2173985 — NEW XWayland apps steal focus Alt+Tab switching, as well as (sometimes) clicking on windows does not focus the window. This seems to largely affect Wine, Java, and Chromium applications. This may have been introduced by upstream commit a68b8e95. Upstream MR #2841 has a fix for Chrome and Electron apps. 6. sddm — https://bugzilla.redhat.com/show_bug.cgi?id=2174563 — NEW Virtual keyboard (on-screen) not working at sddm-wayland-plasma The virtual keyboard at the login screen does not appear when you click the appropriate button. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

On Fri, Mar 03, 2023 at 04:02:43PM -0500, Stephen Smoogen wrote: Yes. People are aware of this. Merge request 129 had to go as far as allowing DSA1024 :( Zbyszek

The current target is the early target date (18 April). Action summary ==================== Accepted blockers ----------------- 1. fcoe-utils — anaconda failed to detect the fcoe target(only affects ixgbe) — NEW ACTION: Maintainer to diagnose issue NEEDINFO: cleech 2. gnome-calendar — After a few searches, search no longer works and cpu is at 100% — VERIFIED ACTION: none 3. gnome-maps — A quick movement breaks tile rendering, gets you banned at the server — VERIFIED ACTION: none 4. gnome-shell — Logout/reboot/poweroff timeout leaves the session in a broken state, doesn't perform the action — POST ACTION: Maintainer to build an update that contains upstream MR #2696 5. gtk4 — With GTK 4.9.1 , Nautilus' target for "Move To" or "Copy To" operations is unexpected and can be invalid — VERIFIED ACTION: none 6. kernel — The kernel sometimes does not initialize SimpleDRM when booting in basic graphics mode on BIOS, causing SDDM to fail — NEW ACTION: Everyone to agree on a suitable workaround 7. mutter — Session crash when reverting Display settings — VERIFIED ACTION: none 8. mutter — Crash when using Win+P shortcut — VERIFIED ACTION: none 9. nautilus — Dragging files is Nautilus doesn't work as expected, quick movements result in a selection box instead — VERIFIED ACTION: none 10. openssh — Update hostkey migration to support OSTree systems and dynamically detect hostkey location — POST ACTION: fedora-release and openssh maintainers to merge pending pull requests 11. sddm — Virtual keyboard (on-screen) not working at sddm-wayland-plasma — NEW ACTION: Maintainers to diagnose issue or revert to using X11 12. shim — Live image made with BOOTX64.EFI from latest shim-x64-15.6-2 fails to boot on some boards — NEW ACTION: kernel upstream to merge NX support Proposed blockers ----------------- 1. f38-backgrounds — The default wallpaper isn't listed among available wallpapers — VERIFIED ACTION: none 2. gnome-abrt — crash data are erased occasionally — NEW ACTION: Maintainer to diagnose issue 3. gnome-calendar — Crash/Hang when clicking a modified Google event right after editing it (due to the preview popover) — NEW ACTION: Upstream to diagnose issue 4. ibus — ibus: XFree(): ibus-x11 killed by SIGABRT — MODIFIED ACTION: QA or reporter to verify FEDORA-2023-e0df9e598e 5. mutter — Fullscreen mode is broken for many games — POST ACTION: Maintainer to create an update the contains upstream MR #2910 6. xdg-desktop-portal-kde — xdg-desktop-portal-kde is launching and crashing when SDDM launches the Wayland greeter — NEW ACTION: Maintainer to diagnose issue Bug-by-bug detail ============= Accepted blockers ----------------- 1. fcoe-utils — https://bugzilla.redhat.com/show_bug.cgi?id=2171350 — NEW anaconda failed to detect the fcoe target(only affects ixgbe) The installer does not detect attached FCOE storage using ixgbe. SELInux warnings appear, but it runs in passive mode, so that is not the root cause. 2. gnome-calendar — https://bugzilla.redhat.com/show_bug.cgi?id=2177992 — VERIFIED After a few searches, search no longer works and cpu is at 100% Several searches result in full CPU and memory utilization, even after closing the application. FEDORA-2023-35421ab32a contains a verified fix. 3. gnome-maps — https://bugzilla.redhat.com/show_bug.cgi?id=2177995 — VERIFIED A quick movement breaks tile rendering, gets you banned at the server Some actions in gnome-maps that involve animations result in being temporarily banned by the server. FEDORA-2023-b3146555f6 contains a verified fix for the blocking behavior. Additional non-blocking behavior remains to be fixed: https://gitlab.gnome.org/GNOME/gnome-maps/-/issues/546 4. gnome-shell — https://bugzilla.redhat.com/show_bug.cgi?id=2177853 — POST Logout/reboot/poweroff timeout leaves the session in a broken state, doesn't perform the action When a user lets the logout/reboot/poweroff confirmation timeout, everything is grayed out and the mouse can't click on anything, but the keyboard can still be used. Upstream MR https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2696 contains a candidate fix. 5. gtk4 — https://bugzilla.redhat.com/show_bug.cgi?id=2173891 — NEW With GTK 4.9.1 , Nautilus' target for "Move To" or "Copy To" operations is unexpected and can be invalid Copying or moving a file to a directory that is not empty results in failure. Empty directory targets work. FEDORA-2023-b6f25977ef contains a verified fix. 6. sddm — https://bugzilla.redhat.com/show_bug.cgi?id=2176782 — NEW The kernel sometimes does not initialize SimpleDRM when booting in basic graphics mode on BIOS, causing SDDM to fail In BIOS mode only, sddm results in a blank screen when using basic graphics mode. This is the result of a SimpleDRM device not being created. gdm uses a fallback to x11 in this scenario, so it works. Configuring GRUB to use a gfxterm for BIOS boots may be a workaround. The proposed `vga=normal` workaround does not appear to work. 7. mutter — https://bugzilla.redhat.com/show_bug.cgi?id=2175809 — VERIFIED Session crash when reverting Display settings Applying a change to Display settings and then reverting (or pressing Escape when presented with the revert dialog) results in a crash. Letting the dialog window time out does not crash. FEDORA-2023-6cec60a347 contains a verified fix. 8. mutter — https://bugzilla.redhat.com/show_bug.cgi?id=2177982 — VERIFIED Crash when using Win+P shortcut Using Win+P to switch between displays configuration crashes gnome-shell. FEDORA-2023-6cec60a347 contains a verified fix. 9. nautilus — https://bugzilla.redhat.com/show_bug.cgi?id=2176766 — VERIFIED Dragging files is Nautilus doesn't work as expected, quick movements result in a selection box instead In order to successfully drag-and-drop a file, you must first hold the mouse still with the left button pressed for ~half a second. FEDORA-2023-287e6e502b contains a verified fix. 10. openssh — https://bugzilla.redhat.com/show_bug.cgi?id=2172956 — POST Update hostkey migration to support OSTree systems and dynamically detect hostkey location rpm-ostree systems don't run RPM scriptlets on upgrade, which could result in an upgrade locking users out of remote machines. Package pull requests https://src.fedoraproject.org/rpms/fedora-release/pull-request/253 and https://src.fedoraproject.org/rpms/openssh/pull-request/45 contain a candidate fix. 11. sddm — https://bugzilla.redhat.com/show_bug.cgi?id=2174563 — NEW Virtual keyboard (on-screen) not working at sddm-wayland-plasma The virtual keyboard at the login screen does not appear when you click the appropriate button. This appears to be a Wayland-specific issue; reverting to X11 allows the keyboard to work as expected. 12. shim — https://bugzilla.redhat.com/show_bug.cgi?id=2113005 — NEW Live image made with BOOTX64.EFI from latest shim-x64-15.6-2 fails to boot on some boards UEFI LoadOptions that start with NUL cause boot failure. This is fixed upstream in https://github.com/rhboot/shim/pull/505 but the SecureBoot signing process requires NX support in the kernel, which is still pending upstream. Proposed blockers ----------------- 1. f38-backgrounds — https://bugzilla.redhat.com/show_bug.cgi?id=2178172 — VERIFIED The default wallpaper isn't listed among available wallpapers The default background is correctly applied, but if the users switches to a different wallpaper, the default is not visible in the selection. FEDORA-2023-359dafca1d contains a verified fix. 2. gnome-abrt — https://bugzilla.redhat.com/show_bug.cgi?id=2177153 — NEW crash data are erased occasionally It appears that abrt is removing report data when disk usage exceeds a threshold, but it's not clear why the reporter is expericing this worse than others. There may be some user experience improvements to make. In any case, the vote looks likely to be for rejecting this as a blocker. 3. gnome-calendar — https://bugzilla.redhat.com/show_bug.cgi?id=2177993 — NEW Crash/Hang when clicking a modified Google event right after editing it (due to the preview popover) Clicking on a remote event immediately after editing it results in either a crash or an unresponsive window. Waiting a few seconds before clicking results in expected behavior. 4. ibus — https://bugzilla.redhat.com/show_bug.cgi?id=2156108 — MODIFIED ibus: XFree(): ibus-x11 killed by SIGABRT Typing is sometimes "sluggish" with frequent pauses. Eventually ibus crashes. FEDORA-2023-e0df9e598e contains a candidate fix. 5. mutter — https://bugzilla.redhat.com/show_bug.cgi?id=2178167 — POST Fullscreen mode is broken for many games Many games fail to work in fullscreen and if they launch in fullscreen, they may not be usable at all. Upstream MR https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2910 contains a candidate fix. 6. xdg-desktop-portal-kde — https://bugzilla.redhat.com/show_bug.cgi?id=2178971 — NEW xdg-desktop-portal-kde is launching and crashing when SDDM launches the Wayland greeter When the greeter launches, xdg-desktop-portal-kde also launches and crashes. This appears to only happen on Wayland. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

On Fri, Mar 24, 2023 at 02:25:46PM -0400, Ben Cotton wrote: It would be helpful if people with hardware could make sure this generally works for them, so if you have found that you need to use basic graphics in the past, try booting with vga=791 just to be sure it doesn't cause problems. I'll likely do a new build with that on Monday. Brian -- Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart

On Sat, Mar 25, 2023 at 8:20 AM Neal H. Walfield <neal(a)walfield.org&gt; wrote: I think my question in https://bugzilla.redhat.com/show_bug.cgi?id=2170878#c125 wasn't really answered, or at least I don't understand the implications.

On 3/27/23 12:40, Fabio Valentini wrote: Kamil, would've been good to state that in the bug then. I only saw this email by sheer luck. Indeed. The RpmSequoia change is not really about phasing out any specific algorithms, that's a different topic. The anydesk case is actually a fine showcase of Sequoia doing exactly what the change is advertising! Only it's getting drowned in this SHA1/DSA noise, and poor error messages (which is rpm's, not Sequoias fault). - Panu -

On Mon, 27 Mar 2023 13:16:45 +0200, Zbigniew Jędrzejewski-Szmek wrote: If you are thinking of sq-keyring-linter, that won't help here. This is not a SHA-1 issue. The issue (I think) is that the anydesk maintains were too aggressive in what they striped when they exported the OpenPGP certificate. They probably ran: `gpg --export --export-options export-minimal FINGERPRINT`. According to the gpg manual page, that does: ``` export-minimal Export the smallest key possible. This removes all signatures except the most recent self-signature on each user ID. This option is the same as running the '--edit-key' command "minimize" before export except that the local copy of the key is not modified. Defaults to no. ``` This makes sense when sharing an OpenPGP certificate via email, say, so that someone can (in the future) send you an encrypted message. But it doesn't make sense when sending the certificate to someone who should then verify past signatures, which is the case here. Neal

Hi Zbyszek, Thanks for the clarifications. Neal On Mon, 27 Mar 2023 14:32:58 +0200, Zbigniew Jędrzejewski-Szmek wrote: > On Mon, Mar 27, 2023 at 01:29:38PM +0200, Neal H. Walfield wrote: > > On Mon, 27 Mar 2023 13:16:45 +0200, > > Zbigniew Jędrzejewski-Szmek wrote: > > > I agree. The scope of the issue is fairly narrow, and the underlying > > > issue is an invalid signature made by the anydesk maintainers. > > > We also have a simple command that users can use to work around > > > the issue. > > > > If you are thinking of sq-keyring-linter, that won't help here. This > > is not a SHA-1 issue. > > I know. I mentioned neither of those two things ;) > > The workaround I had in mind: add '--exclude-anydesk'. > We don't have a good replacement for graphical users yet, but I'm > sure we'll be able to write something up in CommonBugs before F38 is released. > > > The issue (I think) is that the anydesk maintains were too aggressive > > in what they striped when they exported the OpenPGP certificate. > [snip] > > Yes, probably. Anyway, the end result is that "based on the knowledge > that Sequoia has, the certificate was not valid when the signature was > made." (This is based on your comment [1]. I'm reproducing this > here for others.) > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=2170878#c124 > > Zbyszek > _______________________________________________ > 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

The current target is the early target date (18 April). Action summary ==================== Accepted blockers ----------------- 1. shim — Live image made with BOOTX64.EFI from latest shim-x64-15.6-2 fails to boot on some boards — NEW ACTION: kernel upstream to merge NX support Proposed blockers ----------------- 1. fedora-release — Fedora 38 Final needs a non-prerelease fedora-release package and fedora-repos with updates-testing disabled — MODIFIED ACTION: QA to verify update FEDORA-2023-ae8bf65eea Bug-by-bug detail ============= Accepted blockers ----------------- 1. shim — https://bugzilla.redhat.com/show_bug.cgi?id=2113005 — NEW Live image made with BOOTX64.EFI from latest shim-x64-15.6-2 fails to boot on some boards UEFI LoadOptions that start with NUL cause boot failure. This is fixed upstream in https://github.com/rhboot/shim/pull/505 but the SecureBoot signing process requires NX support in the kernel, which is still pending upstream. Proposed blockers ----------------- 1. fedora-release — https://bugzilla.redhat.com/show_bug.cgi?id=2185122 — MODIFIED Fedora 38 Final needs a non-prerelease fedora-release package and fedora-repos with updates-testing disabled Currently fedora-release and fedora-repos are in a pre-release state. Update https://bodhi.fedoraproject.org/updates/FEDORA-2023-ae8bf65eea contains a candidate fix. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis