Re: Patches for Python scripts

2021-01-31 Thread Thibaut Cuvelier 
On Sun, 31 Jan 2021 at 12:39, Enrico Forestieri  wrote:

> On Sun, Jan 31, 2021 at 04:22:39AM +0100, Thibaut Cuvelier wrote:
> > On Sat, 30 Jan 2021 at 12:26, Enrico Forestieri  wrote:
> > > On Sat, Jan 30, 2021 at 05:31:05AM +0100, Thibaut Cuvelier wrote:
> > > > On Sat, 30 Jan 2021 at 02:31, Enrico Forestieri 
> wrote:
> > > > >
> > > > > So, it seems that you have to check also for the 32-bit version.
> > > > >
> > > > Indeed. Would the attached patch solve the problem? I first look for
> a
> > > > 64-bit version before a 32-bit, just to favour newer things, but
> there is
> > > > no other reason to do so.
> > >
> > > The patch does not apply neither to current master nor to current
> stable
> > > (most probably it depends on previous patches):
> > >
> > > $ patch --dry-run -p1 <
> > > 0013-Configure-look-for-Java-in-the-registry-on-Windows.patch
> > > checking file lib/configure.py
> > > Hunk #1 FAILED at 330.
> > > Hunk #2 succeeded at 403 (offset -14 lines).
> > > Hunk #3 succeeded at 1923 (offset -94 lines).
> > > 1 out of 3 hunks FAILED
> > >
> > > and I had to apply it manually. Before applying it, I took away java
> from
> > > PATH and reconfigured:
> > >
> > > ...
> > > checking for a java interpreter...
> > > +checking for "java"...  no
> > > ...
> > >
> > > Correctly, java was not found (it is found when it is in PATH).
> > > Then I applied the patch an reconfigured again:
> > >
> > > ...
> > > checking for a java interpreter...
> > > +checking for "java"...  no
> > > Traceback (most recent call last):
> > >   File "C:\cygwin\win\python\lib\logging\__init__.py", line 870, in
> emit
> > > stream.write(ufs % msg)
> > > LookupError: unknown encoding: cp65001
> > > Logged from file configure.py, line 346
> > > ...
> > >
> > > I have a native Windows version of Python 2.7 installed in
> > > "C:\cygwin\win\python".
> > >
> > > So, it seems there is a problem with Python 2
> > >
> >
> > I just tried with Python 2.7.18 (64 bits), I cannot reproduce your
> problem.
> > What is exactly on your line 346? I guess it is something like
> logger.info,
> > a line that runs without problem on my side (Python 3.8 and 2.7).
>
> Yes, that's exactly "logger.info('+checking for java: ' + java_bin)".
> It seems a problem related to the locale. I was reconfiguring from a
> cygwin shell, whose locale is UTF-8, apparently something alien to
> Windows. I now tried reconfiguring from a cmd.exe window and the result is:
>
> ...
> checking for a java interpreter...
> +checking for "java"...  no
> +checking for java: C:\Program Files (x86)\Java\jre1.8.0_281\bin\java.exe
> ...
>
> So, it works. However, to avoid confusion, you should avoid logging the
> first negative result. Or, maybe, on Windows report something like this:
>
> ...
> checking for a java interpreter...
> +checking for "java" in PATH...  no
> +checking for "java" in registry... C:\Program Files
> (x86)\Java\jre1.8.0_281\bin\java.exe
> ...
>
> And, yes, I know making things work for everyone is exhausting...
>
> Thank you for your efforts.
>

Thank you for testing on your side :)! What's frustrating with your report
is that this bug can only appear on Python 2, and that it will very likely
be dropped for the next release (I remember seeing people wanting to keep
it for LyX 2.4). Nevertheless, I'm trying to do a few things about it.

What I've been doing: change the output when looking for programs, with a
more explicit "not in path" instead of "no", and the same for the registry
check; convert the result of winreg.QueryValueEx to a string (in Python 2,
it looks like it's a byte array, hence the error). If that doesn't work, I
really don't know what to do, apart from not telling the user what Java
binary was found.

I'm attaching a differential patch (unnamed8) for the latest changes, plus
a complete updated patch that should replace the original 0013 patch. Does
it work for you?



More generally, what about the other patches? Are formatting changes
considered risky? What about Joel's suggestions?


unnamed8.patch
Description: Binary data


0013-Configure-look-for-Java-in-the-registry-on-Windows.patch
Description: Binary data
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/master] make distcheck broken after old installer purge.

2021-01-31 Thread Pavel Sanda 
On Sun, Jan 31, 2021 at 04:31:31PM +0100, Pavel Sanda wrote:
> commit dded4c8ab548892d86480d11541ad9a350e4c450
> Author: Pavel Sanda 
> Date:   Sun Jan 31 16:32:51 2021 +0100
> 
> make distcheck broken after old installer purge.

JMarc, are you able to somehow check whether jenkins works?
I am surprised we did not get warning weeks ago... P
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: LyX 2.4.0-alpha1

2021-01-31 Thread Enrico Forestieri 
On Sun, Jan 31, 2021 at 01:33:21PM +, José Abílio Matos wrote:
> On Sunday, January 31, 2021 12:12:41 PM WET Enrico Forestieri wrote:
> > Does the attached patch work for you?
> 
> Yes. Without the patch "make check" fails, with the patch it works.

Committed.

> Thank you. :-)

Thanks for checking.

-- 
Enrico
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: LyX 2.4.0-alpha1

2021-01-31 Thread José Abílio Matos 
On Sunday, January 31, 2021 12:12:41 PM WET Enrico Forestieri wrote:
> Does the attached patch work for you?

Yes. Without the patch "make check" fails, with the patch it works.

Thank you. :-)
-- 
José Abílio-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: LyX 2.4.0-alpha1

2021-01-31 Thread Enrico Forestieri 
On Sun, Jan 31, 2021 at 10:20:20AM +, José Abílio Matos wrote:
> 
> So I suspect that to fix this in the autotools framework we need to link with 
> libz on the check stage. How to this is out of my abilities. :-)

Does the attached patch work for you?

-- 
Enrico
diff --git a/src/support/Makefile.am b/src/support/Makefile.am
index 3dedf57fea..fb833573f3 100644
--- a/src/support/Makefile.am
+++ b/src/support/Makefile.am
@@ -173,28 +173,28 @@ ADD_FRAMEWORKS = \
-Wl,-headerpad_max_install_names
 endif
 
-check_convert_LDADD = liblyxsupport.a $(LIBICONV) $(QT_CORE_LIBS) 
$(LIBSHLWAPI) @LIBS@
+check_convert_LDADD = liblyxsupport.a $(LIBICONV) $(QT_CORE_LIBS) 
$(LIBSHLWAPI) @LIBS@ -lz
 check_convert_LDFLAGS = $(QT_CORE_LDFLAGS) $(ADD_FRAMEWORKS)
 check_convert_SOURCES = \
tests/check_convert.cpp \
tests/dummy_functions.cpp \
tests/boost.cpp
 
-check_filetools_LDADD = liblyxsupport.a $(LIBICONV) $(QT_CORE_LIBS) 
$(LIBSHLWAPI) @LIBS@
+check_filetools_LDADD = liblyxsupport.a $(LIBICONV) $(QT_CORE_LIBS) 
$(LIBSHLWAPI) @LIBS@ -lz
 check_filetools_LDFLAGS = $(QT_CORE_LDFLAGS) $(ADD_FRAMEWORKS)
 check_filetools_SOURCES = \
tests/check_filetools.cpp \
tests/dummy_functions.cpp \
tests/boost.cpp
 
-check_lstrings_LDADD = liblyxsupport.a $(LIBICONV) $(QT_CORE_LIBS) 
$(LIBSHLWAPI) @LIBS@
+check_lstrings_LDADD = liblyxsupport.a $(LIBICONV) $(QT_CORE_LIBS) 
$(LIBSHLWAPI) @LIBS@ -lz
 check_lstrings_LDFLAGS = $(QT_CORE_LDFLAGS) $(ADD_FRAMEWORKS)
 check_lstrings_SOURCES = \
tests/check_lstrings.cpp \
tests/dummy_functions.cpp \
tests/boost.cpp
 
-check_trivstring_LDADD = liblyxsupport.a $(LIBICONV) $(QT_CORE_LIBS) 
$(LIBSHLWAPI) @LIBS@
+check_trivstring_LDADD = liblyxsupport.a $(LIBICONV) $(QT_CORE_LIBS) 
$(LIBSHLWAPI) @LIBS@ -lz
 check_trivstring_LDFLAGS = $(QT_CORE_LDFLAGS) $(ADD_FRAMEWORKS)
 check_trivstring_SOURCES = \
tests/check_trivstring.cpp \
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Patches for Python scripts

2021-01-31 Thread Enrico Forestieri 
On Sun, Jan 31, 2021 at 04:22:39AM +0100, Thibaut Cuvelier wrote:
> On Sat, 30 Jan 2021 at 12:26, Enrico Forestieri  wrote:
> > On Sat, Jan 30, 2021 at 05:31:05AM +0100, Thibaut Cuvelier wrote:
> > > On Sat, 30 Jan 2021 at 02:31, Enrico Forestieri  wrote:
> > > >
> > > > So, it seems that you have to check also for the 32-bit version.
> > > >
> > > Indeed. Would the attached patch solve the problem? I first look for a
> > > 64-bit version before a 32-bit, just to favour newer things, but there is
> > > no other reason to do so.
> >
> > The patch does not apply neither to current master nor to current stable
> > (most probably it depends on previous patches):
> >
> > $ patch --dry-run -p1 <
> > 0013-Configure-look-for-Java-in-the-registry-on-Windows.patch
> > checking file lib/configure.py
> > Hunk #1 FAILED at 330.
> > Hunk #2 succeeded at 403 (offset -14 lines).
> > Hunk #3 succeeded at 1923 (offset -94 lines).
> > 1 out of 3 hunks FAILED
> >
> > and I had to apply it manually. Before applying it, I took away java from
> > PATH and reconfigured:
> >
> > ...
> > checking for a java interpreter...
> > +checking for "java"...  no
> > ...
> >
> > Correctly, java was not found (it is found when it is in PATH).
> > Then I applied the patch an reconfigured again:
> >
> > ...
> > checking for a java interpreter...
> > +checking for "java"...  no
> > Traceback (most recent call last):
> >   File "C:\cygwin\win\python\lib\logging\__init__.py", line 870, in emit
> > stream.write(ufs % msg)
> > LookupError: unknown encoding: cp65001
> > Logged from file configure.py, line 346
> > ...
> >
> > I have a native Windows version of Python 2.7 installed in
> > "C:\cygwin\win\python".
> >
> > So, it seems there is a problem with Python 2
> >
> 
> I just tried with Python 2.7.18 (64 bits), I cannot reproduce your problem.
> What is exactly on your line 346? I guess it is something like logger.info,
> a line that runs without problem on my side (Python 3.8 and 2.7).

Yes, that's exactly "logger.info('+checking for java: ' + java_bin)".
It seems a problem related to the locale. I was reconfiguring from a
cygwin shell, whose locale is UTF-8, apparently something alien to
Windows. I now tried reconfiguring from a cmd.exe window and the result is:

...
checking for a java interpreter...
+checking for "java"...  no
+checking for java: C:\Program Files (x86)\Java\jre1.8.0_281\bin\java.exe
...

So, it works. However, to avoid confusion, you should avoid logging the
first negative result. Or, maybe, on Windows report something like this:

...
checking for a java interpreter...
+checking for "java" in PATH...  no
+checking for "java" in registry... C:\Program Files 
(x86)\Java\jre1.8.0_281\bin\java.exe
...

And, yes, I know making things work for everyone is exhausting...

Thank you for your efforts.

-- 
Enrico
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: LyX 2.4.0-alpha1

2021-01-31 Thread José Abílio Matos 
On Sunday, January 31, 2021 10:04:13 AM WET José Abílio Matos wrote:
> So the summary is that the compile only fails on the "make check" stage. The
> package built fine.

After this clue I searched on the logs of all architectures and the error is 
also present there.

Comparing the output with the latest build of lyx-2.3 with gcc-11 I see that 
the problem is not present there:
https://kojipkgs.fedoraproject.org//packages/lyx/2.3.6.1/2.fc34/data/logs/
x86_64/build.log 

So you are right that we only find this issue in lyx-2.4 and not in lyx-2.3.
Although the warning are scarier there like the violation of the "One 
Definition Rule" in C++.


So I suspect that to fix this in the autotools framework we need to link with 
libz on the check stage. How to this is out of my abilities. :-)

Best regards,
-- 
José Abílio-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: LyX 2.4.0-alpha1

2021-01-31 Thread José Abílio Matos 
On Sunday, January 31, 2021 6:56:31 AM WET Liviu Andronic wrote:
> I've tried building Alpha 1 on Bionic but compilation ends up with this
> error:
> 
> g++ -fPIC -O2 -std=c++17  -std=c++17  -g -O2
> -fdebug-prefix-map=/<>=. -fstack-protector-strong
> -Wformat -Werror=format-security   -Wl,-z,defs -Wl,--as-needed
> -Wl,-Bsymbolic-functions -Wl,-z,relro -o check_convert
> tests/check_convert.o tests/dummy_functions.o tests/boost.o
> liblyxsupport.a  -lQt5Core  -lmythes-1.2 -laspell  -lmagic
> /usr/bin/ld: liblyxsupport.a(checksum.o): undefined reference to symbol
> 'crc32' //lib/x86_64-linux-gnu/libz.so.1: error adding symbols: DSO missing
> from command line
> collect2: error: ld returned 1 exit status

This fails because there is a missing -lz in the g++ call.

This is strange because it is missing in support but is present in tex2lyx 
(immediately above).

Even more stranger I also get this error while compiling in:
https://download.copr.fedorainfracloud.org/results/jamatos/lyx-devel/epel-7-x86_64/01858213-lyx-devel/build.log.gz
 

All the build logs can be found at:
https://download.copr.fedorainfracloud.org/results/jamatos/lyx-devel/epel-7-x86_64/01858213-lyx-devel/
 

I get the error and yet the compile does not stop as the error is ignored... 
(scratch head)


OK, I found it.
We (purposely) ignore errors in the test stage, this is why the build 
proceeds. This is probably a remnant from previous versions.

So the summary is that the compile only fails on the "make check" stage. The 
package built fine.
-- 
José Abílio-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: LyX 2.4.0-alpha1

2021-01-31 Thread José Abílio Matos 
On Sunday, January 31, 2021 6:56:31 AM WET Liviu Andronic wrote:
> Any idea what's wrong? I'm not sure if maybe there are some new
> dependencies for 2.4 I should take into account or if maybe a specific
> compiler flag is needed.
> 
> 
> Thank you,
> Liviu

I am looking into it.

Note that I am building LyX with RHEL-7 that predates Bionic.
I have reviewed the spec files and there are no changes in the build 
requirements between 2.3 and 2.4.

I will look in the log file you referred to see if I get any clue and I will 
report it later.

-- 
José Abílio-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: DocBook to ePub

2021-01-31 Thread Stephan Witt 
Am 30.01.2021 um 04:56 schrieb Thibaut Cuvelier :
> 
> On Sat, 30 Jan 2021 at 01:30, Stephan Witt  wrote:
> Am 29.01.2021 um 18:38 schrieb Thibaut Cuvelier :
> > 
> > Dear list, 
> > 
> > As promised, I started working on ePub output, building upon the new 
> > DocBook output. 
> > 
> > Here is a script that performs the complete process of taking a DocBook 
> > file and generating the ePub. It has several dependencies: 
> > 
> > - an XSLT processor:
> >   • not xsltproc (http://xmlsoft.org/xslt/xsltproc2.html): available 
> > for most Linux distributions, I guess it is available by default on macOS, 
> > must be bundled for Windows. I tried several versions for Windows, but an 
> > old bug that should have been fixed in 1.1.24 (roughly 2010) is still 
> > there: 
> >   • I/O error : No such file or directory
> >   • xsltDocumentElem: unable to save to 
> > C:/Users/Thibaut/AppData/Local/Temp/tmp6c2i6a7h/OEBPS/package.opf
> >   • Saxon 6 (available for most Linux distributions, must be bundled 
> > for Windows and macOS, requires Java). It's outdated software (circa 2005), 
> > but newer versions are not 100% backward compatible, so it is still very 
> > widely used. Other DocBook stylesheets would work on newer Saxon, but they 
> > are not as reliable as the old ones (like 
> > https://github.com/docbook/xslTNG).
> >   • not MSXML6 (Windows-only, mostly built-it, but not compatible with 
> > the DocBook stylesheets — it wrongly errors with chunking) or .Net XSLT 
> > engine (nxslt/nxslt2).
> > - the official DocBook XSLT stylesheets. Three parts are required: XHTML, 
> > XHTML5, and ePub. For now, I copied the needed parts in a patch. On some 
> > Linux distributions, this could be replaced by a version installed by the 
> > package manager (Ubuntu 20.04 has a near-up-to-date version, although the 
> > latest one has been released in 2016: 
> > https://github.com/docbook/xslt10-stylesheets/releases/tag/release%2F1.79.2;
> >  Fedora is up-to-date).
> > 
> > The integration into LyX should be complete, minus testing on Linux and 
> > others and packaging issues: the dependencies must be included for Windows 
> > and macOS, not for all Linux distros. 
> 
> On macOS 10.14 (Mojave) I have:
> 
> $ xsltproc -V
> Using libxml 20904, libxslt 10129 and libexslt 817
> xsltproc was compiled against libxml 20904, libxslt 10129 and libexslt 817
> libxslt 10129 was compiled against libxml 20904
> libexslt 817 was compiled against libxml 20904
> 
> Why not?
> 
> I was not able to make xsltproc work on Windows with these stylesheets, it 
> gave many errors when creating new files. What if you try with the following 
> docbook2epub.py script (it goes in lib/scripts)? 

I’ve applied all (?) your patches and used the LyX made of it to export to ePub:

support/Systemcall.cpp (291): Systemcall: 'python scripts/docbook2epub.py 
"java" "Intro.xml" "Intro.epub"' finished with exit code 2
Error: Die Datei kann nicht konvertiert werden

Bei der Ausführung von
python $$s/scripts/docbook2epub.py "java" "Intro.xml" "Intro.epub"
ist ein Fehler aufgetreten

Can you please be more precise what to try? Ideally I can run some commands in 
terminal to diagnose the ePub export tool chain.
I don’t like to run them from LyX at first.

Stephan
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel