I have a custom layer in project. This gets shared with colleagues.
My distro (poky) it uses a older version of alsa. This gets downloaded on initial setup of the build area. I would like to 'replace' that version of alsa with a later version and do this within my custom layer, so that they don't have to edit/replace recipes in poky.
What's the best way to do this? If I just download the newer recipe and include it in my layer (matching the file system names) will it automatically use the later version or is there something else I need to do?
The way you proceeded is the right way, you should add new recipes/bbappend files on your own layer(s), you shouldn't modify Yocto's base layers nor third-party layers by default. Nevertheless, since you want to add a newer version of an existing recipe, you should keep in mind that:
You have to check the priority of your own layer and the priority of the layer that contains the original recipe. Yocto will pick the recipe of the higher priority layer, no matter if it is a newer version or not (ignoring PV). For further information, search for BBFILE_PRIORITY in the Yocto Project Reference Manual. (You can also see a list of all configured layers along with their priorities with the command bitbake-layers show-layers)
In the case of both layers having the same priority, Yocto will build the recipe with the highest PV (you can check/set this value inside your recipe or in its filename recipename_pv.bb). Alternatively, if you wish to select another version rather than the one that is being currently built, you can just set the variable PREFERRED_VERSION_recipename = desiredPV in your distro.conf or local.conf file.
Related
in yocto imagebuildscripts there is a config variable named "IMAGE_FEATURES" i want to create a custom Imagefeature.
I searched my yocto installation which runs poky for existing imagefeatures but i wasn't able to find it.
IMAGE_FEATURES is a bit special, as its basically being hardcoded into image.bbclass.
Generally you are way better off creating custom DISTRO_FEATURES, and triggering on them whereever needed. See packagegroup-core-boot as an example of a recipe changing behaviour based on DISTRO_FEATURE in various places.
Usage wise there is little difference, the only thing you can't do is set DISTRO_FEATURES in the image recipe. If that is your actual need, then you probably should pour the new functionality in a custom image class the includes and extends image.bbclassm and call it myimage.bbclass (or similar).
EDIT:
Initially, I referred to the dropbear recipe as an example that triggers behaviour based on systemd being set as DISTRO_FEATURE. This is technically correct (and it was the first recipe that came to my mind), but probably confusing as there is a dropbear spedific IMAGE_FEATURE too.
I am currently working on Yocto, want to integrate xvisor hypervisor into Yocto.
I wrote a recipe for xvisor, but how can I tell to the system like I am doing for
linux and uboot using PREFERRED_PROVIDER_virtual/kernel and PREFERRED_PROVIDER_u-boot
I tried with PREFERRED_PROVIDER_virtual/xvisor, but it is not taking.
How to compile the code, i.e do_compile()
According to Yocto Documentations PREFERRED_PROVIDER's usage is as below.
If multiple recipes provide an item, this variable determines which recipe should be given preference.You should always suffix the variable with the name of the provided item, and you should set it to the PN of the recipe to which you want to give precedence.
You simply cannot use PREFERRED_PROVIDERS_virtual/xvisor unless meta-virtualization layer is added.
If you want to add hypervisor support, you have to use meta-virtualization layer in your yoctobuild.
Reference to start with
I have a custom machine layer based on https://github.com/jumpnow/meta-wandboard.
I've upgraded the kernel to 4.8.6 and want to add X11 to the image.
I'm modifying to image recipe (console-image.bb).
Since wandboard is based on i.MX6, I want to include the xf86-video-imxfb-vivante package from meta-fsl-arm.
However, it fails complaining about inability to build kernel-module-imx-gpu-viv. I believe that happens because xf86-video-imxfb-vivante DEPENDS on imx-gpu-viv which in turn RDEPENDS on kernel-module-imx-gpu-viv.
I realize that those dependencies have been created with meta-fsl-arm BSP and vanilla Poky distribution. But those things are way outdated for wandboard, hence I am using the custom machine layer with modern kernel.
The kernel is configured to include the Vivante DRM module and I really don't want the kernel-module-imx-gpu-viv package to be built.
Is there a way to exclude it from RDEPENDS? Can I somehow swear my health to the build system that I will take care of this specific run-time dependency myself?
I have tried blacklisting 'kernel-module-imx-gpu-viv' setting PNBLACKLIST[kernel-module-imx-gpu-viv] in my local.conf, but that's just a part of a solution. It helps avoid build failures, but the packaging process still fails.
IIUC you problem comes from these lines in img-gpu-viv recipe:
FILES_libgal-mx6 = "${libdir}/libGAL${SOLIBS} ${libdir}/libGAL_egl${SOLIBS}"
FILES_libgal-mx6-dev = "${libdir}/libGAL${SOLIBSDEV} ${includedir}/HAL"
RDEPENDS_libgal-mx6 += "kernel-module-imx-gpu-viv"
INSANE_SKIP_libgal-mx6 += "build-deps"
I would actually qualify this RDEPENDS as a bug, usually kernel module dependencies are specified as RRECOMMENDS because most modules can be compiled into the kernel thus making no separate package at all while still providing the functionality. But that's another issue.
There are several ways to fix this problem, the first general route is to tweak RDEPENDS for the package. It's just a bitbake variable, so you can either assign it some other value or remove some portion of it. In the first case it's going to look somewhat like this:
RDEPENDS_libgal-mx6 = ""
In the second one:
RDEPENDS_libgal-mx6_remove = "kernel-module-imx-gpu-viv"
Obviously, these two options have different implications for your present and future work. In general I would opt for the softer one which is the second, because it has less potential for breakage when you're to update meta-fsl-arm layer, which can change imx-gpu-viv recipe in any kind of way. But when you're overriding some more complex recipe with big lists in variables and you're modifying it heavily (not just removing a thing or two) it might be easier to maintain it with full hard assignment of variables.
Now there is also a question of where to do this variable mangling. The main option is .bbappend in your layer, that's what appends are made for, but you can also do this from your distro configuration (if you're maintaining your own distro it might be easier to have all these tweaks in one place, rather than sprayed into numerous appends) or from your local.conf (which is a nice place to quickly try it out, but probably not something to use in longer term). I usually use .bbappend.
But there is also a completely different approach to this problem, rather than fixing package dependencies you can also fix what some other package provides. If for example you have a kernel configured to have imx-gpu-viv module built right into the main zimage you can do
RPROVIDES_kernel-image += "kernel-module-imx-gpu-viv"
(also in .bbappend, distro configuration or local.conf) and that's it.
In any case your approach to fixing this problem should reflect the difference between your setup and recipe assumptions. If you do have the module, but in a different package, then go for RPROVIDES, if you have some other module providing the same functionality to libgal-mx6 package then fix libgal-mx6 dependencies (and it's better to fix them, meaning not only drop something you don't need, but also add things that are relevant for your setup).
I have a single Bitbake recipe that creates several packages, declared by using the PACKAGES variable and specifying the contents of each package using FILE_package1, FILE_package2, etc.
I would like to specify a different version string for each package, but they all share the version string stored in ${PV}. How can I provide a different version for each package?
Although I could be wrong, I don't think it's possible to do what you want. The ${PV} variable is typically specified in the title of the recipe (e.g. busybox_1.22.1.bb) and Bitbake sets the ${PV} variable based on that.
In order to specify different versions for each package I think you're going to have to split the recipe into multiple recipes, each one with its own version.
I have a third-party Yocto layer which provides a recipe (let's call it recipe.bb) which references a local include file using require recipe.inc).
I have then created a custom layer and I would like to "replace" the included file recipe.inc with a custom version of it, provided by me. Is it possible? I've already tried to put my own recipe.inc in my folder and then using FILESEXTRAPATHS_prepend := "${THISDIR}:" in my recipe_%.bbappend but it does not work and the original recipe.inc is still included...
Is there a way for doing that?
No, it's not possible to override an .inc-file like that.
If you really need to do that, you could just as well copy recipe.bb into your own layer as well. Normally, the .inc file has all the logics, and the .bb-file only has the version specific stuff. Thus, replacing the .inc file would basically be equal to writing a new recipe.
What are you trying to do, that would require changing all the logics?
Are you sure that it's not enough to add a .bbappend file in your own layer, and override a smaller selection of tasks / variables from the .inc-file?