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
signature.asc
Description: PGP signature
