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

[ci-lyx]

https://ci.inria.fr/lyx/job/build-master-head/job/ubuntu-xenial-qt4-autotools-extended/812/--
[...truncated 219 lines...]
Receiving objects:  29% (9637/32615), 35.87 MiB | 2.32 MiB/s   
Receiving objects:  29% (9784/32615), 37.47 MiB | 2.22 MiB/s   
Receiving objects:  30% (9785/32615), 37.47 MiB | 2.22 MiB/s   
Receiving objects:  31% (10111/32615), 37.47 MiB | 2.22 MiB/s   
Receiving objects:  32% (10437/32615), 37.47 MiB | 2.22 MiB/s   
Receiving objects:  32% (10701/32615), 38.56 MiB | 2.45 MiB/s   
Receiving objects:  33% (10763/32615), 38.97 MiB | 2.16 MiB/s   
Receiving objects:  34% (11090/32615), 38.97 MiB | 2.16 MiB/s   
Receiving objects:  35% (11416/32615), 38.97 MiB | 2.16 MiB/s   
Receiving objects:  36% (11742/32615), 38.97 MiB | 2.16 MiB/s   
Receiving objects:  36% (11777/32615), 41.62 MiB | 1.90 MiB/s   
Receiving objects:  37% (12068/32615), 41.62 MiB | 1.90 MiB/s   
Receiving objects:  37% (12360/32615), 41.62 MiB | 1.90 MiB/s   
Receiving objects:  38% (12394/32615), 41.62 MiB | 1.90 MiB/s   
Receiving objects:  39% (12720/32615), 43.18 MiB | 1.87 MiB/s   
Receiving objects:  40% (13046/32615), 43.18 MiB | 1.87 MiB/s   
Receiving objects:  41% (13373/32615), 43.18 MiB | 1.87 MiB/s   
Receiving objects:  42% (13699/32615), 43.18 MiB | 1.87 MiB/s   
Receiving objects:  42% (13874/32615), 45.21 MiB | 2.01 MiB/s   
Receiving objects:  43% (14025/32615), 46.01 MiB | 1.99 MiB/s   
Receiving objects:  44% (14351/32615), 47.01 MiB | 2.00 MiB/s   
Receiving objects:  45% (14677/32615), 47.01 MiB | 2.00 MiB/s   
Receiving objects:  46% (15003/32615), 47.01 MiB | 2.00 MiB/s   
Receiving objects:  47% (15330/32615), 47.01 MiB | 2.00 MiB/s   
Receiving objects:  47% (15558/32615), 47.01 MiB | 2.00 MiB/s   
Receiving objects:  47% (15576/32615), 48.25 MiB | 1.91 MiB/s   
Receiving objects:  47% (15594/32615), 49.18 MiB | 1.58 MiB/s   
Receiving objects:  47% (15620/32615), 50.10 MiB | 1.47 MiB/s   
Receiving objects:  48% (15656/32615), 51.02 MiB | 1.07 MiB/s   
Receiving objects:  49% (15982/32615), 51.02 MiB | 1.07 MiB/s   
Receiving objects:  50% (16308/32615), 51.02 MiB | 1.07 MiB/s   
Receiving objects:  50% (16469/32615), 51.02 MiB | 1.07 MiB/s   
Receiving objects:  51% (16634/32615), 51.02 MiB | 1.07 MiB/s   
Receiving objects:  52% (16960/32615), 51.02 MiB | 1.07 MiB/s   
Receiving objects:  52% (17136/32615), 54.04 MiB | 1.32 MiB/s   
Receiving objects:  53% (17286/32615), 54.04 MiB | 1.32 MiB/s   
Receiving objects:  53% (17597/32615), 56.41 MiB | 1.66 MiB/s   
Receiving objects:  54% (17613/32615), 56.41 MiB | 1.66 MiB/s   
Receiving objects:  55% (17939/32615), 57.30 MiB | 1.77 MiB/s   
Receiving objects:  56% (18265/32615), 57.30 MiB | 1.77 MiB/s   
Receiving objects:  57% (18591/32615), 57.30 MiB | 1.77 MiB/s   
Receiving objects:  58% (18917/32615), 57.30 MiB | 1.77 MiB/s   
Receiving objects:  58% (18956/32615), 59.45 MiB | 2.14 MiB/s   
Receiving objects:  59% (19243/32615), 61.24 MiB | 2.43 MiB/s   
Receiving objects:  59% (19426/32615), 62.30 MiB | 2.56 MiB/s   
Receiving objects:  59% (19555/32615), 63.47 MiB | 2.43 MiB/s   
Receiving objects:  60% (19569/32615), 64.07 MiB | 2.17 MiB/s   
Receiving objects:  61% (19896/32615), 64.07 MiB | 2.17 MiB/s   
Receiving objects:  62% (20222/32615), 64.07 MiB | 2.17 MiB/s   
Receiving objects:  62% (20318/32615), 64.92 MiB | 1.99 MiB/s   
Receiving objects:  63% (20548/32615), 65.69 MiB | 2.01 MiB/s   
Receiving objects:  63% (20853/32615), 66.59 MiB | 1.99 MiB/s   
Receiving objects:  63% (20869/32615), 67.01 MiB | 1.60 MiB/s   
Receiving objects:  64% (20874/32615), 67.54 MiB | 1.34 MiB/s   
Receiving objects:  64% (20887/32615), 67.89 MiB | 1.19 MiB/s   
Receiving objects:  65% (21200/32615), 68.32 MiB | 1.14 MiB/s   
Receiving objects:  66% (21526/32615), 68.32 MiB | 1.14 MiB/s   
Receiving objects:  67% (21853/32615), 68.32 MiB | 1.14 MiB/s   
Receiving objects:  68% (22179/32615), 68.32 MiB | 1.14 MiB/s   
Receiving objects:  69% (22505/32615), 68.32 MiB | 1.14 MiB/s   
Receiving objects:  70% (22831/32615), 68.32 MiB | 1.14 MiB/s   
Receiving objects:  71% (23157/32615), 68.32 MiB | 1.14 MiB/s   
Receiving objects:  72% (23483/32615), 68.32 MiB | 1.14 MiB/s   
Receiving objects:  72% (23801/32615), 70.24 MiB | 1.44 MiB/s   
Receiving objects:  73% (23809/32615), 71.75 MiB | 1.63 MiB/s   
Receiving objects:  74% (24136/32615), 73.20 MiB | 1.75 MiB/s   
Receiving objects:  75% (24462/32615), 73.20 MiB | 1.75 MiB/s   
Receiving objects:  76% (24788/32615), 73.20 MiB | 1.75 MiB/s   
Receiving objects:  77% (25114/32615), 73.20 MiB | 1.75 MiB/s   
Receiving objects:  77% (25387/32615), 73.20 MiB | 1.75 MiB/s   
Receiving objects:  78% (25440/32615), 73.20 MiB | 1.75 MiB/s   
Receiving objects:  79% (25766/32615), 73.20 MiB | 1.75 MiB/s   
Receiving objects:  80% (26092/32615), 74.95 MiB | 1.96 MiB/s   
Receiving objects:  81% (26419/32615), 74.95 MiB | 1.96 MiB/s   
Receiving objects:  82% (26745

Re: [LyX/master] Fix the implementation of new libertine package

[Richard Heck]

On 03/06/2018 02:01 AM, Jürgen Spitzmüller wrote:
> Am Samstag, den 03.03.2018, 08:29 +0100 schrieb Jürgen Spitzmüller:
>> Am Freitag, den 02.03.2018, 12:18 +0100 schrieb Juergen Spitzmueller:
>>> commit 905516fd706a90148a458f9936c565cbe5fcfcff
>>> Author: Juergen Spitzmueller
>>> Date:   Fri Mar 2 12:17:33 2018 +0100
>>>
>>> Fix the implementation of new libertine package
>>> 
>>> Needs to go to 2.3.1-staging
>> Jürgen
> Richard, did you see this?

Apparently not. Go ahead

rh




signature.asc
Description: OpenPGP digital signature

Re: Solution: Summary for the Win installer problem

[Jean-Marc Lasgouttes]

Le 06/03/2018 à 14:44, Uwe Stöhr a écrit :
Here is my last attempt to explain the situation. Then I will be quiet 
because I already invested now about 20 hours in nothing else than this.


The goal is definitely not that you become quiet, which would mean "This 
is my last word. Either you accept my solution or you have no windows 
installer".



Here are the principal use cases for LyX users:

A: I am a happy user of LyX 2.2.x and are not interested to upgrade 
anything. If I get now a document from a colleague containing a LaTeX 
package I don't have yet installed, MiKTeX detects it when you compile 
the document. To be able to install the missing package, it needs to 
update its package handling system. 


What if the user set "Install missing packages on the fly: never"? Do 
you still insist that this user should have to do a double update that 
was explicitly opted-out?


As I understand it, the installer sets installation of packages to 
"automatic" by default (it is _not_ the miktex default), but does 
respect the setting "no" that the user may have set.


It should be at least possible not to do any update if the user 
explicitly said "no" to updates.


What is not clear to me is why we change the default update mechanism. 
Miktex documentation explicitly recommends to use the Miktex Console to 
get updates, and does not set the update mechanism to automatic.


Reality is not what we wish. LyX users want to get an output of the 
documents. To get this, third-party programs are necessary like 
ImageMagick, Python, LaTeX, Ghostscript etc. If a third-party program 
has a bug, LyX users don't get an output.


This is why we should not change a system that works, in case it breaks 
the program. If my TeX installation breaks when upgrading to the new 
Ubuntu Clunky Coyote, I can accept that. I am prepared to it because I 
am updating my system.


If TeX breaks because I am typesetting a document, then it is happening 
at the worst possible time. I _do_ need LyX not to break at this 
particular time.


At last a personal statement: I read in the discussions from time to 
time that some are not familiar with Windows but nevertheless they state 
what is right or wrong in their opinion. That is no base for a 
discussion.


I started with Windows 2.0, then 3.0, 3.1, etc. up to windows 10 (OK, I 
skipped a few). These days I use windows 7 and windows 10 on a 
daily/weekly basis. Do I qualify?


Either invest time to try it out on Windows on your own or 
trust me and the MiKTeX developer. I have other things to do on a sunny 
day than to sit at home like a nerd with 3 different PCs to test 
different installations, update states etc. to find a solution.


I understand how frustrating the thing can be. But working alone on this 
is probably the source of many issues. It is never good to have an own 
niche where only one voice counts. We are a team, and this is where our 
strength comes from.


I also miss the view on what users need the most: a LyX that just works 
with all its features. They don't want to learn what a package is, how 
it is handled, what the cryptic package names like "marvosym" stand for, 
what packages LyX needs for what feature etc. 


Well, the OS of choice of elegant people is macOS and you cannot argue 
that they do not care that thing do not "just work". Yet, they install 
MacTeX, which come in only one size (3G), maybe the 500M of extras if 
they are very fussy and they are happy with it. It does not update, but 
once a year one can install a new one.


Are these people so different to what you describe as windows users? We 
are not talking about children here.


As user I need a system 
with which I can just write my text and focus on that.


Yes, and the key to that is not to update a running system too often.

If I like e.g. to 
wavy underline some words, I just want to do this and not to get cryptic 
error messages that a package is not available. How should I know that 
the missing package is necessary because of my wavy underline?



People who use wavy underlines deserve whatever happen ;)


JMarc

Re: tex2lyx no longer compilable because of too many nested ifs

[Jean-Marc Lasgouttes]

Le 06/03/2018 à 15:16, Jürgen Spitzmüller a écrit :
2018-03-06 15:00 GMT+01:00 Jean-Marc Lasgouttes >:


Le 05/03/2018 à 09:13, Jürgen Spitzmüller a écrit :
Do you have an idea of what is the cost in terms of performance? I
remember Georg stating that tex2lyx is slow on big documents.


I didn't check, no. But it should be faster, I think, since it does not 
have to cycle through all conditions.


I did not realize you added `continue' statements. So it should be 
equivalent to the old code, I guess.


JMarc

Re: tex2lyx no longer compilable because of too many nested ifs

[Jürgen Spitzmüller]

2018-03-06 15:00 GMT+01:00 Jean-Marc Lasgouttes :

> Le 05/03/2018 à 09:13, Jürgen Spitzmüller a écrit :
> Do you have an idea of what is the cost in terms of performance? I
> remember Georg stating that tex2lyx is slow on big documents.
>

I didn't check, no. But it should be faster, I think, since it does not
have to cycle through all conditions.

Jürgen


>
> JMarc
>

Re: tex2lyx no longer compilable because of too many nested ifs

[Jean-Marc Lasgouttes]

Le 05/03/2018 à 09:13, Jürgen Spitzmüller a écrit :

Am Sonntag, den 04.03.2018, 21:51 +0100 schrieb Uwe Stöhr:

tex2lyx in master is no longer compilable with MSVC. The reason is
that
we have now too many else if clauses in text.cpp:


Should be fixed.


Do you have an idea of what is the cost in terms of performance? I 
remember Georg stating that tex2lyx is slow on big documents.


JMarc

Re: Solution: Summary for the Win installer problem

[Uwe Stöhr]

Am 06.03.2018 um 04:47 schrieb Richard Heck:


What? So I should deliver a LyX installer leading to a broken LaTeX
that can only be fixed by reinstalling MiKTeX? That cannot be the goal!


The proposal is to *abort* the LyX installation, if the user does not
want to update. You can explain in a dialog that LyX will not work
otherwise. But you cannot screw with their system without their
permission. Really.


Here is my last attempt to explain the situation. Then I will be quiet 
because I already invested now about 20 hours in nothing else than this.


Who is affected by the following?:
- most users having either installed MiKTeX the first time between 
October and maybe mid January this year (independent if LyX was 
installed too)
- many users who use MiKTeX and updated it in the time between October 
and maybe mid January. They might run an update on their own or they 
compiled a LyX file using a missing package.



Here are the principal use cases for LyX users:

A: I am a happy user of LyX 2.2.x and are not interested to upgrade 
anything. If I get now a document from a colleague containing a LaTeX 
package I don't have yet installed, MiKTeX detects it when you compile 
the document. To be able to install the missing package, it needs to 
update its package handling system. Due to a bug this update can break 
LaTeX completely and the user is lost. None of his LyX document will be 
compilable anymore. The only solution for him is to reinstall MiKTeX and 
he looses all his personal settings, packages, BibTeX style files etc. 
and need to set them up again.
Most users don't care about the system behind LyX, they just see that 
their LyX doesn't work anymore.


B: I want to try out LyX 2.3.0. The installer tells me that I must 
upgrade MiKTeX but I deny this. When LyX is started the first time after 
the installation, it runs configure.py which in turn executes 
chklatex.ltx. This triggers MiKTeX to check for packages, missing 
packages will be installed, mf-files of fonts will be created etc. To be 
able to do this, MiKTeX will update its package handling system. The 
result is the same as for use case A.


C: I want to try out LyX 2.3.0. and use version 3 of the LyX for Windows 
installer. The installer forces an update of the package handling system 
at the right step and at this step it has the chance to repair a broken 
MiKTeX system and will do so. This solution was developed by the MiKTeX 
developer. As result, I get a fully functional LyX, all my personal 
MiKTeX settings, packages etc. will be kept.


If this doesn't make the situation clear, I give up.


> The point is that we do not affect people's systems without permission.
> Otherwise, we get reports like
>  https://latex.org/forum/viewtopic.php?f=19&t=30919
> which is unacceptable.

Why are you claiming that the Win installer is to blame here? These 
claims are annoying.
At first the LyX installer available in January did not update MiKTeX if 
you don't want to. The problem described by the bug report is that he 
uses 2 different MiKTeX installations the same time, one is set up for 
all users, one only for the current user. Therefore they interfere. 
Maybe he installed winedt only for the current user and LyX for all 
users or the opposite. Hard to say, but of course if you have set up 
MiKTeX for all users you cannot overwrite its settings for the current 
user with another instance of MiKTeX without getting problems.


> As Scott said some time ago, it is very strange indeed if LyX's basic
> functionality breaks because of a change in some external program's
> package-handling mechanism. LyX should not be that entwined with
> external programs.

Reality is not what we wish. LyX users want to get an output of the 
documents. To get this, third-party programs are necessary like 
ImageMagick, Python, LaTeX, Ghostscript etc. If a third-party program 
has a bug, LyX users don't get an output. This happens from time to 
time. In the past there were e.g. often issues with ImageMagick and now 
we have a severe bug in MiKTeX. In most cases you are not involved 
because if there is for example a bug in a third-party program I just 
release a new installer with a version of the third-party program that 
is known to work.


-

At last a personal statement: I read in the discussions from time to 
time that some are not familiar with Windows but nevertheless they state 
what is right or wrong in their opinion. That is no base for a 
discussion. Either invest time to try it out on Windows on your own or 
trust me and the MiKTeX developer. I have other things to do on a sunny 
day than to sit at home like a nerd with 3 different PCs to test 
different installations, update states etc. to find a solution.


I also miss the view on what users need the most: a LyX that just works 
with all its features. They don't want to learn what a package is, how 
it is handled, what the cryptic package names like "marvosym" stand for, 
what

Re: [LyX/2.3.2-staging] status.23x: mention the new biblatex support in tex2lyx

[Jürgen Spitzmüller]

2018-03-06 13:52 GMT+01:00 Uwe Stöhr :

> commit 150fb89e22742dcf1f61500b498bc9e7e2a7702c
> Author: Uwe Stöhr 
> Date:   Tue Mar 6 13:52:42 2018 +0100
>
> status.23x: mention the new biblatex support in tex2lyx
>

I actually added an note (further down). There is no need to specify it
more than that, so please remove these notes again.

Jürgen

Re: tex2lyx no longer compilable because of too many nested ifs

[Uwe Stöhr]

Am 05.03.2018 um 09:13 schrieb Jürgen Spitzmüller:


Am Sonntag, den 04.03.2018, 21:51 +0100 schrieb Uwe Stöhr:

tex2lyx in master is no longer compilable with MSVC. The reason is
that
we have now too many else if clauses in text.cpp:


Should be fixed.


Many thanks! Your solution is surprisingly straight forward.

Now I can have a look and add some more things to tex2lyx when I find time.

best regards
Uwe