The Workbench 2016-11

  • Posted on: 13 November 2016
  • By: tomww

News From The Workbench 2016-11

LibreOffice4 and LibreOffice5 (new)

Our maintainer Pjama sent in new spec files for LibreOffice 5.1 and 5.2. This is absolutely wonderful!
Today I started to do a test-build on OpenIndiana Hipster 2016.10-like system to see first, if the LibreOffice4 in version can be built in a reproducible way. Finetuning will happen during the next days.
Once this passes or once I give up (never happens, right!), I'll proceed to build the "still" version of LibreOffice5. Believe me, I can't wait to do this. But please be patient for one or two weeks until I can make a testing package available to you.
Update 20161107: libglew needs to be worked on (uninstall it if you use Hipster 2016 as workaround)

This time I'll add a look back to my workbench of 2016-10 (

GCC (done)

Last month I've been working on SFEgcc to be relocated out of the directory /usr/gcc/.
Now SFEgcc lives in /usr/gcc-sfe/ and the pacakges for the 4.8 and 4.9 version of GCC provide compatibilty symlinks.
This may introduce some small issues, if you think you see one, please drop me a note. Especially if your program can't find the correct gcc runtime libraries any more.
This relocation was a tough decision as it contradicts my rule not to change such a basic component and risk roubles for the regular user.
We've not switched to GCC 5 package today. The default compiler in this project is still gcc 4.8. If you want, you can switch yourself to GCC 5 and see if packages break. I would be very much interested in your findings with GCC 5.
By the way, SFEgcc 4.9 package has ecj / gcj integrated now.

Behind the scenes (done)

"pnm_macro"s have been updated to know about the OpenIndiana Hipster Versions from 2016. The Build machine is still at this version but I've made a clone (thank you ZFS and thank you SmartOS for KVM) and updated this clone to Hipster 2016.10.
In SFE we use tons of macros to keep spec-files still simple and hide the complexity in pnm_macro for supporting currently 4 different OSDistros. This is Solaris 11, Solaris 12 (in development), OpenIndiana Hipster and OmniOS.
spec-files-extra is naturally open to support other OSDistros in the "Soalrish" world as well. Even if those use the SVR4 package system.

Over all, this month the large portion of the work for the IPS repository is going into LibreOffice5. But in fact I have to pass on kudos to our maintainer Pjama, as he did all the work from LibreOffice4 to LibreOffice5. Thank you so much Pjama!

As always, please drop me comments, ideas, questions in english or german language on sfepackages at g mail dot com or register a users here on the blog and write comments.

Did you know you can built all these wonderful packages yourself, on your local machine? And make your local changes to it? In case there is enough demand, I would offer making a webinar and show you how you can setup a local build environment. This is no big deal.


Update 20161106+20161113: OpenIndiana Hipster 2016 has some packages with conflicting file paths. For example it added "libglew" so you can't install the upcoming software "kodi" together with LibreOffice4. The workaround is, to simply uninstall libglew and trying to survive without "kodi" for a short while.
I'll think on how to solve / workaround this. At the moment it might "just works" if you just uninstall OI-Hipster package libglew and its dependent (yes, sorry fo the inconvenience). Eventually I'll relocate libglew to /usr/gnu or /usr/g++ or I'll change the Libreoffice package to use the OSDistro provided libglew in case it is OI Hipster 2016 but still depending on SFElibglew in case it is older hipster (it's getting complicated now). You can see, adding a package to the OSDistro but we already have in SFE can lead to ugly workarounds. Think on Libreoffice4, we would need one package requiign libglew form SFE if on pre-Hipster-2016 and another LibreOffice4 package if installing on OI Hipster 2016 and later. Or need two repositories. This is not funny :) (bur you know, we've always found a solution in the past, so we'll find one for these issues too).


Update 20161113: Updated kernel module fusefs to version 1.3.1, rebuilt libfusefs (might get a version update soon) and updates ntfs-3g to recent version 2016.2.22. See this comment: