From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6735105003214602240 X-Received: by 2002:adf:f303:: with SMTP id i3mr31331342wro.242.1568623570301; Mon, 16 Sep 2019 01:46:10 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a5d:526c:: with SMTP id l12ls1721832wrc.12.gmail; Mon, 16 Sep 2019 01:46:09 -0700 (PDT) X-Google-Smtp-Source: APXvYqzzjBgBEgQZ+NOLbCjAOHTb4lytzvCk1eDTa/0ZqQmdknw5XcT+RIrmF00xlGj3UcGZWjBs X-Received: by 2002:a5d:660c:: with SMTP id n12mr20339813wru.286.1568623569836; Mon, 16 Sep 2019 01:46:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568623569; cv=none; d=google.com; s=arc-20160816; b=gYZEPayHOchiiWxjVJPeX2UDLjPh1OhrpGHv/k/Zv3ytf7J8qM78zOYMK+IIWejc5G 7sT4k4r2FRy5KqLrlMbIrwxgt+/dAHzP6lpiX2RD91lez6jhQJShpODRTom7C41Mu8zQ VGkU0OIDCqY2qaQxhaJY75Gtu7VbkOMr1Rsfk9mvU9B9l/fA0HQxUCuTJJ6LKvetaxdE lwLHL/3PX+H2vB0WBQRS0QSStQUZlqWFTQMLPFV52eEpExfMh5LL5GWFc4l1umjxWYl+ M9jGzoeWbiDAcQwkBqPg0gY1AwA7wEC4v0Rcna8j5UHHI8SqdCNVAoCh3GQUlEjmS6Ce 76kg== 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=wAp0gymqOpmmXGi4MsUKXm8+mD5gXSQym4CqDckIgNA=; b=CXBg30s+cJShjQXQWdTk11mxitcAKkIbVwcfS39kpIxxy/kAzAXDK/wNsP6m4t6kr9 zk6e+i4AmJBNPu+8MB0qJlbBBaCPGLzod6QnnQ4Wp8SvPddaEnqjFWa3ScWL36R7T0C5 Xew3stmwfP7RrTa/ERTO33h0rylRblr/FsvkBUhSXcwc5DIDSV9mn5fIcWXrJv2Bs8Pk dS2XFuoH0UTNt0hKCnSk6FaCSMcAC+PhPs4J5dIjqVtQxXWW7bzkuE3GqytuqEUoTuWU bHhJwoXI4rPY/v530nDPeWjf4osE6DHR/t8aIt7eJmtIy4ef9WPXlzqs/VvNLzUSe4QJ IiKg== 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 w8si653963wmk.1.2019.09.16.01.46.09 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Sep 2019 01:46:09 -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 x8G8k98Z023161 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 16 Sep 2019 10:46:09 +0200 Received: from md1za8fc.ad001.siemens.net ([139.25.69.14]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id x8G8k8qb005126; Mon, 16 Sep 2019 10:46:08 +0200 Date: Mon, 16 Sep 2019 10:46:07 +0200 From: Henning Schild To: Jan Kiszka Cc: isar-users , Cedric Hombourger , Claudius Heine Subject: Re: [PATCH] linux-custom: Control linux-libc-dev deployment manually Message-ID: <20190916104607.7142b22e@md1za8fc.ad001.siemens.net> In-Reply-To: <3ea40d5b-daab-f6a6-6bc8-c14b11a49a91@siemens.com> References: <0600904d-7f34-875f-6bcf-6fbbfe8b9933@siemens.com> <20190916102742.284e1838@md1za8fc.ad001.siemens.net> <3ea40d5b-daab-f6a6-6bc8-c14b11a49a91@siemens.com> 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: eqGbWe4D41OF Am Mon, 16 Sep 2019 10:32:19 +0200 schrieb Jan Kiszka : > On 16.09.19 10:27, Henning Schild wrote: > > Am Tue, 10 Sep 2019 20:07:11 +0200 > > schrieb Jan Kiszka : > > > >> From: Jan Kiszka > >> > >> Deploying a version of linux-libc-dev that is different from the > >> one Debian uses easily causes problems. We already ran into those > >> when doing a downgrade, but we can also create deadlocks when > >> doing an update. The latter happens in common cross-build > >> scenarios when pushing a new version for the target arch but not > >> providing one for the builder. > >> > >> Avoid such troubles my making the package deployment opt-in. In > >> most cases, we will not depend on such an update because we will > >> rarely exploit new kernel API in userspace packages. > >> > >> We can revert this behavior once we support building packages for > >> both target and host. > >> > >> Signed-off-by: Jan Kiszka > >> --- > >> meta/recipes-kernel/linux/files/build-kernel.sh | 7 ------- > >> meta/recipes-kernel/linux/linux-custom.inc | 7 +++++-- > >> 2 files changed, 5 insertions(+), 9 deletions(-) > >> > >> diff --git a/meta/recipes-kernel/linux/files/build-kernel.sh > >> b/meta/recipes-kernel/linux/files/build-kernel.sh index > >> 8b7b23b..7b651af 100644 --- > >> a/meta/recipes-kernel/linux/files/build-kernel.sh +++ > >> b/meta/recipes-kernel/linux/files/build-kernel.sh @@ -127,10 +127,3 > >> @@ 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 - > >> -# linux-libc-dev causes dependency problems if we downgrade > >> -# remove it after the build so the downgraded version does not get > >> deployed -LINUX_LIBC_DEV_V=$( dpkg-query --show --showformat > >> '${Version}' linux-libc-dev ) -if dpkg --compare-versions > >> $LINUX_LIBC_DEV_V gt $PV-1; then > >> - rm -f linux-libc-dev_${PV}*.deb > >> -fi > >> diff --git a/meta/recipes-kernel/linux/linux-custom.inc > >> b/meta/recipes-kernel/linux/linux-custom.inc index c045b89..e75eed1 > >> 100644 --- a/meta/recipes-kernel/linux/linux-custom.inc > >> +++ b/meta/recipes-kernel/linux/linux-custom.inc > >> @@ -26,6 +26,8 @@ KBUILD_DEPENDS ?= "build-essential:native > >> libssl-dev libelf-dev bc git kmod biso KERNEL_DEBIAN_DEPENDS ?= > >> "initramfs-tools | linux-initramfs-tool, kmod, linux-base (>= > >> 4.3~)" KERNEL_HEADERS_DEBIAN_DEPENDS ?= "libc6, libssl1.1" > >> +KERNEL_LIBC_DEV_DEPLOY ?= "0" > >> + > >> do_install_builddeps() { > >> dpkg_do_mounts > >> E="${@ bb.utils.export_proxies(d)}" > >> @@ -61,7 +63,8 @@ dpkg_runbuild() { > >> export > >> KERNEL_HEADERS_DEBIAN_DEPENDS="${KERNEL_HEADERS_DEBIAN_DEPENDS}" > >> sudo -E chroot --userspec=$( id -u ):$( id -g ) > >> ${BUILDCHROOT_DIR} ${PP}/build-kernel.sh ${PP}/${PPS} > >> ${DISTRO_ARCH} > >> - if [ ! -f ${WORKDIR}/linux-libc-dev_${PV}*.deb ]; then > >> - bbwarn "Kernel downgrade detected, not deploying > >> linux-libc-dev" + > >> + if [ "${KERNEL_LIBC_DEV_DEPLOY}" != "1" ]; then > >> + rm -f ${WORKDIR}/linux-libc-dev_${PV}*.deb > > > > Maybe keep that warning in an else ... "not deploying since > > KERNEL_LIBC_DEV_DEPLOY=0" > > I don't see the point in this warning. It suggests that you do want > to deploy, which is actually not true. > > > > > And Claudius always suggest to stay away from such boolean variables > > and use arrays instead. That is easier to layer with "random" layer > > prios. > > Can you refer to an example? I could look one up. Do you want a code-example or a quote from Claudius? Just put him on cc, he can probably explain it without going through some ml archives. Henning > Jan >