[PATCH v3 0/6] Fix handling of optional blobs in binman

[Tim Harvey]

On Thu, Aug 14, 2025 at 11:46 PM Yannic Moog <Y.Moog at phytec.de> wrote:
>
> Am Freitag, dem 15.08.2025 um 05:44 +0000 schrieb Yannic Moog:
> > Hi Tim,
> >
> > Am Donnerstag, dem 14.08.2025 um 12:54 -0700 schrieb Tim Harvey:
> > > On Thu, Jun 26, 2025 at 10:57 AM Tom Rini <trini at konsulko.com> wrote:
> > > >
> > > > On Fri, 13 Jun 2025 14:02:39 +0200, Yannic Moog wrote:
> > > >
> > > > > This series solves a contradiction regarding ext blobs packaged in
> > > > > binman. When they are marked as optional, by default they are faked, two
> > > > > messages are emitted. One says the image is not functional the other
> > > > > says the image is still functional. Both concern the same binman
> > > > > entry/blob.
> > > > >
> > > > > Binman is set up to have fake external blobs in case they are missing.
> > > > > This is regardless on whether they are optional or not.
> > > > > The implementation does not allow different types of entries to override
> > > > > the faking decision; at least there wouldn't be much sense in doing so.
> > > > >
> > > > > [...]
> > > >
> > > > Applied to u-boot/next, thanks!
> > > >
> > > > [1/6] binman: drop "faked" return value from check_fake_fname
> > > >       commit: a657d87f08789c4c50423897bd5ee052c6223ee6
> > > > [2/6] binman: mark optional missing blobs as absent
> > > >       commit: 3ae668b9d2101d111d257ee7d8912c19cfb0e102
> > > > [3/6] binman: rework dropping absent entries from packaged image
> > > >       commit: 21bc3433a43d3add3430543c9eee2a95d4dee2f6
> > > > [4/6] binman: add faked optional entry case in CheckForProblems
> > > >       commit: f5817e05efd39dd455c2e6a0f0622d709fe7ea2d
> > > > [5/6] binman: ftest: pass allow_fake_blob to _DoReadFileDtb
> > > >       commit: e749d64b4622806072c56a839cf9a36a5081b575
> > > > [6/6] binman: test: assert optional blobs don't cause non-functionality
> > > >       commit: 0dbb0a8d1f2aefb2a7fdd8e627edd955e4fe8d3a
> > > > --
> > > > Tom
> > > >
> > > >
> > >
> > > Hi Yannic,
> > >
> > > I haven't had time to dig into it in detail yet but it looks like
> > > imx8m boards are failing again in master due to tee changes again and
> > > perhaps its this series that is causing it.
> >
> > Thanks for reporting,
> >
> > >
> > > Here's what I see with today's mater:
> > > make imx8mm_evk_defconfig
> > > make
> > > ...
> > >   BINMAN  .binman_stamp
> > > Image 'image' is missing optional external blobs but is still functional:
> > > tee-
> > > os
> > >
> > > binman: module 'importlib.resources' has no attribute 'files'
> > > make: *** [Makefile:1339: .binman_stamp] Error 1
> > >
> > > I thought I had read something about a warning that wasn't an error
> > > but above is clearly a build failure.
> > >
> > > Am I missing something here?
> >
> > My initial gut feeling says it could be related to this series:
> > https://lore.kernel.org/u-boot/20250701-pkg_resoures-removal-v3-1-270188b335ae@phytec.de/
> >
> > Maybe the combination of the 2 series causes this. Anyway, I'll investigate
> > and
> > report back.
>
> So the error you are seeing is encountered here:
> https://github.com/u-boot/u-boot/blob/0c558bbad9e7581808b358091d1fd979f860e8ac/tools/binman/control.py#L98
>
> This is indeed caused by the patch I linked above.
> When writing the patch (i.e. following the migration guide) I foolishly
> overlooked the fact that importlib.resources.files was only introduced in python
> 3.9, yet we support >=3.7.
>
> I remember you use python 3.8, so that is why you see the error (and I don't).

Hi Yannic,

I confirmed via docker containers that ubuntu-noble 24.04 (python
3.12.3) and ubuntu-jammy 22.04.04 (python 3.10.12) build ok and that
ubuntu-focal 20.04.6 (python 3.8.10) which I was using fails.

I recall Tom saying we should aim for supporting Python 3.7+

>
> I believe I need some help on finding a good solution.
> For this diff
>
> -    glob_list = pkg_resources.resource_listdir(__name__, 'etype')
> -    glob_list = [fname for fname in glob_list if fname.endswith('.py')]
> +    entries = importlib_resources.files(__package__).joinpath('etype')
> +    glob_list = [entry.name for entry in entries.iterdir()
> +                 if entry.name.endswith('.py') and entry.is_file()]
>
> I haven't found a good replacement that is python 3.7 compatible.
> Any ideas?

Sorry, I haven't embraced the snake.

I guess I should update my build system to stop hitting this stuff :)

Best Regards,

Tim