Category: Debian

This time I am not going to blog about KCall, but about DrKonqi. Dario Andres and I, the drkonqi maintainers, are thinking of adding some new features for KDE 4.4. As you already know, most distros out there ship stripped binary packages with their debug symbols put in separate packages. One of the features that we want to add in drkonqi for KDE 4.4 is to make it able to install the required debug packages when there are missing symbols in a crash report.

Our first idea for implementing this was to have a shell script installed somewhere, which by default will do nothing, and let distributions customize it to install the required packages. The input given to the script is the executable name and all the libraries that appear in the backtrace with missing debug symbols. For example, a backtrace line that reads like “#5 0xbf123456 in ?? from /usr/lib/libkdecore.so.5″ probably means that the library “/usr/lib/libkdecore.so.5″ is missing debug symbols, so that library path is passed as an argument to the script.

This is already implemented in trunk (it was very easy to do), but I now want to go further than that. Being a debian packager myself, I attempted to write an utility to do this for debian. I found an easy algorithm that takes as input all the filenames of the binaries that need debug symbols and outputs the names of the packages that need to be installed, using apt-file as a backend for searching package contents. While working on this, I came up with the idea to put this algorithm in a KJob, which eventually made me think of another possible implementation of this feature: Have a unified GUI in drkonqi that takes plugins; every distro will have its own plugin and each plugin will export a KJob that will do all the work (finding and installing packages), or alternatively, that KJob will only find the packages that need to be installed and then drkonqi will use packagekit to install them or display some message to tell the user what to install if packagekit is not available (which is the case for debian, btw).

This scenario would be better than the scenario with the script, because it will allow us to have a unified GUI in all distributions and will also reduce the work of the distributors, as they will have to write only one small plugin instead of a whole application to do all the work. I don’t know however if this scenario works for other distributions, as I don’t know how they handle debug packages.

So, dear fellow packagers and anybody else who has an opinion on this, I would like to know how your distribution handles debug packages and what is your opinion on all this, so that I can decide what to do and how to do it.:)

This week went a bit out of plan. I didn’t work much on kcall as I was busy with other things. On Tuesday I had two exams (fortunately, quite easy ones), which kept me busy for both Monday and Tuesday. Then from Wednesday I started packaging KDE 4.3 beta2 for debian, which was quite challenging and kept me busy for 3 days (Wednesday-Friday). I packaged only the basics (kdelibs, kdepimlibs, kdebase-runtime, kdebase-workspace and some kdesupport dependencies) and of course they are not of release quality yet (so don’t expect 4.3 beta2 packages in debian).

In the meanwhile, despite being busy with other stuff, I took some time to study a bit more the “call example” from the TelepathyQt4 examples, which is essentially a simple version of what I am developing, and I wrote some code for a “call window”, which is an object that in the future it will be able to handle a call and display a nice window with status info, the video widget, audio/video controls, etc… Yesterday (Saturday), I polished a bit the API of this object and I implemented some really basic functionality. While I was looking at the code, I thought it may be better to develop this window as a kpart, which will make it possible to be reused later in other projects, like kopete for example (when it is ported to telepathy, if this ever happens). So, late yesterday afternoon, I ported this window to use kparts. However a linker issue (telepathy bug 21340) stopped me from finishing it. Today I managed to fix this issue and I am now working on finishing the kpart. Unfortunately I don’t have much time to work on it today, but I promise it will be ready by late night today or tomorrow morning.

Now, the next step is to implement an object that will do the encoding/decoding of the audio/video. As an exception to the general design of telepathy, audio/video handling is specified to be done by the application itself and not from the connection manager that connects to the protocol. To handle this, telepathy developers have designed a library called telepathy-farsight, which internally communicates with the connection manager and handles the audio/video streaming part. To do the actual encoding/decoding, gstreamer must be used. Gstreamer is a library that resembles phonon a lot. It uses a similar pipelined architecture. From what I understand, telepathy-farsight provides a gstreamer source and a sink, which can be connected to other gstreamer objects that will do encoding/decoding, grab source from the mic or camera, output to alsa and some video widget, etc… Unfortunately, farsight and gstreamer are the only way to go here. This is how the telepathy specification is designed, and while I bet it would be possible to write something similar to farsight that will do the same job using Qt and phonon, this is too much work to do and if this ever happens, that will take a few years. So, I will have to spend this week learning the glib/gobject and gstreamer basics, so that I will be able to write this part of kcall. The “call example” I mentioned earlier provides a sample implementation of this object, but although I could just copy it, I need to understand what it does so that I will be able to extend it.

I hope this week I will work more and I will manage to make a simple call :) My current plan is to have audio/video fully working (with controls and options) before July 6th (the middle of the gsoc period), so that I can spend the rest of the period doing UI/usability improvements and implementing secondary features that may be needed. (Notice: The author of this post has the authority to change this plan without previous notice! :P)