Where to download zeus 0011-linux-user-remove-host-stime-syscall.patch?
JH
I failed qemu-native/4.1.0-r0/qemu-4.1.0/linux-user/syscall.c:7657:
undefined reference to `stime' running zeus on Ubuntu 20.04, googling to find a patch is needed to fix the bug, where can I download that patch file for zeus? recipes-devtools/qemu/qemu/0011-linux-user-remove-host-stime-syscall.patch I understand new version fixed that issue, but I am not in position to update the new version right now. Thank you. Kind regards, jupiter
|
|
How to assemble FIT images with linux and OPTEE?
Alex G.
Hi,
I'm trying to write a recipe for a secure boot flow. It would look something like this: images { optee@1 { "path/to/tee.bin" } linux@2 { "path/to/zImage" } fdt@board { ... } } configurations { secure { kernel = "optee@1"; loadables = "linux@2"; fdt = "fdt@board"; } } I've tried to "inherit kernel-fitimage", but soon learned of a couple of limitations: * images: No way to add an optee binary * configurations: No way to add a "loadables" Secondly, since this approach would use files from several packages, I think it would be better to have the recipe separate from the kernel build. Bot how would I use files from another recipe? All I could figure out was to first put them in ${DEPLOY_DIR_IMAGE}. What would be the "correct" way to write such a recipe? Alex
|
|
i2c and i2s configuartion in yocto.
NIKHIL PATIL <nikhilvp29@...>
Hi team, We are using audio codec (tlv320aic3109) connected to soc (intel E3900) via i2c . i2s is for audio transfer . ( Soc is a master and codec as a slave) . We are Using yocto sdk for x86 platform . for x86 platform , dts file is not there , so where i can mention all codec related stuffs. ( If it is ARM architecture means dts file there and we can mention codec stuffs there.) I enabled driver (tlv320aic32xx.c) in menuconfig. for i2cdetect command it shows slave address . but MCLK i am not getting on Oscilloscope while probing . 1) how we can configure for i2c and i2s in yocto ? 2) how we can initiate a MCLK from Soc side ? 3) Instead of dts file what is there for x86 arch ?
|
|
[meta-security][PATCH 5/5] tpm2-pkcs11: update to 1.4.0
Signed-off-by: Armin Kuster <akuster808@...>
--- .../0001-remove-local-binary-checkes.patch | 77 +++++++++++++++++++ ...2-pkcs11_1.3.0.bb => tpm2-pkcs11_1.4.0.bb} | 7 +- 2 files changed, 82 insertions(+), 2 deletions(-) create mode 100644 meta-tpm/recipes-tpm2/tpm2-pkcs11/files/0001-remove-local-binary-checkes.patch rename meta-tpm/recipes-tpm2/tpm2-pkcs11/{tpm2-pkcs11_1.3.0.bb => tpm2-pkcs11_1.4.0.bb} (80%) diff --git a/meta-tpm/recipes-tpm2/tpm2-pkcs11/files/0001-remove-local-binary-checkes.patch b/meta-tpm/recipes-tpm2/tpm2-pkcs11/files/0001-remove-local-binary-checkes.patch new file mode 100644 index 0000000..9d3f073 --- /dev/null +++ b/meta-tpm/recipes-tpm2/tpm2-pkcs11/files/0001-remove-local-binary-checkes.patch @@ -0,0 +1,77 @@ +From 9e3ef6f253f9427596baf3e7d748a79854cadfa9 Mon Sep 17 00:00:00 2001 +From: Armin Kuster <akuster808@...> +Date: Wed, 14 Oct 2020 08:55:33 -0700 +Subject: [PATCH] remove local binary checkes + +Signed-off-by: Armin Kuster <akuster808@...> + +Upsteam-Status: Inappropriate +These are only needed to run on the tartget so we add an RDPENDS. +Not needed for building. + +--- + configure.ac | 48 ------------------------------------------------ + 1 file changed, 48 deletions(-) + +diff --git a/configure.ac b/configure.ac +index 50e7d4b..2b9abcf 100644 +--- a/configure.ac ++++ b/configure.ac +@@ -219,54 +219,6 @@ AX_PROG_JAVAC() + AX_PROG_JAVA() + m4_popdef([AC_MSG_ERROR]) + +-AC_CHECK_PROG([tpm2_createprimary], [tpm2_createprimary], [yes], [no]) +- AS_IF([test "x$tpm2_createprimary" != "xyes"], +- [AC_MSG_ERROR([tpm2_ptool requires tpm2_createprimary, but executable not found.])]) +- +-AC_CHECK_PROG([tpm2_create], [tpm2_create], [yes], [no]) +- AS_IF([test "x$tpm2_create" != "xyes"], +- [AC_MSG_ERROR([tpm2_ptool requires tpm2_create, but executable not found.])]) +- +-AC_CHECK_PROG([tpm2_evictcontrol], [tpm2_evictcontrol], [yes], [no]) +- AS_IF([test "x$tpm2_evictcontrol" != "xyes"], +- [AC_MSG_ERROR([tpm2_ptool requires tpm2_evictcontrol, but executable not found.])]) +- +-AC_CHECK_PROG([tpm2_readpublic], [tpm2_readpublic], [yes], [no]) +- AS_IF([test "x$tpm2_readpublic" != "xyes"], +- [AC_MSG_ERROR([tpm2_ptool requires tpm2_readpublic, but executable not found.])]) +- +-AC_CHECK_PROG([tpm2_load], [tpm2_load], [yes], [no]) +- AS_IF([test "x$tpm2_load" != "xyes"], +- [AC_MSG_ERROR([tpm2_ptool requires tpm2_load, but executable not found.])]) +- +-AC_CHECK_PROG([tpm2_loadexternal], [tpm2_loadexternal], [yes], [no]) +- AS_IF([test "x$tpm2_loadexternal" != "xyes"], +- [AC_MSG_ERROR([tpm2_ptool requires tpm2_loadexternal, but executable not found.])]) +- +-AC_CHECK_PROG([tpm2_unseal], [tpm2_unseal], [yes], [no]) +- AS_IF([test "x$tpm2_unseal" != "xyes"], +- [AC_MSG_ERROR([tpm2_ptool requires tpm2_unseal, but executable not found.])]) +- +-AC_CHECK_PROG([tpm2_encryptdecrypt], [tpm2_encryptdecrypt], [yes], [no]) +- AS_IF([test "x$tpm2_encryptdecrypt" != "xyes"], +- [AC_MSG_ERROR([tpm2_ptool requires tpm2_encryptdecrypt, but executable not found.])]) +- +-AC_CHECK_PROG([tpm2_sign], [tpm2_sign], [yes], [no]) +- AS_IF([test "x$tpm2_sign" != "xyes"], +- [AC_MSG_ERROR([tpm2_ptool requires tpm2_sign, but executable not found.])]) +- +-AC_CHECK_PROG([tpm2_getcap], [tpm2_getcap], [yes], [no]) +- AS_IF([test "x$tpm2_getcap" != "xyes"], +- [AC_MSG_ERROR([tpm2_ptool requires tpm2_getcap, but executable not found.])]) +- +-AC_CHECK_PROG([tpm2_import], [tpm2_import], [yes], [no]) +- AS_IF([test "x$tpm2_import" != "xyes"], +- [AC_MSG_ERROR([tpm2_ptool requires tpm2_import, but executable not found.])]) +- +-AC_CHECK_PROG([tpm2_changeauth], [tpm2_changeauth], [yes], [no]) +- AS_IF([test "x$tpm2_changeauth" != "xyes"], +- [AC_MSG_ERROR([tpm2_ptool requires tpm2_changeauth, but executable not found.])]) +- + AC_DEFUN([integration_test_checks], [ + + PKG_CHECK_MODULES([OPENSC_PKCS11],[opensc-pkcs11],, +-- +2.17.1 + diff --git a/meta-tpm/recipes-tpm2/tpm2-pkcs11/tpm2-pkcs11_1.3.0.bb b/meta-tpm/recipes-tpm2/tpm2-pkcs11/tpm2-pkcs11_1.4.0.bb similarity index 80% rename from meta-tpm/recipes-tpm2/tpm2-pkcs11/tpm2-pkcs11_1.3.0.bb rename to meta-tpm/recipes-tpm2/tpm2-pkcs11/tpm2-pkcs11_1.4.0.bb index ce2dac0..4865733 100644 --- a/meta-tpm/recipes-tpm2/tpm2-pkcs11/tpm2-pkcs11_1.3.0.bb +++ b/meta-tpm/recipes-tpm2/tpm2-pkcs11/tpm2-pkcs11_1.4.0.bb @@ -7,9 +7,10 @@ LIC_FILES_CHKSUM = "file://LICENSE;md5=0fc19f620a102768d6dbd1e7166e78ab" DEPENDS = "autoconf-archive pkgconfig dstat sqlite3 openssl libtss2-dev tpm2-tools libyaml" SRC_URI = "git://github.com/tpm2-software/tpm2-pkcs11.git;branch=1.X \ - file://bootstrap_fixup.patch " + file://bootstrap_fixup.patch \ + file://0001-remove-local-binary-checkes.patch" -SRCREV = "8d8f137f65f1d61d66cc191947b59c378f23e97d" +SRCREV = "78bbf6a0237351830d0c3923b25ba0b57ae0b7e9" S = "${WORKDIR}/git" @@ -18,3 +19,5 @@ inherit autotools-brokensep pkgconfig do_configure_prepend () { ${S}/bootstrap } + +RDEPNDS_${PN} = "tpm2-tools" -- 2.17.1
|
|
[meta-security][PATCH 4/5] tpm2-tools: update to 4.3.0
LIC_FILES_CHKSUM changes do to added Copyright
Signed-off-by: Armin Kuster <akuster808@...> --- .../{tpm2-pkcs11_1.2.0.bb => tpm2-pkcs11_1.3.0.bb} | 0 .../tpm2-tools/{tpm2-tools_4.1.3.bb => tpm2-tools_4.3.0.bb} | 4 ++-- 2 files changed, 2 insertions(+), 2 deletions(-) rename meta-tpm/recipes-tpm2/tpm2-pkcs11/{tpm2-pkcs11_1.2.0.bb => tpm2-pkcs11_1.3.0.bb} (100%) rename meta-tpm/recipes-tpm2/tpm2-tools/{tpm2-tools_4.1.3.bb => tpm2-tools_4.3.0.bb} (64%) diff --git a/meta-tpm/recipes-tpm2/tpm2-pkcs11/tpm2-pkcs11_1.2.0.bb b/meta-tpm/recipes-tpm2/tpm2-pkcs11/tpm2-pkcs11_1.3.0.bb similarity index 100% rename from meta-tpm/recipes-tpm2/tpm2-pkcs11/tpm2-pkcs11_1.2.0.bb rename to meta-tpm/recipes-tpm2/tpm2-pkcs11/tpm2-pkcs11_1.3.0.bb diff --git a/meta-tpm/recipes-tpm2/tpm2-tools/tpm2-tools_4.1.3.bb b/meta-tpm/recipes-tpm2/tpm2-tools/tpm2-tools_4.3.0.bb similarity index 64% rename from meta-tpm/recipes-tpm2/tpm2-tools/tpm2-tools_4.1.3.bb rename to meta-tpm/recipes-tpm2/tpm2-tools/tpm2-tools_4.3.0.bb index ae01d5e..5bd26ab 100644 --- a/meta-tpm/recipes-tpm2/tpm2-tools/tpm2-tools_4.1.3.bb +++ b/meta-tpm/recipes-tpm2/tpm2-tools/tpm2-tools_4.3.0.bb @@ -1,13 +1,13 @@ SUMMARY = "Tools for TPM2." DESCRIPTION = "tpm2-tools" LICENSE = "BSD-3-Clause" -LIC_FILES_CHKSUM = "file://LICENSE;md5=0eb1216e46938bd723098d93a23c3bcc" +LIC_FILES_CHKSUM = "file://doc/LICENSE;md5=a846608d090aa64494c45fc147cc12e3" SECTION = "tpm" DEPENDS = "tpm2-abrmd tpm2-tss openssl curl autoconf-archive" SRC_URI = "https://github.com/tpm2-software/${BPN}/releases/download/${PV}/${BPN}-${PV}.tar.gz" -SRC_URI[sha256sum] = "bb5d3310620e75468fe33dbd530bd73dd648c70ec707b4579c74d9f63fc82704" +SRC_URI[sha256sum] = "ae009b3495b44a16faa3d94d41ac9c9d99c71723482efad53c5eea17eeed80fc" inherit autotools pkgconfig bash-completion -- 2.17.1
|
|
[meta-security][PATCH 3/5] tpm2-abrmd: update to 2.3.3
Signed-off-by: Armin Kuster <akuster808@...>
--- .../tpm2-abrmd/{tpm2-abrmd_2.3.0.bb => tpm2-abrmd_2.3.3.bb} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename meta-tpm/recipes-tpm2/tpm2-abrmd/{tpm2-abrmd_2.3.0.bb => tpm2-abrmd_2.3.3.bb} (97%) diff --git a/meta-tpm/recipes-tpm2/tpm2-abrmd/tpm2-abrmd_2.3.0.bb b/meta-tpm/recipes-tpm2/tpm2-abrmd/tpm2-abrmd_2.3.3.bb similarity index 97% rename from meta-tpm/recipes-tpm2/tpm2-abrmd/tpm2-abrmd_2.3.0.bb rename to meta-tpm/recipes-tpm2/tpm2-abrmd/tpm2-abrmd_2.3.3.bb index 991364a..d2a1c47 100644 --- a/meta-tpm/recipes-tpm2/tpm2-abrmd/tpm2-abrmd_2.3.0.bb +++ b/meta-tpm/recipes-tpm2/tpm2-abrmd/tpm2-abrmd_2.3.3.bb @@ -18,7 +18,7 @@ SRC_URI = "\ file://tpm2-abrmd.default \ " -SRCREV = "ac82192df1158cb58eac02777cf15c965b02cfbc" +SRCREV = "4cdda466010a3699ebe967d990ac715ae3de7d35" S = "${WORKDIR}/git" -- 2.17.1
|
|
[meta-security][PATCH 2/5] tpm2-totp: update to 0.2.1
Signed-off-by: Armin Kuster <akuster808@...>
--- .../tpm2-totp/{tpm2-totp_0.2.0.bb => tpm2-totp_0.2.1.bb} | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) rename meta-tpm/recipes-tpm2/tpm2-totp/{tpm2-totp_0.2.0.bb => tpm2-totp_0.2.1.bb} (85%) diff --git a/meta-tpm/recipes-tpm2/tpm2-totp/tpm2-totp_0.2.0.bb b/meta-tpm/recipes-tpm2/tpm2-totp/tpm2-totp_0.2.1.bb similarity index 85% rename from meta-tpm/recipes-tpm2/tpm2-totp/tpm2-totp_0.2.0.bb rename to meta-tpm/recipes-tpm2/tpm2-totp/tpm2-totp_0.2.1.bb index 0dad673..264484f 100644 --- a/meta-tpm/recipes-tpm2/tpm2-totp/tpm2-totp_0.2.0.bb +++ b/meta-tpm/recipes-tpm2/tpm2-totp/tpm2-totp_0.2.1.bb @@ -9,9 +9,8 @@ DEPENDS = "autoconf-archive libtss2-dev qrencode" PE = "1" -SRCREV = "994b4203e4769baefa6e7719915629bc8210e90a" -SRC_URI = "git://github.com/tpm2-software/tpm2-totp.git;branch=v0.2.x \ - " +SRCREV = "bfd581986353edc1058604e77cac804bd8b0d30a" +SRC_URI = "git://github.com/tpm2-software/tpm2-totp.git;branch=v0.2.x" inherit autotools-brokensep pkgconfig -- 2.17.1
|
|
[meta-security][PATCH 1/5] tpm2-tss: update to 2.4.3
includes: CVE-2020-24455
Signed-off-by: Armin Kuster <akuster808@...> --- .../tpm2-tss/{tpm2-tss_2.4.1.bb => tpm2-tss_2.4.3.bb} | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) rename meta-tpm/recipes-tpm2/tpm2-tss/{tpm2-tss_2.4.1.bb => tpm2-tss_2.4.3.bb} (94%) diff --git a/meta-tpm/recipes-tpm2/tpm2-tss/tpm2-tss_2.4.1.bb b/meta-tpm/recipes-tpm2/tpm2-tss/tpm2-tss_2.4.3.bb similarity index 94% rename from meta-tpm/recipes-tpm2/tpm2-tss/tpm2-tss_2.4.1.bb rename to meta-tpm/recipes-tpm2/tpm2-tss/tpm2-tss_2.4.3.bb index 22b961d..78be513 100644 --- a/meta-tpm/recipes-tpm2/tpm2-tss/tpm2-tss_2.4.1.bb +++ b/meta-tpm/recipes-tpm2/tpm2-tss/tpm2-tss_2.4.3.bb @@ -6,10 +6,8 @@ SECTION = "tpm" DEPENDS = "autoconf-archive-native libgcrypt openssl" -SRCREV = "a99e733ba66c359502689a9c42fd5e02ed1dd7d6" - SRC_URI = "https://github.com/tpm2-software/${BPN}/releases/download/${PV}/${BPN}-${PV}.tar.gz" -SRC_URI[sha256sum] = "58d7afcab9ff3daaafb5316e57d2c211118334b470d5a5bc6ceace6f89a1e60d" +SRC_URI[sha256sum] = "e294677f8993234d0adfa191a5cbf9c5b83cc60c724c233e3d631c26712abea0" inherit autotools pkgconfig systemd extrausers -- 2.17.1
|
|
Re: Pinging problem
jchludzinski
After I checked the networking status: $ systemctl status networking
networking.service - LSB: Raise network interfaces.Loaded: loaded (/etc/init.d/networking; generated)Active: [[0;1;31mfailed[[0m (Result: exit-code) since Tue 2020-05-12 15:18:58 UTC; 1h 14min agoDocs: man:systemd-sysv-generator(8)Process: 736 ExecStart=/etc/init.d/networking start [[0;1;31m(code=exited, status=1/FAILURE)[[0mMay 12 15:18:58 arria10 systemd[1]: Starting LSB: Raise network interfaces....May 12 15:18:58 arria10 networking[736]: Configuring network interfaces... ip: RTNETLINK answers: File existsMay 12 15:18:58 arria10 systemd[1]: [[0;1;39m[[0;1;31m[[0;1;39mnetworking.service: Control process exited, code=exited, status=1/FAILURE[[0mMay 12 15:18:58 arria10 systemd[1]: [[0;1;38;5;185m[[0;1;39m[[0;1;38;5;185mnetworking.service: Failed with result 'exit-code'.[[0mMay 12 15:18:58 arria10 systemd[1]: [[0;1;31m[[0;1;39m[[0;1;31mFailed to start LSB: Raise network interfaces..
|
|
Pinging problem
jchludzinski
I just built and installed Linux "arria10 5.4.44-05635-gb810a419a2fa-dirty #2 SMP" onto my board. It recognized the Ethernet interface right out of the box and assigned a static IP address.
I have Ethernet on the board connected to my Linux (Fedora v32) laptop. When I ping from the board to the laptop, the laptop receives the board's ARP request for its MAC address. The laptop then attempts to respond by sending an ARP reply with its MAC address. Apparently the board is not receiving that reply. I validated this pinging from the laptop. The laptop is sending the ARP request "Who has <board IP address>?" And there is no respond coming from the board. Any ideas on what might be happening?
|
|
[meta-security][PATCH] scap-security-guide: add expat-native to DEPENDS
Yu, Mingli
From: Mingli Yu <mingli.yu@...>
Add expat-native to DEPENDS to fix the below do_configure error: | CMake Error at CMakeLists.txt:165 (message): | xmlwf is required! Signed-off-by: Mingli Yu <mingli.yu@...> --- .../scap-security-guide/scap-security-guide.inc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta-security-compliance/recipes-openscap/scap-security-guide/scap-security-guide.inc b/meta-security-compliance/recipes-openscap/scap-security-guide/scap-security-guide.inc index 66c2623..32fce0f 100644 --- a/meta-security-compliance/recipes-openscap/scap-security-guide/scap-security-guide.inc +++ b/meta-security-compliance/recipes-openscap/scap-security-guide/scap-security-guide.inc @@ -6,7 +6,7 @@ HOME_URL = "https://www.open-scap.org/security-policies/scap-security-guide/" LIC_FILES_CHKSUM = "file://LICENSE;md5=97662e4486d9a1d09f358851d9f41a1a" LICENSE = "LGPL-2.1" -DEPENDS = "openscap-native python3 python3-pyyaml-native python3-jinja2-native libxml2-native" +DEPENDS = "openscap-native python3 python3-pyyaml-native python3-jinja2-native libxml2-native expat-native" S = "${WORKDIR}/git" -- 2.17.1
|
|
This is not ideal to capture compiler for your app it should be written portably my guess is that app has issues with using golang properly Do you know what changes they made to compiler and which version is it locked to
On Tue, Oct 13, 2020 at 11:51 AM Mike Thompson via lists.yoctoproject.org <mthompson=dustyrobotics.com@...> wrote:
|
|
Yocto Technical Team Minutes, Engineering Sync, for October 6, 2020
Trevor Woerner
Yocto Technical Team Minutes, Engineering Sync, for October 6, 2020
archive: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit == disclaimer == Best efforts are made to ensure the below is accurate and valid. However, errors sometimes happen. If any errors or omissions are found, please feel free to reply to this email with any corrections. == attendees == Trevor Woerner, Stephen Jolly, Armin Kuster, Josef Holzmayr, Richard Purdie, Joshua Watt, Trevor Gamblin, Steve Sakoman, Paul Barker, Saul Wold, Stacy Gaikovaia, Rob Woolley, Randy MacLeod, Michael Halstead, Jon Mason, Ross Burton, Jan-Simon Möller, Mark Hatle, Scott Murray, Vikram Subramanian, Tim Orling, Denys Dmytriyenko, Bruce Ashfield, Christopher Larson, Martin Jansa (JaMa) == notes == - m3-rc2 released - well into m4 - 3.1.3 out of QA (in review by TSC) - ready for m4, won’t be built until pseudo cleared up - large number of intermittent AB issues == general == RP: 3.1.3 has a ptest regression in perl, but it was due to the test, not perl. some tests need fixing for 3.1.4 SS: it was a problem with the count of the number of tests RP: we’re a little behind schedule for m4, but we need to get pseudo under control RP: if you create files in a pseudo context (LD_PRELOAD) e.g. do_package_qa, do_install, etc if you create a file in that context but then delete it outside that context but then go back into pseudo and try to manipulate the file pseudo gets confused (it assumes if it has the same inode then it’s the same file) RP: one solution is to add path filtering so that pseudo will ignore certain files in certain paths (e.g. sysroot native). the more paths we filter out from the pseudo database the less likely we’ll trip over inode issues. pseudo needs to be unloaded when qemu is run (since they don’t get along). we generally don’t want the files that end up in the deploy folder to be under pseudo, but the tasks that do that (put files in the deploy folder) need to run under pseudo. there’s also the issue of hard linking: sometimes there’s a file under pseudo’s control but then a hard link is made to it so now pseudo needs to know that this other path is the same file as this other thing it knows about. RP: right now we’ve added code so that pseudo aborts should it find an inconsistency. so before releasing: - do we add path filtering: i think yes - do we have pseudo abort if it finds inconsistencies: ?? MarkH: could we do an insane_skip? RP: just to be clear, the abort doesn’t happen consistently in all cases, they hit randomly. i added code to do a sanity check on the db and it found stuff, but it’s not practical to run sanity tests during a live build. a human can look at the issues and know “this is sane, this one isn’t” but coding it isn’t easy MarkH: we should have clear documentation, because layers are going to hit it for sure RP: agreed RP: i was hoping these fixes would improve the builds (time, space) but it only seems to affect space Josef: is this a new issue? RP: problem has been there for years. i can point to bugs 3-4 years ago that had weird permission changes that couldn’t be explained. now i can see this behaviour was the cause. it’s probably been in the pseudo code from the start. why are we seeing it now? because the AB is so extremely busy and i was lucky to catch it once that made it easy to track down. also recipe-specific sysroots exacerbates the issue, making it potentially occur more often now. Josef: then we should focus on fixing RP: agreed. and we need to think of LTS too Josef: any idea on how bad the issue is? is it 1 in 100? 1/1000? 1/10000??? RP: don’t know. the new code, working with sqlite package, brings the number of db entries down from 10,000 to 500. so that means that there were all those extra entries that could be causing issues. all that extra was stuff that was installed but then later deleted (but the db not cleaned up). much less likely to see issue if you’re using a clean build every time rather than reusing the same build area over and over PaulB: are there legitimate cases where we need to delete something from a non-pseudo task that was put in place under pseudo? RP: yes sysroot-native PaulB: is the abort patch available? RP: all in master-next MarkH: fyi i’ve been running that code and haven’t seen an issue Randy: layers? MarkH: meta-browser, meta-xilinx, poky, meta-oe JS-M: i back ported it to dunfell and ran it against AGL, zero hits so far Randy: i’m surprised we’re not seeing it “in the field” RP: i’m not, it’s a core issue, which layers and how many layers shouldn’t affect it RP: for eg. there was an sstate test that would fail, but it only ever failed on one specific worker. turned out to be a cache invalidation issue (sstate cache). pseudo’s ignore paths, which included the cache, should have ignore it but weren’t RP: anyway, please test Randy: a week or two until release? RP: sooner than later S: rc1? RP: m4-rc1. probably not before next week PaulB: i’d rather see aborts than silent failures RP: it’ll annoy people that the aborts are not deterministic JS-M: can we print an error that’ll help the user RP: it’ll be hard to convey the problem when an abort happens Randy: i can offer a large system for helping JS-M: i can offer a large system too Randy: any other tests we can do to try to repeat? Randy: is inode reuse policy done by FS or pseudo? RP: FS. there might be different policies and figuring them out TW: if this issue has been there potentially from the beginning, is it possible there are bad images in the field? images that were built years ago, in production, that might have a bad permission in some file that's almost never used, but could fail if that file is accessed? RP: yes TW: does the file path size of the build area affect this? conversely, could shorter paths help avoid the issue? RP: longer paths will cause slower builds, but not breaking. path comparison is fast, but not an issue. might need to switch to an allow list rather than a deny list, but MarkH has warned against that approach RP: i’ve had more ideas about improving build speed PaulB: do we know when we’re going to talk about features for the next release? RP: not planned yet, we don’t have a lot of people working on new features (like we used to) so if nobody has the time to add new things, there’s little point to talk about what we’d like Randy: should we talk about it in this call? should it only be for the 1st call of the month? Saul: i looked at the qemu monitor issue. i’m trying to use the qemu monitor which gives us visibility into at the state of memory/network/etc qemu. RP suggested we might be able to use the monitor, which often uses the same connection as the serial/console switching between them by a Ctrl key. i was able to get the qemu-montior away from the serial console, interract with it via netcat/telnet in order to access the selftest. RP: what are you seeing? Saul: i’m using qemu-runner to try to connect to the monitor, but it hangs. so if someone has better knowledge of python select()/poll() it might help. i’m select()/poll() on the socket, but it never completes. JPEW: i can help RP: share the code :-) Timo: toaster-container still failing, trying to instrument the code to find out why/where? just getting a bb-unhandled, which isn’t helpful RP: do you have the cooker log? Timo: yes, but it looks clean. it’s the toaster-ui log that shows the failure RP: these are caused by changes i made in bitbake, technically this should be a release blocker Saul: is TOPDIR whitelisted, or magically removed elsewhere? RP: whitelisted from what? sstate-hash Saul: but it’s not in the whitelist itself? it’s magically done RP: it shouldn’t be magic RP: we exclude TMPDIR, so maybe it falls under that JPEW: parsing improvements? RP: PSEUDO_IGNORE_PATHS which has other stuff in it e.g. BUILDHISTORY_DIR. i had been trying to keep BUILDHISTORY_DIR out. the vardeps excludes aren’t working properly, i noticed all variables were being recursed indefinately. i think that at parse time it can get away with only going 1-deep, at build time we need to parse indefinitely, but it would speed up the parsing step. it is a large job at parse time because at parse time it’s looking at everything, at build time we only look at stuff relevant to that task. There’s a chance we’re already relying on this behaviour, which would make it harder to change. TW: MACHINE_EXTRA_RRECOMMENDS is not included in core-image-full-cmdline, is that okay? RP: i stumbled across this earlier, there was an explanation PaulB: probably not included packagegroup-core-base RP: yes, there was a reason, can’t quite remember
|
|
Yocto Technical Team Minutes, Engineering Sync, for October 13, 2020
Trevor Woerner
Yocto Technical Team Minutes, Engineering Sync, for October 13, 2020
archive: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit == disclaimer == Best efforts are made to ensure the below is accurate and valid. However, errors sometimes happen. If any errors or omissions are found, please feel free to reply to this email with any corrections. == attendees == Trevor Woerner, Stephen Jolly, Saul Wold, Armin Kuster, Jan-Simon Möller, Joshua Watt, Sakib Sajal, Steve Sakoman, Scott Murray, Randy MacLeod, David Reyna, Richard Purdie, Stacy Gaikoviaia, Jon Mason, Michael Halstead, Tim Orling, Ross Burton, Bruce Ashfield, Alejandro H, Paul Barker, Trevor Gamblin == notes == - 3.1.3 has been released - 1 week overdue for M4 (3 bugs to clear (buildtools, toaster, init script)) - major pseudo changes merged - thanks for Victor for changes on qemu-mips - 3.3 planning has started (see google doc https://docs.google.com/document/d/1IHiE0NU0XspDocgxZeLQ_W7o-yr0nVeBjbqImQUtH5A) == general == RP: pseudo much improved, if you find issues going forward please report them, hopefully just edge cases left RP: 3 outstanding bugs for m4 (Tim working on toaster, Ross working on buildtools, Armin on init scripts) Randy: WR will be doing a bunch of builds on the new pseudo tonight RP: AB is all green! RP: curious behaviour on the AB. one build fully succeeds, next build (no changes) has failures (bitbake timeouts in tinfoil), starting a new build again (again no changes) succeeds. were there any NAS issues that might explain this? Michael: not that I know of, nor outages this past weekend. was it infrastructure-based, or maybe timeouts accessing remote repositories? RP: it should have been all in cache. Ross: it’s like a gremlin jumped in, broke all the builds, then left RP: okay, gremlins it is RP: what’s up with the buildtools issues? Ross: I’m not fond of exposing more variables to the build than are absolutely necessary RP: (fyi: this is the ssl variables needed to be exposed issue) RP: Armin, Tim, any updates? Armin: still working through the init scripts, making sure they all run Tim: there are a lot of steps of what calling what, not sure how/when cooker data gets populated RP: yes, and changes that were made are affecting this Tim: some part assumes the data is already there RP: all but 2 tasks populate the cooker data, which seemed wasteful, so i changed command.py (see link: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=0bcc00ac517bdb9a80353 97fcac0a402fe1aad13) RP: there were race issues, this fixed the race issues Tim: the code that stopped working didn’t have any try-catch around it, so it probably wasn’t a robust design to begin. the issue is bitbake, it just showed up in toaster (i.e. don’t think it’s a django issue for example) RP: there is a bit of pressure Tim: been busy with Yocto Summit preparation, but that’s going well, so i should have time for this now JPEW: want to talk about new stuff for 3.3? RP: mostly 3.2 stuff that haven’t gotten around to RP: there’s a recursive variable parsing thing that I’ve put your name against tentatively (JPEW) JPEW: yes, i can take a look RP: changing AB to split up logging more, i think that should be done this time RP: i like some of the performance graph things I’ve done lately (i.e. buildstats) maybe that should get in Tim: i’m working with a data science major (outreachy) to look at this… Saul: whoa! we also have a data science major working with Rob Wooley to do some performance graph things, we need to sync up! RP: i’m glad to let people work independently on this, we’ve had people look at this in the past but not get anywhere. sure, have them collaborate but not if it stalls the process/progress Tim: i think the collaboration could be good to make sure nobody goes down dead alleys (relational DB, django, ORM, etc) we should use the same DB as KernelCI (graphana), just trying to read in the data (5GB!!) is difficult Tracy: not sure if this helps, but there’s also Apache Casandra that could be worth exploring (linear performance) RP: there’s no right answer, tools depend on approach Saul: what, RP, are you most interested in? RP: performance metrics Saul: which? RP: parsing time, build time, size tests, test results regressions (overall count and which regress) by commit ranges Saul: we’re looking at overall build time and bottleneck issues (stalling on I/O, etc) RP: we’re stalling on ./configure, 40%: half is autoreconf and half is ./configure execution, but neither are things we want to cache. would be great to go through the m4 base code and delete anything that’s old Ross: i have been looking at this RP: you can do that on the AB, if you run it with build perf it will give you the numbers Scott: now that hash equivalence has been in for a while, is it helping? RP: definitely a win, helps with some changes, but not others (i.e. change to a base task, it can’t tell if it needs to run everything or not e.g. do_compile in base class), it’s been a big win for the AB (but can’t prove it, just a feeling) Randy: going back to 40% in ./configure, trimming scripts that are run, would using dash save a few percent? RP: no. i don’t think the shell would make any difference. there was a test done and bash was shown to be faster, if anything. cutting out m4 macros will save on, for example, macro expansion with all the crazy things that expansion does. my conjecture is that if we remove stuff from the m4 macros for things we don’t care about, that should save a lot of time. if we deleted a lot of the tests and just pasted in the results that should also make it faster. Randy: how do you feel about diverging from upstream? RP: depends on if we can maintain it Scott: if autoreconf was a separate task that could be cached, would that be a win? RP: i’ve wondered about it… don’t know. you could cache it using sstate, it would have minimal dependencies, hard to tell which files that would change would need to re-trigger Scott: equivalency would be based on what it needs RP: yes, but rerunning is a nightmare Scott: isn’t sstate after do_patch? RP: no Scott: ah RP: lots if disk space overhead otherwise. i was looking at this recently (for something else) but couldn’t figure it out, maybe we should revisit it for 3.3 Randy: Ross, you were working on getting stuff to work with any toolchain? Ross: meta-clang has interesting classes that allow one to swap in any toolchain for arbitrary packages. this is something that core should be able to do so that anyone can switch between any toolchain from anywhere for any packages RP: Victor contributed his qemu-mips patches upstream and it looks like they’re going to take it so we won’t have to carry the patches anymore JPEW: i’ll be working on two issues: 1) have an upstream server to pull hashes from, perhaps read-only. 2) replacing multiprocessing in cooker RP: there is an outstanding bug where if someone does Ctrl-C on a build that is using git AUTOREV there seems to be an issue. maybe there’s a way to test this? JPEW: yes, we can switch all to AUTOREV easily to stress test this path (multiprocessing). what’s the bug #? RP: 14034 RP: we fixed the things we were able to reproduce, but no the AUTOREV issue JPEW: i can take a look RP: thanks Randy: any way to avoid ptest dependency creep? RP: lots of tests have dependencies on perl, bash, gcc, etc. RP: see link https://autobuilder.yocto.io/pub/non-release/20201012-6/testresults/buildperf-ubuntu1604/perf-ubuntu1604_master_20201012150127_0c0b236b4c.html of performance metrics. you’ll see a nice drop-off, that’s due to changes from Ross Randy: what about getting rid of perl-modules? RP: yes, which then pulled in a whole bunch of stuff. so yes there’s creep, if we can remove them, it does show noticeable improvements Ross: 30 minute improvement on my build machine. e.g. ptest was building gcc for the target! takes way too long RP: builds a target qemu for every architecture for any one build, perhaps something like that could be target-specific. Ross sees a larger improvement than the AB due to parallelism. a smaller machine with fewer cores will get bottlenecked on this by a larger percentage. anyway, that’s why these charts are so important. RP: there are a couple OSVs on the call, there seem to be a lot of CVEs against Dunfell, is there anything we can do about it. i’m guessing there must be patches out there Randy: WR isn’t on Dunfell, we’re on Zeus and we send those upstream RP: are you going to align with Dunfell Randy: probably not Alejandro: it’s something i’ve been trying to find time to do Tim: the emails, the “new” ones are newly found ones this week? and “removed” are ones we’ve fixed? Steve: in theory yes. sometimes a “new” has an old date, sometime the affected version is all wildcards, so hard to know Ross: i went through some of those wildcards wrt qemu and removed a bunch of them due to narrowing down the version Tim: i think we have some people looking at this RP: it would be great if we coordinated. if everyone took 1 a week and looked at it, and it was coordinated, that would make a huge improvement Tim: should we auto-create bugzillas? RP: no, we should not be auto-creating anything in bugzilla Randy: how do we divide up the work? RP: wiki? don’t need bugzilla for it. if you have a curated list you can put it into bugzilla, that would be fine. but auto-creating bugzillas would be carnage Scott: are we particularly interested in qemu ones more than others? Steve: i’d like to see CVE fixes for anything that runs on the target Scott: seems like many/most are for qemu Steve: and some native ones too Stephen: over time, thanks!
|
|
Mike Thompson <mthompson@...>
A follow up on a Yocto recipe for building a Tailscale package for others who have an interest in this. Although the final recipe I created appears to successfully build the Tailscale utility and daemon without warnings or errors, the resulting 'tailscaled' daemon crashes when used. Investigating this issue further I discovered that Tailscale maintains their own GoLang repository with changes needed to support Tailscale. I suspect, but haven't proven, using the standard Yocto supported versions of GoLang to build Tailscale results in the crashes I see. Unfortunately, I don't have enough of an understanding of GoLang to determine how to build Tailscale with the unique version of GoLang maintained by the Tailscale folks.. Instead of resolving this build issue, I instead created a Yocto recipe that utilizes the released binaries from Tailscale to create a Yocto package. This isn't ideal as I would much rather build from source, but solves my short term needs. This alternate recipe to build a Yocto package from binaries is included below. ------------------------------------------------------------------------ tailscale_1.0.5.bb SUMMARY = "Tailscale client and daemon for Linux from Tailscale pre-built binaries" HOMEPAGE = "github.com/tailscale/tailscale" SECTION = "net" LICENSE = "CLOSED"
COMPATIBLE_HOST = "x86_64.*-linux"
# Archive URL: # https://pkgs.tailscale.com/stable/tailscale_1.0.5_amd64.tgz # # Archive contents: # tailscale_1.0.5_amd64/systemd # tailscale_1.0.5_amd64/systemd/tailscaled.service # tailscale_1.0.5_amd64/systemd/tailscaled.defaults # tailscale_1.0.5_amd64/tailscaled # tailscale_1.0.5_amd64/tailscale # # Set SRC_URI subdir to ${P} so that files are unpacked into ${S} SRC_URI = "https://pkgs.tailscale.com/stable/${BPN}_${PV}_amd64.tgz;subdir=${P}" SRC_URI[md5sum] = "fad1e5317ec567b77c3a0b53b8b976cf" SRC_URI[sha256sum] = "ecfcda12068d6ecb2be72eba5572ab09406643bcc73c0cd482ae88060720c430"
inherit systemd
FILES_${PN} += "${systemd_unitdir}/*"
do_install() { install -d ${D}/${bindir} install -d ${D}/${sbindir} install ${S}/${PN}_${PV}_amd64/tailscale ${D}/${bindir}/tailscale install ${S}/${PN}_${PV}_amd64/tailscaled ${D}/${sbindir}/tailscaled
if ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'true', 'false', d)}; then install -d ${D}${sysconfdir}/default/ install -m 0644 ${S}/${PN}_${PV}_amd64/systemd/tailscaled.defaults ${D}${sysconfdir}/default/tailscaled
install -d ${D}${systemd_unitdir}/system install -m 0644 ${S}/${PN}_${PV}_amd64/systemd/tailscaled.service ${D}${systemd_unitdir}/system/tailscaled.service
install -d ${D}${sysconfdir}/systemd/system/multi-user.target.wants/ ln -s ${systemd_unitdir}/system/tailscaled.service ${D}${sysconfdir}/systemd/system/multi-user.target.wants/tailscaled.service fi }
SYSTEMD_PACKAGES = "${PN}" SYSTEMD_SERVICE_${PN} = "tailscaled.service"
SYSTEMD_AUTO_ENABLE = "enable" ------------------------------------------------------------------------
Mike Thompson
|
|
Re: [meta-openssl102-fips][PATCH] conf/layer.conf: Add dunfell to LAYERSERIES_COMPAT
Davis, Michael
Sorry about the spam the [meta-openssl102-fips] kept getting eaten by a missing -.
toggle quoted messageShow quoted text
-----Original Message-----
From: Davis, Michael Sent: Tuesday, October 13, 2020 11:57 AM To: yocto@... Cc: Davis, Michael <michael.davis@...> Subject: [meta-openssl102-fips][PATCH] conf/layer.conf: Add dunfell to LAYERSERIES_COMPAT Signed-off-by: Michael Davis <michael.davis@...> --- conf/layer.conf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/conf/layer.conf b/conf/layer.conf index 892cf79..1559f57 100644 --- a/conf/layer.conf +++ b/conf/layer.conf @@ -10,7 +10,7 @@ BBFILE_PRIORITY_meta-openssl-one-zero-two-fips = "5" LAYERVERSION_meta-openssl-one-zero-two-fips = "1" -LAYERSERIES_COMPAT_meta-openssl-one-zero-two-fips = "zeus" +LAYERSERIES_COMPAT_meta-openssl-one-zero-two-fips = "zeus dunfell" LAYERPATH_meta-openssl-one-zero-two-fips = "${LAYERDIR}" -- 2.26.2 CONFIDENTIALITY NOTICE: This e-mail transmission and any documents, files or previous e-mail messages attached to it may contain information that is confidential, protected by the attorney/client or other privileges, and may constitute non-public information. It is intended to be conveyed only to the designated recipient(s) named above.
|
|
[meta-openssl102-fips][PATCH] conf/layer.conf: Add dunfell to LAYERSERIES_COMPAT
Davis, Michael
Signed-off-by: Michael Davis <michael.davis@...>
--- conf/layer.conf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/conf/layer.conf b/conf/layer.conf index 892cf79..1559f57 100644 --- a/conf/layer.conf +++ b/conf/layer.conf @@ -10,7 +10,7 @@ BBFILE_PRIORITY_meta-openssl-one-zero-two-fips = "5" LAYERVERSION_meta-openssl-one-zero-two-fips = "1" -LAYERSERIES_COMPAT_meta-openssl-one-zero-two-fips = "zeus" +LAYERSERIES_COMPAT_meta-openssl-one-zero-two-fips = "zeus dunfell" LAYERPATH_meta-openssl-one-zero-two-fips = "${LAYERDIR}" -- 2.26.2 CONFIDENTIALITY NOTICE: This e-mail transmission and any documents, files or previous e-mail messages attached to it may contain information that is confidential, protected by the attorney/client or other privileges, and may constitute non-public information. It is intended to be conveyed only to the designated recipient(s) named above.
|
|
[PATCH] conf/layer.conf: Add dunfell to LAYERSERIES_COMPAT
Davis, Michael
Signed-off-by: Michael Davis <michael.davis@...>
--- conf/layer.conf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/conf/layer.conf b/conf/layer.conf index 892cf79..1559f57 100644 --- a/conf/layer.conf +++ b/conf/layer.conf @@ -10,7 +10,7 @@ BBFILE_PRIORITY_meta-openssl-one-zero-two-fips = "5" LAYERVERSION_meta-openssl-one-zero-two-fips = "1" -LAYERSERIES_COMPAT_meta-openssl-one-zero-two-fips = "zeus" +LAYERSERIES_COMPAT_meta-openssl-one-zero-two-fips = "zeus dunfell" LAYERPATH_meta-openssl-one-zero-two-fips = "${LAYERDIR}" -- 2.26.2 CONFIDENTIALITY NOTICE: This e-mail transmission and any documents, files or previous e-mail messages attached to it may contain information that is confidential, protected by the attorney/client or other privileges, and may constitute non-public information. It is intended to be conveyed only to the designated recipient(s) named above.
|
|
[PATCH] conf/layer.conf: Add dunfell to LAYERSERIES_COMPAT
Davis, Michael
Signed-off-by: Michael Davis <michael.davis@...>
--- conf/layer.conf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/conf/layer.conf b/conf/layer.conf index 892cf79..1559f57 100644 --- a/conf/layer.conf +++ b/conf/layer.conf @@ -10,7 +10,7 @@ BBFILE_PRIORITY_meta-openssl-one-zero-two-fips = "5" LAYERVERSION_meta-openssl-one-zero-two-fips = "1" -LAYERSERIES_COMPAT_meta-openssl-one-zero-two-fips = "zeus" +LAYERSERIES_COMPAT_meta-openssl-one-zero-two-fips = "zeus dunfell" LAYERPATH_meta-openssl-one-zero-two-fips = "${LAYERDIR}" -- 2.26.2 CONFIDENTIALITY NOTICE: This e-mail transmission and any documents, files or previous e-mail messages attached to it may contain information that is confidential, protected by the attorney/client or other privileges, and may constitute non-public information. It is intended to be conveyed only to the designated recipient(s) named above.
|
|
Re: [meta-gplv2] [PATCH] gnupg: Make it build with GCC 10 (which uses -fno-common by default)
Joshua Watt
On 10/5/20 3:36 PM, Peter Kjellerstedt wrote:
Any update on this?-----Original Message-----Interesting. I had not considered building the recipes from FWIW, I think with something this old it's probably best to keep the -fcommon behavior rather than try to patch around it.
|
|