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

[richard.purdie at linuxfoundation.org]

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!

Cheers,

Richard