Embedded Linux News

Right before the Embedded Linux Conference Europe, the Buildroot project organized its Developer Days in Barcelona on Saturday November 3rd and Sunday November 4th.

Thanks to the sponsoring of Fluendo, the meeting took place in the nice Hotel Grumps in downtown Barcelona, and thanks to the sponsoring of Synopsys, the participants enjoyed a free dinner as social event on Saturday evening.

In total, 10 participants took part to the meeting: Peter Korsgaard (from Barco), the Buildroot maintainer, and a number of active developers and contributors: Arnout Vandecappelle (from Mind), Maxime Ripard (from Free Electrons), Luca Ceresoli, Samuel Martin, Simon Dawson, Mischa Jonker (from Synopsys), Maxime Hadjinlian, a surprise participant from PCTV, and your editor, Thomas Petazzoni.

Arnout Vandecappelle wrote a detailed report of the various topics discussed during the meeting, highlighting the action points to be taken. Below a slightly more detailed description for some of the most complicated topics:

• A series of patches from François Perrad adding a package for the full blown Perl interpreter has been around for sometime but hadn’t been merged so far. The issue was the cpanminus package, which is a minimal CPAN client that allows to easily download and install Perl modules from CPAN. While working nicely, this package does the downloading, dependency resolution on its own, which means that it completely defeats the download infrastructure of Buildroot (which allows to keep a local cache of packages, do off-line builds, exhaustively list all tarballs and files needed to do an off-line build) and the license infrastructure of Buildroot (which allows to automatically generate a detailed licensing report for all components of the embedded Linux system being generated). However, nobody really wanted to see hundreds of new packages for small Perl modules and handle the related dependency nightmare. So it was decided that for now, cpanminus would be integrated as is, with the addition of big warnings that it doesn’t integrate properly with the download and licensing infrastructure of Buildroot.
• A series of patches from Yann E. Morin (also the maintainer of crosstool-NG) adds support to build Qemu for the target and a big number of libraries needed to use Qemu as an environment to run virtual machines. Your editor raised the concern that generating Linux systems for virtual machine environments was a bit outside of the scope of Buildroot, and that it could lead the project to loose its focus. However, everyone else seemed to agree that those were just additional packages not causing any additional complexity on the core of Buildroot, so there is no real reason to refuse them. So it is very likely that Yann’s set of patches will get merged in the near future.
• Another topic of discussion was the support for the toolchain on the target. Buildroot is inherently a cross-compilation tool: it builds everything for the target architecture using a cross-compiler on the build machine. However, Buildroot has had support to generate a native toolchain on the target, for the people interested in building programs directly on the target. Unfortunately, this support has been broken for a long time, and none of the core developers and regular contributors care about this. Moreover, it leads newcomers into believing that this is what they need to build their programs, while the Buildroot logic would rather be to use the cross-compiler. So we decided to deprecate of the support of the native toolchain, with the idea of removing it in a few release cycles after making sure that there are really no valid use cases of this feature from our users.
• A big topic of discussion related to a very specific issue that Buildroot has in its usage of the kernel kconfig code to handle the menuconfig interface and all the configuration options. The kconfig language has the unfortunate language that if option A select option B, then option B gets enabled even if it has unmet dependencies (expressed using depends on). For now, we solve this problem by duplicating the depends on that option B has into option A. It works fine, but is very painful to maintain: for example the libffi package is not available on the Microblaze architecture, so we have a depends on !BR2_microblaze. But this libffi package is selected by many things like glib2 or python, and themselves are in turn selected by many other things like dbus, gtk2 and more. Having to duplicate this depends on !BR2_microblaze all on the reverse dependencies of libffi is not nice. The ideal solution here would be to fix kconfig, but the kconfig code base is not really nice, and we also prefer to remain in sync with the kconfig code base from the kernel. So we discussed the proposal from Yann Morin that consists in adding more kconfig options to reflect the dependencies of the different packages. It seems to work quite well, except for the comments that we currently show when a toolchain option is missing to access a component: for example when the toolchain doesn’t have C++ support, instead of silently hiding Qt, we show Qt needs C++ support in your toolchain. Removing all comments doesn’t seem like a good solution as our users would no longer notice the big number of packages that are hidden due to missing dependencies. A number of options have been discussed, but none really seemed to satisfy everybody, so the problem remains open.
• Another topic that has been discussed is supporting multiple versions of the same package, such as python2 and python3, or gtk2 and gtk3, and also supporting packages providing the same functionality, such as jpeg and jpeg-turbo, or multiple implementations of OpenGL. For the first case, it has been decided that we need to discuss on a case-by-case basis how to handle such cases. For the second case, a new type of virtual packages will be used.

Many other topics have been discussed: RPC support, autobuilders, community organization, licensing infrastructure, out-of-tree builds, API changes, and more. See Arnout’s report for details about those topics.

In addition to the discussion, a lot of hacking and merging took place during the week-end. Amongst the things done during the week-end:

• Support for the AArch64 architecture was added
• The Perl series of patches, including the Perl interpreter have been merged, as well as cpanminus
• The qextserialport package was added
• A number of Netfilter related packages were upgraded or added.
• Improvements to the licensing infrastructure that allow to describe packages having a proprietary license but that can be redistributed: it splits the per-package license string from the per-package boolean that says whether it can be redistributed or not.
• Support for libtirpc was added, and a big refactoring of how the RPC support is handled in Buildroot. This allowed to integrate the support for external glibc toolchains that don’t have built-in RPC support, such as the Sourcery CodeBench 2012.03 x86 toolchain.
• A big number of build issues have been fixed during the week-end (but many more were also introduced due to the big number of new packages).
• Maxime Ripard started working on the package for Python 3, which got ready and merged during the week after the meeting.

All in all, all the participants were apparently really happy about the meeting and the new two days format which provided more time for hacking.

At the end of the meeting, the participants also agreed on a date for the next meeting: it will take place on February 2013, Monday 4th and Tuesday 5th in Brussels, Belgium, right after the FOSDEM conference. The first day will be mostly dedicated to discussion, the second day mainly to hacking. This will allow people being able to attend only one day to participate to the most important discussions.