Re: [PATCH 2/2] fetch: bb.fatal when trying to checksum non-existing files.

[Paulo Neves <ptsneves@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2790 bytes --]

That is what I do. If the recipe is machine specific it should be marked as
such.

On Tue, 26 Jul 2022 at 08:39, Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:

> On Mon, 2022-07-25 at 23:09 -0500, Patrick Williams wrote:
> > On Fri, Jul 08, 2022 at 10:54:07PM +0200, Paulo Neves wrote:
> > > If the local fetcher was not able to find the file anywhere but it
> > > was included in the SRC_URI for checksumming just make it a fatal
> > > error.
> > > ---
> > >  lib/bb/fetch2/__init__.py | 2 +-
> > >  lib/bb/tests/fetch.py     | 5 +++++
> > >  2 files changed, 6 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/lib/bb/fetch2/__init__.py b/lib/bb/fetch2/__init__.py
> > > index 5f05278a..8184b55e 100644
> > > --- a/lib/bb/fetch2/__init__.py
> > > +++ b/lib/bb/fetch2/__init__.py
> > > @@ -1237,7 +1237,7 @@ def get_checksum_file_list(d):
> > >                              " This means there is no way to get the
> file except for an orphaned copy"
> > >                              " in DL_DIR.") % (d.getVar('PN'),
> os.path.basename(f)))
> > >                      else:
> > > -                        bb.warn("Unable to get checksum for %s
> SRC_URI entry %s: file could not be found" % (d.getVar('PN'),
> os.path.basename(f)))
> > > +                        bb.fatal("Unable to get checksum for %s
> SRC_URI entry %s: file could not be found" % (d.getVar('PN'),
> os.path.basename(f)))
> >
> > Now that we've picked up this change, it seems to have caused a bunch of
> > irritating hard failures where we use to just get irritating warnings.
> > Our recipes probably aren't 100% ideal, but we had a number of recipes
> > which are not pulled into all our machine configs, and could end up with
> > broken SRC_URIs on machine configs they are not intended to be used on.
> >
> > There are some more complex examples, but one easy example is a recipe
> > which had `file://${MACHINE}/eeprom.h` in its SRC_URI[1].  Any machine
> > which didn't provide this file, even if it never intended to use the
> > recipe, now fails when we picked up this change.
> >
> > I know we've been ignoring the warning(s) for a while on these kinds of
> > failures, so it is our own fault, but it is kind of annoying the new
> > behavior.  We now have to make sure every recipe not only parses validly
> > on all machine configs but it also has to have fully populated SRC_URIs
> > even when the recipe is never used on that machine config.
> >
> > 1.
> https://github.com/facebook/openbmc/blob/f0d9511ad2fbd563a6b793093cdac557c5ef2a89/meta-facebook/recipes-utils/mac-util/mac-util_0.1.bb#L12
>
> I'm just going from memory but it might help to set COMPATIBLE_MACHINE
> in the recipe so that it isn't fully parsed for the machines it isn't
> intended for.
>
> Cheers,
>
> Richard
>
>
>

[-- Attachment #2: Type: text/html, Size: 3736 bytes --]