Common questions asked by new posters to the debian-mentors mailing list. There are five sections:

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

Contents

  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 install a package from mentors.debian.net?
    4. Where else can I learn about the packaging process?
  3. Sponsored Packages
    1. What's a sponsor, why do I want one, and how do I get one?
    2. What's the difference between a sponsor and an advocate?
    3. So how do I get an advocate then?
    4. How do I get a sponsor for my package?
    5. But why should I waste time packaging if there's no guarantee it's going to be uploaded?
    6. Where else can I get a sponsor?
    7. What happens if I can't find a sponsor?
    8. Why is it so hard to find a sponsor?
  4. Infrastructure Projects
  5. For Sponsors...
    1. Who can sponsor a package?
    2. What is the process for sponsoring a package?
    3. What about recurring sponsorship of the same package?
    4. What if I upload a package, and then my mentee disappears?
    5. What resources are there for sponsors and prospective sponsors?

General questions

What is the debian-mentors mailing list for?

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

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

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

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

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

This is a very difficult question, because there's so many different things that could be done, and we don't know what you're really interested in. 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 some task? 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 that doesn't speak to you, they've wasted their time. Mentors have lots of calls on their time, and after they've had that experience a few times, they just stop specifying tasks for people.

It's usually better to 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?

See DebianDeveloper/JoinTheProject.

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 https://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. Besides, running and developing the Debian infrastructure also takes a lot of work. Projects like Debbugs (our bug tracking system), dak (which runs our package archive) and many more would love to see new contributors. See the section Infrastructure Projects below for more information on how to contribute to Debian infrastructure projects.

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

There are several 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. 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. 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 in devscripts.

Some maintainers have requested some help with their packages, by posting a Request For Help ("RFH") on the Work-needing and Prospective Packages list. A list of current requests for help posted by other people is available from https://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 wiki page about the tag.

Packaging

How do I make my first package?

Co-maintenance may be be a better alterntive to creating a new package on your own. You'll get a pre-existing package, plus someone to answer your questions and sponsor your uploads while you learn the ropes.

To co-maintain a package, look at packages for which help was requested for all of Debian, or install how-can-i-help and run how-can-i-help --show RFH --old for packages on your computer. Either way, find a bug that interests you and reply to it.

Adopting a package is another alternative. There are always packages up for adoption or orphaned by their old maintainer, and you can see installed packages with how-can-i-help --show RFA,O --old. These are packages which are in Debian but their previous maintainer(s) have given up maintenance. Packages with a Request For Adoption ("RFA") should have someone to answer your questions and sponsor your uploads while you learn the ropes, but will be more hands-off and will likely expect you to take over in the long-run. You're on your own with orphaned packages, but at least you have a working example to start from.

You can also find packages that need work at the WNPP bug list (alternative interface), or by calling how-can-i-help without arguments (shows every type of issue, but only issues it's never shown you before).

For "Request For Adoption" packages, contact the current maintainer to ask if they'd be willing to let you maintain it, and to sponsor your uploads. Please respect their judgement if they decline - maintainers usually have a good reason for not handing the package off to someone with no experience.

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 yourself as the maintainer, and to close the WNPP bug in the changelog of your first upload.

Improving an abandoned package is also possible, even if the maintainer hasn't officially orphaned it. It's usually best to avoid this unless the package has obvious bugs that have been open for a long time and don't have a reply (e.g. asking to fix a typo that would take a few minutes, or to package a new upstream version with important features). A developer that's just having a bad year won't be happy to see someone threatening to hijack their package!

If you use a program and think you'd be a good new maintainer, bring it to debian-mentors or debian-qa with your reasoning.

Answering a Request For Package is a good way to create a new package, because you can prove there's interest, have someone to test your package, and may even get someone to sponsor your uploads.

Creating an unsolicited package is fine too, so long as it's not already in the archive, and not listed as an ITP (Intent To Package) on the WNPP bugs page.

For more information about creating a package, see the next question.

How do I add a new package to the archive?

{i} If you don't have a specific package in mind, see the previous question for other ways to scratch your itch.

The basic process is:

  1. check your project isn't already being worked on

    • if it is, offer to help out instead

  2. check if your project is already requested to be worked on

    • if it is, contact the requester to see if they're willing to help
  3. check you can actually create the package

    • is its license compatible with the Debian Free Software Guidelines?

    • can you reasonably maintain it?
      • how complex and time-consuming would you find it?
      • are you ready to stick around for years maintaining bugs?
      • are you familiar with the programming language(s) used?
      • can you expect upstream to fix packaging issues and respond to bugs from Debian users?

  4. file an ITP bug report against WNPP as detailed by section 5.1 of the developer's reference

    • or if it's already listed as an RFP, retitle the bug as an ITP (see the BTS manipulation manual)

  5. put a package together, built against a current version of sid

  6. Install and test your package thoroughly

    • ask on the debian-mentors mailing list for people to check your package for errors and common problems

    • if someone else requested the package, ask them to try it out

  7. upload your source package (.orig.tar.gz, .diff, and .dsc), binary package (.deb) and .changes files (sign your .changes if possible)

  8. request a sponsor from debian-mentors, and anywhere else you think you might find one

    • when you get a sponsor, let everyone else know so they don't duplicate that effort
  9. keep your package maintained after the initial upload - respond to bug reports and new upstream versions

For more information, see Packaging.

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

/!\ packages on mentors.debian.net have not been reviewed and could contain malicious code.

If you have reviewed a package to be sure it's clean, and you still want to install it:

  1. install devscripts: 

    • # install devscripts:
sudo apt-get install devscripts

  2. Use dget to download the source code (see dget): 

    • dget <link to the .dsc file>

  3. If you get an error from dscverify about the OpenPGP signature check, use your personal OpenPGP keyring and then download the author's OpenPGP public key: 

    • cp /etc/devscripts.conf ~/.devscripts
# uncomment DSCVERIFY_KEYRINGS="" and set it to your OpenPGP keyring location:
# (e.g. DSCVERIFY_KEYRINGS="~/.gnupg/pubring.gpg")
sensible-editor ~/.devscripts
gpg --keyserver pool.sks-keyservers.net --recv-keys <author's key id>
dget <link to the .dsc file>

  4. cd into the directory that has been created: 

    •  cd /path/to/extracted/package

  5. Build the source into a .deb file: 

    • debuild -us -uc
  6. install the package: 
    • sudo dpkg -i <package-name>.deb

    • you may need to manually install dependencies - dpkg can list missing dependencies, but can't do anything about it

Where else can I learn about the packaging process?

More details questions are available at PackagingFAQ, and Packaging has many more links.

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

A sponsor is a Debian Developer ("DD") who uploads packages to the archive on behalf of a non-DD. 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 or users' systems when in use.

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

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

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

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

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

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

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

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

So how do I get an advocate then?

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

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

How do I get a sponsor for my package?

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

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

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

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

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

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

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

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

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

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

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

And you can always just create your own repository and upload it to a static hosting service (like GitHub Pages). One guide to creating a repo is DebianRepository/SetupWithReprepro.

Where else can I get a sponsor?

debian-mentors isn't the only place where you can get a sponsor. In general, you're more likely to get a sponsor who is actually interested in what you've packaged, but doesn't have time to package it themselves. So, if there's a list dedicated to your "niche market", send the RFS there. For RFS bugs, use the X-Debbugs-CC field in the pseudo-header. For plain RFS mails, CC the address. For instance, if you're packaging Yet Another Perl Module, try debian-perl. If it's YAPython Module, debian-python. Apache module? debian-apache. Something legal-related? debian-lex. Something for kids? debian-edu. 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. 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 feedback on #debian-mentors and the mailing list. Don't just mention the package name, also provide (at least) the brief description. Typically a developer is more likely to sponsor something they might be interested in using, or which they recognise there might be a need for. Just the package name doesn't really convey the sort of information needed to make that call.

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

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

Increase the quality of your package. Check it against various checklists, and with package-checking tools like lintian. Look at the PTS page for your package and at the links on that page. See Working with other developers.

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

Why is it so hard to find a sponsor?

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 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. 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, but still needs work.

Emphasis

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

Infrastructure Projects

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

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

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

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

Some examples of Debian infrastructure projects:

For Sponsors...

Who can sponsor a package?

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

What is the process for sponsoring a package?

You should first, of course, find a package to sponsor. https://mentors.debian.net/, the d-mentors mailing 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 the sponsor 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.

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

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

What about recurring sponsorship of the same package?

You should work out a mutually-agreeable way for your sponsee to contact you to upload new versions of their package. Upload to https://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. debdiff (from devscripts) 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 sponsee vanishes.

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

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

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

What resources are there for sponsors and prospective sponsors?

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-<sponsees-name> 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, <your-name>-sponsoring-<sponsees-name>, which will send mail to both you and your sponsee. Handy!

Originally created and maintained by Mathew Palmer at https://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.

CategoryDeveloper CategoryPackaging