Reportsを読んだので、訳を試みておく。OpenBSDの問題の報告リリース済みのバージョンに関する問題の報告リリース済みのバージョンについて、バグや問題を報告する前には、以下のチェックリストを確認してください。このリリースについてのパッチと正誤表を確認してください。次に、より新しいバージョンさリリースされていないか確認してください。最後に、各バージョン間の変更履歴を確認してください。どれにもあなたの問題が含まれていなかった場合には、バグを報告する前にsendbug(1)コマンドについて学んでください。currentの問題の報告-releaseでも-stableでもなく、-currentのソースツリーにあなたの問題がある場合には、以下を確認してください。少なくとも2回、その問題をテストしてください。その時のソースコードは数日離れたものにしてください。ソースツリーがコンパイルできないという問題は、それが長く続くのでなければ報告しないでください。この種の問題はあなたのミスであるか、作業中のソースツリーを利用してしまっていることがほとんどです。buildを実行しています。普通は異なるアーキテクチャーで1日に等も実行しています。AnonCVSサーバーは、実際の作業中のソースツリーが反映されるのに数時間かかることを覚えておいてください。各バージョン間の変更履歴に既に掲載されていないか確認してください。スナップショットを作る際には、十分に注意していますが、時にはミスをすることもあります。その場合は謝罪します。バグ報告を送るより、メーリングリストで話をする方が適切です。常にできる限り多くの情報を提供するようにしてください。問題をピンポイントに絞り込むようにしてください。問題を再現できる明確な手順を教えてください。正確で混乱を生まないよ言葉を使うようにしてください。このことは、特に再現の難しい問題の場合には重要です。問題を説明するのに「クラッシュする」や「私の組み立てたマシンで奇妙な割り込みの問題が起きた」といった文は役に立ちません。(メーリングリストやその他の知識のある人の集まるフォーラムにおいて)他の人とコミュニケーションするには、あなたの抱える問題が新しいもので、できれば再現性のあるものであると分かってもらわなくてはなりません。壊れていたりサポートされていないハードウェアを使っていたり、ソフトウェアでサポートされていないビルドオプションを使っていたりすることによって生じる自分にしか関係しない問題ではないことを確認するようにしてください。多くの労力の必要な修正を、問題が明確になり、良く理解するより前に開始しないでください。リリース作業中は主要なコードを変更することは禁止されています。多量のコードを書こうとする時は、メーリングリストに投稿して、他の人が既にその問題に対して作業していないか確認してください(重複する作業を避けるためです)。以下の事項を全てのバグ報告に含めるようにしてください。問題を再現するのに必要な起動時からの正確な一連の作業を教えてください。これはその一連の作業の説明で完結するようにしてください。コマンドライン引数やデータの提供なしに、コマンド名だけ報告するのでは不十分です。バグを再現するのに特定の出来事の発生が必要であれば、それらを列挙してください。送ろうとする情報を最も単純にするようにしてみてください。これは必須ではありません。バグに再現性があるのであれば、他の状況でも問題になるはずです。あなたの見たアウトプットを教えてください。「動かなかった」や「失敗した」と伝えるのは止めてください。エラーメッセージが表示されたのであれば、もしその内容が理解できなかったとしても、それを提示してください。OpenBSDが特定のエラーでパニックしたのであれば、それを提示してください。あなたがテストした時には、プログラムがクラッシュしたり、他の明らかな不具合が発生したりしていても、プロジェクトのテスト環境では再現しないかもしれません。簡単なのは、可能であればターミナルからアウトプットをコピーして提示することです。致命的なエラーの場合には、エラーメッセージには全ての情報が含まれているかもしれません。このような場合には、システムログファイルへの出力も見てください。これは/var/logディレクトリーに格納されています。アプリケーションソフトウェアは、httpdのように自分自身でログを記録しているかもしれません。そちらのログにエラーが記録されていないかも確認してください。OpenBSDカーネルのアウトプットを教えてください。これがdmesgコマンドで取得できます。dmesgコマンドの出力が全ての情報を含んでいない場合には、/var/run/dmesg.bootファイルの内容も確認してください。この場合には、dmesgのアウトプットと/var/run/dmesg.bootの両方を含めてください。OpenBSDカーネルのアウトプットは全てのバグ報告で必須です。サードパーティーのソフトウェアを動かしていて、それがバグに関連している場合、そのバージョンも教えてください。スナップショットを使っているのであれば、その旨を書いた上で、日時も教えてください。カーネルパニックからのバックトレース結果を教えてください。カーネルがパニックしてddb(4)プロンプトに移行した場合、パニックメッセージと一緒にtraceコマンドの実行結果とpsコマンドの実行結果を含めることをおすすめします。ddb.console=1をハングするより前で設定し、Ctrl+Alt+Escをキーボードで入力し、DDBに移行してください(この時はXの画面であってはいけません)。シリアルコンソールの場合には、BREAKを送信してください。panicコマンドで再表示されることができます。これは可能であれば、いつでも含めるようにしてください。パニックメッセージとtraceコマンドの実行結果、psコマンドの実行結果のないカーネルパニックの報告は無意味です。registerコマンドの実行結果も役に立ちます。dumpコマンドで再起動すれば、カーネルイメージはsavecore(8)によって保存され、crash(8)のマニュアルページに説明されているように、後でデバッグすることができます。systemに関連する問題を報告する場合には、/var/log/Xorg.0.logファイルの内容をdmesg.bootファイルの内容と合わせて教えてください。バグ報告が長くなっても気にしないでください。最初に全てを報告してしぼり込んでいく方が良いです。あなたの使っている入力ファイルがとても大きい容量であれば、誰かが興味を持って見てくれるか、最初に聞くことも許されます。バグ報告を送る可能であれば、sendbug(1)コマンドをバグ報告を作成するのを助けるために使用してください。sendbug(1)コマンドは、自動的にハードウェアに関する有用な情報を取得してくれます。この情報は多くの問題を診断するのに役立ちます。このツールを使うには、あなたのマシンが適切に電子メールを送ることができることが必要です。正常に動くOpenBSDマシンでsendbug(1)コマンドを使うことができないならば、バグ報告をbug@OpenBSD.orgへ送ってください。バグ報告ではなく、新機能の要望を送ることもあるかもしれません。新機能についても受け付けます。新機能を実装したコードがあれば歓迎します。問題によっては、デバッグするのにハードウェアが必要になる場合があります。OpenBSDプロジェクトのリソースは限られているのを覚えておいてください。ハードウェアを寄付することが可能です。ある環境で仕事をせざるを得ない。Protectionのバージョンは14.0.xxxである。10.2というのがあって、まあ、企業で必要とするロギングはできるものなのであろう。Firefoxのアドオンを勝手に追加されるのは気に入らない。e10sとか阻害されても面白くないし。言うことで、試しに排除できるかやってみた。ExcelからVBAでアクセスしたい。個々の端末にODBCデータソースを設定するのはスクリプトで可能かもしれないが、面倒なのでADOとOLEDBの組み合わせでアクセスすることを考えている。