Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Broken core-image-minimal for qemu targets #17

Open
ismaell opened this issue May 21, 2019 · 11 comments
Open

Broken core-image-minimal for qemu targets #17

ismaell opened this issue May 21, 2019 · 11 comments

Comments

@ismaell
Copy link

ismaell commented May 21, 2019

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.

@slawr
Copy link
Contributor

slawr commented May 21, 2019

Thank you for the report. Can you provide details please. What is the failure? Did you isolate the cause?

@ismaell
Copy link
Author

ismaell commented May 21, 2019

$ 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.
$

@ismaell
Copy link
Author

ismaell commented May 21, 2019

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

@slawr
Copy link
Contributor

slawr commented May 21, 2019

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.

@ismaell
Copy link
Author

ismaell commented May 22, 2019

One does not simply break the base layers

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.

@ismaell
Copy link
Author

ismaell commented May 27, 2019

@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.

@slawr
Copy link
Contributor

slawr commented May 31, 2019

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.

@ismaell
Copy link
Author

ismaell commented Jun 5, 2019

@slawr seems dead, who is responsible for this layer?

@slawr
Copy link
Contributor

slawr commented Jun 6, 2019

@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.

@ismaell
Copy link
Author

ismaell commented Jun 11, 2019

@slawr sadly that's not an option, I'm dealing with prototypes...

@slawr
Copy link
Contributor

slawr commented Jun 11, 2019

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants