My understanding of this is that SDDM uses QML "Image" to load backgrounds, which is backed by QImage, which is supposed to be extended by QtImageFormats to support WebP. So, I'm confused what's going on here...

What's also odd is that this works with fresh installs of Fedora KDE on F37, at least according to OpenQA? 

https://openqa.fedoraproject.org/tests/1491035

Yes, fresh install seems fine

Oh, I've figured out what's wrong here.

the breeze-fedora theme uses "/usr/share/backgrounds/default.png" (from desktop-backgrounds-compat), which is a broken symlink in F37 now because we don't provide "f37.png" in f37-backgrounds-base.

The problem is in f37-backgrounds, so switching components.

Proposed as a Blocker and Freeze Exception for 37-final by Fedora user geraldosimiao using the blocker tracking app because:

 Broken login screen just after a version upgrade from a blocker desktop (KDE spin) is a terrible user experience.

Created attachment 1916627 [details]
journalctl-r from first boot after distro-upgrade F35=>F37

Created attachment 1916628 [details]
Coredump at first boot after distro-upgrade (F35=>F37)

Created attachment 1916629 [details]
blank sddm screen as seen at first boot after distro-upgrade F35=>F37

Created attachment 1916630 [details]
SDDM screen after reselect breeze fedora theme at plasma system settings

After login at first distro-upgrade reboot (F35 to F37) at the white login screen, I went to system-settings and select again "breeze fedora theme" as option for the login screen (it was deselect at first), then I rebooted the VM and sddm started with the plasma default background, as seen on this print.

Created attachment 1916631 [details]
Correct sddm at first boot after distro upgrade (F36=>F37)

This time, for a upgrade F36KDE to F37KDE, sddm shows correctly with right background.
Strangely, looking for journalctl and coredumpctl it has the same behavior as the F35 upgraded one, with xdg-desktop-portal-kde dumping core at boot.

Created attachment 1916632 [details]
Backgrounds and SDDM version of the F36=>F37 setup

It seems my F36 VM used a mirror with different package versions at upgrading, than the F35 one, resulting in these final setup at F37 after upgrade.

Created attachment 1916633 [details]
Backgrounds and SDDM version of the F35=>F37 setup

This setup resulted in the broked SDDM login screen.

Created attachment 1916634 [details]
New package versions after upgrade at the F36=>F37 VM

After running dnf upgrade on the new F37 upgraded machine, I endet up with this packages, and login screen broked just as the other F35/F37 one.

Created attachment 1916635 [details]
SDDM login screen broked at the F36=>F37 VM

With new packages, sddm broke.

So, some notes here. The update for F37 is blocked in testing because of various issues with the attempted webp transition - https://bodhi.fedoraproject.org/updates/FEDORA-2022-a5622b766b . So this doesn't necessarily need to be a release blocker or FE as the problems aren't in stable.

Also there has already been some discussion of this problem on the update, starting at https://bodhi.fedoraproject.org/updates/FEDORA-2022-a5622b766b#comment-2737384 . I'm not sure why openQA didn't catch this (or I didn't spot it) with earlier versions of the update, but people did catch it in manual testing. The latest f37-backgrounds - f37-backgrounds-37.0.4-1.fc37 - looks like it attempts to fix this already, so we need to test with that, I guess.

(In reply to Adam Williamson from comment #15)
> So, some notes here. The update for F37 is blocked in testing because of
> various issues with the attempted webp transition -
> https://bodhi.fedoraproject.org/updates/FEDORA-2022-a5622b766b . So this
> doesn't necessarily need to be a release blocker or FE as the problems
> aren't in stable.
> 
> Also there has already been some discussion of this problem on the update,
> starting at
> https://bodhi.fedoraproject.org/updates/FEDORA-2022-a5622b766b#comment-
> 2737384 . I'm not sure why openQA didn't catch this (or I didn't spot it)
> with earlier versions of the update, but people did catch it in manual
> testing. The latest f37-backgrounds - f37-backgrounds-37.0.4-1.fc37 - looks
> like it attempts to fix this already, so we need to test with that, I guess.

Adam you're right. I upgraded to desktop-backgrounds-compat-37.0.0-4.fc37.noarch.rpm and restarted, now SDDM is back again with the right background.
I'll give karma on that.

Can we mark this ticket as FIXED? Or is better to whait some more?

Created attachment 1916723 [details]
Cerrected SDDM after new update in bodhi

Now with desktop-backgrounds-compat-37.0.0-4.fc37.noarch.rpm all works fine

Thank you testing, Geraldo and also Adam for the quality check. Closing as fixed on https://bodhi.fedoraproject.org/updates/FEDORA-2022-a5622b766b

This is still broken in today's Rawhide (not F37):

https://openqa.fedoraproject.org/tests/1497723#step/_graphical_wait_login/11

I think this may be because you never built f37-backgrounds -3 or -4 for Rawhide, only for F37. Should -4 also be built for Rawhide?

That was an oversight from my part. The build should be ready by this time of posting:
https://koji.fedoraproject.org/koji/taskinfo?taskID=92804804

Actual build: https://koji.fedoraproject.org/koji/taskinfo?taskID=92804804

So this does seem mostly better now, but openQA still *sometimes* seems to see the blank white background. I'm going to keep an eye on it for a few days to see if this persists once all updates are stable in Rawhide. I definitely don't want us to push the F37 update into Final through the freeze.