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

cargo --frozen requires the cargo home to be writable #7147

Closed
glandium opened this issue Jul 19, 2019 · 1 comment · Fixed by #7149
Closed

cargo --frozen requires the cargo home to be writable #7147

glandium opened this issue Jul 19, 2019 · 1 comment · Fixed by #7149
Labels
C-bug Category: bug

Comments

@glandium
Copy link
Contributor

glandium commented Jul 19, 2019

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:

ERROR: Couldn't execute `cargo metadata` with manifest "/<<PKGBUILDDIR>>/toolkit/library/rust/Cargo.toml": Metadata(Output { status: ExitStatus(ExitStatus(25856)), stdout: "", stderr: "error: failed to acquire package cache lock\n\nCaused by:\n  failed to open: /sbuild-nonexistent/.cargo/.package-cache\n\nCaused by:\n  Permission denied (os error 13)\n" })
ERROR: Couldn't generate bindings for /<<PKGBUILDDIR>>/toolkit/library/rust.

/sbuild-nonexistent comes from HOME being set to that value, and not existing, which ensures building packages doesn't rely on doing anything with $HOME.

A minimal reproducer:

$ cargo new foo
     Created binary (application) `foo` package
$ cd foo
$ CARGO_HOME=/forbidden cargo build --frozen
error: failed to acquire package cache lock

Caused by:
  failed to open: /forbidden/.package-cache

Caused by:
  Permission denied (os error 13)
@glandium glandium added the C-bug Category: bug label Jul 19, 2019
@glandium glandium changed the title cargo --frozen requires the cargo home to exist cargo --frozen requires the cargo home to be writable Jul 19, 2019
@glandium
Copy link
Contributor Author

glandium commented 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
Labels
C-bug Category: bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant