1 # SOME DESCRIPTIVE TITLE
2 # Copyright (C) YEAR Free Software Foundation, Inc.
3 # This file is distributed under the same license as the PACKAGE package.
4 # FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
9 "Project-Id-Version: PACKAGE VERSION\n"
10 "POT-Creation-Date: 2008-08-08 11:33-0300\n"
11 "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
12 "Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
13 "Language-Team: LANGUAGE <LL@li.org>\n"
15 "Content-Type: text/plain; charset=utf-8\n"
16 "Content-Transfer-Encoding: ENCODING"
18 # type: Content of: <chapter><title>
20 msgid "Managing Packages"
23 # type: Content of: <chapter><para>
26 "This chapter contains information related to creating, uploading, "
27 "maintaining, and porting packages."
30 # type: Content of: <chapter><section><title>
35 # type: Content of: <chapter><section><para>
38 "If you want to create a new package for the Debian distribution, you should "
39 "first check the <ulink url=\"&url-wnpp;\">Work-Needing and Prospective "
40 "Packages (WNPP)</ulink> list. Checking the WNPP list ensures that no one is "
41 "already working on packaging that software, and that effort is not "
42 "duplicated. Read the <ulink url=\"&url-wnpp;\">WNPP web pages</ulink> for "
46 # type: Content of: <chapter><section><para>
49 "Assuming no one else is already working on your prospective package, you "
50 "must then submit a bug report (<xref linkend=\"submit-bug\"/> ) against the "
51 "pseudo-package <systemitem role=\"package\">wnpp</systemitem> describing "
52 "your plan to create a new package, including, but not limiting yourself to, "
53 "a description of the package, the license of the prospective package, and "
54 "the current URL where it can be downloaded from."
57 # type: Content of: <chapter><section><para>
60 "You should set the subject of the bug to <literal>ITP: "
61 "<replaceable>foo</replaceable> -- <replaceable>short "
62 "description</replaceable></literal>, substituting the name of the new "
63 "package for <replaceable>foo</replaceable>. The severity of the bug report "
64 "must be set to <literal>wishlist</literal>. Please send a copy to "
65 "&email-debian-devel; by using the X-Debbugs-CC header (don't use CC:, "
66 "because that way the message's subject won't indicate the bug number). If "
67 "you are packaging so many new packages (>10) that notifying the mailing "
68 "list in seperate messages is too disruptive, do send a summary after filing "
69 "the bugs to the debian-devel list instead. This will inform the other "
70 "developers about upcoming packages and will allow a review of your "
71 "description and package name."
74 # type: Content of: <chapter><section><para>
77 "Please include a <literal>Closes: "
78 "bug#<replaceable>nnnnn</replaceable></literal> entry in the changelog of the "
79 "new package in order for the bug report to be automatically closed once the "
80 "new package is installed in the archive (see <xref "
81 "linkend=\"upload-bugfix\"/> )."
84 # type: Content of: <chapter><section><para>
87 "When closing security bugs include CVE numbers as well as the Closes: "
88 "#nnnnn. This is useful for the security team to track vulnerabilities. If "
89 "an upload is made to fix the bug before the advisory ID is known, it is "
90 "encouraged to modify the historical changelog entry with the next upload. "
91 "Even in this case, please include all available pointers to background "
92 "information in the original changelog entry."
95 # type: Content of: <chapter><section><para>
98 "There are a number of reasons why we ask maintainers to announce their "
102 # type: Content of: <chapter><section><itemizedlist><listitem><para>
105 "It helps the (potentially new) maintainer to tap into the experience of "
106 "people on the list, and lets them know if anyone else is working on it "
110 # type: Content of: <chapter><section><itemizedlist><listitem><para>
113 "It lets other people thinking about working on the package know that there "
114 "already is a volunteer, so efforts may be shared."
117 # type: Content of: <chapter><section><itemizedlist><listitem><para>
120 "It lets the rest of the maintainers know more about the package than the one "
121 "line description and the usual changelog entry ``Initial release'' that gets "
122 "posted to &email-debian-devel-changes;."
125 # type: Content of: <chapter><section><itemizedlist><listitem><para>
128 "It is helpful to the people who live off <literal>unstable</literal> (and "
129 "form our first line of testers). We should encourage these people."
132 # type: Content of: <chapter><section><itemizedlist><listitem><para>
135 "The announcements give maintainers and other interested parties a better "
136 "feel of what is going on, and what is new, in the project."
139 # type: Content of: <chapter><section><para>
142 "Please see <ulink url=\"http://&ftp-master-host;/REJECT-FAQ.html\"></ulink> "
143 "for common rejection reasons for a new package."
146 # type: Content of: <chapter><section><title>
148 msgid "Recording changes in the package"
151 # type: Content of: <chapter><section><para>
154 "Changes that you make to the package need to be recorded in the "
155 "<filename>debian/changelog</filename>. These changes should provide a "
156 "concise description of what was changed, why (if it's in doubt), and note if "
157 "any bugs were closed. They also record when the package was completed. "
158 "This file will be installed in "
159 "<filename>/usr/share/doc/<replaceable>package</replaceable>/changelog.Debian.gz</filename>, "
161 "<filename>/usr/share/doc/<replaceable>package</replaceable>/changelog.gz</filename> "
162 "for native packages."
165 # type: Content of: <chapter><section><para>
168 "The <filename>debian/changelog</filename> file conforms to a certain "
169 "structure, with a number of different fields. One field of note, the "
170 "<literal>distribution</literal>, is described in <xref "
171 "linkend=\"distribution\"/> . More information about the structure of this "
172 "file can be found in the Debian Policy section titled "
173 "<filename>debian/changelog</filename>."
176 # type: Content of: <chapter><section><para>
179 "Changelog entries can be used to automatically close Debian bugs when the "
180 "package is installed into the archive. See <xref "
181 "linkend=\"upload-bugfix\"/> ."
184 # type: Content of: <chapter><section><para>
187 "It is conventional that the changelog entry of a package that contains a new "
188 "upstream version of the software looks like this:"
191 # type: Content of: <chapter><section><screen>
196 " * new upstream version\n"
199 # type: Content of: <chapter><section><para>
202 "There are tools to help you create entries and finalize the "
203 "<filename>changelog</filename> for release — see <xref "
204 "linkend=\"devscripts\"/> and <xref linkend=\"dpkg-dev-el\"/> ."
207 # type: Content of: <chapter><section><para>
209 msgid "See also <xref linkend=\"bpp-debian-changelog\"/> ."
212 # type: Content of: <chapter><section><title>
214 msgid "Testing the package"
217 # type: Content of: <chapter><section><para>
220 "Before you upload your package, you should do basic testing on it. At a "
221 "minimum, you should try the following activities (you'll need to have an "
222 "older version of the same Debian package around):"
225 # type: Content of: <chapter><section><itemizedlist><listitem><para>
228 "Install the package and make sure the software works, or upgrade the package "
229 "from an older version to your new version if a Debian package for it already "
233 # type: Content of: <chapter><section><itemizedlist><listitem><para>
236 "Run <command>lintian</command> over the package. You can run "
237 "<command>lintian</command> as follows: <literal>lintian -v "
238 "<replaceable>package-version</replaceable>.changes</literal>. This will "
239 "check the source package as well as the binary package. If you don't "
240 "understand the output that <command>lintian</command> generates, try adding "
241 "the <literal>-i</literal> switch, which will cause "
242 "<command>lintian</command> to output a very verbose description of the "
246 # type: Content of: <chapter><section><itemizedlist><listitem><para>
249 "Normally, a package should <emphasis>not</emphasis> be uploaded if it causes "
250 "lintian to emit errors (they will start with <literal>E</literal>)."
253 # type: Content of: <chapter><section><itemizedlist><listitem><para>
256 "For more information on <command>lintian</command>, see <xref "
257 "linkend=\"lintian\"/> ."
260 # type: Content of: <chapter><section><itemizedlist><listitem><para>
263 "Optionally run <xref linkend=\"debdiff\"/> to analyze changes from an older "
264 "version, if one exists."
267 # type: Content of: <chapter><section><itemizedlist><listitem><para>
270 "Downgrade the package to the previous version (if one exists) — this tests "
271 "the <filename>postrm</filename> and <filename>prerm</filename> scripts."
274 # type: Content of: <chapter><section><itemizedlist><listitem><para>
276 msgid "Remove the package, then reinstall it."
279 # type: Content of: <chapter><section><itemizedlist><listitem><para>
282 "Copy the source package in a different directory and try unpacking it and "
283 "rebuilding it. This tests if the package relies on existing files outside "
284 "of it, or if it relies on permissions being preserved on the files shipped "
285 "inside the .diff.gz file."
288 # type: Content of: <chapter><section><title>
290 msgid "Layout of the source package"
293 # type: Content of: <chapter><section><para>
295 msgid "There are two types of Debian source packages:"
298 # type: Content of: <chapter><section><itemizedlist><listitem><para>
301 "the so-called <literal>native</literal> packages, where there is no "
302 "distinction between the original sources and the patches applied for Debian"
305 # type: Content of: <chapter><section><itemizedlist><listitem><para>
308 "the (more common) packages where there's an original source tarball file "
309 "accompanied by another file that contains the patches applied for Debian"
312 # type: Content of: <chapter><section><para>
315 "For the native packages, the source package includes a Debian source control "
316 "file (<literal>.dsc</literal>) and the source tarball "
317 "(<literal>.tar.gz</literal>). A source package of a non-native package "
318 "includes a Debian source control file, the original source tarball "
319 "(<literal>.orig.tar.gz</literal>) and the Debian patches "
320 "(<literal>.diff.gz</literal>)."
323 # type: Content of: <chapter><section><para>
326 "Whether a package is native or not is determined when it is built by "
327 "<citerefentry> <refentrytitle>dpkg-buildpackage</refentrytitle> "
328 "<manvolnum>1</manvolnum> </citerefentry>. The rest of this section relates "
329 "only to non-native packages."
332 # type: Content of: <chapter><section><para>
335 "The first time a version is uploaded which corresponds to a particular "
336 "upstream version, the original source tar file should be uploaded and "
337 "included in the <filename>.changes</filename> file. Subsequently, this very "
338 "same tar file should be used to build the new diffs and "
339 "<filename>.dsc</filename> files, and will not need to be re-uploaded."
342 # type: Content of: <chapter><section><para>
345 "By default, <command>dpkg-genchanges</command> and "
346 "<command>dpkg-buildpackage</command> will include the original source tar "
347 "file if and only if the Debian revision part of the source version number is "
348 "0 or 1, indicating a new upstream version. This behavior may be modified by "
349 "using <literal>-sa</literal> to always include it or <literal>-sd</literal> "
350 "to always leave it out."
353 # type: Content of: <chapter><section><para>
356 "If no original source is included in the upload, the original source "
357 "tar-file used by <command>dpkg-source</command> when constructing the "
358 "<filename>.dsc</filename> file and diff to be uploaded "
359 "<emphasis>must</emphasis> be byte-for-byte identical with the one already in "
363 # type: Content of: <chapter><section><para>
366 "Please notice that, in non-native packages, permissions on files that are "
367 "not present in the .orig.tar.gz will not be preserved, as diff does not "
368 "store file permissions in the patch."
371 # type: Content of: <chapter><section><title>
373 msgid "Picking a distribution"
376 # type: Content of: <chapter><section><para>
379 "Each upload needs to specify which distribution the package is intended "
380 "for. The package build process extracts this information from the first "
381 "line of the <filename>debian/changelog</filename> file and places it in the "
382 "<literal>Distribution</literal> field of the <literal>.changes</literal> "
386 # type: Content of: <chapter><section><para>
389 "There are several possible values for this field: <literal>stable</literal>, "
390 "<literal>unstable</literal>, <literal>testing-proposed-updates</literal> and "
391 "<literal>experimental</literal>. Normally, packages are uploaded into "
392 "<literal>unstable</literal>."
395 # type: Content of: <chapter><section><para>
398 "Actually, there are two other possible distributions: "
399 "<literal>stable-security </literal> and <literal>testing-security</literal>, "
400 "but read <xref linkend=\"bug-security\"/> for more information on those."
403 # type: Content of: <chapter><section><para>
406 "It is not possible to upload a package into several distributions at the "
410 # type: Content of: <chapter><section><section><title>
413 "Special case: uploads to the <literal>stable</literal> and "
414 "<literal>oldstable</literal> distributions"
417 # type: Content of: <chapter><section><section><para>
420 "Uploading to <literal>stable</literal> means that the package will "
421 "transfered to the <literal>proposed-updates-new</literal> queue for review "
422 "by the stable release managers, and if approved will be installed in "
423 "<filename>stable-proposed-updates</filename> directory of the Debian "
424 "archive. From there, it will be included in <literal>stable</literal> with "
425 "the next point release."
428 # type: Content of: <chapter><section><section><para>
431 "To ensure that your upload will be accepted, you should discuss the changes "
432 "with the stable release team before you upload. For that, send a mail to the "
433 "&email-debian-release; mailing list, including the patch you want to apply "
434 "to the package version currently in <literal>stable</literal>. Always be "
435 "verbose and detailed in your changelog entries for uploads to the "
436 "<literal>stable</literal> distribution."
439 # type: Content of: <chapter><section><section><para>
442 "Extra care should be taken when uploading to <literal>stable</literal>. "
443 "Basically, a package should only be uploaded to <literal>stable</literal> if "
444 "one of the following happens:"
447 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
449 msgid "a truly critical functionality problem"
452 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
454 msgid "the package becomes uninstallable"
457 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
459 msgid "a released architecture lacks the package"
462 # type: Content of: <chapter><section><section><para>
465 "In the past, uploads to <literal>stable</literal> were used to address "
466 "security problems as well. However, this practice is deprecated, as uploads "
467 "used for Debian security advisories are automatically copied to the "
468 "appropriate <filename>proposed-updates</filename> archive when the advisory "
469 "is released. See <xref linkend=\"bug-security\"/> for detailed information "
470 "on handling security problems. If the security teams deems the problem to be "
471 "too benign to be fixed through a <literal>DSA</literal>, the stable release "
472 "managers are usually willing to include your fix nonetheless in a regular "
473 "upload to <literal>stable</literal>."
476 # type: Content of: <chapter><section><section><para>
479 "Changing anything else in the package that isn't important is discouraged, "
480 "because even trivial fixes can cause bugs later on."
483 # type: Content of: <chapter><section><section><para>
486 "Packages uploaded to <literal>stable</literal> need to be compiled on "
487 "systems running <literal>stable</literal>, so that their dependencies are "
488 "limited to the libraries (and other packages) available in "
489 "<literal>stable</literal>; for example, a package uploaded to "
490 "<literal>stable</literal> that depends on a library package that only exists "
491 "in <literal>unstable</literal> will be rejected. Making changes to "
492 "dependencies of other packages (by messing with <literal>Provides</literal> "
493 "or <literal>shlibs</literal> files), possibly making those other packages "
494 "uninstallable, is strongly discouraged."
497 # type: Content of: <chapter><section><section><para>
500 "Uploads to the <literal>oldstable</literal> distributions are possible as "
501 "long as it hasn't been archived. The same rules as for <literal>stable "
505 # type: Content of: <chapter><section><section><title>
507 msgid "Special case: uploads to <literal>testing/testing-proposed-updates</literal>"
510 # type: Content of: <chapter><section><section><para>
513 "Please see the information in the <link linkend=\"t-p-u\">testing "
514 "section</link> for details."
517 # type: Content of: <chapter><section><title>
519 msgid "Uploading a package"
522 # type: Content of: <chapter><section><section><title>
524 msgid "Uploading to <literal>ftp-master</literal>"
527 # type: Content of: <chapter><section><section><para>
530 "To upload a package, you should upload the files (including the signed "
531 "changes and dsc-file) with anonymous ftp to "
532 "<literal>&ftp-master-host;</literal> in the directory <ulink "
533 "url=\"ftp://&ftp-master-host;&upload-queue;\">&upload-queue;</ulink>. To "
534 "get the files processed there, they need to be signed with a key in the "
535 "Debian Developers keyring or the Debian Maintainers keyring (see <ulink "
536 "url=\"&url-wiki-dm;\"></ulink>)."
539 # type: Content of: <chapter><section><section><para>
542 "Please note that you should transfer the changes file last. Otherwise, your "
543 "upload may be rejected because the archive maintenance software will parse "
544 "the changes file and see that not all files have been uploaded."
547 # type: Content of: <chapter><section><section><para>
550 "You may also find the Debian packages <xref linkend=\"dupload\"/> or <xref "
551 "linkend=\"dput\"/> useful when uploading packages. These handy programs "
552 "help automate the process of uploading packages into Debian."
555 # type: Content of: <chapter><section><section><para>
558 "For removing packages, please see the README file in that ftp directory, and "
559 "the Debian package <xref linkend=\"dcut\"/> ."
562 # type: Content of: <chapter><section><section><title>
564 msgid "Delayed uploads"
567 # type: Content of: <chapter><section><section><para>
570 "Delayed uploads are done for the moment via the delayed queue at "
571 "<literal>gluck </literal>. The upload-directory is "
572 "<literal>gluck:~tfheen/DELAYED/[012345678]-day</literal>. 0-day is uploaded "
573 "multiple times per day to <literal>&ftp-master-host;</literal>."
576 # type: Content of: <chapter><section><section><para>
578 msgid "With a fairly recent dput, this section"
581 # type: Content of: <chapter><section><section><screen>
588 "fqdn = gluck.debian.org\n"
589 "incoming = ~tfheen\n"
592 # type: Content of: <chapter><section><section><para>
595 "in <filename>~/.dput.cf</filename> should work fine for uploading to the "
596 "<literal>DELAYED</literal> queue."
599 # type: Content of: <chapter><section><section><para>
602 "<emphasis>Note:</emphasis> Since this upload queue goes to "
603 "<literal>&ftp-master-host;</literal>, the prescription found in <xref "
604 "linkend=\"upload-ftp-master\"/> applies here as well."
607 # type: Content of: <chapter><section><section><title>
609 msgid "Security uploads"
612 # type: Content of: <chapter><section><section><para>
615 "Do <emphasis role=\"strong\">NOT</emphasis> upload a package to the security "
616 "upload queue (<literal>oldstable-security</literal>, "
617 "<literal>stable-security </literal>, etc.) without prior authorization from "
618 "the security team. If the package does not exactly meet the team's "
619 "requirements, it will cause many problems and delays in dealing with the "
620 "unwanted upload. For details, please see section <xref "
621 "linkend=\"bug-security\"/> ."
624 # type: Content of: <chapter><section><section><title>
626 msgid "Other upload queues"
629 # type: Content of: <chapter><section><section><para>
632 "The scp queues on <literal>&ftp-master-host;</literal>, and <literal> "
633 "security.debian.org</literal> are mostly unusable due to the login "
634 "restrictions on those hosts."
637 # type: Content of: <chapter><section><section><para>
640 "The anonymous queues on ftp.uni-erlangen.de and ftp.uk.debian.org are "
641 "currently down. Work is underway to resurrect them."
644 # type: Content of: <chapter><section><section><para>
647 "The queues on master.debian.org, samosa.debian.org, master.debian.or.jp, and "
648 "ftp.chiark.greenend.org.uk are down permanently, and will not be "
649 "resurrected. The queue in Japan will be replaced with a new queue on "
650 "hp.debian.or.jp some day."
653 # type: Content of: <chapter><section><section><title>
655 msgid "Notification that a new package has been installed"
658 # type: Content of: <chapter><section><section><para>
661 "The Debian archive maintainers are responsible for handling package "
662 "uploads. For the most part, uploads are automatically handled on a daily "
663 "basis by the archive maintenance tools, <command>katie</command>. "
664 "Specifically, updates to existing packages to the "
665 "<literal>unstable</literal> distribution are handled automatically. In "
666 "other cases, notably new packages, placing the uploaded package into the "
667 "distribution is handled manually. When uploads are handled manually, the "
668 "change to the archive may take up to a month to occur. Please be patient."
671 # type: Content of: <chapter><section><section><para>
674 "In any case, you will receive an email notification indicating that the "
675 "package has been added to the archive, which also indicates which bugs will "
676 "be closed by the upload. Please examine this notification carefully, "
677 "checking if any bugs you meant to close didn't get triggered."
680 # type: Content of: <chapter><section><section><para>
683 "The installation notification also includes information on what section the "
684 "package was inserted into. If there is a disparity, you will receive a "
685 "separate email notifying you of that. Read on below."
688 # type: Content of: <chapter><section><section><para>
691 "Note that if you upload via queues, the queue daemon software will also send "
692 "you a notification by email."
695 # type: Content of: <chapter><section><title>
697 msgid "Specifying the package section, subsection and priority"
700 # type: Content of: <chapter><section><para>
703 "The <filename>debian/control</filename> file's <literal>Section</literal> "
704 "and <literal>Priority</literal> fields do not actually specify where the "
705 "file will be placed in the archive, nor its priority. In order to retain "
706 "the overall integrity of the archive, it is the archive maintainers who have "
707 "control over these fields. The values in the "
708 "<filename>debian/control</filename> file are actually just hints."
711 # type: Content of: <chapter><section><para>
714 "The archive maintainers keep track of the canonical sections and priorities "
715 "for packages in the <literal>override file</literal>. If there is a "
716 "disparity between the <literal>override file</literal> and the package's "
717 "fields as indicated in <filename>debian/control</filename>, then you will "
718 "receive an email noting the divergence when the package is installed into "
719 "the archive. You can either correct your "
720 "<filename>debian/control</filename> file for your next upload, or else you "
721 "may wish to make a change in the <literal>override file</literal>."
724 # type: Content of: <chapter><section><para>
727 "To alter the actual section that a package is put in, you need to first make "
728 "sure that the <filename>debian/control</filename> file in your package is "
729 "accurate. Next, send an email &email-override; or submit a bug against "
730 "<systemitem role=\"package\">ftp.debian.org</systemitem> requesting that the "
731 "section or priority for your package be changed from the old section or "
732 "priority to the new one. Be sure to explain your reasoning."
735 # type: Content of: <chapter><section><para>
738 "For more information about <literal>override files</literal>, see "
739 "<citerefentry> <refentrytitle>dpkg-scanpackages</refentrytitle> "
740 "<manvolnum>1</manvolnum> </citerefentry> and <ulink "
741 "url=\"&url-bts-devel;#maintincorrect\"></ulink>."
744 # type: Content of: <chapter><section><para>
747 "Note that the <literal>Section</literal> field describes both the section as "
748 "well as the subsection, which are described in <xref "
749 "linkend=\"archive-sections\"/> . If the section is main, it should be "
750 "omitted. The list of allowable subsections can be found in <ulink "
751 "url=\"&url-debian-policy;ch-archive.html#s-subsections\"></ulink>."
754 # type: Content of: <chapter><section><title>
756 msgid "Handling bugs"
759 # type: Content of: <chapter><section><para>
762 "Every developer has to be able to work with the Debian <ulink "
763 "url=\"&url-bts;\">bug tracking system</ulink>. This includes knowing how to "
764 "file bug reports properly (see <xref linkend=\"submit-bug\"/> ), how to "
765 "update them and reorder them, and how to process and close them."
768 # type: Content of: <chapter><section><para>
771 "The bug tracking system's features are described in the <ulink "
772 "url=\"&url-bts-devel;\">BTS documentation for developers</ulink>. This "
773 "includes closing bugs, sending followup messages, assigning severities and "
774 "tags, marking bugs as forwarded, and other issues."
777 # type: Content of: <chapter><section><para>
780 "Operations such as reassigning bugs to other packages, merging separate bug "
781 "reports about the same issue, or reopening bugs when they are prematurely "
782 "closed, are handled using the so-called control mail server. All of the "
783 "commands available on this server are described in the <ulink "
784 "url=\"&url-bts-control;\">BTS control server documentation</ulink>."
787 # type: Content of: <chapter><section><section><title>
789 msgid "Monitoring bugs"
792 # type: Content of: <chapter><section><section><para>
795 "If you want to be a good maintainer, you should periodically check the "
796 "<ulink url=\"&url-bts;\">Debian bug tracking system (BTS)</ulink> for your "
797 "packages. The BTS contains all the open bugs against your packages. You "
798 "can check them by browsing this page: "
799 "<literal>http://&bugs-host;/<replaceable>yourlogin</replaceable>@debian.org</literal>."
802 # type: Content of: <chapter><section><section><para>
805 "Maintainers interact with the BTS via email addresses at "
806 "<literal>&bugs-host;</literal>. Documentation on available commands can be "
807 "found at <ulink url=\"&url-bts;\"></ulink>, or, if you have installed the "
808 "<systemitem role=\"package\">doc-debian</systemitem> package, you can look "
809 "at the local files &file-bts-docs;."
812 # type: Content of: <chapter><section><section><para>
815 "Some find it useful to get periodic reports on open bugs. You can add a "
816 "cron job such as the following if you want to get a weekly email outlining "
817 "all the open bugs against your packages:"
820 # type: Content of: <chapter><section><section><screen>
825 "# ask for weekly reports of bugs in my packages\n"
826 "&cron-bug-report;\n"
829 # type: Content of: <chapter><section><section><para>
832 "Replace <replaceable>address</replaceable> with your official Debian "
833 "maintainer address."
836 # type: Content of: <chapter><section><section><title>
838 msgid "Responding to bugs"
841 # type: Content of: <chapter><section><section><para>
844 "When responding to bugs, make sure that any discussion you have about bugs "
845 "is sent both to the original submitter of the bug, and to the bug itself "
846 "(e.g., <email>123@&bugs-host;</email>). If you're writing a new mail and "
847 "you don't remember the submitter email address, you can use the "
848 "<email>123-submitter@&bugs-host;</email> email to contact the submitter "
849 "<emphasis>and</emphasis> to record your mail within the bug log (that means "
850 "you don't need to send a copy of the mail to "
851 "<email>123@&bugs-host;</email>)."
854 # type: Content of: <chapter><section><section><para>
857 "If you get a bug which mentions FTBFS, this means Fails to build from "
858 "source. Porters frequently use this acronym."
861 # type: Content of: <chapter><section><section><para>
864 "Once you've dealt with a bug report (e.g. fixed it), mark it as "
865 "<literal>done</literal> (close it) by sending an explanation message to "
866 "<email>123-done@&bugs-host;</email>. If you're fixing a bug by changing and "
867 "uploading the package, you can automate bug closing as described in <xref "
868 "linkend=\"upload-bugfix\"/> ."
871 # type: Content of: <chapter><section><section><para>
874 "You should <emphasis>never</emphasis> close bugs via the bug server "
875 "<literal>close</literal> command sent to &email-bts-control;. If you do so, "
876 "the original submitter will not receive any information about why the bug "
880 # type: Content of: <chapter><section><section><title>
882 msgid "Bug housekeeping"
885 # type: Content of: <chapter><section><section><para>
888 "As a package maintainer, you will often find bugs in other packages or have "
889 "bugs reported against your packages which are actually bugs in other "
890 "packages. The bug tracking system's features are described in the <ulink "
891 "url=\"&url-bts-devel;\">BTS documentation for Debian developers</ulink>. "
892 "Operations such as reassigning, merging, and tagging bug reports are "
893 "described in the <ulink url=\"&url-bts-control;\">BTS control server "
894 "documentation</ulink>. This section contains some guidelines for managing "
895 "your own bugs, based on the collective Debian developer experience."
898 # type: Content of: <chapter><section><section><para>
901 "Filing bugs for problems that you find in other packages is one of the civic "
902 "obligations of maintainership, see <xref linkend=\"submit-bug\"/> for "
903 "details. However, handling the bugs in your own packages is even more "
907 # type: Content of: <chapter><section><section><para>
909 msgid "Here's a list of steps that you may follow to handle a bug report:"
912 # type: Content of: <chapter><section><section><orderedlist><listitem><para>
915 "Decide whether the report corresponds to a real bug or not. Sometimes users "
916 "are just calling a program in the wrong way because they haven't read the "
917 "documentation. If you diagnose this, just close the bug with enough "
918 "information to let the user correct their problem (give pointers to the good "
919 "documentation and so on). If the same report comes up again and again you "
920 "may ask yourself if the documentation is good enough or if the program "
921 "shouldn't detect its misuse in order to give an informative error message. "
922 "This is an issue that may need to be brought up with the upstream author."
925 # type: Content of: <chapter><section><section><orderedlist><listitem><para>
928 "If the bug submitter disagrees with your decision to close the bug, they may "
929 "reopen it until you find an agreement on how to handle it. If you don't "
930 "find any, you may want to tag the bug <literal>wontfix</literal> to let "
931 "people know that the bug exists but that it won't be corrected. If this "
932 "situation is unacceptable, you (or the submitter) may want to require a "
933 "decision of the technical committee by reassigning the bug to <systemitem "
934 "role=\"package\">tech-ctte</systemitem> (you may use the clone command of "
935 "the BTS if you wish to keep it reported against your package). Before doing "
936 "so, please read the <ulink url=\"&url-tech-ctte;\">recommended "
940 # type: Content of: <chapter><section><section><orderedlist><listitem><para>
943 "If the bug is real but it's caused by another package, just reassign the bug "
944 "to the right package. If you don't know which package it should be "
945 "reassigned to, you should ask for help on <link "
946 "linkend=\"irc-channels\">IRC</link> or on &email-debian-devel;. Please "
947 "inform the maintainer(s) of the package you reassign the bug to, for example "
948 "by Cc:ing the message that does the reassign to "
949 "<email>packagename@packages.debian.org</email> and explaining your reasons "
950 "in that mail. Please note that a simple reassignment is "
951 "<emphasis>not</emphasis> e-mailed to the maintainers of the package being "
952 "reassigned to, so they won't know about it until they look at a bug overview "
953 "for their packages."
956 # type: Content of: <chapter><section><section><orderedlist><listitem><para>
959 "If the bug affects the operation of your package, please consider cloning "
960 "the bug and reassigning the clone to the package that really causes the "
961 "behavior. Otherwise, the bug will not be shown in your package's bug list, "
962 "possibly causing users to report the same bug over and over again. You "
963 "should block \"your\" bug with the reassigned, cloned bug to document the "
967 # type: Content of: <chapter><section><section><orderedlist><listitem><para>
970 "Sometimes you also have to adjust the severity of the bug so that it matches "
971 "our definition of the severity. That's because people tend to inflate the "
972 "severity of bugs to make sure their bugs are fixed quickly. Some bugs may "
973 "even be dropped to wishlist severity when the requested change is just "
977 # type: Content of: <chapter><section><section><orderedlist><listitem><para>
980 "If the bug is real but the same problem has already been reported by someone "
981 "else, then the two relevant bug reports should be merged into one using the "
982 "merge command of the BTS. In this way, when the bug is fixed, all of the "
983 "submitters will be informed of this. (Note, however, that emails sent to "
984 "one bug report's submitter won't automatically be sent to the other report's "
985 "submitter.) For more details on the technicalities of the merge command and "
986 "its relative, the unmerge command, see the BTS control server documentation."
989 # type: Content of: <chapter><section><section><orderedlist><listitem><para>
992 "The bug submitter may have forgotten to provide some information, in which "
993 "case you have to ask them for the required information. You may use the "
994 "<literal>moreinfo</literal> tag to mark the bug as such. Moreover if you "
995 "can't reproduce the bug, you tag it <literal>unreproducible</literal>. "
996 "Anyone who can reproduce the bug is then invited to provide more information "
997 "on how to reproduce it. After a few months, if this information has not "
998 "been sent by someone, the bug may be closed."
1001 # type: Content of: <chapter><section><section><orderedlist><listitem><para>
1004 "If the bug is related to the packaging, you just fix it. If you are not "
1005 "able to fix it yourself, then tag the bug as <literal>help</literal>. You "
1006 "can also ask for help on &email-debian-devel; or &email-debian-qa;. If it's "
1007 "an upstream problem, you have to forward it to the upstream author. "
1008 "Forwarding a bug is not enough, you have to check at each release if the bug "
1009 "has been fixed or not. If it has, you just close it, otherwise you have to "
1010 "remind the author about it. If you have the required skills you can prepare "
1011 "a patch that fixes the bug and send it to the author at the same time. Make "
1012 "sure to send the patch to the BTS and to tag the bug as "
1013 "<literal>patch</literal>."
1016 # type: Content of: <chapter><section><section><orderedlist><listitem><para>
1019 "If you have fixed a bug in your local copy, or if a fix has been committed "
1020 "to the CVS repository, you may tag the bug as <literal>pending</literal> to "
1021 "let people know that the bug is corrected and that it will be closed with "
1022 "the next upload (add the <literal>closes:</literal> in the "
1023 "<filename>changelog</filename>). This is particularly useful if you are "
1024 "several developers working on the same package."
1027 # type: Content of: <chapter><section><section><orderedlist><listitem><para>
1030 "Once a corrected package is available in the archive, the bug should be "
1031 "closed indicating the version in which it was fixed. This can be done "
1032 "automatically, read <xref linkend=\"upload-bugfix\"/>."
1035 # type: Content of: <chapter><section><section><title>
1037 msgid "When bugs are closed by new uploads"
1040 # type: Content of: <chapter><section><section><para>
1043 "As bugs and problems are fixed in your packages, it is your responsibility "
1044 "as the package maintainer to close these bugs. However, you should not "
1045 "close a bug until the package which fixes the bug has been accepted into the "
1046 "Debian archive. Therefore, once you get notification that your updated "
1047 "package has been installed into the archive, you can and should close the "
1048 "bug in the BTS. Also, the bug should be closed with the correct version."
1051 # type: Content of: <chapter><section><section><para>
1054 "However, it's possible to avoid having to manually close bugs after the "
1055 "upload — just list the fixed bugs in your "
1056 "<filename>debian/changelog</filename> file, following a certain syntax, and "
1057 "the archive maintenance software will close the bugs for you. For example:"
1060 # type: Content of: <chapter><section><section><screen>
1065 "acme-cannon (3.1415) unstable; urgency=low\n"
1067 " * Frobbed with options (closes: Bug#98339)\n"
1068 " * Added safety to prevent operator dismemberment, closes: bug#98765,\n"
1069 " bug#98713, #98714.\n"
1070 " * Added man page. Closes: #98725.\n"
1073 # type: Content of: <chapter><section><section><para>
1076 "Technically speaking, the following Perl regular expression describes how "
1077 "bug closing changelogs are identified:"
1080 # type: Content of: <chapter><section><section><screen>
1085 " /closes:\\s*(?:bug)?\\#\\s*\\d+(?:,\\s*(?:bug)?\\#\\s*\\d+)*/ig\n"
1088 # type: Content of: <chapter><section><section><para>
1091 "We prefer the <literal>closes: #<replaceable>XXX</replaceable></literal> "
1092 "syntax, as it is the most concise entry and the easiest to integrate with "
1093 "the text of the <filename>changelog</filename>. Unless specified different "
1094 "by the <replaceable>-v</replaceable>-switch to "
1095 "<command>dpkg-buildpackage</command>, only the bugs closed in the most "
1096 "recent changelog entry are closed (basically, exactly the bugs mentioned in "
1097 "the changelog-part in the <filename>.changes</filename> file are closed)."
1100 # type: Content of: <chapter><section><section><para>
1103 "Historically, uploads identified as <link linkend=\"nmu\">Non-maintainer "
1104 "upload (NMU)</link> were tagged <literal>fixed</literal> instead of being "
1105 "closed, but that practice was ceased with the advent of version-tracking. "
1106 "The same applied to the tag <literal>fixed-in-experimental</literal>."
1109 # type: Content of: <chapter><section><section><para>
1112 "If you happen to mistype a bug number or forget a bug in the changelog "
1113 "entries, don't hesitate to undo any damage the error caused. To reopen "
1114 "wrongly closed bugs, send a <literal>reopen "
1115 "<replaceable>XXX</replaceable></literal> command to the bug tracking "
1116 "system's control address, &email-bts-control;. To close any remaining bugs "
1117 "that were fixed by your upload, email the <filename>.changes</filename> file "
1118 "to <email>XXX-done@&bugs-host;</email>, where <replaceable>XXX</replaceable> "
1119 "is the bug number, and put Version: YYY and an empty line as the first two "
1120 "lines of the body of the email, where <replaceable>YYY</replaceable> is the "
1121 "first version where the bug has been fixed."
1124 # type: Content of: <chapter><section><section><para>
1127 "Bear in mind that it is not obligatory to close bugs using the changelog as "
1128 "described above. If you simply want to close bugs that don't have anything "
1129 "to do with an upload you made, do it by emailing an explanation to "
1130 "<email>XXX-done@&bugs-host;</email>. Do <emphasis "
1131 "role=\"strong\">not</emphasis> close bugs in the changelog entry of a "
1132 "version if the changes in that version of the package don't have any bearing "
1136 # type: Content of: <chapter><section><section><para>
1139 "For general information on how to write your changelog entries, see <xref "
1140 "linkend=\"bpp-debian-changelog\"/> ."
1143 # type: Content of: <chapter><section><section><title>
1145 msgid "Handling security-related bugs"
1148 # type: Content of: <chapter><section><section><para>
1151 "Due to their sensitive nature, security-related bugs must be handled "
1152 "carefully. The Debian Security Team exists to coordinate this activity, "
1153 "keeping track of outstanding security problems, helping maintainers with "
1154 "security problems or fixing them themselves, sending security advisories, "
1155 "and maintaining <literal>security.debian.org</literal>."
1158 # type: Content of: <chapter><section><section><para>
1161 "When you become aware of a security-related bug in a Debian package, whether "
1162 "or not you are the maintainer, collect pertinent information about the "
1163 "problem, and promptly contact the security team at &email-security-team; as "
1164 "soon as possible. <emphasis role=\"strong\">DO NOT UPLOAD</emphasis> any "
1165 "packages for <literal>stable</literal>; the security team will do that. "
1166 "Useful information includes, for example:"
1169 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
1172 "Which versions of the package are known to be affected by the bug. Check "
1173 "each version that is present in a supported Debian release, as well as "
1174 "<literal>testing</literal> and <literal>unstable</literal>."
1177 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
1179 msgid "The nature of the fix, if any is available (patches are especially helpful)"
1182 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
1185 "Any fixed packages that you have prepared yourself (send only the "
1186 "<literal>.diff.gz</literal> and <literal>.dsc</literal> files and read <xref "
1187 "linkend=\"bug-security-building\"/> first)"
1190 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
1193 "Any assistance you can provide to help with testing (exploits, regression "
1197 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
1200 "Any information needed for the advisory (see <xref "
1201 "linkend=\"bug-security-advisories\"/> )"
1204 # type: Content of: <chapter><section><section><section><title>
1206 msgid "Confidentiality"
1209 # type: Content of: <chapter><section><section><section><para>
1212 "Unlike most other activities within Debian, information about security "
1213 "issues must sometimes be kept private for a time. This allows software "
1214 "distributors to coordinate their disclosure in order to minimize their "
1215 "users' exposure. Whether this is the case depends on the nature of the "
1216 "problem and corresponding fix, and whether it is already a matter of public "
1220 # type: Content of: <chapter><section><section><section><para>
1222 msgid "There are several ways developers can learn of a security problem:"
1225 # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
1227 msgid "they notice it on a public forum (mailing list, web site, etc.)"
1230 # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
1232 msgid "someone files a bug report"
1235 # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
1237 msgid "someone informs them via private email"
1240 # type: Content of: <chapter><section><section><section><para>
1243 "In the first two cases, the information is public and it is important to "
1244 "have a fix as soon as possible. In the last case, however, it might not be "
1245 "public information. In that case there are a few possible options for "
1246 "dealing with the problem:"
1249 # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
1252 "If the security exposure is minor, there is sometimes no need to keep the "
1253 "problem a secret and a fix should be made and released."
1256 # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
1259 "If the problem is severe, it is preferable to share the information with "
1260 "other vendors and coordinate a release. The security team keeps in contact "
1261 "with the various organizations and individuals and can take care of that."
1264 # type: Content of: <chapter><section><section><section><para>
1267 "In all cases if the person who reports the problem asks that it not be "
1268 "disclosed, such requests should be honored, with the obvious exception of "
1269 "informing the security team in order that a fix may be produced for a stable "
1270 "release of Debian. When sending confidential information to the security "
1271 "team, be sure to mention this fact."
1274 # type: Content of: <chapter><section><section><section><para>
1277 "Please note that if secrecy is needed you may not upload a fix to "
1278 "<literal>unstable</literal> (or anywhere else, such as a public CVS "
1279 "repository). It is not sufficient to obfuscate the details of the change, "
1280 "as the code itself is public, and can (and will) be examined by the general "
1284 # type: Content of: <chapter><section><section><section><para>
1287 "There are two reasons for releasing information even though secrecy is "
1288 "requested: the problem has been known for a while, or the problem or exploit "
1289 "has become public."
1292 # type: Content of: <chapter><section><section><section><title>
1294 msgid "Security Advisories"
1297 # type: Content of: <chapter><section><section><section><para>
1300 "Security advisories are only issued for the current, released stable "
1301 "distribution, and <emphasis>not</emphasis> for <literal>testing</literal> or "
1302 "<literal>unstable</literal>. When released, advisories are sent to the "
1303 "&email-debian-security-announce; mailing list and posted on <ulink "
1304 "url=\"&url-debian-security-advisories;\">the security web page</ulink>. "
1305 "Security advisories are written and posted by the security team. However "
1306 "they certainly do not mind if a maintainer can supply some of the "
1307 "information for them, or write part of the text. Information that should be "
1308 "in an advisory includes:"
1311 # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
1313 msgid "A description of the problem and its scope, including:"
1316 # type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para>
1318 msgid "The type of problem (privilege escalation, denial of service, etc.)"
1321 # type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para>
1323 msgid "What privileges may be gained, and by whom (if any)"
1326 # type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para>
1328 msgid "How it can be exploited"
1331 # type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para>
1333 msgid "Whether it is remotely or locally exploitable"
1336 # type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para>
1338 msgid "How the problem was fixed"
1341 # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
1343 msgid "This information allows users to assess the threat to their systems."
1346 # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
1348 msgid "Version numbers of affected packages"
1351 # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
1353 msgid "Version numbers of fixed packages"
1356 # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
1359 "Information on where to obtain the updated packages (usually from the Debian "
1363 # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
1366 "References to upstream advisories, <ulink "
1367 "url=\"http://cve.mitre.org\">CVE</ulink> identifiers, and any other "
1368 "information useful in cross-referencing the vulnerability"
1371 # type: Content of: <chapter><section><section><section><title>
1373 msgid "Preparing packages to address security issues"
1376 # type: Content of: <chapter><section><section><section><para>
1379 "One way that you can assist the security team in their duties is to provide "
1380 "them with fixed packages suitable for a security advisory for the stable "
1384 # type: Content of: <chapter><section><section><section><para>
1387 "When an update is made to the stable release, care must be taken to avoid "
1388 "changing system behavior or introducing new bugs. In order to do this, make "
1389 "as few changes as possible to fix the bug. Users and administrators rely on "
1390 "the exact behavior of a release once it is made, so any change that is made "
1391 "might break someone's system. This is especially true of libraries: make "
1392 "sure you never change the API or ABI, no matter how small the change."
1395 # type: Content of: <chapter><section><section><section><para>
1398 "This means that moving to a new upstream version is not a good solution. "
1399 "Instead, the relevant changes should be back-ported to the version present "
1400 "in the current stable Debian release. Generally, upstream maintainers are "
1401 "willing to help if needed. If not, the Debian security team may be able to "
1405 # type: Content of: <chapter><section><section><section><para>
1408 "In some cases, it is not possible to back-port a security fix, for example "
1409 "when large amounts of source code need to be modified or rewritten. If this "
1410 "happens, it may be necessary to move to a new upstream version. However, "
1411 "this is only done in extreme situations, and you must always coordinate that "
1412 "with the security team beforehand."
1415 # type: Content of: <chapter><section><section><section><para>
1418 "Related to this is another important guideline: always test your changes. "
1419 "If you have an exploit available, try it and see if it indeed succeeds on "
1420 "the unpatched package and fails on the fixed package. Test other, normal "
1421 "actions as well, as sometimes a security fix can break seemingly unrelated "
1422 "features in subtle ways."
1425 # type: Content of: <chapter><section><section><section><para>
1428 "Do <emphasis role=\"strong\">NOT</emphasis> include any changes in your "
1429 "package which are not directly related to fixing the vulnerability. These "
1430 "will only need to be reverted, and this wastes time. If there are other "
1431 "bugs in your package that you would like to fix, make an upload to "
1432 "proposed-updates in the usual way, after the security advisory is issued. "
1433 "The security update mechanism is not a means for introducing changes to your "
1434 "package which would otherwise be rejected from the stable release, so please "
1435 "do not attempt to do this."
1438 # type: Content of: <chapter><section><section><section><para>
1441 "Review and test your changes as much as possible. Check the differences "
1442 "from the previous version repeatedly (<command>interdiff</command> from the "
1443 "<systemitem role=\"package\">patchutils</systemitem> package and "
1444 "<command>debdiff</command> from <systemitem "
1445 "role=\"package\">devscripts</systemitem> are useful tools for this, see "
1446 "<xref linkend=\"debdiff\"/> )."
1449 # type: Content of: <chapter><section><section><section><para>
1451 msgid "Be sure to verify the following items:"
1454 # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
1457 "Target the right distribution in your "
1458 "<filename>debian/changelog</filename>. For <literal>stable</literal> this "
1459 "is <literal>stable-security</literal> and for testing this is "
1460 "<literal>testing-security</literal>, and for the previous stable release, "
1461 "this is <literal>oldstable-security</literal>. Do not target "
1462 "<replaceable>distribution</replaceable><literal>-proposed-updates</literal> "
1463 "or <literal>stable</literal>!"
1466 # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
1468 msgid "The upload should have urgency=high."
1471 # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
1474 "Make descriptive, meaningful changelog entries. Others will rely on them to "
1475 "determine whether a particular bug was fixed. Always include an external "
1476 "reference, preferably a CVE identifier, so that it can be cross-referenced. "
1477 "Include the same information in the changelog for "
1478 "<literal>unstable</literal>, so that it is clear that the same bug was "
1479 "fixed, as this is very helpful when verifying that the bug is fixed in the "
1480 "next stable release. If a CVE identifier has not yet been assigned, the "
1481 "security team will request one so that it can be included in the package and "
1485 # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
1488 "Make sure the version number is proper. It must be greater than the current "
1489 "package, but less than package versions in later distributions. If in "
1490 "doubt, test it with <literal>dpkg --compare-versions</literal>. Be careful "
1491 "not to re-use a version number that you have already used for a previous "
1492 "upload. For <literal>testing</literal>, there must be a higher version in "
1493 "<literal>unstable</literal>. If there is none yet (for example, if "
1494 "<literal>testing</literal> and <literal>unstable</literal> have the same "
1495 "version) you must upload a new version to <literal>unstable</literal> first."
1498 # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
1501 "Do not make source-only uploads if your package has any binary-all packages "
1502 "(do not use the <literal>-S</literal> option to "
1503 "<command>dpkg-buildpackage</command>). The <command>buildd</command> "
1504 "infrastructure will not build those. This point applies to normal package "
1508 # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
1511 "Unless the upstream source has been uploaded to <literal>security.debian.org "
1512 "</literal> before (by a previous security update), build the upload with "
1513 "full upstream source (<literal>dpkg-buildpackage -sa</literal>). If there "
1514 "has been a previous upload to <literal>security.debian.org</literal> with "
1515 "the same upstream version, you may upload without upstream source (<literal> "
1516 "dpkg-buildpackage -sd</literal>)."
1519 # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
1522 "Be sure to use the exact same <filename>*.orig.tar.gz</filename> as used in "
1523 "the normal archive, otherwise it is not possible to move the security fix "
1524 "into the main archives later."
1527 # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
1530 "Build the package on a clean system which only has packages installed from "
1531 "the distribution you are building for. If you do not have such a system "
1532 "yourself, you can use a debian.org machine (see <xref "
1533 "linkend=\"server-machines\"/> ) or setup a chroot (see <xref "
1534 "linkend=\"pbuilder\"/> and <xref linkend=\"debootstrap\"/> )."
1537 # type: Content of: <chapter><section><section><section><title>
1539 msgid "Uploading the fixed package"
1542 # type: Content of: <chapter><section><section><section><para>
1545 "Do <emphasis role=\"strong\">NOT</emphasis> upload a package to the security "
1546 "upload queue (<literal>oldstable-security</literal>, "
1547 "<literal>stable-security </literal>, etc.) without prior authorization from "
1548 "the security team. If the package does not exactly meet the team's "
1549 "requirements, it will cause many problems and delays in dealing with the "
1553 # type: Content of: <chapter><section><section><section><para>
1556 "Do <emphasis role=\"strong\">NOT</emphasis> upload your fix to <literal> "
1557 "proposed-updates</literal> without coordinating with the security team. "
1558 "Packages from <literal>security.debian.org</literal> will be copied into the "
1559 "<literal>proposed-updates</literal> directory automatically. If a package "
1560 "with the same or a higher version number is already installed into the "
1561 "archive, the security update will be rejected by the archive system. That "
1562 "way, the stable distribution will end up without a security update for this "
1566 # type: Content of: <chapter><section><section><section><para>
1569 "Once you have created and tested the new package and it has been approved by "
1570 "the security team, it needs to be uploaded so that it can be installed in "
1571 "the archives. For security uploads, the place to upload to is "
1572 "<literal>ftp://security-master.debian.org/pub/SecurityUploadQueue/</literal> "
1576 # type: Content of: <chapter><section><section><section><para>
1579 "Once an upload to the security queue has been accepted, the package will "
1580 "automatically be rebuilt for all architectures and stored for verification "
1581 "by the security team."
1584 # type: Content of: <chapter><section><section><section><para>
1587 "Uploads which are waiting for acceptance or verification are only accessible "
1588 "by the security team. This is necessary since there might be fixes for "
1589 "security problems that cannot be disclosed yet."
1592 # type: Content of: <chapter><section><section><section><para>
1595 "If a member of the security team accepts a package, it will be installed on "
1596 "<literal>security.debian.org</literal> as well as proposed for the proper "
1597 "<replaceable>distribution</replaceable><literal>-proposed-updates</literal> "
1598 "on <literal>&ftp-master-host;</literal>."
1601 # type: Content of: <chapter><section><title>
1603 msgid "Moving, removing, renaming, adopting, and orphaning packages"
1606 # type: Content of: <chapter><section><para>
1609 "Some archive manipulation operations are not automated in the Debian upload "
1610 "process. These procedures should be manually followed by maintainers. This "
1611 "chapter gives guidelines on what to do in these cases."
1614 # type: Content of: <chapter><section><section><title>
1616 msgid "Moving packages"
1619 # type: Content of: <chapter><section><section><para><footnote>
1622 "Sometimes a package will change its section. For instance, a package from "
1623 "the `non-free' section might be GPL'd in a later version, in which case the "
1624 "package should be moved to `main' or `contrib'.<footnote>"
1627 # type: Content of: <chapter><section><section><para><footnote><para>
1630 "See the <ulink url=\"&url-debian-policy;\">Debian Policy Manual</ulink> for "
1631 "guidelines on what section a package belongs in."
1634 # type: Content of: <chapter><section><section><section><para>
1635 #: pkgs.dbk:1216 pkgs.dbk:1648
1639 # type: Content of: <chapter><section><section><para>
1642 "If you need to change the section for one of your packages, change the "
1643 "package control information to place the package in the desired section, and "
1644 "re-upload the package (see the <ulink url=\"&url-debian-policy;\">Debian "
1645 "Policy Manual</ulink> for details). You must ensure that you include the "
1646 "<filename>.orig.tar.gz</filename> in your upload (even if you are not "
1647 "uploading a new upstream version), or it will not appear in the new section "
1648 "together with the rest of the package. If your new section is valid, it "
1649 "will be moved automatically. If it does not, then contact the ftpmasters in "
1650 "order to understand what happened."
1653 # type: Content of: <chapter><section><section><para>
1656 "If, on the other hand, you need to change the <literal>subsection</literal> "
1657 "of one of your packages (e.g., ``devel'', ``admin''), the procedure is "
1658 "slightly different. Correct the subsection as found in the control file of "
1659 "the package, and re-upload that. Also, you'll need to get the override file "
1660 "updated, as described in <xref linkend=\"override-file\"/> ."
1663 # type: Content of: <chapter><section><section><title>
1665 msgid "Removing packages"
1668 # type: Content of: <chapter><section><section><para>
1671 "If for some reason you want to completely remove a package (say, if it is an "
1672 "old compatibility library which is no longer required), you need to file a "
1673 "bug against <literal>ftp.debian.org</literal> asking that the package be "
1674 "removed; as all bugs, this bug should normally have normal severity. The "
1675 "bug title should be in the form <literal>RM: <replaceable>package "
1676 "</replaceable> <replaceable>[architecture list]</replaceable> -- "
1677 "<replaceable>reason</replaceable></literal>, where "
1678 "<replaceable>package</replaceable> is the package to be removed and "
1679 "<replaceable>reason</replaceable> is a short summary of the reason for the "
1680 "removal request. <replaceable>[architecture list]</replaceable> is optional "
1681 "and only needed if the removal request only applies to some architectures, "
1682 "not all. Note that the <command>reportbug</command> will create a title "
1683 "conforming to these rules when you use it to report a bug against the "
1684 "<literal> ftp.debian.org</literal> pseudo-package."
1687 # type: Content of: <chapter><section><section><para>
1690 "If you want to remove a package you maintain, you should note this in the "
1691 "bug title by prepending <literal>ROM</literal> (Request Of Maintainer). "
1692 "There are several other standard acronyms used in the reasoning for a "
1693 "package removal, see <ulink "
1694 "url=\"http://&ftp-master-host;/removals.html\"></ulink> for a complete "
1695 "list. That page also provides a convenient overview of pending removal "
1699 # type: Content of: <chapter><section><section><para>
1702 "Note that removals can only be done for the <literal>unstable </literal>, "
1703 "<literal>experimental</literal> and <literal>stable </literal> "
1704 "distribution. Packages are not removed from <literal>testing</literal> "
1705 "directly. Rather, they will be removed automatically after the package has "
1706 "been removed from <literal>unstable</literal> and no package in "
1707 "<literal>testing </literal> depends on it."
1710 # type: Content of: <chapter><section><section><para>
1713 "There is one exception when an explicit removal request is not necessary: If "
1714 "a (source or binary) package is an orphan, it will be removed "
1715 "semi-automatically. For a binary-package, this means if there is no longer "
1716 "any source package producing this binary package; if the binary package is "
1717 "just no longer produced on some architectures, a removal request is still "
1718 "necessary. For a source-package, this means that all binary packages it "
1719 "refers to have been taken over by another source package."
1722 # type: Content of: <chapter><section><section><para>
1725 "In your removal request, you have to detail the reasons justifying the "
1726 "request. This is to avoid unwanted removals and to keep a trace of why a "
1727 "package has been removed. For example, you can provide the name of the "
1728 "package that supersedes the one to be removed."
1731 # type: Content of: <chapter><section><section><para>
1734 "Usually you only ask for the removal of a package maintained by yourself. "
1735 "If you want to remove another package, you have to get the approval of its "
1736 "maintainer. Should the package be orphaned and thus have no maintainer, you "
1737 "should first discuss the removal request on &email-debian-qa;. If there is a "
1738 "consensus that the package should be removed, you should reassign and "
1739 "retitle the <literal>O:</literal> bug filed against the "
1740 "<literal>wnpp</literal> package instead of filing a new bug as removal "
1744 # type: Content of: <chapter><section><section><para>
1747 "Further information relating to these and other package removal related "
1748 "topics may be found at <ulink "
1749 "url=\"http://wiki.debian.org/ftpmaster_Removals\"></ulink> and <ulink "
1750 "url=\"&url-debian-qa;howto-remove.html\"></ulink>."
1753 # type: Content of: <chapter><section><section><para>
1756 "If in doubt concerning whether a package is disposable, email "
1757 "&email-debian-devel; asking for opinions. Also of interest is the "
1758 "<command>apt-cache</command> program from the <systemitem "
1759 "role=\"package\">apt</systemitem> package. When invoked as "
1760 "<literal>apt-cache showpkg <replaceable>package</replaceable></literal>, the "
1761 "program will show details for <replaceable>package</replaceable>, including "
1762 "reverse depends. Other useful programs include <literal>apt-cache "
1763 "rdepends</literal>, <command>apt-rdepends</command>, "
1764 "<command>build-rdeps</command> (in the <systemitem "
1765 "role=\"package\">devscripts</systemitem> package) and "
1766 "<command>grep-dctrl</command>. Removal of orphaned packages is discussed on "
1767 "&email-debian-qa;."
1770 # type: Content of: <chapter><section><section><para>
1773 "Once the package has been removed, the package's bugs should be handled. "
1774 "They should either be reassigned to another package in the case where the "
1775 "actual code has evolved into another package (e.g. "
1776 "<literal>libfoo12</literal> was removed because <literal>libfoo13</literal> "
1777 "supersedes it) or closed if the software is simply no longer part of Debian."
1780 # type: Content of: <chapter><section><section><section><title>
1782 msgid "Removing packages from <filename>Incoming</filename>"
1785 # type: Content of: <chapter><section><section><section><para>
1788 "In the past, it was possible to remove packages from "
1789 "<filename>incoming</filename>. However, with the introduction of the new "
1790 "incoming system, this is no longer possible. Instead, you have to upload a "
1791 "new revision of your package with a higher version than the package you want "
1792 "to replace. Both versions will be installed in the archive but only the "
1793 "higher version will actually be available in <literal>unstable</literal> "
1794 "since the previous version will immediately be replaced by the higher. "
1795 "However, if you do proper testing of your packages, the need to replace a "
1796 "package should not occur too often anyway."
1799 # type: Content of: <chapter><section><section><title>
1801 msgid "Replacing or renaming packages"
1804 # type: Content of: <chapter><section><section><para>
1807 "When the upstream maintainers for one of your packages chose to rename their "
1808 "software (or you made a mistake naming your package), you should follow a "
1809 "two-step process to rename it. In the first step, change the "
1810 "<filename>debian/control</filename> file to reflect the new name and to "
1811 "replace, provide and conflict with the obsolete package name (see the <ulink "
1812 "url=\"&url-debian-policy;\"> Debian Policy Manual</ulink> for details). "
1813 "Please note that you should only add a <literal>Provides</literal> relation "
1814 "if all packages depending on the obsolete package name continue to work "
1815 "after the renaming. Once you've uploaded the package and the package has "
1816 "moved into the archive, file a bug against <literal> "
1817 "ftp.debian.org</literal> asking to remove the package with the obsolete name "
1818 "(see <xref linkend=\"removing-pkgs\"/>). Do not forget to properly reassign "
1819 "the package's bugs at the same time."
1822 # type: Content of: <chapter><section><section><para>
1825 "At other times, you may make a mistake in constructing your package and wish "
1826 "to replace it. The only way to do this is to increase the version number "
1827 "and upload a new version. The old version will be expired in the usual "
1828 "manner. Note that this applies to each part of your package, including the "
1829 "sources: if you wish to replace the upstream source tarball of your package, "
1830 "you will need to upload it with a different version. An easy possibility is "
1831 "to replace <filename>foo_1.00.orig.tar.gz</filename> with "
1832 "<filename>foo_1.00+0.orig.tar.gz</filename>. This restriction gives each "
1833 "file on the ftp site a unique name, which helps to ensure consistency across "
1834 "the mirror network."
1837 # type: Content of: <chapter><section><section><title>
1839 msgid "Orphaning a package"
1842 # type: Content of: <chapter><section><section><para>
1845 "If you can no longer maintain a package, you need to inform others, and see "
1846 "that the package is marked as orphaned. You should set the package "
1847 "maintainer to <literal>Debian QA Group &orphan-address;</literal> and submit "
1848 "a bug report against the pseudo package <systemitem "
1849 "role=\"package\">wnpp</systemitem>. The bug report should be titled "
1850 "<literal>O: <replaceable>package</replaceable> -- <replaceable>short "
1851 "description</replaceable></literal> indicating that the package is now "
1852 "orphaned. The severity of the bug should be set to "
1853 "<literal>normal</literal>; if the package has a priority of standard or "
1854 "higher, it should be set to important. If you feel it's necessary, send a "
1855 "copy to &email-debian-devel; by putting the address in the X-Debbugs-CC: "
1856 "header of the message (no, don't use CC:, because that way the message's "
1857 "subject won't indicate the bug number)."
1860 # type: Content of: <chapter><section><section><para>
1863 "If you just intend to give the package away, but you can keep maintainership "
1864 "for the moment, then you should instead submit a bug against <systemitem "
1865 "role=\"package\">wnpp</systemitem> and title it <literal>RFA: "
1866 "<replaceable>package</replaceable> -- <replaceable>short "
1867 "description</replaceable></literal>. <literal>RFA</literal> stands for "
1868 "<literal>Request For Adoption</literal>."
1871 # type: Content of: <chapter><section><section><para>
1873 msgid "More information is on the <ulink url=\"&url-wnpp;\">WNPP web pages</ulink>."
1876 # type: Content of: <chapter><section><section><title>
1878 msgid "Adopting a package"
1881 # type: Content of: <chapter><section><section><para>
1884 "A list of packages in need of a new maintainer is available in the <ulink "
1885 "url=\"&url-wnpp;\">Work-Needing and Prospective Packages list "
1886 "(WNPP)</ulink>. If you wish to take over maintenance of any of the packages "
1887 "listed in the WNPP, please take a look at the aforementioned page for "
1888 "information and procedures."
1891 # type: Content of: <chapter><section><section><para>
1894 "It is not OK to simply take over a package that you feel is neglected — that "
1895 "would be package hijacking. You can, of course, contact the current "
1896 "maintainer and ask them if you may take over the package. If you have "
1897 "reason to believe a maintainer has gone AWOL (absent without leave), see "
1898 "<xref linkend=\"mia-qa\"/> ."
1901 # type: Content of: <chapter><section><section><para>
1904 "Generally, you may not take over the package without the assent of the "
1905 "current maintainer. Even if they ignore you, that is still not grounds to "
1906 "take over a package. Complaints about maintainers should be brought up on "
1907 "the developers' mailing list. If the discussion doesn't end with a positive "
1908 "conclusion, and the issue is of a technical nature, consider bringing it to "
1909 "the attention of the technical committee (see the <ulink "
1910 "url=\"&url-tech-ctte;\">technical committee web page</ulink> for more "
1914 # type: Content of: <chapter><section><section><para>
1917 "If you take over an old package, you probably want to be listed as the "
1918 "package's official maintainer in the bug system. This will happen "
1919 "automatically once you upload a new version with an updated "
1920 "<literal>Maintainer:</literal> field, although it can take a few hours after "
1921 "the upload is done. If you do not expect to upload a new version for a "
1922 "while, you can use <xref linkend=\"pkg-tracking-system\"/> to get the bug "
1923 "reports. However, make sure that the old maintainer has no problem with the "
1924 "fact that they will continue to receive the bugs during that time."
1927 # type: Content of: <chapter><section><title>
1929 msgid "Porting and being ported"
1932 # type: Content of: <chapter><section><para>
1935 "Debian supports an ever-increasing number of architectures. Even if you are "
1936 "not a porter, and you don't use any architecture but one, it is part of your "
1937 "duty as a maintainer to be aware of issues of portability. Therefore, even "
1938 "if you are not a porter, you should read most of this chapter."
1941 # type: Content of: <chapter><section><para>
1944 "Porting is the act of building Debian packages for architectures that are "
1945 "different from the original architecture of the package maintainer's binary "
1946 "package. It is a unique and essential activity. In fact, porters do most "
1947 "of the actual compiling of Debian packages. For instance, when a maintainer "
1948 "uploads a (portable) source packages with binaries for the <literal>i386 "
1949 "</literal> architecture, it will be built for each of the other "
1950 "architectures, amounting to &number-of-arches; more builds."
1953 # type: Content of: <chapter><section><section><title>
1955 msgid "Being kind to porters"
1958 # type: Content of: <chapter><section><section><para>
1961 "Porters have a difficult and unique task, since they are required to deal "
1962 "with a large volume of packages. Ideally, every source package should build "
1963 "right out of the box. Unfortunately, this is often not the case. This "
1964 "section contains a checklist of ``gotchas'' often committed by Debian "
1965 "maintainers — common problems which often stymie porters, and make their "
1966 "jobs unnecessarily difficult."
1969 # type: Content of: <chapter><section><section><para>
1972 "The first and most important thing is to respond quickly to bug or issues "
1973 "raised by porters. Please treat porters with courtesy, as if they were in "
1974 "fact co-maintainers of your package (which, in a way, they are). Please be "
1975 "tolerant of succinct or even unclear bug reports; do your best to hunt down "
1976 "whatever the problem is."
1979 # type: Content of: <chapter><section><section><para>
1982 "By far, most of the problems encountered by porters are caused by "
1983 "<emphasis>packaging bugs</emphasis> in the source packages. Here is a "
1984 "checklist of things you should check or be aware of."
1987 # type: Content of: <chapter><section><section><orderedlist><listitem><para>
1990 "Make sure that your <literal>Build-Depends</literal> and "
1991 "<literal>Build-Depends-Indep</literal> settings in "
1992 "<filename>debian/control</filename> are set properly. The best way to "
1993 "validate this is to use the <systemitem "
1994 "role=\"package\">debootstrap</systemitem> package to create an "
1995 "<literal>unstable</literal> chroot environment (see <xref "
1996 "linkend=\"debootstrap\"/> ). Within that chrooted environment, install the "
1997 "<systemitem role=\"package\">build-essential</systemitem> package and any "
1998 "package dependencies mentioned in <literal>Build-Depends</literal> and/or "
1999 "<literal>Build-Depends-Indep</literal>. Finally, try building your package "
2000 "within that chrooted environment. These steps can be automated by the use "
2001 "of the <command>pbuilder</command> program which is provided by the package "
2002 "of the same name (see <xref linkend=\"pbuilder\"/> )."
2005 # type: Content of: <chapter><section><section><orderedlist><listitem><para>
2008 "If you can't set up a proper chroot, <command>dpkg-depcheck</command> may be "
2009 "of assistance (see <xref linkend=\"dpkg-depcheck\"/> )."
2012 # type: Content of: <chapter><section><section><orderedlist><listitem><para>
2015 "See the <ulink url=\"&url-debian-policy;\">Debian Policy Manual</ulink> for "
2016 "instructions on setting build dependencies."
2019 # type: Content of: <chapter><section><section><orderedlist><listitem><para>
2022 "Don't set architecture to a value other than <literal>all</literal> or "
2023 "<literal>any</literal> unless you really mean it. In too many cases, "
2024 "maintainers don't follow the instructions in the <ulink "
2025 "url=\"&url-debian-policy;\">Debian Policy Manual</ulink>. Setting your "
2026 "architecture to only one architecture (such as <literal>i386</literal> or "
2027 "<literal>amd64</literal>) is usually incorrect."
2030 # type: Content of: <chapter><section><section><orderedlist><listitem><para>
2033 "Make sure your source package is correct. Do <literal>dpkg-source -x "
2034 "<replaceable>package</replaceable>.dsc</literal> to make sure your source "
2035 "package unpacks properly. Then, in there, try building your package from "
2036 "scratch with <command>dpkg-buildpackage</command>."
2039 # type: Content of: <chapter><section><section><orderedlist><listitem><para>
2042 "Make sure you don't ship your source package with the "
2043 "<filename>debian/files</filename> or <filename>debian/substvars</filename> "
2044 "files. They should be removed by the <literal>clean</literal> target of "
2045 "<filename>debian/rules</filename>."
2048 # type: Content of: <chapter><section><section><orderedlist><listitem><para>
2051 "Make sure you don't rely on locally installed or hacked configurations or "
2052 "programs. For instance, you should never be calling programs in "
2053 "<filename>/usr/local/bin</filename> or the like. Try not to rely on "
2054 "programs being setup in a special way. Try building your package on another "
2055 "machine, even if it's the same architecture."
2058 # type: Content of: <chapter><section><section><orderedlist><listitem><para>
2061 "Don't depend on the package you're building being installed already (a "
2062 "sub-case of the above issue). There are, of course, exceptions to this rule, "
2063 "but be aware that any case like this needs manual bootstrapping and cannot "
2064 "be done by automated package builders."
2067 # type: Content of: <chapter><section><section><orderedlist><listitem><para>
2070 "Don't rely on the compiler being a certain version, if possible. If not, "
2071 "then make sure your build dependencies reflect the restrictions, although "
2072 "you are probably asking for trouble, since different architectures sometimes "
2073 "standardize on different compilers."
2076 # type: Content of: <chapter><section><section><orderedlist><listitem><para>
2079 "Make sure your debian/rules contains separate <literal>binary-arch</literal> "
2080 "and <literal>binary-indep</literal> targets, as the Debian Policy Manual "
2081 "requires. Make sure that both targets work independently, that is, that you "
2082 "can call the target without having called the other before. To test this, "
2083 "try to run <command>dpkg-buildpackage -B</command>."
2086 # type: Content of: <chapter><section><section><title>
2088 msgid "Guidelines for porter uploads"
2091 # type: Content of: <chapter><section><section><para>
2094 "If the package builds out of the box for the architecture to be ported to, "
2095 "you are in luck and your job is easy. This section applies to that case; it "
2096 "describes how to build and upload your binary package so that it is properly "
2097 "installed into the archive. If you do have to patch the package in order to "
2098 "get it to compile for the other architecture, you are actually doing a "
2099 "source NMU, so consult <xref linkend=\"nmu-guidelines\"/> instead."
2102 # type: Content of: <chapter><section><section><para>
2105 "For a porter upload, no changes are being made to the source. You do not "
2106 "need to touch any of the files in the source package. This includes "
2107 "<filename>debian/changelog</filename>."
2110 # type: Content of: <chapter><section><section><para>
2113 "The way to invoke <command>dpkg-buildpackage</command> is as "
2114 "<literal>dpkg-buildpackage -B "
2115 "-m<replaceable>porter-email</replaceable></literal>. Of course, set "
2116 "<replaceable>porter-email</replaceable> to your email address. This will do "
2117 "a binary-only build of only the architecture-dependent portions of the "
2118 "package, using the <literal>binary-arch</literal> target in "
2119 "<filename>debian/rules </filename>."
2122 # type: Content of: <chapter><section><section><para>
2125 "If you are working on a Debian machine for your porting efforts and you need "
2126 "to sign your upload locally for its acceptance in the archive, you can run "
2127 "<command>debsign</command> on your <filename>.changes</filename> file to "
2128 "have it signed conveniently, or use the remote signing mode of "
2129 "<command>dpkg-sig</command>."
2132 # type: Content of: <chapter><section><section><section><title>
2134 msgid "Recompilation or binary-only NMU"
2137 # type: Content of: <chapter><section><section><section><para>
2140 "Sometimes the initial porter upload is problematic because the environment "
2141 "in which the package was built was not good enough (outdated or obsolete "
2142 "library, bad compiler, ...). Then you may just need to recompile it in an "
2143 "updated environment. However, you have to bump the version number in this "
2144 "case, so that the old bad package can be replaced in the Debian archive "
2145 "(<command>dak</command> refuses to install new packages if they don't have a "
2146 "version number greater than the currently available one)."
2149 # type: Content of: <chapter><section><section><section><para>
2152 "You have to make sure that your binary-only NMU doesn't render the package "
2153 "uninstallable. This could happen when a source package generates "
2154 "arch-dependent and arch-independent packages that have inter-dependencies "
2155 "generated using dpkg's substitution variable <literal>$(Source-Version) "
2159 # type: Content of: <chapter><section><section><section><para>
2162 "Despite the required modification of the changelog, these are called "
2163 "binary-only NMUs — there is no need in this case to trigger all other "
2164 "architectures to consider themselves out of date or requiring recompilation."
2167 # type: Content of: <chapter><section><section><section><para>
2170 "Such recompilations require special ``magic'' version numbering, so that the "
2171 "archive maintenance tools recognize that, even though there is a new Debian "
2172 "version, there is no corresponding source update. If you get this wrong, "
2173 "the archive maintainers will reject your upload (due to lack of "
2174 "corresponding source code)."
2177 # type: Content of: <chapter><section><section><section><para><footnote>
2180 "The ``magic'' for a recompilation-only NMU is triggered by using a suffix "
2181 "appended to the package version number, following the form <literal> "
2182 "b<replaceable>number</replaceable></literal>. For instance, if the latest "
2183 "version you are recompiling against was version <literal>2.9-3</literal>, "
2184 "your binary-only NMU should carry a version of <literal>2.9-3+b1</literal>. "
2185 "If the latest version was <literal>3.4+b1 </literal> (i.e, a native package "
2186 "with a previous recompilation NMU), your binary-only NMU should have a "
2187 "version number of <literal>3.4+b2</literal>. <footnote>"
2190 # type: Content of: <chapter><section><section><section><para><footnote><para>
2193 "In the past, such NMUs used the third-level number on the Debian part of the "
2194 "revision to denote their recompilation-only status; however, this syntax was "
2195 "ambiguous with native packages and did not allow proper ordering of "
2196 "recompile-only NMUs, source NMUs, and security NMUs on the same package, and "
2197 "has therefore been abandoned in favor of this new syntax."
2200 # type: Content of: <chapter><section><section><section><para>
2203 "Similar to initial porter uploads, the correct way of invoking "
2204 "<command>dpkg-buildpackage</command> is <literal>dpkg-buildpackage "
2205 "-B</literal> to only build the architecture-dependent parts of the package."
2208 # type: Content of: <chapter><section><section><section><title>
2210 msgid "When to do a source NMU if you are a porter"
2213 # type: Content of: <chapter><section><section><section><para>
2216 "Porters doing a source NMU generally follow the guidelines found in <xref "
2217 "linkend=\"nmu\"/> , just like non-porters. However, it is expected that the "
2218 "wait cycle for a porter's source NMU is smaller than for a non-porter, since "
2219 "porters have to cope with a large quantity of packages. Again, the "
2220 "situation varies depending on the distribution they are uploading to. It "
2221 "also varies whether the architecture is a candidate for inclusion into the "
2222 "next stable release; the release managers decide and announce which "
2223 "architectures are candidates."
2226 # type: Content of: <chapter><section><section><section><para>
2229 "If you are a porter doing an NMU for <literal>unstable</literal>, the above "
2230 "guidelines for porting should be followed, with two variations. Firstly, "
2231 "the acceptable waiting period — the time between when the bug is submitted "
2232 "to the BTS and when it is OK to do an NMU — is seven days for porters "
2233 "working on the <literal>unstable</literal> distribution. This period can be "
2234 "shortened if the problem is critical and imposes hardship on the porting "
2235 "effort, at the discretion of the porter group. (Remember, none of this is "
2236 "Policy, just mutually agreed upon guidelines.) For uploads to "
2237 "<literal>stable</literal> or <literal>testing </literal>, please coordinate "
2238 "with the appropriate release team first."
2241 # type: Content of: <chapter><section><section><section><para>
2244 "Secondly, porters doing source NMUs should make sure that the bug they "
2245 "submit to the BTS should be of severity <literal>serious</literal> or "
2246 "greater. This ensures that a single source package can be used to compile "
2247 "every supported Debian architecture by release time. It is very important "
2248 "that we have one version of the binary and source package for all "
2249 "architectures in order to comply with many licenses."
2252 # type: Content of: <chapter><section><section><section><para>
2255 "Porters should try to avoid patches which simply kludge around bugs in the "
2256 "current version of the compile environment, kernel, or libc. Sometimes such "
2257 "kludges can't be helped. If you have to kludge around compiler bugs and the "
2258 "like, make sure you <literal>#ifdef</literal> your work properly; also, "
2259 "document your kludge so that people know to remove it once the external "
2260 "problems have been fixed."
2263 # type: Content of: <chapter><section><section><section><para>
2266 "Porters may also have an unofficial location where they can put the results "
2267 "of their work during the waiting period. This helps others running the port "
2268 "have the benefit of the porter's work, even during the waiting period. Of "
2269 "course, such locations have no official blessing or status, so buyer beware."
2272 # type: Content of: <chapter><section><section><title>
2274 msgid "Porting infrastructure and automation"
2277 # type: Content of: <chapter><section><section><para>
2280 "There is infrastructure and several tools to help automate package porting. "
2281 "This section contains a brief overview of this automation and porting to "
2282 "these tools; see the package documentation or references for full "
2286 # type: Content of: <chapter><section><section><section><title>
2288 msgid "Mailing lists and web pages"
2291 # type: Content of: <chapter><section><section><section><para>
2294 "Web pages containing the status of each port can be found at <ulink "
2295 "url=\"&url-debian-ports;\"></ulink>."
2298 # type: Content of: <chapter><section><section><section><para>
2301 "Each port of Debian has a mailing list. The list of porting mailing lists "
2302 "can be found at <ulink url=\"&url-debian-port-lists;\"></ulink>. These "
2303 "lists are used to coordinate porters, and to connect the users of a given "
2304 "port with the porters."
2307 # type: Content of: <chapter><section><section><section><title>
2309 msgid "Porter tools"
2312 # type: Content of: <chapter><section><section><section><para>
2315 "Descriptions of several porting tools can be found in <xref "
2316 "linkend=\"tools-porting\"/> ."
2319 # type: Content of: <chapter><section><section><section><title>
2321 msgid "<systemitem role=\"package\">wanna-build</systemitem>"
2324 # type: Content of: <chapter><section><section><section><para>
2327 "The <systemitem role=\"package\">wanna-build</systemitem> system is used as "
2328 "a distributed, client-server build distribution system. It is usually used "
2329 "in conjunction with build daemons running the <systemitem "
2330 "role=\"package\">buildd </systemitem> program. <literal>Build "
2331 "daemons</literal> are ``slave'' hosts which contact the central <systemitem "
2332 "role=\"package\"> wanna-build</systemitem> system to receive a list of "
2333 "packages that need to be built."
2336 # type: Content of: <chapter><section><section><section><para>
2339 "<systemitem role=\"package\">wanna-build</systemitem> is not yet available "
2340 "as a package; however, all Debian porting efforts are using it for automated "
2341 "package building. The tool used to do the actual package builds, "
2342 "<systemitem role=\"package\">sbuild</systemitem> is available as a package, "
2343 "see its description in <xref linkend=\"sbuild\"/> . Please note that the "
2344 "packaged version is not the same as the one used on build daemons, but it is "
2345 "close enough to reproduce problems."
2348 # type: Content of: <chapter><section><section><section><para>
2351 "Most of the data produced by <systemitem role=\"package\">wanna-build "
2352 "</systemitem> which is generally useful to porters is available on the web "
2353 "at <ulink url=\"&url-buildd;\"></ulink>. This data includes nightly updated "
2354 "statistics, queueing information and logs for build attempts."
2357 # type: Content of: <chapter><section><section><section><para>
2360 "We are quite proud of this system, since it has so many possible uses. "
2361 "Independent development groups can use the system for different sub-flavors "
2362 "of Debian, which may or may not really be of general interest (for instance, "
2363 "a flavor of Debian built with <command>gcc</command> bounds checking). It "
2364 "will also enable Debian to recompile entire distributions quickly."
2367 # type: Content of: <chapter><section><section><section><para>
2370 "The buildds admins of each arch can be contacted at the mail address "
2371 "<literal><replaceable>arch</replaceable>@buildd.debian.org</literal>."
2374 # type: Content of: <chapter><section><section><title>
2376 msgid "When your package is <emphasis>not</emphasis> portable"
2379 # type: Content of: <chapter><section><section><para>
2382 "Some packages still have issues with building and/or working on some of the "
2383 "architectures supported by Debian, and cannot be ported at all, or not "
2384 "within a reasonable amount of time. An example is a package that is "
2385 "SVGA-specific (only available for <literal>i386</literal> and "
2386 "<literal>amd64</literal>), or uses other hardware-specific features not "
2387 "supported on all architectures."
2390 # type: Content of: <chapter><section><section><para>
2393 "In order to prevent broken packages from being uploaded to the archive, and "
2394 "wasting buildd time, you need to do a few things:"
2397 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
2400 "First, make sure your package <emphasis>does</emphasis> fail to build on "
2401 "architectures that it cannot support. There are a few ways to achieve "
2402 "this. The preferred way is to have a small testsuite during build time that "
2403 "will test the functionality, and fail if it doesn't work. This is a good "
2404 "idea anyway, as this will prevent (some) broken uploads on all "
2405 "architectures, and also will allow the package to build as soon as the "
2406 "required functionality is available."
2409 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
2412 "Additionally, if you believe the list of supported architectures is pretty "
2413 "constant, you should change <literal>any</literal> to a list of supported "
2414 "architectures in <filename>debian/control</filename>. This way, the build "
2415 "will fail also, and indicate this to a human reader without actually trying."
2418 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
2421 "In order to prevent autobuilders from needlessly trying to build your "
2422 "package, it must be included in <filename>packages-arch-specific</filename>, "
2423 "a list used by the <command>wanna-build</command> script. The current "
2424 "version is available as <ulink "
2425 "url=\"&url-cvsweb;srcdep/Packages-arch-specific?cvsroot=dak\"></ulink>; "
2426 "please see the top of the file for whom to contact for changes."
2429 # type: Content of: <chapter><section><section><para>
2432 "Please note that it is insufficient to only add your package to "
2433 "Packages-arch-specific without making it fail to build on unsupported "
2434 "architectures: A porter or any other person trying to build your package "
2435 "might accidently upload it without noticing it doesn't work. If in the past "
2436 "some binary packages were uploaded on unsupported architectures, request "
2437 "their removal by filing a bug against <systemitem "
2438 "role=\"package\">ftp.debian.org</systemitem>"
2441 # type: Content of: <chapter><section><title>
2443 msgid "Non-Maintainer Uploads (NMUs)"
2446 # type: Content of: <chapter><section><para>
2449 "Under certain circumstances it is necessary for someone other than the "
2450 "official package maintainer to make a release of a package. This is called "
2451 "a non-maintainer upload, or NMU."
2454 # type: Content of: <chapter><section><para>
2457 "This section handles only source NMUs, i.e. NMUs which upload a new version "
2458 "of the package. For binary-only NMUs by porters or QA members, please see "
2459 "<xref linkend=\"binary-only-nmu\"/> . If a buildd builds and uploads a "
2460 "package, that too is strictly speaking a binary NMU. See <xref "
2461 "linkend=\"wanna-build\"/> for some more information."
2464 # type: Content of: <chapter><section><para>
2467 "The main reason why NMUs are done is when a developer needs to fix another "
2468 "developer's package in order to address serious problems or crippling bugs "
2469 "or when the package maintainer is unable to release a fix in a timely "
2473 # type: Content of: <chapter><section><para>
2476 "First and foremost, it is critical that NMU patches to source should be as "
2477 "non-disruptive as possible. Do not do housekeeping tasks, do not change the "
2478 "name of modules or files, do not move directories; in general, do not fix "
2479 "things which are not broken. Keep the patch as small as possible. If "
2480 "things bother you aesthetically, talk to the Debian maintainer, talk to the "
2481 "upstream maintainer, or submit a bug. However, aesthetic changes must "
2482 "<emphasis>not</emphasis> be made in a non-maintainer upload."
2485 # type: Content of: <chapter><section><para>
2488 "And please remember the Hippocratic Oath: Above all, do no harm. It is "
2489 "better to leave a package with an open grave bug than applying a "
2490 "non-functional patch, or one that hides the bug instead of resolving it."
2493 # type: Content of: <chapter><section><section><title>
2495 msgid "How to do a NMU"
2498 # type: Content of: <chapter><section><section><para>
2501 "NMUs which fix important, serious or higher severity bugs are encouraged and "
2502 "accepted. You should endeavor to reach the current maintainer of the "
2503 "package; they might be just about to upload a fix for the problem, or have a "
2507 # type: Content of: <chapter><section><section><para>
2510 "NMUs should be made to assist a package's maintainer in resolving bugs. "
2511 "Maintainers should be thankful for that help, and NMUers should respect the "
2512 "decisions of maintainers, and try to personally help the maintainer by their "
2516 # type: Content of: <chapter><section><section><para>
2519 "A NMU should follow all conventions, written down in this section. For an "
2520 "upload to <literal>testing</literal> or <literal>unstable</literal>, this "
2521 "order of steps is recommended:"
2524 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
2527 "Make sure that the package's bugs that the NMU is meant to address are all "
2528 "filed in the Debian Bug Tracking System (BTS). If they are not, submit them "
2532 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
2535 "Wait a few days for the response from the maintainer. If you don't get any "
2536 "response, you may want to help them by sending the patch that fixes the "
2537 "bug. Don't forget to tag the bug with the patch keyword."
2540 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
2543 "Wait a few more days. If you still haven't got an answer from the "
2544 "maintainer, send them a mail announcing your intent to NMU the package. "
2545 "Prepare an NMU as described in this section, and test it carefully on your "
2546 "machine (cf. <xref linkend=\"sanitycheck\"/> ). Double check that your "
2547 "patch doesn't have any unexpected side effects. Make sure your patch is as "
2548 "small and as non-disruptive as it can be."
2551 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
2554 "Upload your package to incoming in <filename>DELAYED/7-day</filename> (cf. "
2555 "<xref linkend=\"delayed-incoming\"/> ), send the final patch to the "
2556 "maintainer via the BTS, and explain to them that they have 7 days to react "
2557 "if they want to cancel the NMU."
2560 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
2563 "Follow what happens, you're responsible for any bug that you introduced with "
2564 "your NMU. You should probably use <xref linkend=\"pkg-tracking-system\"/> "
2565 "(PTS) to stay informed of the state of the package after your NMU."
2568 # type: Content of: <chapter><section><section><para>
2571 "At times, the release manager or an organized group of developers can "
2572 "announce a certain period of time in which the NMU rules are relaxed. This "
2573 "usually involves shortening the period during which one is to wait before "
2574 "uploading the fixes, and shortening the DELAYED period. It is important to "
2575 "notice that even in these so-called bug squashing party times, the NMU'er "
2576 "has to file bugs and contact the developer first, and act later. Please see "
2577 "<xref linkend=\"qa-bsp\"/> for details."
2580 # type: Content of: <chapter><section><section><para>
2583 "For the <literal>testing</literal> distribution, the rules may be changed by "
2584 "the release managers. Please take additional care, and acknowledge that the "
2585 "usual way for a package to enter <literal>testing</literal> is through "
2586 "<literal>unstable</literal>."
2589 # type: Content of: <chapter><section><section><para>
2592 "For the stable distribution, please take extra care. Of course, the release "
2593 "managers may also change the rules here. Please verify before you upload "
2594 "that all your changes are OK for inclusion into the next stable release by "
2595 "the release manager."
2598 # type: Content of: <chapter><section><section><para>
2601 "When a security bug is detected, the security team may do an NMU, using "
2602 "their own rules. Please refer to <xref linkend=\"bug-security\"/> for more "
2606 # type: Content of: <chapter><section><section><para>
2609 "For the differences for Porters NMUs, please see <xref "
2610 "linkend=\"source-nmu-when-porter\"/> ."
2613 # type: Content of: <chapter><section><section><para>
2616 "Of course, it is always possible to agree on special rules with a maintainer "
2617 "(like the maintainer asking please upload this fix directly for me, and no "
2621 # type: Content of: <chapter><section><section><title>
2623 msgid "NMU version numbering"
2626 # type: Content of: <chapter><section><section><para>
2629 "Whenever you have made a change to a package, no matter how trivial, the "
2630 "version number needs to change. This enables our packing system to "
2634 # type: Content of: <chapter><section><section><para>
2637 "If you are doing a non-maintainer upload (NMU), you should add a new minor "
2638 "version number to the <replaceable>debian-revision</replaceable> part of the "
2639 "version number (the portion after the last hyphen). This extra minor number "
2640 "will start at `1'. For example, consider the package `foo', which is at "
2641 "version 1.1-3. In the archive, the source package control file would be "
2642 "<filename>foo_1.1-3.dsc</filename>. The upstream version is `1.1' and the "
2643 "Debian revision is `3'. The next NMU would add a new minor number `.1' to "
2644 "the Debian revision; the new source control file would be "
2645 "<filename>foo_1.1-3.1.dsc</filename>."
2648 # type: Content of: <chapter><section><section><para>
2651 "The Debian revision minor number is needed to avoid stealing one of the "
2652 "package maintainer's version numbers, which might disrupt their work. It "
2653 "also has the benefit of making it visually clear that a package in the "
2654 "archive was not made by the official maintainer."
2657 # type: Content of: <chapter><section><section><para>
2660 "If there is no <replaceable>debian-revision</replaceable> component in the "
2661 "version number then one should be created, starting at `0.1' (but in case of "
2662 "a debian native package still upload it as native package). If it is "
2663 "absolutely necessary for someone other than the usual maintainer to make a "
2664 "release based on a new upstream version then the person making the release "
2665 "should start with the <replaceable>debian-revision</replaceable> value "
2666 "`0.1'. The usual maintainer of a package should start their "
2667 "<replaceable>debian-revision</replaceable> numbering at `1'."
2670 # type: Content of: <chapter><section><section><para>
2673 "If you upload a package to <literal>testing</literal> or <literal>stable "
2674 "</literal>, sometimes, you need to fork the version number tree. For this, "
2675 "version numbers like 1.1-3sarge0.1 could be used."
2678 # type: Content of: <chapter><section><section><title>
2680 msgid "Source NMUs must have a new changelog entry"
2683 # type: Content of: <chapter><section><section><para>
2686 "Anyone who is doing a source NMU must create a changelog entry, describing "
2687 "which bugs are fixed by the NMU, and generally why the NMU was required and "
2688 "what it fixed. The changelog entry will have the email address of the "
2689 "person who uploaded it in the log entry and the NMU version number in it."
2692 # type: Content of: <chapter><section><section><para>
2694 msgid "By convention, source NMU changelog entries start with the line"
2697 # type: Content of: <chapter><section><section><screen>
2702 " * Non-maintainer upload\n"
2705 # type: Content of: <chapter><section><section><title>
2707 msgid "Source NMUs and the Bug Tracking System"
2710 # type: Content of: <chapter><section><section><para>
2713 "Maintainers other than the official package maintainer should make as few "
2714 "changes to the package as possible, and they should always send a patch as a "
2715 "unified context diff (<literal>diff -u</literal>) detailing their changes to "
2716 "the Bug Tracking System."
2719 # type: Content of: <chapter><section><section><para>
2722 "What if you are simply recompiling the package? If you just need to "
2723 "recompile it for a single architecture, then you may do a binary-only NMU as "
2724 "described in <xref linkend=\"binary-only-nmu\"/> which doesn't require any "
2725 "patch to be sent. If you want the package to be recompiled for all "
2726 "architectures, then you do a source NMU as usual and you will have to send a "
2730 # type: Content of: <chapter><section><section><para>
2733 "Bugs fixed by source NMUs used to be tagged fixed instead of closed, but "
2734 "since version tracking is in place, such bugs are now also closed with the "
2738 # type: Content of: <chapter><section><section><para>
2741 "Also, after doing an NMU, you have to send the information to the existing "
2742 "bugs that are fixed by your NMU, including the unified diff. Historically, "
2743 "it was custom to open a new bug and include a patch showing all the changes "
2744 "you have made. The normal maintainer will either apply the patch or employ "
2745 "an alternate method of fixing the problem. Sometimes bugs are fixed "
2746 "independently upstream, which is another good reason to back out an NMU's "
2747 "patch. If the maintainer decides not to apply the NMU's patch but to "
2748 "release a new version, the maintainer needs to ensure that the new upstream "
2749 "version really fixes each problem that was fixed in the non-maintainer "
2753 # type: Content of: <chapter><section><section><para>
2756 "In addition, the normal maintainer should <emphasis>always</emphasis> retain "
2757 "the entry in the changelog file documenting the non-maintainer upload -- and "
2758 "of course, also keep the changes. If you revert some of the changes, please "
2759 "reopen the relevant bug reports."
2762 # type: Content of: <chapter><section><section><title>
2764 msgid "Building source NMUs"
2767 # type: Content of: <chapter><section><section><para>
2770 "Source NMU packages are built normally. Pick a distribution using the same "
2771 "rules as found in <xref linkend=\"distribution\"/> , follow the other "
2772 "instructions in <xref linkend=\"upload\"/> ."
2775 # type: Content of: <chapter><section><section><para>
2778 "Make sure you do <emphasis>not</emphasis> change the value of the maintainer "
2779 "in the <filename>debian/control</filename> file. Your name as given in the "
2780 "NMU entry of the <filename>debian/changelog</filename> file will be used for "
2781 "signing the changes file."
2784 # type: Content of: <chapter><section><section><title>
2786 msgid "Acknowledging an NMU"
2789 # type: Content of: <chapter><section><section><para>
2792 "If one of your packages has been NMU'ed, you have to incorporate the changes "
2793 "in your copy of the sources. This is easy, you just have to apply the patch "
2794 "that has been sent to you. Once this is done, you have to close the bugs "
2795 "that have been tagged fixed by the NMU. The easiest way is to use the "
2796 "<literal>-v</literal> option of <command>dpkg-buildpackage</command>, as "
2797 "this allows you to include just all changes since your last maintainer "
2798 "upload. Alternatively, you can close them manually by sending the required "
2799 "mails to the BTS or by adding the required <literal>closes: #nnnn</literal> "
2800 "in the changelog entry of your next upload."
2803 # type: Content of: <chapter><section><section><para>
2806 "In any case, you should not be upset by the NMU. An NMU is not a personal "
2807 "attack against the maintainer. It is a proof that someone cares enough "
2808 "about the package that they were willing to help you in your work, so you "
2809 "should be thankful. You may also want to ask them if they would be "
2810 "interested in helping you on a more frequent basis as co-maintainer or "
2811 "backup maintainer (see <xref linkend=\"collaborative-maint\"/> )."
2814 # type: Content of: <chapter><section><section><title>
2816 msgid "NMU vs QA uploads"
2819 # type: Content of: <chapter><section><section><para>
2822 "Unless you know the maintainer is still active, it is wise to check the "
2823 "package to see if it has been orphaned. The current list of orphaned "
2824 "packages which haven't had their maintainer set correctly is available at "
2825 "<ulink url=\"&url-debian-qa-orphaned;\"></ulink>. If you perform an NMU on "
2826 "an improperly orphaned package, please set the maintainer to <literal>Debian "
2827 "QA Group <packages@qa.debian.org></literal>."
2830 # type: Content of: <chapter><section><section><title>
2832 msgid "Who can do an NMU"
2835 # type: Content of: <chapter><section><section><para>
2838 "Only official, registered Debian Developers can do binary or source NMUs. A "
2839 "Debian Developer is someone who has their key in the Debian key ring. "
2840 "Non-developers, however, are encouraged to download the source package and "
2841 "start hacking on it to fix problems; however, rather than doing an NMU, they "
2842 "should just submit worthwhile patches to the Bug Tracking System. "
2843 "Maintainers almost always appreciate quality patches and bug reports."
2846 # type: Content of: <chapter><section><section><title>
2851 # type: Content of: <chapter><section><section><para>
2854 "There are two new terms used throughout this section: ``binary-only NMU'' "
2855 "and ``source NMU''. These terms are used with specific technical meaning "
2856 "throughout this document. Both binary-only and source NMUs are similar, "
2857 "since they involve an upload of a package by a developer who is not the "
2858 "official maintainer of that package. That is why it's a "
2859 "<literal>non-maintainer</literal> upload."
2862 # type: Content of: <chapter><section><section><para>
2865 "A source NMU is an upload of a package by a developer who is not the "
2866 "official maintainer, for the purposes of fixing a bug in the package. "
2867 "Source NMUs always involves changes to the source (even if it is just a "
2868 "change to <filename>debian/changelog</filename>). This can be either a "
2869 "change to the upstream source, or a change to the Debian bits of the "
2870 "source. Note, however, that source NMUs may also include "
2871 "architecture-dependent packages, as well as an updated Debian diff."
2874 # type: Content of: <chapter><section><section><para>
2877 "A binary-only NMU is a recompilation and upload of a binary package for a "
2878 "given architecture. As such, it is usually part of a porting effort. A "
2879 "binary-only NMU is a non-maintainer uploaded binary version of a package, "
2880 "with no source changes required. There are many cases where porters must "
2881 "fix problems in the source in order to get them to compile for their target "
2882 "architecture; that would be considered a source NMU rather than a "
2883 "binary-only NMU. As you can see, we don't distinguish in terminology "
2884 "between porter NMUs and non-porter NMUs."
2887 # type: Content of: <chapter><section><section><para>
2890 "Both classes of NMUs, source and binary-only, can be lumped under the term "
2891 "``NMU''. However, this often leads to confusion, since most people think "
2892 "``source NMU'' when they think ``NMU''. So it's best to be careful: always "
2893 "use ``binary NMU'' or ``binNMU'' for binary-only NMUs."
2896 # type: Content of: <chapter><section><title>
2898 msgid "Collaborative maintenance"
2901 # type: Content of: <chapter><section><para>
2904 "Collaborative maintenance is a term describing the sharing of Debian package "
2905 "maintenance duties by several people. This collaboration is almost always a "
2906 "good idea, since it generally results in higher quality and faster bug fix "
2907 "turnaround times. It is strongly recommended that packages with a priority "
2908 "of <literal>Standard</literal> or which are part of the base set have "
2912 # type: Content of: <chapter><section><para>
2915 "Generally there is a primary maintainer and one or more co-maintainers. The "
2916 "primary maintainer is the person whose name is listed in the "
2917 "<literal>Maintainer</literal> field of the "
2918 "<filename>debian/control</filename> file. Co-maintainers are all the other "
2919 "maintainers, usually listed in the <literal>Uploaders</literal> field of the "
2920 "<filename>debian/control</filename> file."
2923 # type: Content of: <chapter><section><para>
2926 "In its most basic form, the process of adding a new co-maintainer is quite "
2930 # type: Content of: <chapter><section><itemizedlist><listitem><para>
2933 "Setup the co-maintainer with access to the sources you build the package "
2934 "from. Generally this implies you are using a network-capable version "
2935 "control system, such as <command>CVS</command> or "
2936 "<command>Subversion</command>. Alioth (see <xref linkend=\"alioth\"/> ) "
2937 "provides such tools, amongst others."
2940 # type: Content of: <chapter><section><itemizedlist><listitem><para>
2943 "Add the co-maintainer's correct maintainer name and address to the "
2944 "<literal>Uploaders</literal> field in the first paragraph of the "
2945 "<filename>debian/control</filename> file."
2948 # type: Content of: <chapter><section><itemizedlist><listitem><screen>
2953 "Uploaders: John Buzz <jbuzz@debian.org>, Adam Rex "
2954 "<arex@debian.org>\n"
2957 # type: Content of: <chapter><section><itemizedlist><listitem><para>
2960 "Using the PTS (<xref linkend=\"pkg-tracking-system\"/> ), the co-maintainers "
2961 "should subscribe themselves to the appropriate source package."
2964 # type: Content of: <chapter><section><para>
2967 "Another form of collaborative maintenance is team maintenance, which is "
2968 "recommended if you maintain several packages with the same group of "
2969 "developers. In that case, the Maintainer and Uploaders field of each "
2970 "package must be managed with care. It is recommended to choose between one "
2971 "of the two following schemes:"
2974 # type: Content of: <chapter><section><orderedlist><listitem><para>
2977 "Put the team member mainly responsible for the package in the Maintainer "
2978 "field. In the Uploaders, put the mailing list address, and the team members "
2979 "who care for the package."
2982 # type: Content of: <chapter><section><orderedlist><listitem><para>
2985 "Put the mailing list address in the Maintainer field. In the Uploaders "
2986 "field, put the team members who care for the package. In this case, you "
2987 "must make sure the mailing list accept bug reports without any human "
2988 "interaction (like moderation for non-subscribers)."
2991 # type: Content of: <chapter><section><para>
2994 "In any case, it is a bad idea to automatically put all team members in the "
2995 "Uploaders field. It clutters the Developer's Package Overview listing (see "
2996 "<xref linkend=\"ddpo\"/> ) with packages one doesn't really care for, and "
2997 "creates a false sense of good maintenance."
3000 # type: Content of: <chapter><section><title>
3002 msgid "The testing distribution"
3005 # type: Content of: <chapter><section><section><title>
3010 # type: Content of: <chapter><section><section><para>
3013 "Packages are usually installed into the <literal>testing</literal> "
3014 "distribution after they have undergone some degree of "
3015 "<literal>testing</literal> in <literal>unstable</literal>."
3018 # type: Content of: <chapter><section><section><para>
3021 "They must be in sync on all architectures and mustn't have dependencies that "
3022 "make them uninstallable; they also have to have generally no known "
3023 "release-critical bugs at the time they're installed into <literal>testing "
3024 "</literal>. This way, <literal>testing</literal> should always be close to "
3025 "being a release candidate. Please see below for details."
3028 # type: Content of: <chapter><section><section><title>
3030 msgid "Updates from unstable"
3033 # type: Content of: <chapter><section><section><para>
3036 "The scripts that update the <literal>testing</literal> distribution are run "
3037 "twice each day, right after the installation of the updated packages; these "
3038 "scripts are called <literal>britney</literal>. They generate the "
3039 "<filename>Packages</filename> files for the <literal>testing</literal> "
3040 "distribution, but they do so in an intelligent manner; they try to avoid any "
3041 "inconsistency and to use only non-buggy packages."
3044 # type: Content of: <chapter><section><section><para>
3047 "The inclusion of a package from <literal>unstable</literal> is conditional "
3051 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
3054 "The package must have been available in <literal>unstable</literal> for 2, 5 "
3055 "or 10 days, depending on the urgency (high, medium or low). Please note "
3056 "that the urgency is sticky, meaning that the highest urgency uploaded since "
3057 "the previous <literal>testing</literal> transition is taken into account. "
3058 "Those delays may be doubled during a freeze, or <literal>testing</literal> "
3059 "transitions may be switched off altogether;"
3062 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
3065 "It must not have new release-critical bugs (RC bugs affecting the version "
3066 "available in <literal>unstable</literal>, but not affecting the version in "
3067 "<literal>testing</literal>);"
3070 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
3073 "It must be available on all architectures on which it has previously been "
3074 "built in <literal>unstable</literal>. <xref linkend=\"dak-ls\"/> may be of "
3075 "interest to check that information;"
3078 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
3081 "It must not break any dependency of a package which is already available in "
3082 "<literal>testing</literal>;"
3085 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
3088 "The packages on which it depends must either be available in "
3089 "<literal>testing</literal> or they must be accepted into "
3090 "<literal>testing</literal> at the same time (and they will be if they "
3091 "fulfill all the necessary criteria);"
3094 # type: Content of: <chapter><section><section><para>
3097 "To find out whether a package is progressing into <literal>testing</literal> "
3098 "or not, see the <literal>testing</literal> script output on the <ulink "
3099 "url=\"&url-testing-maint;\">web page of the testing distribution</ulink>, or "
3100 "use the program <command>grep-excuses</command> which is in the <systemitem "
3101 "role=\"package\">devscripts</systemitem> package. This utility can easily "
3102 "be used in a <citerefentry> <refentrytitle>crontab</refentrytitle> "
3103 "<manvolnum>5</manvolnum> </citerefentry> to keep yourself informed of the "
3104 "progression of your packages into <literal>testing</literal>."
3107 # type: Content of: <chapter><section><section><para>
3110 "The <filename>update_excuses</filename> file does not always give the "
3111 "precise reason why the package is refused; you may have to find it on your "
3112 "own by looking for what would break with the inclusion of the package. The "
3113 "<ulink url=\"&url-testing-maint;\">testing web page</ulink> gives some more "
3114 "information about the usual problems which may be causing such troubles."
3117 # type: Content of: <chapter><section><section><para>
3120 "Sometimes, some packages never enter <literal>testing</literal> because the "
3121 "set of inter-relationship is too complicated and cannot be sorted out by the "
3122 "scripts. See below for details."
3125 # type: Content of: <chapter><section><section><para>
3128 "Some further dependency analysis is shown on <ulink "
3129 "url=\"http://release.debian.org/migration/\"></ulink> — but be warned, this "
3130 "page also shows build dependencies which are not considered by britney."
3133 # type: Content of: <chapter><section><section><section><title>
3138 #. FIXME: better rename this file than document rampant professionalism?
3139 # type: Content of: <chapter><section><section><section><para>
3142 "For the <literal>testing</literal> migration script, outdated means: There "
3143 "are different versions in <literal>unstable</literal> for the release "
3144 "architectures (except for the architectures in fuckedarches; fuckedarches is "
3145 "a list of architectures that don't keep up (in "
3146 "<filename>update_out.py</filename>), but currently, it's empty). outdated "
3147 "has nothing whatsoever to do with the architectures this package has in "
3148 "<literal>testing</literal>."
3151 # type: Content of: <chapter><section><section><section><para>
3153 msgid "Consider this example:"
3156 # type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry>
3157 #: pkgs.dbk:2354 pkgs.dbk:2387
3161 # type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry>
3162 #: pkgs.dbk:2355 pkgs.dbk:2388
3166 # type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry>
3167 #: pkgs.dbk:2360 pkgs.dbk:2394 pkgs.dbk:2456
3171 # type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
3172 #: pkgs.dbk:2361 pkgs.dbk:2366 pkgs.dbk:2395 pkgs.dbk:2396 pkgs.dbk:2403
3176 # type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
3177 #: pkgs.dbk:2362 pkgs.dbk:2397 pkgs.dbk:2402
3181 # type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry>
3182 #: pkgs.dbk:2365 pkgs.dbk:2400 pkgs.dbk:2457
3186 # type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
3187 #: pkgs.dbk:2367 pkgs.dbk:2401
3191 # type: Content of: <chapter><section><section><section><para>
3194 "The package is out of date on alpha in <literal>unstable</literal>, and will "
3195 "not go to <literal>testing</literal>. Removing the package would not help at "
3196 "all, the package is still out of date on <literal>alpha</literal>, and will "
3197 "not propagate to testing."
3200 # type: Content of: <chapter><section><section><section><para>
3203 "However, if ftp-master removes a package in <literal>unstable</literal> "
3204 "(here on <literal>arm</literal>):"
3207 # type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry>
3212 # type: Content of: <chapter><section><section><section><para>
3215 "In this case, the package is up to date on all release architectures in "
3216 "<literal>unstable</literal> (and the extra <literal>hurd-i386</literal> "
3217 "doesn't matter, as it's not a release architecture)."
3220 # type: Content of: <chapter><section><section><section><para>
3223 "Sometimes, the question is raised if it is possible to allow packages in "
3224 "that are not yet built on all architectures: No. Just plainly no. (Except "
3225 "if you maintain glibc or so.)"
3228 # type: Content of: <chapter><section><section><section><title>
3230 msgid "Removals from testing"
3233 # type: Content of: <chapter><section><section><section><para>
3236 "Sometimes, a package is removed to allow another package in: This happens "
3237 "only to allow <emphasis>another</emphasis> package to go in if it's ready in "
3238 "every other sense. Suppose e.g. that <literal>a</literal> cannot be "
3239 "installed with the new version of <literal>b</literal>; then "
3240 "<literal>a</literal> may be removed to allow <literal>b</literal> in."
3243 # type: Content of: <chapter><section><section><section><para>
3246 "Of course, there is another reason to remove a package from <literal>testing "
3247 "</literal>: It's just too buggy (and having a single RC-bug is enough to be "
3251 # type: Content of: <chapter><section><section><section><para>
3254 "Furthermore, if a package has been removed from <literal>unstable</literal>, "
3255 "and no package in <literal>testing</literal> depends on it any more, then it "
3256 "will automatically be removed."
3259 # type: Content of: <chapter><section><section><section><title>
3261 msgid "circular dependencies"
3264 # type: Content of: <chapter><section><section><section><para>
3267 "A situation which is not handled very well by britney is if package "
3268 "<literal>a</literal> depends on the new version of package "
3269 "<literal>b</literal>, and vice versa."
3272 # type: Content of: <chapter><section><section><section><para>
3274 msgid "An example of this is:"
3277 # type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
3282 # type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
3284 msgid "1; depends: b=1"
3287 # type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
3289 msgid "2; depends: b=2"
3292 # type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
3297 # type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
3299 msgid "1; depends: a=1"
3302 # type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
3304 msgid "2; depends: a=2"
3307 # type: Content of: <chapter><section><section><section><para>
3310 "Neither package <literal>a</literal> nor package <literal>b</literal> is "
3311 "considered for update."
3314 # type: Content of: <chapter><section><section><section><para>
3317 "Currently, this requires some manual hinting from the release team. Please "
3318 "contact them by sending mail to &email-debian-release; if this happens to "
3319 "one of your packages."
3322 # type: Content of: <chapter><section><section><section><title>
3324 msgid "influence of package in testing"
3327 # type: Content of: <chapter><section><section><section><para>
3330 "Generally, there is nothing that the status of a package in <literal>testing "
3331 "</literal> means for transition of the next version from <literal>unstable "
3332 "</literal> to <literal>testing</literal>, with two exceptions: If the "
3333 "RC-bugginess of the package goes down, it may go in even if it is still "
3334 "RC-buggy. The second exception is if the version of the package in "
3335 "<literal> testing</literal> is out of sync on the different arches: Then any "
3336 "arch might just upgrade to the version of the source package; however, this "
3337 "can happen only if the package was previously forced through, the arch is in "
3338 "fuckedarches, or there was no binary package of that arch present in "
3339 "<literal>unstable </literal> at all during the <literal>testing</literal> "
3343 # type: Content of: <chapter><section><section><section><para>
3346 "In summary this means: The only influence that a package being in <literal> "
3347 "testing</literal> has on a new version of the same package is that the new "
3348 "version might go in easier."
3351 # type: Content of: <chapter><section><section><section><title>
3356 # type: Content of: <chapter><section><section><section><para>
3358 msgid "If you are interested in details, this is how britney works:"
3361 # type: Content of: <chapter><section><section><section><para>
3364 "The packages are looked at to determine whether they are valid candidates. "
3365 "This gives the update excuses. The most common reasons why a package is not "
3366 "considered are too young, RC-bugginess, and out of date on some arches. For "
3367 "this part of britney, the release managers have hammers of various sizes to "
3368 "force britney to consider a package. (Also, the base freeze is coded in "
3369 "that part of britney.) (There is a similar thing for binary-only updates, "
3370 "but this is not described here. If you're interested in that, please peruse "
3374 # type: Content of: <chapter><section><section><section><para>
3377 "Now, the more complex part happens: Britney tries to update <literal>testing "
3378 "</literal> with the valid candidates. For that, britney tries to add each "
3379 "valid candidate to the testing distribution. If the number of uninstallable "
3380 "packages in <literal>testing</literal> doesn't increase, the package is "
3381 "accepted. From that point on, the accepted package is considered to be part "
3382 "of <literal>testing</literal>, such that all subsequent installability tests "
3383 "include this package. Hints from the release team are processed before or "
3384 "after this main run, depending on the exact type."
3387 # type: Content of: <chapter><section><section><section><para>
3390 "If you want to see more details, you can look it up on "
3391 "<filename>merkel:/org/&ftp-debian-org;/testing/update_out/</filename> (or in "
3392 "<filename>merkel:~aba/testing/update_out</filename> to see a setup with a "
3393 "smaller packages file). Via web, it's at <ulink "
3394 "url=\"http://&ftp-master-host;/testing/update_out_code/\"></ulink>"
3397 # type: Content of: <chapter><section><section><section><para>
3400 "The hints are available via <ulink "
3401 "url=\"http://&ftp-master-host;/testing/hints/\"></ulink>."
3404 # type: Content of: <chapter><section><section><title>
3406 msgid "Direct updates to testing"
3409 # type: Content of: <chapter><section><section><para>
3412 "The <literal>testing</literal> distribution is fed with packages from "
3413 "<literal>unstable</literal> according to the rules explained above. "
3414 "However, in some cases, it is necessary to upload packages built only for "
3415 "<literal> testing</literal>. For that, you may want to upload to <literal> "
3416 "testing-proposed-updates</literal>."
3419 # type: Content of: <chapter><section><section><para>
3422 "Keep in mind that packages uploaded there are not automatically processed, "
3423 "they have to go through the hands of the release manager. So you'd better "
3424 "have a good reason to upload there. In order to know what a good reason is "
3425 "in the release managers' eyes, you should read the instructions that they "
3426 "regularly give on &email-debian-devel-announce;."
3429 # type: Content of: <chapter><section><section><para>
3432 "You should not upload to <literal>testing-proposed-updates</literal> when "
3433 "you can update your packages through <literal>unstable</literal>. If you "
3434 "can't (for example because you have a newer development version in "
3435 "<literal>unstable </literal>), you may use this facility, but it is "
3436 "recommended that you ask for authorization from the release manager first. "
3437 "Even if a package is frozen, updates through <literal>unstable</literal> are "
3438 "possible, if the upload via <literal>unstable</literal> does not pull in any "
3442 # type: Content of: <chapter><section><section><para>
3445 "Version numbers are usually selected by adding the codename of the "
3446 "<literal>testing</literal> distribution and a running number, like "
3447 "<literal>1.2sarge1</literal> for the first upload through "
3448 "<literal>testing-proposed-updates</literal> of package version "
3449 "<literal>1.2</literal>."
3452 # type: Content of: <chapter><section><section><para>
3454 msgid "Please make sure you didn't miss any of these items in your upload:"
3457 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
3460 "Make sure that your package really needs to go through "
3461 "<literal>testing-proposed-updates</literal>, and can't go through <literal> "
3462 "unstable</literal>;"
3465 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
3467 msgid "Make sure that you included only the minimal amount of changes;"
3470 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
3472 msgid "Make sure that you included an appropriate explanation in the changelog;"
3475 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
3478 "Make sure that you've written <literal>testing</literal> or "
3479 "<literal>testing-proposed-updates</literal> into your target distribution;"
3482 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
3485 "Make sure that you've built and tested your package in "
3486 "<literal>testing</literal>, not in <literal>unstable</literal>;"
3489 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
3492 "Make sure that your version number is higher than the version in "
3493 "<literal>testing</literal> and <literal>testing-proposed-updates</literal>, "
3494 "and lower than in <literal>unstable</literal>;"
3497 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
3500 "After uploading and successful build on all platforms, contact the release "
3501 "team at &email-debian-release; and ask them to approve your upload."
3504 # type: Content of: <chapter><section><section><title>
3506 msgid "Frequently asked questions"
3509 # type: Content of: <chapter><section><section><section><title>
3511 msgid "What are release-critical bugs, and how do they get counted?"
3514 # type: Content of: <chapter><section><section><section><para>
3517 "All bugs of some higher severities are by default considered "
3518 "release-critical; currently, these are <literal>critical</literal>, "
3519 "<literal>grave</literal> and <literal>serious</literal> bugs."
3522 # type: Content of: <chapter><section><section><section><para>
3525 "Such bugs are presumed to have an impact on the chances that the package "
3526 "will be released with the <literal>stable</literal> release of Debian: in "
3527 "general, if a package has open release-critical bugs filed on it, it won't "
3528 "get into <literal>testing</literal>, and consequently won't be released in "
3529 "<literal> stable</literal>."
3532 # type: Content of: <chapter><section><section><section><para>
3535 "The <literal>unstable</literal> bug count are all release-critical bugs "
3536 "which are marked to apply to "
3537 "<replaceable>package</replaceable>/<replaceable>version </replaceable> "
3538 "combinations that are available in unstable for a release architecture. The "
3539 "<literal>testing</literal> bug count is defined analogously."
3542 # type: Content of: <chapter><section><section><section><title>
3545 "How could installing a package into <literal>testing</literal> possibly "
3546 "break other packages?"
3549 # type: Content of: <chapter><section><section><section><para>
3552 "The structure of the distribution archives is such that they can only "
3553 "contain one version of a package; a package is defined by its name. So when "
3554 "the source package <literal>acmefoo</literal> is installed into "
3555 "<literal>testing</literal>, along with its binary packages "
3556 "<literal>acme-foo-bin</literal>, <literal> acme-bar-bin</literal>, "
3557 "<literal>libacme-foo1</literal> and <literal> libacme-foo-dev</literal>, the "
3558 "old version is removed."
3561 # type: Content of: <chapter><section><section><section><para>
3564 "However, the old version may have provided a binary package with an old "
3565 "soname of a library, such as <literal>libacme-foo0</literal>. Removing the "
3566 "old <literal>acmefoo</literal> will remove <literal>libacme-foo0</literal>, "
3567 "which will break any packages which depend on it."
3570 # type: Content of: <chapter><section><section><section><para>
3573 "Evidently, this mainly affects packages which provide changing sets of "
3574 "binary packages in different versions (in turn, mainly libraries). However, "
3575 "it will also affect packages upon which versioned dependencies have been "
3576 "declared of the ==, <=, or << varieties."
3579 # type: Content of: <chapter><section><section><section><para>
3582 "When the set of binary packages provided by a source package change in this "
3583 "way, all the packages that depended on the old binaries will have to be "
3584 "updated to depend on the new binaries instead. Because installing such a "
3585 "source package into <literal>testing</literal> breaks all the packages that "
3586 "depended on it in <literal>testing</literal>, some care has to be taken now: "
3587 "all the depending packages must be updated and ready to be installed "
3588 "themselves so that they won't be broken, and, once everything is ready, "
3589 "manual intervention by the release manager or an assistant is normally "
3593 # type: Content of: <chapter><section><section><section><para>
3596 "If you are having problems with complicated groups of packages like this, "
3597 "contact &email-debian-devel; or &email-debian-release; for help."