A little while ago, I discovered Emacs has D-Bus support now. I wanted to play around with it, and I discovered Alban’s collaborative editing page. It seems like Emacs’s D-Bus documentation is somewhat lacking, though CVS has some more docs.

Alban’s work seems to need a well-known name, something Emacs can’t yet do, so I’ll probably add a method to text-remote-control where any app can register and say “Hi, I support your interface” as I think this makes more sense. I don’t have any code that does anything useful yet, but once text-remote-control is fixed, I don’t think that’s very hard.

I finally got around to releasing eweouz 0.2 tonight. It is still a bridge between emacs and Evolution Data Server, now with both gnus and wanderlust support.

Changes include:

• Actually works now, sans stupid typo
• A bit more documentation
• Now handles non-ASCII names, thanks to setlocale.
• Be a bit more paranoid and fail if opening addressbooks and such fails.

eweouz now also has a mailing list and a git and gitweb repositories.

I just released the first version of eweouz, the interface between emacs and evolution-data-server. Sources are available, no packages yet. It is now possible to both add contacts from within gnus and search for contacts.

Patches and feedback is of course welcome.

Today, I submitted my two first patches to the kernel. One is fairly trivial (remove a USB ID from the pl2303 driver), the other is a fixup of a patch from some other guy, which adds support for DTR, RTS and CTS to the ch341 driver. Yay, hopefully they’ll get accepted.

The reason for this journey into kernel land is I got a TEMPer USB thermometer in the mail yesterday. After a fair bit of digging around, I found some source code to drive it from C# and Windows. I wanted to poke at it from Linux and C.

After more poking, I found it’s an I2C device connected to the USB serial adapter, where you talk to it by twiddling DTR, RTS and CTS. The C# code was fairly easy to port, so now I can get temperature readings from the command line. The code is a quick hack, but I guess it might be interesting to some people. Oh, and the calibration seems entirely off (but it was off in Windows too), so feedback on whether it’s more accurate for other people would be appreciated.

Some years ago, when I hacked on a TDB backend for Evolution Data Server (EDS), I also wrote something about writing some command line tools for accessing my contacts and so on. I’ve finally gotten my act together and wrote the necessary glue to have addres completion between Gnus and EDS. It’s nowhere as feature-complete as BBDB is, but it allows you to complete addresses, at least. Get it from git (gitweb). I’ll hopefully expand it a little bit and cut a release fairly soon.

Various people have been posting about what to do when the zombies attack.

You are in a mall when zombies attack. You have:
1. One weapon
2. One song blasting on the speakers
3. One famous person to fight along side you.

1. Katana. Doesn’t run out of ammo and should slice up those zombies quite nicely.
2. One of the songs from the soundtrack of “The Rock”. I can’t remember which right now, since it seems to have disappeared from my music collection.
3. Given I’m facing undeads, somebody holy. I suppose Jesus might work well.

(This post is mostly as a reminder to myself on how I’ve set up my backup system. It should probably go on a wiki instead so I can keep it up to date.) After the recent OpenSSL debacle in Debian and Ubuntu, I found that all my backups were encrypted with something amounting to a well-known secret key. Ouch. I was not entirely happy with how my old backup system worked either (it was based on boxbackup). In particular, the on-disk format was opaque, the tools needed to access it were not particularly user-friendly and I had to run Yet Another CA for managing the keys for it.

After looking around a little, I settled on rdup which is a tool very much written in the unix tradition of “do one thing and do it well”. As it reads on the home page:

The only backup program that doesn't make backups!

(which is almost true).

It keeps a list of information about which files have been backed up locally on the machine to be backed up, including some meta-information such as file size and permissions, so it can take a new backup if any of those changes. For more details, read the web page and the source.

rdup is more of a framework for making your own backup system than a complete system in its own right, so this post is really about how I have customised it.

First, I want my backups to be encrypted, and rdup supports encryption (both GPG and mcrypt). I’m lazy, so I settled on what rdup-simple gives me, which is mcrypt. Key generation is easy enough: head -c 56 /dev/random > /root/backup-$(hostname).crypt.key and then a chmod 600 to avoid it being world-readable.

In /root/.ssh/config, I put

Host backup-$hostname
Hostname $backupserver.err.no
User backup-$hostname
IdentityFile /root/.ssh/id_rsa_rdup
ProxyCommand pv -L 40k -q | nc %h %p

so as to make it fairly easy to move stuff around and to make it pick up the right identity. The last bit is a trick to rate limit it so it doesn’t saturate my DSL. pv has a wonderful -R switch which lets me change the arguments to an already-running pv, if I want to do that. ssh-keygen -t rsa -f /root/.ssh/id_rsa_rdup to generate an ssh key. It got put into /home/backup-$hostname/.ssh/authorized_keys on the backup server, so the line reads like:

command="/usr/local/bin/rdup-ssh-wrapper",no-pty,no-port-forwarding,no-agent-forwarding,no-X11-forwarding ssh-rsa AAAAB3N

The /usr/local/bin/rdup-ssh-wrapper is a small perl wrapper which only allows the rdup commands and sanitises the command line somewhat. Since I don’t want to make a backup of all bits on my machines, I have an exclude file, which lives in /root/rdup-exclude. It is just a list of regexes of files to ignore.

To actually make a backup, I run something like for p in /etc /home /var; do rdup-simple -v -a -z -E /root/rdup-exclude -k /root/backup-$(hostname).crypt.key $p ssh://backup-$(hostname)/srv/backup/$(hostname)/$p ; done which then goes on for a while. It gives me nice structures with hard-linked files to avoid using more disk space than needed. I can then just have a small find(1) script prunes old backups as I don’t need them.

From tomorrow on, I’m working full-time for Linpro, a Norwegian Linux consulting company.

This post is both an attempt at replying to a bug against telepathy-glib, but also an attempt at explaining what Requires.private do (and don’t).

I am using Evolution as my example here, not to pick on Evolution or its authors in any way, but because it’s a convenient example. Currently, on Ubuntu Hardy, evolution links against 75 different libraries. Amongst those, we find libz.so.1, libXinerama.so.1 and many more. I’ll go out on a limb here and claim that Evolution does not call any of the functions in libXinerama directly. Let that be the assumption from here on.

An obvious question then is, why does evolution link against libXinerama.so.1 if it doesn’t use it? To answer that question, we need to go back in time to before we had dynamic linking. If you wanted to build a binary like evolution you had to have 75 -l statements when you linked and you ended up with the whole code for Xinerama embedded in your email and calendar client. For various reasons, we stopped doing that and switched to dynamic linking where the evolution binary just contains a reference to libXinerama. At some point we also grew the ability for libraries to contain those references to other libraries, so you don’t have to hunt down all the dependencies of libfoo when you are linking with it. We also got tools such as libtool which try to abstract away a lot of the problems of building on older platforms which don’t support inter-library dependencies.

Now, since evolution still doesn’t use anything directly in libXinerama.so.1 but just uses a library which in turn links against libXinerama.so.1, it shouldn’t be linking against it. Then why is it linked with it? Again, we need to look back at history, and for this part I am at least partially responsible.

pkg-config was originally written as a replacement for gnome-config and various other -config utilities. Lots of libraries and applications now ship .pc files and we have a standardised interface for querying those files. One of the problems the original authors of pkg-config faced was the problem of dependencies. They added dependencies so the authors of gst-python-0.10 could say “We need pygtk-2.0 too” and so the compilation flags needed for gst-python-0.10 would also include those for pygtk-2.0. Note that I’m using “compilation flags” loosely here, I am not just talking about CFLAGS.

This did not fix the problem of inflated dependencies. Not at all. I talked with some of the Debian Release Managers back in 2004/2005 and we worked out a solution which should help us have correct, uninflated dependencies since the then-current way of handling dependencies caused big problems for migrations of packages between unstable and testing.

The plan was to introduce a new field, Requires.private which would not show up unless you passed --static to the pkg-config invocation (since you need all libraries if you are linking statically). This definition of Requires.private was mostly useless since GNOME and GTK+ have a habit of including each other’s headers. To make a long story short, I changed the semantics so the Cflags field from private dependencies were included even when not linking statically.

A problem which pkg-config does nothing to guard against in this case is if you have libfoo.so.2 linking against libbar.so.1 and libfoo.so.2 exports some of libbar’s types in its ABI (and not just as pointers, but actual structs and such). If libbar’s soname is then bumped to libbar.so.2 and libfoo is rebuilt, libfoo’s ABI has changed without a soname bump. This is bad and will cause problems. If your application is linked against both libfoo.so.2 and libbar.so.1, you’ll still get problems since libfoo.so.2 then suddenly pulls in symbols from libbar.so.2. If you used symbol versioning, you would at least not get symbol conflicts and your application would continue to work, but you would have a spurious dependency and the package containing libbar.so.1 would be kept around until your application was recompiled.

With this background, you might ask the question why we still have Requires since it is seemingly useless. For C, it is useless in all but the most special cases, just use Requires.private instead (and its sibling Libs.private). Other languages have different semantics. Some people use .pc files for other purposes such as gnome-screensaver having variables defining where themes and screensavers go.

Hopefully this blog post has explained a bit about why we have Requires.private and what the difference between this and their regular counterpart is. If there’s anything unclear, please do not hesitate to contact me.

Gunnar Wolf claims that Ubuntu ships a passwordless sudo by default. This would be an insane default configuration, so Ubuntu doesn’t. What they do however is add the default user to the admin group which is allowed to use sudo.

Incidentially, Debian does the same thing (except it’s just for the first user, not the admin group) if you don’t set a root password.