A)
First case :
for Magiea8 or Mageia9 (whichever the system is 32 or 64 bits)

the reason :
Guayadeque crashes if binutils is not installed :
Thanks to Thomas Andrews who helped to find the culprit
https://bugs.mageia.org/show_bug.cgi?id=32535#c15 

solution : add Requires : binutils in the spec file

B)
Second case : 
- for Mageia8 or Mageia9 32bits  installed on 32bits real hardwares
- for Mageia8 or Mageia9 64bits installed on some old 64bits hardwares
bug 29742
bug 32535
bug 32536

the reason :
some Mageia build flags used to build the rpm induce a bad stack management by the program 
(this doesn't happen when the program is simply built from source and installed

solution : 
add %global _disable_ld_as_needed 1  in the spec file
Thanks to katnatek who proposed this

C)
third case :
in Mageia9 guayadeque crashes if Fader and Equalizer are enabled
bug 32532 and bug 32231

reason :
the source code used until now is not compliant with the wxgtk 3.2.1 version and gstreamer 1.22.3 that are used inside Mageia9 
(it created with wxgtk3.0 and gstreamer 1.18.5 and needed already patches to build with wxgtk 3.1.5)

first solution found  : add a patch to disable fader and equalizer

second and better solution found :
change the github source 
from https://github.com/anonbeat/guayadeque 
to its fork https://github.com/openmonk/guayadeque

openmonk, thanks to him, brought very quickly some little changes to the source
So that  we don't need any patch now and we don't need to disable fader and equalizer

If Jani is OK with this we just have to add in the spec already in the svn
%global _disable_ld_as_needed 1
to the spec file

changing the source is already done in the svn
adding Requires : binutils is already done too

after this we may provide the rpms
to Mageia8/core/updates_testing 
and to Mageia9/core/updates_testing
and of course to Cauldron


NB I already tested the rpms provided by katnatek  here
https://bugs.mageia.org/show_bug.cgi?id=32536#c12

with Mageia8 32 bits on a real 32bits harware    OK
with Mageia8 64bits on a recent 64bits hardware  OK
with Mageia9 64bits on a recent 64bits hardware  OK

katantek tested it 
with Mageia9 64bits on an old 64bits hardware   OK

We only need to test with Mageia9 32bits on real 32bits hardware

My  tests have been done this way :


1) after having uninstalled the current version
and renamed /home/myusername/.guayadeque to /home/myusername/.guayadequebak
then install the new version and test it : 
it creates a new /home/myusername/.guayadeque
I add a path to music files
play a playlist
everything is OK
stop Guayadeque

2) after having uninstalled the version to test
reinstall the current version
delete the /home/myusername/.guayadeque created by the new version
let the current version create a new /home/myusername/.guayadeque
then update to the new version of guayadeque
no problem it uses correctly /home/myusername/.guayadeque
OK
stop Guayadeque

3) delete the recently created /home/myusername/.guayadeque
copy in Mageia9 the directory from Mageia8 /home/myusername/.guayadeque
Launch again Guayadeque
It uses all that had been created before (no need to add the paths and to rebuild the huge database !)
Everything is OK

When the updates proposed to QA will be validated we may close as resolved
bug 32231
bug 35232
bug 35235
bug 32536
and this bug 32550 that summarize all this mess

PS the rpms are not yet in updates_testing
before submitting them we wait for sysadmins to remove a wrongly versioned rpm already present in Cauldron and in Mageia9/core/updates_testing

@ Jani
I saw that sysadmins removed guayadeque with bad version and release from Cauldron and from Mageia9/core/updates_release
And that you submitted guayadeque-0.4.7-3.git20231115.1 to Cauldron

To solve the crash on 32 bits hardware and old 64bits hardware we need to add %global disable ld --as-needed    inside the spec file
bug 32535 and bug 32536

For this reason, guayadeque-0.4.7-3.git20231115.1 is not yet ready for updates_testing...
Please don't submit yet

We will have to increase the release number to 2 if we add this line it can't be (SILENT)
is it OK for you ?

(In reply to Philippe Didier from comment #4)
> @ Jani
> I saw that sysadmins removed guayadeque with bad version and release from
> Cauldron and from Mageia9/core/updates_release
> And that you submitted guayadeque-0.4.7-3.git20231115.1 to Cauldron
> 
> To solve the crash on 32 bits hardware and old 64bits hardware we need to
> add %global disable ld --as-needed    inside the spec file
> bug 32535 and bug 32536
> 
> For this reason, guayadeque-0.4.7-3.git20231115.1 is not yet ready for
> updates_testing...
> Please don't submit yet
> 
> We will have to increase the release number to 2 if we add this line it
> can't be (SILENT)
> is it OK for you ?

It's not possible to submit any new release until debug pkgs are also removed from the repo.

Releases are not increased in stable releases. Subreleases are used instead. You need to add '%define subrel 1' to .spec. It's recommended to add it to row above the Release tag so it'll be more easier to notice its existence.

(In reply to Jani Välimaa from comment #5)

> 
> It's not possible to submit any new release until debug pkgs are also
> removed from the repo.
> 
> Releases are not increased in stable releases. Subreleases are used instead.
> You need to add '%define subrel 1' to .spec. It's recommended to add it to
> row above the Release tag so it'll be more easier to notice its existence.

Thanks
I will provide the corrected spec file to svn 
for Cauldron
for Mageia8/core/updates
for Mageia9/core/updates

adding 
%global subrel 1
%global _disable_ld_as_needed 1

Then wait to submit

When submitting have been done  I will provide here the list of rpms for QA

and a project for the advisory summarizing the bugs corrected

everything is now in the svn
for Cauldron
for Mageia8/core/updates
for Mageia9/core/updates

waiting now to submit all this when it is possible
(maybe already now for Cauldron and Mageia8 ?)

(In reply to Philippe Didier from comment #7)
> everything is now in the svn
> for Cauldron
> for Mageia8/core/updates
> for Mageia9/core/updates
> 
> waiting now to submit all this when it is possible
> (maybe already now for Cauldron and Mageia8 ?)

There's also subrel in cauldron where it's not used. Please fix it.

(In reply to Jani Välimaa from comment #8)
> (In reply to Philippe Didier from comment #7)
> > everything is now in the svn
> > for Cauldron
> > for Mageia8/core/updates
> > for Mageia9/core/updates
> > 
> > waiting now to submit all this when it is possible
> > (maybe already now for Cauldron and Mageia8 ?)
> 
> There's also subrel in cauldron where it's not used. Please fix it.

I  don't understand why it's not used...
http://svnweb.mageia.org/packages/cauldron/guayadeque/current/SPECS/guayadeque.spec?r1=2008695&r2=2009183
I thought it was enough...

does it means that I have to modify this line too :
Release:        %mkrel 3.git%{?gdate}.%{rel}
this way :
Release:        %mkrel 3.git%{?gdate}.%{rel}.%{subrel}
?

If so I will silently modify it

(In reply to Philippe Didier from comment #9)
> (In reply to Jani Välimaa from comment #8)
> > (In reply to Philippe Didier from comment #7)
> > > everything is now in the svn
> > > for Cauldron
> > > for Mageia8/core/updates
> > > for Mageia9/core/updates
> > > 
> > > waiting now to submit all this when it is possible
> > > (maybe already now for Cauldron and Mageia8 ?)
> > 
> > There's also subrel in cauldron where it's not used. Please fix it.
> 
> I  don't understand why it's not used...
> http://svnweb.mageia.org/packages/cauldron/guayadeque/current/SPECS/
> guayadeque.spec?r1=2008695&r2=2009183
> I thought it was enough...
> 
> does it means that I have to modify this line too :
> Release:        %mkrel 3.git%{?gdate}.%{rel}
> this way :
> Release:        %mkrel 3.git%{?gdate}.%{rel}.%{subrel}
> ?
> 
> If so I will silently modify it

Just remove subrel and increase rel.

Subrels are only for stable release updates to make sure there is no higher EVRD in stable release than in cauldron. We must always have higher EVRD in cauldron to not break update path when cauldron is forked as a new stable.

(In reply to Jani Välimaa from comment #10)
> (In reply to Philippe Didier from comment #9)
> > (In reply to Jani Välimaa from comment #8)
> > > (In reply to Philippe Didier from comment #7)
> > > > everything is now in the svn
> > > > for Cauldron
> > > > for Mageia8/core/updates
> > > > for Mageia9/core/updates
> > > > 
> > > > waiting now to submit all this when it is possible
> > > > (maybe already now for Cauldron and Mageia8 ?)
> > > 
> > > There's also subrel in cauldron where it's not used. Please fix it.
> > 
> > I  don't understand why it's not used...
> > http://svnweb.mageia.org/packages/cauldron/guayadeque/current/SPECS/
> > guayadeque.spec?r1=2008695&r2=2009183
> > I thought it was enough...
> > 
> > does it means that I have to modify this line too :
> > Release:        %mkrel 3.git%{?gdate}.%{rel}
> > this way :
> > Release:        %mkrel 3.git%{?gdate}.%{rel}.%{subrel}
> > ?
> > 
> > If so I will silently modify it
> 
> Just remove subrel and increase rel.
> 
> Subrels are only for stable release updates to make sure there is no higher
> EVRD in stable release than in cauldron. We must always have higher EVRD in
> cauldron to not break update path when cauldron is forked as a new stable.

Ok I'm gonna correct it
sorry for not understanding well the rules

@ Jani

Sorry to disturb you again but I am stuck : I never provided updates for 2 different versions of Mageia (in this case Mageia8 and Mageia9)

I have submitted 
guayadeque 
to Cauldron with rel = 2
guayadeque-0.4.7-3.git20231115.2.mga10

and to Mageia8/core/updates_testing with rel = 1 and subrel =1
guayadeque-0.4.7-3.git20231115.1.1.mga8

That seems to be OK for both of them


I wait for guayadeque debug rpms are removed from updates_testing before submitting it

Nevertheless I have still a pending question with this alternative :
1)  Is it necessary to modify the subrel to =2 for Mageia9 so that this version is higher than for Mageia8 ?
guayadeque-0.4.7-3.git20231115.1.2.mga9

2)  Or may I let this as it is (aka rel=1 subrel=1) for Mageia9 ?
guayadeque-0.4.7-3.git20231115.1.1.mga9

Since it's not yet submitted I have time enough to eventually silently correct the subrel in svn

Thanks for your advice 
and apologizes again for asking so much help from you

Philippe

Actually it should have been without subrel in mga8, because all the changes were included in a single commit and submit.

The first version update is always without subrel, and only the following and subsequent releases should be using it. However it doesn't really matter at this point.

There is no need to bump subrel in mga9. If two stable releases are having the same version and release the newest stable will have highest EVRD.

guayadeque-0.4.7-3.git20231115.1.1.mga8
vs
guayadeque-0.4.7-3.git20231115.1.1.mga9

1.mga8
vs
1.mga9

(In reply to Jani Välimaa from comment #13)
> Actually it should have been without subrel in mga8, because all the changes
> were included in a single commit and submit.
> 
> The first version update is always without subrel, and only the following
> and subsequent releases should be using it. However it doesn't really matter
> at this point.
> 
> There is no need to bump subrel in mga9. If two stable releases are having
> the same version and release the newest stable will have highest EVRD.
> 
> guayadeque-0.4.7-3.git20231115.1.1.mga8
> vs
> guayadeque-0.4.7-3.git20231115.1.1.mga9
> 
> 1.mga8
> vs
> 1.mga9

Thanks for this clear explanation
No change needed for the spec

Nevertheless I can't yet submit this to BS for Mageia9
since there's always for Mageia9 for all arches in  /debug/core/updates_testing/  
2 rpms :
guayadeque-debuginfo-0.4.8-4.git20231115.1.
guayadeque-debugsources-0.4.8-4.git20231115.1.

The sysadmins have already removed the srpm and the rpm itself as they were asked 
but forgot the debug rpms...

When this remaining rpms will have been removed 
and when I will have submitted it 
I will add here :
a list of packages to test for QA
a project of advisory

I'm gonna attach here a draft

Created attachment 14181 [details]
project of advisory when all the rpms will have been uploaded

project of advisory for these updates when all the rpms will have been uploaded in core/updates_testing for Mageia8 and Mageia9 and tested by QA

I will see if I can test later today. It may take a while, since I will be testing on real 32-bit and 64-bit hardware for both Mageia 8 and Mageia 9.

If the packages in this bug are supposed to fix all those other bugs, I wonder if all of them now should be labelled as duplicates of this one. Seems like the easiest way to assign to QA.

But the whole thing has been so complicated that I don't know if that's proper or not. I've not encountered such a, um, "situation" before.

(In reply to Thomas Andrews from comment #18)
> I will see if I can test later today. It may take a while, since I will be
> testing on real 32-bit and 64-bit hardware for both Mageia 8 and Mageia 9.
> 
> If the packages in this bug are supposed to fix all those other bugs, I
> wonder if all of them now should be labelled as duplicates of this one.
> Seems like the easiest way to assign to QA.
> 
> But the whole thing has been so complicated that I don't know if that's
> proper or not. I've not encountered such a, um, "situation" before.

Jus test and report all in this bug, all the other will be closed by me, once this is marked as fixed

Advisory from comment 17 added to SVN, Mga8 and Mga9 description merged. Please remove the "advisory" keyword if it needs to be changed. It also helps when obsolete advisories are tagged as "obsolete"

Keywords: (none) => advisory

Advisory
======================
This update fix issues for guayadeque on Mageia 8 y 9:
Now it's correctly built with wxgtk and gstreamer
No more patch needed
No more crash at start on 32bits hardware or with old intel 64bits processors
No more crash on 64bits hardware 
The source has been changed to an active fork (maintained by its best contributor)
https://github.com/openmonk/guayadeque/tree/master since the developer of the original https://github.com/anonbeat/guayadeque as ended working on it

References:
mga#32550 
mga#29742
mga#32535
mga#32536
mga#32532

Package in 8/Core/Updates_testing:
======================
guayadeque-0.4.7-3.git20231115.1.1.mga8.rpm

from SRPM
guayadeque-0.4.7-3.git20231115.1.1.mga8.srpm


Package in 9/Core/Updates_testing:
======================
guayadeque-0.4.7-3.git20231115.1.1.mga9.rpm

from SRPM
guayadeque-0.4.7-3.git20231115.1.1.mga9.srpm

(In reply to Marja Van Waes from comment #20)
> Advisory from comment 17 added to SVN, Mga8 and Mga9 description merged.
> Please remove the "advisory" keyword if it needs to be changed. It also
> helps when obsolete advisories are tagged as "obsolete"
Great mind think the same XD, you win me by a few

Tested on Real Hardware Mageia 9 i586 with lxqt

Install current version of guayadeque
Run guayadeque as user
The application crash at start
Update without issues to testing version
Run guayadeque as user
The application start without issues
Play some local music files without issues

Whiteboard: MGA8 TOO => MGA8 TOO MGA9-32-OK

I tested this 
with Mageia8 i586 on a real 32 bits old hardware (Compaq mini 311)
with Mageia8 x86_64 on 64bits recent hardware
with Mageia9 x86_64 on 64bits recent hardware 

1) fresh install after having removed the current rpm 
(and renamed the previous  /home/myusername/.guayadeque 
to /home/myusername/.guayadequebak)

2) supressed the /home/myusername/.guayadeque created by the fresh install
and renamed /home/myusername/.guayadequebak to /home/myusername/.guayadeque

3) uninstall this rpm from updates_testing install the current rpm and then update it with the rpm from updates_testing

Everything is OK for MGA8 32 bits,  MGA8 64bits, MGA9 64bits

NB if your previous database was huge Guayadeque may be long before displaying anything... that doesn't mean it's frozen : just let enough time to it to verify its database !

(In reply to Thomas Andrews from comment #18)
> I will see if I can test later today. It may take a while, since I will be
> testing on real 32-bit and 64-bit hardware for both Mageia 8 and Mageia 9.
> 
> If the packages in this bug are supposed to fix all those other bugs, I
> wonder if all of them now should be labelled as duplicates of this one.
> Seems like the easiest way to assign to QA.
> 
> But the whole thing has been so complicated that I don't know if that's
> proper or not. I've not encountered such a, um, "situation" before.

I already tested MGA8 32 bits on a real 32bits hardware
We only need to be sure that MG9 32 bits works on real 32bits hardware 

If you have time enough you may try 64bits on your old 64bits processors
but that must be fine now since they had the same crash as 32bits hardware

I had already started my mga8 test on Foolishness, my Dell Inspiron 5100, so I went ahead with it. Downloaded the package with qarepo, then used urpmi to install it and dependencies.

# urpmi guayadeque
To satisfy dependencies, the following packages are going to be installed:
  Package                        Version      Release       Arch    
(medium "QA Testing (32-bit)")
  guayadeque                     0.4.7        3.git2023111> i586    
(medium "Core Release")
  libgpod                        0.8.3        23.mga8       i586    
  libgpod4                       0.8.3        23.mga8       i586    
  libjsoncpp24                   1.9.4        1.mga8        i586    
  libsgutils2_2                  1.45         3.mga8        i586    
(medium "Core Updates")
  binutils                       2.36.1       1.5.mga8      i586    
  libwx_baseu3.1_5               3.1.5        1.mga8        i586    
  libwx_baseu_net3.1_5           3.1.5        1.mga8        i586    
  libwx_baseu_xml3.1_5           3.1.5        1.mga8        i586    
  libwx_gtk3u_aui3.1_5           3.1.5        1.mga8        i586    
  libwx_gtk3u_core3.1_5          3.1.5        1.mga8        i586    
  libwx_gtk3u_html3.1_5          3.1.5        1.mga8        i586    
  libwx_gtk3u_qa3.1_5            3.1.5        1.mga8        i586    
  libwx_gtk3u_wxsqlite3_3.1_0    4.6.4        1.1.mga8      i586    
  wxgtk3.1                       3.1.5        1.mga8        i586    
51MB of additional disk space will be used.
 
No installation issues. Then I started it from the command line. The gui came up and didn't crash, looked like all was well. Bu8t, after I closed it, I found all this in the terminal window:

$ guayadeque 
05:15:06 PM: Initialized locale ( en_US )
05:15:06 PM: Created collection folder '/home/tom/.guayadeque/Collections/6560DA1A'
05:15:06 PM: Library Db Version 0
05:15:06 PM: Updating database version to 21
05:15:06 PM: SetViewMode -1 => 0

(guayadeque:4402): Gtk-CRITICAL **: 17:15:07.001: gtk_widget_set_size_request: assertion 'height >= -1' failed

(guayadeque:4402): Gtk-CRITICAL **: 17:15:07.001: gtk_widget_set_size_request: assertion 'height >= -1' failed
05:15:07 PM: guLibPanel::IniPanelData( 13101 )
05:15:07 PM: guLibPanel::DoTextSearch( '' )

(guayadeque:4402): Gtk-CRITICAL **: 17:15:07.016: gtk_widget_set_size_request: assertion 'height >= -1' failed
kmsro: driver missing
kmsro: driver missing
05:15:07 PM: OnCollectionCommand 13100  0 0  1

(guayadeque:4402): Gtk-CRITICAL **: 17:15:07.450: gtk_widget_set_size_request: assertion 'height >= -1' failed

(guayadeque:4402): Gtk-CRITICAL **: 17:15:07.562: gtk_widget_set_size_request: assertion 'height >= -1' failed

(guayadeque:4402): Gtk-CRITICAL **: 17:15:07.563: gtk_widget_set_size_request: assertion 'height >= -1' failed

(guayadeque:4402): Gtk-CRITICAL **: 17:15:07.567: gtk_widget_set_size_request: assertion 'height >= -1' failed

(guayadeque:4402): Gtk-CRITICAL **: 17:15:07.569: gtk_widget_set_size_request: assertion 'height >= -1' failed

(guayadeque:4402): Gtk-CRITICAL **: 17:15:07.994: gtk_widget_set_size_request: assertion 'height >= -1' failed

(guayadeque:4402): Gtk-CRITICAL **: 17:15:07.996: gtk_widget_set_size_request: assertion 'height >= -1' failed

(guayadeque:4402): Gtk-CRITICAL **: 17:15:08.000: gtk_widget_set_size_request: assertion 'height >= -1' failed

(guayadeque:4402): Gtk-CRITICAL **: 17:15:08.070: gtk_widget_set_size_request: assertion 'height >= -1' failed

(guayadeque:4402): Gtk-CRITICAL **: 17:15:08.072: gtk_widget_set_size_request: assertion 'height >= -1' failed

(guayadeque:4402): Gtk-CRITICAL **: 17:15:08.076: gtk_widget_set_size_request: assertion 'height >= -1' failed

(guayadeque:4402): Gtk-CRITICAL **: 17:15:08.077: gtk_widget_set_size_request: assertion 'height >= -1' failed

(guayadeque:4402): Gtk-CRITICAL **: 17:15:08.223: gtk_widget_set_size_request: assertion 'height >= -1' failed

(guayadeque:4402): Gtk-CRITICAL **: 17:15:08.224: gtk_widget_set_size_request: assertion 'height >= -1' failed

(guayadeque:4402): Gtk-CRITICAL **: 17:15:08.226: gtk_widget_set_size_request: assertion 'height >= -1' failed

(guayadeque:4402): Gtk-CRITICAL **: 17:15:08.228: gtk_widget_set_size_request: assertion 'height >= -1' failed

(guayadeque:4402): Gtk-CRITICAL **: 17:15:08.231: gtk_widget_set_size_request: assertion 'height >= -1' failed

(guayadeque:4402): Gtk-CRITICAL **: 17:15:08.232: gtk_widget_set_size_request: assertion 'height >= -1' failed

(guayadeque:4402): Gtk-CRITICAL **: 17:15:08.233: gtk_widget_set_size_request: assertion 'height >= -1' failed
05:15:08 PM: Updating the podcasts...
05:15:08 PM: Indicators_Sound_Available() => 0
05:15:08 PM: Indicators_Sound_Available() => 0

(guayadeque:4402): Gtk-CRITICAL **: 17:15:08.531: gtk_widget_set_size_request: assertion 'height >= -1' failed
05:15:08 PM: MainFrame.Size( 800, 600 ) -1
05:15:08 PM: MainFrame.Size( 800, 600 ) -1

(guayadeque:4402): Gtk-WARNING **: 17:15:08.939: Negative content height -1 (allocation 23, extents 12x12) while allocating gadget (node scale, owner GtkScale)

(guayadeque:4402): Gtk-WARNING **: 17:15:08.944: Negative content height -2 (allocation 0, extents 1x1) while allocating gadget (node trough, owner GtkScale)
05:15:09 PM: playlist active 0

(guayadeque:4402): Gtk-WARNING **: 17:15:56.412: Negative content width -23 (allocation 1, extents 12x12) while allocating gadget (node scale, owner GtkScale)

(guayadeque:4402): Gtk-WARNING **: 17:15:56.413: Negative content height -23 (allocation 1, extents 12x12) while allocating gadget (node scale, owner GtkScale)

(guayadeque:4402): Gtk-CRITICAL **: 17:15:56.414: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkScale

(guayadeque:4402): Gtk-WARNING **: 17:15:56.415: Negative content height -2 (allocation 0, extents 1x1) while allocating gadget (node trough, owner GtkScale)

(guayadeque:4402): Gtk-WARNING **: 17:15:56.417: Negative content height -1 (allocation 23, extents 12x12) while allocating gadget (node scale, owner GtkScale)

(guayadeque:4402): Gtk-WARNING **: 17:15:56.418: Negative content height -2 (allocation 0, extents 1x1) while allocating gadget (node trough, owner GtkScale)

(guayadeque:4402): Gtk-WARNING **: 17:15:56.441: Negative content height -1 (allocation 23, extents 12x12) while allocating gadget (node scale, owner GtkScale)

(guayadeque:4402): Gtk-WARNING **: 17:15:56.446: Negative content height -2 (allocation 0, extents 1x1) while allocating gadget (node trough, owner GtkScale)
05:16:03 PM: Indicators_Sound_Available() => 0

(guayadeque:4402): Gtk-WARNING **: 17:16:04.558: Negative content width -23 (allocation 1, extents 12x12) while allocating gadget (node scale, owner GtkScale)

(guayadeque:4402): Gtk-WARNING **: 17:16:04.559: Negative content height -23 (allocation 1, extents 12x12) while allocating gadget (node scale, owner GtkScale)

(guayadeque:4402): Gtk-CRITICAL **: 17:16:04.563: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkScale

(guayadeque:4402): Gtk-WARNING **: 17:16:04.563: Negative content height -2 (allocation 0, extents 1x1) while allocating gadget (node trough, owner GtkScale)

(guayadeque:4402): Gtk-WARNING **: 17:16:04.564: Negative content height -1 (allocation 23, extents 12x12) while allocating gadget (node scale, owner GtkScale)

(guayadeque:4402): Gtk-WARNING **: 17:16:04.564: Negative content height -2 (allocation 0, extents 1x1) while allocating gadget (node trough, owner GtkScale)

(guayadeque:4402): Gtk-WARNING **: 17:16:10.524: Negative content height -1 (allocation 23, extents 12x12) while allocating gadget (node scale, owner GtkScale)

(guayadeque:4402): Gtk-WARNING **: 17:16:10.528: Negative content height -2 (allocation 0, extents 1x1) while allocating gadget (node trough, owner GtkScale)

(guayadeque:4402): Gtk-WARNING **: 17:16:10.663: Negative content width -23 (allocation 1, extents 12x12) while allocating gadget (node scale, owner GtkScale)

(guayadeque:4402): Gtk-WARNING **: 17:16:10.664: Negative content height -23 (allocation 1, extents 12x12) while allocating gadget (node scale, owner GtkScale)

(guayadeque:4402): Gtk-CRITICAL **: 17:16:10.664: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkScale

(guayadeque:4402): Gtk-WARNING **: 17:16:10.665: Negative content height -2 (allocation 0, extents 1x1) while allocating gadget (node trough, owner GtkScale)

(guayadeque:4402): Gtk-WARNING **: 17:16:10.665: Negative content height -1 (allocation 23, extents 12x12) while allocating gadget (node scale, owner GtkScale)

(guayadeque:4402): Gtk-WARNING **: 17:16:10.666: Negative content height -2 (allocation 0, extents 1x1) while allocating gadget (node trough, owner GtkScale)

(guayadeque:4402): Gtk-WARNING **: 17:16:10.745: Negative content width -23 (allocation 1, extents 12x12) while allocating gadget (node scale, owner GtkScale)

(guayadeque:4402): Gtk-WARNING **: 17:16:10.746: Negative content height -23 (allocation 1, extents 12x12) while allocating gadget (node scale, owner GtkScale)

(guayadeque:4402): Gtk-CRITICAL **: 17:16:10.746: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkScale

(guayadeque:4402): Gtk-WARNING **: 17:16:10.746: Negative content height -2 (allocation 0, extents 1x1) while allocating gadget (node trough, owner GtkScale)

(guayadeque:4402): Gtk-WARNING **: 17:16:10.747: Negative content height -1 (allocation 23, extents 12x12) while allocating gadget (node scale, owner GtkScale)

(guayadeque:4402): Gtk-WARNING **: 17:16:10.748: Negative content height -2 (allocation 0, extents 1x1) while allocating gadget (node trough, owner GtkScale)
05:16:10 PM: Destroying the volume monitor object...
05:16:10 PM: >> ~guGIO_VolumeMonitor()
05:16:10 PM: << ~guGIO_VolumeMonitor()

The app didn't crash, but that looks like a LOT of warnings to me...

(In reply to Thomas Andrews from comment #26)
I got that warnings too, but the application works, that mean the developer have lot of work to do and I think is not the scope of this bug

Same hardware as comment 26, mga9-32 Xfce.

Did the same as in comment 26, with essentially the same results.

(In reply to katnatek from comment #27)
> (In reply to Thomas Andrews from comment #26)
> I got that warnings too, but the application works, that mean the developer
> have lot of work to do and I think is not the scope of this bug

I agree. I'm just surprised it's got to the point where it doesn't crash, what with all those warnings. I think it's about as good as we are going to get, for now.

(In reply to katnatek from comment #27)
> (In reply to Thomas Andrews from comment #26)
> I got that warnings too, but the application works, that mean the developer
> have lot of work to do and I think is not the scope of this bug

Those multiple warnings are known when you launch guayadeque from a console
They don't prevent Guayadeque to work and it doesn't crash anymore

After Mageia has moved from wxgtk3.0 to wxgtk3.1.5 : Guayadeque needed some corrections to be built and to work 
That's then that the warnings appeared when Guayadeque was launched from a console
(when launched from the menu or an icon you don't know anything about these)


NB repeated warnings appear also when you build Guayadeque (complaining about  deprecated declarations)
This is known but doesn't need to be corrected in emergency
The first step was to avoid the crash : it's done  :-)

Then I'm gonna communicate for these details with openmonk (the dev who created the fork we use now and that allowed us to have something working )

_________________________________
To conclude
---------------------------

All these test seem to say that this proposed update is OK with all arches for Mageia8 and Mageia9

That means too that now a bunch of bug reports may be closed as resolved
after a long struggle involving a great number of volunteers

Assigning to QA. 

Tested on my Core2Quad machine, with mga9-64 Plasma. No longer crashes.

Assignee: bugsquad => qa-bugs

Adding some OKs, and validating.

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

Tested on Real and afected Hardware Mageia 9 x86_64 with lxqt

Install current version of guayadeque
Run guayadeque as user
The application crash at start
Update without issues to testing version
Run guayadeque as user
The application start without issues
Play some local music files without issues

(In reply to Thomas Andrews from comment #32)
> Adding some OKs, and validating.

Hi
You may validate it for Mageia8 too
and add it to the validated updates for Mageia 8
( it doesn't appear in http://madb.mageia.org/tools/updates)

This will allow to close as fixed :
this bug itself 
and
bug 29742
bug 32532
bug 32535
bug 32536

(In reply to Philippe Didier from comment #34)
> (In reply to Thomas Andrews from comment #32)
> > Adding some OKs, and validating.
> 
> Hi
> You may validate it for Mageia8 too
> and add it to the validated updates for Mageia 8
> ( it doesn't appear in http://madb.mageia.org/tools/updates)
> 
It does now. Had to remove the space from the "MGA TOO" in the Whiteboard. I would have done that before, but just skipped right over it when I read it. Getting old, I guess.

(In reply to Thomas Andrews from comment #35)
> (In reply to Philippe Didier from comment #34)
> > (In reply to Thomas Andrews from comment #32)
> > > Adding some OKs, and validating.
> > 
> > Hi
> > You may validate it for Mageia8 too
> > and add it to the validated updates for Mageia 8
> > ( it doesn't appear in http://madb.mageia.org/tools/updates)
> > 
> It does now. Had to remove the space from the "MGA TOO" in the Whiteboard. I
> would have done that before, but just skipped right over it when I read it.
> Getting old, I guess.

Thanks

And you certainly don't get as old as I am ;-)

I am gonna close the other bugs from the list in comment 34

I don't see much point trying to fix this as app developement has been stopped, so it can break in future again and again....

https://github.com/anonbeat/guayadeque/commit/d524675772f4600c259414b535ff7a980ca1c962

(In reply to Otto Leipälä from comment #37)
> I don't see much point trying to fix this as app developement has been
> stopped, so it can break in future again and again....
> 
> https://github.com/anonbeat/guayadeque/commit/
> d524675772f4600c259414b535ff7a980ca1c962

If you read totally https://bugs.mageia.org/show_bug.cgi?id=32550#c1
You will see that now we use this fork :
https://github.com/openmonk/guayadeque
on which one of the best contributor of guayadeque continues to work and wants to keep guayadeque existing and who reacts very quickly when I ask him some code modifications

we don't use anymore :
https://github.com/anonbeat/guayadeque !!!
since Juan has ended working on it...

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

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

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

(In reply to Philippe Didier from comment #38)
> (In reply to Otto Leipälä from comment #37)
> > I don't see much point trying to fix this as app developement has been
> > stopped, so it can break in future again and again....
> > 
> > https://github.com/anonbeat/guayadeque/commit/
> > d524675772f4600c259414b535ff7a980ca1c962
> 
> If you read totally https://bugs.mageia.org/show_bug.cgi?id=32550#c1
> You will see that now we use this fork :
> https://github.com/openmonk/guayadeque
> on which one of the best contributor of guayadeque continues to work and
> wants to keep guayadeque existing and who reacts very quickly when I ask him
> some code modifications
> 
> we don't use anymore :
> https://github.com/anonbeat/guayadeque !!!
> since Juan has ended working on it...

Okay sorry didn't noticed there is forked version of program.

CC: (none) => ottoleipala1