<> ||<>|| 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|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 https://help.launchpad.net/YourAccount/ImportingYourPGPKey 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 {{{ gpg --list-secret-keys }}} 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: 1. Add a matching UID to the key associated with your launchpad account using `gpg`, or one of it's front-ends, such as `seahorse`. 1. 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. 1. 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 [[../Sponsorship|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 {{{ DEBSIGN_KEYID=D04F19E3 }}} 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|freezes]], or `New` when the package is held in [[../NEW|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') }}} ---- CategoryProcess<
>CategoryUbuntuDevelopment