Testing latest KDE software, from Apps to the Plasma desktop

This is the transcript of the talk I gave at Akademy 2023. If you prefer, you can watch the video (the sound is not great unfortunately) or look at the slides. The videos from the talk are in this post.

While this talk is focused on KDE software and Fedora Kinoite, most the concepts described here also apply to other Flatpak’ed applications (notably GNOME ones) and other rpm-ostree based desktops (Silverblue, Sericea, Onyx, etc.).

Testing: what, when, how?

Software has bugs! One way to find bugs is to have users test changes.

To make that possible, we need to deliver pre-release versions of our software in a way that is accessible to our users which are usually not developers.

Remember that even as a developer, you are always the user of someone else’s project. The technology stack is now so complex that it is mostly impossible to understand every single projects included in a modern desktop environment, even if it is fully open source.

Testing pre-release software also has to be reasonably safe regarding user’s data, as it’s often not practical to ask users to backup everything all the time and testing a small fix for an application should not have your entire system crash.

Users must also be able to go back to state where their system is running only “stable” software again, after they have completed testing a change or a fix.

Ideally, we would let users test all changes before they are commited to a repo, during the merge request process. But sometimes this is too difficult and we should then enable them to test those changes as soon as possible after they are commited.

Let’s start with KDE Apps

We’re now publishing most of KDE Apps as Flatpaks on Flathub. We track the latest stable releases. Updates are directly shipped to users.

See Albert Astals Cid’s talk (Flatpak and KDE) for more details about Flatpak, how they work and how we use it for KDE Apps.

KDE Apps on Flathub

On Flathub, the pull-request workflow is enforced. Each PR will build a “test” Flatpak. This Flatpak is installed using a single command.

This let’s developer create Flatpaks with fixes for users to test on top of stable releases.

Below is a demo of testing a Flatpak fix from Flathub:

Transcript of the video:

# Go to PR: https://github.com/flathub/org.kde.gwenview/pull/97

# Download Flatpak:
$ flatpak install --user \ https://dl.flathub.org/build-repo/35177/org.kde.gwenview.flatpakref

# Run Flatpak
$ flatpak --user run org.kde.gwenview

# Run Gwenview from the host to compare versions
$ gwenview

# Cleanup
$ flatpak --user uninstall org.kde.gwenview

KDE Apps on KDE Invent

We are progressively setting up the same infrastructure in KDE GitLab instance (invent.kde.org) using GitLab CI.

Flatpak manifests are directly stored in application’s repos. Every pull request creates a Flatpak bundle to try out.

This let’s user test fixes and features before the change is merged.

Below is a demo of testing a Flatpak from GitLab CI:

Transcript of the video:

# Go to PR: https://invent.kde.org/graphics/gwenview/-/merge_requests/208

# Download the artifact:
$ curl -O https://invent.kde.org/graphics/gwenview/-/jobs/1041125/artifacts/download?file_type=archive

# Unzip and install the Flatpak bundle
$ unzip Flatpak_artifacts.zip
$ flatpak --user install --bundle ./gwenview.flatpak

# Run the Flatpak
$ flatpak --user run org.kde.gwenview

# Cleanup
$ flatpak --user uninstall org.kde.gwenview

More advanced Flatpak usage

Flatpak content is stored in an ostree repo. Similarly to a Git repo, you can fetch any previous build to test regressions or compare behavior. This works with Flatpaks from Flathub.

Note that apps strictly tied to Qt versions will also need an older Runtime.

Below is a demo of bisecting a Flatpak from Flathub:

Transcript of the video:

# Install a Flatpak from Flathub
$ flatpak --user install org.kde.kcalc 

# Look at the log of versions (ostree commit log)
$ flatpak --user remote-info --log flathub org.kde.kcalc | less

# “Checkout” an older version
$ flaptak --user update --commit=... org.kde.kcalc

# Run the older version
$ flatpak --user run org.kde.kcalc

# Reset to latest version (note: operation canceled)
$ flapak update

# Skipping updates for a Flatpak
$ flatpak --user mask org.kde.kcalc

# Testing updates again
$ flapak update

# Removing the mask
$ flatpak --user mask --remove org.kde.kcalc

# Listing masks
$ flatpak --user mask

# Cleanup
$ flatpak --user uninstall org.kde.gwenview

Can we do the same for KDE Plasma?

(Re-)introducing Fedora Kinoite

Fedora Kinoite is a Fedora variant featuring the KDE Plasma desktop. It follows the latest upstream KDE releases. It is stable and based on an up to date software stack from Fedora: Wayland, Pipewire, systemd user sessions, etc.

Fedora Kinoite brings the concept of an immutable desktop operating system, which means that you control when your system is changed.

The system is focused on Flatpak and container based workflows.

See my previous talk at Akademy: Akademy 2021: Kinoite, a new Fedora variant with the KDE Plasma desktop (slides, video).

Benefits of rpm-ostree

The system is shipped as a single consistent image. The updates are performed atomically: either fully applied or not, thus there are no broken updates and your system is always in a working state.

System updates (rpm-ostree) keeps all your data and Flatpak apps as-is. It makes it easy to rollback to a previous known good version.

You also have access to package diff between versions.

rpm-ostree ❤️ containers

rpm-ostree is now capable of delivering operating system images as a container images. This lets you manage operating system versions with containers tags.

You can store each version of your operating system inside a container registry and rebase your system to almost any version.

Below is a demo of rebasing to a container on Kinoite:

Transcript of the video:

# Looking at current state
$ rpm-ostree status

# Find the version to rebase to in the repo on Quay.io:
https://quay.io/repository/fedora-ostree-desktops/kinoite?tab=tags

# Rebase to this version
$ sudo rpm-ostree rebase \
ostree-unverified-registry:quay.io/fedora-ostree-desktops/kinoite:38.20230710.xyz
$ reboot

# Package diff
$ rpm-ostree db diff

# Cleanup and rollback
$ rpm-ostree cleanup
$ rpm-ostree rollback

Looking forward to Plasma 6

Fedora Kinoite Beta & Nightly

See Introducing Kinoite Nightly (and Kinoite Beta).

The builds for those images are currently paused (waiting for Plasma 6).

Plasma 6 Kinoite images?

We’re working on it! We’ll make Fedora Kinoite Nightly images, with Plasma 6 packages, on top of stable Fedora.

Hopefully coming soon!

Future options for testing?

Could we do pre-merge checks? Testing with OpenQA?

Running OpenQA tests for each Plasma PR is likely to create too much overhead, but maybe we can do daily or weekly checks?

Bringing RPM specfiles to Git Repos and building then in GitLab CI would significantly help with Fedora Kinoite Nightly and Beta efforts for testing.

Conclusion

Happy testing!