[PATCH v3 00/16] Complete backlog: SDK, compat arch, assorting fixed and cleanups

[PATCH v3 00/16] Complete backlog: SDK, compat arch, assorting fixed and cleanups

[Jan Kiszka]

Not all of the patches have dependencies, but let's make it simple and
push them all again at once.

Changes:
 - fix for false sharing when building generic packages from source
 - make isar-apt opt-in when building SDK
 - adjust cross-build documentation
 - switch back to hello-isar for testing compat-arch build
 - add an attempt to mitigate "gpg: can't connect to the agent"

That last patch is under observation here. I had multiple of such
failures in CI with the queue, none after it yet. But as the error is
sporadic, we do not know for sure if it truly helps.

Jan

Jan Kiszka (16):
  Split up isar-apt into distro-arch specific instances
  linux-custom: Clean up minor inconsistencies in rules.tmpl
  sshd-regen-keys: Issue sync after regeneration
  meta-isar: Drop outdated cross-compilation comment
  qemuamd64: Fix OVMF path
  sdk: Add support for adding self-defined sdk packages
  sdk: Make all links in the SDK chroot relative
  sdk: Add script to relocate SDK
  sdk: Make shipping the isar-apt repo opt-in
  sdk: Inject sysroot path when calling relocated toolchain
  sdk: Update README.sdk
  Add compat architecture support via multiarch
  ci: Add compat arch support
  doc: Enhance list of supported cross-archs, drop QEMU reference
  doc: Describe new compat arch support
  isar-bootstrap: Connect to gpg-agent before adding keys

 doc/user_manual.md                            | 26 +++++--
 meta-isar/conf/local.conf.sample              |  6 +-
 meta-isar/conf/machine/qemuamd64.conf         |  2 +-
 .../recipes-app/hello-isar/hello-isar.bb      |  3 +
 meta-isar/recipes-app/libhello/libhello.bb    |  3 +
 meta/classes/dpkg.bbclass                     |  8 ++-
 meta/classes/image-sdk-extension.bbclass      | 31 +++++++-
 meta/conf/bitbake.conf                        |  7 +-
 meta/conf/distro/debian-common.conf           |  3 +
 .../isar-bootstrap/isar-bootstrap.inc         | 18 ++++-
 .../buildchroot/buildchroot.inc               |  5 ++
 .../sdkchroot/files/README.sdk                | 71 ++++++++++---------
 .../sdkchroot/files/gcc-sysroot-wrapper.sh    | 16 +++++
 .../sdkchroot/files/relocate-sdk.sh           | 44 ++++++++++++
 meta/recipes-devtools/sdkchroot/sdkchroot.bb  | 34 ++++++---
 .../linux/files/debian/rules.tmpl             |  6 +-
 .../sshd-regen-keys/files/sshd-regen-keys.sh  |  2 +
 scripts/ci_build.sh                           |  6 ++
 18 files changed, 225 insertions(+), 66 deletions(-)
 create mode 100755 meta/recipes-devtools/sdkchroot/files/gcc-sysroot-wrapper.sh
 create mode 100755 meta/recipes-devtools/sdkchroot/files/relocate-sdk.sh

-- 
2.26.2

[PATCH v3 01/16] Split up isar-apt into distro-arch specific instances

[Jan Kiszka]

From: Jan Kiszka <jan.kiszka@siemens.com>

The split on a per-arch basis is required because bitbake cannot detect
that a generic package (architecture 'all') built by recipes running for
different architectures will produce the same results. The split also
per distro is for consistency reasons only.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 meta/conf/bitbake.conf | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index d2834f53..44ded532 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -77,8 +77,8 @@ QEMU_ARCH_riscv64 = "riscv64"
 DEBDISTRONAME ?= "isar"
 
 # Isar apt repository paths
-REPO_ISAR_DIR = "${DEPLOY_DIR}/isar-apt/apt"
-REPO_ISAR_DB_DIR = "${DEPLOY_DIR}/isar-apt/db"
+REPO_ISAR_DIR = "${DEPLOY_DIR}/isar-apt/${DISTRO}-${DISTRO_ARCH}/apt"
+REPO_ISAR_DB_DIR = "${DEPLOY_DIR}/isar-apt/${DISTRO}-${DISTRO_ARCH}/db"
 THIRD_PARTY_APT_KEYRING = "/etc/apt/trusted.gpg.d/third_party.gpg"
 
 # Base apt repository paths
-- 
2.26.2

[PATCH v3 02/16] linux-custom: Clean up minor inconsistencies in rules.tmpl

[Jan Kiszka]

From: Jan Kiszka <jan.kiszka@siemens.com>

.PHONY is not needed (and wasn't consistently used anyway). And that
missing && before the last export was apparently not critical as well.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 meta/recipes-kernel/linux/files/debian/rules.tmpl | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/meta/recipes-kernel/linux/files/debian/rules.tmpl b/meta/recipes-kernel/linux/files/debian/rules.tmpl
index 46b56ec5..05a26fe2 100755
--- a/meta/recipes-kernel/linux/files/debian/rules.tmpl
+++ b/meta/recipes-kernel/linux/files/debian/rules.tmpl
@@ -12,28 +12,24 @@ isar_env=$(strip \
 	export DEB_BUILD_PROFILES='$(DEB_BUILD_PROFILES)' && \
 	export DEB_HOST_GNU_TYPE='$(DEB_HOST_GNU_TYPE)' && \
 	export MAKE='$(MAKE)' && \
-	export O='${O}' \
+	export O='${O}' && \
 	export S='${S}' \
 )
 
 %:
 	dh $(@)
 
-.PHONY: override_dh_auto_clean
 override_dh_auto_clean:
 	$(isar_env) && bash $(deb_top_dir)/isar/clean
 
-.PHONY: override_dh_auto_build
 override_dh_auto_build:
 	$(isar_env) && bash $(deb_top_dir)/isar/build
 
 override_dh_auto_install:
 	$(isar_env) && bash $(deb_top_dir)/isar/install
 
-.PHONY: override_dh_auto_test
 override_dh_auto_test:
 	true
 
-PHONY: override_dh_strip
 override_dh_strip:
 	unset DEB_HOST_GNU_TYPE && dh_strip -Xvmlinu --no-automatic-dbgsym
-- 
2.26.2

[PATCH v3 03/16] sshd-regen-keys: Issue sync after regeneration

[Jan Kiszka]

From: Jan Kiszka <jan.kiszka@siemens.com>

This reduces the risk that a hard reset or power loss after the
regeneration leaves invalid key files behind, thus prevents that sshd
comes up again.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 meta/recipes-support/sshd-regen-keys/files/sshd-regen-keys.sh | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-support/sshd-regen-keys/files/sshd-regen-keys.sh b/meta/recipes-support/sshd-regen-keys/files/sshd-regen-keys.sh
index 11fca3b4..910d879b 100644
--- a/meta/recipes-support/sshd-regen-keys/files/sshd-regen-keys.sh
+++ b/meta/recipes-support/sshd-regen-keys/files/sshd-regen-keys.sh
@@ -16,3 +16,5 @@ if test -n $SSHD_ENABLED; then
     echo "Reenabling ssh server ..."
     systemctl enable --no-reload ssh
 fi
+
+sync
-- 
2.26.2

[PATCH v3 04/16] meta-isar: Drop outdated cross-compilation comment

[Jan Kiszka]

From: Jan Kiszka <jan.kiszka@siemens.com>

We only support >= stretch, and all archs can do cross-building by now.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 meta-isar/conf/local.conf.sample | 1 -
 1 file changed, 1 deletion(-)

diff --git a/meta-isar/conf/local.conf.sample b/meta-isar/conf/local.conf.sample
index 274cdaea..e842c129 100644
--- a/meta-isar/conf/local.conf.sample
+++ b/meta-isar/conf/local.conf.sample
@@ -173,7 +173,6 @@ IMAGE_INSTALL = "hello-isar example-raw example-module-${KERNEL_NAME} enable-fsc
 
 #
 # Enable cross-compilation support
-# NOTE: this works on build host >= stretch for armhf, arm64 and amd64 targets for now.
 ISAR_CROSS_COMPILE ?= "0"
 
 #
-- 
2.26.2

[PATCH v3 05/16] qemuamd64: Fix OVMF path

[Jan Kiszka]

From: Jan Kiszka <jan.kiszka@siemens.com>

start_vm does not work for amd64 when trying to use a standard Debian
installation of ovmf. Fix this.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 meta-isar/conf/machine/qemuamd64.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-isar/conf/machine/qemuamd64.conf b/meta-isar/conf/machine/qemuamd64.conf
index 028b738d..29fc579e 100644
--- a/meta-isar/conf/machine/qemuamd64.conf
+++ b/meta-isar/conf/machine/qemuamd64.conf
@@ -14,7 +14,7 @@ IMAGE_INSTALL += "sshd-regen-keys"
 QEMU_ARCH ?= "x86_64"
 QEMU_MACHINE ?= "q35"
 QEMU_CPU ?= ""
-QEMU_DISK_ARGS ?= "-hda ##ROOTFS_IMAGE## -bios /usr/local/share/ovmf/OVMF.fd"
+QEMU_DISK_ARGS ?= "-hda ##ROOTFS_IMAGE## -bios /usr/share/ovmf/OVMF.fd"
 
 MACHINE_SERIAL ?= "ttyS0"
 BAUDRATE_TTY ?= "115200"
-- 
2.26.2

[PATCH v3 06/16] sdk: Add support for adding self-defined sdk packages

[Jan Kiszka]

From: Jan Kiszka <jan.kiszka@siemens.com>

We do not yet have a good algorithm for automatically adding build
dependencies to the sdk beyond the basic set, let's allow users to
append what they need by appending SDK_PREINSTALL. Analogously to other
images, also allow to install self-built packages, consequently using
SDK_INSTALL.

Based on original patch by Le Jin.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 doc/user_manual.md                           |  1 +
 meta/recipes-devtools/sdkchroot/sdkchroot.bb | 25 ++++++++++++--------
 2 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/doc/user_manual.md b/doc/user_manual.md
index d13a74e9..fb6574bb 100644
--- a/doc/user_manual.md
+++ b/doc/user_manual.md
@@ -744,6 +744,7 @@ target binary artifacts. Developer chroots to sdk rootfs and develops applicatio
 
 User manually triggers creation of SDK root filesystem for his target platform by launching the task `do_populate_sdk` for target image, f.e.
 `bitbake -c do_populate_sdk mc:${MACHINE}-${DISTRO}:isar-image-base`.
+Packages that should be additionally installed into the SDK can be appended to `SDK_PREINSTALL` (external repositories) and `SDK_INSTALL` (self-built).
 
 The resulting SDK rootfs is archived into `tmp/deploy/images/${MACHINE}/sdk-${DISTRO}-${DISTRO_ARCH}.tar.xz`.
 It is additionally available for direct use under `tmp/deploy/images/${MACHINE}/sdk-${DISTRO}-${DISTRO_ARCH}/`.
diff --git a/meta/recipes-devtools/sdkchroot/sdkchroot.bb b/meta/recipes-devtools/sdkchroot/sdkchroot.bb
index 467e6824..ab0a66dc 100644
--- a/meta/recipes-devtools/sdkchroot/sdkchroot.bb
+++ b/meta/recipes-devtools/sdkchroot/sdkchroot.bb
@@ -13,6 +13,10 @@ SRC_URI = " \
     file://README.sdk"
 PV = "0.1"
 
+SDK_INSTALL ?= ""
+
+DEPENDS += "${SDK_INSTALL}"
+
 TOOLCHAIN = "crossbuild-essential-${DISTRO_ARCH}"
 TOOLCHAIN_${HOST_ARCH} = "build-essential"
 TOOLCHAIN_i386 = "build-essential"
@@ -21,7 +25,7 @@ inherit rootfs
 ROOTFS_ARCH = "${HOST_ARCH}"
 ROOTFS_DISTRO = "${HOST_DISTRO}"
 ROOTFSDIR = "${S}"
-ROOTFS_PACKAGES = "${SDKCHROOT_PREINSTALL} ${TOOLCHAIN}"
+ROOTFS_PACKAGES = "${SDK_PREINSTALL} ${SDK_INSTALL} ${TOOLCHAIN}"
 ROOTFS_FEATURES += "clean-package-cache generate-manifest"
 ROOTFS_MANIFEST_DEPLOY_DIR = "${DEPLOY_DIR_SDKCHROOT}"
 
@@ -31,15 +35,16 @@ python() {
             d.getVar("ROOTFS_ARCH")))
 }
 
-SDKCHROOT_PREINSTALL := "debhelper \
-                           autotools-dev \
-                           dpkg \
-                           locales \
-                           docbook-to-man \
-                           apt \
-                           automake \
-                           devscripts \
-                           equivs"
+SDK_PREINSTALL += " \
+    debhelper \
+    autotools-dev \
+    dpkg \
+    locales \
+    docbook-to-man \
+    apt \
+    automake \
+    devscripts \
+    equivs"
 
 S = "${WORKDIR}/rootfs"
 
-- 
2.26.2

[PATCH v3 07/16] sdk: Make all links in the SDK chroot relative

[Jan Kiszka]

From: Jan Kiszka <jan.kiszka@siemens.com>

This, in combination with interp and rpatch rewriting, will allow to use
the SDK outside of its chroot.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 meta/classes/image-sdk-extension.bbclass | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/meta/classes/image-sdk-extension.bbclass b/meta/classes/image-sdk-extension.bbclass
index b9f2cf4a..84ac9c6d 100644
--- a/meta/classes/image-sdk-extension.bbclass
+++ b/meta/classes/image-sdk-extension.bbclass
@@ -18,6 +18,20 @@ do_populate_sdk() {
     # Remove setup scripts
     sudo rm -f ${SDKCHROOT_DIR}/chroot-setup.sh ${SDKCHROOT_DIR}/configscript.sh
 
+    # Make all links relative
+    for link in $(find ${SDKCHROOT_DIR}/ -type l); do
+        target=$(readlink $link)
+
+        if [ "${target#/}" != "${target}" ]; then
+            basedir=$(dirname $link)
+            new_target=$(realpath --no-symlinks -m --relative-to=$basedir ${SDKCHROOT_DIR}/${target})
+
+            # remove first to allow rewriting directory links
+            sudo rm $link
+            sudo ln -s $new_target $link
+        fi
+    done
+
     # Copy mount_chroot.sh for convenience
     sudo cp ${ISARROOT}/scripts/mount_chroot.sh ${SDKCHROOT_DIR}
 
-- 
2.26.2

[PATCH v3 08/16] sdk: Add script to relocate SDK

[Jan Kiszka]

From: Jan Kiszka <jan.kiszka@siemens.com>

When run inside the unpacked SDK, this script tunes interp and rpath
entry in relevant binaries so that the cross conpilation tool can be
called outside of the chroot, irrespective of the host distribution.
Then only "--sysroot /path/to/sdkroot" needs to be passed to the
compiler.

The script also supports restoring the original chroot-mode when invoked
with the --restore-chroot option.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 .../sdkchroot/files/relocate-sdk.sh           | 41 +++++++++++++++++++
 meta/recipes-devtools/sdkchroot/sdkchroot.bb  |  2 +
 2 files changed, 43 insertions(+)
 create mode 100755 meta/recipes-devtools/sdkchroot/files/relocate-sdk.sh

diff --git a/meta/recipes-devtools/sdkchroot/files/relocate-sdk.sh b/meta/recipes-devtools/sdkchroot/files/relocate-sdk.sh
new file mode 100755
index 00000000..1c9b02fa
--- /dev/null
+++ b/meta/recipes-devtools/sdkchroot/files/relocate-sdk.sh
@@ -0,0 +1,41 @@
+#!/bin/sh
+#
+# This software is a part of ISAR.
+# Copyright (c) Siemens AG, 2020
+#
+# SPDX-License-Identifier: MIT
+
+sdkroot=$(realpath $(dirname $0))
+arch=$(uname -m)
+
+new_sdkroot=$sdkroot
+
+case "$1" in
+--help|-h)
+	echo "Usage: $0 [--restore-chroot|-r]"
+	exit 0
+	;;
+--restore-chroot|-r)
+	new_sdkroot=/
+	;;
+esac
+
+if [ -z $(which patchelf 2>/dev/null) ]; then
+	echo "Please install 'patchelf' package first."
+	exit 1
+fi
+
+echo -n "Adjusting path of SDK to '${new_sdkroot}'... "
+
+for binary in $(find ${sdkroot}/usr/bin ${sdkroot}/usr/sbin ${sdkroot}/usr/lib/gcc* -executable -type f); do
+	interpreter=$(patchelf --print-interpreter ${binary} 2>/dev/null)
+	oldpath=${interpreter%/lib*/ld-linux*}
+	interpreter=${interpreter#${oldpath}}
+	if [ -n "${interpreter}" ]; then
+		patchelf --set-interpreter ${new_sdkroot}${interpreter} \
+			--set-rpath ${new_sdkroot}/usr/lib:${new_sdkroot}/usr/lib/${arch}-linux-gnu \
+			$binary 2>/dev/null
+	fi
+done
+
+echo "done"
diff --git a/meta/recipes-devtools/sdkchroot/sdkchroot.bb b/meta/recipes-devtools/sdkchroot/sdkchroot.bb
index ab0a66dc..2bc9d291 100644
--- a/meta/recipes-devtools/sdkchroot/sdkchroot.bb
+++ b/meta/recipes-devtools/sdkchroot/sdkchroot.bb
@@ -10,6 +10,7 @@ LIC_FILES_CHKSUM = "file://${LAYERDIR_core}/licenses/COPYING.GPLv2;md5=751419260
 
 SRC_URI = " \
     file://configscript.sh \
+    file://relocate-sdk.sh \
     file://README.sdk"
 PV = "0.1"
 
@@ -58,6 +59,7 @@ ROOTFS_POSTPROCESS_COMMAND =+ "sdkchroot_install_files"
 sdkchroot_install_files() {
     # Configure root filesystem
     sudo install -m 644 ${WORKDIR}/README.sdk ${S}
+    sudo install -m 755 ${WORKDIR}/relocate-sdk.sh ${S}
     sudo install -m 755 ${WORKDIR}/configscript.sh ${S}
     sudo chroot ${S} /configscript.sh  ${DISTRO_ARCH}
 }
-- 
2.26.2

[PATCH v3 09/16] sdk: Make shipping the isar-apt repo opt-in

[Jan Kiszka]

From: Jan Kiszka <jan.kiszka@siemens.com>

Users can add what should be included via SDK_INSTALL now, so this
should be the exception. Keep it around until we decide if we can drop
it completely.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 meta/classes/image-sdk-extension.bbclass     | 9 +++++++--
 meta/recipes-devtools/sdkchroot/sdkchroot.bb | 4 +++-
 2 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/meta/classes/image-sdk-extension.bbclass b/meta/classes/image-sdk-extension.bbclass
index 84ac9c6d..07a53410 100644
--- a/meta/classes/image-sdk-extension.bbclass
+++ b/meta/classes/image-sdk-extension.bbclass
@@ -8,8 +8,13 @@
 do_populate_sdk[stamp-extra-info] = "${DISTRO}-${MACHINE}"
 do_populate_sdk[depends] = "sdkchroot:do_build"
 do_populate_sdk() {
-    # Copy isar-apt with deployed Isar packages
-    sudo cp -Trpfx ${REPO_ISAR_DIR}/${DISTRO}  ${SDKCHROOT_DIR}/isar-apt
+    if [ "${SDK_INCLUDE_ISAR_APT}" == "1" ]; then
+        # Copy isar-apt with deployed Isar packages
+        sudo cp -Trpfx ${REPO_ISAR_DIR}/${DISTRO}  ${SDKCHROOT_DIR}/isar-apt
+    else
+        # Remove isar-apt repo entry
+        sudo rm -f ${SDKCHROOT_DIR}/etc/apt/sources.list.d/isar-apt.list
+    fi
 
     sudo umount -R ${SDKCHROOT_DIR}/dev || true
     sudo umount ${SDKCHROOT_DIR}/proc || true
diff --git a/meta/recipes-devtools/sdkchroot/sdkchroot.bb b/meta/recipes-devtools/sdkchroot/sdkchroot.bb
index 2bc9d291..e5d44e73 100644
--- a/meta/recipes-devtools/sdkchroot/sdkchroot.bb
+++ b/meta/recipes-devtools/sdkchroot/sdkchroot.bb
@@ -47,9 +47,11 @@ SDK_PREINSTALL += " \
     devscripts \
     equivs"
 
+SDK_INCLUDE_ISAR_APT ?= "0"
+
 S = "${WORKDIR}/rootfs"
 
-ROOTFS_CONFIGURE_COMMAND += "rootfs_configure_isar_apt_dir"
+ROOTFS_CONFIGURE_COMMAND += "${@'rootfs_configure_isar_apt_dir' if d.getVar('SDK_INCLUDE_ISAR_APT') == '1' else ''}"
 rootfs_configure_isar_apt_dir() {
     # Copy isar-apt instead of mounting:
     sudo cp -Trpfx ${REPO_ISAR_DIR}/${DISTRO} ${ROOTFSDIR}/isar-apt
-- 
2.26.2

[PATCH v3 10/16] sdk: Inject sysroot path when calling relocated toolchain

[Jan Kiszka]

From: Jan Kiszka <jan.kiszka@siemens.com>

This removes the need to specify --sysroot=/path/to/sdkroot when calling
gcc or ld from the SDK.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 meta/classes/image-sdk-extension.bbclass         |  8 ++++++++
 .../sdkchroot/files/gcc-sysroot-wrapper.sh       | 16 ++++++++++++++++
 .../sdkchroot/files/relocate-sdk.sh              |  3 +++
 meta/recipes-devtools/sdkchroot/sdkchroot.bb     |  2 ++
 4 files changed, 29 insertions(+)
 create mode 100755 meta/recipes-devtools/sdkchroot/files/gcc-sysroot-wrapper.sh

diff --git a/meta/classes/image-sdk-extension.bbclass b/meta/classes/image-sdk-extension.bbclass
index 07a53410..59d16cd0 100644
--- a/meta/classes/image-sdk-extension.bbclass
+++ b/meta/classes/image-sdk-extension.bbclass
@@ -37,6 +37,14 @@ do_populate_sdk() {
         fi
     done
 
+    # Set up sysroot wrapper
+    for tool_pattern in "gcc-[0-9]*" "g++-[0-9]*" "cpp-[0-9]*" "ld.bfd" "ld.gold"; do
+        for tool in $(find ${SDKCHROOT_DIR}/usr/bin -type f -name "*-linux-gnu*-${tool_pattern}"); do
+            sudo mv "${tool}" "${tool}.bin"
+            sudo ln -sf gcc-sysroot-wrapper.sh ${tool}
+        done
+    done
+
     # Copy mount_chroot.sh for convenience
     sudo cp ${ISARROOT}/scripts/mount_chroot.sh ${SDKCHROOT_DIR}
 
diff --git a/meta/recipes-devtools/sdkchroot/files/gcc-sysroot-wrapper.sh b/meta/recipes-devtools/sdkchroot/files/gcc-sysroot-wrapper.sh
new file mode 100755
index 00000000..feead1a1
--- /dev/null
+++ b/meta/recipes-devtools/sdkchroot/files/gcc-sysroot-wrapper.sh
@@ -0,0 +1,16 @@
+#!/bin/sh
+#
+# This software is a part of ISAR.
+# Copyright (c) Siemens AG, 2020
+#
+# SPDX-License-Identifier: MIT
+
+GCC_SYSROOT=
+
+NEXT_TARGET=$0
+until [ "${NEXT_TARGET##*/}" = "gcc-sysroot-wrapper.sh" ]; do
+	TARGET=${NEXT_TARGET}
+	NEXT_TARGET=$(dirname ${TARGET})/$(readlink ${TARGET})
+done
+
+${TARGET}.bin --sysroot=${GCC_SYSROOT} "$@"
diff --git a/meta/recipes-devtools/sdkchroot/files/relocate-sdk.sh b/meta/recipes-devtools/sdkchroot/files/relocate-sdk.sh
index 1c9b02fa..0d1c6330 100755
--- a/meta/recipes-devtools/sdkchroot/files/relocate-sdk.sh
+++ b/meta/recipes-devtools/sdkchroot/files/relocate-sdk.sh
@@ -38,4 +38,7 @@ for binary in $(find ${sdkroot}/usr/bin ${sdkroot}/usr/sbin ${sdkroot}/usr/lib/g
 	fi
 done
 
+sed -i 's|^GCC_SYSROOT=.*|GCC_SYSROOT="'"${new_sdkroot}"'"|' \
+    ${sdkroot}/usr/bin/gcc-sysroot-wrapper.sh
+
 echo "done"
diff --git a/meta/recipes-devtools/sdkchroot/sdkchroot.bb b/meta/recipes-devtools/sdkchroot/sdkchroot.bb
index e5d44e73..82b430b3 100644
--- a/meta/recipes-devtools/sdkchroot/sdkchroot.bb
+++ b/meta/recipes-devtools/sdkchroot/sdkchroot.bb
@@ -11,6 +11,7 @@ LIC_FILES_CHKSUM = "file://${LAYERDIR_core}/licenses/COPYING.GPLv2;md5=751419260
 SRC_URI = " \
     file://configscript.sh \
     file://relocate-sdk.sh \
+    file://gcc-sysroot-wrapper.sh \
     file://README.sdk"
 PV = "0.1"
 
@@ -62,6 +63,7 @@ sdkchroot_install_files() {
     # Configure root filesystem
     sudo install -m 644 ${WORKDIR}/README.sdk ${S}
     sudo install -m 755 ${WORKDIR}/relocate-sdk.sh ${S}
+    sudo install -m 755 ${WORKDIR}/gcc-sysroot-wrapper.sh ${S}/usr/bin
     sudo install -m 755 ${WORKDIR}/configscript.sh ${S}
     sudo chroot ${S} /configscript.sh  ${DISTRO_ARCH}
 }
-- 
2.26.2

[PATCH v3 11/16] sdk: Update README.sdk

[Jan Kiszka]

From: Jan Kiszka <jan.kiszka@siemens.com>

Document the out-of-chroot invocation and make it the preferred option.
Also remove irrelevant information.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 .../sdkchroot/files/README.sdk                | 71 ++++++++++---------
 1 file changed, 36 insertions(+), 35 deletions(-)

diff --git a/meta/recipes-devtools/sdkchroot/files/README.sdk b/meta/recipes-devtools/sdkchroot/files/README.sdk
index 9c1af6d3..3e06d8c5 100644
--- a/meta/recipes-devtools/sdkchroot/files/README.sdk
+++ b/meta/recipes-devtools/sdkchroot/files/README.sdk
@@ -1,42 +1,43 @@
-Building applications for targets in ISAR takes a lot of time as they are built under QEMU.
-SDK helps to develop applications for target platform in crossbuild environment.
+ISAR Target SDK
+===============
 
-SDK contains cross-toolchain for target architecture and a copy of isar-apt repo with
-locally prebuilt target debian packages.
+This SDK helps to develop applications for an ISAR target platform in a
+crossbuild environment. It contains a cross-toolchain and development packages
+corresponding to the original target.
 
- - First one have to mount the system directories for proper operation in chroot environement.
-Just call supplied with sdk tarball  in  udo rootfs as an argument to the script `mount_chroot.sh`:
+The SDK can be used in two ways, described in the following.
 
-$ sudo mount_chroot.sh  <sdk_rootfs>
 
- - chroot to isar SDK rootfs:
+Option 1 (recommended): Use cross-compiler in host environment
+--------------------------------------------------------------
+
+After unpacking the SDK at the desired location, it has to be relocated once:
+
+$ <sdk_rootfs>/relocate-sdk.sh
+
+Now you can add <sdk_rootfs>/usr/bin to the local path or adjust your project
+to call the cross-compiler from the SDK.
+
+
+Option 2 (fallback): Build inside chroot
+----------------------------------------
+
+First you have to mount the system directories for proper operation into the
+chroot environment. Call the helper script supplied with SDK tarball:
+
+$ sudo <sdk_rootfs>/mount_chroot.sh <sdk_rootfs>
+
+Bind-mount the project into the rootfs:
+
+$ sudo mount -o bind /path/to/project <sdk_rootfs>/mnt
+
+If you have relocated the SDK previously for using option 1, you need to call
+this next:
+
+$ <sdk_rootfs>/relocate-sdk.sh --restore-chroot
+
+Then chroot into the SDK rootfs:
 
 $ sudo chroot <sdk_rootfs>
 
- - Check that cross toolchains are installed
-
-:~# dpkg -l | grep crossbuild-essential-armhf
-ii  crossbuild-essential-armhf           12.3                   all          Informational list of cross-build-essential packages
-
- - Install needed prebuilt target packages.
-
-:~# apt-get update
-:~# apt-get install libhello-dev:armhf
-
- - Check the contents of the installed target package
-
-:~# dpkg -L libhello-dev
-/.
-/usr
-/usr/include
-/usr/include/hello.h
-/usr/lib
-/usr/lib/arm-linux-gnueabihf
-/usr/lib/arm-linux-gnueabihf/libhello.a
-/usr/lib/arm-linux-gnueabihf/libhello.la
-/usr/share
-/usr/share/doc
-/usr/share/doc/libhello-dev
-/usr/share/doc/libhello-dev/changelog.gz
-/usr/share/doc/libhello-dev/copyright
-~#
+Now you can build the project under /mnt.
-- 
2.26.2

[PATCH v3 12/16] Add compat architecture support via multiarch

[Jan Kiszka]

From: Jan Kiszka <jan.kiszka@siemens.com>

Allow building and installing 32-bit packages an 64-bit architectures
that support this. Namely, these are amd64 and arm64 for us so far,
minus stretch-amd64 which lacks crossbuild-essential-i386 in that
version.

Control the target architecture of a package is added via the
PACKAGE_ARCH variable that defaults to DISTRO_ARCH. When set to
COMPAT_DISTRO_ARCH, the package is built for i386 on amd64 and armhf on
arm64.

If the build environment and the target image should contain the compat
arch is controlled via setting ISAR_ENABLE_COMPAT_ARCH to 1.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 meta-isar/conf/local.conf.sample                   |  5 +++++
 meta/classes/dpkg.bbclass                          |  8 +++++---
 meta/conf/bitbake.conf                             |  3 ++-
 meta/conf/distro/debian-common.conf                |  3 +++
 .../recipes-core/isar-bootstrap/isar-bootstrap.inc | 14 +++++++++++++-
 meta/recipes-devtools/buildchroot/buildchroot.inc  |  5 +++++
 meta/recipes-devtools/sdkchroot/sdkchroot.bb       |  1 +
 7 files changed, 34 insertions(+), 5 deletions(-)

diff --git a/meta-isar/conf/local.conf.sample b/meta-isar/conf/local.conf.sample
index e842c129..2f82020d 100644
--- a/meta-isar/conf/local.conf.sample
+++ b/meta-isar/conf/local.conf.sample
@@ -175,6 +175,11 @@ IMAGE_INSTALL = "hello-isar example-raw example-module-${KERNEL_NAME} enable-fsc
 # Enable cross-compilation support
 ISAR_CROSS_COMPILE ?= "0"
 
+#
+# Uncomment to enable 32-bit compat architecture support
+# NOTE: this works for amd64 and arm64 targets so far
+#ISAR_ENABLE_COMPAT_ARCH ?= "1"
+
 #
 # Uncomment this to enable use of cached base repository
 #ISAR_USE_CACHED_BASE_REPO ?= "1"
diff --git a/meta/classes/dpkg.bbclass b/meta/classes/dpkg.bbclass
index acccc1f2..a24386df 100644
--- a/meta/classes/dpkg.bbclass
+++ b/meta/classes/dpkg.bbclass
@@ -3,16 +3,18 @@
 
 inherit dpkg-base
 
+PACKAGE_ARCH ?= "${DISTRO_ARCH}"
+
 # Install build dependencies for package
 do_install_builddeps() {
     dpkg_do_mounts
     E="${@ isar_export_proxies(d)}"
     deb_dl_dir_import "${BUILDCHROOT_DIR}"
     sudo -E chroot ${BUILDCHROOT_DIR} /isar/deps.sh \
-        ${PP}/${PPS} ${DISTRO_ARCH} --download-only
+        ${PP}/${PPS} ${PACKAGE_ARCH} --download-only
     deb_dl_dir_export "${BUILDCHROOT_DIR}"
     sudo -E chroot ${BUILDCHROOT_DIR} /isar/deps.sh \
-        ${PP}/${PPS} ${DISTRO_ARCH}
+        ${PP}/${PPS} ${PACKAGE_ARCH}
     dpkg_undo_mounts
 }
 
@@ -27,5 +29,5 @@ dpkg_runbuild() {
     E="${@ isar_export_proxies(d)}"
     export PARALLEL_MAKE="${PARALLEL_MAKE}"
     sudo -E chroot --userspec=$( id -u ):$( id -g ) ${BUILDCHROOT_DIR} \
-         /isar/build.sh ${PP}/${PPS} ${DISTRO_ARCH}
+         /isar/build.sh ${PP}/${PPS} ${PACKAGE_ARCH}
 }
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 44ded532..a3e2af2c 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -62,8 +62,9 @@ KERNEL_FILE ?= "vmlinuz"
 KERNEL_FILE_mipsel ?= "vmlinux"
 KERNEL_FILE_riscv64 ?= "vmlinux"
 
-OVERRIDES = "${DISTRO_ARCH}:${MACHINE}:${DISTRO}:forcevariable"
+OVERRIDES = "${DISTRO_ARCH}:${COMPAT_OVERRIDE}:${MACHINE}:${DISTRO}:forcevariable"
 FILESOVERRIDES = "${DISTRO_ARCH}:${MACHINE}"
+COMPAT_OVERRIDE = "${@'compat-arch' if d.getVar('ISAR_ENABLE_COMPAT_ARCH') == '1' else ''}"
 
 # Setting default QEMU_ARCH variables for different DISTRO_ARCH:
 QEMU_ARCH_amd64 = "x86_64"
diff --git a/meta/conf/distro/debian-common.conf b/meta/conf/distro/debian-common.conf
index 7d681c49..582678f6 100644
--- a/meta/conf/distro/debian-common.conf
+++ b/meta/conf/distro/debian-common.conf
@@ -22,3 +22,6 @@ GRUB_BOOTLOADER_INSTALL_armhf = "grub-efi-arm-bin"
 GRUB_BOOTLOADER_INSTALL_arm64 = "grub-efi-arm64-bin"
 
 SYSLINUX_BOOTLOADER_INSTALL = "syslinux syslinux-common"
+
+COMPAT_DISTRO_ARCH_amd64 = "i386"
+COMPAT_DISTRO_ARCH_arm64 = "armhf"
diff --git a/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc b/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc
index da0d436b..fbfe669d 100644
--- a/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc
+++ b/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc
@@ -222,7 +222,7 @@ def get_host_release():
     rel = platform.release()
     return rel
 
-do_bootstrap[vardeps] += "DISTRO_APT_PREMIRRORS"
+do_bootstrap[vardeps] += "DISTRO_APT_PREMIRRORS ISAR_ENABLE_COMPAT_ARCH"
 do_bootstrap[dirs] = "${DEPLOY_DIR_BOOTSTRAP}"
 do_bootstrap[depends] = "base-apt:do_cache"
 
@@ -236,6 +236,14 @@ isar_bootstrap() {
         esac
         shift
     done
+    if [ "${ISAR_ENABLE_COMPAT_ARCH}" = "1" ]; then
+        if [ -z "${COMPAT_DISTRO_ARCH}" ]; then
+            bbfatal "${DISTRO_ARCH} does not have a compat arch"
+        fi
+        if [ "${@get_distro_suite(d, True)}-${COMPAT_DISTRO_ARCH}" = "stretch-i386" ]; then
+            bbfatal "compat arch build for stretch-i386 not supported"
+        fi
+    fi
     debootstrap_args="--verbose --variant=minbase --include=${DISTRO_BOOTSTRAP_BASE_PACKAGES}"
     if [ -f "${DISTRO_BOOTSTRAP_KEYRING}" ]; then
         debootstrap_args="$debootstrap_args --keyring=${DISTRO_BOOTSTRAP_KEYRING}"
@@ -330,6 +338,10 @@ isar_bootstrap() {
                 chroot "${ROOTFSDIR}" /usr/bin/dpkg --add-architecture ${DISTRO_ARCH}
             fi
 
+            if [ "${ISAR_ENABLE_COMPAT_ARCH}" = "1" ]; then
+                chroot "${ROOTFSDIR}" /usr/bin/dpkg --add-architecture ${COMPAT_DISTRO_ARCH}
+            fi
+
             chroot "${ROOTFSDIR}" /usr/bin/apt-get update -y
             chroot "${ROOTFSDIR}" /usr/bin/apt-get install -y -f
             chroot "${ROOTFSDIR}" /usr/bin/apt-get dist-upgrade -y \
diff --git a/meta/recipes-devtools/buildchroot/buildchroot.inc b/meta/recipes-devtools/buildchroot/buildchroot.inc
index b4d7b764..835968de 100644
--- a/meta/recipes-devtools/buildchroot/buildchroot.inc
+++ b/meta/recipes-devtools/buildchroot/buildchroot.inc
@@ -22,7 +22,12 @@ ROOTFS_CLEAN_FILES = ""
 ROOTFS_MANIFEST_DEPLOY_DIR = "${DEPLOY_DIR_BUILDCHROOT}"
 ROOTFS_FEATURES += "generate-manifest"
 
+BUILDCHROOT_COMPAT_PREINSTALL_compat-arch = " \
+    libc6:${COMPAT_DISTRO_ARCH} \
+    crossbuild-essential-${COMPAT_DISTRO_ARCH}"
+
 BUILDCHROOT_PREINSTALL_COMMON = " \
+    ${BUILDCHROOT_COMPAT_PREINSTALL} \
     make \
     debhelper \
     autotools-dev \
diff --git a/meta/recipes-devtools/sdkchroot/sdkchroot.bb b/meta/recipes-devtools/sdkchroot/sdkchroot.bb
index 82b430b3..c96cc772 100644
--- a/meta/recipes-devtools/sdkchroot/sdkchroot.bb
+++ b/meta/recipes-devtools/sdkchroot/sdkchroot.bb
@@ -22,6 +22,7 @@ DEPENDS += "${SDK_INSTALL}"
 TOOLCHAIN = "crossbuild-essential-${DISTRO_ARCH}"
 TOOLCHAIN_${HOST_ARCH} = "build-essential"
 TOOLCHAIN_i386 = "build-essential"
+TOOLCHAIN_append_compat-arch = " crossbuild-essential-${COMPAT_DISTRO_ARCH}"
 
 inherit rootfs
 ROOTFS_ARCH = "${HOST_ARCH}"
-- 
2.26.2

[PATCH v3 13/16] ci: Add compat arch support

[Jan Kiszka]

From: Jan Kiszka <jan.kiszka@siemens.com>

Build hello-isar and libisar for the compat arch if that is enabled.
Set ISAR_ENABLE_COMPAT_ARCH for all supported combinations in CI.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 meta-isar/recipes-app/hello-isar/hello-isar.bb | 3 +++
 meta-isar/recipes-app/libhello/libhello.bb     | 3 +++
 scripts/ci_build.sh                            | 6 ++++++
 3 files changed, 12 insertions(+)

diff --git a/meta-isar/recipes-app/hello-isar/hello-isar.bb b/meta-isar/recipes-app/hello-isar/hello-isar.bb
index 144a433e..8c3ba8b2 100644
--- a/meta-isar/recipes-app/hello-isar/hello-isar.bb
+++ b/meta-isar/recipes-app/hello-isar/hello-isar.bb
@@ -20,4 +20,7 @@ SRC_URI = " \
     file://yet-another-change.txt;apply=yes;striplevel=0"
 SRCREV = "a18c14cc11ce6b003f3469e89223cffb4016861d"
 
+# NOTE: This is just to test 32-bit building on 64-bit archs.
+PACKAGE_ARCH_compat-arch = "${COMPAT_DISTRO_ARCH}"
+
 inherit dpkg
diff --git a/meta-isar/recipes-app/libhello/libhello.bb b/meta-isar/recipes-app/libhello/libhello.bb
index ab271b58..5c44de50 100644
--- a/meta-isar/recipes-app/libhello/libhello.bb
+++ b/meta-isar/recipes-app/libhello/libhello.bb
@@ -13,4 +13,7 @@ PV = "0.1-98f2e41"
 SRC_URI = "git://github.com/ilbers/libhello.git;protocol=https;destsuffix=${P}"
 SRCREV = "98f2e41e7d05ab8d19b0c5d160b104b725c8fd93"
 
+# NOTE: This is just to test 32-bit building on 64-bit archs.
+PACKAGE_ARCH_compat-arch = "${COMPAT_DISTRO_ARCH}"
+
 inherit dpkg
diff --git a/scripts/ci_build.sh b/scripts/ci_build.sh
index af996d19..a5eee82b 100755
--- a/scripts/ci_build.sh
+++ b/scripts/ci_build.sh
@@ -139,6 +139,12 @@ if [ ! -d "$BUILD_DIR" ]; then
 fi
 source isar-init-build-env "$BUILD_DIR"
 
+cat >>conf/local.conf <<EOF
+ISAR_ENABLE_COMPAT_ARCH_amd64 = "1"
+ISAR_ENABLE_COMPAT_ARCH_arm64 = "1"
+ISAR_ENABLE_COMPAT_ARCH_debian-stretch_amd64 = "0"
+EOF
+
 if [ -n "$CROSS_BUILD" ]; then
     sed -i -e 's/ISAR_CROSS_COMPILE ?= "0"/ISAR_CROSS_COMPILE ?= "1"/g' conf/local.conf
 fi
-- 
2.26.2

[PATCH v3 14/16] doc: Enhance list of supported cross-archs, drop QEMU reference

[Jan Kiszka]

From: Jan Kiszka <jan.kiszka@siemens.com>

We also test mipsel in cross-builds. RISC-V 64-bit is available but
experimental.

Furthermore, remove the reference to qemu because Isar also supports
building cross for physical targets. This might be confusing.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 doc/user_manual.md | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/doc/user_manual.md b/doc/user_manual.md
index fb6574bb..5c3996d7 100644
--- a/doc/user_manual.md
+++ b/doc/user_manual.md
@@ -714,10 +714,14 @@ put into Isar apt.
 
 Debian cross-compilation works out of the box starting from Debian stretch distribution. Currently the following build configurations are supported in Isar:
 
- - qemuarm-stretch
- - qemuarm-buster
- - qemuarm64-stretch
- - qemuarm64-buster (for host >= buster)
+ - stretch armhf
+ - stretch arm64
+ - stretch mipsel
+ - buster armhf
+ - buster arm64 (for host >= buster)
+ - buster mipsel (for host >= buster)
+
+Experimental support for riscv64 is available as well.
 
 
 ## Examining and debugging package generation inside their buildchroot
-- 
2.26.2

[PATCH v3 15/16] doc: Describe new compat arch support

[Jan Kiszka]

From: Jan Kiszka <jan.kiszka@siemens.com>

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 doc/user_manual.md | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/doc/user_manual.md b/doc/user_manual.md
index 5c3996d7..dd6fc344 100644
--- a/doc/user_manual.md
+++ b/doc/user_manual.md
@@ -723,6 +723,19 @@ Debian cross-compilation works out of the box starting from Debian stretch distr
 
 Experimental support for riscv64 is available as well.
 
+### Cross-building for a compat architecture
+
+Some architectures, under Isar amd64 and arm64 so far, support running 32-bit
+legacy applications on 64-bit kernels. Debian supports this via the multiarch
+concept.
+
+Isar can build 32-bit packages as part of a 64-bit image build and also enable
+the image with the necessary packages. To activate the compat mode of a build,
+set `ISAR_ENABLE_COMPAT_ARCH = "1"` in `local.conf`. Packages that shall be
+built for the compat arch need to be tagged individually by setting
+`PACKAGE_ARCH = "${COMPAT_DISTRO_ARCH}"` in the package recipe. Non-tagged
+packages will continue to be built for the primary target architecture.
+
 
 ## Examining and debugging package generation inside their buildchroot
 
-- 
2.26.2

[PATCH v3 16/16] isar-bootstrap: Connect to gpg-agent before adding keys

[Jan Kiszka]

From: Jan Kiszka <jan.kiszka@siemens.com>

We have recurring issues in CI with the gpg-agent not being ready when
trying to use apt-key:

gpg: can't connect to the agent: IPC connect call failed

Work around this by connecting upfront to the agent, retrying that in a
bounded loop.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 meta/recipes-core/isar-bootstrap/isar-bootstrap.inc | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc b/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc
index fbfe669d..957dfd6a 100644
--- a/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc
+++ b/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc
@@ -303,6 +303,10 @@ isar_bootstrap() {
                              "${ROOTFSDIR}/etc/apt/apt.conf.d/50isar.conf"
             find ${APT_KEYS_DIR}/ -type f | while read keyfile
             do
+                for i in $(seq 10); do
+                    gpg-connect-agent && break
+                    sleep 1
+                done
                 kfn="$(basename $keyfile)"
                 cp $keyfile "${ROOTFSDIR}/tmp/$kfn"
                 chroot "${ROOTFSDIR}" /usr/bin/apt-key \
-- 
2.26.2

Re: [PATCH v3 16/16] isar-bootstrap: Connect to gpg-agent before adding keys

[Jan Kiszka]

On 22.09.20 17:28, [ext] Jan Kiszka wrote:
> From: Jan Kiszka <jan.kiszka@siemens.com>
> 
> We have recurring issues in CI with the gpg-agent not being ready when
> trying to use apt-key:
> 
> gpg: can't connect to the agent: IPC connect call failed
> 
> Work around this by connecting upfront to the agent, retrying that in a
> bounded loop.
> 
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> ---
>   meta/recipes-core/isar-bootstrap/isar-bootstrap.inc | 4 ++++
>   1 file changed, 4 insertions(+)
> 
> diff --git a/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc b/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc
> index fbfe669d..957dfd6a 100644
> --- a/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc
> +++ b/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc
> @@ -303,6 +303,10 @@ isar_bootstrap() {
>                                "${ROOTFSDIR}/etc/apt/apt.conf.d/50isar.conf"
>               find ${APT_KEYS_DIR}/ -type f | while read keyfile
>               do
> +                for i in $(seq 10); do
> +                    gpg-connect-agent && break
> +                    sleep 1
> +                done
>                   kfn="$(basename $keyfile)"
>                   cp $keyfile "${ROOTFSDIR}/tmp/$kfn"
>                   chroot "${ROOTFSDIR}" /usr/bin/apt-key \
> 

Strike this, nonsense. Got confused by the levels of chroots. New 
version will follow that retries the key addition itself, inside the chroot.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH v3 16/16] isar-bootstrap: Connect to gpg-agent before adding keys

[Baurzhan Ismagulov]

On Tue, Sep 22, 2020 at 11:03:52PM +0200, Jan Kiszka wrote:
> Strike this, nonsense. Got confused by the levels of chroots. New version
> will follow that retries the key addition itself, inside the chroot.

We have a similar implementation which also kills the agent afterwards, will
post as well.

With kind regards,
Baurzhan.

[PATCH v4 16/16] isar-bootstrap: Connect to gpg-agent before adding keys

[Jan Kiszka]

From: Jan Kiszka <jan.kiszka@siemens.com>

We have recurring issues in CI with the gpg-agent not being ready when
trying to use apt-key:

gpg: can't connect to the agent: IPC connect call failed

Work around this by connecting upfront to the agent, retrying that in a
bounded loop.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---

This one seems to work fine.

Not sure if killing the agent is needed. In most cases, Isar runs in 
more (VMs) or less (containers) isolated environments anyway. I case it
doesn't, wouldn't killing possibly affects what the user started before 
running Isar?

 meta/recipes-core/isar-bootstrap/isar-bootstrap.inc | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc b/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc
index fbfe669d..1c5dba74 100644
--- a/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc
+++ b/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc
@@ -303,10 +303,13 @@ isar_bootstrap() {
                              "${ROOTFSDIR}/etc/apt/apt.conf.d/50isar.conf"
             find ${APT_KEYS_DIR}/ -type f | while read keyfile
             do
-                kfn="$(basename $keyfile)"
+                export kfn="$(basename $keyfile)"
                 cp $keyfile "${ROOTFSDIR}/tmp/$kfn"
-                chroot "${ROOTFSDIR}" /usr/bin/apt-key \
-                   --keyring ${THIRD_PARTY_APT_KEYRING} add "/tmp/$kfn"
+                chroot "${ROOTFSDIR}" sh -c '
+                    for i in $(seq 10); do
+                        /usr/bin/apt-key --keyring ${THIRD_PARTY_APT_KEYRING} add "/tmp/$kfn" && break
+                        sleep 1
+                    done'
                 rm "${ROOTFSDIR}/tmp/$kfn"
             done
 
-- 
2.26.2

Re: [PATCH v3 12/16] Add compat architecture support via multiarch

[Baurzhan Ismagulov]

On Tue, Sep 22, 2020 at 05:28:50PM +0200, Jan Kiszka wrote:
> Allow building and installing 32-bit packages an 64-bit architectures
> that support this. Namely, these are amd64 and arm64 for us so far,
> minus stretch-amd64 which lacks crossbuild-essential-i386 in that
> version.
> 
> Control the target architecture of a package is added via the
> PACKAGE_ARCH variable that defaults to DISTRO_ARCH. When set to
> COMPAT_DISTRO_ARCH, the package is built for i386 on amd64 and armhf on
> arm64.
> 
> If the build environment and the target image should contain the compat
> arch is controlled via setting ISAR_ENABLE_COMPAT_ARCH to 1.

Looks like a clean implementation, thanks. Applied 12-15/16 to have this in
earlier than later.

With kind regards,
Baurzhan.

Re: [PATCH v3 06/16] sdk: Add support for adding self-defined sdk packages

[Baurzhan Ismagulov]

Hello Jan,

On Tue, Sep 22, 2020 at 05:28:44PM +0200, Jan Kiszka wrote:
> We do not yet have a good algorithm for automatically adding build
> dependencies to the sdk beyond the basic set, let's allow users to
> append what they need by appending SDK_PREINSTALL. Analogously to other
> images, also allow to install self-built packages, consequently using
> SDK_INSTALL.
> 
> Based on original patch by Le Jin.

Two issues:

1. I've tried the following:

   . ./isar-init-build-env build
   bitbake -c do_populate_sdk mc:qemuarm-buster:isar-image-base

   When I look into tmp/deploy/images/qemuarm/sdk-debian-buster-armhf.tar.xz,
   etc/apt/sources.list.d/isar-apt.list is not present. Am I missing anything?

2. The series still removes isar-apt description in p11.

With kind regards,
Baurzhan.

Re: [PATCH v3 06/16] sdk: Add support for adding self-defined sdk packages

[Jan Kiszka]

On 29.09.20 21:15, Baurzhan Ismagulov wrote:
> Hello Jan,
>
> On Tue, Sep 22, 2020 at 05:28:44PM +0200, Jan Kiszka wrote:
>> We do not yet have a good algorithm for automatically adding build
>> dependencies to the sdk beyond the basic set, let's allow users to
>> append what they need by appending SDK_PREINSTALL. Analogously to other
>> images, also allow to install self-built packages, consequently using
>> SDK_INSTALL.
>>
>> Based on original patch by Le Jin.
>
> Two issues:
>
> 1. I've tried the following:
>
>    . ./isar-init-build-env build
>    bitbake -c do_populate_sdk mc:qemuarm-buster:isar-image-base
>
>    When I look into tmp/deploy/images/qemuarm/sdk-debian-buster-armhf.tar.xz,
>    etc/apt/sources.list.d/isar-apt.list is not present. Am I missing anything?

Was that with SDK_INCLUDE_ISAR_APT = "1"? It's opt-in now, see patch 9.

>
> 2. The series still removes isar-apt description in p11.

It's opt-in now, the common case for most users remains setting
SDK_INSTALL. We are only leaving the option to ship all the packages,
including all the useless ones, for special purposes.

Jan

Re: [PATCH v3 01/16] Split up isar-apt into distro-arch specific instances

[Baurzhan Ismagulov]

Hello Jan,

On Tue, Sep 22, 2020 at 05:28:39PM +0200, Jan Kiszka wrote:
> The split on a per-arch basis is required because bitbake cannot detect
> that a generic package (architecture 'all') built by recipes running for
> different architectures will produce the same results. The split also
> per distro is for consistency reasons only.

Applied 1-5 to next, thanks.

With kind regards,
Baurzhan.

Re: [PATCH v3 06/16] sdk: Add support for adding self-defined sdk packages

[Baurzhan Ismagulov]

On Wed, Sep 30, 2020 at 09:19:15PM +0200, Jan Kiszka wrote:
> > 1. I've tried the following:
> >
> >    . ./isar-init-build-env build
> >    bitbake -c do_populate_sdk mc:qemuarm-buster:isar-image-base
> >
> >    When I look into tmp/deploy/images/qemuarm/sdk-debian-buster-armhf.tar.xz,
> >    etc/apt/sources.list.d/isar-apt.list is not present. Am I missing anything?
> 
> Was that with SDK_INCLUDE_ISAR_APT = "1"? It's opt-in now, see patch 9.

Yes, I forgot to mention that, sorry for the confusion. The commands I used,
hopefully correct now:

. ./isar-init-build-env build
echo 'SDK_INCLUDE_ISAR_APT = "1"' >>conf/local.conf
echo 'ISAR_CROSS_COMPILE = "1"' >>conf/local.conf
time bitbake -c do_populate_sdk mc:qemuarm-buster:isar-image-base
cd tmp/deploy/images/qemuarm
sudo tar Jxf sdk-debian-buster-armhf.tar.xz
ls sdk-debian-buster-armhf/etc/apt/sources.list.d/isar-apt.list
ls: cannot access 'sdk-debian-buster-armhf/etc/apt/sources.list.d/isar-apt.list': No such file or directory


> > 2. The series still removes isar-apt description in p11.
> 
> It's opt-in now, the common case for most users remains setting
> SDK_INSTALL. We are only leaving the option to ship all the packages,
> including all the useless ones, for special purposes.

I'm referring to the following hunk:

- - Check that cross toolchains are installed
-
-:~# dpkg -l | grep crossbuild-essential-armhf
-ii  crossbuild-essential-armhf           12.3                   all          Informational list of cross-build-essential packages
-
- - Install needed prebuilt target packages.
-
-:~# apt-get update
-:~# apt-get install libhello-dev:armhf
-
- - Check the contents of the installed target package
-
-:~# dpkg -L libhello-dev
-/.
-/usr
-/usr/include
-/usr/include/hello.h
-/usr/lib
-/usr/lib/arm-linux-gnueabihf
-/usr/lib/arm-linux-gnueabihf/libhello.a
-/usr/lib/arm-linux-gnueabihf/libhello.la
-/usr/share
-/usr/share/doc
-/usr/share/doc/libhello-dev
-/usr/share/doc/libhello-dev/changelog.gz
-/usr/share/doc/libhello-dev/copyright
-~#

This explains to the user how Debian multiarch works with option 2. This
example works inside or outside of the chroot. We should not be removing
documentation for a supported use case, thus NAK here.


3. In 08/16: Suggest "conpilation" -> "compilation".


With kind regards,
Baurzhan.

Re: [PATCH v3 06/16] sdk: Add support for adding self-defined sdk packages

[Jan Kiszka]

On 06.10.20 11:00, Baurzhan Ismagulov wrote:
> On Wed, Sep 30, 2020 at 09:19:15PM +0200, Jan Kiszka wrote:
>>> 1. I've tried the following:
>>>
>>>    . ./isar-init-build-env build
>>>    bitbake -c do_populate_sdk mc:qemuarm-buster:isar-image-base
>>>
>>>    When I look into tmp/deploy/images/qemuarm/sdk-debian-buster-armhf.tar.xz,
>>>    etc/apt/sources.list.d/isar-apt.list is not present. Am I missing anything?
>>
>> Was that with SDK_INCLUDE_ISAR_APT = "1"? It's opt-in now, see patch 9.
> 
> Yes, I forgot to mention that, sorry for the confusion. The commands I used,
> hopefully correct now:
> 
> . ./isar-init-build-env build
> echo 'SDK_INCLUDE_ISAR_APT = "1"' >>conf/local.conf
> echo 'ISAR_CROSS_COMPILE = "1"' >>conf/local.conf
> time bitbake -c do_populate_sdk mc:qemuarm-buster:isar-image-base
> cd tmp/deploy/images/qemuarm
> sudo tar Jxf sdk-debian-buster-armhf.tar.xz
> ls sdk-debian-buster-armhf/etc/apt/sources.list.d/isar-apt.list
> ls: cannot access 'sdk-debian-buster-armhf/etc/apt/sources.list.d/isar-apt.list': No such file or directory
> 

OK, need to check again. Cannot explain yet why that should happen,
given the change in patch 9. Maybe I have a regression further down the
series...

> 
>>> 2. The series still removes isar-apt description in p11.
>>
>> It's opt-in now, the common case for most users remains setting
>> SDK_INSTALL. We are only leaving the option to ship all the packages,
>> including all the useless ones, for special purposes.
> 
> I'm referring to the following hunk:
> 
> - - Check that cross toolchains are installed
> -
> -:~# dpkg -l | grep crossbuild-essential-armhf
> -ii  crossbuild-essential-armhf           12.3                   all          Informational list of cross-build-essential packages
> -
> - - Install needed prebuilt target packages.
> -
> -:~# apt-get update
> -:~# apt-get install libhello-dev:armhf
> -
> - - Check the contents of the installed target package
> -
> -:~# dpkg -L libhello-dev
> -/.
> -/usr
> -/usr/include
> -/usr/include/hello.h
> -/usr/lib
> -/usr/lib/arm-linux-gnueabihf
> -/usr/lib/arm-linux-gnueabihf/libhello.a
> -/usr/lib/arm-linux-gnueabihf/libhello.la
> -/usr/share
> -/usr/share/doc
> -/usr/share/doc/libhello-dev
> -/usr/share/doc/libhello-dev/changelog.gz
> -/usr/share/doc/libhello-dev/copyright
> -~#
> 
> This explains to the user how Debian multiarch works with option 2. This
> example works inside or outside of the chroot. We should not be removing
> documentation for a supported use case, thus NAK here.
> 

This hunk looks pointless to me. Why should the user try out all that
stuff? It's the duty of the SDK creator to do that upfront and ship a
properly working package.

Jan

> 
> 3. In 08/16: Suggest "conpilation" -> "compilation".
> 

Thanks, will fix.

But please comment inline, not out of context.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: [PATCH v3 06/16] sdk: Add support for adding self-defined sdk packages

[Baurzhan Ismagulov]

On Wed, Oct 07, 2020 at 09:30:06AM +0200, Jan Kiszka wrote:
> OK, need to check again. Cannot explain yet why that should happen,
> given the change in patch 9. Maybe I have a regression further down the
> series...

Thanks, please let us know. I also stared at the line for some time and
couldn't see what is wrong.


> > This explains to the user how Debian multiarch works with option 2. This
> > example works inside or outside of the chroot. We should not be removing
> > documentation for a supported use case, thus NAK here.
> > 
> 
> This hunk looks pointless to me. Why should the user try out all that
> stuff? It's the duty of the SDK creator to do that upfront and ship a
> properly working package.

Trying in the context of SDK -- that's a matter of taste, I like when some
background is presented rather than "do 1, 2, 3", sometimes without
understanding what I'm really doing. The hunk explains how Debian officially
handles cross-building with multiarch, so I'd be reluctant to remove that
completely. Maybe we could make it a separate section on Debian basics or
details how SDK option 2 is implemented.


> Thanks, will fix.
> 
> But please comment inline, not out of context.

I wanted to avoid scattering the issue over many mails -- but no problem, I can
do it.


With kind regards,
Baurzhan.

Re: [PATCH v3 06/16] sdk: Add support for adding self-defined sdk packages

[Jan Kiszka]

On 07.10.20 10:06, Baurzhan Ismagulov wrote:
> On Wed, Oct 07, 2020 at 09:30:06AM +0200, Jan Kiszka wrote:
>> OK, need to check again. Cannot explain yet why that should happen,
>> given the change in patch 9. Maybe I have a regression further down the
>> series...
> 
> Thanks, please let us know. I also stared at the line for some time and
> couldn't see what is wrong.
> 

Fixed: test with "==", rather than "=". Cleaned up more around that.
Will send v4.

> 
>>> This explains to the user how Debian multiarch works with option 2. This
>>> example works inside or outside of the chroot. We should not be removing
>>> documentation for a supported use case, thus NAK here.
>>>
>>
>> This hunk looks pointless to me. Why should the user try out all that
>> stuff? It's the duty of the SDK creator to do that upfront and ship a
>> properly working package.
> 
> Trying in the context of SDK -- that's a matter of taste, I like when some
> background is presented rather than "do 1, 2, 3", sometimes without
> understanding what I'm really doing. The hunk explains how Debian officially
> handles cross-building with multiarch, so I'd be reluctant to remove that
> completely. Maybe we could make it a separate section on Debian basics or
> details how SDK option 2 is implemented.

I'm all for adding relevant information, but this one does not qualify.
Checking for the toolchain being install was always completely pointless
in the context of an SDK that always has this pre-installed according to
our recipes. And since isar-apt is now a special case and SDK_INSTALL
will ensure that all required packages are already installed, the second
hint is also irrelevant for normal users. It is only for the case of
SDK_INCLUDE_ISAR_APT = 1 *and* SDK_INSTALL *not* listing self-built
devel packages needed for building applications.

If you have other information that may help users with using the SDK in
chroot mode, feel free to add that on top.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: [PATCH v3 06/16] sdk: Add support for adding self-defined sdk packages

[Baurzhan Ismagulov]

On Wed, Oct 07, 2020 at 03:36:47PM +0200, Jan Kiszka wrote:
> Fixed: test with "==", rather than "=". Cleaned up more around that.

Thanks, isar-apt.list is now available. However, when I enter the chroot, an
attempt to run arm-linux-gnueabihf-gcc results in:

-bash: arm-linux-gnueabihf-gcc: command not found


> I'm all for adding relevant information, but this one does not qualify.
> Checking for the toolchain being install was always completely pointless
> in the context of an SDK that always has this pre-installed according to
> our recipes.

Yes, it might be confusing in the context of SDK. The section is meant as a
story and not a literal instruction. It tells the user that he can sudo apt-get
install crossbuild-essential-armhf libhello-dev:armhf and build his application
on the host with stock Debian, without any SDK. It describes the official
Debian build tooling and is certainly not limited to the chroot mode, while the
SDK is a convenience offer so that developers famliar with Yocto can start
right away before they learn Debian tools. Checking for the toolchain shows how
stuff works rather than verifying that the recipes have done their job.


> And since isar-apt is now a special case and SDK_INSTALL
> will ensure that all required packages are already installed, the second
> hint is also irrelevant for normal users. It is only for the case of
> SDK_INCLUDE_ISAR_APT = 1 *and* SDK_INSTALL *not* listing self-built
> devel packages needed for building applications.

Yes, so, it is a supported use case and must remain documented.


> If you have other information that may help users with using the SDK in
> chroot mode, feel free to add that on top.

I don't have new material to add. The existing wording is good enough for me.
After the compiler is fixed, I'd be ready to apply the series while keeping the
discussed section till we have a suitable replacement.


With kind regards,
Baurzhan.

Re: [PATCH v3 06/16] sdk: Add support for adding self-defined sdk packages

[Jan Kiszka]

On 15.10.20 23:51, Baurzhan Ismagulov wrote:
> On Wed, Oct 07, 2020 at 03:36:47PM +0200, Jan Kiszka wrote:
>> Fixed: test with "==", rather than "=". Cleaned up more around that.
> 
> Thanks, isar-apt.list is now available. However, when I enter the chroot, an
> attempt to run arm-linux-gnueabihf-gcc results in:
> 
> -bash: arm-linux-gnueabihf-gcc: command not found
> 

Checking... Nope, works fine here:

- echo 'SDK_INCLUDE_ISAR_APT = "1"' >> conf/local.conf
- bitbake -c populate_sdk mc:qemuarm-buster:isar-image-base
- sudo tar xJf
/work/build/tmp/deploy/images/qemuarm/sdk-debian-buster-armhf.tar.xz
- sudo sdk-debian-buster-armhf/mount_chroot.sh sdk-debian-buster-armhf/
- sudo chroot sdk-debian-buster-armhf/

root@566b0c868313:/# arm-linux-gnueabihf-gcc
arm-linux-gnueabihf-gcc-8.bin: fatal error: no input files
compilation terminated.

Please provide more details what you did.

> 
>> I'm all for adding relevant information, but this one does not qualify.
>> Checking for the toolchain being install was always completely pointless
>> in the context of an SDK that always has this pre-installed according to
>> our recipes.
> 
> Yes, it might be confusing in the context of SDK. The section is meant as a
> story and not a literal instruction. It tells the user that he can sudo apt-get
> install crossbuild-essential-armhf libhello-dev:armhf and build his application
> on the host with stock Debian, without any SDK. It describes the official

This section is part of the SDK, not the user manual. So the context is
not as broad as you describe it here.

> Debian build tooling and is certainly not limited to the chroot mode, while the
> SDK is a convenience offer so that developers famliar with Yocto can start
> right away before they learn Debian tools. Checking for the toolchain shows how
> stuff works rather than verifying that the recipes have done their job.
> 
> 
>> And since isar-apt is now a special case and SDK_INSTALL
>> will ensure that all required packages are already installed, the second
>> hint is also irrelevant for normal users. It is only for the case of
>> SDK_INCLUDE_ISAR_APT = 1 *and* SDK_INSTALL *not* listing self-built
>> devel packages needed for building applications.
> 
> Yes, so, it is a supported use case and must remain documented.

Then we need README generation - because all this only makes sense in
that non-default case. I don't see much value, though.

> 
> 
>> If you have other information that may help users with using the SDK in
>> chroot mode, feel free to add that on top.
> 
> I don't have new material to add. The existing wording is good enough for me.
> After the compiler is fixed, I'd be ready to apply the series while keeping the
> discussed section till we have a suitable replacement.

No, that section will not stay for the common case. I will add the
relevant parts in case SDK_INCLUDE_ISAR_APT = 1 and still drop the
irrelevant ones (toolchain check).

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: [PATCH v3 06/16] sdk: Add support for adding self-defined sdk packages

[Baurzhan Ismagulov]

On Fri, Oct 16, 2020 at 09:15:12AM +0200, Jan Kiszka wrote:
> Checking... Nope, works fine here:
> 
> - echo 'SDK_INCLUDE_ISAR_APT = "1"' >> conf/local.conf
> - bitbake -c populate_sdk mc:qemuarm-buster:isar-image-base
> - sudo tar xJf
> /work/build/tmp/deploy/images/qemuarm/sdk-debian-buster-armhf.tar.xz
> - sudo sdk-debian-buster-armhf/mount_chroot.sh sdk-debian-buster-armhf/
> - sudo chroot sdk-debian-buster-armhf/
> 
> root@566b0c868313:/# arm-linux-gnueabihf-gcc
> arm-linux-gnueabihf-gcc-8.bin: fatal error: no input files
> compilation terminated.

Thanks for the details! Turns out I made a mistake while applying the series.


> No, that section will not stay for the common case. I will add the
> relevant parts in case SDK_INCLUDE_ISAR_APT = 1 and still drop the
> irrelevant ones (toolchain check).

As discussed offline, I'd like to have a consensus here. To summarize, your
point is that the description is not necessary if README.sdk is used as a
literal howto, and that the deeper message is only clear for expert users, who
know that anyway. Given these questions, I agree with the answers. My question
is a different one: Multiarch is Debian's unique feature for embedded
development, and we should be covering that somewhere in the docs. As a
solution, I'd like to enhance the existing docs instead of removing them. I've
checked the user manual, the topics are covered there. I've applied v4. As
agreed, the enhancements can still be implemented, I can provide them on top.


With kind regards,
Baurzhan.