$ rustup update 1.7.0
info: syncing channel updates for '1.7.0-x86_64-unknown-linux-gnu'
error: could not download file from 'https://static.rust-lang.org/dist/channel-rust-1.7.0.toml.sha256' to '/home/simon/tmp/rustup/tmp/t8x2esx8afoxnd_y_file
info: caused by: http request returned an unsuccessful status code: 404
Confirming, _all_ of the pre-1.8.0 channel description files (and corresponding hashfiles) are now missing from https://static.rust-lang.org/dist, so rustup.rs (and probably the old multirust?) now error when trying to install anything between 1.0 and 1.7, or when doing a bulk-update with these channel having been installed previously.
CC @brson @edunham
rustup is supposed to fallback to a different download strategy for versions prior to 1.8 (there are no manifest files for them), but it seems that fallback has broken recently.
Is this really fixed?
I tried installing v1.7.0 on a new machine today:
$ rustup toolchain install 1.7.0
info: syncing channel updates for '1.7.0-x86_64-unknown-linux-gnu'
error: could not download file from 'https://static.rust-lang.org/dist/channel-rust-1.7.0.toml.sha256' to '/home/jan/.multirust/tmp/x559c7gmth89ocy5_file
info: caused by: http request returned an unsuccessful status code: 403
I'm using the latest released rustup:
$ rustup --version
rustup 0.2.0 (57f335a 2016-06-21)
The commit that should have fixed this was merge before the release date (though that doesn't mean it was on that release, it probably is).
Can anyone confirm?
Edit: just noticed the URL errors with 403, so maybe something changed on how files are served that caused rustup to break since the fix seems to deal on how to handle a 404.
It was definitely working for a while, but yes it seems broken anew, differently.
I've noticed that https://static.rust-lang.org/dist/ now returns a 0-byte binary, whereas /dist//index.html still works. Then anything that should be 404 like /dist/foo is instead a 403.
I guess we could fix rustup so that 403 (or maybe any 4xx) status will also retry with the fallback. That's seems like a big kludge though...
Does it actually need a fallback mechanism? What if it was hardcoded for version < 1.8? Other than that a fallback on 4xx seems resonable.
But anyway, I understand it's not exactly a bug on rustup, but more on the distribution. Nonetheless something broke. What's the best way to bring people that work on the distribution to this conversation?
What if it was hardcoded for version < 1.8?
Ideally the fix should work for old nightlies too (#487). I suppose that could use a hardcoded date range.