Here you can find some simple notes on how to debug Qt / KDE applications.
My focus is on OpenBSD as host system but everything here should work on GNU/Linux.
kDebug() and friends have been deprecated in KDE Frameworks 5 so you have to
use the recommended logging functions qCDebug(category), qCInfo(category),
qCWarning(category) qCCritical(category) to create logs from Qt5/Qt6 applications.
Since Qt 5.2 QLoggingCategory
is available to configure the category and allows us to control the output.
We can control it as follows and this is also the sequence as they are evaluated.
[QLibraryInfo::DataPath]/qtlogging.iniQtProject/qtlogging.inisetFilterRules()QT_LOGGING_CONFQT_LOGGING_RULES
In my default setup I disabled all debug logging in ~/.config/QtProject/qtlogging.ini by a simple rule like this:
[Rules]
*.debug=false
and enable step by step by QT_LOGGING_RULES what I want to see. For example,
debug KDE Frameworks export QT_LOGGING_RULES="kf.*.debug=true"
QT_FORCE_STDERR_LOGGING is a other useful environment variable to help you
to debug from terminal. This ensure all your logs are going to stderr instead
syslog or journald. export QT_FORCE_STDERR_LOGGING=1
A common case is to see default debug messeages without a category like:
qDeug() << "Simple deug log message". This is possible due to the simple
logging rule QT_LOGGING_RULES="default.debug=true".
The pattern is always the same. Search for Q_DECLARE_LOGGING_CATEGORY to
identify the log name and filter it with QT_LOGGING_RULES
Here you can find example: codesearch.debian.net - Q_DECLARE_LOGGING_CATEGORY
You can set the QT_LOGGING_DEBUG environment variable to find out where your
logging rules are loaded from.
For more informations checkout QLoggingCategory docs.
A lot has happened since the last OpenBSD KDE Status Report in 2021. Let’s split the report in four areas the good, the
bad, the plasma and libinput.
% The good
We welcome Qt6 into OpenBSD! Our Telegram client port (net/tdesktop) depends on
it and kn@ is actively maintaining the client.
tdesktop always quickly goes
with the latest Qt6 version. So there is always some pressure for us to keep
Qt6 up-to-date. I think this will pay off when KDE switches to Qt6.
Besides tdesktop security/qdigidoc4 and net/wireshark also use Qt6 by now.
I have enabled devel/libinotify support in most of the KDE applications and
libraries. It brings support for recursive file watching. Some KDE applications
are fairly hungry for file descriptors and the default limits may be
insufficient.
When crashes occur, it is advisable to increase your file descriptor limits for
your $USER. Checkout login.conf(5) and don’t forget to rebuild the
login.conf.db file (if necessary):
[ -f /etc/login.conf.db ] && cap_mkdb /etc/login.conf
Note that in addition to ulimits, there is a kernel-level file descriptor limit
which may also need to be adjusted. This limit is managed through the
kern.maxfiles sysctl(8).
Many cases known to me have happened with net/nextcloudclient. Of course,
depending on your file count to sync.
- Qt 6.4.1
- Qt 5.15.7
- Qt Creator 8.0.2
- KDE Frameworks 5.101.0
- NEW: KQuickCharts, KCalendarCore, KWayland (Only for dependencies)
- REMOVED: kdewebkit and kjsembed. This are “KDE Porting Aids” ports, that means it provides code and tilities to ease the transition from kdelibs 4 to KDE Frameworks 5.
- KDE Applications 22.12.0
- NEW: KAccounts, kipi-plugins, kirigami-gallery, kontrast, kopeninghours
- NEW in the KDE Gear familia
- KMyMoney 5.1.2
- digiKam (graphics/digikam) 7.9.0
- Krita (graphics/krita) 5.1.4 + krita-gmic-plugin 3.1.6.1
Besides the list above, many many small and large bugfixes have been made.
% The bad
For a long time there has been a really annoying crash in all KDE applications. For example:
- You will just copy/paste a file in dolphin file browser.
- “Save as” in Okular - Universal Document Viewer.
Example trace
#0 FileProtocol::copy (this=0x982b59a6f80, srcUrl=..., destUrl=..., _mode=-1, _flags=...)
at /usr/ports/pobj/kio-5.101.0/kio-5.101.0/src/ioslaves/file/file_unix.cpp:678
#1 0x00000982554ded53 in KIO::SlaveBase::dispatch (this=0x982b59a6f90, command=<optimized out>,
data=...) at /usr/ports/pobj/kio-5.101.0/kio-5.101.0/src/core/slavebase.cpp:1364
#2 0x00000982554d8d05 in KIO::SlaveBase::dispatchLoop (this=0x982b59a6f90)
at /usr/ports/pobj/kio-5.101.0/kio-5.101.0/src/core/slavebase.cpp:339
#3 0x0000098255570803 in KIO::WorkerThread::run (this=0x9832384ca40)
at /usr/ports/pobj/kio-5.101.0/kio-5.101.0/src/core/workerthread.cpp:62
#4 0x00000982b662028c in QThreadPrivate::start(void*) () from /usr/local/lib/qt5/./libQt5Core.so.4.0
#5 0x00000983214cb0b1 in _rthread_start (v=<optimized out>) at /usr/src/lib/librthread/rthread.c:96
#6 0x00000982d7ad5f6a in __tfork_thread () at /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:84
cad/qcad core dumped at start time and devel/qbs at build time.
However, the bug hunting continues.
% The Plasma
This will come as a surprise to some, but I was able to port (almost) all KDE
Plasma components to OpenBSD. You can find all my work on GitHub in the sizeofvoid/wip-ports repository, branch kde-plasma-wip, directory x11/kde-plasma.
I’ve been working on it for a very long time. At some point I was so frustrated that we don’t have UDev and libInput.
Read more here: OpenBSD and Wayland
@robert fixed the UDev problem for me by import libudev-openbsd; a udev compatible library based.
I started to fake lib(open)input a fork of
https://gitlab.freedesktop.org/libinput/libinput.
It is an attempt to extend libinput so that it works with wscons(4) and
kqueue(2) and thus on OpenBSD. For now it’s a stubbed, libinput-1.17.0
compatible API, which is okay since we only need it in conjunction with
Wayland which is currently default off.
The good so far, it already starts:
To build WIP kde-plasma you have to clone the repository and build the port:
git clone -b kde-plasma-wip git@github.com:sizeofvoid/wip-ports.git
cd wip-ports/x11/kde-plasma
# Adjust PORTSDIR in /etc/mk.conf
# Example PORTSDIR_PATH=/usr/ports/mystuff/wip-ports:$(PORTSDIR)
make install
To start KDE Plasma I use the following ~/.xsession. Do not
forget to start DBus rcctl enable messagebus && rcctl start messagebus. Everything communicates via DBus.
# Set to 1 to debug plugins
export QT_DEBUG_PLUGINS=0
# Lets be noisy
export QT_LOGGING_RULES="*.debug=true;qt.*=false"
export XDG_SESSION_TYPE="x11"
export QT_QPA_PLATFORM="xcb"
export QT_QPA_PLATFORMTHEME=KDE
export XDG_CURRENT_DESKTOP=KDE
export KSCREEN_BACKEND=QScreen
export KDE_FULL_SESSION=1
export KDE_SESSION_VERSION=5
# See https://github.com/sizeofvoid/wip-ports/commit/13d490ffca9447788b568c3fb486de1b20c6b026
export QT_OPENBSD_SHM_MODE=1
# If your users intend to develop applications against this build,
# ensure that the IDEs they use either set QT_FORCE_STDERR_LOGGING to 1
export QT_FORCE_STDERR_LOGGING=1
# Start KDE Plasma Shell
exec /usr/local/bin/plasmashell --replace > ~/plasma.log 2>&1
Currently it looks like KDE Plasma and applications lose the connection to our
X11 server. Applications that start in KDE Plasma starts without a window
frame.
Here are the logs for the issue.
Nov 17 18:40:42 fuckup plasmashell: The X11 connection broke (error 1). Did the X11 server die?
Nov 17 18:40:42 fuckup kactivitymanagerd: The X11 connection broke (error 1). Did the X11 server die?
Nov 17 18:40:42 fuckup kglobalaccel5: The X11 connection broke (error 1). Did the X11 server die?
Nov 17 18:40:42 fuckup kglobalaccel5: The X11 connection broke: I/O error (code 1)
Nov 17 18:40:42 fuckup kded5: The X11 connection broke (error 1). Did the X11 server die?
Nov 17 18:40:42 fuckup kscreen_backend_launcher: The X11 connection broke (error 1). Did the X11 server die?
Nov 17 18:40:42 fuckup akonadi_contacts_resource: The X11 connection broke (error 1). Did the X11 server die?
Nov 17 18:40:42 fuckup akonadi_control: The X11 connection broke (error 1). Did the X11 server die?
Nov 17 18:40:42 fuckup akonadi_maildir_resource: The X11 connection broke (error 1). Did the X11 server die?
Nov 17 18:40:42 fuckup akonadi_migration_agent: The X11 connection broke (error 1). Did the X11 server die?
Nov 17 18:40:42 fuckup akonadi_akonotes_resource: The X11 connection broke (error 1). Did the X11 server die?
Nov 17 18:40:42 fuckup akonadi_maildispatcher_agent: The X11 connection broke (error 1). Did the X11 server die?
Nov 17 18:40:42 fuckup akonadiserver: org.kde.pim.akonadiserver: Control process died, committing suicide!
Nov 17 18:40:42 fuckup akonadi_birthdays_resource: The X11 connection broke (error 1). Did the X11 server die?
Nov 17 18:40:42 fuckup baloorunner: The X11 connection broke (error 1). Did the X11 server die?
Nov 17 18:40:42 fuckup akonadi_ical_resource: The X11 connection broke (error 1). Did the X11 server die?
Nov 17 18:40:42 fuckup akonadi_newmailnotifier_agent: The X11 connection broke (error 1). Did the X11 server die?
Anyway, troubleshooting continues here as well.
I hope this blog post could give you a good insight about the current KDE
status on OpenBSD. Thanks kn@ for the English proofreading!
As you can imagine, working on such a large number of ports is very time consuming.
I am happy about any feedback and of course about any kind of support.
GitHub Sponsors
UPDATE
The “copy & paste” and “save as” issues in Okular and Dolphin are fixed with kio-5.101.0p0
Committed here: https://marc.info/?l=openbsd-ports-cvs&m=167286456813105&w=2
Since I have been living near Stuttgart for over a year I decided to travel to
g2k22 by bike.
The days before g2k22 I was a little unmotivated because I didn’t know what to
work on. My yearly huge KDE Gear update to 22.08 was already committed. Even CMake
2.24.1 has already made it in.
When I arrived at the castle, I met sdk@ first. I asked him if he could build
the Qt6 for me and at the and of the first day I got an OK from him and we have
almost Qt6 imported in OpenBSD now. Of course without x11/qt6/qtwebengine I’ll
hack on it if we see consumers otherwise wasting several hours of work makes no
sense.
Next “big” thing on my list was cmake.port.mk. I thought we could certainly
improve that. I end up with 3 changes:
-
Use cmake(1) and ctest(1) instead of ninja(1)
cmake(1) controls the build and install task/jobs. This is the way
CMake prefers and it works very well for us. Full bulk build passed!
Victims already fixed.
-
Remove USE_NINJA from consumers
Is no longer necessary but still optional (requested by sthen@). This diff
removes all usage. Expect www/h2o (see at ports@) This is possible because of
the use of cmake(1).
-
Improve Verbose mode
Before:
===> Regression tests for cmark-0.30.2p0
Test project /usr/ports/pobj/cmark-0.30.2/build-amd64
Start 1: api_test
1/9 Test #1: api_test ......................... Passed 0.01 sec
Start 2: html_normalization
2/9 Test #2: html_normalization ............... Passed 0.16 sec
Start 3: spectest_library
With the new option MODCMAKE_VERBOSE (default to yes):
===> Regression tests for cmark-0.30.2p0
UpdateCTestConfiguration from :/usr/ports/pobj/cmark-0.30.2/build-amd64/DartConfiguration.tcl 21:09:28 [17/151]
Test project /usr/ports/pobj/cmark-0.30.2/build-amd64
Constructing a list of tests
Done constructing a list of tests
Updating test list for fixtures
Added 0 tests to meet fixture requirements
Checking test dependency graph...
Checking test dependency graph end
test 1
Start 1: api_test
1: Test command: /usr/ports/pobj/cmark-0.30.2/build-amd64/api_test/api_test
1: Working Directory: /usr/ports/pobj/cmark-0.30.2/build-amd64/testdir
1: Test timeout computed to be: 10000000
1: 539 tests passed, 0 failed, 0 skipped
1: PASS
1/9 Test #1: api_test ......................... Passed 0.01 sec
test 2
Start 2: html_normalization
2: Test command: /usr/local/bin/python3.9 "-m" "doctest" "/usr/ports/pobj/cmark-0.30.2/cmark-0.30.2/test/normalize.py"
2: Working Directory: /usr/ports/pobj/cmark-0.30.2/build-amd64/testdir
2: Test timeout computed to be: 10000000
2/9 Test #2: html_normalization ............... Passed 0.16 sec
That was easier than I thought and tb@ was kind enough to start an bulk build
for me. Expect from 2-3 broken ports not much had been broken. I was able to
fix the two victims quickly. I’m starting to be really happy with our CMake
port and module.
Apart from that, here’s a short list of what I’ve been working on.
- devel/boost 1.80
- cad/qcad
- gpgme to 1.18.0
- Remove mlt6 and webvfx
- Update quazip to 1.3
- chessx to 1.5.6
- krita to 5.1.0
- doxygen to 1.9.5
- cmark to 0.30.2
- textproc/codespell
- misc/open62541
- meta/qt5
- fonts/font-awesome
- devel/jenkins/devel
- sysutils/krename
- www/h2o
- meta/qt6
- multimedia/assimp
- net/neochat
- devel/cmocka
All in all I can look back on a really successful hackathon. Since I mainly
operate only in ports, it was nice to meet people from the kernel space. On
Monday morning I left the castle in the direction of Nürnberg where I worked
for a customer for the next two days.
Thank you very much to Genua, the team from Burg
Liebenzell
and jan@ for organizing a great hackathon.
The last few days I jumped into the next rabbit hole and I would like to share
some thoughts. With the helpful patches from FreeBSD I was able to quickly
achieve success and port the Wayland base applications/libraries:
- wayland-1.19.0
- wayland-protocols-1.23
- wayland-utils-1.0.0
After this quick one I was all excited, “hey this works way too well”. Time to
become skeptical. But first let’s jump into the wonderful world of KDE/Qt5. Porting QtWayland, KWayland and plasma-framework with Wayland enabled much easier than thought.
I figured even if this whole Wayland construct doesn’t work, fine, just
resolving the dependencies is enough for me to port the KDE Plasma Desktop to OpenBSD.
At the point where I wanted to build KWin and SWAY I saw the full extent of the horror.
Wayland is a drop in the bucket, we need to port the following libraries/applications:
When I read udev in the context of OpenBSD, my stomach turns. Welcome to the
rabbit hole, welcome to hell.
But there seems to be a way out, a shortcut? Maybe: devd(8) from FreeBSD.
If we could port devd to OpenBSD or replicate functionality we would have a
good chance. We would have that the possibilities to port
libudev-devd. This could
solve the missing udev problem under OpenBSD, which would be very helpful for
porting all other new stuff.
It would be worth a try, wouldn’t it?
You can find my work here: GitHub wip-ports kde-plasma-wip branch
2021-12-16 UPDATE:
The following Wayland applications/libraries were committed. That does not mean
that they are useful or you can use wayland. They only serve as a dependency
to build certain ports in the first place.
- wayland-1.19.0
- wayland-protocols-1.23
- wayland-utils-1.0.0
- kwayland-5.88.0
- qtwayland-5.15.2
This also applies to wayland/xwayland
In summary, there will be no Wayland in OpenBSD any time soon. Too few, if any, people are working on a solution here.
YOU CAN CHANGE THAT!
OpenBSD has managed to drop KDE3 and KDE4 in the 6.8 -> 6.9 release cycle. That
makes me very happy because it was a big piece of work and long discussions.
This of course brings questions:
Kde Plasma 5 package missing.
After half a year of work, I managed to successfully update the Qt5
stack to the last LTS version 5.15.2. On the whole, the most work was updating
QtWebengine. What a monster. With my CPU power at home, I can build it 1-2
times a day which makes tasting a little bit annoying and time intensive.
But today we can be happy about an up-to-date KDE stack in OpenBSD.
Currently - at the end of January - our stack is very up-to-date:
- Qt 5.15.2
- Qt Creator 4.14.0
- KDE Frameworks 5.78.0
- KDE Applications 20.12.1 (Almost everything!)
- Kdevelop 5.6.1
- Kirta 4.4.2
- KMyMoney 5.1.1
- DigiKam 7.1.0
I try to keep KDE Applications 20.12.x stable until the 6.9 release.
Let’s move on to the topic of KDE Plasma. The Plasma desktop and some other KDE
applications have a strong dependence on the Wayland. As long as there is no
Wayland under OpenBSD, there will also be no KDE Plasma.
It can be observed that more and more KDE applications already prefer a strong
dependency on Wayland. For example Spectacle.
In summery, no OpenBSD Wayland support no KDE Plasma and probably less and less
KDE applications.