Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nightly Rust using cargo 0.25.0-nightly (930f9d949 2017-12-05) fails to respect --frozen #4815

Closed
carols10cents opened this issue Dec 13, 2017 · 12 comments · Fixed by #4816
Closed

Comments

@carols10cents
Copy link
Member

carols10cents commented Dec 13, 2017

Previous discussion at the end of #4563 (comment) as that issue was suspected at first:

Hi!

We (The Tor Project) appear to be having the same bug as @DanielKeep (and reasoning for backwards compatibility with the lockfiles which are now in our older, maintenance-only branches). However, instead of with --locked, we're specifying --frozen, and newer cargo is desperately trying to update the lockfile, then bailing because it can't. Our bug for tracking this is https://bugs.torproject.org/24608, the description of which includes the logs of a TravisCI build which is failing (we suspect) for this reason.

/cc @matklad @isislovecruft @alexcrichton @nrc

@carols10cents
Copy link
Member Author

Ok, hypothesizing that the problem is that checksums of dependencies would be different under latest rustc stable and latest rustc nightly, but I was unable to reproduce the failure tor is seeing in travis using this hypothesis :-/

What I did:

$ cargo new frozen
$ cd frozen
$ rustup default stable
$ rustc --version
rustc 1.22.1 (05e2e1c41 2017-11-22)
$ cargo --version
cargo 0.23.0 (61fa02415 2017-11-22)

I added libc = "*" as a dependency

$ cargo build
    Updating registry `https://github.com/rust-lang/crates.io-index`
   Compiling libc v0.2.34
   Compiling frozen v0.1.0 (file:///Users/carolnichols/rust/frozen)
    Finished dev [unoptimized + debuginfo] target(s) in 0.96 secs

Cargo.lock now contains:

[[package]]
name = "frozen"
version = "0.1.0"
dependencies = [
 "libc 0.2.34 (registry+https://github.com/rust-lang/crates.io-index)",
]

[[package]]
name = "libc"
version = "0.2.34"
source = "registry+https://github.com/rust-lang/crates.io-index"

[metadata]
"checksum libc 0.2.34 (registry+https://github.com/rust-lang/crates.io-index)" = "36fbc8a8929c632868295d0178dd8f63fc423fd7537ad0738372bd010b3ac9b0"

I checked that I could successfully use --frozen on stable:

$ cargo build --frozen
    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs

I switched to nightly:

$ rustc --version
rustc 1.24.0-nightly (6a3601944 2017-12-12)
11:42:48 (master) ~/rust/frozen $ cargo --version
cargo 0.25.0-nightly (930f9d949 2017-12-05)

And I was able to successfully use --frozen:

11:42:50 (master) ~/rust/frozen $ cargo build --frozen
   Compiling libc v0.2.34
   Compiling frozen v0.1.0 (file:///Users/carolnichols/rust/frozen)
    Finished dev [unoptimized + debuginfo] target(s) in 0.72 secs

So I don't think it's the checksum. Talking with Alex at lunch, he says the checksum commit that updated the test should only apply to cargo's tests. He also can't think of anything recently that could have broken --frozen.

My next step is going to be figuring out what cargo was before it was updated a week ago and start looking at the commits in between to make a new hypothesis :-/

@carols10cents
Copy link
Member Author

carols10cents commented Dec 13, 2017

Last passing tor build

First failing tor build

Cargo commits between 5bb478a and 930f9d9

@matklad
Copy link
Member

matklad commented Dec 13, 2017

@carols10cents were you able to reproduce it locally? I've https://github.com/tlyu/tor

@matklad
Copy link
Member

matklad commented Dec 13, 2017

...

g clone https://github.com/tlyu/tor.git 
cd tor/src/rust
cargo +nightly build --release --frozen --manifest-path tor_rust/Cargo.toml

And it does not complain.

@carols10cents
Copy link
Member Author

@matklad neither I nor Alex have been able to reproduce this locally :( :( :(

@matklad
Copy link
Member

matklad commented Dec 13, 2017

One thing I've noticed is that only builds with TOR_RUST_DEPENDENCIES=true fail: https://travis-ci.org/tlyu/tor/builds/315398991

@carols10cents
Copy link
Member Author

@isislovecruft what effect does the TOR_RUST_DEPENDENCIES env var have?

@carols10cents
Copy link
Member Author

AHA https://github.com/tlyu/tor/blob/master/doc/HACKING/GettingStartedRust.md it turns on a use of cargo-vendor :) the plot thickens!!

@alexcrichton
Copy link
Member

I've reproduced this locally and confirmed that this is a regression due to #4767

alexcrichton added a commit to alexcrichton/cargo that referenced this issue Dec 13, 2017
This commit alters the logic to bail out on probing for `CARGO_HOME` to
do it a little later rather than early on in the loop iteration, notably
allowing members to reside in `CARGO_HOME` itself.

Closes rust-lang#4815
@alexcrichton
Copy link
Member

I've posted a fix at #4816

@isislovecruft for a quick fix deleting this line should fix the regression and I think keep the build working (--frozen shouldn't strictly require that change of env var), or you could do something like set CARGO_HOME to /tmp (or something like that). In any case we can hopefully get a fix into nightlies pretty soon!

bors added a commit that referenced this issue Dec 13, 2017
Defer bailing out workspace root probing

This commit alters the logic to bail out on probing for `CARGO_HOME` to
do it a little later rather than early on in the loop iteration, notably
allowing members to reside in `CARGO_HOME` itself.

Closes #4815
@isislovecruft
Copy link

TOR_RUST_DEPENDENCIES, when present, should point to a repo containing vendored dependencies (using cargo-vendor), as documented here. The repo is hosted (for now) at https://gitweb.torproject.org/user/Sebastian/tor-rust-dependencies.git and it only contains the libc dependency. If TOR_RUST_DEPENDENCIES isn't present, then the --enable-cargo-online-mode flag must be passed to ./configure, which tells cargo to run without --frozen.

@isislovecruft
Copy link

Oh nice, and @carols10cents and @alexcrichton already figured it out by the time I got here to respond! :D

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants