I have a distro layer "meta-clayer" from a 3rd party which i do not want to edit.
Is there any method in yocto to append/overwrite some settings in distro.conf in "meta-clayer" by appending it from my custom created layer similar to bbappend method.
Any inputs will be helpful.
Create your own layer "meta-my-layer", inside
meta-my-layer/conf/layer.conf
set
LAYERDEPENDS_meta-my-layer = "clayer"
BBFILE_PRIORITY_meta-my-layer = "100"
#Could be any number higher than the one in meta-clayer/conf/layer.conf
create your own distro in conf/distro/include/mydistro.conf
copy paste the distro of meta-clayer inside it and do your own modification.
Do not forget to update your DISTRO variable in conf/local.conf.
An other way would be to override "settings" in your local.conf file which is the file with the higher priority but this is really not advised and not the best practice.
Related
I am developing a multiplatform project, so it is a mix of different boards with appropriate meta layers. My meta image layer contains some bbappend recipes that are board specific although I would like to stick to single image layer repository rather than having image layer repository for each board.
So is there any way to completely hide/ignore/disable specific bbappend files?
Example:
I have bblayers for var-som-* boards. For such boards I have recipes-kernel/linux-variscite_%.bbapend, so building for var-som-* boards is fine, but problem happens when I build for example for raspberry. Having variscite layer (as well as all freescale set) adds a lot of things to the image I don't want, so I am removing variscite and freescale layers and it creates No recipes available for: recipes-kernel/linux-variscite_%.bbappend error.
Luckily this question has already been answered:
Yocto Dunfell error 'No recipes available for' with multiple machines in single custom meta layer
So for those, who faced the same problem here is quick summary:
Within your image meta repository create a folder structure that DOES NOT match BBFILES directive.
Move your .bbappend recipes there.
Include recipes on per-meta-layer basis using BBFILES_DYNAMIC directive.
Example:
# thats default and commonly used way to import recipes from your image
BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
# "hide" recipes "deeper" within folder structure
# so they won't be included by ${LAYERDIR}/recipes-*/*/*.bbappend
#
BBFILES_DYNAMIC += "\
meta-atmel:${LAYERDIR}/dynamic-layers/meta-atmel/recipes-*/*/*.bbappend \
meta-atmel:${LAYERDIR}/dynamic-layers/meta-atmel/recipes-*/*/*/*.bbappend \
"
I want the tar.bz image to be included in the wic image, which is an installer wic image
I have:
IMAGE_FSTYPES += "tar.bz2"
do_image_wic[depends] += "${IMAGE_BASENAME}:do_image_tar"
IMAGE_BOOT_FILES += "${IMAGE_BASENAME}-${MACHINE}.tar.bz2;upgrade.bz2"
so the tar.bz is made first, but... it is not deployed at the point the wic images is made, it is in:
build_output/work/device-type-linux/yocto-image-release/1.0-r0/deploy-yocto-image-release-image-complete/yocto-image-release-device-type-20190611214913.rootfs.tar.bz2
It won't appear in the deploy dir until after image yocto-image-release:do_deploy which naturally occurs after the wic is built (which now fails).
Is there a safe way to access that for the wic imager?
I'm guessing work-shared won't be any good https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#structure-build-work-shared
Is the better way to have a new installer.bb which depends on the yocto-image-release.bb:do_deploy so it can find the pieces and then make its own wic?
One solution seems to involve BBCLASSEXTEND so that I can build bitbake yocto-image-release and bitbake yocto-image-installer by amending the recipe (or a parent class) to include:
BBCLASSEXTEND += "installer"
DEPENDS_installer += "${BPN}"
and in installer.bbclass:
CLASSOVERRIDE = "installer"
and then I can override values with _installer suffix, although there will likely be a lot of work neutralising most of the configuration and methods of the native recipe, because (for now) all I want to build is a wic with the systems own kernel.
No doubt later it will have its own kernel configuration and initramfs anyway as the installer specialises.
This seems nice as there are a variety of images (-dev, -debug, etc) all of which may want an installer. But I still wonder if -installer couples the two too tightly
I am using the raspberry pi layer and the IMAGE_CLASSES variable is set this way, I checked doing bitbake core-image-minimal -e | grep "^IMAGE_CLASSES".
I want to modify what is set in ../meta-raspberrypi/conf/machine/include/rpi-default-settings.inc, which defines how the image is partitioned. I want to avoid to edit this file from the raspberrypi layer.
# RaspberryPi BSP default settings
IMAGE_CLASSES += "sdcard_image-rpi"
I would like to use my own .class file. I tried creating a layer with a higher priority, the same filename, same location and different content, but still, bitbake -e returns the same content. And of course, this layer has been added in the bblayer.conf.
I also tried to add in my local.conf:
IMAGES_CLASSES_remove += "sdcard_image-rpi"
Again, no change.
Any idea?
I'm not sure I understand your intention. If you want to override a .class file completely, you can place modified version of it in your custom meta layer, and place your custom layer on top of bblayers.conf (your custom meta should be placed before the one you are overriding class from).
BTW: IMAGES_CLASSES_remove += "sdcard_image-rpi" does not look correct: you should either use _append / _remove override or '+=' operator, not both.
To configure a component I need to add --enable-feature into EXTRA_OECONF_somename
So I tried to do:
EXTRA_OECONF_append_somename = --enable-feature
But it did not help. After investigation it was found that the one of the third-party recipe contains the following line:
EXTRA_OECONF_remove_somename = --enable-feature
I can't modify the third-party recipe.
Is there a way to add --enable-feature into EXTRA_OECONF_somename
Thank you.
I'm afraid not. The _remove operations are always applied last so there is no way to undo them. I would say that the original recipe shouldn't be using it - _remove is intended for distro policy where you want to say "I don't care how this item got in the value, just remove it".
For preference the original recipe should instead it should be using PACKAGECONFIG to control addition (or not) of this feature.
I have a p2 repo with zipped binary data wrapped in features. While creating this repo, I calculate unzipped data size and created artifacts.xml via shell script. But after signing this repo, when I rerun p2 metadata generator (using p2.artifacts.process in ANT script) to fix md5 checksum, it recalculates sizes and as those features are now zipped, it sets wrong artifact.size in artifacts.xml.
Is there any way, I can do any of following:
Using p2.artifacts.process without updating artifacts.size
property?
Any other way to update md5 checksum without changing artifacts.size property?
Any other better way to address this problem?