Today I happened to read about lazr.enum in a mailing list. I went to the PyPI page and saw raw ReStructuredText markup instead of a nicely formatted page. Now I know from prior experience that this happens when the package's description has an error in the markup. I thought I'd report a bug and provide a patch.

Leap of knowledge: since I know lazr.enum was created by the Launchpad.net team I could safely assume they were keeping the sources in Launchpad. Therefore I was pretty sure I could get them with

$ bzr branch lp:lazr.enum

so I ran that command and it worked.

Next I looked at setup.py to see how it produces the long_description field. It was reading the contents of a couple of text files, one of them being src/lazr/enum/README.txt. I looked at that and saw a .. toc-tree: directive that does not exists in plain docutils (it's a Sphinx extension).

I added up a couple of lines to setup.py to strip that out, tested it (with setup.py --long-description > test.rst; restview test.rst) committed to my local branch, and created a bug report in Launchpad. Then I was a bit lost, since I didn't know how to make my fix available. Attach a patch? Maybe, but I wanted to see if this distributed version control thing is good for anything else.

I thought that first I'd make that branch public, and then see if there was a way to link it to the bug report. I ran

$ bzr push lp:~mgedmin/lazr.enum/pypi-fix

which took a few seconds to create a new public branch on Launchpad with my fix in it (it would be nice if I didn't have to explicitly specify my Launchpad username and the project name—both of which bzr already knows—and just specify the name of the branch). Then I went back to my bug report and saw an option to link it to a branch. There was a search field in the popup that found my "~mgedmin/lazr.enum/pypi-fix" easily enough when I pasted it into the search box.

After clicking on the branch, I saw a "propose a merge" option. I did that and Launchpad sent an email to the developers asking them to merge my fix.

I made one mistake, I think: I should've created the bug report first, and then mentioned the bug number in my commit message (with bzr commit --fixes=NNN, although here I'm suddenly not sure if the bug number should be left bare, or prefixed with something like "lp" to indicate it was a Launchpad bug number?).

Other than that it was a pretty smooth experience. When will I be able to do that for Ubuntu packages?

Wanted: PyBlosxom plugin to bake CSS styles into the RSS feed, i.e. replace things like <span style="keyword"> in the main blog pages with things like <span style="color: #ff7700"> in the RSS.

Also wanted: a spam-resistant comments plugin. (Maybe some/all of them are? I was always afraid to try.) And a tags plugin (categories are too limiting). And useful page titles. And a pony.

Update: Laurence Rowe and Alexander Artemenko suggested I check out cssutils. Alexander also pointed out that a similar question was asked on stackoverflow. Peter Bengtsson recently posted a similar tool built with lxml and regexps. Meanwhile, I took the plunge and installed a comments plugin, and even somehow managed not to get drowned in spam.

I think I'm going to blog about Ubuntu bugs I encounter during my day. Don't get me wrong—I love Ubuntu and haven't seen a better OS yet. But it has bugs.

Why blog and not report them to Launchpad? Many reasons: producing good bug reports is hard work; bugs rarely show up alone, and if I start filing one, I'll forget details about the others; sometimes it's unclear whether something is or is not a bug until you've written it down and looked at it; Launchpad is slow while previewing a blog post on the local machine is fast.

This is one of those long and rambling posts that you can skip without feeling guilty. ;-)

Things I did today:

1. I enabled my dual-head screen and had to restart compiz to avoid bug 317431.
2. After work I tried to switch to single-screen mode again and X promptly crashed—bug 298226.
3. When X restarted it picked a fugly stretched 1024x768 mode that looks very bad on my 1280x800 widescreen panel—because this was the only common mode between the internal panel and the external 1280x1024 LCD.
4. I used Ctrl+Alt+Backspace after pulling the VGA cable as a quick way to restart GDM with a saner resolution. I wonder what I'll do in Jaunty where Ctrl+Alt+Backspace is disabled by default. (BTW I agree with that decision, having accidentally pressed Ctrl+Alt+Backspace on several painful occasions.)
5. I suspended my laptop and put it in my backpack, then went home.
6. At home I tried to resume. The laptop suspended again immediately after waking up.
7. When I woke it up again, it did not accept my fingerprint (this often happens, I don't particularly mind—it's difficult to swipe the finger precisely).
8. I then typed my password, pressed Enter—and then gnome-screensaver spent an unreasonably long time verifying my password (this I do mind).
9. While it was verifying the password suddenly the GNOME panel showed up on top of the gnome-screensaver, with two new notification bubbles: one was the usual post-upgrade reboot required, and the other was a typical post-upgrade informational notice (one about refreshing ALSA configuration presets—I haven't seen it before). The interesting thing is that I don't remember running apt-get upgrade today, and /var/log/dpkg.log confirms I last upgraded things yesterday at noon.
10. I could not take a screenshot of the bizarreness described in step 3, but that's reasonable—the desktop was still locked. So I took a (crappy) picture with my cell phone (and now I'm too lazy to upload it—but I have proof! proof!).
11. After 30 seconds or so gnome-screensaver finally timed out, the GNOME panel disappeared, and I got a new fresh screensaver unlock dialog. This time it worked.
12. Just after unlocking the screen I saw a GNOME keyring prompting for my keyring password to enable Network Manager to get the WPA passphrase needed to log in.
13. It's the same as my login password. Shouldn't some PAM magic I recently read about in Ubuntu mailing lists unlock that keyring for me automatically on login? Oh, right, I log in using my fingerprint, not my password. Darn.

Now I feel like I should report item #3 (and #13) as a wishlist, item #6 as a bug (there's probably one open, with a bunch of duplicates, already), #8 as a bug (but that would be useless—I've no recipe for replicating that), #9 as a bug (again, how can I replicate?)—or, rather two bugs (why did the informational notices got delayed by a day?). Maybe three bugs: the untitled (four bugs!) window with the update information says

Refresh Advanced Linux Sound Architecture (ALSA) configuration presets

New Advanced Linux Sound Architecture (ALSA) configuration presets have been added. Please execute the asoundconf(1) set-default-card macro in a Terminal now to refresh your user's configuration presets. You may accomplish this task by executing the following command in a Terminal: asoundconf set-default-card

which reads like gibberish to any nontechnical person (and many technical persons too, I think).

Let's talk more about this notification: the first thought that comes into the mind of a technical person is: if you know what command I should run in a terminal, why don't you run it yourself, you stupid machine? The answer is “because that's not the complete command that you need to run”:

$ asoundconf set-default-card
You have omitted a necessary parameter.  Please see the
output from `asoundconf list`, and use one of those sound
card(s) as the parameter.

Okay, I'll bite

$ asoundconf list
Names of available sound cards:
Intel

There's only one card. Why isn't it selected as default automatically, without forcing me to jump through hoops in a terminal? Think of the children (or, better, your mother)!

But now I remember that Pulseaudio is supposed to be the default ALSA card. What will happen if I select Intel here? Will it break Pulseaudio? Oh dear, I've no idea. I'm afraid to do anything now.

I think I will put on my regular-user-glasses and look at that dialog again:

Technobabble technobabble

gibberish gibberish gibberish

Okay, I hit the only button available—close. I'm done here. Sound appears to continue to work fine without me doing anything. Why was that dialog necessary? Just get rid of it.

I'm sorry. I did not intend this to become a rant. I wanted to make a list of reportable bugs that I could review later and file properly (or have helpful people look up and send me via email—this has happened before, and I was surprised and grateful).

Fennec, the mobile version of Firefox, released a new version (beta 1) for the Nokia N8x0 Internet Tablets recently. Here are my first impressions after about 15 minutes of use:

• It supports the virtual on-screen keyboard now, so would be actually usable on the N800.
• Panning the page is very fast! Unfortunately, opening pages is very slow.
• It eats a lot of memory rather quickly and bogs down when the system starts swapping.
• The user interface is going to be awesome, once the speed and memory problems are fixed.
• Going back in history is cumbersome when you have to pan to the side of the page. The hardware back button doesn't seem to work.
• It has a nice large icon, but there's no small version, and this makes the application organizer in the control panel look weird.

JFFS2, which is the file system used for internal flash memory on NITs, compresses all data, which makes free space comparisons weird. I had 5 megs free, freed up 20 more, then installed Fennec (which, the Aplication Manager assured me, required 10 megs) and ended up with 5 megs free.

I'd include a screenshot, but ad-hoc wifi doesn't work between my Thinkpad and my N810 for some reason.

Last night I thought it would be fun to try to suspend my laptop with the 3G USB modem still plugged in and connected. This morning when I woke it up I had no keyboard.

Ctrl+Alt+F1 worked to switch to a text console (when I pressed it twice). The text console wasn't garbled, which was nice. killall gnome-settings-daemon or gnome-screensaver didn't fix anything. Suspending and resuming again didn't fix things either (not that there's any reason why it should). When I noticed that Ctrl+Alt+Backspace didn't work in X, I realized this wasn't an X grab issue.

/var/log/Xorg.0.log has a series of errors like this:

(EE) AT Translated Set 2 keyboard: Device has changed - disabling.
(WW) AT Translated Set 2 keyboard: Release failed (Invalid argument)

Sadly, there are no timestamps. I think this was printed once on resume, and then once on every VT switch.

xinput still lists "AT Translated Set 2 Keyboard" among its devices.

I remember now -- before suspending I had used sudo showkeys -s in an xterm (trying to see the scan code of the ThinkVantage button). Could've mucked up the keyboard mode?

Alt+SysRq+R (raw mode) didn't help, even when followed by more VT switches. I think I'm gonna restart the X server. Or reboot the whole PC, Ubuntu notifier is showing its reboot icon again...

Meta: I wrote this post on March 6, and then decided it wasn't interesting enough to post. And then posted it accidentally on March 20.

Update: looks like bug 327175.