On Sun, 5 Feb 2012 22:24:54 +0100
"roman" <lists(a)hasnoname.de> wrote:
Hi,
On Sun, February 5, 2012 00:59, E. Liddell wrote:
The default options for every merge will be in
the eclasses, I think. For
single builds, the cmake-utils eclass has a couple of ways of passing
options
back to emake, and probably to configure as well.
Yes, they use the
myconf-variable, but as that stuff was written in the
src i had no idea howto else regenerate those (still need to read up on
autoconf/-reconf autotools etc..).
Would be nice if /usr/include/tqt could be included in the eclass, don't
really know where though. Maybe i will test this with kshutdown later..
There's always the universal patch approach--if you check through
the old -meta eclass, they actually patched all the makefiles through it.
And so do many
other people. It just doesn't suit my control-freak
nature. ;)
I'm currently using thunar which does this fine via
console/policykit/upower... but as soon as konqueror is useable again i
would like to have it automount again.
I do wonder . . . There was a patch posted to the Trinity dev-list a while
back that supposedly re-enabled other automounter backends (pre-HAL)
in KDE3. Tim rejected it on the grounds that he didn't want to replace
only parts of HAL piecemeal, but that doesn't mean it wouldn't be
a usable stopgap measure.
I think they
were removed after HAL left the main tree. Anyway, the
worst known consequence of having both installed at once was that
device icons showed up twice in some applications, IIRC--an annoyance,
but not exactly a showstopping bug.
Thats right. Currently i am having a hard time
deciding/finding out which
bugs are caused by wrong ebuilds and which are upstream.. i guess i will
have to get a complete working set before going bughunting... but
sometimes it is quite annoying... like the kaffeine/xine stuff.
Yeah, that was kind of frustrating. At least it turned out to be a real
bug rather than a stupid mistake by one of us, though.
I did patch the following though to get rid of the
kde3-dir
(also some 'designer-plugins' weren't found)
- export
kde_widgetdir="$KDEDIR/$(get_libdir)/kde3/plugins/designer"
+ export
kde_widgetdir="$KDEDIR/$(get_libdir)/trinity/plugins/designer"
Interesting. I wonder if that would fix the widget style ebuilds in
x11-themes, too.
I was able to install the x11-themes/polyester after that (and
patching
the same into polyester).
Good--I use x11-themes/tiblit on my main desktop, and do not
want to give it up if I can avoid it, buggy though it is sometimes.
I have all of
kdeartwork working (well enough for me to install it,
anyway) except kdeartwork-kworldclock, which
is dependent on one of the kdetoys applications that won't yet build.
Also all of kdegraphics except kdvi, kghostview, and kooka.
Nice! I would love got
get those added as soon as possible.
If I don't get the git thing figured out over the next couple of days,
I'll stuff them into a zip file and email them to you.
We'll even
get a Vietnamese translation as a bonus. 8)
I would like to get trinity in german
first.;)
Well, the metadata.xml has English, German, Spanish, Japanese,
Portugese, Italian, Polish and Dutch (I think "nl" is the code for
Dutch) as well as Vietnamese. I wonder why no French . . . ?
We're
starting to get things sorted out, thankfully. Just have to figure
out
where the rest of the stray symbols are and amend the ebuilds (or the
eclasses?)
to force both libraries into the linker.
Good to hear.. as i already said i found
the tqt-headers in
/usr/include/tqt if that helps.
The problem right now is that I can't get Portage to pass the appropriate
flags to the linker. I'm doing what appears to be the correct thing
according to the documentation and examples I've found,
(append-libs -lkdecore -lqt-mt) but the flags never reach their intended
destination, and I am stumped as to why. We may need to pass this to
someone more experienced to get the last bit done.
PS: kontact is next on my todo does it really
hard-depend on knotes now?
Could it be a plugin thing? There's a note about
them in the old KDE3
ebuild.
Not sure.. will try to check on that. Also there might be some helpful
patches to be found in tde-packaging fixing post-release bugs..
Again, it can't hurt to look.