yocto@lists.yoctoproject.org

Re: same build for multiple machine configurations

Khem Raj

#56210

On Wed, Feb 16, 2022 at 1:36 AM Alexandru Ionita
<alexandru.ionita@gmail.com> wrote:


Hello all,

I'm not sure if this is even possible at all. I'm using the meta-raspberry layer to build raspberry images. Whilst I'm able to build images by strictly selecting a raspberry pi machine configuration (MACHINE=raspberrypi3), I would like to know if it's possible to build an image that is compatible with multiple raspberry pi machine configurations. For instance an image that would work for both raspberrypi3 and raspberrypi4.
I think you can share maximum by using same tunes perhaps for pi3 and
pi4 machines but we do not generate single images which will work
across multiple SOCs.

Thanks.
Alex

Interesting discussion on github relating to branch (re)naming

K1AY <challinan@...>

#56209

https://github.com/fsnotify/fsnotify/issues/426

I discovered the issue while building something on Warrior. Yeah, I know it's been fixed a couple weeks ago in Yocto, but it brings up a bigger point of discussion.

Thought some of you might want to know if you haven't come across the issue yet.

Cheers!

Chris

Re: Yocto Zeus -docker/PREEMPT_RT

Leon Woestenberg

#56208

Hello Steven,

Last entry, from July 2021, in this blog says not supported;
Docker for RTOS? - General Discussions / Feature Requests - Docker Community ForumsNo, that remark is completely wrong and is mixing up things.
"RTLinux" has nothing to do with the mainstream Linux kernel (except
that RTLinux can run the Linux kernel underneath)
Forget about those remarks.

Mainstream Linux is now almost fully-featured with the PREEMPT_RT work
merged, and the Linux kernel can be configured as an RTOS capable
kernel.
There is more to hard real-time than just the kernel, but that is the
kernel part.

I would see *no reason* why Docker should not run on Linux, even when
preemptive realtime is enabled.
In contrast when searching for the PREEMPT_RT / Docker combination I
see successful results.

What is probably the cause for Docker not working, is that the kernel
configuration for the PREEMPT_RT a.k.a. "-rt" kernel in Yocto does not
enable all name space support and other capabilities that Docker
depends on.

I would start comparing .config files at this point, together with the
debug/log output of Docker.
Especially first learn which CONFIG_ options Docker depends on.

Regards,

--
Leon Woestenberg
leon@sidebranch.com
M: +31 6 472 30 372

Sidebranch Embedded Systems
Eindhoven, The Netherlands
http://www.sidebranch.com

On Wed, Feb 16, 2022 at 1:15 PM Monsees, Steven C (US) via
lists.yoctoproject.org
<steven.monsees=baesystems.com@lists.yoctoproject.org> wrote:

I have 2 platforms one with a standard kernel the other using PREEMPT_RT kernel… both work as expected.

All things being equal, when I add docker container support to both platforms, the standard kernel works just fine, but on the

PREEMPT_RT kernel docker does not appear to initialize/work correctly…

I have also tested using both ARM & Intel based HW, and appear tosee the same behavior on both.

Checking online it appears there is chatter about whether docker will run correctly under a PREEMPT_RT kernel.

Example:

Under Yocto, will docker & PREEMPT_RT kernels function correctly, is this combination supported ?

 >
I am currently running zeus based platforms, docker is at version 19.03.2-ce.

Is there a patch to correct for the compatibility issues being seen ?, or

Is there a yocto version I might move to which supports both correctly ?

Any input on this would be greatly appreciated.

Thanks,

Steve

Yocto Zeus -docker/PREEMPT_RT

Monsees, Steven C (US)

#56207

I have 2 platforms one with a standard kernel the other using PREEMPT_RT kernel… both work as expected.

All things being equal, when I add docker container support to both platforms, the standard kernel works just fine, but on the

PREEMPT_RT kernel docker does not appear to initialize/work correctly…

I have also tested using both ARM & Intel based HW, and appear tosee the same behavior on both.

Checking online it appears there is chatter about whether docker will run correctly under a PREEMPT_RT kernel.

Example:

Last entry, from July 2021, in this blog says not supported;

Docker for RTOS? - General Discussions / Feature Requests - Docker Community Forums

Under Yocto, will docker & PREEMPT_RT kernels function correctly, is this combination supported ?

I am currently running zeus based platforms, docker is at version 19.03.2-ce.

Is there a patch to correct for the compatibility issues being seen ?, or

Is there a yocto version I might move to which supports both correctly ?

Any input on this would be greatly appreciated.

Thanks,

Steve

same build for multiple machine configurations

Alexandru Ionita

#56206

Hello all,

I'm not sure if this is even possible at all. I'm using the meta-raspberry layer to build raspberry images. Whilst I'm able to build images by strictly selecting a raspberry pi machine configuration (MACHINE=raspberrypi3), I would like to know if it's possible to build an image that is compatible with multiple raspberry pi machine configurations. For instance an image that would work for both raspberrypi3 and raspberrypi4.

Thanks.

Alex

Re: [OE-core] [qa-build-notification] QA notification for completed autobuilder build (yocto-3.1.14.rc1)

Richard Purdie

#56205

On Tue, 2022-02-15 at 12:46 +0000, Teoh, Jay Shen wrote:
Hi All,

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

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

No new issue found.Thanks for testing! The TSC did discuss this today and agreed it should be good
to release.

Cheers,

Richard

Yocto Project Status WW07`22

Stephen Jolley

#56204

Current Dev Position: YP 3.5 M3

Next Deadline: 21th Feb. 2022 YP 3.5 M3 build

Next Team Meetings:

Bug Triage meeting Thursday Feb. 17th 7:30 am PDT (https://zoom.us/j/454367603?pwd=ZGxoa2ZXL3FkM3Y0bFd5aVpHVVZ6dz09)
Monthly Project Meeting Tuesday Mar. 1st at 8 am PDT (https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09 )
Weekly Engineering Sync Tuesday Feb. 15th at 8 am PDT (https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09 )
Twitch - See https://www.twitch.tv/theyoctojester

Key Status/Updates:

Next week is feature freeze for 3.5, our next LTS release
YP 3.1.14 passed QA and is due to be released
YP 3.2.4 rc2 is in QA (rc1 had sstate networking issues)
We’re extremely worried about the inclusive language changes since these are not anywhere near ready and the freeze deadline is in days. This is an important topic but sadly we’re simply starved of people with the right time and skills to spend on it. There is an email on the openembedded-architecture list about this.
The autobuilder infrastructure is planned to be offline 26-28th February for a data center move. Public services like the website, wiki and git servers will remain live but the git backend (push.yoctoproject.org) will be offline, as will the downloads and sstate services and the autobuilder/NAS.
We’ve upgraded to the new glibc version and have patches in testing for the new binutils release assuming some minor issues there are resolved.
There are changes proposed to the bitbake git fetcher handling of tags. We resolve these against the upstream repositories and the caching of the values was showing issues such as network accesses in the unpack task. We advice against using tags due to the potential for them to change, any layers using them may seen error messages depending on whether their usage is problematic.
Intermittent issues continue to be at record high levels and help is very much welcome in trying to resolve them. 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

In particular, we’re struggling to understand the intermittent network issue with external hosts we’re seeing very occasionally.

Ways to contribute:

There are bugs identified as possible for newcomers to the project: https://wiki.yoctoproject.org/wiki/Newcomers
There are bugs that are currently unassigned for YP 3.5. See: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_3.5_Unassigned_Enhancements.2FBugs
We’d welcome new maintainers for recipes in OE-Core. Please see the list at: http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/distro/include/maintainers.inc and discuss with the existing maintainer, or ask on the OE-Core mailing list. We will likely move a chunk of these to “Unassigned” soon to help facilitate this.
Help us resolve CVE issues: CVE metrics

YP 3.5 Milestone Dates:

YP 3.5 M3 build date 2022/02/21
YP 3.5 M3 Release date 2022/03/04
YP 3.5 M4 build date 2022/04/04
YP 3.5 M4 Release date 2022/04/29

Upcoming dot releases:

YP 3.1.14 is out of QA
YP 3.4.2 is in QA
YP 3.4.2 Release date 2022/02/18
YP 3.3.5 build date 2022/02/14
YP 3.3.5 Release date 2022/02/25
YP 3.1.15 build date 2022/03/14
YP 3.1.15 Release date 2022/03/25
YP 3.4.3 build date 2022/03/21
YP 3.4.3 Release date 2022/04/01
YP 3.3.6 build date 2022/03/28
YP 3.3.6 Release date 2022/04/08
YP 3.1.16 build date 2022/04/25
YP 3.1.16 Release date 2022/05/06

Tracking Metrics:

WDD 2662 (last week 2665) (https://wiki.yoctoproject.org/charts/combo.html)
OE-Core/Poky Patch Metrics

Total patches found: 1208 (last week 1213)
Patches in the Pending State: 334 (28%) [last week 338 (28%)]

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

gpsd bbappend adding new file causing QA errors even with FILES_${PN}:append set

mattwood2000@...

#56203

Hi,

I've seen many questions about this with proposed answers but I cannot
seem to get this to work for my bbappend to gpsd.

I'm simply trying to add an additional systemd service file I created
for the gpspipe client.

What is strange is that I'm already appending the
${systemd_system_unitdir} in this bbappend to replace gpsd.socket with
no error.

I'm confused why adding one additional file to a directory that is
already being appended could cause the QA error:
ERROR: gpsd-3.23.1-r0 do_package: QA Issue: gpsd: Files/directories
were installed but not shipped in any package:
  /lib/systemd/system/gpspipe.service

The recipe is below - I've commented out the three lines that cause
the error.  Anyone have any ideas why this is happening?

Thanks, Matt.

gpsd_%.bbappend:

FILESEXTRAPATHS:prepend := "${THISDIR}/files:"

SRC_URI += "\
        file://gpsd.default \
        file://gpsd.socket \
        file://gpspipe.service \
    "

inherit systemd
SYSTEMD_PACKAGES = "${PN}"
SYSTEMD_AUTO_ENABLE = "enable"
SYSTEMD_SERVICE_${PN}:append = " gpsd.service gpsd.socket gpspipe.service "

do_install:append () {
    install -d ${D}${sysconfdir}/default/
    install -d ${D}${sysconfdir}/systemd/system/multi-user.target.wants/
    install -d ${D}${sysconfdir}/systemd/system/sockets.target.wants/

    install -D -m 600 ${WORKDIR}/gpsd.default ${D}${sysconfdir}/default/
    install -D -m 600 ${WORKDIR}/gpsd.socket ${D}${systemd_system_unitdir}
#    install -D -m 600 ${WORKDIR}/gpspipe.service ${D}${systemd_system_unitdir}

    ln -s ${systemd_unitdir}/system/gpsd.service
${D}${sysconfdir}/systemd/system/multi-user.target.wants/gpsd.service
    ln -s ${systemd_unitdir}/system/gpsd.socket
${D}${sysconfdir}/systemd/system/sockets.target.wants/gpsd.socket
#    ln -s ${systemd_unitdir}/system/gpspipe.service
${D}${sysconfdir}/systemd/system/multi-user.target.wants/gpspipe.service
}

FILES_${PN}:append = " \
            ${sysconfdir}/systemd/system/multi-user.target.wants \
            ${sysconfdir}/systemd/system/sockets.target.wants \
            ${sysconfdir}/default/gpsd.default \
            ${systemd_system_unitdir}/gpsd.socket \
#            ${systemd_system_unitdir}/gpspipe.service \
        "

Best laptop for compiling Yocto

Greg Wilson-Lindberg

#56202

Hello All,

I have a System 76 Serval laptop that I have been using when building Yocto. It seems to be dying and they are on back order now, so not available for replacement. I was wondering what recommendations others would have for a good laptop to use for building Yocto?

Regards,

Greg

Re: [linux-yocto] Controlling features enable/disable across recipe and meta layers ?

Alexander Kanavin

#56201

You need to define several distributions (e.g. several
conf/distro/something.conf files), then you can set DISTRO_FEATURES
accordingly in each of them, and then on the recipe level
PACKAGECONFIGs can be enabled subject to DISTRO_FEATURES. Note that
each of those .conf files can include the same .inc, where the common
parts go, and only differ in things that need to be different.

Yocto does not provide a way to have different 'products' or 'builds'
inside the same distro: you choose a distro, then you choose a target
MACHINE (e.g. the hardware), then you choose the image to build.

Also, distro definitions do not belong in a BSP layer, they need to go
to a separate distro layer. You can ask your colleagues at QC how this
was cleaned up for a certain big german automotive customer and look
at the resulting layer code.

Alex

Show quoted text

On Tue, 15 Feb 2022 at 16:05, Pintu Agarwal <pintu.ping@gmail.com> wrote:

Hi,

I have many questions about Yocto features.
My main question is: In Yocto what is the best mechanism to define a
feature flag such that it can be accessed across many layers and
recipes ?

We are using Yocto thud and/or dunfell at this moment for 2 different products.

From the Yocto document also it is not very clear which one to use.
Also, we are confused when one to use when, like we have:
DISTRO Feature flag,
PACKAGECONFIG variable,
IMAGE Feature,
Global Macro (setVar, getVar), etc.

Example:
Currently, we have many different releases and many different products use it.
So, we have many distro features, many of them are common and many of
them we defined newly for our product.
But for our product we have only one component (say: auto-prod).
So, when this component is enabled the same release should be built
for our product including our feature set.
And when this component is disabled, all our features should be
disabled like mainline release.

So, we wanted to define only one DISTRO feature (auto-prod) and list
all our features under this distro.
Also we wanted to control all these from a single place, so that
enabling/disabling all the features in one shot would be easy and
portable.
We tried doing it using PACKAGECONFIG but it seems this option can be
used only at a recipe level and not visible across all layers.

We wanted to do something like this in: auto.conf
DISTRO_FEATURES = "auto-prod"
if defined (distro-features == auto-prod) ; then
     PACKAGECONFIG_append-pn-<recipe1> = "f1 f2 ..."
     PACKAGECONFIG_append-pn-<recipe2> = "f2 f3 ..."
     PACKAGECONFIG_append-pn-<recipe3> = "f1 f3 f4..."
fi

So, if we comment DISTRO_FEATURES all the features listed above should
be automatically disabled.

Note, our feature flags are used across multiple recipes and layers.
Bootloader layer, Kernel, meta layer, recipe layer, python source, C
source, scripts, etc.
Like: edk2, meta-qti-bsp, meta-security, meta-qti-auto, auto-prod-folder, etc.

Is there a well defined way in Yocto to achieve such a modular design approach ?

If there are any such references please share.

Our reference distro is here:
https://source.codeaurora.org/quic/le/meta-qti-bsp/tree/conf/distro/auto.conf?h=yocto.lnx.3.0.c28

Thanks,
Pintu

Re: Controlling features enable/disable across recipe and meta layers ?

Pintu Agarwal

#56200

Hi,

I have many questions about Yocto features.
My main question is: In Yocto what is the best mechanism to define a
feature flag such that it can be accessed across many layers and
recipes ?

We are using Yocto thud and/or dunfell at this moment for 2 different products.

From the Yocto document also it is not very clear which one to use.
Also, we are confused when one to use when, like we have:
DISTRO Feature flag,
PACKAGECONFIG variable,
IMAGE Feature,
Global Macro (setVar, getVar), etc.

Example:
Currently, we have many different releases and many different products use it.
So, we have many distro features, many of them are common and many of
them we defined newly for our product.
But for our product we have only one component (say: auto-prod).
So, when this component is enabled the same release should be built
for our product including our feature set.
And when this component is disabled, all our features should be
disabled like mainline release.

So, we wanted to define only one DISTRO feature (auto-prod) and list
all our features under this distro.
Also we wanted to control all these from a single place, so that
enabling/disabling all the features in one shot would be easy and
portable.
We tried doing it using PACKAGECONFIG but it seems this option can be
used only at a recipe level and not visible across all layers.

We wanted to do something like this in: auto.conf
DISTRO_FEATURES = "auto-prod"
if defined (distro-features == auto-prod) ; then
     PACKAGECONFIG_append-pn-<recipe1> = "f1 f2 ..."
     PACKAGECONFIG_append-pn-<recipe2> = "f2 f3 ..."
     PACKAGECONFIG_append-pn-<recipe3> = "f1 f3 f4..."
fi

So, if we comment DISTRO_FEATURES all the features listed above should
be automatically disabled.

Note, our feature flags are used across multiple recipes and layers.
Bootloader layer, Kernel, meta layer, recipe layer, python source, C
source, scripts, etc.
Like: edk2, meta-qti-bsp, meta-security, meta-qti-auto, auto-prod-folder, etc.

Is there a well defined way in Yocto to achieve such a modular design approach ?

If there are any such references please share.

Our reference distro is here:
https://source.codeaurora.org/quic/le/meta-qti-bsp/tree/conf/distro/auto.conf?h=yocto.lnx.3.0.c28

Thanks,
Pintu

Re: [qa-build-notification] QA notification for completed autobuilder build (yocto-3.1.14.rc1)

Teoh, Jay Shen

#56199

Hi All,

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

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

No new issue found.


Thanks,
Jay

Show quoted text

-----Original Message-----
From: qa-build-notification@lists.yoctoproject.org <qa-build-
notification@lists.yoctoproject.org> On Behalf Of Teoh, Jay Shen
Sent: Thursday, 10 February, 2022 12:05 PM
To: qa-build-notification@lists.yoctoproject.org;
<yocto@lists.yoctoproject.org> <yocto@lists.yoctoproject.org>; OE-core
<openembedded-core@lists.openembedded.org>
Subject: Re: [qa-build-notification] QA notification for completed autobuilder
build (yocto-3.1.14.rc1)

Hi all,

Intel and WR YP QA is planning for QA execution for YP build yocto-
3.1.14.rc1. We are planning to execute following tests for this cycle:

OEQA-manual tests for following module:
1. OE-Core
2. BSP-hw

Runtime auto test for following platforms:
1. MinnowTurbot 32-bit
2. Coffee Lake
3. NUC 7
4. NUC 6
5. Edgerouter
6. Beaglebone

ETA for completion next Tuesday, Feb 15.

Thanks,
Jay

-----Original Message-----
From: qa-build-notification@lists.yoctoproject.org <qa-build-
notification@lists.yoctoproject.org> On Behalf Of Richard Purdie
Sent: Tuesday, 1 February, 2022 5:47 AM
To: <yocto@lists.yoctoproject.org> <yocto@lists.yoctoproject.org>
Cc: qa-build-notification
<qa-build-notification@lists.yoctoproject.org>
Subject: [qa-build-notification] QA notification for completed
autobuilder build (yocto-3.1.14.rc1)

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


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


Build hash information:

bitbake: be6ecc160ac4a8d9715257b9b955363cecc081ea
meta-agl: 7a644d636237459c54128a71d083cb6f9e1b8e60
meta-arm: ce535dfb96de4d2529f091d7d85a7172c626001c
meta-aws: 9979cfa676105cb68cfadfdaeabf044d7c919319
meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac
meta-intel: 87984115eb6ed1a4c17204629dcb100f6b76fe82
meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7
meta-openembedded: ab9fca485e13f6f2f9761e1d2810f87c2e4f060a
oecore: f3be01483b01c88f8c4ba24ca73ccf1bcc33665c
poky: bba323389749ec3e306509f8fb12649f031be152



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

Re: [qa-build-notification] QA notification for completed autobuilder build (yocto-3.4.2.rc2)

Teoh, Jay Shen

#56198

Hi all,

Intel and WR YP QA is planning for QA execution for YP build yocto-3.4.2.rc2. We are planning to execute following tests for this cycle:

OEQA-manual tests for following module:
1. OE-Core
2. BSP-hw

Runtime auto test for following platforms:
1. MinnowTurbot 32-bit
2. Coffee Lake
3. NUC 7
4. NUC 6
5. Edgerouter
6. Beaglebone

ETA for completion this Friday, Feb 18.

Thanks,
Jay

Show quoted text

-----Original Message-----
From: qa-build-notification@lists.yoctoproject.org <qa-build-
notification@lists.yoctoproject.org> On Behalf Of Richard Purdie
Sent: Tuesday, 15 February, 2022 2:39 AM
To: <yocto@lists.yoctoproject.org> <yocto@lists.yoctoproject.org>
Cc: qa-build-notification <qa-build-notification@lists.yoctoproject.org>
Subject: [qa-build-notification] QA notification for completed autobuilder
build (yocto-3.4.2.rc2)

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


    https://autobuilder.yocto.io/pub/releases/yocto-3.4.2.rc2


Build hash information:

bitbake: c039182c79e2ccc54fff5d7f4f266340014ca6e0
meta-agl: 1a8abc70c4f2339200b612d96d81c4eec3ac0519
meta-arm: 51b728a52bde7c613d5855afeac0fa6a31771bd2
meta-aws: c92344938ab4d37de8bd8b799186dbbe3019a069
meta-gplv2: f04e4369bf9dd3385165281b9fa2ed1043b0e400
meta-intel: 5a30dcefa54040dd05099549a56156a83263554c
meta-mingw: f5d761cbd5c957e4405c5d40b0c236d263c916a8
meta-openembedded: c05ae80ba680887ac924c21536091be7a1173427
oecore: 418a9c4c31615a9e3e011fc2b21fb7154bc6c93a
poky: e0ab08bb6a32916b457d221021e7f402ffa36b1a



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

M+ & H bugs with Milestone Movements WW07

Stephen Jolley

#56197

All,

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

Priority	Bug ID	Short Description	Changer	Owner	Was	Became
Medium+	10693	Add a testcase for multilib eSDK on the autobuilder	randy.macleod@...	Qi.Chen@...	3.5 M2	3.5 M3
	13052	Allow oe-core generated OCI containers to be executed/tested on the build host	randy.macleod@...	bruce.ashfield@...	3.5 M2	3.5 M3
	13053	oe-core OCI container compatibility / deployment and conversion	randy.macleod@...	bruce.ashfield@...	3.5 M2	3.5 M3
	13251	Symlinks overridden when building multitple kernels	randy.macleod@...	bruce.ashfield@...	3.5 M2	3.5 M3
	13722	Debugging With the GNU Project Debugger enhancements	randy.macleod@...	john.kaldas.enpj@...	3.5 M2	3.5 M3
	13835	KCONF_BSP_AUDIT_LEVEL is not properly documented	randy.macleod@...	bruce.ashfield@...	3.5 M2	3.5 M3
	14065	Automated ptest regression testing	randy.macleod@...	chee.yang.lee@...	3.5 M2	3.5 M4
	14118	systemd services not enabled when using package feed	randy.macleod@...	unassigned@...	3.5 M2	3.5 M4
	14121	Implement sphinx switchers.js for bitbake	randy.macleod@...	nicolas.dechesne@...	3.5 M2	3.5 M4
	14571	Add support for arm in poky-tiny	randy.macleod@...	jon.mason@...	3.5 M3	3.5 M4
					3.5 M2	3.5 M3
					3.5 M4	3.5 M3
	14572	mozjs doesn't build for armv5	randy.macleod@...	jon.mason@...	3.5 M2	3.5 M3
	14570	debuginfod gdb: * stack smashing detected *: terminated	randy.macleod@...	pgowda.cve@...	3.5 M2	3.5 M4
	14626	lttng user space tracing example does not build with eSDK. but with classic SDK	randy.macleod@...	saul.wold@...	3.5 M2	3.5 M3
	14640	Relocation error when setting up SDK with rust tools	randy.macleod@...	pgowda.cve@...	3.5 M2	3.5 M3

Thanks,

Stephen K. Jolley

Yocto Project Program Manager

( Cell: (208) 244-4460

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

Enhancements/Bugs closed WW07!

Stephen Jolley

#56196

All,

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

Who	Count
randy.macleod@...	8
richard.purdie@...	3
pavel@...	1
Grand Total	12

Thanks,

Stephen K. Jolley

Yocto Project Program Manager

( Cell: (208) 244-4460

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

Current high bug count owners for Yocto Project 3.5

Stephen Jolley

#56195

All,

Below is the list as of top 46 bug owners as of the end of WW07 of who have open medium or higher bugs and enhancements against YP 3.5. There are 52 possible work days left until the final release candidates for YP 3.5 needs to be released.

Who	Count
michael.opdenacker@...	35
ross@...	34
randy.macleod@...	24
david.reyna@...	22
bruce.ashfield@...	17
sakib.sajal@...	13
tim.orling@...	13
trevor.gamblin@...	12
mhalstead@...	10
richard.purdie@...	9
bluelightning@...	6
saul.wold@...	6
kai.kang@...	6
JPEWhacker@...	4
hongxu.jia@...	4
chee.yang.lee@...	4
jon.mason@...	3
Qi.Chen@...	3
pokylinux@...	3
mshah@...	2
pgowda.cve@...	2
alexandre.belloni@...	2
alejandro@...	2
thomas.perrot@...	1
mark.hatle@...	1
martin.beeger@...	1
liezhi.yang@...	1
kexin.hao@...	1
yi.zhao@...	1
mostthingsweb@...	1
Martin.Jansa@...	1
pavel@...	1
raj.khem@...	1
andrei@...	1
aehs29@...	1
yf3yu@...	1
matthewzmd@...	1
jay.shen.teoh@...	1
mingli.yu@...	1
TicoTimo@...	1
nicolas.dechesne@...	1
jaskij@...	1
shachar@...	1
john.kaldas.enpj@...	1
open.source@...	1
akuster808@...	1
Grand Total	259

Thanks,

Stephen K. Jolley

Yocto Project Program Manager

( Cell: (208) 244-4460

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

Yocto Project Newcomer & Unassigned Bugs - Help Needed

Stephen Jolley

#56194

All,

The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs Also please review: https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and how to create a bugzilla account at: https://bugzilla.yoctoproject.org/createaccount.cgi

The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project. If anyone can help, please take ownership of the bug and send patches! If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too.

Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 401 unassigned or newcomer bugs.

We're hoping people may be able to spare some time now and again to help out with these. Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system. There are also roughly four different "priority" classes right now, “3.5, “3.6”, "3.99" and "Future", the more pressing/urgent issues being in "3.4" and then “3.5”.

Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp.pm@...) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account). The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer_Bugs

Thanks,

Stephen K. Jolley

Yocto Project Program Manager

( Cell: (208) 244-4460

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

Re: [meta-hardening][PATCH] meta-hardening: Fix override syntax

Armin Kuster

#56193

On 2/14/22 09:05, Akshay Bhat wrote:
On Fri, Jan 21, 2022 at 11:33 AM Akshay Bhat <nodeax@gmail.com> wrote:
Commit 352e6498a missed updating the override syntax for the
"harden" distro override.

Fixes: 352e6498a ("meta-hardening: Convert to new override syntax")

Signed-off-by: Akshay Bhat <akshay.bhat@timesys.com>
---Ping... any feedback on the patch? If not can it be applied? Thanks :)
<snip>Thanks for the ping. I didn't find this in my inbox but found it on lore mailing list.

Patch looks fine.

thanks,
-armin

QA notification for completed autobuilder build (yocto-3.4.2.rc2)

Pokybuild User <pokybuild@...>

#56192

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


    https://autobuilder.yocto.io/pub/releases/yocto-3.4.2.rc2


Build hash information: 

bitbake: c039182c79e2ccc54fff5d7f4f266340014ca6e0
meta-agl: 1a8abc70c4f2339200b612d96d81c4eec3ac0519
meta-arm: 51b728a52bde7c613d5855afeac0fa6a31771bd2
meta-aws: c92344938ab4d37de8bd8b799186dbbe3019a069
meta-gplv2: f04e4369bf9dd3385165281b9fa2ed1043b0e400
meta-intel: 5a30dcefa54040dd05099549a56156a83263554c
meta-mingw: f5d761cbd5c957e4405c5d40b0c236d263c916a8
meta-openembedded: c05ae80ba680887ac924c21536091be7a1173427
oecore: 418a9c4c31615a9e3e011fc2b21fb7154bc6c93a
poky: e0ab08bb6a32916b457d221021e7f402ffa36b1a



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

Re: Additional hardening options

Bernhard Rosenkränzer <bero@...>

#56191

Hi,

On Wed, Jan 26, 2022 at 02:39 AM, Paul Eggleton wrote:

I've been looking into a couple of compiler flags for hardening that I think we
might want to consider enabling by default in security-flags.inc:
1) -fstack-clash-protection
2) -z noexecstack (or alternative mitigations)

I've been looking into those flags (and a few more) a while back when picking compiler flags to use for Oniro.

-Wl,-z,-noexecstack is unproblematic, -fstack-clash-protection adds a bit of overhead, but it isn't all that bad (typically in the 2% range).

I've been able to build working systems with both flags enabled.

My full report is at
https://forum.ostc-eu.org/t/compiler-flags-to-be-used-for-all-scenarios-os/94

ttyl
bero