Differences between revisions 2 and 51 (spanning 49 versions)
Revision 2 as of 2010-02-12 20:15:23
Size: 33458
Editor: LeoAntunes
Comment:
Revision 51 as of 2015-12-09 03:39:34
Size: 41853
Editor: BenFinney
Comment: possessive “its” has no apostrophe.
Deletions are marked like this. Additions are marked like this.
Line 7: Line 7:
    * General questions, about the list, Debian, and whatever else doesn't fit in another section.
    * Packaging, issues relating to creating and maintaining Debian packages.
    * Sponsored packages, all about the purpose and process of package sponsorship.
    * For sponsors, info for developers sponsoring or considering sponsoring a package or two.
    * [[#General_questions|General questions]], about the list, Debian, and whatever else doesn't fit in another section.
    * [[#Packaging|Packaging]], issues relating to creating and maintaining Debian packages.
    * [[#Sponsored_Packages|Sponsored packages]], all about the purpose and process of package sponsorship.
    * [[#For_Sponsors...|For sponsors]], info for developers sponsoring or considering sponsoring a package or two.
Line 22: Line 22:
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 [[#ForSponsors...|own section]] in this FAQ. 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 its [[#For_Sponsors...|own section]] in this FAQ.
Line 37: Line 37:
If you really are keen on getting involved in random places in Debian, there are lots of resources in the question "[[#WhatcanIdotohelpDebianotherthanpackaging.3F|What can I do to help Debian other than packaging?]]", below. 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.3F|What can I do to help Debian other than packaging?]]", below.
Line 43: Line 43:
   1. Package stuff. See [[#HowdoImakemyfirstpackage.3F|How do I make my first package?]] for more details on that aspect of the process.    1. Package stuff. See [[#How_do_I_make_my_first_package.3F|How do I make my first package?]] for more details on that aspect of the process.
Line 53: Line 53:
    * Joe Nahmias suggests the #debian-mentors IRC channel on irc.debian.org (the OFTC network), for help with any packaging and other Debian-related problems you might be having.     * Joe Nahmias suggests the [[irc://irc.debian.org/debian-mentors|#debian-mentors]] IRC channel on irc.debian.org (the OFTC network), for help with any packaging and other Debian-related problems you might be having.
Line 56: Line 56:
    * The debian-women project has produced a [[http://women.debian.org/wiki/English/NewBTSHowTo|Short BTS howto]]. They also run a [[http://women.debian.org/mentoring/|One-on-one mentoring program]] for new developers, although it is a little dormant at the moment.     * The debian-women project has produced a [[BTS/HowTo|Short BTS howto]]. They also run a [[http://women.debian.org/mentoring/|One-on-one mentoring program]] for new developers, although it is a little dormant at the moment.
Line 64: Line 64:
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 haras{{{^H^H^H^H^H}}}, uh, help. 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.
Line 72: Line 72:
There is also a list of random "todo" tasks at http://www.debian.org/devel/todo, one or more of which may interest you. Be warned that apparently some of them are somewhat out of date. If you're interested in helping to fix a bug, there is a [[http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-qa@lists.debian.org;tag=gift|list of bugs]] that have been identified by package maintainers as fairly simple, and good to improve your skills on. For more information, see [[qa.debian.org/GiftTag|the QA group's wiki page about the tag]].
Line 97: Line 97:
   2. If it's not already listed, file an ITP bug report against WNPP as detailed by [[http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-newpackage|section 5.1]] of the developer's reference. If it's already listed as an RFP, retitle the bug as an ITP (see the [[http://www.debian.org/Bugs/server-control|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. [[http://www.debian.org/doc/debian-policy/|Debian Policy]] and the [[http://www.debian.org/doc/developers-reference/|Developers' Reference]] are the "bibles" of packaging, however the [[http://www.debian.org/doc/maint-guide/|New Maintainers' Guide]] contains a more gentle introduction to the sport. The Debian Wiki also contains a basic [[HowToPackageForDebian|How To Package For Debian]] guide, while the Debian-women project has produced a [[http://women.debian.org/wiki/English/PackagingTutorial|Packaging Tutorial]].
   2. If it's not already listed, file an ITP bug report against WNPP as detailed by [[http://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#newpackage|section 5.1]] of the developer's reference. If it's already listed as an RFP, retitle the bug as an ITP (see the [[http://www.debian.org/Bugs/server-control|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. [[http://www.debian.org/doc/debian-policy/|Debian Policy]] and the [[http://www.debian.org/doc/developers-reference/|Developers' Reference]] are the "bibles" of packaging, however the [[http://www.debian.org/doc/maint-guide/|New Maintainers' Guide]] contains a more gentle introduction to the sport. The Debian Wiki also contains a basic [[HowToPackageForDebian|How To Package For Debian]] guide, while the Debian-women project has produced a [[PackagingTutorial|Packaging Tutorial]].
Line 100: Line 100:
   5. [[#HowdoIgetasponsorformypackage.3F|Request a sponsor from debian-mentors]], and possibly other places.    5. [[#How_do_I_get_a_sponsor_for_my_package.3F|Request a sponsor from debian-mentors]], and possibly other places.
Line 106: Line 106:

(Thanks to Paul Wise)
Line 116: Line 114:
   8. If you're a DD already, you can just upload your package. Otherwise, register your need for a sponsor on http://sponsors.debian.net, upload your package somewhere that prospective sponsors can review it (such as http://mentors.debian.net/), and then [[[[#HowdoIgetasponsorformypackage.3F|find a sponsor]] to upload the package into the Debian archive for you.    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 [[#How_do_I_get_a_sponsor_for_my_package.3F|find a sponsor]] to upload the package into the Debian archive for you.
Line 121: Line 119:
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.net) 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. 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.
Line 125: Line 123:
Getting the right workflow with your revision control system can be tricky. Manoj Srivastava has a page on managing your packages using Arch at http://arch.debian.org/arch/private/srivasta/.
Line 132: Line 128:
      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.
       A non-native debian source package contains a dsc, diff.gz or debian.tar.$comp and one or more 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.
      * 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.
      * 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(1) for more information.
Line 143: Line 140:
      A few examples of normal packages are: libc6, apache, phpmyadmin. But linda, lintian, dpkg and some other tools are purely developed for debian, and make no sense being released in another distribution.       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.
Line 147: Line 144:
(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(1) for more information about source formats)
Line 154: Line 153:

=== 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:
 <UPSTREAM VER>+dfsg-<DEBIAN VER>

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 [[http://lists.debian.org/debian-mentors/2012/07/msg00429.html|debian-mentors thread]] and [[http://www.debian.org/doc/debian-policy/ch-files.html#s10.7.5|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 downloading 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]].

=== How do I install a package from mentor.debian.net? ===

First of all, it is not recommended to install packages from mentor.debian.net. 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 on dget in the [[http://manpages.ubuntu.com/manpages/precise/man1/dget.1.html|manual]]

{{{
 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 gpg signature check has failed. To fix this, you need to tell dscverify that it is ok to use your personal gpg keyring and then download the author's gpg public key:

{{{
 cp /etc/devscripts.conf ~/.devscripts
}}}

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

{{{
 gpg --keyserver pool.sks-keyservers.net --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 ran as super user.
Line 194: Line 290:
Messages without all this information are far more likely to be ignored. Messages without all this information are far more likely to be ignored (see the [[http://mentors.debian.net/sponsor/rfs-howto|template]] on this page).
Line 206: Line 302:
Don't forget to register your need for a sponsor on http://sponsors.debian.net/ so that it doesn't get forgotten.
Line 212: Line 306:
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. 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.
Line 216: Line 310:
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? 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 [[https://www.debian.org/Bugs/Reporting#xcc|X-Debbugs-CC]] pseudo-header. For plain RFS mails, CC the address. For instance, if you're packaging Yet Another Perl Module, try 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 [[Teams|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.
Line 226: Line 320:
Sometimes RFS' fall through the cracks, so register your need for a sponsor on http://sponsors.debian.net/ so that it doesn't get lost in the mailing list archives. 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.

Try to get it uploaded to Ubuntu's [[http://revu.tauware.de/|REVU]], you will probably get lots of good comments on your package in the process, and perhaps someone from [[http://utnubu.alioth.debian.org/|Utnubu]] will notice that your package was uploaded to Ubuntu and offer to sponsor it for you.
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.
Line 232: Line 324:
Fix lots of bugs, get involved in doing QA work, perhaps you will get to know a DD well enough that they will sponsor you. 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]], [[http:/ftp-master.debian.org/REJECT-FAQ.html|reject FAQ]], [[HowToPackageForDebian#Check_points_for_any_package]],[[http:/mentors.debian.net/intro-reviewers|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 maintain 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-maintenance or team maintenance.

==== 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.
Line 242: Line 366:
You should first, of course, find a package to sponsor. http://sponsors.debian.net/, 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 [[http://people.debian.org/~mpalmer/sponsorship_checklist.html|Mathew Palmer's sponsorship checklist]]. 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.
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 [[SponsorChecklist|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.
Line 254: Line 378:
You should do appropriate checks of each new revision your sponsee provides. The interdiff tool (from the patchutils package) is excellent for getting an overview of what has changed between Debian revisions (although it doesn't work so well between upstream versions, unfortunately). 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.
Line 258: Line 392:
    * The http://sponsors.debian.net/ and http://mentors.debian.net/ websites;     * The http://mentors.debian.net/ website;
Line 260: Line 394:
    * The #debian-mentors IRC channel on irc.debian.org;
    * [[http://people.debian.org/~mpalmer/sponsorship_checklist.html|Mathew Palmer's sponsorship checklist]] (although that list is neither exhaustive nor definitive);
    * The [[irc://irc.debian.org/debian-mentors|#debian-mentors]] IRC channel on irc.debian.org;
    * [[SponsorChecklist|Several sponsorship checklists]] (none of the lists are either exhaustive or definitive);
Line 266: Line 400:

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

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?
      12. How do I install a package from mentor.debian.net?
    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:

  • General questions, about the list, Debian, and whatever else doesn't fit in another section.

  • Packaging, issues relating to creating and maintaining Debian packages.

  • Sponsored packages, all about the purpose and process of package sponsorship.

  • For sponsors, info for developers sponsoring or considering sponsoring a package or two.

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 its own section in this FAQ.

Things that aren't really appropriate for -mentors:

  • Questions about using the debian system, either as a regular user or an admin. These would tend to belong in debian-user or a list devoted to the particular subsystem you're using (debian-x, debian-apache, etc).
  • Questions about programming in general. This would be a topic for a list or forum dedicated to the language or system used.
  • Hard-core debian development questions. Although -mentors will try and help out, you'll get the big brains working on your problem if you take it next door to debian-devel, or to one of the topic-specific debian lists.

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:

  • It's hard to know what you actually want to do. Even with a detailed resume, how do we know whether you're going to be interested, long term, in doing some task. Remember that everyone's a volunteer, and we have no hold over you to tell you to do something you don't want to do (unlike paid employment).
  • If someone spends a lot of time specifying a task for you to do, and then you decide you don't want to do it, then they've wasted time they could have spent doing whatever it is that they do. After you've had this experience a few times, you just stop specifying tasks for people. Instead, just dive into something and try and work out how it's done. Hands-on learning is the best type of learning anyway.

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:

  • Joe Nahmias suggests the #debian-mentors IRC channel on irc.debian.org (the OFTC network), for help with any packaging and other Debian-related problems you might be having.

  • The Developer's corner, which includes links to the Debian Policy, Developers' Reference, New Maintainer's Reference, and basically anything else that a DD or DD-to-be (that rhymes, hee hee!) might be interested in.

  • There is an article in IBM's developerWorks library entitled "Learn how to build easy-to-distribute packages for Debian users", which gives a softer introduction to the whole process.

  • The debian-women project has produced a Short BTS howto. They also run a One-on-one mentoring program for new developers, although it is a little dormant at the moment.

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 or debian.tar.$comp and one or more 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.
    • 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.
    • 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(1) for more information.
  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?

(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(1) 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 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:

  • <UPSTREAM VER>+dfsg-<DEBIAN VER>

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

How do I install a package from mentor.debian.net?

First of all, it is not recommended to install packages from mentor.debian.net. 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 on dget in the manual

 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 gpg signature check has failed. To fix this, you need to tell dscverify that it is ok to use your personal gpg keyring and then download the author's gpg public key:

 cp /etc/devscripts.conf ~/.devscripts

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

 gpg --keyserver pool.sks-keyservers.net --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 ran 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 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 (see the template on this page).

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 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 pseudo-header. For plain RFS mails, CC the address. For instance, if you're packaging Yet Another Perl Module, try 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 maintain 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-maintenance or team maintenance.

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?

  • The http://mentors.debian.net/ website;

  • The debian-mentors mailing list;
  • The #debian-mentors IRC channel on irc.debian.org;

  • Several sponsorship checklists (none of the lists are either exhaustive or definitive);

  • A better checklist (from the gatekeepers of the archive) is also available;

  • Consider setting up a "sponsoring" alias for you and your sponsee, by creating a file in your home directory on master.debian.org called .forward-sponsoring-<jbloggs> containing your e-mail address and the address of your sponsee separated by commas (see existing entries on master). This will create a mail alias, <yourname>-sponsoring-<jbloggs>, which will send mail to both you and your sponsee. Handy!


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