[poky] SRCREV_FORMAT breaks my builds

[Richard Purdie]

On Thu, 2011-01-06 at 22:26 -0500, Bruce Ashfield wrote:
> On Thu, Jan 6, 2011 at 10:10 PM, Bruce Ashfield
> <bruce.ashfield at gmail.com> wrote:
> > On Thu, Jan 6, 2011 at 10:06 PM, Bruce Ashfield
> > <bruce.ashfield at gmail.com> wrote:
> >> On Thu, Jan 6, 2011 at 7:04 PM, Gary Thomas <gary at mlbassoc.com> wrote:
> >>> My system builds on the Poky meta layer (only), plus my
> >>> target layers.  As of an update today, I now get errors
> >>> parsing any package (in meta) which uses SRCREV_FORMAT.
> >>>
> >>> The error (bitback tracebacks) is attached.
> >>>
> >>> I see these recipes with SRCREV_FORMAT:
> >>>  ./meta/recipes-kernel/linux/linux-yocto-stable_git.bb:SRCREV_FORMAT =
> >>> "meta_machine"
> >>>  ./meta/recipes-kernel/linux/linux-yocto_git.bb:SRCREV_FORMAT =
> >>> "meta_machine"
> >>>  ./meta/recipes-kernel/linux-libc-headers/linux-libc-headers-yocto_git.bb:SRCREV_FORMAT
> >>> = "meta_machine"
> >>>
> >>> This error happens because I have my own machine(s) which
> >>> are not listed in poky-default-revisions.inc, such as:
> >>>  SRCREV_machine_pn-linux-yocto-stable_beagleboard ?=
> >>> "0431115c9d720fee5bb105f6a7411efb4f851d26"
> >>> adding such an entry for my machine into my distribution
> >>> files does work past the problem.
> >>
> >> Interesting. I've suffered my fair share of SRCREV pain, but this time I
> >> haven't touched anything in days, and a quick look didn't show me
> >> any suspect commits. But from the traces, it is does look to me to be
> >> another case of the fetcher going out and attempting to validate the
> >> branches in the SRC_URI of the yocto kernel.
> >>
> >> Did you try bisecting a bit to narrow down on the offending commit ?
> >> I'm not seeing it myself, but if I reproduce it here, I'll try locate what's
> >> up. There has been fetching work ongoing, but it doesn't appear to be
> >> the cause here.
> >>
> >> I may be able to drop a sane default in the recipes that will keep
> >> this working, but until I reproduce it, I can't run effective experiments.
> >> It should simply be pointing at the fallback branches and going merrily
> >> along in the build
> >>
> >> I'll continue to try and reproduce this here.
> >
> > And sure enough, I immediately saw this after hitting send. I'm having
> > a look at this now.
> 
> My first thought on this was "It must be the recent SRCPV changes", and
> sure enough, removing SRCPV from the PV of the offending recipes clears
> out the errors. Whacking SRCREV with any value in the recipes themselves
> also fixes things up, I'm going to do some test builds to see if that is the
> solution since the later processing should do the right thing with the specific
> SRCREV overrides.
> 
> I'm not seeing why this is being triggered though, it could be a combination
> of several things .. or I'm just over looking something obvious. I'm more of
> a kernel guy than a bitbake hacker at this point.
> 
> Not much help yet, but providing some extra data.

The error is caused by our recent updates to bitbake from bitbake
upstream. The behaviour of skipped tasks changed in the cache changes in
that variable expansion was still attempted for variables from skipped
recipes.

I've added this fix:

http://git.pokylinux.org/cgit.cgi/poky/commit/?id=847b717862a518746bc5e457f40760e3bd36f1db

which seems to fix the problem here for me.

Cheers,

Richard