From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6818960455927595008 X-Received: by 2002:a05:651c:318:: with SMTP id a24mr4696665ljp.55.1591431036260; Sat, 06 Jun 2020 01:10:36 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a2e:8818:: with SMTP id x24ls662377ljh.8.gmail; Sat, 06 Jun 2020 01:10:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzX5i+Yl/R9/rXZFDiufE4VSDKKsDVufyh35ViDWMcanSYx0yxFp+1NaKyuTZxxdlFoKxG1 X-Received: by 2002:a2e:960b:: with SMTP id v11mr6738914ljh.77.1591431035584; Sat, 06 Jun 2020 01:10:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591431035; cv=none; d=google.com; s=arc-20160816; b=y1X7/8b7uT6mhHwAiSFmdBflmqXXvfseW6gDpzIxt34ZfhSA1tK7T+/Bg3AYPTdmC8 11fmQ2WOjeY3B+VeBIot1mju8XlHDr0B80pH8fwJcX6gnm/ABfMyai/4vUBjaXgVjnCd KdHbeYwNLrnHlK8UpvGpHCYHr4MQHhDagY8fM8mYSdJCgwyvX6Jcb9Il3UYYlbeFMhTS ZxfVvJhEJ3/kk25apnU8nhcXcNBXYRfS24jTcpb0pazhUZu5DPmkvcuYUBq+3YeVLxn3 Xtgjd60QpMUDUcwdY+aKdmu8uGnPZPcbAvjf5YgLcewGfI8/+/tAqZF5YAifGd+DGCaH rvIA== 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=LX7T6LruGqYtyucfNcFhM7M5Wx5DFAQouEJ16Lz6PuY=; b=hX3yE26hvO1FuWSQuI3wER9JIFtB1oTynI9ELC4F8OoUEZfLL1usvHckuYu2frQ3ot 5ZlLrTdKr7YuzLQRp+Ffo/A0wlULphRCAmA+iS5ZmZE4d7jEJD38su2GD9dcKMI9aeVV DaboXcDCtcfQCiBYOhRuhxJ4V8pPKCqQewWBYxO9qf8p5XJy7rNShybt4b1kiat1Sr6z 4zJUm26tke3RGKWYtXIGQwxA5En0VOIecpPxhZtRKuAQRjUclQJuaX7ufPI1sP+Os9lA OTnu67ylHpCaqgU76LLOGWao9EGxaj6+rFRa6pyD4gKKSU5NFDp7sUixTD3YdQgge44X Ourg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.2 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 thoth.sbs.de (thoth.sbs.de. [192.35.17.2]) by gmr-mx.google.com with ESMTPS id x20si220505ljh.1.2020.06.06.01.10.35 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 06 Jun 2020 01:10:35 -0700 (PDT) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.2 as permitted sender) client-ip=192.35.17.2; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.2 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 thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id 0568AYcP025590 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Sat, 6 Jun 2020 10:10:34 +0200 Received: from md1za8fc.ad001.siemens.net ([167.87.0.201]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id 0568AYLC028888; Sat, 6 Jun 2020 10:10:34 +0200 Date: Sat, 6 Jun 2020 10:10:31 +0200 From: Henning Schild To: Jan Kiszka Cc: isar-users Subject: Re: [PATCH] meta-isar: hello: Use in CHANGELOG_V Message-ID: <20200606101031.3d5509e1@md1za8fc.ad001.siemens.net> In-Reply-To: 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> 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: VL9WEyxeM91n Am Fri, 5 Jun 2020 19:55:50 +0200 schrieb Jan Kiszka : > 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. I think it is very closely related. The version to use is always in what you fetch, no matter if you track "apt://" or "git://". So you only know it after unpack. > 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. Yes if you only use apt://PN you will have to discover what you got. In fact i am afraid you might never get tracking without a "do_cleanall_apt" inbetween consecutive runs. Because you will not download again if you have something that looks like it matches. Note that do_apt_fetch creates a directory for every URI to run in. So you can use apt://PN and apt://PN=PV and will get subdirs "PN" and "PN=PV" in. The first one is basically tracking. But in reality the others can be partial tracking if you skip revisions, apt-get source does only partially match PV. Because of that you technically always have to extract the most recent changelog entry from something that did contain a changelog ... We will probably mix up hello-2.1_debian2 with hello-2.1_debian5~6 and just call both hello-2.1-isar99 if we apt://hello=2.1 Henning > 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 > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > >