From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6768877611266342912 X-Received: by 2002:a17:906:5246:: with SMTP id y6mr6175036ejm.330.1576102165701; Wed, 11 Dec 2019 14:09:25 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a17:906:f2c6:: with SMTP id gz6ls950503ejb.3.gmail; Wed, 11 Dec 2019 14:09:24 -0800 (PST) X-Google-Smtp-Source: APXvYqyqqLVETlSl02CkYHn8nt88jNbw5AO5kQz6AHFTuxOUQhRAlCK7LlyRbwr1UCocdfufw77p X-Received: by 2002:a17:906:4d43:: with SMTP id b3mr6094542ejv.109.1576102164905; Wed, 11 Dec 2019 14:09:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1576102164; cv=none; d=google.com; s=arc-20160816; b=m0YBx5qASNYp4ZAYS5DbuLn045fgztrBxzc4uOG/OsoQGQkp7/jimiI849XY3fMnTc diNOoDPYSzfLhaUH9hP5I9vGRiKJsvBkwLEFoGHxxnSFw88hPXVsw0k8f0+8jns6w7Nu cCnA/CRzmlvUp8sGRUBMDbXr7y5IBS+uVOdwRnLtelsypLw9sffpjUYmRcAfh06cpGIp cfdPbjROgTIfmC/IGFBhz7G0wtqIrdhSyRpnNbJ2wTasUL5+cA7ru1sgENCFWq0JPXzk DIoVkve3khvnRsk5huneM7JyzTly+5VH/lKG+J9uJlnFFCsmYJEuL7gH7reS2R9DhIDT eC5A== 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=86YAOpXlLpS3Ky9n8Eyi1nk7F39iMjtvpQcBBEqpIx4=; b=SDgJIWqGaoIg3B5dsMWgTelN/4KEny9hmxthMhMyqcbYllMYRy5ksh91PdPNHHu+W1 DxkSOHwQLonvA4uFwNG0rZ7zl0+imMfsOLHe8xIjjxJe4+sXN5AFXQrm1TVLbGPYDkCZ jjDjorroFnhZ/HB5DiNSEfkSW4Huin7P59iq/MvyK1t9JYH5YWXXEqr0I/AaekvvkQfW aOXLPXWBkimKOrqc3y/ue3Hl0fziOo8rQ6TtePukXIeYwglYaSlAOfjXkMF54Ctaso7h ctik26GhetP9I9sbYQB9SqRygdFCK42docO+f4DMhxPpYbmuiM7sNsci1zpyY6cqekz8 wlEA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.14 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 david.siemens.de (david.siemens.de. [192.35.17.14]) by gmr-mx.google.com with ESMTPS id j19si172760edv.5.2019.12.11.14.09.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Dec 2019 14:09:24 -0800 (PST) Received-SPF: pass (google.com: domain of henning.schild@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 henning.schild@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=henning.schild@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 xBBM9OqJ017705 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 11 Dec 2019 23:09:24 +0100 Received: from md1za8fc.ad001.siemens.net ([167.87.32.178]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id xBBM9Nqj006886; Wed, 11 Dec 2019 23:09:24 +0100 Date: Wed, 11 Dec 2019 23:09:19 +0100 From: Henning Schild To: Jan Kiszka Cc: Gylstorff Quirin , , Cedric Hombourger Subject: Re: [PATCH v5 4/5] linux-custom: rewrite to no longer depend on the kernel's builddeb Message-ID: <20191211230919.2cf24212@md1za8fc.ad001.siemens.net> In-Reply-To: References: <79f99cd5-208c-9968-3b78-08234a206e71@siemens.com> X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-TUID: fOZECJTLjrHd 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: =20 > >>> +do_build() { > >>> + > >>> +=C2=A0=C2=A0=C2=A0 # Print a few things that are of particular inter= est > >>> +=C2=A0=C2=A0=C2=A0 print_settings > >>> + > >>> +=C2=A0=C2=A0=C2=A0 # Process existing kernel configuration to make s= ure it is > >>> complete > >>> +=C2=A0=C2=A0=C2=A0 # (use defaults for options that were not specifi= ed) > >>> +=C2=A0=C2=A0=C2=A0 ${MAKE} O=3D${KERNEL_BUILD_DIR} olddefconfig prep= are || exit > >>> ${?} + > >>> +=C2=A0=C2=A0=C2=A0 # Check if the recipe's PV makes sense > >>> +=C2=A0=C2=A0=C2=A0 KR=3D$(${MAKE} O=3D${KERNEL_BUILD_DIR} -s --no-pr= int-directory > >>> kernelrelease) > >>> +=C2=A0=C2=A0=C2=A0 eval $(grep ^CONFIG_LOCALVERSION=3D > >>> ${KERNEL_BUILD_DIR}/${KCONF} || true) > >>> +=C2=A0=C2=A0=C2=A0 if [ "${PV}-${KERNEL_LOCALVERSION}" !=3D "${KR}" = ]; then > >>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 echo "ERROR: Recipe versi= on > >>> (${PV}-${KERNEL_LOCALVERSION}) does not seem to match the > >>> kernelrelease (${KR})!" 1>&2 > >>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 echo "ERROR: Make sure th= e kernel version in your > >>> NAME/PV/PR settings and/or CONFIG_LOCALVERSION are aligned" 1>&2 > >>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 exit 1 > +=C2=A0=C2=A0=C2= =A0 fi =20 > >> > >> we have some CI use case where we build the latest git release > >> could we add something like this > >> > >> -=C2=A0=C2=A0=C2=A0 if [ "${PV}-${KERNEL_LOCALVERSION}" !=3D "${KR}" ]= ; then > >> -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 echo "ERROR: Recipe version > >> (${PV}-${KERNEL_LOCALVERSION}) does not seem to match the > >> kernelrelease (${KR})!" 1>&2 > >> -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 echo "ERROR: Make sure the= kernel version in your > >> NAME/PV/PR settings and/or CONFIG_LOCALVERSION are aligned" 1>&2 > >> -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 exit 1 > >> +=C2=A0=C2=A0=C2=A0 if [ "${PV}" =3D~ "latest" ]; then =20 > >=20 > > I suspect you wanted to suggest !=3D "latest". > > =20 > >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if [ "${PV}-${KERNEL_LOCAL= VERSION}" !=3D "${KR}" ]; then > >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ec= ho "ERROR: Recipe version > >> (${PV}-${KERNEL_LOCALVERSION}) does not seem to match the > >> kernelrelease (${KR})!" 1>&2 > >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ec= ho "ERROR: Make sure the kernel version in your > >> NAME/PV/PR settings and/or CONFIG_LOCALVERSION are aligned" 1>&2 > >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ex= it 1 > >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 fi =20 > >=20 > > We need some relaxation path for the check, yes. Given the other > > versioning issue, I'm still trying to build a complete picture. =20 >=20 > 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: >=20 > - optional KERNEL_LOCALVERSION > - pick-up of LOCALVERSION from the kernel config for the case it was > defined via the config > - KERNEL_LOCALVERSION ?=3D "" to avoid breaking existing users > needlessly >=20 > 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. >=20 > So we may be left with these options: >=20 > - check if CONFIG_LOCALVERSION =3D=3D 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 >=20 > 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. 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 =3D "1.0" PR =3D "" PLOCALV =3D "" Would have to check if "PR" is the thing after the first "-" ... But maybe PR is what we are looking for ... Henning =20 > Jan >=20