'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

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).

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

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

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".

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

ok, thx for reference !

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

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

@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.

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.

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:~$

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.

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.

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

> 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

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

Affected too.

Can't send apport report. Actualy.

I am seeing this issue in Saucy.

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

Added the tag saucy in respect to # 19

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.

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?

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.

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.

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.

@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.

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.

@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.

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).

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?)

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.

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.

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.

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.

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.

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.

https://help.ubuntu.com/community/ReportingBugs
not open this directory /etc/default/apport does not exist and stating that the program does not direct reports to launchpad

But can modify and the system hangs and does not redirect to this bug tracker, opens the browser in a new tab.
Remembering that before without my modifications was working normally

Leandro Cunha
Student in Information Systems

I think we need to revisit this bug.

Every day I am telling users "Please start by applying the workaround for bug 994921". Without that, we have bug reports describing crashes but no stack traces. So bugs would stay open indefinitely.

By telling users to apply the workaround from bug 994921, I am quickly able to get a stack trace from them, deduplicate their original bug reports and _close_ the bug as a duplicate. It would be a faster and safer process if I didn't have to keep telling (often inexperienced) users to "apply the workaround from bug 994921".

It's worth remembering most users don't install Ubuntu until after release. Only then do they want to report bugs. But only then do we block them from doing so.

Maybe the real problem is that reporters are unable to link to their errors.ubuntu.com report (because if one doesn't have access then one doesn't have _any_ access, as I understand it)? https://bugs.launchpad.net/ubuntu/+source/apport/+bug/994921/comments/33

If the original justification still stands (linked above) then maybe support for users viewing their own reports in e.u.c (so they can link to them) would be useful, or perhaps Ubuntu should make Launchpad scale to mass crash reports somehow...

I think it might be possible for any user to see their own automatic crash reports, but the process is a little obfuscated.

If you're using Unity then you can open:

System Settings >
 Security & Privacy >
 Diagnostics >
 Show Previous Reports

But I can't find any such option in gnome-control-center or 18.04. So you then have to make the link yourself:

  https://errors.ubuntu.com/user/ID

where ID is the contents of /var/lib/whoopsie/whoopsie-id

So you can try running this command to open it:

  xdg-open https://errors.ubuntu.com/user/`sudo cat /var/lib/whoopsie/whoopsie-id`

I've just logged bug 1766148 to resolve the above in Gnome Shell.

On 2018-11-12, Chao MENG wrote:
> Hello guys,
> I meet a bug when using input method, I drag the input method dialog onto the top bar of GNOME, and then I can't drag it anymore; please see the attached screenshot ubuntu_input_method_bug.PNG
>
> Sorry that I report a bug here, but I really can't find a place to
> report a bug, I am working and really don't have much time to check
> carefully a so long document
> https://help.ubuntu.com/community/ReportingBugs
>
> ** Attachment added: "ubuntu_input_method_bug.PNG"
> https://bugs.launchpad.net/ubuntu/+source/apport/+bug/994921/+attachment/5211824/+files/ubuntu_input_method_bug.PNG

Hi Chao,

Your report is useless here, hence I've removed your attachment, sorry.

* If you know the package name of your "input method" program, please
execute somthing like "ubuntu-bug your_package_name_here" from the terminal.
* If you, unfortunately, don't know that, please execute "ubuntu-bug -w"
from the terminal and follow the instruction (close the intro message
box and click on the window of your "input method" program etc.)

References:
*
https://help.ubuntu.com/community/ReportingBugs#Collecting_information_from_a_specific_package
*
https://help.ubuntu.com/community/ReportingBugs#Collecting_information_about_a_program_with_a_window_open

--
Best wishes,
Bob

Hello Bob,

I am sorry that reported an unrelated problem here, I can't delete them after I realised my stupied behavior.
I am so sorry.

Best wishes,
Chao

Try clicking the green "Hide" link on the right.