From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6735105003214602240 X-Received: by 2002:a5d:6108:: with SMTP id v8mr4056543wrt.28.1568622742188; Mon, 16 Sep 2019 01:32:22 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a1c:a78e:: with SMTP id q136ls4687319wme.1.gmail; Mon, 16 Sep 2019 01:32:21 -0700 (PDT) X-Google-Smtp-Source: APXvYqz2Qd5ZXW0sEjX0U6cVlIvIfjUJE4GKPGwgHXeEf6smX8aiLEgaADo1pwZZVJ9YiVVup0gq X-Received: by 2002:a7b:caa9:: with SMTP id r9mr8634404wml.14.1568622741576; Mon, 16 Sep 2019 01:32:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568622741; cv=none; d=google.com; s=arc-20160816; b=zF3XzhUtXZQtyVGrw3bpuh0Cja9aiOxztDznBv9ay0lVuTLj0HNmAyRUXnKqO6kaHE d5Lg21GuNdFa5jCSPKRLylyKYYuVW4nyz66oe//aoTp5j8mDEANmVsxyTL3DjXmWm92r y8vDWEXj2DrjMYzW6bNKBy5ZPbPI/Tzz/0YSYHzvtslT3d4UXiQsQSseGUyvILAzB3Zi AzwnugWwbxDaF3IQHMcReEAP9iZvJ7TEbHoyt3FqdlDqTZK1w9CFudtYaRR471wm+k1J 5p8scpMsSnM7pVnMo3SPO6un3RnueD0coh7rubFvNOSzywnouYzltQsakMRi96UmOXIB 9m6A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject; bh=3UebrHdMplypjli459rhIhoyOV7ld/tspYwHKxvhlm4=; b=KUpuau7aKUXoIYQ/MtLs3FXUMs7Pi2E0E5+5OkMHwCNo+LlRIYKFi+xCkH7jH2JMWh OIIC5WrKES7umRcoWvmBnFyY10BbSt01fDT6Vt18tyJOpiHxTw2MhKektI3tH6oXG89W Rxu+cRvDfxrgeE4eJVP3/mJi927kJPHp/64v+4uf8OHn3b7Z0WunoevWAR685Q2CDhhy XYat5XuD+mGk8rUFtVeRIMHBdfXSWpyxVkuKPBCsS52GI1zp6vurkueJ6ufCO4NIyqvG pZ7fojl5lOguUQxgYdv5HmBfq5NMrE4CZrZcPOyAMunn/fUykuZcG9BRvd1zsEQ9bJKg qt2w== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from david.siemens.de (david.siemens.de. [192.35.17.14]) by gmr-mx.google.com with ESMTPS id l20si298075wmi.2.2019.09.16.01.32.21 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Sep 2019 01:32:21 -0700 (PDT) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.14 as permitted sender) client-ip=192.35.17.14; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id x8G8WLCK026921 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 16 Sep 2019 10:32:21 +0200 Received: from [139.22.36.222] ([139.22.36.222]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id x8G8WJTm026592; Mon, 16 Sep 2019 10:32:20 +0200 Subject: Re: [PATCH] linux-custom: Control linux-libc-dev deployment manually To: Henning Schild Cc: isar-users , Cedric Hombourger References: <0600904d-7f34-875f-6bcf-6fbbfe8b9933@siemens.com> <20190916102742.284e1838@md1za8fc.ad001.siemens.net> From: Jan Kiszka Message-ID: <3ea40d5b-daab-f6a6-6bc8-c14b11a49a91@siemens.com> Date: Mon, 16 Sep 2019 10:32:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190916102742.284e1838@md1za8fc.ad001.siemens.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: RtK2ro38T1Hr 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? Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux