If you’re lucky enough to have a GrandCentral account and use Linux you’ll likely be very pleased with a little application called DialCentral.  Originally written for the Nokia Internet Tablet, DialCentral lets you use your GrandCentral account to make calls to arbitrary numbers.  You can already do that through the web interface but a dialer is much more convenient, especially on an Internet Tablet or Netbook.  It also supports your GrandCentral and Evolution contact lists and your call history.

If you use openSUSE there are packages of DialCentral available in my home repository in the openSUSE Build Service.  If you use Ubuntu or Debian the Maemo package should work for you.  Source code is also available, of course.

And because everyone loves speculation: I think Google intends to integrate GrandCentral with both GoogleTalk and Android some day. It’s odd that the only VoIP supported by GC for now is GizmoProject, but this is clearly just an artifact of the pre-google years. Some day soon you will be able to make POTS phone calls from Google Talk, and probably from Gmail.

One of my favorite ways to abuse the openSUSE Build Service is to link the packages I want to use into my home project. This is remarkably convenient but it wastes CPU cycles and disk space. It’s generally considered A Bad Thing™. But there are some good reasons why I do it and some ways openSUSE could change so that I won’t need to.

Executive Summary: Let upstream projects have their own top-level projects.

Currently it’s very difficult to get a top-level build service project created. You file a bug saying that you want one and they close the bug WONT-FIX. It’s a win-win. There’s a desire inside SUSE to keep the top-level as clean as possible. The solution, from their point of view, is to limit top-level to categories. People who think categories are a good thing need to read Everything is Miscellaneous by David Weinberger, or at least watch the Google Tech Talk. The result is massive projects like GNOME:Community.

GNOME:Community is not all bad but it has some fundamental problems, most prominently that there are often at least a few packages there which are older than the packages on your system. The underlying cause of this is that there are too many packages and not enough people interested in maintaining them. In some cases someone volunteers to maintain a package and does a fine job for a while but then loses interest and the package stagnates.

On the other end of the spectrum we find projects like Banshee. The Banshee developers maintain their own build service project. When they have a release they will update their packages because they want to be able to publish a 1-click link. If I add the Banshee repository I will always have the latest version and I won’t get any fluff I don’t need. This is the right way to do it. I would like to see top-level projects for every major project that wants to participate in openSUSE. There should be top-level projects for Pidgin (well, purple anyway), F-Spot, GIMP, Ekiga, etc. That way I can choose to get the latest GIMP without getting the latest F-Spot if I want to and I know that it’s maintained by people who care about it and are committed to quality.

Not every piece of software should have it’s own top-level project, of course. Some are closely related to each other such that it doesn’t make sense to keep them separate: Pidgin and Finch, for instance, or Firefox and Thunderbird. Others share a release schedule and have interdependencies that would prevent them from splitting up effectively, like GNOME. These should be brought under a single project, but this is not strange because they are already under a single upstream project (GNOME, Mozilla, etc.).

Many upstream projects do not distribute binaries. When they do it’s often just the Windows and Mac binaries because it can be difficult or expensive to build your own. openSUSE could be the place to get binaries of your favorite software, but not if we try to pigeonhole them into someone else’s project. It’s a risk for GIMP to advertise that high quality binaries of 2.6 are available from openSUSE if adding the repository is also going to upgrade your Tomboy.

It’s also difficult to properly categorize a project. Suppose there were a slick new open source file-sharing application and we put it under file-sharing but a year down the road it gets an instant-messaging feature and this feature becomes the feature people really like about it. Should we move it to an IM category? What about a nice DAAP server. Does it go under multimedia or file-sharing? Let’s toss out categories right now and make decent use of tags instead. The technology is already there, tags have been an underused feature of OBS since the beginning.

Making OBS more appealing to upstream projects is good for everyone. Upstream gets a release build system and a network of willing mirrors for free. openSUSE gets free publicity and better coordination with upstream. Users get repositories they know are well maintained by people who care about the project without any extra fluff they don’t want or need.

When packaging a new program for the first time one of the big headaches is figuring out where all your dependencies are.  This difficulty is greatly mitigated on openSUSE by a little tool called webpin.  It’s available in the openSUSE:Tools repository.

When you first build out your basic spec file you have little or no idea what goes in BuildRequires.  For a few projects you don’t need anything there at all so I like to just go ahead and run osc build and see what happens. If you’re not using OBS to build your software then I’m very sorry for you. Usually the configure script will stop somewhere saying that it couldn’t find something it needs, usually a header file or a pkg-config (.pc) file. This is where webpin comes in.

Suppose you get a line that says:

No package 'avahi-sharp' found

This means that configure is looking for a pkg-config file called avahi-sharp.pc. So with webpin installed we type webpin avahi-sharp.pc and we get a result that looks something like this:

1 results (1 packages) found for "avahi-sharp.pc" in openSUSE_110
* avahi-mono: Mono Bindings for avahi, the D-BUS Service for Zeroconf and Bonjour
   - 0.6.22 [suse-oss]
     >> /usr/lib/pkgconfig/avahi-sharp.pc

Now we know to add avahi-mono to our BuildRequires.

Later we might get an error that looks like this:

session-glue.c:5:26: error: X11/SM/SMlib.h: No such file or directory

Unfortunately for us this kind of error comes from gcc and is harder to see in all the gcc error: gobbledygook. If the upstream maintainer had been more careful we would have seen a configure error instead. But no matter! we just type webpin X11/SM/SMlib.h to find that this header file is found in xorg-x11-libSM-devel.

My new package packaging time is as much as cut in half thanks to this excellent tool. Many thanks to those responsible. There is also a web interface for webpin (I’m pretty sure it started out that way, hence the name).

Side note: RPM really needs to have automatic provides for pkg-config files so that we can use BuildRequires: pc(avahi-sharp) >= 0.6 instead of explicit package names. pkg-config is one of the best things to happen to software in a long time IMHO and RPM should be taking full advantage of it.

The package used for this example was Tangerine, a very nice little DAAP server written by James Willcox.