Re: We'd like to continue the production of the 32-bit deb packages

2019-08-28 Thread dreamn...@gmail.com
Escuelas Linux 6.5 with LibreOffice 6.3, both 32 and 64-bit, has been released, as well as the second version of our Escuelas Linux Developer Pack. https://sourceforge.net/p/escuelaslinux/blog/2019/08/announcing-escuelas-linux-65/ and

Re: We'd like to continue the production of the 32-bit deb packages

2019-08-21 Thread Stephan Bergmann
On 21/08/2019 00:11, dreamn...@gmail.com wrote: If the Red Hat Developer Toolset is the answer, that would mean that the OS adequate to produce distro-agnostic deb and rpm packages is Red Hat or CentOS? Yes (matching the "Linux: Runtime: RHEL 7 or CentOS 7" in the "The build chain and

Re: We'd like to continue the production of the 32-bit deb packages

2019-08-20 Thread dreamn...@gmail.com
For some reason, I always thought that Debian was the OS used to produce the Linux distro-agnostic binaries, but I proved wrong when did a test on Debian 9 (as Debian 10 could not be have been used previously due its recent release date). Debian 9 indeed includes a very old C/C++ compiler unable

Re: We'd like to continue the production of the 32-bit deb packages

2019-08-20 Thread dreamn...@gmail.com
Thanks for this info. If the issue was recently solved by commit c78dd0a726b32d922a0d75a26a51d4c30612368c ("configure: don't enable export validation if there are no schemas"), then it should mean that in future LIbreOffice versions this error would not appear again. Nevertheless, this specific

Re: We'd like to continue the production of the 32-bit deb packages

2019-08-20 Thread Stephan Bergmann
On 16/08/2019 20:43, dreamn...@gmail.com wrote: What we did if after a ‘make’ with errors, we had to ran ‘make build-nocheck’ to be able to bypass those errors on a Debian 10 schroot environment. This time, the required debs files were produced. However, when installing those debs and trying

Re: We'd like to continue the production of the 32-bit deb packages

2019-08-19 Thread Michael Weghorn
On 16/08/2019 20.43, dreamn...@gmail.com wrote: > Finally sort of solved. Good to hear. > > We were not able to get ‘make’ without cppunit errors. Tried numerous > times on VMs with Escuelas Linux and Bodhi Linux (both based on Ubuntu > 18.04) and on Debian 10 (on a VM and on a schroot

Re: We'd like to continue the production of the 32-bit deb packages

2019-08-19 Thread Michael Weghorn
On 15/08/2019 12.45, dreamn...@gmail.com wrote: > Well, I think I figured out the correct deletion of lines at > sal/Module_sal.mk file, since I got no errors related to sal after > making those changes. OK; once the other issues are dealt with, the schroot setup should probably be updated to

Re: We'd like to continue the production of the 32-bit deb packages

2019-08-16 Thread dreamn...@gmail.com
Finally sort of solved. We were not able to get ‘make’ without cppunit errors. Tried numerous times on VMs with Escuelas Linux and Bodhi Linux (both based on Ubuntu 18.04) and on Debian 10 (on a VM and on a schroot environment). What we did if after a ‘make’ with errors, we had to ran ‘make

Re: We'd like to continue the production of the 32-bit deb packages

2019-08-15 Thread dreamn...@gmail.com
Well, I think I figured out the correct deletion of lines at sal/Module_sal.mk file, since I got no errors related to sal after making those changes. But, as usual, I got errors related with cpuunittest also in this schroot environment. I really wonder why I still got those errors either on Ubuntu

Re: We'd like to continue the production of the 32-bit deb packages

2019-08-14 Thread dreamn...@gmail.com
Well, I already created the schroot environment following your kind instructions. However... 'make' failed again!!! cppunittest again... My hope is that maybe I didn't interpret correctly the changes that you made on the sal/Module_sal.mk file (for this test I'm not using git, but the xz sources

Re: We'd like to continue the production of the 32-bit deb packages

2019-08-14 Thread Michael Weghorn
On 14/08/2019 19.21, dreamn...@gmail.com wrote: > Would be possible to download your generated deb files from some > file-sharing service? If necessary, I'll probably find a way to upload them somewhere next week. (I'll be away for the next days.) However, that won't help in the long run, so I'll

Re: We'd like to continue the production of the 32-bit deb packages

2019-08-14 Thread dreamn...@gmail.com
Would be possible to download your generated deb files from some file-sharing service? I'm still struggling with compilation issues. 1) After the bad experience with Debian 10, I downloaded Debian 9.9 in the hope that would make a better compilation choice, but, alas, Debian 9 includes a version

Re: We'd like to continue the production of the 32-bit deb packages

2019-08-14 Thread Michael Weghorn
On 14/08/2019 16.18, Michael Weghorn wrote: > I just ran 'make distclean', then updated autogen.input and started a > new build and will let you know of the result. > > I put '--with-distro=LibreOfficeLinux' first, otherwise the > '--disable-gstreamer-0-10' flag is overriden by >

Re: We'd like to continue the production of the 32-bit deb packages

2019-08-14 Thread Michael Weghorn
On 14/08/2019 15.34, dreamn...@gmail.com wrote: > Would be possible to re-create your build with the following > autogen.input, and let me know if it worked for you? > > --disable-gstreamer-0-10 > --with-lang=es > --with-myspell-dicts > --with-distro=LibreOfficeLinux > --enable-release-build >

Re: We'd like to continue the production of the 32-bit deb packages

2019-08-14 Thread dreamn...@gmail.com
Would be possible to re-create your build with the following autogen.input, and let me know if it worked for you? --disable-gstreamer-0-10 --with-lang=es --with-myspell-dicts --with-distro=LibreOfficeLinux --enable-release-build --with-package-format=deb --disable-dependency-tracking

Re: We'd like to continue the production of the 32-bit deb packages

2019-08-14 Thread Michael Weghorn
On 14/08/2019 03.44, escuelaslinux wrote: > Well, today I tried by using Debian 10 (Maybe it would work by going to the > source, right?) > > Wrong. It was an awful experience. > > After seven hours in which the fans were at max, I didn't realize that the > make process hanged. No warning, no

Re: We'd like to continue the production of the 32-bit deb packages

2019-08-13 Thread Miguel Teixeira
" I will start building LibreOffice on Ubuntu 18" Sorry, Linux Mint 19 (Ubuntu 18) 32-bit Em qua, 14 de ago de 2019 às 00:12, Miguel Teixeira < miguel.teixe...@poli.ufrj.br> escreveu: > -enable-ext-languagetool > Download and integrate LanguageTool extension > > "What --enable-epm

Re: We'd like to continue the production of the 32-bit deb packages

2019-08-13 Thread Miguel Teixeira
-enable-ext-languagetool Download and integrate LanguageTool extension "What --enable-epm does?": "The ESP Package Manager (EPM) is a simple tool that generates software and patch distributions in various formats, including AT software packages ("pkg") used by Solaris, Debian ("dpkg"), HP-UX

Re: We'd like to continue the production of the 32-bit deb packages

2019-08-13 Thread escuelaslinux
Your construction method resembles the one found in the LibreOffice blog: https://blog.documentfoundation.org/blog/2019/06/12/start-developing-libreoffice-download-the-source-code-and-build-on-linux/ But it has some differences. I wonder what --enable-ext-languagetool does? We actually use the

Re: We'd like to continue the production of the 32-bit deb packages

2019-08-13 Thread escuelaslinux
Well, today I tried by using Debian 10 (Maybe it would work by going to the source, right?) Wrong. It was an awful experience. After seven hours in which the fans were at max, I didn't realize that the make process hanged. No warning, no memory overflow messages (This VM has 6 GB of RAM

Re: We'd like to continue the production of the 32-bit deb packages

2019-08-11 Thread Teixeira
* "so anything that does or does not work for Ubuntu 18.04 is the same for our distribution."* In derived systems, this is not always true. :/ I already built LibreOffice on an "Elementary OS" (based on Ubuntu 16, if I'm not mistaken), and I can say I had too much work. For a long time I built

Re: We'd like to continue the production of the 32-bit deb packages

2019-08-11 Thread dreamn...@gmail.com
Yes, I am trying to build using Escuelas Linux, which is based on Bodhi Linux 5.0, which is based on Ubuntu 18.04 LTS, so anything that does or does not work for Ubuntu 18.04 is the same for our distribution. If there are issues to compile on a derivative of Ubuntu, I can happily switch to Debian

Re: We'd like to continue the production of the 32-bit deb packages

2019-08-11 Thread Teixeira
Hi, Can describe your development environment? Ex.: SO: Ubuntu 18 Processor Intel Core i5 Ram: 4GB HD: 120GB *I will describe here a construction method that usually works:* :) -> Enable development repositories on your system (This can usually be done in Ubuntu "Programs and Updates", or by

Re: We'd like to continue the production of the 32-bit deb packages

2019-08-11 Thread Michael Weghorn
Can you give a few more details on your build environment (distro,...)? If this is Escuelas Linux, can you possibly also quickly try whether the same happens with e.g. Debian? If I remember correctly, you mentioned that you wanted to set up a VM. If I find the time, I might want to try to

Re: We'd like to continue the production of the 32-bit deb packages

2019-08-10 Thread Michael Weghorn
At a quick glance, this looks like the issue you had earlier, in which case adding the GCC switches Stephan mentioned should hopefully fix it. Can you try again after adding these two lines to your autogen.input? CC=gcc -mfpmath=sse -msse2 CXX=g++ -mfpmath=sse -msse2 On 09/08/2019 02.14,

Re: We'd like to continue the production of the 32-bit deb packages

2019-08-08 Thread dreamn...@gmail.com
Thanks again for your attention to this issue. These are the results of the most recent test. My autogen.input contents: --without-system-postgresql --without-junit --without-java --without-help --without-doxygen --disable-odk --disable-gstreamer-1-0 --disable-gstreamer-0-10

Re: We'd like to continue the production of the 32-bit deb packages

2019-08-08 Thread Michael Weghorn
On 08/08/2019 19.07, dreamn...@gmail.com wrote: > Thanks Michael for the head up about build-nocheck. I used it as a last > resort, because I am still unable to have 'make' finished without an > error if I don't add that parameter. Eike is of course right that disabling unit tests is not a good

Re: We'd like to continue the production of the 32-bit deb packages

2019-08-08 Thread dreamn...@gmail.com
Thanks Michael for the head up about build-nocheck. I used it as a last resort, because I am still unable to have 'make' finished without an error if I don't add that parameter. The use of that parameter is even sort of advised on the LibreOffice blog (

Re: We'd like to continue the production of the 32-bit deb packages

2019-08-08 Thread Eike Rathke
Hi dreamnext, On Thursday, 2019-08-08 10:36:17 -0500, dreamn...@gmail.com wrote: > Thanks for you help. the 'make build-nocheck' did the trick of passing the > unit test, and it finishes successfully :-) > > Now I'm on the stage of trying to build distributable deb files. Which isn't

Re: We'd like to continue the production of the 32-bit deb packages

2019-08-08 Thread dreamn...@gmail.com
Thanks for you help. the 'make build-nocheck' did the trick of passing the unit test, and it finishes successfully :-) Now I'm on the stage of trying to build distributable deb files. As suggested before, I added the following lines to autogen.input --with-distro=LibreOfficeLinux

Re: We'd like to continue the production of the 32-bit deb packages

2019-08-08 Thread Peter Maunder
I would welcome a 32-bit deb package (EN-GB) included.Although I only download a single copy, it is then installed in about 10 other small users.I do a certain amount of checking new versions and some combinations of functions, and was very disappointed that 32 bit linux deb packages are no

Re: We'd like to continue the production of the 32-bit deb packages

2019-08-07 Thread Michael Weghorn
Is there more output for the failing unit test that indicates what might be going wrong? You can e.g. also paste larger output at http://paste.debian.net/ or some similar service. As a workaround, you can also try building LibreOffice without running the unit tests for now, by using 'make

Re: We'd like to continue the production of the 32-bit deb packages

2019-08-06 Thread dreamn...@gmail.com
Well, I did a third compile try, but it failed again. This time first I did a clean up: --- make clean -- Then I did a ./configure, passing CFLAGS and CFLAGSXX as: --- ./configure CFLAGS='-mfpmath=sse -msse2' CFLAGSCXX='-mfpmath=sse -msse2' --with-jdk-home=/usr/lib/jvm/default-java

Re: We'd like to continue the production of the 32-bit deb packages

2019-08-06 Thread Stephan Bergmann
On 05/08/2019 23:40, dreamn...@gmail.com wrote: I intentionally did not type 'make clean' beforehand because: 1) I'm assumming that those additional flags would be applied in the code that fails to compile. I *think* that if it didn't not work again, that would mean that the issue is

Re: We'd like to continue the production of the 32-bit deb packages

2019-08-05 Thread dreamn...@gmail.com
Well, based on the info that Stephan kindly passed, I tried 'make' with the following parameters: make ENVCFLAGS="-mfpmath=sse -msse2" ENVCFLAGSCXX="-mfpmath=sse -msse2" However, it threw the same error as before. I intentionally did not type 'make clean' beforehand because: 1) I'm assumming

Re: We'd like to continue the production of the 32-bit deb packages

2019-08-05 Thread Stephan Bergmann
On 05/08/2019 16:53, dreamn...@gmail.com wrote: "Error: a unit test failed, please do one of: make CppunitTest_sc_filters_test CPPUNITTRACE="gdb --args"     # for interactive debugging on Linux make CppunitTest_sc_filters_test VALGRIND=memcheck     # for memory checking make

Re: We'd like to continue the production of the 32-bit deb packages

2019-08-05 Thread dreamn...@gmail.com
Well, my first compile attempts had not been very good. I followed the instructions kindly provided by Michael Weghorn, and downloaded and uncompress the source packages libreoffice-6.3.0.3.tar.xz, libreoffice-dictionaries-6.3.0.3.tar.xz, libreoffice-help-6.3.0.3.tar.xz and

Re: We'd like to continue the production of the 32-bit deb packages

2019-07-31 Thread Michael Weghorn
Hi! I'm not sure on how to get the exact same build result as the official LibreOffice deb packages, but in general, building LibreOffice and creating the packages requires these steps: 1) install build dependencies 2) ./autogen.sh 3) make I suppose using the following command in