I'm unable to build the servo (GitHub - servo/servo: Servo, the embeddable, independent, memory-safe, modular, parallel web rendering engine) and my problems began with failures to clone the repo.
I have been cloning repos for years without this issue, but found many reports of a similar problem when others were trying to clone other large repos (such as LibreOffice). Those seem to relate to cloning over unreliable connections, and I am using a mobile broadband connection with hotspot so that seemed similar. However none of those suggestions solved my issue and I still cannot clone servo/servo (or related repos including servo/stylo and servo/webrender) directly.
I have though jumped that hurdle by cloning to a cloud server and then rsync'ing the clones to my laptop over mobile broadband.
But when I build, cargo fails while trying to update dependencies of servo/servo (such as servo/stylo and servo/webrender). So I got local copies of those too (and others) by the same roundabout method since they won't clone directly either. Maybe due to size, I'm not sure.
I'm trying to get my ISP to sort this but they claim they don't do anything that might interfere so in the mean time I'm trying to stop cargo from updating dependencies during the build.
I succeeded in one case, so it no longer updates servo/stylo by enabling the following patch section which was commented out in servo/Cargo.toml:
# Or for Stylo:
#
[patch."https://github.com/servo/stylo"]
derive_common = { path = "../stylo/derive_common" }
malloc_size_of = { path = "../stylo/malloc_size_of" }
selectors = { path = "../stylo/selectors" }
servo_arc = { path = "../stylo/servo_arc" }
servo_atoms = { path = "../stylo/atoms" }
size_of_test = { path = "../stylo/size_of_test" }
static_prefs = { path = "../stylo/style_static_prefs" }
style_config = { path = "../stylo/style_config" }
style_derive = { path = "../stylo/style_derive" }
style = { path = "../stylo/style" }
style_traits = { path = "../stylo/style_traits" }
to_shmem = { path = "../stylo/to_shmem" }
That stopped it trying to update stylo but then it fails trying to update servo/webrender 
. So I added the following patch for that, which is being picked up but doesn't prevent it trying to update servo/webrender:
[patch."https://github.com/servo/webrender"]
webrender = { path = "../webrender/webrender" }
webrender_api = { path = "../webrender/webrender_api" }
Instead of updating stylo, I get this:
./mach build
No build type specified so assuming `--dev`.
Updating crates.io index
Updating git repository `https://github.com/servo/webrender`
remote: Enumerating objects: 67923, done.
remote: Counting objects: 100% (1981/1981), done.
remote: Compressing objects: 100% (764/764), done.
Which proceeds for a while and then fails, reporting:
error: RPC failed; curl 56 GnuTLS recv error (-9): Error decoding the received TLS packet.
error: 4287 bytes of body are still expected
fetch-pack: unexpected disconnect while reading sideband packet
fatal: early EOF
fatal: fetch-pack: invalid index-pack output
error: failed to get `webrender` as a dependency of package `libservo v0.0.1 (/home/mrh/src/safe-servo/servo/components/servo)`
Caused by:
failed to load source for dependency `webrender`
Caused by:
Unable to update https://github.com/servo/webrender?branch=0.64#9d354adf
Caused by:
failed to fetch into: /home/mrh/.cargo/git/db/webrender-c3596abe1cf4f320
Caused by:
process didn't exit successfully: `git fetch --force --update-head-ok 'https://github.com/servo/webrender' '+9d354adf8955b1390dd56db89e6d5a9ea7880391:refs/commit/9d354adf8955b1390dd56db89e6d5a9ea7880391'` (exit status: 128)
Failed in 0:02:01
I've been trying to figure this out by adding patches for other repos to the webrender/Cargo.toml but can't get it to work, and I'm poking around in the dark really. So wondering if this is something others have seen with cargo and if there are other ways to control how it works, to prevent it trying remote git operations on the servo repos? Then I can just make sure I have all the dependencies locally.
P.S. I have asked for help in the servo chat and that pointed to the possibility that cargo might be trying to update because of an out of date Cargo.lock. So I tried cargo update on the cloud server and repeating the copy to my laptop using rsync. That didn't change anything but it is possible that the update of one repo is being triggered by something in a dependency repo. I'm not sure.
P.S. ./mach build is the servo repo's method of invoking cargo build, but I get the same result running the latter.
EDIT: I'm trying to work around the issues documented here and have made progress using cargo vendor but that isn't working yet. Issue here: Unable to build servo demo with vendored source · Issue #1194 · tauri-apps/wry · GitHub