Tim, All,
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...)
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've updated 979 with the info.
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
I did not explain correctly.
Don't use the commit hashes from the Commit Patches web page. Use git log.
cd $GIT_DIR_TOP_LEVEL git log
Scroll to the desired date. Find the last commit hash for that date. Copy that hash number and then use git reset --hard.
I have started rebuilding after resetting to 4/10.
Darrell
On 30 Apr 2012, Darrell Anderson verbalised:
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.
This depends.
"git reset --soft" just moves HEAD. The index is unaffected, so everything that has changed between your current position and the point you reset to is now listed as a 'change to be committed' in 'git status'.
"git reset --mixed" (the default) moves HEAD and wipes out the index, but leaves the working tree unaffected.
"git reset --hard" wipes out the working tree, the index, everything. It doesn't touch untracked files, though.
And, the most extreme, "git clean" wipes out untracked files (possibly including ignored ones and whole unknown directories, see the manpage).
This is a right terminological mess, I must admit.
"git reset --soft" just moves HEAD. The index is unaffected, so everything that has changed between your current position and the point you reset to is now listed as a 'change to be committed' in 'git status'.
"git reset --mixed" (the default) moves HEAD and wipes out the index, but leaves the working tree unaffected.
"git reset --hard" wipes out the working tree, the index, everything. It doesn't touch untracked files, though.
And, the most extreme, "git clean" wipes out untracked files (possibly including ignored ones and whole unknown directories, see the manpage).
This is a right terminological mess, I must admit.
I don't know how this is supposed to work. I ran 'git reset --hard'. When I viewed the top level with git log, the newest date was April 10. Seemed okay to me.
After my previous two builds and testing I wondered whether that truly reset the source files. I changed to the tdebase directory and again ran git log. The most recent commit was from a few days ago.
So I did a git reset there too and in tdelibs.
In light of this, I don't think my previous build runs and tests were credible because more than likely I was building at least tdelibs and tdebase with recent sources.
There must be a way to correctly reset my sources so I build with the sources from that date and ignore all commits thereafter. I love wasting my time.
Darrell
On 1 May 2012, Darrell Anderson verbalised:
This is a right terminological mess, I must admit.
I don't know how this is supposed to work. I ran 'git reset --hard'. When I viewed the top level with git log, the newest date was April 10. Seemed okay to me.
After my previous two builds and testing I wondered whether that truly reset the source files. I changed to the tdebase directory and again ran git log. The most recent commit was from a few days ago.
So I did a git reset there too and in tdelibs.
Oh, you'll need to do a 'git submodule update --recursive' after resetting the containing repository to catch the submodules in the reset net, too. Submodules are not instantly affected by motion through history in the parent (which I consider a bug, but which was essential if submodules were not to be so invasive that they'd never have been accepted into git).
"git reset --soft" just moves HEAD. The index is unaffected, so everything that has changed between your current position and the point you reset to is now listed as a 'change to be committed' in 'git status'.
"git reset --mixed" (the default) moves HEAD and wipes out the index, but leaves the working tree unaffected.
"git reset --hard" wipes out the working tree, the index, everything. It doesn't touch untracked files, though.
And, the most extreme, "git clean" wipes out untracked files (possibly including ignored ones and whole unknown directories, see the manpage).
This is a right terminological mess, I must admit.
I don't know how this is supposed to work. I ran 'git reset --hard'. When I viewed the top level with git log, the newest date was April 10. Seemed okay to me.
After my previous two builds and testing I wondered whether that truly reset the source files. I changed to the tdebase directory and again ran git log. The most recent commit was from a few days ago.
So I did a git reset there too and in tdelibs.
In light of this, I don't think my previous build runs and tests were credible because more than likely I was building at least tdelibs and tdebase with recent sources.
There must be a way to correctly reset my sources so I build with the sources from that date and ignore all commits thereafter. I love wasting my time.
Darrell
Try this: git reset --hard HEAD git checkout <hash>
That should do the trick!
Tim
Try this: git reset --hard HEAD git checkout <hash>
That should do the trick!
This needs to be done once for the entire local repo or for each module (tqt3, tdelibs, tdebase...)?
Darrell
Execute those two commands from within each module, e.g.: cd tdebase/ git reset --hard HEAD git checkout <hash> <build/install>
Tim
On 1 May 2012, Timothy Pearson said:
Try this: git reset --hard HEAD git checkout <hash>
That should do the trick!
This needs to be done once for the entire local repo or for each module (tqt3, tdelibs, tdebase...)?
Darrell
Execute those two commands from within each module, e.g.: cd tdebase/ git reset --hard HEAD git checkout <hash> <build/install>
Git 1.6.1+ has 'git submodule foreach' which should take most to all of the pain out of this (and if you're not using at least 1.7.x, you should upgrade, because the submodule support has come on in leaps and bounds).
On 04/30/2012 06:34 PM, Darrell Anderson wrote:
I don't know how this is supposed to work. I ran 'git reset --hard'. When I viewed the top level with git log, the newest date was April 10. Seemed okay to me.
After my previous two builds and testing I wondered whether that truly reset the source files. I changed to the tdebase directory and again ran git log. The most recent commit was from a few days ago.
So I did a git reset there too and in tdelibs.
In light of this, I don't think my previous build runs and tests were credible because more than likely I was building at least tdelibs and tdebase with recent sources.
There must be a way to correctly reset my sources so I build with the sources from that date and ignore all commits thereafter. I love wasting my time.
Darrell
Damn,
I thought I had this, now I'm confused (happens). Just so I'm keeping up, since I create tarballs from the tree before building -- what kind of reset do I do?
GIT = (Great Indecipherable Technology)
In theory backing up should be simple, but I've never done it. Whatever reset we do has to back out all the updates from that point forward so when I step through the tree and create tarballs, I get what I'm supposed to get when I tar the source up.
Do we have a consensus on Tim's:
git reset --hard HEAD git checkout <hash>
executed from within each module?
OK, I'm going with this :)
On 04/30/2012 01:50 PM, Darrell Anderson wrote:
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
Got it! Excellent explanation! That is the practical - this is how to reset your tree to an earlier point in time I need. I had a bunch to do today, but I will have a bit of time tomorrow to focus on this problem. I'll start at 4/4 and work backwards. I've been through each commit in the http://trinitydesktop.org/patches/ list and looking and looking at the diffs for likely ones by title (and even the unlikely ones) didn't turn up anything. It is truly a bisect and build problem. bummer ... :)
Got it! Excellent explanation! That is the practical - this is how to reset your tree to an earlier point in time I need. I had a bunch to do today, but I will have a bit of time tomorrow to focus on this problem. I'll start at 4/4 and work backwards. I've been through each commit in the http://trinitydesktop.org/patches/ list and looking and looking at the diffs for likely ones by title (and even the unlikely ones) didn't turn up anything. It is truly a bisect and build problem. bummer ... :)
Beware that the correct method is actually to do this from within each module (tdelibs/, tdebase/, etc.): git reset --hard HEAD git checkout <hash>
Tim
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...)
So that is the best I can do in narrowing it down rapidly from existing binaries I have.
I reset my GIT repo to 4/10 and rebuilt. No kwrite flakiness and my test means I am outside your proposed time frame.
The mystery deepens. So for me, the problem seems to lie between 4/10 and yesterday. I'll bisect my way to the latest GIT, keep rebuilding and testing.
With that said, although originally to avoid conflicts I removed Qt4 and KDE4 from my Slackware Current build system, I did not remove all Qt4 related packages, like phonon*, akonadi*, QScintilla.... I did not think they would make a difference with the build process, but who knows? I have now removed those packages. If the kwrite weirdness goes away here then I'll have to attribute the problems I saw to one of those packages. We'll see.
Darrell
I reset my GIT repo to 4/10 and rebuilt. No kwrite flakiness and my test means I am outside your proposed time frame.
I wanted to know whether removing the remaining KDE4/Qt4 packages had any influence. I rebuilt the core apps to the latest GIT. Same kwrite flakiness.
David,
Something bothered me about my previous test. I cleaned house and reinstalled those packages from "4/10" that I built earlier today. Sure enough kwrite started misbehaving again.
Seems there is indeed a problem before that date. Ignore my previous post as your time frame seems credible again. :-)
Tim,
The problem I see with kwrite is I can't scroll through to the end of a basic text file. The file I am using is 232 lines long. Hardly a mammoth. Yet whether I scroll one line at a time with the Down arrow key, use Page Down, or use Ctrl-End, kwrite freezes and stops responding. At this point I'm not set up to do backtraces. I don't see any classic crash anyway. The app just freezes.
Curiously, kate does not do this. I tested kate with the Memory Usage buffer set at 16 and at 512 (maximum). No difference. Kate behaves for me.
Darrell
On 04/30/2012 06:13 PM, Darrell Anderson wrote:
Seems there is indeed a problem before that date. Ignore my previous post as your time frame seems credible again. :-)
Tim,
The problem I see with kwrite is I can't scroll through to the end of a basic text file. The file I am using is 232 lines long. Hardly a mammoth. Yet whether I scroll one line at a time with the Down arrow key, use Page Down, or use Ctrl-End, kwrite freezes and stops responding. At this point I'm not set up to do backtraces. I don't see any classic crash anyway. The app just freezes.
Curiously, kate does not do this. I tested kate with the Memory Usage buffer set at 16 and at 512 (maximum). No difference. Kate behaves for me.
Darrell
Man,
You are doing something right if kate is behaving. For me it is all the editors except kedit. Are you dumping ~/.trinity completely for testing each time or just /var/tmp/tdecache-darrell ?
The problem I see with kwrite is I can't scroll through
to the end of a basic text file. The file I am using is 232 lines long. Hardly a mammoth. Yet whether I scroll one line at a time with the Down arrow key, use Page Down, or use Ctrl-End, kwrite freezes and stops responding. At this point I'm not set up to do backtraces. I don't see any classic crash anyway. The app just freezes.
Curiously, kate does not do this. I tested kate with
the Memory Usage buffer set at 16 and at 512 (maximum). No difference. Kate behaves for me.
I have been using the same profile and deleting the cache. For this kind of problem, I probably should create a fresh profile each time. Who knows how this bug is corrupting or influencing the config files.
Ignore my build reports from today. The git reset thing means my results are not trustworthy. Best start from scratch.
As you think the problem is between 3/29 and 4/10, start bisecting at 4/4. That's where I was when I quit.
Now here is the kicker I recognized on my third attempt today that broke my proverbial camel's back. Resetting to an earlier commit point means all those gcc 4.7 patches we pushed no longer are available. That means compiling will break --- and did for me.
I tried using -fpermissive. The packages built without incident, but when I tried to run them, all hell broke loose. I could not run apps from the mini cli and received messages the files did not exist. The files did exist and $PATH was just fine.
At that point I quit.
In hindsight I do not like the idea of using -fpermissive for troubleshooting this problem. Doing so adds another variable to the problem. Specifically, what if the problem is gcc and not a patch? Then using -fpermissive masks the problem because gcc no longer is compiling according to the stricter standards. That would be significant time wasted, not to mention not finding the root cause of the problem.
You'll need to use a few patches as necessary to get past the build problems without -fpermissive. You'll need the easyvector patch, unless that part of the code is in a section that can be bypassed in the build configuration (-DBUILD_WHATEVER=OFF). I back ported that patch but then I encountered another build failure regarding dcop, which then prompted me to use -fpermissive. So at this point I know you'll need at least two of the patches we were using before they were pushed to git.
I have a lot of things outside the project suddenly pulling at me, which doesn't help and certainly added to today's stress. The ebb and flow of life. The best approach is to take care of those things. I don't expect to help for a few days but I'll keep tabs on the emails as best I can.
I'm sure this won't be the last time we need to reset the sources for debugging purposes. If you get through this ordeal without losing your mind then perhaps a short wiki how-to would be nice. :-)
Darrell
On 04/30/2012 11:25 PM, Darrell Anderson wrote:
I have a lot of things outside the project suddenly pulling at me, which doesn't help and certainly added to today's stress. The ebb and flow of life. The best approach is to take care of those things. I don't expect to help for a few days but I'll keep tabs on the emails as best I can.
Yep, you and I both have pushed things to the side to focus on TDE and getting it ready for R14 in good shape. I have a bit of catch-up to play myself. Go get the other half of life back up to par and I'll continue picking away at this. I will have to pull a fresh 3/29 git tree down and then work forward to 4/4. I can do so creating tarballs as I update to ensure I have a set for each day (if not each commit).
I share your frustration. R13 was just getting into good shape when gcc 4.5.2 was released that caused similar problems. Not near the extent that 4.7 has, but frustrating nonetheless. We will find the issue somehow.
I'll go look for the clone command that will let me pull a fresh 3/29 tree. If you know the command, that would save me the time, but I suspect it is already in the wiki or man git will do it. (the submodules might be a trick)
Luckily, there are only a few gcc 4.7 patches needed to build through tdebase. We will just apply them as needed to debug. Back at it....
I'm sure this won't be the last time we need to reset the sources for debugging purposes. If you get through this ordeal without losing your mind then perhaps a short wiki how-to would be nice. :-)
Amen...
Nothing like shooting at a moving target to hone your marksmanship skills...
On 05/01/2012 08:56 AM, David C. Rankin wrote:
On 04/30/2012 11:25 PM, Darrell Anderson wrote:
I have a lot of things outside the project suddenly pulling at me, which doesn't help and certainly added to today's stress. The ebb and flow of life. The best approach is to take care of those things. I don't expect to help for a few days but I'll keep tabs on the emails as best I can.
Yep, you and I both have pushed things to the side to focus on TDE and getting it ready for R14 in good shape. I have a bit of catch-up to play myself. Go get the other half of life back up to par and I'll continue picking away at this. I will have to pull a fresh 3/29 git tree down and then work forward to 4/4. I can do so creating tarballs as I update to ensure I have a set for each day (if not each commit).
I share your frustration. R13 was just getting into good shape when gcc 4.5.2 was released that caused similar problems. Not near the extent that 4.7 has, but frustrating nonetheless. We will find the issue somehow.
I'll go look for the clone command that will let me pull a fresh 3/29 tree. If you know the command, that would save me the time, but I suspect it is already in the wiki or man git will do it. (the submodules might be a trick)
Luckily, there are only a few gcc 4.7 patches needed to build through tdebase. We will just apply them as needed to debug. Back at it....
I'm sure this won't be the last time we need to reset the sources for debugging purposes. If you get through this ordeal without losing your mind then perhaps a short wiki how-to would be nice. :-)
Amen...
Nothing like shooting at a moving target to hone your marksmanship skills...
Good news - sort of. I have full sets of tarballs for:
3/29 4/1 4/3 4/4 4/5 4/9 4/10 4/12 4/14 and so on.
I'll make them available on my site. They will be in:
www.3111skyline.com/dl/dt/tde/tgz/date
where 'date' is eg (20120401)
I'll just post tqtinterface -> tdebase to cut down the size. tqt3 is a bit large for my little connection. (tdelibs and tdebase are big enough) If needed, I can post tqt3, let me know. This will save the git download time and worry about submodule updates, etc... (~8 min per date to download)
If somebody wants to download them and re-host them on a faster connection, fine by me :)
On 05/01/2012 09:52 AM, David C. Rankin wrote:
I'll just post tqtinterface -> tdebase to cut down the size. tqt3 is a bit large for my little connection. (tdelibs and tdebase are big enough) If needed, I can post tqt3, let me know. This will save the git download time and worry about submodule updates, etc... (~8 min per date to download)
I went ahead and added tqt3 to the directories....
-
Darrell Anderson -
David C. Rankin -
Nix -
Timothy Pearson