rustup update fails on FreeBSD for nightly due to missing docs

[bdrewery]

This seems related to #49187:

This breaks rustup update as well with --force.

# rustup update
info: syncing channel updates for 'stable-x86_64-unknown-freebsd'
info: syncing channel updates for 'nightly-x86_64-unknown-freebsd'
info: latest update on 2018-03-28, rust version 1.26.0-nightly (9c9424de5 2018-03-27)
error: component 'rust-docs' for 'x86_64-unknown-freebsd' is unavailable for download
info: checking for self-updates

       stable-x86_64-unknown-freebsd unchanged - rustc 1.24.1 (d3ae9a9e0 2018-02-27)
  nightly-x86_64-unknown-freebsd update failed - rustc 1.26.0-nightly (75af15ee6 2018-03-20)

# RUST_BACKTRACE=1 rustup update --force
info: syncing channel updates for 'stable-x86_64-unknown-freebsd'
info: syncing channel updates for 'nightly-x86_64-unknown-freebsd'
info: latest update on 2018-03-28, rust version 1.26.0-nightly (9c9424de5 2018-03-27)
thread 'main' panicked at 'components available', /checkout/src/libcore/option.rs:874:4
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
             at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at /checkout/src/libstd/sys_common/backtrace.rs:68
   2: std::panicking::default_hook::{{closure}}
             at /checkout/src/libstd/sys_common/backtrace.rs:57
             at /checkout/src/libstd/panicking.rs:381
   3: std::panicking::default_hook
             at /checkout/src/libstd/panicking.rs:397
   4: std::panicking::rust_panic_with_hook
             at /checkout/src/libstd/panicking.rs:577
   5: std::panicking::begin_panic
             at /checkout/src/libstd/panicking.rs:538
   6: std::panicking::begin_panic_fmt
             at /checkout/src/libstd/panicking.rs:522
   7: rust_begin_unwind
             at /checkout/src/libstd/panicking.rs:498
   8: core::panicking::panic_fmt
             at /checkout/src/libcore/panicking.rs:71
   9: core::option::expect_failed
             at /checkout/src/libcore/option.rs:874
  10: rustup_dist::manifestation::Manifestation::update
  11: rustup_dist::dist::update_from_dist_
fatal runtime error: failed to initiate panic, error 5
zsh: abort (core dumped)  RUST_BACKTRACE=1 rustup update --force

[kennytm]

I'm not sure if this should be fixed at rust-central-station level (release promotion --- hard-link/copy the x86_64 Linux docs to every other targets), or rustup level (make docs not an essential component).

[prisme60]

It fails also on my raspberry pi:

[christian@alarmpi ~]$ rustup update nightly
info: syncing channel updates for 'nightly-arm-unknown-linux-gnueabihf'
260.7 KiB / 260.7 KiB (100 %)  50.7 KiB/s ETA:   0 s
info: latest update on 2018-03-29, rust version 1.26.0-nightly (e5277c145 2018-03-28)
error: component 'rust-docs' for 'arm-unknown-linux-gnueabihf' is unavailable for download

[tarka]

Same with armv7:

$ rustup install nightly
info: syncing channel updates for 'nightly-armv7-unknown-linux-gnueabihf'
info: latest update on 2018-03-31, rust version 1.26.0-nightly (80785a547 2018-03-30)
error: component 'rust-docs' for 'armv7-unknown-linux-gnueabihf' is unavailable for download

[ctrlcctrlv]

Same problem here on x86_64-unknown-freebsd

[shisoft]

Same problem on nightly-aarch64-unknown-linux-gnu

[ctrlcctrlv]

This sucks -- builds broken on major platforms for a week and no fix in sight. If we don't know how to fix it, why not just revert https://github.com/rust-lang/rust/pull/49187 until it's figured out?

[Mark-Simulacrum]

Cc @alexcrichton

[alexcrichton]

I've attempted a mitigation of this at https://github.com/rust-lang/rust/pull/49705 although I'm not certain it'll work

[kennytm]

Hi @bdrewery @prisme60 @tarka @ctrlcctrlv @shisoft, could you check if the bug has been fixed in the latest nightly version? Thanks!

[raviqqe]

Works well on 32-bit ARM Linux. Thanks.

> rustup default nightly
info: syncing channel updates for 'nightly-armv7-unknown-linux-gnueabihf'
info: latest update on 2018-04-07, rust version 1.27.0-nightly (eeea94c11 2018-04-06)
info: downloading component 'rustc'
info: downloading component 'rust-std'
info: downloading component 'cargo'
info: installing component 'rustc'
info: installing component 'rust-std'
info: installing component 'cargo'
info: default toolchain set to 'nightly-armv7-unknown-linux-gnueabihf'

  nightly-armv7-unknown-linux-gnueabihf installed - rustc 1.27.0-nightly (eeea94c11 2018-04-06)

> uname -a
Linux localhost 3.14.0 #1 SMP PREEMPT Mon Apr 2 22:10:50 PDT 2018 armv7l GNU/Linux

[tarka]

Looks good; thanks!

[ssmith@nethost:~] 130 $ rustup toolchain install nightly
info: syncing channel updates for 'nightly-armv7-unknown-linux-gnueabihf'
info: latest update on 2018-04-07, rust version 1.27.0-nightly (eeea94c11 2018-04-06)
info: downloading component 'rustc'
 50.5 MiB /  50.5 MiB (100 %)   6.5 MiB/s ETA:   0 s
info: downloading component 'rust-std'
 49.3 MiB /  49.3 MiB (100 %)   5.8 MiB/s ETA:   0 s
info: downloading component 'cargo'
  3.9 MiB /   3.9 MiB (100 %) 841.0 KiB/s ETA:   0 s
info: installing component 'rustc'
info: installing component 'rust-std'
info: installing component 'cargo'

  nightly-armv7-unknown-linux-gnueabihf installed - rustc 1.27.0-nightly (eeea94c11 2018-04-06)

[prisme60]

Ok for me too with raspberry Pi 1 B raspbian (armv6).
Thanks for the fix.

[ctrlcctrlv]

Also working fine on FreeBSD. Thanks a lot for fixing it. 👍

nightly-x86_64-unknown-freebsd installed - rustc 1.27.0-nightly (056f589fb 2018-04-07)

[asomers]

This issue is fixed on nightly, but still broken on stable. When will the fix be ported to stable?

[alexreg]

@asomers It's not a matter of "porting", but rather when Rust 1.27 is released. Rust 1.26.0 just came out a few hours ago, so the next version will come exactly 6 weeks from now, June 22. I doubt the fix will be backported for an already-released stable version, as unfortunate as it is.

[asomers]

Is there a workaround to install 1.26.0 on FreeBSD (or any system that lacks the docs, like arm Linux) ?

[alexreg]

It still installs fine, just missing the docs.

Edit: Nope, it just left the 1.25.0 installation on my system. My bad.

[phyber]

How are you installing it via rustup to get it to install properly?

$ rustup toolchain install stable
info: syncing channel updates for 'stable-x86_64-unknown-freebsd'
info: latest update on 2018-05-10, rust version 1.26.0 (a77568041 2018-05-07)
error: component 'rust-docs' for 'x86_64-unknown-freebsd' is unavailable for download

$ rustup toolchain install 1.26.0
info: syncing channel updates for '1.26.0-x86_64-unknown-freebsd'
info: latest update on 2018-05-10, rust version 1.26.0 (a77568041 2018-05-07)
error: component 'rust-docs' for 'x86_64-unknown-freebsd' is unavailable for download

[kennytm]

• Is it possible to modify https://static.rust-lang.org/dist/channel-rust-1.26.0.toml to fix it live? Or is this file immutable? (cc @rust-lang/infra)
• If the manifest is immutable, do we want to make a point version 1.26.1 for this? My preference is "no" though since it only affects tier 2+ platforms (cc @rust-lang/release)
• If we don't release 1.26.1, should we endorse a workaround in these 6 weeks (e.g. push the fixed manifest in a different server, and let user use RUSTUP_DIST_SERVER=... rustup)?

[asomers]

Rust's platform support page says that Tier 2 platforms are "required to have each of the following: Official binary releases are provided for the platform...". That, to me, suggests that a 1.26.1 release is required.
https://forge.rust-lang.org/platform-support.html

[kennytm]

@asomers Thanks for the correction. Though, technically the binaries (rustc, std, cargo) are available, it is just that the docs (which are not binaries) are missing and messed up rustup. </lawyer-hat>

[asomers]

Do you mean the binaries at the bottom of this page: https://www.rust-lang.org/en-US/other-installers.html ? I can't find any instructions on how to use those in a way that places nicely with an existing rustup installation. Is such a thing possible?

[Mark-Simulacrum]

I think the reasonable fix would be to make rustup able to take a flag or environment variable of some sort that would tell it to keep going despite missing components. This seems long-term useful and is probably not terribly difficult, though I am not familiar with internals.

[alexreg]

@phyber My mistake. I didn't realise it was bailing completely, and leaving the 1.25.0 stable installation on my system.

[alexreg]

I think the reasonable fix would be to make rustup able to take a flag or environment variable of some sort that would tell it to keep going despite missing components. This seems long-term useful and is probably not terribly difficult, though I am not familiar with internals.

@Mark-Simulacrum Totally agree. I expected this behaviour already to be honest.