On Sun, 5 Feb 2012 22:24:54 +0100 "roman" lists@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)
exportkde_widgetdir="$KDEDIR/$(get_libdir)/kde3/plugins/designer"
exportkde_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.