Current Dev Position: YP 4.2 M2
Next Deadline: 23th January 2023 YP 4.2 M2 Build
Next Team Meetings:
- Bug Triage meeting Thursday December 15th 7:30 am PDT (https://zoom.us/j/454367603?pwd=ZGxoa2ZXL3FkM3Y0bFd5aVpHVVZ6dz09)
- Weekly Project Engineering Sync Tuesday December 13th at 8 am PDT (https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09)
- Twitch - See https://www.twitch.tv/theyoctojester
Key Status/Updates:
- YP 4.2 M1 is in QA
- YP 4.0.6 is due to build today
- There have been a number of more invasive bitbake changes either merged or are queued. This included a move to adopt the new layer.conf “addpylib” directive for layers with python library directories. Also included was a new optional bitbake cache mode which includes hash construction information, we’re likely to switch to use this for the dump-signatures functionality. We haven’t merged optimisations for that cache yet.
- We have increased the minimum python version requirement to 3.8.
- Functionality versus parsing speed continues to be a discussion for some of the bitbake patches.
- CVEs in master are lower but some have been open for a number of weeks now.
- We have a growing number of bugs in bugzilla, any help with them is appreciated.
- As people are likely aware, the project has a number of components which are either unmaintained, or have people with little to no time trying to keep them alive. These components include: patchtest, layerindex, devtool, toaster, wic, oeqa, autobuilder, CROPs containers, pseudo and more. Many have open bugs. Help is welcome in trying to better look after these components!
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 4.2. See: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_4.2_Unassigned_Enhancements.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/maintainers.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 is very much welcome in trying to resolve our autobuilder intermittent issues. 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.
- Help us resolve CVE issues: CVE metrics
YP 4.2 Milestone Dates:
- YP 4.2 M1 is in QA
- YP 4.2 M1 Release date 2022/12/16
- YP 4.2 M2 build date 2023/01/23
- YP 4.2 M2 Release date 2023/02/03
- YP 4.2 M3 build date 2023/02/20
- YP 4.2 M3 Release date 2023/03/03
- YP 4.2 M4 build date 2023/04/03
- YP 4.2 M4 Release date 2023/04/28
Upcoming dot releases:
- YP 4.0.6 build date 2022/12/12
- YP 4.0.6 Release date 2022/12/23
- YP 4.1.2 build date 2023/01/09
- YP 4.1.2 Release date 2023/01/20
- YP 3.1.22 build date 2023/01/16
- YP 3.1.22 Release date 2023/01/27
- YP 4.0.7 build date 2023/01/30
- YP 4.0.7 Release date 2023/02/10
- YP 3.1.23 build date 2023/02/13
- YP 3.1.23 Release date 2023/02/24
- YP 4.0.8 build date 2023/02/27
- YP 4.0.8 Release date 2023/03/10
- YP 4.1.3 build date 2023/03/06
- YP 4.1.3 Release date 2023/03/17
- YP 3.1.24 build date 2023/03/20
- YP 3.1.24 Release date 2023/03/31
- YP 4.0.9 build date 2023/04/10
- YP 4.0.9 Release date 2023/04/21
- YP 4.1.4 build date 2023/05/01
- YP 4.1.4 Release date 2023/05/13
- YP 3.1.25 build date 2023/05/08
- YP 3.1.25 Release date 2023/05/19
- YP 4.0.10 build date 2023/05/15
- YP 4.0.10 Release date 2023/05/26
Tracking Metrics:
- WDD 2437 (last week 2444) (https://wiki.yoctoproject.org/charts/combo.html)
- OE-Core/Poky Patch Metrics
- Total patches found: 1162 (last week 1164)
- Patches in the Pending State: 285 (25%) [last week 285 (24%)]
- https://autobuilder.yocto.io/pub/non-release/patchmetrics/
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@...
https://autobuilder.yoctoproject.org/typhoon/#/builders/141/builds/1
The execution time is similar to the 64 bit x86 full ptest, as valgrind has been excluded
from the 32 bit set, so I believe we can afford to run this in the standard
matrix for master-next tests.
Signed-off-by: Alexander Kanavin <alex.kanavin@...>
---
config.py | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/config.py b/config.py
index e638099..711dd98 100644
--- a/config.py
+++ b/config.py
@@ -88,7 +88,7 @@ trigger_builders_wait_quick = trigger_builders_wait_shared + [
trigger_builders_wait_full = trigger_builders_wait_shared + [
"qemumips-alt", "edgerouter-alt", "qemuppc-alt", "qemux86-world-alt",
"oe-selftest-ubuntu", "oe-selftest-debian", "oe-selftest-fedora", "oe-selftest-centos",
- "qemux86-64-ptest", "qemux86-64-ltp", "qemuarm64-ptest", "qemuarm64-ltp",
+ "qemux86-64-ptest", "qemux86-64-ltp", "qemuarm64-ptest", "qemuarm64-ltp", "qemux86-ptest",
"meta-intel", "meta-arm", "meta-aws", "meta-agl-core", "meta-virt"
]
@@ -117,7 +117,6 @@ builders_others = [
"oe-selftest-arm",
"metrics",
"qemuriscv32", "qemuriscv64", "qemuriscv64-ptest", "qemuppc64",
- "qemux86-ptest",
"auh"
]
--
2.38.1
---
config.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/config.py b/config.py
index 3c67351..e638099 100644
--- a/config.py
+++ b/config.py
@@ -82,7 +82,7 @@ trigger_builders_wait_shared = [
]
trigger_builders_wait_quick = trigger_builders_wait_shared + [
- "oe-selftest", "qemux86-64-ptest-fast", "qemuarm64-ptest-fast"
+ "oe-selftest", "qemux86-64-ptest-fast", "qemuarm64-ptest-fast", "qemux86-ptest-fast"
]
trigger_builders_wait_full = trigger_builders_wait_shared + [
@@ -117,7 +117,7 @@ builders_others = [
"oe-selftest-arm",
"metrics",
"qemuriscv32", "qemuriscv64", "qemuriscv64-ptest", "qemuppc64",
- "qemux86-ptest", "qemux86-ptest-fast",
+ "qemux86-ptest",
"auh"
]
--
2.38.1
All,
YP M+ or high bugs which moved to a new milestone in WW50 are listed below:
Priority | Bug ID | Short Description | Changer | Owner | Was | Became |
Medium+ | Bitbake server intermittent timeout | randy.macleod@... | unassigned@... | 4.2 M1 | 4.2 M2 | |
| AB-INT PTEST: lttng-tools ptest intermittent failure | randy.macleod@... | unassigned@... | 4.2 M1 | 4.2 M2 | |
| valgrind drd/tests ptest intermittent failure | randy.macleod@... | Zheng.Qiu@... | 4.2 M1 | 4.2 M2 | |
| systemd.SystemdServiceTests.test_systemd_disable_enable intermittent failure: no filesystem space on target | randy.macleod@... | randy.macleod@... | 4.2 M1 | 4.2 M2 | |
| AB-INT: SDK preparation failure: SState: cannot test file://[...] TimeoutError('timed out') | randy.macleod@... | unassigned@... | 4.2 M1 | 4.2 M2 | |
| AB-INT: prservice.BitbakePrTests.test_pr_service_deb_arch_dep failure | randy.macleod@... | unassigned@... | 4.2 M1 | 4.2 M2 | |
| ltp controllers test failure | randy.macleod@... | unassigned@... | 4.2 M1 | 4.2 M2 | |
| AB-INT PTEST: lttng-tools ptest intermittent failure in tools/clear/test_kernel_316 | randy.macleod@... | unassigned@... | 4.2 M1 | 4.2 M2 | |
| AB-INT: Unable to connect to bitbake server, or start one | randy.macleod@... | unassigned@... | 4.2 M1 | 4.2 M2 |
Thanks,
Stephen K. Jolley
Yocto Project Program Manager
( Cell: (208) 244-4460
* Email: sjolley.yp.pm@...
All,
The below were the owners of enhancements or bugs closed during the last week!
Who | Count |
randy.macleod@... | 4 |
michael.opdenacker@... | 1 |
debrabander@... | 1 |
steve@... | 1 |
Grand Total | 7 |
Thanks,
Stephen K. Jolley
Yocto Project Program Manager
( Cell: (208) 244-4460
* Email: sjolley.yp.pm@...
All,
Below is the list as of top 31 bug owners as of the end of WW50 of who have open medium or higher bugs and enhancements against YP 4.2. There are 94 possible work days left until the final release candidates for YP 4.2 needs to be released.
Who | Count |
michael.opdenacker@... | 35 |
ross.burton@... | 29 |
randy.macleod@... | 25 |
bruce.ashfield@... | 24 |
david.reyna@... | 23 |
richard.purdie@... | 22 |
sakib.sajal@... | 10 |
JPEWhacker@... | 10 |
saul.wold@... | 9 |
pavel@... | 6 |
Zheng.Qiu@... | 5 |
tim.orling@... | 4 |
sundeep.kokkonda@... | 3 |
alexandre.belloni@... | 3 |
sgw@... | 2 |
akuster808@... | 2 |
jon.mason@... | 2 |
sundeep.kokkonda@... | 2 |
Naveen.Gowda@... | 2 |
hongxu.jia@... | 2 |
rybczynska@... | 1 |
bluelightning@... | 1 |
Anton.Antonov@... | 1 |
Qi.Chen@... | 1 |
ptsneves@... | 1 |
martin.beeger@... | 1 |
Martin.Jansa@... | 1 |
mhalstead@... | 1 |
aehs29@... | 1 |
tvgamblin@... | 1 |
thomas.perrot@... | 1 |
Grand Total | 231 |
Thanks,
Stephen K. Jolley
Yocto Project Program Manager
( Cell: (208) 244-4460
* Email: sjolley.yp.pm@...
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 416 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, “4.2”, “4.3”, "4.99" and "Future", the more pressing/urgent issues being in "4.2" and then “4.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@...
<ali.ahmad=rtl-corp.com@...> wrote:
'devtool modify' should help with that. It will clone the source code
Thank you for getting back.
Context/Use case:
My current recipe always checks out code from the git repo before building it.
During development, I want to first build my code successfully before pushing it to the repo. Hence I want the recipe to check if the code exists at a certain location on the file system. If it does, it should build that. If it doesn't it should checkout the code from the repo before building it.
into a 'workspace' folder, and set up a .bbappend in the same
workspace that would instruct bitbake to build from that location
instead of fetching from git. When you're done, there are several
other 'devtool' subcommands to finish up, and revert to building from
git.
Alex
Context/Use case:
My current recipe always checks out code from the git repo before building it.
During development, I want to first build my code successfully before pushing it to the repo. Hence I want the recipe to check if the code exists at a certain location on the file system. If it does, it should build that. If it doesn't it should checkout the code from the repo before building it.
Thanks
I have a recipe for an application. I want it to download its code from the Git repo only if it does not already exist at a specific location on the file system.
How can I go about achieving this?
Thanks
How can I go about achieving this?
Thanks
Thanks for your reply. I did build a recipe for a tar.gz source archive previously, which worked. But for the RPM I felt like I was missing something. Meanwhile, my multilib build for core-image-base is failing with the error below. This is without any custom recipes. I am not sure what to about this missing manifest file. I thought perhaps it was SDK related so I tried running bitbake core-image-base -c populate_sdk... but got a similar error. If I knew the root cause of this error, I might be able to fix it. But it seems that unless I've setup local.conf incorrectly, doing multilib should just work out of the box. Note that I successfully built core-image-base WITHOUT multilib configured in my local.conf. Simply adding the multilib config entries causes this error (local.conf attached).
I feel if I can get this error resolved, it would be tremendous progress.
Thanks again!
David
And this is the commit that did this:Hi Alexander,
https://git.phytec.de/meta-phytec/commit/conf/layer.conf?id=8261e896d2b43211e7377feb38e919336d47c39f
Shame on you, phytec. Shame on you. What you do in your layers perhaps
doesn't matter so much, but you also give everyone a bad example to
follow.
instead of putting shame on people, I would propose, for a prospering
community, to send out hints to maintainers, when an enforced mechanism
is being disabled. I would have just ignored your email if Richard did
not cleared things up with his patch. Thanks.
Regards, Stefan
Alex
On Thu, 1 Dec 2022 at 08:47, Martin Jansa <Martin.Jansa@...> wrote:
Agreed with Rudolf.
If the layer maintainer didn't bother to do at least do one build with new release and adjust
LAYERSERIES_COMPAT, then I don't consider that layer well maintained (it could be someone else who uses
the layer, tests it with new release and sends PR to adjust LAYERSERIES_COMPAT).
Recently I've also seen this:
LAYERSERIES_COMPAT_phytec = "${LAYERSERIES_COMPAT_core}"
which is also bad as it completely disables the check (seen in
https://git.phytec.de/meta-phytec/tree/conf/layer.conf#n14).
On Thu, Dec 1, 2022 at 7:06 AM Rudolf J Streif <rudolf.streif@...> wrote:
On Wed, Nov 30, 2022, 20:27 Zoran <zoran.stojsavljevic@...> wrote:
Hello to Yocto community,
As I am much more passive yocto wise these few years ( working on
Android build systems and around, this is also a nightmare, I should
say ;-) ), I have one Yocto question which I never really understood.
I will ask it by example. I have one layer for the CAN tools and apps
which I have created 4 years ago:
https://github.com/ZoranStojsavljevic/meta-socketcan
In there, in conf/layer.conf:
https://github.com/ZoranStojsavljevic/meta-socketcan/blob/master/conf/layer.conf
I have the following line (layers' compatibility):
LAYERSERIES_COMPAT_meta-socketcan = "sumo thud warrior zeus dunfell
gatesgarth hardknott honister kirkstone"
I do not understand why we need to explicitly name releases for such
simple generic layers?!
To me this indicates that the maintainer of the layer has tested the compatibility of his layer with all
of these releases of the Yocto Project.
A maintainer of a layer should make a deliberate decision of adding a release or dropping one from the
compatibility list. It should be an attestation that the layer's compatibility with the releases in the
list is actually maintained and tested.
There have been changes to the syntax to conditional variables. Your layer might well be compatible with
all of the releases and it's great if you tested it. But it's not a given.
Instead, for a virtual example:
LAYERSERIES_COMPAT_meta-socketcan = "${AUTOLAYER x}"
So all the layers might be included (or for at least lets say x = 4
latest releases, where x = 0 would be include all)? I do understand
that complex layers could NOT have such a definition (because of the
dependencies), but for the generic layers (as such presented), this
would be beneficial.
I never cared for ${AUTOREV}, which is similar, in the first place for the very reason that it creates
inconsistent behavior. This would do the same thing. What would the last 4 releases even mean? What is
the reference and where is it obtained from?
Thank you for the answers,
Zee
_______
Best,
:rjs
Intel and WR YP QA is planning for QA execution for YP build yocto-4.2_M1.rc1. We are planning to execute following tests for this cycle:
OEQA-manual tests for following module:
1. OE-Core
2. BSP-hw
Runtime auto test for following platforms:
1. MinnowTurbot 32-bit
2. NUC 7
3. ADL
4. TGL NUC 11
5. Edgerouter
6. Beaglebone
ETA for completion next Thursday, December 15.
Best regards,
Jing Hui
-----Original Message-----
From: yocto@... <yocto@...> On Behalf
Of Pokybuild User
Sent: Friday, 9 December, 2022 3:39 AM
To: yocto@...
Cc: qa-build-notification@...
Subject: [yocto] QA notification for completed autobuilder build (yocto-
4.2_M1.rc1)
A build flagged for QA (yocto-4.2_M1.rc1) was completed on the autobuilder
and is available at:
https://autobuilder.yocto.io/pub/releases/yocto-4.2_M1.rc1
Build hash information:
bitbake: 6709aedccbb2e7ddbb1b2e7e4893481a7b536436
meta-agl: e2c31ebda224bf6813ff861df9a51e8fc46944e5
meta-arm: 02b430d045b50d5e5cab9a52b786d1134ba17c19
meta-aws: da36bf8bc3f5a1cbb9396e8d28559c422cd96412
meta-intel: de59d48ad2ce88ebe331a8355e742fce7c3b428c
meta-mingw: 4a066511a944ec946efa7a4571029c992cf0ae00
meta-openembedded: 8c58f419c299fe3764482ebe4f366e25533ea23f
meta-virtualization: cb5dfda6f6d862a575f029ee8ded0bc3db6bc766
oecore: 96ff9baa8ead57504f40f362ed3a4aaa776d1b58
poky: 4d19594b8bdacde6d809d3f2a25cff7c5a42295e
This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@...
<ivan.shevtsov@...> wrote:
I want to speed up my production build, by preventing from removing -native, nativesdk- and -cross- packages.Do not remove sstate-cache. It's there specifically to make builds
For now, I clean all by removing tmp, sstate-cache, and some other folders (rm -rf /tmp /sstate-cache...).
Maybe, it is possible to split TMPDIR, SSTATE_DIR, to place native packages in other folders, than nonnative packages.
Or place all prebuild -native, nativesdk- and -cross- packages to SSTATE_MIRRORS.
Any proposition on how can I make this best?
faster by reusing existing build outputs, and is designed to be
reusable between any build configuration.
Removing tmp is fine.
Alex
Hello,
I need to deploy a third-party package as part of my Yocto image. I am not sure how to build a recipe that will automate the installation of this RPM and dependencies. If any of these dependent packages are not already included in the core-image-base image, I'll have to put together recipes for those as well and add them to the main recipe for the package (the RPM I want to install). I have a basic idea of what needs to be done but am fuzzy on the detail. I'll need to create a recipe that points to my RPM file via SRC_URI, but I am not sure what commands need to be included to make sure the RPM is seen as a package I can add via my local.conf. The goal is to have the package installed in the final image such that the software is running as if the RPM was installed manually at the command prompt on the target board. I've done a lot of googling, but the few posts I could find contain bits of information that aren't that useful to a Yocto newbie. Note that I am using latest version of Kirkstone.
Thanks!
David
Is it specifically make processes that are hanging?Alex
On Wed, Dec 7, 2022 at 8:37 AM Bruce Ashfield <bruce.ashfield@...> wrote:
> I don't have anything super helpful to add, but when that git command
> is hung, are you seeing any stalled network connections or processes
> in D state ?
The hung commands are in the S state (sleeping).
> It wasn't clear from your first message. Are all native processes hanging
> at do_install ? or is it a subset ?
The build gets hung on bitbake hosttools-tarball and it seems to be
all of the native targets
Currently 4 running tasks (1519 of 2078) 73%
0: nativesdk-kmod-27-r0 do_install - 5s (pid 3450165)
1: nativesdk-xilinx-qemu-git-r0 do_install - 5s (pid 3450167)
2: nativesdk-zephyr-qemu-git-r0 do_install - 5s (pid 3450169)
3: nativesdk-arc-qemu-git-r0 do_install - 5s (pid 3450172)
If I pass in -vvv -DDD to bitbake I get this output
+ make -j 32 DESTDIR=/home/cfriedt/build-zephyr-sdk/sdk-ng/poky/build-zephyr-tools/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-kmod/27-r0/image
install
...
+ make -j 32 DESTDIR=/home/cfriedt/build-zephyr-sdk/sdk-ng/poky/build-zephyr-tools/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-xilinx-qemu/git-r0/image
install
...
+ make -j 32 DESTDIR=/home/cfriedt/build-zephyr-sdk/sdk-ng/poky/build-zephyr-tools/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-zephyr-qemu/git-r0/image
install
...
+ make -j 32 DESTDIR=/home/cfriedt/build-zephyr-sdk/sdk-ng/poky/build-zephyr-tools/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-arc-qemu/git-r0/image
install
The exact commands that are hanging are
kmod: /bin/bash -c git describe 2>/dev/null
nativesdk-xilinx-qemu: /bin/bash -c git describe 2>/dev/null
In the kmod case, if I go to the build directory and do what the
Makefile does, it's obvious that git will fail since there is no .git
subdirectory.
$ git describe
fatal: No names found, cannot describe anything.
If I swap out the Makefile for something utterly trivial like this, it
still hangs
.PHONY: all install bar
foo-%:
touch $@
bar: foo-$(shell git describe 2>/dev/null)
all: bar
install: bar