Difference between revisions of "Buildroot:DeveloperDaysELCE2014"

From eLinux.org
Jump to: navigation, search
(Patchwork clean-up)
(Patchwork clean-up)
Line 233: Line 233:
* [http://patchwork.ozlabs.org/patch/362034/ LTO]: Just enable lto in the toolchain but leave it up to packages to make use of it. I.e., build gold but keep ld as the default.
* [http://patchwork.ozlabs.org/patch/362034/ LTO]: Just enable lto in the toolchain but leave it up to packages to make use of it. I.e., build gold but keep ld as the default.
* [http://patchwork.ozlabs.org/patch/364983/ libssh2 build failure]: Alternative suggested by Arnout, should be implemented and tested.
* [http://patchwork.ozlabs.org/patch/364983/ libssh2 build failure]: Alternative suggested by Arnout, should be implemented and tested.
* [http://patchwork.ozlabs.org/patch/348364/], rejected, Thomas mails the submitter
* [http://patchwork.ozlabs.org/patch/348364/], rejected, Thomas mails the submitter. (Thomas: done on November, 1st)
* [http://patchwork.ozlabs.org/patch/366435/], rejected, Thomas mails the submitter
* [http://patchwork.ozlabs.org/patch/366435/], rejected, Thomas mails the submitter. (Thomas: done on November, 1st)
* [http://patchwork.ozlabs.org/patch/374715/], rejected, Peter mails the submitter
* [http://patchwork.ozlabs.org/patch/374715/], rejected, Peter mails the submitter

Revision as of 14:32, 1 November 2014

Buildroot Developers Meeting, 11-12 October 2014, Düsseldorf, Germany

What is Buildroot ?

Buildroot is a set of Makefiles and patches that makes it easy to generate a complete embedded Linux system. Buildroot can generate any or all of a cross-compilation toolchain, a root filesystem, a kernel image and a bootloader image. Buildroot is useful mainly for people working with small or embedded systems, using various CPU architectures (x86, ARM, MIPS, PowerPC, etc.): it automates the building process of your embedded system and eases the cross-compilation process.

Location and date

The Buildroot community is organizing a meeting on Saturday 11th and Sunday 12th October 2014 in Düsseldorf, for Buildroot developers and contributors. This meeting is a mixture of discussion and hacking session around the Buildroot project. This meeting takes place right before the Embedded Linux Conference Europe and many other conferences in Düsseldorf, in order to make it easy for participants to attend both events.

The location is Niemandsland, Heerstraße 19 in Düsseldorf.


  • Saturday, start at 9 AM. End late in the evening/night.
  • Sunday, start at 9 AM, finish at 7 PM.


We would like to thank Mind, which is sponsoring this event in Düsseldorf. 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.

See also our sponsors page.



At the last developer days at Fosdem 2014, we did more hacking than usual, and this was considered a good improvement by most attendees. Even though discussion is really important too, we should take care not to over-discuss and engage in lengthy-but-not-really-efficient discussions.

A possible format to handle this is to have hacking going on from the start already, and let any discussion take place at the same time. Attendees interested in the discussion can join in, and others can continue hacking.

A variant of this is to have interleaving of a discussion and hacking session, but time-boxing is likely needed.

Discussion topics and report

Look-back to action points from previous developer days at Fosdem 2014

Is everything that was decided done? What remains?

  • BR2_PREFER_STATIC_LIB refactoring. The point is to clarify BR2_PREFER_STATIC_LIB, and separate three cases: static only, shared+static, shared only. Thomas P. was supposed to work on this, but nothing happened.
  • Hashes of download. This has been implemented by Yann, and merged, and more and more packages are gaining hash files.
    • Nice feature addition: add to pkgstats script if a package has hashes.
    • We should probably have a policy about which hashes to use. Yann will write an update to the manual.
  • SystemV/systemd init scripts. The idea was to do automatic installation of init scripts / service files located in package/<foo>/.
    • Maxime Hadjinlian said he would work on this, but not much happened.
    • On a related note, there is a need to separate the skeleton to not avoid Busybox-related init scripts in a pure systemd configuration.
    • Two things to do:
      1. Remove /etc/init.d from default skeleton, and move to its own package which is selected by busybox and sysvinit.
      2. Remove the need to have a variable in the package, just rely on a file being present in the package directory. Maxime would like to still keep the possibility of the variable
  • Clarification of the meaning of Acked-by/Reviewed-by tag in the Buildroot manual.
    • This has been done by Thomas DS.
  • Evaluation of the patch acceptance process.
    • The idea of a statistic of the list of pending patches in patchwork has not been fully implemented: Arnout has proposed a script, but it has never been converted into a cronjob to provide publicly visible statistics.
    • Manual evaluation shows that it fluctuates between 200 and 350 open patches, so maybe these statistics don't bring much.
    • Regarding Thomas P. taking over the commit access when Peter is away, this is happening more and more frequently.
  • Autouilder wishlist:
    • Run-time tests. Nothing has been done, since we had no GSoC to make progress on this.
      • We could consider the lava project from Linaro, but it doesn't look like it would bring a lot of benefit.
      • Another consideration is that we would need to cross-build additional test software.
    • Expand the number of autobuild machines:
      • done, thanks to the autobuild-run script.
      • Nathaniel Roach and Richard Braun are participating to the testing effort.
      • Peter has added more machines.
      • We now have ~200-230 builds per day, up from ~100 builds per day.
      • Maxime could add an autobuilder instance, but he would only be able to do small builds. The number of packages is currently between 1 and 35%, and it's the same for all autobuilder instances. ThomasP. would like to keep it the same, otherwise the statistics could be skewed by the smaller instance (more successful builds than "normal").
    • Maxime: shouldn't the script be split up, so it's easier to read?
      • ThomasP: now it's a single script which you can wget and run, which makes it really trivial to set up an autobuilder instance.
    • There should be a retry mechanism when submitting build results, in case there's a network problem. Currently the autobuilder script just crashes.
    • The dependencies check should be done in the autobuilder script, so you don't have to run it a couple of times to find out which dependencies are missing.
    • Click on a package and see the last failures of that package:
      • this has been implemented.
    • Expose read-only SQL queries: not done, maybe a bit difficult security wise.
      • Patches welcome!
  • Genimages. No progress has been made on that front.
    • Yann: if we want to split the filesystem into partitions, we also have to update /etc/fstab, which has to be done before generating the rootfs.
    • Maybe the first step is to provide the tools that are needed to create a partitioned image, but without a config file or something like that - let the user write an integration script.
    • Actually, we have those tools already, but they're not very accessible.
    • Yann will add something in the manual that explains how to use the existing tools with some examples for different platforms.
    • It would also be nice to make board-specific scripts that use the genimages.
  • How to handle the uClibc problem.
    • Recently, we've had less problems caused specifically by uClibc feature patches.
    • uClibc-ng has appeared, which is giving some hope of improvement.
      • uClibc-ng has not been integrated in buildroot. The patch that was submitted by Waldemar was not integrated because it created a completely parallel libc while we really want to make it a variant of uClibc.
      • Anyway, uClibc-ng doesn't really solve our problem (yet) because it's the external toolchains using a very old and buggy uClibc release that are biting us.
    • The only recent problem we had was valgrind on PowerPC. Gustavo has submitted a patch that fixes it in uClibc, but that doesn't help when using external toolchains. The patch could be ported to valgrind itself though because it just adds some #defines and typedefs - but Gustavo is probably not going to do it.
  • Website and branding.
    • A new http://buildroot.org has been put online, thanks to the work done by Maxime Hadjinlian.
    • ThomasP will add a 'Users' page to the website, to show some companies that use buildroot in their products.
  • Google Summer of Code
    • One student (Hadrien Boutteville) participated. Unfortunately, it didn't work very well, and not many patches have been contributed.
    • Lesson learnt: the student should work in a work environment. At least, if it looks like s/he is not sufficiently motivated to be working from home.
    • Maybe the scope of the project was too fuzzy.
    • We should go for GSoC again next year, but of course we need to find people who are willing to mentor. Also, we should get more students interested in working with us. Then we can actually choose between the candidates. A technical test (e.g. adding some package) would help to evaluate motivation and both technical and communication skills.
    • To make the GSoC thing more known, we can:
      • Put something on the website.
      • Contact a student organisation at a university, cfr. ROSEDU
    • One issue with GSoC (but it goes beyond it) is that we don't have a legal entity. This makes it fairly difficult for us to receive money - for instance GSoC gives 500 euro to buy hardware, but we never collected it because of all the paperwork.
      • We could start our own non-profit, in France it's really trivial to do that. But of course that does mean paperwork, although it looks like it's not so much. The most tedious part is to open a bank account.
      • Something to investigate before February!
  • Evaluation of BR2_EXTERNAL.
    • Not sure exactly what was needed here.
    • Jeremy Rosen was supposed to submit a patch, but I'm not sure if it happened, or even if something needs to happen.
  • State of major patch sets
    • Systemd/udev support. Has been merged.
    • Perl package infra. Has been merged.
    • SELinux. Still not merged, but not really pushed actively anymore. Matthew Weber will repost this in November.
    • libdrm/mesa3d updates. A lot of things happened in this area, with now a clear owner/maintainer of this package (Bernd).
    • 'target' defconfigs vs. 'development' configs. This was supposed to be an addition to the Buildroot manual, but it never happened. It's not very important.
    • Python packages: depends vs .select. Conclusion: we change the handling of optional python bindings: instead of selecting them automatically when python is enabled, we add explicit config symbols for them. ThomasDS will update the patches accordingly.
      • ThomasDS is still going to do it.
    • pkgparentdir removal. Has been done.

Patch naming

Current convention is package-number-description.patch, but a proposal was made on the list to simplify this to number-description.patch. Go or no-go? Everybody agrees that whatever git does is good, so it's a GO!

Side-track: we should have in a manual a description of the things that should be checked before submitting a patch, e.g. which external toolchains to test it with. Just take one of the mails that ThomasP sends out regularly to ask for this. Later on we could create a script to automate that, if necessary.

State of legal-info infrastructure, improvements to be made?

  • External toolchain legal-info would be nice, but difficult (cfr. discussion on the list). But the value is a bit limited because you anyway need to manually vet the toolchain, because it's so complicated (some things which are installed on the target, some which are not; different license for libgcc vs. gcc, ...).
    • If we do want to implement it, we could put in the toolchain-external.mk for every toolchain a POST_LEGAL_INFO_HOOKS thingy that calls the legal-info macro for each component. Still a bit complicated.
    • Something that would work is to add source URLs for the external toolchains. We'll need toadd a FOO_ACTUAL_SOURCES to the infrastructure: if set (to a tarball URL) it forces 'make legal-info' to download that tarball and store in the tarball directory instead of the FOO_SOURCE tarball.
    • For the license statement, we can add a long line with all the included license, e.g. GPLv3+ (gcc), GPLv3+ (binutils), ...
  • Mark missing license files. Currently there is no way of knowing if we just forgot to add the license file, or the license file is really missing. But actually, if a package defines a license but no license file, then probably it just doesn't have a license file. For packages where we looked at it but didn't come to a conclusion, we can just put FOO_LICENSE = unknown.
    • Conclusion: if there is no license file, don't define LICENSE_FILES - preferably with a comment explaining why it is missing.
    • We still consider SPDX support to be too complicated, and anyway there is not a single upstream that provides SPDX files so we can't do much with it.

Discussion on atomic operations and how to handle the related dependencies at the kconfig level

The problem is that the presence of atomic operations is not just dependent on the architecture but also on the toolchain. And in that case, we want to display the 'requires a toolchain with' comment. It seems that atomics were added in gcc 4.7, so older gcc versions will not support it; the user could select a different gcc version to get the atomic operations. Still, it looks like this is too much of a corner case, so drop the requirement for a comment.

Better than checking the gcc version, check the presence of the feature. We can add tests to the external toolchain that validates that the user-supplied option is correct.

A second problem is RPC support. libtirpc needs atomic operations, and is selected automatically when the toolchain lacks RPC support. So what if the architecture doesn't support atomics, should we then display a comment saying to select a toolchain which does have RPC? One option would be to patch out the atomic operations (replace with a mutex) from libtirpc if they are not available on the platform. We could also simplify the way that libtirpc is used: instead, create a blind config option that is enabled when the toolchain provides RPC or when libtirpc is selected; then change the comments to say 'system with RPC' instead of 'toolchain with RPC'. Or better yet: move the option to select libtirpc to the toolchain options.


  • Create an RPC blind option which other packages can depend on.
  • Add options to select libtirpc to the internal and external toolchain menus. Probably a choice for uClibc (between uclibc RPC and libtirpc), and a simple bool for external toolchains.
  • Add symbols for the gcc version, similar to the kernel headers version. Select the appropriate version for external toolchains.
  • Rename BR2_ARCH_HAS_ATOMICS to BR2_HAS_ATOMICS. BR2_HAS_ATOMICS is a blind option that is enabled by the toolchain, if appropriate.
  • In the external toolchain infrastructure, check that the BR2_HAS_ATOMICS choice is correct.

We have some recent issues with C++11; we could use a similar toolchain-feature approach like above.

Pending large series:

  • The paranoid wrapper series from Thomas P.
    • Looks good. Would be nice if we would have the wrapper for the internal toolchain as well. We can install it in a different place using --exec-prefix, and add symlinks. But it may be a bit too complicated, so we can live with the situation as it is now.
    • A problem with the check as it is now is that there are still a lot of false negatives: /usr/x86_64-linux-gnu/lib, .... However, it's extremely unlikely that these would be poisoned, because typically the wrong paths come from hardcoded stuff or from wrong pkg-config files, either of which would not be /usr/x86_64-linux-gnu/lib. But of course /lib does have to be added.
    • Another issue is that it is likely to fail already during configure, and then the error message goes to config.log; the build may even continue and just disable one of the optional parts. But there's really not much we can do about it.
    • There was some discussion about the variable naming (BR2_ or BR_). There will be a user-visible BR2_ variable that goes into Kconfig, and maybe also a BR_ environment variable.
  • The march/mcpu conflict on ARM series from Thomas P.
    • The only major discussion about this series was that arm1136jf_s has two revisions which are actually different cores, but gcc uses the same -mcpu for them. But this is basically a problem in gcc, so we'll just go for the default and remove the two revisions.
    • The patch needs improvement though because BR2_GCC_TARGET_CPU is used in some places.
    • Separate discussion: what about -mtune? What's the point to have it in buildroot in the first place? It looks like we anyway always use the same -mtune and -march values, so there is no point to it. ThomasP and Arnout looked at this in detail, with these conclusions:
      • On x86, remove the BR2_GCC_TARGET_TUNE option, because it has the same values as BR2_GCC_TARGET_ARCH (except for generic, which should be moved to BR2_GCC_TARGET_ARCH)
      • On SPARC, merged BR2_GCC_TARGET_TUNE into BR2_GCC_TARGET_CPU, and get rid of BR2_GCC_TARGET_TUNE
      • On PowerPC, rename BR2_GCC_TARGET_TUNE to BR2_GCC_TARGET_CPU
      • On m68k, get rid of BR2_GCC_TARGET_TUNE, it's redundant with BR2_GCC_TARGET_CPU
      • Get rid of BR2_GCC_TARGET_TUNE entirely
      • Change the ffmpeg package to pass --cpu=$(BR2_GCC_TARGET_CPU) if this value is non-empty, or --cpu=$(BR2_GCC_TARGET_ARCH) otherwise
  • The Qemu series from Yann
    • Looks basically OK, but needs review.
    • There's also still a host-qemu-system series pending from Gustavo from long ago. It adds a qemu-system package separate from qemu itself, which is not so nice. But actually it can just be added to qemu. What is also not nice is that you don't get any graphical console unless you have sdl headers installed, which depends on X development headers. Building that ourselves is messy, but also reporting it as a dependency is messy...
  • The freerdp series from Yann
    • Looks basically OK, but needs review.
  • The NVidia series from Yann
    • Ugly but we have no alternatives.
  • The OpenCV series from Samuel
  • The apr-util/apache series from Bernd
  • The gendoc series from Yann (IMPORTANT)
    • Nobody has spoken strongly against it so it should be OK to commit it.
    • Peter should however test if he can still build the PDF.
  • The X.org/i.MX6 series from Jérôme
  • The libudev series from Yann (IMPORTANT)
    • Peter is happy with it, but the question is whether it will continue to be easy to build just libudev. It's also something that can only be runtime tested so we won't notice if the udev daemon is really needed. But it looks like libudev is already listening to netlink events from the kernel, so even without udev it should get hotplug events. Still, Bernd reported that some package (xserver_xorg-server) does need udev at runtime! In this particular case there is a workaround (configure it to not use the udev daemon even if libudev is present), but there may be other packages like that. So, dependencies on udev should not be blindly converted to libudev. So we can't remove the udev virtual package.
    • We would also like to change the depends on libudev into select libudev.

Key-signing party

It would be useful to have a web-of-trust amongst Buildroot developers, to submit sensitive information, such as the hashes. This wasn't done. Some people forgot their gpg passphrase, others don't have a gpg key yet.

Project maintenance:

    • Peter seems to be less active now
    • Thomas (who acts as deputy committer) has new responsibilities, and risks being less available too
    • How do we see the short- and long-term maintenance of the project?
    • One of the difficulties for the two maintainers is avoiding to step on eachother, i.e. both doing the same thing. Also they somehow need to agree about when something is too big to apply quickly.
    • More Reviewed/Acked-by is certainly the thing that helps the most. Even if it's no guarantee that it gets applied quickly, it does help to speed things up.
      • There is really not much Reviewed/Acked-by that is provided, cfr. the patchwork columns!
    • If patches need to be fixed up (e.g. small whitespace fixes), it also helps if someone takes it over and reposts.
    • If there are related patches that are spread over patchwork, it helps to create a public branch and a pull request.
    • The easy stuff takes something like 20 minutes a day.
    • Stuff becomes easier with good commit logs. The difficult things are patches which are good but which take time to understand what it does, why and what the implications are. A good commit log makes that easier.
    • Sometimes there are things that are hard for a single maintainer to decide on. The BR devel meeting helps for this, but it would be nice to still be able to make progress on it.
    • The patchwork days didn't really work - it's too hard to gather people for it.

Should we move buildroot.org to its own server, and split from busybox.net and uclibc.org?

This wasn't discussed.

Flattened Image Trees support

Basic work was already done in order to compile and/or install FIT blobs. The final implementation should cover following use cases:

  • create FIT image consisting of kernel and DTB(s) - no build order dependencies
  • create and install FIT image consisting of kernel and DTB(s) - requires FIT blob to be available before filesystem image is created, otherwise FIT blob won't can't be installed to output/target/boot
  • create FIT image having initramfs - requires BR2_TARGET_ROOTFS_CPIO to be available before FIT blob is created
  • create FIT image having initramfs appended to the kernel - requires BR2_TARGET_ROOTFS_INITRAMFS to be available before FIT blob is created

ThomasP and Arnout looked at this. It really looks like something pretty complicated by buildroot which is trivial to do in a post-build or post-image script. ThomasP will send a reject mail.

Patchwork clean-up

Significant progress has been made, cutting the number of New patches in patchwork down from about 350 to 250. The process was:

  • Two persons (ThomasP and Arnout) triage the patches into Patches that need some oral discussion, Patches that should be tested, Acked and committed (i.e. no problems expected), Patches that need review or rework, and Patches that should be sent a rejected mail (some patches were rejected outright, e.g. if the author was present).
  • The others do review, testing, reposting and commenting.
  • Peter does a final check and commits.

We spent about a day and a half on this and we feel it was relatively efficient.

These are the patches that we didn't have the time to work on in the end, with their initial analysis:

These are the patches that have been rejected but didn't receive a mail yet:

  • link toolchain statically against libmpfr etc. so it is relocatable: We don't think this is the right solution. Instead, rpath should be made relative with $ORIGIN (but this gives problems with the $-expansion by make and sh) or we should use patchelf on all host binaries. It's not simple. Marked as rejected. (Thomas: done on November, 1st)
  • LTO: Just enable lto in the toolchain but leave it up to packages to make use of it. I.e., build gold but keep ld as the default.
  • libssh2 build failure: Alternative suggested by Arnout, should be implemented and tested.
  • [1], rejected, Thomas mails the submitter. (Thomas: done on November, 1st)
  • [2], rejected, Thomas mails the submitter. (Thomas: done on November, 1st)
  • [3], rejected, Peter mails the submitter