Date   

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


Re: yocto 3.1.3 cant seem to remove run-postinsts

Michael Opdenacker
 

Hi Jared,

On 8/10/21 4:46 PM, jared_terry@... wrote:
https://www.yoctoproject.org/docs/3.1.3/ref-manual/ref-manual.html#migration-2.1-miscellaneous-changes
<https://www.yoctoproject.org/docs/3.1.3/ref-manual/ref-manual.html#migration-2.1-miscellaneous-changes>

IMAGE_FEATURES="debug-tweaks read-only-rootfs"

according to the manual having read-only-rootfs should remove
run-postinsts and I still have it.  How can I get rid of this?

That's not what I understand from the manual. From
https://docs.yoctoproject.org/dev-manual/common-tasks.html#post-installation-scripts-and-read-only-root-filesystem,
I understand that the build system makes sure that the post install
scripts all succeed, so there is no need to run them again on the target.

Why would you want to skip the post install scripts?

Cheers,
Michael.

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


Re: New Override Syntax

Michael Opdenacker
 

Hi Darcy,

On 8/10/21 6:16 PM, Darcy Watkins wrote:

Hi,

 

Does anyone know how long (or how many releases) that the old override
syntax will still be supported?  (Like a deprecation EOL cycle).

 

A corollary question: How far back in old releases is the new syntax
supported?

 

This potentially affects layers that have a single branch that support
multiple versions of Yocto/OE.
IANTM (I Am Not The Maintainers!), but I know that the old override
syntax will be supported in the maintained releases as long as they are
supported:

* Dunfell 3.1, Long Term Support
* Gatesgarth 3.2, now reaching end of life as written on
https://wiki.yoctoproject.org/wiki/Releases
* Hardknott 3.3, the latest version, still supported.

I know I haven't replied to your first question yet, so here's a
question for other people on the list...

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

To reply to your second question, I believe the new syntax will be
supported in the upcoming updates to  Dunfell 3.1, Gatesgarth 3.2
(provided an update release is made), Hardknott 3.3 and of course in the
upcoming Honister 3.4 release.

I hope this helps. I'm trying to get an answer to the end-of-life question.

Cheers,
Michael.

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


New Override Syntax

Darcy Watkins
 

Hi,

 

Does anyone know how long (or how many releases) that the old override syntax will still be supported?  (Like a deprecation EOL cycle).

 

A corollary question: How far back in old releases is the new syntax supported?

 

This potentially affects layers that have a single branch that support multiple versions of Yocto/OE.

 

Thanks!

 

 

 

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


yocto 3.1.3 cant seem to remove run-postinsts

jared_terry@...
 

https://www.yoctoproject.org/docs/3.1.3/ref-manual/ref-manual.html#migration-2.1-miscellaneous-changes

IMAGE_FEATURES="debug-tweaks read-only-rootfs"

according to the manual having read-only-rootfs should remove run-postinsts and I still have it.  How can I get rid of this?

local.conf:   PACKAGE_EXCLUDE = "run-postinsts"

This didn't do anything either.


Yocto Project Status WW32`21

Stephen Jolley
 

Current Dev Position: YP 3.4 M3

Next Deadline: 23rd Aug. 2021 YP 3.4 M3 build (Feature Freeze)

 

Next Team Meetings:

 

Key Status/Updates:

  • YP 3.3.2 was released
  • YP 3.1.10 is due to be released imminently
  • OE-Core has moved to the new override syntax and is now only compatible with the honister release series. Other layers will need to migrate to the new syntax to work with it. There is documentation about handling migration to the new syntax in the migration section of the manual:

http://docs.yoctoproject.org/migration-guides/migration-3.4.html#override-syntax-changes

  • There has been at least one important bug fix to the overrides syntax change in OE-Core but in general layers do seem to be migrating over and there has been a lot of positive feedback about making this change from a readability perspective. Some additional variables were converted for consistency too.
  • In the last week long standing bugs were fixed, such as being able to use the devupstream class with natively extended recipes, some bitbake hangs in unusual situations with cleanups to the error paths around this and improvements to LTO with regard to binary reproducibility. 
  • The prserv rewrite is making progress but still has some issues with python asyncio.
  • Intermittent issues are ongoing, particularly ptest ones. Help is very much welcome on these issues. You can see the list of failures we’re continuing to see by searching for the “AB-INT” tag in bugzilla: https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT
  • The multiconfig changes pending in master-next for a long time were merged as the approach used is better overall. If anyone still sees multiconfig scheduling bugs, please report those.

 

Ways to contribute:

 

YP 3.4 Milestone Dates:

  • YP 3.4 M3 build date 2021/08/23 (Feature Freeze)
  • 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.2 is released
  • YP 3.1.10 is out of QA.
  • 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@...

 


M+ & H bugs with Milestone Movements WW32

Stephen Jolley
 

All,

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

Priority

Bug ID

Short Description

Changer

Owner

Was

Became

Medium+

12090

bitbake resident server reconnect handling needed

richard.purdie@...

richard.purdie@...

3.4 M3

3.99

 

13768

base-files do_package fatal error in subprocess

randy.macleod@...

mingli.yu@...

3.4 M2

3.4 M3

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Enhancements/Bugs closed WW32!

Stephen Jolley
 

All,

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

Who

Count

richard.purdie@...

13

michael.opdenacker@...

2

Grand Total

15

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


What is the best way to get Environment variables setup in my shell script for export PATH?

JH
 

Hi,

Please correct me, but I think the system environment set up in Yocto
Linux may not be the same as other distributions. I have a shell
script to set up export PATH and LD_LIBRARY_PATH, I want to avoid
putting full path in ExecStart and all of my shell scripts

ExecStart=my_measurement.sh

I have been thinking of the following options, but I am not sure which
one works, if the syntax is correct or not, which one is the best for
common practice, appreciate your advice.

(1) Setup in all systemd service scripts

[Service]
EnvironmentFile=/usr/bin/my_export.sh
ExecStart=my_measurement.sh

Is the syntax above statements in service scripts correct? Will it work?

(2) Add my_export.sh to /etc/profile.d

That one works for Ubuntu, Debian and CentOS, will all Yocto systemd
service scripts pick up environment setup from /etc/profile.d
automatically in Yocto Linux distribution?

(3) Add my_export.sh to /etc/default

Some distributions automatically pick setup from /etc/default, does it
work for Yocto Linux for systemd service scripts to pick up
my_export.sh setup from /etc/default?

Thank you.

Kind regards,

- jupiter

3481 - 3500 of 57813