30 Apr
2012
30 Apr
'12
6:50 p.m.
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