+++ This bug was initially created as a clone of Bug #870224 +++ sealert gets the job done, but it's crufty and fugly. all it really does is slap some UI over the setroubleshoot output AFAICT, so probably straightforward for an abrt addon to just supply the sealert dbus interface and go from there. --- Additional comment from jmoskovc on 2012-10-26 02:45:26 EDT --- We're planning to do it for F19
My concern with this is we begin to treat every AVC as if it is a bug, when a lot of them are just user problems. The goal of setroubleshoot was to instruct the admin how to fix his system as opposed to reporting a bugzilla. The goal of the UI was to get the user to read the description and run restorecon or turn on a boolean, not report a bug, so we have to tell them to run restorecon or set a boolean.
ABRT can still show the window with with the recommendations how to fix the problem before reporting it. By integration we only mean using the same notification icon and have abrt-gui to show the AVC instead of the current avc browser.
We do not want it to be reported if it is a configuration problem. That is the point.
Ok, to make it clear - we only want the AVCs to show in ABRT, so all "problems" can be found at one place, the rest of the process should stay the same - so if anyone clicks on AVC in ABRT the current setroubleshoot window will appear guiding user thru the fixing or reporting as it is now. Only the entry point (notification, gui and cli(if possible)) will be the same. It will still take user thru the path where he can find the suggested fixes or decide to report it - as it is now.
I have no problem with that.
Is this still valid?
No.