I tested it in a couple of browsers, both on my Linux desktop and on the Mac laptop, and planned to test it on the Windows desktop when Katie was done with it. But then something weird started happening.

Firefox started crashing. Repeatedly. Not quite predictably, but only when that test page was open.

I figured maybe it was a corrupted font, so I removed one, then the other, then both. If the page tried to download an embedded font, Firefox would eventually crash. If not, it was rock solid.

This seemed kind of bizarre for such a high-profile new feature to cause consistent crashing.

I did some searches online but didn’t come up with anything until I tried running Firefox from the command-line, so that I could read the error message. It complained, "firefox: cairo-ft-font.c:554: _cairo_ft_unscaled_font_lock_face: Assertion `!unscaled->from_face' failed." Searching for that led me to Fedora bug 509501 and bug 502274, and this blog entry.

To make a long story short:

• On Linux, Firefox uses a library called cairo to handle graphics, including fonts.
• An old version of cairo had a bug that would cause crashes with fonts under certain circumstances.
• Cairo fixed the bug in December.
• Fedora 11 is still using the old version of cairo.

So until Fedora ships a newer (or at least patched) version of cairo, my primary browser on my primary desktop will crash on any web page with an embedded font.

Nice.

I guess I could patch my own system for now and put the fonts up for the benefit of the rest of the Firefox+Safari+Opera-using audience on Windows and Macs (and probably other Linux distributions). But that means causing a crash for anyone else running Fedora 11 when they visit my site. I’m not too thrilled about that idea. I have no problem with adding enhancements that only appear under certain browser+os combinations, but actively crashing a browser? Not something I want to do.

Update (July 21): Aha! Fedora submitted an updated cairo for inclusion in the stable release last night!

• Brian Fuller talks about the future of Pushing Daisies #
• WaMu building has taken down its sign. Giant Chase banner at street level. #
• Guy w/ sign by side of road: “Homeless kind soul stuck in vortex.” I get the 1st half, but WTF does “stuck in vortex” mean? Downward spiral? #
• Retweeting @ThisIsTrue: possible cause identified for honey bee colony collapse #
• Odd: If Ubuntu is the biggest desktop Linux out there, why is my torrent for 8.10 64bit idle? Fedora 10 64bit found 7 peers in 30 seconds. #

Bathysphere was only 8 votes behind. Weird, but considerably cooler.

Oh, well. At least it’s not Mayonnaise or Chupacabra. And some of the other names on that list are considerably worse.

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.

Just for fun, I did some searches for her name. Mostly I came up with cars, horses, wax and, of course, booze. And an alpaca. Back to the booze, there was one point at which the character was mistakenly identified as as Moonshine (later explained away as an in-world mix-up, which would have made more sense if she hadn’t been the one calling herself the wrong name!)

Now the funny thing: the “…in pop culture” section in Wikipedia’s article on Moonshine reminded me that Fedora 7, which just came out last week and which I installed at work a few days ago, is codenamed Moonshine.

The only way the timing could have been more appropriate would be if I’d written the character bio the same day as the Linux release.

I upgraded a system with a Permedia 2 video card, which uses the glint drivers. The installer couldn’t launch the GUI, but I’ve run into that fairly often, so I just used the text-based installer without thinking much of it. The upgrade process itself went fine, but on booting into the new system, it was unable to launch X. I kept getting the following error:

X: symbol lookup error: /usr/lib/xorg/modules/drivers//glint_drv.so: undefined
symbol: RamDacCreateInfoRec

I found a reference to the problem occurring in Debian, as Debian bug #423129, then followed that to Freedesktop.org bug 10906, which has been fixed. It turns out that the xorg X server moved some features from a pluggable module into the server itself, but didn’t keep them available for drivers that use them. I tested the patch with the X server SRPM from Fedora, and was able to run the system in graphics mode again.

Then I checked Fedora’s bug database, and found Red Hat bug 242800, filed just yesterday. I confirmed that I had the same problem, pointed them at the upstream bug, and reported that the fix worked for me.

For those who are comfortable with modifying and building SRPMs, you can grab xorg-x11-server-1.3.0.0-5.fc7.src.rpm from any Fedora mirror, then add the patch from that Freedesktop.org bug report to the SPEC file. That will give you a set of RPMs that will work with the card. (If you don’t know what I’m talking about, you’re probably better off waiting until Fedora has a chance to test the fix and issue an update, but if you want to learn, check out the RPM Guide, particularly chapters 8 and 9.)

Update (June 7): A fixed version, xorg-x11-server-Xorg-1.3.0.0-8.fc7 has hit the testing repository.

Update (June 11): The fix has been released, so all you have to do is install/upgrade in text mode and run yum update after you’re done.

There are two main issues: making Mozilla’s Firefox installer work everywhere (it mostly does, but on some systems you need to install some compatibility libraries first), and keeping the distributions’ versions in sync with the official one.

After the Debian IceWeasel debacle, and Fedora deciding to skip Firefox 2 and wait for Firefox 3, it’s good to know that Mozilla has recognized the problem and is working on it. One key piece of information: Red Hat and Novell will both be providing extended support for Firefox 1.5 past its official EOL next April.

(via Fedora Weekly News)

I’ve run into a couple of gotchas, among them the fact that text is missing in Flash animations. I messed with my font settings, checked SELinux logs, tried switching from the binary installer to the RPM package, to no avail. I tracked down a Fedora mailing list post that pointed to a mozilla bug that had been languishing for a few months, then added what I knew—which was that it affected Flash regardless of the browser.

On Sunday, commenter Dawid Gajownik tracked down the problem: Flash hard-codes the paths where it looks for fonts, instead of letting the X server tell it where to look. Fedora Core 5 includes a new X server, which no longer puts things in /usr/X11R6. Apparently symlinking the old font paths to the new ones works around the problem:

[root@X ~]# mkdir -p /usr/X11R6/lib/X11
[root@X ~]# cd /usr/X11R6/lib/X11
[root@X X11]# ln -s ../../../../etc/X11/fs
[root@X X11]# ln -s ../../../share/X11/fonts

I tried it with absolute links (to /etc/X11/fs and /usr/share/X11/fonts) instead of relative, and it worked fine.

Also, if SELinux is in enforcing mode, you need to allow text relocations on the Flash library. More info on that in Dawid’s bugzilla comment.

So this should take care of Flash until Macrodobe releases an updated version. They’re apparently heading straight for 8.5 on Linux, which is why they haven’t released Flash 8.0 yet.

*Almost. It turns out the repodata on disc 1 isn’t enough for a network or hard disk installation. I copied all the discs onto an internal web server, then had to grab the repodata folder from a mirror. Would’ve been fine with the CDs except for the annoying problem that the CD drive on that machine doesn’t work. Once I had that, though, the upgrade went smoothly.

Meanwhile, I’m reading the release notes, and found one item particularly interesting:

There are new experimental drivers that provide support for the widely-used Broadcom 43xx wireless chipsets (http://bcm43xx.berlios.de/).

This is the chipset used in Apple’s Airport Extreme wireless networking interface, which is what you’ll find in just about every wireless-capable Mac made over the last few years. Until recently, there were no Linux drivers because Broadcom would neither write their own nor release specifications for others to write them. The project at Berlios has apparently reverse-engineered the chip to produce an open-source driver, with its first usable version in December

One of the reasons I so rarely use Linux on the PowerBook is that it can’t use the wireless network. The last time I used it was a couple of months ago. I booted it into YDL just to make sure all the software was current, and discovered there hadn’t been any updates since July—even though I could think of plenty of security fixes that had been released since then. Now that Fedora Core has had two releases with full PowerPC support, I may just replace the Yellow Dog Linux partition with Fedora Core. A better security update policy, a wider range of applications, and possibly wireless network support. Sounds like it might be worth it.

The bug was fixed before Firefox 1.5 was released, but it was too late for the fix to make it in. I actually suspect this bug is one of the reasons that so few Linux distributions have upgraded their built-in Firefox releases to 1.5, though they could always have just added the patch to their build process. Fortunately, Mozilla has decided that it’s worth including in the first bugfix release in the 1.5 series, which is now available for testing. Firefox 1.5.0.1 should be out sometime in the next few weeks.

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.