developers-reference - en to ja translation catalogue (78 entries)

en: Beyond Packaging
ja: パッケージ化、そして…

en: Debian is about a lot more than just packaging software and maintaining those packages. This chapter contains information about ways, often really critical ways, to contribute to Debian beyond simply creating and maintaining packages.
ja: Debian は、単にソフトウェアのパッケージを作ってメンテナンスをしているだけではありません。この章では、単にパッケージを作ってメンテナンスする以外で Debian へ協力・貢献するやり方、多くの場合とても重要となるやり方の情報を取り扱います。

en: As a volunteer organization, Debian relies on the discretion of its members in choosing what they want to work on and in choosing the most critical thing to spend their time on.
ja: ボランティア組織の例にたがわず、Debian の活動はメンバーが何をしたいのか、時間を割くのに最も重大だと思われることが何か、というメンバーの判断に依っています。

en: Bug reporting
ja: バグ報告

en: We encourage you to file bugs as you find them in Debian packages. In fact, Debian developers are often the first line testers. Finding and reporting bugs in other developers' packages improves the quality of Debian.
ja: 我々としては、Debian パッケージで見つけたバグを登録することを勧めています。実際のところ、大抵の場合は Debian 開発者が第一線でのテスト作業者となっています。他の開発者のパッケージで見つけたバグを報告することで Debian の品質が向上されています。

en: Read the `instructions for reporting bugs <https://www.debian.org/Bugs/Reporting>`__ in the Debian `bug tracking system <https://www.debian.org/Bugs/>`__.
ja: Debian `バグ追跡システム (BTS) <https://www.debian.org/Bugs/>`__ の `バグ報告のやり方について (instructions for reporting bugs) <https://www.debian.org/Bugs/Reporting>`__ を参照してください。

en: Try to submit the bug from a normal user account at which you are likely to receive mail, so that people can reach you if they need further information about the bug. Do not submit bugs as root.
ja: いつも使っているメールを受け取れるユーザアカウントからバグを送ってみてください。そうすることで、開発者がそのバグに関するより詳細な情報を必要とする場合にあなたに尋ねることができます。root ユーザでバグを報告しないでください。

en: You can use a tool like reportbug 1 to submit bugs. It can automate and generally ease the process.
ja: バグを報告するには、reportbug 1 のようなツールが使えます。これによって作業を自動化し、かなり簡単なものにできます。

en: Make sure the bug is not already filed against a package. Each package has a bug list easily reachable at ``https://bugs.debian.org/``\ *packagename*. Utilities like querybts 1 can also provide you with this information (and ``reportbug`` will usually invoke ``querybts`` before sending, too).
ja: パッケージに対して既にバグが報告されていないことを確認しておいてください。個々のパッケージに対するバグのリストは ``https://bugs.debian.org/``\ *パッケージ名* にて簡単に確認できます。querybts 1 のようなユーティリティでもこの情報を入手できます (なお、``reportbug`` では大抵の場合、バグを送信する前に ``querybts`` の実行も行っています)。

en: Try to direct your bugs to the proper location. When for example your bug is about a package which overwrites files from another package, check the bug lists for *both* of those packages in order to avoid filing duplicate bug reports.
ja: 正しい所にバグを報告する様に心がけてください。例えばあるパッケージが他のパッケージのファイルを上書きしてしまうバグの場合ですが、バグ報告が重複して登録されるのを避けるため、これらのパッケージの\ *両方*\ のバグリストを確認してください。

en: For extra credit, you can go through other packages, merging bugs which are reported more than once, or tagging bugs ``fixed`` when they have already been fixed. Note that when you are neither the bug submitter nor the package maintainer, you should not actually close the bug (unless you secure permission from the maintainer).
ja: さらに言うと、他のパッケージについても、何度も報告されているバグをマージしたり既に修正されているバグに「fixed」タグをつけたりすることもできます。そのバグの報告者であったりパッケージメンテナではない場合は (メンテナから許可をもらっていなければ)、実際にバグをクローズしてはいけないことに注意してください。

en: From time to time you may want to check what has been going on with the bug reports that you submitted. Take this opportunity to close those that you can't reproduce anymore. To find out all the bugs you submitted, you just have to visit ``https://bugs.debian.org/from:``\ *your-email-addr*.
ja: 時折、あなたが登録したバグ報告について何が起こっているのかをチェックしたくなることでしょう。これは、もう再現できないものをクローズするきっかけになります。報告した全てのバグ報告を確認するには、\ ``https://bugs.debian.org/from:``\ *your-email-addr* を参照すればいいだけです。

en: Reporting lots of bugs at once (mass bug filing)
ja: 一度に大量のバグを報告するには (mass bug filing)

en: Reporting a great number of bugs for the same problem on a great number of different packages — i.e., more than 10 — is a deprecated practice. Take all possible steps to avoid submitting bulk bugs at all. For instance, if checking for the problem can be automated, add a new check to ``lintian`` so that an error or warning is emitted.
ja: 大量の異なるパッケージに対して、同じ問題についての非常に多くのバグ (例えば 10 個以上) を報告するのは、推奨されていないやり方です。不要なバグ報告を避けるため、可能な限りの手続きを踏むようにしましょう。例えば、問題の確認を自動化できる場合は ``lintian`` に新しくチェック項目を追加すれば、エラーや警告が明確になります。

en: If you report more than 10 bugs on the same topic at once, it is recommended that you send a message to ``debian-devel@lists.debian.org`` describing your intention before submitting the report, and mentioning the fact in the subject of your mail. This will allow other developers to verify that the bug is a real problem. In addition, it will help prevent a situation in which several maintainers start filing the same bug report simultaneously.
ja: 同じ問題について一度に 10 個以上のバグを報告する場合は、バグ報告を登録する前に ``debian-devel@lists.debian.org`` へ送ることをお勧めします。バグ報告を送る前に注意点を記述し、メールのサブジェクトに事実を挙げておきます。これで他の開発者がそのバグが本当に問題であるかどうかを確認できるようになります。さらに、これによって複数のメンテナが平行して同じバグ報告を登録するのを防止できるようになります。

en: Please use the programs ``dd-list`` and if appropriate ``whodepends`` (from the package ``devscripts``) to generate a list of all affected packages, and include the output in your mail to ``debian-devel@lists.debian.org``.
ja: ``dd-list`` プログラムを利用することと、明確になっているのであれば影響を受けるパッケージのリストを (``devscripts`` パッケージの) ``whodepends`` を使って出力して、\ ``debian-devel@lists.debian.org`` へのメールに含めて下さい。

en: Note that when sending lots of bugs on the same subject, you should send the bug report to ``maintonly@bugs.debian.org`` so that the bug report is not forwarded to the bug distribution mailing list.
ja: 同じサブジェクトで大量のバグを送信する際は、バグ報告がバグ情報用メーリングリストへ転送されないように　\ ``maintonly@bugs.debian.org`` へバグ報告を送るべきであるの注意してください。

en: Usertags
ja: Usertag

en: You may wish to use BTS usertags when submitting bugs across a number of packages. Usertags are similar to normal tags such as 'patch' and 'wishlist' but differ in that they are user-defined and occupy a namespace that is unique to a particular user. This allows multiple sets of developers to 'usertag' the same bug in different ways without conflicting.
ja: 多数のパッケージに対するバグを登録する際に BTS の usertag を使いたくなるかもしれません。usertag は 'patch' や 'wishlist' のような通常のタグに似ていますが、ユーザが定義する事と特定のユーザに対して一意な名前空間を占めるという点で違っています。これによって、同じバグについて衝突する事無しに、開発者がそれぞれ別のやり方で複数の設定ができるようになります。

en: To add usertags when filing bugs, specify the ``User`` and ``Usertags`` pseudo-headers:
ja: バグを登録する際に usertag を追加するには、擬似ヘッダ (pseudo-header) ``User`` と ``Usertags`` を指定します。

en: To view bugs tagged with a specific usertag, visit ``https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=``\ *email-addr*\ ``&tag=``\ *tag-name*.
ja: 特定の usertag でバグを参照する場合は ``https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=``\ *メールアドレス*\ ``&tag=``\ *タグ名* を指定してください。

en: Quality Assurance effort
ja: 品質維持の努力

en: Daily work
ja: 日々の作業

en: Even though there is a dedicated group of people for Quality Assurance, QA duties are not reserved solely for them. You can participate in this effort by keeping your packages as bug-free as possible, and as lintian-clean (see :ref:`lintian`) as possible. If you do not find that possible, then you should consider orphaning some of your packages (see :ref:`orphaning`). Alternatively, you may ask the help of other people in order to catch up with the backlog of bugs that you have (you can ask for help on ``debian-qa@lists.debian.org`` or ``debian-devel@lists.debian.org``). At the same time, you can look for co-maintainers (see :ref:`collaborative-maint`).
ja: 品質保証に割り当てられたグループの人々がいたとしても、QA 作業は彼らのみに課せられるものではありません。あなたもパッケージを可能な限りバグが無いように保ち、できるだけ lintian clean な状態 (:ref:`lintian` を参照) にすることで品質保証の作業に参加することができるのです。それが可能ではないように思えるなら、パッケージをいくつか「放棄 (orphan)」してください (:ref:`orphaning` 参照)。または、溜まったバグ処理に追いつくため、他の人々に助力を願い出ることも可能です (``debian-qa@lists.debian.org`` や ``debian-devel@lists.debian.org`` で助けを求めることができます)。同時に共同メンテナ (co-maintainer) を探すことも可能です (:ref:`collaborative-maint` を参照してください)。

en: Bug squashing parties
ja: バグ潰しパーティ (BSP)

en: If you don't feel confident about doing an NMU, just send a patch to the BTS. It's far better than a broken NMU.
ja: NMU をする自信が無い場合は、BTS へパッチを投げるだけにしてください。NMU でパッケージを壊してしまうより、遥かに良いことです。

en: Contacting other maintainers
ja: 他のメンテナに連絡を取る

en: During your lifetime within Debian, you will have to contact other maintainers for various reasons. You may want to discuss a new way of cooperating between a set of related packages, or you may simply remind someone that a new upstream version is available and that you need it.
ja: Debian と共に過ごす間、様々な理由で他のメンテナに連絡を取りたくなることでしょう。関連パッケージ間での共同作業の新たなやり方について協議したい場合や、開発元で自分が使いたい新しいバージョンが利用可能になっていることを単に知らせたい場合などです。

en: Looking up the email address of the maintainer for the package can be distracting. Fortunately, there is a simple email alias, *package*\ ``@packages.debian.org``, which provides a way to email the maintainer, whatever their individual email address (or addresses) may be. Replace *package* with the name of a source or a binary package.
ja: パッケージメンテナのメールアドレスを探しだすのは骨が折れます。幸いな事に、\ *パッケージ名*\ ``@packages.debian.org`` というシンプルなメールのエイリアスがあり、メンテナらの個人アドレスが何であれメンテナへメールを届ける手段となっています。\ *パッケージ名* はパッケージのソース名かバイナリパッケージ名に置き換えてください。

en: You may also be interested in contacting the persons who are subscribed to a given source package via :ref:`pkg-tracker`. You can do so by using the *package*\ ``@packages.qa.debian.org`` email address.
ja: :ref:`pkg-tracker` 経由でソースパッケージの購読を行っている人に連絡を取りたくなるかもしれません。その場合は *パッケージ名*\ ``@packages.qa.debian.org`` メールアドレスが使えます。

en: Dealing with inactive and/or unreachable maintainers
ja: 活動的でない、あるいは連絡が取れないメンテナに対応する

en: There is a simple system (the MIA database) in which information about maintainers who are deemed Missing In Action is recorded. When a member of the QA group contacts an inactive maintainer or finds more information about one, this is recorded in the MIA database. This system is available in ``/org/qa.debian.org/mia`` on the host ``qa.debian.org``, and can be queried with the ``mia-query`` tool. Use ``mia-query --help`` to see how to query the database. If you find that no information has been recorded about an inactive maintainer yet, or that you can add more information, you should generally proceed as follows.
ja: Missing In Action (行方不明) だと考えられているメンテナについての情報が記録されるシンプルなシステム (MIA データベース) があります。品質保証グループ (QA グループ) のメンバーが活動的ではないメンテナに連絡を取った場合や、そのメンテナについて新たな情報がもたらされた場合、その記録が MIA データベースに残されます。このシステムは ``qa.debian.org`` ホスト上の ``/org/qa.debian.org/mia`` で利用可能になっており、\ ``mia-query`` ツールで検索ができます。どうやってデータベースを検索するのかについては ``mia-query --help`` と入力してください。活動的ではないメンテナについての情報がまだ記録されていない、あるいはそのメンテナについての情報を追加できる場合は、おおよそ以下の手続きを行う必要があります。

en: The first step is to politely contact the maintainer, and wait a reasonable time for a response. It is quite hard to define reasonable time, but it is important to take into account that real life is sometimes very hectic. One way to handle this would be to send a reminder after two weeks.
ja: 最初の一歩はメンテナに丁寧にコンタクトを取り、応答するのに充分な時間待つことです。充分な時間というのを定義するのは非常に困難ですが、実生活では時折非常に多忙になるのを考慮に入れると重要なことです。一つのやり方としては、リマインダーを二週間後に送るという方法があります。

en: If the maintainer doesn't reply within four weeks (a month), one can assume that a response will probably not happen. If that happens, you should investigate further, and try to gather as much useful information about the maintainer in question as possible. This includes:
ja: メンテナが４週間 (１ヶ月）応答をしない場合、おそらく反応がないと判断できます。この様な場合はより詳細に確認し、可能な限り問題となっているメンテナに関する有用な情報をかき集める必要があります。これには以下のようなものが含まれています。

en: The ``echelon`` information available through the `developers' LDAP database <https://db.debian.org/>`__, which indicates when the developer last posted to a Debian mailing list. (This includes mails about uploads distributed via the ``debian-devel-changes@lists.debian.org`` list.) Also, remember to check whether the maintainer is marked as on vacation in the database.
ja: `開発者 LDAP データベース <https://db.debian.org/>`__ を通じて得られる ``echelon`` 情報は、開発者が最後に Debian メーリングリストに投稿したはいつなのかを示します (これには ``debian-devel-changes@lists.debian.org`` での配布物のアップロードのメールも含まれます)。また、データベースでメンテナが休暇中かどうかも確認してください

en: The number of packages this maintainer is responsible for, and the condition of those packages. In particular, are there any RC bugs that have been open for ages? Furthermore, how many bugs are there in general? Another important piece of information is whether the packages have been NMUed, and if so, by whom.
ja: このメンテナが対応しているパッケージ数やパッケージの状態。特に、長期間放置され続けている RC バグがあるかどうか? さらに通常どの程度の数のバグがあるか? もう一つの重要な情報はパッケージが NMU されているかどうか、されているとしたら誰によって行われているか、です。

en: Is there any activity of the maintainer outside of Debian? For example, they might have posted something recently to non-Debian mailing lists or news groups.
ja: Debian 以外でメンテナの活動があるかどうか? 例えば、近頃 Debian 以外のメーリングリストや news グループへの投稿をしているなど。

en: A bit of a problem are packages which were sponsored — the maintainer is not an official Debian developer. The ``echelon`` information is not available for sponsored people, for example, so you need to find and contact the Debian developer who has actually uploaded the package. Given that they signed the package, they're responsible for the upload anyhow, and are likely to know what happened to the person they sponsored.
ja: パッケージがスポンサーされている、つまりメンテナが公式の Debian 開発者ではない場合はちょっとした問題となります。例えば ``echelon`` の情報は、スポンサーされている人は利用できません。そのため実際にパッケージをアップロードした Debian 開発者を探して確認を取る必要があります。彼らがパッケージにサインしたということは、アップロードについて何であれ責任を持ち、スポンサーした人に何が起こっているかを知っていそうだということです。

en: It is also allowed to post a query to ``debian-devel@lists.debian.org``, asking if anyone is aware of the whereabouts of the missing maintainer. Please Cc: the person in question.
ja: ``debian-devel@lists.debian.org`` に、活動が見えないメンテナの居所に誰か気づいているかという質問を投稿するのもありです。問題の人を Cc: に入れてください。

en: Once you have gathered all of this, you can contact ``mia@qa.debian.org``. People on this alias will use the information you provide in order to decide how to proceed. For example, they might orphan one or all of the packages of the maintainer. If a package has been NMUed, they might prefer to contact the NMUer before orphaning the package — perhaps the person who has done the NMU is interested in the package.
ja: ここに書かれた全てを収集したなら、\ ``mia@qa.debian.org``\ に連絡しましょう。この名前の宛先を担当している人は、あなたが供給した情報を使ってどう進めるかを判断します。例えば、そのメンテナのパッケージの一部または全てを放棄 (Orphan) するかもしれません。パッケージがNMUされていた場合は、パッケージを放棄 (Orphan) する前にNMUをした人に連絡する事を選ぶかもしれません — NMUをした人はきっとパッケージに関心があるでしょうから。

en: One last word: please remember to be polite. We are all volunteers and cannot dedicate all of our time to Debian. Also, you are not aware of the circumstances of the person who is involved. Perhaps they might be seriously ill or might even have died — you do not know who may be on the receiving side. Imagine how a relative will feel if they read the e-mail of the deceased and find a very impolite, angry and accusing message!
ja: 最後に一言: 礼儀正しく振る舞いましょう。我々は所詮ボランティアで、全ての時間を Debian に捧げられるわけではありません。また、関わっている人の状況がわかるわけでもありません。重い病気にかかっているかかもしれないし、あるいは死んでしまっているかもしれません - メッセージを受け取る側にどんな人がいるかは分かりません。亡くなった方のご親戚の方がメールを読んだ場合に、非常に無礼で怒った叱責調のメッセージを見つけてどうお感じになるかを想像してください。

en: Interacting with prospective Debian developers
ja: Debian 開発者候補に対応する

en: Debian's success depends on its ability to attract and retain new and talented volunteers. If you are an experienced developer, we recommend that you get involved with the process of bringing in new developers. This section describes how to help new prospective developers.
ja: Debian の成功は新たな才能あるボランティアをどう魅了し確保するかにかかっています。あなたが経験豊かな開発者なら、新たな開発者を呼び込むプロセスに関与するべきです。このセクションでは新たな開発者候補者をどうやって手助けするのかについて記述します。

en: Sponsoring packages
ja: パッケージのスポンサーを行う

en: Sponsoring a package means uploading a package for a maintainer who is not able to do it on their own. It's not a trivial matter; the sponsor must verify the packaging and ensure that it is of the high level of quality that Debian strives to have.
ja: パッケージのスポンサーをするというのは、パッケージをアップロードする権限をもたないメンテナーのためにかわりにアップロードするということです。アップロードを軽く考えてはなりません。スポンサーはパッケージを検証し、Debianに含まれるのにふさわしい高水準の品質であることを担保すべきです。

en: Debian Developers can sponsor packages. Debian Maintainers can't.
ja: Debian 開発者はパッケージをスポンサーできます。Debian メンテナはできません。

en: The process of sponsoring a package is:
ja: パッケージのスポンサー作業の流れは以下の通りです:

en: The maintainer prepares a source package (``.dsc``) and puts it online somewhere (like on `mentors.debian.net <https://mentors.debian.net/cgi-bin/welcome>`__) or even better, provides a link to a public VCS repository (see :ref:`salsa-debian-org`) where the package is maintained.
ja: メンテナーはソースパッケージ (``.dsc``)  を準備し、オンラインで参照できるどこかにアップロード (例えば `mentors.debian.net <https://mentors.debian.net/cgi-bin/welcome>`__) や他のどこか適切な場所にアップロードし、パッケージをメンテナンスしている公開されているVCSリポジトリ (:ref:`salsa-debian-org` を参照) を示します。

en: The sponsor downloads (or checks out) the source package.
ja: スポンサーはソースパッケージをダウンロード (もしくはチェックアウト)します。

en: The sponsor reviews the source package. If they find issues, they inform the maintainer and ask them to provide a fixed version (the process starts over at step 1).
ja: スポンサーはソースパッケージをレビューします。問題を見つけたら、メンテナに知らせて修正版をくれるように尋ねます (作業は step 1 へやり直しされます)。

en: The sponsor could not find any remaining problem. They build the package, sign it, and upload it to Debian.
ja: スポンサーは、何も問題が残っているのを見つけられませんでした。パッケージをビルドし、署名し、Debian へアップロードします。

en: Before delving into the details of how to sponsor a package, you should ask yourself whether adding the proposed package is beneficial to Debian.
ja: どのようにパッケージをスポンサーするのかの詳細を掘り下げるまえに、提案されているパッケージをDebianに追加するメリットがあるのかを問うべきです。

en: There's no simple rule to answer this question; it can depend on many factors: is the upstream codebase mature and not full of security holes? Are there pre-existing packages that can do the same task and how do they compare to this new package? Has the new package been requested by users and how large is the user base? How active are the upstream developers?
ja: この質問に答えるシンプルなルールは存在しません。様々な要素に依存しうるからです。アップストリームのコードが十分枯れており、脆弱性がまったくないか? 同じようなことができるパッケージがすでにパッケージ化されていないだろうか? そして新しいパッケージはそれらと比較してどんな違いがあるだろうか? 新しいパッケージはユーザーの要望があるだろうか? どれくらいのユーザー数がいるだろうか? アップストリームの開発者はどれくらい精力的に活動しているだろうか?

en: You should also ensure that the prospective maintainer is going to be a good maintainer. Do they already have some experience with other packages? If yes, are they doing a good job with them (check out some bugs)? Are they familiar with the package and its programming language? Do they have the skills needed for this package? If not, are they able to learn them?
ja: それから、メンテナ候補者が良いメンテナになるであろうことを保証する必要があります。他のパッケージでの経験がありますか? そうであれば、良い仕事をしていますか (バグを確認している)? パッケージと使われているプログラミング言語について詳しいですか? そのパッケージに必要なスキルを持っていますか? そうでなければ、学ぶことが可能でしょうか?

en: It's also a good idea to know where they stand with respect to Debian: do they agree with Debian's philosophy and do they intend to join Debian? Given how easy it is to become a Debian Member, you might want to only sponsor people who plan to join. That way you know from the start that you won't have to act as a sponsor indefinitely.
ja: Debianについてどのような立ち位置にあるかを知るのもよいでしょう: 彼らはDebianの哲学に同意し、Debianコミュニティーへ参加するつもりがあるでしょうか? Debianメンバーになることは簡単なので、Debianメンバーになろうと思っている人だけをスポンサーしたいことでしょう。そのようにすれば無期限にスポンサーとして活動する必要がないことが最初からわかります。

en: Sponsoring a new package
ja: 新しいパッケージのスポンサーを行う

en: Don't ever sponsor a new package without reviewing it. The review of new packages done by ftpmasters mainly ensures that the software is really free. Of course, it happens that they stumble on packaging problems but they really should not. It's your task to ensure that the uploaded package complies with the Debian Free Software Guidelines and is of good quality.
ja: レビューをせずに新しいパッケージのスポンサーをしないでください。ftpmaster による新しいパッケージのレビューは、主にソフトウェアが本当にフリーなものであるかを確認するためです。もちろん、パッケージ化に関する問題に偶然気づくことはありますが、それを期待すべきではありません。アップロードされたパッケージが、Debian フリーソフトウェアガイドラインに適合し、良い品質であるのを保証するのは、あなたの仕事です。

en: Building the package and testing the software is part of the review, but it's also not enough. The rest of this section contains a non-exhaustive list of points to check in your review.  [1]_
ja: パッケージをビルドし、ソフトウェアのテストを行うのはレビューの一部ではありますが、それだけでは十分ではありません。この章の残りの部分では、レビューでチェックするポイントの一覧を述べます (徹底的なものではありません)。 [1]_

en: Verify that the upstream tarball provided is the same that has been distributed by the upstream author (when the sources are repackaged for Debian, generate the modified tarball yourself).
ja: upstream の tarball として提供されているものが、upstream の作者が配布しているものと同じかどうかを確認する (ソースが Debian 用に再パッケージされている場合、修正した tarball を自分自身で生成する)。

en: Run ``licensecheck`` (part of :ref:`devscripts`) and verify that ``debian/copyright`` seems correct and complete. Look for license problems (like files with “All rights reserved” headers, or with a non-DFSG compliant license). ``grep -ri`` is your friend for this task.
ja: ``licensecheck``\ (:ref:`devscripts` の一部) を実行し、\ ``debian/copyright`` が正しく、そして完全な事を確認する。ライセンス問題を探してください (頭に“All rights reserved”とあるファイルや、DFSG に適合しないライセンスがあるなど)。この作業には、\ ``grep -ri`` が助けとなることでしょう。

en: Build the package with ``pbuilder`` (or any similar tool, see :ref:`pbuilder`) to ensure that the build-dependencies are complete.
ja: ビルドの依存関係が完全であるのを保証するため、パッケージを ``pbuilder`` (やその他類似のツール) でビルドする (:ref:`pbuilder` 参照)。

en: Proofread ``debian/control``: does it follow the best practices (see :ref:`bpp-debian-control`)? Are the dependencies complete?
ja: ``debian/control`` を査読する: ベストプラクティスに従っている? (:ref:`bpp-debian-control` 参照) 依存関係は完璧ですか?

en: Proofread ``debian/rules``: does it follow the best practices (see :ref:`bpp-debian-rules`)? Do you see some possible improvements?
ja: ``debian/rules`` を査読する: ベストプラクティスに従っている? (:ref:`bpp-debian-rules` 参照) 改善可能な点がある?

en: Proofread the maintainer scripts (``preinst``, ``postinst``, ``prerm``, ``postrm``, ``config``): will the ``preinst``/``postrm`` work when the dependencies are not installed? Are all the scripts idempotent (i.e. can you run them multiple times without consequences)?
ja: メンテナスクリプト (``preinst``, ``postinst``, ``prerm``, ``postrm``, ``config``) を査読する: 依存関係がインストールされていない時でも動作する? 全てのスクリプトが等羃 (idempotent、すなわち、問題無しに複数回実行できる)?

en: Review any change to upstream files (either in ``.diff.gz``, or in ``debian/patches/`` or directly embedded in the ``debian`` tarball for binary files). Are they justified? Are they properly documented (with `DEP-3 <https://dep-team.pages.debian.net/deps/dep3/>`__ for patches)?
ja: 開発元のファイルに対する変更 (``.diff.gz``\ 、\ ``debian/patches/``\ 、あるいは直接 ``debian`` tarball に埋め込まれているバイナリファイル) をレビューする。十分な根拠がありますか? (パッチに対し、`DEP-3 <https://dep-team.pages.debian.net/deps/dep3/>`__ に沿って) 正しくドキュメント化されている?

en: For every file, ask yourself why the file is there and whether it's the right way to achieve the desired result. Is the maintainer following the best packaging practices (see :ref:`best-pkging-practices`)?
ja: すべてのファイルについて、そのファイルが何故そこにあるのか、望んでいる結果をもたらすためにそれが正しいやり方かどうかを自身に問いかけてください。メンテナはパッケージ化のベストプラクティスに従っていますか? (:ref:`best-pkging-practices` 参照)

en: If you use ``debuild`` and ``debsign``, you can even configure it permanently in ``~/.devscripts``:
ja: ``debuild`` と ``debsign`` を使う場合は、\ ``~/.devscripts`` に設定を決め打ちで書いても構いません:

en: Sponsoring an update of an existing package
ja: 既存パッケージの更新をスポンサーする

en: If you compare the source packages (excluding upstream files in the case of a new upstream version, for example by filtering the output of ``debdiff`` with ``filterdiff -i '*/debian/*'``), you must understand all the changes you see and they should be properly documented in the Debian changelog.
ja: ソースパッケージを比較した場合 (新しい開発元のバージョンの場合には、例えば ``debdiff`` の出力を ``filterdiff -i '*/debian/*'`` などとして、開発元のファイルを除外します)、確認したすべての変更点を理解して、この変更点が Debian の changelog に正しく記載されている必要があります。

en: If you have found no major problem, upload the new version. Otherwise ask the maintainer to provide you a fixed version.
ja: 何も大きな問題を見つけなければ、新しいバージョンをアップロードします。そうでなければ、メンテナに修正したバージョンをアップロードするよう要請します。

en: After a Debian Maintainer's key has been added to the debian-maintainers keyring, a Debian Developer may grant upload permissions to the DM for specific packages by uploading a signed dak command to ftp.upload.debian.org `as described in the FTP-Master's announcement to debian-devel <https://lists.debian.org/debian-devel-announce/2012/09/msg00008.html>`__.
ja: Debianメンテナーの鍵はdebian-maintainersキーリングに追加され、Debian開発者は特定のパッケージに関するアップロード権限をDMに許可することがあります。
    これは署名したdakコマンドを `FTP-Masterによるdebian-develへのアナウンス <https://lists.debian.org/debian-devel-announce/2012/09/msg00008.html>`__ のとおりにftp.upload.debian.orgにアップロードすることで行います。

en: This process can be simplified with the help of the ``dcut`` command from the ``dput-ng`` package. Note that this does not work with the ``dcut`` command from the ``dput`` package!
ja: このプロセスは ``dput-ng`` パッケージに含まれる ``dcut`` コマンドにより簡略化できます。 ``dput`` パッケージの ``dcut`` では動作しないことに注意が必要です!

en: For example:
ja: 例:

en: If the DM's key is not in the keyring package yet but in the DD's local keyring, use the ``--force`` option and the fingerprint, without spaces and, in this special case, without the 0x prefix and in all uppercase:
ja: DMの鍵がキーリングパッケージに含まれていないがDDのローカルのキーリングに含まれている場合、``--force`` オプションとスペースを含まないフィンガープリントを指定します。とりわけ0xというプレフィクスをつけず、すべて大文字を指定します。

en: Advocating new developers
ja: 新たな開発者を支持する (advocate)

en: See the page about `advocating a prospective developer <https://www.debian.org/devel/join/nm-advocate>`__ at the Debian web site.
ja: Debian ウェブサイトの\ `開発者志願者の支持者になる (advocating a prospective developer) <https://www.debian.org/devel/join/nm-advocate>`__\ のページを参照してください。

en: Handling new maintainer applications
ja: 新規メンテナ申請 (new maintainer applications) を取り扱う

en: Please see `Checklist for Application Managers <https://www.debian.org/devel/join/nm-amchecklist>`__ at the Debian web site.
ja: Debian のウェブサイトにある `申請管理者用チェックリスト (Checklist for Application Managers) <https://www.debian.org/devel/join/nm-amchecklist>`__ を参照してください。
