| 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
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.
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 >
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
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, >
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 >
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"
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(-)