直到不久前，您运行apport-bug或ubuntu-bug开始报告错误。然后系统会使用您的帐户打开启动板，上传收集的信息并让您向错误报告添加更多信息。
现在当我运行gksudo ubuntu-bug（例如使用crash-file 作为参数）时，会出现常见的错误对话框
就这样。
报告要发到哪里？绝对不会作为错误报告发到 launchpad（尽管在具体情况下人们可以提交有关该错误的报告）。
那么：该报告发送到哪里（可能）我如何才能从我的系统中提交错误报告（使上传相关文件变得更加容易）
难道“系统”认为这是一个已经存在的错误的重复？
答案1
从技术上讲，ubuntu-bug只需在本地记录崩溃报告即可。一个单独的程序whoopsie会监视记录的报告并将其上传到中央数据库，然后自动对报告进行分组以识别主要问题。
结果数据显示在Ubuntu 错误追踪器：
总体趋势是公开的，报告详细信息可供受信任的开发人员查看。更多详细信息可用在 Ubuntu Wiki 上。
默认情况下，ubuntu-bug稳定版本不会在 Launchpad 上打开错误报告，但你可以将其配置为如果需要的话。进行该更改后，您可以通过运行 来打开现有崩溃报告的错误ubuntu-bug /var/crash/foo.crash。
答案2
收集到的信息或报告会上传到错误跟踪系统。
如果系统中的任何进程由于通常称为“崩溃”的信号（分段违规、总线错误、浮点异常等）而死亡，或者例如打包的 Python 应用程序引发未捕获的异常，则会自动调用 apport 后端。
它会在 /var/crash/ 中的一个文件中生成初始崩溃报告（文件名由崩溃的可执行文件的名称和用户 ID 组成）。如果崩溃的进程属于当前登录的用户，或者属于系统进程且用户是管理员，apport 会通知用户崩溃情况并建议报告问题。
如果用户保留“发送错误报告”复选框处于启用状态，Apport 将收集到的信息上传至缺陷跟踪系统。之后，它会打开软件包的错误归档页面，并带有合理的默认错误标题，并将其余的错误归档过程留给 Web UI。
Ubuntu 每天通过我们的错误跟踪系统收到大量的错误报告。我们需要阅读、评估和分类这些报告，以便修复它们。这就是我们需要您通过“帮助解决错误”提供帮助的地方。要直观地了解错误分类过程，请参阅这些精美的流程图。
每个错误报告都是与报告者的一次对话。任何报告者与 Ubuntu 社区的第一次接触通常是通过错误分类员，他们会尝试整理一份完整的错误报告。我们给别人留下好印象非常重要，所以请保持礼貌并尽量使用最好的英语。
处理简单、未分类的错误是开始熟悉分类过程的好方法，因为您必须处理错误生命周期的每个方面。未分类的错误部分解释了在哪里可以找到它们。
错误类型
Apport 报告
Apport 报告是通过自动错误报告程序 Apport 报告的错误。使用 Apport 报告错误是报告错误的首选方式，因为它为开发人员提供了大量有关受影响系统的信息。使用 Apport 时，需要的附加信息较少，从而加快了整个过程。
您可以通过描述中添加的系统信息列表来识别这些错误。一些程序有 Apport 钩子，在报告错误时添加更多信息。这些信息通常可以在附件中找到。
已确认的错误
当错误被标记为“已确认”时，它尚未完全分类。此错误非常接近被标记为“已分类”，但您需要确保它已准备好供开发人员修复。
功能请求
如果错误报告实际上是功能请求，则有两种可能性。如果请求的增强功能很小且定义明确和/或建议涉及上游项目，则应将错误的重要性设置为“愿望清单”。报告完成后，状态应设置为“已分类”。
只有 Ubuntu Bug 控制团队的成员才能这样做。如果您不是成员，则必须请某人为您执行此操作。将错误编号粘贴到 #ubuntu-bugs 中，并说明您认为该错误应设置为“愿望清单”。有人会注意到并为您设置，尽管不一定立即设置。
它的内部是如何运作的？
碰撞拦截
Apport 使用 /proc/sys/kernel/core_pattern 将核心转储直接传送到 apport：
$ cat /proc/sys/kernel/core_pattern
|/usr/share/apport/apport %p %s %c
$
注意：即使将 ulimit 设置为禁用核心文件（通过使用 ulimit -c 0 将核心文件大小指定为零），apport 仍会捕获崩溃。为了拦截 Python 崩溃，它会安装一个以/etc/python*/sitecustomize.py在未处理的异常上调用 apport。
例子
当 PID 1（Upstart）死亡时，Apport 甚至能够捕获核心文件：
- 如果 Upstart 检测到内部不一致，它会发出 SIGABRT 信号。
- Upstart 崩溃处理程序在 SIGABRT 上被调用。
- Upstart 崩溃处理程序分叉一个子进程。
- Upstart 子进程重新发出信号，导致子进程异常退出。
- 内核检测到子进程异常退出，并调用 apport，将核心文件传送到 apports 标准输入（由于 /proc/sys/kernel/core_pattern）。
- apport 将核心文件写入 /var/crash/ 中的磁盘。
- PID 1 等待其子进程终止（只有在 apport 完成核心文件的写入后才会发生）。
- PID 1 退出。
- 内核崩溃。
- 在下次启动时，Whoopsie 将检测崩溃文件并处理它。
后端
为了尽可能降低延迟和 CPU/IO 影响，/usr/share/apport/apport仅收集崩溃进程仍然存在时必须获取的数据：来自 的信息/proc/pid、核心转储、可执行文件路径和信号编号。报告写入/var/crash/executable_path.uid.crash。
前端调用
在 Gnome 中，update-notifier 会持续监视 inotify /var/crash。每当有新内容时，它都会调用 /usr/share/apport/apport-checkreports。如果有新报告，它会调用 /usr/share/apport/apport-gtk，即上面屏幕截图中显示的前端。
然后，前端会收集其他信息，例如软件包版本、软件包文件校验和或操作系统版本，并调用所有匹配的软件包挂钩。要禁用此功能，您可以运行 gsettings set com.ubuntu.update-notifier show-apport-crashes false（以普通桌面用户的身份）。
基于启动板的自动回溯器
Canonical 数据中心运行一项使用 apport 自动追溯错误的服务。通过在 Launchpad 中根据架构标记错误，将进行追溯并删除标记。使用的标记是 need-i386-retrace 或 need-amd64-retrace。请参阅公告。
每个软件包的 Apport 钩子
软件包可以指定从系统收集并包含在错误报告中的信息。这些是通过软件包中包含的 apport 钩子完成的。有关一些有用的示例，请参阅：
- source_xorg.py - 向错误报告添加额外的日志文件和硬件详细信息
- usplash-忽略特定代码路径中的崩溃
- source_totem.py - 向记者提问并根据回答收集不同的信息
在 /usr/share/apport/package-hooks 中。还有一个提供 apport 钩子的软件包列表。
如果通过 apport 提交了崩溃或错误报告，则会自动运行相关钩子。如果您已报告了未通过 apport 提交的错误，并且对这些钩子中的信息感兴趣，您可以要求错误报告者使用 apport-collect bugnumber。
使用来源，卢克！
- 您可以从 Launchpad 项目页面下载上游 tarball，或者从 Ubuntu 档案库下载 Ubuntu 源 tarball。
- apport 是使用 Launchpad 上的 bazaar RCS 开发的。如果您想为其做出贡献或基于它开发自己的系统，您可以使用 bzr get lp:apport 获取主干分支，或使用 debcheckout -a apport 获取 Ubuntu 打包分支。
未来的计划
各种性能改进、更好的报告处理工具以及更多语言的集成（Mono/Python 堆栈跟踪、断言消息等）。请参阅相关规范。
资料来源：阿波特，如何分类， 和如何启用 Apport