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

2019-08-11 Thread dreamn...@gmail.com
e issue locally - > though I can't promise. > > Which way are you currently using to retrieve the sources (git or > tarballs) and what version of LibreOffice are you trying to build? > > On 11/08/2019 02.18, dreamn...@gmail.com wrote: > > Thanks. > > > > Added: > >

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

2019-08-14 Thread dreamn...@gmail.com
downloaded). Could you please paste here the actual contents of that file? El mié., 14 ago. 2019 a las 14:44, Michael Weghorn () escribió: > On 14/08/2019 19.21, dreamn...@gmail.com wrote: > > Would be possible to download your generated deb files from some > > file-

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

2019-08-16 Thread dreamn...@gmail.com
the folks that helped us in this thread. I owe you a big beer ;-) https://sourceforge.net/projects/escuelaslinux/ https://www.facebook.com/escuelas.linux El vie., 26 jul. 2019 a las 10:01, dreamn...@gmail.com () escribió: > Hi! Greetings from the Escuelas Linux team. We are small Li

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

2019-08-15 Thread dreamn...@gmail.com
ir/CppunitTest/chart2_export.test] Error 1 make: *** [Makefile:282: build] Error 2 ... El mié., 14 ago. 2019 a las 14:44, Michael Weghorn () escribió: > On 14/08/2019 19.21, dreamn...@gmail.com wrote: > > Would be possible to download your generated deb files from some > &g

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 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

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

2019-07-26 Thread dreamn...@gmail.com
Hi! Greetings from the Escuelas Linux team. We are small Linux distribution that can be downloaded from https://sourceforge.net/projects/escuelaslinux/. Some more references about our activity can be found by doing an Internet search, or on own Facebook account, escuelas.linux We still provide a

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

2019-08-05 Thread dreamn...@gmail.com
t; So, I'm kind of stuck in both procedures. Does somebody knows how to solve on one or both? Thanks in advance El vie., 26 jul. 2019 a las 10:01, dreamn...@gmail.com () escribió: > Hi! Greetings from the Escuelas Linux team. We are small Linux > distribution that can be downloaded from &

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

2019-08-05 Thread dreamn...@gmail.com
Office I'm compiling. To be worth all the extra efforts that a 'make clean' represents, I'd like to be sure that I'm trying to compile LibreOffice 6.3. Is there a way to prove or instruct that LibreOffice 6.3 is the selected one to compile? Best Regards and Thanks in advance. El lun., 5 ago. 2019 a las 9:53,

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

2019-08-06 Thread dreamn...@gmail.com
gain in advance. El lun., 5 ago. 2019 a las 16:40, dreamn...@gmail.com () escribió: > > 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"

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

2019-08-08 Thread dreamn...@gmail.com
an 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 build-nocheck' instead of the > plain 'make' command. > > On 07/08/2019 00.1

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

2019-08-08 Thread dreamn...@gmail.com
t; El jue., 8 ago. 2019 a las 10:54, Eike Rathke () escribió: > 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 successf

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

2019-08-08 Thread dreamn...@gmail.com
helps to pinpoint what could be the issue to compile LibreOffice without using build-nocheck, in order to be able to later add to autogen.input the building .deb directives for the next attempt. El jue., 8 ago. 2019 a las 14:42, Michael Weghorn () escribió: > On 08/08/2019 19.07, dreamn..

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

2019-08-20 Thread dreamn...@gmail.com
., 20 ago. 2019 a las 7:38, Stephan Bergmann () escribió: > 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 ti

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

2019-08-20 Thread dreamn...@gmail.com
cribió: > 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 sch

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

2019-08-28 Thread dreamn...@gmail.com
-linux-developer-pack-20-is-here/ Again, many thanks to all the folks that helped us to reach this goal.  El vie., 16 ago. 2019 a las 13:43, dreamn...@gmail.com () escribió: > Finally sort of solved. > > We were not able to get ‘make’ without cppunit errors. Tried numerous >