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.
Related
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?
I am working on a yocto project and in my custom layer, I have dozens of recipes. A couple recipes are still under development and were not listed in the my image's recipe. However one broken recipe is still being pulled into the build. I have deleted by build/tmp directory as well as my state cache and rebuilt. But the bad recipe is still being pulled in. How do I figure out what is pulling in this bad recipe? bitbake -e doesn't show my recipe at all.
I was able to figure it out by shear luck, so I'm really asking for debug skills on doing this in the future. In my case, the bad recipe had a dozen or so PROVIDES, and another recipe was DEPENDing on one of those. Is there a way to get bitbake to indicate why a recipe is being baked? something like "Compling lib_bad.bb because lib_good.bb depends on it"
You can generate dependacy graph:
bitbake -g <packagename>
vim task-depends.dot
or graphical version (graphviz):
bitbake -g <packagename> -u taskexp
So to answer my own question, there are a few things to offer: https://docs.yoctoproject.org/what-i-wish-id-known.html My question is basically the crux of item #8 on that list. So here is what I could have done to expedite solving the mystery.
When you run bitbake -g core-image-minimal you get two files in the build directory: task-depends.dot and pn-buildlist.
Then look in the task-depends.dot file and search for the package. grep <package> task-depends.dot The first search results are going to show several entries for the culprit package that is pulling in the bad package.
~/poky/build$ grep lib_bad task-depends.dot
"lib_good.do_build" -> "lib_bad.do_package_write_deb"
"lib_good.do_package" -> "lib_bad.do_packagedata"
"lib_good.do_prepare_recipe_sysroot" -> "lib_bad.do_populate_sysroot"
"lib_bad.do_build" -> "autoconf.do_package_write_deb"
etc...
So after search the dependency graph, we can see that lib_good is somehow pulling lib_bad into the build. The next step will be to look in that recipe for its DEPENDS or RDEPENDS variables, and compare them with what lib_bad has in its PROVIDES variable.
I am having an issue where a recipe i'm using no longer has the variable libdir defined. It appears to only have libdir_native.
This recipe i'm using is poco-1.7.5 for Morty from openembedded so I assume the recipe should work properly.
As a result of the missing libdir variable none of the installed files are being packaged which is screwing up my build.
In the short term i've been able to fix the problem by creating an append file which makes libdir = "${libdir_native} but this doesn't seem like it should be necessary.
The only thing I can think of is that the Bitbake.conf file is not being source properly by Bitbake (or the wrong .conf is being used).
Any suggestions would be appreciated.
Based on the comments this seems to be the problem: Poco upstream installs libraries into /usr/lib/ but the yocto packaging expects them to be in ${libdir} which may be different from /usr/lib/.
The most common reason (for cmake recipes) for this is that the upstream project does not support CMAKE_INSTALL_LIBDIR. Check if the upstream build system has some alternative means for specifying libdir -- this is surprisingly common with cmake projects. If not, you could add support for CMAKE_INSTALL_LIBDIR in the upstream build system (and add a patch to your recipe).
An alternative hack would be to add a do_install_append() that checks if ${libdir} is not /usr/lib/, and moves everything from ${D}/usr/lib/ to ${D}${libdir} in that case.
I'm currently trying to build poky-tiny for imx6ulevk (using the BSP Yocto Project Environment provided by NXP).
I first followed the Quick Start Guide, tested and everything worked just fine. I then went to the usual local.conf file (/build/conf/local.conf) and changed the DISTRO variable to poky-tiny.
In poky-tiny distro file (/sources/poky/meta-yocto/conf/distro/poky-tiny.conf), I changed the virtual/kernel in the variable PREFERRED_PROVIDER_virtual/kernel to linux-imx and the PREFERRED_VERSION_linux-imx to 3.14.38 which is compatible (I think).
I finally added to the local.conf the variable IMAGE_FSTYPES with the value tar.bz2 ext3 sdcard.
At this point I tried to build using:
bitbake core-image-minimal
this runs without any problems. But it doesn't generate sdcard image or any u-boot images as is expected. The only files generated are:
core-image-minimal-imx6ulevk-20160517152114.rootfs.cpio.gz
core-image-minimal-imx6ulevk-20160517152114.rootfs.manifest
core-image-minimal-imx6ulevk.cpio.gz
core-image-minimal-imx6ulevk.manifest
modules-imx6ulevk.tgz
zImage
zImage--3.14.38-r0-imx6ul-14x14-evk-20160517152114.dtb
zImage--3.14.38-r0-imx6ul-14x14-evk-csi-20160517152114.dtb
zImage--3.14.38-r0-imx6ulevk-20160517152114.bin
zImage-imx6ul-14x14-evk-csi.dtb
zImage-imx6ul-14x14-evk.dtb
zImage-imx6ulevk.bin
And I got stuck without knowing how to deploy to the imx6ulevk. What did I do wrong? Why is yocto not generating the usual sdcard image?
If anyone gets this what worked for me was the following:
Turns out poky-tiny for imx6ulevk does not create sdcard images normally. So what you need to do, once you build it with a proper kernel, is to manually create a bootable sdcard. This can be done by using gparted cleaning everything in it and adding 2 partitions, then proceed as follow:
1 - First you use gunzip in the file core-image-minimal-imx6ulevk-...-rootfs.cpio.gz.
2 - Call cpio on the generated file: cpio -i -vd < core-image-minimal...-.cpio
3 - You just generated the root file system copy everything into one of the partitions.
4 - the zImage...* files are the generated kernel for the poky-tiny distro. Copy all but the symbolic links to the second partition. You might need to rename the files (I had to) if you're not sure what to rename to, first build regular poky using sdcard image and check out the proper names.
That's pretty much it, you should be able to boot imx6ulevk using the provided files.
I'm trying to figure out how to convince Yocto to build gcc using my local GIT source rather than standard location it uses.
By default the recipe to build GCC located in meta/recipes-devtools/gcc/gcc_5.2.bb. It includes gcc-5.2.inc, which points to
BASEURI = "${GNU_MIRROR}/gcc/gcc-${PV}/gcc-${PV}.tar.bz2"
as the location of the code.
Based on BitBake's documentation, I've created my own layer and gcc_5.2.bbappend append file. bitbake-layers show-appends shows that the system properly recognized the append file.
However, what this gcc_5.2.bbappend append file need to do to replace the source path? I've tried changing SRC_URI directly, prepending it with my own path. But it always stays the same and attempts to access the specified above path.
My original assumption that the /gcc/gcc_5.2.bb have to appended was incorrect. I've corrupted the specified above BASEURI to consistently cause an error. Running bitbake with -D option showed that there is a different recipe called gcc-source_5.2.bb that actually controls the source file acquisition and it had to be appended.