Can't start KDE kcminit_startup fails to start due to incompatible Qt library 6.7.1 with "this library" 6.7.2

Help
1

When I try to start a KDE Plasma session from SDDM it times out on the spinning cog, and ~/.local/share/sddm/xorg-session.log contains, in part:

QIODevice::readLine (QFile, "/home/test/.config/kdedefaults/package"): device not open
QPixmap: QGuiApplication must be created before calling defaultDepth().
QPixmap: QGuiApplication must be created before calling defaultDepth().
Initializing  "/usr/lib/qt6/plugins/plasma/kcms/systemsettings/kcm_mouse.so"
Initializing  "/usr/lib/qt6/plugins/plasma/kcms/systemsettings/kcm_style.so"
Initializing  "/usr/lib/qt6/plugins/plasma/kcms/systemsettings/kcm_fonts.so"
org.kde.plasma.session: process job  "kcminit_startup" finished with exit code  0
Cannot mix incompatible Qt library (6.7.1) with this library (6.7.2)

I don’t know what “this library” refers to, but maybe systemsettings?

I tried with an entirely new user on my system and had the same results.

I’m on Artix Linux.

I’ve done an update but weirdly the problems didn’t seem to start until sometime after updating. Suddenly alt tab stopped working and other basic KDE functionality, like the meta button opening my launcher.

Does anyone know how to get more information and/or fix this?

pacman shows I have version 6.7.2-1 of qt6-base. pkgfile reports that kcm_fonts.so (if that’s the issue, in systemsettings) is provided by:

$ pkgfile /usr/lib/qt6/plugins/plasma/kcms/systemsettings/kcm_fonts.so
world/plasma-workspace
extra/plasma-workspace

$ pacman -Qi plasma-workspace
Name            : plasma-workspace
Version         : 6.1.0-1
Description     : KDE Plasma Workspace
Architecture    : x86_64
URL             : https://kde.org/plasma-desktop/
Licenses        : LGPL-2.0-or-later
Groups          : plasma
Provides        : None
...
powerdevil-light  xdg-desktop-portal-kde
Optional For    : openbox
Conflicts With  : plasma-wayland-session
Replaces        : plasma-wayland-session
Installed Size  : 54.50 MiB
Packager        : nikolar <nikolar@artixlinux.org>
Build Date      : Thu 20 Jun 2024 10:09:17 AM MDT
Install Date    : Mon 24 Jun 2024 09:33:05 PM MDT
Install Reason  : Explicitly installed
Install Script  : No
Validated By    : Signature

Is plasma-workspace broken upstream? How can I find out what component is still trying to use 6.7.1 when the log message is so unclear? Would it be in other logs?

2

Your operating system seems to have updated your Qt installation to 6.7.2 while still shipping Plasma packages that were built with 6.7.1 - this will not work.

Artix should have only published Qt 6.7.2 either in addition to the previous version that worked or make sure that all Qt depending packages have been rebuilt with the new version. You should complain to your operating system support.

3

Is there some specific Plasma component that’s causing it? Apparently others on my distro (artix) aren’t having this issue.

4

All KDE components are built with Qt and Qt linking always require exact version.

If other people aren’t getting this error - they either didn’t get Qt version update, or the already got the rebuilt Plasma packages.

5

There must be something else, some component stuck not updated in my system, as otherwise it’d be widely reported.

Is there any additional logging I can enable to see what component KDE isn’t happy with?

If it’s linked to the wrong version, I could run ldd on the binary and find it, if I knew which binaries to search for.

6

This really is a discussion for your operating system support - I’m not familiar with Atrix so cannot explain to you how to check for stuck updates or package versions, I don’t know how Atrix developers package the different plasma components and I cannot tell you how to enable more logging on Atrix. Especially as you seem to be running X11 and aren’t using systemd initialization - which is not a common scenario.

The log file you started this thread with seems to have some information - likely it has more, but your OS support forums - where the are people familiar with Atrix integration choices - will be a better place for this discussion.

7

Artix is a distro (not an operating system). KDE is the software it’s running. I’m wondering if there’s a mechanism in KDE Plasma that allows me to get more log output prior to the message about 6.7.1 in my original post. That error is being generated by KDE as it attempts to initialize.

If my distro is responsible for a broken package situation, then it would have caused the circumstances that led to that message being printed, but KDE itself should be able to give me information (I hope) about where it’s failing in the initialization process. So far I’ve only been able to identify that log file (again its presence, contents, and path chosen by KDE, not by my distro).

I am asking on the Artix forums if there’s something broken related to package management or from the maintainer of the package that ships KDE and QT. But the specific questions I have here are relevant to KDE, and I’m hoping someone will have knowledge about something like an environment variable or config file where I can up the verbosity of the log output to see more of what’s causing the failure.

I also think your premise that this is caused by Artix’s integration choices is something I’ve ruled out. This situation would’ve been widely discussed if it was something that isn’t specific to my system. So again, I’m on an information-gathering mission.

8

This is not true. I’m using KDE Neon and I don’t have that log file. That log file appears to be generated by SDDM but on Neon that file didn’t get created especially not in that location.

The startup process, the location of files on your system and what processes are run at what point is mostly up to your operating system (or call is distribution, whatever floats your boat).

9

The exact string is in KDE’s corelib

There’s android-qt5-qtbase but I’m sure if it’s there, it’s elsewhere. This isn’t coming from Artix or SDDM. SDDM is attempting to start the session and handling the stdout and stderr (presumably) and putting it in that log file. SDDM isn’t unique to Artix, and it’s KDE’s recommended display manager for KDE Plasma.

This does hint at the idea that sddm has a configuration issue or is linking to a theme that may be the issue. I may try another DM.

10

I meant that your claim that “that log file […] its presence content and path are chosen by KDE” - is not true.

The error about mixing libraries is from Qt, not from KDE, and it is a well known behavior.

If there is a configuration issue with SDDM or with a theme - that is also a decision by Atrix.

From my perspective this thread is closed and I will not be monitoring it further.

11

Technically correct: it’s chosen by KDE’s choice in DM.

Is it well known how to gain more information about what component is throwing this issue?

That’s fine, cheers. I’m looking for a way to find more information about the error and what’s throwing it. This isn’t an issue that my distro can help with, and I’ve already ruled out that it’s something coming from their default config. It’s something specific to my system.