Here is what we discussed today. If you want to discuss some topic(s) further, reply to this mail, ONE TOPIC per reply (otherwise it will be difficult to track topics)
* remove db, use dump dir name as key (instead of uuid:uid) - report lib probably needs this - users definitely do not want (or cannot) use a centralized storage and db * report lib (urgent?) - what exactly needs to be done? who will be the lead? =============================================================== ^^^^^^ I took it
* implement .conf description files and event description files - see other minidoc ^^^^^^ Postponed
* apply gui_event_fix.patch - otherwise we are still using obsolete [ AnalyzerActionsAndReporters ] section: Kerneloops = KerneloopsReporter CCpp = Bugzilla, Logger Python = Bugzilla, Logger ^^^^^^ I took it
* abrt-action-send-dbus-signal - abrtd no longer needs to send dbus signal then - see the item below why we might want that * split abrt-dbus from abrtd * move command processing from abrt-dbus to abrt-server - this will solve "report step is not threaded" bug, since abrt-server's are run in parallel or move command processing to client side - especially that this would fix security problems - eliminates a lot of complexity by removing the need to talk over dbus - what to do with "inform all" functionality then? - abrt-action-install-debuginfo needs special privs, is it ok?; what else needs special privileges? * rewrite abrt-action-install-debuginfo in C(++)? - which makes it possible to mark it suid-root (IIRC shell scripts have problems there) - while at it, reinstate lost debuginfo cache trimming capability =============================================================== ^^^^^^ Postponed; Jiri wants to try coding abrt-action-install-debuginfo in python
* remove some (all remaining?) C++ isms - just converting LoadPluginSettings() and make_description_FOO() will make all abrt-action-FOO convertible to pure C - move make_description_FOO to libABRTUtils - makes many (all?) abrt-action-FOO lose libABRTdUtils dependency (its BIG) (howto test: change src/plugins/Makefile.am, and try rebuilding) - while at it, rename make_dsc_mailx to make_description_mailx ^^^^^^^ Nikola volunteered
* remove remaining plugins (koops-scanner/ccpp/db) - this will eliminate PluginManager.* ^^^^^^^ Postponed
* generalize "crash detection via log file analysis" - nice to have (can catch X crashes etc), but not urgent ^^^^^^^ Postponed
On Mon, 2010-11-15 at 17:31 +0100, Denys Vlasenko wrote:
Here is what we discussed today. If you want to discuss some topic(s) further, reply to this mail, ONE TOPIC per reply (otherwise it will be difficult to track topics)
Regarding better configurability and ability to learn about and override some settings from the client side:
- implement .conf description files and event description files
- see other minidoc
Minidoc follows:
How to configure event processing?
Via command-line options in abrt_event.conf:
EVENT=report analyzer=CCpp abrt-action-print -o /var/log/abrt.log
Via config file:
EVENT=report_Bz1 abrt-action-bugzilla -c /etc/abrt/plugins/Bugzilla1.conf EVENT=report_Bz2 abrt-action-bugzilla -c /etc/abrt/plugins/Bugzilla2.conf
Using env overrides:
EVENT=report_Bz1 abrt-action-bugzilla -e Bugzilla1 EVENT=report_Bz2 abrt-action-bugzilla -e Bugzilla2
abrt-action-bugzilla will check $BugzillaN_PARAM environment variables. They can be supplied by client. Currently we do this, but without -e, and env var name prefix is fixed in the code (for example, always "Bugzilla" for abrt-action-bugzilla).
Combined two previous:
EVENT=report_Bz1 abrt-action-bugzilla -e Bugzilla1 -c /etc/abrt/plugins/Bugzilla1.conf EVENT=report_Bz2 abrt-action-bugzilla -e Bugzilla2 -c /etc/abrt/plugins/Bugzilla2.conf
This allows client to figure out which settings are used by default (by reading BugzillaN.conf), check them ("does Login parameter exist?") and override exactly them by using correct env var name prefix. Currently we have a problem: the env var name prefix is the same for both invocations, and thus they cannot be overridden *differently*.
How this last approach looks from client's point of view:
Client sees many /etc/abrt/plugins/*.conf and corresponding *.xml (?) files. When it wants to process an event EV, it overrides some of values /etc/abrt/plugins/FOO.conf by setting $FOO_name=value; then runs actions as defined in abrt_event.conf. How it knows which FOO.conf are relevant for event EV? Another *.xml file for that??
(Note on current git: it has only /etc/abrt/plugins/*.conf files. This has a problem that there is no information which parameters are, say, required, required and must be nonempty, must be numeric, etc... the only info .conf files currently provide is that if there is some parameter, then it is obviously exists.)
crash-catcher@lists.fedorahosted.org