Neon/Core

Overview

KDE Neon Core is an effort to create a variant of KDE Neon on an Ubuntu Core base. This means that all the components of the system are packaged as snaps.

Regular snap packaged applications can be installed and run on it, but a full system means that the content of the Plasma session itself is in a snap.

This page tries to document the components needed to build a KDE Neon Core system and how you can make an image to try it. This is still work in progress and as such comes with some limitations also described in this page.

Building Blocks

The building blocks described in this section are necessary to assemble a KDE Neon Core image. Without them no Plasma session can be started.

snapd

The daemon at the core of the snap system. It is orchestrating the installation and ability to run snap applications.

This is built from the following branch in our fork. We cannot use the stock snapd from the Snap store yet as we need a couple of extensions. Most notably we need:

• the extensions done by Canonical to launch snap applications via their desktop file
• the systemd-user-control interface

Information for contributors

This one is not the most convenient to package as snap. This will require the use of multipass and a VM with an old Ubuntu release to actually work.

First one needs to create the VM to build snapd, we'll assume it is named snapcraft-snapd in the following:

multipass launch -d 16G -n snapcraft-snapd xenial

The right version of snapcraft needs to be installed:

multipass exec snapcraft-snapd sudo snap install --classic --channel=4.x/stable snapcraft

Then the code of snapd needs to be exposed to the VM:

multipass mount $PATH_TO_CLONE snapcraft-snapd:/home/ubuntu/snapd

Once this is done, one can start a shell in the VM using multipass shell snapcraft-snapd and run the following:

cp -r snapd snapd2
cd snapd2
sudo snap install snapcraft --channel=4.x/stable
snapcraft snap --destructive-mode
cp snapd_*.snap ../snapd

The produced snap for snapd is then available in the host and can be used to build an image.

pc-plasma-desktop

The "gadget snap" providing configuration for the assembled system.

This is built from the pc-plasma-desktop repository. This is mainly here to force the use of plasma-core22-desktop as base for our system and auto-connections for plasma-desktop-session. If it wasn't necessary the stock pc-desktop snap could have been used.

Information for contributors

This can be simply built by invoking snapcraft at the root of the cloned project.

plasma-core22-desktop

The "base snap" providing all the content used in a Plasma session.

This is built from the plasma-core-desktop repository. It produces a snap providing all the necessary for a full plasma session. This snap doesn't provide any service or apps by itself though since it is a "base snap".

Information for contributors

If you run ./enable-developer-access.sh before building your snap, some extra files are added to the build to ease debugging. Most notably it does the following:

• opens a password less root access on the serial console
• adds a few developer tools like qdbus or apparmor tooling
• adds rules to force connection of a few interfaces needed for startup to work properly

Once done, this can be simply built by invoking snapcraft at the root of the cloned project.

plasma-desktop-session

The "app snap" driving the startup and services of the Plasma session.

This is built from the plasma-desktop-session repository. It has almost no content of its own apart from a couple of scripts and packaging declarations. It refers to the content of the plasma-core22-desktop snap. Its goal is to run parts of plasma-core22-desktop confined and exposed to application snaps.

Information for contributors

The run-plasma-session.sh script is a good entry point for getting more debug information about the session. You can modify it to change the execution environment.

Here is a snippet example you could add just before the final exec:

export QT_LOGGING_RULES="*.debug=true"
export QDBUS_DEBUG=1
systemd-analyze --user set-log-level debug

Then you would need to rebuild your snap of course. This can be simply built by invoking snapcraft at the root of the cloned project.

When starting up the session, journalctl should give you much more information about what systemd and Qt based applications are doing.

Create and Run an Image

You first need to clone the KDE Neon Core repository. Make sure you got the prerequisites for the tool chain to run. Then drop the snaps for the building blocks you built locally in the local-snaps directory. The other snaps will come from the Snap Store directly.

Then you can run make kde-neon-core-dangerous-amd64.img which will build the image. To run the resulting image run: ./run-image.sh kde-neon-core-dangerous-amd64.img.

The process is described in more details in the KDE Neon Core repository.

For even more details about ubuntu-image use and how to build images, you can head to the image building reference documentation.

Known Limitations

Need to build the main snaps locally

The main snaps used for the session are not available from the Snap Store yet. They're waiting to be whitelisted to be allowed to use some privileged interfaces. That's why the image is built mostly from locally built snaps for now. Due to this, some slots don't auto-connect as they should. Expect to have to do a few snap connect manually after installing a new application.

Need to provide our own snapd

Also we needed to adjust existing interfaces and add extra interfaces to snapd itself. One cannot assemble a system with the stock snapd, a temporary snapd branch shall be built and used for that purpose.

Disabled xdg-desktop-portal-kde

The work to get xdg-desktop-portal-kde to work and be exposed to other snaps is still on-going. As such snap applications even connected to the desktop interface are not able to use the portal services (which includes displaying file dialogs among other things).

No signed images yet

A consequence of the limitations above is that currently only "dangerous" variants of the KDE Neon Core image can be built. They need to be solved before "signed" images can be produced.