Buildroot Developers Meeting, 5-6 February 2018, Brussels
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 February 5th and 6th 2018 in Brussels, right after the FOSDEM conference. The meeting will place in Google offices, located Chaussée d'Etterbeek 180, 1040 Brussels, very close to the Schuman metro station.
We would like to thank our sponsors:
- Google, providing the meeting location, with Internet connection, but also free lunch and refreshments for the meeting participants.
We are looking for sponsors to sponsor the dinner for the participants, and possibly travel expenses.
- Namespace collision in package infra
- for example foo and foo-base will collide with variables $(1)_NAME and $(1)_BASE_NAME
- already hit by:
- alljoyn <-> alljoyn-base
- alljoyn-tcl <-> alljoyn-tcl-base
- perl-xml-sax <-> perl-xml-sax-base
- so, we need to better separate the package part from the infra part, for example:
- two underscores as a separator: FOO__NAME and FOO__BASE_NAME
- a dot: FOO.NAME and FOO.BASE_NAME
- Top-Level Parallel Build (TLPB)
- How to trigger it?
- option in menuconfig
- automatic via top-level 'make -jN' ?
- How to handle non-make buildsystems (e.g. meson/ninja) that have their own parallel build that does not talk to a job-server?
- either over-use of CPU (worst case N^2 jobs instead of N)
- or under-use of CPU (1 job instead of N)
- See e.g. https://github.com/ninja-build/ninja/issues/1139
- How to trigger it?
- GObject introspection
- what to do about this?
- without it, we can't bump some packages, or lose functionality when bumping
- RFC-patch from Adam: https://patchwork.ozlabs.org/patch/828791/
- Download script overhaul
- git caching
- Patches from Maxime, reworked by Peter: https://patchwork.ozlabs.org/project/buildroot/list/?series=10225
- Security Hardening
- Validation approach post build that things took effect
- How does it hook in to update the build flags? https://patchwork.ozlabs.org/patch/796080/
- case to be checked for kernel, bootloaders et al.
- Internal toolchain build tweaks (some std libs don't inherently get the build flags tacked on)
- Test case approach(s) for compliance testing