Bug 26040 - Update candidate: rust 1.40.0
Summary: Update candidate: rust 1.40.0
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 7
Hardware: All Linux
Priority: Normal minor
Target Milestone: ---
Assignee: QA Team
QA Contact:
URL:
Whiteboard: MGA7-64-OK
Keywords:
Depends on:
Blocks:
 
Reported: 2020-01-08 21:34 CET by Rémi Verschelde
Modified: 2020-01-25 00:30 CET (History)
4 users (show)

See Also:
Source RPM: rust-1.35.0-1.mga7
CVE:
Status comment:


Attachments

Description Rémi Verschelde 2020-01-08 21:34:05 CET
Here's an update candidate for Rust 1.40.0, from our current 1.35.0.

Rust is still a rapidly evolving language and since we don't have many applications using it, it's a fairly risk-free update.

We do have firefox (and thunderbird?) built against rust, so we need to ensure that our currently packaged version, and future versions we might upgrade to, are able to build against rust 1.40.0.

Do you have any idea about that Thierry? Mozilla used to have this documented but it's no longer updated: https://wiki.mozilla.org/Rust_Update_Policy_for_Firefox


Advisory:
=========

Updated rust packages bring latest stable release

  This update provides Rust 1.40.0 and Cargo 1.40.0, which are the current
  stable versions released on August 2, 2018. See the release announcement
  for more details.

References:
 - https://blog.rust-lang.org/2019/07/04/Rust-1.36.0.html
 - https://blog.rust-lang.org/2019/08/15/Rust-1.37.0.html
 - https://blog.rust-lang.org/2019/09/26/Rust-1.38.0.html
 - https://blog.rust-lang.org/2019/11/07/Rust-1.39.0.html
 - https://blog.rust-lang.org/2019/12/19/Rust-1.40.0.html


RPMs in core/updates_testing:
=============================

cargo-1.40.0-1.mga7
cargo-doc-1.40.0-1.mga7

clippy-1.40.0-1.mga7

rust-1.40.0-1.mga7
rust-analysis-1.40.0-1.mga7
rust-debugger-common-1.40.0-1.mga7
rust-doc-1.40.0-1.mga7
rust-gdb-1.40.0-1.mga7
rust-lldb-1.40.0-1.mga7
rust-src-1.40.0-1.mga7
rust-std-static-1.40.0-1.mga7

rls-1.40.0-1.mga7

rustfmt-1.40.0-1.mga7


SRPMs in core/updates_testing:
==============================

- rust-1.40.0-1.mga7


Testing procedure:
==================

Bug 22882 comment 1
Comment 1 Rémi Verschelde 2020-01-08 21:34:41 CET
Forgot to CC Thierry - see my question about rust vs firefox versioning above.

CC: (none) => thierry.vignaud

Comment 2 Thierry Vignaud 2020-01-09 00:00:02 CET
I don't know.
I would say the easy/hard way is just for you try to locally rebuild mga7's with rust-1.40 :-)
But this has already be done on BS, so it's OK at build time.
We didn't got any reports that current build of ff in updates_testing is broken but you could test it locally and if that's OK, we're in the good.

On the other hand, why should we want to update rust?
For support?

BTW, "which are the current stable versions released on August 2, 2018. "
should be BTW, "which are the current stable versions released on December 19, 2019. "
Comment 3 Len Lawrence 2020-01-09 02:01:12 CET
Mageia7, x86_64.

Discovered a strange situation when trying toinstall current packages from core updates: rust and cargo were already at 1.38 but core updates wanted to install version 1.35 packages so it ended up like this:
cargo-doc-1.35.0-1.mga7
cargo-1.38.0-1.mga7
rust-gdb-1.35.0-1.mga7
rust-src-1.35.0-1.mga7
rust-1.38.0-1.mga7
rustfmt-1.35.0-1.mga7
rust-srpm-macros-9-1.mga7
rust-lldb-1.35.0-1.mga7
rust-std-static-1.38.0-1.mga7
rust-debugger-common-1.35.0-1.mga7
rust-doc-1.35.0-1.mga7

About to see what happens with the updates.

CC: (none) => tarazed25

Comment 4 Len Lawrence 2020-01-09 02:08:41 CET
The updates were fine - no problems.  All 13 packages at version 1.40.
Testing later.
Comment 5 Len Lawrence 2020-01-09 02:13:47 CET
The environment had already been deployed for other rust runs.
lcl@difda:rust-hello_world $ cargo build
   Compiling hello_world v0.0.1 (/data/qa/rust/rust-hello_world)
    Finished dev [unoptimized + debuginfo] target(s) in 0.96s
lcl@difda:rust-hello_world $ cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.01s
     Running `target/debug/hello_world`
Hello World!
I'm a Rustacean!

Shall try to find something more interesting in 'Klabnik and Nichols'.
Comment 6 Len Lawrence 2020-01-09 02:36:31 CET
$ rustfmt -v src/main.rs
Formatting /data/qa/rust/rust-hello_world/src/main.rs
Spent 0.000 secs in the parsing phase, and 0.000 secs in the formatting phase

$ cargo install ripgrep --force
    Updating crates.io index
  Downloaded ripgrep v11.0.2
  Downloaded 1 crate (243.3 KB) in 1.68s
  Installing ripgrep v11.0.2
[...]
   Compiling grep-printer v0.1.3
   Compiling grep v0.2.4
    Finished release [optimized + debuginfo] target(s) in 1m 41s
   Replacing /home/lcl/.cargo/bin/rg
    Replaced package `ripgrep v0.10.0` with `ripgrep v11.0.2` (executable `rg`)

That grabbed 7 of the 8 cores.

$ rg --version
ripgrep 11.0.2
-SIMD -AVX (compiled)
+SIMD +AVX (runtime)

$ rg cargo
report.23328
6:$ cargo install ripgrep --force
16:   Replacing /home/lcl/.cargo/bin/rg
18:$ ls .cargo
20:$ ls .cargo/bin
28:$ rg cargo
30:3457:cargo (0.0.1)
31:3458:cargowise (0.8.4)
32:7072:escargot (0.0.3)
33:14962:motr-cargo (0.0.2)
36:2039:rice, and soya beans.  Only the transport of bulk cargoes was
......

That is probably enough for an OK.

Whiteboard: (none) => MGA7-64-OK

Comment 7 Rémi Verschelde 2020-01-09 08:46:56 CET
(In reply to Thierry Vignaud from comment #2)
> I would say the easy/hard way is just for you try to locally rebuild mga7's
> with rust-1.40 :-)
> But this has already be done on BS, so it's OK at build time.
> We didn't got any reports that current build of ff in updates_testing is
> broken but you could test it locally and if that's OK, we're in the good.

Sounds good, I'll give it a try.
I forgot indeed that since we've had updated rust in core/updates_testing for a while current FF builds would already have picked it up. Now we kind of *have* to do the Rust upgrade to be consistent :P

(In reply to Thierry Vignaud from comment #2)
> On the other hand, why should we want to update rust?
> For support?

Mostly because any Rust users on Mageia 7 (me included) would typically want to have the latest upstream version. There's not much love/support for older releases in the Rust ecosystem so far, so people tend to always upgrade forward every 6 weeks.

Of course it's not a must-have since people can use `rustup` to download the latest stable or beta versions of the compiler, but Fedora also seems to always push latest rust to previous releases (including F30 and EPEL7), so since we sync with them we might as well do the same for easier support.

And since Mozilla doesn't seem to have a Rust version freeze policy for Firefox anymore, I guess that we have less risks of failed Firefox builds if we keep Rust up-to-date... but that's just a guess, maybe that's not true for ESR.

(In reply to Thierry Vignaud from comment #2) 
> BTW, "which are the current stable versions released on August 2, 2018. "
> should be BTW, "which are the current stable versions released on December
> 19, 2019. "

Thanks, fixed advisory:

Advisory:
=========

Updated rust packages bring latest stable release

  This update provides Rust 1.40.0 and Cargo 1.40.0, which are the current
  stable versions released on December 19, 2019. See the release announcements
  since Mageia 7's previous 1.35.0 version for more details.

References:
 - https://blog.rust-lang.org/2019/07/04/Rust-1.36.0.html
 - https://blog.rust-lang.org/2019/08/15/Rust-1.37.0.html
 - https://blog.rust-lang.org/2019/09/26/Rust-1.38.0.html
 - https://blog.rust-lang.org/2019/11/07/Rust-1.39.0.html
 - https://blog.rust-lang.org/2019/12/19/Rust-1.40.0.html
Comment 8 Rémi Verschelde 2020-01-09 08:53:49 CET
Tested the Firefox update (bug 26027) built against this version of Rust, it seems to work fine so far.
Comment 9 Thomas Backlund 2020-01-12 00:29:37 CET
Needs verification on 32bit that it still works on non-sse hw

CC: (none) => tmb

Comment 10 Thomas Andrews 2020-01-15 19:46:05 CET
Do we have anybody still operating such a beast? I have 32-bit hardware, but it's a P4, supporting sse and sse2.

CC: (none) => andrewsfarm

Comment 11 Len Lawrence 2020-01-25 00:30:23 CET
@tmb in response to comment 9.  
It looks like QA have no means of testing such hardware so can we simply accept this update as it is?

Note You need to log in before you can comment on or make changes to this bug.