Date   

Re: gstreamer-emements support fdkaacenc/fdkaacdec #yocto

Khem Raj
 

On 5/26/21 5:01 AM, sateesh m wrote:
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.

see http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.16.3.bb?h=dunfell#n114

change that to -Dfdkaac=enabled

if it works, then perhaps turn that into packageconfig and send a patch as well if you can

--
Regards,
Sateesh


[meta-zephyr][PATCH 5/5] zephyr-mqtt-publisher: Add recipe for mqtt publisher

Amit Kucheria
 

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-mqtt-publisher.bb | 5 +++++
1 file changed, 5 insertions(+)
create mode 100644 recipes-kernel/zephyr-kernel/zephyr-mqtt-publisher.bb

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


[meta-zephyr][PATCH 4/5] zephyr-websocket-client: Add recipe for websocket client

Amit Kucheria
 

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-websocket-client.bb | 5 +++++
1 file changed, 5 insertions(+)
create mode 100644 recipes-kernel/zephyr-kernel/zephyr-websocket-client.bb

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


[meta-zephyr][PATCH 3/5] zephyr-http-client: Add recipe for http client

Amit Kucheria
 

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-http-client.bb | 5 +++++
1 file changed, 5 insertions(+)
create mode 100644 recipes-kernel/zephyr-kernel/zephyr-http-client.bb

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


[meta-zephyr][PATCH 2/5] zephyr-echo-client: Add recipe for echo client

Amit Kucheria
 

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


[meta-zephyr][PATCH 1/5] zephyr-kernel: Clone mbedtls

Amit Kucheria
 

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


[meta-zephyr][PATCH 0/5] Add mbedtls support and sample applications

Amit Kucheria
 

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


[meta-mingw][PATCH] zstd: Fix MinGW builds

Joshua Watt
 

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


[meta-parsec][PATCH] Correct typo: crago-bitbake

Randy MacLeod
 

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


Re: using grpc fails with linker error: file in wrong format

Juergen Landwehr
 

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?


Re: hardknott core-image-weston weston is crashing

Marek Belisko
 

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


gstreamer-emements support fdkaacenc/fdkaacdec #yocto

sateesh m
 

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


Re: hardknott core-image-weston weston is crashing

Zoran
 

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
_______

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



Re: Gatesgarth-24.0.4 image-live fails

Ferry Toth
 

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?


hardknott core-image-weston weston is crashing

Marek Belisko
 

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


QA notification for completed autobuilder build (yocto-3.1.8.rc1)

Pokybuild User <pokybuild@...>
 

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


Re: Gatesgarth-24.0.4 image-live fails

Ferry Toth
 

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?


Yocto Project Status WW21`21

Stephen Jolley
 

Current Dev Position: YP 3.4 M1

Next Deadline: 7th June 2021 YP 3.4 M1 build

 

Next Team Meetings:

 

Key Status/Updates:

  • YP 3.3.1 was released
  • YP 3.1.8 is being built, an autobuilder glitch meant we’re building rc2.
  • We’ve seen a significant reduction in CVE counts for master and the stable releases this week. For master this brings us down to 5 CVEs compared to 63 a couple of weeks ago. This should mean real/open issues are much clearer and old/obsolete issues no longer contribute noise to the output of the tools.
  • Help with the problematic recipe upgrades would be much appreciated.
  • The multiconfig changes in bitbake continue to cause problems, we still need simpler test cases to reproduce issues rather than huge builds. The existing patches seem to fix some workloads and break others. Richard is trying to fix but trying to fix autobuilder issues and other problems and these are slow builds to debug.
  • We have identified ltp issues with some tests causing hangs which have been disabled as well as issues with the 5.10.37 kernel which seem to be fixed in 5.10.38.
  • We’re seeing odd looking rcu stalls in qemu automated testing. This seems to occur more often with 5.10 kernel but also with 5.12 and with kvm-clock disabled and we have seen it with 5.4. It is unclear whether these are kernel issues or qemu issues, we’re struggling to debug them and any insight would be welcome.
  • Some debugging of these intermittent hangs has been posted to the swat mailing list.
  • Intermittent autobuilder issues continue to occur and are now at a record high level. 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

We are working to identify the load pattern on the infrastructure that seems to trigger these.

 

Ways to contribute:

 

YP 3.4 Milestone Dates:

  • YP 3.4 M1 build date 2021/06/07
  • YP 3.4 M1 Release date 2021/06/18
  • YP 3.4 M2 build date 2021/07/12
  • YP 3.4 M2 Release date 2021/07/23
  • YP 3.4 M3 build date 2021/08/23
  • YP 3.4 M3 Release date 2021/09/03
  • YP 3.4 M4 build date 2021/10/04
  • YP 3.4 M4 Release date 2021/10/29

 

Planned upcoming dot releases:

  • YP 3.3.1 is in released
  • YP 3.1.8 is being built
  • YP 3.1.8 release date 2021/06/04
  • YP 3.1.9 build date 2021/06/21
  • YP 3.1.9 release date 2021/07/02
  • YP 3.3.2 build date 2021/07/19
  • YP 3.3.2 release date 2021/07/30
  • YP 3.1.10 build date 2021/07/26
  • YP 3.1.10 release date 2021/08/06
  • YP 3.1.11 build date 2021/09/13
  • YP 3.1.11 release date 2021/9/24

 

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

 


Re: [ANNOUNCEMENT] Yocto Project 3.3.1 (hardknott-25.0.1) is Released

Peter Kjellerstedt
 

-----Original Message-----
From: Richard Purdie <richard.purdie@...>
Sent: den 25 maj 2021 14:44
To: Peter Kjellerstedt <peter.kjellerstedt@...>; Vineela
<vineela.tummalapalli@...>
Cc: 'yocto@...' <yocto@...>; Michael
Halstead <mhalstead@...>
Subject: Re: [yocto] [ANNOUNCEMENT] Yocto Project 3.3.1 (hardknott-25.0.1)
is Released

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?
Well, those are the ones we have traditionally been using. The benefit I see
with them are that they contain the release name. For me as a user, it is much
easier to see and refer to "hardknott-something.1" than "yocto-3.3.1". I.e.,
I don't have a relation to the "25.0" or "3.3" part, but to the release name.
We typically only talk about "hardknott" or "the second hardknott release".

That said, a tag such as "yocto-hardknott-3.3.1" or "hardknott-3.3.1" would
fulfill the same properties as "hardknott-25.0.1", though the one without
the "yocto-" prefix is more suitable when tab completing, e.g.,
`git log hardknott-3.3..hardknott-3.3.1`, so that is the one I would use if
it was up to me. ;)

Cheers,

Richard
//Peter


Re: Gatesgarth-24.0.4 image-live fails

Guillaume Champagne <champagne.guillaume.c@...>
 

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?

4181 - 4200 of 57808