From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6818960455927595008 X-Received: by 2002:a17:906:1c8c:: with SMTP id g12mr9713636ejh.456.1591379753024; Fri, 05 Jun 2020 10:55:53 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a17:907:43c0:: with SMTP id ok24ls4442265ejb.8.gmail; Fri, 05 Jun 2020 10:55:52 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyASipLDuttORSljzvZMfPqmPrthxEn5BOceUemWqm9JfFs0upjxAXDMF/CbU0FWbnh+XKJ X-Received: by 2002:a17:906:4c42:: with SMTP id d2mr10106063ejw.474.1591379752347; Fri, 05 Jun 2020 10:55:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591379752; cv=none; d=google.com; s=arc-20160816; b=k3G6/ZywQ7s+7SV8MKU+BQAAvNnamCUhEtJ2BUg1k48N96+T1OVPApAep9I+T+8rmM D78pw2K5GyN2qmSf25altvGEjyZn41A6pjgTQLj4lsVBufLBLsAFUNn2BDii7UEpvwUs prnYbDgmj8XmABM2l3SRI84thNRrcyEFPrTr27lDy2MyzO+yhhf9GdPwwK+pXP45gWZJ ZcXF582fvo/FwVU0E29Sf6cd6ygbX7K9H2E5TB6xf5agVGMnVoGXwG/+EVtjoXONpuBj OJKaOYci5bgEFkRmi+PyQiwjzZI6d/G87kJCAVzrfKBtHj7xVSmnY4KV0P1kdH53+Ob0 Txmw== 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=JAD1iuaWrvmN9XRpbJ1Wc013xSrVvvr9WnZ2jwBcRw0=; b=G1s5S+VR8R5+TwzhrQMrWUp9CimPMDMQa1YQaflqFGBVVe1Q69AkvsOYWXcpWnJIIs ebsu3ZPyGj0ehR0Whwfob/WyMcWsLSuLUmY9dI7lw5Mfm8BW95kU51fCiJ0DsQefym0L b9TBQV5T14xRCQ1FfE2dpSgywRCCHqWtku3zJLP0ny551GiIMdq2teYRsHE1kG7tsnem EkKwFLoJ1PkO5xDgW/vImvNao5rEV+2JjFV5SfObwDCyujnSlZLID1Q70FTqkRhz3xYf ojCtpw/nwR+4sczu48FdsBZCXP9GnE04Vd+a3rMp8u/QRU6Ap3rWbXA5eYTzb1DWQLHs yvng== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.39 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 lizzard.sbs.de (lizzard.sbs.de. [194.138.37.39]) by gmr-mx.google.com with ESMTPS id bt20si428396edb.2.2020.06.05.10.55.52 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jun 2020 10:55:52 -0700 (PDT) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.39 as permitted sender) client-ip=194.138.37.39; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.39 as permitted sender) smtp.mailfrom=jan.kiszka@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 lizzard.sbs.de (8.15.2/8.15.2) with ESMTPS id 055HtpnC024049 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 5 Jun 2020 19:55:52 +0200 Received: from [167.87.6.236] ([167.87.6.236]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 055HtoGp014740; Fri, 5 Jun 2020 19:55:51 +0200 Subject: Re: [PATCH] meta-isar: hello: Use in CHANGELOG_V To: Henning Schild Cc: isar-users 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> <20200605194658.74038f63@md1za8fc.ad001.siemens.net> From: Jan Kiszka Message-ID: Date: Fri, 5 Jun 2020 19:55:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200605194658.74038f63@md1za8fc.ad001.siemens.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: tKzwliDhX4+5 On 05.06.20 19:46, Henning Schild wrote: > Jan, > > this is what i talked about earlier. Not sure about the details anymore > but never got a reply. > Yes, I think I forgot to write a reply here: I think we are still (luckily) talking about two things here. One, the templating of the changelog with some "original" or whatever version is done and remains useful. The other, processing of arbitrarily versioned debian source packages is still a separate todo. What is missing to build a tracking deb package rebuilder is extraction of the debian source package to a stable path so that S can refer to that without knowing the version in advance (which would be impossible). We basically need to detect what do_apt_fetch unpacked and rename that to comply with S. Can we tell "apt-get source" which directory to create (rather than -? Didn't find anything. Jan > 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 >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux