From: Amit Kucheria <amit.kucheria.ext@...>

This sample application provides an example of using the the MBEDTLS library.

Signed-off-by: Amit Kucheria <amit.kucheria.ext@...>
---
recipes-kernel/zephyr-kernel/zephyr-echo-client.bb | 5 +++++
1 file changed, 5 insertions(+)
create mode 100644 recipes-kernel/zephyr-kernel/zephyr-echo-client.bb

diff --git a/recipes-kernel/zephyr-kernel/zephyr-echo-client.bb b/recipes-kernel/zephyr-kernel/zephyr-echo-client.bb
new file mode 100644
index 000000000000..c17e1e78f6b5
--- /dev/null
+++ b/recipes-kernel/zephyr-kernel/zephyr-echo-client.bb
@@ -0,0 +1,5 @@
+include zephyr-sample.inc
+
+ZEPHYR_SRC_DIR = "${S}/samples/net/sockets/echo_client"
+
+ZEPHYR_MODULES_append = "\;${S}/modules/lib/mbedtls"
--
2.25.1

From: Amit Kucheria <amit.kucheria.ext@...>

MBed TLS is a library that implements cryptographic primitives and
SSL/TLS and DTLS protocols that are needed in secure network
communications.

Add it to the kernel include files to build and link against
applications that need mbedtls.

Signed-off-by: Amit Kucheria <amit.kucheria.ext@...>
---
recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc | 1 +
recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.0-rc1.inc | 1 +
recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc | 1 +
3 files changed, 3 insertions(+)

diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
index 330fe59aebe5..c9acbbbc3645 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
@@ -28,6 +28,7 @@ ZEPHYR_MODULES = ""
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_mbedtls = "\;${S}/modules/lib/mbedtls"
ZEPHYR_MODULES_append_openamp = "\;${S}/modules/lib/open-amp\;${S}/modules/hal/libmetal"

EXTRA_OECMAKE_append = " -DZEPHYR_MODULES=${ZEPHYR_MODULES}"
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.0-rc1.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.0-rc1.inc
index 6ea15931607d..a0e358ecd4f4 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.0-rc1.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.0-rc1.inc
@@ -6,5 +6,6 @@ SRCREV_stm32 = "f8ff8d25aa0a9e65948040c7b47ec67f3fa300df"
SRCREV_open-amp = "6010f0523cbc75f551d9256cf782f173177acdef"
SRCREV_libmetal = "39d049d4ae68e6f6d595fce7de1dcfc1024fb4eb"
SRCREV_tinycrypt = "3e9a49d2672ec01435ffbf0d788db6d95ef28de0"
+SRCREV_mbedtls = "5765cb7f75a9973ae9232d438e361a9d7bbc49e7"

PV = "2.6.0-rc1+git${SRCPV}"
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
index 9fc08baaf210..8dcfec6f1f88 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
@@ -17,6 +17,7 @@ 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;protocol=https;destsuffix=git/modules/hal/stm32;name=stm32 \
+ 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/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 \
--
2.25.1

From: Amit Kucheria <amit.kucheria.ext@...>

MBed TLS is a library that implements cryptographic primitives and SSL/TLS
and DTLS protocols that are needed in secure network communications.

Add it to the kernel include files to build and link against applications
that need mbedtls. Add a few sample applications that utilize mbedtls
library too.

Amit Kucheria (5):
zephyr-kernel: Clone mbedtls
zephyr-echo-client: Add recipe for echo client
zephyr-http-client: Add recipe for http client
zephyr-websocket-client: Add recipe for websocket client
zephyr-mqtt-publisher: Add recipe for mqtt publisher

recipes-kernel/zephyr-kernel/zephyr-echo-client.bb | 5 +++++
recipes-kernel/zephyr-kernel/zephyr-http-client.bb | 5 +++++
recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc | 1 +
recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.0-rc1.inc | 1 +
recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc | 1 +
recipes-kernel/zephyr-kernel/zephyr-mqtt-publisher.bb | 5 +++++
recipes-kernel/zephyr-kernel/zephyr-websocket-client.bb | 5 +++++
7 files changed, 23 insertions(+)
create mode 100644 recipes-kernel/zephyr-kernel/zephyr-echo-client.bb
create mode 100644 recipes-kernel/zephyr-kernel/zephyr-http-client.bb
create mode 100644 recipes-kernel/zephyr-kernel/zephyr-mqtt-publisher.bb
create mode 100644 recipes-kernel/zephyr-kernel/zephyr-websocket-client.bb

--
2.25.1

Fixes the MinGW builds for zstd

Signed-off-by: Joshua Watt <JPEWhacker@...>
---
recipes-extended/zstd/zstd_%.bbappend | 2 ++
1 file changed, 2 insertions(+)
create mode 100644 recipes-extended/zstd/zstd_%.bbappend

diff --git a/recipes-extended/zstd/zstd_%.bbappend b/recipes-extended/zstd/zstd_%.bbappend
new file mode 100644
index 0000000..3b2b991
--- /dev/null
+++ b/recipes-extended/zstd/zstd_%.bbappend
@@ -0,0 +1,2 @@
+EXTRA_OEMAKE_append_mingw32 = " OS=Windows"
+FILES_${PN}_append_mingw32 = " ${libdir}/*.dll"
--
2.31.1

Signed-off-by: Randy MacLeod <Randy.MacLeod@...>
---
meta-parsec/README.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-parsec/README.md b/meta-parsec/README.md
index a2736b6..6d938a6 100644
--- a/meta-parsec/README.md
+++ b/meta-parsec/README.md
@@ -75,7 +75,7 @@ to ensure maximum reproducibility.
versions of parsec recipes.
https://github.com/meta-rust/cargo-bitbake

- When you have crago-bitbake built:
+ When you have cargo-bitbake built:
1. Checkout the required version of parsec repository.
2. Run cargo-bitbake inside the repository. It will produce a BB file.
3. Create a new include file with SRC_URI and LIC_FILES_CHKSUM from the BB file.
--
2.27.0

Hello Khem,

we use CMake as build system.

I checked the "sysdig" recipe and they defined both the "grpc" and "grpc-native" (same with protbuf) in the DEPENDS variable like so:

DEPENDS += "... grpc grpc-native protobuf protobuf-native ..."

If I do this in my recipe I get the following error:

18:55:09  -- Found Protobuf: /data/jenkins/workspace/e0_mbient_yocto_mbient_manifests_master_downstream/build/tmp/work/corei7-64-mbient-linux/tokenmaster-client/git-r0/recipe-sysroot/usr/lib/libprotobuf.so;-lpthread (found version "3.12.3") 
18:55:09  CMake Error at /data/jenkins/workspace/e0_mbient_yocto_mbient_manifests_master_downstream/build/tmp/work/corei7-64-mbient-linux/tokenmaster-client/git-r0/recipe-sysroot/usr/lib/cmake/grpc/gRPCTargets.cmake:197 (message):
18:55:09    The imported target "gRPC::grpc_cpp_plugin" references the file
18:55:09  
18:55:09       "/data/jenkins/workspace/e0_mbient_yocto_mbient_manifests_master_downstream/build/tmp/work/corei7-64-mbient-linux/tokenmaster-client/git-r0/recipe-sysroot/usr/bin/grpc_cpp_plugin"
18:55:09  
18:55:09    but this file does not exist.  Possible reasons include:

which is correct as the directory ".../recipe-sysroot/usr/bin" does not contain any grpc plugins. However the directory ".../recipe-sysroot-native/usr/bin" does (due to the dependency to grpc-native).

It seems to work for sysdig, as they do not use "find_package(Protobuf)" or "find_package("gRPC") to detect gRPC related libraries/programs but use some custom code.

So it looks like:

1) If I use "DEPENDS += "... grpc-native protobuf-native ..." I am able to generate grpc stubs and I am also able to successfully build my component, but only, if the build-host and target-host are compatible => NO CROSS COMPING
2) If I use "DEPENDS += "... grpc grpc-native protobuf protobuf-native ..." CMake immediately complains, that some the grpc plugins are missing
3) Using RDEPENDS seems to have no effect

So it seems the only way to make this work is to use "DEPENDS += grpc grpc-native ...." and write some custom CMake code to detect grpc related libraries (e.g. libgrpc++.so) and programs (e.g. protoc, grpc_cpp_plugin).

But again, I am new to Yocto and still hope, that there is an easier way?

Hi,

On Wed, May 26, 2021 at 1:32 PM Zoran Stojsavljevic
<zoran.stojsavljevic@...> wrote:

Seems like this bug has nothing to do with YOCTO, rather with Wayland setup....

https://wayland-devel.freedesktop.narkive.com/6yavoPFZ/i-ve-got-a-question-to-ask-you

My two cent worth attempt,

Well I found this:
https://gitlab.freedesktop.org/wayland/weston/-/issues/314 and then
related patch https://gitlab.freedesktop.org/wayland/weston/-/commit/d171c7b3ba346c4d0bd6494f45ebf0be3c3cc5fb
which I've added but it doesn't help. When booted with plugged mouse
it boots fine :)

Zoran
_______

BR,

marek

On Wed, May 26, 2021 at 11:40 AM Marek Belisko <marek.belisko@...> wrote:

Hi,

I'm using hardknott poky release and build core-image-weston. When
started on display I didn't see wayland screen + terminal just
console. Same setup works fine on dunfell release.

Output from weston service:

GL_EXT_map_buffer_range GL_KHR_debug
GL_KHR_texture_compression_astc_ldr GL_NV_pixel_buffer_object
GL_OES_required_internalformat GL_OES_surfaceless_context
GL_EXT_separate_shader_objects
GL_EXT_compressed_ETC1_RGB8_sub_texture
GL_EXT_draw_elements_base_vertex GL_EXT_texture_border_clamp
GL_KHR_context_flush_control GL_OES_draw_elements_base_vertex
GL_OES_texture_border_clamp GL_KHR_no_error
GL_KHR_texture_compression_astc_sliced_3d
GL_KHR_parallel_shader_compile GL_MESA_tile_raster_order
[09:38:18.885] GL ES 2 renderer features:
read-back format: BGRA
wl_shm sub-image to texture: yes
EGL Wayland extension: yes
[09:38:18.899] warning: no input devices on entering Weston. Possible causes:
- no permissions to read /dev/input/event*
- seats misconfigured (Weston backend option 'seat', udev
device property ID_SEAT)
[09:38:18.899] failed to create input devices
Segmentation fault

Machine is RPI3. Any ideas?

Thanks and BR,

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

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

Hi Guys,

                I need some support for gstreamer elements support fdkaacenc/fdkaacdec . Currently I am using gstreamer 16.0.1 version OE sources. I have added gstreamer bad,good,base,libav plugins Added in my image.gstreamer-plugins-bad its not providing fdkaac support I tried to enable but its not compiling my sources.
I am using risc-v target machine . I am looking for  where I can get sources can anybody knows please give suggestions  build procedure steps . is i need to add any package related configuration in my local.conf please suggest me. 

Thanking you in advance.
--
Regards,
Sateesh

Seems like this bug has nothing to do with YOCTO, rather with Wayland setup....

https://wayland-devel.freedesktop.narkive.com/6yavoPFZ/i-ve-got-a-question-to-ask-you

My two cent worth attempt,
Zoran
_______

Op 25-05-2021 om 22:13 schreef Guillaume Champagne:

Le mar. 25 mai 2021 à 12:25, Ferry Toth <fntoth@...> a écrit :

Hi

Op 25-05-2021 om 15:09 schreef Guillaume Champagne:

Le mar. 25 mai 2021 à 08:19, Ferry Toth <fntoth@...> a écrit :

Adding Richard and Guillaume.

Hi,

it seems seems edison-image.bb sets ROOTFS as empty:
http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-edison/tree/meta-intel-edison-distro/recipes-core/images/edison-image.bb#n17

so do_bootimg won't depend on ${PN}:do_image:${LIVE_ROOTFS_TYPE}. That
dependency would, I think, create the folder you mentioned.

Maybe the patch wrongly assumes that if ROOTFS is empty, we shouldn't
add a dependency on "do_image.${LIVE_ROOTFS_TYPE}" at all since It
looks like edison-image.bb still depends on
${PN}:do_image.${LIVE_ROOTFS_TYPE} even though ROOTFS is empty. I
haven't looked too much into why edison-image works this way.

It may well be a bug in meta-intel-edison. Although you are looking at
the very, very old code.

So what we have now is:
https://github.com/edison-fw/meta-intel-edison/blob/master/meta-intel-edison-distro/recipes-core/images/edison-image-minimal.bb

this generates a dir edison-image-1.0/hddimg/ containing: bzImage
initrd ldlinux.sys libcom32.c32 libutil.c32 syslinux.cfg vesamenu.c32

and this should generate in dir deploy-edison-image-image-complete/ a
file called edison-image-edison.hddimg

which it does without the patch. So would would I set rootfs to to make
it work?

That's my bad. The initial patch is not right. I could reproduce your
issue on my side. I think ROOTFS should be able to remain empty if
your image does all its work in its initd/initramfs.

I think IMGDEPLOYDIR isn't created in time because the patch removes
the "depends" on "do_image -> do_rootfs" , which would create
IMGDEPLOYDIR via do_rootfs[cleandirs] before do_bootimg runs:
https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/image.bbclass?h=gatesgarth#n252

One way I could think of to fix:

diff --git a/meta/classes/image-live.bbclass b/meta/classes/image-live.bbclass
index e9eba1fc4b..eb92573488 100644
--- a/meta/classes/image-live.bbclass
+++ b/meta/classes/image-live.bbclass
@@ -260,5 +260,6 @@ python do_bootimg() {
}
do_bootimg[subimages] = "hddimg iso"
do_bootimg[imgsuffix] = "."
+do_bootimg[dirs] = "${IMGDEPLOYDIR} ${TOPDIR}"


_AND_ to add to my image recipe:
BUILD_REPRODUCIBLE_BINARIES = "0" # otherwise image.bbclass looks for
a the image's rootfs
deltask rootfs

I am not sure this is the right solution. There might be a way to
avoid adding a "deltask" in my recipe. And image.bbclass could
probably avoid its BUILD_REPRODUCIBLE_BINARIES check on the rootfs if
ROOTFS is empty.
Maybe someone else has a better solution?

Thanks. For some reason I don't see your message appearing on ML.

BTW It also generates a directory iso and associated iso image. Never
understood why, we also set NOISO = "1"

NOISO is valid in Yocto releases before 2.6 (thud):
https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#migration-2.6-miscellaneous-changes
Setting IMAGE_FSTYPES = "hddimg" should be the new equivalent of what
edison-image-minimal.bb does with NOISO="1" and NOHDD="0"

I think setting INITRD_IMAGE_LIVE to core-image-minimal-initramfs
could also replace the custom post process command "install_initrd".

I'll look into that.

Op 24-05-2021 om 14:39 schreef Ferry Toth:

Wow, that got messed up, let me retry.

Op 24-05-2021 om 14:19 schreef Ferry Toth:

Accidentally I refreshed poky and rebuilt. The image-live
(do_bootimg) fails when building hddimg with the following:

ERROR: edison-image-1.0-r0 do_bootimg: Error executing a python
function in exec_python_func() autogenerated:

The stack trace of python calls that resulted in this
exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: <module>
0001:
*** 0002:do_bootimg(d)
0003:
File:
'/home/ferry/tmp/edison-intel/my/edison-morty/out/linux64/poky/meta/classes/image-live.bbclass',
lineno: 258, function: do_bootimg
0254: if d.getVar("PCBIOS") == "1":
0255: bb.build.exec_func('build_syslinux_cfg', d)
0256: if d.getVar("EFI") == "1":
0257: bb.build.exec_func('build_efi_cfg', d)
*** 0258: bb.build.exec_func('build_hddimg', d)
0259: bb.build.exec_func('build_iso', d)
0260: bb.build.exec_func('create_symlinks', d)
0261:}
0262:do_bootimg[subimages] = "hddimg iso"
File:
'/home/ferry/tmp/edison-intel/my/edison-morty/out/linux64/poky/bitbake/lib/bb/build.py',
lineno: 256, function: exec_func
0252: with bb.utils.fileslocked(lockfiles):
0253: if ispython:
0254: exec_func_python(func, d, runfile, cwd=adir)
0255: else:
*** 0256: exec_func_shell(func, d, runfile, cwd=adir)
0257:
0258: try:
0259: curcwd = os.getcwd()
0260: except:
File:
'/home/ferry/tmp/edison-intel/my/edison-morty/out/linux64/poky/bitbake/lib/bb/build.py',
lineno: 503, function: exec_func_shell
0499: with open(fifopath, 'r+b', buffering=0) as fifo:
0500: try:
0501: bb.debug(2, "Executing shell function %s" % func)
0502: with open(os.devnull, 'r+') as stdin, logfile:
*** 0503: bb.process.run(cmd, shell=False,
stdin=stdin, log=logfile, extrafiles=[(fifo,readfifo)])
0504: except bb.process.ExecutionError as exe:
0505: # Find the backtrace that the shell trap generated
0506: backtrace_marker_regex = re.compile(r"WARNING:
Backtrace \(BB generated script\)")
0507: stdout_lines = (exe.stdout or "").split("\n")
File:
'/home/ferry/tmp/edison-intel/my/edison-morty/out/linux64/poky/bitbake/lib/bb/process.py',
lineno: 184, function: run
0180: if not stderr is None:
0181: stderr = stderr.decode("utf-8")
0182:
0183: if pipe.returncode != 0:
*** 0184: raise ExecutionError(cmd, pipe.returncode, stdout,
stderr)
0185: return stdout, stderr
Exception: bb.process.ExecutionError: Execution of
'/home/ferry/tmp/edison-intel/my/edison-morty/out/linux64/build/tmp/work/edison-poky-linux/edison-image/1.0-r0/temp/run.build_hddimg.256530'
failed with exit code 1:
mkdosfs: unable to create
/home/ferry/tmp/edison-intel/my/edison-morty/out/linux64/build/tmp/work/edison-poky-linux/edison-image/1.0-r0/deploy-edison-image-image-complete/edison-image-edison-20210524113748.hddimg
mkfs.fat 4.1 (2017-01-24)
WARNING: exit code 1 from a shell command.

The reason is that the directory deploy-edison-image-image-complete
doesn't exist at the time mkdosfs want to write. However after
completing the remainder of image live the directory does exists.
Consequently, running bitbake a second time image-live succeeds.

I've tried various thing including expressly creating the directory
before mkdosfs, but nothing worked. It seems I don't understand how
it is supposed to work in the first place.

However, I managed to trace back the issue to this commit 91e4a1c1
"image-live.bbclass: optional depends when ROOTFS empty".

Reverting this resolves the issue.

Any idea what could be wrong?

Hi,

I'm using hardknott poky release and build core-image-weston. When
started on display I didn't see wayland screen + terminal just
console. Same setup works fine on dunfell release.

Output from weston service:

GL_EXT_map_buffer_range GL_KHR_debug
GL_KHR_texture_compression_astc_ldr GL_NV_pixel_buffer_object
GL_OES_required_internalformat GL_OES_surfaceless_context
GL_EXT_separate_shader_objects
GL_EXT_compressed_ETC1_RGB8_sub_texture
GL_EXT_draw_elements_base_vertex GL_EXT_texture_border_clamp
GL_KHR_context_flush_control GL_OES_draw_elements_base_vertex
GL_OES_texture_border_clamp GL_KHR_no_error
GL_KHR_texture_compression_astc_sliced_3d
GL_KHR_parallel_shader_compile GL_MESA_tile_raster_order
[09:38:18.885] GL ES 2 renderer features:
read-back format: BGRA
wl_shm sub-image to texture: yes
EGL Wayland extension: yes
[09:38:18.899] warning: no input devices on entering Weston. Possible causes:
- no permissions to read /dev/input/event*
- seats misconfigured (Weston backend option 'seat', udev
device property ID_SEAT)
[09:38:18.899] failed to create input devices
Segmentation fault

Machine is RPI3. Any ideas?

Thanks and BR,

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

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


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


Build hash information:

bitbake: 078f3164dcb1de7a141bec3a8fd52631d0362631
meta-arm: 9dadb61b36fdd09a39d8cb755fa29d03928a1116
meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac
meta-intel: 2fb89eb85dea00de9446c1cf44ba6a5586f42c84
meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7
oecore: ecd636154e7cfc1349a7cfd8026a85eafa219535
poky: 6ebb33bdaccaeadff0c85aab27acf35723df00d8



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

Hi

Op 25-05-2021 om 15:09 schreef Guillaume Champagne:

Le mar. 25 mai 2021 à 08:19, Ferry Toth <fntoth@...> a écrit :

Adding Richard and Guillaume.

Hi,

it seems seems edison-image.bb sets ROOTFS as empty:
http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-edison/tree/meta-intel-edison-distro/recipes-core/images/edison-image.bb#n17

so do_bootimg won't depend on ${PN}:do_image:${LIVE_ROOTFS_TYPE}. That
dependency would, I think, create the folder you mentioned.

Maybe the patch wrongly assumes that if ROOTFS is empty, we shouldn't
add a dependency on "do_image.${LIVE_ROOTFS_TYPE}" at all since It
looks like edison-image.bb still depends on
${PN}:do_image.${LIVE_ROOTFS_TYPE} even though ROOTFS is empty. I
haven't looked too much into why edison-image works this way.

It may well be a bug in meta-intel-edison. Although you are looking at the very, very old code.

So what we have now is: https://github.com/edison-fw/meta-intel-edison/blob/master/meta-intel-edison-distro/recipes-core/images/edison-image-minimal.bb

this generates a dir edison-image-1.0/hddimg/ containing: bzImage  initrd  ldlinux.sys  libcom32.c32  libutil.c32  syslinux.cfg  vesamenu.c32

and this should generate in dir deploy-edison-image-image-complete/ a file called edison-image-edison.hddimg

which it does without the patch. So would would I set rootfs to to make it work?

BTW It also generates a directory iso and associated iso image. Never understood why, we also set NOISO = "1"

Op 24-05-2021 om 14:39 schreef Ferry Toth:

Wow, that got messed up, let me retry.

Op 24-05-2021 om 14:19 schreef Ferry Toth:

Accidentally I refreshed poky and rebuilt. The image-live
(do_bootimg) fails when building hddimg with the following:

ERROR: edison-image-1.0-r0 do_bootimg: Error executing a python
function in exec_python_func() autogenerated:

The stack trace of python calls that resulted in this
exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: <module>
0001:
*** 0002:do_bootimg(d)
0003:
File:
'/home/ferry/tmp/edison-intel/my/edison-morty/out/linux64/poky/meta/classes/image-live.bbclass',
lineno: 258, function: do_bootimg
0254: if d.getVar("PCBIOS") == "1":
0255: bb.build.exec_func('build_syslinux_cfg', d)
0256: if d.getVar("EFI") == "1":
0257: bb.build.exec_func('build_efi_cfg', d)
*** 0258: bb.build.exec_func('build_hddimg', d)
0259: bb.build.exec_func('build_iso', d)
0260: bb.build.exec_func('create_symlinks', d)
0261:}
0262:do_bootimg[subimages] = "hddimg iso"
File:
'/home/ferry/tmp/edison-intel/my/edison-morty/out/linux64/poky/bitbake/lib/bb/build.py',
lineno: 256, function: exec_func
0252: with bb.utils.fileslocked(lockfiles):
0253: if ispython:
0254: exec_func_python(func, d, runfile, cwd=adir)
0255: else:
*** 0256: exec_func_shell(func, d, runfile, cwd=adir)
0257:
0258: try:
0259: curcwd = os.getcwd()
0260: except:
File:
'/home/ferry/tmp/edison-intel/my/edison-morty/out/linux64/poky/bitbake/lib/bb/build.py',
lineno: 503, function: exec_func_shell
0499: with open(fifopath, 'r+b', buffering=0) as fifo:
0500: try:
0501: bb.debug(2, "Executing shell function %s" % func)
0502: with open(os.devnull, 'r+') as stdin, logfile:
*** 0503: bb.process.run(cmd, shell=False,
stdin=stdin, log=logfile, extrafiles=[(fifo,readfifo)])
0504: except bb.process.ExecutionError as exe:
0505: # Find the backtrace that the shell trap generated
0506: backtrace_marker_regex = re.compile(r"WARNING:
Backtrace \(BB generated script\)")
0507: stdout_lines = (exe.stdout or "").split("\n")
File:
'/home/ferry/tmp/edison-intel/my/edison-morty/out/linux64/poky/bitbake/lib/bb/process.py',
lineno: 184, function: run
0180: if not stderr is None:
0181: stderr = stderr.decode("utf-8")
0182:
0183: if pipe.returncode != 0:
*** 0184: raise ExecutionError(cmd, pipe.returncode, stdout,
stderr)
0185: return stdout, stderr
Exception: bb.process.ExecutionError: Execution of
'/home/ferry/tmp/edison-intel/my/edison-morty/out/linux64/build/tmp/work/edison-poky-linux/edison-image/1.0-r0/temp/run.build_hddimg.256530'
failed with exit code 1:
mkdosfs: unable to create
/home/ferry/tmp/edison-intel/my/edison-morty/out/linux64/build/tmp/work/edison-poky-linux/edison-image/1.0-r0/deploy-edison-image-image-complete/edison-image-edison-20210524113748.hddimg
mkfs.fat 4.1 (2017-01-24)
WARNING: exit code 1 from a shell command.

The reason is that the directory deploy-edison-image-image-complete
doesn't exist at the time mkdosfs want to write. However after
completing the remainder of image live the directory does exists.
Consequently, running bitbake a second time image-live succeeds.

I've tried various thing including expressly creating the directory
before mkdosfs, but nothing worked. It seems I don't understand how
it is supposed to work in the first place.

However, I managed to trace back the issue to this commit 91e4a1c1
"image-live.bbclass: optional depends when ROOTFS empty".

Reverting this resolves the issue.

Any idea what could be wrong?

Le mar. 25 mai 2021 à 08:19, Ferry Toth <fntoth@...> a écrit :

Adding Richard and Guillaume.

Hi,

it seems seems edison-image.bb sets ROOTFS as empty:
http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-edison/tree/meta-intel-edison-distro/recipes-core/images/edison-image.bb#n17

so do_bootimg won't depend on ${PN}:do_image:${LIVE_ROOTFS_TYPE}. That
dependency would, I think, create the folder you mentioned.

Maybe the patch wrongly assumes that if ROOTFS is empty, we shouldn't
add a dependency on "do_image.${LIVE_ROOTFS_TYPE}" at all since It
looks like edison-image.bb still depends on
${PN}:do_image.${LIVE_ROOTFS_TYPE} even though ROOTFS is empty. I
haven't looked too much into why edison-image works this way.

Op 24-05-2021 om 14:39 schreef Ferry Toth:

Wow, that got messed up, let me retry.

Op 24-05-2021 om 14:19 schreef Ferry Toth:

Accidentally I refreshed poky and rebuilt. The image-live
(do_bootimg) fails when building hddimg with the following:

ERROR: edison-image-1.0-r0 do_bootimg: Error executing a python
function in exec_python_func() autogenerated:

The stack trace of python calls that resulted in this
exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: <module>
0001:
*** 0002:do_bootimg(d)
0003:
File:
'/home/ferry/tmp/edison-intel/my/edison-morty/out/linux64/poky/meta/classes/image-live.bbclass',
lineno: 258, function: do_bootimg
0254: if d.getVar("PCBIOS") == "1":
0255: bb.build.exec_func('build_syslinux_cfg', d)
0256: if d.getVar("EFI") == "1":
0257: bb.build.exec_func('build_efi_cfg', d)
*** 0258: bb.build.exec_func('build_hddimg', d)
0259: bb.build.exec_func('build_iso', d)
0260: bb.build.exec_func('create_symlinks', d)
0261:}
0262:do_bootimg[subimages] = "hddimg iso"
File:
'/home/ferry/tmp/edison-intel/my/edison-morty/out/linux64/poky/bitbake/lib/bb/build.py',
lineno: 256, function: exec_func
0252: with bb.utils.fileslocked(lockfiles):
0253: if ispython:
0254: exec_func_python(func, d, runfile, cwd=adir)
0255: else:
*** 0256: exec_func_shell(func, d, runfile, cwd=adir)
0257:
0258: try:
0259: curcwd = os.getcwd()
0260: except:
File:
'/home/ferry/tmp/edison-intel/my/edison-morty/out/linux64/poky/bitbake/lib/bb/build.py',
lineno: 503, function: exec_func_shell
0499: with open(fifopath, 'r+b', buffering=0) as fifo:
0500: try:
0501: bb.debug(2, "Executing shell function %s" % func)
0502: with open(os.devnull, 'r+') as stdin, logfile:
*** 0503: bb.process.run(cmd, shell=False,
stdin=stdin, log=logfile, extrafiles=[(fifo,readfifo)])
0504: except bb.process.ExecutionError as exe:
0505: # Find the backtrace that the shell trap generated
0506: backtrace_marker_regex = re.compile(r"WARNING:
Backtrace \(BB generated script\)")
0507: stdout_lines = (exe.stdout or "").split("\n")
File:
'/home/ferry/tmp/edison-intel/my/edison-morty/out/linux64/poky/bitbake/lib/bb/process.py',
lineno: 184, function: run
0180: if not stderr is None:
0181: stderr = stderr.decode("utf-8")
0182:
0183: if pipe.returncode != 0:
*** 0184: raise ExecutionError(cmd, pipe.returncode, stdout,
stderr)
0185: return stdout, stderr
Exception: bb.process.ExecutionError: Execution of
'/home/ferry/tmp/edison-intel/my/edison-morty/out/linux64/build/tmp/work/edison-poky-linux/edison-image/1.0-r0/temp/run.build_hddimg.256530'
failed with exit code 1:
mkdosfs: unable to create
/home/ferry/tmp/edison-intel/my/edison-morty/out/linux64/build/tmp/work/edison-poky-linux/edison-image/1.0-r0/deploy-edison-image-image-complete/edison-image-edison-20210524113748.hddimg
mkfs.fat 4.1 (2017-01-24)
WARNING: exit code 1 from a shell command.

The reason is that the directory deploy-edison-image-image-complete
doesn't exist at the time mkdosfs want to write. However after
completing the remainder of image live the directory does exists.
Consequently, running bitbake a second time image-live succeeds.

I've tried various thing including expressly creating the directory
before mkdosfs, but nothing worked. It seems I don't understand how
it is supposed to work in the first place.

However, I managed to trace back the issue to this commit 91e4a1c1
"image-live.bbclass: optional depends when ROOTFS empty".

Reverting this resolves the issue.

Any idea what could be wrong?

On Tue, 2021-05-25 at 12:13 +0000, Peter Kjellerstedt wrote:

It seems the ”hardknott-25.0.1” tag is missing for meta-gplv2. 
The “yoccto-3.3.1” tag is present.

This was deliberate since we've been trying to step away from the 
"poky" version numbers, I'm not sure they add much to anything.

Is there a particular reason you were looking for those?

Cheers,

Richard

Adding Richard and Guillaume.

Op 24-05-2021 om 14:39 schreef Ferry Toth: