Build failed in Jenkins: Build branch "master" » ubuntu-latest-qt5-cmake #316

[ci-lyx]

https://ci.inria.fr/lyx/job/build-master-head/job/ubuntu-latest-qt5-cmake/316/--
[...truncated 439 lines...]
[  2%] Generating gl/Tutorial.lyx
cd /build/lyx/build/doc && /usr/bin/python2 
/build/lyx/development/cmake/doc/ReplaceValues.py 
LYX_USERDIR_VER=LYX_USERDIR_23x LYX_DIR_VER=LYX_DIR_23x \origin\ 
unavailable=\origin\ /systemlyxdir/doc/gl /build/lyx/lib/doc/gl/Tutorial.lyx > 
/build/lyx/build/doc/gl/Tutorial.lyx
[  2%] Generating hu/Intro.lyx
cd /build/lyx/build/doc && /usr/bin/python2 
/build/lyx/development/cmake/doc/ReplaceValues.py 
LYX_USERDIR_VER=LYX_USERDIR_23x LYX_DIR_VER=LYX_DIR_23x \origin\ 
unavailable=\origin\ /systemlyxdir/doc/hu /build/lyx/lib/doc/hu/Intro.lyx > 
/build/lyx/build/doc/hu/Intro.lyx
[  2%] Generating hu/Tutorial.lyx
cd /build/lyx/build/doc && /usr/bin/python2 
/build/lyx/development/cmake/doc/ReplaceValues.py 
LYX_USERDIR_VER=LYX_USERDIR_23x LYX_DIR_VER=LYX_DIR_23x \origin\ 
unavailable=\origin\ /systemlyxdir/doc/hu /build/lyx/lib/doc/hu/Tutorial.lyx > 
/build/lyx/build/doc/hu/Tutorial.lyx
[  2%] Generating uk/Intro.lyx
cd /build/lyx/build/doc && /usr/bin/python2 
/build/lyx/development/cmake/doc/ReplaceValues.py 
LYX_USERDIR_VER=LYX_USERDIR_23x LYX_DIR_VER=LYX_DIR_23x \origin\ 
unavailable=\origin\ /systemlyxdir/doc/uk /build/lyx/lib/doc/uk/Intro.lyx > 
/build/lyx/build/doc/uk/Intro.lyx
[  2%] Generating MergedManuals.lyx
cd /build/lyx/build/doc && /usr/bin/python2 
/build/lyx/development/cmake/doc/ReplaceValues.py 
LYX_USERDIR_VER=LYX_USERDIR_23x LYX_DIR_VER=LYX_DIR_23x \origin\ 
unavailable=\origin\ /systemlyxdir/doc/. /build/lyx/lib/doc/MergedManuals.lyx > 
/build/lyx/build/doc/MergedManuals.lyx
[  2%] Generating es/DocumentoPostizo2.lyx
cd /build/lyx/build/doc && /usr/bin/python2 
/build/lyx/development/cmake/doc/ReplaceValues.py 
LYX_USERDIR_VER=LYX_USERDIR_23x LYX_DIR_VER=LYX_DIR_23x \origin\ 
unavailable=\origin\ /systemlyxdir/doc/es 
/build/lyx/lib/doc/es/DocumentoPostizo2.lyx > 
/build/lyx/build/doc/es/DocumentoPostizo2.lyx
[  3%] Generating es/Math.lyx
cd /build/lyx/build/doc && /usr/bin/python2 
/build/lyx/development/cmake/doc/ReplaceValues.py 
LYX_USERDIR_VER=LYX_USERDIR_23x LYX_DIR_VER=LYX_DIR_23x \origin\ 
unavailable=\origin\ /systemlyxdir/doc/es /build/lyx/lib/doc/es/Math.lyx > 
/build/lyx/build/doc/es/Math.lyx
[  3%] Generating es/UserGuide.lyx
cd /build/lyx/build/doc && /usr/bin/python2 
/build/lyx/development/cmake/doc/ReplaceValues.py 
LYX_USERDIR_VER=LYX_USERDIR_23x LYX_DIR_VER=LYX_DIR_23x \origin\ 
unavailable=\origin\ /systemlyxdir/doc/es /build/lyx/lib/doc/es/UserGuide.lyx > 
/build/lyx/build/doc/es/UserGuide.lyx
[  3%] Generating es/Shortcuts.lyx
cd /build/lyx/build/doc && /usr/bin/python2 
/build/lyx/development/cmake/doc/ReplaceValues.py 
LYX_USERDIR_VER=LYX_USERDIR_23x LYX_DIR_VER=LYX_DIR_23x \origin\ 
unavailable=\origin\ /systemlyxdir/doc/es /build/lyx/lib/doc/es/Shortcuts.lyx > 
/build/lyx/build/doc/es/Shortcuts.lyx
[  3%] Generating es/DocumentoPostizo1.lyx
cd /build/lyx/build/doc && /usr/bin/python2 
/build/lyx/development/cmake/doc/ReplaceValues.py 
LYX_USERDIR_VER=LYX_USERDIR_23x LYX_DIR_VER=LYX_DIR_23x \origin\ 
unavailable=\origin\ /systemlyxdir/doc/es 
/build/lyx/lib/doc/es/DocumentoPostizo1.lyx > 
/build/lyx/build/doc/es/DocumentoPostizo1.lyx
[  3%] Generating es/Additional.lyx
cd /build/lyx/build/doc && /usr/bin/python2 
/build/lyx/development/cmake/doc/ReplaceValues.py 
LYX_USERDIR_VER=LYX_USERDIR_23x LYX_DIR_VER=LYX_DIR_23x \origin\ 
unavailable=\origin\ /systemlyxdir/doc/es /build/lyx/lib/doc/es/Additional.lyx 
> /build/lyx/build/doc/es/Additional.lyx
[  3%] Generating es/Formula-numbering.lyx
cd /build/lyx/build/doc && /usr/bin/python2 
/build/lyx/development/cmake/doc/ReplaceValues.py 
LYX_USERDIR_VER=LYX_USERDIR_23x LYX_DIR_VER=LYX_DIR_23x \origin\ 
unavailable=\origin\ /systemlyxdir/doc/es 
/build/lyx/lib/doc/es/Formula-numbering.lyx > 
/build/lyx/build/doc/es/Formula-numbering.lyx
[  3%] Generating es/EmbeddedObjects.lyx
cd /build/lyx/build/doc && /usr/bin/python2 
/build/lyx/development/cmake/doc/ReplaceValues.py 
LYX_USERDIR_VER=LYX_USERDIR_23x LYX_DIR_VER=LYX_DIR_23x \origin\ 
unavailable=\origin\ /systemlyxdir/doc/es 
/build/lyx/lib/doc/es/EmbeddedObjects.lyx > 
/build/lyx/build/doc/es/EmbeddedObjects.lyx
[  3%] Generating es/Intro.lyx
cd /build/lyx/build/doc && /usr/bin/python2 
/build/lyx/development/cmake/doc/ReplaceValues.py 
LYX_USERDIR_VER=LYX_USERDIR_23x LYX_DIR_VER=LYX_DIR_23x \origin\ 
unavailable=\origin\ /systemlyxdir/doc/es /build/lyx/lib/doc/es/Intro.lyx > 
/build/lyx/build/doc/es/Intro.lyx
[  4%] Generating es/Customization.lyx
cd /build/lyx/build/doc && /usr/bin/python2 
/build/lyx/development/cmake/doc/ReplaceValues.py 
LYX_USERDIR_VER=LYX_USERDIR_23x LYX_DIR_VER=LYX_DIR_23x \origin\ 
unavailable=\origin\ /systemlyxdir/doc/es 
/build/lyx/lib/doc/es/Customization.lyx > 
/build/lyx/build/doc/es/Customization.lyx
[  4%] Generating es/Tutorial.lyx
cd 

Re: cmake and boost

[Kornel Benko]

Am Freitag, 28. Juli 2017 um 00:26:33, schrieb Cor Blom 
> Op 27-07-17 om 22:27 schreef Kornel Benko:
> > This means that the devel version boost-regex is not found. But maybe your 
> > installed cmake
> > is not able to find such new boost version. Checking FindBoost.cmake in 
> > cmake 3.9, the last
> > known boost are versions between 1.63.00 .. 1.64.99 though.
> > So, what is your cmake version?
> 
> openSUSE Tumbleweed has version 3.8.2.
> 
> > 
> > OTOH, why use boost-regex? You have gcc7.1 installed, so you already may 
> > use std-regex (e.g. without boost)
> 
> Only recently openSUSE has split the boost-devel package in separate 
> packages. I still use boost-devel, which means all boost-devel packages 
> are installed. I haven't come around to changing this yet.
> 
> Does it mean that with gcc7.1 lyx can be build without boost?
> 

Cmake lyx-build will ignore the boost setting if using recent enough compiler 
(e.g version >= 4.9)

> > Nonetheless, you found a bug in our cmake files.
> > 
> > You may want to try the attached.
> 
> Wit the latest git this bug is gone and lyx builds fine.
> 
> Thanks.

You are welcome.

Kornel

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

Re: alternatives for dashes (please vote)

[Pavel Sanda]

Guenter Milde wrote:
> Comments and votes welcome.
...
> e) re-define \textemdash
> f) keep the current 2.3alpha behaviour

Could you expand little bit, what e) means and what f) the current 2.3alpha 
behavior is? Thanks. Pavel

Re: cmake and boost

[Cor Blom]

Op 27-07-17 om 22:27 schreef Kornel Benko:

This means that the devel version boost-regex is not found. But maybe your 
installed cmake
is not able to find such new boost version. Checking FindBoost.cmake in cmake 
3.9, the last
known boost are versions between 1.63.00 .. 1.64.99 though.
So, what is your cmake version?


openSUSE Tumbleweed has version 3.8.2.



OTOH, why use boost-regex? You have gcc7.1 installed, so you already may use 
std-regex (e.g. without boost)


Only recently openSUSE has split the boost-devel package in separate 
packages. I still use boost-devel, which means all boost-devel packages 
are installed. I haven't come around to changing this yet.


Does it mean that with gcc7.1 lyx can be build without boost?



Nonetheless, you found a bug in our cmake files.

You may want to try the attached.


Wit the latest git this bug is gone and lyx builds fine.

Thanks.

alternatives for dashes (please vote)

[Guenter Milde]

Dear LyX developers,

following Scotts suggestion, I prepared an overview of alternatives to
handle the problem with 2.2 breaking formatting of em- and en-dashes.
Comments and votes welcome.

Unfortunately, the topic is emotionally loaded, as we did a mistake and
there is no solution that everyone will agree with. OTOH, it is complex, but
not very important.

The Problem
===

Up to version 2.2, LyX used 2 representations for em- and en-dashes:

"literal" dashes:
   literal Unicode or \textemdash rsp. \textendash macro,
"ligature" dashes:
   "---" and "--" converted by the TeX font ligature mechanism.

"Ligature" and "literal" dashes can coexist in <2.2-documents,
e.g., when parts were copy-pasted from different sources.


LyX 2.2 uses only one representation and converts "ligature dashes" to
"literal dashes".

This turned out to break formatting in some documents, because

"literal" dashes suppress line breaks after the dash
  and allow hyphenation in adjacent words while
"ligature dashes" allow line breaks after the dash
  and suppress hyphenation in adjacent words.

There are use cases for both, dashes with and without optional line break
**switching the representation either way can lead to broken output**
(overfull lines or unwanted line breaks).

For details and examples see http://www.lyx.org/trac/ticket/10543#comment:3
and http://www.lyx.org/trac/attachment/ticket/10543/emdash-line-breaks.lyx


Alternatives for 2.3


a) convert ligature dashes to literal dash + allowbreak

   + keeps formatting in most cases
 - allows (possibly undesired) hyphenation in adjacent words
 - a redefinition of \text*dash would also affect former
   "ligature" dashes.
   + simple
   + configurable/editable (special char can easily be deleted)
   ± verbose (the "allowbreak" special-char is displayed as a small blue mark)

b) convert ligature dashes to "special character" insets

   + no change to LaTeX output.
   - requires "special character" inset for ordinary printable character
 - does not scale well
 + precedence cases: curly quotes, text ellipsis

c) keep 2.2 behaviour (convert ligature dashes to literal dashes)

   + simple
   + no change for 2.2 documents (the damage is already done)
   - breaks formatting for <2.2 documents using ligature dashes

d) convert "ligature dashes" to ERT

   + no change to LaTeX output
   + simple
   - ERT for formerly supported feature

e) re-define \textemdash

   + simple (except for LuaTeX)
   + already done by XeTeX
 
(http://tex.stackexchange.com/questions/62800/lualatex-and-line-breaks-after-em-dashes)
   + configurable
   - hidden in the user preamble

f) keep the current 2.3alpha behaviour

   + configurable
   - breaks formatting for <2.2 documents using literal dashes
 (these were not affected by the change in 2.2)
   - new document setting for LaTeX export of Unicode characters:
 - does not scale well,
 - unprecedented
   - Data loss (ZWSP following dashes are removed by lyx2lyx)
   - different line breaks of the same document with LuaTeX and non-TeX fonts

g) revert to 2.1 behaviour

   - regression on bugs  #3647 and #8561
   - no WYSIWYM: "lyx --help" in the GUI becomes "lyx –help" in the output.


Alternatives b), c), d) and e) could also be applied to 2.2.x,
a) and f) require a fileformat change.



Open question:
  which representation to use with the -- and --- input conversion?

* The simplest way is to keep 2.2 behaviour (insert literal dashes).
  
* Maybe we can use a lyxfun with options that will be bound to the '-'-key?

* Sensible defaults would be
  allow linebreak after em-dash
  prevent linebreak after en-dash.
  
  Rationale: 
en-dash around an ellipsis is used with spaces, no line break
allowed in ranges.


Günter

Re: Living with shell-escape: Using two LyX instances - critique invited

[Christian Ridderström]

On 27 July 2017 at 18:05, Tommaso Cucinotta  wrote:

> On 27/07/2017 17:31, Tommaso Cucinotta wrote:
>
>> I think what we might do in a relatively easy and generic way, is to allow
>> for setting individual preferences settings from the command-line, e.g.:
>>
>>alias lyx-safe='/usr/bin/lyx -Duse_converter_needauth_forbidden=true'
>>alias lyx-unsafe='/usr/bin/lyx -Duse_converter_needauth_forbidden=false
>> -Duse_converter_needauth=false'
>>
>> that would override whatever one has in the ~/.lyx/preferences config.
>>
>
I added a section to the wiki page to note that alias + options might be a
way.


>
> we have an already existing way through the LYXRC_APPLY LFUN, with a
> relatively heavy syntax:
>
> This is lyx-safe:
>
> ./src/lyx -x 'lyxrc-apply Format 22
> \use_converter_needauth_forbidden true'
>
> This is lyx-unsafe:
>
> ./src/lyx -x 'lyxrc-apply Format 22
> \use_converter_needauth_forbidden false
> \use_converter_needauth false'
>

I haven't added this to the wiki page as I don't understand the 'Format 22'
part.

Perhaps you could explain it, or add it to the page?

Would this be applied after LyX preferences/config has been read, but
before a document is opened?

/Christian

Re: cmake and boost

[Kornel Benko]

Am Donnerstag, 27. Juli 2017 um 21:57:54, schrieb Cor Blom 
> Op 27-07-17 om 20:11 schreef Kornel Benko:
> > Have you requested LYX_USE_STD_REGEX?
>
> How do I do that?
>
> If yes, do you have the devel package for boost-regex installed?
> > Don't know the package name for SuSE, on ubuntu it is for example
> > libboost-regex1.55-dev
>
> I have those packages installed. They are called on Tumbleweed:
>
> - libboost_regex1_64_0
> - libboost_regex1_64_0-devel

Should be OK, but maybe we do not search
> This is the last part of the log:
>

...

> [   97s] CMake Error at CMakeLists.txt:814 (message):
> [   97s]   Boost not found

This means that the devel version boost-regex is not found. But maybe your 
installed cmake
is not able to find such new boost version. Checking FindBoost.cmake in cmake 
3.9, the last
known boost are versions between 1.63.00 .. 1.64.99 though.
So, what is your cmake version?

OTOH, why use boost-regex? You have gcc7.1 installed, so you already may use 
std-regex (e.g. without boost)

Nonetheless, you found a bug in our cmake files.

You may want to try the attached.

> Cor

Kornel

signature.asc
Description: This is a digitally signed message part.
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 6975751..5e58de8 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -795,23 +795,23 @@ else()
 endif()
 
 if(LYX_EXTERNAL_BOOST)
-	message(STATUS "Searching for boost")
 	if(NOT LYX_USE_STD_REGEX)
+		message(STATUS "Searching for boost")
 		find_package(Boost COMPONENTS regex)
-	endif()
-	if(Boost_FOUND)
-		message(STATUS "Boost found")
-		message(STATUS "Boost-libs = ${Boost_LIBRARIES}")
-		set(Lyx_Boost_Libraries ${Boost_LIBRARIES})
-		if (LYX_STDLIB_DEBUG)
-			# Comment from 	Jean-Marc Lasgouttes:
-			# In general, system boost libraries are incompatible with
-			# the use of stdlib-debug in libstdc++. See ticket #9736 for
-			# details.
-			message(WARNING "Compiling LyX with stdlib-debug and system boost libraries may lead to crashes. Consider using '-DLYX_STDLIB_DEBUG=OFF' or using '-DLYX_EXTERNAL_BOOST=OFF'")
+		if(Boost_FOUND)
+			message(STATUS "Boost found")
+			message(STATUS "Boost-libs = ${Boost_LIBRARIES}")
+			set(Lyx_Boost_Libraries ${Boost_LIBRARIES})
+			if (LYX_STDLIB_DEBUG)
+# Comment from 	Jean-Marc Lasgouttes:
+# In general, system boost libraries are incompatible with
+# the use of stdlib-debug in libstdc++. See ticket #9736 for
+# details.
+message(WARNING "Compiling LyX with stdlib-debug and system boost libraries may lead to crashes. Consider using '-DLYX_STDLIB_DEBUG=OFF' or using '-DLYX_EXTERNAL_BOOST=OFF'")
+			endif()
+		else()
+			message(FATAL_ERROR "Boost not found" ${Boost_ERROR_REASON})
 		endif()
-	else()
-		message(FATAL_ERROR "Boost not found" ${Boost_ERROR_REASON})
 	endif()
 else()
 	if(NOT LYX_USE_STD_REGEX)

Re: cmake and boost

[Cor Blom]

Op 27-07-17 om 20:11 schreef Kornel Benko:

Have you requested LYX_USE_STD_REGEX?


How do I do that?

If yes, do you have the devel package for boost-regex installed?

Don't know the package name for SuSE, on ubuntu it is for example
libboost-regex1.55-dev


I have those packages installed. They are called on Tumbleweed:

- libboost_regex1_64_0
- libboost_regex1_64_0-devel

This is the last part of the log:

[   91s] -- Building in-source
[   91s] -- The C compiler identification is GNU 7.1.1
[   91s] -- The CXX compiler identification is GNU 7.1.1
[   91s] -- Check for working C compiler: /usr/bin/cc
[   91s] -- Check for working C compiler: /usr/bin/cc -- works
[   91s] -- Detecting C compiler ABI info
[   91s] -- Detecting C compiler ABI info - done
[   91s] -- Detecting C compile features
[   91s] -- Detecting C compile features - done
[   91s] -- Check for working CXX compiler: /usr/bin/c++
[   92s] -- Check for working CXX compiler: /usr/bin/c++ -- works
[   92s] -- Detecting CXX compiler ABI info
[   92s] -- Detecting CXX compiler ABI info - done
[   92s] -- Detecting CXX compile features
[   92s] -- Detecting CXX compile features - done
[   92s] --
[   92s] -- CXX11_FLAG_DETECTED = "--std=c++14"
[   96s] -- Compiler supports std_regex
[   96s] -- Found CXX11Compiler: --std=c++14
[   96s] -- Using GCC version 7
[   96s] -- CMAKE_COMPILER_IS_GNUCXX = 1
[   96s] -- CMAKE_CXX_STANDARD set to 14
[   96s] -- Found Qt-Version 5.9.1
[   96s] -- Looking for magic_file
[   96s] -- Looking for magic_file - not found
[   96s] -- Function magic_file not found
[   96s] -- Looking for magic_open
[   96s] -- Looking for magic_open - not found
[   96s] -- Function magic_open not found
[   96s] -- Looking for magic_load
[   97s] -- Looking for magic_load - not found
[   97s] -- Function magic_load not found
[   97s] -- Looking for magic_close
[   97s] -- Looking for magic_close - not found
[   97s] -- Function magic_close not found
[   97s] -- Looking for magic_error
[   97s] -- Looking for magic_error - not found
[   97s] -- Function magic_error not found
[   97s] -- Could NOT find Magic (missing:  Magic_INCLUDE_DIR 
Magic_LIBRARY HAS_MAGIC_FUNCTIONS)
[   97s] -- Could NOT find MYTHESLIB (missing:  MYTHESLIB_LIBRARY 
MYTHESLIB_INCLUDE_DIR)
[   97s] -- Could NOT find ASPELL (missing:  ASPELL_LIBRARY 
ASPELL_INCLUDE_DIR)

[   97s] -- ASPELL not found, building without ASPELL support
[   97s] -- Found ENCHANT: /usr/lib64/libenchant.so
[   97s] -- Building with USE_ENCHANT
[   97s] -- Found HUNSPELL: /usr/lib64/libhunspell.so
[   97s] -- Building with USE_HUNSPELL
[   97s] -- Found PythonInterp: /usr/bin/python2 (found suitable version 
"2.7.13", minimum required is "2.0")

[   97s] -- Could NOT find LYX_PY_polib (missing:  LYX_PY_POLIB)
[   97s] -- You will be unable to update layouttranslations file
[   97s] -- Looking for iconv
[   97s] -- Looking for iconv - found
[   97s] -- Found iconv library:
[   97s] -- Found Z: /usr/lib64/libz.so
[   97s] -- Searching for boost
[   97s] CMake Error at CMakeLists.txt:814 (message):
[   97s]   Boost not found

Cor

Re: cmake and boost

[Kornel Benko]

Am Donnerstag, 27. Juli 2017 um 19:52:55, schrieb Cor Blom 
> Hi,
> 
> I'm testing 2.3 snapshots for openSUSE packaging and stumbled on a 
> problem when building with cmake and system-boost. On Tumbleweed 
> system-boost is not found and only there this error occurs. On Leap 42.2 
> and 42.3 there is no error, and also not when building with autotools. 
> With automake there is also no error on Tumbleweed.
> 
> All logs can be found here[1], but as far as I can see they don't tell much.
> 
> Cor
> 
> [1] https://build.opensuse.org/project/show/home:cornelisbb:lyx-unstable

Have you requested LYX_USE_STD_REGEX? If yes, do you have the devel package for 
boost-regex installed?
Don't know the package name for SuSE, on ubuntu it is for example
libboost-regex1.55-dev

Kornel

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

cmake and boost

[Cor Blom]

Hi,

I'm testing 2.3 snapshots for openSUSE packaging and stumbled on a 
problem when building with cmake and system-boost. On Tumbleweed 
system-boost is not found and only there this error occurs. On Leap 42.2 
and 42.3 there is no error, and also not when building with autotools. 
With automake there is also no error on Tumbleweed.


All logs can be found here[1], but as far as I can see they don't tell much.

Cor

[1] https://build.opensuse.org/project/show/home:cornelisbb:lyx-unstable

Re: questions regarding the minted listings support

[Richard Heck]

On 07/27/2017 06:34 AM, Uwe Stöhr wrote:
>
>   Original Message  
> From: Richard Heck
> Sent: Donnerstag, 27. Juli 2017 03:28‎
>
>> Uwe, I think you must have missed the month-long discussion 
> Hi Richard,
>
> Yes because I was more or less completely off and on to real life ;-)
>
> However, the win installer for Lyx will noch add any option to the Tex 
> executables. All I implemented is to deliver the Python package pygments. 
>
> Concerning the docs, I prefer to move the minted description to the 
> additional manual because enabling minted is much too complicated for average 
> users in my opinion. 

That's fine with me. But probably, as I said, wait until something's
been decided.

Richard

Re: Living with shell-escape: Using two LyX instances - critique invited

[Tommaso Cucinotta]

[ adding chr@, gm@ explicitly ]

On 27/07/2017 17:31, Tommaso Cucinotta wrote:

I think what we might do in a relatively easy and generic way, is to allow
for setting individual preferences settings from the command-line, e.g.:

   alias lyx-safe='/usr/bin/lyx -Duse_converter_needauth_forbidden=true'
   alias lyx-unsafe='/usr/bin/lyx -Duse_converter_needauth_forbidden=false 
-Duse_converter_needauth=false'

that would override whatever one has in the ~/.lyx/preferences config.


we have an already existing way through the LYXRC_APPLY LFUN, with a relatively 
heavy syntax:

This is lyx-safe:

./src/lyx -x 'lyxrc-apply Format 22
\use_converter_needauth_forbidden true'

This is lyx-unsafe:

./src/lyx -x 'lyxrc-apply Format 22
\use_converter_needauth_forbidden false
\use_converter_needauth false'

T.

Re: Living with shell-escape: Using two LyX instances - critique invited

[Tommaso Cucinotta]

On 27/07/2017 17:31, Tommaso Cucinotta wrote:

I think what we might do in a relatively easy and generic way, is to allow
for setting individual preferences settings from the command-line, e.g.:

   alias lyx-safe='/usr/bin/lyx -Duse_converter_needauth_forbidden=true'
   alias lyx-unsafe='/usr/bin/lyx -Duse_converter_needauth_forbidden=false 
-Duse_converter_needauth=false'

that would override whatever one has in the ~/.lyx/preferences config.


we have an already existing way through the LYXRC_APPLY LFUN, with a relatively 
heavy syntax:

This is lyx-safe:

./src/lyx -x 'lyxrc-apply Format 22
\use_converter_needauth_forbidden true'

This is lyx-unsafe:

./src/lyx -x 'lyxrc-apply Format 22
\use_converter_needauth_forbidden false
\use_converter_needauth false'

T.

Re: Living with shell-escape: Using two LyX instances - critique invited

[Tommaso Cucinotta]

On 27/07/2017 16:10, Guillaume MM wrote:

It makes sense that an option in the command line could disable needauth
entirely. It is becoming hard to track all the suggestions so if you are
interested in this I suggest filing enhancement reports / the wiki page.


I think what we might do in a relatively easy and generic way, is to allow
for setting individual preferences settings from the command-line, e.g.:

  alias lyx-safe='/usr/bin/lyx -Duse_converter_needauth_forbidden=true'
  alias lyx-unsafe='/usr/bin/lyx -Duse_converter_needauth_forbidden=false 
-Duse_converter_needauth=false'

that would override whatever one has in the ~/.lyx/preferences config.

This might be useful beyond needauth et al.

Bye,

T.

Re: Question for Guillaume about b30f8d3c and GuiFontMetrics::countExpanders

[Guillaume MM]

Le 25/07/2017 à 14:36, Jean-Marc Lasgouttes a écrit :


Hi Guillaume,

The commit log for b30f8d3c says: " CountExpanders() is moved to 
FontMetrics to fix a discrepancy with the duplicate implementation from 
598f7e4a."


I interpret that to mean that countExpanders() should be available in 
GuiPainter too, right?


OTOH, countExpanders is basically a plain function and it seems weird to 
require a FontMetrics object to compute it.


Is there a reason why it is not a free standing function somewhere in 
support/ ?


Hi Jean-Marc,

The reasoning was that how many expanders there are in a string is
toolkit-specific. This implementation was by testing and reading the
docs and source code of Qt, and does not correspond to my knowledge to
any Unicode standard (say). So, using the frontends/ virtual interface
is more appropriate, and virtual functions cannot be non-member nor
static. Concretely, the FontMetrics object is used to know which
frontend one refers to.

In contrast, it seems that support/ contains non-UI related Qt tools
that could still work with other frontends (e.g. command-line
interface). (Or maybe I am being too optimistic.)

I you say that for countExpanders this looks like an overzealous
application of the frontend separation I will agree. But if the question
was just out of curiosity and does not limit you then I would say leave
it as is.

Any clarification on Qt in support/ vs. Qt in frontends/ is welcome.

Guillaume

Re: Living with shell-escape: Using two LyX instances - critique invited

[Guillaume MM]

Le 23/07/2017 à 20:45, Christian Ridderström a écrit :

Bah, I again e-mailed only Guillaume and not the list.

On 19 July 2017 at 00:00, Guillaume MM  wrote:



I find that it would be more cumbersome and error-prone than a good
needauth implementation.



cumbersome:
Do you refer to using two user dirs, or perhaps having to (once?)
modify the parameter of the converter settings?
Or do you mean having two LyX windows open at the same time?


All of that. Also that, when running in unsafe mode, you have to assume
that everything is unsafe. So this unsafe mode it is still less safe
than a good needauth implementation.



error-prone:
Do you mean that you'll open the doc^H^H^Hprogram [*] in normal mode
and when you try to build it fails?
Or do you think it'd be difficult to set this thing up?


That one.



If I understand, what you want is visibility
and revokability, which people already seem to agree are desirable
improvements to make to needauth (a red status bar thingy).



Yes, visibility that I'm operating in an unusual/non-default and
potentially dangerous mode.

Revokability I'd rather say isolation/separation.


By isolation/separation, what do you mean? Is it different from 
visibility (being able to tell whether things are safe)?




Besides wanting to allow the use of shell-escape only for a limited
set of documents (i.e. documents), I would likely also only want to
allow shell-escape when I want to run the program.


It makes sense that an option in the command line could disable needauth
entirely. It is becoming hard to track all the suggestions so if you are
interested in this I suggest filing enhancement reports / the wiki page.



Anyway, I think we should strive to allow a design where shell-escape
is not needed. And this topic is about a fallback when shell-escape is
necessary.


+1

Re: Going into dangerous mode (Was: Can shell-escape take advantage of needauth framework?)

[Guillaume MM]

Le 22/07/2017 à 00:47, Guenter Milde a écrit :

On 2017-07-19, Richard Heck wrote:

On 07/19/2017 01:48 AM, Christian Ridderström wrote:

On 18 July 2017 at 23:49, Jean-Marc Lasgouttes > wrote:
 Le 18/07/2017 à 23:42, Christian Ridderström a écrit :



 I think the default should be secure, and that the user should
 have to do something actively to go into a dangerous mode.




 Well, since you consider that turning off two options is not
 active enough, I am not sure what to propose :)




The problem I see with only unchecking two check boxes are e.g.:
- Users uncheck settings all the time, it doesn't seem very "scary"
- In the settings dialog, the real implications of unchecking these
options
   did not seem sufficiently clear to me.
   So calling it "Allow yourself to be shot in the foot by converters"
would help;-)
- The setting is persistent, and easily forgotten



This, I believe, was part of what was addressed by Enrico's patch. Or
the idea behind it.


Enrico's patch did not touch "needauth" but has some nice features for
"shell-escape":


+1


it addressed the "set and forget" issue by

a) adding a red icon to the status bar if a document has the "allow
shell-escape" flag.


+1

   
b) revoking the permission, if the document is moved/copied to another

location.


I like the principle, but I wonder whether this will cause annoyances
for files on removable filesystems.

   
I like the approach, especially b) seems a good compromise between user

comfort and security.

   
 From a user perspective, a common interface to "needauth" and "allow

shell escape" seems the best. "needauth" could actually take advantage of
Enrico's patch.


+1



Some ideas:

* Add "unsafe pdflatex" (== pdflatex --shell-escape) and "unsafe xelatex"
   as new converters requiring "needauth".

* Allow per-converter permission settings (instead of one generic: "I
   trust/don't trust all unsafe converters").


+1



* clicking the red icon should take you to the dialogue allowing to
   revoke the unsafe permission.


+1

   
* Give users the possibility to check scripts before allowing to run them

   with shell-escape or at least list all parts of the document that will be
   allowed to run in unsafe mode
   (e.g. all gnuplot scripts for "gnuplot allowed", all ERT, preamble,
   document classes and packages for latex with shell escape).



I like the idea, though for shell-escape this becomes more complicated.


* I also like the error dialog when -shell-escape has been configured
without needauth, for legacy configurations. (The specific wording can
be discussed later on.)

* Like Jean-Marc, I would prefer if the -shell-escape option was not
hardcoded, but integrated with needauth and the full command-line
visible in the converters dialog in some way. For instance a new token
$$unsafe together with a per-converter checkbox to allow its replacement
by whatever unsafe option.

* One has to decide which suggestions are needed for 2.3 and which ones
can be implemented later.


On the negative side, the patch does not address the original issues:
* The limitations of needauth in the context of adding new converters
such as gnuplot (the patch is only about -shell-escape),
* Having to use -shell-escape for running Pygments.


I would also be more comfortable if somebody takes responsibility for
any patch that is to be committed, given that the author has said that
they do not endorse it.


Guillaume

Re: questions regarding the minted listings support

[Uwe Stöhr]

  Original Message  
From: Richard Heck
Sent: Donnerstag, 27. Juli 2017 03:28‎

> Uwe, I think you must have missed the month-long discussion 

Hi Richard,

Yes because I was more or less completely off and on to real life ;-)

However, the win installer for Lyx will noch add any option to the Tex 
executables. All I implemented is to deliver the Python package pygments. 

Concerning the docs, I prefer to move the minted description to the additional 
manual because enabling minted is much too complicated for average users in my 
opinion. 

> *especially* concerning
-shell-escape. We do NOT want to encourage people to add -shell-escape

I am glad to hear that I am not the only sceptic and that you already took care 
to find a safe solution. 

Regards Uwe