On Jan 31, 2013, at 2:30 PM, Harvey Chapman <hchapman-oec...@3gfp.com> wrote:
> On Jan 31, 2013, at 1:17 PM, Harvey Chapman <hchapman-oec...@3gfp.com> wrote:
>
>> On Jan 31, 2013, at 9:45 AM, "Robert P. J. Day" <rpj...@crashcourse.ca>
>> wrote:
>>
>>> and i'm trying to build a core-image-minimal. with regular
>>> (git-allowed) net access, the build works fine. but i haven't yet
>>> found any combination of BB_SRCREV_POLICY or BB_FETCH_PREMIRRORONLY or
>>> anything else that let's me "fetchall", then disconnect from the net
>>> to do the build.
>>
>> This really seems like a bug in bitbake/lib/bb/fetch2/git.py to me. It
>> should honor BB_NO_NETWORK by trying to see if it has the tag locally before
>> it runs the ls-remote to see if the tag has changed. I was going to suggest
>> this earlier in the thread, but due to my relatively new experience with
>> layered OE and the newer bitbake, I refrained. However, I was just inside
>> that code updating the mercurial.py fetcher to actually work for file://
>> urls. At some point in the next few weeks, I'll update it further to try and
>> be on par with git.py and to at least match the functionality since
>> mercurial.py does things differently. It makes it difficult to understand
>> them both if you only know how to use one.
>
> I made some minor tweaks to git.py so _latest_revision() now respects
> BB_NO_NETWORK. However, I noticed that fetch2.latest_revision() contains:
>
> revs = bb.persist_data.persist('BB_URI_HEADREVS', d)
> key = self.generate_revision_key(url, ud, d, name)
> try:
> return revs[key]
> except KeyError:
> revs[key] = rev = self._latest_revision(url, ud, d, name)
> return rev
>
> What does BB_URI_HEADREVS do and could it be part of the solution to this
> problem?
Nevermind, found BB_URI_HEADREVS is used for BB_SRCREV_POLICY=cache.
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
