FinalBlocker -1

I don't see anything in:

$ systemctl --all --failed

FinalBlocker -1

I don't see anything in:

$ systemctl --all --failed

The bug does not say it was in systemctl --all --failed, it says that there are lots of coredumps reported in journalctl. Unfortunately, I am not able to judge the severity of these coredumps.

FinalBlocker -1

I don't see anything in:

$ systemctl --all --failed

The bug does not say it was in systemctl --all --failed, it says that there are lots of coredumps reported in journalctl. Unfortunately, I am not able to judge the severity of these coredumps.

Mhm, but the cited criterion:

"All system services present after installation with one of the release-blocking package sets must start properly, unless they require hardware which is not present." would be verified by that (systemctl --all --failed) and only that (minus theoretical systemd bug where it wouldn't list failed services properly).

We'll see if there are any consequences to the mentioned coredumps, but if not, this cannot be blocking (I don't think there is any criterion for these random fails in logs).

There's one more applicable criterion:
https://fedoraproject.org/wiki/Fedora_38_Final_Release_Criteria#SELinux_and_crash_notifications

So it depends if there's some error dialog shown during the first login? @lruzicka ?

As commented on the ticket, I do observe that on f38 sddm greeter starts freezed (one cannot input the password right away, must wait for some 30 seconds) that didn't occurred using sddm-x11, and the only different thing at the logs is this xdg-desktop-portal-kde.

Matt mentioned on the ticket that a patch might need to be added to qt5-qtbase to fix this crash.

If this is realy related to the freeze we're seeing on sddm-wayland-plasma, then I vote it for blocking.
Because this is something really really anoying for the user. One must start the computer, wait for sddm to launch, then wait for it to unfreeze (and first time we don't have a clue that its freezed, one try to click on the password field, try to type the password but nothing happens) then, after lets say 25/30 seconds, it responds again, the password appears on the box and we can login. Its not a good user experience and I can reproduce it every time on my hardware and all VMs too.

There's one more applicable criterion:
https://fedoraproject.org/wiki/Fedora_38_Final_Release_Criteria#SELinux_and_crash_notifications

So it depends if there's some error dialog shown during the first login? @lruzicka ?

No, unfortunately nothing. I spotted these looking for something else.

Release F38 is no longer tracked by BlockerBugs, closing this ticket.