From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6768877611266342912 X-Received: by 2002:adf:f604:: with SMTP id t4mr1394380wrp.33.1576089368465; Wed, 11 Dec 2019 10:36:08 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a5d:6650:: with SMTP id f16ls1365943wrw.4.gmail; Wed, 11 Dec 2019 10:36:07 -0800 (PST) X-Google-Smtp-Source: APXvYqwZwSnPoL+Wf8+QaaBPyL7r5l1fQ1Scp8AmYVonqONWwXkLRgi6Oj5FrAW+mQLhiWYqDjl3 X-Received: by 2002:adf:f2d0:: with SMTP id d16mr1388043wrp.314.1576089367480; Wed, 11 Dec 2019 10:36:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1576089367; cv=none; d=google.com; s=arc-20160816; b=dwwBJhhjuBm6pBjrzd659+E1NM8Ilhg6G+024p9hy6i/jcowyhz5HBc1fGzmBf4QD7 aACvkNrx/HXy/fGr305Ve2EPekVTwAiyr5oy7EDlbbGjr6JUMpLhSpeVMBMvhpeOS6VS +9yYUKl+/yaOfbSA6krlr+unCd8xtMIDdeWegRcsDPt0XDpRkAYMwCEJ/H6hhNOxAhZf lyea553AGI4tSv6+5gwsjJXcw0B1Ck9NeZEEicW6B8z2GK8lr5g9q33sCp7L5exZ3Us0 lA7wdnXs3W0Q/YkM6AnJhxbkyNkL5SHi0wbPDo2rjTPa2qUKfrg1I4MCJSf4araQq/NR QkpQ== 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:references:to:from:subject; bh=7WoUslSUXsy+BD+HwhafW8rjLibT96qujgvcgH4B6KM=; b=yxOn3pAZmRp4KDzCrhmFvLUyEb0yiOxEjbvzhhAXfXqKeo+VqbzjUNkP7tGanLjHXK 6ge6OijF0+bVDu89PWapENUqR2isTA+Vzav7hVVQvueEfuK6Cq3VKTQs6dQgGXeZyqCs BTbvFalxSWzYKln5FFhuqRDF+IrmpGAK51otXocqFdn+QTotRvjdHVuD1yw0gCBWyNS8 k2ypWDM+Tz3skwrQHH6qLq2gmOHQCC01746VexSgouDBxfzwD+dew0OREczyqP8rwZ91 I4ZxQyLRHnfQ6/VDVOXnAQ723dbQg0EuyoG6z1OriKeRt8MlVRDZ2c+1BDcUwTxOTAcK Mwdg== 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 r11si132206wrl.3.2019.12.11.10.36.07 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Dec 2019 10:36:07 -0800 (PST) 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 mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id xBBIa7xp005851 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 11 Dec 2019 19:36:07 +0100 Received: from [139.25.68.37] ([139.25.68.37]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id xBBIa6SR000426; Wed, 11 Dec 2019 19:36:07 +0100 Subject: Re: [PATCH v5 4/5] linux-custom: rewrite to no longer depend on the kernel's builddeb From: Jan Kiszka To: Gylstorff Quirin , isar-users@googlegroups.com, Henning Schild , Cedric Hombourger References: <79f99cd5-208c-9968-3b78-08234a206e71@siemens.com> Message-ID: Date: Wed, 11 Dec 2019 19:36:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1 MIME-Version: 1.0 In-Reply-To: <79f99cd5-208c-9968-3b78-08234a206e71@siemens.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-TUID: KlhYATJ82w83 On 11.12.19 16:43, [ext] Jan Kiszka wrote: > On 11.12.19 16:20, Gylstorff Quirin wrote: >>> +do_build() { >>> + >>> +    # Print a few things that are of particular interest >>> +    print_settings >>> + >>> +    # Process existing kernel configuration to make sure it is complete >>> +    # (use defaults for options that were not specified) >>> +    ${MAKE} O=${KERNEL_BUILD_DIR} olddefconfig prepare || exit ${?} >>> + >>> +    # Check if the recipe's PV makes sense >>> +    KR=$(${MAKE} O=${KERNEL_BUILD_DIR} -s --no-print-directory >>> kernelrelease) >>> +    eval $(grep ^CONFIG_LOCALVERSION= ${KERNEL_BUILD_DIR}/${KCONF} || >>> true) >>> +    if [ "${PV}-${KERNEL_LOCALVERSION}" != "${KR}" ]; then >>> +        echo "ERROR: Recipe version (${PV}-${KERNEL_LOCALVERSION}) >>> does not seem to match the kernelrelease (${KR})!" 1>&2 >>> +        echo "ERROR: Make sure the kernel version in your NAME/PV/PR >>> settings and/or CONFIG_LOCALVERSION are aligned" 1>&2 >>> +        exit 1 > +    fi >> >> we have some CI use case where we build the latest git release could we >> add something like this >> >> -    if [ "${PV}-${KERNEL_LOCALVERSION}" != "${KR}" ]; then >> -        echo "ERROR: Recipe version (${PV}-${KERNEL_LOCALVERSION}) does >> not seem to match the kernelrelease (${KR})!" 1>&2 >> -        echo "ERROR: Make sure the kernel version in your NAME/PV/PR >> settings and/or CONFIG_LOCALVERSION are aligned" 1>&2 >> -        exit 1 >> +    if [ "${PV}" =~ "latest" ]; then > > I suspect you wanted to suggest != "latest". > >> +        if [ "${PV}-${KERNEL_LOCALVERSION}" != "${KR}" ]; then >> +            echo "ERROR: Recipe version (${PV}-${KERNEL_LOCALVERSION}) >> does not seem to match the kernelrelease (${KR})!" 1>&2 >> +            echo "ERROR: Make sure the kernel version in your >> NAME/PV/PR settings and/or CONFIG_LOCALVERSION are aligned" 1>&2 >> +            exit 1 >> +        fi > > We need some relaxation path for the check, yes. Given the other > versioning issue, I'm still trying to build a complete picture. Looking the Henning's commit that introduced the check, it reads to me like just addressing constraints of the old build approach. The new one has a way to set LOCALVERSION from the recipe. So, what we would rather need than this hard check is the following: - optional KERNEL_LOCALVERSION - pick-up of LOCALVERSION from the kernel config for the case it was defined via the config - KERNEL_LOCALVERSION ?= "" to avoid breaking existing users needlessly That approach would both enable CONFIG_LOCALVERSION usage via own configs as well as convenient management in recipes via KERNEL_LOCALVERSION. But it has a catch: We need the LOCALVERSION information already for the templating step while dpkg_configure_kernel is part of the build. So we may be left with these options: - check if CONFIG_LOCALVERSION == KERNEL_LOCALVERSION, which is true when KERNEL_LOCALVERSION is used but could be violated when the custom config provides a LOCALVERSION while KERNEL_LOCALVERSION is empty - always override CONFIG_LOCALVERSION with KERNEL_LOCALVERSION, as in this version of the patch - may cause surprises, though - try to pick up CONFIG_LOCALVERSION early, but only from a user- provided defconfig, not from fragments or templates - maybe too unintuitive Not so easy. Thoughts? Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux