NB 
in the past 
I thought it was a problem with mageia's flag
since the rpm crashed and not a building from source directly with its Build requires installed
./buildd
sudo make install

it was OK

then I tried to use a modified buildd script with Mageia's flag
https://bugs.mageia.org/attachment.cgi?id=13054
built it 
and installed it
It crashed

https://bugs.mageia.org/show_bug.cgi?id=29742#c33

That means thet apparently we need a conditional spec

%ifarch i586
something1
%else
something2
%endif

I do not see that this is related to bug 32532, which is resolved in theory.
Except perhaps: 
Bug 32535 - Guayadeque crashes immediately for some users when launched on their 64 bits systems
This last one is fixed by the version 0.4.8-4 in updates_testing. Should this new 32-bit crash be tried with that update?

CC: (none) => lewyssmith

Hi Lewis
Indeed I splitted a previous bug 32231 (closed now) that became unreadable
for 3 problems :
- crash when fader and equalizer enabled = bug 32532 (that seems to be resolved)

- crash for an unknown reason = bug 32355 (that is only partially corrected by adding Requires : binutils but something else is to find)

- crash on 32bits system = bug 32536 that is something old and may be the same as
bug 29742 yet unresolved (that seems to be induced by the way we build our rpms since the program built directly from source and installed doesn't crash)

Of course I will inform here when the modified rpm will be in 
Mageia9/core/updates_testing

Nevertheless it's important to know here that binutils is Required for the ones that build the program directly from the last source that is now a fork :
https://github.com/openmonk/guayadeque

Take a look at this comment :
https://bugs.mageia.org/show_bug.cgi?id=32535#c66

for this 32bits problem could we use conditional lines in the spec file ?
something like this :

%ifarch i586
%global optflags %{optflags} -flto=auto 
%global _disable_ld_as_needed 1
%endif

NB I'm not sure of the syntax

@ katantek
since you are the only one to have a i586 computer
May you rebuild the rpm with a modified spec in copr or mock and test it ?

(In reply to Philippe Didier from comment #5)
> Take a look at this comment :
> https://bugs.mageia.org/show_bug.cgi?id=32535#c66
> 
> for this 32bits problem could we use conditional lines in the spec file ?
> something like this :
> 
> %ifarch i586
> %global optflags %{optflags} -flto=auto 
> %global _disable_ld_as_needed 1
> %endif
> 
> NB I'm not sure of the syntax
> 
> @ katantek
> since you are the only one to have a i586 computer
> May you rebuild the rpm with a modified spec in copr or mock and test it ?

If we are going to not use '-Wl,--as-needed' we should add it unconditionally, and not modify optflags at all. Just '%global _disable_ld_as_needed 1'.

Hi Jani
You know better than me what to do to modify this spec file...
and you know if this '%global _disable_ld_as_needed 1' will not bring problems

Maybe before doing this we may ask to katnatek to test this on his two systems
building a rpm with the last spec file and this %global added

I'm gonna attach here for him the last spec file from the svn

(In reply to Philippe Didier from comment #5)
 
> @ katantek
> since you are the only one to have a i586 computer
> May you rebuild the rpm with a modified spec in copr or mock and test it ?

I have real 32-bit hardware, a Dell Inspiron 5100 that uses a 32-bit P4. That old laptop would not work with gualadeque on MGA8, but then neither would any 32-bit system on any hardware I own. 

Strangely enough it would work with a 32-bit vbox MGA8 guest, which is why the upstream maintainer could not find a way to fix it for us. I suspect the reason is that vbox doesn't provide a true simulation of 32-bit hardware. Some problems just need the real thing.

I can test if something is built for me, but building for myself is beyond my capabilities.

Created attachment 14179 [details]
last spec file for guayadeque from svn

This last spec file contains some modifications
the most important is that now there's 
Requires : binutils

(In reply to Thomas Andrews from comment #8)
> (In reply to Philippe Didier from comment #5)
>  
> > @ katantek
> > since you are the only one to have a i586 computer
> > May you rebuild the rpm with a modified spec in copr or mock and test it ?
> 
> I have real 32-bit hardware, a Dell Inspiron 5100 that uses a 32-bit P4.
> That old laptop would not work with gualadeque on MGA8, but then neither
> would any 32-bit system on any hardware I own. 
> 
> Strangely enough it would work with a 32-bit vbox MGA8 guest, which is why
> the upstream maintainer could not find a way to fix it for us. I suspect the
> reason is that vbox doesn't provide a true simulation of 32-bit hardware.
> Some problems just need the real thing.
> 
> I can test if something is built for me, but building for myself is beyond
> my capabilities.

Hi Thomas
the problem on 32bits computer with Mageia8 appeared for me too :
bug 29742 it was caused by the build time flags of Mageia
the only workaround had been for me to build guayadeque directly from source and install it
It Worked !
I hope that this modification to the spec file will resolve :
bug 32536
bug 32535
and bug 29742 that is still opened

(In reply to Philippe Didier from comment #7)
> Hi Jani
> You know better than me what to do to modify this spec file...
> and you know if this '%global _disable_ld_as_needed 1' will not bring
> problems
> 
> Maybe before doing this we may ask to katnatek to test this on his two
> systems
> building a rpm with the last spec file and this %global added
> 
> I'm gonna attach here for him the last spec file from the svn

I will test just with '%global _disable_ld_as_needed 1 just to be sure, @Jani can you explain why don't include -flto line?

Tested on i586 (in this moment can't test on x86_64) without issues but the build take from 1 to 4 minutes more without the lto, can be a coincide or not, other builds was done more latter so copr can be more busy now

@Thomas if you can help with some test (It's fine if you can't test all), here are the rpms (please uninstall once you make the test to not get conflict when the official package come out) 

MGA8 i586
https://download.copr.fedorainfracloud.org/results/katnatek/blogdrake/mageia-8-i586/06675361-guayadeque/guayadeque-0.4.7-3.git20231115.1.1bdk_mga8.i586.rpm

MGA8 x86_64
https://download.copr.fedorainfracloud.org/results/katnatek/blogdrake/mageia-8-x86_64/06675361-guayadeque/guayadeque-0.4.7-3.git20231115.1.1bdk_mga8.x86_64.rpm

MGA9 i586
https://download.copr.fedorainfracloud.org/results/katnatek/blogdrake/mageia-9-i586/06675361-guayadeque/guayadeque-0.4.7-3.git20231115.1.1bdk_mga9.i586.rpm

MGA9 x86_64
https://download.copr.fedorainfracloud.org/results/katnatek/blogdrake/mageia-9-x86_64/06675361-guayadeque/guayadeque-0.4.7-3.git20231115.1.1bdk_mga9.x86_64.rpm

Please don't mixup unofficial/personal/whatsoever builds with official builds. QA can't be done other pkgs than the official ones. All this creates just a unneeded fuss.

(In reply to katnatek from comment #11)
> (In reply to Philippe Didier from comment #7)
> > Hi Jani
> > You know better than me what to do to modify this spec file...
> > and you know if this '%global _disable_ld_as_needed 1' will not bring
> > problems
> > 
> > Maybe before doing this we may ask to katnatek to test this on his two
> > systems
> > building a rpm with the last spec file and this %global added
> > 
> > I'm gonna attach here for him the last spec file from the svn
> 
> I will test just with '%global _disable_ld_as_needed 1 just to be sure,
> @Jani can you explain why don't include -flto line?

Because it's not in our packaging policy to use -flto when compiling. I don't see any reason why it should be enabled just for one pkg.

(In reply to Jani Välimaa from comment #13)
> Please don't mixup unofficial/personal/whatsoever builds with official
> builds. QA can't be done other pkgs than the official ones. All this creates
> just a unneeded fuss.
That is why I ask to uninstall once the teste is made, consider it a pre test to make sure the modification deserves the effort, if not fix the bug also for Thomas then you not need change nothing and Thomas and  I will know that we can't test this software

(In reply to katnatek from comment #12)
> 
> @Thomas if you can help with some test (It's fine if you can't test all),
> here are the rpms (please uninstall once you make the test to not get
> conflict when the official package come out) 
> 
I'm with Jani on this one. I might better keep my Mageia QA test systems all-Mageia, so there's no possible contamination from outside that might mask or cause problems down the line. When you have something that's actually ready for QA, I will be happy to test.

(In reply to katnatek from comment #12)
> Tested on i586 (in this moment can't test on x86_64) without issues but the
> build take from 1 to 4 minutes more without the lto, can be a coincide or
> not, other builds was done more latter so copr can be more busy now
> 
> @Thomas if you can help with some test (It's fine if you can't test all),
> here are the rpms (please uninstall once you make the test to not get
> conflict when the official package come out) 
> 
> MGA8 i586
> https://download.copr.fedorainfracloud.org/results/katnatek/blogdrake/mageia-
> 8-i586/06675361-guayadeque/guayadeque-0.4.7-3.git20231115.1.1bdk_mga8.i586.
> rpm
> 
> MGA8 x86_64
> https://download.copr.fedorainfracloud.org/results/katnatek/blogdrake/mageia-
> 8-x86_64/06675361-guayadeque/guayadeque-0.4.7-3.git20231115.1.1bdk_mga8.
> x86_64.rpm
> 
> MGA9 i586
> https://download.copr.fedorainfracloud.org/results/katnatek/blogdrake/mageia-
> 9-i586/06675361-guayadeque/guayadeque-0.4.7-3.git20231115.1.1bdk_mga9.i586.
> rpm
> 
> MGA9 x86_64
> https://download.copr.fedorainfracloud.org/results/katnatek/blogdrake/mageia-
> 9-x86_64/06675361-guayadeque/guayadeque-0.4.7-3.git20231115.1.1bdk_mga9.
> x86_64.rpm

Hi katnatek
Thanks for testing what you built with copr

Nevertheless
You can't use the same spec file for Mageia8 that the one we use now for Mageia9
Inside Mageia8 we used wxgtk3.1.5 and gstreamer 1.18.5

The spec was different, the source was different (anonbeat) and there were patches

For Mageia9 we use the last gitclone from openmonk which has been rewritten for wxgtk 3.2.1 and for gstreamer 1.22.3 and needs no more patches

If you want to test it for Mageia8 you might test with this srpm :
https://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/8/SRPMS/core/updates/guayadeque-0.4.6-7.git20201222.2.1.mga8.src.rpm

The spec file from this srpm must be modified to add

%global _disable_ld_as_needed 1

Requires : binutils

(In reply to Thomas Andrews from comment #16)
> (In reply to katnatek from comment #12)
> > 
> > @Thomas if you can help with some test (It's fine if you can't test all),
> > here are the rpms (please uninstall once you make the test to not get
> > conflict when the official package come out) 
> > 
> I'm with Jani on this one. I might better keep my Mageia QA test systems
> all-Mageia, so there's no possible contamination from outside that might
> mask or cause problems down the line. When you have something that's
> actually ready for QA, I will be happy to test.

No problem, thank you

(In reply to Thomas Andrews from comment #16)
> (In reply to katnatek from comment #12)
> > 
> > @Thomas if you can help with some test (It's fine if you can't test all),
> > here are the rpms (please uninstall once you make the test to not get
> > conflict when the official package come out) 
> > 
> I'm with Jani on this one. I might better keep my Mageia QA test systems
> all-Mageia, so there's no possible contamination from outside that might
> mask or cause problems down the line. When you have something that's
> actually ready for QA, I will be happy to test.

Hi Thomas
If you are cautious that might not cause problems

I often test packages that I built myself with mock before providing them to Mageiax/core/updates_testing or for tainted or for nonfree
I want to be sure I don't provide garbage to Mageia testers and users !!!

What to do for this :
1)
uninstall the rpm from Mageia previously installed
rename in /home/yourusername/ the config files and directories it uses
(for instance rename 
/home/yourusername/.guayadeque to /home/yourusername/.guayadequebak)

Click right on the built rpm and install the built rpm to test (your root password will be asked...)
test it
After that uninstall it with the CCM
delete the new created /home/yourusername/.guayadeque

2)
reinstall the previous Mageia rpm with the CCM
copy /home/yourusername/.guayadequebak to /home/yourusername/.guayadeque
install the built rpm (it will be installed as an update of the Mageia initial rpm)
test it again

3)
You may then uninstall this new rpm with CCM
delete /home/yourusername/.guayadeque 
rename /home/yourusername/.guayadequebak to /home/yourusername/.guayadeque
reinstall the initial Mageia rpm with the CCM

You will find again on the computer the same thing as before the test

NB
I have done this way for all the packages I maintain and update
before providing them to QA
I never add any problem on my system using this protocol

(In reply to Philippe Didier from comment #17)
> Hi katnatek
> Thanks for testing what you built with copr
> 
> Nevertheless
> You can't use the same spec file for Mageia8 that the one we use now for
> Mageia9
> Inside Mageia8 we used wxgtk3.1.5 and gstreamer 1.18.5
> 
> The spec was different, the source was different (anonbeat) and there were
> patches
> 
> For Mageia9 we use the last gitclone from openmonk which has been rewritten
> for wxgtk 3.2.1 and for gstreamer 1.22.3 and needs no more patches
> 
> If you want to test it for Mageia8 you might test with this srpm :
> https://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/8/SRPMS/core/
> updates/guayadeque-0.4.6-7.git20201222.2.1.mga8.src.rpm
> 
> The spec file from this srpm must be modified to add
> 
> %global _disable_ld_as_needed 1
> 
> Requires : binutils
Well previous build with the current sources and previous testing spec works without issue in VM with Mageia 8 i586, I can't test on real hardware for Mageia 8

@ katnatek
@ Jani
@ Thomas

Very good news

I have always my old Compaq Mini 311 that I used for sailing (with OpenCPN the navigation software I maintain) until some OpenCPN plugins were only for 64bits system
it's a strictly 32 bits hardware with Mageia8 i586 installed

Since bug 29742 had never been resolved I had uninstalled the Mageia8 guayadeque rpm
in year 2021 (it appears unselected in the CCM)

I had built guayadeque directly from source and installed it (in the directory in which I had extracted the source and build guayadeque I simply sudo make install )

It worked perfectly

To test what katnatek did

I uninstalled it (in the directory where it had been built : sudo make uninstall)

I renamed /home/myname/.guayadeque to /home/myname/.guayadequebak 

I imported https://download.copr.fedorainfracloud.org/results/katnatek/blogdrake/mageia-8-i586/06675361-guayadeque/guayadeque-0.4.7-3.git20231115.1.1bdk_mga8.i586.rpm

I right clicked on it to install (with root password accepting the wrong signature)

Then I launched Guayadeque
added a path to some music files
Created a playlist

It works perfectly !!!!
fader is useable equalizer is useable 
no crash

I then uninstalled it with the CCM where it appeared as installed

I couldn't think that the last source and spec  were backward compatible with Mageia8 !!!

To conclude the spec file modified by katnatek allow to build a rpm for an old Mageia8 32bits system and it works !!

That may resolve at least 
bug 29742 

I have no 32bits hardware with Mageia9 installed
But I think that might resolve bug 32536 too


Just let Thomas and katnatek test on their old 64bits hardware
https://download.copr.fedorainfracloud.org/results/katnatek/blogdrake/mageia-9-x86_64/06675361-guayadeque/guayadeque-0.4.7-3.git20231115.1.1bdk_mga9.x86_64.rpm

If Jani is OK we then may add :
%global _disable_ld_as_needed 1
to the spec file 

and then propose to QA for testing for Mageia9 and even perhaps for Mageia8

@ katnatek
may you provide the diff between the spec file that is attached in the top of this bug report :
https://bugs.mageia.org/attachment.cgi?id=14179

and the spec file you used to build the rpms you provide in 
https://bugs.mageia.org/show_bug.cgi?id=32536#c12

Thanks

Created attachment 14180 [details]
Diff of Philippe's spec an my spex

(In reply to Philippe Didier from comment #22)
> @ katnatek
> may you provide the diff between the spec file that is attached in the top
> of this bug report :
> https://bugs.mageia.org/attachment.cgi?id=14179
> 
> and the spec file you used to build the rpms you provide in 
> https://bugs.mageia.org/show_bug.cgi?id=32536#c12
> 
> Thanks
Here is the requested diff, I see the previous guayadeque version is already removed in updates_testing

(In reply to katnatek from comment #23)
> Created attachment 14180 [details]

> Here is the requested diff, I see the previous guayadeque version is already
> removed in updates_testing

Thanks a lot for this

I will provide the corrected specfile to svn for
Cauldron 
Mageia8/core/updates_testing
Mageia9/core/updates_testing

resolved by bug 32550

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