[OE-core] [PATCH 00/17] linux-yocto: consolidated pull request

[Bruce Ashfield]

On Mon, Dec 17, 2018 at 8:46 AM <richard.purdie at linuxfoundation.org> wrote:
>
> On Mon, 2018-12-17 at 08:37 -0500, Bruce Ashfield wrote:
> > On Mon, Dec 17, 2018 at 7:26 AM <richard.purdie at linuxfoundation.org>
> > wrote:
> > > Hi Bruce,
> > >
> > > On Sun, 2018-12-16 at 22:38 -0500, Bruce Ashfield wrote:
> > > > Here is the latest linux-yocto consolidated pull request. Some of
> > > > these commits are re-sends of changes that didn't make the
> > > > release,
> > > > and others are new.
> > > >
> > > > Most are routine -stable bumps, configuration cleanups, etc, and
> > > > shouldn't cause any issues.
> > > >
> > > > The more interesting part of this queue is the introduction of
> > > > 4.19
> > > > reference kernels to replace 4.14 as the LTS version in master.
> > > > I've
> > > > built and booted it on qemu*, so it is sane from that point of
> > > > view.
> > > >
> > > > I'm trying to separate out the kernel bumps into distict pull
> > > > requests so I can deal with one set of issues at a time:
> > > >
> > > >  - I'm not removing 4.18 yet, since it will be replaced by 4.20+
> > > > as
> > > > the "latest" kernel in the next release. Plus our h/w reference
> > > > BSPs
> > > > need to be updated before I can drop it.
> > > >
> > > >  - I'm not bumping libc-headers in this pull, I'll do that in my
> > > > next
> > > > queue, and we'll jump to 4.20 for the libc-headers at that time.
> > > > There will be one more bump to match the 'latest' reference
> > > > kernel
> > > > for the release.
> > > >
> > > > I will also follow up to the appropriate list with a bump to the
> > > > poky-lsb distro
> > > > builds that are using 4.14 as their default kernel version.
> > > >
> > > > I'm not convinced this is issue free (i.e. did I miss some
> > > > reference
> > > > to a 4.14 kernel ??),
> > >
> > > The bbappend in meta-yocto-bsp? ;-)
> > >
> > > (I deleted it)
> >
> > ahaha. Did you want me to add that to my queue (a delete of it),
> > since I'll have
> > a look at the 4.18 version bump and see what happened to qemumips64.
> >
> > Or I can send an incremental 4.18 patch (since I see there's another
> > version
> > bump for it available now), and take care of that issue without
> > resending the
> > queue. Whatever is easiest for you.
>
> At this point an incremental patch is probably easiest since I have the
> other patches in -next, thanks!

will do.

The "good" news, is that qemumips64 also fails the same way with 4.19.
So this isn't something that came in only with the -stable update to
4.18.

I poked on the autobuilder, and it looks like master last built 14
hours ago for qemumips64 (build 101), I couldn't clearly see the
config in that build, but I assume that was 4.18.x

Cheers,

Bruce

>
> Cheers,
>
> Richard
>
>
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II