>>

OpenBSD KDE status

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

Bitcoin full node on OpenBSD

25 Nov 2018

In the middle of this year I imported Bitcoin to OpenBSD, so it is available since 6.4 as a package. This blog post would like to give a short guide how to run a full-node on OpenBSD. We are not going to talking about mining-nodes. The following quote best illustrates a full node:

A full node is a program that fully validates transactions and blocks. Almost all full nodes also help the network by accepting transactions and blocks from other full nodes, validating those transactions and blocks, and then relaying them to further full nodes.

bitcoin.org

  1. Install bitcoin, as simple as you are familiar with on OpenBSD. I prefer the no_x11 flavor because I run bitcoind on an headless server.

    pkg_add bitcoin
    Ambiguous: choose package for bitcoin
    a       0: <None>
            1: bitcoin-0.17.0
            2: bitcoin-0.17.0-no_x11
    Your choice: 2
    bitcoin-0.17.0-no_x11:boost-1.66.0p0: ok
    bitcoin-0.17.0-no_x11:libevent-2.0.22p1: ok
    bitcoin-0.17.0-no_x11:zeromq-4.2.5: ok
    bitcoin-0.17.0-no_x11:db-4.6.21p5v0: ok
    bitcoin-0.17.0-no_x11: ok
    The following new rcscripts were installed: /etc/rc.d/bitcoind
    See rcctl(8) for details.
    New and changed readme(s):
            /usr/local/share/doc/pkg-readmes/bitcoin

  2. Create RPC user and password (How described in the README). For the example below, replace rsadowski with your locale username.

    $ /usr/local/share/bitcoin/rpcauth.py rsadowski
    
    String to be appended to bitcoin.conf:
    rpcauth=rsadowski:bb7fef8d86d250cfebecb36a20eca7$7d0db3fe6c9eab161d70ffa2023838c8b17b32a3522bdc212438022ac0e5398e
    Your password:
    kMSoXR7rMw_90DxVasp0YLFIZb9a-GS5hhFK9aWi4vE=

  3. Add the generated rpcauth line into you /etc/bitcon.conf and check all option in /etc/bitcon.conf.

  4. Create a RPC cookie file in your home directory

    $ cat /home/rsadowski/.bitcoin/bitcoin.conf
    rpcuser=rsadowski
    rpcpassword=kMSoXR7rMw_90DxVasp0YLFIZb9a-GS5hhFK9aWi4vE=

  5. Adjust your pf rule-set.

    pass quick proto tcp from any to (egress) port { 8333 }

  6. Start bitcoind

    $ rcctl start bitcoind
    282229

  7. After the blockchain is synced you can checkout the status with bitcoin-cli

    $ bitcoin-cli getconnectioncount
    23
    $ bitcoin-cli getblockcount
    282229

  8. As last step you can check you node on bitnodes.earn.com.

Keep in mind to reduce the blockchain size by pruning (deleting) old blocks, otherwise you have to download and verify the whole chain and this may take a few days. Checkout the prue value in /etc/bitcoin.conf. I prefer 550MB.

OpenBSD ports wishlist

24 Mar 2018

The following list shows some of my personal wishes for the next release circle from 6.3 to 6.4. There are already existing ports which needs updates.

  • graphics/ffmpeg
    • Update to the 3rd branch would be really great. Maybe FFmpeg 3.4.2 “Cantor”. If you want help to update , please talk with the maintainer and kn@. There is also a old openbsd-wip port.
  • multimedia/mpv
    • Depending on graphics/ffmpeg update. Maybe kn@ can help you
  • math/graphviz
    • Should be reactive easy to update but the tests are weird.
  • devel/cvsweb
    • Be brave
  • devel/protobuf
    • Dependencies everywhere.
  • misc/screen
    • I know no one needs it but an update would be nice.
  • sysutils/e2fsprogs
  • www/drupal7/*
    • Update or nuke it.
  • multimedia/mkvtoolnix
  • x11/vlc
  • x11/wxWidgs
    • A lot of fighting here!
  • x11/qt5/qtwebengine
    • Anyone who wants to help is welcome. openbsd-wip/x11/qt5/qtwebengine.
  • databases/db/v{3,4}
    • Welcome to hell!

If you want help us, please connect the maintainer hack. If you need help, the ports@ mailininglist is happy to help. Of course, you can also write to me personally.