yocto@lists.yoctoproject.org

[meta-zephyr][PATCH v2 1/4] zephyr-kernel-src: order the SRCREV assignments alphabetically

Bartosz Golaszewski

#55287

From: Bartosz Golaszewski <bartosz.golaszewski@...>

It's easier to parse visually when those assignments are ordered.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@...>
Signed-off-by: Eilís Ní Fhlannagáin <elizabeth.flanagan@...>
---
 recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.1.inc | 8 ++++----
 recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.7.0.inc | 8 ++++----
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.1.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.1.inc
index 109242e..ef6ed71 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.1.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.1.inc
@@ -1,13 +1,13 @@
 SRCREV_FORMAT = "default_cmsis"
-SRCREV_default = "2d6322d74aaac838ead46bfcba0db619cff4b534"
 SRCREV_cmsis = "c3bd2094f92d574377f7af2aec147ae181aa5f8e"
+SRCREV_default = "2d6322d74aaac838ead46bfcba0db619cff4b534"
+SRCREV_libmetal = "39d049d4ae68e6f6d595fce7de1dcfc1024fb4eb"
+SRCREV_mbedtls = "5765cb7f75a9973ae9232d438e361a9d7bbc49e7"
 SRCREV_nordic = "574493fe29c79140df4827ab5d4a23df79d03681"
-SRCREV_stm32 = "f8ff8d25aa0a9e65948040c7b47ec67f3fa300df"
 SRCREV_open-amp = "6010f0523cbc75f551d9256cf782f173177acdef"
 SRCREV_openthread = "385e19da1ae15f27872c2543b97276a42f102ead"
-SRCREV_libmetal = "39d049d4ae68e6f6d595fce7de1dcfc1024fb4eb"
+SRCREV_stm32 = "f8ff8d25aa0a9e65948040c7b47ec67f3fa300df"
 SRCREV_tinycrypt = "3e9a49d2672ec01435ffbf0d788db6d95ef28de0"
-SRCREV_mbedtls = "5765cb7f75a9973ae9232d438e361a9d7bbc49e7"
 
 ZEPHYR_BRANCH = "v2.6-branch"
 PV = "2.6.1+git${SRCPV}"
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.7.0.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.7.0.inc
index a1619a7..9df2194 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.7.0.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.7.0.inc
@@ -1,13 +1,13 @@
 SRCREV_FORMAT = "default_cmsis"
-SRCREV_default = "3f826560aaf81a444018293bd6acce3c339fe150"
 SRCREV_cmsis = "b0612c97c1401feeb4160add6462c3627fe90fc7"
+SRCREV_default = "3f826560aaf81a444018293bd6acce3c339fe150"
+SRCREV_libmetal = "39d049d4ae68e6f6d595fce7de1dcfc1024fb4eb"
+SRCREV_mbedtls = "5765cb7f75a9973ae9232d438e361a9d7bbc49e7"
 SRCREV_nordic = "a6e5299041f152da5ae0ab17b2e44e088bb96d6d"
-SRCREV_stm32 = "5c8275071ec1cf160bfe8c18bbd9330a7d714dc8"
 SRCREV_open-amp = "6010f0523cbc75f551d9256cf782f173177acdef"
 SRCREV_openthread = "5d706547ebcb0a85e11412bcd88e80e2af98c74d"
-SRCREV_libmetal = "39d049d4ae68e6f6d595fce7de1dcfc1024fb4eb"
+SRCREV_stm32 = "5c8275071ec1cf160bfe8c18bbd9330a7d714dc8"
 SRCREV_tinycrypt = "3e9a49d2672ec01435ffbf0d788db6d95ef28de0"
-SRCREV_mbedtls = "5765cb7f75a9973ae9232d438e361a9d7bbc49e7"
 
 ZEPHYR_BRANCH = "v2.7-branch"
 PV = "2.7.0+git${SRCPV}"
-- 
2.30.1

[meta-zephyr][PATCH v2 0/4] zephyr-lvgl: make it possible to build the zephyr lvgl sample

Bartosz Golaszewski

#55286

This series adds a recipe for the lvgl sample from zephyr. Due to how
meta-zephyr works we need to pull in some additional modules for the
build to succeed.

The first three patches are just coding style improvements, the last patch
adds the recipe.

v1 -> v2:
- rebase patches on top of current master

Bartosz Golaszewski (4):
  zephyr-kernel-src: order the SRCREV assignments alphabetically
  zephyr-kernel-src: use the preferred coding style for multi-line
    assignments
  zephyr-kernel-src: order git repos alphabetically
  zephyr-lvgl: new recipe

 ...0001-cmake-added-missing-file-ext-to.patch | 42 +++++++++++++++++++
 .../zephyr-kernel/zephyr-kernel-common.inc    |  1 +
 .../zephyr-kernel/zephyr-kernel-src-2.6.1.inc | 20 +++++----
 .../zephyr-kernel/zephyr-kernel-src-2.7.0.inc | 18 ++++----
 .../zephyr-kernel/zephyr-kernel-src.inc       |  5 ++-
 recipes-kernel/zephyr-kernel/zephyr-lvgl.bb   | 11 +++++
 6 files changed, 81 insertions(+), 16 deletions(-)
 create mode 100644 recipes-kernel/zephyr-kernel/files/0001-cmake-added-missing-file-ext-to.patch
 create mode 100644 recipes-kernel/zephyr-kernel/zephyr-lvgl.bb

-- 
2.30.1

[meta-zephyr] Issues and possible solutions

Eilís Ní Fhlannagáin

#55285

Following on from Bartosz's recent patch, Naveen suggested I take this
to the list. We've been recently discussing some of the drawbacks of
meta-zephyr between myself, Diego Sueiro and Jon Mason at ARM and
Bartosz Golaszewski and we've come up with a few ideas we want to
propose. (Diego, Jon, Bartosz, please add anything I may have missed
from my notes)

The main issues we've seen with the layer are:

1. No separation of BSP layer and functionality.
2. Limited machine support.
3. Kernel SRC_URI is incomplete.
4. Needing to maintain two sets of build information/configuration.

I'd like to propose a few solutions to this and get your thoughts and
feedback before we go further.

First, I would like to refactor the layer into a slightly different setup:

meta-zephyr
  |-meta-zephyr-bsp
  |-meta-zephyr-core
  |-meta-zephyr-west

Where:
meta-zephyr-bsp: contains MACHINE configs and base kernel recipes and
nothing more.
meta-zephyr-core: contains images (zephyr-hello-world.bb, etc),
classes, and nativesdk bits.
meta-zephyr-west: contains a west build implementation and additions
to the sdk needed for this.

There are a few reasons why I'm proposing this.

meta-zephyr-bsp:
For YP compatibility we really should be splitting bsp layers out from
core functionality.

Secondly, I've been working on a meta-zephyr-bsp layer that contains
285 machine configurations autogenerated from zephyr. You can view the
layer here https://booting.oniroproject.org/distro/meta-zephyr-bsp and
the patch to zephyr I use to generate these here
https://booting.oniroproject.org/distro/meta-zephyr-bsp/-/blob/dunfell/recipes-core/meta/files/0001-zephyr-Export-an-OpenEmbedded-machine-config.patch.
It's missing some bits, specifically around do_flash_usb, but it gets
us many more machines than what we currently have. (keep in mind, this
is dunfell and zephyr v2.6.0 atm)

I also want to split out the base kernel bits (zephyr-kernel*) into
the bsp layer and move all the "image" recipes like zephyr-blinky, etc
into meta-zephyr-core/meta-zephyr-core/recipes-core/images.

meta-zephyr-west:
We need to do a lot of MACHINE_OVERRIDES with ZEPHYR_MODULES. Short of
tracking all of this (which is a maintenance nightmare), or generating
them from KConfigs, the only way Diego and I have figured out how to
do this is to offload that onto zephyr itself.

One way we've looked at this is that we can do it via a west.bbclass
where bitbake need not know anything about the oecmake flags, it just
essentially shells out and runs west. Modifying the Kconfigs is done
via menuconfig as usual. Doing this avoids the need to do all those
overrides and track every single module in zephyr (or not in zephyr
even). As well, those MACHINE_OVERRIDES have no knowledge of what is
in the Kconfig, so this would allow us to detangle some of that.

Both Diego and I have come up with a solution for this (mine bbclass
based, Diego doing do_compile overrides directly in the recipe). My
thought would be extending the meta-zephyr layer with a
meta-zephyr-west layer inside that would allow people to use both the
CMAKE way of building zephyr or the west way, depending on their needs
but we're open for some suggestions/ideas.

-b

Re: [meta-zephyr][PATCH 0/4] zephyr-lvgl: make it possible to build the zephyr lvgl sample

Naveen Saini

#55284

Could you please rebase this series with latest !

Regards,
Naveen

Show quoted text

-----Original Message-----
From: yocto@... <yocto@...> On Behalf
Of Bartosz Golaszewski
Sent: Monday, November 8, 2021 11:44 PM
To: yocto@...
Cc: Bartosz Golaszewski <brgl@...>
Subject: [yocto] [meta-zephyr][PATCH 0/4] zephyr-lvgl: make it possible to
build the zephyr lvgl sample

This series adds a recipe for the lvgl sample from zephyr. Due to how meta-
zephyr works we need to pull in some additional modules for the build to
succeed.

The first three patches are just coding style improvements, the last patch
adds the recipe.

Bartosz Golaszewski (4):
  zephyr-kernel-src: order the SRCREV assignments alphabetically
  zephyr-kernel-src: use the preferred coding style for multi-line
    assignments
  zephyr-kernel-src: order git repos alphabetically
  zephyr-lvgl: new recipe

 ...0001-cmake-added-missing-file-ext-to.patch | 42 +++++++++++++++++++
 .../zephyr-kernel/zephyr-kernel-common.inc    |  1 +
 .../zephyr-kernel/zephyr-kernel-src-2.6.1.inc | 20 +++++----  .../zephyr-
kernel/zephyr-kernel-src-2.7.0.inc | 18 ++++----
 .../zephyr-kernel/zephyr-kernel-src.inc       |  5 ++-
 recipes-kernel/zephyr-kernel/zephyr-lvgl.bb   | 11 +++++
 6 files changed, 81 insertions(+), 16 deletions(-)  create mode 100644
recipes-kernel/zephyr-kernel/files/0001-cmake-added-missing-file-ext-
to.patch
 create mode 100644 recipes-kernel/zephyr-kernel/zephyr-lvgl.bb

--
2.30.1

M+ & H bugs with Milestone Movements WW45

Stephen Jolley

#55283

All,

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

Priority	Bug ID	Short Description	Changer	Owner	Was	Became
Medium+	12917	Warnings from nightly-multilib builds (build-deps)	kai.kang@...	kai.kang@...	3.5	3.5 M3
	13550	username/password specified to gitsm:// does not get propagated to submodules	randy.macleod@...	kiran.surendran@...	3.4 M4	3.5 M1
	14268	ruby-ri-docs is not reproducible	richard.purdie@...	thomas.perrot@...	3.4 M4	3.5 M1
	14290	golang test_go_dep_build accessing network during testing	randy.macleod@...	vinay.m.engg@...	3.4 M4	3.5 M2
	14522	qemuppc doesn't shutdown within timeout (serial console issues)	randy.macleod@...	randy.macleod@...	3.5	3.5 M1
	14603	cross-canadian.bbclass sets incorrect PKG_CONFIG_PATH	richard.purdie@...	anuj.mittal@...	3.5 M1	3.3.4

Thanks,

Stephen K. Jolley

Yocto Project Program Manager

( Cell: (208) 244-4460

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

Enhancements/Bugs closed WW45!

Stephen Jolley

#55282

All,

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

Who	Count
richard.purdie@...	5
randy.macleod@...	3
caner.altinbasak@...	1
diego.sueiro@...	1
akuster808@...	1
trevor.gamblin@...	1
Grand Total	12

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

Stephen Jolley

#55281

All,

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

Who	Count
ross@...	37
michael.opdenacker@...	35
david.reyna@...	22
randy.macleod@...	19
bruce.ashfield@...	17
trevor.gamblin@...	15
timothy.t.orling@...	14
JPEWhacker@...	12
sakib.sajal@...	11
richard.purdie@...	8
kai.kang@...	8
mhalstead@...	7
bluelightning@...	6
kiran.surendran@...	5
Qi.Chen@...	5
hongxu.jia@...	4
saul.wold@...	4
jon.mason@...	3
chee.yang.lee@...	3
pgowda.cve@...	3
anuj.mittal@...	2
alejandro@...	2
mingli.yu@...	2
pokylinux@...	2
mshah@...	2
mister_rs@...	1
vinay.m.engg@...	1
kexin.hao@...	1
Martin.Jansa@...	1
nicolas.dechesne@...	1
elberger@...	1
john.kaldas.enpj@...	1
akuster808@...	1
thomas.perrot@...	1
raj.khem@...	1
jaewon@...	1
open.source@...	1
shachar@...	1
ydirson@...	1
yoctoproject@...	1
yi.zhao@...	1
alexandre.belloni@...	1
limon.anibal@...	1
yf3yu@...	1
steve@...	1
jay.shen.teoh@...	1
aehs29@...	1
matthewzmd@...	1
mark.hatle@...	1
TicoTimo@...	1
angolini@...	1

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

#55280

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 and how to create a bugzilla account at: https://bugzilla.yoctoproject.org/createaccount.cgi

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 397 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.4”, “3.5, "3.99" and "Future", the more pressing/urgent issues being in "3.4" and then “3.5”.

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: meta-selinux: dunfell: libselinux: 0001-Fix-NULL-pointer-use-in-selinux_restorecon_set_sehandle.patch fails to apply

Maurizio Macrina <mmacrina@...>

#55279

Hi,

A possible fix for this issue during the do_patch task might be the following:

diff --git a/recipes-security/selinux/libselinux/0001-Fix-NULL-pointer-use-in-selinux_restorecon_set_sehandle.patch b/recipes-security/selinux/libselinux/0001-Fix-NULL-pointer-use-in-selinux_restorecon_set_sehandle.patch

index 8a9fb7c..66c86ee 100644

--- a/recipes-security/selinux/libselinux/0001-Fix-NULL-pointer-use-in-selinux_restorecon_set_sehandle.patch

+++ b/recipes-security/selinux/libselinux/0001-Fix-NULL-pointer-use-in-selinux_restorecon_set_sehandle.patch

@@ -17,8 +17,8 @@ Acked-by: Stephen Smalley <stephen.smalley.work@...>

diff --git a/libselinux/src/selinux_restorecon.c b/libselinux/src/selinux_restorecon.c

index d1ce830c5..6993be6fd 100644

---- a/libselinux/src/selinux_restorecon.c

-+++ b/libselinux/src/selinux_restorecon.c

+--- a/src/selinux_restorecon.c

++++ b/src/selinux_restorecon.c

@@ -1154,6 +1154,8 @@ void selinux_restorecon_set_sehandle(struct selabel_handle *hndl)

size_t num_specfiles, fc_digest_len;

Basically in the patch file: 0001-Fix-NULL-pointer-use-in-selinux_restorecon_set_sehandle.patch remove “libselinux” from a/libselinux/src/selinux_restorecon.c and b/libselinux/src/selinux_restorecon.c

I tested it and works fine.

From: Maurizio Macrina <mmacrina@...>
Date: Monday, 8 November 2021 at 14:13
To: jonas.brich@... <jonas.brich@...>, yocto@... <yocto@...>
Subject: Re: [yocto] meta-selinux: dunfell: libselinux: 0001-Fix-NULL-pointer-use-in-selinux_restorecon_set_sehandle.patch fails to apply

Hello Jonas,

I’ve also recently hit an error during the do_patch task of libselinux.

001-Fix-NULL-pointer-use-in-selinux_restorecon_set_sehandle.patch has been recently added to the dunfell branch but fails to apply:

ERROR: Applying patch '0001-Fix-NULL-pointer-use-in-selinux_restorecon_set_sehandle.patch' on target directory '/yocto/c2100-catchpoint-system-image/poky/build/tmp/work/core2-64-poky-linux/libselinux/3.0-r0/libselinux-3.0'

Command Error: 'quilt --quiltrc /yocto/c2100-catchpoint-system-image/poky/build/tmp/work/core2-64-poky-linux/libselinux/3.0-r0/recipe-sysroot-native/etc/quiltrc push' exited with 0 Output:

Applying patch 0001-Fix-NULL-pointer-use-in-selinux_restorecon_set_sehandle.patch

can't find file to patch at input line 22

Perhaps you used the wrong -p or --strip option?

The text leading up to this was:

--------------------------

|From 08f5e30177218fae7ce9f5c8d6856690126b2b30 Mon Sep 17 00:00:00 2001

|From: Ji Qin <jiqin.ji@...>

|Date: Sun, 14 Jun 2020 21:20:23 -0400

|Subject: [PATCH] libselinux: Fix NULL pointer use in

| selinux_restorecon_set_sehandle

|

|error occur when selinux_restorecon_default_handle return NULL in

|restorecon_init.

|

|fixes: https://github.com/SELinuxProject/selinux/issues/249

|

|Signed-off-by: Ji Qin <jiqin.ji@...>

|Acked-by: Stephen Smalley <stephen.smalley.work@...>

|---

| libselinux/src/selinux_restorecon.c | 2 ++

| 1 file changed, 2 insertions(+)

|

|diff --git a/libselinux/src/selinux_restorecon.c b/libselinux/src/selinux_restorecon.c

|index d1ce830c5..6993be6fd 100644

|--- a/libselinux/src/selinux_restorecon.c

|+++ b/libselinux/src/selinux_restorecon.c

--------------------------

No file to patch. Skipping patch.

1 out of 1 hunk ignored

Patch 0001-Fix-NULL-pointer-use-in-selinux_restorecon_set_sehandle.patch does not apply (enforce with -f)

DEBUG: Python function patch_do_patch finished

DEBUG: Python function do_patch finished

I’ve attached the corresponding log.

What would be the suggested fix for this?

I don’t think the leading a/b in the path is the issue here, other patch files have the same path.

Thanks.

Regards.

Maurizio Macrina

Senior Software Engineer | Catchpoint

P: +39 3472458541

E: mmacrina@catchpoint.com

www.catchpoint.com

[meta-zephyr][PATCH 4/4] zephyr-lvgl: new recipe

Bartosz Golaszewski

#55278

From: Bartosz Golaszewski <bartosz.golaszewski@...>

This adds a recipe for building the lvgl sample from mainline zephyr
source. We need to include one upstream patch that fixes a build problem
with lvgl and pull in two other modules or otherwise the default config
will fail to build. Currently only the nordic reference devkit for
nrf52840 is supported.

Big thanks to Eilís Ní Fhlannagáin <elizabeth.flanagan@...> for
helping me with that.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@...>
Signed-off-by: Eilís Ní Fhlannagáin <elizabeth.flanagan@...>
---
 ...0001-cmake-added-missing-file-ext-to.patch | 42 +++++++++++++++++++
 .../zephyr-kernel/zephyr-kernel-common.inc    |  1 +
 .../zephyr-kernel/zephyr-kernel-src-2.6.1.inc |  3 ++
 .../zephyr-kernel/zephyr-kernel-src-2.7.0.inc |  3 ++
 .../zephyr-kernel/zephyr-kernel-src.inc       |  3 ++
 recipes-kernel/zephyr-kernel/zephyr-lvgl.bb   | 11 +++++
 6 files changed, 63 insertions(+)
 create mode 100644 recipes-kernel/zephyr-kernel/files/0001-cmake-added-missing-file-ext-to.patch
 create mode 100644 recipes-kernel/zephyr-kernel/zephyr-lvgl.bb

diff --git a/recipes-kernel/zephyr-kernel/files/0001-cmake-added-missing-file-ext-to.patch b/recipes-kernel/zephyr-kernel/files/0001-cmake-added-missing-file-ext-to.patch
new file mode 100644
index 0000000..6aeca14
--- /dev/null
+++ b/recipes-kernel/zephyr-kernel/files/0001-cmake-added-missing-file-ext-to.patch
@@ -0,0 +1,42 @@
+From 783c1f78c8e39751fe89d0883c8bce7336f55e94 Mon Sep 17 00:00:00 2001
+From: Torsten Rasmussen <Torsten.Rasmussen@...>
+Date: Thu, 19 Aug 2021 08:53:00 +0200
+Subject: [PATCH] cmake: added missing file ext to
+ lv_font_dejavu_16_persian_hebrew.c
+
+CMake >= 3.20 requires file extensions explicitly added to source files.
+
+See CMP0115:
+> Starting in CMake 3.20, CMake prefers all source files to have their
+> extensions explicitly listed:
+
+In the CMakeLists.txt, the file lv_font_dejavu_16_persian_hebrew.c
+was added without its .c extension, causing never CMakes ti fail
+discovering the file.
+
+This has been fixed by correctly add the file as:
+lv_font_dejavu_16_persian_hebrew.c
+
+Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@...>
+---
+Upstream-status: Accepted
+
+ CMakeLists.txt | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/CMakeLists.txt b/CMakeLists.txt
+index 57b07c84..0f433edc 100644
+--- a/CMakeLists.txt
++++ b/CMakeLists.txt
+@@ -58,7 +58,7 @@ zephyr_library_sources(
+     src/lv_misc/lv_utils.c
+ 
+     src/lv_font/lv_font.c
+-    src/lv_font/lv_font_dejavu_16_persian_hebrew
++    src/lv_font/lv_font_dejavu_16_persian_hebrew.c
+     src/lv_font/lv_font_fmt_txt.c
+     src/lv_font/lv_font_loader.c
+     src/lv_font/lv_font_montserrat_12.c
+-- 
+Gitee
+
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
index 5ae7504..04eb72b 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
@@ -31,6 +31,7 @@ ZEPHYR_MODULES:append:arm = "\;${S}/modules/cmsis"
 ZEPHYR_MODULES:append:nordic = "\;${S}/modules/hal/nordic"
 ZEPHYR_MODULES:append:stm32 = "\;${S}/modules/hal/stm32"
 ZEPHYR_MODULES:append:openamp = "\;${S}/modules/lib/open-amp\;${S}/modules/hal/libmetal"
+ZEPHYR_MODULES:append:zsegger = "\;${S}/modules/debug/segger"
 
 EXTRA_OECMAKE:append = " -DZEPHYR_MODULES=${ZEPHYR_MODULES}"
 
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.1.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.1.inc
index 9f28df7..a7289f1 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.1.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.1.inc
@@ -2,12 +2,15 @@ SRCREV_FORMAT = "default_cmsis"
 SRCREV_cmsis = "c3bd2094f92d574377f7af2aec147ae181aa5f8e"
 SRCREV_default = "2d6322d74aaac838ead46bfcba0db619cff4b534"
 SRCREV_libmetal = "39d049d4ae68e6f6d595fce7de1dcfc1024fb4eb"
+SRCREV_lvgl = "31acbaa36e9e74ab88ac81e3d21e7f1d00a71136"
 SRCREV_mbedtls = "5765cb7f75a9973ae9232d438e361a9d7bbc49e7"
 SRCREV_nordic = "574493fe29c79140df4827ab5d4a23df79d03681"
 SRCREV_open-amp = "6010f0523cbc75f551d9256cf782f173177acdef"
 SRCREV_openthread = "385e19da1ae15f27872c2543b97276a42f102ead"
+SRCREV_segger = "3a52ab222133193802d3c3b4d21730b9b1f1d2f6"
 SRCREV_stm32 = "f8ff8d25aa0a9e65948040c7b47ec67f3fa300df"
 SRCREV_tinycrypt = "3e9a49d2672ec01435ffbf0d788db6d95ef28de0"
+SRCREV_TraceRecorderSource = "36c577727642457b0db7274298a4b96558374832"
 
 ZEPHYR_BRANCH = "v2.6-branch"
 PV = "2.6.1+git${SRCPV}"
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.7.0.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.7.0.inc
index f425d9f..1cc9a4e 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.7.0.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.7.0.inc
@@ -2,12 +2,15 @@ SRCREV_FORMAT = "default_cmsis"
 SRCREV_cmsis = "b0612c97c1401feeb4160add6462c3627fe90fc7"
 SRCREV_default = "3f826560aaf81a444018293bd6acce3c339fe150"
 SRCREV_libmetal = "39d049d4ae68e6f6d595fce7de1dcfc1024fb4eb"
+SRCREV_lvgl = "31acbaa36e9e74ab88ac81e3d21e7f1d00a71136"
 SRCREV_mbedtls = "5765cb7f75a9973ae9232d438e361a9d7bbc49e7"
 SRCREV_nordic = "a6e5299041f152da5ae0ab17b2e44e088bb96d6d"
 SRCREV_open-amp = "6010f0523cbc75f551d9256cf782f173177acdef"
 SRCREV_openthread = "5d706547ebcb0a85e11412bcd88e80e2af98c74d"
+SRCREV_segger = "3a52ab222133193802d3c3b4d21730b9b1f1d2f6"
 SRCREV_stm32 = "5c8275071ec1cf160bfe8c18bbd9330a7d714dc8"
 SRCREV_tinycrypt = "3e9a49d2672ec01435ffbf0d788db6d95ef28de0"
+SRCREV_TraceRecorderSource = "36c577727642457b0db7274298a4b96558374832"
 
 ZEPHYR_BRANCH = "v2.7-branch"
 PV = "2.7.0+git${SRCPV}"
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
index 4ef8a9a..f0445cc 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
@@ -14,10 +14,13 @@ SRC_URI = "\
     git://github.com/zephyrproject-rtos/hal_nordic.git;protocol=https;destsuffix=git/modules/hal/nordic;name=nordic \
     git://github.com/zephyrproject-rtos/hal_stm32.git;branch=main;protocol=https;destsuffix=git/modules/hal/stm32;name=stm32 \
     git://github.com/zephyrproject-rtos/libmetal.git;protocol=https;destsuffix=git/modules/hal/libmetal;name=libmetal \
+    git://github.com/zephyrproject-rtos/lvgl.git;branch=zephyr;protocol=https;destsuffix=git/modules/lib/gui/lvgl;name=lvgl \
     git://github.com/zephyrproject-rtos/mbedtls.git;protocol=https;destsuffix=git/modules/lib/mbedtls;name=mbedtls \
     git://github.com/zephyrproject-rtos/open-amp.git;protocol=https;destsuffix=git/modules/lib/open-amp;name=open-amp \
     git://github.com/zephyrproject-rtos/openthread.git;protocol=https;branch=zephyr;destsuffix=git/modules/lib/openthread;name=openthread \
+    git://github.com/zephyrproject-rtos/segger.git;protocol=https;destsuffix=git/modules/debug/segger;name=segger \
     git://github.com/zephyrproject-rtos/tinycrypt.git;protocol=https;destsuffix=git/modules/crypto/tinycrypt;name=tinycrypt \
+    git://github.com/zephyrproject-rtos/TraceRecorderSource.git;branch=zephyr;protocol=https;destsuffix=git/modules/debug/TraceRecorder;name=TraceRecorderSource \
     "
 S = "${WORKDIR}/git"
 
diff --git a/recipes-kernel/zephyr-kernel/zephyr-lvgl.bb b/recipes-kernel/zephyr-kernel/zephyr-lvgl.bb
new file mode 100644
index 0000000..29d1c5f
--- /dev/null
+++ b/recipes-kernel/zephyr-kernel/zephyr-lvgl.bb
@@ -0,0 +1,11 @@
+include zephyr-sample.inc
+
+ZEPHYR_SRC_DIR = "${S}/samples/subsys/display/lvgl"
+ZEPHYR_MODULES:append = "\;${S}/modules/lib/gui/lvgl"
+
+# TODO Once more machines and displays are supported, add a PACKAGECONFIG.
+EXTRA_OECMAKE:append =" -DSHIELD=adafruit_2_8_tft_touch_v2"
+
+SRC_URI:append = " file://0001-cmake-added-missing-file-ext-to.patch;patchdir=modules/lib/gui/lvgl"
+
+COMATIBLE_MACHINE = "(nrf52840dk-nrf52840)"
-- 
2.30.1

[meta-zephyr][PATCH 3/4] zephyr-kernel-src: order git repos alphabetically

Bartosz Golaszewski

#55277

From: Bartosz Golaszewski <bartosz.golaszewski@...>

As the number of repos pulled gets bigger it's easier to parse them
if they are ordered alphabetically.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@...>
Signed-off-by: Eilís Ní Fhlannagáin <elizabeth.flanagan@...>
---
 recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
index 3a2250d..4ef8a9a 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
@@ -13,10 +13,10 @@ SRC_URI = "\
     git://github.com/zephyrproject-rtos/cmsis.git;protocol=https;destsuffix=git/modules/cmsis;name=cmsis \
     git://github.com/zephyrproject-rtos/hal_nordic.git;protocol=https;destsuffix=git/modules/hal/nordic;name=nordic \
     git://github.com/zephyrproject-rtos/hal_stm32.git;branch=main;protocol=https;destsuffix=git/modules/hal/stm32;name=stm32 \
+    git://github.com/zephyrproject-rtos/libmetal.git;protocol=https;destsuffix=git/modules/hal/libmetal;name=libmetal \
     git://github.com/zephyrproject-rtos/mbedtls.git;protocol=https;destsuffix=git/modules/lib/mbedtls;name=mbedtls \
     git://github.com/zephyrproject-rtos/open-amp.git;protocol=https;destsuffix=git/modules/lib/open-amp;name=open-amp \
     git://github.com/zephyrproject-rtos/openthread.git;protocol=https;branch=zephyr;destsuffix=git/modules/lib/openthread;name=openthread \
-    git://github.com/zephyrproject-rtos/libmetal.git;protocol=https;destsuffix=git/modules/hal/libmetal;name=libmetal \
     git://github.com/zephyrproject-rtos/tinycrypt.git;protocol=https;destsuffix=git/modules/crypto/tinycrypt;name=tinycrypt \
     "
 S = "${WORKDIR}/git"
-- 
2.30.1

[meta-zephyr][PATCH 2/4] zephyr-kernel-src: use the preferred coding style for multi-line assignments

Bartosz Golaszewski

#55276

From: Bartosz Golaszewski <bartosz.golaszewski@...>

This type of multi-line assignments is the most prevalent in well-known
layers and is more visually pleasing.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@...>
Signed-off-by: Eilís Ní Fhlannagáin <elizabeth.flanagan@...>
---
 recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.1.inc | 9 +++++----
 recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.7.0.inc | 7 ++++---
 2 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.1.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.1.inc
index ef6ed71..9f28df7 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.1.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.1.inc
@@ -12,7 +12,8 @@ SRCREV_tinycrypt = "3e9a49d2672ec01435ffbf0d788db6d95ef28de0"
 ZEPHYR_BRANCH = "v2.6-branch"
 PV = "2.6.1+git${SRCPV}"
 
-SRC_URI:append = " file://0001-cmake-add-yocto-toolchain.patch \
-                    file://0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch \
-                    file://arduino-nano-33-ble-storage-partition.patch \
-                    "
+SRC_URI:append = " \
+    file://0001-cmake-add-yocto-toolchain.patch \
+    file://0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch \
+    file://arduino-nano-33-ble-storage-partition.patch \
+"
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.7.0.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.7.0.inc
index 9df2194..f425d9f 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.7.0.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.7.0.inc
@@ -12,6 +12,7 @@ SRCREV_tinycrypt = "3e9a49d2672ec01435ffbf0d788db6d95ef28de0"
 ZEPHYR_BRANCH = "v2.7-branch"
 PV = "2.7.0+git${SRCPV}"
 
-SRC_URI:append = " file://0001-cmake-add-yocto-toolchain.patch \
-                    file://0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch \
-                    "
+SRC_URI:append = " \
+    file://0001-cmake-add-yocto-toolchain.patch \
+    file://0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch \
+"
-- 
2.30.1

[meta-zephyr][PATCH 1/4] zephyr-kernel-src: order the SRCREV assignments alphabetically

Bartosz Golaszewski

#55275

From: Bartosz Golaszewski <bartosz.golaszewski@...>

It's easier to parse visually when those assignments are ordered.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@...>
Signed-off-by: Eilís Ní Fhlannagáin <elizabeth.flanagan@...>
---
 recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.1.inc | 8 ++++----
 recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.7.0.inc | 8 ++++----
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.1.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.1.inc
index 109242e..ef6ed71 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.1.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.1.inc
@@ -1,13 +1,13 @@
 SRCREV_FORMAT = "default_cmsis"
-SRCREV_default = "2d6322d74aaac838ead46bfcba0db619cff4b534"
 SRCREV_cmsis = "c3bd2094f92d574377f7af2aec147ae181aa5f8e"
+SRCREV_default = "2d6322d74aaac838ead46bfcba0db619cff4b534"
+SRCREV_libmetal = "39d049d4ae68e6f6d595fce7de1dcfc1024fb4eb"
+SRCREV_mbedtls = "5765cb7f75a9973ae9232d438e361a9d7bbc49e7"
 SRCREV_nordic = "574493fe29c79140df4827ab5d4a23df79d03681"
-SRCREV_stm32 = "f8ff8d25aa0a9e65948040c7b47ec67f3fa300df"
 SRCREV_open-amp = "6010f0523cbc75f551d9256cf782f173177acdef"
 SRCREV_openthread = "385e19da1ae15f27872c2543b97276a42f102ead"
-SRCREV_libmetal = "39d049d4ae68e6f6d595fce7de1dcfc1024fb4eb"
+SRCREV_stm32 = "f8ff8d25aa0a9e65948040c7b47ec67f3fa300df"
 SRCREV_tinycrypt = "3e9a49d2672ec01435ffbf0d788db6d95ef28de0"
-SRCREV_mbedtls = "5765cb7f75a9973ae9232d438e361a9d7bbc49e7"
 
 ZEPHYR_BRANCH = "v2.6-branch"
 PV = "2.6.1+git${SRCPV}"
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.7.0.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.7.0.inc
index a1619a7..9df2194 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.7.0.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.7.0.inc
@@ -1,13 +1,13 @@
 SRCREV_FORMAT = "default_cmsis"
-SRCREV_default = "3f826560aaf81a444018293bd6acce3c339fe150"
 SRCREV_cmsis = "b0612c97c1401feeb4160add6462c3627fe90fc7"
+SRCREV_default = "3f826560aaf81a444018293bd6acce3c339fe150"
+SRCREV_libmetal = "39d049d4ae68e6f6d595fce7de1dcfc1024fb4eb"
+SRCREV_mbedtls = "5765cb7f75a9973ae9232d438e361a9d7bbc49e7"
 SRCREV_nordic = "a6e5299041f152da5ae0ab17b2e44e088bb96d6d"
-SRCREV_stm32 = "5c8275071ec1cf160bfe8c18bbd9330a7d714dc8"
 SRCREV_open-amp = "6010f0523cbc75f551d9256cf782f173177acdef"
 SRCREV_openthread = "5d706547ebcb0a85e11412bcd88e80e2af98c74d"
-SRCREV_libmetal = "39d049d4ae68e6f6d595fce7de1dcfc1024fb4eb"
+SRCREV_stm32 = "5c8275071ec1cf160bfe8c18bbd9330a7d714dc8"
 SRCREV_tinycrypt = "3e9a49d2672ec01435ffbf0d788db6d95ef28de0"
-SRCREV_mbedtls = "5765cb7f75a9973ae9232d438e361a9d7bbc49e7"
 
 ZEPHYR_BRANCH = "v2.7-branch"
 PV = "2.7.0+git${SRCPV}"
-- 
2.30.1

[meta-zephyr][PATCH 0/4] zephyr-lvgl: make it possible to build the zephyr lvgl sample

Bartosz Golaszewski

#55274

This series adds a recipe for the lvgl sample from zephyr. Due to how
meta-zephyr works we need to pull in some additional modules for the
build to succeed.

The first three patches are just coding style improvements, the last patch
adds the recipe.

Bartosz Golaszewski (4):
  zephyr-kernel-src: order the SRCREV assignments alphabetically
  zephyr-kernel-src: use the preferred coding style for multi-line
    assignments
  zephyr-kernel-src: order git repos alphabetically
  zephyr-lvgl: new recipe

 ...0001-cmake-added-missing-file-ext-to.patch | 42 +++++++++++++++++++
 .../zephyr-kernel/zephyr-kernel-common.inc    |  1 +
 .../zephyr-kernel/zephyr-kernel-src-2.6.1.inc | 20 +++++----
 .../zephyr-kernel/zephyr-kernel-src-2.7.0.inc | 18 ++++----
 .../zephyr-kernel/zephyr-kernel-src.inc       |  5 ++-
 recipes-kernel/zephyr-kernel/zephyr-lvgl.bb   | 11 +++++
 6 files changed, 81 insertions(+), 16 deletions(-)
 create mode 100644 recipes-kernel/zephyr-kernel/files/0001-cmake-added-missing-file-ext-to.patch
 create mode 100644 recipes-kernel/zephyr-kernel/zephyr-lvgl.bb

-- 
2.30.1

Re: Bitbake build fails because of a python function

Maksym Iliev

#55273

Dear Alexander,

The reason for running it in /srv/yocto is because this directory uses NFS caching. I will look into the possibility of running the build in $HOME instead.

I have also ran the strace command but it produces way too much output. I will do my best to sort through it and report back.

Regards,

Maksym

Show quoted text

From: Alexander Kanavin
Sent: November 4, 2021 4:03 PM
To: Maksym Iliev
Cc: Yocto-mailing-list
Subject: Re: [yocto] Bitbake build fails because of a python function

You don't often get email from alex.kanavin@.... Learn why this is important

Just wondering, what it /srv/yocto? Can you build in your $HOME?

Otherwise, you can run bitbake under 'strace -ff -o strace-log ...' and try to check exactly what syscall causes cpio to fail.

Alex

On Thu, 4 Nov 2021 at 20:44, Maksym Iliev <maksym.iliev@...> wrote:

Dear Alexander,

Thanks a lot for responding. I've attached the log file.
The only valuable info I could find is the following piece at the end of the log file. Could that be a potential cause for failures?

Deprecated external dependency generator is used!

create archive failed: cpio: write

WARNING: exit code 1 from a shell command.

Thanks in advance,

Maksym

From: Alexander Kanavin
Sent: November 3, 2021 4:48 PM
To: Maksym Iliev
Cc: Yocto-mailing-list
Subject: Re: [yocto] Bitbake build fails because of a python function

You don't often get email from alex.kanavin@.... Learn why this is important

It's hard to say if we can't replicate the issue. Check /srv/yocto/build/tmp/work/corei7-64-poky-linux/perl/5.30.1-r0/temp/log.do_package_write_rpm, it might have useful debugging info.

Alex

On Wed, 3 Nov 2021 at 21:45, Maksym Iliev via lists.yoctoproject.org <maksym.iliev=litmus.io@...> wrote:

Hello guys. I am brand new to yocto and bitbake and I am looking for any help/advice/hints I can get. I have inherited someone else's code for building yocto project images, but the bitbake fails with the following error:

ERROR: perl-5.30.1-r0 do_package_write_rpm: Error executing a python function in exec_func_python()

autogenerated:The stack trace of python calls that resulted in this exception/failure was: File: 'exec_func_python() autogenerated', lineno: 2, function: <module>

0001: ***

0002:do_package_rpm(d)

0003:

File: '/srv/yocto/poky/meta/classes/package_rpm.bbclass', lineno: 712, function: do_package_rpm

0708:

0709:    # Build the rpm package!

0710:    d.setVar('BUILDSPEC', cmd + \"\\n\" + cleanupcmd + \"\\n\")

0711:    d.setVarFlag('BUILDSPEC', 'func', '1')

0712:    bb.build.exec_func('BUILDSPEC', d)

0713:

0714:    if d.getVar('RPM_SIGN_PACKAGES') == '1':

0715:        bb.build.exec_func(\"sign_rpm\", d)

0716:}

File: '/srv/yocto/poky/bitbake/lib/bb/build.py', lineno: 254, function: exec_func

0250:    with bb.utils.fileslocked(lockfiles):

0251:    if ispython:

0252:            exec_func_python(func, d, runfile, cwd=adir)

0253:    else: ***

0254:            exec_func_shell(func, d, runfile, cwd=adir)

0255:

0256:    try:

0257:        curcwd = os.getcwd()

0258:    except:

File: '/srv/yocto/poky/bitbake/lib/bb/build.py', lineno: 455, function: exec_func_shell

0451:    with open(fifopath, 'r+b', buffering=0) as fifo:

0452:        try:

0453:            bb.debug(2, \"Executing shell function %s\" % func)

0454:            with open(os.devnull, 'r+') as stdin, logfile: ***

0455:                bb.process.run(cmd, shell=False, stdin=stdin, log=logfile, extrafiles=[(fifo,readfifo)])

0456:        finally:

0457:            os.unlink(fifopath)

0458:

0459:    bb.debug(2, \"Shell function %s finished\" % func)

File: '/srv/yocto/poky/bitbake/lib/bb/process.py', lineno: 184, function: run

0180:

0181:    if pipe.returncode != 0:

0182:        if log:

0183:            # Don't duplicate the output in the exception if logging it ***

0184:            raise ExecutionError(cmd, pipe.returncode, None, None)

0185:        raise ExecutionError(cmd, pipe.returncode, stdout, stderr)

0186:    return stdout, stderr Exception: bb.process.ExecutionError: Execution of '/srv/yocto/build/tmp/work/corei7-64-poky-linux/perl/5.30.1-r0/temp/run.BUILDSPEC.35372' failed with exit code 1

Would anyone be able to point me in the right direction as to what could be potentially causing this issue?

Thanks in advance,
Maksym

Re: SRC_URI Directory Change

Richard Purdie

#55272

On Sun, 2021-10-17 at 14:59 -0700, Chuck Wolber wrote:


On Fri, Oct 15, 2021 at 6:58 AM Richard Purdie
<richard.purdie@...> wrote:

I have a bit of a horrible idea to do this in master-next which does solve
the
problem. We probably need a new bitbake selftest testcase before I could
think
about merging it though.

I tested the patch you posted on IRC against bitbake 1.50.0. It seems to work
quite well, but I think I found two minor bugs in it. I pasted an updated
patch below.

In a nutshell...

If you have a SRC_URI file:// entry that ends in a "/", then you get a "."
that is
not enclosed in "/./" when running the checksum_dir method, which causes
checksum_file to throw warnings that look like this:

WARNING: Unable to get checksum for gettext-minimal-native SRC_URI entry
.intlmacosx.m4: [Errno 2] No such file or directory: '/mnt/openembedded-
core/meta/recipes-core/gettext/gettext-minimal-0.21/aclocal/.intlmacosx.m4'

I think the simplest fix is to add a "pth = pth.rstrip("/")" in the
checksum_dir method after
the guard statement. But then that exposes a different issue in the patch.

For recipes that trigger the above warning, the rstrip() fix fixes the
warning, but then you
expose a new problem in siggen.py calc_taskhash().

In your patched version, the check for the "/" fails to include the filename
in the hash calculation
for files at the root of a SRC_URI entry (there is no "/" to be found). This
results in a task hash
mismatch error on the first build, but not on subsequent builds for fairly
obvious reasons.

I solved this by adding a third field to the tuple with a True/False value,
which is a much more reliable semaphore (IMHO).

I tested these fixes and it worked perfectly. Here is an updated version of
your patch that takes into
 account the fixes I described. I can produce a "patch against your patch" if
these fixes are
considered correct and do not cause even bigger problems that are not obvious
to me.


..Ch:W..

P.S. The gettext-minimal-native_0.21.bb (from OEC) is a very good example of
something that triggers this behavior. But I found plenty of others as well.
Thanks, I got around to looking at this again. For the first issue I agree the
rstrip is the best option. For the second, I don't really want to change the on
disk signature formats since that will break the tools and have compatibility
issues. I've therefore tweaked the patch slightly differently in the v2 I've
sent out.

Hopefully this one gives us a version that can be merged.

Cheers,

Richard

Re: building the kernel's usbipd daemon

Nicolas Jeker

#55271

On Fri, 2021-11-05 at 15:02 -0700, chuck kamas via
lists.yoctoproject.org wrote:
Well it turns out that following the Perf recipe was not only a good 
idea, but absolutely necessary. The perf recipe copies the code out of 
the work-shared kernel directory into the perf build directory. This 
avoids the error when bitbake thinks that the kernel code is not needed
anymore and removes it.


Please see my version of the USBIP recipe below.


Question, how does one get this into the recipe database?
I'm not sure where this belongs, but maybe you can try to submit it to
the meta-oe repository. Look at the readme[1] for instructions.

[1]: https://git.openembedded.org/meta-openembedded/tree/meta-oe/README


Again thanks for the help!

Chuck

SUMMARY = "USBip part of Linux kernel built in tools"
DESCRIPTION = " USB/IP protocol allows to pass USB device from server
to \
client over the network. Server is a machine which provides (shares)
a \
USB device. Client is a machine which uses USB device provided by
server \
over the network. The USB device may be either physical device
connected \
to a server or software entity created on a server using USB gadget
subsystem."

LICENSE = "GPLv2"
LIC_FILES_CHKSUM = 
"file://${COMMON_LICENSE_DIR}/GPL-
2.0;md5=801f80980d171dd6425610833a22dbe6"
DEPENDS = "virtual/kernel libtool udev"
PROVIDES = "virtual/usbip-tools"

inherit linux-kernel-base kernel-arch kernelsrc manpages


do_populate_lic[depends] += "virtual/kernel:do_patch"
do_configure[depends] += "virtual/kernel:do_shared_workdir"

EXTRA_OEMAKE = "\
    -C ${S}/tools/usb/usbip \
    O=${B} \
    CROSS_COMPILE=${TARGET_PREFIX} \
    CROSS=${TARGET_PREFIX} \
    CC="${CC}" \
    CCLD="${CC}" \
    LD="${LD}" \
    AR="${AR}" \
    ARCH="${ARCH}" \
    TMPDIR="${B}" \
"

EXTRA_OEMAKE += "\
    'DESTDIR=${D}' \
    KERNEL_SRC=${STAGING_KERNEL_DIR} \
"

do_configure[depends] += "virtual/kernel:do_shared_workdir"

inherit autotools gettext

# stolen from autotools.bbclass

CONFIGUREOPTS = " --build=${BUILD_SYS} \
          --host=${HOST_SYS} \
          --target=${TARGET_SYS} \
          --prefix=${prefix} \
          --exec_prefix=${exec_prefix} \
          --bindir=${bindir} \
          --sbindir=${sbindir} \
          --libexecdir=${libexecdir} \
          --datadir=${datadir} \
          --sysconfdir=${sysconfdir} \
          --sharedstatedir=${sharedstatedir} \
          --localstatedir=${localstatedir} \
          --libdir=${libdir} \
          --includedir=${includedir} \
          --oldincludedir=${oldincludedir} \
          --infodir=${infodir} \
          --mandir=${mandir} \
          --disable-silent-rules \
          ${CONFIGUREOPT_DEPTRACK} \
          ${@append_libtool_sysroot(d)} \
"

do_configure_prepend () {
    cd ${S}/tools/usb/usbip
    ./cleanup.sh
    ./autogen.sh
    ./configure ${CONFIGUREOPTS} ${EXTRA_OECONF}
}

do_compile() {
    oe_runmake
}

do_install() {
    oe_runmake DESTDIR=${D} install
}

PACKAGE_ARCH = "${MACHINE_ARCH}"

python do_package_prepend() {
    d.setVar('PKGV', d.getVar("KERNEL_VERSION", True).split("-")[0])
}

B = "${WORKDIR}/${BPN}-${PV}"

Cross-compile custom ROS2 package for Yocto #bitbake

bojankoce

#55270

Dear Sirs,

I have a hard time to cross-compile and to properly include the custom ROS2 foxy package into the Yocto image. I properly added meta-ros layer and ROS2 foxy distro to our Yocto build by following instructions from here (Sanity Tests pass successfully).

I wanted to use a devtool and build a simple custom ROS2 package containing publisher and subscriber nodes. The source code of the package is on the git - link.

I used tips and tricks from here to create ROS2 recipes with the devtool. My custom bitbake recipe for the simple ROS2 package looks like this (my-first-yocto-pkg_git.bb file):

DESCRIPTION = "Example of minimal publisher/subscriber using rclcpp."
LICENSE = "Apache-2.0"
LIC_FILES_CHKSUM = "file://package.xml;beginline=8;endline=8;md5=3a75fd635766e2f76c3d90ee6495f310"

SRC_URI = "git://github.com/bojankoce/ros2pkg;protocol=https"

# Modify these as desired
PV = "0.1.0"
SRCREV = "1312445de2e6861d9561c0f89f4827b94c2ff6b1"

DEPENDS = "rclcpp std-msgs"

S = "${WORKDIR}/git"

# NOTE: unable to map the following CMake package dependencies: rclcpp ament_lint_auto std_msgs ros_ament_cmake
inherit ros_ament_cmake

However, when I tried to build the package with the devtool build my-first-yocto-pkg command, I get the following error:

CMake Error at CMakeLists.txt:19 (find_package):
  By not providing "Findament_cmake.cmake" in CMAKE_MODULE_PATH this project
  has asked CMake to find a package configuration file provided by
  "ament_cmake", but CMake did not find one.

  Could not find a package configuration file provided by "ament_cmake" with
  any of the following names:

    ament_cmakeConfig.cmake
    ament_cmake-config.cmake

  Add the installation prefix of "ament_cmake" to CMAKE_PREFIX_PATH or set
  "ament_cmake_DIR" to a directory containing one of the above files.  If
  "ament_cmake" provides a separate development package or SDK, be sure it
  has been installed.

The issue is around ament_cmake. I included the inherit ros_ament_cmake line into the recipe but this does not help. Do you have any idea about what I am missing here? Is there any better way to cross-compile and include a custom ROS2 foxy package into the Yocto image?

Thanks in advance for your time and efforts.

Cheers,
Bojan.

Re: meta-selinux: dunfell: libselinux: 0001-Fix-NULL-pointer-use-in-selinux_restorecon_set_sehandle.patch fails to apply

mmacrina@...

#55269

Hello Jonas,

I’ve also recently hit an error during the do_patch task of libselinux.

001-Fix-NULL-pointer-use-in-selinux_restorecon_set_sehandle.patch has been recently added to the dunfell branch but fails to apply:

ERROR: Applying patch '0001-Fix-NULL-pointer-use-in-selinux_restorecon_set_sehandle.patch' on target directory '/yocto/c2100-catchpoint-system-image/poky/build/tmp/work/core2-64-poky-linux/libselinux/3.0-r0/libselinux-3.0'

Command Error: 'quilt --quiltrc /yocto/c2100-catchpoint-system-image/poky/build/tmp/work/core2-64-poky-linux/libselinux/3.0-r0/recipe-sysroot-native/etc/quiltrc push' exited with 0 Output:

Applying patch 0001-Fix-NULL-pointer-use-in-selinux_restorecon_set_sehandle.patch

can't find file to patch at input line 22

Perhaps you used the wrong -p or --strip option?

The text leading up to this was:

--------------------------

|From 08f5e30177218fae7ce9f5c8d6856690126b2b30 Mon Sep 17 00:00:00 2001

|From: Ji Qin <jiqin.ji@...>

|Date: Sun, 14 Jun 2020 21:20:23 -0400

|Subject: [PATCH] libselinux: Fix NULL pointer use in

| selinux_restorecon_set_sehandle

|

|error occur when selinux_restorecon_default_handle return NULL in

|restorecon_init.

|

|fixes: https://github.com/SELinuxProject/selinux/issues/249

|

|Signed-off-by: Ji Qin <jiqin.ji@...>

|Acked-by: Stephen Smalley <stephen.smalley.work@...>

|---

| libselinux/src/selinux_restorecon.c | 2 ++

| 1 file changed, 2 insertions(+)

|

|diff --git a/libselinux/src/selinux_restorecon.c b/libselinux/src/selinux_restorecon.c

|index d1ce830c5..6993be6fd 100644

|--- a/libselinux/src/selinux_restorecon.c

|+++ b/libselinux/src/selinux_restorecon.c

--------------------------

No file to patch. Skipping patch.

1 out of 1 hunk ignored

Patch 0001-Fix-NULL-pointer-use-in-selinux_restorecon_set_sehandle.patch does not apply (enforce with -f)

DEBUG: Python function patch_do_patch finished

DEBUG: Python function do_patch finished

I’ve attached the corresponding log.

What would be the suggested fix for this?

I don’t think the leading a/b in the path is the issue here, other patch files have the same path.

Thanks.

Regards.

Maurizio Macrina

Senior Software Engineer | Catchpoint

P: +39 3472458541

E: mmacrina@catchpoint.com

www.catchpoint.com

log.tgz

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

Teoh, Jay Shen

#55268

Hi all,

Intel and WR YP QA is planning for QA execution for YP build yocto-3.3.4.rc1. We are planning to execute following tests for this cycle:

OEQA-manual tests for following module:
1. OE-Core
2. BSP-hw

Runtime auto test for following platforms:
1. MinnowTurbot 32-bit
2. Coffee Lake
3. NUC 7
4. NUC 6
5. Edgerouter
6. Beaglebone

ETA for completion this Thursday, Nov 11.

Thanks,
Jay

Show quoted text

-----Original Message-----
From: yocto@... <yocto@...> On Behalf
Of Richard Purdie
Sent: Friday, 5 November, 2021 6:58 PM
To: <yocto@...> <yocto@...>
Cc: qa-build-notification <qa-build-notification@...>
Subject: [yocto] QA notification for completed autobuilder build (yocto-
3.3.4.rc1)

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


    https://autobuilder.yocto.io/pub/releases/yocto-3.3.4.rc1


Build hash information:

bitbake: 0fe1a9e2d2e33f80d807cefc7a23df4a5f760c74
meta-agl: d997986f27e239400cf01e0cdef942cee278ea66
meta-arm: 71686ac05c34e53950268bfe0d52c3624e78c190
meta-aws: cad1c714434fe0adc566006e1e1626b4657bcf40
meta-gplv2: 9e119f333cc8f53bd3cf64326f826dbc6ce3db0f
meta-intel: 76495b60dd915846d2f84d03b9c9cfbb548e9dc0
meta-mingw: 422b96cb2b6116442be1f40dfb5bd77447d1219e
meta-openembedded: d378e4293d18e374f5d1494a88bfc3caee4d02df
oecore: 0ca080a23c2770a15138f702d4c879bbd90ca360
poky: c40ac16d79026169639f47be76a3f7b9d8b5178e



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