eLinux.org - User contributions [en]

Buildroot:DeveloperDaysFOSDEM2013

2013-02-05T16:34:34Z

Arnout Vandecappelle: Make topics for the hackaton day match with reality

== Buildroot Developers Meeting, 4-5 February 2013, Brussels ==

=== What is Buildroot ? ===

[http://buildroot.org 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.

=== Thanks to our sponsor Google ===

[[File:google-logo.png|right]]We would like to thank [http://www.google.com Google], who will be providing the meeting location, with Internet connection, but also free lunch and refreshments for the meeting participants. Thanks Google!

It is worth noting that 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].

=== Location and date ===

The Buildroot community is organizing a meeting on Monday February 4th 2013 and Tuesday Feburary 5th 2013, for Buildroot developers and contributors. This meeting will be a mixture of discussion and hacking session around the Buildroot project. This meeting takes place right after the [http://www.fosdem.org FOSDEM], in order to make it easy for participants to attend both events.

Note that it is not mandatory to attend both days. It is expected that the first day will be mostly dedicated to discussion, while the second day will be mostly dedicated to hacking.

The meeting will take place in Google Brussels offices, located Chaussée d'Etterbeek 180, 1040 Brussels. See http://goo.gl/maps/ZVAGJ for a map of the area.

=== Participants ===

# [[User:ThomasPetazzoni|Thomas Petazzoni]], confirmed. Arriving on February, 1st at 19:45 at BRU airport, leaving on February, 5th at 21:10 from BRU airport.
# [[User:Ymorin|Yann E. MORIN]], confirmed. Arriving 2013-02-01 17:23 at Bruxelles Midi, leaving on 2013-02-05 17:13 from Bruxelles Midi.
# [[User:PeterKorsgaard|Peter Korsgaard]], confirmed. Lives close by.
# [[User:Arnout_Vandecappelle|Arnout Vandecappelle]], confirmed. Lives even closer by.
# [[User:SamuelMartin|Samuel Martin]], confirmed. Arriving on February, 2nd at 08:47 at Bruxelles Midi, leaving on February, 5th at 19:13 from Bruxelles Midi.
# Dimitrios Siganos, attending on Monday only.
# [[User:ThomasDeSchampheleire|Thomas De Schampheleire]], confirmed. Lives close by.

=== Registration ===

Please contact Thomas Petazzoni (thomas.petazzoni@free-electrons.com) if you would like to attend.

Attending the event is free, but registration is required.

Note that the event is mainly intended for Buildroot developers and contributors, or advanced users willing to contribute more or to share about their use case for Buildroot.

=== List of topics to discuss ===

Good starting points are:
* [[Buildroot:DeveloperDaysELCE2012#Report_of_the_meeting|Report of the ELCE 2012 Buildroot meeting]]
* [[Buildroot:DeveloperDaysELCE2012#List_of_topics_to_discuss|ELCE 2012 List of topics]]

==== Topics for the discussion day (Monday 2013-02-04) ====

* Topics related to changes to the infrastructures
** current state of the infrastructure, and how to enhance it
*** copy target/ before creating images
*** handling of linux-menuconfig, busybox-menuconfig, uclibc-menuconfig, etc.
*** Refactoring package menus (Arnout)
*** Support for out-of-tree packages (Arnout)
*** Switch to ct-ng as the default backend for toolchain building
** pending series enhancing the infrastructure
*** [http://lists.busybox.net/pipermail/buildroot/2013-January/065603.html post-image-script]
*** [http://lists.busybox.net/pipermail/buildroot/2013-January/065174.html <pkg>_CONFIG_FIXUP]
*** [http://lists.busybox.net/pipermail/buildroot/2013-January/065879.html build out-of-package-dir]
*** [http://lists.busybox.net/pipermail/buildroot/2013-January/065410.html package-create-user]
*** [http://lists.busybox.net/pipermail/buildroot/2012-December/063482.html pkg-infra: limit -reconfigure and -rebuild actions]
* Topics related to the packages included in Buildroot
** finally remove the 'devel-on-target' packages ?
** host-pkgconf and "host-autotools" as visible host packages (Eclipse/app dev)?
** new packages pending
*** [http://lists.busybox.net/pipermail/buildroot/2013-January/064945.html tzdata et al.]
*** What to do with systemd/udev/eudev
* How are we doing? (Arnout)
** Is the project sufficiently stable?
** Do we have enough users, contributors?
** Are there threats we should care about?
** Is there a new important direction for which we lack support?
* [http://lists.busybox.net/pipermail/buildroot/2013-January/064646.html Building a fully configured project]
* Wild idea: [http://maemo.gitorious.org/scratchbox2/pages/Home scratchbox2]
* Giving a status on autobuilder improvements / website improvements (Thomas)
* Wild idea: for VCS site methods where version is HEAD or a branch, BR checks every time if the upstream has changed. This is to track the development made by team mates: your own work is in a OVERRIDE_SRCDIR, other libraries/dependencies are in a VCS method and are automatically updated. Question: how to expose this feature to the user? Addition kconfig option per package? Additional variable in local.mk? Something else?
* Wild idea: make it possible to configure some things per package, like optimisation/debug flags, static library, ... - this would require serious modification to Kconfig or a meta-kconfig.
* Provide a (nightly|weekly)-built manual from master. (Yann)
* Use kconfig-frontends ? (Yann)
* Remove the wget et al config options (Arnout)
* Google Summer of Code 2013 (Thomas)
* Patchwork maintenance, how to deal with pending patches (Arnout)

==== Discussion ====
* Copy target before creating images: the idea is to avoid the need for creating idempotent scripts in e.g. post-build script. It does make sense, because for the user it's a bit more difficult to make scripts idempotent. Also it can be a step for hiding the "target" directory. And it makes complete sense if we remove the "target" directory completely and copy from staging instead.
** The compelling reason to make target a subset of staging is that it is much easier to do debugging: just "gdb staging/usr/bin/foo" and it will have debug symbols and the paths to the source files.
** Single install commands: FOO_INSTALL_CMDS. They get executed twice, with DESTDIR set to the correct place (target or staging or host). The POST_XXX_INSTALL_HOOKS would still be executed separately. But this doesn't yet give us the situation that target and staging are the same, but target just has some stuff removed.
** Take it one step at the time: start with FOO_INSTALL_CMDS, we can see how far we get.
** Document that post-build script has to be idempotent (with an example).
* There was a lot of discussion about using buildroot in practice in different contexts. Add to documentation a section of how to use buildroot in practice. Maybe in the form of one or more use case - but not too many because it would just confuse users. For instance, assume that proprietary patches are in-tree in package/companyname, not out-of-tree. The chapter would be called "Integration into a development workflow".
* There is a consensus that buildroot should not be just an integration platform, but also usable in development. However, we should never sacrifice the simplicity, and integration has to remain the main focus. The out-of-tree package build is a good example, as well as the automatic fetching of VCS HEAD.
* Add chapter to manual to explain the internals of buildroot. Not so much the existing implementation, but rather the design choices.
* post-image script: good thing is that it can be included in a defconfig, so accept it. Post-image script (just like post-build script) will not run in fakeroot.
* Stable releases: the consensus is that it is a lot of effort and nobody would use it.
* Users and contributors: contributors are still increasing, number of users we don't really know but probably pretty high.
* Threats:
** The number of forks of buildroot. We're missing out on contributors, and if it doesn't work well we loose credibility. For instance, armadeus doesn't upstream anything (no kernel, u-boot, buildroot) - for them there is no hope. But for instance also RPi has a buildroot fork on github. Maybe it would help if we would have an official repository on github (github can be setup to automatically pull form the official repository). If we really want, we could pull patches from the repositories that we know about. A fork that just adds a defconfig and a few feature patches is not a big deal, on condition that they are kept up to date.
** Flash sizes are increasing, so the size advantage of buildroot is not much of an advantage anymore. Compared to e.g. emdebian, there are two more advantages:
*** much more understandable what happens at boot time and what exactly is installed, there's no predefined policy;
*** you have a top-level integration of the entire rootfs+kernel+bootloader from the start;
*** easy to learn for someone not familiar with Debian or Linux distros or system administration.
* Thomas would like to add testimonials and a list of users of buildroot to the website.
* Next big directions for buildroot
** SoC-specific libraries (OpenGL) are a pain: packages that use them need to somehow find them. We can use a virtual package mechanism like for jpeg (but then a bit different) and e.g. Qt5 depends on that virtual package.
** Switching to ct-ng as the default toolchain backend has been in the plans for several years. But since it's not the default backend it isn't getting a lot of attention (example: for several months it was broken, libraries were not copied to the target, and it took a lot of time for somebody to notice).
*** Issue #1: passing subarch variants to crosstool-ng. Shouldn't be a big problem to solve, just a matter of work.
*** Issue #2: download integration. Crosstool-NG cannot tell Buildroot what it needs, so Buildroot can't download it, which breaks things like "make source" and "make external-deps". This requires a number of changes in Crosstool-NG: Crosstool-NG doesn't know the exact URL for each component, doesn't yet have a capability to list which tarballs are needed (similar to "external-deps"). It has the capability of doing the download only, but it requires configure and installing crosstool-NG. Which means that "make source" in Buildroot would need to build Crosstool-NG and all its dependencies (host-gawk, host-libtool, host-autoconf, host-automake). This problem requires more work at the Crosstool-NG level.
*** Issue #3: legal info integration.
*** Option 1: keep only external toolchain backend. Consensus is that this is not acceptable, Buildroot should still have a way of building toolchains on its own.
*** Option 2: work on the Crosstool-NG backend to fix all the integration issues, and use it as the default backend.
*** Option 3: improve the internal backend, and assume that we don't really need an integration with Crosstool-NG.
*** Conclusion: Yann gets time till 2013.05 to work on issue #2. If that is successful or is making good progress, we go for Option 2. If it is going nowhere, we go for Option 3 or option 1.
* Handling of make xxx-menuconfig
** The last proposal on the list was to store the xxx-config files in the output directory, and don't remove them with make clean. However, if you delete the output directory that will still be gone.
** Instead, it can directly be saved to the configured place (e.g. boards/mycompany/myboard/xxx-config) instead of requiring an explicit 'make xxx-saveconfig' step. Potential problem: do we save a defconfig or a full config? Linux defconfig only exists since 2.6.26 or so and is sometimes buggy...
** We can disallow linux-menuconfig in case the BR2_LINUX_USE_CUSTOM_CONFIG is not set, and issue a warning. Combine that with automatically saving and we have a pretty complete solution.
** Conclusion: copy it back to the configured place, disallow xxx-menuconfig unless something is configured. We always save full config because defconfig is not always reliable.
* Splitting package/Config.in into separate files for each menu is a good idea for several reasons:
** In patches adding a package, it's obvious in which menu it is added
** Scripts can automatically find out in which menu a package is, e.g. to generate the package list in the manual
* Out of tree package build
** It's mainly needed for the kernel
** But it's also nice for the 600 other packages that support it out of the box.
** Risk of breakage, but can easily be solved by setting SUPPORTS_OUT_OF_TREE to NO
** Makes it slower for some large packages that don't support out-of-tree build, but also saves time for some others.
** Conclusion: the series still needs some work, but we do like out-of-tree package builds.
* Some .la files in the staging directory contain wrong information: paths to the build directory instead of the staging directory. Samuel proposes to remove the .la files. This needs some testing first, though.
* Devel-on-target packages are not removed quite yet. But more packages can be marked as deprecated.
* What to do with systemd/udev/eudev: we try to use the udev from systemd without systemd. Exactly how we don't know yet... There's a risk that udev becomes unusable without systemd, but Leonard Poettering promised this would not happen. After a quick look, it turns out that you always end up building systemd, which requires dbus, even if you need only udev. So it makes the systemd source tarball a bit unpractical to build a system that uses udev only, and doesn't need systemd. Probably an indication that we should have a look at eudev? How would this interact with the systemd selection? What about incompatibilities between udev and eudev?
* Building a fully configured project: the question is: what is the workflow for creating a buildroot-based distribution which has a lot more than just the defconfig, and you don't want to fork the buildroot repository. Answer: fork the buildroot tree, but merge regularly.
* Autobuilder status: Thomas will move the info to a database, and has some very basic webpages for accessing the database. He also dreams about running some tests in qemu - but we already have enough failures with the autobuilders as they are :-)
* Remove the wget et al config options (Arnout): these options are indeed useless, especially because dependencies.sh looks for "git", not BR2_GIT. But in fact, the whole "Build options" menu could use some refactoring.
* scratchbox2: may make life simpler to support cross-compiling. scratchbox2 does LD_PRELOAD magic to make sure that /usr/include and /usr/lib point into the sysroot instead of the host. It also runs foreign executables in qemu. However, Thomas (who used scratchbox before) was not impressed by it. It will probably also run into the kernel headers problems we had with cpanminus/qemu. Bottom line: it can be used if some package requires it, but in the end we will still have to solve cross-compilation issues.
* Use kconfig-frontends: we would clone it into buildroot, just like we currently do. Advantage of current kconfig-frontends is that it has some possibilities for tweaking the config executable, so that we need less or no patches. Still it's a bit of work to integrate. One problem is that it now has a configure script, which checks for flex, bison, gperf, and we want to bypass this in buildroot. We will create our own Makefile (just like we do now) and we'll check in the files generated by flex, bison, gperf. Yann doesn't have a lot of time to work on this.
* GSoC: student works 3 months full-time on a project. Google has to accept it, so it has to be somehow innovative and end up with a product. Core infrastructure work is probably not a good idea, because it's too difficult. Cleaning up and merging the blackfin fork or solving the autobuilder failures may not be a sufficiently well-defined project. Also there is some work for us: interviewing the students, mentoring, ... Thomas will write one or two topics. E.g.: incorporate blackfin support; improvements to test infrastructure.
* We iterated on the AVAILABLE problem once more, and concluded once more that none of the solutions is fully satisfying. The extra AVAILABLE options don't solve the comments - and we really want the comments. Replacing the comments with some generic statement that the required toolchain options are not available is not enough, because it's almost impossible to see which toolchain options you need. The best compromise is to have a script that checks if the dependencies and the comments are inconsistent, but it's not clear how easy it would be to create such a script - perhaps with the [[[https://github.com/ulfalizer/Kconfiglib]] python-kconfig] it's doable. The script could even automatically modify the Config.in in a later stage.
* Patchwork: at FOSDEM, Wolfram Sang mentioned some scripts that he uses to integrate patchwork into his git workflow. Peter is already using that to automate getting patches from patchwork and updating the patch status when it is pushed.
* Flags in external toolchain wrapper. The source of this discussion is the Cavium toolchain which requires an additional linker option to link correctly. Note that this is only about compile/link flags that are strictly needed for compiling for the right target, so typically things like -mfpu. The conclusion is that we want:
** For toolchains built by buildroot (internal, ct-ng), the toolchain configuration itself should already have the right options.
** For external toolchains downloaded by buildroot, buildroot should add the correct flags in the toolchain wrapper to do the right thing.
** For custom external toolchains, there should be a free-text config option that is coded into the toolchain wrapper.
** The BR2_TARGET_OPTIMIZATION option should be renamed to something more sensible, and only be used in TARGET_CFLAGS (not in the wrapper).

==== Action point list ====
* post-build script documentation (Yann E. MORIN)
* merge the staging and target install steps, and have all packages installed to both the staging and target directories
* add in the manual references to previous Buildroot related talks (slides and videos, Thomas)
* Add documentation for "Integration into a development workflow" (Arnout, hopefully others too)
* Documentation: make it clear that buildroot is not a distro (no policy), make it clear what buildroot's niche is compared to e.g. emdebian
* Implement automatic fetching of package's VCS HEAD
* Resend post-image patch set with just the minor comments fixed (Thomas, to be done for 2013.02)
* Write a bit of documentation that documents how to add a minimal board support (Thomas)
* Identify buildroot forks and put them on the website or wiki
* Handling of make xxx-menuconfig
* Split package/Config.in into 35 separate files, e.g. Config.in.lib.crypto (Arnout ?)
* Set up a daily or weekly build of the Git version of the manual (Peter. Really this time.)
* Patches: don't look at the version number anymore, just apply <pkgname>-*.patch (Peter)
* Apply <pkg>_CONFIG_FIXUP patch (Peter)
* Test if removing .la files works (Samuel)
* Refresh the package-create-user patchset (Yann) and commit (Peter)
* Commit pkg-infra: limit -reconfigure and -rebuild actions patch (Peter)
* In the next release announcement, mention the Eclipse plugin (Peter)
* Further improve the tzdata series: fix the duplicate POSIX zones, add a more fine-grained zone selection, add an option to set the local timezone (Yann) (partially done)
* Thomas asks Maxime R. if he can have a look at updating systemd/udev, preferably using the udev that is part of systemd.
* Fix passing random flags to external toolchain wrapper, and rename BR2_TARGET_OPTIMIZATION.
* Change of the patch logic
** For the patches stored in the package directory, if package/<pkg>/<version>/ does exist, apply package/<pkg>/<version>/*.patch, otherwise, apply package/<pkg>/*.patch
** For the patches stored in the global patches directory, if $(GLOBAL_PATCH_DIR)/<pkg>/<version>/ does exist, apply $(GLOBAL_PATCH_DIR)/<pkg>/<version>/*.patch, otherwise, apply $(GLOBAL_PATCH_DIR)/<pkg>/*.patch

==== Topics for the hackaton day (Tuesday 2013-02-05) ====

* help triage the pending patches
** Create scripts to help the triaging process
** More people with patchwork write access?

That was all that was actually done (we still had a lot of discussion). The following topics are still interesting for future reference:

* design (and implement) changes discused the previous day (eg. infrastructure enhancements)
* test and upstream changes discused the previous day (pending infrastructure changes and packages)
* update the crosstool-NG backend
* Fix iso9660 fs
* Document the Buildroot policy decisions (about out-of-tre packages, about package manager support, about cleaning, ...) (Arnout)
* Document use cases (as discussed yesterday)

Buildroot:DeveloperDaysFOSDEM2013

2013-02-05T16:22:22Z

Arnout Vandecappelle: Add report

== Buildroot Developers Meeting, 4-5 February 2013, Brussels ==

=== What is Buildroot ? ===

[http://buildroot.org 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.

=== Thanks to our sponsor Google ===

[[File:google-logo.png|right]]We would like to thank [http://www.google.com Google], who will be providing the meeting location, with Internet connection, but also free lunch and refreshments for the meeting participants. Thanks Google!

It is worth noting that 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].

=== Location and date ===

The Buildroot community is organizing a meeting on Monday February 4th 2013 and Tuesday Feburary 5th 2013, for Buildroot developers and contributors. This meeting will be a mixture of discussion and hacking session around the Buildroot project. This meeting takes place right after the [http://www.fosdem.org FOSDEM], in order to make it easy for participants to attend both events.

Note that it is not mandatory to attend both days. It is expected that the first day will be mostly dedicated to discussion, while the second day will be mostly dedicated to hacking.

The meeting will take place in Google Brussels offices, located Chaussée d'Etterbeek 180, 1040 Brussels. See http://goo.gl/maps/ZVAGJ for a map of the area.

=== Participants ===

# [[User:ThomasPetazzoni|Thomas Petazzoni]], confirmed. Arriving on February, 1st at 19:45 at BRU airport, leaving on February, 5th at 21:10 from BRU airport.
# [[User:Ymorin|Yann E. MORIN]], confirmed. Arriving 2013-02-01 17:23 at Bruxelles Midi, leaving on 2013-02-05 17:13 from Bruxelles Midi.
# [[User:PeterKorsgaard|Peter Korsgaard]], confirmed. Lives close by.
# [[User:Arnout_Vandecappelle|Arnout Vandecappelle]], confirmed. Lives even closer by.
# [[User:SamuelMartin|Samuel Martin]], confirmed. Arriving on February, 2nd at 08:47 at Bruxelles Midi, leaving on February, 5th at 19:13 from Bruxelles Midi.
# Dimitrios Siganos, attending on Monday only.
# [[User:ThomasDeSchampheleire|Thomas De Schampheleire]], confirmed. Lives close by.

=== Registration ===

Please contact Thomas Petazzoni (thomas.petazzoni@free-electrons.com) if you would like to attend.

Attending the event is free, but registration is required.

Note that the event is mainly intended for Buildroot developers and contributors, or advanced users willing to contribute more or to share about their use case for Buildroot.

=== List of topics to discuss ===

Good starting points are:
* [[Buildroot:DeveloperDaysELCE2012#Report_of_the_meeting|Report of the ELCE 2012 Buildroot meeting]]
* [[Buildroot:DeveloperDaysELCE2012#List_of_topics_to_discuss|ELCE 2012 List of topics]]

==== Topics for the discussion day (Monday 2013-02-04) ====

* Topics related to changes to the infrastructures
** current state of the infrastructure, and how to enhance it
*** copy target/ before creating images
*** handling of linux-menuconfig, busybox-menuconfig, uclibc-menuconfig, etc.
*** Refactoring package menus (Arnout)
*** Support for out-of-tree packages (Arnout)
*** Switch to ct-ng as the default backend for toolchain building
** pending series enhancing the infrastructure
*** [http://lists.busybox.net/pipermail/buildroot/2013-January/065603.html post-image-script]
*** [http://lists.busybox.net/pipermail/buildroot/2013-January/065174.html <pkg>_CONFIG_FIXUP]
*** [http://lists.busybox.net/pipermail/buildroot/2013-January/065879.html build out-of-package-dir]
*** [http://lists.busybox.net/pipermail/buildroot/2013-January/065410.html package-create-user]
*** [http://lists.busybox.net/pipermail/buildroot/2012-December/063482.html pkg-infra: limit -reconfigure and -rebuild actions]
* Topics related to the packages included in Buildroot
** finally remove the 'devel-on-target' packages ?
** host-pkgconf and "host-autotools" as visible host packages (Eclipse/app dev)?
** new packages pending
*** [http://lists.busybox.net/pipermail/buildroot/2013-January/064945.html tzdata et al.]
*** What to do with systemd/udev/eudev
* How are we doing? (Arnout)
** Is the project sufficiently stable?
** Do we have enough users, contributors?
** Are there threats we should care about?
** Is there a new important direction for which we lack support?
* [http://lists.busybox.net/pipermail/buildroot/2013-January/064646.html Building a fully configured project]
* Wild idea: [http://maemo.gitorious.org/scratchbox2/pages/Home scratchbox2]
* Giving a status on autobuilder improvements / website improvements (Thomas)
* Wild idea: for VCS site methods where version is HEAD or a branch, BR checks every time if the upstream has changed. This is to track the development made by team mates: your own work is in a OVERRIDE_SRCDIR, other libraries/dependencies are in a VCS method and are automatically updated. Question: how to expose this feature to the user? Addition kconfig option per package? Additional variable in local.mk? Something else?
* Wild idea: make it possible to configure some things per package, like optimisation/debug flags, static library, ... - this would require serious modification to Kconfig or a meta-kconfig.
* Provide a (nightly|weekly)-built manual from master. (Yann)
* Use kconfig-frontends ? (Yann)
* Remove the wget et al config options (Arnout)
* Google Summer of Code 2013 (Thomas)
* Patchwork maintenance, how to deal with pending patches (Arnout)

==== Discussion ====
* Copy target before creating images: the idea is to avoid the need for creating idempotent scripts in e.g. post-build script. It does make sense, because for the user it's a bit more difficult to make scripts idempotent. Also it can be a step for hiding the "target" directory. And it makes complete sense if we remove the "target" directory completely and copy from staging instead.
** The compelling reason to make target a subset of staging is that it is much easier to do debugging: just "gdb staging/usr/bin/foo" and it will have debug symbols and the paths to the source files.
** Single install commands: FOO_INSTALL_CMDS. They get executed twice, with DESTDIR set to the correct place (target or staging or host). The POST_XXX_INSTALL_HOOKS would still be executed separately. But this doesn't yet give us the situation that target and staging are the same, but target just has some stuff removed.
** Take it one step at the time: start with FOO_INSTALL_CMDS, we can see how far we get.
** Document that post-build script has to be idempotent (with an example).
* There was a lot of discussion about using buildroot in practice in different contexts. Add to documentation a section of how to use buildroot in practice. Maybe in the form of one or more use case - but not too many because it would just confuse users. For instance, assume that proprietary patches are in-tree in package/companyname, not out-of-tree. The chapter would be called "Integration into a development workflow".
* There is a consensus that buildroot should not be just an integration platform, but also usable in development. However, we should never sacrifice the simplicity, and integration has to remain the main focus. The out-of-tree package build is a good example, as well as the automatic fetching of VCS HEAD.
* Add chapter to manual to explain the internals of buildroot. Not so much the existing implementation, but rather the design choices.
* post-image script: good thing is that it can be included in a defconfig, so accept it. Post-image script (just like post-build script) will not run in fakeroot.
* Stable releases: the consensus is that it is a lot of effort and nobody would use it.
* Users and contributors: contributors are still increasing, number of users we don't really know but probably pretty high.
* Threats:
** The number of forks of buildroot. We're missing out on contributors, and if it doesn't work well we loose credibility. For instance, armadeus doesn't upstream anything (no kernel, u-boot, buildroot) - for them there is no hope. But for instance also RPi has a buildroot fork on github. Maybe it would help if we would have an official repository on github (github can be setup to automatically pull form the official repository). If we really want, we could pull patches from the repositories that we know about. A fork that just adds a defconfig and a few feature patches is not a big deal, on condition that they are kept up to date.
** Flash sizes are increasing, so the size advantage of buildroot is not much of an advantage anymore. Compared to e.g. emdebian, there are two more advantages:
*** much more understandable what happens at boot time and what exactly is installed, there's no predefined policy;
*** you have a top-level integration of the entire rootfs+kernel+bootloader from the start;
*** easy to learn for someone not familiar with Debian or Linux distros or system administration.
* Thomas would like to add testimonials and a list of users of buildroot to the website.
* Next big directions for buildroot
** SoC-specific libraries (OpenGL) are a pain: packages that use them need to somehow find them. We can use a virtual package mechanism like for jpeg (but then a bit different) and e.g. Qt5 depends on that virtual package.
** Switching to ct-ng as the default toolchain backend has been in the plans for several years. But since it's not the default backend it isn't getting a lot of attention (example: for several months it was broken, libraries were not copied to the target, and it took a lot of time for somebody to notice).
*** Issue #1: passing subarch variants to crosstool-ng. Shouldn't be a big problem to solve, just a matter of work.
*** Issue #2: download integration. Crosstool-NG cannot tell Buildroot what it needs, so Buildroot can't download it, which breaks things like "make source" and "make external-deps". This requires a number of changes in Crosstool-NG: Crosstool-NG doesn't know the exact URL for each component, doesn't yet have a capability to list which tarballs are needed (similar to "external-deps"). It has the capability of doing the download only, but it requires configure and installing crosstool-NG. Which means that "make source" in Buildroot would need to build Crosstool-NG and all its dependencies (host-gawk, host-libtool, host-autoconf, host-automake). This problem requires more work at the Crosstool-NG level.
*** Issue #3: legal info integration.
*** Option 1: keep only external toolchain backend. Consensus is that this is not acceptable, Buildroot should still have a way of building toolchains on its own.
*** Option 2: work on the Crosstool-NG backend to fix all the integration issues, and use it as the default backend.
*** Option 3: improve the internal backend, and assume that we don't really need an integration with Crosstool-NG.
*** Conclusion: Yann gets time till 2013.05 to work on issue #2. If that is successful or is making good progress, we go for Option 2. If it is going nowhere, we go for Option 3 or option 1.
* Handling of make xxx-menuconfig
** The last proposal on the list was to store the xxx-config files in the output directory, and don't remove them with make clean. However, if you delete the output directory that will still be gone.
** Instead, it can directly be saved to the configured place (e.g. boards/mycompany/myboard/xxx-config) instead of requiring an explicit 'make xxx-saveconfig' step. Potential problem: do we save a defconfig or a full config? Linux defconfig only exists since 2.6.26 or so and is sometimes buggy...
** We can disallow linux-menuconfig in case the BR2_LINUX_USE_CUSTOM_CONFIG is not set, and issue a warning. Combine that with automatically saving and we have a pretty complete solution.
** Conclusion: copy it back to the configured place, disallow xxx-menuconfig unless something is configured. We always save full config because defconfig is not always reliable.
* Splitting package/Config.in into separate files for each menu is a good idea for several reasons:
** In patches adding a package, it's obvious in which menu it is added
** Scripts can automatically find out in which menu a package is, e.g. to generate the package list in the manual
* Out of tree package build
** It's mainly needed for the kernel
** But it's also nice for the 600 other packages that support it out of the box.
** Risk of breakage, but can easily be solved by setting SUPPORTS_OUT_OF_TREE to NO
** Makes it slower for some large packages that don't support out-of-tree build, but also saves time for some others.
** Conclusion: the series still needs some work, but we do like out-of-tree package builds.
* Some .la files in the staging directory contain wrong information: paths to the build directory instead of the staging directory. Samuel proposes to remove the .la files. This needs some testing first, though.
* Devel-on-target packages are not removed quite yet. But more packages can be marked as deprecated.
* What to do with systemd/udev/eudev: we try to use the udev from systemd without systemd. Exactly how we don't know yet... There's a risk that udev becomes unusable without systemd, but Leonard Poettering promised this would not happen. After a quick look, it turns out that you always end up building systemd, which requires dbus, even if you need only udev. So it makes the systemd source tarball a bit unpractical to build a system that uses udev only, and doesn't need systemd. Probably an indication that we should have a look at eudev? How would this interact with the systemd selection? What about incompatibilities between udev and eudev?
* Building a fully configured project: the question is: what is the workflow for creating a buildroot-based distribution which has a lot more than just the defconfig, and you don't want to fork the buildroot repository. Answer: fork the buildroot tree, but merge regularly.
* Autobuilder status: Thomas will move the info to a database, and has some very basic webpages for accessing the database. He also dreams about running some tests in qemu - but we already have enough failures with the autobuilders as they are :-)
* Remove the wget et al config options (Arnout): these options are indeed useless, especially because dependencies.sh looks for "git", not BR2_GIT. But in fact, the whole "Build options" menu could use some refactoring.
* scratchbox2: may make life simpler to support cross-compiling. scratchbox2 does LD_PRELOAD magic to make sure that /usr/include and /usr/lib point into the sysroot instead of the host. It also runs foreign executables in qemu. However, Thomas (who used scratchbox before) was not impressed by it. It will probably also run into the kernel headers problems we had with cpanminus/qemu. Bottom line: it can be used if some package requires it, but in the end we will still have to solve cross-compilation issues.
* Use kconfig-frontends: we would clone it into buildroot, just like we currently do. Advantage of current kconfig-frontends is that it has some possibilities for tweaking the config executable, so that we need less or no patches. Still it's a bit of work to integrate. One problem is that it now has a configure script, which checks for flex, bison, gperf, and we want to bypass this in buildroot. We will create our own Makefile (just like we do now) and we'll check in the files generated by flex, bison, gperf. Yann doesn't have a lot of time to work on this.
* GSoC: student works 3 months full-time on a project. Google has to accept it, so it has to be somehow innovative and end up with a product. Core infrastructure work is probably not a good idea, because it's too difficult. Cleaning up and merging the blackfin fork or solving the autobuilder failures may not be a sufficiently well-defined project. Also there is some work for us: interviewing the students, mentoring, ... Thomas will write one or two topics. E.g.: incorporate blackfin support; improvements to test infrastructure.
* We iterated on the AVAILABLE problem once more, and concluded once more that none of the solutions is fully satisfying. The extra AVAILABLE options don't solve the comments - and we really want the comments. Replacing the comments with some generic statement that the required toolchain options are not available is not enough, because it's almost impossible to see which toolchain options you need. The best compromise is to have a script that checks if the dependencies and the comments are inconsistent, but it's not clear how easy it would be to create such a script - perhaps with the [[[https://github.com/ulfalizer/Kconfiglib]] python-kconfig] it's doable. The script could even automatically modify the Config.in in a later stage.
* Patchwork: at FOSDEM, Wolfram Sang mentioned some scripts that he uses to integrate patchwork into his git workflow. Peter is already using that to automate getting patches from patchwork and updating the patch status when it is pushed.
* Flags in external toolchain wrapper. The source of this discussion is the Cavium toolchain which requires an additional linker option to link correctly. Note that this is only about compile/link flags that are strictly needed for compiling for the right target, so typically things like -mfpu. The conclusion is that we want:
** For toolchains built by buildroot (internal, ct-ng), the toolchain configuration itself should already have the right options.
** For external toolchains downloaded by buildroot, buildroot should add the correct flags in the toolchain wrapper to do the right thing.
** For custom external toolchains, there should be a free-text config option that is coded into the toolchain wrapper.
** The BR2_TARGET_OPTIMIZATION option should be renamed to something more sensible, and only be used in TARGET_CFLAGS (not in the wrapper).

==== Action point list ====
* post-build script documentation (Yann E. MORIN)
* merge the staging and target install steps, and have all packages installed to both the staging and target directories
* add in the manual references to previous Buildroot related talks (slides and videos, Thomas)
* Add documentation for "Integration into a development workflow" (Arnout, hopefully others too)
* Documentation: make it clear that buildroot is not a distro (no policy), make it clear what buildroot's niche is compared to e.g. emdebian
* Implement automatic fetching of package's VCS HEAD
* Resend post-image patch set with just the minor comments fixed (Thomas, to be done for 2013.02)
* Write a bit of documentation that documents how to add a minimal board support (Thomas)
* Identify buildroot forks and put them on the website or wiki
* Handling of make xxx-menuconfig
* Split package/Config.in into 35 separate files, e.g. Config.in.lib.crypto (Arnout ?)
* Set up a daily or weekly build of the Git version of the manual (Peter. Really this time.)
* Patches: don't look at the version number anymore, just apply <pkgname>-*.patch (Peter)
* Apply <pkg>_CONFIG_FIXUP patch (Peter)
* Test if removing .la files works (Samuel)
* Refresh the package-create-user patchset (Yann) and commit (Peter)
* Commit pkg-infra: limit -reconfigure and -rebuild actions patch (Peter)
* In the next release announcement, mention the Eclipse plugin (Peter)
* Further improve the tzdata series: fix the duplicate POSIX zones, add a more fine-grained zone selection, add an option to set the local timezone (Yann) (partially done)
* Thomas asks Maxime R. if he can have a look at updating systemd/udev, preferably using the udev that is part of systemd.
* Fix passing random flags to external toolchain wrapper, and rename BR2_TARGET_OPTIMIZATION.
* Change of the patch logic
** For the patches stored in the package directory, if package/<pkg>/<version>/ does exist, apply package/<pkg>/<version>/*.patch, otherwise, apply package/<pkg>/*.patch
** For the patches stored in the global patches directory, if $(GLOBAL_PATCH_DIR)/<pkg>/<version>/ does exist, apply $(GLOBAL_PATCH_DIR)/<pkg>/<version>/*.patch, otherwise, apply $(GLOBAL_PATCH_DIR)/<pkg>/*.patch

==== Topics for the hackaton day (Tuesday 2013-02-05) ====

* help triage the pending patches
** Create scripts to help the triaging process
** More people with patchwork write access?
* design (and implement) changes discused the previous day (eg. infrastructure enhancements)
* test and upstream changes discused the previous day (pending infrastructure changes and packages)
* update the crosstool-NG backend
* Fix iso9660 fs
* Document the Buildroot policy decisions (about out-of-tre packages, about package manager support, about cleaning, ...) (Arnout)
* Document use cases (as discussed yesterday)
* ...

=== Report ===
http://lite.framapad.org/p/buildrootdeveloperday2013

Buildroot:DeveloperDaysFOSDEM2013

2013-02-04T09:56:35Z

Arnout Vandecappelle:

Buildroot:DeveloperDaysFOSDEM2013

2013-02-04T09:50:21Z

Arnout Vandecappelle: /* Topics for the hackaton day (Tuesday 2013-02-05) */

Buildroot:DeveloperDaysFOSDEM2013

2013-02-03T22:58:50Z

Arnout Vandecappelle:

Buildroot:DeveloperDaysFOSDEM2013

2013-02-03T15:08:26Z

Arnout Vandecappelle: More topics for discussion and hacking

Buildroot:DeveloperDaysFOSDEM2013

2013-02-03T12:01:33Z

Arnout Vandecappelle: More topics for discussion and hacking

Buildroot:DeveloperDaysFOSDEM2013

2013-02-03T11:54:09Z

Arnout Vandecappelle: /* Topics for the discussion day (Monday 2013-02-04) */ Added a few topics

Buildroot:DeveloperDaysFOSDEM2013

2013-01-07T20:54:08Z

Arnout Vandecappelle: /* Participants */

Buildroot:DeveloperDaysFOSDEM2013

2013-01-03T08:55:48Z

Arnout Vandecappelle: /* Participants */

ELC 2012 Presentations

2012-11-06T18:17:40Z

Arnout Vandecappelle: /* Presenters */

Presenters, Demo-ers, Participants:
Thanks very much for your participation in Linux Foundation's [https://events.linuxfoundation.org/events/embedded-linux-conference Embedded Linux Conference 2012].

This page is for collecting the presentations that were made at the conference. During and
after the conference we will collect materials from the presenters and place them here.
Please watch this page if you are interested in a particular presentation - and if it
doesn't show up, please [[Special:EmailUser/Wmat | send me and email]] and we'll try to track it down.

== Videos ==

Videos for ELC2012 from the Linux Foundation can be found at [http://video.linux.com/categories/2012-embedded-linux-conference ELC2012 Videos].

In addition, Free Electrons has also provided video of Andoid builders Summit talks, and ELC talks:

[http://free-electrons.com/blog/abs-2012-videos/ Android Builders Summit] 
[http://free-electrons.com/blog/elc-2012-videos/ ELC]

== Instructions ==
'''Presenters:''' Please post your technical conference presentations on this page.
(See Instructions below the tables)

= Table of Presentations =

NOTE: If you add a wikilink to your presentation and attempt to upload it via the link, it may fail. If it does, use the [[Special:Upload]] page to upload your file.

== Keynotes ==
{| border="1" cellspacing="0" cellpadding="4"
|- bgcolor="#c0e0e0"
|+ '''Keynotes'''
|- bgcolor="#c0e0e0"
| align="center" | '''Presenter(s)'''
| align="center" | '''Session Description'''
| align="center" | '''Presentation'''
| align="center" | '''Transcript Status'''
|-
| Jon Corbett, Editor at LWN.net
| The Kernel Report
| [[Media:lf_elc12_corbet.pdf | The Kernel Report ELC2012]]
|
|-
| Mike Anderson, CTO at The PTR Group
| [[Session:The Internet of Things|The Internet of Things]]
| [[Media:anderson.pdf | The Internet of Things]]
| in progress
|}

 

== Presenters ==
{| border="1" cellspacing="0" cellpadding="4"
|- bgcolor="#c0e0e0"
|+ '''Presentations'''
|- bgcolor="#c0e0e0"
| align="center" | '''Presenter(s)'''
| align="center" | '''Session Description'''
| align="center" | '''Presentation'''
| align="center" | '''Transcript Status'''
|-
|- bgcolor="#a0c0c0"
| colspan="4" | Day 1, 9:30am
|-
| Loïc Pallardy
| Saving the Power Consumption of the Unused Memory
| [[Media:lf_elc12_pallardy.pdf|PDF]]
|-
| Bernhard Rosenkränzer, Linaro
| What Android and Embedded Linux Can Learn From Each Other
| [[Media:lf_elc12_rosenkranzer.pdf|PDF]]
|-
| Ricardo Salveti de Araujo, Linaro
| Ubuntu on ARM: Improvements and Optimizations Done By Linaro
| [[Media:Ubuntu_on_ARM-_Improvements_and_Optimizations_Done_By_Linaro.pdf|PDF]]
|- bgcolor="#a0c0c0"
| colspan="3" | Day 1, 11:30am
|-
| Zach Pfeffer, Linaro
| Binary Blobs Attack
| [[Media:lf_elc12_pfeffer.pdf|PDF]]
|-
| Hisao Munakata, Renesas Electronics
| Close Encounters of the Upstream Resource
| [[Media:lf_elc12_munakata.pdf|PDF]]
|-
| Daniel Hursh, IBM
| Open Source Automated Test Framework
| [[Media:lf_elc12_hursh.pdf|PDF]]
|- bgcolor="#a0c0c0"
| colspan="3" | Day 1, 2:00pm
|-
| Saul Wold, Intel
| The Yocto Project Overview and Update
| [[Media:The Yocto Project Overview and Update.pdf|PDF]]
|-
| Sean Hudson, Mentor Graphics, Inc.
| Embedded Linux Pitfalls
| [[Media:Embedded Linux Pitfalls.pdf|PDF]]
|-
| Vincent Guittot, Linaro
| Comparing Power Saving Techniques For Multicore ARM Platforms
| [[Media:Comparing Power Saving Techniques For Multicore ARM Platforms.pdf|PDF]]
|-
|- bgcolor="#a0c0c0"
| colspan="3" | Day 1, 3:00pm
|-
|-
| Tim Bird, Sony Network Entertainment
| Status of Embedded Linux
| [[Media:Status-of-embedded-Linux-2012-02-ELC-v2.pdf|PDF]]
|-
| Bruce Ashfield, Wind River
| A View From the Trenches: Embedded Functionality and How It Impacts Multi-Arch Kernel Maintenance
| [[Media:A_View_From_the_Trenches-_Embedded_Functionality_and_How_It_Impacts_Multi-Arch_Kernel_Maintenance.pdf‎|PDF]]
|-
| R Durgadoss, Intel
| PeakCurrent Management in x86-Based Smartphones
| [[Media:PeakCurrent Management in x86-Based Smartphones.pdf|PDF]]
|- bgcolor="#a0c0c0"
| colspan="3" | Day 1, 4:15pm
|-
| Matt Porter, Texas Instruments
| Passing Time With SPI Framebuffer Driver
| [[Media:Passing Time With SPI Framebuffer Driver.pdf|PDF]]
|-
| Wookey, Linaro
| Multiarch and Why You Should Care: Running, Installing and Crossbuilding With Multiple Architectures
| [[Media:Multiarch_and_Why_You_Should_Care-_Running,_Installing_and_Crossbuilding_With_Multiple_Architectures.pdf|PDF]] [[Media:SourceCode.tgz|SOURCE]]
|-
| Amit Daniel Kachhap, Linaro/Samsung
| A New Simplified Thermal Framework For ARM Platforms
| [[Media:A New Simplified Thermal Framework For ARM Platforms.pdf|PDF]]
|-
|- bgcolor="#a0c0c0"
| colspan="3" | Day 1, 5:15pm
|-
|-
| Tsugikazu Shibata, NEC
| On The Road: To Provide the Long-Term Stable Linux For The Industry
| [[media:On_The_Road-_To_Provide_the_Long-Term_Stable_Linux_For_The_Industry.pdf|PDF]]
|-
| Thomas P. Abraham, Samsung Electronics
| Experiences With Device Tree Support Development For ARM-Based SOC's
| [[Media:Experiences With Device Tree Support Development For ARM-Based SOC's.pdf|PDF]]
|-
| Paul E. McKenney, IBM
| [[Session:Making RCU Safe For Battery-Powered Devices ELC2012|Making RCU Safe For Battery-Powered Devices]]
| [[media:Making RCU Safe For Battery-Powered Devices.pdf|PDF]]
| in progress (0:00 - 6:59)
|- bgcolor="#a0c0c0"
| colspan="3" | Day 2, 10:30am
|-
| Thomas Petazzoni, Free Electrons
| Buildroot: A Nice, Simple, and Efficient Embedded Linux Build System
| [[Media:Buildroot2.pdf|PDF]]
|-
| Steven Rostedt, Red Hat
| Automated Testing with ktest.pl (Embedded Edition)
| [[Media: Automated Testing with ktest.pl (Embedded Edition).pdf|PDF]]
|-
| David VomLehn, Cisco
| Intricacies of a MIPS Stack Backtrace Implementation
| [[Media:Intricacies of a MIPS Stack Backtrace Implementation.pdf|PDF]]
|-
|- bgcolor="#a0c0c0"
| colspan="3" | Day 2, 11:30am
|-
| Edward Hervey, Collabora
| GStreamer 1.0: No Longer Compromise Flexibility For Performance
| [[Media:GStreamer_1.0-_No_Longer_Compromise_Flexibility_For_Performance.pdf|PDF]]
|-
| Steven Rostedt, Red Hat
| Automated Testing with ktest.pl (Embedded Edition) (Cont.)
| [[Media: Automated Testing with ktest.pl (Embedded Edition).pdf|PDF]]
|-
| Tim Bird, Sony Network Entertainment
| Embedded-Appropriate Crash Handling in Linux
| [[Media:Embedded-Appropriate Crash Handling in Linux.pdf|PDF]]
|-
|- bgcolor="#a0c0c0"
| colspan="3" | Day 2, 2:00pm
|-
| Arnd Bergmann, Linaro
| ARM Subarchitecture Status
| [[Media:ARM Subarchitecture Status.pdf|PDF]]
|-
| Mark Gisi, Wind River Systems
| The Power of SPDX - Sharing Critical Licensing Information Within a Linux Device Supply Chain
| [[Media:The Power of SPDX - Sharing Critical Licensing Information Within a Linux Device Supply Chain.pdf|PDF]]
|-
| Yoshitake Kobayashi, Toshiba
| Ineffective and Effective Ways To Find Out Latency Bottlenecks With Ftrace
| [[Media:Ineffective and Effective Ways To Find Out Latency Bottlenecks With Ftrace.pdf|PDF]]
|-
|- bgcolor="#a0c0c0"
| colspan="3" | Day 2, 3:00pm
|-
| Ohad Ben-Cohen, Wizery / Texas Instruments
| Using virtio to Talk With Remote Processors
| [[Media:Using virtio to Talk With Remote Processors.pdf|PDF]]
|-
| Elizabeth Flanagan, Intel
| Embedded License Compliance Patterns and Antipatterns
| [[Media:Embedded License Compliance Patterns and Antipatterns.pdf|PDF]]
|-
| David Anders, Texas Instruments
| Board Bringup: LCD and Display Interfaces
| [[elc-lcd|PDF]]
|-
|- bgcolor="#a0c0c0"
| colspan="3" | Day 2, 4:15pm
|-
| Rob Clark, Texas Instruments
| DMA Buffer Sharing: An Introduction
| [[Media:DMA_Buffer_Sharing-_An_Introduction.pdf|PDF]]
|-
| Ken Tough, Intrinsyc
| Linux on eMMC: Optimizing For Performance
| [[Media:Linux_on_eMMC-_Optimizing_For_Performance.pdf|PDF]]
|-
| Paul Larson, Linaro
| LAVA Project Update
| [[Media:LAVA Project Update.pdf|PDF]]
|-
|- bgcolor="#a0c0c0"
| colspan="3" | Day 2, 5:15pm
|-
| Jeff Osier-Mixon, Intel
| Yocto Project Community (BoFs)
| No Slides
|-
| Frank Rowand, Sony Network Entertainment
| Real Time (BoFs)
| [[Media:Real Time (BoFs).pdf|PDF]]
|-
| Mike Turquette, Texas Instruments
| Common Clock Framework (BoFs)
| [[Media:Common Clock Framework (BoFs).pdf|PDF]]
|-
|- bgcolor="#a0c0c0"
| colspan="3" | Day 3, 9:00am
|-
| Hunyue Yau, HY Research LLC
| Userland Tools and Techniques For Linux Board Bring-Up and Systems Integration
| [[Media:Userland Tools and Techniques For Linux Board Bring-Up and Systems Integration.pdf|PDF]]
|-
| Matt Weber, Rockwell Collins Inc.
| Optimizing the Embedded Platform Using OpenCV
| [[Media:Optimizing the Embedded Platform Using OpenCV.pdf|PDF]]
|-
| Greg Ungerer, McAfee
| M68K: Life in the Old Architecture
| [[Media:M68K-_Life_in_the_Old_Architecture.pdf|PDF]]
|- bgcolor="#a0c0c0"
| colspan="3" | Day 3, 10:00am
|-
| Gary Bisson, Adeneo Embedded
| Useful USB Gadgets on Linux
| [[Media:Useful USB Gadgets on Linux.pdf|PDF]]
|-
| Jason Kridner, Texas Instruments
| GUIs: Coming To Uncommon Goods Near You
| [[Media:Guis_coming_to_uncommon_goods.pdf|PDF]]
|-
| Mike Anderson, The PTR Group
| Adapting Your Network Code For IPv6 Support
| [[Media:Adapting Your Network Code For IPv6 Support.pdf|PDF]]
|- bgcolor="#a0c0c0"
| colspan="3" | Day 3,11:30pm
|-
| Koen Kooi, The Angstrom Distribution
| Producing the Beaglebone and Supporting It
| No Paper - see video
|-
| Danny Bennett, basysKom GmbH
| HTML5 in a Plasma-Active World
| [[Media:HTML5 in a Plasma-Active World.pdf|PDF]]
|-
| Marcin Mielczarczyk, Tieto
| Getting the First Open Source GSM Stack in Linux
| [[Media:Getting the First Open Source GSM Stack in Linux.pdf|PDF]]
|- bgcolor="#a0c0c0"
| colspan="4" | Day 3, 2:00pm
|-
|-
| Pierre Tardy, Intel
| PyTimechart Practical
|[[Media:PyTimechart Practical.pdf|PDF]]
|-
| Linus Walleij, ST-Ericsson
| Pin Control Subsystem Overview
| [[Media:Pin Control Subsystem Overview.pdf|PDF]]
|-
| Khem Raj, OpenEmbedded Project
| OpenEmbedded - A Layered Approach
| [[Media:OpenEmbedded - A Layered Approach.pdf|PDF]]
|- bgcolor="#a0c0c0"
| colspan="3" | Day 3, 3:00pm
|-
| Lucas De Marchi, ProFUSION Embedded Systems
| Managing Kernel Modules With kmod
| [[Media:Managing Kernel Modules With kmod.pdf|PDF]]
|-
| Jean Pihet, NewOldBits
| A New Model for the System and Devices Latency
| [[Media:A New Model for the System and Devices Latency.pdf|PDF]]
|-
| Pintu Kumar, Samsung
| Controlling Linux Memory Fragmentation and Higher Order Allocation Failure: Analysis, Observations and Results
| [[Media:Controlling_Linux_Memory_Fragmentation_and_Higher_Order_Allocation_Failure-_Analysis,_Observations_and_Results.pdf|PDF]]
| in-progress
|}

 

== Workshops ==
{| border="1" cellspacing="0" cellpadding="4"
|- bgcolor="#c0e0e0"
|+ '''Workshops'''
|- bgcolor="#c0e0e0"
| align="center" | '''Presenter(s)'''
| align="center" | '''Session Description'''
| align="center" | '''Presentation'''
|-
|-
| Karim J. Yaghmour
| Embedded Android Workshop
| [[Media:Android Workshop.pdf|PDF]]
|-

|}

 

== Instructions for Presenters ==
Please create a link in the table for your presentation, copying the style of other links.
(You may need to create an account in order to edit the wiki or upload files.)

When you have created the link, click on it to upload the file containing your slides.
[[Category:ELC]]
[[Category:2012]]
[[Category:Events]]
[[Category:Presentations]]

Session:Making RCU Safe For Battery-Powered Devices ELC2012

2012-11-06T18:16:52Z

Arnout Vandecappelle: /* Transcript */

== Session Details ==
; Event : Embedded Linux Conference 2012
; Date : February 16, 2012
; Presenter : Paul E. McKenney
; Organization: IBM
; Slides : http://elinux.org/images/0/06/Making_RCU_Safe_For_Battery-Powered_Devices.pdf
; Video : [http://free-electrons.com/pub/video/2012/elc/elc-2012-mckenney-rcu-safe-battery-powered-devices-450p.webm Free Electrons (450x800)] or [http://free-electrons.com/pub/video/2012/elc/elc-2012-mckenney-rcu-safe-battery-powered-devices.webm Free Electrons (Full HD)] or [http://video.linux.com/videos/making-rcu-safe-for-battery-powered-devices Linux Foundation]
; Duration : 52:29

=== Abstract ===

Back in the 1990s, energy efficiency was not even on the list of RCU-related concerns. Systems using RCU at that time dealt with either large quantities of heavy equipment or large financial flows, so that the energy consumption of the entire server (let alone RCU's contribution) was way down in the noise. This situation changed dramatically with the 2002 introduction of RCU into the Linux kernel. Since then, RCU's energy-efficiency code has been rewritten more than five times. The most recent rewrite was motivated by workloads where RCU was leaving tens of percent of potential energy savings on the table. This talk will give a brief overview of how energy efficiency came to RCU, the current situation, future prospects, and generally applicable lessons learned.

=== Biography ===

Paul E. McKenney is a Distinguished Engineer with the IBM Linux Technology Center, where he maintains the RCU implementation within the Linux kernel. He has been coding for almost four decades, and more than half of that on parallel hardware. His prior lives include working on the DYNIX/ptx kernel at Sequent, work on packet radio, Internet protocols, and system administration at SRI International, and work on soft-realtime systems as a self-employed contract programmer. His hobbies include what passes for running at his age along with the usual house-wife-and-kids habit.

=== Notes ===

== Transcript ==
; Transcribed by: Arnout Vandecappelle (0:00 - 6:59)
; Verified by: 1 -

0:00 - 1:00: [slide 1 - title] [some pre-presentation chatting] >> PAUL MCKENNEY: [slide 2 - Overview] I'm going to go through a little obligatory what-is-RCU. At my age, you ''have'' to have at least some slide about "The Good Old Days", as a log [?] or something, and something about that. We'll take a look at RCU's many energy-efficiency variants over the years, the current state of its energy-efficiency, and of course future directions.

[slide 3 - What is RCU?] Now how many people here have actually written code that uses RCU? Good, we got some, great! Now how many people have ever viewed code that has calls to RCU in it?

1:00 - 2:00: Okay, a few more, good. How many people have heard of RCU before today? All right, that's good. Not so long ago [?] I wouldn't have seen any hands for that last one either. [remark from the audience] Yes, there was a time when I could have said yes to the first one and no to the last one, but that was long ago. Anyway.

[slide 4 - A very brief introduction to RCU] OK, let's go through it quickly. This is just a taste of it. I'll just take a few minutes to go through it. I have a slide at the end of this section that has a list of places to go to get more information. These slides are posted somewhere, they will be on my website as well.

If you only want to hear the number one sentence about RCU, the thing to remember is that first bullet there: RCU is a synchronization technique that is sometimes used in place of reader-writer locking. The reason that it's used in place of reader-writer locking is that it has extremely low read-side overhead. When I say extremely low, I mean that if you have a real linux kernel that's built with CONFIG_PREEMPT=n - without preemption - it will be zero.

2:00 - 3:00: And I mean ''zero'': <tt>#define rcu_read_lock()</tt> newline. So, the C preprocessor sees it, the compiler doesn't. Of course, "free" is a very good price, it gives you great performance scalability, real-time response.

The other nice thing about it, is something called hazard pointers. A guy named Maged Michael worked on this. You can have RCU readers making progress, and at the same time RCU writers making progress. So you can have a reader reading an item, while an updater is updating that same data item, and have something sensible happen. This makes for some very nice non-lockup and non-blockage techniques and properties.

The main place you want to use it is read-mostly data. I'll have a slide near the end that gives a "Go", "Wait", "Stop" kind of thing about where to use it. This is increasingly important.

3:00 - 4:00: There was a time, when I was the average age in this room, where, if you have a machine, and you wanted to plug a disk in it, you had to change lines in the source code of the kernel. Then you could bring down your system and plug your disk, and make sure you boot the kernel that has the change because otherwise it will panic coming up with the extra disk. And even worse if you take one out. Well, our machines are a bit more civilized these days, I can slide a memory stick in this thing any time I want, and it will pop it up and say "Hey, here's your disk, what do you want to do with it." What that means, is that a bunch of stuff that used to be stuck in the source code of the kernel is now data structures. Things like routing tables, security policies, storage configuration. These things almost never change. But they might change at any time. That's the sort of thing that RCU works really well for.

4:00 - 5:00: I will have a couple of slides showing specific operations for it. One thing is - I said up there that the readers can make progress even while you're changing data items, so, clearly you have to be able to take the thing and insert new data while the reader is going through the thing and have it all work out correctly. We'll look at that. Even more exciting is when you want to remove some data while a reader is charging [?] through your list or your data structure, and have that work out right. We'll take a look at how that works. Given that the readers aren't telling us anything - remember that you can have zero code for the reader - we need a way for the writers to figure out whether the readers are there or not, so they can do things without upsetting readers. We'll have a slide on that as well.

[slide 5 - Publication of And Subscription To New Data] This slide is talking about when you want to add new data to your data structure and present it to the readers. On this slide and the next slide, if you have something that's red, it means it's dangerous for updaters. Readers could be looking at it, new readers can show up at any time, we can't stop them, we don't even know they're there. So we have to be very careful for the things that are marked red.

Yellow (not on this slide but it will be on the next slide) is dangerous. There can't be any new readers getting to that piece of data, but there might be old ones still there.

5:00 - 6:00: And finally green is where the updater has full control over it, it can do what it wants.

We have time moving from left to right on this diagram. We're just showing the state of the system, with these arrows meaning a change. We have the global pointer red: any reader at any time can just go to this variable and grab it and does something. We don't know they're there, we don't know when they're showing up or when they're leaving, we can't stop them. What we want to do, is to get to this final state, where the global pointer is pointing to this data structure that's initialized in the way we want to. We want the readers to actually see the data structure in this state.

We take three steps. The first thing we do is we allocate the new data. We get this block of memory, we get a pointer to it, but readers can't get to it - there's no path to it. This is uninitialized, it's just garbage memory that kmalloc or whatever gave us. The next thing we do is, we initialize it.

6:00 - 7:00: Now it has some sensible data in it. Readers still can't reach to it, there's no way to get there. Once we're there, we use this primitive, <tt>rcu_assign_pointer()</tt>, which is essentially a glorified assignment statement. It's an assignment statement that does the change, including some architecture-specific instructions, needed to make sure that the readers see this [the new data structure] and not this [the old data]. If you don't use this special function but just use an equal sign - <tt>gptr = tmp</tt>, what can happen is that both the compiler and the CPU can change the order of things, which means these readers coming in might see garbage instead of the nice initialized stuff you want.

The readers have their own special sauce for their assignment statement. Instead of just saying "give me a copy", like <tt>localvar = gptr</tt>, they have to use <tt>rcu_dereference()</tt>, again, to prevent the compiler and in some cases the CPU from changing the code around and causing things to show up out of order.

7:00 - 8:00:

8:00 - 9:00:

9:00 - 10:00:

10:00 - 11:00:

11:00 - 12:00:

12:00 - 13:00:

13:00 - 14:00:

14:00 - 15:00:

15:00 - 16:00:

16:00 - 17:00:

17:00 - 18:00:

18:00 - 19:00:

19:00 - 20:00:

20:00 - 21:00:

21:00 - 22:00:

22:00 - 23:00:

23:00 - 24:00:

24:00 - 25:00:

25:00 - 26:00:

26:00 - 27:00:

27:00 - 28:00:

28:00 - 29:00:

29:00 - 30:00:

30:00 - 31:00:

31:00 - 32:00:

32:00 - 33:00:

33:00 - 34:00:

34:00 - 35:00:

35:00 - 36:00:

36:00 - 37:00:

37:00 - 38:00:

38:00 - 39:00:

39:00 - 40:00:

40:00 - 41:00:

41:00 - 42:00:

42:00 - 43:00:

43:00 - 44:00:

44:00 - 45:00:

45:00 - 46:00:

46:00 - 47:00:

47:00 - 48:00:

48:00 - 49:00:

49:00 - 50:00:

50:00 - 51:00:

51:00 - 52:00:

52:00 - 53:00:

Session:Making RCU Safe For Battery-Powered Devices ELC2012

2012-11-06T18:04:01Z

Arnout Vandecappelle: /* Transcript */

== Session Details ==
; Event : Embedded Linux Conference 2012
; Date : February 16, 2012
; Presenter : Paul E. McKenney
; Organization: IBM
; Slides : http://elinux.org/images/0/06/Making_RCU_Safe_For_Battery-Powered_Devices.pdf
; Video : [http://free-electrons.com/pub/video/2012/elc/elc-2012-mckenney-rcu-safe-battery-powered-devices-450p.webm Free Electrons (450x800)] or [http://free-electrons.com/pub/video/2012/elc/elc-2012-mckenney-rcu-safe-battery-powered-devices.webm Free Electrons (Full HD)] or [http://video.linux.com/videos/making-rcu-safe-for-battery-powered-devices Linux Foundation]
; Duration : 52:29

=== Abstract ===

Back in the 1990s, energy efficiency was not even on the list of RCU-related concerns. Systems using RCU at that time dealt with either large quantities of heavy equipment or large financial flows, so that the energy consumption of the entire server (let alone RCU's contribution) was way down in the noise. This situation changed dramatically with the 2002 introduction of RCU into the Linux kernel. Since then, RCU's energy-efficiency code has been rewritten more than five times. The most recent rewrite was motivated by workloads where RCU was leaving tens of percent of potential energy savings on the table. This talk will give a brief overview of how energy efficiency came to RCU, the current situation, future prospects, and generally applicable lessons learned.

=== Biography ===

Paul E. McKenney is a Distinguished Engineer with the IBM Linux Technology Center, where he maintains the RCU implementation within the Linux kernel. He has been coding for almost four decades, and more than half of that on parallel hardware. His prior lives include working on the DYNIX/ptx kernel at Sequent, work on packet radio, Internet protocols, and system administration at SRI International, and work on soft-realtime systems as a self-employed contract programmer. His hobbies include what passes for running at his age along with the usual house-wife-and-kids habit.

=== Notes ===

== Transcript ==
; Transcribed by: Arnout Vandecappelle
; Verified by: 1 -

0:00 - 1:00: [slide 1 - title] [some pre-presentation chatting] >> PAUL MCKENNEY: [slide 2 - Overview] I'm going to go through a little obligatory what-is-RCU. At my age, you ''have'' to have at least some slide about "The Good Old Days", as a log [?] or something, and something about that. We'll take a look at RCU's many energy-efficiency variants over the years, the current state of its energy-efficiency, and of course future directions.

[slide 3 - What is RCU?] Now how many people here have actually written code that uses RCU? Good, we got some, great! Now how many people have ever viewed code that has calls to RCU in it?

1:00 - 2:00: Okay, a few more, good. How many people have heard of RCU before today? All right, that's good. Not so long ago [?] I wouldn't have seen any hands for that last one either. [remark from the audience] Yes, there was a time when I could have said yes to the first one and no to the last one, but that was long ago. Anyway.

[slide 4 - A very brief introduction to RCU] OK, let's go through it quickly. This is just a taste of it. I'll just take a few minutes to go through it. I have a slide at the end of this section that has a list of places to go to get more information. These slides are posted somewhere, they will be on my website as well.

If you only want to hear the number one sentence about RCU, the thing to remember is that first bullet there: RCU is a synchronization technique that is sometimes used in place of reader-writer locking. The reason that it's used in place of reader-writer locking is that it has extremely low read-side overhead. When I say extremely low, I mean that if you have a real linux kernel that's built with CONFIG_PREEMPT=n - without preemption - it will be zero.

2:00 - 3:00: And I mean ''zero'': <tt>#define rcu_read_lock()</tt> newline. So, the C preprocessor sees it, the compiler doesn't. Of course, "free" is a very good price, it gives you great performance scalability, real-time response.

The other nice thing about it, is something called hazard pointers. A guy named Maged Michael worked on this. You can have RCU readers making progress, and at the same time RCU writers making progress. So you can have a reader reading an item, while an updater is updating that same data item, and have something sensible happen. This makes for some very nice non-lockup and non-blockage techniques and properties.

The main place you want to use it is read-mostly data. I'll have a slide near the end that gives a "Go", "Wait", "Stop" kind of thing about where to use it. This is increasingly important.

3:00 - 4:00: There was a time, when I was the average age in this room, where, if you have a machine, and you wanted to plug a disk in it, you had to change lines in the source code of the kernel. Then you could bring down your system and plug your disk, and make sure you boot the kernel that has the change because otherwise it will panic coming up with the extra disk. And even worse if you take one out. Well, our machines are a bit more civilized these days, I can slide a memory stick in this thing any time I want, and it will pop it up and say "Hey, here's your disk, what do you want to do with it." What that means, is that a bunch of stuff that used to be stuck in the source code of the kernel is now data structures. Things like routing tables, security policies, storage configuration. These things almost never change. But they might change at any time. That's the sort of thing that RCU works really well for.

4:00 - 5:00: I will have a couple of slides showing specific operations for it. One thing is - I said up there that the readers can make progress even while you're changing data items, so, clearly you have to be able to take the thing and insert new data while the reader is going through the thing and have it all work out correctly. We'll look at that. Even more exciting is when you want to remove some data while a reader is charging [?] through your list or your data structure, and have that work out right. We'll take a look at how that works. Given that the readers aren't telling us anything - remember that you can have zero code for the reader - we need a way for the writers to figure out whether the readers are there or not, so they can do things without upsetting readers. We'll have a slide on that as well.

[slide 5 - Publication of And Subscription To New Data] This slide is talking about when you want to add new data to your data structure and present it to the readers. On this slide and the next slide, if you have something that's red, it means it's dangerous for updaters. Readers could be looking at it, new readers can show up at any time, we can't stop them, we don't even know they're there. So we have to be very careful for the things that are marked red.

Yellow (not on this slide but it will be on the next slide) is dangerous. There can't be any new readers getting to that piece of data, but there might be old ones still there.

5:00 - 6:00: And finally green is where the updater has full control over it, it can do what it wants.

6:00 - 7:00:

7:00 - 8:00:

8:00 - 9:00:

9:00 - 10:00:

10:00 - 11:00:

11:00 - 12:00:

12:00 - 13:00:

13:00 - 14:00:

14:00 - 15:00:

15:00 - 16:00:

16:00 - 17:00:

17:00 - 18:00:

18:00 - 19:00:

19:00 - 20:00:

20:00 - 21:00:

21:00 - 22:00:

22:00 - 23:00:

23:00 - 24:00:

24:00 - 25:00:

25:00 - 26:00:

26:00 - 27:00:

27:00 - 28:00:

28:00 - 29:00:

29:00 - 30:00:

30:00 - 31:00:

31:00 - 32:00:

32:00 - 33:00:

33:00 - 34:00:

34:00 - 35:00:

35:00 - 36:00:

36:00 - 37:00:

37:00 - 38:00:

38:00 - 39:00:

39:00 - 40:00:

40:00 - 41:00:

41:00 - 42:00:

42:00 - 43:00:

43:00 - 44:00:

44:00 - 45:00:

45:00 - 46:00:

46:00 - 47:00:

47:00 - 48:00:

48:00 - 49:00:

49:00 - 50:00:

50:00 - 51:00:

51:00 - 52:00:

52:00 - 53:00:

Session:Making RCU Safe For Battery-Powered Devices ELC2012

2012-11-06T17:28:00Z

Arnout Vandecappelle:

Session:Making RCU Safe For Battery-Powered Devices ELC2012

2012-11-06T17:07:10Z

Arnout Vandecappelle: Created page with "== Session Details == ; Event : Embedded Linux Conference 2012 ; Date : February 16, 2012 ; Presenter : Paul E. McKenney ; Organization: IBM ; Slides : http://elinux.org/imag..."

ELC 2012 Presentations

2012-11-06T16:59:41Z

Arnout Vandecappelle: /* Presenters */ Link to session page for Paul McKenney

Presenters, Demo-ers, Participants:
Thanks very much for your participation in Linux Foundation's [https://events.linuxfoundation.org/events/embedded-linux-conference Embedded Linux Conference 2012].

This page is for collecting the presentations that were made at the conference. During and
after the conference we will collect materials from the presenters and place them here.
Please watch this page if you are interested in a particular presentation - and if it
doesn't show up, please [[Special:EmailUser/Wmat | send me and email]] and we'll try to track it down.

== Videos ==

Videos for ELC2012 from the Linux Foundation can be found at [http://video.linux.com/categories/2012-embedded-linux-conference ELC2012 Videos].

In addition, Free Electrons has also provided video of Andoid builders Summit talks, and ELC talks:

[http://free-electrons.com/blog/abs-2012-videos/ Android Builders Summit] 
[http://free-electrons.com/blog/elc-2012-videos/ ELC]

== Instructions ==
'''Presenters:''' Please post your technical conference presentations on this page.
(See Instructions below the tables)

= Table of Presentations =

NOTE: If you add a wikilink to your presentation and attempt to upload it via the link, it may fail. If it does, use the [[Special:Upload]] page to upload your file.

== Keynotes ==
{| border="1" cellspacing="0" cellpadding="4"
|- bgcolor="#c0e0e0"
|+ '''Keynotes'''
|- bgcolor="#c0e0e0"
| align="center" | '''Presenter(s)'''
| align="center" | '''Session Description'''
| align="center" | '''Presentation'''
| align="center" | '''Transcript Status'''
|-
| Jon Corbett, Editor at LWN.net
| The Kernel Report
| [[Media:lf_elc12_corbet.pdf | The Kernel Report ELC2012]]
|
|-
| Mike Anderson, CTO at The PTR Group
| [[Session:The Internet of Things|The Internet of Things]]
| [[Media:anderson.pdf | The Internet of Things]]
| in progress
|}

 

== Presenters ==
{| border="1" cellspacing="0" cellpadding="4"
|- bgcolor="#c0e0e0"
|+ '''Presentations'''
|- bgcolor="#c0e0e0"
| align="center" | '''Presenter(s)'''
| align="center" | '''Session Description'''
| align="center" | '''Presentation'''
| align="center" | '''Transcript Status'''
|-
|- bgcolor="#a0c0c0"
| colspan="4" | Day 1, 9:30am
|-
| Loïc Pallardy
| Saving the Power Consumption of the Unused Memory
| [[Media:lf_elc12_pallardy.pdf|PDF]]
|-
| Bernhard Rosenkränzer, Linaro
| What Android and Embedded Linux Can Learn From Each Other
| [[Media:lf_elc12_rosenkranzer.pdf|PDF]]
|-
| Ricardo Salveti de Araujo, Linaro
| Ubuntu on ARM: Improvements and Optimizations Done By Linaro
| [[Media:Ubuntu_on_ARM-_Improvements_and_Optimizations_Done_By_Linaro.pdf|PDF]]
|- bgcolor="#a0c0c0"
| colspan="3" | Day 1, 11:30am
|-
| Zach Pfeffer, Linaro
| Binary Blobs Attack
| [[Media:lf_elc12_pfeffer.pdf|PDF]]
|-
| Hisao Munakata, Renesas Electronics
| Close Encounters of the Upstream Resource
| [[Media:lf_elc12_munakata.pdf|PDF]]
|-
| Daniel Hursh, IBM
| Open Source Automated Test Framework
| [[Media:lf_elc12_hursh.pdf|PDF]]
|- bgcolor="#a0c0c0"
| colspan="3" | Day 1, 2:00pm
|-
| Saul Wold, Intel
| The Yocto Project Overview and Update
| [[Media:The Yocto Project Overview and Update.pdf|PDF]]
|-
| Sean Hudson, Mentor Graphics, Inc.
| Embedded Linux Pitfalls
| [[Media:Embedded Linux Pitfalls.pdf|PDF]]
|-
| Vincent Guittot, Linaro
| Comparing Power Saving Techniques For Multicore ARM Platforms
| [[Media:Comparing Power Saving Techniques For Multicore ARM Platforms.pdf|PDF]]
|-
|- bgcolor="#a0c0c0"
| colspan="3" | Day 1, 3:00pm
|-
|-
| Tim Bird, Sony Network Entertainment
| Status of Embedded Linux
| [[Media:Status-of-embedded-Linux-2012-02-ELC-v2.pdf|PDF]]
|-
| Bruce Ashfield, Wind River
| A View From the Trenches: Embedded Functionality and How It Impacts Multi-Arch Kernel Maintenance
| [[Media:A_View_From_the_Trenches-_Embedded_Functionality_and_How_It_Impacts_Multi-Arch_Kernel_Maintenance.pdf‎|PDF]]
|-
| R Durgadoss, Intel
| PeakCurrent Management in x86-Based Smartphones
| [[Media:PeakCurrent Management in x86-Based Smartphones.pdf|PDF]]
|- bgcolor="#a0c0c0"
| colspan="3" | Day 1, 4:15pm
|-
| Matt Porter, Texas Instruments
| Passing Time With SPI Framebuffer Driver
| [[Media:Passing Time With SPI Framebuffer Driver.pdf|PDF]]
|-
| Wookey, Linaro
| Multiarch and Why You Should Care: Running, Installing and Crossbuilding With Multiple Architectures
| [[Media:Multiarch_and_Why_You_Should_Care-_Running,_Installing_and_Crossbuilding_With_Multiple_Architectures.pdf|PDF]] [[Media:SourceCode.tgz|SOURCE]]
|-
| Amit Daniel Kachhap, Linaro/Samsung
| A New Simplified Thermal Framework For ARM Platforms
| [[Media:A New Simplified Thermal Framework For ARM Platforms.pdf|PDF]]
|-
|- bgcolor="#a0c0c0"
| colspan="3" | Day 1, 5:15pm
|-
|-
| Tsugikazu Shibata, NEC
| On The Road: To Provide the Long-Term Stable Linux For The Industry
| [[media:On_The_Road-_To_Provide_the_Long-Term_Stable_Linux_For_The_Industry.pdf|PDF]]
|-
| Thomas P. Abraham, Samsung Electronics
| Experiences With Device Tree Support Development For ARM-Based SOC's
| [[Media:Experiences With Device Tree Support Development For ARM-Based SOC's.pdf|PDF]]
|-
| Paul E. McKenney, IBM
| [[Session:Making RCU Safe For Battery-Powered Devices ELC2012|Making RCU Safe For Battery-Powered Devices]]
| [[media:Making RCU Safe For Battery-Powered Devices.pdf|PDF]]
| in progress
|- bgcolor="#a0c0c0"
| colspan="3" | Day 2, 10:30am
|-
| Thomas Petazzoni, Free Electrons
| Buildroot: A Nice, Simple, and Efficient Embedded Linux Build System
| [[Media:Buildroot2.pdf|PDF]]
|-
| Steven Rostedt, Red Hat
| Automated Testing with ktest.pl (Embedded Edition)
| [[Media: Automated Testing with ktest.pl (Embedded Edition).pdf|PDF]]
|-
| David VomLehn, Cisco
| Intricacies of a MIPS Stack Backtrace Implementation
| [[Media:Intricacies of a MIPS Stack Backtrace Implementation.pdf|PDF]]
|-
|- bgcolor="#a0c0c0"
| colspan="3" | Day 2, 11:30am
|-
| Edward Hervey, Collabora
| GStreamer 1.0: No Longer Compromise Flexibility For Performance
| [[Media:GStreamer_1.0-_No_Longer_Compromise_Flexibility_For_Performance.pdf|PDF]]
|-
| Steven Rostedt, Red Hat
| Automated Testing with ktest.pl (Embedded Edition) (Cont.)
| [[Media: Automated Testing with ktest.pl (Embedded Edition).pdf|PDF]]
|-
| Tim Bird, Sony Network Entertainment
| Embedded-Appropriate Crash Handling in Linux
| [[Media:Embedded-Appropriate Crash Handling in Linux.pdf|PDF]]
|-
|- bgcolor="#a0c0c0"
| colspan="3" | Day 2, 2:00pm
|-
| Arnd Bergmann, Linaro
| ARM Subarchitecture Status
| [[Media:ARM Subarchitecture Status.pdf|PDF]]
|-
| Mark Gisi, Wind River Systems
| The Power of SPDX - Sharing Critical Licensing Information Within a Linux Device Supply Chain
| [[Media:The Power of SPDX - Sharing Critical Licensing Information Within a Linux Device Supply Chain.pdf|PDF]]
|-
| Yoshitake Kobayashi, Toshiba
| Ineffective and Effective Ways To Find Out Latency Bottlenecks With Ftrace
| [[Media:Ineffective and Effective Ways To Find Out Latency Bottlenecks With Ftrace.pdf|PDF]]
|-
|- bgcolor="#a0c0c0"
| colspan="3" | Day 2, 3:00pm
|-
| Ohad Ben-Cohen, Wizery / Texas Instruments
| Using virtio to Talk With Remote Processors
| [[Media:Using virtio to Talk With Remote Processors.pdf|PDF]]
|-
| Elizabeth Flanagan, Intel
| Embedded License Compliance Patterns and Antipatterns
| [[Media:Embedded License Compliance Patterns and Antipatterns.pdf|PDF]]
|-
| David Anders, Texas Instruments
| Board Bringup: LCD and Display Interfaces
| [[elc-lcd|PDF]]
|-
|- bgcolor="#a0c0c0"
| colspan="3" | Day 2, 4:15pm
|-
| Rob Clark, Texas Instruments
| DMA Buffer Sharing: An Introduction
| [[Media:DMA_Buffer_Sharing-_An_Introduction.pdf|PDF]]
|-
| Ken Tough, Intrinsyc
| Linux on eMMC: Optimizing For Performance
| [[Media:Linux_on_eMMC-_Optimizing_For_Performance.pdf|PDF]]
|-
| Paul Larson, Linaro
| LAVA Project Update
| [[Media:LAVA Project Update.pdf|PDF]]
|-
|- bgcolor="#a0c0c0"
| colspan="3" | Day 2, 5:15pm
|-
| Jeff Osier-Mixon, Intel
| Yocto Project Community (BoFs)
| No Slides
|-
| Frank Rowand, Sony Network Entertainment
| Real Time (BoFs)
| [[Media:Real Time (BoFs).pdf|PDF]]
|-
| Mike Turquette, Texas Instruments
| Common Clock Framework (BoFs)
| [[Media:Common Clock Framework (BoFs).pdf|PDF]]
|-
|- bgcolor="#a0c0c0"
| colspan="3" | Day 3, 9:00am
|-
| Hunyue Yau, HY Research LLC
| Userland Tools and Techniques For Linux Board Bring-Up and Systems Integration
| [[Media:Userland Tools and Techniques For Linux Board Bring-Up and Systems Integration.pdf|PDF]]
|-
| Matt Weber, Rockwell Collins Inc.
| Optimizing the Embedded Platform Using OpenCV
| [[Media:Optimizing the Embedded Platform Using OpenCV.pdf|PDF]]
|-
| Greg Ungerer, McAfee
| M68K: Life in the Old Architecture
| [[Media:M68K-_Life_in_the_Old_Architecture.pdf|PDF]]
|- bgcolor="#a0c0c0"
| colspan="3" | Day 3, 10:00am
|-
| Gary Bisson, Adeneo Embedded
| Useful USB Gadgets on Linux
| [[Media:Useful USB Gadgets on Linux.pdf|PDF]]
|-
| Jason Kridner, Texas Instruments
| GUIs: Coming To Uncommon Goods Near You
| [[Media:Guis_coming_to_uncommon_goods.pdf|PDF]]
|-
| Mike Anderson, The PTR Group
| Adapting Your Network Code For IPv6 Support
| [[Media:Adapting Your Network Code For IPv6 Support.pdf|PDF]]
|- bgcolor="#a0c0c0"
| colspan="3" | Day 3,11:30pm
|-
| Koen Kooi, The Angstrom Distribution
| Producing the Beaglebone and Supporting It
| No Paper - see video
|-
| Danny Bennett, basysKom GmbH
| HTML5 in a Plasma-Active World
| [[Media:HTML5 in a Plasma-Active World.pdf|PDF]]
|-
| Marcin Mielczarczyk, Tieto
| Getting the First Open Source GSM Stack in Linux
| [[Media:Getting the First Open Source GSM Stack in Linux.pdf|PDF]]
|- bgcolor="#a0c0c0"
| colspan="4" | Day 3, 2:00pm
|-
|-
| Pierre Tardy, Intel
| PyTimechart Practical
|[[Media:PyTimechart Practical.pdf|PDF]]
|-
| Linus Walleij, ST-Ericsson
| Pin Control Subsystem Overview
| [[Media:Pin Control Subsystem Overview.pdf|PDF]]
|-
| Khem Raj, OpenEmbedded Project
| OpenEmbedded - A Layered Approach
| [[Media:OpenEmbedded - A Layered Approach.pdf|PDF]]
|- bgcolor="#a0c0c0"
| colspan="3" | Day 3, 3:00pm
|-
| Lucas De Marchi, ProFUSION Embedded Systems
| Managing Kernel Modules With kmod
| [[Media:Managing Kernel Modules With kmod.pdf|PDF]]
|-
| Jean Pihet, NewOldBits
| A New Model for the System and Devices Latency
| [[Media:A New Model for the System and Devices Latency.pdf|PDF]]
|-
| Pintu Kumar, Samsung
| Controlling Linux Memory Fragmentation and Higher Order Allocation Failure: Analysis, Observations and Results
| [[Media:Controlling_Linux_Memory_Fragmentation_and_Higher_Order_Allocation_Failure-_Analysis,_Observations_and_Results.pdf|PDF]]
| in-progress
|}

 

== Workshops ==
{| border="1" cellspacing="0" cellpadding="4"
|- bgcolor="#c0e0e0"
|+ '''Workshops'''
|- bgcolor="#c0e0e0"
| align="center" | '''Presenter(s)'''
| align="center" | '''Session Description'''
| align="center" | '''Presentation'''
|-
|-
| Karim J. Yaghmour
| Embedded Android Workshop
| [[Media:Android Workshop.pdf|PDF]]
|-

|}

 

== Instructions for Presenters ==
Please create a link in the table for your presentation, copying the style of other links.
(You may need to create an account in order to edit the wiki or upload files.)

When you have created the link, click on it to upload the file containing your slides.
[[Category:ELC]]
[[Category:2012]]
[[Category:Events]]
[[Category:Presentations]]

Buildroot:DeveloperDaysELCE2012

2012-11-04T19:26:30Z

Arnout Vandecappelle: /* Report of the meeting */

== Buildroot Developers Meeting, 3-4 November 2012, Barcelona Spain ==

=== What is Buildroot ? ===

[http://buildroot.org 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.

=== Meeting in Barcelona ===

The Buildroot community is organizing a meeting on Saturday November 3rd and Sunday November 4th, for Buildroot developers and contributors. This meeting will be a mixture of discussion and hacking session around the Buildroot project. This meeting takes place right before the Embedded Linux Conference Europe, in order to make it easy for participants to attend both events.

=== Event sponsored by Fluendo and Synopsys ===

The meeting room is sponsored by [http://www.fluendo.com Fluendo]. Thanks!

The Saturday dinner is sponsored by [http://www.synopsys.com Synopsys]. Thanks!

=== Report of the meeting ===

==== Action points ====
* Accept perl series.
* Accept qemu series (after further review).
* Remove compiler on target.
* Remove development files on target.
* Remove documentation on target.
* Explain in the documentation why the above was done.
* Put httpd daemons outside BUSYBOX_SHOW_OTHERS.
* Move BUSYBOX_SHOW_OTHERS conditions to ''depends on'' inside the package Config.in
* busybox: disable mount-nfs in the default config.
* simplify patch logic: if pkg-version directory exists, use that; otherwise, use pkg-*.patch.
* Automate selection of correct FP and other compiler options based on subarchitecture.
* Move download helpers to a script.
* Samuel merges documentation patches and sends pull requests to Peter.
* Ask Yann for help regarding the comments in the AVAILABLE framework.
* Document better that you need to do make clean; make instead of make target-clean.
* Rename output/target to output/tmproot.
* Arnout reposts the save-configuration simplification patches without out-of-buildroot-tree support.

==== Details of the discussion ====

# Perl. The perl patch series (now at v11) looks ready to be integrated, but we have our doubts about cpanminus. The problems are: it has separate download infrastructure, which blocks some buildroot features (e.g. make source); it doesn't integrate with the legal-info. However, CPAN is pretty important if you really want to use perl. The decision was to accept cpanminus as well, but add some warnings that some things don't work.
# Qemu. Adding this opens the door for more people to do stuff that buildroot wasn't meant for in the first place (i.e. embedded). However, even in embedded qemu could be relevant. Things like the compiler on the target are much worse for doing crazy things. Giving new packages a chance is OK; we have to be much more careful with things that have global impact (like including development files on target). Conclusion: it's OK to accept qemu.
# Compiler on target. It leads to newbies using buildroot in an inappropriate way (i.e. compile on the target). Also it only works with the internal toolchain. And if we remove it, we can also remove "Development files on target", which simplifies some of the build infrastructure. Also, if you have a compiler on the target, then you can just as well use a distro. Conclusion: we remove it. Also a bunch of other packages can be removed (autotools, vala, ...)
# Documentation on target: if you need this, use a distro. So we remove it.
# We need to explain in the documentation why we removed this stuff.
# Available stuff: i.e. solve the problem of combination of ''select'' and ''depends''. Solving it in Kconfig itself seems to be difficult: there were some patches but the kconfig people didn't like it; Yann and Thomas looked at Kconfig and it looks difficult to modify. The AVAILABLE solution has two problems: it adds verbosity, and the recursive dependencies still should be written in the comments ("libfoo requires WCHAR in the toolchain"). The verbosity is not considered a big issue. For the comments: they currently don't work perfectly either. Removing the comments altogether is an option, but then it is difficult for users to find out why a certain package isn't available. Another possibility is to list the available packages in the documentation (automatically), and mention which toolchain dependencies they have. Wild idea: consider Config.in as a low-level language, and define our own higher-level language from which we generate Config.in. Alternatively, have a developer tool that verifies if everything is consistent (i.e. are the comments correct). One more option: add a big comment in the beginning of the packages list, which says that not all toolchain options are available so not all packages are visible. Converting the toolchain options from ''depends'' to ''select'' is not really an option, because changing toolchain options requires a make clean. After more discussion on Sunday, we didn't find a solution. For the time being, we stick to the old system. We ask Yann if he has a brilliant idea of how to deal with the comments.
# kconfig-frontend: Yann now has a repository for Kconfig, it would be nice to branch our Kconfig from that. The idea is to still copy it to our repository.
# BUSYBOX_SHOW_OTHERS: the only reason to have this is to avoid newcomers enabling things like tar etc. which are anyway already in busybox. But for the web servers, they are clearly different from the busybox web servers (and our default busybox config doesn't even enable a web server). Also bash is a typical one, because people write bashisms in their scripts. This discussion is somewhat related to the discussion how to handle packages that provide the same functionality. But for many packages, it's not even the same (httpd, bash, vim). But actually, we're trying to solve a non-existent problem here - except for the web servers. If we generate a list of packages in the documentation, we can add a remark to that that it's also available in busybox. Also move the condition inside the package Config.in instead of outside and make it a ''depends on'', so it is more visible.
# packages with multiple variants: python2/3, Qt4/5, gtk2/3, gstreamer0.10/1.0... This is again similar to the expat/libxml2 issue. Do we support both python2 and python3? We need to support both versions in most cases. Question is if we want to force that only one of the two is selected, or do we support side-by-side installation. Conclusion: has to be looked at on a case-by-case basis. General philosophy: don't try to be too smart, so don't try to force selecting only one of the two if it doesn't make sense to have both. In cases where a package wants to ''select'' one of these things, convert the ''select'' into a ''depends'' with a comment. For gstreamer, the complexity of having the two side-by-side is unacceptable, because there are so many fine-grained gstreamer configure options (in the plugins). However, we expect that everything will move to gstreamer1.0 quite quickly, so for the time being (and only if someone needs it), we can live with a non-perfect solution that just fits the requirements of whoever needs gstreamer1.0.
# multiple packages providing the same functionality: lua/luajit, jpeg/jpegturbo, expat/libxml2. These cannot be installed side-by-side, and many packages select e.g. jpeg. OpenGL will have this issue as well. A relatively clean solution is to create virtual packages for these, where the user has a choice between the two. The normal config option would be hidden for these packages. This still adds complexity in some corner cases, e.g. some package that doesn't work in luajit, but that can probably be solved at the level of that package.
# Autobuild infrastructure. Thomas is working on scripts that parse the build result and put it in a database. One important missing feature at the moment is visibility of evolution over time (i.e. distinguish regressions from recurring problems). Even more important is just being able to see which packages are failing all the time, i.e. for each package how often it failed. Ideally, we would also want to see how often a package has been built successfully, but when is it successful? Does the entire build have to succeed or that package? Overall, however, the autobuild infrastructure is considered very useful - when something is wrong, it appears in the autobuild very quickly.
#* autobuild of the next branch: if only the master is autobuilt, we don't see a lot of problems until after the release. Delaying fixing bugs makes it more difficult to fix them. To support autobuild of the next branch, this should also be made visible in the database so we can distinguish master failures (more important) from next failures.
#* autobuild database is not suitable to track repeated builds of the same configuration. It needs to keep track of different builds of the same configurations. But the question is if this is really useful. We would like to check the existing defconfigs at every release, but it doesn't have to be tracked. So it can be done manually.
# AVR32. It is end of life as far as Atmel is concerned, but of course there are still products out there using it. It is not really blocking for buildroot. For packages which fail to build, we can just add a ''depends on !BR2_avr32''. But of course, until we have the AVAILABLE mechanism, carrying this kind of dependency can be painful.
# RPC support. Originally, the idea was to consider RPC support as a toolchain option, i.e. using ''depends''. However, libtirpc is really a library, comparable to gettext, so it could be enabled automatically with ''select''. Busybox is special, because we don't want to force RPC just because busybox is selected. Therefore busybox has a user-selectable option to enable RPC-based applets (mount-nfs). After discussion, this option was discarded - just remove mount-nfs from busybox (see below). Other packages will use libtirpc if it was selected (manually or automatically). It's still a question what will happen when dynamically linking against libtirpc when libc also has rpc.
# A bit related: we'll disable mount-nfs in the default busybox config; if user disables RPC and enables mount-nfs in busybox, he'll get a compilation error.
# Support for VCS branches in packages: custom packages are often in a VCS and while developing, you want to track a branch of that VCS. OVERRIDE_SRCDIR doesn't work very well because it means the user has to check everything out at the right version in the right location. An alternative would be to teach OVERRIDE_SRCDIR about VCSes, so that ''make foo-rebuild'' re-syncs with the VCS.
# There is a general feeling (mainly from Thomas) that buildroot isn't very convenient during development of a project where several people are working on several components. But no solution was found.
# FP stuff: we now have a single SOFT_FLOAT option, but actually there's a lot more variation: neon, vfpv3, softfp, .... To support this well, we can add a lot of extra config options to semi-automatically select the correct float options based on the subarchitecture. There is some cross-dependency with the external toolchains, but it's doable. There should still be an option to manually override the float options for exotic cases. ARM thumb adds another layer of complexity. Someone should take the lead on making this easier.
# Porting gcc to the generic package infrastructure. Looks like this is a lot of work, and there's not so much need for it.
# Getting gcc from git. It's more convenient to put a tarball somewhere public and use that as an alternative source, similar to avr32.
# Download helpers are getting too complex. It should move a script so at least it's more readable.
# Community organization:
#* It can be useful to have subsystem maintainers, that are responsible for reviewing and accepting patches. In practice, however, it is difficult to split things in a way that we don't risk duplicating work (i.e. two people in the process of merging the same patch). However, one clearly defined subsystem is the documentation. From now on, Samuel Martin is responsible for all documentation patches. He'll send pull requests to Peter.
#* Patches should be accepted more aggressively, even if there hasn't been (much) testing of the patch. The autobuilders will catch any issues. However, it is still important to properly review and comment on coding style issues (i.e. how the features are implemented. Also, if something really breaks the autobuilder, Thomas can revert it without consulting Peter.
# Out of tree build: this is a feature that people keep on asking. It is particularly useful for packages with an OVERRIDE_SRCDIR. But of course, not all packages support out-of-tree build, and not all packages support it in the same way. For autotools and cmake, it can be automatic; for generic packages, it has to be signalled if out-of-tree build is available.
# legal-info:
#* split _LICENSE and _REDISTRIBUTE: patch proposed by Luca is accepted. Even though there is no proprietary package in buildroot that triggers the feature, if it fails to work as expected the user will hopefully report it.
#* multiple licenses: we don't want to make things very complex. It doesn't have to be machine-readable (we don't need to support machine analysis of the license field), so we don't have to formally decide how the license text must be written. It does make sense to have some convention, though. Proposal: "GPLv2+ or BSD-2c for the library, GPLv2+ for the dtc executable".
# target-clean: purpose is to rebuild the target tree, without rebuilding all packages. The problem is that this looks as if packages are really removed, but there may still be dependencies hidden in the built packages so that the resulting target doesn't work anymore. One idea is to just not have a target dir anymore, but instead reconstruct it from the staging dir every time the fs is built. But this is too much overhead in the usual case. Basically, we prefer to have people do a full make clean if they change anything. We should update the documentation to explain that this is necessary. There was an idea to remove the entire target tree, and just regenerate it on every build. This would simplify the .mk files because for most packages there's no need for INSTALL_TARGET_CMDS anymore (some packages still want to remove stuff), and implicitly does a target-clean (because there is no target dir to begin with), but only for the use case of skeleton changes. In the end, the conclusion was that we don't want to support target-clean, but we'll document why not.
# Regarding out-of-buildroot-tree project stuff: we don't really want to advertise keeping stuff outside of the buildroot tree. Any patches that make that easier will be rejected. But it would be nice to store the result of xxx-menuconfig back to the place where it came from, or warn if that place doesn't exist.
# API changes: we tend to change the way the packages are used very often, without caring about how this affects users who have a modified buildroot tree. Merge conflicts are not much of an issue, but "invisible" changes can really bite users that don't follow the mailing list. We should think a bit about how it affects user before randomly renaming "BR2_NEEDS_GETTEXT" to "BR2_NEEDS_EXTERNAL_GETTEXT".

=== Participants ===

# [[User:Arnout_Vandecappelle|Arnout Vandecappelle]], confirmed. Arriving on Fri Nov 2 20:35 at BCN airport. Leaving Wed Nov. 8 21:15 at BCN. Staying at [http://www.hcchotels.es/en/hotel/12/hcc-lugano HCC Lugano]
# [[User:ThomasPetazzoni|Thomas Petazzoni]], confirmed. Arriving on November, 3rd at BCN airport 9:25 AM. Leaving on November 8th from BCN airport at 3:45 PM. Staying at Hotel Fira Palace.
# Maxime Ripard, confirmed. Arriving on November, 1st at BCN airport. Leaving on November 8th from BCP airport at 3:45 PM. Staying at Hotel Fira Palace.
# [[User:PeterKorsgaard|Peter Korsgaard]], confirmed, Arriving on Fri Nov 2 21:55 at BCN airport. Leaving Sun Nov 11 17:15 at BCN. Staying at [http://www.hcchotels.es/en/hotel/12/hcc-lugano HCC Lugano]
# Luca Ceresoli, confirmed. Arriving on November 3rd at BCN airport 10:05 AM. Leaving on November 7th from BCN airport 19:15 PM. Staying at Hotel Fira Palace. Will arrive around 11:30 AM for the meeting.
# Samuel Martin, confirmed. Arriving on November, 3rd at Barcelona-Franca Train Station 8:05 AM. Leaving on November 10th from Barcelona-Franca Train Station at 8:43 PM.
# Simon Dawson, confirmed. Arriving on November 2nd in the evening. Leaving on November 8th early morning.
# Mischa Jonker, confirmed. From Synopsys.com. Not contributing yet to Buildroot, but interested in using Buildroot for a brand new CPU architecture. Arriving Friday Nov 2nd BCN 21:10 CET, staying at Catalonia Barcelona Plaza (Plaza Espanya), leaving Thursday Nov 8 at 18:40 CET.
# Maxime Hadjinlian.

=== Registration ===

Please contact Thomas Petazzoni (thomas.petazzoni@free-electrons.com) if you would like to attend.

Attending the event is free, but registration is required.

=== Program ===

* Saturday, 10 AM: beginning of the meeting. The first person to arrive can go directly to the front desk and ask for MARIBEL SOCIAS or anyone in the Reservations Department, and then ask for the meeting room booked for Thomas Petazzoni. [[User:ThomasPetazzoni|Thomas Petazzoni]] will only arrive at 10:30-11 AM.
* Saturday, 7 PM: end of the meeting
* Saturday, 8:30 PM: dinner sponsored by Synopsys
* Sunday, 10 AM: beginning of the meeting
* Sunday, 7 PM: end of the meeting

=== Location ===

The event will take place at [http://www.hotelgrumsbarcelona.com/ Hotel Grumps], in downtown Barcelona. See [http://goo.gl/maps/htYi9 this map] for the location of the hotel, and [http://goo.gl/maps/GdiaM this map] for walking directions between the Fira Palace hotel (location of the ELCE conference) and Hotel Grums.

=== List of topics to discuss ===

* Interaction between Buildroot configuration options to select architecture specifities (architecture variant, soft-float vs. hard-float, etc.) and the multilib variants available in external toolchains. Proposed by [[User:ThomasPetazzoni]].
* Status on the community organization. Has patchwork improved things? Are patches taken into account in a faster way? Proposed by [[User:ThomasPetazzoni]].
* What are the next "big" things for Buildroot? Proposed by [[User:ThomasPetazzoni]].
* Documentation refactoring? Proposed by Samuel Martin.
* Autobuilder tests: needed improvements, future work. Proposed by [[User:ThomasPetazzoni]].
* The _AVAILABLE mechanism, and how to properly handle dependency on toolchain options (discuss the proposal made by Yann E. Morin). Proposed by [[User:ThomasPetazzoni]].
* Discuss (and, if approved, implement) the split between _LICENSE and _REDISTRIBUTE for legal-info. I think this won't take much more than 10 minutes chat + 10 minutes hack. Proposed by Luca Ceresoli.
* Make it possible to use a git repository as source for toolchain. This doesn't work well today. Proposed by Mischa Jonker
* Make it possible to do a 'target-clean', as a replacement of uninstall. Will this even work at all? Proposed by Arnout Vandecappelle
* Does it make sense to port the toolchains to generic-package infrastructure? Asked by Arnout Vandecappelle
* How to provide licensing info for packages that have more than one license. The main use cases are: a) different parts of the source code have different licenses, b) a file (or the whole project) is distributed under two or more licenses or c) a mix of the two. See the recent thoughts about this issue by Yann Morin: http://lists.busybox.net/pipermail/buildroot/2012-October/060475.html
* Support for board stuff outside the buildroot tree. Proposed by Arnout Vandecappelle
* Should we remove the ability to build a toolchain on the target? And also things like development files on target, documentation on target, etc. Proposed by [[User:ThomasPetazzoni]].

=== List of topics to hack on ===

* Reduce the back log of bugs. Proposed by [[User:ThomasPetazzoni]].
* Reduce the back log of patches. Proposed by [[User:ThomasPetazzoni]].
* Work on noMMU platform support (Blackfin, Coldfire). Getting Coldfire Qemu working, adding correct support for FLAT binaries. Proposed by [[User:ThomasPetazzoni]].
* Package upgrades: package python3, gtk3 and latest versions of glib and al. Proposed by [[User:ThomasPetazzoni]].
* Triage autobuilder failures and fix them. Proposed by Arnout Vandecappelle
* Improve the documentation. Proposed by Arnout Vandecappelle
* Work on relocatable toolchain. Proposed by Arnout Vandecappelle
* Add some infra for setup.py/qmake based packages. Proposed by Samuel Martin
* Add some infra for make based packages (mainly using the same pattern all over). Proposed by Arnout Vandecappelle
* Add some infra for Kconfig based packages (linux, barebox, busybox, uclibc, ct-ng, at91bootstrap3). Proposed by Arnout Vandecappelle
* Make top-level make -j possible. Proposed by Arnout Vandecappelle

Buildroot:DeveloperDaysELCE2012

2012-11-04T18:56:01Z

Arnout Vandecappelle: /* Report of the meeting */

== Buildroot Developers Meeting, 3-4 November 2012, Barcelona Spain ==

=== What is Buildroot ? ===

[http://buildroot.org 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.

=== Meeting in Barcelona ===

The Buildroot community is organizing a meeting on Saturday November 3rd and Sunday November 4th, for Buildroot developers and contributors. This meeting will be a mixture of discussion and hacking session around the Buildroot project. This meeting takes place right before the Embedded Linux Conference Europe, in order to make it easy for participants to attend both events.

=== Event sponsored by Fluendo and Synopsys ===

The meeting room is sponsored by [http://www.fluendo.com Fluendo]. Thanks!

The Saturday dinner is sponsored by [http://www.synopsys.com Synopsys]. Thanks!

=== Report of the meeting ===

==== Action points ====
* Accept perl series.
* Accept qemu series (after further review).
* Remove compiler on target.
* Remove development files on target.
* Remove documentation on target.
* Explain in the documentation why the above was done.
* Put httpd daemons outside BUSYBOX_SHOW_OTHERS.
* Move BUSYBOX_SHOW_OTHERS conditions to ''depends on'' inside the package Config.in
* busybox: disable mount-nfs in the default config.
* simplify patch logic: if pkg-version directory exists, use that; otherwise, use pkg-*.patch.
* Automate selection of correct FP and other compiler options based on subarchitecture.
* Move download helpers to a script.
* Samuel merges documentation patches and sends pull requests to Peter.
* Ask Yann for help regarding the comments in the AVAILABLE framework.
* Document better that you need to do make clean; make instead of make target-clean.
* Rename output/target to output/tmproot.
* Arnout reposts the save-configuration simplification patches without out-of-buildroot-tree support.

==== Details of the discussion ====

# Perl. The perl patch series (now at v11) looks ready to be integrated, but we have our doubts about cpanminus. The problems are: it has separate download infrastructure, which blocks some buildroot features (e.g. make source); it doesn't integrate with the legal-info. However, CPAN is pretty important if you really want to use perl. The decision was to accept cpanminus as well, but add some warnings that some things don't work.
# Qemu. Adding this opens the door for more people to do stuff that buildroot wasn't meant for in the first place (i.e. embedded). However, even in embedded qemu could be relevant. Things like the compiler on the target are much worse for doing crazy things. Giving new packages a chance is OK; we have to be much more careful with things that have global impact (like including development files on target). Conclusion: it's OK to accept qemu.
# Compiler on target. It leads to newbies using buildroot in an inappropriate way (i.e. compile on the target). Also it only works with the internal toolchain. And if we remove it, we can also remove "Development files on target", which simplifies some of the build infrastructure. Also, if you have a compiler on the target, then you can just as well use a distro. Conclusion: we remove it. Also a bunch of other packages can be removed (autotools, vala, ...)
# Documentation on target: if you need this, use a distro. So we remove it.
# We need to explain in the documentation why we removed this stuff.
# Available stuff: i.e. solve the problem of combination of ''select'' and ''depends''. Solving it in Kconfig itself seems to be difficult: there were some patches but the kconfig people didn't like it; Yann and Thomas looked at Kconfig and it looks difficult to modify. The AVAILABLE solution has two problems: it adds verbosity, and the recursive dependencies still should be written in the comments ("libfoo requires WCHAR in the toolchain"). The verbosity is not considered a big issue. For the comments: they currently don't work perfectly either. Removing the comments altogether is an option, but then it is difficult for users to find out why a certain package isn't available. Another possibility is to list the available packages in the documentation (automatically), and mention which toolchain dependencies they have. Wild idea: consider Config.in as a low-level language, and define our own higher-level language from which we generate Config.in. Alternatively, have a developer tool that verifies if everything is consistent (i.e. are the comments correct). One more option: add a big comment in the beginning of the packages list, which says that not all toolchain options are available so not all packages are visible. Converting the toolchain options from ''depends'' to ''select'' is not really an option, because changing toolchain options requires a make clean. After more discussion on Sunday, we didn't find a solution. For the time being, we stick to the old system. We ask Yann if he has a brilliant idea of how to deal with the comments.
# kconfig-frontend: Yann now has a repository for Kconfig, it would be nice to branch our Kconfig from that. The idea is to still copy it to our repository.
# BUSYBOX_SHOW_OTHERS: the only reason to have this is to avoid newcomers enabling things like tar etc. which are anyway already in busybox. But for the web servers, they are clearly different from the busybox web servers (and our default busybox config doesn't even enable a web server). Also bash is a typical one, because people write bashisms in their scripts. This discussion is somewhat related to the discussion how to handle packages that provide the same functionality. But for many packages, it's not even the same (httpd, bash, vim). But actually, we're trying to solve a non-existent problem here - except for the web servers. If we generate a list of packages in the documentation, we can add a remark to that that it's also available in busybox. Also move the condition inside the package Config.in instead of outside and make it a ''depends on'', so it is more visible.
# packages with multiple variants: python2/3, Qt4/5, gtk2/3, gstreamer0.10/1.0... This is again similar to the expat/libxml2 issue. Do we support both python2 and python3? We need to support both versions in most cases. Question is if we want to force that only one of the two is selected, or do we support side-by-side installation. Conclusion: has to be looked at on a case-by-case basis. General philosophy: don't try to be too smart, so don't try to force selecting only one of the two if it doesn't make sense to have both. In cases where a package wants to ''select'' one of these things, convert the ''select'' into a ''depends'' with a comment. For gstreamer, the complexity of having the two side-by-side is unacceptable, because there are so many fine-grained gstreamer configure options (in the plugins). However, we expect that everything will move to gstreamer1.0 quite quickly, so for the time being (and only if someone needs it), we can live with a non-perfect solution that just fits the requirements of whoever needs gstreamer1.0.
# multiple packages providing the same functionality: lua/luajit, jpeg/jpegturbo, expat/libxml2. These cannot be installed side-by-side, and many packages select e.g. jpeg. OpenGL will have this issue as well. A relatively clean solution is to create virtual packages for these, where the user has a choice between the two. The normal config option would be hidden for these packages. This still adds complexity in some corner cases, e.g. some package that doesn't work in luajit, but that can probably be solved at the level of that package.
# Autobuild infrastructure. Thomas is working on scripts that parse the build result and put it in a database. One important missing feature at the moment is visibility of evolution over time (i.e. distinguish regressions from recurring problems). Even more important is just being able to see which packages are failing all the time, i.e. for each package how often it failed. Ideally, we would also want to see how often a package has been built successfully, but when is it successful? Does the entire build have to succeed or that package? Overall, however, the autobuild infrastructure is considered very useful - when something is wrong, it appears in the autobuild very quickly.
#* autobuild of the next branch: if only the master is autobuilt, we don't see a lot of problems until after the release. Delaying fixing bugs makes it more difficult to fix them. To support autobuild of the next branch, this should also be made visible in the database so we can distinguish master failures (more important) from next failures.
#* autobuild database is not suitable to track repeated builds of the same configuration. It needs to keep track of different builds of the same configurations. But the question is if this is really useful. We would like to check the existing defconfigs at every release, but it doesn't have to be tracked. So it can be done manually.
# AVR32. It is end of life as far as Atmel is concerned, but of course there are still products out there using it. It is not really blocking for buildroot. For packages which fail to build, we can just add a ''depends on !BR2_avr32''. But of course, until we have the AVAILABLE mechanism, carrying this kind of dependency can be painful.
# RPC support. Originally, the idea was to consider RPC support as a toolchain option, i.e. using ''depends''. However, libtirpc is really a library, comparable to gettext, so it could be enabled automatically with ''select''. Busybox is special, because we don't want to force RPC just because busybox is selected. Therefore busybox has a user-selectable option to enable RPC-based applets (mount-nfs). After discussion, this option was discarded - just remove mount-nfs from busybox (see below). Other packages will use libtirpc if it was selected (manually or automatically). It's still a question what will happen when dynamically linking against libtirpc when libc also has rpc.
# A bit related: we'll disable mount-nfs in the default busybox config; if user disables RPC and enables mount-nfs in busybox, he'll get a compilation error.
# Support for VCS branches in packages: custom packages are often in a VCS and while developing, you want to track a branch of that VCS. OVERRIDE_SRCDIR doesn't work very well because it means the user has to check everything out at the right version in the right location. An alternative would be to teach OVERRIDE_SRCDIR about VCSes, so that ''make foo-rebuild'' re-syncs with the VCS.
# There is a general feeling (mainly from Thomas) that buildroot isn't very convenient during development of a project where several people are working on several components. But no solution was found.
# FP stuff: we now have a single SOFT_FLOAT option, but actually there's a lot more variation: neon, vfpv3, softfp, .... To support this well, we can add a lot of extra config options to semi-automatically select the correct float options based on the subarchitecture. There is some cross-dependency with the external toolchains, but it's doable. There should still be an option to manually override the float options for exotic cases. ARM thumb adds another layer of complexity. Someone should take the lead on making this easier.
# Porting gcc to the generic package infrastructure. Looks like this is a lot of work, and there's not so much need for it.
# Getting gcc from git. It's more convenient to put a tarball somewhere public and use that as an alternative source, similar to avr32.
# Download helpers are getting too complex. It should move a script so at least it's more readable.
# Community organization:
#* It can be useful to have subsystem maintainers, that are responsible for reviewing and accepting patches. In practice, however, it is difficult to split things in a way that we don't risk duplicating work (i.e. two people in the process of merging the same patch). However, one clearly defined subsystem is the documentation. From now on, Samuel Martin is responsible for all documentation patches. He'll send pull requests to Peter.
#* Patches should be accepted more aggressively, even if there hasn't been (much) testing of the patch. The autobuilders will catch any issues. However, it is still important to properly review and comment on coding style issues (i.e. how the features are implemented. Also, if something really breaks the autobuilder, Thomas can revert it without consulting Peter.
# Out of tree build: this is a feature that people keep on asking. It is particularly useful for packages with an OVERRIDE_SRCDIR. But of course, not all packages support out-of-tree build, and not all packages support it in the same way. For autotools and cmake, it can be automatic; for generic packages, it has to be signalled if out-of-tree build is available.
# legal-info:
#* split _LICENSE and _REDISTRIBUTE: patch proposed by Luca is accepted. Even though there is no proprietary package in buildroot that triggers the feature, if it fails to work as expected the user will hopefully report it.
#* multiple licenses: we don't want to make things very complex. It doesn't have to be machine-readable (we don't need to support machine analysis of the license field), so we don't have to formally decide how the license text must be written. It does make sense to have some convention, though. Proposal: "GPLv2+ or BSD-2c for the library, GPLv2+ for the dtc executable".
# target-clean: purpose is to rebuild the target tree, without rebuilding all packages. The problem is that this looks as if packages are really removed, but there may still be dependencies hidden in the built packages so that the resulting target doesn't work anymore. One idea is to just not have a target dir anymore, but instead reconstruct it from the staging dir every time the fs is built. But this is too much overhead in the usual case. Basically, we prefer to have people do a full make clean if they change anything. We should update the documentation to explain that this is necessary. There was an idea to remove the entire target tree, and just regenerate it on every build. This would simplify the .mk files because for most packages there's no need for INSTALL_TARGET_CMDS anymore (some packages still want to remove stuff), and implicitly does a target-clean (because there is no target dir to begin with), but only for the use case of skeleton changes. In the end, the conclusion was that we don't want to support target-clean, but we'll document why not.
# Regarding out-of-buildroot-tree project stuff: we don't really want to advertise keeping stuff outside of the buildroot tree. Any patches that make that easier will be rejected. But it would be nice to store the result of xxx-menuconfig back to the place where it came from, or warn if that place doesn't exist.

=== Participants ===

# [[User:Arnout_Vandecappelle|Arnout Vandecappelle]], confirmed. Arriving on Fri Nov 2 20:35 at BCN airport. Leaving Wed Nov. 8 21:15 at BCN. Staying at [http://www.hcchotels.es/en/hotel/12/hcc-lugano HCC Lugano]
# [[User:ThomasPetazzoni|Thomas Petazzoni]], confirmed. Arriving on November, 3rd at BCN airport 9:25 AM. Leaving on November 8th from BCN airport at 3:45 PM. Staying at Hotel Fira Palace.
# Maxime Ripard, confirmed. Arriving on November, 1st at BCN airport. Leaving on November 8th from BCP airport at 3:45 PM. Staying at Hotel Fira Palace.
# [[User:PeterKorsgaard|Peter Korsgaard]], confirmed, Arriving on Fri Nov 2 21:55 at BCN airport. Leaving Sun Nov 11 17:15 at BCN. Staying at [http://www.hcchotels.es/en/hotel/12/hcc-lugano HCC Lugano]
# Luca Ceresoli, confirmed. Arriving on November 3rd at BCN airport 10:05 AM. Leaving on November 7th from BCN airport 19:15 PM. Staying at Hotel Fira Palace. Will arrive around 11:30 AM for the meeting.
# Samuel Martin, confirmed. Arriving on November, 3rd at Barcelona-Franca Train Station 8:05 AM. Leaving on November 10th from Barcelona-Franca Train Station at 8:43 PM.
# Simon Dawson, confirmed. Arriving on November 2nd in the evening. Leaving on November 8th early morning.
# Mischa Jonker, confirmed. From Synopsys.com. Not contributing yet to Buildroot, but interested in using Buildroot for a brand new CPU architecture. Arriving Friday Nov 2nd BCN 21:10 CET, staying at Catalonia Barcelona Plaza (Plaza Espanya), leaving Thursday Nov 8 at 18:40 CET.
# Maxime Hadjinlian.

=== Registration ===

Please contact Thomas Petazzoni (thomas.petazzoni@free-electrons.com) if you would like to attend.

Attending the event is free, but registration is required.

=== Program ===

* Saturday, 10 AM: beginning of the meeting. The first person to arrive can go directly to the front desk and ask for MARIBEL SOCIAS or anyone in the Reservations Department, and then ask for the meeting room booked for Thomas Petazzoni. [[User:ThomasPetazzoni|Thomas Petazzoni]] will only arrive at 10:30-11 AM.
* Saturday, 7 PM: end of the meeting
* Saturday, 8:30 PM: dinner sponsored by Synopsys
* Sunday, 10 AM: beginning of the meeting
* Sunday, 7 PM: end of the meeting

=== Location ===

The event will take place at [http://www.hotelgrumsbarcelona.com/ Hotel Grumps], in downtown Barcelona. See [http://goo.gl/maps/htYi9 this map] for the location of the hotel, and [http://goo.gl/maps/GdiaM this map] for walking directions between the Fira Palace hotel (location of the ELCE conference) and Hotel Grums.

=== List of topics to discuss ===

* Interaction between Buildroot configuration options to select architecture specifities (architecture variant, soft-float vs. hard-float, etc.) and the multilib variants available in external toolchains. Proposed by [[User:ThomasPetazzoni]].
* Status on the community organization. Has patchwork improved things? Are patches taken into account in a faster way? Proposed by [[User:ThomasPetazzoni]].
* What are the next "big" things for Buildroot? Proposed by [[User:ThomasPetazzoni]].
* Documentation refactoring? Proposed by Samuel Martin.
* Autobuilder tests: needed improvements, future work. Proposed by [[User:ThomasPetazzoni]].
* The _AVAILABLE mechanism, and how to properly handle dependency on toolchain options (discuss the proposal made by Yann E. Morin). Proposed by [[User:ThomasPetazzoni]].
* Discuss (and, if approved, implement) the split between _LICENSE and _REDISTRIBUTE for legal-info. I think this won't take much more than 10 minutes chat + 10 minutes hack. Proposed by Luca Ceresoli.
* Make it possible to use a git repository as source for toolchain. This doesn't work well today. Proposed by Mischa Jonker
* Make it possible to do a 'target-clean', as a replacement of uninstall. Will this even work at all? Proposed by Arnout Vandecappelle
* Does it make sense to port the toolchains to generic-package infrastructure? Asked by Arnout Vandecappelle
* How to provide licensing info for packages that have more than one license. The main use cases are: a) different parts of the source code have different licenses, b) a file (or the whole project) is distributed under two or more licenses or c) a mix of the two. See the recent thoughts about this issue by Yann Morin: http://lists.busybox.net/pipermail/buildroot/2012-October/060475.html
* Support for board stuff outside the buildroot tree. Proposed by Arnout Vandecappelle
* Should we remove the ability to build a toolchain on the target? And also things like development files on target, documentation on target, etc. Proposed by [[User:ThomasPetazzoni]].

=== List of topics to hack on ===

* Reduce the back log of bugs. Proposed by [[User:ThomasPetazzoni]].
* Reduce the back log of patches. Proposed by [[User:ThomasPetazzoni]].
* Work on noMMU platform support (Blackfin, Coldfire). Getting Coldfire Qemu working, adding correct support for FLAT binaries. Proposed by [[User:ThomasPetazzoni]].
* Package upgrades: package python3, gtk3 and latest versions of glib and al. Proposed by [[User:ThomasPetazzoni]].
* Triage autobuilder failures and fix them. Proposed by Arnout Vandecappelle
* Improve the documentation. Proposed by Arnout Vandecappelle
* Work on relocatable toolchain. Proposed by Arnout Vandecappelle
* Add some infra for setup.py/qmake based packages. Proposed by Samuel Martin
* Add some infra for make based packages (mainly using the same pattern all over). Proposed by Arnout Vandecappelle
* Add some infra for Kconfig based packages (linux, barebox, busybox, uclibc, ct-ng, at91bootstrap3). Proposed by Arnout Vandecappelle
* Make top-level make -j possible. Proposed by Arnout Vandecappelle

Buildroot:DeveloperDaysELCE2012

2012-11-04T18:20:21Z

Arnout Vandecappelle: /* Report of the meeting */

== Buildroot Developers Meeting, 3-4 November 2012, Barcelona Spain ==

=== What is Buildroot ? ===

[http://buildroot.org 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.

=== Meeting in Barcelona ===

The Buildroot community is organizing a meeting on Saturday November 3rd and Sunday November 4th, for Buildroot developers and contributors. This meeting will be a mixture of discussion and hacking session around the Buildroot project. This meeting takes place right before the Embedded Linux Conference Europe, in order to make it easy for participants to attend both events.

=== Event sponsored by Fluendo and Synopsys ===

The meeting room is sponsored by [http://www.fluendo.com Fluendo]. Thanks!

The Saturday dinner is sponsored by [http://www.synopsys.com Synopsys]. Thanks!

=== Report of the meeting ===

==== Action points ====
* Accept perl series.
* Accept qemu series (after further review).
* Remove compiler on target.
* Remove development files on target.
* Remove documentation on target.
* Explain in the documentation why the above was done.
* Put httpd daemons outside BUSYBOX_SHOW_OTHERS.
* Move BUSYBOX_SHOW_OTHERS conditions to ''depends on'' inside the package Config.in
* busybox: disable mount-nfs in the default config.
* simplify patch logic: if pkg-version directory exists, use that; otherwise, use pkg-*.patch.
* Automate selection of correct FP and other compiler options based on subarchitecture.
* Move download helpers to a script.
* Samuel merges documentation patches and sends pull requests to Peter.
* Ask Yann for help regarding the comments in the AVAILABLE framework.
* Document better that you need to do make clean; make instead of make target-clean.

==== Details of the discussion ====

# Perl. The perl patch series (now at v11) looks ready to be integrated, but we have our doubts about cpanminus. The problems are: it has separate download infrastructure, which blocks some buildroot features (e.g. make source); it doesn't integrate with the legal-info. However, CPAN is pretty important if you really want to use perl. The decision was to accept cpanminus as well, but add some warnings that some things don't work.
# Qemu. Adding this opens the door for more people to do stuff that buildroot wasn't meant for in the first place (i.e. embedded). However, even in embedded qemu could be relevant. Things like the compiler on the target are much worse for doing crazy things. Giving new packages a chance is OK; we have to be much more careful with things that have global impact (like including development files on target). Conclusion: it's OK to accept qemu.
# Compiler on target. It leads to newbies using buildroot in an inappropriate way (i.e. compile on the target). Also it only works with the internal toolchain. And if we remove it, we can also remove "Development files on target", which simplifies some of the build infrastructure. Also, if you have a compiler on the target, then you can just as well use a distro. Conclusion: we remove it. Also a bunch of other packages can be removed (autotools, vala, ...)
# Documentation on target: if you need this, use a distro. So we remove it.
# We need to explain in the documentation why we removed this stuff.
# Available stuff: i.e. solve the problem of combination of ''select'' and ''depends''. Solving it in Kconfig itself seems to be difficult: there were some patches but the kconfig people didn't like it; Yann and Thomas looked at Kconfig and it looks difficult to modify. The AVAILABLE solution has two problems: it adds verbosity, and the recursive dependencies still should be written in the comments ("libfoo requires WCHAR in the toolchain"). The verbosity is not considered a big issue. For the comments: they currently don't work perfectly either. Removing the comments altogether is an option, but then it is difficult for users to find out why a certain package isn't available. Another possibility is to list the available packages in the documentation (automatically), and mention which toolchain dependencies they have. Wild idea: consider Config.in as a low-level language, and define our own higher-level language from which we generate Config.in. Alternatively, have a developer tool that verifies if everything is consistent (i.e. are the comments correct). One more option: add a big comment in the beginning of the packages list, which says that not all toolchain options are available so not all packages are visible. Converting the toolchain options from ''depends'' to ''select'' is not really an option, because changing toolchain options requires a make clean. After more discussion on Sunday, we didn't find a solution. For the time being, we stick to the old system. We ask Yann if he has a brilliant idea of how to deal with the comments.
# kconfig-frontend: Yann now has a repository for Kconfig, it would be nice to branch our Kconfig from that. The idea is to still copy it to our repository.
# BUSYBOX_SHOW_OTHERS: the only reason to have this is to avoid newcomers enabling things like tar etc. which are anyway already in busybox. But for the web servers, they are clearly different from the busybox web servers (and our default busybox config doesn't even enable a web server). Also bash is a typical one, because people write bashisms in their scripts. This discussion is somewhat related to the discussion how to handle packages that provide the same functionality. But for many packages, it's not even the same (httpd, bash, vim). But actually, we're trying to solve a non-existent problem here - except for the web servers. If we generate a list of packages in the documentation, we can add a remark to that that it's also available in busybox. Also move the condition inside the package Config.in instead of outside and make it a ''depends on'', so it is more visible.
# packages with multiple variants: python2/3, Qt4/5, gtk2/3, gstreamer0.10/1.0... This is again similar to the expat/libxml2 issue. Do we support both python2 and python3? We need to support both versions in most cases. Question is if we want to force that only one of the two is selected, or do we support side-by-side installation. Conclusion: has to be looked at on a case-by-case basis. General philosophy: don't try to be too smart, so don't try to force selecting only one of the two if it doesn't make sense to have both. In cases where a package wants to ''select'' one of these things, convert the ''select'' into a ''depends'' with a comment. For gstreamer, the complexity of having the two side-by-side is unacceptable, because there are so many fine-grained gstreamer configure options (in the plugins). However, we expect that everything will move to gstreamer1.0 quite quickly, so for the time being (and only if someone needs it), we can live with a non-perfect solution that just fits the requirements of whoever needs gstreamer1.0.
# multiple packages providing the same functionality: lua/luajit, jpeg/jpegturbo, expat/libxml2. These cannot be installed side-by-side, and many packages select e.g. jpeg. OpenGL will have this issue as well. A relatively clean solution is to create virtual packages for these, where the user has a choice between the two. The normal config option would be hidden for these packages. This still adds complexity in some corner cases, e.g. some package that doesn't work in luajit, but that can probably be solved at the level of that package.
# Autobuild infrastructure. Thomas is working on scripts that parse the build result and put it in a database. One important missing feature at the moment is visibility of evolution over time (i.e. distinguish regressions from recurring problems). Even more important is just being able to see which packages are failing all the time, i.e. for each package how often it failed. Ideally, we would also want to see how often a package has been built successfully, but when is it successful? Does the entire build have to succeed or that package? Overall, however, the autobuild infrastructure is considered very useful - when something is wrong, it appears in the autobuild very quickly.
#* autobuild of the next branch: if only the master is autobuilt, we don't see a lot of problems until after the release. Delaying fixing bugs makes it more difficult to fix them. To support autobuild of the next branch, this should also be made visible in the database so we can distinguish master failures (more important) from next failures.
#* autobuild database is not suitable to track repeated builds of the same configuration. It needs to keep track of different builds of the same configurations. But the question is if this is really useful. We would like to check the existing defconfigs at every release, but it doesn't have to be tracked. So it can be done manually.
# AVR32. It is end of life as far as Atmel is concerned, but of course there are still products out there using it. It is not really blocking for buildroot. For packages which fail to build, we can just add a ''depends on !BR2_avr32''. But of course, until we have the AVAILABLE mechanism, carrying this kind of dependency can be painful.
# RPC support. Originally, the idea was to consider RPC support as a toolchain option, i.e. using ''depends''. However, libtirpc is really a library, comparable to gettext, so it could be enabled automatically with ''select''. Busybox is special, because we don't want to force RPC just because busybox is selected. Therefore busybox has a user-selectable option to enable RPC-based applets (mount-nfs). After discussion, this option was discarded - just remove mount-nfs from busybox (see below). Other packages will use libtirpc if it was selected (manually or automatically). It's still a question what will happen when dynamically linking against libtirpc when libc also has rpc.
# A bit related: we'll disable mount-nfs in the default busybox config; if user disables RPC and enables mount-nfs in busybox, he'll get a compilation error.
# Support for VCS branches in packages: custom packages are often in a VCS and while developing, you want to track a branch of that VCS. OVERRIDE_SRCDIR doesn't work very well because it means the user has to check everything out at the right version in the right location. An alternative would be to teach OVERRIDE_SRCDIR about VCSes, so that ''make foo-rebuild'' re-syncs with the VCS.
# There is a general feeling (mainly from Thomas) that buildroot isn't very convenient during development of a project where several people are working on several components. But no solution was found.
# FP stuff: we now have a single SOFT_FLOAT option, but actually there's a lot more variation: neon, vfpv3, softfp, .... To support this well, we can add a lot of extra config options to semi-automatically select the correct float options based on the subarchitecture. There is some cross-dependency with the external toolchains, but it's doable. There should still be an option to manually override the float options for exotic cases. ARM thumb adds another layer of complexity. Someone should take the lead on making this easier.
# Porting gcc to the generic package infrastructure. Looks like this is a lot of work, and there's not so much need for it.
# Getting gcc from git. It's more convenient to put a tarball somewhere public and use that as an alternative source, similar to avr32.
# Download helpers are getting too complex. It should move a script so at least it's more readable.
# Community organization:
#* It can be useful to have subsystem maintainers, that are responsible for reviewing and accepting patches. In practice, however, it is difficult to split things in a way that we don't risk duplicating work (i.e. two people in the process of merging the same patch). However, one clearly defined subsystem is the documentation. From now on, Samuel Martin is responsible for all documentation patches. He'll send pull requests to Peter.
#* Patches should be accepted more aggressively, even if there hasn't been (much) testing of the patch. The autobuilders will catch any issues. However, it is still important to properly review and comment on coding style issues (i.e. how the features are implemented. Also, if something really breaks the autobuilder, Thomas can revert it without consulting Peter.
# Out of tree build: this is a feature that people keep on asking. It is particularly useful for packages with an OVERRIDE_SRCDIR. But of course, not all packages support out-of-tree build, and not all packages support it in the same way. For autotools and cmake, it can be automatic; for generic packages, it has to be signalled if out-of-tree build is available.
# legal-info:
#* split _LICENSE and _REDISTRIBUTE: patch proposed by Luca is accepted. Even though there is no proprietary package in buildroot that triggers the feature, if it fails to work as expected the user will hopefully report it.
#* multiple licenses: we don't want to make things very complex. It doesn't have to be machine-readable (we don't need to support machine analysis of the license field), so we don't have to formally decide how the license text must be written. It does make sense to have some convention, though. Proposal: "GPLv2+ or BSD-2c for the library, GPLv2+ for the dtc executable".
# target-clean: purpose is to rebuild the target tree, without rebuilding all packages. The problem is that this looks as if packages are really removed, but there may still be dependencies hidden in the built packages so that the resulting target doesn't work anymore. One idea is to just not have a target dir anymore, but instead reconstruct it from the staging dir every time the fs is built. But this is too much overhead in the usual case. Basically, we prefer to have people do a full make clean if they change anything. We should update the documentation to explain that this is necessary. There was an idea to remove the entire target tree, and just regenerate it on every build. This would simplify the .mk files because for most packages there's no need for INSTALL_TARGET_CMDS anymore (some packages still want to remove stuff), and implicitly does a target-clean (because there is no target dir to begin with), but only for the use case of skeleton changes. In the end, the conclusion was that we don't want to support target-clean, but we'll document why not.

For tomorrow:
* Support for board stuff outside the buildroot tree. Proposed by Arnout Vandecappelle

=== Participants ===

# [[User:Arnout_Vandecappelle|Arnout Vandecappelle]], confirmed. Arriving on Fri Nov 2 20:35 at BCN airport. Leaving Wed Nov. 8 21:15 at BCN. Staying at [http://www.hcchotels.es/en/hotel/12/hcc-lugano HCC Lugano]
# [[User:ThomasPetazzoni|Thomas Petazzoni]], confirmed. Arriving on November, 3rd at BCN airport 9:25 AM. Leaving on November 8th from BCN airport at 3:45 PM. Staying at Hotel Fira Palace.
# Maxime Ripard, confirmed. Arriving on November, 1st at BCN airport. Leaving on November 8th from BCP airport at 3:45 PM. Staying at Hotel Fira Palace.
# [[User:PeterKorsgaard|Peter Korsgaard]], confirmed, Arriving on Fri Nov 2 21:55 at BCN airport. Leaving Sun Nov 11 17:15 at BCN. Staying at [http://www.hcchotels.es/en/hotel/12/hcc-lugano HCC Lugano]
# Luca Ceresoli, confirmed. Arriving on November 3rd at BCN airport 10:05 AM. Leaving on November 7th from BCN airport 19:15 PM. Staying at Hotel Fira Palace. Will arrive around 11:30 AM for the meeting.
# Samuel Martin, confirmed. Arriving on November, 3rd at Barcelona-Franca Train Station 8:05 AM. Leaving on November 10th from Barcelona-Franca Train Station at 8:43 PM.
# Simon Dawson, confirmed. Arriving on November 2nd in the evening. Leaving on November 8th early morning.
# Mischa Jonker, confirmed. From Synopsys.com. Not contributing yet to Buildroot, but interested in using Buildroot for a brand new CPU architecture. Arriving Friday Nov 2nd BCN 21:10 CET, staying at Catalonia Barcelona Plaza (Plaza Espanya), leaving Thursday Nov 8 at 18:40 CET.
# Maxime Hadjinlian.

=== Registration ===

Please contact Thomas Petazzoni (thomas.petazzoni@free-electrons.com) if you would like to attend.

Attending the event is free, but registration is required.

=== Program ===

* Saturday, 10 AM: beginning of the meeting. The first person to arrive can go directly to the front desk and ask for MARIBEL SOCIAS or anyone in the Reservations Department, and then ask for the meeting room booked for Thomas Petazzoni. [[User:ThomasPetazzoni|Thomas Petazzoni]] will only arrive at 10:30-11 AM.
* Saturday, 7 PM: end of the meeting
* Saturday, 8:30 PM: dinner sponsored by Synopsys
* Sunday, 10 AM: beginning of the meeting
* Sunday, 7 PM: end of the meeting

=== Location ===

The event will take place at [http://www.hotelgrumsbarcelona.com/ Hotel Grumps], in downtown Barcelona. See [http://goo.gl/maps/htYi9 this map] for the location of the hotel, and [http://goo.gl/maps/GdiaM this map] for walking directions between the Fira Palace hotel (location of the ELCE conference) and Hotel Grums.

=== List of topics to discuss ===

* Interaction between Buildroot configuration options to select architecture specifities (architecture variant, soft-float vs. hard-float, etc.) and the multilib variants available in external toolchains. Proposed by [[User:ThomasPetazzoni]].
* Status on the community organization. Has patchwork improved things? Are patches taken into account in a faster way? Proposed by [[User:ThomasPetazzoni]].
* What are the next "big" things for Buildroot? Proposed by [[User:ThomasPetazzoni]].
* Documentation refactoring? Proposed by Samuel Martin.
* Autobuilder tests: needed improvements, future work. Proposed by [[User:ThomasPetazzoni]].
* The _AVAILABLE mechanism, and how to properly handle dependency on toolchain options (discuss the proposal made by Yann E. Morin). Proposed by [[User:ThomasPetazzoni]].
* Discuss (and, if approved, implement) the split between _LICENSE and _REDISTRIBUTE for legal-info. I think this won't take much more than 10 minutes chat + 10 minutes hack. Proposed by Luca Ceresoli.
* Make it possible to use a git repository as source for toolchain. This doesn't work well today. Proposed by Mischa Jonker
* Make it possible to do a 'target-clean', as a replacement of uninstall. Will this even work at all? Proposed by Arnout Vandecappelle
* Does it make sense to port the toolchains to generic-package infrastructure? Asked by Arnout Vandecappelle
* How to provide licensing info for packages that have more than one license. The main use cases are: a) different parts of the source code have different licenses, b) a file (or the whole project) is distributed under two or more licenses or c) a mix of the two. See the recent thoughts about this issue by Yann Morin: http://lists.busybox.net/pipermail/buildroot/2012-October/060475.html
* Support for board stuff outside the buildroot tree. Proposed by Arnout Vandecappelle
* Should we remove the ability to build a toolchain on the target? And also things like development files on target, documentation on target, etc. Proposed by [[User:ThomasPetazzoni]].

=== List of topics to hack on ===

* Reduce the back log of bugs. Proposed by [[User:ThomasPetazzoni]].
* Reduce the back log of patches. Proposed by [[User:ThomasPetazzoni]].
* Work on noMMU platform support (Blackfin, Coldfire). Getting Coldfire Qemu working, adding correct support for FLAT binaries. Proposed by [[User:ThomasPetazzoni]].
* Package upgrades: package python3, gtk3 and latest versions of glib and al. Proposed by [[User:ThomasPetazzoni]].
* Triage autobuilder failures and fix them. Proposed by Arnout Vandecappelle
* Improve the documentation. Proposed by Arnout Vandecappelle
* Work on relocatable toolchain. Proposed by Arnout Vandecappelle
* Add some infra for setup.py/qmake based packages. Proposed by Samuel Martin
* Add some infra for make based packages (mainly using the same pattern all over). Proposed by Arnout Vandecappelle
* Add some infra for Kconfig based packages (linux, barebox, busybox, uclibc, ct-ng, at91bootstrap3). Proposed by Arnout Vandecappelle
* Make top-level make -j possible. Proposed by Arnout Vandecappelle

Buildroot:DeveloperDaysELCE2012

2012-11-04T17:37:10Z

Arnout Vandecappelle: /* Report of the meeting */

== Buildroot Developers Meeting, 3-4 November 2012, Barcelona Spain ==

=== What is Buildroot ? ===

[http://buildroot.org 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.

=== Meeting in Barcelona ===

The Buildroot community is organizing a meeting on Saturday November 3rd and Sunday November 4th, for Buildroot developers and contributors. This meeting will be a mixture of discussion and hacking session around the Buildroot project. This meeting takes place right before the Embedded Linux Conference Europe, in order to make it easy for participants to attend both events.

=== Event sponsored by Fluendo and Synopsys ===

The meeting room is sponsored by [http://www.fluendo.com Fluendo]. Thanks!

The Saturday dinner is sponsored by [http://www.synopsys.com Synopsys]. Thanks!

=== Report of the meeting ===

==== Action points ====
* Accept perl series.
* Accept qemu series (after further review).
* Remove compiler on target.
* Remove development files on target.
* Remove documentation on target.
* Explain in the documentation why the above was done.
* Put httpd daemons outside BUSYBOX_SHOW_OTHERS.
* Move BUSYBOX_SHOW_OTHERS conditions to ''depends on'' inside the package Config.in
* busybox: disable mount-nfs in the default config.
* simplify patch logic: if pkg-version directory exists, use that; otherwise, use pkg-*.patch.
* Automate selection of correct FP and other compiler options based on subarchitecture.
* Move download helpers to a script.
* Samuel merges documentation patches and sends pull requests to Peter.
* Ask Yann for help regarding the comments in the AVAILABLE framework.

==== Details of the discussion ====

# Perl. The perl patch series (now at v11) looks ready to be integrated, but we have our doubts about cpanminus. The problems are: it has separate download infrastructure, which blocks some buildroot features (e.g. make source); it doesn't integrate with the legal-info. However, CPAN is pretty important if you really want to use perl. The decision was to accept cpanminus as well, but add some warnings that some things don't work.
# Qemu. Adding this opens the door for more people to do stuff that buildroot wasn't meant for in the first place (i.e. embedded). However, even in embedded qemu could be relevant. Things like the compiler on the target are much worse for doing crazy things. Giving new packages a chance is OK; we have to be much more careful with things that have global impact (like including development files on target). Conclusion: it's OK to accept qemu.
# Compiler on target. It leads to newbies using buildroot in an inappropriate way (i.e. compile on the target). Also it only works with the internal toolchain. And if we remove it, we can also remove "Development files on target", which simplifies some of the build infrastructure. Also, if you have a compiler on the target, then you can just as well use a distro. Conclusion: we remove it. Also a bunch of other packages can be removed (autotools, vala, ...)
# Documentation on target: if you need this, use a distro. So we remove it.
# We need to explain in the documentation why we removed this stuff.
# Available stuff: i.e. solve the problem of combination of ''select'' and ''depends''. Solving it in Kconfig itself seems to be difficult: there were some patches but the kconfig people didn't like it; Yann and Thomas looked at Kconfig and it looks difficult to modify. The AVAILABLE solution has two problems: it adds verbosity, and the recursive dependencies still should be written in the comments ("libfoo requires WCHAR in the toolchain"). The verbosity is not considered a big issue. For the comments: they currently don't work perfectly either. Removing the comments altogether is an option, but then it is difficult for users to find out why a certain package isn't available. Another possibility is to list the available packages in the documentation (automatically), and mention which toolchain dependencies they have. Wild idea: consider Config.in as a low-level language, and define our own higher-level language from which we generate Config.in. Alternatively, have a developer tool that verifies if everything is consistent (i.e. are the comments correct). One more option: add a big comment in the beginning of the packages list, which says that not all toolchain options are available so not all packages are visible. Converting the toolchain options from ''depends'' to ''select'' is not really an option, because changing toolchain options requires a make clean. After more discussion on Sunday, we didn't find a solution. For the time being, we stick to the old system. We ask Yann if he has a brilliant idea of how to deal with the comments.
# kconfig-frontend: Yann now has a repository for Kconfig, it would be nice to branch our Kconfig from that. The idea is to still copy it to our repository.
# BUSYBOX_SHOW_OTHERS: the only reason to have this is to avoid newcomers enabling things like tar etc. which are anyway already in busybox. But for the web servers, they are clearly different from the busybox web servers (and our default busybox config doesn't even enable a web server). Also bash is a typical one, because people write bashisms in their scripts. This discussion is somewhat related to the discussion how to handle packages that provide the same functionality. But for many packages, it's not even the same (httpd, bash, vim). But actually, we're trying to solve a non-existent problem here - except for the web servers. If we generate a list of packages in the documentation, we can add a remark to that that it's also available in busybox. Also move the condition inside the package Config.in instead of outside and make it a ''depends on'', so it is more visible.
# packages with multiple variants: python2/3, Qt4/5, gtk2/3, gstreamer0.10/1.0... This is again similar to the expat/libxml2 issue. Do we support both python2 and python3? We need to support both versions in most cases. Question is if we want to force that only one of the two is selected, or do we support side-by-side installation. Conclusion: has to be looked at on a case-by-case basis. General philosophy: don't try to be too smart, so don't try to force selecting only one of the two if it doesn't make sense to have both. In cases where a package wants to ''select'' one of these things, convert the ''select'' into a ''depends'' with a comment. For gstreamer, the complexity of having the two side-by-side is unacceptable, because there are so many fine-grained gstreamer configure options (in the plugins). However, we expect that everything will move to gstreamer1.0 quite quickly, so for the time being (and only if someone needs it), we can live with a non-perfect solution that just fits the requirements of whoever needs gstreamer1.0.
# multiple packages providing the same functionality: lua/luajit, jpeg/jpegturbo, expat/libxml2. These cannot be installed side-by-side, and many packages select e.g. jpeg. OpenGL will have this issue as well. A relatively clean solution is to create virtual packages for these, where the user has a choice between the two. The normal config option would be hidden for these packages. This still adds complexity in some corner cases, e.g. some package that doesn't work in luajit, but that can probably be solved at the level of that package.
# Autobuild infrastructure. Thomas is working on scripts that parse the build result and put it in a database. One important missing feature at the moment is visibility of evolution over time (i.e. distinguish regressions from recurring problems). Even more important is just being able to see which packages are failing all the time, i.e. for each package how often it failed. Ideally, we would also want to see how often a package has been built successfully, but when is it successful? Does the entire build have to succeed or that package? Overall, however, the autobuild infrastructure is considered very useful - when something is wrong, it appears in the autobuild very quickly.
#* autobuild of the next branch: if only the master is autobuilt, we don't see a lot of problems until after the release. Delaying fixing bugs makes it more difficult to fix them. To support autobuild of the next branch, this should also be made visible in the database so we can distinguish master failures (more important) from next failures.
#* autobuild database is not suitable to track repeated builds of the same configuration. It needs to keep track of different builds of the same configurations. But the question is if this is really useful. We would like to check the existing defconfigs at every release, but it doesn't have to be tracked. So it can be done manually.
# AVR32. It is end of life as far as Atmel is concerned, but of course there are still products out there using it. It is not really blocking for buildroot. For packages which fail to build, we can just add a ''depends on !BR2_avr32''. But of course, until we have the AVAILABLE mechanism, carrying this kind of dependency can be painful.
# RPC support. Originally, the idea was to consider RPC support as a toolchain option, i.e. using ''depends''. However, libtirpc is really a library, comparable to gettext, so it could be enabled automatically with ''select''. Busybox is special, because we don't want to force RPC just because busybox is selected. Therefore busybox has a user-selectable option to enable RPC-based applets (mount-nfs). After discussion, this option was discarded - just remove mount-nfs from busybox (see below). Other packages will use libtirpc if it was selected (manually or automatically). It's still a question what will happen when dynamically linking against libtirpc when libc also has rpc.
# A bit related: we'll disable mount-nfs in the default busybox config; if user disables RPC and enables mount-nfs in busybox, he'll get a compilation error.
# Support for VCS branches in packages: custom packages are often in a VCS and while developing, you want to track a branch of that VCS. OVERRIDE_SRCDIR doesn't work very well because it means the user has to check everything out at the right version in the right location. An alternative would be to teach OVERRIDE_SRCDIR about VCSes, so that ''make foo-rebuild'' re-syncs with the VCS.
# There is a general feeling (mainly from Thomas) that buildroot isn't very convenient during development of a project where several people are working on several components. But no solution was found.
# FP stuff: we now have a single SOFT_FLOAT option, but actually there's a lot more variation: neon, vfpv3, softfp, .... To support this well, we can add a lot of extra config options to semi-automatically select the correct float options based on the subarchitecture. There is some cross-dependency with the external toolchains, but it's doable. There should still be an option to manually override the float options for exotic cases. ARM thumb adds another layer of complexity. Someone should take the lead on making this easier.
# Porting gcc to the generic package infrastructure. Looks like this is a lot of work, and there's not so much need for it.
# Getting gcc from git. It's more convenient to put a tarball somewhere public and use that as an alternative source, similar to avr32.
# Download helpers are getting too complex. It should move a script so at least it's more readable.
# Community organization:
#* It can be useful to have subsystem maintainers, that are responsible for reviewing and accepting patches. In practice, however, it is difficult to split things in a way that we don't risk duplicating work (i.e. two people in the process of merging the same patch). However, one clearly defined subsystem is the documentation. From now on, Samuel Martin is responsible for all documentation patches. He'll send pull requests to Peter.
#* Patches should be accepted more aggressively, even if there hasn't been (much) testing of the patch. The autobuilders will catch any issues. However, it is still important to properly review and comment on coding style issues (i.e. how the features are implemented. Also, if something really breaks the autobuilder, Thomas can revert it without consulting Peter.
# Out of tree build: this is a feature that people keep on asking. It is particularly useful for packages with an OVERRIDE_SRCDIR. But of course, not all packages support out-of-tree build, and not all packages support it in the same way. For autotools and cmake, it can be automatic; for generic packages, it has to be signalled if out-of-tree build is available.
# legal-info:
#* split _LICENSE and _REDISTRIBUTE: patch proposed by Luca is accepted. Even though there is no proprietary package in buildroot that triggers the feature, if it fails to work as expected the user will hopefully report it.
#* multiple licenses: we don't want to make things very complex. It doesn't have to be machine-readable (we don't need to support machine analysis of the license field), so we don't have to formally decide how the license text must be written. It does make sense to have some convention, though. Proposal: "GPLv2+ or BSD-2c for the library, GPLv2+ for the dtc executable".
# target-clean: purpose is to rebuild the target tree, without rebuilding all packages. The problem is that this looks as if packages are really removed, but there may still be dependencies hidden in the built packages so that the resulting target doesn't work anymore. One idea is to just not have a target dir anymore, but instead reconstruct it from the staging dir every time the fs is built. But this is too much overhead in the usual case. Basically, we prefer to have people do a full make clean if they change anything. We should update the documentation to explain that this is necessary.

For tomorrow:
* Make it possible to do a 'target-clean', as a replacement of uninstall. Will this even work at all? Proposed by Arnout Vandecappelle
* Support for board stuff outside the buildroot tree. Proposed by Arnout Vandecappelle

=== Participants ===

# [[User:Arnout_Vandecappelle|Arnout Vandecappelle]], confirmed. Arriving on Fri Nov 2 20:35 at BCN airport. Leaving Wed Nov. 8 21:15 at BCN. Staying at [http://www.hcchotels.es/en/hotel/12/hcc-lugano HCC Lugano]
# [[User:ThomasPetazzoni|Thomas Petazzoni]], confirmed. Arriving on November, 3rd at BCN airport 9:25 AM. Leaving on November 8th from BCN airport at 3:45 PM. Staying at Hotel Fira Palace.
# Maxime Ripard, confirmed. Arriving on November, 1st at BCN airport. Leaving on November 8th from BCP airport at 3:45 PM. Staying at Hotel Fira Palace.
# [[User:PeterKorsgaard|Peter Korsgaard]], confirmed, Arriving on Fri Nov 2 21:55 at BCN airport. Leaving Sun Nov 11 17:15 at BCN. Staying at [http://www.hcchotels.es/en/hotel/12/hcc-lugano HCC Lugano]
# Luca Ceresoli, confirmed. Arriving on November 3rd at BCN airport 10:05 AM. Leaving on November 7th from BCN airport 19:15 PM. Staying at Hotel Fira Palace. Will arrive around 11:30 AM for the meeting.
# Samuel Martin, confirmed. Arriving on November, 3rd at Barcelona-Franca Train Station 8:05 AM. Leaving on November 10th from Barcelona-Franca Train Station at 8:43 PM.
# Simon Dawson, confirmed. Arriving on November 2nd in the evening. Leaving on November 8th early morning.
# Mischa Jonker, confirmed. From Synopsys.com. Not contributing yet to Buildroot, but interested in using Buildroot for a brand new CPU architecture. Arriving Friday Nov 2nd BCN 21:10 CET, staying at Catalonia Barcelona Plaza (Plaza Espanya), leaving Thursday Nov 8 at 18:40 CET.
# Maxime Hadjinlian.

=== Registration ===

Please contact Thomas Petazzoni (thomas.petazzoni@free-electrons.com) if you would like to attend.

Attending the event is free, but registration is required.

=== Program ===

* Saturday, 10 AM: beginning of the meeting. The first person to arrive can go directly to the front desk and ask for MARIBEL SOCIAS or anyone in the Reservations Department, and then ask for the meeting room booked for Thomas Petazzoni. [[User:ThomasPetazzoni|Thomas Petazzoni]] will only arrive at 10:30-11 AM.
* Saturday, 7 PM: end of the meeting
* Saturday, 8:30 PM: dinner sponsored by Synopsys
* Sunday, 10 AM: beginning of the meeting
* Sunday, 7 PM: end of the meeting

=== Location ===

The event will take place at [http://www.hotelgrumsbarcelona.com/ Hotel Grumps], in downtown Barcelona. See [http://goo.gl/maps/htYi9 this map] for the location of the hotel, and [http://goo.gl/maps/GdiaM this map] for walking directions between the Fira Palace hotel (location of the ELCE conference) and Hotel Grums.

=== List of topics to discuss ===

* Interaction between Buildroot configuration options to select architecture specifities (architecture variant, soft-float vs. hard-float, etc.) and the multilib variants available in external toolchains. Proposed by [[User:ThomasPetazzoni]].
* Status on the community organization. Has patchwork improved things? Are patches taken into account in a faster way? Proposed by [[User:ThomasPetazzoni]].
* What are the next "big" things for Buildroot? Proposed by [[User:ThomasPetazzoni]].
* Documentation refactoring? Proposed by Samuel Martin.
* Autobuilder tests: needed improvements, future work. Proposed by [[User:ThomasPetazzoni]].
* The _AVAILABLE mechanism, and how to properly handle dependency on toolchain options (discuss the proposal made by Yann E. Morin). Proposed by [[User:ThomasPetazzoni]].
* Discuss (and, if approved, implement) the split between _LICENSE and _REDISTRIBUTE for legal-info. I think this won't take much more than 10 minutes chat + 10 minutes hack. Proposed by Luca Ceresoli.
* Make it possible to use a git repository as source for toolchain. This doesn't work well today. Proposed by Mischa Jonker
* Make it possible to do a 'target-clean', as a replacement of uninstall. Will this even work at all? Proposed by Arnout Vandecappelle
* Does it make sense to port the toolchains to generic-package infrastructure? Asked by Arnout Vandecappelle
* How to provide licensing info for packages that have more than one license. The main use cases are: a) different parts of the source code have different licenses, b) a file (or the whole project) is distributed under two or more licenses or c) a mix of the two. See the recent thoughts about this issue by Yann Morin: http://lists.busybox.net/pipermail/buildroot/2012-October/060475.html
* Support for board stuff outside the buildroot tree. Proposed by Arnout Vandecappelle
* Should we remove the ability to build a toolchain on the target? And also things like development files on target, documentation on target, etc. Proposed by [[User:ThomasPetazzoni]].

=== List of topics to hack on ===

* Reduce the back log of bugs. Proposed by [[User:ThomasPetazzoni]].
* Reduce the back log of patches. Proposed by [[User:ThomasPetazzoni]].
* Work on noMMU platform support (Blackfin, Coldfire). Getting Coldfire Qemu working, adding correct support for FLAT binaries. Proposed by [[User:ThomasPetazzoni]].
* Package upgrades: package python3, gtk3 and latest versions of glib and al. Proposed by [[User:ThomasPetazzoni]].
* Triage autobuilder failures and fix them. Proposed by Arnout Vandecappelle
* Improve the documentation. Proposed by Arnout Vandecappelle
* Work on relocatable toolchain. Proposed by Arnout Vandecappelle
* Add some infra for setup.py/qmake based packages. Proposed by Samuel Martin
* Add some infra for make based packages (mainly using the same pattern all over). Proposed by Arnout Vandecappelle
* Add some infra for Kconfig based packages (linux, barebox, busybox, uclibc, ct-ng, at91bootstrap3). Proposed by Arnout Vandecappelle
* Make top-level make -j possible. Proposed by Arnout Vandecappelle

Buildroot:DeveloperDaysELCE2012

2012-11-04T17:24:52Z

Arnout Vandecappelle: /* Report of the meeting */

== Buildroot Developers Meeting, 3-4 November 2012, Barcelona Spain ==

=== What is Buildroot ? ===

[http://buildroot.org 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.

=== Meeting in Barcelona ===

The Buildroot community is organizing a meeting on Saturday November 3rd and Sunday November 4th, for Buildroot developers and contributors. This meeting will be a mixture of discussion and hacking session around the Buildroot project. This meeting takes place right before the Embedded Linux Conference Europe, in order to make it easy for participants to attend both events.

=== Event sponsored by Fluendo and Synopsys ===

The meeting room is sponsored by [http://www.fluendo.com Fluendo]. Thanks!

The Saturday dinner is sponsored by [http://www.synopsys.com Synopsys]. Thanks!

=== Report of the meeting ===

==== Action points ====
* Accept perl series.
* Accept qemu series (after further review).
* Remove compiler on target.
* Remove development files on target.
* Remove documentation on target.
* Explain in the documentation why the above was done.
* Put httpd daemons outside BUSYBOX_SHOW_OTHERS.
* Move BUSYBOX_SHOW_OTHERS conditions to ''depends on'' inside the package Config.in
* busybox: disable mount-nfs in the default config.
* simplify patch logic: if pkg-version directory exists, use that; otherwise, use pkg-*.patch.
* Automate selection of correct FP and other compiler options based on subarchitecture.
* Move download helpers to a script.
* Samuel merges documentation patches and sends pull requests to Peter.
* Ask Yann for help regarding the comments in the AVAILABLE framework.

==== Details of the discussion ====

# Perl. The perl patch series (now at v11) looks ready to be integrated, but we have our doubts about cpanminus. The problems are: it has separate download infrastructure, which blocks some buildroot features (e.g. make source); it doesn't integrate with the legal-info. However, CPAN is pretty important if you really want to use perl. The decision was to accept cpanminus as well, but add some warnings that some things don't work.
# Qemu. Adding this opens the door for more people to do stuff that buildroot wasn't meant for in the first place (i.e. embedded). However, even in embedded qemu could be relevant. Things like the compiler on the target are much worse for doing crazy things. Giving new packages a chance is OK; we have to be much more careful with things that have global impact (like including development files on target). Conclusion: it's OK to accept qemu.
# Compiler on target. It leads to newbies using buildroot in an inappropriate way (i.e. compile on the target). Also it only works with the internal toolchain. And if we remove it, we can also remove "Development files on target", which simplifies some of the build infrastructure. Also, if you have a compiler on the target, then you can just as well use a distro. Conclusion: we remove it. Also a bunch of other packages can be removed (autotools, vala, ...)
# Documentation on target: if you need this, use a distro. So we remove it.
# We need to explain in the documentation why we removed this stuff.
# Available stuff: i.e. solve the problem of combination of ''select'' and ''depends''. Solving it in Kconfig itself seems to be difficult: there were some patches but the kconfig people didn't like it; Yann and Thomas looked at Kconfig and it looks difficult to modify. The AVAILABLE solution has two problems: it adds verbosity, and the recursive dependencies still should be written in the comments ("libfoo requires WCHAR in the toolchain"). The verbosity is not considered a big issue. For the comments: they currently don't work perfectly either. Removing the comments altogether is an option, but then it is difficult for users to find out why a certain package isn't available. Another possibility is to list the available packages in the documentation (automatically), and mention which toolchain dependencies they have. Wild idea: consider Config.in as a low-level language, and define our own higher-level language from which we generate Config.in. Alternatively, have a developer tool that verifies if everything is consistent (i.e. are the comments correct). One more option: add a big comment in the beginning of the packages list, which says that not all toolchain options are available so not all packages are visible. Converting the toolchain options from ''depends'' to ''select'' is not really an option, because changing toolchain options requires a make clean. After more discussion on Sunday, we didn't find a solution. For the time being, we stick to the old system. We ask Yann if he has a brilliant idea of how to deal with the comments.
# kconfig-frontend: Yann now has a repository for Kconfig, it would be nice to branch our Kconfig from that. The idea is to still copy it to our repository.
# BUSYBOX_SHOW_OTHERS: the only reason to have this is to avoid newcomers enabling things like tar etc. which are anyway already in busybox. But for the web servers, they are clearly different from the busybox web servers (and our default busybox config doesn't even enable a web server). Also bash is a typical one, because people write bashisms in their scripts. This discussion is somewhat related to the discussion how to handle packages that provide the same functionality. But for many packages, it's not even the same (httpd, bash, vim). But actually, we're trying to solve a non-existent problem here - except for the web servers. If we generate a list of packages in the documentation, we can add a remark to that that it's also available in busybox. Also move the condition inside the package Config.in instead of outside and make it a ''depends on'', so it is more visible.
# packages with multiple variants: python2/3, Qt4/5, gtk2/3, gstreamer0.10/1.0... This is again similar to the expat/libxml2 issue. Do we support both python2 and python3? We need to support both versions in most cases. Question is if we want to force that only one of the two is selected, or do we support side-by-side installation. Conclusion: has to be looked at on a case-by-case basis. General philosophy: don't try to be too smart, so don't try to force selecting only one of the two if it doesn't make sense to have both. In cases where a package wants to ''select'' one of these things, convert the ''select'' into a ''depends'' with a comment. For gstreamer, the complexity of having the two side-by-side is unacceptable, because there are so many fine-grained gstreamer configure options (in the plugins). However, we expect that everything will move to gstreamer1.0 quite quickly, so for the time being (and only if someone needs it), we can live with a non-perfect solution that just fits the requirements of whoever needs gstreamer1.0.
# multiple packages providing the same functionality: lua/luajit, jpeg/jpegturbo, expat/libxml2. These cannot be installed side-by-side, and many packages select e.g. jpeg. OpenGL will have this issue as well. A relatively clean solution is to create virtual packages for these, where the user has a choice between the two. The normal config option would be hidden for these packages. This still adds complexity in some corner cases, e.g. some package that doesn't work in luajit, but that can probably be solved at the level of that package.
# Autobuild infrastructure. Thomas is working on scripts that parse the build result and put it in a database. One important missing feature at the moment is visibility of evolution over time (i.e. distinguish regressions from recurring problems). Even more important is just being able to see which packages are failing all the time, i.e. for each package how often it failed. Ideally, we would also want to see how often a package has been built successfully, but when is it successful? Does the entire build have to succeed or that package? Overall, however, the autobuild infrastructure is considered very useful - when something is wrong, it appears in the autobuild very quickly.
#* autobuild of the next branch: if only the master is autobuilt, we don't see a lot of problems until after the release. Delaying fixing bugs makes it more difficult to fix them. To support autobuild of the next branch, this should also be made visible in the database so we can distinguish master failures (more important) from next failures.
#* autobuild database is not suitable to track repeated builds of the same configuration. It needs to keep track of different builds of the same configurations. But the question is if this is really useful. We would like to check the existing defconfigs at every release, but it doesn't have to be tracked. So it can be done manually.
# AVR32. It is end of life as far as Atmel is concerned, but of course there are still products out there using it. It is not really blocking for buildroot. For packages which fail to build, we can just add a ''depends on !BR2_avr32''. But of course, until we have the AVAILABLE mechanism, carrying this kind of dependency can be painful.
# RPC support. Originally, the idea was to consider RPC support as a toolchain option, i.e. using ''depends''. However, libtirpc is really a library, comparable to gettext, so it could be enabled automatically with ''select''. Busybox is special, because we don't want to force RPC just because busybox is selected. Therefore busybox has a user-selectable option to enable RPC-based applets (mount-nfs). After discussion, this option was discarded - just remove mount-nfs from busybox (see below). Other packages will use libtirpc if it was selected (manually or automatically). It's still a question what will happen when dynamically linking against libtirpc when libc also has rpc.
# A bit related: we'll disable mount-nfs in the default busybox config; if user disables RPC and enables mount-nfs in busybox, he'll get a compilation error.
# Support for VCS branches in packages: custom packages are often in a VCS and while developing, you want to track a branch of that VCS. OVERRIDE_SRCDIR doesn't work very well because it means the user has to check everything out at the right version in the right location. An alternative would be to teach OVERRIDE_SRCDIR about VCSes, so that ''make foo-rebuild'' re-syncs with the VCS.
# There is a general feeling (mainly from Thomas) that buildroot isn't very convenient during development of a project where several people are working on several components. But no solution was found.
# FP stuff: we now have a single SOFT_FLOAT option, but actually there's a lot more variation: neon, vfpv3, softfp, .... To support this well, we can add a lot of extra config options to semi-automatically select the correct float options based on the subarchitecture. There is some cross-dependency with the external toolchains, but it's doable. There should still be an option to manually override the float options for exotic cases. ARM thumb adds another layer of complexity. Someone should take the lead on making this easier.
# Porting gcc to the generic package infrastructure. Looks like this is a lot of work, and there's not so much need for it.
# Getting gcc from git. It's more convenient to put a tarball somewhere public and use that as an alternative source, similar to avr32.
# Download helpers are getting too complex. It should move a script so at least it's more readable.
# Community organization:
#* It can be useful to have subsystem maintainers, that are responsible for reviewing and accepting patches. In practice, however, it is difficult to split things in a way that we don't risk duplicating work (i.e. two people in the process of merging the same patch). However, one clearly defined subsystem is the documentation. From now on, Samuel Martin is responsible for all documentation patches. He'll send pull requests to Peter.
#* Patches should be accepted more aggressively, even if there hasn't been (much) testing of the patch. The autobuilders will catch any issues. However, it is still important to properly review and comment on coding style issues (i.e. how the features are implemented. Also, if something really breaks the autobuilder, Thomas can revert it without consulting Peter.
# Out of tree build: this is a feature that people keep on asking. It is particularly useful for packages with an OVERRIDE_SRCDIR. But of course, not all packages support out-of-tree build, and not all packages support it in the same way. For autotools and cmake, it can be automatic; for generic packages, it has to be signalled if out-of-tree build is available.
# legal-info:
#* split _LICENSE and _REDISTRIBUTE: patch proposed by Luca is accepted. Even though there is no proprietary package in buildroot that triggers the feature, if it fails to work as expected the user will hopefully report it.
#* multiple licenses: we don't want to make things very complex. It doesn't have to be machine-readable (we don't need to support machine analysis of the license field), so we don't have to formally decide how the license text must be written. It does make sense to have some convention, though. Proposal: "GPLv2+ or BSD-2c for the library, GPLv2+ for the dtc executable".
# target-clean: purpose is to rebuild the target tree, without rebuilding all packages. The problem is that this looks as if packages are really removed, but there may still be dependencies hidden in the built packages so that the resulting target doesn't work anymore. One idea is to just not have a target dir anymore, but instead reconstruct it from the staging dir every time the fs is built. But this is too much overhead in the usual case.

For tomorrow:
* Make it possible to do a 'target-clean', as a replacement of uninstall. Will this even work at all? Proposed by Arnout Vandecappelle
* Support for board stuff outside the buildroot tree. Proposed by Arnout Vandecappelle

=== Participants ===

# [[User:Arnout_Vandecappelle|Arnout Vandecappelle]], confirmed. Arriving on Fri Nov 2 20:35 at BCN airport. Leaving Wed Nov. 8 21:15 at BCN. Staying at [http://www.hcchotels.es/en/hotel/12/hcc-lugano HCC Lugano]
# [[User:ThomasPetazzoni|Thomas Petazzoni]], confirmed. Arriving on November, 3rd at BCN airport 9:25 AM. Leaving on November 8th from BCN airport at 3:45 PM. Staying at Hotel Fira Palace.
# Maxime Ripard, confirmed. Arriving on November, 1st at BCN airport. Leaving on November 8th from BCP airport at 3:45 PM. Staying at Hotel Fira Palace.
# [[User:PeterKorsgaard|Peter Korsgaard]], confirmed, Arriving on Fri Nov 2 21:55 at BCN airport. Leaving Sun Nov 11 17:15 at BCN. Staying at [http://www.hcchotels.es/en/hotel/12/hcc-lugano HCC Lugano]
# Luca Ceresoli, confirmed. Arriving on November 3rd at BCN airport 10:05 AM. Leaving on November 7th from BCN airport 19:15 PM. Staying at Hotel Fira Palace. Will arrive around 11:30 AM for the meeting.
# Samuel Martin, confirmed. Arriving on November, 3rd at Barcelona-Franca Train Station 8:05 AM. Leaving on November 10th from Barcelona-Franca Train Station at 8:43 PM.
# Simon Dawson, confirmed. Arriving on November 2nd in the evening. Leaving on November 8th early morning.
# Mischa Jonker, confirmed. From Synopsys.com. Not contributing yet to Buildroot, but interested in using Buildroot for a brand new CPU architecture. Arriving Friday Nov 2nd BCN 21:10 CET, staying at Catalonia Barcelona Plaza (Plaza Espanya), leaving Thursday Nov 8 at 18:40 CET.
# Maxime Hadjinlian.

=== Registration ===

Please contact Thomas Petazzoni (thomas.petazzoni@free-electrons.com) if you would like to attend.

Attending the event is free, but registration is required.

=== Program ===

* Saturday, 10 AM: beginning of the meeting. The first person to arrive can go directly to the front desk and ask for MARIBEL SOCIAS or anyone in the Reservations Department, and then ask for the meeting room booked for Thomas Petazzoni. [[User:ThomasPetazzoni|Thomas Petazzoni]] will only arrive at 10:30-11 AM.
* Saturday, 7 PM: end of the meeting
* Saturday, 8:30 PM: dinner sponsored by Synopsys
* Sunday, 10 AM: beginning of the meeting
* Sunday, 7 PM: end of the meeting

=== Location ===

The event will take place at [http://www.hotelgrumsbarcelona.com/ Hotel Grumps], in downtown Barcelona. See [http://goo.gl/maps/htYi9 this map] for the location of the hotel, and [http://goo.gl/maps/GdiaM this map] for walking directions between the Fira Palace hotel (location of the ELCE conference) and Hotel Grums.

=== List of topics to discuss ===

* Interaction between Buildroot configuration options to select architecture specifities (architecture variant, soft-float vs. hard-float, etc.) and the multilib variants available in external toolchains. Proposed by [[User:ThomasPetazzoni]].
* Status on the community organization. Has patchwork improved things? Are patches taken into account in a faster way? Proposed by [[User:ThomasPetazzoni]].
* What are the next "big" things for Buildroot? Proposed by [[User:ThomasPetazzoni]].
* Documentation refactoring? Proposed by Samuel Martin.
* Autobuilder tests: needed improvements, future work. Proposed by [[User:ThomasPetazzoni]].
* The _AVAILABLE mechanism, and how to properly handle dependency on toolchain options (discuss the proposal made by Yann E. Morin). Proposed by [[User:ThomasPetazzoni]].
* Discuss (and, if approved, implement) the split between _LICENSE and _REDISTRIBUTE for legal-info. I think this won't take much more than 10 minutes chat + 10 minutes hack. Proposed by Luca Ceresoli.
* Make it possible to use a git repository as source for toolchain. This doesn't work well today. Proposed by Mischa Jonker
* Make it possible to do a 'target-clean', as a replacement of uninstall. Will this even work at all? Proposed by Arnout Vandecappelle
* Does it make sense to port the toolchains to generic-package infrastructure? Asked by Arnout Vandecappelle
* How to provide licensing info for packages that have more than one license. The main use cases are: a) different parts of the source code have different licenses, b) a file (or the whole project) is distributed under two or more licenses or c) a mix of the two. See the recent thoughts about this issue by Yann Morin: http://lists.busybox.net/pipermail/buildroot/2012-October/060475.html
* Support for board stuff outside the buildroot tree. Proposed by Arnout Vandecappelle
* Should we remove the ability to build a toolchain on the target? And also things like development files on target, documentation on target, etc. Proposed by [[User:ThomasPetazzoni]].

=== List of topics to hack on ===

* Reduce the back log of bugs. Proposed by [[User:ThomasPetazzoni]].
* Reduce the back log of patches. Proposed by [[User:ThomasPetazzoni]].
* Work on noMMU platform support (Blackfin, Coldfire). Getting Coldfire Qemu working, adding correct support for FLAT binaries. Proposed by [[User:ThomasPetazzoni]].
* Package upgrades: package python3, gtk3 and latest versions of glib and al. Proposed by [[User:ThomasPetazzoni]].
* Triage autobuilder failures and fix them. Proposed by Arnout Vandecappelle
* Improve the documentation. Proposed by Arnout Vandecappelle
* Work on relocatable toolchain. Proposed by Arnout Vandecappelle
* Add some infra for setup.py/qmake based packages. Proposed by Samuel Martin
* Add some infra for make based packages (mainly using the same pattern all over). Proposed by Arnout Vandecappelle
* Add some infra for Kconfig based packages (linux, barebox, busybox, uclibc, ct-ng, at91bootstrap3). Proposed by Arnout Vandecappelle
* Make top-level make -j possible. Proposed by Arnout Vandecappelle

Buildroot:DeveloperDaysELCE2012

2012-11-04T17:09:47Z

Arnout Vandecappelle: /* Report of the meeting */

== Buildroot Developers Meeting, 3-4 November 2012, Barcelona Spain ==

=== What is Buildroot ? ===

[http://buildroot.org 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.

=== Meeting in Barcelona ===

The Buildroot community is organizing a meeting on Saturday November 3rd and Sunday November 4th, for Buildroot developers and contributors. This meeting will be a mixture of discussion and hacking session around the Buildroot project. This meeting takes place right before the Embedded Linux Conference Europe, in order to make it easy for participants to attend both events.

=== Event sponsored by Fluendo and Synopsys ===

The meeting room is sponsored by [http://www.fluendo.com Fluendo]. Thanks!

The Saturday dinner is sponsored by [http://www.synopsys.com Synopsys]. Thanks!

=== Report of the meeting ===

==== Action points ====
* Accept perl series.
* Accept qemu series (after further review).
* Remove compiler on target.
* Remove development files on target.
* Remove documentation on target.
* Explain in the documentation why the above was done.
* Put httpd daemons outside BUSYBOX_SHOW_OTHERS.
* Move BUSYBOX_SHOW_OTHERS conditions to ''depends on'' inside the package Config.in
* busybox: disable mount-nfs in the default config.
* simplify patch logic: if pkg-version directory exists, use that; otherwise, use pkg-*.patch.
* Automate selection of correct FP and other compiler options based on subarchitecture.
* Move download helpers to a script.
* Samuel merges documentation patches and sends pull requests to Peter.

==== Details of the discussion ====

# Perl. The perl patch series (now at v11) looks ready to be integrated, but we have our doubts about cpanminus. The problems are: it has separate download infrastructure, which blocks some buildroot features (e.g. make source); it doesn't integrate with the legal-info. However, CPAN is pretty important if you really want to use perl. The decision was to accept cpanminus as well, but add some warnings that some things don't work.
# Qemu. Adding this opens the door for more people to do stuff that buildroot wasn't meant for in the first place (i.e. embedded). However, even in embedded qemu could be relevant. Things like the compiler on the target are much worse for doing crazy things. Giving new packages a chance is OK; we have to be much more careful with things that have global impact (like including development files on target). Conclusion: it's OK to accept qemu.
# Compiler on target. It leads to newbies using buildroot in an inappropriate way (i.e. compile on the target). Also it only works with the internal toolchain. And if we remove it, we can also remove "Development files on target", which simplifies some of the build infrastructure. Also, if you have a compiler on the target, then you can just as well use a distro. Conclusion: we remove it. Also a bunch of other packages can be removed (autotools, vala, ...)
# Documentation on target: if you need this, use a distro. So we remove it.
# We need to explain in the documentation why we removed this stuff.
# Available stuff: i.e. solve the problem of combination of ''select'' and ''depends''. Solving it in Kconfig itself seems to be difficult: there were some patches but the kconfig people didn't like it; Yann and Thomas looked at Kconfig and it looks difficult to modify. The AVAILABLE solution has two problems: it adds verbosity, and the recursive dependencies still should be written in the comments ("libfoo requires WCHAR in the toolchain"). The verbosity is not considered a big issue. For the comments: they currently don't work perfectly either. Removing the comments altogether is an option, but then it is difficult for users to find out why a certain package isn't available. Another possibility is to list the available packages in the documentation (automatically), and mention which toolchain dependencies they have. Wild idea: consider Config.in as a low-level language, and define our own higher-level language from which we generate Config.in. Alternatively, have a developer tool that verifies if everything is consistent (i.e. are the comments correct). One more option: add a big comment in the beginning of the packages list, which says that not all toolchain options are available so not all packages are visible. Converting the toolchain options from ''depends'' to ''select'' is not really an option, because changing toolchain options requires a make clean. After more discussion on Sunday, we didn't find a solution. For the time being, we stick to the old system. We ask Yann if he has a brilliant idea of how to deal with the comments.
# kconfig-frontend: Yann now has a repository for Kconfig, it would be nice to branch our Kconfig from that. The idea is to still copy it to our repository.
# BUSYBOX_SHOW_OTHERS: the only reason to have this is to avoid newcomers enabling things like tar etc. which are anyway already in busybox. But for the web servers, they are clearly different from the busybox web servers (and our default busybox config doesn't even enable a web server). Also bash is a typical one, because people write bashisms in their scripts. This discussion is somewhat related to the discussion how to handle packages that provide the same functionality. But for many packages, it's not even the same (httpd, bash, vim). But actually, we're trying to solve a non-existent problem here - except for the web servers. If we generate a list of packages in the documentation, we can add a remark to that that it's also available in busybox. Also move the condition inside the package Config.in instead of outside and make it a ''depends on'', so it is more visible.
# packages with multiple variants: python2/3, Qt4/5, gtk2/3, gstreamer0.10/1.0... This is again similar to the expat/libxml2 issue. Do we support both python2 and python3? We need to support both versions in most cases. Question is if we want to force that only one of the two is selected, or do we support side-by-side installation. Conclusion: has to be looked at on a case-by-case basis. General philosophy: don't try to be too smart, so don't try to force selecting only one of the two if it doesn't make sense to have both. In cases where a package wants to ''select'' one of these things, convert the ''select'' into a ''depends'' with a comment. For gstreamer, the complexity of having the two side-by-side is unacceptable, because there are so many fine-grained gstreamer configure options (in the plugins). However, we expect that everything will move to gstreamer1.0 quite quickly, so for the time being (and only if someone needs it), we can live with a non-perfect solution that just fits the requirements of whoever needs gstreamer1.0.
# multiple packages providing the same functionality: lua/luajit, jpeg/jpegturbo, expat/libxml2. These cannot be installed side-by-side, and many packages select e.g. jpeg. OpenGL will have this issue as well. A relatively clean solution is to create virtual packages for these, where the user has a choice between the two. The normal config option would be hidden for these packages. This still adds complexity in some corner cases, e.g. some package that doesn't work in luajit, but that can probably be solved at the level of that package.
# Autobuild infrastructure. Thomas is working on scripts that parse the build result and put it in a database. One important missing feature at the moment is visibility of evolution over time (i.e. distinguish regressions from recurring problems). Even more important is just being able to see which packages are failing all the time, i.e. for each package how often it failed. Ideally, we would also want to see how often a package has been built successfully, but when is it successful? Does the entire build have to succeed or that package? Overall, however, the autobuild infrastructure is considered very useful - when something is wrong, it appears in the autobuild very quickly.
#* autobuild of the next branch: if only the master is autobuilt, we don't see a lot of problems until after the release. Delaying fixing bugs makes it more difficult to fix them. To support autobuild of the next branch, this should also be made visible in the database so we can distinguish master failures (more important) from next failures.
#* autobuild database is not suitable to track repeated builds of the same configuration. It needs to keep track of different builds of the same configurations. But the question is if this is really useful. We would like to check the existing defconfigs at every release, but it doesn't have to be tracked. So it can be done manually.
# AVR32. It is end of life as far as Atmel is concerned, but of course there are still products out there using it. It is not really blocking for buildroot. For packages which fail to build, we can just add a ''depends on !BR2_avr32''. But of course, until we have the AVAILABLE mechanism, carrying this kind of dependency can be painful.
# RPC support. Originally, the idea was to consider RPC support as a toolchain option, i.e. using ''depends''. However, libtirpc is really a library, comparable to gettext, so it could be enabled automatically with ''select''. Busybox is special, because we don't want to force RPC just because busybox is selected. Therefore busybox has a user-selectable option to enable RPC-based applets (mount-nfs). After discussion, this option was discarded - just remove mount-nfs from busybox (see below). Other packages will use libtirpc if it was selected (manually or automatically). It's still a question what will happen when dynamically linking against libtirpc when libc also has rpc.
# A bit related: we'll disable mount-nfs in the default busybox config; if user disables RPC and enables mount-nfs in busybox, he'll get a compilation error.
# Support for VCS branches in packages: custom packages are often in a VCS and while developing, you want to track a branch of that VCS. OVERRIDE_SRCDIR doesn't work very well because it means the user has to check everything out at the right version in the right location. An alternative would be to teach OVERRIDE_SRCDIR about VCSes, so that ''make foo-rebuild'' re-syncs with the VCS.
# There is a general feeling (mainly from Thomas) that buildroot isn't very convenient during development of a project where several people are working on several components. But no solution was found.
# FP stuff: we now have a single SOFT_FLOAT option, but actually there's a lot more variation: neon, vfpv3, softfp, .... To support this well, we can add a lot of extra config options to semi-automatically select the correct float options based on the subarchitecture. There is some cross-dependency with the external toolchains, but it's doable. There should still be an option to manually override the float options for exotic cases. ARM thumb adds another layer of complexity. Someone should take the lead on making this easier.
# Porting gcc to the generic package infrastructure. Looks like this is a lot of work, and there's not so much need for it.
# Getting gcc from git. It's more convenient to put a tarball somewhere public and use that as an alternative source, similar to avr32.
# Download helpers are getting too complex. It should move a script so at least it's more readable.
# Community organization:
#* It can be useful to have subsystem maintainers, that are responsible for reviewing and accepting patches. In practice, however, it is difficult to split things in a way that we don't risk duplicating work (i.e. two people in the process of merging the same patch). However, one clearly defined subsystem is the documentation. From now on, Samuel Martin is responsible for all documentation patches. He'll send pull requests to Peter.
#* Patches should be accepted more aggressively, even if there hasn't been (much) testing of the patch. The autobuilders will catch any issues. However, it is still important to properly review and comment on coding style issues (i.e. how the features are implemented. Also, if something really breaks the autobuilder, Thomas can revert it without consulting Peter.
# Out of tree build: this is a feature that people keep on asking. It is particularly useful for packages with an OVERRIDE_SRCDIR. But of course, not all packages support out-of-tree build, and not all packages support it in the same way. For autotools and cmake, it can be automatic; for generic packages, it has to be signalled if out-of-tree build is available.
# legal-info:
#* split _LICENSE and _REDISTRIBUTE: patch proposed by Luca is accepted. Even though there is no proprietary package in buildroot that triggers the feature, if it fails to work as expected the user will hopefully report it.
#* multiple licenses: we don't want to make things very complex. It doesn't have to be machine-readable (we don't need to support machine analysis of the license field), so we don't have to formally decide how the license text must be written. It does make sense to have some convention, though. Proposal: "GPLv2+ or BSD-2c for the library, GPLv2+ for the dtc executable".

For tomorrow:
* The _AVAILABLE mechanism, and how to properly handle dependency on toolchain options (discuss the proposal made by Yann E. Morin). Proposed by [[User:ThomasPetazzoni]].
* Make it possible to do a 'target-clean', as a replacement of uninstall. Will this even work at all? Proposed by Arnout Vandecappelle
* Support for board stuff outside the buildroot tree. Proposed by Arnout Vandecappelle

=== Participants ===

# [[User:Arnout_Vandecappelle|Arnout Vandecappelle]], confirmed. Arriving on Fri Nov 2 20:35 at BCN airport. Leaving Wed Nov. 8 21:15 at BCN. Staying at [http://www.hcchotels.es/en/hotel/12/hcc-lugano HCC Lugano]
# [[User:ThomasPetazzoni|Thomas Petazzoni]], confirmed. Arriving on November, 3rd at BCN airport 9:25 AM. Leaving on November 8th from BCN airport at 3:45 PM. Staying at Hotel Fira Palace.
# Maxime Ripard, confirmed. Arriving on November, 1st at BCN airport. Leaving on November 8th from BCP airport at 3:45 PM. Staying at Hotel Fira Palace.
# [[User:PeterKorsgaard|Peter Korsgaard]], confirmed, Arriving on Fri Nov 2 21:55 at BCN airport. Leaving Sun Nov 11 17:15 at BCN. Staying at [http://www.hcchotels.es/en/hotel/12/hcc-lugano HCC Lugano]
# Luca Ceresoli, confirmed. Arriving on November 3rd at BCN airport 10:05 AM. Leaving on November 7th from BCN airport 19:15 PM. Staying at Hotel Fira Palace. Will arrive around 11:30 AM for the meeting.
# Samuel Martin, confirmed. Arriving on November, 3rd at Barcelona-Franca Train Station 8:05 AM. Leaving on November 10th from Barcelona-Franca Train Station at 8:43 PM.
# Simon Dawson, confirmed. Arriving on November 2nd in the evening. Leaving on November 8th early morning.
# Mischa Jonker, confirmed. From Synopsys.com. Not contributing yet to Buildroot, but interested in using Buildroot for a brand new CPU architecture. Arriving Friday Nov 2nd BCN 21:10 CET, staying at Catalonia Barcelona Plaza (Plaza Espanya), leaving Thursday Nov 8 at 18:40 CET.
# Maxime Hadjinlian.

=== Registration ===

Please contact Thomas Petazzoni (thomas.petazzoni@free-electrons.com) if you would like to attend.

Attending the event is free, but registration is required.

=== Program ===

* Saturday, 10 AM: beginning of the meeting. The first person to arrive can go directly to the front desk and ask for MARIBEL SOCIAS or anyone in the Reservations Department, and then ask for the meeting room booked for Thomas Petazzoni. [[User:ThomasPetazzoni|Thomas Petazzoni]] will only arrive at 10:30-11 AM.
* Saturday, 7 PM: end of the meeting
* Saturday, 8:30 PM: dinner sponsored by Synopsys
* Sunday, 10 AM: beginning of the meeting
* Sunday, 7 PM: end of the meeting

=== Location ===

The event will take place at [http://www.hotelgrumsbarcelona.com/ Hotel Grumps], in downtown Barcelona. See [http://goo.gl/maps/htYi9 this map] for the location of the hotel, and [http://goo.gl/maps/GdiaM this map] for walking directions between the Fira Palace hotel (location of the ELCE conference) and Hotel Grums.

=== List of topics to discuss ===

* Interaction between Buildroot configuration options to select architecture specifities (architecture variant, soft-float vs. hard-float, etc.) and the multilib variants available in external toolchains. Proposed by [[User:ThomasPetazzoni]].
* Status on the community organization. Has patchwork improved things? Are patches taken into account in a faster way? Proposed by [[User:ThomasPetazzoni]].
* What are the next "big" things for Buildroot? Proposed by [[User:ThomasPetazzoni]].
* Documentation refactoring? Proposed by Samuel Martin.
* Autobuilder tests: needed improvements, future work. Proposed by [[User:ThomasPetazzoni]].
* The _AVAILABLE mechanism, and how to properly handle dependency on toolchain options (discuss the proposal made by Yann E. Morin). Proposed by [[User:ThomasPetazzoni]].
* Discuss (and, if approved, implement) the split between _LICENSE and _REDISTRIBUTE for legal-info. I think this won't take much more than 10 minutes chat + 10 minutes hack. Proposed by Luca Ceresoli.
* Make it possible to use a git repository as source for toolchain. This doesn't work well today. Proposed by Mischa Jonker
* Make it possible to do a 'target-clean', as a replacement of uninstall. Will this even work at all? Proposed by Arnout Vandecappelle
* Does it make sense to port the toolchains to generic-package infrastructure? Asked by Arnout Vandecappelle
* How to provide licensing info for packages that have more than one license. The main use cases are: a) different parts of the source code have different licenses, b) a file (or the whole project) is distributed under two or more licenses or c) a mix of the two. See the recent thoughts about this issue by Yann Morin: http://lists.busybox.net/pipermail/buildroot/2012-October/060475.html
* Support for board stuff outside the buildroot tree. Proposed by Arnout Vandecappelle
* Should we remove the ability to build a toolchain on the target? And also things like development files on target, documentation on target, etc. Proposed by [[User:ThomasPetazzoni]].

=== List of topics to hack on ===

* Reduce the back log of bugs. Proposed by [[User:ThomasPetazzoni]].
* Reduce the back log of patches. Proposed by [[User:ThomasPetazzoni]].
* Work on noMMU platform support (Blackfin, Coldfire). Getting Coldfire Qemu working, adding correct support for FLAT binaries. Proposed by [[User:ThomasPetazzoni]].
* Package upgrades: package python3, gtk3 and latest versions of glib and al. Proposed by [[User:ThomasPetazzoni]].
* Triage autobuilder failures and fix them. Proposed by Arnout Vandecappelle
* Improve the documentation. Proposed by Arnout Vandecappelle
* Work on relocatable toolchain. Proposed by Arnout Vandecappelle
* Add some infra for setup.py/qmake based packages. Proposed by Samuel Martin
* Add some infra for make based packages (mainly using the same pattern all over). Proposed by Arnout Vandecappelle
* Add some infra for Kconfig based packages (linux, barebox, busybox, uclibc, ct-ng, at91bootstrap3). Proposed by Arnout Vandecappelle
* Make top-level make -j possible. Proposed by Arnout Vandecappelle

Buildroot:DeveloperDaysELCE2012

2012-11-04T16:44:47Z

Arnout Vandecappelle: /* Report of the meeting */

== Buildroot Developers Meeting, 3-4 November 2012, Barcelona Spain ==

=== What is Buildroot ? ===

[http://buildroot.org 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.

=== Meeting in Barcelona ===

The Buildroot community is organizing a meeting on Saturday November 3rd and Sunday November 4th, for Buildroot developers and contributors. This meeting will be a mixture of discussion and hacking session around the Buildroot project. This meeting takes place right before the Embedded Linux Conference Europe, in order to make it easy for participants to attend both events.

=== Event sponsored by Fluendo and Synopsys ===

The meeting room is sponsored by [http://www.fluendo.com Fluendo]. Thanks!

The Saturday dinner is sponsored by [http://www.synopsys.com Synopsys]. Thanks!

=== Report of the meeting ===

==== Action points ====
* Accept perl series.
* Accept qemu series (after further review).
* Remove compiler on target.
* Remove development files on target.
* Remove documentation on target.
* Explain in the documentation why the above was done.
* Put httpd daemons outside BUSYBOX_SHOW_OTHERS.
* Move BUSYBOX_SHOW_OTHERS conditions to ''depends on'' inside the package Config.in
* busybox: disable mount-nfs in the default config.
* simplify patch logic: if pkg-version directory exists, use that; otherwise, use pkg-*.patch.
* Automate selection of correct FP and other compiler options based on subarchitecture.
* Move download helpers to a script.
* Samuel merges documentation patches and sends pull requests to Peter.

==== Details of the discussion ====

# Perl. The perl patch series (now at v11) looks ready to be integrated, but we have our doubts about cpanminus. The problems are: it has separate download infrastructure, which blocks some buildroot features (e.g. make source); it doesn't integrate with the legal-info. However, CPAN is pretty important if you really want to use perl. The decision was to accept cpanminus as well, but add some warnings that some things don't work.
# Qemu. Adding this opens the door for more people to do stuff that buildroot wasn't meant for in the first place (i.e. embedded). However, even in embedded qemu could be relevant. Things like the compiler on the target are much worse for doing crazy things. Giving new packages a chance is OK; we have to be much more careful with things that have global impact (like including development files on target). Conclusion: it's OK to accept qemu.
# Compiler on target. It leads to newbies using buildroot in an inappropriate way (i.e. compile on the target). Also it only works with the internal toolchain. And if we remove it, we can also remove "Development files on target", which simplifies some of the build infrastructure. Also, if you have a compiler on the target, then you can just as well use a distro. Conclusion: we remove it. Also a bunch of other packages can be removed (autotools, vala, ...)
# Documentation on target: if you need this, use a distro. So we remove it.
# We need to explain in the documentation why we removed this stuff.
# Available stuff: i.e. solve the problem of combination of ''select'' and ''depends''. Solving it in Kconfig itself seems to be difficult: there were some patches but the kconfig people didn't like it; Yann and Thomas looked at Kconfig and it looks difficult to modify. The AVAILABLE solution has two problems: it adds verbosity, and the recursive dependencies still should be written in the comments ("libfoo requires WCHAR in the toolchain"). The verbosity is not considered a big issue. For the comments: they currently don't work perfectly either. Removing the comments altogether is an option, but then it is difficult for users to find out why a certain package isn't available. Another possibility is to list the available packages in the documentation (automatically), and mention which toolchain dependencies they have. Wild idea: consider Config.in as a low-level language, and define our own higher-level language from which we generate Config.in. Alternatively, have a developer tool that verifies if everything is consistent (i.e. are the comments correct). One more option: add a big comment in the beginning of the packages list, which says that not all toolchain options are available so not all packages are visible. Converting the toolchain options from ''depends'' to ''select'' is not really an option, because changing toolchain options requires a make clean. We didn't reach a conclusion, we'll come back to it tomorrow.
# kconfig-frontend: Yann now has a repository for Kconfig, it would be nice to branch our Kconfig from that. The idea is to still copy it to our repository.
# BUSYBOX_SHOW_OTHERS: the only reason to have this is to avoid newcomers enabling things like tar etc. which are anyway already in busybox. But for the web servers, they are clearly different from the busybox web servers (and our default busybox config doesn't even enable a web server). Also bash is a typical one, because people write bashisms in their scripts. This discussion is somewhat related to the discussion how to handle packages that provide the same functionality. But for many packages, it's not even the same (httpd, bash, vim). But actually, we're trying to solve a non-existent problem here - except for the web servers. If we generate a list of packages in the documentation, we can add a remark to that that it's also available in busybox. Also move the condition inside the package Config.in instead of outside and make it a ''depends on'', so it is more visible.
# packages with multiple variants: python2/3, Qt4/5, gtk2/3, gstreamer0.10/1.0... This is again similar to the expat/libxml2 issue. Do we support both python2 and python3? We need to support both versions in most cases. Question is if we want to force that only one of the two is selected, or do we support side-by-side installation. Conclusion: has to be looked at on a case-by-case basis. General philosophy: don't try to be too smart, so don't try to force selecting only one of the two if it doesn't make sense to have both. In cases where a package wants to ''select'' one of these things, convert the ''select'' into a ''depends'' with a comment. For gstreamer, the complexity of having the two side-by-side is unacceptable, because there are so many fine-grained gstreamer configure options (in the plugins). However, we expect that everything will move to gstreamer1.0 quite quickly, so for the time being (and only if someone needs it), we can live with a non-perfect solution that just fits the requirements of whoever needs gstreamer1.0.
# multiple packages providing the same functionality: lua/luajit, jpeg/jpegturbo, expat/libxml2. These cannot be installed side-by-side, and many packages select e.g. jpeg. OpenGL will have this issue as well. A relatively clean solution is to create virtual packages for these, where the user has a choice between the two. The normal config option would be hidden for these packages. This still adds complexity in some corner cases, e.g. some package that doesn't work in luajit, but that can probably be solved at the level of that package.
# Autobuild infrastructure. Thomas is working on scripts that parse the build result and put it in a database. One important missing feature at the moment is visibility of evolution over time (i.e. distinguish regressions from recurring problems). Even more important is just being able to see which packages are failing all the time, i.e. for each package how often it failed. Ideally, we would also want to see how often a package has been built successfully, but when is it successful? Does the entire build have to succeed or that package? Overall, however, the autobuild infrastructure is considered very useful - when something is wrong, it appears in the autobuild very quickly.
#* autobuild of the next branch: if only the master is autobuilt, we don't see a lot of problems until after the release. Delaying fixing bugs makes it more difficult to fix them. To support autobuild of the next branch, this should also be made visible in the database so we can distinguish master failures (more important) from next failures.
#* autobuild database is not suitable to track repeated builds of the same configuration. It needs to keep track of different builds of the same configurations. But the question is if this is really useful. We would like to check the existing defconfigs at every release, but it doesn't have to be tracked. So it can be done manually.
# AVR32. It is end of life as far as Atmel is concerned, but of course there are still products out there using it. It is not really blocking for buildroot. For packages which fail to build, we can just add a ''depends on !BR2_avr32''. But of course, until we have the AVAILABLE mechanism, carrying this kind of dependency can be painful.
# RPC support. Originally, the idea was to consider RPC support as a toolchain option, i.e. using ''depends''. However, libtirpc is really a library, comparable to gettext, so it could be enabled automatically with ''select''. Busybox is special, because we don't want to force RPC just because busybox is selected. Therefore busybox has a user-selectable option to enable RPC-based applets (mount-nfs). After discussion, this option was discarded - just remove mount-nfs from busybox (see below). Other packages will use libtirpc if it was selected (manually or automatically). It's still a question what will happen when dynamically linking against libtirpc when libc also has rpc.
# A bit related: we'll disable mount-nfs in the default busybox config; if user disables RPC and enables mount-nfs in busybox, he'll get a compilation error.
# Support for VCS branches in packages: custom packages are often in a VCS and while developing, you want to track a branch of that VCS. OVERRIDE_SRCDIR doesn't work very well because it means the user has to check everything out at the right version in the right location. An alternative would be to teach OVERRIDE_SRCDIR about VCSes, so that ''make foo-rebuild'' re-syncs with the VCS.
# There is a general feeling (mainly from Thomas) that buildroot isn't very convenient during development of a project where several people are working on several components. But no solution was found.
# FP stuff: we now have a single SOFT_FLOAT option, but actually there's a lot more variation: neon, vfpv3, softfp, .... To support this well, we can add a lot of extra config options to semi-automatically select the correct float options based on the subarchitecture. There is some cross-dependency with the external toolchains, but it's doable. There should still be an option to manually override the float options for exotic cases. ARM thumb adds another layer of complexity. Someone should take the lead on making this easier.
# Porting gcc to the generic package infrastructure. Looks like this is a lot of work, and there's not so much need for it.
# Getting gcc from git. It's more convenient to put a tarball somewhere public and use that as an alternative source, similar to avr32.
# Download helpers are getting too complex. It should move a script so at least it's more readable.
# Community organization:
#* It can be useful to have subsystem maintainers, that are responsible for reviewing and accepting patches. In practice, however, it is difficult to split things in a way that we don't risk duplicating work (i.e. two people in the process of merging the same patch). However, one clearly defined subsystem is the documentation. From now on, Samuel Martin is responsible for all documentation patches. He'll send pull requests to Peter.
#* Patches should be accepted more aggressively, even if there hasn't been (much) testing of the patch. The autobuilders will catch any issues. However, it is still important to properly review and comment on coding style issues (i.e. how the features are implemented. Also, if something really breaks the autobuilder, Thomas can revert it without consulting Peter.
# Out of tree build: this is a feature that people keep on asking. It is particularly useful for packages with an OVERRIDE_SRCDIR. But of course, not all packages support out-of-tree build, and not all packages support it in the same way. For autotools and cmake, it can be automatic; for generic packages, it has to be signalled if out-of-tree build is available.
# legal-info:
#* split _LICENSE and _REDISTRIBUTE: patch proposed by Luca is accepted. Even though there is no proprietary package in buildroot that triggers the feature, if it fails to work as expected the user will hopefully report it.
#* multiple licenses: we don't want to make things very complex. It doesn't have to be machine-readable (we don't need to support machine analysis of the license field), so we don't have to formally decide how the license text must be written. It does make sense to have some convention, though. Proposal: "GPLv2+ or BSD-2c for the library, GPLv2+ for the dtc executable".

For tomorrow:
* The _AVAILABLE mechanism, and how to properly handle dependency on toolchain options (discuss the proposal made by Yann E. Morin). Proposed by [[User:ThomasPetazzoni]].
* Make it possible to do a 'target-clean', as a replacement of uninstall. Will this even work at all? Proposed by Arnout Vandecappelle
* Support for board stuff outside the buildroot tree. Proposed by Arnout Vandecappelle

=== Participants ===

# [[User:Arnout_Vandecappelle|Arnout Vandecappelle]], confirmed. Arriving on Fri Nov 2 20:35 at BCN airport. Leaving Wed Nov. 8 21:15 at BCN. Staying at [http://www.hcchotels.es/en/hotel/12/hcc-lugano HCC Lugano]
# [[User:ThomasPetazzoni|Thomas Petazzoni]], confirmed. Arriving on November, 3rd at BCN airport 9:25 AM. Leaving on November 8th from BCN airport at 3:45 PM. Staying at Hotel Fira Palace.
# Maxime Ripard, confirmed. Arriving on November, 1st at BCN airport. Leaving on November 8th from BCP airport at 3:45 PM. Staying at Hotel Fira Palace.
# [[User:PeterKorsgaard|Peter Korsgaard]], confirmed, Arriving on Fri Nov 2 21:55 at BCN airport. Leaving Sun Nov 11 17:15 at BCN. Staying at [http://www.hcchotels.es/en/hotel/12/hcc-lugano HCC Lugano]
# Luca Ceresoli, confirmed. Arriving on November 3rd at BCN airport 10:05 AM. Leaving on November 7th from BCN airport 19:15 PM. Staying at Hotel Fira Palace. Will arrive around 11:30 AM for the meeting.
# Samuel Martin, confirmed. Arriving on November, 3rd at Barcelona-Franca Train Station 8:05 AM. Leaving on November 10th from Barcelona-Franca Train Station at 8:43 PM.
# Simon Dawson, confirmed. Arriving on November 2nd in the evening. Leaving on November 8th early morning.
# Mischa Jonker, confirmed. From Synopsys.com. Not contributing yet to Buildroot, but interested in using Buildroot for a brand new CPU architecture. Arriving Friday Nov 2nd BCN 21:10 CET, staying at Catalonia Barcelona Plaza (Plaza Espanya), leaving Thursday Nov 8 at 18:40 CET.
# Maxime Hadjinlian.

=== Registration ===

Please contact Thomas Petazzoni (thomas.petazzoni@free-electrons.com) if you would like to attend.

Attending the event is free, but registration is required.

=== Program ===

* Saturday, 10 AM: beginning of the meeting. The first person to arrive can go directly to the front desk and ask for MARIBEL SOCIAS or anyone in the Reservations Department, and then ask for the meeting room booked for Thomas Petazzoni. [[User:ThomasPetazzoni|Thomas Petazzoni]] will only arrive at 10:30-11 AM.
* Saturday, 7 PM: end of the meeting
* Saturday, 8:30 PM: dinner sponsored by Synopsys
* Sunday, 10 AM: beginning of the meeting
* Sunday, 7 PM: end of the meeting

=== Location ===

The event will take place at [http://www.hotelgrumsbarcelona.com/ Hotel Grumps], in downtown Barcelona. See [http://goo.gl/maps/htYi9 this map] for the location of the hotel, and [http://goo.gl/maps/GdiaM this map] for walking directions between the Fira Palace hotel (location of the ELCE conference) and Hotel Grums.

=== List of topics to discuss ===

* Interaction between Buildroot configuration options to select architecture specifities (architecture variant, soft-float vs. hard-float, etc.) and the multilib variants available in external toolchains. Proposed by [[User:ThomasPetazzoni]].
* Status on the community organization. Has patchwork improved things? Are patches taken into account in a faster way? Proposed by [[User:ThomasPetazzoni]].
* What are the next "big" things for Buildroot? Proposed by [[User:ThomasPetazzoni]].
* Documentation refactoring? Proposed by Samuel Martin.
* Autobuilder tests: needed improvements, future work. Proposed by [[User:ThomasPetazzoni]].
* The _AVAILABLE mechanism, and how to properly handle dependency on toolchain options (discuss the proposal made by Yann E. Morin). Proposed by [[User:ThomasPetazzoni]].
* Discuss (and, if approved, implement) the split between _LICENSE and _REDISTRIBUTE for legal-info. I think this won't take much more than 10 minutes chat + 10 minutes hack. Proposed by Luca Ceresoli.
* Make it possible to use a git repository as source for toolchain. This doesn't work well today. Proposed by Mischa Jonker
* Make it possible to do a 'target-clean', as a replacement of uninstall. Will this even work at all? Proposed by Arnout Vandecappelle
* Does it make sense to port the toolchains to generic-package infrastructure? Asked by Arnout Vandecappelle
* How to provide licensing info for packages that have more than one license. The main use cases are: a) different parts of the source code have different licenses, b) a file (or the whole project) is distributed under two or more licenses or c) a mix of the two. See the recent thoughts about this issue by Yann Morin: http://lists.busybox.net/pipermail/buildroot/2012-October/060475.html
* Support for board stuff outside the buildroot tree. Proposed by Arnout Vandecappelle
* Should we remove the ability to build a toolchain on the target? And also things like development files on target, documentation on target, etc. Proposed by [[User:ThomasPetazzoni]].

=== List of topics to hack on ===

* Reduce the back log of bugs. Proposed by [[User:ThomasPetazzoni]].
* Reduce the back log of patches. Proposed by [[User:ThomasPetazzoni]].
* Work on noMMU platform support (Blackfin, Coldfire). Getting Coldfire Qemu working, adding correct support for FLAT binaries. Proposed by [[User:ThomasPetazzoni]].
* Package upgrades: package python3, gtk3 and latest versions of glib and al. Proposed by [[User:ThomasPetazzoni]].
* Triage autobuilder failures and fix them. Proposed by Arnout Vandecappelle
* Improve the documentation. Proposed by Arnout Vandecappelle
* Work on relocatable toolchain. Proposed by Arnout Vandecappelle
* Add some infra for setup.py/qmake based packages. Proposed by Samuel Martin
* Add some infra for make based packages (mainly using the same pattern all over). Proposed by Arnout Vandecappelle
* Add some infra for Kconfig based packages (linux, barebox, busybox, uclibc, ct-ng, at91bootstrap3). Proposed by Arnout Vandecappelle
* Make top-level make -j possible. Proposed by Arnout Vandecappelle

Buildroot:DeveloperDaysELCE2012

2012-11-04T16:31:12Z

Arnout Vandecappelle: /* Report of the meeting */

== Buildroot Developers Meeting, 3-4 November 2012, Barcelona Spain ==

=== What is Buildroot ? ===

[http://buildroot.org 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.

=== Meeting in Barcelona ===

The Buildroot community is organizing a meeting on Saturday November 3rd and Sunday November 4th, for Buildroot developers and contributors. This meeting will be a mixture of discussion and hacking session around the Buildroot project. This meeting takes place right before the Embedded Linux Conference Europe, in order to make it easy for participants to attend both events.

=== Event sponsored by Fluendo and Synopsys ===

The meeting room is sponsored by [http://www.fluendo.com Fluendo]. Thanks!

The Saturday dinner is sponsored by [http://www.synopsys.com Synopsys]. Thanks!

=== Report of the meeting ===

==== Action points ====
* Accept perl series.
* Accept qemu series (after further review).
* Remove compiler on target.
* Remove development files on target.
* Remove documentation on target.
* Explain in the documentation why the above was done.
* Put httpd daemons outside BUSYBOX_SHOW_OTHERS.
* Move BUSYBOX_SHOW_OTHERS conditions to ''depends on'' inside the package Config.in
* busybox: disable mount-nfs in the default config.
* simplify patch logic: if pkg-version directory exists, use that; otherwise, use pkg-*.patch.
* Automate selection of correct FP and other compiler options based on subarchitecture.
* Move download helpers to a script.
* Samuel merges documentation patches and sends pull requests to Peter.

==== Details of the discussion ====

# Perl. The perl patch series (now at v11) looks ready to be integrated, but we have our doubts about cpanminus. The problems are: it has separate download infrastructure, which blocks some buildroot features (e.g. make source); it doesn't integrate with the legal-info. However, CPAN is pretty important if you really want to use perl. The decision was to accept cpanminus as well, but add some warnings that some things don't work.
# Qemu. Adding this opens the door for more people to do stuff that buildroot wasn't meant for in the first place (i.e. embedded). However, even in embedded qemu could be relevant. Things like the compiler on the target are much worse for doing crazy things. Giving new packages a chance is OK; we have to be much more careful with things that have global impact (like including development files on target). Conclusion: it's OK to accept qemu.
# Compiler on target. It leads to newbies using buildroot in an inappropriate way (i.e. compile on the target). Also it only works with the internal toolchain. And if we remove it, we can also remove "Development files on target", which simplifies some of the build infrastructure. Also, if you have a compiler on the target, then you can just as well use a distro. Conclusion: we remove it. Also a bunch of other packages can be removed (autotools, vala, ...)
# Documentation on target: if you need this, use a distro. So we remove it.
# We need to explain in the documentation why we removed this stuff.
# Available stuff: i.e. solve the problem of combination of ''select'' and ''depends''. Solving it in Kconfig itself seems to be difficult: there were some patches but the kconfig people didn't like it; Yann and Thomas looked at Kconfig and it looks difficult to modify. The AVAILABLE solution has two problems: it adds verbosity, and the recursive dependencies still should be written in the comments ("libfoo requires WCHAR in the toolchain"). The verbosity is not considered a big issue. For the comments: they currently don't work perfectly either. Removing the comments altogether is an option, but then it is difficult for users to find out why a certain package isn't available. Another possibility is to list the available packages in the documentation (automatically), and mention which toolchain dependencies they have. Wild idea: consider Config.in as a low-level language, and define our own higher-level language from which we generate Config.in. Alternatively, have a developer tool that verifies if everything is consistent (i.e. are the comments correct). One more option: add a big comment in the beginning of the packages list, which says that not all toolchain options are available so not all packages are visible. Converting the toolchain options from ''depends'' to ''select'' is not really an option, because changing toolchain options requires a make clean. We didn't reach a conclusion, we'll come back to it tomorrow.
# kconfig-frontend: Yann now has a repository for Kconfig, it would be nice to branch our Kconfig from that. The idea is to still copy it to our repository.
# BUSYBOX_SHOW_OTHERS: the only reason to have this is to avoid newcomers enabling things like tar etc. which are anyway already in busybox. But for the web servers, they are clearly different from the busybox web servers (and our default busybox config doesn't even enable a web server). Also bash is a typical one, because people write bashisms in their scripts. This discussion is somewhat related to the discussion how to handle packages that provide the same functionality. But for many packages, it's not even the same (httpd, bash, vim). But actually, we're trying to solve a non-existent problem here - except for the web servers. If we generate a list of packages in the documentation, we can add a remark to that that it's also available in busybox. Also move the condition inside the package Config.in instead of outside and make it a ''depends on'', so it is more visible.
# packages with multiple variants: python2/3, Qt4/5, gtk2/3, gstreamer0.10/1.0... This is again similar to the expat/libxml2 issue. Do we support both python2 and python3? We need to support both versions in most cases. Question is if we want to force that only one of the two is selected, or do we support side-by-side installation. Conclusion: has to be looked at on a case-by-case basis. General philosophy: don't try to be too smart, so don't try to force selecting only one of the two if it doesn't make sense to have both. In cases where a package wants to ''select'' one of these things, convert the ''select'' into a ''depends'' with a comment. For gstreamer, the complexity of having the two side-by-side is unacceptable, because there are so many fine-grained gstreamer configure options (in the plugins). However, we expect that everything will move to gstreamer1.0 quite quickly, so for the time being (and only if someone needs it), we can live with a non-perfect solution that just fits the requirements of whoever needs gstreamer1.0.
# multiple packages providing the same functionality: lua/luajit, jpeg/jpegturbo, expat/libxml2. These cannot be installed side-by-side, and many packages select e.g. jpeg. OpenGL will have this issue as well. A relatively clean solution is to create virtual packages for these, where the user has a choice between the two. The normal config option would be hidden for these packages. This still adds complexity in some corner cases, e.g. some package that doesn't work in luajit, but that can probably be solved at the level of that package.
# Autobuild infrastructure. Thomas is working on scripts that parse the build result and put it in a database. One important missing feature at the moment is visibility of evolution over time (i.e. distinguish regressions from recurring problems). Even more important is just being able to see which packages are failing all the time, i.e. for each package how often it failed. Ideally, we would also want to see how often a package has been built successfully, but when is it successful? Does the entire build have to succeed or that package? Overall, however, the autobuild infrastructure is considered very useful - when something is wrong, it appears in the autobuild very quickly.
#* autobuild of the next branch: if only the master is autobuilt, we don't see a lot of problems until after the release. Delaying fixing bugs makes it more difficult to fix them. To support autobuild of the next branch, this should also be made visible in the database so we can distinguish master failures (more important) from next failures.
#* autobuild database is not suitable to track repeated builds of the same configuration. It needs to keep track of different builds of the same configurations. But the question is if this is really useful. We would like to check the existing defconfigs at every release, but it doesn't have to be tracked. So it can be done manually.
# AVR32. It is end of life as far as Atmel is concerned, but of course there are still products out there using it. It is not really blocking for buildroot. For packages which fail to build, we can just add a ''depends on !BR2_avr32''. But of course, until we have the AVAILABLE mechanism, carrying this kind of dependency can be painful.
# RPC support. Originally, the idea was to consider RPC support as a toolchain option, i.e. using ''depends''. However, libtirpc is really a library, comparable to gettext, so it could be enabled automatically with ''select''. Busybox is special, because we don't want to force RPC just because busybox is selected. Therefore busybox has a user-selectable option to enable RPC-based applets (mount-nfs). After discussion, this option was discarded - just remove mount-nfs from busybox (see below). Other packages will use libtirpc if it was selected (manually or automatically). It's still a question what will happen when dynamically linking against libtirpc when libc also has rpc.
# A bit related: we'll disable mount-nfs in the default busybox config; if user disables RPC and enables mount-nfs in busybox, he'll get a compilation error.
# Support for VCS branches in packages: custom packages are often in a VCS and while developing, you want to track a branch of that VCS. OVERRIDE_SRCDIR doesn't work very well because it means the user has to check everything out at the right version in the right location. An alternative would be to teach OVERRIDE_SRCDIR about VCSes, so that ''make foo-rebuild'' re-syncs with the VCS.
# There is a general feeling (mainly from Thomas) that buildroot isn't very convenient during development of a project where several people are working on several components. But no solution was found.
# FP stuff: we now have a single SOFT_FLOAT option, but actually there's a lot more variation: neon, vfpv3, softfp, .... To support this well, we can add a lot of extra config options to semi-automatically select the correct float options based on the subarchitecture. There is some cross-dependency with the external toolchains, but it's doable. There should still be an option to manually override the float options for exotic cases. ARM thumb adds another layer of complexity. Someone should take the lead on making this easier.
# Porting gcc to the generic package infrastructure. Looks like this is a lot of work, and there's not so much need for it.
# Getting gcc from git. It's more convenient to put a tarball somewhere public and use that as an alternative source, similar to avr32.
# Download helpers are getting too complex. It should move a script so at least it's more readable.
# Community organization:
#* It can be useful to have subsystem maintainers, that are responsible for reviewing and accepting patches. In practice, however, it is difficult to split things in a way that we don't risk duplicating work (i.e. two people in the process of merging the same patch). However, one clearly defined subsystem is the documentation. From now on, Samuel Martin is responsible for all documentation patches. He'll send pull requests to Peter.
#* Patches should be accepted more aggressively, even if there hasn't been (much) testing of the patch. The autobuilders will catch any issues. However, it is still important to properly review and comment on coding style issues (i.e. how the features are implemented. Also, if something really breaks the autobuilder, Thomas can revert it without consulting Peter.
# Out of tree build: this is a feature that people keep on asking. It is particularly useful for packages with an OVERRIDE_SRCDIR. But of course, not all packages support out-of-tree build, and not all packages support it in the same way. For autotools and cmake, it can be automatic; for generic packages, it has to be signalled if out-of-tree build is available.
# legal-info:
#* split _LICENSE and _REDISTRIBUTE: patch proposed by Luca is accepted. Even though there is no proprietary package in buildroot that triggers the feature, if it fails to work as expected the user will hopefully report it.

For tomorrow:
* The _AVAILABLE mechanism, and how to properly handle dependency on toolchain options (discuss the proposal made by Yann E. Morin). Proposed by [[User:ThomasPetazzoni]].
* Discuss (and, if approved, implement) the split between _LICENSE and _REDISTRIBUTE for legal-info. I think this won't take much more than 10 minutes chat + 10 minutes hack. Proposed by Luca Ceresoli.
* Make it possible to do a 'target-clean', as a replacement of uninstall. Will this even work at all? Proposed by Arnout Vandecappelle
* How to provide licensing info for packages that have more than one license. The main use cases are: a) different parts of the source code have different licenses, b) a file (or the whole project) is distributed under two or more licenses or c) a mix of the two. See the recent thoughts about this issue by Yann Morin: http://lists.busybox.net/pipermail/buildroot/2012-October/060475.html
* Support for board stuff outside the buildroot tree. Proposed by Arnout Vandecappelle

=== Participants ===

# [[User:Arnout_Vandecappelle|Arnout Vandecappelle]], confirmed. Arriving on Fri Nov 2 20:35 at BCN airport. Leaving Wed Nov. 8 21:15 at BCN. Staying at [http://www.hcchotels.es/en/hotel/12/hcc-lugano HCC Lugano]
# [[User:ThomasPetazzoni|Thomas Petazzoni]], confirmed. Arriving on November, 3rd at BCN airport 9:25 AM. Leaving on November 8th from BCN airport at 3:45 PM. Staying at Hotel Fira Palace.
# Maxime Ripard, confirmed. Arriving on November, 1st at BCN airport. Leaving on November 8th from BCP airport at 3:45 PM. Staying at Hotel Fira Palace.
# [[User:PeterKorsgaard|Peter Korsgaard]], confirmed, Arriving on Fri Nov 2 21:55 at BCN airport. Leaving Sun Nov 11 17:15 at BCN. Staying at [http://www.hcchotels.es/en/hotel/12/hcc-lugano HCC Lugano]
# Luca Ceresoli, confirmed. Arriving on November 3rd at BCN airport 10:05 AM. Leaving on November 7th from BCN airport 19:15 PM. Staying at Hotel Fira Palace. Will arrive around 11:30 AM for the meeting.
# Samuel Martin, confirmed. Arriving on November, 3rd at Barcelona-Franca Train Station 8:05 AM. Leaving on November 10th from Barcelona-Franca Train Station at 8:43 PM.
# Simon Dawson, confirmed. Arriving on November 2nd in the evening. Leaving on November 8th early morning.
# Mischa Jonker, confirmed. From Synopsys.com. Not contributing yet to Buildroot, but interested in using Buildroot for a brand new CPU architecture. Arriving Friday Nov 2nd BCN 21:10 CET, staying at Catalonia Barcelona Plaza (Plaza Espanya), leaving Thursday Nov 8 at 18:40 CET.
# Maxime Hadjinlian.

=== Registration ===

Please contact Thomas Petazzoni (thomas.petazzoni@free-electrons.com) if you would like to attend.

Attending the event is free, but registration is required.

=== Program ===

* Saturday, 10 AM: beginning of the meeting. The first person to arrive can go directly to the front desk and ask for MARIBEL SOCIAS or anyone in the Reservations Department, and then ask for the meeting room booked for Thomas Petazzoni. [[User:ThomasPetazzoni|Thomas Petazzoni]] will only arrive at 10:30-11 AM.
* Saturday, 7 PM: end of the meeting
* Saturday, 8:30 PM: dinner sponsored by Synopsys
* Sunday, 10 AM: beginning of the meeting
* Sunday, 7 PM: end of the meeting

=== Location ===

The event will take place at [http://www.hotelgrumsbarcelona.com/ Hotel Grumps], in downtown Barcelona. See [http://goo.gl/maps/htYi9 this map] for the location of the hotel, and [http://goo.gl/maps/GdiaM this map] for walking directions between the Fira Palace hotel (location of the ELCE conference) and Hotel Grums.

=== List of topics to discuss ===

* Interaction between Buildroot configuration options to select architecture specifities (architecture variant, soft-float vs. hard-float, etc.) and the multilib variants available in external toolchains. Proposed by [[User:ThomasPetazzoni]].
* Status on the community organization. Has patchwork improved things? Are patches taken into account in a faster way? Proposed by [[User:ThomasPetazzoni]].
* What are the next "big" things for Buildroot? Proposed by [[User:ThomasPetazzoni]].
* Documentation refactoring? Proposed by Samuel Martin.
* Autobuilder tests: needed improvements, future work. Proposed by [[User:ThomasPetazzoni]].
* The _AVAILABLE mechanism, and how to properly handle dependency on toolchain options (discuss the proposal made by Yann E. Morin). Proposed by [[User:ThomasPetazzoni]].
* Discuss (and, if approved, implement) the split between _LICENSE and _REDISTRIBUTE for legal-info. I think this won't take much more than 10 minutes chat + 10 minutes hack. Proposed by Luca Ceresoli.
* Make it possible to use a git repository as source for toolchain. This doesn't work well today. Proposed by Mischa Jonker
* Make it possible to do a 'target-clean', as a replacement of uninstall. Will this even work at all? Proposed by Arnout Vandecappelle
* Does it make sense to port the toolchains to generic-package infrastructure? Asked by Arnout Vandecappelle
* How to provide licensing info for packages that have more than one license. The main use cases are: a) different parts of the source code have different licenses, b) a file (or the whole project) is distributed under two or more licenses or c) a mix of the two. See the recent thoughts about this issue by Yann Morin: http://lists.busybox.net/pipermail/buildroot/2012-October/060475.html
* Support for board stuff outside the buildroot tree. Proposed by Arnout Vandecappelle
* Should we remove the ability to build a toolchain on the target? And also things like development files on target, documentation on target, etc. Proposed by [[User:ThomasPetazzoni]].

=== List of topics to hack on ===

* Reduce the back log of bugs. Proposed by [[User:ThomasPetazzoni]].
* Reduce the back log of patches. Proposed by [[User:ThomasPetazzoni]].
* Work on noMMU platform support (Blackfin, Coldfire). Getting Coldfire Qemu working, adding correct support for FLAT binaries. Proposed by [[User:ThomasPetazzoni]].
* Package upgrades: package python3, gtk3 and latest versions of glib and al. Proposed by [[User:ThomasPetazzoni]].
* Triage autobuilder failures and fix them. Proposed by Arnout Vandecappelle
* Improve the documentation. Proposed by Arnout Vandecappelle
* Work on relocatable toolchain. Proposed by Arnout Vandecappelle
* Add some infra for setup.py/qmake based packages. Proposed by Samuel Martin
* Add some infra for make based packages (mainly using the same pattern all over). Proposed by Arnout Vandecappelle
* Add some infra for Kconfig based packages (linux, barebox, busybox, uclibc, ct-ng, at91bootstrap3). Proposed by Arnout Vandecappelle
* Make top-level make -j possible. Proposed by Arnout Vandecappelle

Buildroot:DeveloperDaysELCE2012

2012-11-04T12:29:58Z

Arnout Vandecappelle: /* Report of the meeting */

== Buildroot Developers Meeting, 3-4 November 2012, Barcelona Spain ==

=== What is Buildroot ? ===

[http://buildroot.org 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.

=== Meeting in Barcelona ===

The Buildroot community is organizing a meeting on Saturday November 3rd and Sunday November 4th, for Buildroot developers and contributors. This meeting will be a mixture of discussion and hacking session around the Buildroot project. This meeting takes place right before the Embedded Linux Conference Europe, in order to make it easy for participants to attend both events.

=== Event sponsored by Fluendo and Synopsys ===

The meeting room is sponsored by [http://www.fluendo.com Fluendo]. Thanks!

The Saturday dinner is sponsored by [http://www.synopsys.com Synopsys]. Thanks!

=== Report of the meeting ===

==== Action points ====
* Accept perl series.
* Accept qemu series (after further review).
* Remove compiler on target.
* Remove development files on target.
* Remove documentation on target.
* Explain in the documentation why the above was done.
* Put httpd daemons outside BUSYBOX_SHOW_OTHERS.
* Move BUSYBOX_SHOW_OTHERS conditions to ''depends on'' inside the package Config.in
* busybox: disable mount-nfs in the default config.
* simplify patch logic: if pkg-version directory exists, use that; otherwise, use pkg-*.patch.
* Automate selection of correct FP and other compiler options based on subarchitecture.
* Move download helpers to a script.

==== Details of the discussion ====

# Perl. The perl patch series (now at v11) looks ready to be integrated, but we have our doubts about cpanminus. The problems are: it has separate download infrastructure, which blocks some buildroot features (e.g. make source); it doesn't integrate with the legal-info. However, CPAN is pretty important if you really want to use perl. The decision was to accept cpanminus as well, but add some warnings that some things don't work.
# Qemu. Adding this opens the door for more people to do stuff that buildroot wasn't meant for in the first place (i.e. embedded). However, even in embedded qemu could be relevant. Things like the compiler on the target are much worse for doing crazy things. Giving new packages a chance is OK; we have to be much more careful with things that have global impact (like including development files on target). Conclusion: it's OK to accept qemu.
# Compiler on target. It leads to newbies using buildroot in an inappropriate way (i.e. compile on the target). Also it only works with the internal toolchain. And if we remove it, we can also remove "Development files on target", which simplifies some of the build infrastructure. Also, if you have a compiler on the target, then you can just as well use a distro. Conclusion: we remove it. Also a bunch of other packages can be removed (autotools, vala, ...)
# Documentation on target: if you need this, use a distro. So we remove it.
# We need to explain in the documentation why we removed this stuff.
# Available stuff: i.e. solve the problem of combination of ''select'' and ''depends''. Solving it in Kconfig itself seems to be difficult: there were some patches but the kconfig people didn't like it; Yann and Thomas looked at Kconfig and it looks difficult to modify. The AVAILABLE solution has two problems: it adds verbosity, and the recursive dependencies still should be written in the comments ("libfoo requires WCHAR in the toolchain"). The verbosity is not considered a big issue. For the comments: they currently don't work perfectly either. Removing the comments altogether is an option, but then it is difficult for users to find out why a certain package isn't available. Another possibility is to list the available packages in the documentation (automatically), and mention which toolchain dependencies they have. Wild idea: consider Config.in as a low-level language, and define our own higher-level language from which we generate Config.in. Alternatively, have a developer tool that verifies if everything is consistent (i.e. are the comments correct). One more option: add a big comment in the beginning of the packages list, which says that not all toolchain options are available so not all packages are visible. Converting the toolchain options from ''depends'' to ''select'' is not really an option, because changing toolchain options requires a make clean. We didn't reach a conclusion, we'll come back to it tomorrow.
# kconfig-frontend: Yann now has a repository for Kconfig, it would be nice to branch our Kconfig from that. The idea is to still copy it to our repository.
# BUSYBOX_SHOW_OTHERS: the only reason to have this is to avoid newcomers enabling things like tar etc. which are anyway already in busybox. But for the web servers, they are clearly different from the busybox web servers (and our default busybox config doesn't even enable a web server). Also bash is a typical one, because people write bashisms in their scripts. This discussion is somewhat related to the discussion how to handle packages that provide the same functionality. But for many packages, it's not even the same (httpd, bash, vim). But actually, we're trying to solve a non-existent problem here - except for the web servers. If we generate a list of packages in the documentation, we can add a remark to that that it's also available in busybox. Also move the condition inside the package Config.in instead of outside and make it a ''depends on'', so it is more visible.
# packages with multiple variants: python2/3, Qt4/5, gtk2/3, gstreamer0.10/1.0... This is again similar to the expat/libxml2 issue. Do we support both python2 and python3? We need to support both versions in most cases. Question is if we want to force that only one of the two is selected, or do we support side-by-side installation. Conclusion: has to be looked at on a case-by-case basis. General philosophy: don't try to be too smart, so don't try to force selecting only one of the two if it doesn't make sense to have both. In cases where a package wants to ''select'' one of these things, convert the ''select'' into a ''depends'' with a comment. For gstreamer, the complexity of having the two side-by-side is unacceptable, because there are so many fine-grained gstreamer configure options (in the plugins). However, we expect that everything will move to gstreamer1.0 quite quickly, so for the time being (and only if someone needs it), we can live with a non-perfect solution that just fits the requirements of whoever needs gstreamer1.0.
# multiple packages providing the same functionality: lua/luajit, jpeg/jpegturbo, expat/libxml2. These cannot be installed side-by-side, and many packages select e.g. jpeg. OpenGL will have this issue as well. A relatively clean solution is to create virtual packages for these, where the user has a choice between the two. The normal config option would be hidden for these packages. This still adds complexity in some corner cases, e.g. some package that doesn't work in luajit, but that can probably be solved at the level of that package.
# Autobuild infrastructure. Thomas is working on scripts that parse the build result and put it in a database. One important missing feature at the moment is visibility of evolution over time (i.e. distinguish regressions from recurring problems). Even more important is just being able to see which packages are failing all the time, i.e. for each package how often it failed. Ideally, we would also want to see how often a package has been built successfully, but when is it successful? Does the entire build have to succeed or that package? Overall, however, the autobuild infrastructure is considered very useful - when something is wrong, it appears in the autobuild very quickly.
#* autobuild of the next branch: if only the master is autobuilt, we don't see a lot of problems until after the release. Delaying fixing bugs makes it more difficult to fix them. To support autobuild of the next branch, this should also be made visible in the database so we can distinguish master failures (more important) from next failures.
#* autobuild database is not suitable to track repeated builds of the same configuration. It needs to keep track of different builds of the same configurations. But the question is if this is really useful. We would like to check the existing defconfigs at every release, but it doesn't have to be tracked. So it can be done manually.
# AVR32. It is end of life as far as Atmel is concerned, but of course there are still products out there using it. It is not really blocking for buildroot. For packages which fail to build, we can just add a ''depends on !BR2_avr32''. But of course, until we have the AVAILABLE mechanism, carrying this kind of dependency can be painful.
# RPC support. Originally, the idea was to consider RPC support as a toolchain option, i.e. using ''depends''. However, libtirpc is really a library, comparable to gettext, so it could be enabled automatically with ''select''. Busybox is special, because we don't want to force RPC just because busybox is selected. Therefore busybox has a user-selectable option to enable RPC-based applets (mount-nfs). After discussion, this option was discarded - just remove mount-nfs from busybox (see below). Other packages will use libtirpc if it was selected (manually or automatically). It's still a question what will happen when dynamically linking against libtirpc when libc also has rpc.
# A bit related: we'll disable mount-nfs in the default busybox config; if user disables RPC and enables mount-nfs in busybox, he'll get a compilation error.
# Support for VCS branches in packages: custom packages are often in a VCS and while developing, you want to track a branch of that VCS. OVERRIDE_SRCDIR doesn't work very well because it means the user has to check everything out at the right version in the right location. An alternative would be to teach OVERRIDE_SRCDIR about VCSes, so that ''make foo-rebuild'' re-syncs with the VCS.
# There is a general feeling (mainly from Thomas) that buildroot isn't very convenient during development of a project where several people are working on several components. But no solution was found.
# FP stuff: we now have a single SOFT_FLOAT option, but actually there's a lot more variation: neon, vfpv3, softfp, .... To support this well, we can add a lot of extra config options to semi-automatically select the correct float options based on the subarchitecture. There is some cross-dependency with the external toolchains, but it's doable. There should still be an option to manually override the float options for exotic cases. ARM thumb adds another layer of complexity. Someone should take the lead on making this easier.
# Porting gcc to the generic package infrastructure. Looks like this is a lot of work, and there's not so much need for it.
# Getting gcc from git. It's more convenient to put a tarball somewhere public and use that as an alternative source, similar to avr32.
# Download helpers are getting too complex. It should move a script so at least it's more readable.
# Community organization:
#* It can be useful to have subsystem maintainers, that are responsible for reviewing and accepting patches. In practice, however, it is difficult to split things in a way that we don't risk duplicating work (i.e. two people in the process of merging the same patch). However, one clearly defined subsystem is the documentation. From now on, Samuel Martin is responsible for all documentation patches. He'll send pull requests to Peter.
#* Patches should be accepted more aggressively, even if there hasn't been (much) testing of the patch. The autobuilders will catch any issues. However, it is still important to properly review and comment on coding style issues (i.e. how the features are implemented.
# Out of tree build: this is a feature that people keep on asking. It is particularly useful for packages with an OVERRIDE_SRCDIR. But of course, not all packages support out-of-tree build, and not all packages support it in the same way. For autotools and cmake, it can be automatic; for generic packages, it has to be signalled if out-of-tree build is available.

For tomorrow:
* Interaction between Buildroot configuration options to select architecture specifities (architecture variant, soft-float vs. hard-float, etc.) and the multilib variants available in external toolchains. Proposed by [[User:ThomasPetazzoni]].
* Status on the community organization. Has patchwork improved things? Are patches taken into account in a faster way? Proposed by [[User:ThomasPetazzoni]].
* What are the next "big" things for Buildroot? Proposed by [[User:ThomasPetazzoni]].
* Documentation refactoring? Proposed by Samuel Martin.
* The _AVAILABLE mechanism, and how to properly handle dependency on toolchain options (discuss the proposal made by Yann E. Morin). Proposed by [[User:ThomasPetazzoni]].
* Discuss (and, if approved, implement) the split between _LICENSE and _REDISTRIBUTE for legal-info. I think this won't take much more than 10 minutes chat + 10 minutes hack. Proposed by Luca Ceresoli.
* Make it possible to do a 'target-clean', as a replacement of uninstall. Will this even work at all? Proposed by Arnout Vandecappelle
* How to provide licensing info for packages that have more than one license. The main use cases are: a) different parts of the source code have different licenses, b) a file (or the whole project) is distributed under two or more licenses or c) a mix of the two. See the recent thoughts about this issue by Yann Morin: http://lists.busybox.net/pipermail/buildroot/2012-October/060475.html
* Support for board stuff outside the buildroot tree. Proposed by Arnout Vandecappelle

=== Participants ===

# [[User:Arnout_Vandecappelle|Arnout Vandecappelle]], confirmed. Arriving on Fri Nov 2 20:35 at BCN airport. Leaving Wed Nov. 8 21:15 at BCN. Staying at [http://www.hcchotels.es/en/hotel/12/hcc-lugano HCC Lugano]
# [[User:ThomasPetazzoni|Thomas Petazzoni]], confirmed. Arriving on November, 3rd at BCN airport 9:25 AM. Leaving on November 8th from BCN airport at 3:45 PM. Staying at Hotel Fira Palace.
# Maxime Ripard, confirmed. Arriving on November, 1st at BCN airport. Leaving on November 8th from BCP airport at 3:45 PM. Staying at Hotel Fira Palace.
# [[User:PeterKorsgaard|Peter Korsgaard]], confirmed, Arriving on Fri Nov 2 21:55 at BCN airport. Leaving Sun Nov 11 17:15 at BCN. Staying at [http://www.hcchotels.es/en/hotel/12/hcc-lugano HCC Lugano]
# Luca Ceresoli, confirmed. Arriving on November 3rd at BCN airport 10:05 AM. Leaving on November 7th from BCN airport 19:15 PM. Staying at Hotel Fira Palace. Will arrive around 11:30 AM for the meeting.
# Samuel Martin, confirmed. Arriving on November, 3rd at Barcelona-Franca Train Station 8:05 AM. Leaving on November 10th from Barcelona-Franca Train Station at 8:43 PM.
# Simon Dawson, confirmed. Arriving on November 2nd in the evening. Leaving on November 8th early morning.
# Mischa Jonker, confirmed. From Synopsys.com. Not contributing yet to Buildroot, but interested in using Buildroot for a brand new CPU architecture. Arriving Friday Nov 2nd BCN 21:10 CET, staying at Catalonia Barcelona Plaza (Plaza Espanya), leaving Thursday Nov 8 at 18:40 CET.
# Maxime Hadjinlian.

=== Registration ===

Please contact Thomas Petazzoni (thomas.petazzoni@free-electrons.com) if you would like to attend.

Attending the event is free, but registration is required.

=== Program ===

* Saturday, 10 AM: beginning of the meeting. The first person to arrive can go directly to the front desk and ask for MARIBEL SOCIAS or anyone in the Reservations Department, and then ask for the meeting room booked for Thomas Petazzoni. [[User:ThomasPetazzoni|Thomas Petazzoni]] will only arrive at 10:30-11 AM.
* Saturday, 7 PM: end of the meeting
* Saturday, 8:30 PM: dinner sponsored by Synopsys
* Sunday, 10 AM: beginning of the meeting
* Sunday, 7 PM: end of the meeting

=== Location ===

The event will take place at [http://www.hotelgrumsbarcelona.com/ Hotel Grumps], in downtown Barcelona. See [http://goo.gl/maps/htYi9 this map] for the location of the hotel, and [http://goo.gl/maps/GdiaM this map] for walking directions between the Fira Palace hotel (location of the ELCE conference) and Hotel Grums.

=== List of topics to discuss ===

* Interaction between Buildroot configuration options to select architecture specifities (architecture variant, soft-float vs. hard-float, etc.) and the multilib variants available in external toolchains. Proposed by [[User:ThomasPetazzoni]].
* Status on the community organization. Has patchwork improved things? Are patches taken into account in a faster way? Proposed by [[User:ThomasPetazzoni]].
* What are the next "big" things for Buildroot? Proposed by [[User:ThomasPetazzoni]].
* Documentation refactoring? Proposed by Samuel Martin.
* Autobuilder tests: needed improvements, future work. Proposed by [[User:ThomasPetazzoni]].
* The _AVAILABLE mechanism, and how to properly handle dependency on toolchain options (discuss the proposal made by Yann E. Morin). Proposed by [[User:ThomasPetazzoni]].
* Discuss (and, if approved, implement) the split between _LICENSE and _REDISTRIBUTE for legal-info. I think this won't take much more than 10 minutes chat + 10 minutes hack. Proposed by Luca Ceresoli.
* Make it possible to use a git repository as source for toolchain. This doesn't work well today. Proposed by Mischa Jonker
* Make it possible to do a 'target-clean', as a replacement of uninstall. Will this even work at all? Proposed by Arnout Vandecappelle
* Does it make sense to port the toolchains to generic-package infrastructure? Asked by Arnout Vandecappelle
* How to provide licensing info for packages that have more than one license. The main use cases are: a) different parts of the source code have different licenses, b) a file (or the whole project) is distributed under two or more licenses or c) a mix of the two. See the recent thoughts about this issue by Yann Morin: http://lists.busybox.net/pipermail/buildroot/2012-October/060475.html
* Support for board stuff outside the buildroot tree. Proposed by Arnout Vandecappelle
* Should we remove the ability to build a toolchain on the target? And also things like development files on target, documentation on target, etc. Proposed by [[User:ThomasPetazzoni]].

=== List of topics to hack on ===

* Reduce the back log of bugs. Proposed by [[User:ThomasPetazzoni]].
* Reduce the back log of patches. Proposed by [[User:ThomasPetazzoni]].
* Work on noMMU platform support (Blackfin, Coldfire). Getting Coldfire Qemu working, adding correct support for FLAT binaries. Proposed by [[User:ThomasPetazzoni]].
* Package upgrades: package python3, gtk3 and latest versions of glib and al. Proposed by [[User:ThomasPetazzoni]].
* Triage autobuilder failures and fix them. Proposed by Arnout Vandecappelle
* Improve the documentation. Proposed by Arnout Vandecappelle
* Work on relocatable toolchain. Proposed by Arnout Vandecappelle
* Add some infra for setup.py/qmake based packages. Proposed by Samuel Martin
* Add some infra for make based packages (mainly using the same pattern all over). Proposed by Arnout Vandecappelle
* Add some infra for Kconfig based packages (linux, barebox, busybox, uclibc, ct-ng, at91bootstrap3). Proposed by Arnout Vandecappelle
* Make top-level make -j possible. Proposed by Arnout Vandecappelle

Buildroot:DeveloperDaysELCE2012

2012-11-04T10:37:48Z

Arnout Vandecappelle:

== Buildroot Developers Meeting, 3-4 November 2012, Barcelona Spain ==

=== What is Buildroot ? ===

[http://buildroot.org 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.

=== Meeting in Barcelona ===

The Buildroot community is organizing a meeting on Saturday November 3rd and Sunday November 4th, for Buildroot developers and contributors. This meeting will be a mixture of discussion and hacking session around the Buildroot project. This meeting takes place right before the Embedded Linux Conference Europe, in order to make it easy for participants to attend both events.

=== Event sponsored by Fluendo and Synopsys ===

The meeting room is sponsored by [http://www.fluendo.com Fluendo]. Thanks!

The Saturday dinner is sponsored by [http://www.synopsys.com Synopsys]. Thanks!

=== Report of the meeting ===

==== Action points ====
* Accept perl series.
* Accept qemu series (after further review).
* Remove compiler on target.
* Remove development files on target.
* Remove documentation on target.
* Explain in the documentation why the above was done.
* Put httpd daemons outside BUSYBOX_SHOW_OTHERS.
* Move BUSYBOX_SHOW_OTHERS conditions to ''depends on'' inside the package Config.in
* busybox: disable mount-nfs in the default config.
* simplify patch logic: if pkg-version directory exists, use that; otherwise, use pkg-*.patch.
* Automate selection of correct FP and other compiler options based on subarchitecture.
* Move download helpers to a script.

==== Details of the discussion ====

# Perl. The perl patch series (now at v11) looks ready to be integrated, but we have our doubts about cpanminus. The problems are: it has separate download infrastructure, which blocks some buildroot features (e.g. make source); it doesn't integrate with the legal-info. However, CPAN is pretty important if you really want to use perl. The decision was to accept cpanminus as well, but add some warnings that some things don't work.
# Qemu. Adding this opens the door for more people to do stuff that buildroot wasn't meant for in the first place (i.e. embedded). However, even in embedded qemu could be relevant. Things like the compiler on the target are much worse for doing crazy things. Giving new packages a chance is OK; we have to be much more careful with things that have global impact (like including development files on target). Conclusion: it's OK to accept qemu.
# Compiler on target. It leads to newbies using buildroot in an inappropriate way (i.e. compile on the target). Also it only works with the internal toolchain. And if we remove it, we can also remove "Development files on target", which simplifies some of the build infrastructure. Also, if you have a compiler on the target, then you can just as well use a distro. Conclusion: we remove it. Also a bunch of other packages can be removed (autotools, vala, ...)
# Documentation on target: if you need this, use a distro. So we remove it.
# We need to explain in the documentation why we removed this stuff.
# Available stuff: i.e. solve the problem of combination of ''select'' and ''depends''. Solving it in Kconfig itself seems to be difficult: there were some patches but the kconfig people didn't like it; Yann and Thomas looked at Kconfig and it looks difficult to modify. The AVAILABLE solution has two problems: it adds verbosity, and the recursive dependencies still should be written in the comments ("libfoo requires WCHAR in the toolchain"). The verbosity is not considered a big issue. For the comments: they currently don't work perfectly either. Removing the comments altogether is an option, but then it is difficult for users to find out why a certain package isn't available. Another possibility is to list the available packages in the documentation (automatically), and mention which toolchain dependencies they have. Wild idea: consider Config.in as a low-level language, and define our own higher-level language from which we generate Config.in. Alternatively, have a developer tool that verifies if everything is consistent (i.e. are the comments correct). One more option: add a big comment in the beginning of the packages list, which says that not all toolchain options are available so not all packages are visible. Converting the toolchain options from ''depends'' to ''select'' is not really an option, because changing toolchain options requires a make clean. We didn't reach a conclusion, we'll come back to it tomorrow.
# kconfig-frontend: Yann now has a repository for Kconfig, it would be nice to branch our Kconfig from that. The idea is to still copy it to our repository.
# BUSYBOX_SHOW_OTHERS: the only reason to have this is to avoid newcomers enabling things like tar etc. which are anyway already in busybox. But for the web servers, they are clearly different from the busybox web servers (and our default busybox config doesn't even enable a web server). Also bash is a typical one, because people write bashisms in their scripts. This discussion is somewhat related to the discussion how to handle packages that provide the same functionality. But for many packages, it's not even the same (httpd, bash, vim). But actually, we're trying to solve a non-existent problem here - except for the web servers. If we generate a list of packages in the documentation, we can add a remark to that that it's also available in busybox. Also move the condition inside the package Config.in instead of outside and make it a ''depends on'', so it is more visible.
# packages with multiple variants: python2/3, Qt4/5, gtk2/3, gstreamer0.10/1.0... This is again similar to the expat/libxml2 issue. Do we support both python2 and python3? We need to support both versions in most cases. Question is if we want to force that only one of the two is selected, or do we support side-by-side installation. Conclusion: has to be looked at on a case-by-case basis. General philosophy: don't try to be too smart, so don't try to force selecting only one of the two if it doesn't make sense to have both. In cases where a package wants to ''select'' one of these things, convert the ''select'' into a ''depends'' with a comment. For gstreamer, the complexity of having the two side-by-side is unacceptable, because there are so many fine-grained gstreamer configure options (in the plugins). However, we expect that everything will move to gstreamer1.0 quite quickly, so for the time being (and only if someone needs it), we can live with a non-perfect solution that just fits the requirements of whoever needs gstreamer1.0.
# multiple packages providing the same functionality: lua/luajit, jpeg/jpegturbo, expat/libxml2. These cannot be installed side-by-side, and many packages select e.g. jpeg. OpenGL will have this issue as well. A relatively clean solution is to create virtual packages for these, where the user has a choice between the two. The normal config option would be hidden for these packages. This still adds complexity in some corner cases, e.g. some package that doesn't work in luajit, but that can probably be solved at the level of that package.
# Autobuild infrastructure. Thomas is working on scripts that parse the build result and put it in a database. One important missing feature at the moment is visibility of evolution over time (i.e. distinguish regressions from recurring problems). Even more important is just being able to see which packages are failing all the time, i.e. for each package how often it failed. Ideally, we would also want to see how often a package has been built successfully, but when is it successful? Does the entire build have to succeed or that package? Overall, however, the autobuild infrastructure is considered very useful - when something is wrong, it appears in the autobuild very quickly.
#* autobuild of the next branch: if only the master is autobuilt, we don't see a lot of problems until after the release. Delaying fixing bugs makes it more difficult to fix them. To support autobuild of the next branch, this should also be made visible in the database so we can distinguish master failures (more important) from next failures.
#* autobuild database is not suitable to track repeated builds of the same configuration. It needs to keep track of different builds of the same configurations. But the question is if this is really useful. We would like to check the existing defconfigs at every release, but it doesn't have to be tracked. So it can be done manually.
# AVR32. It is end of life as far as Atmel is concerned, but of course there are still products out there using it. It is not really blocking for buildroot. For packages which fail to build, we can just add a ''depends on !BR2_avr32''. But of course, until we have the AVAILABLE mechanism, carrying this kind of dependency can be painful.
# RPC support. Originally, the idea was to consider RPC support as a toolchain option, i.e. using ''depends''. However, libtirpc is really a library, comparable to gettext, so it could be enabled automatically with ''select''. Busybox is special, because we don't want to force RPC just because busybox is selected. Therefore busybox has a user-selectable option to enable RPC-based applets (mount-nfs). After discussion, this option was discarded - just remove mount-nfs from busybox (see below). Other packages will use libtirpc if it was selected (manually or automatically). It's still a question what will happen when dynamically linking against libtirpc when libc also has rpc.
# A bit related: we'll disable mount-nfs in the default busybox config; if user disables RPC and enables mount-nfs in busybox, he'll get a compilation error.
# Support for VCS branches in packages: custom packages are often in a VCS and while developing, you want to track a branch of that VCS. OVERRIDE_SRCDIR doesn't work very well because it means the user has to check everything out at the right version in the right location. An alternative would be to teach OVERRIDE_SRCDIR about VCSes, so that ''make foo-rebuild'' re-syncs with the VCS.
# There is a general feeling (mainly from Thomas) that buildroot isn't very convenient during development of a project where several people are working on several components. But no solution was found.
# FP stuff: we now have a single SOFT_FLOAT option, but actually there's a lot more variation: neon, vfpv3, softfp, .... To support this well, we can add a lot of extra config options to semi-automatically select the correct float options based on the subarchitecture. There is some cross-dependency with the external toolchains, but it's doable. There should still be an option to manually override the float options for exotic cases. ARM thumb adds another layer of complexity. Someone should take the lead on making this easier.
# Porting gcc to the generic package infrastructure. Looks like this is a lot of work, and there's not so much need for it.
# Getting gcc from git. It's more convenient to put a tarball somewhere public and use that as an alternative source, similar to avr32.
# Download helpers are getting too complex. It should move a script so at least it's more readable.
# Community organization:
#* It can be useful to have subsystem maintainers, that are responsible for reviewing and accepting patches. In practice, however, it is difficult to split things in a way that we don't risk duplicating work (i.e. two people in the process of merging the same patch). However, one clearly defined subsystem is the documentation. From now on, Samuel Martin is responsible for all documentation patches. He'll send pull requests to Peter.
#* Patches should be accepted more aggressively, even if there hasn't been (much) testing of the patch. The autobuilders will catch any issues. However, it is still important to properly review and comment on coding style issues (i.e. how the features are implemented.

For tomorrow:
* Interaction between Buildroot configuration options to select architecture specifities (architecture variant, soft-float vs. hard-float, etc.) and the multilib variants available in external toolchains. Proposed by [[User:ThomasPetazzoni]].
* Status on the community organization. Has patchwork improved things? Are patches taken into account in a faster way? Proposed by [[User:ThomasPetazzoni]].
* What are the next "big" things for Buildroot? Proposed by [[User:ThomasPetazzoni]].
* Documentation refactoring? Proposed by Samuel Martin.
* The _AVAILABLE mechanism, and how to properly handle dependency on toolchain options (discuss the proposal made by Yann E. Morin). Proposed by [[User:ThomasPetazzoni]].
* Discuss (and, if approved, implement) the split between _LICENSE and _REDISTRIBUTE for legal-info. I think this won't take much more than 10 minutes chat + 10 minutes hack. Proposed by Luca Ceresoli.
* Make it possible to do a 'target-clean', as a replacement of uninstall. Will this even work at all? Proposed by Arnout Vandecappelle
* How to provide licensing info for packages that have more than one license. The main use cases are: a) different parts of the source code have different licenses, b) a file (or the whole project) is distributed under two or more licenses or c) a mix of the two. See the recent thoughts about this issue by Yann Morin: http://lists.busybox.net/pipermail/buildroot/2012-October/060475.html
* Support for board stuff outside the buildroot tree. Proposed by Arnout Vandecappelle

=== Participants ===

# [[User:Arnout_Vandecappelle|Arnout Vandecappelle]], confirmed. Arriving on Fri Nov 2 20:35 at BCN airport. Leaving Wed Nov. 8 21:15 at BCN. Staying at [http://www.hcchotels.es/en/hotel/12/hcc-lugano HCC Lugano]
# [[User:ThomasPetazzoni|Thomas Petazzoni]], confirmed. Arriving on November, 3rd at BCN airport 9:25 AM. Leaving on November 8th from BCN airport at 3:45 PM. Staying at Hotel Fira Palace.
# Maxime Ripard, confirmed. Arriving on November, 1st at BCN airport. Leaving on November 8th from BCP airport at 3:45 PM. Staying at Hotel Fira Palace.
# [[User:PeterKorsgaard|Peter Korsgaard]], confirmed, Arriving on Fri Nov 2 21:55 at BCN airport. Leaving Sun Nov 11 17:15 at BCN. Staying at [http://www.hcchotels.es/en/hotel/12/hcc-lugano HCC Lugano]
# Luca Ceresoli, confirmed. Arriving on November 3rd at BCN airport 10:05 AM. Leaving on November 7th from BCN airport 19:15 PM. Staying at Hotel Fira Palace. Will arrive around 11:30 AM for the meeting.
# Samuel Martin, confirmed. Arriving on November, 3rd at Barcelona-Franca Train Station 8:05 AM. Leaving on November 10th from Barcelona-Franca Train Station at 8:43 PM.
# Simon Dawson, confirmed. Arriving on November 2nd in the evening. Leaving on November 8th early morning.
# Mischa Jonker, confirmed. From Synopsys.com. Not contributing yet to Buildroot, but interested in using Buildroot for a brand new CPU architecture. Arriving Friday Nov 2nd BCN 21:10 CET, staying at Catalonia Barcelona Plaza (Plaza Espanya), leaving Thursday Nov 8 at 18:40 CET.
# Maxime Hadjinlian.

=== Registration ===

Please contact Thomas Petazzoni (thomas.petazzoni@free-electrons.com) if you would like to attend.

Attending the event is free, but registration is required.

=== Program ===

* Saturday, 10 AM: beginning of the meeting. The first person to arrive can go directly to the front desk and ask for MARIBEL SOCIAS or anyone in the Reservations Department, and then ask for the meeting room booked for Thomas Petazzoni. [[User:ThomasPetazzoni|Thomas Petazzoni]] will only arrive at 10:30-11 AM.
* Saturday, 7 PM: end of the meeting
* Saturday, 8:30 PM: dinner sponsored by Synopsys
* Sunday, 10 AM: beginning of the meeting
* Sunday, 7 PM: end of the meeting

=== Location ===

The event will take place at [http://www.hotelgrumsbarcelona.com/ Hotel Grumps], in downtown Barcelona. See [http://goo.gl/maps/htYi9 this map] for the location of the hotel, and [http://goo.gl/maps/GdiaM this map] for walking directions between the Fira Palace hotel (location of the ELCE conference) and Hotel Grums.

=== List of topics to discuss ===

* Interaction between Buildroot configuration options to select architecture specifities (architecture variant, soft-float vs. hard-float, etc.) and the multilib variants available in external toolchains. Proposed by [[User:ThomasPetazzoni]].
* Status on the community organization. Has patchwork improved things? Are patches taken into account in a faster way? Proposed by [[User:ThomasPetazzoni]].
* What are the next "big" things for Buildroot? Proposed by [[User:ThomasPetazzoni]].
* Documentation refactoring? Proposed by Samuel Martin.
* Autobuilder tests: needed improvements, future work. Proposed by [[User:ThomasPetazzoni]].
* The _AVAILABLE mechanism, and how to properly handle dependency on toolchain options (discuss the proposal made by Yann E. Morin). Proposed by [[User:ThomasPetazzoni]].
* Discuss (and, if approved, implement) the split between _LICENSE and _REDISTRIBUTE for legal-info. I think this won't take much more than 10 minutes chat + 10 minutes hack. Proposed by Luca Ceresoli.
* Make it possible to use a git repository as source for toolchain. This doesn't work well today. Proposed by Mischa Jonker
* Make it possible to do a 'target-clean', as a replacement of uninstall. Will this even work at all? Proposed by Arnout Vandecappelle
* Does it make sense to port the toolchains to generic-package infrastructure? Asked by Arnout Vandecappelle
* How to provide licensing info for packages that have more than one license. The main use cases are: a) different parts of the source code have different licenses, b) a file (or the whole project) is distributed under two or more licenses or c) a mix of the two. See the recent thoughts about this issue by Yann Morin: http://lists.busybox.net/pipermail/buildroot/2012-October/060475.html
* Support for board stuff outside the buildroot tree. Proposed by Arnout Vandecappelle
* Should we remove the ability to build a toolchain on the target? And also things like development files on target, documentation on target, etc. Proposed by [[User:ThomasPetazzoni]].

=== List of topics to hack on ===

* Reduce the back log of bugs. Proposed by [[User:ThomasPetazzoni]].
* Reduce the back log of patches. Proposed by [[User:ThomasPetazzoni]].
* Work on noMMU platform support (Blackfin, Coldfire). Getting Coldfire Qemu working, adding correct support for FLAT binaries. Proposed by [[User:ThomasPetazzoni]].
* Package upgrades: package python3, gtk3 and latest versions of glib and al. Proposed by [[User:ThomasPetazzoni]].
* Triage autobuilder failures and fix them. Proposed by Arnout Vandecappelle
* Improve the documentation. Proposed by Arnout Vandecappelle
* Work on relocatable toolchain. Proposed by Arnout Vandecappelle
* Add some infra for setup.py/qmake based packages. Proposed by Samuel Martin
* Add some infra for make based packages (mainly using the same pattern all over). Proposed by Arnout Vandecappelle
* Add some infra for Kconfig based packages (linux, barebox, busybox, uclibc, ct-ng, at91bootstrap3). Proposed by Arnout Vandecappelle
* Make top-level make -j possible. Proposed by Arnout Vandecappelle

Buildroot:DeveloperDaysELCE2012

2012-11-03T18:13:29Z

Arnout Vandecappelle:

== Buildroot Developers Meeting, 3-4 November 2012, Barcelona Spain ==

=== What is Buildroot ? ===

[http://buildroot.org 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.

=== Meeting in Barcelona ===

The Buildroot community is organizing a meeting on Saturday November 3rd and Sunday November 4th, for Buildroot developers and contributors. This meeting will be a mixture of discussion and hacking session around the Buildroot project. This meeting takes place right before the Embedded Linux Conference Europe, in order to make it easy for participants to attend both events.

=== Event sponsored by Fluendo and Synopsys ===

The meeting room is sponsored by [http://www.fluendo.com Fluendo]. Thanks!

The Saturday dinner is sponsored by [http://www.synopsys.com Synopsys]. Thanks!

=== Report of the meeting ===

==== Action points ====
* Accept perl series.
* Accept qemu series (after further review).
* Remove compiler on target.
* Remove development files on target.
* Remove documentation on target.
* Explain in the documentation why the above was done.
* Put httpd daemons outside BUSYBOX_SHOW_OTHERS.
* Move BUSYBOX_SHOW_OTHERS conditions to ''depends on'' inside the package Config.in
* busybox: disable mount-nfs in the default config.
* simplify patch logic: if pkg-version directory exists, use that; otherwise, use pkg-*.patch.
* Automate selection of correct FP and other compiler options based on subarchitecture.
* Move download helpers to a script.

==== Details of the discussion ====

# Perl. The perl patch series (now at v11) looks ready to be integrated, but we have our doubts about cpanminus. The problems are: it has separate download infrastructure, which blocks some buildroot features (e.g. make source); it doesn't integrate with the legal-info. However, CPAN is pretty important if you really want to use perl. The decision was to accept cpanminus as well, but add some warnings that some things don't work.
# Qemu. Adding this opens the door for more people to do stuff that buildroot wasn't meant for in the first place (i.e. embedded). However, even in embedded qemu could be relevant. Things like the compiler on the target are much worse for doing crazy things. Giving new packages a chance is OK; we have to be much more careful with things that have global impact (like including development files on target). Conclusion: it's OK to accept qemu.
# Compiler on target. It leads to newbies using buildroot in an inappropriate way (i.e. compile on the target). Also it only works with the internal toolchain. And if we remove it, we can also remove "Development files on target", which simplifies some of the build infrastructure. Also, if you have a compiler on the target, then you can just as well use a distro. Conclusion: we remove it. Also a bunch of other packages can be removed (autotools, vala, ...)
# Documentation on target: if you need this, use a distro. So we remove it.
# We need to explain in the documentation why we removed this stuff.
# Available stuff: i.e. solve the problem of combination of ''select'' and ''depends''. Solving it in Kconfig itself seems to be difficult: there were some patches but the kconfig people didn't like it; Yann and Thomas looked at Kconfig and it looks difficult to modify. The AVAILABLE solution has two problems: it adds verbosity, and the recursive dependencies still should be written in the comments ("libfoo requires WCHAR in the toolchain"). The verbosity is not considered a big issue. For the comments: they currently don't work perfectly either. Removing the comments altogether is an option, but then it is difficult for users to find out why a certain package isn't available. Another possibility is to list the available packages in the documentation (automatically), and mention which toolchain dependencies they have. Wild idea: consider Config.in as a low-level language, and define our own higher-level language from which we generate Config.in. Alternatively, have a developer tool that verifies if everything is consistent (i.e. are the comments correct). One more option: add a big comment in the beginning of the packages list, which says that not all toolchain options are available so not all packages are visible. Converting the toolchain options from ''depends'' to ''select'' is not really an option, because changing toolchain options requires a make clean. We didn't reach a conclusion, we'll come back to it tomorrow.
# kconfig-frontend: Yann now has a repository for Kconfig, it would be nice to branch our Kconfig from that. The idea is to still copy it to our repository.
# BUSYBOX_SHOW_OTHERS: the only reason to have this is to avoid newcomers enabling things like tar etc. which are anyway already in busybox. But for the web servers, they are clearly different from the busybox web servers (and our default busybox config doesn't even enable a web server). Also bash is a typical one, because people write bashisms in their scripts. This discussion is somewhat related to the discussion how to handle packages that provide the same functionality. But for many packages, it's not even the same (httpd, bash, vim). But actually, we're trying to solve a non-existent problem here - except for the web servers. If we generate a list of packages in the documentation, we can add a remark to that that it's also available in busybox. Also move the condition inside the package Config.in instead of outside and make it a ''depends on'', so it is more visible.
# packages with multiple variants: python2/3, Qt4/5, gtk2/3, ... This is again similar to the expat/libxml2 issue. Do we support both python2 and python3? We need to support both versions in most cases. Question is if we want to force that only one of the two is selected, or do we support side-by-side installation. Conclusion: has to be looked at on a case-by-case basis. General philosophy: don't try to be too smart, so don't try to force selecting only one of the two if it doesn't make sense to have both. In cases where a package wants to ''select'' one of these things, convert the ''select'' into a ''depends'' with a comment.
# multiple packages providing the same functionality: lua/luajit, jpeg/jpegturbo, expat/libxml2. These cannot be installed side-by-side, and many packages select e.g. jpeg. OpenGL will have this issue as well. A relatively clean solution is to create virtual packages for these, where the user has a choice between the two. The normal config option would be hidden for these packages. This still adds complexity in some corner cases, e.g. some package that doesn't work in luajit, but that can probably be solved at the level of that package.
# Autobuild infrastructure. Thomas is working on scripts that parse the build result and put it in a database. One important missing feature at the moment is visibility of evolution over time (i.e. distinguish regressions from recurring problems). Even more important is just being able to see which packages are failing all the time, i.e. for each package how often it failed. Ideally, we would also want to see how often a package has been built successfully, but when is it successful? Does the entire build have to succeed or that package? Overall, however, the autobuild infrastructure is considered very useful - when something is wrong, it appears in the autobuild very quickly.
#* autobuild of the next branch: if only the master is autobuilt, we don't see a lot of problems until after the release. Delaying fixing bugs makes it more difficult to fix them. To support autobuild of the next branch, this should also be made visible in the database so we can distinguish master failures (more important) from next failures.
#* autobuild database is not suitable to track repeated builds of the same configuration. It needs to keep track of different builds of the same configurations. But the question is if this is really useful. We would like to check the existing defconfigs at every release, but it doesn't have to be tracked. So it can be done manually.
# AVR32. It is end of life as far as Atmel is concerned, but of course there are still products out there using it. It is not really blocking for buildroot. For packages which fail to build, we can just add a ''depends on !BR2_avr32''. But of course, until we have the AVAILABLE mechanism, carrying this kind of dependency can be painful.
# RPC support. Originally, the idea was to consider RPC support as a toolchain option, i.e. using ''depends''. However, libtirpc is really a library, comparable to gettext, so it could be enabled automatically with ''select''. Busybox is special, because we don't want to force RPC just because busybox is selected. Therefore busybox has a user-selectable option to enable RPC-based applets (mount-nfs). After discussion, this option was discarded - just remove mount-nfs from busybox (see below). Other packages will use libtirpc if it was selected (manually or automatically). It's still a question what will happen when dynamically linking against libtirpc when libc also has rpc.
# A bit related: we'll disable mount-nfs in the default busybox config; if user disables RPC and enables mount-nfs in busybox, he'll get a compilation error.
# Support for VCS branches in packages: custom packages are often in a VCS and while developing, you want to track a branch of that VCS. OVERRIDE_SRCDIR doesn't work very well because it means the user has to check everything out at the right version in the right location. An alternative would be to teach OVERRIDE_SRCDIR about VCSes, so that ''make foo-rebuild'' re-syncs with the VCS.
# There is a general feeling (mainly from Thomas) that buildroot isn't very convenient during development of a project where several people are working on several components. But no solution was found.
# FP stuff: we now have a single SOFT_FLOAT option, but actually there's a lot more variation: neon, vfpv3, softfp, .... To support this well, we can add a lot of extra config options to semi-automatically select the correct float options based on the subarchitecture. There is some cross-dependency with the external toolchains, but it's doable. There should still be an option to manually override the float options for exotic cases. ARM thumb adds another layer of complexity. Someone should take the lead on making this easier.
# Porting gcc to the generic package infrastructure. Looks like this is a lot of work, and there's not so much need for it.
# Getting gcc from git. It's more convenient to put a tarball somewhere public and use that as an alternative source, similar to avr32.
# Download helpers are getting too complex. It should move a script so at least it's more readable.
# Community organization:
#* It can be useful to have subsystem maintainers, that are responsible for reviewing and accepting patches. In practice, however, it is difficult to split things in a way that we don't risk duplicating work (i.e. two people in the process of merging the same patch). However, one clearly defined subsystem is the documentation. From now on, Samuel Martin is responsible for all documentation patches. He'll send pull requests to Peter.
#* Patches should be accepted more aggressively, even if there hasn't been (much) testing of the patch. The autobuilders will catch any issues. However, it is still important to properly review and comment on coding style issues (i.e. how the features are implemented.

For tomorrow:
* Interaction between Buildroot configuration options to select architecture specifities (architecture variant, soft-float vs. hard-float, etc.) and the multilib variants available in external toolchains. Proposed by [[User:ThomasPetazzoni]].
* Status on the community organization. Has patchwork improved things? Are patches taken into account in a faster way? Proposed by [[User:ThomasPetazzoni]].
* What are the next "big" things for Buildroot? Proposed by [[User:ThomasPetazzoni]].
* Documentation refactoring? Proposed by Samuel Martin.
* The _AVAILABLE mechanism, and how to properly handle dependency on toolchain options (discuss the proposal made by Yann E. Morin). Proposed by [[User:ThomasPetazzoni]].
* Discuss (and, if approved, implement) the split between _LICENSE and _REDISTRIBUTE for legal-info. I think this won't take much more than 10 minutes chat + 10 minutes hack. Proposed by Luca Ceresoli.
* Make it possible to do a 'target-clean', as a replacement of uninstall. Will this even work at all? Proposed by Arnout Vandecappelle
* How to provide licensing info for packages that have more than one license. The main use cases are: a) different parts of the source code have different licenses, b) a file (or the whole project) is distributed under two or more licenses or c) a mix of the two. See the recent thoughts about this issue by Yann Morin: http://lists.busybox.net/pipermail/buildroot/2012-October/060475.html
* Support for board stuff outside the buildroot tree. Proposed by Arnout Vandecappelle

=== Participants ===

# [[User:Arnout_Vandecappelle|Arnout Vandecappelle]], confirmed. Arriving on Fri Nov 2 20:35 at BCN airport. Leaving Wed Nov. 8 21:15 at BCN. Staying at [http://www.hcchotels.es/en/hotel/12/hcc-lugano HCC Lugano]
# [[User:ThomasPetazzoni|Thomas Petazzoni]], confirmed. Arriving on November, 3rd at BCN airport 9:25 AM. Leaving on November 8th from BCN airport at 3:45 PM. Staying at Hotel Fira Palace.
# Maxime Ripard, confirmed. Arriving on November, 1st at BCN airport. Leaving on November 8th from BCP airport at 3:45 PM. Staying at Hotel Fira Palace.
# [[User:PeterKorsgaard|Peter Korsgaard]], confirmed, Arriving on Fri Nov 2 21:55 at BCN airport. Leaving Sun Nov 11 17:15 at BCN. Staying at [http://www.hcchotels.es/en/hotel/12/hcc-lugano HCC Lugano]
# Luca Ceresoli, confirmed. Arriving on November 3rd at BCN airport 10:05 AM. Leaving on November 7th from BCN airport 19:15 PM. Staying at Hotel Fira Palace. Will arrive around 11:30 AM for the meeting.
# Samuel Martin, confirmed. Arriving on November, 3rd at Barcelona-Franca Train Station 8:05 AM. Leaving on November 10th from Barcelona-Franca Train Station at 8:43 PM.
# Simon Dawson, confirmed. Arriving on November 2nd in the evening. Leaving on November 8th early morning.
# Mischa Jonker, confirmed. From Synopsys.com. Not contributing yet to Buildroot, but interested in using Buildroot for a brand new CPU architecture. Arriving Friday Nov 2nd BCN 21:10 CET, staying at Catalonia Barcelona Plaza (Plaza Espanya), leaving Thursday Nov 8 at 18:40 CET.
# Maxime Hadjinlian.

=== Registration ===

Please contact Thomas Petazzoni (thomas.petazzoni@free-electrons.com) if you would like to attend.

Attending the event is free, but registration is required.

=== Program ===

* Saturday, 10 AM: beginning of the meeting. The first person to arrive can go directly to the front desk and ask for MARIBEL SOCIAS or anyone in the Reservations Department, and then ask for the meeting room booked for Thomas Petazzoni. [[User:ThomasPetazzoni|Thomas Petazzoni]] will only arrive at 10:30-11 AM.
* Saturday, 7 PM: end of the meeting
* Saturday, 8:30 PM: dinner sponsored by Synopsys
* Sunday, 10 AM: beginning of the meeting
* Sunday, 7 PM: end of the meeting

=== Location ===

The event will take place at [http://www.hotelgrumsbarcelona.com/ Hotel Grumps], in downtown Barcelona. See [http://goo.gl/maps/htYi9 this map] for the location of the hotel, and [http://goo.gl/maps/GdiaM this map] for walking directions between the Fira Palace hotel (location of the ELCE conference) and Hotel Grums.

=== List of topics to discuss ===

* Interaction between Buildroot configuration options to select architecture specifities (architecture variant, soft-float vs. hard-float, etc.) and the multilib variants available in external toolchains. Proposed by [[User:ThomasPetazzoni]].
* Status on the community organization. Has patchwork improved things? Are patches taken into account in a faster way? Proposed by [[User:ThomasPetazzoni]].
* What are the next "big" things for Buildroot? Proposed by [[User:ThomasPetazzoni]].
* Documentation refactoring? Proposed by Samuel Martin.
* Autobuilder tests: needed improvements, future work. Proposed by [[User:ThomasPetazzoni]].
* The _AVAILABLE mechanism, and how to properly handle dependency on toolchain options (discuss the proposal made by Yann E. Morin). Proposed by [[User:ThomasPetazzoni]].
* Discuss (and, if approved, implement) the split between _LICENSE and _REDISTRIBUTE for legal-info. I think this won't take much more than 10 minutes chat + 10 minutes hack. Proposed by Luca Ceresoli.
* Make it possible to use a git repository as source for toolchain. This doesn't work well today. Proposed by Mischa Jonker
* Make it possible to do a 'target-clean', as a replacement of uninstall. Will this even work at all? Proposed by Arnout Vandecappelle
* Does it make sense to port the toolchains to generic-package infrastructure? Asked by Arnout Vandecappelle
* How to provide licensing info for packages that have more than one license. The main use cases are: a) different parts of the source code have different licenses, b) a file (or the whole project) is distributed under two or more licenses or c) a mix of the two. See the recent thoughts about this issue by Yann Morin: http://lists.busybox.net/pipermail/buildroot/2012-October/060475.html
* Support for board stuff outside the buildroot tree. Proposed by Arnout Vandecappelle
* Should we remove the ability to build a toolchain on the target? And also things like development files on target, documentation on target, etc. Proposed by [[User:ThomasPetazzoni]].

=== List of topics to hack on ===

* Reduce the back log of bugs. Proposed by [[User:ThomasPetazzoni]].
* Reduce the back log of patches. Proposed by [[User:ThomasPetazzoni]].
* Work on noMMU platform support (Blackfin, Coldfire). Getting Coldfire Qemu working, adding correct support for FLAT binaries. Proposed by [[User:ThomasPetazzoni]].
* Package upgrades: package python3, gtk3 and latest versions of glib and al. Proposed by [[User:ThomasPetazzoni]].
* Triage autobuilder failures and fix them. Proposed by Arnout Vandecappelle
* Improve the documentation. Proposed by Arnout Vandecappelle
* Work on relocatable toolchain. Proposed by Arnout Vandecappelle
* Add some infra for setup.py/qmake based packages. Proposed by Samuel Martin
* Add some infra for make based packages (mainly using the same pattern all over). Proposed by Arnout Vandecappelle
* Add some infra for Kconfig based packages (linux, barebox, busybox, uclibc, ct-ng, at91bootstrap3). Proposed by Arnout Vandecappelle
* Make top-level make -j possible. Proposed by Arnout Vandecappelle

Buildroot:DeveloperDaysELCE2012

2012-11-03T16:06:49Z

Arnout Vandecappelle:

== Buildroot Developers Meeting, 3-4 November 2012, Barcelona Spain ==

=== What is Buildroot ? ===

[http://buildroot.org 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.

=== Meeting in Barcelona ===

The Buildroot community is organizing a meeting on Saturday November 3rd and Sunday November 4th, for Buildroot developers and contributors. This meeting will be a mixture of discussion and hacking session around the Buildroot project. This meeting takes place right before the Embedded Linux Conference Europe, in order to make it easy for participants to attend both events.

=== Event sponsored by Fluendo and Synopsys ===

The meeting room is sponsored by [http://www.fluendo.com Fluendo]. Thanks!

The Saturday dinner is sponsored by [http://www.synopsys.com Synopsys]. Thanks!

=== Report of the meeting ===

==== Action points ====
* Accept perl series.
* Accept qemu series (after further review).
* Remove compiler on target.
* Remove development files on target.
* Remove documentation on target.
* Explain in the documentation why the above was done.
* Put httpd daemons outside BUSYBOX_SHOW_OTHERS.
* Move BUSYBOX_SHOW_OTHERS conditions to ''depends on'' inside the package Config.in
* busybox: disable mount-nfs in the default config.
* simplify patch logic: if pkg-version directory exists, use that; otherwise, use pkg-*.patch.
* Automate selection of correct FP and other compiler options based on subarchitecture.

==== Details of the discussion ====

# Perl. The perl patch series (now at v11) looks ready to be integrated, but we have our doubts about cpanminus. The problems are: it has separate download infrastructure, which blocks some buildroot features (e.g. make source); it doesn't integrate with the legal-info. However, CPAN is pretty important if you really want to use perl. The decision was to accept cpanminus as well, but add some warnings that some things don't work.
# Qemu. Adding this opens the door for more people to do stuff that buildroot wasn't meant for in the first place (i.e. embedded). However, even in embedded qemu could be relevant. Things like the compiler on the target are much worse for doing crazy things. Giving new packages a chance is OK; we have to be much more careful with things that have global impact (like including development files on target). Conclusion: it's OK to accept qemu.
# Compiler on target. It leads to newbies using buildroot in an inappropriate way (i.e. compile on the target). Also it only works with the internal toolchain. And if we remove it, we can also remove "Development files on target", which simplifies some of the build infrastructure. Also, if you have a compiler on the target, then you can just as well use a distro. Conclusion: we remove it. Also a bunch of other packages can be removed (autotools, vala, ...)
# Documentation on target: if you need this, use a distro. So we remove it.
# We need to explain in the documentation why we removed this stuff.
# Available stuff: i.e. solve the problem of combination of ''select'' and ''depends''. Solving it in Kconfig itself seems to be difficult: there were some patches but the kconfig people didn't like it; Yann and Thomas looked at Kconfig and it looks difficult to modify. The AVAILABLE solution has two problems: it adds verbosity, and the recursive dependencies still should be written in the comments ("libfoo requires WCHAR in the toolchain"). The verbosity is not considered a big issue. For the comments: they currently don't work perfectly either. Removing the comments altogether is an option, but then it is difficult for users to find out why a certain package isn't available. Another possibility is to list the available packages in the documentation (automatically), and mention which toolchain dependencies they have. Wild idea: consider Config.in as a low-level language, and define our own higher-level language from which we generate Config.in. Alternatively, have a developer tool that verifies if everything is consistent (i.e. are the comments correct). One more option: add a big comment in the beginning of the packages list, which says that not all toolchain options are available so not all packages are visible. Converting the toolchain options from ''depends'' to ''select'' is not really an option, because changing toolchain options requires a make clean. We didn't reach a conclusion, we'll come back to it tomorrow.
# kconfig-frontend: Yann now has a repository for Kconfig, it would be nice to branch our Kconfig from that. The idea is to still copy it to our repository.
# BUSYBOX_SHOW_OTHERS: the only reason to have this is to avoid newcomers enabling things like tar etc. which are anyway already in busybox. But for the web servers, they are clearly different from the busybox web servers (and our default busybox config doesn't even enable a web server). Also bash is a typical one, because people write bashisms in their scripts. This discussion is somewhat related to the discussion how to handle packages that provide the same functionality. But for many packages, it's not even the same (httpd, bash, vim). But actually, we're trying to solve a non-existent problem here - except for the web servers. If we generate a list of packages in the documentation, we can add a remark to that that it's also available in busybox. Also move the condition inside the package Config.in instead of outside and make it a ''depends on'', so it is more visible.
# packages with multiple variants: python2/3, Qt4/5, gtk2/3, ... This is again similar to the expat/libxml2 issue. Do we support both python2 and python3? We need to support both versions in most cases. Question is if we want to force that only one of the two is selected, or do we support side-by-side installation. Conclusion: has to be looked at on a case-by-case basis. General philosophy: don't try to be too smart, so don't try to force selecting only one of the two if it doesn't make sense to have both. In cases where a package wants to ''select'' one of these things, convert the ''select'' into a ''depends'' with a comment.
# multiple packages providing the same functionality: lua/luajit, jpeg/jpegturbo, expat/libxml2. These cannot be installed side-by-side, and many packages select e.g. jpeg. OpenGL will have this issue as well. A relatively clean solution is to create virtual packages for these, where the user has a choice between the two. The normal config option would be hidden for these packages. This still adds complexity in some corner cases, e.g. some package that doesn't work in luajit, but that can probably be solved at the level of that package.
# Autobuild infrastructure. Thomas is working on scripts that parse the build result and put it in a database. One important missing feature at the moment is visibility of evolution over time (i.e. distinguish regressions from recurring problems). Even more important is just being able to see which packages are failing all the time, i.e. for each package how often it failed. Ideally, we would also want to see how often a package has been built successfully, but when is it successful? Does the entire build have to succeed or that package? Overall, however, the autobuild infrastructure is considered very useful - when something is wrong, it appears in the autobuild very quickly.
#* autobuild of the next branch: if only the master is autobuilt, we don't see a lot of problems until after the release. Delaying fixing bugs makes it more difficult to fix them. To support autobuild of the next branch, this should also be made visible in the database so we can distinguish master failures (more important) from next failures.
#* autobuild database is not suitable to track repeated builds of the same configuration. It needs to keep track of different builds of the same configurations. But the question is if this is really useful. We would like to check the existing defconfigs at every release, but it doesn't have to be tracked. So it can be done manually.
# AVR32. It is end of life as far as Atmel is concerned, but of course there are still products out there using it. It is not really blocking for buildroot. For packages which fail to build, we can just add a ''depends on !BR2_avr32''. But of course, until we have the AVAILABLE mechanism, carrying this kind of dependency can be painful.
# RPC support. Originally, the idea was to consider RPC support as a toolchain option, i.e. using ''depends''. However, libtirpc is really a library, comparable to gettext, so it could be enabled automatically with ''select''. Busybox is special, because we don't want to force RPC just because busybox is selected. Therefore busybox has a user-selectable option to enable RPC-based applets (mount-nfs). After discussion, this option was discarded - just remove mount-nfs from busybox (see below). Other packages will use libtirpc if it was selected (manually or automatically). It's still a question what will happen when dynamically linking against libtirpc when libc also has rpc.
# A bit related: we'll disable mount-nfs in the default busybox config; if user disables RPC and enables mount-nfs in busybox, he'll get a compilation error.
# Support for VCS branches in packages: custom packages are often in a VCS and while developing, you want to track a branch of that VCS. OVERRIDE_SRCDIR doesn't work very well because it means the user has to check everything out at the right version in the right location. An alternative would be to teach OVERRIDE_SRCDIR about VCSes, so that ''make foo-rebuild'' re-syncs with the VCS.
# There is a general feeling (mainly from Thomas) that buildroot isn't very convenient during development of a project where several people are working on several components. But no solution was found.
# FP stuff: we now have a single SOFT_FLOAT option, but actually there's a lot more variation: neon, vfpv3, softfp, .... To support this well, we can add a lot of extra config options to semi-automatically select the correct float options based on the subarchitecture. There is some cross-dependency with the external toolchains, but it's doable. There should still be an option to manually override the float options for exotic cases. ARM thumb adds another layer of complexity. Someone should take the lead on making this easier.
# Porting gcc to the generic package infrastructure. Looks like this is a lot of work, and there's not so much need for it.
# Getting gcc from git. It's more convenient to put a tarball somewhere public and use that as an alternative source, similar to avr32.

For tomorrow:
* Interaction between Buildroot configuration options to select architecture specifities (architecture variant, soft-float vs. hard-float, etc.) and the multilib variants available in external toolchains. Proposed by [[User:ThomasPetazzoni]].
* Status on the community organization. Has patchwork improved things? Are patches taken into account in a faster way? Proposed by [[User:ThomasPetazzoni]].
* What are the next "big" things for Buildroot? Proposed by [[User:ThomasPetazzoni]].
* Documentation refactoring? Proposed by Samuel Martin.
* The _AVAILABLE mechanism, and how to properly handle dependency on toolchain options (discuss the proposal made by Yann E. Morin). Proposed by [[User:ThomasPetazzoni]].
* Discuss (and, if approved, implement) the split between _LICENSE and _REDISTRIBUTE for legal-info. I think this won't take much more than 10 minutes chat + 10 minutes hack. Proposed by Luca Ceresoli.
* Make it possible to do a 'target-clean', as a replacement of uninstall. Will this even work at all? Proposed by Arnout Vandecappelle
* How to provide licensing info for packages that have more than one license. The main use cases are: a) different parts of the source code have different licenses, b) a file (or the whole project) is distributed under two or more licenses or c) a mix of the two. See the recent thoughts about this issue by Yann Morin: http://lists.busybox.net/pipermail/buildroot/2012-October/060475.html
* Support for board stuff outside the buildroot tree. Proposed by Arnout Vandecappelle

=== Participants ===

# [[User:Arnout_Vandecappelle|Arnout Vandecappelle]], confirmed. Arriving on Fri Nov 2 20:35 at BCN airport. Leaving Wed Nov. 8 21:15 at BCN. Staying at [http://www.hcchotels.es/en/hotel/12/hcc-lugano HCC Lugano]
# [[User:ThomasPetazzoni|Thomas Petazzoni]], confirmed. Arriving on November, 3rd at BCN airport 9:25 AM. Leaving on November 8th from BCN airport at 3:45 PM. Staying at Hotel Fira Palace.
# Maxime Ripard, confirmed. Arriving on November, 1st at BCN airport. Leaving on November 8th from BCP airport at 3:45 PM. Staying at Hotel Fira Palace.
# [[User:PeterKorsgaard|Peter Korsgaard]], confirmed, Arriving on Fri Nov 2 21:55 at BCN airport. Leaving Sun Nov 11 17:15 at BCN. Staying at [http://www.hcchotels.es/en/hotel/12/hcc-lugano HCC Lugano]
# Luca Ceresoli, confirmed. Arriving on November 3rd at BCN airport 10:05 AM. Leaving on November 7th from BCN airport 19:15 PM. Staying at Hotel Fira Palace. Will arrive around 11:30 AM for the meeting.
# Samuel Martin, confirmed. Arriving on November, 3rd at Barcelona-Franca Train Station 8:05 AM. Leaving on November 10th from Barcelona-Franca Train Station at 8:43 PM.
# Simon Dawson, confirmed. Arriving on November 2nd in the evening. Leaving on November 8th early morning.
# Mischa Jonker, confirmed. From Synopsys.com. Not contributing yet to Buildroot, but interested in using Buildroot for a brand new CPU architecture. Arriving Friday Nov 2nd BCN 21:10 CET, staying at Catalonia Barcelona Plaza (Plaza Espanya), leaving Thursday Nov 8 at 18:40 CET.
# Maxime Hadjinlian.

=== Registration ===

Please contact Thomas Petazzoni (thomas.petazzoni@free-electrons.com) if you would like to attend.

Attending the event is free, but registration is required.

=== Program ===

* Saturday, 10 AM: beginning of the meeting. The first person to arrive can go directly to the front desk and ask for MARIBEL SOCIAS or anyone in the Reservations Department, and then ask for the meeting room booked for Thomas Petazzoni. [[User:ThomasPetazzoni|Thomas Petazzoni]] will only arrive at 10:30-11 AM.
* Saturday, 7 PM: end of the meeting
* Saturday, 8:30 PM: dinner sponsored by Synopsys
* Sunday, 10 AM: beginning of the meeting
* Sunday, 7 PM: end of the meeting

=== Location ===

The event will take place at [http://www.hotelgrumsbarcelona.com/ Hotel Grumps], in downtown Barcelona. See [http://goo.gl/maps/htYi9 this map] for the location of the hotel, and [http://goo.gl/maps/GdiaM this map] for walking directions between the Fira Palace hotel (location of the ELCE conference) and Hotel Grums.

=== List of topics to discuss ===

* Interaction between Buildroot configuration options to select architecture specifities (architecture variant, soft-float vs. hard-float, etc.) and the multilib variants available in external toolchains. Proposed by [[User:ThomasPetazzoni]].
* Status on the community organization. Has patchwork improved things? Are patches taken into account in a faster way? Proposed by [[User:ThomasPetazzoni]].
* What are the next "big" things for Buildroot? Proposed by [[User:ThomasPetazzoni]].
* Documentation refactoring? Proposed by Samuel Martin.
* Autobuilder tests: needed improvements, future work. Proposed by [[User:ThomasPetazzoni]].
* The _AVAILABLE mechanism, and how to properly handle dependency on toolchain options (discuss the proposal made by Yann E. Morin). Proposed by [[User:ThomasPetazzoni]].
* Discuss (and, if approved, implement) the split between _LICENSE and _REDISTRIBUTE for legal-info. I think this won't take much more than 10 minutes chat + 10 minutes hack. Proposed by Luca Ceresoli.
* Make it possible to use a git repository as source for toolchain. This doesn't work well today. Proposed by Mischa Jonker
* Make it possible to do a 'target-clean', as a replacement of uninstall. Will this even work at all? Proposed by Arnout Vandecappelle
* Does it make sense to port the toolchains to generic-package infrastructure? Asked by Arnout Vandecappelle
* How to provide licensing info for packages that have more than one license. The main use cases are: a) different parts of the source code have different licenses, b) a file (or the whole project) is distributed under two or more licenses or c) a mix of the two. See the recent thoughts about this issue by Yann Morin: http://lists.busybox.net/pipermail/buildroot/2012-October/060475.html
* Support for board stuff outside the buildroot tree. Proposed by Arnout Vandecappelle
* Should we remove the ability to build a toolchain on the target? And also things like development files on target, documentation on target, etc. Proposed by [[User:ThomasPetazzoni]].

=== List of topics to hack on ===

* Reduce the back log of bugs. Proposed by [[User:ThomasPetazzoni]].
* Reduce the back log of patches. Proposed by [[User:ThomasPetazzoni]].
* Work on noMMU platform support (Blackfin, Coldfire). Getting Coldfire Qemu working, adding correct support for FLAT binaries. Proposed by [[User:ThomasPetazzoni]].
* Package upgrades: package python3, gtk3 and latest versions of glib and al. Proposed by [[User:ThomasPetazzoni]].
* Triage autobuilder failures and fix them. Proposed by Arnout Vandecappelle
* Improve the documentation. Proposed by Arnout Vandecappelle
* Work on relocatable toolchain. Proposed by Arnout Vandecappelle
* Add some infra for setup.py/qmake based packages. Proposed by Samuel Martin
* Add some infra for make based packages (mainly using the same pattern all over). Proposed by Arnout Vandecappelle
* Add some infra for Kconfig based packages (linux, barebox, busybox, uclibc, ct-ng, at91bootstrap3). Proposed by Arnout Vandecappelle
* Make top-level make -j possible. Proposed by Arnout Vandecappelle

Buildroot:DeveloperDaysELCE2012

2012-11-03T15:46:43Z

Arnout Vandecappelle: /* Report of the meeting */

== Buildroot Developers Meeting, 3-4 November 2012, Barcelona Spain ==

=== What is Buildroot ? ===

[http://buildroot.org 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.

=== Meeting in Barcelona ===

The Buildroot community is organizing a meeting on Saturday November 3rd and Sunday November 4th, for Buildroot developers and contributors. This meeting will be a mixture of discussion and hacking session around the Buildroot project. This meeting takes place right before the Embedded Linux Conference Europe, in order to make it easy for participants to attend both events.

=== Event sponsored by Fluendo and Synopsys ===

The meeting room is sponsored by [http://www.fluendo.com Fluendo]. Thanks!

The Saturday dinner is sponsored by [http://www.synopsys.com Synopsys]. Thanks!

=== Report of the meeting ===

==== Action points ====
* Accept perl series.
* Accept qemu series (after further review).
* Remove compiler on target.
* Remove development files on target.
* Remove documentation on target.
* Explain in the documentation why the above was done.
* Put httpd daemons outside BUSYBOX_SHOW_OTHERS.
* Move BUSYBOX_SHOW_OTHERS conditions to ''depends on'' inside the package Config.in
* busybox: disable mount-nfs in the default config.
* simplify patch logic: if pkg-version directory exists, use that; otherwise, use pkg-*.patch.
* Automate selection of correct FP and other compiler options based on subarchitecture.

==== Details of the discussion ====

# Perl. The perl patch series (now at v11) looks ready to be integrated, but we have our doubts about cpanminus. The problems are: it has separate download infrastructure, which blocks some buildroot features (e.g. make source); it doesn't integrate with the legal-info. However, CPAN is pretty important if you really want to use perl. The decision was to accept cpanminus as well, but add some warnings that some things don't work.
# Qemu. Adding this opens the door for more people to do stuff that buildroot wasn't meant for in the first place (i.e. embedded). However, even in embedded qemu could be relevant. Things like the compiler on the target are much worse for doing crazy things. Giving new packages a chance is OK; we have to be much more careful with things that have global impact (like including development files on target). Conclusion: it's OK to accept qemu.
# Compiler on target. It leads to newbies using buildroot in an inappropriate way (i.e. compile on the target). Also it only works with the internal toolchain. And if we remove it, we can also remove "Development files on target", which simplifies some of the build infrastructure. Also, if you have a compiler on the target, then you can just as well use a distro. Conclusion: we remove it. Also a bunch of other packages can be removed (autotools, vala, ...)
# Documentation on target: if you need this, use a distro. So we remove it.
# We need to explain in the documentation why we removed this stuff.
# Available stuff: i.e. solve the problem of combination of ''select'' and ''depends''. Solving it in Kconfig itself seems to be difficult: there were some patches but the kconfig people didn't like it; Yann and Thomas looked at Kconfig and it looks difficult to modify. The AVAILABLE solution has two problems: it adds verbosity, and the recursive dependencies still should be written in the comments ("libfoo requires WCHAR in the toolchain"). The verbosity is not considered a big issue. For the comments: they currently don't work perfectly either. Removing the comments altogether is an option, but then it is difficult for users to find out why a certain package isn't available. Another possibility is to list the available packages in the documentation (automatically), and mention which toolchain dependencies they have. Wild idea: consider Config.in as a low-level language, and define our own higher-level language from which we generate Config.in. Alternatively, have a developer tool that verifies if everything is consistent (i.e. are the comments correct). One more option: add a big comment in the beginning of the packages list, which says that not all toolchain options are available so not all packages are visible. Converting the toolchain options from ''depends'' to ''select'' is not really an option, because changing toolchain options requires a make clean. We didn't reach a conclusion, we'll come back to it tomorrow.
# kconfig-frontend: Yann now has a repository for Kconfig, it would be nice to branch our Kconfig from that. The idea is to still copy it to our repository.
# BUSYBOX_SHOW_OTHERS: the only reason to have this is to avoid newcomers enabling things like tar etc. which are anyway already in busybox. But for the web servers, they are clearly different from the busybox web servers (and our default busybox config doesn't even enable a web server). Also bash is a typical one, because people write bashisms in their scripts. This discussion is somewhat related to the discussion how to handle packages that provide the same functionality. But for many packages, it's not even the same (httpd, bash, vim). But actually, we're trying to solve a non-existent problem here - except for the web servers. If we generate a list of packages in the documentation, we can add a remark to that that it's also available in busybox. Also move the condition inside the package Config.in instead of outside and make it a ''depends on'', so it is more visible.
# packages with multiple variants: python2/3, Qt4/5, gtk2/3, ... This is again similar to the expat/libxml2 issue. Do we support both python2 and python3? We need to support both versions in most cases. Question is if we want to force that only one of the two is selected, or do we support side-by-side installation. Conclusion: has to be looked at on a case-by-case basis. General philosophy: don't try to be too smart, so don't try to force selecting only one of the two if it doesn't make sense to have both. In cases where a package wants to ''select'' one of these things, convert the ''select'' into a ''depends'' with a comment.
# multiple packages providing the same functionality: lua/luajit, jpeg/jpegturbo, expat/libxml2. These cannot be installed side-by-side, and many packages select e.g. jpeg. OpenGL will have this issue as well. A relatively clean solution is to create virtual packages for these, where the user has a choice between the two. The normal config option would be hidden for these packages. This still adds complexity in some corner cases, e.g. some package that doesn't work in luajit, but that can probably be solved at the level of that package.
# Autobuild infrastructure. Thomas is working on scripts that parse the build result and put it in a database. One important missing feature at the moment is visibility of evolution over time (i.e. distinguish regressions from recurring problems). Even more important is just being able to see which packages are failing all the time, i.e. for each package how often it failed. Ideally, we would also want to see how often a package has been built successfully, but when is it successful? Does the entire build have to succeed or that package? Overall, however, the autobuild infrastructure is considered very useful - when something is wrong, it appears in the autobuild very quickly.
#* autobuild of the next branch: if only the master is autobuilt, we don't see a lot of problems until after the release. Delaying fixing bugs makes it more difficult to fix them. To support autobuild of the next branch, this should also be made visible in the database so we can distinguish master failures (more important) from next failures.
#* autobuild database is not suitable to track repeated builds of the same configuration. It needs to keep track of different builds of the same configurations. But the question is if this is really useful. We would like to check the existing defconfigs at every release, but it doesn't have to be tracked. So it can be done manually.
# AVR32. It is end of life as far as Atmel is concerned, but of course there are still products out there using it. It is not really blocking for buildroot. For packages which fail to build, we can just add a ''depends on !BR2_avr32''. But of course, until we have the AVAILABLE mechanism, carrying this kind of dependency can be painful.
# RPC support. Originally, the idea was to consider RPC support as a toolchain option, i.e. using ''depends''. However, libtirpc is really a library, comparable to gettext, so it could be enabled automatically with ''select''. Busybox is special, because we don't want to force RPC just because busybox is selected. Therefore busybox has a user-selectable option to enable RPC-based applets (mount-nfs). After discussion, this option was discarded - just remove mount-nfs from busybox (see below). Other packages will use libtirpc if it was selected (manually or automatically). It's still a question what will happen when dynamically linking against libtirpc when libc also has rpc.
# A bit related: we'll disable mount-nfs in the default busybox config; if user disables RPC and enables mount-nfs in busybox, he'll get a compilation error.
# Support for VCS branches in packages: custom packages are often in a VCS and while developing, you want to track a branch of that VCS. OVERRIDE_SRCDIR doesn't work very well because it means the user has to check everything out at the right version in the right location. An alternative would be to teach OVERRIDE_SRCDIR about VCSes, so that ''make foo-rebuild'' re-syncs with the VCS.
# There is a general feeling (mainly from Thomas) that buildroot isn't very convenient during development of a project where several people are working on several components. But no solution was found.
# FP stuff: we now have a single SOFT_FLOAT option, but actually there's a lot more variation: neon, vfpv3, softfp, .... To support this well, we can add a lot of extra config options to semi-automatically select the correct float options based on the subarchitecture. There is some cross-dependency with the external toolchains, but it's doable. There should still be an option to manually override the float options for exotic cases. ARM thumb adds another layer of complexity. Someone should take the lead on making this easier.

For tomorrow:
* Interaction between Buildroot configuration options to select architecture specifities (architecture variant, soft-float vs. hard-float, etc.) and the multilib variants available in external toolchains. Proposed by [[User:ThomasPetazzoni]].
* Status on the community organization. Has patchwork improved things? Are patches taken into account in a faster way? Proposed by [[User:ThomasPetazzoni]].
* What are the next "big" things for Buildroot? Proposed by [[User:ThomasPetazzoni]].
* Documentation refactoring? Proposed by Samuel Martin.
* The _AVAILABLE mechanism, and how to properly handle dependency on toolchain options (discuss the proposal made by Yann E. Morin). Proposed by [[User:ThomasPetazzoni]].
* Discuss (and, if approved, implement) the split between _LICENSE and _REDISTRIBUTE for legal-info. I think this won't take much more than 10 minutes chat + 10 minutes hack. Proposed by Luca Ceresoli.
* Make it possible to use a git repository as source for toolchain. This doesn't work well today. Proposed by Mischa Jonker
* Make it possible to do a 'target-clean', as a replacement of uninstall. Will this even work at all? Proposed by Arnout Vandecappelle
* Does it make sense to port the toolchains to generic-package infrastructure? Asked by Arnout Vandecappelle
* How to provide licensing info for packages that have more than one license. The main use cases are: a) different parts of the source code have different licenses, b) a file (or the whole project) is distributed under two or more licenses or c) a mix of the two. See the recent thoughts about this issue by Yann Morin: http://lists.busybox.net/pipermail/buildroot/2012-October/060475.html
* Support for board stuff outside the buildroot tree. Proposed by Arnout Vandecappelle

=== Participants ===

# [[User:Arnout_Vandecappelle|Arnout Vandecappelle]], confirmed. Arriving on Fri Nov 2 20:35 at BCN airport. Leaving Wed Nov. 8 21:15 at BCN. Staying at [http://www.hcchotels.es/en/hotel/12/hcc-lugano HCC Lugano]
# [[User:ThomasPetazzoni|Thomas Petazzoni]], confirmed. Arriving on November, 3rd at BCN airport 9:25 AM. Leaving on November 8th from BCN airport at 3:45 PM. Staying at Hotel Fira Palace.
# Maxime Ripard, confirmed. Arriving on November, 1st at BCN airport. Leaving on November 8th from BCP airport at 3:45 PM. Staying at Hotel Fira Palace.
# [[User:PeterKorsgaard|Peter Korsgaard]], confirmed, Arriving on Fri Nov 2 21:55 at BCN airport. Leaving Sun Nov 11 17:15 at BCN. Staying at [http://www.hcchotels.es/en/hotel/12/hcc-lugano HCC Lugano]
# Luca Ceresoli, confirmed. Arriving on November 3rd at BCN airport 10:05 AM. Leaving on November 7th from BCN airport 19:15 PM. Staying at Hotel Fira Palace. Will arrive around 11:30 AM for the meeting.
# Samuel Martin, confirmed. Arriving on November, 3rd at Barcelona-Franca Train Station 8:05 AM. Leaving on November 10th from Barcelona-Franca Train Station at 8:43 PM.
# Simon Dawson, confirmed. Arriving on November 2nd in the evening. Leaving on November 8th early morning.
# Mischa Jonker, confirmed. From Synopsys.com. Not contributing yet to Buildroot, but interested in using Buildroot for a brand new CPU architecture. Arriving Friday Nov 2nd BCN 21:10 CET, staying at Catalonia Barcelona Plaza (Plaza Espanya), leaving Thursday Nov 8 at 18:40 CET.
# Maxime Hadjinlian.

=== Registration ===

Please contact Thomas Petazzoni (thomas.petazzoni@free-electrons.com) if you would like to attend.

Attending the event is free, but registration is required.

=== Program ===

* Saturday, 10 AM: beginning of the meeting. The first person to arrive can go directly to the front desk and ask for MARIBEL SOCIAS or anyone in the Reservations Department, and then ask for the meeting room booked for Thomas Petazzoni. [[User:ThomasPetazzoni|Thomas Petazzoni]] will only arrive at 10:30-11 AM.
* Saturday, 7 PM: end of the meeting
* Saturday, 8:30 PM: dinner sponsored by Synopsys
* Sunday, 10 AM: beginning of the meeting
* Sunday, 7 PM: end of the meeting

=== Location ===

The event will take place at [http://www.hotelgrumsbarcelona.com/ Hotel Grumps], in downtown Barcelona. See [http://goo.gl/maps/htYi9 this map] for the location of the hotel, and [http://goo.gl/maps/GdiaM this map] for walking directions between the Fira Palace hotel (location of the ELCE conference) and Hotel Grums.

=== List of topics to discuss ===

* Interaction between Buildroot configuration options to select architecture specifities (architecture variant, soft-float vs. hard-float, etc.) and the multilib variants available in external toolchains. Proposed by [[User:ThomasPetazzoni]].
* Status on the community organization. Has patchwork improved things? Are patches taken into account in a faster way? Proposed by [[User:ThomasPetazzoni]].
* What are the next "big" things for Buildroot? Proposed by [[User:ThomasPetazzoni]].
* Documentation refactoring? Proposed by Samuel Martin.
* Autobuilder tests: needed improvements, future work. Proposed by [[User:ThomasPetazzoni]].
* The _AVAILABLE mechanism, and how to properly handle dependency on toolchain options (discuss the proposal made by Yann E. Morin). Proposed by [[User:ThomasPetazzoni]].
* Discuss (and, if approved, implement) the split between _LICENSE and _REDISTRIBUTE for legal-info. I think this won't take much more than 10 minutes chat + 10 minutes hack. Proposed by Luca Ceresoli.
* Make it possible to use a git repository as source for toolchain. This doesn't work well today. Proposed by Mischa Jonker
* Make it possible to do a 'target-clean', as a replacement of uninstall. Will this even work at all? Proposed by Arnout Vandecappelle
* Does it make sense to port the toolchains to generic-package infrastructure? Asked by Arnout Vandecappelle
* How to provide licensing info for packages that have more than one license. The main use cases are: a) different parts of the source code have different licenses, b) a file (or the whole project) is distributed under two or more licenses or c) a mix of the two. See the recent thoughts about this issue by Yann Morin: http://lists.busybox.net/pipermail/buildroot/2012-October/060475.html
* Support for board stuff outside the buildroot tree. Proposed by Arnout Vandecappelle
* Should we remove the ability to build a toolchain on the target? And also things like development files on target, documentation on target, etc. Proposed by [[User:ThomasPetazzoni]].

=== List of topics to hack on ===

* Reduce the back log of bugs. Proposed by [[User:ThomasPetazzoni]].
* Reduce the back log of patches. Proposed by [[User:ThomasPetazzoni]].
* Work on noMMU platform support (Blackfin, Coldfire). Getting Coldfire Qemu working, adding correct support for FLAT binaries. Proposed by [[User:ThomasPetazzoni]].
* Package upgrades: package python3, gtk3 and latest versions of glib and al. Proposed by [[User:ThomasPetazzoni]].
* Triage autobuilder failures and fix them. Proposed by Arnout Vandecappelle
* Improve the documentation. Proposed by Arnout Vandecappelle
* Work on relocatable toolchain. Proposed by Arnout Vandecappelle
* Add some infra for setup.py/qmake based packages. Proposed by Samuel Martin
* Add some infra for make based packages (mainly using the same pattern all over). Proposed by Arnout Vandecappelle
* Add some infra for Kconfig based packages (linux, barebox, busybox, uclibc, ct-ng, at91bootstrap3). Proposed by Arnout Vandecappelle
* Make top-level make -j possible. Proposed by Arnout Vandecappelle

Buildroot:DeveloperDaysELCE2012

2012-11-03T15:42:16Z

Arnout Vandecappelle:

== Buildroot Developers Meeting, 3-4 November 2012, Barcelona Spain ==

=== What is Buildroot ? ===

[http://buildroot.org 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.

=== Meeting in Barcelona ===

The Buildroot community is organizing a meeting on Saturday November 3rd and Sunday November 4th, for Buildroot developers and contributors. This meeting will be a mixture of discussion and hacking session around the Buildroot project. This meeting takes place right before the Embedded Linux Conference Europe, in order to make it easy for participants to attend both events.

=== Event sponsored by Fluendo and Synopsys ===

The meeting room is sponsored by [http://www.fluendo.com Fluendo]. Thanks!

The Saturday dinner is sponsored by [http://www.synopsys.com Synopsys]. Thanks!

=== Report of the meeting ===

==== Action points ====
* Accept perl series.
* Accept qemu series (after further review).
* Remove compiler on target.
* Remove development files on target.
* Remove documentation on target.
* Explain in the documentation why the above was done.
* Put httpd daemons outside BUSYBOX_SHOW_OTHERS.
* Move BUSYBOX_SHOW_OTHERS conditions to ''depends on'' inside the package Config.in
* busybox: disable mount-nfs in the default config.
* simplify patch logic: if pkg-version directory exists, use that; otherwise, use pkg-*.patch.

==== Details of the discussion ====

# Perl. The perl patch series (now at v11) looks ready to be integrated, but we have our doubts about cpanminus. The problems are: it has separate download infrastructure, which blocks some buildroot features (e.g. make source); it doesn't integrate with the legal-info. However, CPAN is pretty important if you really want to use perl. The decision was to accept cpanminus as well, but add some warnings that some things don't work.
# Qemu. Adding this opens the door for more people to do stuff that buildroot wasn't meant for in the first place (i.e. embedded). However, even in embedded qemu could be relevant. Things like the compiler on the target are much worse for doing crazy things. Giving new packages a chance is OK; we have to be much more careful with things that have global impact (like including development files on target). Conclusion: it's OK to accept qemu.
# Compiler on target. It leads to newbies using buildroot in an inappropriate way (i.e. compile on the target). Also it only works with the internal toolchain. And if we remove it, we can also remove "Development files on target", which simplifies some of the build infrastructure. Also, if you have a compiler on the target, then you can just as well use a distro. Conclusion: we remove it. Also a bunch of other packages can be removed (autotools, vala, ...)
# Documentation on target: if you need this, use a distro. So we remove it.
# We need to explain in the documentation why we removed this stuff.
# Available stuff: i.e. solve the problem of combination of ''select'' and ''depends''. Solving it in Kconfig itself seems to be difficult: there were some patches but the kconfig people didn't like it; Yann and Thomas looked at Kconfig and it looks difficult to modify. The AVAILABLE solution has two problems: it adds verbosity, and the recursive dependencies still should be written in the comments ("libfoo requires WCHAR in the toolchain"). The verbosity is not considered a big issue. For the comments: they currently don't work perfectly either. Removing the comments altogether is an option, but then it is difficult for users to find out why a certain package isn't available. Another possibility is to list the available packages in the documentation (automatically), and mention which toolchain dependencies they have. Wild idea: consider Config.in as a low-level language, and define our own higher-level language from which we generate Config.in. Alternatively, have a developer tool that verifies if everything is consistent (i.e. are the comments correct). One more option: add a big comment in the beginning of the packages list, which says that not all toolchain options are available so not all packages are visible. Converting the toolchain options from ''depends'' to ''select'' is not really an option, because changing toolchain options requires a make clean. We didn't reach a conclusion, we'll come back to it tomorrow.
# kconfig-frontend: Yann now has a repository for Kconfig, it would be nice to branch our Kconfig from that. The idea is to still copy it to our repository.
# BUSYBOX_SHOW_OTHERS: the only reason to have this is to avoid newcomers enabling things like tar etc. which are anyway already in busybox. But for the web servers, they are clearly different from the busybox web servers (and our default busybox config doesn't even enable a web server). Also bash is a typical one, because people write bashisms in their scripts. This discussion is somewhat related to the discussion how to handle packages that provide the same functionality. But for many packages, it's not even the same (httpd, bash, vim). But actually, we're trying to solve a non-existent problem here - except for the web servers. If we generate a list of packages in the documentation, we can add a remark to that that it's also available in busybox. Also move the condition inside the package Config.in instead of outside and make it a ''depends on'', so it is more visible.
# packages with multiple variants: python2/3, Qt4/5, gtk2/3, ... This is again similar to the expat/libxml2 issue. Do we support both python2 and python3? We need to support both versions in most cases. Question is if we want to force that only one of the two is selected, or do we support side-by-side installation. Conclusion: has to be looked at on a case-by-case basis. General philosophy: don't try to be too smart, so don't try to force selecting only one of the two if it doesn't make sense to have both. In cases where a package wants to ''select'' one of these things, convert the ''select'' into a ''depends'' with a comment.
# multiple packages providing the same functionality: lua/luajit, jpeg/jpegturbo, expat/libxml2. These cannot be installed side-by-side, and many packages select e.g. jpeg. OpenGL will have this issue as well. A relatively clean solution is to create virtual packages for these, where the user has a choice between the two. The normal config option would be hidden for these packages. This still adds complexity in some corner cases, e.g. some package that doesn't work in luajit, but that can probably be solved at the level of that package.
# Autobuild infrastructure. Thomas is working on scripts that parse the build result and put it in a database. One important missing feature at the moment is visibility of evolution over time (i.e. distinguish regressions from recurring problems). Even more important is just being able to see which packages are failing all the time, i.e. for each package how often it failed. Ideally, we would also want to see how often a package has been built successfully, but when is it successful? Does the entire build have to succeed or that package? Overall, however, the autobuild infrastructure is considered very useful - when something is wrong, it appears in the autobuild very quickly.
#* autobuild of the next branch: if only the master is autobuilt, we don't see a lot of problems until after the release. Delaying fixing bugs makes it more difficult to fix them. To support autobuild of the next branch, this should also be made visible in the database so we can distinguish master failures (more important) from next failures.
#* autobuild database is not suitable to track repeated builds of the same configuration. It needs to keep track of different builds of the same configurations. But the question is if this is really useful. We would like to check the existing defconfigs at every release, but it doesn't have to be tracked. So it can be done manually.
# AVR32. It is end of life as far as Atmel is concerned, but of course there are still products out there using it. It is not really blocking for buildroot. For packages which fail to build, we can just add a ''depends on !BR2_avr32''. But of course, until we have the AVAILABLE mechanism, carrying this kind of dependency can be painful.
# RPC support. Originally, the idea was to consider RPC support as a toolchain option, i.e. using ''depends''. However, libtirpc is really a library, comparable to gettext, so it could be enabled automatically with ''select''. Busybox is special, because we don't want to force RPC just because busybox is selected. Therefore busybox has a user-selectable option to enable RPC-based applets (mount-nfs). After discussion, this option was discarded - just remove mount-nfs from busybox (see below). Other packages will use libtirpc if it was selected (manually or automatically). It's still a question what will happen when dynamically linking against libtirpc when libc also has rpc.
# A bit related: we'll disable mount-nfs in the default busybox config; if user disables RPC and enables mount-nfs in busybox, he'll get a compilation error.
# Support for VCS branches in packages: custom packages are often in a VCS and while developing, you want to track a branch of that VCS. OVERRIDE_SRCDIR doesn't work very well because it means the user has to check everything out at the right version in the right location. An alternative would be to teach OVERRIDE_SRCDIR about VCSes, so that ''make foo-rebuild'' re-syncs with the VCS.
# There is a general feeling (mainly from Thomas) that buildroot isn't very convenient during development of a project where several people are working on several components. But no solution was found.
# FP stuff: we now have a single SOFT_FLOAT option, but actually there's a lot more variation: neon, vfpv3, softfp, .... To support this well, we can add a lot of extra config options to semi-automatically select the correct float options based on the subarchitecture. There is some cross-dependency with the external toolchains, but it's doable. There should still be an option to manually override the float options for exotic cases. ARM thumb adds another layer of complexity.

For tomorrow:
* Interaction between Buildroot configuration options to select architecture specifities (architecture variant, soft-float vs. hard-float, etc.) and the multilib variants available in external toolchains. Proposed by [[User:ThomasPetazzoni]].
* Status on the community organization. Has patchwork improved things? Are patches taken into account in a faster way? Proposed by [[User:ThomasPetazzoni]].
* What are the next "big" things for Buildroot? Proposed by [[User:ThomasPetazzoni]].
* Documentation refactoring? Proposed by Samuel Martin.
* The _AVAILABLE mechanism, and how to properly handle dependency on toolchain options (discuss the proposal made by Yann E. Morin). Proposed by [[User:ThomasPetazzoni]].
* Discuss (and, if approved, implement) the split between _LICENSE and _REDISTRIBUTE for legal-info. I think this won't take much more than 10 minutes chat + 10 minutes hack. Proposed by Luca Ceresoli.
* Make it possible to use a git repository as source for toolchain. This doesn't work well today. Proposed by Mischa Jonker
* Make it possible to do a 'target-clean', as a replacement of uninstall. Will this even work at all? Proposed by Arnout Vandecappelle
* Does it make sense to port the toolchains to generic-package infrastructure? Asked by Arnout Vandecappelle
* How to provide licensing info for packages that have more than one license. The main use cases are: a) different parts of the source code have different licenses, b) a file (or the whole project) is distributed under two or more licenses or c) a mix of the two. See the recent thoughts about this issue by Yann Morin: http://lists.busybox.net/pipermail/buildroot/2012-October/060475.html
* Support for board stuff outside the buildroot tree. Proposed by Arnout Vandecappelle

=== Participants ===

# [[User:Arnout_Vandecappelle|Arnout Vandecappelle]], confirmed. Arriving on Fri Nov 2 20:35 at BCN airport. Leaving Wed Nov. 8 21:15 at BCN. Staying at [http://www.hcchotels.es/en/hotel/12/hcc-lugano HCC Lugano]
# [[User:ThomasPetazzoni|Thomas Petazzoni]], confirmed. Arriving on November, 3rd at BCN airport 9:25 AM. Leaving on November 8th from BCN airport at 3:45 PM. Staying at Hotel Fira Palace.
# Maxime Ripard, confirmed. Arriving on November, 1st at BCN airport. Leaving on November 8th from BCP airport at 3:45 PM. Staying at Hotel Fira Palace.
# [[User:PeterKorsgaard|Peter Korsgaard]], confirmed, Arriving on Fri Nov 2 21:55 at BCN airport. Leaving Sun Nov 11 17:15 at BCN. Staying at [http://www.hcchotels.es/en/hotel/12/hcc-lugano HCC Lugano]
# Luca Ceresoli, confirmed. Arriving on November 3rd at BCN airport 10:05 AM. Leaving on November 7th from BCN airport 19:15 PM. Staying at Hotel Fira Palace. Will arrive around 11:30 AM for the meeting.
# Samuel Martin, confirmed. Arriving on November, 3rd at Barcelona-Franca Train Station 8:05 AM. Leaving on November 10th from Barcelona-Franca Train Station at 8:43 PM.
# Simon Dawson, confirmed. Arriving on November 2nd in the evening. Leaving on November 8th early morning.
# Mischa Jonker, confirmed. From Synopsys.com. Not contributing yet to Buildroot, but interested in using Buildroot for a brand new CPU architecture. Arriving Friday Nov 2nd BCN 21:10 CET, staying at Catalonia Barcelona Plaza (Plaza Espanya), leaving Thursday Nov 8 at 18:40 CET.
# Maxime Hadjinlian.

=== Registration ===

Please contact Thomas Petazzoni (thomas.petazzoni@free-electrons.com) if you would like to attend.

Attending the event is free, but registration is required.

=== Program ===

* Saturday, 10 AM: beginning of the meeting. The first person to arrive can go directly to the front desk and ask for MARIBEL SOCIAS or anyone in the Reservations Department, and then ask for the meeting room booked for Thomas Petazzoni. [[User:ThomasPetazzoni|Thomas Petazzoni]] will only arrive at 10:30-11 AM.
* Saturday, 7 PM: end of the meeting
* Saturday, 8:30 PM: dinner sponsored by Synopsys
* Sunday, 10 AM: beginning of the meeting
* Sunday, 7 PM: end of the meeting

=== Location ===

The event will take place at [http://www.hotelgrumsbarcelona.com/ Hotel Grumps], in downtown Barcelona. See [http://goo.gl/maps/htYi9 this map] for the location of the hotel, and [http://goo.gl/maps/GdiaM this map] for walking directions between the Fira Palace hotel (location of the ELCE conference) and Hotel Grums.

=== List of topics to discuss ===

* Interaction between Buildroot configuration options to select architecture specifities (architecture variant, soft-float vs. hard-float, etc.) and the multilib variants available in external toolchains. Proposed by [[User:ThomasPetazzoni]].
* Status on the community organization. Has patchwork improved things? Are patches taken into account in a faster way? Proposed by [[User:ThomasPetazzoni]].
* What are the next "big" things for Buildroot? Proposed by [[User:ThomasPetazzoni]].
* Documentation refactoring? Proposed by Samuel Martin.
* Autobuilder tests: needed improvements, future work. Proposed by [[User:ThomasPetazzoni]].
* The _AVAILABLE mechanism, and how to properly handle dependency on toolchain options (discuss the proposal made by Yann E. Morin). Proposed by [[User:ThomasPetazzoni]].
* Discuss (and, if approved, implement) the split between _LICENSE and _REDISTRIBUTE for legal-info. I think this won't take much more than 10 minutes chat + 10 minutes hack. Proposed by Luca Ceresoli.
* Make it possible to use a git repository as source for toolchain. This doesn't work well today. Proposed by Mischa Jonker
* Make it possible to do a 'target-clean', as a replacement of uninstall. Will this even work at all? Proposed by Arnout Vandecappelle
* Does it make sense to port the toolchains to generic-package infrastructure? Asked by Arnout Vandecappelle
* How to provide licensing info for packages that have more than one license. The main use cases are: a) different parts of the source code have different licenses, b) a file (or the whole project) is distributed under two or more licenses or c) a mix of the two. See the recent thoughts about this issue by Yann Morin: http://lists.busybox.net/pipermail/buildroot/2012-October/060475.html
* Support for board stuff outside the buildroot tree. Proposed by Arnout Vandecappelle
* Should we remove the ability to build a toolchain on the target? And also things like development files on target, documentation on target, etc. Proposed by [[User:ThomasPetazzoni]].

=== List of topics to hack on ===

* Reduce the back log of bugs. Proposed by [[User:ThomasPetazzoni]].
* Reduce the back log of patches. Proposed by [[User:ThomasPetazzoni]].
* Work on noMMU platform support (Blackfin, Coldfire). Getting Coldfire Qemu working, adding correct support for FLAT binaries. Proposed by [[User:ThomasPetazzoni]].
* Package upgrades: package python3, gtk3 and latest versions of glib and al. Proposed by [[User:ThomasPetazzoni]].
* Triage autobuilder failures and fix them. Proposed by Arnout Vandecappelle
* Improve the documentation. Proposed by Arnout Vandecappelle
* Work on relocatable toolchain. Proposed by Arnout Vandecappelle
* Add some infra for setup.py/qmake based packages. Proposed by Samuel Martin
* Add some infra for make based packages (mainly using the same pattern all over). Proposed by Arnout Vandecappelle
* Add some infra for Kconfig based packages (linux, barebox, busybox, uclibc, ct-ng, at91bootstrap3). Proposed by Arnout Vandecappelle
* Make top-level make -j possible. Proposed by Arnout Vandecappelle

Buildroot:DeveloperDaysELCE2012

2012-11-03T15:24:26Z

Arnout Vandecappelle: /* Report of the meeting */

== Buildroot Developers Meeting, 3-4 November 2012, Barcelona Spain ==

=== What is Buildroot ? ===

[http://buildroot.org 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.

=== Meeting in Barcelona ===

The Buildroot community is organizing a meeting on Saturday November 3rd and Sunday November 4th, for Buildroot developers and contributors. This meeting will be a mixture of discussion and hacking session around the Buildroot project. This meeting takes place right before the Embedded Linux Conference Europe, in order to make it easy for participants to attend both events.

=== Event sponsored by Fluendo and Synopsys ===

The meeting room is sponsored by [http://www.fluendo.com Fluendo]. Thanks!

The Saturday dinner is sponsored by [http://www.synopsys.com Synopsys]. Thanks!

=== Report of the meeting ===

==== Action points ====
* Accept perl series.
* Accept qemu series (after further review).
* Remove compiler on target.
* Remove development files on target.
* Remove documentation on target.
* Explain in the documentation why the above was done.
* Put httpd daemons outside BUSYBOX_SHOW_OTHERS.
* Move BUSYBOX_SHOW_OTHERS conditions to ''depends on'' inside the package Config.in
* busybox: disable mount-nfs in the default config.
* simplify patch logic: if pkg-version directory exists, use that; otherwise, use pkg-*.patch.

==== Details of the discussion ====

# Perl. The perl patch series (now at v11) looks ready to be integrated, but we have our doubts about cpanminus. The problems are: it has separate download infrastructure, which blocks some buildroot features (e.g. make source); it doesn't integrate with the legal-info. However, CPAN is pretty important if you really want to use perl. The decision was to accept cpanminus as well, but add some warnings that some things don't work.
# Qemu. Adding this opens the door for more people to do stuff that buildroot wasn't meant for in the first place (i.e. embedded). However, even in embedded qemu could be relevant. Things like the compiler on the target are much worse for doing crazy things. Giving new packages a chance is OK; we have to be much more careful with things that have global impact (like including development files on target). Conclusion: it's OK to accept qemu.
# Compiler on target. It leads to newbies using buildroot in an inappropriate way (i.e. compile on the target). Also it only works with the internal toolchain. And if we remove it, we can also remove "Development files on target", which simplifies some of the build infrastructure. Also, if you have a compiler on the target, then you can just as well use a distro. Conclusion: we remove it. Also a bunch of other packages can be removed (autotools, vala, ...)
# Documentation on target: if you need this, use a distro. So we remove it.
# We need to explain in the documentation why we removed this stuff.
# Available stuff: i.e. solve the problem of combination of ''select'' and ''depends''. Solving it in Kconfig itself seems to be difficult: there were some patches but the kconfig people didn't like it; Yann and Thomas looked at Kconfig and it looks difficult to modify. The AVAILABLE solution has two problems: it adds verbosity, and the recursive dependencies still should be written in the comments ("libfoo requires WCHAR in the toolchain"). The verbosity is not considered a big issue. For the comments: they currently don't work perfectly either. Removing the comments altogether is an option, but then it is difficult for users to find out why a certain package isn't available. Another possibility is to list the available packages in the documentation (automatically), and mention which toolchain dependencies they have. Wild idea: consider Config.in as a low-level language, and define our own higher-level language from which we generate Config.in. Alternatively, have a developer tool that verifies if everything is consistent (i.e. are the comments correct). One more option: add a big comment in the beginning of the packages list, which says that not all toolchain options are available so not all packages are visible. Converting the toolchain options from ''depends'' to ''select'' is not really an option, because changing toolchain options requires a make clean. We didn't reach a conclusion, we'll come back to it tomorrow.
# kconfig-frontend: Yann now has a repository for Kconfig, it would be nice to branch our Kconfig from that. The idea is to still copy it to our repository.
# BUSYBOX_SHOW_OTHERS: the only reason to have this is to avoid newcomers enabling things like tar etc. which are anyway already in busybox. But for the web servers, they are clearly different from the busybox web servers (and our default busybox config doesn't even enable a web server). Also bash is a typical one, because people write bashisms in their scripts. This discussion is somewhat related to the discussion how to handle packages that provide the same functionality. But for many packages, it's not even the same (httpd, bash, vim). But actually, we're trying to solve a non-existent problem here - except for the web servers. If we generate a list of packages in the documentation, we can add a remark to that that it's also available in busybox. Also move the condition inside the package Config.in instead of outside and make it a ''depends on'', so it is more visible.
# packages with multiple variants: python2/3, Qt4/5, gtk2/3, ... This is again similar to the expat/libxml2 issue. Do we support both python2 and python3? We need to support both versions in most cases. Question is if we want to force that only one of the two is selected, or do we support side-by-side installation. Conclusion: has to be looked at on a case-by-case basis. General philosophy: don't try to be too smart, so don't try to force selecting only one of the two if it doesn't make sense to have both. In cases where a package wants to ''select'' one of these things, convert the ''select'' into a ''depends'' with a comment.
# multiple packages providing the same functionality: lua/luajit, jpeg/jpegturbo, expat/libxml2. These cannot be installed side-by-side, and many packages select e.g. jpeg. OpenGL will have this issue as well. A relatively clean solution is to create virtual packages for these, where the user has a choice between the two. The normal config option would be hidden for these packages. This still adds complexity in some corner cases, e.g. some package that doesn't work in luajit, but that can probably be solved at the level of that package.
# Autobuild infrastructure. Thomas is working on scripts that parse the build result and put it in a database. One important missing feature at the moment is visibility of evolution over time (i.e. distinguish regressions from recurring problems). Even more important is just being able to see which packages are failing all the time, i.e. for each package how often it failed. Ideally, we would also want to see how often a package has been built successfully, but when is it successful? Does the entire build have to succeed or that package? Overall, however, the autobuild infrastructure is considered very useful - when something is wrong, it appears in the autobuild very quickly.
#* autobuild of the next branch: if only the master is autobuilt, we don't see a lot of problems until after the release. Delaying fixing bugs makes it more difficult to fix them. To support autobuild of the next branch, this should also be made visible in the database so we can distinguish master failures (more important) from next failures.
#* autobuild database is not suitable to track repeated builds of the same configuration. It needs to keep track of different builds of the same configurations. But the question is if this is really useful. We would like to check the existing defconfigs at every release, but it doesn't have to be tracked. So it can be done manually.
# AVR32. It is end of life as far as Atmel is concerned, but of course there are still products out there using it. It is not really blocking for buildroot. For packages which fail to build, we can just add a ''depends on !BR2_avr32''. But of course, until we have the AVAILABLE mechanism, carrying this kind of dependency can be painful.
# RPC support. Originally, the idea was to consider RPC support as a toolchain option, i.e. using ''depends''. However, libtirpc is really a library, comparable to gettext, so it could be enabled automatically with ''select''. Busybox is special, because we don't want to force RPC just because busybox is selected. Therefore busybox has a user-selectable option to enable RPC-based applets (mount-nfs). After discussion, this option was discarded - just remove mount-nfs from busybox (see below). Other packages will use libtirpc if it was selected (manually or automatically). It's still a question what will happen when dynamically linking against libtirpc when libc also has rpc.
# A bit related: we'll disable mount-nfs in the default busybox config; if user disables RPC and enables mount-nfs in busybox, he'll get a compilation error.
# Support for VCS branches in packages: custom packages are often in a VCS and while developing, you want to track a branch of that VCS. OVERRIDE_SRCDIR doesn't work very well because it means the user has to check everything out at the right version in the right location. An alternative would be to teach OVERRIDE_SRCDIR about VCSes, so that ''make foo-rebuild'' re-syncs with the VCS.
# There is a general feeling (mainly from Thomas) that buildroot isn't very convenient during development of a project where several people are working on several components. But no solution was found.

For tomorrow:
* Interaction between Buildroot configuration options to select architecture specifities (architecture variant, soft-float vs. hard-float, etc.) and the multilib variants available in external toolchains. Proposed by [[User:ThomasPetazzoni]].
* Status on the community organization. Has patchwork improved things? Are patches taken into account in a faster way? Proposed by [[User:ThomasPetazzoni]].
* What are the next "big" things for Buildroot? Proposed by [[User:ThomasPetazzoni]].
* Documentation refactoring? Proposed by Samuel Martin.
* The _AVAILABLE mechanism, and how to properly handle dependency on toolchain options (discuss the proposal made by Yann E. Morin). Proposed by [[User:ThomasPetazzoni]].
* Discuss (and, if approved, implement) the split between _LICENSE and _REDISTRIBUTE for legal-info. I think this won't take much more than 10 minutes chat + 10 minutes hack. Proposed by Luca Ceresoli.
* Make it possible to use a git repository as source for toolchain. This doesn't work well today. Proposed by Mischa Jonker
* Make it possible to do a 'target-clean', as a replacement of uninstall. Will this even work at all? Proposed by Arnout Vandecappelle
* Does it make sense to port the toolchains to generic-package infrastructure? Asked by Arnout Vandecappelle
* How to provide licensing info for packages that have more than one license. The main use cases are: a) different parts of the source code have different licenses, b) a file (or the whole project) is distributed under two or more licenses or c) a mix of the two. See the recent thoughts about this issue by Yann Morin: http://lists.busybox.net/pipermail/buildroot/2012-October/060475.html
* Support for board stuff outside the buildroot tree. Proposed by Arnout Vandecappelle

=== Participants ===

# [[User:Arnout_Vandecappelle|Arnout Vandecappelle]], confirmed. Arriving on Fri Nov 2 20:35 at BCN airport. Leaving Wed Nov. 8 21:15 at BCN. Staying at [http://www.hcchotels.es/en/hotel/12/hcc-lugano HCC Lugano]
# [[User:ThomasPetazzoni|Thomas Petazzoni]], confirmed. Arriving on November, 3rd at BCN airport 9:25 AM. Leaving on November 8th from BCN airport at 3:45 PM. Staying at Hotel Fira Palace.
# Maxime Ripard, confirmed. Arriving on November, 1st at BCN airport. Leaving on November 8th from BCP airport at 3:45 PM. Staying at Hotel Fira Palace.
# [[User:PeterKorsgaard|Peter Korsgaard]], confirmed, Arriving on Fri Nov 2 21:55 at BCN airport. Leaving Sun Nov 11 17:15 at BCN. Staying at [http://www.hcchotels.es/en/hotel/12/hcc-lugano HCC Lugano]
# Luca Ceresoli, confirmed. Arriving on November 3rd at BCN airport 10:05 AM. Leaving on November 7th from BCN airport 19:15 PM. Staying at Hotel Fira Palace. Will arrive around 11:30 AM for the meeting.
# Samuel Martin, confirmed. Arriving on November, 3rd at Barcelona-Franca Train Station 8:05 AM. Leaving on November 10th from Barcelona-Franca Train Station at 8:43 PM.
# Simon Dawson, confirmed. Arriving on November 2nd in the evening. Leaving on November 8th early morning.
# Mischa Jonker, confirmed. From Synopsys.com. Not contributing yet to Buildroot, but interested in using Buildroot for a brand new CPU architecture. Arriving Friday Nov 2nd BCN 21:10 CET, staying at Catalonia Barcelona Plaza (Plaza Espanya), leaving Thursday Nov 8 at 18:40 CET.
# Maxime Hadjinlian.

=== Registration ===

Please contact Thomas Petazzoni (thomas.petazzoni@free-electrons.com) if you would like to attend.

Attending the event is free, but registration is required.

=== Program ===

* Saturday, 10 AM: beginning of the meeting. The first person to arrive can go directly to the front desk and ask for MARIBEL SOCIAS or anyone in the Reservations Department, and then ask for the meeting room booked for Thomas Petazzoni. [[User:ThomasPetazzoni|Thomas Petazzoni]] will only arrive at 10:30-11 AM.
* Saturday, 7 PM: end of the meeting
* Saturday, 8:30 PM: dinner sponsored by Synopsys
* Sunday, 10 AM: beginning of the meeting
* Sunday, 7 PM: end of the meeting

=== Location ===

The event will take place at [http://www.hotelgrumsbarcelona.com/ Hotel Grumps], in downtown Barcelona. See [http://goo.gl/maps/htYi9 this map] for the location of the hotel, and [http://goo.gl/maps/GdiaM this map] for walking directions between the Fira Palace hotel (location of the ELCE conference) and Hotel Grums.

=== List of topics to discuss ===

* Interaction between Buildroot configuration options to select architecture specifities (architecture variant, soft-float vs. hard-float, etc.) and the multilib variants available in external toolchains. Proposed by [[User:ThomasPetazzoni]].
* Status on the community organization. Has patchwork improved things? Are patches taken into account in a faster way? Proposed by [[User:ThomasPetazzoni]].
* What are the next "big" things for Buildroot? Proposed by [[User:ThomasPetazzoni]].
* Documentation refactoring? Proposed by Samuel Martin.
* Autobuilder tests: needed improvements, future work. Proposed by [[User:ThomasPetazzoni]].
* The _AVAILABLE mechanism, and how to properly handle dependency on toolchain options (discuss the proposal made by Yann E. Morin). Proposed by [[User:ThomasPetazzoni]].
* Discuss (and, if approved, implement) the split between _LICENSE and _REDISTRIBUTE for legal-info. I think this won't take much more than 10 minutes chat + 10 minutes hack. Proposed by Luca Ceresoli.
* Make it possible to use a git repository as source for toolchain. This doesn't work well today. Proposed by Mischa Jonker
* Make it possible to do a 'target-clean', as a replacement of uninstall. Will this even work at all? Proposed by Arnout Vandecappelle
* Does it make sense to port the toolchains to generic-package infrastructure? Asked by Arnout Vandecappelle
* How to provide licensing info for packages that have more than one license. The main use cases are: a) different parts of the source code have different licenses, b) a file (or the whole project) is distributed under two or more licenses or c) a mix of the two. See the recent thoughts about this issue by Yann Morin: http://lists.busybox.net/pipermail/buildroot/2012-October/060475.html
* Support for board stuff outside the buildroot tree. Proposed by Arnout Vandecappelle
* Should we remove the ability to build a toolchain on the target? And also things like development files on target, documentation on target, etc. Proposed by [[User:ThomasPetazzoni]].

=== List of topics to hack on ===

* Reduce the back log of bugs. Proposed by [[User:ThomasPetazzoni]].
* Reduce the back log of patches. Proposed by [[User:ThomasPetazzoni]].
* Work on noMMU platform support (Blackfin, Coldfire). Getting Coldfire Qemu working, adding correct support for FLAT binaries. Proposed by [[User:ThomasPetazzoni]].
* Package upgrades: package python3, gtk3 and latest versions of glib and al. Proposed by [[User:ThomasPetazzoni]].
* Triage autobuilder failures and fix them. Proposed by Arnout Vandecappelle
* Improve the documentation. Proposed by Arnout Vandecappelle
* Work on relocatable toolchain. Proposed by Arnout Vandecappelle
* Add some infra for setup.py/qmake based packages. Proposed by Samuel Martin
* Add some infra for make based packages (mainly using the same pattern all over). Proposed by Arnout Vandecappelle
* Add some infra for Kconfig based packages (linux, barebox, busybox, uclibc, ct-ng, at91bootstrap3). Proposed by Arnout Vandecappelle
* Make top-level make -j possible. Proposed by Arnout Vandecappelle

Buildroot:DeveloperDaysELCE2012

2012-11-03T15:17:56Z

Arnout Vandecappelle:

== Buildroot Developers Meeting, 3-4 November 2012, Barcelona Spain ==

=== What is Buildroot ? ===

[http://buildroot.org 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.

=== Meeting in Barcelona ===

The Buildroot community is organizing a meeting on Saturday November 3rd and Sunday November 4th, for Buildroot developers and contributors. This meeting will be a mixture of discussion and hacking session around the Buildroot project. This meeting takes place right before the Embedded Linux Conference Europe, in order to make it easy for participants to attend both events.

=== Event sponsored by Fluendo and Synopsys ===

The meeting room is sponsored by [http://www.fluendo.com Fluendo]. Thanks!

The Saturday dinner is sponsored by [http://www.synopsys.com Synopsys]. Thanks!

=== Report of the meeting ===

==== Action points ====
* Accept perl series.
* Accept qemu series (after further review).
* Remove compiler on target.
* Remove development files on target.
* Remove documentation on target.
* Explain in the documentation why the above was done.
* Put httpd daemons outside BUSYBOX_SHOW_OTHERS.
* Move BUSYBOX_SHOW_OTHERS conditions to ''depends on'' inside the package Config.in
* busybox: disable mount-nfs in the default config.

==== Details of the discussion ====

# Perl. The perl patch series (now at v11) looks ready to be integrated, but we have our doubts about cpanminus. The problems are: it has separate download infrastructure, which blocks some buildroot features (e.g. make source); it doesn't integrate with the legal-info. However, CPAN is pretty important if you really want to use perl. The decision was to accept cpanminus as well, but add some warnings that some things don't work.
# Qemu. Adding this opens the door for more people to do stuff that buildroot wasn't meant for in the first place (i.e. embedded). However, even in embedded qemu could be relevant. Things like the compiler on the target are much worse for doing crazy things. Giving new packages a chance is OK; we have to be much more careful with things that have global impact (like including development files on target). Conclusion: it's OK to accept qemu.
# Compiler on target. It leads to newbies using buildroot in an inappropriate way (i.e. compile on the target). Also it only works with the internal toolchain. And if we remove it, we can also remove "Development files on target", which simplifies some of the build infrastructure. Also, if you have a compiler on the target, then you can just as well use a distro. Conclusion: we remove it. Also a bunch of other packages can be removed (autotools, vala, ...)
# Documentation on target: if you need this, use a distro. So we remove it.
# We need to explain in the documentation why we removed this stuff.
# Available stuff: i.e. solve the problem of combination of ''select'' and ''depends''. Solving it in Kconfig itself seems to be difficult: there were some patches but the kconfig people didn't like it; Yann and Thomas looked at Kconfig and it looks difficult to modify. The AVAILABLE solution has two problems: it adds verbosity, and the recursive dependencies still should be written in the comments ("libfoo requires WCHAR in the toolchain"). The verbosity is not considered a big issue. For the comments: they currently don't work perfectly either. Removing the comments altogether is an option, but then it is difficult for users to find out why a certain package isn't available. Another possibility is to list the available packages in the documentation (automatically), and mention which toolchain dependencies they have. Wild idea: consider Config.in as a low-level language, and define our own higher-level language from which we generate Config.in. Alternatively, have a developer tool that verifies if everything is consistent (i.e. are the comments correct). One more option: add a big comment in the beginning of the packages list, which says that not all toolchain options are available so not all packages are visible. Converting the toolchain options from ''depends'' to ''select'' is not really an option, because changing toolchain options requires a make clean. We didn't reach a conclusion, we'll come back to it tomorrow.
# kconfig-frontend: Yann now has a repository for Kconfig, it would be nice to branch our Kconfig from that. The idea is to still copy it to our repository.
# BUSYBOX_SHOW_OTHERS: the only reason to have this is to avoid newcomers enabling things like tar etc. which are anyway already in busybox. But for the web servers, they are clearly different from the busybox web servers (and our default busybox config doesn't even enable a web server). Also bash is a typical one, because people write bashisms in their scripts. This discussion is somewhat related to the discussion how to handle packages that provide the same functionality. But for many packages, it's not even the same (httpd, bash, vim). But actually, we're trying to solve a non-existent problem here - except for the web servers. If we generate a list of packages in the documentation, we can add a remark to that that it's also available in busybox. Also move the condition inside the package Config.in instead of outside and make it a ''depends on'', so it is more visible.
# packages with multiple variants: python2/3, Qt4/5, gtk2/3, ... This is again similar to the expat/libxml2 issue. Do we support both python2 and python3? We need to support both versions in most cases. Question is if we want to force that only one of the two is selected, or do we support side-by-side installation. Conclusion: has to be looked at on a case-by-case basis. General philosophy: don't try to be too smart, so don't try to force selecting only one of the two if it doesn't make sense to have both. In cases where a package wants to ''select'' one of these things, convert the ''select'' into a ''depends'' with a comment.
# multiple packages providing the same functionality: lua/luajit, jpeg/jpegturbo, expat/libxml2. These cannot be installed side-by-side, and many packages select e.g. jpeg. OpenGL will have this issue as well. A relatively clean solution is to create virtual packages for these, where the user has a choice between the two. The normal config option would be hidden for these packages. This still adds complexity in some corner cases, e.g. some package that doesn't work in luajit, but that can probably be solved at the level of that package.
# Autobuild infrastructure. Thomas is working on scripts that parse the build result and put it in a database. One important missing feature at the moment is visibility of evolution over time (i.e. distinguish regressions from recurring problems). Even more important is just being able to see which packages are failing all the time, i.e. for each package how often it failed. Ideally, we would also want to see how often a package has been built successfully, but when is it successful? Does the entire build have to succeed or that package? Overall, however, the autobuild infrastructure is considered very useful - when something is wrong, it appears in the autobuild very quickly.
#* autobuild of the next branch: if only the master is autobuilt, we don't see a lot of problems until after the release. Delaying fixing bugs makes it more difficult to fix them. To support autobuild of the next branch, this should also be made visible in the database so we can distinguish master failures (more important) from next failures.
#* autobuild database is not suitable to track repeated builds of the same configuration. It needs to keep track of different builds of the same configurations. But the question is if this is really useful. We would like to check the existing defconfigs at every release, but it doesn't have to be tracked. So it can be done manually.
# AVR32. It is end of life as far as Atmel is concerned, but of course there are still products out there using it. It is not really blocking for buildroot. For packages which fail to build, we can just add a ''depends on !BR2_avr32''. But of course, until we have the AVAILABLE mechanism, carrying this kind of dependency can be painful.
# RPC support. Originally, the idea was to consider RPC support as a toolchain option, i.e. using ''depends''. However, libtirpc is really a library, comparable to gettext, so it could be enabled automatically with ''select''. Busybox is special, because we don't want to force RPC just because busybox is selected. Therefore busybox has a user-selectable option to enable RPC-based applets (mount-nfs). After discussion, this option was discarded - just remove mount-nfs from busybox (see below). Other packages will use libtirpc if it was selected (manually or automatically). It's still a question what will happen when dynamically linking against libtirpc when libc also has rpc.
# A bit related: we'll disable mount-nfs in the default busybox config; if user disables RPC and enables mount-nfs in busybox, he'll get a compilation error.
# Support for VCS branches in packages: custom packages are often in a VCS and while developing, you want to track a branch of that VCS. OVERRIDE_SRCDIR doesn't work very well because it means the user has to check everything out at the right version in the right location. An alternative would be to teach OVERRIDE_SRCDIR about VCSes, so that ''make foo-rebuild'' re-syncs with the VCS.

For tomorrow:
* Interaction between Buildroot configuration options to select architecture specifities (architecture variant, soft-float vs. hard-float, etc.) and the multilib variants available in external toolchains. Proposed by [[User:ThomasPetazzoni]].
* Status on the community organization. Has patchwork improved things? Are patches taken into account in a faster way? Proposed by [[User:ThomasPetazzoni]].
* What are the next "big" things for Buildroot? Proposed by [[User:ThomasPetazzoni]].
* Documentation refactoring? Proposed by Samuel Martin.
* The _AVAILABLE mechanism, and how to properly handle dependency on toolchain options (discuss the proposal made by Yann E. Morin). Proposed by [[User:ThomasPetazzoni]].
* Discuss (and, if approved, implement) the split between _LICENSE and _REDISTRIBUTE for legal-info. I think this won't take much more than 10 minutes chat + 10 minutes hack. Proposed by Luca Ceresoli.
* Make it possible to use a git repository as source for toolchain. This doesn't work well today. Proposed by Mischa Jonker
* Make it possible to do a 'target-clean', as a replacement of uninstall. Will this even work at all? Proposed by Arnout Vandecappelle
* Does it make sense to port the toolchains to generic-package infrastructure? Asked by Arnout Vandecappelle
* How to provide licensing info for packages that have more than one license. The main use cases are: a) different parts of the source code have different licenses, b) a file (or the whole project) is distributed under two or more licenses or c) a mix of the two. See the recent thoughts about this issue by Yann Morin: http://lists.busybox.net/pipermail/buildroot/2012-October/060475.html
* Support for board stuff outside the buildroot tree. Proposed by Arnout Vandecappelle

=== Participants ===

# [[User:Arnout_Vandecappelle|Arnout Vandecappelle]], confirmed. Arriving on Fri Nov 2 20:35 at BCN airport. Leaving Wed Nov. 8 21:15 at BCN. Staying at [http://www.hcchotels.es/en/hotel/12/hcc-lugano HCC Lugano]
# [[User:ThomasPetazzoni|Thomas Petazzoni]], confirmed. Arriving on November, 3rd at BCN airport 9:25 AM. Leaving on November 8th from BCN airport at 3:45 PM. Staying at Hotel Fira Palace.
# Maxime Ripard, confirmed. Arriving on November, 1st at BCN airport. Leaving on November 8th from BCP airport at 3:45 PM. Staying at Hotel Fira Palace.
# [[User:PeterKorsgaard|Peter Korsgaard]], confirmed, Arriving on Fri Nov 2 21:55 at BCN airport. Leaving Sun Nov 11 17:15 at BCN. Staying at [http://www.hcchotels.es/en/hotel/12/hcc-lugano HCC Lugano]
# Luca Ceresoli, confirmed. Arriving on November 3rd at BCN airport 10:05 AM. Leaving on November 7th from BCN airport 19:15 PM. Staying at Hotel Fira Palace. Will arrive around 11:30 AM for the meeting.
# Samuel Martin, confirmed. Arriving on November, 3rd at Barcelona-Franca Train Station 8:05 AM. Leaving on November 10th from Barcelona-Franca Train Station at 8:43 PM.
# Simon Dawson, confirmed. Arriving on November 2nd in the evening. Leaving on November 8th early morning.
# Mischa Jonker, confirmed. From Synopsys.com. Not contributing yet to Buildroot, but interested in using Buildroot for a brand new CPU architecture. Arriving Friday Nov 2nd BCN 21:10 CET, staying at Catalonia Barcelona Plaza (Plaza Espanya), leaving Thursday Nov 8 at 18:40 CET.
# Maxime Hadjinlian.

=== Registration ===

Please contact Thomas Petazzoni (thomas.petazzoni@free-electrons.com) if you would like to attend.

Attending the event is free, but registration is required.

=== Program ===

* Saturday, 10 AM: beginning of the meeting. The first person to arrive can go directly to the front desk and ask for MARIBEL SOCIAS or anyone in the Reservations Department, and then ask for the meeting room booked for Thomas Petazzoni. [[User:ThomasPetazzoni|Thomas Petazzoni]] will only arrive at 10:30-11 AM.
* Saturday, 7 PM: end of the meeting
* Saturday, 8:30 PM: dinner sponsored by Synopsys
* Sunday, 10 AM: beginning of the meeting
* Sunday, 7 PM: end of the meeting

=== Location ===

The event will take place at [http://www.hotelgrumsbarcelona.com/ Hotel Grumps], in downtown Barcelona. See [http://goo.gl/maps/htYi9 this map] for the location of the hotel, and [http://goo.gl/maps/GdiaM this map] for walking directions between the Fira Palace hotel (location of the ELCE conference) and Hotel Grums.

=== List of topics to discuss ===

* Interaction between Buildroot configuration options to select architecture specifities (architecture variant, soft-float vs. hard-float, etc.) and the multilib variants available in external toolchains. Proposed by [[User:ThomasPetazzoni]].
* Status on the community organization. Has patchwork improved things? Are patches taken into account in a faster way? Proposed by [[User:ThomasPetazzoni]].
* What are the next "big" things for Buildroot? Proposed by [[User:ThomasPetazzoni]].
* Documentation refactoring? Proposed by Samuel Martin.
* Autobuilder tests: needed improvements, future work. Proposed by [[User:ThomasPetazzoni]].
* The _AVAILABLE mechanism, and how to properly handle dependency on toolchain options (discuss the proposal made by Yann E. Morin). Proposed by [[User:ThomasPetazzoni]].
* Discuss (and, if approved, implement) the split between _LICENSE and _REDISTRIBUTE for legal-info. I think this won't take much more than 10 minutes chat + 10 minutes hack. Proposed by Luca Ceresoli.
* Make it possible to use a git repository as source for toolchain. This doesn't work well today. Proposed by Mischa Jonker
* Make it possible to do a 'target-clean', as a replacement of uninstall. Will this even work at all? Proposed by Arnout Vandecappelle
* Does it make sense to port the toolchains to generic-package infrastructure? Asked by Arnout Vandecappelle
* How to provide licensing info for packages that have more than one license. The main use cases are: a) different parts of the source code have different licenses, b) a file (or the whole project) is distributed under two or more licenses or c) a mix of the two. See the recent thoughts about this issue by Yann Morin: http://lists.busybox.net/pipermail/buildroot/2012-October/060475.html
* Support for board stuff outside the buildroot tree. Proposed by Arnout Vandecappelle
* Should we remove the ability to build a toolchain on the target? And also things like development files on target, documentation on target, etc. Proposed by [[User:ThomasPetazzoni]].

=== List of topics to hack on ===

* Reduce the back log of bugs. Proposed by [[User:ThomasPetazzoni]].
* Reduce the back log of patches. Proposed by [[User:ThomasPetazzoni]].
* Work on noMMU platform support (Blackfin, Coldfire). Getting Coldfire Qemu working, adding correct support for FLAT binaries. Proposed by [[User:ThomasPetazzoni]].
* Package upgrades: package python3, gtk3 and latest versions of glib and al. Proposed by [[User:ThomasPetazzoni]].
* Triage autobuilder failures and fix them. Proposed by Arnout Vandecappelle
* Improve the documentation. Proposed by Arnout Vandecappelle
* Work on relocatable toolchain. Proposed by Arnout Vandecappelle
* Add some infra for setup.py/qmake based packages. Proposed by Samuel Martin
* Add some infra for make based packages (mainly using the same pattern all over). Proposed by Arnout Vandecappelle
* Add some infra for Kconfig based packages (linux, barebox, busybox, uclibc, ct-ng, at91bootstrap3). Proposed by Arnout Vandecappelle
* Make top-level make -j possible. Proposed by Arnout Vandecappelle

Buildroot:DeveloperDaysELCE2012

2012-11-03T14:58:52Z

Arnout Vandecappelle:

== Buildroot Developers Meeting, 3-4 November 2012, Barcelona Spain ==

=== What is Buildroot ? ===

[http://buildroot.org 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.

=== Meeting in Barcelona ===

The Buildroot community is organizing a meeting on Saturday November 3rd and Sunday November 4th, for Buildroot developers and contributors. This meeting will be a mixture of discussion and hacking session around the Buildroot project. This meeting takes place right before the Embedded Linux Conference Europe, in order to make it easy for participants to attend both events.

=== Event sponsored by Fluendo and Synopsys ===

The meeting room is sponsored by [http://www.fluendo.com Fluendo]. Thanks!

The Saturday dinner is sponsored by [http://www.synopsys.com Synopsys]. Thanks!

=== Report of the meeting ===

==== Action points ====
* Accept perl series.
* Accept qemu series (after further review).
* Remove compiler on target.
* Remove development files on target.
* Remove documentation on target.
* Explain in the documentation why the above was done.
* Put httpd daemons outside BUSYBOX_SHOW_OTHERS.
* Move BUSYBOX_SHOW_OTHERS conditions to ''depends on'' inside the package Config.in
* busybox: disable mount-nfs in the default config.

==== Details of the discussion ====

# Perl. The perl patch series (now at v11) looks ready to be integrated, but we have our doubts about cpanminus. The problems are: it has separate download infrastructure, which blocks some buildroot features (e.g. make source); it doesn't integrate with the legal-info. However, CPAN is pretty important if you really want to use perl. The decision was to accept cpanminus as well, but add some warnings that some things don't work.
# Qemu. Adding this opens the door for more people to do stuff that buildroot wasn't meant for in the first place (i.e. embedded). However, even in embedded qemu could be relevant. Things like the compiler on the target are much worse for doing crazy things. Giving new packages a chance is OK; we have to be much more careful with things that have global impact (like including development files on target). Conclusion: it's OK to accept qemu.
# Compiler on target. It leads to newbies using buildroot in an inappropriate way (i.e. compile on the target). Also it only works with the internal toolchain. And if we remove it, we can also remove "Development files on target", which simplifies some of the build infrastructure. Also, if you have a compiler on the target, then you can just as well use a distro. Conclusion: we remove it. Also a bunch of other packages can be removed (autotools, vala, ...)
# Documentation on target: if you need this, use a distro. So we remove it.
# We need to explain in the documentation why we removed this stuff.
# Available stuff: i.e. solve the problem of combination of ''select'' and ''depends''. Solving it in Kconfig itself seems to be difficult: there were some patches but the kconfig people didn't like it; Yann and Thomas looked at Kconfig and it looks difficult to modify. The AVAILABLE solution has two problems: it adds verbosity, and the recursive dependencies still should be written in the comments ("libfoo requires WCHAR in the toolchain"). The verbosity is not considered a big issue. For the comments: they currently don't work perfectly either. Removing the comments altogether is an option, but then it is difficult for users to find out why a certain package isn't available. Another possibility is to list the available packages in the documentation (automatically), and mention which toolchain dependencies they have. Wild idea: consider Config.in as a low-level language, and define our own higher-level language from which we generate Config.in. Alternatively, have a developer tool that verifies if everything is consistent (i.e. are the comments correct). One more option: add a big comment in the beginning of the packages list, which says that not all toolchain options are available so not all packages are visible. Converting the toolchain options from ''depends'' to ''select'' is not really an option, because changing toolchain options requires a make clean. We didn't reach a conclusion, we'll come back to it tomorrow.
# kconfig-frontend: Yann now has a repository for Kconfig, it would be nice to branch our Kconfig from that. The idea is to still copy it to our repository.
# BUSYBOX_SHOW_OTHERS: the only reason to have this is to avoid newcomers enabling things like tar etc. which are anyway already in busybox. But for the web servers, they are clearly different from the busybox web servers (and our default busybox config doesn't even enable a web server). Also bash is a typical one, because people write bashisms in their scripts. This discussion is somewhat related to the discussion how to handle packages that provide the same functionality. But for many packages, it's not even the same (httpd, bash, vim). But actually, we're trying to solve a non-existent problem here - except for the web servers. If we generate a list of packages in the documentation, we can add a remark to that that it's also available in busybox. Also move the condition inside the package Config.in instead of outside and make it a ''depends on'', so it is more visible.
# packages with multiple variants: python2/3, Qt4/5, gtk2/3, ... This is again similar to the expat/libxml2 issue. Do we support both python2 and python3? We need to support both versions in most cases. Question is if we want to force that only one of the two is selected, or do we support side-by-side installation. Conclusion: has to be looked at on a case-by-case basis. General philosophy: don't try to be too smart, so don't try to force selecting only one of the two if it doesn't make sense to have both. In cases where a package wants to ''select'' one of these things, convert the ''select'' into a ''depends'' with a comment.
# multiple packages providing the same functionality: lua/luajit, jpeg/jpegturbo, expat/libxml2. These cannot be installed side-by-side, and many packages select e.g. jpeg. OpenGL will have this issue as well. A relatively clean solution is to create virtual packages for these, where the user has a choice between the two. The normal config option would be hidden for these packages. This still adds complexity in some corner cases, e.g. some package that doesn't work in luajit, but that can probably be solved at the level of that package.
# Autobuild infrastructure. Thomas is working on scripts that parse the build result and put it in a database. One important missing feature at the moment is visibility of evolution over time (i.e. distinguish regressions from recurring problems). Even more important is just being able to see which packages are failing all the time, i.e. for each package how often it failed. Ideally, we would also want to see how often a package has been built successfully, but when is it successful? Does the entire build have to succeed or that package? Overall, however, the autobuild infrastructure is considered very useful - when something is wrong, it appears in the autobuild very quickly.
#* autobuild of the next branch: if only the master is autobuilt, we don't see a lot of problems until after the release. Delaying fixing bugs makes it more difficult to fix them. To support autobuild of the next branch, this should also be made visible in the database so we can distinguish master failures (more important) from next failures.
#* autobuild database is not suitable to track repeated builds of the same configuration. It needs to keep track of different builds of the same configurations. But the question is if this is really useful. We would like to check the existing defconfigs at every release, but it doesn't have to be tracked. So it can be done manually.
# AVR32. It is end of life as far as Atmel is concerned, but of course there are still products out there using it. It is not really blocking for buildroot. For packages which fail to build, we can just add a ''depends on !BR2_avr32''. But of course, until we have the AVAILABLE mechanism, carrying this kind of dependency can be painful.
# RPC support. Originally, the idea was to consider RPC support as a toolchain option, i.e. using ''depends''. However, libtirpc is really a library, comparable to gettext, so it could be enabled automatically with ''select''. Busybox is special, because we don't want to force RPC just because busybox is selected. Therefore busybox has a user-selectable option to enable RPC-based applets (mount-nfs). After discussion, this option was discarded - just remove mount-nfs from busybox (see below). Other packages will use libtirpc if it was selected (manually or automatically). It's still a question what will happen when dynamically linking against libtirpc when libc also has rpc.
# A bit related: we'll disable mount-nfs in the default busybox config; if user disables RPC and enables mount-nfs in busybox, he'll get a compilation error.

=== Participants ===

# [[User:Arnout_Vandecappelle|Arnout Vandecappelle]], confirmed. Arriving on Fri Nov 2 20:35 at BCN airport. Leaving Wed Nov. 8 21:15 at BCN. Staying at [http://www.hcchotels.es/en/hotel/12/hcc-lugano HCC Lugano]
# [[User:ThomasPetazzoni|Thomas Petazzoni]], confirmed. Arriving on November, 3rd at BCN airport 9:25 AM. Leaving on November 8th from BCN airport at 3:45 PM. Staying at Hotel Fira Palace.
# Maxime Ripard, confirmed. Arriving on November, 1st at BCN airport. Leaving on November 8th from BCP airport at 3:45 PM. Staying at Hotel Fira Palace.
# [[User:PeterKorsgaard|Peter Korsgaard]], confirmed, Arriving on Fri Nov 2 21:55 at BCN airport. Leaving Sun Nov 11 17:15 at BCN. Staying at [http://www.hcchotels.es/en/hotel/12/hcc-lugano HCC Lugano]
# Luca Ceresoli, confirmed. Arriving on November 3rd at BCN airport 10:05 AM. Leaving on November 7th from BCN airport 19:15 PM. Staying at Hotel Fira Palace. Will arrive around 11:30 AM for the meeting.
# Samuel Martin, confirmed. Arriving on November, 3rd at Barcelona-Franca Train Station 8:05 AM. Leaving on November 10th from Barcelona-Franca Train Station at 8:43 PM.
# Simon Dawson, confirmed. Arriving on November 2nd in the evening. Leaving on November 8th early morning.
# Mischa Jonker, confirmed. From Synopsys.com. Not contributing yet to Buildroot, but interested in using Buildroot for a brand new CPU architecture. Arriving Friday Nov 2nd BCN 21:10 CET, staying at Catalonia Barcelona Plaza (Plaza Espanya), leaving Thursday Nov 8 at 18:40 CET.
# Maxime Hadjinlian.

=== Registration ===

Please contact Thomas Petazzoni (thomas.petazzoni@free-electrons.com) if you would like to attend.

Attending the event is free, but registration is required.

=== Program ===

* Saturday, 10 AM: beginning of the meeting. The first person to arrive can go directly to the front desk and ask for MARIBEL SOCIAS or anyone in the Reservations Department, and then ask for the meeting room booked for Thomas Petazzoni. [[User:ThomasPetazzoni|Thomas Petazzoni]] will only arrive at 10:30-11 AM.
* Saturday, 7 PM: end of the meeting
* Saturday, 8:30 PM: dinner sponsored by Synopsys
* Sunday, 10 AM: beginning of the meeting
* Sunday, 7 PM: end of the meeting

=== Location ===

The event will take place at [http://www.hotelgrumsbarcelona.com/ Hotel Grumps], in downtown Barcelona. See [http://goo.gl/maps/htYi9 this map] for the location of the hotel, and [http://goo.gl/maps/GdiaM this map] for walking directions between the Fira Palace hotel (location of the ELCE conference) and Hotel Grums.

=== List of topics to discuss ===

* Interaction between Buildroot configuration options to select architecture specifities (architecture variant, soft-float vs. hard-float, etc.) and the multilib variants available in external toolchains. Proposed by [[User:ThomasPetazzoni]].
* Status on the community organization. Has patchwork improved things? Are patches taken into account in a faster way? Proposed by [[User:ThomasPetazzoni]].
* What are the next "big" things for Buildroot? Proposed by [[User:ThomasPetazzoni]].
* Documentation refactoring? Proposed by Samuel Martin.
* Autobuilder tests: needed improvements, future work. Proposed by [[User:ThomasPetazzoni]].
* The _AVAILABLE mechanism, and how to properly handle dependency on toolchain options (discuss the proposal made by Yann E. Morin). Proposed by [[User:ThomasPetazzoni]].
* Discuss (and, if approved, implement) the split between _LICENSE and _REDISTRIBUTE for legal-info. I think this won't take much more than 10 minutes chat + 10 minutes hack. Proposed by Luca Ceresoli.
* Make it possible to use a git repository as source for toolchain. This doesn't work well today. Proposed by Mischa Jonker
* Make it possible to do a 'target-clean', as a replacement of uninstall. Will this even work at all? Proposed by Arnout Vandecappelle
* Does it make sense to port the toolchains to generic-package infrastructure? Asked by Arnout Vandecappelle
* How to provide licensing info for packages that have more than one license. The main use cases are: a) different parts of the source code have different licenses, b) a file (or the whole project) is distributed under two or more licenses or c) a mix of the two. See the recent thoughts about this issue by Yann Morin: http://lists.busybox.net/pipermail/buildroot/2012-October/060475.html
* Support for board stuff outside the buildroot tree. Proposed by Arnout Vandecappelle
* Should we remove the ability to build a toolchain on the target? And also things like development files on target, documentation on target, etc. Proposed by [[User:ThomasPetazzoni]].

=== List of topics to hack on ===

* Reduce the back log of bugs. Proposed by [[User:ThomasPetazzoni]].
* Reduce the back log of patches. Proposed by [[User:ThomasPetazzoni]].
* Work on noMMU platform support (Blackfin, Coldfire). Getting Coldfire Qemu working, adding correct support for FLAT binaries. Proposed by [[User:ThomasPetazzoni]].
* Package upgrades: package python3, gtk3 and latest versions of glib and al. Proposed by [[User:ThomasPetazzoni]].
* Triage autobuilder failures and fix them. Proposed by Arnout Vandecappelle
* Improve the documentation. Proposed by Arnout Vandecappelle
* Work on relocatable toolchain. Proposed by Arnout Vandecappelle
* Add some infra for setup.py/qmake based packages. Proposed by Samuel Martin
* Add some infra for make based packages (mainly using the same pattern all over). Proposed by Arnout Vandecappelle
* Add some infra for Kconfig based packages (linux, barebox, busybox, uclibc, ct-ng, at91bootstrap3). Proposed by Arnout Vandecappelle
* Make top-level make -j possible. Proposed by Arnout Vandecappelle

Buildroot:DeveloperDaysELCE2012

2012-11-03T14:35:33Z

Arnout Vandecappelle:

Buildroot:DeveloperDaysELCE2012

2012-11-03T14:27:44Z

Arnout Vandecappelle:

Buildroot:DeveloperDaysELCE2012

2012-11-03T12:39:13Z

Arnout Vandecappelle:

Buildroot:DeveloperDaysELCE2012

2012-11-03T11:56:58Z

Arnout Vandecappelle: /* Report of the meeting */

Buildroot:DeveloperDaysELCE2012

2012-11-03T11:54:54Z

Arnout Vandecappelle: /* Report of the meeting */

Buildroot:DeveloperDaysELCE2012

2012-11-03T11:52:22Z

Arnout Vandecappelle: /* Report of the meeting */

Buildroot:DeveloperDaysELCE2012

2012-11-03T11:23:05Z

Arnout Vandecappelle: /* Report of the meeting */

Buildroot:DeveloperDaysELCE2012

2012-11-03T10:58:21Z

Arnout Vandecappelle: /* Report of the meeting */

Buildroot:DeveloperDaysELCE2012

2012-11-03T10:33:42Z

Arnout Vandecappelle:

Buildroot:DeveloperDaysELCE2012

2012-11-03T10:32:46Z

Arnout Vandecappelle:

Buildroot:DeveloperDaysELCE2012

2012-10-30T21:24:04Z

Arnout Vandecappelle:

Buildroot:DeveloperDaysELCE2012

2012-10-30T21:18:46Z

Arnout Vandecappelle: More discussion and hacking topics

Buildroot:DeveloperDaysELCE2012

2012-10-24T20:01:48Z

Arnout Vandecappelle:

Buildroot:DeveloperDaysELCE2012

2012-09-27T07:38:22Z

Arnout Vandecappelle:

Buildroot

2012-03-03T18:54:48Z

Arnout Vandecappelle:

Buildroot is a nice, simple, and efficient embedded Linux build system. [http://www.buildroot.org Buildroot main page]

==Todo list==

This is a list of improvements that we would like to see in buildroot. Feel free to add suggestions here. If you're working on one of these items, put your name and the date behind it, to avoid duplicate work.

* Document how to contribute (patches to list instead of bugzilla, SOB, formatting rules, acked-by and tested-by, how often to repost, what to expect, CC's, ...)
* Document how a package patch should be formatted (Comment, SOB, file naming rules, ...) + send upstream + CC sendpatches
* Peter sets up a planet on whatever server and links to it from buildroot website
* Peter sets up a cgi script on the website where test results can be POST-ed
* Peter adds a script to the website to generate on-line documentation from asciidoc
* Add the generated manual to the release tarball in the ''release'' target
* Peter contacts ozlabs.org to request hosting a patchwork for buildroot
* Finalize legal-info
* Clean up infrastructure for applying patches: modify apply-patches script to support new naming scheme, migrate existing patches, remove architecture-specific patch support
* In documentation, explain how to report a bug
* Add rsync to target-finalize, document this as the preferred method of customizing the target rootfs
* The CMake toolchain file should be moved somewhere into host/ to be part of the SDK, maybe host/usr/share/cmake or host/usr/share/buildroot.
* It would be nice to add a br-configure script in host/usr/bin for autotools-based packages. Run ...BUILDROOTSDK/usr/bin/br-configure --enable-foo --disable-bar, and the br-configure script would call the ./configure script in the current directory passing all the right options (--host, and all environment variables CC, LD, AS, AR and such).

Here is what needs to be done to make the HOST-directory a relocatable SDK:
* Make sure that all binaries and libraries built for the host are built with a rpath pointing to host/usr/lib. Normally, this should already be the case, but it's worth checking.
* Change the rpath value to $ORIGIN/../lib instead of the current absolute path $(O)/host/usr/lib.
* Modify the compiler wrapper program of external toolchains so that instead of using a fixed location for the compiler tools, it deduces their location in a relative manner from its current location.
* Modify/patch pkg-config so that instead of having a fixed location for the PKG_CONFIG_PATH and PKG_CONFIG_SYSROOT_DIR, those are deduced from the location of the pkg-config binary. This will allow a pkg-config binary that has been moved to still operate properly, without having to set any environment variable.
* Write a shell script, installed in host/usr/bin, which would mungle the libtool .la files, the qmake.conf file and the CMake toolchain file to set the correct path. This script reads a file (can be host/usr/share/buildroot/location) which contains the original location of the SDK. This allows the script to do the right modifications on all the libtool, qmake.conf and cmake files. Once this is done, the script changes the host/usr/share/buildroot/location file so that it contains the new location.
* Modify the external toolchain wrapper so that it bails out and warns the user if the directory it is executed in doesn't match the location of host/usr/share/buildroot/location. We haven't discussed how this could work with internal and crosstool-NG toolchains, though.

Here are some nice-to-have's for which it is not entirely clear if and how they could be implemented:
* Out-of-tree builds, which allows the package source to be shared between different output directories and between host and target compiles.
* It would be nice if you could run a buildroot command that prepares a local copy of a package's source, and allows you to generate patches for it later. This could use git or quilt to keep track of the patches.
* It would be nice if there was a make target to reinstall everything to the target (i.e. remove all the target-installed stamps, remove the root stamp, maybe remove the target too). However, what is missing is the copying of the toolchain support files (libc.so etc.). It's not obvious that this can be done in a reliable way.
* It would be nice if there was some common infrastructure to combine the images into one final flash or SD card or whatever image. However, it is probably difficult to find the commonality of all the different use cases. And we don't even see all these use cases.
* SoC-specific architectures: it would be nice if the user could select e.g. OMAP3 instead of Cortex-A8. It's a bit unclear what granularity would be needed here (OMAP? OMAP3? OMAP3530?). Also, it seems to be too much maintenance work to support all that, and the list of SoCs or SoC families could grow very long.
* The uninstall targets are pretty useless because they don't really work. Should we remove support for uninstall?
* It would be nice to have support for neon, vfp, thumb2, ... Tricky for external compilers, because we must know if it matches the options we want to give it.

Category:Buildroot

2012-02-15T20:05:17Z

Arnout Vandecappelle: Created page with "Buildroot is a nice, simple, and efficient embedded Linux build system. [http://www.buildroot.org Buildroot main page]"

Buildroot is a nice, simple, and efficient embedded Linux build system. [http://www.buildroot.org Buildroot main page]

Build Systems

2012-02-15T20:04:34Z

Arnout Vandecappelle: Convert Buildroot page into a category

* [[Yocto Project]] - Project for multiple embedded Linux technologies
* [[Open Embedded]] - System for building full embedded images from scratch
* [[:Category:Buildroot]] is a set of Makefiles and patches that makes it easy generate a cross-compilation toolchain and root filesystem for your target Linux system using the uClibc C library.
* [http://www.pengutronix.de/software/ptxdist/index_en.html PTXdist]
** Kconfig based build system developed by [http://www.pengutronix.de/index_en.html Pengutronix]
** GPL licensed
** [http://free-electrons.com/pub/video/2009/fosdem/fosdem2009-schwebel-ptxdist.ogv Video] of a talk given by PTXdist maintainer Robert Schwebel at [http://www.fosdem.org FOSDEM 2009]
* [http://www.linuxfromscratch.org/ Linux From Scratch]
* LTIB - Linux Target Image Builder (by Stuart Hughes of FreeScale) - see http://savannah.nongnu.org/projects/ltib
** [http://www.bitshrine.org/celf_ltib_bof_v1.2.pdf Slides] and [http://free-electrons.com/pub/video/2008/ols/ols2008-stuart-hughes-ltib.ogg video] of a talk on LTIB at the Ottawa Linux Symposium 2008
* [[OpenBricks]] - Embedded Linux Framework
** OpenBricks provides a set of packages, patches and shell-based rules that creates a toolchain and a rootfs with customized packages and features selection.
** Currently supports x86_32, x86_64, PowerPC, PowerPC64 and ARM architectures with either uClibc, Glibc or eGlibc C library.
* [http://www.mvista.com/download/fetchdoc.php?docid=342 Building Embedded Userlands] - Presentation by Ned Miljevic & Klaas van Gend at the ELC 2008 which compares different configuration and build systems. [http://free-electrons.com/pub/video/2008/elce/elce2008-miljevic-van-gend-embedded-userlands.ogv Video] of the conference available.
* [[Scratchbox]] Cross-Compilation Toolkit, with support for x86 and arm.
* [[OpenWRT]] Cross-Compilation Toolkit mainly geared towards wireless routers but can be extended to other platforms, with support for x86, MIPS and ARM.
See also [[Toolchains]]
[[Category:Development Tools]]

Build Systems

2012-02-15T20:02:42Z

Arnout Vandecappelle: Internal link for buildroot

* [[Yocto Project]] - Project for multiple embedded Linux technologies
* [[Open Embedded]] - System for building full embedded images from scratch
* [[Buildroot]] is a set of Makefiles and patches that makes it easy generate a cross-compilation toolchain and root filesystem for your target Linux system using the uClibc C library.
* [http://www.pengutronix.de/software/ptxdist/index_en.html PTXdist]
** Kconfig based build system developed by [http://www.pengutronix.de/index_en.html Pengutronix]
** GPL licensed
** [http://free-electrons.com/pub/video/2009/fosdem/fosdem2009-schwebel-ptxdist.ogv Video] of a talk given by PTXdist maintainer Robert Schwebel at [http://www.fosdem.org FOSDEM 2009]
* [http://www.linuxfromscratch.org/ Linux From Scratch]
* LTIB - Linux Target Image Builder (by Stuart Hughes of FreeScale) - see http://savannah.nongnu.org/projects/ltib
** [http://www.bitshrine.org/celf_ltib_bof_v1.2.pdf Slides] and [http://free-electrons.com/pub/video/2008/ols/ols2008-stuart-hughes-ltib.ogg video] of a talk on LTIB at the Ottawa Linux Symposium 2008
* [[OpenBricks]] - Embedded Linux Framework
** OpenBricks provides a set of packages, patches and shell-based rules that creates a toolchain and a rootfs with customized packages and features selection.
** Currently supports x86_32, x86_64, PowerPC, PowerPC64 and ARM architectures with either uClibc, Glibc or eGlibc C library.
* [http://www.mvista.com/download/fetchdoc.php?docid=342 Building Embedded Userlands] - Presentation by Ned Miljevic & Klaas van Gend at the ELC 2008 which compares different configuration and build systems. [http://free-electrons.com/pub/video/2008/elce/elce2008-miljevic-van-gend-embedded-userlands.ogv Video] of the conference available.
* [[Scratchbox]] Cross-Compilation Toolkit, with support for x86 and arm.
* [[OpenWRT]] Cross-Compilation Toolkit mainly geared towards wireless routers but can be extended to other platforms, with support for x86, MIPS and ARM.
See also [[Toolchains]]
[[Category:Development Tools]]