Generating FreeBSD packages with CPack

For software that uses CMake as (meta) buildsystem, and then gets packaged by distro’s — at least on FreeBSD — there’s something weird going on: the meta-buildsystem knows exactly what files are generated and where they get installed, but then knowledge about those files gets re-created outside of the meta-buildsystem in the ports tree, and that re-created information is used to do the actual packaging. To me, it feels like a duplication of effort, since CPack can be used to (re)use the information straight from the meta-buildsystem.

Back in february I blogged about starting on a CPack generator for FreeBSD packages.

Since then, with some comments and hints from Baptiste Daroussin (FreeBSD pkg(8) maintainer) on the FreeBSD side, and a really slick and constructive review process on Kitware’s gitlab, mostly by Brad King, the FreeBSD generator is being upstreamed, and it may be in CMake 3.10, as near as I can tell. There is still some wrestling to be done because there are multiple sources of libpkg.

This isn’t directly intended to break into the FreeBSD ports system — if only because there’s various staging and QA steps in a ports build that CMake just doesn’t know about. But it does produce packages that can be directly installed. That’s a big help for stuff not-yet-in-ports but which might be distributed and tested already. That, in turn, is something I need for some of my other (non-KDE) projects which are inching towards release and could be subsequently packaged but need testing now.

Anyway, big thanks to the constructive reviewers, and y’all can probably look forward to new package generators in CMake 3.10.

One of the new things CMake is picking up — entirely independently — in 3.9 is a new parameter to the project() command. You can check out CMake 3.9-RC2 now. The project() command now has an optional parameter DESCRIPTION, where you can put the human-readable project description. The FreeBSD package generator will use that description if it is given (although the Debian project description takes precedence, and there’s a CPACK_FREEBSD_PACKAGE_DESCRIPTION if you need to set a FreeBSD-specific description which takes precedence over all).

This new parameter is an opportunity for other CPack generators, too: there’s a Deb and RPM generator, and it struck me while writing the FreeBSD package generator that there’s quite a bit of packaging information that is invariant under the actual package format: homepage of the upstream project, for instance; possibly the package description; the software license the upstream software is published under. The different Free Software distro package generators don’t share that information (much — the FreeBSD package generator falls back to Debian and RPM settings if the FreeBSD-specific settings are not given).

So I think there’s a longer-term project that could be undertaken: massaging software meta-data in CMake and sharing that between package generators. That doesn’t just make sense for the Free Software OS generators: Wix and NSIS could (re)use the same information, although I don’t know offhand if there’s license information fields in those packages (the Wix and NSIS stuff I’ve done is for propritary software that comes with a separate EULA, and doesn’t use CMake anyway). And while we’re at it, that makes project metadata more accessible: suppose you could end up with something like this:

  DESCRIPTION "Terminal emulator using KDE Frameworks 5, which integrates fully with the Plasma5 desktop."
  LICENSE spdx:gplv3+

Right now you can find those bits of metadata (usually) in the README and the LICENSE file, possibly in the appinfo file, but I think it would be (even more) useful to have that information available in the (meta) buildsystem. And I think that anything that nudges developers towards better metadata maintainence and use of standard-ish notations is a good thing.

Posted in Bla Bla, FreeBSD | Comments Off on Generating FreeBSD packages with CPack

Migrating Myself

After all that FreeBSD shuffling, I’m going to move myself, too. For the past six years I’ve been commuting by train to Utrecht, where I worked at the Dutch Association of Audiological Centres on patient systems, financing, some data analysis and all the other stuff that happens in a small organization with a broad remit (also “help! the website is down!”). Starting today I’ll be moving less far, and commuting to my office upstairs instead.

As of today, I’m an independent contractor; the domain which I registered ages ago when I last worked with Sebas is now in use.

As of today, I’m working with Blue Systems on the Calamares Installer Framework. Not a KDE project, but an independent, Qt-based, Free Software project used by Linux distro’s like Manjaro and Netrunner (which in turn ship KDE Plasma Desktop images). As a FreeBSD person, it feels a little weird to be writing Linux installers, but I have a secret hobby project for Calamares, too: adding ZFS install support and maybe even getting it to work as a FreeBSD installer. But that’s hobby, outside of the regular maintainence work I’ll be doing.

As of today, I’m working with the ARPA2 project on LDAP tooling and the IdentityHub project. That’s a lot of bit-banging, sometimes in C, which feels a little primitive when coming from a C++ background (I should look at Go sometime).

As of today, I’m still working with the Dutch Association for the Evaluation of Hearing Aids, but only as their occasional website-and-database-futzing dude.

As of today, I’m a full time freelance Free Software contributor. I’ve got a mantra: “if I use it, I’ll aggressively improve it”. Which means there’s plenty of patches coming down the line, for Charm time tracker for one thing.

Posted in Bla Bla, KDE | 5 Comments

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.

Posted in Bla Bla | Comments Off on Moving KDE-FreeBSD ports infrastructure

Moving 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: 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!

Posted in FreeBSD, KDE | Comments Off on Moving to KDE Community Wiki

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.

Posted in FreeBSD, KDE | 1 Comment

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.
Posted in Bla Bla, KDE | Comments Off on My Akademy Plans

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. ]]

Posted in Bla Bla, KDE | Comments Off on I’m going to Akademy!


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.

Posted in FreeBSD, KDE | Comments Off on KDE FreeBSD CI

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, 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 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,
  • The root CA certificate is installed on all the client machines (e.g. in /etc/ssl/certs/)
  • A hostname of, 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 -newreq and fill in the right FQDN for the core machine (e.g. Then sign the certificate with -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 | Comments Off on Quassel with SSL and private CA on FreeBSD

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.

Posted in Bla Bla | 3 Comments