Ubuntu Wiki

• Launchpad Entry: foundations-karmic-kerneloops

• Created: Tue 9 Jun, 2009

• Contributors: JamesWestby, MartinPitt

• Packages affected: kerneloops, apport

Summary

We will make changes to appport and kerneloops so that they can work together to submit issues. This means we can catch OOPSes by default, work with kerneloops.org, and keep a single UI all at the same time.

Release Note

The "kerneloops" package is now installed by default, meaning that when the kernel encounters some types of non-fatal issues you will be asked if you wish to report a bug about the issue. This information will also be submitted to the kerneloops.org project, where reports of these problems from all users are aggregated.

Rationale

Kerneloops is a package that watches for various forms of OOPS from the kernel and offers to report them for the user. By default it reports them to kerneloops.org, a central place than allows kernel developers to see cumalative results, as well as individual entries, so that problems affecting a lot of users can be caught.

Apport is used in Ubuntu to catch various problem events and report bugs about them to launchpad.

We want to enable kerneloops by default so that we can get more information about problems affecting our users. In addition, we want to ensure that the problems can still be automatically sent to kerneloops.org to help with that effort. Therefore sending the reports to both is more desirable.

However, a second interface for doing this is not that desirable, so if possible we should make apport the UI that the user sees if they trigger an OOPS.

User stories

• Anne hits a OOPS in the kernel and gets a dialog box about it. It looks like the one she got when firefox crashed. She chooses to send the bug to Launchpad where an Ubuntu kernel developer can track it. In addition the report is sent to kerneloops.org, along with many reports of the same problem from other users. The high number of reports of this particular problem means that it is quickly fixed.

Assumptions

We want to only have the user see dialogs from apport, not kerneloops itself, but kerneloops will still do the watching and submission to kerneloops.org.

Design

The kerneloops daemon will run as before, as a non-root user, and watch for OOPSes. When it finds one it will trigger apport. Apport will display information about the problem as usual, and ask the user if they would like to submit it. If they choose to submit, then apport will file a bug report on Launchpad. The user will separately be asked if they wish to submit to kerneloops.org, and if they agree apport will instruct kerneloops to submit that problem to kerneloops.org.

There could also be dupe checking similar to with python tracebacks performed on the launchpad reports (the reports have a checksum which kerneloops.org uses for dupe detection, so it would be an easy check).

Implementation

We re-purpose the "submit-pipe" configuration option, set by default in Ubuntu, to make kerneloops merely write to "submit-pipe", and not do any of it's own querying of the user. This option is not upstream yet, so the change in behaviour should not cause any issues. Apport will listen on this pipe (as it does now), and will convert the output in to a problem report of type "Oops". Kerneloops will include an id in the output so that we can later refer to a particular report, and apport will include this as an extra field in the problem report.

When apport in the user's session notices the report it will display it to the user and ask them whether they wish to submit it as normal, submitting to launchpad if they wish.

kerneloops has a configuration option "allow-pass-on", which the user can set to indicate that they want their reports sent to kerneloops.org as well. If this is set (which it will be by default in Ubuntu, the kerneloops output includes the information if it is) then we will also query the user to ask if they wish to submit to kerneloops.org.

If a user wants a "pure upstream" experience then they can unset the "submit-pipe" option, and run the kerneloops-applet in their session.

We have a choice of methods to prompt the user. The simplest one if to change the kernel's apport hook to deal with the kerneloops service. This requires minimal changes to apport, the difficultly being that it runs before the user has been shown the report, so we are asking "Do you want to submit this information?" without the user being able to see the information. The alternative then is to ask them after they have seen it and agreed to submit to Launchpad. This would require extending apport to have a new hook at this point, which shouldn't be too difficult, but is more work that the first option.

There is still an open question over where the kernel team wants these reports by default. It may be that they do not wish to send them to Launchpad by default, just to kerneloops.org. If they do not want them going to both then we need to tweak the design somewhat.

UI Changes

Apport will now have an extra prompt to query the user if they wish to also submit to kerneloops.org. Something like this mockup (Needs UI review):

Kerneloops will in have its UI disabled by default. kerneloops-applet will still be installed, but will not be set to autostart.

Code Changes

kerneloops:

• Option to rely on "submit-pipe" for controlling, that means it just writes to that when it finds a problem.
• Enough exposed over dbus so that apport can call back to submit a particular report.
• applet to quit if it will not be used.

apport:

• Either a change to the kernel hook, or
• A new hook point after sending to Launchpad, and a hook to deal with kerneloops.org at this point.

Migration

No migration should really be needed.

Test/Demo Plan

Jim Lieb wrote a kernel module that can trigger various types of problem. This can be used to simulate issues for testing. More information will be provided here once I have investigated.

Unresolved issues

• What do the kernel team want with these reports? Once we know this then we can decide which option to implement, or to design a new option if neither suits.
• Do we want more than just an "OOPS" type of apport report?
• Do we want dupe detection on launchpad?
• Do we still want to submit to kerneloops.org from stable releases with apport turned off?

BoF agenda and discussion

Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.

CategorySpec