クラッシュを引き起こし、apport / whoopsie経由で報告されたバグを追跡するにはどうすればよいですか?


52

以前は、プログラムがクラッシュしたとき、特にユーザーがUbuntuのプレリリースを使用していたときは、apportを使用してバグレポートを開くことができました。その後、ユーザーはバグを追跡し、他の人に影響があるかどうかを確認したり、修正を支援したりできます。

Precise 12.04から、この動作とワークフローが変更されました。Bug#993450「Apportはバグレポートの送信に失敗しました」で発見したように、デフォルトではapportはバグレポートを開きません(そして厄介ですが、そうすることは不可能ではありません)。同時に、人々は新しい「フープシー」プロセスに気付いています。「フープシー」プロセスとは何ですか?

さらにいくつかのグーグル検索の後、この青写真を掘り下げました。これは、プロセス全体を説明しています: ErrorTracker-Ubuntu Wiki。(それはwhoopsieやデイジーについては言及していなかったので、それらを追加しました-間違っていたら修正してください)

うわー-これは、クラッシュ報告プロセスを合理化し改善するための素晴らしい仕事のように思えます。

この質問が残っています:ユーザーはどのようにして問題の状態を知るのですか?ブループリントにはこの要件があります

ユーザーには、クラッシュレポートのステータスを確認する方法が必要です。たとえば、統計情報や関連するバグ番号を確認するために参照できるレポートIDがあります。たとえば、ファイリング時にシリアル番号を提供し、後でWebページ経由でロードできるようにします。

未実装のようです。その間に利用可能なものはありますか?

そして、開発者はどのようにしてゲームに参入しますか?行くhttps://daisy.ubuntu.comだけで「不正なContent-Typeの」エラーメッセージを提供します。

最後に、リリースノートでapportの動作の変更を文書化することをお勧めします。Ubuntuを助けようとしている人なら誰でも興味があるはずです。


回答:


45

Ubuntuエラートラッカープロジェクトに関心をお寄せいただきありがとうございます。

Precise 12.04から、この動作とワークフローが変更されました。Bug#993450「Apportがバグレポートを送信できない」で発見したように、デフォルトではapportはバグレポートを開かなくなりました(そして厄介ですが、そうすることは不可能ではありません)。

Apportは、リリース後にバグレポートを作成することはありません。リリースがまだ開発中の場合、apportを使用してLaunchpadのバグ(およびエラーレポート)を提出できます。

Ubuntuの最終リリースバージョンでは、エラーダイアログが表示されます。これは、フィードバックなしでプログラムが「消える」ことと、ユーザーに何が起こったのか疑問に思わせることからの大きな改善です。

これらのレポートの送信を選択したときに収集されたデータからの統計は、http://errors.ubuntu.comに表示されます。

この質問が残っています:ユーザーはどのようにして問題の状態を知るのですか?ブループリントにはこの要件があります

ユーザーには、クラッシュレポートのステータスを確認する方法が必要です。たとえば、統計情報や関連するバグ番号を確認するために参照できるレポートIDがあります。たとえば、ファイリング時にシリアル番号を提供し、後でWebページ経由でロードできるようにします。

これを削除します。それは決して意図ではありませんでした。ユーザーインターフェイスは、レポートに関するフィードバックの取得について約束しないように注意します。

これらはバグレポートではありません。

私たちの意図は、開発者が最も差し迫った問題を見つけ、それらを修正するために必要な情報を収集し、ユーザーに修正を提供するのにかかる時間を短縮することです。

最も差し迫った問題を見つける問題を解決しました。これがhttp://errors.ubuntu.comのフロントページです。

必要な情報を迅速に収集し、問題が発生しているユーザーとの長いフィードバックループを伴うことなく、Foundations-q-bucketing-improvementsで対処します。計画は、開発者がサーバー側の情報収集プロセスにフックできるようにすることです。/ var / log / syslogが必要なのにまだ提供されていない場合は、http://errors.ubuntu.comの設定を変更するだけで、エラーが発生した次の人が送信データに自動的に追加します。

修正をユーザーにすばやく取得することは、Foundations-q-updates-from-crash-reportsで対処されています。ユーザーがエラーレポートを送信し、そのエラーが既に修正およびリリースされている場合、発生した問題を修正するソフトウェアのバージョンにアップグレードするかどうかを尋ねるダイアログが表示されます。

そして、開発者はどのようにしてゲームに参入しますか?行くhttps://daisy.ubuntu.comだけで「不正なContent-Typeの」エラーメッセージを提供します。

http://daisy.ubuntu.comは、人間が使用するためのものではありません。エラー報告デーモン(whoopsie)がレポートを送信するためにあります。

他の人が参加することは絶対に素晴らしいことです。現在、このフルタイムでハッキングしているのは私だけです。

システムには4つの部分があります。

  • Apport。デスクトップユーザーインターフェイスを提供します。
  • WhoopsieはApportによって作成されたレポート(およびコアダンプ)を受け取り、それらをエラートラッカーサーバーであるDaisyにシャベルします。
  • デイジー Whoopsieからレポートを収集し、それらを処理し、。これがサービスの中心です。コアファイルをトレースされたレポートに変換し、http://errors.ubuntu.comで表示される統計を生成します。
  • Errorsは、DjangoベースのWebサイトであり、人間が読み取れるデータのビューと、データを操作するためのRESTful APIの両方を提供します。

lp:daisyの setup /ディレクトリの下に、スクリプトのセットが少し古いため、断片がどのように組み合わされるかについてのアイデアが得られます。私はこれを置き換えるためにjuju charmsに取り組んでいます。目標は、テストと開発のためにインフラストラクチャ全体をクラウドに展開する単一のコマンドです。

さらに開発に関する質問がある場合は、Launchpadで私のメールアドレスを見つけることができます。

詳細:


「人々がこれらのレポートの送信を選択したときに収集されたデータからの統計は、errors.ubuntu.comに表示されます。」アプリがサポートされているプログラミング言語で記述されている場合のみ、これは正しくありません。たとえば、モノで書かれたプログラムにはエラーが報告されていません。これは極端に差別的です。Ubuntuのも、活躍の場を提供し、それらが中に書かれている言語に基づいたプログラムを除外するべきではありません。
trampster

2
彼が一人でこれに取り組んでいる部分を逃したと思う、仲間。最初に一般的な言語をサポートしても問題はありません。
ヴァディムペレトキン

5
実際、@ Vadiは正しいです。これについて差別的なものは何もありません。誰かがMonoサポートを強化して実装したい場合は、喜んでレビューしてapportブランチをマージします。
エヴァン

4

独自のシステムからレポートを表示するには、https://bugs.launchpad.net/ubuntu/+source/apport/+bug/994921/comments/43で文書化されているように、これを試して ください。

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

Launchpadで特別な権限がないと、実際のレポートを表示できませんが、レポートされたプログラムを見ることができ、提供されたIDを使用して、適切な権限を持つ開発者と話すときにそれらを参照できます。


弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.