Buildroot Developers meeting report

The Buildroot project has had its developers meeting on Monday and Tuesday earlier this week in Brussels, right after the FOSDEM. Google kindly offered to host the event, which took place in the Brussels offices of the company. Seven persons participated to the meeting: Peter Korsgaard (Buildroot maintainer), Arnout Vandecappelle, Samuel Martin, Thomas De Schampheleire, Dimitrios Siganos, and your editor, Thomas Petazzoni.

Five of the seven participants of the Buildroot Developers Meeting. From left to right: Samuel Martin, Arnout Vandecappelle, Thomas Petazzoni, Thomas de Schampheleire, Peter Korsgaard.

During the entire event, notes have been taken to keep track of the discussion and decisions taken, those notes are now available on the Wiki page of the event. Amongst the topics discussed:

• Addition of the support for post-image scripts, which would be executed after the root filesystem images are created, to allow project-specific customizations.
• Discussion on how to better guide Buildroot users as to what are the best practices to use this tool. The participants agreed to improve the Buildroot manual by describing a few use cases to help new users to organize their Buildroot-based projects.
• How to improve Buildroot when used during application/system development and not only as an integration platform. Specifically, the patch series that builds each package out-of-tree, making it easier to work with custom source trees has been discussed, and the general principle accepted.
• Arnout wondered if it would make sense to maintain stable, long-term releases. However, it seemed to most of the participants that this would require too much work for the project for now.
• There was also a wider discussion about how the project is doing. The consensus seems to be that the project is doing well: the number of contributors increases, and the number of users is apparently important. However, two potential threats were discussed. The first is the existence of an increasing number of Buildroot forks that do not contribute back their changes upstream. This means that the main project misses contributors, and those forks are not generally very well-maintained over the long run, giving a poor reputation to the project. The second threat discussed was the increasing size of flash and storage used in embedded systems, making tools like Buildroot, tailored for small embedded systems, less useful compared to binary distributions like Emdebian. However, many of the participants felt that Buildroot is not only about the size of the generated system, but also about its simplicity and therefore the amount of control it brings to embedded Linux developers.
• Some big directions for the projects were discussed. The first important direction is that Buildroot needs to have more packages for the SoC-specific libraries used for 3D acceleration or video encoding/decoding. Those, general proprietary libraries, are often difficult to package, but are necessary to make Buildroot useful for a number of platforms. The second important direction was the interaction with the Crosstool-NG toolchain generator, and whether and how it would be possible to use it as the default backend for building toolchains in Buildroot. A number of problems remain to be solved, but the Crosstool-NG maintainer, Yann E. Morin, has asked to give another release cycle to find solutions to the problems discussed.
• Some discussion has taken place on how to handle the make targets that allow to configure the Linux kernel, Busybox or uClibc from Buildroot (make linux-menuconfig, make busybox-menuconfig, etc.), and how to keep the modified configuration. After much discussion, an agreement has been found on how to handle this.
• The problem of systemd and udev has been discussed. Buildroot is currently stuck with an old version of systemd and udev, because the project wants to be able to offer udev-based systems that don’t use systemd. Unfortunately, the modern version of systemd directly integrate udev, and it is not possible to build the latter without building the former, bringing D-Bus as a dependency. Investigating the eudev fork was discussing, but relying on a forked version of udev may be causing compatibility issues in the future.
• The removal of the support for development files and toolchain on the target has been discussed. This feature (which allows to install a compiler, headers and so on on the target) has been deprecated since the last release. However, participants generally felt we should give a little bit more time for Buildroot users to react on this, and therefore the feature will not be removed for now.
• The problem of kconfig select statement bypassing the depends on statements of the selected package has again been discussed at length, as during the previous meeting. Two solutions were proposed: either use an upper-level language on top of kconfig, which would be compiled into kconfig code having the right dependencies. Not many participants liked this idea, because it is moving away from its simplicity (“the project is based only on well-known tools and languages: kconfig and make”). The other solution was to add manually more options to handle this dependency problem (the so-called “AVAILABLE” proposal from Yann E. Morin), but unfortunately it didn’t solve the problem of the kconfig comments shown in Buildroot menuconfig when a package is not available for some reason. Participants felt these comments are really needed to let users know that a package exists in Buildroot, but that it isn’t available due to a missing toolchain feature. In the end, participants agreed that the only reasonable solution for now is to keep adding the needed depends on statements manually on all the reverse dependencies of a package having depends on statements.
• A number of other, smaller topics have been discussed and are reported on the Wiki page.

In addition to these discussions, the Buildroot developers also did some patch triaging in the project patchwork, taking decisions on a number of long-waiting patches.

All in all, the participants felt the meeting was very productive and that two days were a good duration for such a meeting, giving enough time for discussion. As it appears now to be a tradition, it is assumed that the next Buildroot meeting will next place near to the upcoming Embedded Linux Conference Europe.