leaves core files behind after calling crashdump-helper

Bumping importance, this clutters up the user's disk.

Martin, the crash helper is going to need to remove the cores now. It should do it when REMOVE_CORE=1 env exists. Had to do this. The fix that caused this bug was to get around the crash that was occurring in another bug.

I want to avoid this whole problem, and this seems like the easiest way. So...

  * crash-helper: Because of the weirdness of deleting a file in the kernel, I
    think it's best to just ask the helper to do it when it needs to. Now
    passes REMOVE_CORE=1 when it should do that.
    - Malone #62972

I saw the upload yesterday, closing the kernel task.

Will do the apport changes ASAP. Thank you, Ben!

apport (0.25) edgy; urgency=low

  * Drop apport-gtk's update-notifier dependency to a Recommends:.
  * apport_utils.py, report_add_gdb_info(): Add register dump and disassembly
    of the last 32 bytes, they might be useful to see what's going on
    sometimes. Thanks to Kees Cook for the idea and the patch.
  * test-apport, check_crash(): Verify that a crash does not leave a core file
    behind. (Test for LP#62972)
  * preloadlib/libapport.c: Do not unlink the core file after calling apport,
    but set REMOVE_CORE=1 environment instead. This matches the current
    kernel behaviour.
  * apport: Register an atexit handler as early as possible for unlinking the
    core dump if REMOVE_CORE environment is set. Closes: LP#62972
  * apport: Set nice level 10 instead of 5. Closes: LP#63099

 -- Martin Pitt <email address hidden> Mon, 2 Oct 2006 14:21:53 +0200