Running Perforce on FreeBSD 10

Yesterday I updated our company server to FreeBSD 10. It went pretty well with only a few glitches: had to remove libiconv (documented in UPDATING) and some of the ports (such as Perl 5.16) needed manual recompilation as portupgrade failed on them.

But I quickly discovered that Perforce does not work – attempting to start the server produces the error message:

Shared object "" not found, required by "p4d"

The reason is that FreeBSD 10 includes a new C++ stack and gcc, including libstdc++, is not installed by default.

So the problem is easy to fix: install lang/gcc from ports. This will bring back libstdc++ and Perforce will run smoothly again.

Update 4/23/2014: Perforce version 2014.1 has a FreeBSD 10 specific build, which does not depend on libstdc++.

hdiutil Requires sudo for Read/Write

Another unwelcome surprise from Apple: in some recent OS X update (I don’t know exactly which one as I ran into the problem this morning) they changed how hdiutil behaves when mounting sparsebundles in read/write mode (it is used in my build scripts as a step toward generating the final setup DMG): it now requires sudo-ing when you use the -readwrite flag.

The problem is that sudo by default prompts for a password and silently fails when used from a script. The solution is to remove that password requirement. This is carried out by adding a line to the /etc/sudoers file:

%admin ALL=(ALL) NOPASSWD: /usr/bin/hdiutil

This innocent one-line edit requires lots of command-line gymnastics, however. Permissions on the sudoers file is 440 by default, and the sudo command fails to work with anything other that that.

So you have to boot your Mac in single user mode to do the edit (by holding down Command+S at startup). Then you have to mount the root file system in read-write mode and change the permissions on the file:

mount -o update /
cd /etc
chmod 640 sudoers
vim sudoers

Add the line to the end of the file, save it and restore the file’s permissions:

chmod 440 sudoers

You can now reboot, and sudo hdiutil will not ask for a password any more! So it can be safely used from within build scripts.

Hibernate File Issue with MacBook 2012 Update

Seems that the list of annoyances I have to deal with after each and every OS X update just grown a bit. Besides the usual

chflags nohidden ~/Library

command that unhides the Library folder, now I have to do some extra work to reclaim the space normally occupied by the hibernate file (/var/vm/sleepimage). I do not use hibernation on my notebooks. I shut them down when I finished. I prefer to start with clean state on every boot, but equally I’m not fond of wasting 17 gigabytes of expensive SSD space on a file that I never use.

In the past you could turn off hibernation with

sudo pmset -a hibernatemode 0
sudo rm /var/vm/sleepimage

But after today’s release of “Update 2.0 for all Mac notebooks introduced in June 2012”, I had to do some extra work. The issue is: regardless of the state of the hibernatemode switch, the hibernate file (stored in /var/vm/sleepimage) is recreated on every boot. Bummer.

Fortunately you can also set the location of the file, so all I had to do is to send it into a black hole:

sudo pmset -a hibernatefile /dev/null

Everything works fine with this setup, but I fear that the next update could bring some more surprises…

Backing up Lightroom with ChronoSync

ChornoSync is what I use on my Mac for backing up user data – including my images. Although I don’t use Lightroom nowadays as much as I used to, backing up the database is important. There’s one gotcha, however. Preview images are stored in something called a bundle. A bundle is a directory that OS X handles as a single entity. For the catalog named Something.lrcat the preview bundle is named Something Previews.lrdata. So if one single preview image is changed, OS X thinks that the bundle is changed and ChronoSync happily copies the entire multi-hundred-megabyte conglomerate, not just the changed (or new) previews.

There’s a simple solution to this issue, shown on the image below.

Check the Dissect packages checkbox on the Options tab, and the Previews bundle will be treated as a regular directory, and ChronoSync will just synchronize newly added or changed previews.