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