Default MaxReports of 3 skews statistics in error database

[Matthew Paul Thomas]

apt 0.8.16~exp12ubuntu6, Ubuntu Pangolin

When more than 3 apt errors occur in some period, apt says "No apport report written because MaxReports has already been reached".

That limit skews statistics of how often each error occurs, which will in turn skew priorities of which problems are most important to fix.

That might have been a worthy tradeoff for saving people from the interaction required to report bugs. But when error reports are being sent to a database without user interaction, it is no longer relevant.

Either the limit should apply only when the error storage requires interaction (e.g. Launchpad), or it should be removed altogether.

[Ubuntu QA Website (ubuntuqa)]

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/973277

[David Kalnischkies (donkult)]

Just as a comment: After the first error you have a decent chance to report errors which depend on the previous error.
'example-data' can't be installed for whatever reason - the logical consequence is that 'example' will fail to install, too, resulting in a useless bugreport. After the first "valid" failure you can easily accumulate hundreds of followups…

3 is not a hard-coded limit btw. APT::Apport::MaxReports is the relevant config option if you desire to play with different values.

[Brian Murray (brian-murray)]

Are package installation failures actually being reported to the crash database or is it only crashes?

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[martin suchanek (martin-suc)]

Where can I setup APT::Apport::MaxReports ?

[Daniel Hartwig (wigs)]

> Where can I setup APT::Apport::MaxReports ?
>

apt.conf(5)