[yocto] M+ & H bugs with Milestone Movements WW02

[Stephen Jolley]

All,

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


Priority

Bug ID

Short Description

Changer

Owner

Was

Became


Medium+

  14697

Hang due to missing asyncio loop argument: Initialising tasks at 44%

randy.macl...@windriver.com

jate...@gmail.com

0.0.0

3.1.14


 

 

jate...@gmail.com

jate...@gmail.com

3.1.14

0.0.0

Thanks, 

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com  

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#55960): https://lists.yoctoproject.org/g/yocto/message/55960
Mute This Topic: https://lists.yoctoproject.org/mt/88664523/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Enhancements/Bugs closed WW04!

[Stephen Jolley]

All,

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


Who

Count


alex.kana...@gmail.com

8


tim.orl...@konsulko.com

1


randy.macl...@windriver.com

1


jpewhac...@gmail.com

1


Grand Total

11

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#55959): https://lists.yoctoproject.org/g/yocto/message/55959
Mute This Topic: https://lists.yoctoproject.org/mt/88664494/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Current high bug count owners for Yocto Project 3.5

[Stephen Jolley]

All,

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


Who

Count


r...@burtonini.com

37


michael.opdenac...@bootlin.com

36


randy.macl...@windriver.com

25


david.re...@windriver.com

22


bruce.ashfi...@gmail.com

17


sakib.sa...@windriver.com

13


tim.orl...@konsulko.com

13


trevor.gamb...@windriver.com

12


richard.pur...@linuxfoundation.org

10


mhalst...@linuxfoundation.org

8


kai.k...@windriver.com

7


saul.w...@windriver.com

6


bluelightn...@bluelightning.org

6


jpewhac...@gmail.com

4


chee.yang@intel.com

4


hongxu@windriver.com

4


qi.c...@windriver.com

3


jon.ma...@arm.com

3


alexandre.bell...@bootlin.com

2


ms...@mvista.com

2


pokyli...@reliableembeddedsystems.com

2


raj.k...@gmail.com

2


pgowda@gmail.com

2


kiran.surend...@windriver.com

2


alejan...@enedino.org

2


open.sou...@oleksandr-kravchuk.com

1


yf...@uwaterloo.ca

1


liezhi.y...@windriver.com

1


nicolas.deche...@linaro.org

1


jay.shen.t...@intel.com

1


kexin@windriver.com

1


john.kaldas.e...@gmail.com

1


aeh...@gmail.com

1


akuster...@gmail.com

1


matthew...@posteo.net

1


thomas.per...@bootlin.com

1


yi.z...@windriver.com

1


mingli...@windriver.com

1


ticot...@gmail.com

1


martin.ja...@gmail.com

1


shac...@vdoo.com

1


mark.ha...@kernel.crashing.org

1


mostthings...@gmail.com

1


Grand Total

262

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#55958): https://lists.yoctoproject.org/g/yocto/message/55958
Mute This Topic: https://lists.yoctoproject.org/mt/88664405/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] 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 398
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...@gmail.com
 ) 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...@gmail.com
 

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#55957): https://lists.yoctoproject.org/g/yocto/message/55957
Mute This Topic: https://lists.yoctoproject.org/mt/88664399/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Custom SDK generation from YoctoSDK #sdk

[Praveen]

I am looking for Custom SDK with filtered Header files/libraries based on some 
rules/approvals. It means not all files from YoctoSDK will be packaged in the 
CustomSDK.

What is the mechanism or approach where we can pull only those approved header 
files & libraries from YoctoSDK and package as Customized SDK tar?

Is there a way we can fetch those approved header files from YOCTO SDK and 
filter it?

I am thinking like creating subset versioned module recipe and specify those 
approved header files and package only those files. Is there any better 
mechanism on packaging or filtering the SDK based on some rules to filter some 
header files?

Like for example in YoctoSDK, we have 2 modules moduleA (A1.h, A2.h,A3.h and 
libA.so), moduleB ( B1.h, B2.h, B3.h and libB.so)
Lets say A3.h & B3.h are not approved in my Custom SDK, then in final Customer 
SDK we will only package
moduleA (A1.h, A2.h and libA.so), moduleB (B1.h, B2.h, and libB.so)

I want to keep YoctoSDK without any filters, so that A3.h/B3.h can be used for 
internal purposes without any issue.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#55956): https://lists.yoctoproject.org/g/yocto/message/55956
Mute This Topic: https://lists.yoctoproject.org/mt/88653143/21656
Mute #sdk:https://lists.yoctoproject.org/g/yocto/mutehashtag/sdk
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Inclusive Language Proposal for YP/OE

[Jon Mason]

>From the beginning, OpenEmbedded and The Yocto Project have always
strived to be as inclusive as possible to all races, sexes,
orientations, religions, nationalities, and any other thing which
might divide people.  As continuation of this striving, there are
suggested changes below that are being proposed to make the projects
more inclusive and show the community as the professional, friendly,
and welcoming group that it is.   There are words in use by the
projects directly or one of its derivative layers that could be
offensive to some.  For more information on which words we selected
and why, please consult
https://inclusivenaming.org/word-lists/overview/

In the process of changing these, we are using this opportunity to
make the terms more obvious and useful, as well as removing cruft and
other unused code.  This is the pure definition of a win-win solution.

With this in mind, a group of people have tried to identify issues and
come up with a plan to address these.   We’ve divided the tasks into 3
areas: bitbake variables, oe-core variables, and everything else.

Bitbake Variables
Taking issues in turn, for bitbake:

For BB_DISKMON_DIRS, the actions "ABORT, STOPTASKS and WARN" would
become "HALT, NO_NEW_TASKS and "WARN".

BB_ENV_WHITELIST -> BB_ENV_PASSTHROUGH
BB_ENV_EXTRAWHITE -> BB_ENV_PASSTHROUGH_ADDITIONS

BB_HASHCONFIG_WHITELIST -> BB_HASHCONFIG_IGNORE_VARS
BB_SETSCENE_ENFORCE_WHITELIST -> BB_SETSCENE_ENFORCE_IGNORE_TASKS
BB_HASHBASE_WHITELIST -> BB_BASEHASH_IGNORE_VARS
MULTI_PROVIDER_WHITELIST -> BB_MULTI_PROVIDER_ALLOWED
BB_STAMP_WHITELIST and BB_STAMP_POLICY -> delete the code (already merged)

basewhitelist and taskwhitelist as used in sigdata/siginfo will need
to be renamed and older file usage of the variables renamed at import
for backwards compatibility. The variables in bitbake along with usage
of abort will be renamed as appropriate.

For most variables, errors will be shown to the user if the old
variable names are set. Mostly this can be done in event hooks but
some like the BB_ENV changes will need special handling.

These changes hopefully improve consistency (e.g. a consistent BB_
prefix and BASHHASH as terminology used elsewhere) and also improve
the description of the variables to be more understandable to users.

OE-Core Variables
For OE-Core, the proposals are:

For blacklist.bbclass, the proposal is to add the functionality to the
anonymous Python in base.bbclass instead. PNBLACKLIST[xxx] would
become SKIP_RECIPE[xxx]. INHERIT_BLACKLIST would simply be dropped.

SSTATE_DUPWHITELIST -> SSTATE_ALLOW_OVERLAP_FILES
CVE_CHECK_PN_WHITELIST -> CVE_CHECK_SKIPRECIPE
CVE_CHECK_WHITELIST -> CVE_CHECK_IGNORECVE
SYSROOT_DIRS_BLACKLIST -> SYSROOT_DIRS_IGNORE
LICENSE_FLAGS_WHITELIST -> LICENSE_FLAGS_ACCEPTED
UNKNOWN_CONFIGURE_WHITELIST -> UNKNOWN_CONFIGURE_OPT_IGNORE
SDK_LOCAL_CONF_BLACKLIST -> ESDK_LOCALCONF_REMOVE
SDK_LOCAL_CONF_WHITELIST -> ESDK_LOCALCONF_ALLOW
SDK_INHERIT_BLACKLIST -> ESDK_CLASS_INHERIT_DISABLE
TUNEABI_WHITELIST - already removed as obsolete

For the ICECC_USER_XXX and ICECC_SYSTEM_XXX, we think these can likely
be merged into single variables:

ICECC_USER_CLASS_BL -> ICECC_CLASS_DISABLE
ICECC_SYSTEM_CLASS_BL -> ICECC_CLASS_DISABLE
ICECC_USER_PACKAGE_WL -> ICECC_RECIPE_ENABLE
ICECC_USER_PACKAGE_BL -> ICECC_RECIPE_DISABLE
ICECC_SYSTEM_PACKAGE_BL -> ICECC_RECIPE_DISABLE

For license handling, we’d use the opportunity to clean up the
WHITELIST_(ANY LICENSE) syntax and replace it with a
INCOMPATIBLE_LICENSE_ALLOWED_RECIPES, which would be a list of recipes
which are of a blocked the INCOMPATIBLE_LICENSE list.

Everything else
The migration plan includes writing a script to assist with the
migration. In many cases it can likely make the translation. In cases
where that isn’t possible, it will aim to list the areas the user
needs to fix references.

A warning mechanism will be added to bitbake to detect usage of old
variable names (post parsing), except for BB_ENV issues which will
likely need special handling. A (limited) conversion script will be
created to help with the migration. For those instances where a 1-1
mapping is not achievable, a list of the occurrences and what it
should be changed to will occur.


Patch files in OE to be renamed:
11_tcpd_blacklist.patch -> 11_tcpd_blocklist.patch
mount.blacklist -> mount.disallow
0001-lxdm.conf.in-blacklist-root-for-release-images.patch ->
0001-lxdm.conf.in-deny-root-for-release-images.patch
022-RH-Remove-the-property-blacklist-exception-builtin.patch ->
022-RH-Remove-the-default-property-exception-builtin.patch
0001-Cargo.toml-do-not-abort-on-panic.patch ->
0001-Cargo.toml-do-not-exit-on-panic.patch
0004-Cargo.toml-do-not-abort-on-panic.patch ->
0004-Cargo.toml-do-not-exit-on-panic.patch
Also, there are a few others outside of OE that should probably be patched too.

Branch Names
The “master” branches on the relevant OpenEmbedded and Yocto Project
git trees will be changed to an alternative name at some point in the
future.  

[yocto] [meta-zephyr][PATCH 1/2] bossa-native: Add Arduino variant of the bossa flashing tool

[Andrei Gherzan]

From: Stefan Schmidt 

This native recipe will be used to streamline the flashing of out
Arduino Nano 33 BLE target. Until now we have pointed to the full
Arduino IDE to get it installed and setting the PATH correctly before
any flashing would work. Having the tool supplied under the hood for
flashing will simplify documentation and support.

Signed-off-by: Stefan Schmidt 
Signed-off-by: Andrei Gherzan 
---
 .../bossa/bossa-native_git.bb | 23 +++
 1 file changed, 23 insertions(+)
 create mode 100644 meta-zephyr-core/recipes-devtools/bossa/bossa-native_git.bb

diff --git a/meta-zephyr-core/recipes-devtools/bossa/bossa-native_git.bb 
b/meta-zephyr-core/recipes-devtools/bossa/bossa-native_git.bb
new file mode 100644
index 000..b645ecf
--- /dev/null
+++ b/meta-zephyr-core/recipes-devtools/bossa/bossa-native_git.bb
@@ -0,0 +1,23 @@
+SUMMARY = "Arduino variant of the BOSSA flashing tool"
+HOMEPAGE = "https://github.com/arduino/BOSSA";
+SECTION = "devel"
+LICENSE = "BSD-3-Clause"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=bcf9399f7b9b96149837290bcdc3ad39"
+
+SRC_URI = "git://github.com/arduino/BOSSA.git;protocol=https;branch=nrf"
+
+PV = "1.9.1+git${SRCPV}"
+SRCREV = "89f3556a761833522cd93c199581265ad689310b"
+
+S = "${WORKDIR}/git"
+
+inherit native
+
+do_compile() {
+# We only compile the bossac commandline tool, not the graphical version.
+oe_runmake bossac
+}
+
+do_install() {
+install -D -m 0755 ${B}/bin/bossac ${D}${bindir}/bossac
+}
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#55953): https://lists.yoctoproject.org/g/yocto/message/55953
Mute This Topic: https://lists.yoctoproject.org/mt/88645462/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] [meta-zephyr][PATCH 2/2] zephyr-flash-bossac.bbclass: Use internal bossac tool instead looking up PATH

[Andrei Gherzan]

From: Stefan Schmidt 

Instead of looking in PATH on the host to find bossac we now depend on the
native variant we build and set the path to our yocto build tool.

Signed-off-by: Stefan Schmidt 
Signed-off-by: Andrei Gherzan 
---
 meta-zephyr-core/classes/zephyr-flash-bossac.bbclass | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/meta-zephyr-core/classes/zephyr-flash-bossac.bbclass 
b/meta-zephyr-core/classes/zephyr-flash-bossac.bbclass
index 50222d5..51f2dd3 100644
--- a/meta-zephyr-core/classes/zephyr-flash-bossac.bbclass
+++ b/meta-zephyr-core/classes/zephyr-flash-bossac.bbclass
@@ -1,17 +1,17 @@
 #@DESCRIPTION: class file to flash boards like Arduino Nano BLE which depends 
on bossac for flashing
 
+DEPENDS += "bossa-native"
+
 python do_flash_usb() {
 import shutil
 import subprocess
 import serial.tools.list_ports
 
-# Note: make sure the installed bossac is set to PATH before running 
flash_usb()
 # Check if bossac is avaiable for flashing
-origbbenv = d.getVar("BB_ORIGENV", False)
-bossac_path = shutil.which("bossac", path=origbbenv.getVar('PATH'))
+bossac_path = shutil.which("bossac")
 
 if not bossac_path:
-   bb.fatal("ERROR: bossac not found, please install first and add to 
PATH")
+   bb.fatal("ERROR: bossac not found.")
 
 board = d.getVar('BOARD')
 
@@ -47,4 +47,3 @@ python do_flash_usb() {
 addtask do_flash_usb after do_deploy
 
 do_flash_usb[nostamp] = "1"
-do_flash_usb[vardepsexclude] = "BB_ORIGENV"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#55954): https://lists.yoctoproject.org/g/yocto/message/55954
Mute This Topic: https://lists.yoctoproject.org/mt/88645463/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] [honister][PATCH] dm-verity-img.bbclass: Fix wrong override syntax for CONVERSION_DEPENDS

[Kristian Klausen via lists.yoctoproject.org]

CONVERSION_DEPENDS hasn't been converted to the new syntax.

Fixes: a23ceef ("dm-verity-img.bbclass: more overided fixups")

Signed-off-by: Kristian Klausen 
Signed-off-by: Armin Kuster 
---
 classes/dm-verity-img.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/classes/dm-verity-img.bbclass b/classes/dm-verity-img.bbclass
index 0b6d053..93f667d 100644
--- a/classes/dm-verity-img.bbclass
+++ b/classes/dm-verity-img.bbclass
@@ -67,7 +67,7 @@ VERITY_TYPES = "ext2.verity ext3.verity ext4.verity 
btrfs.verity"
 IMAGE_TYPES += "${VERITY_TYPES}"
 CONVERSIONTYPES += "verity"
 CONVERSION_CMD:verity = "verity_setup ${type}"
-CONVERSION_DEPENDS:verity = "cryptsetup-native"
+CONVERSION_DEPENDS_verity = "cryptsetup-native"
 
 python __anonymous() {
 verity_image = d.getVar('DM_VERITY_IMAGE')
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#55952): https://lists.yoctoproject.org/g/yocto/message/55952
Mute This Topic: https://lists.yoctoproject.org/mt/88643459/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-