Moving KDE-FreeBSD ports infrastructure

Quoting from a message Tobias C. Berner sent to the kde-freebsd mailing list:

The development repository that the KDE-FreeBSD team uses to work on the KDE for FreeBSD is moving to github. For a long time we have been using’, an SVN repository kindly hosted by PC-BSD and iX Systems. At this point in time, we believe that moving to github will make the ports a bit more accessible for users and align our ports-development effort better with the way upstream (that is, with official FreeBSD ports) works. We would like to express our thanks to PC-BSD for hosting us all this time, in particular Josh Paetzel for administering the repository. In the coming days we will be updating documentation to reflect the new source of KDE-FreeBSD ports.

The repository can now be found at freebsd/freebsd-ports-kde, where the plasma5 branch is a ports tree with all the updates from the old svn repository.

The main difference between the old svn repository and the new one is, that like gnome@ and xorg@, we now have a complete portstree. So the kdemerge script previously used is obsolete — however, this also mean, that we will lag behind ports-master, which we will try to sync with every weekend.

Thanks also to bapt@ for helping set up this ports tree, and kwm@ for helpful suggestions based on what the GNOME-FreeBSD team has done.

We’re updating the documentation (in the KDE Community Wiki), but mostly things will be simpler, and it may make sense to simply checkout /usr/ports from the KDE-FreeBSD ports tree instead of anything else. We’ll continue to call it “Area51”, even if that string doesn’t occur in its name anymore.

Moving freebsd.kde.org to KDE Community Wiki

The KDE/FreeBSD website has been around for a long time. It has been the repository of much (well, maybe some) wisdom around KDE-on-FreeBSD. But as a repository of knowledge, it has been rather limited in recent years: it lives in KDE’s source-code repositories, and as such has a pretty high barrier to entry. You need a KDE developer account to edit it, for one. And then, editing PHP files in git is not fun, if you’re trying to contribute documentation, howto’s, or screenshots.

So the content has almost entirely migrated to the KDE Community wiki.

The community wiki is described as:

Community.kde.org is the working area for the KDE community. It provides a place for sharing information within the community, including policies, guidelines and coordination.

That’s most of what f.k.o does, so putting it somewhere more accessible, and easier to edit, makes sense.

There’s only two things really left in git: the team page, describing who is on the team, and the in-memoriam page for Alan Eldridge. Neither of those is, in my opinion, up for community-editing-debate.

So now’s the time for FreeBSD-using KDEsta’s, and KDE-using FreeBSDudes, to get the content together!

KDE FreeBSD CI (2)

The KDE Continuous Integration system builds KDE software from scratch, straight from the git repositories, and usually from master (or whatever is considered the development branch). It’s been building for Linux for a long time, and has recently been expanded with FreeBSD servers as well. KDE sysadmin has been kind enough to provide two more VMs (with some more compiling “oomph”) so that we can keep up better, and the CI has just been expanded with all of the Plasma products. That means we’re now building KDE Frameworks, and the Plasma desktop.

Results are still in the sandbox, but will eventually end up in the maiin CI.

Frameworks are all blue (good) or yellow (not-quite-good .. but I can’t really tell what Jenkins’ criteria are for making something yellow). Plasma is now in-progress: what we’re trying to do is merge as much as we can from FreeBSD ports to upstream, so that code only needs maintainence once. Today’s small fix is dealing with PAM, where Linux has pam_syslog() defined in the library, and FreeBSD does not.

My Akademy Plans

The Akademy programme (saturday, sunday) is actually pretty long; the conference days stretch into feels-like-evening to me. Of course, the Dutch are infamous for being “6pm at the dinner table, and eat potatoes” so my notion of evening may not match what works on the Mediterranean coast. Actually, I know it doesn’t since way back when at a Ubuntu Developer Summit in Sevilla it took some internal-clock-resetting to adjust to dinner closer to midnight than 18:00.

Akademy LogoForeseen clock-adjustment difficulties aside, I have a plan for Akademy.

  • Attend a bunch of talks. Telemetry / User Feedback sounds like a must-see for me, and lightning talks, and Input Methods is something I know nothing about and should (hey, my work-work application is Latin-1 only and therefore can’t even represent the names of all of its developers properly, and that in 2017), and the analysing code and fuzzing talk connects way back to the English Breakfast Network days of KDE Code Quality.
  • Hammer (and saw, and sand, and paint) on the KDE CI for FreeBSD; this will involve a fair amount of futzing with the base system, but also gently pushing changes to a whole bunch of repositories. KDE Frameworks 5 are mostly blue / yellow. It’s time to start adding higher layers of the software stack to the whole.
  • BoF it up around CMake, FreeBSD, CI, and LDAP.
  • Have fun at the day trip.

I’m going to Akademy!

The program has been finalized, and registration is now open, for Akademy 2017, in Almería, Spain. I had a tiny amount of input for the programme and schedule, and I’d really like to thank the Real Programme Committee for putting together a neat set of talks covering KDE technology and community for us all, and the local team in advance for all their great work.

I don’t see an official I’m-going banner yet on the under-construction wiki page with tips and tricks for this year’s conference, and I’m not going to subject anyone to my art skills either (I can’t seem to find my older Kolourpaint-based efforts for earlier Akademies, either).

[[ And since there’s always bugs: my IRC nick is [ade], which on import into the conference system got turned into the string Array. PHP never ceases to amaze. ]]

KDE FreeBSD CI

The next-generation of KDE CI is nearly here. Ben Cooksley from the KDE Sysadmin team has announced that it is nearly ready to go. On the FreeBSD side, Ben has done the heavy lifting on the CI side and I’ve done a little futzing around to get the build node in working order by installing system-wide dependencies.

The upshot is that FreeBSD as a target platform now has two CI systems for KDE:

  • the upstream CI, which builds straight from KDE git. On FreeBSD, it currently builds all of the KDE Frameworks 5 repositories,
  • the downstream CI, run by swills@, which builds straight from KDE-FreeBSD’s area51 SVN. That’s the packaging repository, so this checks that the packaging of the last-released version of KDE software is ok.

Together, this two-stage CI should help keep FreeBSD as a much-better supported platform, with fewer patches needed at the packaging stage, since upstream is watched more closely.

In getting the FreeBSD KDE CI working, we found a couple of small build-system issues and a single missing #include <errno.h>, across all of the frameworks that can sensibly be supported on FreeBSD (all but modemmanager and networkmanager). So I consider that a pretty good score; next up is probably tackling all the test failures on FreeBSD, which I expect are probably more build-system and runtime-related, than actual code issues.

Quassel with SSL and private CA on FreeBSD

I spent some time improving the state of encyption on my domains (i.e. finally setting up https), and while I was at it, figured that I would switch from ssh+screen+irssi to Quassel. The FreeBSD packages for Quassel support SSL (TLS) by default, and there’s some brief instructions for setting that up as part of the pkg-message. However, I have a slightly different setup: for my in-house network, I have my own little root CA for my SSL certificates, and I wanted to use that. So for my quasselcore running on quassel.local.net, I wanted to have a certificate issued for that host, and used by quasselcore.

For me, the main benefit of doing this is that all my machines already have the local.net root CA added to their trusted roots, so I don’t get SSL errors on client startup.

In writing this up, I’ve collected a whole bunch of wishlist items for Quassel’s SSL support, which I’ll have to submit to the bug tracker there soon (or write patches). Maybe some of it is documentation-related.

Anyway, let’s assume:

  • A root CA created with, and managed by, CA.pl
  • The root CA certificate is installed on all the client machines (e.g. in /etc/ssl/certs/)
  • A hostname of quassel.local.net, for the machine quasselcore is going to run on.

We’ll install quasselcore, set it up for using SSL, then replace the certificate with one from the CA, and then setup the client too.

On the CA: Create a certificate with CA.pl -newreq and fill in the right FQDN for the core machine (e.g. quasselcore.local.net). Then sign the certificate with CA.pl -sign. Remove the passphrase, if any, from the key file. Quasselcore doesn’t like passphrase-protected private keys. Concatenate the certificate and the key to a file called quasselCert.pem.

On quasselcore: Install (using pkg(8)) quassel-core; the default configuration has SSL enabled. The pkg-message says you can run service quasselcore keygen; if you want to do that, you’ll need to do some manual steps first: create /var/db/quasselcore by hand, and chown that to quasselcore:quasselcore. Otherwise, just start, and then stop the core with service quasselcore start ; service quasselcore stop.Now copy over the quasselCert.pem file from the CA into /var/db/quasselcore/quasselCert.pem. Take care with permissions and ownership.Then start the service again; you should get no warnings about SSL certificates.

On clients: When configuring the connection to the core, click use secure connection (SSL) in the core-account dialog (see the documentation).

If the private root CA is recognised by openssl, then you won’t get an SSL warning on startup.

Posted in KDE

Wrapping things up

At the end of this month, after six-and-a-half years working there, I’ll be leaving the Dutch Association of Audiological Centres (FENAC) where I’ve been working as developer. I’ll be switching to Free Software-related projects, which I’ll write about around june 1st.

Gosh, six years. In that time, I’ve written patches for SQLAlchemy, plugins for TRAC, developed my personal theory on the importance of tertiary employment benefits (i.e. baking cookies every tuesday is good for morale), learned a lot about Python, developed packaging tools and small-scale CI things, learned some C#, and gotten used to a certain office culture.

Even so, it’s time to change gears. I’ll miss my favorite baking colleague Meike and the recipes we developed (in particular walnut-date balls); I probably won’t miss C#. I definitely won’t miss hours in the train every day. I’m particularly looking forward to sitting down for C++ again regularly, and getting a decent cup of espresso at 10am instead of instant.