Contents

  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 in the package name mean?
      7. How do I create debian/watch for download from Google Code?
      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?
    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 sponsor?
    4. 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 four 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 developers. 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, then it's probably a good fit for -mentors.

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

One of the most common uses for the list is to attempt to get a sponsor for a piece of software you've packaged (or are intending to package). It's such a common request that it has it's own section in this FAQ.

Things that aren't really appropriate for -mentors:

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?

See http://www.debian.org/devel/wnpp/#howto-o.

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.

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 http://www.debian.org/international/. 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 (debian-qa@lists.debian.org) 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 (http://bugs.debian.org/wnpp). A list of current requests for help posted by other people is available from http://www.debian.org/devel/wnpp/help_requested, 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 the QA group's wiki page about the tag.

Packaging

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 publically 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 http://mentors.debian.net/ 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 http://bugs.debian.org/wnpp)

  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 http://mentors.debian.net/), 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 http://snapshot.debian.org) 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. Non-Native Debian Package

    • A non-native debian source package contains a dsc, diff.gz and an 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: 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. In the orig.tar.gz: This is the upstream tarball. You should very 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 diff.gz.

  2. Native Debian Package

    • The Version number for a debian native package is only the version, it doesn't have a Debian revision number, it looks like: 2.8. A native package contains only a dsc and a tar.gz file. 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 .tar.gz 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 .diff.gz, which is typically much smaller.

      Native debian packages are often accidentally built when upstream tarball (.orig.tar.gz) is named incorrectly. It should always be named <sourcepkg>_<upstreamversion>.orig.tar.gz.

  3. When to use a native vs a non-native debian package

    • You should only use a native Debian package when it is clear that the package would only ever be of use in Debian. 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 packages are: libc6, apache, phpmyadmin. But lintian, dpkg and some other tools are purely developed for debian, and make no sense being released in another distribution.

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

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 released tarballs (used as .orig.tar.gz) and the debian directory separated.

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. Because it was 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 .orig.tar.gz 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 in the package name mean?

dfsg is a conventional way of naming a package, when upstream software was repackaged, because it contains some non-free elements. The changes should be documented in README.Debian-source. The recommended way of naming a package with the 'dfsg' bit is:

For example: I have packaged foobar application which has just released version 1.2.3. Normally the package name would be: abc_1.2.3-1 - and it was packaged as such. I have then discovered that the package contains some files that can not be distributed with the main Debian repository. I have removed them from source package (from .orig.tar.gz) and released new package: abc_1.2.3+dfsg-1. Later on, I have found even more files that should be removed. I did that and released abc_1.2.3+dfsg2-1.

How do I create debian/watch for download from Google Code?

It used to be a problem and special "redirector" service was created at googlecode.debian.net. This, however should not be an issue anymore and extra redirector service is not needed. An example debian/watch entry for Google Code:

version=3
http://code.google.com/p/bullet/downloads/list?can=1 \
  .*/bullet-(\d[\d\.]+)\.(?:tgz|tbz|txz|(?:tar\.(?:gz|bz2|xz))|zip)

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 a downloaded package

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

List files of a package without downloadnig it

 apt-get install apt-file
 apt-file update
 apt-file list

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 http://lists.debian.org/debian-mentors/2012/04/msg00387.html.

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 thing - there is no guarantee that anyone will sponsor your package. It all depends on the interest level and time available from any DD who might sponsor you.

The general rule is to make a request on debian-mentors for a sponsor. Put "RFS:" (Request For Sponsor) at the beginning of the subject of your message. Things to put in the message are:

  1. Name of the package;
  2. The licence the package is provided under;
  3. Short and long descriptions of the package; and
  4. Where the package can be obtained from (either via FTP/HTTP or by e-mailing someone). If you have nowhere to host files yourself, you can make use of the mentors.debian.net service.

Messages without all this information are far more likely to be ignored.

Your message to -mentors 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. Don't bother asking for a sponsor until you've got packages (more-or-less) ready to download.

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 full upload (.changes, .dsc, .orig.tar.gz, .diff.gz, and .deb(s)). 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 mini-NM 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 it's 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", Cc: the RFS there. For instance, if you're packaging Yet Another Perl Module, try a Cc: to debian-perl@lists.debian.org. If it's YAPython Module, d-python@l.d.o. Apache module? d-apache@lists.debian.org. 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 bribe 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 sponsor?

Volume

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.

Time

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 maintian infrastructure or packages they are a maintainer for.

Specialization

Debian contributors generally work on stuff they use or are otherwise are 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.

Preferences

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-maintainence or team maintainence.

Responsibility

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.

Infrastructure

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.

Emphasis

Sponsorship wasn't emphasized 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.

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. http://mentors.debian.net/, 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: headers 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 http://mentors.debian.net/ (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 summarize, 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 http://people.debian.org/~mpalmer/debian-mentors_FAQ.html

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


CategoryDebianDevelopment