Description of problem: When login in into kde4 an error message is shown with the following text. System policy prevents PulseAudio from aquiring high-priority scheduling An application is preventing to perform an action that requires privileges. Authentification as the super user is required to perform this action. Password for root: _____ [...] Details: Application: (unknown) Action: org.pulseaudio.acquire-high-priority Vendor: This error disappears after some time during the login before I'm able to take a screenshot. You've also have to disable kde splash screen at all to see the entire message. Version-Release number of selected component (if applicable): kdelibs-4.0.0-1.fc9 How reproducible: ever Steps to Reproduce: 1. Login into kde 2. start systemsettings and disable splash screen 3. re-login into kde Actual results: error message Expected results: no error message Additional info: From ~/.xsession-errors: W: polkit.c: Failed to show grant dialog: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. W: polkit.c: PolicyKit responded with 'auth_admin_keep_always' N: main.c: Called SUID root and real-time/high-priority scheduling was requested in the configuration. However, we lack the necessary priviliges: N: main.c: We are not in group 'pulse-rt' and PolicyKit refuse to grant us priviliges. Dropping SUID again. N: main.c: For enabling real-time scheduling please acquire the appropriate PolicyKit priviliges, or become a member of 'pulse-rt', or increase the RLIMIT_NICE/RLIMIT_RTPRIO resource limits for this user. E: main.c: read() failed: Inappropriate ioctl for device E: main.c: daemon startup failed. I've filed this against kdebase because of phonon. When we've figuret out what really happens we could re-assign it.
That's not a KDE bug nor even KDE-specific, it's the PolicyKit policy which is to ask this pointless question. This issue has already been discussed on the mailing list, I can't find an existing bug report though. (I searched the PolicyKit and pulseaudio bugs and found nothing.) As discussed there, PolicyKit should answer "yes" or "no" there (I'd lean towards always saying "yes", but I'm not an expert on the matter), either is better than this annoying dialog box. The fact that the dialogbox disappears before an answer can be given is another bug, probably also in PolicyKit.
(In reply to comment #1) > The fact that the dialogbox disappears before an answer can be given is another > bug, probably also in PolicyKit. And, actually, if you bothered to learn what PolicyKit you would discover that, surprisingly, it's a only mechanism. FWIW, I've already asked Lennart to avoid using PolicyKit in this rather silly way. Lennart?
*** Bug 430558 has been marked as a duplicate of this bug. ***
This is an issue in fc9-alpha1
OK this broke more with the lastest set of fc9-alpha1 updates. Now isntead of one of these screens I get three in a row.
Ajax has removed this for now.