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:
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.
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.
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:
Should I write a blog post about my KVM #OpenBSD workstation, #Linux/OpenBSD ThinkPad and MacBook setup? IMHO Perfect cable management with a IKEA standing desk. Anyway, finally done my new setup. pic.twitter.com/RE0gb56i8N
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.
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:
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.
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 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:
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.
