Hi all, The response period for this RFQ is now closed and I have acknowledged each submission that we have received. In the unlikely event that you've sent a response to the RFQ and not got an acknowledgement email from me, please reach out to me this week.
I'll provide an update once the Yocto Project TSC has made a decision on our next steps. Thanks, Paul On Mon, 23 Feb 2026, at 12:10, Paul Barker wrote: > Hi all, > > The Yocto Project has identified an opportunity to make a significant impact > within the Linux Containers space. We can build on recent improvements to the > way container images can be built and tested with Yocto Project tooling, as > presented by Bruce Ashfield at the recent OpenEmbedded Workshop in Brussels > (slides: > https://pretalx.com/media/openembedded-workshop-2026-2025/submissions/ZGLVF7/resources/_0Jc2imX.pdf). > This approach gives us repeatable, auditable, curated containers using the > Yocto Project’s standard build process, which includes all of the existing > benefits that come with our builds. > > To achieve our goals, changes will be needed in metadata layers and the > autobuilder configuration. We would like to move forward with these changes > rapidly and so we need 2-3 months of contractor help to turn this into an end > to end technology demo. We invite individuals and organisations who are able > to deliver the Statement of Work outlined below to submit quotations to the > project. > > Responses should be submitted by email to [email protected] before > *Monday 2nd March 2026, 23:59 PST*. > Background > > The Yocto Project is a highly capable toolkit for building Linux images and > distributions. We have achieved extensive use within the Embedded Linux > space, as well as expanding to support real-time operating systems (RTOS) > such as Zephyr. We have a long history of leading the way with our tools to > support compliance, including license manifest generation, SBOM creation, CVE > tracking and source archival. With the advent of the EU Cyber Resilience Act > (CRA), these compliance tools have become even more relevant and are needed > across the whole software industry, not just in the Embedded space. > > Within the wider Linux containers ecosystem, current compliance tools work by > scanning a generated container image and attempting to identify the included > components. This works well when all components are installed via a > distribution’s package manager and when manually installed software > components come with their own pre-generated SBOM. However, as container > image generation is essentially a free-form process, there is no way to > ensure that all components will be correctly identified and no guarantee of > reproducibility. > > These approaches can be contrasted with the tooling provided by the Yocto > Project. Here the builds system owns the complete image creation process, > using strongly delineated steps of source fetching, compilation, packaging > and rootfs creation. We provide clear guidance on best practices and can > detect many common mistakes that can impact the quality of compliance data > (for example, we can prevent attempts to download sources outside of the > appropriate fetch stage). Reproducibility is treated as a first-class project > goal and is covered by our test suite. These features provide much stronger > guarantees about the quality of the generated compliance data than can be > achieved with a free-form process. > > We support building Linux container images using Yocto Project via the > meta-virtualization layer. Recent improvements allow for container generation > using standard container tools such as docker, without the need for elevated > (root) privileges or other workaround, which was the missing piece of making > containers a primary project technology. > Goals > > To fully demonstrate the project’s container capabilities, the project would > like to show we can build and publish containers. We want to do this by > creating and populating a reference container registry with sample container > images accompanied by comprehensive SBOMs. The process of building and > publishing images needs to be fully automated, running regularly on our > autobuilder cluster to ensure that the reference images remain up-to-date > with changes to our build system and are fully integrated into our CI > workflow. Test cases and documentation need to be expanded to cover the new > features, and developers need to be guided towards best practices when > customising the reference images for production use cases. > Required Skills > > • Experience of Yocto Project/OpenEmbedded builds > • Knowledge of container image generation and best practises > • Knowledge of publishing containers and container registries > • Experience and knowledge of the Yocto Projects CI infrastructure and > tooling/processes > Statement of Work > > **Reference container recipes** > > New recipes must be defined for an initial set of reference container images, > using the `image-oci` bbclass in meta-virtualization. The initial set should > focus on software which is commonly deployed via containers, such as: > • A minimal image (based on core-image-minimal) > • A Python 3 base image > • A sample web application written in Python > • A PostgreSQL database server > • A multi-service container using systemd to manage services > The above list is not intended to be prescriptive - we appreciate input on > appropriate reference container images. The final list of approximately 3-5 > reference container images will be agreed with the Yocto Project TSC. > > Reference container images should be built with the standard poky distro > config. They should build for multiple architectures - initially x86-64, > aarch64 and riscv64. > > This task requires recipes for the agreed list of reference container images > to be added to the meta-virtualization layer. > **Test cases** > > We must be able to test that the container runtime and the reference > container images can be built and that they behave as expected. > > This task requires creation of new oeqa selftest cases which perform build > and runtime testing of the reference container images using the chosen > container runtime. These cases should ensure that the container runtime is > able to create containers from the reference container images, start the > containers, interact with them and stop them without errors. > **Autobuilder integration** > > The new test cases must be executed on the project autobuilder instance as > part of our regular testing. > > This task consists of any integration work required to get the test cases > running on the autobuilder. It may require modification of the controller > configuration (yocto-autobuilder2), build/test scripts > (yocto-autobuilder-helper) and working with Linux Foundation IT to make > configuration changes to the autobuilder workers (such as installing > additional host software). > **Publishing reference containers** > > The reference container images must be published to a publicly accessible > container registry, as multi-arch images with support for at least x86-64, > aarch64 and riscv64. Images should be tagged in line with container best > practices. Due to usage restrictions and rate limits, Docker Hub should not > be used. In line with the Yocto Project approach of owning our > infrastructure, we should run our own container registry if possible. > > This task requires working with Linux Foundation IT to setup a container > registry server for the project - all required system administration tasks > will be performed by Linux Foundation IT but they may require advice and > support with things like selecting a container registry implementation that > meets our needs. > > This task also requires integration work within the project autobuilder > instance to publish container images to the registry. It may require > modification of the controller configuration (yocto-autobuilder2), build/test > scripts (yocto-autobuilder-helper) and working with Linux Foundation IT to > make configuration changes to the autobuilder workers (such as installing > additional host software). > **Publishing SBOM attestations** > > SBOMs should be generated for the reference container images and published to > the container registry as build attestations and/or OCI layers as appropriate. > > This task requires integration work within the project autobuilder instance > to publish SBOM build attestations along with container images. It is likely > to require modification of the autobuilder build/test scripts > (yocto-autobuilder-helper). > **Documentation** > > All new features must be well documented. Our documentation should guide > developers on how to customise the reference container images, following best > practices and making full use of compliance tools like SBOM generation. > > This task requires working with our documentation writer to cover the new > features, bbclasses and reference container images added as part of this > work. The majority of documentation changes can be made by our documentation > writer, but they will require guidance and review of their proposed changes. > References > > • openembeded-core layer: _https://git.openembedded.org/openembedded-core/_ > • meta-virtualization layer: > _https://git.yoctoproject.org/meta-virtualization_ > • Autobuilder configuration: > _https://git.yoctoproject.org/yocto-autobuilder2_ > • Autobuilder helper scripts: > _https://git.yoctoproject.org/yocto-autobuilder-helper_ > • Documentation: _https://git.yoctoproject.org/yocto-docs_ > • OCI image attestation storage: > _https://docs.docker.com/build/metadata/attestations/attestation-storage/#attestation-blob_ > • OCI image SBOM attestations: > _https://docs.docker.com/build/metadata/attestations/sbom/_ > > Best regards, > > Paul Barker > Ecosystem Engineering & Operations Lead, Yocto Project
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2293): https://lists.openembedded.org/g/openembedded-architecture/message/2293 Mute This Topic: https://lists.openembedded.org/mt/117955657/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
