-However, if you are a porter doing an NMU for `unstable', the above
-guidelines for porting should be followed, with one variation.
-If you need to alter the source of a package in order to get a
-released port of Debian to compile, the bug you submit to the BTS
-should be of severity `important' or greater. This ensures that a
-single source package can be used to compile every supported Debian
-architecture.
- <p>
-An acceptable waiting period -- the time between when the bug is
-submitted to the BTS and when it is ok to do an NMU -- is ten days
-for porters working on the unstable distribution.
- <p>
-Try to avoid patches which simply kluge around bugs in the current
-version of the compile environment, kernel, or libc. Sometimes
-that can't be helped. If you have to kluge around compilers bugs and
-the like, make sure you <tt>#ifdef</tt> your work properly; also,
-document your kluge so that people know to remove it once the external
-problems have been fixed.
- <p>
-Porters may also have an unofficial location where they can put the results
-of their work during the waiting period. This helps others running
-the port have the benefit of the porter's work, even during the waiting
-period.
-
-
-<sect id="nmu-guidelines">How to do an NMU
- <p>
-When someone other than the usual maintainer releases a package they
-should add a new minor version number to the <var/debian-revision/ 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 <tt>foo_1.1-3.dsc</tt>. 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 <tt>foo_1.1-3.1.dsc</tt>.
- <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 made by an NMU.
- <p>
-If there is no <var/debian-revision/ 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/
-value `0.1'. The usual maintainer of a package should start their
-<var/debian-revision/ numbering at `1'. Note that if you do this,
-you'll have to invoke <prgn>dpkg-buildpackage</prgn> with the <tt/-sa/
-switch to force the build system to pick up the new source package
-(normally it only looks for Debian revisions of '0' or '1').
- <p>
-<!-- HERE -->
-Maintainers other than the usual package maintainer should make as few
-changes to the package as possible, and they should always send a
-unified context diff (<tt/diff -u/) detailing their changes to the bug
-tracking system. properly flagged with the correct package so that the
-usual maintainer is kept aware of the situation.
- <p>
-If the non-maintainer upload (as known as an ``NMU'') fixes some
-existing bugs, the bug reports should not be closed. Technically,
-only the official package maintainer or the original bug submitter are
-allowed to close bugs. However, the person making the non-maintainer
-release should send a short message to the bug tracking system to all
-the fixed bugs explaining that they have been fixed. Using
-<email/control@bugs.debian.org/, 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.
- <p>
-The normal maintainer should do at least one of the following:
- <list compact>
+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.
+
+
+ <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.
+ <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>
+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>
+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>
+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.
+
+
+ <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-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.
+ <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-only 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>
+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>
+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>
+In addition, the normal maintainer should <em>always</em> retain the
+entry in the changelog file documenting the non-maintainer upload.
+
+
+ <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.
+ <p>
+Make sure you do <em>not</em> change the value of the maintainer in
+the <file>debian/control</file> file. Your name as given in the NMU entry of
+the <file>debian/changelog</file> file will be used for signing the
+changes file.
+
+
+
+
+ <chapt id="porting">Porting and Being Ported
+ <p>
+Debian supports an ever-increasing number of architectures. Even if
+you are not a porter, and you don't use any architecture but one, it
+is part of your duty as a maintainer to be aware of issues of
+portability. Therefore, even if you are not a porter, you should read
+most of this chapter.
+ <p>
+Porting is the act of building Debian packages for architectures that
+is different from the original architecture of the package
+maintainer's binary package. It is a unique and essential activity.
+In fact, porters do most of the actual compiling of Debian packages.
+For instance, for a single <em>i386</em> binary package, there must be
+a recompile for each architecture, which is amounts to
+&number-of-arches; more builds.
+
+
+ <sect id="kind-to-porters">Being Kind to Porters
+ <p>
+Porters have a difficult and unique task, since they are required to
+deal with a large volume of packages. Ideally, every source package
+should build right out of the box. Unfortunately, this is often not
+the case. This section contains a checklist of ``gotchas'' often
+committed by Debian maintainers — common problems which often stymie
+porters, and make their jobs unnecessarily difficult.
+ <p>
+The first and most important watchword is to respond quickly to bug or
+issues raised by porters. Please treat porters with courtesy, as if
+they were in fact co-maintainers of your package (which in a way, they
+are). Please be tolerant of succinct or even unclear bug reports,
+doing your best to hunt down whatever the problem is.
+ <p>
+By far, most of the problems encountered by porters are caused by
+<em>packaging bugs</em> in the source packages. Here is a checklist
+of things you should check or be aware of.
+
+<enumlist>