[OE-core] "Fetcher failure: SRCREV was used yet no valid SCM was found in SRC_URI"

Chris Larson clarson at kergoth.com
Mon Dec 31 17:27:39 UTC 2012


On Mon, Dec 31, 2012 at 10:15 AM, Robert P. J. Day <rpjday at crashcourse.ca>wrote:

>   i'm sure it's something i'm doing but i'm playing with an OE
> configuration for qemuarm and experimenting with "bitbake -e" and got
> this:
>
> $ bitbake -e core-image-minimal | grep SRCREV
> ... snip ...
> # expansion of SRCPV threw ExpansionError: Failure expanding variable
> SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered
> exception FetchError: Fetcher failure: SRCREV was used yet no valid
> SCM was found in SRC_URI
> # SRCREV=INVALID
> SRCREV="INVALID"
> ... snip ...
> $
>
>   i can appreciate *why* this is happening if the fetcher code thinks
> that's a valid value for SRCREV but there's no SRC_URI value for
> core-image-minimal.
>
>   i've googled a bit and perused the code but i'm guessing someone
> else can probably see what's happening in seconds.  the above doesn't
> appear to hurt anything, but it certainly seems like a bogus error.
>

This error is raised whenever SRCPV is expanded. When not using -e, that
only occurs if you set PV to include SRCPV. When using -e, it forces
expansion of every variable, including that one. It's essentially harmless,
as -e is only useful for inspection. Were we to silence all expansion
failures when using -e, it would be easy to miss an actual harmful failure
when trying to inspect a particular variable you require, which is why we
don't do that. In this case, however, you can safely ignore it.
-- 
Christopher Larson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20121231/ded00985/attachment-0002.html>


More information about the Openembedded-core mailing list