Date   

[meta-zephyr][PATCH] zephyr-kernel-test: remove unnecessary "+="

Jon Mason
 

bitbake is now warning when "+=" is used with "remove", as it is not a
recommended combination. Change the commented out versions that have
this combination to prevent anyone from using it.

Signed-off-by: Jon Mason <jon.mason@...>
---
recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc
index c7ccf9e05742..77f45a737407 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc
@@ -14,16 +14,16 @@ ZEPHYRTESTS:remove:qemu-x86 = "common device interrupt poll queue sleep"
ZEPHYRTESTS:remove:stm32mp157c-dk2 = "common device poll queue sleep"

# test_context will fail because QEMU for ARM does not emulate CortexM3 BASEPRI register
-#ZEPHYRTESTS:remove:arm += ""
+#ZEPHYRTESTS:remove:arm = ""

# test_critical never finishes in an unpatched QEMU either
-#ZEPHYRTESTS:remove:arm += ""
+#ZEPHYRTESTS:remove:arm = ""

#Remove ARM specific tests
-#ZEPHYRTESTS:remove:x86 += ""
+#ZEPHYRTESTS:remove:x86 = ""

#Remove tests not intended for Nios2
-#ZEPHYRTESTS:remove:nios2 += ""
+#ZEPHYRTESTS:remove:nios2 = ""

# List of all available kernel tests
ZEPHYRTESTS = " \
--
2.20.1


Re: User configuration & host contamination

Manuel Wagesreither
 

Hi Jeffrey,

Am Do, 4. Nov 2021, um 11:00, schrieb Jeffrey Simons:
Hi all,

I'm having some difficulty with setting up users and the respective
application user assignments. I have a generic recipe which inherits
useradd and sets a user, this
works great for my purpose without one exception. I can't assign the
user in my other recipe where the application is build.

Snippet from my user add (based on the useradd-example):
USERADD_PARAM_${PN} = "--uid 1200 \
--home-dir /home/user1 \
--groups dialout \
--user-group \
--password '********' \
--shell /bin/bash user1"

Snippet from my application which wants to assign the user1:
do_install () {
chown -R user1 ${D}/usr/local/bin/test_app/
}
It fails with the message:
"WARNING: test_app-1.0-12-r0 do_package_qa: QA Issue: test_app:
/usr/local/bin/test_app/some_script.py is owned by uid 1000, which is
the same as the user running bitbake. This may be due to host
contamination"

Any pointers/thoughts in how I can resolve this issue?
Does the recipe which builds the application DEPEND on the recipe which sets up the user? This is what I would try. If I understand things correctly, Yocto/Bitbake provides every recipe a pristine environment unnaffected from other recipes going into the same image. For example, if you want to link your application against some libraries provided by other recipes, you need to add them to DEPENDS. That populates your build environment with that other recipes output. I'm not sure this applies to user accounts as well, but I guess it's worth a try.

Please note I probably used the termins "recipe" and "package" incorrectly.

Hope this helps,
Manuel


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

Teoh, Jay Shen
 

Hi all,

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

======= Summary ========
No high milestone defects.

new issue found

Bug 14622 - bsps-hw.bsps-hw.Test_Seek_bar_and_volume_control manual test case failure

======= Bugs ========
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14622

Thanks,
Jay

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


Re: Unable to parse /home/PATH/meta-swupdate/recipes-support/swupdate/swupdate_git.bb #swupdate

Quentin Schulz
 

Hi Vishal,

On November 11, 2021 5:42:44 AM GMT+01:00, vishal.rana118@... wrote:
Hi Team,

I am new with Yocto and SWupdate framework. I am trying to integrate SWupdate framework in our existing yocto code.
I am using *SUMO version*. while trying to build kernel image I am getting below error.
*MACHINE=imx6s-comg-mtech DISTRO=fsl-imx-fb EULA=1 source setup-environment build-mtech*
*bitbake linux-comg-mtech-4.14.78.local*

////////////////////////////////////////////////////////Error log/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
ERROR: Unable to parse /home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/meta-swupdate/recipes-support/swupdate/swupdate_git.bb
Traceback (most recent call last):
File "/home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/poky/bitbake/lib/bb/parse/__init__.py", line 117, in handle(fn='/home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/meta-swupdate/recipes-support/swupdate/swupdate_git.bb', data=<bb.data_smart.DataSmart object at 0x7f2675a782b0>, include=0):
with data.inchistory.include(fn):
                return h['handle'](fn, data, include)
raise ParseError("not a BitBake file", fn)
File "/home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/poky/bitbake/lib/bb/parse/parse_py/BBHandler.py", line 154, in handle(fn='/home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/meta-swupdate/recipes-support/swupdate/swupdate_git.bb', d=<bb.data_smart.DataSmart object at 0x7f2675a782b0>, include=0):
if ext != ".bbclass" and include == 0:
        return ast.multi_finalize(fn, d)
File "/home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/poky/bitbake/lib/bb/parse/ast.py", line 391, in multi_finalize(fn='/home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/meta-swupdate/recipes-support/swupdate/swupdate_git.bb', d=<bb.data_smart.DataSmart object at 0x7f2675a782b0>):
logger.debug(1, "Appending .bbappend file %s to %s", append, fn)
        bb.parse.BBHandler.handle(append, d, True)
File "/home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/poky/bitbake/lib/bb/parse/parse_py/BBHandler.py", line 132, in handle(fn='/home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/meta-mylayer/recipes-support/swupdate/swupdate_%d', d=<bb.data_smart.DataSmart object at 0x7f2675a782b0>, include=True):

    abs_fn = resolve_file(fn, d)
File "/home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/poky/bitbake/lib/bb/parse/__init__.py", line 141, in resolve_file(fn='/home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/meta-mylayer/recipes-support/swupdate/swupdate_%d', d=<bb.data_smart.DataSmart object at 0x7f2675a782b0>):
if not os.path.isfile(fn):
        raise IOError(errno.ENOENT, "file %s not found" % fn)
FileNotFoundError: [Errno 2] file /home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/meta-mylayer/recipes-support/swupdate/swupdate_%d not found
What's the exact filename of files in the home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/meta-mylayer/recipes-support/swupdate/ directory?

I suspect that you have a swupdate_%d.bbappend which isn't valid in bitbake. It should be swupdate_%.bbappend.

Cheers
Quentin

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

Not able to understand the root cause of this because without adding "meta-swupdate" layer I am able to build the code.
Please help me to resolve this issue.

Regards,
Vishal Rana


[meta-rockchip] dunfell: u-boot build issue when added patch to u-boot

Marek Belisko
 

Hello,

I'm trying to integrate mender for tinker-board-s using meta-rockchip
dunfell branch. When added meta-mender which add few patches to
u-boot I'm seeing u-boot compilation issues like:

Error: SPL image is too large (size 0x11000 than 0x8000)
| Error: Bad parameters for image type

Error is clear to me but patches which mender adds are related mostly
to the environment so I'm not sure how SPL can increase size. Any
ideas on how to resolve this issue?

Thanks and regards,

marek


--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com


Unable to parse /home/PATH/meta-swupdate/recipes-support/swupdate/swupdate_git.bb #swupdate

vishal.rana118@...
 

Hi Team,

I am new with Yocto and SWupdate framework. I am trying to integrate SWupdate framework in our existing yocto code.
I am using SUMO version. while trying to build kernel image I am getting below error.
MACHINE=imx6s-comg-mtech DISTRO=fsl-imx-fb EULA=1 source setup-environment build-mtech
bitbake linux-comg-mtech-4.14.78.local

////////////////////////////////////////////////////////Error log/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
ERROR: Unable to parse /home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/meta-swupdate/recipes-support/swupdate/swupdate_git.bb
Traceback (most recent call last):
  File "/home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/poky/bitbake/lib/bb/parse/__init__.py", line 117, in handle(fn='/home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/meta-swupdate/recipes-support/swupdate/swupdate_git.bb', data=<bb.data_smart.DataSmart object at 0x7f2675a782b0>, include=0):
                 with data.inchistory.include(fn):
    >                return h['handle'](fn, data, include)
         raise ParseError("not a BitBake file", fn)
  File "/home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/poky/bitbake/lib/bb/parse/parse_py/BBHandler.py", line 154, in handle(fn='/home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/meta-swupdate/recipes-support/swupdate/swupdate_git.bb', d=<bb.data_smart.DataSmart object at 0x7f2675a782b0>, include=0):
         if ext != ".bbclass" and include == 0:
    >        return ast.multi_finalize(fn, d)
     
  File "/home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/poky/bitbake/lib/bb/parse/ast.py", line 391, in multi_finalize(fn='/home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/meta-swupdate/recipes-support/swupdate/swupdate_git.bb', d=<bb.data_smart.DataSmart object at 0x7f2675a782b0>):
             logger.debug(1, "Appending .bbappend file %s to %s", append, fn)
    >        bb.parse.BBHandler.handle(append, d, True)
     
  File "/home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/poky/bitbake/lib/bb/parse/parse_py/BBHandler.py", line 132, in handle(fn='/home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/meta-mylayer/recipes-support/swupdate/swupdate_%d', d=<bb.data_smart.DataSmart object at 0x7f2675a782b0>, include=True):
     
    >    abs_fn = resolve_file(fn, d)
     
  File "/home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/poky/bitbake/lib/bb/parse/__init__.py", line 141, in resolve_file(fn='/home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/meta-mylayer/recipes-support/swupdate/swupdate_%d', d=<bb.data_smart.DataSmart object at 0x7f2675a782b0>):
         if not os.path.isfile(fn):
    >        raise IOError(errno.ENOENT, "file %s not found" % fn)
     
FileNotFoundError: [Errno 2] file /home/Mtech/Graphics_Gx_Mtech/Graphics_GX_Mtech/BSP/yocto/sources/meta-mylayer/recipes-support/swupdate/swupdate_%d not found
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

Not able to understand the root cause of this because without adding "meta-swupdate" layer I am able to build the code.
Please help me to resolve this issue.





Regards,
Vishal Rana


Re: __DATE__ and __TIME__ in dunfell builds #dunfell

Peter Bergin
 

On 2021-11-10 21:44, chiefsleepyeye@... wrote:
I have a weird thing going on with __DATE__ and __TIME__ when building my app in the yocto environment.  I'm building for "genericx86-64" and I'm using __DATE__ and __TIME__ in my source to show what the build date/time of my app is at run time.  But... __DATE__ is always "Apr  5 2011" and __TIME__ is always "23:00:00".  And, yes, the current time on the build machine is not that.  Anyone else experience this and/or know how to fix it?  Oh, host is Ubuntu 20.04.3 LTS.

In your build you have reproducible build enabled. https://docs.yoctoproject.org/3.4/test-manual/reproducible-builds.html. You should be able to disable this function with help of the variable BUILD_REPRODUCIBLE_BINARIES. Reproducible builds are now enableb by default in Yocto.

/Peter


__DATE__ and __TIME__ in dunfell builds #dunfell

Mike
 

I have a weird thing going on with __DATE__ and __TIME__ when building my app in the yocto environment.  I'm building for "genericx86-64" and I'm using __DATE__ and __TIME__ in my source to show what the build date/time of my app is at run time.  But... __DATE__ is always "Apr  5 2011" and __TIME__ is always "23:00:00".  And, yes, the current time on the build machine is not that.  Anyone else experience this and/or know how to fix it?  Oh, host is Ubuntu 20.04.3 LTS.

Mike


Re: Cross-compile custom ROS2 package for Yocto #bitbake

bojankoce
 

In addition to the above changes, I also included instructions inside conf/local.conf file to install my first ROS2 package:
IMAGE_INSTALL_append=" ros-core my-first-yocto-pkg"

After that, I was able to bitbake the complete Yocto image, put it on the SD card, and boot the Yocto on my devkit. After sourcing ros2_setup.sh script, I entered:

ros2 pkg list
command to list all available ROS2 packages on the system.

my_first_yocto_pkg package was on the list so I was happy and excited!

I wanted to do the final touch and launch the talker node from the packet with:

ros2 run my_first_yocto_pkg talker

However, I got the info that No executable is found! What the heck!

Do you have any idea what I did wrong in the whole process?

Appreciate your efforts!

Sincerely,
Bojan.


Re: Cross-compile custom ROS2 package for Yocto #bitbake

bojankoce
 

Hello, Matthias.

I added `amente-cmake-native` inti DEPENDS and, indeed, I got a different error this time:
Initialising tasks: 100% |######################################################################################################| Time: 0:00:02
Sstate summary: Wanted 0 Local 0 Network 0 Missed 0 Current 578 (0% match, 100% complete)
NOTE: Executing Tasks
NOTE: my-first-yocto-pkg: compiling from external source tree /home/bojan/var-fslc-yocto-playground/build_xwayland/workspace/sources/my-first-yocto-pkg
ERROR: my-first-yocto-pkg-0.1.0-r0 do_package: QA Issue: my-first-yocto-pkg: Files/directories were installed but not shipped in any package:
  /usr/share/my_first_yocto_pkg
  /usr/share/my_first_yocto_pkg/local_setup.zsh
  /usr/share/my_first_yocto_pkg/local_setup.bash
  /usr/share/my_first_yocto_pkg/package.xml
  /usr/share/my_first_yocto_pkg/local_setup.sh
  /usr/share/my_first_yocto_pkg/package.dsv
  /usr/share/my_first_yocto_pkg/local_setup.dsv
  /usr/share/my_first_yocto_pkg/environment
  /usr/share/my_first_yocto_pkg/cmake
  /usr/share/my_first_yocto_pkg/environment/path.sh
  /usr/share/my_first_yocto_pkg/environment/path.dsv
  /usr/share/my_first_yocto_pkg/environment/ament_prefix_path.dsv
  /usr/share/my_first_yocto_pkg/environment/ament_prefix_path.sh
  /usr/share/my_first_yocto_pkg/cmake/my_first_yocto_pkgConfig.cmake
  /usr/share/my_first_yocto_pkg/cmake/my_first_yocto_pkgConfig-version.cmake
  /usr/lib/my_first_yocto_pkg/talker
  /usr/lib/my_first_yocto_pkg/listener
Please set FILES such that these items are packaged. Alternatively if they are unneeded, avoid installing them or delete them within do_install.
my-first-yocto-pkg: 17 installed and not shipped files. [installed-vs-shipped]
ERROR: my-first-yocto-pkg-0.1.0-r0 do_package: Fatal QA errors found, failing task.
ERROR: Logfile of failure stored in: /home/bojan/var-fslc-yocto-playground/build_xwayland/tmp/work/cortexa53-crypto-fslc-linux/my-first-yocto-pkg/0.1.0-r0/temp/log.do_package.15149
ERROR: Task (/home/bojan/var-fslc-yocto-playground/build_xwayland/workspace/recipes/my-first-yocto-pkg/my-first-yocto-pkg_git.bb:do_package) failed with exit code '1'
NOTE: Tasks Summary: Attempted 2200 tasks of which 2192 didn't need to be rerun and 1 failed.
NOTE: Writing buildhistory
NOTE: Writing buildhistory took: 3 seconds

Summary: 1 task failed:
  /home/bojan/var-fslc-yocto-playground/build_xwayland/workspace/recipes/my-first-yocto-pkg/my-first-yocto-pkg_git.bb:do_package
Summary: There was 1 WARNING message shown.
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
I needed to append the following lines at the end of my-first-yocto-pkg_git.bb file in order to resolve it:
FILES_${PN} += "/usr/share/my_first_yocto_pkg/*"
FILES_${PN} += "/usr/lib/my_first_yocto_pkg/*"
FILES_${PN}-dev = "/usr/share/my_first_yocto_pkg/* /usr/lib/my_first_yocto_pkg/* ${includedir}"


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

Naveen Saini
 

-----Original Message-----
From: yocto@... <yocto@...> On Behalf
Of Bartosz Golaszewski
Sent: Tuesday, November 9, 2021 10:43 PM
To: yocto@...
Cc: Bartosz Golaszewski <bartosz.golaszewski@...>; Eilís Ní
Fhlannagáin <elizabeth.flanagan@...>
Subject: [yocto] [meta-zephyr][PATCH v2 4/4] zephyr-lvgl: new recipe

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-e
+++ xt-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"
[Naveen] zsegger is not defined as override, it causing build failure. If module is required only for lvgl sample, it can move into sample recipe !
| build/tmp-newlib/work/armv7m-yocto-eabi/zephyr-lvgl/2.7.0+gitAUTOINC+3f826560aa_b0612c97c1-r0/git/subsys/logging/log_backend_rtt.c:12:10: fatal error: SEGGER_RTT.h: No such file or directory
| 12 | #include <SEGGER_RTT.h>
| | ^~~~~~~~~~~~~~
| compilation terminated.

It can be checked with $ bitbake zephyr-lvgl -e | grep ^ZEPHYR_MODULES=



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 d8b086b..21ba208 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;nobranch=1;destsuffix=git/modules/hal/n
ordic;name=nordic \
git://github.com/zephyrproject-
rtos/hal_stm32.git;protocol=https;branch=main;destsuffix=git/modules/hal/
stm32;name=stm32 \
git://github.com/zephyrproject-
rtos/libmetal.git;protocol=https;nobranch=1;destsuffix=git/modules/hal/lib
metal;name=libmetal \
+
+ git://github.com/zephyrproject-rtos/lvgl.git;branch=zephyr;protocol=ht
+ tps;destsuffix=git/modules/lib/gui/lvgl;name=lvgl \
git://github.com/zephyrproject-
rtos/mbedtls.git;protocol=https;nobranch=1;destsuffix=git/modules/lib/mbe
dtls;name=mbedtls \
git://github.com/zephyrproject-rtos/open-
amp.git;protocol=https;nobranch=1;destsuffix=git/modules/lib/open-
amp;name=open-amp \
git://github.com/zephyrproject-
rtos/openthread.git;protocol=https;nobranch=1;branch=zephyr;destsuffix=gi
t/modules/lib/openthread;name=openthread \
+
+ git://github.com/zephyrproject-rtos/segger.git;protocol=https;nobranch
+ =1;destsuffix=git/modules/debug/segger;name=segger \
git://github.com/zephyrproject-
rtos/tinycrypt.git;protocol=https;nobranch=1;destsuffix=git/modules/crypto/
tinycrypt;name=tinycrypt \
+
+ git://github.com/zephyrproject-rtos/TraceRecorderSource.git;branch=zep
+
hyr;protocol=https;destsuffix=git/modules/debug/TraceRecorder;name=Tra
+ ceRecorderSource \
"
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


Re: Cross-compile custom ROS2 package for Yocto #bitbake

Matthias Schoepfer
 

Hi Bojan,

On 11/8/21 3:39 PM, bojankoce wrote:

Dear Sirs,

I guess this is not the right address. Just saying.

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?

You are missing a DEPENDS, ros_ament_cmake does not add it. Try adding ament-cmake-native to your DEPENDS and see if that works (or give you a different error message, since I guess you might be missing out more stuff).


Regards,

   Matthias


Re: pre-built native only tool for native and nativesdk

Joel Winarske
 

My solution was to use recipe name without `-native`, and simply use empty packages (no-op) for target.  Only nativesdk- and -native variants have an affect.  Then add `TOOLCHAIN_HOST_TASK:append = " nativesdk-flutter-sdk"` to local.conf.


On Tue, Nov 9, 2021 at 3:32 PM Joel Winarske <joel.winarske@...> wrote:
Actually by removing `inherit native` and adding -native to the recipe name doesn't make it build for native.

On Tue, Nov 9, 2021 at 3:23 PM Joel Winarske <joel.winarske@...> wrote:
To eliminate target option from the recipe I just need to make sure the name of the recipe ends with -native, then removing inherit native works fine.

On Tue, Nov 9, 2021 at 2:09 PM Joel Winarske via lists.yoctoproject.org <joel.winarske=gmail.com@...> wrote:
I'm trying to sort out how to install a pre-built host-only tool for native and nativesdk only.

Using `inherit native` my-recipe-native and nativesdk-my-recipe both build fine, only -c populate_sdk generates "rdepends upon non-existent task do_package_write_rpm".  Looking at native.bbclass it includes `inherit nopackage` which explains the error.

If I remove the `inherit native` and update my recipe name to not include `-native` I can build the -native version, only I can't build nativesdk-*-native.  A target build is invalid.

What is the recommended pattern to do this, and is there an example of this anywhere?


Thanks,
Joel




User configuration & host contamination

Jeffrey Simons
 

Hi all,

I'm having some difficulty with setting up users and the respective application user assignments. I have a generic recipe which inherits useradd and sets a user, this
works great for my purpose without one exception. I can't assign the user in my other recipe where the application is build.

Snippet from my user add (based on the useradd-example):
USERADD_PARAM_${PN} = "--uid 1200 \
--home-dir /home/user1 \
--groups dialout \
--user-group \
--password '********' \
--shell /bin/bash user1"

Snippet from my application which wants to assign the user1:
do_install () {
chown -R user1 ${D}/usr/local/bin/test_app/
}
It fails with the message:
"WARNING: test_app-1.0-12-r0 do_package_qa: QA Issue: test_app: /usr/local/bin/test_app/some_script.py is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination"

Any pointers/thoughts in how I can resolve this issue?

With kind regards,

Jeffrey Simons

Software Engineer
Royal Boon Edam International B.V.


Re: pre-built native only tool for native and nativesdk

Joel Winarske
 

Actually by removing `inherit native` and adding -native to the recipe name doesn't make it build for native.

On Tue, Nov 9, 2021 at 3:23 PM Joel Winarske <joel.winarske@...> wrote:
To eliminate target option from the recipe I just need to make sure the name of the recipe ends with -native, then removing inherit native works fine.

On Tue, Nov 9, 2021 at 2:09 PM Joel Winarske via lists.yoctoproject.org <joel.winarske=gmail.com@...> wrote:
I'm trying to sort out how to install a pre-built host-only tool for native and nativesdk only.

Using `inherit native` my-recipe-native and nativesdk-my-recipe both build fine, only -c populate_sdk generates "rdepends upon non-existent task do_package_write_rpm".  Looking at native.bbclass it includes `inherit nopackage` which explains the error.

If I remove the `inherit native` and update my recipe name to not include `-native` I can build the -native version, only I can't build nativesdk-*-native.  A target build is invalid.

What is the recommended pattern to do this, and is there an example of this anywhere?


Thanks,
Joel




Re: pre-built native only tool for native and nativesdk

Joel Winarske
 

To eliminate target option from the recipe I just need to make sure the name of the recipe ends with -native, then removing inherit native works fine.

On Tue, Nov 9, 2021 at 2:09 PM Joel Winarske via lists.yoctoproject.org <joel.winarske=gmail.com@...> wrote:
I'm trying to sort out how to install a pre-built host-only tool for native and nativesdk only.

Using `inherit native` my-recipe-native and nativesdk-my-recipe both build fine, only -c populate_sdk generates "rdepends upon non-existent task do_package_write_rpm".  Looking at native.bbclass it includes `inherit nopackage` which explains the error.

If I remove the `inherit native` and update my recipe name to not include `-native` I can build the -native version, only I can't build nativesdk-*-native.  A target build is invalid.

What is the recommended pattern to do this, and is there an example of this anywhere?


Thanks,
Joel




Re: [meta-qt4]

Paul Eggleton
 

Hi Jared / all

On Wednesday, 10 November 2021 10:05:39 NZDT jared_terry@... wrote:
I don't see a response yet from Paul Eggleton, how do we proceeded in
getting this fixed?
My apologies - I've applied the fix and pushed it to master, thank you!

I think it's fair to say this layer is pretty much unmaintained at the moment.
I'd be more than happy if someone wants to take it over, FWIW.

Cheers
Paul


pre-built native only tool for native and nativesdk

Joel Winarske
 

I'm trying to sort out how to install a pre-built host-only tool for native and nativesdk only.

Using `inherit native` my-recipe-native and nativesdk-my-recipe both build fine, only -c populate_sdk generates "rdepends upon non-existent task do_package_write_rpm".  Looking at native.bbclass it includes `inherit nopackage` which explains the error.

If I remove the `inherit native` and update my recipe name to not include `-native` I can build the -native version, only I can't build nativesdk-*-native.  A target build is invalid.

What is the recommended pattern to do this, and is there an example of this anywhere?


Thanks,
Joel


Re: [meta-qt4]

jared_terry@...
 

I don't see a response yet from Paul Eggleton, how do we proceeded in getting this fixed?


Yocto Project Status WW45`21

Stephen Jolley
 

Current Dev Position: YP 3.5 M1

Next Deadline: 6th Dec. 2021 YP 3.5 M1 build

 

Next Team Meetings:

 

Key Status/Updates:

  • YP 3.3.4 is in QA
  • YP 3.5 Planning document: https://docs.google.com/document/d/1OXw-NKoL_Vb9RWI6sRPs3zTcAn4hHPtG0Y2BIs7xIzo/edit?usp=sharing
  • There is a proposed syntax simplification on the openembedded-architecture list with a patch on bitbake-devel. This would phase out the use of append/prepend/remove operators with +=/=+ and mean it would just work with “=” alone. We’ve not recommended this combination and it removes a redundancy which confuses new users.
  • There will be some infrastructure down time at the end of the year for the autobuilder and NAS, likely between the 26th and 31st December. This will affect the autobuilder workers, downloads and sstate shares from the project but not websites or git services. Last time we had a NAS outage it caused some issues so we are trying to ensure those issues are fixed in the stable branches and master with mirroring in place for key things like uninative before then. If anyone is aware of any other failure modes we need to address, please let us know.
  • Workarounds for the github protocol changes have been merged to all stable branches and to master with url changes also being made in many cases.
  • We have seen a drop in the number of patches in “Pending” state again this week. Many thanks to everyone who has taken the time to review patch status and handle accordingly.
  • 5.15 kernel headers and kernels have been merged.
  • There have been a number of small but potentially useful bitbake fixes to file checksum tracking, runall option handling and hung parsing threads.
  • Intermittent issues continue to rise and help is very much welcome on these issues. 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

 

Ways to contribute:

 

YP 3.5 Milestone Dates:

  • YP 3.5 M1 build date 2021/12/06
  • YP 3.5 M1 Release date 2021/12/17
  • YP 3.5 M2 build date 2022/01/10
  • YP 3.5 M2 Release date 2022/1/21
  • YP 3.5 M3 build date 2022/2/21
  • YP 3.5 M3 Release date 2022/03/04
  • YP 3.5 M4 build date 2022/04/04
  • YP 3.5 M4 Release date 2022/04/29

 

Upcoming dot releases:

  • YP 3.3.4 is in QA
  • YP 3.1.12 build date 2021/11/15
  • YP 3.1.12 Release date 2021/11/26
  • YP 3.4.1 build date 2021/11/22
  • YP 3.4.1 Release date 2021/12/03
  • YP 3.1.13 build date 2021/12/13
  • YP 3.1.13 Release date 2021/12/22
  • YP 3.1.14 build date 2022/01/24
  • YP 3.1.14 Release date 2022/02/04
  • YP 3.4.2 build date 2022/02/07
  • YP 3.4.2 Release date 2022/02/18
  • YP 3.1.15 build date 2022/03/14
  • YP 3.1.15 Release date 2022/03/25
  • YP 3.4.3 build date 2022/03/21
  • YP 3.4.3 Release date 2022/04/01
  • YP 3.1.16 build date 2022/04/25
  • YP 3.1.16 Release date 2022/05/06

 

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

 

2501 - 2520 of 57773