Comments
mattf
After an update containing aide-0.18.4-2.fc38.x86_64, aide --check was denied execmem 2/2 times when started as a cron job. I reported the denial in more detail at https://bugzilla.redhat.com/show_bug.cgi?id=2217165
I ran sudo dnf offline-upgrade download with updates-testing enabled in a Fedora 38 KDE Plasma installation. Qt 5.15.9 is installed from the update https://bodhi.fedoraproject.org/updates/FEDORA-2023-e78d433635 in updates-testing. dnf had a problem because kf5-frameworkintegration-5.105.0-2.fc38.x86_64 requires qt5-qtbase(x86-64) = 5.15.8, but none of the providers can be installed. I reported this problem at https://bugzilla.redhat.com/show_bug.cgi?id=2187131 dnf couldn't update to kf5-frameworkintegration-5.105.0-2.fc38 due to that problem. kf5-frameworkintegration-5.105.0-2.fc38 might need to be rebuilt with Qt 5.15.9
ksysguardd didn't crash after I updated to ksysguardd-5.22.0-9.fc38. Thanks.
I ran sudo dnf offline-upgrade download with updates-testing enabled in a Fedora 38 KDE Plasma installation. dnf showed a problem because kf5-kcalendarutils-22.12.3-1.fc38.x86_64 requires grantlee-qt5(5.2), but grantlee-qt5-5.3.1-1.fc38 provides grantlee-qt5(5.3) = 5.3.1-1.fc38. I reported this problem at https://bugzilla.redhat.com/show_bug.cgi?id=2180667
Fedora-KDE-Live-x86_64-38_Beta-1.3.iso with 6.2.2-301 booted normally with the default kernel command line parameters on the system which had the black screen problem at https://bugzilla.redhat.com/show_bug.cgi?id=2156691 Thanks.
Switching VTs from sddm on Wayland with kwin_wayland compositor with ctrl+alt+f2 etc. doesn't seem to work any longer after updating to plasma-workspace-5.27.0-4.fc37. Is that intentional or not?
I searched for systemd-userdbd in the systemd-stable repository and found a commit units: allow systemd-userdbd to change process name which makes the following change adding the CAP_SYS_RESOURCE capability to the systemd-userdbd.service file https://github.com/systemd/systemd-stable/commit/9357d2342981a8b4fcfa2d170b7749c27d364fdd
- CapabilityBoundingSet=CAP_DAC_READ_SEARCH
- CapabilityBoundingSet=CAP_DAC_READ_SEARCH CAP_SYS_RESOURCE
That change might be where these denials are coming from.
On the next 2 boots after an update including systemd-251.11-1.fc37.x86_64, processes like sd-worker and systemd-userwork were denied using the sys_resource capability when systemd-userdbd.service was started. I also saw SELinux denial notifications at various times while using Plasma. The same sorts of sys_resource denials were shown in the journal at those times. I reported these denials in more detail at https://bugzilla.redhat.com/show_bug.cgi?id=2166509
dnf problems occurred when updating to webkitgtk-2.38.3-1.fc37 from koji involving nothing provides javascriptcoregtk6.0(x86-64) = 2.38.3-1.fc37 needed by webkit2gtk5.0-2.38.3-1.fc37.x86_64 I reported the problem at https://bugzilla.redhat.com/show_bug.cgi?id=2155975
xdg-desktop-portal-kde crashed when run by sddm on Wayland with kwin_wayland compositor during each boot with sddm-0.19.0^git20221025.fc24321-1.fc37 with the same trace and errors in the journal as I reported at https://bugzilla.redhat.com/show_bug.cgi?id=2129479. The commit "disable automatic portal launching" at https://github.com/sddm/sddm/commit/fc24321541f6f65b7d1aac89cd82336ffd53e1a0 looks like it's intended to fix this problem, but it might not be sufficient to do so. sddm ran normally otherwise. Logging out of Plasma 5.26.2 on Wayland showed sddm on Wayland at least some of the time instead of the text login on VT2 as in https://bugzilla.redhat.com/show_bug.cgi?id=2073725 Since sddm-0.19.0^git20221025.fc24321-1.fc36 was pushed to stable https://bodhi.fedoraproject.org/updates/FEDORA-2022-24b141d508 I think it's better if this one is too at least to avoid downgrades even though xdg-desktop-portal-kde still crashes when run by sddm for me.
The sddm white background problem can be seen in the openqa test fedora-37-updates-kde-x86_64-BuildUpdate-FEDORA-2022-a5622b766b-desktop_background@64bit in the section _graphical_wait_login_2 for this update at https://openqa.fedoraproject.org/tests/1485271#step/_graphical_wait_login_2/3
The sddm background was white after logging out of Plasma in the image Fedora-KDE-Live-x86_64-Rawhide-20221001.n.1.iso https://bugzilla.redhat.com/show_bug.cgi?id=2131638 Only the user icon and the password box and button could be seen. Most of the text wasn't visible because it was in white by default in the Breeze Fedora theme. This problem might be related to the f37-backgrounds-37.0.1-1.fc38 change from png to webp format backgrounds. A journal error showed that the png default background /usr/share/backgrounds/default.png couldn't be opened when the sddm white background problem happened. sddm-greeter[2556]:file:///usr/share/sddm/themes/01-breeze-fedora/Background.qml:21:5: QML Image: Cannot open file:///usr/share/backgrounds/default.png
/usr/share/backgrounds/default.png didn't exist on the live image Fedora-KDE-Live-x86_64-Rawhide-20221001.n.1.iso This problem might happen in F37 as well if /usr/share/backgrounds/default.png is still set for the sddm Breeze Fedora theme. @tseewald reported the sddm white background problem in F37 at the Qt 5.15.6 update https://bodhi.fedoraproject.org/updates/FEDORA-2022-d8cd3b01b7#comment-2732423
@tseewald I've seen the white SDDM background problem, but it was due to the Breeze Fedora SDDM theme background being set to a file which no longer existed instead of the xdg-desktop-portal-kde crashes with Qt 5.15.6 I reported at https://bugzilla.redhat.com/show_bug.cgi?id=2129479 I fixed the white SDDM background in System Settings > Startup and Shutdown > Login Screen (SDDM) > Change Background icon > Load from file and selected a background from /usr/share/wallpapers/F37/contents/images/ with the resolution of my screen. Selecting the Breeze theme in the Login Screen (SDDM) page also fixed this problem for me in the past.
libjxl-0.7.0-1.fc37 wasn't updated from libjxl-0.7.0rc-1.fc37 since dnf showed The same or higher version of libjxl is already installed, cannot update it. I reported this problem at https://bugzilla.redhat.com/show_bug.cgi?id=2129592
xdg-desktop-portal-kde crashed when run by sddm during boot with Qt 5.15.6 as reported at https://bugzilla.redhat.com/show_bug.cgi?id=2129479
rngd from rng-tools-6.15-4.fc37 started, stopped, started, and failed when booting as I reported at https://bugzilla.redhat.com/show_bug.cgi?id=2128954 rngd.service didn't fail in this way with rng-tools-6.15-3.fc37.
The test image with this update 02007780-Fedora-KDE-Live-x86_64-FEDORA-2022-6f3ca6889e.iso has sddm-x11 installed https://bugzilla.redhat.com/show_bug.cgi?id=2110801#c14 sddm was running on X in QEMU/KVM VMs with that image in which I logged out of Plasma normally a few times. Updating a F37 KDE Plasma installation with this update left sddm-wayland-plasma installed, so plasma-workspace-5.25.4-2.fc37 kept sddm on Wayland if it was already installed which might be intended. Plasma on Wayland has run normally otherwise.
dnf errors indicated that qgnomeplatform-qt6-0.8.4-8.fc36.x86_64 requires qt6-qtbase(x86-64) = 6.2.3, but none of the providers can be installed from this update. I reported the problem in more detail at https://bugzilla.redhat.com/show_bug.cgi?id=2088970
dracut-shutdown.service failed due to dracut-initramfs-restore errors opening initrd when rebooting or shutting down with dracut-056-1.fc36. I reported this problem at https://bugzilla.redhat.com/show_bug.cgi?id=2071306
When I've logged into Plasma 5.27.6 on Wayland from sddm after booting 6.3.10, the Plasma splash screen appeared for around a second and then the screen went black indefinitely. This problem happened each time with 6.3.10, but it didn't happen with 6.3.9 or earlier. amdgpu errors and warnings were shown in the journal as I reported at https://bugzilla.redhat.com/show_bug.cgi?id=2218414 I bisected the problem to 1ca399f127e0a372537625b1d462ed586f5d9139 "drm/amd/display: Add wrapper to call planes and stream update"