| Message ID | 20250716144749.1880959-1-dmitry.baryshkov@oss.qualcomm.com |
|---|---|
| State | New |
| Headers | show |
| Series | spirv-llvm-translator: drop tag from the SRC_URI | expand |
On Wed, Jul 16, 2025 at 7:47 AM Dmitry Baryshkov via lists.openembedded.org <dmitry.baryshkov=oss.qualcomm.com@lists.openembedded.org> wrote: > It seems under some circumstances the tag in SRC_URI can prevent the > recipe from being unpacked correctly. Drop it in order to let bitbake > handle the recipe correctly. I think we should look more into underlying problem. I have seen projects create release tags that do not belong to any branches and can create fetching issues using nobranch=1 helped in such cases > > > 2025-07-16T02:15:12.1679756Z 2025-07-16 02:15:12 - ERROR - ERROR: > spirv-llvm-translator-native-20.1.4-r0 do_unpack: Bitbake Fetcher Error: > FetchError('Fetch command export PSEUDO_DISABLED=1; export > GIT_PROXY_COMMAND="oe-git-proxy"; export NO_PROXY="*"; export > PATH="/work/oe-core/scripts/native-intercept:/work/build/tmp/sysroots-uninative/x86_64-linux/usr/bin:/work/build/tmp/work/x86_64-linux/spirv-llvm-translator-native/20.1.4/recipe-sysroot-native/usr/bin/python3-native:/work/oe-core/scripts:/work/build/tmp/work/x86_64-linux/spirv-llvm-translator-native/20.1.4/recipe-sysroot-native/usr/bin/x86_64-linux:/work/build/tmp/work/x86_64-linux/spirv-llvm-translator-native/20.1.4/recipe-sysroot-native/usr/bin:/work/build/tmp/work/x86_64-linux/spirv-llvm-translator-native/20.1.4/recipe-sysroot-native/usr/sbin:/work/build/tmp/work/x86_64-linux/spirv-llvm-translator-native/20.1.4/recipe-sysroot-native/usr/bin:/work/build/tmp/work/x86_64-linux/spirv-llvm-translator-native/20.1.4/recipe-sysroot-native/sbin:/work/build/tmp/work/x86_64-linux/spirv-llvm-translator-native/20.1.4/recipe-sysroot-native/bin:/work/bitbake/bin:/work/build/tmp/hosttools"; > export HOME="/tmp/tmppvfb2ln5"; git -c gc.autoDetach=false -c > core.pager=cat -c safe.bareRepository=all -c clone.defaultRemoteName=origin > rev-list -n 1 v20.1.4 failed with exit code 128, output:\nfatal: ambiguous > argument \'v20.1.4\': unknown revision or path not in the working > tree.\nUse \'--\' to separate paths from revisions, like this:\n\'git > <command> [<revision>...] -- [<file>...]\'\n', None) > 2025-07-16T02:15:12.1686736Z 2025-07-16 02:15:12 - ERROR - ERROR: > Logfile of failure stored in: > /work/build/tmp/work/x86_64-linux/spirv-llvm-translator-native/20.1.4/temp/log.do_unpack.75654 > 2025-07-16T02:15:12.1687492Z 2025-07-16 02:15:12 - INFO - NOTE: recipe > spirv-llvm-translator-native-20.1.4-r0: task do_unpack: Failed > 2025-07-16T02:15:12.1748425Z 2025-07-16 02:15:12 - ERROR - ERROR: Task > (virtual:native:/work/build/../oe-core/meta/recipes-graphics/spir/spirv-llvm-translator_20.1.4.bb:do_unpack) > failed > > Fixes: e3890983dbf4 ("spirv-llvm-translator: upgrade 20.1.2 -> 20.1.4") > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> > --- > meta/recipes-graphics/spir/spirv-llvm-translator_20.1.4.bb | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/meta/recipes-graphics/spir/spirv-llvm-translator_20.1.4.bb > b/meta/recipes-graphics/spir/spirv-llvm-translator_20.1.4.bb > index 14e4bb74ace4..e6c6cbd69d27 100644 > --- a/meta/recipes-graphics/spir/spirv-llvm-translator_20.1.4.bb > +++ b/meta/recipes-graphics/spir/spirv-llvm-translator_20.1.4.bb > @@ -8,7 +8,7 @@ LIC_FILES_CHKSUM = > "file://LICENSE.TXT;md5=47e311aa9caedd1b3abf098bd7814d1d" > SPIRV_BRANCH = "llvm_release_${@oe.utils.trim_version('${PV}', > 1).replace('.', '')}0" > SRCREV = "74843f2186bb63b6802758222084da17fcbe603c" > SRC_URI = " \ > - git:// > github.com/KhronosGroup/SPIRV-LLVM-Translator;protocol=https;tag=v${PV};branch=${SPIRV_BRANCH} > <http://github.com/KhronosGroup/SPIRV-LLVM-Translator;protocol=https;tag=v$%7BPV%7D;branch=$%7BSPIRV_BRANCH%7D> > \ > + git:// > github.com/KhronosGroup/SPIRV-LLVM-Translator;protocol=https;branch=${SPIRV_BRANCH} > <http://github.com/KhronosGroup/SPIRV-LLVM-Translator;protocol=https;branch=$%7BSPIRV_BRANCH%7D> > \ > " > > UPSTREAM_CHECK_GITTAGREGEX = "v(?P<pver>\d+(\.\d+)+)" > -- > 2.39.5 > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#220464): > https://lists.openembedded.org/g/openembedded-core/message/220464 > Mute This Topic: https://lists.openembedded.org/mt/114186099/1997914 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [ > raj.khem@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- > >
On Wed, Jul 16, 2025 at 4:56 PM Khem Raj via lists.openembedded.org <raj.khem=gmail.com@lists.openembedded.org> wrote: > > > > On Wed, Jul 16, 2025 at 7:47 AM Dmitry Baryshkov via lists.openembedded.org <dmitry.baryshkov=oss.qualcomm.com@lists.openembedded.org> wrote: >> >> It seems under some circumstances the tag in SRC_URI can prevent the >> recipe from being unpacked correctly. Drop it in order to let bitbake >> handle the recipe correctly. > > > I think we should look more into underlying problem. I have seen projects create release tags that do not belong to any branches and can create fetching issues using nobranch=1 helped in such cases I think this happens when the git repo tarball already has the revision from SRCREV but not the tag yet. Adding tag param to SRC_URI only when upgrading the version helps in some cases, but not when the tarball was already created with the right SRCREV. The only work around which worked for us in webOS builds is enforcing to use annotated tags and using SRCREV of that annotated tag (not the SHA of the code it points to), then either both (SHA and tag) exist in the tarball or neither and the repo is updated before the tag check. v20.1.4 isn't annotated: SPIRV-LLVM-Translator $ git show-ref -d v20.1.4 74843f2186bb63b6802758222084da17fcbe603c refs/tags/v20.1.4
On 16/07/2025 17:56, Khem Raj wrote: > > > On Wed, Jul 16, 2025 at 7:47 AM Dmitry Baryshkov via > lists.openembedded.org <http://lists.openembedded.org> > <dmitry.baryshkov=oss.qualcomm.com@lists.openembedded.org > <mailto:oss.qualcomm.com@lists.openembedded.org>> wrote: > > It seems under some circumstances the tag in SRC_URI can prevent the > recipe from being unpacked correctly. Drop it in order to let bitbake > handle the recipe correctly. > > > I think we should look more into underlying problem. I have seen > projects create release tags that do not belong to any branches and can > create fetching issues using nobranch=1 helped in such cases I have no idea, because locally (and without kas) everything seems to work. I suspect this might be some mis-interaction between SRCREV, tag= and kas fetching sources. > > > > 2025-07-16T02:15:12.1679756Z 2025-07-16 02:15:12 - ERROR - ERROR: > spirv-llvm-translator-native-20.1.4-r0 do_unpack: Bitbake Fetcher > Error: FetchError('Fetch command export PSEUDO_DISABLED=1; export > GIT_PROXY_COMMAND="oe-git-proxy"; export NO_PROXY="*"; export > PATH="/work/oe-core/scripts/native-intercept:/work/build/tmp/ > sysroots-uninative/x86_64-linux/usr/bin:/work/build/tmp/work/x86_64- > linux/spirv-llvm-translator-native/20.1.4/recipe-sysroot-native/usr/ > bin/python3-native:/work/oe-core/scripts:/work/build/tmp/work/ > x86_64-linux/spirv-llvm-translator-native/20.1.4/recipe-sysroot- > native/usr/bin/x86_64-linux:/work/build/tmp/work/x86_64-linux/spirv- > llvm-translator-native/20.1.4/recipe-sysroot-native/usr/bin:/work/ > build/tmp/work/x86_64-linux/spirv-llvm-translator-native/20.1.4/ > recipe-sysroot-native/usr/sbin:/work/build/tmp/work/x86_64-linux/ > spirv-llvm-translator-native/20.1.4/recipe-sysroot-native/usr/bin:/ > work/build/tmp/work/x86_64-linux/spirv-llvm-translator- > native/20.1.4/recipe-sysroot-native/sbin:/work/build/tmp/work/ > x86_64-linux/spirv-llvm-translator-native/20.1.4/recipe-sysroot- > native/bin:/work/bitbake/bin:/work/build/tmp/hosttools"; export > HOME="/tmp/tmppvfb2ln5"; git -c gc.autoDetach=false -c > core.pager=cat -c safe.bareRepository=all -c > clone.defaultRemoteName=origin rev-list -n 1 v20.1.4 failed with > exit code 128, output:\nfatal: ambiguous argument \'v20.1.4\': > unknown revision or path not in the working tree.\nUse \'--\' to > separate paths from revisions, like this:\n\'git <command> > [<revision>...] -- [<file>...]\'\n', None) > 2025-07-16T02:15:12.1686736Z 2025-07-16 02:15:12 - ERROR - ERROR: > Logfile of failure stored in: /work/build/tmp/work/x86_64-linux/ > spirv-llvm-translator-native/20.1.4/temp/log.do_unpack.75654 > 2025-07-16T02:15:12.1687492Z 2025-07-16 02:15:12 - INFO - NOTE: > recipe spirv-llvm-translator-native-20.1.4-r0: task do_unpack: Failed > 2025-07-16T02:15:12.1748425Z 2025-07-16 02:15:12 - ERROR - ERROR: > Task (virtual:native:/work/build/../oe-core/meta/recipes-graphics/ > spir/spirv-llvm-translator_20.1.4.bb:do_unpack) failed > > Fixes: e3890983dbf4 ("spirv-llvm-translator: upgrade 20.1.2 -> 20.1.4") > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com > <mailto:dmitry.baryshkov@oss.qualcomm.com>> > --- > meta/recipes-graphics/spir/spirv-llvm-translator_20.1.4.bb > <http://spirv-llvm-translator_20.1.4.bb> | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/meta/recipes-graphics/spir/spirv-llvm- > translator_20.1.4.bb <http://spirv-llvm-translator_20.1.4.bb> b/ > meta/recipes-graphics/spir/spirv-llvm-translator_20.1.4.bb <http:// > spirv-llvm-translator_20.1.4.bb> > index 14e4bb74ace4..e6c6cbd69d27 100644 > --- a/meta/recipes-graphics/spir/spirv-llvm-translator_20.1.4.bb > <http://spirv-llvm-translator_20.1.4.bb> > +++ b/meta/recipes-graphics/spir/spirv-llvm-translator_20.1.4.bb > <http://spirv-llvm-translator_20.1.4.bb> > @@ -8,7 +8,7 @@ LIC_FILES_CHKSUM = "file:// > LICENSE.TXT;md5=47e311aa9caedd1b3abf098bd7814d1d" > SPIRV_BRANCH = "llvm_release_${@oe.utils.trim_version('${PV}', > 1).replace('.', '')}0" > SRCREV = "74843f2186bb63b6802758222084da17fcbe603c" > SRC_URI = " \ > - git://github.com/KhronosGroup/SPIRV-LLVM- > Translator;protocol=https;tag=v${PV};branch=${SPIRV_BRANCH} <http:// > github.com/KhronosGroup/SPIRV-LLVM-Translator;protocol=https;tag=v$ > %7BPV%7D;branch=$%7BSPIRV_BRANCH%7D> \ > + git://github.com/KhronosGroup/SPIRV-LLVM- > Translator;protocol=https;branch=${SPIRV_BRANCH} <http://github.com/ > KhronosGroup/SPIRV-LLVM-Translator;protocol=https;branch=$ > %7BSPIRV_BRANCH%7D> \ > " > > UPSTREAM_CHECK_GITTAGREGEX = "v(?P<pver>\d+(\.\d+)+)" > -- > 2.39.5 > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#220464): https://lists.openembedded.org/g/ > openembedded-core/message/220464 <https://lists.openembedded.org/g/ > openembedded-core/message/220464> > Mute This Topic: https://lists.openembedded.org/mt/114186099/1997914 > <https://lists.openembedded.org/mt/114186099/1997914> > Group Owner: openembedded-core+owner@lists.openembedded.org > <mailto:openembedded-core%2Bowner@lists.openembedded.org> > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/ > unsub <https://lists.openembedded.org/g/openembedded-core/unsub> > [raj.khem@gmail.com <mailto:raj.khem@gmail.com>] > -=-=-=-=-=-=-=-=-=-=-=- >
On Wed, Jul 16, 2025 at 05:14:34PM +0200, Martin Jansa wrote: > On Wed, Jul 16, 2025 at 4:56 PM Khem Raj via lists.openembedded.org > <raj.khem=gmail.com@lists.openembedded.org> wrote: > > > > > > > > On Wed, Jul 16, 2025 at 7:47 AM Dmitry Baryshkov via lists.openembedded.org <dmitry.baryshkov=oss.qualcomm.com@lists.openembedded.org> wrote: > >> > >> It seems under some circumstances the tag in SRC_URI can prevent the > >> recipe from being unpacked correctly. Drop it in order to let bitbake > >> handle the recipe correctly. > > > > > > I think we should look more into underlying problem. I have seen projects create release tags that do not belong to any branches and can create fetching issues using nobranch=1 helped in such cases > > I think this happens when the git repo tarball already has the > revision from SRCREV but not the tag yet. Most likely. I don't follow exact timeline of the repo, so it well might be possible that the tag was pushed way later than the commit. > Adding tag param to SRC_URI only when upgrading the version helps in > some cases, but not when the tarball was already created with the > right SRCREV. > > The only work around which worked for us in webOS builds is enforcing > to use annotated tags and using SRCREV of that annotated tag (not the > SHA of the code it points to), then either both (SHA and tag) exist in > the tarball or neither and the repo is updated before the tag check. This might work, but not all repos apear to be using annotated tags. Maybe we should extend bitbake to check for the tags in Fetch code too? Khem, Richard, can we please pick this patch? > > v20.1.4 isn't annotated: > SPIRV-LLVM-Translator $ git show-ref -d v20.1.4 > 74843f2186bb63b6802758222084da17fcbe603c refs/tags/v20.1.4 >
On Thu, 2025-07-17 at 16:00 +0300, Dmitry Baryshkov via lists.openembedded.org wrote: > On Wed, Jul 16, 2025 at 05:14:34PM +0200, Martin Jansa wrote: > > On Wed, Jul 16, 2025 at 4:56 PM Khem Raj via lists.openembedded.org > > <raj.khem=gmail.com@lists.openembedded.org> wrote: > > > > > > > > > > > > On Wed, Jul 16, 2025 at 7:47 AM Dmitry Baryshkov via lists.openembedded.org <dmitry.baryshkov=oss.qualcomm.com@lists.openembedded.org> wrote: > > > > > > > > It seems under some circumstances the tag in SRC_URI can prevent the > > > > recipe from being unpacked correctly. Drop it in order to let bitbake > > > > handle the recipe correctly. > > > > > > > > > I think we should look more into underlying problem. I have seen projects create release tags that do not belong to any branches and can create fetching issues using nobranch=1 helped in such cases > > > > I think this happens when the git repo tarball already has the > > revision from SRCREV but not the tag yet. > > Most likely. I don't follow exact timeline of the repo, so it well might > be possible that the tag was pushed way later than the commit. > > > Adding tag param to SRC_URI only when upgrading the version helps in > > some cases, but not when the tarball was already created with the > > right SRCREV. > > > > The only work around which worked for us in webOS builds is enforcing > > to use annotated tags and using SRCREV of that annotated tag (not the > > SHA of the code it points to), then either both (SHA and tag) exist in > > the tarball or neither and the repo is updated before the tag check. > > This might work, but not all repos apear to be using annotated tags. > Maybe we should extend bitbake to check for the tags in Fetch code too? > > Khem, Richard, can we please pick this patch? I'm not keen to start dropping tags without understanding what the issue is. The fetcher should notice things need updating and pull in the right pieces. If that isn't working, that is the issue we need to fix. Cheers, Richard
On 17/07/2025 16:17, Richard Purdie wrote: > On Thu, 2025-07-17 at 16:00 +0300, Dmitry Baryshkov via lists.openembedded.org wrote: >> On Wed, Jul 16, 2025 at 05:14:34PM +0200, Martin Jansa wrote: >>> On Wed, Jul 16, 2025 at 4:56 PM Khem Raj via lists.openembedded.org >>> <raj.khem=gmail.com@lists.openembedded.org> wrote: >>>> >>>> >>>> >>>> On Wed, Jul 16, 2025 at 7:47 AM Dmitry Baryshkov via lists.openembedded.org <dmitry.baryshkov=oss.qualcomm.com@lists.openembedded.org> wrote: >>>>> >>>>> It seems under some circumstances the tag in SRC_URI can prevent the >>>>> recipe from being unpacked correctly. Drop it in order to let bitbake >>>>> handle the recipe correctly. >>>> >>>> >>>> I think we should look more into underlying problem. I have seen projects create release tags that do not belong to any branches and can create fetching issues using nobranch=1 helped in such cases >>> >>> I think this happens when the git repo tarball already has the >>> revision from SRCREV but not the tag yet. >> >> Most likely. I don't follow exact timeline of the repo, so it well might >> be possible that the tag was pushed way later than the commit. >> >>> Adding tag param to SRC_URI only when upgrading the version helps in >>> some cases, but not when the tarball was already created with the >>> right SRCREV. >>> >>> The only work around which worked for us in webOS builds is enforcing >>> to use annotated tags and using SRCREV of that annotated tag (not the >>> SHA of the code it points to), then either both (SHA and tag) exist in >>> the tarball or neither and the repo is updated before the tag check. >> >> This might work, but not all repos apear to be using annotated tags. >> Maybe we should extend bitbake to check for the tags in Fetch code too? >> >> Khem, Richard, can we please pick this patch? > > I'm not keen to start dropping tags without understanding what the > issue is. The fetcher should notice things need updating and pull in > the right pieces. If that isn't working, that is the issue we need to > fix. If the analysys is correct, the SRCREV is present in the fetched sources, but the tag that is used in SRC_URI doesn't. So do_fetch doesn't perform any additional fetching, but the do_unpack fails as it can not find the tag. > > Cheers, > > Richard
On Thu, Jul 17, 2025 at 4:17 PM Dmitry Baryshkov via lists.openembedded.org <dmitry.baryshkov=oss.qualcomm.com@lists.openembedded.org> wrote: > > On 17/07/2025 16:17, Richard Purdie wrote: > > On Thu, 2025-07-17 at 16:00 +0300, Dmitry Baryshkov via lists.openembedded.org wrote: > >> On Wed, Jul 16, 2025 at 05:14:34PM +0200, Martin Jansa wrote: > >>> On Wed, Jul 16, 2025 at 4:56 PM Khem Raj via lists.openembedded.org > >>> <raj.khem=gmail.com@lists.openembedded.org> wrote: > >>>> > >>>> > >>>> > >>>> On Wed, Jul 16, 2025 at 7:47 AM Dmitry Baryshkov via lists.openembedded.org <dmitry.baryshkov=oss.qualcomm.com@lists.openembedded.org> wrote: > >>>>> > >>>>> It seems under some circumstances the tag in SRC_URI can prevent the > >>>>> recipe from being unpacked correctly. Drop it in order to let bitbake > >>>>> handle the recipe correctly. > >>>> > >>>> > >>>> I think we should look more into underlying problem. I have seen projects create release tags that do not belong to any branches and can create fetching issues using nobranch=1 helped in such cases > >>> > >>> I think this happens when the git repo tarball already has the > >>> revision from SRCREV but not the tag yet. > >> > >> Most likely. I don't follow exact timeline of the repo, so it well might > >> be possible that the tag was pushed way later than the commit. > >> > >>> Adding tag param to SRC_URI only when upgrading the version helps in > >>> some cases, but not when the tarball was already created with the > >>> right SRCREV. > >>> > >>> The only work around which worked for us in webOS builds is enforcing > >>> to use annotated tags and using SRCREV of that annotated tag (not the > >>> SHA of the code it points to), then either both (SHA and tag) exist in > >>> the tarball or neither and the repo is updated before the tag check. > >> > >> This might work, but not all repos apear to be using annotated tags. > >> Maybe we should extend bitbake to check for the tags in Fetch code too? > >> > >> Khem, Richard, can we please pick this patch? > > > > I'm not keen to start dropping tags without understanding what the > > issue is. The fetcher should notice things need updating and pull in > > the right pieces. If that isn't working, that is the issue we need to > > fix. > > If the analysys is correct, the SRCREV is present in the fetched > sources, but the tag that is used in SRC_URI doesn't. So do_fetch > doesn't perform any additional fetching, but the do_unpack fails as it > can not find the tag. > While it's not a full proof.. we ran a 'cleanall task of spirv-llvm-translator' on our CI which exhibited this issue in the first place, and it now builds fine, after it fetched again the tree.. > > > > Cheers, > > > > Richard > > > -- > With best wishes > Dmitry > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#220547): https://lists.openembedded.org/g/openembedded-core/message/220547 > Mute This Topic: https://lists.openembedded.org/mt/114186099/9005974 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [nicolas.dechesne@oss.qualcomm.com] > -=-=-=-=-=-=-=-=-=-=-=- >
On Thu, Jul 17, 2025 at 10:17 AM Nicolas Dechesne < nicolas.dechesne@oss.qualcomm.com> wrote: > On Thu, Jul 17, 2025 at 4:17 PM Dmitry Baryshkov via > lists.openembedded.org > <dmitry.baryshkov=oss.qualcomm.com@lists.openembedded.org> wrote: > > > > On 17/07/2025 16:17, Richard Purdie wrote: > > > On Thu, 2025-07-17 at 16:00 +0300, Dmitry Baryshkov via > lists.openembedded.org wrote: > > >> On Wed, Jul 16, 2025 at 05:14:34PM +0200, Martin Jansa wrote: > > >>> On Wed, Jul 16, 2025 at 4:56 PM Khem Raj via lists.openembedded.org > > >>> <raj.khem=gmail.com@lists.openembedded.org> wrote: > > >>>> > > >>>> > > >>>> > > >>>> On Wed, Jul 16, 2025 at 7:47 AM Dmitry Baryshkov via > lists.openembedded.org <dmitry.baryshkov= > oss.qualcomm.com@lists.openembedded.org> wrote: > > >>>>> > > >>>>> It seems under some circumstances the tag in SRC_URI can prevent > the > > >>>>> recipe from being unpacked correctly. Drop it in order to let > bitbake > > >>>>> handle the recipe correctly. > > >>>> > > >>>> > > >>>> I think we should look more into underlying problem. I have seen > projects create release tags that do not belong to any branches and can > create fetching issues using nobranch=1 helped in such cases > > >>> > > >>> I think this happens when the git repo tarball already has the > > >>> revision from SRCREV but not the tag yet. > > >> > > >> Most likely. I don't follow exact timeline of the repo, so it well > might > > >> be possible that the tag was pushed way later than the commit. > > >> > > >>> Adding tag param to SRC_URI only when upgrading the version helps in > > >>> some cases, but not when the tarball was already created with the > > >>> right SRCREV. > > >>> > > >>> The only work around which worked for us in webOS builds is enforcing > > >>> to use annotated tags and using SRCREV of that annotated tag (not the > > >>> SHA of the code it points to), then either both (SHA and tag) exist > in > > >>> the tarball or neither and the repo is updated before the tag check. > > >> > > >> This might work, but not all repos apear to be using annotated tags. > > >> Maybe we should extend bitbake to check for the tags in Fetch code > too? > > >> > > >> Khem, Richard, can we please pick this patch? > > > > > > I'm not keen to start dropping tags without understanding what the > > > issue is. The fetcher should notice things need updating and pull in > > > the right pieces. If that isn't working, that is the issue we need to > > > fix. > > > > If the analysys is correct, the SRCREV is present in the fetched > > sources, but the tag that is used in SRC_URI doesn't. So do_fetch > > doesn't perform any additional fetching, but the do_unpack fails as it > > can not find the tag. > > > > While it's not a full proof.. we ran a 'cleanall task of > spirv-llvm-translator' on our CI which exhibited this issue in the > first place, and it now builds fine, after it fetched again the tree.. I think that’s perhaps better to recreate the tarball rather than this patch > > > > > > > > Cheers, > > > > > > Richard > > > > > > -- > > With best wishes > > Dmitry > > > > -=-=-=-=-=-=-=-=-=-=-=- > > Links: You receive all messages sent to this group. > > View/Reply Online (#220547): > https://lists.openembedded.org/g/openembedded-core/message/220547 > > Mute This Topic: https://lists.openembedded.org/mt/114186099/9005974 > > Group Owner: openembedded-core+owner@lists.openembedded.org > > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [ > nicolas.dechesne@oss.qualcomm.com] > > -=-=-=-=-=-=-=-=-=-=-=- > > >
diff --git a/meta/recipes-graphics/spir/spirv-llvm-translator_20.1.4.bb b/meta/recipes-graphics/spir/spirv-llvm-translator_20.1.4.bb index 14e4bb74ace4..e6c6cbd69d27 100644 --- a/meta/recipes-graphics/spir/spirv-llvm-translator_20.1.4.bb +++ b/meta/recipes-graphics/spir/spirv-llvm-translator_20.1.4.bb @@ -8,7 +8,7 @@ LIC_FILES_CHKSUM = "file://LICENSE.TXT;md5=47e311aa9caedd1b3abf098bd7814d1d" SPIRV_BRANCH = "llvm_release_${@oe.utils.trim_version('${PV}', 1).replace('.', '')}0" SRCREV = "74843f2186bb63b6802758222084da17fcbe603c" SRC_URI = " \ - git://github.com/KhronosGroup/SPIRV-LLVM-Translator;protocol=https;tag=v${PV};branch=${SPIRV_BRANCH} \ + git://github.com/KhronosGroup/SPIRV-LLVM-Translator;protocol=https;branch=${SPIRV_BRANCH} \ " UPSTREAM_CHECK_GITTAGREGEX = "v(?P<pver>\d+(\.\d+)+)"
It seems under some circumstances the tag in SRC_URI can prevent the recipe from being unpacked correctly. Drop it in order to let bitbake handle the recipe correctly. 2025-07-16T02:15:12.1679756Z 2025-07-16 02:15:12 - ERROR - ERROR: spirv-llvm-translator-native-20.1.4-r0 do_unpack: Bitbake Fetcher Error: FetchError('Fetch command export PSEUDO_DISABLED=1; export GIT_PROXY_COMMAND="oe-git-proxy"; export NO_PROXY="*"; export PATH="/work/oe-core/scripts/native-intercept:/work/build/tmp/sysroots-uninative/x86_64-linux/usr/bin:/work/build/tmp/work/x86_64-linux/spirv-llvm-translator-native/20.1.4/recipe-sysroot-native/usr/bin/python3-native:/work/oe-core/scripts:/work/build/tmp/work/x86_64-linux/spirv-llvm-translator-native/20.1.4/recipe-sysroot-native/usr/bin/x86_64-linux:/work/build/tmp/work/x86_64-linux/spirv-llvm-translator-native/20.1.4/recipe-sysroot-native/usr/bin:/work/build/tmp/work/x86_64-linux/spirv-llvm-translator-native/20.1.4/recipe-sysroot-native/usr/sbin:/work/build/tmp/work/x86_64-linux/spirv-llvm-translator-native/20.1.4/recipe-sysroot-native/usr/bin:/work/build/tmp/work/x86_64-linux/spirv-llvm-translator-native/20.1.4/recipe-sysroot-native/sbin:/work/build/tmp/work/x86_64-linux/spirv-llvm-translator-native/20.1.4/recipe-sysroot-native/bin:/work/bitbake/bin:/work/build/tmp/hosttools"; export HOME="/tmp/tmppvfb2ln5"; git -c gc.autoDetach=false -c core.pager=cat -c safe.bareRepository=all -c clone.defaultRemoteName=origin rev-list -n 1 v20.1.4 failed with exit code 128, output:\nfatal: ambiguous argument \'v20.1.4\': unknown revision or path not in the working tree.\nUse \'--\' to separate paths from revisions, like this:\n\'git <command> [<revision>...] -- [<file>...]\'\n', None) 2025-07-16T02:15:12.1686736Z 2025-07-16 02:15:12 - ERROR - ERROR: Logfile of failure stored in: /work/build/tmp/work/x86_64-linux/spirv-llvm-translator-native/20.1.4/temp/log.do_unpack.75654 2025-07-16T02:15:12.1687492Z 2025-07-16 02:15:12 - INFO - NOTE: recipe spirv-llvm-translator-native-20.1.4-r0: task do_unpack: Failed 2025-07-16T02:15:12.1748425Z 2025-07-16 02:15:12 - ERROR - ERROR: Task (virtual:native:/work/build/../oe-core/meta/recipes-graphics/spir/spirv-llvm-translator_20.1.4.bb:do_unpack) failed Fixes: e3890983dbf4 ("spirv-llvm-translator: upgrade 20.1.2 -> 20.1.4") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> --- meta/recipes-graphics/spir/spirv-llvm-translator_20.1.4.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)