Buildroot:GSoC2016Ideas

From eLinux.org
Revision as of 11:52, 9 February 2016 by Ymorin (talk | contribs)
Jump to: navigation, search

2016 will be the third year of participation of Buildroot to the Google Summer of Code program. This year, we are proposing the following ideas.

Mentors

The following people will be your mentors. Each topic is assigned a mentor, who will be your referent and will follow you during the GSoC. However, all mentors will be available to help you.

  • Arnout Vandecapelle
  • Peter Korsgaard
  • Romain Naour
  • Thomas Petazzoni
  • Yann E. MORIN

Topics

The following topics are suggested by the Buildroot developers; they are not sorted in any specific order, not even of preference. Feel free to propose your own ideas.

(Detailed descriptions will be added shortly.)

Reproducible builds

Mentor: Yann E. MORIN

Short: Ensure that two consecutive runs of Buildroot with the same configuration yield the same result.

Testing infrastructure

Mentor: Thomas Petazzoni

Short: Improve upon the existing testing infrastructures, build-time and runtime tests.

Abstract

The Buildroot project uses automated testing to help validate the stability of the project. There are currently two types of automated testing:

  • random configurations are used to help validate that the millions of possible Buildroot configurations build correctly. This automated build testing has been running for about three years (results visibles at [1]),
  • regression testing of a set of known configurations is used to track the sample configurations for a set of commonly-available embedded boards (Beagle Bone, Raspberry Pi, Wandboard...). This regression testing has been running for a few months now as a test-bed and now reports build results every other days.

These testing infrastructure have helped improve the quality of Buildroot. However, the project would like to bring a number of improvements to the random configuration testing infrastructure.

Description

We would like to add runtime testing, i.e really boot the generated system under Qemu, and verify, for the different packages that are part of the system, that they at least minimally work. For example, if the Python interpreter has been selected to be part of the system, verify that we can run it, and run a simple Python test application on the target. This involves creating an infrastructure to start Qemu, run tests inside Qemu, and integrate the tests in the Buildroot packages themselves.

Skills

  • Basic Embedded Linux knowledge (cross-compilation, kernel configuration/build, etc.)
  • Knowledge of the Python scripting language, used for the development of the testing infrastructure.
  • Some Web development skills and/or knowledge of tools like Jenkins would be a plus.

Relocatable SDK

Mentor: Yann E. MORIN

Short: Make the generated toolchain and staging relocatable.

Top-level parallel build

Mentor: Arnout Vandecapelle

Short: Allow a full top-level, concurrent, parallel build of packages.

Follow upstream updates of packages

Mentor: Peter Korsgaard

Short: Provide infrastructure to easily follow version changes in upstream packages.

Support for LLVM

Mentor: Romain Naour

Short: Add support for building an LLVM/Clang-based cross-toolchain, and ensure as many packages as possible still build and run.

Upstream python patches

Mentor: Thomas Petazzoni

Short: Upstream our many and complex patches against Python (2 and 3) to support cross-compilation.

Support new languages

Mentor: Arnout Vandecapelle

Short: Add support for new languages (Go, Rust...).


Suggestions for candidates

If you want to apply, we recommend you to prove that you have some basic knowledge about Buildroot and open-source contributions:

  • Subscribe to the mailing list and come to the IRC channel
  • Post some patches to the mailing list. Here are some possible contribution ideas:
    • Look at some items in our TODO list at http://elinux.org/Buildroot#Todo_list, implement some of them, and send patches
    • Find some software component that is useful on embedded systems, create a Buildroot package for it, and send patches
    • Find some embedded hardware platform, create a Buildroot defconfig for it, and send patches
    • Look at some build failures in our autobuilders at http://autobuild.buildroot.org and send patches to fix them. Note that some build failures may be difficult to solve.
    • Look at the bug tracker at http://bugs.busybox.net and send patches to fix them. Some patches may be difficult to look at.