Ubuntu Wiki

Introduction

There is only a limited amount of manpower to check packages, so please ensure that your packages are in top notch when you upload them, in order to minimize the number of review iterations necessary for each. Below you'll find a list of common packaging problems.

Common Problems

Listen to REVU

REVU will show some information on common problems at the top of the detail page. Further, it also provides the output of the "lintian" command. Ensure that both reports are clean, and also run lintian against the compiled .deb package(s) (REVU only runs it against the source package).

The changelog

Although it's a rather simple file, debian/changelog is frequently a source of errors. Remember that it should only have one entry (no PPA history!), with the version ending in -0ubuntu1, and that the distribution name must be that one of the current Ubuntu release (which is, right now, "oneiric"). Further, it's recommended that you open a "needs-packaging" bug in Launchpad for each package uploaded to REVU, so if you've opened such a bug you should link to it from the changelog using the following syntax: "(LP: #xxxxx)".

The control file

The Priority is set to "extra" by default, but this is almost never what you want. See the Debian Policy Manual for information on this field and adjust it to the correct value (usually "optional").

When you write the description think of what the package actually does, not who wrote it, what technologies were used for it or what it's history is. The website of the application goes into an "Homepage:" field in the source stanza, not in the description. Also remember that the short description should fit into a sentence like in "<package name> is a/an <short description>". Read the description twice after writing it to ensure that it makes sense and that there are no typos; also run it through some corrector to avoid spelling mistakes.

Build and installation

Check that the package builds in pbuilder, another chroot, or a PPA and that it can be installed, uninstalled and purged correctly. It's particularly important to check if the application works correctly after installing it from the package, and that there are no files missing in the .deb or that not unwanted files are present in it (you can check this with "dpkg-deb --contents <filename>.deb").

Documentation files

When you include documentation files from a tarball into the .deb, look at them and decide whether they are relevant to the end user of the package or not. Installation instructions and the like, are not.

The copyright file

Here we have it, debian/copyright. An innocent looking file which is likely to bring pain upon you :). Always check the upstream source carefully and list all authors, copyright assignments and licenses in debian/copyright. See this mailing list post for some recommendations on how to write the file.

Also note that the GPL License requires a copy of itself to be included in the tarball, but it's not uncommon for upstreams to forget about this. If you want to package something released under the GPL but the tarball doesn't include a complete copy of it, ask upstream to release a new one including it or, if you are in time pressure, do so yourself (and if you think that the author may still release some future versions without it, add a get-orig-source to debian/rules in order to make the tarball repackaging automatic).

What now?

As said before, packages are submitted at a faster rate than we can review them. So, don't get frustrated if your package gets ignored. Here are some tips to increase the chances of getting your package reviewed:

• Ensure that your package is in top notch (see the instructions above on this wiki page).

• Ask for review in #ubuntu-motu (but not more than two or three times a day, or you may annoy people). Always mention the package name, description, amount of advocates and the URL to the package; an example could be: "Hey, anyone up for reviewing foobar? It's a little application to foo bars. I've just uploaded a new candidate to fix all problems about which <previous MOTU> complained. http://revu.ubuntuwire.com/details.py?package=foobar". Creativity when writing this message gives extra points.

• There's a "REVU Day" every week, during which many MOTUs will focus on REVU. Stay around on #ubuntu-motu that day, as being able to talk to you about your packages will increase your odds of it being reviewed. Also see the previous point.
• Subscribe to e-mail notifications or to the Atom feed and answer promptly to any comment. If a reviewer gets interested in your package you'll want to keep him interested in it and show that you are a responsive contributor.

• If your package isn't reviewed in, let's say, two months, consider asking for review on ubuntu-motu@lists.ubuntu.com. Only do this as a last resort.

If you submit a package to REVU you're supposed to be interested in it and maintain it. Previous experience with bug fixing, merging/syncing and other tasks will show MOTUs your commitment to Ubuntu and may help in getting your package reviewed first.

Finally, remember that REVU is not the only way to get new packages into Ubuntu. You're highly encouraged to get them into Debian instead and then request a sync from there.