'ubuntu-bug /var/crash/app.crash' (and even more so, 'apport-cli -c /var/crash/app.crash') should still allow manual bug filing in stable releases

[Steve Langasek]

---
WORKAROUND:
comment out line 23 ("'problem_types': ['Bug', 'Package'],") in '/etc/apport/crashdb.conf'.
---
The crash database work has made it much harder for users to enable apport bug filing for crashes in stable Ubuntu releases, even for those who could otherwise contribute useful bug reports. "Comment out line 23 of /etc/apport/crashdb.conf" is not particularly straightforward.

One thing that would mitigate this is if the users could still run one of the following commands to manually submit a bug report about a given crash:
1) 'ubuntu-bug /var/crash/application.crash';
2) and even more so, 'apport-cli -c /var/crash/app.crash' (as for now, it quietly exits without explanation after pressing the 'S' key instead of sending a crash report, as stated in duplicate bug #992064).
The fact that this is also disabled by the crashdb settings is a tad inconvenient. I think the manual command should be allowed to work even post-release.
---
ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: apport 2.0.1-0ubuntu7
ProcVersionSignature: Ubuntu 3.2.0-24.37-generic 3.2.14
Uname: Linux 3.2.0-24-generic x86_64
ApportVersion: 2.0.1-0ubuntu7
Architecture: amd64
CheckboxSubmission: 017452a27eca3c8b498abbfa5ef91db9
CheckboxSystem: ecaaad6fa1e0799a0aa1126bf620f39e
Date: Fri May 4 17:17:43 2012
InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.1)
PackageArchitecture: all
ProcEnviron:
 TERM=xterm
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: apport
UpgradeStatus: Upgraded to precise on 2011-11-08 (178 days ago)

[Bob Bib (bobbib)]

And even more nasty side of this issue: it doesn't even allow to report a crash by apport-cli, which is probably used only by experienced users (bug #992064).

[George Shuklin (george-shuklin)]

For me that settings is preventing even normal reaction on crashes (f.e. when thunderbird crash, after scanning data no reports is sent).

[Bob Bib (bobbib)]

george-shuklin,
BTW, it's not a bug, but a feature of the new Ubuntu error tracker design concept:
https://wiki.ubuntu.com/ErrorTracker

[Bob Bib (bobbib)]

An alternative to commenting the config line:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/993450/comments/13

"It works to edit /etc/apport/crashdb.conf and add 'Crash' to the 'problem_types': ['Bug', 'Package', 'Crash'], or to make that change in a separate file and run".

[Neal McBurnett (nealmcb)]

For some discussion of how the user can track problems reported via this new workflow, see:
 ErrorTracker: how can I track a bug that caused a crash and was reported via apport / whoopsie? - Ask Ubuntu
 http://askubuntu.com/questions/140379/errortracker-how-can-i-track-a-bug-that-caused-a-crash-and-was-reported-via-app

[Majestyx (majestyx)]

ok, thx for reference !

[Sasa Paporovic (melchiaros)]

The workarround is broken on Quantal 64bit with apport2.2.2-0ubuntu2.

The /etc/apport/crashdb.conf has no entries for 'problem types anymore'.

[Dmitry Shachnev (mitya57)]

@melchiaros:
I believe that quantal's apport is configured to use Launchpad
reporting by default:

apport (2.1.1-0ubuntu2) quantal; urgency=low
 <...>
 * etc/apport/crashdb.conf: Re-enable Launchpad crash reporting again.

[Steve Langasek (vorlon)]

On Thu, Jun 14, 2012 at 06:30:26PM -0000, melchiaros wrote:
> The workarround is broken on Quantal 64bit with apport2.2.2-0ubuntu2.

> The /etc/apport/crashdb.conf has no entries for 'problem types anymore'.

That's because apport is intended to direct users of the devel release to
file bug reports, so no workaround should be needed in quantal.

[drink (martin-espinoza)]

my bug was marked as a duplicate of this bug so I came here to report my update.

I can not now launch ubuntu-bug AT ALL.

drink@alexander:~$ ubuntu-bug update-manager
Gtk-Message: Failed to load module "canberra-gtk-module"
Gtk-Message: Failed to load module "overlay-scrollbar"
Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 9: reading configurations from ~/.fonts.conf is deprecated.
Traceback (most recent call last):
  File "/usr/share/apport/apport-gtk", line 588, in <module>
    app.run_argv()
  File "/usr/lib/python3/dist-packages/apport/ui.py", line 632, in run_argv
    return self.run_report_bug()
  File "/usr/lib/python3/dist-packages/apport/ui.py", line 434, in run_report_bug
    self.collect_info(symptom_script)
  File "/usr/lib/python3/dist-packages/apport/ui.py", line 983, in collect_info
    icthread.exc_raise()
  File "/usr/lib/python3/dist-packages/apport/REThread.py", line 64, in exc_raise
    raise self._exception[1].with_traceback(self._exception[2])
  File "/usr/lib/python3/dist-packages/apport/REThread.py", line 34, in run
    self._retval = self.__target(*self.__args, **self.__kwargs)
  File "/usr/lib/python3/dist-packages/apport/ui.py", line 87, in thread_collect_info
    report.add_package_info(package)
  File "/usr/lib/python3/dist-packages/apport/report.py", line 310, in add_package_info
    dep, v, self._customized_package_suffix(dep))
  File "/usr/lib/python3/dist-packages/apport/report.py", line 244, in _customized_package_suffix
    mod = packaging.get_modified_files(package)
  File "/usr/lib/python3/dist-packages/apport/packaging_impl.py", line 256, in get_modified_files
    s = os.stat('/' + words[-1].decode('UTF-8'))
UnicodeEncodeError: 'ascii' codec can't encode character '\xed' in position 40: ordinal not in range(128)
drink@alexander:~$

[drink (martin-espinoza)]

I just noticed the workaround, and I have to say, not pushing out a release with the workaround in it is unacceptable. I could perform the workaround, but then I'd just get a prompt on my next upgrade. There's been days to get this out already. Obviously the holdup is not testing.

[Steve Langasek (vorlon)]

On Tue, Oct 23, 2012 at 12:31:35PM -0000, drink wrote:
> my bug was marked as a duplicate of this bug so I came here to report my
> update.

> I can not now launch ubuntu-bug AT ALL.

> drink@alexander:~$ ubuntu-bug update-manager
<snip>
> File "/usr/lib/python3/dist-packages/apport/report.py", line 244, in _customized_package_suffix
> mod = packaging.get_modified_files(package)
> File "/usr/lib/python3/dist-packages/apport/packaging_impl.py", line 256, in get_modified_files
> s = os.stat('/' + words[-1].decode('UTF-8'))
> UnicodeEncodeError: 'ascii' codec can't encode character '\xed' in position 40: ordinal not in range(128)

This points to corruption in the md5sums file for the package. You should
try running 'sudo apt-get install --reinstall update-manager' to see if that
fixes the problem.

This error is unrelated to the present bug report.

[drink (martin-espinoza)]

same error. it may be unrelated, but then, I started having these problems
at the same time, so it may be related.

[Steve Langasek (vorlon)]

> same error. it may be unrelated, but then, I started having these problems
> at the same time, so it may be related.

No. It is *not* related. The bug that I reported (which yours has been marked a duplicate of) has nothing to do with any crashes you're experiencing.

Please attach to your original bug #1069061 any of the following files that are present on your system:

/var/lib/dpkg/info/update-manager.md5sums
/var/lib/dpkg/info/update-manager-core.md5sums
/var/lib/dpkg/info/update-manager-text.md5sums
/var/lib/dpkg/info/update-manager-kde.md5sums
/var/lib/dpkg/info/python3-update-manager.md5sums

[drink (martin-espinoza)]

OK, I will take your word for it, and have attached those files.

[CSRedRat (csredrat)]

Affected too.

[CSRedRat (csredrat)]

Can't send apport report. Actualy.

[Chris J Arges (arges)]

I am seeing this issue in Saucy.

[christopherbalz (christophermbalz)]

This "feature" is a bug because it prevented me from finding the solution to this for months: http://ubuntuforums.org/showthread.php?t=2151848&p=12691927#post12691927

[Sasa Paporovic (melchiaros)]

Added the tag saucy in respect to # 19

[Id2ndR (id2ndr)]

The good with this tool is that it pops in front of user that aren't able to use it! That's really professional !
By the way, comment #5 help me to 'fix' that issue in saucy.

[florin (florin-arjocu)]

My thoughts exactly. Just imagine users getting some strange error (that should in the first place never be there if it was tested before launch), getting some buttons to report it but it never happens. You just press it, like a game for children.

@Id2ndR - so editing that file makes reporting active again?

[Bob Bib (bobbib)]

florin:
> getting some buttons to report it but it never happens. You
> just press it, like a game for children.

AFAIK, Apport currently works this way by default:
* in stable Ubuntu releases, it works in a "MS Windows" way, submitting the crash to some kind of Ubuntu crash DB;
* in development releases, it submits the crash to the Launchpad bug tracker.

[florin (florin-arjocu)]

But it does not show anything, the user should know what the program does. Anyways, it should show something like collecting error data, and in the end show the bug was sent and received.

[florin (florin-arjocu)]

I have disabled line 23 in /etc/apport/crashdb.conf, and then it said the bug was already reported and opened a page to complete the bug report (https://bugs.launchpad.net/bugs/1210875). But, that one does not exist any more. So, there is some other bug in the middle, too.

[Dmitry Shachnev (mitya57)]

@florin:
> I have disabled line 23 in /etc/apport/crashdb.conf, and then it said
> the bug was already reported and opened a page to complete the bug
> report (https://bugs.launchpad.net/bugs/1210875).

That bug is private (thus invisible to you), and duplicate of bug 1210785.

[Bob Bib (bobbib)]

florin:
> But it does not show anything, the user should know what the program
> does. Anyways, it should show something like collecting error data, and
> in the end show the bug was sent and received.

Agree; on one hand, it's simplified for newbies, and on the other it's too limited.
Some verbosity should certainly be added.

[florin (florin-arjocu)]

@Dmitry - I learn something new everyday. Today I learned that there are invisible bugs. I know it is not your fault, but I kind of got tired of having 5-6 errors per startup + some more during session. Because of some bugs, I am quite sorry these days I upgraded to 13.10 :(

@Bob - Exactly. The user should know what the computer does, in very simple and nice words.
Knowing it does something I do not have any idea about what it truly does, without any confirmation it worked or not (what if I do not have internet in that moment or there is some other problem?), I could also consider it a worm. Why should one allow an unknown connection to some online service I have no feedback from? Just like a hidden action. Many people criticized Microsoft for things like this.

[Graeme Hewson (ghewson)]

I've wasted several hours today trying to report a kernel oops.

At the very least, as mentioned previously in https://bugs.launchpad.net/apport/+bug/997283/comments/8, apport-cli(1) and the messages from the command should explain clearly what will, or won't, or has, or hasn't happened.

The wiki has a note, but if you go to https://help.ubuntu.com/community/ReportingBugs, then from Contents to https://help.ubuntu.com/community/ReportingBugs#System_crash, the note is just above there, and you'll only see it if you scroll up, and why would you scroll up?

The note says "apport will appear to upload a crash report, but only actually does so if whoopsie is installed. Whoopsie is installed by default for users of ubuntu-desktop, but for users of alternative desktops, or for server users, whoopsie has to be installed manually with apt-get install whoopsie. See bug #1001630 for details."

I don't understand why it's only Ubuntu users who can upload crash reports by default (I'm using Kubuntu).

[LAZA (laza74)]

1/2 OT:
Thanks for this reminder, Graeme - now i know why my machines in I-Café do NOT upload automatically the bug reports!

For the programers:
The milestone
Ubuntu ubuntu-12.04.3
is gone, but 12.04.4 fast approaching.

It would be nice to see this fixed on February 6th in 2014 (was the date shifted?)

[Michael Mess (michael-michaelmess)]

Thanks for reporting this as a bug.

With the line commented out, I was now be able to report some nerving Bugs together with the crash report so that those can be found and fixed much more easily.

[Martin Pitt (pitti)]

I'm closing this as wontfix. We really want crashes to go to http://errors.ubuntu.com only for stable releases. Launchpad isn't suitable for these, both for privacy problems (stable users are much less prone to be able to decide whether a report might contain sensitive data), as well as scalability (Launchpad doesn't deal well with hundreds of duplicates, and a bug tracker isn't meant to).

As you found out, there is still a way to do this manually upon request of a developer, but we don't want to make this any easier.

> 1) 'ubuntu-bug /var/crash/application.crash';

This works for (non-crash) bug reports and is integrated with the MIME system, i. e. you can file those by merely clicking on .crash files. IMHO this would make it too easy to send crashes to LP.

So from what I've heard from Evan and Matthew we eventually want to move to errors.u.c even for the development release, and create bug reports off errors.u.c. when necessary.

[Bob Bib (bobbib)]

Martin Pitt:
> We really want crashes to go to http://errors.ubuntu.com only for stable releases.
> Launchpad isn't suitable for these
> ...
> privacy problems (stable users are much less prone to be able to decide
> whether a report might contain sensitive data)
> ...
> we eventually want to move to errors.u.c even for the development release

IMHO, errors.u.c should be a little more open for collaboration,
as it may give some useful info (e. g., crash backtraces to catch some rare bugs)
for upstream projects developers,
but at the same time it should somehow protect itself from sensitive data leak.

> scalability (Launchpad doesn't deal well with hundreds of duplicates,
> and a bug tracker isn't meant to).
> ...
> As you found out, there is still a way to do this manually
> upon request of a developer, but we don't want to make this any easier.

More to say, AFAIK,
a vast majority of packages stored in Ubuntu repos are NOT really maintained by dedicated persons,
but are actually just auto-synced from Debian repositories
(sometimes with minimal changes to make them buildable on Ubuntu),
so, unfortunately, there's NO much help from reporting problems with such packages here on Launchpad.

So it looks like the advanced Ubuntu users should better look at Debian & actual upstream projects for non-essential Ubuntu packages bug reporting.

[Martin Pitt (pitti)]

Bob Bib [2014-04-14 19:37 -0000]:
> More to say, AFAIK,
> a vast majority of packages stored in Ubuntu repos are NOT really maintained by dedicated persons,
> but are actually just auto-synced from Debian repositories
> (sometimes with minimal changes to make them buildable on Ubuntu),
> so, unfortunately, there's NO much help from reporting problems with such packages here on Launchpad.
>
> So it looks like the advanced Ubuntu users should better look at Debian
> & actual upstream projects for non-essential Ubuntu packages bug
> reporting.

Yes, that's right indeed.

[Donarsson (benjamin-schwarz)]

Sorry for bumping, but just to be clear, does this mean that I (an advanced user) should actually NOT follow the instructions given in the Community Wiki (https://help.ubuntu.com/community/ReportingBugs)? If bug reporting to Launchpad is in fact not helpful, the wiki article should be updated accordingly, as many advanced users follow these instructions, intending to help the developers by uploading meaningful bug reports.

[Christopher M. Penalver (penalvch)]

Donarsson, from a Canonical perspective (I'll let them correct if I'm wrong here), they want to steer folks to errors.ubuntu.com so they can get a high level, statistical view on the issues, as well as granular ones. However, from a triager/non-Canonical developer perspective (who don't have access to that) it's still distinctly helpful to continue to report bugs the old fashioned way as already documented. If the project maintainers don't want to allow either the old fashioned way by default, or a combo of errors+old fashioned, but instead just leave it available for enablement as documented, that works for me.