Monthly Archives: July 2002

linux.conf.au

The call for papers is almost over. If you want to speak, please send in your abstracts soon.

GNOME

I started writing up some code to add RPM support to Nautilus. At the moment, I just have a simple GNOME VFS module that allows you to see what packages are on the system. You can see a sample of what it looks like here. The package sizes represent the installed size of the package (as reported in the RPM database), and the modification times are the installation times of the packages.

I still need to write some code so that you can view information about the package (probably as a nautilus view), and some utilities for installing and removing packages (these will probably be separate applications, which should cut down on the problems I ran into when writing GnoRPM. When it is finished, it should be pretty useful.

One of the annoying problems with libtool is the way the -export-symbols and -export-symbols-regex. The flags are supposed to limit which symbols in the library are available to programs that dynamically link to the library.

Unfortunately, the feature is not implemented correctly for many platforms. Rather than leaving symbols out of the dynamic symbol table, it just removes debugging information for the non-exported symbols (so not only does it not work, it also makes your code harder to debug …).

So I put together a simple patch to fix the problem. At the moment, it only changes the behaviour under Linux as I can’t verify whether it works correctly in the other cases (it probably does though). If anyone wants to try the patch, it is available at:

http://www.daa.com.au/~james/files/libtool.m4.patch

I wonder if libtool will make a new release any time soon?

sej: that sounds a lot more like the NPL than the MPL. The MPL does not give any special privileges to Netscape, the only mention of Netscape in the license is that they may publish new versions of the licence, similar to GPL.

In fact, the license policy states that new original code should be licenced under MPL/GPL/LGPL tripple license. I am not quite sure why an LGPL rendering library (such as the LGPL portions of raph‘s libart) should be a problem — such a license sounds consistant with the license policy for “new non-original source files”.

Wrote a short Samba patch to fix up display of the print queue when using the version of LPRng that came with RH7.3 as a print spooler. One of the new features in that version of LPRng was that it leaves one or two jobs in the print queue marked as done (apparently this was done for accounting purposes).

Unfortunately, Samba was not expecting to see jobs marked as “done” (it assumed that jobs marked “active” were being printed, jobs with a numeric rank were queued, and all other jobs were paused). This was causing a lot of confusion at the office, as Windows would not realise that print jobs had completed.

It was fairly trivial to find out what to patch in the Samba source code to fix this, so in about 20 minutes I had things up and running, and the complaints went away. It was much easier to find the correct part of the code to patch than with some other programs I have had to make modifications to.

PyGTK

In my last diary entry, I talked a bit about how long delays between releases of a package can hurt. It has been almost 2 months since the last 1.99.x snapshot of PyGTK. I will look at putting out a new release tonight after applying Arjan’s closure cyclic garbage collection patch and fixing a tree bug jrb pointed out.

A lot has changed since the last release, so it would be good to get people trying out the new version. It is probably possible to implement proper widgets now, which is a big milestone.

After the release, I will look at implementing some nicer ways to use list store and tree stores:

• len(liststore) should return the number of elements in the list.
• liststore[index] or treestore[treepath] should return an object representing the row. getting and setting indices on the row should get/set the appropriate values in the tree.
• iter(liststore) should return an iterator that returns instances of the above row objects. Haven’t thought about iterating over tree stores.

These should help make the new tree widget feel more python-like, which is helpful.

tromey: I have found automake to be a very useful tool over the years, especially when you take its constraints into account (portable make, shell, etc). Within the GNOME community, my biggest problem has been having to explain myself every time I use a feature not found in 1.4.

Many of the hackers are not even looking at the recent 1.6 releases because their packages break with them. The irony is that the parts of their Makefile.am‘s that break are usually work arounds for bugs or defficiencies in automake 1.4 (many of which have been addressed in 1.6). It is depressing to hear people complaining about bugs in old automake while refusing to upgrade (and this is for bleeding edge gnome development; not maintenance branches of the various packages).

I believe part of the reason for this is the large gap in time between the 1.4 release and 1.5/1.6 (about 2 years, IIRC). People grew too used to all the quirks and bugs in 1.4 that when they got fixed, people started complaining about it. With more frequent releases, these bugs would probably have been recognised as such, rather than features.

Another project that could do with another release is libtool. There are a number of known bugs in the 1.4.2 release (such as not being able to do a buildroot install, which really hurts packaging), and a few more architectures are supported in CVS. Putting out a new maintenance release would be a _really_ good idea.

Overall, the new autoconf and automake releases are a lot nicer to work with, compared to the 2.13/1.4 combo.