Date   

Re: same build for multiple machine configurations

Khem Raj
 

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

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
 

Hello Steven,

Last entry, from July 2021, in this blog says not supported;
Docker for RTOS? - General Discussions / Feature Requests - Docker Community Forums
No, 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)
 

 

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
 


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
 

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
 

Current Dev Position: YP 3.5 M3

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

 

Next Team Meetings:

 

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:

 

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:

 

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

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
 

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
 

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

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
 

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
 

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

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

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

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

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
 

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
 

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
 

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
 

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

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

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

901 - 920 of 57064