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.

CMake 3.11 (P)reparations

CMake 3.11 is here — it went through four rc’s — which means that preparatory work is underway in KDE FreeBSD land (and has been since -rc1). KDE, as the main early consumer of CMake, is the package maintainer on FreeBSD. That means that it falls to us to signal things that break due to CMake updates, and often to fix them as well. Generally the KDE ports (even the KDE4-era onces) are not a problem; modern-ish CMake was basically develop-tested in KDE. Sometimes updates in C++ bite us — recent FreeBSD releases keep updating Clang, which keeps getting more picky about C++ code (and may default to newer C++ standards than expected). But generally, KDE stuff is ok.

To test a CMake update, I build about 2000 packages on my own desktop workstation. It takes about 20 hours with all the supporting libraries and other bits — rebuilding Qt Webengine, three WebKits, five llvm’s and gcc6 kinda takes its time. Then there’s maybe two dozen packages that don’t build, and it comes down to figuring out whether they don’t build because of a change in CMake, or a change in something else, or simply because they’re already broken. But it means I end up diving into all kinds of codebases, for instance:

  • dspdfviewer had a simple C++ error, because of newer Clang being picky. (already fixed)
  • SuperTux2 has a weird #define type .. which of course breaks some C++ standard libraries where type is used as a structure field name. (already fixed)
  • sqlitebrowser has a really weird copy of QtScintilla which has both an enum and a list of #defines for the same tokens .. which breaks under some inclusion sequences. (not fixed)
  • hatari assumes that SDL_INCLUDE_DIR can only have one directory. (already fixed)
  • kicad has a typical CMake 2.6 or 2.8 setup, where some newer CMake modules from 3.0 have been copied into a cmake/ directory. This eventually breaks when the internals that the 3.0 modules rely on change. Fixing this is as easy as just deleting the old, crufty CMake bits that are shipped with the software — but it needs to be spotted before an update anyway. (already fixed)

There are not software packages I would normally involve myself with, and of these five, three have problems that are not really CMake-related.

KitWare has been great in responding to reported regressions, by the way. So those 2000 packages also serve as a testbed to spot unexpected changes in CMake’s behavior. Sometimes the best thing to do is to fix it in CMake, sometimes update the other software — or sometimes say “this has been unmaintained upstream for six years, let it go.”

There are two issues left on my list which are vexing: drawpile needs an extra include with CMake 3.11 and Wesnoth can’t find OpenMP anymore. There’s another dozen or so packages that are failing and need some work. I need to get those sorted out one way or another before the CMake 3.11.0 update hits the FreeBSD ports tree. For the over-eager, it’s already in the area51 staging tree, in branch cmake-3.11.

Outta the way, KDE4

A comic panel from Mary Worth showing the Central Park Shover

The Central Park shover gives a bad example.

KDE4 has been rudely moved aside on FreeBSD. It still installs (use x11/kde4) and should update without a problem, but this is another step towards adding modern KDE (Plasma 5 and Applications) to the official FreeBSD Ports tree.

This has taken a long time mostly for administrative reasons, getting all the bits lined up so that people sticking with KDE4 (which, right now, would be everyone using KDE from official ports and packages on FreeBSD) don’t end up with a broken desktop. We don’t want that. But now that everything Qt4 and kdelibs4-based has been moved aside by suffixing it with -kde4, we have the unsuffixed names free to indicate the latest-and-greatest from upstream.

KDE4 users will see a lot of packages moving around and being renamed, but no functional changes. Curiously, the KDE4 desktop depends on Qt5 and KDE Frameworks 5 — and it has for quite some time already, because the Oxygen icons are shared with KDE Frameworks, but primarily because FileLight was updated to the modern KDE Applications version some time ago (the KDE4 version had some serious bugs, although I can not remember what they were). Now that the names are cleaned up, we could consider giving KDE4 users the buggy version back.

From here on, we’ve got the following things lined up:

  • Qt 5.10 is being worked on, except for WebEngine (it would slow down an update way too much), because Plasma is going to want Qt 5.10 soon.
  • CMake 3.11 is in the -rc stage, so that is being lined up.
  • The kde5-import branch in KDE-FreeBSD’s copy of the FreeBSD ports tree (e.g. Area51) is being prepped and polished for a few big SVN commits that will add all the new bits.

So we’ve been saying Real Soon Now ™ for years, but things are Realer Sooner Nower ™ now.

(The image is from Mary Worth, november 19th 2013, via Mary Worth and Me; this character is known as the Central Park Shover, and he, um .. shoves people out of the way. The Shover does not manage to steal her purse.)

Event Notes

From a KDE event somewhere in 2017 I found this note in the KDE-booth-crate that I keep at home:

1. thin, sour, 4/10 2. slap in the face, gummi bears, fotlcs 5/10 3. citrussy note 6/10 4. aardberg, smokey x3 8/10 5. nothing happens, competent

I can reconstruct that this particular event had some whiskey, but except for the Ardberg I would have no idea what any of them were. There are no alcoholic notes from FOSDEM, except that we ordered a beer because it was described as “trés désalterante” and we decided after tasting that that was French for “pretty gross”. It certainly quenched our thirst for more.

But if you’re thirsting for more KDE events, there’s the list of KDE Sprints which is where you will find the small, focused, fairly short events for hacking on a well-defined project. Some are open for visitors, and if there’s something you want to hack on with a group of KDE contributors, get organising! (Like, seriously, getting a hacking weekend together is just a few phone calls to reserve a rental house somewhere nice and to arrange for transportation — if you can get the people together, which is usually the biggest problem).

And of course there’s Akademy 2018 in Vienna — I suppose tasting notes will be of terrible coffee and that horrible Mozart liqueur — which is the two-litre stein of KDE interaction each year. The call for presentations is open, so you can pour your wisdom, wit, or vinegar on the audience this summer.

A Day on Krypton

It’s a bird! It’s a plane! No, it’s a shiny stable-yet-bleeding-edge KDE Plasma distro!

Since Calamares has to run all over the place, and is used in derivatives of all of the “Big Five” Linux distributions, I regularly switch distro’s as a development platform. Also because I inevitably blow up the VM while running Calamares, or because an update renders the system useless. At FOSDEM I had the pleasure of chatting with the folks from the SUSE stand about OpenQA and OBS.

(Note, when I originally wrote this I was going to just fiddle around a bit and then return to my Manjaro dev VM; instead it’s turned into a week and Krypton is likely to stay lodged on my VMs and spare machines for the foreseeable future.)

Last week I spent the day with openSUSE Krypton, which is a almost-bleeding-edge KDE Plasma desktop (today’s version has Plasma 5.11.5) on top of openSUSE’s rolling-release, Tumbleweed. Most of my Linux systems (e.g. the kids gaming boxes) run openSUSE of some sort, as did all my work systems at my previous job, but I have not yet used it as a development platform for Calamares. Here’s some usage notes.

Day 1 First day with a distro is usually roughly the same: install it, copy some stuff over, install tools, checkout and build Calamares. With Krypton, it’s no different.

  1. Installation looks a little wonky here and there. The installer could use a careful go-over by a designer to smooth out lines, reduce drawing glitches, etc. It may have been an artifact of installing in an 800×600 VirtualBox window, but it didn’t seem very polished, even if the installer procedure was.
  2. Install basic development tools: zypper in git cmake make gcc gcc-c++. Huh, kdevelop is already installed, that’s a good sign (except it seems like it’s broken, and can’t find the plugin KDevWelcomePage, but see below). Shame Linux systems are otherwise so poorly prepared for being development systems.
  3. Run deploycala.py on the installed system (there’s big fat warnings saying never to do that, but I’m the developer and this is a fresh VM, so nyah nyah). Fall over backwards when it turns out that apt-get exists on this system (and invokes zypper via aptitude) so that the deploy script thinks it’s on Debian and is going to do all of the wrong things. Debug the script. Figure out dependency names (e.g. it’s gcc-c++ on openSUSE, g++ on Debian and just gcc on Arch).
  4. Find there’s no PythonQt packaged; while this is a strictly optional dependency, I would like to find a distro that actually ships something usable for PythonQt (seems Arch does, and KaOS).
  5. Build Calamares.
  6. Profit!

So where does that last, profit, step come in? Well, openSUSE has Secure Boot support, while distro’s using Calamares generally don’t — for the simple reason that Calamares doesn’t support it yet. So I’ll be peeking at what, and how, openSUSE does it and massaging that into Calamares.

Day 2 Ran an update, hoping that KDevelop would be fixed by now. That’s a nice thing about rolling- and bleeding-edge distro’s, stuff gets fixed and/or broken on a daily basis. With Krypton, the underlying rolling base is touted as stable while the KDE bits are bleeding-edge. It wasn’t, but a quick question in the right IRC channel (#opensuse-kde for Krypton) got me sorted and a fix scheduled for the next build. Well done, Kryptonites.

Spent the day hacking on Calamares, mostly fiddling with other bits-and-pieces rather than doing what I intended to do, which was examine secure boot.

Day 3 Still stable. Today’s bleeding-edge update is 112MB, as KDE Plasma is updated to 5.12. I decide to do some ARM development today as well. This is obviously not ideal, since I’m then cross-compiling to aarch64 in a Linux VM running on FreeBSD, but hey. After installing cross-aarch64-gcc7 and adjusting some build instructions that assume Debian naming (e.g. CROSS_COMPILE=aarch64-suse-linux- instead of CROSS_COMPILE=aarch64-linux-gnu-), spent a thoroughly frustrating morning building U-Boot and watching it panic. That’s the downside to using very new hardware which isn’t supported by anything yet except the OEM’s binary-blob package.

Day 4 (after the weekend) A total of 733 package updates today, 810MB to download. They’re not kidding about bleeding-edge and up-to-date. In the meantime I’ve learned that my deploycala script could be much simplified by using the package-manager. Since Calamares is packaged for openSUSE, I could have done zypper mr --enable repo-source ; zypper source-install -d calamares to get the build dependencies for it.

Anyway, after a week I’ve I have not yet broken the system, it’s fast and up-to-date. I’ll be keeping this one around. (And if I was looking for something between Krypton and Leap, I’d probably go for GeckoLinux, which uses Calamares — a bit of dogfooding, as it were).

Plasma 5.12 on FreeBSD

“Of course it runs FreeBSD, too” is something I said a lot in the past week (regarding the Pine64, mostly, but also about my Slimbook). I also said “Of course it runs on FreeBSD, too” a lot. Naturally area51, the unofficial KDE-FreeBSD ports tree, contains the latest in released KDE software. Plasma 5.12 and KDE Frameworks 5.42, with Qt 5.9.4. We just bumped Qt to pick up a patch from KDE’s Eike Hein to fix some weird hover behavior. So we’re all up-to-date on the KDE front, and I’ve been running it as my main desktop since the build finished in poudriere.

On the official ports front, Qt 5.9.4 and KDE Frameworks 5.42 are what we’ve got. There’s a big move coming up of KDE4 ports, which is to make room (in a sense) for KDE Applications and the Plasma Desktop ports. If you’re using KDE4 from ports, then expect package bumps and renames over the weekend (no functional change, just a lot of ports will get a -kde4 name to distinguish them from the currently-maintained, up-to-date un-suffixed ports which will land afterwards.

Who, wha, FOSDEM?

Last week, Roman wrote about going to FOSDEM. Huh, so did I. And then, in a flash and a whirlwind, 8000 Free Software supporters descend on Brussels and leave again. After picking up the pieces and catching up on some sleep, here are my post-event impressions:

Photo of laptops

KDE Slimbook, Konqui Pinebook

The cutest thing I brought back from FOSDEM is probably this Konqui Pinebook. The Pinebook is a low-cost ARM-based laptop, which runs KDE Plasma from an SD card I brought along. But a pure-white, totally blank laptop just cries out for some decoration! Timothée Giet was kind enough to use the permanent markers I’d brought for the booth, to create a one-of-a-kind Konqui Pinebook.

Underneath the Konqui Pinebook is my KDE Slimbook. Someone was handing out Nopetopus stickers; I wish I had gotten more. My Slimbook is starting to look a little beat-up — which is good, from a Hitch-Hikers-Guide-to-the-Galaxy point of view, since it’s been baked under the suns of Kakrafoon^WAlmeria, shivered in the snows of Allosymanius Syneca^W^WBrussels. At the KDE booth we were also could show a second-generation machine: the KDE Slimbook II (in Spanish, their English site doesn’t mention it yet). A faster, brighter version of the Free-Software friendly laptop with Linux and KDE Plasma pre-installed. This generation is a little more angled / chunky than the previous generation. It might get fewer “why do you guys have Macbooks .. oh, hey” comments. So an aluminum but not-quite-clamshell look might be more distinctive.

Photo of booth

Early morning booth setup

Early in the morning (as in, 8am on a Sunday) while setting up the KDE stand, things are calm. We had time to set out the ARM64 machines and FHD screen for the live Plasma demo on low-power hardware. Jos ran his Rust-Qt clock as well; full-screen it was rather laggy, but windowed it ran nicely while we experiemented with Firefox and KDevelop. Lots of people were mystified by the Sun type 5 keyboard, but by golly, that’s where Ctrl belongs (next to the A). Speaking of keyboards, we got some heated comments, even from people looking for tall enter keys.

As always in building K, we were next to the GNOME stand, with whom we did a little trading game: they used our power bricks, we used their scissors. Big thanks to the guy in the purple GNOME jumper who helped me sort out firmware for the wireless dongle attached to the Pine64 board.

Building K ground floor has some venerable Free Software projects, the giant Free Software Foundation Europe stand, Operating Systems (the big three, Debian, Fedora, openSUSE, plus Gentoo, FreeBSD and Illumos) and also has a filesystems corner. I’ve since learned of the existence of LizardFS and MooseFS .. oh my.

Photo of booth

Booth hidden behind people

Once people start showing up, then the KDE booth is well-hidden. Here’s Neófytos smiling through the crowds. We’re not allowed to stick stuff to the windows behind the booth, so it can be hard to tell that there’s a booth there. Something to solve next year.

We had people coming up to the booth with comments like “I love KDE! And activities, those are soooo useful”, as well as “I love KDE! But I don’t understand activities”. Also “yeah, but I use xfce”. There’s room for all kinds of choices — I don’t use activities myself, but for some kinds of workflow they’re really nice.

Speaking of activities, we had the pleasure of showing a painting activity. That’s part of KDE’s application story, and a few artists stopped by to show off Krita in particular.

Photo of artist at work

Using Krita to draw Kiki

Here we see Wolthera hard at work at her tablet. She’s not using either of the Slimbooks, but her own laptop hidden behind the table. The monitor is hooked up to the laptop, so it was a live painting demo. I wish my camera’s autofocus worked better to do this justice.

In the early morning, it was charcoal sketching, which before lunch turned into full-color Konqui and Kiki as Paladins battling the forces of Evil. In this shot, Kiki is being lightly colored in (I’m a kolourpaint guy, I don’t know what this stuff is called — if it’s not flood fill, it’s too complicated). Because Wolthera was hidden behind the monitor, some people thought it was a recorded screencast, not a live demo. In the foreground on the booth table, you can see a few adorable knitted Konqui plushes, which come from la Fabrica de Miritich. I’m happy to report that all of the Konquis were adopted by FOSDEM attendees (including one attendee who was wielding a big rubber T-Rex — I was told it was a friendly Rex and of course Konqui is a dragon and can hold their own).

So, until next year in Brussels (or sooner, at Akademy or elsewhere).

Posted in KDE