From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6701739048874016768 X-Received: by 2002:a19:8c06:: with SMTP id o6mr28826316lfd.176.1560442170100; Thu, 13 Jun 2019 09:09:30 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:ac2:4212:: with SMTP id y18ls414979lfh.4.gmail; Thu, 13 Jun 2019 09:09:29 -0700 (PDT) X-Google-Smtp-Source: APXvYqxJYxLuTen4cOP99Zx1CazvBSxUb9Wt2Un0bogKBdtRL+UP1XFwcUaweVXcpEACNmtDMN4P X-Received: by 2002:ac2:50cd:: with SMTP id h13mr8733562lfm.36.1560442169622; Thu, 13 Jun 2019 09:09:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560442169; cv=none; d=google.com; s=arc-20160816; b=cY/A7dH6vp//aGo+z9T8zvFGfGkLPI9/SAE+fsagaHSovX8BTlPnBHeTBKnlQ43f8H clJU+y5Ejj+rUk7o8MKCD53s9651dZobz5shXu3DPGMUXxcrmy3XVWNuKFgE7l6Bhx6W hvcWVYgXRO+ArcmWlZbpJ2ADGHOnDhWCnzOkj2ksbltcd9pfz960F3vot/q6lsIaiVlM GLrCvc1xZ0w/IS7T/wfO/vgdxtRgkw7pDgf4vD5EJHNXTZWKdVJfKFwzfgYcV5KTFvwa huwwvTL1GeH997BGRdA2QqdTBB8kYq3N/8hu6VTyVqZHhI6Mzlh0Zk/c+g0vMyZkkAYH gugg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date; bh=Fn5nj2KBHMwn1LLURfbse/ZRQ50UFAH46RI4rXJUf9Q=; b=xUluJ2c+RRHZyVR8c5TlEB2Lc9/Tk0T8rholtSs6gWVmhVVd8Mxap9BQwln9dRh0dl JNm5pmTwa1ZRaIsl8sYggRkbmCYHBcGJfMAmGl8xlw6PnSVrM1NH1onpQxTzt1FwS3oS ubiAuLR7wwiY+gTmBSxI151/EkrPC1LlKwt/ZpUFQizZXMTajtBorF5HGnpH8Q8cAvXH GWdbqVRWpvw54PKh0RW8sadXqHMrQD6T/1tHL+6pR8RFZrcn2cww7+IlphyHpB9QJWYe FsCz25QoYnh2/izCQJXFyE+fYUeQ64RTDc3DKJtQJAd3wgUzfn1/sDQDKnnPEyEOkCkC Oqcg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=henning.schild@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from goliath.siemens.de (goliath.siemens.de. [192.35.17.28]) by gmr-mx.google.com with ESMTPS id h11si27168lja.0.2019.06.13.09.09.29 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Jun 2019 09:09:29 -0700 (PDT) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.28 as permitted sender) client-ip=192.35.17.28; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=henning.schild@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id x5DG9SXN016464 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 13 Jun 2019 18:09:28 +0200 Received: from md1za8fc.ad001.siemens.net ([139.25.68.171]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id x5DG9SEE012627; Thu, 13 Jun 2019 18:09:28 +0200 Date: Thu, 13 Jun 2019 18:09:28 +0200 From: Henning Schild To: "Hombourger, Cedric" , "Kiszka, Jan (CT RDA IOT SES-DE)" Cc: "isar-users@googlegroups.com" Subject: Re: [PATCH] linux-custom: repack linux-libc-dev Message-ID: <20190613180928.358b01fd@md1za8fc.ad001.siemens.net> In-Reply-To: <20190613173733.483cdb98@md1za8fc.ad001.siemens.net> References: <1560370202-632-1-git-send-email-Cedric_Hombourger@mentor.com> <20190613101030.156ab5ac@md1za8fc.ad001.siemens.net> <1560414746469.39403@mentor.com> <20190613173733.483cdb98@md1za8fc.ad001.siemens.net> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TUID: u8Ag9Rmh1wWH Am Thu, 13 Jun 2019 17:37:33 +0200 schrieb "[ext] Henning Schild" : > Am Thu, 13 Jun 2019 08:32:26 +0000 > schrieb "Hombourger, Cedric" : > > > Hi Henning > > > > Agreed but I would think we would need a work-around in Isar until > > the proposed change gets accepted by k.org folks (on a different > > note, I also need to submit a patch to arch/mips/Makefile for > > builddeb to succeed - my linux-custom recipe would not build without > > a patch as dtbs don't get built by default while they do on e.g. > > aarch64) > > > > I would therefore suggest to have build-kernel.sh do something like: > > > > if [ -d <...>/usr/include/asm ]; then > > echo "warning: your kernel has incorrectly packaged > > linux-libc-dev headers" >&2 # apply work-around and repack > > linux-libc-dev ... > > mv <...>/usr/include/asm <...>/usr/include/${LIBC_HEADERS_DIR}/ > > ... > > fi > > I guess a backport or such a hack would not be a big deal, after > upstream accepted your patch. k.org is probably faster than ilbers > > Lets at least see what the discussion brings and how fast it starts. > Maybe upstream will aknowledge the bug right away. Or they might give > valuable feedback on what we do not understand. ... and should not be > putting into Isar on the fast-lane Thinking about it again. The whole repacking should maybe be replaced with patching the original packing code. That would make clearer what the changes to the kernel actually are. If patches do not apply anymore on changing kernels, we would have a clear warning to review that again. so we would carry meta/recipes-kernel/linux/files/ linux-image-depends.patch linux-image-aarch64-uncompressed_4.19.patch linux-image-aarch64-uncompressed_4.4.patch ... All these would be SRC_URI += ;apply=no from the inc, which would also get a new magic patch function deciding which ones to apply depending on PV. The result would also be a kernel tree that you could actually "builddeb" outside of Isar, and skipping the repack might save time. Henning > Henning > > > I can submit a v2 if the approach is agreeable > > will roll-up my sleeves a prepare a patch for k.org > > > > Cedric > > ________________________________________ > > From: Henning Schild > > Sent: Thursday, June 13, 2019 10:10 AM > > To: Hombourger, Cedric > > Cc: isar-users@googlegroups.com > > Subject: Re: [PATCH] linux-custom: repack linux-libc-dev > > > > Am Wed, 12 Jun 2019 22:10:02 +0200 > > schrieb Cedric Hombourger : > > > > > Debian's linux-libc-dev package has "asm" headers in the following > > > directory: /usr/include//asm while the builddeb script > > > from the Linux kernel places them in: /usr/include/asm. Repack the > > > linux-libc-dev package (fixing a build error for packages built > > > against Isar-created distributions shipping a custom kernel in > > > lieu of Debian's). > > > > To me that sounds like an upstream bug that should not just get > > covered up by repacking. I would propose looking into a kernel patch > > for the "debpkg" step. That patch could be carried in your layer(s) > > and Isar while it is pending upstream. > > > > Looking at both ubuntu and debian, old and new .. it should never > > be /usr/include/asm/. > > > > > Signed-off-by: Cedric Hombourger > > > --- > > > meta/recipes-kernel/linux/files/build-kernel.sh | 38 > > > +++++++++++++++++++++++-- 1 file changed, 35 insertions(+), 3 > > > deletions(-) > > > > > > diff --git a/meta/recipes-kernel/linux/files/build-kernel.sh > > > b/meta/recipes-kernel/linux/files/build-kernel.sh index > > > 8b7b23b..2c97932 100644 --- > > > a/meta/recipes-kernel/linux/files/build-kernel.sh +++ > > > b/meta/recipes-kernel/linux/files/build-kernel.sh @@ -9,8 +9,20 @@ > > > > > > source /isar/common.sh > > > > > > -host_arch=$(dpkg --print-architecture) > > > +unsupported_arch() { > > > + echo "error: unsupported architecture ($1)" >&2 > > > + exit 1 > > > +} > > > + > > > +case $target_arch in > > > + amd64) LIBC_HEADERS_DIR="x86_64-linux-gnu" ;; > > > + armhf) LIBC_HEADERS_DIR="arm-linux-gnueabihf" ;; > > > + arm64) LIBC_HEADERS_DIR="aarch64-linux-gnu" ;; > > > + mipsel) LIBC_HEADERS_DIR="mipsel-linux-gnu" ;; > > > + *) unsupported_arch "$target_arch" ;; > > > +esac > > > > Looks suspiciously like "${CROSS-COMPILE}gcc -dumpmachine". Using > > that would relieve us from carrying those magic strings around. > > > > > > > +host_arch=$(dpkg --print-architecture) > > > if [ "$host_arch" != "$target_arch" ]; then > > > case $target_arch in > > > armhf) > > > @@ -26,8 +38,7 @@ if [ "$host_arch" != "$target_arch" ]; then > > > export CROSS_COMPILE="mipsel-linux-gnu-" > > > ;; > > > *) > > > - echo "error: unsupported architecture ($target_arch)" > > > - exit 1 > > > + unsupported_arch "$target_arch" > > > ;; > > > esac > > > fi > > > @@ -35,6 +46,7 @@ fi > > > REPACK_DIR="$1/../repack" > > > REPACK_LINUX_IMAGE_DIR="${REPACK_DIR}/linux-image" > > > REPACK_LINUX_HEADERS_DIR="${REPACK_DIR}/linux-headers" > > > +REPACK_LIBC_HEADERS_DIR="${REPACK_DIR}/libc-headers" > > > > > > if [ -e .config ]; then > > > make olddefconfig > > > @@ -56,6 +68,7 @@ rm -rf "${REPACK_DIR}" > > > mkdir -p "${REPACK_DIR}" > > > mkdir -p "${REPACK_LINUX_IMAGE_DIR}" > > > mkdir -p "${REPACK_LINUX_HEADERS_DIR}" > > > +mkdir -p "${REPACK_LIBC_HEADERS_DIR}" > > > > > > cp -a debian "${REPACK_DIR}" > > > > > > @@ -67,6 +80,7 @@ cd .. > > > > > > dpkg-deb -R linux-image-${PV}_${PV}-1_*.deb > > > "${REPACK_LINUX_IMAGE_DIR}" dpkg-deb -R > > > linux-headers-${PV}_${PV}-1_*.deb "${REPACK_LINUX_HEADERS_DIR}" > > > +dpkg-deb -R linux-libc-dev_${PV}-1_*.deb > > > "${REPACK_LIBC_HEADERS_DIR}" dpkg-gencontrol > > > -crepack/debian/control \ -lrepack/debian/changelog \ > > > @@ -110,6 +124,10 @@ if [ "$target_arch" = "arm64" ]; then > > > gunzip "$vmlinuz.gz" > > > fi > > > > > > +# Move libc's asm headers where they are expected > > > +mkdir ${REPACK_LIBC_HEADERS_DIR}/usr/include/${LIBC_HEADERS_DIR} > > > +mv ${REPACK_LIBC_HEADERS_DIR}/usr/include/asm > > > ${REPACK_LIBC_HEADERS_DIR}/usr/include/${LIBC_HEADERS_DIR} + > > > dpkg-gencontrol -crepack/debian/control \ > > > -lrepack/debian/changelog \ > > > -frepack/debian/files \ > > > @@ -121,12 +139,26 @@ dpkg-gencontrol -crepack/debian/control \ > > > -DDepends="${KERNEL_HEADERS_DEBIAN_DEPENDS}" \ > > > -DArchitecture=$target_arch > > > > > > +dpkg-gencontrol -crepack/debian/control \ > > > + -lrepack/debian/changelog \ > > > + -frepack/debian/files \ > > > + -plinux-libc-dev \ > > > + -P"${REPACK_LIBC_HEADERS_DIR}" \ > > > + -Vkernel:debarch="${KERNEL_NAME}" \ > > > + -DPackage="linux-libc-dev" \ > > > + -DSection=kernel \ > > > + -DDepends="${LIBC_HEADERS_DEBIAN_DEPENDS}" \ > > > + -DArchitecture=$target_arch > > > + > > > fakeroot dpkg-deb -b "${REPACK_LINUX_IMAGE_DIR}" \ > > > linux-image-${KERNEL_NAME}_${PV}-1_${KERNEL_NAME}.deb > > > rm -f linux-image-${PV}_${PV}-1_*.deb > > > fakeroot dpkg-deb -b "${REPACK_LINUX_HEADERS_DIR}" \ > > > linux-headers-${KERNEL_NAME}_${PV}-1_${KERNEL_NAME}.deb > > > rm -f linux-headers-${PV}_${PV}-1_*.deb > > > +rm -f linux-libc-dev_${PV}-1_*.deb > > > +fakeroot dpkg-deb -b "${REPACK_LIBC_HEADERS_DIR}" \ > > > + linux-libc-dev_${PV}-1_${KERNEL_NAME}.deb > > > > > > # linux-libc-dev causes dependency problems if we downgrade > > > # remove it after the build so the downgraded version does not > > > get deployed > > > > Ahh this guy is still somehow in the patch. You might want to have a > > look at 7a1f14ca. My guess is that skipping the downgrade is still > > OK because the problem just shows once you install the libc-dev > > package. >