Blog

It feels like only yesterday when we reviewed what we did in 2021, and suddenly 2022 is over too! This was a busy year for everyone and obviously we didn’t feel the time passing by. However, we can try to remember what we did and admit that all this indeed took time!

Technical summary

The main achievement was the release in May of version 4.0 (aka Kirkstone), our second LTS (Long Term Support) release. The project is committed to supporting it for at least two years, and at the same time continues to support its first LTS (3.1, aka Dunfell) for two more years (until Apr. 2024). In this way developers have plenty of time to switch from one LTS to the next. It is an interesting experiment for the project to see how much effort will be required to: support one LTS release for 4 years, maintain another LTS (Kirkstone), produce the current stable release, and prepare for the next release, all at the same time!

The project was pleased to announce 100% binary reproducibility of the project’s core components with this feature being enabled by default in all builds. The project also added SPDX Software Bill of Materials (SBoM) generation, and now has automated tooling around CVE analysis. These features mean systems built with the project have clearly identified components and can be rebuilt or changed as needed should the need arise for security updates, or any other reason, in the future.

Here is a curated selection of noteworthy technical changes found in the releases we made in 2022:

• Release 4.0 (Kirkstone) included Rust and SPDX 2.2 SBoM generation support. These features were already present in version 3.4 (October 2021), but continued to mature in 2022. Rust improves software development efficiency while providing enhanced memory management. SPDX facilitates management of open source licenses and security vulnerability assessment.
• Release 4.0 was also the first LTS with our new override syntax, introduced in 3.4. The new syntax helps engineers by clearly distinguishing override labels from variable names.
• CVE checking improvements, in particular to export the report in JSON format. These improvements facilitate keeping distributions up to date with security fixes.
• License names in recipes must now be standard SPDX license identifiers. The standardization of license names facilitates management of open source licenses.
• Binary reproducibility is now standard as well as network access is now disabled by default (in all tasks except do_fetch), relieving developers from explicitly enabling/disabling them. The new defaults improve build consistency from the beginning of a new project.

There was also news on the documentation front. In particular, coverage for a few topics was expanded:

• Brand new SPDX SBoM generation documentation.
• Improved documentation of CVE management.
• Release notes are now part of the documentation, not just in plain text but in all the formats supported by Sphinx. In particular, this makes it possible to refer to a particular section of the release notes. These new release notes are found next to the release migration notes link, starting from version 3.4 (Honister) on.

Conferences and summits

We organized two successful virtual Yocto Project Summits in 2022.

The first one was in May, offering a mix of hands-on sessions, technical presentations and product showcases, followed by informal “Social Hour” time to chill out with speakers and other participants. 21 videos were recorded and slides are available on elinux.org. 273 unique participants attended this event.

The second one was in November, offering the same types of sessions. 31 videos from the event are available and slides are available on elinux.org too. 308 unique participants attended this event.

The Yocto Project got back to in-person events for the first time by having 5 talks at the Embedded Linux Conference in Austin in June.

The Yocto Project also had a big presence at the Embedded Linux Conference Europe in Dublin in September, including 5 sessions and a booth which was donated by Arm. This booth was busy at all times! This event allowed many friends of the project to reunite at last for the first time in 3 years.

Community update

The Yocto Project has been working with SPDX, another Linux Foundation project, to support generating Software Bill of Materials (SBoM) files which can include all the relevant metadata in BitBake recipes, the dependencies between them, and security vulnerability information. Yocto Project developer Joshua Watt is involved in drafting version 3.0 of the SPDX standard.

The Yocto Project, being an Open Source project, has many well-known users, but also many invisible ones. If your company is one of the invisible ones, you can help raise awareness of the Yocto Project without having to reveal any secret information by adding your company’s name to the list on the Project Users wiki page. Of course, more detailed testimonials such as blog posts are even better, and we will be happy to give visibility to them if you let us know through our advocacy mailing list.

Following hard-to-predict events which happened in 2022, the Yocto Project is now present on Mastodon. If you haven’t tried it yet, you will be surprised how many familiar names and faces you will find there!

Members updates

The BMW Group joined the project as a Platinum member and Axis Communications also joined the project as a Silver member. We are grateful to all our members who back our community contributors through engineering time and funding!

Featured product

Synesso brings the ultimate coffee experience of coffee shops to the home with the ES.1. The innovative fuzzy logic control system lets the user experiment with and fine tune all parameters of the brewing process. At the the push of the home barista’s fingertips the Yocto Project powered touch computer adjusts pressure and temperature, provides graphical analysis, records brewing profiles and automates in pursuit of the perfect recipe.

In addition to those benefits as may be set forth in the Project’s Charter, Members of the Yocto Project shall be able to receive certain member benefits as set by time to time by vote of the Governing Board, subject to the availability of project resources. Unless also specified in the Charter, any benefit listed below may be modified or removed by the Governing Board by a standard vote taken in accordance with Section 5.a. of the Charter. At the start of the Project, the following additional benefits, according to their respective level of membership and as made available by the Governing Board and The Linux Foundation

Additional information on these Yocto Project Member Benefits

Git Repo placement: If eligible, it means a member organization can have priority placement of their repositories on git.yoctoproject.org.

Regular Builds: Platinum Members may have multiple configurations (for a board or device) included in the regular builds, while Gold Members may have a single configuration. The regular builds are an “acid” test of any changes made to the Project relative to these configurations and the integrity of other Yocto Project components. Regular Builds go hand in hand with Layer testing and Reference Platform influence.

Layer Testing: The Yocto Project would like layers to be validated against each official Yocto Project release. To provide the highest level of continuity for Platinum Member customers, based on QA results, the project will, within reason, provide preferential treatment to member organization layer patches in time for a new release. For Gold Member customer continuity, the layers will still be tested but once past a certain freeze date patches cannot be accepted. All other Members and non-member users will be dependent on the layer owners for testing and timely updates.

Reference Platform Influence: A member organization can request certain boards to be designated “reference platforms”. These are runtime tested as part of the QA procedures for a release and will be covered in the documentation. Requests are not guaranteed to be included, as included platforms depend greatly on resources available.

Compatible Badge: Members with compatible products or content have special member- designated compatible badges to use on their marketing materials. Those who are not members may use the generic Compatible badge if they meet the criteria set out in the Yocto Project Branding Program.
Booth / Ad Logo: The Yocto Project would like to emphasize those who contribute at the levels required to continue development and provide project stability in our marketing, PR, and event materials.

To fulfill the evolving requirements of its members and users, the Yocto Project announced a new plan to extend support for selected releases. The new support plan covers an initial two-year period and the first candidate to benefit from this change will be the Yocto Project 3.1 release.

A very important criterion for evaluating and adopting a software platform is support. This holds true when it comes to development tools as well. Yocto Project releases are usually maintained for one year. Beyond this period, releases move to community support, which means they only receive occasional patches for critical defects and updates, and no regular defect fixes and security updates. Although this follows the open source culture, where development is particularly known for speed and bleeding-edge innovation, there has been a rising interest among project members and end users for extending this period. As a result, the Yocto Project technical leadership put together a proposal to address this need as well as arranging the tools and processes to allow it to best benefit the project and its users.

The project aims to choose an LTS release every two years. The project components covered under the new plan will match the core subset of those included in the standard release process: Bitbake, OE-Core, meta-yocto, and yocto-docs. These components will now receive the usual defect fixes and updates for the extended period of two years. Additional layers, such as meta-mingw, meta-gplv2 or general OSV vendor layers will not be covered and will follow their usual standard support models.

The LTS release will support the original kernel it has been shipped with. Yocto Project technical leadership will continuously evaluate other similar older LTS kernels on a case by case basis depending on the status of upstream support. The version of linux-libc-headers would not change to avoid user-space problems.

This change will also benefit other downstream projects relying on Yocto Project releases that have longer life cycles such as AGL, RDK etc. The decisions that the technical leadership makes will take into account the community feedback, people committing resources and input from the member organizations.

The LTS maintainer will be responsible for queuing and reviewing suitable changes and starting and monitoring builds. The maintainer may have assistance from the community in resolving new issues identified during build or the QA run. Reviews will use the usual community review mailing list processes. For example, where applicable, a merge request will be sent to the appropriate repo owner once all issues found during the review have been addressed.

The Yocto Project LTS maintainer role hasn’t been appointed yet. At the moment, the project technical leadership is focused on finding the dedicated resources. For more information, and to discuss the LTS maintainer role, contact lts-maintainer@yoctoproject.org.

Today, the Yocto Project – an open source collaboration project which enables developers to create custom Linux*-based systems for an expanding array of uses including embedded, IoT, connected edge, servers, and virtual environments – announced their latest project release, Yocto Project 3.0 “Zeus”. Additionally, the project announced industry support from a new platinum member. For almost a decade, the Yocto Project has continually evolved to meet advancing software development needs. The latest release provides innovative capabilities and technologies that can improve engineering productivity while reducing infrastructure cost.

As the line between embedded and enterprise software requirements continues to blur, there is an increased demand for modern, optimized development practices and tools applicable to industries including transportation, retail, manufacturing, medical, and networking. Yocto Project 3.0 release kicks off a new era in streamlined software development, eliminating redundancies, automating testing steps, and optimizing build processes for customized Linux. “It is wonderful to see where the community is taking the Yocto Project,” said Lieu Ta, Chair of the Yocto Project Advisory Board, “With this year’s new members, the first multi-day Technical Summit, and the release of 3.0 the project is enjoying strong support. It’s a great time to be part of the Yocto Project.”

Release highlights:

• Optimized build processes: Build change equivalence can be detected and used to avoid rebuilding of unchanged components; build task execution and restoration of output from the shared state cache is now done in parallel.
• Improved automated testing: Upstream tests for core toolchain components are now integrated. This release also significantly improves the pass rate for existing upstream tests (“ptests”) and enhances “resulttool” which provides results storage and analysis functionality.
• Automated CVE analysis improvements: Developers can test their builds against known CVEs and compile reports with greater accuracy and detail.
• Improved multiconfig builds: shared state cache is now shared between configurations being built concurrently; syntax is simplified.
• Enhanced support for EFI and BIOS+EFI configurations and kernel + initramfs bundling in the image creator (“wic”).
• Adoption of SPDX license identifiers throughout Yocto Project’s components.

The project continues to develop under the technical leadership provided by Richard Purdie, Project Architect and Linux Foundation Fellow. “Yocto Project 3.0 brings together the project’s unique technology giving us reproducible software with full build traceability, yet at the same time allows cutting edge reuse of artefacts for performance and efficiency.”, said Richard Purdie. More information on the latest Yocto Project release is available at https://yoctoproject.org/software-overview/downloads/.

The project is supported and governed by high-tech industry leaders who have contributed financially, with infrastructure support, and marketing efforts to keep Yocto Project a secure, stable, yet adaptable industry standard. Cisco recently became a Platinum level member, joining existing platinum members Intel, Texas Instruments, Facebook, Arm, and Comcast.

The Yocto Project will be onsite at the Embedded Linux Conference Europe, October 28-31, 2019 in Lyon, France. Members of the Yocto Project community will participate in a variety of sessions, presentations and tutorials during the event. Additionally, the Yocto Project will host the first Yocto Project Summit on October 31 – November 1, 2019. The Yocto Project Summit, is a technical conference for engineers, open source technologists, students and academia. During the 2-day event, attendees will learn about the Yocto Project new release, development tools, features, and will be able to network with their industry peers, Yocto Project maintainers and experts. For more information and to register, visit here.

This is a lab session that will walk you through several exercises using Devtool.

Speakers:

Tim Orling, Sr. Linux Software Engineer, Intel Corporation

Chandana Kalluri, Xilinx

Manjukumar Harthikote Matha, Software Engineering Manager, Xilinx

Manju is a Software Engineering Manager at Xilinx managing open source initiatives within the company like Yocto and OpenAMP.  He is the maintainer for the meta layers from Xilinx and active contributor to the open source components that are used in the PetaLinux Tools software stack. He is a Yocto Project advisory board member and Techincal contact for OpenAMP project in Linaro community.

Abstract: There is a rising demand for embedded support of Blockchain and Distributed Ledger applications. In this talk I will present my recent work of integrating IOTA DLT into the OpenEmbedded space. I will present what has already been integrated into meta-iota, as well as the next steps. The meta-iota layer will soon be supported by IOTA Foundation’s Ecosystem Development Fund.

Speakers: Bernardo A. Rodrigues, Philipp Blum, IOTA Foundation

Bernardo Rodrigues works with Yocto/OpenEmbedded since 2017. He has BitBaked images for Automotive Road Traffic Control in Brazil and recently he used Yocto on an RCar H3 based platform for Advanced Driver-Assistance Systems (ADAS).

His work on the meta-iota OpenEmbedded layer received a warm reception from the IOTA Community, and he will receive incentive from the IOTA Foundation’s Ecosystem Development Fund to keep developing meta-iota.

Philipp Blum represents the IOTA Foundation as Developer Advocate of the Ecosystem team. He focuses on growing and developing an IoT developer community. Philipp lives in Berlin, Germany and has been in the technology sector for over 6 years. He has experience as a marketing developer for startups and wrote software to optimize Web- and TV-Advertising.

Abstract:

From-scratch builds, even using server grade machines (with 40+ cores) will take just under an hour to complete. Additionally this estimate is just for minimal, stripped down images;  Bigger images that bring up more than just core functionality and support things like web browsers/multimedia would take much longer (on the order of several hours).

Use of the sstate cache drastically cuts down on build times, especially for fresh projects. Xilinx makes full use of the sstate cache to speed up builds for its customers by hosting a comprehensive sstate cache (for all packages for different types of architectures) and allowing users to point their builds to this prebuilt and maintained sstate cache.

There are different ways of distributing the sstate. When building an esdk (An extensible software development kit), the sstate of all non-native components is packaged so that any build using the esdk will happen in the blink of an eye. However, when building an sdk from within another sdk, the sstate for the native components were missing , hence making the sdk build disproportionately long compared to regular builds. We introduced a patch into core that allows users to toggle the inclusion of nativesdk packages into the esdk by correctly handling sstate cache artifacts themselves as well as the corresponding signatures that are used to reference if anything has changed. With this change, a bigger esdk will be built, when required, that will skip rebuilding native components.

Speaker: : Jaewon Lee, Xilinx

Jaewon is a member of the Yocto Project team at Xilinx. He studied electrical engineering at Georgia Tech and went from focusing on hardware design to an embedded software position at Xilinx! He has been with Xilinx for two years. He is actively maintaining and contributing to Xilinx layers, and is eager to add more functionality to open source Yocto project.

Abstract:

The usage of Tegra, the CUDA-enabled system on a chip (SoC) series developed by NVIDIA, is increasing in embedded Linux devices for various industries requiring deep learning and artificial intelligence solutions. Often the Ubuntu-derived image provided by NVIDIA L4T and JetPack SDK isn’t flexible enough. Reliable high-quality industrial devices require a custom embedded Linux distribution for the exact needs of their complex operations. The Yocto Project, OpenEmbedded and meta-tegra BSP provide an excellent solution.

In this presentation, Leon will share his experience in customizing Poky, the reference distribution of the Yocto Project, for embedded devices with NVIDIA Tegra SoCs using OpenEmbedded build system and the BSP meta layer meta-tegra. Due to the limitations of the supported GCC version by latest CUDA versions, it is a challenge to make it work with the latest release of the Yocto Project. This presentation will reveal 3 ways for solving the problem by providing an appropriate GCC version through an external toolchain, porting GCC recipes to latest Yocto release or moving to an older Yocto release. Practical examples and testing scenarios based on NVIDIA Jetson development boards will be provided.

The presentation is appropriate for anyone with basic knowledge about the Yocto Project and OpenEmbedded. The provided information will help other software developers in the community to overcame faster and easier similar technical difficulties while using CUDA-enabled hardware.

Speaker: Leon Anavi, Konsulko

Leon Anavi is an open source enthusiast and a senior software engineer at Konsulko Group. He is an active contributor to various Yocto/OpenEmbedded meta layers, Automotive Grade Linux (AGL), Tizen any many other open source projects. His professional experience includes web and mobile application development for various platforms as well as porting and maintaining embedded Linux distributions to Raspberry Pi and devices with i.MX6, Rockchip and Allwinner (aka sunxi) SoC. Leon holds a masters in Information Technology from the Technical University Sofia. He is the author of the Tizen Cookbook printed by Packt Publishing. His previous speaking experience includes talks about open source software and hardware during events in San Francisco, Portland (OR), Hong Kong, Shanghai, Shenzhen, Brussels, Berlin, Bratislava, Edinburgh, Prague, Sofia and his hometown Plovdiv.

Abstract:

The Yocto Project is using Buildbot for continuous integration services.

AutoBuilder is a project that automates build tests and Quality Assurance (QA) upon a Buildbot configuration for the Yocto Project through metadata.

Buildbot is a software development continuous integration tool which automates the compile or test cycle required to validate changes to the project code base.

During this talk will be presented some case-study using CI techniques to strenghten the deployment of Linux embedded components using the Yocto Project.

Buildbot supports not just continuous-integration testing, but automation of complex build systems, application deployment, and management of sophisticated software-release processes.

When software development processes are automated, they are repeatable, reliable and can be run as frequently as available computing resources allow.

Automating the build and test process gives developers immediate feedback on their work. Tests can run on multiple platforms, ensuring that code changes made on one platform do not cause failures on other platforms.

Once a project is ready for use by users, it is either deployed (for hosted applications, such as web sites) or released (for packaged software such as desktop applications).

Automating deployment makes the process predictable and lowers the risk involved with each push. Changes can be deployed to a staging environment first, then deployed to production using exactly the same procedure, eliminating failures due to human error. Deployments can occur many times every day, with only small changes between each deployment.

Releasing packaged software, too, benefits from automation. The process can involve compiling and packaging on multiple platforms, signing builds, localizing strings, quality-assurance checks, and so on. When automated with a tool like Buildbot, all of this occurs repeatably and efficiently.

Speaker: Marco Cavallini, Koan Software

Open Source and Linux embedded evangelist since 1999 with the first StrongArm boards. Marco Cavallini is an OpenEmbedded member since 2009 and Yocto Advocate since 2012. He founded KOAN in 1996, an embedded software engineering company based in Italy, specialized in kernel development and training services for Linux embedded systems. He is a C/C++ programmer since the mid-80s. When not using computers, Marco is usually interested in mixing Physics with Philosophy.