would be nice to send xsessions-errors warnings and errors

trunk r1612

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

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

  * New upstream bug fix release:
    - apport-cli: Print the URL and ask whether to open a browser. In many
      situations (such as usage on a server through ssh), it's preferable to not
      open the browser on the reporting computer. Thanks to Matt Zimmerman for the
      initial patch! (LP: #286415)
    - general-hooks/generic.py: Collect important glib errors/assertions (which
      should not have private data) from ~/.xsession-errors (LP: #431807)
    - launchpad.py: Link hardware data submission key if it exists. (LP: #424382)
    - apport-cli: Fix crash with non-ASCII characters in prompts.
    - Fix "apport-bug symptomname" to actually work.
    - launchpad.py: Fix crash on invalid credentials file. Thanks to Marco
      Rodrigues for the initial patch! (LP: #414055)
  * man/apport-bug.1: Document APPORT_IGNORE_OBSOLETE_PACKAGES (cherrypicked
    from trunk), and APPORT_STAGING (Ubuntu specific change, since it's a
    launchpad backend specific variable).
  * bin/apport-bug: Ignore -p option when giving two arguments, to keep
    compatibility with current bug filing instructions. (LP: #356755)
  * debian/copyright: Update copyright year and fix GPL link, thanks Marco
    Rodrigues!

 -- Martin Pitt <email address hidden> Fri, 02 Oct 2009 13:25:58 +0200

I came to this report here from bug #430705. I had the initial impression that this thing here was intended to provide a solution for that one. However, at least in its current form, it does not:

The errors I am concerned with are generated by the xkbcomp binary, and don't match the glib pattern quoted above.
I just did update to Karmic Beta, and confirmed that there is no magic wrapping these lines into glib error lines.

Unfortunately I can think of no way to easily recognize the xkbcomp errors as such. So properly extracting them from the concatenated log is probably impossible, and bug #328980 a cleaner solution in the long run.

For the specific error message I have in mind, however, you could probably add a suitable regexp:
'^Error: *No Symbols named'
This at least handles the case I encountered in bug #328980 and will help diagnose similar errors.
To be more generic, one could turn all occurrences of the "ERROR3" macro in the xkbcomp sources into patterns, but I don't know if that would be worth the effort.

Would you consider adding the regexp above, or is there a reason not to?

Sure, I added "^Error: .*No Symbols named" to the regexp in trunk r1619.