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

Paul Eggleton paul.eggleton at linux.intel.com
Tue Aug 9 03:22:59 UTC 2016


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



More information about the bitbake-devel mailing list