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 | Leave a comment

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 | Leave a comment

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.

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

Reading old stuff

A few months ago, Helio blogged about building KDE 1 (again) on modern systems. So recently while cleaning up some boxes of old books, I found the corresponding books — which shows that there was a time that there was a market for writing books about the Linux desktop.

Particularly the top book, “Using KDE” by Nicholas Wells, is interesting. The first page I opened it up to was a pointer to the KDE Translation teams, and information on how to contribute, how to get in touch with the translation teams, etc. You can still find the translation info online, although the location has changed since 2000.

There’s also tips and tricks on getting your .xinitrc right, and how to safely fall back to twm. I find this amusing, because I still use the same techniques when testing new Plasma 5 packages in a FreeBSD VM. It’s good that the old standalone twm is still there, but it would be much more amusing to fall back to KDE 1.1.2 if Plasma 5 doesn’t start right, I think.

Posted in Bla Bla, KDE | 1 Comment

Packaging with CPack — on FreeBSD

Some days of the week, I work on Free Software projects that aren’t ready to see the light yet; they live in my own git repo’s, or wherever. While I have the intention of publishing eventually, I usually want to get things somewhat working before throwing code out there.

Part of checking if things work is packaging, and installing the stuff on more than one system. Sure, I can build everywhere, or copy around executables, but it struck me that it’d be cool to have packages — you know, installable with the system package manager — for the stuff I make. O yeah, I know flatpak is the new orange, but I’m not that hip. I’ll stick with Debian and FreeBSD packages, thanks.

And so my thoughts turned to CPack, for the reasons (well, because it’s there anyway and I use cmake as meta-buildsystem for almost everything).

So I spent two days messing with CPack internals and exercising libpkg (from pkg(8)) and writing code and then throwing it away (because can replace a half day of me trying to be clever quite easily).

At this point I’m happy to report that I’ve got a working CPack FreeBSD package generator. Like any package, it needs some metadata to be set before it can actually produce an installable package: things like who is the package maintainer, package description, etc.

I’m taking the position that this way of producing packages is auxiliary to the official packaging mechanisms (in FreeBSD, that would be via ports). So for these unofficial packages, the metadata is of less importance; they’re for unofficial, or for testing, purposes. With that in mind I decided to re-use as many of the package-metadata settings from Debian as I could find, and put bogus (e.g. example.com) defaults in the rest. That way, you can get away with very little metadata setting in CMakeLists.txt before CPack’s FreeBSD package generator is happy.

Here’s a minimal CMakeLists.txt which will successfully be packaged using the CPack FreeBSD generator:

set(CPACK_PACKAGE_CONTACT "groot@kde.org")
set(CPACK_PACKAGE_LICENSE "GPLv2")

include(CPack)

add_executable(hw hw.c)
install(TARGETS hw DESTINATION bin)

Notice that there’s nothing FreeBSD-specific in there. For testing purposes, or maybe also for proprietary software, it’s reasonable to have just one contact address, so the packaging falls back to using the generic CPACK_PACKAGE_CONTACT. Of course there’s also CPACK_FREEBSD_MAINTAINER, just like there’s CPACK_DEBIAN_PACKAGE_MAINTAINER, for setting specific maintainers for different packaging if you want to do that. Similarly, there’s a generic license setting, but in the unlikely chance that the license identifier specified generically isn’t recognized by the packaging system, you can override it. The default for project-homepage is example.com, but if CPACK_DEBIAN_PACKAGE_HOMEPAGE is set, that gets used; CPACK_FREEBSD_PACKAGE_WWW can also be used — but that only makes sense if the homepage of the upstream project is different for FreeBSD than for Debian, which seems unlikely. The rest of the variables that influence CPack FreeBSD package generation are described in the CPack script for it. The only thing specific to FreeBSD packaging that you might really need to set manually is CPACK_FREEBSD_PACKAGE_DEPS, which is a list of ports-origins on which the package depends. I may try to generate this automatically, even — libpkg knows about shared-libs dependencies, and could query the package database as well to get whatprovides information — but not right now.

Anyway, I’m going to add this to FreeBSD’s cmake package, so that we can experiment with it downstream. In the medium term I’m going to try to merge it upstream. It surprises me a little that there’s no Flatpak generator: surely that can’t be too difficult to wrangle up (or maybe there’s no point — the intro-to-Flatpak workshop given in Randa was a long time ago). And now, having spent two days messing around on infrastructure for my other projects, I can get back to those.

Posted in Bla Bla, FreeBSD | 2 Comments

Tracking KDE Frameworks and Qt

The KDE-FreeBSD team bumped Qt to 5.7.1 and KDE Frameworks to 5.31.0 in official ports last week, so we’re fairly up-to-date in that department. On FreeBSD, we still fully support Qt4 next to Qt5, so some of the delay in getting this stuff in is due to some shuffling of install locations. In particular, we’ve added qt-chooser in this round of updates, so that qmake is qmake — and no longer qmake-qt4 or some other suffixed binary. We use qt-chooser to switch out one or the other. Checking that this doesn’t break anything else — or at least making sure that everything still compiles — is what took the most time this round of updates.

So we’re edging closer to getting Plasma 5 Desktop; TCBerner intends to import it together with all the KDE Frameworks-based KDE Applications. That makes it a grand shuffling of ports — and that again takes lots of time.

I’m about to embark on an examination of kcheckpass — we still have two of them, even, one kdelibs4-based and one kf5-based — because the Plasma maintainers would like to clean up the code, and have asked distro’s to double-check what actually gets used on each platform. (And kcheckpass is tricksy, like the time in 2003 or so I locked out all the sysadmins at the university by updating the KDE packages, but forgot to setuid it ..)

Anyway, the usual applies: Plasma 5 and KDE Applications are fine to use on FreeBSD, from the area51 repository, and official ports just keep getting closer, bit-by-bit.

Posted in FreeBSD, KDE | Comments Off on Tracking KDE Frameworks and Qt

Fixing old stuff

On FreeBSD, Qt4 is still a thing — for instance, for the KDE4 desktop that is still the latest full-KDE experience you can get from the official packages. And although that software is pretty old, the base system still evolves. FreeBSD 9 has been put to rest, and with it all the GCC-based FreeBSD systems. That frees us from having to deal with GCC and Clang at the same time, and we can generally patch things in just one way (usually towards more-modern C++). But the base system also evolves “out from under” older software. There’s an effort to update the base system compiler (for FreeBSD 12) to Clang 4.0 (sometime soon-ish), and that means that our older C++ code is being exposed to a newer, pickier, compiler.

Seems like I’ve been doing “fix KDE stuff relative to pickier compilers” since, like, forever (on Solaris, and then FreeBSD, and then Solaris again, and OpenSolaris, and then FreeBSD).
Anyway, today’s little fix comes from Qt4 Linguist (devel/qt4-linguist in the ports tree), where we find this code:
if (c->findMessage(m->text(), m->comment()) >= 0)
Here findMessage() returns a MessageItem*, so that’s a nonsensical comparison that should be != 0 instead (or idiomatically, just leave out the comparison but Qt4 sources are somewhat inconsistent in their formulation of null-pointer checks).
So there’s — for me — a brief interlude of messing with old codebases in preparation for new things, while the rest of the KDE-FreeBSD team deals with newer things like the latest KDE Frameworks and Plasma Desktop releases (which, as I’ve said many times, may be had from the area51 repository and work fine, but are waiting on various dependencies in the official ports tree).

Posted in FreeBSD, KDE | 1 Comment

KDE Frameworks and Plasma on FreeBSD

It’s been quiet from the KDE-FreeBSD folks for a bit, but not because it’s actually been quiet. Tobias has been on a roll, and Dima has started doing stuff again, and Gleb is still watching over some ports, and Raphael is hovering over it all with good advice. So here’s some bits and pieces:

Some time ago I mentioned a branded wallpaper for FreeBSD, based off of the Flying Konqui wallpaper — which in turn I had mentioned in February. Anyway, here’s a screenshot of the if-it’s-up-to-me default wallpaper for Plasma 5 on FreeBSD. It’s running in VirtualBox, which is why KInfoCenter reports an interesting resolution (KInfoCenter has also been expanded with a lot better data on FreeBSD hosts, so that it reports sensible memory use, and sensible disk usage).

shot6a

On the official ports front, KDE Frameworks 5 have landed. All except Wayland — which requires a Wayland port to build against, and that is currently in the almost-but-not-quite state from the FreeBSD graphics developers — and Bluez — which is just hopeless with the FreeBSD bluetooth stack. So that layer of the stack is now complete, and we follow KDE Frameworks releases closely.

Next bits, like a Plasma 5 Desktop, are lined up in the plasma5/ branch in area51, and there’s some work being done in FreeBSD Phabricator, but don’t hold your breath.

In the mean time, we’re also pushing things upstream (i.e. into KDE itself) a little more often. Also through Phabricator — KDE Phab this time. So every now and then I end up with tasks or reviews in the one system that belongs in the other, oh well. Generally I really like the workflow with Phab. Certainly now I’ve found the “add reviewer” button. I’ll give the Krusader folks a shout-out for dealing really quickly with issues raised through Phab, and Dima thanks for the original patches.

So all in all: KDE Plasma 5 Desktop is moving along, with two layers of the software stack to go before there’s an official modern-KDE-desktop available on FreeBSD; one layer is already available for modern-Qt-based-applications. KDE4 is receiving some attention as well — I see there’s a KDevelop 4 release I should chase down.

Posted in FreeBSD, KDE | 5 Comments