Let's reconsider some more applications installed by default

Jakub Filak jfilak at redhat.com
Mon Aug 31 10:09:01 UTC 2015


There are plans to replace sealert with ABRT:
https://bugzilla.redhat.com/show_bug.cgi?id=870224

We were almost there, you can even see the test case linked in the bugzilla bug,
but we have decided to postpone the migration to make the integration of
setroubleshoot with ABRT more natural.

The basic idea is to drop sealert (the GUI), teach setroubleshootd to report AVCs
to ABRT and adapt ABRT to the new type of the detected problems (troubleshooting,
removing data from setroubleshoot database).



Jakub
ABRT team


P.S. Both setroubleshoot and ABRT use libreport to open Bugzilla bugs. So both
projects use the same reporting UI.



----- Original Message -----
From: "Kamil Paral" <kparal at redhat.com>
To: "Discussions about development for the Fedora desktop" <desktop at lists.fedoraproject.org>
Sent: Monday, August 31, 2015 10:57:48 AM
Subject: Re: Let's reconsider some more applications installed by default

> * setroubleshoot. This app is completely hopeless. SELinux issues are
> sufficiently rare nowadays that we simply do not need this anymore,
> although it would be ideal for ABRT to detect the issues and handle bug
> reports.

Sorry, I haven't read the whole discussion, but I want to point out that setroubleshoot is quite important for QA during the release cycle (during which the selinux issues are much more common than after the final release). We have a blocker bug criterion that says that during standard operation of pre-installed apps there must be no selinux alert. setroubleshoot makes it very easy to spot, it would be much harder to do without it. We could argue that it can be installed manually during our QA testing, but let's not forget we mostly deal with LiveCDs, so we would have to install it every single time we boot it (which is sometimes dozens times a day). Nobody will of course do that, so that the end result would be that people would install it just a few times during the release cycle before doing "try out all apps" test case. That would considerably decrease our selinux-issues coverage.

So, yes, setroubleshoot has an ugly UI and UX, but if it's going to be removed, we need some replacement to inform us that a selinux problem occurred, at least from QA point of view.


More information about the desktop mailing list