X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=developers-reference.git;a=blobdiff_plain;f=developers-reference.sgml;h=5c6cffc31cb2f086db4632a90e1be89c01bc4633;hp=0745cc39a1b82cbd58d18d7e16fff50165de83f9;hb=e37ddcf129d5aa099f43eda53a9ad65f0e13848d;hpb=324a7fa44e4fbe00fff2164bbd8c8ac740e7f8c4 diff --git a/developers-reference.sgml b/developers-reference.sgml index 0745cc3..5c6cffc 100644 --- a/developers-reference.sgml +++ b/developers-reference.sgml @@ -4,9 +4,10 @@ %versiondata; %commondata; + %dynamicdata; - + @@ -30,7 +31,7 @@ -copyright © 2004 Andreas Barth +copyright © 2004—2007 Andreas Barth copyright © 1998—2003 Adam Di Carlo @@ -53,6 +54,13 @@ the &debian-formal; distribution or on the World Wide Web at . You can also obtain it by writing to the &fsf-addr;. + +If you want to print this reference, you should use the . +This page is also available in . +]]> + Scope of This Document @@ -87,7 +95,7 @@ id="&url-debian-policy;" name="Debian Policy Manual">.

Furthermore, this document is not an expression of formal policy. It contains documentation for the Debian system and -generally agreed-upon best practices. Thus, it is what is called a +generally agreed-upon best practices. Thus, it is not what is called a ``normative'' document. @@ -116,14 +124,14 @@ to work on something to avoid duplicated effort.

Another good list to subscribe to is &email-debian-mentors;. See for details. The IRC channel #debian can also be -helpful. +helpful; see .

When you know how you want to contribute to &debian-formal;, you should get in contact with existing Debian maintainers who are working on similar tasks. That way, you can learn from experienced developers. For example, if you are interested in packaging existing software for -Debian you should try to get a sponsor. A sponsor will work together +Debian, you should try to get a sponsor. A sponsor will work together with you on your package and upload it to the Debian archive once they are happy with the packaging work you have done. You can find a sponsor by mailing the &email-debian-mentors; mailing list, describing your @@ -135,13 +143,44 @@ you can subscribe to port specific mailing lists and ask there how to 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 +

+The mailing list &email-debian-mentors; has been set up for novice +maintainers who seek help with initial packaging and other +developer-related issues. Every new developer is invited to subscribe +to that list (see for details). +

+Those who prefer one-on-one help (e.g., via private email) should also +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 Developers, and who are willing to +criticize and upload your packages for you. + +Please read the +unofficial debian-mentors FAQ at first. +

+If you wish to be a mentor and/or sponsor, more information is +available in . Registering as a Debian developer

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. @@ -156,15 +195,17 @@ 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 -very important places we have to be careful about being compromised. +&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.

Before you actually register you should have shown that you can do -competent work and will be a good contributor. You can show this by -submitting patches through the Bug Tracking System or having a package -sponsored by an existing maintainer for a while. Also, we expect that +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 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! @@ -172,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 you cannot find a Debian maintainer -close to you, there's an alternative way to pass the ID check. You -can send in a photo ID signed with your GnuPG key. Having your GnuPG -key signed is the preferred way, however. See the - for more -information about these two options.) +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 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 @@ -197,16 +238,43 @@ You can use some other implementation of OpenPGP as well. Note that OpenPGP is an open standard based on .

-The recommended public key algorithm for use in Debian development -work is DSA (sometimes call ``DSS'' or ``DH/ElGamal''). Other key -types may be used however. Your key length must be at least 1024 +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 at least your own user -ID; this prevents user ID tampering. gpg does this -automatically. -

-If your public key isn't on public key servers such as &pgp-keyserv;, -please read the documentation available locally in &file-keyservs;. +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 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. @@ -215,13 +283,12 @@ Some countries restrict the use of cryptographic software by their citizens. This need not impede one's activities as a Debian package maintainer however, as it may be perfectly legal to use cryptographic products for authentication, rather than encryption purposes. -&debian-formal; does not require the use of cryptography qua -cryptography in any manner. If you live in a country where use of +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 @@ -244,28 +311,6 @@ before actually applying. If you are well prepared, you can save a lot of time later on. - Debian mentors and sponsors -

-The mailing list &email-debian-mentors; has been set up for novice -maintainers who seek help with initial packaging and other -developer-related issues. Every new developer is invited to subscribe -to that list (see for details). -

-Those who prefer one-on-one help (e.g., via private email) should also -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 -criticize and upload your packages for you. Those who are seeking a -sponsor can request one at . Please read the -inofficial debian-mentors FAQ at first. -

-If you wish to be a mentor and/or sponsor, more information is -available in . - - Debian Developer's Duties Maintaining your Debian information @@ -289,11 +334,25 @@ public servers or multiuser machines, such as the Debian servers Read the documentation that comes with your software; read the .

+You need to ensure not only that your key is secure against being stolen, +but also that it is secure against being lost. Generate and make a copy +(best also in paper form) of your revocation certificate; this is needed if +your key is lost. +

If you add signatures to your public key, or add user identities, you can update the Debian key ring by sending your key to the key server at -&keyserver-host;. If you need to add a completely new key, -or remove an old key, send mail to &email-debian-keyring;. The same -key extraction routines discussed in apply. +&keyserver-host;. +

+If you need to add a completely new key or remove an old key, you need +to get the new key signed by another developer. +If the old key is compromised or invalid, you +also have to add the revocation certificate. If there is no real +reason for a new key, the Keyring Maintainers might reject the new key. +Details can be found at +. +

+The same key extraction routines discussed in +apply.

You can find a more in-depth discussion of Debian key maintenance in the documentation of the debian-keyring package. @@ -315,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. @@ -327,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. @@ -348,6 +407,13 @@ The other thing to do is to mark yourself as "on vacation" in the Debian developers' LDAP database (this information is only accessible to Debian developers). Don't forget to remove the "on vacation" flag when you come back! +

+Ideally, you should sign up at the + +when booking a holiday and check if anyone there is looking for signing. +This is especially important when people go to exotic places +where we don't have any developers yet but +where there are people who are interested in applying. Coordination with upstream developers @@ -379,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.

@@ -404,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). @@ -444,7 +512,8 @@ replying to. In general, please adhere to the usual conventions for posting messages.

Please read the -for more information. +for more information. The +are also worth reading. Core development mailing lists

@@ -501,10 +570,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 @@ -519,7 +587,7 @@ on Debian, it's not a support channel (there's #debian for that). It is however open to anyone who wants to lurk (and learn). Its topic is commonly full of interesting information for developers.

-Since #debian-devel it's an open channel, you +Since #debian-devel is an open channel, you should not speak there of issues that are discussed in &email-debian-private;. There's another channel for this purpose, it's called #debian-private and it's protected by a key. @@ -529,14 +597,14 @@ 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-boot is used to coordinate the work on the boot -floppies (i.e., the installer). #debian-doc is +#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 reading. Other channels are dedicated to an architecture or a set of packages: #debian-bsd, #debian-kde, #debian-jr, #debian-edu, -#debian-sf (SourceForge package), #debian-oo (OpenOffice +#debian-oo (OpenOffice package) ...

Some non-English developers' channels exist as well, for example @@ -544,14 +612,25 @@ 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 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: +. +The mail needs to be signed by a key in the Debian keyring. +Please see + +for more information about cloaks. Documentation

-This document contains a lot of information very useful to Debian developers, -but it can not contain everything. Most of the other interesting documents +This document contains a lot of information +which is useful to Debian developers, +but it cannot contain everything. Most of the other interesting documents are linked from . Take the time to browse all the links, you will learn many more things. @@ -563,7 +642,7 @@ critical functions in the Debian project. Most of the machines are used for porting activities, and they all have a permanent connection to the Internet.

-Most of the machines are available for individual developers to use, +Some of the machines are available for individual developers to use, as long as the developers follow the rules set forth in the .

@@ -586,8 +665,11 @@ contact information, information about who can log in, SSH keys etc.

If you have a problem with the operation of a Debian server, and you think that the system operators need to be notified of this problem, -the Debian system administrator team is reachable at -debian-admin@lists.debian.org. +you can check the list of open issues in the DSA queue of our request +tracker at (you can login with user "guest" and +password "readonly"). To report a new problem, simply send a mail to +admin@rt.debian.org and make sure to put the string +"Debian RT" somewhere in the subject.

If you have a problem with a certain service, not related to the system administration (such as packages to be removed from the archive, @@ -596,7 +678,7 @@ generally you'll report a bug against a ``pseudo-package''. See for information on how to submit bugs.

Some of the core servers are restricted, but the information from there -is mirror to another server. +is mirrored to another server. The bugs server

@@ -614,7 +696,7 @@ wasted processing time. The ftp-master server

The ftp-master.debian.org server holds the canonical copy of the Debian -archive (excluding the non-US packages). Generally, package uploads +archive. Generally, package uploads go to this server; see .

It is restricted; a mirror is available on merkel. @@ -624,20 +706,6 @@ bugs against the ftp.debian.org pseudo-package or an email to &email-ftpmaster;, but also see the procedures in . - The non-US server -

-The non-US server, non-us.debian.org, -holds the canonical copy of the non-US part of the Debian archive. -If you need to upload a package into one of the non-US sections, upload it -to this server; see . -

-Problems with the non-US package archive should generally be submitted as -bugs against the nonus.debian.org pseudo-package (notice -the lack of hyphen between "non" and "us" in the pseudo-package name -— that's for backwards compatibility). Remember to check whether or -not someone else has already reported the problem on the -. - The www-master server

The main web server is www-master.debian.org. @@ -647,7 +715,7 @@ of Debian for most newbies. If you find a problem with the Debian web server, you should generally submit a bug against the pseudo-package, www.debian.org. Remember to check whether or not someone -else has already reported the problem on the +else has already reported the problem to the . The people web server @@ -667,12 +735,12 @@ whereas on other hosts it won't.

Usually the only reason to use a different host is when you need to publish materials subject to the U.S. export restrictions, in which case you can use -one of the other servers located outside the United States, such as the -aforementioned non-us.debian.org. +one of the other servers located outside the United States.

Send mail to &email-debian-devel; if you have any questions. The CVS server +

Our CVS server is located on cvs.debian.org.

@@ -692,7 +760,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 @@ -731,7 +799,7 @@ Most of the information is not accessible to the public, naturally. For more information please read the online documentation that you can find at .

-One can also submit their SSH keys to be used for authorization on the +Developers can also submit their SSH keys to be used for authorization on the official Debian machines, and even add new *.debian.net DNS entries. Those features are documented at . @@ -810,10 +878,10 @@ commercial distribution, for example.

On the other hand, a CD-ROM vendor could easily check the individual package licenses of the packages in non-free and include as -many on the CD-ROMs as he's allowed to. (Since this varies greatly from +many on the CD-ROMs as it's allowed to. (Since this varies greatly from vendor to vendor, this job can't be done by the Debian developers.)

-Note also that the term "section" is also used to refer to categories +Note that the term "section" is also used to refer to categories which simplify the organization and browsing of available packages, e.g. admin, net, utils etc. Once upon a time, these sections (subsections, rather) existed in the form of subdirectories within @@ -823,8 +891,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.

@@ -843,7 +911,7 @@ also have ports underway to non-Linux kernels. Aside from shipped for i386 and m68k architectures. Debian 2.1 ships for the i386, m68k, alpha, and sparc architectures. Debian 2.2 added support for the -powerpc and arm architectures. Debian 3.0 adds +powerpc and arm architectures. Debian 3.0 added support of five new architectures: ia64, hppa, s390, mips and mipsel.

@@ -867,7 +935,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.

@@ -889,7 +957,7 @@ server. For instance, at the mirror site, contained in /debian, which is a common location (another is /pub/debian).

-A distribution is comprised of Debian source and binary packages, and the +A distribution comprises Debian source and binary packages, and the respective Sources and Packages index files, containing the header information from all those packages. The former are kept in the pool/ directory, while the latter are kept in the dists/ @@ -899,8 +967,8 @@ directory of the archive (for backwards compatibility). Stable, testing, and unstable

There are always distributions called stable (residing in -dists/stable), one called testing (residing in -dists/testing), and one called unstable (residing in +dists/stable), testing (residing in +dists/testing), and unstable (residing in dists/unstable). This reflects the development process of the Debian project.

@@ -908,7 +976,7 @@ Active development is done in the unstable distribution (that's why this distribution is sometimes called the development distribution). Every Debian developer can update his or her packages in this distribution at any time. Thus, the contents of this -distribution changes from day-to-day. Since no special effort is done +distribution change from day to day. Since no special effort is made to make sure everything in this distribution is working properly, it is sometimes literally unstable.

@@ -925,14 +993,17 @@ which control how packages move from unstable to testing are tightened. Packages which are too buggy are removed. No changes are allowed into testing except for bug fixes. After some time has elapsed, depending on progress, the testing distribution -goes into a `deep freeze', when no changes are made to it except those -needed for the installation system. This is called a “test cycle”, -and it can last up to two weeks. There can be several test cycles, -until the distribution is prepared for release, as decided by the -release manager. At the end of the last test cycle, the -testing distribution is renamed to stable, -overriding the old stable distribution, which is removed at -that time (although it can be found at &archive-host;). +is frozen even further. +Details of the handling of the testing distribution are published +by the Release Team on debian-devel-announce. +After the open issues are solved to the satisfaction of the Release Team, +the distribution is released. +Releasing means +that testing is renamed to stable, +and a new copy is created for the new testing, +and the previous stable is renamed to oldstable +and stays there until it is finally archived. +On archiving, the contents are moved to &archive-host;).

This development cycle is based on the assumption that the unstable distribution becomes stable after passing a @@ -948,6 +1019,9 @@ batch into the stable distribution and the revision level of the stable distribution is incremented (e.g., ‘3.0’ becomes ‘3.0r1’, ‘2.2r4’ becomes ‘2.2r5’, and so forth). +Please refer to +uploads to the stable distribution +for details.

Note that development under unstable continues during the freeze period, since the unstable distribution remains in @@ -978,8 +1052,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, @@ -1010,16 +1084,18 @@ New software which isn't likely to damage your system can go directly into An alternative to experimental is to use your personal web space on people.debian.org.

-Please consider to use the option -v to dpkg-buildpackage -if uploading a package to unstable to get the bugs finally closed that were -first fixed in experimental. +When uploading to unstable a package which had bugs fixed in experimental, +please consider using the option -v to dpkg-buildpackage +to finally get them closed. Release code names

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 @@ -1081,27 +1157,37 @@ have accounts on these machines.

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;. +directories and scripts that are installed on &ftp-master-host;.

Packages are uploaded by all the maintainers into a directory called -unchecked. This directory is scanned every 15 minutes by +UploadQueue. +This directory is scanned every few minutes by a daemon called +queued, *.command-files are executed, and +remaining and correctly signed *.changes-files are moved +together with their corresponding files to the unchecked +directory. +This directory is not visible for most Developers, as ftp-master is restricted; +it is scanned every 15 minutes by 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 -"by-hand" it is moved in the byhand directory, where it waits -for a manual installation by the ftpmasters. Otherwise, if any error has been detected, -the package is refused and is moved in the reject directory. -

-Once the package is accepted the system sends a confirmation -mail to the maintainer, closes all the bugs marked as fixed by the upload +the package (or it has new binary packages), +it is moved to the new directory, where it waits +for approval by the ftpmasters. If the package contains files to be installed +"by hand" it is moved to the byhand directory, where it waits +for manual installation by the ftpmasters. Otherwise, if any error has been detected, +the package is refused and is moved to the reject directory. +

+Once the package is accepted, the system sends a confirmation +mail to the maintainer and closes all the bugs marked as fixed by the upload, and the auto-builders may start recompiling it. The package is now publicly -accessible at (there is no -such URL for packages in the non-US archive) until it is really installed -in the Debian archive. This happens only once a day, the package +accessible at +until it is really installed +in the Debian archive. +This happens only once a day +(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 Packages and Sources index files for example) have been @@ -1116,12 +1202,16 @@ If a package is released with Distribution: set to `unstable' or `experimental', the announcement will be posted to &email-debian-devel-changes; instead.

+Though ftp-master is restricted, a copy of the installation is available +to all developers on &ftp-master-mirror;. + Package information @@ -1177,7 +1267,7 @@ Each package has several dedicated web pages. displays each version of the package 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 dependencies, and package download links.

The bug tracking system tracks bugs for each package. You can view the bugs of a given package at the URL @@ -1186,7 +1276,8 @@ You can view the bugs of a given package at the URL The madison utility

madison is a command-line utility that is available -on both &ftp-master-host; and &non-us-host;. It +on &ftp-master-host;, and on +the mirror on &ftp-master-mirror;. It uses a single argument corresponding to a package name. In result it displays which version of the package is available for each architecture and distribution combination. An example will explain @@ -1202,7 +1293,7 @@ libdbd-mysql-perl | 1.2219-1 | unstable | source, alpha, arm, hppa, i386,

In this example, you can see that the version in unstable differs from the version in testing and that there has been a binary-only NMU of the -package for the alpha architecture. Each time the package has been +package for the alpha architecture. Each version of the package has been recompiled on most of the architectures. The Package Tracking System @@ -1247,9 +1338,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. +

@@ -1271,12 +1362,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. @@ -1294,6 +1390,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 @@ -1310,6 +1411,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) @@ -1326,7 +1428,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> @@ -1339,6 +1448,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 @@ -1360,7 +1475,7 @@ X-Unsubscribe: echo 'unsubscribe dpkg' | mail pts@qa.debian.org Forwarding CVS commits in the PTS

If you use a publicly accessible CVS repository for maintaining -your Debian package you may want to forward the commit notification +your Debian package, you may want to forward the commit notification to the PTS so that the subscribers (and possible co-maintainers) can closely follow the package's evolution.

@@ -1446,7 +1561,7 @@ everything here:

Think twice before adding a news item to the PTS because you won't be able -to remove it later and you wan't be able to edit it either. The only thing +to remove it later and you won't be able to edit it either. The only thing that you can do is send a second news item that will deprecate the information contained in the previous one. @@ -1461,8 +1576,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

@@ -1477,8 +1592,23 @@ by Debian, facilitate contributions from external developers to projects started by Debian, and help projects whose goals are the promotion of Debian or its derivatives.

+All Debian developers automatically have an account on Alioth. +They can activate it by using the recover password facility. +External developers can request guest accounts on Alioth. +

For more information please visit . + Goodies for Developers +

+ LWN Subscriptions +

+Since October of 2002, HP has sponsored a subscription to LWN for all +interested Debian developers. + +Details on how to get access to this benefit are in +. + + Managing Packages

@@ -1500,7 +1630,7 @@ you must then submit a bug report () against the pseudo-package wnpp describing your plan to create a new package, including, but not limiting yourself to, a description of the package, the license of the -prospective package and the current URL where it can be downloaded +prospective package, and the current URL where it can be downloaded from.

You should set the subject of the bug to ``ITP: foo @@ -1511,10 +1641,19 @@ to wishlist. If you feel it's necessary, send a copy to of the message (no, don't use CC:, because that way the message's subject won't indicate the bug number).

-Please include a Closes: bug#nnnnn entry on the +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 on the archive -(). +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: @@ -1537,7 +1676,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

@@ -1604,6 +1745,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. @@ -1646,6 +1792,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 @@ -1669,9 +1819,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: @@ -1700,7 +1852,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 @@ -1731,19 +1883,6 @@ 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.

-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 ). Furthermore packages containing code that is -patent-restricted by the United States government can not be uploaded to -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 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 @@ -1752,51 +1891,12 @@ process of uploading packages into Debian. For removing packages, please see the README file in that ftp directory, and the Debian package . - Uploading to non-US -

-Note: non-us is currently not processed any more. -

-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 -are allowed to export some cryptographic software, subject to -notification rules by the U.S. Department of Commerce. However, this -restriction has been waived for software which is already available -outside the U.S. Therefore, any cryptographic software which belongs -in the main section of the Debian archive and does not depend -on any package outside of main (e.g., does not depend on -anything in non-US/main) can be uploaded to ftp-master -or its queues, described above. -

-Debian policy does not prevent upload to non-US by U.S. residents or -citizens, but care should be taken in doing so. It is recommended that -developers take all necessary steps to ensure that they are not -breaking current US law by doing an upload to non-US, including -consulting a lawyer. -

-For packages in non-US/main, non-US/contrib, -developers should at least follow the . Maintainers of -non-US/non-free packages should further consult the of non-free software. -

-This section is for information only and does not constitute legal -advice. Again, it is strongly recommended that U.S. citizens and -residents consult a lawyer before doing uploads to non-US. - - Delayed uploads

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 @@ -1813,7 +1913,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. @@ -1821,14 +1922,14 @@ For details, please see section . Other upload queues

-The scp queues on ftp-master, non-us and security are mostly unuseable +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 +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.

@@ -1858,7 +1959,7 @@ The installation notification also includes information on what section the package was inserted into. If there is a disparity, you will receive a separate email notifying you of that. Read on below.

-Note also that if you upload via queues, the queue daemon software will +Note that if you upload via queues, the queue daemon software will also send you a notification by email. Specifying the package section, subsection and priority @@ -1880,14 +1981,14 @@ 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 priority to the new one. Be sure to explain your reasoning.

For more information about override files, see and +name="dpkg-scanpackages" section="1"> and .

Note that the Section field describes both the section as @@ -1904,15 +2005,15 @@ tracking system" id="&url-bts;">. This includes knowing how to file bug reports properly (see ), how to update them and reorder them, and how to process and close them.

-The bug tracking system's features interesting to developers are described +The bug tracking system's features are described in the . This includes closing bugs, sending followup messages, assigning severities -and tags, marking bugs as forwarded and other issues. +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 @@ -1950,7 +2051,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 @@ -1968,7 +2069,7 @@ closed.

As a package maintainer, you will often find bugs in other packages or have bugs reported against your packages which are actually bugs in -other packages. The bug tracking system's features interesting to developers +other packages. The bug tracking system's features are described in the . Operations such as reassigning, merging, and tagging bug reports are described in the . This section contains some guidelines for managing your own bugs, based on the collective Debian developer experience.

-Filing bugs for problems that you find in other packages is one of +Filing bugs for problems that you find in other packages is one of the "civic obligations" of maintainership, see for details. However, handling the bugs in your own packages is even more important. @@ -1992,7 +2093,7 @@ 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. +to be brought up with the upstream author.

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. @@ -2008,6 +2109,9 @@ If the bug is real but it's caused by another package, just reassign the bug to the right package. If you don't know which package it should be reassigned to, you should ask for help on IRC or on &email-debian-devel;. +Please make sure that the maintainer(s) of the package +the bug is reassigned to +know why you reassigned it.

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 @@ -2015,8 +2119,19 @@ 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. +If the bug is real but the same problem has already been reported by +someone else, then the two relevant bug reports should be merged +into one using the merge command of the BTS. +In this way, when the +bug is fixed, all of the submitters will be informed of this. +(Note, however, that emails sent to one bug report's submitter won't +automatically be sent to the other report's submitter.) +For more +details on the technicalities of the merge command and its relative, +the unmerge command, see the BTS control server documentation. + 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 @@ -2030,8 +2145,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 in 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 @@ -2048,12 +2164,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 @@ -2078,14 +2195,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. +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 @@ -2104,7 +2237,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. @@ -2120,7 +2253,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. @@ -2149,10 +2282,10 @@ 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 a developer can learn of a security problem: +There are several ways developers can learn of a security problem: - he notices it on a public forum (mailing list, web site, etc.) + they notice it on a public forum (mailing list, web site, etc.) someone files a bug report someone informs them via private email @@ -2169,7 +2302,7 @@ There are a few ways a developer 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. @@ -2352,7 +2485,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 @@ -2366,9 +2499,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 @@ -2376,14 +2508,14 @@ 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

Sometimes a package will change its section. For instance, a package from the `non-free' section might be GPL'd in a later version, -in which case, the package should be moved to `main' or +in which case the package should be moved to `main' or `contrib'. See the for guidelines on what section a package belongs in. @@ -2392,7 +2524,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.

@@ -2408,14 +2544,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. @@ -2424,19 +2573,27 @@ Usually you only ask for the removal of a package maintained by yourself. If you want to remove another package, you have to get the approval of its maintainer.

+Further information relating to these and other package removal related +topics may be found at and +. +

If in doubt concerning whether a package is disposable, email &email-debian-devel; asking for opinions. Also of interest is the apt-cache program from the apt 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

@@ -2474,8 +2631,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 @@ -2498,7 +2655,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 @@ -2556,9 +2713,9 @@ porters, and make their jobs unnecessarily difficult.

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, -doing your best to hunt down whatever the problem is. +they were in fact co-maintainers of your package (which, in a way, they +are). Please be tolerant of succinct or even unclear bug reports; +do your best to hunt down whatever the problem is.

By far, most of the problems encountered by porters are caused by packaging bugs in the source packages. Here is a checklist @@ -2606,7 +2763,7 @@ or programs. For instance, you should never be calling programs in 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 +Don't depend on the package you're building being installed already (a sub-case of the above issue). Don't rely on the compiler being a certain version, if possible. If @@ -2643,7 +2800,7 @@ binary-only build of only the architecture-dependent portions of the package, using the `binary-arch' target in debian/rules.

If you are working on a Debian machine for your porting efforts and you -need to sign your upload locally for the acceptance in the archive, you +need to sign your upload locally for its acceptance in the archive, you can run debsign on your .changes file to have it signed conveniently, or use the remote signing mode of dpkg-sig. @@ -2661,7 +2818,7 @@ version number greater than the currently available one).

You have to make sure that your binary-only NMU doesn't render the package uninstallable. This could happen when a source package generates -arch-dependend and arch-independend packages that depend on each other via +arch-dependent and arch-independent packages that depend on each other via $(Source-Version).

Despite the @@ -2675,12 +2832,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 @@ -2721,7 +2888,7 @@ architecture in order to comply with many licenses. Porters should try to avoid patches which simply kludge around bugs in the current version of the compile environment, kernel, or libc. Sometimes such kludges can't be helped. If you have to kludge around -compilers bugs and the like, make sure you #ifdef your work +compiler bugs and the like, make sure you #ifdef your work properly; also, document your kludge so that people know to remove it once the external problems have been fixed.

@@ -2735,7 +2902,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.

@@ -2791,7 +2958,56 @@ different sub-flavors of Debian, which may or may not really be of 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 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 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. +

+In order to prevent broken packages from being uploaded to the archive, and +wasting buildd time, you need to do a few things: +

+ + +

+First, make sure your package does fail to build on +architectures that it cannot support. +There are a few ways to achieve this. +The preferred way is to have a small testsuite during build time +that will test the functionality, and fail if it doesn't work. +This is a good idea anyway, +as this will prevent (some) broken uploads on all architectures, +and also will allow the package to build +as soon as the required functionality is available. +

+Additionally, if you believe the list of supported architectures is +pretty constant, you should change 'any' to a list of supported +architectures in debian/control. This way, the build will fail also, +and indicate this to a human reader without actually trying. + +

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

+Please note that it is insufficient to only add your package to +Packages-arch-specific +without making it fail to build on unsupported architectures: +A porter or any other person trying to build your package might +accidently upload it without noticing it doesn't work. +If in the past some binary packages were uploaded on unsupported architectures, +request their removal by filing a bug against +ftp.debian.org Non-Maintainer Uploads (NMUs) @@ -2803,11 +3019,12 @@ called a non-maintainer upload, or NMU. This section handles only source NMUs, i.e. NMUs which upload a new version of the package. For binary-only NMUs by porters or QA members, please see . -For buildd uploads (which are strictly speaking also NMUs), please see . +If a buildd builds and uploads a package, +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. @@ -2821,9 +3038,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 @@ -2832,10 +3050,10 @@ 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 thankfull for that help, and NMUers should respect +Maintainers should be thankful for that help, and NMUers should respect the decisions of maintainers, and try to personally help the maintainer by their work.

@@ -2854,7 +3072,7 @@ 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 them a mail announcing your intent to NMU the package. -Prepare an NMU as described in , test it +Prepare an NMU as described in this section, and test it carefully on your machine (cf. ). Double check that your patch doesn't have any unexpected side effects. Make sure your patch is as small and as non-disruptive as it can be. @@ -2883,8 +3101,8 @@ 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 -all your changes are ok for inclusion into the next stable release by the +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.

When a security bug is detected, the security team may do an NMU, using @@ -2921,7 +3139,9 @@ work. It also has the benefit of making it visually clear that a package in the archive was not made by the official maintainer.

If there is no debian-revision component in the version -number then one should be created, starting at `0.1'. If it is +number then one should be created, starting at `0.1' (but in case +of a debian native package still upload it as native package). +If it is absolutely necessary for someone other than the usual maintainer to make a release based on a new upstream version then the person making the release should start with the debian-revision value @@ -2936,11 +3156,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 @@ -2962,24 +3182,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 @@ -2989,14 +3199,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 @@ -3011,14 +3224,14 @@ to apply the patch that has been sent to you. Once this is done, you have to close the bugs that have been tagged fixed by the NMU. The easiest way is to use the -v option of dpkg-buildpackage, as this allows you to include just all changes since your last maintainer -upload. Alternativly, you +upload. Alternatively, you can close them manually by sending the required mails to the BTS or by adding the required closes: #nnnn in the changelog 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 @@ -3035,8 +3248,8 @@ improperly orphaned package, please set the maintainer to ``Debian QA Group 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 @@ -3069,10 +3282,10 @@ 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. Best use always ``binary NMU'' or ``binNMU'' for binary-only +be careful: always use ``binary NMU'' or ``binNMU'' for binary-only NMUs. @@ -3082,8 +3295,8 @@ 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 -packages in which a priority of Standard or which are part of +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.

Generally there is a primary maintainer and one or more @@ -3099,7 +3312,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.

@@ -3117,9 +3331,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. @@ -3141,10 +3378,12 @@ Please see below for details. Updates from unstable

The scripts that update the testing distribution are run each -day after the installation of the updated packages. They generate the +day after the installation of the updated packages; +these scripts are called britney. +They generate the Packages files for the testing distribution, but -they do so in an intelligent manner trying to avoid any inconsistency -and trying to use only non-buggy packages. +they do so in an intelligent manner; they try to avoid any inconsistency +and to use only non-buggy packages.

The inclusion of a package from unstable is conditional on the following: @@ -3152,35 +3391,35 @@ the following: The package must have been available in unstable for 2, 5 or 10 days, depending on the urgency (high, medium or low). -Please note that the urgency is sticky, means that the highest -urgency uploaded since the last testing transition is taken into account. -Those delays may be doubled during a freeze, or testing transition may be -switched off at all; +Please note that the urgency is sticky, meaning that the highest +urgency uploaded since the previous testing transition is taken into account. +Those delays may be doubled during a freeze, or testing transitions may be +switched off altogether; -It must have less release-critical bugs than the version 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 been -previously built in unstable. may be of interest to +It must be available on all architectures on which it has previously +been built in unstable. may be of interest to check that information; -It must not break any dependency of a package that is already available +It must not break any dependency of a package which is already available 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 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 testing script output on the , or use the program grep-excuses which is in the devscripts package. This utility can -easily be used in a to keep one -informed of the progression of their packages into testing. +easily be used in a to keep yourself +informed of the progression of your 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 +why the package is refused; you may have to find it on your own by looking for what would break with the inclusion of the package. The gives some more information about the usual problems which may be causing such troubles. @@ -3190,15 +3429,17 @@ inter-relationship is too complicated and cannot be sorted out by the scripts. See below for details.

Some further dependency analysis is shown on - - but be warned, they show also -the build dependencies that are not considered by britney. + — but be warned, +this page also shows build dependencies which +are not considered by britney. out-of-date

+ For the testing migration script, "outdated" means: There are different versions in unstable for the release architectures (except for the -architectures in fuckedarches; fuckedarches is an list of architectures +architectures in fuckedarches; fuckedarches is a list of architectures that don't keep up (in update_out.py), but currently, it's empty). "outdated" has nothing whatsoever to do with the architectures this package has in testing. @@ -3237,18 +3478,23 @@ if you maintain glibc or so.) Removals from testing

Sometimes, a package is removed to allow another package in: This happens -only to allow _another_ package to go in, that's ready in every other -sense. Consider e.g. that a conflicts with the new version of b; than a may -be removed to allow b in. +only to allow another package to go in if it's ready in every other +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

-A situation that is not handled very well by britney is if package a -depends on the new version of package b, and vice versa. +A situation which is not handled very well by britney is if package a +depends on the new version of package b, and vice versa.

An example of this is:

@@ -3259,10 +3505,10 @@ a | 1; depends: b=1 | 2; depends: b=2 b | 1; depends: a=1 | 2; depends: a=2

-Package a is not considered for update, and package b also not. +Neither package a nor package b is considered for update.

Currently, this requires some manual hinting from the release team. -Please, contact them by sending mail to &email-debian-release; if that +Please contact them by sending mail to &email-debian-release; if this happens to one of your packages. @@ -3276,7 +3522,7 @@ even if it is still RC-buggy. The second exception is if the version of the package in testing is out of sync on the different arches: Then any arch might just upgrade to the version of the source package; however, this can happen only if the package was previously forced -through, the arch is in fuckedarches or there was no binary package of that +through, the arch is in fuckedarches, or there was no binary package of that arch present in unstable at all during the testing migration.

In summary this means: The only influence that a package being in testing @@ -3290,17 +3536,18 @@ 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 +why a package is not considered are too young, RC-bugginess, and out of +date on some arches. For this part of britney, +the release managers have hammers +of various sizes to force britney to consider a package. (Also, the base freeze is coded in that part of britney.) (There is a similar thing for binary-only updates, but this is not described here. If you're -interessted in that, please use the code.) +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 sarge is not -more uninstallable after the update as before. (Before and after this part, +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.)

@@ -3325,19 +3572,39 @@ upload to testing-proposed-updates. Keep in mind that packages uploaded there are not automatically processed, they have to go through the hands of the release manager. So you'd better have a good reason to upload there. In order to know what a good reason is in the -release manager's eyes, you should read the instructions that he regularly -gives on &email-debian-devel-announce;. +release managers' eyes, you should read the instructions that they regularly +give on &email-debian-devel-announce;.

You should not upload to testing-proposed-updates when you can update your packages through unstable. If you can't (for example because you have a -newer development version in unstable), you may use it but it is recommended to ask -the authorization of the release manager before. Even if a package is +newer development version in unstable), you may use this facility, +but it is recommended that you ask for authorization from +the release manager first. +Even if a package is frozen, updates through unstable are possible, if the upload via unstable -does not pulls an new dependency in. +does not pull in any new dependencies.

Version numbers are usually selected by adding the codename of the testing -distribution and a incrementing number, like 1.2sarge1 for the first upload -through testing-proposed-updates of the package version 1.2. +distribution and a running number, like 1.2sarge1 for the first upload +through testing-proposed-updates of package version 1.2. +

+Please make sure you didn't miss any of these items in your upload: + + Make sure that your package really needs to go through +testing-proposed-updates, and can't go through unstable; + Make sure that you included only the minimal amount of changes; + Make sure that you included an appropriate explanation in the +changelog; + Make sure that you've written testing or +testing-proposed-updates into your target distribution; + Make sure that you've built and tested your package in +testing, not in unstable; + Make sure that your version number is higher than the version in +testing and testing-proposed-updates, and lower than in +unstable; + After uploading and successful build on all platforms, contact the +release team at &email-debian-release; and ask them to approve your upload. + @@ -3347,23 +3614,30 @@ through testing-proposed-updates of the package version 1.2. What are release-critical bugs, and how do they get counted?

-All bugs of some higher severities are by default considered release-critical; currently, these are critical, grave and serious bugs. +All bugs of some higher severities are by default considered release-critical; currently, these are critical, grave, and serious bugs.

Such bugs are presumed to have an impact on the chances that the package will be released with the stable release of Debian: in general, if a package has open release-critical bugs filed on it, it won't get into "testing", and consequently won't be released in "stable".

-The "testing" bug count for a package is considered to be roughly the bug count at the last point when the "testing" version equalled the "unstable" version. The bugs tagged woody or sarge will not be counted. Bugs with the sid tag will be counted, though. +The unstable bug count are all release-critical bugs +without either any release-tag (such as potato, woody) or with release-tag sid; +also, only if they are neither fixed nor set to sarge-ignore. +The "testing" bug count for a package is considered to be roughly +the bug count of unstable count at the last point +when the "testing" version equalled the "unstable" version. +

+This will change post-sarge, as soon as we have versions in the bug tracking system. How could installing a package into "testing" possibly break other packages?

-The structure of the distribution archives is such that they can only contain one version of a package; a package is defined by its name. So, when the source package acmefoo is installed into "testing", along with its binary packages acme-foo-bin, acme-bar-bin, libacme-foo1 and libacme-foo-dev, the old version is removed. +The structure of the distribution archives is such that they can only contain one version of a package; a package is defined by its name. So when the source package acmefoo is installed into "testing", along with its binary packages acme-foo-bin, acme-bar-bin, libacme-foo1 and libacme-foo-dev, the old version is removed.

However, the old version may have provided a binary package with an old soname of a library, such as libacme-foo0. Removing the old acmefoo will remove libacme-foo0, which will break any packages which depend on it.

-Evidently, this mainly affects packages which provide changing sets of binary packages in different versions (in turn, mainly libraries). However, it will also affect packages upon which versioned dependencies have been declared of the ==, <= or << varieties. +Evidently, this mainly affects packages which provide changing sets of binary packages in different versions (in turn, mainly libraries). However, it will also affect packages upon which versioned dependencies have been declared of the ==, <=, or << varieties.

-When the set of binary packages provided by a source package change in this way, all the packages that depended on the old binaries will have to be updated to depend on the new binaries instead. Because installing such a source package into "testing" breaks all the packages that depended on it in "testing", some care now has to be taken: all the depending packages must be updated and ready to be installed themselves so that they won't be broken, and, once everything is ready, manual intervention by the release manager or an assistant is normally required. +When the set of binary packages provided by a source package change in this way, all the packages that depended on the old binaries will have to be updated to depend on the new binaries instead. Because installing such a source package into "testing" breaks all the packages that depended on it in "testing", some care has to be taken now: all the depending packages must be updated and ready to be installed themselves so that they won't be broken, and, once everything is ready, manual intervention by the release manager or an assistant is normally required.

If you are having problems with complicated groups of packages like this, contact debian-devel or debian-release for help. @@ -3396,9 +3670,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, @@ -3408,7 +3684,7 @@ changed. Helper scripts take care of these issues. Assuming you comply with the conventions expected by the helper script, the helper takes care of all the details. Changes in policy can be made in the helper -script, then packages just need to be rebuilt with the new version of +script; then packages just need to be rebuilt with the new version of the helper and no other changes.

contains a couple of different helpers. The most @@ -3467,7 +3743,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). @@ -3477,8 +3753,8 @@ 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 -subset she needs, and thus save some disk space). +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. You just need to move the appropriate files from the build directory @@ -3607,25 +3883,26 @@ I as a user need this package? What other features does the package have? What outstanding features and deficiencies are there compared to other packages (e.g., "if you need X, use Y instead")? Is this package related to other packages in some way that is not handled by -the package manager (e.g., "this is the client to the foo server")? +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

-User usually expect these questions to be answered in the package -description. +Users usually expect these questions to be answered in the package +description: What does the package do? If it is an add-on to another package, -then the short description of the package we are an add on to +then the short description of the package we are an add-on to should be put in here. -Why should I want this package? This is related to the above, +Why should I want this package? This is related to the above, but not the same (this is a mail user agent; this is cool, fast, -interfaces with pgp and ldap and imap, has features X, Y, and Z). +interfaces with PGP and LDAP and IMAP, has features X, Y, and Z). If this package should not be installed directly, but is pulled in by another package, this should be mentioned. @@ -3636,8 +3913,11 @@ used instead, it should be here as well. How is this package different from the competition? Is it a better implementation? more features? different features? Why should I -choose this package (2. should talk about the class of packages, and +choose this package. + @@ -3665,7 +3945,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 + @@ -3736,21 +4072,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.

@@ -3807,7 +4138,7 @@ start by inserting the title of each different bug. - Suplimenting changelogs with NEWS.Debian files + Supplementing changelogs with NEWS.Debian files

Important news about changes in a package can also be put in NEWS.Debian files. The news will be displayed by tools like apt-listchanges, before @@ -3831,7 +4162,7 @@ cron (3.0pl1-74) unstable; urgency=low functionality provided with that script, please install the new package. - -- Steve Greenland <stevegr&debian.org> Sat, 6 Sep 2003 17:15:03 -0500 + -- Steve Greenland <stevegr@debian.org> Sat, 6 Sep 2003 17:15:03 -0500

The NEWS.Debian file is installed as @@ -3880,7 +4211,7 @@ the postinst script.

Keep the maintainer scripts as simple as possible. We suggest you use pure POSIX shell scripts. Remember, if you do need any bash features, -the maintainer script must have a bash sh-bang line. POSIX shell or +the maintainer script must have a bash shebang line. POSIX shell or Bash are preferred to Perl, since they enable debhelper to easily add bits to the scripts.

@@ -3893,7 +4224,7 @@ If you need to check for the existence of a command, you should use something like if [ -x /usr/sbin/install-docs ]; then ... -If you don't wish to hard-code the path of the command in your +If you don't wish to hard-code the path of a command in your maintainer script, the following POSIX-compliant shell function may help: @@ -3928,6 +4259,387 @@ future. Debconf is a great tool but it is often poorly used. Many common mistakes are listed in the man page. It is something that you must read if you decide to use debconf. +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 (the +installation system for instance). + + Do not abuse debconf +

+Since debconf appeared in Debian, it has been widely abused and +several criticisms received by the Debian distribution come from +debconf abuse with the need of answering a wide bunch of questions +before getting any little thing installed. +

+Keep usage notes to what they belong: the NEWS.Debian, or +README.Debian file. Only use notes for important notes which may +directly affect the package usability. Remember that notes will always +block the install until confirmed or bother the user by email. +

+Carefully choose the questions priorities in maintainer scripts. See + for details about priorities. +Most questions should use medium and low priorities. + + General recommendations for authors and translators +

+ Write correct English +

+Most Debian package maintainers are not native English speakers. So, +writing properly phrased templates may not be easy for them. +

+Please use (and abuse) &email-debian-l10n-english; mailing +list. Have your templates proofread. +

+Badly written templates give a poor image of your package, of your +work...or even of Debian itself. +

+Avoid technical jargon as much as possible. If some terms sound common +to you, they may be impossible to understand for others. If you cannot +avoid them, try to explain them (use the extended description). When +doing so, try to balance between verbosity and simplicity. + + Be kind to translators +

+Debconf templates may be translated. Debconf, along with its sister +package po-debconf offers a simple framework for getting +templates translated by translation teams or even individuals. +

+Please use gettext-based templates. Install po-debconf on your +development system and read its documentation ("man po-debconf" is a +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 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 +headers. +

+The use of the podebconf-report-po from the +po-debconf package is highly recommended to warn translators which +have incomplete translations and request them for updates. +

+If in doubt, you may also contact the translation team for a given +language (debian-l10n-xxxxx@lists.debian.org), or the +&email-debian-i18n; mailing list. +

+Calls for translations posted to +&email-debian-i18n; with the debian/po/templates.pot file +attached or referenced in a URL are encouraged. Be sure to mentions in +these calls for new translations which languages you have existing +translations for, in order to avoid duplicate work. + Unfuzzy complete translations when correcting typos and spelling +

+ +When the text of a debconf template is corrected and you are +sure that the change does not affect +translations, please be kind to translators and unfuzzy their +translations. +

+If you don't do so, the whole template will not be translated as long +as a translator will send you an update. +

+To unfuzzy translations, you can proceed the following way: + + +Put all incomplete PO files out of the way. You can check the +completeness by using (needs the gettext package installed): +for i in debian/po/*po; do echo -n $i: ; msgfmt -o /dev/null +--statistics $i; done + +move all files which report either fuzzy strings to a temporary +place. Files which report no fuzzy strings (only translated and +untranslated) will be kept in place. + +now and now only, modify the template for the typos +and check again that translation are not impacted (typos, spelling +errors, sometimes typographical corrections are usually OK) + +run debconf-updatepo. This will fuzzy all strings +you modified in translations. You can see this by running the above +again + +use the following command: +for i in debian/po/*po; do msgattrib --output-file=$i --clear-fuzzy $i; done + +move back to debian/po the files which showed fuzzy strings in the first step + +run debconf-updatepo again + + Do not make assumptions about interfaces +

+Templates text should not make reference to widgets belonging to some +debconf interfaces. Sentences like "If you answer Yes..." have no +meaning for users of graphical interfaces which use checkboxes for +boolean questions. +

+String templates should also avoid mentioning the default values in +their description. First, because this is redundant with the values +seen by the users. Also, because these default values may be different +from the maintainer choices (for instance, when the debconf database +was preseeded). +

+More generally speaking, try to avoid referring to user actions. +Just give facts. + + Do not use first person +

+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. 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. + + + Templates fields definition +

+This part gives some information which is mostly taken from the + manual page. + + Type +

+ + string: +

+Results in a free-form input field that the user can type any string into. + + password: +

+Prompts the user for a password. Use this with caution; be aware that +the password the user enters will be written to debconf's +database. You should probably clean that value out of the database as +soon as is possible. + + boolean: +

+A true/false choice. Remember: true/false, not yes/no... + + select: +

+A choice between one of a number of values. The choices must be +specified in a field named 'Choices'. Separate the possible values +with commas and spaces, like this: Choices: yes, no, maybe + + multiselect: +

+Like the select data type, except the user can choose any number of + + items from the choices list (or chose none of them). + + note: +

+Rather than being a question per se, this datatype indicates a note +that can be displayed to the user. It should be used only for +important notes that the user really should see, since debconf will go +to great pains to make sure the user sees it; halting the install for +them to press a key, and even mailing the note to them in some +cases. + + text: +

+This type is now considered obsolete: don't use it. + + error: +

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

+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 +that it may be accomodated by most debconf interfaces. Keeping it +short also helps translators, as usually translations tend to end up +being longer than the original. +

+The short description should be able to stand on its own. Some +interfaces do not show the long description by default, or only if the +user explicitely asks for it or even do not show it at all. Avoid +things like "What do you want to do?" +

+The short description does not necessarily have to be a full +sentence. This is part of the "keep it short and efficient" +recommendation. +

+The extended description should not repeat the short description word +for word. If you can't think up a long description, then first, think +some more. Post to debian-devel. Ask for help. Take a writing class! +That extended description is important. If after all that you still +can't come up with anything, leave it blank. +

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

+This field should be used for Select and Multiselect types. It +contains the possible choices which will be presented to users. These +choices should be separated by commas. + + + Default +

+This field is optional. It contains the default answer for string, +select and multiselect templates. For multiselect templates, it may +contain a comma-separated list of choices. + + Templates fields specific style guide +

+ + Type field +

+No specific indication except: use the appropriate type by referring +to the previous section. + + Description field +

+Below are specific instructions for properly writing the Description +(short and extended) depending on the template type. + + String/password templates +

+ + 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. + + The extended description is a complement to the short description. + In the extended part, explain what is being asked, rather than ask + the same question again using longer words. Use complete sentences. + Terse writing style is strongly discouraged. + + + Boolean templates +

+ + The short description should be phrased in the form of a question + which should be kept short and should generally end with a question + mark. Terse writing style is permitted and even encouraged if the + question is rather long (remember that translations are often longer + than original versions) + + Again, please avoid referring to specific interface widgets. A common + mistake for such templates is "if you answer Yes"-type + constructions. + + + Select/Multiselect +

+ + 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...:) + + The extended description will complete the short description. It may + refer to the available choices. It may also mention that the user + may choose more than one of the available choices, if the template + is a multiselect one (although the interface often makes this + clear). + + + Notes +

+ + The short description should be considered to be a *title*. + + 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 + 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. + If, by reading this, you consider converting your Note type templates + to entries in NEWS/Debian or README.Debian, plus consider keeping existing + translations for the future. + + + + Choices field +

+If the Choices are likely to change often, please consider using the +"__Choices" trick. This will split each individual choice into a +single string, which will considerably help translators for doing +their work. + + Default field +

+If the default value, for a "select" template, is likely to vary +depending on the user language (for instance, if the choice is a +language choice), please use the "_DefaultChoice" trick. +

+This special field allow translators to put the most appropriate +choice according to their own language. It will become the default +choice when their language is used while your own mentioned Default +Choice will be used chan using English. +

+Example, taken from the geneweb package templates: + +Template: geneweb/lang +Type: select +__Choices: Afrikaans (af), Bulgarian (bg), Catalan (ca), Chinese (zh), Czech (cs), Danish (da), Dutch (nl), English (en), Esperanto (eo), Estonian (et), Finnish (fi), French (fr), German (de), Hebrew (he), Icelandic (is), Italian (it), Latvian (lv), Norwegian (no), Polish (pl), Portuguese (pt), Romanian (ro), Russian (ru), Spanish (es), Swedish (sv) +# This is the default choice. Translators may put their own language here +# instead of the default. +# WARNING : you MUST use the ENGLISH FORM of your language +# For instance, the french translator will need to put "French (fr)" here. +_DefaultChoice: English (en)[ translators, please see comment in PO files] +_Description: Geneweb default language: + +

+Note the use of brackets which allow internal comments in debconf +fields. Also note the use of comments which will show up in files the +translators will work with. +

+The comments are needed as the DefaultChoice trick is a bit +confusing: the translators may put their own choice + + Default field +

+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 +field translatable, if you think it may be translated. +

+If the default value may vary depending on language/country (for +instance the default value for a language choice), consider using the +special "_DefaultChoice" type documented in ). @@ -3988,7 +4700,7 @@ If you maintain XML or SGML documentation, we suggest that you isolate any language-independent information and define those as entities in a separate file which is included by all the different translations. This makes it much easier, for instance, to keep URLs -up-to-date across multiple files. +up to date across multiple files. @@ -4007,7 +4719,7 @@ up-to-date across multiple files. autoconf/automake

Keeping autoconf's config.sub and -config.guess files up-to-date is critical for porters, +config.guess files up to date is critical for porters, especially on more volatile architectures. Some very good packaging practices for any package using autoconf and/or automake have been synthesized in @@ -4021,7 +4733,7 @@ to follow the given recommendations. Libraries are always difficult to package for various reasons. The policy imposes many constraints to ease their maintenance and to make sure upgrades are as simple as possible when a new upstream version comes out. -A breakage in a library can result in dozens of dependent packages +Breakage in a library can result in dozens of dependent packages breaking.

Good practices for library packaging have been grouped in @@ -4040,7 +4752,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.

@@ -4081,6 +4793,7 @@ package. Lisp packages should register themselves with common-lisp-controller, about which see &file-lisp-controller;. + @@ -4146,23 +4859,276 @@ LOCPATH=$LOCALE_PATH LC_ALL=$LOCALE_NAME.$LOCALE_CHARSET date Make transition packages deborphan compliant

-Deborphan is a program helping users to detect which packages can be safely +Deborphan is a program for helping users to detect which packages can safely be removed from the system, i.e. the ones that have no packages depending on them. The default operation is to search only within the libs and oldlibs sections, to hunt down unused libraries. But when passed the right argument, it tries to catch other useless packages.

-For example, with --guess-dummy, tries to search all transitional packages +For example, with --guess-dummy, deborphan tries to search all transitional packages which were needed for upgrade but which can now safely be removed. For that, it looks for the string "dummy" or "transitional" in their short description.

So, when you are creating such a package, please make sure to add this text -to your short description. If you are looking for example, just run: +to your short description. If you are looking for examples, just run: apt-cache search .|grep dummy or apt-cache search .|grep transitional. + + + Best practices for orig.tar.gz files +

+ 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 +.orig.tar.gz file is byte-for-byte identical to a tarball officially +distributed by the upstream author. + +We cannot prevent upstream authors from changing the tarball +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 +something that upstream once did distribute. + +If a difference arises later (say, if upstream notices that he wasn't +using maximal comression in his original distribution and then +re-gzips it), that's just too bad. Since there is no good way +to upload a new .orig.tar.gz for the same version, there is not even +any point in treating this situation as a bug. + +This makes it possible to use checksums to easily verify that all +changes between Debian's version and upstream's are contained in the +Debian diff. Also, if the original source is huge, upstream authors +and others who already have the upstream tarball can save download +time if they want to inspect your packaging in detail. +

+

+There is no universally accepted guidelines that upstream authors +follow regarding to the directory structure inside their tarball, but +dpkg-source is nevertheless able to deal with most +upstream tarballs as pristine source. Its strategy is equivalent to +the following: +

+

+ + +It unpacks the tarball in an empty temporary directory by doing + + +zcat path/to/<packagename>_<upstream-version>.orig.tar.gz | tar xf - + + + +If, after this, the temporary directory contains nothing but one +directory and no other files, dpkg-source renames that +directory to +<packagename>-<upstream-version>(.orig). The name +of the top-level directory in the tarball does not matter, and is +forgotten. + + +Otherwise, the upstream tarball must have been packaged without a +common top-level directory (shame on the upstream author!). In this +case, dpkg-source renames the temporary directory +itself to +<packagename>-<upstream-version>(.orig). + + +

+ + + Repackaged upstream source +

+You should upload packages with a pristine source +tarball if possible, but there are various reasons why it might not be +possible. This is the case if upstream does not distribute the source +as gzipped tar at all, or if upstream's tarball contains non-DFSG-free +material that you must remove before uploading. +

+

+In these cases the developer must construct a suitable .orig.tar.gz +file himself. We refer to such a tarball as a "repackaged upstream +source". Note that a "repackaged upstream source" is different from a +Debian-native package. A repackaged source still comes with +Debian-specific changes in a separate .diff.gz and still has +a version number composed of <upstream-version> and +<debian-revision>. +

+

+There may be cases where it is desirable to repackage the source even +though upstream distributes a .tar.gz that could in principle +be used in its pristine form. The most obvious is if +significant space savings can be achieved by recompressing +the tar archive or by removing genuinely useless cruft from the +upstream archive. Use your own discretion here, but be prepared to +defend your decision if you repackage source that could have been +pristine. +

+

+A repackaged .orig.tar.gz +

+

+ + +

+must contain detailed information how +the repackaged source was obtained, and how this can be reproduced +in the debian/copyright. +It is also a good idea to provide a +get-orig-source target in your debian/rules file +that repeats the process, as described in the Policy Manual, . +

+ + +should not contain any file that does not come from the +upstream author(s), or whose contents has been changed by you. + +As a special exception, if the omission of non-free files would lead +to the source failing to build without assistance from the Debian +diff, it might be appropriate to instead edit the files, omitting only +the non-free parts of them, and/or explain the situation in a +README.Debian-source file in the root of the source +tree. But in that case please also urge the upstream author to make +the non-free components easier seperable from the rest of the source. + + + +

+should, except where impossible for legal reasons, +preserve the entire building and portablility infrastructure provided +by the upstream author. For example, it is not a sufficient reason for +omitting a file that it is used only when building on +MS-DOS. Similarly, a Makefile provided by upstream should not be +omitted even if the first thing your debian/rules does is +to overwrite it by running a configure script. +

+

+(Rationale: It is common for Debian users who need to build +software for non-Debian platforms to fetch the source from a Debian +mirror rather than trying to locate a canonical upstream distribution +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. + + +should be gzipped with maximal compression. + + +

+

+The canonical way to meet the latter two points is to let +dpkg-source -b construct the repackaged tarball from an +unpacked directory. +

+ + + Changing binary files in diff.gz +

+Sometimes it is necessary to change binary files contained in the +original tarball, or to add binary files that are not in it. +If this is done by simply copying the files into the debianized source +tree, dpkg-source will not be able to handle this. On the +other hand, according to the guidelines given above, you cannot +include such a changed binary file in a repackaged +orig.tar.gz. Instead, include the file in the +debian directory in uuencoded (or similar) +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. +

+

+Some packages use dbs to manage patches to their upstream +source, and always create a new orig.tar.gz file that +contains the real orig.tar.gz in its toplevel directory. This +is questionable with respect to the preference for pristine source. On +the other hand, it is easy to modify or add binary files in this case: +Just put them into the newly created orig.tar.gz file, +besides the real one, and copy them to the right place during the +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}) + + + @@ -4206,7 +5172,7 @@ provide you with this information (and reportbug will usually invoke querybts before sending, too).

Try to direct your bugs to the proper location. When for example -your bug is about a package that overwrites files from another package, +your bug is about a package which overwrites files from another package, check the bug lists for both of those packages in order to avoid filing duplicate bug reports.

@@ -4223,7 +5189,7 @@ close those that you can't reproduce anymore. To find out all the bugs you submitted, you just have to visit http://&bugs-host;/from:<your-email-addr>. - Reporting lots of bugs at once + Reporting lots of bugs at once (mass bug filing)

Reporting a great number of bugs for the same problem on a great number of different packages — i.e., more than 10 — is a deprecated @@ -4234,11 +5200,18 @@ is emitted.

If you report more than 10 bugs on the same topic at once, it is recommended that you send a message to &email-debian-devel; describing -your intention before submitting the report. This will allow other +your intention before submitting the report, and mentioning the +fact in the subject of your mail. This will allow other 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 @@ -4256,7 +5229,7 @@ possible, and as lintian-clean (see ) as possible. If you do not find that possible, then you should consider orphaning some of your packages (see ). Alternatively, you may ask the help of other people -in order to catch up the backlog of bugs that you have (you can ask +in order to catch up with the backlog of bugs that you have (you can ask for help on &email-debian-qa; or &email-debian-devel;). At the same time, you can look for co-maintainers (see ). @@ -4264,13 +5237,13 @@ time, you can look for co-maintainers (see ).

From time to time the QA group organizes bug squashing parties to get rid of as many problems as possible. They are announced on &email-debian-devel-announce; -and the announce explains what area will be focused on during the party: +and the announcement explains which area will be the focus of the party: usually they focus on release critical bugs but it may happen that they -decide to help finish a major upgrade going on (like a new perl version +decide to help finish a major upgrade (like a new perl version which requires recompilation of all the binary modules).

The rules for non-maintainer uploads differ during the parties because -the announce of the party is considered like a prior notice for NMU. If +the announcement of the party is considered prior notice for NMU. If you have packages that may be affected by the party (because they have release critical bugs for example), you should send an update to each of the corresponding bug to explain their current status and what you expect @@ -4280,12 +5253,12 @@ the BTS.

People participating in the party have special rules for NMU, they can NMU without prior notice if they upload their NMU to -DELAYED/3-day at least. All other NMU rules applies as usually, they -should send the patch of the NMU in the BTS (in one of the open bugs -fixed by the NMU or in a new bug tagged fixed). They should -also respect the maintainer's wishes if he expressed some. +DELAYED/3-day at least. All other NMU rules apply as usually; they +should send the patch of the NMU to the BTS (to one of the open bugs +fixed by the NMU, or to a new bug, tagged fixed). They should +also respect any particular wishes of the maintainer.

-If someone doesn't feel confident with an NMU, he should just send a patch +If you don't feel confident about doing an NMU, just send a patch to the BTS. It's far better than a broken NMU. @@ -4306,9 +5279,9 @@ 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. - + Dealing with inactive and/or unreachable maintainers

@@ -4319,22 +5292,22 @@ 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 inactive 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 -them, this is recorded in the MIA database. This system is available +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, -you will generally proceed as follows. +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 send a reminder after two +very hectic. One way to handle this would be to send a reminder after two weeks.

If the maintainer doesn't reply within four weeks (a month), one can @@ -4345,7 +5318,7 @@ about the maintainer in question as possible. This includes: The "echelon" information available through the , - which indicates when's the last time a developer 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. @@ -4355,41 +5328,46 @@ about the maintainer in question as possible. This includes: any RC bugs that have been open for ages? Furthermore, how many bugs are there in general? Another important piece of information is whether the packages have been NMUed, and if - so, by whom? + so, by whom. Is there any activity of the maintainer outside of Debian? For example, they might have posted something recently to 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 -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!) +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!

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;. @@ -4408,9 +5386,11 @@ Sponsoring a package means uploading a package for a maintainer who is not able to do it on their own, a new maintainer applicant. Sponsoring a package also means accepting responsibility for it.

+ New maintainers usually have certain difficulties creating Debian packages — this is quite understandable. That is why the sponsor is there, to check the package and verify that it is good enough for inclusion in Debian. @@ -4433,7 +5413,7 @@ By uploading a sponsored package to Debian, you are certifying that the package meets minimum Debian standards. That implies that you must build and test the package on your own system before uploading.

-You can not simply upload a binary .deb from the sponsoree. In +You cannot simply upload a binary .deb from the sponsoree. In theory, you should only ask for the diff file and the location of the original source tarball, and then you should download the source and apply the diff yourself. In practice, you may want to use the source package @@ -4449,7 +5429,7 @@ means being a mentor. Once the package meets Debian standards, build and sign it with dpkg-buildpackage -kKEY-ID before uploading it to the incoming directory. Of course, you can also -use any part of your KEY-ID, as long as it's uniq in your +use any part of your KEY-ID, as long as it's unique in your secret keyring.

The Maintainer field of the control file and the @@ -4478,10 +5458,10 @@ Application Managers"> at the Debian web site. and being translated

Debian supports an ever-increasing number of natural languages. Even if you are -native English speaker and do not speak any other language, it is part of your +a native English speaker and do not speak any other language, it is part of your duty as a maintainer to be aware of issues of internationalization (abbreviated i18n because there are 18 letters between the 'i' and the 'n' in -internationalization). Therefore, even if you are ok with English only +internationalization). Therefore, even if you are ok with English-only programs, you should read most of this chapter.

According to -l10n and i18n are tied, but the difficulties related to each of them are very +l10n and i18n are interconnected, but the difficulties related to each of them are very different. It's not really difficult to allow a program to change the language in which texts are displayed based on user settings, but it is very time consuming to actually translate these messages. On the other hand, setting the character encoding is trivial, but adapting the code to use several character encodings is a really hard problem.

-Letting alone the i18n problems, where no general receipt exist, there is +Setting aside the i18n problems, where no general guideline can be given, there is actually no central infrastructure for l10n within Debian which could be -compared to the dbuild mechanism for porting. So, most of the work has to be +compared to the dbuild mechanism for porting. So most of the work has to be done manually. @@ -4517,112 +5497,118 @@ translation Project"> or the . The only centralized resource within Debian is the , where you can find some statistics about the translation files -found in the actual package, but no real infrastructure to ease the translation +found in the actual packages, but no real infrastructure to ease the translation process.

-An effort to translate the package descriptions started long ago even if very -few support is offered by the tools to actually use them (ie, only APT can use -them, when configured correctly). There is nothing to do for the maintainers, -and the translators should use the .

-For debconf templates, maintainer should use the po-debconf package to ease the -work of translators, which could use the DDTP to do their work (but French and +For debconf templates, maintainers should use the po-debconf package to ease the +work of translators, who could use the DDTP to do their work (but the French and Brazilian teams don't). Some statistics can be found both on the DDTP site (about what is actually translated), and on the site (about what is integrated in the packages). - p> +

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 an access to the CVS), but there is +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 document, other formats), -almost everything have yet to be done. Most notably, the KDE project handles +For package-specific documentation (man pages, info documents, other formats), +almost everything remains to be done. +

+Most notably, the KDE project handles translation of its documentation in the same way as its program messages. -Debian specific man pages begin to be handled within a +There is an effort to handle Debian-specific man pages +within a . +repository">. I18N & L10N FAQ for maintainers

This is a list of problems that maintainers may face concerning i18n and l10n. -While reading this, keep in mind that there is no real consensus on those -points within Debian, and that they are only advices. If you have a better idea +While reading this, keep in mind that there is no real consensus on these +points within Debian, and that this is only advice. If you have a better idea for a given problem, or if you disagree on some points, feel free to provide your feedback, so that this document can be enhanced. - How to get a given text translated? + How to get a given text translated

-To translate package description or debconf templates, you have nothing to do, +To translate package descriptions or debconf templates, you have nothing to do; the DDTP infrastructure will dispatch the material to translate to volunteers with no need for interaction from your part.

-For all other material (gettext files, man pages or other documentation), the -best solution is to put your text somewhere on Internet, and ask on debian-i18n -for a translation in the different languages. Some translation team members are +For all other material (gettext files, man pages, or other documentation), the +best solution is to put your text somewhere on the Internet, and ask on debian-i18n +for a translation in different languages. Some translation team members are subscribed to this list, and they will take care of the translation and of the -reviewing process. Once done, you will get your translated document from them +reviewing process. Once they are done, you will get your translated document from them in your mailbox. - How to get a given translation reviewed? + How to get a given translation reviewed

->From time to time, individuals translate some texts included in your package -and will ask you for inclusion in the package. This can become problematic if +From time to time, individuals translate some texts in your package +and will ask you for inclusion of the translation in the package. This can become problematic if you are not fluent in the given language. It is a good idea to send the document to the corresponding l10n mailing list, asking for a review. Once it has been done, you should feel more confident in the quality of the -translation, and include it fearlessly into your package. +translation, and feel safe to include it in your package. - How to get a given translation updated? + How to get a given translation updated

-If you have some translations of a given text laying around, each time you -update the original, you should kindly ask to the previous translator to update -his/her work to make the translation up to date with regard to the current -original text. Keep in mind that this task takes time, at least one week to get +If you have some translations of a given text lying around, each time you +update the original, you should ask the previous translator to update +the translation with your new changes. +Keep in mind that this task takes time; at least one week to get the update reviewed and all.

-If the translator is unresponsive, you may ask for help to the corresponding +If the translator is unresponsive, you may ask for help on the corresponding l10n mailing list. If everything fails, don't forget to put a warning in the translated document, stating that the translation is somehow outdated, and that the reader should refer to the original document if possible.

-Avoid removing completely a translation because it is outdated. An old +Avoid removing a translation completely because it is outdated. Old documentation is often better than no documentation at all for non-English -speaker. +speakers. - How to handle a bug report concerning a translation? + How to handle a bug report concerning a translation

The best solution may be to mark the bug as "forwarded to upstream", and forward it to both the previous translator and his/her team (using the corresponding debian-l10n-XXX mailing list). + I18N & L10N FAQ for translators

While reading this, please keep in mind that there is no general procedure -within Debian concerning those points, and that in any case, you should +within Debian concerning these points, and that in any case, you should collaborate with your team and the package maintainer. - How to help the translation effort? + How to help the translation effort

Choose what you want to translate, make sure that nobody is already working on it (using your debian-l10n-XXX mailing list), translate it, get it reviewed by other native speakers on your l10n mailing list, and provide it to the maintainer of the package (see next point). - How to provide a translation for inclusion in a package? + How to provide a translation for inclusion in a package

Make sure your translation is correct (asking for review on your l10n mailing 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 package. Make sure to use the 'PATCH' tag, and to not use a gravity higher +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. @@ -4631,9 +5617,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 @@ -4641,7 +5627,7 @@ they don't report the errors they find, nobody will. In any case, remember that the major issue with l10n is that it requires several people to cooperate, and that it is very easy to start a flamewar about -small problems because of misunderstanding. So, if you have problems with your +small problems because of misunderstandings. So if you have problems with your interlocutor, ask for help on the corresponding l10n mailing list, on debian-i18n, or even on debian-devel (but beware, l10n discussions very often become flamewars on that list :) @@ -4656,7 +5642,7 @@ This section contains a rough overview of the tools available to maintainers. The following is by no means complete or definitive, but just a guide to some of the more popular tools.

-Debian maintainer tools are meant to help convenience developers and +Debian maintainer tools are meant to aid developers and free their time for critical tasks. As Larry Wall says, there's more than one way to do it.

@@ -4664,7 +5650,7 @@ Some people prefer to use high-level package maintenance tools and some do not. Debian is officially agnostic on this issue; any tool which gets the job done is fine. Therefore, this section is not meant to stipulate to anyone which tools they should use or how they should -go about with their duties of maintainership. Nor is it meant to +go about their duties of maintainership. Nor is it meant to endorse any particular tool to the exclusion of a competing tool.

Most of the descriptions of these packages come from the actual @@ -4681,10 +5667,10 @@ The following tools are pretty much required for any maintainer.

dpkg-dev

dpkg-dev contains the tools (including -dpkg-source) required to unpack, build and upload Debian +dpkg-source) required to unpack, build, and upload Debian source packages. These utilities contain the fundamental, low-level -functionality required to create and manipulated packages; as such, -they are required for any Debian maintainer. +functionality required to create and manipulate packages; as such, +they are essential for any Debian maintainer. debconf @@ -4693,12 +5679,12 @@ they are required for any Debian maintainer. configuring packages interactively. It is user interface independent, allowing end-users to configure packages with a text-only interface, an HTML interface, or a dialog interface. New -interfaces can be added modularly. +interfaces can be added as modules.

You can find documentation for this package in the debconf-doc package.

-Many feel that this system should be used for all packages requiring +Many feel that this system should be used for all packages which require interactive configuration; see . debconf is not currently required by Debian Policy, but that may change in the future. @@ -4711,7 +5697,7 @@ but that may change in the future. you to build packages without being root (packages usually want to install files with root ownership). If you have fakeroot installed, you can build packages as a -user: dpkg-buildpackage -rfakeroot. +regular user: dpkg-buildpackage -rfakeroot. @@ -4722,27 +5708,27 @@ According to the Free On-line Dictionary of Computing (FOLDOC), `lint' is "a Unix C language processor which carries out more thorough checks on the code than is usual with C compilers." Package lint tools help package maintainers by automatically finding common problems and -policy violations with their packages.

+policy violations in their packages.

lintian

lintian dissects Debian packages and emits -information on bugs +information about bugs and policy violations. It contains automated checks for many aspects of Debian policy as well as some checks for common errors.

You should periodically get the newest lintian from `unstable' and check over all your packages. Notice that the -i option provides detailed explanations of what each error or warning means, -what is its basis in Policy, and commonly how you can fix the problem. +what its basis in Policy is, and commonly how you can fix the problem.

Refer to for more information on how and when to use Lintian.

You can also see a summary of all problems reported by Lintian on your -packages at . Those reports contain the latest -lintian output on the whole development distribution +packages at . These reports contain the latest +lintian output for the whole development distribution ("unstable"). @@ -4760,7 +5746,7 @@ written in Python rather than Perl.

debdiff (from the devscripts package, ) compares file lists and control files of two packages. It is a simple regression test, as it will help you notice if the number of binary -packages has changed since the last upload, or if something's changed +packages has changed since the last upload, or if something has changed in the control file. Of course, some of the changes it reports will be all right, but it can help you prevent various accidents.

@@ -4785,20 +5771,21 @@ For more information please see .

Package building tools make the process of writing debian/rules files easier. See -for more information on why these might or might not be desired. +for more information about why these might or might not be desired. debhelper

-debhelper is a collection of programs that can be +debhelper is a collection of programs which can be used in debian/rules to automate common tasks related to -building binary Debian packages. Programs are included to install +building binary Debian packages. debhelper includes +programs to install various files into your package, compress files, fix file permissions, -integrate your package with the Debian menu system. +and integrate your package with the Debian menu system.

Unlike some approaches, debhelper is broken into -several small, granular commands which act in a consistent manner. As -such, it allows a greater granularity of control than some of the +several small, simple commands which act in a consistent manner. As +such, it allows more fine-grained control than some of the other "debian/rules tools".

There are a number of little debhelper add-on @@ -4809,8 +5796,8 @@ them by doing apt-cache search ^dh-. debmake

-debmake, a pre-cursor to -debhelper, is a less granular +debmake, a precursor to +debhelper, is a more coarse-grained debian/rules assistant. It includes two main programs: deb-make, which can be used to help a maintainer convert a regular (non-Debian) source archive into a Debian source package; @@ -4819,8 +5806,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. @@ -4893,14 +5881,14 @@ a version control system. debootstrap

The debootstrap package and script allows you to -"bootstrap" a Debian base system into any part of your file-system. +"bootstrap" a Debian base system into any part of your filesystem. By "base system", we mean the bare minimum of packages required to operate and install the rest of the system.

Having a system like this can be useful in many ways. For instance, you can chroot into it if you want to test your build -depends. Or, you can test how your package behaves when installed -into a bare base system. Chroot builders use this package, see below. +dependencies. Or you can test how your package behaves when installed +into a bare base system. Chroot builders use this package; see below. @@ -4912,7 +5900,7 @@ build-dependencies are correct, and to be sure that unnecessary and wrong build dependencies will not exist in the resulting package.

A related package is pbuilder-uml, which goes even -further build doing the build within User-mode-linux.

+further by doing the build within a User Mode Linux environment.

 @@ -4965,8 +5953,8 @@ helps in removing files from the ftp upload directory. Maintenance automation

The following tools help automate different maintenance tasks, from -adding changelog entries or signature lines, looking up bugs in Emacs, -to making use of the newest and official use of +adding changelog entries or signature lines and looking up bugs in Emacs +to making use of the newest and official config.sub.

@@ -4980,7 +5968,7 @@ file from the command-line, and debuild, which is a wrapper around dpkg-buildpackage. The bts utility is also very helpful to update the state of bug reports on the command line. uscan can be used to watch for new upstream -versions of your packages. The debrsign can be used to +versions of your packages. debrsign can be used to remotely sign a package prior to upload, which is nice when the machine you build the package on is different from where your GPG keys are.

@@ -4992,7 +5980,8 @@ complete list of available scripts.

autotools-dev

-Contains best practices for people maintaining packages that use +autotools-dev +contains best practices for people who maintain packages which use autoconf and/or automake. Also contains canonical config.sub and config.guess files which are known to work on all Debian ports.

@@ -5007,8 +5996,8 @@ package while it was unpacked (e.g., files in /etc were modified), the new package will inherit the changes.

This utility can make it easy to copy packages from one computer to -another, or to recreate packages that are installed on your system -but no longer available elsewhere, or to store the current state of a +another, or to recreate packages which are installed on your system +but no longer available elsewhere, or to save the current state of a package before you upgrade it.

 @@ -5017,7 +6006,7 @@ package before you upgrade it.

alien converts binary packages between various packaging formats, including Debian, RPM (RedHat), LSB (Linux Standard Base), -Solaris and Slackware packages.

+Solaris, and Slackware packages.

 @@ -5033,9 +6022,11 @@ by Policy.

dpkg-dev-el is an Emacs lisp package which provides assistance when editing some of the files in the debian -directory of your package. For instance, when editing -debian/changelog, there are handy functions for -finalizing a version and listing the package's current bugs.

+directory of your package. For instance, +there are handy functions for +listing a package's current bugs, +and for finalizing the latest entry in a +debian/changelog file.