Bug#1016573: [Pkg-rust-maintainers] Bug#1016573: Acknowledgement (debcargo: Doesn't find sources)
On 04 août 2022 09:33, Fabian Grünbichler wrote: > On August 3, 2022 11:57 am, Christian Marillat wrote: >> On 03 août 2022 09:54, Fabian Grünbichler wrote: [...] >> I launched debcargo with CARGO_NET_GIT_FETCH_WITH_CLI=true for one >> source "time" and now I'm able to download latest source for "smallvec" >> and "paste" without CARGO_NET_GIT_FETCH_WITH_CLI > > that matches experience of other people in the past when they triggered > this issue - the local cache will be correctly updated when using `git` > (the binary) instead of the built-in libgit2 mechanism, and therefore > the information about crates other than the one being currently > processed is also updated correctly. Thanks for all explanations. I wasn't aware of this issue with libgit2. Now I'll periodically destroy the huge ~/.cargo directory. , | $ du -hsc .cargo | 1010M .cargo | 1010M total ` Only 103M after a "debcargo update". Christian
Bug#1016573: [Pkg-rust-maintainers] Bug#1016573: Acknowledgement (debcargo: Doesn't find sources)
On August 3, 2022 11:57 am, Christian Marillat wrote: > On 03 août 2022 09:54, Fabian Grünbichler wrote: > > [...] > >> works for me here (both the unversioned command and the versioned >> command fetch the same current upstream version) >> >> but there is a known issue where libgit2 sometimes gets stuck and >> doesn't properly update the crates.io index. the usual workaround is >> setting the `net.git-fetch-with-cli` option for cargo (debcargo uses >> cargo as a library internally), e.g. like so: >> >> CARGO_NET_GIT_FETCH_WITH_CLI=1 debcargo package .. > > Must be true or false not 1 or 0 > > [...] > >> could you please report back whether either approach solves the issue >> for you? > > I launched debcargo with CARGO_NET_GIT_FETCH_WITH_CLI=true for one > source "time" and now I'm able to download latest source for "smallvec" > and "paste" without CARGO_NET_GIT_FETCH_WITH_CLI that matches experience of other people in the past when they triggered this issue - the local cache will be correctly updated when using `git` (the binary) instead of the built-in libgit2 mechanism, and therefore the information about crates other than the one being currently processed is also updated correctly. >> please also note that cargo and debcargo are currently prepared for >> upgrading, including upgrading the version of libgit2 they are linked >> with. this upgrade will also solve another issue with crate version >> availability affecting crates that have opted-into using new cargo >> features that are not compatible with the currently packaged >> cargo/debcargo versions - thankfully there aren't that many yet, and >> almost all of them are not (yet) package for Debian either. >> >> unfortunately this update is quite an involved process, so it will >> likely take a few more weeks at least until it will be available. > > OK. Which version should fix these issues above ? I am not sure whether the new version (cargo 0.63) fixes the "stuck index" issue (I've only ever encountered it once myself, and promptly fixed it via the workaround above and never managed to hit or reproduce it again). there is an upstream issue for it: https://github.com/rust-lang/cargo/issues/10230 where one theory is that something went wrong with a index squash (which would mean that only systems having the pre-squash index cached are unable to update, and would explain the lack of reproducibility). I can say that cargo 0.63 (and any debcargo version using that once it hits the repositories) is able to process "v2" crates.io index entries, which the current cargo/debcargo versions can't - but that is a separate issue (with similar symptoms - the old cargo/debcargo will just not know that the new, incompatible crate version exists). These are the Draft MRs for updating src:cargo, src:cargo-rust (and dependencies) and src:debcargo: https://salsa.debian.org/rust-team/cargo/-/merge_requests/14 https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/368 https://salsa.debian.org/rust-team/debcargo/-/merge_requests/41 Also note that cargo is working on switching the index fetching to HTTP instead of git: https://github.com/rust-lang/cargo/issues/9069 which might get rid of some of the libgit2 related woes ;)
Bug#1016573: [Pkg-rust-maintainers] Bug#1016573: Acknowledgement (debcargo: Doesn't find sources)
On 03 août 2022 09:54, Fabian Grünbichler wrote: [...] > works for me here (both the unversioned command and the versioned > command fetch the same current upstream version) > > but there is a known issue where libgit2 sometimes gets stuck and > doesn't properly update the crates.io index. the usual workaround is > setting the `net.git-fetch-with-cli` option for cargo (debcargo uses > cargo as a library internally), e.g. like so: > > CARGO_NET_GIT_FETCH_WITH_CLI=1 debcargo package .. Must be true or false not 1 or 0 [...] > could you please report back whether either approach solves the issue > for you? I launched debcargo with CARGO_NET_GIT_FETCH_WITH_CLI=true for one source "time" and now I'm able to download latest source for "smallvec" and "paste" without CARGO_NET_GIT_FETCH_WITH_CLI > please also note that cargo and debcargo are currently prepared for > upgrading, including upgrading the version of libgit2 they are linked > with. this upgrade will also solve another issue with crate version > availability affecting crates that have opted-into using new cargo > features that are not compatible with the currently packaged > cargo/debcargo versions - thankfully there aren't that many yet, and > almost all of them are not (yet) package for Debian either. > > unfortunately this update is quite an involved process, so it will > likely take a few more weeks at least until it will be available. OK. Which version should fix these issues above ? Christian
Bug#1016573: [Pkg-rust-maintainers] Bug#1016573: Acknowledgement (debcargo: Doesn't find sources)
On August 3, 2022 9:24 am, Christian Marillat wrote: > [...] > But debcargo deosn't find these new sources : > > debcargo package paste > debcargo failed: Could not create source directory rust-paste-1.0.7 > > debcargo package smallvec > debcargo failed: Could not create source directory rust-smallvec-1.8.1 > > debcargo package time > debcargo failed: Could not create source directory rust-time-0.3.11 yes, and the error message indicates that the output dir for the old (cached) version already exists, so if you run this in an empty dir you would get the files for the outdated version, right? > On 03 août 2022 07:09, "Debian Bug Tracking System" > wrote: > > of course fail if a provides the source version : > > debcargo package time 0.3.12 > debcargo failed: Couldn't find any crate matching time =0.3.12 > > debcargo package paste 1.0.8 > debcargo failed: Couldn't find any crate matching paste =1.0.8 > > debcargo package smallvec 1.9.0 > debcargo failed: Couldn't find any crate matching smallvec =1.9.0 works for me here (both the unversioned command and the versioned command fetch the same current upstream version) but there is a known issue where libgit2 sometimes gets stuck and doesn't properly update the crates.io index. the usual workaround is setting the `net.git-fetch-with-cli` option for cargo (debcargo uses cargo as a library internally), e.g. like so: CARGO_NET_GIT_FETCH_WITH_CLI=1 debcargo package .. a slightly more overreaching approach would be to clear out ~/.cargo/registry (the dir where cargo and thus debcargo keep a cached copy of the registry indices and already fetched crates, both in packaged .crate and expanded sources form). could you please report back whether either approach solves the issue for you? please also note that cargo and debcargo are currently prepared for upgrading, including upgrading the version of libgit2 they are linked with. this upgrade will also solve another issue with crate version availability affecting crates that have opted-into using new cargo features that are not compatible with the currently packaged cargo/debcargo versions - thankfully there aren't that many yet, and almost all of them are not (yet) package for Debian either. unfortunately this update is quite an involved process, so it will likely take a few more weeks at least until it will be available.
