The "bitbake -e" got this error: # 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 This is because there is no SCM if we run "bitbake -e" with no args, the following patch would fix the problem. diff --git a/bitbake/lib/bb/fetch2/__init__.py b/bitbake/lib/bb/fetch2/__init__.py index 1365335..ec291ac 100644 --- a/bitbake/lib/bb/fetch2/__init__.py +++ b/bitbake/lib/bb/fetch2/__init__.py @@ -616,7 +616,11 @@ def get_srcrev(d): scms.append(u) if len(scms) == 0: - raise FetchError("SRCREV was used yet no valid SCM was found in SRC_URI") + SRCREV = d.getVar('SRCREV', True) + if SRCREV == "INVALID": + return SRCREV + else: + raise FetchError("SRCREV was used yet no valid SCM was found in SRC_URI") if len(scms) == 1 and len(urldata[scms[0]].names) == 1: autoinc, rev = urldata[scms[0]].method.sortable_revision(scms[0], urldata[scms[0]], d, urldata[scms[0]].names[0])
We intentionally need to throw this exception when an invalid SRCREV is specified to aid usability in other areas. In the -e output, the exception is simply shown as a comment, no error code is set or error raised. I'd suggest we therefore just mark this bug as WONTFIX unless there is some bigger issue I'm not seeing?
(In reply to comment #1) > We intentionally need to throw this exception when an invalid SRCREV is > specified to aid usability in other areas. In the -e output, the exception > is simply shown as a comment, no error code is set or error raised. I'd > suggest we therefore just mark this bug as WONTFIX unless there is some > bigger issue I'm not seeing? Sounds reasonable, I happened to see this error when I ran "bb show" which is similar to "bitbake -e", I will mark this bug as WONTFIX and try to fix it from "bb".