Plasma 5 Desktop on FreeBSD Branding

The FreeBSD packages of KDE software — the KDE 4 desktop, and soon KDE Frameworks 5 and Plasma 5 Desktop and KDE Applications — have traditionally been shipped pretty much as delivered from the upstream source. We compile, we package, and there is very little customization we do as a “distro”. The KDE 4 packages came with a default wallpaper that was a smidgen different from the one shipped with several Linux distro’s. I think Ivan Cukic did that artwork originally. For Plasma 5 Desktop, we also wanted to do a tiny bit of branding — just the default wallpaper for new users, mind.

Thanks to the tremendously helpful Plasma crew who answered my questions about setting a default wallpaper by producing the necessary files on the spot. After a tiny amount of massaging, I’ve now got a package that does the FreeBSD branding of the Plasma 5 Desktop for us. Of course we retain the upstream settings and wallpapers too.

Also great thanks to Timothee Giet, for producing the image (based on his Flying Konqui) that we’re now going to use as the default wallpaper — Konqui flying on BSD, that’s just what we want, after all.

A bit on Tooling

Last weekend, I finished the construction part of my garden shed. The last bit mostly playing with the circular saw, taking rough boards and making them square, then angling them so that they would fit under the roof. It took a couple of hours, but I ended up filling the 3m-by-65cm gable with vertical planking, quite neatly. At the beginning of this year, I wouldn’t pick up a circular saw — power tools, scary. So I planned building a shed to force myself to learn something about carpentry. The next-door neighbour is a handyman, so we worked together and basically he taught me how to use the tools and get things done. (The Czech animation series “Pat a Mat” is popular in the Netherlands as “Buurman en Buurman“, and we style ourselves thus).

Anyway, I think my point is that learning to use the tools is half the battle.

So on the weekend I also worked on updating Qt 5.6.1 to Qt 5.6.2 on FreeBSD, which involves using new and scary tools as well. Power tools, they can be really useful, or they can take off a finger if you’re not careful. In this case it was Phabricator, which is also used in KDE — but not everywhere in KDE. For FreeBSD, the tool is used to review updates to ports (the packaging instructions), so I did an update of Qt from 5.6.1 to 5.6.2 and we handled the review through FreeBSD’s Phab. The ports infrastructure is stored in SVN, so the review is relatively straightforward: update the ports-tree checkout, apply your changes, use arc to create or update a review request. I was amazed by how painless it was — somehow I’d been frightened. Using the tool once, properly, makes a big difference in self-confidence.

At this point, the tooling no longer stands in my way, and we can expect to have KDE-FreeBSD updates rolling out a little faster (until we’re caught up, finally). Current status is: Qt 5.6.2 is in exp-run (last stage before committing), KDE 4 infrastructure has landed, KF5 is being prepared for review by Tobias, and the plasma5/ branch of area51 contains the latest bits of everything released by the KDE community that we can port.

Qt 5.6.2 on FreeBSD

Qt 5.6.2 was released today, the second patch release to the LTS (long-term support) Qt 5.6 release. Tobias had done prep-work by writing the FreeBSD ports for the last snapshot; I accidentally nuked that this morning, but now this afternoon I’ve restored Qt 5.6.2 final to the area51 unofficial ports tree. Since this is a patch-release, I’ll PR it shortly and then we can expect it to end up in official FreeBSD ports shortly.

One little blurb from the release-blog:

Qt 5.6.2 is well suited for users that can not upgrade to a later version of Qt, for example due to dependency to C++98 compiler.

In our (FreeBSD) case, what’s blocking is Qt 5.7 and WebEngine, which remains a big pain in the butt to get working at all (because its upstream doesn’t care about all the platforms that Qt cares about, or that KDE cares about, or that I care about — in decreasing size of audience, I think). How big a pain in the butt? Well, I’ve heard of efforts to update WebKit (not only in BSD-land, mind) and even efforts to port current KDE PIM back to an updated WebKit, thus dropping the WebEngine dependency introduced there. I imagine — or hope — that the pain in the butt of doing that is smaller than the pain of massaging WebEngine into shape. Basic economics — reduction of pain in the butt. I have no idea what’s happening there long-term. Suffice to say that for now, Qt 5.6 is where it’s at on FreeBSD.

KDE Frameworks 5 is lined up for use; there’s a big change in KDE ports infrastructure on FreeBSD going down, which will make it easier for us to keep KDE4 and KDE Frameworks, Plasma and Applications running side-by-side for now, and will help ease the porting maintainence burden. That big change has reached the last stage: an exp-run, which rebuilds everything on every version on every architecture. Once the fallout from that is cleared, KDE Frameworks 5.27 is ready for landing.

KDE Frameworks 5.27.0 on FreeBSD

The latest KDE Frameworks release — this month is 5.27 — is available in the unofficial KDE-FreeBSD ports repository, area51. Users of the plasma5/ branch in that repository can update as usual. or from the bleeding-edge packages provided by the KDE-FreeBSD team.

The state of those ports with respect to the official ports tree is unchanged: we’re working on getting the infrastructure updates needed to subsequently push KDE Frameworks into official ports (just Frameworks, initially, not Plasma or newer applications) and that’s a long-ish process.

KDE Plasma 5.8 LTS on FreeBSD

There’s an LTS (long-term support) release of KDE Plasma 5 available now. The dot story is quite extensive. The FreeBSD ports for this LTS release can be found in area51 (as usual) in the plasma5 branch (as is the norm as long as we’re not done settling other KDE foundations in official ports).

There are also packages available, although those are obviously not sourced from the official FreeBSD package servers but from the KDE-FreeBSD team’s servers. Ask in #kde-freebsd on freenode if you need instructions for adding that repository server.

While the upstream release is an LTS one, we (as in the KDE-FreeBSD team) have not thought about how this translates to FreeBSD ports. The official ports tree doesn’t really support LTS-type releases without forking the tree. What might happen is that we branch off in area51 and keep that around — then users specifically interested in the LTS aspect can merge that with their ports tree. Then again, it might not: we don’t have a lot of energy left over to spend on even more branches.

So where are we regarding the rest of the KDE ports (modernizing KDE4, adding KDE Frameworks 5, etc.)? Well, there’s a Phab review going on to adjust the infrastructure to make the KDE ports more flexible; that is a prerequisite for pushing in the rest. However, once it’s in then we have area51 trunk lined up to add KDE Frameworks 5 ports. Since those are new ports, it’s a lot more straightforward than adjusting infrastructure that a lot of ports depend on.

Answer: slowly getting there.

Akademy: the technical bits

Agh, when I wrote about the social bits of Akademy in Berlin, I intended to follow it up closely with a post on the more technical things I did at the conference. Sadly, that escaped my grasp and much has slipped my mind, too. There was GPG keysigning, and I finally wrestled gpg into shape on FreeBSD at home to be able to use my new keys (when it works, it’s fine, when it doesn’t, the error messages are maddeningly meaningless).

There was a great KMail / KDEPIM BoF, which combined a run-through of the options in KMail — led by Dan — to tally which ones made sense in the modern world. It led to two lists, one of “does this work?” and another of “get rid of it.” There was also a regular stream of “can it do that? neat!” KMail is huge, and it has a lot of really neat features that don’t get a lot of promotion. And during the session David piped up with “yup, killed that one” (which was the intended-as-a-demonstration-plugin never-meant-for-release ROT-13 encryption plugin).

There was more technical stuff, packaging, trying to work on CI, but it’s a little hazy by now. I can still recommend the wrap-up page, which also has the videos of each afternoon’s summary session.

Posted in KDE