Hi Folks

You surely noticed a bit of silence on this blog. Well, there was not much to say – I am not the twittering kind of guy who updates his readers where he’ll go out every night… I think I can lift the lid a little anyway.

I have been working on several larger packaging projects during the past weeks. LibreOffice is the one that took most of my time unfortunately. The new release 3.4.0 has been announced today, and that means I can finally test my revised SlackBuild script when building Slackware packages for you. My old way of compiling LibreOffice no longer works! It has been “deprecated” by the developers, which is a shame because it forces me to do a lot more work. Anyway, expect packages for Slackware 13.37 sometime this weekend.

I will probably not create Slackware 13.1 packages for this new LibreOffice release. What I do consider is to build the upcoming maintenance release for LibreOffice 3.3 (which will be 3.3.3) for Slackware 13.1.

KDE. How to begin? There are some stirrings in the KDE camp.

We are nearing the end of the KDE 4.6 series. Two more updates will see the light: 4.6.4 should be available in a few days and 4.6.5 is the final update, expected in early july. But considering the fact that the previous 4.6.3 experienced delays, it may take a little longer before I can start on packaging 4.6.4.

The new series 4.7.x proves to be a bigger challenge for Slackware. We saw that the 4.6. series moved away from HAL and instead requires udisks/upower (which was the reason for sticking with 4.5.5 in Slackware 13.37). The KDE developers have now finalized their move from CVS to GIT as the source control and version management system. The result is less than optimally arranged for packagers. The old “monolithic” source tarballs are now being split into many additional tarballs for individual applications. This means we have rewrite our scripts and possibly add a lot of packages. While this may be advantageous for some other distros with dedicated packaging teams, for us Slackware people it is a time for decisions.

After talking to Pat Volkerding, I announced on the KDE packager mailing list that we are considering the same solution as was chosen for GNOME in the past: remove KDE from Slackware if it proves to become a maintenance burden. I can not yet say anything final about this. For the time being, I have decided not to create Slackware packages for the KDE Software Compilation 4.7.x.

And then VLC…I have been waiting for a 1.2 release for so long that I almost do not believe it will ever arrive. I have a SlackBuild for it, but I will likely wait a bit longer before releasing a package for ths development version of VLC media player. It appears like there is a 1.1.10 release around the corner which is what I’ll build for Slackware 13.1 as well as 13.37.

Looking ahead, I think that creating VLC versions for Android is going to be considered more important. There is a whole new audience there, and I may very well be one of its users. There is also the fact that the developer team is almost always short of smart and motivated people. This showed last year when it was almost impossible to release a MS Windows version. Jean-Baptiste Kempf feels responsible for this so he made it happen, but I doubt that it is making him very happy.

And finally, Calibre E-book Management. This piece of software is indispensible if you are in the possession of an E-reader. Calibre manages your e-book collection, converts e-books between various formats (interesting for you Kindle users out there!) and allows you to upload books to your E-reader device. Calibre usually works a lot better than the software you get with your E-reader. And  since I am buying a Sony PRS650 for my wife I needed to have a working verison of Calibre for my Slackware box.

I have a Slackware package for Calibre in my repository but I have not been able to update it for a while, because it requires python 2.7. Unfortunately, Slackware 13.37 is still at python version 2.6.6. So I spent a lot of time to find a way around this and decided to take the same approach as with VLC and FFMPEG: that is, to compile all the requirements into the package itself and not depend on Slackware. I think I have succeeded in this, and am currently testing the results. Stay tuned…

Happy hacking! Eric