There is a typo in the "constainers" path, it should be "containers":

What happened

After the GPSD PR (#178) was merged, Leda Distro builds that use meta-leda main now fail to build, due to one of the packages related to gpsd failing to compile.

Error log

error.log

Steps to reproduce

Check-out the main branch of leda-distro, setup a devcontainer/codespace as per the documentation and run

kas build kas/leda-qemux86-64.yaml:kas/mirrors.yaml

The build will fail with a similar error log as the one above.

The verity format should be used instead of the old plain format. The current bundle recipe doesn't set RAUC_BUNDLE_FORMAT so it defaults to plain.

It was introduced in 1.5 to address shortcomings in the plain format: https://rauc.readthedocs.io/en/latest/changes.html#release-1-5-released-dec-14-2020
See
https://rauc.readthedocs.io/en/latest/integration.html?highlight=verity#bundle-format-migration for details.

Fetch fails due to branch rename: master -> main

The components metalayer (meta-leda/meta-leda-components) is supposed to be reusable for other distros as well.
Hence, we need a workflow to test the independence of the components recipes without using the Leda distribution.

The current version of Yocto (Langdale) is not an LTS version, but it may still be used by someone.
We should make our metalayer compatible with Langdale anyway.
See https://wiki.yoctoproject.org/wiki/Releases

After using kas build how can I run qemu in my PC please

The previous setup of Eclipse Leda distro used a Kubernetes-compatible control plane (k3s).

As the behavior of a k3s cluster is not, we decided that we're switching to an Eclipse Kanto based container management for future development. Kanto-CM is based on containerd, very lightweight and better fits the needs on embedded devices than k3s.

Compiling raspiberrypi 4B image failed,
in kas/.config-kirkstone-rpi4.yaml missing:

meta-kanto:
url: "https://github.com/eclipse-kanto/meta-kanto.git"
refspec: kirkstone

The Eclipse SommR project is going to provide a Some/IP implementation.

The SommR daemon should be preinstalled on the Leda distribution.

We introduced meta-leda-backports to port GoLang 1.19+ back to kirkstone, which is required by meta-kanto due to security vulnerabilities upgrades.

In the meantime, we found meta-lts-mixins to provide backports for kirkstone as well.
It may be good to migrate to the official meta-lts-mixins instead of maintaining our own meta-leda-backports.

meta-leda should support hardknott, as this is the only supported release for a specific hardware from Owasys, which we want to use for demo purposes.

Long-term, we try to only support LTS releases of yocto.

Hello,

I would like to know if there is a defined way to "include or enable" an Eclipse SDV project in a Leda build.

For example, we have a Eclipse Bluechi layer that can be included in an Yocto build: https://github.com/eclipse-bluechi/bluechi-on-yocto and I am sure other Eclipse SDV projects could follow the same path, using Bitbake layers as the standard way to run/test their stack within Eclipse SDV.

That means one could easily switch around which container orchestrator or messaging layer to use when building a Leda distro, that would even open the possibility to define some common testing tooling for Blueprints as well.

Any thoughts?

The current bundle recipe set RAUC_BUNDLE_COMPATIBLE = "Eclipse Leda" , so even bundles targeting different architectures use the same compatible. A common approach is to set different RAUC compatibles in the MACHINE files.