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

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@gmail.com (<dreamnext@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.