developers-reference 3.4.4 - en to ja translation catalogue (247 entries)

note: type: Content of: <chapter><title>
en: Managing Packages
ja: パッケージの取扱い方

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

note: type: Content of: <chapter><section><title>
en: New packages
ja: 新規パッケージ

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

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

note: type: Content of: <chapter><section><para>
en: You should set the subject of the bug to <literal>ITP: <replaceable>foo</replaceable> -- <replaceable>short description</replaceable></literal>, substituting the name of the new package for <replaceable>foo</replaceable>.  The severity of the bug report must be set to <literal>wishlist</literal>.  Please send a copy to &email-debian-devel; by using the X-Debbugs-CC header (don't use CC:, because that way the message's subject won't indicate the bug number). If you are packaging so many new packages (>10)  that notifying the mailing list in separate messages is too disruptive, send a summary after filing the bugs to the debian-devel list instead.  This will inform the other developers about upcoming packages and will allow a review of your description and package name.
ja: サブジェクトを <literal>ITP: <replaceable>foo</replaceable> -- <replaceable>short description</replaceable></literal> に設定する必要があります。ここでは <replaceable>foo</replaceable> は新規パッケージの名前に置き換えます。バグ報告の重要度は <literal>wishlist</literal> に設定しなければなりません。X-Debbugs-CC ヘッダを使ってコピーを &email-debian-devel; に送信してください (CC: は使わないでください。CC: を使った場合はメールのサブジェクトがバグ番号を表示しないためです)。大量の新規パッケージの作成 (11 個以上) を行っている場合、メーリングリストへ個別に通知するのは鬱陶しいので、代わりにバグを登録した後で要約を送信してください。これによって、他の開発者らに次に来るパッケージを知らせ、説明とパッケージ名のレビューが可能になります。

note: type: Content of: <chapter><section><para>
en: Please include a <literal>Closes: #<replaceable>nnnnn</replaceable></literal> 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 <xref linkend="upload-bugfix"/>).
ja: 新規パッケージがアーカイブへインストールされる際にバグ報告を自動的に閉じるため、<literal>Closes: #<replaceable>nnnnn</replaceable></literal> というエントリを新規パッケージの changelog 内に含めてください (<xref linkend="upload-bugfix"/> を参照)。

note: type: Content of: <chapter><section><para>
en: If you think your package needs some explanations for the administrators of the NEW package queue, include them in your changelog, send to &email-ftpmaster; 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 に説明を含めて &email-ftpmaster; へ送ってください。アップロード後であればメンテナとして受け取ったメールに返信してください。もしくは既に再アップロードをの最中の場合は reject のメールに対して返信してください。

note: type: Content of: <chapter><section><para>
en: When closing security bugs include CVE numbers as well as the <literal>Closes: #<replaceable>nnnnn</replaceable></literal>.  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 番号を <literal>Closes: #<replaceable>nnnnn</replaceable></literal> と同じく含めるようにしてください。これは、セキュリティチームが脆弱性を追跡するのに役立ちます。アドバイザリの ID が分かる前にバグ修正のためのアップロードが行われた場合は、以前の changelog エントリを次のアップロード時に修正するのが推奨されています。このような場合でも、元々の changelog での記載に可能な限り背景情報へのポインタを全て含めてください。

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

note: type: Content of: <chapter><section><itemizedlist><listitem><para>
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: (潜在的な新たな) メンテナが、メーリングリストの人々の経験を活かすのを手助けし、もし他の誰かが既に作業を行っていた場合に知らせる。

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

note: type: Content of: <chapter><section><itemizedlist><listitem><para>
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 &email-debian-devel-changes;.
ja: &email-debian-devel-changes; に流される一行の説明文 (description) と通常どおりの「Intial release」という changelog エントリよりも、残った他のメンテナがパッケージに関してより深く知ることができる。

note: type: Content of: <chapter><section><itemizedlist><listitem><para>
en: It is helpful to the people who live off <literal>unstable</literal> (and form our first line of testers).  We should encourage these people.
ja: <literal>不安定版 (unstable)</literal> で暮らす人 (そして最前線のテスターである人) の助けになる。

note: type: Content of: <chapter><section><itemizedlist><listitem><para>
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: メンテナや他に興味を持つ人々へ、プロジェクトで何が行われているのか、何か新しいことがあるかということ関して、告知は良い印象を与える。

note: type: Content of: <chapter><section><para>
en: Please see <ulink url="http://&ftp-master-host;/REJECT-FAQ.html"></ulink> for common rejection reasons for a new package.
ja: 新しいパッケージに対する一般的な拒否理由については <ulink url="http://&ftp-master-host;/REJECT-FAQ.html"></ulink> を参照してください。

note: type: Content of: <chapter><section><title>
en: Recording changes in the package
ja: パッケージの変更を記録する

note: type: Content of: <chapter><section><para>
en: Changes that you make to the package need to be recorded in the <filename>debian/changelog</filename>.  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 package was completed.  This file will be installed in <filename>/usr/share/doc/<replaceable>package</replaceable>/changelog.Debian.gz</filename>, or <filename>/usr/share/doc/<replaceable>package</replaceable>/changelog.gz</filename> for native packages.
ja: パッケージについて行った変更は <filename>debian/changelog</filename> に記録されなくてはいけません。これらの変更には、何が変更されたのか、(不確かであれば) 何故なのか、そしてどのバグが閉じられたのかの簡潔な説明文を付加する必要があります。このファイルは <filename>/usr/share/doc/<replaceable>package</replaceable>/changelog.Debian.gz</filename>、あるいは native パッケージの場合は <filename>/usr/share/doc/<replaceable>package</replaceable>/changelog.gz</filename> にインストールされます。

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

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

note: type: Content of: <chapter><section><para>
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 エントリは、以下のようにするのが慣習です:

note: type: Content of: <chapter><section><para>
en: There are tools to help you create entries and finalize the <filename>changelog</filename> for release — see <xref linkend="devscripts"/> and <xref linkend="dpkg-dev-el"/>.
ja: <filename>changelog</filename> エントリの作成と仕上げ処理に使えるツールがあります。<xref linkend="devscripts"/> と <xref linkend="dpkg-dev-el"/> を参照してください。

note: type: Content of: <chapter><section><para>
en: See also <xref linkend="bpp-debian-changelog"/>.
ja: <xref linkend="bpp-debian-changelog"/> も参照してください。

note: type: Content of: <chapter><section><title>
en: Testing the package
ja: パッケージをテストする

note: type: Content of: <chapter><section><para>
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 パッケージの古いバージョンなどが必要になるでしょう):

note: type: Content of: <chapter><section><itemizedlist><listitem><para>
en: Install the package and make sure the software works, or upgrade the package from an older version to your new version if a Debian package for it already exists.
ja: パッケージをインストールしてソフトウェアが動作するのを確認する、あるいは既にそのソフトの Debian パッケージが存在している場合、パッケージを以前のバージョンから新しいバージョンにアップグレードする。

note: type: Content of: <chapter><section><itemizedlist><listitem><para>
en: Run <command>lintian</command> over the package.  You can run <command>lintian</command> as follows: <literal>lintian -v <replaceable>package-version</replaceable>.changes</literal>.  This will check the source package as well as the binary package.  If you don't understand the output that <command>lintian</command> generates, try adding the <literal>-i</literal> switch, which will cause <command>lintian</command> to output a very verbose description of the problem.
ja: パッケージに対して <command>lintian</command> を実行する。以下のようにして <command>lintian</command> を実行できます: <literal>lintian -v <replaceable>package-version</replaceable>.changes</literal> 。<command>lintian</command> が生成した出力を理解していない場合は、<command>lintian</command> が問題の説明を非常に冗長に出力するようにする <literal>-i</literal> オプションを付けて実行してみてください。

note: type: Content of: <chapter><section><itemizedlist><listitem><para>
en: Normally, a package should <emphasis>not</emphasis> be uploaded if it causes lintian to emit errors (they will start with <literal>E</literal>).
ja: 通常、lintian がエラーを出力するようであれば、パッケージをアップロードしては<emphasis>いけません</emphasis> (エラーは <literal>E</literal> で始まります)。

note: type: Content of: <chapter><section><itemizedlist><listitem><para>
en: For more information on <command>lintian</command>, see <xref linkend="lintian"/>.
ja: <command>lintian</command> についての詳細は、<xref linkend="lintian"/> を参照してください。

note: type: Content of: <chapter><section><itemizedlist><listitem><para>
en: Optionally run <command>debdiff</command> (see <xref linkend="debdiff"/>) to analyze changes from an older version, if one exists.
ja: もし古いバージョンがあれば、それからの変更点を分析するために追加で <command>debdiff</command> を実行する (<xref linkend="debdiff"/> を参照) 。

note: type: Content of: <chapter><section><itemizedlist><listitem><para>
en: Downgrade the package to the previous version (if one exists) — this tests the <filename>postrm</filename> and <filename>prerm</filename> scripts.
ja: (もしあれば) 以前のバージョンにダウングレードする — これは <filename>postrm</filename> スクリプトと <filename>prerm</filename> スクリプトをテストします。

note: type: Content of: <chapter><section><itemizedlist><listitem><para>
en: Remove the package, then reinstall it.
ja: パッケージを削除して、再インストールする。

note: type: Content of: <chapter><section><itemizedlist><listitem><para>
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 <filename>.diff.gz</filename> file.
ja: ソースパッケージを違うディレクトリにコピーして展開し、再構築する。これは、パッケージが外部の既存ファイルに依っているか、<filename>.diff.gz</filename> ファイル内に含まれているファイルで保存されている権限に依るかどうかをテストします。

note: type: Content of: <chapter><section><title>
en: Layout of the source package
ja: ソースパッケージの概要

note: type: Content of: <chapter><section><para>
en: There are two types of Debian source packages:
ja: Debian のソースパッケージには 2 種類あります：

note: type: Content of: <chapter><section><itemizedlist><listitem><para>
en: the so-called <literal>native</literal> packages, where there is no distinction between the original sources and the patches applied for Debian
ja: いわゆる <literal>native</literal>パッケージ。元のソースと Debian で当てられたパッチの間に差が無いもの

note: type: Content of: <chapter><section><itemizedlist><listitem><para>
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 によって作成された変更点を含む別のファイルが付随している (より一般的な) パッケージ

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

note: type: Content of: <chapter><section><para>
en: With source format “1.0”, whether a package is native or not was determined by <command>dpkg-source</command> 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 <filename>debian/source/format</filename>.  The rest of this section relates only to non-native packages.
ja: ソース形式“1.0”では、パッケージが native かどうかはビルド時に <command>dpkg-source</command> によって決められていました。最近では望むソース形式を <filename>debian/source/format</filename> に“3.0 (quilt)”または“3.0 (native)”と記述することによって明示することが推奨されています。この章の残りの部分は native ではないパッケージについてのみ記しています。

note: type: Content of: <chapter><section><para>
en: The first time a version is uploaded which corresponds to a particular upstream version, the original source tar file should be uploaded and included in the <filename>.changes</filename> file.  Subsequently, this very same tar file should be used to build the new diffs and <filename>.dsc</filename> files, and will not need to be re-uploaded.
ja: 初回には、特定の開発元のバージョン (upstream version) に該当するバージョンがアップロードされます。元のソース tar ファイルは、アップロードされて <filename>.changes</filename> ファイルに含まれている必要があります。その後、新しい diff ファイルや <filename>.dsc</filename> ファイルの生成には全く同じ tar ファイルを使わなければならず、これを再アップロードする必要はありません。

note: type: Content of: <chapter><section><para>
en: By default, <command>dpkg-genchanges</command> and <command>dpkg-buildpackage</command> 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 <literal>-sa</literal> to always include it or <literal>-sd</literal> to always leave it out.
ja: デフォルトでは、<command>dpkg-genchanges</command> および <command>dpkg-buildpackage</command> は前述されている changelog エントリと現在のエントリが異なった upstream バージョンを持つ場合にのみ、オリジナルのソース tar ファイルを含めようとします。この挙動は、<literal>-sa</literal> を使って常に含めたり、<literal>-sd</literal> を使うことで常に含めないようにするように変更できます。

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

note: type: Content of: <chapter><section><para>
en: Please notice that, in non-native packages, permissions on files that are not present in the <filename>*.orig.tar.{gz,bz2,lzma}</filename> will not be preserved, as diff does not store file permissions in the patch. However when using source format “3.0 (quilt)”, permissions of files inside the <filename>debian</filename> directory are preserved since they are stored in a tar archive.
ja: 注意していただきたいのですが、native ではないパッケージでは、diff はパッチ内のファイルパーミッションを保存しないので、<filename>*.orig.tar.{gz,bz2,lzma}</filename> 内に存在しないファイルのパーミッションは保持されません。しかし、ソース形式“3.0 (quilt)”を使っている場合、<filename>debian</filename> ディレクトリ内にあるファイルのパーミッションは tar アーカイブで保存されるのでそのままになります。

note: type: Content of: <chapter><section><title>
en: Picking a distribution
ja: ディストリビューションを選ぶ

note: type: Content of: <chapter><section><para>
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 <filename>debian/changelog</filename> file and places it in the <literal>Distribution</literal> field of the <filename>.changes</filename> file.
ja: アップロードでは、パッケージがどのディストリビューション向けになっているかを指定してあることが必要です。パッケージの構築プロセスでは、<filename>debian/changelog</filename> ファイルの最初の行からこの情報を展開し、<filename>.changes</filename> ファイルの <literal>Distribution</literal> 欄に配置します。

note: type: Content of: <chapter><section><para>
en: There are several possible values for this field: <literal>stable</literal>, <literal>unstable</literal>, <literal>testing-proposed-updates</literal> and <literal>experimental</literal>.  Normally, packages are uploaded into <literal>unstable</literal>.
ja: この欄にはいくつか指定可能な値があります: <literal>stable</literal>、<literal>unstable</literal>、<literal>testing-proposed-updates</literal>、そして <literal>experimental</literal> です。通常、パッケージは <literal>unstable</literal> にアップロードされます。

note: type: Content of: <chapter><section><para>
en: Actually, there are two other possible distributions: <literal>stable-security</literal> and <literal>testing-security</literal>, but read <xref linkend="bug-security"/> for more information on those.
ja: 実際には、他に二つ指定可能なディストリビューションがあります: <literal>stable-security</literal> と <literal>testing-security</literal> ですが、これらについての詳細は <xref linkend="bug-security"/> を読んでください。

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

note: type: Content of: <chapter><section><section><title>
en: Special case: uploads to the <literal>stable</literal> and <literal>oldstable</literal> distributions
ja: 特別な例: <literal>安定版 (stable)</literal> と <literal>旧安定版 (oldstable)</literal> ディストリビューションへアップロードする

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

note: type: Content of: <chapter><section><section><para>
en: To ensure that your upload will be accepted, you should discuss the changes with the stable release team before you upload. For that, send a mail to the &email-debian-release; mailing list, including the patch you want to apply to the package version currently in <literal>stable</literal>. Always be verbose and detailed in your changelog entries for uploads to the <literal>stable</literal> distribution.
ja: アップロードが許可されるのを確実にするには、アップロードの前に変更点について安定版リリースチームと協議する必要があります。そのためには、<literal>安定版 (stable)</literal> にある現在のパッケージバージョンに適用したいパッチを含めたメールを &email-debian-release; メーリングリストに送ってください。<literal>安定版 (stable)</literal> ディストリビューションへアップロードするパッケージの changelog のエントリには常にくどいほど詳細にしてください。

note: type: Content of: <chapter><section><section><para>
en: Extra care should be taken when uploading to <literal>stable</literal>.  Basically, a package should only be uploaded to <literal>stable</literal> if one of the following happens:
ja: <literal>安定版 (stable)</literal> へのアップロード時には特に注意を払うことが必要です。基本的に、以下のいずれかが起こった際にのみ <literal>安定版 (stable)</literal> へパッケージはアップロードされます:

note: type: Content of: <chapter><section><section><itemizedlist><listitem><para>
en: a truly critical functionality problem
ja: 本当に致命的な機能の問題がある

note: type: Content of: <chapter><section><section><itemizedlist><listitem><para>
en: the package becomes uninstallable
ja: パッケージがインストールできなくなる

note: type: Content of: <chapter><section><section><itemizedlist><listitem><para>
en: a released architecture lacks the package
ja: リリースされたアーキテクチャにパッケージが無い

note: type: Content of: <chapter><section><section><para>
en: In the past, uploads to <literal>stable</literal> were used to address security problems as well.  However, this practice is deprecated, as uploads used for Debian security advisories are automatically copied to the appropriate <filename>proposed-updates</filename> archive when the advisory is released.  See <xref linkend="bug-security"/> for detailed information on handling security problems. If the security teams deems the problem to be too benign to be fixed through a <literal>DSA</literal>, the stable release managers are usually willing to include your fix nonetheless in a regular upload to <literal>stable</literal>.
ja: 以前、<literal>安定版 (stable)</literal> へのアップロードはセキュリティ問題への対処と同等に取り扱われていました。しかし、この慣習は廃れており、Debian セキュリティ勧告がリリースされた際、セキュリティ勧告へのアップロードに使われたものが自動的に適切な <filename>proposed-updates</filename> アーカイブにコピーされます。セキュリティ情報の取り扱い方の詳細については <xref linkend="bug-security"/> を参照してください。セキュリティチームがその問題は <literal>DSA</literal> を通じて修正するには軽微過ぎると思った場合であっても、安定版のリリースマネージャらはそれに関わらず <literal>安定版 (stable)</literal> への定期アップロードに修正を含めようとするでしょう。

note: type: Content of: <chapter><section><section><para>
en: Changing anything else in the package that isn't important is discouraged, because even trivial fixes can cause bugs later on.
ja: 些細な修正でも後ほどバグを引き起こすことがあるので、重要でないものは何であろうと変更するのは推奨されません。

note: type: Content of: <chapter><section><section><para>
en: Packages uploaded to <literal>stable</literal> need to be compiled on systems running <literal>stable</literal>, so that their dependencies are limited to the libraries (and other packages) available in <literal>stable</literal>; for example, a package uploaded to <literal>stable</literal> that depends on a library package that only exists in <literal>unstable</literal> will be rejected.  Making changes to dependencies of other packages (by messing with <literal>Provides</literal> or <filename>shlibs</filename> files), possibly making those other packages uninstallable, is strongly discouraged.
ja: <literal>安定版 (stable)</literal> にアップロードされるパッケージは<literal>安定版 (stable)</literal> を動作しているシステム上でコンパイルされていなければならず、ライブラリ (やその他のパッケージ) への依存は<literal>安定版 (stable)</literal> で入手可能なものに限られます。例えば、<literal>安定版 (stable)</literal> にアップロードされたパッケージが<literal>不安定版 (unstable)</literal> にのみ存在するライブラリパッケージに依存していると reject されます。他のパッケージへの依存を (<literal>提供 (Provides)</literal> や <filename>shlibs</filename> をいじることで) 変更するのは、他のパッケージをインストールできないようにする可能性があるので認められません。

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

note: type: Content of: <chapter><section><section><title>
en: Special case: uploads to <literal>testing/testing-proposed-updates</literal>
ja: 特別な例: <literal>testing/testing-proposed-updates</literal> へアップロードする

note: type: Content of: <chapter><section><section><para>
en: Please see the information in the <link linkend="t-p-u">testing section</link> for details.
ja: 詳細については、<link linkend="t-p-u">testing section</link> にある情報を参照してください。

note: type: Content of: <chapter><section><title>
en: Uploading a package
ja: パッケージをアップロードする

note: type: Content of: <chapter><section><section><title>
en: Uploading to <literal>ftp-master</literal>
ja: <literal>ftp-master</literal> にアップロードする

note: type: Content of: <chapter><section><section><para>
en: To upload a package, you should upload the files (including the signed changes and dsc-file) with anonymous ftp to <literal>&ftp-upload-host;</literal> in the directory <ulink url="ftp://&ftp-upload-host;&upload-queue;">&upload-queue;</ulink>.  To get the files processed there, they need to be signed with a key in the Debian Developers keyring or the Debian Maintainers keyring (see <ulink url="&url-wiki-dm;"></ulink>).
ja: パッケージをアップロードするには、ファイル (署名された changes ファイルと dsc ファイル) を anonymous ftp で <literal>&ftp-upload-host;</literal> の <ulink url="ftp://&ftp-upload-host;&upload-queue;">&upload-queue;</ulink> へアップロードする必要があります。そこでファイルを処理するためには、Debian Developers keyring または Debian Maintainers keyring (<ulink url="&url-wiki-dm;"></ulink> 参照) にある鍵で署名しておく必要があります。

note: type: Content of: <chapter><section><section><para>
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 されるかもしれません。

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

note: type: Content of: <chapter><section><section><para>
en: For removing packages, please see <ulink url="ftp://&ftp-upload-host;&upload-queue;README"/> and the Debian package <link linkend="dcut">dcut</link>.
ja: パッケージを削除するには <ulink url="ftp://&ftp-upload-host;&upload-queue;README"/> と <link linkend="dcut">dcut</link> Debian パッケージを参照してください。

note: type: Content of: <chapter><section><section><title>
en: Delayed uploads
ja: 遅延アップロード

note: type: Content of: <chapter><section><section><para>
en: It is sometimes useful to upload a package immediately, but to want this package to arrive in the archive only a few days later. For example, when preparing a <link linkend="nmu">Non-Maintainer Upload</link>, you might want to give the maintainer a few days to react.
ja: パッケージを直ちにアップロードするのが良い時もありますが、パッケージがアーカイブに入るのが数日後であるのが良いと思う時もあります。例えば、<link linkend="nmu">Non-Maintainer アップロード</link>の準備をする際は、メンテナに対して猶予期間を数日間与えたいと思うでしょう。

note: type: Content of: <chapter><section><section><para>
en: An upload to the delayed directory keeps the package in <ulink url="http://ftp-master.debian.org/deferred.html">the deferred uploads queue</ulink>.  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 <literal>&ftp-upload-host;</literal> in upload-directory <literal>DELAYED/[012345678]-day</literal>. 0-day is uploaded multiple times per day to <literal>&ftp-upload-host;</literal>.
ja: delayed ディレクトリにアップロードされると、パッケージは <ulink url="http://ftp-master.debian.org/deferred.html">the deferred uploads queue</ulink> に保存されます。指定した待ち時間が終わると、パッケージは処理のため通常の incoming ディレクトリに移動されます。この作業は <literal>&ftp-upload-host;</literal> の <literal>DELAYED/[012345678]-day</literal> ディレクトリへのアップロードを通じて自動的に処理されます。0-day は一日に複数回 <literal>&ftp-upload-host;</literal> へアップロードするのに使われます。

note: type: Content of: <chapter><section><section><para>
en: With dput, you can use the <literal>--delayed <replaceable>DELAY</replaceable></literal> parameter to put the package into one of the queues.
ja: dput を使うと、パッケージを遅延キューに入れるのに <literal>--delayed <replaceable>DELAY</replaceable></literal> パラメータを使えます。

note: type: Content of: <chapter><section><section><title>
en: Security uploads
ja: セキュリティアップロード

note: type: Content of: <chapter><section><section><para>
en: Do <emphasis role="strong">NOT</emphasis> upload a package to the security upload queue (<literal>oldstable-security</literal>, <literal>stable-security</literal>, etc.) without prior authorization from the security team.  If the package does not exactly meet the team's requirements, it will cause many problems and delays in dealing with the unwanted upload.  For details, please see <xref linkend="bug-security"/>.
ja: セキュリティアップロードキュー (<literal>oldstable-security</literal>、<literal>stable-security</literal> 等) には、セキュリティチームからの事前許可無しにパッケージを<emphasis role="strong">アップロードしないでください</emphasis>。パッケージがチームの要求に完全に合致していない場合、望まれないアップロードに対処するために多くの問題が引き起こされたり遅延が生じることになります。詳細については <xref linkend="bug-security"/> を参照してください。

note: type: Content of: <chapter><section><section><title>
en: Other upload queues
ja: 他のアップロードキュー

note: type: Content of: <chapter><section><section><para>
en: There is an alternative upload queue in Europe at <ulink url="ftp://&ftp-eu-upload-host;&upload-queue;"/>. It operates in the same way as <literal>&ftp-upload-host;</literal>, but should be faster for European developers.
ja: ヨーロッパにはもう一つのアップロードキューが <ulink url="ftp://&ftp-eu-upload-host;&upload-queue;"/> にあります。操作方法は <literal>&ftp-upload-host;</literal> と同じですが、ヨーロッパ圏の開発者に対しては、より速いはずです。

note: type: Content of: <chapter><section><section><para>
en: Packages can also be uploaded via ssh to <literal>&ssh-upload-host;</literal>; files should be put <literal>/srv/upload.debian.org/UploadQueue</literal>. This queue does not support <link linkend="delayed-incoming">delayed uploads</link>.
ja: パッケージは ssh を使って <literal>&ssh-upload-host;</literal> へアップロードすることも可能です。ファイルは <literal>/srv/upload.debian.org/UploadQueue</literal> に置く必要があります。このキューは<link linkend="delayed-incoming">遅延アップロード</link>をサポートしていません。

note: type: Content of: <chapter><section><section><title>
en: Notification that a new package has been installed
ja: 新しいパッケージがインストールされたことの通知

note: type: Content of: <chapter><section><section><para>
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, <command>katie</command>.  Specifically, updates to existing packages to the <literal>unstable</literal> 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 up to a month to occur.  Please be patient.
ja: Debian アーカイブメンテナはパッケージのアップロードに関して責任を持っています。多くの部分は、アップロードはアーカイブ用のメンテナンスツール <command>katie</command> によって日々自動的に行われています。特に、<literal>不安定版 (unstable)</literal> に存在しているパッケージの更新は自動的に処理されます。それ以外の場合、特に新規パッケージの場合は、アップロードされたパッケージをディストリビューションに含めるのは手動で行われます。アップロードが手動で処理される場合は、アーカイブへの変更は実施されるまでに一ヶ月ほどかかります。お待ちください。

note: type: Content of: <chapter><section><section><para>
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: どの場合であっても、パッケージがアーカイブに追加されたことや、バグがアップロードで閉じられたことを告げるメールでの通知を受け取ることになります。あなたが閉じようとしたバグが処理されてない場合は、この通知を注意深く確認してください。

note: type: Content of: <chapter><section><section><para>
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: インストール通知もパッケージがどのセクションに入ったかを示す情報を含んでいます。不一致がある場合は、それを示す別のメール通知を受け取ります。以下も参照ください。

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

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

note: type: Content of: <chapter><section><para>
en: The <filename>debian/control</filename> file's <literal>Section</literal> and <literal>Priority</literal> 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 <filename>debian/control</filename> file are actually just hints.
ja: <filename>debian/control</filename> ファイルの <literal>セクション (Section)</literal> フィールドと <literal>優先度 (Priority)</literal> フィールドは実際にアーカイブ内でどこに配置されるか、あるいはプライオリティが何かという指定ではありません。<filename>debian/control</filename> ファイル中の値は、実際のところは単なるヒントです。

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

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

note: type: Content of: <chapter><section><para>
en: For more information about <literal>override files</literal>, see <citerefentry> <refentrytitle>dpkg-scanpackages</refentrytitle> <manvolnum>1</manvolnum> </citerefentry> and <ulink url="&url-bts-devel;#maintincorrect"></ulink>.
ja: <literal>override ファイル</literal> についての詳細は、<citerefentry> <refentrytitle>dpkg-scanpackages</refentrytitle> <manvolnum>1</manvolnum> </citerefentry> と <ulink url="&url-bts-devel;#maintincorrect"></ulink> を参照してください。

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

note: type: Content of: <chapter><section><title>
en: Handling bugs
ja: バグの取扱い

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

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

note: type: Content of: <chapter><section><para>
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 <ulink url="&url-bts-control;">BTS control server documentation</ulink>.
ja: バグを他のパッケージに割り当てし直す、同じ問題についての別々のバグ報告をマージする、などの作業はいわゆる制御メールサーバと呼ばれるものを使って処理されています。このサーバで利用可能なすべてのコマンドは、<ulink url="&url-bts-control;">BTS 制御サーバドキュメント</ulink>に記載されています。

note: type: Content of: <chapter><section><section><title>
en: Monitoring bugs
ja: バグの監視

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

note: type: Content of: <chapter><section><section><para>
en: Maintainers interact with the BTS via email addresses at <literal>&bugs-host;</literal>.  Documentation on available commands can be found at <ulink url="&url-bts;"></ulink>, or, if you have installed the <systemitem role="package">doc-debian</systemitem> package, you can look at the local files &file-bts-docs;.
ja: メンテナは、<literal>&bugs-host;</literal> のメールアドレス経由で BTS に対応します。利用可能なコマンドについてのドキュメントは <ulink url="&url-bts;"></ulink> で参照可能ですし、もし <systemitem role="package">doc-debian</systemitem> パッケージをインストールしてあれば、ローカルファイル &file-bts-docs; で見ることも可能です。

note: type: Content of: <chapter><section><section><para>
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 ジョブを追加します:

note: type: Content of: <chapter><section><section><screen>
en: # ask for weekly reports of bugs in my packages
    &cron-bug-report;
ja: # 自分のパッケージにあるバグのレポートを毎週取得する
    &cron-bug-report;

note: type: Content of: <chapter><section><section><para>
en: Replace <replaceable>address</replaceable> with your official Debian maintainer address.
ja: <replaceable>address</replaceable> は、あなたの公式な Debian パッケージメンテナとしてのメールアドレスに置き換えてください。

note: type: Content of: <chapter><section><section><title>
en: Responding to bugs
ja: バグへの対応

note: type: Content of: <chapter><section><section><para>
en: When responding to bugs, make sure that any discussion you have about bugs is sent both to the original submitter of the bug, and to the bug itself (e.g., <email><replaceable>123</replaceable>@&bugs-host;</email>).  If you're writing a new mail and you don't remember the submitter email address, you can use the <email><replaceable>123</replaceable>-submitter@&bugs-host;</email> email to contact the submitter <emphasis>and</emphasis> to record your mail within the bug log (that means you don't need to send a copy of the mail to <email><replaceable>123</replaceable>@&bugs-host;</email>).
ja: バグに対応する際は、バグについて行った議論がバグの元々の報告者とバグ自身 (例えば <email><replaceable>123</replaceable>@&bugs-host;</email>) の両方に送られているのを確認してください。新しくメールを書いていて元々の報告者のメールアドレスを思い出せない場合は、<email><replaceable>123</replaceable>-submitter@&bugs-host;</email> というメールアドレスが報告者へ連絡するのと、<emphasis>さらに</emphasis>バグのログへあなたがメールしたのを記録するのにも使えます (これは <email><replaceable>123</replaceable>@&bugs-host;</email> へメールのコピーを送らなくても済むことを意味しています)。

note: type: Content of: <chapter><section><section><para>
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) を意味します。移植作業をしている人たちはこの略語をよく使います。

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

note: type: Content of: <chapter><section><section><para>
en: You should <emphasis>never</emphasis> close bugs via the bug server <literal>close</literal> command sent to &email-bts-control;.  If you do so, the original submitter will not receive any information about why the bug was closed.
ja: <literal>close</literal> コマンドを &email-bts-control; に送って、バグサーバ経由でバグを閉じるのは<emphasis>決して</emphasis>してはいけません。そのようにした場合、元々の報告者は何故バグが閉じられたのかという情報を得られません。

note: type: Content of: <chapter><section><section><title>
en: Bug housekeeping
ja: バグを掃除する

note: type: Content of: <chapter><section><section><para>
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 <ulink url="&url-bts-devel;">BTS documentation for Debian developers</ulink>.  Operations such as reassigning, merging, and tagging bug reports are described in the <ulink url="&url-bts-control;">BTS control server documentation</ulink>.  This section contains some guidelines for managing your own bugs, based on the collective Debian developer experience.
ja: パッケージメンテナになると、他のパッケージにバグを見つけたり、自分のパッケージに対して報告されたバグが実際には他のパッケージにあるバグであったりということが頻繁にあるでしょう。バグ追跡システムの機能は <ulink url="&url-bts-devel;">Debian 開発者向けの BTS ドキュメント</ulink> に記載されています。バグ報告の再指定 (reassign) やマージ (merge)、そしてタグ付けなどの作業は <ulink url="&url-bts-control;">BTS 制御サーバのドキュメント</ulink> に記述されています。この章では、Debian 開発者から集められた経験を元にしたバグの扱い方のガイドラインを含んでいます。

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

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

note: type: Content of: <chapter><section><section><orderedlist><listitem><para>
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: 報告が実際にバグに関連するものか否かを決めてください。ユーザはドキュメントを読んでいないため、誤ったプログラムの使い方をしているだけのことが時々あります。このように判断した場合は、ユーザに問題を修正するのに十分な情報を与えて (良いドキュメントへのポインタを教えるなどして) バグを閉じます。同じ報告が何度も繰り返し来る場合には、ドキュメントが十分なものかどうか、あるいは有益なエラーメッセージを与えるよう、誤った使い方を検知していないのでは、と自身に問い直してください。これは開発元の作者に伝える必要がある問題かもしれません。

note: type: Content of: <chapter><section><section><orderedlist><listitem><para>
en: If the bug submitter disagrees with your decision to close the bug, they may reopen it until you find an agreement on how to handle it.  If you don't find any, you may want to tag the bug <literal>wontfix</literal> to let people know that the bug exists but that it won't be corrected.  If this situation is unacceptable, you (or the submitter) may want to require a decision of the technical committee by reassigning the bug to <systemitem role="package">tech-ctte</systemitem> (you may use the clone command of the BTS if you wish to keep it reported against your package).  Before doing so, please read the <ulink url="&url-tech-ctte;">recommended procedure</ulink>.
ja: バグを閉じるという貴方の判断にバグ報告者らが同意しない場合には、それをどう取り扱うかについての同意が見つかるまで、彼らは再度オープンな状態 (reopen) にするでしょう。そのバグについてもう議論することが無いという場合は、バグは存在するが修正することはないと知らせるため、バグに対して <literal>wontfix</literal> タグを付けることになります。この決定が受け入れがたい時には、あなた (あるいは報告者) はバグを <systemitem role="package">tech-ctte</systemitem> に再指定 (reassign) して技術委員会 (technical committee) の判断を仰いでください (パッケージへ報告されたものをそのままにしておきたい場合は、BTS の clone コマンドを使ってください)。これを行う前には<ulink url="&url-tech-ctte;">推奨手順</ulink>を読んでおいてください。

note: type: Content of: <chapter><section><section><orderedlist><listitem><para>
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 <link linkend="irc-channels">IRC</link> or on &email-debian-devel;.  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 <email><replaceable>packagename</replaceable>@packages.debian.org</email> and explaining your reasons in that mail. Please note that a simple reassignment is <emphasis>not</emphasis> 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) します。どのパッケージに再指定するべきかが分からない場合は、<link linkend="irc-channels">IRC</link> か &email-debian-devel; で聞いてください。再指定するパッケージのメンテナに通知をしてください。例えば <email><replaceable>packagename</replaceable>@packages.debian.org</email> 宛にメッセージを Cc: してメール中に理由を説明するなどします。単に再指定しただけでは再指定された先のメンテナにはメールは<emphasis>送信されません</emphasis>ので、彼らがパッケージのバグ一覧を見るまでそれを知ることはありません。

note: type: Content of: <chapter><section><section><orderedlist><listitem><para>
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) によって関係があることを記載しておく必要があります。

note: type: Content of: <chapter><section><section><orderedlist><listitem><para>
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) に格下げされるでしょう。

note: type: Content of: <chapter><section><section><orderedlist><listitem><para>
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 制御サーバドキュメントを参照してください。

note: type: Content of: <chapter><section><section><orderedlist><listitem><para>
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 <literal>moreinfo</literal> tag to mark the bug as such.  Moreover if you can't reproduce the bug, you tag it <literal>unreproducible</literal>.  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: バグ報告者は情報を書き漏らしている場合、必要な情報を尋ねる必要があります。その様なバグに印をつけるには <literal>moreinfo</literal> タグを使います。さらに、そのバグを再現できない場合には、<literal>unreproducible</literal> タグを付けます。誰もそのバグを再現できない場合、どうやって再現するのか、さらに情報を何ヶ月経っても、この情報が誰からも送られてこない場合はバグは閉じても構いません。

note: type: Content of: <chapter><section><section><orderedlist><listitem><para>
en: If the bug is related to the packaging, you just fix it.  If you are not able to fix it yourself, then tag the bug as <literal>help</literal>.  You can also ask for help on &email-debian-devel; or &email-debian-qa;.  If it's an upstream problem, you have to forward it to the upstream author.  Forwarding a bug is not enough, you have to check at each release if the bug has been fixed or not.  If it has, you just close it, otherwise you have to remind the author about it.  If you have the required skills you can prepare a patch that fixes the bug and send it to the author at the same time.  Make sure to send the patch to the BTS and to tag the bug as <literal>patch</literal>.
ja: バグがパッケージに起因する場合、さっさと直します。自分では直せない場合は、バグに <literal>help</literal> タグを付けます。&email-debian-devel; や &email-debian-qa; で助けを求めることも出来ます。開発元 (upstream) の問題であれば、作者に転送する必要があります。バグを転送するだけでは十分ではありません。リリースごとにバグが修正されているかどうかを確認しなければいけません。もし修正されていれば、それを閉じ、そうでなければ作者に確認を取る必要があります。必要な技能を持っていてバグを修正するパッチが用意できる場合は、同時に作者に送りましょう。パッチを BTS に送付してバグに <literal>patch</literal> タグを付けるのを忘れないでください。

note: type: Content of: <chapter><section><section><orderedlist><listitem><para>
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 <literal>pending</literal> to let people know that the bug is corrected and that it will be closed with the next upload (add the <literal>closes:</literal> in the <filename>changelog</filename>).  This is particularly useful if you are several developers working on the same package.
ja: ローカル環境でバグを修正した、あるいは VCS リポジトリに修正をコミットした場合には、バグに <literal>pending</literal> タグを付けてバグが修正されたことと次のアップロードでバグが閉じられるであろうことを回りに知らせます (<filename>changelog</filename> に <literal>closes:</literal> を追加します)。これは複数の開発者が同一のパッケージで作業している際に特に役立ちます。

note: type: Content of: <chapter><section><section><orderedlist><listitem><para>
en: Once a corrected package is available in the archive, the bug should be closed indicating the version in which it was fixed. This can be done automatically, read <xref linkend="upload-bugfix"/>.
ja: 一旦修正されたパッケージがアーカイブから入手可能になったら、バグはどのバージョンで修正されたかを指定して閉じられる必要があります。これは自動的に行われます。<xref linkend="upload-bugfix"/> を読んでください。

note: type: Content of: <chapter><section><section><title>
en: When bugs are closed by new uploads
ja: 新規アップロードでバグがクローズされる時

note: type: Content of: <chapter><section><section><para>
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 でバグを閉じることができますし、そうしなければいけません。もちろん、バグは正しいバージョンで閉じなくてはいけません。

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

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

note: type: Content of: <chapter><section><section><para>
en: We prefer the <literal>closes: #<replaceable>XXX</replaceable></literal> syntax, as it is the most concise entry and the easiest to integrate with the text of the <filename>changelog</filename>.  Unless specified different by the <literal>-v</literal>-switch to <command>dpkg-buildpackage</command>, only the bugs closed in the most recent changelog entry are closed (basically, exactly the bugs mentioned in the changelog-part in the <filename>.changes</filename> file are closed).
ja: <literal>closes: #<replaceable>XXX</replaceable></literal> という書き方が推奨されています。これは、最も分かり易いエントリで、<filename>changelog</filename> の本文に挿入するのがもっとも簡単だからです。<command>dpkg-buildpackage</command> に <literal>-v</literal> スイッチを指定して別バージョンを指定しない限り、最も新しい changelog のエントリにあるバグだけが閉じられます (基本的には、です。正確には <filename>.changes</filename> ファイルの changelog-part で明示されたバグが閉じられます)。

note: type: Content of: <chapter><section><section><para>
en: Historically, uploads identified as <link linkend="nmu">non-maintainer upload (NMU)</link> were tagged <literal>fixed</literal> instead of being closed, but that practice was ceased with the advent of version-tracking.  The same applied to the tag <literal>fixed-in-experimental</literal>.
ja: 歴史的に、<link linkend="nmu">non-maintainer upload (NMU)</link> と判別されるアップロードは closed ではなく <literal>fixed</literal> とタグがされてきましたが、この習慣はバージョントラッキングの進化によって廃れています。同じことが <literal>fixed-in-experimental</literal> タグにも言えます。

note: type: Content of: <chapter><section><section><para>
en: If you happen to mistype a bug number or forget a bug in the changelog entries, don't hesitate to undo any damage the error caused.  To reopen wrongly closed bugs, send a <literal>reopen <replaceable>XXX</replaceable></literal> command to the bug tracking system's control address, &email-bts-control;.  To close any remaining bugs that were fixed by your upload, email the <filename>.changes</filename> file to <email><replaceable>XXX</replaceable>-done@&bugs-host;</email>, where <replaceable>XXX</replaceable> is the bug number, and put Version: <replaceable>YYY</replaceable> and an empty line as the first two lines of the body of the email, where <replaceable>YYY</replaceable> is the first version where the bug has been fixed.
ja: もしバグ場号を間違って入力したり、changelog のエントリにバグを入れ忘れた場合、そのミスが起こすであろうダメージを防ぐのを躊躇わないでください。誤って閉じたバグを再度オープンにするには、バグトラッキングシステムのコントロールアドレスである &email-bts-control; に <literal>reopen <replaceable>XXX</replaceable></literal> コマンドを投げます。アップロードで修正されたがまだ残っているバグを閉じるには <filename>.changes</filename> ファイルを <email><replaceable>XXX</replaceable>-done@&bugs-host;</email> にメールします。<replaceable>XXX</replaceable> はバグ番号で、メールの本文の最初の 2 行に Version: <replaceable>YYY</replaceable> と空白行を入れます。<replaceable>YYY</replaceable> はバグが修正された最初のバージョンです。

note: type: Content of: <chapter><section><section><para>
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 <email><replaceable>XXX</replaceable>-done@&bugs-host;</email>.  Do <emphasis role="strong">not</emphasis> 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 を使ったバグの閉じ方は必須ではない、ということは念頭に置いておいてください。行ったアップロードとは無関係に単にバグを閉じたい、という場合は、説明をメールに書いて <email><replaceable>XXX</replaceable>-done@&bugs-host;</email> に送ってバグを閉じてください。そのバージョンのパッケージでの変更がバグに何も関係ない場合は、そのバージョンの changelog エントリではバグを<emphasis role="strong">閉じないで</emphasis>ください。

note: type: Content of: <chapter><section><section><para>
en: For general information on how to write your changelog entries, see <xref linkend="bpp-debian-changelog"/>.
ja: どのように changelog のエントリを書くのか、一般的な情報については <xref linkend="bpp-debian-changelog"/> を参照してください。

note: type: Content of: <chapter><section><section><title>
en: Handling security-related bugs
ja: セキュリティ関連バグの取扱い

note: type: Content of: <chapter><section><section><para>
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 <literal>security.debian.org</literal>.
ja: 機密性が高いその性質上、セキュリティ関連のバグは注意深く取り扱わねばなりません。この作業をコーディネイトし、未処理のセキュリティ問題を追い続け、セキュリティ問題についてメンテナを手助けしたり修正自体を行い、セキュリティ勧告を出し、<literal>security.debian.org</literal> を維持するために Debian セキュリティチームが存在します。

note: type: Content of: <chapter><section><section><para>
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 at &email-security-team; as soon as possible.  <emphasis role="strong">DO NOT UPLOAD</emphasis> any packages for <literal>stable</literal> without contacting the team.  Useful information includes, for example:
ja: Debian パッケージ中のセキュリティ関連のバグに気づいたら、あなたがメンテナであるかどうかに関わらず、問題に関する正確な情報を集めて、まずは可能な限り早く &email-security-team; 宛でセキュリティチームに連絡を取ってください。チームに問い合わせること無く <literal>安定版 (stable)</literal> 向けのパッケージを<emphasis role="strong">アップロードしないでください</emphasis>。例えば、役に立つ情報は以下を含んでいます:

note: type: Content of: <chapter><section><section><itemizedlist><listitem><para>
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 <literal>testing</literal> and <literal>unstable</literal>.
ja: バグによって、どのバージョンが影響を受けると分かっているか。サポートされている Debian のリリース、ならびに <literal>テスト版 (testing)</literal> 及び <literal>不安定版 (unstable)</literal> にある各バージョンをチェックしてください。

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

note: type: Content of: <chapter><section><section><itemizedlist><listitem><para>
en: Any fixed packages that you have prepared yourself (send only the <filename>.diff.gz</filename> and <filename>.dsc</filename> files and read <xref linkend="bug-security-building"/> first)
ja: 自身で準備した修正パッケージ (まずは <xref linkend="bug-security-building"/> を読んで、<filename>.diff.gz</filename> と <filename>.dsc</filename> ファイルだけを送ってください)

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

note: type: Content of: <chapter><section><section><itemizedlist><listitem><para>
en: Any information needed for the advisory (see <xref linkend="bug-security-advisories"/>)
ja: 勧告に必要になる情報 (<xref linkend="bug-security-advisories"/> 参照)

note: type: Content of: <chapter><section><section><para>
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: パッケージメンテナとして、あなたは安定版リリースについてもメンテナンスする責任を持ちます。あなたがパッチの評価と更新パッケージのテストを行うのに最も適任な人です。ですから、以下のセキュリティチームによって取り扱ってもらうため、どのようにしてパッケージを用意するかについての章を参照してください。

note: type: Content of: <chapter><section><section><section><title>
en: The Security Tracker
ja: セキュリティ追跡システム

note: type: Content of: <chapter><section><section><section><para>
en: The security team maintains a central database, the <ulink url="http://security-tracker.debian.org/">Debian Security Tracker</ulink>.  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: セキュリティチームは集約的なデータベース、<ulink url="http://security-tracker.debian.org/">Debian セキュリティ追跡システム</ulink>をメンテナンスしています。これはセキュリティ問題として知られている全ての公開情報を含んでいます: どのパッケージ／バージョンが影響を受ける／修正されているか、つまりは安定版、テスト版、不安定版が脆弱かどうか、という情報です。まだ機密扱いの情報は追跡システムには追加されません。

note: type: Content of: <chapter><section><section><section><para>
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: 特定の問題について検索することもできますし、パッケージ名でも検索できます。あなたのパッケージを探して、どの問題がまだ未解決かを確認してください。できれば追加情報を提供するか、パッケージの問題に対処するのを手伝ってください。やり方は追跡システムのウェブページにあります。

note: type: Content of: <chapter><section><section><section><title>
en: Confidentiality
ja: 秘匿性

note: type: Content of: <chapter><section><section><section><para>
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 内での他の多くの活動とは違い、セキュリティ問題に関する情報については、暫くの間秘密にしておく必要がしばしばあります。これによって、ソフトウェアのディストリビュータがユーザが危険にさらされるのを最小限にするため、公開時期を合わせることができます。今回がそうであるかは、問題と対応する修正の性質や、既に既知のものとなっているかどうかによります。

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

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

note: type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
en: someone files a bug report
ja: 誰かがバグ報告を登録している

note: type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
en: someone informs them via private email
ja: 誰かがプライベートなメールで教えてきた

note: type: Content of: <chapter><section><section><section><para>
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: 最初の二つのケースでは、情報は公開されていて可能な限り早く修正することが重要です。しかしながら最後のケースは、公開情報ではないかもしれません。この場合は、問題に対処するのに幾つか取り得る選択肢があります:

note: type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
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: セキュリティの影響度が小さい場合、問題を秘密にしておく必要はなく、修正を行ってリリースするのが良い場合がしばしばあります。

note: type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
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: 問題が深刻な場合、他のベンダと情報を共有してリリースをコーディネイトする方が望ましいでしょう。セキュリティチームは様々な組織／個人と連絡を取りつづけ、この問題に対応することができます。

note: type: Content of: <chapter><section><section><section><para>
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 の安定版リリースに対する修正を作成してもらうためにセキュリティチームへ連絡すること以外、この様な要求は尊重されるべきです。機密情報をセキュリティチームに送る場合は、この点を明示しておくのを忘れないでください。

note: type: Content of: <chapter><section><section><section><para>
en: Please note that if secrecy is needed you may not upload a fix to <literal>unstable</literal> (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: 機密を要する場合は、修正を<literal>不安定版 (unstable)</literal> (や公開 VCS リポジトリなどその他どこへも) へ修正をアップロードしないよう、注意してください。コードその物が公開されている場合、変更の詳細を難読化するだけでは十分ではなく、皆によって解析され得る (そしてされる) でしょう。

note: type: Content of: <chapter><section><section><section><para>
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 つの理由があります: 問題が一定期間既知の状態になっている、あるいは問題や攻撃コードが公開された場合です。

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

note: type: Content of: <chapter><section><section><section><title>
en: Security Advisories
ja: セキュリティ勧告

note: type: Content of: <chapter><section><section><section><para>
en: Security advisories are only issued for the current, released stable distribution, and <emphasis>not</emphasis> for <literal>testing</literal> or <literal>unstable</literal>.  When released, advisories are sent to the &email-debian-security-announce; mailing list and posted on <ulink url="&url-debian-security-advisories;">the security web page</ulink>.  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: セキュリティ勧告は現在のところ、リリースされた安定版ディストリビューションについてのみ、取り扱われます。<literal>テスト版 (testing)</literal> や <literal>不安定版 (unstable)</literal> についてでは<emphasis>ありません</emphasis>。リリースされると、セキュリティ勧告は email-debian-security-announce; メーリングリストに送られ、<ulink url="&url-debian-security-advisories;">セキュリティのウェブページ</ulink>に掲載されます。セキュリティ勧告はセキュリティチームによって記述、掲載されます。しかし、メンテナが情報を提供できたり、文章の一部を書けるのであれば、彼らは当然そんなことは気にしません。勧告にあるべき情報は以下を含んでいます:

note: type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
en: A description of the problem and its scope, including:
ja: 以下のようなものを含めた問題の説明と範囲:

note: type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para>
en: The type of problem (privilege escalation, denial of service, etc.)
ja: 問題の種類 (権限の上昇、サービス拒否など)

note: type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para>
en: What privileges may be gained, and by whom (if any)
ja: 何の権限が得られるのか、(もし分かれば) 誰が得るのか

note: type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para>
en: How it can be exploited
ja: どのようにして攻撃が可能なのか

note: type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para>
en: Whether it is remotely or locally exploitable
ja: 攻撃はリモートから可能なのかそれともローカルから可能なのか

note: type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para>
en: How the problem was fixed
ja: どのようにして問題が修正されたのか

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

note: type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
en: Version numbers of affected packages
ja: 影響を受けるパッケージのバージョン番号

note: type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
en: Version numbers of fixed packages
ja: 修正されたパッケージのバージョン番号

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

note: type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
en: References to upstream advisories, <ulink url="http://cve.mitre.org">CVE</ulink> identifiers, and any other information useful in cross-referencing the vulnerability
ja: 開発元のアドバイザリへの参照、<ulink url="http://cve.mitre.org">CVE</ulink> 番号、脆弱性の相互参照について役立つその他の情報

note: type: Content of: <chapter><section><section><section><title>
en: Preparing packages to address security issues
ja: セキュリティ問題に対処するパッケージを用意する

note: type: Content of: <chapter><section><section><section><para>
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 リリース用のセキュリティ勧告に適した修正版パッケージを提供することです。

note: type: Content of: <chapter><section><section><section><para>
en: When an update is made to the stable release, care must be taken to avoid changing system behavior or introducing new bugs.  In order to do this, make as few changes as possible to fix the bug.  Users and administrators rely on the exact behavior of a release once it is made, so any change that is made might break someone's system.  This is especially true of libraries: make sure you never change the API or ABI, no matter how small the change.
ja: 安定版について更新が作成される際、システムの挙動の変化や新しいバグの導入を避けるように注意が必要です。これを行うため、バグを修正するための変更は可能な限り少なくします。ユーザや管理者は一旦リリースされたものの厳密な挙動を当てにしている、どのような変更でも誰かのシステムを壊しかねません。これは特にライブラリについて当てはまります: API や ABI を決して変更していないことを確認してください。変更がどれほど小さいものでも関係ありません。

note: type: Content of: <chapter><section><section><section><para>
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 セキュリティチームが手助けすることができます。

note: type: Content of: <chapter><section><section><section><para>
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) へ移行する必要があるかもしれません。しかし、これは極端な状況の場合にのみ行われるものであり、実行する前に必ずセキュリティチームと調整をしなければなりません。

note: type: Content of: <chapter><section><section><section><para>
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) が入手可能な場合には、それを試してみて、パッチを当てていないパッケージで成功するか、修正したパッケージでは失敗することかどうかを確かめてみてください。他の確認として、セキュリティ修正は時折表面上はそれと関係が無いような機能を壊すことがあるので、通常の動作も同様にテストしてください。

note: type: Content of: <chapter><section><section><section><para>
en: Do <emphasis role="strong">NOT</emphasis> 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: 脆弱性の修正に直接関係しない変更をパッケージへ<emphasis role="strong">加えない</emphasis>ようにしてください。この様な変更は元に戻さなくてはならなくなるだけで、時間を無駄にします。他に直したいバグがパッケージにある場合は、セキュリティ勧告が発行された後、通常通りに proposed-update にアップロードを行ってください。セキュリティ更新の仕組みは、それ以外の方法では安定版リリースから reject されるであろう変更をあなたのパッケージに加える方法ではありませんので、この様な事はしないでください。

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

note: type: Content of: <chapter><section><section><section><para>
en: Be sure to verify the following items:
ja: 以下の項目を必ず確認してください

note: type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
en: <emphasis role="strong">Target the right distribution</emphasis> in your <filename>debian/changelog</filename>.  For <literal>stable</literal> this is <literal>stable-security</literal> and for <literal>testing</literal> this is <literal>testing-security</literal>, and for the previous stable release, this is <literal>oldstable-security</literal>.  Do not target <replaceable>distribution</replaceable><literal>-proposed-updates</literal> or <literal>stable</literal>!
ja: <filename>debian/changelog</filename> で <emphasis role="strong">正しいディストリビューションを対象にする</emphasis>。<literal>安定版 (stable)</literal> の場合、これは <literal>stable-security</literal> になり、<literal>テスト版 (testing)</literal> の場合は <literal>testing-security</literal> に、そして以前の安定版リリースへの場合は <literal>oldstable-security</literal> となります。<replaceable>distribution</replaceable><literal>-proposed-updates</literal> や <literal>stable</literal> を対象にしないでください!

note: type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
en: The upload should have <emphasis role="strong">urgency=high</emphasis>.
ja: アップロードは <emphasis role="strong">urgency=high</emphasis> で行う必要があります。

note: type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
en: Make descriptive, meaningful changelog entries.  Others will rely on them to determine whether a particular bug was fixed.  Add <literal>closes:</literal> statements for any <emphasis role="strong">Debian bugs</emphasis> filed.  Always include an external reference, preferably a <emphasis role="strong">CVE identifier</emphasis>, 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 エントリを書くこと。他の人は、これらを元に特定のバグが修正されているのかを見つけ出します。登録されている <emphasis role="strong">Debian バグ</emphasis> に対して <literal>closes:</literal> 行を追加すること。外部のリファレンス、できれば <emphasis role="strong">CVE 識別番号</emphasis> を常に含めること、そうすれば相互参照が可能になります。しかし、CVE 識別番号がまだ付与されていない場合には、それを待たずに作業を進めてください。識別番号は後ほど付与することができます。

note: type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
en: Make sure the <emphasis role="strong">version number</emphasis> is proper.  It must be greater than the current package, but less than package versions in later distributions.  If in doubt, test it with <literal>dpkg --compare-versions</literal>.  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 <literal>+</literal><replaceable>codename</replaceable><literal>1</literal>, e.g.  <literal>1:2.4.3-4+lenny1</literal>, of course increasing 1 for any subsequent uploads.
ja: <emphasis role="strong">バージョン番号</emphasis>が正しいことを確認する。現在のパッケージより大きく、しかし以降のディストリビューションよりパッケージバージョンが小さい必要があります。分からない場合は <literal>dpkg --compare-versions</literal> でテストしてください。以前のアップロードで既に使っているバージョン番号を再利用しないように注意してください。そうしないと番号が binNMU と衝突します。<literal>+</literal><replaceable>codename</replaceable><literal>1</literal> を追加するのが通例です。例えば <literal>1:2.4.3-4+lenny1</literal> とします。もちろん 1 はアップロードするごとに増やします。

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

note: type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
en: Be sure to use the <emphasis role="strong">exact same <filename>*.orig.tar.{gz,bz2,lzma}</filename></emphasis> as used in the normal archive, otherwise it is not possible to move the security fix into the main archives later.
ja: 通常のアーカイブで使われているのと<emphasis role="strong">全く同じ <filename>*.orig.tar.{gz,bz2,lzma}</filename></emphasis>を必ず使うようにしてください。さもなくば、後ほどセキュリティ習性を main アーカイブに移動することができません。

note: type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
en: Build the package on a <emphasis role="strong">clean system</emphasis> 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 <xref linkend="server-machines"/>) or setup a chroot (see <xref linkend="pbuilder"/> and <xref linkend="debootstrap"/>).
ja: ビルドを行っているディストリビューションからインストールしたパッケージだけが含まれている<emphasis role="strong">クリーンなシステム上で</emphasis>パッケージをビルドしてください。その様なシステムを自分で持っていない場合は、debian.org マシン (<xref linkend="server-machines"/> を参照してください) を使うこともできますし、chroot を設定することもできます (<xref linkend="pbuilder"/> と <xref linkend="debootstrap"/> を参照してください)。

note: type: Content of: <chapter><section><section><section><title>
en: Uploading the fixed package
ja: 修正したパッケージをアップロードする

note: type: Content of: <chapter><section><section><section><para>
en: Do <emphasis role="strong">NOT</emphasis> upload a package to the security upload queue (<literal>oldstable-security</literal>, <literal>stable-security</literal>, etc.) without prior authorization from the security team.  If the package does not exactly meet the team's requirements, it will cause many problems and delays in dealing with the unwanted upload.
ja: セキュリティアップロードキュー (<literal>oldstable-security</literal>、<literal>stable-security </literal> 等) には、セキュリティチームからの事前許可無しにパッケージを<emphasis role="strong">アップロードしないでください</emphasis>。パッケージがチームの要求に完全に合致していない場合、望まれないアップロードに対処するために多くの問題が引き起こされたり遅延が生じることになります。詳細については <xref linkend="bug-security"/> を参照してください。

note: type: Content of: <chapter><section><section><section><para>
en: Do <emphasis role="strong">NOT</emphasis> upload your fix to <literal>proposed-updates</literal> without coordinating with the security team.  Packages from <literal>security.debian.org</literal> will be copied into the <literal>proposed-updates</literal> 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: セキュリティチームと調整する事無しに <literal>proposed-updates</literal> へ修正したものをアップロード<emphasis role="strong">しない</emphasis>ようにしてください。<literal>security.debian.org</literal> からパッケージは <literal>proposed-updates</literal> ディレクトリに自動的にコピーされます。アーカイブに同じ、あるいはより高いバージョン番号のものが既にインストールされている場合は、セキュリティアップデートはアーカイブシステムに reject されます。そうすると、安定版ディストリビューションはこのパッケージに対するセキュリティ更新無しで終了してしまうでしょう。

note: type: Content of: <chapter><section><section><section><para>
en: Once you have created and tested the new package and it has been approved by the security team, it needs to be uploaded so that it can be installed in the archives.  For security uploads, the place to upload to is <literal>ftp://security-master.debian.org/pub/SecurityUploadQueue/</literal>.
ja: 一旦、新しいパッケージを作成してテストし、セキュリティチームによって許可を受けたら、アーカイブへインストールできるようにするためにアップロードをする必要があります。セキュリティに関するアップロードの場合、アップロード先は <literal>ftp://security-master.debian.org/pub/SecurityUploadQueue/</literal> になります。

note: type: Content of: <chapter><section><section><section><para>
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: セキュリティキューへアップロードしたものが許可されると、パッケージは自動的にすべてのアーキテクチャに対してビルドされ、セキュリティチームによる確認の為に保存されます。

note: type: Content of: <chapter><section><section><section><para>
en: Uploads which are waiting for acceptance or verification are only accessible by the security team.  This is necessary since there might be fixes for security problems that cannot be disclosed yet.
ja: 許可、あるいは確認を待っているアップロードには、セキュリティチームのみがアクセスできます。これは、まだ公開できないセキュリティ問題の修正があるかも知れないためです。

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

note: type: Content of: <chapter><section><title>
en: Moving, removing, renaming, adopting, and orphaning packages
ja: パッケージの移動、削除、リネーム、変更、みなしご化

note: type: Content of: <chapter><section><para>
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 のアップロードプロセスでは自動的なものにはなっていません。これらの手続きはメンテナによる手動での作業である必要があります。この章では、この様な場合に何をするかのガイドラインを提供します。

note: type: Content of: <chapter><section><section><title>
en: Moving packages
ja: パッケージの移動

note: type: Content of: <chapter><section><section><para><footnote><para>
en: See the <ulink url="&url-debian-policy;">Debian Policy Manual</ulink> for guidelines on what section a package belongs in.
ja: パッケージがどのセクションに属するかのガイドラインは <ulink url="&url-debian-policy;">Debian ポリシーマニュアル</ulink>を参照してください。

note: type: Content of: <chapter><section><section><para>
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'.<placeholder type="footnote" id="0"/>
ja: 時折パッケージは属しているセクションが変わることがあります。例えば「non-free」セクションのパッケージが新しいバージョンで GPL になった場合、パッケージは「main」か「contrib」に移動する必要があります。<placeholder type="footnote" id="0"/>

note: type: Content of: <chapter><section><section><para>
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 <ulink url="&url-debian-policy;">Debian Policy Manual</ulink> for details).  You must ensure that you include the <filename>.orig.tar.{gz,bz2,lzma}</filename> 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 情報を変更してから再アップロードします (詳細については <ulink url="&url-debian-policy;">Debian ポリシーマニュアル</ulink>を参照してください)。必ず <filename>.orig.tar.{gz,bz2,lzma}</filename> を (開発元のバージョンが新しいものになったのではなくても) アップロードに含める必要があります。新しいセクションが正しい場合は、自動的に移動されます。移動されない場合には、何が起こったのかを理解するために ftpmaster に連絡を取ります。

note: type: Content of: <chapter><section><section><title>
en: Removing packages
ja: パッケージの削除

note: type: Content of: <chapter><section><section><para>
en: If for some reason you want to completely remove a package (say, if it is an old compatibility library which is no longer required), you need to file a bug against <literal>ftp.debian.org</literal> asking that the package be removed; as all bugs, this bug should normally have normal severity.  The bug title should be in the form <literal>RM: <replaceable>package</replaceable> <replaceable>[architecture list]</replaceable> -- <replaceable>reason</replaceable></literal>, where <replaceable>package</replaceable> is the package to be removed and <replaceable>reason</replaceable> is a short summary of the reason for the removal request.  <replaceable>[architecture list]</replaceable> is optional and only needed if the removal request only applies to some architectures, not all. Note that the <command>reportbug</command> will create a title conforming to these rules when you use it to report a bug against the <literal>ftp.debian.org</literal> pseudo-package.
ja: 何らかの理由でパッケージを完全に削除したくなった場合 (もう必要がなくなった古い互換用ライブラリの場合、など)、パッケージを削除するよう <literal>ftp.debian.org</literal> に対してバグ登録をする必要があります; すべてのバグ同様、通常このバグは重要度 normal です。バグの題名は <literal>RM: <replaceable>パッケージ名</replaceable> <replaceable>[アーキテクチャ一覧]</replaceable> -- <replaceable>理由</replaceable></literal> という形式である必要があります。<replaceable>パッケージ名</replaceable>は削除されるパッケージ、<replaceable>理由</replaceable>は削除を依頼する理由の短い要約です。<replaceable>[アーキテクチャ一覧]</replaceable>はオプションで、削除依頼が全アーキテクチャではなく一部のアーキテクチャのみに適用される場合にのみ、必要となります。<command>reportbug</command> は <literal>ftp.debian.org</literal> 擬似パッケージに対してバグを報告しようとした場合に、これらのルールに則ってバグの題名を作成しようとすることに注意してください。

note: type: Content of: <chapter><section><section><para>
en: If you want to remove a package you maintain, you should note this in the bug title by prepending <literal>ROM</literal> (Request Of Maintainer).  There are several other standard acronyms used in the reasoning for a package removal, see <ulink url="http://&ftp-master-host;/removals.html"></ulink> for a complete list. That page also provides a convenient overview of pending removal requests.
ja: あなたがメンテナンスしているパッケージを削除したくなった場合は、題名の先頭に <literal>ROM</literal> (Request Of Maintainer) という文字を付けたバグにこれを記述する必要があります。パッケージの削除理由に使われる他の一般的な略語が幾つかありますので、完全な一覧については <ulink url="http://&ftp-master-host;/removals.html"></ulink> を参照してください。このページでは、まだ作業されていない削除依頼の便利な一覧も見ることができます。

note: type: Content of: <chapter><section><section><para>
en: Note that removals can only be done for the <literal>unstable</literal>, <literal>experimental</literal> and <literal>stable</literal> distribution.  Packages are not removed from <literal>testing</literal> directly.  Rather, they will be removed automatically after the package has been removed from <literal>unstable</literal> and no package in <literal>testing</literal> depends on it.
ja: 削除は<literal>不安定版 (unstable)</literal>、<literal>実験版 (experimental)</literal>、<literal>安定版 (stable)</literal> ディストリビューションに対してのみ実施が可能であることに注意してください。パッケージは <literal>テスト版 (testing)</literal> から直接は削除されません。代わりに<literal>不安定版 (unstable)</literal> から削除された後で自動的に削除され、<literal>テスト版 (testing)</literal> にあるパッケージは削除されたパッケージに依存しなくなります。

note: type: Content of: <chapter><section><section><section><title>
en: Removing packages from <filename>Incoming</filename>
ja: <filename>Incoming</filename> からパッケージを削除する

note: type: Content of: <chapter><section><section><section><para>
en: In the past, it was possible to remove packages from <filename>incoming</filename>.  However, with the introduction of the new incoming system, this is no longer possible.  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 <literal>unstable</literal> 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: 以前は、<filename>incoming</filename> からパッケージを削除することが可能でした。しかし、新しい incoming システムが導入されたことにより、これはもはや不可能となっています。その代わりに、置き換えたいパッケージよりも高いバージョンのリビジョンの新しいパッケージをアップロードする必要があります。両方のバージョンのパッケージがアーカイブにインストールされますが、一つ前のバージョンはすぐに高いバージョンで置き換えられるため、実際にはバージョンが高い方だけが <literal>不安定版 (unstable)</literal> で利用可能になります。しかし、もしあなたがパッケージをきちんとテストしていれば、パッケージを置き換える必要はそんなに頻繁には無いはずです。

note: type: Content of: <chapter><section><section><title>
en: Replacing or renaming packages
ja: パッケージをリプレースあるいはリネームする

note: type: Content of: <chapter><section><section><title>
en: Orphaning a package
ja: パッケージをみなしご化する

note: type: Content of: <chapter><section><section><para>
en: More information is on the <ulink url="&url-wnpp;">WNPP web pages</ulink>.
ja: より詳細な情報は <ulink url="&url-wnpp;">WNPP ウェブページ</ulink>にあります。

note: type: Content of: <chapter><section><section><title>
en: Adopting a package
ja: パッケージに変更を加える

note: type: Content of: <chapter><section><para>
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 がサポートするアーキテクチャの数は増え続けています。あなたが移植作業者ではない、あるいは別のアーキテクチャを使うことが無いという場合であっても、移植性の問題に注意を払うことはメンテナとしてのあなたの義務です。従って、あなたが移植作業者でなくても、この章の大半を読む必要があります。

note: type: Content of: <chapter><section><section><orderedlist><listitem><para>
en: If you can't set up a proper chroot, <command>dpkg-depcheck</command> may be of assistance (see <xref linkend="dpkg-depcheck"/>).
ja: chroot を正しく設定できない場合は、<command>dpkg-depcheck</command> が手助けになることでしょう (<xref linkend="dpkg-depcheck"/> 参照)。

note: type: Content of: <chapter><section><section><orderedlist><listitem><para>
en: See the <ulink url="&url-debian-policy;">Debian Policy Manual</ulink> for instructions on setting build dependencies.
ja: ビルドの依存情報の指定方法については、<ulink url="&url-debian-policy;">Debian ポリシーマニュアル</ulink>を参照してください。

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

note: type: Content of: <chapter><section><section><section><title>
en: Recompilation or binary-only NMU
ja: 再コンパイル、あるいは binary-only NMU

note: type: Content of: <chapter><section><section><section><title>
en: Mailing lists and web pages
ja: メーリングリストとウェブページ

note: type: Content of: <chapter><section><section><section><para>
en: Web pages containing the status of each port can be found at <ulink url="&url-debian-ports;"></ulink>.
ja: 各移植版についての状況を含んだウェブページは <ulink url="&url-debian-ports;"></ulink> から参照できます。

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

note: type: Content of: <chapter><section><section><section><title>
en: Porter tools
ja: 移植用ツール

note: type: Content of: <chapter><section><section><section><para>
en: Descriptions of several porting tools can be found in <xref linkend="tools-porting"/>.
ja: 移植用のツールの説明をいくつか <xref linkend="tools-porting"/> で見ることができます。

note: type: Content of: <chapter><section><section><title>
en: When your package is <emphasis>not</emphasis> portable
ja: あなたのパッケージが移植可能なものでは<emphasis>ない</emphasis>場合

note: type: Content of: <chapter><section><title>
en: Non-Maintainer Uploads (NMUs)
ja: Non-Maintainer Upload (NMU)

note: type: Content of: <chapter><section><section><title>
en: When and how to do an NMU
ja: いつ、どうやって NMU を行うか

note: type: Content of: <chapter><section><section><para>
en: Before doing an NMU, consider the following questions:
ja: NMU を行う前に、以下の質問について考えてください:

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

note: type: Content of: <chapter><section><section><itemizedlist><listitem><para>
en: Upload fixing only release-critical and important bugs: 5 days
ja: リリースクリティカルバグや重要なバグの修正のみのアップロード: 5 日

note: type: Content of: <chapter><section><section><itemizedlist><listitem><para>
en: Other NMUs: 10 days
ja: 他の NMU: 10 日

note: type: Content of: <chapter><section><section><title>
en: NMUs and <filename>debian/changelog</filename>
ja: NMU と <filename>debian/changelog</filename>

note: type: Content of: <chapter><section><section><title>
en: Using the <literal>DELAYED/</literal> queue
ja: <literal>DELAYED/</literal> キューを使う

note: type: Content of: <chapter><section><section><title>
en: NMUs from the maintainer's point of view
ja: メンテナの視点から見た NMU

note: type: Content of: <chapter><section><section><title>
en: Source NMUs vs Binary-only NMUs (binNMUs)
ja: ソース NMU vs バイナリのみの NMU (binNMU)

note: type: Content of: <chapter><section><section><title>
en: NMUs vs QA uploads
ja: NMU vs QA アップロード

note: type: Content of: <chapter><section><section><title>
en: NMUs vs team uploads
ja: NMU vs チームアップロード

note: type: Content of: <chapter><section><title>
en: Collaborative maintenance
ja: 共同メンテナンス

note: type: Content of: <chapter><section><title>
en: The testing distribution
ja: テスト版ディストリビューション

note: type: Content of: <chapter><section><section><title>
en: Basics
ja: 基本

note: type: Content of: <chapter><section><section><title>
en: Updates from unstable
ja: 不安定版からの更新

note: type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry>
en: testing
ja: テスト版

note: type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry>
en: unstable
ja: 不安定版

note: type: Content of: <chapter><section><section><section><title>
en: Removals from testing
ja: テスト版からの削除

note: type: Content of: <chapter><section><section><section><title>
en: Circular dependencies
ja: 循環依存

note: type: Content of: <chapter><section><section><section><para>
en: An example of this is:
ja: この場合の例:

note: type: Content of: <chapter><section><section><section><title>
en: Influence of package in testing
ja: テスト版 (testing) にあるパッケージへの影響

note: type: Content of: <chapter><section><section><section><title>
en: Details
ja: 詳細について

note: type: Content of: <chapter><section><section><title>
en: Direct updates to testing
ja: 直接テスト版を更新する

note: type: Content of: <chapter><section><section><itemizedlist><listitem><para>
en: Make sure that you included only the minimal amount of changes;
ja: 必ず最小限な量だけの変更を含めるようにする;

note: type: Content of: <chapter><section><section><title>
en: Frequently asked questions
ja: よく聞かれる質問とその答え (FAQ)

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

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

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

note: type: Content of: <chapter><section><section><section><para>
en: The <literal>unstable</literal> bug count are all release-critical bugs which are marked to apply to <replaceable>package</replaceable>/<replaceable>version</replaceable> combinations that are available in unstable for a release architecture. The <literal>testing</literal> bug count is defined analogously.
ja: <literal>不安定版 (unstable)</literal> でのバグのカウント数は、リリース対象アーキテクチャの不安定版 (unstable) で利用可能な<replaceable>パッケージ</replaceable>/<replaceable>バージョン</replaceable>の組み合わせに適用されるとマークされたすべてのリリースクリティカルバグです。<literal>テスト版 (testing)</literal> のバグのカウント数も同様に定義します。

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

note: type: Content of: <chapter><section><section><section><para>
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 <literal>acmefoo</literal> is installed into <literal>testing</literal>, along with its binary packages <literal>acme-foo-bin</literal>, <literal>acme-bar-bin</literal>, <literal>libacme-foo1</literal> and <literal>libacme-foo-dev</literal>, the old version is removed.
ja: ディストリビューションにおけるアーカイブの構造では、一つのバージョンのパッケージだけを持つことができ、パッケージは名前によって定義されています。そのため、ソースパッケージ <literal>acmefoo</literal> が<literal>テスト版 (testing)</literal> にインストールされると、付随するバイナリパッケージ <literal>acme-foo-bin</literal>、<literal>acme-bar-bin</literal>、<literal>libacme-foo1</literal>、<literal>libacme-foo-dev</literal> の古いバージョンが削除されます。

note: type: Content of: <chapter><section><section><section><para>
en: However, the old version may have provided a binary package with an old soname of a library, such as <literal>libacme-foo0</literal>.  Removing the old <literal>acmefoo</literal> will remove <literal>libacme-foo0</literal>, which will break any packages which depend on it.
ja: しかし、古いバージョンではライブラリに古い soname を含んだ <literal>libacme-foo0</literal> のようなバイナリパッケージを提供しているかもしれません。古い <literal>acmefoo</literal> を削除するのは <literal>libacme-foo0</literal> を削除することになり、これに依存しているパッケージを壊してしまいます。

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