Older blog entries for oku (starting at number 4)

New Project

I am currently working on a new project. It is just an idea, and let's see how far it goes: you all know about the diversity of configuration files in Unix, it seems that every program has its own syntax. This makes it difficult to write configuration editors for web interfaces or GUI configuration editors.I do not think that much can be done about it, it is nearly impossible to convert each program's configuration file to a single, unified format. But still, most, if not all have one thing in common: they can be represented as trees, with the values as its leaves. See eg. /etc/network/interfaces. If it looks like:

auto eth0

iface eth0 inet static address 192.168.1.1 netmask 255.255.255.0 gateway 192.168.1.254

this can be represented in a tree:

auto
  eth0

iface eth0 family 'inet' method 'static' address '192.168.1.1' gateway '192.168.1.254'

So we could write a parser that reads a conf file and represents it internally as a tree. Each entry can than be accessed in a file system like manner, eg. the address of eth0 with

iface/eth0/address

The same can be done with other conf files, eg, XF86Config-4, dhcpd.conf etc. What we then need is a common way to access and modify the tree. This can be simple commands that are called from shell scripts or functions in for example C. To get the address of eth0 in a shell script, we could write:

cnf ifupdown get iface/eth0/address
And the same for XFree86, for example to get the device file for the mouse:
cnf xfree86 get InputDevice/Device
In the latter example, we may have ambiguities, I have two mouse devices. So a real script would have to check the Identifier.

So this way it is possible for shell scripts to get the IP address or other values for an interface easily, and different configuration editors can rely on a unified library to access and modify data.

Of course, this approach does not make it easy as pie: it is still necessary to write a parser, and to change values, also an 'unparser' that writes the data back, without loosing any changes that are not understood, and if possible, also any comments that have been made in the fille. That's why I do not know yet how far this project will get.

weekend is over
Back in Erding since yesterday. For the record: driving took 3:55. I think I should drive more relaxed...

Debian
Updated ifplugd twice a day, because I forgot to put pkg-config into Build-Depends: and of course the buildds failed. Also updated waproamd. So I closed 9 bugs in one day ;-).

Moving to USA
Yes, that's right. More about this later. Anja found a good link for apartment rentals: www.rentnet.com.

Okay, it is weekend, and now I am in Göttingen again. 4hours and 15 minutes drive, not bad for 524km. I am tired, but my little daugher is still awake. It is 00:28.

Just found a strange problem with one of my Debian packages that I maintain, ifplugd. Seems that after some time it does a lot of disk I/O, though it shouldn't - it does not have to do anything with files. My notebook made click-clack all the time, and I tried everything until I did 'killall ifplugd', and then it was quiet. Strange. Wrote upstream about it.

I have a love/hate relationship with autoconf/automake... it is somehow cool for detecting libraries and stuff, it also may make cross compiling easier if done correctly. But it can also cause lots of trouble, even if done correctly:

I have autoconf'ed a small package I am currently developing, and it was all fine, it works, I built a Debian package of it, tested and was happy. I did this on a sid box. But it will be really used on a woody box, so I backported the package for woody, in a chroot, with autoconf and automake installed. I know that during build of a Debian package autoconf/automake should not be used, but just ./configure. But, for some reason during the configure stage autoconf is called, finds that the configure.ac is for autoconf 2.58 and fails... so why is this necessary? I tried different things, like putting another version number to AC_PREREQ, but autoconf 2.53 wants some other details differently, so that did not work out. Final solution is to uninstall autoconf in the chroot.

So autoconf does exactly the contrary to what it is intended for: to find out the environment a package is built in and configure the package accordingly. But fails miserably when it finds an old version of itself.

BTW, the same thing happened to me when I tried to backport flow-tools. Uninstalling the auto tools finally helped.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!