Deciphering Rejection mails

Rejected: GPG signature check failed on `foobar_0.1-5.dsc'.
gpg: no valid OpenPGP data found.
gpg: processing message failed: eof
    

Problem

This is GnuPG's way of reporting that the file isn't signed (a requirement for both .changes and .dsc files).

Solution

Sign the file and reupload.

Notes

If it's an unsigned .dsc file (as is the case in the example above) you will probably need to update and resign the .changes file too; the devscripts package has tools to automate this (debsign(1)).

Rejected: GPG signature check failed on `foobar_0.7.0-1.dsc'.
gpg: Signature made Sat Feb  3 10:35:13 2001 EST using DSA key ID 03FEB4F3
gpg: Can't check signature: public key not found

Problem

The file in question was not signed with a key currently in the Debian GnuPG or PGP keyring (a requirement for both .changes and .dsc files).

Solution

Either resign the .dsc and/or .changes with a key in the keyring, or get the key in the keyring.

Notes

The canonical location of the Debian keyrings is keyring.debian.org which can be accessed via anonymous rsync. If your key is not in the keyring, you need to mail keyring-maint@debian.org; new keys can NOT be added via the keyserver on keyring.debian.org. If you are switching to GnuPG from PGP and your new GnuPG key is not yet in the keyring, consider using your PGP key until the GnuPG key is added.

Rejected: foobar_0.8.1-5_i386.deb: Old version `0.8.1-6' >= new version `0.8.1-5'.

Problem

Every new upload to the archive must have a greater version number than existing versions in the target suite (stable, unstable).

Solution

Increase the version number (with an epoch if necessary).

Notes

You must increase the version number; requests to override the version check will be refused. The reasoning behind this is simple: if the version number does not increase, tools like dpkg, apt and dselect will not see the package as new and will not update it. Epoch-hating has become unfortunately trendly over the last 5 years or so, but with very little technical justification. If there's no better way to increase the version number: Just epoch it.

Rejected: Unknown distribution `woody'.

Problem

You specified an invalid target suite (aka 'distribution').

Solution

Specify a valid distribution/suite and reupload.

Notes

Valid target suites are: 'stable', 'unstable' and 'experimental'. You can't upload to 'testing' as it's controlled by it's own scripts and does not accept direct uploads. If your package is not updating in testing, check the testing pages to see why. You can't upload to 'proposed-updates' directly, instead, upload to 'stable' and your package will be redirected to 'proposed-updates' automatically. Suite/distribution aliases (e.g. 'woody', 'potato') are not supported due to potential problems with their meaning changing between the time the source upload is done and the package is recompiled for some architecture.

Rejected: file 'bind9_9.1.0-2_i386.deb' has unknown component 'non-US/main'.

Problem

You specified an invalid component.

Solution

Specify a valid component and reupload.

Notes

The component is specified as a prefix to the section information in 'debian/control'. Valid components for uploads to ftp-master.debian.org are: 'main', 'contrib' and 'non-free'.

Rejected: freeradius-client_1.1.6-3.dsc refers to non-existing file: freeradius-client_1.1.6.orig.tar.gz.
Perhaps you need to include it in your upload?

Problem

You tried to upload a package, but its .orig.tar.* archive is not known in dak.

Solution

Rebuild your packge passing '-sa' to dpkg-buildpackage and reupload.

Notes

This usually happens when you upload a package which will end in NEW with a Debian revision different than -1. Make sure your .changes file has a line listing the .orig.tar.* archive.

[Much more to come, obviously...]