しばらく前まで、あなたは走っapport-bugたりubuntu-bugバグの報告を始めたりしていました。その後、システムはアカウントでランチパッドを開き、収集した情報をアップロードして、バグレポートにさらに情報を追加します。
今、私が実行したときにgksudo ubuntu-bug（と例えばcrash、引数として-file）の一般的なバグのダイアログが表示されますが
そしてそれだけです。
レポートの送信先はどこですか？バグ報告としてlaunchpadを使用しないことは間違いありません（具体的な状況では、人々はそのバグに関する報告を提出することができました）。
だから：このレポートはどこに送られますか（そして、たぶん）システムからバグレポートをどのように提出できますか（関連ファイルのアップロードがずっと簡単になります）
「システム」が、これが既存のバグの複製であると判断したということでしょうか？
回答:
技術的にはubuntu-bug、クラッシュレポートをローカルに記録するだけです。別のプログラムが、whoopsieログに記録されたレポートを監視し、それらを中央のデータベースにアップロードします。そこで、それらは自動的にグループ化されて、包括的な問題を識別します。
結果のデータはUbuntuエラートラッカーに表示されます。
集約された傾向は公開されており、レポートの詳細は信頼できる開発者が利用できます。詳細については、Ubuntu Wikiをご覧ください。
デフォルトでubuntu-bugは、安定版リリースのクラッシュレポートのランチパッドでバグを開きませんが、必要に応じて構成できます。その変更を行った後、を実行して既存のクラッシュレポートのバグを開くことができますubuntu-bug /var/crash/foo.crash。
収集された情報またはレポートは、バグ追跡システムにアップロードされます。
一般に「クラッシュ」（セグメンテーション違反、バスエラー、浮動小数点例外など）と呼ばれる信号が原因でシステム内のプロセスが停止した場合、またはパッケージ化されたPythonアプリケーションがキャッチされない例外を発生させた場合、apportバックエンド自動的に呼び出されます。
/ var / crash /のファイルに初期クラッシュレポートを生成します（ファイル名は、クラッシュした実行可能ファイルの名前とユーザーIDから構成されます）。クラッシュしたプロセスが現在ログインしているユーザーに属しているか、システムプロセスに属し、ユーザーが管理者である場合、apportはクラッシュについてユーザーに通知し、問題の報告を提案します。
ユーザーが[エラーレポートの送信]チェックボックスを有効のままにすると、Apportは収集した情報をバグ追跡システムにアップロードします。その後、適切なデフォルトのバグタイトルを含むパッケージのバグファイリングページを開き、残りのバグファイリングプロセスをWeb UIに残します。
Ubuntuは、バグ追跡システムを通じて毎日非常に多くのバグレポートを受け取ります。これらを修正、修正するには、それぞれを読み取り、評価し、ソートする必要があります。ここで、バグの支援にご協力いただけます。バグのトリアージプロセスの視覚的表現については、これらの素敵なフローチャートをご覧ください。
すべてのバグレポートはレポーターとの会話です。レポーターがUbuntuコミュニティと最初に接触する最初の連絡先は、完全なバグレポートの作成を試みるバグトリアージャーです。私たちが良い印象を与えることは非常に重要ですので、丁寧にして、あなたの最高の英語を使ってみてください。
単純でトリアージされていないバグに取り組むことは、バグのライフサイクルのあらゆる側面に対処する必要があるため、トリアージ手順を開始し、理解するための良い方法です。「トリアージされていないバグ」セクションでは、それらの場所を説明しています。
バグの種類
レポートの報告
Apportレポートは、自動バグ報告プログラムApportによって報告されるバグです。Apportを使用してバグを報告することは、影響を受けるシステムに関する多くの情報を開発者に提供するため、バグを報告する好ましい方法です。Apportを使用すると、必要な追加情報が少なくなり、プロセス全体が高速化されます。
説明に追加されたシステム情報のリストによって、これらのバグを認識できます。一部のプログラムにはApportのフックがあり、バグを報告するときにさらに情報を追加します。通常、この情報は添付ファイルに記載されています。
確認されたバグ
バグが「確認済み」とマークされている場合、まだ完全にはトリアージされていません。このバグは「トリアージ済み」とマークされるのに非常に近いですが、開発者が修正する準備ができていることを確認する必要があります。
機能リクエスト
バグレポートが実際に機能のリクエストである場合、2つの可能性があります。要求された拡張機能が小さく、明確に定義されている場合、および/または提案が上流プロジェクトに関する場合、バグの重要度は「ウィッシュリスト」に設定する必要があります。レポートが完了したら、ステータスを「トリアージ」に設定する必要があります。
Ubuntu Bug Controlチームのメンバーのみがこれを行うことができます。あなたがメンバーでない場合は、あなたのためにそれを行う誰かに尋ねる必要があります。バグ番号を＃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を呼び出すをます。
例
Apportは、PID 1（Upstart）が死んだ場合でもコアファイルをキャプチャできます。
バックエンド
遅延と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を呼び出します。これは、上記のスクリーンショットに示されているフロントエンドです。
フロントエンドは、パッケージバージョン、パッケージファイルチェックサム、OSバージョンなどの追加情報を収集し、一致するすべてのパッケージフックを呼び出します。これを無効にするには、gsettings set com.ubuntu.update-notifier show-apport-crashes falseを（通常のデスクトップユーザーとして）実行します。
ランチパッドベースの自動リトレーサー
Canonicalデータセンターは、apportでバグを自動的に追跡するサービスを実行します。Launchpadのアーキテクチャに従ってバグにタグを付けることにより、リトレースが行われ、タグが削除されます。使用されるタグは、need-i386-retraceまたはneed-amd64-retraceです。お知らせをご覧ください。
パッケージごとのApportフック
パッケージは、システムから収集され、バグレポートに含まれる情報を指定することができます。これらは、パッケージに含まれるapportフックによって行われます。いくつかの有用な例については、以下を参照してください。
/ usr / share / apport / package-hooksにあります。apportフックを提供するパッケージのリストもあります。
クラッシュまたはバグレポートがapportを介して送信されると、関連するフックが自動的に実行されます。apportを使用せずに報告されたバグが既に報告されており、それらのフックからの情報に興味がある場合は、バグ報告者にapport-collectバグ番号を使用するよう依頼できます。
ソース、ルークを使用してください！
今後の計画
パフォーマンスのさまざまな改善、レポートを操作するためのより良いツール、およびより多くの言語の統合（Mono / Pythonスタックトレース、アサーションメッセージなど）関連する仕様を参照してください。
ソース：Apport、トリアージ方法、およびApportを有効にする方法