Re: SRCREV_FORMAT breaks my builds

[Gary Thomas <gary@mlbassoc.com>]

On 01/07/2011 05:58 AM, Richard Purdie wrote:
> 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@gmail.com>  wrote:
>>> On Thu, Jan 6, 2011 at 10:06 PM, Bruce Ashfield
>>> <bruce.ashfield@gmail.com>  wrote:
>>>> On Thu, Jan 6, 2011 at 7:04 PM, Gary Thomas<gary@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.

Works for me as well.  Thanks for the quick response!

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------