[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openembedded-core
Subject:    [OE-core] BB_SRCREV_POLICY doesn't seem to work
From:       hchapman-oecore () 3gfp ! com (Harvey Chapman)
Date:       2013-01-31 19:37:23
Message-ID: FD05009A-3348-42F7-A820-3D1542D86DFD () 3gfp ! com
[Download RAW message or body]

On Jan 31, 2013, at 2:30 PM, Harvey Chapman <hchapman-oecore at 3gfp.com> wrote:

> On Jan 31, 2013, at 1:17 PM, Harvey Chapman <hchapman-oecore at 3gfp.com> wrote:
> 
> > On Jan 31, 2013, at 9:45 AM, "Robert P. J. Day" <rpjday at 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.


[prev in list] [next in list] [prev in thread] [next in thread]