Hey, On Sun, January 29, 2012 18:03, E. Liddell wrote: > That means we're not going to get anywhere until Serghei finishes > porting, though, which means several more versions of Trinity (and > likely a couple of years) will go by. Well.. the only other possibility would be to set up a clean overlay, put the existing cmake ebuilds there and fill in the rest like kaffeine etc. and then slowly convert them as serghei or someone else seems fit to do so. But for this we need first some documentation/specification about paths/names etc... i don't think it is a good idea to put trinity into the old /usr/kde/3.5 path we should use sth. like /usr/tde or /opt/tde i am not sure what really is FSFE compliant. Btw. what is the correct location for qt3? Is it really /usr/qt/3? I think i remember qt4 installs to /usr/lib/qt4 That should also be fixed... Just some thoughts... I have setup an empty github repository which i wanted to start fresh and add correct mirrors etc. before commiting anything else. If you want, we could put our efforts into that repo ( https://github.com/strowi/tde ) > The most annoying part is that I'm very, very close to getting this > working > (at least for x86). I got half of kdetoys to work, frex, but the other > half is > getting hit with what I think is an --as-needed breakage in kdelibs. If > we > could rope in even one competent dev . . . Maybe we should post this to the gentoo-desktop list (which i really need to re-subscribe) i think i remember that there was at least one other person that was interested in this (not sure if it was a dev). >> > Say, which arch are you on? >> I'm on amdfam10. > > *Ah.* While my actual machine is also amdfam10, the virtual machine > I've been using to test Trinity is set up as x86, not x86_64. So we may > be seeing a pointer cast that works under 32bit but breaks with 64bit. > (And if I were just a bit better with this, that might be enough to tell > me > how to fix it . . . Grrr.) Probably an arch-dependant error.. i can test this again on x86 this week and then report upstream/open a bug-report. > I think there have been reports of that being a problem on other distros > as well, probably from the Slackware packager. It might be possible to > filter the QT4 directory out of the path before building (it doesn't seem > to install to /lib, thankfully), but it's going to take some work to > figure > out how. After looking into the eclass i found that there is a QTDIR-variable. That one should be responsible for the qt-stuff. I will check that also. greetings, Roman --