|
Problems building eSDK: Exception: variable BBFILES references itself!
Bryan Evenson
All,
I've used the SDK in the past and want to start using the eSDK for my project. I'm on the dunfell branch. I'm trying to build the eSDK for my image by calling: bitbake <my_image_name> -c populate_sdk_ext The sdk generation fails with the error in the subject. I haven't been able to find any documentation on what this means or how to fix it. I've tried deleting my tmp directory and running cleansstate on my image and I still get the same error. I've also tried generating the eSDK for core-image-minimal and I have the same error. I can generate the SDK successfully, just not the eSDK. I have copied more of the build output below if it helps. Note that I have replaced some text that I'm paranoid about publishing on the internet; the modified text is enclosed with <>. Does anyone have any insight as to why the eSDK build is failing? Thanks, Bryan NOTE: Running intercept scripts: NOTE: Executing buildhistory_list_installed_sdk_host ... DEBUG: Executing python function buildhistory_list_installed_sdk_host DEBUG: Python function buildhistory_list_installed_sdk_host finished NOTE: Executing buildhistory_get_sdk_installed_host ... DEBUG: Executing shell function buildhistory_get_sdk_installed_host DEBUG: Shell function buildhistory_get_sdk_installed_host finished NOTE: Executing copy_buildsystem ... DEBUG: Executing python function copy_buildsystem NOTE: Excluding local workspace layer <my_home_dir>/poky/poky-build/workspace from extensible SDK NOTE: Generating sstate task list... ERROR: Failed to generate filtered task list for extensible SDK: ### Shell environment set up for builds. ### You can now run 'bitbake <target>' Common targets are: core-image-minimal core-image-sato meta-toolchain meta-ide-support You can also run generated qemu images with a command like 'runqemu qemux86' Other commonly useful commands are: - 'devtool' and 'recipetool' handle common recipe tasks - 'bitbake-layers' handles common layer tasks - 'oe-pkgdata-util' handles common target package tasks ERROR: bitbake failed: ERROR: Command execution failed: Traceback (most recent call last): File "<my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/bitbake/lib/bb/data_smart.py", line 401, in expandWithRefs s = __expand_var_regexp__.sub(varparse.var_sub, s) File "<my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/bitbake/lib/bb/data_smart.py", line 96, in var_sub raise Exception("variable %s references itself!" % self.varname) Exception: variable BBFILES references itself! The above exception was the direct cause of the following exception: Traceback (most recent call last): File "<my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/bitbake/lib/bb/command.py", line 107, in runAsyncCommand self.cooker.updateCache() File "<my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/bitbake/lib/bb/cooker.py", line 1558, in updateCache (filelist, masked, searchdirs) = self.collection.collect_bbfiles(self.data, self.data) File "<my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/bitbake/lib/bb/cooker.py", line 1729, in collect_bbfiles files = (config.getVar( "BBFILES") or "").split() File "<my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/bitbake/lib/bb/data_smart.py", line 589, in getVar return self.getVarFlag(var, "_content", expand, noweakdefault, parsing) File "<my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/bitbake/lib/bb/data_smart.py", line 780, in getVarFlag parser = self.expandWithRefs(value, cachename) File "<my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/bitbake/lib/bb/data_smart.py", line 418, in expandWithRefs raise ExpansionError(varname, s, exc).with_traceback(tb) from exc File "<my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/bitbake/lib/bb/data_smart.py", line 401, in expandWithRefs s = __expand_var_regexp__.sub(varparse.var_sub, s) File "<my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/bitbake/lib/bb/data_smart.py", line 96, in var_sub raise Exception("variable %s references itself!" % self.varname) bb.data_smart.ExpansionError: Failure expanding variable BBFILES, expression was ${BBFILES} <my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/<my_custom_layer1>/recipes-*/*/*.bb <my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/<my_custom_layer1>/recipes-*/*/*.bbappend <my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/<my_custom_layer2>/recipes*/*/*.bb <my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/<my_custom_layer2>/recipes*/*/*.bbappend <my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta-bacnet/recipes-*/*/*.bb <my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta-bacnet/recipes-*/*/*.bbappend <my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta-atmel/recipes*/*/*.bb <my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta-atmel/recipes*/*/*.bbappend <my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta/recipes-*/*/*.bb <my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta-poky/recipes-*/*/*.bb <my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta-poky/recipes-*/*/*.bbappend <my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta-yocto-bsp/recipes-*/*/*.bb <my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta-yocto-bsp/recipes-*/*/*.bbappend <my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta-openembedded/meta-oe/recipes-*/*/*.bb <my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta-openembedded/meta-oe/recipes-*/*/*.bbappend <my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta-openembedded/meta-networking/recipes-*/*/*.bb <my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta-openembedded/meta-networking/recipes-*/*/*.bbappend <my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta-openembedded/meta-python/recipes*/*/*.bb <my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta-openembedded/meta-python/recipes*/*/*.bbappend <my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/workspace/recipes/*/*.bb <my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/workspace/appends/*.bbappend <my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta-openembedded/meta-oe/dynamic-layers/meta-python/recipes-*/*/*.bb which triggered exception Exception: variable BBFILES references itself! Summary: There was 1 ERROR message shown, returning a non-zero exit code. Execution of '. layers/poky/oe-init-build-env .; PYTHONDONTWRITEBYTECODE=1 BB_SETSCENE_ENFORCE=1 PSEUDO_DISABLED=1 oe-check-sstate <my_image_name> meta-extsdk-toolchain:do_populate_sysroot -s -o <my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/tasklist.txt -l <my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/tasklist_bb_log.txt' failed with exit code 1: ### Shell environment set up for builds. ### You can now run 'bitbake <target>' Common targets are: core-image-minimal core-image-sato meta-toolchain meta-ide-support You can also run generated qemu images with a command like 'runqemu qemux86' Other commonly useful commands are: - 'devtool' and 'recipetool' handle common recipe tasks - 'bitbake-layers' handles common layer tasks - 'oe-pkgdata-util' handles common target package tasks ERROR: bitbake failed: ERROR: Command execution failed: Traceback (most recent call last): File "<my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/bitbake/lib/bb/data_smart.py", line 401, in expandWithRefs s = __expand_var_regexp__.sub(varparse.var_sub, s) File "<my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/bitbake/lib/bb/data_smart.py", line 96, in var_sub raise Exception("variable %s references itself!" % self.varname) Exception: variable BBFILES references itself! The above exception was the direct cause of the following exception: Traceback (most recent call last): File "<my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/bitbake/lib/bb/command.py", line 107, in runAsyncCommand self.cooker.updateCache() File "<my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/bitbake/lib/bb/cooker.py", line 1558, in updateCache (filelist, masked, searchdirs) = self.collection.collect_bbfiles(self.data, self.data) File "<my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/bitbake/lib/bb/cooker.py", line 1729, in collect_bbfiles files = (config.getVar( "BBFILES") or "").split() File "<my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/bitbake/lib/bb/data_smart.py", line 589, in getVar return self.getVarFlag(var, "_content", expand, noweakdefault, parsing) File "<my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/bitbake/lib/bb/data_smart.py", line 780, in getVarFlag parser = self.expandWithRefs(value, cachename) File "<my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/bitbake/lib/bb/data_smart.py", line 418, in expandWithRefs raise ExpansionError(varname, s, exc).with_traceback(tb) from exc File "<my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/bitbake/lib/bb/data_smart.py", line 401, in expandWithRefs s = __expand_var_regexp__.sub(varparse.var_sub, s) File "<my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/bitbake/lib/bb/data_smart.py", line 96, in var_sub raise Exception("variable %s references itself!" % self.varname) bb.data_smart.ExpansionError: Failure expanding variable BBFILES, expression was ${BBFILES} <my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/<my_custom_layer1>/recipes-*/*/*.bb <my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/<my_custom_layer1>/recipes-*/*/*.bbappend <my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/<my_custom_layer2>/recipes*/*/*.bb <my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/<my_custom_layer2>/recipes*/*/*.bbappend <my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta-bacnet/recipes-*/*/*.bb <my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta-bacnet/recipes-*/*/*.bbappend <my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta-atmel/recipes*/*/*.bb <my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta-atmel/recipes*/*/*.bbappend <my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta/recipes-*/*/*.bb <my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta-poky/recipes-*/*/*.bb <my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta-poky/recipes-*/*/*.bbappend <my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta-yocto-bsp/recipes-*/*/*.bb <my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta-yocto-bsp/recipes-*/*/*.bbappend <my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta-openembedded/meta-oe/recipes-*/*/*.bb <my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta-openembedded/meta-oe/recipes-*/*/*.bbappend <my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta-openembedded/meta-networking/recipes-*/*/*.bb <my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta-openembedded/meta-networking/recipes-*/*/*.bbappend <my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta-openembedded/meta-python/recipes*/*/*.bb <my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta-openembedded/meta-python/recipes*/*/*.bbappend <my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/workspace/recipes/*/*.bb <my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/workspace/appends/*.bbappend <my_home_dir>/poky/poky-build/tmp/work/at91sam9x5ek-poky-linux-gnueabi/<my_image_name>/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta-openembedded/meta-oe/dynamic-layers/meta-python/recipes-*/*/*.bb which triggered exception Exception: variable BBFILES references itself! Summary: There was 1 ERROR message shown, returning a non-zero exit code. DEBUG: Python function copy_buildsystem finished DEBUG: Python function do_populate_sdk_ext finished |
|
|
|
Re: Maintaining ABI Compatibility for LTS branch
Richard Purdie
On Sun, 2022-02-06 at 20:14 -0500, Sinan Kaya wrote:
One of the limitations of Yocto LTS branch is that there is noWhilst there isn't a guarantee, it is something we're doing our best to ensure. Where there are security issues and we can't fix them as being backwards compatible, we reserve the right to break things in preference to the security issues. We wouldn't do that lightly. Yocto reserves the right to move a package version forward if aIt also comes down to resources. If we have a choice between this and not fixing the issue, we'd have to do this. If there are resources to do a more precision backport, we'd take that option but we're often resource limited. This promise is being held true on the kernel by running kernel APIWe do run extensive tests on the autobuilder including things like LTP. We admittedly lack resources for analysing the comparisions in an automated or manual way sadly. I'd love to see API/ABI reporting added to our builds. I was curious about how everyone is approaching this problem.There have been ideas proposed but I've not seen any full solution as yet. Is everyone rolling their own solution? or never moving forward?I think most are just accepting some level of change and we've tried to keep it to a minimal level. I mentioned this in yesterdays call and these were mentioned: https://github.com/lvc/abi-compliance-checker https://abi-laboratory.pro/index.php?view=tracker There are two reasons people are interested: a) for release stability as you mention b) for performance as it could be tied into the hash equivalence mechanism for artefact reuse - if A hasn't changed ABI, B dependning on it needn't rebuild. There was a proof of concept of b) here: https://lists.yoctoproject.org/g/yocto/message/52650 There are lots of levels it could be implemented at but it is something someone would need to pick up and drive forward with a long term view to helping with issues etc. Cheers, Richard |
|
|
|
Re: Maintaining ABI Compatibility for LTS branch
Steve Sakoman
On Tue, Feb 8, 2022 at 1:07 PM Richard Purdie
<richard.purdie@...> wrote: I'd be interested in hearing about any cases where we've broken things! In general I don't take version upgrades (other than bug fix/cve fix only dot releases) Yocto reserves the right to move a package version forward if aThese cases should be extremely rare, and the community/technical steering committee is given an opportunity to review this before it happens. I'm certainly open to suggestions on how we can do better. I'd love to see some tooling to do ABI checking! Steve This promise is being held true on the kernel by running kernel API |
|
|
|
Re: Maintaining ABI Compatibility for LTS branch
Ross Burton <ross@...>
On Tue, 8 Feb 2022 at 23:07, Richard Purdie
<richard.purdie@...> wrote: I was curious about how everyone is approaching this problem.Relatedly, somewhere I have a branch that uses libabigail to extract the library ABIs in an build. The next step was doing the comparison, but I never got that far. I wouldn't be surprised if someone has done the same but actually finished the effort. Ross |
|
|
|
[meta-raspberrypi][PATCH] gstreamer1.0-plugins-good: Update bbappend to 1.20
An?bal Lim?n
From: Aníbal Limón <limon.anibal@...>
Gstreamer upgraded to 1.20 see, https://git.openembedded.org/openembedded-core/commit/?id=75891f361f3e9df9fc3e97c720a2ae57dda75888 Signed-off-by: Aníbal Limón <anibal@...> Signed-off-by: Aníbal Limón <limon.anibal@...> --- ..._1.18.%.bbappend => gstreamer1.0-plugins-good_1.20.%.bbappend} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename recipes-multimedia/gstreamer/{gstreamer1.0-plugins-good_1.18.%.bbappend => gstreamer1.0-plugins-good_1.20.%.bbappend} (100%) diff --git a/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.18.%.bbappend b/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.20.%.bbappend similarity index 100% rename from recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.18.%.bbappend rename to recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.20.%.bbappend -- 2.34.1 |
|
|
|
Error: Transaction check error: while doing do_rootfs task
Sourabh Hegde
Hello All,
While bitbaking an image recipe with systemd configured in "local.conf", I am facing an error while doing do_rootfs task. In the local.conf : DISTRO_FEATURES_append = " systemd" #DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit" VIRTUAL-RUNTIME_init_manager = "systemd" VIRTUAL-RUNTIME_initscripts = "systemd-compat-units" Bitbake error: . . Transaction check succeeded. Running transaction test Error: Transaction check error: file /sbin/telinit conflicts between attempted installs of sysvinit-2.96-r0.cortexa7t2hf_neon_vfpv4 and systemd-1:244.5-r0.cortexa7t2hf_neon_vfpv4 I was not facing this error before without systemd. Can anyone please let me know how to resolve this error and what does this error mean? Your help will be much appreciated. Thanks in advance P.S: If I uncomment DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit" in local.conf I get below error: ERROR: Nothing RPROVIDES 'sysvinit' (but [...]/core-image-swupdate.bb RDEPENDS on or otherwise requires it) sysvinit was skipped: missing required distro feature 'sysvinit' (not in DISTRO_FEATURES) |
|
|
|
Re: AUh: upgrading recipes bbppend files only
#yocto
Alexander Kanavin
AUH does not actually do the update, it runs devtool upgrade/devtool finish to do the update and modification of recipes/appends, so you need to replicate the issue using devtool, and see what needs to be changed in its invocation by AUH. Alex On Wed, 9 Feb 2022 at 13:19, <ksmanjunath681@...> wrote: HI , |
|
|
|
AUh: upgrading recipes bbppend files only
#yocto
ksmanjunath681@...
HI ,
I am currently working upgrading recipes using AUH(Auto Upgrade Helper ) tool where in i am able to upgrade recipes, custom settings such as SRCBRANCH , SRCREV and SRC_URI in a recipe file of interest. I am able to upgrade recipes in their recipe(.bb)files only i.e., after completion of upgrade process it is able to update SRCREV commit hash to latest in the repo. If i set the above mentioned variables in extended recipe files(.bbappend) by removing in main recipe instead, main recipe file still gets modified/added with variables SRCBRANCH and SRCREV(latest hash) after upgrade process is completed, leaving behind same variables with previous data which was set, how to make the tool to update extended recipes only. Thanks & Regards, Manjunath |
|
|
|
VINCI Maxime
Hi, I am quite new to Yocto/BitBake and I have a bit of a headache trying to figure out the best way to make use of a native tool in the following context:
I have one recipe that fetch and build third party libs and binaries, let's call it X. I have another recipe that also fetch and build third party libs and binaries, those depending on X's libs, let's call it Y. Y needs to run post installation scripts to generate some config files. Those scripts are calling some of X's binaries to generate those files, therefore I added a dependency on X-native to be able to run those scripts on the building machine. At the moment, I include those scripts in do_install[postfuncs] of Y-native recipe while adding it as dependency in Y recipe, as I wish those to files to be part of Y package. Assuming what I am doing until there is alright (correct me if not), here comes my issue: The way X is configured/compiled involves specifying the path where it will write any file it generates/manage (currently based on the 'datadir' prefix). This implies that building X-native will also prefix this path with STAGING_DIR_NATIVE in X recipe context. So, after using X-native binaries from within Y-native recipe I end up generating files in the wrong STAGING_DIR_NATIVE (ie. X recipe context), being unable to easily retrieve those as it's outside of Y recipe context. Am I missing something here ? I read about pkg_postinst and deferring them after sysroot creation, but this is not what I need if I wish to package to config files, right ? If there are no other solution, I may resort not to package them and use this to generate them at image/sdk creation, but this does not seems clean to me. Also, I wish not to patch X sources to enable some sort of runtime output path configuration. |
|
|
|
[meta-zephyr][PATCH] zephyr-image: unify the image generation for tests and samples
Bartosz Golaszewski
From: Bartosz Golaszewski <bartosz.golaszewski@...>
Reuse the same code that generates zephyr samples for building tests. This allows us to generate .bin files in all cases. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@...> --- .../recipes-kernel/zephyr-kernel/zephyr-image.inc | 9 +-------- 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-image.inc b/meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-image.inc index c77692d..2d4c6ff 100644 --- a/meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-image.inc +++ b/meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-image.inc @@ -1,17 +1,10 @@ -require zephyr-kernel-src.inc -require zephyr-kernel-common.inc - +require zephyr-sample.inc inherit testimage -inherit deploy QEMU_BIN_PATH = "${STAGING_BINDIR_NATIVE}" ZEPHYR_BASE = "${S}" OECMAKE_SOURCEPATH = "${S}/${ZEPHYR_SRC_DIR}" -do_deploy () { - install -D ${B}/zephyr/${ZEPHYR_MAKE_OUTPUT} ${DEPLOYDIR}/${ZEPHYR_IMAGENAME} -} - addtask deploy after do_compile do_install[noexec] = "1" -- 2.30.1 |
|
|
|
Maintaining ABI Compatibility for LTS branch
Richard Purdie
Forwarding to the correct list address and cc the LTS maintainer.
Cheers, Richard |
|
|
|
Can't Locate Module in @INC - you may need to install the Module issue...
bgctkd@...
Hello All,
I'm getting an error trying create/use a recipe i created for Pearl Module Const::Fast
It has a Build.PL file as follows:
use 5.0.0.8
use Module::Build::Tiny 0.21;
Build_PL();
I have built ModuleBuild::Tiny as well. (meta-cpan has a recipe for Build::Tiny) And (think I) am placing it as a dependency for Const::Fast. however...
My issue (or my first Issue) I guess is how to populate Module Build::Tiny into recipe-sysroot-native. When I attempt to build my recipe I get an error as follows:
Can't locate Module/Build/Tiny.pm in @INC (you may need to install the Module::Build::Tiny module) (@INC contains: < list of paths it is looking for>)
Paths @INC (in build/tmp/work) is using to fine Module/Build/Tiny.pm are along these lines:
/all-poky-linux/const-fast-perl/0.014-r0/recipe-sysroot-native/<paths below>
/usr/lib/perl5/site_perl/5.34.0/x86_64-linux
/usr/lib/perl5/site_perl/5.34.0
/usr/lib/perl5/vendor_perl/5.34.0
/usr/lib/perl5/5.34.0/x86_64-linux
/usr/lib/perl5/5.34.0
/x86_64-linux/perl-native/5.34.0-r0/recipe-sysroot-native/usr/lib/perl5/<paths below>
/site_perl/5.34.0/x86_64-linux
/site_perl/5.34.0
/vendor_perl/5.34.0/x86_64-linux
/vendor_perl/5.34.0
/5.34.0/x86_64-linux
/5.34.0) at Build.PL line 2.
#| BEGIN failed--compilation aborted at Build.PL line 2.
Paths the module is found are along these lines (found via manual search):
#./all-poky-linux/module-build-tiny-perl/0.021-r0/sysroot-destdir/usr/lib/perl5/vendor_perl/5.34.0/Module/Build/Tiny.pm
./all-poky-linux/module-build-tiny-perl/0.021-r0/package/usr/lib/perl5/vendor_perl/5.34.0/Module/Build/Tiny.pm
My const-fast Recipe is as follows const-fast-perl_014.bb:
DESCRIPTION = "This module provides Const::Fast Functionality"
SECTION = "libs"
LICENSE = "Artisticv1 | GPLv1+"
PR = "r0"
MAINTAINER= "Poky <poky@...>"
HOMEPAGE= "https://metacpan.org/release/Const-Fast"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/Artistic-1.0;md5=cda03bbdc3c1951996392b872397b798 \
file://${COMMON_LICENSE_DIR}/GPL-1.0-or-later;md5=30c0b8a5048cc2f4be5ff15ef0d8cf61"
SRC_URI = "https://cpan.metacpan.org/authors/id/L/LE/LEONT/Const-Fast-0.014.tar.gz"
SRC_URI[sha256sum] = "f805953a08c57846a16a4d85d7b766398afaf7c36c1465fcb1dea09e5fa394db"
S = "${WORKDIR}/Const-Fast-${PV}"
inherit cpan_build allarch
RDEPENDS_${PN} += "extutils-config-perl"
RDEPENDS_${PN} += "extutils-helpers-perl"
RDEPENDS_${PN} += "extutils-installpaths-perl"
DEPENDS += "extutils-config-perl-native"
DEPENDS += "extutils-helpers-perl-native"
DEPENDS += "extutils-installpaths-perl-native"
DEPENDS += "libmodule-build-perl module-build-tiny-perl"
BBCLASSEXTEND = "native"
My module-build-tiny-perl_0.021.bb is as follows:
DESCRIPTION = "Many Perl distributions use a Build.PL file instead of a Makefile.PL file \
to drive distribution configuration, build, test and installation. \
Traditionally, Build.PL uses Module::Build as the underlying build system. \
This module provides a simple, lightweight, drop-in replacement."
SECTION = "libs"
LICENSE = "Artisticv1 | GPLv1+"
PR = "r0"
MAINTAINER= "Poky <poky@...>"
HOMEPAGE= "https://metacpan.org/release/Module-Build-Tiny"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/Artistic-1.0;md5=cda03bbdc3c1951996392b872397b798 \
file://${COMMON_LICENSE_DIR}/GPL-1.0-or-later;md5=30c0b8a5048cc2f4be5ff15ef0d8cf61"
SRC_URI = "https://cpan.metacpan.org/authors/id/L/LE/LEONT/Module-Build-Tiny-0.021.tar.gz"
SRC_URI[sha256sum] = "65e516c2e99d63100fdf4dbfa35489d0562718a0e8d2b885e9daaa7bc174b43e"
RDEPENDS_${PN} += "extutils-config-perl"
RDEPENDS_${PN} += "extutils-helpers-perl"
RDEPENDS_${PN} += "extutils-installpaths-perl"
DEPENDS += "extutils-config-perl-native"
DEPENDS += "extutils-helpers-perl-native"
DEPENDS += "extutils-installpaths-perl-native"
S = "${WORKDIR}/Module-Build-Tiny-${PV}"
inherit cpan_build allarch
BBCLASSEXTEND = "native" Regards, Bruce |
|
|
|
Re: Zeek recipe
Gary Huband
I could never get a Zeek recipe to work. I resorted to building it on the target, saving the binaries in a repo, then creating a recipe to install the binaries.
Gary
From: yocto@... <yocto@...> on behalf of Paul van Berlo via lists.yoctoproject.org <pvanberlo=gmail.com@...>
Sent: Tuesday, February 8, 2022 11:08 AM To: yocto@... <yocto@...> Subject: [yocto] Zeek recipe Hi,
does anyone happen to have a working Zeek recipe? Whatever I do, I cannot get it to compile properly :(
Regards,
Paul van Berlo
Gary Huband
Sr. Software and Systems Engineer
Office: 434.284.8071 x720 Direct: 434.260.4995 Gary@...
: : : : : : : : : : : : : : : : : : : : : : : : : : :
 This email and any files transmitted with it are confidential and proprietary and intended solely for the use of the individual or entity to whom they are addressed.
Any dissemination, distribution or copying of this communication is strictly prohibited without our prior permission. If you received this in error, please contact the sender and delete the material from any computer.
|
|
|
|
Re: run.do_compile error on poky-dunfell release
Sourabh Hegde
Hello Chuck,
Thanks for the hint. @Khem, when I checked the "sources/poky/meta/recipes-core/kbd", above patch is already available and included in "kbd_2.2.0.bb" recipe. And same patch is also present in "build/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/kbd/2.2.0-r0" But still I am getting above error. I have no idea what this error means and why am I getting this all of a sudden. |
|
|
|
Re: run.do_compile error on poky-dunfell release
Just replace the word "commit" in the URL with the word patch, like so: ..Ch:W.. On Tue, Feb 8, 2022 at 9:46 AM Sourabh Hegde <hrsourabh011@...> wrote: Hello Khem, -- "Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire |
|
|
|
Re: run.do_compile error on poky-dunfell release
Sourabh Hegde
Hello Khem,
Thanks for quick response. Can you please let me know where to include this patch file? Thanks in advance. |
|
|
|
Re: run.do_compile error on poky-dunfell release
you perhaps need this kbd patch
toggle quoted message
Show quoted text
https://git.kernel.org/pub/scm/linux/kernel/git/legion/kbd.git/commit/?id=50eae66fc21ef8e01c69a9d3c1ff3fcb0b2644a0 On Tue, Feb 8, 2022 at 7:43 AM Sourabh Hegde <hrsourabh011@...> wrote:
|
|
|
|
Re: Zeek recipe
Ross Burton <ross@...>
On Tue, 8 Feb 2022 at 16:09, Paul van Berlo <pvanberlo@...> wrote:
does anyone happen to have a working Zeek recipe? Whatever I do, I cannot get it to compile properly :(https://layers.openembedded.org/layerindex/branch/master/recipes/?q=zeek says most likely not. Sharing your recipe and the errors would let others help you. Ross |
|
|
|
Zeek recipe
Paul van Berlo <pvanberlo@...>
Hi, does anyone happen to have a working Zeek recipe? Whatever I do, I cannot get it to compile properly :( Regards, Paul van Berlo |
|
|
|
Yocto Project Status WW06`22
Stephen Jolley
Current Dev Position: YP 3.5 M3 Next Deadline: 21th Feb. 2022 YP 3.5 M3 build
Next Team Meetings:
Key Status/Updates:
Everyone can now sign up for an account on the new system. Patchwork project maintainers please email mhalstead@... to have your access restored.
In particular, we’re struggling to understand the intermittent network issue with external hosts we’re seeing very occasionally.
Ways to contribute:
YP 3.5 Milestone Dates:
Upcoming dot releases:
Tracking Metrics:
The Yocto Project’s technical governance is through its Technical Steering Committee, more information is available at: https://wiki.yoctoproject.org/wiki/TSC
The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status
[If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!]
Thanks,
Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
|
|