On Wed, 30 Jan 2013, Chris Larson wrote:
> 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.
i'm not in the least embarrassed to admit i didn't even know that
variable existed. and, yes, that pretty much solves the problem.
i'm still creeped out by that comment of using the tag name to deal
with rebasing a public commit, though. :-P
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
