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()
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...
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?
Created attachment 4957 [details] log of ExpansionError when setting SRCREV = "$PV+git${SRCPV}"
(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.
Everything is clear now, thank you for your time.
Issue resolved as above.