>>

Qt / KDE Controlling Debug Messages

5 Jan 2023

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.ini
  • QtProject/qtlogging.ini
  • setFilterRules()
  • QT_LOGGING_CONF
  • QT_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.

OpenBSD KDE Status Report 2022

27 Dec 2022

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.

% libinput - fake it until you make it.

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

g2k22 - OpenBSD hackathon Burg Liebenzell

23 Sep 2022

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
    • qcad to 3.27.6.7
  • 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.

OpenBSD and Wayland

26 Sep 2021

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 KDE Status Report 2021

23 Jan 2021

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.

Workstation setup

23 Dec 2020

In the days when almost everyone works from home, it seems a good time to write about my workstation setup at home. I built my dream setup some months ago, before COVID19, and finished it at the beginning of the year. My first tweet followed in February:

Timing is everything.

Here is a list of my requirements for a modern setup/desk:

  • Height adjustable
  • Solid wood plate
  • No cable spaghetti
  • Few to no visible cables
  • Suitable for a minimum of 3 devices:
    • OpenBSD workstation
    • OpenBSD/Linux ThinkPad with docking station
    • MacBook Pro from my company
  • Easy to switch among devices
    • Use one main keyboard and mouse for all devices
  • It should look good.

Standing Desk

I think IKEA has the best value for money. The table is very solid and high quality. I have installed a socket and a cable bushing on the left and right side. It’s really easy to drill through the desk. On the left side I have the socket with USB connection, and on the right side are cables for charging daily devices.

IKEA 160x80 cm Standing Desk

Switching among devices

I solved the switching problem a long time ago. For this I use:

Originally, I had it on the table under my monitor. During my big reconstruction, I put it under the table. I just put some glue on it and, to my surprise, it worked very well. I used the following product:

Pattex Montagekleber Kleben statt Bohren Wasserresistent

Cable spaghetti challenge

To solve the cable spaghetti problem I bought the following products from ebay(.de) and Amazon(.de) and installed them:

Keyboard

In early 2018 I decided to buy an ergonomic keyboard. It was a hard decision, but in the end I decided to buy ErgoDox EZ. The keyboard is really expensive. Okay, that I knew, but what really annoyed me were the stress at customs and the handling charges. I paid about 60 Euro in customs duty in addition to the purchase price. If you want to be an ErgoDox EZ EU consumer, you have to dig deeply into your pockets. Anyway, I do not regret my decision! I can write very well and quickly with ErgoDox, but I lose the ability to write with a normal keyboard. This is not a problem in the times of COVID19 and the home office, but when I am on-site at a customer it is often annoying to work without the ErgoDox EZ.

You can find my latest layout here: ErgoDox EZ

Thanks Pamela for the proof-reading!

k2k20 - OpenBSD Hustenthon Burg Liebenzell

21 Sep 2020

First of all let’s talk about the word Hustenthon. Husten is the German word for cough(ing). A small allusion to the current COVID19 situation. (This article does not intend to make an assessment of or talk about COVID19).

Due to the pandemic, this hackathon seemed to be called very spontaneously. Fortunately, the hackathon was over a weekend. This enabled me to attend without missing any professional obligations. On Friday morning, shortly after sunrise, I took the train to Bad Liebenzell. On the train I worked for my employer until I reached Karlsruhe at about 11am. I swapped my MacBook for my OpenBSD ThinkPad T470s.

Only a few days before the hackathon I had committed the big KDE frameworks 5.73.0 and KDE applications 20.08.0 update. With perfect timing, of course, because 1-2 days later 20.08.1 was released. So I had enough time the week before the hackathon to prepare a update diff.

I spent the time in the Bummelbahn (a small and slow train) from Karlsruhe to Bad Liebenzell reviewing my 20.08.1 update diff again. Arrived in the hackroom and connected via em0, my first action was to commit the update. I had a rough plan of what I wanted to do during the weekend: Focus on KDE bugs. Push more OpenBSD-related KDE patches upstream. This worked well in the weeks before the hackathon and you can see first bits landed in KDE Frameworks 5.74.0.

On ports@ I found security/qtpass which interested me as I always try to have a look at new Qt applications to import. Next was sysutils/htop and then security/qca-qt5. Then I got the stupid idea to commit my games/nethack Qt3 removal which ended up with a lot of noise and two additional commits. If there is one thing I have learned over the years, it is that strong nerves are needed to touch old ports-stuff. It is very difficult to work on such large submodules without stepping on someone’s feet from time to time.

Speaking of large submodules, Qt released Qt 5.15.1, the first patch release of Qt 5.15 LTS.

On Saturday, during my morning run, I decided to start working on a Qt 5.15.x update for the next release. Once again, a lot had happened at Qt between our version, 5.13, and the LTS 5.15.1 version. The update has gone well so far. I was able to update all submodules and the first tests were successful. I have tried to update Qt without updating x11/qt5/qtwebengine but it seems to be even more work because you have to fix so many qt-related parts in qtwebengine. I am working on a complete update including x11/qt5/qtwebengine. I’m optimistic.

My logs often contain desktoptojson: vfprintf %s NULL in "Warning: %s(%s:%u, %s) and I found out that this comes from KDE. More precisely, from devel/kf5/kcoreaddons. Quickly found the issue, fixed, sent upstream, merged upstream and committed in CVS.

Based on a very productive devel/kf5/kjs pull request review from upstream, I was able to fix the thread stack base detection in devel/kf5/kjs. The old patch points to the top and not to the base (end) of the thread stack.

I spent some time looking into devel/cmake. There is a sometimes bug in CMake on OpenBSD. This has often been spotted by naddy@. “A shared library has been built with the version number from SHARED_LIBS, but during the fake stage this is forgotten and the upstream version number used instead. This produces an error, because the file doesn’t exist.” – (read more)[https://marc.info/?l=openbsd-ports&m=159733025922436&w=2]

I don’t think I have found this bug but maybe I have. There is a mistake in the cmGeneratorTarget_cxx patch. This creates a wrong scope. this->IsFrameworkOnApple() is present twice and the first one adds a wrong bracket which creates a scope to the end of the whole function. Maybe this triggers our random issues with cmake. We’ll see. More bulk builds will show.

During the Qt 5.15 update I noticed that x11/qt5/qtspeech does not build at all. I looked at our version in CVS and found that it is also broken or useless because it has no backend. A fix was quickly found and I was able to show bluhm@ a voice message via x11/kde-applications/kmouth in the hackroom. Now text-to-speech should again work for all consumers.

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. Thanks pamela@ for the English proof-reading!

This blog post was also published on OpenBSD Journal - undeadly.org

Inspiration from a small town in the Black Forest…

All photos are unedited. License: CC BY-NC 4.0

OpenBSD KDE status 2020

20 May 2020

This short blog post should summarize the KDE/Qt work done in OpenBSD 6.7 and my plans for 6.8.

6.7

The most important achievement was the Qt5 update from 5.9 to 5.13.2. Furthermore, I am very happy that many KDE Applications have made it into the new release. Currently we count 143 KDE5 applications and all KDE Frameworks addon libraries (except Wayland).

The KDE applications are available in version 19.12 and the framework in 5.68.0. In addition, there are some heavyweights in the ports tree:

… and many more exciting KDE/Qt applications.

After the ports-lock

Shortly after the release I committed and announced that I had managed to port the QtWebEngine. All parts are now in the tree and wait until they are unleashed.

It will allow us to port many new applications and give us the opportunity to update a few things. espie@ and tracey@ unbreak kdenlive, which means we have finally a video editor back in OpenBSD.

Next?

As an independent person it is always difficult to plan in the open source environment . Let’s say it like this, I have the following goals for 6.8:

  • Finally enable qtwebengine (easy).
  • Porting the remaining KDE Applications (x11/kde-applications). This is mostly the PIM stuff: Kontact, KMail, KAddressBook KOrganizer https://kontact.kde.org.
  • Get rid of KDE4 (x11/kde4). The conflicts are annoying and nobody uses this stuff anymore. Prove me wrong!

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.


How to build Qt5 applications with CMake on OpenBSD

29 Mar 2020

If you want to develop a Qt application like me on OpenBSD, you may face the same issue. CMake can’t find the Qt modules.

$ cmake -G Ninja -DCMAKE_BUILD_TYPE=Debug ~/src/happy-qt-hacking
-- The C compiler identification is Clang 8.0.1
-- The CXX compiler identification is Clang 8.0.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Error at CMakeLists.txt:18 (find_package):
  By not providing "FindQt5.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "Qt5", but
  CMake did not find one.

  Could not find a package configuration file provided by "Qt5" with any of
  the following names:

    Qt5Config.cmake
    qt5-config.cmake

  Add the installation prefix of "Qt5" to CMAKE_PREFIX_PATH or set "Qt5_DIR"
  to a directory containing one of the above files.  If "Qt5" provides a
  separate development package or SDK, be sure it has been installed.


-- Configuring incomplete, errors occurred!
See also "/home/rsadowski/build-happy-qt-hacking/CMakeFiles/CMakeOutput.log".

This is simply because OpenBSD does not install the Qt5-CMake modules in /usr/local/lib/cmake/ but in /usr/local/lib/qt5/cmake.

In order for find_package to be successful, Qt 5 must be found below the CMAKE_PREFIX_PATH, or the Qt5_DIR must be set in the CMake cache to the location of the Qt5Config.cmake file.

Qt CMake manual

The easiest way to use fix the issue is to set Qt5_DIR

Qt5_DIR=/usr/local/lib/qt5/cmake cmake -G Ninja -DCMAKE_BUILD_TYPE=Debug ~/src/happy-qt-hacking

p2k19 - my first OpenBSD hackathon

3 Mar 2020

When p2k19 was announced, I was quite happy that it was located in Bucharest. A quick check of flight connections, showed that there is a direct connection from Hannover. Without a second thought or planning a vacation, I booked the round trip. I guess I was the first person to put his name under the list.

Booked, signed and forgotten for a while.

Two months before p2k19, kn@ visited me in Hannover for a two person ports hackathon. Since he had already been to a few hackthons, I asked him lots of questions. He told me some stories. He told me to take it easy on the hackathon. “It’s gonna be cool!” After the conversations with kn@ I still did not really know what I would expect. Plus the nervousness. I decided to take kn@’s advice on and just let everything come to me in a very easy way.

After a long Monday working day, I took the train to Airport Hannover where my flight started at 22h. I reached the capital of Romania in time and grabbed a Uber to the hotel. It was my first Uber ride, because it is not allowed everywhere in Germany. I was surprised how easy and stress-free it was. Since then I have often used it in South-East Asia; Grap is more common than Uber which works just as well.

After a short night, I went straight to the hackroom at the University of Bucharest. The room was a Google-sponsored lab from the university. Typical Google colors and quite comfortable and very bright.

I welcomed pvk@ landry@ pirofti@ and immediately started my work. First on my list was deleting the unhooked kde4 ports and cleanup stuff. Then I looked at the ports@ mailing-list and searched for cmake/qt5 ports where I could help. I quickly found nextcloundclient and decided to give it a try. A lot of preparatory work has been done already. I just had to tweak all these little ports-qt5 improvements. After half a day we had a working and good looking port ready.

Besides I took care of the update from KDE4 ports to x11/kde-applications (KDE5). On day two sthen@ surprises me with an OK for the first bunch of KDE5 ports. The morning was spent mostly with cvs madness: cvs import, unhook, cvs commit, cvs remove. Long story short, a time intensive process to replace KDE4 with KDE5 in the CVS tree.

I am a big fan of the Qt5 framework for applications so I try to replace Qt4 applications by Qt5. These applications are mostly no longer being developed and there is often an actively developed Qt5 branch. By the way, I (we) want to get rid of this. So I looked into net/psi and quickly realized that it was broken. No TLS connection to a jabber server was possible. At first I thought psi itself is broken but then I tested other Qt4 programs that establish TLS connections and figured out that our Qt4 SSL runtime was broken. Good that tb@ was sitting at my table. He was able to reproduce the error. His first reaction: “Let’s delete x11/qt4”.

tb@ explained the Qtnetwork LibreSSL patches to me, but we found no bugs and were a bit perplexed at first. I found out that our security/qca port was already outdated and so I updated the qt4 and qt5 variant. The tests were again time consuming, as always by basic libs.

On the 3rd day I finally decided to work on my 5.1X update-diff again. It has been on my mind for a very long time. To my delight, tb@ found a fix for the TLS/Qt4 issue. During the last LibreSSL update something went wrong when merging in Qt4.

My goal for this hackathon was to get at least Qt5base 5.13 to build. A lot has changed between 5.9 and 5.13 in qmake. My biggest challenge was to tell qmake how to deal with the OpenBSD shared library pattern.

On Friday I made the breakthrough and was able to build Qt5base including LibreSSL patches. Since then a lot has happened and I can proudly announce that we can build the complete x11/qt5 subtree in version 5.13.2 and that the first applications are working with it.

It’s still a long way away, but we’re going. My hope is to port a stable state with Qt5.13.x once Qtwebengies. The benefit would be enormous, we could update all old qtwebkit ports.

I really enjoyed the days with the many new (in persona) people. I was able to concentrate completely on OpenBSD for one week, which was great. The good lunches and the events or walking through the city and taking pictures. Bucharest is a wonderful place!

Thank you very much to Paul Irofti, the University of Bucharest, and the OpenBSD Foundation for putting on this hackathon.

This blog post was also published on OpenBSD Journal - undeadly.org

Inspirations of a wonderful city…

All photos are unedited. License: CC BY-NC 4.0