-kxa</tt> in the case of PGP) for the database of keys which is
distributed from <ftpsite/ftp.debian.org/ in
<ftppath>/pub/debian/doc/debian-keyring.tar.gz</ftppath>, or the
-<package/debian-keyring/ package. Please be sure to sign your
-request message with your chosen PGP or RSA key.
+<package/debian-keyring/ package. Please be sure to sign your request
+message with your chosen public key.
<p>
Once this information is received and processed, you should be
contacted with information about your new Debian maintainer account.
If you don't hear anything within 7-14 days, please send a followup
-message asking if your original application was received. Do not
+message asking if your original application was received. Do <em/not/
re-send your original application, that will just confuse the
new-maintainer team. Please be patient, especially near release
points; mistakes do occasionally happen, and people do sometimes run
called a non-maintainer upload, or NMU.
<p>
Debian porters, who compile packages for different architectures, do
-binary NMUs as part of their normal porting activity. Less often,
-Debian developers do NMUs for other developers' packages in order to
-fix a serious security problem or a crippling bug, especially when the
-package maintainer is unable to release a fix in a timely fashion.
+NMUs as part of their normal porting activity. 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>
This chapter contains information providing guidelines for when and
-how NMUs should be done. It also contains information for when a port
-is just a port, or when it is also an NMU, and how these should be
-done.
+how NMUs should be done. A fundamental distinction is made between
+source and binary NMUs, which is explained in the next section.
<sect id="nmu-terms">Terminology
<p>
-There are two new terms used throughout this section: ``NMU'' and
-``port''. These terms are used with specific technical meaning
-throughout this document; common parlance may vary.
+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 regular maintainer. That is why it's a <em/non-maintainer/
+upload.
<p>
-Both ports and NMUs are similar, since they involve an upload of a
-package by a developer who is not the regular maintainer. In common
-parlance, ports are also NMUs since any upload of a package by a
-developer who is not the official maintainer is an NMU (i.e.,
-non-maintainer upload). However, in this chapter, I distinguish
-between ports and NMUs artificially in order to keep my meaning clear.
- <p>
-An 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. In my
-usage, NMUs always involves changes to the source (even if it is just
+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 <tt>debian/changelog</tt>). This can be either a change
to the upstream source, or a change to the Debian bits of the source.
<p>
-A port is a recompilation and upload of a binary packages for a
-specific architecture. There are ports where no source changes are
-needed and ports where the source has to be changed. In this chapter,
-``port'' means a non-maintainer uploaded binary version of a packge
-for anther version, with no source changes needed. Of course, there
-are many cases where porters must fix problems in the source in order
-to get them to compile for their target architecture; however, this
-case is considered to be an NMU rather than a port.
+A binary NMU is a recompilation and upload of a binary package for a
+new architecture. As such, it is part of ``porting''. There are
+ports of a package where no source changes are needed and ports where
+the source has to be changed. A binary NMU is non-maintainer uploaded
+binary version of a package 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 porters' source NMUs and normal NMUs.
+ <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.
- <sect id="nmu-who">Who can do a port or an NMU
+ <sect id="nmu-who">Who can do an NMU
<p>
-Only official Debian maintainers can do ports or NMUs. This is
-because we need to ensure that trojans or other problems are not
+Only official Debian maintainers can do binary or source NMUs. This
+is because we need to ensure that trojans or other problems are not
inserted into the archive. Non-developers, however, are encouraged to
-download the source package and start hacking on it to fix problems.
-Maintainers almost always appreciate quality patches and bug reports.
-Of course there are many other ways that not-yet-official volunteers
-can help. <!-- TODO: link to section talking about how
-non-maintainers can still contribute -->
+download the source package and start hacking on it to fix problems --
+just submit worthwhile patches to the Bug Tracking System.
+Maintainers almost always appreciate quality patches and bug reports
+(at least, we hope).
- <sect id="nmu-when">When to do a port or an NMU
- <p>
-Porters usually use systems such as <package/quinn-diff/ (<ref
-id="quinn-diff">) to tell them what packages need to be compiled for a
-given architecture. See <ref id="porter-guidelines"> for more
-information on how to do this type of upload. Porters are always
-uploading to either frozen or unstable.
+ <sect id="nmu-when">When to do a source NMU
<p>
-NMU guidelines for when to do an NMU depends on the target
-distribution, i.e., stable, unstable, or frozen.
+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">).
<p>
Only critical changes or security bugfixes make it into stable. When
a security bug is detected a fixed package should be uploaded as soon
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.
+package (i.e., do a 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.
+a fix for the problem. As with any source NMU, the guidelines found
+in <ref id="nmu-guidelines"> need to be followed.
<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,
few days.
<item>
Go ahead and fix the bug, submitting a patch to the right bug in the
-BTS.
+BTS. Build the package and test it as discussed in <ref
+id="upload-checking">. Use it locally.
<item>
Wait a couple of weeks for a response.
<item>
Email the maintainer, asking if it is ok to do an NMU.
<item>
-Wait a couple of weeks for a response.
- <item>
Double check that your patch doesn't have any unexpected side effects.
-Build the package and test it as discussed in <ref id="upload-checking">.
+Make sure your patch is as small and as non-disruptive as it can be.
+ <item>
+Wait another week for a response.
+ <item>
+Go ahead and do the source NMU, as described in <ref
+id="nmu-guidelines">.
</list>
- <sect1>When to do an NMU if you are a porter
+
+ <sect1 id="source-nmu-when-porter">When to do a source NMU if you are a porter
<p>
-Porters doing an NMU as well -- i.e., if the source needs changing --
-generally follow the above guidelines, just like normal NMUs.
-However, it is expected that the wait cycle for a porter NMU is
-smaller than normal, since porters have to cope with a high quantity
-of packages.
+Porters doing a source NMU generally follow the above guidelines, just
+like non-porters. However, it is expected that the wait cycle for a
+porter's source NMU is smaller than for a non-porter, since porters
+have to cope with a large quantity of packages.
<p>
-Again, the situation will vary depending on the distribution they are
+Again, the situation varies depending on the distribution they are
uploading to. Crucial fixes (i.e., changes need to get a source
package to compile for a released-targetted architecture) can be
uploaded with <em/no/ waiting period for the `frozen' distribution.
However, if you are a porter doing an NMU for `unstable', the above
guidelines for porting should be followed, with two variations.
Firstly, the 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
+bug is submitted to the BTS and when it is ok to do an NMU -- is seven
days for porters working on the unstable distribution.
<p>
-Secondly, porters doing NMUs should make sure that the bug they 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 by release time.
- <p>
-Try to avoid patches which simply kluge around bugs in the current
-version of the compile environment, kernel, or libc. Sometimes such
-kluges 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.
+Secondly, porters doing source NMUs should make sure that the bug they
+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 by release time. It is very important
+that we have one version of the binary and source package for all
+architecture in order to comply with many licenses.
+ <p>
+Porters should try to avoid patches which simply kluge around bugs in
+the current version of the compile environment, kernel, or libc.
+Sometimes such kluges 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. Of course such waiting periods have no official
-blessing from Debian.
+the waiting period. Of course, such locations have no official
+blessing or status, so buyer, beware.
- <sect id="nmu-guidelines">How to do an NMU
- <p>
-This section applies to NMUs, but not, necessarily, to porters.
-Remember that we are making a distinction between a <em/port/ and an
-<em/NMU/ (see <ref id="nmu-terms">).
+ <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 NMU bug-fixers and porters. If a porter has to
-change the Debian source archive, automatically their upload is an NMU
-and is subject to its rules. If a porter is simply uploading a port,
-the rules are different; see <ref id="porter-guidelines">.
-
-
- <sect1 id="nmu-version">NMU version numbering
+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">.
+ <p>
+First and foremost, it is critical that NMU patches to source should
+be as non-disruptive as possible. Do not do housekeeping task, change
+the name of modules, move directories, or fix things which are not
+broken. Keep the patch as small as possible. If thing bother you
+aesthetically, talk to the Debian maintainer, talk to the upstream
+maintainer, or submit a bug. However, aesthetic changes must <em/not/
+be made by non-maintainers.
+
+
+ <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 actually work.
+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/ part of the version
`.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 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.
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'; it's not clever enough yet to know
-about `0.1').
+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 NMU
-version numbers if and only if they actually have to modify the source
-package in some way.
+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">NMUs must create a changelog entry
+ <sect1 id="nmu-changelog">Source NMUs must have a new changelog entry
<p>
-A non-maintainer doing an NMU must create a changelog entry,
+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>
+By convention, source NMU changelog entries start with the line
+<example>
+ * Non-maintainer upload
+</example>
- <sect1 id="nmu-patch">NMUs must send patches, if any, to the BTS
+ <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/) detailing their
-changes, if any, to the bug tracking system.
+changes, if any, 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 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/), there <em/will/ be a
-changelog entry; therefore, there will be a patch.
+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/), 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 maintainer our archive.)
<p>
-If the NMU (non-maintainer upload) fixes some existing bugs, the bugs
-which are fixed need to be <em/notified/ but not actually <em/closed/
-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, including the patch for that NMU, to the relevant
-bugs explaining that the bugs have been fixed by the NMU. 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.
+If the sounce NMU (non-maintainer upload) fixes some existing bugs,
+the bugs in the Bug Tracking System which are fixed need to be
+<em/notified/ but not actually <em/closed/ 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, including the patch
+for that NMU, to the relevant bugs explaining that the bugs have been
+fixed by the NMU. 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 will either apply the patch or employ an
alternate method of fixing the problem. Sometimes bugs are fixed
-independantly upstream; which is another good reason to back out an
+independantly 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, read the description of the changes to
-the next upstream version and ensure that they fix each problem that
-was fixed in the non-maintainer release.
+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/ include an entry
+In addition, the normal maintainer should <em/always/ retain the entry
in the changelog file documenting the non-maintainer upload.
- <sect1 id="nmu-build">Building the NMU
+ <sect1 id="nmu-build">Building source NMUs
<p>
-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 presecriptions from <ref id="upload"> apply, including the
-need to announce the NMU to the proper lists.
+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/ change the value of the maintainer in the
<tt>debian/control</tt> file. Your name from the NMU entry of the
file.
- <sect id="porter-guidelines">Guidelines for Porters
+ <sect id="porter-guidelines">Guidelines for porters (binary NMUs)
<p>
If the package builds out of the box for the architecture to be ported
to, you are in luck and your job is easy. This section applies to
-that case; it describes how to build and upload your NMU so that it is
-properly installed into the archive. If you do have to patch the
-package in order to get it to compile for the other architecture, read
-<ref id="nmu-guidelines"> instead.
+that case; it describes how to build and upload your binary NMU so
+that it is properly installed into the archive. If you do have to
+patch the package in order to get it to compile for the other
+architecture, you are actually doing a source NMU, so consult <ref
+id="nmu-guidelines"> instead.
<p>
-Since no real changes are being made to the source, you do not need to
-touch any of the files in the source package. This includes
-<tt>debian/changelog</tt>.
+In a binary NMU, no real changes are being made to the source. You do
+not need to touch any of the files in the source package. This
+includes <tt>debian/changelog</tt>.
<p>
The way to invoke <prgn/dpkg-buildpackage/ is as <tt>dpkg-buildpackage
-B -m<var/porter-email/</tt>. Of course, set <var/porter-email/ to
your email address. This will do a binary-only build of only the
-architecture-dependant portions of the package. In case of a somewhat
-broken <tt>debian/rules</tt> file, resorting to <tt>dpkg-buildpackage
--b -m<var/porter-email/</tt> is also acceptable. But remember to file
-a bug against the package that the <tt/binary-arch/ rule is broken!
-
+architecture-dependant portions of the package, using the
+<tt>binary-arch</tt> target in <tt>debian/rules</tt>.
<chapt id="archive-manip"><heading>Moving, Removing, Renaming,
/var/cache/apt/pkgcache.bin <var/package/</tt>, the program will show
details for <var/package/, including reverse depends.
+ <sect1>Removing packages from <tt/Incoming/
+ <p>
+If you decide to remove a package from <tt/Incoming/, it is nice but
+not required to send a notification of that to the appropriate
+announce list (either <email/debian-changes@lists.debian.org/ or
+<email/debian-devel-changes@lists.debian.org/).
+
<sect>Replacing or renaming packages
<p>
Sometimes you made a mistake naming the package and you need to rename
simply want to know if any one is working on a new package, send a
message to <email/wnpp@debian.org/.
<p>
+It is not ok to simply take over a package that you feel is neglected
+-- that would be package hijacking. You can, of course, contact the
+current maintainer and ask them if you may take over the package.
+However, without their assent, you may not take over the package.
+Even if they ignore you, that is still not grounds to take over a
+package. If you really feel that a maintainer has gone AWOL (absent
+without leave), post a query to
+<email/debian-private@lists.debian.org/.
+ <p>
If you take over an old package, you probably want to be listed as the
package's official maintainer in the bug system. This will happen
automatically once you upload a new version with an updated
~ianmdlvl / developers-reference.git / commitdiff