Bug 716501 - Abrt gui hangs when saving the event configuration
Summary: Abrt gui hangs when saving the event configuration
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: abrt
Version: 15
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: ---
Assignee: Jiri Moskovcak
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: ABRTF17
TreeView+ depends on / blocked
 
Reported: 2011-06-24 16:43 UTC by redhatbug
Modified: 2015-02-01 22:54 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-03-19 12:51:15 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description redhatbug 2011-06-24 16:43:43 UTC
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:

Comment 1 Jiri Moskovcak 2011-10-10 13:42:18 UTC
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.

Comment 2 redhatbug 2011-10-11 08:41:53 UTC
(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.

Comment 3 Jiri Moskovcak 2011-10-11 08:50:56 UTC
(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

Comment 4 redhatbug 2011-10-11 09:10:59 UTC
(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.

Comment 5 Jiri Moskovcak 2011-11-30 15:53:58 UTC
Are you still seeing this?


Note You need to log in before you can comment on or make changes to this bug.