From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6735105003214602240 X-Received: by 2002:a50:cc46:: with SMTP id n6mr3239276edi.7.1568705446218; Tue, 17 Sep 2019 00:30:46 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a17:906:564c:: with SMTP id v12ls559229ejr.4.gmail; Tue, 17 Sep 2019 00:30:45 -0700 (PDT) X-Google-Smtp-Source: APXvYqzciNZHmp7PQ+w/J0mcC8jXS8B1DVw2LAzw0mOFa+ZO92IDfbF8VNF10XprRayQ5w1SvUxb X-Received: by 2002:a17:906:c738:: with SMTP id fj24mr3491815ejb.255.1568705445674; Tue, 17 Sep 2019 00:30:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568705445; cv=none; d=google.com; s=arc-20160816; b=SuccIlxMI3gJq2jQWfyrUvAUyTBLOwgprAe4mAHxAow8RluWnH4qYEuAL5EYvCd+AL GfYiuxUSMYQ7Z82KzF+fYw/ApDLJ5EoWgLx3H/vo9JBPUfeq+zO2SAIfwESTgFyfr4Hs NxKv80i/6Yry1w866xfzNlHf2/l2lcqSG/OlblQL9bENTmh0Fji7MWUsBtVdkdJ5XQ87 TyYoTME6j49Bzxj2V0Qc3D4k0HurM4yWBcf9LRck5zasUHJCr9SLnucN13FXNfF9XHVJ IQe1l7wP5cugOUzSnGQilIMiw5O6w8fLBrIJKfpkYCBFdbM4rnam6FueB0MKNBaptj1E lNug== 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=v2VdbJ47Zaq3wx9952t/NiQG8aO/6YaxLlKSULHHwFc=; b=pvC3gXja/infLSQldMsn7ldeviQray6BKJrqZ96NKdZq5jLADfs3NasTEYfMxYrlYZ mBPrWNrAqTBnwgXDch/YFAPJDo9uzM4bWO9smxZPk4mhLhyvC6n8oNc79+vxNA1eNd5z mqM9SN+WSkomFd54bey3NW6T0VyO2eZwsbnyMKZKY+I3mMAw3Zkrrgt0ojmES/F6yjZp 2laqGMX3fCH6/i4fmem9jS3DFct0FV2bG49jkdJogbLe8wUlUHsNuuvk6L8SUzRixiFK NXIQz2F6mfmfheK5Vf6C2uRCvbkil9aK/5h/V1Z0dI2kg8vKD+YD5g2i5eK88pDB12+T cqeQ== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.2 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 thoth.sbs.de (thoth.sbs.de. [192.35.17.2]) by gmr-mx.google.com with ESMTPS id d27si397603ejt.1.2019.09.17.00.30.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Sep 2019 00:30:45 -0700 (PDT) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.2 as permitted sender) client-ip=192.35.17.2; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.2 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 thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id x8H7UihL009221 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 17 Sep 2019 09:30:44 +0200 Received: from [139.22.114.132] ([139.22.114.132]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id x8H7Uh3L023032; Tue, 17 Sep 2019 09:30:43 +0200 Subject: Re: [PATCH] linux-custom: Control linux-libc-dev deployment manually To: Claudius Heine , Henning Schild Cc: isar-users , Cedric Hombourger References: <0600904d-7f34-875f-6bcf-6fbbfe8b9933@siemens.com> <20190916102742.284e1838@md1za8fc.ad001.siemens.net> <3ea40d5b-daab-f6a6-6bc8-c14b11a49a91@siemens.com> <20190916104607.7142b22e@md1za8fc.ad001.siemens.net> <3c2c06e2-7cf3-35c1-f906-80cf2d2e2050@denx.de> From: Jan Kiszka Message-ID: <14541ed4-d325-f26a-d673-87eaa2521922@siemens.com> Date: Tue, 17 Sep 2019 09:30:43 +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: <3c2c06e2-7cf3-35c1-f906-80cf2d2e2050@denx.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: rF2svY5kh3ed On 17.09.19 09:14, Claudius Heine wrote: > Hi, > > On 16/09/2019 10.46, Henning Schild wrote: >> 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. > > Not sure about the issue with the layer priorities, but my point about > preferring a small number of feature array instead of many boolean > options are more in terms of usability from programmer and user > perspective, that they are easier to document and more in line with what > people coming form OE/YP are used to. So what are the rule for clustering features, probably not only boolean values? We only have one here, and abstracting a single case will generally lead to something that does not address the next one. Otherwise, we wait until the second case shows up and do it properly then, with backward compatibility support, of course. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux