[Buildroot] Next Buildroot Developers Meeting approaching

[Buildroot] Next Buildroot Developers Meeting approaching

[Thomas Petazzoni]

Hello,

Our next Buildroot Developers Meeting will take place on October 14-16
in Berlin, so the date is approaching.

We know have 10 participants registered: 8 attending all three days, 1
attending only 2 days, and one attending only one day.

More details:

  http://elinux.org/Buildroot:DeveloperDaysELCE2016

It's time to think about discussion and development topics. Even
contributors not attending the meeting can suggest some topics. During
the meeting we will be available on IRC and can organize live Google
Hangout discussions with remote participants if there is interest.

On my side, I think I'd like to spend a significant part of the 3 days
working on the testing infrastructure. But to do so, I'd like to team
up with someone present during the Developers Meeting. If someone is
interested, let me know.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] Next Buildroot Developers Meeting approaching

[Arnout Vandecappelle]

On 03-10-16 23:40, Thomas Petazzoni wrote:
> Hello,
> 
> Our next Buildroot Developers Meeting will take place on October 14-16
> in Berlin, so the date is approaching.

 I'm happy to announce that Mind will sponsor the Friday night dinner.

 We would still like a sponsor for the location, and it would also be nice if we
could get T-shirts for the participants. So if you think your employer would be
willing, please get in touch!


> We know have 10 participants registered: 8 attending all three days, 1
> attending only 2 days, and one attending only one day.
> 
> More details:
> 
>   http://elinux.org/Buildroot:DeveloperDaysELCE2016
> 
> It's time to think about discussion and development topics. Even
> contributors not attending the meeting can suggest some topics. During
> the meeting we will be available on IRC and can organize live Google
> Hangout discussions with remote participants if there is interest.
> 
> On my side, I think I'd like to spend a significant part of the 3 days
> working on the testing infrastructure. But to do so, I'd like to team
> up with someone present during the Developers Meeting. If someone is
> interested, let me know.

 I'm interested!

 I think there are in fact three completely different testing enhancements we
should consider:

1. Run-time testing, e.g. of the autobuilder artefacts.

2. Feature testing of Buildroot features, like BR2_EXTERNAL, umask handling,
graph-depends, etc.

3. Extending the existing autobuilders with kernel and bootloader builds.

 I guess you would concentrate on 1. I would love to work on 2, but I'm not so
efficient so perhaps my time is better spent on reviewing + looking over your
shoulder.


 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] Next Buildroot Developers Meeting approaching

[Thomas Petazzoni]

Hello,

On Thu, 6 Oct 2016 00:26:26 +0200, Arnout Vandecappelle wrote:

> > Our next Buildroot Developers Meeting will take place on October 14-16
> > in Berlin, so the date is approaching.  
> 
>  I'm happy to announce that Mind will sponsor the Friday night dinner.

Awesome!

Thanks to Mind for this sponsoring!

>  We would still like a sponsor for the location, and it would also be nice if we
> could get T-shirts for the participants. So if you think your employer would be
> willing, please get in touch!

I've asked my employer, but I believe it will be much easier to get
funding once we have a legal entity and the associated bank account.

> > On my side, I think I'd like to spend a significant part of the 3 days
> > working on the testing infrastructure. But to do so, I'd like to team
> > up with someone present during the Developers Meeting. If someone is
> > interested, let me know.  
> 
>  I'm interested!
> 
>  I think there are in fact three completely different testing enhancements we
> should consider:
> 
> 1. Run-time testing, e.g. of the autobuilder artefacts.

Testing the autobuilder artefacts do not make sense. A large number of
the configurations we build do not make any sense to test at runtime.
Just a quick example: we allow building both Dropbear and OpenSSH in
the same image. What happens when you boot: two daemons try to bind on
port 22. Same thing with web servers for example.

So I don't think runtime testing the autobuilder artefacts makes sense.

However, what makes sense is to runtime test a set of configurations
that we define, and progressively extend to cover more and more cases.

> 2. Feature testing of Buildroot features, like BR2_EXTERNAL, umask handling,
> graph-depends, etc.

To me (1) and (2) is basically the same thing. The infrastructure I
have proposed at https://github.com/tpetazzoni/buildroot-runtime-test
handles both things:

 - runtime testing of generated images
 - testing Buildroot features (filesystem images, for example)

> 3. Extending the existing autobuilders with kernel and bootloader builds.

With the above infrastructure, you can add test cases to build the
kernel on various architectures, build various bootloaders in a number
of configurations, etc.

>  I guess you would concentrate on 1. I would love to work on 2, but I'm not so
> efficient so perhaps my time is better spent on reviewing + looking over your
> shoulder.

I'm still undecided on what's the right tool for the job. The
infrastructure I've proposed in the Github repository mentioned above
has some annoying shortcomings, which I'm not sure how to address.

Maybe this is something Luca has more experience with?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] Next Buildroot Developers Meeting approaching

[Luca Ceresoli]

Dear Thomas, Arnout,

On 06/10/2016 17:04, Thomas Petazzoni wrote:
[...]
>>> On my side, I think I'd like to spend a significant part of the 3 days
>>> working on the testing infrastructure. But to do so, I'd like to team
>>> up with someone present during the Developers Meeting. If someone is
>>> interested, let me know.  
>>
>>  I'm interested!

And I am too!

>>  I think there are in fact three completely different testing enhancements we
>> should consider:
>>
>> 1. Run-time testing, e.g. of the autobuilder artefacts.
> 
> Testing the autobuilder artefacts do not make sense. A large number of
> the configurations we build do not make any sense to test at runtime.
> Just a quick example: we allow building both Dropbear and OpenSSH in
> the same image. What happens when you boot: two daemons try to bind on
> port 22. Same thing with web servers for example.
> 
> So I don't think runtime testing the autobuilder artefacts makes sense.
> 
> However, what makes sense is to runtime test a set of configurations
> that we define, and progressively extend to cover more and more cases.
> 
>> 2. Feature testing of Buildroot features, like BR2_EXTERNAL, umask handling,
>> graph-depends, etc.
> 
> To me (1) and (2) is basically the same thing. The infrastructure I
> have proposed at https://github.com/tpetazzoni/buildroot-runtime-test
> handles both things:
> 
>  - runtime testing of generated images
>  - testing Buildroot features (filesystem images, for example)
> 
>> 3. Extending the existing autobuilders with kernel and bootloader builds.
> 
> With the above infrastructure, you can add test cases to build the
> kernel on various architectures, build various bootloaders in a number
> of configurations, etc.
> 
>>  I guess you would concentrate on 1. I would love to work on 2, but I'm not so
>> efficient so perhaps my time is better spent on reviewing + looking over your
>> shoulder.
> 
> I'm still undecided on what's the right tool for the job. The
> infrastructure I've proposed in the Github repository mentioned above
> has some annoying shortcomings, which I'm not sure how to address.
> 
> Maybe this is something Luca has more experience with?

Probably not much, sorry. But I don't remember in detail the work you
did. I'll try to refresh my memory before the meeting.

-- 
Luca