Debian Developer's Reference
Footnotes

1

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.

2

This is so that the message can be easily filtered by people who don't want to read vacation notices.

3

See the Debian Policy Manual for guidelines on what section a package belongs in.

4

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.

5

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.

6

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.

7

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)

Debian Developer's Reference