[OE-core] BB_NO_NETWORK = "1" causes fetch to fail for unnecessary u-boot parsing

[Chris Larson]

On Wed, Jan 30, 2013 at 1:27 PM, Robert P. J. Day <rpjday at crashcourse.ca>wrote:

> On Tue, 29 Jan 2013, Martin Jansa wrote:
>
> ... snip ...
>
> > It would be better to change SRCREV to hash corresponding to that
> > tag and move tag only to comment above SRCREV. Such patch could be
> > applied in upstream...
>
>   which brings up a larger issue ... what is the *preferred* way of
> doing this if one was writing a style guide?  i understand developers
> might like to set git SRCREV variables to meaningful tag names but, as
> i've learned, that really screws up the possibility of building with
> no network.  as it is, quite a few recipes set SRCREV to a hash ID for
> *precisely* that reason and, in a short comment above (as you say),
> mention the tag it corresponds to.
>
>   which brings me to what caused this annoyance in the first place --
> the meta-ti layer, which has only four recipes that use
>
>   SRCREV = <tag name>
>
> so it wouldn't be that hard to submit a patch to adjust those, but
> then there's this in
> meta-ti/recipes-kernel/linux/linux-keystone_3.6.6.bb:
>
> # The tree tends to rebase, use literal stable tags
> SRCREV = "DEV.MCSDK-03.06.06.07"
>
>   uh ... correct me if i'm wrong but isn't it in unspeakably bad taste
> to rebase commits that have already been published?
>
>   in any event, can it be considered bad form to set SRCREV to git tag
> names?  thoughts?
>

It's worth bringing up the SRCREV_POLICY variable, which lets you control
how bitbake handles caching of srcrevs. By default, it figures it needs to
get the mapping every time (value == clear, or unset), which can make sense
in certain cases. But you can tell it to go ahead and use the values it has
cached from a previous run, as well (value == cache). This can be useful if
you know you're moving into an offline state and want to prepare for it
above and beyond the -c fetchall.
-- 
Christopher Larson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20130130/95b43b69/attachment-0002.html>