Buildroot:DeveloperDaysELCE2018

Buildroot Developers Meeting, 20-21 October 2018, Edinburgh

The Buildroot Developers meeting is a 2-day event for Buildroot developers and contributors. It allows Buildroot developers and contributors to discuss the hot topics in the Buildroot development, work on patches, and generally meet each other, facilitating further online discussions. Attending the event is free, after registration.

Location and date

The next Buildroot Developers meeting will take place on October 20th and 21st 2018 in Edinburgh, right before the Embedded Linux Conference Europe 2018. The meeting will take place in a meeting room whose location is communicated only to the registered participants. It is located close to the Edinburg International Conference Center.

Sponsors

We would like to thank our sponsors:

Rockwell Collins delivers innovate aviation and high-integrity solutions that transform commercial and government customers' futures worldwide. Rockwell Collins sponsors a dinner this year for participants of the meeting.
Mind is the Embedded Software division of Essensium, which provides consultancy and services specifically in the field of Linux and Open Source SW for Embedded Systems. Mind has financially contributed to the Buildroot Association, which covers the cost of organizing this meeting.
Amarula Solutions. Amarula Solutions has financially contributed to the Buildroot Association, which covers the cost of organizing this meeting.
Tk Open Systems. Tk Open Systems has financially contributed to the Buildroot Association, which covers the cost of organizing this meeting.
Bootlin. Bootlin has financially contributed to the Buildroot Association, which covers the cost of organizing this meeting.
Logilin. Logilin has financially contributed to the Buildroot Association, which covers the cost of organizing this meeting.

See also our sponsors page.

Please contact Thomas Petazzoni (thomas.petazzoni@bootlin.com) if you would like to sponsor the Buildroot Developers meeting.

Participants

1. Thomas Petazzoni
2. Matt Weber
3. Peter Korsgaard
4. Luca Ceresoli (Sunday only)
5. Trevor Woerner (Saturday only)
6. Arnout Vandecappelle
7. Mark Corbin
8. Romain Naour
9. Yann E. MORIN
10. Alexey Brodkin (Sunday only)

Meeting report

Top-level parallel build

• Thomas has a private autobuilder that builds his PPS branch. Things fail dramatically on that branch.
  • For example, Qt5 hardcodes paths in the qmake files, with the effect that by default things get installed in qt5base's staging dir. sed'ing the Makefiles doesn't work either because they get re-generated in some cases.
• Proposal is to make the PPS conditional and merge it, so more people than just Thomas can start testing it.
• Note that in PPS, it is still OK for one package to access the per-package staging directory of another package.

Reproducible builds

• Turn on by default?
• It's currently not really reproducible anyway. We should add some test infra to make sure that it really is reproducible. What other projects (e.g. OpenWRT) do is just do the build twice (same machine) and compare the binaries.
• Proposal: after a successful build, build the same config again in the same location (only variation is time) and diffoscope the results. diffoscope output is uploaded to autobuild server and build is marked a failure. Ideally, the package is identified by matching the diffoscope output with packages-file-list.
  • Also randomly turn on reproducible (genrandconfig update).
  • Ideal project for a GSoC student.

More testing

• Run an autobuilder in a docker environment without write access to the home dir, this would detect the recent ncurses problem writing to homedir.
  • Maybe interesting to use a filesystem namespace per instance with the autobuild-run script managing the setup/launch what the sandbox looks like (R/O mount in pieces we shouldn't touch) - ( bubblewrap looks like it might work, Matt is currently testing with a autobuilder being called by a sandbox script)
• More randomisation, e.g. of hardening options.
• Add option to specify a repository+branch as part of the Autobuilder
  • Helps to regression patch series in progress which need feedback
  • Should send mails to just the "owner" of that repo instead of to the list + package maintainers
  • Ideally the results are still included on autobuild.buildroot.org but separated from the master results.
    • Requires a php page update for results to have repo noted and hashes linked to the right repository
    • This will increase the noise of number of packages, suggest fixing the next page context bug where any filtering is dropped.
• Arnout will set up a gitlab runner on a dedicated machine; Yann will start one on the same machine as its autobuilder. This will make the gitlab-ci results a bit more stable (today too many of the results are timeouts). Also, trigger the runtime tests explicitly instead of on every commit (there are a lot of runtime tests now, too many to run on every commit). Arnout has sent patches doing that.
  • Test scenarios
    • Defconfigs - investigate updating the "only" section to just have "schedules", then add a gitlab pipeline scheduled execution trigger once a day
    • Runtime tests - add a "only" section like Defconfigs
    • check-package/flake8/DEVELOPER - still run per commit
• Mark will add RISC-V 64-bit to the autobuilder configuration and monitor the results.

Hardening wrapper migration

• Patch series looks OK now.
• Add a script in Buildroot that checks hardening
  • Config option to enable the check, defaults to no, forces to yes in autobuilders
  • Script is called after every package install so package can be identified. Alternatively, detect the failing package at the end of the build.
    • End of build check will need to use reproducible hook to find the affected package to show the correct package.
    • Create new autobuilder result reason
  • Black list files at a per pkg level

Link-Time Optimization support (LTO) (Alexey)

Toolchain should describe if it supports LTO or not.

A global option for LTO would be nice, but some packages will probably break - possibly at runtime. Still, we can do it.

S01logging approach updates

Plan to apply adjusted version of existing patchset and then refactor file naming

Patchwork review

A number of older series have been reviewed and applied (or rejected), but not as much as we would have liked.

Download of extra downloads which have the same filename(different path) and need a unique destination name

Specific package this was required for is eventually openjdk

• For this package one option was to add the mecurial download caching
• Look at an approach to take the *\_EXTRA\_DOWNLOADS and adjust how it's used, i.e., add a optional separator to provide the destination name

Buildroot association

Report of the Buildroot Association general assembly can be found in the br-association github repository.

Points not discussed

The following points were on the agenda, but not discussed.

• Security Assessment Common Product Enumeration (CPE) patches for reporting and maintenance (M. Weber)
  • v7 changes:
    • Added documentation of how to use the make target and check the state of CPE string correctness
    • Added check for glibc library version and if external, add a glibc entry
    • Generates the XML update files required for CPE string update/corrections.
• Gobject Introspection (Adam, Yann)
• Remove old gcc version (4.9, 5) ?
• Use the latest gdb version by default ?
• Add the ability to create containers in Buildroot (light containers)
  • to use a method that call Buildroot inside another Buildroot. (Christian Steward had a similar concept with SkiffOS
  • Would be good to have a runtime test covering a Buildroot container host env and as a container