> Yes, I know there are no official packages for Gentoo > yet. I decided to see > if I could do something useful by installing what > unofficial ones were available > and probing for bugs, and possibly rolling a few ebuilds of > my own for the > packages that haven't gotten any love yet. I used non7top's > GitHub fork of > Serghei's ebuild repository (at the time I started, the > contents of the two were > identical, actually) and did manage to get kdebase > installed after two ebuild- > related hiccups. > > After that, things started to get complicated, and I ran > into a variety of > problems. Unfortunately, I haven't been able to > decide whether some of > them are Trinity bugs, ebuild bugs, or just Gentoo quirks, > so I don't know > where to file them and need help with the triage. > > __________________ > > Problem #1: Unset environment variables > > When I first booted Trinity, the desktop *appeared* to come > up exactly as > it should, but most applications would not start, the main > menu was nearly > empty, and kcontrol had no settings available. After > some mucking around, > I discovered that there was no mention of the Trinity bin > directory in my > PATH, and then found that Gentoo set PATH, ROOTPATH, > LDPATH, and > XDG_DATA_DIRS inside a distro-specific part of starkde (for > KDE 3.5.10, > that is), so I copy-and-pasted those into the startup file > provided. (I know > there are some setters in the Trinity startup script. > They didn't work, > possibly because of Problem #4.) > > Unfortunately, that didn't fix things--I also needed to set > LD_LIBRARY_PATH > for programs (including konsole) to start properly, and > XDG_DATA_HOME, > XDG_CONFIG_HOME, and/or XDG_CONFIG_DIRS (I never tried > setting > them individually, so I can't narrow it down) to get a > working menu and kcontrol. > > I don't know what changed between KDE 3.5.10 and Trinity > 3.5.13 to make > the setting of those additional environment variables > necessary, so I'm not > sure who owns the second half of the bug. > > __________________ > > Problem #2: Autotools packages and ebuilds > > I did manage to write some successful ebuilds (I have most > of kdegraphics and > kdeartwork working, if anyone wants ebuilds for those, plus > kdebase-meta and a > variant ksmserver ebuild with a hal useflag), but only for > packages that have been > ported to CMake. The autotools packages Will Not > Work, no matter how I mangle > the KDE 3.5.10 ebuilds (rewriting from scratch is not an > option, IMAO--the old > kde-meta eclass contains several hundred lines of bash > script, and spending more > than minimal time on a build system that's going away is > wasted effort). > > After a lot of playing around with kdetoys, I was able to > figure out that I was > running into two problems: a minor change in the tarball > structure (not a bug, solved > by a 1-line fix), and a set of missing build/config > files. The kdetoys-3.5.10 tarball > contains a bunch of files at the top level that are missing > from its 3.5.13 equivalent: > configure.in, acinclude.m4, aclocal.m4, and several other > config* and Makefile* > files. When I copied these files from the old to the > new package, the ebuild got > as far as actually configuring/building the package (and, > naturally, failed, because > the old buildscripts didn't know about TQT, but it was the > first iteration that didn't > bail out while trying to find the build directory or run > eautoreconf/aclocal). > > I know next to nothing about autotools, so I don't know if > those files were > removed for a reason. Maybe someone who knows more > about autotools > and ebuilds could do something without them; I just know > that *I* can't. > > Another thing is that I couldn't seem to get the > --without-arts switch to work, > but with the ebuilds so messed up to begin with it's > difficult to tell whether > that's meaningful. > > __________________ > > Problem #3: CMake failures > > Ebuilds for two subapplications of kdeutils that were > included in the stuff I took from > GitHub failed to build, complaining that they weren't able > to find tqt.h (one of them would > have been Ark). I don't know whether this is an > ebuild or a CMake bug. > > __________________ > > Problem #4: startkde/starttrinity and minimal or unusual > builds > > While I was wrestling with Problem #1 above, I had occasion > to examine both > the new and the old startup scripts in detail, and there > were some things in the > new one that drew my attention. However, I'm not sure they > really qualify as bugs: > > > if [ -d /opt/trinity/games ]; then > > That, and the lines that follow it, might work fine if > Trinity is installed into > /opt/trinity/, but Gentoo's practice is to install most > software into /usr/. > Something like: > > if [ -d ${KDEDIR}/games ]; then > > might be more portable. > > > # Make sure a default wallpaper is set. > if [ ! -e $kdehome/share/config/kdesktoprc ]; then > # With Trinity this file should exist, but test first. > if [ -r /usr/share/wallpapers/isadora.png.desktop ]; > then > cat >$kdehome/share/config/kdesktoprc <<EOF > [Desktop0] > Wallpaper=isadora.png > WallpaperMode=Scaled > EOF > fi > fi > > Not having a wallpaper set is harmless--these lines seem to > add complexity to > the script for no good reason (and I don't have a > /usr/share/wallpapers, either-- > isadora.png is in /usr/kde/3.5/share/wallpapers--so this > code isn't portable). > Perhaps it belongs in a distro-specific patch? > > > # Configuration of the gtk_qt_engine if not already set. > [...] > > Trinity will run quite happily without gtk-qt-engine > installed, so a test needs > to be made for that (at minimum--I'd relegate this to > "distro-specific" too). > > > # Remove moodin cache if we have a new wallpaper installed, > jriddell. Distro-specific. > if [ -d $kdehome/share/apps/ksplash/cache/Moodin/kubuntu ]; > then > if [ /usr/share/wallpapers/kubuntu-wallpaper.png -nt > $kdehome/share/apps/ksplash/cache/Moodin/kubuntu/ ]; then > rm -rf > $kdehome/share/apps/ksplash/cache/Moodin/kubuntu/ > fi > fi > > This says right out that it's a Kubuntu patch. It > doesn't belong in vanilla Trinity. > > > $KDEDIR/bin/artsshell -q terminate > > Arts is another optional component that Trinity can operate > without, so it shouldn't > be shut down without testing to see if it's there. Maybe: > > if test -e $KDEDIR/bin/artsshell ; then artsshell -q > terminate ; fi > > > (The prelinking stuff isn't in my old startup script > either, but I suspect that Gentoo may > have removed it.) > > __________________ > > > I think that's everything. The other (minor) bugs I > ran into I'm fairly sure I know where > to file. Welcome! A couple of things that might help. The startkde script provided in 3.5.13 needs love and attention. I uploaded a revised script in bug report 675: http://bugs.pearsoncomputing.net/show_bug.cgi?id=675 You'll find a patch diff and a full script in the attachments. Please test! Please patch! One note: Bear in mind there are many distros to support and the script needs to be flexible for everybody. Don't arbitrarily rip snippets from the script but instead add error checking and tests when to run a snippet in the script. The code upon which TDE was born was not the vanilla code directly from the upstream KDE sources. They were Debianized sources and yes, modified for Kubuntu too. Now that people using different distros are involved a lot of that Debianization is being remedied. Everybody here will be grateful for any help you provide. Not all of the packages have been ported to cmake. Here are the ones I know that have been converted: Core packages: tqtinterface arts kdelibs kdebase Other: amarok dbus-1-tqt dbus-tqt kdeartwork kdegraphics kdenetwork kdepim kdevelop Use autotools to build the other packages. The wiki has basic instructions for building but needs somebody new (unfamiliar) to help improve those instructions. Know too that not everybody uses all of the packages in the source tree. So that means some of those non main packages are not tested as well as core packages. Browse the bugzilla for patches to the packages. Every distro is different and many packages will not build without those patches. Those patches will get merged when the SVN to GIT conversion is completed. Until then just backport the patches as necessary. The GIT repository is not ready for use. Tim (project leader) is still converting everything from SVN. He also is implementing a massive file and package renaming scheme before opening GIT to all of us. So don't use GIT, just use the 3.5.13 tarballs. :) Darrell