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

Virtual Machines with ZFS Volumes

My main workstation runs FreeBSD; my work on Calamares is all Linux, so I use a lot of virtual machines and do a lot of disk-swapping. My tool of choice is VirtualBox, which is really darn useful for running complete desktop environments.

But I’ve just added a new¬†item to my toolbox. It’s called vzvol.

A very recent addition to the official ports collection, vzvol is a script that helps with, and automates, creating ZFS volumes. I saw the commit adding vzvol to the ports tree, and immediately thought “hey, that’s really nifty.” And it ticks an awful lot of boxes for me in my regular workflow.

A ZFS volume is just a reservation in a zpool (which is a storage pool, composed of one or more disks; zpools have their own administration layer) which is treated as a block device by the host OS. It’s like an image file — except it’s not a file, and the blocks in the reserved space are addressable just like any other block device. For a volume called¬†kde-neon-dev in the pool zdata, the corresponding block device is /dev/zvol/zdata/kde-neon, and you can treat it like any other disk. For instance, you can dd(1) zeroes into it, and then run fdisk(8), or gpart(8), and experiment with disk utilities.

That’s quite different from disk images as files, where you need to loopback-mount or memory-disk-wrangle them; worse still are disk images created by VirtualBox, which are hard to manipulate from the host side with regular tools.

VirtualBox can use “write-through” devices, though — it’s a bit fiddly, but you can create a VMDK that points to a block device. Any block device, including ZFS volumes! All of a sudden, the disk blocks used by my VM are also easily manipulable from the host OS. For my day-to-day disk-wrangling, this makes a huge difference.

vzvol makes manipulating and maintaining these ZFS volumes a snap, and it’s saved me tons of time in just the past two weeks. Hey, let’s try the latest Manjaro:

vzvol -s 20G -t virtualbox -p zdata -v manjaro-test

after the test, vzvol --delete cleans it up. (And vzvol runs on Linux, too, if you have ZFS there).

Events: Akademy 2018

Not nearly as close as FOSDEM, but still coming up on the KDE Community calendar: Akademy 2018. It’s in Vienna. I vaguely remember visiting Vienna once, long ago — possibly an FSFE function. So it’s high time to head out that way again to visit the local KDE team and to see what 2017-2018 has brought (and will bring) the KDE community.

Of course, to hear from the community, the community needs to speak! The call for participation is open, so send something in to the programme committee. Check out the list of potential topics — a lot of stuff can fit.

Personally, I’d like to give a talk on Calamares — which isn’t a KDE project, but which is used by various distro’s that ship KDE versions (e.g. Manjaro, Netrunner, KDE Neon dev, KaOS, Kannolo). Not really sure which parts of Calamares to present, but something will fit. And as a packager, I’d really like to see a panel-ish thing with OpenSUSE, KDE Neon, FreeBSD and other distro’s on stage talking about the KDE packaging process in the traditional sense. After that, Flatpak can take over ūüôā

But for everyone in the KDE community: what have you done, what are you doing, and where are you going? Share it with us and with the world at Akademy 2018.

Events: FOSDEM 2018

The annual FOSDEM event is really close now. It’s a kind of geek valhalla, with carousing and quaffing and a whole lot of technology things. There’s a KDE stand where you can see some of the latest KDE bits and pieces, including Plasma 5 running on low-power hardware. 2GB ought to be enough for everyone, right? We might¬†have a phone available running the existing Plasma Mobile code, since hardware continues to be tricky to come by (Nexus5X is fine).

Come by and chat about Plasma, Kirigami, artwork, Krita, databases, graphics on low-power ARM devices, KDE on FreeBSD, Konversation, Discover¬†(Nate Graham gives really good overviews of what’s happening), translation¬†and more. See you soon!

Debugging Tools

Today I had to repair my most important debugging tool. Here’s the result:

That’s three strands (red, white, black) from a USB-to-serial converter, soldered on to a 3-pole screw-tightened connector. Clamped into that are the serial lines (red, green and blue) which were originally crimped straight to the lines. After a few months of use, the crimping failed and the red cable (RX) broke off.

So I had to fix it, and in the process decided to make it more sturdy, more ugly, but also easier to use.

The three grey wires clamped into the connector are part of a 10-pin flat cable which I scavenged out of a 9-pin serial connector I had left in the box-of-old-parts.

The flatcable, and especially the 10-pin connector at the end, is nice and sturdy for connecting to the headers on single-board-computers, like here:

That’s why I need a serial cable for debugging. The frontmost board is a Pine64+. It runs FreeBSD and Linux; in Linux it will drive a full Plasma 5 desktop at FHD and acceptable responsiveness; FreeBSD is limited to serial console and ssh access. I use this board to test aarch64 support in FreeBSD and to test our KDE-FreeBSD packages on yet-more-unusual platforms. This turns up occasional issues in KDE code.

(The other two boards are a switch I had left over, and there’s an Odroid C2 at the back; together they form my little ARM rack, along with two planks they’re screwed on to and a power supply. Did you know the Palm m500 used the same size barrel jack for power as the Odroid C2? Yet another reason to keep old parts lying around.)

A Fistful of Ports Updates

Here’s a list of KDE-related stuff (mostly official FreeBSD ports) the KDE-FreeBSD team handled recently. You could call it “a week in the life of some packagers”, packagers who are also otherwise busy with $work-work.

  • Updated otter-browser (a Qt webengine-based browser) to latest version 0.9.94
  • Added a GTK QPA
  • Updated latte-dock to latest released version 0.7.3
  • Clang6 fixes to older KDE and Qt software (out favorite #define nullptr NULL)
  • Reworked packaging of Qt 5.9 to fix a broken (generated) qconfig.h

And in area51, the unofficial ports tree where we do preparatory work (use the branch kde5-import, which supercedes the plasma5 branch; this one contains the current plan for adding Plasma5 to the ports tree and updating all the KDE Applications), we’ve also got:

  • Updated digikam to 5.8
  • Updated KDE Frameworks to 5.42 (this is waiting on an exp-run to move to official ports)
  • Improved powerdevil backend, thanks to Henry Hu
  • Added plasma5-browser-integration
  • Support Qt4 on aarch64, thanks to Fedora

As usual: you can run a full modern KDE desktop system with Plasma 5 and KDE Applications, from the area51 repository, from the kde5-import branch; official ports have the latest Qt and KDE Frameworks, but not the desktop.

Qt 5.9 on FreeBSD

Tobias and Raphael have spent the past month or so hammering on the Qt 5.9 branch, which has (finally!) landed in the official FreeBSD ports tree. This brings FreeBSD back up-to-date with current Qt releases and, more importantly, up-to-date with the Qt release KDE software is increasingly expecting. With Qt 5.9, the Elisa music player works, for instance (where it has run-time errors with Qt 5.7, even if it compiles). The KDE-FreeBSD CI system has had Qt 5.9 for some time already, but that was hand-compiled and jimmied into the system, rather than being a “proper” ports build.

The new Qt version uses a new build system, which is one of the things that really slowed us down from a packaging perspective. Some modules have been reshuffled in the process. Some applications depending on Qt internal-private headers have been fixed along the way. The Telegram desktop client continues to be a pain in the butt that way.

Following on from Qt 5.9 there has been some work in getting ready for Clang 6 support; in general the KDE and Qt stack is clean and modern C++, so it’s more infrastructural tweaks than fixing code. Outside of our silo, I still see lots of wonky C++ code being fixed and plenty of confusion between pointers and integers and strings and chars and .. ugh. Speraking of ugh, I’m still planning to clean up Qt4 on ARM aarch64 for FreeBSD; this boils down to stealing suitable qatomic implementations from Arch Linux.

For regular users of Qt applications on FreeBSD, there should be few to no changes required outside the regular upgrade cycle. For KDE Plasma users, note that development of the ports has changed branches; as we get closer to actually landing modern KDE bits, things have been renamed and reshuffled and mulled over so often that the old plasma5 branch wasn’t really right anymore. The kde5-import branch is where it’s at nowadays, and the instructions are the same: the x11/kde5 metaport will give you all the KDE Frameworks 5, KDE Plasma Desktop and modern KDE Applications you need.

Auditing Licenses in KDE Frameworks FreeBSD Packaging

FreeBSD is getting more serious about license metadata in the packages¬†produced by the project — that is, the binary distribution of software¬†produced from licensed source code. A lot of software in FreeBSD “proper”¬†is (naturally) BSD-licensed, and a lot of Free Software packaged by¬†FreeBSD is (also naturally) GPL licensed. But the different licenses¬†carry different obligations, so it’s good to keep track of the exact¬†licensing applied to each bit of software.

To this end, there’s the LICENSE= line in each port’s Makefile. Its¬†meaning is “this software has such-and-such a license”. For conciseness,¬†SPDX identifiers are used, so that you can write


and we know what you mean. Because licenses can carry textual obligations (e.g. the GPL expects you to receive a copy, and the BSD licenses generally require you to include the copyright notice with distributions), there’s
an additional setting to include the actual text, called LICENSE_FILES:


There’s a third source of license information, and that is the headers of the sources themselves. Usually you put a copyright-and-license header at the top of each file; some licenses such as the MPL even require some administration in there. The reuse.software site (by the FSFE) provides good guidance and best-practices information for providing licensing metadata in software packages.

Anyway, for KDE Frameworks 5 I was going through the ports Makefiles and adding LICENSE information. The KDE Licensing Policy tells me that frameworks should be licensed LGPL21+, with a few variants allowed; an interesting one is (at your option) “LGPL21 or LGPL3 or any later version approved by KDE e.V.” Right now, in 2017, this choice is the same as LGPL21+ because no later versions exist, but it is not always-in-the-future-same, so I hesitate to write


for KDE Frameworks until I’ve checked the files. The license text is usually included, but it’s not quite consistently named, so I need to look into the tarballs anyway. And as a double-check, I read a couple of source headers to see if the license named in the code, matches the license text elsewhere (e.g. some files say LGPL 2.1 only).

It’s a bit of a slow process — one which upstream (that is, the source code) could support a little better with consistent naming. It’s also a process that needs to be monitored continually, to ensure that the whole body of software remains properly and consistently licensed — hopefully following best practices, too.

Anyway, as of today only ten of the KDE Frameworks 5 ports in the official FreeBSD ports repository ¬†have all their licensing information set, to the best of my ability to check their accuracy. As an ongoing project in keeping-license-info up-to-date it’s not very high-priority but something that gets done in-between other things.