apport package hook for Bazaar

[Matt Zimmerman]

Binary package hint: bzr

Attached is an apport package hook for Bazaar. By installing source_bzr.py in /usr/share/apport/package-hooks, you can cause Ubuntu bug reports for bzr to include additional information, including the end of ~/.bzr.log and the output of "bzr plugins -v".

ProblemType: Bug
Architecture: i386
Date: Tue Jun 23 09:51:29 2009
DistroRelease: Ubuntu 9.10
Package: bzr 1.15-1
ProcEnviron:
 LC_COLLATE=C
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/zsh
ProcVersionSignature: Ubuntu 2.6.30-6.7-generic
SourcePackage: bzr
Uname: Linux 2.6.30-6-generic i686

[Matt Zimmerman (mdz)]

I reported this bug using the hook, so that you can see what it looks like

[Matt Zimmerman (mdz)]

I also recommend installing the following symlinks:

/usr/share/apport/package-hooks/source_bzrtools.py -> source_bzr.py
/usr/share/apport/package-hooks/source_bzr-gtk.py -> source_bzr.py

and likewise for other Bazaar-related packages which would benefit from the same information. This way, if a bug is reported on bzrtools, the hook will run there as well.

[Robert Collins (lifeless)]

On Tue, 2009-06-23 at 08:53 +0000, Matt Zimmerman wrote:
> Public bug reported:
>
> Binary package hint: bzr
>
> Attached is an apport package hook for Bazaar. By installing
> source_bzr.py in /usr/share/apport/package-hooks, you can cause Ubuntu
> bug reports for bzr to include additional information, including the end
> of ~/.bzr.log and the output of "bzr plugins -v".

We had previously written directly to the apport API, which allows
gathering this data in-process rather than later when the log may be
messy or distorted (by other bzr processes).

Is that no longer supported?

Note that bzr never 'crashes' in the python sense, so apport won't ever
see bzr fail to trigger, unless we do it ourselves.

-Rob

[Matt Zimmerman (mdz)]

On Tue, Jun 23, 2009 at 09:21:33AM -0000, Robert Collins wrote:
> On Tue, 2009-06-23 at 08:53 +0000, Matt Zimmerman wrote:
> > Public bug reported:
> >
> > Binary package hint: bzr
> >
> > Attached is an apport package hook for Bazaar. By installing
> > source_bzr.py in /usr/share/apport/package-hooks, you can cause Ubuntu
> > bug reports for bzr to include additional information, including the end
> > of ~/.bzr.log and the output of "bzr plugins -v".
>
> We had previously written directly to the apport API, which allows
> gathering this data in-process rather than later when the log may be
> messy or distorted (by other bzr processes).
>
> Is that no longer supported?

Both approaches are independently useful, though there may be value in
sharing code between the package hook and your internal error handler.

> Note that bzr never 'crashes' in the python sense, so apport won't ever
> see bzr fail to trigger, unless we do it ourselves.

While apport originated as a crash handler, it has grown into much more than
that. We encourage all Ubuntu bug reports to be reported using apport, even
when they are manually initiated (rather than in response to a crash).

It's used when a user runs "ubuntu-bug bzr" for example, to report a bug
which didn't result in a crash.

See
http://mdzlog.alcor.net/2009/03/31/please-dont-report-ubuntu-bugs-directly-to-launchpad/

--
 - mdz

[Robert Collins (lifeless)]

On Tue, 2009-06-23 at 09:46 +0000, Matt Zimmerman wrote:

> > Note that bzr never 'crashes' in the python sense, so apport won't ever
> > see bzr fail to trigger, unless we do it ourselves.
>
> While apport originated as a crash handler, it has grown into much more than
> that. We encourage all Ubuntu bug reports to be reported using apport, even
> when they are manually initiated (rather than in response to a crash).
>
> It's used when a user runs "ubuntu-bug bzr" for example, to report a bug
> which didn't result in a crash.

Yup, am aware of that - but thanks for being clear.

Many of our users, particularly those testing newest code, run from our
PPA; can such bugs be reported with PPAs at the moment? And similarly,
can we get them to go upstream directly for PPA packages (which as the
nightly PPA represents development versions, is entirely appropriate).

-Rob

[Matt Zimmerman (mdz)]

On Tue, Jun 23, 2009 at 09:59:09AM -0000, Robert Collins wrote:
> On Tue, 2009-06-23 at 09:46 +0000, Matt Zimmerman wrote:
>
> > > Note that bzr never 'crashes' in the python sense, so apport won't ever
> > > see bzr fail to trigger, unless we do it ourselves.
> >
> > While apport originated as a crash handler, it has grown into much more than
> > that. We encourage all Ubuntu bug reports to be reported using apport, even
> > when they are manually initiated (rather than in response to a crash).
> >
> > It's used when a user runs "ubuntu-bug bzr" for example, to report a bug
> > which didn't result in a crash.
>
> Yup, am aware of that - but thanks for being clear.
>
> Many of our users, particularly those testing newest code, run from our
> PPA; can such bugs be reported with PPAs at the moment? And similarly,
> can we get them to go upstream directly for PPA packages (which as the
> nightly PPA represents development versions, is entirely appropriate).

Launchpad doesn't support filing bugs on software in PPAs at the moment.
It's possible that apport could be tweaked to direct certain reports
upstream, if we can identify the packages reliably.

--
 - mdz

[Robert Collins (lifeless)]

On Tue, 2009-06-23 at 10:08 +0000, Matt Zimmerman wrote:

> Launchpad doesn't support filing bugs on software in PPAs at the moment.
> It's possible that apport could be tweaked to direct certain reports
> upstream, if we can identify the packages reliably.

I think the vast majority of bzr bugs will be upstream; if we can do
something for the bzr suite to get bug reports going upstream by
default, well I think that would be great.

-Rob

[Matt Zimmerman (mdz)]

On Tue, Jun 23, 2009 at 10:29:06AM -0000, Robert Collins wrote:
> I think the vast majority of bzr bugs will be upstream; if we can do
> something for the bzr suite to get bug reports going upstream by
> default, well I think that would be great.

It would be best to speak to Martin Pitt about that, and see what he thinks
is possible.

--
 - mdz

[Martin Pitt (pitti)]

If you want all or some bugs to be filed against the bzr product instead of the bzr package, this can be done with two steps:

1. define a new crash database for upstream bzr, like

  $ cat /etc/apport/crashdb.conf.d/bzr.conf
  bzr = {
      'impl': 'launchpad',
      'bug_pattern_base': 'http://people.ubuntu.com/~pitti/bugpatterns',
      'project': 'bazaar',
  }

  See /usr/share/doc/apport/crashdb-conf.txt for details.

2. in bzr's package hook, set

       report['CrashDB'] = 'bzr'

   either unconditionally, or in some code which determines whether or not the bug report should go upstream.

However, this will still cause Apport to complain about packages which come from a PPA. It shouldn't do this if CrashDB is set, I'll get that fixed.

[Martin Pitt (pitti)]

Fixed above behaviour in in lp:apport r1476.

[Martin Pitt (pitti)]

I just wonder whether it would actually help anyone to have these bugs on the upstream product? Or do the bzr developers only follow the upstream bug reports, and not the Ubuntu package ones?

For the record, if you want PPA package reports to be filed against the Ubuntu package, you can disable the "distro package version" check with

  report['CrashDB'] = 'ubuntu'

[Robert Collins (lifeless)]

On Tue, 2009-06-23 at 11:23 +0000, Martin Pitt wrote:
> I just wonder whether it would actually help anyone to have these bugs
> on the upstream product? Or do the bzr developers only follow the
> upstream bug reports, and not the Ubuntu package ones?

We don't generally look at package bugs. I think the reason for this is
simply that we have plenty of bugs. We could say [for the canonical
developers anyway] 'please go and look at the distro', but I think that
that is less efficient than presuming that packaging bugs are a small
fraction of the bugs encountered with bzr, and thus inverting the
default: start upstream, push it back to the distro if its not actually
a bzr issue.

-Rob

[Martin Pool (mbp)]

2009/6/23 Martin Pitt <email address hidden>:
> I just wonder whether it would actually help anyone to have these bugs
> on the upstream product? Or do the bzr developers only follow the
> upstream bug reports, and not the Ubuntu package ones?

We should/do follow the Ubuntu bugs, however we do also make a
distinction between upstream and packaging bugs. It would be
inefficient (in time and noise) to have bugs filed against the package
and then have to redirect 95%+ of them to be upstream.

--
Martin <http://launchpad.net/~mbp/>

[Martin Pitt (pitti)]

Good, then I recommend the approach in comment 10. This works from Ubuntu 9.04 on.

[Martin Pool (mbp)]

Thanks for your help.

I wonder, should we put this into the bzr tarball or just into the deb packages? It could be of use on other platforms I suppose.

[James Westby (james-w)]

On Wed, 2009-06-24 at 21:23 +0000, Martin Pool wrote:
> Thanks for your help.
>
> I wonder, should we put this into the bzr tarball or just into the deb
> packages? It could be of use on other platforms I suppose.

Yes, Ubuntu isn't the only distro using apport, so putting it in the
tarball (even if not installing it with setup.py) would be better.

Thanks,

James

[Launchpad Janitor (janitor)]

This bug was fixed in the package apport - 1.4-0ubuntu1

---------------
apport (1.4-0ubuntu1) karmic; urgency=low

  * New upstream release. Compared to our previous snapshot, this changes:
    - Replace Qt4 frontend with KDE frontend, thanks to Richard Johnson!
    - apport/ui.py, run_report_bug(): Clean up PID information collection.
    - gtk/apport-gtk.ui: Drop invalid icon reference. (LP: #389064)
    - ui.py: Do not reject non-distro package reports if report sets CrashDB
      (for third-party destination). (LP: #391015)
    - bin/kernel_crashdump: Use packaging API properly.
    - apport-gtk.ui: Drop erroneous translatable flag from stock buttons.
    - Update German translations.
  * debian/*: qt → kde, add transitional package for apport-qt.
  * Drop backends/packaging_rpm.py. We don't use it in the Ubuntu package at
    all, and it's still in trunk.
  * debian/rules: Drop some deprecated dh_* calls, cdbs's debhelper.mk has
    done them for a long time.
  * debian/control: Bump Standards-Version to 3.8.2 (no changes necessary).
  * debian/control: Replace URLs in descriptions with proper Homepage: field.

 -- Martin Pitt <email address hidden> Fri, 26 Jun 2009 10:44:54 +0200

[Martin Pool (mbp)]

An updated version of the source hook and crashdb config is now in ./contrib/apport in bzr, but it's not yet installed by either the package or make install.

[Martin Pool (mbp)]

I wonder if it's more tasteful to install it from the upstream setup.py, or from the debian/ubuntu packaging? Perhaps the latter, at least for now, because installing into arbitrary directories owned by other packages is not really in the normal scope of setup.py, and apport is unlikely to be present elsewhere.

[Martin Pitt (pitti)]

The branch looks okay to me. I just don't understand why bzrlib/crash.py would need to set CrashDb, SourcePackage, and Package fields? The latter two are done during post-processing in the Apport UI, and the apport hook sets CrashDb already.

[Martin Pool (mbp)]

On 30 March 2010 17:48, Martin Pitt <email address hidden> wrote:
> The branch looks okay to me. I just don't understand why bzrlib/crash.py
> would need to set CrashDb, SourcePackage, and Package fields? The latter
> two are done during post-processing in the Apport UI, and the apport
> hook sets CrashDb already.

If the SourcePackage and Package are not recorded, it seems to also
fail as in 528114: apport counts on them being there.

--
Martin <http://launchpad.net/~mbp/>

[Martin Pitt (pitti)]

The problem there rather seems to be that the initial report is missing ExecutablePath.

[John A Meinel (jameinel)]

Martin, your patch for this is considered landed in trunk, but Rejected for 2.1. So I'm going to mark this as such, and change the In Progress setting.

[Martin Pool (mbp)]

On 21 April 2011 23:12, John A Meinel <email address hidden> wrote:
> Martin, your patch for this is considered landed in trunk, but Rejected
> for 2.1. So I'm going to mark this as such, and change the In Progress
> setting.
>
> ** Changed in: bzr
>       Status: In Progress => Fix Released

I think that's reasonable; we seem to be getting apport reports.