[apport] apport-gtk crashed with error in load()

Fixed in bzr head.

 apport (0.78) gutsy; urgency=low
 .
   * apport/packaging.py, backends/packaging-dpkg.py: Add new interface
     is_distro_package(package) which verifies the origin of a given package.
     Move the dodgy hack from apport/ui.py to the backend, where it belongs to.
     Also add a test case.
   * debian/control: Add python-apt dependency to python-apport.
   * debian/control: Remove debianutils dependency, it's essential.
   * Drop backends/packaging-dpkg.py. It had some hackish usage of python-apt
     anyway, since some things just cannot be figured out with dpkg alone.
     Since we have to give up on that idea, implement a new clean packaging
     backend 'packaging-apt-dpkg.py' which now uses python-apt and dpkg in a
     clean way.
   * apport/report.py, add_gdb_info(): Fix crash when Stacktrace could not be
     created. (LP: #107853)
   * ./test-apport: Check that crashes create a core dump (with proper ulimits)
     when an unseen crash report exists already. This reproduces LP #105976.
   * bin/apport: Create core dump file if aborting because an unseen crash
     report already exists. (LP: #105976)
   * apport/ui.py: Add a comment for translators. (LP: #104703)
   * apport/ui.py, load_report(): Also catch zlib.error on invalid reports.
     (LP: #103547)
   * apport/report.py: Add method has_useful_stacktrace() to determine whether
     the stack trace can be considered useful. The current heuristic is to
     consider it useless if it either is shorter than three lines and has any
     unknown function, or for longer traces, a minority of known functions. Add
     test cases.
   * gtk/apport-gtk, qt4/apport-qt, cli/apport-cli: Do not offer 'reduced
     report' option if the stack trace is useless. (LP: #87430) Bump the
     python-apport dependencies of the frontend packages to ensure that we have
     has_useful_stacktrace().