Hello I make some advance on this and there is a drawback that I didn't foreseen, in case of patched git url (those set up by cargo_common_do_patch_path), the Cargo.lock file must be modified to remove source entry , hence not compatible with --frozen.
I put more info in comment YOCTO #15104 <https://bugzilla.yoctoproject.org/show_bug.cgi?id=15104> for those interested but for the moment, I cleaned the Cargo.lock by myself before freezing it for the next build steps. There is still the question about the fate of "rust-hello-world" recipe too (which cannot be built with --frozen flag without having a Cargo.lock file), I don't know if I can suppress it or if I need to create a Cargo.lock for it. On Thu, 20 Jul 2023 at 14:00, Frederic Martinsons via lists.openembedded.org <frederic.martinsons=gmail....@lists.openembedded.org> wrote: > Hello list, > > In the course of YOCTO #15104 > <https://bugzilla.yoctoproject.org/show_bug.cgi?id=15104> , I finally > found the issue was due to a missing Cargo.lock file at the root of the > project (which is pretty usual for a Rust project from git since Cargo.lock > is only required when publishing on the crates registry). > > With a Cargo.lock correctly placed, the patch process made by > cargo_common.bbclass works perfectly fine even with a virtual manifest. > > I often encountered issues that were in the end due to a missing > Cargo.lock and I think we all agree on this list (I didn't crawl the mail > archives, I talked from my memory) that this file is absolutely required > when building a rust project under yocto. > (especially for reproducible build) > > I'm currently testing a patch which will replace --offline cargo build > flags with --frozen (which supersedes --offline mode since it prevents > network access but also Cargo.lock to be present and up to date). > > I have two questions though: > 1) rust-hello-world doesn't embed a Cargo.lock (and doesn't need to > since it had zero dependencies) , considering that we now have a more > "real" recipe (zvariant) that is used within selftest, would it be > acceptable to suppress rust-hello-world ? > 2) below is kind of message we will have when using --frozen with an > absent Cargo.lock: > > | error: failed to get `glib` as a dependency of package `zvariant v3.12.0 > (/home/fmartinsons/TAPOS_build/build-tapos/tmp/work/corei7-64-tapos-linux/zbus/3.11.0-r0/git/zvariant)` > | > | Caused by: > | failed to load source for dependency `glib` > | > | Caused by: > | Unable to update https://github.com/gtk-rs/glib?rev=c9ee583cea0 > | > | Caused by: > | failed to fetch into: > /home/fmartinsons/TAPOS_build/build-tapos/tmp/work/corei7-64-tapos-linux/zbus/3.11.0-r0/cargo_home/git/db/glib-928cf7b282977403 > | > | Caused by: > | attempting to update a git repository, but --frozen was specified > > I think it is not very clear that the root cause is a missing Cargo.lock , > so I'm wondering if a specific bitbake ops (do_compile_prepend) would not > be better to check for Cargo.lock and output an explicit message (it > doesn't prevent to keep --frozen anyway). What do you think ? > > PS: I copied Randy as the maintainer of rust-hello-world but also the > ticket assignee. > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#184790): https://lists.openembedded.org/g/openembedded-core/message/184790 Mute This Topic: https://lists.openembedded.org/mt/100254129/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
