I don't have anything super helpful to add, but when that git command
In all cases, the problem is traced back to a Makefile, where
something calls $(shell git ... ) to get a git version.
I was able to find out because one shell had executed a script called
scripts/setlocalversion that looked kind of suspicious in terms of
error propagation. In this script, if I manually echoed "1.6.0" and
then exited, do_install would not hang.
Some early discussion suggests that it might be avoidable with 'set -o
pipefail' in the shell, but I haven't investigated further.
is hung, are you seeing any stalled network connections or processes
in D state ?
It wasn't clear from your first message. Are all native processes hanging
at do_install ? or is it a subset ?
Bruce
C
--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
Thanks Khem, can you please help explain or give an example of a package that is doing this? If we had separate output packages, are you suggesting we build 3 times- each time after applying a patch related to dhcrelay and dhclient?
We are somewhat doing this today where binaries dhcrelay and dhclient need to be built with different build options and with different patch files.
git apply $WORKSPACE/git-build/dhcrelay.patch
devtool modify dhcp
devtool build dhcp
cp $WORKSPACE/work/poky/build/workspace/sources/dhcp/relay/dhcrelay $OUR_WORKPSACE/dhcp/dhcrelay
devtool reset dhcp
git apply $WORKSPACE/git-build/dhclient.patch
devtool modify dhcp
devtool build dhcp
cp $WORKSPACE/work/poky/build/workspace/sources/dhcp/relay/dhclient $OUR_WORKPSACE/dhcp/dhclient
-- Vaijayanthi
something calls $(shell git ... ) to get a git version.
I was able to find out because one shell had executed a script called
scripts/setlocalversion that looked kind of suspicious in terms of
error propagation. In this script, if I manually echoed "1.6.0" and
then exited, do_install would not hang.
Some early discussion suggests that it might be avoidable with 'set -o
pipefail' in the shell, but I haven't investigated further.
C
BB_VERSION = "1.48.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "universal"
TARGET_SYS = "i686-zephyr-linux"
MACHINE = "qemux86"
DISTRO = "zephyr-sdk"
DISTRO_VERSION = "0.9"
TUNE_FEATURES = "m32 core2"
TARGET_FPU = ""
meta
meta-poky
meta-yocto-bsp = "HEAD:8daedc01101e686fc640c164004c0ec4e5f90b4e"
meta-zephyr-sdk = "HEAD:43582cc208d97cf32c49973ff4ff5d994ae41264"
I've done some digging with this myself, but have not found a root
cause, fix, or workaround. Google shows me that a number of other
users have encountered this problem as well with Yocto, but I have not
found a solution with those either.
Native targets are stuck in the do_install phase and can literally
hang for days.
Currently 2 running tasks (2004 of 2078) 96%
...
0: nativesdk-dtc-1.6.0-r0 do_install - 1h17m52s (pid 2572369)
1: nativesdk-kmod-27-r0 do_install - 1h16m2s (pid 2656202)
Does anyone have any debugging suggestions?
$ strace -p 2572369
strace: Process 2572369 attached
pselect6(15, [12 14], [], [], {tv_sec=0, tv_nsec=526887424}, NULL) = 0 (Timeout)
wait4(2572898, 0x7ffd153a439c, WNOHANG, NULL) = 0
pselect6(15, [12 14], [], [], {tv_sec=0, tv_nsec=526887424}, NULL) = 0 (Timeout)
wait4(2572898, 0x7ffd153a439c, WNOHANG, NULL) = 0
pselect6(15, [12 14], [], [], {tv_sec=0, tv_nsec=526887424}, NULL) = 0 (Timeout)
wait4(2572898, 0x7ffd153a439c, WNOHANG, NULL) = 0
...
$ ps -fw 2572368
... /bin/sh ... temp/run.do_install.2572369
I can send a signal to the parent process (e.g. kill -USR1 2572368)
but then the process fails. I can do a clean on the targets, but the
exact same problem repeats itself.
Manually stepping through build phases also does not work, as
do_install simply hangs again when I get there.
It seems to be a pretty serious problem and not an isolated issue.
Complete showstopper, as the Yocto build cannot proceed beyond this
point without manual hacks.
I've encountered this while building the Zephyr SDK [1] on a company
machine (where it actually matters) but am unable to reproduce the
issue inside of a
centos-stream-9 docker container [2] (where it doesn't matter).
I've tried rebooting, completely wiping all of the build directories,
standing on one foot, trying to forget about it, sleeping on it, etc.
Nothing seems to fix the issue.
So yea, the fun continues!
Any ideas?
[1] https://github.com/zephyrproject-rtos/sdk-ng
[2] https://github.com/cfriedt/zephyr-sdk-builder/tree/using-centos-stream-9
needs to use buildtools tarball to remain compatible
Signed-off-by: Joshua Watt <JPEWhacker@...>
---
config.json | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/config.json b/config.json
index 713afe5..1149c98 100644
--- a/config.json
+++ b/config.json
@@ -11,6 +11,7 @@
"BUILDTOOLS_URL_TEMPLOCAL" : "/srv/autobuilder/autobuilder.yocto.io/pub/non-release/20210214-8/buildtools/x86_64-buildtools-extended-nativesdk-standalone-3.2+snapshot-7d38cc8e749aedb8435ee71847e04b353cca541d.sh",
"BUILDTOOLS_URL_TEMPLOCAL2" : "https://downloads.yoctoproject.org/releases/yocto/milestones/yocto-3.1_M3/buildtools/x86_64-buildtools-extended-nativesdk-standalone-3.0+snapshot-20200315.sh",
"BUILDTOOLS_URL" : "https://downloads.yoctoproject.org/releases/yocto/yocto-3.4/buildtools/x86_64-buildtools-extended-nativesdk-standalone-3.4.sh",
+ "BUILDTOOLS_ARM_URL" : "https://downloads.yoctoproject.org/releases/yocto/yocto-3.4/buildtools/aarch64-buildtools-extended-nativesdk-standalone-3.4.sh",
"BUILDTOOLS_MAKE_URL" : "/srv/autobuilder/autobuilder.yocto.io/pub/non-release/20220413-28/buildtools/x86_64-buildtools-make-nativesdk-standalone-4.0.sh",
"REPO_STASH_DIR" : "${BASE_HOMEDIR}/git/mirror",
@@ -1287,6 +1288,8 @@
"debian9*" : "${BUILDTOOLS_URL}",
"centos7*" : "${BUILDTOOLS_URL}",
"ubuntu1604*" : "${BUILDTOOLS_URL}",
+ "ubuntu1804-ty-*" : "${BUILDTOOLS_URL}",
+ "ubuntu1804-arm-*" : "${BUILDTOOLS_ARM_URL}",
"alma8*" : "${BUILDTOOLS_MAKE_URL}",
"centos8*" : "${BUILDTOOLS_MAKE_URL}",
"stream8*" : "${BUILDTOOLS_MAKE_URL}",
@@ -1294,6 +1297,8 @@
"opensuse154*" : "${BUILDTOOLS_MAKE_URL}",
"perf-alma8*" : "${BUILDTOOLS_MAKE_URL}",
"perf-centos7*" : "${BUILDTOOLS_URL}",
- "perf-ubuntu1604*" : "${BUILDTOOLS_URL}"
+ "perf-ubuntu1604*" : "${BUILDTOOLS_URL}",
+ "perf-ubuntu1804-ty-*" : "${BUILDTOOLS_URL}",
+ "perf-ubuntu1804-arm-*" : "${BUILDTOOLS_ARM_URL}"
}
}
--
2.33.0
see how xorg.conf is defined for different qemu based machines in
Hello Khem Raj,
Thank you for the response.
Second, way would be to have test.service copies installed under
files/<customer-override>/ directory next to recipe
and then define customer distro specific overrides
This seems to be a better solution for my use case. But, I didn't understand it completely. Could you please provide an example or any link to documentation? Is it also needed to create a custom distribution? This layer will be used by different customers in bblayers.conf
xserver-xf86-config recipe [1]
[1] https://git.yoctoproject.org/poky/tree/meta/recipes-graphics/xorg-xserver/xserver-xf86-config
Current Dev Position: YP 4.2 M1
Next Deadline: 5th December 2022 YP 4.2 Build
Next Team Meetings:
- Bug Triage meeting Thursday December 8th 7:30 am PDT (https://zoom.us/j/454367603?pwd=ZGxoa2ZXL3FkM3Y0bFd5aVpHVVZ6dz09)
- Weekly Project Engineering Sync Tuesday December 6th 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 due to be built this week, likely once we merge a few remaining patches and hopefully some CVE fixes.
- Thanks to everyone who attended or helped contribute to the Yocto Summit, it seemed to be a success and had some good presentations!
- There are a number of bitbake patches pending with an unresolved dilemma on functionality versus parsing speeds.
- CVEs in master have risen with 7 across 5 components, help in bringing the numbers down would be appreciated
- We are starting to see some rough plans around Y2038, largefile support and some other topics, thanks to all those helping move this forward, there has been some useful discussion and we look forward to seeing the changes!
- 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 build date 2022/12/05
- 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 2444 (last week 2446) (https://wiki.yoctoproject.org/charts/combo.html)
- OE-Core/Poky Patch Metrics
- Total patches found: 1164 (last week 1175)
- Patches in the Pending State: 285 (24%) [last week 288 (25%)]
- 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@...
needs to use buildtools tarball to remain compatible
Signed-off-by: Joshua Watt <JPEWhacker@...>
---
config.json | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/config.json b/config.json
index 713afe5..3d89856 100644
--- a/config.json
+++ b/config.json
@@ -1287,6 +1287,7 @@
"debian9*" : "${BUILDTOOLS_URL}",
"centos7*" : "${BUILDTOOLS_URL}",
"ubuntu1604*" : "${BUILDTOOLS_URL}",
+ "ubuntu1804*" : "${BUILDTOOLS_URL}",
"alma8*" : "${BUILDTOOLS_MAKE_URL}",
"centos8*" : "${BUILDTOOLS_MAKE_URL}",
"stream8*" : "${BUILDTOOLS_MAKE_URL}",
@@ -1294,6 +1295,7 @@
"opensuse154*" : "${BUILDTOOLS_MAKE_URL}",
"perf-alma8*" : "${BUILDTOOLS_MAKE_URL}",
"perf-centos7*" : "${BUILDTOOLS_URL}",
- "perf-ubuntu1604*" : "${BUILDTOOLS_URL}"
+ "perf-ubuntu1604*" : "${BUILDTOOLS_URL}",
+ "perf-ubuntu1804*" : "${BUILDTOOLS_URL}"
}
}
--
2.33.0
All,
The below were the owners of enhancements or bugs closed during the last week!
Who | Count |
richard.purdie@... | 2 |
yashinde145@... | 1 |
Grand Total | 3 |
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 WW49 of who have open medium or higher bugs and enhancements against YP 4.2. There are 99 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@... | 26 |
bruce.ashfield@... | 24 |
david.reyna@... | 23 |
richard.purdie@... | 21 |
sakib.sajal@... | 11 |
JPEWhacker@... | 10 |
saul.wold@... | 9 |
pavel@... | 4 |
Zheng.Qiu@... | 4 |
tim.orling@... | 4 |
sundeep.kokkonda@... | 3 |
alexandre.belloni@... | 3 |
aehs29@... | 2 |
Naveen.Gowda@... | 2 |
jon.mason@... | 2 |
akuster808@... | 2 |
hongxu.jia@... | 2 |
sgw@... | 2 |
hummerbliss@... | 1 |
Qi.Chen@... | 1 |
Anton.Antonov@... | 1 |
martin.beeger@... | 1 |
rybczynska@... | 1 |
ptsneves@... | 1 |
sundeep.kokkonda@... | 1 |
tvgamblin@... | 1 |
thomas.perrot@... | 1 |
Martin.Jansa@... | 1 |
mhalstead@... | 1 |
Grand Total | 229 |
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 418 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@...
Thank you for the response.
Second, way would be to have test.service copies installed underThis seems to be a better solution for my use case. But, I didn't understand it completely. Could you please provide an example or any link to documentation? Is it also needed to create a custom distribution? This layer will be used by different customers in bblayers.conf
files/<customer-override>/ directory next to recipe
and then define customer distro specific overrides
Your email prompted me to check my own software (Dropbear) and it showed aThat is really interesting data as it confirmed there are real world
few y2038 issues to fix. Those bugs wouldn't be noticed from a quick test -
it "only" prevented auth and idle timeouts from occurring.
gcc and clang are able to flag truncated conversions for 64-bit time_t with
-Wconversion, but that's very noisy. Comparing that against a 32-bit time_t
build, however, gives a pretty clean list of code that needs attention.
As an experiment I've built OpenBMC with and without 64-bit time_t,
https://github.com/mkj/yocto-y2038 has the results and a description. There
are a mix of false positives (particularly tv_usec/tv_nsec), but also some
real-looking things. As an example, busybox using a uint32_t to copy a dhcpd
lease expiry.
I'm not sure the best way to use these logs - they need manual review.
Expanding the list of packages should be easy, but there will be more that
need manual intervention to get rid of -Werror.
issues which changing the compiler flags is going to break. Thanks for
sharing.
What you describe is relatively easy for a maintainer to do as a one
off check but not really something we can do at scale for all the
software we build. It worries me :/. I guess the one upside is that
whilst it did break some functionality, it didn't actually crash the
runtime if I understand what happened correctly.
I'm not sure this should stop our plan to switch the flags but it is
certainly something to think about and be aware of.
Cheers,
Richard
Dennis Lambe (He/Him) Lead Firmware Engineer Download Currently Today! |
Few things comes to mind. You could deploy the systemd unit fragment strategy
Hello,
I have a generic use-case of maintaining the meta layer. I have a custom meta layer. But this layer serves multiple customers who share most of the recipes and files. But some files are customer-specific. Currently, I am using different repos and tags in gitlab but regularly updating them is tedious and time-consuming. Rather I am think to create to create a generic meta layer and use Yocto features/variables (if existing) to maintain different versions. For example, a recipe test.bb has FILES_${PN} += "/lib/systemd/system/test.service \ "
But the contents of "test.service" is customer-specific and different versions has to be maintained. So, is there any way to make this generic? Can this be done using .bbappend files?
https://wiki.archlinux.org/title/systemd#Drop-in_files
so any customizations you have could be done via these drop-ins and
keeping common service file
these drops can be then controlled via customer distro specific
override in your main bb itself.
Second, way would be to have test.service copies installed under
files/<customer-override>/ directory next to recipe
and then define customer distro specific overrides
I assume this might be the use case of many people..
Thanks in advance
I have a generic use-case of maintaining the meta layer. I have a custom meta layer. But this layer serves multiple customers who share most of the recipes and files. But some files are customer-specific. Currently, I am using different repos and tags in gitlab but regularly updating them is tedious and time-consuming. Rather I am think to create to create a generic meta layer and use Yocto features/variables (if existing) to maintain different versions. For example, a recipe test.bb has FILES_${PN} += "/lib/systemd/system/test.service \ "
I assume this might be the use case of many people..
Thanks in advance
On Mon, 2022-12-05 at 11:00 +0100, Ola x Nilsson wrote:That works for me. I've started preparing a patch for oe-core.On Wed, Nov 30 2022, Richard Purdie wrote:That does sound useful, perhaps sharing it as an RFC patch might be aOn Wed, 2022-11-30 at 17:56 +0100, Alexandre Belloni wrote:I have a working sanity checker that checks for any glibc functionsOn 30/11/2022 16:46:17+0000, Ross Burton wrote:That sounds interesting and something we should probably look into forOn 30 Nov 2022, at 14:20, Richard Purdie via
lists.yoctoproject.org
<richard.purdie=linuxfoundation.org@...> wrote:Some time ago I filedI'm meaning disabling the 32 bit glibc time functions.* Could we optionally disable some of the glibc 32 bit function callsCould you be more specific here? Would you like to disable some
to ensure they're not being used?
syscalls?
https://bugzilla.yoctoproject.org/show_bug.cgi?id=6803 as Debian
has a nice sanity check where it warns if non-LFS glibc functions
are used. I imagine the same logic could be used to check for 32-
bit time_t use.
both issues...
affected by -D_FILE_OFFSET_BITS=64 or -D_TIME_BITS=64.
The INSANE_SKIP functionality needs some more polish but I'd be happy to
contribute it.
Some libraries use both 32 and 64 bit APIs to glibc and needs exceptions
in the checker.
I have not run any world builds with this checker, I've focused on the
recipes we actually use so far so we could get to a testable system. My
biggest worry at the moment is rust, I know to little to know if it is
an actual problem and how to fix it.
I would like to be part of any "y2038 team" for Yocto.
good place to start? We might be able to run one of the autobuilder
world targets against it, see how it looks for our core recipes?
--
Ola x Nilsson