The kdelibs sources were modified to avoid compile errors when the --disable-dnssd option is used and avahi is not installed. In the stock Slackware build script that option is not used. The stock Slackware build script compiles without those errors. In configure --help, the default option is not explicitly declared. Only the --disable-dnssd option is mentioned in the help output. There is no --enable-dnssd option mentioned in the --help options. I think the latter option is valid, however. In the stock configure there is a test for --enable-dnssd. One way or another, I presume that dnssd support is enabled by default. To the best of my knowledge Slackware does not include any kind of dnssd service. So an obvious question is why does the Slackware build script not fail? The stock configure file contains the following mild warning: if test "$have_libdns_sd" = "no"; then echo "" echo "You're missing Apple mDNSResponder 85 or later, therefore" echo "dnssd will be compiled as stub, without any real functionality." echo "If you want zeroconf support (www.zeroconf.org), you should install mDNSResponder first." echo "See dnssd/INSTALL for details." echo "" all_tests=bad fi I think this warning is the same as Trinity KDE. Yet the stock KDE 3.5.10 builds without halting if no such service is installed while the Trinity version does not. Based upon that warning, kdelibs should compile with or without the --disable-dnssd option and the KDE DNS-SD watcher service should compile as an unfunctional stub. At this point I don't think being required to use the --disable-dnssd option is the correct approach. Related to this issue, what will happen if I compile kdelibs with avahi installed, but an end-user installs that package without avahi installed? Will KDE choke or spew forth a bunch of error messages? As we have not yet ironed out the bugs that will allow me to install these recompiled packages, I have no idea of the result. I can see the KDE DNS-SD watcher service in the my stock version of the Control Center. Hopefully compiling with avahi but installing without causes no problems and the KDE watcher services just shrugs, so to speak. I can add some verbosity in the build script explaining that building with avahi installed is a good idea but installing the kdelibs package does not require having avahi installed. I doubt the Slackware maintainer compiled kdelibs with avahi installed. He's not that kind of person. His philosophy is to provide a basic operating system. If an end-user wants DNS-SD suppor then that would be up to the end-user. Therefore I think kdelibs should compile without needing the --disable-dns option or having avahi installed. I have all the original stock KDE 3.5.10 sources. Please let me know what information to forward to better resolve this issue. I can send anything from the stock Slackware build process too. Thanks. Darrell

Hmmm....Xinerama works just fine on Ubuntu. I wonder if the the option is now either locked to "enable" or if Trinity may just be using Qt's underlying Xinerama support at this point (my guess). Did you get a chance to try modifying kdelibs/kdecore/kipc.cpp yet? I will commit the 3.5.12 version change along with that file if the build problem was fixed. Thanks! Tim

Does building each Trinity package depend upon having the previous package in the build chain installed? For example, do I have to have the Trinity version of kdelibs installed to build kdebase? Or can I build each Trinity package on my stock KDE 3.5.10 system?

Hmm. Okay. I'll create a virtual Slackware 12.2 machine that does not have KDE 3.5.10, or arts installed and start building in that environment. Could some of these build errors have to do with me building in an a KDE 3.5.10 environment?

Good news. I reconfigured my virtual Slackware 12.2 machine with no KDE remnants. The kdelibs package built for about 63 minutes before failing. The virtual machine is a tad slower than the actual hardware. When we were testing the Ark modifcations I could build the stock 3.5.10 kdelibs in about 50 minutes. Thus I am guessing that the build in the clean environment might have been close to completion before failing. As my first pass was a test, I did not keep a log of the output. I just updated svn and am now running another build pass. I'll send an update in a few hours.

The only thing I can think of is to check the KDE version number; if it is greater than or equal to 3.5.11 then Trinity is installed. Probably a good idea; I don't have the time at the moment to pursue it further but if you come up with a reliable method for doing this I would be willing to look at it and commit it to SVN.

When building kdelibs I always receive the following configure warning: lua.h was not found or was not usable, Lua 5.0 headers are required ! I see that same warning when I build from the stock KDE and Slackware build scripts. Obviously the package builds just fine in Slackware, so I'm just wondering what that warning is all about. Darrell

Trinity is intended to coexist with KDE4. If I set my build options to install in /usr rather than /opt/kde3, how much will break because Trinity expects to exist in /opt? Hopefully nothing in the sources is hard-coded to /opt. I want to make that an option in my build scripts and not a requirement. In my build scripts I can set the --prefix option to /usr. Or /opt/kde3. Or whatver. I really do not want to install in /opt and have no motivation at this time to install KDE4. I suspect many people using KDE3 don't care about KDE4, although ensuring they can coexist is a pragamatic decision. Darrell

Excuse my ignorance or blindness, but is there a master change log anywhere? I notice change logs in each .svn directory, which seem to match the ChangeLog in the parent directory, but they all are outdated terribly. Darrell

Okay. That works. I was thinking a more human readable log that most people are accustomed to reading. The trick would be to massage that list into something friendlier. I ask because when I announce that this project works with Slackware, I expect people to ask what has changed. If most people think the only thing provided is simply compiling 3.5.10 to work with newer software layers, then many will not be motivated to investigate. If they know that Trinity actually provides many bug fixes and enhancements, then those who have wanted to stay with 3.5.x will be more motivated. I am aware of your kubuntu web page with a handful of screen shots. I was thinking a more verbose but friendly change log link at that page might be useful and simple marketing.

What is the status of the KDE help files? I always found them terribly outdated in the stock KDE. As Trinity is being patched and wonderfully updated, are the Help files being updated too? Darrell

Heh. I have provided technical writing services for a couple of decades or so. Some challenges I forsee: 1. I have to learn how to edit and make KDE Help files. 2. I need a way to monitor the master change log to know what needs updating. that was one reason I asked about change logs.

Correct. Yes.