Re: arm `rustdoc` Rust 1.85.0-only build error

["Gary Guo" <gary@garyguo.net>]

On Fri Apr 3, 2026 at 9:12 AM BST, Fabian Grünbichler wrote:
> On Tue, Mar 31, 2026, at 9:00 PM, Miguel Ojeda wrote:
>> Hi Christian, Russell, arm, Fabian,
>>
>> For Rust 1.85.0, for arm32, for the `rustdoc` target (i.e. all those
>> combined), I am seeing:
>>
>>       RUSTDOC   
>> .../1.85.0-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/lib.rs
>>     error: target feature `fp-armv8` cannot be toggled with 
>> `#[target_feature]`: Rust ties `fp-armv8` to `neon`
>>         --> 
>> .../1.85.0-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/../../stdarch/crates/core_arch/src/arm_shared/neon/generated.rs:7538:48
>>          |
>>     7538 | #[cfg_attr(target_arch = "arm", target_feature(enable = 
>> "fp-armv8,v8"))]
>>          |                                                
>> ^^^^^^^^^^^^^^^^^^^^^
>>
>> The issue is [1], was introduced in Rust 1.85.0 and was fixed already in
>> Rust 1.85.1 [2]:
>>
>>   Link: https://github.com/rust-lang/rust/issues/137366 [1]
>>   Link: https://github.com/rust-lang/rust/pull/137632 [2]
>>
>> It is unfortunate since our minimum is going to be 1.85.0 since that is
>> what Debian Stable has (even if patches may be on top) -- I generally
>> test the latest patch versions for each minor, but I noticed this since
>> I also test the actual minimum, and I am bumping it to 1.85.0.
>>
>> To be clear, it is likely almost no one actually cares about this, since
>> nobody complained yet, and this can easily be fixed using the already
>> released Rust 1.85.1.
>>
>> By the way, what is Debian's policy on upstream Rust patch versions?
>
> In unstable, we pull them in usually by virtue of lagging behind a bit anyway.
>
> In stable there is no policy per se - both importing a new smallish important
> upstream release, or cherry-picking patches are options in general. A few
> packages with clear upstream LTS policies are updated often (systemd, glibc,
> the kernel itself, firefox-esr and chromium would be the most popular
> examples). If there is no upstream stable release series that matches Debian
> stable policies, the usual approach is to do a targeted backport of just the
> fixes.
> lack of rustc LTS, usually there are no point releases for the version to be
> included in Debian stable anyway.
>
> It's up to the stable release managers how big of a delta is acceptable.
>
> I will check how the full diff for 1.85.1 looks like compared to just picking
> the rustdoc fix referenced above, and then file a stable update request. AFAIU
> either option works for you?

You can check diff here:
https://github.com/rust-lang/rust/compare/1.85.0...1.85.1

The change is not much, there is a library change although that's for Windows
only. The compiler and rustdoc changes are usually pretty harmless to backport.

I guess for Debian you cared about binary compatibility; in which case you
probably want to keep the compiler version number at 1.85.0, so the compiler
verison hash stays unchanged.

Best,
Gary