From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6768877611266342912 X-Received: by 2002:a05:600c:388:: with SMTP id w8mr4773910wmd.177.1576137685723; Thu, 12 Dec 2019 00:01:25 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:adf:eb4c:: with SMTP id u12ls1813573wrn.6.gmail; Thu, 12 Dec 2019 00:01:24 -0800 (PST) X-Google-Smtp-Source: APXvYqxOTKJZY0v/xmSa8XgzC2tPPwG18mA7rHIH1DcxURwCpy1KArwyq5rMfi3so9G0ovW6WLji X-Received: by 2002:adf:f2d0:: with SMTP id d16mr4842421wrp.314.1576137684936; Thu, 12 Dec 2019 00:01:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1576137684; cv=none; d=google.com; s=arc-20160816; b=GAvHhkLIfrIf/8IBC7alO1t5gQ04pr2qIMVWnVhNfY4sYSKS+Ax11C63EQjxBdLfVJ f0iR0TPD084rE5F8Dn457XNAbBwdU662LPQg2QA4JULQ3BYGmVmRQXpfJ8t/YK0Y+PlV rAl7mLcEGTsRZ2k3yxzOxGQt293MamxZ7gR/bga/NzsToWuS5iOj5uXJyj6nxqauvPLH /OlldjhZXgzrr3Bqhe8AaYAVDvQhrvveSx3yoDmgqegZMvO5rB/Zfg2irWh7XEp39Vvr GGhX4+rMZxZs/zYT6KkvWpGGtMfq9Vnmp3UngBBen+DmR5tuLs58S0U3Juw+4+2TZjIl BZVQ== 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=TfAIYHUYA5Yh7FIE8WH2yz684qTUYhA87ll1JPHNfYI=; b=kHOVyX9d9vMIV5/CpeE1a4e3dG21u8mZNUAVc09SwTJhIDMlIBX9r8/wQ0rHia9Blk PenVKia7cj3Ew50+wcK2bB1kOflSXooCKS7eujOpmZ0ND0LGVXc94Y4RQsWlBX4jfRIB 6z+4y737nvVSLSAoJb7/qp7XqkCAYJFACma7E9/S4jHcp0JZH6CnMU14NqyjAIwms4Tv 2MWLCn4UBfqRSGMk4wvXT6YVoB8wEC0NVAeMIC0dSJ9tKnIf9Z7rzW7bwa2Y/Hr99Bdi /p2f0jnrhv7ol0jwjrmTD9d5pjWL+CXVYe4LInA4yBm2pEwk1Juj4hfIPXOH9BASXMvl 4WWw== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.40 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 gecko.sbs.de (gecko.sbs.de. [194.138.37.40]) by gmr-mx.google.com with ESMTPS id u9si61191wri.3.2019.12.12.00.01.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Dec 2019 00:01:24 -0800 (PST) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.40 as permitted sender) client-ip=194.138.37.40; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.40 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 gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id xBC81OvQ021806 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 12 Dec 2019 09:01:24 +0100 Received: from [139.22.38.215] ([139.22.38.215]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id xBC81NVe015155; Thu, 12 Dec 2019 09:01:23 +0100 Subject: Re: [PATCH v5 4/5] linux-custom: rewrite to no longer depend on the kernel's builddeb To: Gylstorff Quirin , Henning Schild Cc: isar-users@googlegroups.com, Cedric Hombourger References: <79f99cd5-208c-9968-3b78-08234a206e71@siemens.com> <20191211230919.2cf24212@md1za8fc.ad001.siemens.net> From: Jan Kiszka Message-ID: <398c47ca-7e4b-5f4e-2acd-aaf9cd6c3f82@siemens.com> Date: Thu, 12 Dec 2019 09:01:22 +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: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-TUID: 99Ol2MnAq4pY On 12.12.19 08:57, Gylstorff Quirin wrote: > > > On 12/11/19 11:09 PM, Henning Schild wrote: >> On Wed, 11 Dec 2019 19:36:05 +0100 >> Jan Kiszka wrote: >> >>> 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. >> >> Yes, the check is just early catching a weird error that would have >> popped up later. That must have been either the build or the step >> copying the kernel binary to DEPLOY. >> >> If a new way of building can deal with it, the check can be dropped. >> >>> 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? >> >> I am not sure i fully get the suggestion. I think you suggest to have a >> bitbake variable control parts of the config ... that one localversion >> key in it. >> >> The user expectation would probably be that the PV will become _the_ >> version. So i would go for a sanity check for that, and a warning if >> not. After that we can discuss a magic that will turn something behind >> the first or last "-" in PV into CONFIG_LOCALVERSION and patch that >> into the config. > You mean a warning or an error? The current version aborts the build, if > the versions do not match. > > As mentioned before: If a mainline kernel is used PV == KERNEL_RELEASE > is already not fulfilled. So we already have a two expectation the > Debian user and the bitbake user. > >> >> So instead of a new variable, come up with a new recipe naming >> convention. And for people that really want to call the recipe >> "kernel.bb" they would get the default >> >> PV = "1.0" >> PR = "" >> PLOCALV = "" >> >> Would have to check if "PR" is the thing after the first "-" ... But >> maybe PR is what we are looking for ... > PR is the revision of the recipe which comes after the first "-". Yocto > uses its own variable "LINUX_VERSION_EXTENSION" which sets > CONFIG_LOCALVERSION. Then we should do s/KERNEL_LOCALVERSION/LINUX_VERSION_EXTENSION. Just leaves us with the other policy questions. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux