Guayadeque 4.7 worked perfectly inside Mageia8 It was built upon wxgtk3.1.5 with three patches : 0001-Fix-compilation-error-with-gcc13-in-taginfo.patch guayadeque-0.4.6-wxgtk3.1.6.patch guayadeque-0.4.6-wxgtk3.1.patch I already filed a bug on anonbeat's github page https://github.com/anonbeat/guayadeque/issues/162 I tried to build guayadeque without the patches but building fails I think there's something to modify in the wxgtk patches so that they become compliant with wxgtk 3.2
Created attachment 13965 [details] crash explanation file created by guayadeque crash explanation file created by guayadeque
I tried to rebuild guayadeque strictly upon wxgtk 3.0 for which it had been written Modifying the spec file this way BuildRequires: wxgtk3.0-devel < 3.1 BuildRequires: wxgtku3.0-devel < 3.1 But unfortunately in the spec file we have this : BuildRequires: pkgconfig(wxsqlite3) and wxsqlite3 needs wxgtk3.2-devel... No way to build guayadeque upon wxgtk3.0 ! the build fails because even if this is clearly asked the presence of pkgconfig(wxsqlite3) implies the use of wxgtk3.2 There's no other solution than rewriting the 2 patches guayadeque-0.4.6-wxgtk3.1.6.patch guayadeque-0.4.6-wxgtk3.1.patch I'm not able to do this :-(
Do you say that guayadeque as currently offered does not work ? What is wrong with the current version, which seems to have been built with wxgtk3.2 ? What drove you to experiment as you have ? These are the three most recent commit comments for it: - Jul 18 2022: add hackish patch to get pkg to build with wxgtk >= 3.1.6 - Apr 22 2023: new version: 0.4.7 - Apr 22 2023: add upstream patch to fix compilation error with gcc13 in taginfo Trying to find what it requires: $ urpmq --requires-recursive guayadeque | grep wxgtk3 wxgtk3.2 $ urpmq --requires guayadeque | grep sqlite libwx_gtk3u_wxsqlite3-3.2.so.0()(64bit) $ urpmf libwx_gtk3u_wxsqlite3-3.2.so.0 lib64wx_gtk3u_wxsqlite3_3.2_0 and the last makes no visible reference to wxgtk3.2-devel: $ urpmq --requires lib64wx_gtk3u_wxsqlite3_3.2_0 | grep wxgtk3 $
Source RPM: guayadeque => guayadeque-0.4.7-1.mga9.src.rpmCC: (none) => lewyssmith
Hi Lewis Guayadeque starts correctly : you can add a directory of music files you can play a first file but when you click a button to pause or stop playing you get a crash Guayadeque creates itself a debug file in /temp/ directory (that I attached in comment 1) https://bugs.mageia.org/attachment.cgi?id=13965 The useful part of this file is in its end : <stack> <frame level="0" function="Guayadeque::guMainApp::OnFatalException()" offset="0" address="0x56e9ba"/> <frame level="1" offset="0x1d8570" address="0x7fbdfd5d8570" module="/lib64/libwx_baseu-3.2.so.0"/> <frame level="2" offset="0x36980" address="0x7fbdfbb88980" module="/lib64/libc.so.6"/> <frame level="3" function="Guayadeque::guGstStateToNullAndUnref(_GstElement*)" offset="0" address="0x58410b"/> <frame level="4" function="Guayadeque::guFaderPlaybin::~guFaderPlaybin()" offset="0" address="0x570ede"/> <frame level="5" function="Guayadeque::guFaderPlaybin::~guFaderPlaybin()" offset="0" address="0x571079"/> <frame level="6" function="Guayadeque::guMediaCtrl::DoCleanUp()" offset="0" address="0x58756f"/> <frame level="7" function="Guayadeque::guMediaCtrl::DoCleanUp()" offset="0" address="0x5878c9"/> <frame level="8" offset="0x59164" address="0x7fbdfc75a164" module="/lib64/libglib-2.0.so.0"/> <frame level="9" function="g_main_context_dispatch" offset="0x149" address="0x7fbdfc759689" module="/lib64/libglib-2.0.so.0"/> <frame level="10" offset="0x58a18" address="0x7fbdfc759a18" module="/lib64/libglib-2.0.so.0"/> <frame level="11" function="g_main_loop_run" offset="0x6f" address="0x7fbdfc759cbf" module="/lib64/libglib-2.0.so.0"/> <frame level="12" function="gtk_main" offset="0x75" address="0x7fbdfb3ecc45" module="/lib64/libgtk-3.so.0"/> <frame level="13" function="wxGUIEventLoop::DoRun()" offset="0x25" address="0x7fbdfcd723e5" module="/lib64/libwx_gtk3u_core-3.2.so.0"/> <frame level="14" function="wxEventLoopBase::Run()" offset="0x2d" address="0x7fbdfd4d72ad" module="/lib64/libwx_baseu-3.2.so.0"/> <frame level="15" function="wxAppConsoleBase::MainLoop()" offset="0x6b" address="0x7fbdfd4a4afb" module="/lib64/libwx_baseu-3.2.so.0"/> <frame level="16" function="wxEntry(int&, wchar_t**)" offset="0x47" address="0x7fbdfd51ec67" module="/lib64/libwx_baseu-3.2.so.0"/> <frame level="17" function="main" offset="0" address="0x561a88"/> <frame level="18" offset="0x236b7" address="0x7fbdfbb756b7" module="/lib64/libc.so.6"/> <frame level="19" function="__libc_start_main" offset="0x85" address="0x7fbdfbb75775" module="/lib64/libc.so.6"/> <frame level="20" function="_start" offset="0" address="0x566fd1"/> </stack> NB libwx_gtk3u_wxsqlite3 itself doesn't need wxgtk3.2-devel but pkgconfig(wxsqlite3) does need it So if I try to build guayadeque strictly upon wxgtk3.0 I can't because wsqlite has fulfilled the /include/wxgtk with 3.2 version besides 3.0 version NB bis about the patches 1) the patch to fix compilation error with gcc13 in taginfo is absolutely necessary for guayadeque 4.7 2) the hackish patch to get pkg to build with wxgtk >= 3.1.6 was not needed to build with wxgtk3.0 but necessary for wxgtk 3.1.5 and 3.2.0 3) guayadeque-0.4.6-wxgtk3.1.patch was not needed to build with wxgtk3.0 but necessary for wxgtk 3.1.5 and 3.2.0 In the past we could build guayadeque upon wxgtk3.0 for Mageia7 we built it upon wxgtk3.1.5 with patches (n°2 and n°3) If I try to build with a strict BuildRequire for wxgtk 3.0 without the 2 patches (n°2 and n°3) the build stops at 1/3 of the task with the same problems as when I try to build for wxgtk 3.2 without these patches ! That seems to show that we can't build upon wxgtk3.0-devel because wxgtk3.2-devel is present too - asked by pkgconfig(wxsqlite3) - and preferently used As a summary the hackish patch to get pkg to build with wxgtk >= 3.1.6 the guayadeque-0.4.6-wxgtk3.1.patch allow to build for wxgtk 3.2.0 but not guayadeque to work they need to be partly rewritten so that what appears in the <stack> part of the bug file is corrected
correcting a typo instead of In the past we could build guayadeque upon wxgtk3.0 for Mageia7 we built it upon wxgtk3.1.5 with patches (n°2 and n°3) you may read In the past we could build guayadeque upon wxgtk3.0 for Mageia8 we built it upon wxgtk3.1.5 with patches (n°2 and n°3)
Thank you for re-stating everything. It is complicated. (In reply to Philippe Didier from comment #4) > Hi Lewis > Guayadeque starts correctly : > you can add a directory of music files > you can play a first file > but when you click a button to pause or stop playing you get a crash > Guayadeque creates itself a debug file in /temp/ directory (that I attached > in comment 1) > https://bugs.mageia.org/attachment.cgi?id=13965 > The useful part of this file is in its end : Ah, something specific. Thank you. This pkg has no dedicated maintainer, so assigning this bug globally. CC'ing the two packagers who have dealt with it most recently.
CC: lewyssmith => geiger.david68210, jani.valimaaAssignee: bugsquad => pkg-bugs
Hi I have tried to rebuild guayadeque from the last pertinent git https://github.com/anonbeat/guayadeque/tree/1ae725ae887e36c4c9c6aa8fbc166e82e0a204e0 which needs only one patch now I attach the spec file and patch No way ! It builds correctly it works correctly : -adding a music directory -playing selected files -jumping to a next file in the playlist Everything is OK until I click the stop button then I get the same crash as written in https://bugs.mageia.org/show_bug.cgi?id=32231#c4
Created attachment 13973 [details] new spec file spec to build with the git from 2023/03/19
Created attachment 13974 [details] patch to build upon wxgtk3.2 patch to build upon wxgtk3.2
Hi again It seems to be a compatibility problem with some versions provided by Mageia9 different from the ones provided by Mageia8 : fontconfig 2.13.93 versus 2.14.2 gstreamer 1.22 versus 1.18 taglib 1.12 versus 1.11.1 wxgtk 3.1.5 versus 3.2.1 Guayadeque rpm can be built for Mageia8 and Mageia9 (with patches) inside mock It runs inside Mageia8 It crashes (segfault) inside Mageia9 (and creates its own debug file) I have used gdb (and hundred of debug rpms) Same segfault as indicated by the xml file created by Guayadeque To verify if it's not a rpm building problem for Mageia9 I have built the binary and installed it (after having modified the source to make it compliant with wxgtk3.2 the same way as the patches do it) Guayadeque crashes the same way It's definitely an upstream problem needing some modifications to some src files (which are calling functions now deprecated...)
Maybe it would be useful that someone else tests guayadeque on its own computer (It's perhaps a problem with my nvidia driver or with plasma !)
typos ! you may read Mageia8 Mageia9 fontconfig 2.13.93 versus 2.14.2 gstreamer 1.18 versus 1.22 taglib 1.11.1 versus 1.12 wxgtk 3.1.5 versus 3.2.1
Summary: guayadeque built upon wxgtk 3.2.0 crashes inside Mageia9 => guayadeque built upon wxgtk 3.2.0, taglib crashes inside Mageia9
After having struggled for a time I found a way to solve this bug !!!! I revert back to the working version for Mageia8 !!! In mock I used this for Mageia9 : the git clone from 2020 12 22 3 patches guayadeque-0.4.6-desktop-shortcuts.patch guayadeque-0.4.6-wxgtk3.1.6.patch guayadeque-0.4.6-wxgtk3.1.patch and this spec file Installed it works without any segfault !!!! And can use the previous configuration from Mageia8 (database and config files) patches and spec file will come attached... Until the 4.7 version or the git clone from 2023/03/19 is bugless (certainly needing patches) It looks better to come back to this old working version
Created attachment 13988 [details] spec file using an old git clone spec file for 2020-12-22 git clone
Created attachment 13989 [details] guayadeque-0.4.6-wxgtk3.1.6.patch guayadeque-0.4.6-wxgtk3.1.6.patch
Created attachment 13990 [details] guayadeque-0.4.6-wxgtk3.1.patch guayadeque-0.4.6-wxgtk3.1.patch
Created attachment 13991 [details] guayadeque-0.4.6-desktop-shortcuts.patch guayadeque-0.4.6-desktop-shortcuts.patch
address where to clone the working version https://github.com/anonbeat/guayadeque/tree/407b183ab67ae7d90940146b0dddaa431da90fef NB : Now that I have found a working git-clone I am gonna try to build and test rpms using more recent clones !
@ Wally I saw you have just modified the spec file adding ninja I tried to build this rpm inside mock I get always lots of warnings about deprecated stuffs When I install it it always crashes (segfault) I'm gonna try to use git clones more recent than 2020/12/22 but les old than 4.7 version (I don't have any answer from upstream) NB when building with your spec and sources I get lots of warnings NB one warning concerns gstreamer : /builddir/build/BUILD/guayadeque-0.4.7/src/audio/FaderPlaybin.cpp:1401:46: warning: 'GstPad* gst_element_get_request_pad(GstElement*, const gchar*)' is deprecated: Use 'gst_element_request_pad_simple' instead [-Wdeprecated-declarations] 1401 | m_TeeSrcPad = gst_element_get_request_pad( m_Tee, "src_%u" ); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~ In file included from /usr/include/gstreamer-1.0/gst/gstbin.h:27, from /usr/include/gstreamer-1.0/gst/gst.h:35, from /builddir/build/BUILD/guayadeque-0.4.7/src/misc/TimeLine.h:27, from /builddir/build/BUILD/guayadeque-0.4.7/src/audio/FaderTimeLine.h:25, from /builddir/build/BUILD/guayadeque-0.4.7/src/audio/FaderPlaybin.h:26, from /builddir/build/BUILD/guayadeque-0.4.7/src/audio/FaderPlaybin.cpp:22: /usr/include/gstreamer-1.0/gst/gstelement.h:1042:25: note: declared here 1042 | GstPad* gst_element_get_request_pad (GstElement *element, const gchar *name); NB lots of warning concern taglib for some kind of files (vorbis MP4) /builddir/build/BUILD/guayadeque-0.4.7/src/taginfo/TagInfo.cpp:389:37: warning: 'void TagLib::Ogg::XiphComment::removeField(const TagLib::String&, const TagLib::String&)' is deprecated [-Wdeprecated-declarations] 389 | xiphcomment->removeField( "COVERARTMIME" ); | ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~ In file included from /usr/include/taglib/vorbisfile.h:31, from /builddir/build/BUILD/guayadeque-0.4.7/src/taginfo/TagInfo.h:39, from /builddir/build/BUILD/guayadeque-0.4.7/src/taginfo/TagInfo.cpp:22: /usr/include/taglib/xiphcomment.h:189:30: note: declared here 189 | TAGLIB_DEPRECATED void removeField(const String &key, const String &value = String()); NB some warnings concern wx itself
There's definitely something that doesn't work for Mageia9 in the Guayadeque sources I have tried to use some git archives further and further back to old commits (I went even back to april 2021...) they need patches to buid, but Guayadeque crashes (segfault) everytime The only clone that can be built and gets a working Guayadeque is the one from the git clone from the commit of 2020 12 22 that was used for Mageia8 with the patches from Mageia8 Since there is a serious regression with the last version and no answer from upstream it maybe necessary to downgrade Guayadeque to the same version as in Mageia8 ! I built a rpm for Mageia9 with mock (for which I used a workaround see : https://bugs.mageia.org/show_bug.cgi?id=32230) same spec file same patches the rpm installed works perfectly even with a copy of the guayadeque config and database from Mageia8 Unless someone find the right patches to have a working rpm with the last version ! Unless Guayadeque will be rebuilt upon wxgtk when it has been updated from 3.2.1 to 3.2.2 in Mageia9 and then it works ?!
Try to disable "Enable equalizer" and "Enable volume and fader" from the "Playback" preferences.
Hi Jani Nice diagnostic !!!! Congratulations I reinstalled guayadeque 4.7.1 I first disabled both "Enable equalizer" and "Enable volume and fader" => NO CRASH Then I enabled "Enable volume and fader" alone => CRASH Then I enabled "Enable equalizer" alone => NO CRASH NB when I tried to rebuild with 4.7 version inside mock I noticed some warnings about taglib ... and about FaderPlaybin : https://bugs.mageia.org/show_bug.cgi?id=32231#c19 I added a patch (that will come attached) but it was not enough to prevent CRASH
Created attachment 13992 [details] patch to try having no warning during build patch to prevent some warnings during building NB the warnings didn't prevent to build without this patch Applying the patch makes the warning disappear but doesn't prevent Guayadeque to crash I'm gonna write to upstream thanks to you for having narrowed the cause of the crash
Summary: guayadeque built upon wxgtk 3.2.0, taglib crashes inside Mageia9 => guayadeque crashes inside Mageia9 when "enable volume and fader" is activated in settings
I will try to build upon the commit on Mar 18, 2023 since apparently Juan brought lots of changes on FaderPlayerbin.cpp and MediaCtrl.cpp and GstUtils.cpp
I can reproduce a crash also with "Enable equalizer" when closing the app. Play some music, press stop, close the program and a crash window appears.
Hi Jani I have narrowed the origin of the problem : I tested some rpms built inside mock for Mageia9 with severalgit clone from successive commits commit from 2021/04/08 OK commit from 2021/04/09 OK commit from 2021/04/12 OK commit from 2021/04/15 OK commit from 2021/04/17 OK commit from 2021/04/18 OK The problem appeared with commit from 2021/04/20 and remains until now I filled a bug upstream : https://github.com/anonbeat/guayadeque/issues/162 Now we have two possibilities : 1) A warning in ERRATA until it's corrected upstream (or by ourselves) a downgrade to 2) replace the 4.7 version by the the git clone of 2021/04/18 b608f7b82d32b90d4e408d0bd91a0f65d36931d3
Created attachment 13993 [details] spec file for the last working commit spec file for the git clone of 2021/04/18
@ Jani NB I built an rpm from the git clone of 2021/04/18 for Mageia9 I uninstalled the rpm from Mageia9 core and installed this built rpm It works perfectly : no crash with fader and equalizer activated (these are useful) A temporary solution may be to use the last spec file I have proposed, Modifying it rename this rpm 4.7-2.git20210418 to use it as an update I will attach this modified spec file Nevertheless I saw in the http://svnweb.mageia.org/ that you wrote a patch to disable these options for the 4.7 version (that doesn't need guayadeque-0.4.6-wxgtk3.1.patch anymore... this needs to modify the Release to %mkrel 2 if we want to use as an update I'm gonna try to build with your last modified spec and patch and test it
Created attachment 13998 [details] spec file for the last working commit allowing to use it as an update spec file for the last working commit allowing to use it as an update for the buggy 4.7 version in Mageia9core It may be an alternative solution of using the patch to disable the fader and the equlizer...
@ Jani I built and tested with the patch you wrote in http://svnweb.mageia.org/ to disable equalizer and fader It's OK for a new and first install of guayadeque the /home/myname/.guayadeque/ *.cfg created files are correct : equalizer and fader are disabled But for an update of the previous used core version these config files are already created and the update doesn't change them so the crash remains Two solutions for this ERRATA (not user friendly) Using as an update the solution I propose in https://bugs.mageia.org/show_bug.cgi?id=32231#c28 and https://bugs.mageia.org/show_bug.cgi?id=32231#c29
Hi Jani In reply to a mail I sent to him I've just received an answer from Juan Rios (anonbeat) We already communicated in the past to correct some bugs and he usually was very fast to reply and correct the problems (never more than 2 days !) Now he is a little busy (he's moving house) but he will have a look as soon as possible at the bug report that I wrote but that he had no time yet to read https://github.com/anonbeat/guayadeque/issues/162 where is narrowed the cause of the problem which appeared for fader and equalizer after the commit of 2021/04/20 https://github.com/anonbeat/guayadeque/commit/a341f649a0eda9cb641a30003a0db672b29c87fa I will test the modified source as soon as he provides it if it's Ok I will provide here the new spec for update
Hi Jani and to others interested with Guayadeque I got very bad and sad news from Juan Rios (anonbeat): He stops maintaining Guayadeque (after 7 years of work to improve his initial release from 2017 creating one of the best music player I know) It's confirmed by his last commit : https://github.com/anonbeat/guayadeque/commit/d524675772f4600c259414b535ff7a980ca1c962 The bug causing the crash when Fader & Volume and Equalizer are activated won't be repaired for Mageia9 even if we know which commit induced this... https://github.com/anonbeat/guayadeque/commit/a341f649a0eda9cb641a30003a0db672b29c87fa Nevertheless it's an opensource project and some of its last contributors will perhaps continue NB The project has never caused security problem and I will continue to use it as it is ... (I created for my own use a rpm with the git clone of 2021/04/18 b608f7b82d32b90d4e408d0bd91a0f65d36931d3 allowing to use fader and equalizer)
Now there are two ways to solve the bug for Mageia9 users - Propose the last 4.7 version with the patch added by Jani disabling fader and equalizer in the config file - Revert to the git clone of 2021/04/18 which allows fader and equalizer
I found an explanation to the crash of Guayadeque 4.7 with fader and equalizer enabled I have built guayadeque for Mageia8 with a git clone of its last commit 8f21414475504d820d027b1d20268d7b39547188 from 2023/09/28 it needs only one patch : guayadeque-0.4.6-wxgtk3.1.patch (no more patch needed for taglib) I installed it inside Mageia8 where it works perfectly (we can use fader, volume control and equalizer) => no crash ! NB in Mageia8 Guayadeque is built upon wxgtk-3.1.5 (Anonbeat, the guayadeque creator, had initially written the source for wxgtk3.0 but, when we asked for this, had modified the source so that it can build with wxgtk3.1.5) The switch to wxgt3.2.0 needs again some work to adapt the source and that seems the reason why Juan stopped to care about his creation !!! (no backward compatibility of wxgtk3.2.0 is painful... and one may get bored with this !) For Mageia9 : A patch has been written to build upon wxgtk3.2.0 (guayadeque-0.4.6-wxgtk3.1.6.patch) it had been originally created by https://github.com/sluedecke for this issue https://github.com/anonbeat/guayadeque/issues/144 and worked until the commit of 2021/04/18 But it's not enough since this commit Segfault are often appearing when a new version of wxgtk appears and when programs working perfectly with a previous version are built with the last version (we had a bad experience in Mageia8 when some rpms had been rebuilt upon wxgtk3.1.5 and we had to revert back explicitely to a BuildRequires: wxgtk3.0-devel for some of them !) Fortunately in Mageia8 2 versions of wxgtk coexisted (3.0 and 3.1.5) In Mageia9 we only have wxgtk3.2.0 and no way to build anymore upon 3.1.5 version and use it There's a new patch to write to build guayadeque upon wxgtk3.2.0 to use the commits since the commit of 2021/04/18 :-(
Created attachment 14114 [details] spec file to build Guayadeque for Mageia8 with the last git clone spec file to build Guayadeque for Mageia8 with the last git clone from 2023/09/28 just before Anonbeat ended its work (he didn't rewrite the source for wxgtk3.2.0 but it's still valid for wxgtk 3.1.5) NB by default in Mageia8 wxgtk-devel leads to wxgtk3.1.5
@ Hi Jani and David 1) The problem of crash of Guayadeque inside Mageia9 needs a solution The patch that you added inside Cauldron solves it partly May you propose the same version 0.4.7-2 as in Cauldron (with this patch) for an update testing in Mageia9 ? I built it with the patch - 0001-Disable-Enable-equalizer-and-Enable-volume-and-fader.patch and it doesn't crash anymore 2) Besides this You can use the last git clone for Cauldron : last commit 8f21414475504d820d027b1d20268d7b39547188 from 2023/09/28 it needs now only 3 patches to be built : - guayadeque-0.4.6-wxgtk3.1.patch - guayadeque-0.4.6-wxgtk3.1.6.patch - 0001-Disable-Enable-equalizer-and-Enable-volume-and-fader.patch (and it can even be used as an update for Mageia9 : I built it, tested it no crash anymore) NB this last commit from 2023/09/28 builds perfectly inside Mageia8 and needs only one patch to be built : - guayadeque-0.4.6-wxgtk3.1.patch It works perfectly for wxgtk3.1.5 and gstreamer1.0-1.18.5 for which it had been designed (no crash with fader or equalizer enabled) I have been digging a lot to understand what creates the crash with wxgt3.2.0 even if we use the guayadeque-0.4.6-wxgtk3.1.6.patch But the problem seems to be caused by some incompatibility with gstreame1.0-1.22.3 I have explored the diffs in the commit from 2021/04/20 with which the crash appeared... but it's out of my knowledge to understand what change created the problem and what patch would repair this... there's something wrong in /src/audio/GstUtils.cpp /src/audio/FaderPlaybin.cpp /src/audio/MediaCtrl.cpp It's shown by the debug file automatically created by Guayadeque itself (gdb is useless : it shows the same thing but needs to install a bunch of debug rpms)
Created attachment 14148 [details] useful end of the debug file created by Guayadeque when it crashes I attach only the useful lines at the end of the debug file created by Guayadeque when it crashes
Hi Jani and David VERY GOOD NEWS I finally got a solution to close this bug and to provide the last git clone of Guayadeque with a single simple patch Yesterday I have asked some help to openmonk , one of the best contributor of Guayadeque created by Juan Rios (Aka Anonbeat) Since Juan decided to end we can't merge anymore on his github ... openmonk has just created his fork with a new commit that solves all our problems https://github.com/openmonk/guayadeque I built it tested it and everything is OK : no need to disable neither fader nor equalizer There are two ways to solve this : 1) Use the last git clone from the original anonbeat's source and add a single patch (I provide the spec file and the patch attached) 2) simply change the github source in the spec file : no patch needed
Created attachment 14152 [details] spec file for the last git clone of guayadeque spec file for the last git clone of guayadeque from anonbeat to use with the patch gstreamer1.22.3-wxwidget3.2.1.patch
Attachment 13991 is obsolete: 0 => 1 Attachment 13992 is obsolete: 0 => 1 Attachment 13993 is obsolete: 0 => 1 Attachment 13998 is obsolete: 0 => 1 Attachment 14148 is obsolete: 0 => 1 Attachment 13973 is obsolete: 0 => 1 Attachment 13974 is obsolete: 0 => 1 Attachment 13988 is obsolete: 0 => 1 Attachment 13989 is obsolete: 0 => 1 Attachment 13990 is obsolete: 0 => 1
Created attachment 14153 [details] patch to build the last git clone upon gstreamer 1.22.3 and wxgtk 3.2.1 This patch from openmonk to build guayadeque with the last versions of gstreamer (1.22.3) and wxgtk (3.2.1)
PS I need to ask openmonk if he is OK that we use his fork as source since now (it will not need any patch !) For the moment in the spec file I provide anonbeat's source and the patch from openmonk What ever you decide it will solve this bug and provide the last improvements (it may be a 4.8 version of Guayadeque !)
Whiteboard: (none) => Cauldron too !
NB Careful : there are 2 spec files The first spec file "for Mageia8" may be proposed as an update for Mageia8 and doesn't need any patch The second spec file is for Mageia9 (as an update) and for Cauldron and needs the provided patch
I simplify the update by providing a new spec file for Mageia9 or cauldron to use the last openmonk git clone : no more patch needed
Created attachment 14157 [details] spec file for Mageia9 and Cauldron spec file for Mageia9 and Cauldron using a git clone of openmonk's fork https://github.com/openmonk/guayadeque With this spec file no more patch needed to build upon wxgtk3.2.1 and gstreamer1.22.3 NOTA BENE This spec file is not for Mageia8 ! For Mageia8 use the first spec file (for building upon wxgtk3.1.5 and gstreamer1.18.5)
Attachment 14152 is obsolete: 0 => 1 Attachment 14153 is obsolete: 0 => 1
Hi Jani David (and bugsquad..) I have finally submitted what I have done - to cauldron - and to Mageia9/core/updates_testing They have been correctly built for all arches You may ask to QA to test this update (I already tested this and I can say it's OK for 64bits) Package in 9/Core/Updates_testing: ====================== guayadeque-0.4.8-4.git20231115.1.mga9.rpm from SRPM guayadeque-0.4.8-4.git20231115.1.mga9.srpm Advisory suggested ====================== This update correct this bug https://bugs.mageia.org/show_bug.cgi?id=32231 Now it's correctly built with wxgtk-3.2.1 and gstreamer-1.22.3 No more patch needed No more crash when fader or equalizer are enabled 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
Assignee: pkg-bugs => qa-bugs
Version: 9 => CauldronWhiteboard: Cauldron too ! => MGS9TOO
Whiteboard: MGS9TOO => MGA9TOO
Created attachment 14158 [details] Crash at start Not good for mga 9 i586, the current and testing version crash at start
Created attachment 14159 [details] Info created by the crash
this seems to be linked with an old issue with 32bits system https://github.com/anonbeat/guayadeque/issues/137 It is apparently caused by our rpm macros https://bugs.mageia.org/show_bug.cgi?id=29742 As not a lot of people use 32bits this may not have appeared for a long time to anyone The workaround that I had to use in 2021 for i586 system was not to use our %cmake %cmake_build %cmake_install As I had been told the dev of guayadeque https://bugs.mageia.org/show_bug.cgi?id=29742#c21 I cloned his last code on my 32bits system launched a console cd to the guayadeque folder enter ./buildd then sudo make install And it worked ! I then modified the buildt script to add Mageia build flags https://bugs.mageia.org/attachment.cgi?id=13054 https://bugs.mageia.org/show_bug.cgi?id=29742#c33 Guayadeque crashed NB the rpm crashed inside a real i586 system but not in a virtual machine ! This seems to be caused by stricly a "rpm build flags" problem for 32bits systems certainly this one : -fstack-protector --param=ssp-buffer-size=4 https://bugs.mageia.org/show_bug.cgi?id=29742#c40 The conclusion then was : won't fix Since I opened the bug https://bugs.mageia.org/show_bug.cgi?id=29742 no one else than me complained about crash on 32bits system : perhaps nobody uses this arch anymore (I don't use this because some other programs I maintain needs strictly a 64bits) to way to resolve this : 1) modify the spec file so that we have a conditional specific way to build for 32bits without our build-flags (that seems to be complicated) 2) exclude to build a rpm for the 32bits arch
Forgot to say the 3) way to resolve this : Warning in ERRATA : our rpm of Guayadeque can't work on 32bits systems If you really want to use this program : build it yourself from source from here : https://github.com/openmonk/guayadeque following the README.md
(In reply to Philippe Didier from comment #49) > to way to resolve this : > 1) > modify the spec file so that we have a conditional specific way to build for > 32bits > without our build-flags (that seems to be complicated) I try to give a hand with that
Yes, the last time this was up for update I could not get it to work on ANY 32-bit install on real hardware, even x86_64 hardware. For some reason, which we never really discovered, it WOULD work on a 32-bit VM in VirtualBox.
CC: (none) => andrewsfarm
(In reply to katnatek from comment #47) > Created attachment 14158 [details] > Crash at start > > Not good for mga 9 i586, the current and testing version crash at start Hi katnatek Have you tried Guayadeque on Mageia9 or Cauldron with other arches than i586 ? For i586 systems the problem appeared for Mageia8 and got no solution Before this Guayadeque worked perfectly on Mageia7 and Mageia6 i586 : The build flags have changed after those versions of Mageia
Created attachment 14160 [details] Crash information on x86_64 Sorry crash at star also on my Mageia 9 x86_64 inxi -F System: Host: phoenix Kernel: 6.4.16-desktop-3.mga9 arch: x86_64 bits: 64 Desktop: LXQt v: 1.3.0 Distro: Mageia 9 Machine: Type: Desktop System: Dell product: OptiPlex 755 v: N/A serial: <superuser required> Mobo: Dell model: 0PU052 serial: <superuser required> BIOS: Dell v: A09 date: 03/11/2008 CPU: Info: dual core model: Intel Core2 Duo E6550 bits: 64 type: MCP cache: L2: 4 MiB Speed (MHz): avg: 2327 min/max: N/A cores: 1: 2327 2: 2328 Graphics: Device-1: Intel 82Q35 Express Integrated Graphics driver: i915 v: kernel Display: x11 server: X.org v: 1.21.1.8 with: Xwayland v: 22.1.9 driver: X: loaded: intel,v4l dri: i915 gpu: i915 resolution: 1024x768 API: OpenGL v: 2.1 Mesa 23.1.7 renderer: i915 (: Q35) Audio: Device-1: Intel 82801I HD Audio driver: snd_hda_intel API: ALSA v: k6.4.16-desktop-3.mga9 status: kernel-api Server-1: PulseAudio v: 16.1 status: active Network: Device-1: Intel 82566DM-2 Gigabit Network driver: e1000e IF: enp0s25 state: up speed: 100 Mbps duplex: full mac: 00:1e:c9:6c:bc:3d IF-ID-1: virbr0 state: down mac: 52:54:00:b3:6f:9c Drives: Local Storage: total: 298.09 GiB used: 194.8 GiB (65.3%) ID-1: /dev/sda vendor: Western Digital model: WD3200BEKT-60V5T1 size: 298.09 GiB Partition: ID-1: / size: 49.2 GiB used: 11.49 GiB (23.4%) fs: ext4 dev: /dev/sda1 ID-2: /home size: 238.91 GiB used: 182.99 GiB (76.6%) fs: ext4 dev: /dev/sda6 Swap: ID-1: swap-1 type: partition size: 4 GiB used: 326.5 MiB (8.0%) dev: /dev/sda5 Sensors: System Temperatures: cpu: 46.0 C mobo: N/A Fan Speeds (RPM): N/A Info: Processes: 212 Uptime: 23m Memory: 1.91 GiB used: 1008.4 MiB (51.7%) Shell: Bash inxi: 3.3.26
(In reply to Philippe Didier from comment #49) Or the rpm build skip something/make something or I don't find why is failing on i586, I reduce the buildflags to just -O2, but still crash, I will build from sources without package to see what I can find
(In reply to katnatek from comment #54) > Created attachment 14160 [details] > Crash information on x86_64 > > Sorry crash at star also on my Mageia 9 x86_64 > inxi -F > System: > Host: phoenix Kernel: 6.4.16-desktop-3.mga9 arch: x86_64 bits: 64 > Desktop: LXQt v: 1.3.0 Distro: Mageia 9 > Machine: > Type: Desktop System: Dell product: OptiPlex 755 v: N/A > serial: <superuser required> > Mobo: Dell model: 0PU052 serial: <superuser required> BIOS: Dell v: A09 > date: 03/11/2008 > CPU: > Info: dual core model: Intel Core2 Duo E6550 bits: 64 type: MCP cache: > L2: 4 MiB > Speed (MHz): avg: 2327 min/max: N/A cores: 1: 2327 2: 2328 > Graphics: > Device-1: Intel 82Q35 Express Integrated Graphics driver: i915 v: kernel > Display: x11 server: X.org v: 1.21.1.8 with: Xwayland v: 22.1.9 driver: X: > loaded: intel,v4l dri: i915 gpu: i915 resolution: 1024x768 > API: OpenGL v: 2.1 Mesa 23.1.7 renderer: i915 (: Q35) > Audio: > Device-1: Intel 82801I HD Audio driver: snd_hda_intel > API: ALSA v: k6.4.16-desktop-3.mga9 status: kernel-api > Server-1: PulseAudio v: 16.1 status: active > Network: > Device-1: Intel 82566DM-2 Gigabit Network driver: e1000e > IF: enp0s25 state: up speed: 100 Mbps duplex: full mac: 00:1e:c9:6c:bc:3d > IF-ID-1: virbr0 state: down mac: 52:54:00:b3:6f:9c > Drives: > Local Storage: total: 298.09 GiB used: 194.8 GiB (65.3%) > ID-1: /dev/sda vendor: Western Digital model: WD3200BEKT-60V5T1 > size: 298.09 GiB > Partition: > ID-1: / size: 49.2 GiB used: 11.49 GiB (23.4%) fs: ext4 dev: /dev/sda1 > ID-2: /home size: 238.91 GiB used: 182.99 GiB (76.6%) fs: ext4 > dev: /dev/sda6 > Swap: > ID-1: swap-1 type: partition size: 4 GiB used: 326.5 MiB (8.0%) > dev: /dev/sda5 > Sensors: > System Temperatures: cpu: 46.0 C mobo: N/A > Fan Speeds (RPM): N/A > Info: > Processes: 212 Uptime: 23m Memory: 1.91 GiB used: 1008.4 MiB (51.7%) > Shell: Bash inxi: 3.3.26 Hi That looks very strange : on my 64bits system I have no crash at all with this update from updates_testing that kind of crash never happened to me : your crash is induced by libwx_gtk3u_wxsqlite3 ! It's perhaps induced by a missing dependency (a rpm installed on my system but not on yours) until now the crashes with guayadeque from core repo was linked to wxgtk3.2.1 or gstreamer1.22.3 https://bugs.mageia.org/show_bug.cgi?id=32231#c4 the only way to prevent it was to disable fader and equalizer openmonk corrected the source so that guayadeque can be built upon wxgtk3.2.1 and gstreamer1.22.3 and works May you uninstall guayadeque-0.4.8-4.git20231115.1.mga9.rpm erase /home/yourname/.guayadeque install guayadeque-0.4.7-1 from core repo launch it (and disable immediately fader and equalizer : tab view > settings > play) then add a directory for your music files (tab sources > my music > add a place) If a crash appears verify if it's caused by libwx_gtk3u_wxsqlite3 !
(In reply to Thomas Andrews from comment #52) > Yes, the last time this was up for update I could not get it to work on ANY > 32-bit install on real hardware, even x86_64 hardware. > > For some reason, which we never really discovered, it WOULD work on a 32-bit > VM in VirtualBox. Hi Thomas Would you please test this update from updates_testing on your 64bits system to verify if you get a crash ?
Hi again Katantek I saw in comment https://bugs.mageia.org/show_bug.cgi?id=32231#c56 "Host: phoenix Kernel: 6.4.16-desktop-3.mga9 arch: x86_64 bits: 64 Desktop: LXQt v: 1.3.0 Distro: Mageia 9" I personally use Plasma as desktop... and get no crash is there some rpm brought by plasma that is missing with LXQt ? Another track to understand what happens for you with the rpm from updates_testing (there's maybe something wrong in your /home/yourusername/.guayadeque/cache.db) may you rename /home/yourusername/.guayadeque to /home/yourusername/.guayadequebak and launch again Guayadeque : it will create a new /home/yourusername/.guayadeque Then you'll have to add a new path to your music source
PS When testing the proposed update I always rename /home/myusername/.guayadeque to /home/myusername/.guayadequebak If it works I then quit Guayadeque erase the new created /home/myusername/.guayadeque and then copy /home/myusername/.guayadequebak to /home/myusername/.guayadeque and then launch again Guaydeque Doing so my previous database is preserved if I have to downgrade to a previous working version (20 000 indexed files with lyrics embedded ) We need other testers... to verify if the crash appears on other 64bits systems than yours
(In reply to Philippe Didier from comment #56) > May you uninstall guayadeque-0.4.8-4.git20231115.1.mga9.rpm > erase /home/yourname/.guayadeque > install guayadeque-0.4.7-1 from core repo > launch it (and disable immediately fader and equalizer : tab view > settings > > play) > then add a directory for your music files (tab sources > my music > add a > place) > If a crash appears verify if it's caused by libwx_gtk3u_wxsqlite3 ! That is not necessary, my workflow was: Install current version Run as user from console to try to reproduce reported behaviour I can't do that, I get a crash Update to testing version Run as user from console I get the crash I make some progress with i586, I set optflags to -O2 %{debugcflags} and have to unset build_ldflags , the bin generated don't crash Now I have to find the right combination of optflags to each arch
CC: (none) => ngompa13
Very strange indeed To test it further on my 64bits system A) 1) I install current version (with no /home/myusername/.guayadeque) Launch it, (without disabling fader and equalizer) add a path to one directory it creates /home/myusername/.guayadeque and a db Read an album Crash ! because of fader and gstreamer (not because of wxsqlite !) when I launch it from its icon or from the console 2) I install the updated version from updates_testing without suppressing this /home/myusername/.guayadeque Launch it again from its icon : no more crash Launch from the console : no more crash B) 1) I uninstall guayadeque 2) I install only the version from updates_testing Use the previous /home/myusername/.guayadeque keeped from A no crash 3) rename /home/myusername/.guayadeque to /home/myusername/.guayadequebak2 Launch again, it creates a new /home/myusername/.guayadeque add a path to one directory no crash C) I use my old /home/myusername/.guayadeque that I created in Mageia8 (that I had previously backedup ) and already used inside Mageia9 do the same test as in A and in B same results : crash with the current version no crash with the version from updates_testing I think that some hidden dependency is missing on your system ...
Nota Bene For me the crash appears for the current version only when I read a filelist not immediately when I launch Guayadeque When I launch it I can add a path to a directory, then Guayadeque builds its database and the Library appears I can choose an album to read The first file is played but the crash appears when the second file is gonna be read it's the enabled fader that causes the crash ! Jani added a patch to disable the fader and equalizer in the settings (in cauldron) I tested it after building Guayadeque with his spec file and this patch for Mageia9 I had no more crash ! but loosed some functionalities That's the reason why I asked openmonk (a Guayadeque dev) to bring some corrections to the source That seemed OK If your crash appears immediately when you launch Guayadeque before trying to use it that's not the same bug
"If your crash appears immediately when you launch Guayadeque before trying to use it that's not the same bug" Then you have more than one bug here. On a Dell Dimension E520, Core2Quad, AMD HD8570 graphics, nearly untouched MGA9 Plasma install (This install has never had any version of guayadeque installed on it): I tried something you didn't - installing the update directly rather than updating an old install. Lacking a rpm list for this update, I used qarepo to download "guayadeque*" and then used urpmi to install it: # urpmi guayadeque To satisfy dependencies, the following packages are going to be installed: Package Version Release Arch (medium "QA Testing (64-bit)") guayadeque 0.4.8 4.git2023111> x86_64 (medium "Core Release (distrib1)") gspell-i18n 1.12.1 1.mga9 x86_64 lib64gspell1_2 1.12.1 1.mga9 x86_64 lib64jsoncpp24 1.9.4 4.mga9 x86_64 lib64wx_baseu3.2_0 3.2.1 3.mga9 x86_64 lib64wx_baseu_xml3.2_0 3.2.1 3.mga9 x86_64 lib64wx_gtk3u_aui3.2_0 3.2.1 3.mga9 x86_64 lib64wx_gtk3u_core3.2_0 3.2.1 3.mga9 x86_64 lib64wx_gtk3u_html3.2_0 3.2.1 3.mga9 x86_64 lib64wx_gtk3u_qa3.2_0 3.2.1 3.mga9 x86_64 lib64wx_gtk3u_wxsqlite3_3.2_0 4.9.1 1.mga9 x86_64 wxgtk3.2 3.2.1 3.mga9 x86_64 27MB of additional disk space will be used. 7.8MB of packages will be retrieved. Proceed with the installation of the 12 packages? (Y/n) y There were no installation issues, but when I attempted to run it from the Plasma menu, it immediately crashed. Still needs work somewhere.
https://github.com/anonbeat/guayadeque/commit/d524675772f4600c259414b535ff7a980ca1c962 If the application is no longer being maintained, then we should strongly consider dropping it in Cauldron/Mageia10.
http://madb.mageia.org/tools/listRpmsForQaBug/bugnum/32231/application/0 indicates that the guayadeque rpm was the only package involved, so it would seem I didn't miss any listed dependencies in comment 63.
To this application not like the mageia's ldflags , I test build for x86_64 without that and not crash at start the line to do that is %global build_ldflags %{nil} I still need to tune the optflags for i586, -O2 %{debugcflags}, works but I want to search what more can be added
(In reply to Thomas Andrews from comment #64) > https://github.com/anonbeat/guayadeque/commit/ > d524675772f4600c259414b535ff7a980ca1c962 > > If the application is no longer being maintained, then we should strongly > consider dropping it in Cauldron/Mageia10. Philippe Didier made the switch to an active developer, for the moment we can keep the application https://github.com/openmonk/guayadeque
(In reply to Thomas Andrews from comment #63) > "If your crash appears immediately when you launch Guayadeque before trying > to use it > that's not the same bug" > > Then you have more than one bug here. > > On a Dell Dimension E520, Core2Quad, AMD HD8570 graphics, nearly untouched > MGA9 Plasma install (This install has never had any version of guayadeque > installed on it): > > I tried something you didn't - installing the update directly rather than > updating an old install. I did this indeed ! https://bugs.mageia.org/show_bug.cgi?id=32231#c61 read the B) part of this comment NB I use an updated Mageia9 (updated from core-updates tainted-updates and nonfree-updates) (that's the only way to install gstreamer1.0-plugins-ugly > > Lacking a rpm list for this update, I used qarepo to download "guayadeque*" > and then used urpmi to install it: > > # urpmi guayadeque > To satisfy dependencies, the following packages are going to be installed: > Package Version Release Arch > (medium "QA Testing (64-bit)") > guayadeque 0.4.8 4.git2023111> x86_64 > (medium "Core Release (distrib1)") > gspell-i18n 1.12.1 1.mga9 x86_64 > lib64gspell1_2 1.12.1 1.mga9 x86_64 > lib64jsoncpp24 1.9.4 4.mga9 x86_64 > lib64wx_baseu3.2_0 3.2.1 3.mga9 x86_64 > lib64wx_baseu_xml3.2_0 3.2.1 3.mga9 x86_64 > lib64wx_gtk3u_aui3.2_0 3.2.1 3.mga9 x86_64 > lib64wx_gtk3u_core3.2_0 3.2.1 3.mga9 x86_64 > lib64wx_gtk3u_html3.2_0 3.2.1 3.mga9 x86_64 > lib64wx_gtk3u_qa3.2_0 3.2.1 3.mga9 x86_64 > lib64wx_gtk3u_wxsqlite3_3.2_0 4.9.1 1.mga9 x86_64 > wxgtk3.2 3.2.1 3.mga9 x86_64 > 27MB of additional disk space will be used. > 7.8MB of packages will be retrieved. > Proceed with the installation of the 12 packages? (Y/n) y > > There were no installation issues, but when I attempted to run it from the > Plasma menu, it immediately crashed. > > Still needs work somewhere. I think that some hidden dependency of Guayadeque, needed by an other program is already installed on my system One other test you may try : uninstall guayadeque ! delete the /home/yourusername/.guayadeque Install guayadeque from core (current version) launch it and verify if it crashes immediately... That didn't happen for me (the crash, for which this bug was created, happened lately, when playing music, after the database had been created, and some tracks added in the playlist)
(In reply to katnatek from comment #66) > To this application not like the mageia's ldflags , I test build for x86_64 > without that and not crash at start > > the line to do that is > > %global build_ldflags %{nil} > > I still need to tune the optflags for i586, -O2 %{debugcflags}, works but I > want to search what more can be added What is surprising is that I tested it twice : built with mock built on the MageiaBS I'm wondering which rpm dependency is missing in the spec file Not easy to investigate because this hidden rpm is a dependency of an other program, The way to find the culprit would be to compare the rpms list of a system where guayadeque works and the list of a system where it crashes
(In reply to Thomas Andrews from comment #64) > https://github.com/anonbeat/guayadeque/commit/ > d524675772f4600c259414b535ff7a980ca1c962 > > If the application is no longer being maintained, then we should strongly > consider dropping it in Cauldron/Mageia10. The application is always been maintained by one of its main developers on a fork https://github.com/openmonk/guayadeque/tree/master It doesn't need to be dropped we only need to understand why it crashes on some systems and works well on some others
There is indeed an other bug than this one corrected by the patch of Jani for Cauldron and the last git clone proposed for updates_testing This bug was about a late crash with fader and equalizer enabled We need perhaps to open a new bug for an immediate crash when launching Guayadeque (some dependency missing or a bad link to sqlite) NB too this version of guayadeque has been built with and for a totally updated Mageia9 (glibc-2.36.51 libxml2-2.10.4-1.2) It must be tested with a totally updated Mageia9 (core-updates and tainted-updates)
(In reply to Philippe Didier from comment #68) > (In reply to Thomas Andrews from comment #63) > > > > I tried something you didn't - installing the update directly rather than > > updating an old install. > > > I did this indeed ! > https://bugs.mageia.org/show_bug.cgi?id=32231#c61 > read the B) part of this comment OK. I saw the part about using the old.guayadeque folder, but skipped over the part where you renamed it before running it. My apologies. > NB I use an updated Mageia9 (updated from core-updates tainted-updates and > nonfree-updates) > > (that's the only way to install gstreamer1.0-plugins-ugly > So is mine, and the tainted gstreamer plugin is installed. However, that shouldn't make a difference with running guayadeque unless it's actually a dependency. And if it IS a dependency, then guayadeque should be in the tainted repos, not core. > > > > I think that some hidden dependency of Guayadeque, needed by an other > program is already installed on my system > > One other test you may try : > uninstall guayadeque ! delete the /home/yourusername/.guayadeque > Install guayadeque from core (current version) > launch it and verify if it crashes immediately... It does. It did create a new .guayadeque before crashing, but I don't know if there is anything wrong with it. > That didn't happen for me (the crash, for which this bug was created, > happened lately, when playing music, after the database had been created, > and some tracks added in the playlist) I will attach the xml file generated by guayadeque from the crash of the current version. Maybe it will tell you something.
Created attachment 14161 [details] TJ's crash information
Advisory with the SRPM from comment 46 added to SVN. Please remove the "advisory" keyword if it needs to be changed. It also helps when obsolete advisories are tagged as "obsolete"
CC: (none) => marja11Version: Cauldron => 9Status comment: (none) => advisory in comment 46Whiteboard: MGA9TOO => (none)Keywords: (none) => advisory
Hi Thomas Thanks for this xml file But apparenly there's nothing in it about the crash : If you look at the attached files from katnatek : https://bugs.mageia.org/attachment.cgi?id=14159 https://bugs.mageia.org/attachment.cgi?id=14160 They end with some lines (15 or 17) beginning with <stack> ending with </stack> the first line of these lines after <stack> <frame level="0" function="Guayadeque::guMainApp::OnFatalException()" indicates the crash the others lines surround the cause of the crash something wrong for Guayadeque database (guDB) and Guayadeque database cache (guDBCache) with libwx_gtk3u_wxsqlite3-3.2.so.0 Your xml file indicates only the modules but doesn't indicate the stack pile For my initial bug report I attached an xml file too https://bugs.mageia.org/attachment.cgi?id=13965 It ended completely differently it indicated problems for guFaderPlaybin and for guMediaCtrl That's what the Jani's patch corrected by disabling fader and equalizer and that's what corrected openmonk upstream in his last commits on his fork allowing to build with wxgtk3.2.1 and gstreamer1.22.3 I had no crash with guayadeque current version rebuilt with Jani's patch I had no crash with what I propose in updates_testing I never encountered the same problem as katnatek ! It's clearly an other bug that didn't appear to anyone before (perhaps not so many users of Guayadeque in Mageia9) It's an aporia for me ! I can't reproduce it I'm gonna contact openmonk and see if he can explain this
Last detail : We don't use the same kernel !!! Mine is Linux 6.4.9-desktop-4.mga9 x86_64 and I get no crash Andrew's is Linux 6.4.16-desktop-4.mga9 x86_64 katnatek's is Linux 6.4.16-desktop-3.mga9 x86_64 or Linux 6.5.11-desktop586-2.mga9 i686
(In reply to Philippe Didier from comment #76) > Last detail : > We don't use the same kernel !!! > Mine is Linux 6.4.9-desktop-4.mga9 x86_64 and I get no crash > > Andrew's is Linux 6.4.16-desktop-4.mga9 x86_64 > > katnatek's is Linux 6.4.16-desktop-3.mga9 x86_64 > or Linux 6.5.11-desktop586-2.mga9 i686 useless comment !! I restarted with Linux 6.4.16-desktop-3.mga9 x86_64 => no crash at start no crash with equalizer and fader enabled
(In reply to Marja Van Waes from comment #74) > Advisory with the SRPM from comment 46 added to SVN. Please remove the > "advisory" keyword if it needs to be changed. It also helps when obsolete > advisories are tagged as "obsolete" Indeed this update is not yet validated
And I just booted into the 6.4.9-4 kernel, and the guayadeque that shipped with Mageia 9 still crashed, though I had the impression that it took just a bit longer to do so. The 6.4.16-3 i586 server kernel has some problems, but the x86_64 kernel doesn't appear to have them. Work is proceeding to update to the 6.5.11 series kernel, but it's not ready for general testing yet. See bug 32530. As for my xml file, that's the one that was put there. All I did was pass it on. Perhaps my install simply failed before it got as far as yours did. Would an strace file generated by running guayadeque be of any assistance?
Last and strangest news I have a second computer (a laptop) that I don't use for compiling nor building packages with mock or testing rpms (I use my first computer for this and it has a fresh install of Mageia9) This laptop worked originally with Mageia8 and I upgraded it recently to Mageia9 with an usb stick created with isodumper for Mageia9 I installed today the Guayadeque rpm from updates_testing on this laptop and tested it : 1) first after having renamed /home/myusername/.guayadeque to /home/myusername/.guayadequebak I launch Guayadeque : it creates a new /home/myusername/.guayadeque and doesn't crash when playing tracks 2) I then erased the new /home/myusername/.guayadeque and renamed /home/myusername/.guayadequebak to /home/myusername/.guayadeque I launch again Guayadeque it works perfectly using the library (and of course its database) No crash at all for me on my two computers
I suspect that if you had a new, clean install of Mageia 9 (not an upgrade), and you installed gualadeque as one of the first things you added, it would crash for you, too. Whatever package is the missing dependency could have been on the Mageia 8 install, and then upgraded to the Mageia 9 package during the upgrade.
Created attachment 14162 [details] Changes to fix guayadeque Well I find a better way to fix guayadeque for both arches, disabling the as-needed ldflags You can ignore if you like the line that enable lto, just keep the subrel and %global _disable_ld_as_needed 1 changes
Created attachment 14163 [details] Drop not needed line Sorry in previous diff I don't remove a line part of my not working test
Attachment 14162 is obsolete: 0 => 1
Created attachment 14164 [details] guayadeque on Mageia 8 i586 And at less in VM also works on Mageia 8 i586
(In reply to Philippe Didier from comment #46) > Hi Jani David (and bugsquad..) > > I have finally submitted what I have done > - to cauldron > - and to Mageia9/core/updates_testing > They have been correctly built for all arches > > You may ask to QA to test this update > (I already tested this and I can say it's OK for 64bits) > > Package in 9/Core/Updates_testing: > ====================== > guayadeque-0.4.8-4.git20231115.1.mga9.rpm > > from SRPM > guayadeque-0.4.8-4.git20231115.1.mga9.srpm > Version and release are quite much messed up. I'd say it should have been 0.4.7-3.git20231115.1 to be somehow consistent between mga9 and cauldron. If there is a guarantee 0.4.8 is ever released one could use it as a version, and 0.gitxxxxyyzz.1 as a release for git snapshots.
This is not a critical bug as nothing major is not broken in users' systems. No known security issues etc.
Severity: critical => normal
(In reply to katnatek from comment #82) > Created attachment 14162 [details] > Changes to fix guayadeque > > Well I find a better way to fix guayadeque for both arches, disabling the > as-needed ldflags > Linker flag '-Wl,--as-needed' only removes unused libraries from linking. There might be a problem in app's build system itself and how it links. E.g. wrong linking order or missing libs from linking. Or then there's a bigger issue in some i586 libs having missing symbols.
(In reply to Jani Välimaa from comment #85) > (In reply to Philippe Didier from comment #46) > > Hi Jani David (and bugsquad..) > > > > I have finally submitted what I have done > > - to cauldron > > - and to Mageia9/core/updates_testing > > They have been correctly built for all arches > > > > You may ask to QA to test this update > > (I already tested this and I can say it's OK for 64bits) > > > > Package in 9/Core/Updates_testing: > > ====================== > > guayadeque-0.4.8-4.git20231115.1.mga9.rpm > > > > from SRPM > > guayadeque-0.4.8-4.git20231115.1.mga9.srpm > > > > Version and release are quite much messed up. I'd say it should have been > 0.4.7-3.git20231115.1 to be somehow consistent between mga9 and cauldron. > > If there is a guarantee 0.4.8 is ever released one could use it as a > version, and 0.gitxxxxyyzz.1 as a release for git snapshots. Hi Jani I'm sorry for the bad numbering but I have increased the rel each time I tested a new git clone Indeed a 0.4.8 version will certainly be taged as soon as the build upon wxgtk-3.2.0 and gstreamer1.22.3 will be OK with the last commits of openmonk I thought it was Ok since I tested it on two computers : one with a fresh install of Mageia9 the other upgraded from Mageia8 to Mageia9 : - no more crash with fader and equalizer enabled - no more patches needed to build upon upon wxgtk-3.2.0 and gstreamer1.22.3 (thanks to openmonk whose I use the git now that anonbeat ended to develop Guayadeque : Juan Rios seems to get bored with no backward compatibility of some of the BuildRequires implying to modify his source code) BUT a new bug appears for katnatek and Thomas Andrews! certainly induced by an hidden dependency that is installed on my computers but not on theirs About 586 version on 32bits computers it's an old problem https://bugs.mageia.org/show_bug.cgi?id=29742 it appeared when the mageia's macro changed for Mageia8 and didn't exist for Mageia7 No solution had been found !
(In reply to Philippe Didier from comment #88) > (In reply to Jani Välimaa from comment #85) > > (In reply to Philippe Didier from comment #46) > > > Hi Jani David (and bugsquad..) > > > > > > I have finally submitted what I have done > > > - to cauldron > > > - and to Mageia9/core/updates_testing > > > They have been correctly built for all arches > > > > > > You may ask to QA to test this update > > > (I already tested this and I can say it's OK for 64bits) > > > > > > Package in 9/Core/Updates_testing: > > > ====================== > > > guayadeque-0.4.8-4.git20231115.1.mga9.rpm > > > > > > from SRPM > > > guayadeque-0.4.8-4.git20231115.1.mga9.srpm > > > > > > > Version and release are quite much messed up. I'd say it should have been > > 0.4.7-3.git20231115.1 to be somehow consistent between mga9 and cauldron. > > > > If there is a guarantee 0.4.8 is ever released one could use it as a > > version, and 0.gitxxxxyyzz.1 as a release for git snapshots. > > Hi Jani > I'm sorry for the bad numbering but I have increased the rel each time I > tested a new git clone > Indeed a 0.4.8 version will certainly be taged as soon as the build upon > wxgtk-3.2.0 and gstreamer1.22.3 will be OK with the last commits of openmonk Please keep local builds and mageia builds separate from each others. IMO we should remove guayadeque from mga9 core/updates_testing and from cauldron to be able to resubmit with correct version and release.
(In reply to Philippe Didier from comment #88) > > About 586 version on 32bits computers it's an old problem > https://bugs.mageia.org/show_bug.cgi?id=29742 > it appeared when the mageia's macro changed for Mageia8 and didn't exist for > Mageia7 What macro change? I think we have not changed our build nor linker flags.
(In reply to Philippe Didier from comment #88) > a new bug appears for katnatek and Thomas Andrews! > certainly induced by an hidden dependency that is installed on my computers > but not on theirs > I don't believe to such hidden dependencies. At the very most it's a bug in package's build system or a matter of rebuilding libraries like for example wxsqlite3 due to a possibly missing symbols.
(In reply to Jani Välimaa from comment #91) > (In reply to Philippe Didier from comment #88) > > a new bug appears for katnatek and Thomas Andrews! > > certainly induced by an hidden dependency that is installed on my computers > > but not on theirs > > > > I don't believe to such hidden dependencies. At the very most it's a bug in > package's build system or a matter of rebuilding libraries like for example > wxsqlite3 due to a possibly missing symbols. One could try to run the app on i586 with some debugging. For example: $ LD_DEBUG=symbols LD_DEBUG_OUTPUT=ld-guayadeque.txt guayadeque To get help with LD_DEBUG one can use: $ LD_DEBUG=help cat
@ katnatek @ Thomas I am still searching what is the hidden dependency installed on my computer that is not on yours Would you please run this in a console : rpm -qa |sort > rpm.list and attach this file so that I can compare with mine : I will try to uninstall some rpms that are on my computers and not on yours to find the culprit
(In reply to Jani Välimaa from comment #91) > (In reply to Philippe Didier from comment #88) > > a new bug appears for katnatek and Thomas Andrews! > > certainly induced by an hidden dependency that is installed on my computers > > but not on theirs > > > > I don't believe to such hidden dependencies. At the very most it's a bug in > package's build system or a matter of rebuilding libraries like for example > wxsqlite3 due to a possibly missing symbols. Sorry there was an air collision I was writing in the same time as you
(In reply to Jani Välimaa from comment #89) > (In reply to Philippe Didier from comment #88) > > (In reply to Jani Välimaa from comment #85) > > > (In reply to Philippe Didier from comment #46) > > > > Hi Jani David (and bugsquad..) > > > > > > > > I have finally submitted what I have done > > > > - to cauldron > > > > - and to Mageia9/core/updates_testing > > > > They have been correctly built for all arches > > > > > > > > You may ask to QA to test this update > > > > (I already tested this and I can say it's OK for 64bits) > > > > > > > > Package in 9/Core/Updates_testing: > > > > ====================== > > > > guayadeque-0.4.8-4.git20231115.1.mga9.rpm > > > > > > > > from SRPM > > > > guayadeque-0.4.8-4.git20231115.1.mga9.srpm > > > > > > > > > > Version and release are quite much messed up. I'd say it should have been > > > 0.4.7-3.git20231115.1 to be somehow consistent between mga9 and cauldron. > > > > > > If there is a guarantee 0.4.8 is ever released one could use it as a > > > version, and 0.gitxxxxyyzz.1 as a release for git snapshots. > > > > Hi Jani > > I'm sorry for the bad numbering but I have increased the rel each time I > > tested a new git clone > > Indeed a 0.4.8 version will certainly be taged as soon as the build upon > > wxgtk-3.2.0 and gstreamer1.22.3 will be OK with the last commits of openmonk > > Please keep local builds and mageia builds separate from each others. IMO we > should remove guayadeque from mga9 core/updates_testing and from cauldron to > be able to resubmit with correct version and release. OK for removing my last submit from Cauldron and Update_testing ... and from svn if it's possible Sorry again !
(In reply to Jani Välimaa from comment #90) > (In reply to Philippe Didier from comment #88) > > > > About 586 version on 32bits computers it's an old problem > > https://bugs.mageia.org/show_bug.cgi?id=29742 > > it appeared when the mageia's macro changed for Mageia8 and didn't exist for > > Mageia7 > > What macro change? I think we have not changed our build nor linker flags. Indeed ? new rpm macros in 2017 Before this there was no problem for i586 systems on i586 hardware
(In reply to Philippe Didier from comment #96) > (In reply to Jani Välimaa from comment #90) > > (In reply to Philippe Didier from comment #88) > > > > > > About 586 version on 32bits computers it's an old problem > > > https://bugs.mageia.org/show_bug.cgi?id=29742 > > > it appeared when the mageia's macro changed for Mageia8 and didn't exist for > > > Mageia7 > > > > What macro change? I think we have not changed our build nor linker flags. > > Indeed ? new rpm macros in 2017 > Before this there was no problem for i586 systems on i586 hardware And guayadeque built directly from source and installed didn't crash https://bugs.mageia.org/show_bug.cgi?id=29742#c21
So we have two different bugs 1) Guayadeque not working on a 32bits hardware : it's an old problem (katnatek is trying to find a solution) 2) - guayadeque no more crashing with fader and equalizer enabled, - building now without any patch needed to build upon upon wxgtk-3.2.0 and gstreamer1.22.3 - OK on my two computers BUT crashing on some other computers with something linked to the use of libwx_gtk3u_wxsqlite3-3.2.so.0
@ Jani Last but not least The 4.7 current version (from Mageia9 core) crashes immediately when launched for Andrew and katnatek But it could be launched by me and crashed only if fader and equalizer were enabled Nevertheless, I could launch it, disable fader and equalizer, and then it worked perfectly I rebuilt it with your patch (to disable fader and equalizer) and it never crashed again !!! (I didn't have to disable manually fader and equalizer) It's an aporia ! I don't know where to dig if not about a missing dependency...
(In reply to Philippe Didier from comment #99) > @ Jani > > Last but not least > The 4.7 current version (from Mageia9 core) crashes immediately when > launched for Andrew and katnatek > > But it could be launched by me and crashed only if fader and equalizer were > enabled When playing a playlist going from the first track to the second track (which started the fader) > Nevertheless, I could launch it, disable fader and equalizer, and then it > worked perfectly > I rebuilt it with your patch (to disable fader and equalizer) and it never > crashed again !!! (I didn't have to disable manually fader and equalizer) > > > It's an aporia ! I don't know where to dig if not about a missing > dependency...
(In reply to Philippe Didier from comment #98) > So we have two different bugs > 1) > Guayadeque not working on a 32bits hardware : it's an old problem (katnatek > is trying to find a solution) > > 2) > - guayadeque no more crashing with fader and equalizer enabled, > - building now without any patch needed to build upon upon wxgtk-3.2.0 and > gstreamer1.22.3 > - OK on my two computers > BUT crashing on some other computers with something linked to the use of > libwx_gtk3u_wxsqlite3-3.2.so.0 I would divide this into a three separate bugs. Here's the status after all the fuss in comments. 1. Bug 32231. Fixed with a new fork, but needs to be resubmit with fixed version and release 2. i586 crash 3. wxsqlite3 in mga9 needs a rebuild due to a undefined symbol. I noticed this before, but can't reproduce anymore.
(In reply to Philippe Didier from comment #99) > The 4.7 current version (from Mageia9 core) crashes immediately when > launched for Andrew and katnatek I have a minor request. My name is not "Andrew." Andrews is my last name. If you want to refer to me, please use "TJ" or "MageiaTJ" (either is preferred), "Thomas" (a bit confusing with others of the same first name, but acceptable), or "Andrews." Being identified by a name that isn't mine gets annoying after a while.
(In reply to Thomas Andrews from comment #102) > (In reply to Philippe Didier from comment #99) > > > The 4.7 current version (from Mageia9 core) crashes immediately when > > launched for Andrew and katnatek > > I have a minor request. > > My name is not "Andrew." Andrews is my last name. If you want to refer to > me, please use "TJ" or "MageiaTJ" (either is preferred), "Thomas" (a bit > confusing with others of the same first name, but acceptable), or "Andrews." > > Being identified by a name that isn't mine gets annoying after a while. Sorry I will take care since now
(In reply to Jani Välimaa from comment #101) > > 1. Bug 32231. Fixed with a new fork, but needs to be resubmit with fixed > version and release May I provide a new spec corrected spec file to svn with mgarepo even if the numbering is lower ? We need a sysadmin to remove my last submits to Cauldron and Mageia9 updates_request > > 2. i586 crash May we use this previous bug for this ? https://bugs.mageia.org/show_bug.cgi?id=29742 > > 3. wxsqlite3 in mga9 needs a rebuild due to a undefined symbol. I noticed > this before, but can't reproduce anymore. What is strange is that I used mock (updated) and then the BS (updated too) to build and test this rpm and got no crash...
(In reply to Philippe Didier from comment #104) > (In reply to Jani Välimaa from comment #101) > > > > > 1. Bug 32231. Fixed with a new fork, but needs to be resubmit with fixed > > version and release > > May I provide a new spec corrected spec file to svn with mgarepo even if the > numbering is lower ? > > We need a sysadmin to remove my last submits to Cauldron and Mageia9 > updates_request sorry typo : updates_testing > > > > 2. i586 crash > May we use this previous bug for this ? > https://bugs.mageia.org/show_bug.cgi?id=29742 > > > > 3. wxsqlite3 in mga9 needs a rebuild due to a undefined symbol. I noticed > > this before, but can't reproduce anymore. > What is strange is that I used mock (updated) and then the BS (updated too) > to build and test this rpm and got no crash...
(In reply to Jani Välimaa from comment #101) > (In reply to Philippe Didier from comment #98) > > 3. wxsqlite3 in mga9 needs a rebuild due to a undefined symbol. I noticed > this before, but can't reproduce anymore. Does it means that before resubmitting guayadeque we have to wait that wxsqlite3 has been rebuilt and uploaded in updates_testing and tested and then pushed to core/updates ?
Created attachment 14165 [details] corrected spec file for Mageia9 and Cauldron with a better version numbering corrected spec file for Mageia9 and Cauldron with a better version numbering @ Jani Is it OK for you ?
Attachment 14157 is obsolete: 0 => 1
(In reply to Marja Van Waes from comment #74) > Advisory with the SRPM from comment 46 added to SVN. Please remove the > "advisory" keyword if it needs to be changed. It also helps when obsolete > advisories are tagged as "obsolete" Removing the "advisory" keyword, as it is obvious that this still needs a great deal of work. Marja, I believe the advisory needs to be deleted altogether in this one. This is also nowhere near ready for QA, especially if it is going to be split up into two or three bugs. I would say it needs to be re-assigned to either Philippe or Jani, or both, but I'm deferring that to others as I have little experience in choosing where a bug should be assigned. As this bug is already over 100 comments long, I'd say it needs to be closed and at least one new one started, but again I have little experience in what that would involve, so I don't think I'm the one to make that call.
@ katnatek @ Thomas Andrews May you verify if lib64wx_gtk3u_wxsqlite3_3.2_0 is installed on your system we have BuildRequires: pkgconfig(wxsqlite3) in the spec file but I am not sure that this implies that lib64wx_gtk3u_wxsqlite3_3.2_0 is considered as a dependence needed by Guayadeque I have it installed by default since I had installed lib64wx_gtk3u_wxsqlite3_3.2-devel and guayadeque works since it needs it But when I launch in a console : rpm -q --whatrequires lib64wx_gtk3u_wxsqlite3_3.2_0 lib64wx_gtk3u_wxsqlite3_3.2-devel-4.9.1-1.mga9 guayadeque doesn't appear as requiring it If lib64wx_gtk3u_wxsqlite3_3.2_0 is not installed on your system, that may explain the immediate crash That means that we must clearly add this dependency in the spec file
wxsqlite3 is pulled automatic via generated deps. $ urpmq --whatrequires lib64wx_gtk3u_wxsqlite3_3.2_0 codelite guayadeque lib64wx_gtk3u_wxsqlite3_3.2_0 lib64wx_gtk3u_wxsqlite3_3.2-devel # urpme lib64wx_gtk3u_wxsqlite3_3.2_0 To satisfy dependencies, the following 2 packages will be removed (10MB): guayadeque-0.4.8-4.git20231115.1.mga10.x86_64 (due to missing libwx_gtk3u_wxsqlite3-3.2.so.0()(64bit)) lib64wx_gtk3u_wxsqlite3_3.2_0-4.9.6-1.mga10.x86_64
(In reply to Thomas Andrews from comment #108) > (In reply to Marja Van Waes from comment #74) > > Advisory with the SRPM from comment 46 added to SVN. Please remove the > > "advisory" keyword if it needs to be changed. It also helps when obsolete > > advisories are tagged as "obsolete" > > Removing the "advisory" keyword, as it is obvious that this still needs a > great deal of work. Marja, I believe the advisory needs to be deleted > altogether in this one. > > This is also nowhere near ready for QA, especially if it is going to be > split up into two or three bugs. I would say it needs to be re-assigned to > either Philippe or Jani, or both, but I'm deferring that to others as I have > little experience in choosing where a bug should be assigned. > > As this bug is already over 100 comments long, I'd say it needs to be closed > and at least one new one started, but again I have little experience in what > that would involve, so I don't think I'm the one to make that call. I would recommend to open a new bug for this and for the others as this bug report is already full of fuss.
(In reply to Philippe Didier from comment #107) > Created attachment 14165 [details] > corrected spec file for Mageia9 and Cauldron with a better version numbering > > > corrected spec file for Mageia9 and Cauldron with a better version numbering > > @ Jani > Is it OK for you ? Please provide SVN diff instead so others can see what's changed.
Created attachment 14166 [details] diff for the corrected spec file
Status comment: advisory in comment 46 => (none)Keywords: advisory => (none)
The advisory in SVN has been deleted
(In reply to Philippe Didier from comment #113) > Created attachment 14166 [details] > diff for the corrected spec file There are also other changes than the version and release fix, but looks valid.
created a new shorter bug : https://bugs.mageia.org/show_bug.cgi?id=32532 with some links to this one
(In reply to Jani Välimaa from comment #115) > (In reply to Philippe Didier from comment #113) > > Created attachment 14166 [details] > > diff for the corrected spec file > > There are also other changes than the version and release fix, but looks > valid. There's no more bundled libs for wxsqlite ;)
for the i586 crashes may we use https://bugs.mageia.org/show_bug.cgi?id=29742 inserting some of the comments from this bug ?
Closing this
Status: NEW => RESOLVEDResolution: (none) => WONTFIX
(In reply to Philippe Didier from comment #118) > for the i586 crashes may we use > https://bugs.mageia.org/show_bug.cgi?id=29742 > > inserting some of the comments from this bug ? Note that, with 45 comments, it already started to be confusing. However, if all comments apart from the comments that really matter are obsoleted, then it is less confusing. An alternative would be to create a new report for that issue, too. (In reply to Philippe Didier from comment #116) > created a new shorter bug : > https://bugs.mageia.org/show_bug.cgi?id=32532 > > with some links to this one Thanks! Closing this one as duplicate of the new one *** This bug has been marked as a duplicate of bug 32532 ***
Resolution: WONTFIX => DUPLICATE
I created 2 other bugs to clarify this mess https://bugs.mageia.org/show_bug.cgi?id=32536 for the 32bits problem https://bugs.mageia.org/show_bug.cgi?id=32535 for a different crash not caused by the fader problem
this bug may now be marked as duplicate of 32535 and 32536
(In reply to Philippe Didier from comment #122) > this bug may now be marked as duplicate of 32535 and 32536 It is already a duplicate of 32532 and can't be a duplicate of more than one bug. But they are in the "See Also:" field now.
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=32535, https://bugs.mageia.org/show_bug.cgi?id=32536
(In reply to Marja Van Waes from comment #123) > (In reply to Philippe Didier from comment #122) > > this bug may now be marked as duplicate of 32535 and 32536 > > It is already a duplicate of 32532 and can't be a duplicate of more than one > bug. But they are in the "See Also:" field now. Thanks a lot
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=32550