KDE on FreeBSD – June 2018

The KDE-FreeBSD team (a half-dozen hardy individuals, with varying backgrounds and varying degrees of involvement depending on how employment is doing) has a status message in the #kde-freebsd channel on freenode. Right now it looks like this:

http://FreeBSD.kde.org | Bleeding edge http://FreeBSD.kde.org/area51.php | Released: Qt 5.10.1, KDE SC 4.14.3, KF5 5.46.0, Applications 18.04.1, Plasma-5.12.5, Kdevelop-5.2.1, Digikam-5.9.0

It’s been a while since I wrote about KDE on FreeBSD, what with Calamares and third-party software happening as well. We’re better at keeping the IRC topic up-to-date than a lot of other sources of information (e.g. the FreeBSD quarterly reports, or the f.k.o website, which I’ll just dash off and update after writing this).

In no particular order:

  • Qt 5.10 is here, in a FrankenEngine incarnation: we still use WebEnging from Qt 5.9 because — like I’ve said before — WebEngine is such a gigantic pain in the butt to update with all the necessary patches to get it to compile.
  • Our collection of downstream patches to Qt 5.10 is growing, slowly. None of them are upstreamable (e.g. libressl support) though.
  • KDE Frameworks releases are generally pushed to ports within a week or two of release. Actually, now that there is a bigger stack of KDE software in FreeBSD ports the updates take longer because we have to do exp-runs.
  • Similarly, Applications and Plasma releases are reasonably up-to-date. We dodged a bullet by not jumping on Plasma 5.13 right away, I see. Tobias is the person doing almost all of the drudge-work of these updates, he deserves a pint of something in Vienna this summer.
  • The freebsd.kde.org website has been slightly updated; it was terribly out-of-date.

So we’re mostly-up-to-date, and mostly all packaged up and ready to go. Much of my day is spent in VMs packaged by other people, but it’s good to have a full KDE developer environment outside of them as well. (PS. Gotta hand it to Tomasz for the amazing application for downloading and displaying a flamingo .. niche usecases FTW)

CMake 3.12 Update on FreeBSD

CMake 3.12 has reached rc1. That means we’re testing the update on FreeBSD, and building lots and lots of packages. And, as I’ve written previously, every CMake update triggers a bunch of interesting software findings.

As a motto, I’ve got “use it, aggressively improve it” on my website (you can hire me for odd CMake and C++ jobs, too). So hitting compile issues makes me turn to fixing software outside of KDE.

  • Spring is a 3D RTS engine, with only a minor CMakeLists fix — CMake 3.12 is strict about file(GLOB) and the FOLLOW_SYMLINKS keyword, which is documented only for file(GLOB_RECURSE). Since CMake 3.5, probably much earlier, that keyword has been ignored, and now it’s an error (this is considered a regression).
  • Coin3D is a 3D toolkit, which in the version currently available on FreeBSD, doesn’t even use CMake. It hit a bunch of Clang6 compatibility issues, and after some investigation it turns out they had all been fixed already in later releases; I put in a little time to improve FreeBSD compatibility for the next release.

What I found interesting in those two was once again the variety in CMake styles — “Modern CMake Style” still needs to catch on in many places, and the wider ecosystem. Mantis bug-tracker! Mercurial! I remember being a big Mercurial fan years ago when doing KDE-Solaris and complaining how obtuse git is. (It’s still obtuse, but I’m used to it now).

There’s another four dozen ports that have fallout from this update; amusingly Kitware’s VTK 5 and VTK 6 are among them — although a first glance tells me that’s C++ problems and not CMake problems, actually. (Generally, using NULL in places where you want to write 0; older macro definitions of NULL would re-write to something that could successfully be cast to 0, but clang6 in C++17 mode, the default, uses nullptr which doesn’t cast).

Other People’s Work

Most of my writing on this blog is about FreeBSD, KDE, or Calamares. So it gives a bit of a one-sided view of what I do. There’s lots of pictures of rhubarb crumble, for instance, that never see the bloggy light-of-day. But I can build more than just software! Two months ago an unusually heavy storm blew down part of the fence in my back yard, which wasn’t really good for the privacy of that yard.

Photos of fence

I could pretend this fits into the KDE privacy goals, but really I just want to show off that yes, I can dig post holes, cut lumber, hammer and fasten. While doing so I also found tomatoes, cilantro and dill growing in the yard like weeds, so that’s a bonus.

Software thingies:

Since Daniel Nicoletti keeps writing about Cutelyst, I took a stab at a FreeBSD port, since web-frameworks should be plenty portable. Well, except for the logic failure that UNIX AND NOT APPLE means LINUX. After a half-hour or so of trying to get FreeBSD’s libepoll-shim to be used, I noticed that the shim API is incomplete, so I just punted LINUX out of there. After a minor code update to deal with implicit includes, I’ve got a port file for it that needs some polishing for porter’s-handbook compliance. Expect Cutelyst in the FreeBSD ports tree within a few days.

Atelier and AtCore are active, so here’s a blue-blobs picture of what’s going on (since january). Plenty of commits from the core developer, and some incidental contributions. Lays is less visible in the contribution blobs recently, but that’s probably because of fun Free Software events.

Screenshot of activity-blobs

So that’s what everyone else has done (well, some of everyone else; I’ll leave broader coverage to Nate). Next week, come back for bicycle repairs and Calamares releases.

Watching the Detectives

There are many ways to understand a community.

For instance, Kevin Ottens has been writing about understanding the KDE community by the “green blobs” method, showing who is active when. Lays Rodrigues has written about using Gource to show Plasma growing up. Nate Graham describes the goings-on in the KDE community nearly every week.

Those are, roughly: a metric-, a visual-, and a story-based approach to understanding the community, over different timescales. But understanding of a system doesn’t come from a single dimension, from a single axis of measurement. It comes from mixing up the different views to look the system as a whole.

To that end, I’m going to apply Kevin’s and Lays’s approaches to .. well, not to something Nate has written, but to a recent this-week-in-Elisa post by Matthieu Gallien. The relevant period is april 22nd (the release of Elisa 0.1.1) to may 16th (latest post on Elisa progress).

ComDaAn is the toolbox Kevin has come up with for dealing with activity and centrality. It’s a Python3 application — it almost works with Python2, except that timestamp-formatting in Python2 does not support the %z flag (in spite of the documentation). No strange dependencies, and easy_install or system packages get everything (even on FreeBSD). The green-blobs tool is called activity.py and can take a date range to limit what is shown, for instance ComDaAn/activity.py -f 2018-04-21 -u 2018-05-16 ~/src/kde/elisa/ , which gives us this (image links to an actual HTML page with all the fanciness).

Image of contributions to Elisa

Elisa Contributors, 2018-04-22 — 2018-05-16

Gource is what Lays used to show off Plasma development. I used the same video (regenerated locally) as a blinkenlights show at the KDE booth at FOSS-North. Gource also takes a date range, for instance , which gives us this (image links to the video).

Elisa Gource Screenshot

A moment in Elisa time

The time period here is short; it’s unwise to draw any conclusions from any of these visualisations. They do support the story that Matthieu tells, and the natural order of things is that the main developer does the most commits, with features and fixes coming (ir)regularly from others. The movie shows that the structure of Elisa (or the source code, at least) remains stable over this period. Together, the visualisations along different axes enliven the story of Elisa — and running those tools over a longer period of months can help understand how the community around that application grows and changes.

[[ As an aside, there’s a really neat use of Gource out there: instead of visualising source-code changes, use it to watch other kinds of events, like those that DTrace can provide from a running system. FreeBSD users can enjoy Devin Teske’s dwatch-gource, which uses dwatch to produce logs suitable for gource, and then make a movie of what their system is doing. Maybe not great for parties, but excellent for figuring out why the desktop is suddenly slow while building Qt, LLVM and GCC in parallel (all three with -j8). ]]

Calamares and Google Summer of Code

This year Calamares is participating in Google’s Summer of Code. While Calamares doesn’t live under the KDE umbrella — for political reasons, basically, to emplasize that it is a desktop-agnostic system installer — it has a great deal of KDE DNA inside. The maintainers (that’s Teo, then myself) have been KDE people, some of the technology is definitely KDE (KPMCore in particular). So we’re happy to be participating under the KDE umbrella in a mixed KPMCore / Calamares role.

Andrius (KPMCore) and myself (Calamares) will be working with our student Caio Jordão de Lima Carvalho on a list of advanced partitioning scheme improvements. With this, we’ll make KPMCore a more powerful library for dealing with complicated partitioning schemes, and Calamares a more powerful installer. The “advanced” schemes here are all based around LVM (Linux Volume Manager) which is something I’ve been dreading having to deal with — so I’m really happy Caio will.

He’s pushed stuff to KPMCore before, and his first pull request to Calamares arrived this week, so I feel we’re off to a good start. Look for more on the Calamares site.

Welcome x11/kde5 to the FreeBSD Ports Tree

Desktop wallpaper with Konqui and FreeBSD LogoThere is no KDE5. There are KDE Frameworks 5 (releasing monthly, now reaching version 5.45) and KDE Plasma Desktop 5 (releasing quarterly, I think, now 5.12) and KDE Applications (releasing semi-anually, called 18.04).

For the FreeBSD ports tree, there is a x11/kde5. It is a metaport, which means it collects other ports together; in this case, x11/kf5-frameworks (metaport for all the frameworks), x11/plasma5-plasma-desktop and a fistful of KDE Applications metaports (e.g. the metaport for KDE games, and the metaport for KDE graphics applications, and the metaport for what-we-consider-essential KDE applications like konsole, konqueror, dolphin, and okular). So, from a bare FreeBSD installation, installing x11/xorg, x11/sddm, and x11/kde5 should get you close to a working modern KDE Desktop experience. Throw in www/falkon and devel/kdevelop for a developer workstation, or graphics/krita for an artists workstation, and you’ve got a daily driver.

I’m not really happy with naming the port this way, but it is just an identifier that needs to distinguish it from other bits and pieces on the system. And our naming was historically such a mess that it’s taken a long time to sort out; there are still some odd corners like x11/kde-baseapps.

KDE4-style exit buttonWhat this means is that KDE4 users and modern KDE Desktop users can now be separated out effectively with the KDE packages on FreeBSD. Since there’s no more upstream releases of KDE4-era code and Qt4 was end-of-lifed long ago, I can see us going the same route as Ubuntu (and Debian, and basically everyone else) soon-ish (in FreeBSD time) and handing the whole unmaintained stack to people with an active interest in maintaining it themselves, or dropping it.

Photo of FOSDEM booth with Tobias

The elusive Tobias at FOSDEM

Special and exceptional thanks needs to go to Tobias Berner for pushing the last bits to the official ports tree and for catherding this process over the course of several years (of course, you could run a modern KDE Desktop from Area51 since 2016 or so, but not from the official ports tree).

So, what’s next? Well, in no particular order:

  • Qt 5.10 in the official tree. We’ve pushed it quickly to the KDE-FreeBSD CI systems so that git master can continue to build, but it needs to go to the official ports tree too. Main issue is dealing with WebEngine (no surprise there), so we’re looking at Qt 5.10 and the unmodified WebEngine from 5.9 — a FrankenEngine, which, for all its frightening and unnatural connotations, is probably the right name for it anyway.
  • Improving overall system integration and dealing with papercuts.
  • Chasing our CMake and KDE bug lists.
  • Bringing Wayland to fruition on FreeBSD. This in cooperation with the Mesa and GNOME teams.
  • Fixing ports and things all over the tree as we bump into things (I’ve spent some time with FreeRDP recently, and should say thanks to Kyle Evans for taking my throw-them-at-the-wall patches and making them stick).

That’ll keep us busy through 2018.

KDE at FOSS-North

Over the weekend, while some KDE people were in Toulouse improving Akonadi, and other KDE people were in Berlin improving Plasma, I was in Goteborg at FOSS-North showing off some KDE things.

Anyone who saw our FOSDEM booth knows the setup. We still had the same blue table (thanks, Sune) and selection of low-power ARM blinkenlights, the Pine64 and a Pinebook. I still think that “hey, Plasma runs fine on an overpowered x86 laptop” is not particularly interesting, but that “the past six months have seen serious work on reducing Plasma’s resource usage aimed specifically at this kind of device” is. Different from FOSDEM is that I could now run one of the just-released Netrunner images for the Pinebook.

There are pictures circulating of a staged fist-fight between me and Bastian, who ran the GNOME booth. Except for those 30 seconds, we were good neighbours and I’d like to thank Bastian for keeping an eye on things when the KDE booth wasn’t otherwise occupied.

Bigger thanks to Helio, who came from not-Bavaria to help at the stand as well and give a software archaeology talk. And biggest thanks to Johan, for setting up and running the whole conference.

I gave a talk on governance — call it “Open Source Project Governance 101, with a brief mention of how KDE does it specifically”. A half hour is long enough for an overview, not long enough to really go over all the considerations you might have along each of the different axes of decision. I’m more than happy to be talking with people about specific issues in governance. I didn’t see many talks themselves: just one on deep-dive C++ and OpenGL stuff (I didn’t understand all of what Patricia does) and reproducible-builds tools like diffoscope (Chris’s talk gave a nice overview).

CMake 3.11 in FreeBSD

The latest release of CMake has landed in FreeBSD. Prior to release we had good contact with KitWare via the bug tracker so there were few surprises left in the actual release. There were still a few last-minute fixes left, in KDE applications no less. Here is a brief summary of changes we made:

  • FindQt doesn’t match the way FreeBSD ports are built and installed, so we defer to QMake rather than looking for directories,
  • FindOpenMP gets a tweak because it won’t find the system pthreads library when gcc (for Fortran) is used,
  • FindBLAS gets a larger tweak because BLAS may need to link to libgcc_s, and which gcc_s that is needs to be figured out via ldd(1).

Some older patches have gone away because upstream has picked them up. Tweaks downstream, in package-building-terms, of cmake that were necessary:

  • check_include_files respects the required libraries, which can be a surprise when the required libraries have been found but not fully plugged into the build (e.g. missing -L flags).
  • the order of includes in automoc sources has changed, which reveals places where a C++ header file doesn’t actually include all of the headers it needs to fully define the types it uses; previously the include order might implicitly include them and the issue is papered over.

CPack now fully supports producing FreeBSD packages from a build / install tree by default, so for non-ports software which uses CMake, cpack -G FREEBSD does the right thing. Previously, this was a non-default tweak to CPack as built in FreeBSD ports.
Edit: as of CMake 3.11.0_1, CPack no longer supports producing FreeBSD packages. There were some unexplored corners of the build process that cause build failures when the FreeBSD pkg(8) support is enabled. So it’s off again until we shine some more light into those corners.

.. and a PS., CMake 3.11.1 has just been released, which reverts the change to check_include_files which I’d been working around.

Modern Akonadi and KMail on FreeBSD

For, quite literally a year or more, KMail and Akonadi on FreeBSD have been only marginally useful, at best. KDE4 era KMail was pretty darn good, but everything after that has had a number of FreeBSD users tearing out their hair. Sure, you can go to Trojitá, which has its own special problems and is generally “meh”, or bail out entirely to webmail, but .. KMail is a really great mail client when it works. Which, on Linux desktops, is nearly always, and on FreeBSD, iswas nearly never.

I looked at it with Dan and Volker last summer, briefly, and we got not much further than “hmm”. There’s a message about “The world is going to end!” which hardly makes sense, it means that a message has been truncated or corrupted while traversing a UNIX domain socket.

Now Alexandre Martins — praise be! — has wandered in with a likely solution. KDE Bug 381850 contains a suggestion, which deserves to be publicised (and tested):

sysctl net.local.stream.recvspace=65536
sysctl net.local.stream.sendspace=65536

The default FreeBSD UNIX local socket buffer space is 8kiB. Bumping the size up to 64kiB — which matches the size that Linux has by default — suddenly makes KMail and Akonadi shine again. No other changes, no recompiling, just .. bump the sysctls (perhaps also in /etc/sysctl.conf) and KMail from Area51 hums along all day without ending the world.

Since changing this value may have other effects, and Akonadi shouldn’t be dependent on a specific buffer size anyway, I’m looking into the Akonadi code (encouraged by Dan) to either automatically size the socket buffers, or to figure out where in the underlying code the assumption about buffer size lives. So for now, sysctl can make KMail users on FreeBSD happy, and later we hope to have things fully automatic (and if that doesn’t pan out, well, pkg-message exists).

PS. Modern KDE PIM applications — Akonadi, KMail — which live in the deskutils/ category of the official FreeBSD ports were added to the official tree April 10th, so you can get your fix now from the official tree.

Modern KDE Applications on FreeBSD

After the shoving is done — and it is, for the most part — it is time to fill up the void left behind by the KDE4 ports that have been shoved aside. In other words, all over the place <foo> has been shoved aside to <foo>-kde4, and now it’s time to reintroduce <foo>, but in the modern KDE Applications form. For instance, there is now a science/kalzium-kde4 (the old stuff) and a science/kalzium (the new stuff). It’s not 100% complete, but most of the applications are there.

Tobias has been the driving force behind this, with ports commits like r466877 which introduced the modern KDE applications in science/. So a huge shout-out to his work in bringing things almost-up-to-date.

Note that we now have KDE Frameworks (5.44 .. there’s an exp-run planned for this week’s 5.45 release) and KDE Applications (17.12.3) but not a Plasma 5 Desktop; so you will be running KDE Applications on the older desktop of your choice if you’re using FreeBSD ports.