This came out of our Intel Edison community discussion when builds were failing with a bogus git error.
It turned out to be a Git repo problem coupled with the secondary, tarball-based, mirrors fail and it was fixed by Yocto team after I talked to them on the IRC even before I could post the workaround to the forum. But I want to use this as an example of the mirror/premirror mechanism you can use in your recipes in such cases or e.g. when you want to establish a mirror internally in your organization’s network.
When something like that happens, you can work that around by finding another source of this same file on the Internet (filename will be in the do_fetch log mentioned in the bitbake error message) and then adding a line similar to the below to the recipe that fails (in this specific case that was a kernel recipe):
MIRRORS += “git://git.yoctoproject.org/linux-yocto-3.10.git http://build.gnome.org/ostree/work/build-yocto/downloads/ \n”
Here I’ve found the same file on one of the Gnome servers by googling, and by means of that variable I’m just adding it as a mirror for the location with URL “git://git.yoctoproject.org/linux-yocto-3.10.git” (which is the main source mentioned in the kernel recipe in question). I could have added it into the PREMIRROR variable instead, then the mirror would’ve been tried even before the main repo.
You can read more about MIRROR/PREMIRROR variable functions in the Yocto manual here
Hi
how do i add prebuild binary package to the final image?
ex: add clamav.rpm to the final image.
could you please help me.
thanks
You typically don’t do things like that with Yocto – you rather use recipes to build your binaries and then deploy them to the image. Otherwise you risk to have binaries incompatible with your target architecture in the image. There’s a ClamAV recipe here you can use for starting: http://git.yoctoproject.org/cgit/cgit.cgi/meta-security/tree/recipes-security/clamav/clamav_0.98.5.bb?h=master