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

2017-03-21 Thread 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: System for continuous integration (CI) of LyX master branch, compiled on Ubuntu

2017-03-21 Thread 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

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

2017-03-20 Thread Jean-Marc Lasgouttes 

Le 20/03/2017 à 14:33, Jean-Marc Lasgouttes a écrit :

Le 20/03/2017 à 14:23, Jean-Marc Lasgouttes a écrit :


Here is the updated patch
- simplifies configure.ac because of the new enough automake.
- updates documentation
- fixes distclean
- fixes test_Length, which was leading to SIGSEGV
- add test_layout to lists of tests (was forgotten in Makefile.am)

What still does not work:
- distcheck

OK?


With the patch...


Updated version, AM_SILENT_RULES was missing.

JMarc

From 61b856c92ad94c9bb196aee1da34f9187944076a Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes 
Date: Thu, 26 Jan 2017 14:39:22 +0100
Subject: [PATCH] Require automake 1.14 and autoconf 2.65

This allows to fix distclean properly, since we know that
subdir-objects is used. When it is the case, it is not a good idea for
a Makefile to use a source file which is under the control of another
one. This could not be made to work work with old automake versions
(<1.14).

Therefore we refer to object files in Make.am instead of source files,
which leads to less compilation in tex2lyx BTW.

Renable the layout test and fix the Length test, which was ovewriting
memory in test_inPixels() because lyxrc did not had a correct layout.
---
 INSTALL   |4 +-
 autogen.sh|   12 +++---
 configure.ac  |   15 +++
 src/Makefile.am   |   90 ++---
 src/tests/dummy_functions.cpp |   67 ++
 src/tex2lyx/Makefile.am   |   50 +++
 6 files changed, 154 insertions(+), 84 deletions(-)
 create mode 100644 src/tests/dummy_functions.cpp

diff --git a/INSTALL b/INSTALL
index 5e75f61..8d3b609 100644
--- a/INSTALL
+++ b/INSTALL
@@ -36,8 +36,8 @@ Note for Git checkouts
 -
 
 If you have checked this out from Git, you need to have:
-* automake (supported versions are 1.8--1.15)
-* autoconf (supported versions are 2.60--2.69)
+* automake (supported versions are 1.14--1.15)
+* autoconf (supported versions are 2.65--2.69)
 Then type "./autogen.sh" to build the needed configuration
 files and proceed as stated above/below.
 
diff --git a/autogen.sh b/autogen.sh
index b58c27b..2cacc5c 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -11,16 +11,16 @@ automake_version=`$AUTOMAKE --version 2>/dev/null | head -n 1`
 test "$automake_version" != "" && {
 echo "Using $automake_version"
 } || {
-echo "LyX requires automake >= 1.8"
+echo "LyX requires automake >= 1.14"
 exit 1
 }
 
 case $automake_version in
-*' '1.[8-9]*|*' '1.1[012345]*)
+*' '1.1[45]*)
 	;;
 *)
 	echo "This automake version is not supported by LyX."
-	echo "LyX only supports automake 1.8 to 1.15."
+	echo "LyX only supports automake 1.14 to 1.15."
 	exit 1
 	;;
 esac
@@ -31,16 +31,16 @@ autoversion=`$AUTOCONF --version 2>/dev/null | head -n 1`
 test "$autoversion" != "" && {
 echo "Using $autoversion"
 } || {
-echo "LyX requires autoconf >= 2.60"
+echo "LyX requires autoconf >= 2.65"
 exit 1
 }
 
 case $autoversion in
-*' '2.60[ab]|*' '2.6[0-9])
+*' '2.6[5-9])
 	;;
 *)
 	echo "This autoconf version is not supported by LyX."
-	echo "LyX only supports autoconf 2.60-2.69."
+	echo "LyX only supports autoconf 2.65-2.69."
 	exit 1
 	;;
 esac
diff --git a/configure.ac b/configure.ac
index 694ddc4..5df8aa8 100644
--- a/configure.ac
+++ b/configure.ac
@@ -4,7 +4,7 @@ AC_INIT(LyX,2.3.0dev,[lyx-devel@lists.lyx.org],[lyx])
 AC_PRESERVE_HELP_ORDER
 # Use ISO format only. The frontend needs to parse this
 AC_SUBST(LYX_DATE, ["2016-04-16"])
-AC_PREREQ(2.60)
+AC_PREREQ(2.65)
 AC_CONFIG_SRCDIR(src/main.cpp)
 AC_CONFIG_HEADERS([config.h])
 
@@ -26,17 +26,12 @@ if test "${enable_maintainer_mode+set}" != set; then
   enable_maintainer_mode=$lyx_devel_version
 fi
 AM_MAINTAINER_MODE
-
-save_PACKAGE=$PACKAGE
-dnl The test for _AM_PROG_CC_C_O intends to test for automake 1.14 or newer,
-dnl which are the versions where subdir-objects can beused.
-dnl see: https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg181023.html
-m4_define([LYX_OBJECTS_LAYOUT], m4_ifdef([_AM_PROG_CC_C_O],[subdir-objects],))
+AM_SILENT_RULES([yes])
 # Automake is pulling the historical V7 format. This tar format supports
 # file names only up to 99 characters. tar-ustar selects the ustar format defined
 # by POSIX 1003.1-1988. This format is believed to be old enough to be portable.
-AM_INIT_AUTOMAKE([foreign dist-bzip2 no-define 1.8 tar-ustar] LYX_OBJECTS_LAYOUT)
-m4_ifdef([AM_SILENT_RULES],[AM_SILENT_RULES([yes])])
+save_PACKAGE=$PACKAGE
+AM_INIT_AUTOMAKE([foreign dist-bzip2 no-define 1.8 tar-ustar subdir-objects])
 PACKAGE=$save_PACKAGE
 
 # Allow to build some parts of the code as one big chunk
@@ -72,7 +67,7 @@ LYX_PATH_PYTHON23([2.7.0], [3.3.0])
 AM_PATH_PYTHON
 
 # Tools for creating libraries (note that we do not use libtool)
-m4_ifdef([AM_PROG_AR], [AM_PROG_AR]) dnl AM_PROG_AR requires automake 1.12

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

2017-03-20 Thread Jean-Marc Lasgouttes 

Le 20/03/2017 à 14:23, Jean-Marc Lasgouttes a écrit :


Here is the updated patch
- simplifies configure.ac because of the new enough automake.
- updates documentation
- fixes distclean
- fixes test_Length, which was leading to SIGSEGV
- add test_layout to lists of tests (was forgotten in Makefile.am)

What still does not work:
- distcheck

OK?


With the patch...

JMarc
From f45442181090cb6a6348b077bd02d0c15ad0cb8a Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes 
Date: Thu, 26 Jan 2017 14:39:22 +0100
Subject: [PATCH] Require automake 1.14 and autoconf 2.65

This allows to fix distclean properly, since we know that
subdir-objects is used. When it is the case, it is not a good idea for
a Makefile to use a source file which is under the control of another
one. This could not be made to work work with old automake versions
(<1.14).

Therefore we refer to object files in Make.am instead of source files,
which leads to less compilation in tex2lyx BTW.

Renable the layout test and fix the Length test, which was ovewriting
memory in test_inPixels() because lyxrc did not had a correct layout.
---
 INSTALL   |4 +-
 autogen.sh|   12 +++---
 configure.ac  |   11 ++---
 src/Makefile.am   |   90 ++---
 src/tests/dummy_functions.cpp |   67 ++
 src/tex2lyx/Makefile.am   |   50 +++
 6 files changed, 152 insertions(+), 82 deletions(-)
 create mode 100644 src/tests/dummy_functions.cpp

diff --git a/INSTALL b/INSTALL
index 5e75f61..8d3b609 100644
--- a/INSTALL
+++ b/INSTALL
@@ -36,8 +36,8 @@ Note for Git checkouts
 -
 
 If you have checked this out from Git, you need to have:
-* automake (supported versions are 1.8--1.15)
-* autoconf (supported versions are 2.60--2.69)
+* automake (supported versions are 1.14--1.15)
+* autoconf (supported versions are 2.65--2.69)
 Then type "./autogen.sh" to build the needed configuration
 files and proceed as stated above/below.
 
diff --git a/autogen.sh b/autogen.sh
index b58c27b..2cacc5c 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -11,16 +11,16 @@ automake_version=`$AUTOMAKE --version 2>/dev/null | head -n 1`
 test "$automake_version" != "" && {
 echo "Using $automake_version"
 } || {
-echo "LyX requires automake >= 1.8"
+echo "LyX requires automake >= 1.14"
 exit 1
 }
 
 case $automake_version in
-*' '1.[8-9]*|*' '1.1[012345]*)
+*' '1.1[45]*)
 	;;
 *)
 	echo "This automake version is not supported by LyX."
-	echo "LyX only supports automake 1.8 to 1.15."
+	echo "LyX only supports automake 1.14 to 1.15."
 	exit 1
 	;;
 esac
@@ -31,16 +31,16 @@ autoversion=`$AUTOCONF --version 2>/dev/null | head -n 1`
 test "$autoversion" != "" && {
 echo "Using $autoversion"
 } || {
-echo "LyX requires autoconf >= 2.60"
+echo "LyX requires autoconf >= 2.65"
 exit 1
 }
 
 case $autoversion in
-*' '2.60[ab]|*' '2.6[0-9])
+*' '2.6[5-9])
 	;;
 *)
 	echo "This autoconf version is not supported by LyX."
-	echo "LyX only supports autoconf 2.60-2.69."
+	echo "LyX only supports autoconf 2.65-2.69."
 	exit 1
 	;;
 esac
diff --git a/configure.ac b/configure.ac
index 694ddc4..b4598c5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -4,7 +4,7 @@ AC_INIT(LyX,2.3.0dev,[lyx-devel@lists.lyx.org],[lyx])
 AC_PRESERVE_HELP_ORDER
 # Use ISO format only. The frontend needs to parse this
 AC_SUBST(LYX_DATE, ["2016-04-16"])
-AC_PREREQ(2.60)
+AC_PREREQ(2.65)
 AC_CONFIG_SRCDIR(src/main.cpp)
 AC_CONFIG_HEADERS([config.h])
 
@@ -28,15 +28,10 @@ fi
 AM_MAINTAINER_MODE
 
 save_PACKAGE=$PACKAGE
-dnl The test for _AM_PROG_CC_C_O intends to test for automake 1.14 or newer,
-dnl which are the versions where subdir-objects can beused.
-dnl see: https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg181023.html
-m4_define([LYX_OBJECTS_LAYOUT], m4_ifdef([_AM_PROG_CC_C_O],[subdir-objects],))
 # Automake is pulling the historical V7 format. This tar format supports
 # file names only up to 99 characters. tar-ustar selects the ustar format defined
 # by POSIX 1003.1-1988. This format is believed to be old enough to be portable.
-AM_INIT_AUTOMAKE([foreign dist-bzip2 no-define 1.8 tar-ustar] LYX_OBJECTS_LAYOUT)
-m4_ifdef([AM_SILENT_RULES],[AM_SILENT_RULES([yes])])
+AM_INIT_AUTOMAKE([foreign dist-bzip2 no-define 1.8 tar-ustar subdir-objects])
 PACKAGE=$save_PACKAGE
 
 # Allow to build some parts of the code as one big chunk
@@ -72,7 +67,7 @@ LYX_PATH_PYTHON23([2.7.0], [3.3.0])
 AM_PATH_PYTHON
 
 # Tools for creating libraries (note that we do not use libtool)
-m4_ifdef([AM_PROG_AR], [AM_PROG_AR]) dnl AM_PROG_AR requires automake 1.12
+AM_PROG_AR
 AC_PROG_RANLIB
 dnl Recent debian/ubuntu (at least) have built 'ar' so that deterministic mode is the default.
 dnl This means that it does not make sense to use the 'u' flag (default ARFLAGS is 'cru').
diff --git a/src/Makefile.am

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

2017-03-20 Thread Jean-Marc Lasgouttes 

Le 20/03/2017 à 10:47, Jean-Marc Lasgouttes a écrit :

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.


Here is the updated patch
- simplifies configure.ac because of the new enough automake.
- updates documentation
- fixes distclean
- fixes test_Length, which was leading to SIGSEGV
- add test_layout to lists of tests (was forgotten in Makefile.am)

What still does not work:
- distcheck

OK?

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

2017-03-20 Thread Jean-Marc Lasgouttes 

Le 20/03/2017 à 08:30, Christian Ridderström a écrit :


On Mon, 6 Feb 2017 at 11:44, Jean-Marc Lasgouttes > wrote:


We could boldly (!) declare that we rely on automake 1.14 (Jun 2013),
since only developers (on antique systems like mine) would have to
adapt.


I believe this is the thread with the patch in question, related to the
current breakage of CI
job: 
https://ci.inria.fr/lyx/job/build-master-head/job/ubuntu-xenial-qt4-autotools-extended/


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.

JMarc

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

2017-03-20 Thread Christian Ridderström 
On Mon, 6 Feb 2017 at 11:44, Jean-Marc Lasgouttes 
wrote:

>
> We could boldly (!) declare that we rely on automake 1.14 (Jun 2013),
> since only developers (on antique systems like mine) would have to adapt.


I believe this is the thread with the patch in question, related to the
current breakage of CI job:
https://ci.inria.fr/lyx/job/build-master-head/job/ubuntu-xenial-qt4-autotools-extended/

/Christian

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

2017-01-30 Thread Pavel Sanda 
Jean-Marc Lasgouttes wrote:
> Le 25/01/2017 ? 10:01, Pavel Sanda a écrit :
>>> I am not sure why . is added explicitly here. What happens if we remove 
>>> it?
>>
>> bilions of
>> ...
>> make[3]: Entering directory 
>> '/home/paf/lyx/devel/lyx-2.3.0dev/_build/sub/src'
>> .deps/AppleSpellChecker.Po: No such file or directory
>
> Here is my take on the bug. This is the right thing to do with 
> subdir-objects option, which will be required with automake-2 (if this is 
> ever released), but does not work with versions earlier than 1.14.
>
> However, this breaks build with 1.11.
>
> I have another idea, we'll see how it fares, but here is the first take 
> anyway.

I can confirm that this patch fixed 1.15 distcheck.
Pavel

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

2017-01-26 Thread Jean-Marc Lasgouttes 

Le 25/01/2017 à 10:01, Pavel Sanda a écrit :

I am not sure why . is added explicitly here. What happens if we remove it?


bilions of
...
make[3]: Entering directory '/home/paf/lyx/devel/lyx-2.3.0dev/_build/sub/src'
.deps/AppleSpellChecker.Po: No such file or directory


Here is my take on the bug. This is the right thing to do with 
subdir-objects option, which will be required with automake-2 (if this 
is ever released), but does not work with versions earlier than 1.14.


However, this breaks build with 1.11.

I have another idea, we'll see how it fares, but here is the first take 
anyway.


JMarc
From 1b07d825083f2b5c80dd740230be70c2459c9944 Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes 
Date: Thu, 26 Jan 2017 14:39:22 +0100
Subject: [PATCH] Fix distclean for recent automake versions

When subdir-objects is used, it is not a good idea for a Makefile to
use a source file which is under the control of another one.

Therefore we refer to object files instead, which leads to less
compilation in tex2lyx BTW.

This will however not work with old automake versions (<1.14).
---
 src/Makefile.am   | 81 ---
 src/tests/dummy_functions.cpp | 56 ++
 src/tex2lyx/Makefile.am   | 50 +-
 3 files changed, 127 insertions(+), 60 deletions(-)
 create mode 100644 src/tests/dummy_functions.cpp

diff --git a/src/Makefile.am b/src/Makefile.am
index 3f3e99a..f0b1921 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -709,7 +709,9 @@ EXTRA_DIST += \
 	tests/regfiles/Length \
 	tests/regfiles/ListingsCaption \
 	tests/test_layout \
-	tests/test_Length
+	tests/test_Length \
+	tests/dummy_functions.cpp \
+	tests/boost.cpp
 
 TESTS = tests/test_ExternalTransforms tests/test_Length tests/test_ListingsCaption
 
@@ -738,57 +740,66 @@ ADD_FRAMEWORKS = -framework QtGui -framework QtCore -framework AppKit -framework
 endif
 
 check_layout_CPPFLAGS = $(AM_CPPFLAGS)
-check_layout_LDADD = support/liblyxsupport.a CiteEnginesList.o $(LIBICONV) $(BOOST_LIBS) @LIBS@ \
+check_layout_LDADD = $(check_layout_LYX_OBJS) support/liblyxsupport.a \
+	$(LIBICONV) $(BOOST_LIBS) @LIBS@ \
 	$(ICONV_LIBS) $(ZLIB_LIBS) $(QT_LIB) $(LIBSHLWAPI)
 check_layout_LDFLAGS = $(QT_LDFLAGS) $(ADD_FRAMEWORKS)
 check_layout_SOURCES = \
-	insets/InsetLayout.cpp \
-	Color.cpp \
-	Counters.cpp \
-	Floating.cpp \
-	FloatList.cpp \
-	FontInfo.cpp \
-	Layout.cpp \
-	LayoutFile.cpp \
-	Lexer.cpp \
-	ModuleList.cpp \
-	Spacing.cpp \
-	TextClass.cpp \
-	support/tests/dummy_functions.cpp \
-	tests/check_layout.cpp \
-	tests/boost.cpp
+	tests/check_layout.cpp
+check_layout_LYX_OBJS = \
+	insets/InsetLayout.o \
+	CiteEnginesList.o \
+	Color.o \
+	Counters.o \
+	Floating.o \
+	FloatList.o \
+	FontInfo.o \
+	Layout.o \
+	LayoutFile.o \
+	Lexer.o \
+	ModuleList.o \
+	Spacing.o \
+	TextClass.o \
+	tests/dummy_functions.o \
+	tests/boost.o
 
 check_ExternalTransforms_CPPFLAGS = $(AM_CPPFLAGS)
-check_ExternalTransforms_LDADD = support/liblyxsupport.a $(LIBICONV) $(BOOST_LIBS) @LIBS@ \
+check_ExternalTransforms_LDADD = $(check_ExternalTransforms_LYX_OBJS) support/liblyxsupport.a \
+	$(LIBICONV) $(BOOST_LIBS) @LIBS@ \
 	$(ICONV_LIBS) $(ZLIB_LIBS) $(QT_LIB) $(LIBSHLWAPI)
 check_ExternalTransforms_LDFLAGS = $(QT_LDFLAGS) $(ADD_FRAMEWORKS)
 check_ExternalTransforms_SOURCES = \
-	graphics/GraphicsParams.cpp \
-	insets/ExternalTransforms.cpp \
-	Length.cpp \
-	lengthcommon.cpp \
-	support/tests/dummy_functions.cpp \
-	tests/check_ExternalTransforms.cpp \
-	tests/boost.cpp
+	tests/check_ExternalTransforms.cpp
+check_ExternalTransforms_LYX_OBJS = \
+	tests/dummy_functions.o \
+	tests/boost.o \
+	graphics/GraphicsParams.o \
+	insets/ExternalTransforms.o \
+	Length.o \
+	lengthcommon.o
 
 check_Length_CPPFLAGS = $(AM_CPPFLAGS)
-check_Length_LDADD = support/liblyxsupport.a $(LIBICONV) $(BOOST_LIBS) @LIBS@ \
+check_Length_LDADD = $(check_Length_LYX_OBJS) support/liblyxsupport.a \
+	$(LIBICONV) $(BOOST_LIBS) @LIBS@ \
 	$(ICONV_LIBS) $(ZLIB_LIBS) $(QT_LIB) $(LIBSHLWAPI)
 check_Length_LDFLAGS = $(QT_LDFLAGS) $(ADD_FRAMEWORKS)
 check_Length_SOURCES = \
-	Length.cpp \
-	lengthcommon.cpp \
-	support/tests/dummy_functions.cpp \
-	tests/check_Length.cpp \
-	tests/boost.cpp
+	tests/check_Length.cpp
+check_Length_LYX_OBJS = \
+	tests/dummy_functions.o \
+	tests/boost.o \
+	Length.o \
+	lengthcommon.o
 
 check_ListingsCaption_CPPFLAGS = $(AM_CPPFLAGS)
-check_ListingsCaption_LDADD = support/liblyxsupport.a $(LIBICONV) $(BOOST_LIBS) @LIBS@ \
+check_ListingsCaption_LDADD = $(check_ListingsCaption_LYX_OBJS) support/liblyxsupport.a \
+	$(LIBICONV) $(BOOST_LIBS) @LIBS@ \
 	$(ICONV_LIBS) $(ZLIB_LIBS) $(QT_LIB) $(LIBSHLWAPI)
 check_ListingsCaption_LDFLAGS = $(QT_LDFLAGS) $(ADD_FRAMEWORKS)
 check_ListingsCaption_SOURCES = \
-	support/tests/dummy_functions.cpp \
-	tests/check_ListingsCaption.cpp \
-	tests/boost.cpp
+	tests/check_ListingsCaption.cpp
+check_ListingsCaption_LYX_OBJS = \
+

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

2017-01-25 Thread Pavel Sanda 
Jean-Marc Lasgouttes wrote:
> Le 24/01/2017 ? 10:25, Pavel Sanda a écrit :
>> which has to obviously fail because we deleted tests/.deps already.
>>
>> JMarc, do you have idea about the fix?
>
> I suspect this is related to our SUBDIRS variable
>
> SUBDIRS = support frontends . $(CLIENT) tex2lyx

My guess is that the solution might be separate makefile for test subdir.

> I am not sure why . is added explicitly here. What happens if we remove it?

bilions of
...
make[3]: Entering directory '/home/paf/lyx/devel/lyx-2.3.0dev/_build/sub/src'
.deps/AppleSpellChecker.Po: No such file or directory
...
Makefile:2455: support/tests/.deps/check_layout-dummy_functions.Po: No such 
file or directory
make[3]: *** No rule to make target 
'support/tests/.deps/check_layout-dummy_functions.Po'.  Stop.
make[3]: Leaving directory '/home/paf/lyx/devel/lyx-2.3.0dev/_build/sub/src'
Makefile:2908: recipe for target 'distclean-recursive' failed
...

Pavel

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

2017-01-25 Thread Pavel Sanda 
Christian Ridderström wrote:
> Using automake (GNU automake) 1.14.1
> 
> Using autoconf (GNU Autoconf) 2.69
> 
> but it still fails at the same place.
> 
> Do you know a version of automake for which it works?

automake (GNU automake) 1.11.3
autoconf (GNU Autoconf) 2.68

P

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

2017-01-24 Thread Christian Ridderström 
On 24 January 2017 at 10:25, Pavel Sanda  wrote:

> > The job that builds with autotools and qt4 fails during 'make distclean'
> > within 'make distcheck'.
> > Here's a link to the console output:
>
> I looked into the issue and it is caused by the fact that you use new
> autotools (automake 1.15).
>

I tried it again with:

Using automake (GNU automake) 1.14.1

Using autoconf (GNU Autoconf) 2.69

but it still fails at the same place.

Do you know a version of automake for which it works?
/Christian
PS.
I don't mean we should leave it as it is, I think it's a bug that we can't
build with the automake version coming with Ubuntu 16.05.
But I thought for now we could create a separate CI job where it works
using some previous version of automake.

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

2017-01-24 Thread Jean-Marc Lasgouttes 

Le 24/01/2017 à 10:25, Pavel Sanda a écrit :

which has to obviously fail because we deleted tests/.deps already.

JMarc, do you have idea about the fix?


I suspect this is related to our SUBDIRS variable

SUBDIRS = support frontends . $(CLIENT) tex2lyx

I am not sure why . is added explicitly here. What happens if we remove it?

JMarc

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

2017-01-24 Thread Pavel Sanda 
Christian Ridderström wrote:
> > > Yes, it will, hopefully we will get this fixed within next few days.
> >
> > distcheck works for me right now.
> >
> 
> The job that builds with autotools and qt4 fails during 'make distclean'
> within 'make distcheck'.
> Here's a link to the console output:

I looked into the issue and it is caused by the fact that you use new autotools 
(automake 1.15).

For some reasons dependencies are created differently now:
older autotools produce in src/Makefile.in e.g.:
@AMDEP_TRUE@@am__include@ 
@am__quote@./$(DEPDIR)/check_ListingsCaption-dummy_functions.Po@am__quote@
and creates pulls all .Po files together into e.g 
./lyx-2.3.0dev/_build/src/.deps/check_ListingsCaption-dummy_functions.Po


while newer suddenly start recognizing directory structure of deps listed int 
check_*_SOURCES, i.e.:
@AMDEP_TRUE@@am__include@ 
@am__quote@support/tests/$(DEPDIR)/check_ListingsCaption-dummy_functions.Po@am__quote@
and creates dir structure, e.g.: 
lyx-2.3.0dev/_build/sub/src/support/tests/.deps/check_ListingsCaption-dummy_functions.Po


Now, while doing distclean:
make[3]: Entering directory '/usr/src/lyx/lyx-2.3.0dev/_build/sub/src/support'
..
rm -rf ./.deps linkback/.deps mythes/.deps tests/.deps
..
Leaving directory '/usr/src/lyx/lyx-2.3.0dev/_build/sub/src/support
..
Entering directory '/usr/src/lyx/lyx-2.3.0dev/_build/sub/src
Makefile:2453: support/tests/.deps/check_ExternalTransforms-dummy_functions.Po: 
No such file or directory


which has to obviously fail because we deleted tests/.deps already.

JMarc, do you have idea about the fix?

Pavel

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

2017-01-20 Thread Enrico Forestieri 
On Thu, Jan 19, 2017 at 04:29:21PM -0800, Pavel Sanda wrote:

> Christian Ridderström wrote:
> > I actually wanted to test building with Qt5, but I couldn't (easily) get it
> > to work with autotools...
> > I assume I'm either missing some dependencies or I'm not using correct
> > arguments to e.g. ./configure.
> 
> If you have all deps, then configure needs --enable-qt5. Can't tell you more
> still on qt4.

If you use debian, you may also have to "export QT_SELECT=qt5" to force the
use of Qt5.

-- 
Enrico

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

2017-01-20 Thread Kornel Benko 
Am Donnerstag, 19. Januar 2017 um 23:47:49, schrieb Christian Ridderström 

> On 19 January 2017 at 16:30, Kornel Benko  wrote:
> 
> > > # Change directory to folder with cloned LyX repository
> >
> > Clone is not needed normally iff used only by cmake.
> >
> 
> The cloning is automatically done by the CI server / CI job, pulling the
> latest changes from git.lyx.org.
> 
> > This will build LyX and only then do 'make package_source'.  Anything else
> > > that should be in there?
> >
> > On ubuntu I use 'make package' to build everything.
> > E.g.
> > #CMAKE_OPTS= "-DLYX_USE_QT=QT5 -DLYX_CPACK=ON
> > -DCPACK_BINARY_DEB:BOOL=ON -DCPACK_SOURCE_TGZ:BOOL=ON -DLYX_NLS=ON
> > -DLYX_EXTERNAL_Z=ON -DLYX_EXTERNAL_ICONV=ON -DLYX_EXTERNAL_BOOST=OFF"
> > #cmake .. $CMAKE_OPTS && make package && make package_source
> >
> >
> I don't actually know what these options do, but the CI job is now using
> them.

-DLYX_CPACK=ON  Uses the cpack macros
-DCPACK_BINARY_DEB:BOOL=ON  configures for creation the debian .deb 
package,
(e.g. 'make 
package') ready to install with dpkg -i $packagename
-DCPACK_SOURCE_TGZ:BOOL=ON  configures for creation of source 
package (make package_source)
-DLYX_NLS=ONuse xgettext, msgfmt, msgmerge 
etc for creation of .gmo files
-DLYX_EXTERNAL_Z=ON use external libz because of 
conflicts with our supplied sources (valid for windows? only)
-DLYX_EXTERNAL_ICONV=ON use external libiconv because of 
conflicts with our supplied sources (valid for windows? only)
-DLYX_EXTERNAL_BOOST=OFFuse our supplied boost sources

> To be specific, this is the script that's being run to build:
> 
> https://github.com/DrChr/build-lyx-using-ubuntu-latest-qt5-cmake/blob/master/build_lyx.sh
> 

Yes, that should work.

The ultimate check would be
# make package_source
# mkdir src2
# cd src2
# tar axf ../LyX-2.3.tar.gz # creates source tree starting with 
"LyX-2.3/"
# mkdir build2  # e.g. $top/build/build2
# cd build2
# cmake ../LyX-2.3 $CMAKE_OPTS
# make package

> /Christian

Kornel

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

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

2017-01-20 Thread Christian Ridderström 
On 20 January 2017 at 02:05, Pavel Sanda  wrote:

> Pavel Sanda wrote:
> > > However, I expect that this job will fail like before, but at least
> the job
> > > is setup.
> >
> > Yes, it will, hopefully we will get this fixed within next few days.
>
> distcheck works for me right now.
>

The job that builds with autotools and qt4 fails during 'make distclean'
within 'make distcheck'.
Here's a link to the console output:

https://ci.inria.fr/lyx/job/build-master-head/job/ubuntu-xenial-qt4-autotools-extended/4/console
I've copied in the last part of the output at the end of this email

The setup of the Docker container (sort of a light weight VM) that contains
the build environment can be seen here:

https://github.com/DrChr/build-lyx-using-ubuntu-xenial-qt4-autotools/blob/master/Dockerfile
but it's just these steps:
FROM ubuntu:16.04
MAINTAINER Christian Ridderström 

# Install tools and libraries needed to build LyX
RUN apt-get update \
&& DEBIAN_FRONTEND=noninteractive apt-get install -y \
build-essential \
automake \
autoconf \
zlib1g-dev \
pkg-config \
&& DEBIAN_FRONTEND=noninteractive apt-get build-dep -y \
lyx \

&& rm -rf /var/lib/apt/lists/*

The actual build commands are as seen in this script

https://github.com/DrChr/build-lyx-using-ubuntu-xenial-qt4-autotools/blob/master/build_lyx_extended.sh
which are just

do_or_fail ./autogen.sh
do_or_fail ./configure
do_or_fail make
do_or_fail make check
do_or_fail make distcheck

The log indicates it works up to "make check" and the error happens during
"make distcheck".
Below is the very last bit of the log output. Within the "make distcheck",
it seems that "make distclean" fails.
/Christian

rm -f Makefile
make[3]: Leaving directory '/usr/src/lyx/lyx-2.3.0dev/_build/sub/src/frontends'
Making distclean in .
make[3]: Entering directory '/usr/src/lyx/lyx-2.3.0dev/_build/sub/src'
Makefile:2453: support/tests/.deps/check_ExternalTransforms-dummy_functions.Po:
No such file or directory
Makefile:2454: support/tests/.deps/check_Length-dummy_functions.Po: No
such file or directory
Makefile:2455: support/tests/.deps/check_ListingsCaption-dummy_functions.Po:
No such file or directory
Makefile:2456: support/tests/.deps/check_layout-dummy_functions.Po: No
such file or directory
make[3]: *** No rule to make target
'support/tests/.deps/check_layout-dummy_functions.Po'.  Stop.
make[3]: Leaving directory '/usr/src/lyx/lyx-2.3.0dev/_build/sub/src'
Makefile:2909: recipe for target 'distclean-recursive' failed
make[2]: *** [distclean-recursive] Error 1
make[2]: Leaving directory '/usr/src/lyx/lyx-2.3.0dev/_build/sub/src'
Makefile:574: recipe for target 'distclean-recursive' failed
make[1]: Leaving directory '/usr/src/lyx/lyx-2.3.0dev/_build/sub'
make[1]: *** [distclean-recursive] Error 1
Makefile:779: recipe for target 'distcheck' failed
make: *** [distcheck] Error 1
Command 'make distcheck' failed, exiting





> Pavel
>

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

2017-01-19 Thread Pavel Sanda 
Pavel Sanda wrote:
> > However, I expect that this job will fail like before, but at least the job
> > is setup.
> 
> Yes, it will, hopefully we will get this fixed within next few days.

distcheck works for me right now.

Pavel

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

2017-01-19 Thread Pavel Sanda 
Christian Ridderström wrote:
> I actually wanted to test building with Qt5, but I couldn't (easily) get it
> to work with autotools...
> I assume I'm either missing some dependencies or I'm not using correct
> arguments to e.g. ./configure.

If you have all deps, then configure needs --enable-qt5. Can't tell you more
still on qt4.

> However, I expect that this job will fail like before, but at least the job
> is setup.

Yes, it will, hopefully we will get this fixed within next few days.

> Generating doxygen docs should be easy. If someone can give me the
> dependencies and the commands to execute, I can set up such a job.

deps: doxygen, graphviz, maybe latex was needed as well for graphs, not sure 
anymore
command: make doxydoc

Pavel

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

2017-01-19 Thread Christian Ridderström 
On 19 January 2017 at 20:57, Pavel Sanda  wrote:

>
> If you want test cmake as well you can, but please run autotools, I am
> going to debug
> primarily that.
>

I actually wanted to test building with Qt5, but I couldn't (easily) get it
to work with autotools...
I assume I'm either missing some dependencies or I'm not using correct
arguments to e.g. ./configure.



> > #!/bin/sh
> > # Change directory to folder with cloned LyX repository
> > cd "$1"
>
> Good way how test autotools is eg. this:
>
> git reset --hard && git clean -xdf && ./autogen.sh &&
> ./configure &&
> make &&
> make check &&
> make distcheck &&
> echo "GOOD"
>
> If you use clean checkout already you can omit the git part.
>

I've added the above to another build script

https://github.com/DrChr/build-lyx-using-ubuntu-xenial-qt4-autotools/blob/master/build_lyx_extended.sh

I've then created another CI job that uses this script for the build step:

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

However, I expect that this job will fail like before, but at least the job
is setup.
With e-mail notifications, so there should be an e-mail in a while
regarding this..

> This will build LyX and only then do 'make package_source'.  Anything else
> > that should be in there?
>
> This will test compilation, making tarballs, compiling, installing,
> uninstalling
> from tarballs.
>

Ok it'll be really good if we all of that to be tested automatically.


> Another things which we could try in next round is monolithic build and
> it maybe easy wit this machinery to update our web:
> - translations statistics
> - doxygen docs
> - contributions
> ?


Generating doxygen docs should be easy. If someone can give me the
dependencies and the commands to execute, I can set up such a job.

/Christian

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

2017-01-19 Thread Christian Ridderström 
On 19 January 2017 at 16:30, Kornel Benko  wrote:

> > # Change directory to folder with cloned LyX repository
>
> Clone is not needed normally iff used only by cmake.
>

The cloning is automatically done by the CI server / CI job, pulling the
latest changes from git.lyx.org.

> This will build LyX and only then do 'make package_source'.  Anything else
> > that should be in there?
>
> On ubuntu I use 'make package' to build everything.
> E.g.
> #CMAKE_OPTS= "-DLYX_USE_QT=QT5 -DLYX_CPACK=ON
> -DCPACK_BINARY_DEB:BOOL=ON -DCPACK_SOURCE_TGZ:BOOL=ON -DLYX_NLS=ON
> -DLYX_EXTERNAL_Z=ON -DLYX_EXTERNAL_ICONV=ON -DLYX_EXTERNAL_BOOST=OFF"
> #cmake .. $CMAKE_OPTS && make package && make package_source
>
>
I don't actually know what these options do, but the CI job is now using
them. To be specific, this is the script that's being run to build:

https://github.com/DrChr/build-lyx-using-ubuntu-latest-qt5-cmake/blob/master/build_lyx.sh


/Christian

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

2017-01-19 Thread Pavel Sanda 
Christian Ridderström wrote:
> On 19 January 2017 at 09:28, Kornel Benko  wrote:
> 
> > The equivalent target for cmake is called "package_source". The result can
> > be
> > LyX-2.3.tar.gz, LyX-2.3.tar.xz, or LyX-2.3.zip
> > depending on configure parameters.
> >
> > e.g.
> > #cmake .. -DLYX_USE_QT=QT5 -DLYX_CPACK=ON
> > -DCPACK_SOURCE_TGZ:BOOL=ON
> > #make package_source
> > should produce LyX-2.3.tar.gz.
> >
> 
> Is it correct that
>make package_source
> will not actually build LyX?  I was expecting 'make package_source' to
> depend on first building LyX, but perhaps that's not needed.
> 
> For the purpose of doing a build test in the CI system, would the following
> build script then be appropriate?

If you want test cmake as well you can, but please run autotools, I am going to 
debug
primarily that.

> #!/bin/sh
> # Change directory to folder with cloned LyX repository
> cd "$1"

Good way how test autotools is eg. this:

git reset --hard && git clean -xdf && ./autogen.sh &&   

   
./configure &&  

   
make && 

   
make check &&   

   
make distcheck &&   

   
echo "GOOD"  

If you use clean checkout already you can omit the git part.

> This will build LyX and only then do 'make package_source'.  Anything else
> that should be in there?

This will test compilation, making tarballs, compiling, installing, uninstalling
from tarballs.


Another things which we could try in next round is monolithic build and
it maybe easy wit this machinery to update our web:
- translations statistics
- doxygen docs
- contributions
?

Pavel

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

2017-01-19 Thread Kornel Benko 
Am Donnerstag, 19. Januar 2017 um 15:45:43, schrieb Christian Ridderström 

> On 19 January 2017 at 09:28, Kornel Benko  wrote:
> 
> > The equivalent target for cmake is called "package_source". The result can
> > be
> > LyX-2.3.tar.gz, LyX-2.3.tar.xz, or LyX-2.3.zip
> > depending on configure parameters.
> >
> > e.g.
> > #cmake .. -DLYX_USE_QT=QT5 -DLYX_CPACK=ON
> > -DCPACK_SOURCE_TGZ:BOOL=ON
> > #make package_source
> > should produce LyX-2.3.tar.gz.
> >
> 
> Is it correct that
>make package_source
> will not actually build LyX?

Yes, that is my understanding.

> I was expecting 'make package_source' to
> depend on first building LyX, but perhaps that's not needed.
> 
> For the purpose of doing a build test in the CI system, would the following
> build script then be appropriate?
> 
> #!/bin/sh
> 
> 
> 
> 
> # Change directory to folder with cloned LyX repository
 
Clone is not needed normally iff used only by cmake.

> 
> cd "$1"
> 
> 
> # Add a directory out-of-source for building
> 
> 
> 
> mkdir -p build
> 
> cd build
> 
> CMAKE_OPTS="-DLYX_USE_QT=QT5  -DLYX_CPACK=ON  -DCPACK_SOURCE_TGZ:BOOL=ON"
> 
> cmake $CMAKE_OPTS .. && make && make package_source
> 
> This will build LyX and only then do 'make package_source'.  Anything else
> that should be in there?

On ubuntu I use 'make package' to build everything.
E.g.
#CMAKE_OPTS= "-DLYX_USE_QT=QT5 -DLYX_CPACK=ON 
-DCPACK_BINARY_DEB:BOOL=ON -DCPACK_SOURCE_TGZ:BOOL=ON -DLYX_NLS=ON 
-DLYX_EXTERNAL_Z=ON -DLYX_EXTERNAL_ICONV=ON -DLYX_EXTERNAL_BOOST=OFF"
#cmake .. $CMAKE_OPTS && make package && make package_source

> /Christian
> 
> 
 Kornel


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

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

2017-01-19 Thread Jean-Marc Lasgouttes 

Le 19/01/2017 à 12:44, Christian Ridderström a écrit :

Could someone perhaps ask Maté (?) if he can add ci-...@inria.fr
 to the devel-list?


I did this and he did that.

JMarc

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

2017-01-19 Thread Christian Ridderström 
On 19 January 2017 at 09:28, Kornel Benko  wrote:

> The equivalent target for cmake is called "package_source". The result can
> be
> LyX-2.3.tar.gz, LyX-2.3.tar.xz, or LyX-2.3.zip
> depending on configure parameters.
>
> e.g.
> #cmake .. -DLYX_USE_QT=QT5 -DLYX_CPACK=ON
> -DCPACK_SOURCE_TGZ:BOOL=ON
> #make package_source
> should produce LyX-2.3.tar.gz.
>

Is it correct that
   make package_source
will not actually build LyX?  I was expecting 'make package_source' to
depend on first building LyX, but perhaps that's not needed.

For the purpose of doing a build test in the CI system, would the following
build script then be appropriate?

#!/bin/sh




# Change directory to folder with cloned LyX repository



cd "$1"


# Add a directory out-of-source for building



mkdir -p build

cd build

CMAKE_OPTS="-DLYX_USE_QT=QT5  -DLYX_CPACK=ON  -DCPACK_SOURCE_TGZ:BOOL=ON"

cmake $CMAKE_OPTS .. && make && make package_source

This will build LyX and only then do 'make package_source'.  Anything else
that should be in there?
/Christian


> Kornel
>
>


-- 
Christian Ridderström, +46-70 687 39 44

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

2017-01-19 Thread Christian Ridderström 
On 19 January 2017 at 03:53, Pavel Sanda  wrote:

> Christian Ridderström wrote:
> > The Jenkins SW is capable of sending an e-mail, I just tested to two of
> my
> > e-mail addresses.
> > But to where should e-mails be sent - lyx-devel-list?
>
> I would think so, unless other people are not against it.


If we don't hear objections, let's go for this. We can change it if it
spams us.


> > I think the sender, ci-...@inria.fr, needs to be added to a list of
> > approved addresses or something.
>
> Can you receive mails from ci-...@inria.fr?
>

I don't know if its possible, nor how I'd read the answers :-(
I've googled a bit without luck. And I found a mailing list for Inria's CI
stuff, but it's in french - so something for Jean-Marc or Guillaume to look
at perhaps.

I have however (most likely) gotten the CI server (Jenkins) to send an
e-mail to lyx-devel-subscr...@lists.lyx.org, not that it helps us with by
itself.

For info: To send a test e-mail from the CI server, go to the bottom of
this page (you have to be logged in): https://ci.inria.fr/lyx/configure
In the menu system this corresponds to Jenkins / Manage Jenkins / Configure
System. Then it's under the heading of "E-mail notification" at the bottom.

Could someone perhaps ask Maté (?) if he can add ci-...@inria.fr to the
devel-list?


> If yes then just sent from that address email to
> lyx-devel-subscr...@lists.lyx.org
> and reply to the mail you get.
> From that point ci-...@inria.fr mails should be accepted.
> (I am not sure whether ci-...@inria.fr has to be used for envelope
> are just correct From: header is enough for our list, you have to try :)
>

I actually don't know how to forge the from header, maybe I should learn :-)
/Christian

-- 
Christian Ridderström, +46-70 687 39 44

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

2017-01-19 Thread Kornel Benko 
Am Mittwoch, 18. Januar 2017 um 18:53:17, schrieb Pavel Sanda 
> Christian Ridderström wrote:
> > The Jenkins SW is capable of sending an e-mail, I just tested to two of my
> > e-mail addresses.
> > But to where should e-mails be sent - lyx-devel-list?
> 
> I would think so, unless other people are not against it.
> 
> > I think the sender, ci-...@inria.fr, needs to be added to a list of
> > approved addresses or something.
> 
> Can you receive mails from ci-...@inria.fr?
> If yes then just sent from that address email to 
> lyx-devel-subscr...@lists.lyx.org
> and reply to the mail you get.
> From that point ci-...@inria.fr mails should be accepted.
> (I am not sure whether ci-...@inria.fr has to be used for envelope
> are just correct From: header is enough for our list, you have to try :)
> 
> > It's the same error I get.
> 
> Yes, if you get this machinery working, I will invest some time
> to clean up distcheck (again...) so we can start fresh.
> 
> P

The equivalent target for cmake is called "package_source". The result can be
LyX-2.3.tar.gz, LyX-2.3.tar.xz, or LyX-2.3.zip
depending on configure parameters.

e.g.
#cmake .. -DLYX_USE_QT=QT5 -DLYX_CPACK=ON -DCPACK_SOURCE_TGZ:BOOL=ON
#make package_source
should produce LyX-2.3.tar.gz.

Kornel



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

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

2017-01-18 Thread Pavel Sanda 
Christian Ridderström wrote:
> The Jenkins SW is capable of sending an e-mail, I just tested to two of my
> e-mail addresses.
> But to where should e-mails be sent - lyx-devel-list?

I would think so, unless other people are not against it.

> I think the sender, ci-...@inria.fr, needs to be added to a list of
> approved addresses or something.

Can you receive mails from ci-...@inria.fr?
If yes then just sent from that address email to 
lyx-devel-subscr...@lists.lyx.org
and reply to the mail you get.
>From that point ci-...@inria.fr mails should be accepted.
(I am not sure whether ci-...@inria.fr has to be used for envelope
are just correct From: header is enough for our list, you have to try :)

> It's the same error I get.

Yes, if you get this machinery working, I will invest some time
to clean up distcheck (again...) so we can start fresh.

P

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

2017-01-18 Thread Christian Ridderström 
On 19 January 2017 at 03:17, Pavel Sanda  wrote:

> >
> > Trying with just "make distcheck" instead of "make" produced error about
> > missing target 'distcheck'.
>
> distcheck is autotools not cmake target. Since we (still) build tarballs
> via automake it would be worth using this target.
>

Ok, understood.


> I just tried running make distcheck here and immediately got error,
> which is exactly why your machinery could be useful!
>

I get the same error (output attached below) for doing 'make && make
distcheck'


> Simply running distcheck once a day and send email to lyx-devel in case of
> error.
>
> Otherwise it can take quite some time to find the offender (the error
> messages are sometimes convoluted).
>
> > There seems to be RSS feeds available right now (see bottom right corner
> of
> > https://ci.inria.fr/lyx/ ) that I was able to add to my RSS reader (
> > http://theoldreader.com) . It's probably also possible to get the CI
> server
> > to send e-mail notifications to lyx-devel, assuming we want that?
>
> If you don't have SMTP machinery working on that machine I can send you
> simple
> shell script that would do the sending job. You just need port 25 open &
> SMTP
> server accepting us.
>

The Jenkins SW is capable of sending an e-mail, I just tested to two of my
e-mail addresses.
But to where should e-mails be sent - lyx-devel-list?

I think the sender, ci-...@inria.fr, needs to be added to a list of
approved addresses or something.
/Christian


>
> Pavel
>
> PS: the current err if it rings bell to someone, I guess just entry in
> makefile is missing:
> make[1]: *** No rule to make target `export/ja/wrong_auto_encoding.lyx',
> needed
>

It's the same error I get.
Below's my full log:

# make distcheck

make  dist-bzip2 dist-gzip am__post_remove_distdir='@:'

make[1]: Entering directory '/usr/src/lyx'

if test -d "lyx-2.3.0dev"; then find "lyx-2.3.0dev" -type d ! -perm -200
-exec chmod u+w {} ';' && rm -rf "lyx-2.3.0dev" || { sleep 5 && rm -rf
"lyx-2.3.0dev"; }; else :; fi

test -d "lyx-2.3.0dev" || mkdir "lyx-2.3.0dev"

 (cd 3rdparty && make  top_distdir=../lyx-2.3.0dev
distdir=../lyx-2.3.0dev/3rdparty \

 am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=:
distdir)

make[2]: Entering directory '/usr/src/lyx/3rdparty'

 (cd boost && make  top_distdir=../../lyx-2.3.0dev
distdir=../../lyx-2.3.0dev/3rdparty/boost \

 am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=:
distdir)

make[3]: Entering directory '/usr/src/lyx/3rdparty/boost'

make[3]: Leaving directory '/usr/src/lyx/3rdparty/boost'

 (cd hunspell && make  top_distdir=../../lyx-2.3.0dev
distdir=../../lyx-2.3.0dev/3rdparty/hunspell \

 am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=:
distdir)

make[3]: Entering directory '/usr/src/lyx/3rdparty/hunspell'

make[3]: Leaving directory '/usr/src/lyx/3rdparty/hunspell'

 (cd libiconv && make  top_distdir=../../lyx-2.3.0dev
distdir=../../lyx-2.3.0dev/3rdparty/libiconv \

 am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=:
distdir)

make[3]: Entering directory '/usr/src/lyx/3rdparty/libiconv'

make[3]: Leaving directory '/usr/src/lyx/3rdparty/libiconv'

 (cd zlib && make  top_distdir=../../lyx-2.3.0dev
distdir=../../lyx-2.3.0dev/3rdparty/zlib \

 am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=:
distdir)

make[3]: Entering directory '/usr/src/lyx/3rdparty/zlib'

make[3]: Leaving directory '/usr/src/lyx/3rdparty/zlib'

make[2]: Leaving directory '/usr/src/lyx/3rdparty'

 (cd autotests && make  top_distdir=../lyx-2.3.0dev
distdir=../lyx-2.3.0dev/autotests \

 am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=:
distdir)

make[2]: Entering directory '/usr/src/lyx/autotests'

make[2]: *** No rule to make target 'export/ja/wrong_auto_encoding.lyx',
needed by 'distdir'.  Stop.

make[2]: Leaving directory '/usr/src/lyx/autotests'

Makefile:674: recipe for target 'distdir' failed

make[1]: *** [distdir] Error 1

make[1]: Leaving directory '/usr/src/lyx'

Makefile:772: recipe for target 'dist' failed

make: *** [dist] Error 2




-- 
Christian Ridderström, +46-70 687 39 44

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

2017-01-18 Thread Pavel Sanda 
Christian Ridderström wrote:
> On 19 January 2017 at 01:45, Pavel Sanda  wrote:
> 
> > > The system is currently doing this:
> > > - Polls the LyX repository at git.lyx.org  (every few hours)
> > > - If branch 'master' has changed, then it builds LyX in two different
> > > configurations
> >
> > What you mean by build? "make" or "make distcheck"?
> >
> The second one would be more useful,
> 
> 
> Currently it's "make" (I didn't know about distcheck), e.g. the CMake
> version does this:
> 
> cmake -DLYX_USE_QT=QT5 .. && make
> 
> Trying with just "make distcheck" instead of "make" produced error about
> missing target 'distcheck'.

distcheck is autotools not cmake target. Since we (still) build tarballs
via automake it would be worth using this target.

I just tried running make distcheck here and immediately got error,
which is exactly why your machinery could be useful!

Simply running distcheck once a day and send email to lyx-devel in case of 
error.

Otherwise it can take quite some time to find the offender (the error
messages are sometimes convoluted).

> There seems to be RSS feeds available right now (see bottom right corner of
> https://ci.inria.fr/lyx/ ) that I was able to add to my RSS reader (
> http://theoldreader.com) . It's probably also possible to get the CI server
> to send e-mail notifications to lyx-devel, assuming we want that?

If you don't have SMTP machinery working on that machine I can send you simple
shell script that would do the sending job. You just need port 25 open & SMTP
server accepting us.

Pavel

PS: the current err if it rings bell to someone, I guess just entry in makefile 
is missing:
make[1]: *** No rule to make target `export/ja/wrong_auto_encoding.lyx', needed

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

2017-01-18 Thread Christian Ridderström 
On 19 January 2017 at 01:45, Pavel Sanda  wrote:

> > The system is currently doing this:
> > - Polls the LyX repository at git.lyx.org  (every few hours)
> > - If branch 'master' has changed, then it builds LyX in two different
> > configurations
>
> What you mean by build? "make" or "make distcheck"?
>
The second one would be more useful,


Currently it's "make" (I didn't know about distcheck), e.g. the CMake
version does this:

cmake -DLYX_USE_QT=QT5 .. && make

Trying with just "make distcheck" instead of "make" produced error about
missing target 'distcheck'.
I can try with "make && make distcheck" instead of "make" and see if I can
get that working.

Let me know if there's other options or similar that ought to be used.

Here's the build scripts used in the two containers (using only "make"):
-
https://github.com/DrChr/build-lyx-using-ubuntu-latest-qt5-cmake/blob/master/build_lyx.sh
-
https://github.com/DrChr/build-lyx-using-ubuntu-xenial-qt4-autotools/blob/master/build_lyx.sh



> especially if it sends warning to the list if error was found.
>

There seems to be RSS feeds available right now (see bottom right corner of
https://ci.inria.fr/lyx/ ) that I was able to add to my RSS reader (
http://theoldreader.com) . It's probably also possible to get the CI server
to send e-mail notifications to lyx-devel, assuming we want that?

/Christian

-- 
Christian Ridderström, +46-70 687 39 44

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

2017-01-18 Thread Pavel Sanda 
Christian Ridderström wrote:
> Hi,
> 
> I'd like to announce that we now have a (somewhat) working system for doing
> continuous integration (CI) of the LyX master branch on Linux.
> 
> The system is currently doing this:
> - Polls the LyX repository at git.lyx.org  (every few hours)
> - If branch 'master' has changed, then it builds LyX in two different
> configurations

What you mean by build? "make" or "make distcheck"?
The second one would be more useful, especially if it sends
warning to the list if error was found.

Pavel