[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openembedded-core
Subject:    Re: [OE-core] [PATCH 00/10] kernel: consolidated pull request
From:       "Richard Purdie" <richard.purdie () linuxfoundation ! org>
Date:       2023-09-30 17:26:45
Message-ID: cc6fc822a636a0e000f9667099618eca0f1e251e.camel () linuxfoundation ! org
[Download RAW message or body]

On Sat, 2023-09-30 at 13:05 -0400, Bruce Ashfield wrote:
> On Sat, Sep 30, 2023 at 12:58 PM Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > On Sat, 2023-09-30 at 12:33 -0400, Bruce Ashfield wrote:
> > > On Sat, Sep 30, 2023 at 7:07 AM Richard Purdie
> > > <richard.purdie@linuxfoundation.org> wrote:
> > > 
> > > > 
> > > > I had some difficulties with this series since it doesn't apply
> > > > against
> > > > master. The issue was that someone else had updated the kernel
> > > > CVEs
> > > > and
> > > > those changes weren't in your tree (nor was the btrfs upgrade).
> > > > This
> > > > meant all the cve inc changes threw errors. We will likely need
> > > > to
> > > > assume someone will update the CVE includes semi regularly just
> > > > so
> > > > we
> > > > can keep the noise on the CVE reports down.
> > > > 
> > > 
> > > 
> > > That's odd. I always do a pull --rebase before sending my
> > > changes,
> > > but yet none of them showed up   (on any of my builders, so I had
> > > 3x
> > > machines running that queue of patches and none of them had the
> > > changes from master).
> > 
> > I don't know what happened but you were definitely not on a recent
> > master branch as the changes did not apply.
> > 
> > > For the kernel CVEs. They either need to be part of my kernel
> > > releases or not. I've updated my scripts, and they'll always be
> > > updated as part of the process. Having something / someone else
> > > update that file is just a huge pain, and we shouldn't do that.
> > 
> > The question is whether you're able to just update the CVE
> > revisions
> > out of cycle with the kernel point release bumps?
> > 
> 
> 
> I mean I could, but that's not something I want to take on. I'm not
> actively monitoring the kernel CVEs, and take the fixes as they flow
> through -stable and are tested in my sanity. So the only point they
> matter (to me) is when a -stable bump proves to be sane enough to
> send to the list with bumped SRCREVs.
> 
> I'm going to drop the part of my script that updates the CVE file
> when I do a release, since the conflicts are such a hassle when I'm
> working through my -stable queue. I sometimes need to hold it for a
> week (or more) depending on what is broken or what part of the cycle
> we are in.
> 
> It sounds like there's a better solution down the road, so me
> dropping the update of the .inc file won't be an issue for long.

Ok, I'll need to do it when I process your patches but I've just proven
I can do that.

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#188464): https://lists.openembedded.org/g/openembedded-core/message/188464
Mute This Topic: https://lists.openembedded.org/mt/101665418/4454766
Group Owner: openembedded-core+owner@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [openembedded-core@marc.info]
-=-=-=-=-=-=-=-=-=-=-=-



[prev in list] [next in list] [prev in thread] [next in thread]