Date   

Yocto Project Status WW13`21

Stephen Jolley
 

Current Dev Position: YP 3.3 M4 (Feature Freeze)

Next Deadline: 5th April 2021 YP 3.3 M4 build

 

Next Team Meetings:

 

Key Status/Updates:

  • YP 3.3 M3 has been released, the issue with beaglebone was resolved.
  • YP 3.2.3 has been built and is in QA.
  • It was a quiet week for patches whilst the M3 issues were resolved. We’re not taking non-essential version upgrades at this point. There are some tweaks to meson’s native build handling and some selftest parallelism unittest output handling fixes pending.
  • Intermittent autobuilder issues continue to occur and are now at a record high level. 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

We are working to identify the load pattern on the infrastructure that seems to trigger these.

 

Ways to contribute:

 

YP 3.3 Milestone Dates:

  • YP 3.3 M3 has been released.
  • YP 3.3 M4 build date 2021/04/05
  • YP 3.3 M4 Release date 2021/04/30

 

Planned upcoming dot releases:

  • YP 3.2.3 is in QA.
  • YP 3.1.7 build date 2021/03/29
  • YP 3.1.7 release date 2021/04/09
  • YP 3.2.4 build date 2021/05/3
  • YP 3.2.4 release date 2021/05/14
  • YP 3.1.8 build date 2021/05/17
  • YP 3.1.8 release date 2021/05/28

 

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

 


SDK build artifacts describing software composition

keydi
 

I wonder if all the artifacts described in YP Development Manual, current release, ch. 3.32*
yet only those describing software composition (for purposes of compliance with copyleft software)
will change if one builds SDK additionally to target system image.

Is it recommended to start analysis of mentioned artifacts not until SDK is built
if analysis results have to describe also software composition in SDK; rather doesn't matter?

*) Chapter title "Working With Licenses"


Re: Get PR value of another recipe

Quentin Schulz
 

Hi Mauro,

On Tue, Mar 30, 2021 at 02:44:14PM +0200, Mauro Ziliani wrote:
Hi all.

From an image recipe a-image_1.0.bb with IMAGE_INSTALL_append = " a " defined, can I get the PR value of recipe a?
No. Recipe data is local to the recipe.

Cheers,
Quentin


Get PR value of another recipe

Mauro Ziliani
 

Hi all.

From an image recipe a-image_1.0.bb with IMAGE_INSTALL_append = " a " defined, can I get the PR value of  recipe a?

a_1.0.bb:  
     PR="r5"

a-image_1.0.bb:
A_PR_VALUE := " <get PR of >"

MZ

Sent from Mailspring, the best free email app for work


Re: Naming images

Damien LEFEVRE
 

Thanks Quentin! That's just what I needed.

Do you know if there's a variable to control the content of /etc/version?

Cheers,
-Damien

On Mon, Mar 29, 2021 at 4:14 PM Quentin Schulz <quentin.schulz@...> wrote:
Hi Damien,

On Mon, Mar 29, 2021 at 03:33:09PM +0300, Damien LEFEVRE wrote:
> Hi,
>
> In my build system the generated images are in this format:
>
> imagename-machine-timestamp.img
>
> For release builds, I'd like to replace the time stamp with the image
> version. I could rename the image after the build but is there a better way?
>

IMAGE_NAME variable is the one specifying the name which should be used
for the final image. c.f. https://docs.yoctoproject.org/ref-manual/variables.html#term-IMAGE_NAME

By default, its value is "${IMAGE_BASENAME}-${MACHINE}${IMAGE_VERSION_SUFFIX}"

IMAGE_VERSION_SUFFIX is by default set to "-${DATETIME}" as documented
here: https://docs.yoctoproject.org/ref-manual/variables.html#term-IMAGE_VERSION_SUFFIX

Therefore to put the image version, you just need to change
IMAGE_VERSION_SUFFIX to what you want it to contain.

Cheers,
Quentin


Re: eula-downloads.yoctoproject.org down???

Josef Holzmayr
 

Am Di., 30. März 2021 um 05:22 Uhr schrieb anthony.l via
lists.yoctoproject.org <anthony.l=axxin.com@lists.yoctoproject.org>:

Getting a message today
Fetcher failure for URL: 'https://eula-downloads.yoctoproject.org/index.php'. URL https://eula-downloads.yoctoproject.org/index.php doesn't work. Please ensure your network is configured correctly.

Can't ping the url? Anyone have an ETA on this being back up? Just trying to get some urgent builds done today.
Please see https://www.yoctoproject.org/pipermail/poky/2016-January/010357.html

If you are experiencing problems, you can override the connectivity
check, and then please revisit your versions and/or third party
layers.

Greetz


Many thanks.
Anthony


How can I use old Package version with latest Yocto version. #cups #zeus

rohit jadhav
 

Hi
   I was using very old version of Yocto i.e. Krogoth. In that version I am able to use following packages with respective version:
    Package name   Version
   Cups                     2.2.4
   Cups-filter            1.14.0
   qpdf                      6.0.0
   Opencv                 2.4
It was working fine. But When I switch to any other version of Yocto like  Zeus [which I have tried on ].
Specifically for cups-filter pakage observed following errors while compilation and generation of rootfs
ERROR: cups-filters-1.14.0-r0 do_compile: oe_runmake failed
ERROR: cups-filters-1.14.0-r0 do_compile: Execution of '/home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/cortexa7t2hf-neon-poky-linux-gnueabi/cups-filters/1.14.0-r0/temp/run.do_compile.17590' failed with exit code 1:

It is observed due to wrong c standard while compilation as some log says as follow:
warning: ISO C99 doesn't support unnamed structs/unions [-Wpedantic]
warning: ' LPT #' directive output may be truncated writing 6 bytes into a region of size between 1 and 1024 [-Wformat-truncation=]
warning: 'strncpy' specified bound 1024 equals destination size [-Wstringop-truncation]
filter/pdftoopvp/oprs/OPVPSplash.h:53:3: error: 'GBool' does not name a type

Just Need some guideline to resolve this issue.
Please also suggest is there any way to use old pakage of Yocto version to latest Yocto version.
Thanks and Regards
Rohit


Re: Can't build gatesgarth after PSEUDO_IGNORE_PATHS change in poky

Ramsay, Lincoln <Lincoln.Ramsay@...>
 

Hi,

Just to follow up on this, I eventually figured out the root cause, but I still don't understand why PSEUDO_IGNORE_PATHS was allowing it to work...

When I setup my PC, I created the user and then changed the UID of the user (for NFS auth reasons). The end result of this is that my user has UID 1111 but GID 1000.

I do all of my building in Docker and a user is created that (in theory) matches my real user so that ownership for bind-mounted locations “just works”. However, the in-Docker user has UID 1111 but GID 1111.

When bb.utils.copyfile tries to copy files, it is copying from a source directory that is 1111/1000 into a target directory that would be 1111/1111. I still don’t quite know how, but that seems to be behind the chmod failing.

The chmod failing is (as already noted) why the +x is lost on the postinstall_intercept script, which is why I got failing builds instead of just the chmod warnings.

I have fixed this by updating my Docker creation scripts (to ensure the in-Docker user has GID 1000) and to find and update all the files with GID 1111 to have GID 1000 instead.

find . -gid 1111 -print0 | xargs -0 chgrp -h 1000

I can once again build without patching poky :)

Lincoln


eula-downloads.yoctoproject.org down???

anthony.l@...
 

Getting a message today 
Fetcher failure for URL: 'https://eula-downloads.yoctoproject.org/index.php'. URL https://eula-downloads.yoctoproject.org/index.php doesn't work. Please ensure your network is configured correctly.

Can't ping the url?  Anyone have an ETA on this being back up?  Just trying to get some urgent builds done today.

Many thanks.
Anthony


M+ & H bugs with Milestone Movements WW13

Stephen Jolley
 

All,

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

Priority

Bug ID

Short Description

Changer

Owner

Was

Became

Medium+

10693

Add a testcase for multilib eSDK on the autobuilder

randy.macleod@...

Qi.Chen@...

3.3

3.4 M1

 

13025

WIC image install support

randy.macleod@...

kexin.hao@...

3.3

3.4 M1

 

13980

Investigate replacements for PhantomJS for buildperf output

randy.macleod@...

trevor.gamblin@...

3.3

3.3 M1

 

 

 

 

3.3 M1

3.4 M1

 

14099

PACKAGE_EXCLUDE not removing packages when PACKAGE_CLASSES = "package_deb"

randy.macleod@...

stacygaikovaia@...

3.3 M3

3.3 M4

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


3Enhancements/Bugs closed WW13!

Stephen Jolley
 

All,

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

Who

Count

randy.macleod@...

5

richard.purdie@...

2

ross@...

2

yifan.yu@...

2

raj.khem@...

1

kexin.hao@...

1

dorindabassey@...

1

nicolas.dechesne@...

1

sjolley.yp.pm@...

1

kai.kang@...

1

Grand Total

17

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

Stephen Jolley
 

All,

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

Who

Count

ross@...

17

bluelightning@...

14

richard.purdie@...

9

mark.morton@...

7

JPEWhacker@...

7

akuster808@...

5

raj.khem@...

4

chee.yang.lee@...

4

idadelm@...

3

Qi.Chen@...

3

timothy.t.orling@...

3

trevor.gamblin@...

3

mostthingsweb@...

3

matthewzmd@...

2

limon.anibal@...

2

randy.macleod@...

2

ydirson@...

2

jeanmarie.lemetayer@...

2

sakib.sajal@...

2

nicolas.dechesne@...

2

alejandro@...

2

jaewon@...

2

yoctoproject@...

1

mhalstead@...

1

bruce.ashfield@...

1

twoerner@...

1

mister_rs@...

1

pokylinux@...

1

open.source@...

1

devendra.tewari@...

1

dorindabassey@...

1

mark.hatle@...

1

stacygaikovaia@...

1

hongxu.jia@...

1

yifan.yu@...

1

matt.ranostay@...

1

john.kaldas.enpj@...

1

aehs29@...

1

kergoth@...

1

mshah@...

1

Grand Total

118

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 362 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.2”, “3.3, "3.99" and "Future", the more pressing/urgent issues being in "3.2" and then “3.3”.

 

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

 


[ANNOUNCEMENT]Milestone 3 for Yocto Project 3.3 (yocto-3.3_M3) now available

Vineela
 

Hello,

We are pleased to announce the third milestone release for Yocto Project 3.3 (yocto-3.3_M3) is now available for download.

Download:

http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-3.3_M3

bitbake: ed8e1fd4cf9d5ac8a8203638add99d686b4b3521
meta-arm: ac1dc0b894642101a80235a920bdc3bbe6d74558
meta-gplv2: 9e119f333cc8f53bd3cf64326f826dbc6ce3db0f
meta-intel: 6fea44c695730129df8bd744b0e22ccd62a725c2
meta-kernel: 29329d7cacc71595cecfdd05a455a0cfb164564d
meta-mingw: 422b96cb2b6116442be1f40dfb5bd77447d1219e
oecore: 7ae12e4278e98c5b916a1067ae0b48c2da6e82cd
poky: ea455ca8671d3bc2a1097989bfaabe92f3ca37ab

Full Test Report:

http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-3.3_M3/testreport.txt

Thank you.

Vineela Tummalapalli,
Yocto Project Build and Release
vineela.tummalapalli@intel.com


Re: Naming images

Quentin Schulz
 

Hi Damien,

On Mon, Mar 29, 2021 at 03:33:09PM +0300, Damien LEFEVRE wrote:
Hi,

In my build system the generated images are in this format:

imagename-machine-timestamp.img

For release builds, I'd like to replace the time stamp with the image
version. I could rename the image after the build but is there a better way?
IMAGE_NAME variable is the one specifying the name which should be used
for the final image. c.f. https://docs.yoctoproject.org/ref-manual/variables.html#term-IMAGE_NAME

By default, its value is "${IMAGE_BASENAME}-${MACHINE}${IMAGE_VERSION_SUFFIX}"

IMAGE_VERSION_SUFFIX is by default set to "-${DATETIME}" as documented
here: https://docs.yoctoproject.org/ref-manual/variables.html#term-IMAGE_VERSION_SUFFIX

Therefore to put the image version, you just need to change
IMAGE_VERSION_SUFFIX to what you want it to contain.

Cheers,
Quentin


Re: Package indexes for package feeds, ipk and rpm

Ross Burton
 

That's just how RPM and opkg work, Yocto can't control or alter that.

Ross

On Mon, 29 Mar 2021 at 10:36, keydi <krzysztof.dudziak@thalesgroup.com> wrote:

Regarding package feed packages index I learned one difference between rpm and ipk.
For ipk plain-text files named Packages are generated and placed to architecture-subdirectories in tmp/deploy/ipk tree.
For rpm I see just one file named Packages, it is a binary file yet located in one image arch-subdir within tmp/deploy/rpm tree.

Is this difference the result how Poky/OE handles both
or rather coming already from package management systems?

I wonder also how could the chances be to have Packages files in RPM in same form
as for IPK - plain-text yet provided for each architecture build artifacts sub-tree?



Naming images

Damien LEFEVRE
 

Hi,

In my build system the generated images are in this format:

imagename-machine-timestamp.img

For release builds, I'd like to replace the time stamp with the image version. I could rename the image after the build but is there a better way?

I found a BUILDNAME variable but it has no effect.

Also should the timestamp written in /etc/version match the one from the image name?

For some reason for me it doesn't. /etc/version is 20180309123456 while the one from the image name is 20210329064542.

-Damien


[meta-zephyr][PATCH 1/1] zephyr-kernel-src.inc: Support samples from external layers

Andrei Gherzan
 

From: Andrei Gherzan <andrei.gherzan@huawei.com>

The inc file references patch(es) local to the inc file. Including this
file from another recipe as part of an external layer, will make bitbake
fail finding the files referenced in zephyr-kernel-src.inc's SRC_URI.

By including an explicit path to the files directory in FILESEXTRAPATHS,
we make sure that any recipe including this inc file will inherit the
needed path.

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>
---
recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc | 5 +++++
1 file changed, 5 insertions(+)

diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
index 39cbc10..8c987bb 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
@@ -7,6 +7,11 @@ include zephyr-kernel-src-${PREFERRED_VERSION_zephyr-kernel}.inc

inherit cmake

+# This file might be included from other places (like other layers) and not
+# having an explicit path to the patches directory, will make bitbake fail to
+# find the patch(es) in SRC_URI.
+FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+
SRC_URI = "\
git://github.com/zephyrproject-rtos/zephyr.git;protocol=https;branch=master;name=default \
git://github.com/zephyrproject-rtos/cmsis.git;protocol=https;destsuffix=git/modules/cmsis;name=cmsis \
--
2.31.1


Package indexes for package feeds, ipk and rpm

keydi
 

Regarding package feed packages index I learned one difference between rpm and ipk.
For ipk plain-text files named Packages are generated and placed to architecture-subdirectories in tmp/deploy/ipk tree.
For rpm I see just one file named Packages, it is a binary file yet located in one image arch-subdir within tmp/deploy/rpm tree.

Is this difference the result how Poky/OE handles both
or rather coming already from package management systems?

I wonder also how could the chances be to have Packages files in RPM in same form
as for IPK - plain-text yet provided for each architecture build artifacts sub-tree?


Re: To burn 'bitbake package-index' into build process

keydi
 

Thanks for hint.
Which qualities might current implementation output still miss?

I tried to ask in meantime three Yocto books for help
but no clear help got. My search went toward distribution-level meta-data,
this can be however wrong direction as package index is not built for
target system distribution/image.

I get the impression as of time being the only solution
will be to start one small script additionally to main script
to respawn Bitbake environment once again to do bitbake package-index.

Regards
k.d.

-----Original Message-----
From: Ross Burton [mailto:ross@burtonini.com]
Sent: Samstag, 27. März 2021 22:20
To: DUDZIAK Krzysztof <krzysztof.dudziak@thalesgroup.com>
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] To burn 'bitbake package-index' into build process

http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=ross/index
is close to what you want, but I didn't quite finish it off!

Ross

On Fri, 26 Mar 2021 at 16:45, keydi <krzysztof.dudziak@thalesgroup.com>
wrote:

Should it be feasible to burn execution of 'bitbake package-index'
into distribution/image build process by conducting an adaption of meta-
data ?
I mean high-level script is used to spawn Bitbake environment then start
Bitbake image target.
I am unhappy to mess up high-level script to add that step to build process.
I am unhappy to make detail that level be visible in high-level script.
Rather I prefer to modify meta-data.


1321 - 1340 of 54253