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.

I finally got tired of Achievo not remembering what projects I last used, so I whipped up a small greasemonkey script to do that. It just makes the selection sticky, nothing very fancy.

I am currently working on implementing a cryptographic file system using FUSE. It is different from EncFS and similar in that it just mirrors a normal directory tree, but encrypts the contents of the files as they are read or decrypted as they are written.

My use case is backups. I have some machines where I and only I have access, machines which may contain proprietary information, personal emails and so on. Of course, I want backups of those, so when the hard drives stop working, I don’t lose any data. The machine(s) I am backing up to, however are not always machines where I trust all the people with physical access to not make a copy of my data. In addition, I don’t want broken hard drives returned under warranty to contain unencrypted data. This use case is the reason for why I’m encrypting on read rather than on write.

I have chosen to use CTR (counter) mode together with AES which should give acceptable security. One of the requirements CTR needs to work well is a nonce, typically 64 bits (for 128 bit AES) which must not ever be used twice. If you use it twice, you leak information about your plaintext, which is, for obvious reasons, bad.

My current design headache is how to choose a good nonce. Ideally, I believe it should be persistent for each version of the file and unique per file. Using the inode number takes up 64 bits (on AMD64 at any take, or when using -D_FILE_OFFSET_BITS=64 on 32 bit platforms). So while this gives me the latter, it doesn’t give me the former at all. I am wondering if I should use the inode number modulo 2^32 (effectively choosing the lower 32 bits of the inode number) and then something which is fairly sure to never be the same, such as mtime (or at least the lower 32 bits of it, when time_t becomes 64 bit). The reason for not just choosing a completely random value is I don’t want a command like diff file1 file1 to claim there are differences in the file.

My hope was I’d get a great idea on how to solve the problem as part of writing it down. Alas, that hasn’t happened, so if you happen to come across a great solution (or a reason to avoid a particular choice), feel free to email me

In Soviet Boston, button pushes you. Here is proof:

I’m in the process of moving servers at the moment, and amongst the services I am moving is my authenticated, but public SMTP relay service. That service includes a basic web-based CA whose CA certificate is going to expire in July 2008. Apparently, it is possible to refresh CA certificates without having to distribute fresh certificates to all the clients. The magic steps, using openssl are:

First, generate a new CSR using the existing certificate and key as input:

openssl x509 -x509toreq -in cacert.crt \
  -signkey cakey.key -out renew.pem

Then sign it:

openssl x509 \
  -extfile openssl.cnf \
  -extensions v3_ca \
  -CA cacert.crt -CAkey cakey.key \
  -set_serial 0 -days 365 \
  -req -in renew.pem -out newcacert.pem

This information was quite hard to come by, so hereby put here so I can find it if I need it again.

Daniel Burrows writes about the feature of some call centres whereas if all operators are busy, it gives the caller the option of being called back. He’d like the nice twist of being able to enter his phone number on a web page and then be called back so he doesn’t actually have to call, then wait.

I’m not sure where Daniel lives, but I’m happy to report that this practice is quite common here in Norway, so it might well be on its way to whatever companies are local to Daniel.

Also, why does bloglines link to the completely wrong place on dburrow’s posts? It links to http://planet.debian.org/tag:blogger.com,1999:blog-$blah rather than the real URL.

Recently, I added some photo related blogs to my reading list, amongst them strobist, and so I came across a post about the Open Source Wireless Trigger. Being interested in both electronics and free software, I read through most of the posts on the forum as well as the wiki. I also started experimenting a bit with an old Nikon SB-24 flash I had lying around since even if I managed to break it, it wouldn’t be that bad. And it’s old and robust.

So far, I’ve played around with how to make the flash go off. For the hot shoe, it’s just shorting the ground and center pin (I just used a big resistor). For the PC connector, I had to apply a bit of voltage; I used an AA/LR06 battery and that worked splendidly. (Oh, and PC in this context has nothing to do with computers, it’s an abbreviation of Prontor-Compur, two shutter manufacturers who decided on the design of the connector back in the 1950s.)

Just like an infinite number of monkeys, given infinite time are likely to produce infinite copies of Hamlet, I knew that given an infinite number of blog postings by Clint, I had to find one which both made sense to me and which I agreed with.

Somebody please write a free syndicate (or syndicate wars) clone.

I just read Sun’s announcement of “Project Hamburg”. I am not sure what it is about, but that is not very important in this context. I have worked a bit with Intel lately and gotten introduced into a whole new world of code names such as Mccaslin, Menlow and so on. Up until now, most of them were obscure enough that I thought they were just random names picked from somewhere, but they are, like Sun’s names of geographical features, be it towns, cities, rivers or something else. The reason for this naming is, like Sun’s, that geographical names can’t be trademarked, though in this particular case, Sun supplied a short list of “why Hamburg” with some references to Hamburg’s history.