./x.py dist fails to build in an offline environment

[yungkneez]

When trying to build in an offline environment (eg: where crates.io is accessible only through a proxy or mirror), ./x.py dist fails with:

(truncated)
Dist rust-src-1.60.0-dev
        finished in 6.561 seconds
Dist rust-dev-1.60.0-dev-x86_64-unknown-linux-gnu
finished in 52.322 seconds
       Updating crates.io index
warning: spurious network error (2 tries remaining): [6] Couldn’t resolve host name (Could not resolve host: crates.io)
(truncated)
warning: spurious network error (2 tries remaining): [6] Couldn’t resolve host name (Could not resolve host: crates.io)
error: failed to sync
 
Caused by: 
    failed to download packages
 
Caused by: 
    failed to download from ‘https://crates.io/ap1/v1/crates/addr2line/0.17.0/download’
 
Caused by: 
    [6] Could not resolve host name (Could not resolve host: crates.io)
Build completed unsuccessfully in 0:23:21

I have cargo configured to use the proxy in ~/.cargo/config, but this seems to have no affect.

Code

I tried this code:

./configure
./x.py dist

I expected to see this happen: A successful build

Instead, this happened: An unsuccessful build

Version it worked on

It most recently worked on: 1.53.0, but I did not try later versions until 1.60.0

Version with regression

1.60.0

[ehuss]

Are you setting vendor=true in config.toml? That will use the vendored packages that come with source tarball. I would also recommend to let x.py create the .cargo/config.toml with the appropriate vendor settings.

[yungkneez]

Are you setting vendor=true in config.toml? That will use the vendored packages that come with source tarball. I would also recommend to let x.py create the .cargo/config.toml with the appropriate vendor settings.

Thanks! I hadn't tried this originally but am still unable to build. Full steps are below:

Clear local cache

rm -rf ~/.cargo/registry ~/.cargo/git

Clone & initialize repo

git clone https://github.com/rust-lang/rust
cd rust && git checkout 1.60.0
git submodule update --init

Initialize vendored crates

cargo vendor --respect-source-config

Added vendor source to ./cargo/config.toml

./x.py setup user

Set build.vendor flag = true in config.toml

Disconnected from network here

Build

Works!

./x.py build

Fails :(

./x.py dist

(truncated)
Dist rls-1.60.0-dev-x86_64-unknown-linux-gnu
	finished in 12.627 seconds
Building stage1 tool rust-analyzer (x86_64-unknown-linux-gnu)
error: failed to select a version for the requirement `anyhow = "^1.0.26"`
candidate versions found which didn't match: 1.0.51
location searched: directory source `<hidden>/rust/vendor` (which is replacing registry `crates-io`)
required by package `xtask v0.1.0 (<hidden>/rust/src/tools/rust-analyzer/xtask)`
perhaps a crate was updated and forgotten to be re-vendored?
thread 'main' panicked at 'rust-analyzer always builds', src/bootstrap/dist.rs:1090:14
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Build completed unsuccessfully in 0:11:24

[ehuss]

vendor=true needs to be set before going offline and before running x.py. x.py takes care of properly vendoring everything with all the different workspaces. Running cargo vendor manually won't work, because of things like rust-analyzer which are in a different workspace. The only steps you should need to take before going offline are:

1. Clone the repo
2. Copy config.toml.example to config.toml
3. Set vendor=true in config.toml
   • And set any other settings in config.toml you want, like extended=true
   • Setting these settings can be done with the ./configure script if you want
4. Run ./x.py help which should set up the submodules, download the bootstrap compiler, vendor everything, and set up .cargo/config.toml.

[Dylan-DPC]

removing nomination since this seems more like a user issue.

[yungkneez]

Understood. I appreciate you taking the time to explain the procedure!

I think I've identified the problem:
I followed your steps as above but before running ./x.py help, I started Wireshark to see what was going on. I noticed that when it tries to download the necessary crates, it tries to resolve crates.io via DNS instead of using the proxy configured in ~/.cargo/config. This is confirmed when warnings are printed out:

warning: spurious network error (2 tries remaining): [6] Couldn’t resolve host name (Could not resolve host: crates.io)
(repeated)

If a proxy is configured in ~/.cargo/config, crates.io is probably not resolvable via DNS.

This seems like a bug. It should use the source configured in ~/.cargo/config and not reach out directly to crates.io.

[ehuss]

Using a proxy seems like a bit of a different issue than pre-fetching dependencies with cargo vendor. You may also be better served by downloading the source tarballs instead of trying to vendor things yourself.

I would check that the proxy configuration is set up correctly, as it looks like it isn't being picked up. You can run this command with the nightly toolchain to check that it is being picked up:

cargo +nightly config get -Zunstable-options --show-origin http.proxy

Another thing you can try is to get cargo to display debug information about its network activity by setting these environment variables:

CARGO_HTTP_DEBUG=true CARGO_LOG=cargo::ops::registry=trace

[yungkneez]

You've given me some ideas as to where I can look for what's causing this and possible solutions.

To better capture the scope of the problem and what could be done, I'm going to close this issue for now, go over those ideas, and open a new issue if need be.

Thanks!