-----Original Message-----
From: Jasper Orschulko <redacted>
Sent: den 11 november 2021 11:05
To: richard.purdie@linuxfoundation.org; openembedded-
core@lists.openembedded.org; kweihmann@outlook.com; Peter Kjellerstedt
[off-list ref]; jasper@fancydomain.eu
Cc: martin@mko.dev; Daniel Baumgart <redacted>;
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 Peter,

quoted

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.

It might be how repo is designed, but it will still break the bitbake 
expectations. I.e., if I have an environment with the layers available, 
a populated DL_DIR and BB_NO_NETWORK = "1", and then disconnect the 
build host from the Internet, I should still be able to source 
oe-init-build-env for a new machine and build it. However, this means 
that only the source for the repo wrapper is available in DL_DIR. So 
when the repo wrapper executes it will try to go on the Internet to 
fetch the rest of the repo source, which will fail.

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:

quoted

quoted

-----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:

quoted

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

quoted

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-----