Date   

OpenEmbedded Happy Hour January 26 5pm/1700 UTC

Denys Dmytriyenko
 

All,

Our next OpenEmbedded Happy Hour is on January 26 for Europe/Americas
timezones @ 1700/5pm UTC (12pm ET / 9am PT):

https://www.openembedded.org/wiki/Calendar
https://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenEmbedded+Happy+Hour+January+26&iso=20220126T17

--
Regards,
Denys Dmytriyenko <denis@denix.org>
PGP: 0x420902729A92C964 - https://denix.org/0x420902729A92C964
Fingerprint: 25FC E4A5 8A72 2F69 1186 6D76 4209 0272 9A92 C964


Re: [OE-core] Inclusive Language Proposal for YP/OE

Richard Purdie
 

On Tue, 2022-01-25 at 07:50 -0800, Chuck Wolber wrote:
On Mon, Jan 24, 2022 at 8:18 AM Jon Mason <jdmason@kudzu.us> wrote:

%< SNIP %<
 
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.  The current preferred name is “devel”.

Why devel instead of main [1]?

[1]
https://lore.kernel.org/git/pull.656.v4.git.1593009996.gitgitgadget@gmail.com/
The idea is we're trying to use the language which makes sense and "devel" says
what the branch is/does.

Cheers,

Richard


[PATCH yocto-autobuilder-helper] run-docs-build: fix checkout of releases.rst from master

Michael Opdenacker
 

A wrong path was given given the working directory.

Also revert the changes with "git reset --hard" to
have a clean state before further branch switches.

Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
---
scripts/run-docs-build | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/scripts/run-docs-build b/scripts/run-docs-build
index 5d6d24a..c93b3e6 100755
--- a/scripts/run-docs-build
+++ b/scripts/run-docs-build
@@ -43,11 +43,12 @@ cp -r ./_build/final/* $outputdir/bitbake/next
# see the latest releases.
for branch in 1.46 1.48 1.50 1.52; do
git checkout $branch
- git checkout master doc/releases.rst
+ git checkout master releases.rst
make clean
make publish
mkdir $outputdir/bitbake/$branch
cp -r ./_build/final/* $outputdir/bitbake/$branch
+ git reset --hard
done

# only sync bitbake folder for now. We need bitbake to be published first
@@ -79,11 +80,12 @@ cp -r ./_build/final/* $outputdir/next
for branch in dunfell gatesgarth hardknott honister; do
cd $ypdocs
git checkout $branch
- git checkout master documentation/releases.rst
+ git checkout master releases.rst
make clean
make publish
mkdir $outputdir/$branch
cp -r ./_build/final/* $outputdir/$branch
+ git reset --hard
done

# Yocto Project releases/tags
@@ -101,12 +103,13 @@ for tag in $(git tag --list 'yocto-*'); do
if [ "$tag" = "yocto-3.3" ] || [ "$tag" = "yocto-3.4" ]; then
git am "${scriptdir}/${tag}/0001-conf-update-for-release.patch"
fi
- git checkout master documentation/releases.rst
+ git checkout master releases.rst
make clean
make publish
version=$(echo $tag | cut -c7-)
mkdir $outputdir/$version
cp -r ./_build/final/* $outputdir/$version
+ git reset --hard
fi
done

--
2.25.1


Re: [oe] Inclusive Language Proposal for YP/OE

Ross Burton <ross@...>
 

On Mon, 24 Jan 2022 at 16:18, Jon Mason <jdmason@kudzu.us> wrote:
CVE_CHECK_PN_WHITELIST -> CVE_CHECK_SKIPRECIPE
CVE_CHECK_WHITELIST -> CVE_CHECK_IGNORECVE
This is the only one that sticks out to me. I think it needs another
_, SKIP_RECIPE and IGNORE_CVE.

Other than that, +1.

Will we have a bit of logic to detect the obsolete names being set and
emit warnings/errors?

Ross


Re: [oe] [OE-core] Inclusive Language Proposal for YP/OE

Ross Burton <ross@...>
 

On Tue, 25 Jan 2022 at 15:50, Chuck Wolber <chuckwolber@gmail.com> wrote:
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. The current preferred name is “devel”.

Why devel instead of main [1]?

[1] https://lore.kernel.org/git/pull.656.v4.git.1593009996.gitgitgadget@gmail.com/
Personally, the only advantage of 'main' is muscle memory of m[tab].

Semantically it's not the 'main' branch, it's the active development
branch. Thus, devel.

Ross


Yocto Project Status WW04`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:

  • YP 3.5 M2 finally built today after a number of autobuilder build issues and is now in QA
  • Building M2 was fairly painful as various sstate error/warning code paths were exposed in release builds, there were some infrastructure issues, some test reporting bugs and other bugs like that in systemtap on arm and a reproducibility issue, all of which combined to break the release builds in different ways. Hopefully most of these are now addressed or in the process of being fixed/tested.
  • Upstream glibc are planning to remove prelink support in 2.35 with patches proposed on their mailing list. The project is unlikely to be able to continue to maintain any prelink support once this happens and we will therefore remove our prelink support before the next LTS unless the situation changes and maintainers step forward.
  • An email proposing inclusive language changes for bitbake and OE-Core has been sent to the community for review. The aim is to implement this before M3.
  • The debian9 autobuilder issues were hardware related and fixes for the arm systemtap issues are being tested but autobuilder intermittent issues are still at an all time high.
  • CVE metrics improved for master but work still remains on the various stable branches which have high counts.
  • 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

 

Ways to contribute:

 

YP 3.5 Milestone Dates:

  • YP 3.5 M2 is built
  • YP 3.5 M2 Release date 2022/01/28
  • 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 build date 2022/01/24
  • YP 3.1.14 Release date 2022/02/04
  • YP 3.4.2 build date 2022/02/07
  • 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@...

 


Re: [OE-core] Inclusive Language Proposal for YP/OE

Chuck Wolber
 

On Mon, Jan 24, 2022 at 8:18 AM Jon Mason <jdmason@...> wrote:

%< SNIP %<
 
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.  The current preferred name is “devel”.

Why devel instead of main [1]?


..Ch:W..
 


--
"Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire


QA notification for completed autobuilder build (yocto-3.5_M2.rc6)

Richard Purdie
 

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


https://autobuilder.yocto.io/pub/releases/yocto-3.5_M2.rc6


Build hash information:

bitbake: 1f06f326fa8b47e2a4dce756d57a9369a2225201
meta-agl: 7a644d636237459c54128a71d083cb6f9e1b8e60
meta-arm: 254482284d4588532bd7b9d980193e3e41adaa99
meta-aws: 8893e0cd4c0981eeda941eaa9ad2eb9359670502
meta-gplv2: f04e4369bf9dd3385165281b9fa2ed1043b0e400
meta-intel: 4ff5b19ba63ea69c47198e641acbc12e33634cac
meta-mingw: ddbf14b224215f47a5f80fc8154ade8d3bc318e8
meta-openembedded: a558d51fecda3e66ace21d02b57ab61bf122fdc1
oecore: a179485351a0563d12a2fef3e49971122255ed80
poky: 27ff420543f0195dab024698d804aca33f2ae139



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


Re: Inclusive Language Proposal for YP/OE

Paul Barker
 

On 24/01/2022 16:17, Jon Mason wrote:
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.

This is an excellent proposal, the new variable names for bitbake & oe-core are clear and easy to understand.

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. The current preferred name is “devel”. There is no time
table for this currently, and there is no obligation or requirement to
change the branch name for any downstream project which is beyond the
project’s remit.
The layer index may need some modification to handle different layers having different names for the in-development branch. We could implement the layer index changes first to support other layers which rename their master branch.

I'm going to bite the bullet with meta-linux-mainline and rename the master branch to "dev" this week to see what happens.

Similarly, there is no need to change any recipes that are using a
“master” branch as part of the SRC_URI. Those are outside the scope
of YP/OE and this effort.
Note
These changes are only to bitbake and OE-Core. There is no
requirement to change any other layers but we’d note consistency is
encouraged and helpful to users.
Helping
If you would like to help, please put your name by the items in
question on the inclusive language wiki page.
https://wiki.yoctoproject.org/wiki/Inclusive_language
Thanks
Special thanks to Richard Purdie, Michael Opdenacker. Marta
Rybczynska, Scott Murray, Jan-Simon Moeller, Saul Wold, and Armin
Kuster for providing their time, technical details, text, and feedback
on this task.
Thanks all, it's great to see this moving forward!

--
Paul Barker
Principal Software Engineer
SanCloud Ltd

e: paul.barker@sancloud.com
w: https://sancloud.co.uk/


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

jatedev@...

0.0.0

3.1.14

 

 

jatedev@...

jatedev@...

3.1.14

0.0.0

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Enhancements/Bugs closed WW04!

Stephen Jolley
 

All,

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

Who

Count

alex.kanavin@...

8

tim.orling@...

1

randy.macleod@...

1

JPEWhacker@...

1

Grand Total

11

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

ross@...

37

michael.opdenacker@...

36

randy.macleod@...

25

david.reyna@...

22

bruce.ashfield@...

17

sakib.sajal@...

13

tim.orling@...

13

trevor.gamblin@...

12

richard.purdie@...

10

mhalstead@...

8

kai.kang@...

7

saul.wold@...

6

bluelightning@...

6

JPEWhacker@...

4

chee.yang.lee@...

4

hongxu.jia@...

4

Qi.Chen@...

3

jon.mason@...

3

alexandre.belloni@...

2

mshah@...

2

pokylinux@...

2

raj.khem@...

2

pgowda.cve@...

2

kiran.surendran@...

2

alejandro@...

2

open.source@...

1

yf3yu@...

1

liezhi.yang@...

1

nicolas.dechesne@...

1

jay.shen.teoh@...

1

kexin.hao@...

1

john.kaldas.enpj@...

1

aehs29@...

1

akuster808@...

1

matthewzmd@...

1

thomas.perrot@...

1

yi.zhao@...

1

mingli.yu@...

1

TicoTimo@...

1

Martin.Jansa@...

1

shachar@...

1

mark.hatle@...

1

mostthingsweb@...

1

Grand Total

262

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

 


Custom SDK generation from YoctoSDK #sdk

Praveen <praveen44com@...>
 

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.


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. The current preferred name is “devel”. There is no time
table for this currently, and there is no obligation or requirement to
change the branch name for any downstream project which is beyond the
project’s remit.

Similarly, there is no need to change any recipes that are using a
“master” branch as part of the SRC_URI. Those are outside the scope
of YP/OE and this effort.

Note
These changes are only to bitbake and OE-Core. There is no
requirement to change any other layers but we’d note consistency is
encouraged and helpful to users.

Helping
If you would like to help, please put your name by the items in
question on the inclusive language wiki page.
https://wiki.yoctoproject.org/wiki/Inclusive_language

Thanks
Special thanks to Richard Purdie, Michael Opdenacker. Marta
Rybczynska, Scott Murray, Jan-Simon Moeller, Saul Wold, and Armin
Kuster for providing their time, technical details, text, and feedback
on this task.


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

Andrei Gherzan
 

From: Stefan Schmidt <stefan.schmidt@huawei.com>

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 <stefan.schmidt@huawei.com>
Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>
---
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


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

Andrei Gherzan
 

From: Stefan Schmidt <stefan.schmidt@huawei.com>

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 <stefan.schmidt@huawei.com>
Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>
---
.../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 0000000..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


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

Kristian Klausen
 

CONVERSION_DEPENDS hasn't been converted to the new syntax.

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

Signed-off-by: Kristian Klausen <kristian@klausen.dk>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
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.bbclas=
s
index 0b6d053..93f667d 100644
--- a/classes/dm-verity-img.bbclass
+++ b/classes/dm-verity-img.bbclass
@@ -67,7 +67,7 @@ VERITY_TYPES =3D "ext2.verity ext3.verity ext4.verity b=
trfs.verity"
IMAGE_TYPES +=3D "${VERITY_TYPES}"
CONVERSIONTYPES +=3D "verity"
CONVERSION_CMD:verity =3D "verity_setup ${type}"
-CONVERSION_DEPENDS:verity =3D "cryptsetup-native"
+CONVERSION_DEPENDS_verity =3D "cryptsetup-native"
=20
python __anonymous() {
verity_image =3D d.getVar('DM_VERITY_IMAGE')
--=20
2.34.1


Re: [meta-tensorflow][PATCH] Update SRC_URI git default protocol

hongxu
 

Merged

//Hongxu

On 1/21/22 16:51, Changqing Li wrote:
From: Changqing Li <changqing.li@windriver.com>

Signed-off-by: Changqing Li <changqing.li@windriver.com>
---
recipes-framework/tensorflow/keras_2.6.0.bb | 2 +-
recipes-framework/tensorflow/tensorflow-estimator_2.6.bb | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-framework/tensorflow/keras_2.6.0.bb b/recipes-framework/tensorflow/keras_2.6.0.bb
index dc1a98d..ebb668d 100644
--- a/recipes-framework/tensorflow/keras_2.6.0.bb
+++ b/recipes-framework/tensorflow/keras_2.6.0.bb
@@ -3,7 +3,7 @@ DESCRIPTION = "TensorFlow Keras is an implementation of the Keras API that\
LICENSE = "Apache-2.0"
LIC_FILES_CHKSUM = "file://LICENSE;md5=c573baaa40a28002a2d03d3e7e9bc583"

-SRC_URI = "git://github.com/keras-team/keras.git;branch=r2.6 \
+SRC_URI = "git://github.com/keras-team/keras.git;branch=r2.6;protocol=https \
file://0001-customize-for-yocto.patch \
"

diff --git a/recipes-framework/tensorflow/tensorflow-estimator_2.6.bb b/recipes-framework/tensorflow/tensorflow-estimator_2.6.bb
index 910ca4d..83804af 100644
--- a/recipes-framework/tensorflow/tensorflow-estimator_2.6.bb
+++ b/recipes-framework/tensorflow/tensorflow-estimator_2.6.bb
@@ -3,7 +3,7 @@ learning programming."
LICENSE = "Apache-2.0"
LIC_FILES_CHKSUM = "file://LICENSE;md5=01e86893010a1b87e69a213faa753ebd"

-SRC_URI = "git://github.com/tensorflow/estimator.git;branch=r2.6 \
+SRC_URI = "git://github.com/tensorflow/estimator.git;branch=r2.6;protocol=https \
file://0001-customize-for-yocto.patch \
"
SRCREV = "9a6c1260bbb468a013e39cf7d6f5af369cf2db2b"



Re: [meta-tensorflow][PATCH 3/3] tensorflow-lite: add recipe

hongxu
 

On 1/14/22 18:19, Julien Stephan wrote:

[Please note: This e-mail is from an EXTERNAL e-mail address]

Hi Hongxu

Did you have a chance to take a look at it?

Sorry for replying late, thanks for your contribution, merged

//Hongxu

Best
Julien

Le ven. 24 déc. 2021 à 19:48, Randy MacLeod <randy.macleod@...> a écrit :
Thanks Stephan.

Hongxu, did you miss this?

../Randy

On 2021-12-21 3:42 a.m., Julien STEPHAN wrote:
> Adding 2.6.1 tensorflow-lite recipe.
> This recipe is directly based on the corresponding 2.6.1 tensorflow
> recipe.
>
> It has been build tested with latest honister and tested on
> several mediatek soc using benchmark_model and label_image (C++ and
> python)
>
> Signed-off-by: Julien STEPHAN <jstephan@...>
> ---
>   .../tensorflow/tensorflow-lite_2.6.1.bb       | 156 ++++++++++++++++++
>   1 file changed, 156 insertions(+)
>   create mode 100644 recipes-framework/tensorflow/tensorflow-lite_2.6.1.bb
>
> diff --git a/recipes-framework/tensorflow/tensorflow-lite_2.6.1.bb b/recipes-framework/tensorflow/tensorflow-lite_2.6.1.bb
> new file mode 100644
> index 0000000..104e5a3
> --- /dev/null
> +++ b/recipes-framework/tensorflow/tensorflow-lite_2.6.1.bb
> @@ -0,0 +1,156 @@
> +include tensorflow.inc
> +
> +SRC_URI += " \
> +           file://0001-add-yocto-toolchain-to-support-cross-compiling.patch \
> +           file://0001-fix-build-tensorflow-lite-examples-label_image-label.patch \
> +           file://0001-label_image-tweak-default-model-location.patch \
> +           file://0001-label_image.lite-tweak-default-model-location.patch \
> +           file://0001-CheckFeatureOrDie-use-warning-to-avoid-die.patch \
> +           file://0001-support-32-bit-x64-and-arm-for-yocto.patch \
> +           file://0001-Revert-set-distinct_host_configuration-false-by-defa.patch \
> +           file://0001-fix-default-Bazel-toolchain-not-work.patch \
> +           file://0001-distutils-is-deprecated-in-Python-3.10-cross.patch \
> +           file://BUILD.in \
> +           file://BUILD.yocto_compiler \
> +           file://cc_config.bzl.tpl \
> +           file://yocto_compiler_configure.bzl \
> +          "
> +
> +SRC_URI += "https://storage.googleapis.com/download.tensorflow.org/models/inception_v3_2016_08_28_frozen.pb.tar.gz;name=model-inv3"
> +SRC_URI[model-inv3.md5sum] = "a904ddf15593d03c7dd786d552e22d73"
> +SRC_URI[model-inv3.sha256sum] = "7045b72a954af4dce36346f478610acdccbf149168fa25c78e54e32f0c723d6d"
> +
> +SRC_URI += "https://storage.googleapis.com/download.tensorflow.org/models/tflite/mobilenet_v1_1.0_224_quant_and_labels.zip;name=model-mobv1"
> +SRC_URI[model-mobv1.md5sum] = "38ac0c626947875bd311ef96c8baab62"
> +SRC_URI[model-mobv1.sha256sum] = "2f8054076cf655e1a73778a49bd8fd0306d32b290b7e576dda9574f00f186c0f"
> +
> +RDEPENDS:${PN} += " \
> +    python3 \
> +    python3-core \
> +    python3-numpy \
> +"
> +
> +export PYTHON_BIN_PATH="${PYTHON}"
> +export PYTHON_LIB_PATH="${STAGING_LIBDIR_NATIVE}/${PYTHON_DIR}/site-packages"
> +
> +export CROSSTOOL_PYTHON_INCLUDE_PATH="${STAGING_INCDIR}/python${PYTHON_BASEVERSION}${PYTHON_ABI}"
> +
> +do_configure:append () {
> +    if [ ! -e ${CROSSTOOL_PYTHON_INCLUDE_PATH}/pyconfig-target.h ];then
> +        mv ${CROSSTOOL_PYTHON_INCLUDE_PATH}/pyconfig.h ${CROSSTOOL_PYTHON_INCLUDE_PATH}/pyconfig-target.h
> +    fi
> +
> +    install -m 644 ${STAGING_INCDIR_NATIVE}/python${PYTHON_BASEVERSION}${PYTHON_ABI}/pyconfig.h \
> +       ${CROSSTOOL_PYTHON_INCLUDE_PATH}/pyconfig-native.h
> +
> +    cat > ${CROSSTOOL_PYTHON_INCLUDE_PATH}/pyconfig.h <<ENDOF
> +#if defined (_PYTHON_INCLUDE_TARGET)
> +#include "pyconfig-target.h"
> +#elif defined (_PYTHON_INCLUDE_NATIVE)
> +#include "pyconfig-native.h"
> +#else
> +#error "_PYTHON_INCLUDE_TARGET or _PYTHON_INCLUDE_NATIVE is not defined"
> +#endif // End of #if defined (_PYTHON_INCLUDE_TARGET)
> +
> +ENDOF
> +
> +    mkdir -p ${S}/third_party/toolchains/yocto/
> +    sed "s#%%CPU%%#${BAZEL_TARGET_CPU}#g" ${WORKDIR}/BUILD.in  > ${S}/third_party/toolchains/yocto/BUILD
> +    chmod 644 ${S}/third_party/toolchains/yocto/BUILD
> +    install -m 644 ${WORKDIR}/cc_config.bzl.tpl ${S}/third_party/toolchains/yocto/
> +    install -m 644 ${WORKDIR}/yocto_compiler_configure.bzl ${S}/third_party/toolchains/yocto/
> +    install -m 644 ${WORKDIR}/BUILD.yocto_compiler ${S}
> +
> +    CT_NAME=$(echo ${HOST_PREFIX} | rev | cut -c 2- | rev)
> +    SED_COMMAND="s#%%CT_NAME%%#${CT_NAME}#g"
> +    SED_COMMAND="${SED_COMMAND}; s#%%WORKDIR%%#${WORKDIR}#g"
> +    SED_COMMAND="${SED_COMMAND}; s#%%YOCTO_COMPILER_PATH%%#${BAZEL_OUTPUTBASE_DIR}/external/yocto_compiler#g"
> +
> +    sed -i "${SED_COMMAND}" ${S}/BUILD.yocto_compiler \
> +                            ${S}/WORKSPACE
> +
> +    ${TF_CONFIG} \
> +    ./configure
> +}
> +
> +TF_TARGET_EXTRA ??= ""
> +
> +export CUSTOM_BAZEL_FLAGS = " \
> +    ${TF_ARGS_EXTRA} \
> +    --jobs=auto \
> +    -c opt \
> +    --cpu=${BAZEL_TARGET_CPU} \
> +    --crosstool_top=@local_config_yocto_compiler//:toolchain \
> +    --host_crosstool_top=@bazel_tools//tools/cpp:toolchain \
> +"
> +
> +do_compile () {
> +    export CT_NAME=$(echo ${HOST_PREFIX} | rev | cut -c 2- | rev)
> +    unset CC
> +
> +    ${BAZEL} build \
> +        ${CUSTOM_BAZEL_FLAGS} \
> +        --copt -DTF_LITE_DISABLE_X86_NEON --copt -DMESA_EGL_NO_X11_HEADERS \
> +        tensorflow/lite:libtensorflowlite.so \
> +        tensorflow/lite/tools/benchmark:benchmark_model \
> +        //tensorflow/lite/examples/label_image:label_image \
> +        ${TF_TARGET_EXTRA}
> +
> +    # build pip package
> +    ${S}/tensorflow/lite/tools/pip_package/build_pip_package_with_bazel.sh
> +
> +}
> +
> +do_install() {
> +    install -d ${D}${libdir}
> +    install -m 644 ${S}/bazel-bin/tensorflow/lite/libtensorflowlite.so \
> +        ${D}${libdir}
> +
> +    install -d ${D}${sbindir}
> +    install -m 755 ${S}/bazel-bin/tensorflow/lite/tools/benchmark/benchmark_model \
> +        ${D}${sbindir}
> +
> +    install -m 755 ${S}/bazel-bin/tensorflow/lite/examples/label_image/label_image \
> +        ${D}${sbindir}/label_image
> +
> +    install -d ${D}${datadir}/label_image
> +    install -m 644 ${WORKDIR}/imagenet_slim_labels.txt ${D}${datadir}/label_image
> +    install -m 644 ${WORKDIR}/inception_v3_2016_08_28_frozen.pb \
> +        ${D}${datadir}/label_image
> +    install -m 644 ${S}/tensorflow/examples/label_image/data/grace_hopper.jpg \
> +        ${D}${datadir}/label_image
> +
> +    install -m 644 ${WORKDIR}/labels_mobilenet_quant_v1_224.txt ${D}${datadir}/label_image
> +    install -m 644 ${WORKDIR}/mobilenet_v1_1.0_224_quant.tflite \
> +        ${D}${datadir}/label_image
> +    install -m 644 ${S}/tensorflow/lite/examples/label_image/testdata/grace_hopper.bmp \
> +        ${D}${datadir}/label_image
> +
> +
> +    #echo "Installing pip package"
> +    install -d ${D}/${PYTHON_SITEPACKAGES_DIR}
> +    ${STAGING_BINDIR_NATIVE}/pip3 install --disable-pip-version-check -v \
> +        -t ${D}/${PYTHON_SITEPACKAGES_DIR} --no-cache-dir --no-deps \
> +        ${S}/tensorflow/lite/tools/pip_package/gen/tflite_pip/python3/dist/tflite_runtime-${PV}-*.whl
> +
> +}
> +
> +FILES:${PN} += "${libdir} ${sbindir} ${datadir}/*"
> +INSANE_SKIP:${PN} += "dev-so \
> +                      already-stripped \
> +                     "
> +
> +SOLIBS = ".so"
> +FILES_SOLIBSDEV = ""
> +ALLOW_EMPTY:${PN} = "1"
> +
> +FILES:${PN} += "${libdir} /home/root/*"
> +
> +inherit siteinfo unsupportarch
> +python __anonymous() {
> +    if d.getVar("SITEINFO_ENDIANNESS") == 'be':
> +        msg =  "\nIt failed to use pre-build model to do predict/inference on big-endian platform"
> +        msg += "\n(such as qemumips), since upstream does not support big-endian very well."
> +        msg += "\nDetails: https://github.com/tensorflow/tensorflow/issues/16364"
> +        bb.warn(msg)
> +}
>
>
>
>
>


--
# Randy MacLeod
# Wind River Linux


1181 - 1200 of 57104