Migrating MoinMoin 1.5.3 -> 1.9.3

How to migrate from moinmoin 1.5.3 (ie. old debian) to 1.9.3 (ie. new debian).

1) If you're using a farmconfig, in your wikis section if you have

"wikiname", "^wikiname.example.com/.*"

change it to

"wikiname", "^(http://)?wikiname.example.com/.*"

This makes the upgrade code match correctly (it incorrectly adds an http prefix to the url, despite saying it's not going to do so).

2) Update your underlay by going to your wiki's dir and doing:

rm -rf underlay
(cd /usr/share/moin ; tar cf - underlay | (cd /your/wiki/dir ; tar xf - ))

3) Provide metadata so the migration system can work. Go into your wiki's data/ dir and do

echo "data_format_revision: 1050300" >meta

4) Finally, run the migration by doing:

python2.5 /var/lib/python-support/python2.5/MoinMoin/script/moin.py --config-dir=/etc/moin --wiki-url=http://wikiname.example.com/ migration data

and then follow the directions it gives you. Note that after you rename rename1.txt to rename2.txt, the next step can take several minutes.

Worked for me, but YMMV.

How to explain Git's Index to a Subversion/CVS/Mercurial/etc user

One thing about git that consistently seems to puzzle or scare off new users is the index. I, in turn, am puzzled at this puzzlement, because every version control system I've ever heard of has something similar... it's just implicit and therefore not as easy to deal with. In CVS or Subversion, when you do an 'add'... what are you adding that new file to? It's not checked in yet (you haven't done a commit). The answer is the implicit index I was talking about. Take that minor little feature and expand it. Note the minor inconsistency that if you were to add a file and then change or delete it, the state gets.. inconsistent. To solve this, and add more functionality in the bargain, what if when you do an add, the system were to store the file _at the time you did the add_ and be ready to commit *that* version when you did the commit? That way it's always exactly clear what is going to happen when you do a commit, and also since all modifications have to be re-added, you've got a nice way to separate out changes in the working copy you want committed from those you don't.

Python debugging trick

A personal project of mine is in python and littered with some heavy debugging statements. 'Heavy' as in there are many of them, and even more so in that they're costly to execute. My debugging method was:

def noop(*args):
pass

def debug(string):
print("##DEBUG >>> {0}".format(string))

debug=noop

def foo(...):
...
debug("blah blah " + repr(baz))
...

Debugging is then enabled by commenting out the debug=noop line, or disabled by uncommenting it.
The downside is that the repr() is executed whether or not debugging is enabled; so if they turn out to be large or expensive to calculate, they hurt performance in all cases.

In the car on the way to lunch today with a colleague, I was bemoaning this state of affairs and wishing python had some kind of macros. His suggested solution was to eval a string; my mildly better counterproposal was to use python's excuse for a closure:

def noop(*args):
pass

def debug(stringfunc):
for line in stringfunc():
print("##DEBUG >>> {0}".format(line))

debug=noop

def foo(...):
...
debug(lambda : "blah blah " + repr(baz))
...

This saves the evaluation of the repr() until the lambda is eval'd... which may be never. The more conventional way of doing this is:

DEBUG=false

def debug(string):
print("##DEBUG >>> {0}".format(string))

def foo(...):
...
if DEBUG: debug("blah blah" + repr(baz))
...

which always seemed much more... redundant, I guess... to me. Either one is a solution to the problem of extra debug overhead, however.

Must-have Thunderbird Addons

Since I've got a G1 that syncs between it and Google Contacts, I figured I should have Thunderbird sync too, which apparently means Zindus.

And IWBNI more messaging was in one place, so SamePlace means I don't need to fire up Pidgin as well as Thunderbird.

And finally, most of what I do is file stuff as 'done', so Archive This will save me a bunch of mouse-time.

Dear Lazyweb, here's an idea:

Talking to some friends about wanting safer logins, it seems that a cellphone with a camera could be a good challenge/response device, like so:

1) sit down to log into your desktop as normal
2) enter your username
- the response is a 2D barcode 'challenge' with an entry field for the response
3) use your cellphone to take a picture or 'scan' in the barcode.
- cellphone generates the correct response (presumably your key is in the cellphone software already)
4) type in the code that your cellphone generates as the response

Kind of like OPIE stuff or those RSA keyfobs, but slightly more general since the above is mostly an I/O method and says nothing about the encryption used.

Free of the FreeRunner

I've given up on trying to use the FreeRunner as an "every-day phone". There aren't enough buttons to support Android properly. Suspect/Resume support (vital on a power-limited device like a cellphone!) was always touchy. It was just all a bit too unfriendly.

So I bought a G1 from a friend-of-a-friend for cheap and unlocked it to work on my current provider. It's been fun! ConnectBot gives me an 80x22 ssh session anywhere - that's only 3 lines from the size of the standard PC text console that I spent so many of my teenage years in front of. The dev environment is open enough that I experimented with writing my own game - a falling-blocks game called Polyfallminoes. Contacts sync with google, the browser is fine to read ebooks on (I read html ebooks that I buy from webscriptions.net and host on my own server), and in general it acts like a nice polished platform. Not that things aren't missing, because they are... but I'm going to see what I can do about fixing that :)

Android

I've gotten more and more interested in Android lately. My FreeRunner is running it thanks to a guy named panicking. I've got an app in the App Store... er, pardon me, 'Android Market' for it. And I think in general it's a Good Thing.

Silence...

should not be construed as satisfaction. Okay, well not as Complete satisfaction. My current Qtopia 4.3.2 install has been working fairly well for the past few months (modulo the re-registration bug), but there's still a ways to go before I'm truly ecstatic with the phone. I'm much heartened by Android's release and rapid progress on the GTA02 platform, as well as by Openmoko's new dedication to working on fixing the fundamental functionality first.

But my old 4.3.2 distro is getting a bit long in the tooth, so I'm likely going to try 4.4.1, and maybe FDOM, soon.

Corruption details

fso and qtopia are both showing microSD (ext2) corruption:
fso while running a kernel with build date of 'Thu Aug 7 15:57:11 CST 2008'.
qtopia while running one built 'Sun Aug 3 16:16:27 CDT 2008'
'
Upgraded fso to one with built 'Sat Aug 16 16:34:47 CEST 2008' and I couldn't repro the corruption. Yay! Fixed for now.

microSD data corruption

In trying to get an FSO-daily on my microSD card, I discovered some microSD corruption: I copied a 35MB file over USB via scp straight to the micro SD card... and it was bogus. So I copied it instead to /tmp, which is on a ramdisk - and it worked fine. So to verify, I then tried to copy the file from /tmp to the micro SD card via 'cp'... and it was again bogus. So there's some corruption hiding there. This is with qtopia 4.3.2 rootfs and kernel.