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