On Sat, 2023-09-30 at 13:05 -0400, Bruce Ashfield wrote: > On Sat, Sep 30, 2023 at 12:58 PM Richard Purdie > <richard.pur...@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.pur...@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/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
