[Buildroot] Bugs cleanup (input requested)

[Buildroot] Bugs cleanup (input requested)

[Thomas De Schampheleire]

All,

I have been looking at some bugs / enhancement requests this weekend.

*For the entries proposing new packages*, I have updated the todo
list. Feel free to adopt these patches (but please wait until next
release cycle): http://elinux.org/Buildroot#Packages

*For some entries, I have resubmitted the patch to the mailing list*.
Three of these have already been integrated (thanks!), following is
still remaining:

https://bugs.busybox.net/show_bug.cgi?id=6542
external python modules fail to compile to pyc if \\N escapes are used

Corresponding patch is: http://patchwork.ozlabs.org/patch/317659/
ThomasP commented that a similar change is also made by his upcoming
Python patch series, but since this won't be included in 2014.02, I
think the proposed patch can already be applied.


*Finally, for some entries we need to make a decision on how to
proceed*. I am listing these entries below:


https://bugs.busybox.net/show_bug.cgi?id=3811
Added auto-mount for USB and SD Card (mdev) (for 2011.05)

In my opinion, this script/proposal is very project-specific and does not need
to be part of mainline buildroot. What is the opinion of other buildroot
developers?
If you agree, I would propose to close this bug as Resolved/Wontfix.


https://bugs.busybox.net/show_bug.cgi?id=4454
There should be simple way to update image, when changing external fs skeleton

This is about changing the custom target skeleton after the first
build, and then expecting these changes to be applied on the target
image. This is not something we support, and we propose the post-build
script / rootfs overlay mechanisms for it.
So my proposal is also to close this bug as Resolved/Wontfix, if you agree.


https://bugs.busybox.net/show_bug.cgi?id=2419
Add a bundle of Lua modules

This is a bug from 2010 by Francois, and as far as I can see this is
about the luarocks infrastructure. So I think this bug can be closed
now, but I wanted to check with you to be sure.


https://bugs.busybox.net/show_bug.cgi?id=4339
Allow override of DL_DIR in extract step

I have requested the author of the problem for additional info, which
was provided. They are using a custom dl dir for company packages, by
adding the following in these packages' .mk file:
$($(PKG)_BUILD_DIR)/.stamp_% : DL_DIR=$(OUR_SPECIAL_DL_DIR)
In order to make this work, they need the following change in
package/pkg-generic.mk:

  # default extract command
  $(2)_EXTRACT_CMDS ?= \
-     $$(if $$($(2)_SOURCE),$$(INFLATE$$(suffix $$($(2)_SOURCE)))
$(DL_DIR)/$$($(2)_SOURCE) | \
+     $$(if $$($(2)_SOURCE),$$(INFLATE$$(suffix $$($(2)_SOURCE)))
$$(DL_DIR)/$$($(2)_SOURCE) | \
      $(TAR) $(TAR_STRIP_COMPONENTS)=1 -C $$($(2)_DIR) $(TAR_OPTIONS) -)

  # post-steps hooks

Although the usage is pretty funky, the patch is not very invasive and
I don't have a strong objection.  But I could understand that other
people don't like this. I think there are three alternatives:
- accept the patch
- reject the patch
- reject the patch but propose another solution


Thanks for your feedback,
Thomas

[Buildroot] Bugs cleanup (input requested)

[Maxime Hadjinlian]

Hi all,

On Mon, Feb 10, 2014 at 11:21 AM, Thomas De Schampheleire
<patrickdepinguin@gmail.com> wrote:
> All,
>
> I have been looking at some bugs / enhancement requests this weekend.
>
> *For the entries proposing new packages*, I have updated the todo
> list. Feel free to adopt these patches (but please wait until next
> release cycle): http://elinux.org/Buildroot#Packages
We should organize and specify clearly who is working on what, to
avoid work done twice. In the bug tracker, it can be assigned to the
person wanting to adopt this one, other than that. The wiki should be
edited or a mail sent to the mailing.
>
> *For some entries, I have resubmitted the patch to the mailing list*.
> Three of these have already been integrated (thanks!), following is
> still remaining:
>
> https://bugs.busybox.net/show_bug.cgi?id=6542
> external python modules fail to compile to pyc if \\N escapes are used
>
> Corresponding patch is: http://patchwork.ozlabs.org/patch/317659/
> ThomasP commented that a similar change is also made by his upcoming
> Python patch series, but since this won't be included in 2014.02, I
> think the proposed patch can already be applied.
>
>
> *Finally, for some entries we need to make a decision on how to
> proceed*. I am listing these entries below:
>
>
> https://bugs.busybox.net/show_bug.cgi?id=3811
> Added auto-mount for USB and SD Card (mdev) (for 2011.05)
>
> In my opinion, this script/proposal is very project-specific and does not need
> to be part of mainline buildroot. What is the opinion of other buildroot
> developers?
> If you agree, I would propose to close this bug as Resolved/Wontfix.
I agree, it seems too specific, this could be done in a post build script.
>
>
> https://bugs.busybox.net/show_bug.cgi?id=4454
> There should be simple way to update image, when changing external fs skeleton
>
> This is about changing the custom target skeleton after the first
> build, and then expecting these changes to be applied on the target
> image. This is not something we support, and we propose the post-build
> script / rootfs overlay mechanisms for it.
> So my proposal is also to close this bug as Resolved/Wontfix, if you agree.
Also agreed.
>
>
> https://bugs.busybox.net/show_bug.cgi?id=2419
> Add a bundle of Lua modules
>
> This is a bug from 2010 by Francois, and as far as I can see this is
> about the luarocks infrastructure. So I think this bug can be closed
> now, but I wanted to check with you to be sure.
>
>
> https://bugs.busybox.net/show_bug.cgi?id=4339
> Allow override of DL_DIR in extract step
>
> I have requested the author of the problem for additional info, which
> was provided. They are using a custom dl dir for company packages, by
> adding the following in these packages' .mk file:
> $($(PKG)_BUILD_DIR)/.stamp_% : DL_DIR=$(OUR_SPECIAL_DL_DIR)
> In order to make this work, they need the following change in
> package/pkg-generic.mk:
>
>   # default extract command
>   $(2)_EXTRACT_CMDS ?= \
> -     $$(if $$($(2)_SOURCE),$$(INFLATE$$(suffix $$($(2)_SOURCE)))
> $(DL_DIR)/$$($(2)_SOURCE) | \
> +     $$(if $$($(2)_SOURCE),$$(INFLATE$$(suffix $$($(2)_SOURCE)))
> $$(DL_DIR)/$$($(2)_SOURCE) | \
>       $(TAR) $(TAR_STRIP_COMPONENTS)=1 -C $$($(2)_DIR) $(TAR_OPTIONS) -)
>
>   # post-steps hooks
>
> Although the usage is pretty funky, the patch is not very invasive and
> I don't have a strong objection.  But I could understand that other
> people don't like this. I think there are three alternatives:
> - accept the patch
> - reject the patch
> - reject the patch but propose another solution
Maybe I am mistaken, but BR2_EXTERNAL seems to fit their uses ? They
could keep their internals packages separated this way, using also the
PROPRIETARY license along with LIBFOO_REDISTRIBUTE.
>
>
> Thanks for your feedback,
> Thomas
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] Bugs cleanup (input requested)

[Thomas De Schampheleire]

Hi Maxime,

On Mon, Feb 10, 2014 at 1:02 PM, Maxime Hadjinlian
<maxime.hadjinlian@gmail.com> wrote:
> Hi all,
>
> On Mon, Feb 10, 2014 at 11:21 AM, Thomas De Schampheleire
> <patrickdepinguin@gmail.com> wrote:
>> All,
>>
>> I have been looking at some bugs / enhancement requests this weekend.
>>
>> *For the entries proposing new packages*, I have updated the todo
>> list. Feel free to adopt these patches (but please wait until next
>> release cycle): http://elinux.org/Buildroot#Packages
>
> We should organize and specify clearly who is working on what, to
> avoid work done twice. In the bug tracker, it can be assigned to the
> person wanting to adopt this one, other than that. The wiki should be
> edited or a mail sent to the mailing.

I fully agree.

Best regards,
Thomas

[Buildroot] Bugs cleanup (input requested)

[Danomi Manchego]

On Mon, Feb 10, 2014 at 5:21 AM, Thomas De Schampheleire
<patrickdepinguin@gmail.com> wrote:
> https://bugs.busybox.net/show_bug.cgi?id=4454
> There should be simple way to update image, when changing external fs skeleton
>
> This is about changing the custom target skeleton after the first
> build, and then expecting these changes to be applied on the target
> image. This is not something we support, and we propose the post-build
> script / rootfs overlay mechanisms for it.
> So my proposal is also to close this bug as Resolved/Wontfix, if you agree.

The custom skeleton can easily be added to the list rootfs overlays,
as the first overlay.  Seems "Resolved" to me.

[Buildroot] Bugs cleanup (input requested)

[Thomas Petazzoni]

Dear Thomas De Schampheleire,

On Mon, 10 Feb 2014 11:21:24 +0100, Thomas De Schampheleire wrote:

> *For the entries proposing new packages*, I have updated the todo
> list. Feel free to adopt these patches (but please wait until next
> release cycle): http://elinux.org/Buildroot#Packages

Note that for libav, Spenser Gilliland has proposed a patch some time
ago, and said he would resubmit an updated version.

For these bug reports, did you change them to another state?

Note that bug reports can be separated from enhancement requests in
Bugzilla, using the severity of the bug. When I look at Bugzilla, I
have two separate saved queries: "bugs" and "enhancements".

> *For some entries, I have resubmitted the patch to the mailing list*.
> Three of these have already been integrated (thanks!), following is
> still remaining:
> 
> https://bugs.busybox.net/show_bug.cgi?id=6542
> external python modules fail to compile to pyc if \\N escapes are used
> 
> Corresponding patch is: http://patchwork.ozlabs.org/patch/317659/
> ThomasP commented that a similar change is also made by his upcoming
> Python patch series, but since this won't be included in 2014.02, I
> think the proposed patch can already be applied.

True.

> https://bugs.busybox.net/show_bug.cgi?id=3811
> Added auto-mount for USB and SD Card (mdev) (for 2011.05)
> 
> In my opinion, this script/proposal is very project-specific and does not need
> to be part of mainline buildroot. What is the opinion of other buildroot
> developers?
> If you agree, I would propose to close this bug as Resolved/Wontfix.

Agreed.

> https://bugs.busybox.net/show_bug.cgi?id=4454
> There should be simple way to update image, when changing external fs skeleton
> 
> This is about changing the custom target skeleton after the first
> build, and then expecting these changes to be applied on the target
> image. This is not something we support, and we propose the post-build
> script / rootfs overlay mechanisms for it.
> So my proposal is also to close this bug as Resolved/Wontfix, if you agree.

Agreed.

> https://bugs.busybox.net/show_bug.cgi?id=2419
> Add a bundle of Lua modules
> 
> This is a bug from 2010 by Francois, and as far as I can see this is
> about the luarocks infrastructure. So I think this bug can be closed
> now, but I wanted to check with you to be sure.

As far as I can see, all the Lua modules added by the proposed patch
are now part of Buildroot mainline, so it can be closed.

> https://bugs.busybox.net/show_bug.cgi?id=4339
> Allow override of DL_DIR in extract step
> 
> I have requested the author of the problem for additional info, which
> was provided. They are using a custom dl dir for company packages, by
> adding the following in these packages' .mk file:
> $($(PKG)_BUILD_DIR)/.stamp_% : DL_DIR=$(OUR_SPECIAL_DL_DIR)
> In order to make this work, they need the following change in
> package/pkg-generic.mk:
> 
>   # default extract command
>   $(2)_EXTRACT_CMDS ?= \
> -     $$(if $$($(2)_SOURCE),$$(INFLATE$$(suffix $$($(2)_SOURCE)))
> $(DL_DIR)/$$($(2)_SOURCE) | \
> +     $$(if $$($(2)_SOURCE),$$(INFLATE$$(suffix $$($(2)_SOURCE)))
> $$(DL_DIR)/$$($(2)_SOURCE) | \
>       $(TAR) $(TAR_STRIP_COMPONENTS)=1 -C $$($(2)_DIR) $(TAR_OPTIONS) -)
> 
>   # post-steps hooks
> 
> Although the usage is pretty funky, the patch is not very invasive and
> I don't have a strong objection.  But I could understand that other
> people don't like this. I think there are three alternatives:
> - accept the patch
> - reject the patch
> - reject the patch but propose another solution

Reject the patch, with the following explanations:

 * The "file" site method can be used to "download" tarballs from a
   local directory, when needed.

 * The licensing infrastructure allows to create a directory with all
   the open-source tarballs, keeping them separate from proprietary
   bits, for delivery to customers.

I would also add that supporting highly-specific use cases in the
package infrastructure is not a good idea, because we might very easily
break them in the future if they are too specific and therefore not
used by enough people to be tested when we make changes.

Best regards,

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

[Buildroot] Bugs cleanup (input requested)

[Thomas De Schampheleire]

Hi Maxime, Danomi, Thomas,

On Mon, Feb 10, 2014 at 3:43 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
[..]
> *Finally, for some entries we need to make a decision on how to
> proceed*. I am listing these entries below:

Thanks for your feedback, I will update the bugs accordingly.

Best regards,
Thomas

[Buildroot] Bugs cleanup (input requested)

[Thomas De Schampheleire]

Hi Thomas,

On Mon, Feb 10, 2014 at 3:43 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Thomas De Schampheleire,
>
> On Mon, 10 Feb 2014 11:21:24 +0100, Thomas De Schampheleire wrote:
>
>> *For the entries proposing new packages*, I have updated the todo
>> list. Feel free to adopt these patches (but please wait until next
>> release cycle): http://elinux.org/Buildroot#Packages
>
> Note that for libav, Spenser Gilliland has proposed a patch some time
> ago, and said he would resubmit an updated version.

OK, I updated the wiki to reflect this.

>
> For these bug reports, did you change them to another state?

Not yet. I see that several already are in state 'enhancement', prio P5.

What about additionally 'assigning' them to a mailing address that
reflects that these are packages? Currently unassigned bugs are
assigned to 'unassigned at buildroot.uclibc.org'. Is this a real e-mail
address or not? What about we assign 'new package' entries to
'unassigned-newpkg at buildroot.uclibc.org' instead?

>
> Note that bug reports can be separated from enhancement requests in
> Bugzilla, using the severity of the bug. When I look at Bugzilla, I
> have two separate saved queries: "bugs" and "enhancements".

I will update the bugs I looked at accordingly.

Thanks,
Thomas

[Buildroot] Bugs cleanup (input requested)

[Thomas Petazzoni]

Dear Thomas De Schampheleire,

On Mon, 10 Feb 2014 16:20:10 +0100, Thomas De Schampheleire wrote:

> > For these bug reports, did you change them to another state?
> 
> Not yet. I see that several already are in state 'enhancement', prio P5.
> 
> What about additionally 'assigning' them to a mailing address that
> reflects that these are packages? Currently unassigned bugs are
> assigned to 'unassigned at buildroot.uclibc.org'. Is this a real e-mail
> address or not? What about we assign 'new package' entries to
> 'unassigned-newpkg at buildroot.uclibc.org' instead?

What would this be useful for? I believe we should either find people
willing to "adopt" those packages and do the remaining work needed to
get them merge, or close the bugs.

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

[Buildroot] Bugs cleanup (input requested)

[Thomas De Schampheleire]

Hi Thomas,

On Mon, Feb 10, 2014 at 5:48 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Thomas De Schampheleire,
>
> On Mon, 10 Feb 2014 16:20:10 +0100, Thomas De Schampheleire wrote:
>
>> > For these bug reports, did you change them to another state?
>>
>> Not yet. I see that several already are in state 'enhancement', prio P5.
>>
>> What about additionally 'assigning' them to a mailing address that
>> reflects that these are packages? Currently unassigned bugs are
>> assigned to 'unassigned at buildroot.uclibc.org'. Is this a real e-mail
>> address or not? What about we assign 'new package' entries to
>> 'unassigned-newpkg at buildroot.uclibc.org' instead?
>
> What would this be useful for? I believe we should either find people
> willing to "adopt" those packages and do the remaining work needed to
> get them merge, or close the bugs.

Main goal would be to visually separate 'add-package-foo' enhancements
(which are relatively easy to close) from other enhancements.

Finding people to adopt the package patches in enhancement requests is
similar to finding people to adopt patches from the patchwork cleanup
actions. The amount of developers attending the buildroot developer
days this year gives me good hopes to actually get to this, but it may
take some time.

Best regards,
Thomas

[Buildroot] Bugs cleanup (input requested)

[Thomas Petazzoni]

Dear Thomas De Schampheleire,

On Mon, 10 Feb 2014 18:48:13 +0100, Thomas De Schampheleire wrote:

> > What would this be useful for? I believe we should either find people
> > willing to "adopt" those packages and do the remaining work needed to
> > get them merge, or close the bugs.
> 
> Main goal would be to visually separate 'add-package-foo' enhancements
> (which are relatively easy to close) from other enhancements.

Simply give them a distinctive title, like:

"package addition: <package name>"

> Finding people to adopt the package patches in enhancement requests is
> similar to finding people to adopt patches from the patchwork cleanup
> actions. The amount of developers attending the buildroot developer
> days this year gives me good hopes to actually get to this, but it may
> take some time.

Indeed. I am however for fairly aggressively closing enhancement
requests for package additions that are not very interesting to active
contributors, and unlikely to find an adopter. Things like
open-vm-tools doesn't seem that useful to me, for example :)

Therefore, I would reply in the bug report, ask for either the original
bug reporter or another contributor to adopt the patch, and if no reply
within 2 weeks, close the bug.

Best regards,

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

[Buildroot] Bugs cleanup (input requested)

[Arnout Vandecappelle]

On 02/10/14 15:43, Thomas Petazzoni wrote:
> Dear Thomas De Schampheleire,
> 
> On Mon, 10 Feb 2014 11:21:24 +0100, Thomas De Schampheleire wrote:
> 
[snip]
>> https://bugs.busybox.net/show_bug.cgi?id=4339
>> Allow override of DL_DIR in extract step
>>
>> I have requested the author of the problem for additional info, which
>> was provided. They are using a custom dl dir for company packages, by
>> adding the following in these packages' .mk file:
>> $($(PKG)_BUILD_DIR)/.stamp_% : DL_DIR=$(OUR_SPECIAL_DL_DIR)
>> In order to make this work, they need the following change in
>> package/pkg-generic.mk:
>>
>>   # default extract command
>>   $(2)_EXTRACT_CMDS ?= \
>> -     $$(if $$($(2)_SOURCE),$$(INFLATE$$(suffix $$($(2)_SOURCE)))
>> $(DL_DIR)/$$($(2)_SOURCE) | \
>> +     $$(if $$($(2)_SOURCE),$$(INFLATE$$(suffix $$($(2)_SOURCE)))
>> $$(DL_DIR)/$$($(2)_SOURCE) | \
>>       $(TAR) $(TAR_STRIP_COMPONENTS)=1 -C $$($(2)_DIR) $(TAR_OPTIONS) -)
>>
>>   # post-steps hooks
>>
>> Although the usage is pretty funky, the patch is not very invasive and
>> I don't have a strong objection.  But I could understand that other
>> people don't like this. I think there are three alternatives:
>> - accept the patch
>> - reject the patch
>> - reject the patch but propose another solution
> 
> Reject the patch, with the following explanations:
> 
>  * The "file" site method can be used to "download" tarballs from a
>    local directory, when needed.
> 
>  * The licensing infrastructure allows to create a directory with all
>    the open-source tarballs, keeping them separate from proprietary
>    bits, for delivery to customers.
> 
> I would also add that supporting highly-specific use cases in the
> package infrastructure is not a good idea, because we might very easily
> break them in the future if they are too specific and therefore not
> used by enough people to be tested when we make changes.

 It is true that their use case should be solved with the legal-info
infrastructure - and if that doesn't work for them, it should be fixed there.

 However, the patch is still valid for a different reason: it makes
things more consistent. We use $$ almost everywhere within
generic-package, so ideally it should be done there as well.


 Regards,
 Arnout


> 
> Best regards,
> 
> Thomas
> 


-- 
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] Bugs cleanup (input requested)

[Thomas De Schampheleire]

Hi Arnout,

On Mon, Feb 10, 2014 at 9:39 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
[..]
>
>  It is true that their use case should be solved with the legal-info
> infrastructure - and if that doesn't work for them, it should be fixed there.
>
>  However, the patch is still valid for a different reason: it makes
> things more consistent. We use $$ almost everywhere within
> generic-package, so ideally it should be done there as well.

As I said in the original mail, I'm open to this change.
Would you like to adopt the patch and send it to the list to give it a
chance to be integrated?

Thanks,
Thomas