Hi, On Fri, January 27, 2012 04:40, Timothy Pearson wrote: 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 --

Hey, On Fri, January 27, 2012 23:25, E. Liddell wrote: 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;) greetings, Roman --

Hi, On Sat, January 28, 2012 03:39, E. Liddell wrote: 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. On a side-note, can anyone tell me how the *.moc-files are being generated by automake? kaffeine seems to be missing at least one of those during compilation. greetings, Roman --

Hey, On Sun, January 29, 2012 15:16, E. Liddell 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] --

On Sun, 29 Jan 2012 15:40:16 +0100 "roman" <lists(a)hasnoname.de> wrote: Yeah. Problem is that no one seems to want the job of organizer (including me!). 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. 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?

On Sun, 29 Jan 2012 16:45:28 +0100 "roman" <lists(a)hasnoname.de> 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. I'm not good with C/C++ or their build systems either--I'm a Java/Perl/PHP programmer by inclination. 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 . . . *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.) 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.

On Sun, 29 Jan 2012 19:01:27 +0200 Serghei Amelian <serghei(a)thel.ro> wrote: 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.

Hey, On Sun, January 29, 2012 18:03, E. Liddell wrote: 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... 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 ) 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). Probably an arch-dependant error.. i can test this again on x86 this week and then report upstream/open a bug-report. 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. greetings, Roman --

Hi, On Wed, February 1, 2012 14:14, E. Liddell wrote: 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]. 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. Not much in there yet, just the thirdpartymirrors and an empty documentation folder. Definitly! I would go with tde-* it's less typing.;) But i wouldn't want to change stuff like "konqueror" to "tonqueror" *g. I hope i can start going over the whole thing this evening or on friday/weekend. It's on my TODO for the weekend. I always keep a stage4 somewhere;) 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. But currently i seem to be having another little problem with the tdesktop not wanting to run commands via ALT+F2. Will have to revisit this later when the groundworks are there. greetings, Roman --

On Wednesday 01 February 2012 17:57:12 E. Liddell wrote: Hehe, if you will create a tqt3 ebuild, I promise that I will port everything you need to cmake :) -- Serghei

On Thursday 02 February 2012 11:33:55 roman 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. -- Serghei

On Thursday 02 February 2012 12:03:54 roman wrote: [...] I will try it this weekend, because I'm using trinity on my workstation and I'm not ready to broke it right now :) -- Serghei

On Thu, 2 Feb 2012 10:52:39 +0100 "roman" <lists(a)hasnoname.de> 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. HAL is optional for everything except . . . was it knetworkmanager? Something I don't have installed, anyway. ksmserver can optionally use it, but doesn't have to. We need something like: RDEPEND="trinity-base/kdelibs:${SLOT} dev-libs/dbus-tqt hal? ( sys-apps/hal )" DEPEND="${RDEPEND}" S=${WORKDIR}/kdebase src_configure() { mycmakeargs=( -DCMAKE_INSTALL_RPATH=/usr/tde/3.5/lib -DBUILD_KSMSERVER=ON `cmake-utils_use_with hal HAL` ) cmake-utils_src_configure } in the ksmserver ebuild and this appended to profiles/use.desc: #added for Trinity 3.5.13 as a stopgap measure hal - Activates functionality depending on HAL, the obsolete Hardware Abstraction Layer I have the last hal ebuild from the main tree floating around here somewhere, if we want to include it in the overlay. 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. Ah. We should probably have a metadata.xml too. 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. 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. 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.) True--and from what little I know of him, he seems like a nice guy. The Gentoo devs are more of a mixed bag, from what I've seen--some nice, others really abrasive. 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.

Hey, On Thu, February 2, 2012 15:01, E. Liddell wrote: qt-meta-3,3,8d should already be in the repository Ok, i thought it was still needed for automounting with konqueror or sth. like that. 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.. 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... 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! Uhm... whats that for again? Ah ok, so scratch the above then;) tde-base or trinity-base then? Yes, we can lower the priority on that i guess.. and start replacing automake in R14. Hehe, if you can't get github working i can also setup a repo on my own server.. 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. 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? Yep, he and the others in #funtoo are always very helpful and fun. Very good! I don't know how much distro-differences are in the linker-part.;) good night, Roman

Hi, On Fri, February 3, 2012 02:17, E. Liddell wrote: Well, qt-meta, tqtinterface and dbus-tqt should be working fine from the github-repo. 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). I always liked the automount feature;) 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) 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... 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" 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.. That should do it. 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... Fixed! I was missing the kdebase-kioslaves. Also fixed, though i don't really know why it wasn't working before... firefox and urxvt were in the same PATH and only firefox worked... anyway i changed the startkde-script and now it seems working fine. 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. PS: kontact is next on my todo does it really hard-depend on knotes now? greetings, Roman --

Hi, On Sun, February 5, 2012 00:59, E. Liddell wrote: Yep, exactly. As long as they work it doesn't matter. 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.. 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. 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. I was able to install the x11-themes/polyester after that (and patching the same into polyester). Nice! I would love got get those added as soon as possible. I would like to get trinity in german first.;) No problem, i know migranes well enough.;( Good to hear.. as i already said i found the tqt-headers in /usr/include/tqt if that helps. 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.. greetings, Roman --

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-b… 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... greetings, Roman -- --

The linker problem has been isolated but not fixed: the libs that need to be linked in are libkdecore and libqt-mt, but I cannot for the life of me get the ebuild to actually add them to the linker line. I've tried every variation I can think of on append-libs, append-ldflags, and even just setting LDFLAGS. Nothing works. Any ideas?

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

Aklternatively you can create your own repo and open a pull request. On Thu, February 9, 2012 19:11, roman wrote: -- --

Hey, Am 09.02.2012 21:13, schrieb E. Liddell: 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. greetings Roman -- "Nuclear war would really set back cable." - Ted Turner

Hi, On Fri, February 10, 2012 19:17, E. Liddell wrote: I am sorry to say .. I don't see anything new... did you pull, add, commit, push ? --

Hi, Am 11.02.2012 14:53, schrieb E. Liddell: 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..;\ greetings, Roman -- "Nuclear war would really set back cable." - Ted Turner

Hey, Am 12.02.2012 13:29, schrieb Serghei Amelian: Very nice! I already tried looking into converting autotools to cmake but failed... If we're talking about amarok... is it possible that there is a bug with the dynamic playlists? They don't seem to add anything to the current playlist. Yes, we can do that definitly. Although i have no idea how live-ebuilds with git work... 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/ greetings, Roman -- "Nuclear war would really set back cable." - Ted Turner

On Sunday 12 February 2012 15:34:36 Roman wrote: [...] I did already few live ebuilds, check the attachment. -- Serghei.

Hi, On Sun, February 12, 2012 18:55, E. Liddell wrote: Yes, it came through this time. Haven't had the time to look at it though... Currently busy preparing for lpic. greetings, Roman --

On Friday 03 February 2012 00:44:44 roman wrote: [...] Which version of xine-lib are you using? I have xine-lib-1.1.20 and kaffeine compiling without any problem. -- Serghei

On Sat, 4 Feb 2012 22:00:33 +0100 "roman" <lists(a)hasnoname.de> wrote: Ah-*ha*. I was compiling against 1.1.19, I think--whatever was stable for x86 in the main tree when I last bothered sync'ing the VM in November, anyway. [R]DEPEND will need to reflect the version restriction.