From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk1-f194.google.com (mail-vk1-f194.google.com [209.85.221.194]) by mail.openembedded.org (Postfix) with ESMTP id 7960C7FE63 for ; Thu, 9 Jan 2020 11:26:49 +0000 (UTC) Received: by mail-vk1-f194.google.com with SMTP id w67so1870550vkf.1 for ; Thu, 09 Jan 2020 03:26:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1NbkPXdFygoGyKUsDT1kvZevbwAw4UoG8RYD7ivVAwk=; b=DgZdu+FeAWmeKPQbWoGCAeikTzxihkA4wdn333jta4jNyHUNl3Jxo1g9LIjuv7HPlq 5NWalAX8cBM4yq2Y/XGmH3RDg7/U9jRSJmq6+nNfLLMS6tSy4gvx16cBRAZ4cz5DIyzb 5+CtdheYsLp8y1VQb1WRmD3twvsGkVij/I3aSzG5dFwhXvz7MMWYf4hksOZKjnOzJkwp rUPbqTX7C+w2Rq5nkYnBQn51cfsMiKY+p4giqif5EzoxqKs8uHYt3nAuOZmi8+QPZNPK fjgjW5a0FrKM+iFOqqha86JdfwrSIqMaIDU3q91kBtGBMWXFrj1c8B5b0f2ibz9Z1Ve9 cPFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1NbkPXdFygoGyKUsDT1kvZevbwAw4UoG8RYD7ivVAwk=; b=OSzKun+/GmlxdcBvphPOx+A1hoO0uEhIXgIRJAhizjeHbyf5TWq48Zh0+czCw54NSl 9CU10c2X1g5892MVqLvTekq/WQsZxhroCrJ3JrBow9w00I/emYKj110vJ6pVqUFICttI 903JKvPLHCI7u6622YQTtifkcODYCNSN9lzGoH5UR6OOWcOQE6MVMfMTEV6cP9ahYRH6 bup04BLKIaKck/Kt/eUf0g2PZHY3vbcPExLCdRC5LBFyNNrK5S3XkNHBlSOWCAGrND7U mCXzWoQaAkRCaPuE0bgRapyHLkOrCa8AxlLEkT9MTPDt3nt4VrO95uQLATULhF7YM/nM FzwQ== X-Gm-Message-State: APjAAAX3jBT8bbpGubLRMsJj9yj3CwL3ikvIs1Ou2XFQYL528n+atecE zsvf4mnAj5eQvQq0LyTszS4W/NuXgDoSA1EnGoo/YhTuB5Q= X-Google-Smtp-Source: APXvYqykR/CZ5VOX2bMcnyvGSasGAotiGoGvAbFNhW3FvRiqI/lFVvYGPdjUroTdDsaBO6iqcCPFu5GfVgMSsL7+ifo= X-Received: by 2002:a1f:7cc2:: with SMTP id x185mr6291951vkc.1.1578569210270; Thu, 09 Jan 2020 03:26:50 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Alexander Kanavin Date: Thu, 9 Jan 2020 12:26:39 +0100 Message-ID: To: Richard Purdie Cc: Rich Persaud , OE-core Subject: Re: Looking for a way to build latest tagged releases in recipes X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 11:26:49 -0000 Content-Type: multipart/alternative; boundary="000000000000081945059bb34934" --000000000000081945059bb34934 Content-Type: text/plain; charset="UTF-8" I think you can do this with a little help from devtool: devtool upgrade component devtool finish component layer-path git add/commit layer-path bitbake component This has the added benefit of keeping things deterministic and reproducible. You can further automate these steps with help from AUH: https://git.yoctoproject.org/cgit/cgit.cgi/auto-upgrade-helper/about/ Alex On Thu, 9 Jan 2020 at 11:52, Richard Purdie < richard.purdie@linuxfoundation.org> wrote: > On Wed, 2020-01-08 at 13:10 +0100, Pascal Huerst wrote: > > I'm looking for a way in yocto to build tagged releases or actually > > to build the newest tagged release from repositories. > > > > There is a way to specify a branch or a tag in a recipe, but no way > > to always clone the newest tagged release, that I'm aware of. I > > submitted a patch to bitbake's mailing list with a proposal [1], that > > would use bitbake's `latest_versionstring()`, to always find, fetch > > and build the latest tagged release. Unfortunately there wasn't much > > of a reaction on that proposal, so I'm taking a step back, collecting > > ideas on how this could be achieved properly. > > > > Please share your ideas... > > I did look at and think a bit about your patch. The trouble for me (as > the bitbake maintainer) is that: > > a) it isn't clear/obvious from the variable name what it does (or even > from the code) > b) it adds yet more options to the fetcher which increases the test > matrix and possible ways things can break > c) the test doesn't actually test it does what its supposed to (no > check is made on which output is downloaded for a given revision) > > Some of these can be fixed, some are much harder and I can't decide if > supporting this kind of edge case is going to be an overall good thing > for the project or not. I don't want to give you false hope by fixing > c) only to say "no". > > Add in Khem's valid concerns about reproducibility and it makes it a > tough one even to give feedback on. > > If we have a ton of users saying "yes we really need this", that would > help but I haven't seen that as yet... > > Cheers, > > Richard > > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core > --000000000000081945059bb34934 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think you can do this with a little help from devto= ol:

devtool upgrade component
devtool fi= nish component layer-path
git add/commit layer-path
bit= bake component

This has the added benefit of keepi= ng things deterministic and reproducible.

You can = further automate these steps with help from AUH:
=
Alex

On Thu, 9 Jan 2020 at 11:52, Richard Purdie &= lt;richard.purdie@lin= uxfoundation.org> wrote:
On Wed, 2020-01-08 at 13:10 +0100, Pascal Huerst wrote:
> I'm looking for a way in yocto to build tagged releases or actuall= y
> to build the newest tagged release from repositories.
>
> There is a way to specify a branch or a tag in a recipe, but no way > to always clone the newest tagged release, that I'm aware of. I > submitted a patch to bitbake's mailing list with a proposal [1], t= hat
> would use bitbake's `latest_versionstring()`, to always find, fetc= h
> and build the latest tagged release. Unfortunately there wasn't mu= ch
> of a reaction on that proposal, so I'm taking a step back, collect= ing
> ideas on how this could be achieved properly.
>
> Please share your ideas...

I did look at and think a bit about your patch. The trouble for me (as
the bitbake maintainer) is that:

a) it isn't clear/obvious from the variable name what it does (or even =
=C2=A0 =C2=A0from the code)
b) it adds yet more options to the fetcher which increases the test
=C2=A0 =C2=A0matrix and possible ways things can break
c) the test doesn't actually test it does what its supposed to (no
=C2=A0 =C2=A0check is made on which output is downloaded for a given revisi= on)

Some of these can be fixed, some are much harder and I can't decide if<= br> supporting this kind of edge case is going to be an overall good thing
for the project or not. I don't want to give you false hope by fixing c) only to say "no".

Add in Khem's valid concerns about reproducibility and it makes it a tough one even to give feedback on.

If we have a ton of users saying "yes we really need this", that = would
help but I haven't seen that as yet...

Cheers,

Richard


--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailma= n/listinfo/openembedded-core
--000000000000081945059bb34934--