Can I help? Please let me help...

Asked by Bruno Maximilian Voss on 2020-09-15


Today I had a "bug experience" and I didn't like it.

A window launched labled "ubuntu" that said "[version] has experienced a problem".

It then took quite a while to load the information what the actual problem was. Which is odd, because there is usually some error code being reported or a traceback or *something* that communicates that there is an actual problem.

My problem was with a package with a bug that has already been fixed in may. Which is cool.

What isn't cool is that I can then not interact at all with the information that is presented, except "send it" or "not send it".

 - there is no information what this window (apport) even *is*.
 - there is no information on where to configure it's settings.
 - there is no option to save the information presented somewhere where I can look at it.
 - If this is done already, there is no Information where this happens.
 - there is actually no info on what will be sent or to whom or how

Please, let's talk about improving this.

I don't know much about how you collect the info, but I do know enough python to fix that.

And if this was a bit emotionally loaded, I apologize, I really just want to help.


Question information

English Edit question
Apport Edit question
No assignee Edit question
Last query:
Last reply:
Launchpad Janitor (janitor) said : #1

This question was expired because it remained in the 'Open' state without activity for the last 15 days.

Launchpad Janitor (janitor) said : #3

This question was expired because it remained in the 'Open' state without activity for the last 15 days.

Launchpad Janitor (janitor) said : #5

This question was expired because it remained in the 'Open' state without activity for the last 15 days.

Yes I still want to help.

On 11/2/20, Launchpad Janitor <email address hidden> wrote:
> Your question #692912 on Apport changed:
> Status: Open => Expired
> Launchpad Janitor expired the question:
> This question was expired because it remained in the 'Open' state
> without activity for the last 15 days.
> --
> If you're still having this problem, you can reopen your question either
> by replying to this email or by going to the following page and
> entering more information about your problem:
> You received this question notification because you asked the question.

Manfred Hampl (m-hampl) said : #7

The best way to help is creating a new version of the software with your improvements, creating a diff between the current version and yours, and then creating a bug report where you list the weaknesses and add the diff as proposal for a correction.

Additional reading: for the concepts of apport please see

Thank you for your answer, but I really need to talk it over with
someone with approval rights first, since it's a feature request and I
have to make sure there is chance of it being accepted at all.

I'm not going to invest a significant amount of time into a solution
that has a high chance of being ignored.

I have filed a bug:

I have filed a easy to review and discuss pull request as an ice
breaker to start the conversation:

Tiago Stürmer Daitx (tdaitx) said : #9

Hi Bruno,

Thank you for getting in touch. I have some knowledge about apport cli, as I have fixed some bugs there, but I don't know about the GTK UI enough to help in that particular area.

You should start by taking a look at the source, available at

It contains all the cli and GTK bits.

The loading part you mentioned also happens in the CLI, but its effect is not as dramatic. I can understand that the GUI would look better if it could somehow show what is going on "behind the scenes".

The .crash files generated at /var/crash happens in a 2 stage process: first by the systemd's apport service that creates the reports with the core file attached and the second step only before uploading the crash file. It is designed this way so the first crash report is created quickly, leaving all the extra processing (running apport hooks, querying installed packages, etc) to later. This later step can be called the "collect" step and it only runs just before the upload happens or - as you noticed - when the user clicks to see the extra details.

Assuming the user does not have autoreport enabled, the systemd user service called "update-notifier-crash" (from update-notifier package) will take care of showing that GTK popup window which in turn calls apport-gtk.

I would recommend looking over gtk/apport-gtk to see how that window operates. From there you should be able to check ways to improve it and propose patches to the code.

Again, thanks for your interest in improving apport.

Hi Tiago,

Thanks for the pointer and the kind words, they really are appreciated.

I want to point out that my main problem doesn't even concern anything
about the collection, although it's cool to know more about it. My
problem is more how the GUI presents itself and what is happening, to
a user. I don't necessarily want to change anything about how things
are collected.

Feedback is such an important step, anywhere. These bug reports, if
they're sent, are feedback. It would be wonderful to have an
established, reliable channel for novice users to send feedback on.

May I should brainstorm some new gui and propose that, so it's a bit
more substantial and there is more to talk about.

Tiago Stürmer Daitx (tdaitx) said : #11

Hi Bruno,

Right, I probably gave too much importance on the part were you mentioned that the collection took too long and failed to address the rest.

That said, if you want to have a look and a go at the GUI, look at the code in the gtk/ directory [1]. Just in case you are not familiar with Ubuntu development, it is best to start on the code for the Ubuntu "devel" release - which at this time is hirsute. Please notice that it is a bzr repository, but development in apport has not yet moved to git. If you are more familiar with Git an alternative is to clone from the "package" git repository [2] - it is called that way because it simply reflects the package uploads from an automated tool, no actual development is done at those - but that could help you to at least use a local git repo before submitting any patches.

For communication, you can use #ubuntu-devel on Freenode over IRC or the mailing list <email address hidden> [3].
I'm not sure if those are actually the proper or efficient channels to discuss apport GUI changes, but I am certain someone there can help figure that out.

And whenever you have some code with the GUI improvements, you could either upload your bzr branch and propose a merge or simply open a bug against apport with the patch.

Another source of information is, which even link to 2 other wiki pages related to design and UI - just take care because there's certainly a lot of outdated information there, the design and UI pages are pretty old.


Can you help with this problem?

Provide an answer of your own, or ask Bruno Maximilian Voss for more information if necessary.

To post a message you must log in.