Description of problem: Abrt gui does not respond to Configure Event Entries Version-Release number of selected component (if applicable): abrt-2.0.3-1.fc15.x86_64 How reproducible: Always Steps to Reproduce: 1. Run Automatic Bug Reporting Tool 2. In the "select reporter" screen click Configure Events 3. Select an Event to enter details 4. Enter the details eg username etc for Bugzilla Actual results: Whether the installed configuration file for the event has any entries (as distributed) or not distributed Then when you click the OK button to save your entries or amendments the application hangs and the entered information is not sent to file You have to terminate the application The above scenario is also the case when the older package is installed and the config files are in /etc/abrt/events and not /etc/libreport/events Also when the new "abrt" and "libreport" packages are installed the configuration file in the older version (located in directory /etc/abrt/events and not in its new location of /etc/libreport/events) is saved as /etc/abrt/events/<configfilename>.rpmsave. Should the previous configuration file not be moved from its old location in /etc/abrt/events to the new /etc/libreport/events and the incoming empty configuration file saved as <configfile>.rpmnew Expected results: The Clicking of the OK button should result in the entries being written to the relevant configuration file in /etc/libreport/events. Additional info:
The settings are stored in keyring not in the conf files. The plain text conf files are considered security risk and that's why abrt doesn't write the config there, but these conf files can be edited by hand and abrt will use it as defaults.
(In reply to comment #1) > The settings are stored in keyring not in the conf files. The plain text conf > files are considered security risk and that's why abrt doesn't write the config > there, but these conf files can be edited by hand and abrt will use it as > defaults. But why does the application not work when you first use it after installation? When you try to configure your settings from the application interface it just hangs as reported above and you cannot do anything. Surely this should not happen and the information entered through the gui interface should be stored by the application in the proper place (wherever that is) for future use and the bug report sent off using the settings entered.
(In reply to comment #2) > (In reply to comment #1) > > The settings are stored in keyring not in the conf files. The plain text conf > > files are considered security risk and that's why abrt doesn't write the config > > there, but these conf files can be edited by hand and abrt will use it as > > defaults. > > But why does the application not work when you first use it after installation? - that's a good question, what desktop are you running > When you try to configure your settings from the application interface it just > hangs as reported above and you cannot do anything. - it tries to talk to gnome-keyring-daemon, isn't there a dialog asking for password to unlock the keyring? (might be hidden behind other windows) > Surely this should not happen and the information entered through the gui > interface should be stored by the application in the proper place (wherever > that is) for future use and the bug report sent off using the settings entered. - it definitely shouldn't, reopening for further investigation
(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > The settings are stored in keyring not in the conf files. The plain text conf > > > files are considered security risk and that's why abrt doesn't write the config > > > there, but these conf files can be edited by hand and abrt will use it as > > > defaults. > > > > But why does the application not work when you first use it after installation? > > - that's a good question, what desktop are you running > > > When you try to configure your settings from the application interface it just > > hangs as reported above and you cannot do anything. > > - it tries to talk to gnome-keyring-daemon, isn't there a dialog asking for > password to unlock the keyring? (might be hidden behind other windows) > > > Surely this should not happen and the information entered through the gui > > interface should be stored by the application in the proper place (wherever > > that is) for future use and the bug report sent off using the settings entered. > > - it definitely shouldn't, reopening for further investigation I am using KDE on fedora 15. The problem occurred after first installation. About two months ago I installed Fedora 15 a few times on different machines and installed the updates then current. And the problem repeated in all cases. I am pretty certain the key ring daemon was not invoked and no other windows opened. It may be that subsequent updates have resolved the issue. If I were to install Fedora 15 again now and apply the latest updates it may be ok. But that was not the case a month or two ago. I think it is worth investigating though. And thank you.
Are you still seeing this?