Wow, what a list! :) Will try to answer what I can and CCing the rest of the team so they can help with answers.
On 03/16/2011 12:24 PM, Michal Nowak wrote:
Cau,
pri adaptaci fedoriho test daye na F15 a ABRT2 jsem narazil na nekolik problemu/odlisnosti od verze 1.1.
Testoval jsem to vcerejsim dopolednim buildu, takze mozna neco uz bude opravene.
- strace je na blacklistu, ale nenapada me proc. Jestli to
bylo kvuli tomu, ze kdyz spadl program, ktery byl tracovany, tak strace se ukoncila s taky s coredumpem, tak mu prijde, ze tohle chovani se zmenilo: `strace sleep 3m`; kdyz sundam sleep, tak ABRT zachyti crash v coreutils.
- don't remember, but it was because of the strace maintainer wanted it
- Pri testovani kerneloops jsem narazil na tohle: Kdyz se do
/var/log/messages prida "cut_here.test" z Gitu, tak se ABRT zacykli a zamyka a odemyka adresar.
- sounds like a bug, need to test it
- Kdyz selze autentizace pri pokusu o analyzovani v Retrace
Serveru (v GUI), tak wizard dovoli pokracovani.
- wizard shouldn't allow user to continue if analyze action finishes with exit code != 0
- Nekolikrat se mi stalo, ze Logger nezalogoval do
/var/log/abrt.log (v GUI se vsechno zdalo OK, ale soubor neexistoval.
- the default path is wrong and user doesn't have permission to write there..
- Kdyz se da oops1.test do /var/log/messages, tak se OOPS
najde, kdyz se ale pak smaze, tak se zase "najde", asi tam chybi nejaka zarazka (nebo jich tam je vic...).
- hm, kerneloops plugin should use some marker and shouldn't find the same crash again..
- Seznam problemu v GUI se neaktualizuje automaticky. Napr.
kdyz mam otevrene GUI a prijde nejaky pak, tak se to v novem GUI neprojevi, ve starem jo.
- known bug, gui needs to watch the dump directories, it's in our TODO
- "Enabled = no" v CCpp.conf (i jinde) nefunguje, jak bych
cekal, crashe se porad nachazeji.
- this is obsolete and should be removed from the config files
- Koukal jsem do ruznych konfiguraku v /etc/abrt a prijde mi,
ze LogPath u Loggeru je definovana aspon na trech mistech, tak nevim, ktere je to "hlavni". Je to matouci.
- yes, we should have only one default config and we should provide some docs about the other non default places...
- 'cmdline' u pythoni vyjimky je v review casti u GUI prazdna.
- shouldn't be, that's probably a bug
- Uzivatel nemuze zapisovat do /var/log/abrt.log, coz je zmena
oproti ABRT 1.1 a prijde mi, ze Logger pak pro nej vubec nefunguje (Permission denied).
- this is actually a correct behaviour, only the path shouldn't be /var/log/abrt.log
- Podpora pro Mailx neni kompletni, chybi tam nejaky event, ktery
by ten plugin zprovoznoval.
- yes, Mailx needs an event config file
- Kdyz se povoli sosreport v abrt_event.conf, tak uzivatel nema
prava k takovemu souboru a nepodari se mu (minimalne pres GUI) ten problem nikam zahlasit (Permission denied na sosreport.tar).
- known bug
- Edit> Preferences nic nedela.
- I know, this is just a stub and will be removed in Fedora build
- "Tecka" v prvnim sloupci GUI se u uzivatele nikdy nezmeni z
cervene na zelenou, i kdyz je bug zareportovan. Pro roota to funguje.
- sounds like a bug
- `abrt-cli -l` pro uzivatele nefunguje (root je OK), nezobrazi
nic - ani reportovane, ani nereportovane. `abrt-cli -l -f` zobrazi vsechny.
- sounds like a bug, do you have any crashes owned by the user who runs the abrt-cli?
- V abrt-cli u uzivatele se nedeje zadna analyza, ale CLI ten
problem v klidu odesle bez backtrace za to s corefile. BZ#687916
- bug
- Bugzilli plug-in se uz nepta na login/heslo, kdyz je ve
wizardu vybrany, reportovani tak v poslednim okne zdechne.
- known bug, it's in our TODO
- Edit> Plugin> BZ neuklada do g-keyringu.
- this should work since Monday 14.3.2011 ;)
- V GUI je dvakrat akcelerator pro "O" (Open a Online Help).
Chova se to pak divne pri "Alt-O". Co takhle "Online _Help"?
- will change it
- Kdyz si pustim `abrtd -dvvv` manualne, tak po tom, co se
postara o crash, vyplivne GLib-CRITICAL a nejaky problem s hashovaci tabulkou, podle te hlasky to leze z procesu abrtd.
- sounds like a bug
- Uzivatel neni upozornen na kernel OOPS, v ABRT 1.1 to tak
myslim bylo, ale mozna se spletu.
- sounds like a bug we need to test oopses more
- Whiteboard pole v BZ obsahuje prazdny hash: abrt_hash:(null)
Coz by byl problem pro kontrolu duplicity.
- that sounds like a bug in bz plugin
- btw, it would be much easier if you write in English and send emails like this directly to our ml ;)
Thank you, Jirka
On Wed, 2011-03-16 at 12:45 +0100, Jiri Moskovcak wrote:
- strace je na blacklistu, ale nenapada me proc. Jestli to
bylo kvuli tomu, ze kdyz spadl program, ktery byl tracovany, tak strace se ukoncila s taky s coredumpem, tak mu prijde, ze tohle chovani se zmenilo: `strace sleep 3m`; kdyz sundam sleep, tak ABRT zachyti crash v coreutils.
- don't remember, but it was because of the strace maintainer wanted it
Strace kills itself with the same signal as the straced process, in order to propagate correct exitcode to the parent.
Imagine "strace buggy_process_that SIGSEGVs". We don't want to report "strace died with SIGSEGV!" in this case.
----- Original Message -----
On Wed, 2011-03-16 at 12:45 +0100, Jiri Moskovcak wrote:
- strace je na blacklistu, ale nenapada me proc. Jestli to
bylo kvuli tomu, ze kdyz spadl program, ktery byl tracovany, tak strace se ukoncila s taky s coredumpem, tak mu prijde, ze tohle chovani se zmenilo: `strace sleep 3m`; kdyz sundam sleep, tak ABRT zachyti crash v coreutils.
- don't remember, but it was because of the strace maintainer wanted
it
Strace kills itself with the same signal as the straced process, in order to propagate correct exitcode to the parent.
Imagine "strace buggy_process_that SIGSEGVs". We don't want to report "strace died with SIGSEGV!" in this case.
You are right. strace should remain blacklisted.
-- vda
Michal
----- Original Message -----
Wow, what a list! :) Will try to answer what I can and CCing the rest of the team so they can help with answers.
- Uzivatel nemuze zapisovat do /var/log/abrt.log, coz je zmena
oproti ABRT 1.1 a prijde mi, ze Logger pak pro nej vubec nefunguje (Permission denied).
- this is actually a correct behaviour, only the path shouldn't be
/var/log/abrt.log
Perhaps Logger should use some place in ~/.abrt/ when started by user? Dunno; way confused from the new version :).
- `abrt-cli -l` pro uzivatele nefunguje (root je OK), nezobrazi
nic - ani reportovane, ani nereportovane. `abrt-cli -l -f` zobrazi vsechny.
- sounds like a bug, do you have any crashes owned by the user who
runs the abrt-cli?
Indeed I have. Have a fresh crash: GUI shows it; `abrt-cli -l` does not; `abrt-cli -l -f` shows it. I believe `abrt-cli -l` should show me the new crash.
- Edit> Plugin> BZ neuklada do g-keyringu.
- this should work since Monday 14.3.2011 ;)
Right. Works for me as well.
- btw, it would be much easier if you write in English and send emails
like this directly to our ml ;)
Sure will do next time.
What about those "probably bugs"? Should I give you bug somewhere?
Thank you, Jirka
Michal
On 03/16/2011 04:05 PM, Michal Nowak wrote:
----- Original Message -----
Wow, what a list! :) Will try to answer what I can and CCing the rest of the team so they can help with answers.
- Uzivatel nemuze zapisovat do /var/log/abrt.log, coz je zmena
oproti ABRT 1.1 a prijde mi, ze Logger pak pro nej vubec nefunguje (Permission denied).
- this is actually a correct behaviour, only the path shouldn't be
/var/log/abrt.log
Perhaps Logger should use some place in ~/.abrt/ when started by user? Dunno; way confused from the new version :).
- yes, we need to change this
- `abrt-cli -l` pro uzivatele nefunguje (root je OK), nezobrazi
nic - ani reportovane, ani nereportovane. `abrt-cli -l -f` zobrazi vsechny.
- sounds like a bug, do you have any crashes owned by the user who
runs the abrt-cli?
Indeed I have. Have a fresh crash: GUI shows it; `abrt-cli -l` does not; `abrt-cli -l -f` shows it. I believe `abrt-cli -l` should show me the new crash.
- yes, it should, it's a bug
- Edit> Plugin> BZ neuklada do g-keyringu.
- this should work since Monday 14.3.2011 ;)
Right. Works for me as well.
- btw, it would be much easier if you write in English and send emails
like this directly to our ml ;)
Sure will do next time.
What about those "probably bugs"? Should I give you bug somewhere?
- yes please, create a ticket in rh bugzilla (btw, the kerneloops looping should be fixed ;)
Thank you, Jirka
Michal _______________________________________________ Crash-catcher mailing list Crash-catcher@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/crash-catcher
*** 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?
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
- agreed, will remove it over weekend
- 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
- will fix this
- 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?
- I will if I finish with the koops fix, but if anyone can take a look at it sooner I won't fight ;)
- `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?
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?
----- Original Message -----
- in the Whiteboard field contains an empty hash BZ: abrt_hash:
(null)
Which would be a problem for checking duplicates.
How to reproduce this?
File random bug to Bugzilla and see what's in the Whiteboard, I can see: abrt_hash:(null)
https://bugzilla.redhat.com/show_bug.cgi?id=688618
Michal
crash-catcher@lists.fedorahosted.org