#: pkgs.dbk:7 msgid "Managing Packages" msgstr "" # type: Content of: <chapter><para> #: pkgs.dbk:9 msgid "" "This chapter contains information related to creating, uploading, " "maintaining, and porting packages." msgstr "" # type: Content of: <chapter><section><title> #: pkgs.dbk:13 msgid "New packages" msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:15 msgid "" "If you want to create a new package for the Debian distribution, you should " "first check the <ulink url=\"&url-wnpp;\">Work-Needing and Prospective " "Packages (WNPP)</ulink> list. Checking the WNPP list ensures that no one is " "already working on packaging that software, and that effort is not " "duplicated. Read the <ulink url=\"&url-wnpp;\">WNPP web pages</ulink> for " "more information." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:23 msgid "" "Assuming no one else is already working on your prospective package, you " "must then submit a bug report (<xref linkend=\"submit-bug\"/> ) against the " "pseudo-package <systemitem role=\"package\">wnpp</systemitem> describing " "your plan to create a new package, including, but not limiting yourself to, " "a description of the package, the license of the prospective package, and " "the current URL where it can be downloaded from." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:31 msgid "" "You should set the subject of the bug to ``ITP: " "<replaceable>foo</replaceable> -- <replaceable>short " "description</replaceable>'', substituting the name of the new package for " "<replaceable>foo</replaceable>. The severity of the bug report must be set " "to <emphasis>wishlist</emphasis>. If you feel it's necessary, send a copy " "to &email-debian-devel; by putting the address in the " "<literal>X-Debbugs-CC:</literal> header of the message (no, don't use " "<literal>CC:</literal>, because that way the message's subject won't " "indicate the bug number)." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:41 msgid "" "Please include a <literal>Closes: " "bug#<replaceable>nnnnn</replaceable></literal> entry in the changelog of the " "new package in order for the bug report to be automatically closed once the " "new package is installed in the archive (see <xref " "linkend=\"upload-bugfix\"/> )." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:47 msgid "" "When closing security bugs include CVE numbers as well as the Closes: " "#nnnnn. This is useful for the security team to track vulnerabilities. If " "an upload is made to fix the bug before the advisory ID is known, it is " "encouraged to modify the historical changelog entry with the next upload. " "Even in this case, please include all available pointers to background " "information in the original changelog entry." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:55 msgid "" "There are a number of reasons why we ask maintainers to announce their " "intentions:" msgstr "" # type: Content of: <chapter><section><itemizedlist><listitem><para> #: pkgs.dbk:61 msgid "" "It helps the (potentially new) maintainer to tap into the experience of " "people on the list, and lets them know if anyone else is working on it " "already." msgstr "" # type: Content of: <chapter><section><itemizedlist><listitem><para> #: pkgs.dbk:67 msgid "" "It lets other people thinking about working on the package know that there " "already is a volunteer, so efforts may be shared." msgstr "" # type: Content of: <chapter><section><itemizedlist><listitem><para> #: pkgs.dbk:73 msgid "" "It lets the rest of the maintainers know more about the package than the one " "line description and the usual changelog entry ``Initial release'' that gets " "posted to <literal>debian-devel-changes</literal>." msgstr "" # type: Content of: <chapter><section><itemizedlist><listitem><para> #: pkgs.dbk:80 msgid "" "It is helpful to the people who live off unstable (and form our first line " "of testers). We should encourage these people." msgstr "" # type: Content of: <chapter><section><itemizedlist><listitem><para> #: pkgs.dbk:86 msgid "" "The announcements give maintainers and other interested parties a better " "feel of what is going on, and what is new, in the project." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:92 msgid "" "Please see <ulink url=\"http://&ftp-master-host;/REJECT-FAQ.html\"></ulink> " "for common rejection reasons for a new package." msgstr "" # type: Content of: <chapter><section><title> #: pkgs.dbk:98 msgid "Recording changes in the package" msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:100 msgid "" "Changes that you make to the package need to be recorded in the " "<filename>debian/changelog</filename>. These changes should provide a " "concise description of what was changed, why (if it's in doubt), and note if " "any bugs were closed. They also record when the package was completed. " "This file will be installed in " "<filename>/usr/share/doc/<replaceable>package</replaceable>/changelog.Debian.gz</filename>, " "or " "<filename>/usr/share/doc/<replaceable>package</replaceable>/changelog.gz</filename> " "for native packages." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:111 msgid "" "The <filename>debian/changelog</filename> file conforms to a certain " "structure, with a number of different fields. One field of note, the " "<emphasis>distribution</emphasis>, is described in <xref " "linkend=\"distribution\"/> . More information about the structure of this " "file can be found in the Debian Policy section titled " "<filename>debian/changelog</filename>." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:119 msgid "" "Changelog entries can be used to automatically close Debian bugs when the " "package is installed into the archive. See <xref " "linkend=\"upload-bugfix\"/> ." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:123 msgid "" "It is conventional that the changelog entry of a package that contains a new " "upstream version of the software looks like this:" msgstr "" # type: Content of: <chapter><section><screen> #: pkgs.dbk:127 #, no-wrap msgid "* new upstream version" msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:130 msgid "" "There are tools to help you create entries and finalize the " "<filename>changelog</filename> for release — see <xref " "linkend=\"devscripts\"/> and <xref linkend=\"dpkg-dev-el\"/> ." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:135 msgid "See also <xref linkend=\"bpp-debian-changelog\"/> ." msgstr "" # type: Content of: <chapter><section><title> #: pkgs.dbk:140 msgid "Testing the package" msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:142 msgid "" "Before you upload your package, you should do basic testing on it. At a " "minimum, you should try the following activities (you'll need to have an " "older version of the same Debian package around):" msgstr "" # type: Content of: <chapter><section><itemizedlist><listitem><para> #: pkgs.dbk:149 msgid "" "Install the package and make sure the software works, or upgrade the package " "from an older version to your new version if a Debian package for it already " "exists." msgstr "" # type: Content of: <chapter><section><itemizedlist><listitem><para> #: pkgs.dbk:156 msgid "" "Run <command>lintian</command> over the package. You can run " "<command>lintian</command> as follows: <literal>lintian -v " "<replaceable>package-version</replaceable>.changes</literal>. This will " "check the source package as well as the binary package. If you don't " "understand the output that <command>lintian</command> generates, try adding " "the <literal>-i</literal> switch, which will cause " "<command>lintian</command> to output a very verbose description of the " "problem." msgstr "" # type: Content of: <chapter><section><itemizedlist><listitem><para> #: pkgs.dbk:165 msgid "" "Normally, a package should <emphasis>not</emphasis> be uploaded if it causes " "lintian to emit errors (they will start with <literal>E</literal>)." msgstr "" # type: Content of: <chapter><section><itemizedlist><listitem><para> #: pkgs.dbk:169 msgid "" "For more information on <command>lintian</command>, see <xref " "linkend=\"lintian\"/> ." msgstr "" # type: Content of: <chapter><section><itemizedlist><listitem><para> #: pkgs.dbk:175 msgid "" "Optionally run <xref linkend=\"debdiff\"/> to analyze changes from an older " "version, if one exists." msgstr "" # type: Content of: <chapter><section><itemizedlist><listitem><para> #: pkgs.dbk:181 msgid "" "Downgrade the package to the previous version (if one exists) — this tests " "the <filename>postrm</filename> and <filename>prerm</filename> scripts." msgstr "" # type: Content of: <chapter><section><itemizedlist><listitem><para> #: pkgs.dbk:187 msgid "Remove the package, then reinstall it." msgstr "" # type: Content of: <chapter><section><itemizedlist><listitem><para> #: pkgs.dbk:192 msgid "" "Copy the source package in a different directory and try unpacking it and " "rebuilding it. This tests if the package relies on existing files outside " "of it, or if it relies on permissions being preserved on the files shipped " "inside the .diff.gz file." msgstr "" # type: Content of: <chapter><section><title> #: pkgs.dbk:202 msgid "Layout of the source package" msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:204 msgid "There are two types of Debian source packages:" msgstr "" # type: Content of: <chapter><section><itemizedlist><listitem><para> #: pkgs.dbk:209 msgid "" "the so-called <emphasis>native</emphasis> packages, where there is no " "distinction between the original sources and the patches applied for Debian" msgstr "" # type: Content of: <chapter><section><itemizedlist><listitem><para> #: pkgs.dbk:215 msgid "" "the (more common) packages where there's an original source tarball file " "accompanied by another file that contains the patches applied for Debian" msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:221 msgid "" "For the native packages, the source package includes a Debian source control " "file (<literal>.dsc</literal>) and the source tarball " "(<literal>.tar.gz</literal>). A source package of a non-native package " "includes a Debian source control file, the original source tarball " "(<literal>.orig.tar.gz</literal>) and the Debian patches " "(<literal>.diff.gz</literal>)." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:229 msgid "" "Whether a package is native or not is determined when it is built by " "<citerefentry> <refentrytitle>dpkg-buildpackage</refentrytitle> " "<manvolnum>1</manvolnum> </citerefentry>. The rest of this section relates " "only to non-native packages." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:235 msgid "" "The first time a version is uploaded which corresponds to a particular " "upstream version, the original source tar file should be uploaded and " "included in the <filename>.changes</filename> file. Subsequently, this very " "same tar file should be used to build the new diffs and " "<filename>.dsc</filename> files, and will not need to be re-uploaded." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:242 msgid "" "By default, <command>dpkg-genchanges</command> and " "<command>dpkg-buildpackage</command> will include the original source tar " "file if and only if the Debian revision part of the source version number is " "0 or 1, indicating a new upstream version. This behavior may be modified by " "using <literal>-sa</literal> to always include it or <literal>-sd</literal> " "to always leave it out." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:250 msgid "" "If no original source is included in the upload, the original source " "tar-file used by <command>dpkg-source</command> when constructing the " "<filename>.dsc</filename> file and diff to be uploaded " "<emphasis>must</emphasis> be byte-for-byte identical with the one already in " "the archive." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:257 msgid "" "Please notice that, in non-native packages, permissions on files that are " "not present in the .orig.tar.gz will not be preserved, as diff does not " "store file permissions in the patch." msgstr "" # type: Content of: <chapter><section><title> #: pkgs.dbk:264 msgid "Picking a distribution" msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:266 msgid "" "Each upload needs to specify which distribution the package is intended " "for. The package build process extracts this information from the first " "line of the <filename>debian/changelog</filename> file and places it in the " "<literal>Distribution</literal> field of the <literal>.changes</literal> " "file." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:272 msgid "" "There are several possible values for this field: `stable', `unstable', " "`testing-proposed-updates' and `experimental'. Normally, packages are " "uploaded into <emphasis>unstable</emphasis>." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:277 msgid "" "Actually, there are two other possible distributions: `stable-security' and " "`testing-security', but read <xref linkend=\"bug-security\"/> for more " "information on those." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:282 msgid "" "It is not possible to upload a package into several distributions at the " "same time." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:286 msgid "Special case: uploads to the <emphasis>stable</emphasis> distribution" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:288 msgid "" "Uploading to <emphasis>stable</emphasis> means that the package will " "transfered to the <emphasis>p-u-new</emphasis>-queue for review by the " "stable release managers, and if approved will be installed in " "<filename>stable-proposed-updates</filename> directory of the Debian " "archive. From there, it will be included in <emphasis>stable</emphasis> " "with the next point release." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:296 msgid "" "Extra care should be taken when uploading to <emphasis>stable</emphasis>. " "Basically, a package should only be uploaded to stable if one of the " "following happens:" msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:303 msgid "a truly critical functionality problem" msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:308 msgid "the package becomes uninstallable" msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:313 msgid "a released architecture lacks the package" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:318 msgid "" "In the past, uploads to <emphasis>stable</emphasis> were used to address " "security problems as well. However, this practice is deprecated, as uploads " "used for Debian security advisories are automatically copied to the " "appropriate <filename>proposed-updates</filename> archive when the advisory " "is released. See <xref linkend=\"bug-security\"/> for detailed information " "on handling security problems." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:326 msgid "" "Changing anything else in the package that isn't important is discouraged, " "because even trivial fixes can cause bugs later on." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:330 msgid "" "Packages uploaded to <emphasis>stable</emphasis> need to be compiled on " "systems running <emphasis>stable</emphasis>, so that their dependencies are " "limited to the libraries (and other packages) available in " "<emphasis>stable</emphasis>; for example, a package uploaded to " "<emphasis>stable</emphasis> that depends on a library package that only " "exists in unstable will be rejected. Making changes to dependencies of " "other packages (by messing with <literal>Provides</literal> or shlibs " "files), possibly making those other packages uninstallable, is strongly " "discouraged." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:340 msgid "" "The Release Team (which can be reached at &email-debian-release;) will " "regularly evaluate the uploads To " "<emphasis>stable-proposed-updates</emphasis> and decide if your package can " "be included in <emphasis>stable</emphasis>. Please be clear (and verbose, " "if necessary) in your changelog entries for uploads to " "<emphasis>stable</emphasis>, because otherwise the package won't be " "considered for inclusion." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:349 msgid "" "It's best practice to speak with the stable release manager " "<emphasis>before</emphasis> uploading to " "<emphasis>stable</emphasis>/<emphasis>stable-proposed-updates</emphasis>, so " "that the uploaded package fits the needs of the next point release." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:357 msgid "" "Special case: uploads to " "<emphasis>testing/testing-proposed-updates</emphasis>" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:359 msgid "" "Please see the information in the <link linkend=\"t-p-u\">testing " "section</link> for details." msgstr "" # type: Content of: <chapter><section><title> #: pkgs.dbk:367 msgid "Uploading a package" msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:369 msgid "Uploading to <literal>ftp-master</literal>" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:371 msgid "" "To upload a package, you should upload the files (including the signed " "changes and dsc-file) with anonymous ftp to " "<literal>&ftp-master-host;</literal> in the directory <ulink " "url=\"ftp://&ftp-master-host;&upload-queue;\">&upload-queue;</ulink>. To " "get the files processed there, they need to be signed with a key in the " "debian keyring." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:379 msgid "" "Please note that you should transfer the changes file last. Otherwise, your " "upload may be rejected because the archive maintenance software will parse " "the changes file and see that not all files have been uploaded." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:384 msgid "" "You may also find the Debian packages <xref linkend=\"dupload\"/> or <xref " "linkend=\"dput\"/> useful when uploading packages. These handy programs " "help automate the process of uploading packages into Debian." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:389 msgid "" "For removing packages, please see the README file in that ftp directory, and " "the Debian package <xref linkend=\"dcut\"/> ." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:395 msgid "Uploading to <literal>non-US</literal>" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:397 msgid "" "<emphasis>Note:</emphasis> non-us was discontinued with the release of " "sarge." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:402 msgid "Delayed uploads" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:404 msgid "" "Delayed uploads are done for the moment via the delayed queue at gluck. The " "upload-directory is " "<literal>gluck:~tfheen/DELAYED/[012345678]-day</literal>. 0-day is uploaded " "multiple times per day to ftp-master." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:409 msgid "With a fairly recent dput, this section" msgstr "" # type: Content of: <chapter><section><section><screen> #: pkgs.dbk:412 #, no-wrap msgid "" "[tfheen_delayed]\n" "method = scp\n" "fqdn = gluck.debian.org\n" "incoming = ~tfheen" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:418 msgid "in ~/.dput.cf should work fine for uploading to the DELAYED queue." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:421 msgid "" "<emphasis>Note:</emphasis> Since this upload queue goes to " "<literal>ftp-master</literal>, the prescription found in <xref " "linkend=\"upload-ftp-master\"/> applies here as well." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:428 msgid "Security uploads" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:430 msgid "" "Do <emphasis role=\"strong\">NOT</emphasis> upload a package to the security " "upload queue (oldstable-security, stable-security, etc.) without prior " "authorization from the security team. If the package does not exactly meet " "the team's requirements, it will cause many problems and delays in dealing " "with the unwanted upload. For details, please see section <xref " "linkend=\"bug-security\"/> ." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:440 msgid "Other upload queues" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:442 msgid "" "The scp queues on ftp-master, and security are mostly unusable due to the " "login restrictions on those hosts." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:446 msgid "" "The anonymous queues on ftp.uni-erlangen.de and ftp.uk.debian.org are " "currently down. Work is underway to resurrect them." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:450 msgid "" "The queues on master.debian.org, samosa.debian.org, master.debian.or.jp, and " "ftp.chiark.greenend.org.uk are down permanently, and will not be " "resurrected. The queue in Japan will be replaced with a new queue on " "hp.debian.or.jp some day." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:456 msgid "" "For the time being, the anonymous ftp queue on auric.debian.org (the former " "ftp-master) works, but it is deprecated and will be removed at some point in " "the future." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:463 msgid "Notification that a new package has been installed" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:465 msgid "" "The Debian archive maintainers are responsible for handling package " "uploads. For the most part, uploads are automatically handled on a daily " "basis by the archive maintenance tools, <command>katie</command>. " "Specifically, updates to existing packages to the `unstable' distribution " "are handled automatically. In other cases, notably new packages, placing " "the uploaded package into the distribution is handled manually. When " "uploads are handled manually, the change to the archive may take up to a " "month to occur. Please be patient." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:474 msgid "" "In any case, you will receive an email notification indicating that the " "package has been added to the archive, which also indicates which bugs will " "be closed by the upload. Please examine this notification carefully, " "checking if any bugs you meant to close didn't get triggered." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:480 msgid "" "The installation notification also includes information on what section the " "package was inserted into. If there is a disparity, you will receive a " "separate email notifying you of that. Read on below." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:485 msgid "" "Note that if you upload via queues, the queue daemon software will also send " "you a notification by email." msgstr "" # type: Content of: <chapter><section><title> #: pkgs.dbk:493 msgid "Specifying the package section, subsection and priority" msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:495 msgid "" "The <filename>debian/control</filename> file's <literal>Section</literal> " "and <literal>Priority</literal> fields do not actually specify where the " "file will be placed in the archive, nor its priority. In order to retain " "the overall integrity of the archive, it is the archive maintainers who have " "control over these fields. The values in the " "<filename>debian/control</filename> file are actually just hints." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:503 msgid "" "The archive maintainers keep track of the canonical sections and priorities " "for packages in the <emphasis>override file</emphasis>. If there is a " "disparity between the <emphasis>override file</emphasis> and the package's " "fields as indicated in <filename>debian/control</filename>, then you will " "receive an email noting the divergence when the package is installed into " "the archive. You can either correct your " "<filename>debian/control</filename> file for your next upload, or else you " "may wish to make a change in the <emphasis>override file</emphasis>." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:513 msgid "" "To alter the actual section that a package is put in, you need to first make " "sure that the <filename>debian/control</filename> file in your package is " "accurate. Next, send an email &email-override; or submit a bug against " "<systemitem role=\"package\">ftp.debian.org</systemitem> requesting that the " "section or priority for your package be changed from the old section or " "priority to the new one. Be sure to explain your reasoning." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:521 msgid "" "For more information about <emphasis>override files</emphasis>, see " "<citerefentry> <refentrytitle>dpkg-scanpackages</refentrytitle> " "<manvolnum>1</manvolnum> </citerefentry> and <ulink " "url=\"&url-bts-devel;#maintincorrect\"></ulink>." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:527 msgid "" "Note that the <literal>Section</literal> field describes both the section as " "well as the subsection, which are described in <xref " "linkend=\"archive-sections\"/> . If the section is main, it should be " "omitted. The list of allowable subsections can be found in <ulink " "url=\"&url-debian-policy;ch-archive.html#s-subsections\"></ulink>." msgstr "" # type: Content of: <chapter><section><title> #: pkgs.dbk:536 msgid "Handling bugs" msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:538 msgid "" "Every developer has to be able to work with the Debian <ulink " "url=\"&url-bts;\">bug tracking system</ulink>. This includes knowing how to " "file bug reports properly (see <xref linkend=\"submit-bug\"/> ), how to " "update them and reorder them, and how to process and close them." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:544 msgid "" "The bug tracking system's features are described in the <ulink " "url=\"&url-bts-devel;\">BTS documentation for developers</ulink>. This " "includes closing bugs, sending followup messages, assigning severities and " "tags, marking bugs as forwarded, and other issues." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:550 msgid "" "Operations such as reassigning bugs to other packages, merging separate bug " "reports about the same issue, or reopening bugs when they are prematurely " "closed, are handled using the so-called control mail server. All of the " "commands available on this server are described in the <ulink " "url=\"&url-bts-control;\">BTS control server documentation</ulink>." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:558 msgid "Monitoring bugs" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:560 msgid "" "If you want to be a good maintainer, you should periodically check the " "<ulink url=\"&url-bts;\">Debian bug tracking system (BTS)</ulink> for your " "packages. The BTS contains all the open bugs against your packages. You " "can check them by browsing this page: " "<literal>http://&bugs-host;/<replaceable>yourlogin</replaceable>@debian.org</literal>." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:567 msgid "" "Maintainers interact with the BTS via email addresses at " "<literal>&bugs-host;</literal>. Documentation on available commands can be " "found at <ulink url=\"&url-bts;\"></ulink>, or, if you have installed the " "<systemitem role=\"package\">doc-debian</systemitem> package, you can look " "at the local files &file-bts-docs;." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:574 msgid "" "Some find it useful to get periodic reports on open bugs. You can add a " "cron job such as the following if you want to get a weekly email outlining " "all the open bugs against your packages:" msgstr "" # type: Content of: <chapter><section><section><screen> #: pkgs.dbk:579 #, no-wrap msgid "" "# ask for weekly reports of bugs in my packages\n" "&cron-bug-report;" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:583 msgid "" "Replace <replaceable>address</replaceable> with your official Debian " "maintainer address." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:589 msgid "Responding to bugs" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:591 msgid "" "When responding to bugs, make sure that any discussion you have about bugs " "is sent both to the original submitter of the bug, and to the bug itself " "(e.g., <email>123@&bugs-host;</email>). If you're writing a new mail and " "you don't remember the submitter email address, you can use the " "<email>123-submitter@&bugs-host;</email> email to contact the submitter " "<emphasis>and</emphasis> to record your mail within the bug log (that means " "you don't need to send a copy of the mail to " "<email>123@&bugs-host;</email>)." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:600 msgid "" "If you get a bug which mentions FTBFS, this means Fails to build from " "source. Porters frequently use this acronym." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:604 msgid "" "Once you've dealt with a bug report (e.g. fixed it), mark it as " "<emphasis>done</emphasis> (close it) by sending an explanation message to " "<email>123-done@&bugs-host;</email>. If you're fixing a bug by changing and " "uploading the package, you can automate bug closing as described in <xref " "linkend=\"upload-bugfix\"/> ." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:611 msgid "" "You should <emphasis>never</emphasis> close bugs via the bug server " "<literal>close</literal> command sent to &email-bts-control;. If you do so, " "the original submitter will not receive any information about why the bug " "was closed." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:619 msgid "Bug housekeeping" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:621 msgid "" "As a package maintainer, you will often find bugs in other packages or have " "bugs reported against your packages which are actually bugs in other " "packages. The bug tracking system's features are described in the <ulink " "url=\"&url-bts-devel;\">BTS documentation for Debian developers</ulink>. " "Operations such as reassigning, merging, and tagging bug reports are " "described in the <ulink url=\"&url-bts-control;\">BTS control server " "documentation</ulink>. This section contains some guidelines for managing " "your own bugs, based on the collective Debian developer experience." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:632 msgid "" "Filing bugs for problems that you find in other packages is one of the civic " "obligations of maintainership, see <xref linkend=\"submit-bug\"/> for " "details. However, handling the bugs in your own packages is even more " "important." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:637 msgid "Here's a list of steps that you may follow to handle a bug report:" msgstr "" # type: Content of: <chapter><section><section><orderedlist><listitem><para> #: pkgs.dbk:642 msgid "" "Decide whether the report corresponds to a real bug or not. Sometimes users " "are just calling a program in the wrong way because they haven't read the " "documentation. If you diagnose this, just close the bug with enough " "information to let the user correct their problem (give pointers to the good " "documentation and so on). If the same report comes up again and again you " "may ask yourself if the documentation is good enough or if the program " "shouldn't detect its misuse in order to give an informative error message. " "This is an issue that may need to be brought up with the upstream author." msgstr "" # type: Content of: <chapter><section><section><orderedlist><listitem><para> #: pkgs.dbk:652 msgid "" "If the bug submitter disagrees with your decision to close the bug, they may " "reopen it until you find an agreement on how to handle it. If you don't " "find any, you may want to tag the bug <literal>wontfix</literal> to let " "people know that the bug exists but that it won't be corrected. If this " "situation is unacceptable, you (or the submitter) may want to require a " "decision of the technical committee by reassigning the bug to <systemitem " "role=\"package\">tech-ctte</systemitem> (you may use the clone command of " "the BTS if you wish to keep it reported against your package). Before doing " "so, please read the <ulink url=\"&url-tech-ctte;\">recommended " "procedure</ulink>." msgstr "" # type: Content of: <chapter><section><section><orderedlist><listitem><para> #: pkgs.dbk:666 msgid "" "If the bug is real but it's caused by another package, just reassign the bug " "to the right package. If you don't know which package it should be " "reassigned to, you should ask for help on <link " "linkend=\"irc-channels\">IRC</link> or on &email-debian-devel;. Please make " "sure that the maintainer(s) of the package the bug is reassigned to know why " "you reassigned it." msgstr "" # type: Content of: <chapter><section><section><orderedlist><listitem><para> #: pkgs.dbk:674 msgid "" "Sometimes you also have to adjust the severity of the bug so that it matches " "our definition of the severity. That's because people tend to inflate the " "severity of bugs to make sure their bugs are fixed quickly. Some bugs may " "even be dropped to wishlist severity when the requested change is just " "cosmetic." msgstr "" # type: Content of: <chapter><section><section><orderedlist><listitem><para> #: pkgs.dbk:682 msgid "" "If the bug is real but the same problem has already been reported by someone " "else, then the two relevant bug reports should be merged into one using the " "merge command of the BTS. In this way, when the bug is fixed, all of the " "submitters will be informed of this. (Note, however, that emails sent to " "one bug report's submitter won't automatically be sent to the other report's " "submitter.) For more details on the technicalities of the merge command and " "its relative, the unmerge command, see the BTS control server documentation." msgstr "" # type: Content of: <chapter><section><section><orderedlist><listitem><para> #: pkgs.dbk:693 msgid "" "The bug submitter may have forgotten to provide some information, in which " "case you have to ask them for the required information. You may use the " "<literal>moreinfo</literal> tag to mark the bug as such. Moreover if you " "can't reproduce the bug, you tag it <literal>unreproducible</literal>. " "Anyone who can reproduce the bug is then invited to provide more information " "on how to reproduce it. After a few months, if this information has not " "been sent by someone, the bug may be closed." msgstr "" # type: Content of: <chapter><section><section><orderedlist><listitem><para> #: pkgs.dbk:704 msgid "" "If the bug is related to the packaging, you just fix it. If you are not " "able to fix it yourself, then tag the bug as <literal>help</literal>. You " "can also ask for help on &email-debian-devel; or &email-debian-qa;. If it's " "an upstream problem, you have to forward it to the upstream author. " "Forwarding a bug is not enough, you have to check at each release if the bug " "has been fixed or not. If it has, you just close it, otherwise you have to " "remind the author about it. If you have the required skills you can prepare " "a patch that fixes the bug and send it to the author at the same time. Make " "sure to send the patch to the BTS and to tag the bug as " "<literal>patch</literal>." msgstr "" # type: Content of: <chapter><section><section><orderedlist><listitem><para> #: pkgs.dbk:718 msgid "" "If you have fixed a bug in your local copy, or if a fix has been committed " "to the CVS repository, you may tag the bug as <literal>pending</literal> to " "let people know that the bug is corrected and that it will be closed with " "the next upload (add the <literal>closes:</literal> in the " "<filename>changelog</filename>). This is particularly useful if you are " "several developers working on the same package." msgstr "" # type: Content of: <chapter><section><section><orderedlist><listitem><para> #: pkgs.dbk:728 msgid "" "Once a corrected package is available in the <emphasis>unstable</emphasis> " "distribution, you can close the bug. This can be done automatically, read " "<xref linkend=\"upload-bugfix\"/> ." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:737 msgid "When bugs are closed by new uploads" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:739 msgid "" "As bugs and problems are fixed in your packages, it is your responsibility " "as the package maintainer to close these bugs. However, you should not " "close a bug until the package which fixes the bug has been accepted into the " "Debian archive. Therefore, once you get notification that your updated " "package has been installed into the archive, you can and should close the " "bug in the BTS. Also, the bug should be closed with the correct version." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:747 msgid "" "However, it's possible to avoid having to manually close bugs after the " "upload — just list the fixed bugs in your " "<filename>debian/changelog</filename> file, following a certain syntax, and " "the archive maintenance software will close the bugs for you. For example:" msgstr "" # type: Content of: <chapter><section><section><screen> #: pkgs.dbk:753 #, no-wrap msgid "" "acme-cannon (3.1415) unstable; urgency=low\n" "\n" " * Frobbed with options (closes: Bug#98339)\n" " * Added safety to prevent operator dismemberment, closes: bug#98765,\n" " bug#98713, #98714.\n" " * Added man page. Closes: #98725." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:761 msgid "" "Technically speaking, the following Perl regular expression describes how " "bug closing changelogs are identified:" msgstr "" # type: Content of: <chapter><section><section><screen> #: pkgs.dbk:765 #, no-wrap msgid "/closes:\\s*(?:bug)?\\#\\s*\\d+(?:,\\s*(?:bug)?\\#\\s*\\d+)*/ig" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:768 msgid "" "We prefer the <literal>closes: #<replaceable>XXX</replaceable></literal> " "syntax, as it is the most concise entry and the easiest to integrate with " "the text of the <filename>changelog</filename>. Unless specified different " "by the <replaceable>-v</replaceable>-switch to " "<command>dpkg-buildpackage</command>, only the bugs closed in the most " "recent changelog entry are closed (basically, exactly the bugs mentioned in " "the changelog-part in the <filename>.changes</filename> file are closed)." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:777 msgid "" "Historically, uploads identified as <link linkend=\"nmu\">Non-maintainer " "upload (NMU)</link> were tagged <literal>fixed</literal> instead of being " "closed, but that practice was ceased with the advent of version-tracking. " "The same applied to the tag <literal>fixed-in-experimental</literal>." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:783 msgid "" "If you happen to mistype a bug number or forget a bug in the changelog " "entries, don't hesitate to undo any damage the error caused. To reopen " "wrongly closed bugs, send a <literal>reopen " "<replaceable>XXX</replaceable></literal> command to the bug tracking " "system's control address, &email-bts-control;. To close any remaining bugs " "that were fixed by your upload, email the <filename>.changes</filename> file " "to <email>XXX-done@&bugs-host;</email>, where <replaceable>XXX</replaceable> " "is the bug number, and put Version: YYY and an empty line as the first two " "lines of the body of the email, where <replaceable>YYY</replaceable> is the " "first version where the bug has been fixed." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:795 msgid "" "Bear in mind that it is not obligatory to close bugs using the changelog as " "described above. If you simply want to close bugs that don't have anything " "to do with an upload you made, do it by emailing an explanation to " "<email>XXX-done@&bugs-host;</email>. Do <emphasis " "role=\"strong\">not</emphasis> close bugs in the changelog entry of a " "version if the changes in that version of the package don't have any bearing " "on the bug." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:803 msgid "" "For general information on how to write your changelog entries, see <xref " "linkend=\"bpp-debian-changelog\"/> ." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:809 msgid "Handling security-related bugs" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:811 msgid "" "Due to their sensitive nature, security-related bugs must be handled " "carefully. The Debian Security Team exists to coordinate this activity, " "keeping track of outstanding security problems, helping maintainers with " "security problems or fixing them themselves, sending security advisories, " "and maintaining security.debian.org." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:820 msgid "" "When you become aware of a security-related bug in a Debian package, whether " "or not you are the maintainer, collect pertinent information about the " "problem, and promptly contact the security team at &email-security-team; as " "soon as possible. <emphasis role=\"strong\">DO NOT UPLOAD</emphasis> any " "packages for stable; the security team will do that. Useful information " "includes, for example:" msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:830 msgid "" "Which versions of the package are known to be affected by the bug. Check " "each version that is present in a supported Debian release, as well as " "testing and unstable." msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:837 msgid "The nature of the fix, if any is available (patches are especially helpful)" msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:842 msgid "" "Any fixed packages that you have prepared yourself (send only the " "<literal>.diff.gz</literal> and <literal>.dsc</literal> files and read <xref " "linkend=\"bug-security-building\"/> first)" msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:849 msgid "" "Any assistance you can provide to help with testing (exploits, regression " "testing, etc.)" msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:855 msgid "" "Any information needed for the advisory (see <xref " "linkend=\"bug-security-advisories\"/> )" msgstr "" # type: Content of: <chapter><section><section><section><title> #: pkgs.dbk:861 msgid "Confidentiality" msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:863 msgid "" "Unlike most other activities within Debian, information about security " "issues must sometimes be kept private for a time. This allows software " "distributors to coordinate their disclosure in order to minimize their " "users' exposure. Whether this is the case depends on the nature of the " "problem and corresponding fix, and whether it is already a matter of public " "knowledge." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:870 msgid "There are several ways developers can learn of a security problem:" msgstr "" # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> #: pkgs.dbk:875 msgid "they notice it on a public forum (mailing list, web site, etc.)" msgstr "" # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> #: pkgs.dbk:880 msgid "someone files a bug report" msgstr "" # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> #: pkgs.dbk:885 msgid "someone informs them via private email" msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:890 msgid "" "In the first two cases, the information is public and it is important to " "have a fix as soon as possible. In the last case, however, it might not be " "public information. In that case there are a few possible options for " "dealing with the problem:" msgstr "" # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> #: pkgs.dbk:898 msgid "" "If the security exposure is minor, there is sometimes no need to keep the " "problem a secret and a fix should be made and released." msgstr "" # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> #: pkgs.dbk:904 msgid "" "If the problem is severe, it is preferable to share the information with " "other vendors and coordinate a release. The security team keeps in contact " "with the various organizations and individuals and can take care of that." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:911 msgid "" "In all cases if the person who reports the problem asks that it not be " "disclosed, such requests should be honored, with the obvious exception of " "informing the security team in order that a fix may be produced for a stable " "release of Debian. When sending confidential information to the security " "team, be sure to mention this fact." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:918 msgid "" "Please note that if secrecy is needed you may not upload a fix to unstable " "(or anywhere else, such as a public CVS repository). It is not sufficient " "to obfuscate the details of the change, as the code itself is public, and " "can (and will) be examined by the general public." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:924 msgid "" "There are two reasons for releasing information even though secrecy is " "requested: the problem has been known for a while, or the problem or exploit " "has become public." msgstr "" # type: Content of: <chapter><section><section><section><title> #: pkgs.dbk:931 msgid "Security Advisories" msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:933 msgid "" "Security advisories are only issued for the current, released stable " "distribution, and <emphasis>not</emphasis> for testing or unstable. When " "released, advisories are sent to the &email-debian-security-announce; " "mailing list and posted on <ulink " "url=\"&url-debian-security-advisories;\">the security web page</ulink>. " "Security advisories are written and posted by the security team. However " "they certainly do not mind if a maintainer can supply some of the " "information for them, or write part of the text. Information that should be " "in an advisory includes:" msgstr "" # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> #: pkgs.dbk:946 msgid "A description of the problem and its scope, including:" msgstr "" # type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para> #: pkgs.dbk:951 msgid "The type of problem (privilege escalation, denial of service, etc.)" msgstr "" # type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para> #: pkgs.dbk:956 msgid "What privileges may be gained, and by whom (if any)" msgstr "" # type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para> #: pkgs.dbk:961 msgid "How it can be exploited" msgstr "" # type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para> #: pkgs.dbk:966 msgid "Whether it is remotely or locally exploitable" msgstr "" # type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para> #: pkgs.dbk:971 msgid "How the problem was fixed" msgstr "" # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> #: pkgs.dbk:976 msgid "This information allows users to assess the threat to their systems." msgstr "" # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> #: pkgs.dbk:981 msgid "Version numbers of affected packages" msgstr "" # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> #: pkgs.dbk:986 msgid "Version numbers of fixed packages" msgstr "" # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> #: pkgs.dbk:991 msgid "" "Information on where to obtain the updated packages (usually from the Debian " "security archive)" msgstr "" # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> #: pkgs.dbk:997 msgid "" "References to upstream advisories, <ulink " "url=\"http://cve.mitre.org\">CVE</ulink> identifiers, and any other " "information useful in cross-referencing the vulnerability" msgstr "" # type: Content of: <chapter><section><section><section><title> #: pkgs.dbk:1006 msgid "Preparing packages to address security issues" msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1008 msgid "" "One way that you can assist the security team in their duties is to provide " "them with fixed packages suitable for a security advisory for the stable " "Debian release." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1013 msgid "" "When an update is made to the stable release, care must be taken to avoid " "changing system behavior or introducing new bugs. In order to do this, make " "as few changes as possible to fix the bug. Users and administrators rely on " "the exact behavior of a release once it is made, so any change that is made " "might break someone's system. This is especially true of libraries: make " "sure you never change the API or ABI, no matter how small the change." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1021 msgid "" "This means that moving to a new upstream version is not a good solution. " "Instead, the relevant changes should be back-ported to the version present " "in the current stable Debian release. Generally, upstream maintainers are " "willing to help if needed. If not, the Debian security team may be able to " "help." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1027 msgid "" "In some cases, it is not possible to back-port a security fix, for example " "when large amounts of source code need to be modified or rewritten. If this " "happens, it may be necessary to move to a new upstream version. However, " "this is only done in extreme situations, and you must always coordinate that " "with the security team beforehand." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1034 msgid "" "Related to this is another important guideline: always test your changes. " "If you have an exploit available, try it and see if it indeed succeeds on " "the unpatched package and fails on the fixed package. Test other, normal " "actions as well, as sometimes a security fix can break seemingly unrelated " "features in subtle ways." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1041 msgid "" "Do <emphasis role=\"strong\">NOT</emphasis> include any changes in your " "package which are not directly related to fixing the vulnerability. These " "will only need to be reverted, and this wastes time. If there are other " "bugs in your package that you would like to fix, make an upload to " "proposed-updates in the usual way, after the security advisory is issued. " "The security update mechanism is not a means for introducing changes to your " "package which would otherwise be rejected from the stable release, so please " "do not attempt to do this." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1051 msgid "" "Review and test your changes as much as possible. Check the differences " "from the previous version repeatedly (<command>interdiff</command> from the " "<systemitem role=\"package\">patchutils</systemitem> package and " "<command>debdiff</command> from <systemitem " "role=\"package\">devscripts</systemitem> are useful tools for this, see " "<xref linkend=\"debdiff\"/> )." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1059 msgid "Be sure to verify the following items:" msgstr "" # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> #: pkgs.dbk:1064 msgid "" "Target the right distribution in your " "<filename>debian/changelog</filename>. For stable this is " "<literal>stable-security</literal> and for testing this is " "<literal>testing-security</literal>, and for the previous stable release, " "this is <literal>oldstable-security</literal>. Do not target " "<replaceable>distribution</replaceable>-proposed-updates or " "<literal>stable</literal>!" msgstr "" # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> #: pkgs.dbk:1074 msgid "The upload should have urgency=high." msgstr "" # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> #: pkgs.dbk:1079 msgid "" "Make descriptive, meaningful changelog entries. Others will rely on them to " "determine whether a particular bug was fixed. Always include an external " "reference, preferably a CVE identifier, so that it can be cross-referenced. " "Include the same information in the changelog for unstable, so that it is " "clear that the same bug was fixed, as this is very helpful when verifying " "that the bug is fixed in the next stable release. If a CVE identifier has " "not yet been assigned, the security team will request one so that it can be " "included in the package and in the advisory." msgstr "" # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> #: pkgs.dbk:1091 msgid "" "Make sure the version number is proper. It must be greater than the current " "package, but less than package versions in later distributions. If in " "doubt, test it with <literal>dpkg --compare-versions</literal>. Be careful " "not to re-use a version number that you have already used for a previous " "upload. For <emphasis>testing</emphasis>, there must be a higher version in " "<emphasis>unstable</emphasis>. If there is none yet (for example, if " "<emphasis>testing</emphasis> and <emphasis>unstable</emphasis> have the same " "version) you must upload a new version to unstable first." msgstr "" # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> #: pkgs.dbk:1103 msgid "" "Do not make source-only uploads if your package has any binary-all packages " "(do not use the <literal>-S</literal> option to " "<command>dpkg-buildpackage</command>). The <command>buildd</command> " "infrastructure will not build those. This point applies to normal package " "uploads as well." msgstr "" # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> #: pkgs.dbk:1112 msgid "" "Unless the upstream source has been uploaded to security.debian.org before " "(by a previous security update), build the upload with full upstream source " "(<literal>dpkg-buildpackage -sa</literal>). If there has been a previous " "upload to security.debian.org with the same upstream version, you may upload " "without upstream source (<literal>dpkg-buildpackage -sd</literal>)." msgstr "" # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> #: pkgs.dbk:1121 msgid "" "Be sure to use the exact same <filename>*.orig.tar.gz</filename> as used in " "the normal archive, otherwise it is not possible to move the security fix " "into the main archives later." msgstr "" # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> #: pkgs.dbk:1128 msgid "" "Build the package on a clean system which only has packages installed from " "the distribution you are building for. If you do not have such a system " "yourself, you can use a debian.org machine (see <xref " "linkend=\"server-machines\"/> ) or setup a chroot (see <xref " "linkend=\"pbuilder\"/> and <xref linkend=\"debootstrap\"/> )." msgstr "" # type: Content of: <chapter><section><section><section><title> #: pkgs.dbk:1139 msgid "Uploading the fixed package" msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1141 msgid "" "Do <emphasis role=\"strong\">NOT</emphasis> upload a package to the security " "upload queue (oldstable-security, stable-security, etc.) without prior " "authorization from the security team. If the package does not exactly meet " "the team's requirements, it will cause many problems and delays in dealing " "with the unwanted upload." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1148 msgid "" "Do <emphasis role=\"strong\">NOT</emphasis> upload your fix to " "proposed-updates without coordinating with the security team. Packages from " "security.debian.org will be copied into the proposed-updates directory " "automatically. If a package with the same or a higher version number is " "already installed into the archive, the security update will be rejected by " "the archive system. That way, the stable distribution will end up without a " "security update for this package instead." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1157 msgid "" "Once you have created and tested the new package and it has been approved by " "the security team, it needs to be uploaded so that it can be installed in " "the archives. For security uploads, the place to upload to is " "<literal>ftp://security-master.debian.org/pub/SecurityUploadQueue/</literal> " "." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1163 msgid "" "Once an upload to the security queue has been accepted, the package will " "automatically be rebuilt for all architectures and stored for verification " "by the security team." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1168 msgid "" "Uploads which are waiting for acceptance or verification are only accessible " "by the security team. This is necessary since there might be fixes for " "security problems that cannot be disclosed yet." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1173 msgid "" "If a member of the security team accepts a package, it will be installed on " "security.debian.org as well as proposed for the proper " "<replaceable>distribution</replaceable>-proposed-updates on ftp-master." msgstr "" # type: Content of: <chapter><section><title> #: pkgs.dbk:1184 msgid "Moving, removing, renaming, adopting, and orphaning packages" msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:1186 msgid "" "Some archive manipulation operations are not automated in the Debian upload " "process. These procedures should be manually followed by maintainers. This " "chapter gives guidelines on what to do in these cases." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:1191 msgid "Moving packages" msgstr "" # type: Content of: <chapter><section><section><para><footnote> #: pkgs.dbk:1193 msgid "" "Sometimes a package will change its section. For instance, a package from " "the `non-free' section might be GPL'd in a later version, in which case the " "package should be moved to `main' or `contrib'.<footnote>" msgstr "" # type: Content of: <chapter><section><section><para><footnote><para> #: pkgs.dbk:1195 msgid "" "See the <ulink url=\"&url-debian-policy;\">Debian Policy Manual</ulink> for " "guidelines on what section a package belongs in." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1200 msgid "" "If you need to change the section for one of your packages, change the " "package control information to place the package in the desired section, and " "re-upload the package (see the <ulink url=\"&url-debian-policy;\">Debian " "Policy Manual</ulink> for details). You must ensure that you include the " "<filename>.orig.tar.gz</filename> in your upload (even if you are not " "uploading a new upstream version), or it will not appear in the new section " "together with the rest of the package. If your new section is valid, it " "will be moved automatically. If it does not, then contact the ftpmasters in " "order to understand what happened." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1212 msgid "" "If, on the other hand, you need to change the " "<emphasis>subsection</emphasis> of one of your packages (e.g., ``devel'', " "``admin''), the procedure is slightly different. Correct the subsection as " "found in the control file of the package, and re-upload that. Also, you'll " "need to get the override file updated, as described in <xref " "linkend=\"override-file\"/> ." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:1221 msgid "Removing packages" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1223 msgid "" "If for some reason you want to completely remove a package (say, if it is an " "old compatibility library which is no longer required), you need to file a " "bug against <literal>ftp.debian.org</literal> asking that the package be " "removed; as all bugs, this bug should normally have normal severity. Make " "sure you indicate which distribution the package should be removed from. " "Normally, you can only have packages removed from " "<emphasis>unstable</emphasis> and <emphasis>experimental</emphasis>. " "Packages are not removed from <emphasis>testing</emphasis> directly. " "Rather, they will be removed automatically after the package has been " "removed from <emphasis>unstable</emphasis> and no package in " "<emphasis>testing</emphasis> depends on it." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1236 msgid "" "There is one exception when an explicit removal request is not necessary: If " "a (source or binary) package is an orphan, it will be removed " "semi-automatically. For a binary-package, this means if there is no longer " "any source package producing this binary package; if the binary package is " "just no longer produced on some architectures, a removal request is still " "necessary. For a source-package, this means that all binary packages it " "refers to have been taken over by another source package." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1245 msgid "" "In your removal request, you have to detail the reasons justifying the " "request. This is to avoid unwanted removals and to keep a trace of why a " "package has been removed. For example, you can provide the name of the " "package that supersedes the one to be removed." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1251 msgid "" "Usually you only ask for the removal of a package maintained by yourself. " "If you want to remove another package, you have to get the approval of its " "maintainer." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1256 msgid "" "Further information relating to these and other package removal related " "topics may be found at <ulink " "url=\"http://wiki.debian.org/ftpmaster_Removals\"></ulink> and <ulink " "url=\"&url-debian-qa;howto-remove.html\"></ulink>." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1261 msgid "" "If in doubt concerning whether a package is disposable, email " "&email-debian-devel; asking for opinions. Also of interest is the " "<command>apt-cache</command> program from the <systemitem " "role=\"package\">apt</systemitem> package. When invoked as " "<literal>apt-cache showpkg <replaceable>package</replaceable></literal>, the " "program will show details for <replaceable>package</replaceable>, including " "reverse depends. Other useful programs include <literal>apt-cache " "rdepends</literal>, <command>apt-rdepends</command> and " "<command>grep-dctrl</command>. Removal of orphaned packages is discussed on " "&email-debian-qa;." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1272 msgid "" "Once the package has been removed, the package's bugs should be handled. " "They should either be reassigned to another package in the case where the " "actual code has evolved into another package (e.g. " "<literal>libfoo12</literal> was removed because <literal>libfoo13</literal> " "supersedes it) or closed if the software is simply no longer part of Debian." msgstr "" # type: Content of: <chapter><section><section><section><title> #: pkgs.dbk:1279 msgid "Removing packages from <filename>Incoming</filename>" msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1281 msgid "" "In the past, it was possible to remove packages from " "<filename>incoming</filename>. However, with the introduction of the new " "incoming system, this is no longer possible. Instead, you have to upload a " "new revision of your package with a higher version than the package you want " "to replace. Both versions will be installed in the archive but only the " "higher version will actually be available in <emphasis>unstable</emphasis> " "since the previous version will immediately be replaced by the higher. " "However, if you do proper testing of your packages, the need to replace a " "package should not occur too often anyway." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:1296 msgid "Replacing or renaming packages" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1298 msgid "" "When you make a mistake naming your package, you should follow a two-step " "process to rename it. First, set your <filename>debian/control</filename> " "file to replace and conflict with the obsolete name of the package (see the " "<ulink url=\"&url-debian-policy;\">Debian Policy Manual</ulink> for " "details). Once you've uploaded the package and the package has moved into " "the archive, file a bug against <literal>ftp.debian.org</literal> asking to " "remove the package with the obsolete name. Do not forget to properly " "reassign the package's bugs at the same time." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1308 msgid "" "At other times, you may make a mistake in constructing your package and wish " "to replace it. The only way to do this is to increase the version number " "and upload a new version. The old version will be expired in the usual " "manner. Note that this applies to each part of your package, including the " "sources: if you wish to replace the upstream source tarball of your package, " "you will need to upload it with a different version. An easy possibility is " "to replace <filename>foo_1.00.orig.tar.gz</filename> with " "<filename>foo_1.00+0.orig.tar.gz</filename>. This restriction gives each " "file on the ftp site a unique name, which helps to ensure consistency across " "the mirror network." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:1322 msgid "Orphaning a package" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1324 msgid "" "If you can no longer maintain a package, you need to inform others, and see " "that the package is marked as orphaned. You should set the package " "maintainer to <literal>Debian QA Group &orphan-address;</literal> and submit " "a bug report against the pseudo package <systemitem " "role=\"package\">wnpp</systemitem>. The bug report should be titled " "<literal>O: <replaceable>package</replaceable> -- <replaceable>short " "description</replaceable></literal> indicating that the package is now " "orphaned. The severity of the bug should be set to " "<emphasis>normal</emphasis>; if the package has a priority of standard or " "higher, it should be set to important. If you feel it's necessary, send a " "copy to &email-debian-devel; by putting the address in the X-Debbugs-CC: " "header of the message (no, don't use CC:, because that way the message's " "subject won't indicate the bug number)." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1339 msgid "" "If you just intend to give the package away, but you can keep maintainership " "for the moment, then you should instead submit a bug against <systemitem " "role=\"package\">wnpp</systemitem> and title it <literal>RFA: " "<replaceable>package</replaceable> -- <replaceable>short " "description</replaceable></literal>. <literal>RFA</literal> stands for " "<emphasis>Request For Adoption</emphasis>." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1347 msgid "More information is on the <ulink url=\"&url-wnpp;\">WNPP web pages</ulink>." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:1353 msgid "Adopting a package" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1355 msgid "" "A list of packages in need of a new maintainer is available in the <ulink " "url=\"&url-wnpp;\">Work-Needing and Prospective Packages list " "(WNPP)</ulink>. If you wish to take over maintenance of any of the packages " "listed in the WNPP, please take a look at the aforementioned page for " "information and procedures." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1362 msgid "" "It is not OK to simply take over a package that you feel is neglected — that " "would be package hijacking. You can, of course, contact the current " "maintainer and ask them if you may take over the package. If you have " "reason to believe a maintainer has gone AWOL (absent without leave), see " "<xref linkend=\"mia-qa\"/> ." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1368 msgid "" "Generally, you may not take over the package without the assent of the " "current maintainer. Even if they ignore you, that is still not grounds to " "take over a package. Complaints about maintainers should be brought up on " "the developers' mailing list. If the discussion doesn't end with a positive " "conclusion, and the issue is of a technical nature, consider bringing it to " "the attention of the technical committee (see the <ulink " "url=\"&url-tech-ctte;\">technical committee web page</ulink> for more " "information)." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1378 msgid "" "If you take over an old package, you probably want to be listed as the " "package's official maintainer in the bug system. This will happen " "automatically once you upload a new version with an updated " "<literal>Maintainer:</literal> field, although it can take a few hours after " "the upload is done. If you do not expect to upload a new version for a " "while, you can use <xref linkend=\"pkg-tracking-system\"/> to get the bug " "reports. However, make sure that the old maintainer has no problem with the " "fact that they will continue to receive the bugs during that time." msgstr "" # type: Content of: <chapter><section><title> #: pkgs.dbk:1392 msgid "Porting and being ported" msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:1394 msgid "" "Debian supports an ever-increasing number of architectures. Even if you are " "not a porter, and you don't use any architecture but one, it is part of your " "duty as a maintainer to be aware of issues of portability. Therefore, even " "if you are not a porter, you should read most of this chapter." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:1400 msgid "" "Porting is the act of building Debian packages for architectures that are " "different from the original architecture of the package maintainer's binary " "package. It is a unique and essential activity. In fact, porters do most " "of the actual compiling of Debian packages. For instance, for a single " "<emphasis>i386</emphasis> binary package, there must be a recompile for each " "architecture, which amounts to &number-of-arches; more builds." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:1408 msgid "Being kind to porters" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1410 msgid "" "Porters have a difficult and unique task, since they are required to deal " "with a large volume of packages. Ideally, every source package should build " "right out of the box. Unfortunately, this is often not the case. This " "section contains a checklist of ``gotchas'' often committed by Debian " "maintainers — common problems which often stymie porters, and make their " "jobs unnecessarily difficult." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1418 msgid "" "The first and most important thing is to respond quickly to bug or issues " "raised by porters. Please treat porters with courtesy, as if they were in " "fact co-maintainers of your package (which, in a way, they are). Please be " "tolerant of succinct or even unclear bug reports; do your best to hunt down " "whatever the problem is." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1425 msgid "" "By far, most of the problems encountered by porters are caused by " "<emphasis>packaging bugs</emphasis> in the source packages. Here is a " "checklist of things you should check or be aware of." msgstr "" # type: Content of: <chapter><section><section><orderedlist><listitem><para> #: pkgs.dbk:1432 msgid "" "Make sure that your <literal>Build-Depends</literal> and " "<literal>Build-Depends-Indep</literal> settings in " "<filename>debian/control</filename> are set properly. The best way to " "validate this is to use the <systemitem " "role=\"package\">debootstrap</systemitem> package to create an unstable " "chroot environment (see <xref linkend=\"debootstrap\"/> ). Within that " "chrooted environment, install the <systemitem " "role=\"package\">build-essential</systemitem> package and any package " "dependencies mentioned in <literal>Build-Depends</literal> and/or " "<literal>Build-Depends-Indep</literal>. Finally, try building your package " "within that chrooted environment. These steps can be automated by the use " "of the <command>pbuilder</command> program which is provided by the package " "of the same name (see <xref linkend=\"pbuilder\"/> )." msgstr "" # type: Content of: <chapter><section><section><orderedlist><listitem><para> #: pkgs.dbk:1446 msgid "" "If you can't set up a proper chroot, <command>dpkg-depcheck</command> may be " "of assistance (see <xref linkend=\"dpkg-depcheck\"/> )." msgstr "" # type: Content of: <chapter><section><section><orderedlist><listitem><para> #: pkgs.dbk:1450 msgid "" "See the <ulink url=\"&url-debian-policy;\">Debian Policy Manual</ulink> for " "instructions on setting build dependencies." msgstr "" # type: Content of: <chapter><section><section><orderedlist><listitem><para> #: pkgs.dbk:1456 msgid "" "Don't set architecture to a value other than ``all'' or ``any'' unless you " "really mean it. In too many cases, maintainers don't follow the " "instructions in the <ulink url=\"&url-debian-policy;\">Debian Policy " "Manual</ulink>. Setting your architecture to ``i386'' is usually incorrect." msgstr "" # type: Content of: <chapter><section><section><orderedlist><listitem><para> #: pkgs.dbk:1464 msgid "" "Make sure your source package is correct. Do <literal>dpkg-source -x " "<replaceable>package</replaceable>.dsc</literal> to make sure your source " "package unpacks properly. Then, in there, try building your package from " "scratch with <command>dpkg-buildpackage</command>." msgstr "" # type: Content of: <chapter><section><section><orderedlist><listitem><para> #: pkgs.dbk:1472 msgid "" "Make sure you don't ship your source package with the " "<filename>debian/files</filename> or <filename>debian/substvars</filename> " "files. They should be removed by the `clean' target of " "<filename>debian/rules</filename>." msgstr "" # type: Content of: <chapter><section><section><orderedlist><listitem><para> #: pkgs.dbk:1480 msgid "" "Make sure you don't rely on locally installed or hacked configurations or " "programs. For instance, you should never be calling programs in " "<filename>/usr/local/bin</filename> or the like. Try not to rely on " "programs being setup in a special way. Try building your package on another " "machine, even if it's the same architecture." msgstr "" # type: Content of: <chapter><section><section><orderedlist><listitem><para> #: pkgs.dbk:1489 msgid "" "Don't depend on the package you're building being installed already (a " "sub-case of the above issue)." msgstr "" # type: Content of: <chapter><section><section><orderedlist><listitem><para> #: pkgs.dbk:1495 msgid "" "Don't rely on the compiler being a certain version, if possible. If not, " "then make sure your build dependencies reflect the restrictions, although " "you are probably asking for trouble, since different architectures sometimes " "standardize on different compilers." msgstr "" # type: Content of: <chapter><section><section><orderedlist><listitem><para> #: pkgs.dbk:1503 msgid "" "Make sure your debian/rules contains separate ``binary-arch'' and " "``binary-indep'' targets, as the Debian Policy Manual requires. Make sure " "that both targets work independently, that is, that you can call the target " "without having called the other before. To test this, try to run " "<literal>dpkg-buildpackage -B</literal>." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:1514 msgid "Guidelines for porter uploads" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1516 msgid "" "If the package builds out of the box for the architecture to be ported to, " "you are in luck and your job is easy. This section applies to that case; it " "describes how to build and upload your binary package so that it is properly " "installed into the archive. If you do have to patch the package in order to " "get it to compile for the other architecture, you are actually doing a " "source NMU, so consult <xref linkend=\"nmu-guidelines\"/> instead." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1524 msgid "" "For a porter upload, no changes are being made to the source. You do not " "need to touch any of the files in the source package. This includes " "<filename>debian/changelog</filename>." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1529 msgid "" "The way to invoke <command>dpkg-buildpackage</command> is as " "<literal>dpkg-buildpackage -B " "-m<replaceable>porter-email</replaceable></literal>. Of course, set " "<replaceable>porter-email</replaceable> to your email address. This will do " "a binary-only build of only the architecture-dependent portions of the " "package, using the `binary-arch' target in " "<filename>debian/rules</filename>." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1537 msgid "" "If you are working on a Debian machine for your porting efforts and you need " "to sign your upload locally for its acceptance in the archive, you can run " "<command>debsign</command> on your <filename>.changes</filename> file to " "have it signed conveniently, or use the remote signing mode of " "<command>dpkg-sig</command>." msgstr "" # type: Content of: <chapter><section><section><section><title> #: pkgs.dbk:1544 msgid "Recompilation or binary-only NMU" msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1546 msgid "" "Sometimes the initial porter upload is problematic because the environment " "in which the package was built was not good enough (outdated or obsolete " "library, bad compiler, ...). Then you may just need to recompile it in an " "updated environment. However, you have to bump the version number in this " "case, so that the old bad package can be replaced in the Debian archive " "(<command>katie</command> refuses to install new packages if they don't have " "a version number greater than the currently available one)." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1555 msgid "" "You have to make sure that your binary-only NMU doesn't render the package " "uninstallable. This could happen when a source package generates " "arch-dependent and arch-independent packages that depend on each other via " "$(Source-Version)." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1561 msgid "" "Despite the required modification of the changelog, these are called " "binary-only NMUs — there is no need in this case to trigger all other " "architectures to consider themselves out of date or requiring recompilation." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1566 msgid "" "Such recompilations require special ``magic'' version numbering, so that the " "archive maintenance tools recognize that, even though there is a new Debian " "version, there is no corresponding source update. If you get this wrong, " "the archive maintainers will reject your upload (due to lack of " "corresponding source code)." msgstr "" # type: Content of: <chapter><section><section><section><para><footnote> #: pkgs.dbk:1573 msgid "" "The ``magic'' for a recompilation-only NMU is triggered by using a suffix " "appended to the package version number, following the form b<number>. " "For instance, if the latest version you are recompiling against was version " "``2.9-3'', your NMU should carry a version of ``2.9-3+b1''. If the latest " "version was ``3.4+b1'' (i.e, a native package with a previous recompilation " "NMU), your NMU should have a version number of ``3.4+b2''. <footnote>" msgstr "" # type: Content of: <chapter><section><section><section><para><footnote><para> #: pkgs.dbk:1578 msgid "" "In the past, such NMUs used the third-level number on the Debian part of the " "revision to denote their recompilation-only status; however, this syntax was " "ambiguous with native packages and did not allow proper ordering of " "recompile-only NMUs, source NMUs, and security NMUs on the same package, and " "has therefore been abandoned in favor of this new syntax." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1586 msgid "" "Similar to initial porter uploads, the correct way of invoking " "<command>dpkg-buildpackage</command> is <literal>dpkg-buildpackage " "-B</literal> to only build the architecture-dependent parts of the package." msgstr "" # type: Content of: <chapter><section><section><section><title> #: pkgs.dbk:1593 msgid "When to do a source NMU if you are a porter" msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1595 msgid "" "Porters doing a source NMU generally follow the guidelines found in <xref " "linkend=\"nmu\"/> , just like non-porters. However, it is expected that the " "wait cycle for a porter's source NMU is smaller than for a non-porter, since " "porters have to cope with a large quantity of packages. Again, the " "situation varies depending on the distribution they are uploading to. It " "also varies whether the architecture is a candidate for inclusion into the " "next stable release; the release managers decide and announce which " "architectures are candidates." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1604 msgid "" "If you are a porter doing an NMU for `unstable', the above guidelines for " "porting should be followed, with two variations. Firstly, the acceptable " "waiting period — the time between when the bug is submitted to the BTS and " "when it is OK to do an NMU — is seven days for porters working on the " "unstable distribution. This period can be shortened if the problem is " "critical and imposes hardship on the porting effort, at the discretion of " "the porter group. (Remember, none of this is Policy, just mutually agreed " "upon guidelines.) For uploads to stable or testing, please coordinate with " "the appropriate release team first." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1615 msgid "" "Secondly, porters doing source NMUs should make sure that the bug they " "submit to the BTS should be of severity `serious' or greater. This ensures " "that a single source package can be used to compile every supported Debian " "architecture by release time. It is very important that we have one version " "of the binary and source package for all architecture in order to comply " "with many licenses." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1623 msgid "" "Porters should try to avoid patches which simply kludge around bugs in the " "current version of the compile environment, kernel, or libc. Sometimes such " "kludges can't be helped. If you have to kludge around compiler bugs and the " "like, make sure you <literal>#ifdef</literal> your work properly; also, " "document your kludge so that people know to remove it once the external " "problems have been fixed." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1631 msgid "" "Porters may also have an unofficial location where they can put the results " "of their work during the waiting period. This helps others running the port " "have the benefit of the porter's work, even during the waiting period. Of " "course, such locations have no official blessing or status, so buyer beware." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:1641 msgid "Porting infrastructure and automation" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1643 msgid "" "There is infrastructure and several tools to help automate package porting. " "This section contains a brief overview of this automation and porting to " "these tools; see the package documentation or references for full " "information." msgstr "" # type: Content of: <chapter><section><section><section><title> #: pkgs.dbk:1648 msgid "Mailing lists and web pages" msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1650 msgid "" "Web pages containing the status of each port can be found at <ulink " "url=\"&url-debian-ports;\"></ulink>." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1654 msgid "" "Each port of Debian has a mailing list. The list of porting mailing lists " "can be found at <ulink url=\"&url-debian-port-lists;\"></ulink>. These " "lists are used to coordinate porters, and to connect the users of a given " "port with the porters." msgstr "" # type: Content of: <chapter><section><section><section><title> #: pkgs.dbk:1662 msgid "Porter tools" msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1664 msgid "" "Descriptions of several porting tools can be found in <xref " "linkend=\"tools-porting\"/> ." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1672 msgid "" "The <systemitem role=\"package\">buildd</systemitem> system is used as a " "distributed, client-server build distribution system. It is usually used in " "conjunction with <emphasis>auto-builders</emphasis>, which are ``slave'' " "hosts which simply check out and attempt to auto-build packages which need " "to be ported. There is also an email interface to the system, which allows " "porters to ``check out'' a source package (usually one which cannot yet be " "auto-built) and work on it." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1681 msgid "" "<systemitem role=\"package\">buildd</systemitem> is not yet available as a " "package; however, most porting efforts are either using it currently or " "planning to use it in the near future. The actual automated builder is " "packaged as <systemitem role=\"package\">sbuild</systemitem>, see its " "description in <xref linkend=\"sbuild\"/> . The complete <systemitem " "role=\"package\">buildd</systemitem> system also collects a number of as yet " "unpackaged components which are currently very useful and in use " "continually, such as <command>andrea</command> and " "<command>wanna-build</command>." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1691 msgid "" "Some of the data produced by <systemitem " "role=\"package\">buildd</systemitem> which is generally useful to porters is " "available on the web at <ulink url=\"&url-buildd;\"></ulink>. This data " "includes nightly updated information from <command>andrea</command> (source " "dependencies) and <systemitem role=\"package\">quinn-diff</systemitem> " "(packages needing recompilation)." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1699 msgid "" "We are quite proud of this system, since it has so many possible uses. " "Independent development groups can use the system for different sub-flavors " "of Debian, which may or may not really be of general interest (for instance, " "a flavor of Debian built with <command>gcc</command> bounds checking). It " "will also enable Debian to recompile entire distributions quickly." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1706 msgid "" "The buildds admins of each arch can be contacted at the mail address " "$arch@buildd.debian.org." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:1714 msgid "When your package is <emphasis>not</emphasis> portable" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1716 msgid "" "Some packages still have issues with building and/or working on some of the " "architectures supported by Debian, and cannot be ported at all, or not " "within a reasonable amount of time. An example is a package that is " "SVGA-specific (only i386), or uses other hardware-specific features not " "supported on all architectures." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1723 msgid "" "In order to prevent broken packages from being uploaded to the archive, and " "wasting buildd time, you need to do a few things:" msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:1729 msgid "" "First, make sure your package <emphasis>does</emphasis> fail to build on " "architectures that it cannot support. There are a few ways to achieve " "this. The preferred way is to have a small testsuite during build time that " "will test the functionality, and fail if it doesn't work. This is a good " "idea anyway, as this will prevent (some) broken uploads on all " "architectures, and also will allow the package to build as soon as the " "required functionality is available." msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:1737 msgid "" "Additionally, if you believe the list of supported architectures is pretty " "constant, you should change 'any' to a list of supported architectures in " "debian/control. This way, the build will fail also, and indicate this to a " "human reader without actually trying." msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:1745 msgid "" "In order to prevent autobuilders from needlessly trying to build your " "package, it must be included in <filename>packages-arch-specific</filename>, " "a list used by the <command>wanna-build</command> script. The current " "version is available as <ulink " "url=\"&url-cvsweb;srcdep/Packages-arch-specific?cvsroot=dak\"></ulink>; " "please see the top of the file for whom to contact for changes." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1755 msgid "" "Please note that it is insufficient to only add your package to " "Packages-arch-specific without making it fail to build on unsupported " "architectures: A porter or any other person trying to build your package " "might accidently upload it without noticing it doesn't work. If in the past " "some binary packages were uploaded on unsupported architectures, request " "their removal by filing a bug against <systemitem " "role=\"package\">ftp.debian.org</systemitem>" msgstr "" # type: Content of: <chapter><section><title> #: pkgs.dbk:1768 msgid "Non-Maintainer Uploads (NMUs)" msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:1770 msgid "" "Under certain circumstances it is necessary for someone other than the " "official package maintainer to make a release of a package. This is called " "a non-maintainer upload, or NMU." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:1775 msgid "" "This section handles only source NMUs, i.e. NMUs which upload a new version " "of the package. For binary-only NMUs by porters or QA members, please see " "<xref linkend=\"binary-only-nmu\"/> . If a buildd builds and uploads a " "package, that too is strictly speaking a binary NMU. See <xref " "linkend=\"buildd\"/> for some more information." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:1782 msgid "" "The main reason why NMUs are done is when a developer needs to fix another " "developer's package in order to address serious problems or crippling bugs " "or when the package maintainer is unable to release a fix in a timely " "fashion." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:1787 msgid "" "First and foremost, it is critical that NMU patches to source should be as " "non-disruptive as possible. Do not do housekeeping tasks, do not change the " "name of modules or files, do not move directories; in general, do not fix " "things which are not broken. Keep the patch as small as possible. If " "things bother you aesthetically, talk to the Debian maintainer, talk to the " "upstream maintainer, or submit a bug. However, aesthetic changes must " "<emphasis>not</emphasis> be made in a non-maintainer upload." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:1796 msgid "" "And please remember the Hippocratic Oath: Above all, do no harm. It is " "better to leave a package with an open grave bug than applying a " "non-functional patch, or one that hides the bug instead of resolving it." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:1801 msgid "How to do a NMU" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1803 msgid "" "NMUs which fix important, serious or higher severity bugs are encouraged and " "accepted. You should endeavor to reach the current maintainer of the " "package; they might be just about to upload a fix for the problem, or have a " "better solution." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1809 msgid "" "NMUs should be made to assist a package's maintainer in resolving bugs. " "Maintainers should be thankful for that help, and NMUers should respect the " "decisions of maintainers, and try to personally help the maintainer by their " "work." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1815 msgid "" "A NMU should follow all conventions, written down in this section. For an " "upload to testing or unstable, this order of steps is recommended:" msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:1821 msgid "" "Make sure that the package's bugs that the NMU is meant to address are all " "filed in the Debian Bug Tracking System (BTS). If they are not, submit them " "immediately." msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:1828 msgid "" "Wait a few days for the response from the maintainer. If you don't get any " "response, you may want to help them by sending the patch that fixes the " "bug. Don't forget to tag the bug with the patch keyword." msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:1835 msgid "" "Wait a few more days. If you still haven't got an answer from the " "maintainer, send them a mail announcing your intent to NMU the package. " "Prepare an NMU as described in this section, and test it carefully on your " "machine (cf. <xref linkend=\"sanitycheck\"/> ). Double check that your " "patch doesn't have any unexpected side effects. Make sure your patch is as " "small and as non-disruptive as it can be." msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:1845 msgid "" "Upload your package to incoming in <filename>DELAYED/7-day</filename> (cf. " "<xref linkend=\"delayed-incoming\"/> ), send the final patch to the " "maintainer via the BTS, and explain to them that they have 7 days to react " "if they want to cancel the NMU." msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:1853 msgid "" "Follow what happens, you're responsible for any bug that you introduced with " "your NMU. You should probably use <xref linkend=\"pkg-tracking-system\"/> " "(PTS) to stay informed of the state of the package after your NMU." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1860 msgid "" "At times, the release manager or an organized group of developers can " "announce a certain period of time in which the NMU rules are relaxed. This " "usually involves shortening the period during which one is to wait before " "uploading the fixes, and shortening the DELAYED period. It is important to " "notice that even in these so-called bug squashing party times, the NMU'er " "has to file bugs and contact the developer first, and act later. Please see " "<xref linkend=\"qa-bsp\"/> for details." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1869 msgid "" "For the testing distribution, the rules may be changed by the release " "managers. Please take additional care, and acknowledge that the usual way " "for a package to enter testing is through unstable." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1874 msgid "" "For the stable distribution, please take extra care. Of course, the release " "managers may also change the rules here. Please verify before you upload " "that all your changes are OK for inclusion into the next stable release by " "the release manager." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1880 msgid "" "When a security bug is detected, the security team may do an NMU, using " "their own rules. Please refer to <xref linkend=\"bug-security\"/> for more " "information." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1885 msgid "" "For the differences for Porters NMUs, please see <xref " "linkend=\"source-nmu-when-porter\"/> ." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1889 msgid "" "Of course, it is always possible to agree on special rules with a maintainer " "(like the maintainer asking please upload this fix directly for me, and no " "diff required)." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:1896 msgid "NMU version numbering" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1898 msgid "" "Whenever you have made a change to a package, no matter how trivial, the " "version number needs to change. This enables our packing system to " "function." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1902 msgid "" "If you are doing a non-maintainer upload (NMU), you should add a new minor " "version number to the <replaceable>debian-revision</replaceable> part of the " "version number (the portion after the last hyphen). This extra minor number " "will start at `1'. For example, consider the package `foo', which is at " "version 1.1-3. In the archive, the source package control file would be " "<filename>foo_1.1-3.dsc</filename>. The upstream version is `1.1' and the " "Debian revision is `3'. The next NMU would add a new minor number `.1' to " "the Debian revision; the new source control file would be " "<filename>foo_1.1-3.1.dsc</filename>." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1913 msgid "" "The Debian revision minor number is needed to avoid stealing one of the " "package maintainer's version numbers, which might disrupt their work. It " "also has the benefit of making it visually clear that a package in the " "archive was not made by the official maintainer." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1919 msgid "" "If there is no <replaceable>debian-revision</replaceable> component in the " "version number then one should be created, starting at `0.1' (but in case of " "a debian native package still upload it as native package). If it is " "absolutely necessary for someone other than the usual maintainer to make a " "release based on a new upstream version then the person making the release " "should start with the <replaceable>debian-revision</replaceable> value " "`0.1'. The usual maintainer of a package should start their " "<replaceable>debian-revision</replaceable> numbering at `1'." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1929 msgid "" "If you upload a package to testing or stable, sometimes, you need to fork " "the version number tree. For this, version numbers like 1.1-3sarge0.1 could " "be used." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:1936 msgid "Source NMUs must have a new changelog entry" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1938 msgid "" "Anyone who is doing a source NMU must create a changelog entry, describing " "which bugs are fixed by the NMU, and generally why the NMU was required and " "what it fixed. The changelog entry will have the email address of the " "person who uploaded it in the log entry and the NMU version number in it." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1944 msgid "By convention, source NMU changelog entries start with the line" msgstr "" # type: Content of: <chapter><section><section><screen> #: pkgs.dbk:1947 #, no-wrap msgid "* Non-maintainer upload" msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:1952 msgid "Source NMUs and the Bug Tracking System" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1954 msgid "" "Maintainers other than the official package maintainer should make as few " "changes to the package as possible, and they should always send a patch as a " "unified context diff (<literal>diff -u</literal>) detailing their changes to " "the Bug Tracking System." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1960 msgid "" "What if you are simply recompiling the package? If you just need to " "recompile it for a single architecture, then you may do a binary-only NMU as " "described in <xref linkend=\"binary-only-nmu\"/> which doesn't require any " "patch to be sent. If you want the package to be recompiled for all " "architectures, then you do a source NMU as usual and you will have to send a " "patch." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1967 msgid "" "Bugs fixed by source NMUs used to be tagged fixed instead of closed, but " "since version tracking is in place, such bugs are now also closed with the " "NMU version." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1972 msgid "" "Also, after doing an NMU, you have to send the information to the existing " "bugs that are fixed by your NMU, including the unified diff. Historically, " "it was custom to open a new bug and include a patch showing all the changes " "you have made. The normal maintainer will either apply the patch or employ " "an alternate method of fixing the problem. Sometimes bugs are fixed " "independently upstream, which is another good reason to back out an NMU's " "patch. If the maintainer decides not to apply the NMU's patch but to " "release a new version, the maintainer needs to ensure that the new upstream " "version really fixes each problem that was fixed in the non-maintainer " "release." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1983 msgid "" "In addition, the normal maintainer should <emphasis>always</emphasis> retain " "the entry in the changelog file documenting the non-maintainer upload -- and " "of course, also keep the changes. If you revert some of the changes, please " "reopen the relevant bug reports." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:1991 msgid "Building source NMUs" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1993 msgid "" "Source NMU packages are built normally. Pick a distribution using the same " "rules as found in <xref linkend=\"distribution\"/> , follow the other " "instructions in <xref linkend=\"upload\"/> ." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1998 msgid "" "Make sure you do <emphasis>not</emphasis> change the value of the maintainer " "in the <filename>debian/control</filename> file. Your name as given in the " "NMU entry of the <filename>debian/changelog</filename> file will be used for " "signing the changes file." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:2006 msgid "Acknowledging an NMU" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:2008 msgid "" "If one of your packages has been NMU'ed, you have to incorporate the changes " "in your copy of the sources. This is easy, you just have to apply the patch " "that has been sent to you. Once this is done, you have to close the bugs " "that have been tagged fixed by the NMU. The easiest way is to use the " "<literal>-v</literal> option of <command>dpkg-buildpackage</command>, as " "this allows you to include just all changes since your last maintainer " "upload. Alternatively, you can close them manually by sending the required " "mails to the BTS or by adding the required <literal>closes: #nnnn</literal> " "in the changelog entry of your next upload." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:2019 msgid "" "In any case, you should not be upset by the NMU. An NMU is not a personal " "attack against the maintainer. It is a proof that someone cares enough " "about the package that they were willing to help you in your work, so you " "should be thankful. You may also want to ask them if they would be " "interested in helping you on a more frequent basis as co-maintainer or " "backup maintainer (see <xref linkend=\"collaborative-maint\"/> )." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:2029 msgid "NMU vs QA uploads" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:2031 msgid "" "Unless you know the maintainer is still active, it is wise to check the " "package to see if it has been orphaned. The current list of orphaned " "packages which haven't had their maintainer set correctly is available at " "<ulink url=\"&url-debian-qa-orphaned;\"></ulink>. If you perform an NMU on " "an improperly orphaned package, please set the maintainer to <literal>Debian " "QA Group <packages@qa.debian.org></literal>." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:2041 msgid "Who can do an NMU" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:2043 msgid "" "Only official, registered Debian Developers can do binary or source NMUs. A " "Debian Developer is someone who has their key in the Debian key ring. " "Non-developers, however, are encouraged to download the source package and " "start hacking on it to fix problems; however, rather than doing an NMU, they " "should just submit worthwhile patches to the Bug Tracking System. " "Maintainers almost always appreciate quality patches and bug reports." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:2053 msgid "Terminology" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:2055 msgid "" "There are two new terms used throughout this section: ``binary-only NMU'' " "and ``source NMU''. These terms are used with specific technical meaning " "throughout this document. Both binary-only and source NMUs are similar, " "since they involve an upload of a package by a developer who is not the " "official maintainer of that package. That is why it's a " "<emphasis>non-maintainer</emphasis> upload." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:2063 msgid "" "A source NMU is an upload of a package by a developer who is not the " "official maintainer, for the purposes of fixing a bug in the package. " "Source NMUs always involves changes to the source (even if it is just a " "change to <filename>debian/changelog</filename>). This can be either a " "change to the upstream source, or a change to the Debian bits of the " "source. Note, however, that source NMUs may also include " "architecture-dependent packages, as well as an updated Debian diff." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:2072 msgid "" "A binary-only NMU is a recompilation and upload of a binary package for a " "given architecture. As such, it is usually part of a porting effort. A " "binary-only NMU is a non-maintainer uploaded binary version of a package, " "with no source changes required. There are many cases where porters must " "fix problems in the source in order to get them to compile for their target " "architecture; that would be considered a source NMU rather than a " "binary-only NMU. As you can see, we don't distinguish in terminology " "between porter NMUs and non-porter NMUs." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:2082 msgid "" "Both classes of NMUs, source and binary-only, can be lumped under the term " "``NMU''. However, this often leads to confusion, since most people think " "``source NMU'' when they think ``NMU''. So it's best to be careful: always " "use ``binary NMU'' or ``binNMU'' for binary-only NMUs." msgstr "" # type: Content of: <chapter><section><title> #: pkgs.dbk:2092 msgid "Collaborative maintenance" msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:2094 msgid "" "Collaborative maintenance is a term describing the sharing of Debian package " "maintenance duties by several people. This collaboration is almost always a " "good idea, since it generally results in higher quality and faster bug fix " "turnaround times. It is strongly recommended that packages with a priority " "of <literal>Standard</literal> or which are part of the base set have " "co-maintainers." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:2102 msgid "" "Generally there is a primary maintainer and one or more co-maintainers. The " "primary maintainer is the person whose name is listed in the " "<literal>Maintainer</literal> field of the " "<filename>debian/control</filename> file. Co-maintainers are all the other " "maintainers." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:2108 msgid "" "In its most basic form, the process of adding a new co-maintainer is quite " "easy:" msgstr "" # type: Content of: <chapter><section><itemizedlist><listitem><para> #: pkgs.dbk:2114 msgid "" "Setup the co-maintainer with access to the sources you build the package " "from. Generally this implies you are using a network-capable version " "control system, such as <command>CVS</command> or " "<command>Subversion</command>. Alioth (see <xref linkend=\"alioth\"/> ) " "provides such tools, amongst others." msgstr "" # type: Content of: <chapter><section><itemizedlist><listitem><para> #: pkgs.dbk:2122 msgid "" "Add the co-maintainer's correct maintainer name and address to the " "<literal>Uploaders</literal> field in the global part of the " "<filename>debian/control</filename> file." msgstr "" # type: Content of: <chapter><section><itemizedlist><listitem><screen> #: pkgs.dbk:2127 #, no-wrap msgid "" "Uploaders: John Buzz <jbuzz@debian.org>, Adam Rex " "<arex@debian.org>" msgstr "" # type: Content of: <chapter><section><itemizedlist><listitem><para> #: pkgs.dbk:2132 msgid "" "Using the PTS (<xref linkend=\"pkg-tracking-system\"/> ), the co-maintainers " "should subscribe themselves to the appropriate source package." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:2138 msgid "" "Another form of collaborative maintenance is team maintenance, which is " "recommended if you maintain several packages with the same group of " "developers. In that case, the Maintainer and Uploaders field of each " "package must be managed with care. It is recommended to choose between one " "of the two following schemes:" msgstr "" # type: Content of: <chapter><section><orderedlist><listitem><para> #: pkgs.dbk:2147 msgid "" "Put the team member mainly responsible for the package in the Maintainer " "field. In the Uploaders, put the mailing list address, and the team members " "who care for the package." msgstr "" # type: Content of: <chapter><section><orderedlist><listitem><para> #: pkgs.dbk:2154 msgid "" "Put the mailing list address in the Maintainer field. In the Uploaders " "field, put the team members who care for the package. In this case, you " "must make sure the mailing list accept bug reports without any human " "interaction (like moderation for non-subscribers)." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:2162 msgid "" "In any case, it is a bad idea to automatically put all team members in the " "Uploaders field. It clutters the Developer's Package Overview listing (see " "<xref linkend=\"ddpo\"/> ) with packages one doesn't really care for, and " "creates a false sense of good maintenance." msgstr "" # type: Content of: <chapter><section><title> #: pkgs.dbk:2170 msgid "The testing distribution" msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:2172 msgid "Basics" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:2174 msgid "" "Packages are usually installed into the `testing' distribution after they " "have undergone some degree of testing in unstable." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:2178 msgid "" "They must be in sync on all architectures and mustn't have dependencies that " "make them uninstallable; they also have to have generally no known " "release-critical bugs at the time they're installed into testing. This way, " "`testing' should always be close to being a release candidate. Please see " "below for details." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:2187 msgid "Updates from unstable" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:2189 msgid "" "The scripts that update the <emphasis>testing</emphasis> distribution are " "run each day after the installation of the updated packages; these scripts " "are called <emphasis>britney</emphasis>. They generate the " "<filename>Packages</filename> files for the <emphasis>testing</emphasis> " "distribution, but they do so in an intelligent manner; they try to avoid any " "inconsistency and to use only non-buggy packages." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:2197 msgid "" "The inclusion of a package from <emphasis>unstable</emphasis> is conditional " "on the following:" msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:2203 msgid "" "The package must have been available in <emphasis>unstable</emphasis> for 2, " "5 or 10 days, depending on the urgency (high, medium or low). Please note " "that the urgency is sticky, meaning that the highest urgency uploaded since " "the previous testing transition is taken into account. Those delays may be " "doubled during a freeze, or testing transitions may be switched off " "altogether;" msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:2212 msgid "" "It must have the same number or fewer release-critical bugs than the version " "currently available in <emphasis>testing</emphasis>;" msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:2218 msgid "" "It must be available on all architectures on which it has previously been " "built in unstable. <xref linkend=\"madison\"/> may be of interest to check " "that information;" msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:2225 msgid "" "It must not break any dependency of a package which is already available in " "<emphasis>testing</emphasis>;" msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:2231 msgid "" "The packages on which it depends must either be available in " "<emphasis>testing</emphasis> or they must be accepted into " "<emphasis>testing</emphasis> at the same time (and they will be if they " "fulfill all the necessary criteria);" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:2239 msgid "" "To find out whether a package is progressing into testing or not, see the " "testing script output on the <ulink url=\"&url-testing-maint;\">web page of " "the testing distribution</ulink>, or use the program " "<command>grep-excuses</command> which is in the <systemitem " "role=\"package\">devscripts</systemitem> package. This utility can easily " "be used in a <citerefentry> <refentrytitle>crontab</refentrytitle> " "<manvolnum>5</manvolnum> </citerefentry> to keep yourself informed of the " "progression of your packages into <emphasis>testing</emphasis>." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:2250 msgid "" "The <filename>update_excuses</filename> file does not always give the " "precise reason why the package is refused; you may have to find it on your " "own by looking for what would break with the inclusion of the package. The " "<ulink url=\"&url-testing-maint;\">testing web page</ulink> gives some more " "information about the usual problems which may be causing such troubles." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:2257 msgid "" "Sometimes, some packages never enter <emphasis>testing</emphasis> because " "the set of inter-relationship is too complicated and cannot be sorted out by " "the scripts. See below for details." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:2262 msgid "" "Some further dependency analysis is shown on <ulink " "url=\"http://bjorn.haxx.se/debian/\"></ulink> — but be warned, this page " "also shows build dependencies which are not considered by britney." msgstr "" # type: Content of: <chapter><section><section><section><title> #: pkgs.dbk:2267 msgid "out-of-date" msgstr "" #. FIXME: better rename this file than document rampant professionalism? # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2270 msgid "" "For the testing migration script, outdated means: There are different " "versions in unstable for the release architectures (except for the " "architectures in fuckedarches; fuckedarches is a list of architectures that " "don't keep up (in update_out.py), but currently, it's empty). outdated has " "nothing whatsoever to do with the architectures this package has in testing." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2277 msgid "Consider this example:" msgstr "" # type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry> #: pkgs.dbk:2284 pkgs.dbk:2315 msgid "alpha" msgstr "" # type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry> #: pkgs.dbk:2285 pkgs.dbk:2316 msgid "arm" msgstr "" # type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry> #: pkgs.dbk:2290 pkgs.dbk:2322 pkgs.dbk:2382 msgid "testing" msgstr "" # type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry> #: pkgs.dbk:2291 pkgs.dbk:2296 pkgs.dbk:2323 pkgs.dbk:2324 pkgs.dbk:2331 msgid "1" msgstr "" # type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry> #: pkgs.dbk:2292 pkgs.dbk:2325 pkgs.dbk:2330 msgid "-" msgstr "" # type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry> #: pkgs.dbk:2295 pkgs.dbk:2328 pkgs.dbk:2383 msgid "unstable" msgstr "" # type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry> #: pkgs.dbk:2297 pkgs.dbk:2329 msgid "2" msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2303 msgid "" "The package is out of date on alpha in unstable, and will not go to " "testing. And removing foo from testing would not help at all, the package " "is still out of date on alpha, and will not propagate to testing." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2308 msgid "However, if ftp-master removes a package in unstable (here on arm):" msgstr "" # type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry> #: pkgs.dbk:2317 msgid "hurd-i386" msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2337 msgid "" "In this case, the package is up to date on all release architectures in " "unstable (and the extra hurd-i386 doesn't matter, as it's not a release " "architecture)." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2342 msgid "" "Sometimes, the question is raised if it is possible to allow packages in " "that are not yet built on all architectures: No. Just plainly no. (Except " "if you maintain glibc or so.)" msgstr "" # type: Content of: <chapter><section><section><section><title> #: pkgs.dbk:2349 msgid "Removals from testing" msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2351 msgid "" "Sometimes, a package is removed to allow another package in: This happens " "only to allow <emphasis>another</emphasis> package to go in if it's ready in " "every other sense. Suppose e.g. that <emphasis>a</emphasis> cannot be " "installed with the new version of <emphasis>b</emphasis>; then " "<emphasis>a</emphasis> may be removed to allow <emphasis>b</emphasis> in." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2358 msgid "" "Of course, there is another reason to remove a package from testing: It's " "just too buggy (and having a single RC-bug is enough to be in this state)." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2362 msgid "" "Furthermore, if a package has been removed from unstable, and no package in " "testing depends on it any more, then it will automatically be removed." msgstr "" # type: Content of: <chapter><section><section><section><title> #: pkgs.dbk:2368 msgid "circular dependencies" msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2370 msgid "" "A situation which is not handled very well by britney is if package " "<emphasis>a</emphasis> depends on the new version of package " "<emphasis>b</emphasis>, and vice versa." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2375 msgid "An example of this is:" msgstr "" # type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry> #: pkgs.dbk:2388 msgid "a" msgstr "" # type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry> #: pkgs.dbk:2389 msgid "1; depends: b=1" msgstr "" # type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry> #: pkgs.dbk:2390 msgid "2; depends: b=2" msgstr "" # type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry> #: pkgs.dbk:2393 msgid "b" msgstr "" # type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry> #: pkgs.dbk:2394 msgid "1; depends: a=1" msgstr "" # type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry> #: pkgs.dbk:2395 msgid "2; depends: a=2" msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2401 msgid "" "Neither package <emphasis>a</emphasis> nor package <emphasis>b</emphasis> is " "considered for update." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2405 msgid "" "Currently, this requires some manual hinting from the release team. Please " "contact them by sending mail to &email-debian-release; if this happens to " "one of your packages." msgstr "" # type: Content of: <chapter><section><section><section><title> #: pkgs.dbk:2412 msgid "influence of package in testing" msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2414 msgid "" "Generally, there is nothing that the status of a package in testing means " "for transition of the next version from unstable to testing, with two " "exceptions: If the RC-bugginess of the package goes down, it may go in even " "if it is still RC-buggy. The second exception is if the version of the " "package in testing is out of sync on the different arches: Then any arch " "might just upgrade to the version of the source package; however, this can " "happen only if the package was previously forced through, the arch is in " "fuckedarches, or there was no binary package of that arch present in " "unstable at all during the testing migration." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2424 msgid "" "In summary this means: The only influence that a package being in testing " "has on a new version of the same package is that the new version might go in " "easier." msgstr "" # type: Content of: <chapter><section><section><section><title> #: pkgs.dbk:2431 msgid "details" msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2433 msgid "If you are interested in details, this is how britney works:" msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2436 msgid "" "The packages are looked at to determine whether they are valid candidates. " "This gives the update excuses. The most common reasons why a package is not " "considered are too young, RC-bugginess, and out of date on some arches. For " "this part of britney, the release managers have hammers of various sizes to " "force britney to consider a package. (Also, the base freeze is coded in " "that part of britney.) (There is a similar thing for binary-only updates, " "but this is not described here. If you're interested in that, please peruse " "the code.)" msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2445 msgid "" "Now, the more complex part happens: Britney tries to update testing with the " "valid candidates; first, each package alone, and then larger and even larger " "sets of packages together. Each try is accepted if testing is not more " "uninstallable after the update than before. (Before and after this part, " "some hints are processed; but as only release masters can hint, this is " "probably not so important for you.)" msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2453 msgid "" "If you want to see more details, you can look it up on " "merkel:/org/&ftp-debian-org;/testing/update_out/ (or there in " "~aba/testing/update_out to see a setup with a smaller packages file). Via " "web, it's at <ulink " "url=\"http://&ftp-master-host;/testing/update_out_code/\"></ulink>" msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2460 msgid "" "The hints are available via <ulink " "url=\"http://&ftp-master-host;/testing/hints/\"></ulink>." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:2468 msgid "Direct updates to testing" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:2470 msgid "" "The testing distribution is fed with packages from unstable according to the " "rules explained above. However, in some cases, it is necessary to upload " "packages built only for testing. For that, you may want to upload to " "<emphasis>testing-proposed-updates</emphasis>." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:2476 msgid "" "Keep in mind that packages uploaded there are not automatically processed, " "they have to go through the hands of the release manager. So you'd better " "have a good reason to upload there. In order to know what a good reason is " "in the release managers' eyes, you should read the instructions that they " "regularly give on &email-debian-devel-announce;." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:2483 msgid "" "You should not upload to <emphasis>testing-proposed-updates</emphasis> when " "you can update your packages through <emphasis>unstable</emphasis>. If you " "can't (for example because you have a newer development version in " "unstable), you may use this facility, but it is recommended that you ask for " "authorization from the release manager first. Even if a package is frozen, " "updates through unstable are possible, if the upload via unstable does not " "pull in any new dependencies." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:2492 msgid "" "Version numbers are usually selected by adding the codename of the testing " "distribution and a running number, like 1.2sarge1 for the first upload " "through testing-proposed-updates of package version 1.2." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:2497 msgid "Please make sure you didn't miss any of these items in your upload:" msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:2502 msgid "" "Make sure that your package really needs to go through " "<emphasis>testing-proposed-updates</emphasis>, and can't go through " "unstable;" msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:2508 msgid "Make sure that you included only the minimal amount of changes;" msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:2513 msgid "Make sure that you included an appropriate explanation in the changelog;" msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:2518 msgid "" "Make sure that you've written <emphasis>testing</emphasis> or " "<emphasis>testing-proposed-updates</emphasis> into your target distribution;" msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:2524 msgid "" "Make sure that you've built and tested your package in " "<emphasis>testing</emphasis>, not in <emphasis>unstable</emphasis>;" msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:2530 msgid "" "Make sure that your version number is higher than the version in " "<emphasis>testing</emphasis> and " "<emphasis>testing-proposed-updates</emphasis>, and lower than in " "<emphasis>unstable</emphasis>;" msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:2537 msgid "" "After uploading and successful build on all platforms, contact the release " "team at &email-debian-release; and ask them to approve your upload." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:2545 msgid "Frequently asked questions" msgstr "" # type: Content of: <chapter><section><section><section><title> #: pkgs.dbk:2547 msgid "What are release-critical bugs, and how do they get counted?" msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2549 msgid "" "All bugs of some higher severities are by default considered " "release-critical; currently, these are critical, grave, and serious bugs." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2553 msgid "" "Such bugs are presumed to have an impact on the chances that the package " "will be released with the stable release of Debian: in general, if a package " "has open release-critical bugs filed on it, it won't get into testing, and " "consequently won't be released in stable." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2559 msgid "" "The unstable bug count are all release-critical bugs without either any " "release-tag (such as potato, woody) or with release-tag sid; also, only if " "they are neither fixed nor set to sarge-ignore. The testing bug count for a " "package is considered to be roughly the bug count of unstable count at the " "last point when the testing version equalled the unstable version." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2566 msgid "" "This will change post-sarge, as soon as we have versions in the bug tracking " "system." msgstr "" # type: Content of: <chapter><section><section><section><title> #: pkgs.dbk:2572 msgid "How could installing a package into testing possibly break other packages?" msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2574 msgid "" "The structure of the distribution archives is such that they can only " "contain one version of a package; a package is defined by its name. So when " "the source package acmefoo is installed into testing, along with its binary " "packages acme-foo-bin, acme-bar-bin, libacme-foo1 and libacme-foo-dev, the " "old version is removed." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2581 msgid "" "However, the old version may have provided a binary package with an old " "soname of a library, such as libacme-foo0. Removing the old acmefoo will " "remove libacme-foo0, which will break any packages which depend on it." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2586 msgid "" "Evidently, this mainly affects packages which provide changing sets of " "binary packages in different versions (in turn, mainly libraries). However, " "it will also affect packages upon which versioned dependencies have been " "declared of the ==, <=, or << varieties." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2592 msgid "" "When the set of binary packages provided by a source package change in this " "way, all the packages that depended on the old binaries will have to be " "updated to depend on the new binaries instead. Because installing such a " "source package into testing breaks all the packages that depended on it in " "testing, some care has to be taken now: all the depending packages must be " "updated and ready to be installed themselves so that they won't be broken, " "and, once everything is ready, manual intervention by the release manager or " "an assistant is normally required." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2602 msgid "" "If you are having problems with complicated groups of packages like this, " "contact debian-devel or debian-release for help." msgstr ""

# SOME DESCRIPTIVE TITLE # Copyright (C) YEAR Free Software Foundation, Inc. # FIRST AUTHOR , YEAR. # #, fuzzy msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" "POT-Creation-Date: 2007-07-01 21:01+0000\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME \n" "Language-Team: LANGUAGE \n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=utf-8\n" "Content-Transfer-Encoding: ENCODING" # type: Content of: #: pkgs.dbk:7 msgid "Managing Packages" msgstr "" # type: Content of: <chapter><para> #: pkgs.dbk:9 msgid "" "This chapter contains information related to creating, uploading, " "maintaining, and porting packages." msgstr "" # type: Content of: <chapter><section><title> #: pkgs.dbk:13 msgid "New packages" msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:15 msgid "" "If you want to create a new package for the Debian distribution, you should " "first check the <ulink url=\"&url-wnpp;\">Work-Needing and Prospective " "Packages (WNPP)</ulink> list. Checking the WNPP list ensures that no one is " "already working on packaging that software, and that effort is not " "duplicated. Read the <ulink url=\"&url-wnpp;\">WNPP web pages</ulink> for " "more information." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:23 msgid "" "Assuming no one else is already working on your prospective package, you " "must then submit a bug report (<xref linkend=\"submit-bug\"/> ) against the " "pseudo-package <systemitem role=\"package\">wnpp</systemitem> describing " "your plan to create a new package, including, but not limiting yourself to, " "a description of the package, the license of the prospective package, and " "the current URL where it can be downloaded from." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:31 msgid "" "You should set the subject of the bug to ``ITP: " "<replaceable>foo</replaceable> -- <replaceable>short " "description</replaceable>'', substituting the name of the new package for " "<replaceable>foo</replaceable>. The severity of the bug report must be set " "to <emphasis>wishlist</emphasis>. If you feel it's necessary, send a copy " "to &email-debian-devel; by putting the address in the " "<literal>X-Debbugs-CC:</literal> header of the message (no, don't use " "<literal>CC:</literal>, because that way the message's subject won't " "indicate the bug number)." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:41 msgid "" "Please include a <literal>Closes: " "bug#<replaceable>nnnnn</replaceable></literal> entry in the changelog of the " "new package in order for the bug report to be automatically closed once the " "new package is installed in the archive (see <xref " "linkend=\"upload-bugfix\"/> )." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:47 msgid "" "When closing security bugs include CVE numbers as well as the Closes: " "#nnnnn. This is useful for the security team to track vulnerabilities. If " "an upload is made to fix the bug before the advisory ID is known, it is " "encouraged to modify the historical changelog entry with the next upload. " "Even in this case, please include all available pointers to background " "information in the original changelog entry." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:55 msgid "" "There are a number of reasons why we ask maintainers to announce their " "intentions:" msgstr "" # type: Content of: <chapter><section><itemizedlist><listitem><para> #: pkgs.dbk:61 msgid "" "It helps the (potentially new) maintainer to tap into the experience of " "people on the list, and lets them know if anyone else is working on it " "already." msgstr "" # type: Content of: <chapter><section><itemizedlist><listitem><para> #: pkgs.dbk:67 msgid "" "It lets other people thinking about working on the package know that there " "already is a volunteer, so efforts may be shared." msgstr "" # type: Content of: <chapter><section><itemizedlist><listitem><para> #: pkgs.dbk:73 msgid "" "It lets the rest of the maintainers know more about the package than the one " "line description and the usual changelog entry ``Initial release'' that gets " "posted to <literal>debian-devel-changes</literal>." msgstr "" # type: Content of: <chapter><section><itemizedlist><listitem><para> #: pkgs.dbk:80 msgid "" "It is helpful to the people who live off unstable (and form our first line " "of testers). We should encourage these people." msgstr "" # type: Content of: <chapter><section><itemizedlist><listitem><para> #: pkgs.dbk:86 msgid "" "The announcements give maintainers and other interested parties a better " "feel of what is going on, and what is new, in the project." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:92 msgid "" "Please see <ulink url=\"http://&ftp-master-host;/REJECT-FAQ.html\"></ulink> " "for common rejection reasons for a new package." msgstr "" # type: Content of: <chapter><section><title> #: pkgs.dbk:98 msgid "Recording changes in the package" msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:100 msgid "" "Changes that you make to the package need to be recorded in the " "<filename>debian/changelog</filename>. These changes should provide a " "concise description of what was changed, why (if it's in doubt), and note if " "any bugs were closed. They also record when the package was completed. " "This file will be installed in " "<filename>/usr/share/doc/<replaceable>package</replaceable>/changelog.Debian.gz</filename>, " "or " "<filename>/usr/share/doc/<replaceable>package</replaceable>/changelog.gz</filename> " "for native packages." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:111 msgid "" "The <filename>debian/changelog</filename> file conforms to a certain " "structure, with a number of different fields. One field of note, the " "<emphasis>distribution</emphasis>, is described in <xref " "linkend=\"distribution\"/> . More information about the structure of this " "file can be found in the Debian Policy section titled " "<filename>debian/changelog</filename>." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:119 msgid "" "Changelog entries can be used to automatically close Debian bugs when the " "package is installed into the archive. See <xref " "linkend=\"upload-bugfix\"/> ." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:123 msgid "" "It is conventional that the changelog entry of a package that contains a new " "upstream version of the software looks like this:" msgstr "" # type: Content of: <chapter><section><screen> #: pkgs.dbk:127 #, no-wrap msgid "* new upstream version" msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:130 msgid "" "There are tools to help you create entries and finalize the " "<filename>changelog</filename> for release — see <xref " "linkend=\"devscripts\"/> and <xref linkend=\"dpkg-dev-el\"/> ." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:135 msgid "See also <xref linkend=\"bpp-debian-changelog\"/> ." msgstr "" # type: Content of: <chapter><section><title> #: pkgs.dbk:140 msgid "Testing the package" msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:142 msgid "" "Before you upload your package, you should do basic testing on it. At a " "minimum, you should try the following activities (you'll need to have an " "older version of the same Debian package around):" msgstr "" # type: Content of: <chapter><section><itemizedlist><listitem><para> #: pkgs.dbk:149 msgid "" "Install the package and make sure the software works, or upgrade the package " "from an older version to your new version if a Debian package for it already " "exists." msgstr "" # type: Content of: <chapter><section><itemizedlist><listitem><para> #: pkgs.dbk:156 msgid "" "Run <command>lintian</command> over the package. You can run " "<command>lintian</command> as follows: <literal>lintian -v " "<replaceable>package-version</replaceable>.changes</literal>. This will " "check the source package as well as the binary package. If you don't " "understand the output that <command>lintian</command> generates, try adding " "the <literal>-i</literal> switch, which will cause " "<command>lintian</command> to output a very verbose description of the " "problem." msgstr "" # type: Content of: <chapter><section><itemizedlist><listitem><para> #: pkgs.dbk:165 msgid "" "Normally, a package should <emphasis>not</emphasis> be uploaded if it causes " "lintian to emit errors (they will start with <literal>E</literal>)." msgstr "" # type: Content of: <chapter><section><itemizedlist><listitem><para> #: pkgs.dbk:169 msgid "" "For more information on <command>lintian</command>, see <xref " "linkend=\"lintian\"/> ." msgstr "" # type: Content of: <chapter><section><itemizedlist><listitem><para> #: pkgs.dbk:175 msgid "" "Optionally run <xref linkend=\"debdiff\"/> to analyze changes from an older " "version, if one exists." msgstr "" # type: Content of: <chapter><section><itemizedlist><listitem><para> #: pkgs.dbk:181 msgid "" "Downgrade the package to the previous version (if one exists) — this tests " "the <filename>postrm</filename> and <filename>prerm</filename> scripts." msgstr "" # type: Content of: <chapter><section><itemizedlist><listitem><para> #: pkgs.dbk:187 msgid "Remove the package, then reinstall it." msgstr "" # type: Content of: <chapter><section><itemizedlist><listitem><para> #: pkgs.dbk:192 msgid "" "Copy the source package in a different directory and try unpacking it and " "rebuilding it. This tests if the package relies on existing files outside " "of it, or if it relies on permissions being preserved on the files shipped " "inside the .diff.gz file." msgstr "" # type: Content of: <chapter><section><title> #: pkgs.dbk:202 msgid "Layout of the source package" msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:204 msgid "There are two types of Debian source packages:" msgstr "" # type: Content of: <chapter><section><itemizedlist><listitem><para> #: pkgs.dbk:209 msgid "" "the so-called <emphasis>native</emphasis> packages, where there is no " "distinction between the original sources and the patches applied for Debian" msgstr "" # type: Content of: <chapter><section><itemizedlist><listitem><para> #: pkgs.dbk:215 msgid "" "the (more common) packages where there's an original source tarball file " "accompanied by another file that contains the patches applied for Debian" msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:221 msgid "" "For the native packages, the source package includes a Debian source control " "file (<literal>.dsc</literal>) and the source tarball " "(<literal>.tar.gz</literal>). A source package of a non-native package " "includes a Debian source control file, the original source tarball " "(<literal>.orig.tar.gz</literal>) and the Debian patches " "(<literal>.diff.gz</literal>)." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:229 msgid "" "Whether a package is native or not is determined when it is built by " "<citerefentry> <refentrytitle>dpkg-buildpackage</refentrytitle> " "<manvolnum>1</manvolnum> </citerefentry>. The rest of this section relates " "only to non-native packages." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:235 msgid "" "The first time a version is uploaded which corresponds to a particular " "upstream version, the original source tar file should be uploaded and " "included in the <filename>.changes</filename> file. Subsequently, this very " "same tar file should be used to build the new diffs and " "<filename>.dsc</filename> files, and will not need to be re-uploaded." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:242 msgid "" "By default, <command>dpkg-genchanges</command> and " "<command>dpkg-buildpackage</command> will include the original source tar " "file if and only if the Debian revision part of the source version number is " "0 or 1, indicating a new upstream version. This behavior may be modified by " "using <literal>-sa</literal> to always include it or <literal>-sd</literal> " "to always leave it out." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:250 msgid "" "If no original source is included in the upload, the original source " "tar-file used by <command>dpkg-source</command> when constructing the " "<filename>.dsc</filename> file and diff to be uploaded " "<emphasis>must</emphasis> be byte-for-byte identical with the one already in " "the archive." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:257 msgid "" "Please notice that, in non-native packages, permissions on files that are " "not present in the .orig.tar.gz will not be preserved, as diff does not " "store file permissions in the patch." msgstr "" # type: Content of: <chapter><section><title> #: pkgs.dbk:264 msgid "Picking a distribution" msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:266 msgid "" "Each upload needs to specify which distribution the package is intended " "for. The package build process extracts this information from the first " "line of the <filename>debian/changelog</filename> file and places it in the " "<literal>Distribution</literal> field of the <literal>.changes</literal> " "file." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:272 msgid "" "There are several possible values for this field: `stable', `unstable', " "`testing-proposed-updates' and `experimental'. Normally, packages are " "uploaded into <emphasis>unstable</emphasis>." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:277 msgid "" "Actually, there are two other possible distributions: `stable-security' and " "`testing-security', but read <xref linkend=\"bug-security\"/> for more " "information on those." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:282 msgid "" "It is not possible to upload a package into several distributions at the " "same time." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:286 msgid "Special case: uploads to the <emphasis>stable</emphasis> distribution" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:288 msgid "" "Uploading to <emphasis>stable</emphasis> means that the package will " "transfered to the <emphasis>p-u-new</emphasis>-queue for review by the " "stable release managers, and if approved will be installed in " "<filename>stable-proposed-updates</filename> directory of the Debian " "archive. From there, it will be included in <emphasis>stable</emphasis> " "with the next point release." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:296 msgid "" "Extra care should be taken when uploading to <emphasis>stable</emphasis>. " "Basically, a package should only be uploaded to stable if one of the " "following happens:" msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:303 msgid "a truly critical functionality problem" msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:308 msgid "the package becomes uninstallable" msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:313 msgid "a released architecture lacks the package" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:318 msgid "" "In the past, uploads to <emphasis>stable</emphasis> were used to address " "security problems as well. However, this practice is deprecated, as uploads " "used for Debian security advisories are automatically copied to the " "appropriate <filename>proposed-updates</filename> archive when the advisory " "is released. See <xref linkend=\"bug-security\"/> for detailed information " "on handling security problems." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:326 msgid "" "Changing anything else in the package that isn't important is discouraged, " "because even trivial fixes can cause bugs later on." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:330 msgid "" "Packages uploaded to <emphasis>stable</emphasis> need to be compiled on " "systems running <emphasis>stable</emphasis>, so that their dependencies are " "limited to the libraries (and other packages) available in " "<emphasis>stable</emphasis>; for example, a package uploaded to " "<emphasis>stable</emphasis> that depends on a library package that only " "exists in unstable will be rejected. Making changes to dependencies of " "other packages (by messing with <literal>Provides</literal> or shlibs " "files), possibly making those other packages uninstallable, is strongly " "discouraged." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:340 msgid "" "The Release Team (which can be reached at &email-debian-release;) will " "regularly evaluate the uploads To " "<emphasis>stable-proposed-updates</emphasis> and decide if your package can " "be included in <emphasis>stable</emphasis>. Please be clear (and verbose, " "if necessary) in your changelog entries for uploads to " "<emphasis>stable</emphasis>, because otherwise the package won't be " "considered for inclusion." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:349 msgid "" "It's best practice to speak with the stable release manager " "<emphasis>before</emphasis> uploading to " "<emphasis>stable</emphasis>/<emphasis>stable-proposed-updates</emphasis>, so " "that the uploaded package fits the needs of the next point release." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:357 msgid "" "Special case: uploads to " "<emphasis>testing/testing-proposed-updates</emphasis>" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:359 msgid "" "Please see the information in the <link linkend=\"t-p-u\">testing " "section</link> for details." msgstr "" # type: Content of: <chapter><section><title> #: pkgs.dbk:367 msgid "Uploading a package" msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:369 msgid "Uploading to <literal>ftp-master</literal>" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:371 msgid "" "To upload a package, you should upload the files (including the signed " "changes and dsc-file) with anonymous ftp to " "<literal>&ftp-master-host;</literal> in the directory <ulink " "url=\"ftp://&ftp-master-host;&upload-queue;\">&upload-queue;</ulink>. To " "get the files processed there, they need to be signed with a key in the " "debian keyring." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:379 msgid "" "Please note that you should transfer the changes file last. Otherwise, your " "upload may be rejected because the archive maintenance software will parse " "the changes file and see that not all files have been uploaded." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:384 msgid "" "You may also find the Debian packages <xref linkend=\"dupload\"/> or <xref " "linkend=\"dput\"/> useful when uploading packages. These handy programs " "help automate the process of uploading packages into Debian." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:389 msgid "" "For removing packages, please see the README file in that ftp directory, and " "the Debian package <xref linkend=\"dcut\"/> ." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:395 msgid "Uploading to <literal>non-US</literal>" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:397 msgid "" "<emphasis>Note:</emphasis> non-us was discontinued with the release of " "sarge." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:402 msgid "Delayed uploads" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:404 msgid "" "Delayed uploads are done for the moment via the delayed queue at gluck. The " "upload-directory is " "<literal>gluck:~tfheen/DELAYED/[012345678]-day</literal>. 0-day is uploaded " "multiple times per day to ftp-master." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:409 msgid "With a fairly recent dput, this section" msgstr "" # type: Content of: <chapter><section><section><screen> #: pkgs.dbk:412 #, no-wrap msgid "" "[tfheen_delayed]\n" "method = scp\n" "fqdn = gluck.debian.org\n" "incoming = ~tfheen" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:418 msgid "in ~/.dput.cf should work fine for uploading to the DELAYED queue." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:421 msgid "" "<emphasis>Note:</emphasis> Since this upload queue goes to " "<literal>ftp-master</literal>, the prescription found in <xref " "linkend=\"upload-ftp-master\"/> applies here as well." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:428 msgid "Security uploads" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:430 msgid "" "Do <emphasis role=\"strong\">NOT</emphasis> upload a package to the security " "upload queue (oldstable-security, stable-security, etc.) without prior " "authorization from the security team. If the package does not exactly meet " "the team's requirements, it will cause many problems and delays in dealing " "with the unwanted upload. For details, please see section <xref " "linkend=\"bug-security\"/> ." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:440 msgid "Other upload queues" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:442 msgid "" "The scp queues on ftp-master, and security are mostly unusable due to the " "login restrictions on those hosts." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:446 msgid "" "The anonymous queues on ftp.uni-erlangen.de and ftp.uk.debian.org are " "currently down. Work is underway to resurrect them." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:450 msgid "" "The queues on master.debian.org, samosa.debian.org, master.debian.or.jp, and " "ftp.chiark.greenend.org.uk are down permanently, and will not be " "resurrected. The queue in Japan will be replaced with a new queue on " "hp.debian.or.jp some day." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:456 msgid "" "For the time being, the anonymous ftp queue on auric.debian.org (the former " "ftp-master) works, but it is deprecated and will be removed at some point in " "the future." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:463 msgid "Notification that a new package has been installed" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:465 msgid "" "The Debian archive maintainers are responsible for handling package " "uploads. For the most part, uploads are automatically handled on a daily " "basis by the archive maintenance tools, <command>katie</command>. " "Specifically, updates to existing packages to the `unstable' distribution " "are handled automatically. In other cases, notably new packages, placing " "the uploaded package into the distribution is handled manually. When " "uploads are handled manually, the change to the archive may take up to a " "month to occur. Please be patient." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:474 msgid "" "In any case, you will receive an email notification indicating that the " "package has been added to the archive, which also indicates which bugs will " "be closed by the upload. Please examine this notification carefully, " "checking if any bugs you meant to close didn't get triggered." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:480 msgid "" "The installation notification also includes information on what section the " "package was inserted into. If there is a disparity, you will receive a " "separate email notifying you of that. Read on below." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:485 msgid "" "Note that if you upload via queues, the queue daemon software will also send " "you a notification by email." msgstr "" # type: Content of: <chapter><section><title> #: pkgs.dbk:493 msgid "Specifying the package section, subsection and priority" msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:495 msgid "" "The <filename>debian/control</filename> file's <literal>Section</literal> " "and <literal>Priority</literal> fields do not actually specify where the " "file will be placed in the archive, nor its priority. In order to retain " "the overall integrity of the archive, it is the archive maintainers who have " "control over these fields. The values in the " "<filename>debian/control</filename> file are actually just hints." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:503 msgid "" "The archive maintainers keep track of the canonical sections and priorities " "for packages in the <emphasis>override file</emphasis>. If there is a " "disparity between the <emphasis>override file</emphasis> and the package's " "fields as indicated in <filename>debian/control</filename>, then you will " "receive an email noting the divergence when the package is installed into " "the archive. You can either correct your " "<filename>debian/control</filename> file for your next upload, or else you " "may wish to make a change in the <emphasis>override file</emphasis>." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:513 msgid "" "To alter the actual section that a package is put in, you need to first make " "sure that the <filename>debian/control</filename> file in your package is " "accurate. Next, send an email &email-override; or submit a bug against " "<systemitem role=\"package\">ftp.debian.org</systemitem> requesting that the " "section or priority for your package be changed from the old section or " "priority to the new one. Be sure to explain your reasoning." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:521 msgid "" "For more information about <emphasis>override files</emphasis>, see " "<citerefentry> <refentrytitle>dpkg-scanpackages</refentrytitle> " "<manvolnum>1</manvolnum> </citerefentry> and <ulink " "url=\"&url-bts-devel;#maintincorrect\"></ulink>." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:527 msgid "" "Note that the <literal>Section</literal> field describes both the section as " "well as the subsection, which are described in <xref " "linkend=\"archive-sections\"/> . If the section is main, it should be " "omitted. The list of allowable subsections can be found in <ulink " "url=\"&url-debian-policy;ch-archive.html#s-subsections\"></ulink>." msgstr "" # type: Content of: <chapter><section><title> #: pkgs.dbk:536 msgid "Handling bugs" msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:538 msgid "" "Every developer has to be able to work with the Debian <ulink " "url=\"&url-bts;\">bug tracking system</ulink>. This includes knowing how to " "file bug reports properly (see <xref linkend=\"submit-bug\"/> ), how to " "update them and reorder them, and how to process and close them." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:544 msgid "" "The bug tracking system's features are described in the <ulink " "url=\"&url-bts-devel;\">BTS documentation for developers</ulink>. This " "includes closing bugs, sending followup messages, assigning severities and " "tags, marking bugs as forwarded, and other issues." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:550 msgid "" "Operations such as reassigning bugs to other packages, merging separate bug " "reports about the same issue, or reopening bugs when they are prematurely " "closed, are handled using the so-called control mail server. All of the " "commands available on this server are described in the <ulink " "url=\"&url-bts-control;\">BTS control server documentation</ulink>." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:558 msgid "Monitoring bugs" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:560 msgid "" "If you want to be a good maintainer, you should periodically check the " "<ulink url=\"&url-bts;\">Debian bug tracking system (BTS)</ulink> for your " "packages. The BTS contains all the open bugs against your packages. You " "can check them by browsing this page: " "<literal>http://&bugs-host;/<replaceable>yourlogin</replaceable>@debian.org</literal>." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:567 msgid "" "Maintainers interact with the BTS via email addresses at " "<literal>&bugs-host;</literal>. Documentation on available commands can be " "found at <ulink url=\"&url-bts;\"></ulink>, or, if you have installed the " "<systemitem role=\"package\">doc-debian</systemitem> package, you can look " "at the local files &file-bts-docs;." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:574 msgid "" "Some find it useful to get periodic reports on open bugs. You can add a " "cron job such as the following if you want to get a weekly email outlining " "all the open bugs against your packages:" msgstr "" # type: Content of: <chapter><section><section><screen> #: pkgs.dbk:579 #, no-wrap msgid "" "# ask for weekly reports of bugs in my packages\n" "&cron-bug-report;" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:583 msgid "" "Replace <replaceable>address</replaceable> with your official Debian " "maintainer address." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:589 msgid "Responding to bugs" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:591 msgid "" "When responding to bugs, make sure that any discussion you have about bugs " "is sent both to the original submitter of the bug, and to the bug itself " "(e.g., <email>123@&bugs-host;</email>). If you're writing a new mail and " "you don't remember the submitter email address, you can use the " "<email>123-submitter@&bugs-host;</email> email to contact the submitter " "<emphasis>and</emphasis> to record your mail within the bug log (that means " "you don't need to send a copy of the mail to " "<email>123@&bugs-host;</email>)." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:600 msgid "" "If you get a bug which mentions FTBFS, this means Fails to build from " "source. Porters frequently use this acronym." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:604 msgid "" "Once you've dealt with a bug report (e.g. fixed it), mark it as " "<emphasis>done</emphasis> (close it) by sending an explanation message to " "<email>123-done@&bugs-host;</email>. If you're fixing a bug by changing and " "uploading the package, you can automate bug closing as described in <xref " "linkend=\"upload-bugfix\"/> ." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:611 msgid "" "You should <emphasis>never</emphasis> close bugs via the bug server " "<literal>close</literal> command sent to &email-bts-control;. If you do so, " "the original submitter will not receive any information about why the bug " "was closed." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:619 msgid "Bug housekeeping" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:621 msgid "" "As a package maintainer, you will often find bugs in other packages or have " "bugs reported against your packages which are actually bugs in other " "packages. The bug tracking system's features are described in the <ulink " "url=\"&url-bts-devel;\">BTS documentation for Debian developers</ulink>. " "Operations such as reassigning, merging, and tagging bug reports are " "described in the <ulink url=\"&url-bts-control;\">BTS control server " "documentation</ulink>. This section contains some guidelines for managing " "your own bugs, based on the collective Debian developer experience." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:632 msgid "" "Filing bugs for problems that you find in other packages is one of the civic " "obligations of maintainership, see <xref linkend=\"submit-bug\"/> for " "details. However, handling the bugs in your own packages is even more " "important." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:637 msgid "Here's a list of steps that you may follow to handle a bug report:" msgstr "" # type: Content of: <chapter><section><section><orderedlist><listitem><para> #: pkgs.dbk:642 msgid "" "Decide whether the report corresponds to a real bug or not. Sometimes users " "are just calling a program in the wrong way because they haven't read the " "documentation. If you diagnose this, just close the bug with enough " "information to let the user correct their problem (give pointers to the good " "documentation and so on). If the same report comes up again and again you " "may ask yourself if the documentation is good enough or if the program " "shouldn't detect its misuse in order to give an informative error message. " "This is an issue that may need to be brought up with the upstream author." msgstr "" # type: Content of: <chapter><section><section><orderedlist><listitem><para> #: pkgs.dbk:652 msgid "" "If the bug submitter disagrees with your decision to close the bug, they may " "reopen it until you find an agreement on how to handle it. If you don't " "find any, you may want to tag the bug <literal>wontfix</literal> to let " "people know that the bug exists but that it won't be corrected. If this " "situation is unacceptable, you (or the submitter) may want to require a " "decision of the technical committee by reassigning the bug to <systemitem " "role=\"package\">tech-ctte</systemitem> (you may use the clone command of " "the BTS if you wish to keep it reported against your package). Before doing " "so, please read the <ulink url=\"&url-tech-ctte;\">recommended " "procedure</ulink>." msgstr "" # type: Content of: <chapter><section><section><orderedlist><listitem><para> #: pkgs.dbk:666 msgid "" "If the bug is real but it's caused by another package, just reassign the bug " "to the right package. If you don't know which package it should be " "reassigned to, you should ask for help on <link " "linkend=\"irc-channels\">IRC</link> or on &email-debian-devel;. Please make " "sure that the maintainer(s) of the package the bug is reassigned to know why " "you reassigned it." msgstr "" # type: Content of: <chapter><section><section><orderedlist><listitem><para> #: pkgs.dbk:674 msgid "" "Sometimes you also have to adjust the severity of the bug so that it matches " "our definition of the severity. That's because people tend to inflate the " "severity of bugs to make sure their bugs are fixed quickly. Some bugs may " "even be dropped to wishlist severity when the requested change is just " "cosmetic." msgstr "" # type: Content of: <chapter><section><section><orderedlist><listitem><para> #: pkgs.dbk:682 msgid "" "If the bug is real but the same problem has already been reported by someone " "else, then the two relevant bug reports should be merged into one using the " "merge command of the BTS. In this way, when the bug is fixed, all of the " "submitters will be informed of this. (Note, however, that emails sent to " "one bug report's submitter won't automatically be sent to the other report's " "submitter.) For more details on the technicalities of the merge command and " "its relative, the unmerge command, see the BTS control server documentation." msgstr "" # type: Content of: <chapter><section><section><orderedlist><listitem><para> #: pkgs.dbk:693 msgid "" "The bug submitter may have forgotten to provide some information, in which " "case you have to ask them for the required information. You may use the " "<literal>moreinfo</literal> tag to mark the bug as such. Moreover if you " "can't reproduce the bug, you tag it <literal>unreproducible</literal>. " "Anyone who can reproduce the bug is then invited to provide more information " "on how to reproduce it. After a few months, if this information has not " "been sent by someone, the bug may be closed." msgstr "" # type: Content of: <chapter><section><section><orderedlist><listitem><para> #: pkgs.dbk:704 msgid "" "If the bug is related to the packaging, you just fix it. If you are not " "able to fix it yourself, then tag the bug as <literal>help</literal>. You " "can also ask for help on &email-debian-devel; or &email-debian-qa;. If it's " "an upstream problem, you have to forward it to the upstream author. " "Forwarding a bug is not enough, you have to check at each release if the bug " "has been fixed or not. If it has, you just close it, otherwise you have to " "remind the author about it. If you have the required skills you can prepare " "a patch that fixes the bug and send it to the author at the same time. Make " "sure to send the patch to the BTS and to tag the bug as " "<literal>patch</literal>." msgstr "" # type: Content of: <chapter><section><section><orderedlist><listitem><para> #: pkgs.dbk:718 msgid "" "If you have fixed a bug in your local copy, or if a fix has been committed " "to the CVS repository, you may tag the bug as <literal>pending</literal> to " "let people know that the bug is corrected and that it will be closed with " "the next upload (add the <literal>closes:</literal> in the " "<filename>changelog</filename>). This is particularly useful if you are " "several developers working on the same package." msgstr "" # type: Content of: <chapter><section><section><orderedlist><listitem><para> #: pkgs.dbk:728 msgid "" "Once a corrected package is available in the <emphasis>unstable</emphasis> " "distribution, you can close the bug. This can be done automatically, read " "<xref linkend=\"upload-bugfix\"/> ." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:737 msgid "When bugs are closed by new uploads" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:739 msgid "" "As bugs and problems are fixed in your packages, it is your responsibility " "as the package maintainer to close these bugs. However, you should not " "close a bug until the package which fixes the bug has been accepted into the " "Debian archive. Therefore, once you get notification that your updated " "package has been installed into the archive, you can and should close the " "bug in the BTS. Also, the bug should be closed with the correct version." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:747 msgid "" "However, it's possible to avoid having to manually close bugs after the " "upload — just list the fixed bugs in your " "<filename>debian/changelog</filename> file, following a certain syntax, and " "the archive maintenance software will close the bugs for you. For example:" msgstr "" # type: Content of: <chapter><section><section><screen> #: pkgs.dbk:753 #, no-wrap msgid "" "acme-cannon (3.1415) unstable; urgency=low\n" "\n" " * Frobbed with options (closes: Bug#98339)\n" " * Added safety to prevent operator dismemberment, closes: bug#98765,\n" " bug#98713, #98714.\n" " * Added man page. Closes: #98725." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:761 msgid "" "Technically speaking, the following Perl regular expression describes how " "bug closing changelogs are identified:" msgstr "" # type: Content of: <chapter><section><section><screen> #: pkgs.dbk:765 #, no-wrap msgid "/closes:\\s*(?:bug)?\\#\\s*\\d+(?:,\\s*(?:bug)?\\#\\s*\\d+)*/ig" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:768 msgid "" "We prefer the <literal>closes: #<replaceable>XXX</replaceable></literal> " "syntax, as it is the most concise entry and the easiest to integrate with " "the text of the <filename>changelog</filename>. Unless specified different " "by the <replaceable>-v</replaceable>-switch to " "<command>dpkg-buildpackage</command>, only the bugs closed in the most " "recent changelog entry are closed (basically, exactly the bugs mentioned in " "the changelog-part in the <filename>.changes</filename> file are closed)." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:777 msgid "" "Historically, uploads identified as <link linkend=\"nmu\">Non-maintainer " "upload (NMU)</link> were tagged <literal>fixed</literal> instead of being " "closed, but that practice was ceased with the advent of version-tracking. " "The same applied to the tag <literal>fixed-in-experimental</literal>." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:783 msgid "" "If you happen to mistype a bug number or forget a bug in the changelog " "entries, don't hesitate to undo any damage the error caused. To reopen " "wrongly closed bugs, send a <literal>reopen " "<replaceable>XXX</replaceable></literal> command to the bug tracking " "system's control address, &email-bts-control;. To close any remaining bugs " "that were fixed by your upload, email the <filename>.changes</filename> file " "to <email>XXX-done@&bugs-host;</email>, where <replaceable>XXX</replaceable> " "is the bug number, and put Version: YYY and an empty line as the first two " "lines of the body of the email, where <replaceable>YYY</replaceable> is the " "first version where the bug has been fixed." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:795 msgid "" "Bear in mind that it is not obligatory to close bugs using the changelog as " "described above. If you simply want to close bugs that don't have anything " "to do with an upload you made, do it by emailing an explanation to " "<email>XXX-done@&bugs-host;</email>. Do <emphasis " "role=\"strong\">not</emphasis> close bugs in the changelog entry of a " "version if the changes in that version of the package don't have any bearing " "on the bug." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:803 msgid "" "For general information on how to write your changelog entries, see <xref " "linkend=\"bpp-debian-changelog\"/> ." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:809 msgid "Handling security-related bugs" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:811 msgid "" "Due to their sensitive nature, security-related bugs must be handled " "carefully. The Debian Security Team exists to coordinate this activity, " "keeping track of outstanding security problems, helping maintainers with " "security problems or fixing them themselves, sending security advisories, " "and maintaining security.debian.org." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:820 msgid "" "When you become aware of a security-related bug in a Debian package, whether " "or not you are the maintainer, collect pertinent information about the " "problem, and promptly contact the security team at &email-security-team; as " "soon as possible. <emphasis role=\"strong\">DO NOT UPLOAD</emphasis> any " "packages for stable; the security team will do that. Useful information " "includes, for example:" msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:830 msgid "" "Which versions of the package are known to be affected by the bug. Check " "each version that is present in a supported Debian release, as well as " "testing and unstable." msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:837 msgid "The nature of the fix, if any is available (patches are especially helpful)" msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:842 msgid "" "Any fixed packages that you have prepared yourself (send only the " "<literal>.diff.gz</literal> and <literal>.dsc</literal> files and read <xref " "linkend=\"bug-security-building\"/> first)" msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:849 msgid "" "Any assistance you can provide to help with testing (exploits, regression " "testing, etc.)" msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:855 msgid "" "Any information needed for the advisory (see <xref " "linkend=\"bug-security-advisories\"/> )" msgstr "" # type: Content of: <chapter><section><section><section><title> #: pkgs.dbk:861 msgid "Confidentiality" msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:863 msgid "" "Unlike most other activities within Debian, information about security " "issues must sometimes be kept private for a time. This allows software " "distributors to coordinate their disclosure in order to minimize their " "users' exposure. Whether this is the case depends on the nature of the " "problem and corresponding fix, and whether it is already a matter of public " "knowledge." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:870 msgid "There are several ways developers can learn of a security problem:" msgstr "" # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> #: pkgs.dbk:875 msgid "they notice it on a public forum (mailing list, web site, etc.)" msgstr "" # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> #: pkgs.dbk:880 msgid "someone files a bug report" msgstr "" # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> #: pkgs.dbk:885 msgid "someone informs them via private email" msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:890 msgid "" "In the first two cases, the information is public and it is important to " "have a fix as soon as possible. In the last case, however, it might not be " "public information. In that case there are a few possible options for " "dealing with the problem:" msgstr "" # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> #: pkgs.dbk:898 msgid "" "If the security exposure is minor, there is sometimes no need to keep the " "problem a secret and a fix should be made and released." msgstr "" # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> #: pkgs.dbk:904 msgid "" "If the problem is severe, it is preferable to share the information with " "other vendors and coordinate a release. The security team keeps in contact " "with the various organizations and individuals and can take care of that." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:911 msgid "" "In all cases if the person who reports the problem asks that it not be " "disclosed, such requests should be honored, with the obvious exception of " "informing the security team in order that a fix may be produced for a stable " "release of Debian. When sending confidential information to the security " "team, be sure to mention this fact." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:918 msgid "" "Please note that if secrecy is needed you may not upload a fix to unstable " "(or anywhere else, such as a public CVS repository). It is not sufficient " "to obfuscate the details of the change, as the code itself is public, and " "can (and will) be examined by the general public." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:924 msgid "" "There are two reasons for releasing information even though secrecy is " "requested: the problem has been known for a while, or the problem or exploit " "has become public." msgstr "" # type: Content of: <chapter><section><section><section><title> #: pkgs.dbk:931 msgid "Security Advisories" msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:933 msgid "" "Security advisories are only issued for the current, released stable " "distribution, and <emphasis>not</emphasis> for testing or unstable. When " "released, advisories are sent to the &email-debian-security-announce; " "mailing list and posted on <ulink " "url=\"&url-debian-security-advisories;\">the security web page</ulink>. " "Security advisories are written and posted by the security team. However " "they certainly do not mind if a maintainer can supply some of the " "information for them, or write part of the text. Information that should be " "in an advisory includes:" msgstr "" # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> #: pkgs.dbk:946 msgid "A description of the problem and its scope, including:" msgstr "" # type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para> #: pkgs.dbk:951 msgid "The type of problem (privilege escalation, denial of service, etc.)" msgstr "" # type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para> #: pkgs.dbk:956 msgid "What privileges may be gained, and by whom (if any)" msgstr "" # type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para> #: pkgs.dbk:961 msgid "How it can be exploited" msgstr "" # type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para> #: pkgs.dbk:966 msgid "Whether it is remotely or locally exploitable" msgstr "" # type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para> #: pkgs.dbk:971 msgid "How the problem was fixed" msgstr "" # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> #: pkgs.dbk:976 msgid "This information allows users to assess the threat to their systems." msgstr "" # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> #: pkgs.dbk:981 msgid "Version numbers of affected packages" msgstr "" # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> #: pkgs.dbk:986 msgid "Version numbers of fixed packages" msgstr "" # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> #: pkgs.dbk:991 msgid "" "Information on where to obtain the updated packages (usually from the Debian " "security archive)" msgstr "" # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> #: pkgs.dbk:997 msgid "" "References to upstream advisories, <ulink " "url=\"http://cve.mitre.org\">CVE</ulink> identifiers, and any other " "information useful in cross-referencing the vulnerability" msgstr "" # type: Content of: <chapter><section><section><section><title> #: pkgs.dbk:1006 msgid "Preparing packages to address security issues" msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1008 msgid "" "One way that you can assist the security team in their duties is to provide " "them with fixed packages suitable for a security advisory for the stable " "Debian release." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1013 msgid "" "When an update is made to the stable release, care must be taken to avoid " "changing system behavior or introducing new bugs. In order to do this, make " "as few changes as possible to fix the bug. Users and administrators rely on " "the exact behavior of a release once it is made, so any change that is made " "might break someone's system. This is especially true of libraries: make " "sure you never change the API or ABI, no matter how small the change." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1021 msgid "" "This means that moving to a new upstream version is not a good solution. " "Instead, the relevant changes should be back-ported to the version present " "in the current stable Debian release. Generally, upstream maintainers are " "willing to help if needed. If not, the Debian security team may be able to " "help." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1027 msgid "" "In some cases, it is not possible to back-port a security fix, for example " "when large amounts of source code need to be modified or rewritten. If this " "happens, it may be necessary to move to a new upstream version. However, " "this is only done in extreme situations, and you must always coordinate that " "with the security team beforehand." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1034 msgid "" "Related to this is another important guideline: always test your changes. " "If you have an exploit available, try it and see if it indeed succeeds on " "the unpatched package and fails on the fixed package. Test other, normal " "actions as well, as sometimes a security fix can break seemingly unrelated " "features in subtle ways." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1041 msgid "" "Do <emphasis role=\"strong\">NOT</emphasis> include any changes in your " "package which are not directly related to fixing the vulnerability. These " "will only need to be reverted, and this wastes time. If there are other " "bugs in your package that you would like to fix, make an upload to " "proposed-updates in the usual way, after the security advisory is issued. " "The security update mechanism is not a means for introducing changes to your " "package which would otherwise be rejected from the stable release, so please " "do not attempt to do this." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1051 msgid "" "Review and test your changes as much as possible. Check the differences " "from the previous version repeatedly (<command>interdiff</command> from the " "<systemitem role=\"package\">patchutils</systemitem> package and " "<command>debdiff</command> from <systemitem " "role=\"package\">devscripts</systemitem> are useful tools for this, see " "<xref linkend=\"debdiff\"/> )." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1059 msgid "Be sure to verify the following items:" msgstr "" # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> #: pkgs.dbk:1064 msgid "" "Target the right distribution in your " "<filename>debian/changelog</filename>. For stable this is " "<literal>stable-security</literal> and for testing this is " "<literal>testing-security</literal>, and for the previous stable release, " "this is <literal>oldstable-security</literal>. Do not target " "<replaceable>distribution</replaceable>-proposed-updates or " "<literal>stable</literal>!" msgstr "" # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> #: pkgs.dbk:1074 msgid "The upload should have urgency=high." msgstr "" # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> #: pkgs.dbk:1079 msgid "" "Make descriptive, meaningful changelog entries. Others will rely on them to " "determine whether a particular bug was fixed. Always include an external " "reference, preferably a CVE identifier, so that it can be cross-referenced. " "Include the same information in the changelog for unstable, so that it is " "clear that the same bug was fixed, as this is very helpful when verifying " "that the bug is fixed in the next stable release. If a CVE identifier has " "not yet been assigned, the security team will request one so that it can be " "included in the package and in the advisory." msgstr "" # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> #: pkgs.dbk:1091 msgid "" "Make sure the version number is proper. It must be greater than the current " "package, but less than package versions in later distributions. If in " "doubt, test it with <literal>dpkg --compare-versions</literal>. Be careful " "not to re-use a version number that you have already used for a previous " "upload. For <emphasis>testing</emphasis>, there must be a higher version in " "<emphasis>unstable</emphasis>. If there is none yet (for example, if " "<emphasis>testing</emphasis> and <emphasis>unstable</emphasis> have the same " "version) you must upload a new version to unstable first." msgstr "" # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> #: pkgs.dbk:1103 msgid "" "Do not make source-only uploads if your package has any binary-all packages " "(do not use the <literal>-S</literal> option to " "<command>dpkg-buildpackage</command>). The <command>buildd</command> " "infrastructure will not build those. This point applies to normal package " "uploads as well." msgstr "" # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> #: pkgs.dbk:1112 msgid "" "Unless the upstream source has been uploaded to security.debian.org before " "(by a previous security update), build the upload with full upstream source " "(<literal>dpkg-buildpackage -sa</literal>). If there has been a previous " "upload to security.debian.org with the same upstream version, you may upload " "without upstream source (<literal>dpkg-buildpackage -sd</literal>)." msgstr "" # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> #: pkgs.dbk:1121 msgid "" "Be sure to use the exact same <filename>*.orig.tar.gz</filename> as used in " "the normal archive, otherwise it is not possible to move the security fix " "into the main archives later." msgstr "" # type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> #: pkgs.dbk:1128 msgid "" "Build the package on a clean system which only has packages installed from " "the distribution you are building for. If you do not have such a system " "yourself, you can use a debian.org machine (see <xref " "linkend=\"server-machines\"/> ) or setup a chroot (see <xref " "linkend=\"pbuilder\"/> and <xref linkend=\"debootstrap\"/> )." msgstr "" # type: Content of: <chapter><section><section><section><title> #: pkgs.dbk:1139 msgid "Uploading the fixed package" msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1141 msgid "" "Do <emphasis role=\"strong\">NOT</emphasis> upload a package to the security " "upload queue (oldstable-security, stable-security, etc.) without prior " "authorization from the security team. If the package does not exactly meet " "the team's requirements, it will cause many problems and delays in dealing " "with the unwanted upload." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1148 msgid "" "Do <emphasis role=\"strong\">NOT</emphasis> upload your fix to " "proposed-updates without coordinating with the security team. Packages from " "security.debian.org will be copied into the proposed-updates directory " "automatically. If a package with the same or a higher version number is " "already installed into the archive, the security update will be rejected by " "the archive system. That way, the stable distribution will end up without a " "security update for this package instead." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1157 msgid "" "Once you have created and tested the new package and it has been approved by " "the security team, it needs to be uploaded so that it can be installed in " "the archives. For security uploads, the place to upload to is " "<literal>ftp://security-master.debian.org/pub/SecurityUploadQueue/</literal> " "." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1163 msgid "" "Once an upload to the security queue has been accepted, the package will " "automatically be rebuilt for all architectures and stored for verification " "by the security team." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1168 msgid "" "Uploads which are waiting for acceptance or verification are only accessible " "by the security team. This is necessary since there might be fixes for " "security problems that cannot be disclosed yet." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1173 msgid "" "If a member of the security team accepts a package, it will be installed on " "security.debian.org as well as proposed for the proper " "<replaceable>distribution</replaceable>-proposed-updates on ftp-master." msgstr "" # type: Content of: <chapter><section><title> #: pkgs.dbk:1184 msgid "Moving, removing, renaming, adopting, and orphaning packages" msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:1186 msgid "" "Some archive manipulation operations are not automated in the Debian upload " "process. These procedures should be manually followed by maintainers. This " "chapter gives guidelines on what to do in these cases." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:1191 msgid "Moving packages" msgstr "" # type: Content of: <chapter><section><section><para><footnote> #: pkgs.dbk:1193 msgid "" "Sometimes a package will change its section. For instance, a package from " "the `non-free' section might be GPL'd in a later version, in which case the " "package should be moved to `main' or `contrib'.<footnote>" msgstr "" # type: Content of: <chapter><section><section><para><footnote><para> #: pkgs.dbk:1195 msgid "" "See the <ulink url=\"&url-debian-policy;\">Debian Policy Manual</ulink> for " "guidelines on what section a package belongs in." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1200 msgid "" "If you need to change the section for one of your packages, change the " "package control information to place the package in the desired section, and " "re-upload the package (see the <ulink url=\"&url-debian-policy;\">Debian " "Policy Manual</ulink> for details). You must ensure that you include the " "<filename>.orig.tar.gz</filename> in your upload (even if you are not " "uploading a new upstream version), or it will not appear in the new section " "together with the rest of the package. If your new section is valid, it " "will be moved automatically. If it does not, then contact the ftpmasters in " "order to understand what happened." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1212 msgid "" "If, on the other hand, you need to change the " "<emphasis>subsection</emphasis> of one of your packages (e.g., ``devel'', " "``admin''), the procedure is slightly different. Correct the subsection as " "found in the control file of the package, and re-upload that. Also, you'll " "need to get the override file updated, as described in <xref " "linkend=\"override-file\"/> ." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:1221 msgid "Removing packages" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1223 msgid "" "If for some reason you want to completely remove a package (say, if it is an " "old compatibility library which is no longer required), you need to file a " "bug against <literal>ftp.debian.org</literal> asking that the package be " "removed; as all bugs, this bug should normally have normal severity. Make " "sure you indicate which distribution the package should be removed from. " "Normally, you can only have packages removed from " "<emphasis>unstable</emphasis> and <emphasis>experimental</emphasis>. " "Packages are not removed from <emphasis>testing</emphasis> directly. " "Rather, they will be removed automatically after the package has been " "removed from <emphasis>unstable</emphasis> and no package in " "<emphasis>testing</emphasis> depends on it." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1236 msgid "" "There is one exception when an explicit removal request is not necessary: If " "a (source or binary) package is an orphan, it will be removed " "semi-automatically. For a binary-package, this means if there is no longer " "any source package producing this binary package; if the binary package is " "just no longer produced on some architectures, a removal request is still " "necessary. For a source-package, this means that all binary packages it " "refers to have been taken over by another source package." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1245 msgid "" "In your removal request, you have to detail the reasons justifying the " "request. This is to avoid unwanted removals and to keep a trace of why a " "package has been removed. For example, you can provide the name of the " "package that supersedes the one to be removed." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1251 msgid "" "Usually you only ask for the removal of a package maintained by yourself. " "If you want to remove another package, you have to get the approval of its " "maintainer." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1256 msgid "" "Further information relating to these and other package removal related " "topics may be found at <ulink " "url=\"http://wiki.debian.org/ftpmaster_Removals\"></ulink> and <ulink " "url=\"&url-debian-qa;howto-remove.html\"></ulink>." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1261 msgid "" "If in doubt concerning whether a package is disposable, email " "&email-debian-devel; asking for opinions. Also of interest is the " "<command>apt-cache</command> program from the <systemitem " "role=\"package\">apt</systemitem> package. When invoked as " "<literal>apt-cache showpkg <replaceable>package</replaceable></literal>, the " "program will show details for <replaceable>package</replaceable>, including " "reverse depends. Other useful programs include <literal>apt-cache " "rdepends</literal>, <command>apt-rdepends</command> and " "<command>grep-dctrl</command>. Removal of orphaned packages is discussed on " "&email-debian-qa;." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1272 msgid "" "Once the package has been removed, the package's bugs should be handled. " "They should either be reassigned to another package in the case where the " "actual code has evolved into another package (e.g. " "<literal>libfoo12</literal> was removed because <literal>libfoo13</literal> " "supersedes it) or closed if the software is simply no longer part of Debian." msgstr "" # type: Content of: <chapter><section><section><section><title> #: pkgs.dbk:1279 msgid "Removing packages from <filename>Incoming</filename>" msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1281 msgid "" "In the past, it was possible to remove packages from " "<filename>incoming</filename>. However, with the introduction of the new " "incoming system, this is no longer possible. Instead, you have to upload a " "new revision of your package with a higher version than the package you want " "to replace. Both versions will be installed in the archive but only the " "higher version will actually be available in <emphasis>unstable</emphasis> " "since the previous version will immediately be replaced by the higher. " "However, if you do proper testing of your packages, the need to replace a " "package should not occur too often anyway." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:1296 msgid "Replacing or renaming packages" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1298 msgid "" "When you make a mistake naming your package, you should follow a two-step " "process to rename it. First, set your <filename>debian/control</filename> " "file to replace and conflict with the obsolete name of the package (see the " "<ulink url=\"&url-debian-policy;\">Debian Policy Manual</ulink> for " "details). Once you've uploaded the package and the package has moved into " "the archive, file a bug against <literal>ftp.debian.org</literal> asking to " "remove the package with the obsolete name. Do not forget to properly " "reassign the package's bugs at the same time." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1308 msgid "" "At other times, you may make a mistake in constructing your package and wish " "to replace it. The only way to do this is to increase the version number " "and upload a new version. The old version will be expired in the usual " "manner. Note that this applies to each part of your package, including the " "sources: if you wish to replace the upstream source tarball of your package, " "you will need to upload it with a different version. An easy possibility is " "to replace <filename>foo_1.00.orig.tar.gz</filename> with " "<filename>foo_1.00+0.orig.tar.gz</filename>. This restriction gives each " "file on the ftp site a unique name, which helps to ensure consistency across " "the mirror network." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:1322 msgid "Orphaning a package" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1324 msgid "" "If you can no longer maintain a package, you need to inform others, and see " "that the package is marked as orphaned. You should set the package " "maintainer to <literal>Debian QA Group &orphan-address;</literal> and submit " "a bug report against the pseudo package <systemitem " "role=\"package\">wnpp</systemitem>. The bug report should be titled " "<literal>O: <replaceable>package</replaceable> -- <replaceable>short " "description</replaceable></literal> indicating that the package is now " "orphaned. The severity of the bug should be set to " "<emphasis>normal</emphasis>; if the package has a priority of standard or " "higher, it should be set to important. If you feel it's necessary, send a " "copy to &email-debian-devel; by putting the address in the X-Debbugs-CC: " "header of the message (no, don't use CC:, because that way the message's " "subject won't indicate the bug number)." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1339 msgid "" "If you just intend to give the package away, but you can keep maintainership " "for the moment, then you should instead submit a bug against <systemitem " "role=\"package\">wnpp</systemitem> and title it <literal>RFA: " "<replaceable>package</replaceable> -- <replaceable>short " "description</replaceable></literal>. <literal>RFA</literal> stands for " "<emphasis>Request For Adoption</emphasis>." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1347 msgid "More information is on the <ulink url=\"&url-wnpp;\">WNPP web pages</ulink>." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:1353 msgid "Adopting a package" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1355 msgid "" "A list of packages in need of a new maintainer is available in the <ulink " "url=\"&url-wnpp;\">Work-Needing and Prospective Packages list " "(WNPP)</ulink>. If you wish to take over maintenance of any of the packages " "listed in the WNPP, please take a look at the aforementioned page for " "information and procedures." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1362 msgid "" "It is not OK to simply take over a package that you feel is neglected — that " "would be package hijacking. You can, of course, contact the current " "maintainer and ask them if you may take over the package. If you have " "reason to believe a maintainer has gone AWOL (absent without leave), see " "<xref linkend=\"mia-qa\"/> ." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1368 msgid "" "Generally, you may not take over the package without the assent of the " "current maintainer. Even if they ignore you, that is still not grounds to " "take over a package. Complaints about maintainers should be brought up on " "the developers' mailing list. If the discussion doesn't end with a positive " "conclusion, and the issue is of a technical nature, consider bringing it to " "the attention of the technical committee (see the <ulink " "url=\"&url-tech-ctte;\">technical committee web page</ulink> for more " "information)." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1378 msgid "" "If you take over an old package, you probably want to be listed as the " "package's official maintainer in the bug system. This will happen " "automatically once you upload a new version with an updated " "<literal>Maintainer:</literal> field, although it can take a few hours after " "the upload is done. If you do not expect to upload a new version for a " "while, you can use <xref linkend=\"pkg-tracking-system\"/> to get the bug " "reports. However, make sure that the old maintainer has no problem with the " "fact that they will continue to receive the bugs during that time." msgstr "" # type: Content of: <chapter><section><title> #: pkgs.dbk:1392 msgid "Porting and being ported" msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:1394 msgid "" "Debian supports an ever-increasing number of architectures. Even if you are " "not a porter, and you don't use any architecture but one, it is part of your " "duty as a maintainer to be aware of issues of portability. Therefore, even " "if you are not a porter, you should read most of this chapter." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:1400 msgid "" "Porting is the act of building Debian packages for architectures that are " "different from the original architecture of the package maintainer's binary " "package. It is a unique and essential activity. In fact, porters do most " "of the actual compiling of Debian packages. For instance, for a single " "<emphasis>i386</emphasis> binary package, there must be a recompile for each " "architecture, which amounts to &number-of-arches; more builds." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:1408 msgid "Being kind to porters" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1410 msgid "" "Porters have a difficult and unique task, since they are required to deal " "with a large volume of packages. Ideally, every source package should build " "right out of the box. Unfortunately, this is often not the case. This " "section contains a checklist of ``gotchas'' often committed by Debian " "maintainers — common problems which often stymie porters, and make their " "jobs unnecessarily difficult." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1418 msgid "" "The first and most important thing is to respond quickly to bug or issues " "raised by porters. Please treat porters with courtesy, as if they were in " "fact co-maintainers of your package (which, in a way, they are). Please be " "tolerant of succinct or even unclear bug reports; do your best to hunt down " "whatever the problem is." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1425 msgid "" "By far, most of the problems encountered by porters are caused by " "<emphasis>packaging bugs</emphasis> in the source packages. Here is a " "checklist of things you should check or be aware of." msgstr "" # type: Content of: <chapter><section><section><orderedlist><listitem><para> #: pkgs.dbk:1432 msgid "" "Make sure that your <literal>Build-Depends</literal> and " "<literal>Build-Depends-Indep</literal> settings in " "<filename>debian/control</filename> are set properly. The best way to " "validate this is to use the <systemitem " "role=\"package\">debootstrap</systemitem> package to create an unstable " "chroot environment (see <xref linkend=\"debootstrap\"/> ). Within that " "chrooted environment, install the <systemitem " "role=\"package\">build-essential</systemitem> package and any package " "dependencies mentioned in <literal>Build-Depends</literal> and/or " "<literal>Build-Depends-Indep</literal>. Finally, try building your package " "within that chrooted environment. These steps can be automated by the use " "of the <command>pbuilder</command> program which is provided by the package " "of the same name (see <xref linkend=\"pbuilder\"/> )." msgstr "" # type: Content of: <chapter><section><section><orderedlist><listitem><para> #: pkgs.dbk:1446 msgid "" "If you can't set up a proper chroot, <command>dpkg-depcheck</command> may be " "of assistance (see <xref linkend=\"dpkg-depcheck\"/> )." msgstr "" # type: Content of: <chapter><section><section><orderedlist><listitem><para> #: pkgs.dbk:1450 msgid "" "See the <ulink url=\"&url-debian-policy;\">Debian Policy Manual</ulink> for " "instructions on setting build dependencies." msgstr "" # type: Content of: <chapter><section><section><orderedlist><listitem><para> #: pkgs.dbk:1456 msgid "" "Don't set architecture to a value other than ``all'' or ``any'' unless you " "really mean it. In too many cases, maintainers don't follow the " "instructions in the <ulink url=\"&url-debian-policy;\">Debian Policy " "Manual</ulink>. Setting your architecture to ``i386'' is usually incorrect." msgstr "" # type: Content of: <chapter><section><section><orderedlist><listitem><para> #: pkgs.dbk:1464 msgid "" "Make sure your source package is correct. Do <literal>dpkg-source -x " "<replaceable>package</replaceable>.dsc</literal> to make sure your source " "package unpacks properly. Then, in there, try building your package from " "scratch with <command>dpkg-buildpackage</command>." msgstr "" # type: Content of: <chapter><section><section><orderedlist><listitem><para> #: pkgs.dbk:1472 msgid "" "Make sure you don't ship your source package with the " "<filename>debian/files</filename> or <filename>debian/substvars</filename> " "files. They should be removed by the `clean' target of " "<filename>debian/rules</filename>." msgstr "" # type: Content of: <chapter><section><section><orderedlist><listitem><para> #: pkgs.dbk:1480 msgid "" "Make sure you don't rely on locally installed or hacked configurations or " "programs. For instance, you should never be calling programs in " "<filename>/usr/local/bin</filename> or the like. Try not to rely on " "programs being setup in a special way. Try building your package on another " "machine, even if it's the same architecture." msgstr "" # type: Content of: <chapter><section><section><orderedlist><listitem><para> #: pkgs.dbk:1489 msgid "" "Don't depend on the package you're building being installed already (a " "sub-case of the above issue)." msgstr "" # type: Content of: <chapter><section><section><orderedlist><listitem><para> #: pkgs.dbk:1495 msgid "" "Don't rely on the compiler being a certain version, if possible. If not, " "then make sure your build dependencies reflect the restrictions, although " "you are probably asking for trouble, since different architectures sometimes " "standardize on different compilers." msgstr "" # type: Content of: <chapter><section><section><orderedlist><listitem><para> #: pkgs.dbk:1503 msgid "" "Make sure your debian/rules contains separate ``binary-arch'' and " "``binary-indep'' targets, as the Debian Policy Manual requires. Make sure " "that both targets work independently, that is, that you can call the target " "without having called the other before. To test this, try to run " "<literal>dpkg-buildpackage -B</literal>." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:1514 msgid "Guidelines for porter uploads" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1516 msgid "" "If the package builds out of the box for the architecture to be ported to, " "you are in luck and your job is easy. This section applies to that case; it " "describes how to build and upload your binary package so that it is properly " "installed into the archive. If you do have to patch the package in order to " "get it to compile for the other architecture, you are actually doing a " "source NMU, so consult <xref linkend=\"nmu-guidelines\"/> instead." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1524 msgid "" "For a porter upload, no changes are being made to the source. You do not " "need to touch any of the files in the source package. This includes " "<filename>debian/changelog</filename>." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1529 msgid "" "The way to invoke <command>dpkg-buildpackage</command> is as " "<literal>dpkg-buildpackage -B " "-m<replaceable>porter-email</replaceable></literal>. Of course, set " "<replaceable>porter-email</replaceable> to your email address. This will do " "a binary-only build of only the architecture-dependent portions of the " "package, using the `binary-arch' target in " "<filename>debian/rules</filename>." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1537 msgid "" "If you are working on a Debian machine for your porting efforts and you need " "to sign your upload locally for its acceptance in the archive, you can run " "<command>debsign</command> on your <filename>.changes</filename> file to " "have it signed conveniently, or use the remote signing mode of " "<command>dpkg-sig</command>." msgstr "" # type: Content of: <chapter><section><section><section><title> #: pkgs.dbk:1544 msgid "Recompilation or binary-only NMU" msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1546 msgid "" "Sometimes the initial porter upload is problematic because the environment " "in which the package was built was not good enough (outdated or obsolete " "library, bad compiler, ...). Then you may just need to recompile it in an " "updated environment. However, you have to bump the version number in this " "case, so that the old bad package can be replaced in the Debian archive " "(<command>katie</command> refuses to install new packages if they don't have " "a version number greater than the currently available one)." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1555 msgid "" "You have to make sure that your binary-only NMU doesn't render the package " "uninstallable. This could happen when a source package generates " "arch-dependent and arch-independent packages that depend on each other via " "$(Source-Version)." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1561 msgid "" "Despite the required modification of the changelog, these are called " "binary-only NMUs — there is no need in this case to trigger all other " "architectures to consider themselves out of date or requiring recompilation." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1566 msgid "" "Such recompilations require special ``magic'' version numbering, so that the " "archive maintenance tools recognize that, even though there is a new Debian " "version, there is no corresponding source update. If you get this wrong, " "the archive maintainers will reject your upload (due to lack of " "corresponding source code)." msgstr "" # type: Content of: <chapter><section><section><section><para><footnote> #: pkgs.dbk:1573 msgid "" "The ``magic'' for a recompilation-only NMU is triggered by using a suffix " "appended to the package version number, following the form b<number>. " "For instance, if the latest version you are recompiling against was version " "``2.9-3'', your NMU should carry a version of ``2.9-3+b1''. If the latest " "version was ``3.4+b1'' (i.e, a native package with a previous recompilation " "NMU), your NMU should have a version number of ``3.4+b2''. <footnote>" msgstr "" # type: Content of: <chapter><section><section><section><para><footnote><para> #: pkgs.dbk:1578 msgid "" "In the past, such NMUs used the third-level number on the Debian part of the " "revision to denote their recompilation-only status; however, this syntax was " "ambiguous with native packages and did not allow proper ordering of " "recompile-only NMUs, source NMUs, and security NMUs on the same package, and " "has therefore been abandoned in favor of this new syntax." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1586 msgid "" "Similar to initial porter uploads, the correct way of invoking " "<command>dpkg-buildpackage</command> is <literal>dpkg-buildpackage " "-B</literal> to only build the architecture-dependent parts of the package." msgstr "" # type: Content of: <chapter><section><section><section><title> #: pkgs.dbk:1593 msgid "When to do a source NMU if you are a porter" msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1595 msgid "" "Porters doing a source NMU generally follow the guidelines found in <xref " "linkend=\"nmu\"/> , just like non-porters. However, it is expected that the " "wait cycle for a porter's source NMU is smaller than for a non-porter, since " "porters have to cope with a large quantity of packages. Again, the " "situation varies depending on the distribution they are uploading to. It " "also varies whether the architecture is a candidate for inclusion into the " "next stable release; the release managers decide and announce which " "architectures are candidates." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1604 msgid "" "If you are a porter doing an NMU for `unstable', the above guidelines for " "porting should be followed, with two variations. Firstly, the acceptable " "waiting period — the time between when the bug is submitted to the BTS and " "when it is OK to do an NMU — is seven days for porters working on the " "unstable distribution. This period can be shortened if the problem is " "critical and imposes hardship on the porting effort, at the discretion of " "the porter group. (Remember, none of this is Policy, just mutually agreed " "upon guidelines.) For uploads to stable or testing, please coordinate with " "the appropriate release team first." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1615 msgid "" "Secondly, porters doing source NMUs should make sure that the bug they " "submit to the BTS should be of severity `serious' or greater. This ensures " "that a single source package can be used to compile every supported Debian " "architecture by release time. It is very important that we have one version " "of the binary and source package for all architecture in order to comply " "with many licenses." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1623 msgid "" "Porters should try to avoid patches which simply kludge around bugs in the " "current version of the compile environment, kernel, or libc. Sometimes such " "kludges can't be helped. If you have to kludge around compiler bugs and the " "like, make sure you <literal>#ifdef</literal> your work properly; also, " "document your kludge so that people know to remove it once the external " "problems have been fixed." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1631 msgid "" "Porters may also have an unofficial location where they can put the results " "of their work during the waiting period. This helps others running the port " "have the benefit of the porter's work, even during the waiting period. Of " "course, such locations have no official blessing or status, so buyer beware." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:1641 msgid "Porting infrastructure and automation" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1643 msgid "" "There is infrastructure and several tools to help automate package porting. " "This section contains a brief overview of this automation and porting to " "these tools; see the package documentation or references for full " "information." msgstr "" # type: Content of: <chapter><section><section><section><title> #: pkgs.dbk:1648 msgid "Mailing lists and web pages" msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1650 msgid "" "Web pages containing the status of each port can be found at <ulink " "url=\"&url-debian-ports;\"></ulink>." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1654 msgid "" "Each port of Debian has a mailing list. The list of porting mailing lists " "can be found at <ulink url=\"&url-debian-port-lists;\"></ulink>. These " "lists are used to coordinate porters, and to connect the users of a given " "port with the porters." msgstr "" # type: Content of: <chapter><section><section><section><title> #: pkgs.dbk:1662 msgid "Porter tools" msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1664 msgid "" "Descriptions of several porting tools can be found in <xref " "linkend=\"tools-porting\"/> ." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1672 msgid "" "The <systemitem role=\"package\">buildd</systemitem> system is used as a " "distributed, client-server build distribution system. It is usually used in " "conjunction with <emphasis>auto-builders</emphasis>, which are ``slave'' " "hosts which simply check out and attempt to auto-build packages which need " "to be ported. There is also an email interface to the system, which allows " "porters to ``check out'' a source package (usually one which cannot yet be " "auto-built) and work on it." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1681 msgid "" "<systemitem role=\"package\">buildd</systemitem> is not yet available as a " "package; however, most porting efforts are either using it currently or " "planning to use it in the near future. The actual automated builder is " "packaged as <systemitem role=\"package\">sbuild</systemitem>, see its " "description in <xref linkend=\"sbuild\"/> . The complete <systemitem " "role=\"package\">buildd</systemitem> system also collects a number of as yet " "unpackaged components which are currently very useful and in use " "continually, such as <command>andrea</command> and " "<command>wanna-build</command>." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1691 msgid "" "Some of the data produced by <systemitem " "role=\"package\">buildd</systemitem> which is generally useful to porters is " "available on the web at <ulink url=\"&url-buildd;\"></ulink>. This data " "includes nightly updated information from <command>andrea</command> (source " "dependencies) and <systemitem role=\"package\">quinn-diff</systemitem> " "(packages needing recompilation)." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1699 msgid "" "We are quite proud of this system, since it has so many possible uses. " "Independent development groups can use the system for different sub-flavors " "of Debian, which may or may not really be of general interest (for instance, " "a flavor of Debian built with <command>gcc</command> bounds checking). It " "will also enable Debian to recompile entire distributions quickly." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:1706 msgid "" "The buildds admins of each arch can be contacted at the mail address " "$arch@buildd.debian.org." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:1714 msgid "When your package is <emphasis>not</emphasis> portable" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1716 msgid "" "Some packages still have issues with building and/or working on some of the " "architectures supported by Debian, and cannot be ported at all, or not " "within a reasonable amount of time. An example is a package that is " "SVGA-specific (only i386), or uses other hardware-specific features not " "supported on all architectures." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1723 msgid "" "In order to prevent broken packages from being uploaded to the archive, and " "wasting buildd time, you need to do a few things:" msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:1729 msgid "" "First, make sure your package <emphasis>does</emphasis> fail to build on " "architectures that it cannot support. There are a few ways to achieve " "this. The preferred way is to have a small testsuite during build time that " "will test the functionality, and fail if it doesn't work. This is a good " "idea anyway, as this will prevent (some) broken uploads on all " "architectures, and also will allow the package to build as soon as the " "required functionality is available." msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:1737 msgid "" "Additionally, if you believe the list of supported architectures is pretty " "constant, you should change 'any' to a list of supported architectures in " "debian/control. This way, the build will fail also, and indicate this to a " "human reader without actually trying." msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:1745 msgid "" "In order to prevent autobuilders from needlessly trying to build your " "package, it must be included in <filename>packages-arch-specific</filename>, " "a list used by the <command>wanna-build</command> script. The current " "version is available as <ulink " "url=\"&url-cvsweb;srcdep/Packages-arch-specific?cvsroot=dak\"></ulink>; " "please see the top of the file for whom to contact for changes." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1755 msgid "" "Please note that it is insufficient to only add your package to " "Packages-arch-specific without making it fail to build on unsupported " "architectures: A porter or any other person trying to build your package " "might accidently upload it without noticing it doesn't work. If in the past " "some binary packages were uploaded on unsupported architectures, request " "their removal by filing a bug against <systemitem " "role=\"package\">ftp.debian.org</systemitem>" msgstr "" # type: Content of: <chapter><section><title> #: pkgs.dbk:1768 msgid "Non-Maintainer Uploads (NMUs)" msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:1770 msgid "" "Under certain circumstances it is necessary for someone other than the " "official package maintainer to make a release of a package. This is called " "a non-maintainer upload, or NMU." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:1775 msgid "" "This section handles only source NMUs, i.e. NMUs which upload a new version " "of the package. For binary-only NMUs by porters or QA members, please see " "<xref linkend=\"binary-only-nmu\"/> . If a buildd builds and uploads a " "package, that too is strictly speaking a binary NMU. See <xref " "linkend=\"buildd\"/> for some more information." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:1782 msgid "" "The main reason why NMUs are done is when a developer needs to fix another " "developer's package in order to address serious problems or crippling bugs " "or when the package maintainer is unable to release a fix in a timely " "fashion." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:1787 msgid "" "First and foremost, it is critical that NMU patches to source should be as " "non-disruptive as possible. Do not do housekeeping tasks, do not change the " "name of modules or files, do not move directories; in general, do not fix " "things which are not broken. Keep the patch as small as possible. If " "things bother you aesthetically, talk to the Debian maintainer, talk to the " "upstream maintainer, or submit a bug. However, aesthetic changes must " "<emphasis>not</emphasis> be made in a non-maintainer upload." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:1796 msgid "" "And please remember the Hippocratic Oath: Above all, do no harm. It is " "better to leave a package with an open grave bug than applying a " "non-functional patch, or one that hides the bug instead of resolving it." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:1801 msgid "How to do a NMU" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1803 msgid "" "NMUs which fix important, serious or higher severity bugs are encouraged and " "accepted. You should endeavor to reach the current maintainer of the " "package; they might be just about to upload a fix for the problem, or have a " "better solution." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1809 msgid "" "NMUs should be made to assist a package's maintainer in resolving bugs. " "Maintainers should be thankful for that help, and NMUers should respect the " "decisions of maintainers, and try to personally help the maintainer by their " "work." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1815 msgid "" "A NMU should follow all conventions, written down in this section. For an " "upload to testing or unstable, this order of steps is recommended:" msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:1821 msgid "" "Make sure that the package's bugs that the NMU is meant to address are all " "filed in the Debian Bug Tracking System (BTS). If they are not, submit them " "immediately." msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:1828 msgid "" "Wait a few days for the response from the maintainer. If you don't get any " "response, you may want to help them by sending the patch that fixes the " "bug. Don't forget to tag the bug with the patch keyword." msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:1835 msgid "" "Wait a few more days. If you still haven't got an answer from the " "maintainer, send them a mail announcing your intent to NMU the package. " "Prepare an NMU as described in this section, and test it carefully on your " "machine (cf. <xref linkend=\"sanitycheck\"/> ). Double check that your " "patch doesn't have any unexpected side effects. Make sure your patch is as " "small and as non-disruptive as it can be." msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:1845 msgid "" "Upload your package to incoming in <filename>DELAYED/7-day</filename> (cf. " "<xref linkend=\"delayed-incoming\"/> ), send the final patch to the " "maintainer via the BTS, and explain to them that they have 7 days to react " "if they want to cancel the NMU." msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:1853 msgid "" "Follow what happens, you're responsible for any bug that you introduced with " "your NMU. You should probably use <xref linkend=\"pkg-tracking-system\"/> " "(PTS) to stay informed of the state of the package after your NMU." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1860 msgid "" "At times, the release manager or an organized group of developers can " "announce a certain period of time in which the NMU rules are relaxed. This " "usually involves shortening the period during which one is to wait before " "uploading the fixes, and shortening the DELAYED period. It is important to " "notice that even in these so-called bug squashing party times, the NMU'er " "has to file bugs and contact the developer first, and act later. Please see " "<xref linkend=\"qa-bsp\"/> for details." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1869 msgid "" "For the testing distribution, the rules may be changed by the release " "managers. Please take additional care, and acknowledge that the usual way " "for a package to enter testing is through unstable." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1874 msgid "" "For the stable distribution, please take extra care. Of course, the release " "managers may also change the rules here. Please verify before you upload " "that all your changes are OK for inclusion into the next stable release by " "the release manager." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1880 msgid "" "When a security bug is detected, the security team may do an NMU, using " "their own rules. Please refer to <xref linkend=\"bug-security\"/> for more " "information." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1885 msgid "" "For the differences for Porters NMUs, please see <xref " "linkend=\"source-nmu-when-porter\"/> ." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1889 msgid "" "Of course, it is always possible to agree on special rules with a maintainer " "(like the maintainer asking please upload this fix directly for me, and no " "diff required)." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:1896 msgid "NMU version numbering" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1898 msgid "" "Whenever you have made a change to a package, no matter how trivial, the " "version number needs to change. This enables our packing system to " "function." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1902 msgid "" "If you are doing a non-maintainer upload (NMU), you should add a new minor " "version number to the <replaceable>debian-revision</replaceable> part of the " "version number (the portion after the last hyphen). This extra minor number " "will start at `1'. For example, consider the package `foo', which is at " "version 1.1-3. In the archive, the source package control file would be " "<filename>foo_1.1-3.dsc</filename>. The upstream version is `1.1' and the " "Debian revision is `3'. The next NMU would add a new minor number `.1' to " "the Debian revision; the new source control file would be " "<filename>foo_1.1-3.1.dsc</filename>." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1913 msgid "" "The Debian revision minor number is needed to avoid stealing one of the " "package maintainer's version numbers, which might disrupt their work. It " "also has the benefit of making it visually clear that a package in the " "archive was not made by the official maintainer." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1919 msgid "" "If there is no <replaceable>debian-revision</replaceable> component in the " "version number then one should be created, starting at `0.1' (but in case of " "a debian native package still upload it as native package). If it is " "absolutely necessary for someone other than the usual maintainer to make a " "release based on a new upstream version then the person making the release " "should start with the <replaceable>debian-revision</replaceable> value " "`0.1'. The usual maintainer of a package should start their " "<replaceable>debian-revision</replaceable> numbering at `1'." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1929 msgid "" "If you upload a package to testing or stable, sometimes, you need to fork " "the version number tree. For this, version numbers like 1.1-3sarge0.1 could " "be used." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:1936 msgid "Source NMUs must have a new changelog entry" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1938 msgid "" "Anyone who is doing a source NMU must create a changelog entry, describing " "which bugs are fixed by the NMU, and generally why the NMU was required and " "what it fixed. The changelog entry will have the email address of the " "person who uploaded it in the log entry and the NMU version number in it." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1944 msgid "By convention, source NMU changelog entries start with the line" msgstr "" # type: Content of: <chapter><section><section><screen> #: pkgs.dbk:1947 #, no-wrap msgid "* Non-maintainer upload" msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:1952 msgid "Source NMUs and the Bug Tracking System" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1954 msgid "" "Maintainers other than the official package maintainer should make as few " "changes to the package as possible, and they should always send a patch as a " "unified context diff (<literal>diff -u</literal>) detailing their changes to " "the Bug Tracking System." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1960 msgid "" "What if you are simply recompiling the package? If you just need to " "recompile it for a single architecture, then you may do a binary-only NMU as " "described in <xref linkend=\"binary-only-nmu\"/> which doesn't require any " "patch to be sent. If you want the package to be recompiled for all " "architectures, then you do a source NMU as usual and you will have to send a " "patch." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1967 msgid "" "Bugs fixed by source NMUs used to be tagged fixed instead of closed, but " "since version tracking is in place, such bugs are now also closed with the " "NMU version." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1972 msgid "" "Also, after doing an NMU, you have to send the information to the existing " "bugs that are fixed by your NMU, including the unified diff. Historically, " "it was custom to open a new bug and include a patch showing all the changes " "you have made. The normal maintainer will either apply the patch or employ " "an alternate method of fixing the problem. Sometimes bugs are fixed " "independently upstream, which is another good reason to back out an NMU's " "patch. If the maintainer decides not to apply the NMU's patch but to " "release a new version, the maintainer needs to ensure that the new upstream " "version really fixes each problem that was fixed in the non-maintainer " "release." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1983 msgid "" "In addition, the normal maintainer should <emphasis>always</emphasis> retain " "the entry in the changelog file documenting the non-maintainer upload -- and " "of course, also keep the changes. If you revert some of the changes, please " "reopen the relevant bug reports." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:1991 msgid "Building source NMUs" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1993 msgid "" "Source NMU packages are built normally. Pick a distribution using the same " "rules as found in <xref linkend=\"distribution\"/> , follow the other " "instructions in <xref linkend=\"upload\"/> ." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:1998 msgid "" "Make sure you do <emphasis>not</emphasis> change the value of the maintainer " "in the <filename>debian/control</filename> file. Your name as given in the " "NMU entry of the <filename>debian/changelog</filename> file will be used for " "signing the changes file." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:2006 msgid "Acknowledging an NMU" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:2008 msgid "" "If one of your packages has been NMU'ed, you have to incorporate the changes " "in your copy of the sources. This is easy, you just have to apply the patch " "that has been sent to you. Once this is done, you have to close the bugs " "that have been tagged fixed by the NMU. The easiest way is to use the " "<literal>-v</literal> option of <command>dpkg-buildpackage</command>, as " "this allows you to include just all changes since your last maintainer " "upload. Alternatively, you can close them manually by sending the required " "mails to the BTS or by adding the required <literal>closes: #nnnn</literal> " "in the changelog entry of your next upload." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:2019 msgid "" "In any case, you should not be upset by the NMU. An NMU is not a personal " "attack against the maintainer. It is a proof that someone cares enough " "about the package that they were willing to help you in your work, so you " "should be thankful. You may also want to ask them if they would be " "interested in helping you on a more frequent basis as co-maintainer or " "backup maintainer (see <xref linkend=\"collaborative-maint\"/> )." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:2029 msgid "NMU vs QA uploads" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:2031 msgid "" "Unless you know the maintainer is still active, it is wise to check the " "package to see if it has been orphaned. The current list of orphaned " "packages which haven't had their maintainer set correctly is available at " "<ulink url=\"&url-debian-qa-orphaned;\"></ulink>. If you perform an NMU on " "an improperly orphaned package, please set the maintainer to <literal>Debian " "QA Group <packages@qa.debian.org></literal>." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:2041 msgid "Who can do an NMU" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:2043 msgid "" "Only official, registered Debian Developers can do binary or source NMUs. A " "Debian Developer is someone who has their key in the Debian key ring. " "Non-developers, however, are encouraged to download the source package and " "start hacking on it to fix problems; however, rather than doing an NMU, they " "should just submit worthwhile patches to the Bug Tracking System. " "Maintainers almost always appreciate quality patches and bug reports." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:2053 msgid "Terminology" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:2055 msgid "" "There are two new terms used throughout this section: ``binary-only NMU'' " "and ``source NMU''. These terms are used with specific technical meaning " "throughout this document. Both binary-only and source NMUs are similar, " "since they involve an upload of a package by a developer who is not the " "official maintainer of that package. That is why it's a " "<emphasis>non-maintainer</emphasis> upload." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:2063 msgid "" "A source NMU is an upload of a package by a developer who is not the " "official maintainer, for the purposes of fixing a bug in the package. " "Source NMUs always involves changes to the source (even if it is just a " "change to <filename>debian/changelog</filename>). This can be either a " "change to the upstream source, or a change to the Debian bits of the " "source. Note, however, that source NMUs may also include " "architecture-dependent packages, as well as an updated Debian diff." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:2072 msgid "" "A binary-only NMU is a recompilation and upload of a binary package for a " "given architecture. As such, it is usually part of a porting effort. A " "binary-only NMU is a non-maintainer uploaded binary version of a package, " "with no source changes required. There are many cases where porters must " "fix problems in the source in order to get them to compile for their target " "architecture; that would be considered a source NMU rather than a " "binary-only NMU. As you can see, we don't distinguish in terminology " "between porter NMUs and non-porter NMUs." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:2082 msgid "" "Both classes of NMUs, source and binary-only, can be lumped under the term " "``NMU''. However, this often leads to confusion, since most people think " "``source NMU'' when they think ``NMU''. So it's best to be careful: always " "use ``binary NMU'' or ``binNMU'' for binary-only NMUs." msgstr "" # type: Content of: <chapter><section><title> #: pkgs.dbk:2092 msgid "Collaborative maintenance" msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:2094 msgid "" "Collaborative maintenance is a term describing the sharing of Debian package " "maintenance duties by several people. This collaboration is almost always a " "good idea, since it generally results in higher quality and faster bug fix " "turnaround times. It is strongly recommended that packages with a priority " "of <literal>Standard</literal> or which are part of the base set have " "co-maintainers." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:2102 msgid "" "Generally there is a primary maintainer and one or more co-maintainers. The " "primary maintainer is the person whose name is listed in the " "<literal>Maintainer</literal> field of the " "<filename>debian/control</filename> file. Co-maintainers are all the other " "maintainers." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:2108 msgid "" "In its most basic form, the process of adding a new co-maintainer is quite " "easy:" msgstr "" # type: Content of: <chapter><section><itemizedlist><listitem><para> #: pkgs.dbk:2114 msgid "" "Setup the co-maintainer with access to the sources you build the package " "from. Generally this implies you are using a network-capable version " "control system, such as <command>CVS</command> or " "<command>Subversion</command>. Alioth (see <xref linkend=\"alioth\"/> ) " "provides such tools, amongst others." msgstr "" # type: Content of: <chapter><section><itemizedlist><listitem><para> #: pkgs.dbk:2122 msgid "" "Add the co-maintainer's correct maintainer name and address to the " "<literal>Uploaders</literal> field in the global part of the " "<filename>debian/control</filename> file." msgstr "" # type: Content of: <chapter><section><itemizedlist><listitem><screen> #: pkgs.dbk:2127 #, no-wrap msgid "" "Uploaders: John Buzz <jbuzz@debian.org>, Adam Rex " "<arex@debian.org>" msgstr "" # type: Content of: <chapter><section><itemizedlist><listitem><para> #: pkgs.dbk:2132 msgid "" "Using the PTS (<xref linkend=\"pkg-tracking-system\"/> ), the co-maintainers " "should subscribe themselves to the appropriate source package." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:2138 msgid "" "Another form of collaborative maintenance is team maintenance, which is " "recommended if you maintain several packages with the same group of " "developers. In that case, the Maintainer and Uploaders field of each " "package must be managed with care. It is recommended to choose between one " "of the two following schemes:" msgstr "" # type: Content of: <chapter><section><orderedlist><listitem><para> #: pkgs.dbk:2147 msgid "" "Put the team member mainly responsible for the package in the Maintainer " "field. In the Uploaders, put the mailing list address, and the team members " "who care for the package." msgstr "" # type: Content of: <chapter><section><orderedlist><listitem><para> #: pkgs.dbk:2154 msgid "" "Put the mailing list address in the Maintainer field. In the Uploaders " "field, put the team members who care for the package. In this case, you " "must make sure the mailing list accept bug reports without any human " "interaction (like moderation for non-subscribers)." msgstr "" # type: Content of: <chapter><section><para> #: pkgs.dbk:2162 msgid "" "In any case, it is a bad idea to automatically put all team members in the " "Uploaders field. It clutters the Developer's Package Overview listing (see " "<xref linkend=\"ddpo\"/> ) with packages one doesn't really care for, and " "creates a false sense of good maintenance." msgstr "" # type: Content of: <chapter><section><title> #: pkgs.dbk:2170 msgid "The testing distribution" msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:2172 msgid "Basics" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:2174 msgid "" "Packages are usually installed into the `testing' distribution after they " "have undergone some degree of testing in unstable." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:2178 msgid "" "They must be in sync on all architectures and mustn't have dependencies that " "make them uninstallable; they also have to have generally no known " "release-critical bugs at the time they're installed into testing. This way, " "`testing' should always be close to being a release candidate. Please see " "below for details." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:2187 msgid "Updates from unstable" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:2189 msgid "" "The scripts that update the <emphasis>testing</emphasis> distribution are " "run each day after the installation of the updated packages; these scripts " "are called <emphasis>britney</emphasis>. They generate the " "<filename>Packages</filename> files for the <emphasis>testing</emphasis> " "distribution, but they do so in an intelligent manner; they try to avoid any " "inconsistency and to use only non-buggy packages." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:2197 msgid "" "The inclusion of a package from <emphasis>unstable</emphasis> is conditional " "on the following:" msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:2203 msgid "" "The package must have been available in <emphasis>unstable</emphasis> for 2, " "5 or 10 days, depending on the urgency (high, medium or low). Please note " "that the urgency is sticky, meaning that the highest urgency uploaded since " "the previous testing transition is taken into account. Those delays may be " "doubled during a freeze, or testing transitions may be switched off " "altogether;" msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:2212 msgid "" "It must have the same number or fewer release-critical bugs than the version " "currently available in <emphasis>testing</emphasis>;" msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:2218 msgid "" "It must be available on all architectures on which it has previously been " "built in unstable. <xref linkend=\"madison\"/> may be of interest to check " "that information;" msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:2225 msgid "" "It must not break any dependency of a package which is already available in " "<emphasis>testing</emphasis>;" msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:2231 msgid "" "The packages on which it depends must either be available in " "<emphasis>testing</emphasis> or they must be accepted into " "<emphasis>testing</emphasis> at the same time (and they will be if they " "fulfill all the necessary criteria);" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:2239 msgid "" "To find out whether a package is progressing into testing or not, see the " "testing script output on the <ulink url=\"&url-testing-maint;\">web page of " "the testing distribution</ulink>, or use the program " "<command>grep-excuses</command> which is in the <systemitem " "role=\"package\">devscripts</systemitem> package. This utility can easily " "be used in a <citerefentry> <refentrytitle>crontab</refentrytitle> " "<manvolnum>5</manvolnum> </citerefentry> to keep yourself informed of the " "progression of your packages into <emphasis>testing</emphasis>." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:2250 msgid "" "The <filename>update_excuses</filename> file does not always give the " "precise reason why the package is refused; you may have to find it on your " "own by looking for what would break with the inclusion of the package. The " "<ulink url=\"&url-testing-maint;\">testing web page</ulink> gives some more " "information about the usual problems which may be causing such troubles." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:2257 msgid "" "Sometimes, some packages never enter <emphasis>testing</emphasis> because " "the set of inter-relationship is too complicated and cannot be sorted out by " "the scripts. See below for details." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:2262 msgid "" "Some further dependency analysis is shown on <ulink " "url=\"http://bjorn.haxx.se/debian/\"></ulink> — but be warned, this page " "also shows build dependencies which are not considered by britney." msgstr "" # type: Content of: <chapter><section><section><section><title> #: pkgs.dbk:2267 msgid "out-of-date" msgstr "" #. FIXME: better rename this file than document rampant professionalism? # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2270 msgid "" "For the testing migration script, outdated means: There are different " "versions in unstable for the release architectures (except for the " "architectures in fuckedarches; fuckedarches is a list of architectures that " "don't keep up (in update_out.py), but currently, it's empty). outdated has " "nothing whatsoever to do with the architectures this package has in testing." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2277 msgid "Consider this example:" msgstr "" # type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry> #: pkgs.dbk:2284 pkgs.dbk:2315 msgid "alpha" msgstr "" # type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry> #: pkgs.dbk:2285 pkgs.dbk:2316 msgid "arm" msgstr "" # type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry> #: pkgs.dbk:2290 pkgs.dbk:2322 pkgs.dbk:2382 msgid "testing" msgstr "" # type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry> #: pkgs.dbk:2291 pkgs.dbk:2296 pkgs.dbk:2323 pkgs.dbk:2324 pkgs.dbk:2331 msgid "1" msgstr "" # type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry> #: pkgs.dbk:2292 pkgs.dbk:2325 pkgs.dbk:2330 msgid "-" msgstr "" # type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry> #: pkgs.dbk:2295 pkgs.dbk:2328 pkgs.dbk:2383 msgid "unstable" msgstr "" # type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry> #: pkgs.dbk:2297 pkgs.dbk:2329 msgid "2" msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2303 msgid "" "The package is out of date on alpha in unstable, and will not go to " "testing. And removing foo from testing would not help at all, the package " "is still out of date on alpha, and will not propagate to testing." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2308 msgid "However, if ftp-master removes a package in unstable (here on arm):" msgstr "" # type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry> #: pkgs.dbk:2317 msgid "hurd-i386" msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2337 msgid "" "In this case, the package is up to date on all release architectures in " "unstable (and the extra hurd-i386 doesn't matter, as it's not a release " "architecture)." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2342 msgid "" "Sometimes, the question is raised if it is possible to allow packages in " "that are not yet built on all architectures: No. Just plainly no. (Except " "if you maintain glibc or so.)" msgstr "" # type: Content of: <chapter><section><section><section><title> #: pkgs.dbk:2349 msgid "Removals from testing" msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2351 msgid "" "Sometimes, a package is removed to allow another package in: This happens " "only to allow <emphasis>another</emphasis> package to go in if it's ready in " "every other sense. Suppose e.g. that <emphasis>a</emphasis> cannot be " "installed with the new version of <emphasis>b</emphasis>; then " "<emphasis>a</emphasis> may be removed to allow <emphasis>b</emphasis> in." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2358 msgid "" "Of course, there is another reason to remove a package from testing: It's " "just too buggy (and having a single RC-bug is enough to be in this state)." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2362 msgid "" "Furthermore, if a package has been removed from unstable, and no package in " "testing depends on it any more, then it will automatically be removed." msgstr "" # type: Content of: <chapter><section><section><section><title> #: pkgs.dbk:2368 msgid "circular dependencies" msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2370 msgid "" "A situation which is not handled very well by britney is if package " "<emphasis>a</emphasis> depends on the new version of package " "<emphasis>b</emphasis>, and vice versa." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2375 msgid "An example of this is:" msgstr "" # type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry> #: pkgs.dbk:2388 msgid "a" msgstr "" # type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry> #: pkgs.dbk:2389 msgid "1; depends: b=1" msgstr "" # type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry> #: pkgs.dbk:2390 msgid "2; depends: b=2" msgstr "" # type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry> #: pkgs.dbk:2393 msgid "b" msgstr "" # type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry> #: pkgs.dbk:2394 msgid "1; depends: a=1" msgstr "" # type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry> #: pkgs.dbk:2395 msgid "2; depends: a=2" msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2401 msgid "" "Neither package <emphasis>a</emphasis> nor package <emphasis>b</emphasis> is " "considered for update." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2405 msgid "" "Currently, this requires some manual hinting from the release team. Please " "contact them by sending mail to &email-debian-release; if this happens to " "one of your packages." msgstr "" # type: Content of: <chapter><section><section><section><title> #: pkgs.dbk:2412 msgid "influence of package in testing" msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2414 msgid "" "Generally, there is nothing that the status of a package in testing means " "for transition of the next version from unstable to testing, with two " "exceptions: If the RC-bugginess of the package goes down, it may go in even " "if it is still RC-buggy. The second exception is if the version of the " "package in testing is out of sync on the different arches: Then any arch " "might just upgrade to the version of the source package; however, this can " "happen only if the package was previously forced through, the arch is in " "fuckedarches, or there was no binary package of that arch present in " "unstable at all during the testing migration." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2424 msgid "" "In summary this means: The only influence that a package being in testing " "has on a new version of the same package is that the new version might go in " "easier." msgstr "" # type: Content of: <chapter><section><section><section><title> #: pkgs.dbk:2431 msgid "details" msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2433 msgid "If you are interested in details, this is how britney works:" msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2436 msgid "" "The packages are looked at to determine whether they are valid candidates. " "This gives the update excuses. The most common reasons why a package is not " "considered are too young, RC-bugginess, and out of date on some arches. For " "this part of britney, the release managers have hammers of various sizes to " "force britney to consider a package. (Also, the base freeze is coded in " "that part of britney.) (There is a similar thing for binary-only updates, " "but this is not described here. If you're interested in that, please peruse " "the code.)" msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2445 msgid "" "Now, the more complex part happens: Britney tries to update testing with the " "valid candidates; first, each package alone, and then larger and even larger " "sets of packages together. Each try is accepted if testing is not more " "uninstallable after the update than before. (Before and after this part, " "some hints are processed; but as only release masters can hint, this is " "probably not so important for you.)" msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2453 msgid "" "If you want to see more details, you can look it up on " "merkel:/org/&ftp-debian-org;/testing/update_out/ (or there in " "~aba/testing/update_out to see a setup with a smaller packages file). Via " "web, it's at <ulink " "url=\"http://&ftp-master-host;/testing/update_out_code/\"></ulink>" msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2460 msgid "" "The hints are available via <ulink " "url=\"http://&ftp-master-host;/testing/hints/\"></ulink>." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:2468 msgid "Direct updates to testing" msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:2470 msgid "" "The testing distribution is fed with packages from unstable according to the " "rules explained above. However, in some cases, it is necessary to upload " "packages built only for testing. For that, you may want to upload to " "<emphasis>testing-proposed-updates</emphasis>." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:2476 msgid "" "Keep in mind that packages uploaded there are not automatically processed, " "they have to go through the hands of the release manager. So you'd better " "have a good reason to upload there. In order to know what a good reason is " "in the release managers' eyes, you should read the instructions that they " "regularly give on &email-debian-devel-announce;." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:2483 msgid "" "You should not upload to <emphasis>testing-proposed-updates</emphasis> when " "you can update your packages through <emphasis>unstable</emphasis>. If you " "can't (for example because you have a newer development version in " "unstable), you may use this facility, but it is recommended that you ask for " "authorization from the release manager first. Even if a package is frozen, " "updates through unstable are possible, if the upload via unstable does not " "pull in any new dependencies." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:2492 msgid "" "Version numbers are usually selected by adding the codename of the testing " "distribution and a running number, like 1.2sarge1 for the first upload " "through testing-proposed-updates of package version 1.2." msgstr "" # type: Content of: <chapter><section><section><para> #: pkgs.dbk:2497 msgid "Please make sure you didn't miss any of these items in your upload:" msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:2502 msgid "" "Make sure that your package really needs to go through " "<emphasis>testing-proposed-updates</emphasis>, and can't go through " "unstable;" msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:2508 msgid "Make sure that you included only the minimal amount of changes;" msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:2513 msgid "Make sure that you included an appropriate explanation in the changelog;" msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:2518 msgid "" "Make sure that you've written <emphasis>testing</emphasis> or " "<emphasis>testing-proposed-updates</emphasis> into your target distribution;" msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:2524 msgid "" "Make sure that you've built and tested your package in " "<emphasis>testing</emphasis>, not in <emphasis>unstable</emphasis>;" msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:2530 msgid "" "Make sure that your version number is higher than the version in " "<emphasis>testing</emphasis> and " "<emphasis>testing-proposed-updates</emphasis>, and lower than in " "<emphasis>unstable</emphasis>;" msgstr "" # type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: pkgs.dbk:2537 msgid "" "After uploading and successful build on all platforms, contact the release " "team at &email-debian-release; and ask them to approve your upload." msgstr "" # type: Content of: <chapter><section><section><title> #: pkgs.dbk:2545 msgid "Frequently asked questions" msgstr "" # type: Content of: <chapter><section><section><section><title> #: pkgs.dbk:2547 msgid "What are release-critical bugs, and how do they get counted?" msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2549 msgid "" "All bugs of some higher severities are by default considered " "release-critical; currently, these are critical, grave, and serious bugs." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2553 msgid "" "Such bugs are presumed to have an impact on the chances that the package " "will be released with the stable release of Debian: in general, if a package " "has open release-critical bugs filed on it, it won't get into testing, and " "consequently won't be released in stable." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2559 msgid "" "The unstable bug count are all release-critical bugs without either any " "release-tag (such as potato, woody) or with release-tag sid; also, only if " "they are neither fixed nor set to sarge-ignore. The testing bug count for a " "package is considered to be roughly the bug count of unstable count at the " "last point when the testing version equalled the unstable version." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2566 msgid "" "This will change post-sarge, as soon as we have versions in the bug tracking " "system." msgstr "" # type: Content of: <chapter><section><section><section><title> #: pkgs.dbk:2572 msgid "How could installing a package into testing possibly break other packages?" msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2574 msgid "" "The structure of the distribution archives is such that they can only " "contain one version of a package; a package is defined by its name. So when " "the source package acmefoo is installed into testing, along with its binary " "packages acme-foo-bin, acme-bar-bin, libacme-foo1 and libacme-foo-dev, the " "old version is removed." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2581 msgid "" "However, the old version may have provided a binary package with an old " "soname of a library, such as libacme-foo0. Removing the old acmefoo will " "remove libacme-foo0, which will break any packages which depend on it." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2586 msgid "" "Evidently, this mainly affects packages which provide changing sets of " "binary packages in different versions (in turn, mainly libraries). However, " "it will also affect packages upon which versioned dependencies have been " "declared of the ==, <=, or << varieties." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2592 msgid "" "When the set of binary packages provided by a source package change in this " "way, all the packages that depended on the old binaries will have to be " "updated to depend on the new binaries instead. Because installing such a " "source package into testing breaks all the packages that depended on it in " "testing, some care has to be taken now: all the depending packages must be " "updated and ready to be installed themselves so that they won't be broken, " "and, once everything is ready, manual intervention by the release manager or " "an assistant is normally required." msgstr "" # type: Content of: <chapter><section><section><section><para> #: pkgs.dbk:2602 msgid "" "If you are having problems with complicated groups of packages like this, " "contact debian-devel or debian-release for help." msgstr ""