1 Feb
2012
1 Feb
'12
1:14 p.m.
On Wed, 1 Feb 2012 11:29:35 +0100
"roman" <lists(a)hasnoname.de> wrote:
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.
*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 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.
Hey,
On Sun, January 29, 2012 18:03, E. Liddell wrote:
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.
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...
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). Say, which
arch are you on?
I'm on amdfam10. 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.