Cargo build --verbose stuck when add rand = "0.3.0" in Cargo.toml.

[grv07]

[package]
name = "guessing_game"
version = "0.1.0"
authors = ["grv07"]

[dependencies]

rand = "0.3.0"

when run >> cargo build --verbose

it just show me
Updating registry https://github.com/rust-lang/crates.io-index
and wait ....

[alexcrichton]

Interesting! Can you try running with RUST_LOG=trace and gist what Cargo prints?

[grv07]

my Internet speed was too slow that time sorry for your time

[ankush981]

But it did take too, too long in my case. Around 5-6 minutes. -.-

[kuchaguangjie]

I am seeing the same issue, my internet is pretty quick (50Mb), but cargo build --verbose stuck there, don't know what is happening. Even with RUST_LOG=trace set, it's the same.

Maybe this issue should be reopened.

[alexcrichton]

@ankush981 @kuchaguangjie do you know how to reproduce the issue? Is there something I can do locally to reproduce this?

If not, could you try attaching a debugger to Cargo as it's running to see where it's at?

[kuchaguangjie]

After, trying for many times, it succeed, here is the console output on my Linux.

eric@eric-pc:/mnt/star/rust_repository/rust-guessing-game$ cargo build -v
Updating registry https://github.com/rust-lang/crates.io-index
Downloading rand v0.3.15
Downloading libc v0.2.22
warning: spurious network error (2 tries remaining): [28] Timeout was reached (Operation too slow. Less than 10 bytes/sec transferred the last 30 seconds)
Compiling libc v0.2.22
Running rustc --crate-name libc /home/eric/.cargo/registry/src/github.com-1ecc6299db9ec823/libc-0.2.22/src/lib.rs --crate-type lib --emit=dep-info,link -C debuginfo=2 --cfg 'feature="use_std"' --cfg 'feature="default"' -C metadata=026076ef8cc90032 -C extra-filename=-026076ef8cc90032 --out-dir /mnt/star/rust_repository/rust-guessing-game/target/debug/deps -L dependency=/mnt/star/rust_repository/rust-guessing-game/target/debug/deps --cap-lints allow
Compiling rand v0.3.15
Running rustc --crate-name rand /home/eric/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.3.15/src/lib.rs --crate-type lib --emit=dep-info,link -C debuginfo=2 -C metadata=c9d9fbdab2355ee4 -C extra-filename=-c9d9fbdab2355ee4 --out-dir /mnt/star/rust_repository/rust-guessing-game/target/debug/deps -L dependency=/mnt/star/rust_repository/rust-guessing-game/target/debug/deps --extern libc=/mnt/star/rust_repository/rust-guessing-game/target/debug/deps/liblibc-026076ef8cc90032.rlib --cap-lints allow
Compiling rust-guessing-game v0.1.0 (file:///mnt/star/rust_repository/rust-guessing-game)
Running rustc --crate-name rust_guessing_game src/main.rs --crate-type bin --emit=dep-info,link -C debuginfo=2 -C metadata=a010b57006bee8ed -C extra-filename=-a010b57006bee8ed --out-dir /mnt/star/rust_repository/rust-guessing-game/target/debug/deps -L dependency=/mnt/star/rust_repository/rust-guessing-game/target/debug/deps --extern rand=/mnt/star/rust_repository/rust-guessing-game/target/debug/deps/librand-c9d9fbdab2355ee4.rlib
Finished dev [unoptimized + debuginfo] target(s) in 5.85 secs
eric@eric-pc:/mnt/star/rust_repository/rust-guessing-game$

It did report network slow from the output, but actually I got a very quick network.
But, I am from China, there do have a possibility that the network between github & China is slow, even though I could open github without a proxy now.

But, the other guy is not from my area. So, I am not sure what happened to him.

From the output, it says 10byte/sec for 30 seconds might cause a timeout, is that correct? Maybe that's the reason to cause it failed. I think there should not put such a limitation, or at least let it configurable, and give tips on first time out, not after 28 times trying, that would be at least (30 second * 28) = 14 minutes, if I understand the output correctly.

Thanks.

[alexcrichton]

Oh so crate downloads actually come directly from S3 right now (like directly from the bucket, no CDN), so that may be why it's a slow connection (is that blocked by default in China?)

Right now the intention is that if no bytes have been received in 30s then the connection is terminated, but the logic may not be right?

[kuchaguangjie]

@alexcrichton I guess the connection between China and the S3 is not stable.
Is it reasonable and possible to make the max timeout configurable? So that in some special areas (e.g China), people could try download with a slow & unstable connection without been terminated.

Thanks.

[alexcrichton]

@kuchaguangjie can you try the timeout configuration here? If that doesn't work we may have forgotten a location!

[kuchaguangjie]

@alexcrichton Thanks, I didn't notice there is such a configuration, I would try to config the timeout in ~/.cargo/config, also might set a proxy using xxnet if that would boost the speed.

[kuchaguangjie]

@alexcrichton Hey, at the beginning of weekend, I got some time to check this issue.

As mentioned in previous comment, I just used xxnet (a free https proxy tool base on GAE, mainly to anti against GFW) to setup proxy for cargo, the config is as following:

[http]
timeout = 300000        # 5 min 
proxy = "localhost:8087"
cainfo = "/mnt/star/git_repository/xxnet/data/gae_proxy/CA.crt"         # path to CA file,

Once the proxy is setup, the cargo download speed is very fast, following is an example output:

eric@eric-pc:/mnt/star/rust_repository/rust-guessing-game$ cargo b
Updating registry https://github.com/rust-lang/crates.io-index
Downloading docker v0.0.41
Downloading unix_socket v0.4.6
Downloading openssl v0.6.7
Downloading debug-builders v0.1.0
Downloading libc v0.1.12
Downloading openssl-sys v0.6.7
Downloading lazy_static v0.1.16
Downloading bitflags v0.3.3
Downloading pkg-config v0.3.9
Compiling lazy_static v0.1.16
Compiling pkg-config v0.3.9
Compiling libc v0.1.12
Compiling debug-builders v0.1.0
Compiling bitflags v0.3.3
Compiling unix_socket v0.4.6
Compiling openssl-sys v0.6.7
Compiling openssl v0.6.7
Compiling docker v0.0.41
Compiling rust-guessing-game v0.1.0 (file:///mnt/star/rust_repository/rust-guessing-game)
Finished dev [unoptimized + debuginfo] target(s) in 7.49 secs

So, I guess the slow speed to download via cargo in China is caused by GFW, and it could be resolved using xxnet which is totally free.

Thus, the issue is not caused by cargo or github, maybe the post could be closed.

BWT, the config file of cargo is really simple & easy to use, nice job!

Thanks.

[ankush981]

I'm in India and have a 16 Mbps connection, with no restrictions or regulations. This time I uninstalled Rust, installed it again, and again tried to build the project. It built the new crate after a wait of a few seconds (comparable to npm install). But I've not been able to reproduce it. All I can say is that it halts when trying to fetch from Github, though otherwise I have no lag when cloning from Github.

[alexcrichton]

Alas :(

I see this as "Cargo really needs more progress bars" or something like that then!

[carols10cents]

Sounds like this issue is resolved for now, but the longer term issues are:

• crates.io mirrors and getting one that works behind the GFW
• providing a progress bar for slow git operations

Thank you!