While building a Yocto image, BitBake fetches the files specified in layer recipes. When running bitbake, the process identifies missing files and tries to find them from mirrors.
Aside from searching the whole project for the missing file, is there a bitbake tool to identify a layer or recipe, given a broken package/file link?
One current example is:
expat-native-2.2.8-r0
tried, invalid: https://downloads.sourceforge.net/expat/expat-2.2.8.tar.bz2
use: https://github.com/libexpat/libexpat/releases/download/R_2_2_8/expat-2.2.8.tar.bz2
This question may be similar, but is out of date.
How do I find which layer is using the expat-native package?
Related
I am trying to build a system (Yocto based project) using bitbake and one of the steps is that it needs to retrieve an archive.zip file with a hex file in it from a Jenkins instance somewhere and install that somewhere within the kernel.
The problem now is that I have get a bitbake error on the do_fetch step of this precise recipe.
File: '/cache/downloads/firmware-17.zip' has sha256 checksum 6b565bbe776e3eabd883af7d1660db6ac2c13f13f16fbb1dbf6b9af42e31e9c9 when 6b565bbe776e3eabd883af7d1660db6ac2c13f13f16fbb1dbf6b9af42e31e9c9 was expected If this change is expected (e.g. you have upgraded to a new version without updating the checksums) then you can use these lines within the recipe: SRC_URI[sha256sum] = "6b565bbe776e3eabd883af7d1660db6ac2c13f13f16fbb1dbf6b9af42e31e9c9"
As you can see the expected checksum is identical between what bitbake reads and expects so I don't really understand what to do at the moment.
What I have already tried is:
Ensure that bitbake does a full clean build.
Bump the repository where archive.zip originates from so that the hash isn't the problem.
What I haven't tried yet is:
Manually download the firmware and place it in the /downloads folder of bitbake and mark the recipe as 'fetched' but since it is running in docker that is not a viable solution really.
Has anybody come across something like this?
I suspect there is a stray space in the value set in your recipe. The message hints at that with "9c9 was" showing a double space.
To edit source in Yocto, I have to execute devtool modify <recipe>. I know the name of the source file, say foo.cpp, not the recipe. Using information captured elsewhere I can find out which recipe corresponds to my source file. To me that's the brute force method. Is there a recommended way to find the recipe using Yocto tools?
I have already viewed dependencies and reverse dependencies with Toaster. That did not help.
I am trying to determine how I can find what recipe a source file from the build/tmp/work directory came from. Basically normally most of the recipes in the source folder are uri. Then get downloaded and installed to various temp folders. I want to create a patch for some of the files, but I can't seem to figure out which files belong to what recipes.
Thank you
Run oe-pkgdata-util find-path /path/on/target/to/file. This will give you the package installing the file. From there, run oe-pkgdata-util lookup-recipe <pkg-name>, this will give you which recipe is creating the package. That should be enough to find out which recipe you need to modify. You then need to check whether the file you want to modify is part of the recipe (Yocto artifact) or part of the software that the recipe builds. For the former, you can override the file, for the latter, you can create a patch (you can use devtool to help you create the patch).
I have a project that is mostly complete for a custom third party SoM which requires custom bootstrap/bootloaders, currently the recipe is in a meta-bsp layer which works alright however they are built in the aarch64-poky-linux build directory. We have multiple SoM models from this manufacturer that each require different bootloader configs and I'd like them to be built in a machine specific non-linux directory if possible like aarch64-<machine>-none or something. Is this possible?
We are using dunfell release.
Recipes are in meta-mfg/recipes-bsp/mfg-/mfg-_version.bb
Fairly standard recipe setup including:
SECTION = "bootloaders"
SRC_URI..
DEPENDS (native packages only)
do_configure()
do_compile()
do_install()
Current build directory: tmp/work/aarch64-poky-linux/mfg-bootloader/1.x.x-rx/
Preferred build directory: tmp/work/aarch64-<machine>-none/mfg-bootloader/1.x.x-rx/
When building for different machines/soms it uses the same directory and uses the previous build which may be incorrect. We do have a workaround where we don't stamp the configure/build/install tasks so they always rebuild however we'd like a cleaner more appropriate implementation.
Is there any way to accomplish this?
I haven't been able to find any information so far.
I have been pointed to the solution from the IRC channel for anyone with the same question:
Add PACKAGE_ARCH = "${MACHINE_ARCH}" to the recipe to build in machine specific folders.
For an application I am running, there is a run time error as it cannot find libwayland-client.so.0 shared object. How do I know which package provides it and where do I add it. I tried as shown below but it gave me a Nothing PROVIDES error.
CORE_IMAGE_EXTRA_INSTALL += "libwayland-client"
You don't typically work with single files when building Yocto images
In reverse order
You install packages to the image
You build packages by using a recipe
You find (or as a last resort write) recipes as part of layers.
Generally when something is missing you take the following steps:
Check the layerindex https://layers.openembedded.org/layerindex/branch/master/recipes/?q=wayland It tells you that there is a recipe called wayland in layer openembedded-core
Add the layer in question. openembedded-core is already contained in Yocto's poky (directly under the name meta, just to confuse the newcomer...), so nothing to add in this example
Create the environment listing of the recipe in question, bitbake -e wayland >wayland.env
Check what packages the recipe in question creates grep ^PACKAGES= wayland.env. In this case it is easy because there is really only one package wayland (-debug, -dev etc. are special purpose that would not contain the library)
Add a package to the image by its package name. How to do that exactly depends on the image type you create. The variable name given in the question works for some images, but not all. Search for IMAGE_INSTALL in the manual https://www.yoctoproject.org/docs/2.6.1/mega-manual/mega-manual.html for other options.
Once you have built the recipe in question you can also check what files are contained in a package (In this case recipe name and package name are identical, but that is not always the case. Some recipes build more than one package suitable for installation, so obviously they need to use different names)
$ oe-pkgdata-util list-pkg-files wayland
wayland:
/usr/lib/libwayland-client.so.0
/usr/lib/libwayland-client.so.0.3.0
/usr/lib/libwayland-cursor.so.0
/usr/lib/libwayland-cursor.so.0.0.0
/usr/lib/libwayland-server.so.0
/usr/lib/libwayland-server.so.0.1.0