Calendar

libreoffice: updated to 4.4.1. Note that these packages are compiled on Slackware 14.1 (and work fine on -current). These packages will not work on Slackware 14.0 (I have libreoffice-4.1.6 packages for that).

vlc: updated to 2.2.0. First major release in a long time. New libraries: asdcplib, speexdsp. Several internal libraries got an update as well: ffmpeg, libass, libbluray, libdvbpsi, libdvdcss, libdvdnav, libdvdread, libebml, libmatroska, libupnp, libvdpau, live, orc, speex. Usual caveat: versions that can not only DEcode but also ENcode mp3 and aac audio, and can play […]

libreoffice: updated to 4.4.0. Note that these packages are compiled on Slackware 14.1 (and work fine on -current). These packages will not work on Slackware 14.0 (I have libreoffice-4.1.6 packages for that). Recommended: if you work with MS Office documents a lot, you may want to install the two open source font packages google-caladea-font-ttf and […]

chromium: updated to 40.0.2214.111 with working support for Widevine CDM (you will need to install chromium-widevine-plugin for that) chromium-widevine-plugin: upgraded to 40.0.2214.111 (needs chromium of the same version)

This is KDE 5_15.02_2 for Slackware, consisting of the KDE Frameworks 5.7.0, Plasma 5.2.1 and Applications 14.12.2. This is meant only to be installed on top of Slackware -current and it will *replace* any version of KDE 4 you migh thave installed! New & changed since my KDE 5_15.02 release: - deps/libssh version 0.6.4 was […]

Meta

Compiling new LibreOffice sources is a bitch

<rant> After three compilation failures (each setting me back several hours) I must say this:

Whenever I have to bump a LibreOffice package – and perhaps due to moving up from Slackware 14.0 to 14.1 for compiling – it annoys the hell out of me that there are so many unexpected build failures. Not because I cannot fix them, but because every iteration of a LibreOffice compilation attempt costs another few hours. And there’s only so many hours between coming home from work and falling over because of sleep deprivation.

I am afraid that it will take some time before I can produce proper LibreOffice 4.2.0 packages for you. They will be available for Slackware 14.1 and newer . If you are running Slackware 14.0 then you’ll have to stick with LibreOffice 4.1.x (32-bit, 64-bit) for which I will build new packages soon (4.1.5 is around the corner). Users of Slackware 13.37 can still enjoy LibreOffice 3.6.7 (32-bit,64-bit).

In the meantime I am baking a fresh bread for tomorrow morning, so that I get at least something useful out of this frustrating evening.

Sometimes it happens that I undertake a project, and if there are too many failures leading me nowhere, I have to ask myself: is it really worth the hassle? If I was in your position, I’d simply repackage the prebuilt binaries. One has to wonder: what is it with these office suite developers? Even with the binaries, they can’t help but breaking naming schemes even between minor version bumps.

You probably already know that sort of solution, but in the past, when building big things like KDE, I’ve been using a combination of Distcc and CCache (http://www.microlinux.fr/slackware/Linux-HOWTOs/Distcc-HOWTO.txt). A distributed build on four or five machines can be quite fast. Plus, in the winter, you can turn off the heater in the office. Another alternate solution is to purchase a workstation similar to the monster one of my clients (the oceanographic institue in Brest) is using: 24 CPUs with 32 GB RAM. :o)

Comment from y0g1Posted: January 31, 2014 at 09:15

Hello,
maybe You could try to build Apache OO?
I would like to try it and check if its stability is better for production use than LO. I did compiled few times aoo on slackware64-current, but when I run it there were some problems with dbus.

I know about distcc and I use it when compiling for ARM. However I only have one big machine, and that is the server where I compile my x86 packages already, so distcc is not an option here.

Going with the binary pre-built stuff from libreoffice.org is going against my principles that I only use binaries if there are no sources to compile. In case of LibreOffice, the vendor binaries have been compiled to work on as many systems as possible, therefore they are not optimal binaries for Slackware.

Twice now, the compilation process managed to fill my 40 GB filesystem (which I use for compiling programs in the virtual machine) to the max. What kind of crazy software creep is inside of libreoffice 4.2.0 ?
I have enlarged my VM disk image and hope it is sufficient. At least the errors are caused by insufficient disk space and not by changed configuration parameters… this I can fix.

There was an issue with some files that are no longer present, which triggered a script abortion (due to a chmod command that failed), and that means I have to wait another 10 hours for my VM to compile a new set of 64-bit packages.

At least it enabled me to add “–enable-extra-fonts” in the assumption that this will add Google’s Carlito and Caladea fonts (free replacements for MS fonts) to the package.
The Carlito font is metrically compatible with the current MS default font “Calibri”. The Caladea font does the same for Microsoft’s “Cambria” font. Identical metrics means that you can use these fonts when rendering MS Office documents in LibreOffice and the document layout will not change. Even if the fonts don’t look the same, they take up the same space on the page.

Eric

Comment from Jeronimo BarrosPosted: February 1, 2014 at 14:02

Hi,

Eric, could you list the error ?

I’m asking because I’m having a very annoying time trying to compile PHP 5.5 on Slackware 14.1 and I’m wondering if it could be the same error.

Apparently is something related to the new GCC 4.8.2, the new glibc or both.

It’s the error from config.log after a “./configure —disable-all” at the PHP 5.5.8 source package:

once when i was waiting for libreoffice to start i measured the time – 9 sec. 25 years ago i waited the same amount of time to start wordstar from a floppy disk! great. so i searched for an alternative and – as tex is a huge package – i gave groff a try. to make it short – i write all my letters with groff now, and i wont touch libre-/openoffice again. there are macro packages (mom), which makes this taks easy.

libreoffice is in fact windows software – huge, bloated, has a huge amount of functionality and it uses a binary file format format. so maybe the solution to our problem is to dismiss libreoffice and switch from “word processing” to “text processing” by using groff or tex. This is actually a return to the unix philosophy.