Feel free to skip this if you are not interested in political blogs…

The German government is planing to release new ID-Cards in 2009 for all citizens. To add some additional values to that cards they will contain some electronic signature to be able to prove your identity on the internet. That of course is really a good idea and they even try to protect your privacy by introducing a PIN code if someone wants to read from your card and the possibility to allow to read a subset of the data (e.g. your birth date).

The problem is that the good things end here. Because together with the chip that should be readable in any chipcard reader it is physical attached to the card should contain an RFID chip. Other than reading from the chip which nobody can do unless you give him the card, the RFID chip can be read without noticing. Big brother will now everywhere you go and even more dangerous everywhere you have been.

To make it even worse, in addition to the photo which is rather public on the card anyway, the RFID will contain two fingerprints. They do not only know where you have been, the also know what you touched (and they can easily break your cool new biometric authentication…). And it’s getting even better because they also create a central register of the photos and the also want (but there is even some resistance inside the government) a central register of the fingerprints.

You may say now, that you have nothing to hide. Do you? What if you have been at the wrong place at the wrong time? Demonstrated against the government and they put an RFID reader along the street?

Remember big brother is watching YOU!

This post is for all people that need debian packages for their software but are far too lazy to really learn all this packaging from the beginning. But be aware that it is really easy to build broken packages. I will not explain how to build packages for simple applications since this is explained quite good in the Debian packaging guide. Anyway, it does not explain library-packaging at all.

Packaging a library is not really difficult most of the time. Given that most GNOME libraries share a very common build system layout it would be a waste of time to start from scratch. So we search for a library the seems to be a good starting point for our own package. In my case, packaging libnotifymm, this was obviously glibmm. So first step, get the sources of that package:


apt-get source libglibmm-2.4-dev


Next step, copy the debian directory over to your project, not very tricky either, and delete the useless changelog:

cp -r glibmm-2.4-2.13.3/debian libnotifymm
cd libnotifymm/debian
rm changelog


Now, you end up with some files in the debian directory:

• copyright: Check the license, put your name in, etc
• control: The most important file. Replace the name of the library you took as sample with the name of your actual library, take care of the versions and update the dependencies. With an appropriate sample file the format is quite obvious.
• *.dirs, *.install: These file show where the library gets installed on the system. Normally you should not have to change much here apart from renaming the files from oldlib.dirs to newlib.dirs. But always take a look a the files as there is probably mentioning the old package somewhere and you want to change that.
• rules: Do not touch for now. Hopefully it will just work, otherwise you will notice that later

In the end, create a changelog using this command which will ensure you have the correct format:

dch --create


Now, let’s give it a go:

dpkg-buildpackage -rfakeroot


If you are (too) lucky, you will have fresh debian packages now. If not, it’s time to check the rules file for stupid shell scripting. The error messages normally give you some indication what could have been wrong. You may need some tries before everything works smoothly.

When you have finished, check if the packages install cleanly on your system and explore them with file-roller to see if they really install all the files needed.

As said before, this is really not the greatest way to create packages and you will do better if you read all the documentation about building packages. But often you get the idea from looking at other packages.

So I am happy to annouce anjuta 2.2.1 (stable) release which is a rather unspectacular bug-fix release. Anyway, it fixes most critical bugs reported since our first stable realease in 2.2 series.

But we are not there yet. A lot of development is happening in trunk currently. But a screenshot is worth more than thousand words:

This shows a function tooltip in gtksourceview editor which now finally works and provides equal, but better-looking functionality as the scintilla editor.

And as we will soon merge the new sqlite-gda-based symbol-db, we will be able to have much better support for different languages and for more complicated cases. Think of “myclass.return_something()->do_something(” for example.

But I would also like to ask for help. Is there any GTK+ wizard who has an idea about this gdl related crash (or with a similar trace). It seems to crash deep inside GTK+ and I have no idea what could be the cause. Thanks!

This is something I noticed playing around in valgrind and seems to be quite common in GTK+ code. When you retrieve a string from a GtkTreeView, YOU are responsible for freeing it:


gchar* my_string
gtk_tree_model_get (model, COLUMN_MY_STRING, &my_string, -1);
g_message ("Printing my string: %s", my_string);
/* Do something more useful
------------------------------- */
g_free (my_string); // Important, otherwise YOU leak memory.


In the hope it is correct and helps some people…