20 May 2004

Mail Viruses

The barrage of mail viruses and their side effects is getting quite annoying. In the past week, I’ve had a gnome.org mailing list subscriptions disabled twice. After looking at the mailing list archive, it was pretty obvious why.

The mail server that serves my account is set up to reject windows executables a few other viruses at SMTP delivery time (so it isn’t responsible for generating bounces). Unfortunately, a number of viruses got through to the mailing lists and were subsequently rejected before reaching my account. After a certain number of bounces of this type, mailman helpfully disables delivery.

It’d be nice if mail.gnome.org was set up to reject these sort of messages too (in the case of gnome.org it’d probably be safe to block zip files as well, which would cut out virtually all the viruses).

It also seems that the email viruses don’t pick the sender and recipient completely at random. Apparently a number of infected machines keep on mailing the XML mailing list with my address as the sender. It got so bad that the list admin put me in the “always moderate” list. Of course, this meant that I ended up receiving many messages telling me my message awaits moderation (which are pretty easy to filter). Luckily the new version of Mailman limits itself to 10 of these messages a day.

jhbuild

I’ve merged in some of Thomas Fitzsimmons’ jhbuild patches. It isn’t yet at a stage where you can build GCJ using an unmodified jhbuild, but we’ve got some of the basics in there. A big part of the changes involve adding support for srcdir != builddir builds, which is apparently the preferred way of compiling GCJ. This is accomplished by setting the buildroot config key to the directory where you want builds to be performed. Things aren’t fully working yet, but at least some modules build in this mode. We’ll probably need to add support for marking some modules as not supporting srcdir != builddir builds, since some modules will most likely never support it.

gnome-common

I’ve been doing some work to simplify the gnome-common autogen script. A lot of the infrastructure dates back to the early 2.0 days where it was important to make sure developers could hack on 1.x apps and 2.0 stuff at the same time, which involved complicated infrastructure to make sure 2.0 packages didn’t see the Gnome 1.x autoconf macros and vice versa.

Since then things have changed. Developing Gnome 1.x apps isn’t really a priority any more (and no one was using the stuff installed by gnome-common for 1.x work anyway). We also have far fewer autoconf macros in gnome-common, and they aren’t particularly Gnome 2 specific. This is partly because I killed a lot of them last year, and deprecated most of the rest. While looking through the macros this time, it turned out I could remove another one, and get rid of the deprecated macros altogether. This just leaves some macros for setting compiler warning flags, one for adding a --enable-debug configure option.

The patch moves the remaining autoconf macros to the normal $(datadir)/aclocal directory so that aclocal can find it easily, and install the common autogen script as $(bindir)/bin/gnome-autogen.sh (which was previously a small script that would choose which set of macros and autogen script to call based on an environment variable).

Hopefully these simplifications will make it easier to debug autotool failures in the various Gnome packages. Many people seem to find autoconf hard enough to understand as is without us making things more complicated and adding extra ways that things could fail.

nxml-mode

Started playing with nxml-mode, which makes editing XML much nicer in emacs (psgml-1.3 does an okay job, but the indenter and tag closer sometimes get confused by empty elements). There is a nice article about nxml-mode on xmlhack which gives an introduction to the mode.

The first thing that struck me about nxml in comparison to psgml was the lack of syntax highlighting. It turned out that the reason for this was that colours were only specified for the light background case, and I was using a dark background. After setting the colours appropriately (customise faces matching the regexp ^nxml-), I could see that the highlighting was a lot better than what psgml did.

One of the big differences between nxml and psgml is that it uses RELAX-NG schemas rather than DTDs. It comes with schemas for most of the common formats I want to edit (xhtml, docbook, etc), but I also wanted to edit documents in a few custom formats (the module description files I use for jhbuild being a big one).

Writing RELAX-NG schemas in the compact syntax is very easy to do (the tutorial helps a lot). I especially like the interleave feature, since it makes certain constraints much easier to express (in a lot of cases, your code doesn’t care what order the child elements occur in, as long as particular ones appear). While it is possible to express the same constraint without the interleave operator, you end up with a combinatorial explosion (I guess that’s why XML Schema people don’t like RELAX-NG people making use of it). For example, A & B & C would need to be expressed as:

(A, B, C) | (A, C, B) | (B, A, C) | (B, C, A) | (C, A, B) | (C, B, A)

(for n interleaved items, you’d end up with n! groups in the resulting pattern).

After writing a schema, it was a simple matter of dropping a schemas.xml file in the same directory as my XML documents to associate the schema with the documents. This is required because RELAX-NG doesn’t specify a way to associate a schema with a document, so nxml has its own method. Matching rules can be based on file extensions, document element names, XML namespaces or public IDs, but I used the document element name for simplicity. You can specify other locations for schema locator rules, but putting it in the same directory is the easiest with multiple developers.

Once that is done, you get background revalidation of the document, and highlighting of invalid portions of the document (something that psgml doesn’t seem to be able to do). It also says whether the document is valid or not in the modeline, which is helpful when editing documents.

Now all we need is for libxml2 to be able to parse RELAX-NG compact syntax schemas …