Closed phanirajkiran closed 7 months ago
Bitbake version and build configurations:
Yocto branch langdale/kirkstone, are effected.
I don't know about bitbake, but I just double-checked in fresh containers that the published version works with cargo. I even tried on Fedora and Debian to hopefully rule out system differences. Maybe your file was corrupted somehow?
$ stat -c %s num-integer-0.1.44.crate
22216
$ file num-integer-0.1.44.crate
num-integer-0.1.44.crate: gzip compressed data, was "num-integer-0.1.44.crate", max compression, original size modulo 2^32 122880
$ md5sum num-integer-0.1.44.crate
a8ec1126ef06244ac1e3773981a005f1 num-integer-0.1.44.crate
$ sha1sum num-integer-0.1.44.crate
531b8667a612f7031f71dc61e097f8f87dfdfabc num-integer-0.1.44.crate
$ sha256sum num-integer-0.1.44.crate
d2cc698a63b549a70bc047073d2949cce27cd1c7b0a4a862d08a8031bc2801db num-integer-0.1.44.crate
The sha256sum
is also the checksum
that you'll find in Cargo.lock
.
One guess -- that crates.io/api/.../download
URL should be redirecting to static.crates.io
, so bitbake needs to follow that header when it fetches the crate. This is the difference between curl
and curl -L
, for example, and this is probably what failed if you find your file is empty. Better yet, it should fetch directly from the static CDN as cargo is now doing:
https://blog.rust-lang.org/2024/03/11/crates-io-download-changes.html
Thank you @cuviper , you are correct it is sha256sum mismatch. I have fixed it by adding more compat layer in the series.( Mainly in poky core layer )
Hi Josh Stone @cuviper
Greetings!!
In yocto builds num-integer are being used in python3-cryptography-37.0.4.bb recipe of Yocto langdale branch. Issue is num-integer-0.1.44.crate is NOT a gzip compressed file.
error log :
For a candidate test sample : ( command sequence can be found in the above error log)
@cuviper can you please guide/provide hint on how to build locally / solve this issue. Others ( lazy_static-1.4.0.crate) in the recipe are being done without problem.
Regards, Phanirajkiran