Bug 561218 - abrt-gui unable to display or report kerneloops
Summary: abrt-gui unable to display or report kerneloops
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: abrt
Version: 12
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Jiri Moskovcak
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-02-03 03:16 UTC by Ralf Corsepius
Modified: 2015-02-01 22:50 UTC (History)
10 users (show)

Fixed In Version: abrt-1.0.7-1.fc12
Clone Of:
Environment:
Last Closed: 2010-02-23 05:39:52 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Screenshot of the "Bug reporting form" (41.11 KB, image/png)
2010-02-03 03:19 UTC, Ralf Corsepius
no flags Details

Description Ralf Corsepius 2010-02-03 03:16:26 UTC
Description of problem:
I am facing a kerneloops on a remote machine.

When loggin into this machine via a cascade of "ssh -X"'s, 
abrt-gui displays the kerneloops.
When trying to report this kerneloops, the "bug reporting form" stays empty and doesn't allow me to send it.

Version-Release number of selected component (if applicable):
abrt-1.0.4-1.fc12.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Login into a remote machine via ssh -X.
2. run "abrt-gui", press <Report> to report.
3.
  
Actual results:
* "Bug reporting form" pops up, but stays empty and doesn't allow to one to send.
* When pressing "Log" inside of the "Bug reporting form", an empty window pops up, which only displays a "Close" button,

Expected results:
Being able to do something useful, e.g. to store a report to file, such that it could be transferred and mailed/bugzilla'ed.

Additional info:
* The user, I am logging into this machines doesn't have a valid mail account on this machine.

* I meanwhile am convinced that abrt was prematurely unleashed to Fedora 12. 
It should be made strictly optional and not be installed by default in FC13.

Comment 1 Ralf Corsepius 2010-02-03 03:19:07 UTC
Created attachment 388428 [details]
Screenshot of the "Bug reporting form"

Note:
* "Send" button greyed out, no possibilty to "save" report to file
* No readable contents inside of the form.

Comment 2 Denys Vlasenko 2010-02-03 11:01:35 UTC
"Send" button is grey because you did not check "I agree to submit this backtrace..." checkbox. This isn't a bug.

"Invisible backtrace" isn't invisible, it's just empty.
If you click on it, you will likely discover that you can actually type some text there. This is a bug - the oops text should be there. It is fixed in git and will be fixed in future releases.

Comment 3 Ralf Corsepius 2010-02-03 11:34:06 UTC
(In reply to comment #2)
> "Send" button is grey because you did not check "I agree to submit this
> backtrace..." checkbox. This isn't a bug.

Stop cheating to yourself: This is a usability bug!

> "Invisible backtrace" isn't invisible, it's just empty.
> If you click on it, you will likely discover that you can actually type some
> text there. This is a bug - the oops text should be there. It is fixed in git
> and will be fixed in future releases.    
Reopening - Whether some arbitrary upstream might have fixed it inside of their VCS is not of any importance.

"FIXED NEXTRELEASE" means the bug has not been fixed in the currently released version and is presented to users.

Comment 4 Denys Vlasenko 2010-02-03 12:17:24 UTC
The bugzilla is not the place to vent your anger. It's a database of TODOs. Oops display problem *is* fixed. Why this bug should stay open when there is nothing more for developers to do to fix it?

Comment 5 Jiri Moskovcak 2010-02-03 21:23:27 UTC
abrt 1.0.6 has been submitted for testing.

Comment 6 Ralf Corsepius 2010-02-04 04:11:28 UTC
(In reply to comment #4)
> The bugzilla is not the place to vent your anger.
Apparently you are not interested in feedback or at least not able to accept negative feedback.

> It's a database of TODOs.
> Oops display problem *is* fixed. Why this bug should stay open when there is
> nothing more for developers to do to fix it?    
BZs should be closed when they are supposed to be fixed in released packages of the distro.

I seriously advise you to separate your position as "upstream" and "Fedora package maintainer" as well as to separate your position as "RH employee" and "Fedora contributor".

Bluntly speaking, the way ABRT has been introduced in Fedora and is being maintained in Fedora, to me is a case of "RH or @RH's abusing the Fedora community".

Comment 7 Jiri Moskovcak 2010-02-04 12:01:32 UTC
(In reply to comment #6)
> Bluntly speaking, the way ABRT has been introduced in Fedora and is being
> maintained in Fedora, to me is a case of "RH or @RH's abusing the Fedora
> community".

In what sense? That we help non-technical users with reporting bugs? Yes, this probably generates more work for developers, but that's how it works, if you have some idea, how it would work better, then please don't hesitate and share it with us and if you just against it in general, then please write to appropriate mailing list and we can discuss your reasons more public.

Jirka

Comment 8 Ralf Corsepius 2010-02-04 13:23:31 UTC
(In reply to comment #7)
> (In reply to comment #6)
> > Bluntly speaking, the way ABRT has been introduced in Fedora and is being
> > maintained in Fedora, to me is a case of "RH or @RH's abusing the Fedora
> > community".

> In what sense?
You are abusing the community Fedora as your Guinea pigs to iron out the poor shape of your work. And when being told that your Guinean pigs find your works unusable and immature your are illegitiately start to close bugs.

Also, I feel, if you weren't @RH and working on ABRT under RH direction, this package hardly would have made it into Fedora and even less into default set of packages. I feel this case to be a case of RH having abused their powers.

> That we help non-technical users with reporting bugs?
Exactly this is what you are not doing. Your GUI so far has been "plain simply unusable" - It's far from being end-user ready, and ever further away from being suitable for a non-technical users.

From  maintainer's POV, all I can add:
The concepts behind ABRT only work in random situation, c.f. bugs owned by root, bogues reports when interpreters of scripted languages crash, /var/log/abrt.log system wide readable, /var/cache/abort flowing over, empty kerneloops, silly handling of 3rd party repos...

> then please write to
> appropriate mailing list and we can discuss your reasons more public.
You've nagged me enough to not be interested in any further contact with you and your works.

Comment 9 Denys Vlasenko 2010-02-04 14:11:34 UTC
(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #6)
> > > Bluntly speaking, the way ABRT has been introduced in Fedora and is being
> > > maintained in Fedora, to me is a case of "RH or @RH's abusing the Fedora
> > > community".
> > In what sense?
> You are abusing the community Fedora as your Guinea pigs to iron out the poor
> shape of your work. And when being told that your Guinean pigs find your works
> unusable and immature your are illegitiately start to close bugs.

No, I closed the bug because there is nothing more to do for me to fix it, this particular bug is fixed in git already.

If you are asking me to not close bugs until fix hits update repos, it is ok with me - I will set them to MODIFIED, not CLOSED. Is this fine with you?

> Also, I feel, if you weren't @RH and working on ABRT under RH direction, this
> package hardly would have made it into Fedora and even less into default set of
> packages. I feel this case to be a case of RH having abused their powers.

Maybe. I personally wasn't involved in making this decision. If I was, I would like to let abrt mature in rawhide sometime longer.

> > That we help non-technical users with reporting bugs?
> Exactly this is what you are not doing. Your GUI so far has been "plain simply
> unusable" - It's far from being end-user ready, and ever further away from
> being suitable for a non-technical users.
> 
> From  maintainer's POV, all I can add:
> The concepts behind ABRT only work in random situation, c.f. bugs owned by
> root,

didn't understand this part

> bogues reports when interpreters of scripted languages crash,

fixed

> /var/log/abrt.log system wide readable,

fixed

> /var/cache/abort flowing over,

fixed

> empty kerneloops,

fixed

> silly handling of 3rd party repos...

didn't fully understand this part, but it is known that this area needs much thought and work

> > then please write to
> > appropriate mailing list and we can discuss your reasons more public.
> You've nagged me enough to not be interested in any further contact with you
> and your works.    

We love you too.

Comment 10 Ralf Corsepius 2010-02-04 14:30:06 UTC
(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > (In reply to comment #6)
> > > > Bluntly speaking, the way ABRT has been introduced in Fedora and is being
> > > > maintained in Fedora, to me is a case of "RH or @RH's abusing the Fedora
> > > > community".
> > > In what sense?
> > You are abusing the community Fedora as your Guinea pigs to iron out the poor
> > shape of your work. And when being told that your Guinean pigs find your works
> > unusable and immature your are illegitiately start to close bugs.
> 
> No, I closed the bug because there is nothing more to do for me to fix it, this
> particular bug is fixed in git already.
What clue stick does it take until you finally understand?

Whatever you commit to your devel-git is IRRELEVANT!!!!

What matters is your "fixed package" to land in Fedora/updates.

This is NOT WHAT YOU DID! YOU did NOT FIX this bug IN FEDORA.


> Maybe. I personally wasn't involved in making this decision. If I was, I would
> like to let abrt mature in rawhide sometime longer.
Do you realize how silly, infantile and irresponsible this attitude is?

> We love you too.    
Get grown up, kid!

Comment 11 Michal Schmidt 2010-02-15 11:03:16 UTC
"NEXTRELEASE" and "UPSTREAM" are clearly allowed bug resolutions by the Fedora Bug Status Workflow documentation:
https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow

The "MODIFIED" state also has a precisely defined meaning - it should be only used if the fix is already committed in Fedora CVS.

Comment 12 Ralf Corsepius 2010-02-15 12:02:19 UTC
(In reply to comment #11)
> "NEXTRELEASE" and "UPSTREAM" are clearly allowed bug resolutions by the Fedora
> Bug Status Workflow documentation:
> https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow
Faulty management decisions doesn't make the defects in your workflows any better.


Fact is: "FIXED NEXTRELEASE" and "FIXED UPSTREAMS" imply you to prematurely close BZ's without having fixed YOUR BUGS in a released product but YOU to continue exposing users to the BUGS.

From a user's perspective this qualifies you to cheating about the shape of your product. You openly lie at them "It is fixed", while it actually is not fixed.

Comment 13 Fedora Update System 2010-02-15 14:08:26 UTC
abrt-1.0.7-1.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/abrt-1.0.7-1.fc12

Comment 14 Michal Schmidt 2010-02-15 14:24:54 UTC
(In reply to comment #12)
> Faulty management decisions doesn't make the defects in your workflows any
> better.

If you think these resolutions should not be used, raise it with BugZappers or FESCo.

> Fact is: "FIXED NEXTRELEASE" and "FIXED UPSTREAMS" imply you to prematurely
> close BZ's without having fixed YOUR BUGS in a released product but YOU to
> continue exposing users to the BUGS.

I am not a big fan of "CLOSED UPSTREAM" either, but in the case of the abrt package which receives about 2 updates every month, its use is tolerable, because the fixed package can be expected to arrive in a reasonable time frame.

> From a user's perspective this qualifies you to cheating about the shape of
> your product. You openly lie at them "It is fixed", while it actually is not
> fixed.    

I disagree fully with the notion that using "CLOSED NEXTRELEASE" or "CLOSED UPSTREAM" is lying or cheating. You're just misinterpreting the meaning of these resolutions. And Bugzilla is not meant to be a product shape measurement tool.

Comment 15 Ralf Corsepius 2010-02-15 14:50:16 UTC
(In reply to comment #14)

> > From a user's perspective this qualifies you to cheating about the shape of
> > your product. You openly lie at them "It is fixed", while it actually is not
> > fixed.    
> 
> I disagree fully with the notion that using "CLOSED NEXTRELEASE" or "CLOSED
> UPSTREAM" is lying or cheating.

Consider ABRT was a Toyota model and Toyota told you "CLOSED NEXTRELEASE/UPSTREAM". 

It means, "we will not fix your car, buy a newer model".

> You're just misinterpreting the meaning of
> these resolutions.
Bugzilla is the bug reporting and tracking tool being used by Fedora.

... also have a look at koji/bodhi's "close bugs when packages is released".

It's cases like these, it supposed to use for.

Comment 16 Michal Schmidt 2010-02-15 15:31:20 UTC
> Consider ABRT was a Toyota model and Toyota told you "CLOSED
> NEXTRELEASE/UPSTREAM". 

This sketch^Wdiscussion has become far too silly.
Let's just test 1.0.7.

Comment 17 Ralf Corsepius 2010-02-15 15:55:19 UTC
(In reply to comment #16)
> > Consider ABRT was a Toyota model and Toyota told you "CLOSED
> > NEXTRELEASE/UPSTREAM". 
> 
> This sketch^Wdiscussion has become far too silly.
Well, if this is your attude, then this discussion is indeed a waste of time.

> Let's just test 1.0.7.    
You do that!

I for one have decided not to be any longer be abused by Red Hat's ABRT team and to waste my time with people who are resistant to learning.

CLOSING this bug as CANTFIX ... CANFIX in the sense of "Maintainer" is unwilling to do a reasonable job.

Comment 18 Jiri Moskovcak 2010-02-15 16:07:39 UTC
Please, don't close ABRT bugs, when you're not asked to. This bug in this BZ was properly fixed, and the fix is now waiting to be pushed to the repository, so CLOSED CANTFIX would be laying to users, wouldn't it?

Have a nice day,
Jirka

Comment 19 Ralf Corsepius 2010-02-15 16:19:30 UTC
(In reply to comment #18)
> Please, don't close ABRT bugs, when you're not asked to. This bug in this BZ
> was properly fixed, and the fix is now waiting to be pushed to the repository,
> so CLOSED CANTFIX would be laying to users, wouldn't it?

Closing again ... Feel free to clone this bug or refile it. I don't want to any longer be molested by this nor any other ABRT bug, nor by ABRT.

Comment 20 Michal Schmidt 2010-02-15 16:24:33 UTC
(In reply to comment #17)
> > Let's just test 1.0.7.    
> You do that!

"Let's" is a first-person plural (as in "we") imperative, so yes, I am including myself in the group of testers.

> I for one have decided not to be any longer be abused by Red Hat's ABRT team

To make it clear - I am not a member of the ABRT team. I found this bug only because I was looking for a different bug related to kerneloops and I thought I'd shed some light on the Bugzilla workflow, because there was clearly some confusion.

> and to waste my time with people who are resistant to learning.

Projection bias?

Comment 21 Ralf Corsepius 2010-02-15 16:44:28 UTC
(In reply to comment #20)
> (In reply to comment #17)
> > > Let's just test 1.0.7.    
> > You do that!
> 
> "Let's" is a first-person plural (as in "we") imperative, so yes, I am
> including myself in the group of testers.

Well, I am sick of being confronted with crappy junkware in Fedora - I feel ABRT is not ready for public consumption, should be removed from Fedora and its devs to be sent back to the drawing board.

> > and to waste my time with people who are resistant to learning.
> 
> Projection bias?    
No experience with some @RHs ... There are some who consider themselves to be exempt from the rules/conventions etc. being applied everywhere else in Fedora.

Comment 22 Fedora Update System 2010-02-23 05:38:13 UTC
abrt-1.0.7-1.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.