Package: cargo Version: 0.66.0+ds1-1 Severity: normal Tags: upstream X-Debbugs-Cc: debbug.ca...@sideload.33mail.com
Cargo has proven to be seriously fragile and flimsy when it comes to fetching large files from the cloud. Cargo is also (inadvertently) designed to trap users so there is no mechanism by which users can use more robust tools for the download and then feed the file to cargo. Installing a package took a few days of running around a city to try different internet connections and different libraries and cafes until a single connection was found to be up to the full task. The procedure was like this: ===8<---------------------------------------- $ env -C /usr/local/src git clone --config http.proxy=http://127.0.0.1:8118 https://github.com/wireapp/cryptobox-c $ env -C /usr/local/src/cryptobox-c make cargo build Updating crates.io index warning: spurious network error (2 tries remaining): http parser error: stream ended at an unexpected time; class=Http (34) Fetch [ ] 3.11%, 33.10KiB/s warning: spurious network error (1 tries remaining): http parser error: stream ended at an unexpected time; class=Http (34) Fetch [ ] 2.47%, 44.87KiB/s ===8<---------------------------------------- The “cargo build” was tried probably ~30 or so times. Sometimes over tor; sometimes over a vpn; often over normal clearnet. The following was added to /usr/local/src/cryptobox-c/Cargo.toml and various parameters were fiddled with to try to get more forgiveness on the network problems: ===8<---------------------------------------- [http] #proxy = "http://127.0.0.1:8118" # HTTP proxy in libcurl format timeout = 80 # timeout for each HTTP request, in seconds low-speed-limit = 1 # network timeout threshold (bytes/sec) multiplexing = false # HTTP/2 multiplexing [net] retry = 30 # network retries git-fetch-with-cli = false # use the `git` executable for git operations ===8<---------------------------------------- That was futile. A warning was given about the section titles “[http]” and “[net]”, but some of the parameters seemed to take effect. There was also no way to pass in git parameters. It would have been useful to pass in “--depth 1 --shallow-submodules” Setting git-fetch-with-cli=true would not help because shallow fetching options are not offered by git as global configuration variables. The verbose logs showed that it made around ~40% progress on a ~750mb file and die due to spurious network errors. Then on the next attempt it would only get 10% of that same file, starting from the beginning. I had to connection shop, travelling around town until I could find a high-bandwidth low-latency connection at a time of day with relatively low traffic to get the package downloaded. It finally succeeded but only because of that overperforming uplink was available to me. Many improvements are needed: ① a way to pass in git options. ② crash recovery/resume - it’s crazy to fetch half of a 700mb file and then throw it all away and start over when the network fails. ③ a way to be informed about the exact URL being fetched so we can use something like “aria2c -c” or “wget -c” to fetch the big files using robust tools dedicated to this purpose. (maybe http.debug covers this.. not tested) ④ when cargo quits due to spurious network errors, it needs to keep the partial download around and tell users where the partial file is. ⑤ a way to feed a complete local file to cargo to use in place of whatever it would normally fetch. ⑥ a way to specify a log file. All output was dumped to the terminal and no transcription mechanism was being used. The man page and the config manual¹ make no mention of a logfile option. The files that gave the most grief were apparently standard libraries not specific to cryptobox. The full Debian release disk (90gb, which I have on-hand) likely even has the file that was needed somewhere. But cargo lacked the options needed to put it to use. This is tagged with severity normal. The five improvements listed above may technically be “wishlist” severity, but it seems more like a defect that cargo is essentially rendered dysfunctional on any less than perfect or average network. ¹ https://doc.rust-lang.org/cargo/reference/config.html -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-28-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cargo depends on: ii binutils 2.40-2 ii gcc [c-compiler] 4:12.2.0-3 ii gcc-10 [c-compiler] 10.2.1-6 ii gcc-12 [c-compiler] 12.2.0-14 ii libc6 2.36-9+deb12u6 ii libcurl3-gnutls 7.88.1-10+deb12u5 ii libgcc-s1 12.2.0-14 ii libgit2-1.5 1.5.1+ds-1+deb12u1 ii libssh2-1 1.10.0-3+b1 ii libssl3 3.0.11-1~deb12u2 ii rustc 1.63.0+dfsg1-2 ii zlib1g 1:1.2.13.dfsg-1 cargo recommends no packages. Versions of packages cargo suggests: pn cargo-doc <none> ii python3 3.11.2-1+b1 -- no debconf information