Note: this bug has been successfully reproduced on 5 different machines, Fedora 23: I updated from Plasma 5.5.5 to 5.6.2 and now after the login: - every single window's namebar is not shown, you cannot resize, minimize, maximize it; - panel's taskbar entries are missing - the panel size is wrong (see screenshot) and you cannot extend it back again - the whole Plasma is unusable I also need help in starting GDB and Valgrind from TTY since I cannot use "kquitapp5 plasmashell" and again "gdb plasmashell", because Konsole will disappear as soon Plasma restarts. Guide https://techbase.kde.org/Development/Tutorials/Debugging/Debugging_with_GDB does not help. I have been able to reproduce this bug on 2 real machines and 3 virtual machines Reproducible: Always
Created attachment 98477 [details] screenshot
Created attachment 98478 [details] xsession-errors
Ops I forgot to delete the first line of message
Fedora bugreport https://bugzilla.redhat.com/show_bug.cgi?id=1328942
Appears user updated to kwin-5.6.x , but (probably) missed upgrading kscreenlocker-5.6.x along with it (and tried using kscreenlocker-5.5.x), resulting in missing symbols: kwin_x11: symbol lookup error: /lib64/libkwin.so.5: undefined symbol: _ZN12ScreenLocker7KSldApp16lockStateChangedEv Shouldn't libKScreenLocker soname get bumped for the new symbol?
The problem was that entering # dnf update kf* plasm* --enablerepo=updates-testing the system did not update kscreenlocker package
It's not resolved (re-opening), I'd still argue upstream should consider bumping libKScreenLocker soname
triaging to kscreenlocker component
Ok
sorry kscreenlocker is not yet in a quality from library point of view that we can ensure it's properly so-bumped. It doesn't follow any library guidelines, no d-ptr, etc. etc. kscreenlocker is part of Plasma and used in plasma-workspace and KWin. Those products release together and need to be updated in lock-step anyway. If distributions cannot ensure that those get updated together, please so-bump kscreenlocker manually.
Fair enough, but I'm curious how distributors (or users even) are expected to know that which libraries can be trusted to be "properly so-bumped", "follow any library guidelines", etc... I'd go so far as say if you cannot guarantee soname compatibility, then some suggestions to help make that clearer to everyone: * clearly advertise/document it * bump soname for *every* release, or even don't use a soname at all * name the library to make it painfully obvious, ie, use "private" or "experimental" in the library name
If I had enough time for this I would have made it a proper library. Alas I didn't have the time. This included that I didn't have the time to so-bump it. And it also didn't occur to me as the products are released together. Sorry about that.