Description of problem: system-config-users cannot gain root rights and because of that, it doesn't start when you start it from the KDE menu. How reproducible: Just search for "Users and groups" in the KDE menu and execute it. Actual results: The config tool doesn't start. If you run it in a terminal, it says it can't run without root rights and asks for the root password. Expected results: The tool should ask polkit for root rights and the user should be prompted to type a root password. Additional info: I'm proposing this as a F19 Finale blocker bug because it meets the criteria "All applications listed under the Applications menu or category must start successfully".
I can't reproduce it on my F19 installation and it looks more like Polkit issue. Are polkitd and auth agent running? ps -A | grep polkit
Yes, it seems like a polkit-kde issue because other things don't work either. It was TC1 after updates. Now, I'm reinstalling the machine to make sure it occurs in TC1 without updates, too.
OK, we narrowed it down to systemd. It works with TC1 without updates and systemd 204.3, but it doesn't work with systemd 204.4 from updates-testing. polkit-kde-auth doesn't run any more for some reason. It's not also specific to system-config-users, it affects other KDE components that require polkit, too (you can't logout, reboot,... from the KDE menu).
Unfortunately I can't reproduce with TC2 x86_64 DVD. Initially there's systemd 204-3. I updated to 204-6, and then downgraded to 204-4. All with reboots. All of them worked correctly, polkit-kde-auth was running every time. I have no idea where the difference is, because initially I worked with Jiri on this report and his findings were real.
The bug might be related to localization. I can reproduce it every time with Czech localization, but I couldn't reproduce it with the default English one. Will investigate it a bit more tomorrow.
I repeated my approach from comment 4 with Czech localization, same results - still can't reproduce.
Discussed at 2013-06-10 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-10/f19final-blocker-review-4.2013-06-10-16.01.log.txt . For now this is rejected as a blocker as no-one else has been able to reproduce it. Please re-propose as a blocker if you can pinpoint the setup that causes this bug to occur, and it seems common enough to be worth blocker status.
Seems like a raise condition. We've tried it many times on several computers and we cannot find any pattern. Even I can't preproduce it every time, now.
If you guys want this fixed I fear you need to track this down on your own, as I am not running KDE.
After talking to Jiri, we decided to close this bug. We can't reproduce it anymore. When someone sees this problem again, feel free to reopen, thanks.