Over on the Calamares website, most of the news items are about releases and the release schedule. Here’s some more community-related tidbits for the first quarter of 2020.

Calamares development is sponsored by Blue Systems, which means I can spend three days a week – more, in practice – working on it. This is a form of service to the Open Source community; Calamares is used by some Linux distro’s that Blue Systems is interested in, but I (or Calamares) explicitly support all kinds of distro’s. Every downstream is a welcome downstream.

In the first few months of 2020 I learned of several “new” distro’s that use Calamares. “New” to me; they have existed for years, usually, and I don’t pay attention to every Linux distro out there. Drop me a note by email, as a GitHub issue, or on Freenode IRC in #calamares if you have a distro that should be listed among the Calamares-users.

As an aside, I get lots of “new distro” news via Twitter, just from following Jason Evangelho and waiting for new videos on Linux for Everyone.

Calamares is a distro- and toolkit-agnostic installer. So while there are specific technology choices in Calamares, it says nothing about the technologies your distro should be using. Calamares uses Qt and works just fine in a GTK-based environment, or whatever – I don’t think there are any Motif- or plain XLib-based environments anymore though. Calamares supports Debian, (Ubuntu), Arch, Fedora, SUSE and Gentoo derivatives; it can be fit and configured for everyone.

That isn’t to say that Calamares “as-is” can install any distro: any distro can configure Calamares to install that distro. That can take a fair bit of work, although cribbing notes from existing users saves a lot of time. I see each distro as one of my users; generally the person building the ISO (installer) images for that distro is my “customer” or “user” and I talk mostly with them to make Calamares work well for that specific distro.

News to me

Here are some “new” distro’s. I don’t really care what they install in the end but I do care about the installer. I often spend a few hours in a live ISO image, rebuilding Calamares and checking that the next version of Calamares works for the distro. That means I see some of the bits the distro provides, but I certainly don’t do a deep-dive.

Lubuntu is a lightweight Ubuntu, which installs LxQt. There are a few Calamares modules for Ubuntu-derivatives that are developed by Lubuntu. Usually I’m an “eager upstream”, and I think that modules should live upstream. This module, automirror, is really distro-family specific though and I’m happy to see that it’s good code (smart enough to fetch cached GeoIP results) and maintained downstream – and if Lubuntu needs something, they know where I live on IRC. (Edit 2020-04-09: not LXDE, LxQt – I said I don’t pay much attention to what the environment is, eh.)

UbuntuDDE is a new kid on the block, with a gorgeous environment (and a warning when running it in a VM that the graphical effects might not be supported). As another Ubuntu derivative it shares parts of the Lubuntu configuration for Calamares, which I think is efficient and smart.

Salient OS is an Arch derivative – from a very different distro-family – aimed at gaming enthusiasts. I get careful bug reports and feature requests from Salient, and am happy to drive some extra features into Calamares to support their use-cases. Some recent expansion of the netinstall module comes from this side.

Hamara Linux is more than an operating system, there is a clear social conscience and cultural plan behind it, promoting self-sufficiency and local growth. I don’t interact with the Hamara people much – we met at conf.kde.in – but they are self-sufficient and self-reliant.

Calamares plans

Calamares runs on “short cycle” releases; that means a new release every two weeks or so (varying from one to four). I’ve been doing that for a year now, and while it slightly annoys packagers it does mean that there are recent bugfixes whenever a new ISO from any distro needs to be rolled.

This year, we’ve had Calamares 3.2.18, .19, 19.1 (oops), .20, .21, and .22 happens today. Each comes with release notes – generally short ones, because it’s a short cycle – and thanks to a few contributors from downstream who have contributed patches or especially useful bug reports.

At some point Calamares 3.2 development is going to slip into “LTS” mode and receive only bug-fixes. That is when 3.3 development will start, and that is when a bunch of configuration-incompatible changes will be made – basically, ripping out a bunch of code that still supports old configuration options, and stating that the new way to configure things is the right way.

As an example, the URL for the release notes button on the welcome page can be specified in two different and unrelated places. And if specified, can then be turned off separately. This will become one single place.

The time for that split is not now, though: there is still a bunch of tidying that I feel needs to be done before then. One of the things I noticed in a previous long-lived Calamares branch is that backports become much harder when there has been tech-debt removal and cleanup in between: a backport becomes a rewrite-this-bugfix-against-the-broken-old-API and that’s no fun at all.

So, count on at least another four months of 3.2 series releases with regular clean-up. Some of those releases will also contain module-replacements: I’m trying to move all the essential functionality of Calamares to C++ modules, rather than Python. Why? Part of it is reducing the dependency footprint, to allow Python-free live images. Part of it is the desire to have better-checked code before I run it. The last bit is a desire to replace the ad-hoc approaches of many of the Python modules with more-structured and better-designed code: for instance, to run external helper commands in a consistent way.

Once the split happens, 3.3 releases will probably start slow as a large axe descends on legacy code.

Calamares features

Sure, there are 118 open issues right now, of which at least 34 are feature requests, but there’s one big feature that is in the pipeline that I’d like to pick out: QML

The Calamares UI is built with Qt Widgets. This offers some flexibility for styling through platform styling and Qt Stylesheets, but there are limits to that flexibility. In particular, re-arranging a panel or swapping out icons can be a real pain, and there have been downstream forks of Calamares for that kind of stuff.

As an additional option we’re moving to QML UIs. These offer a lot more flexibility for designers, since they don’t have to be compiled in to Calamares, and they offer more space to move things around or style them specially for a distro. The widgets-based UI will still exist, and you can (or will be able to) turn off QML entirely if you like (although that also affects the slideshow during installation).

Camilo Higuita – also involved with Nitrux – has been pushing this forward. There are three kind-of-independent axes along which this work develops:

  • Cleaning up Calamares internals to be QML compatible. This means adding Model-View code to internal data structures so that those structures are available to QML. There’s plenty of tech debt, where configuration and data is mixed in with existing widgets code, so this needs to be resolved and extracted – so that the widgets code and QML code both use the same underlying data. Plenty of short branches here to clean it up.
  • Getting QML to load nicely. Since Calamares is a framework that assembles itself based on a configuration file settings.conf, it puts together the UI from lots of different parts. Loading separate QML files into a complete thing is slightly tricky.
  • Writing an acceptable generic QML UI. Although the idea is to use QML to offer designers lots of flexibility and freedom to create a unique UI, we need a basic UI to at least showcase that QML UIs are possible and to validate that the internals are good.

There are currently modules welcomeq, localeq and keyboardq which offer QML UI alternatives to the existing modules of the same name without the q. The developers of KaOS are creating and polishing up the generic QML.

I think I’m going to make KDE’s Kirigami a requirement for the QML UIs (at least the generic ones) because it is lightweight (about 1MB packaged) and offers a lot of UI parts used in KDE applications. Designers are welcome to use their own frameworks for QML if they like – that is the freedom and flexibility that QML offers and you can start from scratch if you want.

Eager upstream

Calamares is an eager upstream. That’s a phrase I’ve coined for

  • forks should only happen if really really really needed,
  • let’s work together, up and downstream, to avoid that,
  • when I say “PRs welcome” I mean that they are welcome, encouraged, and will be given a review,
  • issues filed even for downstream problems are considered.

It comes down to roughly this: if something downstream needs a feature that makes sense at all for more than one distro, I encourage it to come upstream. I might not test it myself, but it’ll be there for everyone who needs it.

.. and now it’s time to push the button on the next release.