>   I have completed downgrading through the sets of
> binaries I have and from that I can summize that this bug
> was introduced sometime between 3/29 and 4/10. In my 3/29
> build, kwrite is fine. In my 4/10 build, this bug effects
> kwrite, kate, all editors EXCEPT kedit. In kedit, I can
> continue to paste away without any crash (I'm sure it makes
> no use of katepart...)

kedit is an orphan text editor, installed as part of tdeutils and does not use any k*parts of any kind. Off topic, I wish we would update kedit to use the same shortcuts and dialogs and nominal behavior to provide consistency. Sounds like an enhancement request. :-)

>   So that is the best I can do in narrowing it down
> rapidly from existing binaries I have.
> 
>   Darrell, do you have any binaries between 3/29 and
> 4/10 that could help narrow? There were a ton of changes
> that went into the GIT tree for tdelibs and tdebase during
> that two week period. It would be great if we could further
> narrow it by simply loading binaries rather going through
> all the commits...

I have backups but they won't help us. :-) I did not start building Slackware Current until a few days ago. The package backups I have all are for Slackware 13.1 32-bit. The kwrite problem I witness here never surfaced in my 13.1 (or 13.37) builds. Only Slackware Current is affected.

We use 'git reset' to move back in time. I don't know whether a git reset deletes files or only moves to where HEAD is being pointed.

Would one of the GIT gurus help with this?

Yet even if git reset deletes files then that is a nominal price to pay to resolve this problem. After the problem is narrowed we resync to restore up to date.

Start at 4/4 to bisect the alleged bad time frame.

Both kate and kwrite are part of the core packages. To save time, build only the core packages (TQt3->tdebase), install and run quick tests. For me, all I need do is start kwrite and move the cursor a few lines. :-)

Using git reset requires the commit hash number. Use the Commit Patches web page (or 'git log') to determine the last commit on a desired date.

The last commit for 4/4 was 9e172fa7a1e93cc77e09616eb793b823d29ebaec. The syntax is like this:

cd $GIT_DIR_TOP_LEVEL
git reset --hard 9e172fa7a1e93cc77e09616eb793b823d29ebaec
git log

The 'git log' command is needed only to verify the reset took place.

If the kwrite/kate problem perists then continue with another git reset at 4/1 and repeat.

After determining the problem occurs with commits for a specific day, then start bisecting the commits for that day.

I'll start with the last commit for 4/10 (0a4d85561846548aab970994d2787c4eaa14bba7) to confirm your proposed time period. If I can't confirm then the story gets more complicated. If I can't confirm the problem with that reset then I will start bisecting commits in the other direction.

Considering that building the core packages is about a 1 to 1-1/2 hours, this could take a while.

This has to be a clean rebuild each time. Don't try to mix and match. Uninstall everything, build, test, uninstall everything, build, test....

With that said, if this is a gcc 4.7 conflict and not a specific patch commit, then this test plan is unlikely to expose anything. That is, the problem should persist regardless of how far back we go in time. That in itself will help some, although the gcc gurus will have to help.

We do this independently. That way hopefully we arrive at the same conclusion.

Darrell