[Buildroot] [PATCH] package: fix 'local' site method for host packages

[Buildroot] [PATCH] package: fix 'local' site method for host packages

[Thomas Petazzoni]

Using the 'local' site method works just fine for target
packages. However, for host packages, when HOST_<pkg>_SITE is
automatically defined by the package infrastructure to be equal to
<pkg>_SITE, when defining the <pkg>_OVERRIDE_SRCDIR, the $($(2)_SITE)
is empty, due to a missing additional dollar sign.

This patch ensures that the <pkg>_OVERRIDE_SRCDIR gets the correct
value, regardless of whether the HOST_<pkg>_SITE variable has been
defined by the package itself, or inferred by the package
infrastructure using the <pkg>_SITE value.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reported-by: http://stackoverflow.com/questions/19311747/buildroot-cant-use-local-site-method-for-custom-host-packages
---
 package/pkg-generic.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/pkg-generic.mk b/package/pkg-generic.mk
index a46457c..4bba4b5 100644
--- a/package/pkg-generic.mk
+++ b/package/pkg-generic.mk
@@ -281,7 +281,7 @@ endif
 
 ifeq ($$($(2)_SITE_METHOD),local)
 ifeq ($$($(2)_OVERRIDE_SRCDIR),)
-$(2)_OVERRIDE_SRCDIR = $($(2)_SITE)
+$(2)_OVERRIDE_SRCDIR = $$($(2)_SITE)
 endif
 endif
 
-- 
1.8.1.2

[Buildroot] [PATCH] package: fix 'local' site method for host packages

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 Thomas> Using the 'local' site method works just fine for target
 Thomas> packages. However, for host packages, when HOST_<pkg>_SITE is
 Thomas> automatically defined by the package infrastructure to be equal to
 Thomas> <pkg>_SITE, when defining the <pkg>_OVERRIDE_SRCDIR, the $($(2)_SITE)
 Thomas> is empty, due to a missing additional dollar sign.

 Thomas> This patch ensures that the <pkg>_OVERRIDE_SRCDIR gets the correct
 Thomas> value, regardless of whether the HOST_<pkg>_SITE variable has been
 Thomas> defined by the package itself, or inferred by the package
 Thomas> infrastructure using the <pkg>_SITE value.

 Thomas> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
 Thomas> Reported-by: http://stackoverflow.com/questions/19311747/buildroot-cant-use-local-site-method-for-custom-host-packages

Heh, odd place to report such issues. Committed, thanks.

-- 
Bye, Peter Korsgaard

[Buildroot] About user support and the mailing list

[Thomas Petazzoni]

Dear Peter Korsgaard,

On Mon, 14 Oct 2013 21:59:12 +0200, Peter Korsgaard wrote:

>  Thomas> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>  Thomas> Reported-by: http://stackoverflow.com/questions/19311747/buildroot-cant-use-local-site-method-for-custom-host-packages
> 
> Heh, odd place to report such issues. Committed, thanks.

Yes and no. Our mailing list is now having a *huge* traffic, mainly
developer-oriented (patches and related discussions). For the user just
starting up with Buildroot, not very familiar of open-source
communities, not feeling necessarily at ease with subscribing to a
50-100 e-mails/day mailing list, searching other forms of support seems
natural to me.

Maybe it's a sign that we should have a more "user-oriented" support
channel. A dedicated mailing list? An publicized usage of Stack
Overflow or some other similar stuff? Not sure exactly about this, but
might be worth a chat at the next Buildroot meeting, I believe.

Best regards,

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

[Buildroot] About user support and the mailing list

[Thomas De Schampheleire]

Hi,

On Tue, Oct 15, 2013 at 10:25 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Peter Korsgaard,
>
> On Mon, 14 Oct 2013 21:59:12 +0200, Peter Korsgaard wrote:
>
>>  Thomas> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>>  Thomas> Reported-by: http://stackoverflow.com/questions/19311747/buildroot-cant-use-local-site-method-for-custom-host-packages
>>
>> Heh, odd place to report such issues. Committed, thanks.
>
> Yes and no. Our mailing list is now having a *huge* traffic, mainly
> developer-oriented (patches and related discussions). For the user just
> starting up with Buildroot, not very familiar of open-source
> communities, not feeling necessarily at ease with subscribing to a
> 50-100 e-mails/day mailing list, searching other forms of support seems
> natural to me.
>
> Maybe it's a sign that we should have a more "user-oriented" support
> channel. A dedicated mailing list? An publicized usage of Stack
> Overflow or some other similar stuff? Not sure exactly about this, but
> might be worth a chat at the next Buildroot meeting, I believe.

The amount of traffic on the mailing list has indeed increased a lot.
On a previous Buildroot meeting, we talked about a split of the
mailing lists. At that time, we decided not to do this (yet).

One of the advantages of a unified list is that new users also are
'exposed' to development, and are hopefully more likely to contribute
too. There is no 'development elite' in this model.
At the same time, a unified list also encourages developers to help
users. It's not possible to subscribe to 'only the developer list'.

A split mailing list model is mainly advantageous for users that only
want to subscribe to a low-volume list, but other than that I don't
yet see big advantages. If you have more, please let me know.

Thomas: you seem to be active on StackOverflow. Can you give some more
background how this would work for us? I've only used stackoverflow in
a read-only mode, when googling a specific question.

Other possibilities are a forum (don't really like it) and IRC (we
have it already). Others?

Best regards,
Thomas

[Buildroot] About user support and the mailing list

[Jeremy Rosen]

> 
> One of the advantages of a unified list is that new users also are
> 'exposed' to development, and are hopefully more likely to contribute
> too. There is no 'development elite' in this model.
> At the same time, a unified list also encourages developers to help
> users. It's not possible to subscribe to 'only the developer list'.
> 

hmm, compared to most FOSS projects I know buildroot is a bit special...

There is no clear separation between users and developers as far as 
knowledge is concerned. All users should be able to compile stuff
know about cross compilers and installing firmwares. So doing a 
separate -user vs -dev mailing list makes less sense her.

However I would like to have a separate -discuss an -patch mailing 
list, one of them being for patch+reviews+commit messages and the 
other one being for actual discussions. 

That would separate the high traffic/fast reading parts from the 
low traffic/philosophical discussion parts.

The important part is that mose people (everybody?) should logically
subscribe to both, but mail filtering etc... would be much simpler.

[Buildroot] About user support and the mailing list

[Ryan Barnett]

Jeremy, Thomas P and D, All,

Jeremy Rosen <jeremy.rosen@openwide.fr> wrote on 10/15/2013 08:16:23 AM:

> > One of the advantages of a unified list is that new users also are
> > 'exposed' to development, and are hopefully more likely to contribute
> > too. There is no 'development elite' in this model.
> > At the same time, a unified list also encourages developers to help
> > users. It's not possible to subscribe to 'only the developer list'.
> > 
> 
> hmm, compared to most FOSS projects I know buildroot is a bit special...
> 
> There is no clear separation between users and developers as far as 
> knowledge is concerned. All users should be able to compile stuff
> know about cross compilers and installing firmwares. So doing a 
> separate -user vs -dev mailing list makes less sense her.
> 
> However I would like to have a separate -discuss an -patch mailing 
> list, one of them being for patch+reviews+commit messages and the 
> other one being for actual discussions. 
> 
> That would separate the high traffic/fast reading parts from the 
> low traffic/philosophical discussion parts.

I really like this idea as I believe it fits well with how this FOSS
project works. The majority of the emails are related to patches and
discussion surrounding them. I usually glance through these emails
since I don't necessarily have time to read through all of the patches.
So by having this separation would be nice as that way I don't 
accidentally glance over a philosophical discussion such as this.

> The important part is that mose people (everybody?) should logically
> subscribe to both, but mail filtering etc... would be much simpler.
 
Thanks,
-Ryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20131015/3725fc1e/attachment-0001.html>

[Buildroot] About user support and the mailing list

[Peter Korsgaard]

>>>>> "Ryan" == Ryan Barnett <rjbarnet@rockwellcollins.com> writes:

Hi,

 >> That would separate the high traffic/fast reading parts from the
 >> low traffic/philosophical discussion parts.

 Ryan> I really like this idea as I believe it fits well with how this
 Ryan> FOSS project works. The majority of the emails are related to
 Ryan> patches and discussion surrounding them. I usually glance through
 Ryan> these emails since I don't necessarily have time to read through
 Ryan> all of the patches.  So by having this separation would be nice
 Ryan> as that way I don't accidentally glance over a philosophical
 Ryan> discussion such as this.

The problem is that these things are rarely nicely seperated. This
thread started as a reply to a patch submission.

-- 
Bye, Peter Korsgaard

[Buildroot] About user support and the mailing list

[Thomas De Schampheleire]

Hi Peter,

On Tue, Oct 15, 2013 at 6:07 PM, Peter Korsgaard <jacmet@uclibc.org> wrote:
>>>>>> "Ryan" == Ryan Barnett <rjbarnet@rockwellcollins.com> writes:
>
> Hi,
>
>  >> That would separate the high traffic/fast reading parts from the
>  >> low traffic/philosophical discussion parts.
>
>  Ryan> I really like this idea as I believe it fits well with how this
>  Ryan> FOSS project works. The majority of the emails are related to
>  Ryan> patches and discussion surrounding them. I usually glance through
>  Ryan> these emails since I don't necessarily have time to read through
>  Ryan> all of the patches.  So by having this separation would be nice
>  Ryan> as that way I don't accidentally glance over a philosophical
>  Ryan> discussion such as this.
>
> The problem is that these things are rarely nicely seperated. This
> thread started as a reply to a patch submission.

This is not necessarily a big problem. If a discussion occurs on the
'patch' mailing list that is no longer directly related with the
actual patch, we should at least put the 'discussion' mailing list in
copy (or use only that list). In the beginning this can be odd, but
it's something we can learn.

I think the patch / discussion mailing list split, although similar,
is certainly better than a developer / user split. I'm not against it.
But if there are other ideas, let's hear them :)

Best regards,
Thomas

[Buildroot] About user support and the mailing list

[Thomas Petazzoni]

Dear Thomas De Schampheleire,

On Tue, 15 Oct 2013 15:04:44 +0200, Thomas De Schampheleire wrote:

> > Yes and no. Our mailing list is now having a *huge* traffic, mainly
> > developer-oriented (patches and related discussions). For the user just
> > starting up with Buildroot, not very familiar of open-source
> > communities, not feeling necessarily at ease with subscribing to a
> > 50-100 e-mails/day mailing list, searching other forms of support seems
> > natural to me.
> >
> > Maybe it's a sign that we should have a more "user-oriented" support
> > channel. A dedicated mailing list? An publicized usage of Stack
> > Overflow or some other similar stuff? Not sure exactly about this, but
> > might be worth a chat at the next Buildroot meeting, I believe.
> 
> The amount of traffic on the mailing list has indeed increased a lot.
> On a previous Buildroot meeting, we talked about a split of the
> mailing lists. At that time, we decided not to do this (yet).
> 
> One of the advantages of a unified list is that new users also are
> 'exposed' to development, and are hopefully more likely to contribute
> too. There is no 'development elite' in this model.
> At the same time, a unified list also encourages developers to help
> users. It's not possible to subscribe to 'only the developer list'.

Agreed.

> A split mailing list model is mainly advantageous for users that only
> want to subscribe to a low-volume list, but other than that I don't
> yet see big advantages. If you have more, please let me know.

That's mainly what I was concerned about. Subscribing to a 50-100
mails/day mailing list might be problematic for people who just want to
use Buildroot, even though I agree that the boundary between "users"
and "developers" is a lot less cut in Buildroot than it is for other
software.

> Thomas: you seem to be active on StackOverflow. Can you give some more
> background how this would work for us? I've only used stackoverflow in
> a read-only mode, when googling a specific question.

I'm not so much active on stackoverflow actually. In fact I just
subscribed to the tag "buildroot" so that whenever a Buildroot related
question is asked, I receive an e-mail. I generally find Stack Overflow
a bit better than web forums thanks to the scoring system which ensures
"good" answers are the one getting the highest visibility. Stack
Overflow also generally has a very high Google rank, so whenever you
search something programming-related on Google, there's a high chance
of having a hit on Stack Overflow.

In this discussion, I don't really have one good solution to suggest,
I'm merely interested in discussing the fact that the mailing list
traffic has increased, which on one side is really great (the project
is active) but on the other side may be problematic for users who just
want to have a little bit of support.

Best regards,

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

[Buildroot] About user support and the mailing list

[Arnout Vandecappelle]

On 15/10/13 21:44, Thomas De Schampheleire wrote:
> On Tue, Oct 15, 2013 at 6:07 PM, Peter Korsgaard<jacmet@uclibc.org>  wrote:
>>>>>>> >>>>>>"Ryan" == Ryan Barnett<rjbarnet@rockwellcollins.com>  writes:
>> >
>> >Hi,
>> >
>> >  >> That would separate the high traffic/fast reading parts from the
>> >  >> low traffic/philosophical discussion parts.
>> >
>> >  Ryan> I really like this idea as I believe it fits well with how this
>> >  Ryan> FOSS project works. The majority of the emails are related to
>> >  Ryan> patches and discussion surrounding them. I usually glance through
>> >  Ryan> these emails since I don't necessarily have time to read through
>> >  Ryan> all of the patches.  So by having this separation would be nice
>> >  Ryan> as that way I don't accidentally glance over a philosophical
>> >  Ryan> discussion such as this.
>> >
>> >The problem is that these things are rarely nicely seperated. This
>> >thread started as a reply to a patch submission.
> This is not necessarily a big problem. If a discussion occurs on the
> 'patch' mailing list that is no longer directly related with the
> actual patch, we should at least put the 'discussion' mailing list in
> copy (or use only that list). In the beginning this can be odd, but
> it's something we can learn.

  I was first against the -patch / -discuss split for the same reasons as 
Peter's, but as you say, it's easy to add -discuss to a reply.

  If this split goes through, I'd keep buildroot at busybox.net as the 
-discuss list and create a new one for patches.

  Patchwork should probably listen to both, since people will (certainly 
in the beginning) still send patches to the normal list.

  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