Even with no changes in my recipes, I see that on an incremental rebuild, do_configure is getting re-triggered.
Appreciate any pointers on what can cause this.
Try this:
bitbake-diffsigs -t your_recipe configure
Related
I was exporting my component to Bit.dev, when I got stuck at the bit tag --message command, with the error message: Failed task 1: "teambit.pkg/pkg:PackComponents" of env "teambit.harmony/node"
I have already ran the previous commands: bit link --rewire, bit compile and bit build --all prior. I would also like to mention that I have circular dependencies errors which I workaround with the --ignore-issues \"CircularDependencies\" flag.
Have anyone faced this issue before, and managed to solve it? Thanks in advance.
I'm developing on Yocto 2.4 rockowith a BSP given by my provider. I'm trying to build modemmanager from the meta-openembedded layer, included in the meta-oe sub layer.
The configure task fail and give me as error :
checking for gobject-introspection...
configure: error: gobject-introspection-1.0 is not installed
After some search I've installed the libgirepository1.0-dev package on my host machine. But the error is always present.
I've continued investigations, and find in my recipe log the line :
DEBUG: EXCLUDE FROM WORLD: virtual:native:/home/test/share/sc20_linux/poky/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.52.1.bb
I've tried to find which recipe excludes the dependency, with no success.
Can you help me to understand how works the EXCLUDE_FROM_WORLD mechanism ?
Thanks for your help.
I suspect that is debug output and doesn't mean the recipe is excluded. Have you looked at the modemmanager recipe to see if it has a DEPENDS on gobject-introspection-native and perhaps gobject-introspection? If not, or the PACKAGECONFIG isn't set, try adding the DEPENDS or enabling the PACKGECONFIG?
Also, have you tried simply building "bitbake object-introspection-native" and "bitbake object-introspection". You should get an error about why they ar disabled if you try and build them directly and they are excluded/disabled for some reason.
I am trying to build an console image for an RPi using the core-image-base recipe, but somewhere in my configuration, I seem to have switched something on that is increasing the number of recipes built by around 1000 which include many things that don't feel like they belong in a console image (libx11, gnome-desktop-testing, etc.)
I am trying to track down why these recipes are being included in my build. My method so far has been to run the following commands:
# Generate a massive dot file with all the dependencies in it
bitbake -g core-image-base
# grep through that file to find out what is bringing in
# gnome-desktop-testing.
cat task-depends.dot | grep -i gnome-desktop-testing | grep -vi do_package_write_rpm
I removed do_package_write_rpm from the matching since everything seems to match against it. This leaves the following:
"core-image-base.do_build" -> "gnome-desktop-testing.do_build"
"core-image-base.do_rootfs" -> "gnome-desktop-testing.do_package_qa"
"core-image-base.do_rootfs" -> "gnome-desktop-testing.do_packagedata"
"core-image-base.do_rootfs" -> "gnome-desktop-testing.do_populate_lic"
"glib-2.0.do_package_qa" -> "gnome-desktop-testing.do_packagedata"
(followed by many dependencies between the tasks of the gnome-desktop-testing recipe)
So, if my interpretation is correct, it seems that core-image-base is depending directly on gnome-desktop-testing. This seems unusual since core-image-base is supposed to be a console only image.
I tried adding PACKAGE_EXCLUDE = "gnome-desktop-testing" to my local.conf hoping that it would give back some more information, but the build just seems to proceed regardless of this variable's setting :/
How can I figure out why gnome-desktop-testing is being built by Yocto? Ideally I would like to have a solution not involving toaster.
I ran into this issue and so I thought I would post the answer.
First, I removed the recipe, rebuilt and then looked at the first dependency chain.
NOTE: Runtime target 'shared-mime-info' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['shared-mime-info', 'glib-2.0', 'gnome-desktop-testing']
Then we look in the recipe to see that glib-ptest has an RDEPENDS on gnome-desktop-testing.
RDEPENDS_${PN}-ptest += "\
coreutils \
libgcc \
dbus \
gnome-desktop-testing \
tzdata \
So then to fix that you will need to disable "ptest". This can be done from the your distro configuration (meta-layer/conf/distro/*.conf).
One brutal solution to this problem is to just delete the recipe that you don't want and to rerun bitbake. This gives you a useful message such as:
ERROR: Required build target 'core-image-base' has no buildable providers.
Missing or unbuildable dependency chain was:
['core-image-base', 'packagegroup-base-extended', 'ofono', 'glib-2.0', 'gnome-desktop-testing']
If you have brought in these layers using git, the changes can be quickly reverted with git checkout path/to/deleted/recipe
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 was under the impression that I could do:
app.import('bower_components/core.js/library/fn/object/entries.js');
But it's not resolving the imported portions of it. If I start linking it up myself I end up with:
app.import('bower_components/core.js/modules/_global.js');
app.import('bower_components/core.js/modules/_export.js');
app.import('bower_components/core.js/library/fn/object/entries.js');
And
Module is not defined.
What's the proper way of doing this?
Right okay it seems like I need to install core.js then build it:
npm run grunt build:es7.object.entries
Then include the product of that.