From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6818960455927595008 X-Received: by 2002:a2e:9b4a:: with SMTP id o10mr5354232ljj.278.1591379222765; Fri, 05 Jun 2020 10:47:02 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:ac2:43bb:: with SMTP id t27ls363656lfl.3.gmail; Fri, 05 Jun 2020 10:47:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwqNYrWUzmdC1Zd+Yl9lmSJlYtva7Tm6Qp995rYdrIgGEgC3IfG5jtCwaDyY2tsOJ5H52en X-Received: by 2002:ac2:4562:: with SMTP id k2mr5964969lfm.5.1591379222023; Fri, 05 Jun 2020 10:47:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591379222; cv=none; d=google.com; s=arc-20160816; b=u7RaEmKga8ilz39r2mcBA7w9vEfMTkUtUXZsXp+KFOme6AMnMIHF2xaRQqQf/z9XQP veeVKSp2ahGqQ4kaQ56fyiY3lYAV0oQZz8y07/3sEDARQqLcCZ7y1nE0spZJkCmF0A7F FwPXdWDyO27zHYzAoiUve67iESEH0LmbZ+d6PBtuHQjr652wiWO94iH63dbE2ri+Kg4I bhqvpXqsNBQbDnxlXCwZzONNEWwZdKoJ+S9zRDCO0LjehgZkxmjXFfQbzOaCUnDAew6g +RmTcPs0tIMj0EB9tu9NvV9g+Q0nPhwpd5Ue5GERKzreqs4hlb8Esml7foMLjoKQxn7F 72qg== 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=9Htx4OqlRljlFnY8ZTFHjcoha8LrLscl50ndUiOaPKY=; b=luDMG73GB5qztMVbz6tfnHFhZruMWK6FxNWi7k/ScIQbd7HeJCG3omlA/baEIjl8Kx XWZRjDb/dR8DIZMKo05dBAVowEPoUO2noom40xy1qYsoH0P3JQQ9a3iVBU+rPnHpU80g QTnGFYkYnQ3mwGPBdbBXFGCcFDcTIQzR5wZsLiCb40GLLzeZZ80oKLcOUcD7FfmQiVgc p8LcN4iYTulEjqCCxvn2JxO7e2JS6OswAQjVYP00V/g7RJQCbsUy5EoY7cwPOPHLIjH2 TTgYPeCnG5zXwyMqfRIzyV8syh39XRA1cSUQITlT6ES9+8oLxv3afHhFvx1zAq87Mn/1 0ZEA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.28 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 goliath.siemens.de (goliath.siemens.de. [192.35.17.28]) by gmr-mx.google.com with ESMTPS id r21si189996ljp.0.2020.06.05.10.47.01 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jun 2020 10:47:02 -0700 (PDT) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.28 as permitted sender) client-ip=192.35.17.28; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.28 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 goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id 055Hl1bP016843 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 5 Jun 2020 19:47:01 +0200 Received: from md1za8fc.ad001.siemens.net ([167.87.0.201]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id 055Hl0bV018670; Fri, 5 Jun 2020 19:47:01 +0200 Date: Fri, 5 Jun 2020 19:46:58 +0200 From: Henning Schild To: Jan Kiszka Cc: isar-users Subject: Re: [PATCH] meta-isar: hello: Use in CHANGELOG_V Message-ID: <20200605194658.74038f63@md1za8fc.ad001.siemens.net> In-Reply-To: <20200429085149.60531f33@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> <20200429085149.60531f33@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: x1U2F+aB4+CW Jan, this is what i talked about earlier. Not sure about the details anymore but never got a reply. Henning Am Wed, 29 Apr 2020 08:51:49 +0200 schrieb "[ext] Henning Schild" : > 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 > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > > > >