|Deletions are marked like this.||Additions are marked like this.|
|Line 53:||Line 53:|
|You can see the packages in the NEW queue on ''launchpad.net/ubuntu/<current_development_release>/+queue'' ([[https://launchpad.net/ubuntu/jaunty/+queue|link for jaunty]]). You can also view the unaccepted queue, which will show uploaded packages pending freeze approvals as release approaches.||You can see the packages in the NEW queue on ''launchpad.net/ubuntu/<current_development_release>/+queue'' ([[https://launchpad.net/ubuntu/saucy/+queue|link for saucy]]). You can also view the unaccepted queue, which will show uploaded packages pending freeze approvals as release approaches.|
Information for new MOTUs
This page documents some of the stuff which you have to know as a MOTU, but which isn't useful before you become one.
Uploading a package
This hasn't anything difficult - it's just like with a PPA, but the Ubuntu Archive is dput's default upload target, so you don't have to touch any configuration file; just do: dput <package_name>_<version>_source.changes.
Remember that if it's a new upstream version you'll have to include the .orig.tar.gz in the upload (debuild -S -sa), but if it's just a new revision then it shouldn't be uploaded again (debuild -S). Also note that you have to respect all active freezes.
Uploading a merge
When you upload a merge, you'll have to use the -v<version> argument with debuild. This argument will be passed to dpkg-genchanges and will cause the changelog information from all versions strictly later than the indicated version to be listed in the .changes file. Always use the last Ubuntu version in the changelog as the argument to -v. Alternatively, you use merge-debuild if you get packages from grab-merge
Sponsoring someone else's work
Ubuntu's archive recognizes the uploader checking the key with which the .changes file has been signed with; if that key isn't in the keyring, the upload will be rejected. Because of that, when you sponsor a package you'll have to sign it with your key, so you'll have to use the -k<your_email_address> option with debuild.
If you want to modify something in the package, you can do so, but if the changes are important add an entry to debian/changelog stating that it's you who has done them. Remember that if you use dch that will change the signature in the last entry to yours; you'll want to consider the amount of work you and the other contributor have done, and decide if you really want to change that line or not (having a nice uploaded packages list is more important for the new contributor).
If you plan to sponsor packages frequently consider joining the ubuntu-sponsors team, so that you can unsubscribe the team from bugs of which you've already taken care.
Sponsoring sync request
syncpackage -d <debian-distribution> -r <ubuntu-release> -b <XXXX> -s $SPONSOR $PACKAGE
You can use --force to ignoring Ubuntu changes, of course if Ubuntu changes has been applied in Debian.
Forwarding changes to Debian
It's important that new contributors learn that forwarding their changes to Debian is important. After you sponsor an upload which contains something relevant to Debian:
It's a good idea to check if the same bug has been reported in Debian's BTS and if so link it to the Launchpad bug and send an email to <debian_bugnumber>@bugs.debian.org explaining that there's a fix available in Ubuntu; if there isn't one, create it. Finally, leave a comment explaining to the contributor what you have done and asking him to do that the next time.
- Alternatively, just ask the contributor to do that himself.
Handling transient build failures
Sometimes it happens that a package Fails To Build From Source on a certain architecture because some of its dependencies haven't been build for it yet. In this case, you can requested a give-back (that is, a rebuild without a new source upload).
To do that, go to launchpad.net/ubuntu/+source/<source_package>, click on the version number which failed to build, click on the desired architecture on the "Builds" section and there click the "retry" link and press the confirmation button.
If the package is in main or restricted, you'll have to poke a Core Developer (you can find them in #ubuntu-devel).
Checking package's status
You can see the packages in the NEW queue on launchpad.net/ubuntu/<current_development_release>/+queue (link for saucy). You can also view the unaccepted queue, which will show uploaded packages pending freeze approvals as release approaches.
By default, if you do not specify a host when using dput in Ubuntu, it will attempt to upload to the official repositories. If you are not a MOTU, and you try to upload a package, it will fail. It will also fail if you are not a core-dev, and you try to upload a package that is in Main/Restricted. This prevents unauthorized people from uploading to the repositories.
Once you are a MOTU, you no longer have this protection. As a result, if you accidentally use dput to upload a package without specifying a host, it will be uploaded to the repositories. This often leads to unintended uploads. It is strongly recommended that you modify your /etc/dput.cf file so that it uploads to a host that does not exist by default. That way, you are required to specify the host every time you use dput to upload. This can be done by changing the line in the [DEFAULT] section that says "default_host_main = ubuntu" to say something like "default_host_main = SPECIFY_A_HOST".
Now, create a [SPECIFY_A_HOST] section, and add two lines that look like this: "fqdn = null" and "incoming = "null". Now, if you try to upload a package without specifying a host, it will fail with the message "Uploading to SPECIFY_A_HOST (via ftp to null): Connection failed, aborting. Check your network (-2, 'Name or service not known')". You can upload to the repositories by specifying the host: dput ubuntu foo-X.Y-ZubuntuN_source.changes