1. Yocto
  2. Messages

Expanded

Topics Messages
   Date   
Re: RTC issue

Matthias Klein
 

Hello Jupiter,

How did you disable snvs_rtc? My device tree to include imx6ull.dtsi which don't have snvs_rtc, only has snvs-rtc-lp, so I added status = "disabled"; to the snvs-rtc-lp node:

snvs-rtc-lp {
compatible = "fsl,sec-v4.0-mon-rtc-lp";
regmap = <0x16>;
offset = <0x34>;
status = "disabled";
}

that must be wrong, it crashed in kernel booting.
I only added status = "disabled": https://github.com/optimeas/linux-tx6-5.10/blob/tx6-5.10/arch/arm/boot/dts/imx6dl-tx6s-8035-smartmini-v2p3.dts#L77

Best regards,
Matthias
Re: RTC issue

JH
 

Hello Matthias,

Thanks for your kind response.

I have seen the same message on an i.MX6S7
(https://www.karo-electronics.com/fileadmin/download/Datasheets/TX6S-Datasheet.pdf)
with kernel 5.10 (in a dunfell Yocto after I upgraded from kernel 4.14).

Since we use an external RTC on the I2C bus, I disabled the internal RTC
("snvs_rtc") in the device tree, and did not analyze the problem further.
How did you disable snvs_rtc? My device tree to include imx6ull.dtsi
which don't have snvs_rtc, only has snvs-rtc-lp, so I added status =
"disabled"; to the snvs-rtc-lp node:

snvs-rtc-lp {
compatible = "fsl,sec-v4.0-mon-rtc-lp";
regmap = <0x16>;
offset = <0x34>;
status = "disabled";
}

that must be wrong, it crashed in kernel booting.

[ 9.478754] ---[ end trace dc624b5857965e18 ]---
[ 9.483962] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0b
[ 9.483962]
[ 9.493223] ---[ end Kernel panic - not syncing: Attempted to kill init! exib
[ 9.493223] ]---


Thank you.

Kind regards,

- jupiter
Re: Hardknott support level

Randy MacLeod
 

On 2021-08-03 9:52 a.m., Alexander Kanavin wrote:
Hardknott will not become an LTS version, and will be maintained for 7 months, per https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS <https://urldefense.com/v3/__https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS__;!!AjveYdw8EvQ!NIoKnDSRFq3WDiKuTYy4hTbk0Nk0McU69nTZltOJaEobA7lVri6QJvk6HoQXH-Qq0S1rew$> (all of it worth reading).
The current plan is that Kirkstone will be the next LTS release (there's an LTS release every two years).
My recommendation is to start the project using current master (rather than something already released), periodically rebase on a later master, and branch off the stable/product branches in sync with upstream LTS releases. Rebasing from one yocto release to another yocto release is a lot more painful than rolling master + stable LTS model.
Alex
Or contact one of the companies that support Yocto:


https://www.yoctoproject.org/ecosystem/yocto-project-compatible-product-showcase/

That page is out of date and I'm trying to get it refreshed but it at
least shows which companies are available.

../Randy

On Tue, 3 Aug 2021 at 15:40, Fernando Luiz Cola <ferlzc@... <mailto:ferlzc@...>> wrote:
Hi, I'm starting a new project using Yocto and we plan to use Stable
(Hardknott - 3.3).
We gather this information on:
https://wiki.yoctoproject.org/wiki/Releases
<https://urldefense.com/v3/__https://wiki.yoctoproject.org/wiki/Releases__;!!AjveYdw8EvQ!NIoKnDSRFq3WDiKuTYy4hTbk0Nk0McU69nTZltOJaEobA7lVri6QJvk6HoQXH-TNnj1LJA$>
How can I verify/follow the when the project will schedule from
Stable to LTS?  There is an estimate for the EOL ?
Thank you in advance

--
# Randy MacLeod
# Wind River Linux
Re: multilib32: libtool-cross_2.4.6.bb configure failure

Geller, Nir <nir.geller@...>
 

Executing

bitbake lib32-libtool-cross -e

Yields, among many others,

 

18513 # $TARGET_VENDOR [3 operations]

18514 #   set /home/build/tisdk/sources/oe-core/meta/conf/bitbake.conf:132

18515 #     "-oe"

18516 #   set /home/build/tisdk/sources/meta-arago/meta-arago-distro/conf/distro/include/toolchain-arm.inc:15

18517 #     ""

18518 #   override[virtclass-multilib-lib32]:set multilib_global.bbclass:159 [multilib_virtclass_handler_vendor]

18519 #     "mllib32"

18520 # pre-expansion value:

18521 #   "mllib32"

18522 TARGET_VENDOR="mllib32"

 

Later, HOST_VENDOR  = "${TARGET_VENDOR}",

And HOST_SYS = "${HOST_ARCH}${HOST_VENDOR}-${HOST_OS}"

 

Ok.

 

So either these variables are calculated incorrectly, or the libtool-cross recipe needs to be fixed in order to support multilib properly.

 

Can anyone please assist?

 

Thanks,

 

Nir.

 

From: yocto@... <yocto@...> On Behalf Of Geller, Nir
Sent: Wednesday, August 11, 2021 5:03 PM
To: Geller, Nir <nir.geller@...>; yocto@...
Subject: Re: [yocto] multilib32: libtool-cross_2.4.6.bb configure failure

 

The variable SYS_HOST is expanded to armmllib32-linux-gnueabi

Shouldn’t it be expanded to arm-none-linux-gnueabihf ?

 

Thanks,

 

Nir.

 

From: yocto@... <yocto@...> On Behalf Of Geller, Nir
Sent: Wednesday, August 11, 2021 4:41 PM
To: yocto@...
Subject: Re: [yocto] multilib32: libtool-cross_2.4.6.bb configure failure

 

Investigating run.do_configure suggests that in the configure stage oe_runconf() is set with what seems to be wrong –host and –target values:

 --host=armmllib32-linux-gnueabi   --target=armmllib32-linux-gnueabi

 

How can I influence oe_runconf() generation and set correct values?

 

From: yocto@... <yocto@...> On Behalf Of Geller, Nir
Sent: Wednesday, August 11, 2021 12:42 PM
To: yocto@...
Subject: [yocto] multilib32: libtool-cross_2.4.6.bb configure failure

 

Hi There,

 

Following the instruction from TI

 

https://software-dl.ti.com/processor-sdk-linux-rt/esd/AM64X/latest/exports/docs/linux/Overview_Building_the_SDK.html

 

I’ve setup a yocto project for the AM64x.

 

Toolchain used is 9.2-2019.12

 

Now I need to add support for multilib32 because I have some software that can be compiled only 32 bit.

 

I added the following lines to conf/local.conf

 

# Define multilib target

require conf/multilib.conf

MULTILIBS = "multilib:lib32"

DEFAULTTUNE_virtclass-multilib-lib32 = "armv7athf-neon"

 

And I am able to build a few packges with lib32- successfully, however, lib32-libtool-cross fails at the configure stage:

 

--host is set to the value armmllib32-linux-gnueabi

 

ERROR: lib32-libtool-cross-2.4.6-r0 do_configure: configure failed

ERROR: lib32-libtool-cross-2.4.6-r0 do_configure: Execution of '/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/temp/run.do_configure.29261' failed with exit code 1:

automake (GNU automake) 1.16.1

Copyright (C) 2018 Free Software Foundation, Inc.

License GPLv2+: GNU GPL version 2 or later <https://gnu.org/licenses/gpl-2.0.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

 

Written by Tom Tromey <tromey@...>

       and Alexandre Duret-Lutz <adl@...>.

AUTOV is 1.16

autoreconf: Entering directory `.'

autoreconf: configure.ac: not using Gettext

autoreconf: running: aclocal --system-acdir=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot/usr/share/aclocal/ --automake-acdir=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/share/aclocal-1.16 -I /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/m4/ -I /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/tests/ -I /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/share/aclocal/ --force --warnings=cross -I m4

aclocal: warning: unknown warning category 'cross'

autoreconf: configure.ac: tracing

autoreconf: running: /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/bin/autoconf --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/m4/ --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/tests/ --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/share/aclocal/ --force --warnings=cross

autoreconf: running: /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/bin/autoheader --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/m4/ --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/tests/ --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/share/aclocal/ --force --warnings=cross

autoreconf: running: automake --add-missing --copy --force-missing --warnings=cross

automake: warning: unknown warning category 'cross'

autoreconf: running: gnu-configize

autoreconf: Leaving directory `.'

| NOTE: Running ../libtool-2.4.6/configure  --build=x86_64-linux                                 --host=armmllib32-linux-gnueabi                   --target=armmllib32-linux-gnueabi                         --prefix=/usr           --exec_prefix=/usr                          --bindir=/usr/bin                             --sbindir=/usr/sbin                              --libexecdir=/usr/libexec                             --datadir=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot/usr/share                      --sysconfdir=/etc                            --sharedstatedir=/com                                 --localstatedir=/var                             --libdir=/usr/lib                               --includedir=/usr/include                                 --oldincludedir=/usr/include                      --infodir=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot/usr/share/info                                 --mandir=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot/usr/share/man                   --disable-silent-rules                      --disable-dependency-tracking                                --with-libtool-sysroot=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot

configure: loading site script /home/build/tisdk/sources/meta-openembedded/meta-networking/site/endian-little

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/endian-little

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/arm-common

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/arm-32

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/common-linux

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/common-glibc

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/arm-linux

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/common

## ------------------------- ##

## Configuring libtool 2.4.6 ##

## ------------------------- ##

 

checking for GNU M4 that supports accurate traces... /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/bin/m4

checking whether /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/bin/m4 accepts --gnu... yes

checking how m4 supports trace files... --debugfile

checking for a BSD-compatible install... /home/build/tisdk/build/arago-tmp-external-arm-glibc/hosttools/install -c

checking whether build environment is sane... yes

checking for armmllib32-linux-gnueabi-strip... arm-none-linux-gnueabihf-strip

checking for a thread-safe mkdir -p... /home/build/tisdk/build/arago-tmp-external-arm-glibc/hosttools/mkdir -p

checking for gawk... gawk

checking whether make sets $(MAKE)... yes

checking whether make supports nested variables... yes

checking whether make supports nested variables... (cached) yes

checking build system type... x86_64-pc-linux-gnu

checking host system type... Invalid configuration `armmllib32-linux-gnueabi': machine `armmllib32-unknown' not recognized

configure: error: /bin/bash ../libtool-2.4.6/build-aux/config.sub armmllib32-linux-gnueabi failed

WARNING: /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/temp/run.do_configure.29261:1 exit 1 from 'exit 1'

 

ERROR: Logfile of failure stored in: /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/temp/log.do_configure.29261

 

 

Manually running the configure command with –host=arm-none-linux-gnueabihf is working properly.

 

How can I fix the recipe to set –host correctly in this case?

 

Thanks a lot,

 

Nir.

 
Re: multilib32: libtool-cross_2.4.6.bb configure failure

Geller, Nir <nir.geller@...>
 

The variable SYS_HOST is expanded to armmllib32-linux-gnueabi

Shouldn’t it be expanded to arm-none-linux-gnueabihf ?

 

Thanks,

 

Nir.

 

From: yocto@... <yocto@...> On Behalf Of Geller, Nir
Sent: Wednesday, August 11, 2021 4:41 PM
To: yocto@...
Subject: Re: [yocto] multilib32: libtool-cross_2.4.6.bb configure failure

 

Investigating run.do_configure suggests that in the configure stage oe_runconf() is set with what seems to be wrong –host and –target values:

 --host=armmllib32-linux-gnueabi   --target=armmllib32-linux-gnueabi

 

How can I influence oe_runconf() generation and set correct values?

 

From: yocto@... <yocto@...> On Behalf Of Geller, Nir
Sent: Wednesday, August 11, 2021 12:42 PM
To: yocto@...
Subject: [yocto] multilib32: libtool-cross_2.4.6.bb configure failure

 

Hi There,

 

Following the instruction from TI

 

https://software-dl.ti.com/processor-sdk-linux-rt/esd/AM64X/latest/exports/docs/linux/Overview_Building_the_SDK.html

 

I’ve setup a yocto project for the AM64x.

 

Toolchain used is 9.2-2019.12

 

Now I need to add support for multilib32 because I have some software that can be compiled only 32 bit.

 

I added the following lines to conf/local.conf

 

# Define multilib target

require conf/multilib.conf

MULTILIBS = "multilib:lib32"

DEFAULTTUNE_virtclass-multilib-lib32 = "armv7athf-neon"

 

And I am able to build a few packges with lib32- successfully, however, lib32-libtool-cross fails at the configure stage:

 

--host is set to the value armmllib32-linux-gnueabi

 

ERROR: lib32-libtool-cross-2.4.6-r0 do_configure: configure failed

ERROR: lib32-libtool-cross-2.4.6-r0 do_configure: Execution of '/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/temp/run.do_configure.29261' failed with exit code 1:

automake (GNU automake) 1.16.1

Copyright (C) 2018 Free Software Foundation, Inc.

License GPLv2+: GNU GPL version 2 or later <https://gnu.org/licenses/gpl-2.0.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

 

Written by Tom Tromey <tromey@...>

       and Alexandre Duret-Lutz <adl@...>.

AUTOV is 1.16

autoreconf: Entering directory `.'

autoreconf: configure.ac: not using Gettext

autoreconf: running: aclocal --system-acdir=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot/usr/share/aclocal/ --automake-acdir=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/share/aclocal-1.16 -I /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/m4/ -I /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/tests/ -I /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/share/aclocal/ --force --warnings=cross -I m4

aclocal: warning: unknown warning category 'cross'

autoreconf: configure.ac: tracing

autoreconf: running: /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/bin/autoconf --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/m4/ --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/tests/ --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/share/aclocal/ --force --warnings=cross

autoreconf: running: /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/bin/autoheader --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/m4/ --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/tests/ --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/share/aclocal/ --force --warnings=cross

autoreconf: running: automake --add-missing --copy --force-missing --warnings=cross

automake: warning: unknown warning category 'cross'

autoreconf: running: gnu-configize

autoreconf: Leaving directory `.'

| NOTE: Running ../libtool-2.4.6/configure  --build=x86_64-linux                                 --host=armmllib32-linux-gnueabi                   --target=armmllib32-linux-gnueabi                         --prefix=/usr           --exec_prefix=/usr                          --bindir=/usr/bin                             --sbindir=/usr/sbin                              --libexecdir=/usr/libexec                             --datadir=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot/usr/share                      --sysconfdir=/etc                            --sharedstatedir=/com                                 --localstatedir=/var                             --libdir=/usr/lib                               --includedir=/usr/include                                 --oldincludedir=/usr/include                      --infodir=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot/usr/share/info                                 --mandir=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot/usr/share/man                   --disable-silent-rules                      --disable-dependency-tracking                                --with-libtool-sysroot=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot

configure: loading site script /home/build/tisdk/sources/meta-openembedded/meta-networking/site/endian-little

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/endian-little

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/arm-common

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/arm-32

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/common-linux

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/common-glibc

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/arm-linux

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/common

## ------------------------- ##

## Configuring libtool 2.4.6 ##

## ------------------------- ##

 

checking for GNU M4 that supports accurate traces... /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/bin/m4

checking whether /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/bin/m4 accepts --gnu... yes

checking how m4 supports trace files... --debugfile

checking for a BSD-compatible install... /home/build/tisdk/build/arago-tmp-external-arm-glibc/hosttools/install -c

checking whether build environment is sane... yes

checking for armmllib32-linux-gnueabi-strip... arm-none-linux-gnueabihf-strip

checking for a thread-safe mkdir -p... /home/build/tisdk/build/arago-tmp-external-arm-glibc/hosttools/mkdir -p

checking for gawk... gawk

checking whether make sets $(MAKE)... yes

checking whether make supports nested variables... yes

checking whether make supports nested variables... (cached) yes

checking build system type... x86_64-pc-linux-gnu

checking host system type... Invalid configuration `armmllib32-linux-gnueabi': machine `armmllib32-unknown' not recognized

configure: error: /bin/bash ../libtool-2.4.6/build-aux/config.sub armmllib32-linux-gnueabi failed

WARNING: /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/temp/run.do_configure.29261:1 exit 1 from 'exit 1'

 

ERROR: Logfile of failure stored in: /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/temp/log.do_configure.29261

 

 

Manually running the configure command with –host=arm-none-linux-gnueabihf is working properly.

 

How can I fix the recipe to set –host correctly in this case?

 

Thanks a lot,

 

Nir.

 
Re: multilib32: libtool-cross_2.4.6.bb configure failure

Geller, Nir <nir.geller@...>
 

Investigating run.do_configure suggests that in the configure stage oe_runconf() is set with what seems to be wrong –host and –target values:

 --host=armmllib32-linux-gnueabi   --target=armmllib32-linux-gnueabi

 

How can I influence oe_runconf() generation and set correct values?

 

From: yocto@... <yocto@...> On Behalf Of Geller, Nir
Sent: Wednesday, August 11, 2021 12:42 PM
To: yocto@...
Subject: [yocto] multilib32: libtool-cross_2.4.6.bb configure failure

 

Hi There,

 

Following the instruction from TI

 

https://software-dl.ti.com/processor-sdk-linux-rt/esd/AM64X/latest/exports/docs/linux/Overview_Building_the_SDK.html

 

I’ve setup a yocto project for the AM64x.

 

Toolchain used is 9.2-2019.12

 

Now I need to add support for multilib32 because I have some software that can be compiled only 32 bit.

 

I added the following lines to conf/local.conf

 

# Define multilib target

require conf/multilib.conf

MULTILIBS = "multilib:lib32"

DEFAULTTUNE_virtclass-multilib-lib32 = "armv7athf-neon"

 

And I am able to build a few packges with lib32- successfully, however, lib32-libtool-cross fails at the configure stage:

 

--host is set to the value armmllib32-linux-gnueabi

 

ERROR: lib32-libtool-cross-2.4.6-r0 do_configure: configure failed

ERROR: lib32-libtool-cross-2.4.6-r0 do_configure: Execution of '/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/temp/run.do_configure.29261' failed with exit code 1:

automake (GNU automake) 1.16.1

Copyright (C) 2018 Free Software Foundation, Inc.

License GPLv2+: GNU GPL version 2 or later <https://gnu.org/licenses/gpl-2.0.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

 

Written by Tom Tromey <tromey@...>

       and Alexandre Duret-Lutz <adl@...>.

AUTOV is 1.16

autoreconf: Entering directory `.'

autoreconf: configure.ac: not using Gettext

autoreconf: running: aclocal --system-acdir=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot/usr/share/aclocal/ --automake-acdir=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/share/aclocal-1.16 -I /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/m4/ -I /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/tests/ -I /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/share/aclocal/ --force --warnings=cross -I m4

aclocal: warning: unknown warning category 'cross'

autoreconf: configure.ac: tracing

autoreconf: running: /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/bin/autoconf --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/m4/ --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/tests/ --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/share/aclocal/ --force --warnings=cross

autoreconf: running: /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/bin/autoheader --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/m4/ --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/tests/ --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/share/aclocal/ --force --warnings=cross

autoreconf: running: automake --add-missing --copy --force-missing --warnings=cross

automake: warning: unknown warning category 'cross'

autoreconf: running: gnu-configize

autoreconf: Leaving directory `.'

| NOTE: Running ../libtool-2.4.6/configure  --build=x86_64-linux                                 --host=armmllib32-linux-gnueabi                   --target=armmllib32-linux-gnueabi                         --prefix=/usr           --exec_prefix=/usr                          --bindir=/usr/bin                             --sbindir=/usr/sbin                              --libexecdir=/usr/libexec                             --datadir=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot/usr/share                      --sysconfdir=/etc                            --sharedstatedir=/com                                 --localstatedir=/var                             --libdir=/usr/lib                               --includedir=/usr/include                                 --oldincludedir=/usr/include                      --infodir=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot/usr/share/info                                 --mandir=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot/usr/share/man                   --disable-silent-rules                      --disable-dependency-tracking                                --with-libtool-sysroot=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot

configure: loading site script /home/build/tisdk/sources/meta-openembedded/meta-networking/site/endian-little

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/endian-little

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/arm-common

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/arm-32

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/common-linux

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/common-glibc

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/arm-linux

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/common

## ------------------------- ##

## Configuring libtool 2.4.6 ##

## ------------------------- ##

 

checking for GNU M4 that supports accurate traces... /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/bin/m4

checking whether /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/bin/m4 accepts --gnu... yes

checking how m4 supports trace files... --debugfile

checking for a BSD-compatible install... /home/build/tisdk/build/arago-tmp-external-arm-glibc/hosttools/install -c

checking whether build environment is sane... yes

checking for armmllib32-linux-gnueabi-strip... arm-none-linux-gnueabihf-strip

checking for a thread-safe mkdir -p... /home/build/tisdk/build/arago-tmp-external-arm-glibc/hosttools/mkdir -p

checking for gawk... gawk

checking whether make sets $(MAKE)... yes

checking whether make supports nested variables... yes

checking whether make supports nested variables... (cached) yes

checking build system type... x86_64-pc-linux-gnu

checking host system type... Invalid configuration `armmllib32-linux-gnueabi': machine `armmllib32-unknown' not recognized

configure: error: /bin/bash ../libtool-2.4.6/build-aux/config.sub armmllib32-linux-gnueabi failed

WARNING: /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/temp/run.do_configure.29261:1 exit 1 from 'exit 1'

 

ERROR: Logfile of failure stored in: /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/temp/log.do_configure.29261

 

 

Manually running the configure command with –host=arm-none-linux-gnueabihf is working properly.

 

How can I fix the recipe to set –host correctly in this case?

 

Thanks a lot,

 

Nir.

 
Re: #yocto debbuging option under zeus #yocto

Monsees, Steven C (US)
 

 

Is it documented anywhere on how one might manually load debug info an for image with the binaries stripped ?

 

Thanks,

Steve

From: yocto@... <yocto@...> On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Tuesday, August 10, 2021 1:48 PM
To: yocto@...
Subject: [yocto] #yocto debbuging option under zeus

 

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.

 

 

I ran across the following under the Yocto Project Profiling and Tracing Manual, and after checking my ipk data files/layout, I was wondering if someone could tell me, if ipk is capable of performing a similar set of operations to install my debug data ?, and if so, what would be the correct command sequence ?

 

“ The debug packages once built can be found in build/tmp/deploy/rpm/* on the host system. Find the busybox-dbg-...rpm file and copy it to the target. For example:

 

[trz@empanada core2]$ scp /home/trz/yocto/crownbay-tracing-dbg/build/tmp/deploy/rpm/core2_32/busybox-dbg-1.20.2r2.core2_32.rpm root@....31:

     root@....31's password:

     busybox-dbg-1.20.2-r2.core2_32.rpm                     100% 1826KB   1.8MB/s   00:01

 

Now install the debug rpm on the target:

     root@crownbay:~# rpm -i busybox-dbg-1.20.2-r2.core2_32.rpm

“

 

Thanks,

Steve
multilib32: libtool-cross_2.4.6.bb configure failure

Geller, Nir <nir.geller@...>
 

Hi There,

 

Following the instruction from TI

 

https://software-dl.ti.com/processor-sdk-linux-rt/esd/AM64X/latest/exports/docs/linux/Overview_Building_the_SDK.html

 

I’ve setup a yocto project for the AM64x.

 

Toolchain used is 9.2-2019.12

 

Now I need to add support for multilib32 because I have some software that can be compiled only 32 bit.

 

I added the following lines to conf/local.conf

 

# Define multilib target

require conf/multilib.conf

MULTILIBS = "multilib:lib32"

DEFAULTTUNE_virtclass-multilib-lib32 = "armv7athf-neon"

 

And I am able to build a few packges with lib32- successfully, however, lib32-libtool-cross fails at the configure stage:

 

--host is set to the value armmllib32-linux-gnueabi

 

ERROR: lib32-libtool-cross-2.4.6-r0 do_configure: configure failed

ERROR: lib32-libtool-cross-2.4.6-r0 do_configure: Execution of '/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/temp/run.do_configure.29261' failed with exit code 1:

automake (GNU automake) 1.16.1

Copyright (C) 2018 Free Software Foundation, Inc.

License GPLv2+: GNU GPL version 2 or later <https://gnu.org/licenses/gpl-2.0.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

 

Written by Tom Tromey <tromey@...>

       and Alexandre Duret-Lutz <adl@...>.

AUTOV is 1.16

autoreconf: Entering directory `.'

autoreconf: configure.ac: not using Gettext

autoreconf: running: aclocal --system-acdir=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot/usr/share/aclocal/ --automake-acdir=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/share/aclocal-1.16 -I /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/m4/ -I /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/tests/ -I /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/share/aclocal/ --force --warnings=cross -I m4

aclocal: warning: unknown warning category 'cross'

autoreconf: configure.ac: tracing

autoreconf: running: /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/bin/autoconf --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/m4/ --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/tests/ --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/share/aclocal/ --force --warnings=cross

autoreconf: running: /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/bin/autoheader --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/m4/ --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/tests/ --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/share/aclocal/ --force --warnings=cross

autoreconf: running: automake --add-missing --copy --force-missing --warnings=cross

automake: warning: unknown warning category 'cross'

autoreconf: running: gnu-configize

autoreconf: Leaving directory `.'

| NOTE: Running ../libtool-2.4.6/configure  --build=x86_64-linux                                 --host=armmllib32-linux-gnueabi                   --target=armmllib32-linux-gnueabi                         --prefix=/usr           --exec_prefix=/usr                          --bindir=/usr/bin                             --sbindir=/usr/sbin                              --libexecdir=/usr/libexec                             --datadir=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot/usr/share                      --sysconfdir=/etc                            --sharedstatedir=/com                                 --localstatedir=/var                             --libdir=/usr/lib                               --includedir=/usr/include                                 --oldincludedir=/usr/include                      --infodir=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot/usr/share/info                                 --mandir=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot/usr/share/man                   --disable-silent-rules                      --disable-dependency-tracking                                --with-libtool-sysroot=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot

configure: loading site script /home/build/tisdk/sources/meta-openembedded/meta-networking/site/endian-little

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/endian-little

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/arm-common

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/arm-32

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/common-linux

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/common-glibc

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/arm-linux

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/common

## ------------------------- ##

## Configuring libtool 2.4.6 ##

## ------------------------- ##

 

checking for GNU M4 that supports accurate traces... /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/bin/m4

checking whether /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/bin/m4 accepts --gnu... yes

checking how m4 supports trace files... --debugfile

checking for a BSD-compatible install... /home/build/tisdk/build/arago-tmp-external-arm-glibc/hosttools/install -c

checking whether build environment is sane... yes

checking for armmllib32-linux-gnueabi-strip... arm-none-linux-gnueabihf-strip

checking for a thread-safe mkdir -p... /home/build/tisdk/build/arago-tmp-external-arm-glibc/hosttools/mkdir -p

checking for gawk... gawk

checking whether make sets $(MAKE)... yes

checking whether make supports nested variables... yes

checking whether make supports nested variables... (cached) yes

checking build system type... x86_64-pc-linux-gnu

checking host system type... Invalid configuration `armmllib32-linux-gnueabi': machine `armmllib32-unknown' not recognized

configure: error: /bin/bash ../libtool-2.4.6/build-aux/config.sub armmllib32-linux-gnueabi failed

WARNING: /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/temp/run.do_configure.29261:1 exit 1 from 'exit 1'

 

ERROR: Logfile of failure stored in: /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/temp/log.do_configure.29261

 

 

Manually running the configure command with –host=arm-none-linux-gnueabihf is working properly.

 

How can I fix the recipe to set –host correctly in this case?

 

Thanks a lot,

 

Nir.

 
Re: New Override Syntax

Richard Purdie
 

On Wed, 2021-08-11 at 10:18 +0200, Michael Opdenacker wrote:
Hi Richard,

On 8/10/21 10:21 PM, Richard Purdie wrote:
On Tue, 2021-08-10 at 17:51 +0000, Darcy Watkins wrote:
My apologies. I don't think I made my question clear. I am asking about the 
compatibility of old style override syntax moving forward (and new style syntax
in old versions).

So if I continue using the old style override syntax (to ensure sure 
compatibility for use with older Yocto versions), at what future Yocto/OE 
release do you expect that old style override syntax will become erroneous 
(as opposed to say triggering deprecation warnings, etc)?

Is support for the new style override syntax present in any existing 
Yocto/OpenEmbedded releases (in other words, has it been there for a while, 
but we are just now actively migrating to use it)? If so, how far back does it go?
The new syntax will work on the dunfell, gatesgarth, hardknott, master and new 
release branches going forward. That applies now and that support will be in the
next point releases for dunfell (3.1.11) and hardknott (3.3.3).

Thank you for the clarification.

Why do you mention Gatesgarth (3.2) while no update release is in sight?
According to https://wiki.yoctoproject.org/wiki/Releases, it's already
end of life.
I mention is as if I didn't someone would ask about it. I did backport the change
to the corresponding bitbake branch and it hence made it to the poky branch for
gatesgarth but there are no plans for any further 3.2 releases.

Cheers,

Richard
Re: New Override Syntax

Michael Opdenacker
 

Hi Richard,

On 8/10/21 10:21 PM, Richard Purdie wrote:
On Tue, 2021-08-10 at 17:51 +0000, Darcy Watkins wrote:
My apologies. I don't think I made my question clear. I am asking about the 
compatibility of old style override syntax moving forward (and new style syntax
in old versions).

So if I continue using the old style override syntax (to ensure sure 
compatibility for use with older Yocto versions), at what future Yocto/OE 
release do you expect that old style override syntax will become erroneous 
(as opposed to say triggering deprecation warnings, etc)?

Is support for the new style override syntax present in any existing 
Yocto/OpenEmbedded releases (in other words, has it been there for a while, 
but we are just now actively migrating to use it)? If so, how far back does it go?
The new syntax will work on the dunfell, gatesgarth, hardknott, master and new 
release branches going forward. That applies now and that support will be in the
next point releases for dunfell (3.1.11) and hardknott (3.3.3).

Thank you for the clarification.

Why do you mention Gatesgarth (3.2) while no update release is in sight?
According to https://wiki.yoctoproject.org/wiki/Releases, it's already
end of life.

Cheers,
Michael.

--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[meta-zephyr][PATCH 1/2] zephyr-kernel-src: switch to main branch for hal_stm32 module repo

Naveen Saini
 

Signed-off-by: Naveen Saini <naveen.kumar.saini@...>
---
recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
index 950966e..abe755d 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
@@ -12,7 +12,7 @@ SRC_URI = "\
git://github.com/zephyrproject-rtos/zephyr.git;protocol=https;branch=${ZEPHYR_BRANCH};name=default \
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/hal_stm32.git;branch=main;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/openthread.git;protocol=https;branch=zephyr;destsuffix=git/modules/lib/openthread;name=openthread \
--
2.17.1
[meta-zephyr][PATCH 2/2] zephyr-kernel-src-dev.inc: add dev recipe

Naveen Saini
 

It allow to build against latest main branch. User need
to have following config locally to use it.

PREFERRED_VERSION_zephyr-kernel = "dev"

Signed-off-by: Naveen Saini <naveen.kumar.saini@...>
---
.../zephyr-kernel/zephyr-kernel-src-dev.inc | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
create mode 100644 recipes-kernel/zephyr-kernel/zephyr-kernel-src-dev.inc

diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-dev.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-dev.inc
new file mode 100644
index 0000000..da2a5d5
--- /dev/null
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-dev.inc
@@ -0,0 +1,17 @@
+SRCREV_FORMAT = "default_cmsis"
+SRCREV_default = "72bb75a360ce05bfc94ff0fbecda2e2d094e3d84"
+SRCREV_cmsis = "c3bd2094f92d574377f7af2aec147ae181aa5f8e"
+SRCREV_nordic = "00fd2aa97a22ea1052d9dabe1b18ab396daab93a"
+SRCREV_stm32 = "4200321ef1cd27cacc37b0439389424156bb1267"
+SRCREV_open-amp = "6010f0523cbc75f551d9256cf782f173177acdef"
+SRCREV_openthread = "542b14a5bc5b38f29e2cab892c66da670a524b05"
+SRCREV_libmetal = "39d049d4ae68e6f6d595fce7de1dcfc1024fb4eb"
+SRCREV_tinycrypt = "3e9a49d2672ec01435ffbf0d788db6d95ef28de0"
+SRCREV_mbedtls = "5765cb7f75a9973ae9232d438e361a9d7bbc49e7"
+
+ZEPHYR_BRANCH = "main"
+PV = "2.6.0+git${SRCPV}"
+
+SRC_URI:append = " file://0001-cmake-add-yocto-toolchain.patch \
+ file://0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch \
+ "
--
2.17.1
[ANNOUNCEMENT] Yocto Project 3.1.10 (dunfell-23.0.10) is Released

Vineela
 

Hello,

 

We are pleased to announce the Yocto Project 3.1.10 (dunfell-23.0.10) Release is now available for download.

 

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.10/poky-dunfell-23.0.10.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.10/poky-dunfell-23.0.10.tar.bz2

 

A gpg signed version of the release notes is available at:

 

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.10/RELEASENOTES

 

Full Test Report:

 

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.10/testreport.txt

 

Thank you for everyone's contributions to this release.

 

Vineela Tummalapalli

Yocto Project Build and Release

vineela.tummalapalli@...

 

 

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

yocto-3.1.10 Release Notes

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

 

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

Repositories/Downloads

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

 

Repository Name: poky

Repository Location: https://git.yoctoproject.org/git/poky

Branch: dunfell

Tag: yocto-3.1.10

Git Revision: 2a848e95074318f3a243df7b3f40513a13173a82

Release Artefact: poky-dunfell-23.0.10

sha: 8ff647b1de50cc915491765b6c19e9f1430519e7238275d7e012e0183a7c6f7d

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.10/poky-dunfell-23.0.10.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.10/poky-dunfell-23.0.10.tar.bz2

 

Repository Name: openembedded-core

Repository Location: https://git.openembedded.org/openembedded-core

Branch: dunfell

Tag: 2020-04.10-dunfell

Git Revision: 9ae339ace9274be71bfd3b5e5da64dceac9fa963

Release Artefact: oecore-dunfell-23.0.10

sha: 651943e0919c6731441c67460b35b92f592bf60f9509b0be041cacdcb7db838c

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.10/oecore-dunfell-23.0.10.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.10/oecore-dunfell-23.0.10.tar.bz2

 

Repository Name: meta-mingw

Repository Location: https://git.yoctoproject.org/git/meta-mingw

Branch: dunfell

Tag: yocto-3.1.10

Git Revision: 524de686205b5d6736661d4532f5f98fee8589b7

Release Artefact: meta-mingw-dunfell-23.0.10

sha: a2db888019c3e35cf12edda6fc68ae4f9522a2a975a57f492e9f86673dfa5c82

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.10/meta-mingw-dunfell-23.0.10.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.10/meta-mingw-dunfell-23.0.10.tar.bz2

 

Repository Name: meta-gplv2

Repository Location: https://git.yoctoproject.org/git/meta-gplv2

Branch: dunfell

Tag: yocto-3.1.10

Git Revision: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac

Release Artefact: meta-gplv2-dunfell-23.0.10

sha: 97e915d0312fd07a6da3ae0fd21c9463ddeae03bc097b3cfe75234a066bb7045

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.10/meta-gplv2-dunfell-23.0.10.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.10/meta-gplv2-dunfell-23.0.10.tar.bz2

 

Repository Name: bitbake

Repository Location: https://git.openembedded.org/bitbake

Branch: 1.46

Tag: 2020-04.10-dunfell

Git Revision: 0e0af15b84e07e6763300dcd092b980086b9b9c4

Release Artefact: bitbake-dunfell-23.0.10

sha: 99fbb9ecf86385bf1effbde433f95d465c3ab90084b9dc985597220b60b6c0bd

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.10/bitbake-dunfell-23.0.10.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.10/bitbake-dunfell-23.0.10.tar.bz2

 

Repository Name: yocto-docs

Repository Location: https://git.yoctoproject.org/git/yocto-docs

Branch: dunfell

Tag: yocto-3.1.10

Git Revision:180d5fcb893e8b2ebcd779d1b07f5c9e8e1bceca

 

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

Contributors

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

Alexander Kanavin

Andrej Valek

Bruce Ashfield

Chen Qi

Denys Dmytriyenko

Florian Amstutz

Jain Sangeeta

Jasper Orschulko

Khem Raj

Marek Vasut

Michael Halstead

Michael Ho

Minjae Kim

Richard Purdie

Steve Sakoman

Tim Orling

Tomasz Dziendzielski

Yi Zhao

Zoltán Böszörményi

 

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

Known Issues

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

AB-INT PTEST: tcl socket.test intermittent failure

 

 

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

Security Fixes

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

gstreamer-plugins-good: ignore CVE-2021-3497/8 since they are fixed

gstreamer-plugins-base: ignore CVE-2021-3522 since it is fixed

bluez: fix CVE-2021-3588

dhcp: fix CVE-2021-25217

busybox: fix CVE-2021-28831

gstreamer-plugins-base: fix CVE-2021-3522

rpm: fix CVE-2021-3421

libx11: Fix CVE-2021-31535

libxml2: Fix CVE-2021-3518

expat: fix CVE-2013-0340

 

 

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

Fixes

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

bitbake: providers: replace newly added logger.warn() with logger.warning()

bitbake: data_smart: Allow colon in variable expansion regex

bitbake: data_smart/parse: Allow ':' characters in variable/function names

bitbake: BBHandler: Don't classify shell functions that names start with "python*" as python function

poky.conf: Bump version for 3.1.10 release

documentation: prepare for 3.1.10 release

kernel-devsrc: fix 32bit ARM devsrc builds

linux-yocto/5.4: update to v5.4.132

linux-yocto/5.4: update to v5.4.131

busybox: add tmpdir option into mktemp applet

sstate: Drop pseudo exclusion

pseudo: Update to latest version including statx fix

pseudo: Add uninative configuration sanity check

report-error: Drop pointless inherit

update-rc.d: update SRCREV to pull in fix for non-bash shell support

tzdata: Allow controlling zoneinfo binary format

oeqa/selftest/multiprocesslauch: Fix test race

dwarfsrcfiles: Avoid races over debug-link files

bootchart2: update 0.14.8 -> 0.14.9

glibc: update to lastest 2.31 release HEAD

webkitgtk: Upgrade to 2.28.4

webkitgtk: upgrade 2.28.2 -> 2.28.3

python3: upgrade 3.8.10 -> 3.8.11

oeqa/selftest/archiver: Allow tests to ignore empty directories

devtool: deploy-target: Fix preserving attributes when using --strip

sstate/staging: Handle directory creation race issue

oeqa/selftest/runcmd: Tweal test timeouts

sstate.bbclass: fix errors about read-only sstate mirrors

package_pkgdata: Avoid task hash mismatches for generic task changes

perf: Use python3targetconfig to ensure we use target libraries

selftest: do not hardcode /tmp/sdk

kernel-devicetree: Fix interaction when packaging disabled

kernel: Fix interaction when packaging disabled

linux-yocto/5.4: update to v5.4.129

linux-yocto/5.4: update to v5.4.128

linux-yocto/5.4: update to v5.4.125

linux-yocto/5.4: update to v5.4.124

python3: apply test skipping patch unconditionally

python3: skip tests requiring tools-sdk

python3-ptest: add newly discovered missing rdeps

python3: upgrade 3.8.9 -> 3.8.10

python3: upgrade 3.8.8 -> 3.8.9

powertop: fix aclocal error too many loops

python3: upgrade 3.8.7 -> 3.8.8

python3: upgrade 3.8.6 -> 3.8.7

python3: upgrade 3.8.5 -> 3.8.6

python3: upgrade 3.8.4 -> 3.8.5

python3: upgrade 3.8.3 -> 3.8.4

python3: upgrade 3.8.2 -> 3.8.3

uninative: Upgrade to 3.2 (gcc11 support)
Re: New Override Syntax

Richard Purdie
 

On Tue, 2021-08-10 at 17:51 +0000, Darcy Watkins wrote:
My apologies. I don't think I made my question clear. I am asking about the 
compatibility of old style override syntax moving forward (and new style syntax
in old versions).

So if I continue using the old style override syntax (to ensure sure 
compatibility for use with older Yocto versions), at what future Yocto/OE 
release do you expect that old style override syntax will become erroneous 
(as opposed to say triggering deprecation warnings, etc)?

Is support for the new style override syntax present in any existing 
Yocto/OpenEmbedded releases (in other words, has it been there for a while, 
but we are just now actively migrating to use it)? If so, how far back does it go?
The new syntax will work on the dunfell, gatesgarth, hardknott, master and new 
release branches going forward. That applies now and that support will be in the
next point releases for dunfell (3.1.11) and hardknott (3.3.3).

The old syntax is no longer supported in master as of now and will not be supported
in new releases going forward. It continues to work fine in older releases prior
to the next new release series (honister).

Cheers,

Richard
Re: [meta-rockchip][PATCH] rockchip-gpt-img: fix for new override syntax

Trevor Woerner
 

On Fri, Aug 6, 2021 at 12:56 PM Trevor Woerner <twoerner@...> wrote:
It looks like I missed a case for the new bitbake override syntax. My tests
weren't done from a fresh build so either a preexisting image was still
available, or the unfixed syntax caused a race.

Signed-off-by: Trevor Woerner <twoerner@...>
---
 classes/rockchip-gpt-img.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

applied to meta-rockchip, master 
Yocto Technical Team Minutes, Engineering Sync, for August 10, 2021

Trevor Woerner
 

Yocto Technical Team Minutes, Engineering Sync, for August 10, 2021
archive: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit

== disclaimer ==
Best efforts are made to ensure the below is accurate and valid. However,
errors sometimes happen. If any errors or omissions are found, please feel
free to reply to this email with any corrections.

== attendees ==
Trevor Woerner, Stephen Jolley, Saul Wold, Jan-Simon Möller, Armin Kuster,
Michael Opdenacker, Michael Halstead, Steve Sakokan, Randy MacLeod, Richard
Purdie, Paul Barker, Tony Tascioglu, Jon Mason, Angolini, Alexandre
Belloni, Richard Elberger, David Reyna

== project status ==
- 3.3.2 (hardknott) was released
- 3.1.10 (dunfell) to be released imminently
- bitbake’s new override syntax is now in and is part of honister
- there was 1 bugfix related to override syntax
- 2 long-standing bugs fixed (devupstream class and LTO)
- prserv coming along
- AB-INT issues around ptests still persist
- multiconfig changes in master-next, please test

== discussion ==
RP: one critical fix for the override syntax so far, but relatively smooth
with positive feedback (in general). working through the backlog caused by
the conversion (e.g. LTO patches, odd bugs in bitbake, task explorer UI on
an empty directory). load of patches in master-next (e.g. esdk bug)

DavidR: re: ELC. we are getting a booth (both physical and virtual). looking
for volunteers to be at the booth (physically) during ELC. also, YPS
coming later in the Fall

Jon: can we move TUNES now?
RP: sounds like a reasonable time to do it now. but reluctant to break
everything again. i’ll double-check, but it probably makes sense now.
the python2 to python3 migration was bad for many users so i don’t want
a repeat of that mess, but i think the TUNES change should be easier. did
you have something in mind?
Jon: i want to move the CortexMs to core, but maybe reshuffle the CortexA ones
too. there are also some x86 ones that could be cleaned up too
RP: this change will cause loud errors, so this would be obvious to users

Saul: re: SBOM work with JPEW. Joshua submitted a patch to integrate more of
the meta-doubleopen layer to oe-core. there were discussions regarding
changes to the packager.
RP: i don’t remember that discussion
Saul: fetcher and archiver. we can discuss more in IRC. meta-doubleopen did a
mirror checkout and patch (archiver) which is different than the oe-core
archiver. we’ll go digging into that.
RP: wanted to change the way the fetcher unpacks instead of just dumping into
workdir, but it messes up devtool. remind me on IRC and i’ll dig up the
patch for you

Randy: re: meta-rust merge to oe-core. ~35 commits to pull in. will have
something pushed to poky-contrib later this week

RP: the prserv work is paused right now, and there are a couple other patches
for m3. but if anyone else is working on anything else please let me know

Randy: there was a Go bug that a co-worker was working on, but was unable to
reproduce. maybe something about Go accessing the web during the build?
RP: Go-mod-dep. i think there’s an sdk failure and a failure somewhere else
that suggests Go is trying to access the net. try doing a build locally
and killing the default route (for example) to see if you can reproduce

RP: I’m hoping Tony has a valgrind patch for me
Randy: is he working on that?
Tony: is there a ptest we were going to skip?
RP: glibc-4 work
Randy: where?
RP: master-next. we can exclude them now, but fix them up in due course

Randy: re: swat team (to AlexB)
AlexB: yes, i haven’t moved on it yet but will before Thursday.
Randy: the intent is to make the swat team more effective and coordinate the
reporting tools on the AB?
AlexB: yes
Re: New Override Syntax

Michael Opdenacker
 

Hi Darcy,

On 8/10/21 7:51 PM, Darcy Watkins wrote:
Hi,

My apologies. I don't think I made my question clear. I am asking about the compatibility of old style override syntax moving forward (and new style syntax in old versions).

So if I continue using the old style override syntax (to ensure sure compatibility for use with older Yocto versions), at what future Yocto/OE release do you expect that old style override syntax will become erroneous (as opposed to say triggering deprecation warnings, etc)?
If I understood correctly, the old style will continue to be supported
in 3.1 and in 3.3, as long as these releases are supported (that's what
I'm trying to find out). These versions will support both syntaxes
actually.

However, from 3.4 on, only the new syntax will be supported.


Is support for the new style override syntax present in any existing Yocto/OpenEmbedded releases (in other words, has it been there for a while, but we are just now actively migrating to use it)? If so, how far back does it go?

No, we don't have any releases yet with the new syntax. The next dot
update to Dunfell is planned on 2021/9/24, and that's when you'll have a
release with both syntaxes supported. Dunfell is supposed to be
supported for at least 2 years, that is until Apr. 2022.

Cheers,
Michael.

--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Re: New Override Syntax

Darcy Watkins
 

Hi,

My apologies. I don't think I made my question clear. I am asking about the compatibility of old style override syntax moving forward (and new style syntax in old versions).

So if I continue using the old style override syntax (to ensure sure compatibility for use with older Yocto versions), at what future Yocto/OE release do you expect that old style override syntax will become erroneous (as opposed to say triggering deprecation warnings, etc)?

Is support for the new style override syntax present in any existing Yocto/OpenEmbedded releases (in other words, has it been there for a while, but we are just now actively migrating to use it)? If so, how far back does it go?


Regards,

Darcy

Darcy Watkins :: Senior Staff Engineer, Firmware

SIERRA WIRELESS
Direct +1 604 233 7989 :: Fax +1 604 231 1109 :: Main +1 604 231 1100
13811 Wireless Way :: Richmond, BC Canada V6V 3A4
[M4]
dwatkins@... :: www.sierrawireless.com <http://www.sierrawireless.com/>

On 2021-08-10, 10:17 AM, "Michael Opdenacker" <michael.opdenacker@...> wrote:

Hi again Darcy,

On 8/10/21 6:35 PM, Michael Opdenacker wrote:
> Where can we find until when the current releases are going to be
> supported? Such information doesn't appear on
> https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.yoctoproject.org%2Fwiki%2FReleases&;data=04%7C01%7Cdwatkins%40sierrawireless.com%7C672b1b0d748041f1a5e108d95c22b3d0%7C08059a4c248643dd89e33a747e0dcbe8%7C1%7C0%7C637642126398105344%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=yqtJtouZsl7JBRtIfvYrRNmNAIa40d5vyk5%2BZl0sy7g%3D&amp;reserved=0

I haven't managed to get such information yet, so I opened a bug to make
sure I get an answer by Thursday, when we have our bug triage meeting.

Here's the bug: https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.yoctoproject.org%2Fshow_bug.cgi%3Fid%3D14503&;data=04%7C01%7Cdwatkins%40sierrawireless.com%7C672b1b0d748041f1a5e108d95c22b3d0%7C08059a4c248643dd89e33a747e0dcbe8%7C1%7C0%7C637642126398105344%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=cyIznH%2F%2B%2BPzccxcue710LByZiJGI9tx7%2B4fiyLK6Ba8%3D&amp;reserved=0
Don't hesitate to subscribe to it.

Cheers
Michael.

--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbootlin.com%2F&;data=04%7C01%7Cdwatkins%40sierrawireless.com%7C672b1b0d748041f1a5e108d95c22b3d0%7C08059a4c248643dd89e33a747e0dcbe8%7C1%7C0%7C637642126398105344%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=N2uSry78vScI0moDWsDvzJCT53avVXzvIBoY9P9Vn7U%3D&amp;reserved=0
#yocto debbuging option under zeus #yocto

Monsees, Steven C (US)
 

 

I ran across the following under the Yocto Project Profiling and Tracing Manual, and after checking my ipk data files/layout, I was wondering if someone could tell me, if ipk is capable of performing a similar set of operations to install my debug data ?, and if so, what would be the correct command sequence ?

 

“ The debug packages once built can be found in build/tmp/deploy/rpm/* on the host system. Find the busybox-dbg-...rpm file and copy it to the target. For example:

 

[trz@empanada core2]$ scp /home/trz/yocto/crownbay-tracing-dbg/build/tmp/deploy/rpm/core2_32/busybox-dbg-1.20.2r2.core2_32.rpm root@....31:

     root@....31's password:

     busybox-dbg-1.20.2-r2.core2_32.rpm                     100% 1826KB   1.8MB/s   00:01

 

Now install the debug rpm on the target:

     root@crownbay:~# rpm -i busybox-dbg-1.20.2-r2.core2_32.rpm

“

 

Thanks,

Steve
Re: New Override Syntax

Michael Opdenacker
 

Hi again Darcy,

On 8/10/21 6:35 PM, Michael Opdenacker wrote:
Where can we find until when the current releases are going to be
supported? Such information doesn't appear on
https://wiki.yoctoproject.org/wiki/Releases
I haven't managed to get such information yet, so I opened a bug to make
sure I get an answer by Thursday, when we have our bug triage meeting.

Here's the bug: https://bugzilla.yoctoproject.org/show_bug.cgi?id=14503
Don't hesitate to subscribe to it.

Cheers
Michael.

--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
5841 - 5860 of 60181