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

[dreamnext at 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, dreamnext at gmail.com (<dreamnext at 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, dreamnext at gmail.com (<
> dreamnext at 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 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 ask for some pointers and steps required to reach
>> this goal. In this way, we might be able to continue the production of the
>> 32-bit deb packages, freeing TDF of that burden as planned but, at the same
>> time, we could provide those packages for the parties that could be still
>> interested in them. We could not be able to support rpm-based binaries
>> though, someone else would have to step up if there's a need for that.
>>
>> Please let us know if this request of help is feasible for the
>> Developer(s) that are responsible of the LibreOffice packaging.
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20190805/05faa99e/attachment.html>