> > Here's what I do. Create a patch. In this case to fix
> the QString -> TQString. Then build the package with the
> patch. If the build succeeds then submit the patch in a bug
> report. If the patch fails then submit a big report
> explaining your effort.
> > 
> Err OK... This is where I have a bit more learning to know
> what to patch where :)

Yeah, that's how I learn. I won't pretend to have mastered much, but I'm willing to get my hands dirty. :)

I read the build failure. Most of the time the failure is straightforward. Sometimes not and then I'll rerun the build without parallel building (NUMJOBS=-j1). That forces an easier to read output because the build output is sequential. Slower too. :)

Read the failure and be sure to find the problem file. Often the output says in this file, declared by that file, etc. The last file listed is the problem.

Then look at the line number, which is a number after a colon next to the name of the problematic file.

Open that file from the sources and verify the text. In your case look for QString.

For me, I prefer not to edit my local GIT repository while experimenting because I have not yet learned the many ways of the git commands. Therefore I copy that module to a working directory. Then make another copy with the .new extension. I edit the problematic file in the .new directory. In your case change QString to TQString.

Then in the parent directory of the two copied directories:

diff -urN module module.new > module-tqstring-fix.diff

Name the diff file to something that makes sense.

Then merge the patch into the build process as usual.

Darrell