As KDE software (be it the Frameworks libraries, the Plasma 5 workspace, or the Applications) develops during a normal release cycle, a lot of things happen. New and exciting features emerge, bugs get fixed, and the software becomes better and more useful than it was before. Thanks to code review and continuous integration, the code quality of KDE software has also tremendously improved. Given how things are improving, it is tempting to follow development as it happens. Sounds exciting?

Except that there are some roadblocks that can be problematic:

• If you want to build the full stack from source, there are often many problems if you’re not properly prepared;
• Builds take time (yes, there are tricks to reduce that, but not all people know about them);
• If things break… well, you get to keep the pieces.

But aside personal enjoyment, KDE would really benefit from more people tracking development. It would mean faster bug reporting, uncovering bugs in setups that the developers don’t have, and so on.

What about noble gases?

Recently, an announcement about a gas used in fluorescent lamps generated quite a buzz in the FOSS community. Indeed, such an effort would solve many of the problems highlighted above, because part of the issues would be on the backs of integrators and packagers, which are much better apt for this task.

But what, am I telling a story you already know? Not quite.

A little flashback

For those who don’t know, openSUSE has a certain number of additional repositories with KDE software. Some of these, since many years, have been providing the current state of KDE software as in git for those who wanted to experiment. This hasn’t been done just for being on the bleeding edge: it’s also been used by the openSUSE KDE team itself to identify and fix in advance issues related to packaging, dependencies, and occasionally help testing patches (or submit their own to KDE).

So, in a way, there were already means to test KDE software during development. However, there was a major drawback in adoption, which involves the fact that these packages replace the current ones on the system. For technical reasons, it is not possible to do co-installation (for example, in a separate prefix) in a way that is maintainable long term.

So, what now?

After hearing about the announcement, we (the openSUSE KDE team) realized that we had already the foundation to provide this software to our users. Of course, if you got too much neon, you’d asphyxiate ;), so we had to look at alternative solutions. And the solutions were, like the repositories, already there, provided by openSUSE: the Open Build Service and the KIWI image system which can create images from distribution packages.

But wait, there’s more (TM)!

openSUSE ships two main flavors: the ever-changing (but battle-tested) Tumbleweed, and the rock-solid Leap. So, one user would ever want to experience the latest state of many applications, or just be focused on KDE software while running from a stable base. So, if we could create images using KIWI, why not create two, one for Leap and one for Tumbleweed? And you know what…


Lo and behold, in particular thanks to the heroic efforts of Raymond Wooninck, we had working images! We also like noble gases, so Argon and Krypton were born!

The nitty gritty details

These images work in two ways:

• They work as live images, meaining you can test the latest KDE software without touching your existing system, and like that, not worry about something that breaks;
• You can also install them, and have a fully updated Leap or Tumbleweed system with the KDE:Unstable repositories active. Use this if you know what you’re doing, and want to test and report issues.

Bugs, bugs everywhere!

Chances are that you might run into one or more bugs. This is software from git, and code review/continuous integration can only do so much. What should you do in such a case?

1. (NOT recommended) Kick and scream and demand a refund ;)
2. If your bug is in the distribution stack, like drivers or packaging, file a bug on openSUSE’s bugzilla with enough details so that it can be looked at;
3. If your bug is instead in KDE software, turn to KDE’s bugzilla.

And of course, like the openSUSE login text says, “have a lot of fun!”

• Linux
• KDE
• openSUSE
• tumbleweed
• leap
• live_media