Am Samstag, dem 09.03.2024 um 13:04 -0800 schrieb Bruce Ashfield:
> On Sat, Mar 9, 2024 at 12:58 PM <max.oss...@gmail.com> wrote:
> >
> > From: Max Krummenacher <max.krummenac...@toradex.com>
> >
> > Hello
> >
> > If one builds a kernel using AUTOREV invoking bitbake only works once.
> > Any subsequent bitbake invocation fails parsing the meta data.
> >
> > Reproducable with:
> > - latest poky, b5624ee564
> > - Kernel with SRCREV = "AUTOREV", e.g. in local.conf
> > `SRCREV_machine:pn-linux-yocto:forcevariable = "${AUTOREV}"`
> > - bitbake virtual/kernel; bitbake virtual/kernel
> >
> > On the second invocation parsing fails when the fetcher tries to
> > evaluate the latest SRCREV:
> >
> > > ERROR: ExpansionError during parsing
> > > meta/recipes-kernel/linux/linux-yocto_6.6.bb
> > > Traceback (most recent call last):
> > > File "bitbake/lib/bb/fetch2/__init__.py", line 1245, in
> > > srcrev_internal_helper(ud=<bb.fetch2.FetchData object at 0x7f8e26f5f290>,
> > > d=<bb.data_smart.DataSmart object at 0x7f8e26195890>, name='machine'):
> > > d.setVar("__BBAUTOREV_ACTED_UPON", True)
> > > > srcrev = ud.method.latest_revision(ud, d, name)
> > >
> > > File "bitbake/lib/bb/fetch2/__init__.py", line 1667, in
> > > Git.latest_revision(ud=<bb.fetch2.FetchData object at 0x7f8e26f5f290>,
> > > d=<bb.data_smart.DataSmart object at 0x7f8e26195890>, name='machine'):
> > > except KeyError:
> > > > revs[key] = rev = self._latest_revision(ud, d, name)
> > > return rev
> > > File "bitbake/lib/bb/fetch2/git.py", line 850, in
> > > Git._latest_revision(ud=<bb.fetch2.FetchData object at 0x7f8e26f5f290>,
> > > d=<bb.data_smart.DataSmart object at 0x7f8e26195890>, name='machine'):
> > >
> > > > output = self._lsremote(ud, d, "")
> > > # Tags of the form ^{} may not work, need to fallback to
> > > other form
> > > File "bitbake/lib/bb/fetch2/git.py", line 833, in
> > > Git._lsremote(ud=<bb.fetch2.FetchData object at 0x7f8e26f5f290>,
> > > d=<bb.data_smart.DataSmart object at 0x7f8e26195890>, search=''):
> > > bb.fetch2.check_network_access(d, cmd, repourl)
> > > > output = runfetchcmd(cmd, d, True)
> > > if not output:
> > > File "bitbake/lib/bb/fetch2/__init__.py", line 957, in
> > > runfetchcmd(cmd='export PSEUDO_DISABLED=1; export
> > > DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1003/bus"; export
> > > PATH="build/tmp/sysroots-uninative/x86_64-linux/usr/bin:scripts:build/tmp/work/qemux86_64-poky-linux/linux-yocto/6.6.20+git/recipe-sysroot-native/usr/bin/x86_64-poky-linux:build/tmp/work/qemux86_64-poky-linux/linux-yocto/6.6.20+git/recipe-sysroot/usr/bin/crossscripts:build/tmp/work/qemux86_64-poky-linux/linux-yocto/6.6.20+git/recipe-sysroot-native/usr/sbin:build/tmp/work/qemux86_64-poky-linux/linux-yocto/6.6.20+git/recipe-sysroot-native/usr/bin:build/tmp/work/qemux86_64-poky-linux/linux-yocto/6.6.20+git/recipe-sysroot-native/sbin:build/tmp/work/qemux86_64-poky-linux/linux-yocto/6.6.20+git/recipe-sysroot-native/bin:bitbake/bin:build/tmp/hosttools";
> > > export HOME="/home/krm"; git -c gc.autoDetach=false -c core.pager=cat -c
> > > safe.bareRepository=all ls-remote
> > > https://git.yoctoproject.org/linux-yocto.git ',
> > > d=<bb.data_smart.DataSmart object at 0x7f8e26195890>, quiet=True,
> > > cleanup=[], log=None, workdir=None):
> > >
> > > > raise FetchError(error_message)
> > >
> > > bb.data_smart.ExpansionError: Failure expanding variable
> > > fetcher_hashes_dummyfunc[vardepvalue], expression was
> > > ${@bb.fetch.get_hashvalue(d)} which triggered exception FetchError:
> > > Fetcher failure: Fetch command export PSEUDO_DISABLED=1; export
> > > DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1003/bus"; export
> > > PATH="build/tmp/sysroots-uninative/x86_64-linux/usr/bin:scripts:/var/home/krm/build/poky/build/tmp/work/qemux86_64-poky-linux/linux-yocto/6.6.20+git/recipe-sysroot-native/usr/bin/x86_64-poky-linux:build/tmp/work/qemux86_64-poky-linux/linux-yocto/6.6.20+git/recipe-sysroot/usr/bin/crossscripts:build/tmp/work/qemux86_64-poky-linux/linux-yocto/6.6.20+git/recipe-sysroot-native/usr/sbin:build/tmp/work/qemux86_64-poky-linux/linux-yocto/6.6.20+git/recipe-sysroot-native/usr/bin:build/tmp/work/qemux86_64-poky-linux/linux-yocto/6.6.20+git/recipe-sysroot-native/sbin:build/tmp/work/qemux86_64-poky-linux/linux-yocto/6.6.20+git/recipe-sysroot-native/bin:bitbake/bin:build/tmp/hosttools";
> > > export HOME="/home/krm"; git -c gc.autoDetach=false -c core.pager=cat -c
> > > safe.bareRepository=all ls-remote
> > > https://git.yoctoproject.org/linux-yocto.git failed with exit code 128,
> > > output:
> > > fatal: unable to access 'https://git.yoctoproject.org/linux-yocto.git/':
> > > error setting certificate file:
> > > build/tmp/work/x86_64-linux/curl-native/8.6.0/recipe-sysroot-native/etc/ssl/certs/ca-certificates.crt
> > >
> > > The variable dependency chain for the failure is:
> > > fetcher_hashes_dummyfunc[vardepvalue]
> >
> > Note:
> > One gets out of that parser error by deleting the git binary in the
> > kernel's work recipe-sysroot-native
> > `rm
> > tmp/work/qemux86_64-poky-linux/linux-yocto/6.6.20+git/recipe-sysroot-native/usr/bin/git`
> >
> > Bisecting poky leads to commit
> > f7fa98cca8 ("kern-tools: depend on git-replacement-native")
> > Reverting it on top of b5624ee564 makes the parsing pass.
> >
> > I assume that `git-replacement-native` does not work with https, the
> > fetch error also goes away if changing in SRC_URI from https to git.
> >
> > Any comments?
>
> I didn't even know that curl was coming into play :)
>
> Adding DEPENDS:class-native += "ca-certificates" to the curl recipe
> should resolve the issue.
Looks like curl-native resp. libcurl hardcodes the lookup to its own
work directory, i.e.:
x86_64-linux/curl-native/8.6.0/recipe-sysroot-native/etc/ssl/certs/ca-certificates.crt
So even if DEPENDS/RDEPENDS will install ca-certificates in the kernel's
recipe-sysroot-native the parsing will fail if the curl-native directory
is not/no longer populated, e.g. because curl-native came from sstate or
rm_work is in INHERIT.
Max
>
> I also tried exporting the SSL_CERT_DIR in the git-native wrapper, but
> that didn't help
> since of course it is curl that is looking for the certs.
>
> I also thought we could export the SSL_CERT_DIR from within the
> kern-tools, but really,
> it does seem like curl should know that this is a dependency when used
> as a native
> tool (it already has ca-certficates as a RRECOMMENDS).
>
> I haven't done a patch for it, because the intricacies of the native
> classes and where
> we should actually add that depends is someone lost on me.
>
> Richard will likely know the right place to fix it .. and then I'm
> happy to spin a patch.
>
> Bruce
>
> >
> > Cheers
> > Max
>
>
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196881):
https://lists.openembedded.org/g/openembedded-core/message/196881
Mute This Topic: https://lists.openembedded.org/mt/104831542/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
