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

[Chris Larson]

On Wed, Jan 30, 2013 at 1:37 PM, Robert P. J. Day <rpjday at crashcourse.ca>wrote:

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

Keep in mind, though, it stores it in the persist_data cache, which by
default lives inside of TMPDIR. So if you're going to set it to cache, best
move the persist dir outside of tmpdir, or just make sure you keep the
TMPDIR around.

The only reason I know the variable exists is I had to deal with this for
the Mentor Embedded Linux product releases. We wanted our engineers to be
able to point at branches, but we also wanted our customers to be able to
build without network (we ship the DL_DIR).

What we ended up doing was having our release archival process capture the
srcrev map from the persist data cache into a standalone db, ship that, and
added a class which restored that into the persist data db at the start of
a build in a new TMPDIR.  Not ideal, but got the job done for that
particular use case. For reference,
http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor/tree/classes/restore-dumped-headrevs.bbclass
does
the save/restore of the headrev map, and then we adjust our local.conf
sample we ship to set BB_SRCREV_POLICY to cache. Probably more detail than
anyone cares to know, but I'm sure we aren't the only ones that ran into
this sort of a problem, so perhaps it may be of interest.

  i'm still creeped out by that comment of using the tag name to deal
> with rebasing a public commit, though.  :-P


It depends.  There are cases where it makes sense, such as in sharing of
work which is pending upstream merge, where you might rebase each time you
submit, as long as the people cloning it are aware of the behavior of the
branch.
-- 
Christopher Larson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20130130/6cb548f3/attachment-0002.html>