Support to report to different launchpad projects to be added

Current apport already has some infrastructure to support this, which can easily be generalized for this.

Let's keep this bug report for the UNR case, since it's more pressing for you; I'll worry about making it generic enough.

I need to know:
 - how apport can identify that it should report against UNR (this would ideally use lsb_release)
 - which Launchpad project to report bugs against

sources.list guesswork etc. sounds a bit too brittle to me. Would it be possible to ship a different apport configuration file in UNR which makes apport report to the LP project? That'd be cheap to implement in Jaunty even at this point (easy feature freeze exception).

Changing the configuration file sounds like a good solution to the problem I'm trying to get solved.

Let me asked you a couple of questions to understand better the recommended solution:
Is the configuration file statically added or auto-generated when apport package is installed?
What you suggest then is to change that configuration file when another UNR-specific package is installed?

Javier Collado [2009-03-09 16:40 -0000]:
> Is the configuration file statically added or auto-generated when
> apport package is installed?

It's a conffile, i. e. statically shipped in the package.

> What you suggest then is to change that configuration file when
> another UNR-specific package is installed?

No, packages mustn't change foreign conffiles. You need to do that
modification in the image build process, or we need to make apport
look for a conf directory such as /etc/apport/crashdb.conf.d/*.conf;
in the the latter case, you can ship a conf snippet in an UNR package;
in the former case you just change the image build scripts.

Hello Martin,

Let's try the second option, that's to say, adding an specific package in the UNR builds that adds a small configuration file with the information that is needed to change the default launchpad project to report to.

Please let me know the format of the file that should be added.

Best regards,
    Javier

Javier,

do you want bug reports for *all* packages go against that new project, or only some specific ones? I. e. should your new rule completely override the standard of reporting against ubuntu packages, or use it by default and only override it for UNR specific packages/binaries/etc.?

In the first case, I'd add support for reading /etc/apport/crashdb.conf.vendor which is read after /etc/apport/crashdb.conf and can redefine the "default" setting (and also add new databases).

In the second case we need support for an executable path/package name -> LP project mapping.

Hello Martin,

I would say that as a first approach I would like to try the first option, that is, just override the reporting project regardless of the package that has caused the problem. What should be the format of the /etc/apport/crashdb.conf.vendor configuration file in such a case?

Best regards,
    Javier

It could be a modified copy of crashdb.conf, and look like:

--------------- 8< -----------------
default = 'ubuntu_netbook'

databases = {
    'ubuntu_netbook': {
        'impl': 'launchpad',
        'bug_pattern_base': 'http://people.ubuntu.com/~pitti/bugpatterns',
        'project': 'ubuntu-netbook-remix',
    },
--------------- 8< -----------------

i. e. it would define a new crash database which doesn't report against 'distro': 'ubuntu', but against a 'project', and then set that as default.

Hello Martin,

Following you advice I've writing the file /etc/apport/crashdb.conf.vendor with the following contents:

-------------------------------------
default = '<lp_project>'

databases = {
    'ubuntu_netbook': {
        'impl': 'launchpad',
        'bug_pattern_base': 'http://people.ubuntu.com/~pitti/bugpatterns',
        'project': '<lp_project>'}
    },
}
-------------------------------------

where <lp_project> is the launchpad project that I would like to be used for reporting.

After that, I've followed the steps to generate a crash report for the notification-daemon explained in https://wiki.ubuntu.com/ApportImprovements. However, when the crash report is generated, it tries to report it to ubuntu/notification-daemon package instead of to <lp_project>.

Is there something that I'm missing? I'm using apport 0.119 and the machine was rebooted before the crash so the configuration should have been loaded successfully.

The contents of the log file is the following:
apport (pid 8371) Mon Mar 23 11:13:48 2009: called for pid 7840, signal 11
apport (pid 8371) Mon Mar 23 11:13:48 2009: executable: /usr/lib/notification-daemon/notification-daemon (command line "/usr/lib/notification-daemon/notification-daemon")
modinfo: could not open cdrom: No such device
modinfo: could not open cdrom: No such device
apport (pid 8371) Mon Mar 23 11:13:49 2009: wrote report /var/crash/_usr_lib_notification-daemon_notification-daemon.1000.crash

Is it possible to increase log level to obtain more detailed information?

Best regards,
    Javier

Javier Collado [2009-03-23 10:40 -0000]:
> -------------------------------------
> default = '<lp_project>'

That should be 'ubuntu_netbook'; it needs to refer to a key in the
databases map.

> After that, I've followed the steps to generate a crash report for the
> notification-daemon explained in
> https://wiki.ubuntu.com/ApportImprovements. However, when the crash
> report is generated, it tries to report it to ubuntu/notification-daemon
> package instead of to <lp_project>.

Right. Apport does not yet have the code to evaluate the additional
configuration file. I was just discussing with you how it could look
like, and whether the approach would fulfill your needs. That's why
the bug report is still open.

Hello Martin,

You're right regarding the configuration file. I've fixed the mistake and now the configuration file is as follows:
-------------------------------------
default = 'ubuntu_netbook'

databases = {
    'ubuntu_netbook': {
        'impl': 'launchpad',
        'bug_pattern_base': 'http://people.ubuntu.com/~pitti/bugpatterns',
        'project': '<lp_project>'}
    },
}
-------------------------------------

I thought that this support was already in place and that the more complex option (report to different projects depending on the package responsible for the failure) was the one that needed extra development. Now I see that it was a misunderstanding.

Anyway, I think that the proposed solution is clear from my side now and that we've discussed in this thread would be completely acceptable, so please keep me up-to-date with the changes in the code so that I can test them when ready.

Thanks & regards,
    Javier

Javier, sorry for the confusion. Apport already has support for reading third-party configuration files, and it just occurred to me that the existing infrastructure is sufficient. If you want *all* bug reports to go to a project, then you should just ship a file which completely overrides the default ubuntu database:

$ cat crashdb.conf.d/unr.conf
ubuntu = {
    'impl': 'launchpad',
    'bug_pattern_base': 'http://people.ubuntu.com/~pitti/bugpatterns',
    'project': 'ubuntu-netbook-remix',
}

If you decide later that you only want bug reports for a subset of packages, then you can change above database to have its own name (like "unr") and use a package hook which dynamically selects between the unr or ubuntu database depending on properties of the crash report. Let me know if you are interested in this.

So the only thing which is still required here is to have the "launchpad" CrashDB implementation respect the "project" option. I'm working on this now.

The full path of that new file is /etc/apport/crashdb.conf.d/unr.conf, for the record.

r1340

This bug was fixed in the package apport - 0.146

---------------
apport (0.146) jaunty; urgency=low

  * apport/report.py, _generate_sigsegv_report(): Turn into a class method, so
    that it can be used by test cases in other modules as well. Also add
    missing Signal field.
  * apport/crashdb_impl/launchpad.py: Fully enable operation with
    staging.launchpad.net.
  * apport/crashdb_impl/launchpad.py: Add initial test suite, performing data
    upload, Python and SEGV bug reporting, report download, report updating,
    tag and duplicate handling. This happens on staging.launchpad.net.
  * apport/crashdb.py: Add new interface duplicate_of(id) to return the master
    bug of a duplicate. Also document that close_duplicate() with "None"
    master bug will un-duplicate the bug.
  * apport/crashdb_impl/{launchpad,memory}.py: Implement duplicate_of() and
    add test cases. The Launchpad test case reproduces the
    "duplicate-of-a-duplicate" regression, which now got fixed in
    python-launchpad-bugs bzr head.
  * apport/ui.py, open_url(): Also consider a sesssion as "GNOME" if gconfd-2
    is running; some variants such as UNR do not have gnome-panel; this fixes
    using the preferred browser for them. (LP: #322386)
  * debian/local/apport-collect: Add new option -p to explicitly specify a
    (binary) package name instead of guesstimating it from the bug's source
    package tasks. Document new option in debian/local/apport-collect.1.
    (LP: #333875)
  * apport/crashdb.py, duplicate_db_consolidate(): Add logging about removing
    invalidated bugs from the duplicate database, now that this actually
    works.
  * debian/local/ubuntu-bug.1: Update for the possibility to specify a package
    name or PID without any options. Also document the "ubuntu-bug linux"
    special case. (LP: #348985)
  * debian/local/ubuntu-bug.1: Add missing documentation of the case of
    specifying a path name.
  * backends/packaging-apt-dpkg.py: When unpacking source trees, try
    "debian/rules setup" last, since it is the least common variant.
  * debian/local/ubuntu-fat-chroot: Divert away
    /usr/lib/xulrunner-1.9.1b3/xulrunner-bin. It is called on debian/rules
    patch in xulrunner-1.9.1 and hangs eternally in the fakechroots. This is
    only a temporary kludge, though, until the next xulrunner version lands.
  * apport/crashdb_impl/launchpad.py: Add test case: Update a bug report which
    got marked as a duplicate during processing. This reproduces #349407.
  * apport/crashdb_impl/launchpad.py, update(): Intercept and ignore IOErrors
    when changing the bug priority. This happens if a bug gets duplicated
    underneath us. (LP: #349407)
  * apport/crashdb.py, get_crashdb(): Print syntax errors from parsing
    conf.d/*.conf to stderr.
  * apport/crashdb_impl/launchpad.py: Support new CrashDB option "project"
    which can be set to a LP project name to file bugs against that project
    instead of the distribution. Add test case for filing crash bug against a
    project, updating it, duplicating/unduplicating it, and determining fixed
    version. (LP: #338835)
  * bin/crash-digger: If apport-retrace exits with 99, consider it a transient
   ...

I've done an small tests and the bug reporting page for the expected launchpad project has been opened.

Thanks for your help on this Martin.