Date   

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

Armin Kuster
 

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

Armin Kuster
 

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

Armin Kuster
 

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

Armin Kuster
 

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

Armin Kuster
 

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
I found: "Unit networking.service is masked."
So, I unmasked the service: $ systemctl unmask networking
Then started it:  $ systemctl start networking
Then, check 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 ago
     Docs: man:systemd-sysv-generator(8)
  Process: 736 ExecStart=/etc/init.d/networking start [[0;1;31m(code=exited, status=1/FAILURE)[[0m
May 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 exists
May 12 15:18:58 arria10 systemd[1]: [[0;1;39m[[0;1;31m[[0;1;39mnetworking.service: Control process exited, code=exited, status=1/FAILUR
E[[0m
May 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'.[[0m
May 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


Re: Yocto recipe for Tailscale #yocto #golang

Khem Raj
 


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:

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





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!


Re: Yocto recipe for Tailscale #yocto #golang

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


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

Any unauthorized use, reproduction, forwarding, distribution or other dissemination of this transmission is strictly prohibited and may be unlawful. If you are not an intended recipient of this email transmission, please notify the sender by return e-mail and permanently delete any record of this transmission. Your cooperation is appreciated. To find out more Click Here.


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

Any unauthorized use, reproduction, forwarding, distribution or other dissemination of this transmission is strictly prohibited and may be unlawful. If you are not an intended recipient of this email transmission, please notify the sender by return e-mail and permanently delete any record of this transmission. Your cooperation is appreciated. To find out more Click Here.


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

Any unauthorized use, reproduction, forwarding, distribution or other dissemination of this transmission is strictly prohibited and may be unlawful. If you are not an intended recipient of this email transmission, please notify the sender by return e-mail and permanently delete any record of this transmission. Your cooperation is appreciated. To find out more Click Here.


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

Any unauthorized use, reproduction, forwarding, distribution or other dissemination of this transmission is strictly prohibited and may be unlawful. If you are not an intended recipient of this email transmission, please notify the sender by return e-mail and permanently delete any record of this transmission. Your cooperation is appreciated. To find out more Click Here.


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:
-----Original Message-----
From: yocto@... <yocto@...> On
Behalf Of Joshua Watt
Sent: den 1 oktober 2020 15:27
To: Khem Raj <raj.khem@...>
Cc: Peter Kjellerstedt <peter.kjellerstedt@...>;
yocto@...
Subject: Re: [yocto] [meta-gplv2] [PATCH] gnupg: Make it build with GCC
10 (which uses -fno-common by default)

On Wed, Sep 30, 2020 at 4:34 PM Khem Raj <raj.khem@...> wrote:
On Wed, Sep 30, 2020 at 1:37 PM Joshua Watt <JPEWhacker@...>
wrote:
With this patch applied, I get the following errors when using the
latest master branches:

| ../mpi/libmpi.a(mpiutil.o): In function `mpi_alloc_limb_space':
| mpiutil.c:(.text+0x84): undefined reference to `memory_debug_mode'
| ../mpi/libmpi.a(mpiutil.o): In function `mpi_alloc':
| mpiutil.c:(.text+0xda): undefined reference to `memory_debug_mode'
| ../mpi/libmpi.a(mpiutil.o): In function `mpi_alloc_secure':
| mpiutil.c:(.text+0x14a): undefined reference to `memory_debug_mode'
| ../mpi/libmpi.a(mpiutil.o): In function `mpi_free_limb_space':
| mpiutil.c:(.text+0x1c7): undefined reference to `memory_debug_mode'
| ../mpi/libmpi.a(mpiutil.o): In function `mpi_free':
| mpiutil.c:(.text+0x267): undefined reference to `memory_debug_mode'
| ../util/libutil.a(iobuf.o): In function `file_filter':
| iobuf.c:(.text+0x1c0): undefined reference to `iobuf_debug_mode'
| iobuf.c:(.text+0x1ea): undefined reference to `iobuf_debug_mode'
| iobuf.c:(.text+0x2e0): undefined reference to `iobuf_debug_mode'
| iobuf.c:(.text+0x305): undefined reference to `iobuf_debug_mode'
| ../util/libutil.a(iobuf.o): In function `underflow':
| iobuf.c:(.text+0x4b3): undefined reference to `iobuf_debug_mode'
| ../util/libutil.a(iobuf.o):iobuf.c:(.text+0x567): more undefined
references to `iobuf_debug_mode' follow
| collect2: error: ld returned 1 exit status

If I revert this commit, gnupg-native will again build correctly. Any
ideas?
Interesting. I had not considered building the recipes from
meta-gplv2 for native as we only use them for target builds.

does it help if you add -fno-common to native CFLAGS
No. It works in all cases if I remove the patch and use "-fcommon"
though. Oddly enough, in my build having the patch caused the target
recipe to fail one way, and not having it caused it to fail another
way....
Are you saying you still have build failures when building gnupg for
target as well, with the patch applied?

not sure what's going on there, but I suspect for something
this old, adding "-fcommon" to restore the original behavior makes the
most sense.
Anyway, I get the same errors as above when I try building it for
native using gcc 9.3.1. I'll look into it and see if I can improve
the patch, or if I will have to resort to using -fcommon.
Any update on this?

FWIW, I think with something this old it's probably best to keep the -fcommon behavior rather than try to patch around it.



//Peter

6801 - 6820 of 57809