[developers-reference.git] / po4a / po / pkgs.pot

# SOME DESCRIPTIVE TITLE
# Copyright (C) YEAR Free Software Foundation, Inc.
# This file is distributed under the same license as the PACKAGE package.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"POT-Creation-Date: 2008-08-08 11:33-0300\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:7
msgid "Managing Packages"
msgstr ""

# type: Content of: <chapter><para>
#: pkgs.dbk:9
msgid ""
"This chapter contains information related to creating, uploading, "
"maintaining, and porting packages."
msgstr ""

# type: Content of: <chapter><section><title>
#: pkgs.dbk:13
msgid "New packages"
msgstr ""

# type: Content of: <chapter><section><para>
#: pkgs.dbk:15
msgid ""
"If you want to create a new package for the Debian distribution, you should "
"first check the <ulink url=\"&url-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=\"&url-wnpp;\">WNPP web pages</ulink> for "
"more information."
msgstr ""

# type: Content of: <chapter><section><para>
#: pkgs.dbk:23
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:31
msgid ""
"You should set the subject of the bug to <literal>ITP: "
"<replaceable>foo</replaceable> -- <replaceable>short "
"description</replaceable></literal>, substituting the name of the new "
"package for <replaceable>foo</replaceable>.  The severity of the bug report "
"must be set to <literal>wishlist</literal>.  Please send a copy to "
"&email-debian-devel; by using the X-Debbugs-CC header (don't use CC:, "
"because that way the message's subject won't indicate the bug number). If "
"you are packaging so many new packages (>10)  that notifying the mailing "
"list in seperate messages is too disruptive, do send a summary after filing "
"the bugs to the debian-devel list instead.  This will inform the other "
"developers about upcoming packages and will allow a review of your "
"description and package name."
msgstr ""

# type: Content of: <chapter><section><para>
#: pkgs.dbk:45
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:51
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:59
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:65
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:71
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:77
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 &email-debian-devel-changes;."
msgstr ""

# type: Content of: <chapter><section><itemizedlist><listitem><para>
#: pkgs.dbk:84
msgid ""
"It is helpful to the people who live off <literal>unstable</literal> (and "
"form our first line of testers).  We should encourage these people."
msgstr ""

# type: Content of: <chapter><section><itemizedlist><listitem><para>
#: pkgs.dbk:90
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:96
msgid ""
"Please see <ulink url=\"http://&ftp-master-host;/REJECT-FAQ.html\"></ulink> "
"for common rejection reasons for a new package."
msgstr ""

# type: Content of: <chapter><section><title>
#: pkgs.dbk:102
msgid "Recording changes in the package"
msgstr ""

# type: Content of: <chapter><section><para>
#: pkgs.dbk:104
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:115
msgid ""
"The <filename>debian/changelog</filename> file conforms to a certain "
"structure, with a number of different fields.  One field of note, the "
"<literal>distribution</literal>, 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:123
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:127
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:130
#, no-wrap
msgid ""
"\n"
"  * new upstream version\n"
msgstr ""

# type: Content of: <chapter><section><para>
#: pkgs.dbk:134
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:139
msgid "See also <xref linkend=\"bpp-debian-changelog\"/> ."
msgstr ""

# type: Content of: <chapter><section><title>
#: pkgs.dbk:144
msgid "Testing the package"
msgstr ""

# type: Content of: <chapter><section><para>
#: pkgs.dbk:146
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:153
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:160
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:169
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:173
msgid ""
"For more information on <command>lintian</command>, see <xref "
"linkend=\"lintian\"/> ."
msgstr ""

# type: Content of: <chapter><section><itemizedlist><listitem><para>
#: pkgs.dbk:179
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:185
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:191
msgid "Remove the package, then reinstall it."
msgstr ""

# type: Content of: <chapter><section><itemizedlist><listitem><para>
#: pkgs.dbk:196
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:206
msgid "Layout of the source package"
msgstr ""

# type: Content of: <chapter><section><para>
#: pkgs.dbk:208
msgid "There are two types of Debian source packages:"
msgstr ""

# type: Content of: <chapter><section><itemizedlist><listitem><para>
#: pkgs.dbk:213
msgid ""
"the so-called <literal>native</literal> 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:219
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:225
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:233
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:239
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:246
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:254
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:261
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:268
msgid "Picking a distribution"
msgstr ""

# type: Content of: <chapter><section><para>
#: pkgs.dbk:270
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:276
msgid ""
"There are several possible values for this field: <literal>stable</literal>, "
"<literal>unstable</literal>, <literal>testing-proposed-updates</literal> and "
"<literal>experimental</literal>.  Normally, packages are uploaded into "
"<literal>unstable</literal>."
msgstr ""

# type: Content of: <chapter><section><para>
#: pkgs.dbk:282
msgid ""
"Actually, there are two other possible distributions: "
"<literal>stable-security </literal> and <literal>testing-security</literal>, "
"but read <xref linkend=\"bug-security\"/> for more information on those."
msgstr ""

# type: Content of: <chapter><section><para>
#: pkgs.dbk:287
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:291
msgid ""
"Special case: uploads to the <literal>stable</literal> and "
"<literal>oldstable</literal> distributions"
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:294
msgid ""
"Uploading to <literal>stable</literal> means that the package will "
"transfered to the <literal>proposed-updates-new</literal> 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 <literal>stable</literal> with "
"the next point release."
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:302
msgid ""
"To ensure that your upload will be accepted, you should discuss the changes "
"with the stable release team before you upload. For that, send a mail to the "
"&email-debian-release; mailing list, including the patch you want to apply "
"to the package version currently in <literal>stable</literal>. Always be "
"verbose and detailed in your changelog entries for uploads to the "
"<literal>stable</literal> distribution."
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:310
msgid ""
"Extra care should be taken when uploading to <literal>stable</literal>.  "
"Basically, a package should only be uploaded to <literal>stable</literal> if "
"one of the following happens:"
msgstr ""

# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
#: pkgs.dbk:317
msgid "a truly critical functionality problem"
msgstr ""

# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
#: pkgs.dbk:322
msgid "the package becomes uninstallable"
msgstr ""

# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
#: pkgs.dbk:327
msgid "a released architecture lacks the package"
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:332
msgid ""
"In the past, uploads to <literal>stable</literal> 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. If the security teams deems the problem to be "
"too benign to be fixed through a <literal>DSA</literal>, the stable release "
"managers are usually willing to include your fix nonetheless in a regular "
"upload to <literal>stable</literal>."
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:343
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:347
msgid ""
"Packages uploaded to <literal>stable</literal> need to be compiled on "
"systems running <literal>stable</literal>, so that their dependencies are "
"limited to the libraries (and other packages) available in "
"<literal>stable</literal>; for example, a package uploaded to "
"<literal>stable</literal> that depends on a library package that only exists "
"in <literal>unstable</literal> will be rejected.  Making changes to "
"dependencies of other packages (by messing with <literal>Provides</literal> "
"or <literal>shlibs</literal> files), possibly making those other packages "
"uninstallable, is strongly discouraged."
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:357
msgid ""
"Uploads to the <literal>oldstable</literal> distributions are possible as "
"long as it hasn't been archived. The same rules as for <literal>stable "
"</literal> apply."
msgstr ""

# type: Content of: <chapter><section><section><title>
#: pkgs.dbk:364
msgid "Special case: uploads to <literal>testing/testing-proposed-updates</literal>"
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:366
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:374
msgid "Uploading a package"
msgstr ""

# type: Content of: <chapter><section><section><title>
#: pkgs.dbk:376
msgid "Uploading to <literal>ftp-master</literal>"
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:378
msgid ""
"To upload a package, you should upload the files (including the signed "
"changes and dsc-file) with anonymous ftp to "
"<literal>&ftp-master-host;</literal> in the directory <ulink "
"url=\"ftp://&ftp-master-host;&upload-queue;\">&upload-queue;</ulink>.  To "
"get the files processed there, they need to be signed with a key in the "
"Debian Developers keyring or the Debian Maintainers keyring (see <ulink "
"url=\"&url-wiki-dm;\"></ulink>)."
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:387
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:392
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:397
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:403
msgid "Delayed uploads"
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:405
msgid ""
"Delayed uploads are done for the moment via the delayed queue at "
"<literal>gluck </literal>. The upload-directory is "
"<literal>gluck:~tfheen/DELAYED/[012345678]-day</literal>. 0-day is uploaded "
"multiple times per day to <literal>&ftp-master-host;</literal>."
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:411
msgid "With a fairly recent dput, this section"
msgstr ""

# type: Content of: <chapter><section><section><screen>
#: pkgs.dbk:413
#, no-wrap
msgid ""
"\n"
"[tfheen_delayed]\n"
"method = scp\n"
"fqdn = gluck.debian.org\n"
"incoming = ~tfheen\n"
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:420
msgid ""
"in <filename>~/.dput.cf</filename> should work fine for uploading to the "
"<literal>DELAYED</literal> queue."
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:424
msgid ""
"<emphasis>Note:</emphasis> Since this upload queue goes to "
"<literal>&ftp-master-host;</literal>, the prescription found in <xref "
"linkend=\"upload-ftp-master\"/> applies here as well."
msgstr ""

# type: Content of: <chapter><section><section><title>
#: pkgs.dbk:431
msgid "Security uploads"
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:433
msgid ""
"Do <emphasis role=\"strong\">NOT</emphasis> upload a package to the security "
"upload queue (<literal>oldstable-security</literal>, "
"<literal>stable-security </literal>, 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:443
msgid "Other upload queues"
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:445
msgid ""
"The scp queues on <literal>&ftp-master-host;</literal>, and <literal> "
"security.debian.org</literal> are mostly unusable due to the login "
"restrictions on those hosts."
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:450
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:454
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><title>
#: pkgs.dbk:462
msgid "Notification that a new package has been installed"
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:464
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 "
"<literal>unstable</literal> 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:474
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:480
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:485
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:493
msgid "Specifying the package section, subsection and priority"
msgstr ""

# type: Content of: <chapter><section><para>
#: pkgs.dbk:495
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:503
msgid ""
"The archive maintainers keep track of the canonical sections and priorities "
"for packages in the <literal>override file</literal>.  If there is a "
"disparity between the <literal>override file</literal> 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 <literal>override file</literal>."
msgstr ""

# type: Content of: <chapter><section><para>
#: pkgs.dbk:513
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; 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:521
msgid ""
"For more information about <literal>override files</literal>, see "
"<citerefentry> <refentrytitle>dpkg-scanpackages</refentrytitle> "
"<manvolnum>1</manvolnum> </citerefentry> and <ulink "
"url=\"&url-bts-devel;#maintincorrect\"></ulink>."
msgstr ""

# type: Content of: <chapter><section><para>
#: pkgs.dbk:527
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=\"&url-debian-policy;ch-archive.html#s-subsections\"></ulink>."
msgstr ""

# type: Content of: <chapter><section><title>
#: pkgs.dbk:536
msgid "Handling bugs"
msgstr ""

# type: Content of: <chapter><section><para>
#: pkgs.dbk:538
msgid ""
"Every developer has to be able to work with the Debian <ulink "
"url=\"&url-bts;\">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:544
msgid ""
"The bug tracking system's features are described in the <ulink "
"url=\"&url-bts-devel;\">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:550
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=\"&url-bts-control;\">BTS control server documentation</ulink>."
msgstr ""

# type: Content of: <chapter><section><section><title>
#: pkgs.dbk:558
msgid "Monitoring bugs"
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:560
msgid ""
"If you want to be a good maintainer, you should periodically check the "
"<ulink url=\"&url-bts;\">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-host;/<replaceable>yourlogin</replaceable>@debian.org</literal>."
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:567
msgid ""
"Maintainers interact with the BTS via email addresses at "
"<literal>&bugs-host;</literal>.  Documentation on available commands can be "
"found at <ulink url=\"&url-bts;\"></ulink>, or, if you have installed the "
"<systemitem role=\"package\">doc-debian</systemitem> package, you can look "
"at the local files &file-bts-docs;."
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:574
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:578
#, no-wrap
msgid ""
"\n"
"# ask for weekly reports of bugs in my packages\n"
"&cron-bug-report;\n"
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:583
msgid ""
"Replace <replaceable>address</replaceable> with your official Debian "
"maintainer address."
msgstr ""

# type: Content of: <chapter><section><section><title>
#: pkgs.dbk:589
msgid "Responding to bugs"
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:591
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-host;</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-host;</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-host;</email>)."
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:600
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:604
msgid ""
"Once you've dealt with a bug report (e.g.  fixed it), mark it as "
"<literal>done</literal> (close it) by sending an explanation message to "
"<email>123-done@&bugs-host;</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:611
msgid ""
"You should <emphasis>never</emphasis> close bugs via the bug server "
"<literal>close</literal> command sent to &email-bts-control;.  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:619
msgid "Bug housekeeping"
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:621
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=\"&url-bts-devel;\">BTS documentation for Debian developers</ulink>.  "
"Operations such as reassigning, merging, and tagging bug reports are "
"described in the <ulink url=\"&url-bts-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:632
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:637
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:642
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:652
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=\"&url-tech-ctte;\">recommended "
"procedure</ulink>."
msgstr ""

# type: Content of: <chapter><section><section><orderedlist><listitem><para>
#: pkgs.dbk:666
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;.  Please "
"inform the maintainer(s) of the package you reassign the bug to, for example "
"by Cc:ing the message that does the reassign to "
"<email>packagename@packages.debian.org</email> and explaining your reasons "
"in that mail. Please note that a simple reassignment is "
"<emphasis>not</emphasis> e-mailed to the maintainers of the package being "
"reassigned to, so they won't know about it until they look at a bug overview "
"for their packages."
msgstr ""

# type: Content of: <chapter><section><section><orderedlist><listitem><para>
#: pkgs.dbk:678
msgid ""
"If the bug affects the operation of your package, please consider cloning "
"the bug and reassigning the clone to the package that really causes the "
"behavior. Otherwise, the bug will not be shown in your package's bug list, "
"possibly causing users to report the same bug over and over again. You "
"should block \"your\" bug with the reassigned, cloned bug to document the "
"relationship."
msgstr ""

# type: Content of: <chapter><section><section><orderedlist><listitem><para>
#: pkgs.dbk:688
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:696
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:707
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:718
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; or &email-debian-qa;.  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:732
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:742
msgid ""
"Once a corrected package is available in the archive, the bug should be "
"closed indicating the version in which it was fixed. This can be done "
"automatically, read <xref linkend=\"upload-bugfix\"/>."
msgstr ""

# type: Content of: <chapter><section><section><title>
#: pkgs.dbk:751
msgid "When bugs are closed by new uploads"
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:753
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:761
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:766
#, no-wrap
msgid ""
"\n"
"acme-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.\n"
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:775
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:778
#, no-wrap
msgid ""
"\n"
"  /closes:\\s*(?:bug)?\\#\\s*\\d+(?:,\\s*(?:bug)?\\#\\s*\\d+)*/ig\n"
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:782
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:791
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:797
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-bts-control;.  To close any remaining bugs "
"that were fixed by your upload, email the <filename>.changes</filename> file "
"to <email>XXX-done@&bugs-host;</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:809
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-host;</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:817
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:823
msgid "Handling security-related bugs"
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:825
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 <literal>security.debian.org</literal>."
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:834
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-security-team; as "
"soon as possible.  <emphasis role=\"strong\">DO NOT UPLOAD</emphasis> any "
"packages for <literal>stable</literal>; the security team will do that.  "
"Useful information includes, for example:"
msgstr ""

# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
#: pkgs.dbk:844
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 "
"<literal>testing</literal> and <literal>unstable</literal>."
msgstr ""

# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
#: pkgs.dbk:851
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:856
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:863
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:869
msgid ""
"Any information needed for the advisory (see <xref "
"linkend=\"bug-security-advisories\"/> )"
msgstr ""

# type: Content of: <chapter><section><section><section><title>
#: pkgs.dbk:875
msgid "Confidentiality"
msgstr ""

# type: Content of: <chapter><section><section><section><para>
#: pkgs.dbk:877
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:884
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:889
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:894
msgid "someone files a bug report"
msgstr ""

# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
#: pkgs.dbk:899
msgid "someone informs them via private email"
msgstr ""

# type: Content of: <chapter><section><section><section><para>
#: pkgs.dbk:904
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:912
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:918
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:925
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:932
msgid ""
"Please note that if secrecy is needed you may not upload a fix to "
"<literal>unstable</literal> (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:939
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:946
msgid "Security Advisories"
msgstr ""

# type: Content of: <chapter><section><section><section><para>
#: pkgs.dbk:948
msgid ""
"Security advisories are only issued for the current, released stable "
"distribution, and <emphasis>not</emphasis> for <literal>testing</literal> or "
"<literal>unstable</literal>.  When released, advisories are sent to the "
"&email-debian-security-announce; mailing list and posted on <ulink "
"url=\"&url-debian-security-advisories;\">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:961
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:966
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:971
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:976
msgid "How it can be exploited"
msgstr ""

# type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para>
#: pkgs.dbk:981
msgid "Whether it is remotely or locally exploitable"
msgstr ""

# type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para>
#: pkgs.dbk:986
msgid "How the problem was fixed"
msgstr ""

# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
#: pkgs.dbk:991
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:996
msgid "Version numbers of affected packages"
msgstr ""

# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
#: pkgs.dbk:1001
msgid "Version numbers of fixed packages"
msgstr ""

# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
#: pkgs.dbk:1006
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:1012
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:1021
msgid "Preparing packages to address security issues"
msgstr ""

# type: Content of: <chapter><section><section><section><para>
#: pkgs.dbk:1023
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:1028
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:1036
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:1042
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:1049
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:1056
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:1066
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:1074
msgid "Be sure to verify the following items:"
msgstr ""

# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
#: pkgs.dbk:1079
msgid ""
"Target the right distribution in your "
"<filename>debian/changelog</filename>.  For <literal>stable</literal> 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><literal>-proposed-updates</literal> "
"or <literal>stable</literal>!"
msgstr ""

# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
#: pkgs.dbk:1089
msgid "The upload should have urgency=high."
msgstr ""

# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
#: pkgs.dbk:1094
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 "
"<literal>unstable</literal>, 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:1107
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 <literal>testing</literal>, there must be a higher version in "
"<literal>unstable</literal>.  If there is none yet (for example, if "
"<literal>testing</literal> and <literal>unstable</literal> have the same "
"version) you must upload a new version to <literal>unstable</literal> first."
msgstr ""

# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
#: pkgs.dbk:1119
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:1128
msgid ""
"Unless the upstream source has been uploaded to <literal>security.debian.org "
"</literal> 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 <literal>security.debian.org</literal> 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:1138
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:1145
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:1156
msgid "Uploading the fixed package"
msgstr ""

# type: Content of: <chapter><section><section><section><para>
#: pkgs.dbk:1158
msgid ""
"Do <emphasis role=\"strong\">NOT</emphasis> upload a package to the security "
"upload queue (<literal>oldstable-security</literal>, "
"<literal>stable-security </literal>, 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:1165
msgid ""
"Do <emphasis role=\"strong\">NOT</emphasis> upload your fix to <literal> "
"proposed-updates</literal> without coordinating with the security team.  "
"Packages from <literal>security.debian.org</literal> will be copied into the "
"<literal>proposed-updates</literal> 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:1175
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:1181
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:1186
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:1191
msgid ""
"If a member of the security team accepts a package, it will be installed on "
"<literal>security.debian.org</literal> as well as proposed for the proper "
"<replaceable>distribution</replaceable><literal>-proposed-updates</literal> "
"on <literal>&ftp-master-host;</literal>."
msgstr ""

# type: Content of: <chapter><section><title>
#: pkgs.dbk:1203
msgid "Moving, removing, renaming, adopting, and orphaning packages"
msgstr ""

# type: Content of: <chapter><section><para>
#: pkgs.dbk:1205
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:1210
msgid "Moving packages"
msgstr ""

# type: Content of: <chapter><section><section><para><footnote>
#: pkgs.dbk:1212
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:1214
msgid ""
"See the <ulink url=\"&url-debian-policy;\">Debian Policy Manual</ulink> for "
"guidelines on what section a package belongs in."
msgstr ""

# type: Content of: <chapter><section><section><section><para>
#: pkgs.dbk:1216 pkgs.dbk:1648
msgid "</footnote>"
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:1219
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=\"&url-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:1231
msgid ""
"If, on the other hand, you need to change the <literal>subsection</literal> "
"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:1240
msgid "Removing packages"
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:1242
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.  The "
"bug title should be in the form <literal>RM: <replaceable>package "
"</replaceable> <replaceable>[architecture list]</replaceable> -- "
"<replaceable>reason</replaceable></literal>, where "
"<replaceable>package</replaceable> is the package to be removed and "
"<replaceable>reason</replaceable> is a short summary of the reason for the "
"removal request.  <replaceable>[architecture list]</replaceable> is optional "
"and only needed if the removal request only applies to some architectures, "
"not all. Note that the <command>reportbug</command> will create a title "
"conforming to these rules when you use it to report a bug against the "
"<literal> ftp.debian.org</literal> pseudo-package."
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:1259
msgid ""
"If you want to remove a package you maintain, you should note this in the "
"bug title by prepending <literal>ROM</literal> (Request Of Maintainer).  "
"There are several other standard acronyms used in the reasoning for a "
"package removal, see <ulink "
"url=\"http://&ftp-master-host;/removals.html\"></ulink> for a complete "
"list. That page also provides a convenient overview of pending removal "
"requests."
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:1268
msgid ""
"Note that removals can only be done for the <literal>unstable </literal>, "
"<literal>experimental</literal> and <literal>stable </literal> "
"distribution.  Packages are not removed from <literal>testing</literal> "
"directly.  Rather, they will be removed automatically after the package has "
"been removed from <literal>unstable</literal> and no package in "
"<literal>testing </literal> depends on it."
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:1277
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:1286
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:1292
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. Should the package be orphaned and thus have no maintainer, you "
"should first discuss the removal request on &email-debian-qa;. If there is a "
"consensus that the package should be removed, you should reassign and "
"retitle the <literal>O:</literal> bug filed against the "
"<literal>wnpp</literal> package instead of filing a new bug as removal "
"request."
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:1302
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=\"&url-debian-qa;howto-remove.html\"></ulink>."
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:1307
msgid ""
"If in doubt concerning whether a package is disposable, email "
"&email-debian-devel; 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>, "
"<command>build-rdeps</command> (in the <systemitem "
"role=\"package\">devscripts</systemitem> package) and "
"<command>grep-dctrl</command>.  Removal of orphaned packages is discussed on "
"&email-debian-qa;."
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:1320
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:1327
msgid "Removing packages from <filename>Incoming</filename>"
msgstr ""

# type: Content of: <chapter><section><section><section><para>
#: pkgs.dbk:1329
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 <literal>unstable</literal> "
"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:1344
msgid "Replacing or renaming packages"
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:1346
msgid ""
"When the upstream maintainers for one of your packages chose to rename their "
"software (or you made a mistake naming your package), you should follow a "
"two-step process to rename it. In the first step, change the "
"<filename>debian/control</filename> file to reflect the new name and to "
"replace, provide and conflict with the obsolete package name (see the <ulink "
"url=\"&url-debian-policy;\"> Debian Policy Manual</ulink> for details).  "
"Please note that you should only add a <literal>Provides</literal> relation "
"if all packages depending on the obsolete package name continue to work "
"after the renaming. 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 "
"(see <xref linkend=\"removing-pkgs\"/>).  Do not forget to properly reassign "
"the package's bugs at the same time."
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:1362
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:1376
msgid "Orphaning a package"
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:1378
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 &orphan-address;</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 "
"<literal>normal</literal>; 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; 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:1393
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 "
"<literal>Request For Adoption</literal>."
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:1401
msgid "More information is on the <ulink url=\"&url-wnpp;\">WNPP web pages</ulink>."
msgstr ""

# type: Content of: <chapter><section><section><title>
#: pkgs.dbk:1407
msgid "Adopting a package"
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:1409
msgid ""
"A list of packages in need of a new maintainer is available in the <ulink "
"url=\"&url-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:1416
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:1422
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=\"&url-tech-ctte;\">technical committee web page</ulink> for more "
"information)."
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:1432
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:1446
msgid "Porting and being ported"
msgstr ""

# type: Content of: <chapter><section><para>
#: pkgs.dbk:1448
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:1454
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, when a maintainer "
"uploads a (portable) source packages with binaries for the <literal>i386 "
"</literal> architecture, it will be built for each of the other "
"architectures, amounting to &number-of-arches; more builds."
msgstr ""

# type: Content of: <chapter><section><section><title>
#: pkgs.dbk:1463
msgid "Being kind to porters"
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:1465
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:1473
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:1480
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:1487
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 "
"<literal>unstable</literal> 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:1502
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:1506
msgid ""
"See the <ulink url=\"&url-debian-policy;\">Debian Policy Manual</ulink> for "
"instructions on setting build dependencies."
msgstr ""

# type: Content of: <chapter><section><section><orderedlist><listitem><para>
#: pkgs.dbk:1512
msgid ""
"Don't set architecture to a value other than <literal>all</literal> or "
"<literal>any</literal> unless you really mean it.  In too many cases, "
"maintainers don't follow the instructions in the <ulink "
"url=\"&url-debian-policy;\">Debian Policy Manual</ulink>.  Setting your "
"architecture to only one architecture (such as <literal>i386</literal> or "
"<literal>amd64</literal>) is usually incorrect."
msgstr ""

# type: Content of: <chapter><section><section><orderedlist><listitem><para>
#: pkgs.dbk:1522
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:1530
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 <literal>clean</literal> target of "
"<filename>debian/rules</filename>."
msgstr ""

# type: Content of: <chapter><section><section><orderedlist><listitem><para>
#: pkgs.dbk:1538
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:1547
msgid ""
"Don't depend on the package you're building being installed already (a "
"sub-case of the above issue). There are, of course, exceptions to this rule, "
"but be aware that any case like this needs manual bootstrapping and cannot "
"be done by automated package builders."
msgstr ""

# type: Content of: <chapter><section><section><orderedlist><listitem><para>
#: pkgs.dbk:1555
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:1563
msgid ""
"Make sure your debian/rules contains separate <literal>binary-arch</literal> "
"and <literal>binary-indep</literal> 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 <command>dpkg-buildpackage -B</command>."
msgstr ""

# type: Content of: <chapter><section><section><title>
#: pkgs.dbk:1574
msgid "Guidelines for porter uploads"
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:1576
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:1584
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:1589
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 <literal>binary-arch</literal> target in "
"<filename>debian/rules </filename>."
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:1598
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:1605
msgid "Recompilation or binary-only NMU"
msgstr ""

# type: Content of: <chapter><section><section><section><para>
#: pkgs.dbk:1607
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>dak</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:1616
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 have inter-dependencies "
"generated using dpkg's substitution variable <literal>$(Source-Version)  "
"</literal>."
msgstr ""

# type: Content of: <chapter><section><section><section><para>
#: pkgs.dbk:1623
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:1628
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:1635
msgid ""
"The ``magic'' for a recompilation-only NMU is triggered by using a suffix "
"appended to the package version number, following the form <literal> "
"b<replaceable>number</replaceable></literal>.  For instance, if the latest "
"version you are recompiling against was version <literal>2.9-3</literal>, "
"your binary-only NMU should carry a version of <literal>2.9-3+b1</literal>.  "
"If the latest version was <literal>3.4+b1 </literal> (i.e, a native package "
"with a previous recompilation NMU), your binary-only NMU should have a "
"version number of <literal>3.4+b2</literal>.  <footnote>"
msgstr ""

# type: Content of: <chapter><section><section><section><para><footnote><para>
#: pkgs.dbk:1643
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:1651
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:1658
msgid "When to do a source NMU if you are a porter"
msgstr ""

# type: Content of: <chapter><section><section><section><para>
#: pkgs.dbk:1660
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:1669
msgid ""
"If you are a porter doing an NMU for <literal>unstable</literal>, 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 <literal>unstable</literal> 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 "
"<literal>stable</literal> or <literal>testing </literal>, please coordinate "
"with the appropriate release team first."
msgstr ""

# type: Content of: <chapter><section><section><section><para>
#: pkgs.dbk:1681
msgid ""
"Secondly, porters doing source NMUs should make sure that the bug they "
"submit to the BTS should be of severity <literal>serious</literal> 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 "
"architectures in order to comply with many licenses."
msgstr ""

# type: Content of: <chapter><section><section><section><para>
#: pkgs.dbk:1689
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:1697
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:1707
msgid "Porting infrastructure and automation"
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:1709
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:1714
msgid "Mailing lists and web pages"
msgstr ""

# type: Content of: <chapter><section><section><section><para>
#: pkgs.dbk:1716
msgid ""
"Web pages containing the status of each port can be found at <ulink "
"url=\"&url-debian-ports;\"></ulink>."
msgstr ""

# type: Content of: <chapter><section><section><section><para>
#: pkgs.dbk:1720
msgid ""
"Each port of Debian has a mailing list.  The list of porting mailing lists "
"can be found at <ulink url=\"&url-debian-port-lists;\"></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:1728
msgid "Porter tools"
msgstr ""

# type: Content of: <chapter><section><section><section><para>
#: pkgs.dbk:1730
msgid ""
"Descriptions of several porting tools can be found in <xref "
"linkend=\"tools-porting\"/> ."
msgstr ""

# type: Content of: <chapter><section><section><section><title>
#: pkgs.dbk:1736
msgid "<systemitem role=\"package\">wanna-build</systemitem>"
msgstr ""

# type: Content of: <chapter><section><section><section><para>
#: pkgs.dbk:1738
msgid ""
"The <systemitem role=\"package\">wanna-build</systemitem> system is used as "
"a distributed, client-server build distribution system.  It is usually used "
"in conjunction with build daemons running the <systemitem "
"role=\"package\">buildd </systemitem> program. <literal>Build "
"daemons</literal> are ``slave'' hosts which contact the central <systemitem "
"role=\"package\"> wanna-build</systemitem> system to receive a list of "
"packages that need to be built."
msgstr ""

# type: Content of: <chapter><section><section><section><para>
#: pkgs.dbk:1746
msgid ""
"<systemitem role=\"package\">wanna-build</systemitem> is not yet available "
"as a package; however, all Debian porting efforts are using it for automated "
"package building.  The tool used to do the actual package builds, "
"<systemitem role=\"package\">sbuild</systemitem> is available as a package, "
"see its description in <xref linkend=\"sbuild\"/> .  Please note that the "
"packaged version is not the same as the one used on build daemons, but it is "
"close enough to reproduce problems."
msgstr ""

# type: Content of: <chapter><section><section><section><para>
#: pkgs.dbk:1755
msgid ""
"Most of the data produced by <systemitem role=\"package\">wanna-build "
"</systemitem> which is generally useful to porters is available on the web "
"at <ulink url=\"&url-buildd;\"></ulink>.  This data includes nightly updated "
"statistics, queueing information and logs for build attempts."
msgstr ""

# type: Content of: <chapter><section><section><section><para>
#: pkgs.dbk:1761
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:1768
msgid ""
"The buildds admins of each arch can be contacted at the mail address "
"<literal><replaceable>arch</replaceable>@buildd.debian.org</literal>."
msgstr ""

# type: Content of: <chapter><section><section><title>
#: pkgs.dbk:1776
msgid "When your package is <emphasis>not</emphasis> portable"
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:1778
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 available for <literal>i386</literal> and "
"<literal>amd64</literal>), or uses other hardware-specific features not "
"supported on all architectures."
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:1785
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:1791
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:1799
msgid ""
"Additionally, if you believe the list of supported architectures is pretty "
"constant, you should change <literal>any</literal> to a list of supported "
"architectures in <filename>debian/control</filename>.  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:1807
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=\"&url-cvsweb;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:1817
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:1830
msgid "Non-Maintainer Uploads (NMUs)"
msgstr ""

# type: Content of: <chapter><section><para>
#: pkgs.dbk:1832
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:1837
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=\"wanna-build\"/> for some more information."
msgstr ""

# type: Content of: <chapter><section><para>
#: pkgs.dbk:1844
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:1849
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:1858
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:1863
msgid "How to do a NMU"
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:1865
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:1871
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:1877
msgid ""
"A NMU should follow all conventions, written down in this section.  For an "
"upload to <literal>testing</literal> or <literal>unstable</literal>, this "
"order of steps is recommended:"
msgstr ""

# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
#: pkgs.dbk:1884
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:1891
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:1898
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:1908
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:1916
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:1923
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:1932
msgid ""
"For the <literal>testing</literal> 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 <literal>testing</literal> is through "
"<literal>unstable</literal>."
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:1938
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:1944
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:1949
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:1953
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:1960
msgid "NMU version numbering"
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:1962
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:1966
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:1977
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:1983
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:1993
msgid ""
"If you upload a package to <literal>testing</literal> or <literal>stable "
"</literal>, 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:2000
msgid "Source NMUs must have a new changelog entry"
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:2002
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:2008
msgid "By convention, source NMU changelog entries start with the line"
msgstr ""

# type: Content of: <chapter><section><section><screen>
#: pkgs.dbk:2010
#, no-wrap
msgid ""
"\n"
"  * Non-maintainer upload\n"
msgstr ""

# type: Content of: <chapter><section><section><title>
#: pkgs.dbk:2016
msgid "Source NMUs and the Bug Tracking System"
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:2018
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:2024
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:2031
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:2036
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:2047
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:2055
msgid "Building source NMUs"
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:2057
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:2062
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:2070
msgid "Acknowledging an NMU"
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:2072
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:2083
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:2093
msgid "NMU vs QA uploads"
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:2095
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=\"&url-debian-qa-orphaned;\"></ulink>.  If you perform an NMU on "
"an improperly orphaned package, please set the maintainer to <literal>Debian "
"QA Group &lt;packages@qa.debian.org&gt;</literal>."
msgstr ""

# type: Content of: <chapter><section><section><title>
#: pkgs.dbk:2105
msgid "Who can do an NMU"
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:2107
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:2117
msgid "Terminology"
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:2119
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 "
"<literal>non-maintainer</literal> upload."
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:2127
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:2136
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:2146
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:2156
msgid "Collaborative maintenance"
msgstr ""

# type: Content of: <chapter><section><para>
#: pkgs.dbk:2158
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:2166
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, usually listed in the <literal>Uploaders</literal> field of the "
"<filename>debian/control</filename> file."
msgstr ""

# type: Content of: <chapter><section><para>
#: pkgs.dbk:2174
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:2180
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:2188
msgid ""
"Add the co-maintainer's correct maintainer name and address to the "
"<literal>Uploaders</literal> field in the first paragraph of the "
"<filename>debian/control</filename> file."
msgstr ""

# type: Content of: <chapter><section><itemizedlist><listitem><screen>
#: pkgs.dbk:2192
#, no-wrap
msgid ""
"\n"
"Uploaders: John Buzz &lt;jbuzz@debian.org&gt;, Adam Rex "
"&lt;arex@debian.org&gt;\n"
msgstr ""

# type: Content of: <chapter><section><itemizedlist><listitem><para>
#: pkgs.dbk:2198
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:2204
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:2213
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:2220
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:2228
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:2236
msgid "The testing distribution"
msgstr ""

# type: Content of: <chapter><section><section><title>
#: pkgs.dbk:2238
msgid "Basics"
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:2240
msgid ""
"Packages are usually installed into the <literal>testing</literal> "
"distribution after they have undergone some degree of "
"<literal>testing</literal> in <literal>unstable</literal>."
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:2245
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 <literal>testing "
"</literal>.  This way, <literal>testing</literal> should always be close to "
"being a release candidate.  Please see below for details."
msgstr ""

# type: Content of: <chapter><section><section><title>
#: pkgs.dbk:2254
msgid "Updates from unstable"
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:2256
msgid ""
"The scripts that update the <literal>testing</literal> distribution are run "
"twice each day, right after the installation of the updated packages; these "
"scripts are called <literal>britney</literal>.  They generate the "
"<filename>Packages</filename> files for the <literal>testing</literal> "
"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:2264
msgid ""
"The inclusion of a package from <literal>unstable</literal> is conditional "
"on the following:"
msgstr ""

# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
#: pkgs.dbk:2270
msgid ""
"The package must have been available in <literal>unstable</literal> 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 <literal>testing</literal> transition is taken into account.  "
"Those delays may be doubled during a freeze, or <literal>testing</literal> "
"transitions may be switched off altogether;"
msgstr ""

# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
#: pkgs.dbk:2280
msgid ""
"It must not have new release-critical bugs (RC bugs affecting the version "
"available in <literal>unstable</literal>, but not affecting the version in "
"<literal>testing</literal>);"
msgstr ""

# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
#: pkgs.dbk:2287
msgid ""
"It must be available on all architectures on which it has previously been "
"built in <literal>unstable</literal>.  <xref linkend=\"dak-ls\"/> may be of "
"interest to check that information;"
msgstr ""

# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
#: pkgs.dbk:2294
msgid ""
"It must not break any dependency of a package which is already available in "
"<literal>testing</literal>;"
msgstr ""

# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
#: pkgs.dbk:2300
msgid ""
"The packages on which it depends must either be available in "
"<literal>testing</literal> or they must be accepted into "
"<literal>testing</literal> 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:2308
msgid ""
"To find out whether a package is progressing into <literal>testing</literal> "
"or not, see the <literal>testing</literal> script output on the <ulink "
"url=\"&url-testing-maint;\">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 <literal>testing</literal>."
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:2319
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=\"&url-testing-maint;\">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:2326
msgid ""
"Sometimes, some packages never enter <literal>testing</literal> 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:2331
msgid ""
"Some further dependency analysis is shown on <ulink "
"url=\"http://release.debian.org/migration/\"></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:2336
msgid "out-of-date"
msgstr ""

#.  FIXME: better rename this file than document rampant professionalism? 
# type: Content of: <chapter><section><section><section><para>
#: pkgs.dbk:2339
msgid ""
"For the <literal>testing</literal> migration script, outdated means: There "
"are different versions in <literal>unstable</literal> for the release "
"architectures (except for the architectures in fuckedarches; fuckedarches is "
"a list of architectures that don't keep up (in "
"<filename>update_out.py</filename>), but currently, it's empty).  outdated "
"has nothing whatsoever to do with the architectures this package has in "
"<literal>testing</literal>."
msgstr ""

# type: Content of: <chapter><section><section><section><para>
#: pkgs.dbk:2347
msgid "Consider this example:"
msgstr ""

# type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry>
#: pkgs.dbk:2354 pkgs.dbk:2387
msgid "alpha"
msgstr ""

# type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry>
#: pkgs.dbk:2355 pkgs.dbk:2388
msgid "arm"
msgstr ""

# type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry>
#: pkgs.dbk:2360 pkgs.dbk:2394 pkgs.dbk:2456
msgid "testing"
msgstr ""

# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
#: pkgs.dbk:2361 pkgs.dbk:2366 pkgs.dbk:2395 pkgs.dbk:2396 pkgs.dbk:2403
msgid "1"
msgstr ""

# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
#: pkgs.dbk:2362 pkgs.dbk:2397 pkgs.dbk:2402
msgid "-"
msgstr ""

# type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry>
#: pkgs.dbk:2365 pkgs.dbk:2400 pkgs.dbk:2457
msgid "unstable"
msgstr ""

# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
#: pkgs.dbk:2367 pkgs.dbk:2401
msgid "2"
msgstr ""

# type: Content of: <chapter><section><section><section><para>
#: pkgs.dbk:2373
msgid ""
"The package is out of date on alpha in <literal>unstable</literal>, and will "
"not go to <literal>testing</literal>. Removing the package would not help at "
"all, the package is still out of date on <literal>alpha</literal>, and will "
"not propagate to testing."
msgstr ""

# type: Content of: <chapter><section><section><section><para>
#: pkgs.dbk:2379
msgid ""
"However, if ftp-master removes a package in <literal>unstable</literal> "
"(here on <literal>arm</literal>):"
msgstr ""

# type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry>
#: pkgs.dbk:2389
msgid "hurd-i386"
msgstr ""

# type: Content of: <chapter><section><section><section><para>
#: pkgs.dbk:2409
msgid ""
"In this case, the package is up to date on all release architectures in "
"<literal>unstable</literal> (and the extra <literal>hurd-i386</literal> "
"doesn't matter, as it's not a release architecture)."
msgstr ""

# type: Content of: <chapter><section><section><section><para>
#: pkgs.dbk:2414
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:2421
msgid "Removals from testing"
msgstr ""

# type: Content of: <chapter><section><section><section><para>
#: pkgs.dbk:2423
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 <literal>a</literal> cannot be "
"installed with the new version of <literal>b</literal>; then "
"<literal>a</literal> may be removed to allow <literal>b</literal> in."
msgstr ""

# type: Content of: <chapter><section><section><section><para>
#: pkgs.dbk:2430
msgid ""
"Of course, there is another reason to remove a package from <literal>testing "
"</literal>: 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:2435
msgid ""
"Furthermore, if a package has been removed from <literal>unstable</literal>, "
"and no package in <literal>testing</literal> depends on it any more, then it "
"will automatically be removed."
msgstr ""

# type: Content of: <chapter><section><section><section><title>
#: pkgs.dbk:2442
msgid "circular dependencies"
msgstr ""

# type: Content of: <chapter><section><section><section><para>
#: pkgs.dbk:2444
msgid ""
"A situation which is not handled very well by britney is if package "
"<literal>a</literal> depends on the new version of package "
"<literal>b</literal>, and vice versa."
msgstr ""

# type: Content of: <chapter><section><section><section><para>
#: pkgs.dbk:2449
msgid "An example of this is:"
msgstr ""

# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
#: pkgs.dbk:2462
msgid "a"
msgstr ""

# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
#: pkgs.dbk:2463
msgid "1; depends: b=1"
msgstr ""

# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
#: pkgs.dbk:2464
msgid "2; depends: b=2"
msgstr ""

# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
#: pkgs.dbk:2467
msgid "b"
msgstr ""

# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
#: pkgs.dbk:2468
msgid "1; depends: a=1"
msgstr ""

# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
#: pkgs.dbk:2469
msgid "2; depends: a=2"
msgstr ""

# type: Content of: <chapter><section><section><section><para>
#: pkgs.dbk:2475
msgid ""
"Neither package <literal>a</literal> nor package <literal>b</literal> is "
"considered for update."
msgstr ""

# type: Content of: <chapter><section><section><section><para>
#: pkgs.dbk:2479
msgid ""
"Currently, this requires some manual hinting from the release team.  Please "
"contact them by sending mail to &email-debian-release; if this happens to "
"one of your packages."
msgstr ""

# type: Content of: <chapter><section><section><section><title>
#: pkgs.dbk:2486
msgid "influence of package in testing"
msgstr ""

# type: Content of: <chapter><section><section><section><para>
#: pkgs.dbk:2488
msgid ""
"Generally, there is nothing that the status of a package in <literal>testing "
"</literal> means for transition of the next version from <literal>unstable "
"</literal> to <literal>testing</literal>, 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 "
"<literal> testing</literal> 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 "
"<literal>unstable </literal> at all during the <literal>testing</literal> "
"migration."
msgstr ""

# type: Content of: <chapter><section><section><section><para>
#: pkgs.dbk:2500
msgid ""
"In summary this means: The only influence that a package being in <literal> "
"testing</literal> 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:2507
msgid "details"
msgstr ""

# type: Content of: <chapter><section><section><section><para>
#: pkgs.dbk:2509
msgid "If you are interested in details, this is how britney works:"
msgstr ""

# type: Content of: <chapter><section><section><section><para>
#: pkgs.dbk:2512
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:2521
msgid ""
"Now, the more complex part happens: Britney tries to update <literal>testing "
"</literal> with the valid candidates. For that, britney tries to add each "
"valid candidate to the testing distribution. If the number of uninstallable "
"packages in <literal>testing</literal> doesn't increase, the package is "
"accepted. From that point on, the accepted package is considered to be part "
"of <literal>testing</literal>, such that all subsequent installability tests "
"include this package.  Hints from the release team are processed before or "
"after this main run, depending on the exact type."
msgstr ""

# type: Content of: <chapter><section><section><section><para>
#: pkgs.dbk:2531
msgid ""
"If you want to see more details, you can look it up on "
"<filename>merkel:/org/&ftp-debian-org;/testing/update_out/</filename> (or in "
"<filename>merkel:~aba/testing/update_out</filename> to see a setup with a "
"smaller packages file).  Via web, it's at <ulink "
"url=\"http://&ftp-master-host;/testing/update_out_code/\"></ulink>"
msgstr ""

# type: Content of: <chapter><section><section><section><para>
#: pkgs.dbk:2538
msgid ""
"The hints are available via <ulink "
"url=\"http://&ftp-master-host;/testing/hints/\"></ulink>."
msgstr ""

# type: Content of: <chapter><section><section><title>
#: pkgs.dbk:2546
msgid "Direct updates to testing"
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:2548
msgid ""
"The <literal>testing</literal> distribution is fed with packages from "
"<literal>unstable</literal> according to the rules explained above.  "
"However, in some cases, it is necessary to upload packages built only for "
"<literal> testing</literal>.  For that, you may want to upload to <literal> "
"testing-proposed-updates</literal>."
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:2555
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;."
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:2562
msgid ""
"You should not upload to <literal>testing-proposed-updates</literal> when "
"you can update your packages through <literal>unstable</literal>.  If you "
"can't (for example because you have a newer development version in "
"<literal>unstable </literal>), 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 <literal>unstable</literal> are "
"possible, if the upload via <literal>unstable</literal> does not pull in any "
"new dependencies."
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:2571
msgid ""
"Version numbers are usually selected by adding the codename of the "
"<literal>testing</literal> distribution and a running number, like "
"<literal>1.2sarge1</literal> for the first upload through "
"<literal>testing-proposed-updates</literal> of package version "
"<literal>1.2</literal>."
msgstr ""

# type: Content of: <chapter><section><section><para>
#: pkgs.dbk:2578
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:2583
msgid ""
"Make sure that your package really needs to go through "
"<literal>testing-proposed-updates</literal>, and can't go through <literal> "
"unstable</literal>;"
msgstr ""

# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
#: pkgs.dbk:2590
msgid "Make sure that you included only the minimal amount of changes;"
msgstr ""

# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
#: pkgs.dbk:2595
msgid "Make sure that you included an appropriate explanation in the changelog;"
msgstr ""

# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
#: pkgs.dbk:2600
msgid ""
"Make sure that you've written <literal>testing</literal> or "
"<literal>testing-proposed-updates</literal> into your target distribution;"
msgstr ""

# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
#: pkgs.dbk:2606
msgid ""
"Make sure that you've built and tested your package in "
"<literal>testing</literal>, not in <literal>unstable</literal>;"
msgstr ""

# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
#: pkgs.dbk:2612
msgid ""
"Make sure that your version number is higher than the version in "
"<literal>testing</literal> and <literal>testing-proposed-updates</literal>, "
"and lower than in <literal>unstable</literal>;"
msgstr ""

# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
#: pkgs.dbk:2619
msgid ""
"After uploading and successful build on all platforms, contact the release "
"team at &email-debian-release; and ask them to approve your upload."
msgstr ""

# type: Content of: <chapter><section><section><title>
#: pkgs.dbk:2627
msgid "Frequently asked questions"
msgstr ""

# type: Content of: <chapter><section><section><section><title>
#: pkgs.dbk:2629
msgid "What are release-critical bugs, and how do they get counted?"
msgstr ""

# type: Content of: <chapter><section><section><section><para>
#: pkgs.dbk:2631
msgid ""
"All bugs of some higher severities are by default considered "
"release-critical; currently, these are <literal>critical</literal>, "
"<literal>grave</literal> and <literal>serious</literal> bugs."
msgstr ""

# type: Content of: <chapter><section><section><section><para>
#: pkgs.dbk:2636
msgid ""
"Such bugs are presumed to have an impact on the chances that the package "
"will be released with the <literal>stable</literal> release of Debian: in "
"general, if a package has open release-critical bugs filed on it, it won't "
"get into <literal>testing</literal>, and consequently won't be released in "
"<literal> stable</literal>."
msgstr ""

# type: Content of: <chapter><section><section><section><para>
#: pkgs.dbk:2643
msgid ""
"The <literal>unstable</literal> bug count are all release-critical bugs "
"which are marked to apply to "
"<replaceable>package</replaceable>/<replaceable>version </replaceable> "
"combinations that are available in unstable for a release architecture. The "
"<literal>testing</literal> bug count is defined analogously."
msgstr ""

# type: Content of: <chapter><section><section><section><title>
#: pkgs.dbk:2651
msgid ""
"How could installing a package into <literal>testing</literal> possibly "
"break other packages?"
msgstr ""

# type: Content of: <chapter><section><section><section><para>
#: pkgs.dbk:2654
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 <literal>acmefoo</literal> is installed into "
"<literal>testing</literal>, along with its binary packages "
"<literal>acme-foo-bin</literal>, <literal> acme-bar-bin</literal>, "
"<literal>libacme-foo1</literal> and <literal> libacme-foo-dev</literal>, the "
"old version is removed."
msgstr ""

# type: Content of: <chapter><section><section><section><para>
#: pkgs.dbk:2662
msgid ""
"However, the old version may have provided a binary package with an old "
"soname of a library, such as <literal>libacme-foo0</literal>.  Removing the "
"old <literal>acmefoo</literal> will remove <literal>libacme-foo0</literal>, "
"which will break any packages which depend on it."
msgstr ""

# type: Content of: <chapter><section><section><section><para>
#: pkgs.dbk:2668
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 ==, &lt;=, or &lt;&lt; varieties."
msgstr ""

# type: Content of: <chapter><section><section><section><para>
#: pkgs.dbk:2674
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 <literal>testing</literal> breaks all the packages that "
"depended on it in <literal>testing</literal>, 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:2685
msgid ""
"If you are having problems with complicated groups of packages like this, "
"contact &email-debian-devel; or &email-debian-release; for help."
msgstr ""