0 - en to ja translation catalogue (107 entries)

en: Backport
ja: バックポート

en: Rebuild
ja: 再ビルド

en: Source package
ja: ソースパッケージ

en: Archive
ja: アーカイブ

en: Meta-package
ja: メタパッケージ

en: Debian Developer
ja: Debian 開発者

en: Maintainer
ja: メンテナ

en: Creating a Debian Package
ja: Debian パッケージの作成

en: It is quite common, for an administrator who has been handling Debian packages in a regular fashion, to eventually feel the need to create their own packages, or to modify an existing package. This chapter aims to answer the most common questions in this field, and provide the required elements to take advantage of the Debian infrastructure in the best way. With any luck, after trying your hand for local packages, you may even feel the need to go further than that and join the Debian project itself!
ja: Debian パッケージを標準的な方法で取り扱ってきた管理者がいずれは自分自身のパッケージを作成したり、既存のパッケージを変更したりする必要性を感じるということは極めて普通のことです。この章ではパッケージングに関する最も一般的な質問に答えたり、最良のやり方で Debian インフラをうまく使うために必要な要素を提供したりすることを目標にしています。運が良ければ、ローカルパッケージを取り扱った後、さらに進んで Debian プロジェクト自体に参加する必要性を感じるかもしれません。

en: Rebuilding a Package from its Sources
ja: ソースを使ったパッケージの再ビルド

en: Rebuilding a binary package is required under several sets of circumstances. In some cases, the administrator needs a software feature that requires the software to be compiled from sources, with a particular compilation option; in others, the software as packaged in the installed version of Debian is not recent enough. In the latter case, the administrator will usually build a more recent package taken from a newer version of Debian — such as <emphasis role="distribution">Testing</emphasis> or even <emphasis role="distribution">Unstable</emphasis> — so that this new package works in their <emphasis role="distribution">Stable</emphasis> distribution; this operation is called “backporting”. As usual, care should be taken, before undertaking such a task, to check whether it has been done already — a quick look on the Debian Package Tracker for that package will reveal that information. <ulink type="block" url="https://tracker.debian.org/" /> <indexterm><primary>backport</primary></indexterm>
ja: いくつかの状況下では、バイナリパッケージの再ビルドが必要です。たとえば、管理者は特定のコンパイルオプションを付けてソフトウェアをソースからコンパイルすることで導入されるソフトウェアの機能を必要とする場合があります。そしてまた、インストール済みの Debian のバージョン用にパッケージングされたソフトウェアのバージョンが古い場合があります。ソフトウェアのバージョンが古い場合、管理者は<emphasis role="distribution">テスト版</emphasis>や<emphasis role="distribution">不安定版</emphasis>などの Debian の新しいバージョンから取得したより新しいパッケージをビルドすることが多いです。こうすることで、新しいパッケージを<emphasis role="distribution">安定版</emphasis>ディストリビューションで動かすことが可能です。この操作は「バックポート」と呼ばれています。いつも通り、バックポート作業の前に既にバックポートパッケージが公開されているか否かを注意深く確認するべきです。対象のパッケージに対する Debian Package Tracker を一読するだけでこの種の情報が明らかになります。<ulink type="block" url="https://tracker.debian.org/" /><indexterm><primary>バックポート</primary></indexterm>

en: Getting the Sources
ja: ソースの取得

en: Making Changes
ja: 修正を行う

en: Depending on the local changes to the packages, an update may also be required in the <filename>debian/control</filename> file, which contains a description of the generated packages. In particular, this file contains <literal>Build-Depends</literal> lines controlling the list of dependencies that must be fulfilled at package build time. These often refer to versions of packages contained in the distribution the source package comes from, but which may not be available in the distribution used for the rebuild. There is no automated way to determine if a dependency is real or only specified to guarantee that the build should only be attempted with the latest version of a library — this is the only available way to force an <emphasis>autobuilder</emphasis> to use a given package version during build, which is why Debian maintainers frequently use strictly versioned build-dependencies.
ja: パッケージに対して行った変更の内容によっては、<filename>debian/control</filename> ファイルの内容もまた更新する必要があります。<filename>debian/control</filename> ファイルには生成されるパッケージの説明が含まれます。特に、<filename>debian/control</filename> ファイルにはパッケージのビルド時点で満足されなければいけない依存関係のリストを制御する <literal>Build-Depends</literal> 行が含まれます。<literal>Build-Depends</literal> 行で指定されているパッケージのバージョンはソースパッケージが提供されるディストリビューションに含まれるパッケージのバージョンと一致している場合が多いです。しかし、再ビルドを行うディストリビューションではここで指定されているバージョンが利用できないかもしれません。依存関係が本物か、それともビルド時にライブラリの最新版を試すことを保証するためだけ指定されているかを決定する自動的な方法はありません。<literal>Build-Depends</literal> 行を使うことが<emphasis>自動ビルドロボット</emphasis>にビルド中に与えられたパッケージバージョンを使うことを強制するための唯一の方法なので、Debian メンテナはバージョンを厳しく指定したビルド依存関係を使うことが多いです。

en: If you know for sure that these build-dependencies are too strict, you should feel free to relax them locally. Reading the files which document the standard way of building the software — these files are often called <filename>INSTALL</filename> — will help you figure out the appropriate dependencies. Ideally, all dependencies should be satisfiable from the distribution used for the rebuild; if they are not, a recursive process starts, whereby the packages mentioned in the <literal>Build-Depends</literal> field must be backported before the target package can be. Some packages may not need backporting, and can be installed as-is during the build process (a notable example is <emphasis role="pkg">debhelper</emphasis>). Note that the backporting process can quickly become complex if you are not careful. Therefore, backports should be kept to a strict minimum when possible.
ja: もしあなたが、指定されているビルド依存関係を緩めても問題ないと確信できる場合、手元で自由に依存関係を緩和することが可能です。対象のソフトウェアをビルドする標準的な方法について説明しているファイル (<filename>INSTALL</filename> と名付けられていることが多いです) を読むことは適切な依存関係を明らかにする助けになります。理想的に言えば、再ビルドに使うディストリビューションの要素を使ってすべての依存関係を満足させるべきです。しかしそれが無理ならば、対象のパッケージをバックポートする前に、再帰的に <literal>Build-Depends</literal> フィールドで言及されているパッケージを必ずバックポートしなければいけません。一部のパッケージはバックポートの必要がなく、ビルド作業中に現状のままインストールできます (特筆すべき例は <emphasis role="pkg">debhelper</emphasis> です)。バックポート作業は気を付けないとすぐに複雑になる点に注意してください。それゆえ、バックポートは可能な限り厳密に必要最低限に留めるべきです。

en: <emphasis>TIP</emphasis> Installing <literal>Build-Depends</literal>
ja: <emphasis>TIP</emphasis> <literal>Build-Depends</literal> のインストール

en: Starting the Rebuild
ja: 再ビルドの開始

en: When all the needed changes have been applied to the sources, we can start generating the actual binary package (<filename>.deb</filename> file). The whole process is managed by the <command>dpkg-buildpackage</command> command.
ja: ソースに対するすべての必要な変更が完了したら、実際のバイナリパッケージ (<filename>.deb</filename> ファイル) を生成します。すべてのプロセスは <command>dpkg-buildpackage</command> コマンドで管理されます。

en: Rebuilding a package
ja: パッケージの再ビルド

en: In essence, the package creation process is a simple matter of gathering in an archive a set of existing (or built) files; most of the files will end up being owned by <emphasis>root</emphasis> in the archive. However, building the whole package under this user would imply increased risks; fortunately, this can be avoided with the <command>fakeroot</command> command. This tool can be used to run a program and give it the impression that it runs as <emphasis>root</emphasis> and creates files with arbitrary ownership and permissions. When the program creates the archive that will become the Debian package, it is tricked into creating an archive containing files marked as belonging to arbitrary owners, including <emphasis>root</emphasis>. This setup is so convenient that <command>dpkg-buildpackage</command> uses <command>fakeroot</command> by default when building packages.
ja: 基本的に、パッケージ作成作業とは存在する (ビルドされた) ファイル群を 1 つのアーカイブにまとめるという単純な作業に過ぎません。さらにほとんどのファイルは最終的にアーカイブ中で <emphasis>root</emphasis> によって所有されることになります。しかしながら、パッケージ全体を root で作ると暗黙のうちにリスクが増加します。しかし幸いなことに、<command>fakeroot</command> コマンドを使うことでこれを避けることが可能です。<command>fakeroot</command> 環境を使うことで、プログラムを実行したり、プログラムに自分の実行者が <emphasis>root</emphasis> であり任意の所有者とパーミッションを持つファイルを作成することが可能であると認識させたりすることが可能になります。<command>fakeroot</command> 環境下で Debian パッケージとなるアーカイブを作成した場合、<command>fakeroot</command> プログラムは <emphasis>root</emphasis> およびその他のユーザに所有されるファイルを含むアーカイブを作成します。<command>dpkg-buildpackage</command> がパッケージをビルドする際にデフォルトで <command>fakeroot</command> を使っていることからも分かる通り、<command>fakeroot</command> 環境下でパッケージをビルドすることはとても便利な方法です。

en: Note that the program is only tricked into “believing” that it operates as a privileged account, and the process actually runs as the user running <command>fakeroot <replaceable>program</replaceable></command> (and the files are actually created with that user's permissions). At no time does it actually get root privileges that it could abuse.
ja: <command>fakeroot</command> 環境下で動作するプログラムはだまされて特権アカウントとして操作するように「信じこまされる」だけです。プロセスは <command>fakeroot <replaceable>program</replaceable></command> を実行しているユーザの権限で実行されます (作成されるファイルはそのユーザのパーミッションを与えられます)。fakeroot が実際に root 権限を取得してそれを乱用することは決してありません。

en: Building your First Package
ja: 最初のパッケージのビルド

en: Meta-Packages or Fake Packages
ja: メタパッケージやフェイクパッケージ

en: Fake packages and meta-packages are similar, in that they are empty shells that only exist for the effects their meta-data have on the package handling stack.
ja: フェイクパッケージとメタパッケージは似ています。両者は自分のメタデータをパッケージ取り扱いスタックに置いておくためだけに存在する抜け殻です。

en: On the other hand, a meta-package exists mostly as a collection of dependencies, so that installing the meta-package will actually bring in a set of other packages in a single step.
ja: 逆に、メタパッケージはメタパッケージをインストールするだけで一連の他のパッケージをインストールすることが可能になる依存関係の集合体として使われます。

en: Both these kinds of packages can be created by the <command>equivs-control</command> and <command>equivs-build</command> commands (in the <emphasis role="pkg">equivs</emphasis> package). The <command>equivs-control <replaceable>file</replaceable></command> command creates a Debian package header file that should be edited to contain the name of the expected package, its version number, the name of the maintainer, its dependencies, and its description. Other fields without a default value are optional and can be deleted. The <literal>Copyright</literal>, <literal>Changelog</literal>, <literal>Readme</literal> and <literal>Extra-Files</literal> fields are not standard fields in Debian packages; they only make sense within the scope of <command>equivs-build</command>, and they will not be kept in the headers of the generated package.
ja: フェイクパッケージとメタパッケージは <command>equivs-control</command> と <command>equivs-build</command> コマンド (<emphasis role="pkg">equivs</emphasis> パッケージに含まれます) を使って作成されます。<command>equivs-control <replaceable>file</replaceable></command> コマンドは Debian パッケージヘッダファイルを作成します。Debian パッケージヘッダファイルには、パッケージの名前、バージョン番号、メンテナ、依存関係、説明を含めるように編集します。デフォルト値を持たない他のフィールドは任意で、削除することも可能です。<literal>Copyright</literal>、<literal>Changelog</literal>、<literal>Readme</literal>、<literal>Extra-Files</literal> フィールドは Debian パッケージの標準的なフィールドではありません。さらに、これらのフィールドは <command>equivs-build</command> を使う限りにおいて意味を持つものであり、生成されるパッケージのヘッダから削除されます。

en: Header file of the <emphasis>libxml-libxml-perl</emphasis> fake package
ja: <emphasis>libxml-libxml-perl</emphasis> フェイクパッケージのヘッダファイル

en: The next step is to generate the Debian package with the <command>equivs-build <replaceable>file</replaceable></command> command. Voilà: the package is created in the current directory and it can be handled like any other Debian package would.
ja: 次のステップでは、<command>equivs-build <replaceable>file</replaceable></command> コマンドを使って Debian パッケージを生成します。さぁこれでパッケージは現在のディレクトリに作成され、他の Debian パッケージと同様に取り扱うことが可能になります。

en: Simple File Archive
ja: 単純なファイルアーカイブ

en: The Falcot Corp administrators need to create a Debian package in order to ease deployment of a set of documents on a large number of machines. The administrator in charge of this task first reads the “New Maintainer's Guide”, then starts working on their first package. <ulink type="block" url="https://www.debian.org/doc/manuals/maint-guide/" />
ja: Falcot Corp の管理者は大量のマシン上に一連の文書を配備することを簡単に行うために Debian パッケージを作成する必要があります。この作業を担当している管理者は最初に「新メンテナーガイド」を読み、その後最初のパッケージに対する作業に着手します。<ulink type="block" url="https://www.debian.org/doc/manuals/maint-guide/" />

en: The first step is creating a <filename>falcot-data-1.0</filename> directory to contain the target source package. The package will logically, be named <literal>falcot-data</literal> and bear the <literal>1.0</literal> version number. The administrator then places the document files in a <filename>data</filename> subdirectory. Then they invoke the <command>dh_make</command> command (from the <emphasis role="pkg">dh-make</emphasis> package) to add files required by the package generation process, which will all be stored in a <filename>debian</filename> subdirectory:
ja: 最初に、対象のソースパッケージを含める <filename>falcot-data-1.0</filename> ディレクトリを作成します。こうしておけば、パッケージは必然的に <literal>falcot-data</literal> と名付けられ、バージョン番号は <literal>1.0</literal> になります。その後、管理者は文書ファイルを <filename>data</filename> サブディレクトリに置きます。その後、管理者は <command>dh_make</command> コマンド (<emphasis role="pkg">dh-make</emphasis> パッケージに含まれます) を実行し、パッケージ生成作業に必要なファイルを追加します。ここで追加されるファイルは <filename>debian</filename> サブディレクトリに保存されます。

en: <primary>package</primary><secondary>types</secondary>
ja: <primary>パッケージ</primary><secondary sortas="シュルイ">種類</secondary>

en: <emphasis>TIP</emphasis> Maintainer's name and email address
ja: <emphasis>TIP</emphasis> メンテナの名前と電子メールアドレス

en: Most of the programs involved in package maintenance will look for your name and email address in the <varname>DEBFULLNAME</varname> and <varname>DEBEMAIL</varname> or <varname>EMAIL</varname> environment variables. Defining them once and for all will avoid you having to type them multiple times. If your usual shell is <command>bash</command>, it is a simple matter of adding the following two lines in your <filename>~/.bashrc</filename> file (you will obviously replace the values with more relevant ones!):
ja: パッケージメンテナンスに関わるほとんどのプログラムはメンテナの名前と電子メールアドレスを <varname>DEBFULLNAME</varname> と <varname>DEBEMAIL</varname> または <varname>EMAIL</varname> 環境変数から取得します。たった 1 回これらの環境変数を定義するだけで、毎回これらの情報を打ち込む必要がなくなります。通常のシェルが <command>bash</command> の場合、<filename>~/.bashrc</filename> ファイルに以下の 2 行 (当然ですが、値を自分のものに変えてください!) を追加するだけで簡単にこれを行うことが可能です。

en: The <filename>control</filename> file
ja: <filename>control</filename> ファイル

en: The <filename>changelog</filename> file
ja: <filename>changelog</filename> ファイル

en: The <filename>copyright</filename> file
ja: <filename>copyright</filename> ファイル

en: <emphasis>BACK TO BASICS</emphasis> <filename>Makefile</filename> file
ja: <emphasis>BACK TO BASICS</emphasis> <filename>Makefile</filename> ファイル

en: A <filename>Makefile</filename> file is a script used by the <command>make</command> program; it describes rules for how to build a set of files from each other in a tree of dependencies (for instance, a program can be built from a set of source files). The <filename>Makefile</filename> file describes these rules in the following format:
ja: <filename>Makefile</filename> ファイルは <command>make</command> プログラムによって使われるスクリプトであり、互いに依存関係を持つファイル群をビルドする規則を指定します (たとえば、複数のソースファイル群から 1 つのプログラムをビルドする規則を指定します)。<filename>Makefile</filename> ファイルはビルド規則を以下のフォーマットで指定します。

en: Note that the command lines must start with a tab character; also note that when a command line starts with a dash character (<literal>-</literal>), failure of the command does not interrupt the whole process.
ja: コマンド行は必ずタブ文字で開始しなければいけない点に注意してください。さらに、コマンド行がダッシュ文字 (<literal>-</literal>) で始まる場合、そのコマンドが失敗しても全体のプロセスは停止されなくなる点に注意してください。

en: The <filename>rules</filename> file usually contains a set of rules used to configure, build and install the software in a dedicated subdirectory (named after the generated binary package). The contents of this subdirectory is then archived within the Debian package as if it were the root of the filesystem. In our case, files will be installed in the <filename>debian/falcot-data/usr/share/falcot-data/</filename> subdirectory, so that installing the generated package will deploy the files under <filename>/usr/share/falcot-data/</filename>. The <filename>rules</filename> file is used as a <filename>Makefile</filename>, with a few standard targets (including <literal>clean</literal> and <literal>binary</literal>, used respectively to clean the source directory and generate the binary package).
ja: <filename>rules</filename> ファイルには、(生成されるバイナリパッケージにちなんで名付けられた) 専用のサブディレクトリ内で対象のソフトウェアを設定、ビルド、インストールするために使われる一連の規則が定義されています。このサブディレクトリの内容はあたかもサブディレクトリがファイルシステムのルートであるかのように Debian パッケージの中に保存されます。今回の場合、ファイルは <filename>debian/falcot-data/usr/share/falcot-data/</filename> サブディレクトリにインストールされます。こうすることで、生成されたパッケージをインストールするとファイルが <filename>/usr/share/falcot-data/</filename> の下に配備されます。<filename>rules</filename> ファイルはいくつかの標準的なターゲットが定義されている <filename>Makefile</filename> として使われます (定義済みターゲットの <literal>clean</literal> と <literal>binary</literal> はそれぞれソースディレクトリを削除する場合とバイナリパッケージを生成する場合に使います)。

en: Although this file is the heart of the process, it increasingly contains only the bare minimum for running a standard set of commands provided by the <command>debhelper</command> tool. Such is the case for files generated by <command>dh_make</command>. To install our files, we simply configure the behavior of the <command>dh_install</command> command by creating the following <filename>debian/falcot-data.install</filename> file:
ja: <filename>rules</filename> ファイルはビルド作業の核心で、<command>debhelper</command> ツールによって提供される標準的なコマンド群を実行するために必要な最低限の要素だけを含みます。<filename>rules</filename> ファイルが面倒を見るのは <command>dh_make</command> によって生成されたファイルだけです。自分のファイルをインストールするためには、以下の <filename>debian/falcot-data.install</filename> ファイルを作成して、<command>dh_install</command> コマンドの挙動を単純に設定します。

en: The <filename>falcot-data.desktop</filename> file
ja: <filename>falcot-data.desktop</filename> ファイル

en: The updated <filename>debian/falcot-data.install</filename> looks like this:
ja: 編集後の <filename>debian/falcot-data.install</filename> は以下のようになります。

en: Creating a Package Repository for APT
ja: APT 用のパッケージリポジトリの作成

en: <primary>package</primary><secondary>Debian</secondary><tertiary>archive of</tertiary>
ja: <primary>パッケージ</primary><secondary>Debian</secondary><tertiary>アーカイブ</tertiary>

en: Falcot Corp gradually started maintaining a number of Debian packages either locally modified from existing packages or created from scratch to distribute internal data and programs.
ja: Falcot Corp のメンテナンスする Debian パッケージの数は次第に増えました。この中には既存のパッケージから手元で修正したパッケージや、内部データとプログラムを配布するために最初から作成したパッケージなどがあります。

en: To make deployment easier, they want to integrate these packages in a package archive that can be directly used by APT. For obvious maintenance reasons, they wish to separate internal packages from locally-rebuilt packages. The goal is for the matching entries in a <filename>/etc/apt/sources.list.d/falcot.list</filename> file to be as follows:
ja: パッケージの配備を簡単にするために、管理者はこれらのパッケージを APT から直接使うことが可能なパッケージアーカイブに組み込みたいと思っています。明らかなメンテナンス上の理由により、管理者は内部パッケージと手元で再ビルドしたパッケージを別にしたいと思っています。すなわち、最終的に <filename>/etc/apt/sources.list.d/falcot.list</filename> ファイル内のエントリを以下のようにしたいと思っています。

en: The administrators therefore configure a virtual host on their internal HTTP server, with <filename>/srv/vhosts/packages/</filename> as the root of the associated web space. The management of the archive itself is delegated to the <command>mini-dinstall</command> command (in the similarly-named package). This tool keeps an eye on an <filename>incoming/</filename> directory (in our case, <filename>/srv/vhosts/packages/mini-dinstall/incoming/</filename>) and waits for new packages there; when a package is uploaded, it is installed into a Debian archive at <filename>/srv/vhosts/packages/</filename>. The <command>mini-dinstall</command> command reads the <filename>*.changes</filename> file created when the Debian package is generated. These files contain a list of all other files associated with the version of the package (<filename>*.deb</filename>, <filename>*.dsc</filename>, <filename>*.diff.gz</filename>/<filename>*.debian.tar.gz</filename>, <filename>*.orig.tar.gz</filename>, or their equivalents with other compression tools), and these allow <command>mini-dinstall</command> to know which files to install. <filename>*.changes</filename> files also contain the name of the target distribution (often <literal>unstable</literal>) mentioned in the latest <filename>debian/changelog</filename> entry, and <command>mini-dinstall</command> uses this information to decide where the package should be installed. This is why administrators must always change this field before building a package, and set it to <literal>internal</literal> or <literal>updates</literal>, depending on the target location. <command>mini-dinstall</command> then generates the files required by APT, such as <filename>Packages.gz</filename>.
ja: このため、管理者は内部 HTTP サーバ上に仮想ホストを設定して、APT リポジトリのルートとして <filename>/srv/vhosts/packages/</filename> を割り当てます。パッケージアーカイブ自体の管理は <command>mini-dinstall</command> コマンド (同名のパッケージに含まれます) に委託されます。<command>mini-dinstall</command> ツールは <filename>incoming/</filename> ディレクトリ (今回の場合、<filename>/srv/vhosts/packages/mini-dinstall/incoming/</filename>) を監視して、新しいパッケージがこのディレクトリにアップロードされることを待ちます。そしてパッケージがアップロードされたら、<command>mini-dinstall</command> は <filename>/srv/vhosts/packages/</filename> のパッケージアーカイブにパッケージをインストールします。<command>mini-dinstall</command> コマンドは Debian パッケージが生成された時に作成される <filename>*.changes</filename> ファイルを読みます。<filename>*.changes</filename> ファイルには、パッケージのバージョンに対応するその他のファイル (<filename>*.deb</filename>、<filename>*.dsc</filename>、<filename>*.diff.gz</filename>/<filename>*.debian.tar.gz</filename>、<filename>*.orig.tar.gz</filename>、その他の圧縮ツールを使った場合の同等ファイル) のリストが書かれており、<command>mini-dinstall</command> はこのリストに従ってインストールするファイルを把握します。さらに <filename>*.changes</filename> ファイルの <literal>Distribution</literal> ヘッダフィールドには、<filename>debian/changelog</filename> ファイル内の最新エントリに書かれた対象ディストリビューションの名前 (通常 <literal>unstable</literal>) が書かれており、<command>mini-dinstall</command> はこの名前に従ってパッケージのインストール先を決めます。このため、管理者は対象パッケージをビルドする前に <filename>debian/changelog</filename> ファイル内の最新エントリに書かれた対象ディストリビューションの名前を必ず変更し、対象パッケージのインストール先に従ってその名前を <literal>internal</literal> または <literal>updates</literal> に設定しなければいけません。この後、<command>mini-dinstall</command> は APT が必要とする <filename>Packages.gz</filename> などのファイルを生成します。

en: If <command>mini-dinstall</command> seems too complex for your Debian archive needs, you can also use the <command>apt-ftparchive</command> command. This tool scans the contents of a directory and displays (on its standard output) a matching <filename>Packages</filename> file. In the Falcot Corp case, administrators could upload the packages directly into <filename>/srv/vhosts/packages/updates/</filename> or <filename>/srv/vhosts/packages/internal/</filename>, then run the following commands to create the <filename>Packages.gz</filename> files:
ja: 必要なパッケージアーカイブが <command>mini-dinstall</command> を使うほど複雑なパッケージアーカイブではない場合、<command>apt-ftparchive</command> コマンドを使うことも可能です。<command>apt-ftparchive</command> ツールは指定したディレクトリの内容を調査して、その内容に対応する <filename>Packages</filename> ファイルを (標準出力に) 表示します。<command>apt-ftparchive</command> を使う場合、Falcot Corp の管理者はパッケージを直接 <filename>/srv/vhosts/packages/updates/</filename> や <filename>/srv/vhosts/packages/internal/</filename> にアップロードすることが可能です。その後以下のコマンドを実行して <filename>Packages.gz</filename> ファイルを作成します。

en: The <command>apt-ftparchive sources</command> command allows creating <filename>Sources.gz</filename> files in a similar fashion.
ja: <command>apt-ftparchive sources</command> コマンドを使えば、同様の方法で <filename>Sources.gz</filename> ファイルを作成することが可能です。

en: Configuring <command>mini-dinstall</command> requires setting up a <filename>~/.mini-dinstall.conf</filename> file; in the Falcot Corp case, the contents are as follows:
ja: <command>mini-dinstall</command> を設定するには、<filename>~/.mini-dinstall.conf</filename> ファイルをセットアップする必要があります。Falcot Corp では以下の通り設定しました。

en: One decision worth noting is the generation of <filename>Release</filename> files for each archive. This can help manage package installation priorities using the <filename>/etc/apt/preferences</filename> configuration file (see <xref linkend="sect.apt.priorities" /> for details).
ja: 各パッケージアーカイブに対して <filename>Release</filename> ファイルを作成することに決めた点は注目に値します。これは <filename>/etc/apt/preferences</filename> 設定ファイルを使ってパッケージインストール優先度を管理する場合に役立ちます (詳細は<xref linkend="sect.apt.priorities" />を参照してください)。

en: <emphasis>SECURITY</emphasis> <command>mini-dinstall</command> and permissions
ja: <emphasis>SECURITY</emphasis> <command>mini-dinstall</command> とパーミッション

en: Invoking <command>mini-dinstall</command> actually starts a daemon in the background. As long as this daemon runs, it will check for new packages in the <filename>incoming/</filename> directory every half-hour; when a new package arrives, it will be moved to the archive and the appropriate <filename>Packages.gz</filename> and <filename>Sources.gz</filename> files will be regenerated. If running a daemon is a problem, <command>mini-dinstall</command> can also be manually invoked in batch mode (with the <literal>-b</literal> option) every time a package is uploaded into the <filename>incoming/</filename> directory. Other possibilities provided by <command>mini-dinstall</command> are documented in its <citerefentry><refentrytitle>mini-dinstall</refentrytitle> <manvolnum>1</manvolnum></citerefentry> manual page.
ja: <command>mini-dinstall</command> を実行すると、バックグラウンドでデーモンが開始されます。<command>mini-dinstall</command> デーモンが実行されている限り、デーモンは 30 分ごとに <filename>incoming/</filename> ディレクトリにアップロードされた新しいパッケージを確認します。そして新しいパッケージがアップロードされると、パッケージはパッケージアーカイブに移動され、適切な <filename>Packages.gz</filename> と <filename>Sources.gz</filename> ファイルが再生成されます。デーモンの実行に問題がある場合、<filename>incoming/</filename> ディレクトリにパッケージをアップロードしたら毎回、手作業で <command>mini-dinstall</command> をバッチモードで実行します (<literal>-b</literal> オプションを付けます)。<command>mini-dinstall</command> 他の使い方は <citerefentry><refentrytitle>mini-dinstall</refentrytitle> <manvolnum>1</manvolnum></citerefentry> マニュアルページで説明されています。

en: <emphasis>EXTRA</emphasis> Generating a signed archive
ja: <emphasis>EXTRA</emphasis> 署名済みパッケージアーカイブの生成

en: The APT suite checks a chain of cryptographic signatures on the packages it handles before installing them, in order to ensure their authenticity (see <xref linkend="sect.package-authentication" />). Private APT archives can then be a problem, since the machines using them will keep displaying warnings about unsigned packages. A diligent administrator will therefore integrate private archives with the secure APT mechanism.
ja: APT スイートは対象のパッケージをインストールする前にそのパッケージに含まれる一連の暗号署名を確認し、そのパッケージの信頼性を確かめます (<xref linkend="sect.package-authentication" />を参照してください)。この挙動はプライベートパッケージアーカイブにとって問題です。なぜなら、プライベートパッケージアーカイブを使うマシンでは署名されていないパッケージに関する警告が表示され続けるからです。プライベートパッケージアーカイブを安全な APT メカニズムに適合させるのが真面目な管理者の仕事と言えます。

en: To help with this process, <command>mini-dinstall</command> includes a <literal>release_signscript</literal> configuration option that allows specifying a script to use for generating the signature. A good starting point is the <filename>sign-release.sh</filename> script provided by the <emphasis role="pkg">mini-dinstall</emphasis> package in <filename>/usr/share/doc/mini-dinstall/examples/</filename>; local changes may be relevant.
ja: パッケージアーカイブの署名作業を助けるために、<command>mini-dinstall</command> には <filename>Release</filename> に対する署名の生成に使うスクリプトを指定する <literal>release_signscript</literal> 設定オプションが含まれます。ここでは <emphasis role="pkg">mini-dinstall</emphasis> パッケージによって提供された <filename>/usr/share/doc/mini-dinstall/examples/</filename> 内に含まれる <filename>sign-release.sh</filename> スクリプトが良い足掛かりとなるでしょう。しかし、このスクリプトを使うには手元で修正が必要になるかもしれません。

en: Becoming a Package Maintainer
ja: パッケージメンテナになる

en: Learning to Make Packages
ja: パッケージを作るための知識

en: Rules
ja: 規則

en: Procedures
ja: 手続き

en: Debian is not a simple collection of individual packages. Everyone's packaging work is part of a collective project; being a Debian developer involves knowing how the Debian project operates as a whole. Every developer will, sooner or later, interact with others. The Debian Developer's Reference (in the <emphasis role="pkg">developers-reference</emphasis> package) summarizes what every developer must know in order to interact as smoothly as possible with the various teams within the project, and to take the best possible advantages of the available resources. This document also enumerates a number of duties a developer is expected to fulfill. <ulink type="block" url="https://www.debian.org/doc/manuals/developers-reference/" />
ja: Debian は各パッケージを単純に収集しているだけではありません。全員のパッケージング作業は共同プロジェクトの一部です。そして Debian 開発者になるには、Debian プロジェクトが全体としてどのように運営されているかを知る必要があります。すべての Debian 開発者は遅かれ早かれ他人と協力して行動することになるでしょう。Debian 開発者リファレンス (<emphasis role="pkg">developers-reference</emphasis> パッケージに含まれます) では、プロジェクト内のさまざまなチームと可能な限り円滑に一緒に作業を行ったり利用できる資源を大いに活用するためにすべての開発者が必ず知らなければいけないことを要約しています。また、Debian 開発者リファレンスは管理者が果たすべき数多くの義務も列挙しています。<ulink type="block" url="https://www.debian.org/doc/manuals/developers-reference/" />

en: Tools
ja: ツール

en: Many tools help package maintainers in their work. This section describes them quickly, but does not give the full details, since they all have comprehensive documentation of their own.
ja: パッケージメンテナの作業を手助けする数多くのツールが存在します。この節では、それらのツールを簡単に説明します (詳細は説明しません)。なぜなら、これらのツールには自分自身を解説する総合的な文書が用意されているからです。

en: The <emphasis role="pkg">devscripts</emphasis> package contains many programs helping with a wide array of a Debian developer's job:
ja: <emphasis role="pkg">devscripts</emphasis> パッケージには、Debian 開発者が行う作業の大部分に対する手助けを行う数多くのプログラムが含まれます。

en: <command>debuild</command> allows generating a package (with <command>dpkg-buildpackage</command>) and running <command>lintian</command> to check its compliance with the Debian policy afterwards.
ja: <command>debuild</command> を使うことで、(<command>dpkg-buildpackage</command> から) パッケージを生成したり、Debian ポリシーへの遵守を確認するために後から <command>lintian</command> を実行することが可能です。

en: <command>debclean</command> cleans a source package after a binary package has been generated.
ja: <command>debclean</command> を使うことで、バイナリパッケージを生成した後にソースパッケージの後片付けをすることが可能です。

en: <command>dch</command> allows quick and easy editing of a <filename>debian/changelog</filename> file in a source package.
ja: <command>dch</command> を使うことで、素早く簡単にソースパッケージ中の <filename>debian/changelog</filename> ファイルを編集することが可能です。

en: <command>uscan</command> checks whether a new version of a software has been released by the upstream author; this requires a <filename>debian/watch</filename> file with a description of the location of such releases.
ja: <command>uscan</command> を使うことで、上流開発者がソフトウェアの新しいバージョンをリリースしたか否かを確認することが可能です。確認を行うにはリリースの場所が書かれた <filename>debian/watch</filename> ファイルが必要です。

en: <command>debi</command> allows installing (with <command>dpkg -i</command>) the Debian package that was just generated without the need to type its full name and path.
ja: <command>debi</command> を使うことで、Debian パッケージを生成した直後に (<command>dpkg -i</command> を使って) そのパッケージをインストールすることが可能になります。パッケージの完全な名前やパスを指定する必要はありません。

en: In a similar fashion, <command>debc</command> allows scanning the contents of the recently-generated package (with <command>dpkg -c</command>), without needing to type its full name and path.
ja: <command>debc</command> を使うことで、Debian パッケージを生成した直後に (<command>dpkg -c</command> を使って) そのパッケージの内容を調査することが可能です。パッケージの完全な名前やパスを指定する必要はありません。

en: <command>debrelease</command> uploads a recently-generated package to a remote server, without needing to type the full name and path of the related <filename>.changes</filename> file.
ja: <command>debrelease</command> を使うことで、Debian パッケージを生成した直後にそのパッケージをリモートサーバにアップロードすることが可能です。関連する <filename>.changes</filename> ファイルの完全な名前やパスを指定する必要はありません。

en: <command>debsign</command> signs the <filename>*.dsc</filename> and <filename>*.changes</filename> files.
ja: <command>debsign</command> を使うことで、<filename>*.dsc</filename> と <filename>*.changes</filename> ファイルに署名することが可能です。

en: <command>uupdate</command> automates the creation of a new revision of a package when a new upstream version has been released.
ja: <command>uupdate</command> を使うことで、新しい上流開発版がリリースされた場合にパッケージの新しい修正版の作成を自動化することが可能です。

en: <emphasis role="pkg">debhelper</emphasis> and <emphasis role="pkg">dh-make</emphasis>
ja: <emphasis role="pkg">debhelper</emphasis> と <emphasis role="pkg">dh-make</emphasis>

en: The <command>dh_make</command> script (in the <emphasis>dh-make</emphasis> package) creates files required for generating a Debian package in a directory initially containing the sources for a piece of software. As can be guessed from the name of the program, the generated files use debhelper by default.
ja: <command>dh_make</command> スクリプト (<emphasis>dh-make</emphasis> パッケージに含まれます) はソフトウェアのソースが含まれるディレクトリ内に Debian パッケージを生成するために必要なファイルを作成します。<command>dh_make</command> という名前から推測される通り、生成されたファイルはデフォルトで debhelper を使います。

en: This tool is only a helper, and it sometimes gets it wrong (for instance, since the Debian policy changes over time, <command>lintian</command> is sometimes outdated). It is also not exhaustive: not getting any Lintian error should not be interpreted as a proof that the package is perfect; at most, it avoids the most common errors.
ja: <command>lintian</command> の情報は参考程度にしかならず、間違いを犯すこともあります (たとえば、Debian ポリシーは常に変わるものなので、しばしば <command>lintian</command> は時代遅れになることがあります)。また、<command>lintian</command> は徹底的な調査を行いません。すなわち、<command>lintian</command> がエラーを出さないことを理由に対象のパッケージが完全であると結論付けてはいけません。<command>lintian</command> を使ってわかることはせいぜい最も一般的な間違いを犯していないことだけです。

en: This is another important tool: it automates the installation, upgrade, removal and purge of a package (in an isolated environment), and checks that none of these operations leads to an error. It can help in detecting missing dependencies, and it also detects when files are incorrectly left over after the package got purged.
ja: <command>piuparts</command> もまた重要なツールの 1 つです。すなわち、<command>piuparts</command> は (隔離環境の中で) パッケージのインストール、アップグレード、削除、完全削除の作業を自動化し、これらの作業中にエラーが起きないことを確認します。<command>piuparts</command> は不足している依存関係を検出したり、パッケージが完全削除された後にファイルが誤って残されたことを検出したりする際にも役立ちます。

en: <command>dupload</command> and <command>dput</command>
ja: <command>dupload</command> と <command>dput</command>

en: Acceptance Process
ja: 受け入れ過程

en: Becoming a “Debian developer” is not a simple administrative matter. The process comprises several steps, and is as much an initiation as it is a selection process. In any case, it is formalized and well-documented, so anyone can track their progression on the website dedicated to the new member process. <ulink type="block" url="https://nm.debian.org/" />
ja: 「Debian 開発者」になることは単なる管理上の手続きを経るだけの問題ではありません。受け入れ過程は複数の段階から成り、選考過程に匹敵する入会儀式と言えます。いかなる場合も、受け入れ過程は形式化され明確に文書化されています。そのため、誰でも新メンバー過程専用のウェブサイト上で進み具合を追跡することが可能です。<ulink type="block" url="https://nm.debian.org/" />

en: <emphasis>EXTRA</emphasis> Lightweight process for “Debian Maintainers”
ja: <emphasis>EXTRA</emphasis> 「Debian メンテナ」向けの簡単なプロセス

en: “Debian Maintainer” is another status that gives less privileges than “Debian developer” but whose associated process is quicker. With this status, the contributors can maintain their own packages only. A Debian developer only needs to perform a check on an initial upload, and issue a statement to the effect that they trust the prospective maintainer with the ability to maintain the package on their own.
ja: 「Debian メンテナ」とはもう一つの地位です。「Debian メンテナ」に与えられる特権は「Debian 開発者」よりも低いものですが、「Debian メンテナ」になるためのプロセスは「Debian 開発者」になるためのものよりも短い時間ですみます。「Debian メンテナ」の地位を持っている貢献者がメンテナンスできるのは自分自身のパッケージだけです。あなたが「Debian メンテナ」になりたいならば、少なくとも一人以上の Debian 開発者から最初のアップロードに対する確認を受ける必要があります。そして、あなたが自ら進んでパッケージをメンテナンスする能力を持つ見込みあるメンテナであるという点について、その Debian 開発者から信用されなければいけません。さらに、Debian 開発者があなたを信用するということについて声明を発表する必要があります。

en: Prerequisites
ja: 必要条件

en: All candidates are expected to have at least a working knowledge of the English language. This is required at all levels: for the initial communications with the examiner, of course, but also later, since English is the preferred language for most of the documentation; also, package users will be communicating in English when reporting bugs, and they will expect replies in English.
ja: すべての候補者は少なくとも実務に役立つ英語力を持つことを期待されます。英語力はすべての段階で要求されます。たとえば試験官に対する最初の連絡はもちろんその後も必要です。なぜなら、英語はほとんどの文書で推奨される言語だからです。また、パッケージのユーザはバグを報告する際に英語で連絡を取るでしょうし、ユーザは英語で返信をもらうことを期待するでしょう。

en: The other prerequisite deals with motivation. Becoming a Debian developer is a process that only makes sense if the candidate knows that their interest in Debian will last for many months. The acceptance process itself may last for several months, and Debian needs developers for the long haul; each package needs permanent maintenance, and not just an initial upload.
ja: もう一つの必要条件は意欲です。Debian 開発者の受け入れ過程に出願することが合理的な行為と考えられるのは候補者が Debian に対する自分の関心が何カ月も続くことを理解している場合に限ります。受け入れ過程は数カ月間続き、開発者として受け入れられた暁には Debian から長期にわたる苦労を要求されます。すなわち、それぞれのパッケージに対する永久的なメンテナンスが要求され、一回だけアップロードすればメンテナンスを終わらせられるというわけではありません。

en: Registration
ja: 登録

en: The first (real) step consists in finding a sponsor or advocate; this means an official developer willing to state that they believe that accepting <emphasis>X</emphasis> would be a good thing for Debian. This usually implies that the candidate has already been active within the community, and that their work has been appreciated. If the candidate is shy and their work is not publicly touted, they can try to convince a Debian developer to advocate them by showing their work in a private way.
ja: 候補者が最初に (現実的な意味で) やることは保証人か支持者を見つけることです。そしてこれは公式の開発者が<emphasis>候補者</emphasis>を受け入れることが Debian のためになると信じていると喜んで宣言すること意味します。通常これは候補者が既にコミュニティ内で活発に活動し続けており、候補者の業績が受け入れられ続けていることを暗黙的に意味します。候補者が遠慮がちで候補者の業績が公に注目されていなければ、候補者は Debian 開発者に対して個人的な方法で自分の業績を明らかにして自分を支持することを納得するように試みることが可能です。

en: <primary>key pair</primary>
ja: <primary sortas="カギペア">鍵ペア</primary>

en: At the same time, the candidate must generate a public/private RSA key pair with GnuPG, which should be signed by at least two official Debian developers. The signature authenticates the name on the key. Effectively, during a key signing party, each participant must show an official identification (usually an ID card or passport) together with their key identifiers. This step confirms the link between the human and the keys. This signature thus requires meeting in real life. If you have not yet met any Debian developers in a public free software conference, you can explicitly seek developers living nearby using the list on the following webpage as a starting point. <ulink type="block" url="https://wiki.debian.org/Keysigning" />
ja: 同時に、候補者は GnuPG を使って RSA 公開鍵と秘密鍵のペアを生成しなければいけません。候補者の公開鍵は少なくとも 2 人の公式 Debian 開発者の秘密鍵によって署名されるべきです。この署名は候補者の公開鍵に書かれた名前が本物であることを証明するものです。実質的なことを言えば、候補者はキーサインパーティで公式 Debian 開発者に直接会って、自分の公開鍵を公式 Debian 開発者の秘密鍵によって署名してもらう必要があります。キーサインパーティの参加者は鍵 ID と一緒に必ず公式の身分証明書 (通常 ID カードかパスポート) を提示しなければいけません。これは人と鍵の関連付けを確認するために必要な措置です。候補者が公のフリーソフトウェアカンファレンスで公式 Debian 開発者に直接会っていない場合、候補者は以下のウェブページに載っているリストを足掛かりとして、近くに住んでいる開発者を探すことが可能です。<ulink type="block" url="https://wiki.debian.org/Keysigning" />

en: Once the registration on <literal>nm.debian.org</literal> has been validated by the advocate, an <emphasis>Application Manager</emphasis> is assigned to the candidate. The application manager will then drive the process through multiple pre-defined steps and checks.
ja: 候補者の支持者が <literal>nm.debian.org</literal> 上の登録内容の正当性を認めたら、対象の候補者に対して 1 人の<emphasis>応募管理者</emphasis>が割り当てられます。応募管理者は複数の事前に定義された段階と確認を通じて作業を進めます。

en: The first verification is an identity check. If you already have a key signed by two Debian developers, this step is easy; otherwise, the application manager will try and guide you in your search for Debian developers close by to organize a meet-up and a key signing.
ja: 最初の妥当性確認事項は候補者の本人確認です。既に 2 人の Debian 開発者が自分の秘密鍵で候補者の公開鍵に署名しているならば、この段階は簡単です。そうでなければ、応募管理者はあなたに対して、近くにいる Debian 開発者を探し、直接会ってキーサインする段取りを付けるように指導するでしょう。

en: Accepting the Principles
ja: 原則の受け入れ

en: These administrative formalities are followed by philosophical considerations. The point is to make sure that the candidate understands and accepts the social contract and the principles behind Free Software. Joining Debian is only possible if one shares the values that unite the current developers, as expressed in the founding texts (and summarized in <xref linkend="the-debian-project" />).
ja: 次の管理上の手続きでは哲学の検討を行います。ここで、候補者は社会契約とフリーソフトウェアの背後にある原理を理解して受け入れることに対して確認を取られます。Debian に参加するには、必ず創設理念 (および<xref linkend="the-debian-project" />) で述べられている現在の開発者を団結させている価値に共感する必要があります。

en: In addition, each candidate wishing to join the Debian ranks is expected to know the workings of the project, and how to interact appropriately to solve the problems they will doubtless encounter as time passes. All of this information is generally documented in manuals targeting the new maintainers, and in the Debian developer's reference. An attentive reading of this document should be enough to answer the examiner's questions. If the answers are not satisfactory, the candidate will be informed. They will then have to read (again) the relevant documentation before trying again. In the cases where the existing documentation does not contain the appropriate answer for the question, the candidate can usually reach an answer with some practical experience within Debian, or potentially by discussing with other Debian developers. This mechanism ensures that candidates get involved somewhat in Debian before becoming a full part of it. It is a deliberate policy, by which candidates who eventually join the project are integrated as another piece of an infinitely extensible jigsaw puzzle.
ja: 加えて、Debian に参加したいと思っている各候補者はプロジェクトの仕組みと時間がたてば間違いなく直面するであろう問題を解決する際に適切に相互協力する方法を知ることを期待されます。これらに関するすべての情報は新しいメンテナ向けのマニュアルと Debian 開発者リファレンスの中で大ざっぱに説明されています。応募管理者からの質問に答えるには、これらの文書を注意深く読むだけで十分です。回答が不十分な場合、候補者はその旨通知されます。候補者は再試験を受ける前に関連する文書を (もう一度) 読まなければいけません。既存の文書に質問に対する適切な回答が含まれなかった場合、候補者は Debian 内の実務経験を使うか他の Debian 開発者との議論を通じて回答を作成しても構いません。このメカニズムによって、候補者が Debian のすべての部分に参加する前に一部分だけに参加することが保証されます。これは慎重な方針です。この方針によって最終的に Debian プロジェクトに参加する候補者は永久的に広がるジグソーパズルにそのピースの 1 つとして組み込まれます。

en: This step is usually known as the <emphasis>Philosophy &amp; Procedures</emphasis> (P&amp;P for short) in the lingo of the developers involved in the new member process.
ja: この段階は新メンバー過程に参加する開発者の間で使われる用語の <emphasis>Philosophy &amp; Procedures</emphasis> (略して P&amp;P、哲学と手順) として知られています。

en: Checking Skills
ja: 能力の確認

en: Each application to become an official Debian developer must be justified. Becoming a project member requires showing that this status is legitimate, and that it facilitates the candidate's job in helping Debian. The most common justification is that being granted Debian developer status eases maintenance of a Debian package, but it is not the only one. Some developers join the project to contribute to porting to a specific architecture, others want to improve documentation, and so on.
ja: 公式 Debian 開発者の受け入れ過程への出願は理に適ったものでなければいけません。プロジェクトメンバーになるには、候補者はプロジェクトメンバーの地位を得ることが合理的な要求であり、プロジェクトメンバーの地位を得ることで Debian の手助けに関する自分の作業が容易になることを示す必要があります。最も一般的な理由付けは Debian 開発者の地位が Debian パッケージのメンテナンスを簡単にするというものです。しかしこれは唯一の理由ではありません。特定のアーキテクチャへの移植に貢献するためにプロジェクトに参加している開発者もいれば、文書を改良したいと思ってプロジェクトに参加している開発者もいます。

en: This step represents the opportunity for the candidate to state what they intend to do within the Debian project and to show what they have already done towards that end. Debian is a pragmatic project and saying something is not enough, if the actions do not match what is announced. Generally, when the intended role within the project is related to package maintenance, a first version of the prospective package will have to be validated technically and uploaded to the Debian servers by a sponsor among the existing Debian developers.
ja: この段階で、候補者は Debian プロジェクトの中で自分が何をしたいと思っているのか宣言し、その目的のために自分がこれまで何をしてきたか示す機会を与えられます。Debian は実用主義的なプロジェクトで、やっていることが言っていることと食い違っている場合、言うだけでは不十分です。一般的に言って、プロジェクト内で希望する役割がパッケージメンテナンスに関連する場合、候補となっているパッケージの最初のバージョンは必ず技術的な正当性を確認され、既存の Debian 開発者から選ばれた保証人によって Debian サーバにアップロードされることでしょう。

en: <emphasis>COMMUNITY</emphasis> Sponsoring
ja: <emphasis>COMMUNITY</emphasis> パッケージの支援

en: <primary>sponsoring</primary>
ja: <primary sortas="パッケージノシエン">パッケージの支援</primary>

en: Debian developers can “sponsor” packages prepared by someone else, meaning that they publish them in the official Debian repositories after having performed a careful review. This mechanism enables external persons, who have not yet gone through the new member process, to contribute occasionally to the project. At the same time, it ensures that all packages included in Debian have always been checked by an official member.
ja: Debian 開発者は誰かによって用意されたパッケージを「支援」することが可能です。これは注意深く調査した後に Debian 開発者が公式の Debian リポジトリの中でパッケージを公開することを意味します。このメカニズムのおかげで、まだ新メンバー過程を通過していない外部の人も時折 Debian プロジェクトに貢献することが可能になります。同時に、Debian に含まれるすべてのパッケージは常に公式メンバーによって確認されていることが保証されます。

en: This step is known as the <emphasis>Tasks &amp; Skills</emphasis> step (T&amp;S for short) in the examiners' jargon.
ja: この段階は応募管理者によって使われる隠語の <emphasis>Tasks &amp; Skills</emphasis> (略して T&amp;S、作業と技能) として知られています。

en: Final Approval
ja: 最後の承認

en: At the very last step, the whole process is reviewed by a DAM (<emphasis>Debian Account Manager</emphasis>). The DAM will review all the information about the candidate that the examiner collected, and makes the decision on whether or not to create an account on the Debian servers. In cases where extra information is required, the account creation may be delayed. Refusals are rather rare if the examiner does a good job of following the process, but they sometimes happen. They are never permanent, and the candidate is free to try again at a later time.
ja: 最後の段階で、DAM (<emphasis>Debian アカウントマネージャ</emphasis>) がすべてのプロセスを再確認します。DAM は応募管理者が集めた候補者に関するすべての情報を再確認し、Debian サーバにアカウントを作成するか否かについて決断を下します。追加的情報が必要な場合、アカウントの作成が遅れるかもしれません。応募管理者がプロセスに従って良い作業をしていれば、この段階で不合格になることはほとんどありません。しかし、不合格なる場合も時々あります。不合格は永久的なものではありません。候補者はしばらくの後に再試験を受けることが可能です。

en: The DAM's decision is authoritative and (almost) without appeal, which explains why the people in that seat have often been criticized in the past.
ja: DAM の決定は権威あるもので (ほとんど) 覆されません。このおかげで、DAM の役職に就く人はこれまでずっと批判され続けています。
