Open ismaell opened 5 years ago
Thank you for the report. Can you provide details please. What is the failure? Did you isolate the cause?
$ MACHINE=qemuarm64 bitbake core-image-minimal
Loading cache: 100% |###############################################################| Time: 0:00:00
Loaded 3049 entries from dependency cache.
Parsing recipes: 100% |#############################################################| Time: 0:00:01
Parsing of 2201 .bb files complete (2197 cached, 4 parsed). 3052 targets, 310 skipped, 11 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
ERROR: Nothing RPROVIDES 'optee-client' (but /home/sg/yocto/build/../openembedded-core/meta/recipes-core/images/core-image-minimal.bb RDEPENDS on or otherwise requires it)
optee-client was skipped: incompatible with machine qemuarm64 (not in COMPATIBLE_MACHINE)
NOTE: Runtime target 'optee-client' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['optee-client']
ERROR: Required build target 'core-image-minimal' has no buildable providers.
Missing or unbuildable dependency chain was: ['core-image-minimal', 'optee-client']
Summary: There was 1 WARNING message shown.
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
$
The problem is you can't just import random things into recipes unless they're platform independent.
The core-image-minimal
bbappend contains:
require recipes-graphics/images/core-image-renesas-base.inc
Thanks for the update.
The
core-image-minimal
bbappend contains:require recipes-graphics/images/core-image-renesas-base.inc
Out of interest what is the use case for including meta-renesas in your bblayer but building for a non-Renesas platform? You like to have all layers for all of the machines you target in a single configuration?
As you say in that setup IMAGE_INSTALL appends would need machine qualifiers.
I have virtual hardware (several machines) which should build together because they're meant to be built all at once and run on the same platform. Also because it's a PITA to do continuous integration without fixing this.
@slawr I've added one include per SoC and replaced the require
by a an include
, would that be acceptable for inclusion?
If so I'll do a PR.
Hi @ismaell I'm not the maintainer of the layer so I can't give concrete guidance. I use the YBSP in my work in the Genivi automotive alliance. I saw the ticket and was interested in your use case.
I've not given it in depth thought and I'm not sure what you mean exactly by one include per SoC. I think I would have been tempted to start with your original point. Fixing the image bbappend so machine modifiers are used in the include if that would fix it. Certainly I can't see that file changing much so carrying a local patch until its changed upstream should not be a huge maintenance burden.
I'll mention it to the team.
@slawr seems dead, who is responsible for this layer?
@ismaell I can't speak for the team's processes but my advice, assuming you are using R-Car as part of a commercial project, would be to go through the support mechanism setup with Renesas for the project.
@slawr sadly that's not an option, I'm dealing with prototypes...
@ismaell if not possible then I would look to the community. The YBSP maintainer details are in the source. elinux.org is the central hub for R-Car h/w and s/w community. There you can find details about various upstreams such as the kernel. Then Renesas involves itself directly in various automotive communities. So you can find people working in Genivi, AGL and Autosar for example. Similar is also taking place in areas of ADAS such as OpenADx. That's for the general case for finding people working on R-Car.
Re this specific question as I said I'll raise it with the team.
This layer breaks the
core-image-minimal
target for all the qemu targets. The layer should only modify the package selection and other settings for the machines it intends to support, where such changes make sense.