On Wed, 1 Feb 2012 11:29:35 +0100 "roman" <lists@...> wrote: > 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. My understanding is that it would go under /usr . . . somewhere. (ref: http://devmanual.gentoo.org/general-concepts/filesystem/index.html ) /usr/kde/3.5 is definitely not right, though--we probably want /usr/tde/[version] or /usr/trinity/[version], for consistency. > 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... QT4 actually spatters files all over the place, including locations like /usr/bin (I ran equery files qt-core while I was trying to find out where the moc was . . .) > 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 ) I'll have a look--I do have cmake ebuilds for kdeartwork and most of kdegraphics, although they need a bit of cleanup for mirror stuff. Another thing that needs to be looked at is package taxonomy--we should consider replacing the kde-base and kde-misc categories with trinity-base and trinity-misc or the like, although I'm not sure exactly how adding whole categories works. I'm also looking at changing the names of the eclasses (kde-functions -> tde-functions or trinity-functions, etc.) > > 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). Yes, there were a few posts a while back that indicated a couple of people were interested (kaffeine was mentioned in particular). I didn't get the impression that they were devs, but they might at least be willing to help test. > >> > 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. Sounds like a plan. > > 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. I found the problem, actually: QT4 installs its moc (and some other stuff, but I think it's the moc that's causing the breakage) to /usr/bin, which is normally going to come very early in the path. Having each ebuild temporarily rearrange the path so that the QT3 dirs come before /usr/bin, and therefore the QT3 moc is used, might fix things. The alternative would be patching the make/cmake files to specify the moc by full path, but that's a lot more complicated (and might break under some circumstances). I wish I knew how kde-sunset deals with this . . . I guess that's another thing to ask on gentoo-desktop.