7 Dec
2011
7 Dec
'11
12:39 a.m.
On Tue, 29 Nov 2011 16:07:27 -0800 (PST)
Darrell Anderson <humanreadable(a)yahoo.com> wrote:
(Things got hectic for me after my original message was sent and I never got around to
replying to this. Or filing those bugs. Mea culpa. I'll do the bugs soon.)
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 startup script I eventually ended up using was created by combining parts of one of
the
scripts you posted here with the Gentoo KDE 3.5.10 startup script (and adding a few extra
variable setters to fix the problems I ran into). It is extensively stripped and probably
not
suited for general use by other distros as-is, but I'll check the bug and see about
posting a
diff for any useful bits.
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
Personally, I wouldn't consider aRts a core package--KDE 3.5.10 runs perfectly well
without it, and I
expect Trinity will too, unless there have been extensive changes. (I haven't set up
sound inside my
testing VM yet, or I would know for certain.)
Other:
amarok
dbus-1-tqt
dbus-tqt
kdeartwork
kdegraphics
kdenetwork
kdepim
kdevelop
Use autotools to build the other packages.
Part of the problem is that I am trying to package some of the peripheral, non-core parts
of Trinity
for Gentoo. I was hoping to make things easier for Serghei and the others involved in the
Gentoo
packaging effort, which seems to have even less manpower available than the main Trinity
project
and is moving forward very slowly.
The thing is, I cannot get Portage, Gentoo's package manager, to build the packages
that still use autotools.
(CMake-based packages are okay.) I apparently need the configure.in and supporting files
that are
missing from the root level of the source tarballs for 3.5.13 so that Portage can
regenerate the
other configuration files.
Unfortunately, I suspect that Timothy Pearson is the only person who might be able to
produce these files.
I'm hesitant to file a bug about this because the problem is 1. with autotools and 2.
probably limited to
distros using ebuilds/Portage, of which there are only about three (Gentoo, Funtoo, and
kinda-sorta
Sabayon).
Without the missing files, these packages are going to have to wait for the attention of
someone who knows
more about Portage and autotools than I do, which might take a long time. It would also
be wasted time,
with the CMake port in process. I'd like to see Gentoo able to offer a full set of
Trinity packages before the
latter hits v15, though.
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.
Given that I've been installing everything piecemeal according to what I could
persuade Portage to handle,
I suspect I know this better than most (I basically had only kdebase, kdelibs, and
tqtinterface installed
when I first started Trinity up). I had intended to test the handful of non-core
applications that I use
under KDE 3.5.10 (Filelight, K3B, the Tiblit widget style if I can get it to build, and
some stuff from
kdegraphics, kdemultimedia, and kdeutils), but that was before I ran into the build
problems with Portage.
It's nice to see the flaky compositing bugs I keep getting with KDE 3 gone, anyway.
:)