SRCREV_FORMAT breaks my builds

SRCREV_FORMAT breaks my builds

[Gary Thomas]

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

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.

Since I have my own machines and linux recipes, the linux-yocto
ones are not needed and indeed cause pain.  How can I ignore
them (since I want to use the poky meta layer untouched)?

Thanks

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

[-- Attachment #2: out --]
[-- Type: text/plain, Size: 10781 bytes --]

Pseudo has not been built, building this first before the main build
Loading cache...done.
Loaded 687 entries from dependency cache.
Parsing recipes...ERROR: Error evaluating '${@bb.fetch.get_srcrev(d)}'
Traceback (most recent call last):
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 117, in expandWithRefs
    s = __expand_python_regexp__.sub(varparse.python_sub, s)
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 76, in python_sub
    value = utils.better_eval(codeobj, DataContext(self.d))
  File "/tmp/poky-mlb/bitbake/lib/bb/utils.py", line 400, in better_eval
    return eval(source, _context, locals)
  File "SRCPV", line 1, in <module>
  File "/tmp/poky-mlb/bitbake/lib/bb/fetch/__init__.py", line 389, in get_srcrev
    ud.setup_localpath(d)
  File "/tmp/poky-mlb/bitbake/lib/bb/fetch/__init__.py", line 572, in setup_localpath
    self.localpath = self.method.localpath(self.url, self, d)
  File "/tmp/poky-mlb/bitbake/lib/bb/fetch/git.py", line 59, in localpath
    tag = Fetch.srcrev_internal_helper(ud, d)
  File "/tmp/poky-mlb/bitbake/lib/bb/fetch/__init__.py", line 701, in srcrev_internal_helper
    raise InvalidSRCREV("Please set SRCREV to a valid value")
InvalidSRCREV: Please set SRCREV to a valid value

ERROR: Error evaluating '${LINUX_VERSION}+git${SRCPV}'
Traceback (most recent call last):
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 116, in expandWithRefs
    s = __expand_var_regexp__.sub(varparse.var_sub, s)
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 60, in var_sub
    var = self.d.getVar(key, 1)
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 260, in getVar
    return self.expand(value, var)
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 132, in expand
    return self.expandWithRefs(s, varname).value
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 117, in expandWithRefs
    s = __expand_python_regexp__.sub(varparse.python_sub, s)
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 76, in python_sub
    value = utils.better_eval(codeobj, DataContext(self.d))
  File "/tmp/poky-mlb/bitbake/lib/bb/utils.py", line 400, in better_eval
    return eval(source, _context, locals)
  File "SRCPV", line 1, in <module>
  File "/tmp/poky-mlb/bitbake/lib/bb/fetch/__init__.py", line 389, in get_srcrev
    ud.setup_localpath(d)
  File "/tmp/poky-mlb/bitbake/lib/bb/fetch/__init__.py", line 572, in setup_localpath
    self.localpath = self.method.localpath(self.url, self, d)
  File "/tmp/poky-mlb/bitbake/lib/bb/fetch/git.py", line 59, in localpath
    tag = Fetch.srcrev_internal_helper(ud, d)
  File "/tmp/poky-mlb/bitbake/lib/bb/fetch/__init__.py", line 701, in srcrev_internal_helper
    raise InvalidSRCREV("Please set SRCREV to a valid value")
InvalidSRCREV: Please set SRCREV to a valid value

ERROR: Error evaluating 'sstate-${PN}-${MULTIMACH_ARCH}${TARGET_VENDOR}-${TARGET_OS}-${PV}-${PR}-${SSTATE_PKGARCH}-${SSTATE_VERSION}-'
Traceback (most recent call last):
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 116, in expandWithRefs
    s = __expand_var_regexp__.sub(varparse.var_sub, s)
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 60, in var_sub
    var = self.d.getVar(key, 1)
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 260, in getVar
    return self.expand(value, var)
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 132, in expand
    return self.expandWithRefs(s, varname).value
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 116, in expandWithRefs
    s = __expand_var_regexp__.sub(varparse.var_sub, s)
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 60, in var_sub
    var = self.d.getVar(key, 1)
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 260, in getVar
    return self.expand(value, var)
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 132, in expand
    return self.expandWithRefs(s, varname).value
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 117, in expandWithRefs
    s = __expand_python_regexp__.sub(varparse.python_sub, s)
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 76, in python_sub
    value = utils.better_eval(codeobj, DataContext(self.d))
  File "/tmp/poky-mlb/bitbake/lib/bb/utils.py", line 400, in better_eval
    return eval(source, _context, locals)
  File "SRCPV", line 1, in <module>
  File "/tmp/poky-mlb/bitbake/lib/bb/fetch/__init__.py", line 389, in get_srcrev
    ud.setup_localpath(d)
  File "/tmp/poky-mlb/bitbake/lib/bb/fetch/__init__.py", line 572, in setup_localpath
    self.localpath = self.method.localpath(self.url, self, d)
  File "/tmp/poky-mlb/bitbake/lib/bb/fetch/git.py", line 59, in localpath
    tag = Fetch.srcrev_internal_helper(ud, d)
  File "/tmp/poky-mlb/bitbake/lib/bb/fetch/__init__.py", line 701, in srcrev_internal_helper
    raise InvalidSRCREV("Please set SRCREV to a valid value")
InvalidSRCREV: Please set SRCREV to a valid value

ERROR: Error evaluating '${SSTATE_PKGSPEC}${BB_TASKHASH}'
Traceback (most recent call last):
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 116, in expandWithRefs
    s = __expand_var_regexp__.sub(varparse.var_sub, s)
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 60, in var_sub
    var = self.d.getVar(key, 1)
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 260, in getVar
    return self.expand(value, var)
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 132, in expand
    return self.expandWithRefs(s, varname).value
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 116, in expandWithRefs
    s = __expand_var_regexp__.sub(varparse.var_sub, s)
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 60, in var_sub
    var = self.d.getVar(key, 1)
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 260, in getVar
    return self.expand(value, var)
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 132, in expand
    return self.expandWithRefs(s, varname).value
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 116, in expandWithRefs
    s = __expand_var_regexp__.sub(varparse.var_sub, s)
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 60, in var_sub
    var = self.d.getVar(key, 1)
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 260, in getVar
    return self.expand(value, var)
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 132, in expand
    return self.expandWithRefs(s, varname).value
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 117, in expandWithRefs
    s = __expand_python_regexp__.sub(varparse.python_sub, s)
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 76, in python_sub
    value = utils.better_eval(codeobj, DataContext(self.d))
  File "/tmp/poky-mlb/bitbake/lib/bb/utils.py", line 400, in better_eval
    return eval(source, _context, locals)
  File "SRCPV", line 1, in <module>
  File "/tmp/poky-mlb/bitbake/lib/bb/fetch/__init__.py", line 389, in get_srcrev
    ud.setup_localpath(d)
  File "/tmp/poky-mlb/bitbake/lib/bb/fetch/__init__.py", line 572, in setup_localpath
    self.localpath = self.method.localpath(self.url, self, d)
  File "/tmp/poky-mlb/bitbake/lib/bb/fetch/git.py", line 59, in localpath
    tag = Fetch.srcrev_internal_helper(ud, d)
  File "/tmp/poky-mlb/bitbake/lib/bb/fetch/__init__.py", line 701, in srcrev_internal_helper
    raise InvalidSRCREV("Please set SRCREV to a valid value")
InvalidSRCREV: Please set SRCREV to a valid value

ERROR: Error evaluating '${SSTATE_PKGNAME}'
Traceback (most recent call last):
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 116, in expandWithRefs
    s = __expand_var_regexp__.sub(varparse.var_sub, s)
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 60, in var_sub
    var = self.d.getVar(key, 1)
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 260, in getVar
    return self.expand(value, var)
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 132, in expand
    return self.expandWithRefs(s, varname).value
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 116, in expandWithRefs
    s = __expand_var_regexp__.sub(varparse.var_sub, s)
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 60, in var_sub
    var = self.d.getVar(key, 1)
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 260, in getVar
    return self.expand(value, var)
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 132, in expand
    return self.expandWithRefs(s, varname).value
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 116, in expandWithRefs
    s = __expand_var_regexp__.sub(varparse.var_sub, s)
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 60, in var_sub
    var = self.d.getVar(key, 1)
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 260, in getVar
    return self.expand(value, var)
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 132, in expand
    return self.expandWithRefs(s, varname).value
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 116, in expandWithRefs
    s = __expand_var_regexp__.sub(varparse.var_sub, s)
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 60, in var_sub
    var = self.d.getVar(key, 1)
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 260, in getVar
    return self.expand(value, var)
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 132, in expand
    return self.expandWithRefs(s, varname).value
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 117, in expandWithRefs
    s = __expand_python_regexp__.sub(varparse.python_sub, s)
  File "/tmp/poky-mlb/bitbake/lib/bb/data_smart.py", line 76, in python_sub
    value = utils.better_eval(codeobj, DataContext(self.d))
  File "/tmp/poky-mlb/bitbake/lib/bb/utils.py", line 400, in better_eval
    return eval(source, _context, locals)
  File "SRCPV", line 1, in <module>
  File "/tmp/poky-mlb/bitbake/lib/bb/fetch/__init__.py", line 389, in get_srcrev
    ud.setup_localpath(d)
  File "/tmp/poky-mlb/bitbake/lib/bb/fetch/__init__.py", line 572, in setup_localpath
    self.localpath = self.method.localpath(self.url, self, d)
  File "/tmp/poky-mlb/bitbake/lib/bb/fetch/git.py", line 59, in localpath
    tag = Fetch.srcrev_internal_helper(ud, d)
  File "/tmp/poky-mlb/bitbake/lib/bb/fetch/__init__.py", line 701, in srcrev_internal_helper
    raise InvalidSRCREV("Please set SRCREV to a valid value")
InvalidSRCREV: Please set SRCREV to a valid value

ERROR: Error parsing /tmp/poky-mlb/meta/recipes-kernel/linux/linux-yocto-stable_git.bb: Please set SRCREV to a valid value
ERROR: Command execution failed: Exited with 1

Re: SRCREV_FORMAT breaks my builds

[Bruce Ashfield]

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.

Bruce

>
> Since I have my own machines and linux recipes, the linux-yocto
> ones are not needed and indeed cause pain.  How can I ignore
> them (since I want to use the poky meta layer untouched)?
>
> Thanks
>
> --
> ------------------------------------------------------------
> Gary Thomas                 |  Consulting for the
> MLB Associates              |    Embedded world
> ------------------------------------------------------------
>
> _______________________________________________
> poky mailing list
> poky@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky
>
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: SRCREV_FORMAT breaks my builds

[Bruce Ashfield]

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.

Bruce

>
> Bruce
>
>>
>> Since I have my own machines and linux recipes, the linux-yocto
>> ones are not needed and indeed cause pain.  How can I ignore
>> them (since I want to use the poky meta layer untouched)?
>>
>> Thanks
>>
>> --
>> ------------------------------------------------------------
>> Gary Thomas                 |  Consulting for the
>> MLB Associates              |    Embedded world
>> ------------------------------------------------------------
>>
>> _______________________________________________
>> poky mailing list
>> poky@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/poky
>>
>>
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end"
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: SRCREV_FORMAT breaks my builds

[Bruce Ashfield]

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.

Cheers,

Bruce

>
> Bruce
>
>>
>> Bruce
>>
>>>
>>> Since I have my own machines and linux recipes, the linux-yocto
>>> ones are not needed and indeed cause pain.  How can I ignore
>>> them (since I want to use the poky meta layer untouched)?
>>>
>>> Thanks
>>>
>>> --
>>> ------------------------------------------------------------
>>> Gary Thomas                 |  Consulting for the
>>> MLB Associates              |    Embedded world
>>> ------------------------------------------------------------
>>>
>>> _______________________________________________
>>> poky mailing list
>>> poky@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/poky
>>>
>>>
>>
>>
>>
>> --
>> "Thou shalt not follow the NULL pointer, for chaos and madness await
>> thee at its end"
>>
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end"
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: 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@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.

Cheers,

Richard

Re: SRCREV_FORMAT breaks my builds

[Gary Thomas]

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

Re: SRCREV_FORMAT breaks my builds

[Chris Larson]

On Fri, Jan 7, 2011 at 5:58 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> 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.

Well spotted, thanks.  I'll go ahead and apply to upstream master as
well, unless you'd like to do so.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

Re: SRCREV_FORMAT breaks my builds

[Richard Purdie]

On Fri, 2011-01-07 at 07:44 -0700, Chris Larson wrote:
> On Fri, Jan 7, 2011 at 5:58 AM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > 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.
> 
> Well spotted, thanks.  I'll go ahead and apply to upstream master as
> well, unless you'd like to do so.

Just to follow up for the benefit of the mailing list, I didn't like my
ugly fix, Chris found a neater way to do it and both bitbake upstream
and poky now have the neater version of the fix.

Cheers,

Richard