+There are several tools available for the porting effort. This section
+contains a brief introduction to these tools; see the package
+documentation or references for full information.
+
+
+ <sect1 id="quinn-diff">
+ <heading><package>quinn-diff</package>
+ <p>
+<package/quinn-diff/ is used to locate the differences from one
+architecture to another. For instance, it could tell you which
+packages need to be ported for architecture <var/Y/, based on
+architecture <var/X/.
+
+
+ <sect1 id="buildd">
+ <heading><package>buildd</package>
+ <p>
+<package/buildd/ is not yet available! However, it collects a number
+of as yet unpackaged components which are currently in production
+(such as <prgn/debbuild/ and <prgn/wanna-build/.
+ <p>
+The <package/buildd/ system is used as a distributed, client-server
+build distribution system. It is usually used in conjunction with
+<em/auto-builders/, which are ``slave'' hosts which simply check out
+and attempt to auto-build packages which need to be ported. There is
+also an email interface to the system, which allows porters to ``check
+out'' a source package (usually one which cannot yet be autobuilt) and
+work on it.
+ <p>
+We are very excited about this system, since it potentially has so
+many uses. Independent development groups can use the system for
+different sub-flavors of Debian, which may or may not really be of
+general interest (for instance, a flavor of Debian built with gcc
+bounds checking). It will also enable Debian to recompile entire
+distributions quickly.
+
+
+ <sect1 id="dpkg-cross">
+ <heading><package>dpkg-cross</package>
+ <p>
+<package>dpkg-cross</package> is a tool for installing libraries and
+headers for cross-compiling in a way similar to
+<package>dpkg</package>. Furthermore, the functionality of
+<prgn>dpkg-buildpackage</prgn> and <prgn>dpkg-shlibdeps</prgn> is
+enhanced to support cross-compiling.
+
+
+
+
+ <chapt id="archive-manip"><heading>Moving, Removing, Renaming,
+ Adopting, and Orphaning Packages</heading>
+ <p>
+Some archive manipulation operation are not automated in the Debian
+upload process. These procedures should be manually followed by
+maintainers. This chapter gives guidelines in what to do in these
+cases.
+
+ <sect>Moving packages
+ <p>
+Sometimes a package will change either its section or its subsection.
+For instance, a package from the `non-free' section might be GPL'd in
+a later version; in this case you should consider moving it to `main'
+or `contrib' (see the <url
+id="http://www.debian.org/doc/debian-policy/" name="Debian Policy
+Manual"> for guidelines).
+ <p>
+In this case, it is sufficient to edit the package control information
+normally and re-upload the package (see the <url
+id="http://www.debian.org/doc/packaging-manuals/packaging.html/"
+name="Debian Packaging Manual"> for
+details). Carefully examine the installation log sent to you when the
+package is installed into the archive. If for some reason the old
+location of the package remains, file a bug against
+<tt/ftp.debian.org/ asking that the old location be removed. Give
+details on what you did, since it might be a <prgn/dinstall/ bug.
+
+
+ <sect>Removing packages
+ <p>
+If for some reason you want to completely remove a package (say, if it
+is an old compatibility library which is not longer required), you
+need to file a bug against <tt/ftp.debian.org/ asking that the
+package be removed. Make sure you indicate which distribution the
+package should be removed from.
+ <p>
+If in doubt concerning whether a package is disposable, email
+<email/debian-devel@lists.debian.org/ asking for opinions. Also of
+interest is the <prgn/apt-cache/ program from the <package/apt/
+package. When invoked as <tt>apt-cache showpkg
+/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
+it. In this case, you need to follow a two-step process. First, set
+your <file>debian/control</file> file to replace and conflict with the
+obsolete name of the package (see the <url
+id="http://www.debian.org/doc/packaging-manuals/packaging.html/"
+name="Debian Packaging Manual"> for details). Once you've uploaded
+that package, and the package has moved into the archive, file a bug
+against <tt/ftp.debian.org/ asking to remove the package with the
+obsolete name.
+
+
+
+ <sect id="orphaning">Orphaning a package
+ <p>
+If you can no longer maintain a package, then you should set the
+package maintainer to <tt>Debian QA Group
+<debian-qa@lists.debian.org></tt> and email
+<email/wnpp@debian.org/ indicating that the package is now orphaned.
+If the package is especially crucial to Debian, you should instead
+email <email/debian-devel@lists.debian.org/ asking for a new
+maintainer.
+
+
+ <sect id="adopting">Adopting a package
+ <p>
+Periodically, a listing of packages in need of new maintainers will be
+sent to <email/debian-devel@lists.debian.org</email> list. This list
+is also available at in the Work-Needing and Prospective Packages
+document (WNPP), <url
+id="ftp://ftp.debian.org/debian/doc/package-developer/prospective-packages.html">
+and at <url id="http://www.debian.org/doc/prospective-packages.html">.
+If you wish to take over maintenance of any of the packages listed in
+the WNPP, or if you can no longer maintain a packages you have, or you
+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
+<tt/Maintainer:/ field, although it can take a couple of weeks. If you
+do not expect to upload a new version for a while, send an email to
+<email/override-change@debian.org/ so that bug reports will go to you
+right away.
+
+
+
+
+ <chapt id="bug-handling">Handling Bugs
+
+ <sect>Monitoring bugs
+ <p>
+If you want to be a good maintainer, you should periodically check the
+<url id="http://www.debian.org/Bugs/" name="Debian bug tracking system
+(BTS)"> for your packages. The BTS contains all the open bugs against
+your packages.
+ <p>
+Maintainers interact with the BTS via email addresses at
+<tt/bugs.debian.org/. Documentation on available commands can be
+found at <url id="http://www.debian.org/Bugs/">, or, if you have
+installed the <package/debian-doc/ package, you can look at the local
+files <file>/usr/doc/debian/bug-*</file>.
+ <p>
+Some find it useful to get periodic reports on open bugs. You can add
+a cron job such as the following if you want to get a weekly email
+outlining all the open bugs against your packages:
+<example>
+# ask for weekly reports of bugs in my packages
+0 17 * * fri echo "index maint <var>maintainer-address</var>" | mail request@bugs.debian.org
+</example>
+Replace <var>maintainer-address</var> with you official Debian
+maintainer address.
+
+ <sect>Submitting Bugs
+ <p>
+Often as a package maintainer, you find bugs in other packages or else
+have bugs reported to your packages which need to be reassigned. The
+BTS <url id="http://www.debian.org/Bugs/server-control.html"
+name="instructions"> can tell you how to do this.
+ <p>
+We encourage you to file bugs when there are problems. Try to submit
+the bug from a normal user account at which you are likely to receive
+mail. Do not submit bugs as root.
+ <p>
+Make sure the bug is not already filed against a package. Try to do a
+good job reporting a bug and redirecting it to the proper location.
+For extra credit, you can go through other packages, merging bugs
+which are reported more than once, or setting bug severities to
+`fixed' when they have already been fixed. Note that when you are
+neither the bug submitter nor the package maintainer, you are should
+not actually close the bug (unless you secure permission from the
+maintainer).
+
+ <sect>Responding to Bugs