'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
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| apport (Ubuntu) |
Medium
|
Evan | ||
| Precise |
Medium
|
Evan | ||
| Quantal |
Medium
|
Evan |
Bug Description
---
WORKAROUND:
comment out line 23 ("'problem_types': ['Bug', 'Package'],") in '/etc/apport/
---
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/
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/
2) and even more so, 'apport-cli -c /var/crash/
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
ProcVersionSign
Uname: Linux 3.2.0-24-generic x86_64
ApportVersion: 2.0.1-0ubuntu7
Architecture: amd64
CheckboxSubmission: 017452a27eca3c8
CheckboxSystem: ecaaad6fa1e0799
Date: Fri May 4 17:17:43 2012
InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.1)
PackageArchitec
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)
Steve Langasek (vorlon) wrote : | #1 |
Changed in apport (Ubuntu): | |
status: | New → Triaged |
importance: | Undecided → Medium |
assignee: | nobody → Evan Dandrea (ev) |
Changed in apport (Ubuntu Precise): | |
assignee: | nobody → Evan Dandrea (ev) |
status: | New → Triaged |
importance: | Undecided → Medium |
Bob Bib (bobbib) wrote : | #2 |
George Shuklin (george-shuklin) wrote : | #3 |
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) wrote : | #4 |
george-shuklin,
BTW, it's not a bug, but a feature of the new Ubuntu error tracker design concept:
https:/
Bob Bib (bobbib) wrote : | #5 |
An alternative to commenting the config line:
https:/
"It works to edit /etc/apport/
Neal McBurnett (nealmcb) wrote : | #6 |
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://
Majestyx (majestyx) wrote : | #7 |
ok, thx for reference !
description: | updated |
summary: |
- 'ubuntu-bug /var/crash/app.crash' should still allow manual bug filing + 'ubuntu-bug /var/crash/app.crash' (and even more so, 'apport-cli -c + /var/crash/app.crash') should still allow manual bug filing |
Changed in apport (Ubuntu Precise): | |
milestone: | none → ubuntu-12.04.1 |
Sasa Paporovic (melchiaros) wrote : Re: 'ubuntu-bug /var/crash/app.crash' (and even more so, 'apport-cli -c /var/crash/app.crash') should still allow manual bug filing | #8 |
The workarround is broken on Quantal 64bit with apport2.
The /etc/apport/
Dmitry Shachnev (mitya57) wrote : Re: [Bug 994921] Re: 'ubuntu-bug /var/crash/app.crash' (and even more so, 'apport-cli -c /var/crash/app.crash') should still allow manual bug filing | #9 |
@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/
Steve Langasek (vorlon) wrote : | #10 |
On Thu, Jun 14, 2012 at 06:30:26PM -0000, melchiaros wrote:
> The workarround is broken on Quantal 64bit with apport2.
> The /etc/apport/
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.
description: | updated |
summary: |
'ubuntu-bug /var/crash/app.crash' (and even more so, 'apport-cli -c - /var/crash/app.crash') should still allow manual bug filing + /var/crash/app.crash') should still allow manual bug filing in stable + releases |
Changed in apport (Ubuntu Precise): | |
milestone: | ubuntu-12.04.1 → ubuntu-12.04.2 |
drink (martin-espinoza) wrote : | #11 |
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-Message: Failed to load module "overlay-scrollbar"
Fontconfig warning: "/etc/fonts/
Traceback (most recent call last):
File "/usr/share/
app.run_argv()
File "/usr/lib/
return self.run_
File "/usr/lib/
self.
File "/usr/lib/
icthread.
File "/usr/lib/
raise self._exception
File "/usr/lib/
self._retval = self.__
File "/usr/lib/
report.
File "/usr/lib/
dep, v, self._customize
File "/usr/lib/
mod = packaging.
File "/usr/lib/
s = os.stat('/' + words[-
UnicodeEncodeError: 'ascii' codec can't encode character '\xed' in position 40: ordinal not in range(128)
drink@alexander:~$
drink (martin-espinoza) wrote : | #12 |
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/
> mod = packaging.
> File "/usr/lib/
> s = os.stat('/' + words[-
> 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) wrote : | #14 |
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) wrote : | #15 |
> 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/
/var/lib/
/var/lib/
/var/lib/
/var/lib/
drink (martin-espinoza) wrote : | #16 |
OK, I will take your word for it, and have attached those files.
Changed in apport (Ubuntu Quantal): | |
milestone: | none → quantal-updates |
tags: | added: quantal |
CSRedRat (csredrat) wrote : | #17 |
Affected too.
CSRedRat (csredrat) wrote : | #18 |
Can't send apport report. Actualy.
Changed in apport (Ubuntu Precise): | |
milestone: | ubuntu-12.04.2 → ubuntu-12.04.3 |
Chris J Arges (arges) wrote : | #19 |
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://
Id2ndR (id2ndr) wrote : | #22 |
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) wrote : | #23 |
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) wrote : Re: [Bug 994921] | #24 |
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) wrote : | #25 |
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) wrote : | #26 |
I have disabled line 23 in /etc/apport/
@florin:
> I have disabled line 23 in /etc/apport/
> the bug was already reported and opened a page to complete the bug
> report (https:/
That bug is private (thus invisible to you), and duplicate of bug 1210785.
Bob Bib (bobbib) wrote : | #28 |
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) wrote : | #29 |
@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) wrote : | #30 |
I've wasted several hours today trying to report a kernel oops.
At the very least, as mentioned previously in https:/
The wiki has a note, but if you go to https:/
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) wrote : | #31 |
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.
Changed in apport (Ubuntu Quantal): | |
status: | Triaged → Won't Fix |
Martin Pitt (pitti) wrote : | #33 |
I'm closing this as wontfix. We really want crashes to go to http://
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/
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.
Changed in apport (Ubuntu): | |
status: | Triaged → Won't Fix |
Changed in apport (Ubuntu Precise): | |
status: | Triaged → Won't Fix |
Bob Bib (bobbib) wrote : | #34 |
Martin Pitt:
> We really want crashes to go to http://
> 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) wrote : | #35 |
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) wrote : | #36 |
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:/
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/
Leandro Cunha (leandrocunha526) wrote : | #38 |
https:/
not open this directory /etc/default/apport does not exist and stating that the program does not direct reports to launchpad
Leandro Cunha (leandrocunha526) wrote : | #39 |
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
Daniel van Vugt (vanvugt) wrote : | #40 |
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".
Daniel van Vugt (vanvugt) wrote : | #41 |
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.
Ads20000 (ads20000) wrote : | #42 |
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:/
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...
Daniel van Vugt (vanvugt) wrote : | #43 |
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-
https:/
where ID is the contents of /var/lib/
So you can try running this command to open it:
xdg-open https:/
Daniel van Vugt (vanvugt) wrote : | #44 |
I've just logged bug 1766148 to resolve the above in Gnome Shell.
Bob Bib (bobbib) wrote : | #46 |
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_
>
> 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:/
>
> ** Attachment added: "ubuntu_
> https:/
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_
* 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:/
*
https:/
--
Best wishes,
Bob
Chao MENG (cmeng0532) wrote : | #47 |
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
Daniel van Vugt (vanvugt) wrote : | #48 |
Try clicking the green "Hide" link on the right.
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).