On Wed, 1 Feb 2012 11:29:35 +0100 "roman" lists@hasnoname.de 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.