rust 1.81.0 fails to build without network access

[jpalus]

Distribution packages are often built from self contained sources in isolated environment without network access. Contrary to previous releases rust 1.81.0 fails to build without network access although it's not clear to me why exactly. ./x.py dist fails with;

Command cd "/tmp/B.dlfv1vcs/BUILD/rustc-1.81.0-src/build/tmp/tarball/rustc/src/image" && RUSTC_BOOTSTRAP="1" "/usr/bin/cargo" "vendor" "--versioned-dirs" "--sync" "/tmp/B.dlfv1vcs/BUILD/rustc-1.81.0-src/./src/tools/cargo/Cargo.toml" "--sync" "/tmp/B.dlfv1vcs/BUILD/rustc-1.81.0-src/./src/tools/rust-analyzer/Cargo.toml" "--sync" "/tmp/B.dlfv1vcs/BUILD/rustc-1.81.0-src/./compiler/rustc_codegen_cranelift/Cargo.toml" "--sync" "/tmp/B.dlfv1vcs/BUILD/rustc-1.81.0-src/./compiler/rustc_codegen_gcc/Cargo.toml" "--sync" "/tmp/B.dlfv1vcs/BUILD/rustc-1.81.0-src/./src/bootstrap/Cargo.toml" "--sync" "/tmp/B.dlfv1vcs/BUILD/rustc-1.81.0-src/./src/tools/opt-dist/Cargo.toml" "--sync" "/tmp/B.dlfv1vcs/BUILD/rustc-1.81.0-src/./src/tools/rustc-perf/Cargo.toml" "--sync" "/tmp/B.dlfv1vcs/BUILD/rustc-1.81.0-src/./src/tools/rustc-perf/collector/compile-benchmarks/syn-1.0.89/Cargo.toml" "--sync" "/tmp/B.dlfv1vcs/BUILD/rustc-1.81.0-src/./src/tools/rustc-perf/collector/compile-benchmarks/cargo-0.60.0/Cargo.toml" "--sync" "/tmp/B.dlfv1vcs/BUILD/rustc-1.81.0-src/./src/tools/rustc-perf/collector/compile-benchmarks/serde-1.0.136/Cargo.toml" "--sync" "/tmp/B.dlfv1vcs/BUILD/rustc-1.81.0-src/./src/tools/rustc-perf/collector/compile-benchmarks/ripgrep-13.0.0/Cargo.toml" "--sync" "/tmp/B.dlfv1vcs/BUILD/rustc-1.81.0-src/./src/tools/rustc-perf/collector/compile-benchmarks/regex-1.5.5/Cargo.toml" "--sync" "/tmp/B.dlfv1vcs/BUILD/rustc-1.81.0-src/./src/tools/rustc-perf/collector/compile-benchmarks/clap-3.1.6/Cargo.toml" "--sync" "/tmp/B.dlfv1vcs/BUILD/rustc-1.81.0-src/./src/tools/rustc-perf/collector/compile-benchmarks/hyper-0.14.18/Cargo.toml" "--sync" "/tmp/B.dlfv1vcs/BUILD/rustc-1.81.0-src/./src/tools/rustc-perf/collector/compile-benchmarks/externs/Cargo.toml" "--sync" "/tmp/B.dlfv1vcs/BUILD/rustc-1.81.0-src/./src/tools/rustc-perf/collector/compile-benchmarks/ctfe-stress-5/Cargo.toml" "--sync" "/tmp/B.dlfv1vcs/BUILD/rustc-1.81.0-src/./src/tools/rustc-perf/collector/compile-benchmarks/cargo-0.60.0/Cargo.toml" "--sync" "/tmp/B.dlfv1vcs/BUILD/rustc-1.81.0-src/./src/tools/rustc-perf/collector/compile-benchmarks/token-stream-stress/Cargo.toml" "--sync" "/tmp/B.dlfv1vcs/BUILD/rustc-1.81.0-src/./src/tools/rustc-perf/collector/compile-benchmarks/match-stress/Cargo.toml" "--sync" "/tmp/B.dlfv1vcs/BUILD/rustc-1.81.0-src/./src/tools/rustc-perf/collector/compile-benchmarks/tuple-stress/Cargo.toml" "--sync" "/tmp/B.dlfv1vcs/BUILD/rustc-1.81.0-src/./src/tools/rustc-perf/collector/compile-benchmarks/diesel-1.4.8/Cargo.toml" "--sync" "/tmp/B.dlfv1vcs/BUILD/rustc-1.81.0-src/./src/tools/rustc-perf/collector/compile-benchmarks/bitmaps-3.1.0/Cargo.toml" (failure_mode=Exit, stdout_mode=Capture, stderr_mode=Capture) did not execute successfully.
Expected success, got exit status: 101
Created at: src/core/build_steps/dist.rs:1026:27
Executed at: src/core/build_steps/dist.rs:1063:40

STDOUT ----


STDERR ----
Updating crates.io index
warning: spurious network error (3 tries remaining): [6] Could not resolve hostname (Could not resolve host: index.crates.io)
warning: spurious network error (2 tries remaining): [6] Could not resolve hostname (Could not resolve host: index.crates.io)
warning: spurious network error (1 tries remaining): [6] Could not resolve hostname (Could not resolve host: index.crates.io)
error: failed to sync

Caused by:
  failed to load pkg lockfile

Caused by:
  failed to get `serde` as a dependency of package `cargo-platform v0.1.8 (/tmp/B.dlfv1vcs/BUILD/rustc-1.81.0-src/src/tools/cargo/crates/cargo-platform)`

Caused by:
  download of config.json failed

Caused by:
  failed to download from `https://index.crates.io/config.json`

Caused by:
  [6] Could not resolve hostname (Could not resolve host: index.crates.io)

Traceback (most recent call last):
  File "/tmp/B.dlfv1vcs/BUILD/rustc-1.81.0-src/./x.py", line 50, in <module>
    bootstrap.main()
  File "/tmp/B.dlfv1vcs/BUILD/rustc-1.81.0-src/src/bootstrap/bootstrap.py", line 1191, in main
    bootstrap(args)
  File "/tmp/B.dlfv1vcs/BUILD/rustc-1.81.0-src/src/bootstrap/bootstrap.py", line 1167, in bootstrap
    run(args, env=env, verbose=build.verbose, is_bootstrap=True)
  File "/tmp/B.dlfv1vcs/BUILD/rustc-1.81.0-src/src/bootstrap/bootstrap.py", line 186, in run
    raise RuntimeError(err)
RuntimeError: failed to run: /tmp/B.dlfv1vcs/BUILD/rustc-1.81.0-src/build/bootstrap/debug/bootstrap dist -j 28 --verbose

[onur-ozkan]

We vendor dependencies in distribution tarballs, so when you run ./x.py dist, bootstrap executes cargo vendor and that will fail if it cannot connect to crates.io. This isn't new behaviour with version 1.81.0; it has been like this for a while (see the PR that made it possible).

[onur-ozkan]

Dropped the regression label as this isn't a regression from the previous stable.

[jpalus]

bootstrap executes cargo vendor and that will fail if it cannot connect to crates.io

I don't see a single cargo vendor invocation like the one in description throughout entire rust 1.80.1 build that happened just a day before it.

[onur-ozkan]

I don't see a single cargo vendor invocation like the one in description

And that command is generated from here.

entire rust 1.80.1 build that happened just a day before it.

Do you mean x build or x dist?

[jpalus]

To be clear x.py dist:

• when building 1.80.1 does not result in any `cargo vendor*
• when building 1.81.0 it does

[jpalus]

Is it perhaps 1089de4

[onur-ozkan]

Is it perhaps 1089de4

It shouldn't be that one.

To be clear x.py dist:

• when building 1.80.1 does not result in any `cargo vendor*
• when building 1.81.0 it does

Vendoring should be trigger for both builds if I am not missing anything. Can you tell me how did you get "1.80.1" source code? Did you download it from Github as a zip file ? If so, vendoring can be skipped as the check here will return false in that scenario.

Did you download it from Github as a zip file ?

What I mean is this:

[jpalus]

Is it perhaps 1089de4

It shouldn't be that one.

I don't know what dry run meant in this context but at least prior to this commit codepath existed that would skip cmd execution.

To be clear x.py dist:

• when building 1.80.1 does not result in any `cargo vendor*
• when building 1.81.0 it does

Vendoring should be trigger for both builds if I am not missing anything. Can you tell me how did you get "1.80.1" source code? Did you download it from Github as a zip file ?

Downloaded since forever from https://static.rust-lang.org/dist/rustc-1.81.0-src.tar.xz

[onur-ozkan]

Are you sure that "cargo vendor" is not being executed? Maybe it's being executed but performing no-op 🤔

[jpalus]

Attaching full log file for reference:
log.gz

[weihanglo]

Probably because of this PR #125465? Though I removed the code vendoring training crates, bootstrap still accesses the network.

[onur-ozkan]

Probably because of this PR #125465? Though I removed the code vendoring training crates, bootstrap still accesses the network.

At which part?

[weihanglo]

Reverting e24be07 didn't make any difference. Index still got updated. So #125465 seems unrelated.

[weihanglo]

Looks like

• https://static.rust-lang.org/dist/2024-07-05/rustc-nightly-src.tar.gz is bad, which is cc8da78
• https://static.rust-lang.org/dist/2024-07-04/rustc-nightly-src.tar.gz is good, which is aa1d4f6

[weihanglo]

Just bisected and found 3ef77cc is the bad commit. Changing back to using std::process::Command from BootstrapCommand fixes the behavior. Feels odd.

[onur-ozkan]

Just bisected and found 3ef77cc is the bad commit. Changing back to using std::process::Command from BootstrapCommand fixes the behavior. Feels odd.

cc @Kobzol

[Kobzol]

@weihanglo Could you please post the bootstrap invocation that you used to bisect this?

[weihanglo]

Finally got time look into the actual code. Seems like cargo vendor execution failed but old bootstrap code didn't check output.status.success(). Hence both the vendor directory and .cargo/config.toml were empty when disting rustc-src in an air-gapped environment.

The 3ef77cc did nothing wrong. It's a correct fix revealing the silent failure. The follow-up question would be: should x.py dist rustc-src respects existing Cargo [source] replacement? Or should we have a config value for respecting that?

[onur-ozkan]

There's this PR #130110 which makes the dist vendoring configurable.

[weihanglo]

There's this PR #130110 which makes the dist vendoring configurable.

While my original proposal was using the --respect-source-config flag in cargo vendor, #130110 looks way better a solution to this. Thank you!

I cannot think of a reason people want to create a self-contained source tarball from a self-contained source tarball. That said, we can always look into that feature when it is requested.

Given above I think #130110 resolves this issue.

[Kobzol]

Thanks for investigating this! Good to know that the command refactoring helped find a silent error.

[jpalus]

Fixed in 1.83.0.