> 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. I suspected there was no easy way. > 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. 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. > Also please > note that distro-specific patches cannot be applied for > obvious reasons--I > noticed quite a few of them in kdebase. ;-). 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.