Had you changed the theme to something 3rd party?

Please run /usr/lib/libexec/kscreenlocker_greet --testing

and confirm if this is broken and include output

(In reply to David Edmundson from comment #1)
> Had you changed the theme to something 3rd party?
> 
> Please run /usr/lib/libexec/kscreenlocker_greet --testing
> 
> and confirm if this is broken and include output

If I start /usr/libexec/kscreenlocker_greet it works just fine here. If the lockscreen is triggered by the system it is broken.

~> /usr/libexec/kscreenlocker_greet --testing
Locked at 1650544271
file:///usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/components/UserList.qml:49:9: Unable to assign [undefined] to bool
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()

Does it work on X11, or is it broken there too? (Thanks for using Wayland BTW)

(In reply to Nate Graham from comment #3)
> Does it work on X11, or is it broken there too? (Thanks for using Wayland
> BTW)

This is from X11: Here starting via  /usr/libexec/kscreenlocker_greet works, normal trigger does here simply nothing, also no flickering or black screen.

> /usr/libexec/kscreenlocker_greet --testing
Locked at 1650562857
file:///usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/components/UserList.qml:49:9: Unable to assign [undefined] to bool
file:///usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/lockscreen/LockScreenUi.qml:543: TypeError: Cannot read property 'longName' of undefined
qt.virtualkeyboard.hunspell: Hunspell dictionary is missing for "en_GB" . Search paths ("/usr/share/qt5/qtvirtualkeyboard/hunspell", "/usr/share/hunspell", "/usr/share/myspell/dicts")

And when you run kscreenlocker_greet --testing, the actual UI appears as expected? It looks visually fine there?

Yes, it appears just fine. I already wondered whether it might a config-issue with the unstable-repos in Tumbleweed?
Also the kcm (the setup page to adjust the visual appearance is not working properly (e.g. no field to set a wallpaper ect..)

The KCM issue was something separate that was just fixed yesterday.

This happens because KLibexec looks up kscreenlocker_greet in /libexec, not /usr/libexec.

From strace I ran on a nested Wayland session:

[pid 13948] execve("/libexec/kscreenlocker_greet"

But in openSUSE Tumbleweed it is installed in /usr/libexec.

I had a discussion about it with Fabian on IRC about a possible cause:

[12:35] <fvogt> The relative path is formed by going from /usr/lib64/ to /usr/libexec
[12:36] <fvogt> During runtime the shared library is opened from /lib64/ though, so it tries /libexec
[12:36] <fvogt> i.e. incompatible with usrmerge
[12:37] <fvogt> At least that's my theory

(In reply to Luca Beltrame from comment #8)
> This happens because KLibexec looks up kscreenlocker_greet in /libexec, not
> /usr/libexec.
> 
> From strace I ran on a nested Wayland session:
> 
> [pid 13948] execve("/libexec/kscreenlocker_greet"
> 
> But in openSUSE Tumbleweed it is installed in /usr/libexec.
> 
> I had a discussion about it with Fabian on IRC about a possible cause:
> 
> [12:35] <fvogt> The relative path is formed by going from /usr/lib64/ to
> /usr/libexec
> [12:36] <fvogt> During runtime the shared library is opened from /lib64/
> though, so it tries /libexec
> [12:36] <fvogt> i.e. incompatible with usrmerge
> [12:37] <fvogt> At least that's my theory

Looks like my theory is correct.

libkscreenlocker is built with /usr/lib64 as full libdir path and /usr/libexec as full libexec path, so it tries to reach the greeter by doing $self/../libexec/kscreenlocker_greet. In a usr-merged system, /lib64 is a symlink to /usr/lib64 (or the other way around), so /lib64/libKScreenLocker.so.5.24.80 and /usr/lib64/libKScreenLocker.so.5.24.80 refer to the same file. As /lib64 is earlier in the library search path than /usr/lib64, the library is loaded as /lib64/libKScreenLocker.so.5.24.80 and the path ends up as /lib64/../libexec/.

It works after forcing /usr/lib64/ earlier in the search path than /lib64.

Moving this over to kcoreaddons as the issue is with KLibexec.

For completeness, a quick discussion with sitter on IRC/matrix:

[11:51] <sitter[m]> so we could consider either the ld_library_path wrong, or the fact that libexec is in /usr (and then not symlinked), or that kscreenlocker should hardcode the build time libexec location as final fallback. the latter is why I imagine this isn't also failing for KIO because there we should have that final fallback
[11:52] <fvogt> Qt has different builds for relocatable and non-relocatable
[11:53] <fvogt> That might be an option as well, if it's not a use case to put system frameworks into some other location
[11:53] <sitter[m]> that'd be where the final fallback comes in IMO
[11:54] <sitter[m]> on systems where relocatability doesn't matter we'll find libexec in the buildtime location anyway so klibexec is only extra sugar there
[11:54] <fvogt> Having an optional final fallback which has to be done explicitly in every use of klibexec seems fragile
[11:55] <sitter[m]> yes. I am leaning towards saying you should symlink libexec ;)
[11:55] <sitter[m]> or patch klibexec to never be relative maybe
[11:56] <fvogt> At some point libexec was below lib64, but that was changed some time ago...
[11:56] <sitter[m]> https://invent.kde.org/frameworks/kcoreaddons/-/merge_requests/142#note_383993
[11:57] <sitter[m]> perhaps the answer should be a builtime switch to make klibexec return a fixed prefix 🤷
[11:58] <fvogt> To have the inline functions in klibexec.h just return the full libexecdir path, effectively like before?
[11:59] <sitter[m]> it all seems equally suitable to my mind. but I would argue that not having libexec inside a lib location goes against the spirit of usrmerge
[11:59] <sitter[m]> the point of it is to get rid of the separation of / and /usr, but then having libexec only in one location is undermining that
[11:59] <sitter[m]> fvogt: yep
[11:59] <fvogt> https://fedoraproject.org/wiki/Features/UsrMove agrees with not having /libexec
[12:02] <sitter[m]> fair point. still violates the motivation from my POV if the library location then resolves to / and not /usr
[12:03] <sitter[m]> all that said, I would give a +1 to an MR that adds a full libexecdir switch to kcoreaddons ^^
[14:53] <fvogt> sitter[m]: Adding the libexecdir switch to kcoreaddons assumes that kcoreaddons is built with the same full libexecdir as its users which might not be the case
[14:53] <fvogt> Not sure how to get the application/library's full libexecdir into klibexec.h

We also have the option to revert: 13ae6539794c0c7b3019cb843f4b3c90db3cf675 in kscreenlocker.

That pushes the can down the road instead of fixing it but it's worth mentioning as an option. Also explains why 5.24 works correctly.

*** Bug 453210 has been marked as a duplicate of this bug. ***

(In reply to David Edmundson from comment #11)
> We also have the option to revert: 13ae6539794c0c7b3019cb843f4b3c90db3cf675
> in kscreenlocker.
> 
> That pushes the can down the road instead of fixing it but it's worth
> mentioning as an option. Also explains why 5.24 works correctly.

+1. For issues like these I'm generally in favor of "revert first, fix later".

Git commit 4485c8ca5ec818da5588d7835adb63d5ee6eb30b by Fabian Vogt.
Committed on 12/05/2022 at 08:08.
Pushed by fvogt into branch 'master'.

Add fallback to the absolute path to kscreenlocker_greet

KLibexec doesn't work on usr-merged distros as libraries can be loaded
through a different path (/lib*) than they are installed to (/usr/lib*).

M  +4    -2    CMakeLists.txt
M  +1    -1    greeter/autotests/CMakeLists.txt
M  +2    -2    greeter/autotests/killtest.cpp
M  +6    -1    ksldapp.cpp

https://invent.kde.org/plasma/kscreenlocker/commit/4485c8ca5ec818da5588d7835adb63d5ee6eb30b

thanks, works again in Tumbleweed.