On Sat, Sep 30, 2023 at 7:07 AM Richard Purdie < richard.pur...@linuxfoundation.org> wrote:
> Hi Bruce, > > On Fri, 2023-09-29 at 16:04 -0400, bruce.ashfi...@gmail.com wrote: > > Given where we are in the release cycle, this clearly is NOT a typical > > consolidated pull request. > > > > I've done what normally takes about three weeks in about 4 days. > > Thanks, I know this isn't where any of us wanted to be. > > > > > With 6.4 going EOL before expected upstream, it really isn't a suitable > > reference kernel for the release. > > > > So we've decided to take on the task of getting 6.5 ready and available, > > and at the same time moving the -dev kernel to v6.6. The -dev kernel > > testing for 6.5 was critical for this, since I already knew the core > > was sane. > > > > Also we've never shipped purposely mismatched libc-headers in the > release, > > so I also took the leap to update the libc-headers to match. > > Agreed on both counts, I think we need to make 6.5 work. > > > I've already sent fixes to meta-oe, and there's a btrfs update in this > > series to fix breakage that I found in the tightly coupled packages. > > I think btrfs-tools was already upgraded in master? > Ah bugger. That would have saved me some time :) > > > I've built and booted core-image-kernel-dev, core-image-minimal, > core-image-sato > > for both glibc and musl for all the supported architectures. > > There will be some things that break regardless, but this needs the > > better coverage of the AB. > > > > If this causes too much problems, our choices are to ship 6.4 EOLd, or > > fall all the way back to 6.1. > > > > I'll remove 6.4 from master once we've figured out the fallout from > > this kernel, and which direction we are going. > > 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). 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. Bruce > Since we're short on time, I regenerated the series re-running the CVE > script and rebuilding that piece of each commit. I suspect now we > understand what happened we'll be able to better handle it in future. > > The first autobuilder test run crashed and burned due to unrelated > patches. I've a new build running: > > https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/5969 > > 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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#188461): https://lists.openembedded.org/g/openembedded-core/message/188461 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] -=-=-=-=-=-=-=-=-=-=-=-
