[Buildroot] Some topics for the Buildroot Developer Day

[Buildroot] Some topics for the Buildroot Developer Day

[Thomas Petazzoni]

Hello,

As discussed on IRC, I am posting below a list of topics that might be
discussed during the developer day. Note that this is just _my_ list of
topics, note the one of the Buildroot project as a whole. Moreover,
it's very likely that not all topics will be covered during our meeting
day. However, feel free to add your opinion and/or your additional
topics, especially if you can't make it to the Developer day.

Regards,

Thomas

ELCE 2011 meeting agenda
========================

 * Migration to the Ascii-doc format, what remains to be done ?
   Infrastructure on the web server side ?

 * Extract sources in a new output/sources/ directory, and do
   out-of-tree build of packages.

   Pros:

    - Allows more natural integration with the override source
      directory mechanism. No rsync needed here, especially useful for
      big packages such as the kernel.

    - Allows to extract only once the source code for utitilies built
      for the host and the target (X.org components, Glib/Gtk stack,
      etc.)

    - Should work fine for all CMake-based and autotools-based packages.

   Cons:

    - Not all packages support out-of-tree build. The infrastructure
      should support a <pkg>_OUTOFTREE boolean, defaulting to NO for
      all packages, overriden to YES for autotools-based and
      CMake-based packages. When set to NO, the infrastructure will
      have to copy/rsync the source code to the build directory. This
      adds an additional copy of the source code for packages that
      don't support out-of-tree build.

 * Website improvement. The website is ugly, never changes, not
   representative of the vivacity of the community. At least improve
   the design. Wiki ? Blog ?

 * Maintainance/patch review/merge. How to spread the load ? Should we
   move to a model with trusted maintainers for specific parts of
   Buildroot ? Usage of patchwork/Gerrit ?

 * Host packages visible in menuconfig. Discussion has taken place on
   the list, consensus reached between several contributors,
   implementation proposed. What do we do ?

   + proposal of Arnout to derive host dependencies from target
     dependencies.

 * Per-package device files handling, proposed by Maxime Ripard.

 * Testing infrastructure. Possible to put build results on the Web
   server ? Common format for them ?

 * Tracking of files installed by packages. Do we care ? Is this an
   important feature of Buildroot ? Won't the added complexity make
   Buildroot more complicated to understand ?

   Which solution ? Two solutions:

    - Change the installation steps of packages so that each package
      installs in a different directory.

      Pros:

        seems to be the cleanest solution.

        allows to easily detect packages overriding files installed by
        other packages.

      Cons:

        requires modifications of all gentargets packages to use
        $$(STAGING_DIR) and $$(TARGET_DIR) instead of $(STAGING_DIR)
        and $(TARGET_DIR).

        strange handling of host packages. DESTDIR isn't used, the
        prefix is the absolute path to HOST_DIR.

    - Keep installing package files in their normal directory, but
      detect new files and modified files.

      Pros:

        no need to change anything in the current package installation
        procedures.

      Cons:

        need to scan the TARGET_DIR, STAGING_DIR and HOST_DIR after
        every package installation.

        hard to detect modified/overwritten files, except by storing
        hashes of installed files.

 * Next big directions. What are the next big directions for Buildroot
   ? The major features we want to implement ?



-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Some topics for the Buildroot Developer Day

[Robert Schwebel]

Hi Thomas,

On Mon, Oct 24, 2011 at 05:38:15PM +0200, Thomas Petazzoni wrote:
> ELCE 2011 meeting agenda
> ========================

I cannot comment much about the buildroot specific things, being an
alien here :) However, some comments for topics where we might be able
to do some collaboration with the ptxdist + buildroot folks:

>  * Testing infrastructure. Possible to put build results on the Web
>    server? Common format for them?

This would surely be an interesting topic. We have worked on a test
infrastructure for ptxdist for a while now; in fact, we are in the 3rd
iteration:

- The first one was "expect" based. It failed because tcl is *just* so
  ugly, and the risk of getting eye cancer was simply too high ...

- The 2nd one was Python / pexpect based (failed because our method to
  connect the serial port's file descriptor to pexpect was discontinued
  some python minor revisions later). And it turned out that our initial
  idea to easily re-use tests due to the object orientation of Python
  didn't work, because the test adaptions to a scenario often are bigger
  then the test itself.

- We have a kermit based infrastructure now, with shell wrappers; the
  kermit code is ugly as hell, but it works reliably and is well
  wrapped.

If somebody is interested, I can show how we do that.

However, we also do not have the infrastructure for a sane
representation + website presentation of test results, so this is
definitely something where we might collaborate nicely.

>  * Next big directions. What are the next big directions for Buildroot
>    ? The major features we want to implement ?

Does buildroot have a possibility to split between runtime and build
time dependencies? This is something we are fighting with.

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[Buildroot] Some topics for the Buildroot Developer Day

[Thomas Petazzoni]

Le Mon, 24 Oct 2011 18:59:04 +0200,
Robert Schwebel <r.schwebel@pengutronix.de> a ?crit :

> >  * Testing infrastructure. Possible to put build results on the Web
> >    server? Common format for them?
> 
> This would surely be an interesting topic. We have worked on a test
> infrastructure for ptxdist for a while now; in fact, we are in the 3rd
> iteration:
> 
> - The first one was "expect" based. It failed because tcl is *just* so
>   ugly, and the risk of getting eye cancer was simply too high ...
> 
> - The 2nd one was Python / pexpect based (failed because our method to
>   connect the serial port's file descriptor to pexpect was discontinued
>   some python minor revisions later). And it turned out that our initial
>   idea to easily re-use tests due to the object orientation of Python
>   didn't work, because the test adaptions to a scenario often are bigger
>   then the test itself.
> 
> - We have a kermit based infrastructure now, with shell wrappers; the
>   kermit code is ugly as hell, but it works reliably and is well
>   wrapped.
> 
> If somebody is interested, I can show how we do that.

Sure, would be interesting to hear what you're doing in terms of
testing.

> However, we also do not have the infrastructure for a sane
> representation + website presentation of test results, so this is
> definitely something where we might collaborate nicely.

Ok. However note that for the moment, we're only trying to do automated
*build* testing. Automated *runtime* testing is an entirely different
story.

> Does buildroot have a possibility to split between runtime and build
> time dependencies? This is something we are fighting with.

Yes and no. In Buildroot, packages express their dependencies
in their Config.in and their .mk file. The dependencies in the .mk file
are build dependencies, since they are guaranteed to be built before
that package. However, dependencies in Config.in can go beyond the
build dependencies, so some of them can be seen as runtime
dependencies. But we haven't formalized that in any sort of way.

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Some topics for the Buildroot Developer Day

[Eric Bénard]

Hi Thomas,

Le 24/10/2011 21:47, Thomas Petazzoni a ?crit :
> Ok. However note that for the moment, we're only trying to do automated
> *build* testing. Automated *runtime* testing is an entirely different
> story.
>
you may be interested in buildbot or jenkins :
http://trac.buildbot.net/
http://jenkins-ci.org/

example configurations for OE :
http://cgit.openembedded.org/openembedded/tree/contrib/buildbot
http://code.google.com/p/oe-buildbot/wiki/SetupBuildbotMaster
http://code.google.com/p/oe-buildbot/wiki/SetupBuildbotSlaver
http://www.openembedded.org/index.php/TestingScript#Getting_things_on_Hudson_autobuilder_.281.29

Eric

[Buildroot] Some topics for the Buildroot Developer Day

[Shawn J. Goff]

> ?? - Keep installing package files in their normal directory, but
> ? ? ?detect new files and modified files.
>
> ? ? ?Pros:
>
> ? ? ? ?no need to change anything in the current package installation
> ? ? ? ?procedures.
>
> ? ? ?Cons:
>
> ? ? ? ?need to scan the TARGET_DIR, STAGING_DIR and HOST_DIR after
> ? ? ? ?every package installation.
>
> ? ? ? ?hard to detect modified/overwritten files, except by storing
> ? ? ? ?hashes of installed files.
>

Would inotify not be suitable for this? You could use it to generate a
list of which files were created/deleted/modified.

[Buildroot] Some topics for the Buildroot Developer Day

[Quotient Remainder]

Ar 24 DF?mh 2011 ag 16:38, scr?obh "Thomas Petazzoni" <
thomas.petazzoni@free-electrons.com>:
>
>  * Tracking of files installed by packages. Do we care ? Is this an
>   important feature of Buildroot ? Won't the added complexity make
>   Buildroot more complicated to understand ?
>
>   Which solution ? Two solutions:
>
>    - Change the installation steps of packages so that each package
>      installs in a different directory.
>
>      Pros:
>
>        seems to be the cleanest solution.
>
>        allows to easily detect packages overriding files installed by
>        other packages.
>
>      Cons:
>
>        requires modifications of all gentargets packages to use
>        $$(STAGING_DIR) and $$(TARGET_DIR) instead of $(STAGING_DIR)
>        and $(TARGET_DIR).
>

Hello all,
A few months back I posted a patch set that provided a primitive, but
functional, first attempt at this feature (as a separate target install
stage in addition to the existing method) after being prompted to share by
Yann. I don't think I saw any response but I do remember ThomasP saying on
IRC that it was too simplistic and that he would comment in detail on the
list but it seems to have fallen off his (long) list of tasks.
I might take this opportunity to ask for comment again. One thing is that it
needed no extra $ on TARGET_DIR for gen-/auto-targets. The value of
TARGET_DIR is simply overridden to be "output/package/$package".

The reason I "care" about this kind of thing is to allow packaging of the
build components for separate download to the target. I doubt I'm the only
one with such a need - never mind the possibility of package uninstall and
other as yet unconsidered purposes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20111024/44a3f729/attachment.html>

[Buildroot] Some topics for the Buildroot Developer Day

[Mike Frysinger]

On Mon, Oct 24, 2011 at 17:44, Shawn J. Goff wrote:
>> ?? - Keep installing package files in their normal directory, but
>> ? ? ?detect new files and modified files.
>>
>> ? ? ?Pros:
>>
>> ? ? ? ?no need to change anything in the current package installation
>> ? ? ? ?procedures.
>>
>> ? ? ?Cons:
>>
>> ? ? ? ?need to scan the TARGET_DIR, STAGING_DIR and HOST_DIR after
>> ? ? ? ?every package installation.
>>
>> ? ? ? ?hard to detect modified/overwritten files, except by storing
>> ? ? ? ?hashes of installed files.
>>
>
> Would inotify not be suitable for this? You could use it to generate a
> list of which files were created/deleted/modified.

not really.  you'd have to write an inotify daemon, and then keep it
running the entire time from when you last installed to the new
install.  basically it doesn't work out.
-mike

[Buildroot] Some topics for the Buildroot Developer Day

[Peter Korsgaard]

>>>>> "Eric" == Eric B?nard <eric@eukrea.com> writes:

 Eric> Hi Thomas,
 Eric> Le 24/10/2011 21:47, Thomas Petazzoni a ?crit :
 >> Ok. However note that for the moment, we're only trying to do automated
 >> *build* testing. Automated *runtime* testing is an entirely different
 >> story.
 >> 
 Eric> you may be interested in buildbot or jenkins :
 Eric> http://trac.buildbot.net/
 Eric> http://jenkins-ci.org/

Yes, I'm using buildbot at work for the defconfigs we use, and it works
very well - But the problem is how to get good test coverage of our 700+
package / toolchain / kernel combinations?

What I'm currently doing is simply lots of 'make randpackageconfig'
builds - But it generates lots of data, so I haven't found a good way of
putting this information online.

-- 
Bye, Peter Korsgaard

[Buildroot] Some topics for the Buildroot Developer Day

[Thomas Petazzoni]

Le Mon, 24 Oct 2011 23:54:42 +0100,
Quotient Remainder <quotientvremainder@gmail.com> a ?crit :

> A few months back I posted a patch set that provided a primitive, but
> functional, first attempt at this feature (as a separate target install
> stage in addition to the existing method) after being prompted to share by
> Yann. I don't think I saw any response but I do remember ThomasP saying on
> IRC that it was too simplistic and that he would comment in detail on the
> list but it seems to have fallen off his (long) list of tasks.
> I might take this opportunity to ask for comment again. One thing is that it
> needed no extra $ on TARGET_DIR for gen-/auto-targets. The value of
> TARGET_DIR is simply overridden to be "output/package/$package".

What you posted on July 2011 is a very simplified version of what
Lionel Landwerlin did a while ago. Basically, Lionel did what you did,
but in a much more complete way:

 * He did handle the installation of files in the TARGET_DIR, but also
   in STAGING_DIR and HOST_DIR

 * Each part of a package (target, staging, host) was then packaged in
   a tarball

 * Using this, Lionel implemented a <pkg>-uninstall mechanism that
   worked reliably for all packages.

 * On top of his work, I did start implementing support to remove
   packages automatically when they were removed from the menuconfig
   interface.

But I still do remember that it was working just fine on autotargets
packages, but was causing problems on gentargets packages. And there
were also other problems here and there, and the whole thing was making
Buildroot a lot more complicated. I really think we need to keep a
"simplicity first" rule for Buildroot. There are already other very
elaborate build systems, with package management and al., and it
doesn't make sense if Buildroot becomes as complicated as those build
systems.

I don't find the patches Lionel had posted last year, and his Git
repository seems to be offline. Lionel, can you put your Git repo back
online ?

> The reason I "care" about this kind of thing is to allow packaging of the
> build components for separate download to the target.

With your patch, for each package, the files gets installed both into
output/target and output/package/<pkg>/. Then how do you use that ? I
mean, you're talking about "separate" download to the target, but since
everything is already in output/target and therefore in your root
filesystem image?

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Some topics for the Buildroot Developer Day

[Robert Schwebel]

On Tue, Oct 25, 2011 at 08:02:19AM +0200, Peter Korsgaard wrote:
> Yes, I'm using buildbot at work for the defconfigs we use, and it
> works very well - But the problem is how to get good test coverage of
> our 700+ package / toolchain / kernel combinations?
> 
> What I'm currently doing is simply lots of 'make randpackageconfig'
> builds - But it generates lots of data, so I haven't found a good way
> of putting this information online.

When we started with tests, we quickly found out that you don't only
have to be able to test, but also have to cope with what you'll find :)
So if you find lots of broken things, you have to fix them, and that
quickly becomes a lot of work.

So our current strategy is to have a set of "real-life" configs
(customer BSPs), plus corner cases (a config with all-yes). We build
that for the most important platforms (x86/powerpc/arm) and on the
kernels which have most relevance for us (linus-git, linux-next) on a
nightly base. That doesn't cover everything, but seems to be a good
compromise.

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[Buildroot] Some topics for the Buildroot Developer Day

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

 Thomas> But I still do remember that it was working just fine on autotargets
 Thomas> packages, but was causing problems on gentargets packages. And there
 Thomas> were also other problems here and there, and the whole thing was making
 Thomas> Buildroot a lot more complicated. I really think we need to keep a
 Thomas> "simplicity first" rule for Buildroot. There are already other very
 Thomas> elaborate build systems, with package management and al., and it
 Thomas> doesn't make sense if Buildroot becomes as complicated as those build
 Thomas> systems.

I strongly agree.

I'm wondering if we could somehow get rid of the explicit handling of
both staging and target (similar to how we do it for host packages), and
simply exclude some files from staging when we create the file systems.

-- 
Bye, Peter Korsgaard

[Buildroot] Some topics for the Buildroot Developer Day

[Peter Korsgaard]

>>>>> "Robert" == Robert Schwebel <r.schwebel@pengutronix.de> writes:

Hi,

 >> What I'm currently doing is simply lots of 'make randpackageconfig'
 >> builds - But it generates lots of data, so I haven't found a good way
 >> of putting this information online.

 Robert> When we started with tests, we quickly found out that you don't only
 Robert> have to be able to test, but also have to cope with what you'll find :)
 Robert> So if you find lots of broken things, you have to fix them, and that
 Robert> quickly becomes a lot of work.

Indeed. That's the same experience I have from all then
'randpackageconfig' builds. Making the issues public (and fixing what
you can) is not a bad thing though.

-- 
Bye, Peter Korsgaard

[Buildroot] Some topics for the Buildroot Developer Day

[Thomas De Schampheleire]

Hi,

On Mon, Oct 24, 2011 at 5:38 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> As discussed on IRC, I am posting below a list of topics that might be
> discussed during the developer day. Note that this is just _my_ list of
> topics, note the one of the Buildroot project as a whole. Moreover,
> it's very likely that not all topics will be covered during our meeting
> day. However, feel free to add your opinion and/or your additional
> topics, especially if you can't make it to the Developer day.

First of all, thanks for posting this list.
I will not be able to attend ELCE/BDD, so all I can do is give my
preliminary input below...

[..]

> ELCE 2011 meeting agenda
> ========================
>
> ?* Migration to the Ascii-doc format, what remains to be done ?
> ? Infrastructure on the web server side ?

Ack

>
> ?* Extract sources in a new output/sources/ directory, and do
> ? out-of-tree build of packages.
>
> ? Pros:
>
> ? ?- Allows more natural integration with the override source
> ? ? ?directory mechanism. No rsync needed here, especially useful for
> ? ? ?big packages such as the kernel.
>
> ? ?- Allows to extract only once the source code for utitilies built
> ? ? ?for the host and the target (X.org components, Glib/Gtk stack,
> ? ? ?etc.)
>
> ? ?- Should work fine for all CMake-based and autotools-based packages.
>
> ? Cons:
>
> ? ?- Not all packages support out-of-tree build. The infrastructure
> ? ? ?should support a <pkg>_OUTOFTREE boolean, defaulting to NO for
> ? ? ?all packages, overriden to YES for autotools-based and
> ? ? ?CMake-based packages. When set to NO, the infrastructure will
> ? ? ?have to copy/rsync the source code to the build directory. This
> ? ? ?adds an additional copy of the source code for packages that
> ? ? ?don't support out-of-tree build.

I would be in favor of out-of-tree building. We had a discussion on
this some time ago in the thread "[PATCH 05/12] package: implement a
'local' site method". At that time, it was still considered too
difficult to get right.

>
> ?* Website improvement. The website is ugly, never changes, not
> ? representative of the vivacity of the community. At least improve
> ? the design. Wiki ? Blog ?

I agree that the website doesn't look very modern, and I would
certainly not be opposed to changing it.
But, I do feel this is a of a lesser priority with respect to some
other items on the list. So, please don't spend half of Buildroot
Developer Day on creating a website layout ;-)

>
> ?* Maintainance/patch review/merge. How to spread the load ? Should we
> ? move to a model with trusted maintainers for specific parts of
> ? Buildroot ? Usage of patchwork/Gerrit ?

In my opinion, the buildroot development model is an important item to discuss.

Peter has indicated that he currently has little time to spend on
Buildroot, and understandably so: this is a community project and we
cannot expect anyone to take this as a full-time task.
Nevertheless, we should think about ways to improve the way
contributions are handled: patches that are reviewed should make it to
master faster, and we should certainly avoid reviewed patches not
being taken in at all.
Tools like patchwork may help the maintainer in getting an overview of
patches and their statuses, but are not necessarily solving a problem
if all Peter is lacking is time, and he *does* have a good overview of
what remains to be done. This is something that Peter can assess
better than us.
Having co-maintainership for Buildroot, or partial-maintainership on
specific parts could indeed be a solution, but only works if there is
a good understanding between these people and the way the project
should evolve.

Regarding the stable releases: I think it would be good to announce
which date we are shooting for, until when last 'new features' and
until when bugfixes will be accepted. For example, all I know about
the next release is that it's due in November, but there are 30 days
in that month and we're close to the 1st.

Another item regarding the development model is the usage of mailing
list versus bug tracker. Although most people use the mailing list to
send patches or report issues, occasionally people file bug reports as
well (with or without patch). What is the intended split? When should
something become a reported bug, and when is it just posted to the
list?
Also, we should attempt to bring down the number of open bugs
(currently: 66 open bugs). I had the impression that there was some
crash action a short while ago closing or at least querying certain
bugs. We should do that more regularly.
Certainly, bugs that have patches attached to them, should either be
closed and the patch applied to master, or rejected.

Note that closing bugs can be a joint effort, but I'd prefer to have
some directions first: what to do with old bugs that can not be
reproduced. The poster may not be interested anymore and not respond.

>
> ?* Host packages visible in menuconfig. Discussion has taken place on
> ? the list, consensus reached between several contributors,
> ? implementation proposed. What do we do ?
>
> ? + proposal of Arnout to derive host dependencies from target
> ? ? dependencies.

Ack.

>
> ?* Per-package device files handling, proposed by Maxime Ripard.

Ack.

>
> ?* Testing infrastructure. Possible to put build results on the Web
> ? server ? Common format for them ?

At work we're using Jenkins. I haven't worked with buildbot.
I feel that re-using such a system is the way to go.
As others indicated, we'll need to define the configurations that'll
be built, and which build server(s) will be used.

>
> ?* Tracking of files installed by packages. Do we care ? Is this an
> ? important feature of Buildroot ? Won't the added complexity make
> ? Buildroot more complicated to understand ?
>
> ? Which solution ? Two solutions:
>
> ? ?- Change the installation steps of packages so that each package
> ? ? ?installs in a different directory.
>
> ? ? ?Pros:
>
> ? ? ? ?seems to be the cleanest solution.
>
> ? ? ? ?allows to easily detect packages overriding files installed by
> ? ? ? ?other packages.
>
> ? ? ?Cons:
>
> ? ? ? ?requires modifications of all gentargets packages to use
> ? ? ? ?$$(STAGING_DIR) and $$(TARGET_DIR) instead of $(STAGING_DIR)
> ? ? ? ?and $(TARGET_DIR).
>
> ? ? ? ?strange handling of host packages. DESTDIR isn't used, the
> ? ? ? ?prefix is the absolute path to HOST_DIR.
>
> ? ?- Keep installing package files in their normal directory, but
> ? ? ?detect new files and modified files.
>
> ? ? ?Pros:
>
> ? ? ? ?no need to change anything in the current package installation
> ? ? ? ?procedures.
>
> ? ? ?Cons:
>
> ? ? ? ?need to scan the TARGET_DIR, STAGING_DIR and HOST_DIR after
> ? ? ? ?every package installation.
>
> ? ? ? ?hard to detect modified/overwritten files, except by storing
> ? ? ? ?hashes of installed files.

I would like a feature that can list all files owned by a certain
package. It also facilitates to make a breakdown of the rootfs size.
Although I'm not currently using this, being able to upload a 'package
of a package' to the target and install it on the fly can be useful.
For example, you need to debug a certain problem but did not include a
debugger on target. Or you want to add a profiling tool because it
turns out that there is a performance problem in the field.

Gentoo uses a sandbox environment for installing each package. Access
by the installation phase outside of the sandbox is detected and
raises a sandbox violation. I haven't looked into the implementation
of this sandbox, but if we could reuse something like that, detecting
which files were added is very simple.
A sandbox seems like a clean solution as well, that (depending on the
implementation) wouldn't complicate buildroot too much.

>
> ?* Next big directions. What are the next big directions for Buildroot
> ? ? The major features we want to implement ?

This may not be a major feature, but nevertheless it crossed my mind:
I would like to see a document describing the recommended approach to
use buildroot to meet license requirements (such as GPL's) for systems
that have open-source software mixed with proprietary software.
For example, place a copy of all tarballs in the dl directory, copy
all proprietary software to the 'customize' package (even though
during development you use a 'real' buildroot package to build it),
... (or whatever the recommendation is).
We could provide a command that automates certain aspects of this,
e.g. 'make buildroot-tarball'.

Another item: external toolchain support of Buildroot toolchains: the
issue was raised that Buildroot toolchains are not relocatable, which
is problematic if you try using it as an external toolchain. Will we
fix this? Or will we give the recommendation to use crosstool-ng
instead for external toolchains?
What I like about the buildroot toolchains is that its build is
integrated in Buildroot. You don't have to get to know another tool
like crosstool-ng. You don't have to duplicate certain modifications
(like adding scp support for package downloads) in multiple places.


Best regards,
Thomas

[Buildroot] Some topics for the Buildroot Developer Day

[Robert Schwebel]

On Tue, Oct 25, 2011 at 09:15:09AM +0200, Peter Korsgaard wrote:
> Indeed. That's the same experience I have from all then
> 'randpackageconfig' builds. Making the issues public (and fixing what
> you can) is not a bad thing though.

Right - this is definitely something where the community can help.

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[Buildroot] Some topics for the Buildroot Developer Day

[Yegor Yefremov]

Am 24.10.2011 17:38, schrieb Thomas Petazzoni:
> Hello,
> 
> As discussed on IRC, I am posting below a list of topics that might be
> discussed during the developer day. Note that this is just _my_ list of
> topics, note the one of the Buildroot project as a whole. Moreover,
> it's very likely that not all topics will be covered during our meeting
> day. However, feel free to add your opinion and/or your additional
> topics, especially if you can't make it to the Developer day.

was such an issue as firmware support already discussed? There is such a repo 
http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git
containing firmware for a broad set of devices. If we could make an infrastructure for this repo it would be very easy to use it projects without a need to manually copy those files. What do you think about it?

Yegor

[Buildroot] Some topics for the Buildroot Developer Day

[Gustavo Zacarias]

On 26.10.2011 09:48, Yegor Yefremov wrote:

> was such an issue as firmware support already discussed? There is
> such a repo
> http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git
> containing firmware for a broad set of devices. If we could make an
> infrastructure for this repo it would be very easy to use it projects
> without a need to manually copy those files. What do you think about
> it?
>
> Yegor

There used to be release/snapshot tarballs in kernel.org before the 
debacle.
My $.02 is that we could just do it as a package with a huge option 
list for each firmware file(s) required for different drivers/devices.
I'd go for a smaller subset to begin with since there are firmware 
files for SAN controllers and other big iron stuff that probably are't 
the target for buildroot.
Regards.

[Buildroot] Some topics for the Buildroot Developer Day

[Thomas Petazzoni]

Le Wed, 26 Oct 2011 10:05:55 -0300,
Gustavo Zacarias <gustavo@zacarias.com.ar> a ?crit :

> My $.02 is that we could just do it as a package with a huge option 
> list for each firmware file(s) required for different drivers/devices.
> I'd go for a smaller subset to begin with since there are firmware 
> files for SAN controllers and other big iron stuff that probably
> are't the target for buildroot.

Or you put a single "string" option in which the user can pass a
space-separated list of firmware to install.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Some topics for the Buildroot Developer Day

[Gustavo Zacarias]

On 29.10.2011 03:20, Thomas Petazzoni wrote:

> Le Wed, 26 Oct 2011 10:05:55 -0300,
> Gustavo Zacarias <gustavo@zacarias.com.ar> a ?crit :
>
>> My $.02 is that we could just do it as a package with a huge option
>> list for each firmware file(s) required for different 
>> drivers/devices.
>> I'd go for a smaller subset to begin with since there are firmware
>> files for SAN controllers and other big iron stuff that probably
>> are't the target for buildroot.
>
> Or you put a single "string" option in which the user can pass a
> space-separated list of firmware to install.
>
> Thomas

That may be an extra option for yet undefined/new options, but i 
wouldn't go for that exclusively.
Some firmware consists of several files in a separate subdirectory.
For example zd1211rw firmware is in /lib/firmware/zd1211 and consists 
of the following files: zd1211_ub, zd1211_uphr, zd1211_ur, zd1211b_ub, 
zd1211_uphr and zd1211_ur.
It would be a stretch for the user to know every single piece of it 
which would make the option somewhat irrelevant at that point (he could 
just copy the files himself if he knows all of them).
Regards.

[Buildroot] Some topics for the Buildroot Developer Day

[Thomas Petazzoni]

Le Mon, 24 Oct 2011 17:38:15 +0200,
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> a ?crit :

> As discussed on IRC, I am posting below a list of topics that might be
> discussed during the developer day. Note that this is just _my_ list
> of topics, note the one of the Buildroot project as a whole. Moreover,
> it's very likely that not all topics will be covered during our
> meeting day. However, feel free to add your opinion and/or your
> additional topics, especially if you can't make it to the Developer
> day.

For information, the developer day took place on Saturday, as expected.
I am currently writing a detailed report of what has been said, it'll
be sent to the mailing list after review by other participants (in
order to make it as complete and accurate as possible). Hopefully
should be within this week.

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Some topics for the Buildroot Developer Day

[Thomas Petazzoni]

Le Wed, 26 Oct 2011 14:48:56 +0200,
Yegor Yefremov <yegor_sub1@visionsystems.de> a ?crit :

> was such an issue as firmware support already discussed? There is
> such a repo
> http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git
> containing firmware for a broad set of devices. If we could make an
> infrastructure for this repo it would be very easy to use it projects
> without a need to manually copy those files. What do you think about
> it?

I think it's a good idea, some of those firmwares are definitely needed
for some devices.

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com