Advisory from comment 0 added to SVN. Please remove the "advisory" keyword if it needs to be changed. It also helps when obsolete advisories are tagged as "obsolete"

Keywords: (none) => advisory
CC: (none) => marja11

Mageia9, x86_64
Updated all the packages without issues.  mingw packages pulled in.
Created an empty project directory and moved to it.
$ cargo install ripgrep --force
<That installed a load of things in ~/.cargo - 285 directories, 1283 files>
$ rg --version
ripgrep 14.0.3

features:-simd-accel,-pcre2
simd(compile):+SSE2,-SSSE3,-AVX2
simd(runtime):+SSE2,+SSSE3,+AVX2

PCRE2 is not available in this build of ripgrep.
$ cargo update
$ cargo run
   Compiling hello_world v0.0.1 (/run/media/lcl/Toshiba/qa/rust/project)
    Finished dev [unoptimized + debuginfo] target(s) in 0.16s
     Running `target/debug/hello_world`
Hello World!
I'm a Rustacean!
$ rustfmt -v src/main.rs
Formatting /run/media/lcl/Toshiba/qa/rust/project/src/main.rs
Spent 0.000 secs in the parsing phase, and 0.000 secs in the formatting phase
$ cargo doc --open
 Documenting hello_world v0.0.1 (/run/media/lcl/Toshiba/qa/rust/project)
    Finished dev [unoptimized + debuginfo] target(s) in 0.18s
     Opening /run/media/lcl/Toshiba/qa/rust/project/target/doc/hello_world/index.html

That last command created a Crate hello_world page in a browser.

Giving this the OK for 64-bit architectures.

CC: (none) => tarazed25
Whiteboard: (none) => MGA9-64-OK

Don't know where this came from:
$ cat panic_not.rs
fn main() {
    let a = vec!["".to_string()];
    a.iter()
        .enumerate()
        .take_while(|(_, &t)| false)
        .collect::<Vec<_>>();
}

Tried running it as suggested:
$ cargo -Zscript panic_not.rs
error: the `-Z` flag is only accepted on the nightly channel of Cargo, but this is the `stable` channel
See https://doc.rust-lang.org/book/appendix-07-nightly-rust.html for more information about Rust release channels.

So, not useful to QA but I guess it shows that the infrastructure works.

"We might want to test that important rust packages rebuild fine with this update candidate before pushing it to core/updates."

Hmmm. Not my area of expertise, not at all. 

What do you think, Len? I suspect your test wouldn't be considered an "important" package, but then I wouldn't know an "important rust package" if I tripped over it.

Is Remi's request beyond the scope of QA?

CC: (none) => andrewsfarm

(In reply to Thomas Andrews from comment #4)
> "We might want to test that important rust packages rebuild fine with this
> update candidate before pushing it to core/updates."
> 
> Hmmm. Not my area of expertise, not at all. 
> 
> What do you think, Len? I suspect your test wouldn't be considered an
> "important" package, but then I wouldn't know an "important rust package" if
> I tripped over it.
> 
> Is Remi's request beyond the scope of QA? 
The Len Lawrence's test in comment#2 is good to me considering the fedora's test case https://fedoraproject.org/wiki/QA:Testcase_rust_compile

Mid-air collision!

Nor do I know which packages they might be.  A recursive check on dependencies turns up hundreds of packages but they are all rust related anyway; e.g. rust-backtrace+dladdr-devel and cargo.  I remember vaguely that rust was mentioned in the rebuild of Firefox but it is very hazy.  If Rémi can give us examples we could only try a local rebuild if the procedure is as simple as that used to rebuild docker with go, otherwise packagers would need to be involved.  It is beginning to sound like a project.  I would be willing to try it even if it is essentially outside our remit.

In reply to katnatek in comment 5:
Thanks for the upvote but my view is a little different.  Since reliable compilation is at the heart of any operating system we do need to think beyond the "hello-world" paradigm and try to exercise them in real-world scenarios.  I suspect that a lot of that sort of testing has already been done behind the scenes before a new version hits the "market" - us, but it would give us confidence in adding OKs if such procedures were available.  

Similar considerations apply to running PoCs.  No doubt these are sometimes handled by packagers and many times they depend on frameworks which actually modify the software for testing, which some might consider an invalidation of the software.  I consider it in our remit to check the CVEs and attempt to run PoCs, at least some of them.  Other people may disagree with that.

Created attachment 14189 [details]
Latest czkawka in Mageia 9 x86_64

(In reply to Len Lawrence from comment #7)
> In reply to katnatek in comment 5:
> Thanks for the upvote but my view is a little different.  Since reliable
> compilation is at the heart of any operating system we do need to think
> beyond the "hello-world" paradigm and try to exercise them in real-world
> scenarios.  I suspect that a lot of that sort of testing has already been
> done behind the scenes before a new version hits the "market" - us, but it
> would give us confidence in adding OKs if such procedures were available. 

I install the testing packages and after also install the buildrequires I build the latest czkawka version https://github.com/qarmin/czkawka/releases/tag/6.1.0 , in my experience this program not build if you don't have a compatible rust version

I hope this is enough for you and Thomas ;)

In reply to katnatek in comment 8:

Good find!  Something strange at my end; czkawka-gui can be installed but no sign of czkawka itself, but I could get hold of the sources.

$ mgarepo co czkawka
A    czkawka/SOURCES
A    czkawka/SOURCES/sha1.lst
A    czkawka/SOURCES/cargo.config
A    czkawka/SOURCES/pack-cargo-vendor.sh
A    czkawka/SPECS
A    czkawka/SPECS/czkawka.spec
Checked out revision 2012641.
 
Anyway, since your rebuild succeeded testing looks complete.
From the spec file:
BuildRequires:  rust-packaging
BuildRequires:  rust
BuildRequires:  rust-src
BuildRequires:  cargo
BuildRequires:  cargo-c

You should add the OK.

s/czkawka-gui/czkawka_gui/

(In reply to Len Lawrence from comment #9)
> In reply to katnatek in comment 8:
> 
> Good find!  Something strange at my end; czkawka-gui can be installed but no
> sign of czkawka itself, but I could get hold of the sources.
> 
> $ mgarepo co czkawka
> A    czkawka/SOURCES
> A    czkawka/SOURCES/sha1.lst
> A    czkawka/SOURCES/cargo.config
> A    czkawka/SOURCES/pack-cargo-vendor.sh
> A    czkawka/SPECS
> A    czkawka/SPECS/czkawka.spec
> Checked out revision 2012641.
>  
> Anyway, since your rebuild succeeded testing looks complete.
> From the spec file:
> BuildRequires:  rust-packaging
> BuildRequires:  rust
> BuildRequires:  rust-src
> BuildRequires:  cargo
> BuildRequires:  cargo-c
> 
> You should add the OK.

The spec splits czkawka in czkawka-gui czkawka-cli

I probably would have sent it on with just Len's test had it not been for Remi's comment asking for a bit of extra scrutiny. And I think that katnatek's test fills the bill.

Thank you both.

Validating.

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGAA-2023-0133.html

Resolution: (none) => FIXED
Status: NEW => RESOLVED