[Buildroot] Patchwork cleanup #8: submitter notification

[Buildroot] Patchwork cleanup #8: submitter notification

[Thomas De Schampheleire]

People in To,

The buildroot community is trying to clean up the backlog of unhandled
patches sent to the mailing list (logged in patchwork [1]). We are
starting from the oldest patches and working our way up towards the
present.

In this mail, one or more patches you sent to the buildroot list are
put in one of four categories:
A. to be refreshed and resent to the list
B. rejected
C. we're unsure, your feedback is requested
D. more thorough changes needed instead of the current patch

If one of your patches falls into category A, it will be added to the
buildroot todo list, meaning that someone will eventually take the
time to refresh and resend the patch. However, if you can spare some
time to do it yourself, then this will greatly accelerate the
inclusion of your patch in buildroot.

If one of your patches falls into category B, you can either accept
the reasons given, or you may disagree in which case we invite you to
discuss the matter with us. In this case, please explain why you think
the patch should still be accepted.

If one of your patches falls into category C, please provide more
feedback. For some patches, our question to you may be if you are
still interested in getting this patch in buildroot or not. Other
patches may be in this category because we don't fully understand its
purpose (yet). Your feedback will help us in making the right choice.

If one of your patches falls into category D, the buildroot developers
accept the problem that the patch is addressing, but believe it should
be fixed in a different way, possibly requiring some changes in the
buildroot core infrastructure.

We propose a two-week period to give you some time to respond with
your feedback.

For this cleanup session, here are the patches:

[RFC,5/7] python-linaro-dashboard-
bundle: new package
ludovic.desroches at atmel.com
http://patchwork.ozlabs.org/patch/282728

[RFC,6/7] lava-tool: new package
ludovic.desroches at atmel.com
http://patchwork.ozlabs.org/patch/282729

[RFC,7/7] lava-test: new package
ludovic.desroches at atmel.com
http://patchwork.ozlabs.org/patch/282730

Ludovic said he would revise/retest/resubmit these patches, also
taking into account the new python-package infrastructure. The patches
are thus marked as Changes Requested in patchwork.


package/makedevs: add "l" type for symlinks ownership change
angelo dureghello <angelo70@gmail.com>
http://patchwork.ozlabs.org/patch/283015

C unsure: Angelo: could you describe in more detail if you are still
using this patch, and why you need it? How come the symbolic link does
not have the right ownership from the start?


[v9] espeak: new package
Arnaud Aujon <arnaud.aujon@gmail.com>
http://patchwork.ozlabs.org/patch/284229

python-sip: new package
Sergey Kostanbaev <sergey.kostanbaev@gmail.com>
http://patchwork.ozlabs.org/patch/284873

python-pyqt: new package
Sergey Kostanbaev <sergey.kostanbaev@gmail.com>
http://patchwork.ozlabs.org/patch/284874

Above three patches: A keep. If the original submitters could refresh
and resend the patches, that would be great. Otherwise it will be
added to the buildroot TODO list awaiting an adopter.


[RFC,1/2] host-xxd: new package
Ryan Barnett <rjbarnet@rockwellcollins.com>
http://patchwork.ozlabs.org/patch/285936

[RFC,2/2] uboot: introduce u-boot.pbl format
Ryan Barnett <rjbarnet@rockwellcollins.com>
http://patchwork.ozlabs.org/patch/285937

Above two patches are still in progress by Ryan. As Ryan is still
active in Buildroot development, the patches will be marked as Changes
Requested in patchwork so they are no longer in the 'active' queue.


[1/3] ccache: change compilercheck to use compiler and toolchain info
Danomi Manchego <danomimanchego123@gmail.com>
http://patchwork.ozlabs.org/patch/287383

D more work needed. Looking at Arnout's
comments on the first patch, this needs to be thought through, and a
final solution is to be implemented. I really think we should improve
ccache in buildroot, though, so I hope a proper solution can be found.
Danomi mentioned he has no bandwidth at the moment to pull this, so
it's up to others. Thanks Danomi for all the work you've spent on this
so far!


[2/3] ccache: change default cache directory path to match config setting
Danomi Manchego <danomimanchego123@gmail.com>
http://patchwork.ozlabs.org/patch/287384

[3/3] ccache: provide capability to do initial ccache setup
Danomi Manchego <danomimanchego123@gmail.com>
http://patchwork.ozlabs.org/patch/287385

Danomi indicated that the above two patches are indepedent from the
first one. I'm triaging it as A, and hope to be able to refresh it (or
someone else).


Best regards,
Thomas

[Buildroot] Patchwork cleanup #8: submitter notification

[Danomi Manchego]

Thomas,

On Tue, Apr 29, 2014 at 3:48 PM, Thomas De Schampheleire
<patrickdepinguin@gmail.com> wrote:
> People in To,
...
> [2/3] ccache: change default cache directory path to match config setting
> Danomi Manchego <danomimanchego123@gmail.com>
> http://patchwork.ozlabs.org/patch/287384
>
> [3/3] ccache: provide capability to do initial ccache setup
> Danomi Manchego <danomimanchego123@gmail.com>
> http://patchwork.ozlabs.org/patch/287385
>
> Danomi indicated that the above two patches are indepedent from the
> first one. I'm triaging it as A, and hope to be able to refresh it (or
> someone else).

I'm not in the "To" list, but I can refresh these and submit as a
separate series, if you like.

Danomi -

[Buildroot] Patchwork cleanup #8: submitter notification

[Yann E. MORIN]

Thomas, Angelo, All,

On 2014-04-29 21:48 +0200, Thomas De Schampheleire spake thusly:
[--SNIP--]
> For this cleanup session, here are the patches:
[--SNIP--]
> package/makedevs: add "l" type for symlinks ownership change
> angelo dureghello <angelo70@gmail.com>
> http://patchwork.ozlabs.org/patch/283015
> 
> C unsure: Angelo: could you describe in more detail if you are still
> using this patch, and why you need it? How come the symbolic link does
> not have the right ownership from the start?

Note that ownership and permissions of symlinks are never checked, only
those of the pointed-to entity (file, dir...) are.

Setting ownership of symlinks should not generally be a concern.

However, I can se one case where we would want to be able to set
ownership and/or permissions on a synlink: to avoid the identity of the
"builder" to seep down into the generated filesystem. But even in that
case, only the numerical UID would end up in the generated filesystem,
so it is not really a concern.

So, I can't really understand what the underlying problem is.

Angelo, we need you to explain the issue you are facing, so we understand
why you believe this change to be needed.

(Note: a proper commit message would do just that: describe the observed
problem, explain the underlying reason it behaves that way, introduce
and explain the proposed fix. See for example cset 86c3244 "wget: fix
host-gettext build dependency race" for a real-world example.)

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] Patchwork cleanup #8: submitter notification

[Thomas Petazzoni]

Dear Yann E. MORIN,

On Tue, 29 Apr 2014 23:09:05 +0200, Yann E. MORIN wrote:

> However, I can se one case where we would want to be able to set
> ownership and/or permissions on a synlink: to avoid the identity of the
> "builder" to seep down into the generated filesystem. But even in that
> case, only the numerical UID would end up in the generated filesystem,
> so it is not really a concern.

We do a "chown -R 0:0" on all files in the root filesystem, before
taking into account device tables. So I don't see how an ownership on
the build machine can leak into the generated root filesystem.

See fs/common.mk to see where's it's done.

Best regards,

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

[Buildroot] Patchwork cleanup #8: submitter notification

[Arnout Vandecappelle]

On 29/04/14 23:09, Yann E. MORIN wrote:
> Thomas, Angelo, All,
> 
> On 2014-04-29 21:48 +0200, Thomas De Schampheleire spake thusly:
> [--SNIP--]
>> For this cleanup session, here are the patches:
> [--SNIP--]
>> package/makedevs: add "l" type for symlinks ownership change
>> angelo dureghello <angelo70@gmail.com>
>> http://patchwork.ozlabs.org/patch/283015
>>
>> C unsure: Angelo: could you describe in more detail if you are still
>> using this patch, and why you need it? How come the symbolic link does
>> not have the right ownership from the start?
> 
> Note that ownership and permissions of symlinks are never checked, only
> those of the pointed-to entity (file, dir...) are.

 Except for directories with mode 1777. From man 7 symlink:

The only time that the ownership of a symbolic link
matters is when the link is being removed or renamed in a directory
that has the sticky bit set (see stat(2)).

 I find it hard to construct a use case, but I can imagine there is one.
It would indeed be good if this were documented in the commit log.

> Setting ownership of symlinks should not generally be a concern.
> 
> However, I can se one case where we would want to be able to set
> ownership and/or permissions on a synlink: to avoid the identity of the
> "builder" to seep down into the generated filesystem. But even in that
> case, only the numerical UID would end up in the generated filesystem,
> so it is not really a concern.

 That argument is void, since everything is already chown root:root.


> So, I can't really understand what the underlying problem is.
> 
> Angelo, we need you to explain the issue you are facing, so we understand
> why you believe this change to be needed.
> 
> (Note: a proper commit message would do just that: describe the observed
> problem, explain the underlying reason it behaves that way, introduce
> and explain the proposed fix. See for example cset 86c3244 "wget: fix
> host-gettext build dependency race" for a real-world example.)

 +1


 Regards,
 Arnout

> 
> Regards,
> Yann E. MORIN.
> 


-- 
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] Patchwork cleanup #8: submitter notification

[Yann E. MORIN]

Thomas, All,

On 2014-04-30 00:52 +0200, Thomas Petazzoni spake thusly:
> On Tue, 29 Apr 2014 23:09:05 +0200, Yann E. MORIN wrote:
> 
> > However, I can se one case where we would want to be able to set
> > ownership and/or permissions on a synlink: to avoid the identity of the
> > "builder" to seep down into the generated filesystem. But even in that
> > case, only the numerical UID would end up in the generated filesystem,
> > so it is not really a concern.
> 
> We do a "chown -R 0:0" on all files in the root filesystem, before
> taking into account device tables. So I don't see how an ownership on
> the build machine can leak into the generated root filesystem.

chown does not change the ownership of a symlink, only that of the
pointed-to entity:

    $ touch titi
    $ ln -s titi toto
    $ sudo chown root:root toto
    $ ls -l titi toto
    -rw-r--r-- 1 root   root   0 Apr 30 18:55 titi
    lrwxrwxrwx 1 ymorin ymorin 4 Apr 30 18:55 toto -> titi

So the symlink's ownership is not modified.

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] Patchwork cleanup #8: submitter notification

[Thomas Petazzoni]

Dear Yann E. MORIN,

On Wed, 30 Apr 2014 18:56:59 +0200, Yann E. MORIN wrote:

> > We do a "chown -R 0:0" on all files in the root filesystem, before
> > taking into account device tables. So I don't see how an ownership on
> > the build machine can leak into the generated root filesystem.
> 
> chown does not change the ownership of a symlink, only that of the
> pointed-to entity:
> 
>     $ touch titi
>     $ ln -s titi toto
>     $ sudo chown root:root toto
>     $ ls -l titi toto
>     -rw-r--r-- 1 root   root   0 Apr 30 18:55 titi
>     lrwxrwxrwx 1 ymorin ymorin 4 Apr 30 18:55 toto -> titi
> 
> So the symlink's ownership is not modified.

Should we do a chown -h -R 0:0 then?

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

[Buildroot] Patchwork cleanup #8: submitter notification

[Yann E. MORIN]

Thomas, All,

On 2014-04-30 19:40 +0200, Thomas Petazzoni spake thusly:
> On Wed, 30 Apr 2014 18:56:59 +0200, Yann E. MORIN wrote:
> 
> > > We do a "chown -R 0:0" on all files in the root filesystem, before
> > > taking into account device tables. So I don't see how an ownership on
> > > the build machine can leak into the generated root filesystem.
> > 
> > chown does not change the ownership of a symlink, only that of the
> > pointed-to entity:
> > 
> >     $ touch titi
> >     $ ln -s titi toto
> >     $ sudo chown root:root toto
> >     $ ls -l titi toto
> >     -rw-r--r-- 1 root   root   0 Apr 30 18:55 titi
> >     lrwxrwxrwx 1 ymorin ymorin 4 Apr 30 18:55 toto -> titi
> > 
> > So the symlink's ownership is not modified.
> 
> Should we do a chown -h -R 0:0 then?

Oh, Neat! I did not know about -h.

I was afraid that was a recent addition, but it's been in chown since
1996-05-19, so we can safely assume that even enterprise distros (that
get updated once in a blue moon) will all have it.

Yeah! :-)

I'll cook up a patch.

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] Patchwork cleanup #8: submitter notification

[sergey kostanbaev]

Hi,

I'll try to update my patches.

Best regards,
Sergey


On Tue, Apr 29, 2014 at 7:48 PM, Thomas De Schampheleire <
patrickdepinguin@gmail.com> wrote:

> People in To,
>
> The buildroot community is trying to clean up the backlog of unhandled
> patches sent to the mailing list (logged in patchwork [1]). We are
> starting from the oldest patches and working our way up towards the
> present.
>
> In this mail, one or more patches you sent to the buildroot list are
> put in one of four categories:
> A. to be refreshed and resent to the list
> B. rejected
> C. we're unsure, your feedback is requested
> D. more thorough changes needed instead of the current patch
>
> If one of your patches falls into category A, it will be added to the
> buildroot todo list, meaning that someone will eventually take the
> time to refresh and resend the patch. However, if you can spare some
> time to do it yourself, then this will greatly accelerate the
> inclusion of your patch in buildroot.
>
> If one of your patches falls into category B, you can either accept
> the reasons given, or you may disagree in which case we invite you to
> discuss the matter with us. In this case, please explain why you think
> the patch should still be accepted.
>
> If one of your patches falls into category C, please provide more
> feedback. For some patches, our question to you may be if you are
> still interested in getting this patch in buildroot or not. Other
> patches may be in this category because we don't fully understand its
> purpose (yet). Your feedback will help us in making the right choice.
>
> If one of your patches falls into category D, the buildroot developers
> accept the problem that the patch is addressing, but believe it should
> be fixed in a different way, possibly requiring some changes in the
> buildroot core infrastructure.
>
> We propose a two-week period to give you some time to respond with
> your feedback.
>
> For this cleanup session, here are the patches:
>
> [RFC,5/7] python-linaro-dashboard-
> bundle: new package
> ludovic.desroches at atmel.com
> http://patchwork.ozlabs.org/patch/282728
>
> [RFC,6/7] lava-tool: new package
> ludovic.desroches at atmel.com
> http://patchwork.ozlabs.org/patch/282729
>
> [RFC,7/7] lava-test: new package
> ludovic.desroches at atmel.com
> http://patchwork.ozlabs.org/patch/282730
>
> Ludovic said he would revise/retest/resubmit these patches, also
> taking into account the new python-package infrastructure. The patches
> are thus marked as Changes Requested in patchwork.
>
>
> package/makedevs: add "l" type for symlinks ownership change
> angelo dureghello <angelo70@gmail.com>
> http://patchwork.ozlabs.org/patch/283015
>
> C unsure: Angelo: could you describe in more detail if you are still
> using this patch, and why you need it? How come the symbolic link does
> not have the right ownership from the start?
>
>
> [v9] espeak: new package
> Arnaud Aujon <arnaud.aujon@gmail.com>
> http://patchwork.ozlabs.org/patch/284229
>
> python-sip: new package
> Sergey Kostanbaev <sergey.kostanbaev@gmail.com>
> http://patchwork.ozlabs.org/patch/284873
>
> python-pyqt: new package
> Sergey Kostanbaev <sergey.kostanbaev@gmail.com>
> http://patchwork.ozlabs.org/patch/284874
>
> Above three patches: A keep. If the original submitters could refresh
> and resend the patches, that would be great. Otherwise it will be
> added to the buildroot TODO list awaiting an adopter.
>
>
> [RFC,1/2] host-xxd: new package
> Ryan Barnett <rjbarnet@rockwellcollins.com>
> http://patchwork.ozlabs.org/patch/285936
>
> [RFC,2/2] uboot: introduce u-boot.pbl format
> Ryan Barnett <rjbarnet@rockwellcollins.com>
> http://patchwork.ozlabs.org/patch/285937
>
> Above two patches are still in progress by Ryan. As Ryan is still
> active in Buildroot development, the patches will be marked as Changes
> Requested in patchwork so they are no longer in the 'active' queue.
>
>
> [1/3] ccache: change compilercheck to use compiler and toolchain info
> Danomi Manchego <danomimanchego123@gmail.com>
> http://patchwork.ozlabs.org/patch/287383
>
> D more work needed. Looking at Arnout's
> comments on the first patch, this needs to be thought through, and a
> final solution is to be implemented. I really think we should improve
> ccache in buildroot, though, so I hope a proper solution can be found.
> Danomi mentioned he has no bandwidth at the moment to pull this, so
> it's up to others. Thanks Danomi for all the work you've spent on this
> so far!
>
>
> [2/3] ccache: change default cache directory path to match config setting
> Danomi Manchego <danomimanchego123@gmail.com>
> http://patchwork.ozlabs.org/patch/287384
>
> [3/3] ccache: provide capability to do initial ccache setup
> Danomi Manchego <danomimanchego123@gmail.com>
> http://patchwork.ozlabs.org/patch/287385
>
> Danomi indicated that the above two patches are indepedent from the
> first one. I'm triaging it as A, and hope to be able to refresh it (or
> someone else).
>
>
> Best regards,
> Thomas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20140430/32b29fe9/attachment.html>