> A lot of the patches are already in Trinity; in fact with a > couple of > exceptions I only started to see significant unpatched > files in kdebase. Yes, I did sample from that package tree. :) > I will see how far I get with incorporating those patches > before the > 3.5.12 feature freeze...thanks for letting me know about > them! 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. > Remember "KDE3 is dead, no more feature patches will be > accepted"? That > was occurring for a long time before KDE4 actually came > out. 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. > By the way, I think I *might* have fixed your kdebase build > problem. Can > you update kdebase to SVN revision 1172412 or higher and > try building > kdebase again? 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.