Buildroot:DeveloperDaysFOSDEM2016

From eLinux.org
Jump to: navigation, search

Buildroot Developers Meeting, 1-2 February 2016, Brussels

Location and date

The Buildroot community is organizing a meeting on February 1st and 2nd 2016, for Buildroot developers and contributors. This meeting will be a mixture of discussion and hacking session around the Buildroot project. This meeting takes place either right before or right after the FOSDEM, in order to make it easy for participants to attend both events. It is not mandatory to attend both days.

The meeting will take place in Google offices, located Chaussée d'Etterbeek 180, 1040 Brussels, very close to the Schuman metro station.

The meeting hours will be 9 AM to 6 PM on both days, the lunch is free of charge, courtesy of Google. On Sunday and Monday evenings, we will be organising some social events for which the details will be communicated to the participants.

Sponsors

Google-logo.png
Mind-logo.png

We would like to thank our sponsors:

  • Google is sponsoring due to their usage of Buildroot to build embedded Linux systems for embedded devices used in the Google Fiber project. The source code of their modified Buildroot is available at [1]. Google will be providing the meeting location, with Internet connection, but also free lunch and refreshments for the meeting participants.
  • 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 is currently hiring! Mind will be offering the Monday dinner to the participants of the meeting.

Participants

  1. Samuel MARTIN
  2. Thomas Petazzoni
  3. Yann E. MORIN
  4. Arnout Vandecappelle
  5. Thomas De Schampheleire
  6. Julien BOIBESSOT
  7. Peter Korsgaard
  8. Gwenhael Goavec-Merou
  9. Naour Romain
  10. Maxime Hadjinlian
  11. Luca Ceresoli

Jan Heylen did not attend due to illness.

Topics discussed

  • key-signing party
    • Only Thomas, Yann and Arnout participated in the party.
  • Buildroot Association
    • Maxime checked, we just have to make sure the statutes are in French and then we can create an association in France. Members don't have to be French.
    • Statutes are on github for editing. English translation is available.
    • We have to have a founding General Assembly and sign the statutes.
    • Naming: "Buildroot" or "Buildroot Foundation"?
      • Arnout prefers plain Buildroot
      • Buildroot Foundation has the advantage that it is more clear that if e.g. someone makes a commit that violates a license, it's not the Buildroot Foundation that is liable for it.
      • Decision: Buildroot Foundation
    • Other discussion was directly updated in the statutes.
  • GSoC participation
    • Possible topics:
      • Reproducible builds
      • Testing infrastructure (both autobuilder improvements and runtime tests)
      • Relocatable SDK
      • Top-level parallel build
      • Script to check for package updates, CVEs, ... There are existing things that we may be able to reuse, but of course it will have to be adapted to fit Buildroot.
      • Support for LLVM. This includes adding the toolchain, but also updating packages to support LLVM builds.
      • Upstream python patches. Perhaps co-mentored with a Python developer (ThomasP knows someone).
      • Support new languages: Go, Rust. But Ludovic Guegan is already preparing patches for adding Go infrastructure, and we already have a basic patch in patchwork.
    • The date is approaching, we have to have an ideas page by then with enough details so they check if it's worthwhile to sponsor.
    • Yann, ThomasP, Arnout, Peter, Romain volunteer to be mentors.
    • Yann will write the ideas page (but poll on the mailing list and IRC for help) and randomly put mentors on topics.
  • State of per-package staging patches
    • Gustavo is working on this topic for a customer, but still hasn't sent an updated version of the patch series.
  • State of relocatable host tools
  • musl/gettext handling
    • A proposal has been made by Bernd on the mailing list
    • This proposal is exactly the same as what Peter has just applied for libmadplay specifically.
    • The problem is that the gettext.m4 macro checks for GNU gettext, while most packages just need any gettext. If there is any package that really needs these extensions, it should depend on !MUSL. Note that fixing gettext.m4 is not a real solution since we'd have to autoreconf all packages...
    • Why do we even have gettext for the target in glibc and musl? Because it adds a gettext tool that can be used by shell scripts.
    • In addition, the gettext package installs its own libintl.h which conflicts with the one installed by musl. The configure option to disable libintl doesn't seem to work.
    • Peter looked at it during the meeting, and a solution similar to Bernd's proposal, but simpler, was merged.
  • qemu / host-qemu integration
    • Patch on the list to improve host-qemu support. Simon (who submitted this patch) looked at the original patch from Gustavo and the ensuing discussion.
    • There was a discussion about if we really want to build host development tools that could be just as well be built outside of buildroot. But for qemu there is certainly a point for that, because you want to build a qemu version that corresponds to your defconfig.
    • We don't like much that the patch adds options for git and hg and ... like Linux does. You can use OVERRIDE_SRCDIR, although admittedly that's not ideal
    • Ideally, we should have a more generic way of overriding stuff (including VERSION, SITE, SITE_METHOD). But that would require a lot of infrastructure work.
      • How about -include'ing a <pkg>-override.mk at the beginning of inner-generic-package? This could make things simpler, but there are a lot of corner cases that still make it complicated. For example, it would also have to be included at the beginning of inner-autotools-package; avoid double inclusion for target and host package; there has to be some way to avoid applying the in-tree and/or downloaded packages. Also it gives people more ways to shoot themselves in the foot.
    • We should separately merge the interesting parts of the qemu patch, while someone works on a generic mechanism in parallel.
  • run-time testing infrastructure
    • No progress since the last meeting
    • Building of defconfigs has moved to TravisCI, results are posted on IRC. There is a repo at https://github.com/buildroot/buildroot-defconfig-testing which has a travis.yaml config and script that fetches from the buildroot.git repository and builds all defconfigs.
    • Travis CI dashboard at https://travis-ci.org/buildroot/buildroot-defconfig-testing/builds
    • There is no full build log because Travis will abort the build if you output too much. It also aborts if there is no output at all, so there is a dummy background process that outputs something every so many seconds.
    • The buildroot version to download is done by a cron job on Thomas's machine that makes a commit to the buildroot-defconfig-testing repo, and this triggers the build.
    • Once in a blue moon, the build will fail because we need to install bc and this is racy with other Travis processes. bc is needed for recent kernels.
  • Licensing of patches: clarifying in the manual and/or the COPYING file the license under which the patches for the different packages are released.
    • Thomas has received several questions about this.
    • We only mention it very briefly in the "Format and licensing of the package patches" section of the manual, which is not really a 'legal-info' location.
    • This really should be mentioned in several places: in the COPYING file (a section on top, like the kernel does); in the manual's legal section; in the legal-info README. Luca volunteers to supply patches.
  • How to deal with packages that require specific kernel options to be set.
  • "Big" pending series:
    • We didn't discuss any of these, we spent a lot of time on the Buildroot Foundation.

Hackaton topics

Not much hacking has been done in these two days. See the patches posted on the mailing list for what actually was done. We did discuss the following idea.

  • gdb debugging improvements:
    • toolchain copying: lib structure in staging and target should line up; otherwise gdb will not automatically find libraries. For example, for external toolchains where libstdc++ is in /lib, buildroot copies it to /usr/lib and gdb doesn't find it. Workaround is to 'set solib-search-path' in gdb.
    • cross-gdb in output/staging/usr/share/buildroot: this could become a wrapper that immediately passes '-x gdbinit' instead of requiring the user to do that. In fact, this could even remove the need for gdbinit, and make it immediately relocatable because the wrapper script can calculate the correct path instead of hardcode it.
    • For either the internal or the external toolchain, the cross-gdb symlink is missing.

Pictures

Group picture. From left to right: Julien Boibessot, Maxime Hadjinlian, Gwenhael Goavec-Merou, Samuel Martin, Peter Korsgaard, Arnout Vandecappelle, Romain Naour, Luca Ceresoli, Thomas De Schampheleire, Thomas Petazzoni