Hey Ankur, On Wed, Nov 13, 2019 at 9:55 PM Ankur Tyagi <ankur.tyag...@gmail.com> wrote: > > Hi, > > I have a custom layer for custom board based upon am335x-evm and custom > images. > > I have a master layer called "my-custom-layer" which has three sub-layers > - my-custom-distro : custom distro based upon TI's 'arago' distro, Qt > and other s/w recipe appends > - my-custom-image : custom images, packagegroups, toolchain recipes > - my-custom-machine : custom machine conf, bsp and kernel recipes
Those config files are OK to create, but can you please tell how did you create your own machine? > > When I am building my image, it throws numerous warnings like below > for almost all packages in the image: > > eudev-3.2.7-r0.3.arago5 do_package_qa: QA Issue: libudev rdepends on > u-boot-custom-src, but it isn't a build dependency, missing > u-boot-custom in DEPENDS or PACKAGECONFIG? [build-deps] > WARNING: eudev-3.2.7-r0.3.arago5 do_package_qa: QA Issue: eudev > rdepends on u-boot-custom-src, but it isn't a build dependency, > missing u-boot-custom in DEPENDS or PACKAGECONFIG? [build-deps] > WARNING: libinput-1.11.3-r0 do_package_qa: QA Issue: libinput rdepends > on u-boot-custom-src, but it isn't a build dependency, missing > u-boot-custom in DEPENDS or PACKAGECONFIG? [build-deps] > WARNING: libinput-1.11.3-r0 do_package_qa: QA Issue: libinput-bin > rdepends on u-boot-custom-src, but it isn't a build dependency, > missing u-boot-custom in DEPENDS or PACKAGECONFIG? [build-deps] > I would be interesting to see your u-boot-custom recipe here. Looks like this one is not formed well enough. Did you base it from u-boot recipe of am335x layer? Another thing is if you're building your own version of U-Boot - you would need to set a PREFERRED_PROVIDER to point to it. This > > And once sstate-cache is built and if I try to reuse it after bumping > u-boot-custom to new SRCREV then I get errors like: > > Collected errors: > * Solver encountered 2 problem(s): > * Problem 1/2: > * - nothing provides u-boot-custom-src >= 2019.01+git0+b31ea1d606 > needed by linux-custom-src-4.19.73+git0+d02acfec3d-gamos.wsl > * > * Solution 1: > * - do not ask to install a package providing packagegroup-ggl-base > > * Problem 2/2: > * - nothing provides u-boot-custom-src >= 2019.01+git0+b31ea1d606 > needed by linux-custom-src-4.19.73+git0+d02acfec3d-gamos.wsl > * > * Solution 1: > * - do not ask to install a package providing packagegroup-ggl-qt > Those might come from the point I stated above - your u-boot recipe does not provide necessary packages, or the PREFERRED_PROVIDER might not be set correctly. > Something is definitely not right the way I am have setup my layers > but I would like to understand what is wrong, why it is wrong and what > is the recommended way to do it I can tell you how I personally do it. This is a mere experience that I have and it does not serve as an official How-To - there is a very good documentation about the process of using Yocto on the website. :) I base my new configuration on the oe-core/vendor BSP, utilizing as much as possible from it at the first step. Then once the evaluation image is built (for example core-image-minimal) I examine the distro/machine to identify whether I can use it as-is, or create my distro/machine based on those provided. In later case I try to keep it as close to original source as possible, this would allow ease of upgrade in the future. As a suggested reading here: https://www.yoctoproject.org/docs/latest/brief-yoctoprojectqs/brief-yoctoprojectqs.html > Because in future I would like to add different machines, distros and > images for different custom products. That is why instead of putting > everything inside one layer I thought of keeping a separate layer for > each. This is a correct approach to follow. The only thing you would always have to keep in mind is a concept of "non-destructive layer", meaning that if you remove your layer from the build system - it should not affect all other layers you have included, and you should always have a possibility to build other distro/machine/image triplets. In other words - don't pollute your build system with unnecessary dependencies. > > Looking forward to learning from your responses. > > Thanks > Ankur > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- Regards, Andrey. -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
