Developer's Reference chap.7

[Yoshizumi Endo <y-endo@xxxxxxxxxxxxxxx>]

遠藤です。

Debian デベロッパーズリファレンス第 7 章の翻訳です。
チェックお願いします。

>     <chapt id="nmu">Non-Maintainer Uploads (NMUs)
>       <p>
> Under certain circumstances it is necessary for someone other than the
> official package maintainer to make a release of a package.  This is
> called a non-maintainer upload, or NMU.

    <chapt id="nmu">ノンメンテナアップロード (NMU)
      <p>
状況によっては、あるパッケージをその公式な開発者以外の誰かが
リリースしなければならないことがあります。
このことはノンメンテナアップロード、すなわち NMU と呼ばれています。

>        <p>
> Debian porters, who compile packages for different architectures, do
> NMUs as part of their normal porting activity (see <ref
> id="porting">).  Another reason why NMUs are done is when a Debian
> developers needs to fix another developers' packages in order to
> address serious security problems or crippling bugs, especially during
> the freeze, or when the package maintainer is unable to release a fix
> in a timely fashion.

       <p>
異なるアーキテクチャ向けのパッケージを作成するという
Debian の移植作業に携わる人にとっては、
この NMU は正規の移植作業の一環にあります。
(<ref id="porting"> をご覧ください。)
他にも、特にフリーズ期間などに、
セキュリティや機能に関する深刻な問題を処理するために、
Debian 開発者が他の開発者のパッケージを修正する必要がある場合、
つまり、パッケージ開発者が修正版を即座にリリースできない場合には
NMU が行なわれます。

>       <p>
> This chapter contains information providing guidelines for when and
> how NMUs should be done.  A fundamental distinction is made between
> source and binary NMUs, which is explained in the next section.

      <p>
この章では、NMU がいつどのように行なわれるべきかについての
ガイドラインを扱います。
なお次節で説明しますが、この NMU には source NMU と binary NMU
の二つがあります。

>       <sect id="nmu-terms">Terminology
> 	<p>
> There are two new terms used throughout this section: ``binary NMU''
> and ``source NMU''.  These terms are used with specific technical
> meaning throughout this document.  Both binary and source NMUs are
> similar, since they involve an upload of a package by a developer who
> is not the official maintainer of that package.  That is why it's a
> <em>non-maintainer</em> upload.
      <sect id="nmu-terms">用語
	<p>
この節の全体にわたって二つの新たな用語、``binary NMU'' と ``source NMU''
を用います。
これらの用語は、この文書の中では技術上の特別な意味を示すものとして用います。
binary NMU と source NMU は、あるパッケージが公式な開発者以外の開発者
によってアップロードされる点では同じです。
<em>ノンメンテナ</em>アップロードと呼ばれるのはこのためです。

> 	<p>
> A source NMU is a upload of a package by a developer who is not the
> official maintainer, for the purposes of fixing a bug in the package.
> Source NMUs always involves changes to the source (even if it is just
> a change to <file>debian/changelog</file>).  This can be either a change
> to the upstream source, or a change to the Debian bits of the source.

	<p>
source NMU とは、あるパッケージがそのバグ修正のために、
公式開発者以外の開発者によってアップロードされることを指します。
source NMU は、(<file>debian/changelog</file> の改変のみかもしれませんが、)
常にソースの改変を伴います。
この改変はアップストリームソースと、
Debian で加えられたソースのどちらに対して行なうことができます。

> 	<p>
> A binary NMU is a recompilation and upload of a binary package for a
> new architecture.  As such, it is usually part of a porting effort.  A
> binary NMU is non-maintainer uploaded binary version of a package
> (often for another architecture), with no source changes required.
> There are many cases where porters must fix problems in the source in
> order to get them to compile for their target architecture; that would
> be considered a source NMU rather than a binary NMU.  As you can see,
> we don't distinguish in terminology between porter NMUs and non-porter
> NMUs.

	<p>
binary NMU は、新たなアーキテクチャ向けにバイナリパッケージを
再コンパイルしアップロードすることを指します。
そのため、こちらは移植に関する正規の作業一環にあるものです。
つまり binary NMU とは、ソース改変を必要としない、
(普通は他アーキテクチャ用) パッケージのバイナリバージョンが
ノンメンテナアップロードされたものです。
ただ、ターゲットとするアーキテクチャでコンパイルを通すために、
移植作業者がソース上の問題を修正することはよくあることです。
そのため、こちらは binary NMU というよりもむしろ source NMU
とみなされるものです。
このように、私たちは、移植作業者による NMU と非移植作業者による
NMU を用語の上では区別していません。

> 	<p>
> Both classes of NMUs, source and binary, can be lumped by the term
> ``NMU''.  However, this often leads to confusion, since most people
> think ``source NMU'' when they think ``NMU''.  So it's best to be
> careful.  In this chapter, if I use the unqualified term ``NMU'', I
> mean both source and binary NMUs.

	<p>
source および binary の両 NMU は、``NMU'' という用語で一括りされえます。
しかしながら、``NMU'' という用語が使われる際に多くの人々は
``source NMU''を想定するために、このことはしばしば混乱をもたらしがちです。
そのためこの区別については注意を払っておくべきでしょう。
この章で私が不特定に ``NMU'' という用語を使う場合、
それは source および binary の両 NMU を指すものとします。

>       <sect id="nmu-who">Who can do an NMU
> 	<p>
> Only official, registered Debian maintainers can do binary or source
> NMUs.  An official maintainer is someone who has their key in the
> Debian key ring.  Non-developers, however, are encouraged to download
> the source package and start hacking on it to fix problems; however,
> rather than doing an NMU, they should just submit worthwhile patches
> to the Bug Tracking System.  Maintainers almost always appreciate
> quality patches and bug reports.

      <sect id="nmu-who">NMU を行なうことができるのは誰か
	<p>
Debian 開発者として正式に登録された者のみが
binary NMU あるいは source NMU を行なうことができます。
公式な開発者とは、Debian キーリングに自分の鍵が登録されている者のことです。
もちろん、非開発者の場合もソースパッケージをダウンロードして、
問題を修正するためにそのハックを始めることは奨励されています。
ただその際には、NMU を行なう代わりに
バグ追跡システムへ適切なパッチを登録するべきです。
開発者は質の高いパッチやバグ報告に対して普通いつでも感謝しています。

>       <sect id="nmu-when">When to do a source NMU
> 	<p>
> Guidelines for when to do a source NMU depend on the target
> distribution, i.e., stable, unstable, or frozen.  Porters have
> slightly different rules than non-porters, due to their unique
> circumstances (see <ref id="source-nmu-when-porter">).

      <sect id="nmu-when">source NMU を行なう場合には
	<p>
source NMU を行なう場合のガイドラインは、
ターゲットとするディストリビューション
(つまり stable や、unstable あるいは frozen) によって異なります。
なお、移植作業者が従うルールは、その特別な状況
(<ref id="source-nmu-when-porter"> をご覧ください)
のために、非移植作業者の場合とは若干異なります。

> 	<p>
> Only critical changes or security bug fixes make it into stable.  When
> a security bug is detected a fixed package should be uploaded as soon
> as possible. In this case, the Debian Security Managers should get in
> contact with the package maintainer to make sure a fixed package is
> uploaded within a reasonable time (less than 48 hours). If the package
> maintainer cannot provide a fixed package fast enough or if he/she
> cannot be reached in time, the Security Manager may upload a fixed
> package (i.e., do a source NMU).

	<p>
stable 版に対して行なえるものは、critical なバグの修正や、
セキュリティ上のバグに関する修正のみです。
セキュリティ上のバグが発覚した場合、
修正版パッケージは可能な限り早くアップロードされるべきです。
この場合、Debian セキュリティマネージャは、
修正版パッケージを適切な期限内 (48 時間以内)
に確実にアップロードできるよう該当パッケージの開発者と連絡をとるべきです。
パッケージ開発者が修正版パッケージを十分に早くは提供できない場合や、
その開発者にすぐに連絡の取れない場合には、
セキュリティマネージャが修正版パッケージ (つまり source NMU )
をアップロードすることができます。

> 	<p>
> During the release freeze (see <ref id="upload-frozen">), NMUs which
> fix important or higher severity bugs are encouraged and accepted.
> Even during this window, however, you should endeavor to reach the
> current maintainer of the package; they might be just about to upload
> a fix for the problem.  As with any source NMU, the guidelines found
> in <ref id="nmu-guidelines"> need to be followed.

	<p>
リリースのフリーズ期間 (<ref id="upload-frozen"> をご覧ください) には、
important バグや重要度の高いバグの修正は奨励されており認められます。
しかし、この期間においても、
そのパッケージの現行開発者と連絡をとるよう努めなければなりません。
現行開発者がその問題の修正をちょうどアップロードしようとしているところ
なのかもしれないからです。
また、いかなる source NMU を行なう場合でも、<ref id="nmu-guidelines">
にて掲げられているガイドラインには従う必要があります。

> 	<p>
> Bug fixes to unstable by non-maintainers are also acceptable, but only
> as a last resort or with permission.  Try the following steps first,
> and if they don't work, it is probably OK to do an NMU:

	<p>
非開発者による unstable 版へのバグ修正も、
最終手段として行なわれる場合や許可がある場合のみ
認められています。
まず最初は以下の各ステップにしたがってください。
もし誰もその作業に取り組まない場合は、
おそらく NMU を行なうに問題はないでしょう。

> <list>
> 	    <item>
> Make sure that the package bug is in the Debian Bug Tracking System
> (BTS).  If not, submit a bug.

<list>
	    <item>
そのパッケージのバグが Debian バグ追跡システム (BTS) 
に登録されているかどうかを確認します。
もし登録されていない場合は、バグ登録を行なってください。

> 	    <item>
> Email the maintainer, and offer to help fix the package bug.  Give it a 
> few days.

	    <item>
その開発者に電子メールを送り、
そのパッケージのバグ修正を援助する旨申し出ます。
返信をもらうまでに二三日は待ってください。

> 	    <item>
> Go ahead and fix the bug, submitting a patch to the right bug in the
> BTS.  Build the package and test it as discussed in <ref
> id="upload-checking">.  Use it locally.

	    <item>
作業を開始しバグを修正します。
BTS に登録された適切なバグに対してパッチを登録してください。
そのパッケージを <ref id="upload-checking"> 
の説明にしたがってビルドおよびテストします。
こちらはローカルで行なってください。

> 	    <item>
> Wait a couple of weeks for a response.

	    <item>
開発者の対応を二三週間待ちます。

> 	    <item>
> Email the maintainer, asking if it is OK to do an NMU.

	    <item>
NMU を行なってよいかどうか尋ねるために、
開発者に電子メールを送ります。

> 	    <item>
> Double check that your patch doesn't have any unexpected side effects.
> Make sure your patch is as small and as non-disruptive as it can be.

	    <item>
ご自分のパッチが予期しない副作用を持っていないかどうかを
重ねてチェックします。
その際ご自分のパッチができるだけ小さなものとなるように、
また元のソースをなるべく改変しないものとなるよう確認してください。

> 	    <item>
> Wait another week for a response.

	    <item>
開発者の対応をもう一週間待ちます。

> 	    <item>
> Go ahead and do the source NMU, as described in <ref
> id="nmu-guidelines">.
> 	  </list>

	    <item>
作業を進め、<ref id="nmu-guidelines"> の説明にしたがい
source NMU を行ないます。
	  </list>

>       <sect id="nmu-guidelines">How to do a source NMU
> 	<p>
> The following applies to porters insofar as they are playing the dual
> role of being both package bug-fixers and package porters.  If a
> porter has to change the Debian source archive, automatically their
> upload is a source NMU and is subject to its rules.  If a porter is
> simply uploading a recompiled binary package, the rules are different;
> see <ref id="porter-guidelines">.

      <sect id="nmu-guidelines">source NMU を行なうには
	<p>
以下の記述は、移植作業者が
パッケージのバグ修正ならびにパッケージの移植の両方の役割を果たす場合のみ
当てはまります。
移植作業者が Debian ソースアーカイブに変更を加える必要がある場合、
そのアップロードはすなわち source NMU であり、
その際には source NMU に関するルールにしたがわなければなりません。
単に再コンパイルしたバイナリパッケージをアップロードする場合、
適用されるルールは異なってきます。
こちらに関しては <ref id="porter-guidelines"> をご覧ください。

> 	<p>
> First and foremost, it is critical that NMU patches to source should
> be as non-disruptive as possible.  Do not do housekeeping tasks, do
> not change the name of modules or files, do not move directories; in
> general, do not fix things which are not broken.  Keep the patch as
> small as possible.  If things bother you aesthetically, talk to the
> Debian maintainer, talk to the upstream maintainer, or submit a bug.
> However, aesthetic changes must <em>not</em> be made in a non-maintainer
> upload.

	<p>
まず第一に、ソースに対する NMU パッチは、
元のソースをなるべく改変しないものであることが重要です。
あれこれとソースを整理したりしないでください。
モジュール名やファイル名は変更しないでください。
ディレクトリは移動しないでください。
つまり、一般的には問題のない箇所に変更を加えないでください。
パッチはなるべく小さなものとなるようにしてください。
ご自分の審美的な観点から何とかしたいことがあるならば、
Debian 開発者やアップストリーム開発者に連絡を取るか、
バグ報告を行なってください。
ともあれ、審美的な観点からの変更は
ノンメンテナアップロードで行なうべきでは<em>ありません</em>。

> 	<sect1 id="nmu-version">Source NMU version numbering
> 	  <p>
> Whenever you have made a change to a package, no matter how trivial,
> the version number needs to change.  This enables our packing system
> to function.

	<sect1 id="nmu-version">source NMU のバージョン番号づけ
	  <p>
パッケージに変更を加える際には常に、
それがどんなに些細なものであろうとも、
バージョン番号を変更しなければなりません。
そうしなければ、パッケージングシステムが正しく機能しません。

> 	  <p>
> If you are doing a non-maintainer upload (NMU), you should add a new
> minor version number to the <var>debian-revision</var> part of the
> version number (the portion after the last hyphen).  This extra minor
> number will start at `1'.  For example, consider the package `foo',
> which is at version 1.1-3.  In the archive, the source package control
> file would be <file>foo_1.1-3.dsc</file>.  The upstream version is
> `1.1' and the Debian revision is `3'.  The next NMU would add a new
> minor number `.1' to the Debian revision; the new source control file
> would be <file>foo_1.1-3.1.dsc</file>.

	  <p>
ノンメンテナアップロード (NMU) を行なう場合、
バージョン番号の <var>debian-revision</var> 部分 (最後のハイフン以降の部分) 
に新たなマイナーバージョン番号を追加しなければなりません
この拡張マイナー番号は `1' から始められます。
例えば、1.1-3 というバージョンの `foo' 
というパッケージの場合を考えてみましょう。
Debian アーカイブにおいては、そのソースパッケージの制御ファイルは、
<file>foo_1.1-3.dsc</file> になります。
つまり、アップストリームバージョンは `1.1' で、
Debian バージョンは `3' です。
そして、次の NMU では新たなマイナー番号 `.1' を Debian
リビジョンに追加することになります。
つまり、新たなソース制御ファイルは <file>foo_1.1-3.1.dsc</file> になります。

> 	  <p>
> The Debian revision minor number is needed to avoid stealing one of
> the package maintainer's version numbers, which might disrupt their
> work.  It also has the benefit of making it visually clear that a
> package in the archive was not made by the official maintainer.

	  <p>
Debian リビジョンマイナー番号は、パッケージ開発者のバージョン番号の
いずれかと衝突しないようにするために必要になるものです。
これがなければパッケージ開発者の作業が混乱してしまいます。
また、こうすることには、
Debian アーカイブ中のあるパッケージが公式な開発者によるもの
でないことが見てすぐわかるという利点もあります。

> 	  <p>
> If there is no <var>debian-revision</var> component in the version
> number then one should be created, starting at `0.1'.  If it is
> absolutely necessary for someone other than the usual maintainer to
> make a release based on a new upstream version then the person making
> the release should start with the <var>debian-revision</var> value
> `0.1'.  The usual maintainer of a package should start their
> <var>debian-revision</var> numbering at `1'.  Note that if you do
> this, you'll have to invoke <prgn>dpkg-buildpackage</prgn> with the
> <tt>-sa</tt> switch to force the build system to pick up the new
> source package (normally it only looks for Debian revisions of '0' or
> '1' -- it's not yet clever enough to know about `0.1').

	  <p>
もしバージョン番号に <var>debian-revision</var> 部分がない場合は、
`0.1' で始まるように追加しなければなりません。
正規の開発者以外の誰かが、新たなアップストリームバージョンベースのリリース
をどうしても行なう必要がある場合は、`0.1' という <var>debian-revision</var>
を付けてリリースを行なってください。
正規のパッケージ開発者の場合は、
<var>debian-revision</var> を `1' から始めてください。
ただこちらを行なう場合、
ビルドシステムに新たなソースパッケージを強制的に選択させるために、
<tt>-sa</tt> スイッチを付けて <prgn>dpkg-buildpackage</prgn> 
を起動する必要があるでしょう。
(普通このプログラムは、Debian リビジョン が '0' あるいは '1'
かどうかのみを確認します。
-- `0.1' という数字を認識するほどにはまだ賢くないのです。)

> 	  <p>
> Remember, porters who are simply recompiling a package for a different
> architecture do not need to renumber.  Porters should use new version
> numbers if and only if they actually have to modify the source package
> in some way, i.e., if they are doing a source NMU and not a binary
> NMU.

	  <p>
注意していただきたいのですが、移植作業者が異なるアーキテクチャ向けに
パッケージを単に再コンパイルする場合は、
バージョン番号を付け直す必要はありません。
移植作業者は、何らかの方法でソースパッケージに変更を加えた場合、
つまり、binary NMU ではなく source NMU を行なう場合 (のみ)、
新たなバージョン番号を用いるべきです。

> 	<sect1 id="nmu-changelog">
> 	  <heading>Source NMUs must have a new changelog entry</heading>
> 	  <p>
> A non-maintainer doing a source NMU must create a changelog entry,
> describing which bugs are fixed by the NMU, and generally why the NMU
> was required and what it fixed.  The changelog entry will have the
> non-maintainer's email address in the log entry and the NMU version
> number in it.</p>
> 	  <p>
> By convention, source NMU changelog entries start with the line
> <example>
>   * Non-maintainer upload
> </example></p></sect1>

	<sect1 id="nmu-changelog">
	  <heading>source NMU は新たな changelog エントリを必要とする</heading>
	  <p>
source NMU を行なう非公式開発者は、
NMU によってどのバグが修正されたのか、
また通常は NMU がなぜ必要でどこを修正したのかを説明する
changelog エントリを作成しなければなりません。
changelog エントリの log エントリには、
その非公式開発者の電子メールアドレスと NMU バージョン番号が含められます。</p>
	  <p>
慣例によって、source NMU の changelog エントリは次の行で始められます。
<example>
  * Non-maintainer upload
</example></p></sect1>

> 	<sect1 id="nmu-patch">Source NMUs and the Bug Tracking System
> 	  <p>
> Maintainers other than the official package maintainer should make as
> few changes to the package as possible, and they should always send a
> patch as a unified context diff (<tt>diff -u</tt>) detailing their
> changes to the Bug Tracking System.

	<sect1 id="nmu-patch">source NMU とバグ追跡システム
	  <p>
公式なパッケージ開発者以外の開発者がパッケージに変更を加える場合、
その変更はなるべく小さなものに留めるべきです。
また、変更箇所を詳しく説明するために必ず、
そのパッチを unified context diff (<tt>diff -u</tt>) 
の形でバグ追跡システムに送るべきです。

> 	  <p>
> What if you are simply recompiling the package?  In this case, the
> process is different for porters than it is for non-porters, as
> mentioned above.  If you are not a porter and are doing an NMU that
> simply requires a recompile (i.e., a new shared library is available
> to be linked against, a bug was fixed in
> <package>debhelper</package>), there must still be a changelog entry;
> therefore, there will be a patch.  If you are a porter, you are
> probably just doing a binary NMU.  (Note: this leaves out in the cold
> porters who have to do recompiles -- chalk it up as a weakness in how
> we maintain our archive.)

	  <p>
単にパッケージを再コンパイルする場合はどうするのでしょうか？
この場合、すでに述べたように移植作業者の場合と非移植作業者の場合では
その手順が異なります。
移植作業者ではない開発者が単に再コンパイルが必要なだけの NMU を行なう場合、
(つまり、新たな共有ライブラリが利用できるようになった場合や
<package>debhelper</package> でバグ修正が行なわれた場合)
やはり changelog エントリが必要になり、
それゆえパッチが存在することになります。
一方、移植作業者の場合は、おそらく単に binary NMU を行なうことになります。
(注意: このことは、本来再コンパイルをしなければならない移植作業者が
それを行なわないことに関しては考慮していません。
-- こちらは、私たちのアーカイブ管理に関する問題点の一つでしょう。)

> 	  <p>
> If the source NMU (non-maintainer upload) fixes some existing bugs,
> the bugs in the Bug Tracking System which are fixed need to be
> <em>notified</em> but not actually <em>closed</em> by the
> non-maintainer.  Technically, only the official package maintainer or
> the original bug submitter are allowed to close bugs.  However, the
> person making the non-maintainer release must send a short message to
> the relevant bugs explaining that the bugs have been fixed by the NMU.
> Using <email>control@bugs.debian.org</email>, the party doing the NMU
> should also set the severity of the bugs fixed in the NMU to `fixed'.
> This ensures that everyone knows that the bug was fixed in an NMU;
> however the bug is left open until the changes in the NMU are
> incorporated officially into the package by the official package
> maintainer.  Also, open a bug with the patches needed to fix the
> problem, or make sure that one of the other (already open) bugs has
> the patches.

	  <p>
source NMU (ノンメンテナアップロード) によって
バグ追跡システムに登録されている既存のバグを修正した場合、
非公式開発者はそのバグを<em>クローズ</em>するのではなく、
その旨を<em>通知</em>しなければなりません。
規則の上では、バグをクローズすることができるのは、
公式パッケージ開発者か元のバグ報告者のみです。
しかしながら、ノンメンテナリリースを行なった者は、適切なバグに対して、
そのバグが NMU によって修正されたことを説明する
手短なメッセージを送付しなければなりません。
また、<email>control@bugs.debian.org</email> を利用する場合、
NMU を行なった当事者は NMU で修正したバグの重要度を `fixed'
に設定しなければなりません。
こうすることによって、そのバグが NMU によって修正されたことを、
確実に皆に知らせることができるわけです。
ただ、NMU で加えられた変更が、公式なパッケージ開発者によって正式に採用され
るまで、そのバグは開かれたままです。
また、その問題を修正するために必要となるパッチを添えてバグをオープンするか、
(すでにオープンされている) 
他のバグ報告のいずれかにそのパッチを追加してください。

> 	  <p>
> The normal maintainer will either apply the patch or employ an
> alternate method of fixing the problem.  Sometimes bugs are fixed
> independently upstream, which is another good reason to back out an
> NMU's patch.  If the maintainer decides not to apply the NMU's patch
> but to release a new version, the maintainer needs to ensure that the
> new upstream version really fixes each problem that was fixed in the
> non-maintainer release.

	  <p>
正規の開発者は、そのパッチを採用するか、
あるいはその問題を修正する他の方途を用いることになります。
時にはバグがアップストリームで独自に修正されることもあります。
このことは NMU によるパッチが退けられる十分な理由のひとつです。
新たなバージョンをリリースする際に、
正規の開発者が NMU によるパッチを採用しない場合、
その開発者はノンメンテナリリースで修正された問題のそれぞれが
新たなアップストリームバージョンで確実に修正されていること
を保証しなければなりません。

> 	  <p>
> In addition, the normal maintainer should <em>always</em> retain the
> entry in the changelog file documenting the non-maintainer upload.

	  <p>
さらに正規の開発者は、changelog ファイルのエントリに
ノンメンテナアップロードに関する記述を
<em>常に</em>残すようにしておかなければなりません。

> 	<sect1 id="nmu-build">Building source NMUs
> 	  <p>
> Source NMU packages are built normally.  Pick a distribution using the
> same rules as found in <ref id="upload-dist">.  Just as described in
> <ref id="uploading">, a normal changes file, etc., will be built.  In
> fact, all the prescriptions from <ref id="upload"> apply, including
> the need to announce the NMU to the proper lists.

	<sect1 id="nmu-build">source NMU のビルド
	  <p>
source NMU パッケージは、通常どおりにビルドされます。
ディストリビューションの選択には、
<ref id="upload-dist"> で説明したものと同じルールが適用されます。
また <ref id="uploading"> で説明したとおり、
通常の changes ファイルなどがビルドされます。
実際、<ref id="upload"> で説明したルールは、
適切なメーリングリストへの NMU のアナウンスの必要性も含めて
すべて適用されます。

> 	  <p>
> Make sure you do <em>not</em> change the value of the maintainer in
> the <file>debian/control</file> file.  Your name from the NMU entry of
> the <file>debian/changelog</file> file will be used for signing the
> changes file.

	  <p>
<file>debian/control</file> ファイルにある開発者の名前は、
変更し<em>ない</em>ように気をつけてください。
なお、<file>debian/changelog</file> ファイルの NMU エントリにある
あなたの名前は、changes ファイルに署名する際に用いられます。

-- 
Yoshizumi Endo <y-endo@xxxxxxxxxxxxxxx>