Differences between revisions 2 and 3
Revision 2 as of 2008-08-10 13:43:05
Size: 4008
Editor: 77
Revision 3 as of 2008-08-10 13:48:24
Size: 4020
Editor: 77
Deletions are marked like this. Additions are marked like this.
Line 39: Line 39:
If the package is in '''main''' or '''restricted''', you'll have to poke a [[|Core Developer] (you can find them in ''#ubuntu-devel''). If the package is in '''main''' or '''restricted''', you'll have to poke a [[|Core Developer]] (you can find them in ''#ubuntu-devel'').
Line 43: Line 43:
You can see the packages in the NEW queue on ''[[||<current_development_release>/+queue]]''. You can see the packages in the NEW queue on ''<current_development_release>/+queue'' ([[|link for intrepid]]).

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 that.

Uploading a package

This hasn't anything difficult - it's just like with REVU, but the Ubuntu Archive is dput's the 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.

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-universe-sponsors team, so that you can unsubscribe the team from bugs of which you've already taken care.

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> 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<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<current_development_release>/+queue (link for intrepid).

MOTU/New (last edited 2013-06-16 02:59:56 by mfisch)