X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?a=blobdiff_plain;f=developers-reference.sgml;h=08d332289cfb0fc5a3a11c307a9e6106471feb54;hb=43e4deb6e74fb659fa1f0823e7f11c0798d3faec;hp=9fad180f20eb58afa4e60c0f30d2e4594f5a847c;hpb=12fbee5c84dfbf838146cb5ea38b122ceecd0041;p=developers-reference.git diff --git a/developers-reference.sgml b/developers-reference.sgml index 9fad180..08d3322 100644 --- a/developers-reference.sgml +++ b/developers-reference.sgml @@ -6,12 +6,11 @@ %commondata; - + + - + revision of the original developer's reference in cvs-en-rev --> + FIXME: "> @@ -142,7 +141,7 @@ name="New Maintainer's Corner">. It describes exactly the preparations you have to do before you can register to become a Debian developer. -For example, before you apply, you have to to read the . Registering as a developer means that you agree with and pledge to uphold the Debian Social Contract; it is very important that @@ -221,7 +220,7 @@ To apply as a new maintainer, you need an existing Debian maintainer to verify your application (an advocate). After you have contributed to Debian for a while, and you want to apply to become a registered developer, an existing developer with whom you -have worked over the past months has to express his belief that you +have worked over the past months has to express their belief that you can contribute to Debian successfully.

When you have found an advocate, have your GnuPG key signed and have @@ -715,7 +714,7 @@ Those features are documented at .

The &debian-formal; distribution consists of a lot of packages (.deb's, currently around &number-of-pkgs;) and a few -additional files (such documentation and installation disk images). +additional files (such as documentation and installation disk images).

Here is an example directory tree of a complete Debian archive:

@@ -740,13 +739,13 @@ In each of the areas, there is a directory for the source packages (source) and a directory for each supported architecture (binary-i386, binary-m68k, etc.).

-The main area contains additional directories which holds +The main area contains additional directories which hold the disk images and some essential pieces of documentation required for installing the Debian distribution on a specific architecture (disks-i386, disks-m68k, etc.). - Sections + Sections

The main section of the Debian archive is what makes up the official &debian-formal; distribution. The @@ -808,7 +807,7 @@ The Linux 2.0 kernel supports Intel x86, DEC Alpha, SPARC, Motorola Linux 2.2 kernel supports even more architectures, including ARM and UltraSPARC. Since Linux supports these platforms, Debian decided that it should, too. Therefore, Debian has ports underway; in fact, we -also have ports underway to non-Linux kernel. Aside from +also have ports underway to non-Linux kernels. Aside from i386 (our name for Intel x86), there is m68k, alpha, powerpc, sparc, hurd-i386, arm, ia64, hppa, s390, mips, @@ -822,7 +821,7 @@ ships for the i386, m68k, alpha, and support of five new architectures: ia64, hppa, s390, mips and mipsel.

-Information for developers or uses about the specific ports are +Information for developers and users about the specific ports are available at the . @@ -887,11 +886,11 @@ distribution changes from day-to-day. Since no special effort is done to make sure everything in this distribution is working properly, it is sometimes literally unstable.

- is generated automatically by taking +"testing" is generated automatically by taking packages from unstable if they satisfy certain criteria. Those criteria should ensure a good quality for packages within testing. The update to testing is launched each day after the -new packages have been installed. +new packages have been installed. See .

After a period of development, once the release manager deems fit, the testing distribution is frozen, meaning that the policies @@ -957,7 +956,7 @@ in testing; The packages on which it depends must either be available in testing or they must be accepted into testing at the same time (and they will -if they respect themselves all the criteria); +if they respect all the necessary criteria);

To find out whether a package is progressing into testing or not, see the @@ -969,12 +968,12 @@ informed of the progression of their packages into testing.

The update_excuses file does not always give the precise reason why the package is refused, one may have to find it on their own by looking -what would break with the inclusion of the package. The gives some more information -about the usual problems which may be causing such troubles. +for what would break with the inclusion of the package. The + gives some more +information about the usual problems which may be causing such troubles.

Sometimes, some packages never enter testing because the set of -inter-relationship is too complicated and can not be sorted out +inter-relationship is too complicated and cannot be sorted out by the scripts. In that case, the release manager must be contacted, and he will force the inclusion of the packages.

@@ -1011,7 +1010,7 @@ into experimental. Whenever there is a new upstream version of a package that introduces new features but breaks a lot of old ones, it should either not be uploaded, or be uploaded to experimental. A new, beta, version of some software -which uses completely different configuration can go into +which uses a completely different configuration can go into experimental, at the maintainer's discretion. If you are working on an incompatible or complex upgrade situation, you can also use experimental as a staging area, so that testers can get early @@ -1074,8 +1073,8 @@ symbolic links for stable, testing, and

The various download archives and the web site have several mirrors available in order to relieve our canonical servers from heavy load. -In fact, some of the canonical servers aren't public, and instead a -first tier of mirrors balances the load. That way, users always access +In fact, some of the canonical servers aren't public — a first tier +of mirrors balances the load instead. That way, users always access the mirrors and get used to using them, which allows Debian to better spread its bandwidth requirements over several servers and networks, and basically makes users avoid hammering on one primary location. @@ -1097,15 +1096,16 @@ have accounts on these machines. The Incoming system

-The Incoming system is responsible of collecting updated packages and +The Incoming system is responsible for collecting updated packages and installing them in the Debian archive. It consists of a set of directories and scripts that are installed both on &ftp-master-host; and &non-us-host;.

Packages are uploaded by all the maintainers into a directory called unchecked. This directory is scanned every 15 minutes by -the katie script, which verifies the integrity of the uploaded packages and the cryptographic -signatures. If the package is considered ready to be installed, it +the katie script, which verifies the integrity of the uploaded +packages and their cryptographic signatures. +If the package is considered ready to be installed, it is moved into the accepted directory. If this is the first upload of the package, it is moved in the new directory, where it waits for an approval of the ftpmasters. If the package contains files to be installed @@ -1192,8 +1192,8 @@ available in the various distributions. Each version links to a page which provides information, including the package description, the dependencies and package download links.

-The bug tracking system track bugs for each package. You can -view the bugs of a given package at the URL +The bug tracking system tracks bugs for each package. +You can view the bugs of a given package at the URL http://&bugs-host;/package-name. The madison utility @@ -1225,7 +1225,7 @@ the activity of a source package. This really means that you can get the same emails that the package maintainer gets, simply by subscribing to the package in the PTS.

-Each email sent through the PTS is classified and associated to one of +Each email sent through the PTS is classified under one of the keywords listed below. This will let you select the mails that you want to receive.

@@ -1338,7 +1338,7 @@ various commands to pts@qa.debian.org. keyword [<email>] {+|-|=} <list of keywords> - Accept (+) or refuse (-) mails associated to the given keyword(s). + Accept (+) or refuse (-) mails classified under the given keyword(s). Define the list (=) of accepted keywords. keyword <sourcepackage> [<email>] {+|-|=} <list of keywords> @@ -1420,7 +1420,7 @@ Usual news items may be used to announce that: something important will affect the package

-Both kind of news are generated in a similar manner: you just have to send +Both kinds of news are generated in a similar manner: you just have to send an email either to pts-static-news@qa.debian.org or to pts-news@qa.debian.org. The mail should indicate which package is concerned by having the name of the source package in a @@ -1573,7 +1573,7 @@ Changelog entries can be used to automatically close Debian bugs when the package is installed into the archive. See .

-It is conventional that the changelog entry notating of a package that +It is conventional that the changelog entry of a package that contains a new upstream version of the software looks like this: * new upstream version @@ -1676,11 +1676,8 @@ Actually, there are two other possible distributions: `stable-security' and `testing-security', but read for more information on those.

-It is technically possible to upload a package into several distributions -at the same time but it usually doesn't make sense to use that feature -because the dependencies of the package may vary with the distribution. -In particular, it never makes sense to combine the experimental -distribution with anything else (see ). +It is not possible to upload a package into several distributions +at the same time. Special case: uploads to the stable distribution @@ -1704,8 +1701,8 @@ appropriate proposed-updates archive when the advisory is released. See for detailed information on handling security problems.

-It is discouraged to change anything else in the package that isn't -important, because even trivial fixes can cause bugs later on. +Changing anything else in the package that isn't important is discouraged, +because even trivial fixes can cause bugs later on.

Packages uploaded to stable need to be compiled on systems running stable, so that their dependencies are limited to the libraries @@ -1721,6 +1718,10 @@ your package can be included in stable. Please be clear (and verbose, if necessary) in your changelog entries for uploads to stable, because otherwise the package won't be considered for inclusion. +

+It's best practice to speak with the stable release manager before +uploading to stable/stable-proposed-updates, so that the +uploaded package fits the needs of the next point release. Special case: uploads to testing-proposed-updates @@ -1746,25 +1747,17 @@ the authorization of the release manager before. Uploading to ftp-master

-To upload a package, you need a personal account on -&ftp-master-host;, which you should have as an -official maintainer. If you use scp or rsync -to transfer the files, place them into &us-upload-dir;; -if you use anonymous FTP to upload, place them into -&upload-queue;. -

-If you want to use feature described in , -you'll have to upload to ftp-master. It is the only upload -point that supports delayed incoming. +To upload a package, you should upload the files (including the signed +changes and dsc-file) with anonymous ftp to +&ftp-master-host; in the directory &upload-queue;. +To get the files processed there, they need to be signed with a key in the +debian keyring.

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. If you don't want to bother with transferring -the changes file last, you can simply copy your files to a temporary -directory on ftp-master and then move them to -&us-upload-dir;. -

+all files have been uploaded. +

Note: Do not upload to ftp-master cryptographic packages which belong to contrib or non-free. Uploads of such software should go to non-us (see ftp-master; depending on the case they may still be uploaded to non-US/non-free (it's in non-free because of distribution issues and not because of the license of the software). If you can't upload it to -ftp-master, then neither can you upload it to the overseas upload -queues on chiark or erlangen. If you are not sure +ftp-master, then neither can you upload it to backup +queues that finally also end up on ftp-master. If you are not sure whether U.S. patent controls or cryptographic controls apply to your package, post a message to &email-debian-devel; and ask.

You may also find the Debian packages or useful -when uploading packages. These handy programs help automate the +when uploading packages. These handy programs help automate the process of uploading packages into Debian.

-After uploading your package, you can check how the archive -maintenance software will process it by running dinstall -on your changes file: -dinstall -n foo.changes -

-Note that dput can do this for you automatically. +For removing packages, please see the README file in that ftp directory, +and the Debian package . Uploading to non-US

-As discussed above, export controlled software should not be uploaded -to ftp-master. Instead, upload the package to -non-us.debian.org, placing the files in -&non-us-upload-dir; (again, both and can do this for you if invoked properly). By default, -you can use the same account/password that works on -ftp-master. If you use anonymous FTP to upload, place the -files into &upload-queue;. +Note: non-us is currently not processed any more.

-You can check your upload the same way it's done on ftp-master, -with: -dinstall -n foo.changes +As discussed above, export controlled software should not be uploaded +to ftp-master. Instead, upload the package with anonymous FTP +to non-us.debian.org, placing the files in +&upload-queue; (again, both and can do this for you if invoked properly).

Note that U.S. residents or citizens are subject to restrictions on export of cryptographic software. As of this writing, U.S. citizens @@ -1834,64 +1818,50 @@ advice. Again, it is strongly recommended that U.S. citizens and residents consult a lawyer before doing uploads to non-US. - Uploads via chiark -

-If you have a slow network connection to ftp-master, there are -alternatives. One is to upload files to Incoming via a -upload queue in Europe on chiark. For details connect to -. -

-Note: Do not upload packages containing software that is -export-controlled by the United States government to the queue on -chiark. Since this upload queue goes to ftp-master, the -prescription found in applies here as well. -

-The program dupload comes with support for uploading to -chiark; please refer to the documentation that comes with the -program for details. - - - Uploads via erlangen -

-Another upload queue is available in Germany: just upload the files -via anonymous FTP to . + Delayed uploads

-The upload must be a complete Debian upload, as you would put it into -ftp-master's Incoming, i.e., a .changes files -along with the other files mentioned in the .changes. The -queue daemon also checks that the .changes is correctly -signed with GnuPG or OpenPGP by a Debian developer, so that no bogus files can find -their way to ftp-master via this queue. Please also make sure that -the Maintainer field in the .changes contains -your e-mail address. The address found there is used for all -replies, just as on ftp-master. +Delayed uploads are done for the moment via the delayed queue at +gluck. The upload-directory is +gluck:~tfheen/DELAYED/[012345678]-day. +0-day is uploaded approximately one hour before dinstall runs.

-There's no need to move your files into a second directory after the -upload, as on chiark. And, in any case, you should get a -mail reply from the queue daemon explaining what happened to your -upload. Hopefully it should have been moved to ftp-master, but in -case of errors you're notified, too. +With a fairly recent dput, this section + +[tfheen_delayed] +method = scp +fqdn = gluck.debian.org +incoming = ~tfheen + +in ~/.dput.cf should work fine for uploading to the DELAYED queue.

-Note: Do not upload packages containing software that is -export-controlled by the United States government to the queue on -erlangen. Since this upload queue goes to ftp-master, the +Note: +Since this upload queue goes to ftp-master, the prescription found in applies here as well. -

-The program dupload comes with support for uploading to -erlangen; please refer to the documentation that comes with -the program for details. + Security uploads +

+Do NOT 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 . Other upload queues

-Another upload queue is available which is based in the US, and is a -good backup when there are problems reaching ftp-master. You can -upload files, just as in erlangen, to . +The scp queues on ftp-master, non-us and security are mostly unuseable +due to the login restrictions on those hosts.

-An upload queue is available in Japan: just upload the files via -anonymous FTP to . - +The anonymous queues on ftp.uni-erlangen.de and ftp.uk.debian.org are +currently down. Work is underway to resurrect those. +

+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. +

+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. Notification that a new package has been installed @@ -1918,7 +1888,7 @@ will receive a separate email notifying you of that. Read on below. Note also that if you upload via queues, the queue daemon software will also send you a notification by email. - Determining section and priority of a package + Specifying the package section, subsection and priority

The debian/control file's Section and Priority fields do not actually specify where the file will @@ -1947,9 +1917,11 @@ For more information about override files, see and .

-Note also that the term "section" is used for the separation of packages -according to their licensing, e.g. main, contrib and -non-free. This is described in another section, . +Note that the Section field describes both the section as +well as the subsection, which are described in . If the section is "main", it should be +omitted. The list of allowable subsections can be found in . Handling bugs @@ -2042,14 +2014,14 @@ Here's a list of steps that you may follow to handle a bug report: 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 his problem (give pointers +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 to the upstream author.

-If the bug submitter disagree with your decision to close the bug, +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 wontfix to let people know that the bug exists but that it won't be corrected. @@ -2060,10 +2032,10 @@ the BTS if you wish to keep it reported against your package). Before doing so, please read the . If the bug is real but it's caused by another package, just reassign -the bug the right package. If you don't know which package it should +the bug to the right package. If you don't know which package it should be reassigned to, you may either ask for help on &email-debian-devel; or reassign it to debian-policy to let them decide which -package is in fault. +package is at fault.

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 @@ -2071,8 +2043,8 @@ 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. -The bug submitter may have forgotten to provide some information, in that -case you have to ask him the information required. You may use the +The bug submitter may have forgotten to provide some information, in which +case you have to ask them the required information. You may use the moreinfo tag to mark the bug as such. Moreover if you can't reproduce the bug, you tag it unreproducible. Anyone who can reproduce the bug is then invited to provide more information @@ -2148,7 +2120,7 @@ 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 XXX-done@&bugs-host;. Do not close bugs in the changelog entry of a version if -the changes in that version of the package doesn't have any bearing on +the changes in that version of the package don't have any bearing on the bug.

For general information on how to write your changelog entries, see @@ -2170,8 +2142,10 @@ security advisories, and maintaining security.debian.org. 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. Useful information -includes, for example: +&email-security-team; as soon as possible. DO NOT UPLOAD any +packages for stable; the security team will do that. + +Useful information includes, for example: What versions of the package are known to be affected by the @@ -2208,7 +2182,7 @@ There are a few ways a developer can learn of a security problem: he notices it on a public forum (mailing list, web site, etc.) someone files a bug report - someone informs him via private email + someone informs them via private email In the first two cases, the information is public and it is important @@ -2242,7 +2216,7 @@ itself is public, and can (and will) be examined by the general public.

There are two reasons for releasing information even though secrecy is -requested: the problem has been known for a while, or that the problem +requested: the problem has been known for a while, or the problem or exploit has become public. Security Advisories @@ -2315,30 +2289,48 @@ 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.

+Do NOT 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. +

Review and test your changes as much as possible. Check the differences from the previous version repeatedly (interdiff from the patchutils package and debdiff from devscripts are useful tools for this, see ).

-When packaging the fix, keep the following points in mind: +Be sure to verify the following items: - Make sure you target the right distribution in your + Target the right distribution in your debian/changelog. For stable this is stable-security and for testing this is testing-security, and for the previous stable release, this is oldstable-security. Do not target - distribution-proposed-updates! + distribution-proposed-updates or stable! + + The upload should have urgency=high. Make descriptive, meaningful changelog entries. Others will rely on them to determine whether a particular bug was fixed. - Whenever possible, include an external reference, preferably a CVE - identifier, so that it can be cross-referenced. + 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. 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 dpkg - --compare-versions. For testing, there must be + --compare-versions. Be careful not to re-use a version + number that you have already used for a previous upload. For + testing, there must be a higher version in unstable. If there is none yet (for example, if testing and unstable have the same version) you must upload a new version to unstable first. @@ -2349,17 +2341,18 @@ When packaging the fix, keep the following points in mind: not build those. This point applies to normal package uploads as well. - If the upstream source has been uploaded to + Unless the upstream source has been uploaded to security.debian.org before (by a previous security update), build - the upload without the upstream source (dpkg-buildpackage - -sd). Otherwise, build with full source - (dpkg-buildpackage -sa). + the upload with full upstream source (dpkg-buildpackage + -sa). If there has been a previous upload to + security.debian.org with the same upstream version, you may upload + without upstream source (dpkg-buildpackage -sd). Be sure to use the exact same *.orig.tar.gz as used in the normal archive, otherwise it is not possible to move the security fix into the main archives later. - Be sure to build the package on a clean + 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 ) @@ -2455,9 +2448,9 @@ 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.

-Usually you only ask the removal of a package maintained by yourself. +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 last maintainer. +of its maintainer.

If in doubt concerning whether a package is disposable, email &email-debian-devel; asking for opinions. Also of interest is the @@ -2465,6 +2458,7 @@ If in doubt concerning whether a package is disposable, email package. When invoked as apt-cache showpkg package, the program will show details for package, including reverse depends. +Removal of orphaned packages is discussed on &email-debian-qa;.

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 @@ -2477,7 +2471,7 @@ software is simply no more part of Debian. In the past, it was possible to remove packages from incoming. 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 as the package you want to replace. Both versions will be +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 unstable since the previous version will immediately be replaced by the higher. However, if you do proper testing of your @@ -2485,8 +2479,8 @@ packages, the need to replace a package should not occur too often anyway. Replacing or renaming packages

-Sometimes you made a mistake naming the package and you need to rename -it. In this case, you need to follow a two-step process. First, set +When you make a mistake naming your package, you should follow a two-step +process to rename it. First, set your debian/control file to replace and conflict with the obsolete name of the package (see the for details). Once you've uploaded @@ -2571,7 +2565,7 @@ portability. Therefore, even if you are not a porter, you should read most of this chapter.

Porting is the act of building Debian packages for architectures that -is different from the original architecture of the package +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 i386 binary package, there must be @@ -2588,7 +2582,7 @@ 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.

-The first and most important watchword is to respond quickly to bug or +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, @@ -2637,7 +2631,7 @@ They should be removed by the `clean' target of Make sure you don't rely on locally installed or hacked configurations or programs. For instance, you should never be calling programs in /usr/local/bin or the like. Try not to rely on programs -be setup in a special way. Try building your package on another +being setup in a special way. Try building your package on another machine, even if it's the same architecture. Don't depend on the package you're building already being installed (a @@ -2750,7 +2744,7 @@ 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. +blessing or status, so buyer beware. @@ -2824,7 +2818,7 @@ called a non-maintainer upload, or NMU. Debian porters, who compile packages for different architectures, occasionally do binary-only NMUs as part of their porting activity (see ). Another reason why NMUs are done is when a -Debian developers needs to fix another developers' packages in order to +Debian developer needs to fix another developer's packages in order to address serious security problems or crippling bugs, especially during the freeze, or when the package maintainer is unable to release a fix in a timely fashion. @@ -2905,12 +2899,12 @@ 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. -Wait a few days the response from the maintainer. If you don't get -any response, you may want to help him by sending the patch that fixes +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. Wait a few more days. If you still haven't got an answer from the -maintainer, send him a mail announcing your intent to NMU the package. +maintainer, send them a mail announcing your intent to NMU the package. Prepare an NMU as described in , test it carefully on your machine (cf. ). Double check that your patch doesn't have any unexpected side effects. @@ -2938,8 +2932,8 @@ and act later.

The following applies to porters insofar as they are playing the dual role of being both package bug-fixers and package porters. If a -porter has to change the Debian source archive, automatically their -upload is a source NMU and is subject to its rules. If a porter is +porter has to change the Debian source archive, their upload is +automatically a source NMU and is subject to its rules. If a porter is simply uploading a recompiled binary package, the rules are different; see .

@@ -3065,7 +3059,7 @@ 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 and 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 to help you on a more frequent +ask them if they would be interested in helping you on a more frequent basis as co-maintainer or backup maintainer (see ). @@ -3081,7 +3075,7 @@ packages in which a priority of Standard or which are part of the base set have co-maintainers.

Generally there is a primary maintainer and one or more -co-maintainers. The primary maintainer is the whose name is listed in +co-maintainers. The primary maintainer is the person whose name is listed in the Maintainer field of the debian/control file. Co-maintainers are all the other maintainers.

@@ -3253,7 +3247,7 @@ this using an hand-crafted debian/rules file.

The following practices are relevant to the debian/control file. They supplement the .

The description of the package, as defined by the corresponding field @@ -4401,6 +4395,12 @@ check the GnuPG signature and checksums before uploading, and the possibility of running dinstall in dry-run mode after the upload. + + dcut +

+The dcut script (part of the package ) +helps in removing files from the ftp upload directory. +