[OE-core] [PATCH 2/3] linux-yocto/3.10: update to 3.10.25

Richard Purdie richard.purdie at linuxfoundation.org
Wed Jan 15 15:46:49 UTC 2014


On Wed, 2014-01-15 at 10:11 -0500, Bruce Ashfield wrote:
> On 14-01-15 10:06 AM, Richard Purdie wrote:
> > On Wed, 2014-01-15 at 00:57 -0500, Bruce Ashfield wrote:
> >> Updating the 3.10 tree to the 3.10.25 korg -stable release.
> >>
> >> Signed-off-by: Bruce Ashfield <bruce.ashfield at windriver.com>
> >> ---
> >>   meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb   | 10 ++++------
> >>   meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb |  6 +++---
> >>   meta/recipes-kernel/linux/linux-yocto_3.10.bb      | 18 +++++++++---------
> >>   3 files changed, 16 insertions(+), 18 deletions(-)
> >>
> >> diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb b/meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb
> >> index e81a77ba4ea5..d301c06eae37 100644
> >> --- a/meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb
> >> +++ b/meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb
> >> @@ -3,13 +3,11 @@ require recipes-kernel/linux/linux-yocto.inc
> >>   KBRANCH = "standard/preempt-rt/base"
> >>   KBRANCH_qemuppc = "standard/preempt-rt/qemuppc"
> >>
> >> -SRCREV_machine ?= "ee9480cd91b2b46325a2da9aa6ae779d8e4163c0"
> >> -SRCREV_machine_qemuppc ?= "5c126504c0a2f72d80bae9d96cea7eb9d7854290"
> >> -SRCREV_meta ?= "d9cd83c0292bd4e2a6754a96761027252e726a42"
> >> +SRCREV_machine ?= "957ba6ae6c1d81b57da6a36b93f1b2a0ced2f45d"
> >> +SRCREV_machine_qemuppc ?= "37e40b7017a9c78d676b19716011494dc7cb6369"
> >> +SRCREV_meta ?= "778d5f6259f0b8e28a46d8a764979e20e5a8ffc4"
> >>
> >> -SRC_URI = "git://git.yoctoproject.org/linux-yocto-3.10.git;bareclone=1;branch=${KBRANCH},meta;name=machine,meta"
> >> -
> >
> > I'm guessing this shouldn't remove the above line? It triggers parse
> > failures...
> 
> urk. He who rebases patch series late at night, shouldn't hit send until
> the morning.
> 
> That was aggressive trailing whitespace cleanup gone bad. If you can
> restore it, I'll be eternally grateful. Or I can resend, but that
> seems like excessive overhead for an obvious mess up.

I've tweaked it in master-next.

Cheers,

Richard




More information about the Openembedded-core mailing list