Add --no-check-certificate to the wget call in logBugDataP4.pl

The Waffle

On the recommendation of Kirby, I’ve been trying out FogBugz for task and bug tracking. I’d dismissed FogBugz assuming the cost would be too much (and for the daft name), but, amazingly, it has a free startup edition – good for 2 users. (One of the most interesting features is the Evidence Based Scheduling i.e using historical metrics for better estimates. I’ll be very interested to see how it works out.)

FogBugz integrates with a number of SCM packages. In my case I’m also running the free 2-user Perforce install, and of course wanted to link the two. (I’ll get around to SVN and Git too but for now it looks like I’ll have to sort myself out for integration with AccuRev).

For Mac OS X, FogBugz has a Perl script (logBugDataP4.pl) which scans your changelist description for lines like:

BugzIDs: 1234


This allows FogBugz to link back to the Perforce changelist (if you’re running P4Web). By default though, the script appears to fail when issuing the wget.

The answer is to add –no-check-certificate to the wget calls, so that:

system("wget '$url' -q -O /dev/null");

becomes

system("wget '$url' -q -O /dev/null --no-check-certificate");

In my version I’ve removed the -q and the /dev/null preferring to dump the output and logging to files, so I can see what’s going on.

(There are two calls around lines 134 and 165.)

The articles are:

• Dealing with new-gen – I didn’t want to use the word “next-gen”, but I’ve ended up with something that sounds worse! Inspired by the launch of the PS3.
• Losing Control – ramblings about control devices, inspired by the launch of the Wii.
• Private Brancher – pun based title for an article about private workspaces in Perforce.
• Troublesome enums – I’m no C++ mastermind, but here I talk about enums in C++. Hopefully it’s correct

The articles are pretty much in the form they were in the magazine, but with some errors removed.

One of the more important things I’ve been wanting to do, is to set up a perforce proxy to connect to the work server.

That way, it can sit in the background periodically updating itself (not quite but see below), and when I want to sync, it should be nice and fast. In theory. In reality I suspect it won’t be so clear cut.

Running a perforce proxy is easy, it’s just a case of choosing a root for the cache, telling it what port to listen on, and what the target server is:

p4p -p 1667 -t workserver:1666 -r /perforce/p4p/cache -L /perforce/p4p/p4p.log

That’s nice, but I want this to start automatically when I boot up, and an easy way to quickly stop and start it. I need a script in /etc/init.d. Here’s mine:

#! /bin/sh
# p4pinit
# Startup script for Perforce Proxy server.
# Check out the man page for start-stop-daemon. Notice
# I use -b to run p4p in the background. p4p has a similar
# option, but I didn't have as much success.

DAEMON=/usr/local/bin/p4p
P4P_NAME=p4p
P4P_DESC="Perforce Proxy"
P4P_CACHE=/perforce/p4p/cache
P4P_PORT=1667
P4P_TARGET=workserver.somewhere.co.uk:1666
P4P_LOG=/perforce/p4p/p4p.log

# Check p4p exists
test -x $DAEMON || exit 0

case "$1" in

  start)
	echo -n "Starting $P4P_DESC: "
	start-stop-daemon --start -b -m
                --pidfile /var/run/$P4P_NAME.pid
                --exec $DAEMON
                -- -p $P4P_PORT -t $P4P_TARGET
                -r $P4P_CACHE -L $P4P_LOG
	echo "$P4P_NAME."
	;;

  stop)
	echo -n "Stopping $P4P_DESC: "
	start-stop-daemon --stop
                --pidfile /var/run/$P4P_NAME.pid
                --signal KILL
                --exec $DAEMON
                --oknodo
	echo "$P4P_NAME."
	;;

  *)
	echo "Usage: $0 {start|stop}"
	exit 1
	;;
esac

exit 0

Once you’ve done this, you need to call update-rc.d p4pinit defaults. This will ensure that p4p is started when you boot up. This will create symlinks to p4pinit in the directories /etc/rcX.d etc…

Now synching is just a case of pointing the client at homeserver:1667, rather than the default However, you need to pre-load the cache and ideally keep it synched regularly after that.

Unfortunately this is where Perforce falls down, as the proxy has no means to do this itself; You’re required to set up another client spec, and use that to sync and fill the proxy’s cache. This could mean double the files on your server, which isn’t great.

What you can do, rather cunningly, is set your client root to /dev/null. When you sync you’ll get errors that it can’t write the file/create the directory, but by that point the file has been downloaded to the cache. To quote Tim O’Mahony of Perforce support:

…The errors mean that you can’t write anything to db.have for those files, but by this time you already have downloaded them to the proxy. That means that every time you then run a p4 sync on this client it is the same as running a full “p4 sync”. Files that aren’t on the proxy will simply be got from the server…

In other words, if you sync later, p4 will want to re-grab those files. However it will take them from the proxy, so it will only download genuinely new files. If you don’t want the output in your logs (like me), then you can run p4 flush immediately after the sync, to convince the server that you really do have those files:

p4 sync //depot/something/to/sync/...
p4 flush //depot/something/to/sync/...

Hope this helps someone.