rust packages seems to be maintained by various people and "nobody" do most, by https://pkgsubmit.mageia.org/data/maintdb.txt

Assignee: bugsquad => pkg-bugs
CC: (none) => fri

We need to know exactly the procedure used last time when we bumped from 1.70.0 then to 1.74.0 and to 1.76.0, as the changelog seems not smooth, e.g. we can see:

- try to build rust 1.76 for all arches
- Enable bootstrap
  Remove patches for the moment
- New version 1.77.2
- Downgrade to 1.76.0 to help bootstrap
- New version 1.78.0

so, apparently an attempt to bump to 1.78.0 and then to 1.77.2 seems to be done in first instance, then stopped to 1.76.0. E.g. were there problems with 1.78.0?

Some update, I tried a quick building for 1.77.0, as intermediate version towards 1.78.0, but got these errors:

WARNING: The `change-id` is missing in the `config.toml`. This means that you will not be able to track the major changes made to the bootstrap configurations.
NOTE: to silence this warning, add `change-id = 102579` at the top of `config.toml`
thread 'main' panicked at src/core/build_steps/compile.rs:435:13:
need LLVM sources available to build `compiler-rt`, but they weren't present; consider enabling `build.submodules = true` or disabling `optimized-compiler-builtins`

and hadn't time to further dig into. Anyone who has time/competence, please look at this.

(In reply to Giuseppe Ghibò from comment #3)
> Some update, I tried a quick building for 1.77.0, as intermediate version
> towards 1.78.0, but got these errors:
> 
> WARNING: The `change-id` is missing in the `config.toml`. This means that
> you will not be able to track the major changes made to the bootstrap
> configurations.
> NOTE: to silence this warning, add `change-id = 102579` at the top of
> `config.toml`
> thread 'main' panicked at src/core/build_steps/compile.rs:435:13:
> need LLVM sources available to build `compiler-rt`, but they weren't
> present; consider enabling `build.submodules = true` or disabling
> `optimized-compiler-builtins`
> 
> and hadn't time to further dig into. Anyone who has time/competence, please
> look at this.

I think I find something, building in my copr jump to 1.77.2 as still can be built with our current rust as I can see

Pass that part but
Finished dev [unoptimized] target(s) in 47.29s
thread 'main' panicked at src/core/build_steps/compile.rs:435:13:
need LLVM sources available to build `compiler-rt`, but they weren't present; consider enabling `build.submodules = true` or disabling `optimized-compiler-builtins`
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Build completed unsuccessfully in 0:00:47

https://copr.fedorainfracloud.org/coprs/katnatek/mgaMentorship/build/8883865/

If you want to dig, I'll check tomorrow

After reading by million time the
spec I think start to understanding
But test will be done at>= 18:00 UTC

Created attachment 14942 [details]
rust 1.77.2 spec candidate

Remy sorry to call you
But you say we can consult about this , for me is not detecting compiler-rt
Features from llvm-17-suite or something like that, but I can't go beyond this point Perhaps some of my changes are not needed, but I try to force use llvm17-suite

Building with bundled llvm finally go beyond the point where I was stuck
But really don't like to do that :S
I report results

As I guess, build with bundled llvm is not option for some architectures
I find something in OMDV, I am testing now

CC: rverschelde => (none)

(In reply to katnatek from comment #9)
> As I guess, build with bundled llvm is not option for some architectures
> I find something in OMDV, I am testing now

Thanks for your testing and efforts.

If I understand correctly the difficultes originate in the rust SPEC file (tight with the FC one) which unbundles most of the required Rust components (LLVM, SQLite, etc.) with system ones. That exposes of rapid components obsolescence, particulary on a distro with a longer release cycle than 6 months.

So, you've identified the core problem, and noticed that the SPEC file allows to utilize the unbundled rust for bootstrapping a newer version. So in the end the possibilites are to utilize the current bundled 'llvm-project' (i.e. bundled into rust/src/ source dir), or our entire llvm17-suite-17.0.6 as BuildRequires, which functions similarly to the internal's rust bundled version (but doesn't require recompiling every time). The observation that it might break building on other architectures (I guess armv7, due to poor memory availability) is also important, and explains the use of llvm-suite-19.1.0 in the current mga9's rust-1.76.0 changelog.

Given our target versions of 1.78.0 or 1.79.0, and the intermediate step of 1.77.2, I think we might use the llvm-suite-19.1.0 for now and monitor the build process. On the other hand rust 1.78.0 seems requiring at least llvm-18.1.2. Here is a list LLVM versions bundled with each Rust version:

*   1.77.2: llvm-17.0.6
*   1.78.0: llvm-18.1.2
*   1.79.0: llvm-18.1.7
*   1.80.0: llvm-18.1.7
...
*   1.85.1: llvm-19.1.7
*   1.86.0: llvm-19.1.7

(In reply to Giuseppe Ghibò from comment #10)
> (In reply to katnatek from comment #9)
> > As I guess, build with bundled llvm is not option for some architectures
> > I find something in OMDV, I am testing now
> 
> Thanks for your testing and efforts.
> 
> If I understand correctly the difficultes originate in the rust SPEC file
> (tight with the FC one) which unbundles most of the required Rust components
> (LLVM, SQLite, etc.) with system ones. That exposes of rapid components
> obsolescence, particulary on a distro with a longer release cycle than 6
> months.
> 
> So, you've identified the core problem, and noticed that the SPEC file
> allows to utilize the unbundled rust for bootstrapping a newer version. So
> in the end the possibilites are to utilize the current bundled
> 'llvm-project' (i.e. bundled into rust/src/ source dir), or our entire
> llvm17-suite-17.0.6 as BuildRequires, which functions similarly to the
> internal's rust bundled version (but doesn't require recompiling every
> time). The observation that it might break building on other architectures
> (I guess armv7, due to poor memory availability) is also important, and
> explains the use of llvm-suite-19.1.0 in the current mga9's rust-1.76.0
> changelog.
> 
> Given our target versions of 1.78.0 or 1.79.0, and the intermediate step of
> 1.77.2, I think we might use the llvm-suite-19.1.0 for now and monitor the
> build process. On the other hand rust 1.78.0 seems requiring at least
> llvm-18.1.2. Here is a list LLVM versions bundled with each Rust version:
> 
> *   1.77.2: llvm-17.0.6
> *   1.78.0: llvm-18.1.2
> *   1.79.0: llvm-18.1.7
> *   1.80.0: llvm-18.1.7
> ...
> *   1.85.1: llvm-19.1.7
> *   1.86.0: llvm-19.1.7

The solution was mire simply
I undo almost alk my changes

All the time the error message
was giving us a clue.
Is setting a build flag,
I did try but fail because not 
was the right name, in OMDV
find the solutio.
The build is success now
Just I want to try one more time
use the llvm17 profiler instead the
the llvm 15 as is done currently

Time to send it to real life
Send the build to BS

How to handle this update
In parts, ie
 QA 1.77.2 if pass
 Build if possible 1.78.0
 QA 1.78.0

Or can jump to 1.78.0 if builds and then QA 1.78.0?

CC: (none) => jani.valimaa, yvesbrungard

I think we can QA only the final version, not the intermediate steps.

I agree; only QA version to be released as update.

(In reply to Giuseppe Ghibò from comment #14)
> I think we can QA only the final version, not the intermediate steps.

I'm doing a minimal test building current firefox version
I don't know if worry about this messages in the build log

WARNING: Using a potentially old libstd. This may not behave well.
WARNING: Using a potentially old librustc. This may not behave well.
WARNING: Use `--keep-stage-std` if you want to rebuild the compiler when it changes

Are there logs from previous firefox build still available to check if they were already there?

(In reply to Giuseppe Ghibò from comment #17)
> Are there logs from previous firefox build still available to check if they
> were already there?

The message is from rust 1.77.2 sorry to not be clear

Then let's see how it would build the current firefox.

(In reply to Giuseppe Ghibò from comment #19)
> Then let's see how it would build the current firefox.

Looks like works, not ends yet for x86_64, but I start to work in 1.78.0

CC: jani.valimaa, yvesbrungard => (none)

Testing build 1.78.0 adapted from a revision of cauldron

rust 1.78.0 version tested building current firefox , this version is enough
or is mandatory to build 1.79.0?

For current mesa-25.0.3, rust 1.78.0 is enough.

Packages in 9/core/updates_testing

i586:
cargo-1.78.0-1.mga9.i586.rpm
clippy-1.78.0-1.mga9.i586.rpm
rust-1.78.0-1.mga9.i586.rpm
rust-analyzer-1.78.0-1.mga9.i586.rpm
rust-debugger-common-1.78.0-1.mga9.noarch.rpm
rust-doc-1.78.0-1.mga9.i586.rpm
rust-gdb-1.78.0-1.mga9.noarch.rpm
rust-lldb-1.78.0-1.mga9.noarch.rpm
rust-src-1.78.0-1.mga9.noarch.rpm
rust-std-static-1.78.0-1.mga9.i586.rpm
rust-std-static-i686-pc-windows-gnu-1.78.0-1.mga9.noarch.rpm
rust-std-static-wasm32-unknown-unknown-1.78.0-1.mga9.noarch.rpm
rust-std-static-wasm32-wasi-1.78.0-1.mga9.noarch.rpm
rust-std-static-wasm32-wasip1-1.78.0-1.mga9.noarch.rpm
rust-std-static-x86_64-pc-windows-gnu-1.78.0-1.mga9.noarch.rpm
rustfmt-1.78.0-1.mga9.i586.rpm

x86_64:
cargo-1.78.0-1.mga9.x86_64.rpm
clippy-1.78.0-1.mga9.x86_64.rpm
rust-1.78.0-1.mga9.x86_64.rpm
rust-analyzer-1.78.0-1.mga9.x86_64.rpm
rust-debugger-common-1.78.0-1.mga9.noarch.rpm
rust-doc-1.78.0-1.mga9.x86_64.rpm
rust-gdb-1.78.0-1.mga9.noarch.rpm
rust-lldb-1.78.0-1.mga9.noarch.rpm
rust-src-1.78.0-1.mga9.noarch.rpm
rust-std-static-1.78.0-1.mga9.x86_64.rpm
rust-std-static-i686-pc-windows-gnu-1.78.0-1.mga9.noarch.rpm
rust-std-static-wasm32-unknown-unknown-1.78.0-1.mga9.noarch.rpm
rust-std-static-wasm32-wasi-1.78.0-1.mga9.noarch.rpm
rust-std-static-wasm32-wasip1-1.78.0-1.mga9.noarch.rpm
rust-std-static-x86_64-pc-windows-gnu-1.78.0-1.mga9.noarch.rpm
rust-std-static-x86_64-unknown-none-1.78.0-1.mga9.x86_64.rpm
rust-std-static-x86_64-unknown-uefi-1.78.0-1.mga9.x86_64.rpm
rustfmt-1.78.0-1.mga9.x86_64.rpm


SRPM:
rust-1.78.0-1.mga9.src.rpm

Assignee: j.alberto.vc => qa-bugs

I already  build current firefox with this packages for i586, x86_64 and aarch64

Used to build czcawka 6.0.0-2 from cauldron in mageia 9

Compiled and run a simple Hello world example, that is OK. But the czcawka stuff is beyond me.

CC: (none) => herman.viaene

I don't know what more to test 
Looks OK to me, is tested in 3 architectures i586, x86_64, aarch64 
Building 2 srpms from mageia

CC: (none) => andrewsfarm, j.alberto.vc

I built mesa-25.0.3 in mga9 with it, and seems working ok.

Firefox warning messages are gone?

(In reply to Giuseppe Ghibò from comment #30)
> Firefox warning messages are gone?

The warnings were in the build of rust 1.77.2 , in the build of 1.78.0 no see
that warnings

Going by the previous few comments, I'm going ahead with OKs and validating, because it looks like we should have this ASAP.

I have questions that I almost hate to bring up, but...

The next Firefox is scheduled to be released in two weeks or so, with another one a month after that. Are we likely to need a newer rust, like 1.79.0, for one of those? And if so, should we start the process to update for it now, or wait?

Keywords: (none) => validated_update
Whiteboard: (none) => MGA9-32-OK MGA9-64-OK
CC: (none) => sysadmin-bugs

(In reply to Thomas Andrews from comment #32)
> Going by the previous few comments, I'm going ahead with OKs and validating,
> because it looks like we should have this ASAP.
> 
> I have questions that I almost hate to bring up, but...
> 
> The next Firefox is scheduled to be released in two weeks or so, with
> another one a month after that. Are we likely to need a newer rust, like
> 1.79.0, for one of those? And if so, should we start the process to update
> for it now, or wait?

Will burn that bridge if needed ;)

That is responsibility of Firefox maintainer, but If he makes similar petition
I'll help if I can, I get it the trick to modify cauldron revision of rust with the version we want to make it build in mageia 9, the 1.78.0 version spec is a few less pains to read than 1.77.2

(In reply to Thomas Andrews from comment #32)

> Going by the previous few comments, I'm going ahead with OKs and validating,
> because it looks like we should have this ASAP.
> 
> I have questions that I almost hate to bring up, but...
> 
> The next Firefox is scheduled to be released in two weeks or so, with
> another one a month after that. Are we likely to need a newer rust, like
> 1.79.0, for one of those? And if so, should we start the process to update
> for it now, or wait?

IMHO rust 1.78.0 is a big step forward. From what I see, it seems the next big projects might require rust beyond 1.80, perhaps around 1.82. I think we should could on 1.78.0 for now and keep an eye on the next releases. AFAIK, we've learned how to handle the upgrades. We might try some local builds from time to time to see if we can bump beyond rust 1.80.0, to check for any potential issues.

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

https://advisories.mageia.org/MGASA-2025-0136.html

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