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

en: Managing Packages
ja: パッケージの取扱い方

en: This chapter contains information related to creating, uploading, maintaining, and porting packages.
ja: この章では、パッケージの作成、アップロード、メンテナンス、移植についての情報を扱います。

en: New packages
ja: 新規パッケージ

en: If you want to create a new package for the Debian distribution, you should first check the `Work-Needing and Prospective Packages (WNPP) <https://www.debian.org/devel/wnpp/>`__ list. Checking the WNPP list ensures that no one is already working on packaging that software, and that effort is not duplicated. Read the `WNPP web pages <https://www.debian.org/devel/wnpp/>`__ for more information.
ja: もしあなたが Debian ディストリビューションに対して新たなパッケージを作成したいという場合、まず `作業が望まれるパッケージ (Work-Needing and Prospective Packages (WNPP)) <https://www.debian.org/devel/wnpp/>`__ の一覧をチェックする必要があります。WNPP 一覧をチェックすることで、まだ誰もそのソフトをパッケージ化していないことや、作業が重複していないことを確認します。詳細については `WNPP のページ <https://www.debian.org/devel/wnpp/>`__ を読んでください。

en: Assuming no one else is already working on your prospective package, you must then submit a bug report (:ref:`submit-bug`) against the pseudo-package ``wnpp`` describing your plan to create a new package, including, but not limiting yourself to, the description of the package (so that others can review it), the license of the prospective package, and the current URL where it can be downloaded from.
ja: パッケージ化しようとしているソフトについて、誰もまだ作業していないようであれば、まずは ``wnpp`` 擬似パッケージ (pseudo-package) に対してバグ報告を投稿する必要があります (:ref:`submit-bug`)。このバグ報告には、パッケージの説明 (他の人がレビューできます)、作業しようとしているパッケージのライセンス、ダウンロードが可能な現在の URL を含めた新規パッケージの作成予定 (自分自身が分かるだけではないもの) を記述します。

en: Please include a ``Closes: #``\ *nnnnn* entry in the changelog of the new package in order for the bug report to be automatically closed once the new package is installed in the archive (see :ref:`upload-bugfix`).
ja: 新規パッケージがアーカイブへインストールされる際にバグ報告を自動的に閉じるため、\ ``Closes: #``\ *nnnnn* というエントリを新規パッケージの changelog 内に含めてください (:ref:`upload-bugfix` を参照)。

en: If you think your package needs some explanations for the administrators of the NEW package queue, include them in your changelog, send to ``ftpmaster@debian.org`` a reply to the email you receive as a maintainer after your upload, or reply to the rejection email in case you are already re-uploading.
ja: パッケージについて、NEW パッケージキューの管理者への説明が必要だろうと思う場合は、changelog に説明を含めて ``ftpmaster@debian.org`` へ送ってください。アップロード後であればメンテナとして受け取ったメールに返信してください。もしくは既に再アップロード最中の場合は reject メールに対して返信してください。

en: When closing security bugs include CVE numbers as well as the ``Closes: #``\ *nnnnn*. This is useful for the security team to track vulnerabilities. If an upload is made to fix the bug before the advisory ID is known, it is encouraged to modify the historical changelog entry with the next upload. Even in this case, please include all available pointers to background information in the original changelog entry.
ja: セキュリティバグを閉じる場合は、CVE 番号を ``Closes: #``\ *nnnnn* と同じく含めるようにしてください。これは、セキュリティチームが脆弱性を追跡するのに役立ちます。アドバイザリの ID が分かる前にバグ修正のためのアップロードが行われた場合は、以前の changelog エントリを次のアップロード時に修正するのが推奨されています。このような場合でも、元々の changelog での記載に可能な限り背景情報へのポインタを全て含めてください。

en: There are a number of reasons why we ask maintainers to announce their intentions:
ja: 我々がメンテナに意図しているところをアナウンスする様に求めるのには、いくつもの理由があります。

en: It helps the (potentially new) maintainer to tap into the experience of people on the list, and lets them know if anyone else is working on it already.
ja: (潜在的な新たな) メンテナが、メーリングリストの人々の経験を活かすのを手助けし、もし他の誰かが既に作業を行っていた場合に知らせる。

en: It lets other people thinking about working on the package know that there already is a volunteer, so efforts may be shared.
ja: そのパッケージについての作業を検討している他の人へ、既に作業をしているボランティアがいることを知らせ、労力が共有される。

en: It lets the rest of the maintainers know more about the package than the one line description and the usual changelog entry ``Initial release`` that gets posted to ``debian-devel-changes@lists.debian.org``.
ja: ``debian-devel-changes@lists.debian.org`` に流される一行の説明文 (description) と通常どおりの「Intial release」という changelog エントリよりも、残った他のメンテナがパッケージに関してより深く知ることができる。

en: It is helpful to the people who live off ``unstable`` (and form our first line of testers). We should encourage these people.
ja: 不安定版 (``unstable``) で暮らす人 (そして最前線のテスターである人) の助けになる。我々はそのような人々を推奨すべきである。

en: The announcements give maintainers and other interested parties a better feel of what is going on, and what is new, in the project.
ja: メンテナや他に興味を持つ人々へ、プロジェクトで何が行われているのか、何か新しいことがあるかということ関して、告知は良い印象を与える。

en: Please see https://ftp-master.debian.org/REJECT-FAQ.html\  for common rejection reasons for a new package.
ja: 新しいパッケージに対するよくある拒否理由については https://ftp-master.debian.org/REJECT-FAQ.html\ を参照してください。

en: Recording changes in the package
ja: パッケージの変更を記録する

en: Changes that you make to the package need to be recorded in the ``debian/changelog`` file, for human users to read and comprehend. These changes should provide a concise description of what was changed, why (if it's in doubt), and note if any bugs were closed. They also record when the packaging was completed. This file will be installed in ``/usr/share/doc/``\ *package*\ ``/changelog.Debian.gz``, or ``/usr/share/doc/``\ *package*\ ``/changelog.gz`` for native packages.
ja: パッケージについて行った変更は ``debian/changelog`` に記録されなくてはいけません。これらの変更には、何が変更されたのか、(不確かであれば) 何故なのか、そしてどのバグが閉じられたのかの簡潔な説明文を付加する必要があります。このファイルは ``/usr/share/doc/``\ *package*\ ``/changelog.Debian.gz``\ 、あるいはネイティブパッケージの場合は ``/usr/share/doc/``\ *package*\ ``/changelog.gz`` にインストールされます。

en: The ``debian/changelog`` file conforms to a certain structure, with a number of different fields. One field of note, the ``distribution``, is described in :ref:`distribution`. More information about the structure of this file can be found in the Debian Policy section titled ``debian/changelog``.
ja: ``debian/changelog`` ファイルは、幾つもの異なった項目からなる特定の構造に従っています。一点を取り上げてみると、\ ``distribution`` については\ :ref:`distribution`\ に記述されています。このファイルの構造について、より詳細な情報は Debian ポリシーの ``debian/changelog`` という章で確認できます。

en: Changelog entries can be used to automatically close Debian bugs when the package is installed into the archive. See :ref:`upload-bugfix`.
ja: changelog への記載は、パッケージがアーカイブにインストールされる際、自動的に Debian バグを閉じるのに利用できます。\ :ref:`upload-bugfix` を参照してください。

en: It is conventional that the changelog entry of a package that contains a new upstream version of the software looks like this:
ja: ソフトウェアの新しい開発元のバージョン (new upstream version) を含むパッケージの changelog エントリは、以下のようにするのが慣習です:

en: See also :ref:`bpp-debian-changelog`.
ja: :ref:`bpp-debian-changelog` も参照してください。

en: Testing the package
ja: パッケージをテストする

en: Before you upload your package, you should do basic testing on it. At a minimum, you should try the following activities (you'll need to have an older version of the same Debian package around):
ja: パッケージをアップロードする前に、基本的なテストをする必要があります。最低限、以下の作業が必要です (同じ Debian パッケージの古いバージョンなどが必要になるでしょう):

en: Run ``lintian`` over the package. You can run ``lintian`` as follows: ``lintian -v`` *package-version*\ ``.changes``. This will check the source package as well as the binary package. If you don't understand the output that ``lintian`` generates, try adding the ``-i`` switch, which will cause ``lintian`` to output a very verbose description of the problem.
ja: パッケージに対して ``lintian`` を実行する。以下のようにして ``lintian`` を実行できます: ``lintian -v``\ *package-version*\ ``.changes`` これによって、バイナリパッケージ同様にソースパッケージを確認できます。\ ``lintian`` が生成した出力を理解していない場合は、\ ``lintian`` が問題の説明を非常に冗長に出力するようにする ``-i`` オプションを付けて実行してみてください。

en: Normally, a package should *not* be uploaded if it causes ``lintian`` to emit errors (they will start with ``E``).
ja: 通常、\ ``lintian`` がエラーを出力するようであれば、パッケージをアップロードしては\ *いけません* (エラーは ``E`` で始まります)。

en: For more information on ``lintian``, see :ref:`lintian`.
ja: ``lintian`` についての詳細は、\ :ref:`lintian` を参照してください。

en: Optionally run ``debdiff`` (see :ref:`debdiff`) to analyze changes from an older version, if one exists.
ja: もし古いバージョンがあれば、それからの変更点を分析するために追加で ``debdiff`` を実行する (:ref:`debdiff` を参照) 。

en: Remove the package, then reinstall it.
ja: パッケージを削除して、再インストールする。

en: Copy the source package in a different directory and try unpacking it and rebuilding it. This tests if the package relies on existing files outside of it, or if it relies on permissions being preserved on the files shipped inside the ``.diff.gz`` file.
ja: ソースパッケージを違うディレクトリにコピーして展開し、再構築する。これは、パッケージが外部の既存ファイルに依っているか、\ ``.diff.gz`` ファイル内に含まれているファイルで保存されている権限に依るかどうかをテストします。

en: Layout of the source package
ja: ソースパッケージの概要

en: There are two types of Debian source packages:
ja: Debian のソースパッケージには 2 種類あります：

en: the so-called ``native`` packages, where there is no distinction between the original sources and the patches applied for Debian
ja: いわゆる ``ネイティブ (native)`` パッケージ。元のソースと Debian で当てられたパッチの間に差が無いもの

en: the (more common) packages where there's an original source tarball file accompanied by another file that contains the changes made by Debian
ja: オリジナルのソースコードの tarball ファイルに、Debian によって作成された変更点を含む別のファイルが付随している (より一般的な) パッケージ

en: For the native packages, the source package includes a Debian source control file (``.dsc``) and the source tarball (``.tar.{gz,bz2,xz}``). A source package of a non-native package includes a Debian source control file, the original source tarball (``.orig.tar.{gz,bz2,xz}``) and the Debian changes (``.diff.gz`` for the source format “1.0” or ``.debian.tar.{gz,bz2,xz}`` for the source format “3.0 (quilt)”).
ja: ネイティブパッケージの場合、ソースパッケージは Debian のソース control ファイル (``.dsc``) とソースコードの tarball (``.tar.{gz,bz2,xz}``) を含んでいます。ネイティブではないパッケージのソースパッケージは Debian のソース control ファイルと、オリジナルのソースコードの tarball (``.orig.tar.{gz,bz2,xz}``)、そして Debian での変更点 (ソース形式“1.0”は ``.diff.gz``\ 、ソース形式“3.0 (quilt)”は ``.debian.tar.{gz,bz2,xz}``) を含んでいます。

en: With source format “1.0”, whether a package is native or not was determined by ``dpkg-source`` at build time. Nowadays it is recommended to be explicit about the desired source format by putting either “3.0 (quilt)” or “3.0 (native)” in ``debian/source/format``. The rest of this section relates only to non-native packages.
ja: ソース形式“1.0”では、パッケージが native かどうかはビルド時に ``dpkg-source`` によって決められていました。最近では望むソース形式を ``debian/source/format`` に“3.0 (quilt)”または“3.0 (native)”と記述することによって明示することが推奨されています。この章の残りの部分は native ではないパッケージについてのみ記しています。

en: By default, ``dpkg-genchanges`` and ``dpkg-buildpackage`` will include the original source tar file if and only if the current changelog entry has a different upstream version from the preceding entry. This behavior may be modified by using ``-sa`` to always include it or ``-sd`` to always leave it out.
ja: デフォルトでは、\ ``dpkg-genchanges`` および ``dpkg-buildpackage`` は前述されている changelog エントリと現在のエントリが異なった upstream バージョンを持つ場合にのみ、オリジナルのソース tar ファイルを含めようとします。この挙動は、\ ``-sa`` を使って常に含めたり、\ ``-sd`` を使うことで常に含めないようにするように変更できます。

en: If no original source is included in the upload, the original source tar-file used by ``dpkg-source`` when constructing the ``.dsc`` file and diff to be uploaded *must* be byte-for-byte identical with the one already in the archive.
ja: アップロード時にオリジナルのソースが含まれていない場合、アップロードされる ``.dsc`` と diff ファイルを構築する際に ``dpkg-source`` が使用するオリジナルの tar ファイルは、\ *必ず*\ 既にアーカイブにあるものと 1 バイトも違わぬものでなくてはなりません。

en: Picking a distribution
ja: ディストリビューションを選ぶ

en: Each upload needs to specify which distribution the package is intended for. The package build process extracts this information from the first line of the ``debian/changelog`` file and places it in the ``Distribution`` field of the ``.changes`` file.
ja: アップロードでは、パッケージがどのディストリビューション向けになっているかを指定してあることが必要です。パッケージの構築プロセスでは、\ ``debian/changelog`` ファイルの最初の行からこの情報を展開し、\ ``.changes`` ファイルの ``Distribution`` 欄に配置します。

en: Packages are normally uploaded into ``unstable``. Uploads to ``unstable`` or ``experimental`` should use these suite names in the changelog entry; uploads for other supported suites should use the suite codenames, as they avoid any ambiguity.
ja: パッケージは、通常 ``unstable`` へアップロードされます。\ ``unstable`` あるいは ``experimental`` へのアップロードはこれらの suite を changelog のエントリに記します。サポートされている他の suite へのアップロードは、曖昧さを避けるために suite のコードネームを使う必要があります。

en: Actually, there are other possible distributions: |codename-security|, but read :ref:`bug-security` for more information on those.
ja: 実際には、他にも指定可能なディストリビューションがあります: ``codename-security`` ですが、その詳細については :ref:`bug-security` を読んでください。

en: It is not possible to upload a package into several distributions at the same time.
ja: 同時に複数のディストリビューションへ、パッケージをアップロードすることはできません。

en: Special case: uploads to the ``stable`` and ``oldstable`` distributions
ja: 特別な例: 安定版 (``stable``) と ``旧安定版 (oldstable)`` ディストリビューションへアップロードする

en: Uploading to ``stable`` means that the package will be transferred to the ``proposed-updates-new`` queue for review by the stable release managers, and if approved will be installed in the ``stable-proposed-updates`` directory of the Debian archive. From there, it will be included in ``stable`` with the next point release.
ja: 安定版 (``stable``) へのアップロードは、安定版リリースマネージャによるレビューのため、パッケージは ``proposed-updates-new`` キューに転送され、許可された場合は Debian アーカイブの ``stable-proposed-updates`` ディレクトリにインストールされます。ここから、ここから、安定版 (``stable``) の次期ポイントリリースに含まれることになります。

en: Uploads to the ``oldstable`` distributions are possible as long as it hasn't been archived. The same rules as for ``stable`` apply.
ja: ``旧安定版 (oldstable)`` ディストリビューションへのアップロードはアーカイブされてない限り可能です。\ ``安定版 (stable)``\ と同じルールが適用されます。

en: Special case: uploads to ``testing/testing-proposed-updates``
ja: 特別な例: ``testing/testing-proposed-updates`` へアップロードする

en: Please see the information in the :ref:`t-p-u` for details.
ja: 詳細については、\ :ref:`t-p-u` にある情報を参照してください。

en: Uploading a package
ja: パッケージをアップロードする

en: Uploading to ``ftp-master``
ja: ``ftp-master`` にアップロードする

en: Please note that you should transfer the changes file last. Otherwise, your upload may be rejected because the archive maintenance software will parse the changes file and see that not all files have been uploaded.
ja: changes ファイルは最後に転送する必要があることに注意してください。そうしないとアーカイブのメンテナンスを行っているソフトが changes ファイルをパースして全てのファイルがアップロードされていないと判断して、アップロードは reject されるかもしれません。

en: You may also find the Debian packages :ref:`dupload` or :ref:`dput` useful when uploading packages.These handy programs help automate the process of uploading packages into Debian.
ja: パッケージのアップロードを行う際には :ref:`dupload` や :ref:`dput` が便利なことにも気づくことでしょう。これらの便利なプログラムは、パッケージを Debian にアップロードする作業を自動化するのに役立ちます。

en: For removing packages or cancelling an upload, please see ftp://ftp.upload.debian.org/pub/UploadQueue/README\  and the Debian package :ref:`dcut`.
ja: パッケージを削除もしくはアップロードを取り消すには ftp://ftp.upload.debian.org/pub/UploadQueue/README\  と :ref:`dcut` Debian パッケージを参照してください。

en: Delayed uploads
ja: 遅延アップロード

en: An upload to the delayed directory keeps the package in `the deferred uploads queue <https://ftp-master.debian.org/deferred.html>`__. When the specified waiting time is over, the package is moved into the regular incoming directory for processing. This is done through automatic uploading to ``ftp.upload.debian.org`` in upload-directory ``DELAYED/``\ *X*\ ``-day`` (*X* between 0 and 15). 0-day is uploaded multiple times per day to ``ftp.upload.debian.org``.
ja: delayed ディレクトリにアップロードされると、パッケージは `the deferred uploads queue <https://ftp-master.debian.org/deferred.html>`__ に保存されます。指定した待ち時間が終わると、パッケージは処理のため通常の incoming ディレクトリに移動されます。この作業は ``ftp.upload.debian.org`` の ``DELAYED/``\ *X*\ ``-day`` ディレクトリへのアップロードを通じて自動的に処理されます (*X* は 0 から 15 の間です)。0-day は一日に複数回 ``ftp.upload.debian.org`` へアップロードするのに使われます。

en: With dput, you can use the ``--delayed`` *DELAY* parameter to put the package into one of the queues.
ja: dput を使うと、パッケージを遅延キューに入れるのに ``--delayed``\ *DELAY* パラメータを使えます。

en: Security uploads
ja: セキュリティアップロード

en: Other upload queues
ja: 他のアップロードキュー

en: There is an alternative upload queue in Europe at ftp://ftp.eu.upload.debian.org/pub/UploadQueue/\ . It operates in the same way as ``ftp.upload.debian.org``, but should be faster for European developers.
ja: ヨーロッパにはもう一つのアップロードキューが ftp://ftp.eu.upload.debian.org/pub/UploadQueue/\ にあります。操作方法は ``ftp.upload.debian.org`` と同じですが、ヨーロッパ圏の開発者に対しては、より速いはずです。

en: Packages can also be uploaded via ssh to ``ssh.upload.debian.org``; files should be put ``/srv/upload.debian.org/UploadQueue``. This queue does not support :ref:`delayed-incoming`.
ja: パッケージは ssh を使って ``ssh.upload.debian.org`` へアップロードすることも可能です。ファイルは ``/srv/upload.debian.org/UploadQueue`` に置く必要があります。このキューは\ :ref:`delayed-incoming`\ をサポートしていません。

en: The Debian archive maintainers are responsible for handling package uploads. For the most part, uploads are automatically handled on a daily basis by the archive maintenance tools, ``dak process-upload``. Specifically, updates to existing packages to the ``unstable`` distribution are handled automatically. In other cases, notably new packages, placing the uploaded package into the distribution is handled manually. When uploads are handled manually, the change to the archive may take some time to occur. Please be patient.
ja: Debian アーカイブメンテナはパッケージのアップロードに関して責任を持っています。多くの部分は、アップロードはアーカイブ用のメンテナンスツール ``dak process-upload`` によって日々自動的に行われています。特に、\ ``不安定版 (unstable)`` に存在しているパッケージの更新は自動的に処理されます。それ以外の場合、特に新規パッケージの場合は、アップロードされたパッケージをディストリビューションに含めるのは手動で行われます。アップロードが手動で処理される場合は、アーカイブへの変更は実施されるまでに一ヶ月ほどかかります。お待ちください。

en: In any case, you will receive an email notification indicating that the package has been added to the archive, which also indicates which bugs will be closed by the upload. Please examine this notification carefully, checking if any bugs you meant to close didn't get triggered.
ja: どの場合であっても、パッケージがアーカイブに追加されたことや、バグがアップロードで閉じられたことを告げるメールでの通知を受け取ることになります。あなたが閉じようとしたバグが処理されてない場合は、この通知を注意深く確認してください。

en: The installation notification also includes information on what section the package was inserted into. If there is a disparity, you will receive a separate email notifying you of that. Read on below.
ja: インストール通知は、パッケージがどのセクションに入ったかを示す情報を含んでいます。不一致がある場合は、それを示す別のメール通知を受け取ります。以下も参照ください。

en: Note that if you upload via queues, the queue daemon software will also send you a notification by email.
ja: キュー経由でアップロードした場合は、キューデーモンソフトウェアもメールで通知を行うことに留意してください。

en: Specifying the package section, subsection and priority
ja: パッケージのセクション、サブセクション、優先度を指定する

en: The ``debian/control`` file's ``Section`` and ``Priority`` fields do not actually specify where the file will be placed in the archive, nor its priority. In order to retain the overall integrity of the archive, it is the archive maintainers who have control over these fields. The values in the ``debian/control`` file are actually just hints.
ja: ``debian/control`` ファイルの ``セクション (Section)`` フィールドと ``優先度 (Priority)`` フィールドは実際にアーカイブ内でどこに配置されるか、あるいはプライオリティが何かという指定ではありません。\ ``debian/control`` ファイル中の値は、実際のところは単なるヒントです。

en: The archive maintainers keep track of the canonical sections and priorities for packages in the ``override file``. If there is a disparity between the ``override file`` and the package's fields as indicated in ``debian/control``, then you will receive an email noting the divergence when the package is installed into the archive. You can either correct your ``debian/control`` file for your next upload, or else you may wish to make a change in the ``override file``.
ja: アーカイブメンテナは、\ ``override ファイル``\ 内でパッケージについて定められたセクションと優先度を常に確認しています。\ ``override ファイル``\ と ``debian/control`` で指定されたパッケージのフィールドに不一致がある場合、パッケージがアーカイブにインストールされる際に相違について記述されたメールを受け取ります。\ ``debian/control`` ファイルを次回のアップロード時に修正することもできますし、\ ``override ファイル``\ に変更を加えるように依頼するのもよいでしょう。

en: To alter the actual section that a package is put in, you need to first make sure that the ``debian/control`` file in your package is accurate. Next, submit a bug against ``ftp.debian.org`` requesting that the section or priority for your package be changed from the old section or priority to the new one. Use a Subject like ``override: PACKAGE1:section/priority, [...], PACKAGEX:section/priority``, and include the justification for the change in the body of the bug report.
ja: パッケージが現状で置かれているセクションを変更するには、まずパッケージの ``debian/control`` ファイルが正しいことを確認する必要があります。次に、\ ``ftp.debian.org`` に対し、あなたのパッケージに対するセクションあるいは優先度について古いものから新しいものへ変更する依頼のバグ登録をします。\ ``override: PACKAGE1:section/priority, [...], PACKAGEX:section/priority`` のようなサブジェクトを使い、バグ報告の本文に変更に関する根拠を記述してください。

en: For more information about ``override files``, see dpkg-scanpackages 1 and https://www.debian.org/Bugs/Developer#maintincorrect\ .
ja: ``override ファイル`` についての詳細は、dpkg-scanpackages 1 と https://www.debian.org/Bugs/Developer#maintincorrect\ を参照してください。

en: Note that the ``Section`` field describes both the section as well as the subsection, which are described in :ref:`archive-sections`. If the section is main, it should be omitted. The list of allowable subsections can be found in https://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections\ .
ja: :ref:`archive-sections` で書かれているように、\ ``セクション (Section)``\ フィールドにはセクション同様にサブセクションも記述するのに注意ください。セクションが main の場合は、それは書かないようにしてください。利用可能なサブセクションは https://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections\ で検索できます。

en: Handling bugs
ja: バグの取扱い

en: Every developer has to be able to work with the Debian `bug tracking system <https://www.debian.org/Bugs/>`__. This includes knowing how to file bug reports properly (see :ref:`submit-bug`), how to update them and reorder them, and how to process and close them.
ja: すべての開発者は Debian `バグ追跡システム <https://www.debian.org/Bugs/>`__\ を取り扱えるようでなければいけません。これは、どの様にしてバグ報告を正しく登録するか (:ref:`submit-bug` 参照)、どの様に更新及び整理するか、そしてどの様にして処理をして完了するかを知っていることを含みます。

en: The bug tracking system's features are described in the `BTS documentation for developers <https://www.debian.org/Bugs/Developer>`__. This includes closing bugs, sending followup messages, assigning severities and tags, marking bugs as forwarded, and other issues.
ja: バグ追跡システムの機能は、\ `Debian BTS 開発者向け情報 <https://www.debian.org/Bugs/Developer>`__\ に記載されています。これには、バグの完了処理・追加メッセージの送信・重要度とタグを割り当てる・バグを転送済み (Forwarded) にする・その他が含まれています。

en: Operations such as reassigning bugs to other packages, merging separate bug reports about the same issue, or reopening bugs when they are prematurely closed, are handled using the so-called control mail server. All of the commands available on this server are described in the `BTS control server documentation <https://www.debian.org/Bugs/server-control>`__.
ja: バグを他のパッケージに割り当てし直す、同じ問題についての別々のバグ報告をマージする、早まってクローズされたバグの再オープンなどの作業は、いわゆる制御メールサーバと呼ばれるものを使って処理されています。このサーバで利用可能なすべてのコマンドは、\ `BTS 制御サーバドキュメント <https://www.debian.org/Bugs/server-control>`__\ に記載されています。

en: Monitoring bugs
ja: バグの監視

en: If you want to be a good maintainer, you should periodically check the `Debian bug tracking system (BTS) <https://www.debian.org/Bugs/>`__ for your packages. The BTS contains all the open bugs against your packages. You can check them by browsing this page: ``https://bugs.debian.org/``\ *yourlogin*\ ``@debian.org``.
ja: 良いメンテナになりたい場合は、あなたのパッケージに関する `Debian バグ追跡システム (BTS) <https://www.debian.org/Bugs/>`__ のページを定期的にチェックする必要があります。BTS には、あなたのパッケージに対して登録されている全てのバグが含まれています。登録されているバグについては、以下のページを参照することで確認できます: ``https://bugs.debian.org/``\ *yourlogin*\ ``@debian.org``

en: Maintainers interact with the BTS via email addresses at ``bugs.debian.org``. Documentation on available commands can be found at https://www.debian.org/Bugs/\ , or, if you have installed the ``doc-debian`` package, you can look at the local files ``/usr/share/doc/debian/bug-*``.
ja: メンテナは、\ ``bugs.debian.org`` のメールアドレス経由で BTS に対応します。利用可能なコマンドについてのドキュメントは https://www.debian.org/Bugs/\  で参照可能ですし、もし ``doc-debian`` パッケージをインストールしてあれば、ローカルファイル ``/usr/share/doc/debian/bug-*`` で見ることも可能です。

en: Some find it useful to get periodic reports on open bugs. You can add a cron job such as the following if you want to get a weekly email outlining all the open bugs against your packages:
ja: 定期的にオープンになっているバグについてのレポートを受け取るのも良いでしょう。あなたのパッケージでオープンになっているバグの全一覧を毎週受け取りたい場合、以下のような cron ジョブを追加します:

en: Replace *address* with your official Debian maintainer address.
ja: *address* は、あなたの公式な Debian パッケージメンテナとしてのメールアドレスに置き換えてください。

en: Responding to bugs
ja: バグへの対応

en: If you get a bug which mentions FTBFS, this means Fails to build from source. Porters frequently use this acronym.
ja: FTBFS である旨のバグを受け取った場合、これはソースからビルドできないこと (Fails to build from source) を意味します。移植作業をしている人たちはこの略語をよく使います。

en: Once you've dealt with a bug report (e.g. fixed it), mark it as ``done`` (close it) by sending an explanation message to *123*\ ``-done@bugs.debian.org``. If you're fixing a bug by changing and uploading the package, you can automate bug closing as described in :ref:`upload-bugfix`.
ja: 既にバグに対処していた場合 (例えば修正済みの時)、説明のメッセージを *123*\ ``-done@bugs.debian.org`` に送ることで ``done`` とマークしておいて (閉じて) ください。パッケージを変更してアップロードすることでバグを修正する場合は、\ :ref:`upload-bugfix` に記載されているように自動的にバグを閉じることができます。

en: You should *never* close bugs via the bug server ``close`` command sent to ``control@bugs.debian.org``. If you do so, the original submitter will not receive any information about why the bug was closed.
ja: ``close`` コマンドを ``control@bugs.debian.org`` に送って、バグサーバ経由でバグを閉じるのは\ *決して*\ してはいけません。そのようにした場合、元々の報告者は何故バグが閉じられたのかという情報を得られません。

en: Bug housekeeping
ja: バグを掃除する

en: As a package maintainer, you will often find bugs in other packages or have bugs reported against your packages which are actually bugs in other packages. The bug tracking system's features are described in the `BTS documentation for Debian developers <https://www.debian.org/Bugs/Developer>`__. Operations such as reassigning, merging, and tagging bug reports are described in the `BTS control server documentation <https://www.debian.org/Bugs/server-control>`__. This section contains some guidelines for managing your own bugs, based on the collective Debian developer experience.
ja: パッケージメンテナになると、他のパッケージにバグを見つけたり、自分のパッケージに対して報告されたバグが実際には他のパッケージにあるバグであったりということが頻繁にあるでしょう。バグ追跡システムの機能は `Debian 開発者向けの BTS ドキュメント <https://www.debian.org/Bugs/Developer>`__ に記載されています。バグ報告の再指定 (reassign) やマージ (merge)、そしてタグ付けなどの作業は `BTS 制御サーバのドキュメント <https://www.debian.org/Bugs/server-control>`__ に記述されています。この章では、Debian 開発者から集められた経験を元にしたバグの扱い方のガイドラインを含んでいます。

en: Filing bugs for problems that you find in other packages is one of the civic obligations of maintainership, see :ref:`submit-bug` for details. However, handling the bugs in your own packages is even more important.
ja: 他のパッケージで見つけた問題についてバグを登録するのは、メンテナとしての責務の一つです。詳細については :ref:`submit-bug` を参照してください。しかし、自分のパッケージのバグを管理するのはさらに重要です。

en: Here's a list of steps that you may follow to handle a bug report:
ja: 以下がバグ報告を取り扱う手順です:

en: Decide whether the report corresponds to a real bug or not. Sometimes users are just calling a program in the wrong way because they haven't read the documentation. If you diagnose this, just close the bug with enough information to let the user correct their problem (give pointers to the good documentation and so on). If the same report comes up again and again you may ask yourself if the documentation is good enough or if the program shouldn't detect its misuse in order to give an informative error message. This is an issue that may need to be brought up with the upstream author.
ja: 報告が実際にバグに関連するものか否かを決めてください。ユーザはドキュメントを読んでいないため、誤ったプログラムの使い方をしているだけのことが時々あります。このように判断した場合は、ユーザに問題を修正するのに十分な情報を与えて (良いドキュメントへのポインタを教えるなどして) バグを閉じます。同じ報告が何度も繰り返し来る場合には、ドキュメントが十分なものかどうか、あるいは有益なエラーメッセージを与えるよう、誤った使い方を検知していないのでは、と自身に問い直してください。これは開発元の作者に伝える必要がある問題かもしれません。

en: If the bug is real but it's caused by another package, just reassign the bug to the right package. If you don't know which package it should be reassigned to, you should ask for help on :ref:`irc-channels` or on ``debian-devel@lists.debian.org``. Please inform the maintainer(s) of the package you reassign the bug to, for example by Cc:ing the message that does the reassign to *packagename*\ ``@packages.debian.org`` and explaining your reasons in that mail. Please note that a simple reassignment is *not* e-mailed to the maintainers of the package being reassigned to, so they won't know about it until they look at a bug overview for their packages.
ja: バグが実際にあるが、他のパッケージによって引き起こされている場合は、バグを正しいパッケージに再指定 (reassign) します。どのパッケージに再指定するべきかが分からない場合は、\ :ref:`irc-channels` か ``debian-devel@lists.debian.org`` で聞いてください。再指定するパッケージのメンテナに通知をしてください。例えば *packagename*\ ``@packages.debian.org`` 宛にメッセージを Cc: してメール中に理由を説明するなどします。単に再指定しただけでは再指定された先のメンテナにはメールは\ *送信されません*\ ので、彼らがパッケージのバグ一覧を見るまでそれを知ることはありません。

en: If the bug affects the operation of your package, please consider cloning the bug and reassigning the clone to the package that really causes the behavior. Otherwise, the bug will not be shown in your package's bug list, possibly causing users to report the same bug over and over again. You should block "your" bug with the reassigned, cloned bug to document the relationship.
ja: バグがあなたのパッケージの動作に影響する場合は、バグを複製し (clone)、複製したバグをその挙動を実際に起こしているパッケージに再指定することを検討してください。さもなければ、あなたのパッケージのバグ一覧にバグが見つからないので、多分ユーザに同じバグを何度も繰り返し報告される羽目になる可能性があります。あなたは、再指定 (reassign) によって「自分の」バグということを防ぎ、バグの複製 (clone) によって関係があることを記載しておく必要があります。

en: Sometimes you also have to adjust the severity of the bug so that it matches our definition of the severity. That's because people tend to inflate the severity of bugs to make sure their bugs are fixed quickly. Some bugs may even be dropped to wishlist severity when the requested change is just cosmetic.
ja: 時々、重要度の定義に合うようにバグの重要度を調整する必要もあります。これは、人々はバグ修正を確実に早くしてもらうために重要度を極端に上げようとするからです。要望された変更点が単に体裁的なものな時には、バグは要望 (wishlist) に格下げされるでしょう。

en: If the bug is real but the same problem has already been reported by someone else, then the two relevant bug reports should be merged into one using the merge command of the BTS. In this way, when the bug is fixed, all of the submitters will be informed of this. (Note, however, that emails sent to one bug report's submitter won't automatically be sent to the other report's submitter.) For more details on the technicalities of the merge command and its relative, the unmerge command, see the BTS control server documentation.
ja: バグが確かにあるが既に他の誰かによって同じ問題が報告されている場合は、2 つの関連したバグを BTS の merge コマンドを使って 1 つにマージします。このようにすると、バグが修正された時に全ての投稿者に通知がいきます (ですが、そのバグ報告の投稿者へのメールは報告の他の投稿者には自動的には通知されないことに注意してください)。merge コマンドや類似の unmerge コマンドの技術詳細については、BTS 制御サーバドキュメントを参照してください。

en: The bug submitter may have forgotten to provide some information, in which case you have to ask them for the required information. You may use the ``moreinfo`` tag to mark the bug as such. Moreover if you can't reproduce the bug, you tag it ``unreproducible``. Anyone who can reproduce the bug is then invited to provide more information on how to reproduce it. After a few months, if this information has not been sent by someone, the bug may be closed.
ja: バグ報告者は情報を書き漏らしている場合、必要な情報を尋ねる必要があります。その様なバグに印をつけるには ``moreinfo`` タグを使います。さらに、そのバグを再現できない場合には、\ ``unreproducible`` タグを付けます。誰もそのバグを再現できない場合、どうやって再現するのか、さらに情報を何ヶ月経っても、この情報が誰からも送られてこない場合はバグは閉じても構いません。

en: If you have fixed a bug in your local copy, or if a fix has been committed to the VCS repository, you may tag the bug as ``pending`` to let people know that the bug is corrected and that it will be closed with the next upload (add the ``closes:`` in the ``changelog``). This is particularly useful if you are several developers working on the same package.
ja: ローカル環境でバグを修正した、あるいは VCS リポジトリに修正をコミットした場合には、バグに ``pending`` タグを付けてバグが修正されたことと次のアップロードでバグが閉じられるであろうことを回りに知らせます (``changelog`` に ``closes:`` を追加します)。これは複数の開発者が同一のパッケージで作業している際に特に役立ちます。

en: When bugs are closed by new uploads
ja: 新規アップロードでバグがクローズされる時

en: As bugs and problems are fixed in your packages, it is your responsibility as the package maintainer to close these bugs. However, you should not close a bug until the package which fixes the bug has been accepted into the Debian archive. Therefore, once you get notification that your updated package has been installed into the archive, you can and should close the bug in the BTS. Also, the bug should be closed with the correct version.
ja: バグや問題があなたのパッケージで修正されたとしたら、そのバグを閉じるのはパッケージメンテナとしての責任になります。しかし、バグを修正したパッケージが Debian アーカイブに受け入れられるまではバグを閉じてはいけません。従って、一旦更新したパッケージがアーカイブにインストールされたという通知を受け取った場合は、BTS でバグを閉じることができますし、そうしなければいけません。もちろん、バグは正しいバージョンで閉じなくてはいけません。

en: However, it's possible to avoid having to manually close bugs after the upload — just list the fixed bugs in your ``debian/changelog`` file, following a certain syntax, and the archive maintenance software will close the bugs for you. For example:
ja: ですが、アップロード後に手動でバグをクローズしなくても済む方法があります — ``debian/changelog`` に以下の特定の書き方にて修正したバグを列挙すれば、それだけで後はアーカイブのメンテナンスソフトがバグをクローズしてくれます。例:

en: Technically speaking, the following Perl regular expression describes how bug closing changelogs are identified:
ja: 技術的に言うと、どの様にしてバグを閉じる changelog が判別されているかを以下の Perl の正規表現にて記述しています:

en: Historically, uploads identified as :ref:`nmu` were tagged ``fixed`` instead of being closed, but that practice was ceased with the advent of version-tracking. The same applied to the tag ``fixed-in-experimental``.
ja: 歴史的に、\ :ref:`nmu` と判別されるアップロードは closed ではなく ``fixed`` とタグがされてきましたが、この習慣はバージョントラッキングの進化によって廃れています。同じことが ``fixed-in-experimental`` タグにも言えます。

en: Bear in mind that it is not obligatory to close bugs using the changelog as described above. If you simply want to close bugs that don't have anything to do with an upload you made, do it by emailing an explanation to *XXX*\ ``-done@bugs.debian.org``. Do **not** close bugs in the changelog entry of a version if the changes in that version of the package don't have any bearing on the bug.
ja: 上に書いたような changelog を使ったバグの閉じ方は必須ではない、ということは念頭に置いておいてください。行ったアップロードとは無関係に単にバグを閉じたい、という場合は、説明をメールに書いて *XXX*\ ``-done@bugs.debian.org`` に送ってバグを閉じてください。そのバージョンのパッケージでの変更がバグに何も関係ない場合は、そのバージョンの changelog エントリではバグを\ **閉じないで**\ ください。

en: For general information on how to write your changelog entries, see :ref:`bpp-debian-changelog`.
ja: どのように changelog のエントリを書くのか、一般的な情報については :ref:`bpp-debian-changelog` を参照してください。

en: Handling security-related bugs
ja: セキュリティ関連バグの取扱い

en: Due to their sensitive nature, security-related bugs must be handled carefully. The Debian Security Team exists to coordinate this activity, keeping track of outstanding security problems, helping maintainers with security problems or fixing them themselves, sending security advisories, and maintaining ``security.debian.org``.
ja: 機密性が高いその性質上、セキュリティ関連のバグは注意深く取り扱わねばなりません。この作業をコーディネイトし、未処理のセキュリティ問題を追い続け、セキュリティ問題についてメンテナを手助けしたり修正自体を行い、セキュリティ勧告を出し、\ ``security.debian.org`` を維持するために Debian セキュリティチームが存在します。

en: When you become aware of a security-related bug in a Debian package, whether or not you are the maintainer, collect pertinent information about the problem, and promptly contact the security team by emailing ``team@security.debian.org``. If desired, email can be encrypted with the Debian Security Contact key, see https://www.debian.org/security/faq#contact\  for details. **DO NOT UPLOAD** any packages for ``stable`` without contacting the team. Useful information includes, for example:
ja: Debian パッケージ中のセキュリティ関連のバグに気づいたら、あなたがメンテナであるかどうかに関わらず、問題に関する正確な情報を集め、まずは ``team@security.debian.org`` 宛にメールを出してセキュリティチームへ連絡を取ってください。お望みであれば、Debian セキュリティ担当窓口の鍵を使ってメールを暗号化できます。詳細は https://www.debian.org/security/faq#contact\ を参照してください。チームに問い合わせること無く 安定版 (``stable``) 向けのパッケージを\ **アップロードしないでください**\ 。例として、役に立つ情報は以下のようなものになります:

en: Whether or not the bug is already public.
ja: バグが既に公開されているか否か

en: Which versions of the package are known to be affected by the bug. Check each version that is present in a supported Debian release, as well as ``testing`` and ``unstable``.
ja: バグによって、どのバージョンが影響を受けると分かっているか。サポートされている Debian のリリース、ならびに ``テスト版 (testing)`` 及び 不安定版 (``unstable``) にある各バージョンをチェックしてください。

en: The nature of the fix, if any is available (patches are especially helpful)
ja: 利用可能なものがあれば、修正内容 (パッチが特に望ましい)

en: Any fixed packages that you have prepared yourself (send the resulting debdiff or alternatively only the ``.diff.gz`` and ``.dsc`` files and read :ref:`bug-security-building` first)
ja: 自身で準備した修正パッケージ (まずは :ref:`bug-security-building` を読んで、debdiff の結果、あるいは ``.diff.gz`` と ``.dsc`` ファイルだけを送ってください)

en: Any assistance you can provide to help with testing (exploits, regression testing, etc.)
ja: テストについて何かしらの手助けになるもの (攻撃コード、リグレッションテストなど)

en: Any information needed for the advisory (see :ref:`bug-security-advisories`)
ja: 勧告に必要になる情報 (:ref:`bug-security-advisories` 参照)

en: As the maintainer of the package, you have the responsibility to maintain it, even in the stable release. You are in the best position to evaluate patches and test updated packages, so please see the sections below on how to prepare packages for the Security Team to handle.
ja: パッケージメンテナとして、あなたは安定版リリースについてもメンテナンスする責任を持ちます。あなたがパッチの評価と更新パッケージのテストを行うのに最も適任な人です。ですから、以下のセキュリティチームによって取り扱ってもらうため、どのようにしてパッケージを用意するかについての章を参照してください。

en: Debian Security Tracker
ja: セキュリティ追跡システム

en: The security team maintains a central database, the `Debian Security Tracker <https://security-tracker.debian.org/>`__. This contains all public information that is known about security issues: which packages and versions are affected or fixed, and thus whether stable, testing and/or unstable are vulnerable. Information that is still confidential is not added to the tracker.
ja: セキュリティチームは集約的なデータベース、\ `Debian セキュリティ追跡システム (Debian Security Tracker) <https://security-tracker.debian.org/>`__\ をメンテナンスしています。これはセキュリティ問題として知られている全ての公開情報を含んでいます: どのパッケージ／バージョンが影響を受ける／修正されているか、つまりは安定版、テスト版、不安定版が脆弱かどうか、という情報です。まだ機密扱いの情報は追跡システムには追加されません。

en: You can search it for a specific issue, but also on package name. Look for your package to see which issues are still open. If you can, please provide more information about those issues, or help to address them in your package. Instructions are on the tracker web pages.
ja: 特定の問題について検索することもできますし、パッケージ名でも検索できます。あなたのパッケージを探して、どの問題がまだ未解決かを確認してください。できれば追加情報を提供するか、パッケージの問題に対処するのを手伝ってください。やり方は追跡システムのウェブページにあります。

en: Confidentiality
ja: 秘匿性

en: Unlike most other activities within Debian, information about security issues must sometimes be kept private for a time. This allows software distributors to coordinate their disclosure in order to minimize their users' exposure. Whether this is the case depends on the nature of the problem and corresponding fix, and whether it is already a matter of public knowledge.
ja: Debian 内での他の多くの活動とは違い、セキュリティ問題に関する情報については、暫くの間秘密にしておく必要がしばしばあります。これによって、ソフトウェアのディストリビュータがユーザが危険にさらされるのを最小限にするため、公開時期を合わせることができます。今回がそうであるかは、問題と対応する修正の性質や、既に既知のものとなっているかどうかによります。

en: There are several ways developers can learn of a security problem:
ja: 開発者がセキュリティ問題を知る方法はいくつかあります:

en: they notice it on a public forum (mailing list, web site, etc.)
ja: 公開フォーラム (メーリングリスト、ウェブサイトなど) で知らせる

en: someone files a bug report
ja: 誰かがバグ報告を登録している

en: someone informs them via private email
ja: 誰かがプライベートなメールで教えてきた

en: In the first two cases, the information is public and it is important to have a fix as soon as possible. In the last case, however, it might not be public information. In that case there are a few possible options for dealing with the problem:
ja: 最初の二つのケースでは、情報は公開されていて可能な限り早く修正することが重要です。しかしながら最後のケースは、公開情報ではないかもしれません。この場合は、問題に対処するのに幾つか取り得る選択肢があります:

en: If the security exposure is minor, there is sometimes no need to keep the problem a secret and a fix should be made and released.
ja: セキュリティの影響度が小さい場合、問題を秘密にしておく必要はなく、修正を行ってリリースするのが良い場合がしばしばあります。

en: If the problem is severe, it is preferable to share the information with other vendors and coordinate a release. The security team keeps in contact with the various organizations and individuals and can take care of that.
ja: 問題が深刻な場合、他のベンダと情報を共有してリリースをコーディネイトする方が望ましいでしょう。セキュリティチームは様々な組織／個人と連絡を取りつづけ、この問題に対応することができます。

en: In all cases if the person who reports the problem asks that it not be disclosed, such requests should be honored, with the obvious exception of informing the security team in order that a fix may be produced for a stable release of Debian. When sending confidential information to the security team, be sure to mention this fact.
ja: どのような場合でも、問題を報告した人がこれを公開しないように求めているのであれば、明白な例外として Debian の安定版リリースに対する修正を作成してもらうためにセキュリティチームへ連絡すること以外、この様な要求は尊重されるべきです。機密情報をセキュリティチームに送る場合は、この点を明示しておくのを忘れないでください。

en: Please note that if secrecy is needed you may not upload a fix to ``unstable`` (or anywhere else, such as a public VCS repository). It is not sufficient to obfuscate the details of the change, as the code itself is public, and can (and will) be examined by the general public.
ja: 機密を要する場合は、修正を不安定版 (``unstable``) (や公開 VCS リポジトリなどその他どこへも) へ修正をアップロードしないよう、注意してください。コードその物が公開されている場合、変更の詳細を難読化するだけでは十分ではなく、皆によって解析され得る (そしてされる) でしょう。

en: There are two reasons for releasing information even though secrecy is requested: the problem has been known for a while, or the problem or exploit has become public.
ja: 機密であることを要求されたにも関わらず、情報を公開するのには 2 つの理由があります: 問題が一定期間既知の状態になっている、あるいは問題や攻撃コードが公開された場合です。

en: The Security Team has a PGP-key to enable encrypted communication about sensitive issues. See the `Security Team FAQ <https://www.debian.org/security/faq#contact>`__ for details.
ja: セキュリティチームは、機密事項に関して通信を暗号化できる PGP 鍵を持っています。詳細については、\ `セキュリティチーム FAQ <https://www.debian.org/security/faq#contact>`__ を参照してください。

en: Security Advisories
ja: セキュリティ勧告

en: Security advisories are only issued for the current, released stable distribution, and *not* for ``testing`` or ``unstable``. When released, advisories are sent to the ``debian-security-announce@lists.debian.org`` mailing list and posted on `the security web page <https://www.debian.org/security/>`__. Security advisories are written and posted by the security team. However they certainly do not mind if a maintainer can supply some of the information for them, or write part of the text. Information that should be in an advisory includes:
ja: セキュリティ勧告は現在のところ、リリースされた安定版ディストリビューションについてのみ、取り扱われます。\ ``テスト版 (testing)`` や 不安定版 (``unstable``) についてでは\ *ありません*\ 。リリースされると、セキュリティ勧告は email-debian-security-announce; メーリングリストに送られ、\ `セキュリティのウェブページ <https://www.debian.org/security/>`__\ に掲載されます。セキュリティ勧告はセキュリティチームによって記述、掲載されます。しかし、メンテナが情報を提供できたり、文章の一部を書けるのであれば、彼らは当然そんなことは気にしません。勧告にあるべき情報は以下を含んでいます:

en: A description of the problem and its scope, including:
ja: 以下のようなものを含めた問題の説明と範囲:

en: The type of problem (privilege escalation, denial of service, etc.)
ja: 問題の種類 (権限の上昇、サービス拒否など)

en: What privileges may be gained, and by whom (if any)
ja: 何の権限が得られるのか、(もし分かれば) 誰が得るのか

en: How it can be exploited
ja: どのようにして攻撃が可能なのか

en: Whether it is remotely or locally exploitable
ja: 攻撃はリモートから可能なのかそれともローカルから可能なのか

en: How the problem was fixed
ja: どのようにして問題が修正されたのか

en: This information allows users to assess the threat to their systems.
ja: この情報によって、ユーザがシステムに対する脅威を評価できるようになります。

en: Version numbers of affected packages
ja: 影響を受けるパッケージのバージョン番号

en: Version numbers of fixed packages
ja: 修正されたパッケージのバージョン番号

en: Information on where to obtain the updated packages (usually from the Debian security archive)
ja: どこで更新されたパッケージを得るかという情報 (通常は Debian のセキュリティアーカイブからです)

en: References to upstream advisories, `CVE <https://cve.mitre.org>`__ identifiers, and any other information useful in cross-referencing the vulnerability
ja: 開発元のアドバイザリへの参照、\ `CVE <https://cve.mitre.org>`__ 番号、脆弱性の相互参照について役立つその他の情報

en: Preparing packages to address security issues
ja: セキュリティ問題に対処するパッケージを用意する

en: One way that you can assist the security team in their duties is to provide them with fixed packages suitable for a security advisory for the stable Debian release.
ja: あなたがセキュリティチームに対し、彼らの職務に関して手助けできる方法の一つは、安定版 Debian リリース用のセキュリティ勧告に適した修正版パッケージを提供することです。

en: This means that moving to a new upstream version is not a good solution. Instead, the relevant changes should be back-ported to the version present in the current stable Debian release. Generally, upstream maintainers are willing to help if needed. If not, the Debian security team may be able to help.
ja: これは、開発元の新しいリリースバージョン (new upstream version) への移行が良い解決策ではないことを意味しています。代わりに、関連する変更を現在の Debian 安定版リリースに存在しているバージョンへバックポートするべきです。通常、開発元のメンテナは助けが必要であれば手伝おうとしてくれます。そうでない場合は、Debian セキュリティチームが手助けすることができます。

en: In some cases, it is not possible to back-port a security fix, for example when large amounts of source code need to be modified or rewritten. If this happens, it may be necessary to move to a new upstream version. However, this is only done in extreme situations, and you must always coordinate that with the security team beforehand.
ja: いくつかのケースでは、例えば大量のソースコードの変更や書き直しが必要など、セキュリティ修正をバックポートできないことがあります。この様な場合、新しいバージョン (new upstream version) へ移行する必要があるかもしれません。しかし、これは極端な状況の場合にのみ行われるものであり、実行する前に必ずセキュリティチームと調整をしなければなりません。

en: Related to this is another important guideline: always test your changes. If you have an exploit available, try it and see if it indeed succeeds on the unpatched package and fails on the fixed package. Test other, normal actions as well, as sometimes a security fix can break seemingly unrelated features in subtle ways.
ja: これに関してはもう一つ重要な指針があります: 必ず変更についてテストをしてください。攻撃用コード (exploit) が入手可能な場合には、それを試してみて、パッチを当てていないパッケージで成功するか、修正したパッケージでは失敗することかどうかを確かめてみてください。他の確認として、セキュリティ修正は時折表面上はそれと関係が無いような機能を壊すことがあるので、通常の動作も同様にテストしてください。

en: Do **NOT** include any changes in your package which are not directly related to fixing the vulnerability. These will only need to be reverted, and this wastes time. If there are other bugs in your package that you would like to fix, make an upload to proposed-updates in the usual way, after the security advisory is issued. The security update mechanism is not a means for introducing changes to your package which would otherwise be rejected from the stable release, so please do not attempt to do this.
ja: 脆弱性の修正に直接関係しない変更をパッケージへ\ **加えない**\ ようにしてください。この様な変更は元に戻さなくてはならなくなるだけで、時間を無駄にします。他に直したいバグがパッケージにある場合は、セキュリティ勧告が発行された後、通常通りに proposed-update にアップロードを行ってください。セキュリティ更新の仕組みは、それ以外の方法では安定版リリースから reject されるであろう変更をあなたのパッケージに加える方法ではありませんので、この様な事はしないでください。

en: Review and test your changes as much as possible. Check the differences from the previous version repeatedly (``interdiff`` from the ``patchutils`` package and ``debdiff`` from ``devscripts`` are useful tools for this, see :ref:`debdiff`).
ja: 変更点を可能な限り見直してください。以前のバージョンとの変更点を繰り返し確認してください (これには ``patchutils`` パッケージの ``interdiff`` や ``devscripts`` の ``debdiff`` が役立ちます。\ :ref:`debdiff` を参照してください)。

en: Be sure to verify the following items:
ja: 以下の項目を必ず確認してください

en: **Target the right distribution** in your ``debian/changelog``: |codename-security| (e.g. |codename-stable-security|). Do not target *distribution*\ ``-proposed-updates`` or ``stable``!
ja: ``debian/changelog`` で **正しいディストリビューションを対象にする**: |codename-security| (例えば |codename-stable-security|)。\ *distribution*\ ``-proposed-updates`` や ``stable`` を対象にしないでください!

en: Make descriptive, meaningful changelog entries. Others will rely on them to determine whether a particular bug was fixed. Add ``closes:`` statements for any **Debian bugs** filed. Always include an external reference, preferably a **CVE identifier**, so that it can be cross-referenced. However, if a CVE identifier has not yet been assigned, do not wait for it but continue the process. The identifier can be cross-referenced later.
ja: 説明が十分にされている、意味がある changelog エントリを書くこと。他の人は、これらを元に特定のバグが修正されているのかを見つけ出します。登録されている **Debian バグ** に対して ``closes:`` 行を追加すること。外部のリファレンス、できれば **CVE 識別番号** を常に含めること、そうすれば相互参照が可能になります。しかし、CVE 識別番号がまだ付与されていない場合には、それを待たずに作業を進めてください。識別番号は後ほど付与することができます。

en: Make sure the **version number** is proper. It must be greater than the current package, but less than package versions in later distributions. If in doubt, test it with ``dpkg --compare-versions``. Be careful not to re-use a version number that you have already used for a previous upload, or one that conflicts with a binNMU. The convention is to append ``+deb``\ *X*\ ``u1`` (where *X* is the major release number), e.g. |version1-revision-deb-version-stable-u1|, of course increasing 1 for any subsequent uploads.
ja: **バージョン番号**\ が正しいことを確認する。現在のパッケージより大きく、しかし以降のディストリビューションよりパッケージバージョンが小さい必要があります。分からない場合は ``dpkg --compare-versions`` でテストしてください。以前のアップロードで既に使っているバージョン番号を再利用しないように注意してください。そうしないと番号が binNMU と衝突します。\ ``+deb``\ *X*\ ``u1`` (*X* はメジャーリリース番号) を追加するのが通例です。例えば |version1-revision-deb-version-stable-u1| とします。もちろん 1 はアップロードするごとに増やします。

en: Unless the upstream source has been uploaded to ``security.debian.org`` before (by a previous security update), build the upload **with full upstream source** (``dpkg-buildpackage -sa``). If there has been a previous upload to ``security.debian.org`` with the same upstream version, you may upload without upstream source (``dpkg-buildpackage -sd``).
ja: これまでに (以前のセキュリティ更新によって) ``security.debian.org`` へ開発元のソースコードをアップロードしていなければ、\ **開発元のソースコードを全て含めて**\ アップロードするパッケージをビルドする (``dpkg-buildpackage -sa``)。以前、同じ開発元のバージョンで ``security.debian.org`` にアップロードしたことがある場合は、開発元のソースコード無しでアップロードしても構いません (``dpkg-buildpackage -sd``)。

en: Be sure to use the **exact same ``*.orig.tar.{gz,bz2,xz}``** as used in the normal archive, otherwise it is not possible to move the security fix into the main archives later.
ja: 通常のアーカイブで使われているのと\ **全く同じ ``*.orig.tar.{gz,bz2,xz}``**\ を必ず使うようにしてください。さもなくば、後ほどセキュリティ修正を main アーカイブに移動することができません。

en: Build the package on a **clean system** which only has packages installed from the distribution you are building for. If you do not have such a system yourself, you can use a debian.org machine (see :ref:`server-machines`) or setup a chroot (see :ref:`pbuilder` and :ref:`debootstrap`).
ja: ビルドを行っているディストリビューションからインストールしたパッケージだけが含まれている\ **クリーンなシステム上で**\ パッケージをビルドしてください。その様なシステムを自分で持っていない場合は、debian.org マシン (:ref:`server-machines` を参照してください) を使うこともできますし、chroot を設定することもできます (:ref:`pbuilder` と :ref:`debootstrap` を参照してください)。

en: Uploading the fixed package
ja: 修正したパッケージをアップロードする

en: Do **NOT** upload your fix to ``proposed-updates`` without coordinating with the security team. Packages from ``security.debian.org`` will be copied into the ``proposed-updates`` directory automatically. If a package with the same or a higher version number is already installed into the archive, the security update will be rejected by the archive system. That way, the stable distribution will end up without a security update for this package instead.
ja: セキュリティチームと調整する事無しに ``proposed-updates`` へ修正したものをアップロード\ **しない**\ ようにしてください。\ ``security.debian.org`` からパッケージは ``proposed-updates`` ディレクトリに自動的にコピーされます。アーカイブに同じ、あるいはより高いバージョン番号のものが既にインストールされている場合は、セキュリティアップデートはアーカイブシステムに reject されます。そうすると、安定版ディストリビューションはこのパッケージに対するセキュリティ更新無しで終了してしまうでしょう。

en: Once an upload to the security queue has been accepted, the package will automatically be built for all architectures and stored for verification by the security team.
ja: セキュリティキューへアップロードしたものが許可されると、パッケージは自動的にすべてのアーキテクチャに対してビルドされ、セキュリティチームによる確認の為に保存されます。

en: If a member of the security team accepts a package, it will be installed on ``security.debian.org`` as well as proposed for the proper *distribution*\ ``-proposed-updates`` on ``ftp-master.debian.org``.
ja: セキュリティチームのメンバーがパッケージを許可した場合は、proposed パッケージに対する ``ftp-master.debian.org`` 上の適切な *distribution*\ ``-proposed-updates`` と同様に ``security.debian.org`` 上にインストールされます。

en: Moving, removing, renaming, orphaning, adopting, and reintroducing packages
ja: パッケージの移動、削除、リネーム、放棄、引き取り、再導入

en: Some archive manipulation operations are not automated in the Debian upload process. These procedures should be manually followed by maintainers. This chapter gives guidelines on what to do in these cases.
ja: アーカイブの変更作業のいくつかは、Debian のアップロードプロセスでは自動的なものにはなっていません。これらの手続きはメンテナによる手動での作業である必要があります。この章では、この様な場合に何をするかのガイドラインを提供します。

en: Moving packages
ja: パッケージの移動

en: Sometimes a package will change its section. For instance, a package from the ``non-free`` section might be GPL'd in a later version, in which case the package should be moved to ``main`` or ``contrib``. [1]_
ja: 時折、パッケージは属しているセクションが変わることがあります。例えば「\ ``non-free``\ 」セクションのパッケージが新しいバージョンで GPL になった場合、パッケージは「main」か「contrib」に移動する必要があります。 [1]_

en: If you need to change the section for one of your packages, change the package control information to place the package in the desired section, and re-upload the package (see the `Debian Policy Manual <https://www.debian.org/doc/debian-policy/>`__ for details). You must ensure that you include the ``.orig.tar.{gz,bz2,xz}`` in your upload (even if you are not uploading a new upstream version), or it will not appear in the new section together with the rest of the package. If your new section is valid, it will be moved automatically. If it does not, then contact the ftpmasters in order to understand what happened.
ja: パッケージのどれかがセクションを変更する必要がある場合、希望するセクションにパッケージを配置するためパッケージの control 情報を変更してから再アップロードします (詳細については `Debian ポリシーマニュアル <https://www.debian.org/doc/debian-policy/>`__\ を参照してください)。必ず ``.orig.tar.{gz,bz2,xz}`` を (開発元のバージョンが新しいものになったのではなくても) アップロードに含める必要があります。新しいセクションが正しい場合は、自動的に移動されます。移動されない場合には、何が起こったのかを理解するために ftpmaster に連絡を取ります。

en: If, on the other hand, you need to change the ``subsection`` of one of your packages (e.g., ``devel``, ``admin``), the procedure is slightly different. Correct the subsection as found in the control file of the package, and re-upload that. Also, you'll need to get the override file updated, as described in :ref:`override-file`.
ja: 一方で、もしパッケージの一つの\ ``サブセクション`` (例:「devel」「admin」) を変更する必要がある、という場合には、手順は全く異なります。パッケージの control ファイルにあるサブセクションを修正して、再アップロードします。また、\ :ref:`override-file` に記述してあるように override ファイルを更新する必要が出てくるでしょう。

en: Removing packages
ja: パッケージの削除

en: There is one exception when an explicit removal request is not necessary: If a (source or binary) package is no longer built from source, it will be removed semi-automatically. For a binary-package, this means if there is no longer any source package producing this binary package; if the binary package is just no longer produced on some architectures, a removal request is still necessary. For a source-package, this means that all binary packages it refers to have been taken over by another source package.
ja: 例外として、明示的な削除依頼が必要ない場合が一つあります: (ソース、あるいはバイナリ) パッケージがソースからビルドされなくなった場合、半自動的に削除されます。バイナリパッケージの場合、これはこのバイナリパッケージを生成するソースパッケージがもはや存在しないということを意味します。バイナリパッケージがいくつかのアーキテクチャで生成されなくなったという場合には、削除依頼は必要です。ソースパッケージの場合は、関連の全バイナリパッケージが別のソースパッケージによって上書きされるのを意味しています。

en: In your removal request, you have to detail the reasons justifying the request. This is to avoid unwanted removals and to keep a trace of why a package has been removed. For example, you can provide the name of the package that supersedes the one to be removed.
ja: 削除依頼では、依頼を判断する理由を詳細に書く必要があります。これは不必要な削除を避け、何故パッケージが削除されたのかを追跡できるようにするためです。例えば、削除されるパッケージにとって代わるパッケージの名前を記述します。

en: Usually you only ask for the removal of a package maintained by yourself. If you want to remove another package, you have to get the approval of its maintainer. Should the package be orphaned and thus have no maintainer, you should first discuss the removal request on ``debian-qa@lists.debian.org``. If there is a consensus that the package should be removed, you should reassign and retitle the ``O:`` bug filed against the ``wnpp`` package instead of filing a new bug as removal request.
ja: 通常は自分がメンテナンスしているパッケージの削除のみを依頼します。その他のパッケージを削除したい場合は、メンテナの許可を取る必要があります。パッケージが放棄されたのでメンテナがいない場合は、まず ``debian-qa@lists.debian.org`` で削除依頼について議論をしてください。パッケージの削除についての合意ができたら、削除依頼の新規バグを登録するのではなく、\ ``wnpp`` パッケージに対して登録されているバグを reassign して ``O:`` に題名を変更するべきです。

en: Further information relating to these and other package removal related topics may be found at https://wiki.debian.org/ftpmaster_Removals\ and https://qa.debian.org/howto-remove.html\ .
ja: この件、あるいはパッケージ削除に関するその他のトピックについて、さらなる情報を https://wiki.debian.org/ftpmaster_Removals\  や https://qa.debian.org/howto-remove.html\  で参照できます。

en: If in doubt concerning whether a package is disposable, email ``debian-devel@lists.debian.org`` asking for opinions. Also of interest is the ``apt-cache`` program from the ``apt`` package. When invoked as ``apt-cache showpkg`` *package*, the program will show details for *package*, including reverse depends. Other useful programs include ``apt-cache rdepends``, ``apt-rdepends``, ``build-rdeps`` (in the ``devscripts`` package) and ``grep-dctrl``. Removal of orphaned packages is discussed on ``debian-qa@lists.debian.org``.
ja: パッケージを破棄しても構わないか迷う場合には、意見を聞きに ``debian-devel@lists.debian.org`` へメールしてください。\ ``apt`` の ``apt-cache`` プログラムも重要です。\ ``apt-cache showpkg``\ *パッケージ名* として起動した際、プログラムは\ *パッケージ名*\ の被依存関係を含む詳細を表示します。他にも ``apt-cache rdepends``\ 、\ ``apt-rdepends``\ 、\ ``build-rdeps`` (``devscripts`` パッケージに含まれる)、\ ``grep-dctrl`` などの有用なプログラムが非依存関係を含む情報を表示します。みなしご化されたパッケージの削除は、\ ``debian-qa@lists.debian.org`` で話し合われます。

en: Once the package has been removed, the package's bugs should be handled. They should either be reassigned to another package in the case where the actual code has evolved into another package (e.g. ``libfoo12`` was removed because ``libfoo13`` supersedes it) or closed if the software is simply no longer part of Debian. When closing the bugs, to avoid marking the bugs as fixed in versions of the packages in previous Debian releases, they should be marked as fixed in the version ``<most-recent-version-ever-in-Debian>+rm``.
ja: 一旦パッケージが削除されたら、パッケージのバグを処理する必要があります。実際のコードが別のパッケージに含まれるようになったので、別のパッケージへバグを付け替える (例えば、``libfoo13`` が上書きするので、\ ``libfoo12`` が削除される) か、あるいはソフトウェアがもう Debian の一部では無くなった場合にはバグを閉じるかする必要があります。バグを閉じる場合、過去の Debian のリリースにあるパッケージバージョンで修正されたとマークするのを避けてください。バージョン ``<most-recent-version-ever-in-Debian>+rm`` で修正されたとマークしなければなりません。

en: Removing packages from ``Incoming``
ja: ``Incoming`` からパッケージを削除する

en: In the past, it was possible to remove packages from ``incoming``. However, with the introduction of the new incoming system, this is no longer possible. [4]_ Instead, you have to upload a new revision of your package with a higher version than the package you want to replace. Both versions will be installed in the archive but only the higher version will actually be available in ``unstable`` since the previous version will immediately be replaced by the higher. However, if you do proper testing of your packages, the need to replace a package should not occur too often anyway.
ja: 以前は、\ ``incoming`` からパッケージを削除することが可能でした。しかし、新しい incoming システムが導入されたことにより、これはもはや不可能となっています。[4]_ その代わりに、置き換えたいパッケージよりも高いバージョンのリビジョンの新しいパッケージをアップロードする必要があります。両方のバージョンのパッケージがアーカイブにインストールされますが、一つ前のバージョンはすぐに高いバージョンで置き換えられるため、実際にはバージョンが高い方だけが 不安定版 (``unstable``) で利用可能になります。しかし、もしあなたがパッケージをきちんとテストしていれば、パッケージを置き換える必要はそんなに頻繁には無いはずです。

en: Replacing or renaming packages
ja: パッケージをリプレースあるいはリネームする

en: When the upstream maintainers for one of your packages chose to rename their software (or you made a mistake naming your package), you should follow a two-step process to rename it. In the first step, change the ``debian/control`` file to reflect the new name and to replace, provide and conflict with the obsolete package name (see the `Debian Policy Manual <https://www.debian.org/doc/debian-policy/>`__ for details). Please note that you should only add a ``Provides`` relation if all packages depending on the obsolete package name continue to work after the renaming. Once you've uploaded the package and the package has moved into the archive, file a bug against ``ftp.debian.org`` asking to remove the package with the obsolete name (see :ref:`removing-pkgs`). Do not forget to properly reassign the package's bugs at the same time.
ja: あなたのパッケージのどれかの開発元のメンテナらが、ソフトウェアをリネームするのを決めた時 (あるいはパッケージを間違えて名前を付けた時)、以下の二段階のリネーム手続きに従う必要があります。最初の段階では、``debian/control`` ファイルに新しい名前を反映し、利用しなくなるパッケージ名に対して Replace、Provides、Conflicts を設定する変更をします (詳細に関しては `Debian ポリシーマニュアルl <https://www.debian.org/doc/debian-policy/>`__ を参照)。注意してほしいのは、利用しなくなるパッケージ名がリネーム後も動作する場合のみ、\ ``Provides`` を付け加えるべきだということです。一旦パッケージをアップロードがアップロードされてアーカイブに移動したら、\ ``ftp.debian.org`` に対してバグを報告してください (:ref:`removing-pkgs` 参照)。同時にパッケージのバグを正しく付け替えするのを忘れないでください。

en: At other times, you may make a mistake in constructing your package and wish to replace it. The only way to do this is to increase the version number and upload a new version. The old version will be expired in the usual manner. Note that this applies to each part of your package, including the sources: if you wish to replace the upstream source tarball of your package, you will need to upload it with a different version. An easy possibility is to replace ``foo_1.00.orig.tar.gz`` with ``foo_1.00+0.orig.tar.gz`` or ``foo_1.00.orig.tar.bz2``. This restriction gives each file on the ftp site a unique name, which helps to ensure consistency across the mirror network.
ja: 他に、パッケージの作成でミスを犯したので置き換えたいという場合があるかもしれません。これを行う方法は唯一つ、バージョン番号を上げて新しいバージョンをアップロードすることです。通常、古いバージョンは無効になります。これはソースを含めた各パッケージ部分に適用されることに注意してください: パッケージの開発元のソース tarball を入れ替えたい場合には、別のバージョンをつけてアップロードする必要があります。よくある例は ``foo_1.00.orig.tar.gz`` を ``foo_1.00+0.orig.tar.gz``\ 、あるいは ``foo_1.00.orig.tar.bz2`` で置き換えるというものです。この制約によって、ftp サイト上で各ファイルが一意の名前を持つことになり、ミラーネットワークをまたがった一貫性を保障するのに役立ちます。

en: Orphaning a package
ja: パッケージを放棄する

en: If you can no longer maintain a package, you need to inform others, and see that the package is marked as orphaned. You should set the package maintainer to ``Debian QA Group <packages@qa.debian.org>`` and submit a bug report against the pseudo package ``wnpp``. The bug report should be titled ``O:`` *package* ``--`` *short description* indicating that the package is now orphaned. The severity of the bug should be set to ``normal``; if the package has a priority of standard or higher, it should be set to important. If you feel it's necessary, send a copy to ``debian-devel@lists.debian.org`` by putting the address in the X-Debbugs-CC: header of the message (no, don't use CC:, because that way the message's subject won't indicate the bug number).
ja: パッケージをもうメンテナンスできなくなってしまった場合、ほかの人に知らせて、パッケージが放棄 (orphaned) とマークされたのが分かるようにする必要があります。パッケージメンテナを ``Debian QA Group <packages@qa.debian.org>`` に設定し、疑似パッケージ\ ``wnpp`` に対してバグ報告を送信しなければなりません。バグ報告は、パッケージが今放棄されていることを示すように ``O:``\ *パッケージ名*\ ``--``\ *短い要約* というタイトルにする必要があります。バグの重要度は ``通常 (normal)`` に設定しなければなりません; パッケージの重要 (priority) が standard より高い場合には重要 (important) に設定する必要があります。必要だと思うのならば、メッセージの X-Debbugs-CC: ヘッダのアドレスに ``debian-devel@lists.debian.org`` を入れてコピーを送ってください (そう、CC: を使わないでください。その理由は、CC: を使うと、メッセージの題名がバグ番号を含まないからです)。

en: If you just intend to give the package away, but you can keep maintainership for the moment, then you should instead submit a bug against ``wnpp`` and title it ``RFA:`` *package* ``--`` *short description*. ``RFA`` stands for ``Request For Adoption``.
ja: パッケージを手放したいが、しばらくの間はメンテナンスを継続できる場合には、代わりに ``wnpp`` へ ``RFA:``\ *パッケージ名*\ ``--``\ *短い要約* という題名でバグ報告を送信する必要があります。\ ``RFA`` は ``Request For Adoption (引き取り依頼)`` を意味しています。

en: More information is on the `WNPP web pages <https://www.debian.org/devel/wnpp/>`__.
ja: より詳細な情報は `WNPP ウェブページ <https://www.debian.org/devel/wnpp/>`__\ にあります。

en: Adopting a package
ja: パッケージを引き取る

en: A list of packages in need of a new maintainer is available in the `Work-Needing and Prospective Packages list (WNPP) <https://www.debian.org/devel/wnpp/>`__. If you wish to take over maintenance of any of the packages listed in the WNPP, please take a look at the aforementioned page for information and procedures.
ja: 新たなメンテナが必要なパッケージの一覧は `作業が望まれるパッケージ (WNPP、Work-Needing and Prospective Packages list) <https://www.debian.org/devel/wnpp/>`__ で入手できます。WNPP でリストに挙がっているパッケージのどれかに対するメンテナンスを引き継ぎたい場合には、情報と手続きについては前述のページを確認してください。

en: If you take over an old package, you probably want to be listed as the package's official maintainer in the bug system. This will happen automatically once you upload a new version with an updated ``Maintainer`` field, although it can take a few hours after the upload is done. If you do not expect to upload a new version for a while, you can use :ref:`pkg-tracker` to get the bug reports. However, make sure that the old maintainer has no problem with the fact that they will continue to receive the bugs during that time.
ja: 古いパッケージを引き継いだ場合は、おそらくバグ追跡システムでパッケージの公式メンテナとして表示されるようにしたいことでしょう。これは、一旦 ``Maintainer`` 欄を更新した新しいバージョンをアップロードすれば自動的に行われますが、アップロードが完了してから数時間はかかります。しばらくは新しいバージョンをアップロードする予定が無い場合は、\ :ref:`pkg-tracker` を使ってバグ報告を受け取ることができます。しかし、以前のメンテナにしばらくの間はバグ報告が届き続けても問題無いことを確認してください。

en: Reintroducing packages
ja: パッケージの再導入

en: Packages are often removed due to release-critical bugs, absent maintainers, too few users or poor quality in general. While the process of reintroduction is similar to the initial packaging process, you can avoid some pitfalls by doing some historical research first.
ja: パッケージは、リリースクリティカルのバグやメンテナ不在、不人気あるいは全体的な品質の低さ等により削除されることがよくあります。再導入プロセスはパッケージ化の開始時と似ていますが、あらかじめその歴史的経緯を調べておくことにより、落し穴にはまるのをいくらか避けることができます。

en: You should check why the package was removed in the first place. This information can be found in the removal item in the news section of the PTS page for the package or by browsing the log of `removals <https://ftp-master.debian.org/#removed>`__. The removal bug will tell you why the package was removed and will give some indication of what you will need to work on in order to reintroduce the package. It may indicate that the best way forward is to switch to some other piece of software instead of reintroducing the package.
ja: まず初めに、パッケージが削除された理由を確認しましょう。この情報はそのパッケージの PTS ページのニュースから削除の項目か\ `削除 <https://ftp-master.debian.org/#removed>`__\ ログを探すことにより見つけられます。削除のバグにはそのパッケージが削除された理由や、そのパッケージの再導入にあたって必要なことがいくらか提示されているでしょう。パッケージの再導入ではなくどこか他のソフトウェアの一部への乗り替えが最適であるということが提示されているかもしれません。

en: It may be appropriate to contact the former maintainers to find out if they are working on reintroducing the package, interested in co-maintaining the package or interested in sponsoring the package if needed.
ja: 以前のメンテナに連絡を取り、パッケージの再導入のために作業していないか、パッケージ共同保守に関心はないか、必要になったときにパッケージのスポンサーをしてくれないか、等を確認しておくと良いでしょう。

en: You should do all the things required before introducing new packages (:ref:`newpackage`).
ja: 新しいパッケージ (:ref:`newpackage`) の導入前に必要なことは全てやりましょう。

en: You should base your work on the latest packaging available that is suitable. That might be the latest version from ``unstable``, which will still be present in the `snapshot archive <https://snapshot.debian.org/>`__.
ja: 利用できる中で適切な最新のパッケージをベースに作業しましょう。これは\ ``unstable`` の最新版かもしれません。また、\ `snapshot アーカイブ <https://snapshot.debian.org>`__\ にはまだ存在するでしょう。

en: The version control system used by the previous maintainer might contain useful changes, so it might be a good idea to have a look there. Check if the ``control`` file of the previous package contained any headers linking to the version control system for the package and if it still exists.
ja: 前のメンテナにより利用されていたバージョン管理システムに有用な変更が記録されているかもしれないので、確認してみるのは良いことです。以前のパッケージの ``control`` ファイルにそのパッケージのバージョン管理システムにリンクしているヘッダが無いか、それがまだ存在するか確認してください。

en: Package removals from ``unstable`` (not ``testing``, ``stable`` or ``oldstable``) trigger the closing of all bugs related to the package. You should look through all the closed bugs (including archived bugs) and unarchive and reopen any that were closed in a version ending in ``+rm`` and still apply. Any that no longer apply should be marked as fixed in the correct version if that is known.
ja: (``testing`` や ``stable``\ 、\ ``oldstable`` ではなく) ``unstable`` からパッケージが削除されると、そのパッケージに関連するバグは全て閉じられます。閉じられたバグを全て (アーカイブされているバグを含めて) 確認し、\ ``+rm`` で終わるバージョンで閉じられていて現在でも有効なものを全て unarchive および reopen してください。有効ではなくなっているものは修正されているバージョンがわかればすべて修正済みとしてください。

en: Porting and being ported
ja: 移植作業、そして移植できるようにすること

en: Debian supports an ever-increasing number of architectures. Even if you are not a porter, and you don't use any architecture but one, it is part of your duty as a maintainer to be aware of issues of portability. Therefore, even if you are not a porter, you should read most of this chapter.
ja: Debian がサポートするアーキテクチャの数は増え続けています。あなたが移植作業者ではない、あるいは別のアーキテクチャを使うことが無いという場合であっても、移植性の問題に注意を払うことはメンテナとしてのあなたの義務です。従って、あなたが移植作業者でなくても、この章の大半を読む必要があります。

en: Being kind to porters
ja: 移植作業者に対して協力的になる

en: Porters have a difficult and unique task, since they are required to deal with a large volume of packages. Ideally, every source package should build right out of the box. Unfortunately, this is often not the case. This section contains a checklist of *gotchas* often committed by Debian maintainers — common problems which often stymie porters, and make their jobs unnecessarily difficult.
ja: 移植作業者は、難解かつ他には無いタスクを抱えています。それは、彼らは膨大な量のパッケージに対処する必要があるからです。理想を言えば、すべてのソースパッケージは変更を加えないできちんとビルドできるべきです。残念なことに、その様な場合はほとんどありません。この章は Debian メンテナによってよくコミットされる「潜在的な問題」のチェックリストを含んでいます — よく移植作業者を困らせ、彼らの作業を不必要に難解にする共通の問題です。

en: By far, most of the problems encountered by porters are caused by *packaging bugs* in the source packages. Here is a checklist of things you should check or be aware of.
ja: 移植作業者が遭遇する問題のほとんどは、何といっても、ソースパッケージ内での\ *パッケージ作成のバグ*\ によって引き起こされます。以下は、確認あるいは注意すべき項目のリストです。

en: If you can't set up a proper chroot, ``dpkg-depcheck`` may be of assistance (see :ref:`dpkg-depcheck`).
ja: chroot を正しく設定できない場合は、\ ``dpkg-depcheck`` が手助けになることでしょう (:ref:`dpkg-depcheck` 参照)。

en: See the `Debian Policy Manual <https://www.debian.org/doc/debian-policy/>`__ for instructions on setting build dependencies.
ja: ビルドの依存情報の指定方法については、\ `Debian ポリシーマニュアル <https://www.debian.org/doc/debian-policy/>`__\ を参照してください。

en: Don't set architecture to a value other than ``all`` or ``any`` unless you really mean it. In too many cases, maintainers don't follow the instructions in the `Debian Policy Manual <https://www.debian.org/doc/debian-policy/>`__. Setting your architecture to only one architecture (such as ``i386`` or ``amd64``) is usually incorrect.
ja: 意図がある場合以外は、アーキテクチャの値を ``all`` または ``any`` 以外に指定しないでください。非常に多くの場合、メンテナが `Debianポリシーマニュアル <https://www.debian.org/doc/debian-policy/>`__\ の指示に従っていません。アーキテクチャを単一のものに指定する (``i386`` あるいは ``amd64`` など) は大抵誤りです。

en: Make sure your source package is correct. Do ``dpkg-source -x`` *package*\ ``.dsc`` to make sure your source package unpacks properly. Then, in there, try building your package from scratch with ``dpkg-buildpackage``.
ja: ソースパッケージが正しいことを確かめてください。ソースパッケージが正しく展開されたのを確認するため、\ ``dpkg-source -x``\ *package*\ ``.dsc`` を実行してください。そして、ここでは、一からパッケージを ``dpkg-buildpackage`` でビルドするのに挑戦してみてください。

en: Make sure you don't ship your source package with the ``debian/files`` or ``debian/substvars`` files. They should be removed by the ``clean`` target of ``debian/rules``.
ja: ``debian/files`` や ``debian/substvars`` を含んだソースパッケージを出していないかを確かめてください。これらは、\ ``debian/rules`` の ``clean`` ターゲットによって削除されるべきです。

en: Don't depend on the package you're building being installed already (a sub-case of the above issue). There are, of course, exceptions to this rule, but be aware that any case like this needs manual bootstrapping and cannot be done by automated package builders.
ja: 構築中の既にインストールしてあるパッケージに依存しないでください (上記の話の一例です)。もちろん、このルールには例外はありますが、そのような場合には手動で一から環境を構築する必要があり、パッケージ作成マシンで自動的に構築することはできません。

en: Don't rely on the compiler being a certain version, if possible. If not, then make sure your build dependencies reflect the restrictions, although you are probably asking for trouble, since different architectures sometimes standardize on different compilers.
ja: 可能であれば、特定のバージョンのコンパイラに依存しないでください。もし無理であれば、その制約をビルドの依存関係に反映されているのを確認してください。だとしても異なったアーキテクチャでは時折異なったバージョンのコンパイラで統一されているので、それでも恐らく問題を引き起こすことになるでしょう。

en: Make sure your ``debian/rules`` contains separate ``binary-arch`` and ``binary-indep`` targets, as the Debian Policy Manual requires. Make sure that both targets work independently, that is, that you can call the target without having called the other before. To test this, try to run ``dpkg-buildpackage -B``.
ja: ``debian/rules`` で、Debian ポリシーマニュアルが定めるように、\ ``binary-arch`` 及び ``binary-indep`` ターゲットに分かれて含まれていることを確かめてください。両方のターゲットが独立して動作するのを確かめてください。つまり、他のターゲットを事前に呼び出さなくても、ターゲットを呼び出せるのを確かめるということです。これをテストするには、\ ``dpkg-buildpackage -B`` を実行してください。

en: Guidelines for porter uploads
ja: 移植作業者のアップロード (porter upload) に関するガイドライン

en: If the package builds out of the box for the architecture to be ported to, you are in luck and your job is easy. This section applies to that case; it describes how to build and upload your binary package so that it is properly installed into the archive. If you do have to patch the package in order to get it to compile for the other architecture, you are actually doing a source NMU, so consult :ref:`nmu-guidelines` instead.
ja: パッケージが移植作業を行うアーキテクチャで手を入れずに構築できるのであれば、あなたは幸運で作業は簡単です。この章は、その様な場合に当てはめられます: きちんとアーカイブにインストールされるために、どうやってバイナリパッケージを構築・アップロードするかを記述しています。他のアーキテクチャでコンパイルできるようにするため、パッケージにパッチを当てる必要がある場合は、実際のところ、ソース NMU を行なうので、代わりに :ref:`nmu-guidelines` を参照してください。

en: For a porter upload, no changes are being made to the source. You do not need to touch any of the files in the source package. This includes ``debian/changelog``.
ja: 移植作業者のアップロード (porter upload) は、ソースに何も変更を加えません。ソースパッケージ中のファイルには触る必要はありません。これは ``debian/changelog`` を含みます。

en: The way to invoke ``dpkg-buildpackage`` is as ``dpkg-buildpackage -B -m`` *porter-email*. Of course, set *porter-email* to your email address. This will do a binary-only build of only the architecture-dependent portions of the package, using the ``binary-arch`` target in ``debian/rules``.
ja: ``dpkg-buildpackage`` を ``dpkg-buildpackage -B -m``\ *porter-email* として起動してください。もちろん、\ *porter-email*\ にはあなたのメールアドレスを設定します。これは\ ``debian/rules`` の ``binary-arch`` を使ってパッケージのバイナリ依存部分のみのビルドを行います。

en: If you are working on a Debian machine for your porting efforts and you need to sign your upload locally for its acceptance in the archive, you can run ``debsign`` on your ``.changes`` file to have it signed conveniently, or use the remote signing mode of ``dpkg-sig``.
ja: 移植作業のために Debian マシン上で作業をしていて、アーカイブに入れてもらうためにアップロードするパッケージにローカルでサインする必要がある場合は、\ ``.changes`` に対して ``debsign`` を手軽に実行するのもできますし、\ ``dpkg-sig`` のリモート署名モードを使うこともできます。

en: Recompilation or binary-only NMU
ja: 再コンパイル、あるいは binary-only NMU

en: Sometimes the initial porter upload is problematic because the environment in which the package was built was not good enough (outdated or obsolete library, bad compiler, etc.). Then you may just need to recompile it in an updated environment. However, you have to bump the version number in this case, so that the old bad package can be replaced in the Debian archive (``dak`` refuses to install new packages if they don't have a version number greater than the currently available one).
ja: 時折、最初の移植作業者のアップロード作業は困難なものになります。パッケージが構築された環境があまり良くないからです (古すぎる、使われていないライブラリがある、コンパイラの問題、などなど…)。その場合には、更新した環境で再コンパイルする必要があるでしょう。しかし、この場合にはバージョンを上げる必要があり、古いおかしなパッケージは Debian アーカイブ中で入れ替えられることになります (現在利用可能なものよりバージョン番号が大きくない場合、``dak`` は新しいパッケージのインストールを拒否します)。

en: You have to make sure that your binary-only NMU doesn't render the package uninstallable. This could happen when a source package generates arch-dependent and arch-independent packages that have inter-dependencies generated using dpkg's substitution variable ``$(Source-Version)``.
ja: binary-only NMU がパッケージをインストール不可能にしてしまっていないことを確認する必要があります。ソースパッケージが、dpkg の substitution 変数 ``$(Source-Version)`` を使って内部依存関係を生成しているアーキテクチャ依存パッケージとアーキテクチャ非依存パッケージを生成した場合に起こる可能性があります。

en: Despite the required modification of the changelog, these are called binary-only NMUs — there is no need in this case to trigger all other architectures to consider themselves out of date or requiring recompilation.
ja: changelog の変更が必要かどうかに関わらず、これらは binary-only NMU と呼ばれます — この場合には、他の全アーキテクチャで古すぎるかどうかや再コンパイルが必要かなどを考える必要はありません。

en: Such recompilations require special *magic* version numbering, so that the archive maintenance tools recognize that, even though there is a new Debian version, there is no corresponding source update. If you get this wrong, the archive maintainers will reject your upload (due to lack of corresponding source code).
ja: このような再コンパイルは、特別な「magic」バージョン番号を付けるのを必要とするので、アーカイブのメンテナンスツールは、これを理解してくれます。新しい Debian バージョンで、対応するソースアップデートが無くても、です。これを間違えた場合、アーカイブメンテナは (対応するソースコードが欠落しているので) アップロードを拒否します。

en: The *magic* for a recompilation-only NMU is triggered by using a suffix appended to the package version number, following the form ``b``\ *number*. For instance, if the latest version you are recompiling against was version ``2.9-3``, your binary-only NMU should carry a version of ``2.9-3+b1``. If the latest version was ``3.4+b1`` (i.e, a native package with a previous recompilation NMU), your binary-only NMU should have a version number of ``3.4+b2``. [2]_
ja: 再コンパイルのみの NMU への「magic」は、\ ``b``\ *番号* という形式に従った、パッケージのバージョン番号に対するサフィックスを追加することで引き起こされます。例えば、再コンパイル対象の最新バージョンが ``2.9-3`` の場合、バイナリのみの NMU は ``2.9-3+b1`` というバージョンになる必要があります。最新のバージョンが ``3.4+b1`` (つまり、ネイティブパッケージで、前回が再コンパイルの NMU) の場合、バイナリのみの NMU は ``3.4+b2`` というバージョン番号にならねばいけません。 [2]_

en: Similar to initial porter uploads, the correct way of invoking ``dpkg-buildpackage`` is ``dpkg-buildpackage -B`` to only build the architecture-dependent parts of the package.
ja: 最初の移植作業者のアップロード (porter upload) と同様に、パッケージのアーキテクチャ依存部分をビルドするための ``dpkg-buildpackage`` の正しい実行の仕方は ``dpkg-buildpackage -B`` です。

en: When to do a source NMU if you are a porter
ja: あなたが移植作業者の場合、source NMU を行う時は何時か

en: Porters doing a source NMU generally follow the guidelines found in :ref:`nmu`, just like non-porters. However, it is expected that the wait cycle for a porter's source NMU is smaller than for a non-porter, since porters have to cope with a large quantity of packages. Again, the situation varies depending on the distribution they are uploading to. It also varies whether the architecture is a candidate for inclusion into the next stable release; the release managers decide and announce which architectures are candidates.
ja: 移植作業者は、通常は非移植作業者同様に :ref:`nmu` にあるガイドラインに沿ってソース NMU を行います。しかし、移植作業者のソース NMU に対する待ち時間は非移植作業者より小さくなります。これは、移植作業は大量のパッケージに対応する必要があるからです。さらに、状況はパッケージがアップロードされるディストリビューションに依って変わります。これは、アーキテクチャが次の安定版リリースに含められるかどうかによっても変わります。リリースマネージャはどのアーキテクチャが候補なのかを決定してアナウンスします。

en: If you are a porter doing an NMU for ``unstable``, the above guidelines for porting should be followed, with two variations. Firstly, the acceptable waiting period — the time between when the bug is submitted to the BTS and when it is OK to do an NMU — is seven days for porters working on the ``unstable`` distribution. This period can be shortened if the problem is critical and imposes hardship on the porting effort, at the discretion of the porter group. (Remember, none of this is Policy, just mutually agreed upon guidelines.) For uploads to ``stable`` or ``testing``, please coordinate with the appropriate release team first.
ja: あなたが不安定版 (``unstable``) へ NMU を行う移植作業者の場合、移植作業についての上記のガイドライン、そして 2 つの相違点に従う必要があります。まず、適切な待ち時間です — バグが BTS へ投稿されてから NMU を行って OK になるまでの間 — 移植作業者が 不安定版 (``unstable``) ディストリビューションに対して行う場合は 7 日間になります。問題が致命的で移植作業に困難を強いるような場合には、この期間は短くできます (注意してください。この何れもがポリシーではなく、単にガイドラインに沿って相互に了解されているだけです)。``安定版 (stable)`` や テスト版 (``testing``) へのアップロードについては、まず適切なリリースチームと調整をしてください。

en: Secondly, porters doing source NMUs should make sure that the bug they submit to the BTS should be of severity ``serious`` or greater. This ensures that a single source package can be used to compile every supported Debian architecture by release time. It is very important that we have one version of the binary and source package for all architectures in order to comply with many licenses.
ja: 次に、ソース NMU を行う移植作業者は BTS へ登録したバグの重要度が ``serious`` かそれ以上であることを確認してください。これは単一のソースパッケージが、すべての Debian でサポートされているアーキテクチャでコンパイルされたことをリリース時に保証します。数多くのライセンスに従うため、すべてのアーキテクチャについて、単一のバージョンのバイナリパッケージとソースパッケージを持つことがとても重要です。

en: Porters should try to avoid patches which simply kludge around bugs in the current version of the compile environment, kernel, or libc. Sometimes such kludges can't be helped. If you have to kludge around compiler bugs and the like, make sure you ``#ifdef`` your work properly; also, document your kludge so that people know to remove it once the external problems have been fixed.
ja: 移植作業者は、現在のバージョンのコンパイル環境やカーネル、libc にあるバグのために作られた単なる力業のパッチを極力回避すべきです。この様なでっち上げの代物があるのは、仕方がないことが時折あります。コンパイラのバグやその他の為にでっち上げを行う必要がある場合には、\ ``#ifdef`` で作業したものが動作することを確認してください。また、力業についてドキュメントに載せてください。一旦外部の問題が修正されたら、それを削除するのを皆が知ることができます。

en: Porters may also have an unofficial location where they can put the results of their work during the waiting period. This helps others running the port have the benefit of the porter's work, even during the waiting period. Of course, such locations have no official blessing or status, so buyer beware.
ja: 移植作業者は、待ち期間の間、作業結果を置いておける非公式の置き場所を持つこともあります。移植版を動作させている人が、待ち期間の間であっても、これによって移植作業者による作業の恩恵を受けられるようになります。もちろん、この様な場所は、公式な恩恵や状況の確認を受けることはできませんので、利用者は注意してください。

en: Porting infrastructure and automation
ja: 移植用のインフラと自動化

en: There is infrastructure and several tools to help automate package porting. This section contains a brief overview of this automation and porting to these tools; see the package documentation or references for full information.
ja: パッケージの自動移植に役立つインフラストラクチャと複数のツールがあります。この章には、この自動化とこれらのツールへの移植の概要が含まれています。全体の情報に付いてはパッケージのドキュメントかリファレンスを参照してください。

en: Mailing lists and web pages
ja: メーリングリストとウェブページ

en: Web pages containing the status of each port can be found at https://www.debian.org/ports/\ .
ja: 各移植版についての状況を含んだウェブページは https://www.debian.org/ports/\  から参照できます。

en: Each port of Debian has a mailing list. The list of porting mailing lists can be found at https://lists.debian.org/ports.html\ . These lists are used to coordinate porters, and to connect the users of a given port with the porters.
ja: Debian の各移植版はメーリングリストを持っています。移植作業のメーリングリストは https://lists.debian.org/ports.html\ で見ることができます。これらのリストは移植作業者の作業の調整や移植版のユーザと移植作業者をつなぐために使われています。

en: Porter tools
ja: 移植用ツール

en: Descriptions of several porting tools can be found in :ref:`tools-porting`.
ja: 移植用のツールの説明をいくつか :ref:`tools-porting` で見ることができます。

en: We are quite proud of this system, since it has so many possible uses. Independent development groups can use the system for different sub-flavors of Debian, which may or may not really be of general interest (for instance, a flavor of Debian built with ``gcc`` bounds checking). It will also enable Debian to recompile entire distributions quickly.
ja: 我々はこのシステムを極めて誇りに思っています。何故ならば、様々な利用方法の可能性があるからです。独立した開発グループは、実際に一般的な用途に合うかどうか分からない異なった別アプローチの Debian にシステムを使うことができます (例えば、``gcc`` の配列境界チェック付きでビルドした Debian など)。そして、Debian がディストリビューション全体を素早く再コンパイルできるようにもなります。

en: The wanna-build team, in charge of the buildds, can be reached at ``debian-wb-team@lists.debian.org``. To determine who (wanna-build team, release team) and how (mail, BTS) to contact, refer to https://lists.debian.org/debian-project/2009/03/msg00096.html\ .
ja: buildd の担当である wanna-build チームには、\ ``debian-wb-team@lists.debian.org`` で連絡が取れます。誰 (wanna-build チーム、リリースチーム) に連絡を取るのか、どうやって (メール、BTS) 連絡するのかを決めるには、\ https://lists.debian.org/debian-project/2009/03/msg00096.html\ を参照してください。

en: When requesting binNMUs or give-backs (retries after a failed build), please use the format described at https://release.debian.org/wanna-build.txt\ .
ja: binNMU や give-back (ビルド失敗後のやり直し) を依頼する時には、\ https://release.debian.org/wanna-build.txt\ で記述されている形式を使ってください。

en: When your package is *not* portable
ja: あなたのパッケージが移植可能なものでは\ *ない*\ 場合

en: Some packages still have issues with building and/or working on some of the architectures supported by Debian, and cannot be ported at all, or not within a reasonable amount of time. An example is a package that is SVGA-specific (only available for ``i386`` and ``amd64``), or uses other hardware-specific features not supported on all architectures.
ja: いくつかのパッケージでは、Debian でサポートされているアーキテクチャのうちの幾つかで、構築や動作に問題を抱えており、全く移植できない、あるいは十分な時間内では移植ができないものがあります。例としては、SVGA に特化したパッケージ (``i386`` と ``amd64`` のみで利用可能)や、すべてのアーキテクチャではサポートされていないようなハードウェア固有の機能があります。

en: In order to prevent broken packages from being uploaded to the archive, and wasting buildd time, you need to do a few things:
ja: 壊れたパッケージがアーカイブにアップロードされたり buildd の時間が無駄に費やされたりするのを防ぐため、幾つかしなければならないことがあります:

en: First, make sure your package *does* fail to build on architectures that it cannot support. There are a few ways to achieve this. The preferred way is to have a small testsuite during build time that will test the functionality, and fail if it doesn't work. This is a good idea anyway, as this will prevent (some) broken uploads on all architectures, and also will allow the package to build as soon as the required functionality is available.
ja: まず、サポートできないアーキテクチャ上ではパッケージがビルドに\ *失敗する*\ のを確認しておく必要があります。これを行うには幾つかやり方があります。お勧めの方法は構築時に機能をテストする小さなテストスイートを用意して、動かない場合に失敗するようにすることです。これは、全てのアーキテクチャ上で、壊れたものをアップロードするのを防ぎ、必要な機能が動作するようになればパッケージがビルドできるようになる、良い考えです。

en: Additionally, if you believe the list of supported architectures is pretty constant, you should change ``any`` to a list of supported architectures in ``debian/control``. This way, the build will fail also, and indicate this to a human reader without actually trying.
ja: さらに、サポートしているアーキテクチャ一覧が一定量であると信ずるのであれば、\ ``debian/control`` 内で ``any`` からサポートしているアーキテクチャの一覧に変更するべきです。この方法であれば、ビルドが同様に失敗するようになるのに加え、実際に試すことなく人間である読み手にサポートしているアーキテクチャが分かるようにできます。

en: In order to prevent autobuilders from needlessly trying to build your package, it must be included in ``Packages-arch-specific``, a list used by the ``wanna-build`` script. The current version is available as https://wiki.debian.org/PackagesArchSpecific\ ; please see the top of the file for whom to contact for changes.
ja: autobuilder が必要もなくパッケージをビルドしようとしないように、\ ``wanna-build`` スクリプトが使うリストである ``Packages-arch-specific`` に追加しておく必要があります。現在のバージョンは https://wiki.debian.org/PackagesArchSpecific\  から入手できます: 変更依頼をする相手はファイルの一番上を参照してください。

en: Marking non-free packages as auto-buildable
ja: non-free のパッケージを auto-build 可能であるとマークする

en: Check whether it is legally allowed and technically possible to auto-build the package;
ja: 法的に許可されているか、技術的にパッケージが auto-build 可能かどうかを確認する;

en: Add ``XS-Autobuild: yes`` into the header part of ``debian/control``;
ja: ``debian/control`` のヘッダ部分に ``XS-Autobuild: yes`` を追加する;

en: Send an email to ``non-free@buildd.debian.org`` and explain why the package can legitimately and technically be auto-built.
ja: メールを ``non-free@buildd.debian.org`` に送り、何故パッケージが合法的、かつ技術的に auto-build できるものなのかを説明する

en: Non-Maintainer Uploads (NMUs)
ja: Non-Maintainer Upload (NMU)

en: Every package has one or more maintainers. Normally, these are the people who work on and upload new versions of the package. In some situations, it is useful that other developers can upload a new version as well, for example if they want to fix a bug in a package they don't maintain, when the maintainer needs help to respond to issues. Such uploads are called *Non-Maintainer Uploads (NMU)*.
ja: すべてのパッケージには最低一人のメンテナがいます。通常、この人達がパッケージに対して作業をし、新しいバージョンをアップロードします。時折、他の開発者らが新しいバージョンをアップロードできると便利な場合があります。例えば、彼らがメンテナンスしていないパッケージにあるバグを修正したいが、メンテナが問題に対応するのには助けが必要な場合です。このようなアップロードは *Non-Maintainer Upload (NMU)* と呼ばれます。

en: When and how to do an NMU
ja: いつ、どうやって NMU を行うか

en: Before doing an NMU, consider the following questions:
ja: NMU を行う前に、以下の質問について考えてください:

en: Did you give enough time to the maintainer? When was the bug reported to the BTS? Being busy for a week or two isn't unusual. Is the bug so severe that it needs to be fixed right now, or can it wait a few more days?
ja: メンテナに十分な時間を与えましたか? BTS にバグが報告されたのは何時ですか? 一、二週間忙しいことはあり得ないことでは無いです。そのバグはすぐに修正しなければならないほど重大ですか? それとも、あと数日待てるものですか?

en: How confident are you about your changes? Please remember the Hippocratic Oath: "Above all, do no harm." It is better to leave a package with an open grave bug than applying a non-functional patch, or one that hides the bug instead of resolving it. If you are not 100% sure of what you did, it might be a good idea to seek advice from others. Remember that if you break something in your NMU, many people will be very unhappy about it.
ja: その変更にどれくらい自信がありますか? ヒポクラテスの誓いを思い出してください: 「何よりも、害を及ぼすことなかれ」 動かないパッチを当てるよりもパッケージの重大なバグをそのままオープンな状態にしておく方が良いですし、パッチによってバグを解決するのではなく隠してしまうかもしれません。自分が 100% 何をしたのか分かっていないのであれば、他の人からアドバイスをもらうのも良い考えでしょう。NMU で何かを壊したのであれば、多くの人がとても不幸になるであろうことを覚えておいてください。

en: Have you clearly expressed your intention to NMU, at least in the BTS? If that didn't generate any feedback, it might also be a good idea to try to contact the maintainer by other means (email to the maintainer addresses or private email, IRC).
ja: 少なくとも BTS で、NMU するのを明確に表明しましたか? 何も反応が得られなかった場合、他の手段 (プライベートなメール、IRC) でメンテナに連絡をとるのも良い考えです。

en: If the maintainer is usually active and responsive, have you tried to contact them? In general it should be considered preferable that maintainers take care of an issue themselves and that they are given the chance to review and correct your patch, because they can be expected to be more aware of potential issues which an NMUer might miss. It is often a better use of everyone's time if the maintainer is given an opportunity to upload a fix on their own.
ja: メンテナがいつも活動的で応答してくれる場合、彼に連絡を取ろうとしましたか? 大概の場合、メンテナ自身が問題に対応して、あなたのパッチをレビューする機会が与えられる方が好ましいと思われます。これは、NMU をする人が見落としているだろう潜在的な問題にメンテナは気付くことができるからです。大抵、メンテナが自分でアップロードする機会が与えられる方が、皆の時間を使うよりも良いやり方です。

en: When doing an NMU, you must first make sure that your intention to NMU is clear. Then, you must send a patch with the differences between the current package and your proposed NMU to the BTS. The ``nmudiff`` script in the ``devscripts`` package might be helpful.
ja: NMU をする際には、まず NMU をする意図を明確にしておかねばなりません。それから、BTS へ現在のパッケージと提案する NMU との差分をパッチとして送付する必要があります。\ ``devscripts`` パッケージにある ``nmudiff`` スクリプトが役に立つでしょう。

en: Unless you have an excellent reason not to do so, you must then give some time to the maintainer to react (for example, by uploading to the ``DELAYED`` queue). Here are some recommended values to use for delays:
ja: そうするべき十二分な理由が無い限り、メンテナに対応する時間を与えるべきです (例えば ``DELAYED`` キューにアップロードすることによってこれを行います)。以下が delayed キューを使う際のお勧めの値です:

en: Upload fixing only release-critical bugs older than 7 days, with no maintainer activity on the bug for 7 days and no indication that a fix is in progress: 0 days
ja: 7 日以上経っているリリースクリティカルバグのみを修正するアップロードで、バグに対するメンテナの活動が 7 日間見られなく、修正が行われている形跡が無い: 0 日

en: Upload fixing only release-critical bugs older than 7 days: 2 days
ja: 7 日以上経っているリリースクリティカルバグのみを修正するアップロード: 2 日

en: Upload fixing only release-critical and important bugs: 5 days
ja: リリースクリティカルバグや重要なバグの修正のみのアップロード: 5 日

en: Those delays are only examples. In some cases, such as uploads fixing security issues, or fixes for trivial bugs that block a transition, it is desirable that the fixed package reaches ``unstable`` sooner.
ja: この値は例に過ぎません。セキュリティ問題を修正するアップロードや、移行を阻む些細なバグを修正するなど、いくつかのケースでは修正されたパッケージが 不安定版 (``unstable``) にすぐ入るようになるのは望ましいことです。

en: Sometimes, release managers decide to encourage NMUs with shorter delays for a subset of bugs (e.g release-critical bugs older than 7 days). Also, some maintainers list themselves in the `Low Threshold NMU list <https://wiki.debian.org/LowThresholdNmu>`__, and accept that NMUs are uploaded without delay. But even in those cases, it's still a good idea to give the maintainer a few days to react before you upload, especially if the patch wasn't available in the BTS before, or if you know that the maintainer is generally active.
ja: 時々、リリースマネージャが特定のバグに対して短い delay 日数の NMU を許可を認めることがあります (7 日より古いリリースクリティカルバグなど)。また、一部のメンテナは `Low Threshold NMU list <https://wiki.debian.org/LowThresholdNmu>`__ に自身を挙げており、遅延なしの NMU アップロードを許可しています。しかしそのような場合であっても、特にパッチが BTS で以前手に入らなかったり、メンテナが大抵アクティブであるのを知っている場合など、アップロードの前にメンテナに対して数日与えるのは良い考えです。

en: This is not a license to perform NMUs thoughtlessly. If you NMU when it is clear that the maintainers are active and would have acknowledged a patch in a timely manner, or if you ignore the recommendations of this document, your upload might be a cause of conflict with the maintainer. You should always be prepared to defend the wisdom of any NMU you perform on its own merits.
ja: これは、軽率な NMU を行うための許可証ではありません。明らかにメンテナがアクティブで時期を逃さずパッチについて対応している場合や、このドキュメントに書かれている推奨を無視している場合など、あなたによるアップロードはメンテナと衝突を起こすでしょう。NMU のメリットについて、自分が行ったことの賢明さを常に弁護できるようにしておく必要があります。

en: NMUs and ``debian/changelog``
ja: NMU と ``debian/changelog``

en: The way to version NMUs differs for native and non-native packages.
ja: NMU のバージョンのつけ方は、ネイティブなパッケージとネイティブではないパッケージでは異なります。

en: If the package is a native package (without a Debian revision in the version number), the version must be the version of the last maintainer upload, plus ``+nmu``\ *X*, where *X* is a counter starting at ``1``. If the last upload was also an NMU, the counter should be increased. For example, if the current version is ``1.5``, then an NMU would get version ``1.5+nmu1``.
ja: パッケージがネイティブパッケージの場合 (バージョン番号に Debian リビジョンが付かない)、バージョンはメンテナの最後のアップロードのバージョン + ``+nmu``\ *X* となり、\ *X* は ``1`` から始まる数字になります。最後のアップロードが同様に NMU の場合は、数字を増やします。例えば、現在のバージョンが ``1.5`` だとすると、NMU はバージョンが ``1.5+nmu1`` になります。

en: If the package is not a native package, you should add a minor version number to the Debian revision part of the version number (the portion after the last hyphen). This extra number must start at ``1``. For example, if the current version is ``1.5-2``, then an NMU would get version ``1.5-2.1``. If a new upstream version is packaged in the NMU, the Debian revision is set to ``0``, for example ``1.6-0.1``.
ja: パッケージがネイティブパッケージではない場合は、バージョン番号の Debian リビジョン部分 (最後のハイフン以下の部分) にマイナーバージョン番号を追加します。例えば、現在のバージョンが ``1.5-2`` であれば、NMU は ``1.5-2.1`` というバージョンになります。開発元のバージョンが新しくなったものが NMU でパッケージになった場合は、Debian リビジョンは ``0`` に設定されます。例えば ``1.6-0.1`` です。

en: In both cases, if the last upload was also an NMU, the counter should be increased. For example, if the current version is ``1.5+nmu3`` (a native package which has already been NMUed), the NMU would get version ``1.5+nmu4``.
ja: どちらの場合でも、最後のアップロードも NMU だった場合には数字が増えます。例えば、現在のバージョンが ``1.5+nmu3`` (既に NMU されたネイティブパッケージ) の場合、NMU は ``1.5+nmu4`` というバージョンになります。

en: A special versioning scheme is needed to avoid disrupting the maintainer's work, since using an integer for the Debian revision will potentially conflict with a maintainer upload already in preparation at the time of an NMU, or even one sitting in the ftp NEW queue. It also has the benefit of making it visually clear that a package in the archive was not made by the official maintainer.
ja: 特別なバージョン付け方法が必要とされるのは、メンテナの作業を混乱させるのを避けるためです。何故ならば、Debian リビジョンのために整数を使っていると、NMU の際に既に準備されていたメンテナによるアップロードや、さらには ftp NEW queue にあるパッケージともぶつかる可能性があります。これには、アーカイブのパッケージが公式メンテナによるものではない、と視覚的に明らかにする利点もあります。

en: If you upload a package to testing or stable, you sometimes need to "fork" the version number tree. This is the case for security uploads, for example. For this, a version of the form ``+deb``\ *X*\ ``u``\ *Y* should be used, where *X* is the major release number, and *Y* is a counter starting at ``1``. For example, while |codename-stable| (Debian |version-stable|) is stable, a security NMU to stable for a package at version ``1.5-3`` would have version |version2-revision-deb-version-stable-u1|, whereas a security upload to |codename-testing| would get version |version2-revision-deb-version-testing-u1|.
ja: パッケージをテスト版や安定版にアップロードする場合、バージョン番号を「分岐」する必要が時々あります。これは例えばセキュリティアップロードが該当します。そのため、\ ``+deb``\ *X*\ ``u``\ *Y* 形式のバージョン番号を使うようにしてください。\ *X* はメジャーリリース番号で *Y* は ``1`` から始まるカウンターです。例えば、|codename-stable| (Debian |version-stable|) が安定版の間は安定版バージョン ``1.5-3`` のパッケージへのセキュリティ NMU ならバージョン |version2-revision-deb-version-stable-u1| となりますが、|codename-testing| へのセキュリティ NMU ではバージョン |version2-revision-deb-version-testing-u1| となります。

en: Using the ``DELAYED/`` queue
ja: ``DELAYED/`` キューを使う

en: Having to wait for a response after you request permission to NMU is inefficient, because it costs the NMUer a context switch to come back to the issue. The ``DELAYED`` queue (see :ref:`delayed-incoming`) allows the developer doing the NMU to perform all the necessary tasks at the same time. For instance, instead of telling the maintainer that you will upload the updated package in 7 days, you should upload the package to ``DELAYED/7`` and tell the maintainer that they have 7 days to react. During this time, the maintainer can ask you to delay the upload some more, or cancel your upload.
ja: NMU の許可を求めた後で待っているのは効率的ではありません。NMU した人が作業にもどるために頭を切り替えるのに手間がかかるからです。\ ``DELAYED`` キュー (:ref:`delayed-incoming` 参照) は、開発者が NMU をするのに必要な作業を同時にできるようになります。例えば、メンテナに対して更新したパッケージを 7 日後にアップロードするのを伝えるのではなく、パッケージを ``DELAYED/7`` にアップロードしてメンテナに対して対応するのに 7 日間あることを伝えるべきです。この間、メンテナはもっとアップロードを遅らせるかアップロードをキャンセルするかを尋ねることができます。

en: The ``DELAYED`` queue should not be used to put additional pressure on the maintainer. In particular, it's important that you are available to cancel or delay the upload before the delay expires since the maintainer cannot cancel the upload themselves.
ja: ``DELAYED`` キューは、無用のプレッシャーをメンテナに与えるために使われるべきではありません。特に、メンテナはアップロードを自身ではキャンセルできないので、delay が完了する前にアップロードをキャンセルあるいは遅らせることができるのはあなただ、という点が重要です。

en: If you make an NMU to ``DELAYED`` and the maintainer updates the package before the delay expires, your upload will be rejected because a newer version is already available in the archive. Ideally, the maintainer will take care to include your proposed changes (or at least a solution for the problems they address) in that upload.
ja: ``DELAYED`` を使った NMU を行って delay が完了する前にメンテナがパッケージを更新した場合には、アーカイブに既により新しいバージョンがあるので、あなたのアップロードは拒否されます。理想的なのは、メンテナがそのアップロードであなたが提案した変更 (あるいは少なくとも対応した問題の解決方法) を含めるのを取り仕切ることです。

en: NMUs from the maintainer's point of view
ja: メンテナの視点から見た NMU

en: When someone NMUs your package, this means they want to help you to keep it in good shape. This gives users fixed packages faster. You can consider asking the NMUer to become a co-maintainer of the package. Receiving an NMU on a package is not a bad thing; it just means that the package is interesting enough for other people to work on it.
ja: 誰かがあなたのパッケージを NMU した場合、これは彼らがパッケージを良い形に保つのを助けたいと思っているということです。これによって、ユーザへ修正したパッケージをより早く届けます。NMU した人に、パッケージの副メンテナになることを尋ねるのを考えてみるのも良いでしょう。パッケージに対して NMU を受け取るのは悪いことではありません。それは、単にそのパッケージが他の人が作業する価値があるという意味です。

en: To acknowledge an NMU, include its changes and changelog entry in your next maintainer upload. If you do not acknowledge the NMU by including the NMU changelog entry in your changelog, the bugs will remain closed in the BTS but will be listed as affecting your maintainer version of the package.
ja: NMU を承認するには、変更と changelog のエントリを次のメンテナアップロードに含めます。バグは BTS で close されたままになりますが、パッケージのメンテナバージョンに影響していると表示されます。

en: Source NMUs vs Binary-only NMUs (binNMUs)
ja: ソース NMU vs バイナリのみの NMU (binNMU)

en: The full name of an NMU is *source NMU*. There is also another type, namely the *binary-only NMU*, or *binNMU*. A binNMU is also a package upload by someone other than the package's maintainer. However, it is a binary-only upload.
ja: NMU のフルネームは\ *ソース NMU* です。もう一つ別の種類があって、\ *バイナリのみの NMU (binary-only NMU)* あるいは *binNMU* と名付けられています。binNMU も、パッケージメンテナ以外の誰かによるパッケージのアップロードです。しかし、これはバイナリのみのアップロードです。

en: When a library (or other dependency) is updated, the packages using it may need to be rebuilt. Since no changes to the source are needed, the same source package is used.
ja: ライブラリ (や他の依存関係) が更新された時、それを使っているパッケージを再ビルドする必要があるかもしれません。ソースへの変更は必要ないので、同じソースパッケージが利用されます。

en: BinNMUs are usually triggered on the buildds by wanna-build. An entry is added to ``debian/changelog``, explaining why the upload was needed and increasing the version number as described in :ref:`binary-only-nmu`. This entry should not be included in the next upload.
ja: binNMU は、通常 wanna-build によって buildd 上で引き起こされます。\ ``debian/changelog`` にエントリが追加され、なぜアップロードが必要だったのか、という説明と :ref:`binary-only-nmu` で記述されているようにバージョン番号を増やします。このエントリは、その次のアップロードに含めるべきではありません。

en: Buildds upload packages for their architecture to the archive as binary-only uploads. Strictly speaking, these are binNMUs. However, they are not normally called NMU, and they don't add an entry to ``debian/changelog``.
ja: buildd は、アーカイブするために、バイナリのみのアップロードとして、そのアーキテクチャに対してパッケージをアップロードします。厳密に言えば、これは binNMU です。しかし、これは通常 NMU とは呼ばれず、\ ``debian/changelog`` にエントリを追加しません。

en: NMUs vs QA uploads
ja: NMU と QA アップロード

en: QA uploads are very much like normal maintainer uploads: they may fix anything, even minor issues; the version numbering is normal, and there is no need to use a delayed upload. The difference is that you are not listed as the ``Maintainer`` or ``Uploader`` for the package. Also, the changelog entry of a QA upload has a special first line:
ja: QA アップロードは、ほとんど通常のメンテナによるアップロードと同じです: 些細な問題であっても、なんでも修正します。バージョン番号の付け方は通常のものですし、delay アップロードをする必要もありません。違いは、パッケージのメンテナあるいはアップローダとして記載されていない点です。また、QA アップロードの changelog のエントリは以下のように最初の一行が特別になっています:

en: If you want to do an NMU, and it seems that the maintainer is not active, it is wise to check if the package is orphaned (this information is displayed on the package's Package Tracking System page). When doing the first QA upload to an orphaned package, the maintainer should be set to ``Debian QA Group <packages@qa.debian.org>``. Orphaned packages which did not yet have a QA upload still have their old maintainer set. There is a list of them at https://qa.debian.org/orphaned.html\ .
ja: あなたが NMU をしたいと思い、かつ、メンテナが活動的ではない場合、パッケージが放棄されてないかどうかを確認するのが賢明です (この情報はパッケージ追跡システム (PTS) のページで表示されています)。放棄されたパッケージに対して最初の QA アップロードを行うときは、メンテナは ``Debian QA Group <packages@qa.debian.org>`` に設定する必要があります。まだ QA アップロードがされていない放棄されたパッケージには、以前のメンテナが設定されています。この一覧は https://qa.debian.org/orphaned.html\  で手に入ります。

en: NMUs vs team uploads
ja: NMU とチームアップロード

en: Collaborative maintenance
ja: 共同メンテナンス

en: Collaborative maintenance is a term describing the sharing of Debian package maintenance duties by several people. This collaboration is almost always a good idea, since it generally results in higher quality and faster bug fix turnaround times. It is strongly recommended that packages with a priority of ``standard`` or which are part of the base set have co-maintainers.
ja: 共同メンテナンス (collaborative maintenance) は、Debian パッケージのメンテナンス責任を数人でシェアすることを指す用語です。この共同作業は、通常はより上質で短いバグ修正時間をもたらすので、大抵の場合は常に良い考えです。優先度が標準 (``standard``) あるいは基本セット (base) の一部であるパッケージは、共同メンテナ (co-maintainer) を持つことを強くお勧めします。

en: Generally there is a primary maintainer and one or more co-maintainers. The primary maintainer is the person whose name is listed in the ``Maintainer`` field of the ``debian/control`` file. Co-maintainers are all the other maintainers, usually listed in the ``Uploaders`` field of the ``debian/control`` file.
ja: 大抵の場合、主メンテナに加えて一人か二人の共同メンテナが居ます。主メンテナは ``debian/control`` ファイルの ``Maintainer`` 欄に名前が記載されている人です。共同メンテナは他のすべてのメンテナで、通常 ``debian/control`` ファイルの ``Uploaders`` に記載されています。

en: In its most basic form, the process of adding a new co-maintainer is quite easy:
ja: もっとも基本的なやり方では、新しい副メンテナの追加は大変簡単です:

en: Add the co-maintainer's correct maintainer name and address to the ``Uploaders`` field in the first paragraph of the ``debian/control`` file.
ja: 共同メンテナの正確なメンテナ名とアドレスを ``debian/control`` ファイルの最初の段落の ``Uploaders`` 欄に追加します。

en: Another form of collaborative maintenance is team maintenance, which is recommended if you maintain several packages with the same group of developers. In that case, the ``Maintainer`` and ``Uploaders`` field of each package must be managed with care. It is recommended to choose between one of the two following schemes:
ja: 共同メンテナンスのもう一つの形態はチームメンテナンスです。これは、複数のパッケージを同じ開発者グループでメンテナンスする場合にお勧めです。その場合、各パッケージの ``Maintainer`` 欄と ``Uploaders`` 欄は注意して扱わねばいけません。以下の二つの案からいずれかを選ぶのがお勧めです:

en: Put the team member mainly responsible for the package in the ``Maintainer`` field. In the ``Uploaders``, put the mailing list address, and the team members who care for the package.
ja: パッケージの主に担当をするチームメンバーを ``Maintainer`` 欄に追加します。\ ``Uploaders`` 欄には、メーリングリストのアドレスとパッケージの面倒をみるチームメンバーを追加します。

en: In any case, it is a bad idea to automatically put all team members in the ``Uploaders`` field. It clutters the Developer's Package Overview listing (see :ref:`ddpo`) with packages one doesn't really care for, and creates a false sense of good maintenance. For the same reason, team members do not need to add themselves to the ``Uploaders`` field just because they are uploading the package once, they can do a “Team upload” (see :ref:`nmu-team-upload`). Conversely, it is a bad idea to keep a package with only the mailing list address as a ``Maintainer`` and no ``Uploaders``.
ja: どのような場合でも、すべてのチームメンバーを ``Uploaders`` 欄に入れるのは良くない考えです。これは、Developer's Package Overview の一覧 (:ref:`ddpo` 参照) を実際には対応していないパッケージで散らかしてしまい、偽りの良いメンテナンス状態を作り出します。同じ理由から、パッケージを一回アップロードするのであれば、「チームアップロード (Team Upload)」ができるので、チームメンバーは ``Uploaders`` 欄へ自分を追加する必要はありません (:ref:`nmu-team-upload` 参照)。逆にいえば、\ ``Maintainer`` 欄にメーリングリストのアドレスのみで ``Uploaders`` 欄に誰も追加していないままにしておくのは良くない考えです。

en: The testing distribution
ja: テスト版ディストリビューション

en: Basics
ja: 基本

en: Packages are usually installed into the ``testing`` distribution after they have undergone some degree of testing in ``unstable``.
ja: パッケージは通常、不安定版 (``unstable``) におけるテスト版への移行基準を満たした後でテスト版 (``testing``) ディストリビューションへとインストールされます。

en: They must be in sync on all architectures and mustn't have dependencies that make them uninstallable; they also have to have generally no known release-critical bugs at the time they're installed into ``testing``. This way, ``testing`` should always be close to being a release candidate. Please see below for details.
ja: これらは、すべてのアーキテクチャ上で同期していなければならず、インストールできなくなるような依存関係を持ってはいけません。また、\ ``テスト版 (testing)`` にインストールされる際に既知のリリースクリティカルバグを持っていない必要があります。このようにして、\ ``テスト版 (testing)`` は常にリリース候補に近いものである必要があります。詳細は以下を参照してください。

en: Updates from unstable
ja: 不安定版からの更新

en: The scripts that update the ``testing`` distribution are run twice each day, right after the installation of the updated packages; these scripts are called ``britney``. They generate the ``Packages`` files for the ``testing`` distribution, but they do so in an intelligent manner; they try to avoid any inconsistency and to use only non-buggy packages.
ja: テスト版 (``testing``) ディストリビューションを更新するスクリプトは、日に二回、更新されたパッケージのインストール直後に動作します。これらのスクリプトは ``britney`` と呼ばれます。これは、テスト版 (``testing``) ディストリビューションに対して ``Packages`` ファイルを生成しますが、不整合を避けてバグが無いパッケージのみを利用しようとする気の利いたやり方で行います。

en: The inclusion of a package from ``unstable`` is conditional on the following:
ja: 不安定版 (``unstable``) からのパッケージの取り込みは以下の条件です:

en: It must not have new release-critical bugs (RC bugs affecting the version available in ``unstable``, but not affecting the version in ``testing``);
ja: 新たなリリースクリティカルバグを持っていないこと (不安定版 (``unstable``)で利用可能なバージョンに影響する RC バグであって、テスト版 (``testing``) にあるバージョンに影響するものではない);

en: It must be available on all architectures on which it has previously been built in ``unstable``. :ref:`dak-ls` may be of interest to check that information;
ja: あらかじめ ``unstable`` でビルドされた際に、全アーキテクチャで利用可能になっていなくてはいけません。この情報をチェックするのに :ref:`dak-ls` に興味を持つかもしれません;

en: It must not break any dependency of a package which is already available in ``testing``;
ja: 既にテスト版 (``testing``) で利用可能になっているパッケージの依存関係を壊さないこと;

en: The packages on which it depends must either be available in ``testing`` or they must be accepted into ``testing`` at the same time (and they will be if they fulfill all the necessary criteria);
ja: パッケージが依存するものは、テスト版 (``testing``) で利用可能なものか、\ ``テスト版 (testing)`` に同時に受け入れられるものでなくてはいけない (そして、それらは必要な条件をすべて満たしていれば、テスト版 (``testing``)) に入る);

en: The phase of the project. I.e. automatic transitions are turned off during the *freeze* of the ``testing`` distribution.
ja: プロジェクトの状況。つまり、テスト版 (``testing``) ディストリビューションの\ *フリーズ*\ 中は、自動的な移行がオフになります。

en: To find out whether a package is progressing into ``testing`` or not, see the ``testing`` script output on the `web page of the testing distribution <https://www.debian.org/devel/testing>`__, or use the program ``grep-excuses`` which is in the ``devscripts`` package. This utility can easily be used in a crontab 5 to keep yourself informed of the progression of your packages into ``testing``.
ja: パッケージがテスト版 (``testing``) に入る処理がされるかどうかは、\ `テスト版ディストリビューションのウェブページ <https://www.debian.org/devel/testing>`__\ の\ ``テスト版 (testing)`` スクリプトの出力を参照するか、\ ``devscripts`` パッケージ中の ``grep-excuses`` プログラムを使ってください。このユーティリティは、パッケージが\ ``テスト版 (testing)`` への進行の通知をし続けるのに、crontab 5 で手軽に使うことができます。

en: The ``update_excuses`` file does not always give the precise reason why the package is refused; you may have to find it on your own by looking for what would break with the inclusion of the package. The `testing web page <https://www.debian.org/devel/testing>`__ gives some more information about the usual problems which may be causing such troubles.
ja: ``update_excuses`` は、なぜパッケージが拒否されたのか正確な理由を必ずしも表示しません。自分自身で何がパッケージが含まれるのを妨げているのか、探す必要があるかもしれません。\ `テスト版のウェブページ <https://www.debian.org/devel/testing>`__\ が、そのような問題を引き起こす良くある問題についての情報を与えてくれるでしょう。

en: Sometimes, some packages never enter ``testing`` because the set of interrelationship is too complicated and cannot be sorted out by the scripts. See below for details.
ja: 時折、相互依存関係の組み合わせが非常に難解なのでスクリプトが解決できないことがあるため、パッケージが\ ``テスト版 (testing)`` に決して入らないことがあります。詳細は下記を参照してください。

en: Out-of-date
ja: 時代遅れ (Out-of-date)

en: Consider this example:
ja: 以下の例を考えてみましょう:

en: testing
ja: テスト版

en: unstable
ja: 不安定版

en: However, if ftp-master removes a package in ``unstable`` (here on ``arm``):
ja: ですが、もしも ftp-master が不安定版 (``unstable``) のパッケージ (ここでは ``arm`` の) を削除した場合:

en: In this case, the package is up to date on all release architectures in ``unstable`` (and the extra ``hurd-i386`` doesn't matter, as it's not a release architecture).
ja: この場合、パッケージは不安定版 (``unstable``) ですべてのリリースアーキテクチャで最新になります (それから、もう一つの ``hurd-i386`` は、リリースアーキテクチャではないので問題になりません)。

en: Sometimes, the question is raised if it is possible to allow packages in that are not yet built on all architectures: No. Just plainly no. (Except if you maintain glibc or so.)
ja: 時折、すべてのアーキテクチャでまだビルドされていていないパッケージを入れられるか、という質問がでてきます: いいえ。 単純にいいえ、です (glibc などをメンテしている場合を除きます)。

en: Removals from testing
ja: テスト版からの削除

en: Sometimes, a package is removed to allow another package in: This happens only to allow *another* package to go in if it's ready in every other sense. Suppose e.g. that ``a`` cannot be installed with the new version of ``b``; then ``a`` may be removed to allow ``b`` in.
ja: 時折、パッケージは他のパッケージがテスト版へ入るために削除されます: これは、\ *他の*\ パッケージが他のすべての面で準備ができている場合にテスト版に入るようにする場合のみ発生します。例えば、\ ``a`` が新しいバージョンの ``b`` とはインストールできない場合を考えてみましょう。その場合、\ ``a`` は ``b`` が入るために削除されるかもしれません。

en: Furthermore, if a package has been removed from ``unstable``, and no package in ``testing`` depends on it any more, then it will automatically be removed.
ja: さらに、パッケージが 不安定版 (``unstable``) から削除され、\ ``テスト版 (testing)`` にはこれに依存するパッケージがもうなくなった場合、パッケージは自動的に削除されます。

en: Circular dependencies
ja: 循環依存

en: A situation which is not handled very well by britney is if package ``a`` depends on the new version of package ``b``, and vice versa.
ja: britney によってうまく取扱われない状況は、パッケージ ``a`` がパッケージ ``b`` の新しいバージョンに依存していて、そしてその逆も、というものです。

en: An example of this is:
ja: この場合の例:

en: Neither package ``a`` nor package ``b`` is considered for update.
ja: パッケージ ``a`` あるいはパッケージ ``b`` が更新対象と見做されない。

en: Currently, this requires some manual hinting from the release team. Please contact them by sending mail to ``debian-release@lists.debian.org`` if this happens to one of your packages.
ja: 現状、このような場合はリリースチームによる手動でのヒントが必要になります。あなたのパッケージのどれかにこのような状況が起きた場合は、\ ``debian-release@lists.debian.org`` にメールを送って連絡を取ってください。

en: Influence of package in testing
ja: テスト版 (testing) にあるパッケージへの影響

en: In summary this means: The only influence that a package being in ``testing`` has on a new version of the same package is that the new version might go in easier.
ja: この要旨: 影響は、テスト版 (``testing``) にあるパッケージが、同じパッケージの新しいバージョンになるのは、新しいバージョンの方が楽にできそうだから、ということです。

en: Details
ja: 詳細について

en: If you are interested in details, this is how britney works:
ja: 詳細について知りたい場合ですが、britney の動作は以下のようになります:

en: The packages are looked at to determine whether they are valid candidates. This gives the update excuses. The most common reasons why a package is not considered are too young, RC-bugginess, and out of date on some arches. For this part of britney, the release managers have hammers of various sizes, called hints (see below), to force britney to consider a package.
ja: パッケージが、適切な候補であるかどうかを決めるために確認が行われます。これによって、更新が実行されます。パッケージが候補とみなされない理由でもっともよくあるのは、まだ日数が経過していない (too young)、RC バグがある、いくつかのアーキテクチャで古くなりすぎている、というものです。britney のこの部分では、リリースマネージャーが britney がパッケージを検討できるように、hints と呼ばれる様々なサイズのハンマーを使います (下記を参照してください)。

en: Now, the more complex part happens: Britney tries to update ``testing`` with the valid candidates. For that, britney tries to add each valid candidate to the testing distribution. If the number of uninstallable packages in ``testing`` doesn't increase, the package is accepted. From that point on, the accepted package is considered to be part of ``testing``, such that all subsequent installability tests include this package. Hints from the release team are processed before or after this main run, depending on the exact type.
ja: さて、より複雑な部分に差し掛かります: Britney が適正候補を使ってテスト版 (``testing``) を更新しようとします。このため、britney はテスト版ディストリビューションに個々の適正な候補を追加しようとします。\ ``テスト版 (testing)`` でインストール不可能なパッケージの数が増えないのであれば、パッケージは受け入れられます。その時から、受け入れられたパッケージは\ ``テスト版 (testing)`` の一部として取り扱われ、このパッケージを含めるためのインストールチェックテストが引き続き行われます。リリースチームからの hints は、実際の内容に応じて、このメインの処理の前後に処理されます。

en: If you want to see more details, you can look it up on https://release.debian.org/britney/update_output/\ .
ja: より詳細を見たい場合は、\ https://release.debian.org/britney/update_output/\ で探すことができます。

en: Direct updates to testing
ja: 直接テスト版を更新する

en: The ``testing`` distribution is fed with packages from ``unstable`` according to the rules explained above. However, in some cases, it is necessary to upload packages built only for ``testing``. For that, you may want to upload to ``testing-proposed-updates``.
ja: テスト版 (``testing``) ディストリビューションは、上記で説明したルールに従って ``不安定版 (unstable)`` からのパッケージで作られています。しかし、時折、\ ``テスト版 (testing)`` の為だけに構築したパッケージをアップロードする必要があるという場合があります。そのためには、\ ``testing-proposed-updates`` にアップロードするのが良いでしょう。

en: Version numbers are usually selected by appending ``+deb``\ *X*\ ``uY``, where *X* is the major release number of Debian and *Y* is a counter starting at ``1``. e.g. |version1-revision-deb-version-stable-u1|.
ja: バージョン番号は、通常 ``+deb``\ *X*\ ``uY`` を付加することで指定されます。\ *X* は Debian のメジャーリリース番号で *Y* は ``1`` から始まる数です。例: |version1-revision-deb-version-stable-u1|

en: Please make sure you didn't miss any of these items in your upload:
ja: アップロードでは、以下の項目のいずれも見落とさないように必ずしてください:

en: Make sure that your package really needs to go through ``testing-proposed-updates``, and can't go through ``unstable``;
ja: 本当に ``testing-proposed-updates`` を通す必要があり、\ ``unstable`` ではダメなことを確認する;

en: Make sure that you included only the minimal amount of changes;
ja: 必ず、最小限な量だけの変更を含めるようにする;

en: Make sure that you included an appropriate explanation in the changelog;
ja: 必ず changelog 中に適切な説明を含める;

en: Make sure that you've written the testing :ref:`codenames` (e.g. |codename-testing|) into your target distribution;
ja: 必ず、対象とするディストリビューションとして testing :ref:`codenames` (e.g. |codename-testing|) を記述している;

en: Make sure that you've built and tested your package in ``testing``, not in ``unstable``;
ja: 必ず 不安定版 (``unstable``) ではなく テスト版 (``testing``) でパッケージを構築・テストしている;

en: Make sure that your version number is higher than the version in ``testing`` and ``testing-proposed-updates``, and lower than in ``unstable``;
ja: バージョン番号が ``testing`` および ``testing-proposed-updates`` のものよりも大きく、\ ``unstable`` のものよりも小さいのを確認する;

en: After uploading and successful build on all platforms, contact the release team at ``debian-release@lists.debian.org`` and ask them to approve your upload.
ja: アップロードしてすべてのプラットフォームで構築が成功したら、\ ``debian-release@lists.debian.org`` 宛でリリースチームに連絡を取って、アップロードを承認してくれるように依頼しましょう。

en: Frequently asked questions
ja: よく聞かれる質問とその答え (FAQ)

en: What are release-critical bugs, and how do they get counted?
ja: リリースクリティカルバグとは何ですか、どうやって数えるのですか?

en: All bugs of some higher severities are by default considered release-critical; currently, these are ``critical``, ``grave`` and ``serious`` bugs.
ja: ある重要度以上のバグすべてが通常リリースクリティカルであると見なされます。現在のところ、\ ``critical (致命的)``\ 、\ ``grave (重大)``\ 、\ ``serious (深刻)`` バグがそれにあたります。

en: Such bugs are presumed to have an impact on the chances that the package will be released with the ``stable`` release of Debian: in general, if a package has open release-critical bugs filed on it, it won't get into ``testing``, and consequently won't be released in ``stable``.
ja: そのようなバグは、Debian の 安定版 (``stable``) リリース時に、そのパッケージがリリースされる見込みに影響があるものと仮定されます: 一般的に、パッケージでオープンになっているリリースクリティカルバグがある場合、そのパッケージは\ ``テスト版 (testing)`` に入らず、その結果安定版 (``stable``) ではリリースされません。

en: How could installing a package into ``testing`` possibly break other packages?
ja: どのようにすれば、他のパッケージを壊す可能性があるパッケージをテスト版 (``testing``) へインストールできますか?

en: The structure of the distribution archives is such that they can only contain one version of a package; a package is defined by its name. So when the source package ``acmefoo`` is installed into ``testing``, along with its binary packages ``acme-foo-bin``, ``acme-bar-bin``, ``libacme-foo1`` and ``libacme-foo-dev``, the old version is removed.
ja: ディストリビューションにおけるアーカイブの構造では、一つのバージョンのパッケージだけを持つことができ、パッケージは名前によって定義されています。そのため、ソースパッケージ ``acmefoo`` がテスト版 (``testing``) にインストールされると、付随するバイナリパッケージ ``acme-foo-bin``\ 、\ ``acme-bar-bin``\ 、\ ``libacme-foo1``\ 、\ ``libacme-foo-dev`` の古いバージョンが削除されます。

en: If you are having problems with complicated groups of packages like this, contact ``debian-devel@lists.debian.org`` or ``debian-release@lists.debian.org`` for help.
ja: この様に複雑な組み合わせのパッケージで問題がある場合は、\ ``debian-devel@lists.debian.org`` あるいは ``debian-release@lists.debian.org`` に連絡を取って手助けを求めてください。

en: See the `Debian Policy Manual <https://www.debian.org/doc/debian-policy/>`__ for guidelines on what section a package belongs in.
ja: パッケージがどのセクションに属するかのガイドラインは `Debian ポリシーマニュアル <https://www.debian.org/doc/debian-policy/>`__\ \ を参照してください。

en: In the past, such NMUs used the third-level number on the Debian part of the revision to denote their recompilation-only status; however, this syntax was ambiguous with native packages and did not allow proper ordering of recompile-only NMUs, source NMUs, and security NMUs on the same package, and has therefore been abandoned in favor of this new syntax.
ja: 過去においては、再コンパイルのみの状態を意味するために、このような NMU はリビジョンの Debian 部分の三つ目の番号を使っていました。しかし、この記法はネイティブパッケージの場合に曖昧で、同一パッケージでの再コンパイルのみの NMU と、ソース NMU と、セキュリティ NMU の正しい順序が付けられなかったため、この新しい記法で置き換えられました。
