Phew! Slackware 14 is born, and I think I should use the quiet post-release moments to create some packages specifically for the new version. Most of the packages I have for Slackware 13.37 will of course “just work” on Slackware 14 as well. During the Release Candidate phase, I already built and uploaded several Slackware 14-specific packages for which the “13.37 version” had issues. If you think I missed a package which is important to you, and needs to be built for Slackware 14 ASAP, please leave a message in the comments section below!
Not every package will be built for Slackware 14 from now on. In particular, the package which consumes the most resources and time during compilation – LibreOffice – will be built on Slackware 13.37 as long as the package also works on Slackware 14. The reason for that is: time and availability. If I build LibreOffice for 32-bit and 64-bit Slackware, that takes me two full days (I compile my packages inside QEMU virtual machines which makes the process a bit slower). It makes no sense to also try and compile the same packages for a second Slackware release. I do have a life, you know!
At the end of august, LibreOffice 3.6.1 was released, the first stabilization update in the 3.6 series. I have waited a bit with starting on the 3.6 series, and prefered to offer the latest in the 3.5 series instead a while ago.I feel more confident now with this “.1” release and decided to build some packages for it. The first thing which caught my eye when upgrading and starting libreoffice was the new green splash screen. The “about” box received an update too:
Of course, there have been many more enhancements since 3.5.x. If you are curious, check out this page. A great deal of this new functionality is geared toward making LibreOffice more suited as a contender to the non-free Microsoft Office suite. And because the developers keep improving on the interoperability by working on the import and export filters for the MS Office file formats, it is becoming more attractive for organizations to consider a migration away from the proprietary world of “vendor lock-in”. The aforementioned page lists a few cases of such migrations. Well worth considering in these economically challenging times!
Back to Slackware, and the new packages. Again, these new LibreOffice 3.6.1 packages are built on Slackware 13.37 but can be installed on Slackware 14 as well. I did not find any issues on my Slackware 14 desktop yet after I installed it there. You will find the package and source downloads at the usual locations (mirrors will catch up in the next 24 hours):
- http://slackware.com/~alien/slackbuilds/libreoffice/ (master site)
- http://taper.alienbase.nl/mirrors/people/alien/slackbuilds/libreoffice/ (my own mirror)
- http://scw.net.br/alien/slackbuilds/libreoffice/
- http://repo.ukdw.ac.id/alien-libreoffice/
- http://alien.slackbook.org/slackbuilds/libreoffice/
Be more productive than ever! Eric
Some ideas about compilation times and resource-hungry uses of our PCs. Earlier this year a new client of mine asked me to tailor a machine for geophysical calculations. I installed the software (designed for 64-bit RHEL) on an AMD64 in my office, and even on this machine and 3 GB RAM, some operations took a whole day to finish! The hardware I used for the job was in Intel i5 processor (i7 generated too much heat) with lots of RAM and good ventilation. Then I installed RHEL 64-bit on the box and the geophysical application. On this setup, even the biggest calculations went down from something like half a day or even a whole day to no more than 30 minutes. The hardware (carefully picked from various retailers) cost around 700 euros, dual monitor as well as RAID 1 dual hard disk for increased data security included.
I’m a regular reader of your blog, and I consider it a highly valuable resource. Given the intensity of your packaging activities, I think a hardware setup as the one just described would come in quite handy.
Hi Niki
Compiling software is not a computationally intensive task. Most of the bottleneck goes into disk I/O.
Even though I am using “virtio” disk driver support in the virtual machine, this is a limiting factor in virtualized environments.
I have a AMD Athlon quad-core with 4 GB of RAM and a set of 5400RPM SATA disks (no 7200RPM because then I would not be able to sleep at night because of their noise). I bought this two years ago, using the donation money I had accumulated at that time. Currently I have no money available at all. The donation money I get is not even enough to pay for the electricity my server eats up every year, let alone buy new hardware.
Long ago, I made a career decision to support Slackware with more than just a DVD subscription, after Pat fell ill. This is a personal obligation. The time I spend on Slackware and its support is so extensive that it has affected the progress in my career at my current employer. This has resulted in several years of no pay raises with a rising cost of living (I am the sole provider of income for my family).
These are my choices and I would not do this differently if I had to decide again. But, it limits what I can do.
So, I am planning my software builds around the big events like new releases of VLC, KDE, LibreOffice and updates to slackware-current which affect my multilib packages. So far, and using a high level of scripted automation in my virtual machine setup, lots of packages are compiled in a “fire and forget” way, and I can pick up the finished results after a couple of hours. Only the big guys like KDE and LibreOffice require manual attention at all times – a single error in the build usually sets me back for a full day.
Eric
Thank you Eric! I concur with your observations. I think it would be good to keep building pacakges in this way, provided that they work on 14.0.
What you said prompts me to reflection: “Compiling software is not a computationally intensive task.” My, how far we have come, when compilation is not regarded as a computation-intensive activity anymore 🙂
Thanks a bunch for these new packages Eric. Awesome work!
Hi Eric, agreed on the financial issues. I’ve even been considering farming my local power-munching on-site email server ( Dell 1950 ) out to the cloud to save on electricity costs ( which have risen by 150% over the last 2 years in this part of the world ).
Regarding compilations, if you are having constraints in terms of time, let us in the community know and I’m sure there would be any number of volunteers for compute time. Yes I know there is hand-holding involved but nevertheless, we’re here to help if you need it.
I do a fairly large amount of compiles ( with src2pkg – thanks Gilbert! ) on my own box ( AMD Quad 640 + 8GB mem + KVM ); sounds a lot like your rig. And yes I/O can be a problem.
Regarding using 13.37 packages on 14, I think you’re on the right track. And those who want release-specific builds can just grab the slackbuild script and do their own thing ( like I’ve just done with LibreOffice ).
In France we say “On connaît la chanson”. Here I’ve more or less split my work between “regular” customers and a series of not-for-profit-organizations for whom I gradually “advanced” from paid to semi-benevolent sysadmin. More recently, the benevolent tasks even seem to have the upper hand, and I’m currently trying (with limited success) to rebalance this a little bit.
Except for my server, an HP Proliant ML36 with 4×250 GB RAID 5 disks which I bought new, all the PCs in my office come from a retailer specialized in refurbished hardware. My two main workhorse PCs are a pair of five year old NEC Powermates, attached via NFS and NIS to the server (and all running Slackware 13.37 for the moment). The second PC is a dedicated build box, a quadruple boot running 32-bit and 64-bit flavors of Slackware 13.37 and 14.0. Lately this machine is chugging along all night building packages. Money is also tight here for the moment, the crisis manifesting itself in a phone that remains silent. But as soon as business starts again, I guess the first thing I’ll buy is simply a second NEC Powermate equal to the first, and coupled to it with distcc. There’s an old HOWTO on Alphageek’s (Erik Jan Tromp’s) site for ccache and distcc which still works as is on recent versions of Slackware.
PS: I’ve recently packaged Firefox ESR, Thunderbird ESR and corresponding localization packages. I use these for my daily work and I’m very happy with them, since they prove more stable than the “current” counterparts. I wonder if there’s any demand for them among Slackers.
Eric, have you tried the PDF Import extension? It is supposed to open PDF files in Draw, but for me it doesn’t. It just opens an empty document in the current LO application. And it doesn’t produce any error messages when I run LO in konsole, I have no clues to find out whether some package is missing from my installation or the extension ‘just’ doen’t work.
One afterthought to the disk bottleneck effect. There’s always the possibility of configuring RAID 0, which should increase disk I/O significantly. I also prefer 5.400 RPM over 7.200, but for other reasons, namely heat, which can be a serious consideration here in South France, judging by the masses of broken PCs piling up at the computer repair shops in the summer. For the same reason I try to avoid large disk sizes.
Eric, I just upgraded LibreOffice to:
« Version 3.6.1.2 (Build ID: SlackBuild for 3.6.1 by Eric Hameleers) ».
Thanks a lot!
Hey Eric! Thanks for yet another splendid set of packages! I’d download them right now, but I just noticed on The Document Foundation Blog that LO 3.6.2 was released today. There were many bugs fixed since LO 3.6.1, particularly regarding compatibility with Microsoft Office formats. In any case, I was just wondering when you think you might package LO 3.6.2, as if it’s the next few days I’ll save my download usage until then. 🙂 Thanks again Eric!
O wow… another two days of compiling 🙂
I’ll start right away.
Eric
The new version of LibreOffice 3.6.2 came out on this day. A good idea would be to create a script like Patrick Volkerding made ??for JAVA. Eric Hameleers Success!
Slackmaster,
I am not interested in re-packaging the official LibreOffice binaries. Those are not compiled on Slackware.
If you want such a script, use http://slackbuilds.org/office/libreoffice/
Eric
You’ve just done 3.6.1 and here comes 3.6.2 – never a dull moment ; )
hi Eric, is it possible for you to take look on clementine x86_64 slackbuild script. it works on 13.37 but not on current and also 14! you might find a solution. clementine works truly better than Amarok. i would appreciate it! thank you. http://slackbuilds.org/repository/14.0/audio/clementine/
Hi inman
I am not interested in Clementine, sorry. Perhaps you could try VLC instead.
It’s strange that the clementine.SlackBuild for Slackware 14.0 (http://slackbuilds.org/repository/14.0/audio/clementine/) does not work. The SBo admins do a good job of finding issues.. Perhaps you should evaluate your own installation.
Posting errors is also better than just stating that “it works on 13.37 but not on current”.
If you want to talk more about your Clementine issues, do not do that here. Open a thread on LinuxQuestions.org and let other people look at your errors.
Eric
Dear Eric,
thank for many many slackware packages you produce for the community. Your work makes slackware very comfortable. I use many packages you’ve made. So I tried to install libreoffice361, but I can not use it. I have the same problem I had some months ago with 35x: the password function still does not work. Will there once be a solution? Meanwhile I use the slackbuild script
for libreoffice355. There are no password problems.
Best regards from Peter
Oh wow, you were quick to act on my comment Eric! I’ve already downloaded and begun using your LO 3.6.2 packages. Thank you so much Eric! Your contributions, as always, are most appreciated! 🙂
thank you for your tips! i asked this in LQ it’s solved now! and believe me VLC is the best player but clementine taste so good! 😉