Message: previous - next
Month: February 2012

Re: [trinity-users] kaffeine-3.5.13 compilation error

From: "E. Liddell" <ejlddll@...>
Date: Wed, 1 Feb 2012 08:14:45 -0500
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: )
/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 (
> )

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,

> > 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

> >> > 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