[PATCH] barebox: Add recipe for this new bootloader

[PATCH] barebox: Add recipe for this new bootloader

[Eric Benard]

* barebox is "a bootloader that inherits the best of U-Boot and the Linux kernel"
* add recipe for v2009.12.0 (last stable)
* add recipe for git repository

Signed-off-by: Eric Benard <eric@eukrea.com>
---
 recipes/barebox/barebox.inc        |   49 ++++++++++++++++++++++++++++++++++++
 recipes/barebox/barebox_2009.12.bb |   15 +++++++++++
 recipes/barebox/barebox_git.bb     |   10 +++++++
 3 files changed, 74 insertions(+), 0 deletions(-)
 create mode 100644 recipes/barebox/barebox.inc
 create mode 100644 recipes/barebox/barebox_2009.12.bb
 create mode 100644 recipes/barebox/barebox_git.bb

diff --git a/recipes/barebox/barebox.inc b/recipes/barebox/barebox.inc
new file mode 100644
index 0000000..b3def2a
--- /dev/null
+++ b/recipes/barebox/barebox.inc
@@ -0,0 +1,49 @@
+DESCRIPTION = "Barebox - a bootloader that inherits the best of U-Boot and the Linux kernel"
+HOMEPAGE = "http://www.barebox.org/"
+SECTION = "bootloaders"
+PRIORITY = "optional"
+LICENSE = "GPL"
+PROVIDES = "virtual/bootloader"
+
+PACKAGE_ARCH = "${MACHINE_ARCH}"
+
+inherit kernel-arch
+
+EXTRA_OEMAKE = "CROSS_COMPILE=${TARGET_PREFIX}"
+
+BAREBOX_MACHINE ?= "${MACHINE}_defconfig"
+BAREBOX_BINARY ?= "barebox.bin"
+BAREBOX_IMAGE ?= "barebox-${MACHINE}-${PV}-${PR}.bin"
+BAREBOX_SYMLINK ?= "barebox-${MACHINE}.bin"
+
+INSANE_SKIP_${PN} = True
+
+do_configure_prepend() {
+	   cp ${WORKDIR}/defconfig ${S}/.config
+	   oe_runmake oldconfig
+}
+
+do_compile () {
+	   unset LDFLAGS
+	   unset CFLAGS
+	   unset CPPFLAGS
+	   oe_runmake all
+}
+
+do_deploy () {
+	  install -d ${DEPLOY_DIR_IMAGE}
+	  install ${S}/${BAREBOX_BINARY} ${DEPLOY_DIR_IMAGE}/${BAREBOX_IMAGE}
+	  package_stagefile_shell ${DEPLOY_DIR_IMAGE}/${BAREBOX_IMAGE}
+
+	  cd ${DEPLOY_DIR_IMAGE}
+	  rm -f ${BAREBOX_SYMLINK}
+	  ln -sf ${BAREBOX_IMAGE} ${BAREBOX_SYMLINK}
+	  package_stagefile_shell ${DEPLOY_DIR_IMAGE}/${BAREBOX_SYMLINK}
+}
+do_deploy[dirs] = "${S}"
+addtask deploy before do_build after do_compile
+
+do_stage() {
+	   install -d ${STAGING_BINDIR_NATIVE}
+	   install -m 755 scripts/mkimage ${STAGING_BINDIR_NATIVE}/
+}
diff --git a/recipes/barebox/barebox_2009.12.bb b/recipes/barebox/barebox_2009.12.bb
new file mode 100644
index 0000000..2977429
--- /dev/null
+++ b/recipes/barebox/barebox_2009.12.bb
@@ -0,0 +1,15 @@
+require barebox.inc
+
+PR = "r0"
+
+DEFAULT_PREFERENCE = "-1"
+
+BAREBOX_REVISION ?= "0"
+
+S = "${WORKDIR}/barebox-${PV}.${BAREBOX_REVISION}"
+
+SRC_URI = "http://barebox.org/download/barebox-${PV}.${BAREBOX_REVISION}.tar.bz2;name=barebox-${PV}.${BAREBOX_REVISION} \
+	   file://defconfig"
+
+SRC_URI[barebox-2009.12.0.md5sum] = "d1aefe17cfd72affec766617b42dfb78"
+SRC_URI[barebox-2009.12.0.sha256sum] = "0ccd59898289652f4bebd8282737a771729d84886195221c781df08f81a837ef"
diff --git a/recipes/barebox/barebox_git.bb b/recipes/barebox/barebox_git.bb
new file mode 100644
index 0000000..8f9e322
--- /dev/null
+++ b/recipes/barebox/barebox_git.bb
@@ -0,0 +1,10 @@
+require barebox.inc
+
+PR = "r0"
+
+FILESPATHPKG =. "barebox-git:"
+
+SRC_URI = "git://git.pengutronix.de/git/barebox.git;protocol=git \
+	   file://defconfig"
+
+S = "${WORKDIR}/git"
-- 
1.6.0.4

Re: [PATCH] barebox: Add recipe for this new bootloader

[Eric Bénard]

Hi,

Le 17/01/2010 21:32, Eric Benard a écrit :
> * barebox is "a bootloader that inherits the best of U-Boot and the Linux kernel"
> * add recipe for v2009.12.0 (last stable)
> * add recipe for git repository
>
Please review carefully this recipe as this is my first public recipe so 
I may have misunderstood some variable's usage.

It's based on u-boot & linux recipes.
inherit kernel-arch is here in order to get the ARCH variable set

I'll send patches for a machine using barebox in a few days/weeks.

One question : is there a clean way to handle several config files for 
the bootloader (or for the kernel) for one machine (example : 
mymachine_with_128M_ram, mymachine_with_256M_ran) in order to compile 
several binaries which can be used depending on the hardware 
configuration used by the customer ?

Thanks,
Eric

Re: [PATCH] barebox: Add recipe for this new bootloader

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 17-01-10 21:32, Eric Benard wrote:
> * barebox is "a bootloader that inherits the best of U-Boot and the Linux kernel"
> * add recipe for v2009.12.0 (last stable)
> * add recipe for git repository
> 
> Signed-off-by: Eric Benard <eric@eukrea.com>

> +++ b/recipes/barebox/barebox_2009.12.bb
> @@ -0,0 +1,15 @@


> +PR = "r0"

> +++ b/recipes/barebox/barebox_git.bb
> @@ -0,0 +1,10 @@

> +PR = "r0"

Please don't set variables to the current default value, but leave them
out. We had tons of problems with vars getting copy/paste where the
default changed and we had to manually fix those (e.g. efl.bbclass still
pokes needlessly at PACKAGES).

Setting PR is relatively minor, but lets stay consistent :)

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFLU3rkMkyGM64RGpERAozFAKCreMUUurwnuzOIWPSqx7ZEUTeNVACeNxUF
vSV+pweWy2F1wabuldokuIw=
=TFC8
-----END PGP SIGNATURE-----

Re: [PATCH] barebox: Add recipe for this new bootloader

[Paul Menzel]

[-- Attachment #1: Type: text/plain, Size: 1187 bytes --]

Am Sonntag, den 17.01.2010, 22:02 +0100 schrieb Koen Kooi:
> On 17-01-10 21:32, Eric Benard wrote:
> > * barebox is "a bootloader that inherits the best of U-Boot and the
> Linux kernel"
> > * add recipe for v2009.12.0 (last stable)
> > * add recipe for git repository
> > 
> > Signed-off-by: Eric Benard <eric@eukrea.com>
> 
> > +++ b/recipes/barebox/barebox_2009.12.bb
> > @@ -0,0 +1,15 @@
> 
> 
> > +PR = "r0"
> 
> > +++ b/recipes/barebox/barebox_git.bb
> > @@ -0,0 +1,10 @@
> 
> > +PR = "r0"
> 
> Please don't set variables to the current default value, but leave
> them
> out. We had tons of problems with vars getting copy/paste where the
> default changed and we had to manually fix those (e.g. efl.bbclass
> still
> pokes needlessly at PACKAGES).
> 
> Setting PR is relatively minor, but lets stay consistent :) 

Could someone please change this in the manual please [1].

»It is good practice to always define PR in your recipes, even for the
"r0" release, so that when editing the recipe it is clear that the PR
number needs to be updated.«


Thanks,

Paul


[1] http://docs.openembedded.org/usermanual/html/recipes_versioning.html

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

[PATCH] usermanual : update note about PR

[Eric Benard]

quoting Koen Kooi : Please don't set variables to the current default
value, but leave them out. We had tons of problems with vars getting
copy/paste where the default changed and we had to manually fix those
(e.g. efl.bbclass still pokes needlessly at PACKAGES).

Signed-off-by: Eric Benard <eric@eukrea.com>
---
 docs/usermanual/chapters/recipes.xml |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/docs/usermanual/chapters/recipes.xml b/docs/usermanual/chapters/recipes.xml
index cad1d80..30364c0 100644
--- a/docs/usermanual/chapters/recipes.xml
+++ b/docs/usermanual/chapters/recipes.xml
@@ -323,9 +323,9 @@ mv fixed.recipe.bb myrecipe.bb</screen></para>
     then the default value of "r0" is used.</para>
 
     <para><note>
-        <para>It is good practice to always define PR in your recipes, even
-        for the <emphasis>"r0"</emphasis> release, so that when editing the
-        recipe it is clear that the PR number needs to be updated.</para>
+        <para>As PR is set to "r0" as a default, it must not be defined at the
+        creation of the recipe. When editing the recipe for the first time, the
+        PR variable must be defined to "r1".</para>
 
         <para>You should always increment PR when modifying a recipe.
         Sometimes this can be avoided if the change will have no effect on the
-- 
1.6.3.3

Re: [PATCH] usermanual : update note about PR

[Frans Meulenbroeks]

2010/1/17 Eric Benard <eric@eukrea.com>:
> quoting Koen Kooi : Please don't set variables to the current default
> value, but leave them out. We had tons of problems with vars getting
> copy/paste where the default changed and we had to manually fix those
> (e.g. efl.bbclass still pokes needlessly at PACKAGES).
>
> Signed-off-by: Eric Benard <eric@eukrea.com>
> ---
>  docs/usermanual/chapters/recipes.xml |    6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/docs/usermanual/chapters/recipes.xml b/docs/usermanual/chapters/recipes.xml
> index cad1d80..30364c0 100644
> --- a/docs/usermanual/chapters/recipes.xml
> +++ b/docs/usermanual/chapters/recipes.xml
> @@ -323,9 +323,9 @@ mv fixed.recipe.bb myrecipe.bb</screen></para>
>     then the default value of "r0" is used.</para>
>
>     <para><note>
> -        <para>It is good practice to always define PR in your recipes, even
> -        for the <emphasis>"r0"</emphasis> release, so that when editing the
> -        recipe it is clear that the PR number needs to be updated.</para>
> +        <para>As PR is set to "r0" as a default, it must not be defined at the
> +        creation of the recipe. When editing the recipe for the first time, the
> +        PR variable must be defined to "r1".</para>
>
>         <para>You should always increment PR when modifying a recipe.
>         Sometimes this can be avoided if the change will have no effect on the
> --
> 1.6.3.3

Personally (having forgotten to bump PR once or twice), I'm in favour
of keeping the recommendation of setting PR = "r0" as good practice in
a recipe.
Apart from the good practice, it also might help a little bit to give
PR a standard location.

Frans.

Re: [PATCH] usermanual : update note about PR

[Eric Bénard]

Le 17/01/2010 23:11, Frans Meulenbroeks a écrit :
> Personally (having forgotten to bump PR once or twice), I'm in favour
> of keeping the recommendation of setting PR = "r0" as good practice in
> a recipe.
> Apart from the good practice, it also might help a little bit to give
> PR a standard location.

yes this looks like a sane pratice.

Eric

Re: [PATCH] usermanual : update note about PR

[Rolf Leggewie]

Frans Meulenbroeks wrote:
> Apart from the good practice, it also might help a little bit to give
> PR a standard location.

PR does have a standard location as defined in the StyleGuide, although
of course it may not be observed in all recipes.

http://wiki.openembedded.org/index.php/Styleguide

Re: [PATCH] usermanual : update note about PR

[Rolf Leggewie]

Eric Benard wrote:
> quoting Koen Kooi : Please don't set variables to the current default

NACK.  This is Koen's position.  See my previous mail that there are
differing views.

Re: [PATCH] barebox: Add recipe for this new bootloader

[Frans Meulenbroeks]

2010/1/17 Paul Menzel <paulepanter@users.sourceforge.net>:
> Am Sonntag, den 17.01.2010, 22:02 +0100 schrieb Koen Kooi:
>> On 17-01-10 21:32, Eric Benard wrote:
>> > * barebox is "a bootloader that inherits the best of U-Boot and the
>> Linux kernel"
>> > * add recipe for v2009.12.0 (last stable)
>> > * add recipe for git repository
>> >
>> > Signed-off-by: Eric Benard <eric@eukrea.com>
>>
>> > +++ b/recipes/barebox/barebox_2009.12.bb
>> > @@ -0,0 +1,15 @@
>>
>>
>> > +PR = "r0"
>>
>> > +++ b/recipes/barebox/barebox_git.bb
>> > @@ -0,0 +1,10 @@
>>
>> > +PR = "r0"
>>
>> Please don't set variables to the current default value, but leave
>> them
>> out. We had tons of problems with vars getting copy/paste where the
>> default changed and we had to manually fix those (e.g. efl.bbclass
>> still
>> pokes needlessly at PACKAGES).
>>
>> Setting PR is relatively minor, but lets stay consistent :)
>
> Could someone please change this in the manual please [1].
>
> »It is good practice to always define PR in your recipes, even for the
> "r0" release, so that when editing the recipe it is clear that the PR
> number needs to be updated.«
>
Personally I'm in favour of the above good practice.
I suggest to keep PR = "r0" in recipes

Frans

Re: [PATCH] barebox: Add recipe for this new bootloader

[Mike Westerhof]

Frans Meulenbroeks wrote:
> 2010/1/17 Paul Menzel <paulepanter@users.sourceforge.net>:
>> Am Sonntag, den 17.01.2010, 22:02 +0100 schrieb Koen Kooi:

>>> Please don't set variables to the current default value, but leave
>>> them
>>> out. We had tons of problems with vars getting copy/paste where the
>>> default changed and we had to manually fix those (e.g. efl.bbclass
>>> still
>>> pokes needlessly at PACKAGES).
>>>
>>> Setting PR is relatively minor, but lets stay consistent :)
>> Could someone please change this in the manual please [1].
>>
>> »It is good practice to always define PR in your recipes, even for the
>> "r0" release, so that when editing the recipe it is clear that the PR
>> number needs to be updated.«
>>
> Personally I'm in favour of the above good practice.
> I suggest to keep PR = "r0" in recipes
> 
> Frans

+1 on this.   The PR is such a common variable to set, and as Koen
observes setting it to zero is relatively minor.  I feel that its
presence in a recipe may help avoid the "forgot to bump PR" problems.

-Mike (mwester)

Re: [PATCH] barebox: Add recipe for this new bootloader

[Rolf Leggewie]

Paul Menzel wrote:
>> Setting PR is relatively minor, but lets stay consistent :) 
> 
> Could someone please change this in the manual please [1].
> 
> »It is good practice to always define PR in your recipes, even for the
> "r0" release, so that when editing the recipe it is clear that the PR
> number needs to be updated.«

I think it's safe to say that there are two factions with regard to PR
being set to r0.  And as you can see, both have their arguments in
favor.  Even though it may sound like it, Koen's position is not the
only one.  And I guess, neither one is official.

Re: [PATCH] barebox: Add recipe for this new bootloader

[Phil Blundell]

On Mon, 2010-01-18 at 01:22 +0100, Rolf Leggewie wrote:
> Paul Menzel wrote:
> >> Setting PR is relatively minor, but lets stay consistent :) 
> > 
> > Could someone please change this in the manual please [1].
> > 
> > »It is good practice to always define PR in your recipes, even for the
> > "r0" release, so that when editing the recipe it is clear that the PR
> > number needs to be updated.«
> 
> I think it's safe to say that there are two factions with regard to PR
> being set to r0.  And as you can see, both have their arguments in
> favor.  Even though it may sound like it, Koen's position is not the
> only one.  And I guess, neither one is official.

Yes, I think that's an accurate summary of the situation.  I think the
only way we will get a definitive answer would be to have the TSC hand
down a judgement on the matter.

p.

Re: [PATCH] barebox: Add recipe for this new bootloader

[Richard Purdie]

On Mon, 2010-01-18 at 13:10 +0000, Phil Blundell wrote:
> On Mon, 2010-01-18 at 01:22 +0100, Rolf Leggewie wrote:
> > Paul Menzel wrote:
> > >> Setting PR is relatively minor, but lets stay consistent :) 
> > > 
> > > Could someone please change this in the manual please [1].
> > > 
> > > »It is good practice to always define PR in your recipes, even for the
> > > "r0" release, so that when editing the recipe it is clear that the PR
> > > number needs to be updated.«
> > 
> > I think it's safe to say that there are two factions with regard to PR
> > being set to r0.  And as you can see, both have their arguments in
> > favor.  Even though it may sound like it, Koen's position is not the
> > only one.  And I guess, neither one is official.
> 
> Yes, I think that's an accurate summary of the situation.  I think the
> only way we will get a definitive answer would be to have the TSC hand
> down a judgement on the matter.

That would seem sensible if only to lay this matter to rest once and for
all! It would also be good to test the TSC processes...

Cheers,

Richard

include default PR or not (was: [PATCH] barebox: Add recipe for this new bootloader)

[Rolf Leggewie]

Richard Purdie wrote:
> On Mon, 2010-01-18 at 13:10 +0000, Phil Blundell wrote:
[...]
>> only way we will get a definitive answer would be to have the TSC hand
>> down a judgement on the matter.
> 
> That would seem sensible if only to lay this matter to rest once and for
> all! It would also be good to test the TSC processes...

I would think this is too minor for the TSC to bother.  But if you want
to take it on, why should I object?  It does take up bandwidth on this
list from time to time, so much is true.  Personally, I don't think the
best option would be to rule in favor of one or the other faction,
because that's what it would be seen for.  I don't think the TSC can
really win and resolve this issue.

*If* the TSC decides to vote on this, may I propose to have it decide
that people are free to include PR as r0 or not as they see fit,
perpetuating current practice. I think that is about the only sensible
solution we can find here.  If anything were to be made definitive, it
should be that devs - when speaking "officially" or something that could
be perceived as such - ought to make sure to stress this is a matter of
(their) personal preference.

Please don't let the TSC turn into some bureaucratic monster that
regulates everything.  When in doubt, feel free to not rule at all.

Re: include default PR or not (was: [PATCH] barebox: Add recipe for this new bootloader)

[Phil Blundell]

On Mon, 2010-01-18 at 17:24 +0100, Rolf Leggewie wrote:
> Richard Purdie wrote:
> > On Mon, 2010-01-18 at 13:10 +0000, Phil Blundell wrote:
> [...]
> >> only way we will get a definitive answer would be to have the TSC hand
> >> down a judgement on the matter.
> > 
> > That would seem sensible if only to lay this matter to rest once and for
> > all! It would also be good to test the TSC processes...
> 
> I would think this is too minor for the TSC to bother.  But if you want
> to take it on, why should I object?  It does take up bandwidth on this
> list from time to time, so much is true.  Personally, I don't think the
> best option would be to rule in favor of one or the other faction,
> because that's what it would be seen for.  I don't think the TSC can
> really win and resolve this issue.

I'm not entirely sure what point you are making about it being
undesirable for the TSC to "rule in favour of one or the other faction".
One of the primary roles of the TSC is to resolve or adjudicate disputes
between developers and, since such disputes are often binary issues by
their nature, it seems likely that in a lot of cases this is going to
boil down to having the TSC accept the viewpoint of one party and reject
the viewpoint of the other.  It would certainly be a shame for the TSC
to shy away from making a decision just because it might be seen to
agree with one group and disagree with another.

A large part of the reason for having the TSC in the first place was to
establish a group of people who were empowered (and, indeed, obliged) to
make decisions, and I think this is a fairly good example of a situation
where simply having a decision of some kind is more important than the
detail of what exactly that decision is.  

This particular issue is clearly somewhat trivial and, whichever
viewpoint prevails, the impact in the real world is going to be fairly
small.  But it has cropped up on this list several times now and it
seems equally clear that, so long as it remains unresolved, it will
continue to waste everybody's time and contributors will continue to be
baffled as to what exactly they should put in their patches in order to
get them applied.

p.

Re: include default PR or not (was: [PATCH] barebox: Add recipe for this new bootloader)

[Frans Meulenbroeks]

2010/1/21 Phil Blundell <philb@gnu.org>:
> On Mon, 2010-01-18 at 17:24 +0100, Rolf Leggewie wrote:
>> Richard Purdie wrote:
>> > On Mon, 2010-01-18 at 13:10 +0000, Phil Blundell wrote:
>> [...]
>> >> only way we will get a definitive answer would be to have the TSC hand
>> >> down a judgement on the matter.
>> >
>> > That would seem sensible if only to lay this matter to rest once and for
>> > all! It would also be good to test the TSC processes...
>>
>> I would think this is too minor for the TSC to bother.  But if you want
>> to take it on, why should I object?  It does take up bandwidth on this
>> list from time to time, so much is true.  Personally, I don't think the
>> best option would be to rule in favor of one or the other faction,
>> because that's what it would be seen for.  I don't think the TSC can
>> really win and resolve this issue.
>
> I'm not entirely sure what point you are making about it being
> undesirable for the TSC to "rule in favour of one or the other faction".
> One of the primary roles of the TSC is to resolve or adjudicate disputes
> between developers and, since such disputes are often binary issues by
> their nature, it seems likely that in a lot of cases this is going to
> boil down to having the TSC accept the viewpoint of one party and reject
> the viewpoint of the other.  It would certainly be a shame for the TSC
> to shy away from making a decision just because it might be seen to
> agree with one group and disagree with another.

Actually the # of options for TSC are somewhat bigger.
A decision could be that X is the required way of working and !X is not ok
However, it can also be weakened into making X is the preferred way
and !X less desirable (without forbidding it)
And there is still the option to leave X as a personal preference to
the developer.

For PR, guess my suggestion would be to have PR="r0" as preferred and
not having PR as less desirabe.
But if you make a change bumping PR (or adding PR="r1", if no PR
exists) is required.

Frans
>
> A large part of the reason for having the TSC in the first place was to
> establish a group of people who were empowered (and, indeed, obliged) to
> make decisions, and I think this is a fairly good example of a situation
> where simply having a decision of some kind is more important than the
> detail of what exactly that decision is.
>
> This particular issue is clearly somewhat trivial and, whichever
> viewpoint prevails, the impact in the real world is going to be fairly
> small.  But it has cropped up on this list several times now and it
> seems equally clear that, so long as it remains unresolved, it will
> continue to waste everybody's time and contributors will continue to be
> baffled as to what exactly they should put in their patches in order to
> get them applied.
>
> p.
>
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: include default PR or not (was: [PATCH] barebox: Add recipe for this new bootloader)

[Khem Raj]

On Thu, Jan 21, 2010 at 11:52 PM, Frans Meulenbroeks
<fransmeulenbroeks@gmail.com> wrote:
> 2010/1/21 Phil Blundell <philb@gnu.org>:
>> On Mon, 2010-01-18 at 17:24 +0100, Rolf Leggewie wrote:
>>> Richard Purdie wrote:
>>> > On Mon, 2010-01-18 at 13:10 +0000, Phil Blundell wrote:
>>> [...]
>>> >> only way we will get a definitive answer would be to have the TSC hand
>>> >> down a judgement on the matter.
>>> >
>>> > That would seem sensible if only to lay this matter to rest once and for
>>> > all! It would also be good to test the TSC processes...
>>>
>>> I would think this is too minor for the TSC to bother.  But if you want
>>> to take it on, why should I object?  It does take up bandwidth on this
>>> list from time to time, so much is true.  Personally, I don't think the
>>> best option would be to rule in favor of one or the other faction,
>>> because that's what it would be seen for.  I don't think the TSC can
>>> really win and resolve this issue.
>>
>> I'm not entirely sure what point you are making about it being
>> undesirable for the TSC to "rule in favour of one or the other faction".
>> One of the primary roles of the TSC is to resolve or adjudicate disputes
>> between developers and, since such disputes are often binary issues by
>> their nature, it seems likely that in a lot of cases this is going to
>> boil down to having the TSC accept the viewpoint of one party and reject
>> the viewpoint of the other.  It would certainly be a shame for the TSC
>> to shy away from making a decision just because it might be seen to
>> agree with one group and disagree with another.
>
> Actually the # of options for TSC are somewhat bigger.
> A decision could be that X is the required way of working and !X is not ok
> However, it can also be weakened into making X is the preferred way
> and !X less desirable (without forbidding it)
> And there is still the option to leave X as a personal preference to
> the developer.
>
> For PR, guess my suggestion would be to have PR="r0" as preferred and
> not having PR as less desirabe.
> But if you make a change bumping PR (or adding PR="r1", if no PR
> exists) is required.

IMO Letting PR=r0 is better because it does help people in remembering
to bump PR when they make the first change after r0
afterall 0 is also a number so it does convey some information in the recipe.

>
> Frans
>>
>> A large part of the reason for having the TSC in the first place was to
>> establish a group of people who were empowered (and, indeed, obliged) to
>> make decisions, and I think this is a fairly good example of a situation
>> where simply having a decision of some kind is more important than the
>> detail of what exactly that decision is.
>>
>> This particular issue is clearly somewhat trivial and, whichever
>> viewpoint prevails, the impact in the real world is going to be fairly
>> small.  But it has cropped up on this list several times now and it
>> seems equally clear that, so long as it remains unresolved, it will
>> continue to waste everybody's time and contributors will continue to be
>> baffled as to what exactly they should put in their patches in order to
>> get them applied.
>>
>> p.
>>
>>
>>
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: include default PR or not

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 22-01-10 17:13, Khem Raj wrote:

> IMO Letting PR=r0 is better because it does help people in remembering
> to bump PR when they make the first change after r0
> afterall 0 is also a number so it does convey some information in the recipe.

My experience is that people forget to bump PR regardless of PR = rX
being present in the recipe and/or includes, that line of thinking is moot.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFLXB7qMkyGM64RGpERAh9dAKCOEMCbtp+JMVdjqmpIJeAwO0sxuQCfXUbN
6ggZc7oVtJXYhraPeNIwSIw=
=/Bkw
-----END PGP SIGNATURE-----

Re: include default PR or not

[Rolf Leggewie]

Phil Blundell wrote:
> I'm not entirely sure what point you are making about it being
> undesirable for the TSC to "rule in favour of one or the other faction".

I'm not advocating for the TSC to take a soft stance for fear of
confrontation.  But why have a rule about something that isn't really so
important?  If we follow down the path of letting the TSC decide even
over silly things like PR, I'm afraid two things will happen.  One is
the TSC will become overloaded and two OE will become a bureaucratic,
no-fun hell.  Not sure that would be an improvement.

Re: [PATCH] barebox: Add recipe for this new bootloader

[Eric Bénard]

Hi,

Le 17/01/2010 21:32, Eric Benard a écrit :
> * barebox is "a bootloader that inherits the best of U-Boot and the Linux kernel"
> * add recipe for v2009.12.0 (last stable)
> * add recipe for git repository
>
appart from the comment from Koen I didn't receive any comment 
concerning this recipes.
Does this mean they are OK and can be pushed upstream by someone with 
commit access ?

Thanks,
Eric

Re: [PATCH] barebox: Add recipe for this new bootloader

[Khem Raj]

On (19/01/10 21:44), Eric Bénard wrote:
> Hi,
> 
> Le 17/01/2010 21:32, Eric Benard a écrit :
> >* barebox is "a bootloader that inherits the best of U-Boot and the Linux kernel"
> >* add recipe for v2009.12.0 (last stable)
> >* add recipe for git repository
> >
> appart from the comment from Koen I didn't receive any comment
> concerning this recipes.
> Does this mean they are OK and can be pushed upstream by someone
> with commit access ?

thanks. I applied the patch

> 
> Thanks,
> Eric
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel