> 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.