13711 2019-12-16 22:47:24 +0000 Parsing fails on externalsrc recipe containing both git and file in SRC_URI 2021-09-14 13:28:48 +0000 1 1 7 Build System, Metadata & Runtime BitBake bitbake 3.0 x86 Multiple RESOLVED WORKSFORME with backport Medium+ normal 3.4 M4 1 jon.richardson richard.purdie akuster poky.bs.watcher poky.watcher --- --- No (bug/feature does not impact docs) oldest_to_newest 85841 0 4603 jon.richardson 2019-12-16 22:47:24 +0000 Created attachment 4603 example recipe When I devtool a recipe that has both git:// and file:// in SRC_URI, SRCREV=AUTOREV, then try to build it, I get a parse error on the recipe: WARNING: /home/jon/work/yocto/nxs/poky/build/../meta-brcm/meta-datacenter/recipes-core/spdk/brcm-spdk.bb: Exception during build_dependencies for AUTOREV WARNING: /home/jon/work/yocto/nxs/poky/build/../meta-brcm/meta-datacenter/recipes-core/spdk/brcm-spdk.bb: Error during finalise of /home/jon/work/yocto/nxs/poky/build/../meta-brcm/meta-datacenter/recipes-core/spdk/brcm-spdk.bb ERROR: ExpansionError during parsing /home/jon/work/yocto/nxs/poky/build/../meta-brcm/meta-datacenter/recipes-core/spdk/brcm-spdk.bb:05:06 Traceback (most recent call last): File "Var <SRCPV>", line 1, in <module> File "/home/jon/work/yocto/nxs/poky/bitbake/lib/bb/fetch2/__init__.py", line 752, in get_srcrev(d=<bb.data_smart.DataSmart object at 0x7fb142e91dd8>, method_name='sortable_revision'): if len(scms) == 0: > raise FetchError("SRCREV was used yet no valid SCM was found in SRC_URI") bb.data_smart.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 If I comment out the file:// then it works fine. I bisected poky and came to: commit d427f58977a46f2bda4b7f30cf83793373e401d3 (refs/bisect/bad) Author: Richard Purdie <richard.purdie@linuxfoundation.org> Date: Sat Nov 2 17:57:10 2019 +0000 bitbake: fetch2: Ensure cached url data is matched to a datastore There was a weird error in OE-Core where "devtool modify virtual/kernel" was showing basehash mismatch errors. This was due to SRCPV sometimes being: AUTOINC+b867b78b50_47b80ef7bd and sometimes AUTOINC+b867b78b50_255a750d28. If I revert that I no longer see the issue. An example recipe is attached. I've simplified it as much as possible. 91396 1 richard.purdie 2021-09-14 13:28:48 +0000 I just tested this with a recipe: SUMMARY = "Storage Plane Development Kit (SPDK)" DESCRIPTION = "Storage Plane Development Kit (SPDK) provides a set of tools and libraries for writing high performance, scalable, user-mode storage applications." HOMEPAGE = "http://www.spdk.io/" LICENSE = "CLOSED" S = "${WORKDIR}/git" SRCREV = "${AUTOREV}" SRC_URI = "git://git.yoctoproject.org/pseudo;protocol=git \ file://somefile.service" do_compile() { } do_install() { } which was tweaked to use urls I could access. I tried "devtool modify" with this and it seems to work fine. If you have more details and it still fails with master, please reopen but for now, this seems to work for me. Sorry about the time it took to get to this btw. What would help a lot in future would be a test case that fails (see oe-selftest -r devtool as an example of our devtool testing). 4603 2019-12-16 22:47:24 +0000 2019-12-16 22:47:24 +0000 example recipe brcm-spdk.bb application/octet-stream 564 jon.richardson U1VNTUFSWSA9ICJTdG9yYWdlIFBsYW5lIERldmVsb3BtZW50IEtpdCAoU1BESykiCkRFU0NSSVBU SU9OID0gIlN0b3JhZ2UgUGxhbmUgRGV2ZWxvcG1lbnQgS2l0IChTUERLKSBwcm92aWRlcyBhIHNl dCBvZiB0b29scyBhbmQgbGlicmFyaWVzIGZvciB3cml0aW5nIGhpZ2ggcGVyZm9ybWFuY2UsIHNj YWxhYmxlLCB1c2VyLW1vZGUgc3RvcmFnZSBhcHBsaWNhdGlvbnMuIgpIT01FUEFHRSA9ICJodHRw Oi8vd3d3LnNwZGsuaW8vIgpMSUNFTlNFID0gIkJTRCIKTElDX0ZJTEVTX0NIS1NVTSA9ICJmaWxl Oi8vTElDRU5TRTttZDU9NzRjODYxNWIyNmJiMmU2Zjk4YWY0ZmY0OTE5Yzk5ZWQiClMgPSAiJHtX T1JLRElSfS9naXQiCgpTUkNSRVYgPSAiJHtBVVRPUkVWfSIKU1JDX1VSSSA9ICJnaXQ6Ly9zdmNj Y3hzd2dpdEBnaXQtY2N4c3cucnRwLmJyb2FkY29tLmNvbS9icmNtL3NvYy9zcGRrLmdpdDtwcm90 b2NvbD1zc2g7YnJhbmNoPWJjbS9tYXN0ZXIgXAogICAgICAgICAgZmlsZTovL3NwZGstbnZtZi10 YXJnZXQuc2VydmljZSIKCmRvX2NvbXBpbGUoKSB7Cn0KCmRvX2luc3RhbGwoKSB7Cn0K