1 # Debian Developer's Reference (Japanese)
2 # Hideki Yamane (Debian-JP) <henrich@debian.or.jp>, 2008.
6 "Project-Id-Version: developers-reference 3.3.9\n"
7 "POT-Creation-Date: 2008-03-05 18:02+0900\n"
8 "PO-Revision-Date: 2008-03-05 18:30+0900\n"
9 "Last-Translator: Hideki Yamane (Debian-JP) <henrich@debian.or.jp>\n"
10 "Language-Team: Debian JP Project <debian-doc@debian.or.jp>\n"
12 "Content-Type: text/plain; charset=UTF-8\n"
13 "Content-Transfer-Encoding: 8bit\n"
15 # type: Content of: <chapter><title>
17 msgid "Managing Packages"
20 # type: Content of: <chapter><para>
23 "This chapter contains information related to creating, uploading, "
24 "maintaining, and porting packages."
26 "この章は、パッケージの作成、アップロード、メンテナンス、移植についての情報を"
29 # type: Content of: <chapter><section><title>
34 # type: Content of: <chapter><section><para>
37 "If you want to create a new package for the Debian distribution, you should "
38 "first check the <ulink url=\"&url-wnpp;\">Work-Needing and Prospective "
39 "Packages (WNPP)</ulink> list. Checking the WNPP list ensures that no one is "
40 "already working on packaging that software, and that effort is not "
41 "duplicated. Read the <ulink url=\"&url-wnpp;\">WNPP web pages</ulink> for "
45 # type: Content of: <chapter><section><para>
48 "Assuming no one else is already working on your prospective package, you "
49 "must then submit a bug report (<xref linkend=\"submit-bug\"/> ) against the "
50 "pseudo-package <systemitem role=\"package\">wnpp</systemitem> describing "
51 "your plan to create a new package, including, but not limiting yourself to, "
52 "a description of the package, the license of the prospective package, and "
53 "the current URL where it can be downloaded from."
56 # type: Content of: <chapter><section><para>
59 "You should set the subject of the bug to ``ITP: <replaceable>foo</"
60 "replaceable> -- <replaceable>short description</replaceable>'', substituting "
61 "the name of the new package for <replaceable>foo</replaceable>. The "
62 "severity of the bug report must be set to <emphasis>wishlist</emphasis>. If "
63 "you feel it's necessary, send a copy to &email-debian-devel; by putting the "
64 "address in the <literal>X-Debbugs-CC:</literal> header of the message (no, "
65 "don't use <literal>CC:</literal>, because that way the message's subject "
66 "won't indicate the bug number)."
69 # type: Content of: <chapter><section><para>
72 "Please include a <literal>Closes: bug#<replaceable>nnnnn</replaceable></"
73 "literal> entry in the changelog of the new package in order for the bug "
74 "report to be automatically closed once the new package is installed in the "
75 "archive (see <xref linkend=\"upload-bugfix\"/> )."
78 # type: Content of: <chapter><section><para>
81 "When closing security bugs include CVE numbers as well as the Closes: "
82 "#nnnnn. This is useful for the security team to track vulnerabilities. If "
83 "an upload is made to fix the bug before the advisory ID is known, it is "
84 "encouraged to modify the historical changelog entry with the next upload. "
85 "Even in this case, please include all available pointers to background "
86 "information in the original changelog entry."
89 # type: Content of: <chapter><section><para>
92 "There are a number of reasons why we ask maintainers to announce their "
96 # type: Content of: <chapter><section><itemizedlist><listitem><para>
99 "It helps the (potentially new) maintainer to tap into the experience of "
100 "people on the list, and lets them know if anyone else is working on it "
104 # type: Content of: <chapter><section><itemizedlist><listitem><para>
107 "It lets other people thinking about working on the package know that there "
108 "already is a volunteer, so efforts may be shared."
111 # type: Content of: <chapter><section><itemizedlist><listitem><para>
114 "It lets the rest of the maintainers know more about the package than the one "
115 "line description and the usual changelog entry ``Initial release'' that gets "
116 "posted to <literal>debian-devel-changes</literal>."
119 # type: Content of: <chapter><section><itemizedlist><listitem><para>
122 "It is helpful to the people who live off unstable (and form our first line "
123 "of testers). We should encourage these people."
126 # type: Content of: <chapter><section><itemizedlist><listitem><para>
129 "The announcements give maintainers and other interested parties a better "
130 "feel of what is going on, and what is new, in the project."
133 # type: Content of: <chapter><section><para>
136 "Please see <ulink url=\"http://&ftp-master-host;/REJECT-FAQ.html\"></ulink> "
137 "for common rejection reasons for a new package."
140 # type: Content of: <chapter><section><title>
142 msgid "Recording changes in the package"
143 msgstr "パッケージの変更を記録する"
145 # type: Content of: <chapter><section><para>
148 "Changes that you make to the package need to be recorded in the "
149 "<filename>debian/changelog</filename>. These changes should provide a "
150 "concise description of what was changed, why (if it's in doubt), and note if "
151 "any bugs were closed. They also record when the package was completed. "
152 "This file will be installed in <filename>/usr/share/doc/"
153 "<replaceable>package</replaceable>/changelog.Debian.gz</filename>, or "
154 "<filename>/usr/share/doc/<replaceable>package</replaceable>/changelog.gz</"
155 "filename> for native packages."
158 # type: Content of: <chapter><section><para>
161 "The <filename>debian/changelog</filename> file conforms to a certain "
162 "structure, with a number of different fields. One field of note, the "
163 "<emphasis>distribution</emphasis>, is described in <xref linkend="
164 "\"distribution\"/> . More information about the structure of this file can "
165 "be found in the Debian Policy section titled <filename>debian/changelog</"
169 # type: Content of: <chapter><section><para>
172 "Changelog entries can be used to automatically close Debian bugs when the "
173 "package is installed into the archive. See <xref linkend=\"upload-bugfix\"/"
177 # type: Content of: <chapter><section><para>
180 "It is conventional that the changelog entry of a package that contains a new "
181 "upstream version of the software looks like this:"
184 # type: Content of: <chapter><section><screen>
189 " * new upstream version\n"
190 msgstr "* new upstream version"
192 # type: Content of: <chapter><section><para>
195 "There are tools to help you create entries and finalize the "
196 "<filename>changelog</filename> for release — see <xref linkend=\"devscripts"
197 "\"/> and <xref linkend=\"dpkg-dev-el\"/> ."
200 # type: Content of: <chapter><section><para>
202 msgid "See also <xref linkend=\"bpp-debian-changelog\"/> ."
203 msgstr "<xref linkend=\"bpp-debian-changelog\"/> も参照してください。"
205 # type: Content of: <chapter><section><title>
207 msgid "Testing the package"
210 # type: Content of: <chapter><section><para>
213 "Before you upload your package, you should do basic testing on it. At a "
214 "minimum, you should try the following activities (you'll need to have an "
215 "older version of the same Debian package around):"
218 # type: Content of: <chapter><section><itemizedlist><listitem><para>
221 "Install the package and make sure the software works, or upgrade the package "
222 "from an older version to your new version if a Debian package for it already "
226 # type: Content of: <chapter><section><itemizedlist><listitem><para>
229 "Run <command>lintian</command> over the package. You can run "
230 "<command>lintian</command> as follows: <literal>lintian -v "
231 "<replaceable>package-version</replaceable>.changes</literal>. This will "
232 "check the source package as well as the binary package. If you don't "
233 "understand the output that <command>lintian</command> generates, try adding "
234 "the <literal>-i</literal> switch, which will cause <command>lintian</"
235 "command> to output a very verbose description of the problem."
238 # type: Content of: <chapter><section><itemizedlist><listitem><para>
241 "Normally, a package should <emphasis>not</emphasis> be uploaded if it causes "
242 "lintian to emit errors (they will start with <literal>E</literal>)."
245 # type: Content of: <chapter><section><itemizedlist><listitem><para>
248 "For more information on <command>lintian</command>, see <xref linkend="
252 # type: Content of: <chapter><section><itemizedlist><listitem><para>
255 "Optionally run <xref linkend=\"debdiff\"/> to analyze changes from an older "
256 "version, if one exists."
259 # type: Content of: <chapter><section><itemizedlist><listitem><para>
262 "Downgrade the package to the previous version (if one exists) — this tests "
263 "the <filename>postrm</filename> and <filename>prerm</filename> scripts."
266 # type: Content of: <chapter><section><itemizedlist><listitem><para>
269 msgid "Remove the package, then reinstall it."
270 msgstr "パッケージを削除して、再インストールしてください。"
272 # type: Content of: <chapter><section><itemizedlist><listitem><para>
275 "Copy the source package in a different directory and try unpacking it and "
276 "rebuilding it. This tests if the package relies on existing files outside "
277 "of it, or if it relies on permissions being preserved on the files shipped "
278 "inside the .diff.gz file."
281 # type: Content of: <chapter><section><title>
284 msgid "Layout of the source package"
287 # type: Content of: <chapter><section><para>
289 msgid "There are two types of Debian source packages:"
290 msgstr "Debian のソースパッケージには 2 種類あります："
292 # type: Content of: <chapter><section><itemizedlist><listitem><para>
295 "the so-called <emphasis>native</emphasis> packages, where there is no "
296 "distinction between the original sources and the patches applied for Debian"
299 # type: Content of: <chapter><section><itemizedlist><listitem><para>
302 "the (more common) packages where there's an original source tarball file "
303 "accompanied by another file that contains the patches applied for Debian"
306 # type: Content of: <chapter><section><para>
309 "For the native packages, the source package includes a Debian source control "
310 "file (<literal>.dsc</literal>) and the source tarball (<literal>.tar.gz</"
311 "literal>). A source package of a non-native package includes a Debian "
312 "source control file, the original source tarball (<literal>.orig.tar.gz</"
313 "literal>) and the Debian patches (<literal>.diff.gz</literal>)."
316 # type: Content of: <chapter><section><para>
319 "Whether a package is native or not is determined when it is built by "
320 "<citerefentry> <refentrytitle>dpkg-buildpackage</refentrytitle> "
321 "<manvolnum>1</manvolnum> </citerefentry>. The rest of this section relates "
322 "only to non-native packages."
325 # type: Content of: <chapter><section><para>
328 "The first time a version is uploaded which corresponds to a particular "
329 "upstream version, the original source tar file should be uploaded and "
330 "included in the <filename>.changes</filename> file. Subsequently, this very "
331 "same tar file should be used to build the new diffs and <filename>.dsc</"
332 "filename> files, and will not need to be re-uploaded."
335 # type: Content of: <chapter><section><para>
338 "By default, <command>dpkg-genchanges</command> and <command>dpkg-"
339 "buildpackage</command> will include the original source tar file if and only "
340 "if the Debian revision part of the source version number is 0 or 1, "
341 "indicating a new upstream version. This behavior may be modified by using "
342 "<literal>-sa</literal> to always include it or <literal>-sd</literal> to "
343 "always leave it out."
346 # type: Content of: <chapter><section><para>
349 "If no original source is included in the upload, the original source tar-"
350 "file used by <command>dpkg-source</command> when constructing the <filename>."
351 "dsc</filename> file and diff to be uploaded <emphasis>must</emphasis> be "
352 "byte-for-byte identical with the one already in the archive."
355 # type: Content of: <chapter><section><para>
358 "Please notice that, in non-native packages, permissions on files that are "
359 "not present in the .orig.tar.gz will not be preserved, as diff does not "
360 "store file permissions in the patch."
363 # type: Content of: <chapter><section><title>
365 msgid "Picking a distribution"
368 # type: Content of: <chapter><section><para>
371 "Each upload needs to specify which distribution the package is intended "
372 "for. The package build process extracts this information from the first "
373 "line of the <filename>debian/changelog</filename> file and places it in the "
374 "<literal>Distribution</literal> field of the <literal>.changes</literal> "
378 # type: Content of: <chapter><section><para>
381 "There are several possible values for this field: `stable', `unstable', "
382 "`testing-proposed-updates' and `experimental'. Normally, packages are "
383 "uploaded into <emphasis>unstable</emphasis>."
386 # type: Content of: <chapter><section><para>
389 "Actually, there are two other possible distributions: `stable-security' and "
390 "`testing-security', but read <xref linkend=\"bug-security\"/> for more "
391 "information on those."
394 # type: Content of: <chapter><section><para>
397 "It is not possible to upload a package into several distributions at the "
401 # type: Content of: <chapter><section><section><title>
403 msgid "Special case: uploads to the <emphasis>stable</emphasis> distribution"
406 # type: Content of: <chapter><section><section><para>
409 "Uploading to <emphasis>stable</emphasis> means that the package will "
410 "transfered to the <emphasis>p-u-new</emphasis>-queue for review by the "
411 "stable release managers, and if approved will be installed in "
412 "<filename>stable-proposed-updates</filename> directory of the Debian "
413 "archive. From there, it will be included in <emphasis>stable</emphasis> "
414 "with the next point release."
417 # type: Content of: <chapter><section><section><para>
420 "Extra care should be taken when uploading to <emphasis>stable</emphasis>. "
421 "Basically, a package should only be uploaded to stable if one of the "
425 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
427 msgid "a truly critical functionality problem"
430 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
432 msgid "the package becomes uninstallable"
435 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
437 msgid "a released architecture lacks the package"
440 # type: Content of: <chapter><section><section><para>
443 "In the past, uploads to <emphasis>stable</emphasis> were used to address "
444 "security problems as well. However, this practice is deprecated, as uploads "
445 "used for Debian security advisories are automatically copied to the "
446 "appropriate <filename>proposed-updates</filename> archive when the advisory "
447 "is released. See <xref linkend=\"bug-security\"/> for detailed information "
448 "on handling security problems."
451 # type: Content of: <chapter><section><section><para>
454 "Changing anything else in the package that isn't important is discouraged, "
455 "because even trivial fixes can cause bugs later on."
458 # type: Content of: <chapter><section><section><para>
461 "Packages uploaded to <emphasis>stable</emphasis> need to be compiled on "
462 "systems running <emphasis>stable</emphasis>, so that their dependencies are "
463 "limited to the libraries (and other packages) available in <emphasis>stable</"
464 "emphasis>; for example, a package uploaded to <emphasis>stable</emphasis> "
465 "that depends on a library package that only exists in unstable will be "
466 "rejected. Making changes to dependencies of other packages (by messing with "
467 "<literal>Provides</literal> or shlibs files), possibly making those other "
468 "packages uninstallable, is strongly discouraged."
471 # type: Content of: <chapter><section><section><para>
474 "The Release Team (which can be reached at &email-debian-release;) will "
475 "regularly evaluate the uploads To <emphasis>stable-proposed-updates</"
476 "emphasis> and decide if your package can be included in <emphasis>stable</"
477 "emphasis>. Please be clear (and verbose, if necessary) in your changelog "
478 "entries for uploads to <emphasis>stable</emphasis>, because otherwise the "
479 "package won't be considered for inclusion."
482 # type: Content of: <chapter><section><section><para>
485 "It's best practice to speak with the stable release manager "
486 "<emphasis>before</emphasis> uploading to <emphasis>stable</emphasis>/"
487 "<emphasis>stable-proposed-updates</emphasis>, so that the uploaded package "
488 "fits the needs of the next point release."
491 # type: Content of: <chapter><section><section><title>
494 "Special case: uploads to <emphasis>testing/testing-proposed-updates</"
498 # type: Content of: <chapter><section><section><para>
501 "Please see the information in the <link linkend=\"t-p-u\">testing section</"
505 # type: Content of: <chapter><section><title>
507 msgid "Uploading a package"
508 msgstr "パッケージをアップロードする"
510 # type: Content of: <chapter><section><section><title>
512 msgid "Uploading to <literal>ftp-master</literal>"
513 msgstr "<literal>ftp-master</literal> にアップロードする"
515 # type: Content of: <chapter><section><section><para>
518 "To upload a package, you should upload the files (including the signed "
519 "changes and dsc-file) with anonymous ftp to <literal>&ftp-master-host;</"
520 "literal> in the directory <ulink url=\"ftp://&ftp-master-host;&upload-queue;"
521 "\">&upload-queue;</ulink>. To get the files processed there, they need to "
522 "be signed with a key in the debian keyring."
525 # type: Content of: <chapter><section><section><para>
528 "Please note that you should transfer the changes file last. Otherwise, your "
529 "upload may be rejected because the archive maintenance software will parse "
530 "the changes file and see that not all files have been uploaded."
533 # type: Content of: <chapter><section><section><para>
536 "You may also find the Debian packages <xref linkend=\"dupload\"/> or <xref "
537 "linkend=\"dput\"/> useful when uploading packages. These handy programs "
538 "help automate the process of uploading packages into Debian."
541 # type: Content of: <chapter><section><section><para>
544 "For removing packages, please see the README file in that ftp directory, and "
545 "the Debian package <xref linkend=\"dcut\"/> ."
548 # type: Content of: <chapter><section><section><title>
550 msgid "Delayed uploads"
553 # type: Content of: <chapter><section><section><para>
556 "Delayed uploads are done for the moment via the delayed queue at gluck. The "
557 "upload-directory is <literal>gluck:~tfheen/DELAYED/[012345678]-day</"
558 "literal>. 0-day is uploaded multiple times per day to ftp-master."
561 # type: Content of: <chapter><section><section><para>
563 msgid "With a fairly recent dput, this section"
566 # type: Content of: <chapter><section><section><screen>
573 "fqdn = gluck.debian.org\n"
574 "incoming = ~tfheen\n"
578 "fqdn = gluck.debian.org\n"
581 # type: Content of: <chapter><section><section><para>
583 msgid "in ~/.dput.cf should work fine for uploading to the DELAYED queue."
586 # type: Content of: <chapter><section><section><para>
589 "<emphasis>Note:</emphasis> Since this upload queue goes to <literal>ftp-"
590 "master</literal>, the prescription found in <xref linkend=\"upload-ftp-master"
591 "\"/> applies here as well."
594 # type: Content of: <chapter><section><section><title>
596 msgid "Security uploads"
597 msgstr "セキュリティアップロード"
599 # type: Content of: <chapter><section><section><para>
602 "Do <emphasis role=\"strong\">NOT</emphasis> upload a package to the security "
603 "upload queue (oldstable-security, stable-security, etc.) without prior "
604 "authorization from the security team. If the package does not exactly meet "
605 "the team's requirements, it will cause many problems and delays in dealing "
606 "with the unwanted upload. For details, please see section <xref linkend="
607 "\"bug-security\"/> ."
610 # type: Content of: <chapter><section><section><title>
612 msgid "Other upload queues"
615 # type: Content of: <chapter><section><section><para>
618 "The scp queues on ftp-master, and security are mostly unusable due to the "
619 "login restrictions on those hosts."
622 # type: Content of: <chapter><section><section><para>
625 "The anonymous queues on ftp.uni-erlangen.de and ftp.uk.debian.org are "
626 "currently down. Work is underway to resurrect them."
629 # type: Content of: <chapter><section><section><para>
632 "The queues on master.debian.org, samosa.debian.org, master.debian.or.jp, and "
633 "ftp.chiark.greenend.org.uk are down permanently, and will not be "
634 "resurrected. The queue in Japan will be replaced with a new queue on hp."
635 "debian.or.jp some day."
638 # type: Content of: <chapter><section><section><para>
641 "For the time being, the anonymous ftp queue on auric.debian.org (the former "
642 "ftp-master) works, but it is deprecated and will be removed at some point in "
646 # type: Content of: <chapter><section><section><title>
648 msgid "Notification that a new package has been installed"
651 # type: Content of: <chapter><section><section><para>
654 "The Debian archive maintainers are responsible for handling package "
655 "uploads. For the most part, uploads are automatically handled on a daily "
656 "basis by the archive maintenance tools, <command>katie</command>. "
657 "Specifically, updates to existing packages to the `unstable' distribution "
658 "are handled automatically. In other cases, notably new packages, placing "
659 "the uploaded package into the distribution is handled manually. When "
660 "uploads are handled manually, the change to the archive may take up to a "
661 "month to occur. Please be patient."
664 # type: Content of: <chapter><section><section><para>
667 "In any case, you will receive an email notification indicating that the "
668 "package has been added to the archive, which also indicates which bugs will "
669 "be closed by the upload. Please examine this notification carefully, "
670 "checking if any bugs you meant to close didn't get triggered."
673 # type: Content of: <chapter><section><section><para>
676 "The installation notification also includes information on what section the "
677 "package was inserted into. If there is a disparity, you will receive a "
678 "separate email notifying you of that. Read on below."
681 # type: Content of: <chapter><section><section><para>
684 "Note that if you upload via queues, the queue daemon software will also send "
685 "you a notification by email."
688 # type: Content of: <chapter><section><title>
690 msgid "Specifying the package section, subsection and priority"
693 # type: Content of: <chapter><section><para>
696 "The <filename>debian/control</filename> file's <literal>Section</literal> "
697 "and <literal>Priority</literal> fields do not actually specify where the "
698 "file will be placed in the archive, nor its priority. In order to retain "
699 "the overall integrity of the archive, it is the archive maintainers who have "
700 "control over these fields. The values in the <filename>debian/control</"
701 "filename> file are actually just hints."
704 # type: Content of: <chapter><section><para>
707 "The archive maintainers keep track of the canonical sections and priorities "
708 "for packages in the <emphasis>override file</emphasis>. If there is a "
709 "disparity between the <emphasis>override file</emphasis> and the package's "
710 "fields as indicated in <filename>debian/control</filename>, then you will "
711 "receive an email noting the divergence when the package is installed into "
712 "the archive. You can either correct your <filename>debian/control</"
713 "filename> file for your next upload, or else you may wish to make a change "
714 "in the <emphasis>override file</emphasis>."
717 # type: Content of: <chapter><section><para>
720 "To alter the actual section that a package is put in, you need to first make "
721 "sure that the <filename>debian/control</filename> file in your package is "
722 "accurate. Next, send an email &email-override; or submit a bug against "
723 "<systemitem role=\"package\">ftp.debian.org</systemitem> requesting that the "
724 "section or priority for your package be changed from the old section or "
725 "priority to the new one. Be sure to explain your reasoning."
728 # type: Content of: <chapter><section><para>
731 "For more information about <emphasis>override files</emphasis>, see "
732 "<citerefentry> <refentrytitle>dpkg-scanpackages</refentrytitle> "
733 "<manvolnum>1</manvolnum> </citerefentry> and <ulink url=\"&url-bts-devel;"
734 "#maintincorrect\"></ulink>."
737 # type: Content of: <chapter><section><para>
740 "Note that the <literal>Section</literal> field describes both the section as "
741 "well as the subsection, which are described in <xref linkend=\"archive-"
742 "sections\"/> . If the section is main, it should be omitted. The list of "
743 "allowable subsections can be found in <ulink url=\"&url-debian-policy;ch-"
744 "archive.html#s-subsections\"></ulink>."
747 # type: Content of: <chapter><section><title>
749 msgid "Handling bugs"
752 # type: Content of: <chapter><section><para>
755 "Every developer has to be able to work with the Debian <ulink url=\"&url-bts;"
756 "\">bug tracking system</ulink>. This includes knowing how to file bug "
757 "reports properly (see <xref linkend=\"submit-bug\"/> ), how to update them "
758 "and reorder them, and how to process and close them."
761 # type: Content of: <chapter><section><para>
764 "The bug tracking system's features are described in the <ulink url=\"&url-"
765 "bts-devel;\">BTS documentation for developers</ulink>. This includes "
766 "closing bugs, sending followup messages, assigning severities and tags, "
767 "marking bugs as forwarded, and other issues."
770 # type: Content of: <chapter><section><para>
773 "Operations such as reassigning bugs to other packages, merging separate bug "
774 "reports about the same issue, or reopening bugs when they are prematurely "
775 "closed, are handled using the so-called control mail server. All of the "
776 "commands available on this server are described in the <ulink url=\"&url-bts-"
777 "control;\">BTS control server documentation</ulink>."
780 # type: Content of: <chapter><section><section><title>
782 msgid "Monitoring bugs"
785 # type: Content of: <chapter><section><section><para>
788 "If you want to be a good maintainer, you should periodically check the "
789 "<ulink url=\"&url-bts;\">Debian bug tracking system (BTS)</ulink> for your "
790 "packages. The BTS contains all the open bugs against your packages. You "
791 "can check them by browsing this page: <literal>http://&bugs-host;/"
792 "<replaceable>yourlogin</replaceable>@debian.org</literal>."
795 # type: Content of: <chapter><section><section><para>
798 "Maintainers interact with the BTS via email addresses at <literal>&bugs-host;"
799 "</literal>. Documentation on available commands can be found at <ulink url="
800 "\"&url-bts;\"></ulink>, or, if you have installed the <systemitem role="
801 "\"package\">doc-debian</systemitem> package, you can look at the local files "
805 # type: Content of: <chapter><section><section><para>
808 "Some find it useful to get periodic reports on open bugs. You can add a "
809 "cron job such as the following if you want to get a weekly email outlining "
810 "all the open bugs against your packages:"
813 # type: Content of: <chapter><section><section><screen>
818 "# ask for weekly reports of bugs in my packages\n"
819 "&cron-bug-report;\n"
822 # type: Content of: <chapter><section><section><para>
825 "Replace <replaceable>address</replaceable> with your official Debian "
826 "maintainer address."
829 # type: Content of: <chapter><section><section><title>
831 msgid "Responding to bugs"
834 # type: Content of: <chapter><section><section><para>
837 "When responding to bugs, make sure that any discussion you have about bugs "
838 "is sent both to the original submitter of the bug, and to the bug itself (e."
839 "g., <email>123@&bugs-host;</email>). If you're writing a new mail and you "
840 "don't remember the submitter email address, you can use the <email>123-"
841 "submitter@&bugs-host;</email> email to contact the submitter <emphasis>and</"
842 "emphasis> to record your mail within the bug log (that means you don't need "
843 "to send a copy of the mail to <email>123@&bugs-host;</email>)."
846 # type: Content of: <chapter><section><section><para>
849 "If you get a bug which mentions FTBFS, this means Fails to build from "
850 "source. Porters frequently use this acronym."
853 # type: Content of: <chapter><section><section><para>
856 "Once you've dealt with a bug report (e.g. fixed it), mark it as "
857 "<emphasis>done</emphasis> (close it) by sending an explanation message to "
858 "<email>123-done@&bugs-host;</email>. If you're fixing a bug by changing and "
859 "uploading the package, you can automate bug closing as described in <xref "
860 "linkend=\"upload-bugfix\"/> ."
863 # type: Content of: <chapter><section><section><para>
866 "You should <emphasis>never</emphasis> close bugs via the bug server "
867 "<literal>close</literal> command sent to &email-bts-control;. If you do so, "
868 "the original submitter will not receive any information about why the bug "
872 # type: Content of: <chapter><section><section><title>
874 msgid "Bug housekeeping"
877 # type: Content of: <chapter><section><section><para>
880 "As a package maintainer, you will often find bugs in other packages or have "
881 "bugs reported against your packages which are actually bugs in other "
882 "packages. The bug tracking system's features are described in the <ulink "
883 "url=\"&url-bts-devel;\">BTS documentation for Debian developers</ulink>. "
884 "Operations such as reassigning, merging, and tagging bug reports are "
885 "described in the <ulink url=\"&url-bts-control;\">BTS control server "
886 "documentation</ulink>. This section contains some guidelines for managing "
887 "your own bugs, based on the collective Debian developer experience."
890 # type: Content of: <chapter><section><section><para>
893 "Filing bugs for problems that you find in other packages is one of the civic "
894 "obligations of maintainership, see <xref linkend=\"submit-bug\"/> for "
895 "details. However, handling the bugs in your own packages is even more "
899 # type: Content of: <chapter><section><section><para>
901 msgid "Here's a list of steps that you may follow to handle a bug report:"
904 # type: Content of: <chapter><section><section><orderedlist><listitem><para>
907 "Decide whether the report corresponds to a real bug or not. Sometimes users "
908 "are just calling a program in the wrong way because they haven't read the "
909 "documentation. If you diagnose this, just close the bug with enough "
910 "information to let the user correct their problem (give pointers to the good "
911 "documentation and so on). If the same report comes up again and again you "
912 "may ask yourself if the documentation is good enough or if the program "
913 "shouldn't detect its misuse in order to give an informative error message. "
914 "This is an issue that may need to be brought up with the upstream author."
917 # type: Content of: <chapter><section><section><orderedlist><listitem><para>
920 "If the bug submitter disagrees with your decision to close the bug, they may "
921 "reopen it until you find an agreement on how to handle it. If you don't "
922 "find any, you may want to tag the bug <literal>wontfix</literal> to let "
923 "people know that the bug exists but that it won't be corrected. If this "
924 "situation is unacceptable, you (or the submitter) may want to require a "
925 "decision of the technical committee by reassigning the bug to <systemitem "
926 "role=\"package\">tech-ctte</systemitem> (you may use the clone command of "
927 "the BTS if you wish to keep it reported against your package). Before doing "
928 "so, please read the <ulink url=\"&url-tech-ctte;\">recommended procedure</"
932 # type: Content of: <chapter><section><section><orderedlist><listitem><para>
935 "If the bug is real but it's caused by another package, just reassign the bug "
936 "to the right package. If you don't know which package it should be "
937 "reassigned to, you should ask for help on <link linkend=\"irc-channels"
938 "\">IRC</link> or on &email-debian-devel;. Please make sure that the "
939 "maintainer(s) of the package the bug is reassigned to know why you "
943 # type: Content of: <chapter><section><section><orderedlist><listitem><para>
946 "Sometimes you also have to adjust the severity of the bug so that it matches "
947 "our definition of the severity. That's because people tend to inflate the "
948 "severity of bugs to make sure their bugs are fixed quickly. Some bugs may "
949 "even be dropped to wishlist severity when the requested change is just "
953 # type: Content of: <chapter><section><section><orderedlist><listitem><para>
956 "If the bug is real but the same problem has already been reported by someone "
957 "else, then the two relevant bug reports should be merged into one using the "
958 "merge command of the BTS. In this way, when the bug is fixed, all of the "
959 "submitters will be informed of this. (Note, however, that emails sent to "
960 "one bug report's submitter won't automatically be sent to the other report's "
961 "submitter.) For more details on the technicalities of the merge command and "
962 "its relative, the unmerge command, see the BTS control server documentation."
965 # type: Content of: <chapter><section><section><orderedlist><listitem><para>
968 "The bug submitter may have forgotten to provide some information, in which "
969 "case you have to ask them for the required information. You may use the "
970 "<literal>moreinfo</literal> tag to mark the bug as such. Moreover if you "
971 "can't reproduce the bug, you tag it <literal>unreproducible</literal>. "
972 "Anyone who can reproduce the bug is then invited to provide more information "
973 "on how to reproduce it. After a few months, if this information has not "
974 "been sent by someone, the bug may be closed."
977 # type: Content of: <chapter><section><section><orderedlist><listitem><para>
980 "If the bug is related to the packaging, you just fix it. If you are not "
981 "able to fix it yourself, then tag the bug as <literal>help</literal>. You "
982 "can also ask for help on &email-debian-devel; or &email-debian-qa;. If it's "
983 "an upstream problem, you have to forward it to the upstream author. "
984 "Forwarding a bug is not enough, you have to check at each release if the bug "
985 "has been fixed or not. If it has, you just close it, otherwise you have to "
986 "remind the author about it. If you have the required skills you can prepare "
987 "a patch that fixes the bug and send it to the author at the same time. Make "
988 "sure to send the patch to the BTS and to tag the bug as <literal>patch</"
992 # type: Content of: <chapter><section><section><orderedlist><listitem><para>
995 "If you have fixed a bug in your local copy, or if a fix has been committed "
996 "to the CVS repository, you may tag the bug as <literal>pending</literal> to "
997 "let people know that the bug is corrected and that it will be closed with "
998 "the next upload (add the <literal>closes:</literal> in the "
999 "<filename>changelog</filename>). This is particularly useful if you are "
1000 "several developers working on the same package."
1003 # type: Content of: <chapter><section><section><orderedlist><listitem><para>
1006 "Once a corrected package is available in the <emphasis>unstable</emphasis> "
1007 "distribution, you can close the bug. This can be done automatically, read "
1008 "<xref linkend=\"upload-bugfix\"/> ."
1011 # type: Content of: <chapter><section><section><title>
1013 msgid "When bugs are closed by new uploads"
1014 msgstr "新規アップロードでバグがクローズされる時"
1016 # type: Content of: <chapter><section><section><para>
1019 "As bugs and problems are fixed in your packages, it is your responsibility "
1020 "as the package maintainer to close these bugs. However, you should not "
1021 "close a bug until the package which fixes the bug has been accepted into the "
1022 "Debian archive. Therefore, once you get notification that your updated "
1023 "package has been installed into the archive, you can and should close the "
1024 "bug in the BTS. Also, the bug should be closed with the correct version."
1027 # type: Content of: <chapter><section><section><para>
1030 "However, it's possible to avoid having to manually close bugs after the "
1031 "upload — just list the fixed bugs in your <filename>debian/changelog</"
1032 "filename> file, following a certain syntax, and the archive maintenance "
1033 "software will close the bugs for you. For example:"
1036 # type: Content of: <chapter><section><section><screen>
1041 "acme-cannon (3.1415) unstable; urgency=low\n"
1043 " * Frobbed with options (closes: Bug#98339)\n"
1044 " * Added safety to prevent operator dismemberment, closes: bug#98765,\n"
1045 " bug#98713, #98714.\n"
1046 " * Added man page. Closes: #98725.\n"
1048 "acme-cannon (3.1415) unstable; urgency=low\n"
1050 " * Frobbed with options (closes: Bug#98339)\n"
1051 " * Added safety to prevent operator dismemberment, closes: bug#98765,\n"
1052 " bug#98713, #98714.\n"
1053 " * Added man page. Closes: #98725."
1055 # type: Content of: <chapter><section><section><para>
1058 "Technically speaking, the following Perl regular expression describes how "
1059 "bug closing changelogs are identified:"
1062 # type: Content of: <chapter><section><section><screen>
1067 " /closes:\\s*(?:bug)?\\#\\s*\\d+(?:,\\s*(?:bug)?\\#\\s*\\d+)*/ig\n"
1068 msgstr "/closes:\\s*(?:bug)?\\#\\s*\\d+(?:,\\s*(?:bug)?\\#\\s*\\d+)*/ig"
1070 # type: Content of: <chapter><section><section><para>
1073 "We prefer the <literal>closes: #<replaceable>XXX</replaceable></literal> "
1074 "syntax, as it is the most concise entry and the easiest to integrate with "
1075 "the text of the <filename>changelog</filename>. Unless specified different "
1076 "by the <replaceable>-v</replaceable>-switch to <command>dpkg-buildpackage</"
1077 "command>, only the bugs closed in the most recent changelog entry are closed "
1078 "(basically, exactly the bugs mentioned in the changelog-part in the "
1079 "<filename>.changes</filename> file are closed)."
1082 # type: Content of: <chapter><section><section><para>
1085 "Historically, uploads identified as <link linkend=\"nmu\">Non-maintainer "
1086 "upload (NMU)</link> were tagged <literal>fixed</literal> instead of being "
1087 "closed, but that practice was ceased with the advent of version-tracking. "
1088 "The same applied to the tag <literal>fixed-in-experimental</literal>."
1091 # type: Content of: <chapter><section><section><para>
1094 "If you happen to mistype a bug number or forget a bug in the changelog "
1095 "entries, don't hesitate to undo any damage the error caused. To reopen "
1096 "wrongly closed bugs, send a <literal>reopen <replaceable>XXX</replaceable></"
1097 "literal> command to the bug tracking system's control address, &email-bts-"
1098 "control;. To close any remaining bugs that were fixed by your upload, email "
1099 "the <filename>.changes</filename> file to <email>XXX-done@&bugs-host;</"
1100 "email>, where <replaceable>XXX</replaceable> is the bug number, and put "
1101 "Version: YYY and an empty line as the first two lines of the body of the "
1102 "email, where <replaceable>YYY</replaceable> is the first version where the "
1103 "bug has been fixed."
1106 # type: Content of: <chapter><section><section><para>
1109 "Bear in mind that it is not obligatory to close bugs using the changelog as "
1110 "described above. If you simply want to close bugs that don't have anything "
1111 "to do with an upload you made, do it by emailing an explanation to "
1112 "<email>XXX-done@&bugs-host;</email>. Do <emphasis role=\"strong\">not</"
1113 "emphasis> close bugs in the changelog entry of a version if the changes in "
1114 "that version of the package don't have any bearing on the bug."
1117 # type: Content of: <chapter><section><section><para>
1120 "For general information on how to write your changelog entries, see <xref "
1121 "linkend=\"bpp-debian-changelog\"/> ."
1124 # type: Content of: <chapter><section><section><title>
1126 msgid "Handling security-related bugs"
1127 msgstr "セキュリティ関連バグの取扱い"
1129 # type: Content of: <chapter><section><section><para>
1132 "Due to their sensitive nature, security-related bugs must be handled "
1133 "carefully. The Debian Security Team exists to coordinate this activity, "
1134 "keeping track of outstanding security problems, helping maintainers with "
1135 "security problems or fixing them themselves, sending security advisories, "
1136 "and maintaining security.debian.org."
1139 # type: Content of: <chapter><section><section><para>
1142 "When you become aware of a security-related bug in a Debian package, whether "
1143 "or not you are the maintainer, collect pertinent information about the "
1144 "problem, and promptly contact the security team at &email-security-team; as "
1145 "soon as possible. <emphasis role=\"strong\">DO NOT UPLOAD</emphasis> any "
1146 "packages for stable; the security team will do that. Useful information "
1147 "includes, for example:"
1150 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
1153 "Which versions of the package are known to be affected by the bug. Check "
1154 "each version that is present in a supported Debian release, as well as "
1155 "testing and unstable."
1158 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
1161 "The nature of the fix, if any is available (patches are especially helpful)"
1164 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
1167 "Any fixed packages that you have prepared yourself (send only the <literal>."
1168 "diff.gz</literal> and <literal>.dsc</literal> files and read <xref linkend="
1169 "\"bug-security-building\"/> first)"
1172 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
1175 "Any assistance you can provide to help with testing (exploits, regression "
1179 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
1182 "Any information needed for the advisory (see <xref linkend=\"bug-security-"
1186 # type: Content of: <chapter><section><section><section><title>
1188 msgid "Confidentiality"
1191 # type: Content of: <chapter><section><section><section><para>
1194 "Unlike most other activities within Debian, information about security "
1195 "issues must sometimes be kept private for a time. This allows software "
1196 "distributors to coordinate their disclosure in order to minimize their "
1197 "users' exposure. Whether this is the case depends on the nature of the "
1198 "problem and corresponding fix, and whether it is already a matter of public "
1202 # type: Content of: <chapter><section><section><section><para>
1204 msgid "There are several ways developers can learn of a security problem:"
1207 # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
1209 msgid "they notice it on a public forum (mailing list, web site, etc.)"
1212 # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
1214 msgid "someone files a bug report"
1217 # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
1219 msgid "someone informs them via private email"
1222 # type: Content of: <chapter><section><section><section><para>
1225 "In the first two cases, the information is public and it is important to "
1226 "have a fix as soon as possible. In the last case, however, it might not be "
1227 "public information. In that case there are a few possible options for "
1228 "dealing with the problem:"
1231 # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
1234 "If the security exposure is minor, there is sometimes no need to keep the "
1235 "problem a secret and a fix should be made and released."
1238 # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
1241 "If the problem is severe, it is preferable to share the information with "
1242 "other vendors and coordinate a release. The security team keeps in contact "
1243 "with the various organizations and individuals and can take care of that."
1246 # type: Content of: <chapter><section><section><section><para>
1249 "In all cases if the person who reports the problem asks that it not be "
1250 "disclosed, such requests should be honored, with the obvious exception of "
1251 "informing the security team in order that a fix may be produced for a stable "
1252 "release of Debian. When sending confidential information to the security "
1253 "team, be sure to mention this fact."
1256 # type: Content of: <chapter><section><section><section><para>
1259 "Please note that if secrecy is needed you may not upload a fix to unstable "
1260 "(or anywhere else, such as a public CVS repository). It is not sufficient "
1261 "to obfuscate the details of the change, as the code itself is public, and "
1262 "can (and will) be examined by the general public."
1265 # type: Content of: <chapter><section><section><section><para>
1268 "There are two reasons for releasing information even though secrecy is "
1269 "requested: the problem has been known for a while, or the problem or exploit "
1270 "has become public."
1273 # type: Content of: <chapter><section><section><section><title>
1275 msgid "Security Advisories"
1278 # type: Content of: <chapter><section><section><section><para>
1281 "Security advisories are only issued for the current, released stable "
1282 "distribution, and <emphasis>not</emphasis> for testing or unstable. When "
1283 "released, advisories are sent to the &email-debian-security-announce; "
1284 "mailing list and posted on <ulink url=\"&url-debian-security-advisories;"
1285 "\">the security web page</ulink>. Security advisories are written and "
1286 "posted by the security team. However they certainly do not mind if a "
1287 "maintainer can supply some of the information for them, or write part of the "
1288 "text. Information that should be in an advisory includes:"
1291 # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
1293 msgid "A description of the problem and its scope, including:"
1296 # type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para>
1298 msgid "The type of problem (privilege escalation, denial of service, etc.)"
1301 # type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para>
1303 msgid "What privileges may be gained, and by whom (if any)"
1306 # type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para>
1308 msgid "How it can be exploited"
1309 msgstr "どのようにして攻撃が可能なのか"
1311 # type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para>
1313 msgid "Whether it is remotely or locally exploitable"
1314 msgstr "攻撃はリモートから可能なのかそれともローカルから可能なのか"
1316 # type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para>
1318 msgid "How the problem was fixed"
1319 msgstr "どのようにして問題が修正されたのか"
1321 # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
1323 msgid "This information allows users to assess the threat to their systems."
1326 # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
1328 msgid "Version numbers of affected packages"
1329 msgstr "影響を受けるパッケージのバージョン番号"
1331 # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
1333 msgid "Version numbers of fixed packages"
1334 msgstr "修正されたパッケージのバージョン番号"
1336 # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
1339 "Information on where to obtain the updated packages (usually from the Debian "
1343 # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
1346 "References to upstream advisories, <ulink url=\"http://cve.mitre.org\">CVE</"
1347 "ulink> identifiers, and any other information useful in cross-referencing "
1351 # type: Content of: <chapter><section><section><section><title>
1353 msgid "Preparing packages to address security issues"
1356 # type: Content of: <chapter><section><section><section><para>
1359 "One way that you can assist the security team in their duties is to provide "
1360 "them with fixed packages suitable for a security advisory for the stable "
1364 # type: Content of: <chapter><section><section><section><para>
1367 "When an update is made to the stable release, care must be taken to avoid "
1368 "changing system behavior or introducing new bugs. In order to do this, make "
1369 "as few changes as possible to fix the bug. Users and administrators rely on "
1370 "the exact behavior of a release once it is made, so any change that is made "
1371 "might break someone's system. This is especially true of libraries: make "
1372 "sure you never change the API or ABI, no matter how small the change."
1375 # type: Content of: <chapter><section><section><section><para>
1378 "This means that moving to a new upstream version is not a good solution. "
1379 "Instead, the relevant changes should be back-ported to the version present "
1380 "in the current stable Debian release. Generally, upstream maintainers are "
1381 "willing to help if needed. If not, the Debian security team may be able to "
1385 # type: Content of: <chapter><section><section><section><para>
1388 "In some cases, it is not possible to back-port a security fix, for example "
1389 "when large amounts of source code need to be modified or rewritten. If this "
1390 "happens, it may be necessary to move to a new upstream version. However, "
1391 "this is only done in extreme situations, and you must always coordinate that "
1392 "with the security team beforehand."
1395 # type: Content of: <chapter><section><section><section><para>
1398 "Related to this is another important guideline: always test your changes. "
1399 "If you have an exploit available, try it and see if it indeed succeeds on "
1400 "the unpatched package and fails on the fixed package. Test other, normal "
1401 "actions as well, as sometimes a security fix can break seemingly unrelated "
1402 "features in subtle ways."
1405 # type: Content of: <chapter><section><section><section><para>
1408 "Do <emphasis role=\"strong\">NOT</emphasis> include any changes in your "
1409 "package which are not directly related to fixing the vulnerability. These "
1410 "will only need to be reverted, and this wastes time. If there are other "
1411 "bugs in your package that you would like to fix, make an upload to proposed-"
1412 "updates in the usual way, after the security advisory is issued. The "
1413 "security update mechanism is not a means for introducing changes to your "
1414 "package which would otherwise be rejected from the stable release, so please "
1415 "do not attempt to do this."
1418 # type: Content of: <chapter><section><section><section><para>
1421 "Review and test your changes as much as possible. Check the differences "
1422 "from the previous version repeatedly (<command>interdiff</command> from the "
1423 "<systemitem role=\"package\">patchutils</systemitem> package and "
1424 "<command>debdiff</command> from <systemitem role=\"package\">devscripts</"
1425 "systemitem> are useful tools for this, see <xref linkend=\"debdiff\"/> )."
1428 # type: Content of: <chapter><section><section><section><para>
1430 msgid "Be sure to verify the following items:"
1433 # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
1436 "Target the right distribution in your <filename>debian/changelog</"
1437 "filename>. For stable this is <literal>stable-security</literal> and for "
1438 "testing this is <literal>testing-security</literal>, and for the previous "
1439 "stable release, this is <literal>oldstable-security</literal>. Do not "
1440 "target <replaceable>distribution</replaceable>-proposed-updates or "
1441 "<literal>stable</literal>!"
1444 # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
1446 msgid "The upload should have urgency=high."
1447 msgstr "アップロードは urgency=high で行う必要があります。"
1449 # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
1452 "Make descriptive, meaningful changelog entries. Others will rely on them to "
1453 "determine whether a particular bug was fixed. Always include an external "
1454 "reference, preferably a CVE identifier, so that it can be cross-referenced. "
1455 "Include the same information in the changelog for unstable, so that it is "
1456 "clear that the same bug was fixed, as this is very helpful when verifying "
1457 "that the bug is fixed in the next stable release. If a CVE identifier has "
1458 "not yet been assigned, the security team will request one so that it can be "
1459 "included in the package and in the advisory."
1462 # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
1465 "Make sure the version number is proper. It must be greater than the current "
1466 "package, but less than package versions in later distributions. If in "
1467 "doubt, test it with <literal>dpkg --compare-versions</literal>. Be careful "
1468 "not to re-use a version number that you have already used for a previous "
1469 "upload. For <emphasis>testing</emphasis>, there must be a higher version in "
1470 "<emphasis>unstable</emphasis>. If there is none yet (for example, if "
1471 "<emphasis>testing</emphasis> and <emphasis>unstable</emphasis> have the same "
1472 "version) you must upload a new version to unstable first."
1475 # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
1478 "Do not make source-only uploads if your package has any binary-all packages "
1479 "(do not use the <literal>-S</literal> option to <command>dpkg-buildpackage</"
1480 "command>). The <command>buildd</command> infrastructure will not build "
1481 "those. This point applies to normal package uploads as well."
1484 # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
1487 "Unless the upstream source has been uploaded to security.debian.org before "
1488 "(by a previous security update), build the upload with full upstream source "
1489 "(<literal>dpkg-buildpackage -sa</literal>). If there has been a previous "
1490 "upload to security.debian.org with the same upstream version, you may upload "
1491 "without upstream source (<literal>dpkg-buildpackage -sd</literal>)."
1494 # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
1497 "Be sure to use the exact same <filename>*.orig.tar.gz</filename> as used in "
1498 "the normal archive, otherwise it is not possible to move the security fix "
1499 "into the main archives later."
1502 # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
1505 "Build the package on a clean system which only has packages installed from "
1506 "the distribution you are building for. If you do not have such a system "
1507 "yourself, you can use a debian.org machine (see <xref linkend=\"server-"
1508 "machines\"/> ) or setup a chroot (see <xref linkend=\"pbuilder\"/> and <xref "
1509 "linkend=\"debootstrap\"/> )."
1512 # type: Content of: <chapter><section><section><section><title>
1514 msgid "Uploading the fixed package"
1517 # type: Content of: <chapter><section><section><section><para>
1520 "Do <emphasis role=\"strong\">NOT</emphasis> upload a package to the security "
1521 "upload queue (oldstable-security, stable-security, etc.) without prior "
1522 "authorization from the security team. If the package does not exactly meet "
1523 "the team's requirements, it will cause many problems and delays in dealing "
1524 "with the unwanted upload."
1527 # type: Content of: <chapter><section><section><section><para>
1530 "Do <emphasis role=\"strong\">NOT</emphasis> upload your fix to proposed-"
1531 "updates without coordinating with the security team. Packages from security."
1532 "debian.org will be copied into the proposed-updates directory "
1533 "automatically. If a package with the same or a higher version number is "
1534 "already installed into the archive, the security update will be rejected by "
1535 "the archive system. That way, the stable distribution will end up without a "
1536 "security update for this package instead."
1539 # type: Content of: <chapter><section><section><section><para>
1542 "Once you have created and tested the new package and it has been approved by "
1543 "the security team, it needs to be uploaded so that it can be installed in "
1544 "the archives. For security uploads, the place to upload to is "
1545 "<literal>ftp://security-master.debian.org/pub/SecurityUploadQueue/</"
1549 # type: Content of: <chapter><section><section><section><para>
1552 "Once an upload to the security queue has been accepted, the package will "
1553 "automatically be rebuilt for all architectures and stored for verification "
1554 "by the security team."
1557 # type: Content of: <chapter><section><section><section><para>
1560 "Uploads which are waiting for acceptance or verification are only accessible "
1561 "by the security team. This is necessary since there might be fixes for "
1562 "security problems that cannot be disclosed yet."
1565 # type: Content of: <chapter><section><section><section><para>
1568 "If a member of the security team accepts a package, it will be installed on "
1569 "security.debian.org as well as proposed for the proper "
1570 "<replaceable>distribution</replaceable>-proposed-updates on ftp-master."
1573 # type: Content of: <chapter><section><title>
1575 msgid "Moving, removing, renaming, adopting, and orphaning packages"
1576 msgstr "パッケージの移動、削除、リネーム、変更、みなしご化"
1578 # type: Content of: <chapter><section><para>
1581 "Some archive manipulation operations are not automated in the Debian upload "
1582 "process. These procedures should be manually followed by maintainers. This "
1583 "chapter gives guidelines on what to do in these cases."
1586 # type: Content of: <chapter><section><section><title>
1588 msgid "Moving packages"
1591 # type: Content of: <chapter><section><section><para><footnote>
1594 "Sometimes a package will change its section. For instance, a package from "
1595 "the `non-free' section might be GPL'd in a later version, in which case the "
1596 "package should be moved to `main' or `contrib'.<footnote>"
1599 # type: Content of: <chapter><section><section><para><footnote><para>
1602 "See the <ulink url=\"&url-debian-policy;\">Debian Policy Manual</ulink> for "
1603 "guidelines on what section a package belongs in."
1606 # type: Content of: <chapter><section><section><section><para>
1607 #: pkgs.dbk:1190 pkgs.dbk:1576
1611 # type: Content of: <chapter><section><section><para>
1614 "If you need to change the section for one of your packages, change the "
1615 "package control information to place the package in the desired section, and "
1616 "re-upload the package (see the <ulink url=\"&url-debian-policy;\">Debian "
1617 "Policy Manual</ulink> for details). You must ensure that you include the "
1618 "<filename>.orig.tar.gz</filename> in your upload (even if you are not "
1619 "uploading a new upstream version), or it will not appear in the new section "
1620 "together with the rest of the package. If your new section is valid, it "
1621 "will be moved automatically. If it does not, then contact the ftpmasters in "
1622 "order to understand what happened."
1625 # type: Content of: <chapter><section><section><para>
1628 "If, on the other hand, you need to change the <emphasis>subsection</"
1629 "emphasis> of one of your packages (e.g., ``devel'', ``admin''), the "
1630 "procedure is slightly different. Correct the subsection as found in the "
1631 "control file of the package, and re-upload that. Also, you'll need to get "
1632 "the override file updated, as described in <xref linkend=\"override-file\"/"
1636 # type: Content of: <chapter><section><section><title>
1638 msgid "Removing packages"
1641 # type: Content of: <chapter><section><section><para>
1644 "If for some reason you want to completely remove a package (say, if it is an "
1645 "old compatibility library which is no longer required), you need to file a "
1646 "bug against <literal>ftp.debian.org</literal> asking that the package be "
1647 "removed; as all bugs, this bug should normally have normal severity. Make "
1648 "sure you indicate which distribution the package should be removed from. "
1649 "Normally, you can only have packages removed from <emphasis>unstable</"
1650 "emphasis> and <emphasis>experimental</emphasis>. Packages are not removed "
1651 "from <emphasis>testing</emphasis> directly. Rather, they will be removed "
1652 "automatically after the package has been removed from <emphasis>unstable</"
1653 "emphasis> and no package in <emphasis>testing</emphasis> depends on it."
1656 # type: Content of: <chapter><section><section><para>
1659 "There is one exception when an explicit removal request is not necessary: If "
1660 "a (source or binary) package is an orphan, it will be removed semi-"
1661 "automatically. For a binary-package, this means if there is no longer any "
1662 "source package producing this binary package; if the binary package is just "
1663 "no longer produced on some architectures, a removal request is still "
1664 "necessary. For a source-package, this means that all binary packages it "
1665 "refers to have been taken over by another source package."
1668 # type: Content of: <chapter><section><section><para>
1671 "In your removal request, you have to detail the reasons justifying the "
1672 "request. This is to avoid unwanted removals and to keep a trace of why a "
1673 "package has been removed. For example, you can provide the name of the "
1674 "package that supersedes the one to be removed."
1677 # type: Content of: <chapter><section><section><para>
1680 "Usually you only ask for the removal of a package maintained by yourself. "
1681 "If you want to remove another package, you have to get the approval of its "
1685 # type: Content of: <chapter><section><section><para>
1688 "Further information relating to these and other package removal related "
1689 "topics may be found at <ulink url=\"http://wiki.debian.org/ftpmaster_Removals"
1690 "\"></ulink> and <ulink url=\"&url-debian-qa;howto-remove.html\"></ulink>."
1693 # type: Content of: <chapter><section><section><para>
1696 "If in doubt concerning whether a package is disposable, email &email-debian-"
1697 "devel; asking for opinions. Also of interest is the <command>apt-cache</"
1698 "command> program from the <systemitem role=\"package\">apt</systemitem> "
1699 "package. When invoked as <literal>apt-cache showpkg <replaceable>package</"
1700 "replaceable></literal>, the program will show details for "
1701 "<replaceable>package</replaceable>, including reverse depends. Other useful "
1702 "programs include <literal>apt-cache rdepends</literal>, <command>apt-"
1703 "rdepends</command> and <command>grep-dctrl</command>. Removal of orphaned "
1704 "packages is discussed on &email-debian-qa;."
1707 # type: Content of: <chapter><section><section><para>
1710 "Once the package has been removed, the package's bugs should be handled. "
1711 "They should either be reassigned to another package in the case where the "
1712 "actual code has evolved into another package (e.g. <literal>libfoo12</"
1713 "literal> was removed because <literal>libfoo13</literal> supersedes it) or "
1714 "closed if the software is simply no longer part of Debian."
1717 # type: Content of: <chapter><section><section><section><title>
1719 msgid "Removing packages from <filename>Incoming</filename>"
1720 msgstr "<filename>Incoming</filename> からパッケージを削除する"
1722 # type: Content of: <chapter><section><section><section><para>
1725 "In the past, it was possible to remove packages from <filename>incoming</"
1726 "filename>. However, with the introduction of the new incoming system, this "
1727 "is no longer possible. Instead, you have to upload a new revision of your "
1728 "package with a higher version than the package you want to replace. Both "
1729 "versions will be installed in the archive but only the higher version will "
1730 "actually be available in <emphasis>unstable</emphasis> since the previous "
1731 "version will immediately be replaced by the higher. However, if you do "
1732 "proper testing of your packages, the need to replace a package should not "
1733 "occur too often anyway."
1736 # type: Content of: <chapter><section><section><title>
1738 msgid "Replacing or renaming packages"
1739 msgstr "パッケージをリプレースあるいはリネームする"
1741 # type: Content of: <chapter><section><section><para>
1744 "When you make a mistake naming your package, you should follow a two-step "
1745 "process to rename it. First, set your <filename>debian/control</filename> "
1746 "file to replace and conflict with the obsolete name of the package (see the "
1747 "<ulink url=\"&url-debian-policy;\">Debian Policy Manual</ulink> for "
1748 "details). Once you've uploaded the package and the package has moved into "
1749 "the archive, file a bug against <literal>ftp.debian.org</literal> asking to "
1750 "remove the package with the obsolete name. Do not forget to properly "
1751 "reassign the package's bugs at the same time."
1754 # type: Content of: <chapter><section><section><para>
1757 "At other times, you may make a mistake in constructing your package and wish "
1758 "to replace it. The only way to do this is to increase the version number "
1759 "and upload a new version. The old version will be expired in the usual "
1760 "manner. Note that this applies to each part of your package, including the "
1761 "sources: if you wish to replace the upstream source tarball of your package, "
1762 "you will need to upload it with a different version. An easy possibility is "
1763 "to replace <filename>foo_1.00.orig.tar.gz</filename> with <filename>foo_1.00"
1764 "+0.orig.tar.gz</filename>. This restriction gives each file on the ftp site "
1765 "a unique name, which helps to ensure consistency across the mirror network."
1768 # type: Content of: <chapter><section><section><title>
1770 msgid "Orphaning a package"
1771 msgstr "パッケージをみなしご化する"
1773 # type: Content of: <chapter><section><section><para>
1776 "If you can no longer maintain a package, you need to inform others, and see "
1777 "that the package is marked as orphaned. You should set the package "
1778 "maintainer to <literal>Debian QA Group &orphan-address;</literal> and submit "
1779 "a bug report against the pseudo package <systemitem role=\"package\">wnpp</"
1780 "systemitem>. The bug report should be titled <literal>O: "
1781 "<replaceable>package</replaceable> -- <replaceable>short description</"
1782 "replaceable></literal> indicating that the package is now orphaned. The "
1783 "severity of the bug should be set to <emphasis>normal</emphasis>; if the "
1784 "package has a priority of standard or higher, it should be set to "
1785 "important. If you feel it's necessary, send a copy to &email-debian-devel; "
1786 "by putting the address in the X-Debbugs-CC: header of the message (no, don't "
1787 "use CC:, because that way the message's subject won't indicate the bug "
1791 # type: Content of: <chapter><section><section><para>
1794 "If you just intend to give the package away, but you can keep maintainership "
1795 "for the moment, then you should instead submit a bug against <systemitem "
1796 "role=\"package\">wnpp</systemitem> and title it <literal>RFA: "
1797 "<replaceable>package</replaceable> -- <replaceable>short description</"
1798 "replaceable></literal>. <literal>RFA</literal> stands for <emphasis>Request "
1799 "For Adoption</emphasis>."
1802 # type: Content of: <chapter><section><section><para>
1805 "More information is on the <ulink url=\"&url-wnpp;\">WNPP web pages</ulink>."
1807 "より詳細な情報は <ulink url=\"&url-wnpp;\">WNPP ウェブページ</ulink>にありま"
1810 # type: Content of: <chapter><section><section><title>
1812 msgid "Adopting a package"
1813 msgstr "パッケージに変更を加える"
1815 # type: Content of: <chapter><section><section><para>
1818 "A list of packages in need of a new maintainer is available in the <ulink "
1819 "url=\"&url-wnpp;\">Work-Needing and Prospective Packages list (WNPP)</"
1820 "ulink>. If you wish to take over maintenance of any of the packages listed "
1821 "in the WNPP, please take a look at the aforementioned page for information "
1825 # type: Content of: <chapter><section><section><para>
1828 "It is not OK to simply take over a package that you feel is neglected — that "
1829 "would be package hijacking. You can, of course, contact the current "
1830 "maintainer and ask them if you may take over the package. If you have "
1831 "reason to believe a maintainer has gone AWOL (absent without leave), see "
1832 "<xref linkend=\"mia-qa\"/> ."
1835 # type: Content of: <chapter><section><section><para>
1838 "Generally, you may not take over the package without the assent of the "
1839 "current maintainer. Even if they ignore you, that is still not grounds to "
1840 "take over a package. Complaints about maintainers should be brought up on "
1841 "the developers' mailing list. If the discussion doesn't end with a positive "
1842 "conclusion, and the issue is of a technical nature, consider bringing it to "
1843 "the attention of the technical committee (see the <ulink url=\"&url-tech-"
1844 "ctte;\">technical committee web page</ulink> for more information)."
1847 # type: Content of: <chapter><section><section><para>
1850 "If you take over an old package, you probably want to be listed as the "
1851 "package's official maintainer in the bug system. This will happen "
1852 "automatically once you upload a new version with an updated "
1853 "<literal>Maintainer:</literal> field, although it can take a few hours after "
1854 "the upload is done. If you do not expect to upload a new version for a "
1855 "while, you can use <xref linkend=\"pkg-tracking-system\"/> to get the bug "
1856 "reports. However, make sure that the old maintainer has no problem with the "
1857 "fact that they will continue to receive the bugs during that time."
1860 # type: Content of: <chapter><section><title>
1862 msgid "Porting and being ported"
1865 # type: Content of: <chapter><section><para>
1868 "Debian supports an ever-increasing number of architectures. Even if you are "
1869 "not a porter, and you don't use any architecture but one, it is part of your "
1870 "duty as a maintainer to be aware of issues of portability. Therefore, even "
1871 "if you are not a porter, you should read most of this chapter."
1874 # type: Content of: <chapter><section><para>
1877 "Porting is the act of building Debian packages for architectures that are "
1878 "different from the original architecture of the package maintainer's binary "
1879 "package. It is a unique and essential activity. In fact, porters do most "
1880 "of the actual compiling of Debian packages. For instance, for a single "
1881 "<emphasis>i386</emphasis> binary package, there must be a recompile for each "
1882 "architecture, which amounts to &number-of-arches; more builds."
1885 # type: Content of: <chapter><section><section><title>
1887 msgid "Being kind to porters"
1890 # type: Content of: <chapter><section><section><para>
1893 "Porters have a difficult and unique task, since they are required to deal "
1894 "with a large volume of packages. Ideally, every source package should build "
1895 "right out of the box. Unfortunately, this is often not the case. This "
1896 "section contains a checklist of ``gotchas'' often committed by Debian "
1897 "maintainers — common problems which often stymie porters, and make their "
1898 "jobs unnecessarily difficult."
1901 # type: Content of: <chapter><section><section><para>
1904 "The first and most important thing is to respond quickly to bug or issues "
1905 "raised by porters. Please treat porters with courtesy, as if they were in "
1906 "fact co-maintainers of your package (which, in a way, they are). Please be "
1907 "tolerant of succinct or even unclear bug reports; do your best to hunt down "
1908 "whatever the problem is."
1911 # type: Content of: <chapter><section><section><para>
1914 "By far, most of the problems encountered by porters are caused by "
1915 "<emphasis>packaging bugs</emphasis> in the source packages. Here is a "
1916 "checklist of things you should check or be aware of."
1919 # type: Content of: <chapter><section><section><orderedlist><listitem><para>
1922 "Make sure that your <literal>Build-Depends</literal> and <literal>Build-"
1923 "Depends-Indep</literal> settings in <filename>debian/control</filename> are "
1924 "set properly. The best way to validate this is to use the <systemitem role="
1925 "\"package\">debootstrap</systemitem> package to create an unstable chroot "
1926 "environment (see <xref linkend=\"debootstrap\"/> ). Within that chrooted "
1927 "environment, install the <systemitem role=\"package\">build-essential</"
1928 "systemitem> package and any package dependencies mentioned in <literal>Build-"
1929 "Depends</literal> and/or <literal>Build-Depends-Indep</literal>. Finally, "
1930 "try building your package within that chrooted environment. These steps can "
1931 "be automated by the use of the <command>pbuilder</command> program which is "
1932 "provided by the package of the same name (see <xref linkend=\"pbuilder\"/> )."
1935 # type: Content of: <chapter><section><section><orderedlist><listitem><para>
1938 "If you can't set up a proper chroot, <command>dpkg-depcheck</command> may be "
1939 "of assistance (see <xref linkend=\"dpkg-depcheck\"/> )."
1942 # type: Content of: <chapter><section><section><orderedlist><listitem><para>
1945 "See the <ulink url=\"&url-debian-policy;\">Debian Policy Manual</ulink> for "
1946 "instructions on setting build dependencies."
1949 # type: Content of: <chapter><section><section><orderedlist><listitem><para>
1952 "Don't set architecture to a value other than ``all'' or ``any'' unless you "
1953 "really mean it. In too many cases, maintainers don't follow the "
1954 "instructions in the <ulink url=\"&url-debian-policy;\">Debian Policy Manual</"
1955 "ulink>. Setting your architecture to ``i386'' is usually incorrect."
1958 # type: Content of: <chapter><section><section><orderedlist><listitem><para>
1961 "Make sure your source package is correct. Do <literal>dpkg-source -x "
1962 "<replaceable>package</replaceable>.dsc</literal> to make sure your source "
1963 "package unpacks properly. Then, in there, try building your package from "
1964 "scratch with <command>dpkg-buildpackage</command>."
1967 # type: Content of: <chapter><section><section><orderedlist><listitem><para>
1970 "Make sure you don't ship your source package with the <filename>debian/"
1971 "files</filename> or <filename>debian/substvars</filename> files. They "
1972 "should be removed by the `clean' target of <filename>debian/rules</filename>."
1975 # type: Content of: <chapter><section><section><orderedlist><listitem><para>
1978 "Make sure you don't rely on locally installed or hacked configurations or "
1979 "programs. For instance, you should never be calling programs in <filename>/"
1980 "usr/local/bin</filename> or the like. Try not to rely on programs being "
1981 "setup in a special way. Try building your package on another machine, even "
1982 "if it's the same architecture."
1985 # type: Content of: <chapter><section><section><orderedlist><listitem><para>
1988 "Don't depend on the package you're building being installed already (a sub-"
1989 "case of the above issue)."
1992 # type: Content of: <chapter><section><section><orderedlist><listitem><para>
1995 "Don't rely on the compiler being a certain version, if possible. If not, "
1996 "then make sure your build dependencies reflect the restrictions, although "
1997 "you are probably asking for trouble, since different architectures sometimes "
1998 "standardize on different compilers."
2001 # type: Content of: <chapter><section><section><orderedlist><listitem><para>
2004 "Make sure your debian/rules contains separate ``binary-arch'' and ``binary-"
2005 "indep'' targets, as the Debian Policy Manual requires. Make sure that both "
2006 "targets work independently, that is, that you can call the target without "
2007 "having called the other before. To test this, try to run <literal>dpkg-"
2008 "buildpackage -B</literal>."
2011 # type: Content of: <chapter><section><section><title>
2013 msgid "Guidelines for porter uploads"
2016 # type: Content of: <chapter><section><section><para>
2019 "If the package builds out of the box for the architecture to be ported to, "
2020 "you are in luck and your job is easy. This section applies to that case; it "
2021 "describes how to build and upload your binary package so that it is properly "
2022 "installed into the archive. If you do have to patch the package in order to "
2023 "get it to compile for the other architecture, you are actually doing a "
2024 "source NMU, so consult <xref linkend=\"nmu-guidelines\"/> instead."
2027 # type: Content of: <chapter><section><section><para>
2030 "For a porter upload, no changes are being made to the source. You do not "
2031 "need to touch any of the files in the source package. This includes "
2032 "<filename>debian/changelog</filename>."
2035 # type: Content of: <chapter><section><section><para>
2038 "The way to invoke <command>dpkg-buildpackage</command> is as <literal>dpkg-"
2039 "buildpackage -B -m<replaceable>porter-email</replaceable></literal>. Of "
2040 "course, set <replaceable>porter-email</replaceable> to your email address. "
2041 "This will do a binary-only build of only the architecture-dependent portions "
2042 "of the package, using the `binary-arch' target in <filename>debian/rules</"
2046 # type: Content of: <chapter><section><section><para>
2049 "If you are working on a Debian machine for your porting efforts and you need "
2050 "to sign your upload locally for its acceptance in the archive, you can run "
2051 "<command>debsign</command> on your <filename>.changes</filename> file to "
2052 "have it signed conveniently, or use the remote signing mode of <command>dpkg-"
2056 # type: Content of: <chapter><section><section><section><title>
2058 msgid "Recompilation or binary-only NMU"
2061 # type: Content of: <chapter><section><section><section><para>
2064 "Sometimes the initial porter upload is problematic because the environment "
2065 "in which the package was built was not good enough (outdated or obsolete "
2066 "library, bad compiler, ...). Then you may just need to recompile it in an "
2067 "updated environment. However, you have to bump the version number in this "
2068 "case, so that the old bad package can be replaced in the Debian archive "
2069 "(<command>katie</command> refuses to install new packages if they don't have "
2070 "a version number greater than the currently available one)."
2073 # type: Content of: <chapter><section><section><section><para>
2076 "You have to make sure that your binary-only NMU doesn't render the package "
2077 "uninstallable. This could happen when a source package generates arch-"
2078 "dependent and arch-independent packages that depend on each other via "
2079 "$(Source-Version)."
2082 # type: Content of: <chapter><section><section><section><para>
2085 "Despite the required modification of the changelog, these are called binary-"
2086 "only NMUs — there is no need in this case to trigger all other architectures "
2087 "to consider themselves out of date or requiring recompilation."
2090 # type: Content of: <chapter><section><section><section><para>
2093 "Such recompilations require special ``magic'' version numbering, so that the "
2094 "archive maintenance tools recognize that, even though there is a new Debian "
2095 "version, there is no corresponding source update. If you get this wrong, "
2096 "the archive maintainers will reject your upload (due to lack of "
2097 "corresponding source code)."
2100 # type: Content of: <chapter><section><section><section><para><footnote>
2103 "The ``magic'' for a recompilation-only NMU is triggered by using a suffix "
2104 "appended to the package version number, following the form b<number>. "
2105 "For instance, if the latest version you are recompiling against was version "
2106 "``2.9-3'', your NMU should carry a version of ``2.9-3+b1''. If the latest "
2107 "version was ``3.4+b1'' (i.e, a native package with a previous recompilation "
2108 "NMU), your NMU should have a version number of ``3.4+b2''. <footnote>"
2111 # type: Content of: <chapter><section><section><section><para><footnote><para>
2114 "In the past, such NMUs used the third-level number on the Debian part of the "
2115 "revision to denote their recompilation-only status; however, this syntax was "
2116 "ambiguous with native packages and did not allow proper ordering of "
2117 "recompile-only NMUs, source NMUs, and security NMUs on the same package, and "
2118 "has therefore been abandoned in favor of this new syntax."
2121 # type: Content of: <chapter><section><section><section><para>
2124 "Similar to initial porter uploads, the correct way of invoking <command>dpkg-"
2125 "buildpackage</command> is <literal>dpkg-buildpackage -B</literal> to only "
2126 "build the architecture-dependent parts of the package."
2129 # type: Content of: <chapter><section><section><section><title>
2131 msgid "When to do a source NMU if you are a porter"
2134 # type: Content of: <chapter><section><section><section><para>
2137 "Porters doing a source NMU generally follow the guidelines found in <xref "
2138 "linkend=\"nmu\"/> , just like non-porters. However, it is expected that the "
2139 "wait cycle for a porter's source NMU is smaller than for a non-porter, since "
2140 "porters have to cope with a large quantity of packages. Again, the "
2141 "situation varies depending on the distribution they are uploading to. It "
2142 "also varies whether the architecture is a candidate for inclusion into the "
2143 "next stable release; the release managers decide and announce which "
2144 "architectures are candidates."
2147 # type: Content of: <chapter><section><section><section><para>
2150 "If you are a porter doing an NMU for `unstable', the above guidelines for "
2151 "porting should be followed, with two variations. Firstly, the acceptable "
2152 "waiting period — the time between when the bug is submitted to the BTS and "
2153 "when it is OK to do an NMU — is seven days for porters working on the "
2154 "unstable distribution. This period can be shortened if the problem is "
2155 "critical and imposes hardship on the porting effort, at the discretion of "
2156 "the porter group. (Remember, none of this is Policy, just mutually agreed "
2157 "upon guidelines.) For uploads to stable or testing, please coordinate with "
2158 "the appropriate release team first."
2161 # type: Content of: <chapter><section><section><section><para>
2164 "Secondly, porters doing source NMUs should make sure that the bug they "
2165 "submit to the BTS should be of severity `serious' or greater. This ensures "
2166 "that a single source package can be used to compile every supported Debian "
2167 "architecture by release time. It is very important that we have one version "
2168 "of the binary and source package for all architecture in order to comply "
2169 "with many licenses."
2172 # type: Content of: <chapter><section><section><section><para>
2175 "Porters should try to avoid patches which simply kludge around bugs in the "
2176 "current version of the compile environment, kernel, or libc. Sometimes such "
2177 "kludges can't be helped. If you have to kludge around compiler bugs and the "
2178 "like, make sure you <literal>#ifdef</literal> your work properly; also, "
2179 "document your kludge so that people know to remove it once the external "
2180 "problems have been fixed."
2183 # type: Content of: <chapter><section><section><section><para>
2186 "Porters may also have an unofficial location where they can put the results "
2187 "of their work during the waiting period. This helps others running the port "
2188 "have the benefit of the porter's work, even during the waiting period. Of "
2189 "course, such locations have no official blessing or status, so buyer beware."
2192 # type: Content of: <chapter><section><section><title>
2194 msgid "Porting infrastructure and automation"
2197 # type: Content of: <chapter><section><section><para>
2200 "There is infrastructure and several tools to help automate package porting. "
2201 "This section contains a brief overview of this automation and porting to "
2202 "these tools; see the package documentation or references for full "
2206 # type: Content of: <chapter><section><section><section><title>
2208 msgid "Mailing lists and web pages"
2209 msgstr "メーリングリストとウェブページ"
2211 # type: Content of: <chapter><section><section><section><para>
2214 "Web pages containing the status of each port can be found at <ulink url="
2215 "\"&url-debian-ports;\"></ulink>."
2218 # type: Content of: <chapter><section><section><section><para>
2221 "Each port of Debian has a mailing list. The list of porting mailing lists "
2222 "can be found at <ulink url=\"&url-debian-port-lists;\"></ulink>. These "
2223 "lists are used to coordinate porters, and to connect the users of a given "
2224 "port with the porters."
2227 # type: Content of: <chapter><section><section><section><title>
2229 msgid "Porter tools"
2232 # type: Content of: <chapter><section><section><section><para>
2235 "Descriptions of several porting tools can be found in <xref linkend=\"tools-"
2239 # type: Content of: <chapter><section><section><section><title>
2241 msgid "<systemitem role=\"package\">buildd</systemitem>"
2244 # type: Content of: <chapter><section><section><section><para>
2247 "The <systemitem role=\"package\">buildd</systemitem> system is used as a "
2248 "distributed, client-server build distribution system. It is usually used in "
2249 "conjunction with <emphasis>auto-builders</emphasis>, which are ``slave'' "
2250 "hosts which simply check out and attempt to auto-build packages which need "
2251 "to be ported. There is also an email interface to the system, which allows "
2252 "porters to ``check out'' a source package (usually one which cannot yet be "
2253 "auto-built) and work on it."
2256 # type: Content of: <chapter><section><section><section><para>
2259 "<systemitem role=\"package\">buildd</systemitem> is not yet available as a "
2260 "package; however, most porting efforts are either using it currently or "
2261 "planning to use it in the near future. The actual automated builder is "
2262 "packaged as <systemitem role=\"package\">sbuild</systemitem>, see its "
2263 "description in <xref linkend=\"sbuild\"/> . The complete <systemitem role="
2264 "\"package\">buildd</systemitem> system also collects a number of as yet "
2265 "unpackaged components which are currently very useful and in use "
2266 "continually, such as <command>andrea</command> and <command>wanna-build</"
2270 # type: Content of: <chapter><section><section><section><para>
2273 "Some of the data produced by <systemitem role=\"package\">buildd</"
2274 "systemitem> which is generally useful to porters is available on the web at "
2275 "<ulink url=\"&url-buildd;\"></ulink>. This data includes nightly updated "
2276 "information from <command>andrea</command> (source dependencies) and "
2277 "<systemitem role=\"package\">quinn-diff</systemitem> (packages needing "
2281 # type: Content of: <chapter><section><section><section><para>
2284 "We are quite proud of this system, since it has so many possible uses. "
2285 "Independent development groups can use the system for different sub-flavors "
2286 "of Debian, which may or may not really be of general interest (for instance, "
2287 "a flavor of Debian built with <command>gcc</command> bounds checking). It "
2288 "will also enable Debian to recompile entire distributions quickly."
2291 # type: Content of: <chapter><section><section><section><para>
2294 "The buildds admins of each arch can be contacted at the mail address "
2295 "$arch@buildd.debian.org."
2298 # type: Content of: <chapter><section><section><title>
2300 msgid "When your package is <emphasis>not</emphasis> portable"
2303 # type: Content of: <chapter><section><section><para>
2306 "Some packages still have issues with building and/or working on some of the "
2307 "architectures supported by Debian, and cannot be ported at all, or not "
2308 "within a reasonable amount of time. An example is a package that is SVGA-"
2309 "specific (only i386), or uses other hardware-specific features not supported "
2310 "on all architectures."
2313 # type: Content of: <chapter><section><section><para>
2316 "In order to prevent broken packages from being uploaded to the archive, and "
2317 "wasting buildd time, you need to do a few things:"
2320 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
2323 "First, make sure your package <emphasis>does</emphasis> fail to build on "
2324 "architectures that it cannot support. There are a few ways to achieve "
2325 "this. The preferred way is to have a small testsuite during build time that "
2326 "will test the functionality, and fail if it doesn't work. This is a good "
2327 "idea anyway, as this will prevent (some) broken uploads on all "
2328 "architectures, and also will allow the package to build as soon as the "
2329 "required functionality is available."
2332 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
2335 "Additionally, if you believe the list of supported architectures is pretty "
2336 "constant, you should change 'any' to a list of supported architectures in "
2337 "debian/control. This way, the build will fail also, and indicate this to a "
2338 "human reader without actually trying."
2341 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
2344 "In order to prevent autobuilders from needlessly trying to build your "
2345 "package, it must be included in <filename>packages-arch-specific</filename>, "
2346 "a list used by the <command>wanna-build</command> script. The current "
2347 "version is available as <ulink url=\"&url-cvsweb;srcdep/Packages-arch-"
2348 "specific?cvsroot=dak\"></ulink>; please see the top of the file for whom to "
2349 "contact for changes."
2352 # type: Content of: <chapter><section><section><para>
2355 "Please note that it is insufficient to only add your package to Packages-"
2356 "arch-specific without making it fail to build on unsupported architectures: "
2357 "A porter or any other person trying to build your package might accidently "
2358 "upload it without noticing it doesn't work. If in the past some binary "
2359 "packages were uploaded on unsupported architectures, request their removal "
2360 "by filing a bug against <systemitem role=\"package\">ftp.debian.org</"
2364 # type: Content of: <chapter><section><title>
2366 msgid "Non-Maintainer Uploads (NMUs)"
2369 # type: Content of: <chapter><section><para>
2372 "Under certain circumstances it is necessary for someone other than the "
2373 "official package maintainer to make a release of a package. This is called "
2374 "a non-maintainer upload, or NMU."
2377 # type: Content of: <chapter><section><para>
2380 "This section handles only source NMUs, i.e. NMUs which upload a new version "
2381 "of the package. For binary-only NMUs by porters or QA members, please see "
2382 "<xref linkend=\"binary-only-nmu\"/> . If a buildd builds and uploads a "
2383 "package, that too is strictly speaking a binary NMU. See <xref linkend="
2384 "\"buildd\"/> for some more information."
2387 # type: Content of: <chapter><section><para>
2390 "The main reason why NMUs are done is when a developer needs to fix another "
2391 "developer's package in order to address serious problems or crippling bugs "
2392 "or when the package maintainer is unable to release a fix in a timely "
2396 # type: Content of: <chapter><section><para>
2399 "First and foremost, it is critical that NMU patches to source should be as "
2400 "non-disruptive as possible. Do not do housekeeping tasks, do not change the "
2401 "name of modules or files, do not move directories; in general, do not fix "
2402 "things which are not broken. Keep the patch as small as possible. If "
2403 "things bother you aesthetically, talk to the Debian maintainer, talk to the "
2404 "upstream maintainer, or submit a bug. However, aesthetic changes must "
2405 "<emphasis>not</emphasis> be made in a non-maintainer upload."
2408 # type: Content of: <chapter><section><para>
2411 "And please remember the Hippocratic Oath: Above all, do no harm. It is "
2412 "better to leave a package with an open grave bug than applying a non-"
2413 "functional patch, or one that hides the bug instead of resolving it."
2416 # type: Content of: <chapter><section><section><title>
2418 msgid "How to do a NMU"
2421 # type: Content of: <chapter><section><section><para>
2424 "NMUs which fix important, serious or higher severity bugs are encouraged and "
2425 "accepted. You should endeavor to reach the current maintainer of the "
2426 "package; they might be just about to upload a fix for the problem, or have a "
2430 # type: Content of: <chapter><section><section><para>
2433 "NMUs should be made to assist a package's maintainer in resolving bugs. "
2434 "Maintainers should be thankful for that help, and NMUers should respect the "
2435 "decisions of maintainers, and try to personally help the maintainer by their "
2439 # type: Content of: <chapter><section><section><para>
2442 "A NMU should follow all conventions, written down in this section. For an "
2443 "upload to testing or unstable, this order of steps is recommended:"
2446 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
2449 "Make sure that the package's bugs that the NMU is meant to address are all "
2450 "filed in the Debian Bug Tracking System (BTS). If they are not, submit them "
2454 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
2457 "Wait a few days for the response from the maintainer. If you don't get any "
2458 "response, you may want to help them by sending the patch that fixes the "
2459 "bug. Don't forget to tag the bug with the patch keyword."
2462 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
2465 "Wait a few more days. If you still haven't got an answer from the "
2466 "maintainer, send them a mail announcing your intent to NMU the package. "
2467 "Prepare an NMU as described in this section, and test it carefully on your "
2468 "machine (cf. <xref linkend=\"sanitycheck\"/> ). Double check that your "
2469 "patch doesn't have any unexpected side effects. Make sure your patch is as "
2470 "small and as non-disruptive as it can be."
2473 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
2476 "Upload your package to incoming in <filename>DELAYED/7-day</filename> (cf. "
2477 "<xref linkend=\"delayed-incoming\"/> ), send the final patch to the "
2478 "maintainer via the BTS, and explain to them that they have 7 days to react "
2479 "if they want to cancel the NMU."
2482 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
2485 "Follow what happens, you're responsible for any bug that you introduced with "
2486 "your NMU. You should probably use <xref linkend=\"pkg-tracking-system\"/> "
2487 "(PTS) to stay informed of the state of the package after your NMU."
2490 # type: Content of: <chapter><section><section><para>
2493 "At times, the release manager or an organized group of developers can "
2494 "announce a certain period of time in which the NMU rules are relaxed. This "
2495 "usually involves shortening the period during which one is to wait before "
2496 "uploading the fixes, and shortening the DELAYED period. It is important to "
2497 "notice that even in these so-called bug squashing party times, the NMU'er "
2498 "has to file bugs and contact the developer first, and act later. Please see "
2499 "<xref linkend=\"qa-bsp\"/> for details."
2502 # type: Content of: <chapter><section><section><para>
2505 "For the testing distribution, the rules may be changed by the release "
2506 "managers. Please take additional care, and acknowledge that the usual way "
2507 "for a package to enter testing is through unstable."
2510 # type: Content of: <chapter><section><section><para>
2513 "For the stable distribution, please take extra care. Of course, the release "
2514 "managers may also change the rules here. Please verify before you upload "
2515 "that all your changes are OK for inclusion into the next stable release by "
2516 "the release manager."
2519 # type: Content of: <chapter><section><section><para>
2522 "When a security bug is detected, the security team may do an NMU, using "
2523 "their own rules. Please refer to <xref linkend=\"bug-security\"/> for more "
2527 # type: Content of: <chapter><section><section><para>
2530 "For the differences for Porters NMUs, please see <xref linkend=\"source-nmu-"
2534 # type: Content of: <chapter><section><section><para>
2537 "Of course, it is always possible to agree on special rules with a maintainer "
2538 "(like the maintainer asking please upload this fix directly for me, and no "
2542 # type: Content of: <chapter><section><section><title>
2544 msgid "NMU version numbering"
2547 # type: Content of: <chapter><section><section><para>
2550 "Whenever you have made a change to a package, no matter how trivial, the "
2551 "version number needs to change. This enables our packing system to function."
2554 # type: Content of: <chapter><section><section><para>
2557 "If you are doing a non-maintainer upload (NMU), you should add a new minor "
2558 "version number to the <replaceable>debian-revision</replaceable> part of the "
2559 "version number (the portion after the last hyphen). This extra minor number "
2560 "will start at `1'. For example, consider the package `foo', which is at "
2561 "version 1.1-3. In the archive, the source package control file would be "
2562 "<filename>foo_1.1-3.dsc</filename>. The upstream version is `1.1' and the "
2563 "Debian revision is `3'. The next NMU would add a new minor number `.1' to "
2564 "the Debian revision; the new source control file would be <filename>foo_1.1-"
2565 "3.1.dsc</filename>."
2568 # type: Content of: <chapter><section><section><para>
2571 "The Debian revision minor number is needed to avoid stealing one of the "
2572 "package maintainer's version numbers, which might disrupt their work. It "
2573 "also has the benefit of making it visually clear that a package in the "
2574 "archive was not made by the official maintainer."
2577 # type: Content of: <chapter><section><section><para>
2580 "If there is no <replaceable>debian-revision</replaceable> component in the "
2581 "version number then one should be created, starting at `0.1' (but in case of "
2582 "a debian native package still upload it as native package). If it is "
2583 "absolutely necessary for someone other than the usual maintainer to make a "
2584 "release based on a new upstream version then the person making the release "
2585 "should start with the <replaceable>debian-revision</replaceable> value "
2586 "`0.1'. The usual maintainer of a package should start their "
2587 "<replaceable>debian-revision</replaceable> numbering at `1'."
2590 # type: Content of: <chapter><section><section><para>
2593 "If you upload a package to testing or stable, sometimes, you need to fork "
2594 "the version number tree. For this, version numbers like 1.1-3sarge0.1 could "
2598 # type: Content of: <chapter><section><section><title>
2600 msgid "Source NMUs must have a new changelog entry"
2603 # type: Content of: <chapter><section><section><para>
2606 "Anyone who is doing a source NMU must create a changelog entry, describing "
2607 "which bugs are fixed by the NMU, and generally why the NMU was required and "
2608 "what it fixed. The changelog entry will have the email address of the "
2609 "person who uploaded it in the log entry and the NMU version number in it."
2612 # type: Content of: <chapter><section><section><para>
2614 msgid "By convention, source NMU changelog entries start with the line"
2617 # type: Content of: <chapter><section><section><screen>
2622 " * Non-maintainer upload\n"
2623 msgstr "* Non-maintainer upload"
2625 # type: Content of: <chapter><section><section><title>
2627 msgid "Source NMUs and the Bug Tracking System"
2630 # type: Content of: <chapter><section><section><para>
2633 "Maintainers other than the official package maintainer should make as few "
2634 "changes to the package as possible, and they should always send a patch as a "
2635 "unified context diff (<literal>diff -u</literal>) detailing their changes to "
2636 "the Bug Tracking System."
2639 # type: Content of: <chapter><section><section><para>
2642 "What if you are simply recompiling the package? If you just need to "
2643 "recompile it for a single architecture, then you may do a binary-only NMU as "
2644 "described in <xref linkend=\"binary-only-nmu\"/> which doesn't require any "
2645 "patch to be sent. If you want the package to be recompiled for all "
2646 "architectures, then you do a source NMU as usual and you will have to send a "
2650 # type: Content of: <chapter><section><section><para>
2653 "Bugs fixed by source NMUs used to be tagged fixed instead of closed, but "
2654 "since version tracking is in place, such bugs are now also closed with the "
2658 # type: Content of: <chapter><section><section><para>
2661 "Also, after doing an NMU, you have to send the information to the existing "
2662 "bugs that are fixed by your NMU, including the unified diff. Historically, "
2663 "it was custom to open a new bug and include a patch showing all the changes "
2664 "you have made. The normal maintainer will either apply the patch or employ "
2665 "an alternate method of fixing the problem. Sometimes bugs are fixed "
2666 "independently upstream, which is another good reason to back out an NMU's "
2667 "patch. If the maintainer decides not to apply the NMU's patch but to "
2668 "release a new version, the maintainer needs to ensure that the new upstream "
2669 "version really fixes each problem that was fixed in the non-maintainer "
2673 # type: Content of: <chapter><section><section><para>
2676 "In addition, the normal maintainer should <emphasis>always</emphasis> retain "
2677 "the entry in the changelog file documenting the non-maintainer upload -- and "
2678 "of course, also keep the changes. If you revert some of the changes, please "
2679 "reopen the relevant bug reports."
2682 # type: Content of: <chapter><section><section><title>
2684 msgid "Building source NMUs"
2687 # type: Content of: <chapter><section><section><para>
2690 "Source NMU packages are built normally. Pick a distribution using the same "
2691 "rules as found in <xref linkend=\"distribution\"/> , follow the other "
2692 "instructions in <xref linkend=\"upload\"/> ."
2695 # type: Content of: <chapter><section><section><para>
2698 "Make sure you do <emphasis>not</emphasis> change the value of the maintainer "
2699 "in the <filename>debian/control</filename> file. Your name as given in the "
2700 "NMU entry of the <filename>debian/changelog</filename> file will be used for "
2701 "signing the changes file."
2704 # type: Content of: <chapter><section><section><title>
2706 msgid "Acknowledging an NMU"
2709 # type: Content of: <chapter><section><section><para>
2712 "If one of your packages has been NMU'ed, you have to incorporate the changes "
2713 "in your copy of the sources. This is easy, you just have to apply the patch "
2714 "that has been sent to you. Once this is done, you have to close the bugs "
2715 "that have been tagged fixed by the NMU. The easiest way is to use the "
2716 "<literal>-v</literal> option of <command>dpkg-buildpackage</command>, as "
2717 "this allows you to include just all changes since your last maintainer "
2718 "upload. Alternatively, you can close them manually by sending the required "
2719 "mails to the BTS or by adding the required <literal>closes: #nnnn</literal> "
2720 "in the changelog entry of your next upload."
2723 # type: Content of: <chapter><section><section><para>
2726 "In any case, you should not be upset by the NMU. An NMU is not a personal "
2727 "attack against the maintainer. It is a proof that someone cares enough "
2728 "about the package that they were willing to help you in your work, so you "
2729 "should be thankful. You may also want to ask them if they would be "
2730 "interested in helping you on a more frequent basis as co-maintainer or "
2731 "backup maintainer (see <xref linkend=\"collaborative-maint\"/> )."
2734 # type: Content of: <chapter><section><section><title>
2736 msgid "NMU vs QA uploads"
2739 # type: Content of: <chapter><section><section><para>
2742 "Unless you know the maintainer is still active, it is wise to check the "
2743 "package to see if it has been orphaned. The current list of orphaned "
2744 "packages which haven't had their maintainer set correctly is available at "
2745 "<ulink url=\"&url-debian-qa-orphaned;\"></ulink>. If you perform an NMU on "
2746 "an improperly orphaned package, please set the maintainer to <literal>Debian "
2747 "QA Group <packages@qa.debian.org></literal>."
2750 # type: Content of: <chapter><section><section><title>
2752 msgid "Who can do an NMU"
2753 msgstr "誰が NMU 可能なのか"
2755 # type: Content of: <chapter><section><section><para>
2758 "Only official, registered Debian Developers can do binary or source NMUs. A "
2759 "Debian Developer is someone who has their key in the Debian key ring. Non-"
2760 "developers, however, are encouraged to download the source package and start "
2761 "hacking on it to fix problems; however, rather than doing an NMU, they "
2762 "should just submit worthwhile patches to the Bug Tracking System. "
2763 "Maintainers almost always appreciate quality patches and bug reports."
2766 # type: Content of: <chapter><section><section><title>
2771 # type: Content of: <chapter><section><section><para>
2774 "There are two new terms used throughout this section: ``binary-only NMU'' "
2775 "and ``source NMU''. These terms are used with specific technical meaning "
2776 "throughout this document. Both binary-only and source NMUs are similar, "
2777 "since they involve an upload of a package by a developer who is not the "
2778 "official maintainer of that package. That is why it's a <emphasis>non-"
2779 "maintainer</emphasis> upload."
2782 # type: Content of: <chapter><section><section><para>
2785 "A source NMU is an upload of a package by a developer who is not the "
2786 "official maintainer, for the purposes of fixing a bug in the package. "
2787 "Source NMUs always involves changes to the source (even if it is just a "
2788 "change to <filename>debian/changelog</filename>). This can be either a "
2789 "change to the upstream source, or a change to the Debian bits of the "
2790 "source. Note, however, that source NMUs may also include architecture-"
2791 "dependent packages, as well as an updated Debian diff."
2794 # type: Content of: <chapter><section><section><para>
2797 "A binary-only NMU is a recompilation and upload of a binary package for a "
2798 "given architecture. As such, it is usually part of a porting effort. A "
2799 "binary-only NMU is a non-maintainer uploaded binary version of a package, "
2800 "with no source changes required. There are many cases where porters must "
2801 "fix problems in the source in order to get them to compile for their target "
2802 "architecture; that would be considered a source NMU rather than a binary-"
2803 "only NMU. As you can see, we don't distinguish in terminology between "
2804 "porter NMUs and non-porter NMUs."
2807 # type: Content of: <chapter><section><section><para>
2810 "Both classes of NMUs, source and binary-only, can be lumped under the term "
2811 "``NMU''. However, this often leads to confusion, since most people think "
2812 "``source NMU'' when they think ``NMU''. So it's best to be careful: always "
2813 "use ``binary NMU'' or ``binNMU'' for binary-only NMUs."
2816 # type: Content of: <chapter><section><title>
2818 msgid "Collaborative maintenance"
2821 # type: Content of: <chapter><section><para>
2824 "Collaborative maintenance is a term describing the sharing of Debian package "
2825 "maintenance duties by several people. This collaboration is almost always a "
2826 "good idea, since it generally results in higher quality and faster bug fix "
2827 "turnaround times. It is strongly recommended that packages with a priority "
2828 "of <literal>Standard</literal> or which are part of the base set have co-"
2832 # type: Content of: <chapter><section><para>
2835 "Generally there is a primary maintainer and one or more co-maintainers. The "
2836 "primary maintainer is the person whose name is listed in the "
2837 "<literal>Maintainer</literal> field of the <filename>debian/control</"
2838 "filename> file. Co-maintainers are all the other maintainers."
2841 # type: Content of: <chapter><section><para>
2844 "In its most basic form, the process of adding a new co-maintainer is quite "
2848 # type: Content of: <chapter><section><itemizedlist><listitem><para>
2851 "Setup the co-maintainer with access to the sources you build the package "
2852 "from. Generally this implies you are using a network-capable version "
2853 "control system, such as <command>CVS</command> or <command>Subversion</"
2854 "command>. Alioth (see <xref linkend=\"alioth\"/> ) provides such tools, "
2858 # type: Content of: <chapter><section><itemizedlist><listitem><para>
2861 "Add the co-maintainer's correct maintainer name and address to the "
2862 "<literal>Uploaders</literal> field in the global part of the "
2863 "<filename>debian/control</filename> file."
2866 # type: Content of: <chapter><section><itemizedlist><listitem><screen>
2871 "Uploaders: John Buzz <jbuzz@debian.org>, Adam Rex <arex@debian.org>\n"
2872 msgstr "Uploaders: John Buzz <jbuzz@debian.org>, Adam Rex <arex@debian.org>"
2874 # type: Content of: <chapter><section><itemizedlist><listitem><para>
2877 "Using the PTS (<xref linkend=\"pkg-tracking-system\"/> ), the co-maintainers "
2878 "should subscribe themselves to the appropriate source package."
2881 # type: Content of: <chapter><section><para>
2884 "Another form of collaborative maintenance is team maintenance, which is "
2885 "recommended if you maintain several packages with the same group of "
2886 "developers. In that case, the Maintainer and Uploaders field of each "
2887 "package must be managed with care. It is recommended to choose between one "
2888 "of the two following schemes:"
2891 # type: Content of: <chapter><section><orderedlist><listitem><para>
2894 "Put the team member mainly responsible for the package in the Maintainer "
2895 "field. In the Uploaders, put the mailing list address, and the team members "
2896 "who care for the package."
2899 # type: Content of: <chapter><section><orderedlist><listitem><para>
2902 "Put the mailing list address in the Maintainer field. In the Uploaders "
2903 "field, put the team members who care for the package. In this case, you "
2904 "must make sure the mailing list accept bug reports without any human "
2905 "interaction (like moderation for non-subscribers)."
2908 # type: Content of: <chapter><section><para>
2911 "In any case, it is a bad idea to automatically put all team members in the "
2912 "Uploaders field. It clutters the Developer's Package Overview listing (see "
2913 "<xref linkend=\"ddpo\"/> ) with packages one doesn't really care for, and "
2914 "creates a false sense of good maintenance."
2917 # type: Content of: <chapter><section><title>
2919 msgid "The testing distribution"
2920 msgstr "テスト版ディストリビューション"
2922 # type: Content of: <chapter><section><section><title>
2927 # type: Content of: <chapter><section><section><para>
2930 "Packages are usually installed into the `testing' distribution after they "
2931 "have undergone some degree of testing in unstable."
2934 # type: Content of: <chapter><section><section><para>
2937 "They must be in sync on all architectures and mustn't have dependencies that "
2938 "make them uninstallable; they also have to have generally no known release-"
2939 "critical bugs at the time they're installed into testing. This way, "
2940 "`testing' should always be close to being a release candidate. Please see "
2941 "below for details."
2944 # type: Content of: <chapter><section><section><title>
2946 msgid "Updates from unstable"
2949 # type: Content of: <chapter><section><section><para>
2952 "The scripts that update the <emphasis>testing</emphasis> distribution are "
2953 "run each day after the installation of the updated packages; these scripts "
2954 "are called <emphasis>britney</emphasis>. They generate the "
2955 "<filename>Packages</filename> files for the <emphasis>testing</emphasis> "
2956 "distribution, but they do so in an intelligent manner; they try to avoid any "
2957 "inconsistency and to use only non-buggy packages."
2960 # type: Content of: <chapter><section><section><para>
2963 "The inclusion of a package from <emphasis>unstable</emphasis> is conditional "
2967 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
2970 "The package must have been available in <emphasis>unstable</emphasis> for 2, "
2971 "5 or 10 days, depending on the urgency (high, medium or low). Please note "
2972 "that the urgency is sticky, meaning that the highest urgency uploaded since "
2973 "the previous testing transition is taken into account. Those delays may be "
2974 "doubled during a freeze, or testing transitions may be switched off "
2978 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
2981 "It must have the same number or fewer release-critical bugs than the version "
2982 "currently available in <emphasis>testing</emphasis>;"
2985 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
2988 "It must be available on all architectures on which it has previously been "
2989 "built in unstable. <xref linkend=\"madison\"/> may be of interest to check "
2993 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
2996 "It must not break any dependency of a package which is already available in "
2997 "<emphasis>testing</emphasis>;"
3000 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
3003 "The packages on which it depends must either be available in "
3004 "<emphasis>testing</emphasis> or they must be accepted into "
3005 "<emphasis>testing</emphasis> at the same time (and they will be if they "
3006 "fulfill all the necessary criteria);"
3009 # type: Content of: <chapter><section><section><para>
3012 "To find out whether a package is progressing into testing or not, see the "
3013 "testing script output on the <ulink url=\"&url-testing-maint;\">web page of "
3014 "the testing distribution</ulink>, or use the program <command>grep-excuses</"
3015 "command> which is in the <systemitem role=\"package\">devscripts</"
3016 "systemitem> package. This utility can easily be used in a <citerefentry> "
3017 "<refentrytitle>crontab</refentrytitle> <manvolnum>5</manvolnum> </"
3018 "citerefentry> to keep yourself informed of the progression of your packages "
3019 "into <emphasis>testing</emphasis>."
3022 # type: Content of: <chapter><section><section><para>
3025 "The <filename>update_excuses</filename> file does not always give the "
3026 "precise reason why the package is refused; you may have to find it on your "
3027 "own by looking for what would break with the inclusion of the package. The "
3028 "<ulink url=\"&url-testing-maint;\">testing web page</ulink> gives some more "
3029 "information about the usual problems which may be causing such troubles."
3032 # type: Content of: <chapter><section><section><para>
3035 "Sometimes, some packages never enter <emphasis>testing</emphasis> because "
3036 "the set of inter-relationship is too complicated and cannot be sorted out by "
3037 "the scripts. See below for details."
3040 # type: Content of: <chapter><section><section><para>
3043 "Some further dependency analysis is shown on <ulink url=\"http://bjorn.haxx."
3044 "se/debian/\"></ulink> — but be warned, this page also shows build "
3045 "dependencies which are not considered by britney."
3048 # type: Content of: <chapter><section><section><section><title>
3053 # type: Content of: <chapter><section><section><section><para>
3054 #. FIXME: better rename this file than document rampant professionalism?
3057 "For the testing migration script, outdated means: There are different "
3058 "versions in unstable for the release architectures (except for the "
3059 "architectures in fuckedarches; fuckedarches is a list of architectures that "
3060 "don't keep up (in update_out.py), but currently, it's empty). outdated has "
3061 "nothing whatsoever to do with the architectures this package has in testing."
3064 # type: Content of: <chapter><section><section><section><para>
3066 msgid "Consider this example:"
3069 # type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry>
3070 #: pkgs.dbk:2277 pkgs.dbk:2308
3074 # type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry>
3075 #: pkgs.dbk:2278 pkgs.dbk:2309
3079 # type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry>
3080 #: pkgs.dbk:2283 pkgs.dbk:2315 pkgs.dbk:2375
3084 # type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
3085 #: pkgs.dbk:2284 pkgs.dbk:2289 pkgs.dbk:2316 pkgs.dbk:2317 pkgs.dbk:2324
3089 # type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
3090 #: pkgs.dbk:2285 pkgs.dbk:2318 pkgs.dbk:2323
3094 # type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry>
3095 #: pkgs.dbk:2288 pkgs.dbk:2321 pkgs.dbk:2376
3099 # type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
3100 #: pkgs.dbk:2290 pkgs.dbk:2322
3104 # type: Content of: <chapter><section><section><section><para>
3107 "The package is out of date on alpha in unstable, and will not go to "
3108 "testing. And removing foo from testing would not help at all, the package "
3109 "is still out of date on alpha, and will not propagate to testing."
3112 # type: Content of: <chapter><section><section><section><para>
3114 msgid "However, if ftp-master removes a package in unstable (here on arm):"
3117 # type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry>
3122 # type: Content of: <chapter><section><section><section><para>
3125 "In this case, the package is up to date on all release architectures in "
3126 "unstable (and the extra hurd-i386 doesn't matter, as it's not a release "
3130 # type: Content of: <chapter><section><section><section><para>
3133 "Sometimes, the question is raised if it is possible to allow packages in "
3134 "that are not yet built on all architectures: No. Just plainly no. (Except "
3135 "if you maintain glibc or so.)"
3138 # type: Content of: <chapter><section><section><section><title>
3140 msgid "Removals from testing"
3143 # type: Content of: <chapter><section><section><section><para>
3146 "Sometimes, a package is removed to allow another package in: This happens "
3147 "only to allow <emphasis>another</emphasis> package to go in if it's ready in "
3148 "every other sense. Suppose e.g. that <emphasis>a</emphasis> cannot be "
3149 "installed with the new version of <emphasis>b</emphasis>; then <emphasis>a</"
3150 "emphasis> may be removed to allow <emphasis>b</emphasis> in."
3153 # type: Content of: <chapter><section><section><section><para>
3156 "Of course, there is another reason to remove a package from testing: It's "
3157 "just too buggy (and having a single RC-bug is enough to be in this state)."
3160 # type: Content of: <chapter><section><section><section><para>
3163 "Furthermore, if a package has been removed from unstable, and no package in "
3164 "testing depends on it any more, then it will automatically be removed."
3167 # type: Content of: <chapter><section><section><section><title>
3169 msgid "circular dependencies"
3172 # type: Content of: <chapter><section><section><section><para>
3175 "A situation which is not handled very well by britney is if package "
3176 "<emphasis>a</emphasis> depends on the new version of package <emphasis>b</"
3177 "emphasis>, and vice versa."
3180 # type: Content of: <chapter><section><section><section><para>
3182 msgid "An example of this is:"
3185 # type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
3190 # type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
3192 msgid "1; depends: b=1"
3193 msgstr "1; depends: b=1"
3195 # type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
3197 msgid "2; depends: b=2"
3198 msgstr "2; depends: b=2"
3200 # type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
3205 # type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
3207 msgid "1; depends: a=1"
3208 msgstr "1; depends: a=1"
3210 # type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
3212 msgid "2; depends: a=2"
3213 msgstr "2; depends: a=2"
3215 # type: Content of: <chapter><section><section><section><para>
3218 "Neither package <emphasis>a</emphasis> nor package <emphasis>b</emphasis> is "
3219 "considered for update."
3222 # type: Content of: <chapter><section><section><section><para>
3225 "Currently, this requires some manual hinting from the release team. Please "
3226 "contact them by sending mail to &email-debian-release; if this happens to "
3227 "one of your packages."
3230 # type: Content of: <chapter><section><section><section><title>
3232 msgid "influence of package in testing"
3233 msgstr "テスト版パッケージへの影響"
3235 # type: Content of: <chapter><section><section><section><para>
3238 "Generally, there is nothing that the status of a package in testing means "
3239 "for transition of the next version from unstable to testing, with two "
3240 "exceptions: If the RC-bugginess of the package goes down, it may go in even "
3241 "if it is still RC-buggy. The second exception is if the version of the "
3242 "package in testing is out of sync on the different arches: Then any arch "
3243 "might just upgrade to the version of the source package; however, this can "
3244 "happen only if the package was previously forced through, the arch is in "
3245 "fuckedarches, or there was no binary package of that arch present in "
3246 "unstable at all during the testing migration."
3249 # type: Content of: <chapter><section><section><section><para>
3252 "In summary this means: The only influence that a package being in testing "
3253 "has on a new version of the same package is that the new version might go in "
3257 # type: Content of: <chapter><section><section><section><title>
3262 # type: Content of: <chapter><section><section><section><para>
3264 msgid "If you are interested in details, this is how britney works:"
3267 # type: Content of: <chapter><section><section><section><para>
3270 "The packages are looked at to determine whether they are valid candidates. "
3271 "This gives the update excuses. The most common reasons why a package is not "
3272 "considered are too young, RC-bugginess, and out of date on some arches. For "
3273 "this part of britney, the release managers have hammers of various sizes to "
3274 "force britney to consider a package. (Also, the base freeze is coded in "
3275 "that part of britney.) (There is a similar thing for binary-only updates, "
3276 "but this is not described here. If you're interested in that, please peruse "
3280 # type: Content of: <chapter><section><section><section><para>
3283 "Now, the more complex part happens: Britney tries to update testing with the "
3284 "valid candidates; first, each package alone, and then larger and even larger "
3285 "sets of packages together. Each try is accepted if testing is not more "
3286 "uninstallable after the update than before. (Before and after this part, "
3287 "some hints are processed; but as only release masters can hint, this is "
3288 "probably not so important for you.)"
3291 # type: Content of: <chapter><section><section><section><para>
3294 "If you want to see more details, you can look it up on merkel:/org/&ftp-"
3295 "debian-org;/testing/update_out/ (or there in ~aba/testing/update_out to see "
3296 "a setup with a smaller packages file). Via web, it's at <ulink url=\"http://"
3297 "&ftp-master-host;/testing/update_out_code/\"></ulink>"
3300 # type: Content of: <chapter><section><section><section><para>
3303 "The hints are available via <ulink url=\"http://&ftp-master-host;/testing/"
3304 "hints/\"></ulink>."
3307 # type: Content of: <chapter><section><section><title>
3309 msgid "Direct updates to testing"
3310 msgstr "直接テスト版を更新する"
3312 # type: Content of: <chapter><section><section><para>
3315 "The testing distribution is fed with packages from unstable according to the "
3316 "rules explained above. However, in some cases, it is necessary to upload "
3317 "packages built only for testing. For that, you may want to upload to "
3318 "<emphasis>testing-proposed-updates</emphasis>."
3321 # type: Content of: <chapter><section><section><para>
3324 "Keep in mind that packages uploaded there are not automatically processed, "
3325 "they have to go through the hands of the release manager. So you'd better "
3326 "have a good reason to upload there. In order to know what a good reason is "
3327 "in the release managers' eyes, you should read the instructions that they "
3328 "regularly give on &email-debian-devel-announce;."
3331 # type: Content of: <chapter><section><section><para>
3334 "You should not upload to <emphasis>testing-proposed-updates</emphasis> when "
3335 "you can update your packages through <emphasis>unstable</emphasis>. If you "
3336 "can't (for example because you have a newer development version in "
3337 "unstable), you may use this facility, but it is recommended that you ask for "
3338 "authorization from the release manager first. Even if a package is frozen, "
3339 "updates through unstable are possible, if the upload via unstable does not "
3340 "pull in any new dependencies."
3343 # type: Content of: <chapter><section><section><para>
3346 "Version numbers are usually selected by adding the codename of the testing "
3347 "distribution and a running number, like 1.2sarge1 for the first upload "
3348 "through testing-proposed-updates of package version 1.2."
3351 # type: Content of: <chapter><section><section><para>
3353 msgid "Please make sure you didn't miss any of these items in your upload:"
3356 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
3359 "Make sure that your package really needs to go through <emphasis>testing-"
3360 "proposed-updates</emphasis>, and can't go through unstable;"
3363 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
3365 msgid "Make sure that you included only the minimal amount of changes;"
3368 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
3371 "Make sure that you included an appropriate explanation in the changelog;"
3374 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
3377 "Make sure that you've written <emphasis>testing</emphasis> or "
3378 "<emphasis>testing-proposed-updates</emphasis> into your target distribution;"
3381 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
3384 "Make sure that you've built and tested your package in <emphasis>testing</"
3385 "emphasis>, not in <emphasis>unstable</emphasis>;"
3388 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
3391 "Make sure that your version number is higher than the version in "
3392 "<emphasis>testing</emphasis> and <emphasis>testing-proposed-updates</"
3393 "emphasis>, and lower than in <emphasis>unstable</emphasis>;"
3396 # type: Content of: <chapter><section><section><itemizedlist><listitem><para>
3399 "After uploading and successful build on all platforms, contact the release "
3400 "team at &email-debian-release; and ask them to approve your upload."
3403 # type: Content of: <chapter><section><section><title>
3405 msgid "Frequently asked questions"
3408 # type: Content of: <chapter><section><section><section><title>
3410 msgid "What are release-critical bugs, and how do they get counted?"
3413 # type: Content of: <chapter><section><section><section><para>
3416 "All bugs of some higher severities are by default considered release-"
3417 "critical; currently, these are critical, grave, and serious bugs."
3420 # type: Content of: <chapter><section><section><section><para>
3423 "Such bugs are presumed to have an impact on the chances that the package "
3424 "will be released with the stable release of Debian: in general, if a package "
3425 "has open release-critical bugs filed on it, it won't get into testing, and "
3426 "consequently won't be released in stable."
3429 # type: Content of: <chapter><section><section><section><para>
3432 "The unstable bug count are all release-critical bugs without either any "
3433 "release-tag (such as potato, woody) or with release-tag sid; also, only if "
3434 "they are neither fixed nor set to sarge-ignore. The testing bug count for a "
3435 "package is considered to be roughly the bug count of unstable count at the "
3436 "last point when the testing version equalled the unstable version."
3439 # type: Content of: <chapter><section><section><section><para>
3442 "This will change post-sarge, as soon as we have versions in the bug tracking "
3446 # type: Content of: <chapter><section><section><section><title>
3449 "How could installing a package into testing possibly break other packages?"
3452 # type: Content of: <chapter><section><section><section><para>
3455 "The structure of the distribution archives is such that they can only "
3456 "contain one version of a package; a package is defined by its name. So when "
3457 "the source package acmefoo is installed into testing, along with its binary "
3458 "packages acme-foo-bin, acme-bar-bin, libacme-foo1 and libacme-foo-dev, the "
3459 "old version is removed."
3462 # type: Content of: <chapter><section><section><section><para>
3465 "However, the old version may have provided a binary package with an old "
3466 "soname of a library, such as libacme-foo0. Removing the old acmefoo will "
3467 "remove libacme-foo0, which will break any packages which depend on it."
3470 # type: Content of: <chapter><section><section><section><para>
3473 "Evidently, this mainly affects packages which provide changing sets of "
3474 "binary packages in different versions (in turn, mainly libraries). However, "
3475 "it will also affect packages upon which versioned dependencies have been "
3476 "declared of the ==, <=, or << varieties."
3479 # type: Content of: <chapter><section><section><section><para>
3482 "When the set of binary packages provided by a source package change in this "
3483 "way, all the packages that depended on the old binaries will have to be "
3484 "updated to depend on the new binaries instead. Because installing such a "
3485 "source package into testing breaks all the packages that depended on it in "
3486 "testing, some care has to be taken now: all the depending packages must be "
3487 "updated and ready to be installed themselves so that they won't be broken, "
3488 "and, once everything is ready, manual intervention by the release manager or "
3489 "an assistant is normally required."
3492 # type: Content of: <chapter><section><section><section><para>
3495 "If you are having problems with complicated groups of packages like this, "
3496 "contact debian-devel or debian-release for help."
~ianmdlvl / developers-reference.git / blob