Add to sysadmins because will need to modify the time by hand like in webkit (I ignore the amount of time required)

https://bugs.mageia.org/show_bug.cgi?id=32202#c27

Add to Remi because is the rust packager

CC: (none) => rverschelde, sysadmin-bugs

Hi. I don’t have time to do that right now. If it is urgent, someone else needs to take over.

Created attachment 14593 [details]
Diff form current spec

With these changes, I get llvm17-suite build in aarch64 for me looks like the thing that did the trick is the change in cmake part

Reminder firefox 112 esr support
 
Ends in 01 Oct 2024

https://endoflife.date/firefox

Firefox 128 esr will need new rust to build in mageia 9

(In reply to katnatek from comment #4)
> Reminder firefox 112 esr support
>  
> Ends in 01 Oct 2024
> 
> https://endoflife.date/firefox
> 
> Firefox 128 esr will need new rust to build in mageia 9

112 esr -> 115 esr

Created attachment 14638 [details]
Update to llvm18

As newer chromium browser could require llvm18, I update the spec and rediff a patch

This i the diff from the current llvm17-suite spec and of course I call the spec llvm18-suite

I'm not sure if the Obsoletes are necessary, feel free to remove if not

Created attachment 14639 [details]
Rediif patch to detect mageia

Created attachment 14640 [details]
Update to llvm18 version 2

Sorry I forgot to update the  diff before upload, I add -fPIC to make it build in cauldron

Attachment 14638 is obsolete: 0 => 1

This update is urgently needed for
Bug 33443 - chromium-browser-stable new security issues

CC: (none) => chb0, fri
Severity: normal => major
Priority: Normal => High

(In reply to Morgan Leijström from comment #9)
> This update is urgently needed for
> Bug 33443 - chromium-browser-stable new security issues

Giuseppe like to jump to llvm19 but is giving some issues, I need to check if I can do something

Hi,

I think we should also carefully check if some patches were added to llvm, clang... for Cauldron and do not forget to add them also to llvmxx-suite for Mga9.

For example, Firefox 128.2 (ix86) compiles fine with llvm, clang... 17.0.6 for Cauldron but fails with llvm17-suite 17.0.6 for Mga9 (with the same crash of the compiler as with llvm 15.0.6, which is provided by default by Mga9).

The only differences I saw between the two are some patches that are present into llvm, clang... 17.0.6 for Cauldron but absent from llvm17-suite 17.0.6.

In the crash described above, I suspect the crash is fixed in Cauldron because of the patch "0001-PEI-Don-t-zero-out-noreg-operands.patch" for llvm but I am not totally sure as there are several patches for clang too.

Moreover, we must not forget to build llvmxx-suite for all arches, to be able to build the new version of rust for all arches, to be able to build Firefox and Thunderbird 128.2 for all arches.

Best regards,

Nico.

CC: (none) => nicolas.salguero

(In reply to Nicolas Salguero from comment #11)
> Hi,
> 
> I think we should also carefully check if some patches were added to llvm,
> clang... for Cauldron and do not forget to add them also to llvmxx-suite for
> Mga9.
> 
> For example, Firefox 128.2 (ix86) compiles fine with llvm, clang... 17.0.6
> for Cauldron but fails with llvm17-suite 17.0.6 for Mga9 (with the same
> crash of the compiler as with llvm 15.0.6, which is provided by default by
> Mga9).
> 
> The only differences I saw between the two are some patches that are present
> into llvm, clang... 17.0.6 for Cauldron but absent from llvm17-suite 17.0.6.
> 
> In the crash described above, I suspect the crash is fixed in Cauldron
> because of the patch "0001-PEI-Don-t-zero-out-noreg-operands.patch" for llvm
> but I am not totally sure as there are several patches for clang too.
> 

I will see what can I import to llvm18 and llvm19,perhaps that help with build issues in ix86 

> Moreover, we must not forget to build llvmxx-suite for all arches, to be
> able to build the new version of rust for all arches, to be able to build
> Firefox and Thunderbird 128.2 for all arches.
> 

I have that covered at less build for aarch64, I can't test for armv7hl as copr not offer that chroot and my system is not too powerful to try to build in it.

I'm tempted to reduce debug info also for x86_64 as takes too much time to build, I give 10hrs to my last attempt, and it dies for cauldron x86_64 at write packages stage

Created attachment 14671 [details]
Tweaked llvm19-suite-spec

Giuseppe 
I made some changes from llvm spec in cauldron and webkit2 to see if this could be built

Fails in copr for ix86 arches with

ld.lld: error: failed to open lib/libclang-cpp.so.19.1-rc4: Cannot allocate memory
clang-15: error: linker command failed with exit code 1 (use -v to see invocation)

Once the rebuild of llvm18-suite ends, I will test building with that llvm to see if something change

(In reply to katnatek from comment #13)

> Once the rebuild of llvm18-suite ends, I will test building with that llvm
> to see if something change

basically you plan a "two stage" building, which might have sense. Another possibility is to modify the SPEC file to allow two stage building in the same package, first stage -> bootstrap, then 2nd stage build using the compiler generated in stage1 build.

Note that using:

%undefine _include_frame_pointers

as in the SPEC file you attached, to have the side effect of speeding up building IIUC, doesn't seem having any effects on MGA (maybe works only on FC), as I see the -fomit-frame-pointer passed everywhere, despite that option, rather than -fno-omit-frame-pointer.

(In reply to Giuseppe Ghibò from comment #14)
> (In reply to katnatek from comment #13)
> 
> > Once the rebuild of llvm18-suite ends, I will test building with that llvm
> > to see if something change
> 
> basically you plan a "two stage" building, which might have sense. Another
> possibility is to modify the SPEC file to allow two stage building in the
> same package, first stage -> bootstrap, then 2nd stage build using the
> compiler generated in stage1 build.
> 
> Note that using:
> 
> %undefine _include_frame_pointers
> 
> as in the SPEC file you attached, to have the side effect of speeding up
> building IIUC, doesn't seem having any effects on MGA (maybe works only on
> FC), as I see the -fomit-frame-pointer passed everywhere, despite that
> option, rather than -fno-omit-frame-pointer.

I implement something like the 2-steps build in the llvm spec in cauldron, I'll inform the result and just if that not works I build it with the llvm18 already generated in my copr 

and will check that perhaps instead of undefine we need to set it to nil

(In reply to katnatek from comment #15)
> (In reply to Giuseppe Ghibò from comment #14)
> > (In reply to katnatek from comment #13)
> > 
> > > Once the rebuild of llvm18-suite ends, I will test building with that llvm
> > > to see if something change
> > 
> > basically you plan a "two stage" building, which might have sense. Another
> > possibility is to modify the SPEC file to allow two stage building in the
> > same package, first stage -> bootstrap, then 2nd stage build using the
> > compiler generated in stage1 build.
> > 
> > Note that using:
> > 
> > %undefine _include_frame_pointers
> > 
> > as in the SPEC file you attached, to have the side effect of speeding up
> > building IIUC, doesn't seem having any effects on MGA (maybe works only on
> > FC), as I see the -fomit-frame-pointer passed everywhere, despite that
> > option, rather than -fno-omit-frame-pointer.
> 
> I implement something like the 2-steps build in the llvm spec in cauldron,
> I'll inform the result and just if that not works I build it with the llvm18
> already generated in my copr 
> 
> and will check that perhaps instead of undefine we need to set it to nil


Here is a spec file, based on your old one, for llvm 19.1.0 that went successful building on copr for x86_64, i586, and aarch64 (no idea on %arm). It compiled successfully even without the omit-frame-pointer tweaking, which I think it's not necessary anymore at the moment. Curiously building took just 3 hours on aarch64, more than twice on x86_64 and i586. Feel free to improve it. It's not yet a two stage building but should work. I added the missed openmp support module which might be useful under certain circumstances. I also commented the extra -fPIC for %optflags, as I think default flag should actually be correct even without it:

https://copr-be.cloud.fedoraproject.org/results/ghibo/mageia9-bonus/mageia-9-x86_64/08053010-llvm19-suite/

https://copr-be.cloud.fedoraproject.org/results/ghibo/mageia9-bonus/mageia-9-i586/08053010-llvm19-suite/

https://copr-be.cloud.fedoraproject.org/results/ghibo/mageia9-bonus/mageia-9-aarch64/08053010-llvm19-suite/

(In reply to Giuseppe Ghibò from comment #16)
> (In reply to katnatek from comment #15)
> > (In reply to Giuseppe Ghibò from comment #14)
> > > (In reply to katnatek from comment #13)
> > > 
> > > > Once the rebuild of llvm18-suite ends, I will test building with that llvm
> > > > to see if something change
> > > 
> > > basically you plan a "two stage" building, which might have sense. Another
> > > possibility is to modify the SPEC file to allow two stage building in the
> > > same package, first stage -> bootstrap, then 2nd stage build using the
> > > compiler generated in stage1 build.
> > > 
> > > Note that using:
> > > 
> > > %undefine _include_frame_pointers
> > > 
> > > as in the SPEC file you attached, to have the side effect of speeding up
> > > building IIUC, doesn't seem having any effects on MGA (maybe works only on
> > > FC), as I see the -fomit-frame-pointer passed everywhere, despite that
> > > option, rather than -fno-omit-frame-pointer.
> > 
> > I implement something like the 2-steps build in the llvm spec in cauldron,
> > I'll inform the result and just if that not works I build it with the llvm18
> > already generated in my copr 
> > 
> > and will check that perhaps instead of undefine we need to set it to nil
> 
> 
> Here is a spec file, based on your old one, for llvm 19.1.0 that went
> successful building on copr for x86_64, i586, and aarch64 (no idea on %arm).
> It compiled successfully even without the omit-frame-pointer tweaking, which
> I think it's not necessary anymore at the moment. Curiously building took
> just 3 hours on aarch64, more than twice on x86_64 and i586. Feel free to
> improve it. It's not yet a two stage building but should work. I added the
> missed openmp support module which might be useful under certain
> circumstances. I also commented the extra -fPIC for %optflags, as I think
> default flag should actually be correct even without it:
> 
> https://copr-be.cloud.fedoraproject.org/results/ghibo/mageia9-bonus/mageia-9-
> x86_64/08053010-llvm19-suite/
> 
> https://copr-be.cloud.fedoraproject.org/results/ghibo/mageia9-bonus/mageia-9-
> i586/08053010-llvm19-suite/
> 
> https://copr-be.cloud.fedoraproject.org/results/ghibo/mageia9-bonus/mageia-9-
> aarch64/08053010-llvm19-suite/

Perhaps you save me some more rebuild as build llvm19 with llvm18 bring some interesting results , all mga9 builds did not generate debug info, and cauldron i686 fail with ld.lld: error: cannot open crtbegin_so.o: No such file or directory and complains about the compiler not pass a single test, now I need to check if I can build firefox for mageia 9 with llvm19 generated by you

(In reply to katnatek from comment #17)
> (In reply to Giuseppe Ghibò from comment #16)
> Perhaps you save me some more rebuild as build llvm19 with llvm18 bring some
> interesting results , all mga9 builds did not generate debug info, and
> cauldron i686 fail with ld.lld: error: cannot open crtbegin_so.o: No such
> file or directory and complains about the compiler not pass a single test,
> now I need to check if I can build firefox for mageia 9 with llvm19
> generated by you

This is the fail in cauldron i686 if you are interested 

-- The C compiler identification is Clang 18.1.8
-- The CXX compiler identification is Clang 18.1.8
-- The ASM compiler identification is Clang with GNU-like command-line
-- Found assembler: /usr/lib/llvm18/bin/clang
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - failed
-- Check for working C compiler: /usr/lib/llvm18/bin/clang
-- Check for working C compiler: /usr/lib/llvm18/bin/clang - broken
-- Configuring incomplete, errors occurred!
CMake Error at /usr/share/cmake/Modules/CMakeTestCCompiler.cmake:67 (message):
  The C compiler

    "/usr/lib/llvm18/bin/clang"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: '/builddir/build/BUILD/llvm-project-llvmorg-19.1.0/build/CMakeFiles/CMakeScratch/TryCompile-fi0auY'
    
    Run Build Command(s): /usr/bin/ninja -v cmTC_5a2a9
    [1/2] /usr/lib/llvm18/bin/clang   -O2 -g -pipe -Wformat -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -fomit-frame-pointer -m32 -march=i686 -msse2 -mtune=generic -mfpmath=sse -mstackrealign -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection=full -fPIC -MD -MT CMakeFiles/cmTC_5a2a9.dir/testCCompiler.c.o -MF CMakeFiles/cmTC_5a2a9.dir/testCCompiler.c.o.d -o CMakeFiles/cmTC_5a2a9.dir/testCCompiler.c.o -c /builddir/build/BUILD/llvm-project-llvmorg-19.1.0/build/CMakeFiles/CMakeScratch/TryCompile-fi0auY/testCCompiler.c
    clang: warning: argument unused during compilation: '-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1' [-Wunused-command-line-argument]
    [2/2] : && /usr/lib/llvm18/bin/clang -O2 -g -pipe -Wformat -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -fomit-frame-pointer -m32 -march=i686 -msse2 -mtune=generic -mfpmath=sse -mstackrealign -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection=full -fPIC -Wl,--as-needed -Wl,--no-undefined -Wl,-z,relro -Wl,-z,now -Wl,-O1 -Wl,--build-id=sha1 -Wl,--enable-new-dtags -specs=/usr/lib/rpm/redhat/redhat-hardened-ld CMakeFiles/cmTC_5a2a9.dir/testCCompiler.c.o -o cmTC_5a2a9   && :
    FAILED: cmTC_5a2a9 
    : && /usr/lib/llvm18/bin/clang -O2 -g -pipe -Wformat -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -fomit-frame-pointer -m32 -march=i686 -msse2 -mtune=generic -mfpmath=sse -mstackrealign -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection=full -fPIC -Wl,--as-needed -Wl,--no-undefined -Wl,-z,relro -Wl,-z,now -Wl,-O1 -Wl,--build-id=sha1 -Wl,--enable-new-dtags -specs=/usr/lib/rpm/redhat/redhat-hardened-ld CMakeFiles/cmTC_5a2a9.dir/testCCompiler.c.o -o cmTC_5a2a9   && :
    clang: warning: argument unused during compilation: '-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1' [-Wunused-command-line-argument]
    clang: warning: argument unused during compilation: '-specs=/usr/lib/rpm/redhat/redhat-hardened-ld' [-Wunused-command-line-argument]
    ld.lld: error: cannot open crtbeginS.o: No such file or directory
    ld.lld: error: unable to find library -lgcc
    ld.lld: error: unable to find library -lgcc_s
    ld.lld: error: unable to find library -lgcc
    ld.lld: error: unable to find library -lgcc_s
    ld.lld: error: cannot open crtendS.o: No such file or directory
    clang: error: linker command failed with exit code 1 (use -v to see invocation)
    ninja: build stopped: subcommand failed.
    

  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:45 (project)

(In reply to Giuseppe Ghibò from comment #16)
> (In reply to katnatek from comment #15)
> > (In reply to Giuseppe Ghibò from comment #14)
> > > (In reply to katnatek from comment #13)
> > > 
> > > > Once the rebuild of llvm18-suite ends, I will test building with that llvm
> > > > to see if something change
> > > 
> > > basically you plan a "two stage" building, which might have sense. Another
> > > possibility is to modify the SPEC file to allow two stage building in the
> > > same package, first stage -> bootstrap, then 2nd stage build using the
> > > compiler generated in stage1 build.
> > > 
> > > Note that using:
> > > 
> > > %undefine _include_frame_pointers
> > > 
> > > as in the SPEC file you attached, to have the side effect of speeding up
> > > building IIUC, doesn't seem having any effects on MGA (maybe works only on
> > > FC), as I see the -fomit-frame-pointer passed everywhere, despite that
> > > option, rather than -fno-omit-frame-pointer.
> > 
> > I implement something like the 2-steps build in the llvm spec in cauldron,
> > I'll inform the result and just if that not works I build it with the llvm18
> > already generated in my copr 
> > 
> > and will check that perhaps instead of undefine we need to set it to nil
> 
> 
> Here is a spec file, based on your old one, for llvm 19.1.0 that went
> successful building on copr for x86_64, i586, and aarch64 (no idea on %arm).
> It compiled successfully even without the omit-frame-pointer tweaking, which
> I think it's not necessary anymore at the moment. Curiously building took
> just 3 hours on aarch64, more than twice on x86_64 and i586. Feel free to
> improve it. It's not yet a two stage building but should work. I added the
> missed openmp support module which might be useful under certain
> circumstances. I also commented the extra -fPIC for %optflags, as I think
> default flag should actually be correct even without it:
> 
> https://copr-be.cloud.fedoraproject.org/results/ghibo/mageia9-bonus/mageia-9-
> x86_64/08053010-llvm19-suite/
> 
> https://copr-be.cloud.fedoraproject.org/results/ghibo/mageia9-bonus/mageia-9-
> i586/08053010-llvm19-suite/
> 
> https://copr-be.cloud.fedoraproject.org/results/ghibo/mageia9-bonus/mageia-9-
> aarch64/08053010-llvm19-suite/
We can proceed with your spec, I use without issues to build Firefox i586 for mageia 9
I have to explicit BuildRequire llvm19–suite even if the package should be fetched but could be a weird issue with dnf or the method used to build
I assing this to you

Assignee: pkg-bugs => ghibomgx
CC: ghibomgx => (none)

https://bugs.mageia.org/show_bug.cgi?id=33322(In reply to katnatek from comment #19)

> We can proceed with your spec, I use without issues to build Firefox i586
> for mageia 9
> I have to explicit BuildRequire llvm19–suite even if the package should be
> fetched but could be a weird issue with dnf or the method used to build
> I assing this to you

I've not followed the whole story, I thought the newer llvm*-suite was needed to build (or trying to build) newer chromium-browser-128...

As for firefox I didn't knew why firefox i586 requires to be built with clang (according to buildflags we were already using it for ffox i586's 115.13), while 64bit version compiles with gcc. Anyway...

As for BuildRequires, I think it's right to have it explicity specified when required, as llvm17(19)-suite is not a system compiler and hasn't any library from its toolchain exposed to system /usr/lib64/ level (nor it should). Basically it should be used when we are sure all of the llvm required libraries in the binaries produced are statically linked.

(In reply to Giuseppe Ghibò from comment #20)
> I've not followed the whole story, I thought the newer llvm*-suite was
> needed to build (or trying to build) newer chromium-browser-128...
> 
> As for firefox I didn't knew why firefox i586 requires to be built with
> clang (according to buildflags we were already using it for ffox i586's
> 115.13), while 64bit version compiles with gcc. Anyway...
> 
> As for BuildRequires, I think it's right to have it explicity specified when
> required, as llvm17(19)-suite is not a system compiler and hasn't any
> library from its toolchain exposed to system /usr/lib64/ level (nor it
> should). Basically it should be used when we are sure all of the llvm
> required libraries in the binaries produced are statically linked.

Sorry for the lack of information in previous comment, as a way to test the llvm19-suite works in real case I build in copr adding your copr and testing repositories as external repositories, also try that in mock with the same result https://bugs.mageia.org/show_bug.cgi?id=33501#c16.

Some search points that the bin/clang things not be present but it should be as the 
llvm19-suite-devel requires llvm19-suite, but the logs show that not was the case so I have to explicit buildrequire the missing package to get it build :S, that is is my part of the history

About the difference of build tools between ix86 and x86_64, Nicolas is the regular packager so he should know that better

Blocks: (none) => 33443

News about this?

Reminder to sysadmins, llvm19-suite will need at less the same time that llvm17-suite,  60000 is the value I find in mail list

Timeout has been bumped.

CC: (none) => dan

(In reply to katnatek from comment #22)

> News about this?

Hadn't yet time to deal directly with this. Basically what we need to do is:

a) fork current llvm17-suite from svn in tree 9/updates/llvm17-suite to 9/update/llvm19-suite (use svn cp).

b) rename 9/llvm17-suite/llvm17-suite.spec file to llvm19-suite.spec

c) merge the llv19-suite.spec file proposed in my copr and the corresponding newer included patches.

d) remove from the spec file the line about undefining the frame-pointer which I has no effect (at least in mga9).

e) start the building, ensuring there is at least 70-80GB of free building space.

(In reply to Giuseppe Ghibò from comment #25)
> (In reply to katnatek from comment #22)
> 
> > News about this?
> 
> Hadn't yet time to deal directly with this. Basically what we need to do is:
> 
> a) fork current llvm17-suite from svn in tree 9/updates/llvm17-suite to
> 9/update/llvm19-suite (use svn cp).
> 
> b) rename 9/llvm17-suite/llvm17-suite.spec file to llvm19-suite.spec
> 
> c) merge the llv19-suite.spec file proposed in my copr and the corresponding
> newer included patches.
> 
> d) remove from the spec file the line about undefining the frame-pointer
> which I has no effect (at least in mga9).
> 
> e) start the building, ensuring there is at least 70-80GB of free building
> space.

I can't do that sorry, perhaps Nicolas Salguero could do it 
I link the src rpm here to can be used 

https://copr-be.cloud.fedoraproject.org/results/ghibo/mageia9-bonus/mageia-9-x86_64/08053010-llvm19-suite/llvm19-suite-19.1.0-0.5.mga9.src.rpm

Please don't remove from your copr ;)

Hi,

llvm19-suite is now committed into SVN.  Could you check I did not miss anything, please?

Best regards,

Nico.

(In reply to Nicolas Salguero from comment #27)
> Hi,
> 
> llvm19-suite is now committed into SVN.  Could you check I did not miss
> anything, please?
> 
> Best regards,
> 
> Nico.

Yes, it's ok.

Fails building on armv7hl due to lack of memory, I'd add:

# reduce number of parallel building process for ninja
%ifarch %ix86 %arm
%global _smp_ncpus_max 1
%else
...

Sadly, the build also failed for i586.

Assignee: nicolas.salguero => pkg-bugs

(In reply to Nicolas Salguero from comment #30)

> Sadly, the build also failed for i586.

Pretty weird as i586 was building successfully on copr. I don't see the exact error in the i586 build logs, maybe it hit the timeout limit of 60000 seconds?

(In reply to Giuseppe Ghibò from comment #31)
> (In reply to Nicolas Salguero from comment #30)
> 
> > Sadly, the build also failed for i586.
> 
> Pretty weird as i586 was building successfully on copr. I don't see the
> exact error in the i586 build logs, maybe it hit the timeout limit of 60000
> seconds?

Killed! (probably because of the 36000 timeout)

Looks like the build don't respect the time assigned

(In reply to katnatek from comment #32)
> (In reply to Giuseppe Ghibò from comment #31)
> > (In reply to Nicolas Salguero from comment #30)
> > 
> > > Sadly, the build also failed for i586.
> > 
> > Pretty weird as i586 was building successfully on copr. I don't see the
> > exact error in the i586 build logs, maybe it hit the timeout limit of 60000
> > seconds?
> 
> Killed! (probably because of the 36000 timeout)
> 
> Looks like the build don't respect the time assigned

(In reply to Dan Fandrich from comment #24)
> Timeout has been bumped.

Please give a check about that, because i586 build dies after the new time (uses the default time I guess)

(In reply to Dan Fandrich from comment #24)
> Timeout has been bumped.

Can you check again. 

Was it bumped for llvm17-suite or llvm19-suite? We need llvm19-suite in this context, despite the bug title has llvm17-suite.

Plase bump to 86400.

(In reply to Giuseppe Ghibò from comment #34)
> (In reply to Dan Fandrich from comment #24)
> > Timeout has been bumped.
> 
> Can you check again. 
> 
> Was it bumped for llvm17-suite or llvm19-suite? We need llvm19-suite in this
> context, despite the bug title has llvm17-suite.
> 
> Plase bump to 86400.

As long as I can see in the corresponding place, Dan did the right thing and add the value for llvm19-suite, but the build for i586 not did honor to the configuration

As I recall, something like this happened a few months ago and the issue was that some of the build nodes were not getting updated by puppet. I'm not very familiar with how the build nodes are set up and I don't know the reason for this.

(In reply to Dan Fandrich from comment #36)
> As I recall, something like this happened a few months ago and the issue was
> that some of the build nodes were not getting updated by puppet. I'm not
> very familiar with how the build nodes are set up and I don't know the
> reason for this.

Good memory, in one WebKit2 report.

@Jani Valimaa, can you please help with this?
I see you help in similar issue with https://bugs.mageia.org/show_bug.cgi?id=32202

CC: (none) => jani.valimaa

There were manual modifications in puppet files in duvel and thus the changes from git weren't applied and delegated by puppet.

I have now synced all iurt configs on build nodes.

Built went successfull on aarch64, x86_64 and i586.

Building time seems to be 19 hours.

Failed on armv7hl, due to lack of memory, even with lowest number of threads. 

I'd try still an attempt on armv7hl adding the fix, where there is:

-DCLANG_DEFAULT_LINKER=lld \
%ifarch %ix86
	        -DLLVM_USE_LINKER=gold \

to use

-DCLANG_DEFAULT_LINKER=lld \
%ifarch %ix86 %arm
	        -DLLVM_USE_LINKER=gold \

That should fix it, and then try a rebuild.

More close, just include the ifnarch part of this suggestion if Giuseppe can't detect why is not generating gdb for armv7hl 

From line 287 

%files -n %libname
%ifarch x86_64
%{install_prefix}/lib/clang/%{llvm_major}*/bin/hwasan_symbolize
%endif
%{install_prefix}/lib/*.so.*
%{install_prefix}/lib/clang/%{llvm_major}*/include/*
%{install_prefix}/lib/clang/%{llvm_major}*/share/*.txt
%{install_prefix}/lib/*-mageia-linux-*/*
%ifnarch %arm
%{install_prefix}/share/gdb
%endif

I build with success for armv7hl with the suggested change

(In reply to katnatek from comment #41)

> I build with success for armv7hl with the suggested change

Then fine. 

I didn't know mgarepo could push a single arch without the others.

I'd add also the "BuildRequires: git-core" to the current SPEC which seems a thing missed in the config, probably not essential but could be useful for next builds.

As of missed files in arm, probably it's due to some missed tools or function. I'd to setup an arm7hl VM in qemu to check... (next...).

That dir contains python files related to openmp, maybe in the arm arch the systen is missing something, or is so.

I'd say it's OK with your fix for now.

(In reply to Giuseppe Ghibò from comment #42)
> (In reply to katnatek from comment #41)
> 
> > I build with success for armv7hl with the suggested change
> 
> Then fine. 
> 
> I didn't know mgarepo could push a single arch without the others.
I don't know if that is possible, I always see the build is done for all architectures

I build in other system with mock (I took lot more than the limit we set up, but I think is due how mock build for this architecture)

@Nicolas you not change

%{install_prefix}/lib/*-mageia-linux-gnu/*

to

%{install_prefix}/lib/*-mageia-linux-*/*

And the armv7hl fail again due that

Used to build firefox-128.3.1 for i586

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

Whiteboard: (none) => MGA9-32-OK

Interesting.

Since this is developer territory, I set out to test by updating over the old 64-bit packages, using QArepo. But that doesn't work, as an llvm19-suite-xxxx package is not considered an update for the corresponding llvm17-suite-xxxx package. I didn't think it would be, but I tried, anyway.

So I had to settle for a simple install. That worked, though on my test system I had to remove the previously-installed llvm17-suite packages to make enough room to install the llvm19-suite packages.

Katnatek, your list shouldn't include the debug packages if it is to be used in qarepo.

I'm giving this a 64-bit OK, based on my install and using comment 46 as a test of function.

Validating. (I can't help with the advisory. I don't have a clue here.)

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

(In reply to Thomas Andrews from comment #47)
> Interesting.
> 
> Since this is developer territory, I set out to test by updating over the
> old 64-bit packages, using QArepo. But that doesn't work, as an
> llvm19-suite-xxxx package is not considered an update for the corresponding
> llvm17-suite-xxxx package. I didn't think it would be, but I tried, anyway.
> 
> So I had to settle for a simple install. That worked, though on my test
> system I had to remove the previously-installed llvm17-suite packages to
> make enough room to install the llvm19-suite packages.
> 
> Katnatek, your list shouldn't include the debug packages if it is to be used
> in qarepo.
I see it too late to remove, I copy the generated files from https://pkgsubmit.mageia.org/

This update is missing an advisory.

(In reply to Dan Fandrich from comment #49)
> This update is missing an advisory.

I request help for that in comment#45

(In reply to Dan Fandrich from comment #49)
> This update is missing an advisory.

Tweak the 1st advisory for llvm17 https://advisories.mageia.org/MGAA-2024-0102.html
Changing what needed, I hope is fine I will can't fix errors until tomorrow

Keywords: (none) => advisory

(In reply to katnatek from comment #46)
> Used to build firefox-128.3.1 for i586
> 
> https://copr.fedorainfracloud.org/coprs/katnatek/mgaMentorship/build/8133397/

But it cannot build rust 1.76, at least without some modifications to rust code :-(

CC: (none) => nicolas.salguero

For rust 1.76, llvm17-suite is needed because llvm19 is too new.  So we will have a new build of llvm17-suite for all arches plus the new llvm19-suite.

(In reply to Nicolas Salguero from comment #53)
> For rust 1.76, llvm17-suite is needed because llvm19 is too new.  So we will
> have a new build of llvm17-suite for all arches plus the new llvm19-suite.

I see you update llvm17-suite with changes from llvm19-suite, but I must remember you that you suggest include this patch https://svnweb.mageia.org/packages/cauldron/llvm/current/SOURCES/0001-PEI-Don-t-zero-out-noreg-operands.patch?view=log

Hold this update one more time :(

A few notes. llvm 19.1.1 is out so maybe worthwhile to to upgrade 19.1.0 -> 19.1.1, it should work everything just by bumping the release number and refreshing the tarball.

For rust. Do we really need 1.76 or could it be bumped already to 1.81? Also FC is using patch for rust-1.81 for building with llvm 19.1.x. In the case in case 1.76 is required or don't want to bump to 1.81 yet it could be worthwhile to see if simply adaptable this patch to 1.76 (see: https://src.fedoraproject.org/rpms/rust/raw/rawhide/f/rustc-1.81.0-Update-to-LLVM-19.patch), just in case the building problem is there.

(In reply to Giuseppe Ghibò from comment #55)
> A few notes. llvm 19.1.1 is out so maybe worthwhile to to upgrade 19.1.0 ->
> 19.1.1, it should work everything just by bumping the release number and
> refreshing the tarball.
> 
> For rust. Do we really need 1.76 or could it be bumped already to 1.81? Also
> FC is using patch for rust-1.81 for building with llvm 19.1.x. In the case
> in case 1.76 is required or don't want to bump to 1.81 yet it could be
> worthwhile to see if simply adaptable this patch to 1.76 (see:
> https://src.fedoraproject.org/rpms/rust/raw/rawhide/f/rustc-1.81.0-Update-to-
> LLVM-19.patch), just in case the building problem is there.

The "problem" with rust is version N needs version N-1 to build, so we can't just jump to 1.81

You could keep llvm17-suite only in testing (not submit to QA), and use it to build successive rust versions in testing to reach the latest stable, using llvm19-suite.

I did a mix from squidf spec and current, need to test if works, I will keep in contact as soon as I can test

OK, looks like our changes make this generate more files, so I add the extra files and test again

More files need to be added, already working on it

Created attachment 14701 [details]
Fixed spec 2

Sorry Nicolas, this should be the good

Attachment 14700 is obsolete: 0 => 1

In my copr is finished for aarch64
And almost for i586 with spec in comment#62
x86_64 is also in final stage as soon as ends I'll test build something with llvm17 i586, sadly I can't verify for arm, will be necessarily test if is need to disable %{install_prefix}/share/gdb/* line for arm so in the worst case will need 2 builds more

Interesting firefox i586 fails with llvm17

But llvm17 builds rust with success, so builds llvm19 not was a waste of time :)
I hope this means when llvm17 finally be available for all arches we can proceed with rust for all arches

rust aarch64 build with llvm17 OK
firefox aarch64 build with llvm19 OK

Nicolas, I think once you can generate llvm17 for all architectures we finally can unstuck firefox and thunderbird for architectures != x86_64

I also get 
objcopy: unable to copy file '/builddir/build/BUILDROOT/llvm17-suite-17.0.6-2.5.mga9.aarch64/usr/lib64/llvm17/share/gdb/python/ompd/ompdModule.so'; reason: Permission denied 

in my build but that not abort the build for aarch64, I don't know what suggest

(In reply to katnatek from comment #67)
> I also get 
> objcopy: unable to copy file
> '/builddir/build/BUILDROOT/llvm17-suite-17.0.6-2.5.mga9.aarch64/usr/lib64/
> llvm17/share/gdb/python/ompd/ompdModule.so'; reason: Permission denied 
> 
> in my build but that not abort the build for aarch64, I don't know what
> suggest

I find this suggestion in https://bugzilla.redhat.com/show_bug.cgi?id=1046276

/usr/bin/chmod 755 %{buildroot}/%{install_prefix}/share/gdb/python/ompd/ompdModule.so

I will test ASAP before you send other build

/usr/bin/chmod 755 %{buildroot}/%{install_prefix}/share/gdb/python/ompd/ompdModule.so

Did the trick, I add the line between EOF and %files lines, but you can place where you like after %cmake_install

@sysadmins

armv7hl not reach end
Killed! (probably because of the 60000 timeout)

In one test that I could did with llvm19 it tooks ~ 28 hrs so please bump the time to

86400 as Giuseppe suggest in comment#34

commit a0853334c478eb6f595c72fd51af8dfb98b15c21
Author: Dan Fandrich <danf@...>
Date:   Thu Oct 17 11:59:30 2024 -0700

    Bump timeouts for llvm17-suite and llvm19-suite (mga#33322)
    
    60000 isn't enough for llvm19-suite at least.
---
 Commit Link:
   https://gitweb.mageia.org/infrastructure/puppet/commit/?id=a0853334c478eb6f595c72fd51af8dfb98b15c21

(In reply to Mageia Robot from comment #71)
> commit a0853334c478eb6f595c72fd51af8dfb98b15c21
> Author: Dan Fandrich <danf@...>
> Date:   Thu Oct 17 11:59:30 2024 -0700
> 
>     Bump timeouts for llvm17-suite and llvm19-suite (mga#33322)
>     
>     60000 isn't enough for llvm19-suite at least.
> ---
>  Commit Link:
>   
> https://gitweb.mageia.org/infrastructure/puppet/commit/
> ?id=a0853334c478eb6f595c72fd51af8dfb98b15c21

llvm19 not was necessary but thank you :)

Comment #34 said llvm19-suite. But I figured I'd do both just in case.

Note that it can take up to about 45 minutes for puppet changes to take effect. Do you want me to cancel the llvm17 build that just started in case it's too early?

(In reply to Dan Fandrich from comment #73)
> Comment #34 said llvm19-suite. But I figured I'd do both just in case.

Sorry I did mus specify that was just a parameter to compare and specify that the change is just for llvm17

 (In reply to Dan Fandrich from comment #74)
> Note that it can take up to about 45 minutes for puppet changes to take
> effect. Do you want me to cancel the llvm17 build that just started in case
> it's too early?

That is the decision of Nicolas, thanks again for the help

(In reply to katnatek from comment #75)
> (In reply to Dan Fandrich from comment #73)
> > Comment #34 said llvm19-suite. But I figured I'd do both just in case.
> 
> Sorry I did mus specify that was just a parameter to compare and specify
> that the change is just for llvm17
> 
>  (In reply to Dan Fandrich from comment #74)
> > Note that it can take up to about 45 minutes for puppet changes to take
> > effect. Do you want me to cancel the llvm17 build that just started in case
> > it's too early?
> 
> That is the decision of Nicolas, thanks again for the help

I mean, That is decision for Nicolas, just in case to not have another misunderstanding

84(In reply to Dan Fandrich from comment #74)

> Note that it can take up to about 45 minutes for puppet changes to take
> effect. Do you want me to cancel the llvm17 build that just started in case
> it's too early?

86400 shouldn't hurt for both, so I'd keep them both for future build (there is llvm19-suite 19.1.1 for instance once llvm17-suite will be completed for instance).

I wonder if mgarepo could have some modification to allow canceling the 
building from the same authors. Has anyone ever seen on its code?

That's the plan: https://ml.mageia.org/l/arc/dev/2024-05/msg00046.html  Feel free to implement it!

(In reply to Giuseppe Ghibò from comment #77)
> 84(In reply to Dan Fandrich from comment #74)
> 
> > Note that it can take up to about 45 minutes for puppet changes to take
> > effect. Do you want me to cancel the llvm17 build that just started in case
> > it's too early?
> 
> 86400 shouldn't hurt for both, so I'd keep them both for future build (there
> is llvm19-suite 19.1.1 for instance once llvm17-suite will be completed for
> instance).

Please not, It can be done later as update, but for the moment is more urgent bring supported firefox and thunderbird for architectures != x86_64, I used with success llvm17 to build rust for aarch64 and then llvm19 to build firefox for the same

(In reply to katnatek from comment #79)
> (In reply to Giuseppe Ghibò from comment #77)
> > 84(In reply to Dan Fandrich from comment #74)
> > 
> > > Note that it can take up to about 45 minutes for puppet changes to take
> > > effect. Do you want me to cancel the llvm17 build that just started in case
> > > it's too early?
> > 
> > 86400 shouldn't hurt for both, so I'd keep them both for future build (there
> > is llvm19-suite 19.1.1 for instance once llvm17-suite will be completed for
> > instance).
> 
> Please not, It can be done later as update, but for the moment is more
> urgent bring supported firefox and thunderbird for architectures != x86_64,
> I used with success llvm17 to build rust for aarch64 and then llvm19 to
> build firefox for the same

Yes, I mean after the cycle with ffox + tb + rust bootstrap + rust is completed.

Thank you all for keeping pushing these beasts forward. :)

List of packages in 9/core/updates_testing

lib(64)llvm19-suite-19.1.0-3.mga9
lib(64)llvm19-suite-devel-19.1.0-3.mga9
llvm19-suite-19.1.0-3.mga9
llvm19-suite-analyzer-19.1.0-3.mga9
llvm19-suite-polly-19.1.0-3.mga9
llvm19-suite-polly-devel-19.1.0-3.mga9
llvm19-suite-static-19.1.0-3.mga9
llvm19-suite-tools-extra-19.1.0-3.mga9

SRPM:
llvm19-suite-19.1.0-3.mga9


lib(64)llvm17-suite-17.0.6-2.7.mga9
lib(64)llvm17-suite-devel-17.0.6-2.7.mga9
llvm17-suite-17.0.6-2.7.mga9
llvm17-suite-analyzer-17.0.6-2.7.mga9.noarch.rpm
llvm17-suite-polly-17.0.6-2.7.mga9
llvm17-suite-polly-devel-17.0.6-2.7.mga9
llvm17-suite-static-17.0.6-2.7.mga9
llvm17-suite-tools-extra-17.0.6-2.7.mga9

SRPM:
llvm17-suite-17.0.6-2.7.mga9

llvm19 packages are already tested

Assignee: nicolas.salguero => qa-bugs

Build rust 1.76.0 for aarch64, i586, and x86_64 with llvm17 packages
works ok

Keywords: (none) => validated_update
Whiteboard: (none) => MGA9-64-OK,MGA9-32-OK

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

https://advisories.mageia.org/MGAA-2024-0214.html

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