I updated svn but have not yet recompiled. I'm getting there.... :)
> > 1. As non-root Trinity seems to completely honor
> $KDEHOME. There is no
> > ~/.kde3 directory created and Trinity uses my existing
> ~/.kde directory.
> >
> > As root Trinity does not fully honor $KDEHOME.
> >
> <snip>
> Quick comment here. The above was very important.
> ;-) Trinity expects to
> see KDEROOTHOME set, not KDEHOME, when run as root.
> Maybe you can help
> here; is this a Debian-only distinction, or do other Linux
> systems also
> use KDEROOTHOME?
I know about the KDEROOTHOME variable. I have not toyed with a sufficient number of distros to provide a full answer. The stock Slackware does NOT set the variable. Certainly I can adjust my local /etc/profile.d variable scripts to set that variable. I will test that.
With that said, I wonder whether a simple check can be added in Trinty to look at $UID when KDEROOTHOME is not set?
> ===========================================================
> >
> > 4. The existing startkde is Debianized and causes
> breakage on Slackware
> > systems. I am submitting a proposed new startkde
> script. The proposed
> > script avoids certain presumptions and adds some tests
> before running
> > various commands. The proposed script also adds
> additional echo messages
> > to help debugging efforts.
>
> Can you attach it please? I would like to look at
> it/get it in SVN ASAP
> as we have already run past the feature freeze and these
> types of major
> changes need to be tested thoroughly prior to release.
Yes. Attached. I was going to attach to the previous message but decided to wait until I updated svn and could review your changes. :)
My proposed script is more robust that previous scripts, including the original kde scripts. Part of my additions I already had in my own modified 3.5.10 script. The script works fine here, but I don't have a Debian install using Trinity to test there.
As I mentioned, now that the core packages build and are installed (but not tested for usability!), I am again trying to build koffice.
I would like to ignore previous koffice reports and start fresh.
The first items I hope get addressed are the following configure warnings:
unknown icon type in kivio/plugins/kivioconnectortool/Makefile.in (kivio_connector_cursor1.png)
unknown icon type in kivio/plugins/kivioconnectortool/Makefile.in (kivio_connector_cursor2.png)
unknown icon prefix action in kpresenter/toolbar/Makefile.in
unknown icon prefix action in kpresenter/toolbar/Makefile.in
unknown icon prefix action in kpresenter/toolbar/Makefile.in
unknown icon prefix action in kpresenter/toolbar/Makefile.in
unknown icon prefix action in kpresenter/toolbar/Makefile.in
unknown icon prefix action in kpresenter/toolbar/Makefile.in
unknown icon prefix action in kpresenter/toolbar/Makefile.in
unknown icon prefix action in kpresenter/toolbar/Makefile.in
unknown icon prefix action in kpresenter/toolbar/Makefile.in
unknown icon prefix action in kpresenter/toolbar/Makefile.in
unknown icon prefix action in kpresenter/toolbar/Makefile.in
unknown icon prefix action in kpresenter/toolbar/Makefile.in
unknown icon prefix action in kpresenter/toolbar/Makefile.in
unknown icon prefix action in kpresenter/toolbar/Makefile.in
unknown icon prefix action in kpresenter/toolbar/Makefile.in
unknown icon prefix action in kpresenter/toolbar/Makefile.in
unknown icon prefix action in kpresenter/toolbar/Makefile.in
unknown icon prefix action in kpresenter/toolbar/Makefile.in
unknown icon prefix action in kpresenter/toolbar/Makefile.in
The warnings more than likely are non-fatal errors, but they also should be fixed. I'm new to this game, but I suspect the problem is with incorrect file names or typos in the make files or something similar.
Darrell
All core packages build. The following also build:
k3b
amarok
knemo
ktorrent
These popular non-core packages are yet untested but will be soon:
koffice
digikam
gtk-qt-engine
gwenview
k9copy
kaffeine
I have had problems building koffice. Now that the core packages build and install, which establishes a known foundation and baseline, I will start again trying to build koffice.
I have not yet installed any packages in a testing environment. Soon!
Darrell
Okay, I'm a little slow. I added the --enable-closure option to the kdeartwork build script and the package built.
Thus, at this point, all core trinity kde packages build on Slackware 12.2!
Darrell
There is some nominal support in kcontrol to support startup management.
I don't know what all is available in this area for KDE 3.5.x, but I'd like to see more.
As Slackers tend to be rather anal about such GUI apps <roll eyes>, very little in that way ever apeared in Slackware.
There is some kind of Lilo manager hook in kcontrol. There is something called qgrubeditor that supports GRUB 1. That tool now only supports QT4 (what's new). I don't see qgrubeditor in svn so here is a vote to support that.
Then there are the startup services and daemons. I don't know if any KDE GUI tool exists for that. If there I would appreciate a link so I can consider how that tool might be adapted to Slackware. I think the Ubuntu folks have something like that, but of course, GTK.
This all would be something for 3.5.13 of course.
Darrell
All core packages, as well as amarok, ktorrent, k3b, and knemo built without error!
kdeartwork is the lone holdout in tonight's effort. :( Log attached.
Darrell
I'm thinking ahead with you offering binary packages for Slackware.
There are several packages that do not have to be installed to build the core KDE packages. I have created this list from watching the build messages and logs. There might be additional packages to add to this list:
libcarddav (part of the Trinity Project, kdepim)
libcaldav (part of the Trinity Project, kdepim)
avahi (dns-sd, DNS service discovery/zeroconf, kdelibs/kdebase)
lua
hspell (Hebrew spell checking)
krb5 (kerberos)
OpenEXR Libraries (EXR image format support, several KDE packages)
GraphicsMagick (various image filters; e.g. koffice/krita, kdebase)
JRE-Java Runtime Engine (kdebindings)
JDK-Java Development Kit (kdebindings)
SIP
PyQT3
PyKDE (Trinity KDE Python bindings; require SIP and PyQT)
PostgreSQL (koffice/kexi)
Transcode, ffmpeg (k3b ripping)
libdvdread, libdvdnav (k3b video ripping)
If the binaries are built without these packages installed, then the build process will not create any related support, even if the end-user installs those packages after installing the KDE packages.
If the binaries are built with these packages installed, then the end-user should be able to make use of those hooks as soon as the additional packages are added.
What happens when the packages are built to provide that support but the end-user does not have the support packages installed?
I'm presuming nothing happens and the built-in support is a dead-end stub. Hopefully the xsession errors log is not filled with useless messages. I always thought the KDE developers were horribly sloppy about controlling stdout/stderr messages captured in the xsession errors log.
Have you done any testing in this area or offer any observations from daily use of Trinity?
As you liked the idea about two sets of packages, one embracing full third-party support and one set stripped to the essentials, seems some testing in this area will be needed if we travel that road.
For my first full build set I am going to build mostly without the third-party support. I likely will install most of the third-party packages listed previously and then build another set of packages. I'm curious what the differences will be in package sizes and performance.
I have both a Pentium I and II box that provide some hard-core performance testing of any distro. :)
If you decide to support two sets of packages I foresee a handful of exceptions. For example, people using K3B will presume and want full ripping support out of the box. I think that package has to be built the same for either set of packages. The K3B package in Slackware never was built that way because of concerns about digital restrictions. I always thought the package should be built with full support but then just don't include the other packages with the distro. At least then when users add the necessary support packages K3B would work immediately as advertised.
Darrell
> Also, on a different note, a Web page now exists that
> details most of the
> major changes from stock 3.5.11 to Trinity 3.5.11.
> The address is
> http://trinity.pearsoncomputing.net/wiki/bin/view/Documentation/Releases_3_…
Looks nice!
Some thoughts:
Image sizes might be too large for folks on slower connections. I have a nominal broadband connection and some of the images took several seconds to download.
How about a note that Ark was patched to support lzma/xz? Oh wait, never mind --- that is an improvement to 3.5.12. Seems we will need a 3.5.12 page too!
What was the date of the official 3.5.11 release? I'll try to learn how to parse the svn logs since that date to create a punch list of improvements since then.
> I did some poking around the Trinity source tree, and it
> appears the
> reason for the build failures is outdated code. Eons
> ago Debian split out
> the three components contained in kdebindings into
> different source
> packages.
>
> The components are:
> SIP
> PyQt
> PyKDE
>
> I agree with this decision for the following reasons:
> 1. SIP and PyQt are both maintained upstream and function
> perfectly with
> Trinity as-is; it makes no sense to maintain a
> Trinity-specific copy of
> these software projects.
> 2. PyKDE needs to be patched for Trinity, and has already
> been moved to
> <svnroot>/libraries/python-kde3
> 3. This decision seems to fit with the general
> user-configurability model
> of Trinity; some users may want to install the Java/Ruby
> bindings, but not
> the Python bindings.
>
> With this in mind, I believe the correct course of action
> is to remove the
> <svnroot>/kdebindings/python folder completely.
I don't know whether these decisions are correct. I'll trust you. As long as kdebindings works as expected in non-Debian systems _and_ various python bindings work in KDE.
Slackware always uses stock KDE sources from upstream. Thus, if the KDE devs were including sip and python support in kdebindings, Patrick would not monkey with that. NOt saying who is right or wrong, just sharing facts. :)
SIP was not included with the stock Slackware but available as an extra package.
PyQt3 was not included with the stock Slackware but available as an extra package.
PyKDE is unknown to Slackware. By your description, sounds as though this Debian package is the python-specific portion originally packaged with kdebindings.
Sounds as though the first two packages are not strict build prerequisites, but recommended build prerequisites and should be built/installed by people who want those bindings when building pyKDE. Is that correct? Or do users merely install SIP and PyQT after installing KDE and those bindings work thereafter with KDE? There has to be some way when building kdebindings to provide the foundations hooks so python will work with KDE.
How does all of this affect building the core KDE packages? Do I need to modify my kdebindings build script?
With that said, I have progressed further with kdebindings.
I mentioned my scheme to copy on-the-fly in my build script the python/sip/sipgen files from 3.5.10. That gets me past the original build failure. Of course, your information sounds as though all of that will disappear now anyway.
Sounds good.
With that said, my builds go for a while before failing. I have patched some /usr/include files from kdelibs. All of the patches are one-liners adding a specific tqt interface include statement. You can review the patches and decide whether they are necessary. Maybe they are, maybe they are not with the changes you propose.
The process is slow because I get to see only one failure when the build fails. I add an appropriate include statement and then build again. I don't know the QT/TQT interface like you and I have to learn which include statement to add. Takes time. Regardless, the three patches I am including eliminate the build failures related to those files. Good thing this stuff can run in the background. :)
I just compiled again and received an error I don't know how to fix. Log attached.
I don't now how this is all affected by what just shared, but I suspect we are getting closer to building kdebindings. :)
