Re: [ATTEND] oops.kernel.org prospect

[Anton Arapov <anton@redhat.com>]

On Tue, Aug 20, 2013 at 08:37:48AM -0400, Dave Jones wrote:
> On Tue, Aug 20, 2013 at 10:22:16AM +0200, Borislav Petkov wrote:
>  > On Tue, Aug 20, 2013 at 10:02:43AM +0200, Anton Arapov wrote:
>  > > > * Visiting it with chromium gets an annoying warning about the https server
>  > > > ...
>  > > [snip]
>  > > > ...
>  > > > 	Dave
>  > > 
>  > > Thanks, Dave! Will be fixed and improved.
>  > 
>  > Yeah, collecting oopses is a good idea, so +1.
>  > 
>  > However, we probably want to think about what exactly we're going to
>  > do with that information. For example, if I want to address an issue,
>  > I probably want to know how I can reproduce the oops - maybe something
>  > like allowing the reporter to add free text note to the oops.
> abrt used to have a free-form entry like this.
> What happened is users have no idea what to type in there, so you end up
> with bugs containing things like "don't know" or worse, some crazy moon
> language you can't even read.
Agree.

>  > And yes, as tytso already said, we are very often going to need more
>  > info about a system causing the oops (dmesg, lspci, dmidecode, etc,
>  > etc). I'm not sure how we're going to collect that without sacrificing
>  > some privacy. Or maybe, we could be able to ask people to open a bug on
>  > bugzilla.kernel.org where further debugging can take place...
> Two things worth noting here, are 1) the original kerneloops also didn't
> collect anything like this, and was still very useful, and 2) for the more
> common issues (which let's face it, are going to be the only things
> people really look at) chances are pretty high that there's going to be
> someone also reporting it on lkml, or in a distro bug tracker.
> 
> What might be useful however, is collecting things like dmi/lspci/lsusb etc
> and _asking_ the user if they're ok with including them at time of filing.
> We might scare off some of the more paranoid OMGMYSECRETDATAS users, but
> chances are high most people won't care. This requires the client to have
> a UI though, which aiui, it currently doesn't. Anton?
The above is possible with abrt/libreport-kerneloops it does have UI
and a possibility to include the dmi/lspci/lsusb into the message to
oops.kernel.org.

Some distros still using the old reporting tool written by Arjan that
doesn't have UI.

I am going to research what and how distros are using nowadays, get in
touch with people/distro_maintainers in order to align the process as
well as gather their views and concerns on sharing anything other than
just a stacktrace and doing unconditionally(w/o user intervention).
oops.kernel.org can sanitize the 'private' data is it already does for
oopses.

Will be keeping lkml posted on my progress.

> We might also ask if they want to provide an email address for feedback,
> but that leads to a bunch of questions about how we expose that to developers
> without exposing it to spambots.
I'd not want to ask user about anything. In Fedora, Abrt end up
this way -- abrt asks user to review the report and whether one is
willing to send it to Bugzilla and oops.kernel.org. User also can
check a "don't ask me in the future for this kind of issues - just
send reports" checkbox. This is what I was able to get from Abrt
folks so far.


Anton