opensync-plugin-kdepim and opensync-plugin-akonadi

Following on from my previous posts [1], [2], here is are the release announcements for the OpenSync plugins I've been working on.

opensync-plugin-kdepim
This is an OpenSync 0.22 plugin to sync with KDEPIM (pre-akonadi, so < 4.5). Using this and the OpenSync framework you can sync your KDE PIM data with mobile devices and other applications. This is ONLY compatible with OpenSync 0.22; not OpenSync 0.3x or above. This code is not guaranteed bug-free; always have a backup of your data. This plugin can sync contacts with KAddressBook, events and todos with KOrganizer, and notes with KNotes (over DBus). If you have akonadi configured this plugin will refuse to sync (you can override this in the config, see the README). IMPORTANT: Note syncing depends on you having a KDE installation where bko#251914 is fixed. This means knotes >= 4.4.7, or use the patch there to recompile.
If you can't get that to work, or if you don't need note syncing, in the patches directory of the source there is a patch that can turn off note syncing and allow it to compile.

opensync-plugin-kdepim on kde-apps.org
libopensync-plugin-kdepim-0.22.tar.bz2 source tarball on the OBS

opensync-plugin-akonadi
This is an OpenSync 0.22 plugin to sync with KDEPIM with akonadi, so > 4.4).
Using this and the OpenSync framework you can sync your KDE PIM data with mobile devices and other applications.
This is ONLY compatible with OpenSync 0.22; not OpenSync 0.3x or above.
This code is not guaranteed bug-free; always have a backup of your data.

This plugin can sync contacts, events, todos, and notes with Akonadi. (There is currently no easy way to view Akonadi notes). Make sure you have at least one akonadi collection of each type before syncing.

opensync-plugin-akonadi on kde-apps.org
libopensync-plugin-akonadi-0.22.tar.bz2 source tarball on the OBS

For both, prerequisites are libopensync-devel and libkdepimlibs4-devel. Compilation is standard

mkdir build; cd build
cmake ..
make
make install

Usage is add plugin to an OpenSync sync group; sync.

Both are available on the OBS in KDE:Unstable:Playground

KitchenSync 0.22

As explained in my previous post, something is finally happening with regards to KDEPIM and syncing with mobile devices.

As step 1, I have resurrected KitchenSync - the KDE OpenSync frontend. This application allows for creating, configuring, and syncing OpenSync sync groups among any of the OpenSync plugins (check your distro for opensync-plugin-* or similar).

Basic use should be straightforward - add a sync group, add the members you want to sync between, configure if necessary, sync.

The underlying OpenSync 0.22 framework is showings its age a bit though, and does have some bugs, so if you see a problem in KitchenSync, first make sure that the syncing works with the command-line tool msynctool before reporting a bug in KitchenSync (which, for this version, you can do by directly contacting me here on this blog or via email). Msynctool will also show a bit more debugging output so if something is going wrong, definitely check there first.

I've made binary and source RPMs available for openSUSE 11.1 and newer on the OBS in KDE:Unstable:Playground, which I'll try and keep updated whenever I can.
The source tarball is also available thanks to the OBS. I'll see about getting some publicly accessible source repository soon.

Prerequisites are libopensync-devel, libkde4-devel, and kdepimlibs4-devel or whatever similar name your distro calls them. Compilation instructions are standard KDE SC 4 / cmake stuff.

mkdir build; cd build
cmake ..
make
make install

The release is available on KDE-Apps.org.

In an entirely coincidental event, Quentin Denis has revived the KDE4 + OpenSync 0.40 version of KitchenSync on KDE SVN too. This does not overlap with his work; OpenSync 0.40 is not compatible with OpenSync 0.22. However, I'll be keeping track of his development and backporting any useful fixes (and lending any help I can).

OpenSync and KDE

Those of you who have used KDE software for a while may remember way, way back when it was announced that KDE would be cooperating with a project called OpenSync to provide PIM data synchronisation to a wide range of devices. The program KitchenSync was brought in as an OpenSync frontend and for a while everything was good - you could sync contacts, events, todos, and notes from KDE 3.5 with your mobile phones and PDAs.

Then the OpenSync project moved away from the stable version 0.22 and started work on a grand new 0.3x branch. They said when they reached 0.40, the project would be stable for end users again. Three years later they are still not ready, with the last release, 0.39, one year ago now. The project still has not been abandoned but things are moving extremely slowly.

Meanwhile KDE moved on as well, to our beloved 4.x series. It was decided to wait for OpenSync 0.40, and then put some effort into porting over the KDE-OpenSync integration - but as KDE release after release went by without OpenSync 0.40 being ready, people got bored of waiting for OpenSync and so KitchenSync was dropped, leaving KDE 4.x users no way of syncing PIM data with mobile devices. Further complicating this is the recent move to akonadi, which adds another layer between your PIM data and where you want it to be - on your mobile device. Compounding this is that all distributions, on the instructions of the OpenSync project, still ship the now-unmaintained and uncared-for OpenSync 0.22 version.

A few technically successful KDE Google SoC projects were undertaken to provide an alternative syncing framework (for example based on SyncML) but they never gained enough polish, or enough device support, to catch anyone's attention.

Now one of my introductions to the F/OSS world was helping a project called SynCE, a framework to talk to Windows Mobile devices from Linux. SynCE had always used OpenSync as the syncing framework and a common question on the SynCE mailing lists was "How can I get my data into KDE?" - and there was no answer. So finally given some free time this summer I decided to do something about it.

In total, I backported the half-finished KitchenSync KDE4 + OpenSync 0.40 port back to OpenSync 0.22 so that it is usable right now. Then I did the same for the KDEPIM plugin - but this only works with KDE SC releases before akonadi was introduced (i.e. < 4.4). Then I wrote a brand-new Akonadi Sync plugin for OpenSync 0.22 - not to be confused with the still-in-development Akonadi / OpenSync 0.40 plugin still available in KDE trunk. I'll do separate release announcements for them all.

Build ATI fglrx RPMs on openSUSE -- part 2

UPDATE 26/09/10: Switch the repositories back to X11:Drivers:Video; thanks to Stefan's work it is updated. Also, a post on the list says that ati-fglrxG01 legacy driver won't work on openSUSE 11.3 even if it builds, due to Xserver incompatibilities :(
UPDATE 24/09/10: I've branched and submitreq'ed the changes back to X11:Drivers:Video. Therefore I've changes the instructions below to checkout my branch instead and avoid the patching.
UPDATE 24/09/10: If you need the ATI legacy driver, for example for Radeon X1400 chipsets, checkout X11:Drivers:Video/ati-fglrxG01 instead. I've patched that to build on openSUSE 11.3 but don't have the hardware to test if it actually works.

In part 1 of this topic, I discussed the current (sad) state of ATI/AMD fglrx video driver RPMs on openSUSE Linux, and suggested that the best, cleanest way to build them was actually via the OBS. Here I cover step-by-step instructions on how to do so.

(Note: I use sudo on my machine, if you don't have it configured, use su)
The first step is to install the OBS command-line frontend, osc.

sudo zypper in osc

This will also pull in the famous SUSE 'build' script that allows cleanly building rpms.

Then, in a clean working directory (e.g. ~/src):

osc co X11:Drivers:Video ati-fglrxG02

Voila! The necessary spec files and patches will be made available in X11:Drivers:Video/ati-fglrxG02.

If you use sudo, make sure to edit the osc configuration file ~/.oscrc to tell it that. Uncomment the line starting with su-wrapper and change the value to suit you.

Now time to build! (Fix distro version/arch as necessary)

mkdir ~/src/packages
cd X11\:Drivers\:Video/ati-fglrxG02
sh ./fetch.sh
osc build -k ~/src/packages -j 4 openSUSE_11.3 x86_64 ati-fglrxG02.spec

fetch.sh downloads the ATI driver release you wanted. The osc build will download necessary pacakges, create an entirely separate build system running in a chroot at /var/tmp/build-root - where it cannot affect your main system - and safely build the kernel module rpms, and once built save them in ~/src/packages. You will be asked for the root (or yours, if using sudo) password to create the chroot.
Similarly build the X11 drivers.

osc build -k ~/src/packages -j 4 openSUSE_11.3 x86_64 x11-video-fglrxG02.spec

Now go to your brand new rpms and install them!

cd ~/src/packages
sudo zypper in -f ati-fglrxG02-kmp-desktop-8.771_*.x86_64.rpm \
                    x11-video-fglrxG02-8.771-*.x86_64.rpm

This does take a bit of bandwidth (~150 binary packages to download into /var/tmp/osbuild-packagecache), and is slightly slower than compiling the driver yourself, but it's much cleaner and you end up with a better constructed package. The package will automatically change your display driver to fglrx on installing, and when uninstalling will not leave any cruft about your system. This method is also completely applicable to openSUSE 11.2 and previous.

Incidentally, if you add something useful in these RPMs (spec file, code patch), feel free to submit the changes back to the OBS so everyone can benefit - see OBS Collaboration.

Build ATI fglrx RPMs on openSUSE -- part 1

How to install the ATI/AMD fglrx video drivers is one of the first questions many users have when they start up a new distro. The easiest option is an install from the distro's package manager; otherwise you have to manually download and compile from the ATI website.

Although they are evil proprietary binary code, without these drivers, 3d acceleration for games and desktop effects is usually missing or extremely poor performance. In some cases even the 2d performance is quite bad; so most users like to install them as soon as possible.

Traditionally (see SBD:ATI) on openSUSE a YaST/zypper repository has been available at http://www2.ati.com/suse/ (not viewable in a web browser). However in recent releases the ATI driver rpms in this repo have had bugs (originating in the original driver, not in the SUSE packaging); for some time the 64bit version installed files to 32bit locations and so failed to work; with the 11.3 release, the fglrx-10.7 rpms provided simply segfault on boot.

So with openSUSE 11.3 everyone had to fall back to the manual method. Some enterprising openSUSE users have written scripts and workarounds ([1],[2]) that automate at least part of the process; but it still requires installing development tools (kernel-sources, gcc, etc.) on a non-development machine, which I especially dislike.

As it turns out the real source of the ATI rpms (and nVidia rpms BTW, but that's a topic for another day) normally available in the YaST repository is Stefan Dirsch's hard work in the X11:Drivers:Video OBS project. Since the drivers are non-free, the actual source code is not uploaded to the OBS, but it is made available in what as known as a "nosrc" format - including all the build instructions and patches, just missing the source package. Happily, this makes it possible for anyone to build their own video driver RPMs to exactly the same quality that would be available from the repo, and without having to install development packages.

Step by-step instructions are available in part 2 of this post.

Introduction

Just to get this blog started, a quick introduction.

I have been running GNU/Linux distributions for almost 8 years now. My first experience was with Mandrake (today Mandriva) Linux - downloading 6 CD's on dialup was fun - and after some distro hopping I soon found a home with SuSE 9.2. Since then I've stuck with openSUSE as my main distro while also running the *buntu's and others on testing machines. My preference has always been for KDE - which is why I've never been a fan of Ubuntu - but every so often I'll fire up Gnome, Xfce, LXDE to see what progress has been made. I'm just as happy hacking away from a console.

Over the years I've picked up a fair few scripting and coding skills. Given a bit of time to remember the syntax, I can generally get what I want done in most common languages - bash, awk, sed, perl, C/C++.

My main contributions to the FOSS software environment are RPM packaging/maintenance (made super easy by the OpenSUSE Build Service), and C++/Qt/KDE application maintenance and patching. One of the first projects I became directly involved in is the SynCE project, where I ported some simple KDE3 applications to KDE4. Since then I've been active on the openSUSE mailing lists and occasionally on the forums.

My openSUSE Build Service home project is accessible here.