Patchwork [1/3] linux-yocto: restoring LINUX_VERSION ?= "3.0"

login
register
mail settings
Submitter Bruce Ashfield
Date Aug. 19, 2011, 5:20 a.m.
Message ID <e7036174cf607031e13323564f402c7b805e4572.1313730559.git.bruce.ashfield@windriver.com>
Download mbox | patch
Permalink /patch/10267/
State New, archived
Headers show

Comments

Bruce Ashfield - Aug. 19, 2011, 5:20 a.m.
There are enough other recipes/layers and users that are currently
using PREFERRED_VERSION that changing the value to 3.0.x does not
work at the current time. So we'll restore this to 3.0 and follow
the same model as previous releases. Using DEFAULT_PREFERENCE and
other schemes will be considered in the future.

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
---
 meta/recipes-kernel/linux/linux-yocto_3.0.bb |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
Phil Blundell - Aug. 19, 2011, 9:43 a.m.
On Fri, 2011-08-19 at 01:20 -0400, Bruce Ashfield wrote:
> diff --git a/meta/recipes-kernel/linux/linux-yocto_3.0.bb b/meta/recipes-kernel/linux/linux-yocto_3.0.bb
> index 44f1ebe..5d9871f 100644
> --- a/meta/recipes-kernel/linux/linux-yocto_3.0.bb
> +++ b/meta/recipes-kernel/linux/linux-yocto_3.0.bb
> @@ -11,7 +11,7 @@ KMACHINE_qemuarm  = "yocto/standard/arm-versatile-926ejs"
>  KBRANCH = ${KMACHINE}
>  KMETA = meta
>  
> -LINUX_VERSION ?= "3.0.1"
> +LINUX_VERSION ?= "3.0"
>  LINUX_VERSION_EXTENSION ?= "-yocto-${LINUX_KERNEL_TYPE}"
>  
>  SRCREV_machine_qemuarm = "36b4cdddcafc711f0ec9ad97882f23a6443c61b2"

That's going to cause PV to go backwards, right?  If you're going to do
that then you probably ought to consider bumping PE to retain
monotonicity.

p.
Bruce Ashfield - Aug. 19, 2011, 12:53 p.m.
On Fri, Aug 19, 2011 at 5:43 AM, Phil Blundell <philb@gnu.org> wrote:
> On Fri, 2011-08-19 at 01:20 -0400, Bruce Ashfield wrote:
>> diff --git a/meta/recipes-kernel/linux/linux-yocto_3.0.bb b/meta/recipes-kernel/linux/linux-yocto_3.0.bb
>> index 44f1ebe..5d9871f 100644
>> --- a/meta/recipes-kernel/linux/linux-yocto_3.0.bb
>> +++ b/meta/recipes-kernel/linux/linux-yocto_3.0.bb
>> @@ -11,7 +11,7 @@ KMACHINE_qemuarm  = "yocto/standard/arm-versatile-926ejs"
>>  KBRANCH = ${KMACHINE}
>>  KMETA = meta
>>
>> -LINUX_VERSION ?= "3.0.1"
>> +LINUX_VERSION ?= "3.0"
>>  LINUX_VERSION_EXTENSION ?= "-yocto-${LINUX_KERNEL_TYPE}"
>>
>>  SRCREV_machine_qemuarm = "36b4cdddcafc711f0ec9ad97882f23a6443c61b2"
>
> That's going to cause PV to go backwards, right?  If you're going to do
> that then you probably ought to consider bumping PE to retain
> monotonicity.

Indeed. I always just think of LINUX_VERSION as yet another package internal
variable (from non-bitbake experience), so tweaking it has no impact
on this sort
of thing.

I can look into changing the epoch .. but not until Monday or later in
the weekend.

Cheers,

Bruce

>
> p.
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
Richard Purdie - Aug. 19, 2011, 5:24 p.m.
On Fri, 2011-08-19 at 08:53 -0400, Bruce Ashfield wrote:
> On Fri, Aug 19, 2011 at 5:43 AM, Phil Blundell <philb@gnu.org> wrote:
> > On Fri, 2011-08-19 at 01:20 -0400, Bruce Ashfield wrote:
> >> diff --git a/meta/recipes-kernel/linux/linux-yocto_3.0.bb b/meta/recipes-kernel/linux/linux-yocto_3.0.bb
> >> index 44f1ebe..5d9871f 100644
> >> --- a/meta/recipes-kernel/linux/linux-yocto_3.0.bb
> >> +++ b/meta/recipes-kernel/linux/linux-yocto_3.0.bb
> >> @@ -11,7 +11,7 @@ KMACHINE_qemuarm  = "yocto/standard/arm-versatile-926ejs"
> >>  KBRANCH = ${KMACHINE}
> >>  KMETA = meta
> >>
> >> -LINUX_VERSION ?= "3.0.1"
> >> +LINUX_VERSION ?= "3.0"
> >>  LINUX_VERSION_EXTENSION ?= "-yocto-${LINUX_KERNEL_TYPE}"
> >>
> >>  SRCREV_machine_qemuarm = "36b4cdddcafc711f0ec9ad97882f23a6443c61b2"
> >
> > That's going to cause PV to go backwards, right?  If you're going to do
> > that then you probably ought to consider bumping PE to retain
> > monotonicity.
> 
> Indeed. I always just think of LINUX_VERSION as yet another package internal
> variable (from non-bitbake experience), so tweaking it has no impact
> on this sort
> of thing.
> 
> I can look into changing the epoch .. but not until Monday or later in
> the weekend.

I'm not 100% convinced that this is a good idea. I'd really prefer the
kernel accurately reflected the version it was. Can we not do:

PREFERRRED_VERSION_xxx = "3.0%"

to get around the preferred version issues?

Cheers,

Richard
Khem Raj - Aug. 19, 2011, 7:05 p.m.
On Fri, Aug 19, 2011 at 10:24 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>
> I'm not 100% convinced that this is a good idea. I'd really prefer the
> kernel accurately reflected the version it was. Can we not do:
>
> PREFERRRED_VERSION_xxx = "3.0%"
>

yes I would prefer that too

> to get around the preferred version issues?
>
> Cheers,
>
Bruce Ashfield - Aug. 19, 2011, 8:51 p.m.
On Fri, Aug 19, 2011 at 1:24 PM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Fri, 2011-08-19 at 08:53 -0400, Bruce Ashfield wrote:
>> On Fri, Aug 19, 2011 at 5:43 AM, Phil Blundell <philb@gnu.org> wrote:
>> > On Fri, 2011-08-19 at 01:20 -0400, Bruce Ashfield wrote:
>> >> diff --git a/meta/recipes-kernel/linux/linux-yocto_3.0.bb b/meta/recipes-kernel/linux/linux-yocto_3.0.bb
>> >> index 44f1ebe..5d9871f 100644
>> >> --- a/meta/recipes-kernel/linux/linux-yocto_3.0.bb
>> >> +++ b/meta/recipes-kernel/linux/linux-yocto_3.0.bb
>> >> @@ -11,7 +11,7 @@ KMACHINE_qemuarm  = "yocto/standard/arm-versatile-926ejs"
>> >>  KBRANCH = ${KMACHINE}
>> >>  KMETA = meta
>> >>
>> >> -LINUX_VERSION ?= "3.0.1"
>> >> +LINUX_VERSION ?= "3.0"
>> >>  LINUX_VERSION_EXTENSION ?= "-yocto-${LINUX_KERNEL_TYPE}"
>> >>
>> >>  SRCREV_machine_qemuarm = "36b4cdddcafc711f0ec9ad97882f23a6443c61b2"
>> >
>> > That's going to cause PV to go backwards, right?  If you're going to do
>> > that then you probably ought to consider bumping PE to retain
>> > monotonicity.
>>
>> Indeed. I always just think of LINUX_VERSION as yet another package internal
>> variable (from non-bitbake experience), so tweaking it has no impact
>> on this sort
>> of thing.
>>
>> I can look into changing the epoch .. but not until Monday or later in
>> the weekend.
>
> I'm not 100% convinced that this is a good idea. I'd really prefer the
> kernel accurately reflected the version it was. Can we not do:
>
> PREFERRRED_VERSION_xxx = "3.0%"
>
> to get around the preferred version issues?

Both Darren and I tried variants of this but couldn't get it to match, but I can
certainly try again. This was also my first attempt when bumping the string.

But as I mentioned multiple times before, even changing the version with
sub releases is a change from how I handled it before, so from that point
of view, I never should have entered into tweaking this. :)

Bruce

>
> Cheers,
>
> Richard
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
Bruce Ashfield - Aug. 20, 2011, 3:51 a.m.
On Fri, Aug 19, 2011 at 4:51 PM, Bruce Ashfield
<bruce.ashfield@gmail.com> wrote:
> On Fri, Aug 19, 2011 at 1:24 PM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
>> On Fri, 2011-08-19 at 08:53 -0400, Bruce Ashfield wrote:
>>> On Fri, Aug 19, 2011 at 5:43 AM, Phil Blundell <philb@gnu.org> wrote:
>>> > On Fri, 2011-08-19 at 01:20 -0400, Bruce Ashfield wrote:
>>> >> diff --git a/meta/recipes-kernel/linux/linux-yocto_3.0.bb b/meta/recipes-kernel/linux/linux-yocto_3.0.bb
>>> >> index 44f1ebe..5d9871f 100644
>>> >> --- a/meta/recipes-kernel/linux/linux-yocto_3.0.bb
>>> >> +++ b/meta/recipes-kernel/linux/linux-yocto_3.0.bb
>>> >> @@ -11,7 +11,7 @@ KMACHINE_qemuarm  = "yocto/standard/arm-versatile-926ejs"
>>> >>  KBRANCH = ${KMACHINE}
>>> >>  KMETA = meta
>>> >>
>>> >> -LINUX_VERSION ?= "3.0.1"
>>> >> +LINUX_VERSION ?= "3.0"
>>> >>  LINUX_VERSION_EXTENSION ?= "-yocto-${LINUX_KERNEL_TYPE}"
>>> >>
>>> >>  SRCREV_machine_qemuarm = "36b4cdddcafc711f0ec9ad97882f23a6443c61b2"
>>> >
>>> > That's going to cause PV to go backwards, right?  If you're going to do
>>> > that then you probably ought to consider bumping PE to retain
>>> > monotonicity.
>>>
>>> Indeed. I always just think of LINUX_VERSION as yet another package internal
>>> variable (from non-bitbake experience), so tweaking it has no impact
>>> on this sort
>>> of thing.
>>>
>>> I can look into changing the epoch .. but not until Monday or later in
>>> the weekend.
>>
>> I'm not 100% convinced that this is a good idea. I'd really prefer the
>> kernel accurately reflected the version it was. Can we not do:
>>
>> PREFERRRED_VERSION_xxx = "3.0%"
>>
>> to get around the preferred version issues?

I reset my environment and re-did my tests .. and this does match what
we want. I'm gong to re-spin my series with a version bump to 3.0.3 and
I'll update the preferred versions that I know about to this format.

Cheers,

Bruce

>
> Both Darren and I tried variants of this but couldn't get it to match, but I can
> certainly try again. This was also my first attempt when bumping the string.
>
> But as I mentioned multiple times before, even changing the version with
> sub releases is a change from how I handled it before, so from that point
> of view, I never should have entered into tweaking this. :)
>
> Bruce
>
>>
>> Cheers,
>>
>> Richard
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end"
>

Patch

diff --git a/meta/recipes-kernel/linux/linux-yocto_3.0.bb b/meta/recipes-kernel/linux/linux-yocto_3.0.bb
index 44f1ebe..5d9871f 100644
--- a/meta/recipes-kernel/linux/linux-yocto_3.0.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_3.0.bb
@@ -11,7 +11,7 @@  KMACHINE_qemuarm  = "yocto/standard/arm-versatile-926ejs"
 KBRANCH = ${KMACHINE}
 KMETA = meta
 
-LINUX_VERSION ?= "3.0.1"
+LINUX_VERSION ?= "3.0"
 LINUX_VERSION_EXTENSION ?= "-yocto-${LINUX_KERNEL_TYPE}"
 
 SRCREV_machine_qemuarm = "36b4cdddcafc711f0ec9ad97882f23a6443c61b2"