miniupnpd stale EXTIP

Miniupnpd comes with the script, which among other things adds an iptables rule:

#adding the rule to MINIUPNPD

Unfortunately, this rule isn’t replaced when the connection is dropped (and the router gets a new dynamic IP). OpenWRT does have a hotplug script:

[ "$ACTION" = "ifup" -a "$INTERFACE" = "wan" ] && \
/etc/init.d/miniupnpd enabled && \
/etc/init.d/miniupnpd restart

Problem here is that /etc/init.d/miniupnpd enabled returns false! It’s a function defined in /etc/rc.common that checks for /etc/rc.d/S95miniupnpd. So the solution is:

ln -s /etc/init.d/miniupnpd ./S95miniupnpd

Realistically, the ipkg should come with this file (effectively enabling miniupnpd by default). A more robust solution would be to modify the hotplug script so that it restarts the daemon without the enabled check, and rely on the restart function not to start the daemon if it wasn’t already running.

PHP array references

Hit this one at work, where we use RHEL4’s PHP 4.3.9.

The online documentation doesn’t mention it any more, but there’s a history of PHP not dealing well with array references.

PHP segfaults. Unfortunately it’s quite hard to reproduce artificially; we don’t see the segfault until way after the reference was taken (presumably after the GC has done its rounds). It’s 100% reproducible in our program, but I’m still working on a minimal test case.

iTerm+blur: updated; thanks git

Update: The patch has been merged into upstream CVS. Yay!

I’ve merged the current CVS HEAD (sub-minor version 0821 apparently) of iTerm with my +blur branch. You can download the new binary.

In doing so, I found that there’s a new maintainer, James Bunton, responsible for most of the changes. He’s got a mercurial tree, but it’s not up to date with sourceforge CVS. Welcome to distributed VC hell, where CVS is being used as a central repository between patchset-based DVCs. There are some importers, but if the canonical repository is CVS, importing from the mercurial tree is strictly more work (since I’d still need to import the CVS updates, and merge again).

cvsps and git-cvsimport do a good job of making working with cvs repositories from git reasonably painless. But I had some issues.

Perhaps it was just me failing, but I couldn’t coax git-cvsimport to import into my remotes (yes, using -r). Also it would be nice if git pull could figure out a remote was CVS and run git-cvsimport for me, using cached parameters. As it is, I have one repository for running git-cvsimport, and my working repository that pulls from that.

Git seems remarkably unhelpful when it comes time to do manual merging. An “ours”-type strategy for hunks consisting of just CVS $Id$ keywords would be nice. Why isn’t there a simple comand to run a 3-way merge with an arbitrary merge(1)-compatible invocation? I discovered smartmerge too late, but surely manual merges are common enough that getting 3 temporary files together could be done in one base command?

There’s a persistent feeling when using git that I’m doing it wrong, or at least there’s an easier way if only I could remember the command. I ran git status |grep unmerged because I couldn’t remember that I wanted git ls-files -u. I have to re-read git-rebase’s documentation every time I use it.

Update: the ident attribute deals neatly with CVS $Id$ keywords.
Update: the git mergetool command can be used instead of smartmerge.