X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?a=blobdiff_plain;f=developers-reference.sgml;h=a00cabd3ace8f97d7fcf6ee63b1a026c12149ca0;hb=0705951199dd03a594900f56aa58225d68314ba6;hp=a00841f28e0ec27cb5625ca8bf61e79d5e9ad133;hpb=3210a6c768303c663ccfe933c328d6f9d4008819;p=developers-reference.git diff --git a/developers-reference.sgml b/developers-reference.sgml index a00841f..a00cabd 100644 --- a/developers-reference.sgml +++ b/developers-reference.sgml @@ -7,7 +7,7 @@ %dynamicdata; - + @@ -58,6 +58,7 @@ writing to the &fsf-addr;.

If you want to print this reference, you should use the . +This page is also available in . ]]> @@ -164,7 +165,7 @@ Those who are seeking a sponsor can request one at . --> Please read the -inofficial debian-mentors FAQ at first. +unofficial debian-mentors FAQ at first.

If you wish to be a mentor and/or sponsor, more information is available in . @@ -231,12 +232,39 @@ You can use some other implementation of OpenPGP as well. Note that OpenPGP is an open standard based on .

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

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

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

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

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

If your public key isn't on public key servers such as &pgp-keyserv;, please read the documentation available locally in &file-keyservs;. @@ -435,7 +463,7 @@ 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 @@ -560,7 +588,7 @@ just zgrep for #debian-private in all the files.

There are other additional channels dedicated to specific subjects. -#debian-bugs is used for coordinating bug squash parties. +#debian-bugs is used for coordinating bug squashing parties. #debian-boot is used to coordinate the work on the debian-installer. #debian-doc is occasionally used to talk about documentation, like the document you are @@ -578,7 +606,7 @@ Channels dedicated to Debian also exist on other IRC networks, notably on the IRC network.

-To get a cloak on freenode, you send Göran Weinholt <weinholt@debian.org> +To get a cloak on freenode, you send Jörg Jaspert <joerg@debian.org> a signed mail where you tell what your nick is. Put "cloak" somewhere in the Subject: header. The nick should be registered: @@ -668,17 +696,10 @@ 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 to the -. +The non-US server non-us.debian.org +was discontinued with the release of sarge. The pseudo-package +nonus.debian.org +stil exists for now. The www-master server

@@ -709,8 +730,7 @@ 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. @@ -995,7 +1015,7 @@ 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 +uploads to the stable distribution for details.

Note that development under unstable continues during the @@ -1027,8 +1047,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, @@ -1067,8 +1087,10 @@ to finally get them closed.

Every released Debian distribution has a code name: Debian 1.1 is called `buzz'; Debian 1.2, `rex'; Debian 1.3, `bo'; Debian 2.0, -`hamm'; Debian 2.1, `slink'; Debian 2.2, `potato'; and Debian 3.0, `woody'. There is also -a ``pseudo-distribution'', called `sid', which is the current +`hamm'; Debian 2.1, `slink'; Debian 2.2, `potato'; Debian 3.0, `woody'; +Debian 3.1, "sarge"; +Debian (number needs to be determined), "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 @@ -1130,8 +1152,7 @@ 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 UploadQueue. @@ -1250,7 +1271,7 @@ 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;, and on +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 @@ -1336,12 +1357,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. @@ -1359,6 +1385,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 @@ -1375,6 +1406,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) @@ -1391,7 +1423,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> @@ -1404,6 +1443,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 @@ -1548,6 +1593,17 @@ 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

@@ -1673,6 +1729,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. @@ -1715,6 +1776,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 @@ -1800,20 +1865,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 cannot 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 @@ -1824,41 +1875,7 @@ 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. +Note: non-us was discontinued with release of sarge. Delayed uploads @@ -1891,7 +1908,7 @@ For details, please see section . Other upload queues

-The scp queues on ftp-master, non-us, and security are mostly unusable +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 @@ -2132,9 +2149,9 @@ 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. @@ -2447,7 +2464,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 @@ -2503,7 +2520,9 @@ 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 @@ -2770,12 +2789,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 @@ -2894,7 +2923,7 @@ $arch@buildd.debian.org.

Some packages still have issues with building and/or working on some of the architectures supported by Debian, and cannot be ported at all, -or not with a reasonable amount of time. An example is a package that +or not within a reasonable amount of time. An example is a package that is SVGA-specific (only i386), or uses other hardware-specific features not supported on all architectures.

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

@@ -2934,7 +2963,7 @@ without making it fail to build on unsupported architectures: A porter or any other person trying to build your package might accidently upload it without noticing it doesn't work. If in the past some binary packages were uploaded on unsupported architectures, -request there removal by filing a bug against +request their removal by filing a bug against ftp.debian.org @@ -2966,9 +2995,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 @@ -3028,7 +3058,7 @@ managers. Please take additional care, and acknowledge that the usual way for a package to enter testing is through unstable.

For the stable distribution, please take extra care. Of course, the release -managers may also change the rules here. Please verify before upload that +managers may also change the rules here. Please verify before you upload that all your changes are OK for inclusion into the next stable release by the release manager.

@@ -3134,7 +3164,10 @@ 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 @@ -3317,7 +3350,7 @@ urgency uploaded since the previous testing transition is taken into account. Those delays may be doubled during a freeze, or testing transitions may be switched off altogether; -It must have fewer release-critical bugs than the version currently available +It must have the same number or fewer release-critical bugs than the version currently available in testing; It must be available on all architectures on which it has previously @@ -3461,7 +3494,7 @@ interested in that, please peruse the code.)

Now, the more complex part happens: Britney tries to update testing with the valid candidates; first, each package alone, and then larger and even -larger sets of packages together. Each try is accepted if unstable is not +larger sets of packages together. Each try is accepted if testing is not more uninstallable after the update than before. (Before and after this part, some hints are processed; but as only release masters can hint, this is probably not so important for you.) @@ -3585,9 +3618,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, @@ -3656,7 +3691,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). @@ -3799,10 +3834,11 @@ package related to other packages in some way that is not handled by the package manager (e.g., "this is the client for the foo server")?

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

Users usually expect these questions to be answered in the package description: @@ -3857,7 +3893,10 @@ 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.

@@ -3928,15 +3967,9 @@ 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. +Please use the option -v to dpkg-buildpackage +to close the relevant bug report. @@ -4124,8 +4157,8 @@ Also, we document some best practices here.

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

@@ -4150,7 +4183,7 @@ Most questions should use medium and low priorities. Most Debian package maintainers are not native English speakers. So, writing properly phrased templates may not be easy for them.

-Please use (and abuse) debian-l10n-english@lists.debian.org mailing +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 @@ -4164,10 +4197,10 @@ 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 +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 +Please use gettext-based templates. Install po-debconf on your development system and read its documentation ("man po-debconf" is a good start).

@@ -4180,10 +4213,57 @@ 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 -debian-i18n@lists.debian.org mailing list. +&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 @@ -4191,6 +4271,12 @@ 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. @@ -4275,7 +4361,7 @@ usual blue one). Description: short and extended description

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

The short description should be kept short (50 characters or so) so @@ -4558,7 +4644,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.

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

- + Pristine source

The defining characteristic of a pristine source tarball is that the @@ -4697,7 +4783,7 @@ The defining characteristic of a pristine source tarball is that the distributed by the upstream author. We cannot prevent upstream authors from changing the tarball -they distribute without also upping the version number, so +they distribute without also incrementing the version number, so there can be no guarantee that a pristine tarball is identical to what upstream currently distributing at any point in time. All that can be expected is that it is identical to @@ -4748,7 +4834,7 @@ case, dpkg-source renames the temporary directory

- + Repackaged upstream source

You should upload packages with a pristine source @@ -5018,7 +5104,7 @@ a source or a binary package.

You may also be interested in contacting the persons who are subscribed to a given source package via . -You can do so by using the <package-name>@&pts-host; +You can do so by using the <package>@&pts-host; email address. @@ -5084,7 +5170,7 @@ 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.

-Once you have gathered all of this, you can contact &email-debian-qa;. +Once you have gathered all of this, you can contact &email-mia;. People on this alias will use the information you provided 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 @@ -5341,7 +5427,7 @@ list) before providing it for inclusion. It will save time for everyone, and avoid the chaos resulting in having several versions of the same document in bug reports.

-The best solution is to fill a regular bug containing the translation against +The best solution is to file a regular bug containing the translation against the package. Make sure to use the 'PATCH' tag, and to not use a severity higher than 'wishlist', since the lack of translation never prevented a program from running. @@ -5540,8 +5626,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.