KDE4 and Qt4 deprecation in FreeBSD

This is a reminder — for those who don’t read all of the FreeBSD mailing lists — that KDE4 is marked deprecated in the official ports tree for FreeBSD, and will be removed at the end of this year (in about 20 days). Then Qt4 will be removed from the official ports tree in mid-march.

Since both pieces of software are end-of-life and unmaintained upstream already for several years, the kde@ team at FreeBSD no longer can maintain them. Recent time-sinks were dealing with OpenSSL 1.1.1, libressl, C++17, .. the code is old, and there’s newer, nicer, better-maintained code available generally by replacing 4 with 5.

Users are encouraged to migrate to Qt5 and KDE Plasma plus KDE Applications. The easiest way to do so is to follow the instructions on the KDE-FreeBSD community wiki.

Elisa in FreeBSD

Elisa (product page, release announcements blog) is a music player designer for excellent integration into the KDE Plasma desktop (but of course it runs everywhere, including some non-Free platforms). I had used it a few times, but had not gotten around to packaging it. So today I threw together a FreeBSD port of Elisa, and you’ll be able to install it from official packages whenever the package cluster gets around to it.

Screenshot of pkg info for ElisaI say “threw together” because it took me only a half hour (most of that was just building it a half-dozen times in different ways). The Elisa code itself is very straightforward and nice. It doesn’t even spit out a single warning with Clang 6 on FreeBSD. That’s an indicator (for me, anyway) of good code. So if you want more music on FreeBSD, it’s there! (And the multimedia controls work from the SDDM lock screen, too)

October?

Gosh, you just blink and the month is over, eh.Let’s do an info-dump.

FreeBSD bits

FreeBSD ports contain Qt 5.11.2 (except for WebEngine), KDE Frameworks 5.51, KDE Plasma 5.12.7 (LTS, but there’s movement lower in the graphics stack that should allow us to update to the current feature release soon-ish), and Applications 18.08. I just updated deskutils/latte-dock to the latest 0.8.2 release. Tobias has been doing everything, updating stuff all over.

There are also things going away from FreeBSD ports. I’ll repeat for the hard-of-understanding: KDE4 ports are being removed on december 31st, 2018. We’ve notified those maintainers that we can — people using BitBounce deserve a special place and haven’t been informed, although we tried. New is that Qt4 ports are deprecated on FreeBSD and scheduled for removal on march 31st, 2019 (three months after KDE4, the main consumer, is removed). This is a bigger deprecation step, actually, since it touches applications maintained outside of kde@. The issue is simple though: Qt4 went EOL in 2015 and maintainence is increasing (e.g. for OpenSSL 1.1.1, changing C++ compilers, etc.). We have started updating default flavors (for things that have both) and informing maintainers.

KDE bits

Photo of Edinburgh from Calton Hill I went to Edinburgh to staff the KDE booth at the Embedded Linux Conference, along with Jon and Paul. I helped make lots of soup on the weekend and it was delicious. And then I spent three days from 8am to 6pm standing and talking to the 2000-or-so attendees of that conference.

It was exhausting, but worth it. Mostly the message is the same: Plasma has had lots of performance work done (for the Pinebook, among other things) and so Plasma runs on a whole range of devices, from this 2GB-ram low-power ARM64 board, to, over there, the 22-core Power 9 workstation. If you thought KDE was bloated (you mean KDE4, and last looked nearly 10 years ago, right? right) then here’s what we’ve done for you: come back and try it again.

KDE was one of only two “community” booths. The other was from Code Your Future, which is a coding school to give refugees new skills. When you spend three whole days at a booth, you hear the “pitches” around you a lot of times, so by the end of the second day I could do a pretty keen presentation for them as well. On the other side was a stand from Togán Labs, who do Yocto-based board bring-up and stuff .. not immediately our cup of tea, but I did end up talking about late-80s Canadian jazz bands with one of their developers. It’s a small-ish world.

At the end of the row was the stand from the OpenPower Foundation, with a demonstration Power9-based workstations. That’s a whole different ballgame from the low-end ARM boards, and seeing 32 hardware threads (at least, I think it was a 2-CPU times 8-core times 2-threads setup) running is pretty keen. The machine arrived with KDE Trinity installed, which .. well, I was wearing my KDE4 launch event T-shirt on tuesday and lets say that KDE3 looks even more dated than a ten-year-old conference shirt.

Rasterman beat me to it, and the machine was quickly running a gorgeous Enlightenment environment all with fancy bubbling backgrounds and other stuff that would drive me mad quite quickly. But pretty. There is Debian installed on it, so a brief chat with the people at the stand allowed us to install Plasma 5 Desktop (apt install whatever..) to check that it works nicely. And it does! The performance work done really does pay off up and down the stack.

Calamares Bits

The next Calamares release, 3.2.3, is delayed. That is at least partly due to events-preparation and general futzing-about. I was intending to get it done this week, but I can tell already that that’s not going to happen: there was an issue reported just today that definitely needs attention. So it looks like after-the-next-event, mid-november, is a good bet for that release.

Everything old is new again

Just because KDE4-era software has been deprecated by the KDE-FreeBSD team in the official ports-repository, doesn’t mean we don’t care for it while we still need to. KDE4 was released on January 11th, 2008 — I still have the T-shirt — which was a very different C++ world than what we now live in. Much of the code pre-dates the availability of C++11 — certainly the availability of compilers with C++11 support. The language has changed a great deal in those ten years since the original release.

The platforms we run KDE code on have, too — FreeBSD 12 is a long way from the FreeBSD 6 or 7 that were current at release (although at the time, I was more into OpenSolaris). In particular, since then the FreeBSD world has switched over to Clang, and FreeBSD current is experimenting with Clang 7. So we’re seeing KDE4-era code being built, and running, on FreeBSD 12 with Clang 7. That’s a platform with a very different idea of what constitutes correct code, than what the code was originally written for. (Not quite as big a difference as Helio’s KDE1 efforts, though)

So, while we’re counting down to removing KDE4 from the FreeBSD ports tree, we’re also going through and fixing it to work with Clang 7, which defaults to a newer C++ standard and which is quite picky about some things. Some time in the distant past, when pointers were integers and NULL was zero, there was some confusion about booleans. So there’s lots of code that does list.contains(element) > 0 .. this must have been a trick before booleans were a supported type in all our compilers. In any case it breaks with Clang 7, since contains() returns a QBool which converts to a nullptr (when false) which isn’t comparable to the integer 0. Suffice to say I’ve spent more time reading KDE4-era code this month, than in the past two years.

However, work is proceeding apace, so if you really really want to, you can still get your old-school kicks on a new platform. Because we care about packaging things right, even when we want to get rid of it.

.. in with the New

It’s been a long time since I wrote anything about the state of current KDE software in FreeBSD. So, without further ado:

  • Qt is now at 5.10.1; work on 5.11 is proceeding. Right now, WebEngine is still at 5.9.5, and that’s remaining so for 5.11 unless we have a sudden influx of free time to work on that monster.
  • KDE Frameworks are at 5.49, which is the august 2018 release; 5.50 hasn’t come out yet but we’re ready for them when they do.
  • KDE Applications are at 18.08.0, which again is the august 2018 release; 18.08.1 was just released today.
  • KDE Plasma is at 5.12.5, so we’re one whole minor release behind (5.13.5 came out on tuesday). This is actually blocked by libinput, which is lagging in FreeBSD.
  • KDevelop version 5.2.3 is one patch level behind

So except for the Qt version, we’re keeping up reasonably well with the modern stuff. And we’ve finally joined most of the Linux distributions in deprecating KDE4 software. For KDE4-using ports that are not “ours”, we’re encouraging other ports maintainers to update them (e.g. to KF5-enabled versions) or follow in deprecating the software.

Out with the Old ..

KDE4 ports will be removed from FreeBSD ports on December 31st, 2018

The KDE-FreeBSD team met at Akademy this year, and while hacking on some other stuff, we also got around to deciding what to do with the KDE4 ports. We have wanted to get rid of them for some time, and there is an increasing pressure of maintainence on them: code written in 2003 doesn’t play well with the C++ of 2018 (in particular clang keeps getting more picky, which is good).

As for KDE4 itself: there haven’t been any upstream KDE4 releases since Applications 17.08.3, and Qt4 upon which it depends is EOL since 2015. The latest KDE Plasma desktop has been available in the official ports tree for over four months (and has been in use by users of Area51 for much much longer).

So, given that there is a viable upgrade path (although, truth be told, you’ll probably have to re-configure KMail and get used to Falkon), we’ve decided to put a four month deprecation period on all the KDE4 ports. They will be removed at the end of this year, which will free up some maintainence time for chasing the steady stream of updates from the KDE community.

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