All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jasper Orschulko <Jasper.Orschulko@iris-sensing.com>
To: "richard.purdie@linuxfoundation.org"
	<richard.purdie@linuxfoundation.org>,
	"openembedded-core@lists.openembedded.org"
	<openembedded-core@lists.openembedded.org>,
	"kweihmann@outlook.com" <kweihmann@outlook.com>,
	"peter.kjellerstedt@axis.com" <peter.kjellerstedt@axis.com>,
	"jasper@fancydomain.eu" <jasper@fancydomain.eu>
Cc: "martin@mko.dev" <martin@mko.dev>,
	Daniel Baumgart <Daniel.Baumgart@iris-sensing.com>,
	"bitbake-devel@lists.openembedded.org"
	<bitbake-devel@lists.openembedded.org>
Subject: Re: [bitbake-devel] [oe-core][PATCH 1/2] devtools: Initial recipe for repo 2.17.3
Date: Thu, 11 Nov 2021 10:04:38 +0000	[thread overview]
Message-ID: <c1b45d484d3f55f9522cfa85c58e2acfa7d0e3f1.camel@iris-sensing.com> (raw)
In-Reply-To: <dd07e5137044429f805caf23114a2e72@axis.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Peter,

> How do you avoid the repo wrapper fetching the repo source itself 
> and instead fetch it using the bitbake fetcher? I have seen nothing
> to that extent in the patches so far.

we don't. This recipe only installs the repo wrapper. The source code
is downloaded and installed when running `repo init`.

However, in our opinion this is not an issue. When installing repo as a
package to a target, this is the expected behaviour. The target would
only have the repo wrapper installed, just like on any other linux
distrobution. The actual usage of repo on the target is decoupled from
the bitbake build process.

When using the repo fetcher, the repo source is fetched during the
do_fetch stage by running `repo init` (when SRCREV = AUTOREV, changes
to the recipe or no previous sources available in DL_DIR). By executing
this within the "runfetchcmd" function, this also works with the usual
network features bitbake provides, e.g. proxy.
If the recipe has not changed and sources are already available from a
previous run, repo will not be rerun. As such, reproducing a build
offline is also possible.

- -- 
With best regards

Jasper Orschulko
DevOps Engineer

Tel. +49 30 58 58 14 265
Fax +49 30 58 58 14 999
Jasper.Orschulko@iris-sensing.com

• • • • • • • • • • • • • • • • • • • • • • • • • •

iris-GmbH
infrared & intelligent sensors
Schnellerstraße 1-5 | 12439 Berlin

https://iris-sensing.com/





On Wed, 2021-11-10 at 23:55 +0000, Peter Kjellerstedt wrote:
> > -----Original Message-----
> > From: bitbake-devel@lists.openembedded.org <bitbake-
> > devel@lists.openembedded.org> On Behalf Of Jasper Orschulko
> > Sent: den 9 november 2021 12:26
> > To: richard.purdie@linuxfoundation.org; openembedded-
> > core@lists.openembedded.org; kweihmann@outlook.com;
> > jasper@fancydomain.eu
> > Cc: martin@mko.dev; Daniel.Baumgart@iris-sensing.net; bitbake-
> > devel@lists.openembedded.org
> > Subject: Re: [bitbake-devel] [oe-core][PATCH 1/2] devtools: Initial
> > recipe
> > for repo 2.17.3
> > 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA256
> > 
> > Hi Richard,
> > 
> > I think our implementation of the repo fetcher checks the (what I
> > believe to be) most relevant parts of your checklist (thanks for the
> > write-up). Martin, please corrent me if I'm missing something:
> > 
> > > a) network access for sources is only expected to happen in the
> > > do_fetch step.
> > > This is not enforced or tested but is required so that we can:
> > > 
> > >  i) audit the sources used (i.e. for license/manifest reasons)
> > >  ii) support offline builds with a suitable cache
> > >  iii) allow work to continue even with downtime upstream
> > >  iv) allow for changes upstream in incompatible ways
> > >  v) allow rebuilding of the software in X years time
> > 
> > check
> > 
> > > b) network access is not expected in do_unpack
> > 
> > check
> 
> How do you avoid the repo wrapper fetching the repo source itself 
> and instead fetch it using the bitbake fetcher? I have seen nothing 
> to that extent in the patches so far.
> 
> //Peter
> 
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEE4WyPMIC5Ap4+Ooo1Ygqew07VMNUFAmGM6rUACgkQYgqew07V
MNUCIAf+MXGp9Hnfxmu+8w3BasVsP2N7ttW2FN3Zroiyr/hKrJzeq/qDQwO+/K3U
zWZJ85H6L2eTjOP8fPaHbVMRD1jUoYVpYUAE/fN64FbhCBmurVuWFrLo/u6Gy2cU
DCd3SIejXidB25EQRoS4Bfl25il1wG4iMw1pCFA6ku5rGhb8q5jvfZECf0Wuhh7X
FnMQlI3VZsSk4CakF3g88AFTLFrsQYcN2vDUskdhMfTZpuRA8duIvW4rVgOvHJQT
v07rASNR/9yzPRVkzpgPUI9Vl2LA3vEZ3Rccw3jscYHFwkzj0096DO4+jeDwyza5
fFm0dDT9HjGuzTz66c5JL8sdZZi9pw==
=AOyp
-----END PGP SIGNATURE-----

  reply	other threads:[~2021-11-11 10:04 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-05 13:31 [oe-core][PATCH 1/2] devtools: Initial recipe for repo 2.17.3 Jasper Orschulko
2021-11-05 13:31 ` [oe-core][PATCH 2/2] base.bbclass: Add sysroot deps for repo fetcher Jasper Orschulko
2021-11-05 13:35 ` [bitbake-devel] [oe-core][PATCH 1/2] devtools: Initial recipe for repo 2.17.3 Konrad Weihmann
2021-11-05 13:47   ` Jasper Orschulko
2021-11-05 14:09     ` Jasper Orschulko
2021-11-05 14:20       ` Konrad Weihmann
2021-11-05 14:53         ` Jasper Orschulko
2021-11-05 15:34         ` Jasper Orschulko
2021-11-06  9:43       ` Richard Purdie
2021-11-09 11:26         ` Jasper Orschulko
2021-11-10 12:46           ` Richard Purdie
2021-11-10 13:52             ` Jasper Orschulko
2021-11-10 16:33               ` Richard Purdie
2021-11-11 11:42                 ` Jasper Orschulko
2021-11-24 16:04                   ` Jasper Orschulko
2021-11-10 23:55           ` Peter Kjellerstedt
2021-11-11 10:04             ` Jasper Orschulko [this message]
2021-11-11 11:34               ` Peter Kjellerstedt
2021-11-11 12:10                 ` Jasper Orschulko
2021-11-11 14:11                   ` Peter Kjellerstedt
2021-11-11 15:08                     ` Jasper Orschulko
2021-11-11 19:20                       ` Alexander Kanavin
2021-11-12 12:22                         ` Jasper Orschulko
2021-11-15 12:59                         ` Jasper Orschulko
2021-11-15 13:05                           ` Alexander Kanavin
2021-11-15 13:12                             ` Jasper Orschulko
2021-11-05 14:20 ` Alexander Kanavin
2021-11-05 15:04   ` Alexander Kanavin
2021-11-05 15:24   ` Jasper Orschulko
2021-11-05 17:46     ` Alexander Kanavin
2021-11-05 18:05       ` Jasper Orschulko
2021-11-05 18:45         ` Alexander Kanavin
2021-11-05 20:32           ` Jasper Orschulko
2021-11-06  6:39             ` Alexander Kanavin
2021-11-07  9:05 ` Richard Purdie
2021-11-08 11:55   ` Jasper Orschulko
2021-11-08 12:48     ` Fwd: " Richard Purdie
2021-11-09  9:29       ` [docs] " Quentin Schulz
2021-11-09 10:40       ` Fwd: " Michael Opdenacker
2021-11-10  8:47         ` Michael Opdenacker
2021-11-11 10:49           ` Richard Purdie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c1b45d484d3f55f9522cfa85c58e2acfa7d0e3f1.camel@iris-sensing.com \
    --to=jasper.orschulko@iris-sensing.com \
    --cc=Daniel.Baumgart@iris-sensing.com \
    --cc=bitbake-devel@lists.openembedded.org \
    --cc=jasper@fancydomain.eu \
    --cc=kweihmann@outlook.com \
    --cc=martin@mko.dev \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=peter.kjellerstedt@axis.com \
    --cc=richard.purdie@linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.