Difference between revisions of "Buildroot:DeveloperDaysFOSDEM2016"

From eLinux.org
Jump to: navigation, search
(add Romain Naour in Buildroot FOSDEM DevDay 2016 particiants list)
(Pictures)
 
(30 intermediate revisions by 8 users not shown)
Line 11: Line 11:
 
=== Sponsors ===
 
=== Sponsors ===
  
[[File:google-logo.png|right]]
+
[[File:google-logo.png|right]][[File:Mind-logo.png|right]]
  
We would like to thank our sponsor:
+
We would like to thank our sponsors:
 
* [http://www.google.com Google] is sponsoring due to their usage of Buildroot to build embedded Linux systems for embedded devices used in the [https://fiber.google.com/about/ Google Fiber] project. The source code of their modified Buildroot is available at [https://gfiber.googlesource.com/buildroot/+/master]. Google will be providing the meeting location, with Internet connection, but also free lunch and refreshments for the meeting participants.
 
* [http://www.google.com Google] is sponsoring due to their usage of Buildroot to build embedded Linux systems for embedded devices used in the [https://fiber.google.com/about/ Google Fiber] project. The source code of their modified Buildroot is available at [https://gfiber.googlesource.com/buildroot/+/master]. Google will be providing the meeting location, with Internet connection, but also free lunch and refreshments for the meeting participants.
 +
* [http://www.mind.be 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 ===
 
=== Participants ===
  
# [[User:SamuelMartin|Samuel MARTIN]], arriving at Bruxelles Midi train station on Friday at 19:47, leaving from Bruxelles Midi train station on Tuesday at 19:13.
+
# [[User:SamuelMartin|Samuel MARTIN]]
# [[User:ThomasPetazzoni|Thomas Petazzoni]], arriving at BRU airport on Friday at 20:05, leaving from BRU airport on Tuesday at 21:05.
+
# [[User:ThomasPetazzoni|Thomas Petazzoni]]
 
# [[User:ymorin|Yann E. MORIN]]
 
# [[User:ymorin|Yann E. MORIN]]
# [[User:Arnout_Vandecappelle|Arnout Vandecappelle]], commuting daily from Leuven.
+
# [[User:Arnout_Vandecappelle|Arnout Vandecappelle]]
 
# Thomas De Schampheleire
 
# Thomas De Schampheleire
 
# [[User:JulienBoibessot|Julien BOIBESSOT]]
 
# [[User:JulienBoibessot|Julien BOIBESSOT]]
 
# [[User:PeterKorsgaard|Peter Korsgaard]]
 
# [[User:PeterKorsgaard|Peter Korsgaard]]
# Jan Heylen
 
 
# Gwenhael Goavec-Merou
 
# Gwenhael Goavec-Merou
 
# Naour Romain
 
# Naour Romain
 +
# Maxime Hadjinlian
 +
# Luca Ceresoli
  
=== Who can attend ? ===
+
Jan Heylen did not attend due to illness.
  
This meeting is opened to all Buildroot users and developers. The event is free. However, we make it clear that it is not a training event about Buildroot aimed at newcomers. It is a meeting for Buildroot developers to make progress about various topics in Buildroot. It is recommended to already be a Buildroot contributor to participate to the event.
+
=== Topics discussed ===
 
 
=== Topic to discuss ===
 
  
 
* key-signing party
 
* key-signing party
 +
** Only Thomas, Yann and Arnout participated in the party.
 
* Buildroot Association
 
* 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.
 +
** [https://github.com/buildroot/buildroot-association 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
 
* 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 [http://patchwork.ozlabs.org/patch/542108/ 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
 
* 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
 +
** Samuel is still working on this, he should send his patches soonish series has been reposted (http://lists.busybox.net/pipermail/buildroot/2016-February/151229.html , http://patchwork.ozlabs.org/patch/576591/ and followers)
 +
** But the problems should really be handled one by one, because it's too big to tackle in one shot.
 +
** Samuel also has some patches to fix <pkg>-config scripts
 +
** Samuel has a patch that fixes rpath
 +
** Samuel also has a tool that checks for wrong things in target rpath.
 +
** Samuel will focus on this today.
 +
* 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 [[Buildroot:DeveloperDaysELCE2015#Report|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 [https://buildroot.org/downloads/manual/manual.html#_format_and_licensing_of_the_package_patches 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.
 +
* [http://comments.gmane.org/gmane.comp.lib.uclibc.buildroot/128874 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 ===
 
=== 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:
 
* 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.
 
** 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.
+
** 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.
* Host-perf support after tools infrastructure changes in linux.mk (and the removal of perf.mk)
+
** For either the internal or the external toolchain, the cross-gdb symlink is missing.
 +
 
 +
=== Pictures ===
 +
 
 +
[[File:Buildroot-meeting-feb-2016-group.jpg|framed|center|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]]

Latest revision as of 00:55, 8 February 2016

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