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 activity.py and can take a date range to limit what is shown, for instance ComDaAn/activity.py -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 on Krypton

Calamares is a Linux system installer (and some day, a FreeBSD system installer, but that is a long way off) which is distro- and desktop-independent. OpenSUSE Krypton is a live CD and installer for the latest-and-greatest .. but it already has an installer, so why try Calamares on it?

Well, sometimes it’s just to show that a derivative could be made (there is one, called GeckoLinux), or to experiment with tools and configurations.

Calamares has a script called deploycala.py, which like every gaping huge security hole is expected to be downloaded from the Calamares site, then run. It is recommended to only use this in a VM, with a live CD / ISO image running. What the script does is install a basic dev environment for Calamares, install up-to-date dependencies, and then it builds and installs Calamares. That then gives you a way to experiment, installing with Calamares from an already-set-up live CD.

The deploy script supports many different package managers and host systems, so it’s just a matter of running python3 deploycala.py -n to get started (and then wait for a while as packages are installed, Calamares is cloned, and then built). Calamares builds with no issues on Krypton (at least today, when I tried it).

Screrenshot of Calamares in Krypton

Calamares in Krypton (Qt 5.11)

Screenshot of Calamares in Manjaro

Calamares in Manjaro (Qt 5.10)

Having built Calamares, there’s a few bits I notice:

  • Esperanto isn’t supported in Qt applications (neither in Krypton, nor in Manjaro, nor in anything else I tested); QLocale has a constructor that takes an enum value specifying the language, but for a bunch of languages in that enum, it then creates a “C” locale. This is documented with the wriggly description “… if found in the database …”, but is rather unsatisfying.
  • Manjaro (Qt 5.10) does a better job of displaying Indic scripts than OpenSUSE Krypton (Qt 5.11), although this might be an artifact of installing updated packages into the live system.
  • The keyboard-layout picker displays no keycaps. It also doesn’t provide any useful debugging output. This is probably a combination of missing packages in the live system, and Calamares not providing enough useful feedback when the live image isn’t quite right. The latter, I can fix.

So, by briefly switching distro’s today, I’ve found one bug of my own, and one configuration thing for myself to document. And then from this not-using-Calamares distro, I can move on to another one.

HowTo Modern (2018) KDE on FreeBSD

Quite some time ago I wrote a how-to to install modern KDE on FreeBSD. Now that the ports are all in the main tree, things are a lot simpler. So I’m writing it out anew.

  1. VM: Let’s start over with a fresh VirtualBox VM, with a 30GB zvol for storage, 4GB RAM, 4 cores of my desktop CPU.
  2. Basic Install: Get 11.x, amd64. Don’t bother with src or with a ports tree, since this is going to install from packages. I picked auto-UFS, with MBR, the most straightforward setup. IPv4, DHCP, timezone .. for system-hardening options, I added clear /tmp and disable sendmail, nothing else. That whole process took about five minutes.
  3. Initial update: Run pkg once, to install it. Optionally, run freebsd-update to update the installed system to the latest security patches. Optionally, switch to a local pkg repository. Edit: Switch to the non-quarterly package branch, first. Thanks George.
  4. Basic packages: Run pkg repeatedly:

    pkg install xorg xterm twm # basic X
    pkg install sddm kde5 kdevelop kmail # the good stuff (edit: sddm optional!)
    pkg install virtualbox-ose-additions # only if VBox

  5. Service configuration: Add these lines to /etc/rc.conf (as suggested by the pkg-messages):

    dbus_enable="YES"
    sddm_enable="YES" # edit: if you want to
    vboxguest_enable="YES" # only if VBox
    vboxservice_enable="YES" # only if VBox

  6. Sysctl configuration: Add these lines to /etc/sysctl.conf to make sure Akonadi works:

    net.local.stream.recvspace=65536
    net.local.stream.sendspace=65536

  7. Reboot and login

Screenshot

And there’s a few gotcha’s:

  • In VirtualBox, sometimes the screen may not resize when you resize the VM window. That’s not actually a KDE Plasma problem, but you can run randr --output VGA-0 --auto from a konsole to get it to resize.
  • Akonadi may not start. There’s a warning about TIMESTAMP with implicit DEFAULT, something you can find in older KDE Forum posts, too. The fix is mkdir -p ~/.local/share/akonadi/db_data ; akonadictl start .
  • You can logout, but not shutdown from Plasma itself; you can shutdown from SDDM, but don’t count on any feedback after you click on the big red (er .. monochrome) off button.

Edit: 1. The packages are only built on the regular package branch, not quarterly, so you’ll have to switch to that if you want the packages. I didn’t catch that because (right, cheating) I have my own poudriere builds from ports HEAD. 2. SDDM is optional; you can of course use any other DM (be sure to run /usr/local/bin/startkde) or use startx and an .xinitrc file (in that case, use ck-launch-session, so that you can unlock in case of general disaster. 3. Logging goes .. somewhere. Gosh, I can’t find any useful output; we’ll document that on the KDE community wiki once it’s been tracked down. In the meantime, kdebugdialog5 --fullmode can help out. 4. As for KDevelop pulling in the old desktop environment, that’s probably solved by switching away from quarterly.

KDE at FOSS-North

Over the weekend, while some KDE people were in Toulouse improving Akonadi, and other KDE people were in Berlin improving Plasma, I was in Goteborg at FOSS-North showing off some KDE things.

Anyone who saw our FOSDEM booth knows the setup. We still had the same blue table (thanks, Sune) and selection of low-power ARM blinkenlights, the Pine64 and a Pinebook. I still think that “hey, Plasma runs fine on an overpowered x86 laptop” is not particularly interesting, but that “the past six months have seen serious work on reducing Plasma’s resource usage aimed specifically at this kind of device” is. Different from FOSDEM is that I could now run one of the just-released Netrunner images for the Pinebook.

There are pictures circulating of a staged fist-fight between me and Bastian, who ran the GNOME booth. Except for those 30 seconds, we were good neighbours and I’d like to thank Bastian for keeping an eye on things when the KDE booth wasn’t otherwise occupied.

Bigger thanks to Helio, who came from not-Bavaria to help at the stand as well and give a software archaeology talk. And biggest thanks to Johan, for setting up and running the whole conference.

I gave a talk on governance — call it “Open Source Project Governance 101, with a brief mention of how KDE does it specifically”. A half hour is long enough for an overview, not long enough to really go over all the considerations you might have along each of the different axes of decision. I’m more than happy to be talking with people about specific issues in governance. I didn’t see many talks themselves: just one on deep-dive C++ and OpenGL stuff (I didn’t understand all of what Patricia does) and reproducible-builds tools like diffoscope (Chris’s talk gave a nice overview).

Calamares Pinebook

Photo of laptop on table

Netrunner Pinebook

This week, there was the launch of Netrunner for Pinebook (1) (2). A lot of effort has gone into building the software, improving performance, getting automation and CI in place. That’s effort that benefits the wider KDE community, the wider Free Software-on-ARM community, and more. This is the laptop I’d take with me on a bicycle camping trip — clean, cheap and affordable, although heavier than a phone.

But there is an under-appreciated bit regarding images for an ARM laptop — or pre-installed Linux distro’s in general. And that’s the first-run experience. The Netrunner Pinebook image is delivered so that it boots to the Plasma 5 desktop, no passwords asked, etc. The user is called “live”, the password is “live”, and nothing is personalized. It’s possible, though not particularly secure, to use the laptop this way in a truly disposable fashion. A first-run application helps finalize the configuration of the device by creating a named user, among other things.

One of the under-documented features of Calamares is that it can operate as a first-run application as well as a system installer. This is called “OEM Mode“, because it’s of greatest interest to OEMs .. but also to distro’s that ship an image for users to flash onto (micro)SD card for use in a device.

Screenshot of desktop

Main Desktop on Pinebook

This screenshot is from Netrunner on the Pinebook, and you can see the purple-ish Calamares logo labeled “First Time Run This Installer” on the desktop — it’s partly hidden by the system information KCM. That runs Calamares in OEM mode, hardly distinguishable from the live-ISO-installer-mode that it usually has.

A Calamares OEM configuration generally:

  • Resizes the image file to fill the entire card,
  • Creates a user (the real one, personalised) with a password,
  • Performs some initial configuration of the real user,
  • Adds packages and system configuration based on that configuration, and
  • Does some cleanup (e.g. removing Calamares, since you only need it once).

Configuring Calamares as an OEM installer is no different from any other Calamares installation: make sure the config files end up in /etc/calamares, and then set dontChroot to true (that’s the real difference between OEM mode and regular).

The way Calamares development works, downstreams — that is the distro’s, and in this case Netrunner — just file feature requests for the stuff they need in Calamares, and after some back-and-forthing to make sure it’s sufficiently general, I write it. So the run up to Netrunner on the Pinebook saw some Calamares development aimed specifically at the OEM mode, and some extra bug reports. Nothing, though, that isn’t equally applicable to any other distro that needs a first-run installer.

There is a lot more that could be done in a first-run installer. KaOS has a really nice one, basically hand-holding through initial KDE Plasma Desktop setup. Pardus and Pisi Linux have something similar. A downside is that the more you do, the more specialized it becomes — it would be nice to have a good GNOME counterpart to the Plasma Look-and-Feel selection module in Calamares, but that quickly leads to a multitude of modules and dependencies (not to mention that I can’t write it all myself).

Anyway, that’s my little square inch claim to being useful to the Netrunner Pinebook project (which deletes itself).

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

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!