Kilian Krause

Email: <kilian AT debian DOT org>

IRC: kilian (most large IRC networks)

Debian Developer information

Debian Mentors

Derived from the good ideas at DebianMentorsNet and inspired by Joey's existing debreview script, I've enhanced my version based on his. It can be found here.

My requirements for sponsoring a package are (generally at least) the following:

  1. You have a working debian/watch pointing to the correct upstream website to verify your upstream tarball
  2. Your orig.tar.{gz,bz2,xz,lzma} is ""exactly"" what upstream has on their site ""unless"" you do a DFSG-repack (or repack due to any other sensible reason)
  3. In case you repack, the procedure is documented in either README.source or debian/rules get-orig-source target
  4. Your packages does follow latest Debian standards and preferably does not use CDBS, this includes:
    • debhelper should be latest (currently 8)
    • dpkg source format 3.0 or at least 1.0
    • Your package does not alter any files outside debian/ directly but uses patches (please insert header with description - even if not DEP-3 please follow quilt/dpatch best pratices)
    • debian/copyright should be DEP-5
  5. If you package an update to an existing Debian package, please note clearly so in the email to the debian-mentors mailing list
  6. Any patches that are not absolutely Debian specific should be sent upstream and marked as such
  7. Your package follows the best practice recommendations

  8. Your package builds fine in pbuilder on at least one of the official Debian arches
  9. If remotely possible, make your clean target fail gracefully if build-deps are not installed (outside pbuilder)
  10. Please clean out any unneeded Build-Depends and Depends. Make sure to use the full potential of the apt-get/aptitude/dpkg magic instead of scripting hard references into your debian/control.
  11. If not otherwise possible, you may consider dh-autoreconf an option. If you seriously can't work around it please put a note why this is required and preferred over any other solution to the problem.
  12. Make sure your programs run, your libs have and use a test case (if available - if not ask upstream to add one)
  13. If your package is a shared library consider adding a symbols file and a dbg package
  14. Run your package past "lintian -F" and "lintian -IE --pedantic" (make sure to use unstable version of lintian). If the former still spits out lines, fix those first. If the latter spits out lines, consider fixing them first before uploading. Be assured, I will look at them!
  15. Use FHS paths for your package.

Good coding style and aesthetically good-looking packages are a plus. They simplify my review and thus speed up your chances that I'll process it fast and not toss it back into my TODO queue.

If you're agreed to subject your package to the above requirements you can also submit the *.dsc directly to me (or just put it to the general list for public review).

To also give you a more in depth insight on what happens after you submit your packages to review, I'll list my general procedure below.

Basically my review procedure follows this pattern:

  1. If the package is not a new upload to Debian, check debdiff against the last version
  2. Proofread debian/* to get a first impression
  3. Eventually more proofreading the source etc. (depends on the package)
  4. Build the package with pbuilder in unstable chroot
  5. Run my debreview -d (and optionally -f if upstream source changes aren't too large)

  6. If ok, sign, upload. If not, comment on debian-mentors@lists.d.o