Buildroot:DeveloperDaysELCE2014

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.

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

Sponsors
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.

Participants

 * Thomas Petazzoni
 * Peter Korsgaard
 * Luca Ceresoli
 * Arnout Vandecappelle
 * Maxime Hadjinlian
 * Yann E. MORIN
 * Vicente Olivert Riera
 * Alexey Brodkin (arriving 10 AM on Saturday at the airport)
 * Romain Naour

Format
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.

Topics to discuss

 * Look-back to action points from previous developer days at Fosdem 2014: is everything that was decided done? What remains?
 * 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?
 * Since Luca will be present: state of legal-info infrastructure, improvements to be made?
 * Could more details be added here (by Thomas DS, who proposed the topic)
 * Discussion on atomic operations and how to handle the related dependencies at the kconfig level
 * Cleanup the patchwork; triage patches in two categories:
 * things that hasn't been pushed enough but that we believe is useful
 * things that haven't been pushed enough and that are too anecdotic for us to care about
 * Pending large series:
 * The paranoid wrapper series from Thomas P.
 * The march/mcpu conflict on ARM series from Thomas P.
 * The Qemu series from Yann
 * The freerdp series from Yann
 * The NVidia series from Yann
 * The OpenCV series from Samuel
 * The apr-util/apache series from Bernd
 * The gendoc series from Yann (IMPORTANT)
 * The X.org/i.MX6 series from Jérôme
 * The libudev series from Yann (IMPORTANT)
 * Key-signing party: it would be usefull to have a web-of-trust amongst Buildroot developpers, to submit sensitive information, such as the hashes.
 * 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?
 * Should we move buildroot.org to its own server, and split from busybox.net and uclibc.org?
 * Flattened Image Trees support. Basic work was already done in order to compile and/or install FIT blobs (http://patchwork.ozlabs.org/patch/396240/). 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