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

[Chris Larson]

On Wed, Jan 30, 2013 at 1:34 PM, Chris Larson <clarson at kergoth.com> wrote:

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


Erm, s/SRCREV_POLICY/BB_SRCREV_POLICY/
-- 
Christopher Larson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20130130/d6ac3cbf/attachment-0002.html>