On Thu, 2011-10-20 at 12:31 +0200, Martin Milata wrote:
Doesn't really make sense, as it is always path to the python
executable. bz#741255
I cannot agree with you. As I see the purpose of the
"executable:
SOMETHING" item in the bugreport it's used to differentiate between
running /usr/bin/vim and /usr/bin/vimdiff (which is a symlink to
the /usr/bin/vim). According to the value of argv[0] vim decides how it
should run. And you can do exactly the same in Python and sys.argv[0].
And even if this item should have been removed this wouldn't have been
the right way to do it -- let handlers query and pass this info and then
remove it somewhere else?
If you look at the
https://bugzilla.redhat.com/show_bug.cgi?id=747562
which is a testing bugreport for my python-meh and libreport patches
"executable: /usr/sbin/firstboot" is redundant here. And I think the
righ way how to report this info is to use "cmdline: SOMETHING"
containing (in case of python script):
"cmdline: PATH_TO_PYTHON PYTHON_OPTIONS EXECUTABLE EXECUTABLE_OPTIONS"
for example: "cmdline: /usr/bin/python -t -Q /usr/bin/phatch
halved.phatch"
Which gives much more information (e.g. python 2 vs. python 3?) and
includes also the "executable".
I don't think it would resolve bz#741255. But this should be solved
somewhere else.
--
Vratislav Podzimek
---
src/include/problem_data.h | 3 +++
src/lib/problem_data.c | 5 +++++
src/report-python/problem_data.c | 8 ++++++++
3 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/src/include/problem_data.h b/src/include/problem_data.h
index 14d1240..87037a2 100644
--- a/src/include/problem_data.h
+++ b/src/include/problem_data.h
@@ -74,6 +74,9 @@ void add_to_problem_data(problem_data_t *problem_data,
const char *name,
const char *content);
+/* Removes item from problem data */
+void remove_from_problem_data(problem_data_t *problem_data, const char *key);
+
static inline struct problem_item *get_problem_data_item_or_NULL(problem_data_t
*problem_data, const char *key)
{
return (struct problem_item *)g_hash_table_lookup(problem_data, key);
diff --git a/src/lib/problem_data.c b/src/lib/problem_data.c
index 2ddff86..7d85709 100644
--- a/src/lib/problem_data.c
+++ b/src/lib/problem_data.c
@@ -155,6 +155,11 @@ void add_to_problem_data(problem_data_t *problem_data,
add_to_problem_data_ext(problem_data, name, content, CD_FLAG_TXT +
CD_FLAG_ISNOTEDITABLE);
}
+void remove_from_problem_data(problem_data_t *problem_data, const char *key)
+{
+ g_hash_table_remove(problem_data, key);
+}
+
const char *get_problem_item_content_or_die(problem_data_t *problem_data, const char
*key)
{
struct problem_item *item = get_problem_data_item_or_NULL(problem_data, key);
diff --git a/src/report-python/problem_data.c b/src/report-python/problem_data.c
index 9067dea..8b4088d 100644
--- a/src/report-python/problem_data.c
+++ b/src/report-python/problem_data.c
@@ -115,8 +115,16 @@ static PyObject *p_create_dump_dir_from_problem_data(PyObject
*pself, PyObject *
static PyObject *p_add_basics_to_problem_data(PyObject *pself, PyObject *always_null)
{
p_problem_data *self = (p_problem_data*)pself;
+ int have_executable = (get_problem_data_item_or_NULL(self->cd,
"executable") != NULL);
+
add_basics_to_problem_data(self->cd);
+ /* Workaround - the executable item will always be /usr/bin/python, which is
useless. */
+ if (!have_executable)
+ {
+ remove_from_problem_data(self->cd, "executable");
+ }
+
Py_RETURN_NONE;
}