media-sound/gigedit-1.1.1-r1 builds fine however, gigedit fails to start : ---------- acoswt@Tux ~ $ gigedit Initializing 3rd party services needed by gigedit. (gigedit:4770): Gtk-ERROR **: 13:40:27.246: GTK+ 2.x symbols detected. Using GTK+ 2.x and GTK+ 3 in the same process is not supported ---------- Which is somehow understandable considering : ---------- acoswt@Tux ~ $ ldd /usr/bin/gigedit|grep gtk libgtk-3.so.0 => /usr/lib64/libgtk-3.so.0 (0x00007ffff75d5000) libgtkmm-2.4.so.1 => /usr/lib64/libgtkmm-2.4.so.1 (0x00007ffff6ce7000) libgtk-x11-2.0.so.0 => /usr/lib64/libgtk-x11-2.0.so.0 (0x00007ffff67c9000) ---------- The dependency on gtkmm:2 (CDEPEND="dev-cpp/gtkmm:2.4...) appears to be the culprit there. As a matter of fact, replacing it in favour of a dependency on gtkmm:3 ( CDEPEND="dev-cpp/gtkmm:3.0...) solved the problem for me : ---------- acoswt@Tux ~ $ ldd /usr/bin/gigedit|grep gtk libgtkmm-3.0.so.1 => /usr/lib64/libgtkmm-3.0.so.1 (0x00007ffff73c8000) libgtk-3.so.0 => /usr/lib64/libgtk-3.so.0 (0x00007ffff6a8d000) ---------- This fixed, gigedit-1.1.1-r1 builds and runs fine (for me). I did not test the 9999 version however, looking at the ebuild, the same fix should logically apply.
The fix mentioned here-above actually enables gigedit to start and run fine... run fine... well!... as far as user keeps on basic operations. As soon as user tries to tune dimensions, gigedit starts firing GTK-CRITICAL ** error messages instead of displaying what would be expected. Therefore, blindly switching to gtkmm:3 (as I had suggested) does not appear to be an acceptable option. BTW, keeping gtkmm:2 is not either since, as package's Makefile tells : - GTK_CFLAGS = -I/usr/include/gtk-3.0... - GTK_LIBS = -lgtk-3... which, normally will mix GTK+3 symbols with the GTL+2 symbols of gtkmm:2 Time to switch to .sfz ?
Just asking : Is it a common practice to fire and stabilize packages without any respect for open bugs ? To who would care (I no longer) : The problem hereabove reported against 1.1.1-r1 is easily reproduceable with last 1.2 Of course, if you get gtkmm:3 already installed on your system, you might not notice because gigedit will automagically depend on it. Steps to reproduce : A/ Ensure gtkmm:3 is installed on your system (or have it installed emerging gigedit-1.1.1-r1 with the fix suggested hereabove) B/ Emerge gigedit-1.2 and test : It works (As badly as usual I mean) C/ Unmerge gtkmm:3 (or depclean it since gigedit ebuilds do not explicitely make it DEPEND) D/ Rebuild gigedit (or emerge @preserved-rebuild) and test : gigedit fails to start due to mixed GTK+2 and GTK+3 symbols.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=99277a325dbc4cb4d58c42e2dc6544e6d6875e76 commit 99277a325dbc4cb4d58c42e2dc6544e6d6875e76 Author: Miroslav Šulc <fordfrog@gentoo.org> AuthorDate: 2021-06-14 07:02:23 +0000 Commit: Miroslav Šulc <fordfrog@gentoo.org> CommitDate: 2021-06-14 07:02:41 +0000 media-sound/gigedit: fixed dependency on gtkmm Closes: https://bugs.gentoo.org/753203 Package-Manager: Portage-3.0.19, Repoman-3.0.3 Signed-off-by: Miroslav Šulc <fordfrog@gentoo.org> media-sound/gigedit/{gigedit-1.2.0.ebuild => gigedit-1.2.0-r1.ebuild} | 2 +- media-sound/gigedit/gigedit-9999.ebuild | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
