>> 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. There really is no way to do that...Trinity has come very far since 3.5.10, and a lot of code has been rewritten/moved/added. I am merging the patches in as I write this; I have to preselect which patches can be safely applied versus those which would be adding duplicate functionality or causing accidental regressions. > > 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. That you could definitely help with as I do not have the time nor inclination to do so. I would suggest pulling each patch file, and comparing it against the current Trinity sources. If it looks like a patch was not applied, look around a bit in the source file to see if the same functionality was implemented in a different manner. If it looks like something is completely missing, please let me know. Also please note that distro-specific patches cannot be applied for obvious reasons--I noticed quite a few of them in kdebase. ;-). > <snip> > > 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. Not sure; I wouldn't spend too much time on it myself. One idea is that /dev and /proc may need to be mounted in the chroot environment, but that is just a wild guess. Tim