| Summary: | Update candidate: rust 1.40.0 | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Rémi Verschelde <rverschelde> |
| Component: | RPM Packages | Assignee: | QA Team <qa-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | minor | ||
| Priority: | Normal | CC: | andrewsfarm, mageia, sysadmin-bugs, tarazed25, thierry.vignaud, tmb, westel |
| Version: | 7 | Keywords: | advisory, validated_update |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | MGA7-64-OK, MGA7-32-OK | ||
| Source RPM: | rust-1.35.0-1.mga7 | CVE: | |
| Status comment: | |||
|
Description
Rémi Verschelde
2020-01-08 21:34:05 CET
Forgot to CC Thierry - see my question about rust vs firefox versioning above. CC:
(none) =>
thierry.vignaud 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. " 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 The updates were fine - no problems. All 13 packages at version 1.40. Testing later. 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'.
$ 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 (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 Tested the Firefox update (bug 26027) built against this version of Rust, it seems to work fine so far. Needs verification on 32bit that it still works on non-sse hw CC:
(none) =>
tmb 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 @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? Nope, we want it verified as we had to jump through some loops to get it to clean i586 before mga7 was released, so I guess someone need to fire up a qemu instance emulating legacy hw... If no-one gets to it I will try to get some time later this week... Thanks Thomas - let's hope somebody puts their hand up. Awesome, thanks for the help Martin. Validating Whiteboard:
MGA7-64-OK =>
MGA7-64-OK, MGA7-32-OK
Thomas Backlund
2020-01-31 20:30:36 CET
Keywords:
(none) =>
advisory An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGAA-2020-0040.html Resolution:
(none) =>
FIXED Mga7 on real 32bit hardware desktop(LXDE system)
free -m
total used free shared buff/cache available
Mem: 935 413 69 49 453 351
Swap: 6026 0 6026
$ uname -r
5.4.16-desktop-1.mga7
$ lscpu
Architecture: i686
CPU op-mode(s): 32-bit
AMD Athlon(tm) XP 2400+
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext
3dnow cpuid 3dnowprefetch vmmcall
In order to satisfy the 'pkg-command(debuginfo-install)' dependency, one of the following packages is needed:
1- urpmi-debuginfo-install-8.2-8.mga7.noarch: debuginfo-install shim for urpmi (to install)
2- dnf-utils-4.0.7-1.mga7.noarch: Yum-utils CLI compatibility layer (to install)
What is your choice? (1-2) 1
To satisfy dependencies, the following packages are going to be installed:
Package Version Release Arch
(medium "Core Release (distrib1)")
compiler-rt 8.0.0 1.mga7 i586 (recommended)
gdb 8.2 8.mga7 i586
gdb-headless 8.2 8.mga7 i586
guile-runtime 2.0.14 3.mga7 i586
isl 0.18 1.mga7 i586
libatomic_ops1 7.6.10 1.mga7 i586
libbabeltrace1 1.5.6 1.mga7 i586
libclang8.0 8.0.0 1.mga7 i586
libgc1 7.6.4 2.mga7 i586
libguile2.0_22 2.0.14 3.mga7 i586
libipt1 1.4.4 3.mga7 i586
libisl15 0.18 1.mga7 i586
liblldb0 8.0.0 1.mga7 i586
libmpc3 1.1.0 3.mga7 i586
libomp 8.0.0 1.mga7 i586 (recommended)
libxcrypt-devel 4.4.6 1.mga7 i586
lldb 8.0.0 1.mga7 i586
python2-lldb 8.0.0 1.mga7 i586
python2-six 1.12.0 3.mga7 noarch
urpmi-debuginfo-install 8.2 8.mga7 noarch
(medium "Core Updates (distrib3)")
gcc 8.3.1 0.20191101.1> i586
gcc-cpp 8.3.1 0.20191101.1> i586
gcc-plugins 8.3.1 0.20191101.1> i586 (recommended)
glibc-devel 2.29 19.mga7 i586
libstdc++-devel 8.3.1 0.20191101.1> i586
(medium "Core Updates Testing (distrib5)")
cargo 1.40.0 1.mga7 i586
cargo-doc 1.40.0 1.mga7 noarch
clippy 1.40.0 1.mga7 i586
rls 1.40.0 1.mga7 i586
rust 1.40.0 1.mga7 i586
rust-analysis 1.40.0 1.mga7 i586
rust-debugger-common 1.40.0 1.mga7 noarch
rust-doc 1.40.0 1.mga7 i586
rust-gdb 1.40.0 1.mga7 noarch
rust-lldb 1.40.0 1.mga7 noarch
rust-src 1.40.0 1.mga7 noarch
rust-std-static 1.40.0 1.mga7 i586
rustfmt 1.40.0 1.mga7 i586
774MB of additional disk space will be used.
135MB of packages will be retrieved.
Proceed with the installation of the 38 packages? (Y/n)
[home@localhost rust-hello_world]$ cargo build
Compiling hello_world v0.0.1 (/home/home/Documents/Programmation/Rust/rust-hello_world)
Finished dev [unoptimized + debuginfo] target(s) in 11.51s
[home@localhost rust-hello_world]$ cargo run
Finished dev [unoptimized + debuginfo] target(s) in 0.05s
Running `target/debug/hello_world`
Hello World!
I'm a Rustacean!CC:
(none) =>
westel |