Date   

[meta-zephyr][PATCH] qemuzephyrrunner.py: use os._exit instead of sys.exit

Jon Mason
 

sys.exit(0) can cause an error to be reported when the child exits, even
though not an error. Since this is a child process, os._exit(0) is the
proper way to exit and not cause this issue.

Signed-off-by: Jon Mason <jon.mason@...>
---
lib/oeqa/utils/qemuzephyrrunner.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/oeqa/utils/qemuzephyrrunner.py b/lib/oeqa/utils/qemuzephyrrunner.py
index a1ed30be1ca8..7b486ce8af3f 100644
--- a/lib/oeqa/utils/qemuzephyrrunner.py
+++ b/lib/oeqa/utils/qemuzephyrrunner.py
@@ -191,7 +191,7 @@ class QemuZephyrRunner(QemuRunner):
r = os.fdopen(r)
x = r.read()
os.killpg(os.getpgid(self.runqemu.pid), signal.SIGTERM)
- sys.exit(0)
+ os._exit(0)

bb.note("qemu started, pid is %s" % self.runqemu.pid)
return self.create_socket()
--
2.20.1


Re: [meta-rockchip][PATCH] use uuid instead of hard-coding root device

Trevor Woerner
 

On Sat 2021-09-25 @ 09:56:21 AM, Markus Volk wrote:

Am 23.09.21 um 22:55 schrieb Trevor Woerner:
We can add the --use-uuid line to the /boot entry if you really think it
should be mounted on boot, but we shouldn't use it on the others and cause wic
to generate a bad fstab. There are examples of other boards that don't mount
/boot by default (raspi for sure, and I think bbb too).
Could the solution be as simple as this?
Probably.

You'll need to re-send this with a better subject line and commit
message so the right people will notice it. Otherwise they'll think it's
meta-rockchip-specific.


From b8ba56d84fbac53901e5b7ca122498320e51fbf4 Mon Sep 17 00:00:00 2001
From: MarkusVolk <f_l_k@...>
Date: Sat, 25 Sep 2021 09:21:15 +0200
Subject: [PATCH] wic:direct.py: improve filter for fstab update

Signed-off-by: MarkusVolk <f_l_k@...>
---
scripts/lib/wic/plugins/imager/direct.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/lib/wic/plugins/imager/direct.py b/scripts/lib/wic/plugins/imager/direct.py
index 9d10ec01d0..15fa47356f 100644
--- a/scripts/lib/wic/plugins/imager/direct.py
+++ b/scripts/lib/wic/plugins/imager/direct.py
@@ -117,7 +117,7 @@ class DirectPlugin(ImagerPlugin):
updated = False
for part in self.parts:
if not part.realnum or not part.mountpoint \
- or part.mountpoint == "/":
+ or part.mountpoint == "/" or not part.mountpoint.startswith('/'):
continue
if part.use_uuid:
--
2.25.1

With this patch wic only adds the /boot mountpoint. The invalid entries get filtered out.
We would then only need to set --use-uuid for /boot to avoid the system from crashing if
'no-fstab-update' isn't expicitly given as an argument
If (when) this patch gets applied upstream, then we can remove our
work-around.

This is a fantastic find, I'm guessing other BSP layers might find it useful.
I was thinking of investigating adding a per-line "--no-fstab" option to wic
to indicate specific lines not desired in the fstab, but this looks much
nicer.


Re: [meta-rockchip][PATCH v2 2/2] rockchip-wic.inc: dont let wic edit fstab by default

Trevor Woerner
 

On Thu 2021-09-23 @ 11:17:59 PM, Markus Volk wrote:
Signed-off-by: MarkusVolk <f_l_k@...>
---
conf/machine/include/rockchip-wic.inc | 3 +++
1 file changed, 3 insertions(+)

diff --git a/conf/machine/include/rockchip-wic.inc b/conf/machine/include/rockchip-wic.inc
index 15010a0..30b0d57 100644
--- a/conf/machine/include/rockchip-wic.inc
+++ b/conf/machine/include/rockchip-wic.inc
@@ -26,3 +26,6 @@ WICVARS:append = " \
SPL_BINARY \
UBOOT_SUFFIX \
"
+
+# Do not update fstab file while creating wic images
+WIC_CREATE_EXTRA_ARGS ?= "--no-fstab-update"
Applied to meta-rockchip master (with an updated commit message), thanks!


Re: [meta-rockchip][PATCH] use uuid instead of hard-coding root device

Markus Volk
 


Am 23.09.21 um 22:55 schrieb Trevor Woerner:
We can add the --use-uuid line to the /boot entry if you really think it
should be mounted on boot, but we shouldn't use it on the others and cause wic
to generate a bad fstab. There are examples of other boards that don't mount
/boot by default (raspi for sure, and I think bbb too).
Could the solution be as simple as this?

From b8ba56d84fbac53901e5b7ca122498320e51fbf4 Mon Sep 17 00:00:00 2001
From: MarkusVolk <f_l_k@...>
Date: Sat, 25 Sep 2021 09:21:15 +0200
Subject: [PATCH] wic:direct.py: improve filter for fstab update

Signed-off-by: MarkusVolk <f_l_k@...>
---
 scripts/lib/wic/plugins/imager/direct.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/lib/wic/plugins/imager/direct.py b/scripts/lib/wic/plugins/imager/direct.py
index 9d10ec01d0..15fa47356f 100644
--- a/scripts/lib/wic/plugins/imager/direct.py
+++ b/scripts/lib/wic/plugins/imager/direct.py
@@ -117,7 +117,7 @@ class DirectPlugin(ImagerPlugin):
         updated = False
         for part in self.parts:
             if not part.realnum or not part.mountpoint \
-               or part.mountpoint == "/":
+               or part.mountpoint == "/" or not part.mountpoint.startswith('/'):
                 continue
 
             if part.use_uuid:
-- 
2.25.1

With this patch wic only adds the /boot mountpoint. The invalid entries get filtered out.
We would then only need to set --use-uuid for /boot to avoid the system from crashing if
'no-fstab-update' isn't expicitly given as an argument


Re: [meta-rockchip][PATCH v2 2/2] rockchip-wic.inc: dont let wic edit fstab by default

Markus Volk
 


Am 24.09.21 um 15:10 schrieb Trevor Woerner:
Thanks for the patch and the SoB line. I'm going to apply this patch, but I'm
going to amend the commit message to capture some of the conversation we've
had. There's a chance we'll want to know "why" at some point in the future ;-)
Thanks for applying :)

It would be cool if wic had something like an 'exclude-from-fstab-update" option.
That would make the 'fstab-update' much more useful.


Re: Cross-compiling or compiling on target VM?

Khem Raj
 

On 9/24/21 2:06 AM, arnaud.bienner@... wrote:
Hi,
We are starting a new project using Yocto to build a custom Linux image which matches our needs.
We are new to Yocto and still trying to figure out the best way to work with it.
Especially, if it is best to cross-compile or to build on a VM running an image of the target.
Some background:
Our target system is x86_64, and we are all working on x86_64 computers obviously.
For now, we don't have yet a physical target system so we are running the image generated by Yocto in VirtualBox or VMWare.
For practical reasons, since not all developers use the same OS (Windows, macOS) we decided to do all development work on Linux VM (Debian distribution) so everyone has the same system.
For now, we are cross-compiling applications using Yocto SDK in that Debian VM, copying it to the Yocto VM to run it.
Even though copying/deploying and running them could be somehow automated, since we are developing on a Linux VM anyway, I thought it could be best to build a Yocto image (maybe as an additional "dev" image based on the existing one) which contains all tools we need (gcc, cmake, etc.).
This way, we could execute the binaries (in particular the unit tests) locally.
For some of our unit tests in particular that we run at build time, it sounds easier to run them locally, compared to deploying them and running them remotely.
Any thoughts about this?
there are different possibilities you have with all great tooling you get with yocto project, I think you have made a good choice.

inherently Yocto project is a cross compiling infrastructure so lot of commonly used workflows will be around cross-compiling, however you can also leverage it in ways you described, where you build a development VM using yocto project itself which includes all the tools your developers would need and use that as build env + devtest env, see core-image-sato-sdk. However, this will be more of less a static env, which means devs wont be able to install packages like they might be doing with debian VM, you will have to either rebuild the VM or publish own feeds, but if you expect this to be static env then this might turn out to be ok. Advantage is that you will use same tools that your final target will use and you have ease of native development and folks not familiar with yocto can be effective as well. However this is not a common workflow that yocto project users might be using, so community support might be scarce.

Other option could be that you do cross builds on your debian VM and use qemux86-64 as target and run your tests using ptest framework so you will be running your target VM in qemu on top of your build running debian which is running on windows/MacOS or Linux baremetal. There might be some quirks to use qemu in VM but I think it should work out well. This also means that in future when you target real hardware ( I assume thats what you want eventually ) then not much changes, you add another MACHINE and workflow remains pretty much same. But this would require your devs to learn a bit of yocto-fu and cross-complation workflows.

In advance, thanks a lot for your help.
Best regards,
Arnaud


[PATCH] yocto-bsp/5.13: drop recipes

Bruce Ashfield
 

From: Bruce Ashfield <bruce.ashfield@...>

5.13 has been removed from core, and we've moved the default
support to 5.14, so we can drop our bbappend.

Signed-off-by: Bruce Ashfield <bruce.ashfield@...>
---
.../linux/linux-yocto_5.13.bbappend | 23 -------------------
1 file changed, 23 deletions(-)
delete mode 100644 meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.13.bbappend

diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.13.bbappend b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.13.bbappend
deleted file mode 100644
index daf5fd2cd6..0000000000
--- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.13.bbappend
+++ /dev/null
@@ -1,23 +0,0 @@
-KBRANCH:genericx86 = "v5.13/standard/base"
-KBRANCH:genericx86-64 = "v5.13/standard/base"
-KBRANCH:edgerouter = "v5.13/standard/edgerouter"
-KBRANCH:beaglebone-yocto = "v5.13/standard/beaglebone"
-
-KMACHINE:genericx86 ?= "common-pc"
-KMACHINE:genericx86-64 ?= "common-pc-64"
-KMACHINE:beaglebone-yocto ?= "beaglebone"
-
-SRCREV_machine:genericx86 ?= "7280c93f5599946db3add473eeb05b34c364938d"
-SRCREV_machine:genericx86-64 ?= "7280c93f5599946db3add473eeb05b34c364938d"
-SRCREV_machine:edgerouter ?= "a832a0390e96c4f014d7b2bf9f161ac9477140f7"
-SRCREV_machine:beaglebone-yocto ?= "dbdc921374c057a75b2df92302124994e241ca51"
-
-COMPATIBLE_MACHINE:genericx86 = "genericx86"
-COMPATIBLE_MACHINE:genericx86-64 = "genericx86-64"
-COMPATIBLE_MACHINE:edgerouter = "edgerouter"
-COMPATIBLE_MACHINE:beaglebone-yocto = "beaglebone-yocto"
-
-LINUX_VERSION:genericx86 = "5.13.15"
-LINUX_VERSION:genericx86-64 = "5.13.15"
-LINUX_VERSION:edgerouter = "5.13.15"
-LINUX_VERSION:beaglebone-yocto = "5.13.15"
--
2.19.1


Re: #yocto -third party licensimg #yocto

Robert Berger
 

Hi Steven,

Please see my comments inline

On 24/09/2021 14:10, Monsees, Steven C (US) via lists.yoctoproject.org wrote:
The one solution I found says : Add *LICENSE_PATH += "${LAYERDIR}/custom-licenses"* under conf/layer.conf, *this does not resolve this warning*.
This is a new item being added to our Yocto build.
The Data Direct vendor does not submit their code to Yocto because they sell thier code.
We are adding code to Yocto that has a private license and we are attempting to have Yocto accept the license, *is this proper way to handle this ?*
I am a bit confused, but can try to show you what I typically do.
In my custom meta-my-layer I add to layer.conf:

#-->
LICENSE_PATH += " ${LAYERDIR}/custom-licenses"

CUSTOM_COMMON_LICENSE_DIR := '${@os.path.normpath("${LAYERDIR}/custom-licenses")}'
BB_HASHBASE_WHITELIST_append = " CUSTOM_COMMON_LICENSE_DIR"
#<--

underneath the custom-licenses dir in this meta-my-layer I put the custom "hello-license".

*Can you tell me the proper way to add a custom license to a recipe in yocto ?*
Once you did something like mentioned above you can add the license to the recipe you use to build the funny component of your supplier.

example_0.1.bb:

LICENSE = "hello-license"
LIC_FILES_CHKSUM = "file://${CUSTOM_COMMON_LICENSE_DIR}/hello-license;beginline=5;endline=12;md5=36e6988a930e054886e6af19372edb07"

If you want to get fancy, since it does not seem to be an open source license, you can mark it also as:

LICENSE_FLAGS = "commercial" in the recipe

but then you need to whitelist e.g. in your local.conf to be able to bitbake it:

# whitelist example recipe, which is under a commercial license
LICENSE_FLAGS_WHITELIST = "commercial_example"

Thanks,
Steve
Hope this helps,

Regards,

Robert


Re: [meta-rockchip][PATCH v2 2/2] rockchip-wic.inc: dont let wic edit fstab by default

Trevor Woerner
 

On Thu 2021-09-23 @ 11:17:59 PM, Markus Volk wrote:
Signed-off-by: MarkusVolk <f_l_k@...>
---
conf/machine/include/rockchip-wic.inc | 3 +++
1 file changed, 3 insertions(+)

diff --git a/conf/machine/include/rockchip-wic.inc b/conf/machine/include/rockchip-wic.inc
index 15010a0..30b0d57 100644
--- a/conf/machine/include/rockchip-wic.inc
+++ b/conf/machine/include/rockchip-wic.inc
@@ -26,3 +26,6 @@ WICVARS:append = " \
SPL_BINARY \
UBOOT_SUFFIX \
"
+
+# Do not update fstab file while creating wic images
+WIC_CREATE_EXTRA_ARGS ?= "--no-fstab-update"
Thanks for the patch and the SoB line. I'm going to apply this patch, but I'm
going to amend the commit message to capture some of the conversation we've
had. There's a chance we'll want to know "why" at some point in the future ;-)


Re: [meta-rockchip][PATCH] use uuid instead of hard-coding root device

Trevor Woerner
 

On Thu 2021-09-23 @ 09:46:40 PM, Khem Raj wrote:
are you both using systemd or sysvinit
Ah, good catch. I'm using sysvinit.


#yocto -third party licensimg #yocto

Monsees, Steven C (US)
 

 

Hello:

 

I am running zeus 3.0.4…

 

A vendor has supplied us with a generic license.txt file, which we were able to add to the acexpci recipe we use to build in their package.

The license provided to us by the vendor is not part of the generic licenses list that yocto recognizes.

 

We get a warning though which says:

 

WARNING: aiox-defaultfs-1.0-r0 do_rootfs: The license listed DataDeviceCorporation was not in the licenses collected for recipe acexpci

 

Though the warning occurs, I can see the license.txt being saved inside the rootfs on and is saved under tmp/deploy/licenses/acexpci.

I’ve been trying to get rid of this warning when the image builds, but I can’t seem to find anything in the manuals or online.

 

The one solution I found says : Add LICENSE_PATH += "${LAYERDIR}/custom-licenses" under conf/layer.conf, this does not resolve this warning.

 

This is a new item being added to our Yocto build.

The Data Direct vendor does not submit their code to Yocto because they sell thier code.

We are adding code to Yocto that has a private license and we are attempting to have Yocto accept the license, is this proper way to handle this ?

 

Can you tell me the proper way to add a custom license to a recipe in yocto ?

 

Thanks,

Steve


Re: [meta-rockchip][PATCH] use uuid instead of hard-coding root device

Markus Volk
 


Am 24.09.21 um 06:46 schrieb Khem Raj:
are you both using systemd or sysvinit
I am using systemd


Re: Cross-compiling or compiling on target VM?

Alexander Kanavin
 

Yocto has built-in qemu targets for this purpose, and associated infrastructure to start qemu VMs and run tests in them. But to make it practical, these qemu images need to be started on a baremetal Linux machine. So I'd suggest you start by giving all your developers Linux laptops.

Alex


On Fri, 24 Sept 2021 at 11:06, <arnaud.bienner@...> wrote:
Hi,

We are starting a new project using Yocto to build a custom Linux image which matches our needs.
We are new to Yocto and still trying to figure out the best way to work with it.

Especially, if it is best to cross-compile or to build on a VM running an image of the target.

Some background:
Our target system is x86_64, and we are all working on x86_64 computers obviously.
For now, we don't have yet a physical target system so we are running the image generated by Yocto in VirtualBox or VMWare.

For practical reasons, since not all developers use the same OS (Windows, macOS) we decided to do all development work on Linux VM (Debian distribution) so everyone has the same system.
For now, we are cross-compiling applications using Yocto SDK in that Debian VM, copying it to the Yocto VM to run it.
Even though copying/deploying and running them could be somehow automated, since we are developing on a Linux VM anyway, I thought it could be best to build a Yocto image (maybe as an additional "dev" image based on the existing one) which contains all tools we need (gcc, cmake, etc.).

This way, we could execute the binaries (in particular the unit tests) locally.
For some of our unit tests in particular that we run at build time, it sounds easier to run them locally, compared to deploying them and running them remotely.

Any thoughts about this?

In advance, thanks a lot for your help.

Best regards,
Arnaud



[meta-selinux][PATCH] libsepol: Security fix for CVE-2021-36086

Yi Zhao
 

CVE-2021-36086:
The CIL compiler in SELinux 3.2 has a use-after-free in cil_reset_classpermission
(called from cil_reset_classperms_set and cil_reset_classperms_list).

Reference:
https://nvd.nist.gov/vuln/detail/CVE-2021-36086

Patch from:
https://github.com/SELinuxProject/selinux/commit/c49a8ea09501ad66e799ea41b8154b6770fec2c8

Signed-off-by: Yi Zhao <yi.zhao@...>
---
.../selinux/libsepol/CVE-2021-36086.patch | 46 +++++++++++++++++++
recipes-security/selinux/libsepol_3.2.bb | 3 +-
2 files changed, 48 insertions(+), 1 deletion(-)
create mode 100644 recipes-security/selinux/libsepol/CVE-2021-36086.patch

diff --git a/recipes-security/selinux/libsepol/CVE-2021-36086.patch b/recipes-security/selinux/libsepol/CVE-2021-36086.patch
new file mode 100644
index 0000000..7a2d616
--- /dev/null
+++ b/recipes-security/selinux/libsepol/CVE-2021-36086.patch
@@ -0,0 +1,46 @@
+From 49f9aa2a460fc95f04c99b44f4dd0d22e2f0e5ee Mon Sep 17 00:00:00 2001
+From: James Carter <jwcart2@...>
+Date: Thu, 8 Apr 2021 13:32:06 -0400
+Subject: [PATCH] libsepol/cil: cil_reset_classperms_set() should not reset
+ classpermission
+
+In struct cil_classperms_set, the set field is a pointer to a
+struct cil_classpermission which is looked up in the symbol table.
+Since the cil_classperms_set does not create the cil_classpermission,
+it should not reset it.
+
+Set the set field to NULL instead of resetting the classpermission
+that it points to.
+
+Signed-off-by: James Carter <jwcart2@...>
+
+Upstream-Status: Backport
+[https://github.com/SELinuxProject/selinux/commit/c49a8ea09501ad66e799ea41b8154b6770fec2c8]
+
+CVE: CVE-2021-36086
+
+Signed-off-by: Yi Zhao <yi.zhao@...>
+---
+ cil/src/cil_reset_ast.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/cil/src/cil_reset_ast.c b/cil/src/cil_reset_ast.c
+index 89f91e5..1d9ca70 100644
+--- a/cil/src/cil_reset_ast.c
++++ b/cil/src/cil_reset_ast.c
+@@ -59,7 +59,11 @@ static void cil_reset_classpermission(struct cil_classpermission *cp)
+
+ static void cil_reset_classperms_set(struct cil_classperms_set *cp_set)
+ {
+- cil_reset_classpermission(cp_set->set);
++ if (cp_set == NULL) {
++ return;
++ }
++
++ cp_set->set = NULL;
+ }
+
+ static inline void cil_reset_classperms_list(struct cil_list *cp_list)
+--
+2.17.1
+
diff --git a/recipes-security/selinux/libsepol_3.2.bb b/recipes-security/selinux/libsepol_3.2.bb
index ef5de1e..192f1b3 100644
--- a/recipes-security/selinux/libsepol_3.2.bb
+++ b/recipes-security/selinux/libsepol_3.2.bb
@@ -10,7 +10,8 @@ LIC_FILES_CHKSUM = "file://${S}/COPYING;md5=a6f89e2100d9b6cdffcea4f398e37343"
require selinux_common.inc

SRC_URI += "file://CVE-2021-36084.patch \
- file://CVE-2021-36085.patch "
+ file://CVE-2021-36085.patch \
+ file://CVE-2021-36086.patch "

inherit lib_package

--
2.25.1


Cross-compiling or compiling on target VM?

arnaud.bienner@...
 

Hi,

We are starting a new project using Yocto to build a custom Linux image which matches our needs.
We are new to Yocto and still trying to figure out the best way to work with it.

Especially, if it is best to cross-compile or to build on a VM running an image of the target.

Some background:
Our target system is x86_64, and we are all working on x86_64 computers obviously.
For now, we don't have yet a physical target system so we are running the image generated by Yocto in VirtualBox or VMWare.

For practical reasons, since not all developers use the same OS (Windows, macOS) we decided to do all development work on Linux VM (Debian distribution) so everyone has the same system.
For now, we are cross-compiling applications using Yocto SDK in that Debian VM, copying it to the Yocto VM to run it.
Even though copying/deploying and running them could be somehow automated, since we are developing on a Linux VM anyway, I thought it could be best to build a Yocto image (maybe as an additional "dev" image based on the existing one) which contains all tools we need (gcc, cmake, etc.).

This way, we could execute the binaries (in particular the unit tests) locally.
For some of our unit tests in particular that we run at build time, it sounds easier to run them locally, compared to deploying them and running them remotely.

Any thoughts about this?

In advance, thanks a lot for your help.

Best regards,
Arnaud


Re: Using bitbake with external SDK #sdk #zeus #toolchain

Marco Cavallini
 

Hello Enrico,
an eSDK would be enough to do everything, however I would demand the entire development system if I were to start a project, but that is my opinion.
I don't know well Node-RED but using devtool add you should be able to create or manage a recipe for any Node application.
Happy hacking!
--
Marco Cavallini | KOAN sas
Bergamo - Italia
embedded software engineering
https://KoanSoftware.com


Re: Using bitbake with external SDK #sdk #zeus #toolchain

enrico.buffoli1994@...
 

Hello Marco,

In your opinion isn't enough to ask for eSDK? for instance if i want to add Node-RED, it would be difficult to build with devtool? because i've seen that it doesn't resolve dependencies automatically.
Thanks.


Re: Using bitbake with external SDK #sdk #zeus #toolchain

enrico.buffoli1994@...
 

With the eSDK i've to use devtool right?


Re: Using bitbake with external SDK #sdk #zeus #toolchain

Marco Cavallini
 

Hello Enrico,
usually nowadays every honest hardware manufacturer provides all the sources of the BSP and the development system to their customers.
Try asking your supplier for them.
--
Marco Cavallini | KOAN sas
Bergamo - Italia
embedded software engineering
https://KoanSoftware.com


[meta-zephyr][PATCH 1/2] zephyr-qemuboot: fix parse build failure

Naveen Saini
 

As OE-core explicitly have added depends for qemu-helper addto_recipe_sysroot task, which
breaks zephyr-qemuboot implementation of adding build dependencies
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=282d596b8cc81d650b6d20c6131fdc236bad2c20

ERROR: Error for meta-zephyr/recipes-kernel/zephyr-kernel/zephyr-helloworld.bb:
do_bootconf_write[depends], dependency qemu-helper-native:do_addto_recipe_sysroot:do_addto_recipe_sysroot in
' qemu-helper-native:do_addto_recipe_sysroot:do_addto_recipe_sysroot qemu-helper-native:do_addto_recipe_sysroot:do_populate_sysroot' does not contain exactly one ':' character.
Task 'depends' should be specified in the form 'packagename:task'
ERROR: Command execution failed: Exited with 1

Signed-off-by: Naveen Saini <naveen.kumar.saini@...>
---
classes/zephyr-qemuboot.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/classes/zephyr-qemuboot.bbclass b/classes/zephyr-qemuboot.bbclass
index c268e9e..b45e6f6 100644
--- a/classes/zephyr-qemuboot.bbclass
+++ b/classes/zephyr-qemuboot.bbclass
@@ -48,7 +48,7 @@ python () {
for dep in (d.getVar('EXTRA_IMAGEDEPENDS') or "").split():
# Make sure we only add it for qemu
if 'qemu-helper-native' in dep:
- deps += " %s:%s" % (dep, task)
+ deps += " qemu-helper-native:%s" % (task)
return deps
d.appendVarFlag('do_bootconf_write', 'depends', extraimage_getdepends('do_addto_recipe_sysroot'))
d.appendVarFlag('do_bootconf_write', 'depends', extraimage_getdepends('do_populate_sysroot'))
--
2.17.1

2561 - 2580 of 57376