Buildroot:DeveloperDaysFOSDEM2015

From eLinux.org
Revision as of 07:42, 7 March 2015 by Arnout Vandecappelle (talk | contribs) (Add summary of meeting outcome)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Buildroot Developers Meeting, 2-3 February 2015, Brussels

Location and date

The Buildroot community is organizing a meeting on February 2nd and 3rd 2015, 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 offices of Google in Brussels, located Chaussée d'Etterbeek 176-180. See a map.

Sponsors

Google-logo.png
Mind-logo.png

We would like to thank our sponsor:

  • 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. Thomas Petazzoni
  2. Yann E. MORIN
  3. Peter Korsgaard
  4. Samuel MARTIN
  5. Thomas De Schampheleire
  6. Romain Naour
  7. Julien Boibessot (Armadeus)
  8. Arnout Vandecappelle

Summary and conclusions

The report of the meeting is written at [2]. This section summarizes the main points and conclusions.

Patches

The main result of this developer meeting has been a big patchwork cleanup. We managed to reduce the number of pending patches in patchwork from about 350 to about 200. A good deal of patches have been rejected (with an explanation why), but also many patches have been applied after some clean-up.

Some of the patch series required some discussion to decide how to continue with them. Normally the conclusions should have been posted on the list, but you can also out the full report.

GSoC and money

Thanks to GSoC, buildroot now has some money. There is now an accounting section on this wiki to keep track of where it comes from and how it is spent. Since founding a non-profit seems to be too much effort, the money is currently held by Yann E. Morin.

Some ideas were posted for the next GSoC. As it turns out, however, we've not been accepted as a mentoring organisation for GSoC'15. Better luck next year!

Help text and README

Due to a patch series to rewrite the 'make help' output by ThomasP., we have discussed what we really want to show where. The conclusions are:

  • Keep one big 'make help', no 'make foo-help'. Order the output in a more logical way.
  • Create a new 'make list-defconfigs' to reduce the output of 'make help'. Add a FAQ entry that refers to this.
  • The README should be rewritten so it is small and refers to other documentation.

Arnout was volunteered to do this.

Original agenda

Most of these topics were indeed discussed.

  • Download infra
    • Patches that need discussion
      • Per-package help text (Thomas P.)
      • The mesa3d-headers issue (Yann)
      • DT Overlay patches for dtc (Peter Seiderer)
      • Lua 5.3 stuff (François Perrad)
      • Simple network config (Jérémy Rosen)
      • skeleton: make /run a proper directory/filesystem
    • GitHub helper:
      • try to avoid the breakage when GitHub changes the download scheme
        • use the API => stable, but rate-limited to 60 anonymous requests per hour (5000 when authenticated)
        • always do a git clone => stable, not rate limited, but may have a huge impact on download sizes
      • what to do about other forges: Gitorious, Google Code...
    • Upstream tarballs not named PKG-VERSION
      • Yann proposed a way to specify upstream name when it differs from PKG-VERSION, and keep _SOURCE to name the local tarball
      • Alternate solution: always use PKG-VERSION when saving the local tarball anyway
  • The Code Sourcery Standard toolchains:
  • Further cleanup wrt. static vs. shared:
    • a lot of packages still install static libs, even when doing a shared-only build
    • we can't really run: find staging/ -type f -name '*.a' -delete because of static libs from the toolchain we really want to keep, and because some packages may really want to install only static libs
    • proposal (YEM):
      • add a new package variable: FOO_KEEP_STATIC_LIBS = foo.a foobar.a
      • add a new internal variable: KEEP_STATIC_LIBS += $($(2)_KEEP_STATIC_LIBS)
      • after staging-install, run: find staging/ \( -type f -o -type L \) -name '*.a' -a \! \( -name toolchain.a BLABLA \) -delete
        • where toolchain.a is for all static libs from the toolchain
        • BLABLA is something like: $(foreach lib,$(KEEP_STATIC_LIBS),-o -name $(lib))
      • the reasoning is:
        • there are very few packages that really want to install static libs
        • so instead of saying what to remove (the majority), we state what to keep (the minority)
  • Google Summer of Code
    • Money from the GSoC 2014
      • Google has paid $500 (€423.94) for mentoring a student
      • Yann has received the money, and holds it on his own bank account for now. What about the long term?
      • How should we spend this money?
    • GSoC 2015
      • Org registration opens 2015-02-09 19:00 UTC, closes 2015-02-20 19:00 UTC
      • Should we participate again this year?
      • What topics?
  • Open patches
    • autobuild-run improvements (ThomasDS)

Code hacking

  • Continuation of the kconfig-package infrastructure (for Linux etc.)