ubuntu-packaging-guide - en to ja translation catalogue (134 entries)

en: autopkgtest: Automatic testing for packages
ja: autopkgtest: パッケージの自動テスト

en: The actual tests
ja: 実際のテスト

en: Using Chroots
ja: Chrootの使用

en: If you are running one version of Ubuntu but working on packages for another versions you can create the environment of the other version with a ``chroot``.
ja: あるバージョンのUbuntuを起動しているのに他のバージョン向けのパッケージの作業を行なう場合は、 ``chroot`` で他のバージョンの環境を作成することができます。

en: A ``chroot`` allows you to have a full filesystem from another distribution which you can work in quite normally.  It avoids the overhead of running a full virtual machine.
ja: ``chroot`` を使えば、他のディストリビューションからすべてのファイルシステムを持つことが可能になります。それにより、完全仮想化マシンを実行する際のオーバーヘッドを回避します。

en: Creating a Chroot
ja: Chroot環境の作成

en: Use the command ``debootstrap`` to create a new chroot::
ja: ``debootstrap`` コマンドを使用して新しいchroot環境を作成します::

en: You can then work inside the chroot::
ja: これによりchroot環境の中で作業できます::

en: Where you can install or remove any package you wish without affecting your main system.
ja: メイン環境に影響を与えることなく、任意のパッケージをインストールしたり削除することができます。

en: To stop apt and other programs complaining about missing locales you can install your relevant language pack::
ja: aptや他のプログラムが、ロケールが見つからないというエラーを出すのを止めたいのであれば、適切な言語パックをインストールすることができます::

en: If you want to run X programs you will need to bind the /tmp directory into the chroot, from outside the chroot run::
ja: Xのプログラムを実行したい場合は、/tmpディレクトリをchroot内にバインドする必要があります。chrootの外側から実行してください::

en: Some programs may need you to bind /dev or /proc.
ja: 一部のプログラムは/devまたは/procにバインドする必要があるかもしれません。

en: Alternatives
ja: その他の手段

en: Communication in Ubuntu Development
ja: Ubuntu開発におけるコミュニケーション

en: In a project where thousands of lines of code are changed, lots of decisions are made and hundreds of people interact every day, it is important to communicate effectively.
ja: 何千行ものコードが変更され、多くの決定がされ、何百人もの人々が毎日互いに影響しあっているようなプロジェクトでは、効果的にコミュニケーションを取ることが重要になります。

en: Mailing lists
ja: メーリングリスト

en: Mailing lists are a very important tool if you want to communicate ideas to a broader team and make sure that you reach everybody, even across timezones.
ja: タイムゾーンを超えて、幅広いチームとアイディアを話し合ったり、皆に確かめたいことがあるなら、メーリングリストは大変重要なツールです。

en: In terms of development, these are the most important ones:
ja: 開発に関して言えば、これらは最も重要なものです:

en: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce (announce-only, the most important development announcements go here)
ja: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce (アナウンスのみ。最も重要な開発アナウンスがここで行われます)

en: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel (general Ubuntu development discussion)
ja: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel (Ubuntu開発全般の議論)

en: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu (MOTU Team discussion, get help with packaging)
ja: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu (MOTU チームの議論。パッケージングに関するヘルプ)

en: IRC Channels
ja: IRCチャンネル

en: For real-time discussions, please connect to irc.freenode.net and join one or any of these channels:
ja: リアルタイムで議論を行うには、irc.freenode.netに接続して、これらのチャンネルの一つまたはいずれかにjoinしてください:

en: #ubuntu-devel (for general development discussion)
ja: #ubuntu-devel (開発全般に関する議論)

en: #ubuntu-motu (for MOTU team discussion and generally getting help)
ja: #ubuntu-motu (MOTU チームの議論ならびに一般的なヘルプ)

en: Basic Overview of the ``debian/`` Directory
ja: ``debian/`` ディレクトリに関する基本概要

en: This article will briefly explain the different files important to the packaging of Ubuntu packages which are contained in the ``debian/`` directory. The most important of them are ``changelog``, ``control``, ``copyright``, and ``rules``. These are required for all packages. A number of additional files in the ``debian/`` may be used in order to customize and configure the behavior of the package. Some of these files are discussed in this article, but this is not meant to be a complete list.
ja: この記事では、Ubuntuパッケージのパッケージングの際に重要な、``debian/`` ディレクトリに含まれるファイルについて簡単に説明します。最も重要なファイルは、 ``changelog``、``control``、``copyright``、``rules`` です。これらのファイルは、すべてのパッケージで必須です。``debian/`` にあるいくつかの追加ファイルは、パッケージの挙動をカスタマイズしたり設定するために利用されているはずです。これらのファイルの一部は、この記事で述べますが、完全なリストであることを意図したものではありません。

en: The changelog
ja: changelog (変更履歴)

en: This file is, as its name implies, a listing of the changes made in each version. It has a specific format that gives the package name, version, distribution, changes, and who made the changes at a given time. If you have a GPG key (see: :doc:`Getting set up<./getting-set-up/>`), make sure to use the same name and email address in ``changelog`` as you have in your key. The following is a template ``changelog``::
ja: このファイルでは、その名のとおり、バージョンごとに行われた変更点を列挙します。パッケージ名、バージョン、ディストリビューション、変更点、変更した人、そして記述した時刻について、決まった形式が存在します。 GPG鍵（参考： :doc:`Getting set up<./getting-set-up/>` ）を持っているなら、 ``changelog`` には必ずその鍵と同じ名前とメールアドレスを使用してください。 ``changelog`` のテンプレートは次のようになります::

en: The format (especially of the date) is important. The date should be in :rfc:`5322` format, which can be obtained by using the command ``date -R``. For convenience, the command ``dch`` may be used to edit changelog. It will update the date automatically.
ja: 書式（特に日付）が重要です。日付は :rfc:`5322` 形式に準じ、 ``date -R`` コマンドで取得できます。changelogを編集する場合は、 ``dch`` コマンドを使うと便利でしょう。このコマンドは、自動的に日付を更新してくれます。

en: Minor bullet points are indicated by a dash "-", while major points use an asterisk "*".
ja: 箇条書きの小項目にはダッシュ"-"を、大項目にはアスタリスク"*"を使います。

en: If you are packaging from scratch, ``dch --create`` (``dch`` is in the ``devscripts`` package) will create a standard ``debian/changelog`` for you.
ja: 一からパッケージを作る場合は、 ``dch --create`` （``dch`` は ``devscripts`` パッケージにあります）を使うと、標準的な ``debian/changelog`` を作成できます。

en: Here is a sample ``changelog`` file for hello::
ja: 以下はhelloのサンプル ``changelog`` ファイルです::

en: Notice that the version has a ``-0ubuntu1`` appended to it, this is the distro revision, used so that the packaging can be updated (to fix bugs for example) with new uploads within the same source release version.
ja: バージョンに ``-0ubuntu1`` と追加されていることに気づくでしょう。これはディストロリビジョンで、ソースコードのバージョンは同じだけれども、アップロード時に（例えば不具合修正などの）更新を行ったパッケージに使われます。

en: Ubuntu and Debian have slightly different package versioning schemes to avoid conflicting packages with the same source version. If a Debian package has been changed in Ubuntu, it has ``ubuntuX`` (where ``X`` is the Ubuntu revision number) appended to the end of the Debian version. So if the Debian hello ``2.6-1`` package was changed by Ubuntu, the version string would be ``2.6-1ubuntu1``. If a package for the application does not exist in Debian, then the Debian revision is ``0`` (e.g. ``2.6-0ubuntu1``).
ja: UbuntuとDebianでは同じソースバージョンに対して衝突が起きないように、少し異なるバージョン付けを行っています。DebianパッケージがUbuntuで変更された場合、そのパッケージには ``ubuntuX`` （ここで ``X`` は Ubuntu リビジョン番号）が、Debianのバージョンの後ろに追加されます。Debian hello ``2.6-1`` パッケージがUbuntuで変更された場合は、バージョン文字列は ``2.6-1ubuntu1`` になるのです。あるアプリケーションのパッケージがDebianには存在しない場合、Debianリビジョンは ``0`` になります（例： ``2.6-0ubuntu1`` ）。

en: The control file
ja: controlファイル

en: The ``control`` file contains the information that the package manager (such as ``apt-get``, ``synaptic``, and ``adept``) uses, build-time dependencies, maintainer information, and much more.
ja: ``control`` ファイルには、パッケージマネージャー(``apt-get``、``synaptic``、``adept``など)が使用したり、ビルド時刻、依存関係、メンテナー情報、その他多くの情報が含まれています。

en: For the Ubuntu ``hello`` package, the ``control`` file looks something like this:
ja: Ubuntuにおける``hello``パッケージの``control``ファイルは以下のように書かれています:

en: The first paragraph describes the source package including the list of packages required to build the package from source in the ``Build-Depends`` field. It also contains some meta-information such as the maintainer's name, the version of Debian Policy that the package complies with, the location of the packaging version control repository, and the upstream home page.
ja: 最初の段落は、パッケージをビルドするときに必要なパッケージを列挙する ``Build-Depends`` フィールドを含む、ソースパッケージの概要を記述します。ここには、メンテナーの名前や パッケージが準拠しているDebianポリシーのバージョン、パッケージのバージョン管理リポジトリの場所、アップストリームのホームページなどのメタ情報も含まれます。

en: Each additional paragraph describes a binary package to be built.
ja: 以降の個々の段落には、ビルドされるバイナリパッケージについて記述します。

en: The copyright file
ja: copyrightファイル

en: Generally, copyright information is found in the ``COPYING`` file in the program's source directory. This file should include such information as the names of the author and the packager, the URL from which the source came, a Copyright line with the year and copyright holder, and the text of the copyright itself. An example template would be::
ja: 一般的に著作権情報は、そのプログラムのソースディレクトリの ``COPYING`` ファイルに記載されています。このファイルには、作者とパッケージ作成者の名前、ソースコードを取得したURL、年と著作権保持者を記述したCopyrightマークの行、そして権利に関する文章そのものが含まれている必要があります。以下はその例です::

en: The rules file
ja: rulesファイル

en: The last file we need to look at is ``rules``. This does all the work for creating our package. It is a Makefile with targets to compile and install the application, then create the ``.deb`` file from the installed files. It also has a target to clean up all the build files so you end up with just a source package again.
ja: 確認が必要な最後のファイルは ``rules`` ファイルです。ここにはパッケージを作成する際に必要な作業をすべて記述します。アプリケーションをコンパイル、インストールし、その後インストールされるファイルから ``.deb`` ファイルを作成するターゲットが記述されたMakefileなのです。また、最終的にただのソースパッケージに再び戻すために、ビルド時に作成したファイルを掃除するターゲットも存在します。

en: Let us go through this file in some detail. What this does is pass every build target that ``debian/rules`` is called with as an argument to ``/usr/bin/dh``, which itself will call all the necessary ``dh_*`` commands.
ja: このファイルについてもう少し詳しく見ていきましょう。これは ``debian/rules`` を呼び出したすべてのビルドターゲットについて、 必要な ``dh_*`` コマンドを呼び出す ``/usr/bin/dh`` へと引数を渡しています。

en: ``dh`` runs a sequence of debhelper commands. The supported sequences correspond to the targets of a ``debian/rules`` file: "build", "clean", "install", "binary-arch", "binary-indep", and "binary". In order to see what commands are run in each target, run::
ja: ``dh`` は、debhelperコマンドのシーケンスを実行します。 ``debian/rules`` ファイルのターゲットのうち、サポートしているシーケンスは次のとおりです："build"、"clean"、"install"、"binary-arch"、"binary-indep"、"binary"。それぞれのターゲットについてどのようなコマンドが呼び出されるかを確認するには、次のように実行します::

en: Commands in the binary-indep sequence are passed the "-i" option to ensure they only work on binary independent packages, and commands in the binary-arch sequences are passed the "-a" option to ensure they only work on architecture dependent packages.
ja: binary-indepシーケンスのコマンドはバイナリに非依存なパッケージのみ作用するように"-i"オプションが渡されますし、binary-archシーケンスのコマンドはアーキテクチャに依存したパッケージのみに作用するように"-a"オプションが渡されます。

en: Each debhelper command will record when it's successfully run in ``debian/package.debhelper.log``. (Which dh_clean deletes.) So dh can tell which commands have already been run, for which packages, and skip running those commands again.
ja: 個々のdebhelperコマンドは、成功時には ``debian/package.debhelper.log`` に記録されます（dh_cleanで削除されます）。そのため、dhはどのパッケージのどのコマンドが既に実行済みか分かっているため、同じコマンドの実行をスキップします。

en: Each time ``dh`` is run, it examines the log, and finds the last logged command that is in the specified sequence. It then continues with the next command in the sequence. The ``--until``, ``--before``, ``--after``, and ``--remaining`` options can override this behavior.
ja: ``dh`` の実行時にはこのログを調べ、特定のシーケンスに対して最後に記録されたコマンドを探し、その次のコマンドから実行を再開するのです。この振る舞いは、 ``--until`` 、 ``--before`` 、 ``--after`` 、 ``--remaining`` オプションで変更できます。

en: If ``debian/rules`` contains a target with a name like ``override_dh_command``, then when it gets to that command in the sequence, ``dh`` will run that target from the rules file, rather than running the actual command. The override target can then run the command with additional options, or run entirely different commands instead. (Note that to use this feature, you should Build-Depend on debhelper 7.0.50 or above.)
ja: ``debian/rules`` に ``override_dh_command`` という名前のターゲットが含まれており、さらにシーケンスにそのコマンドが存在する場合、 ``dh`` は実際のコマンドではなく、rulesファイルにあるそのターゲットを実行します。この上書きターゲットを使えば、コマンドに追加のオプションを設定したり、完全に異なるコマンドを実行させることができます（この機能を使うには、debhelperのバージョン7.0.50以上をBuild-Dependに指定する必要があります）。

en: Have a look at ``/usr/share/doc/debhelper/examples/`` and ``man dh`` for more examples. Also see `the rules section (Section 4.9) <http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules>`_ of the Debian Policy Manual.
ja: その他のサンプルは ``/usr/share/doc/debhelper/examples/`` や ``man dh`` を確認してください。Debianポリシーマニュアルの `the rules section (Section 4.9) <http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules>`_ も確認すると良いでしょう。

en: Additional Files
ja: その他のファイル

en: The install file
ja: installファイル

en: The ``install`` file is used by ``dh_install`` to install files into the binary package. It has two standard use cases:
ja: ``install`` ファイルは、 ``dh_install`` に対してバイナリパッケージ内へインストールするファイルを指定するために使われます。二種類の標準的な使い方が存在します:

en: To install files into your package that are not handled by the upstream build system.
ja: アップストリームのビルドシステムでは設定されていないファイルをパッケージ内へインストールする。

en: Splitting a single large source package into multiple binary packages.
ja: 一つの巨大なソースパッケージを複数のバイナリパッケージに分割する。

en: In the first case, the ``install`` file should have one line per file installed, specifying both the file and the installation directory. For example, the following ``install`` file would install the script ``foo`` in the source package's root directory to ``usr/bin`` and a desktop file in the ``debian`` directory to ``usr/share/applications``::
ja: 最初のケースの場合、 ``install`` ファイルは、インストールするファイルとインストール先のディレクトリを一行にまとめて、一行ずつ記述していきます。例えば次の ``install`` ファイルは、ソースパッケージのルートディレクトリにある ``foo`` スクリプトを ``usr/bin`` にインストールし、 ``debian`` ディレクトリにあるデスクトップファイルを ``usr/share/applications`` にインストールします::

en: When a source package is producing multiple binary packages ``dh`` will install the files into ``debian/tmp`` rather than directly into ``debian/<package>``. Files installed into ``debian/tmp`` can then be moved into separate binary packages using multiple ``$package_name.install`` files. This is often done to split large amounts of architecture independent data out of architecture dependent packages and into ``Architecture: all`` packages. In this case, only the name of the files (or directories) to be installed are needed without the installation directory. For example, ``foo.install`` containing only the architecture dependent files might look like::
ja: 一つのソースパッケージから複数のバイナリパッケージを生成するとき、 ``dh`` はファイルを ``debian/<package>`` ではなく ``debian/tmp`` にインストールします。 ``debian/tmp`` にインストールされたファイルたちは、複数の ``$package_name.install`` ファイルを使うことで別々のバイナリパッケージへと分割できます。この方法はしばしば、アーキテクチャに依存しない大量のデータを、アーキテクチャに依存するパッケージから ``Architecture: all`` なパッケージへと分離する際に使われます。この場合、インストールされるファイル（とディレクトリ）の名前だけを列挙すれば良く、インストール先のディレクトリを指定する必要はありません。例えば、アーキテクチャに依存したファイルのみを含む ``foo.install`` は次のように記述します::

en: While ``foo-common.install`` containing only the architecture independent file might look like::
ja: それに対して、アーキテクチャに依存しないファイルのみを含む ``foo-common.install`` は次のようになります::

en: This would create two binary packages, ``foo`` and ``foo-common``. Both would require their own paragraph in ``debian/control``.
ja: これにより、 ``foo`` と ``foo-common`` という二つのバイナリパッケージが作成されます。どちらも ``debian/control`` にそれを指定する段落が必要です。

en: See ``man dh_install`` and the `install file section (Section 5.11) <http://www.debian.org/doc/manuals/maint-guide/dother.en.html#install>`_  of the Debian New Maintainers' Guide for additional details.
ja: さらに詳細を知りたい場合は、 ``man dh_install`` やDebian新メンテナーガイドの `install file section (Section 5.11) <http://www.debian.org/doc/manuals/maint-guide/dother.ja.html#install>`_  を参照してください。

en: The watch file
ja: watchファイル

en: The ``debian/watch`` file allows us to check automatically for new upstream versions using the tool ``uscan`` found in the ``devscripts`` package. The first line of the watch file must be the format version (3, at the time of this writing), while the following lines contain any URLs to parse. For example::
ja: ``debian/watch`` ファイルを設定すると、 ``devscripts`` にある ``uscan`` ツールを使うことで、自動的にアップストリームの新バージョンをチェックできます。watchファイルの先頭行は書式のバージョン（執筆時点では 3 です）を指定する必要があり、それ以降の行は解析用のURLを記述します。例::

en: Running ``uscan`` in the root source directory will now compare the upstream version number in ``debian/changelog`` with the latest available upstream version. If a new upstream version is found, it will be automatically downloaded. For example::
ja: ソースディレクトリの一番上で ``uscan`` を実行すると、 ``debian/changelog`` にあるアップストリームのバージョン番号と、アップストリームの最新のバージョンを比較します。新しいバージョンがアップストリームに存在する場合は、自動的にダウンロードされます。例えば次のようになります::

en: For further information, see ``man uscan`` and the `watch file section (Section 4.11) <http://www.debian.org/doc/debian-policy/ch-source.html#s-debianwatch>`_ of the Debian Policy Manual.
ja: 詳細については ``man uscan`` やDebianポリシーマニュアルの `watch file section (Section 4.11) <http://www.debian.org/doc/debian-policy/ch-source.html#s-debianwatch>`_ を参照してください。

en: For a list of packages where the ``watch`` file reports they are not in sync with upstream see `Ubuntu External Health Status <http://qa.ubuntuwire.org/uehs/no_updated.html>`_.
ja: ``watch`` ファイルによって、アップストリームとの同期ができていないことが判明しているパッケージの一覧は、 `Ubuntu External Health Status <http://qa.ubuntuwire.org/uehs/no_updated.html>`_ を参照してください。

en: The source/format file
ja: source/formatファイル

en: This file indicates the format of the source package. It should contain a single line indicating the desired format:
ja: このファイルはソースパッケージの書式を指定します。使用したい書式を指定する一行のみを記述します:

en: ``3.0 (native)`` for Debian native packages (no upstream version)
ja: ``3.0 (native)`` Debianネイティブなパッケージ（アップストリームが存在しない）

en: ``3.0 (quilt)`` for packages with a separate upstream tarball
ja: ``3.0 (quilt)`` 別途、アップストリームの tarボールが存在するパッケージ

en: ``1.0`` for packages wishing to explicitly declare the default format
ja: ``1.0`` 既定の書式であることが明示されたパッケージ

en: Currently, the package source format will default to 1.0 if this file does not exist. You can make this explicit in the source/format file. If you choose not to use this file to define the source format, Lintian will warn about the missing file. This warning is informational only and may be safely ignored.
ja: 現時点では、このファイルが存在しない時のパッケージソースのデフォルトの書式は1.0になります。source/formatファイルで、書式を明示できます。ソースの書式を指定するのにこのファイルを使わなかった場合は、Lintianはファイルが存在しないことに対して警告を発します。この警告は情報表示のみであり、安全に無視できます。

en: You are encouraged to use the newer 3.0 source format. It provides a number of new features:
ja: より新しい3.0の書式を使うことが推奨されます。この書式にはいくつかの新機能が存在します:

en: Support for additional compression formats: bzip2, lzma and xz
ja: より多くの圧縮形式のサポート: bzip2、lzma、xz

en: Support for multiple upstream tarballs
ja: 複数のアップストリームtarボールのサポート

en: Not necessary to repack the upstream tarball to strip the debian directory
ja: debianディレクトリを分割するために、アップストリームのtarボールを作り直す必要がなくなった

en: Debian-specific changes are no longer stored in a single .diff.gz but in multiple patches compatible with quilt under ``debian/patches/``
ja: Debianによる変更点を一つの.diff.gzに保存する必要がなくなり、 ``debian/patches/`` 以下のquilt準拠の複数のパッチとして保存されます。

en: Additional Resources
ja: その他の情報

en: Fixing a bug in Ubuntu
ja: Ubuntuでバグを修正する

en: Introduction
ja: 紹介

en: If you followed the instructions to :doc:`get set up with Ubuntu Development<./getting-set-up>`, you should be all set and ready to go.
ja: :doc:`get set up with Ubuntu Development<./getting-set-up>` をまだ読んでいないなら、まずはそちらで設定を行ってから先に読み進めてください。

en: As you can see in the image above, there is no surprises in the process of fixing bugs in Ubuntu: you found a problem, you get the code, work on the fix, test it, push your changes to Launchpad and ask for it to be reviewed and merged. In this guide we will go through all the necessary steps one by one.
ja: 上図からもわかる通り、Ubuntuにおけるバグ修正の手順に特別な意外性はありません：問題を見つけたら、ソースコードを取得し、問題を修正し、テストし、変更点をLaunchpadに報告し、レビューとマージ（取り込み）のための依頼をするだけです。このガイドでは、必要なすべての手順について、一つずつ説明します。

en: Finding the problem
ja: 問題を見つける

en: There are a lot of different ways to find things to work on. It might be a bug report you are encountering yourself (which gives you a good opportunity to test the fix), or a problem you noted elsewhere, maybe in a bug report.
ja: 問題を見つける方法はいくつか存在します。それはあなた自身が遭遇した不具合かもしれませんし（その場合、修正点に対してテストを行う良い機械でしょう）、どこか別の場所で発生した問題をバグレポートの中から見つけるということもあります。

en: Figuring out what to fix
ja: 何を修正するか理解する

en: If you don't know the source package containing the code that has the problem, but you do know the path to the affected program on your system, you can discover the source package that you'll need to work on.
ja: コンピューター上で問題のあるプログラムのパスが分かっているのに問題のあるコードを含んだソースパッケージがわからない場合、作業を行う必要のあるソースパッケージを探し出すことができます。

en: This would print out::
ja: このように出力されます::

en: Getting the code
ja: コードの取得

en: Work on a fix
ja: 修正作業

en: There are entire books written about finding bugs, fixing them, testing them, etc. If you are completely new to programming, try to fix easy bugs such as obvious typos first. Try to keep changes as minimal as possible and document your change and assumptions clearly.
ja: 不具合の見つけ方や修正やテストの方法などを記述すると何冊もの本になってしまいます。プログラミングの初心者であれば、最初は明らかなタイプミスなど簡単な修正からはじめましょう。変更点はできるだけ小さくし、その変更点と前提条件ははっきりとドキュメントに残すようにしてください。

en: Before working on a fix yourself, make sure to investigate if nobody else has fixed it already or is currently working on a fix. Good sources to check are:
ja: 修正作業を始める前に、他の誰かが既に修正した、もしくは現在修正中であるかどうかを調べておきましょう。調べるに際して以下の情報源をあたると良いでしょう:

en: Upstream (and Debian) bug tracker (open and closed bugs),
ja: アップストリーム（やDebian）のバグトラッキングシステム（オープンだけでなく既に閉じられたバグも）

en: Upstream revision history (or newer release) might have fixed the problem,
ja: アップストリームのリビジョン履歴（もしくは新しいリリース）で問題が修正されているかもしれません

en: bugs or package uploads of Debian or other distributions.
ja: Debianや他のディストリビューションのバグやアップロードされたパッケージ

en: This will copy the packaging to a temporary directory.  You can now edit files with a text editor or apply patches from upstream, for example::
ja: これによりパッケージの内容が一時ディレクトリにコピーされます。テキストエディターを使ってファイルを編集したり、アップストリームからのパッチを適用できます。例えば次のように適用できます::

en: After editing the file type ``exit`` or press ``control-d`` to quit the temporary shell.  The new patch will have been added into ``debian/patches``.
ja: 編集が終わったら ``exit`` を入力するか、 ``control-d`` を押して、一時的なシェルを終了します。新規に作成したパッチが、 ``debian/patches`` に追加されます。

en: Documenting the fix
ja: 修正をドキュメントに残す

en: It is very important to document your change sufficiently so developers who look at the code in the future won't have to guess what your reasoning was and what your assumptions were. Every Debian and Ubuntu package source includes ``debian/changelog``, where changes of each uploaded package are tracked.
ja: 将来あなたが変更を加えたコードを見た人が、あなたが行った変更の理由や前提条件を推測しなくてもすむように、変更について十分なドキュメントを残すことは大変重要です。すべてのDebianとUbuntuのパッケージは、アップロードされたパッケージの変更点を追跡するための ``debian/changelog`` を持っています。

en: The easiest way to update this is to run::
ja: 最も簡単にドキュメントを更新するには以下を実行してください::

en: This will add a boilerplate changelog entry for you and launch an editor where you can fill in the blanks. An example of this could be::
ja: これによりchangelogエントリーの定型文が挿入され、内容を追記するためのエディターが起動します。例えば以下のように入力すると良いでしょう::

en: ``dch`` should fill out the first and last line of such a changelog entry for you already. Line 1 consists of the source package name, the version number, which Ubuntu release it is uploaded to, the urgency (which almost always is 'low'). The last line always contains the name, email address and timestamp (in :rfc:`5322` format) of the change.
ja: ``dch`` は、changelogエントリーの先頭行と最終行を書き込みます。先頭行はソースパッケージの名前、バージョン番号、アップロード対象のUbuntuリリース、緊急度（ほとんどの場合は「low」になります）からなります。最終行は常に、名前とメールアドレスと、変更の日時（ :rfc:`5322` の書式で）からなります。

en: In our (very sparse) example the last point is covered by ``(LP: #123456)`` which refers to Launchpad bug 123456. Bug reports or mailing list threads or specifications are usually good information to provide as a rationale for a change. As a bonus, if you use the ``LP: #<number>`` notation for Launchpad bugs, the bug will be automatically closed when the package is uploaded to Ubuntu.
ja: 今回の（とても簡単な）例において、最後の部分は ``(LP: #123456)`` で実現しています。これは、Launchpadのバグ123456を参照しています。バグレポートやメーリングリストのスレッド、仕様書は変更の根拠として提供する良い情報源でしょう。おまけに、Launchpadのバグについては ``LP: #<番号>`` 記法を使うと、そのパッケージがUbuntuにアップロードされたら自動的にチケットが閉じられます。

en: Testing the fix
ja: 修正をテストする

en: To build a test package with your changes, run these commands::
ja: 変更点を含んだテストパッケージをビルドするには、これらのコマンドを実行してください::

en: Getting Set Up
ja: セットアップ

en: There are a number of things you need to do to get started developing for Ubuntu. This article is designed to get your computer set up so that you can start working with packages, and upload your packages to Ubuntu's hosting platform, Launchpad. Here's what we'll cover:
ja: Ubuntu開発を開始するにあたり、沢山のことをする必要があります。パッケージに取り組み、パッケージをUbuntuのホスティングプラットフォームであるLaunchpadにアップロード出来るようになるよう、コンピューターをセットアップするために、この記事は書かれています。以下にカバーする内容を示します：

en: Installing packaging-related software. This includes:
ja: パッケージング関係のソフトウェアのインストール。以下を含みます。

en: Ubuntu-specific packaging utilities
ja: Ubuntu特有のパッケージングユーティリティ

en: Encryption software so your work can be verified as being done by you
ja: あなたの仕事があなたによって行われたことを検証するための暗号化ソフトウェア

en: Additional encryption software so you can securely transfer files
ja: ファイルを安全に転送するための暗号化ソフトウェアの追加

en: Creating and configuring your account on Launchpad
ja: Launchpadのアカウントの作成と設定

en: Install basic packaging software
ja: 基本的なパッケージングソフトウェアのインストール

en: This command will install the following software:
ja: このコマンドは以下のソフトウェアをインストールします:

en: ``gnupg`` -- `GNU Privacy Guard <GPG_>`_ contains tools you will need to create a cryptographic key with which you will sign files you want to upload to Launchpad.
ja: ``gnupg`` -- `GNU Privacy Guard <GPG_>`_ はLaunchpadにアップロードしたいファイルを署名する暗号鍵を作成するにに必要なツールを含みます。

en: ``pbuilder`` -- a tool to do reproducible builds of a package in a clean and isolated environment.
ja: ``pbuilder`` -- クリーンで隔離された環境でパッケージの再現性のあるビルドを行うためのツール。

en: ``ubuntu-dev-tools`` (and ``devscripts``, a direct dependency) -- a collection of tools that make many packaging tasks easier.
ja: ``ubuntu-dev-tools`` （と直接依存した``devscripts``） -- たくさんのパッケージングタスクを簡単にするためのツールコレクション。

en: ``apt-file`` provides an easy way to find the binary package that contains a given file.
ja: ``apt-file`` は指定されたファイルを提供するバイナリパッケージを探す簡単な方法を提供します。

en: Create your GPG key
ja: GPG鍵の作成

en: To generate a new GPG key, run::
ja: 新しいGPG鍵を生成するには、以下を実行します::

en: Create your SSH key
ja: SSH鍵の作成

en: To generate an SSH key, enter::
ja: SSH鍵を生成するには以下を入力します::

en: Set up pbuilder
ja: pbuilderのセットアップ

en: There is no need to install all necessary *build dependencies* locally
ja: *ビルド依存物*をローカルにインストールする必要はありません

en: About Launchpad
ja: Launchpadとは

en: Get a Launchpad account
ja: Launchpadアカウントの取得

en: Upload your GPG key to Launchpad
ja: GPG鍵のLaunchpadへのアップロード

en: and it will print out something like::
ja: そしてこのようなものが出力されるでしょう::

en: Upload your SSH key to Launchpad
ja: SSH鍵のLaunchpadへのアップロード

en: Configure your shell
ja: シェルの設定

en: Ubuntu Packaging Guide
ja: Ubuntuパッケージングガイド

en: The guide is split up into two sections:
ja: このガイドは2つのセクションに分割されています:

en: Knowledge Base
ja: ナレッジベース

en: Introduction to Ubuntu Development
ja: Ubuntu開発の紹介

en: Translations
ja: 翻訳
