Since I had no answers to this, I'll send a patch series soon (tomorrow?) targeting what I have in mind, for rust-hello-world, I think I'll send a specific patch to disable frozen flag for this recipe (until its fate is known).
Maybe sending code will help to know what it is about and, I hope, make people interested in rust dev inside yocto give some feedbacks Le lun. 24 juil. 2023, 11:27, Frédéric Martinsons < frederic.martins...@gmail.com> a écrit : > 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 (#185063): https://lists.openembedded.org/g/openembedded-core/message/185063 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] -=-=-=-=-=-=-=-=-=-=-=-
