On 22/04/16 10:24, Guillaume Munch wrote:
Le 22/04/2016 02:04, bruce muirhead a écrit :
On 22/04/16 06:04, Scott Kostyshak wrote:
On Thu, Apr 21, 2016 at 10:02:47PM +1000, bruce muirhead wrote:
On 21/04/16 15:38, Scott Kostyshak wrote:
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
Ok, process finished.
The insert-citation problem was present in two earlier bisect runs,
but was
then fixed, until the very last, at which stage the information
provided is:
HEAD is now at 7ffaf4e Review of norwegian layout translations by Helge
bruce@debian:~/lyx$ git bisect bad
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[b5a2f1c7e5caf6f79b6894b562769a5513b7b13f] Fix broken layout of the
citation
dialog (#10019)
Then, after compiling again, the following:
bruce@debian:~/lyx$ git reset --hard
HEAD is now at b5a2f1c Fix broken layout of the citation dialog
(#10019)
bruce@debian:~/lyx$ git bisect bad
b5a2f1c7e5caf6f79b6894b562769a5513b7b13f is the first bad commit
commit b5a2f1c7e5caf6f79b6894b562769a5513b7b13f
Author: Guillaume Munch <g...@lyx.org>
Date: Wed Mar 16 21:47:32 2016 +0000
Fix broken layout of the citation dialog (#10019)
7b1107d7 introduced the following inconveniences which are
regressions
to 2.1:
* The citation dialog can open with vertical scroll bars in the
options
* The citation dialog can open with horizontal scroll bars,
especially
if the
translated text is longer than the original text (e.g. in FR)
* Resizing the dialog is inconvenient because it increases the gap
between the
options. This is unlike before when the dialog could let us
see more
of the
reference list when enlarging.
This is because the QToolbox that the above commit introduced is
not
natively
aware of the sizes of its page sub-widgets. The widget is not
conceived
for this
use, where the space is scarce.
Geometry values provided in the ui file (automatically computed by
qtcreator I
suppose) somehow gave the illusion that it worked, but relying
on such
values is
not portable : it does not take into account the specific theme,
font
sizes and
localization. This explains why it failed on my side and will
probably
fail in
other settings too.
Luckily, there is a simple way to make QToolbox suitable for the
current
use,
which is to add the "missing link" which computes its size based
on the
minimal
sizes of its pages. The result looks very nice and intuitive. It
solves
all the
aforementioned issues.
:040000 040000 87209a4f5b08317ebb29f4bb7eccd9b552bb8830
29964547351ab2a2e272c1d52b05e2dc1792d0e9 M src
bruce@debian:~/lyx$
I hope this is the information you need, and that it is helpful.
This helps a lot, Bruce. Thank you.
Guillaume, do you think it is reasonable to revert this commit with
respect to 2.2.0? Even if we were able to quickly fix it, it seems this
might be sensitive code.
Also, since Guillaume had made some improvements to this commit, it
might be nice to know if Bruce still sees the problem on 2.3-staging.
Bruce, can you do the following?
git checkout 2.3-staging
and compile and test there to see if this particular problem occurs?
After that, it is still better for you to test 2.2.0rc1 with the
reversion for future testing as I detailed in the other email.
Scott
2.2.0rc1, with the reversion, works as expected, i.e., citation insets
work, >insert>citation... works in both fluxbox and openbox. (No
surprise really, that both boxes should behave similarly in respect of
this.)
2.3-staging failed to compile with the following messages:
Makefile:2097: recipe for target 'lyx' failed
make[4]: *** [lyx] Error 1
make[4]: Leaving directory '/home/bruce/lyx/src'
Makefile:2825: recipe for target 'all-recursive' failed
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory '/home/bruce/lyx/src'
Makefile:1658: recipe for target 'all' failed
make[2]: *** [all] Error 2
make[2]: Leaving directory '/home/bruce/lyx/src'
Makefile:543: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/bruce/lyx'
Makefile:437: recipe for target 'all' failed
make: *** [all] Error 2
I attempted configuration and compilation after rc1. I was asked to
commit changes, and used "git checkout-f" to resolve this. Was this
incorrect? In other words, tell me if there is some step I need to take
in order for 2.3-staging to compile correctly.
Bruce
Thanks for that information Guillaume. I am learning as I go, so some
simple mistakes are happening and I apologise for that.
What you copied does not contain the actual error message, which should
be a bit above your selection. Can you please try to find the actual
compilation error message?
This should be the information you need:
liblyxcore.a(BufferParams.o): In function
`lyx::BufferParams::setBaseClass(std::string const&)':
/home/bruce/lyx/src/BufferParams.cpp:2248: undefined reference to
`lyx::LayoutModuleList::adaptToBaseClass(lyx::LayoutFile const*,
std::__debug::list<std::string, std::allocator<std::string> > const&)'
collect2: error: ld returned 1 exit status
'git checkout -f' should be ok to solve this issue (I imagine due to
changed .gmo files), I personnally do 'git stash' when I want to get rid
of changes (this way they can be brought back easily).
To permanently get rid of *.gmo file changes, I do
'git update-index --assume-unchanged po/*.gmo'
Guillaume
Ok, thanks again for that.
I also did, before attempting to compile on openbox, a "git fetch",
which the online documentation should have me up to date with what is
online.
As someone with willingness but no real knowledge, I think I'll start
using 'git update-index --assume-unchanged po/*.gmo' so that all testing
is done without any inadvertent changes by me.
bruce
