I thought a major point of PulseAudio was to let applications share the sound card cleanly. *grumble* Sound worked fine before Fedora switched. I can’t even blame it on a bleeding-edge distribution, since from what I hear, Ubuntu has similar problems.

At least now I know (sort of) why it stopped again after applying the Complete guide to fix PulseAudio and video/audio VLC Media Player issues.

So I put it off for a few days.

Today I decided to try it.

The automatic upgrade program is called preupgrade, presumably because it downloads everything you need in order to prepare for the upgrade. It downloads everything while your system is up and running, then sets it up so that when you reboot, it will launch the installer. It installs everything, makes the changes, then reboots into the newly upgraded system.

And then it’s done.

It’s network aware, and works through yum, so it will actually take into account both third-party repositories and anything that’s been updated since the new release. It actually went out to livna.org RPM Fusion and picked up the appropriate NVIDIA display drivers.

Download while you work. Reboot. Wait. Done.

The only snafu I ran into was that it removed my copy of the Flash plugin, but I think I was using the experimental 64-bit one anyway, so it’s not terribly surprising.

I get the impression that Ubuntu has had a similarly smooth upgrade process for a while. And after my experiences moving from Fedora 9 to Fedora 10, I was seriously considering jumping ship. (Hazards of living on the bleeding edge.) But it looks like I won’t have to.

Now I just have to find time to play around and see what’s new!

• 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. #

Admittedly, Linux distributions often include non-final software by necessity. Many open-source projects spend years in the 0.x state not because they don’t work well, but because the authors don’t feel that it’s complete yet. (Often, a project will take their checklist and build feature 1, stabilize it, add feature 2, stabilize that, etc. so that you get a program that’s a stable subset of the target. Off the top of my head, FreeRADIUS was quite stable long before it hit 1.0, and Clam AntiVirus has been quite usable despite the fact that its latest version is 0.93.)

Lately, though, there’s been a tendency toward sticking with the latest stable release, at least for projects that have reached that magical 1.0 number. Sometimes they go even further. Only a year and a half ago, Fedora planned to skip Firefox 2 and wait for version 3. (Clearly, they expected Firefox 3 would be out sooner!) So it was a surprise to see that this time, Fedora has decided to jump on the new version before it’s finished.

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.

This time, the joke announcement is a song parody of Michael Jackson’s “Thriller.” And unlike a lot of really bad filk I’ve seen (online and otherwise), it’s surprisingly not bad (for all the subject matter is a bit odd. At least, from what I remember of the original song, it scans.

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.