apportに関するバグを報告するにはどうすればよいですか？
Apportがランダムに起動し、（通常はバックグラウンドアプリケーションで）クラッシュが発生したことを通知し、それを報告するかどうかを尋ねる問題が発生しています。アプリケーションを見ると、すべて問題ありませんが、Apportはクラッシュしたと思っているようです。今日発生した2つの例は、LibreOfficeスプレッドシート（問題はありませんでした）とChromiumダウンロード（「クラッシュ」したと思われるにもかかわらず正常に終了しました）です。
私の質問：apportとubuntu-bugを使用して別のプログラムに関するバグレポートを送信する方法を知っていますが、具体的にapportに関するバグレポートを送信するにはどうすればよいですか？
これは実際には not Apportのバグであり、それが伝えたクラッシュは本物だと思います。 LibreOfficeとChromiumはどちらも、多くの場合、複数のプロセスを使用します。 （特に Chromium、少なくとも1つを使用します タブごとに個別のプロセス 。）1つはクラッシュする可能性があり、他のユーザーは実行を継続します。ユーザーエクスペリエンスに影響を与えない、影響を最小限に抑えたクラッシュが発生する可能性があります。
これは、プログラムの終了時にクラッシュが発生した場合など、限られた状況で一度に1つのプロセスのみを実行するように実装されたプログラムでも可能です（したがって、通常の終了の代わりに異常が発生し、ユーザーエクスペリエンスに影響を与えない可能性があります）明白な方法）。
したがって、実際に先に進んで、Apportが通知したクラッシュを報告し、 before Apport自体のバグであると思われるものを報告することをお勧めします。 （または、すでにApportのレポートを提出している場合。）LibreOfficeおよびChromiumのクラッシュに関するバグレポートで送信された情報は、クラッシュが本物であるかどうか、したがって、 Apportがそうだと思うのはバグではありません。
具体的には、を読んだ後 バグレポートのドキュメント（ この質問）もご覧ください ）、私はあなたをお勧めします：
Whoopsie経由ではなくLaunchpadにレポートするようにApportを構成します 。 （そこでの私の回答で説明されているように、
'Crash'のprobem_typesリストに/etc/apport/crashdb.confを追加します。）Apportがクラッシュを検出すると、
.crashに/var/crashファイルを作成します。クラッシュファイルへのパスを引数としてubuntu-bugを実行できます。たとえば、私のシステムの
/var/crashフォルダーの1つに、grub2-themes-ubuntu-mate.0.crashがあります。私が走ったらubuntu-bug /var/crash/grub2-themes-ubuntu-mate.0.crashまたは
cd /var/crashの後にubuntu-bug grub2-themes-ubuntu-mate.0.crashが続く場合、Apportは収集してその.crashファイルに保存したデータを送信することにより、そのクラッシュのバグ報告プロセスを開始し、Webブラウザウィンドウを開きます。バグレポートに記入します。したがって、LibreOfficeとChromiumのクラッシュに対してこれを行う必要があります（一度に1つずつ）。
クラッシュは十分に一般的で認識できる場合があり、Apportは、独自に作成する機会を与える代わりに、既存のバグレポートに送信します。それが発生し、バグレポートに追加する情報がある場合は、コメントを投稿できます。
バグに苦しんでいる可能性があると思われる場合（レポートの情報に基づいて判断できますが、この状況ではおそらく are です）、緑色を使用する必要がありますバグレポートの上部にある[このバグは影響します...]リンクをクリックして、あなたも影響を受けていることを示します。必要に応じて、バグをサブスクライブして、進行状況に関する電子メールを受信することもできます。
ただし、十分な技術的詳細がまだ報告されておらず、複数回再報告されていないバグについては、自分でバグを報告する機会が与えられます。
Webブラウザーで、適切に機能しているように見えるアプリケーションがクラッシュしたことを通知するApportに至るまでに何が起こったかを完全に説明します。実際のクラッシュは発生しておらず、Apportが間違っている可能性があると思われるので、そのことも説明する必要があります（つまり、アプリケーションが正常に動作しているように見え、実行を継続した理由を説明します）。ただし、 triagers および開発者が（a）レポートを理解し、（b）できるように、十分な事実の詳細を提供するようにしてください。 報告された事実のみに、または主に依存して、独自の仮説を立てます。彼らの最初の考えはあなたの考えと同じかもしれないし、違うかもしれません（そして正しいか間違っているかもしれません）。
他の関連するバグレポートへのリンクも含める必要があります。この場合は yours になります。先に進んでChromiumとLibreOfficeの両方のクラッシュを報告すると仮定すると、2つのバグレポートがあります。入力する2番目のレポートには、最初のバグへのリンクを含めることができます。次に、最初のバグレポートを編集して、2番目のバグレポートへのリンクを含めることができます。
すでにApportに対してバグを報告している場合は、LibreOfficeおよびChromiumレポートにそのバグへのリンクを含める必要があります（もちろん、その重要性を説明してください）。
クラッシュバグを報告すると、通常は自動的にプライベートとして設定されます。これは、クラッシュしたプログラムによって処理またはアクセスされた機密性の高い個人情報が、クラッシュバグを報告するときにApportに通常含まれる コアダンプ に含まれる可能性があるためです。情報はレジスタに含まれるか（通常、状態が含まれます）、自動的に含まれるスタックトレースにリストされている関数に引数として渡されます。
バグレポートを非公開のままにしておいてもかまいません。おそらく、コアダンプを削除でき、トリアージでレポートを検査できれば、それらは一般にアクセス可能になります。それが起こるかどうかにかかわらず、それらの作業は進行する可能性があります。
機密情報が伝達されていないと確信している場合は、自分でそれらを公開するオプションがあります。しかし、これを行うようにプレッシャーを感じるべきではありません。状況によっては役立つ場合がありますが、バグレポートを有効にするために必要というわけではありません。
プライベートバグレポートへのリンクは、それにアクセスできない人がアクセスすることを許可しません。したがって、他のバグ関連のバグレポート（プライベートかどうかに関係なく）にプライベートバグレポートへのリンクを含めることで安心できます。
ChromiumとLibreOfficeのバグレポートをざっと調べただけでも、ドキュメントに記録されているクラッシュが本物かどうかを高い確実性で判断するには十分かもしれません。または時間がかかる場合があります。通常、Apportバグレポートに含まれる スタックトレース は、システムにいくつかのデバッグシンボルパッケージがないため、最初は理想的とは言えません。 ボット Launchpadでリトレースを実行し、欠落している デバッグシンボル を埋め、クラッシュの状態と性質を明らかにすることがよくあります。
プライベートであってもバグの表示を許可したい関心のある個人がいる場合は、バグページでバグをサブスクライブできます。この質問のトピックに関連してファイルするバグをサブスクライブしてください me 。 （もしそうなら、コメントか何かを投稿することをお勧めします。あなたがそうしたことを私が知っていることと、私に何かを見てもらいたいことを確認するためです。）しかしあなたがする前に、 メモを取る：
- 私は not バグ修正の専門家です。お手伝いできない可能性があります。そして、私はおそらく助けようとしますが、継続的な支援を提供することを約束することはできません。 Apportが添付したファイルを見ると、クラッシュバグが実際のクラッシュを表しているかどうかについてさらに洞察が得られると思いますが、それでも約束することはできません。
- 私や他の誰かをバグレポートに登録する必要はありません。必要なグループはすでにサブスクライブされており、必要な個人にはレポートが表示されます。
- バグがまだ非公開である場合は、潜在的に機密性の高い情報へのアクセスを最小限に抑えるために、単にスタックトレースを表示するか、バグから再トレースすることをお勧めします。
- スタックトレースを自分で調べて、その中のどの変数にもパスワードやクレジットカード番号などの機密情報が含まれていないことに満足するかもしれません。次に、そうすることに抵抗がない場合は、 http://paste.ubuntu.com （または他の場所）に公開して投稿し、全員に提供することなく、コミュニティ全体の検討に開放することができます。コアダンプファイルなど、バグレポート内の潜在的により機密性の高いデータへのアクセス。
バグレポートを送信し、入手可能な事実（説明と、Apportによって自動的に添付されたファイル）の両方と、クラッシュが誤って識別および報告された可能性があるという懸念を表明した後は、単に待つだけで十分です。
バグは、自動（ボットによる）または手動（トリアージまたは開発者、または場合によってはどちらでもないコミュニティのメンバーによる）で、既存のバグレポートの複製になり、コメント、クローズ、確認、トリアージされ、重大度、またはそれらの組み合わせを割り当てました。これらの行動のいずれも、それが実際の墜落であったかどうかを含め、報告された内容の性質に光を当てる可能性があります。
から man apport-bug ：
You can provide a package name or program
name to apport-bug, e. g.:
apport-bug firefox
apport-bug /usr/bin/unzip
だから試してみてください：
apport-bug apport
私が試したときにこれを手に入れました： 
（提出しませんでした。）
バグの報告に関するガイド を参照してください。