[SATYR PATCH] Add source line to gdb frame text output
by Jakub Filak
Closes #95
Signed-off-by: Jakub Filak <jfilak(a)redhat.com>
---
lib/gdb_frame.c | 2 ++
tests/python/gdb.py | 10 +++++-----
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/lib/gdb_frame.c b/lib/gdb_frame.c
index e3985c4..7cf0287 100644
--- a/lib/gdb_frame.c
+++ b/lib/gdb_frame.c
@@ -282,6 +282,8 @@ sr_gdb_frame_append_to_str(struct sr_gdb_frame *frame,
if (frame->function_name)
sr_strbuf_append_str(str, " at");
sr_strbuf_append_strf(str, " %s", frame->source_file);
+ if (frame->source_line != -1)
+ sr_strbuf_append_strf(str, ":%d", frame->source_line);
}
if (frame->signal_handler_called)
diff --git a/tests/python/gdb.py b/tests/python/gdb.py
index 2752771..fdc61a6 100755
--- a/tests/python/gdb.py
+++ b/tests/python/gdb.py
@@ -13,11 +13,11 @@ contents = load_input_contents('../gdb_stacktraces/rhbz-803600')
threads_expected = 2
frames_expected = 227
expected_short_text = '''Thread no. 1 (5 frames)
- #0 validate_row at gtktreeview.c
- #1 validate_visible_area at gtktreeview.c
- #2 gtk_tree_view_bin_expose at gtktreeview.c
- #3 gtk_tree_view_expose at gtktreeview.c
- #4 _gtk_marshal_BOOLEAN__BOXED at gtkmarshalers.c
+ #0 validate_row at gtktreeview.c:5699
+ #1 validate_visible_area at gtktreeview.c:5898
+ #2 gtk_tree_view_bin_expose at gtktreeview.c:4253
+ #3 gtk_tree_view_expose at gtktreeview.c:4955
+ #4 _gtk_marshal_BOOLEAN__BOXED at gtkmarshalers.c:84
'''
class TestGdbStacktrace(BindingsTestCase):
--
1.8.3.1
10 years, 9 months
[ABRT PATCH] use absolute path in python shebang rhzb#987010
by Jiri Moskovcak
- also use -u to disable output buffering (helps when scraping
the output and showing it in gui)
Signed-off-by: Jiri Moskovcak <jmoskovc(a)redhat.com>
---
src/plugins/abrt-action-perform-ccpp-analysis.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/plugins/abrt-action-perform-ccpp-analysis.in b/src/plugins/abrt-action-perform-ccpp-analysis.in
index 7348641..fbcd8a1 100644
--- a/src/plugins/abrt-action-perform-ccpp-analysis.in
+++ b/src/plugins/abrt-action-perform-ccpp-analysis.in
@@ -1,4 +1,4 @@
-#!/usr/bin/env python
+#!/usr/bin/python -u
"""This module provides a function for executing of disjunction of analyze
events.
"""
--
1.8.3.1
10 years, 9 months
[PATCH] abrt-action-save-package-data: fix handling of ProcessUnpackaged on scripts
by Denys Vlasenko
get_script_name() returns NULL if "python /path/to/something"
and /path/to/something isn't packaged, or __if it is blacklisted__.
But then the caller, SavePackageDescriptionToDebugDump,
returns 1 as intended... only if (!settings_bProcessUnpackaged).
This is wrong if /path/to/something is blacklisted -
in this case, it should be unconditional.
This change moves "if (is_path_blacklisted(executable))"
check out of get_script_name() into the caller.
While as it, eliminate double checking of !settings_bProcessUnpackaged
by also moving
log("Interpreter crashed, but no packaged script detected: '%s'", cmdline);
tot he caller.
Signed-off-by: Denys Vlasenko <dvlasenk(a)redhat.com>
---
src/daemon/abrt-action-save-package-data.c | 44 ++++++++++++++----------------
1 file changed, 21 insertions(+), 23 deletions(-)
diff --git a/src/daemon/abrt-action-save-package-data.c b/src/daemon/abrt-action-save-package-data.c
index b6da39e..c209c4b 100644
--- a/src/daemon/abrt-action-save-package-data.c
+++ b/src/daemon/abrt-action-save-package-data.c
@@ -194,10 +194,10 @@ static struct pkg_envra *get_script_name(const char *cmdline, char **executable)
// TODO: we don't verify that python executable is not modified
// or that python package is properly signed
// (see CheckFingerprint/CheckHash below)
- /* Try to find package for the script by looking at argv[1].
- * This will work only if the cmdline contains the whole path.
- * Example: python /usr/bin/system-control-network
- */
+ /* Try to find package for the script by looking at argv[1].
+ * This will work only if the cmdline contains the whole path.
+ * Example: python /usr/bin/system-control-network
+ */
struct pkg_envra *script_pkg = NULL;
char *script_name = get_argv1_if_full_path(cmdline);
if (script_name)
@@ -207,23 +207,12 @@ static struct pkg_envra *get_script_name(const char *cmdline, char **executable)
{
/* There is a well-formed script name in argv[1],
* and it does belong to some package.
- * Replace interpreter's package_full_name and executable
+ * Replace executable
* with data pertaining to the script.
*/
*executable = script_name;
- /* executable has changed, check it again */
- if (is_path_blacklisted(*executable))
- {
- log("Blacklisted executable '%s'", *executable);
- return NULL;
- }
}
}
- if (!script_pkg && !settings_bProcessUnpackaged)
- {
- log("Interpreter crashed, but no packaged script detected: '%s'", cmdline);
- return NULL;
- }
return script_pkg;
}
@@ -299,18 +288,27 @@ static int SavePackageDescriptionToDebugDump(const char *dump_dir_name)
if (g_list_find_custom(settings_Interpreters, basename, (GCompareFunc)g_strcmp0))
{
struct pkg_envra *script_pkg = get_script_name(cmdline, &executable);
+ /* executable may have changed, check it again */
+ if (is_path_blacklisted(executable))
+ {
+ log("Blacklisted executable '%s'", executable);
+ goto ret; /* return 1 (failure) */
+ }
if (!script_pkg)
{
- /* none or unknown script, and config says we don't care about
- * unpackaged things
+ /* Script name is not absolute, or it doesn't
+ * belong to any installed package.
*/
if (!settings_bProcessUnpackaged)
- goto ret;
+ {
+ log("Interpreter crashed, but no packaged script detected: '%s'", cmdline);
+ goto ret; /* return 1 (failure) */
+ }
- /* unpackaged script, but the settings says we want to keep it
- * bz plugin wont allow to report this anyway, because component
- * is missing, so there is no reason to mark it as not_reportable
- * someone might want to use abrt to report it using ftp
+ /* Unpackaged script, but the settings says we want to keep it.
+ * BZ plugin wont allow to report this anyway, because component
+ * is missing, so there is no reason to mark it as not_reportable.
+ * Someone might want to use abrt to report it using ftp.
*/
goto ret0;
}
--
1.8.1.4
10 years, 9 months
[GNOME-ABRT PATCH] Use GLib.io_add_watch() instead of IOChanell.add_watch()
by Jakub Filak
The add_watch() method has been deprecated in pygobject-3.7.2
Closes rhbz#985990
Signed-off-by: Jakub Filak <jfilak(a)redhat.com>
---
src/gnome_abrt/signals.py | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/gnome_abrt/signals.py b/src/gnome_abrt/signals.py
index b17ae48..e5c4e83 100644
--- a/src/gnome_abrt/signals.py
+++ b/src/gnome_abrt/signals.py
@@ -70,5 +70,6 @@ def glib_sigchld_signal_handler(callback, data=None):
channel = GLib.IOChannel(pipes[0])
channel.set_flags(GLib.IOFlags.NONBLOCK)
- channel.add_watch(GLib.IOCondition.IN,
- _gsource_handle_signal, (callback, data))
+
+ GLib.io_add_watch(channel, GLib.PRIORITY_DEFAULT, GLib.IOCondition.IN,
+ _gsource_handle_signal, (callback, data))
--
1.8.3.1
10 years, 9 months
Handle BlackListedPaths in abrt coredump hook too?
by Denys Vlasenko
Currently we have
BlackListedPaths = /usr/share/doc/*, */example*, /usr/bin/nspluginviewer, /usr/lib/xulrunner-*/plugin-container
in abrt-action-save-package-data.conf, and
abrt-action-save-package-data will fail (exit with 1)
if it sees one of these executables.
(Sans a bug which I just noticed there. Sigh...).
IOW: we still save the crash using abrt coredump hook,
and then delete it.
However, we may want to improve this.
In particular, it would help these people:
https://bugzilla.redhat.com/show_bug.cgi?id=918274
"Make it possible for coredumping process to close file descriptors early"
Their problem is that coredumping takes noticeable
amount of time, and for them it is a problem:
"""
When an application is coring, the network connections are not
torn down till the application is done coring.
This is unfortunate as it means connectivity
isn’t severed and we don’t get cancel on disconnect
till the core is done.
"""
This looks like a genuine situation to me.
I suggested this, among other possible solutions:
"""
If they don't absolutely need to have coredumps,
they can disable coredumping for the programs they
want to terminate fast(er). Either via shell ("ulimit -c 0") or in C:
struct_rlimit rlim = {0, 0};
set_rlimit(RLIMIT_CORE, &rlim);
"""
but it's won't _really_ help if abrt hook is installed:
it still will be called, and still will read and save
entire coredump.
If we can teach coredump helper to check BlackListedPaths
and abort coredump at once, it will help them:
they can simply add their app to BlackListedPaths.
Question #1: do we want to implement this?
Question #2: isn't abrt-action-save-package-data.conf
a wrong file for this conf item, then?
Where should it be moved? /etc/abrt/blacklist.conf?
--
vda
10 years, 9 months
[ABRT PATCH] change /var/spool/abrt/ to /var/tmp/abrt rhbz#912750
by Jiri Moskovcak
- note: /var/spool/abrt-upload is still ok, the data is moved
to /var/tmp/abrt/ after it's processed
Signed-off-by: Jiri Moskovcak <jmoskovc(a)redhat.com>
---
doc/abrt.conf.txt | 2 +-
.../en-US/Automatic_Bug_Reporting_Tool_ABRT.xml | 26 +++++++++++-----------
doc/design | 24 ++++++++++----------
doc/implementation | 6 ++---
doc/interpreted-languages | 8 +++----
src/cli/list.c | 2 +-
src/daemon/abrt.conf | 4 ++--
src/daemon/abrtd.c | 2 +-
src/hooks/abrt-harvest-vmcore.conf | 2 +-
src/hooks/abrt-harvest-vmcore.in | 2 +-
src/hooks/abrt-hook-ccpp.c | 4 ++--
11 files changed, 41 insertions(+), 41 deletions(-)
diff --git a/doc/abrt.conf.txt b/doc/abrt.conf.txt
index 6626596..d782e3d 100644
--- a/doc/abrt.conf.txt
+++ b/doc/abrt.conf.txt
@@ -16,7 +16,7 @@ A description of each item follows:
DumpLocation = 'directory'::
The directory where should 'abrt' store coredumps and all files which are
- needed for reporting. The default is /var/spool/abrt.
+ needed for reporting. The default is /var/tmp/abrt.
MaxCrashReportsSize = 'number'::
The maximum disk space (specified in megabytes) that 'abrt'
diff --git a/doc/deployment/en-US/Automatic_Bug_Reporting_Tool_ABRT.xml b/doc/deployment/en-US/Automatic_Bug_Reporting_Tool_ABRT.xml
index c05dd4a..e11307a 100644
--- a/doc/deployment/en-US/Automatic_Bug_Reporting_Tool_ABRT.xml
+++ b/doc/deployment/en-US/Automatic_Bug_Reporting_Tool_ABRT.xml
@@ -15,7 +15,7 @@
</para>
<!-- msvoboda: Differencies between ABRT 1-series and ABRT 2-series cannot be added to Release Notes because the amount of changes is too large
<para>For more information on the major differences between the <application>ABRT</application> 1-series and <application>ABRT</application> 2-series, refer to the <citetitle>Red Hat Enterprise Linux 6.2 Release Notes</citetitle>.</para>-->
- <!--msvoboda: The ABRT Migration section will be added on RHEL 6.2 GA
+ <!--msvoboda: The ABRT Migration section will be added on RHEL 6.2 GA
<para>For more information on the major differences between the <application>ABRT</application> 1-series and <application>ABRT</application> 2-series, as well as easy migration instructions, refer to <xref linkend="sect-migration_to_abrt2"/>
</para>-->
</important>
@@ -222,7 +222,7 @@ Starting abrt daemon: [ OK ]</screen>
<section id="sect-abrt-gui">
<title>Using the Graphical User Interface</title>
<para>
- The <application>ABRT</application> daemon sends a broadcast D-Bus message whenever a problem report is created. If the <application>ABRT</application> notification applet is running, it catches this message and displays an orange alarm icon in the Notification Area. You can open the <application>ABRT GUI</application> application using this icon. As an alternative, you can display the <application>ABRT</application> GUI by selecting the
+ The <application>ABRT</application> daemon sends a broadcast D-Bus message whenever a problem report is created. If the <application>ABRT</application> notification applet is running, it catches this message and displays an orange alarm icon in the Notification Area. You can open the <application>ABRT GUI</application> application using this icon. As an alternative, you can display the <application>ABRT</application> GUI by selecting the
<menuchoice>
<guimenu>Application</guimenu>
<guisubmenu>System Tools</guisubmenu>
@@ -449,14 +449,14 @@ Starting abrt daemon: [ OK ]</screen>
To view detected problems, enter the <command>abrt-cli list</command> command:
</para>
<screen>~]# <command>abrt-cli list</command>
-Directory: /var/spool/abrt/ccpp-2011-09-13-10:18:14-2895
+Directory: /var/tmp/abrt/ccpp-2011-09-13-10:18:14-2895
count: 2
executable: /usr/bin/gdb
package: gdb-7.2-48.el6
time: Tue 13 Sep 2011 10:18:14 AM CEST
uid: 500
-Directory: /var/spool/abrt/ccpp-2011-09-21-18:18:07-2841
+Directory: /var/tmp/abrt/ccpp-2011-09-21-18:18:07-2841
count: 1
executable: /bin/bash
package: bash-4.1.2-8.el6
@@ -631,7 +631,7 @@ uid: 500</screen>
<para>...where <replaceable>directory</replaceable> stands for the <emphasis
role="bold">problem data directory</emphasis> of the problem that is being reported. For example:
</para>
- <screen>~]$ <command>abrt-cli report</command> <filename>/var/spool/abrt/ccpp-2011-09-13-10:18:14-2895</filename>
+ <screen>~]$ <command>abrt-cli report</command> <filename>/var/tmp/abrt/ccpp-2011-09-13-10:18:14-2895</filename>
How you would like to analyze the problem?
1) Collect .xsession-errors
2) Local GNU Debugger
@@ -710,8 +710,8 @@ Select reporter(s): _</screen>
<para>
...where <replaceable>directory</replaceable> stands for the problem data directory of the problem being deleted. For example:
</para>
- <screen>~]$ <command>abrt-cli rm</command> <filename>/var/spool/abrt/ccpp-2011-09-12-18:37:24-4413</filename>
-rm '/var/spool/abrt/ccpp-2011-09-12-18:37:24-4413'</screen>
+ <screen>~]$ <command>abrt-cli rm</command> <filename>/var/tmp/abrt/ccpp-2011-09-12-18:37:24-4413</filename>
+rm '/var/tmp/abrt/ccpp-2011-09-12-18:37:24-4413'</screen>
<note>
<title>Deletion of a problem can lead to frequent ABRT notification</title>
<para>
@@ -1234,11 +1234,11 @@ rm '/var/spool/abrt/ccpp-2011-09-12-18:37:24-4413'</screen>
</varlistentry>
<varlistentry>
<term>
- DumpLocation = /var/spool/abrt
+ DumpLocation = /var/tmp/abrt/
</term>
<listitem>
<para>
- This directive is commented out by default. It specifies the location where problem data directories are created and in which problem core dumps and all other problem data are stored. The default location is set to the <filename>/var/spool/abrt</filename> directory. Whichever directory you specify in this directive, you must ensure that it exists and it is writable for <systemitem class="daemon">abrtd</systemitem>. If you change the default value of this option, be aware that in order to ensure proper functionality of <application>ABRT</application>, this directory <emphasis role="bold">must not</emphasis> be the same as the directory specified for the <option>WatchCrashdumpArchiveDir</option> option.
+ This directive is commented out by default. It specifies the location where problem data directories are created and in which problem core dumps and all other problem data are stored. The default location is set to the <filename>/var/tmp/abrt/</filename> directory. Whichever directory you specify in this directive, you must ensure that it exists and it is writable for <systemitem class="daemon">abrtd</systemitem>. If you change the default value of this option, be aware that in order to ensure proper functionality of <application>ABRT</application>, this directory <emphasis role="bold">must not</emphasis> be the same as the directory specified for the <option>WatchCrashdumpArchiveDir</option> option.
</para>
<warning>
<title>Do not modify this option in SELinux</title>
@@ -1330,7 +1330,7 @@ rm '/var/spool/abrt/ccpp-2011-09-12-18:37:24-4413'</screen>
<section id="sect-abrt-configuration-kernel_panic_detection">
<title>Configuring ABRT to Detect a Kernel Panic</title>
<para>
- With Red Hat Enterprise Linux 6.3, <application>ABRT</application> can detect a kernel panic using the <systemitem class="service">abrt-vmcore</systemitem> service, which is provided by the <package>abrt-addon-vmcore</package> package. The service starts automatically on system boot and searches for a core dump file in the <filename>/var/crash/</filename> directory. If a core dump file is found, <systemitem class="service">abrt-vmcore</systemitem> creates the <systemitem>problem data directory</systemitem> in the <filename>/var/spool/abrt/</filename> directory and moves the core dump file to the newly created problem data directory. After the <filename>/var/crash/</filename> directory is searched through, the service is stopped until the next system boot.
+ With Red Hat Enterprise Linux 6.3, <application>ABRT</application> can detect a kernel panic using the <systemitem class="service">abrt-vmcore</systemitem> service, which is provided by the <package>abrt-addon-vmcore</package> package. The service starts automatically on system boot and searches for a core dump file in the <filename>/var/crash/</filename> directory. If a core dump file is found, <systemitem class="service">abrt-vmcore</systemitem> creates the <systemitem>problem data directory</systemitem> in the <filename>/var/tmp/abrt/</filename> directory and moves the core dump file to the newly created problem data directory. After the <filename>/var/crash/</filename> directory is searched through, the service is stopped until the next system boot.
</para>
<para>
To configure <application>ABRT</application> to detect a kernel panic, perform the following steps:
@@ -1357,7 +1357,7 @@ rm '/var/spool/abrt/ccpp-2011-09-12-18:37:24-4413'</screen>
</listitem>
</orderedlist>
<para>
- Unless <application>ABRT</application> is configured differently, problem data for any detected kernel panic is now stored in the <filename>/var/spool/abrt/</filename> directory and can be further processed by <application>ABRT</application> just as any other detected kernel oops.
+ Unless <application>ABRT</application> is configured differently, problem data for any detected kernel panic is now stored in the <filename>/var/tmp/abrt/</filename> directory and can be further processed by <application>ABRT</application> just as any other detected kernel oops.
</para>
</section>
<section id="sect-abrt-configuration-debuginfo">
@@ -1447,7 +1447,7 @@ rm '/var/spool/abrt/ccpp-2011-09-12-18:37:24-4413'</screen>
<note>
<title>The abrt user and group</title>
<para>
- When the <package>abrt-desktop</package> package is installed, it creates a new system user and a group, both named <systemitem class="username">abrt</systemitem>. This user is used by the <systemitem class="daemon">abrtd</systemitem> daemon, for example, as the owner:group of <filename>/var/spool/abrt/*</filename> directories.
+ When the <package>abrt-desktop</package> package is installed, it creates a new system user and a group, both named <systemitem class="username">abrt</systemitem>. This user is used by the <systemitem class="daemon">abrtd</systemitem> daemon, for example, as the owner:group of <filename>/var/tmp/abrt/*</filename> directories.
</para>
</note>
</listitem>
@@ -1612,7 +1612,7 @@ ftp> <command>quit</command></screen>
[1] 2823
~]$ <command>kill -s SEGV 2823</command></screen>
<para>
- <application>ABRT</application> should detect a crash shortly after executing the <command>kill</command> command. Check that the crash was detected by <application>ABRT</application> on the client system (this can be checked by examining the appropriate syslog file, by running the <command>abrt-cli list --full</command> command, or by examining the crash dump created in the <filename>/var/spool/abrt</filename> directory), copied to the server system, unpacked on the server system and can be seen and acted upon using <command>abrt-cli</command> or <command>abrt-gui</command> on the server system.
+ <application>ABRT</application> should detect a crash shortly after executing the <command>kill</command> command. Check that the crash was detected by <application>ABRT</application> on the client system (this can be checked by examining the appropriate syslog file, by running the <command>abrt-cli list --full</command> command, or by examining the crash dump created in the <filename>/var/tmp/abrt</filename> directory), copied to the server system, unpacked on the server system and can be seen and acted upon using <command>abrt-cli</command> or <command>abrt-gui</command> on the server system.
</para>
</section>
</section>
diff --git a/doc/design b/doc/design
index 9044529..a9ce040 100644
--- a/doc/design
+++ b/doc/design
@@ -43,23 +43,23 @@ of the above usage scenarios.
Since currently we do not know how to dump oops on demand,
we can only poll for it. There is a small daemon, abrt-dump-oops,
which polls syslog file and saves oopses when it sees them.
-The oops dump is written into /var/spool/abrt/DIR.
-[TODO? abrt-dump-oops spawns "abrt-handle-crashdump -d /var/spool/abrt/DIR"
+The oops dump is written into /var/tmp/abrt/DIR.
+[TODO? abrt-dump-oops spawns "abrt-handle-crashdump -d /var/tmp/abrt/DIR"
which processes it according to configuration in /etc/abrt/*.conf]
In order to catch binary crashes, we install a handler for it
in /proc/sys/kernel/core_pattern (by setting it to
-"|/usr/libexec/abrt-hook-ccpp /var/spool/abrt ....").
-When process dumps core, the dump is written into /var/spool/abrt/DIR.
+"|/usr/libexec/abrt-hook-ccpp /var/tmp/abrt ....").
+When process dumps core, the dump is written into /var/tmp/abrt/DIR.
[TODO? after this, abrt-hook-ccpp spawns "abrt-handle-crashdump
--d /var/spool/abrt/DIR"]
+-d /var/tmp/abrt/DIR"]
Then abrt-hook-ccpp terminates.
When python program crashes, it invokes internal python subroutine
which connects to abrtd via /var/run/abrt/abrt.socket and sends
-crash data to abrtd. abrtd creates dump dir /var/spool/abrt/DIR.
+crash data to abrtd. abrtd creates dump dir /var/tmp/abrt/DIR.
-abrtd daemon watches /var/spool/abrt for new directories.
+abrtd daemon watches /var/tmp/abrt/ for new directories.
When new directory is noticed, abrtd runs "post-create" event
on it, and emits a dbus signal. This dbus signal is used
to inform online users about the new crash: if abrt-applet
@@ -89,22 +89,22 @@ The key dbus calls served by abrtd are:
- GetCrashInfos(): returns a vector_map_crash_data_t (vector_map_vector_string_t)
of crashes for given uid
v[N]["executable"/"uid"/"kernel"/"backtrace"][N] = "contents"
-- CreateReport(/var/spool/abrt/DIR): starts creating a report.
+- CreateReport(/var/tmp/abrt/DIR): starts creating a report.
Returns job id (uint64).
Then abrtd run "analyze" event on the DIR.
After it completes, when report creation thread has finished,
- JobDone(client_dbus_ID,/var/spool/abrt/DIR) dbus signal is emitted.
+ JobDone(client_dbus_ID,/var/tmp/abrt/DIR) dbus signal is emitted.
[Problem: how to do privilegged plugin specific actions?]
Solution: if plugin needs an access to some root only accessible dir then
abrt should be run by root anyway
- debuginfo gets installed using pk-debuginfo-install, which cares about
privileges itself, so no problem here
-- GetJobResult(/var/spool/abrt/DIR): returns map_crash_data_t (map_vector_string_t)
+- GetJobResult(/var/tmp/abrt/DIR): returns map_crash_data_t (map_vector_string_t)
- Report(map_crash_data_t (map_vector_string_t)):
- "Please report this crash":
+ "Please report this crash":
abrtd run "report[_FOO]" event(s) on the DIR.
Returns report_status_t (map_vector_string_t) - the status of each event
-- DeleteDebugDump(/var/spool/abrt/DIR): delete /var/spool/abrt/DIR. Returns bool
+- DeleteDebugDump(/var/tmp/abrt/DIR): delete /var/tmp/abrt/DIR. Returns bool
[Note: we are in the process of reducing/eliminating
dbus communication between abrt-gui/abrt-cli and abrtd.
diff --git a/doc/implementation b/doc/implementation
index e749a47..0ec9831 100644
--- a/doc/implementation
+++ b/doc/implementation
@@ -8,7 +8,7 @@ the coredump of crashing app:
* helper source code: http://git.fedorahosted.org/git/abrt.git?p=abrt.git;a=blob_plain;f=src/Ho...
the code responsible for this:
- #define CORE_PATTERN "|/usr/libexec/abrt-hook-ccpp" "/var/spool/abrt" %p %s %u"
+ #define CORE_PATTERN "|/usr/libexec/abrt-hook-ccpp" "/var/tmp/abrt" %p %s %u"
ofstream fOutCorePattern;
fOutCorePattern.open(CORE_PATTERN_IFACE);
if (fOutCorePattern.is_open())
@@ -33,7 +33,7 @@ cmdline:
char path[sizeof("/proc/%u/cmdline") + sizeof(int)*3];
sprintf(path, "/proc/%u/cmdline", (int)pid);
-both is saved to file in /var/spool/abrt/ccpp-<time>-<pid> readable
+both is saved to file in /var/tmp/abrt/ccpp-<time>-<pid> readable
only by owner the crashed process:
int fd = open(pPath, O_WRONLY | O_TRUNC | O_CREAT, 0666);
if(fd){
@@ -82,7 +82,7 @@ abrt-action-install-debuginfo is a shell script using elfutils to get build-ids
- gdb is run with the same privileges as the crashed app (setregid, setreuid)
d) BT is saved to same directory where the coredump is
-Once the backtrace is processed all data from the /var/spool/abrt/ccpp-<time>-<pid> is sent
+Once the backtrace is processed all data from the /var/tmp/abrt/ccpp-<time>-<pid> is sent
over dbus to the client and then user can edit the backtrace. When user is happy about
the report and command the client (gui, tui) to send the it, the client sends the data back
to the daemon calling the Report(data) method over the dbus. The actual reporting is done by
diff --git a/doc/interpreted-languages b/doc/interpreted-languages
index 6609cd9..713bc59 100644
--- a/doc/interpreted-languages
+++ b/doc/interpreted-languages
@@ -32,12 +32,12 @@ be interpreted by the interpreter in the same way as the applications
When some event which should be caught by ABRT occurs and is detected
by the hook, the hook reports it to ABRT using ABRT daemon's socket
file. ABRT then creates a new directory describing the crash in
-/var/spool/abrt.
+/var/tmp/abrt.
The ABRT's CCpp plugin does not use the socket file, but it creates
-crash data directory in /var/spool/abrt directly. Interpreted hooks
+crash data directory in /var/tmp/abrt directly. Interpreted hooks
must not report crashes this way, because SELinux blocks interpreter
-access to /var/spool/abrt and this access can not be granted due to
+access to /var/tmp/abrt and this access can not be granted due to
security issues.
ABRT socket file resides in /var/run/abrt.socket. Hooks should open
@@ -76,7 +76,7 @@ for the crash dump. Sensible names are "python", "perl", "java" etc.
BASENAME
Short string indicating the origin of the event. It is used as a part
-of directory name: /var/spool/abrt/BASENAME-suffix. Use "python" for
+of directory name: /var/tmp/abrt/BASENAME-suffix. Use "python" for
Python exceptions, "ruby" for ruby interpreter, "java" for JRE.
REASON
diff --git a/src/cli/list.c b/src/cli/list.c
index 67ee00e..c29eba5 100644
--- a/src/cli/list.c
+++ b/src/cli/list.c
@@ -27,7 +27,7 @@
* add wildcard e.g. *-2011-04-01-10-* (list all problems in specific day)
*
* TODO?: remove base dir from list of crashes? is there a way that same crash can be in
- * ~/.abrt/spool and /var/spool/abrt? needs more _meditation_.
+ * ~/.abrt/spool and /var/tmp/abrt? needs more _meditation_.
*/
/** Prints basic information about a crash to stdout. */
diff --git a/src/daemon/abrt.conf b/src/daemon/abrt.conf
index d00e84b..59d1831 100644
--- a/src/daemon/abrt.conf
+++ b/src/daemon/abrt.conf
@@ -10,11 +10,11 @@
MaxCrashReportsSize = 1000
# Specify where you want to store coredumps and all files which are needed for
-# reporting. (default:/var/spool/abrt)
+# reporting. (default:/var/tmp/abrt)
#
# Changing dump location could cause problems with SELinux. See man abrt_selinux(8).
#
-#DumpLocation = /var/spool/abrt
+#DumpLocation = /var/tmp/abrt
# If you want to automatically clean the upload directory you have to tweak the
# selinux policy.
diff --git a/src/daemon/abrtd.c b/src/daemon/abrtd.c
index 1418aab..573ec28 100644
--- a/src/daemon/abrtd.c
+++ b/src/daemon/abrtd.c
@@ -45,7 +45,7 @@
/* Daemon initializes, then sits in glib main loop, waiting for events.
* Events can be:
- * - inotify: something new appeared under /var/spool/abrt or /var/spool/abrt-upload
+ * - inotify: something new appeared under /var/tmp/abrt or /var/spool/abrt-upload
* - signal: we got SIGTERM, SIGINT, SIGALRM or SIGCHLD
* - new socket connection
*/
diff --git a/src/hooks/abrt-harvest-vmcore.conf b/src/hooks/abrt-harvest-vmcore.conf
index d2d5413..ed7556f 100644
--- a/src/hooks/abrt-harvest-vmcore.conf
+++ b/src/hooks/abrt-harvest-vmcore.conf
@@ -1,4 +1,4 @@
-# Do you want vmcore to be copied, or moved from /var/crash to /var/spool/abrt?
+# Do you want vmcore to be copied, or moved from /var/crash to /var/tmp/abrt?
# (default is to copy, but it may duplicate way too much data)
CopyVMcore = yes
diff --git a/src/hooks/abrt-harvest-vmcore.in b/src/hooks/abrt-harvest-vmcore.in
index 99022d9..a9ed1a2 100644
--- a/src/hooks/abrt-harvest-vmcore.in
+++ b/src/hooks/abrt-harvest-vmcore.in
@@ -48,7 +48,7 @@ for d in *; do
# to process partially-copied directory.
#
# This is the efficient way:
- #mv -- "$d" "/var/spool/abrt/vmcore-$d.new" || continue
+ #mv -- "$d" "/var/tmp/abrt/vmcore-$d.new" || continue
# ...and this is what selinux forces me to do
# (otherwise files have wrong context and abrtd can't access them):
cp -r --no-preserve=all -- "$d" "$dst.new" || {
diff --git a/src/hooks/abrt-hook-ccpp.c b/src/hooks/abrt-hook-ccpp.c
index 2fd6d6d..99ce5d5 100644
--- a/src/hooks/abrt-hook-ccpp.c
+++ b/src/hooks/abrt-hook-ccpp.c
@@ -626,7 +626,7 @@ int main(int argc, char** argv)
check_free_space(maxsize, g_settings_dump_location);
}
- /* Check /var/spool/abrt/last-ccpp marker, do not dump repeated crashes
+ /* Check /var/tmp/abrt/last-ccpp marker, do not dump repeated crashes
* if they happen too often. Else, write new marker value.
*/
snprintf(path, sizeof(path), "%s/last-ccpp", g_settings_dump_location);
@@ -666,7 +666,7 @@ int main(int argc, char** argv)
}
/* use fsuid instead of uid, so we don't expose any sensitive
- * information of suided app in /var/spool/abrt
+ * information of suided app in /var/tmp/abrt
*/
dd = dd_create(path, fsuid, DEFAULT_DUMP_DIR_MODE);
if (dd)
--
1.8.3.1
10 years, 9 months
[LIBREPORT PATCH] skip the workflow selection if there is only 1 available closes #167
by Jiri Moskovcak
Signed-off-by: Jiri Moskovcak <jmoskovc(a)redhat.com>
---
src/gui-wizard-gtk/main.c | 19 +++++++++++++++++++
src/include/workflow.h | 1 +
src/lib/workflow.c | 13 +++++++++++++
3 files changed, 33 insertions(+)
diff --git a/src/gui-wizard-gtk/main.c b/src/gui-wizard-gtk/main.c
index 3239420..c9f9a0a 100644
--- a/src/gui-wizard-gtk/main.c
+++ b/src/gui-wizard-gtk/main.c
@@ -145,6 +145,25 @@ int main(int argc, char **argv)
load_workflow_config_data(WORKFLOWS_DIR);
+ /* list of workflows applicable to the currently processed problem */
+ GHashTable *possible_workflows = load_workflow_config_data_from_list(
+ list_possible_events_glist(g_dump_dir_name, "workflow"),
+ WORKFLOWS_DIR);
+
+ /* if we have only 1 workflow, we can use the events from it as default */
+ if (g_auto_event_list == NULL && g_hash_table_size(possible_workflows) == 1)
+ {
+ GHashTableIter iter;
+ gpointer key, value;
+
+ g_hash_table_iter_init(&iter, possible_workflows);
+ if (g_hash_table_iter_next(&iter, &key, &value))
+ {
+ VERB1 log("autoselected workflow: '%s'", (char *)key);
+ g_auto_event_list = wf_get_event_names((workflow_t *)value);
+ }
+ }
+
problem_data_reload_from_dump_dir();
create_assistant(expert_mode);
diff --git a/src/include/workflow.h b/src/include/workflow.h
index db8c65d..66bbdaf 100644
--- a/src/include/workflow.h
+++ b/src/include/workflow.h
@@ -35,6 +35,7 @@ void load_workflow_description_from_file(workflow_t *w, const char *filename);
config_item_info_t *workflow_get_config_info(workflow_t *w);
const char *wf_get_name(workflow_t *w);
GList *wf_get_event_list(workflow_t *w);
+GList *wf_get_event_names(workflow_t *w);
const char *wf_get_screen_name(workflow_t *w);
const char *wf_get_description(workflow_t *w);
const char *wf_get_long_desc(workflow_t *w);
diff --git a/src/lib/workflow.c b/src/lib/workflow.c
index 3acf00c..10848c2 100644
--- a/src/lib/workflow.c
+++ b/src/lib/workflow.c
@@ -160,6 +160,19 @@ GList *wf_get_event_list(workflow_t *w)
return w->events;
}
+GList *wf_get_event_names(workflow_t *w)
+{
+ GList *wf_event_list = wf_get_event_list(w);
+ GList *event_names = NULL;
+ while(wf_event_list)
+ {
+ event_names = g_list_append(event_names, xstrdup(ec_get_name(wf_event_list->data)));
+ wf_event_list = g_list_next(wf_event_list);
+ }
+
+ return event_names;
+}
+
const char *wf_get_name(workflow_t *w)
{
return ci_get_name(workflow_get_config_info(w));
--
1.8.3.1
10 years, 9 months
[LIBREPORT PATCH] skip the workflow selection if there is only 1 available closes #167
by Jiri Moskovcak
Signed-off-by: Jiri Moskovcak <jmoskovc(a)redhat.com>
---
src/gui-wizard-gtk/main.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/src/gui-wizard-gtk/main.c b/src/gui-wizard-gtk/main.c
index 3239420..235c4bf 100644
--- a/src/gui-wizard-gtk/main.c
+++ b/src/gui-wizard-gtk/main.c
@@ -145,6 +145,25 @@ int main(int argc, char **argv)
load_workflow_config_data(WORKFLOWS_DIR);
+ /* list of workflows applicable to the currently processed problem */
+ GHashTable *possible_workflows = load_workflow_config_data_from_list(
+ list_possible_events_glist(g_dump_dir_name, "workflow"),
+ WORKFLOWS_DIR);
+
+ /* if we have only 1 workflow, we can use the events from it as default */
+ if (g_auto_event_list == NULL && g_hash_table_size(possible_workflows) == 1)
+ {
+ GHashTableIter iter;
+ gpointer key, value;
+
+ g_hash_table_iter_init(&iter, possible_workflows);
+ if (g_hash_table_iter_next(&iter, &key, &value))
+ {
+ VERB1 log("autoselected workflow: '%s'", (char *)key);
+ g_auto_event_list = wf_get_event_list((workflow_t *)value);
+ }
+ }
+
problem_data_reload_from_dump_dir();
create_assistant(expert_mode);
--
1.8.3.1
10 years, 9 months
[LIBREPORT PATCH 1/2] added missing workflows for Fedora rhbz#866027
by Jiri Moskovcak
Signed-off-by: Jiri Moskovcak <jmoskovc(a)redhat.com>
---
po/POTFILES.in | 6 +++++-
src/workflows/Makefile.am | 12 ++++++++++--
src/workflows/report_fedora.conf | 18 +++++++++++++++++-
src/workflows/workflow_Fedora.xml.in | 13 -------------
src/workflows/workflow_FedoraCCpp.xml.in | 13 +++++++++++++
src/workflows/workflow_FedoraKerneloops.xml.in | 11 +++++++++++
src/workflows/workflow_FedoraPython.xml.in | 11 +++++++++++
src/workflows/workflow_FedoraVmcore.xml.in | 12 ++++++++++++
src/workflows/workflow_FedoraXorg.xml.in | 9 +++++++++
9 files changed, 88 insertions(+), 17 deletions(-)
delete mode 100644 src/workflows/workflow_Fedora.xml.in
create mode 100644 src/workflows/workflow_FedoraCCpp.xml.in
create mode 100644 src/workflows/workflow_FedoraKerneloops.xml.in
create mode 100644 src/workflows/workflow_FedoraPython.xml.in
create mode 100644 src/workflows/workflow_FedoraVmcore.xml.in
create mode 100644 src/workflows/workflow_FedoraXorg.xml.in
diff --git a/po/POTFILES.in b/po/POTFILES.in
index 3f10efe..914f16b 100644
--- a/po/POTFILES.in
+++ b/po/POTFILES.in
@@ -46,7 +46,11 @@ src/plugins/ureport.c
src/report-newt/report-newt.c
src/workflows/workflow_AnacondaFedora.xml.in
src/workflows/workflow_AnacondaUpload.xml.in
-src/workflows/workflow_Fedora.xml.in
+src/workflows/workflow_FedoraCCpp.xml.in
+src/workflows/workflow_FedoraKerneloops.xml.in
+src/workflows/workflow_FedoraPython.xml.in
+src/workflows/workflow_FedoraVmcore.xml.in
+src/workflows/workflow_FedoraXorg.xml.in
src/workflows/workflow_Upload.xml.in
src/workflows/workflow_RHELCCpp.xml.in
src/workflows/workflow_RHELKerneloops.xml.in
diff --git a/src/workflows/Makefile.am b/src/workflows/Makefile.am
index 9e53c8c..0aa8886 100644
--- a/src/workflows/Makefile.am
+++ b/src/workflows/Makefile.am
@@ -1,7 +1,11 @@
workflowsdir = $(WORKFLOWS_DIR)
dist_workflows_DATA = \
- workflow_Fedora.xml \
+ workflow_FedoraCCpp.xml \
+ workflow_FedoraKerneloops.xml \
+ workflow_FedoraPython.xml \
+ workflow_FedoraVmcore.xml \
+ workflow_FedoraXorg.xml \
workflow_Upload.xml \
workflow_RHELCCpp.xml \
workflow_RHELKerneloops.xml \
@@ -29,7 +33,11 @@ endif
@INTLTOOL_XML_RULE@
EXTRA_DIST = \
- workflow_Fedora.xml.in \
+ workflow_FedoraCCpp.xml.in \
+ workflow_FedoraKerneloops.xml.in \
+ workflow_FedoraPython.xml.in \
+ workflow_FedoraVmcore.xml.in \
+ workflow_FedoraXorg.xml.in \
workflow_Upload.xml.in \
workflow_RHELCCpp.xml.in \
workflow_RHELKerneloops.xml.in \
diff --git a/src/workflows/report_fedora.conf b/src/workflows/report_fedora.conf
index 8c58f12..b5a49e2 100644
--- a/src/workflows/report_fedora.conf
+++ b/src/workflows/report_fedora.conf
@@ -1,3 +1,19 @@
-EVENT=workflow_Fedora analyzer=CCpp
+EVENT=workflow_FedoraCCpp analyzer=CCpp
+# this is just a meta event which consists of other events
+# the list is defined in the xml file
+
+EVENT=workflow_FedoraPython analyzer=Python
+# this is just a meta event which consists of other events
+# the list is defined in the xml file
+
+EVENT=workflow_FedoraKerneloops analyzer=Kerneloops
+# this is just a meta event which consists of other events
+# the list is defined in the xml file
+
+EVENT=workflow_FedoraVmcore analyzer=vmcore
+# this is just a meta event which consists of other events
+# the list is defined in the xml file
+
+EVENT=workflow_FedoraXorg analyzer=xorg
# this is just a meta event which consists of other events
# the list is defined in the xml file
diff --git a/src/workflows/workflow_Fedora.xml.in b/src/workflows/workflow_Fedora.xml.in
deleted file mode 100644
index f9df177..0000000
--- a/src/workflows/workflow_Fedora.xml.in
+++ /dev/null
@@ -1,13 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" ?>
-<workflow>
- <_name>Report to Fedora</_name>
- <_description>Process the report using the Fedora infrastructure</_description>
-
- <events>
- <event>report_uReport</event>
- <event>collect_*</event>
- <event>analyze_CCpp</event>
- <event>report_Bugzilla</event>
- <event>post_report</event>
- </events>
-</workflow>
diff --git a/src/workflows/workflow_FedoraCCpp.xml.in b/src/workflows/workflow_FedoraCCpp.xml.in
new file mode 100644
index 0000000..b48d25a
--- /dev/null
+++ b/src/workflows/workflow_FedoraCCpp.xml.in
@@ -0,0 +1,13 @@
+<?xml version="1.0" encoding="UTF-8" ?>
+<workflow>
+ <_name>Report to Fedora</_name>
+ <_description>Process the C/C++ crash using the Fedora infrastructure</_description>
+
+ <events>
+ <event>report_uReport</event>
+ <event>collect_*</event>
+ <event>analyze_CCpp</event>
+ <event>report_Bugzilla</event>
+ <event>post_report</event>
+ </events>
+</workflow>
diff --git a/src/workflows/workflow_FedoraKerneloops.xml.in b/src/workflows/workflow_FedoraKerneloops.xml.in
new file mode 100644
index 0000000..a8b4a28
--- /dev/null
+++ b/src/workflows/workflow_FedoraKerneloops.xml.in
@@ -0,0 +1,11 @@
+<?xml version="1.0" encoding="UTF-8" ?>
+<workflow>
+ <_name>Report to Fedora</_name>
+ <_description>Process the kerneloops using the Fedora infrastructure</_description>
+
+ <events>
+ <event>report_uReport</event>
+ <event>collect_*</event>
+ <event>report_Bugzilla</event>
+ </events>
+</workflow>
\ No newline at end of file
diff --git a/src/workflows/workflow_FedoraPython.xml.in b/src/workflows/workflow_FedoraPython.xml.in
new file mode 100644
index 0000000..81e0fca
--- /dev/null
+++ b/src/workflows/workflow_FedoraPython.xml.in
@@ -0,0 +1,11 @@
+<?xml version="1.0" encoding="UTF-8" ?>
+<workflow>
+ <_name>Report to Fedora</_name>
+ <_description>Process the python exception using the Fedora infrastructure</_description>
+
+ <events>
+ <event>report_uReport</event>
+ <event>collect_*</event>
+ <event>report_Bugzilla</event>
+ </events>
+</workflow>
diff --git a/src/workflows/workflow_FedoraVmcore.xml.in b/src/workflows/workflow_FedoraVmcore.xml.in
new file mode 100644
index 0000000..a6abb6a
--- /dev/null
+++ b/src/workflows/workflow_FedoraVmcore.xml.in
@@ -0,0 +1,12 @@
+<?xml version="1.0" encoding="UTF-8" ?>
+<workflow>
+ <_name>Report to Fedora</_name>
+ <_description>Process the kernel crash using the Fedora infrastructure</_description>
+
+ <events>
+ <event>analyze_VMcore</event>
+ <event>report_uReport</event>
+ <event>collect_*</event>
+ <event>report_Bugzilla</event>
+ </events>
+</workflow>
diff --git a/src/workflows/workflow_FedoraXorg.xml.in b/src/workflows/workflow_FedoraXorg.xml.in
new file mode 100644
index 0000000..d796bae
--- /dev/null
+++ b/src/workflows/workflow_FedoraXorg.xml.in
@@ -0,0 +1,9 @@
+<?xml version="1.0" encoding="UTF-8" ?>
+<workflow>
+ <_name>Report to Fedora</_name>
+ <_description>Process the X Server problem using the Fedora infrastructure</_description>
+
+ <events>
+ <event>report_Bugzilla</event>
+ </events>
+</workflow>
--
1.8.3.1
10 years, 9 months
[ABRT PATCH] stop using the hardcoded event list, use workflows instead rhbz#866027
by Jiri Moskovcak
Signed-off-by: Jiri Moskovcak <jmoskovc(a)redhat.com>
---
src/plugins/ccpp_event.conf | 2 +-
src/plugins/koops_event.conf | 2 +-
src/plugins/python_event.conf | 2 +-
src/plugins/vmcore_event.conf | 2 +-
src/plugins/xorg_event.conf | 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/plugins/ccpp_event.conf b/src/plugins/ccpp_event.conf
index aa8cdb3..1dacbeb 100644
--- a/src/plugins/ccpp_event.conf
+++ b/src/plugins/ccpp_event.conf
@@ -90,7 +90,7 @@ EVENT=analyze_CCpp analyzer=CCpp
# Reporting of C/Cpp problems
EVENT=report-gui analyzer=CCpp
- report-gtk -e report_uReport -e analyze_CCpp -e "collect_*" -e report_Bugzilla -e post_report -- "$DUMP_DIR"
+ report-gtk -- "$DUMP_DIR"
EVENT=report-cli analyzer=CCpp
report-cli -e report_uReport -e analyze_CCpp -e report_Bugzilla -e post_report -- "$DUMP_DIR"
diff --git a/src/plugins/koops_event.conf b/src/plugins/koops_event.conf
index 9966775..78f8f4a 100644
--- a/src/plugins/koops_event.conf
+++ b/src/plugins/koops_event.conf
@@ -30,7 +30,7 @@ EVENT=post_report analyzer=Kerneloops
# Automatic/simple GUI-based kernel oopses reporting will do this:
EVENT=report-gui analyzer=Kerneloops
- report-gtk -e report_uReport -e "collect_*" -e report_Bugzilla -e post_report -- "$DUMP_DIR"
+ report-gtk -- "$DUMP_DIR"
EVENT=report-cli analyzer=Kerneloops
report-cli -e report_uReport -e report_Bugzilla -e post_report -- "$DUMP_DIR"
diff --git a/src/plugins/python_event.conf b/src/plugins/python_event.conf
index 3a45373..f211b30 100644
--- a/src/plugins/python_event.conf
+++ b/src/plugins/python_event.conf
@@ -25,7 +25,7 @@ EVENT=post_report analyzer=Python
# Reporting of python exceptions
EVENT=report-gui analyzer=Python component!=anaconda
- report-gtk -e report_uReport -e "collect_*" -e report_Bugzilla -e post_report -- "$DUMP_DIR"
+ report-gtk -- "$DUMP_DIR"
EVENT=report-cli analyzer=Python component!=anaconda
report-cli -e report_uReport -e report_Bugzilla -e post_report -- "$DUMP_DIR"
diff --git a/src/plugins/vmcore_event.conf b/src/plugins/vmcore_event.conf
index 5d2d099..68e1d24 100644
--- a/src/plugins/vmcore_event.conf
+++ b/src/plugins/vmcore_event.conf
@@ -24,7 +24,7 @@ EVENT=report_uReport analyzer=vmcore
/usr/libexec/abrt-action-ureport
EVENT=report-gui analyzer=vmcore
- report-gtk -e analyze_VMcore -e report_uReport -e "collect_*" -e report_Bugzilla -e post_report -- "$DUMP_DIR"
+ report-gtk -- "$DUMP_DIR"
EVENT=report-cli analyzer=vmcore
report-cli -e analyze_VMcore -e report_uReport -e report_Bugzilla -e post_report -- "$DUMP_DIR"
diff --git a/src/plugins/xorg_event.conf b/src/plugins/xorg_event.conf
index 71ca171..1bd7617 100644
--- a/src/plugins/xorg_event.conf
+++ b/src/plugins/xorg_event.conf
@@ -22,7 +22,7 @@ EVENT=report_Bugzilla analyzer=xorg
# Automatic/simple GUI-based xorg problems reporting will do this:
EVENT=report-gui analyzer=xorg
- report-gtk -e report_Bugzilla -- "$DUMP_DIR"
+ report-gtk -- "$DUMP_DIR"
EVENT=report-cli analyzer=xorg
report-cli -e report_Bugzilla -- "$DUMP_DIR"
--
1.8.3.1
10 years, 9 months