Date   

Re: [meta-cgl][PATCH] ucarp: fix build error with gcc-10

Bas Mevissen
 

On 2020-09-23 09:56, Chen Qi wrote:
gcc-10 uses '-fno-common' by default, causing multiple definition
error. Use '-fcommon' to fix this problem.
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
---
meta-cgl-common/recipes-cgl/ucarp/ucarp_1.5.2.bb | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta-cgl-common/recipes-cgl/ucarp/ucarp_1.5.2.bb
b/meta-cgl-common/recipes-cgl/ucarp/ucarp_1.5.2.bb
index d17baa0..87e5ada 100644
--- a/meta-cgl-common/recipes-cgl/ucarp/ucarp_1.5.2.bb
+++ b/meta-cgl-common/recipes-cgl/ucarp/ucarp_1.5.2.bb
@@ -37,6 +37,9 @@ SYSTEMD_AUTO_ENABLE = "disable"
export FETCHCMD_wget = "/usr/bin/env wget --secure-protocol=TLSv1_2
-t 2 -T 30 --passive-ftp --no-check-certificate"
EXTRA_OECONF += "--sysconfdir=${sysconfdir}/${BPN}"
+# Fix build error with gcc-10
+CFLAGS_append = " -fcommon"
+
Why are you not patching the source to use "extern" where it is needed, like in pacemaker? How many errors does ucarp give?
Then it might also a patch that upstream will take, solving the issue forever in a proper way.

# fix the perms for config.rpath
do_configure_prepend() {
chmod 755 ${S}/config.rpath


[meta-cgl][PATCH] meta-cgl-common: depend on meta-python2 layer

Chen Qi
 

It requires meta-python2 to be there at the moment.
More specifically, the crmsh recipe needs python-setuptools-native.

Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
---
meta-cgl-common/conf/layer.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-cgl-common/conf/layer.conf b/meta-cgl-common/conf/layer.conf
index 6035b4b..6b689ea 100644
--- a/meta-cgl-common/conf/layer.conf
+++ b/meta-cgl-common/conf/layer.conf
@@ -9,7 +9,7 @@ BBFILE_COLLECTIONS += "cgl-common"
BBFILE_PATTERN_cgl-common = "^${LAYERDIR}/"
BBFILE_PRIORITY_cgl-common = "7"

-LAYERDEPENDS_cgl-common = "core openembedded-layer networking-layer perl-layer filesystems-layer security selinux"
+LAYERDEPENDS_cgl-common = "core openembedded-layer networking-layer perl-layer filesystems-layer security selinux meta-python2"

LAYERSERIES_COMPAT_cgl-common = "warrior zeus dunfell"

--
2.17.1


[meta-cgl][PATCH] ucarp: fix build error with gcc-10

Chen Qi
 

gcc-10 uses '-fno-common' by default, causing multiple definition
error. Use '-fcommon' to fix this problem.

Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
---
meta-cgl-common/recipes-cgl/ucarp/ucarp_1.5.2.bb | 3 +++
1 file changed, 3 insertions(+)

diff --git a/meta-cgl-common/recipes-cgl/ucarp/ucarp_1.5.2.bb b/meta-cgl-common/recipes-cgl/ucarp/ucarp_1.5.2.bb
index d17baa0..87e5ada 100644
--- a/meta-cgl-common/recipes-cgl/ucarp/ucarp_1.5.2.bb
+++ b/meta-cgl-common/recipes-cgl/ucarp/ucarp_1.5.2.bb
@@ -37,6 +37,9 @@ SYSTEMD_AUTO_ENABLE = "disable"
export FETCHCMD_wget = "/usr/bin/env wget --secure-protocol=TLSv1_2 -t 2 -T 30 --passive-ftp --no-check-certificate"
EXTRA_OECONF += "--sysconfdir=${sysconfdir}/${BPN}"

+# Fix build error with gcc-10
+CFLAGS_append = " -fcommon"
+
# fix the perms for config.rpath
do_configure_prepend() {
chmod 755 ${S}/config.rpath
--
2.17.1


[meta-cgl][PATCH] pacemaker: Fix build with -fno-common

Chen Qi
 

From: Mingli Yu <mingli.yu@windriver.com>

Starting with GCC >= 10.x, -fno-common is used as default
instead of -fcommon.

Make the function definiton extern to fix the build failure.

Signed-off-by: Mingli Yu <mingli.yu@windriver.com>
---
.../0001-Mark-declaration-with-extern.patch | 46 +++++++++++++++++++
...maker-set-OCF_ROOT_DIR-to-libdir-ocf.patch | 32 +++++++++++++
.../recipes-cgl/pacemaker/pacemaker_2.0.3.bb | 2 +
3 files changed, 80 insertions(+)
create mode 100644 meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-Mark-declaration-with-extern.patch
create mode 100644 meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-pacemaker-set-OCF_ROOT_DIR-to-libdir-ocf.patch

diff --git a/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-Mark-declaration-with-extern.patch b/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-Mark-declaration-with-extern.patch
new file mode 100644
index 0000000..5729447
--- /dev/null
+++ b/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-Mark-declaration-with-extern.patch
@@ -0,0 +1,46 @@
+From e1abd3b7c7a0122813e4d0abdb079df10104882c Mon Sep 17 00:00:00 2001
+From: Mingli Yu <mingli.yu@windriver.com>
+Date: Thu, 3 Sep 2020 04:44:09 +0000
+Subject: [PATCH] Mark declaration with extern
+
+Fixes build with gcc 10+
+
+Upstream-Status: Pending
+
+Signed-off-by: Mingli Yu <mingli.yu@windriver.com>
+---
+ daemons/attrd/pacemaker-attrd.h | 4 ++--
+ daemons/execd/pacemaker-execd.h | 2 +-
+ 2 files changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/daemons/attrd/pacemaker-attrd.h b/daemons/attrd/pacemaker-attrd.h
+index cc8e29ee1..76778915e 100644
+--- a/daemons/attrd/pacemaker-attrd.h
++++ b/daemons/attrd/pacemaker-attrd.h
+@@ -106,8 +106,8 @@ typedef struct attribute_value_s {
+ gboolean seen;
+ } attribute_value_t;
+
+-crm_cluster_t *attrd_cluster;
+-GHashTable *attributes;
++extern crm_cluster_t *attrd_cluster;
++extern GHashTable *attributes;
+
+ #define attrd_send_ack(client, id, flags) \
+ crm_ipcs_send_ack((client), (id), (flags), "ack", __FUNCTION__, __LINE__)
+diff --git a/daemons/execd/pacemaker-execd.h b/daemons/execd/pacemaker-execd.h
+index 4a52d9183..dab3ccdbe 100644
+--- a/daemons/execd/pacemaker-execd.h
++++ b/daemons/execd/pacemaker-execd.h
+@@ -20,7 +20,7 @@
+ # include <gnutls/gnutls.h>
+ # endif
+
+-GHashTable *rsc_list;
++extern GHashTable *rsc_list;
+
+ typedef struct lrmd_rsc_s {
+ char *rsc_id;
+--
+2.26.2
+
diff --git a/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-pacemaker-set-OCF_ROOT_DIR-to-libdir-ocf.patch b/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-pacemaker-set-OCF_ROOT_DIR-to-libdir-ocf.patch
new file mode 100644
index 0000000..1ff9c7d
--- /dev/null
+++ b/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-pacemaker-set-OCF_ROOT_DIR-to-libdir-ocf.patch
@@ -0,0 +1,32 @@
+From 3ca78a6441eefc26f18211375b18205ed6fc28c6 Mon Sep 17 00:00:00 2001
+From: Mingli Yu <mingli.yu@windriver.com>
+Date: Thu, 3 Sep 2020 05:26:36 +0000
+Subject: [PATCH] pacemaker: set OCF_ROOT_DIR to $libdir/ocf
+
+* Set the default OCF_ROOT_DIR to $libdir/ocf
+ to make the resource agents components more
+ compatible
+
+Upstream-Status: Pending
+
+Signed-off-by: Mingli Yu <mingli.yu@windriver.com>
+---
+ configure.ac | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/configure.ac b/configure.ac
+index 58d39cdc0..eb4275560 100644
+--- a/configure.ac
++++ b/configure.ac
+@@ -315,7 +315,7 @@ dnl This defaults to /usr/lib rather than libdir because it's determined by the
+ dnl OCF project and not pacemaker. Even if a user wants to install pacemaker to
+ dnl /usr/local or such, the OCF agents will be expected in their usual
+ dnl location. However, we do give the user the option to override it.
+-OCF_ROOT_DIR="/usr/lib/ocf"
++OCF_ROOT_DIR="$libdir/ocf"
+ AC_ARG_WITH([ocfdir],
+ [AS_HELP_STRING([--with-ocfdir=DIR],
+ [OCF resource agent root directory (advanced option: changing this may break other cluster components unless similarly configured) @<:@/usr/lib/ocf@:>@])],
+--
+2.26.2
+
diff --git a/meta-cgl-common/recipes-cgl/pacemaker/pacemaker_2.0.3.bb b/meta-cgl-common/recipes-cgl/pacemaker/pacemaker_2.0.3.bb
index 9b63acd..56f3bc4 100644
--- a/meta-cgl-common/recipes-cgl/pacemaker/pacemaker_2.0.3.bb
+++ b/meta-cgl-common/recipes-cgl/pacemaker/pacemaker_2.0.3.bb
@@ -16,6 +16,8 @@ DEPENDS = "corosync libxslt libxml2 gnutls resource-agents libqb python3-native"
SRC_URI = "git://github.com/ClusterLabs/${BPN}.git \
file://0006-Fix-tools-Fix-definition-of-curses_indented_printf.patch \
file://0001-Fix-python3-usage.patch \
+ file://0001-Mark-declaration-with-extern.patch \
+ file://0001-pacemaker-set-OCF_ROOT_DIR-to-libdir-ocf.patch \
file://volatiles \
file://tmpfiles \
"
--
2.17.1


Re: bitbake recipe / Network UPS tool

Yocto
 


On 9/23/20 12:48 PM, Maciej Pijanowski wrote:


On 07.09.2020 11:58, Yocto wrote:

On 9/7/20 1:23 PM, Maciej Pijanowski wrote:

Hi,

I happen to have this recipe lying around. I have not upstreamed it for some
reason (probably lack of time and I have not been using this package at the end,
so it is not properly tested out). I gave it a try today and at least it builds.

Please try it out: https://github.com/3mdeb/meta-openembedded/commit/e523d0bb4bddf0ef8521804459b265c14100f83c

If it works for you, please let me know. I would be happy to push the patches upstream.

wow... much appreciated, probably just saved me a few headaches and a ton of time.

Ill get it onboard and configured and let you know how i make out!

I was actually surprised to not find it already in the tree....
Have you got a chance to test something?

its  in the build we are assembling the system the past 2 days actually with the ups / power supply and case for prototype... testing will come in days when i have a functional device built i can flash it and test it all out



Thanks


-- 
Maciej Pijanowski
Embedded Systems Engineer
GPG: 9963C36AAC3B2B46
https://3mdeb.com | @3mdeb_com




[meta-security][master][dunfell][PATCH] gitignore added

Adrian Freihofer
 

After running testimage there are some python left overs at
lib/oeqa/runtime/cases/__pycache__/

Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
---
.gitignore | 7 +++++++
1 file changed, 7 insertions(+)
create mode 100644 .gitignore

diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..c01df45
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,7 @@
+*.pyc
+*.pyo
+/*.patch
+*.swp
+*.orig
+*.rej
+*~
--
2.26.2


Re: bitbake recipe / Network UPS tool

Maciej Pijanowski
 


On 07.09.2020 11:58, Yocto wrote:

On 9/7/20 1:23 PM, Maciej Pijanowski wrote:

Hi,

I happen to have this recipe lying around. I have not upstreamed it for some
reason (probably lack of time and I have not been using this package at the end,
so it is not properly tested out). I gave it a try today and at least it builds.

Please try it out: https://github.com/3mdeb/meta-openembedded/commit/e523d0bb4bddf0ef8521804459b265c14100f83c

If it works for you, please let me know. I would be happy to push the patches upstream.

wow... much appreciated, probably just saved me a few headaches and a ton of time.

Ill get it onboard and configured and let you know how i make out!

I was actually surprised to not find it already in the tree....
Have you got a chance to test something?

Thanks



    
-- 
Maciej Pijanowski
Embedded Systems Engineer
GPG: 9963C36AAC3B2B46
https://3mdeb.com | @3mdeb_com


Re: Yocto recipe for Tailscale #yocto #golang

Mike Thompson
 

On Mon, Sep 21, 2020 at 10:31 AM, Randy MacLeod wrote:

Could you send your tailscale recipe to meta-openembedded/meta-networking?
    Email: OpenEmbedded Development mailing list <openembedded-devel@...>
    Instructions: https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded

It looks like all the work is done aside from an email!

Sure.  I'm traveling right now, but I'll look to do this in the next week or two.

Mike Thompson


Re: RDEPENDS problem

Greg Wilson-Lindberg
 

Hi Quentin,
It turns out that there was a problem in the build of the libcanfestival.so library that was adding in a reference to ../bin/....
This caused the failure that I asked about initially.

Thank you for your suggestions that then led me to figuring out the problem with the canfestival build.

Greg

-----Original Message-----
From: Quentin Schulz <quentin.schulz@streamunlimited.com>
Sent: Tuesday, September 22, 2020 1:20 AM
To: Greg Wilson-Lindberg <GWilson@sakuraus.com>
Cc: Yocto list discussion <yocto@yoctoproject.org>
Subject: Re: [yocto] RDEPENDS problem

Hi Greg,

On Mon, Sep 21, 2020 at 09:46:51PM +0000, Greg Wilson-Lindberg wrote:

 I have a custom recipe that copies a .so, that libMotors.so calls functions in
another libcanfestival.so.

When I first added in the copy of the .so I didn't have an RDEPENDS
and Yocto printed out an warning listing the package that it wanted. I
added an RDEPENDS_${PN} with all of the packages listed, but I'm still
getting an error for the first libMotors.so:

ERROR: userconfig-1.0-r0 do_package_qa: QA Issue:
/home/sakura/lib/libMotors.so.1.0.0 contained in package userconfig
requires libcanfestival.so, but no providers found in
RDEPENDS_userconfig? [file-rdeps]

In userdepends I added:

RDEPENDS_${PN} += "canfestival libelf libgcrypt pcsc-lite-lib qtbase
qtdeclarative qtserialport zint"

Package canfestival_3-asc in has:

FILES_${PN} = "/usr/lib/libcanfestival.so /usr/lib/libcanfestival_unix.so
/usr/lib/libcanfestival_can_socket.so"
.so files are installed in the -dev package even with the line above.

Please have a look here:
https://wiki.yoctoproject.org/wiki/TipsAndTricks/Packaging_Prebuilt_Librarie
s#Non-versioned_Libraries
if there is really no way for you to avoid having a non-versioned library.
First, the canfestival package that I have doesn't create versioned libraries, only the non-versioned .so's.

I changed the canfestival .bb to:

SOLIBS = ".so.*"
SOLIBSDEV = ".so"

FILES_${PN} = " ${libdir}/lib*${SOLIBSDEV}"
FILES_SOLIBSDEV ?= " ${libdir}/lib*${SOLIBSDEV}"
FILES_${PN}-dev = " /usr/include/canfestival/*.h ${FILES_SOLIBSDEV}"

And I get the following error:

ERROR: canfestival-3-asc-r01 do_package_qa: QA Issue: -dev package contains non-symlink .so: canfestival-dev path '/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/canfestival/3-asc-r01/packages-split/canfestival-dev/usr/lib/libcanfestival_unix.so'
-dev package contains non-symlink .so: canfestival-dev path '/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/canfestival/3-asc-r01/packages-split/canfestival-dev/usr/lib/libcanfestival.so'
-dev package contains non-symlink .so: canfestival-dev path '/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/canfestival/3-asc-r01/packages-split/canfestival-dev/usr/lib/libcanfestival_can_socket.so' [dev-elf]
ERROR: canfestival-3-asc-r01 do_package_qa: QA run found fatal errors. Please consider fixing them.

I removed the ${FILES_SOLIBSDEV} from the FILES_${PN}-dev and then I get:
WARNING: canfestival-3-asc-r01 do_package: canfestival-dev-3-asc was registered as shlib provider for ../bin/libcanfestival.so, changing it to canfestival-3-asc because it was built later
WARNING: canfestival-3-asc-r01 do_package: canfestival-dev-3-asc was registered as shlib provider for libcanfestival_can_socket.so, changing it to canfestival-3-asc because it was built later
WARNING: canfestival-3-asc-r01 do_package: canfestival-dev-3-asc was registered as shlib provider for libcanfestival_unix.so, changing it to canfestival-3-asc because it was built later
ERROR: userconfig-1.0-r0 do_package_qa: QA Issue: /home/sakura/lib/libMotors.so.1.0.0 contained in package userconfig requires libcanfestival.so, but no providers found in RDEPENDS_userconfig? [file-rdeps]
ERROR: userconfig-1.0-r0 do_package_qa: QA run found fatal errors. Please consider fixing them.

It looks like the first warning is the key to the ERROR of not finding libcanfestival.so, but not getting errors for the other 2 libraries.

I looked in the build for canfestival and nowhere is there a bin/libcanfestival.so. Any ideas of how this could be created or referenced?




You can check if .so files are part of a package by using `oe-pkgdata-util find-
path /usr/lib/libcanfestival.so`

Cheers,
Quentin


Re: How to *properly* use SSTATE_DUPWHITELIST?

Richard Purdie
 

On Tue, 2020-09-22 at 16:40 -0400, Robert P. J. Day wrote:
Quoting "Robert P. J. Day" <rpjday@crashcourse.ca>:

Never had cause to dig into SSTATE_DUPWHITELIST until now,
so a couple questions. (Side Note: This variable is not listed
in the YP Reference Manual variable glossary -- should it be?)

Ran across this as current project incorporates recipes
grpc-python and python-grpcio, which is problematic as the
latter is simply the renamed version of the former so, yeah,
that's definitely going to generate a ton of file install
conflicts.

The solution selected (and, yes, I know this is tacky and
gross and this should be fixed the right way) was to add
the line:

SSTATE_DUPWHITELIST = "/"

to python-grpcio.inc, which *seemed* to fix the problem,
until I started playing this morning to clarify what different
variations of this solution would do.

First oddity was that, after I added or deleted that line,
it seemed it made no difference in the rebuild of the
incorporating image, until I noticed this in
sstate.bbclass:

sstate_install[vardepsexclude] += "SSTATE_DUPWHITELIST ..."

which suggests that the sstate doesn't check dependency
based on SSTATE_DUPWHITELIST, so to get the change to kick in,
I did a "bitbake -c cleanall ..." on those recipes first,
and that seemed to do it.

But even that showed some weirdly non-deterministic behaviour,
as there seemed to be a difference based on which recipe I
added that line to, and which recipe I cleaned. So the
obvious question is, if I have two recipes that clash in
terms of installed files like these two, does one add that
line to either or both of the recipes? What does it mean to
add it to only one, and if that happens (as it did here),
how does that affect the eventual install? Does ordering then
matter?

In a general case, if I have, say, 5 recipes all of which
clash in the same place, do I add that line to all 5 recipes?
And if I don't, do I get undefined behaviour?
Oh, wait, I think I misunderstood this variable entirely --
it's not a per-recipe variable, is it? Its value represents the
combination over all recipes in the image, is that right? So
by adding the line:

SSTATE_DUPWHITELIST = "/"

I've effectively de-activated file conflict errors across the
entire rootfs and all recipes in the image, do I have that right?
You are totally misunderstanding what this variable does. It has
nothing to do with images or rootfs. Its also definitely not per
recipe.

sstate has an overall view of any output 'deployed' in TMPDIR. For
example the sstate of the do_package_write_ipk tasks deploys the ipks
into DEPLOY_DIR_IPK.

In a perfect world, no sstate should overwrite the sstate of anything
else.

In reality there are some corner cases where one set of sstate output
may overwrite another set. An example would be the sdk-provides-dummy-
target ipk/rpm files when multilib is enabled.

This variable controls whether these overlapping sstate files should be
allowed or whether they should be errors.

Documenting it is a low priority as either you understand the sstate
code internals and know how to use it or you probably shouldn't be
changing it.

Cheers,

Richard


Re: How to *properly* use SSTATE_DUPWHITELIST?

Robert P. J. Day
 

Quoting "Robert P. J. Day" <rpjday@crashcourse.ca>:

Never had cause to dig into SSTATE_DUPWHITELIST until now,
so a couple questions. (Side Note: This variable is not listed
in the YP Reference Manual variable glossary -- should it be?)

Ran across this as current project incorporates recipes
grpc-python and python-grpcio, which is problematic as the
latter is simply the renamed version of the former so, yeah,
that's definitely going to generate a ton of file install
conflicts.

The solution selected (and, yes, I know this is tacky and
gross and this should be fixed the right way) was to add
the line:

SSTATE_DUPWHITELIST = "/"

to python-grpcio.inc, which *seemed* to fix the problem,
until I started playing this morning to clarify what different
variations of this solution would do.

First oddity was that, after I added or deleted that line,
it seemed it made no difference in the rebuild of the
incorporating image, until I noticed this in
sstate.bbclass:

sstate_install[vardepsexclude] += "SSTATE_DUPWHITELIST ..."

which suggests that the sstate doesn't check dependency
based on SSTATE_DUPWHITELIST, so to get the change to kick in,
I did a "bitbake -c cleanall ..." on those recipes first,
and that seemed to do it.

But even that showed some weirdly non-deterministic behaviour,
as there seemed to be a difference based on which recipe I
added that line to, and which recipe I cleaned. So the
obvious question is, if I have two recipes that clash in
terms of installed files like these two, does one add that
line to either or both of the recipes? What does it mean to
add it to only one, and if that happens (as it did here),
how does that affect the eventual install? Does ordering then
matter?

In a general case, if I have, say, 5 recipes all of which
clash in the same place, do I add that line to all 5 recipes?
And if I don't, do I get undefined behaviour?
Oh, wait, I think I misunderstood this variable entirely --
it's not a per-recipe variable, is it? Its value represents the
combination over all recipes in the image, is that right? So
by adding the line:

SSTATE_DUPWHITELIST = "/"

I've effectively de-activated file conflict errors across the
entire rootfs and all recipes in the image, do I have that right?

rday


How to *properly* use SSTATE_DUPWHITELIST?

Robert P. J. Day
 

Never had cause to dig into SSTATE_DUPWHITELIST until now,
so a couple questions. (Side Note: This variable is not listed
in the YP Reference Manual variable glossary -- should it be?)

Ran across this as current project incorporates recipes
grpc-python and python-grpcio, which is problematic as the
latter is simply the renamed version of the former so, yeah,
that's definitely going to generate a ton of file install
conflicts.

The solution selected (and, yes, I know this is tacky and
gross and this should be fixed the right way) was to add
the line:

SSTATE_DUPWHITELIST = "/"

to python-grpcio.inc, which *seemed* to fix the problem,
until I started playing this morning to clarify what different
variations of this solution would do.

First oddity was that, after I added or deleted that line,
it seemed it made no difference in the rebuild of the
incorporating image, until I noticed this in
sstate.bbclass:

sstate_install[vardepsexclude] += "SSTATE_DUPWHITELIST ..."

which suggests that the sstate doesn't check dependency
based on SSTATE_DUPWHITELIST, so to get the change to kick in,
I did a "bitbake -c cleanall ..." on those recipes first,
and that seemed to do it.

But even that showed some weirdly non-deterministic behaviour,
as there seemed to be a difference based on which recipe I
added that line to, and which recipe I cleaned. So the
obvious question is, if I have two recipes that clash in
terms of installed files like these two, does one add that
line to either or both of the recipes? What does it mean to
add it to only one, and if that happens (as it did here),
how does that affect the eventual install? Does ordering then
matter?

In a general case, if I have, say, 5 recipes all of which
clash in the same place, do I add that line to all 5 recipes?
And if I don't, do I get undefined behaviour?

rday


M+ & H bugs with Milestone Movements WW38

Stephen Jolley
 

All,

 

YP M+ or high bugs which moved to a new milestone in WW38 are listed below:

Priority

Bug ID

Short Description

Changer

Owner

Was

Became

High

14027

bitbake cooker processes left hanging at exit

randy.macleod@...

richard.purdie@...

3.2 M3

3.2 M4

Medium+

5389

bitbake/lib/bb/fetch2: filename too long

randy.macleod@...

unassigned@...

3.2 M3

3.3 M1

 

8805

Detect and warn people naming functions something_remove_something

randy.macleod@...

unassigned@...

3.2 M3

3.3 M1

 

10061

Ctrl+C during BB_HASHCHECK_FUNCTION execution does not interrupt processing nicely

randy.macleod@...

unassigned@...

3.2 M3

3.3 M1

 

10731

bitbake --observe-only doesn't work with memres

randy.macleod@...

unassigned@...

3.2 M3

3.3 M1

 

11781

bitbake --observe-only may get KeyError

randy.macleod@...

unassigned@...

3.2 M3

3.3 M1

 

11899

broken 'bitbake --status-only' and 'bitbake -m'

randy.macleod@...

unassigned@...

3.2 M3

3.3 M1

 

12023

bitbake-layers show-layers doesn't show layer if it doesn't append itself to BBFILE_COLLECTIONS

randy.macleod@...

unassigned@...

3.2 M3

3.3 M1

 

12290

cross recipe kernel module dependency generation stopped working

randy.macleod@...

unassigned@...

3.2 M3

3.3 M1

 

12374

do_rootfs failed when len(TMPDIR) == 410

randy.macleod@...

unassigned@...

3.2 M3

3.3 M1

 

12367

moving or removing tmp breaks persistent bitbake server

randy.macleod@...

unassigned@...

3.2 M3

3.3 M1

 

12963

nativesdk-opkg prefixes all internal paths with $SDKPATH and won't work

randy.macleod@...

unassigned@...

3.2 M3

3.3 M1

 

13039

fetch2: PREMIRROR and SRC_URI with type https and parameter downloadfilename yields invalid url

randy.macleod@...

unassigned@...

3.2 M3

3.3 M1

 

13181

persist_data sqlite database mixed with forking is irreparably broken

randy.macleod@...

unassigned@...

3.2 M3

3.3 M1

 

13236

sstate for host native packages

randy.macleod@...

unassigned@...

3.2 M3

3.3 M1

 

13279

Make sure users/groups exist for package_write_* tasks

randy.macleod@...

unassigned@...

3.2 M3

3.3 M1

 

13306

bitbake starts up to n^2 processes with n cpus

randy.macleod@...

unassigned@...

3.2 M3

3.3 M1

 

13353

bitbake git fetcher does not honour BB_FETCH_PREMIRRORONLY

randy.macleod@...

unassigned@...

3.2 M3

3.3 M1

 

13411

ptest-perl.bbclass run-ptest is too greedy for SKIP

timothy.t.orling@...

timothy.t.orling@...

3.2 M3

3.3 M1

 

13419

recipes that add users to groups cannot rely on other recipes creating those groups (when population from sstate happens)

randy.macleod@...

unassigned@...

3.2 M3

3.3 M1

 

13646

runtime tests sometimes can't login to the serial console on systemd images (generates warning)

richard.purdie@...

kai.kang@...

3.2 M4

3.2 M3

 

13690

runqemu with slirp, forwarded host ports are not available on host

timothy.t.orling@...

timothy.t.orling@...

3.2 M3

3.2 M4

 

13705

master] bitbake and hashserve.sock left behind when ^C a build

randy.macleod@...

unassigned@...

3.2 M3

3.3 M1

 

13803

devtool setupClass file copying race

timothy.t.orling@...

timothy.t.orling@...

3.2 M3

3.2 M4

 

13843

bitbake worker stuck using 100% cpu on aborted build

randy.macleod@...

unassigned@...

3.2 M3

3.3 M1

 

13868

Python cache files get lost in packages

randy.macleod@...

unassigned@...

3.2 M3

3.3 M1

 

13897

POSTINST_INTERCEPTS_DIR broken by undocumented POSTINST_INTERCEPTS_PATHS since thud

randy.macleod@...

unassigned@...

3.2 M3

3.3 M1

 

13910

Intermittent host UID contamination highlighted by devtool tests

randy.macleod@...

unassigned@...

3.2 M3

3.3 M1

 

13919

Multi License GPLv3 -lic cannot be installed into the image because it has incompatible license

randy.macleod@...

unassigned@...

3.2 M3

3.3 M1

 

13920

uninative tarball license compliance in ESDK

randy.macleod@...

unassigned@...

3.2 M3

3.3 M1

 

13929

toaster-container has been broken since morty

timothy.t.orling@...

timothy.t.orling@...

3.2 M3

3.2 M4

 

13930

Port the CROPS toaster-container selenium tests to the Autobuilder

timothy.t.orling@...

timothy.t.orling@...

3.2 M3

3.3 M1

 

13938

devtool modify virtual/kernel fails when EXTRAVERSION field is empty in Makefile

timothy.t.orling@...

timothy.t.orling@...

3.2 M3

3.2 M4

 

13976

gdb8.3 do compile with musl is error

randy.macleod@...

unassigned@...

3.2 M3

3.3 M1

 

13993

tinfoil error handling during server startup suboptimal

randy.macleod@...

unassigned@...

3.2 M3

3.2 M4

 

13994

wic is modifying /etc/fstab in place, which races with other image type tasks

randy.macleod@...

unassigned@...

3.2 M3

3.3 M1

 

13998

Changing create_sdk_files doesn't rebuild buildtools-tarball

randy.macleod@...

unassigned@...

3.2 M3

3.3 M1

 

14015

URL Arguments in MIRROR/PREMIRROR get encoded

randy.macleod@...

unassigned@...

3.2 M3

3.3 M1

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Enhancements/Bugs closed WW38!

Stephen Jolley
 

All,

 

The below were the owners of enhancements or bugs closed during the last week!

Who

Count

akuster808@...

1

randy.macleod@...

1

Grand Total

2

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Yocto Project Status WW38'20

Stephen Jolley
 

Current Dev Position: YP 3.2 M4

Next Deadline: YP 3.2 M4 Feature Freeze - Now

 

Next Team Meetings:

 

Key Status/Updates:

  • M3 rc1 has been built and been through QA. Unfortunately beaglebone fails to boot so we’ll have to go to an rc2. There were 4 other issues reported by QA too (3 ptest regressions and a bitbake UI issue).
  • We plan to build 3.1.3 imminently
  • The sphinx documentation transition has merged. There is still work needed to clean up various links and other conversion glitches as well as areas the manual needs to be brought up to date. Any help much appreciated. Big thanks to Nico for driving this!
  • The new documentation can be seen at  https://docs.yoctoproject.org/,
  • One significant potential cause for autobuilder timeout issues has been identified, potentially the journal on ext4 filesystems was causing IO prioritisation to fail as the journal only runs with one IO level. We’ve modified the journal options on autobuilder workers to be “writeback” to avoid this. This should reduce autobuilder bitbake timeout issues.
  • Two of the three significant autobuilder issues mentioned last week remain:
    • qemumips fails with systemd with 256MB memory, it needs 512MB. If we enable 512MB, we see random hangs. Unless someone can debug and sort the qemu memory issues, we may end up disabling core-image-sato-sdk and core-image-full-cmdline for qemumips+systemd
    • networking with qemu images appears to glitch at times (particularly slower targets such as ltp and qemumips), the session stalls with “no route to host”. We need better serial interrogation to determine the state of qemu when this happens, it's unclear if qemu/kernel hangs, networking fails or what is breaking. Help to add this extra debugging would be much appreciated.
  • There are new autobuilder issues this week, a pseudo bug appears to be being exposed as well as new intermittent issues, as yet not looked into.
  • We continue to struggle with a number of autobuilder intermittent bugs. You can see the list of failures we’re continuing to see by searching for the “AB-INT” tag in bugzilla: https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT

Help with any of these would be much appreciated, unfortunately it is proving hard to find anyone interested in helping figure these out and they significantly hamper our testing.

 

Ways to contribute:

 

YP 3.2 Milestone Dates:

  • YP 3.2 M3 is out of QA and will be rebuilt
  • YP 3.2 M4 build date 2020/10/5
  • YP 3.2 M4 Release date 2020/10/30

 

Planned upcoming dot releases:

  • YP 3.1.3 build date 2020/9/14
  • YP 3.1.3 release date 2020/9/25
  • YP 3.1.4 build date 2020/11/2
  • YP 3.1.4 release date 2020/11/13

 

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@...

 


Current Autobuilder Intermittent bugs by the WW created or closed.

Stephen Jolley
 

All,

Below are the lists of open and closed medium or higher Autobuilder Intermittent bugs by the WW created or closed'.

Opened

Count

 

Closed

Count

2019WW47

1

 

2020WW26

2

2020WW8

1

 

2020WW27

2

2020WW24

1

 

2020WW28

3

2020WW25

1

 

2020WW29

2

2020WW29

1

 

2020WW30

3

2020WW30

1

 

2020WW31

1

2020WW31

2

 

2020WW33

1

2020WW33

5

 

2020WW34

4

2020WW34

2

 

2020WW35

1

2020WW35

3

 

2020WW37

2

2020WW36

3

 

Grand Total

21

2020WW37

1

 

 

 

Grand Total

22

 

 

 

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Current high bug count owners for Yocto Project 3.2

Stephen Jolley
 

All,

Below is the list as of top 48 bug owners as of the end of WW38 of who have open medium or higher bugs and enhancements against YP 3.2.   There are 28 possible work days left until the final release candidates for YP 3.2 needs to be released.

Who

Count

richard.purdie@...

33

david.reyna@...

23

bruce.ashfield@...

18

akuster808@...

18

ross@...

17

bluelightning@...

17

mark.morton@...

11

kai.kang@...

10

sakib.sajal@...

10

JPEWhacker@...

10

trevor.gamblin@...

9

Qi.Chen@...

9

timothy.t.orling@...

9

raj.khem@...

5

hongxu.jia@...

5

randy.macleod@...

5

rpjday@...

4

mostthingsweb@...

4

mingli.yu@...

4

yi.zhao@...

3

jon.mason@...

3

jeanmarie.lemetayer@...

2

alejandro@...

2

michael@...

2

ydirson@...

2

jaewon@...

2

jpuhlman@...

2

steve@...

2

chee.yang.lee@...

2

kergoth@...

2

mark.hatle@...

2

khairul.rohaizzat.jamaluddin@...

1

joe.slater@...

1

liu.ming50@...

1

kai.ruhnau@...

1

akuster@...

1

Martin.Jansa@...

1

jason.wessel@...

1

kexin.hao@...

1

anuj.mittal@...

1

amber.n.elliot@...

1

maxime.roussinbelanger@...

1

changqing.li@...

1

matt.ranostay@...

1

ankur.tyagi85@...

1

aehs29@...

1

dl9pf@...

1

liezhi.yang@...

1

Grand Total

264

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Yocto Project Newcomer & Unassigned Bugs - Help Needed

Stephen Jolley
 

All,

 

The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs  Also please review: https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded

The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project.  If anyone can help, please take ownership of the bug and send patches!  If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too.

 

Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 334 unassigned or newcomer bugs.

 

We're hoping people may be able to spare some time now and again to help out with these.  Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system.  There are also roughly four different "priority" classes right now, “3.2”, “3.3, "3.99" and "Future", the more pressing/urgent issues being in "3.2" and then “3.3”.

 

Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp.pm@...) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account).  The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Re: QA notification for completed autobuilder build (yocto-3.2_M3.rc1)

Sangeeta Jain
 

Hello all,

This is the full report for yocto-3.2_M3.rc1:
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults

======= Summary ========
Beaglebone can not boot up, hence all beaglebone test case are blocked in this release.
No high milestone defects.

2 new defects and 3 ptest failures are found:

1. The beaglebone can not bootup (BUG id:14052)
This bug blocked all beaglebone test cases.
2. failure in oe-core manual test: test_dependency_explorer_is_launched (BUG id:14055)
3. valgrind ptest failed (BUG id:14051)
4. parted ptest failed (BUG id:14050)
5. pango ptest failed (BUG id:14049)

======= Bugs ========
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14052
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14055
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14051
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14050
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14049 This is the full report for yocto-3.2_M3.rc1:
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults

Thanks,
Sangeeta

-----Original Message-----
From: Pokybuild User <pokybuild@ubuntu2004-ty-2.yocto.io>
Sent: Friday, 18 September, 2020 12:18 AM
To: yocto@lists.yoctoproject.org
Cc: otavio@ossystems.com.br; yi.zhao@windriver.com; Sangal, Apoorv
<apoorv.sangal@intel.com>; Yeoh, Ee Peng <ee.peng.yeoh@intel.com>;
Chan, Aaron Chun Yew <aaron.chun.yew.chan@intel.com>;
richard.purdie@linuxfoundation.org; akuster808@gmail.com;
sjolley.yp.pm@gmail.com; Jain, Sangeeta <sangeeta.jain@intel.com>
Subject: QA notification for completed autobuilder build (yocto-3.2_M3.rc1)


A build flagged for QA (yocto-3.2_M3.rc1) was completed on the autobuilder
and is available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.2_M3.rc1


Build hash information:

bitbake: 29081375659e3dcf1c578cd98ab2c8a2e9f07ca8
meta-arm: 1f3cf5812c91cdc15f63737bf9b30cce665b2999
meta-gplv2: a8da8eb127a56561bf633ab53bec57fb5dbba537
meta-intel: f7580d72763653893c06e1d9ece7a77c4adb8485
meta-kernel: cb7f0dc5bb1ea0998c8d4fcb486148d4cab575f4
meta-mingw: 30a051401c0a73dfff486ca4d0303b434816200f
oecore: 4e7506882cabf3936f0269c2a98f61c7d595d613
poky: c6bc20857cd1bdfd25dfc50e413be84d1d12b189



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@linuxfoundation.org



[meta-zephyr][PATCH v3] zephyr-kernel: add Zephyr RTOS version 2.3.0 support

yock.gen.mah@...
 

From: "Mah, Yock Gen" <yock.gen.mah@intel.com>

Signed-off-by: Mah, Yock Gen <yock.gen.mah@intel.com>
---
classes/zephyr-kernel-src.bbclass | 16 ++++++---
.../{qemu_4.2.%.bbappend => qemu_%.bbappend} | 0
.../zephyr-kernel/zephyr-kernel-common.inc | 3 +-
.../zephyr-kernel/zephyr-kernel-src_2.2.bb | 33 -------------------
.../zephyr-kernel/zephyr-kernel-src_2.3.bb | 24 ++++++++++++++
.../zephyr-kernel/zephyr-kernel-test.inc | 5 ++-
6 files changed, 39 insertions(+), 42 deletions(-)
rename recipes-devtools/qemu/{qemu_4.2.%.bbappend => qemu_%.bbappend} (100%)
delete mode 100644 recipes-kernel/zephyr-kernel/zephyr-kernel-src_2.2.bb
create mode 100644 recipes-kernel/zephyr-kernel/zephyr-kernel-src_2.3.bb

diff --git a/classes/zephyr-kernel-src.bbclass b/classes/zephyr-kernel-src.bbclass
index 653cb9b..50e46af 100644
--- a/classes/zephyr-kernel-src.bbclass
+++ b/classes/zephyr-kernel-src.bbclass
@@ -1,13 +1,19 @@
#Set relevant variables based on Zephyr kernel version

-PREFERRED_VERSION_zephyr-kernel ??= "2.2.0"
+PREFERRED_VERSION_zephyr-kernel ??= "2.3.0"

-SRCREV = "d39cb42d0920d5658fad358ad5b91de75d747a20"
+SRCREV_FORMAT = "default_cmsis"
+SRCREV_default = "b8c78e254ff875680e99c9f131fbe285c4575927"
+SRCREV_cmsis = "542b2296e6d515b265e25c6b7208e8fea3014f90"

-SRC_URI = "git://github.com/zephyrproject-rtos/zephyr.git;protocol=https;branch=v2.2-branch \
+
+SRC_URI = "git://github.com/zephyrproject-rtos/zephyr.git;protocol=https;branch=v2.3-branch;name=default \
+ git://github.com/zephyrproject-rtos/cmsis.git;protocol=https;destsuffix=git/modules/cmsis;name=cmsis \
file://0001-cmake-add-yocto-toolchain.patch \
"
-PV = "2.2.0"
+
+PV = "2.3.0+git${SRCPV}"
+
LICENSE = "Apache-2.0"
LIC_FILES_CHKSUM = "file://LICENSE;md5=fa818a259cbed7ce8bc2a22d35a464fc"

@@ -15,7 +21,7 @@ ZEPHYR_TEST_SRCDIR = "tests/legacy/kernel/"

python () {
src_pn = d.getVar('PREFERRED_VERSION_zephyr-kernel', True)
- if src_pn == '2.2.0':
+ if src_pn == '2.3.0':
return
else:
bb.error("Unsupported Zephyr kernel version requested")
diff --git a/recipes-devtools/qemu/qemu_4.2.%.bbappend b/recipes-devtools/qemu/qemu_%.bbappend
similarity index 100%
rename from recipes-devtools/qemu/qemu_4.2.%.bbappend
rename to recipes-devtools/qemu/qemu_%.bbappend
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
index 7e569ed..7fa4b25 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
@@ -15,13 +15,14 @@ ZEPHYR_MAKE_OUTPUT = "zephyr.elf"


EXTRA_OECMAKE = " -DZEPHYR_BASE=${S} -DZEPHYR_GCC_VARIANT=yocto -DBOARD=${BOARD} -DARCH=${ARCH} -DCROSS_COMPILE=${CROSS_COMPILE} -DZEPHYR_SYSROOT=${ZEPHYR_SYSROOT} -DZEPHYR_TOOLCHAIN_VARIANT=yocto"
+EXTRA_OECMAKE_append_arm = " -DZEPHYR_MODULES=${S}/modules/cmsis"
export ZEPHYR_BASE="${S}"


# We always need a toolchain to cross-compile.
INHIBIT_DEFAULT_DEPS = "1"
DEPENDS += "gcc-cross-${TARGET_ARCH} libgcc ${TOOLCHAIN_TARGET_TASK} gperf-native"
-DEPENDS += " python3-pyelftools-native python3-pyyaml-native"
+DEPENDS += " python3-pyelftools-native python3-pyyaml-native python3-pykwalify-native"
CROSS_COMPILE = "${STAGING_BINDIR_TOOLCHAIN}/${TARGET_PREFIX}"

DEPENDS_append_qemuall = " qemu-native qemu-helper-native"
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src_2.2.bb b/recipes-kernel/zephyr-kernel/zephyr-kernel-src_2.2.bb
deleted file mode 100644
index a3e1c28..0000000
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src_2.2.bb
+++ /dev/null
@@ -1,33 +0,0 @@
-
-LICENSE = "Apache-2.0"
-LIC_FILES_CHKSUM = "file://LICENSE;md5=fa818a259cbed7ce8bc2a22d35a464fc"
-
-# tag v2.2
-SRCREV="d39cb42d0920d5658fad358ad5b91de75d747a20"
-SRC_URI = "git://github.com/zephyrproject-rtos/zephyr.git;protocol=https;branch=v2.2-branch \
- file://0001-cmake-add-yocto-toolchain.patch \
- "
-inherit cmake
-PV = "2.2.0"
-S = "${WORKDIR}/git"
-
-IMAGE_NO_MANIFEST = "1"
-INHIBIT_DEFAULT_DEPS = "1"
-
-do_configure[noexec] = "1"
-do_compile[noexec] = "1"
-
-do_compile () {
-}
-
-do_install () {
- kerneldir=${D}/usr/src/zephyr
- install -d $kerneldir
- cp -r ${S}/* $kerneldir
-}
-
-PACKAGES = "${PN}"
-FILES_${PN} = "/usr/src/zephyr"
-
-SYSROOT_DIRS += "/usr/src/zephyr"
-
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src_2.3.bb b/recipes-kernel/zephyr-kernel/zephyr-kernel-src_2.3.bb
new file mode 100644
index 0000000..8e8b5b8
--- /dev/null
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src_2.3.bb
@@ -0,0 +1,24 @@
+
+inherit zephyr-kernel-src
+inherit cmake
+
+S = "${WORKDIR}/git"
+
+IMAGE_NO_MANIFEST = "1"
+INHIBIT_DEFAULT_DEPS = "1"
+
+do_configure[noexec] = "1"
+do_compile[noexec] = "1"
+
+
+do_install () {
+ kerneldir=${D}/usr/src/zephyr
+ install -d $kerneldir
+ cp -r ${S}/* $kerneldir
+}
+
+PACKAGES = "${PN}"
+FILES_${PN} = "/usr/src/zephyr"
+
+SYSROOT_DIRS += "/usr/src/zephyr"
+
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc
index 65da7e8..faf28bd 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc
@@ -1,4 +1,4 @@
-ZEPHYRTESTS_remove = "fifo fp_sharing lifo mbox mem_heap mem_pool \
+ZEPHYRTESTS_remove = "fifo fpu_sharing lifo mbox mem_heap mem_pool \
mem_protect mem_slab msgq mutex pipe profiling sched semaphore \
stack threads tickless timer workq"

@@ -23,12 +23,11 @@ ZEPHYRTESTS_remove = "gen_isr_table spinlock smp mp"
ZEPHYRTESTS = " \
common \
context \
- critical \
device \
early_sleep \
fatal \
fifo \
- fp_sharing \
+ fpu_sharing \
gen_isr_table \
interrupt \
lifo \
--
2.25.1

1801 - 1820 of 52565