Closed patrislav1 closed 9 months ago
Both have issues, e.g. our exprtk might not be the correct version for the other project. I will have a look. I wonder if that is a problem with gatesgarth only, because I did not see this issue with kirkstone
also: why tf gatesgarth...
I wonder if that is a problem with gatesgarth only, because I did not see this issue with kirkstone
Kirkstone also has exprtk
recipe. Maybe you didn't run into that issue b/c of layer ordering. If two layers have the same priority, then the one that's sourced later takes precedence.
WHY are you not closing this, github... DId I use the wrong magic word...
No that doesn't work because
ERROR: exprtk-git-r0 do_fetch: Fetcher failure: Unable to find revision 281c2ccc65b8f91c012ea3725ebcef406378a225 in branch master even from upstream
ERROR: exprtk-git-r0 do_fetch: Fetcher failure for URL: 'git://github.com/ArashPartow/exprtk.git;branch=master;protocol=https'. Unable to fetch URL from any source.
ERROR: Logfile of failure stored in: /home/jgeorg/Projects/Yocto/plain/poky/build-honister/tmp/work/cortexa57-poky-linux/exprtk/git-r0/temp/log.do_fetch.3602080
ERROR: Task (/home/jgeorg/Projects/Yocto/plain/poky/meta-openembedded/meta-oe/recipes-devtools/exprtk/exprtk_git.bb:do_fetch) failed with exit code '1'
He force-pushed to master at some point
ufff. so it's going to be a .bbappend
with corrected SRCREV
probably?
yeah. just taking the version from kirkstone
Can"t fix this upstream because noone will care about honister as it is EOL
I tried to build DeviceAccess in a Petalinux 2021.2 (Yocto version 'gatesgarth') with the 'zeus' branch of this layer. After adding 'gatesgarth' to
LAYERSERIES_COMPAT
and trying to builddeviceaccess
package, the fetcher choked onexprtk
package. Turns out that this package is (at least in Yocto 'gatesgarth') not only defined in this layer, but also inmeta-oe
. (The recipe inmeta-oe
also uses an anonymous SSH URL which GitHub stopped supporting and now makes the fetcher time out, but that's a different problem).Since
meta-oe
andmeta-chimeratk
have the same layer priority (6), the latter doesn't override the former and whendeviceaccess
depends onexprtk
, Bitbake chooses the upstream one inmeta-oe
which is wrong (I guess even if that recipe used an actually working URL it would still not work with DeviceAccess et al, since the additional CMake / versioning / packaging stuff added in exprtk-interface would be missing).I can imagine following fixes/workarounds:
meta-chimeratk
so its bundledexprtk
overrides themeta-oe
-bundled onemeta-chimeratk
-bundled package to something else, maybeexprtk-interface
; update the name in depending recipesThe former one is probably safer, b/c if any other package introduces the upstream
exprtk
via dependency tree, the Yocto image will include two packages providing the same file which will probably break the build.