I found this sign on the day after National Punctuation Day. You can still see the residue from the adhesive where the extra apostrophe was attached.

Someone clearly got Starbucks Coffee confused with Starbuck’s coffee. Of course, in some cases, they could be the same thing:

Flickr photo by amidalasrogue

In this case, it was a digital camera problem. Since we bought our Canon PowerShot SD600 last December, I’ve used KDE’s digiKam to transfer and manage the photos. DigiKam detected the camera and accessed the photos right out of the box, no configuration needed beyond telling it to remember the model. But something changed in the last two weeks, and last night I started getting an error message: Failed to connect to the camera. Oddly enough, it could still detect the camera when it was connected. But it couldn’t display or download the images.

I searched all over, hitting dead end after dead end, until I got a hint that it was a permissions problem. That’s when I hit the command line to start troubleshooting.

Digikam uses a library called gphoto2 to access cameras. It has utilities that you can run from the command line for testing. I ran gphoto2 --auto-detect, which dutifully reported the correct camera. I ran gphoto2 -l to list the folders on the camera, and it spit out an error including the phrase: Could not claim the USB device. The interesting thing was, if I ran the same command as root, it was able to see the folders.

Way back when, Linux used a static list of devices in /dev. Now that everyone is constantly connecting and disconnecting devices with USB, Firewire, Bluetooth etc., that’s not practical. Most modern Linux distributions use one method or another to dynamically build that list from what’s actually connected to the computer, and react when new devices are plugged in. Fedora 7 uses udev to identify and configure devices. I had to figure out how to tell udev to give me write access.

I finally found the gphoto documentation on setting permissions, and found the command I needed: print-camera-list, which will build a list of rules for udev to use when someone attaches a camera. Unfortunately, the directions were slightly out of date. Instead of adding a “version 0.98″ option, it wanted “udev-rules-0.98″.

So the command I used (as root) was this:

/usr/lib/libgphoto2/print-camera-list udev-rules-0.98 group users mode 0660 > /etc/udev/rules.d/90-libgphoto2.rules

Note that where it says “users” you should substitute the name of the group your account belongs to. (In Fedora, that might actually be the same name as your username, since it likes to create a group just for you.)

It took me about an hour to track this down, since initial searches sent me looking in the wrong direction. I’m hoping this blog post will save someone else a little time and frustration.

Update (June 2008)

I’ve run into a different problem with Fedora 9. In this case, I’m running digiKam under the GNOME desktop. GNOME can mount the camera now, so it auto-mounts and pops up a filesystem window. But when I try to access the camera in digiKam, I get the same error message about not being able to connect.

It turns out this one’s just a conflict: either the virtual filesystem or digiKam can access the camera, but not both at once. I just right-clicked on the icon on the desktop, unmounted it, and was able to connect in digiKam.

I just checked back and the listing is gone. I figure it was probably a placeholder or something.

This site was built with ColdFusion, and used a then-freely-available library called PDFFormFiller.cfm (I can’t find any sign of it now) to generate the FDF code. After saving the offending FDF to a file (eliminating the browser as a factor), I started manually editing the code to see what happened.

The problem turned out to be parentheses appearing in the form data. FDF uses parentheses-delimited strings, and it was finding ) in the code and trying to parse what was left as FDF tokens. The solution was simple: just escape the parentheses as \( or \).

In this case, I changed this expression:

#Evaluate("VarStruct.#VarName#")#

to

#ReplaceList(Evaluate("VarStruct.#VarName#"),"(,)","\(,\)")#

I don’t know whether older versions of Acrobat Reader were more lenient about this or whether this site just never ran into anyone using parentheses before. Either way, there’s precious little useful information about this problem online. In case anyone else runs into it, this entry should help.

If you get syntax errors in krb5.h while trying to build Apache with mod_ssl, it’s probably because your Linux distribution puts the Kerberos include files in their own subdirectory (Red Hat/Fedora and derivatives do this), and the configure script has somehow missed them.

Solution: Configure mod_ssl and Apache as normal. Then edit the file path_to_apache_source/src/modules/ssl/Makefile. Look for the CFLAGS1 line and add -I/usr/kerberos/include to it.

Then continue with the build as normal.

We now return you to your regularly scheduled blog.

<?php code goes here ?>

On some servers—maybe even your own—you can shorten this to just the opening <?. The following line in php.ini will disable this “feature,” and many web server administrators do so to simplify things like generating XML with PHP:

short_open_tag = Off

When this option is set, PHP will ignore <? and assume it’s simply part of the template… along with all the code following it. If you’re lucky, it means a bunch of PHP code gets sent to the web browser. If you’re not lucky, it results in invalid syntax, and PHP grinds to a halt, spitting out a blank page and a PHP Parse Error.

So please make sure you always use the full opening tag so that your plugin will be compatible with everyone’s system. If you run your own server, set that option in php.ini so that if you miss one, you can catch it before you post it.