On Thu, Apr 21, 2016 at 03:22:43PM +1000, bruce muirhead wrote: > On 21/04/16 15:00, Scott Kostyshak wrote: > > On Thu, Apr 21, 2016 at 02:26:12PM +1000, bruce muirhead wrote: > > > On 21/04/16 13:10, Scott Kostyshak wrote: > > > > On Thu, Apr 21, 2016 at 11:51:38AM +1000, bruce muirhead wrote: > > > > > On 21/04/16 09:37, Scott Kostyshak wrote: > > > > > > On Thu, Apr 21, 2016 at 09:20:04AM +1000, bruce muirhead wrote: > > > > > > > On 21/04/16 03:34, Scott Kostyshak wrote: > > > > > > > > On Wed, Apr 20, 2016 at 02:39:19PM +0200, Jean-Marc Lasgouttes > > > > > > > > wrote: > > > > > > > > > Le 20/04/2016 14:31, bruce muirhead a écrit : > > > > > > > > > > Clearly the problem had to be my particular debian setup. > > > > > > > > > > > > > > > > > > > > My first port of call was to change the window manager I > > > > > > > > > > have been > > > > > > > > > > using, from xfce running on openbox to xfwm4. > > > > > > > > > > > > > > > > > > > > This completely removed the problem, and all is now working > > > > > > > > > > as it > > > > > > > > > > should, although I am at a loss in terms of knowing why > > > > > > > > > > openbox should > > > > > > > > > > be a problem---it has until very recently been my desktop > > > > > > > > > > of choice. > > > > > > > > > > (Obviously, some modification in the openbox version I use.) > > > > > > > > > > > > > > > > > > That's pretty strange... If you ever find out why openbox > > > > > > > > > does not like this > > > > > > > > > dialog, there may be something we have to fix on our side. > > > > > > > > > > > > > > > > > > > I have, apparently, been wasting your time, but all I can > > > > > > > > > > say is thank > > > > > > > > > > you---without confirmation that the file worked, I would > > > > > > > > > > not have found > > > > > > > > > > what was causing my problem. > > > > > > > > > > > > > > > > > > Don't worry, it is important for us to understand those > > > > > > > > > problems. We've had > > > > > > > > > several instances where weeks of head scratching lead to > > > > > > > > > discover an actual > > > > > > > > > bug in our code. > > > > > > > > > > > > > > > > +1 on the contrary, thank you Bruce for helping investigate > > > > > > > > this issue! > > > > > > > > > > > > > > > > Even though you know the issue has to do with openbox, I think > > > > > > > > it is > > > > > > > > important to know which change in LyX's code triggered the > > > > > > > > issue. > > > > > > > > > > > > > > > > In my opinion the way to proceed is a git bisect. Now that you > > > > > > > > have git > > > > > > > > set up and you have compiled 2.1.0, here is the procedure: > > > > > > > > > > > > > > > > # will remove any extra files > > > > > > > > git clean -xdf > > > > > > > > git bisect start > > > > > > > > # "good" because you cannot reproduce the bug > > > > > > > > git bisect good 2.1.0 > > > > > > > > # "bad" because you can reproduce the bug > > > > > > > > git bisect bad 2.2.0rc1 > > > > > > > > > > > > > > > > # chunk label A > > > > > > > > # now compile and run LyX, e.g. > > > > > > > > # use make -j4 or whatever to speed things up > > > > > > > > # sometimes the compilation fails, see below for details on > > > > > > > > what to do > > > > > > > > ./autogen.sh && ./configure && make && ./src/lyx > > > > > > > > # go have a tea, watch a movie, or eat some ice cream feeling > > > > > > > > happy with > > > > > > > > # yourself because your computer is doing important work so > > > > > > > > this is not > > > > > > > > # wasted time. > > > > > > > > # When LyX has compiled (if it compiled successfully), it will > > > > > > > > # automatically start (because of the ./src/lyx) so you don't > > > > > > > > need to > > > > > > > > # constantly check back on the terminal. > > > > > > > > > > > > > > > > # now do your manual test of "can you reproduce the bug" ? > > > > > > > > # if you do see the bug, then this is a "bad" commit and you run > > > > > > > > # git bisect bad > > > > > > > > # if you do not see the bug, then this is a "good commit" and > > > > > > > > you run > > > > > > > > # git bisect good > > > > > > > > # if you were not able to compile a certain commit, you do not > > > > > > > > know if > > > > > > > > # it is "good" or "bad". In this case do > > > > > > > > # git bisect skip > > > > > > > > > > > > > > > > # after the above, you will be taken to a new commit to test > > > > > > > > whether > > > > > > > > # good or bad. > > > > > > > > # to be sure, I recommend doing the following: > > > > > > > > # this will make sure you do a fresh compile every time. > > > > > > > > git clean -xdf > > > > > > > > > > > > > > > > # now go up to chunk label A and start again. > > > > > > > > > > > > > > > > # the output that git provides, should be understandable. It > > > > > > > > will tell > > > > > > > > # you how many times you will need to compile and test, and it > > > > > > > > will tell > > > > > > > > # you which commit is the "bad" one. > > > > > > > > > > > > > > > > Please ask on the list if you have questions. > > > > > > > > > > > > > > > > Scott > > > > > > > > > > > > > > > When running > > > > > > > git bisect bad 2.2.0rc1 > > > > > > > I receive the following message: > > > > > > > > > > > > > > Please, commit your changes or stash them before you can switch > > > > > > > branches. > > > > > > > Aborting > > > > > > > > > > > > > > Please advise. > > > > > > > > > > > > OK, did you make any changes to the LyX source code? If so, make > > > > > > sure > > > > > > you back them up. Then, in the instructions above, add > > > > > > > > > > > > git reset --hard > > > > > > > > > > > > to every instruction just before every > > > > > > git clean -xdf > > > > > > > > > > > > You might need to do > > > > > > git bisect reset > > > > > > > > > > > > If you see another problem, post the output (showing if some of the > > > > > > commands worked and where you are at in the instructions when you > > > > > > run > > > > > > into the problem). > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Scott > > > > > > > > > > > Ok, I started the whole process over, from the beginning, i.e., I did > > > > > a > > > > > fresh clone of the git files, and followed your procedure. > > > > > > > > > > The first compilation resulted in the following version > > > > > > > > > > version 2.2.0dev > > > > > Built from git commit hash 7f0ac093 > > > > > > > > > > which was good. I input the command you gave, and received the > > > > > following: > > > > > > > > > > bruce@debian:~/lyx$ git bisect good > > > > > Bisecting: 755 revisions left to test after this (roughly 10 steps) > > > > > error: Your local changes to the following files would be overwritten > > > > > by > > > > > checkout: > > > > > po/ar.gmo > > > > > po/ar.po > > > > > po/ca.gmo > > > > > po/ca.po > > > > > po/cs.gmo > > > > > po/cs.po > > > > > po/da.gmo > > > > > po/da.po > > > > > po/de.gmo > > > > > po/de.po > > > > > po/el.gmo > > > > > po/el.po > > > > > po/en.gmo > > > > > po/en.po > > > > > po/es.gmo > > > > > po/es.po > > > > > po/eu.gmo > > > > > po/eu.po > > > > > po/fi.gmo > > > > > po/fi.po > > > > > po/fr.gmo > > > > > po/fr.po > > > > > po/gl.gmo > > > > > po/gl.po > > > > > po/he.gmo > > > > > po/he.po > > > > > po/hu.gmo > > > > > po/hu.po > > > > > po/ia.gmo > > > > > po/ia.po > > > > > po/id.gmo > > > > > po/id.po > > > > > po/it.gmo > > > > > po/it.po > > > > > po/ja.gmo > > > > > po/ja.po > > > > > po/nb.gmo > > > > > po/nb.po > > > > > po/nl.gmo > > > > > po/nl.po > > > > > po/nn.gmo > > > > > po/nn.po > > > > > po/pl.gmo > > > > > po/pl.po > > > > > po/pt_BR.gmo > > > > > po/pt_BR.po > > > > > po/pt_PT.gmo > > > > > po/pt_PT.po > > > > > po/ro.gmo > > > > > po/ro.po > > > > > po/ru.gmo > > > > > po/ru.po > > > > > po/sk.gmo > > > > > po/sk.po > > > > > po/sr.gmo > > > > > po/sr.po > > > > > po/sv.gmo > > > > > po/sv.po > > > > > po/tr.gmo > > > > > po/tr.po > > > > > po/uk.gmo > > > > > po/uk.po > > > > > po/zh_CN.gmo > > > > > po/zh_CN.po > > > > > po/zh_TW.gmo > > > > > po/zh_TW.po > > > > > Please, commit your changes or stash them before you can switch > > > > > branches. > > > > > Aborting > > > > > > > > > > A hard reset returns me to the already tested hash, and so achieves > > > > > nothing. > > > > > And a bisect reset returns me to 2.1.0. > > > > > > > > > > Clearly there is something I need to do before inputing the "bisect > > > > > good" > > > > > command, or perhaps there is something I need to install. > > > > > > > > > > In any event, without knowledge which I do not currently possess, I > > > > > cannot > > > > > continue. > > > > > > > > Try doing the "git reset --hard" before "git bisect good". > > > > > > > > Scott > > > > > > > "git reset --hard" takes me back to the original head, from which the > > > problem continues. > > > > > > Before I arrived at the same message I noted above, I managed to test: > > > > > > LyX Version 2.2.0dev > > > (not released yet) > > > Built from git commit hash 7f0ac093 > > > > > > and it was good. > > > > > > Reading the git manual and various pages of information has not helped me > > > to > > > work out what is happening, so I am going to have to leave it here, for > > > now. > > > > OK let's try a fresh start with updated instructions. Please try the > > following, and if you get an error, post all of the output (beginning > > from the start of the instructions listed below): > > > > # first back up any changees in the LyX source in case you want to keep > > # anything. Ask if you need clarification. > > > > # will remove any extra files, and any changes to the LyX source > > git clean -xdf > > git reset --hard > > # possible need the following command if you had started a bisect before > > # and want to start over: > > git bisect reset > > > > git bisect start > > # "good" because you cannot reproduce the bug > > git bisect good 2.1.0 > > # "bad" because you can reproduce the bug > > git bisect bad 2.2.0rc1 > > > > # chunk label A > > # now compile and run LyX, e.g. > > # use make -j4 or whatever to speed things up > > # sometimes the compilation fails, see below for details on what to > > # do > > ./autogen.sh && ./configure && make && ./src/lyx > > # go have a tea, watch a movie, or eat some ice cream feeling happy with > > # yourself because your computer is doing important work so this is not > > # wasted time. > > # When LyX has compiled (if it compiled successfully), it will > > # automatically start (because of the ./src/lyx) so you don't need to > > # constantly check back on the terminal. > > > > git clean -xdf > > git reset --hard > > > > # now do your manual test of "can you reproduce the bug" ? > > # if you do see the bug, then this is a "bad" commit and you run > > # git bisect bad > > # if you do not see the bug, then this is a "good commit" and you run > > # git bisect good > > # if you were not able to compile a certain commit, you do not know if > > # it is "good" or "bad". In this case do > > # git bisect skip > > > > # after the above, you will be taken to a new commit to test whether > > # good or bad. > > > > # now go up to "chunk label A" and start again. > > > > # the output that git provides, should be understandable. It will tell > > # you how many times you will need to compile and test, and it will tell > > # you which commit is the "bad" one. > > > > Scott > > > Ok, first question: What does "chunk label A" refer to.
It is just a way that I can refer to a previous piece of code. If it is easier to understand, delete the line # chunk label A and where it says # now go up to "chunk label A" and start again. instead change that to be now go back to to the line in the instructions that starts with "now compile and run LyX" Does that make sense? I'm sorry for the unclear instructions. Thanks for sticking with it. Scott
signature.asc
Description: PGP signature
