[Buildroot] Buildroot developer meeting report

[Buildroot] Buildroot developer meeting report

[Arnout Vandecappelle]

 Hi all,

 As you will have noticed from the mailing list traffic, it's been a very busy
two days at the Buildroot developer meeting in Dublin. You can find the full
report at [1]. Here are the highlights:

- We have decided to proceed with starting a not-for-profit organisation. It
will be based in France. Maxime H. volunteered to get the ball rolling. The plan
is to prepare the statutes in the coming months and sign them at FOSDEM.

- 110 patches were committed, the patchwork queue has been reduced from 331 to
236 patches. We also discussed a few of the difficult patches and series that
are pending, though in fact there are still many more that warrant discussion.

- We decided how to proceed with the runtime testing. Nothing has been committed
yet, the a Jenkins instance is already running at [2].

- When discussing the idea of making .hash files mandatory for all packages, we
discovered that it looks like the tarballs generated automatically by github are
nowadays stable. We'll verify this by adding a couple of hashes for github
packages and check if the autobuilders survive.


 Regards,
 Arnout


[1] http://elinux.org/Buildroot:DeveloperDaysELCE2015#Report
[2] http://jenkins.free-electrons.com/job/buildroot-runtime-tests/
-- 
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] Buildroot developer meeting report

[Yann E. MORIN]

Hello All,

On 2015-10-04 23:47 +0100, Arnout Vandecappelle spake thusly:
>  As you will have noticed from the mailing list traffic, it's been a very busy
> two days at the Buildroot developer meeting in Dublin. You can find the full
> report at [1].
[--SNIP--]

As part of the discussions came the subject of supporting multiple
br2-external trees at once.

The proposal I sent earlier was deemed to introduce too much complexity,
and Peter suggested we do it with "a script that will generate a bunch
of symlinks into a single directory, and use that directory as the
traditional br2-external."

So, I've spent most of my spare time since then to try to implement that
proposal, and made quite some progress, up to the point that I believe
this is not a doable solution. Although it seems nice on paper, it is
broken by design.

For example, take those two br2-external trees as a simple example (only
interesting files are listed):

    br2-ext-1/
        external.mk
            include $(BR2_EXTERNAL)/foo/foo.mk
        foo/
            foo.mk
                blabla package stuff in here
            

    br2-ext-2/
        external.mk
            include $(BR2_EXTERNAL)/*/*.mk


Now, when we create the "shadow copy" full of symlinks, we inevitably
have to include those two external.mk files, because they may contain
more than include statements (like custom local rules, or custom macros,
or whatever; we always said that users were free to provide "even custom
configuration options and make logic" in there).


Now, since we're using a shadow copy, BR2_EXTERNAL at runtime will be
pointing to that shadow copy, so what happens in that case is that the
second external.mk will re-include foo/foo.mk

So far, this is not really a problem. Except we now want to ensure that
a package is not defined multiple times, to avoid a br2-external tree
redefining a package in Buildroot or in another br2-external tree.

But since foo/foo.mk is included twice, the second time will trigger the
re-definition check and we would abort.


There are not many solutions to this, but the more we try to fix this,
the more complex and fragile the code is getting. And worse, it would
inevitably break existing br2-external trees, which we are trying hard
to keep working without modification to those.


So, I'm calling the symlink (or "shadow copy") solution a dead-end out of
which I can't see an easy path.


Input most welcome.

Regards,
Yann E. MORIN.


-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] Buildroot developer meeting report

[Arnout Vandecappelle]

 Hi all,

 Just before ELC-E in Duesseldorf, on October 11 and 12, we had a Buildroot
Developer Meeting (sponsored by Mind, yay!). You can find the report on the wiki:

http://elinux.org/Buildroot:DeveloperDaysELCE2014#Discussion_topics_and_report


 Some highlights:

* We mainly used this time to clean up patchwork. We didn't keep exact
statistics, but the number of patches was reduced from roughly 350 to roughly
250, and a significant number of patches have been reviewed and/or reposted.

* There were a few important large series that were discussed and eventually
applied.

* We have taken a decision on how to deal with atomic operations, with missing
license files, with march/mcpu/mtune conflicts, and we have decided to leave the
package name out of patch file names. Some of these things have been
implemented, some are still to do.

* We discussed the GSoC project which wasn't successful this year. We'll try
again next year.


 If there is any further point of discussion or a conclusion that you don't
agree with, feel free to start a discussion here on the list or on IRC.


 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:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] Buildroot developer meeting report

[Doug Kehn]

Hi Arnout, Everyone,
I'm new to Buildroot and have been evaluating it along with Yocto to replace uClinux/home-brew environment for a new design. ?I noticed in the 'Discussion_topics_and_report' that there was an evaluation of BR2_EXTERNAL. ?Was it determined what was needed? ?I hope this wasn't a foreshadowing that BR2_EXTERNAL might be deprecated.
As part of my evaluation, I created a 'doug' directory and mimicked the Buildroot?directory structure as needed. ?All my custom bits were confined to this directory; I didn't pollute the Buildroot tree with irrelevant changes. ?I then use BR2_EXTERNAL to point to 'doug'. ?For example,
make BR2_EXTERNAL=doug [defconfig]
set up the environment to point to all the proper locations. ?BR2_EXTERNAL, as is, is a very nice feature!
Thanks and regards,...doug(Doug Kehn) 

     On Wednesday, October 22, 2014 7:56 AM, Arnout Vandecappelle <arnout@mind.be> wrote:
   

  Hi all,

 Just before ELC-E in Duesseldorf, on October 11 and 12, we had a Buildroot
Developer Meeting (sponsored by Mind, yay!). You can find the report on the wiki:

http://elinux.org/Buildroot:DeveloperDaysELCE2014#Discussion_topics_and_report


 Some highlights:

* We mainly used this time to clean up patchwork. We didn't keep exact
statistics, but the number of patches was reduced from roughly 350 to roughly
250, and a significant number of patches have been reviewed and/or reposted.

* There were a few important large series that were discussed and eventually
applied.

* We have taken a decision on how to deal with atomic operations, with missing
license files, with march/mcpu/mtune conflicts, and we have decided to leave the
package name out of patch file names. Some of these things have been
implemented, some are still to do.

* We discussed the GSoC project which wasn't successful this year. We'll try
again next year.


 If there is any further point of discussion or a conclusion that you don't
agree with, feel free to start a discussion here on the list or on IRC.


 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:? 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot


   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20141024/a731637d/attachment.html>

[Buildroot] Buildroot developer meeting report

[Yann E. MORIN]

Doug, All,

On 2014-10-24 19:32 +0000, Doug Kehn spake thusly:
> Hi Arnout, Everyone,
> I'm new to Buildroot and have been evaluating it along with Yocto to replace uClinux/home-brew environment for a new design.  I
> noticed in the 'Discussion_topics_and_report' that there was an evaluation of BR2_EXTERNAL.  Was it determined what was needed?  I
> hope this wasn't a foreshadowing that BR2_EXTERNAL might be deprecated.

No, BR2_EXTERNAL is not deprecated at all. It is a relatively new
feature, and at the previous developpers days, some users expressed some
concerns about some behaviour of BR2_EXTERNAL, because it was new at
that time.

Since those concerns were unfounded, so the topic was only briefly
skimmed over in D?sseldorf, and the conclusion was that "everything is
OK".

So, you can count on BR2_EXTERNAL for the foreseeable future. :-)

> As part of my evaluation, I created a 'doug' directory and mimicked the Buildroot directory structure as needed.  All my custom bits
> were confined to this directory; I didn't pollute the Buildroot tree with irrelevant changes.  I then use BR2_EXTERNAL to point to
> 'doug'.  For example,
> make BR2_EXTERNAL=doug [defconfig]
> set up the environment to point to all the proper locations.  BR2_EXTERNAL, as is, is a very nice feature!

Yup, that's how it is expected to be used. Nice to see you like it! :-)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] Buildroot developer meeting report

[Matthew Weber]

All,
On Oct 22, 2014 7:56 AM, "Arnout Vandecappelle" <arnout@mind.be> wrote:
>
>  Hi all,
>
>  Just before ELC-E in Duesseldorf, on October 11 and 12, we had a
Buildroot
> Developer Meeting (sponsored by Mind, yay!). You can find the report on
the wiki:
>
>
http://elinux.org/Buildroot:DeveloperDaysELCE2014#Discussion_topics_and_report
>
>
>  Some highlights:
>
> * We mainly used this time to clean up patchwork. We didn't keep exact
> statistics, but the number of patches was reduced from roughly 350 to
roughly
> 250, and a significant number of patches have been reviewed and/or
reposted.
>
> * There were a few important large series that were discussed and
eventually
> applied.
>
> * We have taken a decision on how to deal with atomic operations, with
missing

Related to atomics, has anyone looked at creating a patchset for those
updates?  If not, I'll take a look and put together a draft.  I think I've
got a pretty good idea of changes based on the developer meeting mins.

Thanks,
Matt

<snip>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20141230/d3b5e44f/attachment.html>