[PATCH 0/7] binman: Check code-coverage requirements
Tom Rini
trini at konsulko.com
Thu Feb 27 18:04:41 CET 2025
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 <trini at 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 <trini at 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 <trini at 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.
> 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.
> I also just found the membuf thing was never applied.
Was that the one where Rasmus asked you to do it differently?
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20250227/ba5b6a3d/attachment.sig>
More information about the U-Boot
mailing list