Older blog entries for jamesh (starting at number 159)

Bushisms

I found this one quite good.

Compulsory Voting

tberman: I agree that voters should have the right not to vote for anyone, but don't feel that simply not turning up to vote is a good way to do so. In a non-compulsory election, the non-voter count is going to be comprised of those who are abstaining from voting, and those who are simply two lazy to turn up. With compulsory voting, those who don't wish to vote for any particular candidate can simply leave their ballot blank, which is known as an informal vote.

Given the difference in turnout between U.S. and Australian elections, I'd guess that a fair number of the people who don't vote in the U.S. would vote if they had to turn up to a polling place on the day.

I also think it is important for as many people as possible to vote. The people who get elected are supposed to represent the electorate. When there is a clear majority it doesn't matter much, but in a marginal seat, those missing votes could easily swing the result. In this case, people can claim that the winner does not have the support of the majority of the electorate.

As far as the U.S. gravitating towards a two party system, I'd suggest that this is caused more by the vote counting procedure than the culture. When you have a system where where voting for someone who won't get a high first preference count is equivalent to not voting, people are going to gravitate towards the parties where their votes actually make a difference (or not vote at all).

With a preferential system, you can vote for a minor party as your first preference, then number off the major parties with your other preferences. This also fixes the problem where two similar candidates might split the vote causing both to lose -- one will get knocked out, and their votes will be transfered to the next preference (which would likely be the other similar candidate). This generally leads to the least unpopular candidate winning, rather than the most popular one.

Fahrenheit 9/11

Went to see Fahrenheit 9/11 on Monday night. It was an interesting movie, but it was clearly aimed at a US audience. It did have a fair bit of information I hadn't heard before, but in some areas he was obviously choosing which bits of information to include to increase the effect (eg. when listing the countries in the "coallition of the willing" he didn't list Britain). Other bits seemed particularly relevant like the bit about the Bush administration playing with the terror alert apparently for political reasons, given what has happened so far this week.

Overall, I thought it was a good movie.

Firefox

Firefox is quite a nice browser, but the toolbars seem to have too much padding round the buttons in the toolbar. It looks like this is due to the double padding round the back and forward buttons.

It looks a bit better after creating a chrome/userChrome.css file in the profile directory containing the following:

@namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"); .toolbarbutton-1, .toolbarbutton-menubutton-button { padding: 5px !important; } .toolbarbutton-menubutton-button { margin: -1px 0px -1px -1px !important; } .toolbarbutton-1[type="menu-button"] { padding: 0px !important; }

You might need to adjust the negative margins to match the xthickness/ythickness of your GTK theme in order to make it look okay.

The other cool thing is that some people are working on adding GTK stock icon support to the Mozilla code base. While the initial focus of this is to add stock icons to buttons in the dialogs, it sounds like it could be extended to toolbar buttons and other places in the future. This would make it fit in on the Gnome desktop a lot better.

Subversion

Have been looking at the Subversion 1.1 release candidate, and it looks pretty good. This could be the point where more people start to seriously look at using Subversion as a CVS replacement.

This would be largely due to the new fsfs repository backend. This new backend doesn't use berkeley db, and shouldn't ever wedge like the BDB backend does occasionally. Furthermore, you don't need write access to the repository to perform read only operations. This should make it a lot easier to set up systems where you have multiple ways of accessing the repository (eg. svnserve/ssh for write access, DAV and viewcvs for read access).

The fsfs backend stores each revision of the repository as two files in the repository (one for changes to the files/properties, and one to store revision properties), and doesn't modify the files associated with previous revisions when performing a commit. This means that the the existing backup and mirror infrastructure that projects have set up for CVS repositories should work equally well for Subversion.

The "new file for each revision" policy also has some nice features. In the case of svn+ssh access where each committer can directly access the repository files, it means that the existing revisions in the repository can be made readonly without preventing people from committing new revisions (something that can't really be done with CVS).

These administrative improvements should make it a lot easier to deploy Subversion, which in turn let more developers take advantage of its features.

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 ...

An interesting essay on asylum seekers by Greg Egan (a local Science Fiction author). If you are interested in the subject, Dark Victory is also worth reading.

ViewCVS

Made a few more changes to the Gnome viewcvs. Pretty much all of the original ugly colour scheme is gone now, and I got it to pretty print some more files with gnome specific file extensions.

We are maintaining the modifications in CVS using the standard vendor branch/main branch setup. Since the cvs import command is one that people screw up the most, I wrote some scripts to help with exporting viewcvs from upstream CVS and then importing it into our CVS.

When I went to test the script, it worked fairly well, except for the fact that some of the template files had been moved between the two pulls. Since there was no link between the two different file names, CVS wasn't able to merge my local changes. Other than that, the merge went okay.

I wonder if Arch or Subversion would have been able to handle this situation any better, given that the upstream repository didn't record that the file had been moved?

ViewCVS

After the breakin at the gnome.org web server, the CVS server were moved over to the new server HP donated. However, the LXR and Bonsai tools weren't considered as high a priority, so have not been restored yet.

Since it was easier to set up than either LXR or Bonsai, I set up ViewCVS (with jdub's help), so we now have online repository browsing again. It doesn't provide all the features found in the other packages, so it'll be good to get them set up again too though.

We made a few superficial changes to the templates to make them look a bit more gnomey, but they probably still need a bit more work.

jhbuild

Merged a patch to add an optional "make clean" phase to jhbuild, and added a "make check" phase (also off by default). These should be useful for the unattended "tinderbox" mode.

It does increase the complexity a bit, so I think I'll have to look at how to simplify it a bit (probably pull a bit more of the logic out of the program code).

jhbuild

Made some changes to the way "jhbuild bootstrap" works. Whereas previously bootstrap would check to see if each required build tool was installed by the distro and only build the tools that were missing, it now builds all the tools.

If you wish to use the build tools supplied by your distro, it is now recommended that you don't run bootstrap. To perform the "check that required tools are installed" job that bootstrap used to do, you can instead run the "jhbuild sanitycheck" command, which will do these checks and report any errors. The sanitycheck command also checks for other configuration problems as well, such as whether the all the different automake versions will be able to find the libtool macros.

The upside for me is that there are now only 2 combinations of distro packages vs. packages installed by jhbuild, as opposed to the 2n combinations previously (where n is the number of bootstrap packages). This greatly reduces the number of ways someone can screw up their system.

Since bootstrap is a lot simpler now, I also changed how it was implemented. Rather than using a separate code path, it now uses the same build framework as the main build. The bootstrap command is now functionally equivalent to building meta-bootstrap from the bootstrap module set. Changing the list of bootstrap packages can now be done as easily as modifying any other module set.

Removing the redundant code path should make things a little more robust, since it reduces the amount of infrequently used and/or untested code.

IPP

Did a little more hacking on my IPP client library, and wrote a small PyGTK program that lets you do simple management tasks (view all print queues/classes, view queued and completed jobs for printers, stop and start print queues, etc).

If you want to try it out, grab ipplib.py and printerlist.py. Put them in the same directory and run "python printerlist.py". Seems to work pretty well for less than a thousand lines of code.

To get things working with CUPS's authentication, I do the following for operations like Pause-Printer:

1. Submit request to the HTTP URI corresponding to the IPP one.
2. If the response has an IPP status code of client-error-not-authorized, then resubmit the request to the URI /admin/ relative to the previous URI (not changing the IPP message).
3. Return the IPP response message.

This seems to work quite reliably, so I might add the fallback to all the IPP requests.