[Buildroot] Topics to discuss at the meeting

[Buildroot] Topics to discuss at the meeting

[Thomas Petazzoni]

Hello,

The meeting is approaching, so to foster some preliminary discussion,
here is the current list of topics we have in the Wiki:

 - Look-back to action points from previous developer days at Fosdem
   2014: is everything that was decided done? What remains?

 - Patch naming: current convention is
   package-number-description.patch, but a proposal was made on the
   list to simplify this to number-description.patch. Go or no-go?

 - Since Luca will be present: state of legal-info infrastructure,
   improvements to be made?

   - Could more details be added here (by Thomas DS, who proposed the
     topic)

 - Discussion on atomic operations and how to handle the related
   dependencies at the kconfig level

 - Cleanup the patchwork; triage patches in two categories:

   - things that hasn't been pushed enough but that we believe is useful

   - things that haven't been pushed enough and that are too anecdotic
     for us to care about

 - Pending large series:

   - The paranoid wrapper series from Thomas P.
   - The march/mcpu conflict on ARM series from Thomas P.
   - The Qemu series from Yann
   - The freerdp series from Yann
   - The NVidia series from Yann
   - The OpenCV series from Samuel
   - The apr-util/apache series from Bernd
   - The gendoc series from Yann (IMPORTANT)
   - The X.org/i.MX6 series from J?r?me
   - The libudev series from Yann (IMPORTANT)

 - Key-signing party: it would be usefull to have a web-of-trust
   amongst Buildroot developpers, to submit sensitive information, such
   as the hashes.

 - Project maintenance:

   - Peter seems to be less active now

   - Thomas (who acts as deputy committer) has new responsibilities,
     and risks being less available too

  - How do we see the short- and long-term maintenance of the project?

 - Should we move buildroot.org to its own server, and split from
   busybox.net and uclibc.org?

Feel free to comment on these topics, or add new ones. For those who
have an account, do not hesitate to update the Wiki accordingly.

Thanks,

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

[Buildroot] Topics to discuss at the meeting

[Yegor Yefremov]

On Wed, Oct 8, 2014 at 10:56 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> The meeting is approaching, so to foster some preliminary discussion,
> here is the current list of topics we have in the Wiki:
>
>  - Look-back to action points from previous developer days at Fosdem
>    2014: is everything that was decided done? What remains?
>
>  - Patch naming: current convention is
>    package-number-description.patch, but a proposal was made on the
>    list to simplify this to number-description.patch. Go or no-go?
>
>  - Since Luca will be present: state of legal-info infrastructure,
>    improvements to be made?
>
>    - Could more details be added here (by Thomas DS, who proposed the
>      topic)
>
>  - Discussion on atomic operations and how to handle the related
>    dependencies at the kconfig level
>
>  - Cleanup the patchwork; triage patches in two categories:
>
>    - things that hasn't been pushed enough but that we believe is useful
>
>    - things that haven't been pushed enough and that are too anecdotic
>      for us to care about
>
>  - Pending large series:
>
>    - The paranoid wrapper series from Thomas P.
>    - The march/mcpu conflict on ARM series from Thomas P.
>    - The Qemu series from Yann
>    - The freerdp series from Yann
>    - The NVidia series from Yann
>    - The OpenCV series from Samuel
>    - The apr-util/apache series from Bernd
>    - The gendoc series from Yann (IMPORTANT)
>    - The X.org/i.MX6 series from J?r?me
>    - The libudev series from Yann (IMPORTANT)
>
>  - Key-signing party: it would be usefull to have a web-of-trust
>    amongst Buildroot developpers, to submit sensitive information, such
>    as the hashes.
>
>  - Project maintenance:
>
>    - Peter seems to be less active now
>
>    - Thomas (who acts as deputy committer) has new responsibilities,
>      and risks being less available too
>
>   - How do we see the short- and long-term maintenance of the project?
>
>  - Should we move buildroot.org to its own server, and split from
>    busybox.net and uclibc.org?
>
> Feel free to comment on these topics, or add new ones. For those who
> have an account, do not hesitate to update the Wiki accordingly.

Could we add FIT topic? Basic creation and installation is already
implemented (http://patchwork.ozlabs.org/patch/396240/). The bigger
part is to control the priorities when and what step should be taken
first: at fist cpio and then fit, first fit and then ext2 etc.
I doubt, that ROOTFS_$(FSTYPE)_PRE_GEN_HOOKS and
ROOTFS_$(FSTYPE)_POST_TARGETS will help here.

Yegor

[Buildroot] Topics to discuss at the meeting

[Thomas Petazzoni]

Dear Yegor Yefremov,

On Wed, 8 Oct 2014 11:10:25 +0200, Yegor Yefremov wrote:

> > Feel free to comment on these topics, or add new ones. For those who
> > have an account, do not hesitate to update the Wiki accordingly.
> 
> Could we add FIT topic? Basic creation and installation is already
> implemented (http://patchwork.ozlabs.org/patch/396240/). The bigger
> part is to control the priorities when and what step should be taken
> first: at fist cpio and then fit, first fit and then ext2 etc.
> I doubt, that ROOTFS_$(FSTYPE)_PRE_GEN_HOOKS and
> ROOTFS_$(FSTYPE)_POST_TARGETS will help here.

Sure. However, the two persons having expressed some knowledge about
FIT are you and Thomas DS, and none of you will be at the meeting.

Could you give some examples about the two cases you have (cpio and
ext2) and how they cause issues with the current Buildroot? I
understand it's a build ordering problem, but I'd like to understand
better the use cases of FIT to see how we can solve this.

Thanks!

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

[Buildroot] Topics to discuss at the meeting

[Yegor Yefremov]

On Wed, Oct 8, 2014 at 6:13 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Yegor Yefremov,
>
> On Wed, 8 Oct 2014 11:10:25 +0200, Yegor Yefremov wrote:
>
>> > Feel free to comment on these topics, or add new ones. For those who
>> > have an account, do not hesitate to update the Wiki accordingly.
>>
>> Could we add FIT topic? Basic creation and installation is already
>> implemented (http://patchwork.ozlabs.org/patch/396240/). The bigger
>> part is to control the priorities when and what step should be taken
>> first: at fist cpio and then fit, first fit and then ext2 etc.
>> I doubt, that ROOTFS_$(FSTYPE)_PRE_GEN_HOOKS and
>> ROOTFS_$(FSTYPE)_POST_TARGETS will help here.
>
> Sure. However, the two persons having expressed some knowledge about
> FIT are you and Thomas DS, and none of you will be at the meeting.
>
> Could you give some examples about the two cases you have (cpio and
> ext2) and how they cause issues with the current Buildroot? I
> understand it's a build ordering problem, but I'd like to understand
> better the use cases of FIT to see how we can solve this.

I've added FIT topic to the TODO list on elinux.org:
http://elinux.org/Buildroot#Core_Buildroot_infrastructure

Yegor

[Buildroot] Topics to discuss at the meeting

[Thomas Petazzoni]

Dear Yegor Yefremov,

On Fri, 10 Oct 2014 09:41:57 +0200, Yegor Yefremov wrote:

> > Sure. However, the two persons having expressed some knowledge about
> > FIT are you and Thomas DS, and none of you will be at the meeting.
> >
> > Could you give some examples about the two cases you have (cpio and
> > ext2) and how they cause issues with the current Buildroot? I
> > understand it's a build ordering problem, but I'd like to understand
> > better the use cases of FIT to see how we can solve this.
> 
> I've added FIT topic to the TODO list on elinux.org:
> http://elinux.org/Buildroot#Core_Buildroot_infrastructure

Well, if you want the FIT topic to be discussed during the meeting,
that's not the right place. The right place is
http://elinux.org/Buildroot:DeveloperDaysELCE2014, which is the page
dedicated to the meeting.

Thanks,

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

[Buildroot] Topics to discuss at the meeting

[Thomas De Schampheleire]

Hi Thomas,

On Wed, Oct 8, 2014 at 10:56 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> The meeting is approaching, so to foster some preliminary discussion,
> here is the current list of topics we have in the Wiki:
>
>  - Look-back to action points from previous developer days at Fosdem
>    2014: is everything that was decided done? What remains?
>
>  - Patch naming: current convention is
>    package-number-description.patch, but a proposal was made on the
>    list to simplify this to number-description.patch. Go or no-go?
>
>  - Since Luca will be present: state of legal-info infrastructure,
>    improvements to be made?
>
>    - Could more details be added here (by Thomas DS, who proposed the
>      topic)

I thought, with Luca being present again after a few years, it would
be a good idea to briefly see what may need to be improved / added to
the legal-info infrastructure. Is there anything missing,
feature-wise?

There was a proposal to add the site URL to the manifest, but this has
been merged meanwhile.
We could consider improving the handling of the currently unhandled
parts, like toolchain, buildroot itself, ...

For toolchain, even if it is difficult to save the sources, we could
consider identifying the packages contained in the toolchain, like
which C library, compiler, etc. and provide version and license for
each of them. This info could then be collected in the manifest as
well. This should include info on the target files, like libstdc++,
libgcc, ...

Also, to me it would make sense to place the code related to
legal-info in one file, like legal-info.mk. Currently there are parts
in Makefile, pkg-utils.mk and pkg-generic.mk. While pkg-generic can
stay as it is, the lines from Makefile and pkg-utils.mk could be
extracted to a single, separate file IMO.

Looking at the package stats:
Packages having license information 1298
Packages not having licence information 73
Packages having license files information 1219
Packages not having licence files information 152

So at that level we're pretty good, but ideally we can get these
second and fourth counters to 0.


Best regards,
Thomas

[Buildroot] Topics to discuss at the meeting

[Thomas Petazzoni]

Dear Thomas De Schampheleire,

On Wed, 8 Oct 2014 13:56:56 +0200, Thomas De Schampheleire wrote:

> I thought, with Luca being present again after a few years, it would
> be a good idea to briefly see what may need to be improved / added to
> the legal-info infrastructure. Is there anything missing,
> feature-wise?

Well, if no-one asks for any feature, there's nothing missing,
right ? :-)

> For toolchain, even if it is difficult to save the sources, we could
> consider identifying the packages contained in the toolchain, like
> which C library, compiler, etc. and provide version and license for
> each of them. This info could then be collected in the manifest as
> well. This should include info on the target files, like libstdc++,
> libgcc, ...

I guess you're talking about the external toolchains, right?

Then yes, we need to do something about it, but I don't think there's a
need to identify the C library, compiler and so on. Most of the
external toolchain providers already provide a tarball of the sources
they use to build the toolchain. At least that's the case for Sourcery
CodeBench toolchains and Linaro toolchains. But I'm not sure how to
integrate this with the licensing infrastructure, which assumes that
what each package downloads is already the source code.

Certainly something we can discuss with Luca during the meeting.

> Also, to me it would make sense to place the code related to
> legal-info in one file, like legal-info.mk. Currently there are parts
> in Makefile, pkg-utils.mk and pkg-generic.mk. While pkg-generic can
> stay as it is, the lines from Makefile and pkg-utils.mk could be
> extracted to a single, separate file IMO.

Right. Generally speaking, I'd like the main Makefile to reduce in
size, by moving "specific" things in other places, in a more organized
way.

> Looking at the package stats:
> Packages having license information 1298
> Packages not having licence information 73
> Packages having license files information 1219
> Packages not having licence files information 152
> 
> So at that level we're pretty good, but ideally we can get these
> second and fourth counters to 0.

For the second, yes. For the fourth, there's unfortunately an issue: we
don't distinguish packages for which we haven't yet filled the license
files information from the packages we already had a look at, and for
which unfortunately there isn't a file containing the license text. So
it's hard to go to 0 for the fourth counter, because some packages
simply do not have a license text built-in. What do we do for those
packages? Add the license text in package/<foo>/ and copy it to the
source tree as a post-extract hook ?

Best regards,

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

[Buildroot] Topics to discuss at the meeting

[Thomas De Schampheleire]

On Wed, Oct 8, 2014 at 6:12 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Thomas De Schampheleire,
>
> On Wed, 8 Oct 2014 13:56:56 +0200, Thomas De Schampheleire wrote:
>
>> I thought, with Luca being present again after a few years, it would
>> be a good idea to briefly see what may need to be improved / added to
>> the legal-info infrastructure. Is there anything missing,
>> feature-wise?
>
> Well, if no-one asks for any feature, there's nothing missing,
> right ? :-)
>
>> For toolchain, even if it is difficult to save the sources, we could
>> consider identifying the packages contained in the toolchain, like
>> which C library, compiler, etc. and provide version and license for
>> each of them. This info could then be collected in the manifest as
>> well. This should include info on the target files, like libstdc++,
>> libgcc, ...
>
> I guess you're talking about the external toolchains, right?

Yes indeed.

>
> Then yes, we need to do something about it, but I don't think there's a
> need to identify the C library, compiler and so on. Most of the
> external toolchain providers already provide a tarball of the sources
> they use to build the toolchain. At least that's the case for Sourcery
> CodeBench toolchains and Linaro toolchains. But I'm not sure how to
> integrate this with the licensing infrastructure, which assumes that
> what each package downloads is already the source code.

Sources are one thing, the manifest is the other. Both are pretty
independent. Even if you find some way of obtaining the sources for
the external toolchain, you still have to list the components used in
the manifest. For a toolchain, some components are host components
(the actual compiler, linker etc.) and some are target components,
like the C library, C++ library, libgcc, etc. Each of these have a
license, version etc.

>
> Certainly something we can discuss with Luca during the meeting.
>
>> Also, to me it would make sense to place the code related to
>> legal-info in one file, like legal-info.mk. Currently there are parts
>> in Makefile, pkg-utils.mk and pkg-generic.mk. While pkg-generic can
>> stay as it is, the lines from Makefile and pkg-utils.mk could be
>> extracted to a single, separate file IMO.
>
> Right. Generally speaking, I'd like the main Makefile to reduce in
> size, by moving "specific" things in other places, in a more organized
> way.
>
>> Looking at the package stats:
>> Packages having license information 1298
>> Packages not having licence information 73
>> Packages having license files information 1219
>> Packages not having licence files information 152
>>
>> So at that level we're pretty good, but ideally we can get these
>> second and fourth counters to 0.
>
> For the second, yes. For the fourth, there's unfortunately an issue: we
> don't distinguish packages for which we haven't yet filled the license
> files information from the packages we already had a look at, and for
> which unfortunately there isn't a file containing the license text. So
> it's hard to go to 0 for the fourth counter, because some packages
> simply do not have a license text built-in. What do we do for those
> packages? Add the license text in package/<foo>/ and copy it to the
> source tree as a post-extract hook ?

To be correct, this should be reported and fixed upstream.
In the meantime, adding the license to buildroot seems a bit odd.
Rather I would mark the package with some magic string (like
'(missing)' that indicates that the license text is missing. However,
I vaguely recall that we discussed that before, and that not everyone
was agreeing with such a magic string.

Best regards,
Thomas

[Buildroot] Topics to discuss at the meeting

[Thomas Petazzoni]

Dear Thomas De Schampheleire,

On Fri, 10 Oct 2014 11:50:56 +0200, Thomas De Schampheleire wrote:

> > Then yes, we need to do something about it, but I don't think there's a
> > need to identify the C library, compiler and so on. Most of the
> > external toolchain providers already provide a tarball of the sources
> > they use to build the toolchain. At least that's the case for Sourcery
> > CodeBench toolchains and Linaro toolchains. But I'm not sure how to
> > integrate this with the licensing infrastructure, which assumes that
> > what each package downloads is already the source code.
> 
> Sources are one thing, the manifest is the other. Both are pretty
> independent. Even if you find some way of obtaining the sources for
> the external toolchain, you still have to list the components used in
> the manifest. For a toolchain, some components are host components
> (the actual compiler, linker etc.) and some are target components,
> like the C library, C++ library, libgcc, etc. Each of these have a
> license, version etc.

Right, not easy. Something to be discussed at the meeting maybe, even
though I'd like to avoid long and unproductive discussions if
possible :-)

> To be correct, this should be reported and fixed upstream.

Except that in many cases, those packages not having any license files
are old, not really maintained packages, where upstream is close to
dead.

> In the meantime, adding the license to buildroot seems a bit odd.
> Rather I would mark the package with some magic string (like
> '(missing)' that indicates that the license text is missing. However,
> I vaguely recall that we discussed that before, and that not everyone
> was agreeing with such a magic string.

Did we discuss that in the past? I believe it would be a good idea, as
we allow us to distinguish the cases where we have already done some
inspection and concluded that there is really no license from the cases
where the license files information hasn't been added. Though it's true
that in general, when <pkg>_LICENSE is mentioned but not
<pkg>_LICENSE_FILES, it's already an indication that the license
information has been inspected and that the conclusion was that there
was no license file available.

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

[Buildroot] Topics to discuss at the meeting

[Luca Ceresoli]

Dear Thomas,

we discussed your proposals yesterday. You can see the final decisions
on the Etherpad (https://etherpad.fr/p/Izjy5fFsA4). I'll take care of
sending patches to implement the planned changes.

Some more comments below.

Thomas De Schampheleire wrote:
> Hi Thomas,
>
> On Wed, Oct 8, 2014 at 10:56 AM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
>> Hello,
>>
>> The meeting is approaching, so to foster some preliminary discussion,
>> here is the current list of topics we have in the Wiki:
>>
>>   - Look-back to action points from previous developer days at Fosdem
>>     2014: is everything that was decided done? What remains?
>>
>>   - Patch naming: current convention is
>>     package-number-description.patch, but a proposal was made on the
>>     list to simplify this to number-description.patch. Go or no-go?
>>
>>   - Since Luca will be present: state of legal-info infrastructure,
>>     improvements to be made?
>>
>>     - Could more details be added here (by Thomas DS, who proposed the
>>       topic)
>
> I thought, with Luca being present again after a few years, it would
> be a good idea to briefly see what may need to be improved / added to
> the legal-info infrastructure. Is there anything missing,
> feature-wise?
>
> There was a proposal to add the site URL to the manifest, but this has
> been merged meanwhile.
> We could consider improving the handling of the currently unhandled
> parts, like toolchain, buildroot itself, ...
>
> For toolchain, even if it is difficult to save the sources, we could
> consider identifying the packages contained in the toolchain, like
> which C library, compiler, etc. and provide version and license for
> each of them. This info could then be collected in the manifest as
> well. This should include info on the target files, like libstdc++,
> libgcc, ...

For the _LICENSE text, the infra already allows to state the license of
the external toolchain as a long string ("GPL (this), LGPL (that),
..."). This allows to add licenses without any addition to the
infrastructure, so we'll go that way. The ultimate goal is to provide
the info to our users without making Buildroot more complex.

Providing the source tarballs cannot be made "for free" as of now,
because the downloaded _SOURCE for the ext-toolchains is a binary.
But usually toolchain providers also provide a source tarball for
download, so that's the URL we'd like to have in the legal-info
manifest and download.

To meet that goal we evaluated two solutions:
  1. add a FOO_DONT_ADD_TO_LEGAL_MANIFEST (or any better name!),
     so the package can call legal-manifest its own, and
     download the actual source file on its own;
  2. add a FOO_ACTUAL_SOURCES (ditto) that, if defined, forces the
     legal infra to write that URL in the manifes, and download that
     URL to be store in the tarball directory instead of the FOO_SOURCE
     tarball.

We chose option 2.

>
> Also, to me it would make sense to place the code related to
> legal-info in one file, like legal-info.mk. Currently there are parts
> in Makefile, pkg-utils.mk and pkg-generic.mk. While pkg-generic can
> stay as it is, the lines from Makefile and pkg-utils.mk could be
> extracted to a single, separate file IMO.

We thought a little bit about this, and it looked like not enough code
to justify the creation of a new file.

-- 
Luca

[Buildroot] Topics to discuss at the meeting

[Matthew Weber]

I'm unable to listen to the discussion this weekend, but I'd be curious
where discussions on atomic operations go.
On Oct 8, 2014 3:57 AM, "Thomas Petazzoni" <
thomas.petazzoni@free-electrons.com> wrote:

> Hello,
>
> The meeting is approaching, so to foster some preliminary discussion,
> here is the current list of topics we have in the Wiki:
>
>  - Look-back to action points from previous developer days at Fosdem
>    2014: is everything that was decided done? What remains?
>
>  - Patch naming: current convention is
>    package-number-description.patch, but a proposal was made on the
>    list to simplify this to number-description.patch. Go or no-go?
>
>  - Since Luca will be present: state of legal-info infrastructure,
>    improvements to be made?
>
>    - Could more details be added here (by Thomas DS, who proposed the
>      topic)
>
>  - Discussion on atomic operations and how to handle the related
>    dependencies at the kconfig level
>
>  - Cleanup the patchwork; triage patches in two categories:
>
>    - things that hasn't been pushed enough but that we believe is useful
>
>    - things that haven't been pushed enough and that are too anecdotic
>      for us to care about
>
>  - Pending large series:
>
>    - The paranoid wrapper series from Thomas P.
>    - The march/mcpu conflict on ARM series from Thomas P.
>    - The Qemu series from Yann
>    - The freerdp series from Yann
>    - The NVidia series from Yann
>    - The OpenCV series from Samuel
>    - The apr-util/apache series from Bernd
>    - The gendoc series from Yann (IMPORTANT)
>    - The X.org/i.MX6 series from J?r?me
>    - The libudev series from Yann (IMPORTANT)
>
>  - Key-signing party: it would be usefull to have a web-of-trust
>    amongst Buildroot developpers, to submit sensitive information, such
>    as the hashes.
>
>  - Project maintenance:
>
>    - Peter seems to be less active now
>
>    - Thomas (who acts as deputy committer) has new responsibilities,
>      and risks being less available too
>
>   - How do we see the short- and long-term maintenance of the project?
>
>  - Should we move buildroot.org to its own server, and split from
>    busybox.net and uclibc.org?
>
> Feel free to comment on these topics, or add new ones. For those who
> have an account, do not hesitate to update the Wiki accordingly.
>
> Thanks,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
> _______________________________________________
> 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/20141012/b9402fb1/attachment.html>