What does ‘LEB’ stand for?
Linaro Engineering Build
What is a LEB/Linaro Engineering Build?
A full system build of popular linux open-source products that come with Linaro improvements pre-integrated; currently products supported by the LEB program are Android, OpenEmbedded and Ubuntu.
What hardware is supported by LEBs?
LEBs are only made available for SoCs produced by Linaro Members; typically we target the official (low cost) development boards for the most recent, publicly available member SoC.
How frequently are LEBs released?
Linaro platform produces monthly LEB releases.
When are LEBs released?
LEBs are getting released on the last Thursday of the month.
Is Linaro a distribution?
Linaro neither is, nor aims to be a distribution.
How is the LEB different to a distribution?
Linaro provides engineering builds that come with significantly different priorities and requirements than the product and end-user focused distribution business. As such we heavily focus on middleware, kernel and hardware enablement topics, but deprioritize typical distribution specific domains such as providing safe upgrade paths, security or stability updates. Also we don’t provide end-user support and we are not aiming to build an end-user community around our LEBs.
Why do LEBs exist in first place?
- One motivation of Engineering Builds is to provide a common integration target for all Linaro engineering that allows efficient development and full system validation of Linaro work facing most of the requirements and code paths as found in real products.
- Due to the relatively high fixed cost of maintaining an efficient full system integration target that can be used by whole of Linaro engineering, we found it useful to go one step further and provide a polished and validated build for Linaro member boards on a monthly cadence.
What is the primary audience for LEBs?
Internal Linaro engineering teams, ARM enthusiasts, OEMs that want to start with a very recent BSP, ARM developers.
What product baselines are currently tracked as part of the LEB program?
We currently produce LEBs for latest publicly available Android, OpenEmbedded and Ubuntu
What are the ingredients of an LEB?
- We track all Linaro work that gets integrated and make it transparently available and individually consumable alongside the LEB release
- LEBs focus on integrating landing teams and working groups output; those are typically developed against the upstream trunk. Hence, you will find very recent/bleeding-edge kernel versions and other optimizations in user space in the LEBs.
- If you need recent hardware enablement on an old kernel version for your product, the LEB is the wrong place to look for it.
What are the enablement requirements for an LEB?
In general, we require all enablement needed for delivering a basic user experience. This includes primary enablement for user interaction devices such as touch screen, USB mouse and keyboard as well as networking, primary monitor, and graphics hardware acceleration support. On top, we aim to not release an LEB that significantly regresses the hardware enablement and stability delivered in the best LEB release so far. The goal therefore, is that LEBs always improve from month to month.
LEBs are trunk focused builds? What does that mean?
Linaro focuses on the future. Therefore we focus on stabilizing product components like the Linux kernel before they hit product requirements. Also, all Linaro work is heading upstream. The only viable way to develop and maintain changes staged for upstreaming is to keep the code base fresh, very close to the upstream trunk.
What happens if the “tip” LEB for my platform does not meet the LEB requirements at the end of the month?
If the monthly validation shows that there are significant regressions or that a required feature such as hardware accelerated graphics is broken, we won’t release a fresh LEB, but rather continue to ship the last known good LEB. Development efforts continue to focus on tip with the goal to release a new LEB that meets the requirements as soon as possible.
Are LEBs of product quality?
An LEB cannot be of product quality as it is not driven by real product requirements; instead we focus on the specific quality properties needed to fulfill its primary purpose of being the development and integration target for all Linaro engineering.
What is done to validate the LEB?
Linaro Platform team validates all monthly LEBs using a semi-automated sign off plan; the plan and the results are published alongside the release
The results can be found when following the “Status” link next to the download entry on the www.linaro.org/downloadspage. Details on the tests referenced in the spreadsheet can be found at
Does Linaro provide end-user support for LEBs?
The short answer is no. The longer answer is that we are usually happy to discuss issues seen by ARM enthusiast users that are providing good input and actively help debug issues. However, don’t expect us to fix issues that are not related to our focus areas: kernel, middleware and hardware enablement. And even there, we don’t provide any guarantees that your individual pet bug will get fixed in a finite amount of time.
Are there any other support options for LEBs?
Linaro Member Services offers various services that help Linaro members leverage LEBs or parts of LEBs or individual Linaro components in your products. If you are a member and are thinking about using Linaro output as ingredients for your product development you should definitely get in touch with Member Services.
Is see that testing around enablement and Working Group topics has a high priority on your list. Isn’t this leaving out lot’s of testing we would need to do for a product?
The majority of issues we find during our monthly release validation are related to hardware enablement. We anticipate that the main challenges that cause this will be solved sooner rather than later and in turn we anticipate that we will get to a point where distributable and working hardware enablement can be taken more for granted. Once we get closer to that we will probably add more priority to general system stability and stress testing.
I am not a member, but want to participate in the LEB program. Is that possible?
No, the LEB program is an exclusive service offered to Linaro Members.
I am a member, but I don’t have a Landing Team. Can I get an LEB for my board?
Unless your board is very well supported in the mainline kernel, there is no sustainable way we can produce an LEB for your board. The results would be underwhelming. Please talk to your Member Services contact to explore options.
Should I start building my Android Product from the LEB?
We believe that starting with the Android LEB will give you a noticeable head start if you use one of our supported member SoCs and if you want to make use of any Linaro optimizations including the latest Linaro toolchain.
Can I just use component X from the LEB in my products?
All integrated components and improvements are made available as individual components that can be downloaded and consumed individually. Support for individual components is not provided through the standard LEB program, but for Linaro members there are options for support offered through Member Services. See next question.
I have used component Y from your most recent Android LEB. Now I see random crashes. Can you help me?
The LEB program focuses on providing full system integrations stack for developing, validating and staging Linaro optimizations. Since interactions of software components can be quite complex, we cannot provide support for your individual version mix through our standard LEB program. However, there are services offered to Linaro members by Member Services that might help you. Let’s discuss your case!
How do you provide a head start for using the Linaro toolchain on Android?
- Our Android LEB comes with improvements that enable you to make use of bleeding edge toolchain optimizations as present in Linaro GCC releases.
- The Linaro Android team provides a binary toolchain build for the most recent Linaro toolchain releases. By using the binary toolchain with the LEB platform code combination you will free resources to focus on improving the actual Android experience instead of toolchain integration issues.
- For the convenience of product builders that want to make use of Linaro’s toolchain without basing their Android code base off our LEB platform, we release distinct patchset for the Android platform that enables product builders to adopt Linaro’s toolchain independent of other Linaro improvements.
I am not happy with the amount and type of tests run during LEB validation, what can I do?
- Please support the Platform QA services team to extend automation and manual test plans used for continuous validation; this will over time ensure that the quality converges closer to what you expect.
- Sponsor general and board specific test automation (talk to your Member Services Project Manager and we will setup a project to integrate your tests) …