X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?a=blobdiff_plain;f=developers-reference.sgml;h=a09903cfd840dcdd2035f96644ebf1d09a5a1873;hb=5381651c352723b79a2c71528f5fd0670d826725;hp=8698e292cf5c22047500915027370c8cfb5b9660;hpb=7b4eb78a176fb544351c029399682b7a74ff89a0;p=developers-reference.git diff --git a/developers-reference.sgml b/developers-reference.sgml index 8698e29..a09903c 100644 --- a/developers-reference.sgml +++ b/developers-reference.sgml @@ -7,7 +7,7 @@ %dynamicdata; - + @@ -31,7 +31,7 @@ -copyright © 2004—2005 Andreas Barth +copyright © 2004—2007 Andreas Barth copyright © 1998—2003 Adam Di Carlo @@ -144,6 +144,11 @@ get started. Finally, if you are interested in documentation or Quality Assurance (QA) work you can join maintainers already working on these tasks and submit patches and improvements. +

+One pitfall could be a too-generic local part in your mailadress: +Terms like mail, admin, root, master should be avoided, please +see for details. + Debian mentors and sponsors

@@ -158,14 +163,14 @@ post to that list and an experienced developer will volunteer to help. In addition, if you have some packages ready for inclusion in Debian, but are waiting for your new maintainer application to go through, you might be able find a sponsor to upload your package for you. Sponsors -are people who are official Debian maintainers, and who are willing to +are people who are official Debian Developers, and who are willing to criticize and upload your packages for you. Please read the -inofficial debian-mentors FAQ at first. +unofficial debian-mentors FAQ at first.

If you wish to be a mentor and/or sponsor, more information is available in . @@ -175,7 +180,7 @@ available in .

Before you decide to register with &debian-formal;, you will need to read all the information available at the . It describes exactly the +name="New Maintainer's Corner">. It describes in detail the preparations you have to do before you can register to become a Debian developer. @@ -190,7 +195,7 @@ Manifesto"> would also be a good idea. The process of registering as a developer is a process of verifying your identity and intentions, and checking your technical skills. As the number of people working on &debian-formal; has grown to over -&number-of-maintainers; people and our systems are used in several +&number-of-maintainers; and our systems are used in several very important places, we have to be careful about being compromised. Therefore, we need to verify new maintainers before we can give them accounts on our servers and let them upload packages. @@ -199,7 +204,8 @@ Before you actually register you should have shown that you can do competent work and will be a good contributor. You show this by submitting patches through the Bug Tracking System and having a package -sponsored by an existing maintainer for a while. Also, we expect that +sponsored by an existing Debian Developer for a while. +Also, we expect that contributors are interested in the whole project and not just in maintaining their own packages. If you can help other maintainers by providing further information on a bug or even a patch, then do so! @@ -207,19 +213,19 @@ providing further information on a bug or even a patch, then do so! Registration requires that you are familiar with Debian's philosophy and technical documentation. Furthermore, you need a GnuPG key which has been signed by an existing Debian maintainer. If your GnuPG key -is not signed yet, you should try to meet a Debian maintainer in +is not signed yet, you should try to meet a Debian Developer in person to get your key signed. There's a which should help you find -a maintainer close to you. -(If there is no Debian maintainer close to you, +a Debian Developer close to you. +(If there is no Debian Developer close to you, alternative ways to pass the ID check may be permitted as an absolute exception on a case-by-case-basis. See the -for more informations.) +for more information.)

If you do not have an OpenPGP key yet, generate one. Every developer -needs a OpenPGP key in order to sign and verify package uploads. You +needs an OpenPGP key in order to sign and verify package uploads. You should read the manual for the software you are using, since it has much important information which is critical to its security. Many more security failures are due to human error than to software failure @@ -232,15 +238,43 @@ You can use some other implementation of OpenPGP as well. Note that OpenPGP is an open standard based on .

-You need a type 4 key for use in Debian Development. +You need a version 4 key for use in Debian Development. Your key length must be at least 1024 bits; there is no reason to use a smaller key, and doing so would be -much less secure. Your key must be signed with your own user -ID; this prevents user ID tampering. gpg does this -automatically. +much less secure. +Version 4 keys are keys conforming to +the OpenPGP standard as defined in RFC 2440. Version 4 is the key +type that has always been created when using GnuPG. PGP versions +since 5.x also could create v4 keys, the other choice having beein +pgp 2.6.x compatible v3 keys (also called "legacy RSA" by PGP). +

+Version 4 (primary) keys can either use the RSA or the DSA algorithms, +so this has nothing to do with GnuPG's question about "which kind +of key do you want: (1) DSA and Elgamal, (2) DSA (sign only), (5) +RSA (sign only)". If you don't have any special requirements just pick +the default. +

+The easiest way to tell whether an existing key is a v4 key or a v3 +(or v2) key is to look at the fingerprint: +Fingerprints of version 4 keys are the SHA-1 hash of some key matieral, +so they are 40 hex digits, usually grouped in blocks of 4. Fingerprints +of older key format versions used MD5 and are generally shown in blocks +of 2 hex digits. For example if your fingerprint looks like +5B00 C96D 5D54 AEE1 206B  AF84 DE7A AF6E 94C0 9C7F +then it's a v4 key. +

+Another possibility is to pipe the key into pgpdump, +which will say something like "Public Key Packet - Ver 4". +

+Also note that your key must be self-signed (i.e. it has to sign +all its own user IDs; this prevents user ID tampering). All +modern OpenPGP software does that automatically, but if you +have an older key you may have to manually add those signatures. +

-If your public key isn't on public key servers such as &pgp-keyserv;, -please read the documentation available locally in &file-keyservs;. +If your public key isn't on a public key server such as &pgp-keyserv;, +please read the documentation available at +. That document contains instructions on how to put your key on the public key servers. The New Maintainer Group will put your public key on the servers if it isn't already there. @@ -253,8 +287,8 @@ If you live in a country where use of cryptography even for authentication is forbidden then please contact us so we can make special arrangements.

-To apply as a new maintainer, you need an existing Debian maintainer -to verify your application (an advocate). After you have +To apply as a new maintainer, you need an existing Debian Developer +to support 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 their belief that you @@ -340,10 +374,10 @@ You don't have to track the pre-vote discussions, as the secretary will issue several calls for votes on &email-debian-devel-announce; (and all developers are expected to be subscribed to that list). Democracy doesn't work well if people don't take part in the vote, which is why we encourage -all developers to vote. Voting is conducted via GPG-signed/encrypted emails +all developers to vote. Voting is conducted via GPG-signed/encrypted email messages.

-The list of all the proposals (past and current) is available on the +The list of all proposals (past and current) is available on the page, along with information on how to make, second and vote on proposals. @@ -352,14 +386,14 @@ information on how to make, second and vote on proposals.

It is common for developers to have periods of absence, whether those are planned vacations or simply being buried in other work. The important thing -to notice is that the other developers need to know that you're on vacation +to notice is that other developers need to know that you're on vacation so that they can do whatever is needed if a problem occurs with your packages or other duties in the project.

Usually this means that other developers are allowed to NMU (see -) your package if a big problem (release critical bugs, +) your package if a big problem (release critical bug, security update, etc.) occurs while you're on vacation. Sometimes it's -nothing as critical as that, but it's still appropriate to let the others +nothing as critical as that, but it's still appropriate to let others know that you're unavailable.

In order to inform the other developers, there are two things that you should do. @@ -411,7 +445,7 @@ you need to take care of — the so-called release-critical bugs (RC bugs). All bug reports that have severity critical, grave or serious are considered to have an impact on whether the package can be released in the next stable release of Debian. -Those bugs can delay the Debian release +These bugs can delay the Debian release and/or can justify the removal of a package at freeze time. That's why these bugs need to be corrected as quickly as possible.

@@ -436,11 +470,13 @@ the following steps: Orphan all your packages, as described in . -Send an email about why you are leaving the project to +Send an gpg-signed email about why you are leaving the project to &email-debian-private;. Notify the Debian key ring maintainers that you are leaving by -emailing to &email-debian-keyring;. +opening a ticket in Debian RT by sending a mail +to keyring@rt.debian.org with the words 'Debian RT' somewhere in the subject +line (case doesn't matter). @@ -533,10 +569,9 @@ id="&url-debian-lists-new;">. IRC channels

Several IRC channels are dedicated to Debian's development. They are mainly -hosted on the network -(previously known as Open Projects Network). -The irc.debian.org DNS entry is an alias to -irc.freenode.net. +hosted on the network. The irc.debian.org DNS entry is an alias to +irc.oftc.net.

The main channel for Debian in general is #debian. This is a large, general-purpose channel where users can find recent news in the topic and @@ -561,7 +596,7 @@ just zgrep for #debian-private in all the files.

There are other additional channels dedicated to specific subjects. -#debian-bugs is used for coordinating bug squash parties. +#debian-bugs is used for coordinating bug squashing parties. #debian-boot is used to coordinate the work on the debian-installer. #debian-doc is occasionally used to talk about documentation, like the document you are @@ -576,10 +611,10 @@ Some non-English developers' channels exist as well, for example French speaking people interested in Debian's development.

Channels dedicated to Debian also exist on other IRC networks, notably on -the IRC network. +the IRC network, which was +pointed at by the irc.debian.org alias until 4th June 2006.

-To get a cloak on freenode, you send Göran Weinholt <weinholt@debian.org> +To get a cloak on freenode, you send Jörg Jaspert <joerg@debian.org> a signed mail where you tell what your nick is. Put "cloak" somewhere in the Subject: header. The nick should be registered: @@ -672,7 +707,7 @@ an email to &email-ftpmaster;, but also see the procedures in The non-US server non-us.debian.org was discontinued with the release of sarge. The pseudo-package nonus.debian.org -stil exists for now. +still exists for now. The www-master server

@@ -728,7 +763,7 @@ the Debian account that should own the CVS root area, and why you need it. chroots to different distributions

On some machines, there are chroots to different distributions available. -You can use them like +You can use them like this: vore% dchroot unstable @@ -859,8 +894,8 @@ fields of packages. Architectures

-In the first days, the Linux kernel was only available for the Intel -i386 (or greater) platforms, and so was Debian. But when Linux became +In the first days, the Linux kernel was only available for Intel +i386 (or greater) platforms, and so was Debian. But as Linux became more and more popular, the kernel was ported to other architectures, too.

@@ -903,7 +938,7 @@ outside of Debian, there is just one .tar.gz file which contains the sources of the program. If a package is distributed elsewhere too, the .orig.tar.gz file stores the so-called upstream source code, that is the source code that's -distributed from the upstream maintainer (often the author of +distributed by the upstream maintainer (often the author of the software). In this case, the .diff.gz contains the changes made by the Debian maintainer.

@@ -1020,8 +1055,8 @@ distribution. These are the lines for experimental: -deb http://ftp.xy.debian.org/debian/ ../project/experimental main -deb-src http://ftp.xy.debian.org/debian/ ../project/experimental main +deb http://ftp.xy.debian.org/debian/ experimental main +deb-src http://ftp.xy.debian.org/debian/ experimental main

If there is a chance that the software could do grave damage to a system, @@ -1060,8 +1095,10 @@ to finally get them closed.

Every released Debian distribution has a code name: Debian 1.1 is called `buzz'; Debian 1.2, `rex'; Debian 1.3, `bo'; Debian 2.0, -`hamm'; Debian 2.1, `slink'; Debian 2.2, `potato'; and Debian 3.0, `woody'. There is also -a ``pseudo-distribution'', called `sid', which is the current +`hamm'; Debian 2.1, `slink'; Debian 2.2, `potato'; Debian 3.0, `woody'; +Debian 3.1, "sarge"; +Debian 4.0, "etch". +There is also a ``pseudo-distribution'', called `sid', which is the current `unstable' distribution; since packages are moved from `unstable' to `testing' as they approach stability, `sid' itself is never released. As well as the usual contents of a Debian distribution, `sid' contains @@ -1152,7 +1189,7 @@ accessible at until it is really installed in the Debian archive. This happens only once a day -(and is also called `dinstall run' for historical reasons); +(and is also called the `dinstall run' for historical reasons); the package is then removed from incoming and installed in the pool along with all the other packages. Once all the other updates (generating new @@ -1304,9 +1341,9 @@ header with a non-empty value. summary -(This is a planned expansion.) -The regular summary emails about the package's status (bug statistics, -porting overview, progression in testing, ...). +Regular summary emails about the package's status. +Currently, only progression in testing is sent. +

@@ -1328,12 +1365,17 @@ maintainer has set up forwarding commit notifications to the PTS. Translations of descriptions or debconf templates submitted to the Debian Description Translation Project. + + derivatives + +Information about changes made to the package in derivative distributions +(for example Ubuntu). The PTS email interface

You can control your subscription(s) to the PTS by sending -various commands to pts@qa.debian.org. +various commands to pts@qa.debian.org. @@ -1351,6 +1393,11 @@ various commands to pts@qa.debian.org. using the specified email address or the sender address if the second argument is left out. +unsubscribeall [<email>] + + Removes all subscriptions of the specified email address or the sender + address if the second argument is left out. + which [<email>] Lists all subscriptions for the sender or the email address optionally @@ -1367,6 +1414,7 @@ various commands to pts@qa.debian.org. summary: automatic summary mails about the state of a package cvs: notification of CVS commits ddtp: translations of descriptions and debconf templates + derivatives: changes made on the package by derivative distributions upload-source: announce of a new source upload that has been accepted upload-binary: announce of a new binary-only upload (porting) @@ -1383,7 +1431,14 @@ various commands to pts@qa.debian.org. keyword [<email>] {+|-|=} <list of keywords> Accept (+) or refuse (-) mails classified under the given keyword(s). - Define the list (=) of accepted keywords. + Define the list (=) of accepted keywords. This changes the default set + of keywords accepted by a user. + +keywordall [<email>] {+|-|=} <list of keywords> + + Accept (+) or refuse (-) mails classified under the given keyword(s). + Define the list (=) of accepted keywords. This changes the set of + accepted keywords of all the currently active subscriptions of a user. keyword <sourcepackage> [<email>] {+|-|=} <list of keywords> @@ -1396,6 +1451,12 @@ various commands to pts@qa.debian.org. the bot. +

+The pts-subscribe command-line utility (from the +devscripts package) can be handy to temporarily +subscribe to some packages, for example after having made an +non-maintainer upload. + Filtering PTS mails

Once you are subscribed to a package, you will get the mails sent to @@ -1518,8 +1579,8 @@ distribution, testing status and much more including links to any other useful information.

It is a good idea to look up your own data regularly so that -you don't forget any open bug, and so that you don't forget which -packages are under your responsibility. +you don't forget any open bugs, and so that you don't forget which +packages are your responsibility. Debian *Forge: Alioth

@@ -1587,6 +1648,15 @@ Please include a Closes: bug#nnnnn 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 ). +

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

There are a number of reasons why we ask maintainers to announce their intentions: @@ -1609,7 +1679,9 @@ line of testers). We should encourage these people. The announcements give maintainers and other interested parties a better feel of what is going on, and what is new, in the project. - +

+Please see +for common rejection reasons for a new package. Recording changes in the package

@@ -1676,6 +1748,11 @@ Downgrade the package to the previous version (if one exists) — this tests the postrm and prerm scripts. Remove the package, then reinstall it. + +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. @@ -1718,6 +1795,10 @@ If no original source is included in the upload, the original source tar-file used by dpkg-source when constructing the .dsc file and diff to be uploaded must be byte-for-byte identical with the one already in the archive. +

+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. Picking a distribution @@ -1741,9 +1822,11 @@ at the same time. Special case: uploads to the stable distribution

-Uploading to stable means that the package will be placed into the -stable-proposed-updates directory of the Debian archive for further -testing before it is actually included in stable. +Uploading to stable means that the package will transfered to the +p-u-new-queue for review by the stable release managers, and +if approved will be installed in +stable-proposed-updates directory of the Debian archive. +From there, it will be included in stable with the next point release.

Extra care should be taken when uploading to stable. Basically, a package should only be uploaded to stable if one of the following happens: @@ -1772,7 +1855,7 @@ packages (by messing with Provides or shlibs files), possibly making those other packages uninstallable, is strongly discouraged.

The Release Team (which can be reached at &email-debian-release;) will -regularly evaluate the uploads in stable-proposed-updates and decide if +regularly evaluate the uploads To stable-proposed-updates and decide if 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 @@ -1813,7 +1896,7 @@ and the Debian package . Uploading to non-US

-Note: non-us was discontinued with release of sarge. +Note: non-us was discontinued with the release of sarge. Delayed uploads @@ -1821,7 +1904,7 @@ and the Debian package . 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. +0-day is uploaded multiple times per day to ftp-master.

With a fairly recent dput, this section @@ -1838,7 +1921,8 @@ prescription found in applies here as well. Security uploads

-Do NOT upload a package to the security upload queue (oldstable-security, +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. @@ -1850,7 +1934,7 @@ The scp queues on ftp-master, and security are mostly unusable due to the login restrictions on those hosts.

The anonymous queues on ftp.uni-erlangen.de and ftp.uk.debian.org are -currently down. Work is underway to resurrect those. +currently down. Work is underway to resurrect them.

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 @@ -1905,7 +1989,7 @@ for your next upload, or else you may wish to make a change in the override file.

To alter the actual section that a package is put in, you need to -first make sure that the debian/control in your package +first make sure that the debian/control file in your package is accurate. Next, send an email &email-override; or submit a bug against ftp.debian.org requesting that the section or priority for your package be changed from the old section or @@ -1937,7 +2021,7 @@ and tags, marking bugs as forwarded, and other issues. 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 in this server are described in the +All of the commands available on this server are described in the . Monitoring bugs @@ -1975,7 +2059,7 @@ contact the submitter and to record your mail within the bug log (that means you don't need to send a copy of the mail to 123@&bugs-host;).

-If you get a bug which mentions "FTBFS", that means "Fails to build +If you get a bug which mentions "FTBFS", this means "Fails to build from source". Porters frequently use this acronym.

Once you've dealt with a bug report (e.g. fixed it), mark it as @@ -2055,7 +2139,7 @@ details on the technicalities of the merge command and its relative, the unmerge command, see the BTS control server documentation. 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 +case you have to ask them for 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 @@ -2069,8 +2153,9 @@ 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 that you send at the -same time to the author. Make sure to send the patch to the BTS and to +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 patch. If you have fixed a bug in your local copy, or if a fix has been @@ -2087,12 +2172,13 @@ read . When bugs are closed by new uploads

-As bugs and problems are fixed your packages, it is your -responsibility as the package maintainer to close the bug. However, -you should not close the bug until the package which fixes the bug has +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.

However, it's possible to avoid having to manually close bugs after the upload — just list the fixed bugs in your debian/changelog @@ -2117,25 +2203,30 @@ how bug closing changelogs are identified: We prefer the closes: #XXX syntax, as it is the most concise entry and the easiest to integrate with the text of the changelog. -

-If an upload is identified as Non-maintainer upload (NMU) -(and that is the case if the name of the person who commits this change -is not exactly the same as any one of Maintainer or Uploader, -except if the maintainer is the qa group), -than the bug is only tagged fixed instead of being closed. -If a maintainer upload is targetted to experimental, -than the tag fixed-in-experimental is added to the bug; -for NMUs, the tag fixed is used. -(The special rule for experimental is expected to change -as soon as version-tracking is added to the bug tracking system.) +Unless specified different by the -v-switch to +dpkg-buildpackage, only the bugs closed in the +most recent changelog entry are closed (basically, exactly +the bugs mentioned in the changelog-part +in the .changes file are closed). +

+Historically, uploads identified as +Non-maintainer upload (NMU) +were tagged fixed instead of being closed, +but that practice was ceased with the advent of version-tracking. +The same applied to the tag fixed-in-experimental.

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 an reopen XXX command to +wrongly closed bugs, send a reopen XXX 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 .changes file to XXX-done@&bugs-host;, -where XXX is your bug number. +where XXX is the bug number, and +put "Version: YYY" and an empty line as the first two lines +of the body of the email, +where YYY is the first version +where the bug has been fixed. +

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 @@ -2154,7 +2245,7 @@ For general information on how to write your changelog entries, see 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 fix them themselves, sending +maintainers with security problems or fixing them themselves, sending security advisories, and maintaining security.debian.org. @@ -2170,7 +2261,7 @@ 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 + 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. @@ -2199,7 +2290,7 @@ case depends on the nature of the problem and corresponding fix, and whether it is already a matter of public knowledge.

-There are a few ways developers can learn of a security problem: +There are several ways developers can learn of a security problem: they notice it on a public forum (mailing list, web site, etc.) @@ -2219,7 +2310,7 @@ There are a few ways developers can learn of a security problem: If the problem is severe, it is preferable to share the information with other vendors and coordinate a release. The security team keeps - contacts with the various organizations and individuals and can take + in contact with the various organizations and individuals and can take care of that. @@ -2402,7 +2493,7 @@ 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 -ftp://security.debian.org/pub/SecurityUploadQueue/ . +ftp://security-master.debian.org/pub/SecurityUploadQueue/ .

Once an upload to the security queue has been accepted, the package @@ -2416,9 +2507,8 @@ be fixes for security problems that cannot be disclosed yet.

If a member of the security team accepts a package, it will be -installed on security.debian.org as well as the proper -distribution-proposed-updates on ftp-master or in the non-US -archive. +installed on security.debian.org as well as proposed for the proper +distribution-proposed-updates on ftp-master. Moving, removing, renaming, adopting, and orphaning @@ -2426,7 +2516,7 @@ archive.

Some archive manipulation operations are not automated in the Debian upload process. These procedures should be manually followed by -maintainers. This chapter gives guidelines in what to do in these +maintainers. This chapter gives guidelines on what to do in these cases. Moving packages @@ -2442,7 +2532,11 @@ belongs in. 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 for details). If your new section is +name="Debian Policy Manual"> for details). +You must ensure that you include the .orig.tar.gz 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.

@@ -2458,14 +2552,27 @@ override file updated, as described in . 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 ftp.debian.org asking that the -package be removed. Make sure you indicate which distribution 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 unstable and experimental. Packages are not removed from testing directly. Rather, they will be removed automatically after the package has been removed from unstable and no package in testing depends on it.

-You also have to detail the reasons justifying that request. This is to +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. +

+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. @@ -2480,13 +2587,17 @@ 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. +Other useful programs include +apt-cache rdepends, +apt-rdepends and +grep-dctrl. 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 the actual code has evolved into another package (e.g. libfoo12 was removed because libfoo13 supersedes it) or closed if the -software is simply no more part of Debian. +software is simply no longer part of Debian. Removing packages from Incoming

@@ -2524,8 +2635,8 @@ mirror network. Orphaning a package

-If you can no longer maintain a package, you need to inform the others -about that, and see that the package is marked as orphaned. +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 Debian QA Group &orphan-address; and submit a bug report against the pseudo package wnpp. The bug report should be @@ -2548,7 +2659,7 @@ More information is on the . Adopting a package

-A list of packages in need of a new maintainer is available at in the +A list of packages in need of a new maintainer is available in the . If you wish to take over maintenance of any of the packages listed in the WNPP, please take a look at the aforementioned @@ -2725,12 +2836,22 @@ 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).

-The ``magic'' for a recompilation-only NMU is triggered by using the -third-level number on the Debian part of the version. 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.0.1''. If the -latest version was ``3.4-2.1'', your NMU should have a version number -of ``3.4-2.1.1''. +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''. + + +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.

Similar to initial porter uploads, the correct way of invoking dpkg-buildpackage is dpkg-buildpackage -B to only @@ -2785,7 +2906,7 @@ blessing or status, so buyer beware. Porting infrastructure and automation

-There is infrastructure and several tools to help automate the package +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.

@@ -2842,14 +2963,14 @@ general interest (for instance, a flavor of Debian built with gcc bounds checking). It will also enable Debian to recompile entire distributions quickly.

-The buildds admins of each arch can be contacted by the mail address +The buildds admins of each arch can be contacted at the mail address $arch@buildd.debian.org. When your package is not portable

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 with a reasonable amount of time. An example is a package that +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.

@@ -2879,7 +3000,7 @@ In order to prevent autobuilders from needlessly trying to build your package, it must be included in packages-arch-specific, a list used by the wanna-build script. The current version is available as -; +; please see the top of the file for whom to contact for changes.

@@ -2889,7 +3010,7 @@ 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 there removal by filing a bug against +request their removal by filing a bug against ftp.debian.org @@ -2907,7 +3028,7 @@ that too is strictly speaking a binary NMU. See for some more information.

The main reason why NMUs are done is when a -developer needs to fix another developer's packages in order to +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. @@ -2921,9 +3042,10 @@ Debian maintainer, talk to the upstream maintainer, or submit a bug. However, aesthetic changes must not be made in a non-maintainer upload.

-And please remember the Hippocratic Oath: "Above all, do no harm." -It is better if a package has an grave bug open, than if a not working -patch was applied, and the bug is only hidden now but not resolved. +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. How to do a NMU @@ -2932,7 +3054,7 @@ 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 present. +solution.

NMUs should be made to assist a package's maintainer in resolving bugs. Maintainers should be thankful for that help, and NMUers should respect @@ -2983,7 +3105,7 @@ managers. Please take additional care, and acknowledge that the usual way for a package to enter testing is through unstable.

For the stable distribution, please take extra care. Of course, the release -managers may also change the rules here. Please verify before upload that +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.

@@ -3036,11 +3158,11 @@ If you upload a package to testing or stable, sometimes, you need to Source NMUs must have a new changelog entry

-A non-maintainer doing a source NMU must create a changelog entry, +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 -non-maintainer's email address in the log entry and the NMU version -number in it. +email address of the person who uploaded it in the log entry +and the NMU version number in it.

By convention, source NMU changelog entries start with the line @@ -3062,24 +3184,14 @@ 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.

-If the source NMU (non-maintainer upload) fixes some existing bugs, -these bugs should be tagged fixed in the Bug Tracking -System rather than closed. By convention, only the official package -maintainer or the original bug submitter close bugs. -Fortunately, Debian's archive system recognizes NMUs and thus marks -the bugs fixed in the NMU appropriately if the person doing the NMU -has listed all bugs in the changelog with the Closes: -bug#nnnnn syntax (see for -more information describing how to close bugs via the changelog). -Tagging the bugs fixed ensures that everyone knows that the -bug was fixed in an NMU; however the bug is left open until the -changes in the NMU are incorporated officially into the package by -the official package maintainer. +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.

Also, after doing an NMU, you have to send -that information to the existing bugs that are fixed by your NMU, +the information to the existing bugs that are fixed by your NMU, including the unified diff. -Alternatively you can open a new bug and include a +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 @@ -3089,14 +3201,17 @@ new version, the maintainer needs to ensure that the new upstream version really fixes each problem that was fixed in the non-maintainer release.

In addition, the normal maintainer should always retain the -entry in the changelog file documenting the non-maintainer upload. +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. Building source NMUs

Source NMU packages are built normally. Pick a distribution using the same rules as found in , follow the other -prescriptions in . +instructions in .

Make sure you do not change the value of the maintainer in the debian/control file. Your name as given in the NMU entry of @@ -3118,7 +3233,7 @@ entry of your next upload.

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 +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 @@ -3131,31 +3246,18 @@ 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 . If you perform an NMU on an improperly orphaned package, please set the maintainer to ``Debian QA Group -<packages@qa.debian.org>''. Also, the bugs are closed in that case, -and not only marked fixed. +<packages@qa.debian.org>''. Who can do an NMU

-Only official, registered Debian maintainers can do binary or source -NMUs. An official maintainer is someone who has their key in the +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. - How dak detects NMUs -

-Whether an upload is treated as an NMU or as a maintainer upload by -the archive scripts and the bugtracking system (see ) is not decided by looking at the version -number (see ). Instead, an upload is handled as -an NMU if the maintainer address in the .changes file is not -binary the same as the address in the Maintainer field, or -any of the addresses the Uploaders field, of the dsc -file, and also if the maintainer address is not special (i.e. it is -not set to the QA Group address). - Terminology

There are two new terms used throughout this section: ``binary-only NMU'' @@ -3182,7 +3284,7 @@ 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.

-Both classes of NMUs, source and binary-only, can be lumped by the +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 @@ -3195,7 +3297,7 @@ NMUs. "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 time. It is strongly recommended that +faster bug fix turnaround times. It is strongly recommended that packages with a priority of Standard or which are part of the base set have co-maintainers.

@@ -3212,7 +3314,8 @@ quite easy: 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 CVS or -Subversion.

+Subversion. Alioth (see ) provides such +tools, amongst others.

@@ -3230,9 +3333,32 @@ Using the PTS (), the co-maintainers should subscribe themselves to the appropriate source package.

-

-Collaborative maintenance can often be further eased with the use of -tools on Alioth (see ). +

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

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

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

+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 ) with packages one doesn't really care for, and +creates a false sense of good maintenance. @@ -3272,7 +3398,7 @@ 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; -It must have fewer release-critical bugs than the version currently available +It must have the same number or fewer release-critical bugs than the version currently available in testing; It must be available on all architectures on which it has previously @@ -3284,7 +3410,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 fulfill all the necessary criteria); +be if they fulfill all the necessary criteria);

To find out whether a package is progressing into testing or not, see the @@ -3355,11 +3481,16 @@ if you maintain glibc or so.)

Sometimes, a package is removed to allow another package in: This happens only to allow another package to go in if it's ready in every other -sense. Suppose e.g. that a conflicts with the new version of +sense. Suppose e.g. that a cannot be installed with the new version of b; then a may be removed to allow b in.

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

+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. + circular dependencies @@ -3408,15 +3539,16 @@ If you are interested in details, this is how britney works: 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, the release managers have hammers -of any size to force britney to consider a package. (Also, the base +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.)

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 unstable is not +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.) @@ -3540,9 +3672,11 @@ it's usually the file maintainers spend the most time on. Helper scripts

The rationale for using helper scripts in debian/rules is -that lets maintainers use and share common logic among many packages. +that they let maintainers use and share common logic among many packages. Take for instance the question of installing menu entries: you need to -put the file into /usr/lib/menu, and add commands to the +put the file into /usr/lib/menu (or +/usr/lib/menu for executable binary menufiles, if this is needed), +and add commands to the maintainer scripts to register and unregister the menu entries. Since this is a very common thing for packages to do, why should each maintainer rewrite all this on their own, sometimes with bugs? Also, @@ -3611,7 +3745,7 @@ of the above, and provides a facility for creating new and updating old patches. See the package dbs for more information and hello-dbs for an example.

-dpatch also provides these facilities, but it's intented to be +dpatch also provides these facilities, but it's intended to be even easier to use. See the package dpatch for documentation and examples (in /usr/share/doc/dpatch). @@ -3621,7 +3755,7 @@ documentation and examples (in /usr/share/doc/dpatch). A single source package will often build several binary packages, either to provide several flavors of the same software (e.g., the vim source package) or to make several small -packages instead of a big one (e.g., if the user can install only the +packages instead of a big one (e.g., so the user can install only the subset needed, and thus save some disk space).

The second case can be easily managed in debian/rules. @@ -3754,10 +3888,11 @@ package related to other packages in some way that is not handled by the package manager (e.g., "this is the client for the foo server")?

Be careful to avoid spelling and grammar mistakes. Ensure that you -spell-check it. ispell has a special -g option -for debian/control files: +spell-check it. Both ispell and aspell +have special modes for checking debian/control files: ispell -d american -g debian/control +aspell -d en -D -c debian/control

Users usually expect these questions to be answered in the package description: @@ -3812,7 +3947,63 @@ Note that we expect this field will eventually be replaced by a proper debian/control field understood by dpkg and &packages-host;. If you don't want to bother migrating the home page from the description to this field, you should probably wait -until that is available.

+until that is available. + Please make sure that this line matches the regular expression + /^ Homepage: [^ ]*$/, + as this allows packages.debian.org to parse it correctly.

+ + + + Version Control System location +

+There are additional fields for the location of the Version Control System +in debian/control. + XS-Vcs-Browser +

+Value of this field should be a http:// URL pointing to a +web-browsable copy of the Version Control System repository used to +maintain the given package, if available. +

+The information is meant to be useful for the final user, willing to +browse the latest work done on the package (e.g. when looking for the +patch fixing a bug tagged as pending in the bug tracking +system). + XS-Vcs-* +

+Value of this field should be a string identifying unequivocally the +location of the Version Control System repository used to maintain the +given package, if available. * identify the Version Control +System; currently the following systems are supported by the package +tracking system: arch, bzr (Bazaar), cvs, +darcs, git, hg (Mercurial), mtn +(Monotone), svn (Subversion). It is allowed to specify different +VCS fields for the same package: they will all be shown in the PTS web +interface. +

+The information is meant to be useful for a user knowledgeable in the +given Version Control System and willing to build the current version of +a package from the VCS sources. Other uses of this information might +include automatic building of the latest VCS version of the given +package. To this end the location pointed to by the field should better +be version agnostic and point to the main branch (for VCSs supporting +such a concept). Also, the location pointed to should be accessible to +the final user; fulfilling this requirement might imply pointing to an +anonymous access of the repository instead of pointing to an +SSH-accessible version of the same. +

+In the following example, an instance of the field for a Subversion +repository of the vim package is shown. Note how the +URL is in the svn:// scheme (instead of svn+ssh://) and +how it points to the trunk/ branch. The use of the +XS-Vcs-Browser field described above is also shown. + + Source: vim + Section: editors + Priority: optional + <snip> + XS-Vcs-Svn: svn://svn.debian.org/svn/pkg-vim/trunk/packages/vim + XS-Vcs-Browser: http://svn.debian.org/wsvn/pkg-vim/trunk/packages/vim + @@ -3883,21 +4074,16 @@ id="bug-answering"> for more information on how to use the bug tracking system.

It is an old tradition to acknowledge bugs fixed in non-maintainer -uploads in the first changelog entry of the proper maintainer upload, -for instance, in a changelog entry like this: - - * Maintainer upload, closes: #42345, #44484, #42444. - -This will close the NMU bugs tagged "fixed" when the package makes -it into the archive. The bug for the fact that an NMU was done can be -closed the same way. Of course, it's also perfectly acceptable to -close NMU-fixed bugs by other means; see . +uploads in the first changelog entry of the proper maintainer upload. +As we have version tracking now, +it is enough to keep the NMUed changelog entries and +just mention this fact in your own changelog entry. Common errors in changelog entries

-The following examples demonstrate some common errors or example of +The following examples demonstrate some common errors or examples of bad style in changelog entries.

@@ -4079,8 +4265,8 @@ Also, we document some best practices here.

These guidelines include some writing style and typography recommendations, general considerations about debconf usage as well as -more specific recommendations for some parts of the distribution (for -instance, the installation system). +more specific recommendations for some parts of the distribution (the +installation system for instance). Do not abuse debconf

@@ -4129,7 +4315,7 @@ good start). Avoid changing templates too often. Changing templates text induces more work to translators which will get their translation "fuzzied". If you plan changes to your original templates, please contact -translators. Most active translators are very reactive and getting +translators. Most active translators are very responsive and getting their work included along with your modified templates will save you additional uploads. If you use gettext-based templates, the translator's name and e-mail addresses are mentioned in the po files @@ -4207,15 +4393,18 @@ Just give facts. You should avoid the use of first person ("I will do this..." or "We recommend..."). The computer is not a person and the Debconf templates do not speak for the Debian developers. You should use neutral -construction and often the passive form. Those of you who already +construction. Those of you who already wrote scientific publications, just write your templates like you would write a scientific paper. +However, try using action voice if still possible, like +"Enable this if ..." +instead of +"This can be enabled if ...". Be gender neutral

The world is made of men and women. Please use gender-neutral -constructions in your writing. This is not Political Correctness, this -is showing respect to all humanity. +constructions in your writing. Templates fields definition @@ -4239,7 +4428,7 @@ soon as is possible. boolean:

-A true/false choice. Remember: true/false, NOT YES/NO... +A true/false choice. Remember: true/false, not yes/no... select:

@@ -4268,22 +4457,18 @@ This type is now considered obsolete: don't use it. error:

-THIS TEMPLATE TYPE IS NOT HANDLED BY DEBCONF YET. -

-It has been added to cdebconf, the C version of debconf, first used in -the Debian Installer. -

-Please do not use it unless debconf supports it. -

-This type is designed to handle error message. It is mostly similar to +This type is designed to handle error messages. It is mostly similar to the "note" type. Frontends may present it differently (for instance, the dialog frontend of cdebconf draws a red screen instead of the usual blue one). +

+It is recommended to use this type for any message that needs user +attention for a correction of any kind. Description: short and extended description

-Templates descriptions have two parts: short and extended. The short +Template descriptions have two parts: short and extended. The short description is in the "Description:" line of the template.

The short description should be kept short (50 characters or so) so @@ -4310,9 +4495,12 @@ The extended description should use complete sentences. Paragraphs should be kept short for improved readability. Do not mix two ideas in the same paragraph but rather use another paragraph.

-Don't be too verbose. Some debconf interfaces cannot deal very well -with descriptions of more than about 20 lines, so try to keep it below -this limit. +Don't be too verbose. User tend to ignore too long screens. +20 lines are by experience a border you shouldn't cross, +because that means that in the classical dialog interface, +people will need to scroll, and lot of people just don't do that. +

+The extended description should never include a question.

For specific rules depending on templates type (string, boolean, etc.), please read below. @@ -4346,7 +4534,7 @@ Below are specific instructions for properly writing the Description String/password templates

- The short description is a prompt and NOT a title. Avoid + The short description is a prompt and not a title. Avoid question style prompts ("IP Address?") in favour of "opened" prompts ("IP address:"). The use of colons is recommended. @@ -4366,8 +4554,6 @@ Below are specific instructions for properly writing the Description question is rather long (remember that translations are often longer than original versions) - The extended description should NOT include a question. - Again, please avoid referring to specific interface widgets. A common mistake for such templates is "if you answer Yes"-type constructions. @@ -4376,7 +4562,8 @@ Below are specific instructions for properly writing the Description Select/Multiselect

- The short description is a prompt and NOT a title. Do NOT use useless + The short description is a prompt and not a title. + Do not use useless "Please choose..." constructions. Users are clever enough to figure out they have to choose something...:) @@ -4395,7 +4582,8 @@ Below are specific instructions for properly writing the Description The extended description is what will be displayed as a more detailed explanation of the note. Phrases, no terse writing style. - DO NOT ABUSE DEBCONF. Notes are the most common way to abuse + Do not abuse debconf. + Notes are the most common way to abuse debconf. As written in debconf-devel manual page: it's best to use them only for warning about very serious problems. The NEWS.Debian or README.Debian files are the appropriate location for a lot of notes. @@ -4448,7 +4636,7 @@ confusing: the translators may put their own choice Do NOT use empty default field. If you don't want to use default values, do not use Default at all.

-If you use po-debconf (and you SHOULD, see 2.2), consider making this +If you use po-debconf (and you should, see 2.2), consider making this field translatable, if you think it may be translated.

If the default value may vary depending on language/country (for @@ -4566,7 +4754,7 @@ should retrieve the source package.

Policy specifies that documentation should be shipped in HTML format. We also recommend shipping documentation in PDF and plain text format if -convenient and quality output is possible. However, it is generally +convenient and if output of reasonable quality is possible. However, it is generally not appropriate to ship plain text versions of documentation whose source format is HTML.

@@ -4697,7 +4885,7 @@ to your short description. If you are looking for examples, just run: There are two kinds of original source tarballs: Pristine source and repackaged upstream source.

- + Pristine source

The defining characteristic of a pristine source tarball is that the @@ -4705,7 +4893,7 @@ The defining characteristic of a pristine source tarball is that the distributed by the upstream author. We cannot prevent upstream authors from changing the tarball -they distribute without also upping the version number, so +they distribute without also incrementing the version number, so there can be no guarantee that a pristine tarball is identical to what upstream currently distributing at any point in time. All that can be expected is that it is identical to @@ -4736,7 +4924,8 @@ the following: It unpacks the tarball in an empty temporary directory by doing -zcat path/to/<packagename>_<upstream-version>.orig.tar.gz | tar xf - + +zcat path/to/<packagename>_<upstream-version>.orig.tar.gz | tar xf - + If, after this, the temporary directory contains nothing but one @@ -4756,7 +4945,7 @@ case, dpkg-source renames the temporary directory

- + Repackaged upstream source

You should upload packages with a pristine source @@ -4836,7 +5025,8 @@ point). should use <packagename>-<upstream-version>.orig as the name of the top-level directory in its tarball. This makes it possible to -distinguish pristine tarballs from repackaged ones. + +distinguish pristine tarballs from repackaged ones. + should be gzipped with maximal compression. @@ -4864,6 +5054,17 @@ form The file should have a name that makes it clear which binary file it encodes. Usually, some postfix indicating the encoding should be appended to the original filename. +Note that you don't need to depend on sharutils to get +the uudecode program if you use perl's +pack function. +The code could look like + +uuencode-file: + perl -ne 'print(pack "u", $$_);' $(file) > $(file).uuencoded + +uudecode-file: + perl -ne 'print(unpack "u", $$_);' $(file).uuencoded > $(file) + . The file would then be decoded and copied to its place during the build process. Thus the change will be visible quite easy. @@ -4880,6 +5081,56 @@ build process.

+ + Best practices for debug packages +

+A debug package is a package with a name ending in "-dbg", that contains +additional information that gdb can use. Since Debian binaries are +stripped by default, debugging information, including function names and +line numbers, is otherwise not available when running gdb on Debian binaries. +Debug packages allow users who need this additional debugging information to +install it, without bloating a regular system with the information. +

+It is up to a package's maintainer whether to create a debug package or +not. Maintainers are encouraged to create debug packages for library +packages, since this can aid in debugging many programs linked to a +library. In general, debug packages do not need to be added for all +programs; doing so would bloat the archive. But if a maintainer finds +that users often need a debugging version of a program, it can be +worthwhile to make a debug package for it. Programs that are core +infrastructure, such as apache and the X server are also good candidates +for debug packages. +

+Some debug packages may contain an entire special debugging build of a +library or other binary, but most of them can save space and build time +by instead containing separated debugging symbols that gdb can find and +load on the fly when debugging a program or library. The convention in +Debian is to keep these symbols in /usr/lib/debug/path, +where path is the path to the executable or library. For example, +debugging symbols for /usr/bin/foo go in +/usr/lib/debug/usr/bin/foo, and +debugging symbols for /usr/lib/libfoo.so.1 go in +/usr/lib/debug/usr/lib/libfoo.so.1. +

+The debugging symbols can be extracted from an object file using +"objcopy --only-keep-debug". Then the object file can be stripped, and +"objcopy --add-gnu-debuglink" used to specify the path to the debugging +symbol file. explains in detail how this +works. +

+The dh_strip command in debhelper supports creating debug packages, and +can take care of using objcopy to separate out the debugging symbols for +you. If your package uses debhelper, all you need to do is call +"dh_strip --dbg-package=libfoo-dbg", and add an entry to debian/control +for the debug package. +

+Note that the Debian package should depend on the package that it +provides debugging symbols for, and this dependency should be versioned. +For example: + + +Depends: libfoo-dbg (= ${binary:Version}) + @@ -4959,6 +5210,12 @@ developers to verify that the bug is a real problem. In addition, it will help prevent a situation in which several maintainers start filing the same bug report simultaneously.

+Please use the programms dd-list and +if appropriate whodepends +(from the package devscripts) +to generate a list of all affected packages, and include the +output in your mail to &email-debian-devel;. +

Note that when sending lots of bugs on the same subject, you should send the bug report to maintonly@&bugs-host; so that the bug report is not forwarded to the bug distribution mailing @@ -5026,7 +5283,7 @@ a source or a binary package.

You may also be interested in contacting the persons who are subscribed to a given source package via . -You can do so by using the <package-name>@&pts-host; +You can do so by using the <package>@&pts-host; email address. @@ -5039,20 +5296,20 @@ haven't registered out of the system, so to speak. On the other hand, it is also possible that they just need a reminder.

There is a simple system (the MIA database) in which information about -maintainers who are deemed Missing In Action are recorded. When a member of the +maintainers who are deemed Missing In Action is recorded. +When a member of the QA group contacts an inactive maintainer or finds more information about one, this is recorded in the MIA database. This system is available in /org/qa.debian.org/mia on the host qa.debian.org, and can be queried -with a tool known as mia-history. By default, -mia-history shows information about every person it knows -about, but it accepts regular expressions as arguments which it uses to -match user names. mia-history --help shows which -arguments are accepted. If you find that no information has been recorded -about an inactive maintainer already, or that you can add more information, +with a tool known as mia-query. +Use mia-query --help to see how to query the database. +If you find that no information has been recorded +about an inactive maintainer yet, or that you can add more information, you should generally proceed as follows.

-The first step is to politely contact the maintainer, and wait for a -response for a reasonable time. It is quite hard to define "reasonable +The first step is to politely contact the maintainer, +and wait a reasonable time for a response. +It is quite hard to define "reasonable time", but it is important to take into account that real life is sometimes very hectic. One way to handle this would be to send a reminder after two weeks. @@ -5065,7 +5322,7 @@ about the maintainer in question as possible. This includes: The "echelon" information available through the , - which indicates when the developer last has posted to + which indicates when the developer last posted to a Debian mailing list. (This includes uploads via debian-*-changes lists.) Also, remember to check whether the maintainer is marked as "on vacation" in the database. @@ -5082,34 +5339,39 @@ about the maintainer in question as possible. This includes: non-Debian mailing lists or news groups.

-One big problem are packages which were sponsored — the maintainer is not +A bit of a problem are packages which were sponsored — the maintainer is not an official Debian developer. The echelon information is not available for sponsored people, for example, so you need to find and contact the Debian developer who has actually uploaded the package. Given that they signed the -package, they're responsible for the upload anyhow, and should know what +package, they're responsible for the upload anyhow, and are likely to know what happened to the person they sponsored.

It is also allowed to post a query to &email-debian-devel;, asking if anyone is aware of the whereabouts of the missing maintainer. +Please Cc: the person in question.

-Once you have gathered all of this, you can contact &email-debian-qa;. -People on this alias will use the information you provided in order to +Once you have gathered all of this, you can contact &email-mia;. +People on this alias will use the information you provide in order to decide how to proceed. For example, they might orphan one or all of the -packages of the maintainer. If a packages has been NMUed, they might prefer +packages of the maintainer. If a package has been NMUed, they might prefer to contact the NMUer before orphaning the package — perhaps the person who has done the NMU is interested in the package.

One last word: please remember to be polite. We are all volunteers and cannot dedicate all of our time to Debian. Also, you are not aware of the circumstances of the person who is involved. Perhaps they might be -seriously ill or might even had died — you do not know who may be on the +seriously ill or might even have died — you do not know who may be on the receiving side. Imagine how a relative will feel if they read the e-mail -of the deceased and find a very impolite, angry and accusing message!) +of the deceased and find a very impolite, angry and accusing message!

On the other hand, although we are volunteers, we do have a responsibility. So you can stress the importance of the greater good — if a maintainer does not have the time or interest anymore, they should "let go" and give the package to someone with more time. +

+If you are interested in working in the MIA team, please have a look at the +README file in /org/qa.debian.org/mia on qa.debian.org where the technical +details and the MIA procedures are documented and contact &email-mia;. @@ -5260,7 +5522,7 @@ For web pages, each l10n team has access to the relevant CVS, and the statistics are available from the Central Debian translation statistics site.

For general documentation about Debian, the process is more or less the same -than for the web pages (the translators have access to the CVS), but there are +as for the web pages (the translators have access to the CVS), but there are no statistics pages.

For package-specific documentation (man pages, info documents, other formats), @@ -5349,7 +5611,7 @@ list) before providing it for inclusion. It will save time for everyone, and avoid the chaos resulting in having several versions of the same document in bug reports.

-The best solution is to fill a regular bug containing the translation against +The best solution is to file a regular bug containing the translation against the package. Make sure to use the 'PATCH' tag, and to not use a severity higher than 'wishlist', since the lack of translation never prevented a program from running. @@ -5359,9 +5621,9 @@ running. As a maintainer, never edit the translations in any way (even to reformat the -layout) without asking to the corresponding l10n mailing list. You risk for -example to break the encoding of the file by doing so. Moreover, what you -consider as an error can be right (or even needed) in the given language. +layout) without asking on the corresponding l10n mailing list. You risk for +example breaksing the encoding of the file by doing so. Moreover, what you +consider an error can be right (or even needed) in the given language. As a translator, if you find an error in the original text, make sure to report it. Translators are often the most attentive readers of a given text, and if @@ -5548,8 +5810,9 @@ sort of automated functions that one finds in debhelper.

The consensus is that debmake is now deprecated in -favor of debhelper. However, it's not a bug to use -debmake. +favor of debhelper. It is a bug to use +debmake in new packages. New packages using +debmake will be rejected from the archive.