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

Submitted by Bruce Ashfield on Aug. 19, 2011, 5:20 a.m.

Details

Message ID e7036174cf607031e13323564f402c7b805e4572.1313730559.git.bruce.ashfield@windriver.com
State New, archived
Headers show

Commit Message

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(-)

Patch hide | download patch | download mbox

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"

Comments

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"
>