-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
cargo --frozen requires the cargo home to be writable #7147
Labels
C-bug
Category: bug
Comments
glandium
changed the title
cargo --frozen requires the cargo home to exist
cargo --frozen requires the cargo home to be writable
Jul 19, 2019
I guess the problem can be summarized as "cargo fails when the package cache lock doesn't exist and can't be created". |
alexcrichton
added a commit
to alexcrichton/cargo
that referenced
this issue
Jul 19, 2019
This commit updates support from rust-lang#6940 to not only gracefully handle situations where the lock can be acquired in readonly but not read/write mode but also handle situations where even a readonly lock can't be acquired. If a readonly lock can't be acquired (and the read/write failed) then we likely can't touch anything in the directory, so there's no value gained from locking anyway. Closes rust-lang#7147
bors
added a commit
that referenced
this issue
Jul 19, 2019
Don't fail if we can't acquire readonly lock This commit updates support from #6940 to not only gracefully handle situations where the lock can be acquired in readonly but not read/write mode but also handle situations where even a readonly lock can't be acquired. If a readonly lock can't be acquired (and the read/write failed) then we likely can't touch anything in the directory, so there's no value gained from locking anyway. Closes #7147
ehuss
pushed a commit
to ehuss/cargo
that referenced
this issue
Jul 23, 2019
This commit updates support from rust-lang#6940 to not only gracefully handle situations where the lock can be acquired in readonly but not read/write mode but also handle situations where even a readonly lock can't be acquired. If a readonly lock can't be acquired (and the read/write failed) then we likely can't touch anything in the directory, so there's no value gained from locking anyway. Closes rust-lang#7147
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Before whatever change #6940 was undoing, a non-existing
CARGO_HOME
worked with--frozen
. But despite #6940, upgrading cargo to 1.36/0.37 on Debian broke Firefox builds on Debian builders, where they now fail with:/sbuild-nonexistent
comes fromHOME
being set to that value, and not existing, which ensures building packages doesn't rely on doing anything with$HOME
.A minimal reproducer:
The text was updated successfully, but these errors were encountered: