From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6818960455927595008 X-Received: by 2002:a5d:6841:: with SMTP id o1mr37292237wrw.412.1588143112917; Tue, 28 Apr 2020 23:51:52 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a5d:4605:: with SMTP id t5ls31915956wrq.6.gmail; Tue, 28 Apr 2020 23:51:52 -0700 (PDT) X-Google-Smtp-Source: APiQypIn0HHKXURD8y3rROZPexO+bbupxDi8JVi2XfcKHGmJgwcD5dWLzxGvA9gZw+8flLKJn4Zs X-Received: by 2002:a5d:6647:: with SMTP id f7mr39587577wrw.41.1588143112342; Tue, 28 Apr 2020 23:51:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588143112; cv=none; d=google.com; s=arc-20160816; b=IubN5JucpGH6MBfL4u22ez1MtYy3oCJkwstGFQVAvW2pi297AoLOdKMFuxOKdvBZLl mC/2jtndZanpwJb04027GYffU1rt3iQvt8jKocUF1YwSaienrkK/+bcA/nbaoxfORGAR yYZ3uDNO8EFRBUw4FQ7elg9P6slwUcp7pARbMgVUkYtC0LWnkIzAqMd1l09d8oMBGeGa OscrqFeUTKpoqGohcDm54VFHdWgJ2+TEKxXuJEhJ8GGMJKQuqijI7qystVaEE83HYugf kQtc8ZO6khSUVBDz+qSHjVqx6Sm7WPyYxiNHF5Ms5ibmCb0JCuYxdRrHANZ7CoheWla9 EwDA== 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=Rorl5OZY+8FnZI+9FvXcWRCGmEnUcx0tKGgs4pbL1zc=; b=dMkKwhRcVxLGLZa+trBxX2O4vKoPRBIedb8UKiLEQW5To2jNbkMKC6LZtsRFOhDjy7 tAysU6qIPUWArXd9tDOevyMVV/LECtdcKVKBQ/XGDsg3TaAGf/j0EN0EAFVzGM81I2Pr JGquOJKCgivSTWZe/rT9UsBklf3eAJqRhZat93HTGMZPtRIbG54WvBAcGRfCduvNXAic V1eNMDj/+PqbT7PIfXqEnG1ZeLsgwfvBWswBPeqvCwIBWohpyAUWb9JR6qQ2pQCxDiUB j5xXPqI60UGT9nrImoZpVqXf+QQbNm7SOE3orF97CbSdDhM6MTEJgf5vRQJA+AZBSjiB oR/g== 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 f129si28401wmf.2.2020.04.28.23.51.52 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Apr 2020 23:51:52 -0700 (PDT) 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 mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id 03T6ppte001407 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 29 Apr 2020 08:51:52 +0200 Received: from md1za8fc.ad001.siemens.net ([167.87.51.203]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id 03T6ppA8024928; Wed, 29 Apr 2020 08:51:51 +0200 Date: Wed, 29 Apr 2020 08:51:49 +0200 From: Henning Schild To: Jan Kiszka Cc: isar-users Subject: Re: [PATCH] meta-isar: hello: Use in CHANGELOG_V Message-ID: <20200429085149.60531f33@md1za8fc.ad001.siemens.net> In-Reply-To: <20200429083720.14373071@md1za8fc.ad001.siemens.net> References: <20200428180026.45a7acf4@md1za8fc.ad001.siemens.net> <4c1fbf72-b59c-9dc4-e8ff-01d0bf8f0674@siemens.com> <20200429075415.25d6d96b@md1za8fc.ad001.siemens.net> <20200429082724.4b71ad8b@md1za8fc.ad001.siemens.net> <20200429083720.14373071@md1za8fc.ad001.siemens.net> X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TUID: WhLfqvcSUl1O Hi, here some notes on a PV pattern for "tracking" - choose a pattern that bitbake can order in case of multiple recipes for one package release < master < next 2.0 < 9999 < 99999, using strings instead of numbers might not allow bitbake to order - choose a pattern that people see as "tracking" - that PV would only be used in bitbake, the DEBIAN_V would come from the code and might be partially constructed with isar patchlevels - look at how oe chooses its PV for "tracking", if it does not support that, look at gentoo - use the pattern across all recipes, no matter how they fetch Henning Am Wed, 29 Apr 2020 08:37:20 +0200 schrieb "[ext] Henning Schild" : > Am Wed, 29 Apr 2020 08:27:24 +0200 > schrieb "[ext] Henning Schild" : > > > Am Wed, 29 Apr 2020 08:10:07 +0200 > > schrieb Jan Kiszka : > > > > > On 29.04.20 07:54, Henning Schild wrote: > > > > Am Tue, 28 Apr 2020 18:01:53 +0200 > > > > schrieb Jan Kiszka : > > > > > > > >> On 28.04.20 18:00, Henning Schild wrote: > > > >>> I think with this we might be able to put everything into one > > > >>> .bb. At the moment we have the inc plus two bbs that have PV > > > >>> in their names. > > > >>> > > > >>> Taking PV from a bb filename is wrong when the inc uses > > > >>> . > > > >> > > > >> "We cannot consolidate the recipes carrying the upstream > > > >> versions, though, as that information needs to be propagated > > > >> into ${S}." > > > > > > > > I read that but did not fully understand it. If we can not do > > > > that or fully do that, does that mean the tracking of > > > > "" can not be fully implemented? Maybe we can > > > > fill the gaps or document them. To me it sounds like a > > > > "half-feature" to introduce orig-version as proposed. > > > > > > We have two problems to solve here: > > > > > > - appending to the exact debian version our own suffix when > > > patching it > > > - tracking the upstream version under which the source package > > > is extracted to so that ${S} is set correctly > > > > > > The former is addressed by my patch to debianize, for the latter > > > I'm lacking a good idea. However, that is generally not a bit > > > issue because Debian does less frequently the update of the major > > > version, often only when switching its own major release. Also, > > > patches you carry are more likely to require adjustments anyway > > > in that case. > > > > > > The problem for setting S is not the version extraction like we do > > > for the changelog. It is that this has to happen rather early - > > > but after recipe parsing where it normally happens. It would > > > require to rewrite do_apt_fetch so that it identifies the path > > > and sets S, somehow. > > > > But S can be anything, it is a temporary directory ... afaik. > > > > We have S="${WORKDIR}/git", why not have > > S="${WORKDIR}/${PN}-orig-version" ... really that string and no > > substitution later on. Or even PN-42-nobody-cares > > > > I might be wrong, got a little lost in S and D in isar and still > > have those gentoo meanings in my head. But i guess it should be the > > same as in gentoo. > > gentoo uses PV=9999 for "tracking", the real number will come out of > the code you fetch .. i.e. with git. Some packages require more 9s, > the idea is to have the tracking recipe always be the most recent. > And all those 9s tell devs in the filename that it is the tracking > one. In fact it might even be the "same" recipe there. > > https://github.com/gentoo/gentoo/blob/master/net-vpn/openconnect/openconnect-9999.ebuild > > is basically the same as > > https://github.com/gentoo/gentoo/blob/master/net-vpn/openconnect/openconnect-8.08.ebuild > > So we want to use for when we fetch with apt:// but we > might want a PV-pattern that also covers git fetching or tarball > fetching. > > I.e. in jailhouse the recipe could git fetch the tag when PV looks > like a release. And if PV looks like tracking it could take latest > master or next. Same recipe, just a different filename. > > Whatever works there should be taken for the apt://-fetcher as well, > not different PV pattern depending on the fetcher. > > Henning > > > Henning > > > > > Jan > > > > > > > > > > > Henning > > > > > > > >> Jan > > > >> > > > >>> Henning > > > >>> > > > >>> On Thu, 23 Apr 2020 19:29:11 +0200 > > > >>> Jan Kiszka wrote: > > > >>> > > > >>>> From: Jan Kiszka > > > >>>> > > > >>>> Make use of the new placeholder to append "+isar" to the > > > >>>> original version. We cannot consolidate the recipes carrying > > > >>>> the upstream versions, though, as that information needs to > > > >>>> be propagated into ${S}. > > > >>>> > > > >>>> Signed-off-by: Jan Kiszka > > > >>>> --- > > > >>>> > > > >>>> Depends on > > > >>>> https://groups.google.com/d/msgid/isar-users/ebf1ab25-74ea-b3ba-4c48-2ecac873c6f7%40siemens.com > > > >>>> > > > >>>> meta-isar/recipes-app/hello/hello.inc | 2 +- > > > >>>> 1 file changed, 1 insertion(+), 1 deletion(-) > > > >>>> > > > >>>> diff --git a/meta-isar/recipes-app/hello/hello.inc > > > >>>> b/meta-isar/recipes-app/hello/hello.inc index > > > >>>> c5f322bb..d81085d8 100644 --- > > > >>>> a/meta-isar/recipes-app/hello/hello.inc +++ > > > >>>> b/meta-isar/recipes-app/hello/hello.inc @@ -11,7 +11,7 @@ > > > >>>> inherit dpkg SRC_URI = "apt://${PN}" > > > >>>> > > > >>>> MAINTAINER = "isar-users " > > > >>>> -CHANGELOG_V = "${PV}-99+isar" > > > >>>> +CHANGELOG_V = "+isar" > > > >>>> > > > >>>> do_prepare_build() { > > > >>>> deb_add_changelog > > > >>> > > > >> > > > >> > > > > > > > > > >