Uploading a package is the usual way to get your changes integrated in to Ubuntu if you have upload rights to the package. If you do not then you should use the sponsorship process.
It is also necessary to get your packages in to a PPA.
Signing the package
In order for your upload to be accepted by the archive maintenance software it must be signed by a GPG key that is associated with a launchpad account that has upload rights for the package.
The first step is to ensure that your key is associated with your launchpad account. For instructions on doing this refer to
The next step is to sign the package using your key. This is usually done using debsign from the devscripts package.
The first thing to note is that you upload source packages only to Ubuntu. The signature for this consists of two parts. The first is the signature on the .dsc file, which is the signature of the source package itself. The second is the signature on the _source.changes file, which is the signature of the upload.
Once you have a source package with an associated _source.changes file you can sign it by running
$ debsign foo_1.0-0ubuntu1_source.changes
This will take the Changed-By entry from the file, and ask GPG to sign the two parts with the key that has a UID matching that value. The UID must be byte-for-byte identical to the Changed-By value (including the key "comment"), so any changes in the name or email address (even down to whitespace) will cause the match to fail. If that happens then GPG will report that it can't find the needed secret key.
You can check the two things with these commands:
dpkg-parsechangelog | sed -n -e '/^Maintainer: /s/^Maintainer: //p'
will show what is entered in debian/changelog, and
will shows what UIDs are on your secret keys. Therefore if
gpg --list-secret-keys "$(dpkg-parsechangelog | sed -n -e '/^Maintainer: /s/^Maintainer: //p')"
prints nothing then you don't have the required secret key.
There are three ways to fix this:
Add a matching UID to the key associated with your launchpad account using gpg, or one of it's front-ends, such as seahorse.
Alter the Changed-By line to match a UID on the desired signing key. This is usually taken from the trailer line of the last changelog entry in debian/changelog when you build the source package, so change that and build again.
Instruct debsign to use the desired key by using the -k option. For instance if your key has the id D04F19E3 then you can run debsign -kD04F19E3 to make it use that key (note the absence of a space after -k). This is the correct way to use your key when signing a package changed by someone else, i.e. when Sponsoring an upload for someone else.
More efficient methods
If you are in the root of an unpacked source package of the source that you would like to upload (with the same version in debian/changelog then you can simply run debsign -S. This will sign the _source.changes file in the parent directory. This means it works for the default behavior of most tools to build a source package and saves you typing the filename.
debuild (also from devscripts) will invoke debsign after completing a successful build (and when not invoked with the -uc -us options). This is easier than running debsign yourself, and usually works well, as long as you don't sign the packages on a different machine from the one used to build them. debuild accepts the same -k argument to set the key id to use.
When sponsoring it becomes tedious to specify -k every time to sign someone else's changes. Instead of this you can specify the key to use in a config file. Simply create a ~/.devscripts file with contents similar to
One thing to note with this is that it will never look at Changed-By anymore, so it won't catch any typos in your name in debian/changelog, but that is rarely important.
Uploading with `dput`
dput is the most common way to upload source packages. It is installed by installing the package of the same name. It comes with a default configuration that knows about most upload targets. It is invoked by giving a target, and the name of the signed _source.changes file to upload.
$ dput ubuntu foo_1.0-0ubuntu1_source.changes
which will upload that source package to Ubuntu. You can see the other builtin targets in /etc/dput.cf.
Once you have uploaded you should shortly receive an email from launchpad telling you what it did with the upload. This will often be Accepted, but can be Awaiting approval during freezes, or New when the package is held in the NEW queue. The other common outcome is that the upload is Rejected, and the email should explain why.
In a few cases you won't get any email at all. The usual reason for this is that the upload wasn't correctly signed, so double check the signatures. If you see nothing wrong then ask for assistance. The launchpad team can usually dig in to the logs to find out the exact reason.
To upload to a PPA you can use the ppa target, and use the associated magic to specify which ppa you want. (This is only available in Jaunty and later. If you can't use it then you must create a stanza describing your PPA as described at https://help.launchpad.net/Packaging/PPA#Uploading)
$ dput ppa:lpid/ppa-name foo_1.0-0ubuntu1_source.changes
Avoiding uploading to the wrong place
dput actually allows you to upload without specifying a target, and uses a default, which is the ubuntu target on Ubuntu. This is rather unfortunate, as it means you can inadvertently upload to the wrong location, and have to deal with that. It becomes more of an annoyance for those with upload rights, as not specifying a target for your PPA upload would mean that it ended up in Ubuntu proper.
You can avoid this by defining your own default upload target that does nothing, quickly alerting you to the problem. To do this create a ~/.dput.cf with the following contents:
[DEFAULT] default_host_main = unspecified [unspecified] fqdn = SPECIFY.A.TARGET incoming = /
which would lead to the following if you didn't specify a target for your upload:
Upload package to host unspecified Checking Signature on .changes . . . Uploading to unspecified (via ftp to SPECIFY.A.TARGET): Connection failed, aborting. Check your network (-2, 'Name or service not known')