There was a big flood at Anna's today. I heard it was going down so I went ahead with my planned visit. In the field across the road, the creek was swollen to a lake at least 200 feet wide. At the ford, the water was only out of the banks of the creek about 30 feet on each side, and I could even see the bridge, but getting to it would have involved swimming.

I went down the road half a mile, past the confluence of the two creeks, where it was very backed up (and nearly up to the road), and explored upstream to where the creek was back within its banks, but still several feet high. Found a tree down and had a thrilling trip over. Then I had to bushwack all the way back upstream to Anna's. The flood reached right up to the hillsides in most places, so lots of scrambling around hills.

Finally, about an hour after arriving, I got in. With feet completly dry.

Then we went around surveying for a couple hours -- when better to survey a near-swamp than when it's in flood. My dry feet -- not dry anymore.

I kinda dreaded getting back out, since the waters were not going down much more. 2/3 of the way out, I hurt my knee slightly, and getting back across the deadfall was even more tricky. Lucy the dog walked across a more precarious tree at the same time, like it was nothing.

Well, that was an adventure! Some day I want to see where this creek goes underground and supposedly passes under the Clinch river to emerge at Sinking spring.

Spent much of this afternoon reducing the number of hard drives I have to keep running. Every computer in the office, except my laptop, is now running from flash or network, and has no moving parts. Nice milestone. Kinda spooky tho. The server closet still has a few dozen drives in it, but one less than yesterday, and only three run full time.

Reading Paul Graham's latest as well as having written a few things today that involved considerable rewriting before I sent them out (this blog entry not^W amoung them!), I'd like the following:

A way, when saving a file in vim, to have it replay the undo buffer in reverse, outputtng whole series of snapshots documenting the changes that were made to the file. And an easy way to commit those snapshots, in order, to git, at the same time the final file is checked in.

This would address that period in the lifecycle of a file when it's too new, its author too busy, and its situation too precarious, for it to be checked in yet. These early stages can be very interesting, and generally go unrecorded.

discussion

These graphs can help give some idea of how the shortened DPL voting period this year changed voting patterns.

Each vote starts on a Sunday (except 2005 which was a day late). Calls for votes are posted again each weekend during the vote, and a final call two days before the end of the vote. These are responsible for most of the spikes on the graph, and the trail off after each CFV is probably due to some people seeing it the next day.

Shortening the voting period seems to have made more people respond to the second and third CFV (both in percentage and absolute number of voters). It's also interesting that a smaller percent than usual of votes were recieved on the last day this year. There seems to not have been a rush to vote on the last day despite the shortened period.

I wonder if posting CFVs more frequently would result in more voters, or if it would just level off the graph?

(Graph produced using this tool and final vote timing logs provided by Manoj.)

I'm still following The Lost Ring, but it got a little too intense today when someone who was not very familiar with what was going on was recruited to pick up an envolope hidden in an umbrella stand at a gallery in Hong Kong became disturbed by the contents and destroyed it. All we're left with is some fuzzy pictures.

This fragment contains a code. If we can figure out enough of the code, it can be used to download a digital copy of the paper that got torn up. It's a kind of checksum, was written with a typewriter (that writes capital letters a bit higher than the rest of the line, and tends to fade bottoms of numbers), and will look something like "SS71/124P/84JH/HFGS/CEAS". After playing with the gimp, I'm fairly sure that the code starts out "C??L/T4GA/L".

In the movies, this is easy, you just zoom in on the blurry picture until you can see fingerprints. In the "real" world, it's gonna be tricky.

We found it: 5474/WAS8/541S/9424/92U6/50MJ

We seem to keep having problems deciding what content to put on Planet Debian. I wonder to what extent this has to do with the software running the planet.

My experience with using ikiwiki to run Planet Debian upstream is that if a particular feed annoys readers, a page can easily be created that omits that feed (or feeds) while keeping everything else. Anyone can do this by creating a new wiki page and putting something like "!feeds/richard_stallman/*" in the PageSpec. So there's no real reason to drop any feeds for excessive or annoying content.

The Planet software makes this harder to do; you have to set up your own server running it, and manually keep your modified feed list up-to-date. So instead there's a general drive to more tightly limit what content is allowed on Planet Debian. The result is that interesting feeds are removed, and that other feeds are self-limited to only technical posts. None of this is making Planet Debian more interesting or useful.

simple case

Imagine a very simple debian/rules, that should work for most packages w/o modification:

#!/usr/bin/make -f
build:
    dh build

clean:
    dh clean

binary-arch:
    dh binary-arch

binary-indep:
    dh binary-indep

binary: build binary-arch binary-indep

absurdly simple case

AKA debian/rules zen guru level.

#!/usr/bin/make -f
%:
    dh $@

the complex cases

Often you'll want to handle configuring by hand. (And maybe, run automake too.)

build:
    dh build --before configure
    #aclocal
    #autoheader
    #automake --add-missing
    #autoconf
    ./configure --kitchen-sink=yes
    dh build --after configure

Here's how to skip two steps in a row (configure and build):

build:
    dh build --before configure
    ./mondoconfig
    make universe-explode-in-delight GROOVINESS=420
    dh build --after build

Another common case is wanting to run some code manually after a particular debhelper command is run.

binary: build
    dh binary --until dh_fixperms
    # dh_fixperms has run, now override it for one program
    chmod 4755 debian/foo/usr/bin/foo
    # and continue
    dh binary

Suppose you hate dh_strip, and just don't want it to run. (This might be a contrived example; if people frequently don't want to run a few commands in a set, it may be better to have -X exclude them.)

binary: build
    dh binary --before dh_strip
    dh binary --after dh_strip

Maybe you want to run a command out of order. This should be no problem:

binary: build
    dh binary --until dh_fixperms
    dh_install foo usr/bin
    dh binary --after dh_fixperms

A separate install target can be added if you like. And maybe you want to run make install by hand in it. (This is tricky because dh binary needs to avoid running dh_auto_install which was skipped over in the install target.)

install: build
    dh install --before install
    $(MAKE) install PREFIX=debian/tmp
    dh install --after install

binary: install
    dh binary

Once you have an install target, you can do this to run some commands manually after the install target runs, and before the remaining steps are run to build a binary.

binary: install
    dh_strip -X foo
    dh_fixperms -X bar
    dh binary --remaining

If the --remaining was left off, dh binary would only run commands in its list after dh_fixperms. With --remaining, it runs commands that haven't run before, avoiding running dh_strip and dh_fixperms again.

A more elaborate way to do the same thing, without needing a separate install target is this.

binary: build
    dh binary --before dh_strip
    dh_strip -X foo
    dh binary --after dh_strip --before dh_fixperms
    dh_fixperms -X bar
    dh binary --after dh_fixperms

the dh_auto_* commands

dh_auto_* are thin wrappers, with enough intelligence to handle 90% of cases (autofoo, perl/python packages, etc) automatically. These will rarely be run by hand, instead if they don't do what is needed, they can just be skipped.

• dh_auto_configure: Figures out how to run autofoo, ./configure, Makefile.PL, or whatever.
• dh_auto_build: runs make
• dh_auto_test: runs make test or the like (may have a config file specifying if test failures should fail the build).
• dh_auto_clean: runs "make clean" etc
• dh_auto_install: runs "make install" or similar

the dh command

dh runs a set of other debhelper commands in order (and prints their names as it does so). The set that it runs is determined by its parameter.

The sets of commands are:

• build: dh_auto_configure, dh_auto_build, dh_auto_test
• clean: dh_testdir, dh_testroot(?), dh_auto_clean, and finally dh_clean.
• install: Everything in the build list, plus dh_installdirs, dh_install, dh_auto_install (and probably dh_install* too)
• binary: Everything in the install list, and all debhelper commands used in binary targets.
• binary-arch: Like binary, but runs commands with -s.
• binary-indep: Like binary, but does not run dh_strip or dh_shlibdeps or dh_makeshlibs, and runs commands with -i.

Possibly dh does smart optimisations to avoid running lesser-used commands if they will do nothing. (Or not.)

Each debhelper command will record when it's successfully run in debian/package.log.debhelper. (Which dh_clean deletes.) So dh can tell which commands have already been run, for which packages, and skip those.

Options passed to dh are passed on to each command it runs, which is useful for common options like -v, -X, and the like. For that matter, you can use it for uncommon options as well, since commands will ignore options that don't apply to them.

dh has a few options of its own:

• --until cmd: Run commands until and including cmd, then stop.
• --before cmd: Run commands before cmd, then stop.
• --after cmd: Run commands that are listed after cmd.
• --remaining: Run all listed commands that have yet to be run.

cmd can be a full name of a debhelper command, or a substring. It'll first search for a command exactly matching the name, to avoid any ambiguity. For example, "--before dh_installdeb" does not refer to dh_installdebconf. Otoh, "--before build" is much easier to type, and clearer, than "--before dh_auto_build". If there are multiple substring matches, the last in the command list is taken. So "--before install" stops before dh_auto_install, and not before the earlier dh_install.

Each time dh is run, it examines the log, and finds the last logged command that is in its list of commands to run. It then continues with the following command in its list. (Or the one after --after, if that was specified. Or if --remaining was specified, start at the first command in the list that is not in the log.)

So...

If you run debian/rules build twice, and it just has "dh build" in it, the second run will be a no-op. The same as if the build target touched a build-stamp. This is generally considered a feature, so I'll consider it a feature in dh too. (To force a rebuild, run dh_clean to remove the log.)

If you run debian/rules binary, and a build hasn't happened yet, it will run the build steps first. Even if the rules file is a bit lame (or over-golfed), and doesn't have the binary target explicitly depend on the build target. Ditto for the install target.

If a rules file runs a command out of order, it'll need to use --after to get dh back on track.

If you manually run a debhelper command at the command line, running debian/rules binary will skip forward until after that command. Similarly, if debian/rules binary is interrupted (or fails), running it again will resume after the last debhelper command run. This is a bit of a behavior change, and could be considered a bug, but is easy enough to work around by running debian/rules clean binary. (Or by manually deleting the log.)

I've implemented last night's design, in debhelper 7.0.0.

Currently fully supported are packages that use the autotools, or perl's MakeMaker, or python setup.py, or a simple Makefile. The other classes of packages will be added as bugs are filed about them.

I've uploaded a few of my own packages converted to use debhelper 7 with minimised rules files, so there are a range of examples in incoming:

• mr uses a very simple makefile, and a 3 line debian/rules
• aalib uses automake and autoconf, and is a library package of average complexity. The rules file is minimised where possible using dh, but still does complex things in its build and install targets. It's also a good example of how to set up a -dbg package when using dh, and of how to set up /usr/share/doc symlinks between packages when using dh.
• libaudio-mpd-perl is an example of a perl module package using dh. It shows how to override dh default behavior in two ways: Skipping running dh_auto_test, and passing a changelog filename to dh_installchangelogs.

Early adopters, have at it!

discussion

The Bandwidth of Code:

Hell is Other People's Code is, perhaps, another way of saying that code is a terrible way to communicate with other human beings. Foreign code inspires a mixture of apprehension, anger and anxiety precisely because the bandwidth capacity of written code is so horrifying small. Enormous amounts of context, nuance, philosophy, history -- in short, knowledge -- is lost forever each time we try to translate our ideas and desires into program code. And this tremendous loss of knowledge looks to be unavoidable.

Since even Knuth has given up on literate programming as a general solution to this kind of problem, let me throw another possibility out there: Version control. It's not perfect, but you can get into someone's head by reading their mistakes and false tries in their version control history.

This is why rebasing is bad. But also why it appeals to so many developers, who have no desire to let you inside their head.

Steve Yegge

Steve is very quotable. From Xemacs is dead, Long live Xemacs:

XEmacs should drop out of the race

At this point it's becoming painful to watch. GNU Emacs is getting all the superdelegates. That warmonger VIM is sitting back and laughing at us. But XEmacs just won't quit!

And has some deep insights into the mind of an emacs user. From the Pinocchio Problem:

Viewed from a radical, yet possibly defensible perspective, a reboot is a murder.

And some things that ring true (or at least provide another excuse for not learning haskell properly). Also from the Pinocchio Problem:

There's nothing wrong with static type systems. You just have to realize that when you use them, you're building hardware, not software.

Best of all they're in these enormous long blog-rants of chapter length that discuss a topic in depth, then go out the other side. Great fun, even if you disagree with him.

sad end

SFGate reports:

Reiser is guilty of first-degree murder, the jury has found.

He killed Nina with premeditation and deliberation and now faces 25 years to life in prison.

Pressed to elaborate, Du Bois said, "I'm sure he negatively impressed the jurors."

Hans also mostly negatively impressed me the one time I met him (and the one time I emailed him). And the whole business of hiring Russian programmers to slave away at a filesystem with your name on it has always struck me as shady and disenfranchising.

But, after reading Rick's excellent summaries of every day of the trial, I still have no idea if Reiser killed his wife, and indeed no clue if she's dead at all, or instead back in Russia with the children.

discussion

Here's a nice toy I added to mpdtoys this evening. vipl allows editing mpd's playlist in a standard text editor. Reorder or delete songs, etc. Enter ">" in front of the song you want to play. Type in partial song, album, or artist names and it will expand them to any matches.

:wq to start the music playing.