バグの報告は、Linuxの成長を支援する多くの方法の1つです。すべてのフリーソフトウェアディストリビューション、プロジェクトには、ソースコードを知っている人の数に応じて、バグが収集、分析、ラベル付け、修正されるさまざまなシステムがあります。
私はDebianが大好きなので、Debianでバグレポートを提出する方法を紹介します。
DebianLinuxのバグを報告する方法
バグを報告するためのDebianのgotoツールはReportbugです。 バグ報告を始めたときにそれを知っていたら、自分自身と保守者の胸焼けをかなり回避できたと思います。
DebianLinuxのバグレポートにReportbugをどのように使用できるか見てみましょう。
ステップ1.レポートバグのインストール
以下のコマンドを使用して、Reportbugをインストールします。
sudo aptitude install reportbug
ステップ2.Reportbug：最初の実行
Reportbugをインストールしたら、最初の実行時に、バグレポートの提出に使用できるように構成する必要があります。
以下のコマンドを使用して実行します。
reportbug
次に、以下のように一連のクエリを実行します。
このファイルには、以下に表示されるものとは異なる方法で解釈またはコンパイルされる可能性のある双方向Unicodeテキストが含まれています。確認するには、非表示のUnicode文字を表示するエディターでファイルを開きます。双方向Unicode文字の詳細非表示の文字を表示する| reportbugへようこそ！ reportbugを使用するのはこれが初めてのように見えるため、その動作を構成しています。これらの設定はファイル「/home/shirish/.reportbugrc」に保存され、さらに自由に編集できます。 | |
| レポートバグのデフォルトの動作モードを選択してください。 | |
| 1人の初心者技術的な質問をバイパスして簡単なプロンプトを表示します。 | |
| 2標準適度に洗練されたものについて尋ねるなど、より広範なプロンプトを提供しますユーザーはDebianについて知っていることが期待されます。 | |
| 3高度な標準と同様ですが、Debianについてもう少し知っていることを前提としています。 「着信」を含む。 | |
| 4エキスパートほとんどの手持ち対策と予備的なトリアージルーチンをバイパスします。このモードは、Debianのポリシーと操作手順に慣れていない人は使用しないでください。 | |
| モードの選択：[初心者] 2 | |
| レポートバグのデフォルトのインターフェースを選択してください。 | |
| 1テキストテキスト指向のコンソールユーザーインターフェイス | |
| 2 gtk2グラフィカル（GTK +）ユーザーインターフェイス。 | |
| インターフェースの選択：1 | |
| reportbugはインターネットに直接アクセスできることがよくありますか？ （自分が何をしているのかを理解しておらず、他のチャネルを介して重複したレポートが提出されているかどうかを確認する予定がない限り、この質問に「はい」と答える必要があります。）[Y | n | q |？]？ n | |
| バグレポートの送信に使用する実際の名前は何ですか？ | |
| [shirish]>： | |
| >バグレポートを送信するときに使用するメールアドレスはどれですか？ （このアドレスはバグ追跡システムに表示されるため、Webメールアドレスまたは優れたスパムフィルタリング機能を備えた別のアドレスを使用することをお勧めします。） | |
| [[メール保護]]＆gt;[メール保護] | >
Reportbugの初回実行に関する注意：
a。私はかなり長い間Debianを使用しているので、2と3を切り替えることができます。バグレポートに非常に慣れていない人は、初心者とデフォルトで表示される[1]に固執することができ、Enterキーを押すだけです。
b。テキストUIとgtk2/3インターフェースの間で、gtk2 / 3インターフェースは魅力的でなく、少しメモリを消費しているので、常に1を選択します。 gtk2 / 3エディターを選択した場合でも、以下の手順は同じですが、gtk-editorが同じことを少し美しく表示するのはあなただけです。
c。 Reportbugがネットアクセスを要求する部分私は、セキュリティの観点からだけでなく、実用的な観点からも常にそれを否定しています。私がそうする理由についてもう少し説明を以下に共有します。
d。最後に、名前を尋ねられたら、既存の名前が気に入った場合（[email protected]変数から取得）、Enterキーを押します。別の名前にしたい場合は、表示する名前を指定します。
ステップ3.Gmailの癖の処理
Reportbugを初めて実行すると、メールの設定が要求されます：
このファイルには、以下に表示されるものとは異なる方法で解釈またはコンパイルされる可能性のある双方向Unicodeテキストが含まれています。確認するには、非表示のUnicode文字を表示するエディターでファイルを開きます。双方向Unicode文字の詳細非表示の文字を表示する| 「メールトランスポートエージェント」（MTA）はありますか）インターネットにメールを送信するようにこのコンピューターで構成されたExim、Postfix、またはSSMTPのように？ [y | N | q |？]？n | |
| SMTPホストの名前を入力してください。通常、「mail.example.org」や「smtp.example.org」などと呼ばれます。デフォルトとは異なるポートを使用する必要がある場合は、：代替形式を使用してください。持っていないかわからない場合はEnterキーを押すだけで、DebianSMTPホストが使用されます。 | |
| > | |
| プロキシサーバーの名前を入力してください。このパラメータは、ファイアウォールの背後にいる場合にのみ使用する必要があります。 PROXY引数は、（必要に応じて）ポート番号を含む有効なHTTPURLとしてフォーマットする必要があります。たとえば、http：//192.168.1.1：3128/です。持っていないかわからない場合は、Enterキーを押してください。 | |
| > |
最初の質問は、メールを自動的に送信できるソフトウェアがあるかどうかを尋ねるものです。
EvolutionやThunderbirdなどのデスクトップ電子メールクライアントをセットアップしている場合は、[はい]を選択します。それ以外の場合は、いいえ。
デフォルトの設定ファイルが書き込まれると、それは/home/shirish/.reportbugrcに保存されます。このファイルを編集することで、後で構成を変更できます。
コンソールでは、 CTRL + Cを使用できます いつでもReportbugを終了します。
ステップ5.バイナリからアプリケーションパッケージ名を把握する
アイゼルリオットを例にとってみましょう。お母さんがよく遊ぶGTKカードゲームのひとつです。ゲームに問題がある場合、どのパッケージでバグレポートを提出する必要があるかをどのように知ることができますか？
したがって、GUIアプリケーションのトラブルシューティングを行うときに最初に行うことは、アイコンを取得してパネルに配置し、ここに示しているようにそのプロパティを確認することです–
これで、アプリの名前がわかりました。はAiselriotではなくsolであり、アプリケーションが配置されるパスは/usr/games/solにあります。 。
それでは、パッケージの名前を見つけてみましょう–
dpkg -S /usr/games/sol出力は次のとおりです。
aisleriot: /usr/games/solこのパッケージはaiselriotとも呼ばれていますが、これが常に行われるわけではありません。
次に、最初のバグレポートを報告しましょう。数か月で安定するようにDebianテスト/ストレッチ/間もなく使用しているので、そこにバグレポートを載せます。
ステップ6.Reportbugを使用してバグレポートを作成する
ここで、Debianコミュニティに報告する必要のある問題/バグを含むパッケージが必要です。
私は、要点に示されているようにReportbugに目を向けた問題の症状を示したパッケージpiupartsを持っています：
このファイルには、以下に表示されるものとは異なる方法で解釈またはコンパイルされる可能性のある双方向Unicodeテキストが含まれています。確認するには、非表示のUnicode文字を表示するエディターでファイルを開きます。双方向Unicode文字の詳細非表示の文字を表示する| [$] reportbug piuparts –severity =normal | |
| ***reportbugへようこそ。使用する ？プロンプトでのヘルプ。 *** | |
| 注：バグレポートは公開されています（送信者のメールアドレスを含む） 。 | |
| 検出された文字セット：UTF-8 | |
| これが正しくない場合は、ロケールを変更してください。 | |
| 差出人アドレスとして「shirish」を使用します。 | |
| piupartsのステータスを取得しています… | |
| パッケージの整合性を確認しています… | |
| Debianにレポートを送信します（lsb_releaseごと）。 | |
| piupartsのメンテナは「piuparts開発者チーム」です。 | |
| piupartsの依存関係を検索しています… | |
| 変更された構成ファイルの取得… | |
| 問題を簡単に説明します（最大100文字が許可されます）。これはバグのメールの件名になりますので、要約はできるだけ簡潔にしてください。 | |
| 例：「メールの送信に失敗しました」または「-で始まらないqオプションが指定されました」（Ctrl + cを入力して、バグを報告せずにreportbugを終了します） | |
| >適切なレポートは廃止されました-piupartsのconffile | |
| 「piuparts：適切なレポートは廃止されました-piupartsのconffile」の対象ですか？ | |
| このレポートに次のいずれかを適用してください | |
| 1d-iこのバグはdebian-installerの開発に関連しています。 | |
| 2 ipv6このバグは、インターネットプロトコルバージョン6のサポートに影響します。 | >|
| 3l10nこのバグはローカリゼーション/国際化の問題を報告します。 | |
| 4 lfsこのバグは、大きなファイル（2ギガバイト以上）のサポートに影響します。 | |
| 5 newcomerこのバグには既知の解決策がありますが、メンテナは他の誰かに実装を要求します | |
| 6パッチこの問題を修正するパッチが含まれています。 | >|
| 7アップストリームこのバグはパッケージのアップストリーム部分に適用されます。 | |
| 8なし | |
| タグを選択してください:(一度に1つずつ）[なし] |
それでは、物事がどのように機能しているかを説明しましょう。パッケージをインストールするときは、適切と呼ばれるツール（Debianパッケージチェックツール）を使用します。適切なことについては、今後のブログ投稿で詳しく説明します。
Reportbugが行うことは、パッケージに関するすべての情報を取得して解析し、先に進むかどうかを認識できるようにすることです。
これで、ツールは常にバックグラウンドで適切に実行されます。その主な仕事の1つは、パッケージのインストールの最後に発生します。 piupartsの場合、これを共有/表示しました–
adequate found packaging bugs
-----------------------------
piuparts: obsolete-conffile /etc/piuparts/scripts/post_setup_experimentalこれは、piupartsパッケージに廃止されたconffileがあることを教えてくれました。 Conffileは構成ファイルの略です。
したがって、報告する価値のあるバグを見つけたときに最初に行うコマンドは、これを行うことです–
reportbug piuparts --severity=normal問題のあるパッケージ（この場合はpiuparts）について説明/通知します。
バグに重大度を設定するのは難しい作業です。私がパッケージについてかなり強い感情を持っていて、バグが本当に深刻であることを疑いの余地なく知っていない限り、私は深刻さを上げません。これは私自身の個人的な倫理であり、保守者の仕事も少し少なくなります。
そうは言っても、ほとんどのメンテナは、あなたがどんな重大度を与えても、バグを見るでしょう。ウィッシュリストのバグを提出した場合でも、メンテナに迅速に対応してもらい、メンテナが戻ってこないようにしています。深刻なバグを提出した後でも、MIA（Missing-In-Action）。ファイリングとメンテナとの健全な会話は、技術的かつ社会的な活動です。
件名を尋ねた後、reportbugは、条件の1つが当てはまるかどうかを尋ねたり、さまざまなオプションを提供したりします。バグが影響を受けている、またはリストにある上記のいずれかに影響を与えていると思われる場合は、いずれかを使用できます。たとえば、問題を修正するためのパッチを共有する場合は、6つまたは他の1つを選択します。どれも必要ない場合は、入力して先に進んでください。
上記が完了すると、少し時間がかかり、この共有の要点に似たものが得られます：
このファイルには、以下に表示されるものとは異なる方法で解釈またはコンパイルされる可能性のある双方向Unicodeテキストが含まれています。確認するには、非表示のUnicode文字を表示するエディターでファイルを開きます。双方向Unicode文字の詳細非表示の文字を表示する| 件名：piuparts：適切なレポートでpiupartsのconffileが廃止されました | |
| パッケージ：piuparts | |
| バージョン：0.75 | |
| 重大度：通常 | |
| 親愛なるメンテナ、 | |
| ***レポーター、必要に応じて、これらの質問に回答することを検討してください** * | |
| * What led up to the situation? | |
| * What exactly did you do (or not do) that was effective (or | |
| ineffective)? | |
| * What was the outcome of this action? | |
| * What outcome did you expect instead? | |
| ** End of the template – remove these template lines ** | |
| — System Information: | |
| Debian Release:9.0 | |
| APT prefers testing | |
| APT policy:(600, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (1, 'experimental-debug'), (1, 'experimental'), (1, 'unstable') | |
| Architecture:amd64 (x86_64) | |
| Foreign Architectures:i386 | |
| Kernel:Linux 4.9.0-1-amd64 (SMP w/2 CPU cores) | |
| Locale:LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) | |
| Shell:/bin/sh linked to /bin/dash | |
| Init:systemd (via /run/systemd/system) | |
| Versions of packages piuparts depends on: | |
| ii debootstrap 1.0.87 | |
| ii debsums 2.2 | |
| ii dpkg 1.18.18 | |
| ii lsb-release 9.20161125 | |
| ii lsof 4.89+dfsg-0.1 | |
| ii piuparts-common 0.75 | |
| ii python-debian 0.1.30 | |
| pn python:any | |
| Versions of packages piuparts recommends: | |
| ii adequate 0.15.1 | |
| Versions of packages piuparts suggests: | |
| ii schroot 1.6.10-3 | |
| — no debconf information |
Now what this does is, it gives an idea to the maintainer of the state of your system. As you all know, almost all GNU/Linux distributions and the packages therein are based on a complex set of relationships with other packages. The maintainer needs to know what version of the package you were using, which other packages were there, what version were they at, apart from knowing that the integrity of the package hasn’t been tampered with in any way.
Now you need to fill in the banks –
I usually remove/delete cut the following, if you are a new user you could just answer the questions below and your bug report would be ready.
Step 7. The final changes made to spend the report
And in its place, I put the details as being shared right here:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters Show hidden characters| Subject:piuparts:adequate reports obsolete conffile for piuparts | |
| Package:piuparts | |
| Version:0.75 | |
| Severity:normal | |
| User:[email protected] | |
| Usertags:obsolete-conffile adequate | |
| Dear Maintainer, | |
| Adequate reports broken obsolete-conffile – | |
| [$] adequate piuparts | |
| piuparts:obsolete-conffile /etc/piuparts/scripts/post_setup_experimental | |
| Maybe you could use what pabs (Paul Wise) did in #815563, in that the | |
| proper thing to do would be – | |
| Use the dpkg-maintscript-helper support provided by dh_installdeb to remove such similar obsolete conffiles on upgrade | |
| Also https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files | |
| You can also see manpage of dh_installdeb via debhelper package which is the same thing. | |
| I ran the same command as he did – | |
| [$] pkg=piuparts; adequate $pkg; dpkg-query -W -f='${Conffiles}\n' $pkg | grep obsolete | |
| piuparts:obsolete-conffile /etc/piuparts/scripts/post_setup_experimental | |
| /etc/piuparts/scripts/pre_remove_40_find_obsolete_conffiles | |
| dce83ee504ba336d8a2930fb6053635c | |
| /etc/piuparts/scripts/post_setup_experimental | |
| f7a1f3d45dc43106d1cd9b124b7c1ca8 obsolete | |
| Please fix the above. | |
| — System Information: | |
| Debian Release:9.0 | |
| APT prefers testing | |
| APT policy:(600, 'testing'), (500, 'unstable-debug'), (500, | |
| 'testing-debug'), (1, 'experimental-debug'), (1, 'experimental'), (1, | |
| 'unstable') | |
| Architecture:amd64 (x86_64) | |
| Foreign Architectures:i386 | |
| Kernel:Linux 4.9.0-1-amd64 (SMP w/2 CPU cores) | |
| Locale:LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) | |
| Shell:/bin/sh linked to /bin/dash | |
| Init:systemd (via /run/systemd/system) | |
| Versions of packages piuparts depends on: | |
| ii debootstrap 1.0.87 | |
| ii debsums 2.2 | |
| ii dpkg 1.18.18 | |
| ii lsb-release 9.20161125 | |
| ii lsof 4.89+dfsg-0.1 | |
| ii piuparts-common 0.75 | |
| ii python-debian 0.1.30 | |
| pn python:any | |
| Versions of packages piuparts recommends: | |
| ii adequate 0.15.1 | |
| Versions of packages piuparts suggests: | |
| ii schroot 1.6.10-3 | |
| — no debconf information |
Some more info. now – These two tags signal/tell the maintainers few things –
User: [email protected]The first tag is signaling that the bug being raised is part of debian-qa efforts.
Usertags: obsolete-conffile adequateThe second tag is telling the tool we have used and one of the common issues under which it has come -in this case obsolete-conffile.
There are few common and uncommon use-cases that adequate looks into. As shared before, will need another blog post to share about it in detail.
The other thing I’m telling/sharing the maintainer is s/he should be looking into debhelper (a toolkit for debian/rules) and to look for specific bits therein.
Tip – Paul Wise, better known as pabs in Debian community. He is a prolific contributor to Debian. As you can see from his wiki page and the secondary apps. He always has a never-ending list of applications, packages that would be interesting to package alongwith things that could be/need to be improved. I dunno if he has done any mentoring or not, do see signs of a good and goofy mentor in him. I sometimes ask, sometimes steal his ideas to help in Debian QA :)
Now, that the bug-report is complete, I have to send it via gmail.com . If you have enabled MTA (Mail Transfer Agent) and don’t have a gmail.com you can just send and it will be done. If on the other hand, you haven’t enabled MTA (like me) and like to do things yourself, log on to your gmail account, hit compose and then –
Step 8. The final step
To - [email protected]
Subject - piuparts: adequate reports obsolete conffile for piupartsBody of your mail should start with Package
something like this –
You might have noticed some labels, they are just to help me be somewhat organized as after you have reported some bugs it can become chaotic to know what’s going on. Gmail’s labels and filters make things somewhat sanish with the amount of mail I receive.
At that point, make sure to recheck the mail once more before clicking the send mail button. I usually click on save draft, review it once or twice before sending it over.
If you are satisfied click send and your bug-report will be sent to Debian BTS .
Step 9. Getting acknowledgment from Debian BTS server saying the bug has reached them.
Usually, within minutes I get a short acknowledgment mail from the Debian BTS, like in the gist being shared
Look at the time-stamp given, just 3 minutes apart from when the mail was sent. I sent the bug mail on 05:03 and got the automated reply saying everything went fine on 05:06 itself.
What I look for into the acknowledgment mail is the bug number as that is how I come to know how things are going with the bug. #854317
Post bug-reporting cycle.
Coincidentally, as can be seen, the package maintainer somehow was around the time when I filed the bug. I do know the importance of piuparts in the debian ecosystem but I didn’t think Andreas will act so quickly, so now probably the next point release or even bug-fix release will have the fix. As can be seen though, Andreas seems to be a busy bee seeing the number of packages he’s maintaining/co-maintaining, besides uploading Non-Maintainer Uploads (NMU) and QA uploads.
I hope I have given enough insight so you know what to do as and when things go wrong.
Tip – Nowadays, I usually follow couple of rules before filing a bug. First check the bts for existing list of bugs, for e.g. piuparts bugs page (as also shared by Simon Tatham above). If the bug is not listed there, more often than not, it the package has not too many dependencies, and I know there aren’t any configuration files that I might have to recreate then I usually purge the package and install the package afresh. If adequate still finds a fault, I usually report it. I don’t do that though for obsolete conffiles as they usually happen when you are upgrading from version x.1 to x.2 or something like that.
Using such simple tips I save time and energy for myself as well as the maintainer of a package.
At first, it may take sometime, after a while, the whole thing may take 10-15 minutes or even less, depending on the package in which the bug is found, the bug itself, replication of the bug etc.
That’s about it to make a bug-report in Debian using Reportbug.
Hopefully, you have gotten some idea the steps to finding bugs and reporting them. Please post any queries you have in the comments below and I’ll try my best to answer/share whatever little I know.