Re: Crash in File-Open

[Scott Kostyshak]

On Tue, Mar 21, 2017 at 11:54:56PM +0100, Kornel Benko wrote:
> Am Dienstag, 21. März 2017 um 18:33:07, schrieb Scott Kostyshak 
> 
> > On Tue, Mar 21, 2017 at 05:14:59PM +0100, Kornel Benko wrote:
> > 
> > > I could send you my lyx-executable.
> > 
> > That could give some clues. Should we build .deb packages and trade?
> > 
> > Scott
> 
> I always build a deb package. 27MB. I would upload if I would know to where.

I put mine on Dropbox:

https://www.dropbox.com/s/vepdw4pai0ohlxt/lyx23-2.3.0-49141git-Linux.deb?dl=0

The sig is attached.

SHA256 is:
6700eab25a24f9a82445678ccf855f91716f08906743ecb7bad4808124601d35

Scott


lyx23-2.3.0-49141git-Linux.deb.sig
Description: Binary data


signature.asc
Description: PGP signature

Re: Crash in File-Open

[Kornel Benko]

Am Dienstag, 21. März 2017 um 18:33:07, schrieb Scott Kostyshak 

> On Tue, Mar 21, 2017 at 05:14:59PM +0100, Kornel Benko wrote:
> 
> > I could send you my lyx-executable.
> 
> That could give some clues. Should we build .deb packages and trade?
> 
> Scott

I always build a deb package. 27MB. I would upload if I would know to where.

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: Some of CI jobs failed due to lack of disk space - now back to normal

[Scott Kostyshak]

On Tue, Mar 21, 2017 at 09:11:33PM +0100, Christian Ridderström wrote:
> On 21 March 2017 at 15:48, Scott Kostyshak  wrote:
> 
> > > If anyone's interested, you can see remaining disk space (_if logged in_)
> > > for the CI workers at this link:
> > >   https://ci.inria.fr/lyx/computer/
> >
> > Would it be possible and desirable to have an email sent to the
> > developers list if the free disk space is below e.g. 5 GB?
> 
> 
> E-mail notification would be ok, and probably useful.
> I had already into it a little, but oddly enough, I didn't find a
> ready-made plugin.
> 
> One of the core problems is related to our use of Docker images. When the
> "build image" runs, it creates files that doesn't belong to the standard
> user, 'ci'. I've solved this for the case when the build stage succeeds by
> running a second Docker image to 'chown' the workdir to user 'ci'. However,
> if the build stage fails, the 'chown' part is never executed.  This leads
> to old workdirs piling up, and Jenkins not being able to delete them.  Then
> I've gone in and manually deleted them.
> 
> Another core problem is that the CI workers only have about 20 GB each...
> and with a test job needing 4 GB, we can quickly run out of space. The
> solution is to make the CI worker have more space, and it should be
> possible to do this, I just haven't figured out how to mount the extra disk
> space yet.
> 
> I think I primarily want to make the CI workers have more disk space, as I
> think we in general would like to keep e.g. the workspace of the last
> successful build, and at the same time have more than five big CI jobs.
> 
> So I've started to look at making a CI worker with a bigger disk, and at
> the same time base it on the new Inria template that uses Ubuntu 16.04 LTS.
> /Christian

Sounds good, Christian. Thanks for all of your work on this.

Scott


signature.asc
Description: PGP signature

Re: Crash in File-Open

[Scott Kostyshak]

On Tue, Mar 21, 2017 at 05:14:59PM +0100, Kornel Benko wrote:

> I could send you my lyx-executable.

That could give some clues. Should we build .deb packages and trade?

Scott


signature.asc
Description: PGP signature

Re: Some of CI jobs failed due to lack of disk space - now back to normal

[Christian Ridderström]

On 21 March 2017 at 15:48, Scott Kostyshak  wrote:

> > If anyone's interested, you can see remaining disk space (_if logged in_)
> > for the CI workers at this link:
> >   https://ci.inria.fr/lyx/computer/
>
> Would it be possible and desirable to have an email sent to the
> developers list if the free disk space is below e.g. 5 GB?


E-mail notification would be ok, and probably useful.
I had already into it a little, but oddly enough, I didn't find a
ready-made plugin.

One of the core problems is related to our use of Docker images. When the
"build image" runs, it creates files that doesn't belong to the standard
user, 'ci'. I've solved this for the case when the build stage succeeds by
running a second Docker image to 'chown' the workdir to user 'ci'. However,
if the build stage fails, the 'chown' part is never executed.  This leads
to old workdirs piling up, and Jenkins not being able to delete them.  Then
I've gone in and manually deleted them.

Another core problem is that the CI workers only have about 20 GB each...
and with a test job needing 4 GB, we can quickly run out of space. The
solution is to make the CI worker have more space, and it should be
possible to do this, I just haven't figured out how to mount the extra disk
space yet.

I think I primarily want to make the CI workers have more disk space, as I
think we in general would like to keep e.g. the workspace of the last
successful build, and at the same time have more than five big CI jobs.

So I've started to look at making a CI worker with a bigger disk, and at
the same time base it on the new Inria template that uses Ubuntu 16.04 LTS.
/Christian

Re: Crash in File-Open

[Kornel Benko]

Am Dienstag, 21. März 2017 um 10:46:41, schrieb Scott Kostyshak 

> On Sat, Mar 18, 2017 at 12:23:10AM -0400, Scott Kostyshak wrote:
> > On Wed, Mar 15, 2017 at 03:47:31PM +0100, Kornel Benko wrote:
> 
> > > Scott, could you try to check if the binary-provided qt5.8 crashes on 
> > > your system?
> > 
> > Yes I will try this when I'm back to my testing computer (I'm currently
> > traveling).
> 
> I cannot reproduce with the pre-compiled binary for 5.8.
> 
> Attached is output from ldd after compiling with the pre-compiled
> binaries. Note that the path to the pre-compiled binaries for me is (the
> default): /home/scott/Qt/5.8. From what I understand, the output from
> ldd does show that LyX is using the pre-compiled binaries in ~/Qt and
> not my custom-compiled binaries.

My ldd output is lacking some of the libraries.
libexpat.so.1
libxcb-present.so.0
libxcb-sync.so.1
libxshmfence.so.1
libglapi.so.0
libXdamage.so.1
libXfixes.so.3
libX11-xcb.so.1
libxcb-glx.so.0
libxcb-dri2.so.0
libXxf86vm.so.1
libdrm.so.2

But all of them _are_ installed on my pc.

> I used qt-unified-linux-x64-online.run to install, and I selected all of
> the Qt 5.8 components (see attached), and left the default tools
> selected (I think Qt Creator).

Same here.

> I don't have many ideas with how to proceed. I was going to suggest you
> try 5.9.0alpha but there are no binaries for Qt's alphas.

I could send you my lyx-executable.

> You could install Ubuntu on a virtual box and then run the lyx-tester
> script that I use on it. And then instead of using system from the
> repositories (which is what lyx-tester does by default) you can just use
> the pre-compiled binary. I think it would not crash for you (since my
> system is very similar to the one created when running lyx-tester), and
> you could try to see what the difference is between your system and the
> virtual box.
> 
> Scott

Will see.

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: [LyX/master] Fix missing OutlinerName in simplecv

[Scott Kostyshak]

On Mon, Mar 20, 2017 at 12:13:15AM +0100, Guillaume Munch wrote:
> commit e5d26783393757d6da71362b11616638337124a4
> Author: Guillaume Munch 
> Date:   Mon Mar 20 00:12:30 2017 +0100
> 
> Fix missing OutlinerName in simplecv
> ---
>  lib/layouts/stdinsets.inc |4 
>  1 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/lib/layouts/stdinsets.inc b/lib/layouts/stdinsets.inc
> index 368cf60..981feb0 100644
> --- a/lib/layouts/stdinsets.inc
> +++ b/lib/layouts/stdinsets.inc
> @@ -473,6 +473,10 @@ InsetLayout Float
>   EndHTMLStyle
>  End
>  
> +#InsetWrap requires these, independently of whether stdfloats.inc is included
> +OutlinerName table"Tables" #no AddToToc (built-in)
> +OutlinerName figure   "Figures" #no AddToToc (built-in)

Now that we have a generalized way to add things to the outliner, should
we use that also for Tables and Figures instead of whatever built-in way
we do for Tables and Figures? Do I understand correctly that this would
have the extra advantage that the user could choose to not have them
show by editing a text file instead of recompiling?

Scott


signature.asc
Description: PGP signature

Re: Is this a valid .lyx file (created by 2.0.8.1)?

[Scott Kostyshak]

On Sun, Mar 19, 2017 at 12:38:49PM +, José Abílio Matos wrote:
> On Wednesday, 15 March 2017 19.06.07 WET Scott Kostyshak wrote:
> > Attached is a minimal example from here:
> > 
> > http://tex.stackexchange.com/questions/358326/my-font-shows-up-in-the-font-l
> > ist-but-the-document-wont-compile
> > 
> > It was created with 2.0.8.1.
> > 
> > When I open it in 2.1.0 or 2.2.x I get:
> > 
> > Warning: Malformed LyX document: Can't find \use_mathdots.
> > Warning: Malformed LyX document: Missing \suppress_date.
> > Warning: Malformed LyX document: Can't find \use_package.
> > Warning: Malformed LyX document: Can't find \use_package amsmath.
> > Warning: Malformed LyX document: Can't find \use_package.
> > Warning: Malformed LyX document: Can't find \use_package.
> > Warning: Malformed LyX document: Can't find \use_package.
> > Warning: Malformed LyX document: No \font_sf_scale!
> > Warning: Malformed LyX document: No \font_tt_scale!
> > 
> > Is the document indeed malformed or is there possibly a bug in lyx2lyx?
> > 
> > Scott
> 
> As Enrico said usually lyx generated files have a larger header. So if this 
> file has been produced by lyx it is not in its pristine form.
> 
> With that said we could probably improve the warnings.
> 
> One example is when there is a new file format change that introduces new 
> header elements. The corresponding lyx2lyx change should add those headers 
> with the default values. I am not sure that we do this for all those cases.
> 
> What happens when lyx reads a file where those headers are not present is to 
> assume the default values. It happens sometimes that we change the default 
> values between major versions, a file that has the headers set is immune to 
> the change in the default values because those only apply to new files.
> 
> One other problem with labeling this files as malformed is that there are 
> several levels of malformed, from the the minor warning to the case where lyx 
> is not able to read the file.
> 
> OK, that is all for the little rambling that I had one this issue. Thanks for 
> reading it. :-)

Good thoughts. Once I realize that a file seems malformed, I just move
on. But you are right to think about how can we minimize the damage.

Scott


signature.asc
Description: PGP signature

Re: Some of CI jobs failed due to lack of disk space - now back to normal

[Scott Kostyshak]

On Sun, Mar 19, 2017 at 10:59:53PM +0100, Christian Ridderström wrote:
> Hi,
> 
> Just want to let you know that some of the CI jobs simply failed because
> the CI workers ran out of disk space. Some CI jobs take 4 GB, and with no
> remaining workdirs from CI jobs, the total disk space per slave is about 20
> GB. Anyway, I've done some cleaning and this aspect should be back to
> normal now.
> 
> If anyone's interested, you can see remaining disk space (_if logged in_)
> for the CI workers at this link:
>   https://ci.inria.fr/lyx/computer/

Would it be possible and desirable to have an email sent to the
developers list if the free disk space is below e.g. 5 GB?

By the way, thanks for all of this work Christian. CI testing is a great
step forward!

Scott


signature.asc
Description: PGP signature

Re: Crash in File-Open

[Scott Kostyshak]

On Sat, Mar 18, 2017 at 12:23:10AM -0400, Scott Kostyshak wrote:
> On Wed, Mar 15, 2017 at 03:47:31PM +0100, Kornel Benko wrote:

> > Scott, could you try to check if the binary-provided qt5.8 crashes on your 
> > system?
> 
> Yes I will try this when I'm back to my testing computer (I'm currently
> traveling).

I cannot reproduce with the pre-compiled binary for 5.8.

Attached is output from ldd after compiling with the pre-compiled
binaries. Note that the path to the pre-compiled binaries for me is (the
default): /home/scott/Qt/5.8. From what I understand, the output from
ldd does show that LyX is using the pre-compiled binaries in ~/Qt and
not my custom-compiled binaries.

I used qt-unified-linux-x64-online.run to install, and I selected all of
the Qt 5.8 components (see attached), and left the default tools
selected (I think Qt Creator).

I don't have many ideas with how to proceed. I was going to suggest you
try 5.9.0alpha but there are no binaries for Qt's alphas.

You could install Ubuntu on a virtual box and then run the lyx-tester
script that I use on it. And then instead of using system from the
repositories (which is what lyx-tester does by default) you can just use
the pre-compiled binary. I think it would not crash for you (since my
system is very similar to the one created when running lyx-tester), and
you could try to see what the difference is between your system and the
virtual box.

Scott
scott@kd:~/lyxbuilds/masterQt58/CMakeBuild/bin$ ldd lyx
linux-vdso.so.1 =>  (0x7fff483f4000)
libQt5X11Extras.so.5 => 
/home/scott/Qt/5.8/gcc_64/lib/libQt5X11Extras.so.5 (0x7f741ac3)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 
(0x7f741a9df000)
libhunspell-1.3.so.0 => /usr/lib/x86_64-linux-gnu/libhunspell-1.3.so.0 
(0x7f741a78c000)
libenchant.so.1 => /usr/lib/x86_64-linux-gnu/libenchant.so.1 
(0x7f741a58)
libmagic.so.1 => /usr/lib/x86_64-linux-gnu/libmagic.so.1 
(0x7f741a36)
libQt5Concurrent.so.5 => 
/home/scott/Qt/5.8/gcc_64/lib/libQt5Concurrent.so.5 (0x7f741a158000)
libQt5Svg.so.5 => /home/scott/Qt/5.8/gcc_64/lib/libQt5Svg.so.5 
(0x7f7419f05000)
libQt5Widgets.so.5 => /home/scott/Qt/5.8/gcc_64/lib/libQt5Widgets.so.5 
(0x7f74196d4000)
libQt5Gui.so.5 => /home/scott/Qt/5.8/gcc_64/lib/libQt5Gui.so.5 
(0x7f7418f38000)
libQt5Core.so.5 => /home/scott/Qt/5.8/gcc_64/lib/libQt5Core.so.5 
(0x7f7418818000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f74185fe000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f741827b000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f7417f72000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f7417d5c000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f7417992000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f7417775000)
libGL.so.1 => /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1 
(0x7f7417501000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 
(0x7f74172fc000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 
(0x7f74170f6000)
libgmodule-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0 
(0x7f7416ef2000)
libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 
(0x7f7416be)
libicui18n.so.56 => /home/scott/Qt/5.8/gcc_64/lib/libicui18n.so.56 
(0x7f7416747000)
libicuuc.so.56 => /home/scott/Qt/5.8/gcc_64/lib/libicuuc.so.56 
(0x7f741638e000)
libicudata.so.56 => /home/scott/Qt/5.8/gcc_64/lib/libicudata.so.56 
(0x7f74149ab000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f74147a7000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f741459e000)
libgthread-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgthread-2.0.so.0 
(0x7f741439c000)
/lib64/ld-linux-x86-64.so.2 (0x561bb1aa4000)
libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 
(0x7f7414172000)
libxcb-dri3.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri3.so.0 
(0x7f7413f6f000)
libxcb-present.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-present.so.0 
(0x7f7413d6c000)
libxcb-sync.so.1 => /usr/lib/x86_64-linux-gnu/libxcb-sync.so.1 
(0x7f7413b64000)
libxshmfence.so.1 => /usr/lib/x86_64-linux-gnu/libxshmfence.so.1 
(0x7f7413961000)
libglapi.so.0 => /usr/lib/x86_64-linux-gnu/libglapi.so.0 
(0x7f7413732000)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 
(0x7f741351f000)
libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1 
(0x7f741331c000)
libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 
(0x7f7413116000)
libX11-xcb.so.1 => /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1 
(0x7f7412f13000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 

Re: [LyX/master] Fix output of en- and em-dashes with TeX fonts

[Jürgen Spitzmüller]

2017-03-21 11:06 GMT+01:00 José Abílio Matos :

> On Tuesday, 21 March 2017 09.26.39 WET Jürgen Spitzmüller wrote:
> >
> > I am not sure I understand. The default setting of \dynamic_quotes is
> > "false", which is equal to the case when the param is missing.
> >
> > Jürgen
>
> That was the subject of my rambling on Sunday and something that I have
> been
> trying to enforce in 2.3, but that I have clearly no communicated properly.
> :-)
>
> You are right if you compare the output for lyx-2.3.
>
> My problem is a different one. Suppose that a document that you created
> with
> lyx 2.2 is not touched with lyx 2.3 but later opened with a later version.
> Suppose also that in after 2.3 we decide to change the default setting of
> \dynamic_quotes to "true".
>

In that case, I would ensure that old documents (with no \dynamic_quotes
header) get the correct value, i.e. "false".

I mean, if we would decide that the default value is true, we would have to
assure that the header is always output for new documents (no header would
still mean "false").

But I see what you mean in the sense of "more transparent file format".

Jürgen

Build failed in Jenkins: Build branch "master" » ubuntu-xenial-qt4-autotools-extended #114

[ci-lyx]

https://ci.inria.fr/lyx/job/build-master-head/job/ubuntu-xenial-qt4-autotools-extended/114/Changes:

[spitz] Correct FORMAT documentation

--
[...truncated 1121 lines...]
  CXX  insets/InsetGraphicsParams.o
  CXX  insets/InsetGraphics.o
  CXX  insets/InsetHyperlink.o
  CXX  insets/InsetInclude.o
  CXX  insets/InsetIndex.o
  CXX  insets/InsetInfo.o
  CXX  insets/InsetIPA.o
  CXX  insets/InsetIPAMacro.o
  CXX  insets/InsetLabel.o
  CXX  insets/InsetLayout.o
  CXX  insets/InsetLine.o
  CXX  insets/InsetListings.o
  CXX  insets/InsetListingsParams.o
  CXX  insets/InsetMarginal.o
  CXX  insets/InsetNewline.o
  CXX  insets/InsetNewpage.o
  CXX  insets/InsetNomencl.o
  CXX  insets/InsetNote.o
  CXX  insets/InsetPhantom.o
  CXX  insets/InsetPreview.o
  CXX  insets/InsetQuotes.o
  CXX  insets/InsetRef.o
  CXX  insets/InsetScript.o
  CXX  insets/InsetSeparator.o
  CXX  insets/InsetSpace.o
  CXX  insets/InsetSpecialChar.o
  CXX  insets/InsetTabular.o
  CXX  insets/InsetText.o
  CXX  insets/InsetTOC.o
  CXX  insets/InsetVSpace.o
  CXX  insets/InsetWrap.o
  AR   liblyxinsets.a
  CXX  main.o
  CXX  BiblioInfo.o
  CXX  Box.o
  CXX  Compare.o
  CXX  Dimension.o
  CXX  EnchantChecker.o
  CXX  PersonalWordList.o
  CXX  LaTeXFonts.o
  CXX  PrinterParams.o
  CXX  Thesaurus.o
  CXXLDlyx
make[4]: Leaving directory '/build/workspace/src'
Making all in client
make[4]: Entering directory '/build/workspace/src/client'
make  all-am
make[5]: Entering directory '/build/workspace/src/client'
  CXX  boost.o
  CXX  client.o
  CXXLDlyxclient
make[5]: Leaving directory '/build/workspace/src/client'
make[4]: Leaving directory '/build/workspace/src/client'
Making all in tex2lyx
make[4]: Entering directory '/build/workspace/src/tex2lyx'
  CXX  boost.o
  CXX  Context.o
  CXX  dummy_impl.o
  CXX  math.o
  CXX  Parser.o
  CXX  Preamble.o
  CXX  table.o
  CXX  tex2lyx.o
  CXX  text.o
  CXXLDtex2lyx
make[4]: Leaving directory '/build/workspace/src/tex2lyx'
make[3]: Leaving directory '/build/workspace/src'
make[2]: Leaving directory '/build/workspace/src'
Making all in sourcedoc
make[2]: Entering directory '/build/workspace/sourcedoc'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory '/build/workspace/sourcedoc'
Making all in lib
make[2]: Entering directory '/build/workspace/lib'
Making all in doc
make[3]: Entering directory '/build/workspace/lib/doc'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/build/workspace/lib/doc'
Making all in lyx2lyx
make[3]: Entering directory '/build/workspace/lib/lyx2lyx'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/build/workspace/lib/lyx2lyx'
make[3]: Entering directory '/build/workspace/lib'
  GEN  lyx.desktop
  GEN  lyx.png
  GEN  lyx.svg
make[3]: Leaving directory '/build/workspace/lib'
make[2]: Leaving directory '/build/workspace/lib'
Making all in src/client
make[2]: Entering directory '/build/workspace/src/client'
make  all-am
make[3]: Entering directory '/build/workspace/src/client'
make[3]: Nothing to be done for 'all-am'.
make[3]: Leaving directory '/build/workspace/src/client'
make[2]: Leaving directory '/build/workspace/src/client'
Making all in src/tex2lyx
make[2]: Entering directory '/build/workspace/src/tex2lyx'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory '/build/workspace/src/tex2lyx'
make[2]: Entering directory '/build/workspace'
make[2]: Leaving directory '/build/workspace'
make[1]: Leaving directory '/build/workspace'
# Executing: make check
Making check in autotests
make[1]: Entering directory '/build/workspace/autotests'
make[1]: Nothing to be done for 'check'.
make[1]: Leaving directory '/build/workspace/autotests'
Making check in config
make[1]: Entering directory '/build/workspace/config'
make[1]: Nothing to be done for 'check'.
make[1]: Leaving directory '/build/workspace/config'
Making check in development
make[1]: Entering directory '/build/workspace/development'
make[2]: Entering directory '/build/workspace/development'
make[2]: Nothing to be done for 'check-am'.
make[2]: Leaving directory '/build/workspace/development'
make[1]: Leaving directory '/build/workspace/development'
Making check in po
make[1]: Entering directory '/build/workspace/po'
make[1]: Nothing to be done for 'check'.
make[1]: Leaving directory '/build/workspace/po'
Making check in 3rdparty
make[1]: Entering directory '/build/workspace/3rdparty'
make[2]: Entering directory '/build/workspace/3rdparty'
make[2]: Nothing to be done for 'check-am'.
make[2]: Leaving directory '/build/workspace/3rdparty'
make[1]: Leaving directory '/build/workspace/3rdparty'
Making check in src
make[1]: Entering directory '/build/workspace/src'
rm -f hash-temp \
@echo "  GEN  

Re: [LyX/master] Fix output of en- and em-dashes with TeX fonts

[José Abílio Matos]

On Tuesday, 21 March 2017 09.26.39 WET Jürgen Spitzmüller wrote:
> 
> I am not sure I understand. The default setting of \dynamic_quotes is
> "false", which is equal to the case when the param is missing.
> 
> Jürgen

That was the subject of my rambling on Sunday and something that I have been 
trying to enforce in 2.3, but that I have clearly no communicated properly. 
:-)

You are right if you compare the output for lyx-2.3.

My problem is a different one. Suppose that a document that you created with 
lyx 2.2 is not touched with lyx 2.3 but later opened with a later version. 
Suppose also that in after 2.3 we decide to change the default setting of 
\dynamic_quotes to "true".

So now depending on the conversion path we will get two different documents 
(with a possibly different output):

Case 1:
 * open the original document in lyx 2.3, do not change any of its content but 
make it dirty in order to be able to save it;
 * open that saved document with a later lyx version.

Case 2:
 * open the original document directly with the later version.


Honestly most of the time there will not be any difference between the two 
scenarios. My problem is that when there is a difference it could be very 
difficult to catch.


So what I am proposing is a stricter implementation of a new file format. In 
the case where a new header property is added the lyx2lyx associated changes 
already has in the reversion step a moment where the property is removed from 
the header. I propose that as much as possible you should ensure that in the 
conversion step the properties should be added to the header with the default 
value.

The ideal case would be a new test where for each new file format we a have a 
set of tests where we take a document (with the User's Guide being the best 
candidate), convert it with lyx2lyx to the new file format, load it to lyx 
forcing a save and compare the difference. Ideally there should not be any 
difference between the two versions.

I hope that this makes sense. :-)

Regards,
-- 
José Abílio

Re: System for continuous integration (CI) of LyX master branch, compiled on Ubuntu

[Jean-Marc Lasgouttes]

I have done this patch on 12.04. Downloading and installing automake is not 
that difficult

JMarc

Le 21 mars 2017 06:59:59 GMT+01:00, Pavel Sanda  a écrit :.
>
>Right :) As said, I don't have strong opinion about dropping support
>for older stuff (basically ubuntu 12.04, which accidentally eols now)
>but don't expect me to bisect or help with any distclean issues
>anymore,
>because that's the only machine where I have 32 cores...
>
>Pavel

Re: [LyX/master] Nonsense for whoever insists on using gcc4.6 & qt4.8 in 2017

[Pavel Sanda]

Guillaume MM wrote:
>> So without touching this, do you see easy way how to trigger some signal
>> which would issue loading all images in the document, not just on the
>> screen.  I could just call such lfun and let lyx work in backgrounds without
>> managing it for 5min; even that would be relief...
>
> No, not really familiar with this. But it would be achieved by computing the
> metrics of the whole document. Such an LFUN will also be useful for making
> the scroll bar accurate, would it not?

Maybe I understand this part of the code even less than you do :)
Pavel

Re: System for continuous integration (CI) of LyX master branch, compiled on Ubuntu

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
> OK, would somebody object to requiring automake 1.14 (and thus autoconf 
> 2.65) in master? This only hits the old timers who also compile directly 
> from git (not people using the tar.gz distribution). Of course it does not 
> chnage anything for users.
>
> Pavel, I suspect that you are the only one besides me who would be 
> affected.

Right :) As said, I don't have strong opinion about dropping support
for older stuff (basically ubuntu 12.04, which accidentally eols now)
but don't expect me to bisect or help with any distclean issues anymore,
because that's the only machine where I have 32 cores...

Pavel