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:

Q_UNUSED(gpgagent_data);

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.

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

Wanted!

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:

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.

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.

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.

The Shoving Continues

More KDE4 parts have been moved around on FreeBSD. Basically what we’re seeing is that all the existing KDE4 ports — that is, pretty much all KDE software except the KDE Frameworks 5, which are the kf5-* ports already available — are getting a -kde4 suffix. I resurrected the old filelight from KDE4 times, which we had updated to the modern KDE Applications version some time ago. That is so that KDE4 users can get the authentic (in the case of filelight-kde4, I think that also means “buggy”) experience. Users of x11/kde4 are encouraged to update and upgrade regularly these days, to catch all of the moves of packages. There are no actual updates in here, no new packages, since there aren’t any more upstream releases.

Now that we’re looking closely at the tree we find that there are some stragglers — I moved skanlite, too, for instance, which we missed in earlier shoving-rounds. Expect skanlite (un-suffixed) to be resurrected in the coming weeks, then, as the KDE Frameworks 5 based version. You can, of course, run that in a KDE4 session — or in any other desktop you like. After all, KDE software runs all over the place, it is not (generally) tied to the Plasma desktop.

So look for KDE4 to be pushed entirely to one side soon-ish, and then for something new to flow in and take its place.