15113 2023-05-04 12:35:51 +0000 Using floating tag in SRCREV results in Fetcher Error 2023-06-28 22:32:45 +0000 1 1 7 Build System, Metadata & Runtime BitBake bitbake 4.2 x86 Multiple RESOLVED NOTABUG Medium normal 4.3 1 sergiu.tainescu richard.purdie poky.bs.watcher poky.watcher randy.macleod --- --- No (bug/feature does not impact docs) oldest_to_newest 95494 0 sergiu.tainescu 2023-05-04 12:35:51 +0000 Using a floating tag in any recipe's SRCREV, either by specifying the value directly or by setting it to PV, results in the following error (used vim as quick example): ERROR: vim-9.0.1429-r0 do_fetch: Bitbake Fetcher Error: FetchError("Recipe uses a floating tag/branch 'v9.0.1429' for repo 'github.com/vim/vim.git' without a fixed SRCREV yet doesn't call bb.fetch2.get_srcrev() (use SRCPV in PV for OE).", None) The patch responsible for adding the new error is: https://lists.openembedded.org/g/bitbake-devel/topic/89051455#13338 It is unclear if this behavior is expected or not, on the one hand the discussion from the link above and the patch's description suggest that setting SRCREV to a tag instead of a full version identifier can introduce issues. On the other hand, the error message suggests that it is possible and also says "use SRCPV in PV for OE". Doing this also doesn't work and triggers a circular reference error. It seems that SRCPV which is set to bb.fetch2.get_srcrev(d) does not get expanded before fetching which triggers the fetcher error error added in _latest_revisions() 95774 1 richard.purdie 2023-06-21 12:47:51 +0000 I don't really understand the issue here. If I apply a patch like this: diff --git a/meta/recipes-support/vim/vim.inc b/meta/recipes-support/vim/vim.inc index 33ae0d80797..3b1c83a6b97 100644 --- a/meta/recipes-support/vim/vim.inc +++ b/meta/recipes-support/vim/vim.inc @@ -12,15 +12,14 @@ RSUGGESTS:${PN} = "diffutils" LICENSE = "Vim" LIC_FILES_CHKSUM = "file://LICENSE;md5=6b30ea4fa660c483b619924bc709ef99" -SRC_URI = "git://github.com/vim/vim.git;branch=master;protocol=https \ +SRC_URI = "git://github.com/vim/vim.git;branch=master;protocol=https;tag=v9.0.1592 \ file://disable_acl_header_check.patch \ file://vim-add-knob-whether-elf.h-are-checked.patch \ file://0001-src-Makefile-improve-reproducibility.patch \ file://no-path-adjust.patch \ " -PV .= ".1592" -SRCREV = "29b4c513b11deb37f0e0538df53d195f602fa42c" +PV = "9.0.1592+git${SRCPV}" # Remove when 8.3 is out UPSTREAM_VERSION_UNKNOWN = "1" it works fine? Yes, you need to put SRCPV in PV if you use a floating tag but the message is telling you to do that... 95780 2 sergiu.tainescu 2023-06-22 06:44:32 +0000 Yes, that works if setting the tag in SRC_URI but before the changes from https://lists.openembedded.org/g/bitbake-devel/topic/89051455#13338, I could set SRCREV = $PV, where PV would default to the version from the recipe's name, this worked without setting the tag in SRC_URI. Now, if I try to set SRCREV = "$PV+git${SRCPV}" as the error message would indicate and also set tag=$PV in SRC_URI, I get: bb.data_smart.ExpansionError: Failure expanding variable SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError: Fetcher failure: There are recursive references in fetcher variables, likely through SRC_URI The variable dependency chain for the failure is: SRCPV -> SRCREV -> SRCPV -> SRCREV Is the fact that the tag needs to be set explicitly and not parsed from the recipe name intentional? Was the previous usage not intended to work? 95781 3 4957 sergiu.tainescu 2023-06-22 06:45:19 +0000 Created attachment 4957 log of ExpansionError when setting SRCREV = "$PV+git${SRCPV}" 95811 4 richard.purdie 2023-06-22 15:57:45 +0000 (In reply to Sergiu Tainescu from comment #2) > Yes, that works if setting the tag in SRC_URI but before the changes from > https://lists.openembedded.org/g/bitbake-devel/topic/89051455#13338, I could > set SRCREV = $PV, where PV would default to the version from the recipe's > name, this worked without setting the tag in SRC_URI. One way or another you need to trigger the function call mentioned in the error message. If that function call is not triggered, subtle bugs occur. Those bugs were why the error message was added. The usual way of doing this is to reference SRCPV as it is set with: SRCPV = "${@bb.fetch2.get_srcrev(d)}" > Now, if I try to set SRCREV = "$PV+git${SRCPV}" as the error message would > indicate and also set tag=$PV in SRC_URI, I get: > > bb.data_smart.ExpansionError: Failure expanding variable SRCPV, expression > was ${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError: > Fetcher failure: There are recursive references in fetcher variables, likely > through SRC_URI > The variable dependency chain for the failure is: SRCPV -> SRCREV -> SRCPV > -> SRCREV That isn't surprising as you've created a circular reference where it can't expand one variable as it refers to the other. > Is the fact that the tag needs to be set explicitly and not parsed from the > recipe name intentional? Was the previous usage not intended to work? It isn't that it wasn't intended to work, the previous usage had subtle bugs where things could fail pretty badly due to the fetcher not being in a correct state (such as a build revision changing half way through a build). We added errors to make it clear when there were problems. To get the tag from a filename, I'd suggest something like: TAGFROMFILENAME = "${@bb.parse.vars_from_file(d.getVar('FILE', False),d)[1] or '1.0'}" and then reference TAGFROMFILENAME in the SRC_URI. 95815 5 sergiu.tainescu 2023-06-23 09:31:39 +0000 Everything is clear now, thank you for your time. 95833 6 richard.purdie 2023-06-28 22:32:45 +0000 Issue resolved as above. 4957 2023-06-22 06:45:19 +0000 2023-06-22 06:45:19 +0000 log of ExpansionError when setting SRCREV = "$PV+git${SRCPV}" expansion-error.log text/x-log 1865 sergiu.tainescu VHJhY2ViYWNrIChtb3N0IHJlY2VudCBjYWxsIGxhc3QpOgogIEZpbGUgIi9ob21lL3N0YWluZXNj L3dvcmtzcGFjZS95b2N0by9wb2t5L2JpdGJha2UvbGliL2JiL2RhdGFfc21hcnQucHkiLCBsaW5l IDQ2MCwgaW4gRGF0YVNtYXJ0LmV4cGFuZFdpdGhSZWZzKHM9JyR7QGJiLmZldGNoMi5nZXRfc3Jj cmV2KGQpfScsIHZhcm5hbWU9J1NSQ1BWJyk6CiAgICAgICAgICAgICAgICAgICAgIHRyeToKICAg ID4gICAgICAgICAgICAgICAgICAgIHMgPSBfX2V4cGFuZF9weXRob25fcmVnZXhwX18uc3ViKHZh cnBhcnNlLnB5dGhvbl9zdWIsIHMpCiAgICAgICAgICAgICAgICAgICAgIGV4Y2VwdCBTeW50YXhF cnJvciBhcyBlOgogIEZpbGUgIi9ob21lL3N0YWluZXNjL3dvcmtzcGFjZS95b2N0by9wb2t5L2Jp dGJha2UvbGliL2JiL2RhdGFfc21hcnQucHkiLCBsaW5lIDE1MCwgaW4gVmFyaWFibGVQYXJzZS5w eXRob25fc3ViKG1hdGNoPTxyZS5NYXRjaCBvYmplY3Q7IHNwYW49KDAsIDI3KSwgbWF0Y2g9JyR7 QGJiLmZldGNoMi5nZXRfc3JjcmV2KGQpfSc+KToKICAgICAgICAgICAgICAgICAgICAgICAgIHNl bGYuY29udGFpbnNba10udXBkYXRlKHBhcnNlci5jb250YWluc1trXSkKICAgID4gICAgICAgICAg ICB2YWx1ZSA9IHV0aWxzLmJldHRlcl9ldmFsKGNvZGVvYmosIERhdGFDb250ZXh0KHNlbGYuZCks IHsnZCcgOiBzZWxmLmR9KQogICAgICAgICAgICAgICAgIHJldHVybiBzdHIodmFsdWUpCiAgRmls ZSAiL2hvbWUvc3RhaW5lc2Mvd29ya3NwYWNlL3lvY3RvL3Bva3kvYml0YmFrZS9saWIvYmIvdXRp bHMucHkiLCBsaW5lIDQzNCwgaW4gYmV0dGVyX2V2YWwoc291cmNlPTxjb2RlIG9iamVjdCA8bW9k dWxlPiBhdCAweDdmZWI5NmNhYTJlMCwgZmlsZSAiVmFyIDxTUkNQVj4iLCBsaW5lIDE+LCBsb2Nh bHM9eydkJzogPGJiLmRhdGFfc21hcnQuRGF0YVNtYXJ0IG9iamVjdCBhdCAweDdmZWI5NTVlYTQx MD59LCBleHRyYWdsb2JhbHM9eydkJzogPGJiLmRhdGFfc21hcnQuRGF0YVNtYXJ0IG9iamVjdCBh dCAweDdmZWI5NTVlYTQxMD59KToKICAgICAgICAgICAgICAgICBjdHhbZ10gPSBleHRyYWdsb2Jh bHNbZ10KICAgID4gICAgcmV0dXJuIGV2YWwoc291cmNlLCBjdHgsIGxvY2FscykKICAgICAKICBG aWxlICJWYXIgPFNSQ1BWPiIsIGxpbmUgMSwgaW4gPG1vZHVsZT4KICBGaWxlICIvaG9tZS9zdGFp bmVzYy93b3Jrc3BhY2UveW9jdG8vcG9reS9iaXRiYWtlL2xpYi9iYi9mZXRjaDIvX19pbml0X18u cHkiLCBsaW5lIDc3MywgaW4gZ2V0X3NyY3JldihkPTxiYi5kYXRhX3NtYXJ0LkRhdGFTbWFydCBv YmplY3QgYXQgMHg3ZmViOTU1ZWE0MTA+LCBtZXRob2RfbmFtZT0nc29ydGFibGVfcmV2aXNpb24n KToKICAgICAgICAgaWYgcmVjdXJzaW9uOgogICAgPiAgICAgICAgcmFpc2UgRmV0Y2hFcnJvcigi VGhlcmUgYXJlIHJlY3Vyc2l2ZSByZWZlcmVuY2VzIGluIGZldGNoZXIgdmFyaWFibGVzLCBsaWtl bHkgdGhyb3VnaCBTUkNfVVJJIikKICAgICAgICAgZC5zZXRWYXIoIl9fQkJJTlNSQ1JFViIsIFRy dWUpCmJiLmRhdGFfc21hcnQuRXhwYW5zaW9uRXJyb3I6IEZhaWx1cmUgZXhwYW5kaW5nIHZhcmlh YmxlIFNSQ1BWLCBleHByZXNzaW9uIHdhcyAke0BiYi5mZXRjaDIuZ2V0X3NyY3JldihkKX0gd2hp Y2ggdHJpZ2dlcmVkIGV4Y2VwdGlvbiBGZXRjaEVycm9yOiBGZXRjaGVyIGZhaWx1cmU6IFRoZXJl IGFyZSByZWN1cnNpdmUgcmVmZXJlbmNlcyBpbiBmZXRjaGVyIHZhcmlhYmxlcywgbGlrZWx5IHRo cm91Z2ggU1JDX1VSSQpUaGUgdmFyaWFibGUgZGVwZW5kZW5jeSBjaGFpbiBmb3IgdGhlIGZhaWx1 cmUgaXM6IFNSQ1BWIC0+IFNSQ1JFViAtPiBTUkNQViAtPiBTUkNSRVY=