Package upload errors
Once you've made an upload either to your PPA or the official Ubuntu archive, Launchpad will send you a success or failure notice by email. If you do not receive a success or failure notice, please confirm that you have correctly signed your package.
You can check the status of your build by visiting on your PPA's build status page or the Ubuntu build queue, if you're producing official Ubuntu packages.
clearsign failed: secret key not available
If you get an error when signing the changes file (clearsign failed: secret key not available), pass an additional option -k[key_id] to debuild. You can use gpg --list-keys to get the key ID. Look for line similar to "pub 12345/12ABCDEF"; the key is the alphanumeric section after the forward slash.
Apparently successful upload followed by a rejection email
If you're uploading to a PPA, your upload may appear to succeed, followed by an email with the following:
Rejected: Signer has no upload rights at all to this distribution. Not permitted to upload to the RELEASE pocket in a series in the 'CURRENT' state.
This means that you forgot to specify your PPA's name on the command-line (that is, the "my-ppa" part) and dput sent your upload to the primary Ubuntu archive, for which you don't have authorisation. You can disable that behaviour by adding these lines to your ~/.dput.cf:
[DEFAULT] default_host_main = notspecified [notspecified] fqdn = SPECIFY.A.PPA.NAME incoming = .
Now, if you omit the PPA name you'll immediately get an error.
The rejection email may also say something like:
Rejected: File <UPLOADED_FILE> already exists in <LOCATION>, but uploaded version has different contents. See more information about this error in https://help.launchpad.net/Packaging/UploadErrors.
This mean you have uploaded a file that already exists in the pointed 'LOCATION' (your PPA or Ubuntu primary archive) but with different contents.
It usually happens for re-packaged orig.tar.gz. Gzip header includes a timestamp, resulting in files with different checksums for each individual compression step.
The solution for this problem consists of:
- downloading the pristine original tarball from the location pointed in the rejection message;
regenerate the source upload using it, debuild -S will do it, note that there is no need to include the original tarball in the upload, a reference to the right file will suffice;
reupload the just created source package as usual, dput <TARGET> <CHANGES>.
If you come across other errors when uploading a package to Launchpad, find us in #launchpad on Freenode or get in touch by email.