Actually I think this is the problem:

$ /usr/libexec/polkit-gnome-manager 
(polkit-gnome-manager:16242): PolicyKitGnome-DEBUG: Starting PolicyKit GNOME session daemon version 0.9.2

** (polkit-gnome-manager:16242): WARNING **: Object already registered at /org/gnome/PolicyKit/Manager, can't re-register at /
(polkit-gnome-manager:16242): PolicyKitGnome-DEBUG: Setting kill timer to 30 seconds.

Our AuthenticationAgent object is only registered at /org/gnome/PolicyKit/Manager, and isn't allowed to also register at /.  Is this new D-Bus behaviour?

Attaching a patch which fixes it for me by dropping the older D-Bus path name altogether.

Created attachment 357302 [details]
PolicyKit-gnome-reregister.patch

This patch fixes it for me.

Fixing component.

I think that 0.9.2-5 attempted to fix this but I'm not sure it does.  Doesn't it drop the "/" object name altogether, instead of dropping the "/org/gnome/PolicyKit/Manager" name?

I think it needs to register the "/" name.

OK, confirmed fixed after all in PolicyKit-gnome-0.9.2-5.fc12.

Actual issue is a dbus-glib regression that causes the additional object path registrations to fail.  See the fdo bug referenced in the PolicyKit-gnome changelog.

I assume the longer object registration was added because davidz wanted to deprecate the "/" object path for some reason.  Thus I assumed (and davidz said the patch to PolicyKit-gnome was acceptable) that the preferred object path should be "/org/gnome/PolicyKit/Manager" and used that.

Obvious fix is to fix the regression in dbus-glib of course, letting polkit-gnome-manager register both object paths.

I'll have to apply this patch to system-config-printer then:

 PK_AUTH_NAME  = 'org.freedesktop.PolicyKit.AuthenticationAgent'
-PK_AUTH_PATH  = '/'
+PK_AUTH_PATH  = '/org/gnome/PolicyKit/Manager'
 PK_AUTH_IFACE = 'org.freedesktop.PolicyKit.AuthenticationAgent'

(see bug #518427).