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

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

[Leo Schwab]

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

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

Thanks,
Schwab

[-- Attachment #2: Type: text/html, Size: 1460 bytes --]

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

[Burton, Ross]

On 24 September 2014 23:04, Leo Schwab <lschwab@sensity.com> wrote:
> 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 never seen this before and there's many git-based recipes in
oe-core that the fetcher appears to be working for.  Can you replicate
this behaviour with a minimal recipe that you could share?

Ross

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

[Martin Jansa]

[-- 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 --]

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

[Burton, Ross]

On 25 September 2014 00:43, Martin Jansa <martin.jansa@gmail.com> wrote:
> 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"

As SRCREV does change the fetcher behaviour, shouldn't that be the default?

Ross

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

[Khem Raj]

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

On Thursday, September 25, 2014, Burton, Ross <ross.burton@intel.com> wrote:

> On 25 September 2014 00:43, Martin Jansa <martin.jansa@gmail.com
> <javascript:;>> wrote:
> > 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"
>
> As SRCREV does change the fetcher behaviour, shouldn't that be the default?


I think it should be

>
> Ross
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org <javascript:;>
> https://lists.yoctoproject.org/listinfo/yocto
>

[-- Attachment #2: Type: text/html, Size: 1298 bytes --]