There is a project in which we use project yocto, and our metas fetch source from some remote git repositories.
The problem is that these repositories are only accessible in some particular situations/specific times.
Therefore, I need a way to fetch the repos (when they are available), as to have them locally, but not build anything at that time.
Is this possible?
Starting from Yocto 2.5, it has changed:
bitbake <target> --runall=fetch
Previously it was:
bitbake <target> -c fetchall
Bitbake Usage-and-syntax
Try bitbake -c fetchall <target>
It might help to add:
BB_GENERATE_MIRROR_TARBALLS = "1"
to local.conf, which generates tarballs for all fetched sources which aren't already an archive.
Related
I have some self written yocto recipes, which create issues with the yocto sstate-cache mechanism (like not rebuilding the recipe when dependencies have changed). Is there a way to disable sstate-caching on a per recipe basis?
Searching the interwebs I can only find very old and by now broken mechanisms:
https://patchwork.openembedded.org/patch/17039/
Or only partial disable functions:
https://patchwork.openembedded.org/patch/130719/
My Yocto version is Zeus and above.
Thanks and cheers!
In the recipe:
SSTATE_SKIP_CREATION = "1"
or, from outside the recipe (e.g. local.conf):
SSTATE_SKIP_CREATION_pn-recipefoo = "1"
SSTATE_SKIP_CREATION_pn-recipebar = "1"
You can verify if sstate exists for a recipe, using oe-check-sstate, e.g.:
oe-check-sstate yourimage | grep recipefoo
and you can remove sstate for a recipe using:
bitbake -c cleansstate recipefoo
However, it is concerning that your recipe interferes with the sstate mechanism. Ensure that you are correctly setting & updating the version and revision of your packages whenever the source code changes.
If your recipe source is stored alongside your Yocto metadata, consider using externalsrc to reference it, allowing Yocto to better track changes.
I am trying to build core-image-minimal receipe for iMx7 (Yocto project), the image gets successfully built but it has bluetooth, caam and lot of other stuff. How can I remove these from including in the minimal-image?
core-image-minimal should only have things required for just booting nothing else, somehow other packages are getting added. I didnt add anything in my local.config file.
MACHINE = "imx7dsabresd"
bluetooth and wifi are enabled here:
imx7dsabresd.conf
You can add the following to your local.conf to remove bluetooth:
MACHINE_FEATURES_remove = "bluetooth"
CAAM is enabled in the kernel config here:
defconfig
To change the kernel configuration you can either provide a new defconfig or use a configuration fragment. The following steps describe how to create a config fragment.
Run the following command and deselect the bluetooth related config options:
bitbake -c menuconfig virtual/kernel
Run the following command to generate fragment.cfg in ${WORKDIR}
bitbake -c diffconfig virtual/kernel
At this point if you do not have your own layer, create one by following this guide:
Creating Your Own Layer
Create the directory for the .bbappend and the configuration fragment:
mkdir -p ${PATH_TO_YOUR_LAYER}/recipes-kernel/linux/linux-fslc-imx/linux-fslc-imx/
Move fragment.cfg from ${WORKDIR} to ${PATH_TO_YOUR_LAYER}/recipes-kernel/linux/linux-fslc-imx/linux-fslc-imx/
Create a ${PATH_TO_YOUR_LAYER}/recipes-kernel/linux/linux-fslc-imx_%.bbappend (assuming linux-fslc-imx is the correct kernel recipe for this board) and place the following in it:
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
SRC_URI += "file://fragment.cfg"
Additionally, you may find the Creating Configuration Fragments section of the manual helpful.
For more information about bbappends see:
mega-manual
You do not mention which machine you are building for, but I suspect it has bluetooth enabled in the MACHINE_FEATURES. I also didn't look at the bb file for core-image-minimal closely, so could be something else.
bitbake cleanall
Removes all output files, shared state cache, and downloaded source files for a target
It is not clear or documented if it cleans all build time dependencies as well
If you want to clean everything do,
bitbake world -c cleanall --continue
The --continue will ignore any dependency errors while cleaning. Continue as much as possible after an error.
No, cleanall does not clean dependencies. eg
bitbake -c cleanall core-image-minimal
only removes the output of that named recipe.
What i usually do to clean "everything" is running cleanall on the receipe "world":
bitbake -c cleanall world
If that fails because of unresolvable packages like that:
ERROR: Nothing PROVIDES 'sg3-utils' (but /home/blubb/meta-freescale/recipes-devtools/utp-com/utp-com_git.bb DEPENDS on or otherwise requires it).
I just add the packages temporary to the ASSUME_PROVIDED variable like this :
bitbake -c cleanall world --ignore-deps=python-nativedtc-native --ignore-deps=sg3-utils
If nothing provides this packages it is unlikely that they where ever build.
Please read the mega-manual section do_cleanall .
do_cleanall removes:
all output files
shared state (sstate) cache
and downloaded source files for a target (i.e. the contents of DL_DIR).
You can run this task using BitBake as follows:
$ bitbake -c cleanall <recipe-name>
If recipe name is not passed to cleanall task it does not work.
Removes all output files, shared state (sstate) cache, and downloaded source files for a target (i.e. the contents of DL_DIR). Essentially, the do_cleanall task is identical to the do_cleansstate task with the added removal of downloaded source files.
You can run this task using BitBake as follows:
$ bitbake -c cleanall recipe
Typically, you would not normally use the cleanall task. Do so only if you want to start fresh with the do_fetch task.
Other folks have already answered that bitbake does not automatically clean dependencies, but you can create an Inter-task dependency (https://www.yoctoproject.org/docs/3.1/bitbake-user-manual/bitbake-user-manual.html#inter-task-dependencies) to clean your dependencies if needed by adding a command to the recipe:
do_task[depends] = "recipe:task"
We've extended bitbake to build native recipes and automatically run unit tests during a build. In that case we need to clean the native recipe when cleaning the target so you could add:
do_clean[depends] = "${PN}-native:do_clean"
do_cleanall[depends] = "${PN}-native:do_cleanall"
do_cleansstate[depends] = "${PN}-native:do_cleansstate"
That solution falls a bit short because the native recipes will attempt to clean ${PN}-native-native, so you'll need a conditional to not apply if it's already native:
do_clean[depends] += "${#'' if bb.data.inherits_class('native', d) else '${PN}-native:do_clean'}"
do_cleanall[depends] += "${#'' if bb.data.inherits_class('native', d) else '${PN}-native:do_cleanall'}"
do_cleansstate[depends] += "${#'' if bb.data.inherits_class('native', d) else '${PN}-native:do_cleansstate'}"
I'm having trouble cross compiling Qt5 for beaglebone using openembedded with bitbake. I think in step do_configure not everything is passed from my *.bbappend and no platform plugins are installed (I need 'linuxfb').
My question will be: how to make bitbake print list of arguments it passes to ./configure?
There's a few ways to get that info, I would suggest looking in the recipe work directory:
temp/log.do_configure contains the configure task log which should list exact ./configure-command
build/ contains the projects own build system artefacts
bitbake -e <recipe> | grep <VARIABLE> is very useful if you want to know what variable values end up as (check e.g. PACKAGECONFIG and PACKAGECONFIG_CONFARGS values if you're modifying packageconfig).
I want to add gedit to the the image. But i am not able to find the dependencies of gedit package. How to find the dependencies (DEPENDS) in yocto.
You can use the following command which opens up a Dependency explorer that displays dependencies on the packages:
bitbake -g recipe-name -u depexp
or bitbake -g gedit -u depexp, in your case.
On pyro and later use:
bitbake -g recipe-name -u taskexp
Note: this command needs python-gtk2 installed.
You can also use Toaster, which is a web UI that collects information about what you build, including dependencies. This video shows the dependency information provided:
https://www.youtube.com/watch?v=x-6dx4huNnw
Details on how to set up and use Toaster at
https://www.yoctoproject.org/docs/latest/toaster-manual/toaster-manual.html
The list of packages installed in your image is stored in the manifest file (besides of build history which is already mentioned).
Content of the manifest file looks like:
alsa-conf cortexa7hf-neon-vfpv4 1.1.2-r0.1
alsa-conf-base cortexa7hf-neon-vfpv4 1.1.2-r0.1
alsa-lib cortexa7hf-neon-vfpv4 1.1.2-r0.1
alsa-states cortexa7hf-neon-vfpv4 0.2.0-r5.1
alsa-utils-alsactl cortexa7hf-neon-vfpv4 1.1.2-r0.5
alsa-utils-alsamixer cortexa7hf-neon-vfpv4 1.1.2-r0.5
...
The list consists of the package name, architecture and a version.
That manifest is located in the deploy directory (i.e. deploy/images/${MACHINE}/). Here as an example of the directory listing (there are target images and the manifest file)
example-image-genericx86.ext3
example-image-genericx86.manifest
example-image-genericx86.tar.bz2