<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Jan 30, 2013, at 3:34 PM, Chris Larson <<a href="mailto:clarson@kergoth.com">clarson@kergoth.com</a>> wrote:</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jan 30, 2013 at 1:34 PM, Chris Larson <span dir="ltr"><<a href="mailto:clarson@kergoth.com" target="_blank">clarson@kergoth.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; "><div class="adM"><div class="h5"><div class="gmail_quote"><br></div></div></div>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.</blockquote>
</div><br>Erm, s/SRCREV_POLICY/BB_SRCREV_POLICY/<br></div></div></blockquote><div><br></div><div>So, should BB_NO_NETWORK=1 automatically set BB_SRCREV_POLICY=cache because the former implies the latter?</div><div><br></div></div></body></html>