From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6818960455927595008 X-Received: by 2002:ac2:4304:: with SMTP id l4mr21309756lfh.87.1588142245296; Tue, 28 Apr 2020 23:37:25 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a05:651c:2002:: with SMTP id s2ls7405292ljo.3.gmail; Tue, 28 Apr 2020 23:37:24 -0700 (PDT) X-Google-Smtp-Source: APiQypI+DmUVmj4VD/Rdba19m65FMbrCdo6pUo537xYIqYdXFdtUPxY1FJk7mdBp2mOVMwJKAyFX X-Received: by 2002:a2e:a311:: with SMTP id l17mr19907645lje.106.1588142244615; Tue, 28 Apr 2020 23:37:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588142244; cv=none; d=google.com; s=arc-20160816; b=LILRZk3tjemTzrPbiTBsHEDuDsRcCD2UHzN1X+XhDq627lh7NlSgvYri0eYRCKgOM6 lB7LjZR4MGJmfF9S3G/zZfTxWUZPKUsf/yYhRjqxTcQLIInHEh9exCeiQLm72nxUeGH6 1J1uwI6ZNOp+cQOoAG0YQCRLCRF/OgtbfTn2EuXQzhMC/Wfe4nkE7EKjI/ozR+7d5OGy yqIjzFXNQybLh8BsdifKhu+edlpDM221qRms5NbE1V+OhrfeK5z182A0+KI2tcxFS8q4 Lg1a2i2YX8MqjsRObE/Jly4Eem7/8M/5f5szIjDTfNpFwuvK9a9JLS/pLUjFivsuX+NZ RGbg== 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=EvXm1yR5BOSVSxM4ObgxUfalrDYfwEUkhrSvwLn2xsU=; b=Cc5M0eueKE5vrMLMB07y8y9/ppl6tEa3YM2+dfR/a+VXhfEw/38QyhkHzzjlM5zjzf 6xXzYd1z0H/3JQ0thFZsQ8zrHQP2Lb8iPbEN70eDlHtcUbGr5fPbl1WXqi7CQcqVsiXx TCBMTn3bw9+zM3kNvpKpQGI3C8W8Gm6Wk6/KKE1vLaVYRxvFlI+WNBdPvHtU8rNXBOpf djndtLwZYR1XWmo0rs8vfIg3fv35AoRdRsFyQJGIH7BVdD9+8OX330RGK11V73mbUeRu 3BZbeVkXgCC8Q1CKZepWURC6Yce8qvEshNpjZmNOEWVrukjpGNlJSNHL4fbyzFF8xIii j5Bw== 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 a12si46670ljm.2.2020.04.28.23.37.24 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Apr 2020 23:37:24 -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 03T6bNSC016189 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 29 Apr 2020 08:37:23 +0200 Received: from md1za8fc.ad001.siemens.net ([167.87.51.203]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id 03T6bNNP008677; Wed, 29 Apr 2020 08:37:23 +0200 Date: Wed, 29 Apr 2020 08:37:20 +0200 From: Henning Schild To: Jan Kiszka Cc: isar-users Subject: Re: [PATCH] meta-isar: hello: Use in CHANGELOG_V Message-ID: <20200429083720.14373071@md1za8fc.ad001.siemens.net> In-Reply-To: <20200429082724.4b71ad8b@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> 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: N80+n7JZAy9C 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 > > >>> > > >> > > >> > > > > > >