[bitbake-devel] [PATCH] BB_NO_NETWORK: Fallback to local source for git lsremote

[Tobias Hagelborn]

Thanks for the tip Paul,

I was not aware of this support-script.
This is a good workaround in the current Bitbake environment.

We strive to make it easier for our users to continue building if going offline and as such a step, I will submit a new patchset with some optional flag to use local tags (so that no unexpected side-effect is default in a-action). This since it would be a little less overhead/steps to take when building offline.

Cheers,
Tobias


________________________________________
From: Paul Eggleton <paul.eggleton at linux.intel.com>
Sent: Tuesday, August 9, 2016 5:22 AM
To: bitbake-devel at lists.openembedded.org
Cc: Khem Raj; Jérémy Rosen; Tobias Hagelborn; Richard Purdie
Subject: Re: [bitbake-devel] [PATCH] BB_NO_NETWORK: Fallback to local source for git lsremote

On Mon, 08 Aug 2016 08:35:38 Khem Raj wrote:
> > On Aug 8, 2016, at 4:24 AM, Jérémy Rosen <jeremy.rosen at smile.fr> wrote:
> >
> > On 08/08/2016 11:55, Richard Purdie wrote:
> >> On Mon, 2016-08-08 at 08:34 +0000, Tobias Hagelborn wrote:
> >>> Change made to enable building offline also with git tag references
> >>> in SRC_URI.
> >>>
> >>> If BB_NO_NETWORK is set, fallback to search for tags and revisions
> >>> in local DL_DIR / GITDIR in order to avoid network access.
> >>
> >> I'm not sure I agree with this since you'd get different build results
> >> depending on whether BB_NO_NETWORK is set or not.
> >>
> >> I think if BB_NO_NETWORK is set, its reasonable to assume that the
> >> configuration should be locked down and that BB_NO_NETWORK should not
> >> have other side effects like this.
> >>
> >> It would also make it very hard to detect unlocked configurations
> >> during testing which currently are quite easily identified.
> >
> > To be honest, this is a real world problem I have on a regular basis...
> >
> > The problem we have is that our customers want to keep an archive for
> > (very) long term support and they test offline mode.
> >
> > This problem means that we have to set all our SRC_URI to git SHA instead
> > of the much more readable and easy to check git tags.
> >
> >
> > you think to assume that a reference is a branch, but the real-life
> > problem is when reference is a tag. Tag don't move so this is a case of
> > locked configuration, but i'm not sure how to handle it.
> >
> > Is there a way to have the best of both world somehow ?
>
> Don’t use tags instead rely on SHA numbers in SRCREV and use
> BB_GENERATE_MIRROR_TARBALLS like mentioned here
>
> https://wiki.yoctoproject.org/wiki/How_do_I#Q:_How_do_I_create_my_own_source
> _download_mirror_.3F
>
> tags are floating types in git, you can not use them reliably.
> You may tool in a method to automate updating the
> recipes SRCREVs if you dont want to do it by hand.
>
> That should help hopefully

FYI, another way to handle this is to enable buildhistory, run your build and
then use the buildhistory-collect-srcrevs script. This will produce output
that you can save to .inc file that will lock down the SRCREV values to exact
hashes, which you can then include and commit with your sources. This allows
you to keep your tags and even ${AUTOREV} if you want within each of your
recipes and still have everything locked down for future reproducibility.

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre