Re: Herp-a-Derp Alert: Changes to SRCREV Unpack Wrong Version

[Martin Jansa <martin.jansa@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1812 bytes --]

On Wed, Sep 24, 2014 at 03:04:46PM -0700, Leo Schwab wrote:
> I suspect this is a common issue, but my Google-fu has gotten me no closer
> to understanding what I might be doing wrong, so here goes:
> 
> We have written recipes for various goodies -- both .bb and .bbappend forms
> -- where SRC_URI points to a Git repository, and SRCREV names a commit ID
> (not a tag or a branch name).  When we update the SRCREV to something
> newer, 'bitbake' goes through the motions of rebuilding the recipe but,
> when we look at the result, the thing it built is still the old revision.
> This is confirmed when we look at the file 'log.do_unpack' in the build
> directory, where it is clearly checking out the wrong commit ID.
> 
> I've tried fiddling around various ways with SRC_URI and SRCREV, but the
> problem persists.  All our SRC_URIs have a 'branch=' parameter, and the
> SRCREV points to a commit ID on that branch.  I've tried adding a
> 'name=blah' parameter to the SRC_URI, and then declaring SRCREV_blah, but
> that doesn't seem to help, either.  We do not do anything with ${PV} or
> ${PR} in our recipes.
> 
> In short, from where is the do_unpack step getting the SRCREV it's passing
> to 'git checkout'?  How can I trigger a rebuild using the value named in
> the recipe when SRCREV is updated?  We are using Yocto 1.6.1 (Dora).

Include SRCPV in your PV, otherwise do_fetch signature won't be changed
when you change just SRCREV so it won't update it for you.

You can also add it explicitly
do_fetch[vardeps] += "SRCREV"
but having +git${SRCPV} in PV has the advantage that you'll also see
from package name what revision was used to build it and
package management could be used to do upgrades on target.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]