Author Archive

It has long been a challenge to use MS Silverlight based websites on linux systems. Especially in The Netherlands this is a big hurdle as many (>80%) of the secondary school websites that pupils must use to communicate with their school (for homework, marks, etc) are equipped with Silverlight. Yes, really… 🙁

Fortunately at the end of August 2013 I discovered pipelight, a very smart idea to use MS Silverlight based website natively on Linux. The problem was however to find a working pipelight package for openSUSE. As there was none, I decided to build one myself using the incredible openSUSE Build Service. It was quite a quest to obtain a working package, but due to very good cooperation with the pipelight developers, I’m now able to present a working pipelight package to the openSUSE community. Oh, and while working on the package I reported a bug via the bug report system, that was solved and published via an rpm package within 1 hour after reporting it (that was during out of office hours). Indeed within 1 hour after reporting the problem it was; accepted, investigated, analysed, fixed, tested, handed over to me, packaged, tested and published! The amazing world of Open Source Software!

Pipelight works okay for the following sites (among many others): arte, LOVEFiLM, Netflix, Magister based NL schoolwebsites, WATCHEVER, etc. View the complete list on the pipelight website.

The installation instructions are on the pipelight website. Be aware though, that pipelight requires the wine package that is provided via the home:rbos:pipelight repository. With any other wine package, pipelight will (very likely) not work. If you rely on your currently installed wine package and installed MS applications and are unsure that the wine package provided via the home:rbos:pipelight repository will leave your currently in use MS applications untouched: don’t install pipelight (or only after making very good backups). You can always start by installing pipelight in a virtual machine.

The last days I’ve spent some time to investigate how to package Google Earth into an rpm. There was already a script called make-google-package available on the internet, but this one creates a debian package only. However, it was a good start to get me going to create a Google Earth (GE) rpm. Although I met quite some obstacles, which is not to uncommon in package building, I was still able to come up with a procedure a get GE packaged. The biggest problem I encountered were incorrect library dependencies, for which I opened issue 702 in the Google Earth issue tracker. Anyway to make a long story short: the rpm installs Google Earth system wide, corrects file permissions, for openSUSE_11.2 it takes care that the font is rendered correctly, the rpm takes care that Google Earth integrates nicely with the rest of the openSUSE system.

The procedure to build the rpm can be found in the openSUSE wiki. One word of caution about the procedure, you need to be an experienced linux user and you need to have access to the openSUSE Build Service (OBS) to be able to build the rpm. This is due to library dependency problem, which prevents it to build without modification to the base system.

If you like and you have the knowledge how to build an rpm with the tool ‘build’, it would be great if you can extend the howto with steps how to do this (build a GE rpm with ‘build’) to the before mentioned page. The same is valid for a procedure that uses VirtualBox to build the rpm.

Last but not last; a procedure or even a script, that uses ”’rpmbuild -ba”’ to build the rpm, would be very welcom as well.

When you want to use skype on a 64bit openSUSE 11.x system, there are some additional rpms needed, to get skype going. The following packages are needed:

xorg-x11-libXv-32bit

libqt4-32bit

libqt4-x11-32bit

Those packages will pull in others, but those 3 will take care that all packages are available to run skype. The package can be installed using zypper:zypper install xorg-x11-libXv-32bit libqt4-32bit libqt4-x11-32bit

During the X-mas holidays Kolab, the groupware server got a stable repository for 11.1 and 11.2 on the openSUSE build service (OBS). All packages that are not provided by the openSUSE base distribution have been copied (using osc copypac) to the STABLE repository. Another possiblity to achieve the same result could be by making a fixed link to the unstable package using osc linkpac -r <rev>. Once the unstable package works again the link could be updated with osc setlinkrev -r <newrev> to point to the working revision or updated revision.

The stable repository already shows its benefits, as cyrus-imapd was updated from version 2.3.14 to 2.3.16 in the server:mail, being the cyrus-imapd development repository for Factory. As the cyrus-imapd package in kolab:UNSTABLE links to the server:mail one, it no longer builds as the kolab patches no longer apply. Unfortunately my computer went South, and real package development is at the moment not possible. A good thing to mention here is, that cyrus-imapd-2.3.16 includes patches that are needed for Kolab and which have been in the review queue for multiple years!

Just before X-mas Kolab-2.2.3 was announced. This version is not used in the openSUSE packages, as we package the version from trunk. After the 2.2.3 release the kolab development, moved back to trunk and the next version will be from trunk.

This week kolab became one small step closer to realize feature request 307846: include Kolab in openSUSE. Although it will take lots and lots of more work to achieve this goal at all. The one step closer was realized in cooperation with the openSUSE cyrus-imapd maintainer R. The openSUSE cyrus-imapd spec file in the repository server:mail spec file has been extended with information about kolab, but the actual execution of the information has been switched off. With the Build Service link functionality the package server:mail/cyrus-imapd has been linked to the package server:kolab:UNSTABLE/cyrus-imapd-kolab, where the kolab functionality gets built. This is achieved by activating the variable with_kolab in the project related configuration file:# osc meta prjconf server:Kolab:UNSTABLE
%define with_kolab 1
Macros:
%with_kolab 1

See the Build_Service prjconf page in the openSUSE wiki for more information about this awesome functionality. This way the cyrus-imapd-kolab package inherits everything from the openSUSE base cyrus-imapd package.

One drawback for kolab administrators, you have to manually correct the currently installed kolab packages. Start with downgrading cyrus-imapd-kolab (it only downgrades the Build service version and not cyrus-imapd itself):# zyp in cyrus-imapd-kolab
This will install the dependent package perl-Cyrus-IMAP-kolab instead of perl-Cyrus-IMAP and perl-Cyrus-SIEVE-managesieve-kolab instead of perl-Cyrus-SIEVE-managesieve and it might remove kolab and perl-kolab.

Now reinstall kolab with:# zyp in kolab
that should be sufficient to be in sync with the repository again. Don’t forget to restart the services, with:# rckolab restart

This week also showed the power of the build service, as I could install kolab within only some minutes after installing openSUSE-11.2 in Virtualbox, while I never installed openSUSE-11.2 before.

The kolab installation in openSUS-11.2 made some problems visible in kolabconf -n. The latter has been fixed, it was a general problem in kolabconf and did not have anything to do with openSUSE-11.2.

The kolabconf problem however required some debugging, with a resulted spin off that the spamassassin daemon spamd is no longer activated via the startup scripts, but as a library of amavisd instead. That is the way amavisd and spamd have been configured in kolab, but what was not honored in the kolab setup on openSUSE.

Due to the change in the amavisd and spamd deamons, the script kolabsrv has been extended, and can now show a list with services required by kolab and what their current status is (see screenshot):

kolabsrv list and status output

The main task of kolabsrv is to convert the openpkg service names to the distribution dependent names.

The kolab project is heading towards a new release 2.2.3 with a planned release date in December 2009.

In one of the replies of Sasha’s brain dump, a references was made to project-builder, a project similar to the openSUSE build service. Although the OBS and project-builder may be similar, some people are wondering what the differences (1) and (2) are.

PS: many thanks that M. from Novell, who made my Lizards blog account working again. For the most part of this week, I’ve not been able to login to my blog account. After logging in with the correct credentials, I was referred back to the Lizards entry page. M. knows the details, so if this happens to you contact M. from Novell 🙂

Kolab on openSUSE made some very good progress since my last blog update on this topic. The most visible thing to the system administrator is that all Kolab required packages are available on the build service for openSUSE_Factory which will become openSUSE_11.2 very soon and its and predecessors.

In the past Kolab depended on the project c-client for imap annotations, but about a year ago this project became less open source than it used to be. For this reason I started to look for an alternative, which was found by just removing the c-client project as a dependency for Kolab. This forces Kolab to use the php-pear-net_imap annotation code. It is perhaps not as fast as the c-client code, but I assume that this gives no problem on openSUSE based Kolab installations.

Getting rid of the c-client project has another very big advantage as it now no longer required to rebuild the php module php5-imap. This was always very very problematic, especially for the x86_64 architecture. So the current setup is really nice.

As usual with building packages, getting rid of the c-client looks easier than it actually was, as a bug in the php-pear-net_imap project resulted in a non working setup. It took quite some time, before the solution was found and Kolab started to behave correctly again 🙂

For openSUSE_11.2 the php package php5-pear-log was removed from the base distribution, which prevented many Kolab required php5-pear modules to be build. Once the package was added to the server:php:applications build repository all the required Kolab required php5-pear modules started to build properly.

So for the brave at heart, give Kolab on openSUSE-11.2 a try. For the less brave ones try Kolab on openSUSE-11.1.

Oh and don’t forget to vote for Kolab in openSUSE’s feature tracking system openFATE!

Posted in Server | Comments Off on Kolab becomes available again for openSUSE

After a long time, with lots of not visible activity Kolab, the groupware server build with many known open source components, is slowly getting back into openSUSE. For a year or so it was not possible to use Kolab on openSUSE versions newer than 10.3. That was due to the move from openldap 2.3 to 2.4. The latter does no longer support slurpd as replication mechanism, but uses syncrepl instead. Hence, kolab had to be extended to be able to work with new replication protocol. After that the way the webclient horde was packaged, changed from (to make a long story short) 1 big package, to many small packages. This in preparation for horde4. Today, the following message was posted to the kolab-user e-maillist:

after a lot of tests on a virtual system I finally upgraded my
productive Kolab server to 2.2.1 with the Suse packages.

Now you should now, that kolab-2.2.1 was released about month in April 2009. Although we (Marcus Huewe, Alar Sing, and the author of this article) are not there yet, seeing this message means a lot to us. We’re making good process!

I was just notified by the ftp admin of gwdg.de (Eberhard), the long time reliable mirror of openSUSE, that he is going to stop the cronjobs at ftp4 which generate the /pub/linux/suse/apt/ contents at ftp4.gwdg.de, and shortly there after the rsync runs which sync it to ftp3 and ftp5 will be disabled.

I would like to thank Eberhard for the reliable service and all the hard work that was performed to generate the apt repositories during all those years!