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

[Bruce Ashfield]

On Fri, Aug 19, 2011 at 4:51 PM, Bruce Ashfield
<bruce.ashfield at gmail.com> wrote:
> On Fri, Aug 19, 2011 at 1:24 PM, Richard Purdie
> <richard.purdie at 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 at 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 at 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"
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"