Hi, recently I had to switch from pre-compiled emul-linux-x86 packages to true multilib (as I was missing 32bit tinfo from ncurses) and everything went fine but now 32bit gtk+:1 libs are missing and their deps and there's unfortunately no multilib support in gtk+:1. Is it planned to add it? Thanks
Isn't it dead yet?
It is. There is exactly two users of this in tree and I am considering moving it to the last rite list.
+1, I would try to kill gtk1 reverse dependencies instead of trying to add multilib support to that slot
Looks like there are still third-party programs that are using this, see bug 544876 comment 7.
(In reply to Ulrich Müller from comment #4) > Looks like there are still third-party programs that are using this, see bug > 544876 comment 7. Anybody working on this? Bug #544876 says that the emul-linux has been removed, but without gtk+-1 I cannot run rather old, but paid program Lingea Lexicon. So I cannot uninstall emul-linux.
Given how old this package is, would it make sense to, instead of porting gtk1 to multilib, put/keep an app-emulation/emul-linux-x86-gtk1 in the tree?
(In reply to Ian Stakenvicius from comment #6) > Given how old this package is, would it make sense to, instead of porting > gtk1 to multilib, put/keep an app-emulation/emul-linux-x86-gtk1 in the tree? Please don't, as it would defeat the purpose of the multilib conversion. IMHO the choice here is to support or not to support multilib for x11-libs/gtk+:1, but not to add a new binary package.
(In reply to Ulrich Müller from comment #7) > (In reply to Ian Stakenvicius from comment #6) > > Given how old this package is, would it make sense to, instead of porting > > gtk1 to multilib, put/keep an app-emulation/emul-linux-x86-gtk1 in the tree? > > Please don't, as it would defeat the purpose of the multilib conversion. > > IMHO the choice here is to support or not to support multilib for > x11-libs/gtk+:1, but not to add a new binary package. Understood. gtk:1 needs glib:1 to go along with it. So far both seem to be fairly trivial conversions to autotools-multilib and EAPI5. Initial testing should be finished tomorrow and I'll get the ebuilds revewed by relevant groups before committing.
Created attachment 404554 [details] glib-1.2.10-r6.ebuild (multilib-converted) Here's the version of glib:1 that's been multilib-converted (necessary dep for gtk+:1)
Created attachment 404556 [details] gtk+-1.2.10-r13.ebuild Here's the multilib-converted gtk+:1
Just commit it :). Nobody's going to care enough to review this ancient thing.
Yes, thanks for the work :) Also, maybe it's a good chance to finally fix https://bugs.gentoo.org/show_bug.cgi?id=257996#c9 in old glib-1 :/
Created attachment 404588 [details] gtk+-1.2.10-r13.ebuild (In reply to Michał Górny from comment #11) > Just commit it :). Nobody's going to care enough to review this ancient > thing. Tetromino asked to review it first, and to put the ebuilds on the bug; following his instructions is all. Updating the gtk+ ebuild to contain properly minver-pegged dependencies and other multilib dependencies I forgot to integrate the first time around.
Committed with some fixes (missing a few dependencies, remove .la files, static libs optional in glib and disabled in gtk+, /usr/bin/gtk-config needs wrapping). I really wished we could finally drive a stake into the heart of gtk+-1, but unfortunately, that happy day remains elusive :/ +*glib-1.2.10-r6 (05 Jun 2015) + + 05 Jun 2015; Alexandre Rostovtsev <tetromino@gentoo.org> + +glib-1.2.10-r6.ebuild: + Add multilib support for glib-1 since it seems a few users still need it; + thanks to Ian Stakenvicius for the ebuild (bug #534016). +*gtk+-1.2.10-r13 (05 Jun 2015) + + 05 Jun 2015; Alexandre Rostovtsev <tetromino@gentoo.org> + +gtk+-1.2.10-r13.ebuild: + Add multilib support for gtk+-1 since it seems a few users still need it; + thanks to Ian Stakenvicius for the ebuild (bug #534016).
Thanks, guys. Lingea Lexicon is working fine with in-tree multilib gtk+:1 :-)
