Re: [yocto] On managing debug and production builds

2022-03-01 Thread Josef Holzmayr
Howdy!

Karthik Poduval  schrieb am Mi. 2. März 2022 um
04:23:

> This concept of user vs debug builds is there in Android and any
> Android developer who gets introduced to yocto may look for these
> options. There seem to be many implementation choices here, trying to
> summarize some of the options here.
>
> 1. use different image recipes example-image-user.bb vs
> example-image-debug.bb but this still poses a problem for kernel
> recipes as kernel needs to have different config fragments or
> different defconfig for debug vs user variants. One possible option is
> to use KTYPE to select tiny vs standard or define own for custom BSP
> layers. What about other recipes like u-boot or firmware for other
> remote processors, how to percolate the debug vs user options to those
> recipes via just an image recipe ?


As a recipe cannot affect another recipe, and image recipes are obviously
recipes too, this is usually not useful.


> 2. use different configs using multiconfig. Base config (which is
> debug) also selects the user config hence always building both build
> variants in different tmp directories. Kernel, remote firmware and
> image recipes use variables from the multiconfig cof files to decide
> whether to build debug or user variants.


The whole point of multiconfig is builds depending on each other. I don’t
think it applies here.


> 3. use different distros. DSITRO=user bitbake example-image,
> DISTRO=debug example-image. Kernel and remote firmware recipes use
> variables from the distro to decide whether to build debug or user
> variants.


This is clearly the standard way.


>
> Which is the best method ?
> All these options seem very BSP layer specific, is there something
> more generic and better than the above options ?
> If not, should this be a feature request to the Yocto project ?
>
> NOTE: debug variants may include the following.
> - more debug related kernel configs and security loosened and UART
> ports disabled
> - image recipe debug variant may include debug utilities absent from
> the user variant


Easily archived with 3.


>
> There could be more than just debug and user variants. Android has
> engineering, tests, user, tiny and user-debug.


See 3. You can have an arbitrary number of distros, interrelated however
you wish.

Greetz


> --
> Regards,
> Karthik Poduval
>
> On Tue, Mar 1, 2022 at 1:26 AM tomzy  wrote:
> >
> > Thanks Tomasz. I will check kas.
> >
> > No problem
> >
> > Yes, for selecting some of the packages I have created prod and debug
> image
> > recipes.But this did not work for the kernel as the kernel recipe is
> picked
> > as part of PROVIDERin machine conf.
> >
> > What are the difference there? You want to use different config on prod
> and debug images?
> > Maybe add it as config fragments? Then you would need to add some global
> variable to
> > distinguish when use given .cfg file.
> >
> > [1]
> https://docs.yoctoproject.org/singleindex.html#creating-configuration-fragments
> >
> > SoI had to use 2 conf to have the
> > IMAGE_FEATURES (orany other var)set differently for prod and debug. This
> is for
> > building the kernelrecipie differently for prodand debug. Setting the
> > IMAGE_FEATURES in the image recipe (and not inconf) causes2 problems.
> One is
> > that kernel and other bootloaders recipes arepicked early via PROVIDER
> in conf
> > and not as packages included in image recipe.
> >
> > Is that a problem?
> >
> > Secondly,setting the var in the
> > image recipe breaks this command for e.g.
> > "bitbake base-image-prod.bbbase-image-debug.bb".
> >
> > Didn't you want to distinguish this to builds to be able to run `bitbake
> base-image-prod` or
> > `bitbake base-image-debug`?
> >
> > Since the command parses the recipes only once for both image creation.
> >
> >
> > Nevertheless I would greatly recommend you to use kas. In simple .yml
> file you
> > could prepare different `local.conf` per configuration prod/debug.
> >
> > [2]
> https://kas.readthedocs.io/en/latest/userguide.html#project-configuration
> >
> > Regards,
> > Tomasz Żyjewski
> > Embedded Systems Engineer
> > GPG: 5C495EA3EBEECA59
> > https://3mdeb.com | @3mdeb_com
> >
> >
> >
> >
>
> 
>
>

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



Re: [yocto] On managing debug and production builds

2022-03-01 Thread Vinayak Menon
Add list. missed earlier.

On Wed, Mar 2, 2022 at 8:11 AM Vinayak Menon  wrote:
>
> On Tue, Mar 1, 2022 at 2:56 PM tomzy  wrote:
> >
> > Thanks Tomasz. I will check kas.
> >
> > No problem
> >
> > Yes, for selecting some of the packages I have created prod and debug image
> > recipes.But this did not work for the kernel as the kernel recipe is picked
> > as part of PROVIDERin machine conf.
> >
> > What are the difference there? You want to use different config on prod and 
> > debug images?
> > Maybe add it as config fragments? Then you would need to add some global 
> > variable to
> > distinguish when use given .cfg file.
>
> Ya, and I am using exisitng IMAGE_FEATURE instead of the global var. I
> can use global var too.
> The only thing is that I am setting the global var from a conf and not
> image recipe.
>
> >
> > [1] 
> > https://docs.yoctoproject.org/singleindex.html#creating-configuration-fragments
> >
> > SoI had to use 2 conf to have the
> > IMAGE_FEATURES (orany other var)set differently for prod and debug. This is 
> > for
> > building the kernelrecipie differently for prodand debug. Setting the
> > IMAGE_FEATURES in the image recipe (and not inconf) causes2 problems. One is
> > that kernel and other bootloaders recipes are picked early via PROVIDER in 
> > conf
> > and not as packages included in image recipe.
> >
> > Is that a problem?
>
> Ya you are right, that is not a problem as such. But I have seen in the yocto
> documentation that IMAGE_FEATURES are recommended to be set from conf.
> Is there any reason for such a recommendation ?
>
> >
> > Secondly,setting the var in the
> > image recipe breaks this command for e.g.
> > "bitbake base-image-prod.bbbase-image-debug.bb".
> >
> > Didn't you want to distinguish this to builds to be able to run `bitbake 
> > base-image-prod` or
> > `bitbake base-image-debug`?
>
> Yes I want to distinguish, and as a developer I can give separate
> bitbake commands. But the
> thought was that later the user can issue commands the way they want.
> And if they use it in
> combined manner described above, expecting 2 images with different
> kernels, it does not work.
>
>
> >
> > Since the command parses the recipes only once for both image creation.
> >
> >
> > Nevertheless I would greatly recommend you to use kas. In simple .yml file 
> > you
> > could prepare different `local.conf` per configuration prod/debug.
>
> Sure, I will explore this.
>
>
> >
> > [2] 
> > https://kas.readthedocs.io/en/latest/userguide.html#project-configuration
> >
> > Regards,
> > Tomasz Żyjewski
> > Embedded Systems Engineer
> > GPG: 5C495EA3EBEECA59
> > https://3mdeb.com | @3mdeb_com
> >
> >
> > 
> >
>
>
> --
> vinayak



-- 
vinayak

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



Re: [yocto] On managing debug and production builds

2022-03-01 Thread Karthik Poduval
This concept of user vs debug builds is there in Android and any
Android developer who gets introduced to yocto may look for these
options. There seem to be many implementation choices here, trying to
summarize some of the options here.

1. use different image recipes example-image-user.bb vs
example-image-debug.bb but this still poses a problem for kernel
recipes as kernel needs to have different config fragments or
different defconfig for debug vs user variants. One possible option is
to use KTYPE to select tiny vs standard or define own for custom BSP
layers. What about other recipes like u-boot or firmware for other
remote processors, how to percolate the debug vs user options to those
recipes via just an image recipe ?
2. use different configs using multiconfig. Base config (which is
debug) also selects the user config hence always building both build
variants in different tmp directories. Kernel, remote firmware and
image recipes use variables from the multiconfig cof files to decide
whether to build debug or user variants.
3. use different distros. DSITRO=user bitbake example-image,
DISTRO=debug example-image. Kernel and remote firmware recipes use
variables from the distro to decide whether to build debug or user
variants.

Which is the best method ?
All these options seem very BSP layer specific, is there something
more generic and better than the above options ?
If not, should this be a feature request to the Yocto project ?

NOTE: debug variants may include the following.
- more debug related kernel configs and security loosened and UART
ports disabled
- image recipe debug variant may include debug utilities absent from
the user variant

There could be more than just debug and user variants. Android has
engineering, tests, user, tiny and user-debug.

--
Regards,
Karthik Poduval

On Tue, Mar 1, 2022 at 1:26 AM tomzy  wrote:
>
> Thanks Tomasz. I will check kas.
>
> No problem
>
> Yes, for selecting some of the packages I have created prod and debug image
> recipes.But this did not work for the kernel as the kernel recipe is picked
> as part of PROVIDERin machine conf.
>
> What are the difference there? You want to use different config on prod and 
> debug images?
> Maybe add it as config fragments? Then you would need to add some global 
> variable to
> distinguish when use given .cfg file.
>
> [1] 
> https://docs.yoctoproject.org/singleindex.html#creating-configuration-fragments
>
> SoI had to use 2 conf to have the
> IMAGE_FEATURES (orany other var)set differently for prod and debug. This is 
> for
> building the kernelrecipie differently for prodand debug. Setting the
> IMAGE_FEATURES in the image recipe (and not inconf) causes2 problems. One is
> that kernel and other bootloaders recipes arepicked early via PROVIDER in conf
> and not as packages included in image recipe.
>
> Is that a problem?
>
> Secondly,setting the var in the
> image recipe breaks this command for e.g.
> "bitbake base-image-prod.bbbase-image-debug.bb".
>
> Didn't you want to distinguish this to builds to be able to run `bitbake 
> base-image-prod` or
> `bitbake base-image-debug`?
>
> Since the command parses the recipes only once for both image creation.
>
>
> Nevertheless I would greatly recommend you to use kas. In simple .yml file you
> could prepare different `local.conf` per configuration prod/debug.
>
> [2] https://kas.readthedocs.io/en/latest/userguide.html#project-configuration
>
> Regards,
> Tomasz Żyjewski
> Embedded Systems Engineer
> GPG: 5C495EA3EBEECA59
> https://3mdeb.com | @3mdeb_com
>
>
> 
>

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



[yocto] [meta-gplv2] [PATCH] recipes: Convert to use SPDX license names in LICENSE variables

2022-03-01 Thread Richard Purdie
This uses the script from OE-Core to make the conversion.

Signed-off-by: Richard Purdie 
---
 recipes-bsp/grub/grub_0.97.bb |  2 +-
 recipes-core/coreutils/coreutils_6.9.bb   |  2 +-
 recipes-core/gettext/gettext_0.16.1.bb|  2 +-
 recipes-core/readline/readline_5.2.bb |  2 +-
 recipes-devtools/bison/bison_2.3.bb   |  2 +-
 recipes-devtools/dosfstools/dosfstools_2.11.bb|  2 +-
 recipes-devtools/elfutils/elfutils_0.148.bb   |  2 +-
 recipes-devtools/m4/m4-1.4.9.inc  |  2 +-
 recipes-devtools/make/make_3.81.bb|  2 +-
 recipes-devtools/mtools/mtools_3.9.9.bb   |  2 +-
 recipes-devtools/patch/patch_2.5.9.bb |  2 +-
 recipes-devtools/rsync/rsync_2.6.9.bb |  2 +-
 recipes-extended/bash/bash_3.2.57.bb  |  2 +-
 recipes-extended/bc/bc_1.06.bb|  2 +-
 recipes-extended/cpio/cpio_2.8.bb |  2 +-
 recipes-extended/diffutils/diffutils_2.8.1.bb |  2 +-
 recipes-extended/ed/ed_0.5.bb |  2 +-
 recipes-extended/findutils/findutils_4.2.31.bb|  2 +-
 recipes-extended/gawk/gawk_3.1.5.bb   |  2 +-
 recipes-extended/gperf/gperf.inc  |  2 +-
 recipes-extended/gperf/gperf_3.0.3.bb |  2 +-
 recipes-extended/grep/grep_2.5.1a.bb  |  2 +-
 recipes-extended/groff/groff_1.18.1.4.bb  |  2 +-
 recipes-extended/gzip/gzip_1.3.12.bb  |  2 +-
 recipes-extended/libidn/libidn_0.6.14.bb  |  2 +-
 recipes-extended/mc/mc_4.7.5.2.bb |  2 +-
 recipes-extended/msmtp/msmtp_1.4.12.bb|  2 +-
 recipes-extended/sed/sed_4.1.2.bb |  2 +-
 recipes-extended/tar/tar_1.17.bb  |  2 +-
 recipes-extended/texinfo/texinfo_4.8.bb   |  2 +-
 recipes-extended/time/time_1.7.bb |  2 +-
 recipes-extended/which/which_2.18.bb  |  2 +-
 recipes-sato/rxvt-unicode/rxvt-unicode_9.20.bb|  2 +-
 recipes-support/gdbm/gdbm_1.8.3.bb|  2 +-
 recipes-support/gmp/gmp_4.2.1.bb  |  4 ++--
 recipes-support/gnupg/gnupg_1.4.7.bb  |  2 +-
 recipes-support/gnutls/gnutls.inc | 10 +-
 recipes-support/libiconv/libiconv_1.11.1.bb   |  2 +-
 recipes-support/nettle/nettle_2.7.1.bb|  4 ++--
 recipes-support/shared-mime-info/shared-mime-info.inc |  2 +-
 40 files changed, 46 insertions(+), 46 deletions(-)

diff --git a/recipes-bsp/grub/grub_0.97.bb b/recipes-bsp/grub/grub_0.97.bb
index 3845c94..e6934b9 100644
--- a/recipes-bsp/grub/grub_0.97.bb
+++ b/recipes-bsp/grub/grub_0.97.bb
@@ -5,7 +5,7 @@ standard, which allows for flexible loading of multiple boot 
images."
 HOMEPAGE = "http://www.gnu.org/software/grub/";
 SECTION = "bootloaders"
 
-LICENSE = "GPLv2+"
+LICENSE = "GPL-2.0-or-later"
 LIC_FILES_CHKSUM = "file://COPYING;md5=c93c0550bd3173f4504b2cbd8991e50b \
 
file://grub/main.c;beginline=3;endline=9;md5=22a5f28d2130fff9f2a17ed54be90ed6"
 
diff --git a/recipes-core/coreutils/coreutils_6.9.bb 
b/recipes-core/coreutils/coreutils_6.9.bb
index 8f24556..cc00de0 100644
--- a/recipes-core/coreutils/coreutils_6.9.bb
+++ b/recipes-core/coreutils/coreutils_6.9.bb
@@ -5,7 +5,7 @@ every system."
 
 HOMEPAGE = "http://www.gnu.org/software/coreutils/";
 BUGTRACKER = "http://debbugs.gnu.org/coreutils";
-LICENSE = "GPLv2+"
+LICENSE = "GPL-2.0-or-later"
 LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe \
 
file://src/ls.c;beginline=4;endline=16;md5=15ed60f67b1db5fedd5dbc37cf8a9543"
 PR = "r5"
diff --git a/recipes-core/gettext/gettext_0.16.1.bb 
b/recipes-core/gettext/gettext_0.16.1.bb
index 941a9d2..cd632ba 100644
--- a/recipes-core/gettext/gettext_0.16.1.bb
+++ b/recipes-core/gettext/gettext_0.16.1.bb
@@ -2,7 +2,7 @@ SUMMARY = "Utilities and libraries for producing multi-lingual 
messages"
 DESCRIPTION = "GNU gettext is a set of tools that provides a framework to help 
other programs produce multi-lingual messages. These tools include a set of 
conventions about how programs should be written to support message catalogs, a 
directory and file naming organization for the message catalogs themselves, a 
runtime library supporting the retrieval of translated messages, and a few 
stand-alone programs to massage in various ways the sets of translatable and 
already translated strings."
 HOMEPAGE = "http://www.gnu.org/software/gettext/gettext.html";
 SECTION = "libs"
-LICENSE = "GPLv2"
+LICENSE = "GPL-2.0-only"
 LIC_FILES_CHKSUM = "file://COPYING;md5=9ea3144f04c41cd2eada5d3f472e6ea5"
 
 PR = "r6"
diff --git a/recipes-core/readline/readline_5.2.bb 
b/recipes-core/readline/readline_5.2.bb
index aa2799e..d42ce8b 100644
--- a/recipes-core/r

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

2022-03-01 Thread Richard Purdie
On Tue, 2022-03-01 at 06:13 -0800, Armin Kuster wrote:
> 
> On 2/28/22 11:44, Teoh, Jay Shen wrote:
> > Hi Everyone,
> > 
> > This is the full report for yocto-3.3.5.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.
> 
> As a YP TSC member, I am fine releasing this build.
> 
> I will let Richard send the final word once the rest of the YP TSC respond.

The TSC discussed today and is happy to release, thanks!

Cheers,

Richard


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



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

2022-03-01 Thread Stephen Jolley
All,

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


Priority

Bug ID

Short Description

Changer

Owner

Was

Became


Medium+

  11528

Enable simple toolchain switching

randy.macl...@windriver.com

r...@burtonini.com

3.99

3.6


 

  14726

AB-INT-NET: fetch failure in fetch.Fetch.test_git_mirrors

randy.macl...@windriver.com

mhalst...@linuxfoundation.org

3.5

3.5 M4

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 (#56343): https://lists.yoctoproject.org/g/yocto/message/56343
Mute This Topic: https://lists.yoctoproject.org/mt/89480776/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[yocto] Enhancements/Bugs closed WW09!

2022-03-01 Thread Stephen Jolley
All,

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


Who

Count


richard.pur...@linuxfoundation.org

9


tim.orl...@konsulko.com

3


randy.macl...@windriver.com

2


pa...@zhukoff.net

1


r...@burtonini.com

1


Grand Total

16

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 (#56342): https://lists.yoctoproject.org/g/yocto/message/56342
Mute This Topic: https://lists.yoctoproject.org/mt/89480748/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

2022-03-01 Thread Stephen Jolley
All,

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


Who

Count


michael.opdenac...@bootlin.com

35


r...@burtonini.com

34


randy.macl...@windriver.com

24


david.re...@windriver.com

22


bruce.ashfi...@gmail.com

18


tim.orl...@konsulko.com

15


sakib.sa...@windriver.com

13


trevor.gamb...@windriver.com

12


mhalst...@linuxfoundation.org

10


richard.pur...@linuxfoundation.org

10


saul.w...@windriver.com

7


bluelightn...@bluelightning.org

6


kai.k...@windriver.com

6


chee.yang@intel.com

4


hongxu@windriver.com

4


jpewhac...@gmail.com

4


jon.ma...@arm.com

3


qi.c...@windriver.com

3


ms...@mvista.com

2


akuster...@gmail.com

2


pokyli...@reliableembeddedsystems.com

2


sundeep.kokko...@gmail.com

2


alexandre.bell...@bootlin.com

2


alejan...@enedino.org

2


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

1


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

1


jas...@gmail.com

1


liezhi.y...@windriver.com

1


yf...@uwaterloo.ca

1


martin.ja...@gmail.com

1


ticot...@gmail.com

1


yi.z...@windriver.com

1


martin.bee...@online.de

1


aeh...@gmail.com

1


mostthings...@gmail.com

1


matthew...@posteo.net

1


thomas.per...@bootlin.com

1


kexin@windriver.com

1


pgowda@gmail.com

1


raj.k...@gmail.com

1


mingli...@windriver.com

1


shac...@vdoo.com

1


pa...@zhukoff.net

1


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

1


nicolas.deche...@linaro.org

1


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

1


and...@gherzan.com

1


Grand Total

265

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 (#56341): https://lists.yoctoproject.org/g/yocto/message/56341
Mute This Topic: https://lists.yoctoproject.org/mt/89480621/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

2022-03-01 Thread 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 396
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 (#56340): https://lists.yoctoproject.org/g/yocto/message/56340
Mute This Topic: https://lists.yoctoproject.org/mt/89480593/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[yocto] Yocto Project Status WW09`22

2022-03-01 Thread Stephen Jolley
Current Dev Position: YP 3.5 M4

Next Deadline: 4th April. 2022 YP 3.5 M4 build

 

Next Team Meetings:

*   Bug Triage meeting Thursday Mar. 3rd 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 Mar. 8th  at 8 am PDT (

https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09
 )
*   Twitch -  See https://www.twitch.tv/theyoctojester

 

Key Status/Updates:

*   We are now at feature freeze for 3.5, our next LTS release
*   YP 3.3.5 is out of QA and pending release approval
*   Inclusive language changes have merged however there are still:

*   Incompatible license related variable changes
*   Function variable name changes needed
*   No migration documentation or documentation of the changes
*   No documentation of the bitbake rename code
*   No updates to the manual for the variable renames

We do need people to pull things together and finish things off, help in
doing that is needed and much appreciated.

*   There is a pending patch to warn about old style license identifiers
pending in master-next and due to be posted for review. On balance this is
probably a good thing to get into the LTS but we're open to input on that.
*   The incompatible license changes will mean anyone using those
variables will need to update what they're doing carefully. Patches in
master-next now pass testing and are due to be posted on the mailing list.
*   The python build process change to use wheels has merged. That
change has caused some disruption but was close enough to being ready it
seemed worth making the final push for inclusion.
*   The infrastructure move was successful and all services should be
restored. There are some networking issues occurring on autobuilder builds
which are preventing release builds at this time and are being looked into.
*   As such, the M3 release build will likely happen late this week or
early next week.
*   If people see intermittent issues in their own builds, particularly
if they're the same as intermittent issues seen on the autobuilder, please
do comment in the bugs mentioning when they happen as the frequency
information does help us prioritize fixing the most common issues.
*   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:

*   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_Enhan
cements.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/main
tainers.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.3.5  is out of QA
*   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 2679 (last week 2652) (

https://wiki.yoctoproject.org/charts/combo.html)
*   OE-Core/Poky Patch Metrics

*   Total patches found: 1202 (last week 1202)
*   Pa

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

2022-03-01 Thread Armin Kuster



On 2/28/22 11:44, Teoh, Jay Shen wrote:

Hi Everyone,

This is the full report for yocto-3.3.5.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.


As a YP TSC member, I am fine releasing this build.

I will let Richard send the final word once the rest of the YP TSC respond.

- Armin




Thanks,
Jay

-Original Message-
From: yocto@lists.yoctoproject.org  On
Behalf Of Richard Purdie
Sent: Tuesday, 22 February, 2022 5:51 PM
To:  
Cc: qa-build-notification 
Subject: [yocto] QA notification for completed autobuilder build (yocto-
3.3.5.rc1)

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


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


Build hash information:

bitbake: aaa7f7af23d5f89fe4a5ed48c57ea3dfca07c79d
meta-agl: 9a50bd62dfac0d6ea1320b2ee083529cb98b9f92
meta-arm: fe35ff5ba809bf4826adfe65899a84e9c99494e8
meta-aws: 6801abf40bb255a31bce5061c5c6b72f5e2a8f58
meta-gplv2: 9e119f333cc8f53bd3cf64326f826dbc6ce3db0f
meta-intel: 36e915402dfe317654568f09f18fb6f7653603bc
meta-mingw: 422b96cb2b6116442be1f40dfb5bd77447d1219e
meta-openembedded: 23598caeafce0af0dde8d1339cf5edff021f6823
oecore: 29cd1d796057ef5599fe17c39b42aa099f7b1c29
poky: 8d3e054f6d432b5ca0fcd613e0c767fab3c85f24



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











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



[yocto] [PATCH yocto-autobuilder-helper] auh-config: correct LICENSE_FLAGS variable

2022-03-01 Thread Alexander Kanavin
Signed-off-by: Alexander Kanavin 
---
 scripts/auh-config/local.conf.append | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/auh-config/local.conf.append 
b/scripts/auh-config/local.conf.append
index 25c062b..52e507f 100644
--- a/scripts/auh-config/local.conf.append
+++ b/scripts/auh-config/local.conf.append
@@ -1,5 +1,5 @@
 
 INHERIT += "buildhistory"
-LICENSE_FLAGS_WHITELIST = "commercial"
+LICENSE_FLAGS_ACCEPTED = "commercial"
 DISTRO_FEATURES:append:libc-glibc = ' systemd'
 DISTRO_FEATURES:append = ' pam'
-- 
2.35.1


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



[yocto] [auto-upgrade-helper][PATCH] error.py: initialize stdout/stderr to empty strings

2022-03-01 Thread Alexander Kanavin
This avoids guarding them against NoneType everywhere

Signed-off-by: Alexander Kanavin 
---
 modules/errors.py| 2 +-
 modules/utils/devtool.py | 5 +
 2 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/modules/errors.py b/modules/errors.py
index fa543f7..48e8b70 100644
--- a/modules/errors.py
+++ b/modules/errors.py
@@ -24,7 +24,7 @@
 #
 
 class Error(Exception):
-def __init__(self, message=None, stdout=None, stderr=None):
+def __init__(self, message=None, stdout="", stderr=""):
 self.message = message
 self.stdout = stdout
 self.stderr = stderr
diff --git a/modules/utils/devtool.py b/modules/utils/devtool.py
index e4e028f..c26061f 100644
--- a/modules/utils/devtool.py
+++ b/modules/utils/devtool.py
@@ -19,10 +19,7 @@ class Devtool(object):
 raise DevtoolError("The following devtool command failed: " + 
operation,
 e.stdout, e.stderr)
 
-if stderr is None:
-return stdout
-else:
-return stdout + stderr
+return stdout + stderr
 
 def upgrade(self, recipe, version = None, revision = None):
 cmd = " upgrade " + recipe
-- 
2.30.2


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



Re: [yocto] On managing debug and production builds

2022-03-01 Thread tomzy
> 
> Thanks Tomasz. I will check kas.

No problem

> 
> Yes, for selecting some of the packages I have created prod and debug
> image
> recipes.But this did not work for the kernel as the kernel recipe is
> picked
> as part of PROVIDERin machine conf.

What are the difference there? You want to use different config on prod and 
debug images?
Maybe add it as config fragments? Then you would need to add some global 
variable to
distinguish when use given .cfg file.

[1] 
https://docs.yoctoproject.org/singleindex.html#creating-configuration-fragments

> 
> SoI had to use 2 conf to have the
> IMAGE_FEATURES (orany other var)set differently for prod and debug. This
> is for
> building the kernelrecipie differently for prodand debug. Setting the
> IMAGE_FEATURES in the image recipe (and not inconf) causes2 problems. One
> is
> that kernel and other bootloaders recipes arepicked early via PROVIDER in
> conf
> and not as packages included in image recipe.

Is that a problem?

> 
> Secondly,setting the var in the
> image recipe breaks this command for e.g.
> "bitbake base-image-prod.bbbase-image-debug.bb".

Didn't you want to distinguish this to builds to be able to run `bitbake 
base-image-prod` or
`bitbake base-image-debug`?

> 
> Since the command parses the recipes only once for both image creation.

Nevertheless I would greatly recommend you to use kas. In simple .yml file you
could prepare different `local.conf` per configuration prod/debug.

[2] https://kas.readthedocs.io/en/latest/userguide.html#project-configuration

Regards,
Tomasz Żyjewski
Embedded Systems Engineer
GPG: 5C495EA3EBEECA59
https://3mdeb.com | @3mdeb_com

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



Re: [yocto] On managing debug and production builds

2022-03-01 Thread Alexander Kanavin
If you can't do what you need with only image recipes, then the only
option is to create an additional DISTRO config I'm afraid. Putting
these tweaks into machine config or local.conf is not correct.

Alex

On Tue, 1 Mar 2022 at 09:52, Vinayak Menon  wrote:
>
> On Tue, Mar 1, 2022 at 12:34 PM tomzy  wrote:
> >
> > Hi Vinayak
> >
> > I believe that the best way to prepare debug and prod images is to create
> > include file (.inc) with base set of packages and features and then add two
> > .bb recipes, one for prod and one for debug - every of this recipes will 
> > need
> > to include the `.inc` file. You could name them `base-image-prod.bb` and
> > `base-image-debug.bb`. This way you could run either prod or debug builds
> > by running `bitbake base-image-debug` or `bitbake base-image-prod`.
> >
> > As for the machine, this would need to be set in local.conf every time you 
> > want
> > to switch the machine.To simplify this process, for the management of the
> > configuration of the entire build (including the selection of debug / prod 
> > image
> > or machine configuration), I recommend the kas[1] project with the very 
> > helpful
> > kas-container tool.
>
>
> Thanks Tomasz. I will check kas.
> Yes, for selecting some of the packages I have created prod and debug
> image recipes.
> But this did not work for the kernel as the kernel recipe is picked as
> part of PROVIDER
> in machine conf. SoI had to use 2 conf to have the IMAGE_FEATURES (or
> any other var)
> set differently for prod and debug. This is for building the kernel
> recipie differently for prod
> and debug. Setting the IMAGE_FEATURES in the image recipe (and not in
> conf) causes
> 2 problems. One is that kernel and other bootloaders recipes are
> picked early via PROVIDER
>  in conf and not as packages included in image recipe. Secondly,
> setting the var in the image
> recipe breaks this command for e.g. "bitbake base-image-prod.bb
> base-image-debug.bb".
> Since the command parses the recipes only once for both image creation.
>
>
>
> >
> > [1] https://github.com/siemens/kas
> >
> > Regards,
> > Tomasz Żyjewski
> > Embedded Systems Engineer
> > GPG: 5C495EA3EBEECA59
> > https://3mdeb.com | @3mdeb_com
> >
> >
> >
> >
>
>
> --
> vinayak
>
> 
>

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



Re: [yocto] On managing debug and production builds

2022-03-01 Thread Vinayak Menon
On Tue, Mar 1, 2022 at 12:34 PM tomzy  wrote:
>
> Hi Vinayak
>
> I believe that the best way to prepare debug and prod images is to create
> include file (.inc) with base set of packages and features and then add two
> .bb recipes, one for prod and one for debug - every of this recipes will need
> to include the `.inc` file. You could name them `base-image-prod.bb` and
> `base-image-debug.bb`. This way you could run either prod or debug builds
> by running `bitbake base-image-debug` or `bitbake base-image-prod`.
>
> As for the machine, this would need to be set in local.conf every time you 
> want
> to switch the machine.To simplify this process, for the management of the
> configuration of the entire build (including the selection of debug / prod 
> image
> or machine configuration), I recommend the kas[1] project with the very 
> helpful
> kas-container tool.


Thanks Tomasz. I will check kas.
Yes, for selecting some of the packages I have created prod and debug
image recipes.
But this did not work for the kernel as the kernel recipe is picked as
part of PROVIDER
in machine conf. SoI had to use 2 conf to have the IMAGE_FEATURES (or
any other var)
set differently for prod and debug. This is for building the kernel
recipie differently for prod
and debug. Setting the IMAGE_FEATURES in the image recipe (and not in
conf) causes
2 problems. One is that kernel and other bootloaders recipes are
picked early via PROVIDER
 in conf and not as packages included in image recipe. Secondly,
setting the var in the image
recipe breaks this command for e.g. "bitbake base-image-prod.bb
base-image-debug.bb".
Since the command parses the recipes only once for both image creation.



>
> [1] https://github.com/siemens/kas
>
> Regards,
> Tomasz Żyjewski
> Embedded Systems Engineer
> GPG: 5C495EA3EBEECA59
> https://3mdeb.com | @3mdeb_com
>
>
> 
>


-- 
vinayak

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