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
https://sourceforge.net/p/escuelaslinux/blog/2019/08/escuelas-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
> 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
> 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 to run LibreOffice on Escuelas Linux
> (the main target distribution) it does not work, as it complains about a
> glibc mismatch version. So, it seems that the generated deb files are not
> distribution-independent as the ones that were previously released by The
> Document Foundation.
>
> Under these circumstances, we then proceeded to create the deb files
> inside a Escuelas Linux VM.
>
> In Escuelas Linux (and I guess on any Ubuntu 18.04 system) the command
>
> sudo apt-get build-dep libreoffice
>
> does not install all the required packages to pass the autogen.sh phase,
> as we found to be the case in Debian 10. It complains about missing KF5
> stuff, so we installed these (some packages might not be necessary, but at
> least this worked)
>
>
> sudo apt-get install \
>
>  libkf5archive-dev libkf5bookmarks-dev libkf5coreaddons-dev libkf5config-dev \
>  libkf5configwidgets-dev libkf5dbusaddons-dev libkf5kio-dev 
> libkf5widgetsaddons-dev \
>  libkf5notifyconfig-dev libkf5newstuff-dev libkf5xmlgui-dev 
> libkf5declarative-dev \
>  libkf5notifications-dev libkf5guiaddons-dev libkf5textwidgets-dev 
> libkf5iconthemes-dev \
>  kdoctools-dev libkf5crash-dev libkf5filemetadata-dev extra-cmake-modules \
>  libsm-dev cmake qtdeclarative5-dev kde-runtime kinit  kio \
>  qml-module-qtquick-controls
>
> We also had to install qt5-default and libqt5x11extras5-dev.
>
> Just to be sure, we also installed IBM Java, as it is the one used in
> Escuelas Linux. Other Java environments have an ugly effect specifically on
> LibreOffice 32-bit, as we reported at the time on our blog:
>
>
> https://sourceforge.net/p/escuelaslinux/blog/2019/03/how-to-fix-libreoffice-startup-crashes-in-escuelas-linux-62-32-bit/
>
> However, switching our distribution to IBM Java solved those issues in a
> better way than passing stack_guard_gap=1.
>
> Our autogen.input is:
>
> *--with-distro=LibreOfficeLinux**--disable-gstreamer-0-10**--with-lang=es**--with-myspell-dicts**--enable-release-build**--with-package-format=deb**--disable-dependency-tracking**--with-jdk-home=/usr/lib/jvm/**ibm-java90-jdk-i386**/*
>
> Again, after we got a ‘make’ with errors, we had to ran ‘make
> build-nocheck’ to be able to bypass those. The deb files were produced and
> seem to be working fine when installed on Escuelas Linux.
>
> As the resulting .deb files does not seem to be distribution independent,
> we may not be offering then to download in our SourceForge site as we
> planned. If as time passes somebody knows how to solve the make errors we
> get, and how to release distro-independent deb packages, we might then
> offer LibreOffice 32-bit binary deb builts available for download, for
> parties that might be still interested on them.
>
> For now, I’m happy to announce that our upcoming Escuelas Linux version
> 6.5, will include, among other things, LibreOffice 6.3.0.4 in both of our
> editions, 32-bit and 64-bit.
>
> Many thanks to all 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 (<
> dreamn...@gmail.com>) escribió:
>
>> 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 32-bit edition of our distro, because among our users
>> there are a lot of low-income public schools, in which are still in use old
>> computers with about 512 MB to a 1 GB of RAM. That amount of RAM would make
>> running a Linux 64-bit system awfully slow, so we have to accommodate to
>> the needs and possibilities of what is available in poor areas, those in
>> which even having an old computer is still somehow a luxury.
>>
>> We perfectly understand that TDF releasing 32-bit Linux LibreOffice
>> 

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 runtime baselines" section of README.md in the root of the LO 
core git repo).


[...]


Butt, with the help of all you guys, we managed to solve the issue for 
our own distribution, although we would have loved to offer 32-bit 
distro-neutral deb packages for anyone else. But, who knows, maybe in 
fact is not worth the effort, given the tiny amount of downloads that 
prompted TDF to shutdown the release of binaries for this architecture.


On Linux, typically each distro produces LO binaries for all the 
architectures supported by that distro, so there is likely less demand 
anyway for generic binaries offered from a central place (unlike is the 
case for e.g. macOS and Windows).  But your attempt is appreciated!

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

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 to work with relatively recent versions of LibreOffice, and seems to
be an ugly hassle to try to update its compiler.

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? Either way, doing that would be a very steep endeavor for our
limited experience. We are not aware of documented procedures to produce
LibreOffice distro-neutral binaries, or how to setup a system capable of
achieving that feat. AFAIK, the guy or gal that was responsible for
producing the 32-bit neutral TDF LibreOffice deb and rpm packages didn't
seem to step in this thread, so his/her real life experience, know-how and
expertise on pitfalls and errors avoidance could now be lost on the demise
of the Linux 32-bit support. That's really sad, at least for us. :'(

Butt, with the help of all you guys, we managed to solve the issue for our
own distribution, although we would have loved to offer 32-bit
distro-neutral deb packages for anyone else. But, who knows, maybe in fact
is not worth the effort, given the tiny amount of downloads that prompted
TDF to shutdown the release of binaries for this architecture.

El mar., 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 time, the required debs files were produced. However,
> > when installing those debs and trying to run LibreOffice on Escuelas
> > Linux (the main target distribution) it does not work, as it complains
> > about a glibc mismatch version. So, it seems that the generated deb
> > files are not distribution-independent as the ones that were previously
> > released by The Document Foundation.
>
> Note that producing builds that are compatible with our baseline (as
> spelled out in README.md) is a non-trivial endeavour.  You typically do
> such builds on a baseline machine to make sure you do not link against
> functionality in e.g. libc.so.6 that is only available in newer versions
> of that library.  However, a baseline machine typically has a C++
> compiler that is too old for our needs, so you need a newer compiler but
> which generates code that only links against functionality that is
> already available in the baseline libstdc++.so.6 (e.g., by using Red Hat
> Developer Toolset).
>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

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 issue appeared during a compilation test using Debian 10. I do not
remember having these errors when compiling in Escuelas Linux (Ubuntu 18.04
based), but other errors instead, already described on some previous posts
in this thread. On Debian is when appeared that "Exception in thread "main"
java.lang.NullPointerException", even when having a valid JDK. Anyway, we
ended compiling on Escuelas Linux -also with errors without the
-build-nocheck, otherwise the binaries would not run on our main distro
target.

El lun., 19 ago. 2019 a las 11:59, Michael Weghorn ()
escribió:

> 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 make disabling those tests unnecessary, but let's
> do that in a follow-up step...
>
> Regarding your test failure
>
> > ScFiltersTest::testSheetNamesXLSX finished in: 47ms
> > Exception in thread "main" java.lang.NullPointerException
> > at
> >
> org.odftoolkit.odfvalidator.ODFValidator.getValidatorForSchema(ODFValidator.java:286)
> > at
> >
> org.odftoolkit.odfvalidator.ODFValidator.getManifestValidator(ODFValidator.java:186)
> > at
> >
> org.odftoolkit.odfvalidator.ODFRootPackageValidator.validateManifest(ODFRootPackageValidator.java:170)
> > at
> >
> org.odftoolkit.odfvalidator.ODFRootPackageValidator.validatePre(ODFRootPackageValidator.java:93)
> > at
> >
> org.odftoolkit.odfvalidator.ODFPackageValidator._validate(ODFPackageValidator.java:111)
> > at
> >
> org.odftoolkit.odfvalidator.ODFPackageValidator.validate(ODFPackageValidator.java:81)
> > at
> >
> org.odftoolkit.odfvalidator.ODFValidator.validateFile(ODFValidator.java:163)
> > at
> org.odftoolkit.odfvalidator.ODFValidator.validate(ODFValidator.java:125)
> > at org.odftoolkit.odfvalidator.Main.main(Main.java:314)
> > expected height 6001 actual 5999
> > expected width 2001 actual 2001
> > expected left 6000 actual 5976
> > expected right -2000 actual -1998
> > expected startrow 0 actual 0
> > expected startcol 5 actual 5
> > expected endrow 3 actual 3
> > expected endcol 7 actual 7
> >
> /home/linux/libreoffice-6.3.0.4/test/source/bootstrapfixture.cxx:199:ScFiltersTest::testLegacyCellAnchoredRotatedShape
> > equality assertion failed
> > - Expected: 0
> > - Actual  : 256
> > - failed to execute: sh
> > /home/linux/libreoffice-6.3.0.4/bin/odfvalidator.sh -M
> >
> /home/linux/libreoffice-6.3.0.4/schema/libreoffice/OpenDocument-manifest-schema-v1.3+libreoffice.rng
> > -D
> >
> /home/linux/libreoffice-6.3.0.4/schema/libreoffice/OpenDocument-dsig-schema-v1.3+libreoffice.rng
> > -O
> >
> /home/linux/libreoffice-6.3.0.4/schema/libreoffice/OpenDocument-schema-v1.3+libreoffice.rng
> > -m /home/linux/libreoffice-6.3.0.4/schema/mathml2/mathml2.xsd
> > /tmp/lu5683d1zw.tmp > /tmp/lu5683d201.tmp
>
> please see the mail thread starting at [1] which seems to be about the
> same issue that is specific to building from the tarballs and which was
> fixed recently by commit c78dd0a726b32d922a0d75a26a51d4c30612368c
> ("configure: don't enable export validation if there are no schemas") [2].
>
>
> [1]
> https://lists.freedesktop.org/archives/libreoffice/2019-August/083288.html
> [2] https://gerrit.libreoffice.org/#/c/77383/
>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

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 to run LibreOffice on Escuelas 
Linux (the main target distribution) it does not work, as it complains 
about a glibc mismatch version. So, it seems that the generated deb 
files are not distribution-independent as the ones that were previously 
released by The Document Foundation.


Note that producing builds that are compatible with our baseline (as 
spelled out in README.md) is a non-trivial endeavour.  You typically do 
such builds on a baseline machine to make sure you do not link against 
functionality in e.g. libc.so.6 that is only available in newer versions 
of that library.  However, a baseline machine typically has a C++ 
compiler that is too old for our needs, so you need a newer compiler but 
which generates code that only links against functionality that is 
already available in the baseline libstdc++.so.6 (e.g., by using Red Hat 
Developer Toolset).

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

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 environment).
> 

Depending on what the exact unit test failures are, the previous email
might or might not help. (I somehow missed this email at first when I
replied to the other one...)



signature.asc
Description: OpenPGP digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

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 make disabling those tests unnecessary, but let's
do that in a follow-up step...

Regarding your test failure

> ScFiltersTest::testSheetNamesXLSX finished in: 47ms
> Exception in thread "main" java.lang.NullPointerException
> at
> org.odftoolkit.odfvalidator.ODFValidator.getValidatorForSchema(ODFValidator.java:286)
> at
> org.odftoolkit.odfvalidator.ODFValidator.getManifestValidator(ODFValidator.java:186)
> at
> org.odftoolkit.odfvalidator.ODFRootPackageValidator.validateManifest(ODFRootPackageValidator.java:170)
> at
> org.odftoolkit.odfvalidator.ODFRootPackageValidator.validatePre(ODFRootPackageValidator.java:93)
> at
> org.odftoolkit.odfvalidator.ODFPackageValidator._validate(ODFPackageValidator.java:111)
> at
> org.odftoolkit.odfvalidator.ODFPackageValidator.validate(ODFPackageValidator.java:81)
> at
> org.odftoolkit.odfvalidator.ODFValidator.validateFile(ODFValidator.java:163)
> at org.odftoolkit.odfvalidator.ODFValidator.validate(ODFValidator.java:125)
> at org.odftoolkit.odfvalidator.Main.main(Main.java:314)
> expected height 6001 actual 5999
> expected width 2001 actual 2001
> expected left 6000 actual 5976
> expected right -2000 actual -1998
> expected startrow 0 actual 0
> expected startcol 5 actual 5
> expected endrow 3 actual 3
> expected endcol 7 actual 7
> /home/linux/libreoffice-6.3.0.4/test/source/bootstrapfixture.cxx:199:ScFiltersTest::testLegacyCellAnchoredRotatedShape
> equality assertion failed
> - Expected: 0
> - Actual  : 256
> - failed to execute: sh
> /home/linux/libreoffice-6.3.0.4/bin/odfvalidator.sh -M
> /home/linux/libreoffice-6.3.0.4/schema/libreoffice/OpenDocument-manifest-schema-v1.3+libreoffice.rng
> -D
> /home/linux/libreoffice-6.3.0.4/schema/libreoffice/OpenDocument-dsig-schema-v1.3+libreoffice.rng
> -O
> /home/linux/libreoffice-6.3.0.4/schema/libreoffice/OpenDocument-schema-v1.3+libreoffice.rng
> -m /home/linux/libreoffice-6.3.0.4/schema/mathml2/mathml2.xsd
> /tmp/lu5683d1zw.tmp > /tmp/lu5683d201.tmp

please see the mail thread starting at [1] which seems to be about the
same issue that is specific to building from the tarballs and which was
fixed recently by commit c78dd0a726b32d922a0d75a26a51d4c30612368c
("configure: don't enable export validation if there are no schemas") [2].


[1]
https://lists.freedesktop.org/archives/libreoffice/2019-August/083288.html
[2] https://gerrit.libreoffice.org/#/c/77383/
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

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
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 to run LibreOffice on Escuelas Linux
(the main target distribution) it does not work, as it complains about a
glibc mismatch version. So, it seems that the generated deb files are not
distribution-independent as the ones that were previously released by The
Document Foundation.

Under these circumstances, we then proceeded to create the deb files inside
a Escuelas Linux VM.

In Escuelas Linux (and I guess on any Ubuntu 18.04 system) the command

sudo apt-get build-dep libreoffice

does not install all the required packages to pass the autogen.sh phase, as
we found to be the case in Debian 10. It complains about missing KF5 stuff,
so we installed these (some packages might not be necessary, but at least
this worked)


sudo apt-get install \

 libkf5archive-dev libkf5bookmarks-dev libkf5coreaddons-dev libkf5config-dev \
 libkf5configwidgets-dev libkf5dbusaddons-dev libkf5kio-dev
libkf5widgetsaddons-dev \
 libkf5notifyconfig-dev libkf5newstuff-dev libkf5xmlgui-dev
libkf5declarative-dev \
 libkf5notifications-dev libkf5guiaddons-dev libkf5textwidgets-dev
libkf5iconthemes-dev \
 kdoctools-dev libkf5crash-dev libkf5filemetadata-dev extra-cmake-modules \
 libsm-dev cmake qtdeclarative5-dev kde-runtime kinit  kio \
 qml-module-qtquick-controls

We also had to install qt5-default and libqt5x11extras5-dev.

Just to be sure, we also installed IBM Java, as it is the one used in
Escuelas Linux. Other Java environments have an ugly effect specifically on
LibreOffice 32-bit, as we reported at the time on our blog:

https://sourceforge.net/p/escuelaslinux/blog/2019/03/how-to-fix-libreoffice-startup-crashes-in-escuelas-linux-62-32-bit/

However, switching our distribution to IBM Java solved those issues in a
better way than passing stack_guard_gap=1.

Our autogen.input is:

*--with-distro=LibreOfficeLinux**--disable-gstreamer-0-10**--with-lang=es**--with-myspell-dicts**--enable-release-build**--with-package-format=deb**--disable-dependency-tracking**--with-jdk-home=/usr/lib/jvm/**ibm-java90-jdk-i386**/*

Again, after we got a ‘make’ with errors, we had to ran ‘make
build-nocheck’ to be able to bypass those. The deb files were produced and
seem to be working fine when installed on Escuelas Linux.

As the resulting .deb files does not seem to be distribution independent,
we may not be offering then to download in our SourceForge site as we
planned. If as time passes somebody knows how to solve the make errors we
get, and how to release distro-independent deb packages, we might then
offer LibreOffice 32-bit binary deb builts available for download, for
parties that might be still interested on them.

For now, I’m happy to announce that our upcoming Escuelas Linux version
6.5, will include, among other things, LibreOffice 6.3.0.4 in both of our
editions, 32-bit and 64-bit.

Many thanks to all 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 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 32-bit edition of our distro, because among our users
> there are a lot of low-income public schools, in which are still in use old
> computers with about 512 MB to a 1 GB of RAM. That amount of RAM would make
> running a Linux 64-bit system awfully slow, so we have to accommodate to
> the needs and possibilities of what is available in poor areas, those in
> which even having an old computer is still somehow a luxury.
>
> We perfectly understand that TDF releasing 32-bit Linux LibreOffice
> packages was not worth anymore, given the small amount of downloads.
> Certainly some of those downloads were made by us, as we only required one
> download of a given LibreOffice version to have it installed in our distro
> and be used in hundreds of computers. A lot of those computers could not
> even be traceable, since there are no Internet connection in poor or remote
> schools. But we believe that even if we reported who and where are those
> schools, that would be still a small amount to be worth the effort and
> resources required to match the bigger amounts of downloads that seems to
> be receiving the LibreOffice 32-bit Windows counterpart.
>
> 

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 18.04 or Debian 10 based VMs, or in the schroot Debian 10
environment, while other good folks trying to help me have no issues at all
when they compile. :-0 Maybe I need a compile sorcerer ;-)

-
Testing
file:///home/linux/libreoffice-6.3.0.4/sc/qa/unit/data/wks/pass/sf_8de44549111f8ba3f67509354f677aab-2767-minimized.wks:
Tested
file:///home/linux/libreoffice-6.3.0.4/sc/qa/unit/data/wks/pass/sf_8de44549111f8ba3f67509354f677aab-2767-minimized.wks:
Pass (19ms)
Testing
file:///home/linux/libreoffice-6.3.0.4/sc/qa/unit/data/wks/fail/ofz14129-1.wks:
Tested
file:///home/linux/libreoffice-6.3.0.4/sc/qa/unit/data/wks/fail/ofz14129-1.wks:
Fail (8ms)
Testing
file:///home/linux/libreoffice-6.3.0.4/sc/qa/unit/data/wks/fail/sf_8acee7303920116c1f58c9d0e669855f-7551-minimized.wks:
Tested
file:///home/linux/libreoffice-6.3.0.4/sc/qa/unit/data/wks/fail/sf_8acee7303920116c1f58c9d0e669855f-7551-minimized.wks:
Fail (9ms)
ScFiltersTest::testCVEs finished in: 5322ms
ScFiltersTest::testRangeNameODS finished in: 41ms
ScFiltersTest::testContentODS finished in: 25ms
ScFiltersTest::testContentXLS finished in: 15ms
ScFiltersTest::testContentXLSX finished in: 47ms
ScFiltersTest::testContentXLSXStrict finished in: 46ms
ScFiltersTest::testContentLotus123 finished in: 12ms
ScFiltersTest::testContentofz9704 finished in: 3ms
ScFiltersTest::testContentDIF finished in: 11ms
ScFiltersTest::testContentXLSB finished in: 64ms
ScFiltersTest::testContentXLS_XML finished in: 14ms
ScFiltersTest::testContentGnumeric finished in: 14ms
ScFiltersTest::testSharedFormulaXLS finished in: 36ms
ScFiltersTest::testSharedFormulaXLSX finished in: 40ms
ScFiltersTest::testSheetNamesXLSX finished in: 47ms
Exception in thread "main" java.lang.NullPointerException
at
org.odftoolkit.odfvalidator.ODFValidator.getValidatorForSchema(ODFValidator.java:286)
at
org.odftoolkit.odfvalidator.ODFValidator.getManifestValidator(ODFValidator.java:186)
at
org.odftoolkit.odfvalidator.ODFRootPackageValidator.validateManifest(ODFRootPackageValidator.java:170)
at
org.odftoolkit.odfvalidator.ODFRootPackageValidator.validatePre(ODFRootPackageValidator.java:93)
at
org.odftoolkit.odfvalidator.ODFPackageValidator._validate(ODFPackageValidator.java:111)
at
org.odftoolkit.odfvalidator.ODFPackageValidator.validate(ODFPackageValidator.java:81)
at
org.odftoolkit.odfvalidator.ODFValidator.validateFile(ODFValidator.java:163)
at org.odftoolkit.odfvalidator.ODFValidator.validate(ODFValidator.java:125)
at org.odftoolkit.odfvalidator.Main.main(Main.java:314)
expected height 6001 actual 5999
expected width 2001 actual 2001
expected left 6000 actual 5976
expected right -2000 actual -1998
expected startrow 0 actual 0
expected startcol 5 actual 5
expected endrow 3 actual 3
expected endcol 7 actual 7
/home/linux/libreoffice-6.3.0.4/test/source/bootstrapfixture.cxx:199:ScFiltersTest::testLegacyCellAnchoredRotatedShape
equality assertion failed
- Expected: 0
- Actual  : 256
- failed to execute: sh /home/linux/libreoffice-6.3.0.4/bin/odfvalidator.sh
-M
/home/linux/libreoffice-6.3.0.4/schema/libreoffice/OpenDocument-manifest-schema-v1.3+libreoffice.rng
-D
/home/linux/libreoffice-6.3.0.4/schema/libreoffice/OpenDocument-dsig-schema-v1.3+libreoffice.rng
-O
/home/linux/libreoffice-6.3.0.4/schema/libreoffice/OpenDocument-schema-v1.3+libreoffice.rng
-m /home/linux/libreoffice-6.3.0.4/schema/mathml2/mathml2.xsd
/tmp/lu5683d1zw.tmp > /tmp/lu5683d201.tmp

ScFiltersTest::testLegacyCellAnchoredRotatedShape finished in: 679ms
ScFiltersTest::testEnhancedProtectionXLS finished in: 21ms
ScFiltersTest::testEnhancedProtectionXLSX finished in: 32ms
ScFiltersTest::testSortWithSharedFormulasODS finished in: 87ms
ScFiltersTest::testSortWithSheetExternalReferencesODS finished in: 47ms
bootstrapfixture.cxx:199:Assertion
Test name: ScFiltersTest::testLegacyCellAnchoredRotatedShape
equality assertion failed
- Expected: 0
- Actual  : 256
- failed to execute: sh /home/linux/libreoffice-6.3.0.4/bin/odfvalidator.sh
-M
/home/linux/libreoffice-6.3.0.4/schema/libreoffice/OpenDocument-manifest-schema-v1.3+libreoffice.rng
-D
/home/linux/libreoffice-6.3.0.4/schema/libreoffice/OpenDocument-dsig-schema-v1.3+libreoffice.rng
-O
/home/linux/libreoffice-6.3.0.4/schema/libreoffice/OpenDocument-schema-v1.3+libreoffice.rng
-m /home/linux/libreoffice-6.3.0.4/schema/mathml2/mathml2.xsd
/tmp/lu5683d1zw.tmp > /tmp/lu5683d201.tmp

Failures !!!
Run: 20   Failure total: 1   Failures: 1   Errors: 0

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 CppunitTest_sc_filters_test 

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 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-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 think it'd be better if you can get your build setup
> working.
>
> >
> > 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 of gcc already unsupported by LibreOffice, it
> > requires at least gcc 7. As far as I could found, upgrading gcc on
> > Debian 9 is an ugly chore, so I went back to installing Debian 10...
> > 2) But, this time, instead of choosing LXQT, I chose LXDE and used
> > LXTerminal. Now it compiled until the make error without a single hang.
> > I don't know if LXQT of tis default terminal were the culprits of the
> > frequent crashes, or something else, but at least I reached the make
> > error on Debian 10.
> >
> > I paste the error produced in Debian 10. It seems to be still cpunittest
> > related.
> >
> > Would be wise to apply your diff here, or it is not related since I'm
> > not running a chroot environment but a VM?
>
> The diff wouldn't help, since the tests that fail for you are unrelated
> to the ones I temporarily disabled.
>
> Maybe you want to try setting up an i386 chroot on an amd64 host as
> well? That might work better than using a i386 virtual machine (e.g.
> with regard to memory limitations) and I guess this should also work
> just fine on a host running Escuelas Linux.
>
> The steps I took to set up the chroot for use with schroot were roughly:
>
> Create chroot:
>
> sudo debootstrap --arch=i386 buster /some/path/to/chroot/buster-i386
>
> Create entry in /etc/schroot/schroot.conf:
>
> [buster-i386]
> description=Debian buster (stable) 32-bit
> directory=/some/path/to/chroot/buster-i386
> users=
> root-users=
> personality=linux32
>
> After that, you can change into the chroot using
>
> schroot -c buster-i386
>
> or (to work as root):
>
> schroot -c buster-i386 -u root
>
> and then set up the build dependencies, clone LibreOffice and build from
> there as usual.
>
>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

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 think it'd be better if you can get your build setup
working.

> 
> 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 of gcc already unsupported by LibreOffice, it
> requires at least gcc 7. As far as I could found, upgrading gcc on
> Debian 9 is an ugly chore, so I went back to installing Debian 10...
> 2) But, this time, instead of choosing LXQT, I chose LXDE and used
> LXTerminal. Now it compiled until the make error without a single hang.
> I don't know if LXQT of tis default terminal were the culprits of the
> frequent crashes, or something else, but at least I reached the make
> error on Debian 10.
> 
> I paste the error produced in Debian 10. It seems to be still cpunittest
> related.
> 
> Would be wise to apply your diff here, or it is not related since I'm
> not running a chroot environment but a VM?

The diff wouldn't help, since the tests that fail for you are unrelated
to the ones I temporarily disabled.

Maybe you want to try setting up an i386 chroot on an amd64 host as
well? That might work better than using a i386 virtual machine (e.g.
with regard to memory limitations) and I guess this should also work
just fine on a host running Escuelas Linux.

The steps I took to set up the chroot for use with schroot were roughly:

Create chroot:

sudo debootstrap --arch=i386 buster /some/path/to/chroot/buster-i386

Create entry in /etc/schroot/schroot.conf:

[buster-i386]
description=Debian buster (stable) 32-bit
directory=/some/path/to/chroot/buster-i386
users=
root-users=
personality=linux32

After that, you can change into the chroot using

schroot -c buster-i386

or (to work as root):

schroot -c buster-i386 -u root

and then set up the build dependencies, clone LibreOffice and build from
there as usual.



signature.asc
Description: OpenPGP digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

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 of gcc already unsupported by LibreOffice, it requires
at least gcc 7. As far as I could found, upgrading gcc on Debian 9 is an
ugly chore, so I went back to installing Debian 10...
2) But, this time, instead of choosing LXQT, I chose LXDE and used
LXTerminal. Now it compiled until the make error without a single hang. I
don't know if LXQT of tis default terminal were the culprits of the
frequent crashes, or something else, but at least I reached the make error
on Debian 10.

I paste the error produced in Debian 10. It seems to be still cpunittest
related.

Would be wise to apply your diff here, or it is not related since I'm not
running a chroot environment but a VM?

---
[CUT] vcl_app_test
[CUT] vcl_jpeg_read_write_test
[CUT] vcl_svm_test
[CUT] vcl_errorhandler

(cppunittester:31471): Gdk-WARNING **: 11:55:01.877:
gdk_window_set_icon_list: icons too large
/home/linux/Downloads/libreoffice-6.3.0.4/vcl/qa/cppunit/outdev.cxx:71:VclOutdevTest::testVirtualDevice
equality assertion failed
- Expected: c[ff00]
- Actual  : c[00ff]

VclOutdevTest::testVirtualDevice finished in: 71ms
VclOutdevTest::testUseAfterDispose finished in: 0ms
outdev.cxx:71:Assertion
Test name: VclOutdevTest::testVirtualDevice
equality assertion failed
- Expected: c[ff00]
- Actual  : c[00ff]

Failures !!!
Run: 2   Failure total: 1   Failures: 1   Errors: 0

Error: a unit test failed, please do one of:

make CppunitTest_vcl_outdev CPPUNITTRACE="gdb --args"
# for interactive debugging on Linux
make CppunitTest_vcl_outdev VALGRIND=memcheck
# for memory checking
make CppunitTest_vcl_outdev DEBUGCPPUNIT=TRUE
# for exception catching

You can limit the execution to just one particular test by:

make CPPUNIT_TEST_NAME="testXYZ" ...above mentioned params...

make[1]: ***
[/home/linux/Downloads/libreoffice-6.3.0.4/solenv/gbuild/CppunitTest.mk:114:
/home/linux/Downloads/libreoffice-6.3.0.4/workdir/CppunitTest/vcl_outdev.test]
Error 1
make[1]: *** Waiting for unfinished jobs

(cppunittester:31496): Gdk-WARNING **: 11:55:02.080:
gdk_window_set_icon_list: icons too large
SvmTest::testPixel finished in: 77ms
SvmTest::testPoint finished in: 1ms
SvmTest::testLine finished in: 1ms
SvmTest::testRect finished in: 1ms
SvmTest::testRoundRect finished in: 1ms
SvmTest::testEllipse finished in: 1ms
SvmTest::testArc finished in: 1ms
SvmTest::testPie finished in: 1ms
SvmTest::testChord finished in: 1ms
SvmTest::testPolyLine finished in: 4ms
SvmTest::testPolygon finished in: 1ms
SvmTest::testPolyPolygon finished in: 2ms
SvmTest::testText finished in: 61ms
SvmTest::testTextArray finished in: 0ms
SvmTest::testStrechText finished in: 1ms
SvmTest::testTextRect finished in: 1ms
SvmTest::testTextLine finished in: 0ms
SvmTest::testBitmaps finished in: 1ms
/home/linux/Downloads/libreoffice-6.3.0.4/test/source/xmltesttools.cxx:152:SvmTest::testBitmapExs
equality assertion failed
- Expected: 34434a50
- Actual  : d8870290
- In <>, attribute 'crc' of '/metafile/bmpex[3]' incorrect value.

SvmTest::testBitmapExs finished in: 2ms
SvmTest::testMasks finished in: 1ms
SvmTest::testGradient finished in: 1ms
SvmTest::testGradientEx finished in: 0ms
SvmTest::testHatch finished in: 1ms
SvmTest::testWallpaper finished in: 1ms
SvmTest::testClipRegion finished in: 0ms
SvmTest::testIntersectRectClipRegion finished in: 0ms
SvmTest::testIntersectRegionClipRegion finished in: 0ms
SvmTest::testMoveClipRegion finished in: 0ms
SvmTest::testLineColor finished in: 1ms
SvmTest::testFillColor finished in: 0ms
SvmTest::testTextColor finished in: 1ms
SvmTest::testTextFillColor finished in: 0ms
SvmTest::testTextLineColor finished in: 0ms
SvmTest::testOverLineColor finished in: 1ms
SvmTest::testTextAlign finished in: 0ms
SvmTest::testMapMode finished in: 0ms
SvmTest::testFont finished in: 0ms
SvmTest::testPushPop finished in: 1ms
SvmTest::testRasterOp finished in: 0ms
SvmTest::testTransparent finished in: 1ms
SvmTest::testFloatTransparent finished in: 0ms
SvmTest::testEPS finished in: 0ms
SvmTest::testRefPoint finished in: 0ms
SvmTest::testComment finished in: 1ms
SvmTest::testLayoutMode finished in: 0ms
SvmTest::testTextLanguage finished in: 0ms
xmltesttools.cxx:152:Assertion
Test name: SvmTest::testBitmapExs
equality assertion failed
- Expected: 34434a50
- Actual  : d8870290
- In <>, attribute 'crc' of '/metafile/bmpex[3]' incorrect value.

Failures !!!
Run: 46   Failure total: 1   Failures: 1   Errors: 0

Error: a unit test failed, please do one of:

make CppunitTest_vcl_svm_test CPPUNITTRACE="gdb --args"
# for interactive debugging on Linux
make CppunitTest_vcl_svm_test VALGRIND=memcheck
# for memory checking
make CppunitTest_vcl_svm_test 

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
> '--enable-gstreamer-0-10' set in distro-configs/LibreOfficeLinux.conf,
> so this is the content of the autogen.input I'm using:
> 
> --with-distro=LibreOfficeLinux
> --disable-gstreamer-0-10
> --with-lang=es
> --with-myspell-dicts
> --enable-release-build
> --with-package-format=deb
> --disable-dependency-tracking
> --with-jdk-home=/usr/lib/jvm/java-11-openjdk-i386/

That build succeeded as well in my buster chroot.


(with sal unit tests temporarily disabled due to issues with current
chroot setup as described earlier:

$ git diff
diff --git a/sal/Module_sal.mk b/sal/Module_sal.mk
index 4d7a84ee4e61..129d703a81fd 100644
--- a/sal/Module_sal.mk
+++ b/sal/Module_sal.mk
@@ -23,15 +23,6 @@ $(eval $(call gb_Module_add_targets,sal,\
Executable_osl_process_child \
 ))

-$(eval $(call gb_Module_add_check_targets,sal,\
-   $(if $(filter
TRUE,$(DISABLE_DYNLOADING)),,CppunitTest_Module_DLL) \
-   $(if $(filter WNT,$(OS)),CppunitTest_sal_comtools) \
-   CppunitTest_sal_osl_security \
-   CppunitTest_sal_osl \
-   CppunitTest_sal_rtl \
-   CppunitTest_sal_types \
-))
-
 endif

 # vim: set noet sw=4 ts=4:
)
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

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
> --with-package-format=deb
> --disable-dependency-tracking
> --with-jdk-home=/your/path/to/your/jdk

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
'--enable-gstreamer-0-10' set in distro-configs/LibreOfficeLinux.conf,
so this is the content of the autogen.input I'm using:

--with-distro=LibreOfficeLinux
--disable-gstreamer-0-10
--with-lang=es
--with-myspell-dicts
--enable-release-build
--with-package-format=deb
--disable-dependency-tracking
--with-jdk-home=/usr/lib/jvm/java-11-openjdk-i386/
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

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
--with-jdk-home=/your/path/to/your/jdk

I'm still bumping on the wall trying to compile... grrr

El mié., 14 ago. 2019 a las 1:25, Michael Weghorn ()
escribió:

> 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 memory overflow messages (This VM
> has 6
> > GB of RAM assigned, BTW).
> >
> > [...]
>
> I built LibreOffice from git tag 'libreoffice-6.3.0.3' in an i386 Debian
> buster (Debian 10) (s)chroot (host is Debian testing amd64) and that
> went fine with the following autogen.input (i.e. the one you pasted
> previously except for the '--with-external-tar' flag):
>
> $ cat autogen.input
> --without-system-postgresql
> --without-junit
> --without-java
> --without-help
> --without-doxygen
> --disable-odk
> --disable-gstreamer-1-0
> --disable-gstreamer-0-10
> --disable-firebird-sdbc
> --with-lang=es en-US
> --with-myspell-dicts
> --enable-debug
>
> #--with-external-tar=/home/linux/libreoffice/libreoffice/core/external/tarballs
> --without-krb5
> --without-gssapi
> CC=gcc -mfpmath=sse -msse2
> CXX=g++ -mfpmath=sse -msse2
>
>
> [Some of the 'sal' unit tests failed, so I commented those out and then
> the build including unit tests went fine. The unit test failures I got
> look like they were caused solely by the (s)chroot setup, and could
> probably be fixed by configuring the chroot properly; output:
>
> #Initializing ...
> #
> #logonUser function need root/Administrator account to test.
> #You can test by login with root/Administrator, and execute:
> #testshl2 -forward "username password"
> ../../../wntmsci9/bin/Security.dll
> #  where username and password are forwarded account info.
> #if no text forwarded, this function will be skipped.
> warn:vcl.app:30539:30539:sal/cppunittester/cppunittester.cxx:470:
> Fatal exception: assertion failed
> - Expression: ( pw = getpwuid( getuid() ) ) != nullptr
> - getpwuid: no password entry
>
>
>
> Error: a unit test failed, please do one of:
>
> make CppunitTest_sal_osl_security CPPUNITTRACE="gdb --args"
> # for interactive debugging on Linux
> make CppunitTest_sal_osl_security VALGRIND=memcheck
> # for memory checking
> make CppunitTest_sal_osl_security DEBUGCPPUNIT=TRUE
> # for exception catching
>
> You can limit the execution to just one particular test by:
>
> make CPPUNIT_TEST_NAME="testXYZ" ...above mentioned params...
> ]
>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

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 memory overflow messages (This VM has 6
> GB of RAM assigned, BTW).
> 
> [...]

I built LibreOffice from git tag 'libreoffice-6.3.0.3' in an i386 Debian
buster (Debian 10) (s)chroot (host is Debian testing amd64) and that
went fine with the following autogen.input (i.e. the one you pasted
previously except for the '--with-external-tar' flag):

$ cat autogen.input
--without-system-postgresql
--without-junit
--without-java
--without-help
--without-doxygen
--disable-odk
--disable-gstreamer-1-0
--disable-gstreamer-0-10
--disable-firebird-sdbc
--with-lang=es en-US
--with-myspell-dicts
--enable-debug
#--with-external-tar=/home/linux/libreoffice/libreoffice/core/external/tarballs
--without-krb5
--without-gssapi
CC=gcc -mfpmath=sse -msse2
CXX=g++ -mfpmath=sse -msse2


[Some of the 'sal' unit tests failed, so I commented those out and then
the build including unit tests went fine. The unit test failures I got
look like they were caused solely by the (s)chroot setup, and could
probably be fixed by configuring the chroot properly; output:

#Initializing ...
#
#logonUser function need root/Administrator account to test.
#You can test by login with root/Administrator, and execute:
#testshl2 -forward "username password"
../../../wntmsci9/bin/Security.dll
#  where username and password are forwarded account info.
#if no text forwarded, this function will be skipped.
warn:vcl.app:30539:30539:sal/cppunittester/cppunittester.cxx:470:
Fatal exception: assertion failed
- Expression: ( pw = getpwuid( getuid() ) ) != nullptr
- getpwuid: no password entry



Error: a unit test failed, please do one of:

make CppunitTest_sal_osl_security CPPUNITTRACE="gdb --args"
# for interactive debugging on Linux
make CppunitTest_sal_osl_security VALGRIND=memcheck
# for memory checking
make CppunitTest_sal_osl_security DEBUGCPPUNIT=TRUE
# for exception catching

You can limit the execution to just one particular test by:

make CPPUNIT_TEST_NAME="testXYZ" ...above mentioned params...
]
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

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 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 software packages
> ("swinstall" or "depot"), IRIX Software Manager ("inst" or "tardist"),
> portable (installation and removal scripts with tar files), and Red Hat
> Package Manager ("RPM")."
>
> Its use is described here:
> https://wiki.documentfoundation.org/Development/BuildingOnLinux
> In session: "Build DEB and/or RPM Packages"
>
> Ok, ok.. You can discard these lines:
>
> "I'd be worried about these:
> --enable-kde4
> --disable-gtk
> --disable-gtk3 "
>
> I just described the settings of my last build. You can discard these
> lines without problems.
>
>
>
> Em ter, 13 de ago de 2019 às 22:55, escuelaslinux 
> escreveu:
>
>> 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
>> Languagetool extension in our configuration of LibreOffice. This
>> parameters
>> include that extension on the compiled LibreOffice, or it merely allows
>> Languagetool to be installed as an extension later?
>>
>> I'd be worried about these:
>> --enable-kde4
>> --disable-gtk
>> --disable-gtk3
>>
>> Since our distribution is not based on KDE, and it certainly relies on
>> gtk.
>>
>> What --enable-epm does?
>>
>>
>>
>> --
>> Sent from:
>> http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
>> ___
>> LibreOffice mailing list
>> LibreOffice@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/libreoffice
>
>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

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 software packages
("swinstall" or "depot"), IRIX Software Manager ("inst" or "tardist"),
portable (installation and removal scripts with tar files), and Red Hat
Package Manager ("RPM")."

Its use is described here:
https://wiki.documentfoundation.org/Development/BuildingOnLinux
In session: "Build DEB and/or RPM Packages"

Ok, ok.. You can discard these lines:

"I'd be worried about these:
--enable-kde4
--disable-gtk
--disable-gtk3 "

I just described the settings of my last build. You can discard these lines
without problems.



Em ter, 13 de ago de 2019 às 22:55, escuelaslinux 
escreveu:

> 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
> Languagetool extension in our configuration of LibreOffice. This parameters
> include that extension on the compiled LibreOffice, or it merely allows
> Languagetool to be installed as an extension later?
>
> I'd be worried about these:
> --enable-kde4
> --disable-gtk
> --disable-gtk3
>
> Since our distribution is not based on KDE, and it certainly relies on gtk.
>
> What --enable-epm does?
>
>
>
> --
> Sent from:
> http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libreoffice
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

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
Languagetool extension in our configuration of LibreOffice. This parameters
include that extension on the compiled LibreOffice, or it merely allows
Languagetool to be installed as an extension later?

I'd be worried about these:
--enable-kde4
--disable-gtk
--disable-gtk3 

Since our distribution is not based on KDE, and it certainly relies on gtk.

What --enable-epm does?



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

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 assigned, BTW).

In the evening I restarted several times the VM to let 'make' pickup where
it left before it hanged out, but this turned out to be a very exhausting
method.

There were no compilation errors so far, but I don't intend to restart again
and again to see if it finishes some day.

Maybe tomorrow I'l try with Debian 9, it could be more tested and reliable
for compiling LibreOffice... I guess...

The most recent version of Elementary is based on Ubuntu 18.04. Since you
also had a bad experience in it as me, I'm not very keen on trying Ubuntu
flavors and derivatives at the moment, although I'm curious to know if the
Ubuntu Mate and Budgie you used were based on 18.04, or in the previous LTS
(16.04)





--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

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 LibreOffice in "KDE Neon" and "Ubuntu Budgie"
without problems.

Both distros have 32-bit versions.
I would choose one of the flavors of ubuntu:

Xubuntu
Lubuntu
Ubuntu MATE (already built LibreOffice here)
Kubuntu (already built LibreOffice here)
Ubuntu Budgie (already built LibreOffice here)
Ubuntu Studio




--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

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 on another VM. Should I use the most recent release of Debian, or
could there be a recommended release for compiling LibreOffice?

I retrieved the sources from git, and trying to compile LO 6.3.0.3

El dom., 11 ago. 2019 a las 18:06, Michael Weghorn ()
escribió:

> 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 reproduce the 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:
> >
> > CC=gcc -mfpmath=sse -msse2
> > CXX=g++ -mfpmath=sse -msse2
> >
> > To autogen.input
> >
> > Then
> > make clean
> > ./autogen.sh
> > make
> >
> > However, the compile process still crashes. Here are the last lines of
> > the output:
> >
> > [...]
>
>
>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

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 removing "#" from all lines with
"src" in the "sources.list" file.) To find the file sources.list, type
"locate sources.list" at your system terminal (console).

-> After activating all development repositories, type in the terminal:
-   *sudo apt install build-essential -y*
-   *sudo apt build-dep libreoffice -y*

-> Okay, now you already have what it takes to build LibreOffice. Let's
install Git:
-   *sudo apt install git -y*

-> After following all the steps above, you should be ready to clone
LibreOffice.;
-  Create a folder in your preferred location and open the terminal in that
folder.
- type it: *git clone git://anongit.freedesktop.org/libreoffice/core*

-> Once cloned, open the Core folder and:
- Open the terminal in this folder and type: *./autogen.sh*
- Check that Autogen will go all the way, if not, check for missing
packages, search them on the internet and install them.

-> When you can run Autogen until the end:
-  Open the Core folder and create a file called "*autogen.input*"
- In autogen.input, put this:

/*--enable-odk
--enable-ext-languagetool
--enable-epm
--enable-kde4
--disable-gtk
--disable-gtk3
--with-package-format=archive deb installed
--with-lang=pt-BR  (HERE YOU PUT THE LANGUAGE YOU WANT)*/

- After creating the "autogen.input" file with the above content, run
Autogen again and verify that it is correct.
- I strongly recommend that at least to generate the 32-bit installer (.deb)
you want, you use a "recent" system, for example:
"*https://linuxmint.com/download.php*or  *
https://neon.kde.org/download*;. You will probably have problems if you try
to build a current version of LibreOffice on Ubuntu 16.04 (for example). Of
course, once you build .deb on another system, you can use it there.

-> After following the steps I mentioned before,
- *./autogen.sh*
- *make*
- *instdir/program/soffice*

If you have any further problems, please post here.




--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

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 reproduce the 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:
> 
> CC=gcc -mfpmath=sse -msse2
> CXX=g++ -mfpmath=sse -msse2
> 
> To autogen.input
> 
> Then
> make clean
> ./autogen.sh
> make
> 
> However, the compile process still crashes. Here are the last lines of
> the output:
> 
> [...]




signature.asc
Description: OpenPGP digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

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, dreamn...@gmail.com wrote:
> 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
> --disable-firebird-sdbc
> --with-lang=es en-US
> --with-myspell-dicts
> --enable-debug
> --with-external-tar=/home/linux/libreoffice/libreoffice/core/external/tarballs
> --without-krb5
> --without-gssapi
> linux@escuelasLinux:~/libreoffice/libreoffice$ cat autogen.input
> --without-system-postgresql
> --without-junit
> --without-java
> --without-help
> --without-doxygen
> --disable-odk
> --disable-gstreamer-1-0
> --disable-gstreamer-0-10
> --disable-firebird-sdbc
> --with-lang=es en-US
> --with-myspell-dicts
> --enable-debug
> --with-external-tar=/home/linux/libreoffice/libreoffice/core/external/tarballs
> --without-krb5
> --without-gssapi
> ---
> 
> I typed the following:
> 
> 
> make clean
> ./autogen.sh
> make
> 
> 
> And these are the last lines of the output:
> 
> --
> ...
> 
> [CUT] sw_odfimport
> [CUT] sw_txtexport
> [CUT] sw_uiwriter
> [CUT] sw_layoutwriter
> [CUT] sw_mailmerge
> [CUT] sw_globalfilter
> [CUT] sw_accessible_relation_set
> [CUT] sw_apitests
> [CUT] sw_unowriter
> [CUT] sw_tiledrendering
> [CUT] sw_filters_test
> [CUT] vcl_gen
> [CUT] writerperfect_calc
> [CUT] writerperfect_draw
> [CUT] writerperfect_epubexport
> [CUT] writerperfect_import
> [CUT] writerperfect_impress
> [CUT] writerperfect_writer
> [CUT] xmlsecurity_signing
> [CUT] xmlsecurity_pdfsigning
> [MOD] sc
> [CUT] desktop_lib
> [CUT] services
> [CUT] sc_ucalc
> [CUT] sc_filters_test
> [CUT] sc_tiledrendering
> [CHK] sccomp
> Testing
> file:///home/linux/libreoffice/libreoffice/sc/qa/unit/data/qpro/pass/CVE-2007-5745-1.wb2:
> Tested
> file:///home/linux/libreoffice/libreoffice/sc/qa/unit/data/qpro/pass/CVE-2007-5745-1.wb2:
> Pass (96ms)
> Testing
> file:///home/linux/libreoffice/libreoffice/sc/qa/unit/data/qpro/pass/CVE-2007-5745-2.wb2:
> Tested
> file:///home/linux/libreoffice/libreoffice/sc/qa/unit/data/qpro/pass/CVE-2007-5745-2.wb2:
> Pass (131ms)
> Testing
> file:///home/linux/libreoffice/libreoffice/sc/qa/unit/data/qpro/pass/ofz14090-1.wb2:
> Tested
> file:///home/linux/libreoffice/libreoffice/sc/qa/unit/data/qpro/pass/ofz14090-1.wb2:
> Fail (20ms)
> /home/linux/libreoffice/libreoffice/unotest/source/cpp/filters-test.cxx:145:ScFiltersTest::testCVEs
> equality assertion failed
> - Expected: 1
> - Actual  : 0
> -
> file:///home/linux/libreoffice/libreoffice/sc/qa/unit/data/qpro/pass/ofz14090-1.wb2
> 
> warn:sfx.doc:26598:26598:sfx2/source/doc/objxtor.cxx:711:
> DBG_UNHANDLED_EXCEPTION in const
> com::sun::star::uno::Reference&
> {anonymous}::lcl_getOrCreateLibraryContainer(bool,
> com::sun::star::uno::Reference&,
> const com::sun::star::uno::Reference&)
> exception: com.sun.star.lang.IllegalArgumentException ArgumentPosition: 0
> ScFiltersTest::testCVEs finished in: 359ms
> warn:sc:26598:26598:sc/source/filter/orcus/orcusfiltersimpl.cxx:149:
> Unable to load styles from xml file! failed to load
> warn:sfx.doc:26598:26598:sfx2/source/doc/objxtor.cxx:711:
> DBG_UNHANDLED_EXCEPTION in const
> com::sun::star::uno::Reference&
> {anonymous}::lcl_getOrCreateLibraryContainer(bool,
> com::sun::star::uno::Reference&,
> const com::sun::star::uno::Reference&)
> exception: com.sun.star.lang.IllegalArgumentException ArgumentPosition: 0
> ScFiltersTest::testRangeNameODS finished in: 138ms
> warn:sc:26598:26598:sc/source/filter/orcus/orcusfiltersimpl.cxx:149:
> Unable to load styles from xml file! failed to load
> warn:linguistic:26598:26598:linguistic/source/lngsvcmgr.cxx:443: no
> extension manager - should fire on mobile only
> warn:sfx.doc:26598:26598:sfx2/source/doc/objxtor.cxx:711:
> DBG_UNHANDLED_EXCEPTION in const
> com::sun::star::uno::Reference&
> {anonymous}::lcl_getOrCreateLibraryContainer(bool,
> com::sun::star::uno::Reference&,
> const com::sun::star::uno::Reference&)
> exception: com.sun.star.lang.IllegalArgumentException ArgumentPosition: 0
> ScFiltersTest::testContentODS finished in: 126ms
> warn:sc:26598:26598:sc/source/filter/excel/xlroot.cxx:156:
> XclRootData::XclRootData - cannot get output device info:
> N3com3sun4star3uno9ExceptionE msg: invalid attempt to assign an empty
> interface of type com.sun.star.frame.XFrame!
> warn:legacy.osl:26598:26598:oox/source/helper/graphichelper.cxx:120:
> GraphicHelper::GraphicHelper - cannot get target frame
> warn:sfx.doc:26598:26598:sfx2/source/doc/objxtor.cxx:711:
> DBG_UNHANDLED_EXCEPTION in 

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
--disable-firebird-sdbc
--with-lang=es en-US
--with-myspell-dicts
--enable-debug
--with-external-tar=/home/linux/libreoffice/libreoffice/core/external/tarballs
--without-krb5
--without-gssapi
linux@escuelasLinux:~/libreoffice/libreoffice$ cat autogen.input
--without-system-postgresql
--without-junit
--without-java
--without-help
--without-doxygen
--disable-odk
--disable-gstreamer-1-0
--disable-gstreamer-0-10
--disable-firebird-sdbc
--with-lang=es en-US
--with-myspell-dicts
--enable-debug
--with-external-tar=/home/linux/libreoffice/libreoffice/core/external/tarballs
--without-krb5
--without-gssapi
---

I typed the following:


make clean
./autogen.sh
make


And these are the last lines of the output:

--
...

[CUT] sw_odfimport
[CUT] sw_txtexport
[CUT] sw_uiwriter
[CUT] sw_layoutwriter
[CUT] sw_mailmerge
[CUT] sw_globalfilter
[CUT] sw_accessible_relation_set
[CUT] sw_apitests
[CUT] sw_unowriter
[CUT] sw_tiledrendering
[CUT] sw_filters_test
[CUT] vcl_gen
[CUT] writerperfect_calc
[CUT] writerperfect_draw
[CUT] writerperfect_epubexport
[CUT] writerperfect_import
[CUT] writerperfect_impress
[CUT] writerperfect_writer
[CUT] xmlsecurity_signing
[CUT] xmlsecurity_pdfsigning
[MOD] sc
[CUT] desktop_lib
[CUT] services
[CUT] sc_ucalc
[CUT] sc_filters_test
[CUT] sc_tiledrendering
[CHK] sccomp
Testing
file:///home/linux/libreoffice/libreoffice/sc/qa/unit/data/qpro/pass/CVE-2007-5745-1.wb2:
Tested
file:///home/linux/libreoffice/libreoffice/sc/qa/unit/data/qpro/pass/CVE-2007-5745-1.wb2:
Pass (96ms)
Testing
file:///home/linux/libreoffice/libreoffice/sc/qa/unit/data/qpro/pass/CVE-2007-5745-2.wb2:
Tested
file:///home/linux/libreoffice/libreoffice/sc/qa/unit/data/qpro/pass/CVE-2007-5745-2.wb2:
Pass (131ms)
Testing
file:///home/linux/libreoffice/libreoffice/sc/qa/unit/data/qpro/pass/ofz14090-1.wb2:
Tested
file:///home/linux/libreoffice/libreoffice/sc/qa/unit/data/qpro/pass/ofz14090-1.wb2:
Fail (20ms)
/home/linux/libreoffice/libreoffice/unotest/source/cpp/filters-test.cxx:145:ScFiltersTest::testCVEs
equality assertion failed
- Expected: 1
- Actual  : 0
-
file:///home/linux/libreoffice/libreoffice/sc/qa/unit/data/qpro/pass/ofz14090-1.wb2

warn:sfx.doc:26598:26598:sfx2/source/doc/objxtor.cxx:711:
DBG_UNHANDLED_EXCEPTION in const
com::sun::star::uno::Reference&
{anonymous}::lcl_getOrCreateLibraryContainer(bool,
com::sun::star::uno::Reference&,
const com::sun::star::uno::Reference&)
exception: com.sun.star.lang.IllegalArgumentException ArgumentPosition: 0
ScFiltersTest::testCVEs finished in: 359ms
warn:sc:26598:26598:sc/source/filter/orcus/orcusfiltersimpl.cxx:149: Unable
to load styles from xml file! failed to load
warn:sfx.doc:26598:26598:sfx2/source/doc/objxtor.cxx:711:
DBG_UNHANDLED_EXCEPTION in const
com::sun::star::uno::Reference&
{anonymous}::lcl_getOrCreateLibraryContainer(bool,
com::sun::star::uno::Reference&,
const com::sun::star::uno::Reference&)
exception: com.sun.star.lang.IllegalArgumentException ArgumentPosition: 0
ScFiltersTest::testRangeNameODS finished in: 138ms
warn:sc:26598:26598:sc/source/filter/orcus/orcusfiltersimpl.cxx:149: Unable
to load styles from xml file! failed to load
warn:linguistic:26598:26598:linguistic/source/lngsvcmgr.cxx:443: no
extension manager - should fire on mobile only
warn:sfx.doc:26598:26598:sfx2/source/doc/objxtor.cxx:711:
DBG_UNHANDLED_EXCEPTION in const
com::sun::star::uno::Reference&
{anonymous}::lcl_getOrCreateLibraryContainer(bool,
com::sun::star::uno::Reference&,
const com::sun::star::uno::Reference&)
exception: com.sun.star.lang.IllegalArgumentException ArgumentPosition: 0
ScFiltersTest::testContentODS finished in: 126ms
warn:sc:26598:26598:sc/source/filter/excel/xlroot.cxx:156:
XclRootData::XclRootData - cannot get output device info:
N3com3sun4star3uno9ExceptionE msg: invalid attempt to assign an empty
interface of type com.sun.star.frame.XFrame!
warn:legacy.osl:26598:26598:oox/source/helper/graphichelper.cxx:120:
GraphicHelper::GraphicHelper - cannot get target frame
warn:sfx.doc:26598:26598:sfx2/source/doc/objxtor.cxx:711:
DBG_UNHANDLED_EXCEPTION in const
com::sun::star::uno::Reference&
{anonymous}::lcl_getOrCreateLibraryContainer(bool,
com::sun::star::uno::Reference&,
const com::sun::star::uno::Reference&)
exception: com.sun.star.lang.IllegalArgumentException ArgumentPosition: 0
ScFiltersTest::testContentXLS finished in: 71ms
warn:legacy.osl:26598:26598:oox/source/helper/graphichelper.cxx:120:
GraphicHelper::GraphicHelper - cannot get target frame
warn:sfx.doc:26598:26598:sfx2/source/doc/objxtor.cxx:711:
DBG_UNHANDLED_EXCEPTION in const
com::sun::star::uno::Reference&
{anonymous}::lcl_getOrCreateLibraryContainer(bool,

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 idea in
the long run, in particular if you plan to provide the packages for
"production use", so once the build with disabled unit tests works, the
cause for the failing unit test(s) should be observed.

Unfortunately, there are some "flaky" unit tests, so it might be that
the problem isn't even your build setup by itself. One thing to try
might be to just temporarily disable the specific test that fails
(probably in 'sw/CppunitTest_sw_layoutwriter.mk' according to the output
you pasted previously).
As mentioned before, the more output might help to further narrow the
issue down.

With regard to the build problem you described:

On 08/08/2019 17.36, dreamn...@gmail.com wrote:> 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
> --enable-release-build
> --with-package-format=deb
> --disable-dependency-tracking
> 
> [...]
> 
> However, something is still missing, because make build-nocheck now throws 
> the following error:
> 
> /home/linux/libreoffice/libreoffice/configmgr/source/components.cxx:287: 
> error: undefined reference to 
> 'configmgr::dconf::writeModifications(configmgr::Components&, 
> configmgr::Data&)'
> /home/linux/libreoffice/libreoffice/configmgr/source/components.cxx:531: 
> error: undefined reference to 'configmgr::dconf::readLayer(configmgr::Data&, 
> int)'
> /home/linux/libreoffice/libreoffice/configmgr/source/components.cxx:533: 
> error: undefined reference to 'configmgr::dconf::readLayer(configmgr::Data&, 
> int)'
> collect2: error: ld returned 1 exit status
> /home/linux/libreoffice/libreoffice/Library_merged.mk:11: recipe for target 
> '/home/linux/libreoffice/libreoffice/instdir/program/libmergedlo.so' failed
> make[1]: *** 
> [/home/linux/libreoffice/libreoffice/instdir/program/libmergedlo.so] Error 1
> make[1]: *** Waiting for unfinished jobs
> Makefile:282: recipe for target 'build' failed
> make: *** [build] Error 2
> 
> Any idea what could be missing to successfully build the .deb files?

The autogen param '--with-distro=LibreOfficeLinux' you added also
involves '--disable-dconf', and at a quick glance this looks like the
problem might be caused by artifacts from the previous build still lying
around.

Can you please try whether this goes away with a clean build (it might
be sufficient to just run 'make configmgr.clean' and then 'make' (or
'make build-nocheck')?



signature.asc
Description: OpenPGP digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

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 (
https://blog.documentfoundation.org/blog/2019/06/12/start-developing-libreoffice-download-the-source-code-and-build-on-linux/
)

"If you would like to compile without unit tests (for example, if you don’t
want to check that what you have changed in the source code will cause
regressions), use the *build-nocheck* parameter instead"

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 successfully :-)
> >
> > Now I'm on the stage of trying to build distributable deb files.
>
> Which isn't recommendable though.. or rather ill-advised. Building
> without checks and distributing means it may (and probably will) fail
> for the end user when installed. Checks are there for a reason. make
> build-nocheck does not pass the tests, it skips them. Actually
> build-nocheck should never be recommended unless someone wants to do
> private builds to investigate failures or do modifications and at the
> end would run a build with checks again.
>
>   Eike
>
> --
> GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563
> 2D3A
>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

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 recommendable though.. or rather ill-advised. Building
without checks and distributing means it may (and probably will) fail
for the end user when installed. Checks are there for a reason. make
build-nocheck does not pass the tests, it skips them. Actually
build-nocheck should never be recommended unless someone wants to do
private builds to investigate failures or do modifications and at the
end would run a build with checks again.

  Eike

-- 
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A


signature.asc
Description: PGP signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

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
--enable-release-build
--with-package-format=deb
--disable-dependency-tracking

Next I added export QT5DIR="/usr/lib/i386-linux-gnu/qt5" because in my
system is not enough to have the qt5-make and qr5-make-bin packages
installed.

Then I Installed a bunch of packages that seems to be necessary. As they
seem to be KF5/QT5 related, I installed the suggested ones for kdenlive
development: https://community.kde.org/Kdenlive/Development/KF5, maybe some
were not necessary, but would be hard to know which ones.

sudo apt-get install build-essential pkg-config \
 libavformat-dev libavdevice-dev frei0r-plugins-dev  frei0r-plugins
libgtk2.0-dev libexif-dev \
 libsdl2-dev libsox-dev libxml2-dev \
 ladspa-sdk libcairo2-dev libswscale-dev qtscript5-dev libqt5svg5-dev \
 libqt5opengl5-dev libepoxy-dev libeigen3-dev libfftw3-dev \
 git  yasm libtool automake   autoconf  libtool-bin  libtheora-bin
libtheora-dev \
 intltool swig libmp3lame-dev libgavl-dev libsamplerate0-dev
libjack-dev  libsoup2.4-dev   \
 python-dev  libkf5crash-dev  libkf5filemetadata-dev

After that, I also had to install

libqt5x11extras5-dev

However, something is still missing, because make build-nocheck now throws
the following error:

/home/linux/libreoffice/libreoffice/configmgr/source/components.cxx:287:
error: undefined reference to
'configmgr::dconf::writeModifications(configmgr::Components&,
configmgr::Data&)'
/home/linux/libreoffice/libreoffice/configmgr/source/components.cxx:531:
error: undefined reference to
'configmgr::dconf::readLayer(configmgr::Data&, int)'
/home/linux/libreoffice/libreoffice/configmgr/source/components.cxx:533:
error: undefined reference to
'configmgr::dconf::readLayer(configmgr::Data&, int)'
collect2: error: ld returned 1 exit status
/home/linux/libreoffice/libreoffice/Library_merged.mk:11: recipe for target
'/home/linux/libreoffice/libreoffice/instdir/program/libmergedlo.so' failed
make[1]: ***
[/home/linux/libreoffice/libreoffice/instdir/program/libmergedlo.so] Error 1
make[1]: *** Waiting for unfinished jobs
Makefile:282: recipe for target 'build' failed
make: *** [build] Error 2

Any idea what could be missing to successfully build the .deb files?

Thanks again for all your help.

El mié., 7 ago. 2019 a las 14:44, Michael Weghorn ()
escribió:

> 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 build-nocheck' instead of the
> plain 'make' command.
>
> On 07/08/2019 00.12, dreamn...@gmail.com wrote:
> > 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
> > ---
> >
> > ./configure is in fact reading those flags, as can be seen on the
> > relevant part of its output:
> >
> > ---
> > checking whether to use link-time optimization... no
> > checking for explicit AFLAGS... no
> > checking for explicit CFLAGS... -mfpmath=sse -msse2
> > checking for explicit CXXFLAGS... -mfpmath=sse -msse2
> > checking for explicit OBJCFLAGS... no
> > checking for explicit OBJCXXFLAGS... no
> > checking for explicit LDFLAGS... no
> > -
> >
> > Then I did a make, again passing the CFLAGS(XX) as parameters:
> >
> > 
> > make CLAGS='-mfpmath=sse -msse2' CFLAGSCXX='-mfpmath=sse -msse2'
> > 
> >
> > But it failed again at the CpuunitTest stuff, although the error message
> > is a bit different from the previous ones:
> >
> > -
> > Failures !!!
> > Run: 52   Failure total: 1   Failures: 1   Errors: 0
> >
> > Error: a unit test failed, please do one of:
> >
> > make CppunitTest_sw_layoutwriter CPPUNITTRACE="gdb --args"
> > # for interactive debugging on Linux
> > make CppunitTest_sw_layoutwriter VALGRIND=memcheck
> > # for memory checking
> > make CppunitTest_sw_layoutwriter DEBUGCPPUNIT=TRUE
> > # for exception catching
> >
> > You can limit the execution to just one particular test by:
> >
> > make CPPUNIT_TEST_NAME="testXYZ" ...above mentioned params...
> >
> > /home/linux/libreoffice/libreoffice/solenv/gbuild/CppunitTest.mk:113:
> > recipe for target
> >
> '/home/linux/libreoffice/libreoffice/workdir/CppunitTest/sw_layoutwriter.test'
> > failed
> > make[1]: ***
> >
> 

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



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

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 build-nocheck' instead of the
plain 'make' command.

On 07/08/2019 00.12, dreamn...@gmail.com wrote:
> 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
> ---
> 
> ./configure is in fact reading those flags, as can be seen on the
> relevant part of its output:
> 
> ---
> checking whether to use link-time optimization... no
> checking for explicit AFLAGS... no
> checking for explicit CFLAGS... -mfpmath=sse -msse2
> checking for explicit CXXFLAGS... -mfpmath=sse -msse2
> checking for explicit OBJCFLAGS... no
> checking for explicit OBJCXXFLAGS... no
> checking for explicit LDFLAGS... no
> -
> 
> Then I did a make, again passing the CFLAGS(XX) as parameters:
> 
> 
> make CLAGS='-mfpmath=sse -msse2' CFLAGSCXX='-mfpmath=sse -msse2'
> 
> 
> But it failed again at the CpuunitTest stuff, although the error message
> is a bit different from the previous ones:
> 
> -
> Failures !!!
> Run: 52   Failure total: 1   Failures: 1   Errors: 0
> 
> Error: a unit test failed, please do one of:
> 
> make CppunitTest_sw_layoutwriter CPPUNITTRACE="gdb --args"
>     # for interactive debugging on Linux
> make CppunitTest_sw_layoutwriter VALGRIND=memcheck
>     # for memory checking
> make CppunitTest_sw_layoutwriter DEBUGCPPUNIT=TRUE
>     # for exception catching
> 
> You can limit the execution to just one particular test by:
> 
> make CPPUNIT_TEST_NAME="testXYZ" ...above mentioned params...
> 
> /home/linux/libreoffice/libreoffice/solenv/gbuild/CppunitTest.mk:113:
> recipe for target
> '/home/linux/libreoffice/libreoffice/workdir/CppunitTest/sw_layoutwriter.test'
> failed
> make[1]: ***
> [/home/linux/libreoffice/libreoffice/workdir/CppunitTest/sw_layoutwriter.test]
> Error 1
> make[1]: *** Waiting for unfinished jobs
> Makefile:282: recipe for target 'build' failed
> make: *** [build] Error 2
> -
> 
> So... what else could be done to reach the goal of building LIbreOffice
> 32-bit?
> 
> Thanks again 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"
> 
> However, it threw the same error as before.
> 
> 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 something else?
> 2) I'm willing to do a 'make clean' if my above assumption is
> incorrect, even if that means another 7 hours of hard work for my
> poor computer. However, as I stated before, for this scenario I'm
> following the instructions from
> 
> 
> https://blog.documentfoundation.org/blog/2019/06/12/start-developing-libreoffice-download-the-source-code-and-build-on-linux/
> 
> But I have no idea which version of LibreOffice 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, dreamn...@gmail.com
>  ( >) escribió:
> 
> 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
> libreoffice-translations-6.3.0.3.tar.xz
> 
> The first issue was that autogen requires the presence of
> gstreamer1.0 AND of gstreamer0.10. gstreamer0.10 is deprecated,
> but anyway I found and installed the required gstreamer0.10 deb
> packages from elsewhere, but it still complained that they were
> missing, so I added a --disable-gstreamer-0-10 parameter.
> 
> Then a new error appeared:
> 
> 

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

./configure is in fact reading those flags, as can be seen on the relevant
part of its output:

---
checking whether to use link-time optimization... no
checking for explicit AFLAGS... no
checking for explicit CFLAGS... -mfpmath=sse -msse2
checking for explicit CXXFLAGS... -mfpmath=sse -msse2
checking for explicit OBJCFLAGS... no
checking for explicit OBJCXXFLAGS... no
checking for explicit LDFLAGS... no
-

Then I did a make, again passing the CFLAGS(XX) as parameters:


make CLAGS='-mfpmath=sse -msse2' CFLAGSCXX='-mfpmath=sse -msse2'


But it failed again at the CpuunitTest stuff, although the error message is
a bit different from the previous ones:

-
Failures !!!
Run: 52   Failure total: 1   Failures: 1   Errors: 0

Error: a unit test failed, please do one of:

make CppunitTest_sw_layoutwriter CPPUNITTRACE="gdb --args"
# for interactive debugging on Linux
make CppunitTest_sw_layoutwriter VALGRIND=memcheck
# for memory checking
make CppunitTest_sw_layoutwriter DEBUGCPPUNIT=TRUE
# for exception catching

You can limit the execution to just one particular test by:

make CPPUNIT_TEST_NAME="testXYZ" ...above mentioned params...

/home/linux/libreoffice/libreoffice/solenv/gbuild/CppunitTest.mk:113:
recipe for target
'/home/linux/libreoffice/libreoffice/workdir/CppunitTest/sw_layoutwriter.test'
failed
make[1]: ***
[/home/linux/libreoffice/libreoffice/workdir/CppunitTest/sw_layoutwriter.test]
Error 1
make[1]: *** Waiting for unfinished jobs
Makefile:282: recipe for target 'build' failed
make: *** [build] Error 2
-

So... what else could be done to reach the goal of building LIbreOffice
32-bit?

Thanks again 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"
>
> However, it threw the same error as before.
>
> 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 something else?
> 2) I'm willing to do a 'make clean' if my above assumption is incorrect,
> even if that means another 7 hours of hard work for my poor computer.
> However, as I stated before, for this scenario I'm following the
> instructions from
>
>
> https://blog.documentfoundation.org/blog/2019/06/12/start-developing-libreoffice-download-the-source-code-and-build-on-linux/
>
> But I have no idea which version of LibreOffice 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, dreamn...@gmail.com ()
> escribió:
>
>> 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 libreoffice-translations-6.3.0.3.tar.xz
>>
>> The first issue was that autogen requires the presence of gstreamer1.0
>> AND of gstreamer0.10. gstreamer0.10 is deprecated, but anyway I found and
>> installed the required gstreamer0.10 deb packages from elsewhere, but it
>> still complained that they were missing, so I added a
>> --disable-gstreamer-0-10 parameter.
>>
>> Then a new error appeared:
>>
>> "configure: error: Wrong qmake for Qt5 found. Please specify the root of
>> your Qt5 installation by exporting QT5DIR before running "configure".
>> Error running configure at ./autogen.sh line 302."
>>
>> However, the qt5-qmake and qt5-qmake-bin packages are installed in my
>> system!
>>
>> Since I was not able to stat compiling using Michael instructions, I
>> wondered what would happen if I followed instead the steps recently
>> published on the LibreOffice blog (
>> https://blog.documentfoundation.org/blog/2019/06/12/start-developing-libreoffice-download-the-source-code-and-build-on-linux/
>> )
>> It was a blind choice, since I have no idea what LibreOffice version
>> would I get if compiled (is there a way to get an specific version?), or
>> how easy would be to generate deb packages afterwards.
>>
>> In that set of instructions I changed:
>>
>> 

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 something else?


Your assumption is wrong in two ways:  For one, changes to configuration 
are not generally picked up reliably by a remake (so the common 
understanding is that one needs to `make clean` or even `make distclean` 
when chaning configuration).  For another, the failure happened when 
running a test (against already compiled code), not when compiling code.


(Plus, I'm not sure whether passing ENVCFLAGS[CXX] to mnake actually 
works as intended; I at least never use it and instead add any relevant 
flags directly to CC and CXX passed to configuration; but I don't know, 
and ENVCFLAGS[CXX] may actually work fine.)


But I have no idea which version of LibreOffice 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.


The relevant git branches are libreoffice-6-3 (for ongoing development 
of LO 6.3.x) and libreoffice-6-3-0 (for development towards LO 6.3.0), 
and the git tag libreoffice-6.3.0.3 (for latest LO 6.3.0 RC3).

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

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 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 something else?
2) I'm willing to do a 'make clean' if my above assumption is incorrect,
even if that means another 7 hours of hard work for my poor computer.
However, as I stated before, for this scenario I'm following the
instructions from

https://blog.documentfoundation.org/blog/2019/06/12/start-developing-libreoffice-download-the-source-code-and-build-on-linux/

But I have no idea which version of LibreOffice 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, dreamn...@gmail.com ()
escribió:

> 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 libreoffice-translations-6.3.0.3.tar.xz
>
> The first issue was that autogen requires the presence of gstreamer1.0 AND
> of gstreamer0.10. gstreamer0.10 is deprecated, but anyway I found and
> installed the required gstreamer0.10 deb packages from elsewhere, but it
> still complained that they were missing, so I added a
> --disable-gstreamer-0-10 parameter.
>
> Then a new error appeared:
>
> "configure: error: Wrong qmake for Qt5 found. Please specify the root of
> your Qt5 installation by exporting QT5DIR before running "configure".
> Error running configure at ./autogen.sh line 302."
>
> However, the qt5-qmake and qt5-qmake-bin packages are installed in my
> system!
>
> Since I was not able to stat compiling using Michael instructions, I
> wondered what would happen if I followed instead the steps recently
> published on the LibreOffice blog (
> https://blog.documentfoundation.org/blog/2019/06/12/start-developing-libreoffice-download-the-source-code-and-build-on-linux/
> )
> It was a blind choice, since I have no idea what LibreOffice version would
> I get if compiled (is there a way to get an specific version?), or how easy
> would be to generate deb packages afterwards.
>
> In that set of instructions I changed:
>
> --with-lang=hu en-US
>
> to
>
> --with-lang=es en-US
>
> in order to try to obtain a LibreOffice in Spanish language, not in
> Hungarian.
>
> I also removed the following lines:
>
> --with-referenced-git=/home/linuxosfelhasznalonev/libreoffice/core
>
> --with-external-tar=/home/linuxosfelhasznalonev/libreoffice/core/external/tarballs
>
>
> As they point to hard paths on the disk of the article author. I tried to
> reproduce those paths to match my own by creating core, external and
> tarballs directories, but it didn't work, so I merely removed those two
> lines.
>
> This time it began compiling, but after A LOT of hours and more of 40 GB
> used, the make command always stops at this error:
>
>
> "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 CppunitTest_sc_filters_test DEBUGCPPUNIT=TRUE
> # for exception catching
> You can limit the execution to just one particular test by:
> make CPPUNIT_TEST_NAME="testXYZ" ...above mentioned params...
> /home/linux/libreoffice/libreoffice/solenv/gbuild/CppunitTest.mk:113:
> recipe for target
> '/home/linux/libreoffice/libreoffice/workdir/CppunitTest/sc_filters_test.test'
> failed
> make[1]: ***
> [/home/linux/libreoffice/libreoffice/workdir/CppunitTest/sc_filters_test.test]
> Error 1
> Makefile:167: recipe for target 'CppunitTest_sc_filters_test' failed
> make: *** [CppunitTest_sc_filters_test] Error 2"
>
> 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 (<
> dreamn...@gmail.com>) escribió:
>
>> 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 32-bit edition of our distro, because among our users
>> there are a lot of low-income public schools, in which are still in use old
>> computers with about 512 MB to 

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 CppunitTest_sc_filters_test DEBUGCPPUNIT=TRUE
     # for exception catching
You can limit the execution to just one particular test by:
make CPPUNIT_TEST_NAME="testXYZ" ...above mentioned params...
/home/linux/libreoffice/libreoffice/solenv/gbuild/CppunitTest.mk:113: 
recipe for target 
'/home/linux/libreoffice/libreoffice/workdir/CppunitTest/sc_filters_test.test' 
failed
make[1]: *** 
[/home/linux/libreoffice/libreoffice/workdir/CppunitTest/sc_filters_test.test] 
Error 1

Makefile:167: recipe for target 'CppunitTest_sc_filters_test' failed
make: *** [CppunitTest_sc_filters_test] Error 2"


That could be the same issue as discussed in the mail thread starting at 
 
"Test File: sc/qa/unit/data/functions/fods/chiinv.fods: fails with 
Assertion" (i.e., require -mfpmath=sse -msse2, see 
 
"Re: Test File: sc/qa/unit/data/functions/fods/chiinv.fods: fails with 
Assertion". on 32-bit X86 to produce numeric values that match those 
produced on other platforms, at the expense of killing support for 
non-SSE2 X86 machines).

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

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 libreoffice-translations-6.3.0.3.tar.xz

The first issue was that autogen requires the presence of gstreamer1.0 AND
of gstreamer0.10. gstreamer0.10 is deprecated, but anyway I found and
installed the required gstreamer0.10 deb packages from elsewhere, but it
still complained that they were missing, so I added a
--disable-gstreamer-0-10 parameter.

Then a new error appeared:

"configure: error: Wrong qmake for Qt5 found. Please specify the root of
your Qt5 installation by exporting QT5DIR before running "configure".
Error running configure at ./autogen.sh line 302."

However, the qt5-qmake and qt5-qmake-bin packages are installed in my
system!

Since I was not able to stat compiling using Michael instructions, I
wondered what would happen if I followed instead the steps recently
published on the LibreOffice blog (
https://blog.documentfoundation.org/blog/2019/06/12/start-developing-libreoffice-download-the-source-code-and-build-on-linux/
)
It was a blind choice, since I have no idea what LibreOffice version would
I get if compiled (is there a way to get an specific version?), or how easy
would be to generate deb packages afterwards.

In that set of instructions I changed:

--with-lang=hu en-US

to

--with-lang=es en-US

in order to try to obtain a LibreOffice in Spanish language, not in
Hungarian.

I also removed the following lines:

--with-referenced-git=/home/linuxosfelhasznalonev/libreoffice/core
--with-external-tar=/home/linuxosfelhasznalonev/libreoffice/core/external/tarballs


As they point to hard paths on the disk of the article author. I tried to
reproduce those paths to match my own by creating core, external and
tarballs directories, but it didn't work, so I merely removed those two
lines.

This time it began compiling, but after A LOT of hours and more of 40 GB
used, the make command always stops at this error:


"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 CppunitTest_sc_filters_test DEBUGCPPUNIT=TRUE
# for exception catching
You can limit the execution to just one particular test by:
make CPPUNIT_TEST_NAME="testXYZ" ...above mentioned params...
/home/linux/libreoffice/libreoffice/solenv/gbuild/CppunitTest.mk:113:
recipe for target
'/home/linux/libreoffice/libreoffice/workdir/CppunitTest/sc_filters_test.test'
failed
make[1]: ***
[/home/linux/libreoffice/libreoffice/workdir/CppunitTest/sc_filters_test.test]
Error 1
Makefile:167: recipe for target 'CppunitTest_sc_filters_test' failed
make: *** [CppunitTest_sc_filters_test] Error 2"

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
> 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 32-bit edition of our distro, because among our users
> there are a lot of low-income public schools, in which are still in use old
> computers with about 512 MB to a 1 GB of RAM. That amount of RAM would make
> running a Linux 64-bit system awfully slow, so we have to accommodate to
> the needs and possibilities of what is available in poor areas, those in
> which even having an old computer is still somehow a luxury.
>
> We perfectly understand that TDF releasing 32-bit Linux LibreOffice
> packages was not worth anymore, given the small amount of downloads.
> Certainly some of those downloads were made by us, as we only required one
> download of a given LibreOffice version to have it installed in our distro
> and be used in hundreds of computers. A lot of those computers could not
> even be traceable, since there are no Internet connection in poor or remote
> schools. But we believe that even if we reported who and where are those
> schools, that would be still a small amount to be worth the effort and
> resources required to match the bigger amounts of downloads that seems to
> be receiving the LibreOffice 32-bit Windows counterpart.
>
> Given that TDF ended the provision of Linux 32-bit distribution neutral
> binaries, but not the 32-bit compatibility, we would like to step up to
> produce by ourselves the 32-bit distribution neutral deb packages from
> LibreOffice 6.3 and up. We are not aware of other distros or volunteers
> releasing the most recent LibreOffice version to date (6.3) as 32-bit
> distribution independent 

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 step 1 should give a result
pretty close to the official TDF builds:

./autogen.sh --with-distro=LibreOfficeLinux --enable-release-build
--with-package-format=deb --with-lang=ALL --disable-dependency-tracking

In particular, '--with-package-format=deb' will enable building the deb
packages.
(You can also create a file 'autogen.input' and put the options there
and then just call './autogen.sh' instead of explicitly passing the
options to autogen.sh every time.)

Some general instructions on building LibreOffice can also be found in
the wiki [1] and there's also a page on release builds [2], though I
can't say how up to date that one is (e.g. the info on build host being
CentOS 5 is a bit outdated).

I haven't built Libreoffice from the tar files so far (and can't test at
the moment), but you'll probably have to extract the
'libreoffice-dictionaries-?.?.?.?.tar.xz',
'libreoffice-help-?.?.?.?.tar.xz' and
'libreoffice-translations-?.?.?.?.tar.xz' into the extracted
'libreoffice-?.?.?.?.tar.xz'.
(Alternatively, you can build from git, where those are handled as git
submodules. LibreOffice release versions can be recognized by their git
tags.)

If there are any further questions, please just ask on this mailing list
or on IRC in channel #libreoffice-dev.

Best regards,
Michael

[1] https://wiki.documentfoundation.org/Development
[2] https://wiki.documentfoundation.org/Development/ReleaseBuilds

On 26/07/2019 17.01, dreamn...@gmail.com wrote:
> 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 32-bit edition of our distro, because among our users
> there are a lot of low-income public schools, in which are still in use
> old computers with about 512 MB to a 1 GB of RAM. That amount of RAM
> would make running a Linux 64-bit system awfully slow, so we have to
> accommodate to the needs and possibilities of what is available in poor
> areas, those in which even having an old computer is still somehow a luxury.
> 
> We perfectly understand that TDF releasing 32-bit Linux LibreOffice
> packages was not worth anymore, given the small amount of downloads.
> Certainly some of those downloads were made by us, as we only required
> one download of a given LibreOffice version to have it installed in our
> distro and be used in hundreds of computers. A lot of those computers
> could not even be traceable, since there are no Internet connection in
> poor or remote schools. But we believe that even if we reported who and
> where are those schools, that would be still a small amount to be worth
> the effort and resources required to match the bigger amounts of
> downloads that seems to be receiving the LibreOffice 32-bit Windows
> counterpart.
> 
> Given that TDF ended the provision of Linux 32-bit distribution neutral
> binaries, but not the 32-bit compatibility, we would like to step up to
> produce by ourselves the 32-bit distribution neutral deb packages from
> LibreOffice 6.3 and up. We are not aware of other distros or volunteers
> releasing the most recent LibreOffice version to date (6.3) as 32-bit
> distribution independent binaries.
> 
> Recently, the official LibreOffice Blog published instructions about how
> to compile LibreOffice on Linux. However, we’d like to be able not only
> to compile LibreOffice, but we would like to learn how to be able to
> produce by ourselves the same set of 32-bit distribution-independent deb
> packages that were compressed as a .tar.gz, that is, the LibreOffice
> binaries (LibreOffice_?.?.?_Linux_x86-_deb.tar.gz), the translated user
> interface (the LibreOffice_?.?.?_Linux_x86-_deb_langpack_??.tar.gz) and
> the offline help (LibreOffice_?.?.?_Linux_x86-_deb_helppack_??.tar.gz).
> As for the user interface and the offline packages, our main focus would
> be Spanish language.
> 
> On the download section is always available the following source code
> packages:
> libreoffice-?.?.?.?.tar.xz
> libreoffice-dictionaries-?.?.?.?.tar.xz
> libreoffice-help-?.?.?.?.tar.xz
> libreoffice-translations-?.?.?.?.tar.xz
> 
> But, given our inexperience, we don’t know how to use this source
> packages to produce the same set of 32-bit deb packages as were
> previously provided by TDF. Since LibreOffice is distributed in a lot of
> languages, we guess that the user interface and offline packages are not
> created manually one by one by hand, some useful scripts could have been
> created to automate as far as possible those tasks.
> 
> So, we respectfully