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

[Quentin Schulz <quentin.schulz@theobroma-systems.com>]

Hi Patrick,

On 7/26/22 17:57, Patrick Williams wrote:
> On Tue, Jul 26, 2022 at 07:35:21AM +0200, Alexander Kanavin wrote:
>> On Tue, 26 Jul 2022 at 06:09, Patrick Williams <patrick@stwcx.xyz> wrote:
>>> 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.
>>
>> This is not how machine-specific versions of the same file are
>> supposed to be listed. Just use `file://eeprom.h`, and bitbake will
>> look for it in subdirectories that include $MACHINE, and if not found
>> there, a default version will be picked (which you can make bogus, so
>> builds will fail at recipe build stage instead of parsing stage).
>>
>> Example:
>> https://git.yoctoproject.org/poky/tree/meta/recipes-graphics/xorg-xserver/xserver-xf86-config?h=master-next
> 
> I agree.  The person who originally wrote the recipe didn't know about
> the automatic addition of overrides with the FILESEXTRAPATHS.  As I
> wrote this was just one easy example.  I fixed this one to both use the
> override implicitly (as you also suggested) and put a default 'eeprom.h'
> with a `#error`[1].
> 
> A seriously more complex example we have is that we have our own u-boot
> recipes and used the same `u-boot-foo.inc` file names as are present in
> `meta/`.  It happens that the recipes in `meta/recipes-bsp/u-boot` end
> up, even though we'd never use them, using our `u-boot-foo.inc` files
> and ending up with totally bogus SRC_URIs in the parsing phase (and
> thus failing).  Essentially, whenever there is a new version of u-boot
> in `meta` we're going to end up having to make some bogus empty
> files[2].
> 

Alexander already suggested to use a slightly different recipe name (and 
then you can pick which recipe you want from a configuration file with 
PREFERRED_PROVIDER_u-boot = "" IIRC), but I'm actually surprised by the 
behavior you mention seeing.

The original u-boot recipe uses "require" with just the filename, c.f. 
https://cgit.openembedded.org/openembedded-core/tree/meta/recipes-bsp/u-boot/u-boot_2022.07.bb?h=master, 
etc... there's not a single recipes-bsp/u-boot returned by git grep in 
openembedded-core... My understanding of the require mechanism so far is 
that if you pass it a filename, it'll only look into the current 
directory (where the recipe is located) and if it has a path, it'll look 
for that path in all layers (well, BBPATH, which in the majority of 
cases should be LAYERDIR, the root of the layer). Since there is no path 
in require for the u-boot recipes in openmebedded-core, I don't 
understand what you're saying happens happens. c.f. 
https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-metadata.html#require-directive 
for the doc on require directive.

This highlights one of the following:
  - a rogue bbappend or some weird configuration in one the layers in use,
  - a bug/corner-case in require directive,

Maybe there's something to fix or document, hence why I'm writing this 
mail, it'd be good to actually be able to reproduce this and understand 
why it happens.

Cheers,
Quentin