Will's blog

A couple of days ago, I did a dist-upgrade on my server which runs Debian. I'm not sure what version I had prior to the upgrade, but after the upgrade I'm at 1.6.2. The problem is that the wiki syntax is different, so my wiki data was mildly hosed. I ended up spending 45 minutes to an hour trying to figure out how to migrate the data.

The magic script is /usr/share/python-support/python-moinmoin/MoinMoin/script/moin.py . You need to run it like this:

$ ./moin.py --config-dir=/path/to/wikiconfig.py/dir/ migration data

The other problem I had is that I had no meta file in my data directory and so the moin.py script would die with a stack trace like this:

Traceback (most recent call last):
  File "./moin.py", line 24, in ?
    run()
  File "./moin.py", line 15, in run
    MoinScript().run(showtime=0)
  File "./../../MoinMoin/script/__init__.py", line 138, in run
    self.mainloop()
  File "./../../MoinMoin/script/__init__.py", line 251, in mainloop
    plugin_class(args[2:], self.options).run() # all starts again there
  File "./../../MoinMoin/script/__init__.py", line 138, in run
    self.mainloop()
  File "./../../MoinMoin/script/migration/data.py", line 44, in mainloop
    curr_rev = meta['data_format_revision']
  File "./../../MoinMoin/wikiutil.py", line 472, in __getitem__
    return dict.__getitem__(self, key)
KeyError: 'data_format_revision'

I assumed that I had some version of 1.5 previously and so I created a meta file with this in it:

data_format_revision: 01050800

After doing that, the moin.py script worked nicely and all my wiki data is in the correct syntax now.

I'm trying to get Ubuntu Hardy support for Miro. I installed Hardy Beta 1 in a virtual machine with VirtualBox. The install went fine. I had problems fixing the resolution, though.

Hardy starts off with an 800x600 resolution which is too small to run Miro. To fix it, you have to:

1. run sudo displayconfig-gtk from a terminal
2. click on the dropdown for models and choose LCD Panel 1024x768
3. click on the Test button to make sure it works
4. click on the OK button to apply that one change
5. log off
6. log on again

DON'T change the monitor AND the resolution of the screen at the same time. If you do that, you see no errors, no changes get made, and you'll spend a while scratching your head wondering what happened.

If all went well, you should see the resolution you were looking for.

Note that since Ubuntu Hardy is beta software, this could all change tomorrow.

The Ubuntu Massachusetts LoCo Team is hosting an Ubuntu Install Fest on 10-13-2007 from 9:00am to 5:00pm in Cambridge, MA.

"The festival is an opportunity for the Ubuntu team to show normal computer users how easy using the Linux software has become. Volunteers will be on hand to answer questions, present demonstrations and help users install the free, open source Linux operating system. Ubuntu CDs, case badges, drinks and snacks will be available."

The case badges are pretty nice. I put one on my laptop a week ago and already people have asked about it.

I think I'm going to be bringing my laptop and depending on what's going on, I will demo Miro.

See the wiki page for more details (date, time, location, press release, ...).

I don't use the right alt key much and at some point in time it just stopped working. I thought the key itself was dead, though that was puzzling. Turns out Ubuntu Feisty (and possibly earlier versions--I have no idea) maps the right alt key to a third-level character input key for extended characters.

I bumped into the System \rightarrow Preferences \rightarrow Keyboard panel and also discovered I can very easily switch my caps lock key to a control key. Ahhh... happy emacs pinky....

The hard drive on my laptop was doing some weird things on occasion and I decided to get a new one and an external case to stick the old one in. Figured while I was going to be replacing my hard drive I might as well install Feisty Herd 5 and use that.

Installation had no problems. I was up and running with all the updates in 3 or 4 hours (I have a slow Internet connection and there were a lot of updates). I fiddled with things to get Beryl working mostly because I want an Expose kind of thing, but ... it was really sluggish (I've got a Gateway 450ROG with an ATI Radeon Mobility 7500) so I removed it.

Everything looks good so far. Figured I'd mention it in case anyone else was thinking about Feisty Fawn.

I innocently did an apt-get dist-upgrade today and suddenly Apache wouldn't serve any static files, but anything generated by CGI scripts worked super! Apache would send the headers for static files complete with a Content-Length correctly but wouldn't send any data in the HTTP response (even for an HTTP 200).

I spent hours trying to figure out what was going on under the assumption that I did a bad upgrade. I skimmed documentation, made sure my conf files were ok, did dozens of Google searches and then finally gave up and walked away for a couple of hours.

Long story short I finally hit gold with the right mantra of search terms and bumped into the EnableSendFile directive. I added:

EnableSendFile Off

to my Apache conf file and it works fine now.

I mention it in case someone else does a dist-upgrade with Debian testing on or around November 15th, 2006 and discovers themselves in the same boat.

I went to update bluesock today and had wicked problems when it tried to upgrade tetex-bin to version 3.0-18. Every time it'd try to configure tetex-bin, it'd fail with this:

Setting up tetex-bin (3.0-18) ...
Running fmtutil-sys. This may take some time... Error: `etex -ini  
-jobname=jadetex -progname=jadetex &latex jadetex.ini' failed
Error: `pdfetex -ini  -jobname=pdfjadetex -progname=pdfjadetex &p
dflatex pdfjadetex.ini' failed

and lots of other output.

After futzing with things for a while I finally started skimming the Debian BTS and discovered bug 334613. Towards the bottom, Frank says that he can reproduce the bug by having jadetex installed before upgrading.

So I did an apt-get remove jadetex then an apt-get upgrade and tetex-bin installed fine as did everything else. Then I re-installed jadetex and docbook-utils and my system is happy again.

Figured I'd mention it in case anyone else had the same problem.

I've been running Edgy Eft for a week or so now. In that time, I have successfully performed the following feats that surprised me:

• docked and undocked my laptop without shutting it down and restarting (something that Windows XP would bluescreen on); the battery applet pops up, the screen dims, the laptop knows when it has been docked and undocked
• undocked my laptop, plugged in an HP 1510 PSC printer (USB connection), added a new printer, and printed out my estimated tax forms (which I need to fill out pronto)
• switched between docked and ethernet to undocked and wireless (for some reason I consistently had problems with my wireless connection)

Minor point: I've only had Windows XP and Ubuntu Edgy Eft Knot 2 (with lots of updates so far) on my laptop, so I can only compare between them.

The reason I bring this up is that I'm really excited because this is really fantastic. The total amount of time I've spent installing, fixing configuration files, reading through forums and researching problems, etc. is at most an hour. I spent some time trying to figure out a minor problem I had with installation, but that's it; everything has worked in a way that has been hassle-free.

I'd like to thank the Debian folks, the Ubuntu folks, and all the other thousands of folks who've worked to make this a reality.

I installed Ubuntu Edgy Eft on my Gateway 450something-or-other laptop a couple of days ago. I had one problem with installation where X doesn't come up, but pressing Alt+F3 a bunch of times does something and then everything works nicely. I haven't had any problems since then.

Figured I'd mention it in case anyone else was thinking about Edgy Eft.

Turns out the Debian packager doesn't enable SPF in the exim4-daemon-heavy package. But it took me a couple of hours to figure that out. I ended up implementing SPF using the libmail-spf-query-perl package by adding the following rule to my rcpt acl just before greylist stuff:

  accept
    message     = [SPF] $sender_host_address is not allowed to send mail \
                  from $sender_address_domain.
    log_message = SPF check failed.
    set acl_m9  = -ipv4=$sender_host_address \
                  -sender=$sender_address \
                  -helo=$sender_helo_name
    set acl_m9  = ${run{/usr/bin/spfquery $acl_m9}}
    condition   = ${if eq {$runrc}{0}{true}{false}}

The exit codes for spfquery are in the spfquery file (it's a Perl script) and the code for "pass" is 0. So (in theory) this will accept any email that passes the SPF check. Any email that fails the SPF check will go through greylistd. I think that does what I want it to do.

Incidentally, I found the above code (though I inverted the check) here at The Linux Documentation Project.