FYI I don't know which team first found and assembled all of these KDE patches. The base patch sets seem to be identical for both teams. The chakra collection provides patches for common third-party KDE apps. Here are links to the collection of patches: http://www.chakra-project.org/svn/branches/kde3/ http://vectorlinux.osuosl.org/veclinux-6.0/source/extra/kde/3.5.10/ There are many useful patches available in this collection. I randomly compared some of the patches to the trinity svn source code. Of those few I compared, seems the patch had not been implemented. These collections are small gold mines. The dates in some of the diff files indicate the patches have been available a long time. For whatever reason they never were merged into the KDE source code. This post serves only as a helpful place holder to find those patches at some future date. Darrell

Yes, I did sample from that package tree. :) I am willing to provide grunt work to merge the patches. I can merge the patches with the stock 3.5.10 sources. Thereafter I need ideas how to _efficiently_ compare those patched sources to trinity sources. Even if many of the patches have already been merged, would be nice to check each patch anyway. At least to create a cross-reference note in the sources or build scripts which trinity svn incorporated the patch. I have been adding notes in my Slackware build scripts so users will know where an original Slackware patch was committed to trinity svn. That provides a simple mechanism of traceability and will help avoid the same repeated questions of what happened to the original patches. Please let me know. I did not realize the KDE devs had gone anal that early. Just another reason why I have lost lots of respect for the KDE devs over the past several years. A talented bunch, but clueless about human relations and end-users. A very myopic bunch. I'll update my local tree. I have 1172360. I'm still stumped why I can't build outside the virtual machine. I am going to install a fresh copy of 12.2 on a separate partition and start from scratch. I hope that I can discover the reason. The VM works but is too slow. I don't understand how automake and make files work so my troubleshooting attempts are meager at best. The configure.logs for both environments are identical except for host names and dates. Directories are almost identical. Installed packages are identical. The custom kernels are slightly different, but I don't see why that would make a difference. All I know is that outside the virtual machine the configure process will always fail with the ldd statement I noted in a previous message. Just frustrating and exhausting.

I suspected there was no easy way. I'll browse through each patch and do my best. If I'm unsure I'll just send you a note and let you decide. I saw one patch I knew would not get accepted by Debian folks. The one that sources environment variable files from etc/profile.d. As far as I can tell, using /etc/profile.d in Debian is some kind of sacrilege. :) I don' think that particular patch is necessary anyway, at least not in Slackware. Maybe the patch had some value in the Chakra project.

The startkde shell script still references 3.5.10 and should reflect the correct build version. For my package names, in my build scripts I pull the version number from kdelibs/kdecore/kdeversion.h. The same approach could be used to update startkde on-the-fly when building kdebase. I can run that correction here, but I think the correction should be made by the build process so as to help any person building the package for any distro. Darrell