Please note that User Registration has been temporarily disabled due to a recent increase in automated registrations. If anyone needs an account, please request one here: RequestAccount. Thanks for your patience!--Wmat (talk)
Please email User:Wmat if you experience any issues with the Request Account form.

Buildroot:DeveloperDaysELCE2012

From eLinux.org
Jump to: navigation, search

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

What is Buildroot ?

Buildroot is a set of Makefiles and patches that makes it easy to generate a complete embedded Linux system. Buildroot can generate any or all of a cross-compilation toolchain, a root filesystem, a kernel image and a bootloader image. Buildroot is useful mainly for people working with small or embedded systems, using various CPU architectures (x86, ARM, MIPS, PowerPC, etc.) : it automates the building process of your embedded system and eases the cross-compilation process.

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 Fluendo. Thanks!

The Saturday dinner is sponsored by 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

Details of the discussion

1. 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. 1. 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. 1. 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, ...) 1. Documentation on target: if you need this, use a distro. So we remove it. 1. We need to explain in the documentation why we removed this stuff. 1. 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. 1. 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. 1. 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.

1. Big packages

Participants

  1. Arnout Vandecappelle, confirmed. Arriving on Fri Nov 2 20:35 at BCN airport. Leaving Wed Nov. 8 21:15 at BCN. Staying at HCC Lugano
  2. 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.
  3. 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.
  4. Peter Korsgaard, confirmed, Arriving on Fri Nov 2 21:55 at BCN airport. Leaving Sun Nov 11 17:15 at BCN. Staying at HCC Lugano
  5. 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.
  6. 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.
  7. Simon Dawson, confirmed. Arriving on November 2nd in the evening. Leaving on November 8th early morning.
  8. 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.
  9. 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. 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 Hotel Grumps, in downtown Barcelona. See this map for the location of the hotel, and 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