1. The debian-mentors FAQ
    1. General questions
      1. What is the debian-mentors mailing list for?
      2. I want to help Debian. Tell me what I can do.
      3. What's the process of becoming a Debian Developer?
      4. What other resources are there for new and prospective Developers?
      5. How do I adopt an existing package?
      6. What can I do to help Debian other than packaging?
    2. Packaging
      1. How do I make my first package?
      2. How do I add a new package to the archive?
      3. How do I effectively keep track of my packaging changes?
      4. What is the difference between a native Debian package and a non-native package?
      5. What's wrong with upstream shipping a debian/ directory?
      6. What does “dfsg” or “ds” in the version string mean?
      7. How do I create debian/watch for downloading from GitHub?
      8. How do I update user's configuration in /home/... ?
      9. How do I list the content of a package
      10. How do I find out who uploaded the <package_x>?
      11. Is it OK to edit old changelog entries?
      12. How do I install a package from
    3. Sponsored Packages
      1. What's a sponsor, why do I want one, and how do I get one?
      2. What's the difference between a sponsor and an advocate?
      3. So how do I get an advocate then?
      4. How do I get a sponsor for my package?
      5. But why should I waste time packaging if there's no guarantee it's going to be uploaded?
      6. Where else can I get a sponsor?
      7. What happens if I can't find a sponsor?
      8. Why is it so hard to find a sponsor?
    4. Infrastructure Projects
    5. For Sponsors...
      1. Who can sponsor a package?
      2. What is the process for sponsoring a package?
      3. What about recurring sponsorship of the same package?
      4. What if I upload a package, and then my mentee disappears?
      5. What resources are there for sponsors and prospective sponsors?

The debian-mentors FAQ

This FAQ is intended to head off the standard set of questions asked by a large proportion of new posters to the debian-mentors mailing list. There are five sections:

If in doubt, just read the whole thing. If you still have your question, ask on the debian-mentors list.

General questions

What is the debian-mentors mailing list for?

debian-mentors is for the mentoring of new and prospective Debian maintainers, as well as contributors to Debian infrastructure. Almost any question relating to Debian development is potentially on-topic for d-mentors. Although there are other lists which deal with most aspects of developing for Debian, they're often pretty hard core and can be daunting. If you think your question might be a little "newbie" for the hardcore developers on debian-devel or infrastructure team lists, then it's probably a good fit for debian-mentors.

In short, we aim to be the "softer, gentler" Debian development forum.

One of the most common uses for the list is to seek someone to sponsor a package you have created (or are intending to create). It's such a common request that it has its own section in this FAQ.

Things that aren't really appropriate for the debian-mentors forum:

I want to help Debian. Tell me what I can do.

This is a very difficult question to respond to, because there's so many different things that could be done, and we don't know what you're really interested in doing. Particular problems include:

If you really are keen on getting involved in random places in Debian, there are lots of resources in the question "What can I do to help Debian other than packaging?", below.

What's the process of becoming a Debian Developer?

The perennial question. As provided by Andreas Metzler (I couldn't have put it better myself, so why bother trying?):

  1. Package stuff. See How do I make my first package? for more details on that aspect of the process.

  2. Find a DD who checks and uploads your shiny new package for you, this is called "sponsoring" an upload. Your name is still in the Maintainer: field of the package, so you are still responsible for keeping it in good order.
  3. Keep the package in shape, fix bugs, make new uploads with your sponsor.
  4. Decide whether you want to become a DD and do more work for Debian. If not, just continue with (3).
  5. So you want to become a DD. ;-) First thing you need is a DD who testifies for you, i.e. basically has the opinion that you are doing good work and would like you to become a DD. This is called "advocate". As they have to have some idea _what_ you did it is not sensible to just ask on debian-mentors for an advocate. It has to be somebody who has worked together with you, the DD who previously acted as your sponsor is a natural choice. Once you have an advocate you can start the NM-process.

What other resources are there for new and prospective Developers?

Apart from the debian-mentors mailing list, there are a wealth of useful places and documents which the aspiring developer can use to improve themselves:

How do I adopt an existing package?


What can I do to help Debian other than packaging?

Excellent question! Debian is a lot more than a great big collection of random packages. There's documentation to write and translate, bugs to fix, installers to test, and newbies to harass^H^H^H^H^H, uh, help. Besides, running and developing the Debian infrastructure also takes a lot of work. Projects like ? (our bug tracking system), (which runs our package archive) and many more would love to see new contributors. See the section Infrastructure Projects below for more information on how to contribute to Debian infrastructure projects.

If you write a language other than English fairly well (either because you're a native speaker or you've spent the time to learn) then consider helping out with translations. Everything in Debian needs to be translated, more or less - package descriptions, debconf questions, all of our documentation, etc. There are a lot of clever people involved there - be one of them! Translation work is mostly handled through Most translation projects can be found from there.

There are many thousand open bugs in Debian packages, ranging from the trivial to the critical. Consider looking in the Bug Tracking System for packages that you use often. Try and reproduce a bug, or find the cause of the bug and submit a patch to the bug listing, so that the maintainer can fix the bug. If a bug has one or more patches that haven't been applied in a long time, especially for more serious bugs, and the maintainer hasn't commented, consider bringing the package to the attention of the Quality Assurance team ( so they can have a look at it. You can find Release Critical bugs for packages installed on your system (in case you might like to help fix them) by running the rc-alert script, which is available in the devscripts package.

Some maintainers have requested some help with their packages, by posting a Request For Help (RFH) on the Work-needing and Prospective Packages list ( A list of current requests for help posted by other people is available from, in case you're feeling helpful.

If you're interested in helping to fix a bug, there is a list of bugs that have been identified by package maintainers as fairly simple, and good to improve your skills on. For more information, see wiki page about the tag.


How do I make my first package?

Firstly, you may not necessarily have to package something from scratch.

Consider the benefits of co-maintenance. Instead of having to be out on your own, you get a pre-existing, presumably fairly well-maintained package, and someone to answer your questions.

There are quite a number of packages already in the Debian archives which are orphaned - that is, their previous maintainers have given up maintenance of the package for various reasons. The best option, especially for your first packaging attempt, is to adopt one of these orphans. There are also some packages which are still maintained, but which aren't really wanted by their maintainers any more (known as "RFA" packages, for "Request For Adoption").

The benefits of an RFA package are that you have at least one person who might be willing to sponsor your uploads, and you'll have someone familiar with the package who you can ask any questions you have with the packaging.

To find a package to adopt, look for bugs whose title starts with "O:" (for orphaned) or "RFA:" (for "Request for Adoption") under the WNPP bug list (or at the alternative interface). A more convenient method of finding interesting orphans is to install the devscripts package and run wnpp-alert. This will print out all the packages installed on the system you're running which are orphaned. Handy!

For "Request For Adoption" packages, you should contact the current maintainer and ask if they'd be willing to let you maintain it. Some maintainers may be unwilling to let their package go to an inexperienced maintainer for some reason. Please respect their judgement -- they usually have a good reason for not wanting to hand the package off to someone without experience. Also remember to ask the previous maintainer if they might be willing to sponsor your uploads.

Once you've selected a package to adopt, retitle the WNPP bug so it starts with "ITA:" (for Intent To Adopt) and start working on the package. Fix bugs, package new versions, and hunt for a sponsor for your new package. Remember to set the maintainer to you, and to close the WNPP bug in the changelog of your first upload.

Another place to look for packages is in packages which may not be listed as orphaned, but which are in a bad state. This is not something to take on lightly, as what constitutes "in a bad state" may not be immediately obvious. Nevertheless, if there's a program you use which you think is looking a bit shabby and might benefit from a new maintainer (you!) bring it to d-mentors or the debian-qa mailing list with your reasoning, and someone will try and help you out. Please Note: Don't go e-mailing maintainers with e-mails like "Your package looks unmaintained, I'm going to hijack your package". It helps nobody, and ensures that you will have at least one very unhappy Debian developer.

If you've got your eye on something new to package, there is a set procedure to follow. This is covered heavily elsewhere, including the New Maintainers' Guide, but basically:

  1. Pick something to package not already in the archive, and not listed as an ITP (Intent To Package) on the WNPP bugs page. If it's listed as RFP (Request For Package) then you'll be satisfying someone else's desire for a package, so you're doing extra-special good. <grin>

  2. If it's not already listed, file an ITP bug report against WNPP as detailed by section 5.1 of the developer's reference. If it's already listed as an RFP, retitle the bug as an ITP (see the BTS manipulation manual).

  3. Put a package together, built against a current version of sid. This simple sentence hides a multitude of sins -- it can be a complex process. Debian Policy and the Developers' Reference are the "bibles" of packaging, however the New Maintainers' Guide contains a more gentle introduction to the sport. The Debian Wiki also contains a basic How To Package For Debian guide, while the Debian Women project has produced a Packaging Tutorial.

  4. Provide a publicly accessible place where all of the files relating to your package can be downloaded from. This includes both the source package (.orig.tar.gz, diff, and .dsc), and the corresponding binary package(s), including the .changes file (signed, preferably). There is a "pretend" upload queue at which can be used to host packages if you have nowhere better to put them.

  5. Request a sponsor from debian-mentors, and possibly other places.

  6. Keep your package maintained after the initial upload, by being responsive to bug reports and new upstream versions.

It is also recommended that you familiarise yourself early on with the Debian Developer's Reference and the Debian Policy, which are, respectively, the HOWTO and Do's and Don'ts (that's some ugly apostrophes) of packaging for Debian. You will need to know all about them if you apply to become a DD, so you should start studying now... <grin>

How do I add a new package to the archive?

  1. Get interested in a package by using or developing it.
  2. Discover that it isn't already available from the Debian archive.
  3. Check if it can be packaged (licence, etc) and if it is already being packaged by someone else (via ITPs on

  4. Review whether you can reasonably maintain this package. This includes the complexity of the package and your skill level, whether you're familiar with the programming language(s) used, and also whether upstream is active and you can expect reasonable support from them in bug-fixing and helping to handle bugs from Debian users.
  5. File an ITP (intent to package) bug using reportbug (or the bug reporting e-mail address) against the wnpp package. This is done to prevent duplication of work, and is an essential step.

  6. Create the package, getting help from the various resources listed in this FAQ and elsewhere.
  7. Install and test your package thoroughly. Ask on the debian-mentors mailing list for people to check your packaging for errors and common problems.

  8. If you're a DD already, you can just upload your package. Otherwise, upload your package somewhere that prospective sponsors can review it (such as, and then find a sponsor to upload the package into the Debian archive for you.

  9. Once you get your package sponsored, please tell the debian-mentors mailing list if you asked for sponsorship there, so that other prospective sponsors don't waste time reviewing your package and getting it ready for upload when it's already been uploaded. That way they can go on and upload someone else's package. This goes for any other places you asked for sponsorship, like other lists, IRC channels, etc -- let everyone know you got a sponsor, so we don't duplicate effort.

How do I effectively keep track of my packaging changes?

At the basic level, it's a good idea to keep an archive of the completed source packages that get uploaded. Although there are services which keep a record of everything in the archive (such as there's the hassle of having to go and retrieve your packages from there, and there's no guarantee that external services will always have old copies of your package available. A local copy is just that much easier and more reliable to work with. The debdiff and interdiff programs (in the devscripts and patchutils packages) can help you look at the differences between package versions.

Getting into a more fine-grained approach, consider using a revision control system to store all of the changes you make to your packages. There are *-buildpackage scripts for several of the more popular revision control systems (cvs, svn, darcs, and arch), which will retrieve your package out of revision control and build it for you automatically.

What is the difference between a native Debian package and a non-native package?

(From Matthijs Mohlmann, with additions by Thijs Kinkhorst)

  1. When to use a native vs a non-native package

    • Default to making packages non-native. They are the regular ones. You should only use a native Debian package when it is clear that the package would not be useful outside the context of a Debian system, and would never be distributed except packaged for Debian or its derivatives. Even if the software is currently only available in Debian, if someone could reasonably use the software on another distribution or on another operating system, then the package should be non-native. A few examples of normal (non-native) packages are: libc6, apache, phpmyadmin. And tools like lintian, dpkg and some others are purely developed for Debian, and make no sense being released in another distribution; these belong in native Debian packages.
  2. Non-Native Debian Package

    • A non-native/regular/common/normal Debian source package contains: a source control file (foo-version.dsc), the Debian packaging files (in a foo-version.diff.gz or foo-version.debian.tar.$comp file), and one or more upstream source tarballs (foo-version.orig.tar.gz) file.
    • The version for a non-native Debian package looks like UpstreamVersion-DebianVersion for example: 2.8-1.

    • In the diff.gz/debian.tar.$comp: These are the modifications you made to the package. It contains the debian/ directory and the modifications you made to the source tree, if any.

    • The upstream source tarball (foo-version.orig.tar.gz): You should only rarely make changes to this file, and you should never ever make changes unless you explicitly understand why you are making them. All changes should normally go into the Debian packaging (foo-version.diff.gz).
    • Consider using the "3.0 (quilt)" format as it cannot mistakenly create a native package (instead of "1.0", which can be either). See man dpkg-source for more information.

  3. Native Debian Package

    • The Version number for a Debian native package is only the version, it doesn't have a Debian release number. For example, 2.8. A native package consists of only a source control file (foo-version.dsc) and an upstream source tarball (foo-version.tar.gz). The disadvantage of a native package is that there is no clear separation between "upstream code" and "Debian changes". This means that it is harder to separate out patches that should be sent upstream, and unnecessarily muddies the waters of who is responsible for what. Additionally, a native package requires a whole new upstream source tarball to be created whenever there are packaging changes (which wastes bandwidth and mirror space), while a non-native package only requires the upload of a new Debian packaging file, which is typically much smaller.

      Native Debian packages are often accidentally built when the upstream source tarball (foo-version.orig.tar.gz) is named incorrectly. It should always be named <sourcepkg>_<upstreamversion>.orig.tar.<comp>, where sourcepkg is the upstream name of the package, upstreamversion is the upstream version string, and .comp is the suffix for the compression applied to the tarball (typically .gz or .xz).

What's wrong with upstream shipping a debian/ directory?

(This section is only for source packages using the "1.0" format. For non-native packages using "3.0 (quilt)", the upstream debian/ directory is not an issue except taking a bit of extra space. Please see man dpkg-source for more information about source formats)

There are cases where upstream ships a tarball which already contains a debian/ directory. This is undesirable, even if you're upstream yourself or can commit there. Keep the debian/ directory separated from the released tarballs (used as .orig.tar.gz).

The problem is that at some point, upstream's debian/ directory will deviate from the one in the Debian package -- because the maintainer changes, the directory was already outdated, or someone does an NMU or a security upload. The .diff.gz will now be a diff between the two debian/ dirs, which is very confusing.

The Debian package format is designed to keep upstream and Debian-specific neatly separated into orig.tar.gz and .diff.gz. Putting the debian/ dir in the upstream source tarball confuses this.

If upstream has a debian/ directory in their releases, you should contact them and ask if they can remove the debian/ directory from their tarball releases. There's no need to remove the debian/ directory from their revision control system (although if it's out of date they may decide to do so anyway), but at the very least the directory shouldn't appear in releases. If you are upstream yourself, well, you can ask yourself to do it.

What does “dfsg” or “ds” in the version string mean?

“+dfsg.N” and “+ds.N“ are a conventional way of extending a version string, when the Debian package's upstream source tarball is actually different from the source released upstream. The former is used when upstream's source release contains elements that do not satisfy the Debian Free Software Guildelines (DFSG) and hence may not be distributed as source in the Debian system, the latter (standing for “Debian Source”) is used when the modification are for other non-DFSG reasons.

The changes should be documented in README.source.

The recommended way of forming the version string of a package re-packed for DFSG reasons is “<UPSTREAM_VERSION>+dfsg.<REPACK_COUNT>-<DEBIAN_RELEASE>”, otherwise use “<UPSTREAM_VERSION>+ds.<REPACK_COUNT>-<DEBIAN_RELEASE>”

For example: I am working on a package “abc” which has just been released upstream with version “1.2.3”. This is the first Debian release of this version. Normally the package version would be “1.2.3-1”, and my current packaging reflects this. I have then discovered that the package contains some files that do not conform to the DFSG. I now remove them from the source package by making a new “upstream tarball”, abc-1.2.3+dfsg.1.orig.tar.gz, and release a new package, “abc” version “1.2.3+dfsg.1-1” — the first Debian release (“-1”) of the first DFSG-repack (“+dfsg.1”) of upstream source version “1.2.3”. Later on, I find even more files in version “1.2.3” that should be removed. I do that and release “abc” version “1.2.3+dfsg.2-1” — the first Debian release (“-1”) of the second DFSG-repack (“+dfsg.2”) of upstream version “1.2.3”.

How do I create debian/watch for downloading from GitHub?

For GitHub based projects, you can use the tags or releases page. The archive URL uses only the version as the filename. You can rename the downloaded upstream tarball from into the standard <project>-<version>.tar.gz using filenamemangle. An example debian/watch entry for GitHub:

opts="filenamemangle=s%(?:.*?)?v?(\d[\d.]*)\.tar\.gz%<project>-$1.tar.gz%" \<user>/<project>/tags \
  (?:.*?/)?v?(\d[\d.]*)\.tar\.gz debian uupdate

Note that the "tags" downloads do not include Git submodules in the .tar.gz whilst the "releases" do.

For more examples see the uscan manual.

How do I update user's configuration in /home/... ?

The short answer is: do not do it - your package should not be updating any files in /home/*, see debian-mentors thread and Debian Policy entry.

How do I list the content of a package

List files of an installed package

 dpkg -L <package-name>

List files of a downloaded package

 apt-get download <package-name>
 dpkg-deb -c <package-name.deb>

List files of a package without downloading it

 apt-get install apt-file
 apt-file update
 apt-file list <package-name>

How do I find out who uploaded the <package_x>?

 who-uploads package_x

Is it OK to edit old changelog entries?

You should refrain from doing so but if you have a good reason for editing it, go ahead. See the discussion at

How do I install a package from

First of all, it is not recommended to install packages from These packages have not officially been accepted in the Debian repository and could contain harmful code.

If you are sure that the package is clean and still wish to install it, here is how to do it:

1. Make sure you have the devscripts package installed. It contains the necessary tools to continue:

 apt-get install devscripts

2. Use 'dget' to download the source code. More infos in dget

 dget [link to the .dsc file]

If it is the first time you install a package from mentor, you are likely to get an error from dscverify saying that the OpenPGP signature check has failed. To fix this, you need to tell dscverify that it is ok to use your personal OpenPGP keyring and then download the author's OpenPGP public key:

 cp /etc/devscripts.conf ~/.devscripts

In ~/.devscripts, you will need to activate the option DSCVERIFY_KEYRINGS="" and specify your OpenPGP keyring location. Ex: DSCVERIFY_KEYRINGS="~/.gnupg/pubring.gpg"

 gpg --keyserver --recv-keys [author's key id]

Then, run dget again.

3. cd into the directory that has been created

 cd [/path/to/extracted/package]

4. Build the source into a .deb file

 debuild -us -uc

5. In super user, install the package with dpkg

 dpkg -i [package name].deb

If dpkg outputs an error message about dependencies, install the missing ones and run the command again. Note that only steps 1 and 5 should be run as super user.

What's a sponsor, why do I want one, and how do I get one?

A sponsor is a registered Debian Developer (DD) who takes the packages of a non-DD and uploads them to the archive on the non-DD's behalf. The sponsor is required to check the quality of the package, that there are no show-stopping bugs in it, and that it is unlikely to harm either the Debian infrastructure during build, nor user's systems when in use.

The sponsor needs to do all of this because they are ultimately responsible for what gets uploaded by them into the archive.

You need a sponsor because, as a non-DD, you do not have the ability to upload packages directly into the Debian archive. So, you need to route your packages through a sponsoring DD so they can be properly signed and uploaded.

The presence of the sponsor doesn't mean you can neglect your maintainership duties. You are listed as the maintainer - it's your reputation on the line too. You are expected to keep a handle on bugs and new upstream versions, feed information from Debian users back to upstream, and generally uphold Debian's reputation. If you "dump" poor quality packages on sponsors, or do not maintain your packages well, do not expect to get many people willing to sponsor you.

<yoda>Scared? You will be...</yoda>

What's the difference between a sponsor and an advocate?

A sponsor is any Debian Developer willing to upload packages on your behalf into the Debian archive. You may have multiple people who act as sponsors for your packages - different people for different types of packages, or maybe you change sponsors over time, or rotate between a few (with the knowledge of all of them) to spread the load.

An advocate is a Debian Developer who has worked with you in your capacity as a contributor to Debian, and believes you would be an asset to Debian. When you are ready to apply for New Maintainership, the advocate makes a statement to the effect that they believe you would be a worthwhile addition to Debian, and your application moves forward. Without an advocate, your application cannot proceed.

There is no point asking for an advocate on debian-mentors or any other open mailing list. No developer should be willing to advocate for you without knowing something about you.

So how do I get an advocate then?

Which Debian Developers have you done Debian-related work with? Typically, if you're ready for NM, you should have worked with at least one, if not several. Ask them. If you've done good work, they should be more than happy to say that to the Front Desk via an advocacy. Get them to ask on debian-mentors if they're not sure exactly what advocacy is, when it should be done, and how.

One of your sponsors can be your advocate, and this would probably be the most common way of obtaining an advocate. But if you've had significant contact with any other DD, you can consider asking them.

How do I get a sponsor for my package?

First, be aware there is no guarantee that anyone will sponsor your package. It all depends on the interest level and time available from any prospective sponsor.

You should file a “Request For Sponsor” (RFS) bug report in the Debian BTS. The “sponsorship-requests” pseudo-package in the Debian bug tracking system is designed for receiving these requests. See the instructions on filing a correct RFS. That will lead you through the steps to create an informative, concise request for a sponsor.

Messages in other forums, or without all the information, are far more likely to be ignored.

Your RFS message is like an ad for your package. It's likely to be the only thing that prospective sponsors will judge your package on. You can have all the extra URLs you like in there where sponsors can get more information, but unless your initial message piques their interest, they'll never look at them.

So, tell us what exactly your package does, and why it should be in Debian. If there is already a program that does a similar thing, say why your one is better. Put a little "hot spice" in there to hold people's interest. in other words, think like an advertising executive. Just remember to wash the slime off afterward.

You'll notice that one of the things to have is where the package can be downloaded from. That implies that you've packaged it already. If you need help with packaging, ask for that, but don't bother asking for a sponsor until you've got the source package (more-or-less) ready for a sponsor to download and build.

Sponsoring a package takes a lot more than just downloading it from your website and uploading it to Debian. The prospective sponsor needs to check over the quality of the packaging and ensure that it meets Debian's quality standards before uploading it. For this reason, you need to provide all of the parts which would be needed for a source package upload (the changes file foo.changes, the source control file foo.dsc, the upstream source foo.orig.tar.gz, the Debian packaging patch foo.diff.gz). Also, it may take a few days/weeks to get the whole package checked over, and the sponsor might want to talk to you a bit, just to find out what sort of a person you are.

Think of all this as a smaller-scale New Member check - which is, basically, what it is.

But why should I waste time packaging if there's no guarantee it's going to be uploaded?

You shouldn't be generating a first package "just to get it in Debian". The archive is already well-stocked with poorly-maintained vanity packages. A first package, especially, should be something that you really want to see in Debian but which hasn't been uploaded already for whatever reason. That personal interest will help keep your interest levels up.

It is important to remember that an upload isn't a one-off thing - you're responsible for that package forevermore, unless you request its removal or find another suitably qualified person to maintain it for you. It's like having a child - a big responsibility.

Where else can I get a sponsor?

debian-mentors isn't the only place where you can get a sponsor. In general, you're more likely to get a sponsor who is actually interested in what you've packaged, but doesn't have time to package it themselves. So, if there's a list dedicated to your "niche market", send the RFS there. For RFS bugs, use the X-Debbugs-CC field in the pseudo-header. For plain RFS mails, CC the address. For instance, if you're packaging Yet Another Perl Module, try If it's YAPython Module, d-python@l.d.o. Apache module? Something legal-related? d-lex@l.d.o. Something for kids? d-edu@l.d.o. Getting the picture yet? There's a pretty comprehensive list of teams elsewhere on the wiki. Teams may sometimes request that they become the Maintainer for your package. Don't worry if this is the case --- it just means that they are interested in helping you out. They may also request that you adopt the team's workflow for the package, for example storing the packaging in some VCS. Again, don't worry. Team members should help you get everything straight and having packages organised in the same way makes maintenance easier.

Also, if you're packaging something in a particular technological line, you'll probably want to be subscribed to the relevant speciality mailing list anyway, so you can ask technology-specific questions to the people who know all about it.

What happens if I can't find a sponsor?

First off, don't panic. Not having your package in Debian immediately isn't the end of the world.

Solicit comments on the packaging on IRC and d-mentors. Don't just mention the package name, also provide (at least) the brief description. Typically a developer is more likely to sponsor something they might be interested in using, or which they recognise there might be a need for. Just the package name doesn't really convey the sort of information needed to make that call.

Sometimes RFS' fall through the cracks, so continue updating the package. Mention the package on d-mentors every month or two; people come and go, and their available time varies, so a later mention may catch someone who couldn't help you before.

Meet some Debian folk in your area or at DebConf and convince them to sponsor you :) It's a lot easier for someone to commit some time to helping you if they've got a face and real personality to put to the e-mail address (plus it's a great excuse to get some keysigning action happening).

Increase the quality of your package. Check it against various checklists. Check it with various automatic tools like lintian. Look at the PTS page for your package and at the links on that page. See SponsorChecklist, LucaFalavigna/NEWChecklist, reject FAQ, HowToPackageForDebian#Check_points_for_any_package,intro reviewers.

Fix lots of bugs, get involved in doing QA work. Do reviews for other folks looking for sponsorship and ask them to review your package in return. Perhaps you will get to know a DD well enough that they will sponsor you.

Why is it so hard to find a sponsor?


There are not enough Debian contributors to package every piece of software nor enough Debian members to sponsor every package made by Debian contributors. This has always been the case and always will be the case, there is just so much free software out there and probably many more Debian contributors than Debian members.


Sponsorship is hard work and is a large time investment. Some Debian members might not have enough "Debian time" to do it at all and others might prefer to spend their time on doing work that they signed up to do, like maintain infrastructure or packages they are a maintainer for.


Debian contributors generally work on stuff they use or are otherwise interested in. This can limit the scope of software that gets sponsored. With well-functioning teams, it can also mean that software for a specific area is well covered with sponsorship, DebianMed is a good example. Unfortunately this can mean there are no sponsors for particular areas.


Different folks have different packaging preferences, some like cdbs, some debhelper, some dh, some yada. Your packaging choices will in part reduce the set of folks who will have experience with and willingness to sponsor your package. There are folks and teams who do not do sponsorship, but have a strong emphasis on collaboration and instead do co-maintenance or team maintenance.


Sponsors take responsibility for your upload. Some folks might not want to take this responsibility on, if they didn't check the upload quite well enough and later it was discovered to contain malicious or buggy code, it would be their fault. This scares some people away from doing sponsorship. Some folks are scared of uploading new packages in case it turns out the contributor will disappear after one upload.


In the past we had pretty poor ways of matching packages to be sponsored with potential sponsors based on the above criteria. This is improving with the new developments in mentors.d.n but still needs work.


Sponsorship wasn't emphasised quite as much as other activities in Debian, so less folks considered taking it on at all. This may have changed already or perhaps we need to adjust our new-member documents.

Infrastructure Projects

Debian-mentors explicitly endorses questions about Debian infrastructure projects. We're more than happy to help new contributors with navigating through our infrastructure projects.

Some context: In order to run a project as big as Debian, a lot of infrastructure work is needed. Often, the Debian infrastructure teams had to write custom software for running our infrastructure as no Free Software solution existed beforehand. These software projects need to be maintained, tested, improved and further developed and usually the relevant teams are more than happy to introduce new contributors.

Still, many of our infrastructure teams are chronically understaffed and over-worked, which might lead to brevity and long delays when responding to comprehension questions by new contributors.

If you're interested in contributing to one of our infrastructure projects or have questions about their mode of operation, don't hesitate to ask on debian-mentors.

Some examples of Debian infrastructure projects:

For Sponsors...

Who can sponsor a package?

Any Debian Developer with a key in the keyring can sponsor a package on behalf of another maintainer. There is no special "register" of sponsors. Note that sponsorship is rarely a one-off event; you need to be able to handle regular uploads on behalf of your "sponsee". If you can only do a once-off upload, make your prospective sponsee aware of this up-front, and try to find someone else who will be able to continue the sponsorship process in the future if required.

What is the process for sponsoring a package?

You should first, of course, find a package to sponsor., the d-mentors list and IRC channel, are all good places to find packages.

You need to get the *source* package from your sponsee. That is, the .dsc, .orig.tar.gz, and .diff.gz. You should check the package over carefully, perhaps with reference to this page. If there are problems, provide constructive feedback to the sponsee. Work with them to make the package the best it can be. Build the package on your system, try it out -- does it install/remove properly, does the program run, is it policy compliant? All of the things you're supposed to do for your own packages. Yes, it's a lot of work, but you're responsible for any crud that lands in the archive under your key.

Immediately before upload, rebuild the package in a clean sid chroot, sign the .changes/.dsc file with your key, and then make a normal upload. Make sure your name isn't in the Maintainer: or Changed-By: fields of the .changes file. You can ensure this by either using the -k option to dpkg-buildpackage/debuild, or building without signing (-uc -us) and then using debsign to later sign the .changes file (which will sign the .dsc as part of the process). Do not use the -m or -e flags to dpkg-buildpackage/debuild, as that actually changes the maintainer/uploader information in the .changes/.dsc, which is most certainly not what you want.

Whatever you do, do *not* simply re-sign and upload the sponsee's .dsc/.changes, or (worse!) just upload what they send you (since it won't be properly signed).

What about recurring sponsorship of the same package?

You should work out a mutually-agreeable way for your sponsee to contact you to upload new versions of their package. Upload to (with notification to you, the sponsor) is a good way to go, especially if the sponsee doesn't have web space of their own.

You should do appropriate checks of each new revision your sponsee provides. The debdiff tool (from the devscripts package) is excellent for getting an overview of what has changed between Debian revisions.

What if I upload a package, and then my mentee disappears?

As a Debian developer, it might be scary to upload a package for someone, only to have them perhaps disappear. Don't fret; you don't have to take responsibility for it if your mentee vanishes.

If the mentee disappears, just follow the same procedure as if a Developer went missing-in-action: do a non-maintainer upload of the package, assigning it to debian-qa, and make it available for adoption (or eventually orphanage).

Having said that, this does create some extra work for people who decide to work on QA. It's good to make sure the package that you upload is of decent quality and not a duplicate of an existing package.

To summarise, maintainers and packages enter and exit Debian; it's part of a life cycle. It's okay to upload mentees' packages knowing that you risk going through an orphaning/adoption process later.

What resources are there for sponsors and prospective sponsors?

Originally created and maintained by Mathew Palmer at

Copyright © 2003,2004,2005,2006,2007 Matthew Palmer. Released under the terms of the GNU General Public License version 2.

CategoryDeveloper CategoryPackaging