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.
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: 100000001: 539 tests passed, 0 failed, 0 skipped
1: PASS
1/9 Test #1: api_test ......................... Passed 0.01 sectest 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: 100000002/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
Update to 1.80 and backport some patches from upstram:
Fix: Boost.Unordered containers are not in a valid state after moving
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.
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!
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.
Dscf0250
Dscf0256
Dscf0298
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.
Dscf0349
Dscf0350
Dscf0352
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.
