Yocto

KDE in Yocto

If you never heard about Yocto, a very short and somewhat precise description is: Yocto is a framework to build very hardware tailored device images. It is the currently most used technology in automotive as well as in many embedded projects. In order to make device creation simply it both provides a build system called "BitBake" and hundreds of recipes for libraries, applications, hardware adaptations and images, whereas most of those recipes do not come from the "Yocto Project" itself but from the "OpenEmbedded" project. Those recipes are organized in layers and KDE provides the layers as described below.

== Our Offer

KDE currently ships two Yocto meta layers that are supposed to ease the use of KDE Frameworks, Plasma and Applications for device creators.

• meta-kf5
  • Repository: https://invent.kde.org/packaging/yocto-meta-kf5
  • Yocto Index: http://layers.openembedded.org/layerindex/branch/master/layer/meta-kf5/
• meta-kde
  • Repository: https://invent.kde.org/packaging/yocto-meta-kde
  • Yocto Index: http://layers.openembedded.org/layerindex/branch/master/layer/meta-kde/

Usage

The KDE community does not distribute any full system images in terms of a distributor but provides device manufacturers to integrate released KDE software into their products and or even to build their software products on top of KDE frameworks. Our goal is to follow the Yocto best practices in order to behave like any other Yocto layer.

meta-kf5

For using meta-kf5, simply clone the repository and add it as layer to bblayers. Our current approach with this layer is that there is only the master branch, which targets the following Yocto upstream branches. Dependencies are documented in the layer.conf file:

• dunfell : minimal requirement is dunfell patch version that supports new BitBake colon syntax
• kirkstone : supported
• "Yocto latest release" : not yet supported

The layer provides several recipes that follow exactly the repository names of the existing KDE Frameworks recipes. They are internally organized by "tiers" in the same way as the KDE Frameworks itself are organized.

Note that some of these recipes also bring tools that are required at compile time. Examples for those are "ki18n" or "kdoctools". In general, for those cases always there is a BitBake class provided by the layer that allows you for an recipe, which require those tools at runtime, to inherit it. That will configure the environment that cross-building will correctly pick up the right version of the tool.

meta-kde

For meta-kde, it is mandatory to also use meta-kf5. At the moment, the only Yocto branch in scope is:

• kirkstone

Demo Images

TBD

Layer Development

All changes to the meta-layers are supposed to be proposed as merge-requests in the GitLab repositories and be reviewed before being merged. The main reasons for defaulting to code-reviews is the complexity of the Bitbake language together with the absence of static code check tooling as well as the quality demands of users of the Yocto layers.

CI Approach

Scope

• The goal of the CI tooling is to automatically check the compatibility of the layers with regard to a certain release of the Yocto project in combination with a certain release in relation to a certain release of meta-qt{5|6}
• The CI shall ensure that there is a documented compatible combination of Yocto meta-layers
• The CI shall ensure that backports to older Yocto layers are compatible with older Bitbake versions and recipes

Technical Implementation

Mostly follow the approach done in meta-qt{5|6} in contrast to the Yocto approach, because the goal is to integrate CI builds into the KDE invent.kde.org infrastructure.

• yocto-manifest : new repo to track repo XMl files that provide defined combinations of meta-layers that are compatible for a certain CI branch or a specific release tag:
• both meta-kf5 and meta-kde shall contain a core-image-minimal derived test-image, which then can be used as a CI build target
• nativesdk build is in scope, because that is needed for developers to bootstrap their cross-building integrations
• target hardware for the CI builds is always qemu and not a specific target device

Branch / Merge Strategy

• application releases are updated in the master branch
  • exception is if the tracking branch for an old Yocto LTS release shall be updated to version older than in the master branch
• change from the master branch that shall be used for older Yocto releases shall be cherry-picked