Best Service

How often do you meet your laptop vendor in person? Last year, I picked up a KDE Slimbook, and the machine has been great, acting as my development-box-on-the-go for lots of KDE travels. It has a few stickers, and some scratches, and the screen had gotten a bit wobbly by now .. so, at this year’s Akademy I stopped by the Slimbook stand, admired the newer Slimbook II (alas, the old one isn’t written off yet), and mentioned the wobbly screen.

Photo of an envelope from SlimbookHow often does your laptop vendor say “we can fix that” and do it right there and then? So I had a nicely tightened, fast and friendly Slimbook by the end of the next talk. Not only that, but when I got home from Akademy, I found an envelope with some stickers and the right tool to fix it myself if it happens again.

Now that’s developer-friendly service! Thanks, Alejandro and Raúl, and hope to see you again next year.

Going to Deventer^WVienna^WAkademy

Today I’m heading out to Deventer to say “hi” to Valorie and Boud, whom I’m be seeing again next week in Vienna, at Akademy.

Akademy is, for me, first and foremost a way to see everyone again and re-calibrate my social settings for everyone. After all, I communicate with most KDE people only electronically, though text, and it’s sometimes really important to see the faces behind the IRC nicknames. So I’m particularly excited that Michael Pyne will be there, who has been a voice in KDE for as long as I care to remember, but whom I’ve never actually met. And there will be lots of GSoC students there, new people who deserve all the support they can get — and commendations for the work they have done in KDE this year.

Personally I’m not planning anything specific at Akademy. I may chair a panel during the conference parts, and the Distro BoF is something I’ll definitely attend with my FreeBSD hat on. Other than that, it’ll mostly be spur-of-the-moment what I’m doing. Tug on my sleeve if you want coffee and a chat, about portability, installers, OEM stuff, codes of conduct, or Rick Astley.

My First Clang Bug

Part of the role of being a packager is compiling lots (and lots) of packages. That means compiling lots of code from interesting places and in a variety of styles. In my opinion, being a good packager also means providing feedback to upstream when things are bad. That means filing upstream bugs when possible, and upstreaming patches.

One of the “exciting” moments in packaging is when tools change. So each and every major CMake update is an exercise in recompiling 2400 or more packages and adjusting bits and pieces. When a software project was last released in 2013, adjusting it to modern tools can become quite a chore (e.g. Squid Report Generator). CMake is excellent for maintaining backwards compatibility, generally accomodating old software with new policies. The most recent 3.12 release candidate had three issues filed from the FreeBSD side, all from fallout with older software.  I consider the hours put into good bug reports, part of being a good citizen of the Free Software world.

My most interesting bug this week, though, came from one line of code somewhere in Kleopatra:


That one line triggered a really peculiar link error in KDE’s FreeBSD CI system. Yup .. telling the compiler something is unused made it fall over. Commenting out that line got rid of the link error, but introduced a warning about an unused function. Working with KDE-PIM’s Volker Krause, we whittled the problem down to a six-line example program — two lines if you don’t care much for coding style. I’m glad, at that point, that I could throw it over the hedge to the LLVM team with some explanatory text. Watching the process on their side reminds me ever-so-strongly of how things work in KDE (or FreeBSD for that matter): Bugzilla, Phabricator, and git combine to be an effective workflow for developers (perhaps less so for end-users).

Today I got a note saying that the issue had been resolved. So brief a time for a bug. Live fast. Get squashed young.

Those top Konsole Contributors

Whenever I see a post about community growth or participation — like Tomasz Canabrava’s most recent “From Nothing to top 20 contributors of Konsole in Less Than a Month” — I reach for the toolkit written by Kevin Ottens, because that makes it easy to obtain good numbers and graphs for community measurement.

Graph of Konsole's Entire History, all scrunched up and made tinyLooking at the graph (click to enlarge, but it’s still hardly readable — I’d suggest using Kevin’s tooling directly if you want to zoom in or experiment) of Konsole development since the very beginning shows a few striking facts:

  • Konsole has been in continuous development since 1998
  • Except for a gap 2006-2009, Kurt Hindenburg has been active in Konsole since roughly 2004
  • By looking at the density of commits and the length of commit-streaks, you can guess at maintainers and co-maintainers of Konsole, alongside all the occasional committers. There’s maybe five people whose histories suggest that.

Of personal interest to me is that in 2002 I contributed to Konsole for FreeBSD compatibility, and in 2009 for OpenSolaris compatibility, but nothing else in the history of the project. And Konsole spent a year licensed as Artistic, rather than the GPL2-or-later, in 1999.

Graph of Konsole's Recent HistoryRecently, you can definitely see that Tomaz has been really active, and Kurt has slightly more quiet time. But Ahmad and Mariusz are also consistently putting in work, albeit with a lower rate of commits. Judging by the commit messages, those have gone through Phabricator. That means that their commit counts are reduced because arc squashes commits (just like Tomaz, and as pointed out by Eike elsewhere). Keep in mind that commit-counts are poor proxies for contributions — that’s something we’ve been saying for years and years.

Also of interest in the history: there are 1090 commits by people not in the top-twenty; if those were grouped together they would hold second place!

So, thanks Tomaz for being noisy about what you’re doing. I think we need more of the “hey, I can improve the world” kind of noise — like KDE’s GSoC stories as well. And also, thanks Kurt and KDE community for being consistent and productive in small amounts for many years.

(wanted) Poudriere Workflow Support

One of the premiere tools in FreeBSD CI work is poudriere. It’s a collection of shell scripts that leverage FreeBSD jails (chroot on steroids; build-in containers) and ZFS to build ports in a clean environment. You can also “cross” build for different versions of FreeBSD (e.g. on my 11-STABLE box, I can also build 10-STABLE and 12-CURRENT, although forward-compatibility to 12- can be tricky because of kernel changes). It will even truly cross build, but that’s beastly slow due to QEMU (e.g. my Skylake box can just about keep up with my Pine64). And it supports multiple ports trees, so you can do builds for the official ports tree and for local experiments too.

A typical invocation of poudriere looks like this:

poudriere bulk -j 111amd64 -p github-kde -t -i -C math/freemat

That means “build packages in the 111amd64 jail, from the ports tree called github-kde; test each port, afterwards give an interactive shell, remove and rebuild a clean version of math/freemat“. The -C is generally only used when building something multiple times in the same environment as you refine a port. There’s also a -c “rebuild the whole world” (also known as “damn, I may as well go to bed then”) flag.

Poudriere will grind away at dependencies and everything, and in the end spits out a nicely colored status line; it looks like this (here, I was rebuilding octave in order to test Qt5 compatibility, and most of the dependencies were already done).

Screenshot of Poudriere's console outputDuring the build, poudriere can run hooks in response to various events. Those events include build success, or failure (in various flavors). Using the hooks, it’s easy to move the errors to a separate directory, to end up with the build logs of those things that actually failed. Tobias has done that, and we end up with a directory listing like this:

We call a listing like this fallout. Ports that fail during a poudriere run. Since the poudriere run is often a test-run for the upgrade of an important package (e.g. upgrading CMake is tested by building 2500+ packages), handling the fallout afterwards is important: we need to go through each failed port and figure out why it has failed.

In the screenshot above, Coin was a C++-compatibility issue; so were freeMat and ampas. Apviv is hilariously silly bad C++ code (from 2014, so only in today’s context is it bad). .. and so on, and so on. Most recently, I was working from the top of the list, Tobias from the bottom, fixing actual CMake issues and optionally fixing non-CMake issues (e.g. all the dodgy C++ code). And then it struck me, we need better tool support for our very simple workflow.


What we need is a way to associate two pieces of data with each entry in that directory.

  • Who has “claimed” the entry (file) to look at. This is just to prevent double efforts. It should also be possible to “unclaim” an entry.
  • Tags on an entry, explaining what the problem is (e.g. “derp++”, “CMake”, “Upstream gone”).

Screenshot showing possible design for workflow tool.

Kolourpaint don’t fail me now! Three failed ports, with an image indicating who has claimed them and some tags.

In a way, it’s like an issues tracker, only slightly more free-form. There doesn’t have to be any kind of persistence: the workflow applies to one run of poudriere and the next one is basically independent. It might be nice to have user-selectable nicknames, but the owner could be indicated as an IP address, or a hash, or a color .. perhaps the set of possible tags should persist from one incarnation to another.

Does anyone know of an existing tool that does this?

If all else fails, I may sit down with Cutelyst and see what I can do there (or in Pyramid, or whatever; most of the work is probably in the CSS and Javascript, with only a very small core to serve up the page and handle the AJAX requests).

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: | Bleeding edge | 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 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 and can take a date range to limit what is shown, for instance ComDaAn/ -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.