Nov 01 21:34:24 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 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 oh it's compnerd not you, but you get the fallout Nov 01 21:34:54 Yep Nov 01 21:35:08 well he had time to respond Nov 01 21:35:24 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 it's simple, just depends if to go with use deps or stick with old eapi Nov 01 21:36:51 Caster: What would you suggest as the fix? Nov 01 21:37:19 I'd like to stick with the old eapi if possible (did use deps get into EAPI=1?) Nov 01 21:37:20 use deps, unless you want it to stabilize soon :) Nov 01 21:37:29 no, EAPI=2 Nov 01 21:37:37 --- ChanServ gives channel operator status to compnerd Nov 01 21:37:43 Then I'd prefer not to use usedeps Nov 01 21:37:54 ikelos: want a built_with_use added? Nov 01 21:37:54 Quick, nab him! 5;) Nov 01 21:38:03 built_with_use then Nov 01 21:38:57 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 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 vmware ebuilds should then check the flag on libview, not gtkmm Nov 01 21:39:26 Caster: If someone recompiles gtkmm with USE="Accessibility", it's still not going to direct them to rebuild libview? Nov 01 21:39:36 Caster: Ah, you just answered my question... 5;P Nov 01 21:40:01 dunno if the postinst messages improved, but relying on people reading them is not safest :) Nov 01 21:40:11 compnerd: Does that sound like a plan to you? Nov 01 21:40:56 ikelos: having vmware-workstation ebuilds check? Nov 01 21:41:24 compnerd: Having vmware-workstation check libview for USE="accessibility" and having libview check gtkmm for USE="accessibility"? Nov 01 21:42:11 ikelos: not sure I follow ... libview has no such useflag Nov 01 21:42:33 compnerd: it should add that flag, as now it's automagical thing Nov 01 21:42:36 compnerd: No, it'd need one, and the flag would check that it matched gtkmm's flag Nov 01 21:43:11 compnerd: bug 235344 for reference Nov 01 21:43:14 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 compnerd: If that sounds like a good plan to you, I'll make my changes to the vmware ebuilds... Nov 01 21:44:01 ikelos: there is no automagical thing going on Nov 01 21:44:27 ikelos: the issue is that if you build gtkmm[-accessibility], libview, gtkmm[accessibility], you have changed the gtkmm library Nov 01 21:44:33 the change causes a symbol lookup Nov 01 21:44:38 s/$/ error/ Nov 01 21:44:38 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 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 leio-dl: correct Nov 01 21:45:46 the better fix is to simply drop the accessibility useflag from gtkmm Nov 01 21:46:18 not going to happen Nov 01 21:46:22 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 leio-dl: but, doing something like DEPENDS=dev-cpp/gtkmm[accessibility]" will fix it Nov 01 21:46:36 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 compnerd: That, however, wouldn't get stabilized for ages... Nov 01 21:46:56 ikelos: its sitll going to break Nov 01 21:47:04 Caster: user can later recompile gtkmm without the USE flag. I suppose it might cover initial installation issues... Nov 01 21:47:20 leio-dl: well that's general problem of built-with-use Nov 01 21:47:28 can be converted later to use deps when stable Nov 01 21:47:37 but the concept will be there Nov 01 21:47:50 [accessibility=] I suppose? Nov 01 21:47:57 yeah Nov 01 21:48:31 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 leio-dl: though, the idea of gtkmm[-accessibility] is broken ... afaik, gtk without atk is impossible is it not? Nov 01 21:49:46 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 but I see your point, I was claiming things before figuring out it's only for atkmm purposes Nov 01 21:50:57 so having it always on means installation of an extra C++ library, that many don't use Nov 01 21:51:20 so? having gtk+ means an extra C library that many dont use Nov 01 21:51:24 they don't need it unless they are implementing a custom widget in gtkmm and adding it accessibility support Nov 01 21:51:44 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 true Nov 01 21:52:17 * compnerd mumbles something about castrating caster Nov 01 21:52:23 however e Nov 01 21:52:34 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 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 Caster: once you get gentoo moved to git Nov 01 21:55:31 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 leio-dl: meh Nov 01 21:56:49 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 technically a revdep-rebuild should catch it? Nov 01 21:57:55 theoretically Nov 01 21:58:04 feel like trying it out? Nov 01 21:58:30 I think the problem is missing symbol in libview, not gtkmm Nov 01 21:59:01 or I interpret that wrong? Nov 01 21:59:05 ok, let me revise to "a little bit disturbing that libview ABI changes with and without atkmm" Nov 01 21:59:32 /opt/vmware/player/lib/lib/libvmwareui.so.0/libvmwareui.so.0: undefined symbol:_ZThn12_N4view10FieldEntry17delete_text_vfuncEii Nov 01 21:59:33 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 because the problem was a virtual function in libview, probably from a now differently sized object Nov 01 21:59:45 does that say the symbol is missing in libview? Nov 01 22:00:03 or libview is missing a symbol elsewhere? :) Nov 01 22:00:49 aha Nov 01 22:01:02 I guess it could be an ABI break either due to struct size changes or missing function altogether? Nov 01 22:01:16 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 Caster: You've picked out the most common, but it's not always the same symbol missing... Nov 01 22:04:16 heh, now libview won't even emerge because of other bug, weird that the already emerged version works Nov 01 22:08:32 leio-dl: I think its struct size chnages Nov 01 22:08:52 leio-dl: but, I have no real reason at hand as to why it is that Nov 01 22:08:52 libview's or gtkmm's? Nov 01 22:08:56 gtkmm's Nov 01 22:09:15 and not libview (too) if undefined symbol is a libview one? Nov 01 22:10:00 well, libview inherits Gtk::Entry, so tht would change naturally Nov 01 22:19:34 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 anywho, Im off for a while Nov 01 23:22:47 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 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...