On Thu, 26 Jan 2012 23:13:54 +0100 "roman" lists@hasnoname.de wrote:

...

Hi everyone,

i am currently trying to compile kaffeine-3.5.13 on Funtoo/Gentoo. kdebase-startkde and the kaffeine-deps should already be installed fine.

Running "autoconf && automake && configure --prefix=/usr/kde/3.5 && PATH="/usr/kde/3.5/bin:$PATH" make" results in the following error. Can someone with more in-depth knowledge of autotools/kaffeine help me fix this?

configure.in:56: the top level cd ../../../.. && /bin/sh ./config.status kaffeine/src/player-parts/kaffeine-part/Makefile depfiles config.status: creating kaffeine/src/player-parts/kaffeine-part/Makefile config.status: executing depfiles commands make[5]: Leaving directory `/tmp/applications/kaffeine/kaffeine/src/player-parts/kaffeine-part' make[5]: Entering directory `/tmp/applications/kaffeine/kaffeine/src/player-parts/kaffeine-part' if /bin/sh ../../../../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../../../.. -I/usr/kde/3.5/include -I/usr/qt/3/include -I. -include tqt.h -DQT_THREAD_SUPPORT -D_REENTRANT -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -O2 -g -O2 -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -I/usr/include/tqt -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -MT kaffeinepart.lo -MD -MP -MF ".deps/kaffeinepart.Tpo" \ -c -o kaffeinepart.lo `test -f 'kaffeinepart.cpp' || echo './'`kaffeinepart.cpp; \ then mv -f ".deps/kaffeinepart.Tpo" ".deps/kaffeinepart.Plo"; \ else rm -f ".deps/kaffeinepart.Tpo"; exit 1; \ fi ../../../../libtool: line 451: CDPATH: command not found ../../../../libtool: line 1129: func_opt_split: command not found libtool: Version mismatch error. This is libtool 2.2.6b Debian-2.2.6b-2ubuntu1, but the libtool: definition of this LT_INIT comes from an older release. libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6b Debian-2.2.6b-2ubuntu1 libtool: and run autoconf again. make[5]: *** [kaffeinepart.lo] Fehler 1 make[5]: Leaving directory `/tmp/applications/kaffeine/kaffeine/src/player-parts/kaffeine-part' make[4]: *** [all-recursive] Fehler 1 make[4]: Leaving directory `/tmp/applications/kaffeine/kaffeine/src/player-parts' make[3]: *** [all-recursive] Fehler 1 make[3]: Leaving directory `/tmp/applications/kaffeine/kaffeine/src' make[2]: *** [all-recursive] Fehler 1 make[2]: Leaving directory `/tmp/applications/kaffeine/kaffeine' make[1]: *** [all-recursive] Fehler 1 make[1]: Leaving directory `/tmp/applications/kaffeine' make: *** [all] Fehler 2

Well, the bottom part about the libtool version mismatch looks similar to what I got hit by while trying to write ebuilds for the parts of Trinity that still use autotools. This was back in November, so I'm probably forgetting bits, but I *think* it needed [e]autoreconf to be run to get past that particular error. Unfortunately, the files necessary to run autoreconf (specifically, configure.in) weren't in the Trinity-supplied packages I was trying to use, and the old versions I swiped from kde-sunset didn't work properly, possibly because they didn't know about TQT. I never did manage to get anything working.

If anyone has some actual solution to the problem, I'd like to hear it too.

From the TDE How to Build Wiki page at http://www.trinitydesktop.org/wiki/bin/view/Developers/HowToBuild

Regenerate Autoconf/Automake files

cd to the desired module to build, then run: cp -Rp <path to your system's libtool.m4 file> admin/libtool.m4.in cp -Rp <path to your system's ltmain.sh file> admin/ltmain.sh make -f admin/Makefile.common

Tim

On Fri, 27 Jan 2012 11:53:46 +0100 "roman" lists@hasnoname.de wrote:

Hi,

On Fri, January 27, 2012 04:40, Timothy Pearson wrote:

...

...

On Thu, 26 Jan 2012 23:13:54 +0100 "roman" lists@hasnoname.de wrote:

...

From the TDE How to Build Wiki page at http://www.trinitydesktop.org/wiki/bin/view/Developers/HowToBuild

...

Regenerate Autoconf/Automake files

cd to the desired module to build, then run: cp -Rp <path to your system's libtool.m4 file> admin/libtool.m4.in cp -Rp <path to your system's ltmain.sh file> admin/ltmain.sh make -f admin/Makefile.common

That fixed things for me too, after a little fun-and-games with working out the proper paths for everything and finding the actual make command buried in ~1000 lines of someone else's old shell script. I still have a nasty suspicion that the resultant ebuilds might fail if used for some types of cross-compiling, but since it's all going to go away when the CMake port is finished, I'm not going to lose sleep over it.

Thx for the reply, that gives me the following error.

strowi@Sleipnir:~/tmp/applications/kaffeine> cp /usr/share/aclocal/libtool.m4 admin/libtool.m4.in strowi@Sleipnir:~/tmp/applications/kaffeine> cp /usr/share/libtool/config/ltmain.sh admin/ltmain.sh strowi@Sleipnir:~/tmp/applications/kaffeine> make -f admin/Makefile.common Useless use of /d modifier in transliteration operator at /usr/bin/automake-1.7 line 5985. *** automake (GNU automake) 1.7.9 found. *** Creating acinclude.m4 *** Creating list of subdirectories *** Creating Makefile.am *** Creating configure.files *** Creating configure.in *** Creating aclocal.m4 aclocal: macro `_LT_DECL_SED' required but not defined aclocal: macro `_LT_FUNC_STRIPNAME_CNF' required but not defined make: *** [cvs] Fehler 1

On a hint using "WANT_AUTOMAKE=1.11 make -f admin/Makefile.common" seems to finish, but gives the following error during make:

kxinewidget.cpp: In member function ‘bool KXineWidget::getAutoplayPluginURLS(const QString&, QStringList&)’: kxinewidget.cpp:2641:66: error: invalid conversion from ‘const char* const*’ to ‘char**’ [-fpermissive] kxinewidget.cpp: At global scope: kxinewidget.cpp:3490:49: warning: type qualifiers ignored on function return type [-Wignored-qualifiers] make[5]: *** [kxinewidget.lo] Fehler 1 make[5]: *** Warte auf noch nicht beendete Prozesse... mv -f .deps/xineconfig.Tpo .deps/xineconfig.Plo mv -f .deps/postfilter.Tpo .deps/postfilter.Plo mv -f .deps/xine_part.Tpo .deps/xine_part.Plo make[5]: Leaving directory `/home/strowi/tmp/applications/kaffeine/kaffeine/src/player-parts/xine-part' make[4]: *** [all-recursive] Fehler 1 make[4]: Leaving directory `/home/strowi/tmp/applications/kaffeine/kaffeine/src/player-parts' make[3]: *** [all-recursive] Fehler 1 make[3]: Leaving directory `/home/strowi/tmp/applications/kaffeine/kaffeine/src' make[2]: *** [all-recursive] Fehler 1 make[2]: Leaving directory `/home/strowi/tmp/applications/kaffeine/kaffeine' make[1]: *** [all-recursive] Fehler 1 make[1]: Leaving directory `/home/strowi/tmp/applications/kaffeine' make: *** [all] Fehler 2

Roman, I just succeeded in installing kaffeine-3.5.13 to my Gentoo/Trinity test VM with no errors (most optional functionality was switched off, though, to reduce the size of the dependency downloads). The ebuild is a dreadful kludge, but it appears to work. Would you like me to send you a copy?

On Sat, 28 Jan 2012 02:36:34 +0100 "roman" lists@hasnoname.de wrote:

Hey,

On Fri, January 27, 2012 23:25, E. Liddell wrote:

...

Roman, I just succeeded in installing kaffeine-3.5.13 to my Gentoo/Trinity test VM with no errors (most optional functionality was switched off, though, to reduce the size of the dependency downloads). The ebuild is a dreadful kludge, but it appears to work. Would you like me to send you a copy?

Mhh i tried the one from kde-sunset which failed. Then i tried to compile from source manually which also fails. Yes, please send me a copy so i can figure out where i made my mistake;)

None of the kde-sunset ebuilds work for Trinity unchanged--the tarballs don't have quite the same structure, which screws up the eclasses.

Anyway, hopefully all the attachments will come through--there should be one ebuild and two supporting eclasses which are similar but not identical to the corresponding eclasses from kde-sunset. Keep in mind that I've only compiled this with all use flags off in a test environment that has only had Trinity installed to it, and never any version of KDE. Hopefully it'll work for you.

On Sun, 29 Jan 2012 13:48:12 +0100 "roman" lists@hasnoname.de wrote:

Hi,

On Sat, January 28, 2012 03:39, E. Liddell wrote:

...

None of the kde-sunset ebuilds work for Trinity unchanged--the tarballs don't have quite the same structure, which screws up the eclasses.

Anyway, hopefully all the attachments will come through--there should be one ebuild and two supporting eclasses which are similar but not identical to the corresponding eclasses from kde-sunset. Keep in mind that I've only compiled this with all use flags off in a test environment that has only had Trinity installed to it, and never any version of KDE. Hopefully it'll work for you.

Thx for the ebuild/eclass, but sadly it didn't work for me. I know the kde-sunset ebuilds quite well (and that they do not work). I have updated some of those myself. But with the chanke to trinity/cmake i am still a little lost. I have taken the ebuilds provided by serghei and started editing/updating them for the 3.5.13 release version. I currently do have a gtk-desktop without any qt/kde installed. I guess i will have to recheck the other ebuilds for kdelibs/startkde again for errors.

::muttermumblecurse:: Did the ebuild fail in the same way as the direct build, or was it a different failure? I'd like to figure out what's going on and get the thing working reliably if it's within my ability to do so, although working with this stuff often makes me feel like I'm banging my head against a wall.

We need some sort of organized effort to package Trinity for Gentoo--it seems like 4-5 people have intermittently tried to do bits and pieces, with no real coordination beyond copying Serghei's initial ebuilds, and likely some duplication of effort.

On Sunday 29 January 2012 15:40:16 roman wrote:

You are right about the organized effort. The eclasses alone seem to be quite messy.. The ebuild also came down to the following error which seems to be an code-error?

kxinewidget.cpp:2641:66: error: invalid conversion from ‘const char* const*’ to ‘char**’ [-fpermissive]

could be a compiler issue, more likely. current gcc seems to be more picky with type conversions than older one which was used when kxinewidget.cpp was written...

werner

On Sun, January 29, 2012 16:38, E. Liddell wrote:

...

You are right about the organized effort.

Yeah. Problem is that no one seems to want the job of organizer (including me!).

Well.. i don't want it because i don't really have enough knowledge about c/c++,cmake,automake etc.. to be competent enough. Also the mix from automake/cmake seems to be the biggest to not remove/rewrite the eclasses from ground up. Maybe we should start with a clean cmake-only overlay to get things streamlined? It might take some time to get everything in there, but seems to be the only clean solution.

The eclasses seem to be accretions that go back all the way to the dawn of KDE3--I mean, I found a comment in there that was about 3.2. Probably some of the code is cruft that could be thrown out, but I'm not knowledgeable enough to be able to tell which bits are junk and which are still useful.

Yes, they have only been fixed to work with newer kde-versions.

...

The ebuild also came down to the following error which seems to be an code-error?

kxinewidget.cpp:2641:66: error: invalid conversion from ‘const char* const*’ to ‘char**’ [-fpermissive]

Looks like a code error to me, too . . . Pointer casting like this is one of the reasons I hate C/C++--in a sane language, that would never have compiled to begin with, and the original coder would have had to fix it.

Say, which arch are you on?

I'm on amdfam10.

BTW it also seems that there are problems detecting the correct qt-path when qt4 is installed (just tried installing sopcast, to watch the handball-em final, it's not being broadcasted in germany;( ).

greetings, Roman

On Sunday 29 January 2012 19:03:09 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.

Unfortunately, I cannot continue porting until a tqt3 ebuild will be created. Someone working on it?

On Sunday 29 January 2012 19:32:06 E. Liddell wrote:

On Sun, 29 Jan 2012 19:01:27 +0200

Serghei Amelian serghei@thel.ro wrote:

...

On Sunday 29 January 2012 19:03:09 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.

Unfortunately, I cannot continue porting until a tqt3 ebuild will be created. Someone working on it?

Is that a blocker for 3.5.13, though, or just for R14/git? I thought tqtinterface was supposed to be sufficient for building 3.5.13.

As commiter, I'm working always on latest version, so for R14.

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.

On Wed, 1 Feb 2012 16:16:14 +0100 "roman" lists@hasnoname.de wrote:

Hi,

On Wed, February 1, 2012 14:14, 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.

Mhh i already gave a lecture on linux filesystem-layouts but i have no idea what would be the better solution fsfe-wise. Personally i tend to /usr/tde/[version].

The dev manual indicates that the Gentoo dev team considers the filesystem standard as more of a guideline than an absolute, but since we both think /usr/tde/[version] is good we might as well go with that.

...

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

Mhh my guess is we need to put qt3 in a seperate directory (or should be keep it in /usr/qt/3 ?) otherwise there will be tons of complications.

With the next version, we should be able to go to /usr/tqt, but moving to there with 3.5.13 might be a bit premature.

...

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.

Not much in there yet, just the thirdpartymirrors and an empty documentation folder.

Okay, so the first step is to get tde-base, its dependancies, and the eclasses (I think cmake only uses -functions and maybe qt3) in there. Then ebuilds for the other stuff that's already been moved to cmake. After that, we can look at the rest.

...

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

Definitly! I would go with tde-* it's less typing.;)

I'm a bit worried about it being too similar to kde-, though. Doesn't matter for the eclasses or directories, but for stuff end-users are going to have to type on a regular basis, I'd like to be as distinct as possible.

But i wouldn't want to change stuff like "konqueror" to "tonqueror" *g.

No, "tonqueror" would just be silly. :) We can probably use the same filtration mechanism as kde-sunset and remove the various incarnations of KDE from the path in the startup script. Otherwise, we should do exactly as much renaming as the Trinity project itself, and no more.

...

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.

Yes, i think there is at least a cmake-option or variable in the eclass that specifies the moc-location or the kde-prefix to use.

I'm more worried about the non-cmake packages in that regard, but they're screwed up anyway. Since no one on the trinity-dev list seems interested in helping me sort out the linker problem that seems to exist in half the packages, I may need to go to gentoo-dev for help, which is something I'm not looking forward to. :(

On Wed, February 1, 2012 16:58, Serghei Amelian wrote:

On Wednesday 01 February 2012 17:57:12 E. Liddell wrote:

...

I'm more worried about the non-cmake packages in that regard, but they're screwed up anyway. Since no one on the trinity-dev list seems interested in helping me sort out the linker problem that seems to exist in half the packages, I may need to go to gentoo-dev for help, which is something I'm not looking forward to. :(

Hehe, if you will create a tqt3 ebuild, I promise that I will port everything you need to cmake :)

Hehe, yes devs can be.. complicated (including myself).;) What exactly do you mean by tqt3? the tqtinterface or qt-3.3.8d?

greetings, Roman

Hi,

On Thu, February 2, 2012 10:44, Serghei Amelian wrote:

As I understood, tqt3 is a version of qt3 maintaned by trinity community.

PS I started cmake port for kaffeine, if I will have some spare time, tonigh should be done.

The only things qt-related i found on the trinity pages were tqtinterface and the (now maintained by trinity)-qt-3.3.8d sources.

Can you take a look at this? I created an ebuild for those sources (removing almost all patches, since some don't apply anymore, some are unneeded now).

https://github.com/strowi/tde/blob/develop/x11-libs/qt-meta/qt-meta-3.3.8d.e...

greetings, Roman

Hey,

On Wed, February 1, 2012 16:57, E. Liddell wrote:

The dev manual indicates that the Gentoo dev team considers the filesystem standard as more of a guideline than an absolute, but since we both think /usr/tde/[version] is good we might as well go with that.

Ok, /usr/tde it is then.

...

Mhh my guess is we need to put qt3 in a seperate directory (or should be keep it in /usr/qt/3 ?) otherwise there will be tons of complications.

With the next version, we should be able to go to /usr/tqt, but moving to there with 3.5.13 might be a bit premature.

I agree, lets stick with the default place. I do have an ebuild for qt-3.3.8d and removed all patches that I didn't need to get it working. For some i couldn't find the bug-id since it was long gone on bugs.gentoo.org or didn't apply against the latest version.

Okay, so the first step is to get tde-base, its dependancies, and the eclasses (I think cmake only uses -functions and maybe qt3) in there. Then ebuilds for the other stuff that's already been moved to cmake. After that, we can look at the rest.

Yes, i am currently trying to get the dependencies in-line so they can be used by anyone. Hal is still required right? In kde-*.eclass i think it might be wise to comment/remove all functions und reenable the ones that are still needed for the remaining non-cmake ebuilds on a as-needed basis.

...

...

how adding whole categories works. I'm also looking at changing the names of the eclasses (kde-functions -> tde-functions or trinity-functions, etc.)

Definitly! I would go with tde-* it's less typing.;)

I'm a bit worried about it being too similar to kde-, though. Doesn't matter for the eclasses or directories, but for stuff end-users are going to have to type on a regular basis, I'd like to be as distinct as possible.

Adding new categories is easy, just create the folder-structure and portage will complain that you need to add your own categories into profiles/categories.;) About it being too similar... unless we change the actual ebuild-name (like kdebase-startkde -> tdebase-starttde) they have to emerge it via 'emerge trinity-base/kdebase-startkde' since the package exists in another category as well). So how far do you wanna go with the renaming?

...

Yes, i think there is at least a cmake-option or variable in the eclass that specifies the moc-location or the kde-prefix to use.

I'm more worried about the non-cmake packages in that regard, but they're screwed up anyway. Since no one on the trinity-dev list seems interested in helping me sort out the linker problem that seems to exist in half the packages, I may need to go to gentoo-dev for help, which is something I'm not looking forward to. :(

Ok, but lets try to get the cmake-parts in there first and worry about that later. Maybe then we have a tqt3 and just have to ask Serghei.;)

PS: I hope i will have the cleaned eclasses and dependencies in git until Saturday since i am currently quite busy with work etc.. but i want to get this finally working on gentoo/funtoo and will have to take my time. BTW i am not really running gentoo but funtoo, so i might ask there for some additional help. It's easier to ask for some help there since even D.Robbins is idling there sometimes. And who else knows portage better?;)

greetings, roman

On Thursday 02 February 2012 16:01:36 E. Liddell wrote:

[...]

...

Ok, but lets try to get the cmake-parts in there first and worry about that later. Maybe then we have a tqt3 and just have to ask Serghei.;)

Serghei is more intent on attacking the R14 source in git than the current release, though. Not that there's anything wrong with that (and live ebuilds might be a nice-to-have), but it isn't what I had in mind as a first step.

Yes, because I need to commit changes to git repo. But I think cmake files can be used with 3.5.13 too.

On Fri, 3 Feb 2012 00:19:14 +0100 "roman" lists@hasnoname.de wrote:

Hey,

On Thu, February 2, 2012 15:01, E. Liddell wrote:

...

I believe I used the ebuild for 3.3.8d from Serghei's overlay while setting up my test machine. Basically, his kdebase ebuilds are functional, they just have to have filename changed to 3.5.13-only and SRC_URI changed to pull from the Trinity mirrors.

qt-meta-3,3,8d should already be in the repository

That's a step forward. I was looking at dbus-tqt and tqtinterface earlier today. I need to change the qt-3.3.8d dep to qt-meta-3.3.8d, but after that I should be able to test and upload. That should be everything we need to get started on kdebase.

...

HAL is optional for everything except . . . was it knetworkmanager?

Ok, i thought it was still needed for automounting with konqueror or sth. like that.

Automounting is itself optional, though--I don't use it.

...

Something I don't have installed, anyway. ksmserver can optionally use it, but doesn't have to. We need something like:

src_configure() { mycmakeargs=( -DCMAKE_INSTALL_RPATH=/usr/tde/3.5/lib -DBUILD_KSMSERVER=ON `cmake-utils_use_with hal HAL`

in the ksmserver ebuild and this appended to profiles/use.desc:

As far as i know we need just to add the inlcudes from hal? Could you take a look at that as i am not really familar with that..

The above code is approximately what I used while installing my Trinity tester (just the path is different). If the hal use flag is on, it asks for HAL and compiles it in, or should (I don't think I ever actually took it as far as fetching/installing HAL, I just tested to make sure the dependency was working). If not, it doesn't ask and compiles anyway. Basically it's the same setup as KDE3 had before HAL was deprecated. I had intended to add some messages ("you are compiling this package without HAL support, and therefore automounting may not work"/"you are compiling this package with HAL support--please be aware that HAL is unmaintained and bugs caused by it will be ignored"), but never quite got that far.

It's probably best to have the flag on by default, now that I think about it. The people who want to avoid HAL are more likely to read the fine print than those who just want automounting to work.

...

I have the last hal ebuild from the main tree floating around here somewhere, if we want to include it in the overlay.

I already uploaded the latest hal/hal-info to the repo since it was gone from the tree i had put it in kde-sunset also. I think for now we can keep it around if we can get knetworkmanager working...

I don't think there's any harm in having the ebuild available--people can choose whether or not they want to install it.

...

...

In kde-*.eclass i think it might be wise to comment/remove all functions und reenable the ones that are still needed for the remaining non-cmake ebuilds on a as-needed basis.

Mmph. I think most of them are used--those eclasses provide their own pkg_config, src_configure, etc. that replace the standard ones. The cmake ebuilds only use -functions and qt3, anyway--the other two will be going away once we have no more autotools, so it isn't worth spending more time on them than we absolutely have to.

I did strip some stuff out of qt3.eclass earlier today that had been marked as deprecated--I think we can safely say that anything having to do with pre-slot versioning is obsolete. There may be a few other functions like that around.

Ok, then we just need to revisit the naming scheme;) What would be the best way here? Or did we agree already on this:

• renaming only the categories -> users have to "emerge

trinity-base/kdebase-startkde"

• Changing the prefix to /usr/tde/3.5/

nothing more!

I think that's probably the best way to go for this release.

...

...

...

type on a regular basis, I'd like to be as distinct as possible.

Adding new categories is easy, just create the folder-structure and portage will complain that you need to add your own categories into profiles/categories.;)

Ah. We should probably have a metadata.xml too.

Uhm... whats that for again?

It's mostly just a description of the category. We can probably steal the one for kde-base and do a search-and-replace on "KDE".

...

...

So how far do you wanna go with the renaming?

For this iteration not very far, because it messes with $P and its relatives-- only the category should change. For R14, follow the parent project, which would give us, frex, tdelibs and twin, but not tonqueror.

Ah ok, so scratch the above then;) tde-base or trinity-base then?

I like trinity-base, for reasons previously given.

...

Serghei is more intent on attacking the R14 source in git than the current release, though. Not that there's anything wrong with that (and live ebuilds might be a nice-to-have), but it isn't what I had in mind as a first step.

Yes, we can lower the priority on that i guess.. and start replacing automake in R14.

That was my thought.

...

I'll probably have a couple of hours to put into this between now and then. If I can get a github account actually set up (last attempt failed because I didn't realize I was blocking their cookies), I'll see about uploading what I have for kdebase/kdeartwork/kdegraphics and their deps once I've cleaned and sorted everything. (At the moment, I'm using a really messy local overlay that mixes Serghei's stuff, kde-sunset, and my own work, but I obviously can't upload that.)

Hehe, if you can't get github working i can also setup a repo on my own server..

I'm pretty sure it's my weird browser setup--the account exists, as I found out when I tried to recreate it, but my login attempts don't register. I'll try tomorrow with a different Firefox profile, and/or Chromium and/or the command-line git client. If none of those work, then we can worry.

For the basic kdebase-startkde i guess i do have probably most of the ebuilds working. But i still do have 2 errors during runtime:

1. Only the first click on the K-Menu gives me a "Malformed URL"-Error.

I haven't seen that one (I did have a hellish time when I first installed because environment variables weren't being set, but I eventually figured that out).

2. via ALT+F2 Launcher i can run firefox, thunar, evince, gimp (i guess

all X11-progs), but cant seem to get a simple urxvt or other console-tool running. Anyone know what this error could be?

No clue.

...

I have had an offer of assistance in sorting out the linker problem, but the person involved is, I believe, with a different distro. Still, we'll see what we can do.

Very good! I don't know how much distro-differences are in the linker-part.;)

None in the software itself as far as I know, but the default options chosen can be very different.

On Sat, 4 Feb 2012 22:22:42 +0100 "roman" lists@hasnoname.de wrote:

Hi,

On Fri, February 3, 2012 02:17, E. Liddell wrote:

...

...

qt-meta-3,3,8d should already be in the repository

That's a step forward. I was looking at dbus-tqt and tqtinterface earlier today. I need to change the qt-3.3.8d dep to qt-meta-3.3.8d, but after that I should be able to test and upload. That should be everything we need to get started on kdebase.

Well, qt-meta, tqtinterface and dbus-tqt should be working fine from the github-repo.

So long as they work, I don't think it matters who puts 'em there.

I ran into some other problem though with one or two other ebuilds not finding "tqglobals.h" or similar. Those tqt-header files are located in /usr/include/tqt and not /ust/qt/3/include. So the path needs to be added to the configure options but i am not sure what the best way is to do that... But currently this is only for trinity-misc/kshutdown ( just ran sed over the files, which seems very silly to me, there has to be a better way).

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.

...

Automounting is itself optional, though--I don't use it.

I always liked the automount feature;)

And so do many other people. It just doesn't suit my control-freak nature. ;)

...

The above code is approximately what I used while installing my Trinity tester (just the path is different). If the hal use flag is on, it asks for HAL and compiles it in, or should (I don't think I ever actually took it as far as fetching/installing HAL, I just tested to make sure the dependency was working). If not, it doesn't ask and compiles anyway. Basically it's the same setup as KDE3 had before HAL was deprecated. I had intended to add some messages ("you are compiling this package without HAL support, and therefore automounting may not work"/"you are compiling this package with HAL support--please be aware that HAL is unmaintained and bugs caused by it will be ignored"), but never quite got that far.

It's probably best to have the flag on by default, now that I think about it. The people who want to avoid HAL are more likely to read the fine print than those who just want automounting to work.

Yes i think it's a good idea to include hal, but we should look out for blockers (there were some i think from pciutils if i remember correct)

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.

...

I did strip some stuff out of qt3.eclass earlier today that had been marked as deprecated--I think we can safely say that anything having to do with pre-slot versioning is obsolete. There may be a few other functions like that around.

After looking closer at the eclasses... uhhmmm lets keep them around until they have absolutely no use. Diving in there might be hard and not get us very far...

Trust me, if both the function of the code and its lack of usefulness for modern Portage hadn't been clearly evident, I wouldn't have touched it. (Anyway, I'm pretty sure that any Trinity build calling those bits would have failed, since it didn't know about qt-3.3.8d)

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.

...

...

• renaming only the categories -> users have to "emerge

trinity-base/kdebase-startkde"

• Changing the prefix to /usr/tde/3.5/

nothing more!

I think that's probably the best way to go for this release.

Ok, if you can take a look at the repository i think the stuff in there should be working for x86/amd64. There is also a Documentation/TODO with packages i haven't gotten around to or couldn't get working yet like kdeartwork or kde-i18n..

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.

...

...

...

Ah. We should probably have a metadata.xml too.

Uhm... whats that for again?

It's mostly just a description of the category. We can probably steal the one for kde-base and do a search-and-replace on "KDE".

That should do it.

We'll even get a Vietnamese translation as a bonus. 8)

...

...

Hehe, if you can't get github working i can also setup a repo on my own server..

I'm pretty sure it's my weird browser setup--the account exists, as I found out when I tried to recreate it, but my login attempts don't register. I'll try tomorrow with a different Firefox profile, and/or Chromium and/or the command-line git client. If none of those work, then we can worry.

To be able to push into the repo i need to give you access and you need to upload your pubkey to github if i remember correct...

I was felled by a migraine yesterday and so am behind on doing anything about this. Will try to sort things tomorrow if I can stay sitting up for long enough.

...

...

Very good! I don't know how much distro-differences are in the linker-part.;)

None in the software itself as far as I know, but the default options chosen can be very different.

Oh linker.. i had fun with that getting kshutdown working it always complains about unknown option "--sort-common". Can't help you there much though.

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.

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.

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)

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

On Mon, 6 Feb 2012 17:15:04 +0100 "roman" lists@hasnoname.de wrote:

Hi,

there is at least one other thing we need to fix. It's about the patches. As you can see here: http://git.trinitydesktop.org/cgit/tde-packaging/tree/arch/3.5.13/trinity-ba... there are already some patches for packages like kdebase which is used by multiple ebuilds (e.g. kcontrol, kicker). Now how should we include those? Twice for each package or create a patches.tar.gz and reuse/fix the eclass function that handles this? I am not quite sure how/if that code in the eclass works...

The traditional method would be to place each ebuild's patches in its files directory and put them in the ebuild's PATCHES variable--patching should only take place in the eclasses if the patch needs to be applied to all Trinity ebuilds (or all autotools Trinity ebuilds).

In the case of what you've linked here, we can unpack the .bz2 and examine each patch individually. The only patch that might apply to more than one ebuild is the doc_locations patch, and it is, as far as I can tell, a mere cosmetic directory name change--we can ignore it without hurting anything until it's actually merged into the cmake stuff.

We can't use the dbusfix patch at all, because we are not installing to /opt/trinity, nor should we. The other patches can each be assigned to a single ebuild: two to kcontrol, one to kicker, one to nsplugins, and the last to (I think) kdesktop. They go to the appropriate files/ directories.

I have no idea what the Xsession patch outside the .bz2 actually does or whether we need it--would someone care to enlighten me?

On Sat, 4 Feb 2012 22:22:42 +0100 "roman" lists@hasnoname.de wrote:

...

...

Hehe, if you can't get github working i can also setup a repo on my own server..

I'm pretty sure it's my weird browser setup--the account exists, as I found out when I tried to recreate it, but my login attempts don't register. I'll try tomorrow with a different Firefox profile, and/or Chromium and/or the command-line git client. If none of those work, then we can worry.

To be able to push into the repo i need to give you access and you need to upload your pubkey to github if i remember correct...

I've sorted this out and uploaded a public key--is there anything further I need to do for you to give me push access?

Aklternatively you can create your own repo and open a pull request.

On Thu, February 9, 2012 19:11, roman wrote:

Hi,

i think i just need to add your username to the collaborators. What is your nick on github?

On Thu, February 9, 2012 19:01, E. Liddell wrote:

...

On Sat, 4 Feb 2012 22:22:42 +0100 "roman" lists@hasnoname.de wrote:

...

...

...

Hehe, if you can't get github working i can also setup a repo on my

own

...

...

server..

I'm pretty sure it's my weird browser setup--the account exists, as I found out when I tried to recreate it, but my login attempts don't register. I'll try tomorrow with a different Firefox profile, and/or Chromium

and/or

...

the command-line git client. If none of those work, then we can

worry. To be able to push into the repo i need to give you access and you need to upload your pubkey to github if i remember correct...

I've sorted this out and uploaded a public key--is there anything further I need to do for you to give me push access?

---

To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting

On Thu, 9 Feb 2012 19:11:24 +0100 "roman" lists@hasnoname.de wrote:

Hi,

i think i just need to add your username to the collaborators. What is your nick on github?

eliddell (I'm pretty predictable)

On Fri, 10 Feb 2012 14:45:44 +0100 Roman lists@hasnoname.de wrote:

Hey,

Am 09.02.2012 21:13, schrieb E. Liddell:

...

On Thu, 9 Feb 2012 19:11:24 +0100 "roman"lists@hasnoname.de wrote:

...

Hi,

i think i just need to add your username to the collaborators. What is your nick on github?

eliddell (I'm pretty predictable)

Ok, i have hadded you to the collaborators list. I think you should be able to push to the repository. Please push only to the develop-branch as i would like to keep the master a 'working' copy.

Assuming that I didn't mess anything up, you should have the kdeartwork files now.

On Sat, 11 Feb 2012 10:57:15 +0100 "roman" lists@hasnoname.de wrote:

Hi,

On Fri, February 10, 2012 19:17, E. Liddell wrote:

...

...

...

eliddell (I'm pretty predictable)

Ok, i have hadded you to the collaborators list. I think you should be able to push to the repository. Please push only to the develop-branch as i would like to keep the master a 'working' copy.

Assuming that I didn't mess anything up, you should have the kdeartwork files now.

I am sorry to say .. I don't see anything new... did you pull, add, commit, push ?

Damn, I see what happened now--I entered the push command then switched to another desktop, and didn't notice I'd gotten "Permission denied (publickey)". Why, I'm not quite sure--all other tests indicate I've set up the key correctly. I'll have to troubleshoot more extensively, and likely generate another key.

On Sunday 12 February 2012 14:26:09 Roman wrote:

Hi,

Am 11.02.2012 14:53, schrieb E. Liddell:

...

Damn, I see what happened now--I entered the push command then switched to another desktop, and didn't notice I'd gotten "Permission denied (publickey)". Why, I'm not quite sure--all other tests indicate I've set up the key correctly. I'll have to troubleshoot more extensively, and likely generate another key.

Ok. I haven't gotten around to do much this week... currently trying to find out why amarok keeps failing all of a sudden. i miss my music-collection the db is stored in mysql..;\

Hehe, I did not use sql backends, for this reason I ommitted this kind of support. I will implement it.

PS I want to create live ebuilds, I think would be good idea to include they in your git repo.

greetings, Roman

On Sun, 12 Feb 2012 14:34:36 +0100 Roman lists@hasnoname.de wrote:

Hey,

Am 12.02.2012 13:29, schrieb Serghei Amelian:

...

PS I want to create live ebuilds, I think would be good idea to include they in your git repo.

Yes, we can do that definitly. Although i have no idea how live-ebuilds with git work...

There's at least one in the main tree (media-libs/x264-9999) that we can use as a starting point.

I have been working on converting/extending the 3.5.13-ebuilds, but seem to be having some trouble with the ones using autotool like kde-l10n. Can't really figure out where the difference ist with those..

Currently i am still missing these 3.5.13: kde-l10n/ kcachegrind/ kcalc/ kcfgcreator/ knotes/ kode/ korn/ quanta/ umbrello/

I think I built kcalc successfully with autotools while I was flipping through the first few kdeutils apps--it isn't affected by the linker bug.

My current immediate TODO: -sort out github and finally upload what I have in terms of working ebuilds -look at the linker bug again -post to gentoo-desktop and the forums asking for help both with the linker bug and with general packaging/testing--there are a couple of hundred ebuilds here and I think we could use some extra hands

On Sun, 12 Feb 2012 13:26:09 +0100 Roman lists@hasnoname.de wrote:

Hi,

Am 11.02.2012 14:53, schrieb E. Liddell:

...

Damn, I see what happened now--I entered the push command then switched to another desktop, and didn't notice I'd gotten "Permission denied (publickey)". Why, I'm not quite sure--all other tests indicate I've set up the key correctly. I'll have to troubleshoot more extensively, and likely generate another key.

Ok.

I think it made it this time--the problem seems to have been the permissions on ~/.ssh, but of course the bloody thing couldn't just *tell* me that . . . ::grump, growl::

On Thursday 26 January 2012 10:41:33 pm E. Liddell wrote:

On Thu, 26 Jan 2012 23:13:54 +0100

"roman" lists@hasnoname.de wrote:

...

Hi everyone,

i am currently trying to compile kaffeine-3.5.13 on Funtoo/Gentoo. kdebase-startkde and the kaffeine-deps should already be installed fine.

Running "autoconf && automake && configure --prefix=/usr/kde/3.5 && PATH="/usr/kde/3.5/bin:$PATH" make" results in the following error. Can someone with more in-depth knowledge of autotools/kaffeine help me fix this?

configure.in:56: the top level cd ../../../.. && /bin/sh ./config.status kaffeine/src/player-parts/kaffeine-part/Makefile depfiles config.status: creating kaffeine/src/player-parts/kaffeine-part/Makefile config.status: executing depfiles commands make[5]: Leaving directory `/tmp/applications/kaffeine/kaffeine/src/player-parts/kaffeine-part' make[5]: Entering directory `/tmp/applications/kaffeine/kaffeine/src/player-parts/kaffeine-part' if /bin/sh ../../../../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../../../.. -I/usr/kde/3.5/include -I/usr/qt/3/include -I. -include tqt.h -DQT_THREAD_SUPPORT -D_REENTRANT -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -O2 -g -O2 -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -I/usr/include/tqt -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -MT kaffeinepart.lo -MD -MP -MF ".deps/kaffeinepart.Tpo" \ -c -o kaffeinepart.lo `test -f 'kaffeinepart.cpp' || echo './'`kaffeinepart.cpp; \ then mv -f ".deps/kaffeinepart.Tpo" ".deps/kaffeinepart.Plo"; \ else rm -f ".deps/kaffeinepart.Tpo"; exit 1; \ fi ../../../../libtool: line 451: CDPATH: command not found ../../../../libtool: line 1129: func_opt_split: command not found libtool: Version mismatch error. This is libtool 2.2.6b Debian-2.2.6b-2ubuntu1, but the libtool: definition of this LT_INIT comes from an older release. libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6b Debian-2.2.6b-2ubuntu1 libtool: and run autoconf again. make[5]: *** [kaffeinepart.lo] Fehler 1 make[5]: Leaving directory `/tmp/applications/kaffeine/kaffeine/src/player-parts/kaffeine-part' make[4]: *** [all-recursive] Fehler 1 make[4]: Leaving directory `/tmp/applications/kaffeine/kaffeine/src/player-parts' make[3]: *** [all-recursive] Fehler 1 make[3]: Leaving directory `/tmp/applications/kaffeine/kaffeine/src' make[2]: *** [all-recursive] Fehler 1 make[2]: Leaving directory `/tmp/applications/kaffeine/kaffeine' make[1]: *** [all-recursive] Fehler 1 make[1]: Leaving directory `/tmp/applications/kaffeine' make: *** [all] Fehler 2

Well, the bottom part about the libtool version mismatch looks similar to what I got hit by while trying to write ebuilds for the parts of Trinity that still use autotools. This was back in November, so I'm probably forgetting bits, but I *think* it needed [e]autoreconf to be run to get past that particular error. Unfortunately, the files necessary to run autoreconf (specifically, configure.in) weren't in the Trinity-supplied packages I was trying to use, and the old versions I swiped from kde-sunset didn't work properly, possibly because they didn't know about TQT. I never did manage to get anything working.

If anyone has some actual solution to the problem, I'd like to hear it too.

---

To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting

Have you tried this?

cp -f "/usr/share/aclocal/libtool.m4" "admin/libtool.m4.in" cp -f "/usr/share/libtool/config/ltmain.sh" "admin/ltmain.sh" make -f "Makefile.cvs" ./configure prefix=/usr \ --sysconfdir=/etc \ --libdir=/usr/lib \ --mandir=/usr/share/man \ --docdir=/usr/share/doc/kde \ --disable-dependency-tracking \ --enable-closure \ --disable-rpath

On Thu, February 2, 2012 22:25, Serghei Amelian wrote:

Hello,

As I promise, I ported kaffeine build system to cmake.

There are complete sources: http://thel.ro/distfiles/kaffeine-0.8.8.tar.bz2

Also, I attached ebuild file.

Thank you very much Serghei! It seems to work! At least up until i run into the same make-error as with automake:

/tmp/kaffeine/kaffeine/src/player-parts/xine-part/kxinewidget.cpp:2641:66: Fehler: ungültige Umwandlung von »const char* const*« in »char**« [-fpermissive] [ 69%] Generating subeditor.moc

Guess that needs to be fixed in the source until i can watch tv again...

greetings, Roman

Hi,

On Fri, February 3, 2012 08:37, Serghei Amelian wrote:

Which version of xine-lib are you using? I have xine-lib-1.1.20 and kaffeine compiling without any problem.

Thank you very much for that hint. Downgrading xine-lib worked. Haven't tested the dvb-t functions yet, but video seems to work just fine.;)

greetings, roman