Repository navigation
rustup update fails on FreeBSD for nightly due to missing docs #49462
Copy link
Copy link
Closed
Labels
T-bootstrapRelevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)regression-from-stable-to-nightlyPerformance or correctness regression from stable to nightly.Performance or correctness regression from stable to nightly.
Description
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
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
T-bootstrapRelevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)regression-from-stable-to-nightlyPerformance or correctness regression from stable to nightly.Performance or correctness regression from stable to nightly.
Activity
kennytm commentedon Mar 28, 2018
I'm not sure if this should be fixed at
rust-central-stationlevel (release promotion --- hard-link/copy the x86_64 Linux docs to every other targets), orrustuplevel (make docs not an essential component).prisme60 commentedon Mar 29, 2018
It fails also on my raspberry pi:
tarka commentedon Mar 31, 2018
Same with armv7:
ctrlcctrlv commentedon Apr 4, 2018
Same problem here on
x86_64-unknown-freebsdshisoft commentedon Apr 5, 2018
Same problem on
nightly-aarch64-unknown-linux-gnuctrlcctrlv commentedon Apr 5, 2018
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 #49187 until it's figured out?
Mark-Simulacrum commentedon Apr 5, 2018
Cc @alexcrichton
alexcrichton commentedon Apr 5, 2018
I've attempted a mitigation of this at #49705 although I'm not certain it'll work
4 remaining items
ctrlcctrlv commentedon Apr 8, 2018
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 commentedon May 11, 2018
This issue is fixed on nightly, but still broken on stable. When will the fix be ported to stable?
alexreg commentedon May 11, 2018
@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 commentedon May 11, 2018
Is there a workaround to install 1.26.0 on FreeBSD (or any system that lacks the docs, like arm Linux) ?
alexreg commentedon May 11, 2018
It still installs fine, just missing the docs.
Edit: Nope, it just left the 1.25.0 installation on my system. My bad.
phyber commentedon May 11, 2018
How are you installing it via
rustupto get it to install properly?kennytm commentedon May 11, 2018
My preference is "no" though since it only affects tier 2+ platforms(cc @rust-lang/release)RUSTUP_DIST_SERVER=... rustup)?asomers commentedon May 11, 2018
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 commentedon May 11, 2018
@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 commentedon May 11, 2018
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 commentedon May 11, 2018
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 commentedon May 11, 2018
@phyber My mistake. I didn't realise it was bailing completely, and leaving the 1.25.0 stable installation on my system.
alexreg commentedon May 11, 2018
@Mark-Simulacrum Totally agree. I expected this behaviour already to be honest.
Filter out missing components from manifests