+# SOME DESCRIPTIVE TITLE
+# Copyright (C) YEAR Free Software Foundation, Inc.
+# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
+#
+#, fuzzy
+msgid ""
+msgstr ""
+"Project-Id-Version: PACKAGE VERSION\n"
+"POT-Creation-Date: 2007-06-26 16:13+0000\n"
+"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
+"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
+"Language-Team: LANGUAGE <LL@li.org>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=utf-8\n"
+"Content-Transfer-Encoding: ENCODING"
+
+# type: Content of: <chapter><title>
+#: pkgs.dbk:5
+msgid "Managing Packages"
+msgstr ""
+
+# type: Content of: <chapter><para>
+#: pkgs.dbk:7
+msgid ""
+"This chapter contains information related to creating, uploading, "
+"maintaining, and porting packages."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:11
+msgid "New packages"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:13
+msgid ""
+"If you want to create a new package for the Debian distribution, you should "
+"first check the <ulink "
+"url=\"http://www.debian.org/devel/wnpp/\">Work-Needing and Prospective "
+"Packages (WNPP)</ulink> list. Checking the WNPP list ensures that no one is "
+"already working on packaging that software, and that effort is not "
+"duplicated. Read the <ulink url=\"http://www.debian.org/devel/wnpp/\">WNPP "
+"web pages</ulink> for more information."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:21
+msgid ""
+"Assuming no one else is already working on your prospective package, you "
+"must then submit a bug report (<xref linkend=\"submit-bug\"/> ) against the "
+"pseudo-package <systemitem role=\"package\">wnpp</systemitem> describing "
+"your plan to create a new package, including, but not limiting yourself to, "
+"a description of the package, the license of the prospective package, and "
+"the current URL where it can be downloaded from."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:29
+msgid ""
+"You should set the subject of the bug to ``ITP: "
+"<replaceable>foo</replaceable> -- <replaceable>short "
+"description</replaceable>'', substituting the name of the new package for "
+"<replaceable>foo</replaceable>. The severity of the bug report must be set "
+"to <emphasis>wishlist</emphasis>. If you feel it's necessary, send a copy "
+"to <email>debian-devel@lists.debian.org</email> by putting the address in "
+"the <literal>X-Debbugs-CC:</literal> header of the message (no, don't use "
+"<literal>CC:</literal>, because that way the message's subject won't "
+"indicate the bug number)."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:39
+msgid ""
+"Please include a <literal>Closes: "
+"bug#<replaceable>nnnnn</replaceable></literal> entry in the changelog of the "
+"new package in order for the bug report to be automatically closed once the "
+"new package is installed in the archive (see <xref "
+"linkend=\"upload-bugfix\"/> )."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:45
+msgid ""
+"When closing security bugs include CVE numbers as well as the Closes: "
+"#nnnnn. This is useful for the security team to track vulnerabilities. If "
+"an upload is made to fix the bug before the advisory ID is known, it is "
+"encouraged to modify the historical changelog entry with the next upload. "
+"Even in this case, please include all available pointers to background "
+"information in the original changelog entry."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:53
+msgid ""
+"There are a number of reasons why we ask maintainers to announce their "
+"intentions:"
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:59
+msgid ""
+"It helps the (potentially new) maintainer to tap into the experience of "
+"people on the list, and lets them know if anyone else is working on it "
+"already."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:65
+msgid ""
+"It lets other people thinking about working on the package know that there "
+"already is a volunteer, so efforts may be shared."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:71
+msgid ""
+"It lets the rest of the maintainers know more about the package than the one "
+"line description and the usual changelog entry ``Initial release'' that gets "
+"posted to <literal>debian-devel-changes</literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:78
+msgid ""
+"It is helpful to the people who live off unstable (and form our first line "
+"of testers). We should encourage these people."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:84
+msgid ""
+"The announcements give maintainers and other interested parties a better "
+"feel of what is going on, and what is new, in the project."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:90
+msgid ""
+"Please see <ulink "
+"url=\"http://ftp-master.debian.org/REJECT-FAQ.html\"></ulink> for common "
+"rejection reasons for a new package."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:96
+msgid "Recording changes in the package"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:98
+msgid ""
+"Changes that you make to the package need to be recorded in the "
+"<filename>debian/changelog</filename>. These changes should provide a "
+"concise description of what was changed, why (if it's in doubt), and note if "
+"any bugs were closed. They also record when the package was completed. "
+"This file will be installed in "
+"<filename>/usr/share/doc/<replaceable>package</replaceable>/changelog.Debian.gz</filename>, "
+"or "
+"<filename>/usr/share/doc/<replaceable>package</replaceable>/changelog.gz</filename> "
+"for native packages."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:109
+msgid ""
+"The <filename>debian/changelog</filename> file conforms to a certain "
+"structure, with a number of different fields. One field of note, the "
+"<emphasis>distribution</emphasis>, is described in <xref "
+"linkend=\"distribution\"/> . More information about the structure of this "
+"file can be found in the Debian Policy section titled "
+"<filename>debian/changelog</filename>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:117
+msgid ""
+"Changelog entries can be used to automatically close Debian bugs when the "
+"package is installed into the archive. See <xref "
+"linkend=\"upload-bugfix\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:121
+msgid ""
+"It is conventional that the changelog entry of a package that contains a new "
+"upstream version of the software looks like this:"
+msgstr ""
+
+# type: Content of: <chapter><section><screen>
+#: pkgs.dbk:125
+#, no-wrap
+msgid "* new upstream version"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:128
+msgid ""
+"There are tools to help you create entries and finalize the "
+"<filename>changelog</filename> for release — see <xref "
+"linkend=\"devscripts\"/> and <xref linkend=\"dpkg-dev-el\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:133
+msgid "See also <xref linkend=\"bpp-debian-changelog\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:138
+msgid "Testing the package"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:140
+msgid ""
+"Before you upload your package, you should do basic testing on it. At a "
+"minimum, you should try the following activities (you'll need to have an "
+"older version of the same Debian package around):"
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:147
+msgid ""
+"Install the package and make sure the software works, or upgrade the package "
+"from an older version to your new version if a Debian package for it already "
+"exists."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:154
+msgid ""
+"Run <command>lintian</command> over the package. You can run "
+"<command>lintian</command> as follows: <literal>lintian -v "
+"<replaceable>package-version</replaceable>.changes</literal>. This will "
+"check the source package as well as the binary package. If you don't "
+"understand the output that <command>lintian</command> generates, try adding "
+"the <literal>-i</literal> switch, which will cause "
+"<command>lintian</command> to output a very verbose description of the "
+"problem."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:163
+msgid ""
+"Normally, a package should <emphasis>not</emphasis> be uploaded if it causes "
+"lintian to emit errors (they will start with <literal>E</literal>)."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:167
+msgid ""
+"For more information on <command>lintian</command>, see <xref "
+"linkend=\"lintian\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:173
+msgid ""
+"Optionally run <xref linkend=\"debdiff\"/> to analyze changes from an older "
+"version, if one exists."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:179
+msgid ""
+"Downgrade the package to the previous version (if one exists) — this tests "
+"the <filename>postrm</filename> and <filename>prerm</filename> scripts."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:185
+msgid "Remove the package, then reinstall it."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:190
+msgid ""
+"Copy the source package in a different directory and try unpacking it and "
+"rebuilding it. This tests if the package relies on existing files outside "
+"of it, or if it relies on permissions being preserved on the files shipped "
+"inside the .diff.gz file."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:200
+msgid "Layout of the source package"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:202
+msgid "There are two types of Debian source packages:"
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:207
+msgid ""
+"the so-called <emphasis>native</emphasis> packages, where there is no "
+"distinction between the original sources and the patches applied for Debian"
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:213
+msgid ""
+"the (more common) packages where there's an original source tarball file "
+"accompanied by another file that contains the patches applied for Debian"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:219
+msgid ""
+"For the native packages, the source package includes a Debian source control "
+"file (<literal>.dsc</literal>) and the source tarball "
+"(<literal>.tar.gz</literal>). A source package of a non-native package "
+"includes a Debian source control file, the original source tarball "
+"(<literal>.orig.tar.gz</literal>) and the Debian patches "
+"(<literal>.diff.gz</literal>)."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:227
+msgid ""
+"Whether a package is native or not is determined when it is built by "
+"<citerefentry> <refentrytitle>dpkg-buildpackage</refentrytitle> "
+"<manvolnum>1</manvolnum> </citerefentry>. The rest of this section relates "
+"only to non-native packages."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:233
+msgid ""
+"The first time a version is uploaded which corresponds to a particular "
+"upstream version, the original source tar file should be uploaded and "
+"included in the <filename>.changes</filename> file. Subsequently, this very "
+"same tar file should be used to build the new diffs and "
+"<filename>.dsc</filename> files, and will not need to be re-uploaded."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:240
+msgid ""
+"By default, <command>dpkg-genchanges</command> and "
+"<command>dpkg-buildpackage</command> will include the original source tar "
+"file if and only if the Debian revision part of the source version number is "
+"0 or 1, indicating a new upstream version. This behavior may be modified by "
+"using <literal>-sa</literal> to always include it or <literal>-sd</literal> "
+"to always leave it out."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:248
+msgid ""
+"If no original source is included in the upload, the original source "
+"tar-file used by <command>dpkg-source</command> when constructing the "
+"<filename>.dsc</filename> file and diff to be uploaded "
+"<emphasis>must</emphasis> be byte-for-byte identical with the one already in "
+"the archive."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:255
+msgid ""
+"Please notice that, in non-native packages, permissions on files that are "
+"not present in the .orig.tar.gz will not be preserved, as diff does not "
+"store file permissions in the patch."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:262
+msgid "Picking a distribution"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:264
+msgid ""
+"Each upload needs to specify which distribution the package is intended "
+"for. The package build process extracts this information from the first "
+"line of the <filename>debian/changelog</filename> file and places it in the "
+"<literal>Distribution</literal> field of the <literal>.changes</literal> "
+"file."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:270
+msgid ""
+"There are several possible values for this field: `stable', `unstable', "
+"`testing-proposed-updates' and `experimental'. Normally, packages are "
+"uploaded into <emphasis>unstable</emphasis>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:275
+msgid ""
+"Actually, there are two other possible distributions: `stable-security' and "
+"`testing-security', but read <xref linkend=\"bug-security\"/> for more "
+"information on those."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:280
+msgid ""
+"It is not possible to upload a package into several distributions at the "
+"same time."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:284
+msgid "Special case: uploads to the <emphasis>stable</emphasis> distribution"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:286
+msgid ""
+"Uploading to <emphasis>stable</emphasis> means that the package will "
+"transfered to the <emphasis>p-u-new</emphasis>-queue for review by the "
+"stable release managers, and if approved will be installed in "
+"<filename>stable-proposed-updates</filename> directory of the Debian "
+"archive. From there, it will be included in <emphasis>stable</emphasis> "
+"with the next point release."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:294
+msgid ""
+"Extra care should be taken when uploading to <emphasis>stable</emphasis>. "
+"Basically, a package should only be uploaded to stable if one of the "
+"following happens:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:301
+msgid "a truly critical functionality problem"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:306
+msgid "the package becomes uninstallable"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:311
+msgid "a released architecture lacks the package"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:316
+msgid ""
+"In the past, uploads to <emphasis>stable</emphasis> were used to address "
+"security problems as well. However, this practice is deprecated, as uploads "
+"used for Debian security advisories are automatically copied to the "
+"appropriate <filename>proposed-updates</filename> archive when the advisory "
+"is released. See <xref linkend=\"bug-security\"/> for detailed information "
+"on handling security problems."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:324
+msgid ""
+"Changing anything else in the package that isn't important is discouraged, "
+"because even trivial fixes can cause bugs later on."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:328
+msgid ""
+"Packages uploaded to <emphasis>stable</emphasis> need to be compiled on "
+"systems running <emphasis>stable</emphasis>, so that their dependencies are "
+"limited to the libraries (and other packages) available in "
+"<emphasis>stable</emphasis>; for example, a package uploaded to "
+"<emphasis>stable</emphasis> that depends on a library package that only "
+"exists in unstable will be rejected. Making changes to dependencies of "
+"other packages (by messing with <literal>Provides</literal> or shlibs "
+"files), possibly making those other packages uninstallable, is strongly "
+"discouraged."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:338
+msgid ""
+"The Release Team (which can be reached at "
+"<email>debian-release@lists.debian.org</email>) will regularly evaluate the "
+"uploads To <emphasis>stable-proposed-updates</emphasis> and decide if your "
+"package can be included in <emphasis>stable</emphasis>. Please be clear "
+"(and verbose, if necessary) in your changelog entries for uploads to "
+"<emphasis>stable</emphasis>, because otherwise the package won't be "
+"considered for inclusion."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:347
+msgid ""
+"It's best practice to speak with the stable release manager "
+"<emphasis>before</emphasis> uploading to "
+"<emphasis>stable</emphasis>/<emphasis>stable-proposed-updates</emphasis>, so "
+"that the uploaded package fits the needs of the next point release."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:355
+msgid ""
+"Special case: uploads to "
+"<emphasis>testing/testing-proposed-updates</emphasis>"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:357
+msgid ""
+"Please see the information in the <link linkend=\"t-p-u\">testing "
+"section</link> for details."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:365
+msgid "Uploading a package"
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:367
+msgid "Uploading to <literal>ftp-master</literal>"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:369
+msgid ""
+"To upload a package, you should upload the files (including the signed "
+"changes and dsc-file) with anonymous ftp to "
+"<literal>ftp-master.debian.org</literal> in the directory <ulink "
+"url=\"ftp://ftp-master.debian.org/pub/UploadQueue/\">/pub/UploadQueue/</ulink>. "
+"To get the files processed there, they need to be signed with a key in the "
+"debian keyring."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:377
+msgid ""
+"Please note that you should transfer the changes file last. Otherwise, your "
+"upload may be rejected because the archive maintenance software will parse "
+"the changes file and see that not all files have been uploaded."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:382
+msgid ""
+"You may also find the Debian packages <xref linkend=\"dupload\"/> or <xref "
+"linkend=\"dput\"/> useful when uploading packages. These handy programs "
+"help automate the process of uploading packages into Debian."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:387
+msgid ""
+"For removing packages, please see the README file in that ftp directory, and "
+"the Debian package <xref linkend=\"dcut\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:393
+msgid "Uploading to <literal>non-US</literal>"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:395
+msgid ""
+"<emphasis>Note:</emphasis> non-us was discontinued with the release of "
+"sarge."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:400
+msgid "Delayed uploads"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:402
+msgid ""
+"Delayed uploads are done for the moment via the delayed queue at gluck. The "
+"upload-directory is "
+"<literal>gluck:~tfheen/DELAYED/[012345678]-day</literal>. 0-day is uploaded "
+"multiple times per day to ftp-master."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:407
+msgid "With a fairly recent dput, this section"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: pkgs.dbk:410
+#, no-wrap
+msgid ""
+"[tfheen_delayed]\n"
+"method = scp\n"
+"fqdn = gluck.debian.org\n"
+"incoming = ~tfheen"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:416
+msgid "in ~/.dput.cf should work fine for uploading to the DELAYED queue."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:419
+msgid ""
+"<emphasis>Note:</emphasis> Since this upload queue goes to "
+"<literal>ftp-master</literal>, the prescription found in <xref "
+"linkend=\"upload-ftp-master\"/> applies here as well."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:426
+msgid "Security uploads"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:428
+msgid ""
+"Do <emphasis role=\"strong\">NOT</emphasis> upload a package to the security "
+"upload queue (oldstable-security, stable-security, etc.) without prior "
+"authorization from the security team. If the package does not exactly meet "
+"the team's requirements, it will cause many problems and delays in dealing "
+"with the unwanted upload. For details, please see section <xref "
+"linkend=\"bug-security\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:438
+msgid "Other upload queues"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:440
+msgid ""
+"The scp queues on ftp-master, and security are mostly unusable due to the "
+"login restrictions on those hosts."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:444
+msgid ""
+"The anonymous queues on ftp.uni-erlangen.de and ftp.uk.debian.org are "
+"currently down. Work is underway to resurrect them."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:448
+msgid ""
+"The queues on master.debian.org, samosa.debian.org, master.debian.or.jp, and "
+"ftp.chiark.greenend.org.uk are down permanently, and will not be "
+"resurrected. The queue in Japan will be replaced with a new queue on "
+"hp.debian.or.jp some day."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:454
+msgid ""
+"For the time being, the anonymous ftp queue on auric.debian.org (the former "
+"ftp-master) works, but it is deprecated and will be removed at some point in "
+"the future."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:461
+msgid "Notification that a new package has been installed"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:463
+msgid ""
+"The Debian archive maintainers are responsible for handling package "
+"uploads. For the most part, uploads are automatically handled on a daily "
+"basis by the archive maintenance tools, <command>katie</command>. "
+"Specifically, updates to existing packages to the `unstable' distribution "
+"are handled automatically. In other cases, notably new packages, placing "
+"the uploaded package into the distribution is handled manually. When "
+"uploads are handled manually, the change to the archive may take up to a "
+"month to occur. Please be patient."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:472
+msgid ""
+"In any case, you will receive an email notification indicating that the "
+"package has been added to the archive, which also indicates which bugs will "
+"be closed by the upload. Please examine this notification carefully, "
+"checking if any bugs you meant to close didn't get triggered."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:478
+msgid ""
+"The installation notification also includes information on what section the "
+"package was inserted into. If there is a disparity, you will receive a "
+"separate email notifying you of that. Read on below."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:483
+msgid ""
+"Note that if you upload via queues, the queue daemon software will also send "
+"you a notification by email."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:491
+msgid "Specifying the package section, subsection and priority"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:493
+msgid ""
+"The <filename>debian/control</filename> file's <literal>Section</literal> "
+"and <literal>Priority</literal> fields do not actually specify where the "
+"file will be placed in the archive, nor its priority. In order to retain "
+"the overall integrity of the archive, it is the archive maintainers who have "
+"control over these fields. The values in the "
+"<filename>debian/control</filename> file are actually just hints."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:501
+msgid ""
+"The archive maintainers keep track of the canonical sections and priorities "
+"for packages in the <emphasis>override file</emphasis>. If there is a "
+"disparity between the <emphasis>override file</emphasis> and the package's "
+"fields as indicated in <filename>debian/control</filename>, then you will "
+"receive an email noting the divergence when the package is installed into "
+"the archive. You can either correct your "
+"<filename>debian/control</filename> file for your next upload, or else you "
+"may wish to make a change in the <emphasis>override file</emphasis>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:511
+msgid ""
+"To alter the actual section that a package is put in, you need to first make "
+"sure that the <filename>debian/control</filename> file in your package is "
+"accurate. Next, send an email <email>override-change@debian.org</email> or "
+"submit a bug against <systemitem "
+"role=\"package\">ftp.debian.org</systemitem> requesting that the section or "
+"priority for your package be changed from the old section or priority to the "
+"new one. Be sure to explain your reasoning."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:519
+msgid ""
+"For more information about <emphasis>override files</emphasis>, see "
+"<citerefentry> <refentrytitle>dpkg-scanpackages</refentrytitle> "
+"<manvolnum>1</manvolnum> </citerefentry> and <ulink "
+"url=\"http://www.debian.org/Bugs/Developer#maintincorrect\"></ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:525
+msgid ""
+"Note that the <literal>Section</literal> field describes both the section as "
+"well as the subsection, which are described in <xref "
+"linkend=\"archive-sections\"/> . If the section is main, it should be "
+"omitted. The list of allowable subsections can be found in <ulink "
+"url=\"http://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections\"></ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:534
+msgid "Handling bugs"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:536
+msgid ""
+"Every developer has to be able to work with the Debian <ulink "
+"url=\"http://www.debian.org/Bugs/\">bug tracking system</ulink>. This "
+"includes knowing how to file bug reports properly (see <xref "
+"linkend=\"submit-bug\"/> ), how to update them and reorder them, and how to "
+"process and close them."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:542
+msgid ""
+"The bug tracking system's features are described in the <ulink "
+"url=\"http://www.debian.org/Bugs/Developer\">BTS documentation for "
+"developers</ulink>. This includes closing bugs, sending followup messages, "
+"assigning severities and tags, marking bugs as forwarded, and other issues."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:548
+msgid ""
+"Operations such as reassigning bugs to other packages, merging separate bug "
+"reports about the same issue, or reopening bugs when they are prematurely "
+"closed, are handled using the so-called control mail server. All of the "
+"commands available on this server are described in the <ulink "
+"url=\"http://www.debian.org/Bugs/server-control\">BTS control server "
+"documentation</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:556
+msgid "Monitoring bugs"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:558
+msgid ""
+"If you want to be a good maintainer, you should periodically check the "
+"<ulink url=\"http://www.debian.org/Bugs/\">Debian bug tracking system "
+"(BTS)</ulink> for your packages. The BTS contains all the open bugs against "
+"your packages. You can check them by browsing this page: "
+"<literal>http://bugs.debian.org/<replaceable>yourlogin</replaceable>@debian.org</literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:565
+msgid ""
+"Maintainers interact with the BTS via email addresses at "
+"<literal>bugs.debian.org</literal>. Documentation on available commands can "
+"be found at <ulink url=\"http://www.debian.org/Bugs/\"></ulink>, or, if you "
+"have installed the <systemitem role=\"package\">doc-debian</systemitem> "
+"package, you can look at the local files "
+"<filename>/usr/share/doc/debian/bug-*</filename>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:572
+msgid ""
+"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:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: pkgs.dbk:577
+#, no-wrap
+msgid ""
+"# ask for weekly reports of bugs in my packages\n"
+"0 17 * * fri echo index maint <replaceable>address</replaceable> | mail "
+"request@bugs.debian.org"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:581
+msgid ""
+"Replace <replaceable>address</replaceable> with your official Debian "
+"maintainer address."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:587
+msgid "Responding to bugs"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:589
+msgid ""
+"When responding to bugs, make sure that any discussion you have about bugs "
+"is sent both to the original submitter of the bug, and to the bug itself "
+"(e.g., <email>123@bugs.debian.org</email>). If you're writing a new mail "
+"and you don't remember the submitter email address, you can use the "
+"<email>123-submitter@bugs.debian.org</email> email to contact the submitter "
+"<emphasis>and</emphasis> to record your mail within the bug log (that means "
+"you don't need to send a copy of the mail to "
+"<email>123@bugs.debian.org</email>)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:598
+msgid ""
+"If you get a bug which mentions FTBFS, this means Fails to build from "
+"source. Porters frequently use this acronym."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:602
+msgid ""
+"Once you've dealt with a bug report (e.g. fixed it), mark it as "
+"<emphasis>done</emphasis> (close it) by sending an explanation message to "
+"<email>123-done@bugs.debian.org</email>. If you're fixing a bug by changing "
+"and uploading the package, you can automate bug closing as described in "
+"<xref linkend=\"upload-bugfix\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:609
+msgid ""
+"You should <emphasis>never</emphasis> close bugs via the bug server "
+"<literal>close</literal> command sent to "
+"<email>control@bugs.debian.org</email>. If you do so, the original "
+"submitter will not receive any information about why the bug was closed."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:617
+msgid "Bug housekeeping"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:619
+msgid ""
+"As a package maintainer, you will often find bugs in other packages or have "
+"bugs reported against your packages which are actually bugs in other "
+"packages. The bug tracking system's features are described in the <ulink "
+"url=\"http://www.debian.org/Bugs/Developer\">BTS documentation for Debian "
+"developers</ulink>. Operations such as reassigning, merging, and tagging "
+"bug reports are described in the <ulink "
+"url=\"http://www.debian.org/Bugs/server-control\">BTS control server "
+"documentation</ulink>. This section contains some guidelines for managing "
+"your own bugs, based on the collective Debian developer experience."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:630
+msgid ""
+"Filing bugs for problems that you find in other packages is one of the civic "
+"obligations of maintainership, see <xref linkend=\"submit-bug\"/> for "
+"details. However, handling the bugs in your own packages is even more "
+"important."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:635
+msgid "Here's a list of steps that you may follow to handle a bug report:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:640
+msgid ""
+"Decide whether the report corresponds to a real bug or not. Sometimes users "
+"are just calling a program in the wrong way because they haven't read the "
+"documentation. If you diagnose this, just close the bug with enough "
+"information to let the user correct their problem (give pointers to the good "
+"documentation and so on). If the same report comes up again and again you "
+"may ask yourself if the documentation is good enough or if the program "
+"shouldn't detect its misuse in order to give an informative error message. "
+"This is an issue that may need to be brought up with the upstream author."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:650
+msgid ""
+"If the bug submitter disagrees with your decision to close the bug, they may "
+"reopen it until you find an agreement on how to handle it. If you don't "
+"find any, you may want to tag the bug <literal>wontfix</literal> to let "
+"people know that the bug exists but that it won't be corrected. If this "
+"situation is unacceptable, you (or the submitter) may want to require a "
+"decision of the technical committee by reassigning the bug to <systemitem "
+"role=\"package\">tech-ctte</systemitem> (you may use the clone command of "
+"the BTS if you wish to keep it reported against your package). Before doing "
+"so, please read the <ulink "
+"url=\"http://www.debian.org/devel/tech-ctte\">recommended procedure</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:664
+msgid ""
+"If the bug is real but it's caused by another package, just reassign the bug "
+"to the right package. If you don't know which package it should be "
+"reassigned to, you should ask for help on <link "
+"linkend=\"irc-channels\">IRC</link> or on "
+"<email>debian-devel@lists.debian.org</email>. Please make sure that the "
+"maintainer(s) of the package the bug is reassigned to know why you "
+"reassigned it."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:672
+msgid ""
+"Sometimes you also have to adjust the severity of the bug so that it matches "
+"our definition of the severity. That's because people tend to inflate the "
+"severity of bugs to make sure their bugs are fixed quickly. Some bugs may "
+"even be dropped to wishlist severity when the requested change is just "
+"cosmetic."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:680
+msgid ""
+"If the bug is real but the same problem has already been reported by someone "
+"else, then the two relevant bug reports should be merged into one using the "
+"merge command of the BTS. In this way, when the bug is fixed, all of the "
+"submitters will be informed of this. (Note, however, that emails sent to "
+"one bug report's submitter won't automatically be sent to the other report's "
+"submitter.) For more details on the technicalities of the merge command and "
+"its relative, the unmerge command, see the BTS control server documentation."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:691
+msgid ""
+"The bug submitter may have forgotten to provide some information, in which "
+"case you have to ask them for the required information. You may use the "
+"<literal>moreinfo</literal> tag to mark the bug as such. Moreover if you "
+"can't reproduce the bug, you tag it <literal>unreproducible</literal>. "
+"Anyone who can reproduce the bug is then invited to provide more information "
+"on how to reproduce it. After a few months, if this information has not "
+"been sent by someone, the bug may be closed."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:702
+msgid ""
+"If the bug is related to the packaging, you just fix it. If you are not "
+"able to fix it yourself, then tag the bug as <literal>help</literal>. You "
+"can also ask for help on <email>debian-devel@lists.debian.org</email> or "
+"<email>debian-qa@lists.debian.org</email>. If it's an upstream problem, you "
+"have to forward it to the upstream author. Forwarding a bug is not enough, "
+"you have to check at each release if the bug has been fixed or not. If it "
+"has, you just close it, otherwise you have to remind the author about it. "
+"If you have the required skills you can prepare a patch that fixes the bug "
+"and send it to the author at the same time. Make sure to send the patch to "
+"the BTS and to tag the bug as <literal>patch</literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:716
+msgid ""
+"If you have fixed a bug in your local copy, or if a fix has been committed "
+"to the CVS repository, you may tag the bug as <literal>pending</literal> to "
+"let people know that the bug is corrected and that it will be closed with "
+"the next upload (add the <literal>closes:</literal> in the "
+"<filename>changelog</filename>). This is particularly useful if you are "
+"several developers working on the same package."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:726
+msgid ""
+"Once a corrected package is available in the <emphasis>unstable</emphasis> "
+"distribution, you can close the bug. This can be done automatically, read "
+"<xref linkend=\"upload-bugfix\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:735
+msgid "When bugs are closed by new uploads"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:737
+msgid ""
+"As bugs and problems are fixed in your packages, it is your responsibility "
+"as the package maintainer to close these bugs. However, you should not "
+"close a bug until the package which fixes the bug has been accepted into the "
+"Debian archive. Therefore, once you get notification that your updated "
+"package has been installed into the archive, you can and should close the "
+"bug in the BTS. Also, the bug should be closed with the correct version."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:745
+msgid ""
+"However, it's possible to avoid having to manually close bugs after the "
+"upload — just list the fixed bugs in your "
+"<filename>debian/changelog</filename> file, following a certain syntax, and "
+"the archive maintenance software will close the bugs for you. For example:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: pkgs.dbk:751
+#, no-wrap
+msgid ""
+"-cannon (3.1415) unstable; urgency=low\n"
+"\n"
+" * Frobbed with options (closes: Bug#98339)\n"
+" * Added safety to prevent operator dismemberment, closes: bug#98765,\n"
+" bug#98713, #98714.\n"
+" * Added man page. Closes: #98725."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:759
+msgid ""
+"Technically speaking, the following Perl regular expression describes how "
+"bug closing changelogs are identified:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: pkgs.dbk:763
+#, no-wrap
+msgid "/closes:\\s*(?:bug)?\\#\\s*\\d+(?:,\\s*(?:bug)?\\#\\s*\\d+)*/ig"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:766
+msgid ""
+"We prefer the <literal>closes: #<replaceable>XXX</replaceable></literal> "
+"syntax, as it is the most concise entry and the easiest to integrate with "
+"the text of the <filename>changelog</filename>. Unless specified different "
+"by the <replaceable>-v</replaceable>-switch to "
+"<command>dpkg-buildpackage</command>, only the bugs closed in the most "
+"recent changelog entry are closed (basically, exactly the bugs mentioned in "
+"the changelog-part in the <filename>.changes</filename> file are closed)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:775
+msgid ""
+"Historically, uploads identified as <link linkend=\"nmu\">Non-maintainer "
+"upload (NMU)</link> were tagged <literal>fixed</literal> instead of being "
+"closed, but that practice was ceased with the advent of version-tracking. "
+"The same applied to the tag <literal>fixed-in-experimental</literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:781
+msgid ""
+"If you happen to mistype a bug number or forget a bug in the changelog "
+"entries, don't hesitate to undo any damage the error caused. To reopen "
+"wrongly closed bugs, send a <literal>reopen "
+"<replaceable>XXX</replaceable></literal> command to the bug tracking "
+"system's control address, <email>control@bugs.debian.org</email>. To close "
+"any remaining bugs that were fixed by your upload, email the "
+"<filename>.changes</filename> file to "
+"<email>XXX-done@bugs.debian.org</email>, where "
+"<replaceable>XXX</replaceable> is the bug number, and put Version: YYY and "
+"an empty line as the first two lines of the body of the email, where "
+"<replaceable>YYY</replaceable> is the first version where the bug has been "
+"fixed."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:793
+msgid ""
+"Bear in mind that it is not obligatory to close bugs using the changelog as "
+"described above. If you simply want to close bugs that don't have anything "
+"to do with an upload you made, do it by emailing an explanation to "
+"<email>XXX-done@bugs.debian.org</email>. Do <emphasis "
+"role=\"strong\">not</emphasis> close bugs in the changelog entry of a "
+"version if the changes in that version of the package don't have any bearing "
+"on the bug."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:801
+msgid ""
+"For general information on how to write your changelog entries, see <xref "
+"linkend=\"bpp-debian-changelog\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:807
+msgid "Handling security-related bugs"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:809
+msgid ""
+"Due to their sensitive nature, security-related bugs must be handled "
+"carefully. The Debian Security Team exists to coordinate this activity, "
+"keeping track of outstanding security problems, helping maintainers with "
+"security problems or fixing them themselves, sending security advisories, "
+"and maintaining security.debian.org."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:816
+msgid ""
+"When you become aware of a security-related bug in a Debian package, whether "
+"or not you are the maintainer, collect pertinent information about the "
+"problem, and promptly contact the security team at "
+"<email>team@security.debian.org</email> as soon as possible. <emphasis "
+"role=\"strong\">DO NOT UPLOAD</emphasis> any packages for stable; the "
+"security team will do that. Useful information includes, for example:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:826
+msgid ""
+"Which versions of the package are known to be affected by the bug. Check "
+"each version that is present in a supported Debian release, as well as "
+"testing and unstable."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:833
+msgid "The nature of the fix, if any is available (patches are especially helpful)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:838
+msgid ""
+"Any fixed packages that you have prepared yourself (send only the "
+"<literal>.diff.gz</literal> and <literal>.dsc</literal> files and read <xref "
+"linkend=\"bug-security-building\"/> first)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:845
+msgid ""
+"Any assistance you can provide to help with testing (exploits, regression "
+"testing, etc.)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:851
+msgid ""
+"Any information needed for the advisory (see <xref "
+"linkend=\"bug-security-advisories\"/> )"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:857
+msgid "Confidentiality"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:859
+msgid ""
+"Unlike most other activities within Debian, information about security "
+"issues must sometimes be kept private for a time. This allows software "
+"distributors to coordinate their disclosure in order to minimize their "
+"users' exposure. Whether this is the case depends on the nature of the "
+"problem and corresponding fix, and whether it is already a matter of public "
+"knowledge."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:866
+msgid "There are several ways developers can learn of a security problem:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:871
+msgid "they notice it on a public forum (mailing list, web site, etc.)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:876
+msgid "someone files a bug report"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:881
+msgid "someone informs them via private email"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:886
+msgid ""
+"In the first two cases, the information is public and it is important to "
+"have a fix as soon as possible. In the last case, however, it might not be "
+"public information. In that case there are a few possible options for "
+"dealing with the problem:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:894
+msgid ""
+"If the security exposure is minor, there is sometimes no need to keep the "
+"problem a secret and a fix should be made and released."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:900
+msgid ""
+"If the problem is severe, it is preferable to share the information with "
+"other vendors and coordinate a release. The security team keeps in contact "
+"with the various organizations and individuals and can take care of that."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:907
+msgid ""
+"In all cases if the person who reports the problem asks that it not be "
+"disclosed, such requests should be honored, with the obvious exception of "
+"informing the security team in order that a fix may be produced for a stable "
+"release of Debian. When sending confidential information to the security "
+"team, be sure to mention this fact."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:914
+msgid ""
+"Please note that if secrecy is needed you may not upload a fix to unstable "
+"(or anywhere else, such as a public CVS repository). It is not sufficient "
+"to obfuscate the details of the change, as the code itself is public, and "
+"can (and will) be examined by the general public."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:920
+msgid ""
+"There are two reasons for releasing information even though secrecy is "
+"requested: the problem has been known for a while, or the problem or exploit "
+"has become public."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:927
+msgid "Security Advisories"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:929
+msgid ""
+"Security advisories are only issued for the current, released stable "
+"distribution, and <emphasis>not</emphasis> for testing or unstable. When "
+"released, advisories are sent to the "
+"<email>debian-security-announce@lists.debian.org</email> mailing list and "
+"posted on <ulink url=\"http://www.debian.org/security/\">the security web "
+"page</ulink>. Security advisories are written and posted by the security "
+"team. However they certainly do not mind if a maintainer can supply some of "
+"the information for them, or write part of the text. Information that "
+"should be in an advisory includes:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:942
+msgid "A description of the problem and its scope, including:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para>
+#: pkgs.dbk:947
+msgid "The type of problem (privilege escalation, denial of service, etc.)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para>
+#: pkgs.dbk:952
+msgid "What privileges may be gained, and by whom (if any)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para>
+#: pkgs.dbk:957
+msgid "How it can be exploited"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para>
+#: pkgs.dbk:962
+msgid "Whether it is remotely or locally exploitable"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para>
+#: pkgs.dbk:967
+msgid "How the problem was fixed"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:972
+msgid "This information allows users to assess the threat to their systems."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:977
+msgid "Version numbers of affected packages"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:982
+msgid "Version numbers of fixed packages"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:987
+msgid ""
+"Information on where to obtain the updated packages (usually from the Debian "
+"security archive)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:993
+msgid ""
+"References to upstream advisories, <ulink "
+"url=\"http://cve.mitre.org\">CVE</ulink> identifiers, and any other "
+"information useful in cross-referencing the vulnerability"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:1002
+msgid "Preparing packages to address security issues"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1004
+msgid ""
+"One way that you can assist the security team in their duties is to provide "
+"them with fixed packages suitable for a security advisory for the stable "
+"Debian release."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1009
+msgid ""
+"When an update is made to the stable release, care must be taken to avoid "
+"changing system behavior or introducing new bugs. In order to do this, make "
+"as few changes as possible to fix the bug. Users and administrators rely on "
+"the exact behavior of a release once it is made, so any change that is made "
+"might break someone's system. This is especially true of libraries: make "
+"sure you never change the API or ABI, no matter how small the change."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1017
+msgid ""
+"This means that moving to a new upstream version is not a good solution. "
+"Instead, the relevant changes should be back-ported to the version present "
+"in the current stable Debian release. Generally, upstream maintainers are "
+"willing to help if needed. If not, the Debian security team may be able to "
+"help."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1023
+msgid ""
+"In some cases, it is not possible to back-port a security fix, for example "
+"when large amounts of source code need to be modified or rewritten. If this "
+"happens, it may be necessary to move to a new upstream version. However, "
+"this is only done in extreme situations, and you must always coordinate that "
+"with the security team beforehand."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1030
+msgid ""
+"Related to this is another important guideline: always test your changes. "
+"If you have an exploit available, try it and see if it indeed succeeds on "
+"the unpatched package and fails on the fixed package. Test other, normal "
+"actions as well, as sometimes a security fix can break seemingly unrelated "
+"features in subtle ways."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1037
+msgid ""
+"Do <emphasis role=\"strong\">NOT</emphasis> include any changes in your "
+"package which are not directly related to fixing the vulnerability. These "
+"will only need to be reverted, and this wastes time. If there are other "
+"bugs in your package that you would like to fix, make an upload to "
+"proposed-updates in the usual way, after the security advisory is issued. "
+"The security update mechanism is not a means for introducing changes to your "
+"package which would otherwise be rejected from the stable release, so please "
+"do not attempt to do this."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1047
+msgid ""
+"Review and test your changes as much as possible. Check the differences "
+"from the previous version repeatedly (<command>interdiff</command> from the "
+"<systemitem role=\"package\">patchutils</systemitem> package and "
+"<command>debdiff</command> from <systemitem "
+"role=\"package\">devscripts</systemitem> are useful tools for this, see "
+"<xref linkend=\"debdiff\"/> )."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1055
+msgid "Be sure to verify the following items:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1060
+msgid ""
+"Target the right distribution in your "
+"<filename>debian/changelog</filename>. For stable this is "
+"<literal>stable-security</literal> and for testing this is "
+"<literal>testing-security</literal>, and for the previous stable release, "
+"this is <literal>oldstable-security</literal>. Do not target "
+"<replaceable>distribution</replaceable>-proposed-updates or "
+"<literal>stable</literal>!"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1070
+msgid "The upload should have urgency=high."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1075
+msgid ""
+"Make descriptive, meaningful changelog entries. Others will rely on them to "
+"determine whether a particular bug was fixed. Always include an external "
+"reference, preferably a CVE identifier, so that it can be cross-referenced. "
+"Include the same information in the changelog for unstable, so that it is "
+"clear that the same bug was fixed, as this is very helpful when verifying "
+"that the bug is fixed in the next stable release. If a CVE identifier has "
+"not yet been assigned, the security team will request one so that it can be "
+"included in the package and in the advisory."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1087
+msgid ""
+"Make sure the version number is proper. It must be greater than the current "
+"package, but less than package versions in later distributions. If in "
+"doubt, test it with <literal>dpkg --compare-versions</literal>. Be careful "
+"not to re-use a version number that you have already used for a previous "
+"upload. For <emphasis>testing</emphasis>, there must be a higher version in "
+"<emphasis>unstable</emphasis>. If there is none yet (for example, if "
+"<emphasis>testing</emphasis> and <emphasis>unstable</emphasis> have the same "
+"version) you must upload a new version to unstable first."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1099
+msgid ""
+"Do not make source-only uploads if your package has any binary-all packages "
+"(do not use the <literal>-S</literal> option to "
+"<command>dpkg-buildpackage</command>). The <command>buildd</command> "
+"infrastructure will not build those. This point applies to normal package "
+"uploads as well."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1108
+msgid ""
+"Unless the upstream source has been uploaded to security.debian.org before "
+"(by a previous security update), build the upload with full upstream source "
+"(<literal>dpkg-buildpackage -sa</literal>). If there has been a previous "
+"upload to security.debian.org with the same upstream version, you may upload "
+"without upstream source (<literal>dpkg-buildpackage -sd</literal>)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1117
+msgid ""
+"Be sure to use the exact same <filename>*.orig.tar.gz</filename> as used in "
+"the normal archive, otherwise it is not possible to move the security fix "
+"into the main archives later."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1124
+msgid ""
+"Build the package on a clean system which only has packages installed from "
+"the distribution you are building for. If you do not have such a system "
+"yourself, you can use a debian.org machine (see <xref "
+"linkend=\"server-machines\"/> ) or setup a chroot (see <xref "
+"linkend=\"pbuilder\"/> and <xref linkend=\"debootstrap\"/> )."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:1135
+msgid "Uploading the fixed package"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1137
+msgid ""
+"Do <emphasis role=\"strong\">NOT</emphasis> upload a package to the security "
+"upload queue (oldstable-security, stable-security, etc.) without prior "
+"authorization from the security team. If the package does not exactly meet "
+"the team's requirements, it will cause many problems and delays in dealing "
+"with the unwanted upload."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1144
+msgid ""
+"Do <emphasis role=\"strong\">NOT</emphasis> upload your fix to "
+"proposed-updates without coordinating with the security team. Packages from "
+"security.debian.org will be copied into the proposed-updates directory "
+"automatically. If a package with the same or a higher version number is "
+"already installed into the archive, the security update will be rejected by "
+"the archive system. That way, the stable distribution will end up without a "
+"security update for this package instead."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1153
+msgid ""
+"Once you have created and tested the new package and it has been approved by "
+"the security team, it needs to be uploaded so that it can be installed in "
+"the archives. For security uploads, the place to upload to is "
+"<literal>ftp://security-master.debian.org/pub/SecurityUploadQueue/</literal> "
+"."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1159
+msgid ""
+"Once an upload to the security queue has been accepted, the package will "
+"automatically be rebuilt for all architectures and stored for verification "
+"by the security team."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1164
+msgid ""
+"Uploads which are waiting for acceptance or verification are only accessible "
+"by the security team. This is necessary since there might be fixes for "
+"security problems that cannot be disclosed yet."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1169
+msgid ""
+"If a member of the security team accepts a package, it will be installed on "
+"security.debian.org as well as proposed for the proper "
+"<replaceable>distribution</replaceable>-proposed-updates on ftp-master."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:1180
+msgid "Moving, removing, renaming, adopting, and orphaning packages"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:1182
+msgid ""
+"Some archive manipulation operations are not automated in the Debian upload "
+"process. These procedures should be manually followed by maintainers. This "
+"chapter gives guidelines on what to do in these cases."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1187
+msgid "Moving packages"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para><footnote>
+#: pkgs.dbk:1189
+msgid ""
+"Sometimes a package will change its section. For instance, a package from "
+"the `non-free' section might be GPL'd in a later version, in which case the "
+"package should be moved to `main' or `contrib'.<footnote>"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para><footnote><para>
+#: pkgs.dbk:1191
+msgid ""
+"See the <ulink url=\"http://www.debian.org/doc/debian-policy/\">Debian "
+"Policy Manual</ulink> for guidelines on what section a package belongs in."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1196
+msgid ""
+"If you need to change the section for one of your packages, change the "
+"package control information to place the package in the desired section, and "
+"re-upload the package (see the <ulink "
+"url=\"http://www.debian.org/doc/debian-policy/\">Debian Policy "
+"Manual</ulink> for details). You must ensure that you include the "
+"<filename>.orig.tar.gz</filename> in your upload (even if you are not "
+"uploading a new upstream version), or it will not appear in the new section "
+"together with the rest of the package. If your new section is valid, it "
+"will be moved automatically. If it does not, then contact the ftpmasters in "
+"order to understand what happened."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1208
+msgid ""
+"If, on the other hand, you need to change the "
+"<emphasis>subsection</emphasis> of one of your packages (e.g., ``devel'', "
+"``admin''), the procedure is slightly different. Correct the subsection as "
+"found in the control file of the package, and re-upload that. Also, you'll "
+"need to get the override file updated, as described in <xref "
+"linkend=\"override-file\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1217
+msgid "Removing packages"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1219
+msgid ""
+"If for some reason you want to completely remove a package (say, if it is an "
+"old compatibility library which is no longer required), you need to file a "
+"bug against <literal>ftp.debian.org</literal> asking that the package be "
+"removed; as all bugs, this bug should normally have normal severity. Make "
+"sure you indicate which distribution the package should be removed from. "
+"Normally, you can only have packages removed from "
+"<emphasis>unstable</emphasis> and <emphasis>experimental</emphasis>. "
+"Packages are not removed from <emphasis>testing</emphasis> directly. "
+"Rather, they will be removed automatically after the package has been "
+"removed from <emphasis>unstable</emphasis> and no package in "
+"<emphasis>testing</emphasis> depends on it."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1232
+msgid ""
+"There is one exception when an explicit removal request is not necessary: If "
+"a (source or binary) package is an orphan, it will be removed "
+"semi-automatically. For a binary-package, this means if there is no longer "
+"any source package producing this binary package; if the binary package is "
+"just no longer produced on some architectures, a removal request is still "
+"necessary. For a source-package, this means that all binary packages it "
+"refers to have been taken over by another source package."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1241
+msgid ""
+"In your removal request, you have to detail the reasons justifying the "
+"request. This is to avoid unwanted removals and to keep a trace of why a "
+"package has been removed. For example, you can provide the name of the "
+"package that supersedes the one to be removed."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1247
+msgid ""
+"Usually you only ask for the removal of a package maintained by yourself. "
+"If you want to remove another package, you have to get the approval of its "
+"maintainer."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1252
+msgid ""
+"Further information relating to these and other package removal related "
+"topics may be found at <ulink "
+"url=\"http://wiki.debian.org/ftpmaster_Removals\"></ulink> and <ulink "
+"url=\"http://qa.debian.org/howto-remove.html\"></ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1257
+msgid ""
+"If in doubt concerning whether a package is disposable, email "
+"<email>debian-devel@lists.debian.org</email> asking for opinions. Also of "
+"interest is the <command>apt-cache</command> program from the <systemitem "
+"role=\"package\">apt</systemitem> package. When invoked as "
+"<literal>apt-cache showpkg <replaceable>package</replaceable></literal>, the "
+"program will show details for <replaceable>package</replaceable>, including "
+"reverse depends. Other useful programs include <literal>apt-cache "
+"rdepends</literal>, <command>apt-rdepends</command> and "
+"<command>grep-dctrl</command>. Removal of orphaned packages is discussed on "
+"<email>debian-qa@lists.debian.org</email>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1268
+msgid ""
+"Once the package has been removed, the package's bugs should be handled. "
+"They should either be reassigned to another package in the case where the "
+"actual code has evolved into another package (e.g. "
+"<literal>libfoo12</literal> was removed because <literal>libfoo13</literal> "
+"supersedes it) or closed if the software is simply no longer part of Debian."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:1275
+msgid "Removing packages from <filename>Incoming</filename>"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1277
+msgid ""
+"In the past, it was possible to remove packages from "
+"<filename>incoming</filename>. However, with the introduction of the new "
+"incoming system, this is no longer possible. Instead, you have to upload a "
+"new revision of your package with a higher version than the package you want "
+"to replace. Both versions will be installed in the archive but only the "
+"higher version will actually be available in <emphasis>unstable</emphasis> "
+"since the previous version will immediately be replaced by the higher. "
+"However, if you do proper testing of your packages, the need to replace a "
+"package should not occur too often anyway."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1292
+msgid "Replacing or renaming packages"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1294
+msgid ""
+"When you make a mistake naming your package, you should follow a two-step "
+"process to rename it. First, set your <filename>debian/control</filename> "
+"file to replace and conflict with the obsolete name of the package (see the "
+"<ulink url=\"http://www.debian.org/doc/debian-policy/\">Debian Policy "
+"Manual</ulink> for details). Once you've uploaded the package and the "
+"package has moved into the archive, file a bug against "
+"<literal>ftp.debian.org</literal> asking to remove the package with the "
+"obsolete name. Do not forget to properly reassign the package's bugs at the "
+"same time."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1304
+msgid ""
+"At other times, you may make a mistake in constructing your package and wish "
+"to replace it. The only way to do this is to increase the version number "
+"and upload a new version. The old version will be expired in the usual "
+"manner. Note that this applies to each part of your package, including the "
+"sources: if you wish to replace the upstream source tarball of your package, "
+"you will need to upload it with a different version. An easy possibility is "
+"to replace <filename>foo_1.00.orig.tar.gz</filename> with "
+"<filename>foo_1.00+0.orig.tar.gz</filename>. This restriction gives each "
+"file on the ftp site a unique name, which helps to ensure consistency across "
+"the mirror network."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1318
+msgid "Orphaning a package"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1320
+msgid ""
+"If you can no longer maintain a package, you need to inform others, and see "
+"that the package is marked as orphaned. You should set the package "
+"maintainer to <literal>Debian QA Group "
+"<packages@qa.debian.org></literal> and submit a bug report against the "
+"pseudo package <systemitem role=\"package\">wnpp</systemitem>. The bug "
+"report should be titled <literal>O: <replaceable>package</replaceable> -- "
+"<replaceable>short description</replaceable></literal> indicating that the "
+"package is now orphaned. The severity of the bug should be set to "
+"<emphasis>normal</emphasis>; if the package has a priority of standard or "
+"higher, it should be set to important. If you feel it's necessary, send a "
+"copy to <email>debian-devel@lists.debian.org</email> by putting the address "
+"in the X-Debbugs-CC: header of the message (no, don't use CC:, because that "
+"way the message's subject won't indicate the bug number)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1335
+msgid ""
+"If you just intend to give the package away, but you can keep maintainership "
+"for the moment, then you should instead submit a bug against <systemitem "
+"role=\"package\">wnpp</systemitem> and title it <literal>RFA: "
+"<replaceable>package</replaceable> -- <replaceable>short "
+"description</replaceable></literal>. <literal>RFA</literal> stands for "
+"<emphasis>Request For Adoption</emphasis>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1343
+msgid ""
+"More information is on the <ulink "
+"url=\"http://www.debian.org/devel/wnpp/\">WNPP web pages</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1349
+msgid "Adopting a package"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1351
+msgid ""
+"A list of packages in need of a new maintainer is available in the <ulink "
+"url=\"http://www.debian.org/devel/wnpp/\">Work-Needing and Prospective "
+"Packages list (WNPP)</ulink>. If you wish to take over maintenance of any "
+"of the packages listed in the WNPP, please take a look at the aforementioned "
+"page for information and procedures."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1358
+msgid ""
+"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. If you have "
+"reason to believe a maintainer has gone AWOL (absent without leave), see "
+"<xref linkend=\"mia-qa\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1364
+msgid ""
+"Generally, you may not take over the package without the assent of the "
+"current maintainer. Even if they ignore you, that is still not grounds to "
+"take over a package. Complaints about maintainers should be brought up on "
+"the developers' mailing list. If the discussion doesn't end with a positive "
+"conclusion, and the issue is of a technical nature, consider bringing it to "
+"the attention of the technical committee (see the <ulink "
+"url=\"http://www.debian.org/devel/tech-ctte\">technical committee web "
+"page</ulink> for more information)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1374
+msgid ""
+"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 "
+"<literal>Maintainer:</literal> field, although it can take a few hours after "
+"the upload is done. If you do not expect to upload a new version for a "
+"while, you can use <xref linkend=\"pkg-tracking-system\"/> to get the bug "
+"reports. However, make sure that the old maintainer has no problem with the "
+"fact that they will continue to receive the bugs during that time."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:1388
+msgid "Porting and being ported"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:1390
+msgid ""
+"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."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:1396
+msgid ""
+"Porting is the act of building Debian packages for architectures that are "
+"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 "
+"<emphasis>i386</emphasis> binary package, there must be a recompile for each "
+"architecture, which amounts to 12 more builds."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1404
+msgid "Being kind to porters"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1406
+msgid ""
+"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."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1414
+msgid ""
+"The first and most important thing 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; do your best to hunt down "
+"whatever the problem is."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1421
+msgid ""
+"By far, most of the problems encountered by porters are caused by "
+"<emphasis>packaging bugs</emphasis> in the source packages. Here is a "
+"checklist of things you should check or be aware of."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:1428
+msgid ""
+"Make sure that your <literal>Build-Depends</literal> and "
+"<literal>Build-Depends-Indep</literal> settings in "
+"<filename>debian/control</filename> are set properly. The best way to "
+"validate this is to use the <systemitem "
+"role=\"package\">debootstrap</systemitem> package to create an unstable "
+"chroot environment (see <xref linkend=\"debootstrap\"/> ). Within that "
+"chrooted environment, install the <systemitem "
+"role=\"package\">build-essential</systemitem> package and any package "
+"dependencies mentioned in <literal>Build-Depends</literal> and/or "
+"<literal>Build-Depends-Indep</literal>. Finally, try building your package "
+"within that chrooted environment. These steps can be automated by the use "
+"of the <command>pbuilder</command> program which is provided by the package "
+"of the same name (see <xref linkend=\"pbuilder\"/> )."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:1442
+msgid ""
+"If you can't set up a proper chroot, <command>dpkg-depcheck</command> may be "
+"of assistance (see <xref linkend=\"dpkg-depcheck\"/> )."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:1446
+msgid ""
+"See the <ulink url=\"http://www.debian.org/doc/debian-policy/\">Debian "
+"Policy Manual</ulink> for instructions on setting build dependencies."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:1452
+msgid ""
+"Don't set architecture to a value other than ``all'' or ``any'' unless you "
+"really mean it. In too many cases, maintainers don't follow the "
+"instructions in the <ulink "
+"url=\"http://www.debian.org/doc/debian-policy/\">Debian Policy "
+"Manual</ulink>. Setting your architecture to ``i386'' is usually incorrect."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:1460
+msgid ""
+"Make sure your source package is correct. Do <literal>dpkg-source -x "
+"<replaceable>package</replaceable>.dsc</literal> to make sure your source "
+"package unpacks properly. Then, in there, try building your package from "
+"scratch with <command>dpkg-buildpackage</command>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:1468
+msgid ""
+"Make sure you don't ship your source package with the "
+"<filename>debian/files</filename> or <filename>debian/substvars</filename> "
+"files. They should be removed by the `clean' target of "
+"<filename>debian/rules</filename>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:1476
+msgid ""
+"Make sure you don't rely on locally installed or hacked configurations or "
+"programs. For instance, you should never be calling programs in "
+"<filename>/usr/local/bin</filename> or the like. Try not to rely on "
+"programs being setup in a special way. Try building your package on another "
+"machine, even if it's the same architecture."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:1485
+msgid ""
+"Don't depend on the package you're building being installed already (a "
+"sub-case of the above issue)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:1491
+msgid ""
+"Don't rely on the compiler being a certain version, if possible. If not, "
+"then make sure your build dependencies reflect the restrictions, although "
+"you are probably asking for trouble, since different architectures sometimes "
+"standardize on different compilers."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:1499
+msgid ""
+"Make sure your debian/rules contains separate ``binary-arch'' and "
+"``binary-indep'' targets, as the Debian Policy Manual requires. Make sure "
+"that both targets work independently, that is, that you can call the target "
+"without having called the other before. To test this, try to run "
+"<literal>dpkg-buildpackage -B</literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1510
+msgid "Guidelines for porter uploads"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1512
+msgid ""
+"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 binary package 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 <xref linkend=\"nmu-guidelines\"/> instead."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1520
+msgid ""
+"For a porter upload, no changes are being made to the source. You do not "
+"need to touch any of the files in the source package. This includes "
+"<filename>debian/changelog</filename>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1525
+msgid ""
+"The way to invoke <command>dpkg-buildpackage</command> is as "
+"<literal>dpkg-buildpackage -B "
+"-m<replaceable>porter-email</replaceable></literal>. Of course, set "
+"<replaceable>porter-email</replaceable> to your email address. This will do "
+"a binary-only build of only the architecture-dependent portions of the "
+"package, using the `binary-arch' target in "
+"<filename>debian/rules</filename>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1533
+msgid ""
+"If you are working on a Debian machine for your porting efforts and you need "
+"to sign your upload locally for its acceptance in the archive, you can run "
+"<command>debsign</command> on your <filename>.changes</filename> file to "
+"have it signed conveniently, or use the remote signing mode of "
+"<command>dpkg-sig</command>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:1540
+msgid "Recompilation or binary-only NMU"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1542
+msgid ""
+"Sometimes the initial porter upload is problematic because the environment "
+"in which the package was built was not good enough (outdated or obsolete "
+"library, bad compiler, ...). Then you may just need to recompile it in an "
+"updated environment. However, you have to bump the version number in this "
+"case, so that the old bad package can be replaced in the Debian archive "
+"(<command>katie</command> refuses to install new packages if they don't have "
+"a version number greater than the currently available one)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1551
+msgid ""
+"You have to make sure that your binary-only NMU doesn't render the package "
+"uninstallable. This could happen when a source package generates "
+"arch-dependent and arch-independent packages that depend on each other via "
+"$(Source-Version)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1557
+msgid ""
+"Despite the required modification of the changelog, these are called "
+"binary-only NMUs — there is no need in this case to trigger all other "
+"architectures to consider themselves out of date or requiring recompilation."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1562
+msgid ""
+"Such recompilations require special ``magic'' version numbering, so that the "
+"archive maintenance tools recognize that, even though there is a new Debian "
+"version, there is no corresponding source update. If you get this wrong, "
+"the archive maintainers will reject your upload (due to lack of "
+"corresponding source code)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para><footnote>
+#: pkgs.dbk:1569
+msgid ""
+"The ``magic'' for a recompilation-only NMU is triggered by using a suffix "
+"appended to the package version number, following the form b<number>. "
+"For instance, if the latest version you are recompiling against was version "
+"``2.9-3'', your NMU should carry a version of ``2.9-3+b1''. If the latest "
+"version was ``3.4+b1'' (i.e, a native package with a previous recompilation "
+"NMU), your NMU should have a version number of ``3.4+b2''. <footnote>"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para><footnote><para>
+#: pkgs.dbk:1574
+msgid ""
+"In the past, such NMUs used the third-level number on the Debian part of the "
+"revision to denote their recompilation-only status; however, this syntax was "
+"ambiguous with native packages and did not allow proper ordering of "
+"recompile-only NMUs, source NMUs, and security NMUs on the same package, and "
+"has therefore been abandoned in favor of this new syntax."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1582
+msgid ""
+"Similar to initial porter uploads, the correct way of invoking "
+"<command>dpkg-buildpackage</command> is <literal>dpkg-buildpackage "
+"-B</literal> to only build the architecture-dependent parts of the package."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:1589
+msgid "When to do a source NMU if you are a porter"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1591
+msgid ""
+"Porters doing a source NMU generally follow the guidelines found in <xref "
+"linkend=\"nmu\"/> , 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. Again, the "
+"situation varies depending on the distribution they are uploading to. It "
+"also varies whether the architecture is a candidate for inclusion into the "
+"next stable release; the release managers decide and announce which "
+"architectures are candidates."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1600
+msgid ""
+"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 seven days for porters working on the "
+"unstable distribution. This period can be shortened if the problem is "
+"critical and imposes hardship on the porting effort, at the discretion of "
+"the porter group. (Remember, none of this is Policy, just mutually agreed "
+"upon guidelines.) For uploads to stable or testing, please coordinate with "
+"the appropriate release team first."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1611
+msgid ""
+"Secondly, porters doing source NMUs should make sure that the bug they "
+"submit to the BTS should be of severity `serious' 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."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1619
+msgid ""
+"Porters should try to avoid patches which simply kludge around bugs in the "
+"current version of the compile environment, kernel, or libc. Sometimes such "
+"kludges can't be helped. If you have to kludge around compiler bugs and the "
+"like, make sure you <literal>#ifdef</literal> your work properly; also, "
+"document your kludge so that people know to remove it once the external "
+"problems have been fixed."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1627
+msgid ""
+"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 locations have no official blessing or status, so buyer beware."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1637
+msgid "Porting infrastructure and automation"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1639
+msgid ""
+"There is infrastructure and several tools to help automate package porting. "
+"This section contains a brief overview of this automation and porting to "
+"these tools; see the package documentation or references for full "
+"information."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:1644
+msgid "Mailing lists and web pages"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1646
+msgid ""
+"Web pages containing the status of each port can be found at <ulink "
+"url=\"http://www.debian.org/ports/\"></ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1650
+msgid ""
+"Each port of Debian has a mailing list. The list of porting mailing lists "
+"can be found at <ulink url=\"http://lists.debian.org/ports.html\"></ulink>. "
+"These lists are used to coordinate porters, and to connect the users of a "
+"given port with the porters."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:1658
+msgid "Porter tools"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1660
+msgid ""
+"Descriptions of several porting tools can be found in <xref "
+"linkend=\"tools-porting\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1668
+msgid ""
+"The <systemitem role=\"package\">buildd</systemitem> system is used as a "
+"distributed, client-server build distribution system. It is usually used in "
+"conjunction with <emphasis>auto-builders</emphasis>, 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 "
+"auto-built) and work on it."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1677
+msgid ""
+"<systemitem role=\"package\">buildd</systemitem> is not yet available as a "
+"package; however, most porting efforts are either using it currently or "
+"planning to use it in the near future. The actual automated builder is "
+"packaged as <systemitem role=\"package\">sbuild</systemitem>, see its "
+"description in <xref linkend=\"sbuild\"/> . The complete <systemitem "
+"role=\"package\">buildd</systemitem> system also collects a number of as yet "
+"unpackaged components which are currently very useful and in use "
+"continually, such as <command>andrea</command> and "
+"<command>wanna-build</command>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1687
+msgid ""
+"Some of the data produced by <systemitem "
+"role=\"package\">buildd</systemitem> which is generally useful to porters is "
+"available on the web at <ulink url=\"http://buildd.debian.org/\"></ulink>. "
+"This data includes nightly updated information from "
+"<command>andrea</command> (source dependencies) and <systemitem "
+"role=\"package\">quinn-diff</systemitem> (packages needing recompilation)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1695
+msgid ""
+"We are quite proud of this system, since it has so many possible 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 <command>gcc</command> bounds checking). It "
+"will also enable Debian to recompile entire distributions quickly."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1702
+msgid ""
+"The buildds admins of each arch can be contacted at the mail address "
+"$arch@buildd.debian.org."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1710
+msgid "When your package is <emphasis>not</emphasis> portable"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1712
+msgid ""
+"Some packages still have issues with building and/or working on some of the "
+"architectures supported by Debian, and cannot be ported at all, or not "
+"within a reasonable amount of time. An example is a package that is "
+"SVGA-specific (only i386), or uses other hardware-specific features not "
+"supported on all architectures."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1719
+msgid ""
+"In order to prevent broken packages from being uploaded to the archive, and "
+"wasting buildd time, you need to do a few things:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1725
+msgid ""
+"First, make sure your package <emphasis>does</emphasis> fail to build on "
+"architectures that it cannot support. There are a few ways to achieve "
+"this. The preferred way is to have a small testsuite during build time that "
+"will test the functionality, and fail if it doesn't work. This is a good "
+"idea anyway, as this will prevent (some) broken uploads on all "
+"architectures, and also will allow the package to build as soon as the "
+"required functionality is available."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1733
+msgid ""
+"Additionally, if you believe the list of supported architectures is pretty "
+"constant, you should change 'any' to a list of supported architectures in "
+"debian/control. This way, the build will fail also, and indicate this to a "
+"human reader without actually trying."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1741
+msgid ""
+"In order to prevent autobuilders from needlessly trying to build your "
+"package, it must be included in <filename>packages-arch-specific</filename>, "
+"a list used by the <command>wanna-build</command> script. The current "
+"version is available as <ulink "
+"url=\"http://cvs.debian.org/srcdep/Packages-arch-specific?cvsroot=dak\"></ulink>; "
+"please see the top of the file for whom to contact for changes."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1751
+msgid ""
+"Please note that it is insufficient to only add your package to "
+"Packages-arch-specific without making it fail to build on unsupported "
+"architectures: A porter or any other person trying to build your package "
+"might accidently upload it without noticing it doesn't work. If in the past "
+"some binary packages were uploaded on unsupported architectures, request "
+"their removal by filing a bug against <systemitem "
+"role=\"package\">ftp.debian.org</systemitem>"
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:1764
+msgid "Non-Maintainer Uploads (NMUs)"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:1766
+msgid ""
+"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."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:1771
+msgid ""
+"This section handles only source NMUs, i.e. NMUs which upload a new version "
+"of the package. For binary-only NMUs by porters or QA members, please see "
+"<xref linkend=\"binary-only-nmu\"/> . If a buildd builds and uploads a "
+"package, that too is strictly speaking a binary NMU. See <xref "
+"linkend=\"buildd\"/> for some more information."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:1778
+msgid ""
+"The main reason why NMUs are done is when a developer needs to fix another "
+"developer's package in order to address serious problems or crippling bugs "
+"or when the package maintainer is unable to release a fix in a timely "
+"fashion."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:1783
+msgid ""
+"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 "
+"<emphasis>not</emphasis> be made in a non-maintainer upload."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:1792
+msgid ""
+"And please remember the Hippocratic Oath: Above all, do no harm. It is "
+"better to leave a package with an open grave bug than applying a "
+"non-functional patch, or one that hides the bug instead of resolving it."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1797
+msgid "How to do a NMU"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1799
+msgid ""
+"NMUs which fix important, serious or higher severity bugs are encouraged and "
+"accepted. You should endeavor to reach the current maintainer of the "
+"package; they might be just about to upload a fix for the problem, or have a "
+"better solution."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1805
+msgid ""
+"NMUs should be made to assist a package's maintainer in resolving bugs. "
+"Maintainers should be thankful for that help, and NMUers should respect the "
+"decisions of maintainers, and try to personally help the maintainer by their "
+"work."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1811
+msgid ""
+"A NMU should follow all conventions, written down in this section. For an "
+"upload to testing or unstable, this order of steps is recommended:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1817
+msgid ""
+"Make sure that the package's bugs that the NMU is meant to address are all "
+"filed in the Debian Bug Tracking System (BTS). If they are not, submit them "
+"immediately."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1824
+msgid ""
+"Wait a few days for the response from the maintainer. If you don't get any "
+"response, you may want to help them by sending the patch that fixes the "
+"bug. Don't forget to tag the bug with the patch keyword."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1831
+msgid ""
+"Wait a few more days. If you still haven't got an answer from the "
+"maintainer, send them a mail announcing your intent to NMU the package. "
+"Prepare an NMU as described in this section, and test it carefully on your "
+"machine (cf. <xref linkend=\"sanitycheck\"/> ). 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."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1841
+msgid ""
+"Upload your package to incoming in <filename>DELAYED/7-day</filename> (cf. "
+"<xref linkend=\"delayed-incoming\"/> ), send the final patch to the "
+"maintainer via the BTS, and explain to them that they have 7 days to react "
+"if they want to cancel the NMU."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1849
+msgid ""
+"Follow what happens, you're responsible for any bug that you introduced with "
+"your NMU. You should probably use <xref linkend=\"pkg-tracking-system\"/> "
+"(PTS) to stay informed of the state of the package after your NMU."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1856
+msgid ""
+"At times, the release manager or an organized group of developers can "
+"announce a certain period of time in which the NMU rules are relaxed. This "
+"usually involves shortening the period during which one is to wait before "
+"uploading the fixes, and shortening the DELAYED period. It is important to "
+"notice that even in these so-called bug squashing party times, the NMU'er "
+"has to file bugs and contact the developer first, and act later. Please see "
+"<xref linkend=\"qa-bsp\"/> for details."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1865
+msgid ""
+"For the testing distribution, the rules may be changed by the release "
+"managers. Please take additional care, and acknowledge that the usual way "
+"for a package to enter testing is through unstable."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1870
+msgid ""
+"For the stable distribution, please take extra care. Of course, the release "
+"managers may also change the rules here. Please verify before you upload "
+"that all your changes are OK for inclusion into the next stable release by "
+"the release manager."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1876
+msgid ""
+"When a security bug is detected, the security team may do an NMU, using "
+"their own rules. Please refer to <xref linkend=\"bug-security\"/> for more "
+"information."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1881
+msgid ""
+"For the differences for Porters NMUs, please see <xref "
+"linkend=\"source-nmu-when-porter\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1885
+msgid ""
+"Of course, it is always possible to agree on special rules with a maintainer "
+"(like the maintainer asking please upload this fix directly for me, and no "
+"diff required)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1892
+msgid "NMU version numbering"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1894
+msgid ""
+"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."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1898
+msgid ""
+"If you are doing a non-maintainer upload (NMU), you should add a new minor "
+"version number to the <replaceable>debian-revision</replaceable> 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 "
+"<filename>foo_1.1-3.dsc</filename>. 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 "
+"<filename>foo_1.1-3.1.dsc</filename>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1909
+msgid ""
+"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."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1915
+msgid ""
+"If there is no <replaceable>debian-revision</replaceable> component in the "
+"version number then one should be created, starting at `0.1' (but in case of "
+"a debian native package still upload it as native package). 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 <replaceable>debian-revision</replaceable> value "
+"`0.1'. The usual maintainer of a package should start their "
+"<replaceable>debian-revision</replaceable> numbering at `1'."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1925
+msgid ""
+"If you upload a package to testing or stable, sometimes, you need to fork "
+"the version number tree. For this, version numbers like 1.1-3sarge0.1 could "
+"be used."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1932
+msgid "Source NMUs must have a new changelog entry"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1934
+msgid ""
+"Anyone who is 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 email address of the "
+"person who uploaded it in the log entry and the NMU version number in it."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1940
+msgid "By convention, source NMU changelog entries start with the line"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: pkgs.dbk:1943
+#, no-wrap
+msgid "* Non-maintainer upload"
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1948
+msgid "Source NMUs and the Bug Tracking System"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1950
+msgid ""
+"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 (<literal>diff -u</literal>) detailing their changes to "
+"the Bug Tracking System."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1956
+msgid ""
+"What if you are simply recompiling the package? If you just need to "
+"recompile it for a single architecture, then you may do a binary-only NMU as "
+"described in <xref linkend=\"binary-only-nmu\"/> which doesn't require any "
+"patch to be sent. If you want the package to be recompiled for all "
+"architectures, then you do a source NMU as usual and you will have to send a "
+"patch."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1963
+msgid ""
+"Bugs fixed by source NMUs used to be tagged fixed instead of closed, but "
+"since version tracking is in place, such bugs are now also closed with the "
+"NMU version."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1968
+msgid ""
+"Also, after doing an NMU, you have to send the information to the existing "
+"bugs that are fixed by your NMU, including the unified diff. Historically, "
+"it was custom to open a new bug and include a patch showing all the changes "
+"you have made. 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."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1979
+msgid ""
+"In addition, the normal maintainer should <emphasis>always</emphasis> retain "
+"the entry in the changelog file documenting the non-maintainer upload -- and "
+"of course, also keep the changes. If you revert some of the changes, please "
+"reopen the relevant bug reports."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1987
+msgid "Building source NMUs"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1989
+msgid ""
+"Source NMU packages are built normally. Pick a distribution using the same "
+"rules as found in <xref linkend=\"distribution\"/> , follow the other "
+"instructions in <xref linkend=\"upload\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1994
+msgid ""
+"Make sure you do <emphasis>not</emphasis> change the value of the maintainer "
+"in the <filename>debian/control</filename> file. Your name as given in the "
+"NMU entry of the <filename>debian/changelog</filename> file will be used for "
+"signing the changes file."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:2002
+msgid "Acknowledging an NMU"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2004
+msgid ""
+"If one of your packages has been NMU'ed, you have to incorporate the changes "
+"in your copy of the sources. This is easy, you just have to apply the patch "
+"that has been sent to you. Once this is done, you have to close the bugs "
+"that have been tagged fixed by the NMU. The easiest way is to use the "
+"<literal>-v</literal> option of <command>dpkg-buildpackage</command>, as "
+"this allows you to include just all changes since your last maintainer "
+"upload. Alternatively, you can close them manually by sending the required "
+"mails to the BTS or by adding the required <literal>closes: #nnnn</literal> "
+"in the changelog entry of your next upload."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2015
+msgid ""
+"In any case, you should not be upset by the NMU. An NMU is not a personal "
+"attack against the maintainer. It is a proof that someone cares enough "
+"about the package that they were willing to help you in your work, so you "
+"should be thankful. You may also want to ask them if they would be "
+"interested in helping you on a more frequent basis as co-maintainer or "
+"backup maintainer (see <xref linkend=\"collaborative-maint\"/> )."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:2025
+msgid "NMU vs QA uploads"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2027
+msgid ""
+"Unless you know the maintainer is still active, it is wise to check the "
+"package to see if it has been orphaned. The current list of orphaned "
+"packages which haven't had their maintainer set correctly is available at "
+"<ulink url=\"http://qa.debian.org/orphaned.html\"></ulink>. If you perform "
+"an NMU on an improperly orphaned package, please set the maintainer to "
+"``Debian QA Group <packages@qa.debian.org>''."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:2037
+msgid "Who can do an NMU"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2039
+msgid ""
+"Only official, registered Debian Developers can do binary or source NMUs. A "
+"Debian Developer 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."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:2049
+msgid "Terminology"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2051
+msgid ""
+"There are two new terms used throughout this section: ``binary-only NMU'' "
+"and ``source NMU''. These terms are used with specific technical meaning "
+"throughout this document. Both binary-only 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 "
+"<emphasis>non-maintainer</emphasis> upload."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2059
+msgid ""
+"A source NMU is an 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 <filename>debian/changelog</filename>). This can be either a "
+"change to the upstream source, or a change to the Debian bits of the "
+"source. Note, however, that source NMUs may also include "
+"architecture-dependent packages, as well as an updated Debian diff."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2068
+msgid ""
+"A binary-only NMU is a recompilation and upload of a binary package for a "
+"given architecture. As such, it is usually part of a porting effort. A "
+"binary-only NMU is a non-maintainer uploaded binary version of a package, "
+"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-only NMU. As you can see, we don't distinguish in terminology "
+"between porter NMUs and non-porter NMUs."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2078
+msgid ""
+"Both classes of NMUs, source and binary-only, can be lumped under 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: always "
+"use ``binary NMU'' or ``binNMU'' for binary-only NMUs."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:2088
+msgid "Collaborative maintenance"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:2090
+msgid ""
+"Collaborative maintenance is a term describing the sharing of Debian package "
+"maintenance duties by several people. This collaboration is almost always a "
+"good idea, since it generally results in higher quality and faster bug fix "
+"turnaround times. It is strongly recommended that packages with a priority "
+"of <literal>Standard</literal> or which are part of the base set have "
+"co-maintainers."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:2098
+msgid ""
+"Generally there is a primary maintainer and one or more co-maintainers. The "
+"primary maintainer is the person whose name is listed in the "
+"<literal>Maintainer</literal> field of the "
+"<filename>debian/control</filename> file. Co-maintainers are all the other "
+"maintainers."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:2104
+msgid ""
+"In its most basic form, the process of adding a new co-maintainer is quite "
+"easy:"
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2110
+msgid ""
+"Setup the co-maintainer with access to the sources you build the package "
+"from. Generally this implies you are using a network-capable version "
+"control system, such as <command>CVS</command> or "
+"<command>Subversion</command>. Alioth (see <xref linkend=\"alioth\"/> ) "
+"provides such tools, amongst others."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2118
+msgid ""
+"Add the co-maintainer's correct maintainer name and address to the "
+"<literal>Uploaders</literal> field in the global part of the "
+"<filename>debian/control</filename> file."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><screen>
+#: pkgs.dbk:2123
+#, no-wrap
+msgid ": John Buzz <jbuzz@debian.org>, Adam Rex <arex@debian.org>"
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2128
+msgid ""
+"Using the PTS (<xref linkend=\"pkg-tracking-system\"/> ), the co-maintainers "
+"should subscribe themselves to the appropriate source package."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:2134
+msgid ""
+"Another form of collaborative maintenance is team maintenance, which is "
+"recommended if you maintain several packages with the same group of "
+"developers. In that case, the Maintainer and Uploaders field of each "
+"package must be managed with care. It is recommended to choose between one "
+"of the two following schemes:"
+msgstr ""
+
+# type: Content of: <chapter><section><orderedlist><listitem><para>
+#: pkgs.dbk:2143
+msgid ""
+"Put the team member mainly responsible for the package in the Maintainer "
+"field. In the Uploaders, put the mailing list address, and the team members "
+"who care for the package."
+msgstr ""
+
+# type: Content of: <chapter><section><orderedlist><listitem><para>
+#: pkgs.dbk:2150
+msgid ""
+"Put the mailing list address in the Maintainer field. In the Uploaders "
+"field, put the team members who care for the package. In this case, you "
+"must make sure the mailing list accept bug reports without any human "
+"interaction (like moderation for non-subscribers)."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:2158
+msgid ""
+"In any case, it is a bad idea to automatically put all team members in the "
+"Uploaders field. It clutters the Developer's Package Overview listing (see "
+"<xref linkend=\"ddpo\"/> ) with packages one doesn't really care for, and "
+"creates a false sense of good maintenance."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:2166
+msgid "The testing distribution"
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:2168
+msgid "Basics"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2170
+msgid ""
+"Packages are usually installed into the `testing' distribution after they "
+"have undergone some degree of testing in unstable."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2174
+msgid ""
+"They must be in sync on all architectures and mustn't have dependencies that "
+"make them uninstallable; they also have to have generally no known "
+"release-critical bugs at the time they're installed into testing. This way, "
+"`testing' should always be close to being a release candidate. Please see "
+"below for details."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:2183
+msgid "Updates from unstable"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2185
+msgid ""
+"The scripts that update the <emphasis>testing</emphasis> distribution are "
+"run each day after the installation of the updated packages; these scripts "
+"are called <emphasis>britney</emphasis>. They generate the "
+"<filename>Packages</filename> files for the <emphasis>testing</emphasis> "
+"distribution, but they do so in an intelligent manner; they try to avoid any "
+"inconsistency and to use only non-buggy packages."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2193
+msgid ""
+"The inclusion of a package from <emphasis>unstable</emphasis> is conditional "
+"on the following:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2199
+msgid ""
+"The package must have been available in <emphasis>unstable</emphasis> for 2, "
+"5 or 10 days, depending on the urgency (high, medium or low). Please note "
+"that the urgency is sticky, meaning that the highest urgency uploaded since "
+"the previous testing transition is taken into account. Those delays may be "
+"doubled during a freeze, or testing transitions may be switched off "
+"altogether;"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2208
+msgid ""
+"It must have the same number or fewer release-critical bugs than the version "
+"currently available in <emphasis>testing</emphasis>;"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2214
+msgid ""
+"It must be available on all architectures on which it has previously been "
+"built in unstable. <xref linkend=\"madison\"/> may be of interest to check "
+"that information;"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2221
+msgid ""
+"It must not break any dependency of a package which is already available in "
+"<emphasis>testing</emphasis>;"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2227
+msgid ""
+"The packages on which it depends must either be available in "
+"<emphasis>testing</emphasis> or they must be accepted into "
+"<emphasis>testing</emphasis> at the same time (and they will be if they "
+"fulfill all the necessary criteria);"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2235
+msgid ""
+"To find out whether a package is progressing into testing or not, see the "
+"testing script output on the <ulink "
+"url=\"http://www.debian.org/devel/testing\">web page of the testing "
+"distribution</ulink>, or use the program <command>grep-excuses</command> "
+"which is in the <systemitem role=\"package\">devscripts</systemitem> "
+"package. This utility can easily be used in a <citerefentry> "
+"<refentrytitle>crontab</refentrytitle> <manvolnum>5</manvolnum> "
+"</citerefentry> to keep yourself informed of the progression of your "
+"packages into <emphasis>testing</emphasis>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2246
+msgid ""
+"The <filename>update_excuses</filename> file does not always give the "
+"precise reason why the package is refused; you may have to find it on your "
+"own by looking for what would break with the inclusion of the package. The "
+"<ulink url=\"http://www.debian.org/devel/testing\">testing web page</ulink> "
+"gives some more information about the usual problems which may be causing "
+"such troubles."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2253
+msgid ""
+"Sometimes, some packages never enter <emphasis>testing</emphasis> because "
+"the set of inter-relationship is too complicated and cannot be sorted out by "
+"the scripts. See below for details."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2258
+msgid ""
+"Some further dependency analysis is shown on <ulink "
+"url=\"http://bjorn.haxx.se/debian/\"></ulink> — but be warned, this page "
+"also shows build dependencies which are not considered by britney."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:2263
+msgid "out-of-date"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2265
+msgid ""
+"For the testing migration script, outdated means: There are different "
+"versions in unstable for the release architectures (except for the "
+"architectures in fuckedarches; fuckedarches is a list of architectures that "
+"don't keep up (in update_out.py), but currently, it's empty). outdated has "
+"nothing whatsoever to do with the architectures this package has in testing."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2272
+msgid "Consider this example:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry>
+#: pkgs.dbk:2279 pkgs.dbk:2310
+msgid "alpha"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry>
+#: pkgs.dbk:2280 pkgs.dbk:2311
+msgid "arm"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry>
+#: pkgs.dbk:2285 pkgs.dbk:2317 pkgs.dbk:2377
+msgid "testing"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
+#: pkgs.dbk:2286 pkgs.dbk:2291 pkgs.dbk:2318 pkgs.dbk:2319 pkgs.dbk:2326
+msgid "1"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
+#: pkgs.dbk:2287 pkgs.dbk:2320 pkgs.dbk:2325
+msgid "-"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry>
+#: pkgs.dbk:2290 pkgs.dbk:2323 pkgs.dbk:2378
+msgid "unstable"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
+#: pkgs.dbk:2292 pkgs.dbk:2324
+msgid "2"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2298
+msgid ""
+"The package is out of date on alpha in unstable, and will not go to "
+"testing. And removing foo from testing would not help at all, the package "
+"is still out of date on alpha, and will not propagate to testing."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2303
+msgid "However, if ftp-master removes a package in unstable (here on arm):"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry>
+#: pkgs.dbk:2312
+msgid "hurd-i386"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2332
+msgid ""
+"In this case, the package is up to date on all release architectures in "
+"unstable (and the extra hurd-i386 doesn't matter, as it's not a release "
+"architecture)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2337
+msgid ""
+"Sometimes, the question is raised if it is possible to allow packages in "
+"that are not yet built on all architectures: No. Just plainly no. (Except "
+"if you maintain glibc or so.)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:2344
+msgid "Removals from testing"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2346
+msgid ""
+"Sometimes, a package is removed to allow another package in: This happens "
+"only to allow <emphasis>another</emphasis> package to go in if it's ready in "
+"every other sense. Suppose e.g. that <emphasis>a</emphasis> cannot be "
+"installed with the new version of <emphasis>b</emphasis>; then "
+"<emphasis>a</emphasis> may be removed to allow <emphasis>b</emphasis> in."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2353
+msgid ""
+"Of course, there is another reason to remove a package from testing: It's "
+"just too buggy (and having a single RC-bug is enough to be in this state)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2357
+msgid ""
+"Furthermore, if a package has been removed from unstable, and no package in "
+"testing depends on it any more, then it will automatically be removed."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:2363
+msgid "circular dependencies"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2365
+msgid ""
+"A situation which is not handled very well by britney is if package "
+"<emphasis>a</emphasis> depends on the new version of package "
+"<emphasis>b</emphasis>, and vice versa."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2370
+msgid "An example of this is:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
+#: pkgs.dbk:2383
+msgid "a"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
+#: pkgs.dbk:2384
+msgid "1; depends: b=1"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
+#: pkgs.dbk:2385
+msgid "2; depends: b=2"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
+#: pkgs.dbk:2388
+msgid "b"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
+#: pkgs.dbk:2389
+msgid "1; depends: a=1"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
+#: pkgs.dbk:2390
+msgid "2; depends: a=2"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2396
+msgid ""
+"Neither package <emphasis>a</emphasis> nor package <emphasis>b</emphasis> is "
+"considered for update."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2400
+msgid ""
+"Currently, this requires some manual hinting from the release team. Please "
+"contact them by sending mail to "
+"<email>debian-release@lists.debian.org</email> if this happens to one of "
+"your packages."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:2407
+msgid "influence of package in testing"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2409
+msgid ""
+"Generally, there is nothing that the status of a package in testing means "
+"for transition of the next version from unstable to testing, with two "
+"exceptions: If the RC-bugginess of the package goes down, it may go in even "
+"if it is still RC-buggy. The second exception is if the version of the "
+"package in testing is out of sync on the different arches: Then any arch "
+"might just upgrade to the version of the source package; however, this can "
+"happen only if the package was previously forced through, the arch is in "
+"fuckedarches, or there was no binary package of that arch present in "
+"unstable at all during the testing migration."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2419
+msgid ""
+"In summary this means: The only influence that a package being in testing "
+"has on a new version of the same package is that the new version might go in "
+"easier."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:2426
+msgid "details"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2428
+msgid "If you are interested in details, this is how britney works:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2431
+msgid ""
+"The packages are looked at to determine whether they are valid candidates. "
+"This gives the update excuses. The most common reasons why a package is not "
+"considered are too young, RC-bugginess, and out of date on some arches. For "
+"this part of britney, the release managers have hammers of various sizes to "
+"force britney to consider a package. (Also, the base freeze is coded in "
+"that part of britney.) (There is a similar thing for binary-only updates, "
+"but this is not described here. If you're interested in that, please peruse "
+"the code.)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2440
+msgid ""
+"Now, the more complex part happens: Britney tries to update testing with the "
+"valid candidates; first, each package alone, and then larger and even larger "
+"sets of packages together. Each try is accepted if testing is not more "
+"uninstallable after the update than before. (Before and after this part, "
+"some hints are processed; but as only release masters can hint, this is "
+"probably not so important for you.)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2448
+msgid ""
+"If you want to see more details, you can look it up on "
+"merkel:/org/ftp.debian.org/testing/update_out/ (or there in "
+"~aba/testing/update_out to see a setup with a smaller packages file). Via "
+"web, it's at <ulink "
+"url=\"http://ftp-master.debian.org/testing/update_out_code/\"></ulink>"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2455
+msgid ""
+"The hints are available via <ulink "
+"url=\"http://ftp-master.debian.org/testing/hints/\"></ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:2463
+msgid "Direct updates to testing"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2465
+msgid ""
+"The testing distribution is fed with packages from unstable according to the "
+"rules explained above. However, in some cases, it is necessary to upload "
+"packages built only for testing. For that, you may want to upload to "
+"<emphasis>testing-proposed-updates</emphasis>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2471
+msgid ""
+"Keep in mind that packages uploaded there are not automatically processed, "
+"they have to go through the hands of the release manager. So you'd better "
+"have a good reason to upload there. In order to know what a good reason is "
+"in the release managers' eyes, you should read the instructions that they "
+"regularly give on <email>debian-devel-announce@lists.debian.org</email>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2478
+msgid ""
+"You should not upload to <emphasis>testing-proposed-updates</emphasis> when "
+"you can update your packages through <emphasis>unstable</emphasis>. If you "
+"can't (for example because you have a newer development version in "
+"unstable), you may use this facility, but it is recommended that you ask for "
+"authorization from the release manager first. Even if a package is frozen, "
+"updates through unstable are possible, if the upload via unstable does not "
+"pull in any new dependencies."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2487
+msgid ""
+"Version numbers are usually selected by adding the codename of the testing "
+"distribution and a running number, like 1.2sarge1 for the first upload "
+"through testing-proposed-updates of package version 1.2."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2492
+msgid "Please make sure you didn't miss any of these items in your upload:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2497
+msgid ""
+"Make sure that your package really needs to go through "
+"<emphasis>testing-proposed-updates</emphasis>, and can't go through "
+"unstable;"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2503
+msgid "Make sure that you included only the minimal amount of changes;"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2508
+msgid "Make sure that you included an appropriate explanation in the changelog;"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2513
+msgid ""
+"Make sure that you've written <emphasis>testing</emphasis> or "
+"<emphasis>testing-proposed-updates</emphasis> into your target distribution;"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2519
+msgid ""
+"Make sure that you've built and tested your package in "
+"<emphasis>testing</emphasis>, not in <emphasis>unstable</emphasis>;"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2525
+msgid ""
+"Make sure that your version number is higher than the version in "
+"<emphasis>testing</emphasis> and "
+"<emphasis>testing-proposed-updates</emphasis>, and lower than in "
+"<emphasis>unstable</emphasis>;"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2532
+msgid ""
+"After uploading and successful build on all platforms, contact the release "
+"team at <email>debian-release@lists.debian.org</email> and ask them to "
+"approve your upload."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:2541
+msgid "Frequently asked questions"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:2543
+msgid "What are release-critical bugs, and how do they get counted?"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2545
+msgid ""
+"All bugs of some higher severities are by default considered "
+"release-critical; currently, these are critical, grave, and serious bugs."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2549
+msgid ""
+"Such bugs are presumed to have an impact on the chances that the package "
+"will be released with the stable release of Debian: in general, if a package "
+"has open release-critical bugs filed on it, it won't get into testing, and "
+"consequently won't be released in stable."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2555
+msgid ""
+"The unstable bug count are all release-critical bugs without either any "
+"release-tag (such as potato, woody) or with release-tag sid; also, only if "
+"they are neither fixed nor set to sarge-ignore. The testing bug count for a "
+"package is considered to be roughly the bug count of unstable count at the "
+"last point when the testing version equalled the unstable version."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2562
+msgid ""
+"This will change post-sarge, as soon as we have versions in the bug tracking "
+"system."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:2568
+msgid "How could installing a package into testing possibly break other packages?"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2570
+msgid ""
+"The structure of the distribution archives is such that they can only "
+"contain one version of a package; a package is defined by its name. So when "
+"the source package acmefoo is installed into testing, along with its binary "
+"packages acme-foo-bin, acme-bar-bin, libacme-foo1 and libacme-foo-dev, the "
+"old version is removed."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2577
+msgid ""
+"However, the old version may have provided a binary package with an old "
+"soname of a library, such as libacme-foo0. Removing the old acmefoo will "
+"remove libacme-foo0, which will break any packages which depend on it."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2582
+msgid ""
+"Evidently, this mainly affects packages which provide changing sets of "
+"binary packages in different versions (in turn, mainly libraries). However, "
+"it will also affect packages upon which versioned dependencies have been "
+"declared of the ==, <=, or << varieties."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2588
+msgid ""
+"When the set of binary packages provided by a source package change in this "
+"way, all the packages that depended on the old binaries will have to be "
+"updated to depend on the new binaries instead. Because installing such a "
+"source package into testing breaks all the packages that depended on it in "
+"testing, some care has to be taken now: all the depending packages must be "
+"updated and ready to be installed themselves so that they won't be broken, "
+"and, once everything is ready, manual intervention by the release manager or "
+"an assistant is normally required."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2598
+msgid ""
+"If you are having problems with complicated groups of packages like this, "
+"contact debian-devel or debian-release for help."
+msgstr ""