Hi Tom, On Tue, 4 Mar 2025 at 07:20, Tom Rini <tr...@konsulko.com> wrote: > > On Tue, Mar 04, 2025 at 06:10:27AM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 27 Feb 2025 at 10:04, Tom Rini <tr...@konsulko.com> wrote: > > > > > > On Thu, Feb 27, 2025 at 09:25:25AM -0700, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Tue, 25 Feb 2025 at 14:53, Tom Rini <tr...@konsulko.com> wrote: > > > > > > > > > > On Tue, Feb 25, 2025 at 02:44:12PM -0700, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Tue, 25 Feb 2025 at 14:31, Tom Rini <tr...@konsulko.com> wrote: > > > > > > > > > > > > > > On Tue, Feb 25, 2025 at 02:26:39PM -0700, Simon Glass wrote: > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > On Tue, 25 Feb 2025 at 14:06, Tom Rini <tr...@konsulko.com> > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On Tue, Feb 25, 2025 at 01:06:25PM -0700, Simon Glass wrote: > > > > > > > > > > > > > > > > > > > This series adds a cover-coverage check to CI for Binman. > > > > > > > > > > The iMX8 tests > > > > > > > > > > are still not completed, so a work-around is included for > > > > > > > > > > those. > > > > > > > > > > > > > > > > > > > > A few fixes are included for some other problems. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Jiaxun Yang (1): > > > > > > > > > > binman: Workaround lz4 cli padding in test cases > > > > > > > > > > > > > > > > > > > > Simon Glass (6): > > > > > > > > > > binman: Exclude dist-packages and site-packages > > > > > > > > > > binman: Drop GetRootSkipAtStart() > > > > > > > > > > binman: fit: Drop unused code > > > > > > > > > > binman: Drop algo check in CheckSetHashValue() > > > > > > > > > > binman: Workaround missing test coverage > > > > > > > > > > CI: Run code-coverage test for Binman > > > > > > > > > > > > > > > > > > While we likely need Jiaxun's fix in order to be able to > > > > > > > > > update to > > > > > > > > > Ubuntu 24.04, the series itself doesn't apply to -next, > > > > > > > > > please rebase if > > > > > > > > > you intend for this to be in mainline, thanks. > > > > > > > > > > > > > > > > OK, would you able to pick this series up? > > > > > > > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/list/?series=444576 > > > > > > > > > > > > > > It also doesn't apply. You should really put together a PR, > > > > > > > against > > > > > > > next. > > > > > > > > > > > > Oh, it needs another patch anyway. I'll send a v2. Once that is in I > > > > > > can rework this one. > > > > > > > > > > Again, it would be helpful if you would send a PR and always base your > > > > > patches on the appropriate upstream branch. > > > > > > > > I understand that, and I'm happy to rebase / resend when you are ready > > > > to apply. I'd like to keep the diff as small as we can. But I don't > > > > think it should hold up reviews, otherwise we're just going to diverge > > > > further. When you reject patches for your tree I typically apply them > > > > to my tree in the hope that they might find favour in future. > > > > > > I think you've got this backwards still. > > > > > > > For the skip-at-start series I sent a series, which you have seen. > > > > > > Yes, and what blocked them to start with is they defaulted to your tree > > > and not mainline. > > > > I can send a pull request for things, but your tree is missing things > > and that seems to be growing over time. > > By definition your downstream fork is missing things. That's on you to > fix, not me.
Yes, so let's try to minimise that where we can. > > > As you have seen, I sent [1] to test the water so we'll see how it fares. > > That's not a very kind way to put it, given that I've only stopped > applying your various series once they don't apply to upstream. And > since that's actually fixing platforms and not just tidying up code I'll > likely apply that later today. OK good, thank you. > > > > > Speaking of patches, the PXE series seems to have got lost. It is > > > > 'changes requested' but I'm not sure what changes are needed. > > > > > > The changes requested was that it breaks lwIP + tftp. You asked that I > > > ignore that since it wasn't failing in public CI, I said it was failing > > > in my CI. I then noticed that it should have failed in public CI (and > > > likely was on Azure, but that's often overloaded enough I cancel runs > > > when I see failures elsewhere). So I then fixed public CI so that the > > > lwIP platforms there too should fail. > > > > Well I did offer to add a test in my lab...I'll take another look at some > > point. > > Well, it's blocked until it doesn't break platforms. OK I'll have another try. > > > > > I also just found the membuf thing was never applied. > > > > > > Was that the one where Rasmus asked you to do it differently? > > > > Yes and I spent quite a bit of time investigating, and replied, but > > didn't see any further response. The power-of-two idea is too > > restrictive and anyway is beyond the scope of my series which is > > mostly to add some tests and align the naming better with U-Boot. I > > did suggest some follow-on ideas. Anyway, I am wanting to use it in > > future series, so it would be good to apply it. > > No, I'm not going to apply something where the feedback starts with "No, > that is the worst of all worlds". Well, perhaps he's just wrong. I'll reply again. I've applied it to my tree. Regards, Simon
