Conversation from IRC concerning gtkmm/libview/vmware and USE="accessibility"

Freenode-gentoo-dev-libview2.log (text/plain), 9.53 KB, created by Mike Auty (RETIRED) on 2008-11-17 11:07:40 UTC

Nov 01 21:34:24 <Caster>	how bout the bug 235344, some people testing 6.5.0 seem to be affected and then resort to the shipped gtk
Nov 01 21:34:26 <Willikins>	Caster: https://bugs.gentoo.org/235344 "x11-libs/libview-0.6.1 has some automagical dependency on USE=accessibility in dev-cpp/gtkmm which causes undefined symbol: _ZThn12_N4view10FieldEntry17delete_text_vfuncEii in vmware-player"; Gentoo Linux, Ebuilds; NEW; caster@g.o:compnerd@g.o
Nov 01 21:34:50 <Caster>	oh it's compnerd not you, but you get the fallout
Nov 01 21:34:54 <ikelos>	Yep
Nov 01 21:35:08 <Caster>	well he had time to respond
Nov 01 21:35:24 <ikelos>	We offered to pick it up after it got stuck at an old revision, but compnerd came in and fixed it up so we left it in his care...
Nov 01 21:35:28 <Caster>	it's simple, just depends if to go with use deps or stick with old eapi
Nov 01 21:36:51 <ikelos>	Caster: What would you suggest as the fix?
Nov 01 21:37:19 <ikelos>	I'd like to stick with the old eapi if possible (did use deps get into EAPI=1?)
Nov 01 21:37:20 <Caster>	use deps, unless you want it to stabilize soon :)
Nov 01 21:37:29 <Caster>	no, EAPI=2
Nov 01 21:37:37 ---	ChanServ gives channel operator status to compnerd
Nov 01 21:37:43 <ikelos>	Then I'd prefer not to use usedeps
Nov 01 21:37:54 <compnerd>	ikelos: want a built_with_use added?
Nov 01 21:37:54 <ikelos>	Quick, nab him!  5;)
Nov 01 21:38:03 <Caster>	built_with_use then
Nov 01 21:38:57 <Caster>	libview should add accessibility to IUSE and use built_with_use to keep it synced with gtkmm's accessibility flag
Nov 01 21:38:58 <ikelos>	Opfer: Not that I know of.  compnerd: Yes please, although I'm still not sure about the ins and outs of requiring it?
Nov 01 21:39:16 <Caster>	vmware ebuilds should then check the flag on libview, not gtkmm
Nov 01 21:39:26 <ikelos>	Caster: If someone recompiles gtkmm with USE="Accessibility", it's still not going to direct them to rebuild libview?
Nov 01 21:39:36 <ikelos>	Caster: Ah, you just answered my question...  5;P
Nov 01 21:40:01 <Caster>	dunno if the postinst messages improved, but relying on people reading them is not safest :)
Nov 01 21:40:11 <ikelos>	compnerd: Does that sound like a plan to you?
Nov 01 21:40:56 <compnerd>	ikelos: having vmware-workstation ebuilds check?
Nov 01 21:41:24 <ikelos>	compnerd: Having vmware-workstation check libview for USE="accessibility" and having libview check gtkmm for USE="accessibility"?
Nov 01 21:42:11 <compnerd>	ikelos: not sure I follow ... libview has no such useflag
Nov 01 21:42:33 <Caster>	compnerd: it should add that flag, as now it's automagical thing
Nov 01 21:42:36 <ikelos>	compnerd: No, it'd need one, and the flag would check that it matched gtkmm's flag
Nov 01 21:43:11 <ikelos>	compnerd: bug 235344 for reference
Nov 01 21:43:14 <Willikins>	ikelos: https://bugs.gentoo.org/235344 "x11-libs/libview-0.6.1 has some automagical dependency on USE=accessibility in dev-cpp/gtkmm which causes undefined symbol: _ZThn12_N4view10FieldEntry17delete_text_vfuncEii in vmware-player"; Gentoo Linux, Ebuilds; NEW; caster@g.o:compnerd@g.o
Nov 01 21:43:45 <ikelos>	compnerd: If that sounds like a good plan to you, I'll make my changes to the vmware ebuilds...
Nov 01 21:44:01 <compnerd>	ikelos: there is no automagical thing going on
Nov 01 21:44:27 <compnerd>	ikelos: the issue is that if you build gtkmm[-accessibility], libview, gtkmm[accessibility], you have changed the gtkmm library
Nov 01 21:44:33 <compnerd>	the change causes a symbol lookup
Nov 01 21:44:38 <compnerd>	s/$/ error/
Nov 01 21:44:38 <Caster>	compnerd: it has or has not some symbols based on other package's flag, i'd say that's automagical
Nov 01 21:45:09 <leio-dl>	but built_with_use won't be able to do anything about the user changing the USE flags on gtkmm
Nov 01 21:45:21 <compnerd>	leio-dl: correct
Nov 01 21:45:46 <compnerd>	the better fix is to simply drop the accessibility useflag from gtkmm
Nov 01 21:46:18 <leio-dl>	not going to happen
Nov 01 21:46:22 <ikelos>	compnerd: I'm happy with anything that saves user's having to recompile this, then recompile that and then hope that it works...
Nov 01 21:46:25 <compnerd>	leio-dl: but, doing something like DEPENDS=dev-cpp/gtkmm[accessibility]" will fix it
Nov 01 21:46:36 <Caster>	leio-dl: hm right, but vmware will want libview to be built with accessibility, which will want gtkmm be built with accessibility
Nov 01 21:46:42 <ikelos>	compnerd: That, however, wouldn't get stabilized for ages...
Nov 01 21:46:56 <compnerd>	ikelos: its sitll going to break
Nov 01 21:47:04 <leio-dl>	Caster: user can later recompile gtkmm without the USE flag. I suppose it might cover initial installation issues...
Nov 01 21:47:20 <Caster>	leio-dl: well that's general problem of built-with-use
Nov 01 21:47:28 <Caster>	can be converted later to use deps when stable
Nov 01 21:47:37 <Caster>	but the concept will be there
Nov 01 21:47:50 <leio-dl>	[accessibility=] I suppose?
Nov 01 21:47:57 <compnerd>	yeah
Nov 01 21:48:31 <leio-dl>	you could have one revision adding the built_with_use, and another higher one using USE deps, so ~arch users will already loose the pain while the older revision goes stable at some point
Nov 01 21:48:53 <compnerd>	leio-dl: though, the idea of gtkmm[-accessibility] is broken ... afaik, gtk without atk is impossible is it not?
Nov 01 21:49:46 <leio-dl>	compnerd: that's correct. But if you don't use the atk C++ API, but only gtkmm API, you don't need it
Nov 01 21:50:07 <leio-dl>	but I see your point, I was claiming things before figuring out it's only for atkmm purposes
Nov 01 21:50:57 <leio-dl>	so having it always on means installation of an extra C++ library, that many don't use
Nov 01 21:51:20 <compnerd>	so?  having gtk+ means an extra C library that many dont use
Nov 01 21:51:24 <leio-dl>	they don't need it unless they are implementing a custom widget in gtkmm and adding it accessibility support
Nov 01 21:51:44 <leio-dl>	typically they are simply using existing gtk+ classes, and the C atk will take care of the accessibility - no atkmm needed
Nov 01 21:51:57 *	Caster mumbles something about qt's superiorness
Nov 01 21:51:59 <compnerd>	true
Nov 01 21:52:17 *	compnerd mumbles something about castrating caster
Nov 01 21:52:23 <leio-dl>	however e
Nov 01 21:52:34 <leio-dl>	however the ABI difference between atkmm and no atkmm is disturbing
Nov 01 21:52:43 *	compnerd hands some e to leio-dl 
Nov 01 21:54:16 <compnerd>	leio-dl: agreed on the ABI difference, which goes back to my point of, Id prefer just dropping that useflag that shouldnt have been added in th efirst place
Nov 01 21:55:10 <compnerd>	Caster: once you get gentoo moved to git
Nov 01 21:55:31 <leio-dl>	compnerd: should you be retired for until such a thing happens or what?
Nov 01 21:55:34 *	Opfer hands it over from his pocket
Nov 01 21:56:19 <compnerd>	leio-dl: meh
Nov 01 21:56:49 <ikelos>	leio-dl: So, should we change the libview bug to being a non-stable ABI bug on gtkmm?  It sounds like you're warming to the idea of removing the accessibility flag?
Nov 01 21:57:34 <leio-dl>	technically a revdep-rebuild should catch it?
Nov 01 21:57:55 <compnerd>	theoretically
Nov 01 21:58:04 <compnerd>	feel like trying it out?
Nov 01 21:58:30 <Caster>	I think the problem is missing symbol in libview, not gtkmm
Nov 01 21:59:01 <Caster>	or I interpret that wrong?
Nov 01 21:59:05 <leio-dl>	ok, let me revise to "a little bit disturbing that libview ABI changes with and without atkmm"
Nov 01 21:59:32 <Caster>	/opt/vmware/player/lib/lib/libvmwareui.so.0/libvmwareui.so.0: undefined symbol:_ZThn12_N4view10FieldEntry17delete_text_vfuncEii
Nov 01 21:59:33 <ikelos>	It might be worse than that, remember vmware likes to mix and match binary libraries it has with system libraries.  Half of the problem...  5:\
Nov 01 21:59:34 <leio-dl>	because the problem was a virtual function in libview, probably from a now differently sized object
Nov 01 21:59:45 <Caster>	does that say the symbol is missing in libview?
Nov 01 22:00:03 <Caster>	or libview is missing a symbol elsewhere? :)
Nov 01 22:00:49 <Caster>	aha
Nov 01 22:01:02 <leio-dl>	I guess it could be an ABI break either due to struct size changes or missing function altogether?
Nov 01 22:01:16 <ikelos>	Caster: The problem is, there's several missing symbols, some are fixed by gtkmm itself, and others by libview (hence we only recommend gtkmm, since that initially solved most of the problems)
Nov 01 22:01:36 <ikelos>	Caster: You've picked out the most common, but it's not always the same symbol missing...
Nov 01 22:04:16 <Caster>	heh, now libview won't even emerge because of other bug, weird that the already emerged version works
Nov 01 22:08:32 <compnerd>	leio-dl: I think its struct size chnages
Nov 01 22:08:52 <compnerd>	leio-dl: but, I have no real reason at hand as to why it is that
Nov 01 22:08:52 <leio-dl>	libview's or gtkmm's?
Nov 01 22:08:56 <compnerd>	gtkmm's
Nov 01 22:09:15 <leio-dl>	and not libview (too) if undefined symbol is a libview one?
Nov 01 22:10:00 <compnerd>	well, libview inherits Gtk::Entry, so tht would change naturally
Nov 01 22:19:34 <leio-dl>	compnerd: ok, personally I'd first get to putting new versions in portage before checking into the details as it might be already better in the new versions
Nov 01 22:22:10 <compnerd>	anywho, Im off for a while
Nov 01 23:22:47 <Caster>	compnerd, ikelos: hey why not just make libview depend on accessibility in gtkmm unconditionally without introducing new flag there? since only rdeps of libview is vmware which expects it there...
Nov 02 00:02:12 <ikelos>	Caster: Seems a little specific.  So far we don't know of any projects requiring it, but the ABI stability issue may hit others so that's ideally what could do with pinning down...