Improvements to Buildroot maintenance tooling

From mid-April to end of August, Victor Huesca, a student from the University of Toulouse joined Bootlin’s team for a 3.5 months internship. His internship was focused on the Buildroot project, and Victor’s mission was to improve various aspect of the tooling around Buildroot to help in the maintenance of this build system. In this blog post, we will present the different improvements and features implemented by Victor during his internship. This internship was funded by Bootlin, and entirely focused on contributing to the Buildroot project.

Notifications of new upstream versions of packages

Buildroot has over 2400 packages for a wide variety of software components, and it is a challenge to keep all of those packages updated with the latest releases from the upstream developers. Buildroot has a nice statistics page with all its packages, and in early 2019, your author added support for querying the service to find the latest upstream version of each package. This allowed our statistics page to show the current version in Buildroot and the latest version available upstream for all Builroot packages.

Victor improved this by implementing e-mail notifications to Buildroot developers about their package having new upstream releases available. Indeed, Buildroot has a DEVELOPERS file which associates the name and e-mail of Buildroot contributors/developers with the packages they take care of. So, what Victor did is:

  • Extend the pkg-stats script, which generates the statistics page, to not only generate a HTML output, but also a JSON output. A JSON output is obviously a lot more usable by other tools. Victor also improved the efficiency of this script in several ways, especially by parallelizing the requests made to
  • Extend the daily-mail script, which until now was only sending autobuild results, to also send notifications about packages that are not up to date with their latest upstream version

The notifications are sent only once a week, both individually to the developers, and globally on the mailing list. They are grouped in a single e-mail with the existing autobuild results notifications, to minimize the amount of e-mails received by developers. You can see an example of such a notification in this e-mail, with a small excerpt below:

Packages having a newer version

             name              | found by |        link to        |   version    |   upstream   | orph?
                           4th |  DISTRO  | | 3.62.5       | 3625         |     
                        acpica |  DISTRO  | | 20190703     | 20190816     |     
                         acpid |  DISTRO  | | 2.0.30       | 2.0.32       | ORPH
                       acsccid |  DISTRO  | | 1.1.4        | 1.1.7        |     
            adwaita-icon-theme |  DISTRO  | | 3.22.0       | 3.33.92      |     
                       aespipe |  GUESS   | | 2.4d         | 2.4e         | ORPH
                 android-tools |  GUESS   | | 4.2.2+git... | 10.0.0_r2    |     
                      argparse |  GUESS   | | 0.7.0-1      | 1.0.10       |     
                         argus |  GUESS   | | 3.0.8        |      | ORPH
                     armadillo |  GUESS   | | 7.900.1      | 9.700.2      |     
                   at-spi2-atk |  GUESS   | | 2.26.2       | 2.33.92      |     
                  at-spi2-core |  GUESS   | | 2.28.0       | 2.33.92      |     
                         atkmm |  GUESS   | | 2.24.2       | 2.29.1       |     
                      automake |  DISTRO  | | 1.15.1       | 1.16.1       | ORPH

As part of this work, Victor also improved the matching of versions between the Buildroot package versions and the upstream versions. Indeed, for many packages, Buildroot used to use the full Git tag name as the version (for example v1.3), while removes any prefix and keeps only 1.3.

As of today, not all Buildroot packages match with a project known by, either because doesn’t know the project, or because the name is slightly different, but we are improving this progressively (the name mismatch can be handled by creating a mapping on, thanks to the concept of distribution they have).

The work of Victor has already proven to be very useful: a number of infrequent contributors suddenly started taking care of the packages they had contributed a long time ago and perhaps forgotten since then, which is very good.

Notifications of defconfig and runtime test failures

Buildroot provides a number of defconfig files, which are example Buildroot configuration for a wide range of hardware platforms (Raspberry Pi, BeagleBone, Qemu emulated machines, NXP or Microchip evaluation boards, and more). These defconfigs offers a very simple way for users to get a minimal Buildroot system up and running on those hardware platforms, making them a great starting point. Of course, to make them useful, they have to build properly, and we regularly build them using Gitlab CI to ensure they continue to build.

Buildroot also has runtime tests, which were initially introduced in the project by your author back in 2017. Those runtime tests are test cases that will each build a specific well-defined Buildroot configuration, boot it under Qemu, and verify that everything works properly. For example, the filesystem test cases will each make a Buildroot build with a specific filesystem image format selected, and boot the result under Qemu, to make sure that the filesystem image is correct and working. We also have a significant number of test cases for Perl or Python modules, which simply build the Perl or Python interpreter with a collection of modules, boot under Qemu, and verify that those modules can be loaded/imported. Just like the defconfigs, these runtime tests are already tested on a regular basis using Gitlab CI, to detect and fix any regression.

However, the results of those tests in Gitlab CI (and especially failures) were not notified to the Buildroot community in a meaningful way. This is where Victor filled in the gap, by adding the appropriate notifications.

He further extended the daily-mail script so that using the Gitlab CI API, the latest Gitlab CI pipelines for the Buildroot project are retrieved, the defconfig and runtime test failures are identified, and the appropriate Buildroot developers and contributors are notified. Indeed, just like packages are referenced in Buildroot’s DEVELOPERS file, the defconfigs and runtime tests are also referenced. The daily-mail script will notify individual developers about the defconfig and runtime tests they take care of, and it will also globally notify the mailing list about all defconfig and runtime test failures.

An example output, visible in this notification e-mail is:

Detail of defconfig failures

                        defconfig |                        link to the job                        | orph?
                amarula_a64_relic |  |      
               arcturus_ucls1012a |  |      
                        bananapro |  |      
                   beaglebone_qt5 |  | ORPH 
        engicam_imx6qdl_icore_qt5 |  |      
                 imx6-sabresd_qt5 |  |      
                       imx6ulpico |  |      
                        imx7dpico |  |      
                    licheepi_zero |  |      
               linksprite_pcduino |  |      
                    orangepi_lite |  |      
                   orangepi_lite2 |  |      
                 orangepi_pc_plus |  |      
                    orangepi_zero |  |      
              orangepi_zero_plus2 |  |      
                   pc_x86_64_bios |  |      
                    pc_x86_64_efi |  |      
               raspberrypi3_qt5we |  | ORPH 
                            warp7 |  |      
                        warpboard |  | ORPH 

Detail of runtime-test failures

             runtime-test |                        link to the job                        | orph?
...ystemSystemdRoIfupdown |  | ORPH 
...ystemSystemdRoNetworkd |  | ORPH 
...nitSystemSystemdRwFull |  | ORPH 
...ystemSystemdRwIfupdown |  | ORPH 
...ystemSystemdRwNetworkd |  | ORPH 
             TestSyslogNg |  | ORPH 

Overall, thanks to Victor’s work, a single e-mail now reports autobuilder failures, the need to update packages to a newer upstream versions, defconfig build failures and runtime tests failures. This is a really good improvement in the tooling of the Buildroot community!

Buildroot autobuilder search capabilities

Buildroot provides over 2400 packages, and many of them have configurable features and optional dependencies. This creates a massive amount of possible configuration combinations, making it impossible to test all of them. To make sure as many Buildroot configurations build properly, the project has been running for many years the Buildroot autobuilders. A number of build machines build random Buildroot configurations 24/7, and report their results to This helps tremendously the Buildroot developers and maintainers to detect the problematic packages and configurations.

For a long time, the allowed to filter build results by architecture, C library, failing package, and a few other criterias. Such filtering is very often useful to understand when a package started failing to build, and in which situations it fails to build. was also collecting in a database all the configuration symbols (the BR2_something symbols) for every Buildroot configuration that was built. However, the size of this database made any query excessively long, so we were not able to make use of it so far. This was annoying because it would sometimes be useful to ask could you tell me which configuration had BR2_PACKAGE_STRACE=y and built successfully ?.

That’s where Victor jumped in:

  • He improved the database by adding the appropriate indexes and found a reasonably efficient way to query the database when configuration symbols are involved
  • He added filtering per configuration symbol, which can be done using GET arguments on the main page:[BR2_PACKAGE_STRACE]=y will show the builds that had BR2_PACKAGE_STRACE=y and that ended successfully. Multiple symbols[name]=value arguments can be passed.
  • Since writing such queries by hand was a bit cumbersome, Victor also added a new search page.
Autobuild search page
Autobuild search page

This work will be very useful in the future to analyze build failures and understand better in which situations they are happening.


Victor’s internship has been very productive in improving the tooling used by the Buildroot community to maintain the project. All the work done by Victor has been merged, is in production, and is already showing some useful results.

Author: Thomas Petazzoni

Thomas Petazzoni is Bootlin's co-owner and CEO. Thomas joined Bootlin in 2008 as a kernel and embedded Linux engineer, became CTO in 2013, and co-owner/CEO in 2021. More details...

4 thoughts on “Improvements to Buildroot maintenance tooling”

  1. Hi Dear,
    I have problem with external toolchain;
    finally I have received the following error when I put the make linux-menuconfig command (I want to check this menu for eth driver)
    ubuntu@upc:~/buildroot-2021.02.5$ make linux-menuconfig
    BR_BINARIES_DIR=/home/ubuntu/buildroot-2021.02.5/output/images PKG_CONFIG_PATH=”” /usr/bin/make -j9 -C /home/ubuntu/buildroot-2021.02.5/output/build/linux-5.10.9 HOSTCC=”/usr/bin/gcc” HOSTCC=”/usr/bin/gcc -O2 -I/home/ubuntu/buildroot-2021.02.5/output/host/include -L/home/ubuntu/buildroot-2021.02.5/output/host/lib -Wl,-rpath,/home/ubuntu/buildroot-2021.02.5/output/host/lib” ARCH=arm INSTALL_MOD_PATH=/home/ubuntu/buildroot-2021.02.5/output/target CROSS_COMPILE=”/home/ubuntu/buildroot-2021.02.5/output/host/bin/arm-linux-gnueabihf-” DEPMOD=/home/ubuntu/buildroot-2021.02.5/output/host/sbin/depmod INSTALL_MOD_STRIP=1 HOSTCC=”/usr/bin/gcc” menuconfig
    scripts/Kconfig.include:39: compiler ‘/home/ubuntu/buildroot-2021.02.5/output/host/bin/arm-linux-gnueabihf-gcc’ not found
    scripts/kconfig/Makefile:29: recipe for target ‘menuconfig’ failed
    make[3]: *** [menuconfig] Error 1
    Makefile:602: recipe for target ‘menuconfig’ failed
    make[2]: *** [menuconfig] Error 2
    linux/ recipe for target ‘/home/ubuntu/buildroot-2021.02.5/output/build/linux-5.10.9/.kconfig_editor_menuconfig’ failed
    make[1]: *** [/home/ubuntu/buildroot-2021.02.5/output/build/linux-5.10.9/.kconfig_editor_menuconfig] Error 2
    Makefile:84: recipe for target ‘_all’ failed
    make: *** [_all] Error 2
    before this command I have done “make” successfully and the toolchain configuration is like that:
    Toolchain type (External toolchain) —> │ │
    │ │ *** Toolchain External Options *** │ │
    │ │ Toolchain (Custom toolchain) —> │ │
    │ │ Toolchain origin (Pre-installed toolchain) —> │ │
    │ │ (gcc-linaro) Toolchain path │ │
    │ │ (arm-linux-gnueabihf) Toolchain prefix │ │
    │ │ External toolchain gcc version (7.x) —> │ │
    │ │ External toolchain kernel headers series (4.10.x) —> │ │
    │ │ External toolchain C library (glibc/eglibc) —> │ │
    │ │ [*] Toolchain has SSP support? │ │
    │ │ [*] Toolchain has SSP strong support? │ │
    │ │ [*] Toolchain has RPC support? │ │
    │ │ [*] Toolchain has C++ support? │ │
    │ │ [ ] Toolchain has D support? │ │
    │ │ [ ] Toolchain has Fortran support? │ │
    │ │ [ ] Toolchain has OpenMP support? │ │
    │ │ [ ] Copy gdb server to the Target │ │
    │ │ *** Host GDB Options *** │ │
    │ │ [ ] Build cross gdb for the host │ │
    │ │ *** Toolchain Generic Options *** │ │
    │ │ [ ] Copy gconv libraries │ │
    │ │ () Extra toolchain libraries to be copied to target │ │
    │ │ [*] Enable MMU support │ │
    │ │ () Target Optimizations │ │
    │ │ () Target linker options │ │
    │ │ [ ] Register toolchain within Eclipse Buildroot plug-in

    When I checked the arm-linux-gnueabihf, I have received the following output, I have installed linaro gnueabihf toolchain and saved it as “gcc-linaro”
    ubuntu@upc:~/buildroot-2021.02.5$ find . -name *linux-gnueabi*

    Could you guide me at that point ?
    I want to add eth interface to images and arm-linux-gnueabihf external toolchain,
    Tahnk you

    1. I am not sure why you are picking this particular blog post to get support on Buildroot. You should rather use StackOverflow, or the Buildroot bug tracker, or the Buildroot mailing list, or the Buildroot IRC channel.

      Anyway, the issue is most likely that you changed the toolchain in your Buildroot configuration, without doing a full rebuild of Buildroot. Please read carefully

Leave a Reply