Tickets for the bugs can be found here:
https://fedorahosted.org/abrt/query?status=new&status=assigned&statu...
- please take the ticket (re-assing to yourself) if you're working on it.
Thank you, Jirka
On 03/17/2011 03:47 PM, Denys Vlasenko wrote:
*** warning: google translated text ahead ***
On 03/16/2011 12:24 PM, Michal Nowak wrote:
- by testing kerneloops I stumbled upon this: When the
/ Var / log / messages add "cut_here.test" Git out, so ABRT loops and locks and unlocks the directory.
Likely already fixed: can't reproduce.
- if it fails authentication when analyzed in an attempt to Retrace
Server (GUI) and Wizard allows continue.
Not fixed yet.
- several times happened to me, Logger didn't write to the file
/var/log/abrt.log (in the GUI, everything seemed OK, but the file There.
Changed default path to /tmp/abrt.log
- When writing oops1.test to /var/log/messages OOPS
is found, but when it is erased, it is found again, around there Stop missing some (or not there is more ...).
Found the problem, fixed, tested.
- "Enabled = no" in CCpp.conf (and elsewhere) does not work
I propose to remove all old PLUGIN.{conf,glade} files
- I was looking into various config files in /etc/abrt and it seems
to me
Logpath of the logger is defined by at least three places, so do not know which is the "lead". It's confusing.
I propose to remove all old PLUGIN.{conf,glade} files
- 'cmdline' at the Python exception is in review with the GUI part is
empty.
I don't see it. How can I reproduce this?
- User can not write to /var/log/abrt.log, a change
ABRT than 1.1 and it seems to me that the logger is not working for
him
(Permission denied).
Fixed by using /tmp/abrt.log as default - see above.
- Support for mailx is not complete, there is missing some events
that
to the plugin from bringing.
Yes, we need to test / maybe_fix / document mailx
- When the Enable sosreport abrt_event.conf, the user does not
Rights to a file and fails to do (at least through the GUI) The problem anywhere zahlasit (Permission denied on sosreport.tar).
Should be fixed by now. Verifying... yes, works for me.
14), 'dot' in the first column of the GUI for the user never changes
from
Red to green, even when the Bug Report Broken. To root it Works.
This is the same thing as "doesn't detect changes in the dir", so will be fixed when that problem is fixed. Any takers?
- `abrt-cli-l` does not work for users (root is OK), they do not
Nothing - no reporting, no nereportovane. `Abrt-cli-l-f` Displays All. 16) in the cli-abrt the user is not happening, no analysis, but the
CLI
Problem in the rest left without a backtrace with corefile. BZ #
687916
I'm working on this.
- When I run you abrtd -dvvv manually, after what
Take care of the crash, spits GLib-CRITICAL and some problems with Hash tables, this is what it sounds coming out of the process abrtd.
Bug found and fixed.
- You are not aware of the kernel oops in 1.1 so ABRT
I think it was, but maybe a mistake.
Jiri works on this.
- in the Whiteboard field contains an empty hash BZ: abrt_hash:
(null)
Which would be a problem for checking duplicates.
How to reproduce this?