[Nm-templates-discuss] templates nm_assigned.txt, 1.23,
1.24 nm_pp1.txt, 1.8, 1.9 nm_pp2.txt, 1.12, 1.13 nm_ts1.txt,
1.4, 1.5 nm_ts2.txt, 1.8, 1.9
joerg at alioth.debian.org
joerg at alioth.debian.org
Wed Dec 27 00:04:35 CET 2006
Update of /cvsroot/nm-templates/templates
In directory alioth:/tmp/cvs-serv30118
Modified Files:
nm_assigned.txt nm_pp1.txt nm_pp2.txt nm_ts1.txt nm_ts2.txt
Log Message:
First revision of a reworked set of templates. Merged, moved and restructured
a lot of questions.
99% of this work was done by Myon, thanks!
Index: nm_assigned.txt
===================================================================
RCS file: /cvsroot/nm-templates/templates/nm_assigned.txt,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -d -r1.23 -r1.24
--- nm_assigned.txt 31 Mar 2006 17:47:23 -0000 1.23
+++ nm_assigned.txt 26 Dec 2006 23:04:33 -0000 1.24
@@ -5,7 +5,7 @@
you and then send a summary to the Debian Account Managers (DAM)
and a brief summary to the debian-newmaint mailing list.
-First a quick note: please read all of my mails carefully. Many
+First a quick note: please read all of my mails carefully. Some
applicants have a tendency of only answering half the questions. This
generates more work for both of us and means we will need more time
for your NM process.
@@ -22,11 +22,8 @@
Now it's time to check your identity.
-1. Please send me the keyid of your GPG public key so I can fetch it
-from a keyserver. If your GPG key is not on a public keyserver, please
-upload it to subkeys.pgp.net. If your GPG key is signed by a Debian
-developer, the ID check is completed. However, if your key is not
-signed, then we have to figure out what to do for the ID check.
+ID Check
+--------
Since many people trust Debian, we have to make sure that new
volunteers are who they claim to be. The easiest check is having your
@@ -40,9 +37,13 @@
to learn more about the web of trust and key signing.
-If you don't have your key signed by a Debian Developer please let me
-know and we can discuss it. Usually I can find someone that lives near
-you that would agree to meet you and sign your key.
+Please send me the keyid of your GPG public key so I can fetch it
+from a keyserver. If your GPG key is not on a public keyserver, please
+upload it to subkeys.pgp.net. If your GPG key is signed by a Debian
+developer, the ID check is completed. However, if your key is not
+signed, then we have to figure out what to do for the ID check. Usually
+I can find someone that lives near you that would agree to meet you and
+sign your key.
Although it is sufficient that you have just one signature from an
existing Debian developer, it is strongly advised to get more
@@ -60,16 +61,25 @@
how.
-2. The DAM needs some data to create your account, so please tell me
+Account
+-------
+
+When we successfully finish this process the DAM needs some data to
+create your account, so please tell me
+
- the preferred account name for the Debian machines, and
- the email address to which Debian mail should be forwarded.
+
Please make sure that the account name is still free -- visit
http://db.debian.org/ to find out if this is the case. After your
account was created, you can use the CGIs available there to
change the data that is kept about you in the Debian LDAP.
-3. Finally, please tell me about yourself, how you came to GNU/Linux and
+About you
+---------
+
+Finally, please tell me about yourself, how you came to GNU/Linux and
free software, and why you want to volunteer your time. Please describe
the contributions you have made to Debian, your primary areas of
interest within Debian, and any goals you plan to accomplish.
@@ -79,6 +89,9 @@
which parts I may publish and which not.
+Things to come
+--------------
+
If you have packaged an application for Debian already, please take
another deep look into it, eliminating any error you may find. When we
start with the "Tasks and Skills" checks, you will get more information
Index: nm_pp1.txt
===================================================================
RCS file: /cvsroot/nm-templates/templates/nm_pp1.txt,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -d -r1.8 -r1.9
--- nm_pp1.txt 14 Jul 2006 09:43:19 -0000 1.8
+++ nm_pp1.txt 26 Dec 2006 23:04:33 -0000 1.9
@@ -8,6 +8,12 @@
If any questions arise, you should have a look at the draft for a DFSG
FAQ [5].
+ [1] http://www.debian.org/devel/constitution
+ [2] http://www.debian.org/social_contract.en.html
+ [3] http://www.debian.org/doc/developers-reference/
+ [4] http://www.debian.org/doc/debian-policy/
+ [5] http://people.debian.org/~bap/dfsg-faq.html
+
After you have done this, please answer the following set of questions
and try to be quite verbose in your answers. This, and the next half of
P&P are the main areas that we can only check via your written
@@ -16,55 +22,58 @@
A request: There will usually be several replies and followups to every
question. If you remove any quoted part, please do not remove the
-numbers of the questions so we can more easily see what we are talking
+numbers of the questions, so we can more easily see what we are talking
about.
+Philosophy
+----------
+
First, please explain the key points of the Social Contract and the
DFSG _in your own words_. Also, describe what you personally think
about these documents.
Secondly, a few questions, based on them:
- 0. What is Debian's approach to non-free software? Why? Is non-free
- part of the Debian System?
+PH1. What is Debian's approach to non-free software? Why? Is non-free
+ part of the Debian System?
- 1. Suppose that Debian were offered a Debian-specific license to
- package a certain piece of software: would we put it in main?
+PH2. Suppose that Debian were offered a Debian-specific license to
+ package a certain piece of software: would we put it in main?
- 2. Donald Knuth, author of TeX, insists that no-one has the right to
- modify the source code of TeX, and that any changes must be made using
- "change files" (a sort of patch file). Is this allowed for a program
- for the main section of Debian?
+PH3. Donald Knuth, author of TeX, insists that no-one has the right to
+ modify the source code of TeX, and that any changes must be made using
+ "change files" (a sort of patch file). Is this allowed for a program
+ for the main section of Debian?
- 3. Do you know (and can you explain) the difference between free speech
- and free beer? Is Debian mainly about free speech or free beer?
+PH4. Do you know (and can you explain) the difference between free speech
+ and free beer? Is Debian mainly about free speech or free beer?
- 4. What are the sections of Debian software and the differences between
- them? How would you decide where to put a new package? Which requirements
- do the packages in the sections have to meet?
+PH5. What are the sections of Debian software and the differences between
+ them? How would you decide where to put a new package? Which requirements
+ do the packages in the sections have to meet?
- 5. At http://people.debian.org/~joerg/bad.licenses.tar.bz2 you can
- find a tarball of bad licenses. Please compare the graphviz and three
- other (your choice) licenses with the first nine points of the DFSG
- and show what changes would be needed to make them DFSG-free.
- There's no need to compare word for word (which would be impossible
- for some licenses anyway), but you should spot the biggest mistakes.
+PH6. The GNU Free Documentation License (FDL) has been heavily discussed
+ on debian-legal in the past, leading to a GR, see
+ http://www.debian.org/vote/2006/vote_001. What is your opinion about
+ how the DFSG should be applied to parts of an application that are
+ not source code, such as documentation, firmware, image, etc?
-5a. The GNU Free Documentation License (FDL) has been heavily discussed
- on debian-legal in the past, leading to a GR, see
- http://www.debian.org/vote/2006/vote_001. What is your opinion about
- how the DFSG should be applied to parts of an application that are
- not source code, such as documentation, firmware, image, etc?
+PH7. How do *you* check if a license is DFSG-compatible?
-5b. How do *you* check if a license is DFSG-compatible?
+PH8. There are a few "tests" for this purpose, based on (not really) common
+ situations. Explain them to me and point out which common problems can
+ be discovered by them.
-5c. There are a few "tests" for this purpose, based on (not really) common
- situations. Explain them to me and point out which common problems can
- be discovered by them.
+PH9. At http://people.debian.org/~joerg/bad.licenses.tar.bz2 you can
+ find a tarball of bad licenses. Please compare the graphviz and three
+ other (your choice) licenses with the first nine points of the DFSG
+ and show what changes would be needed to make them DFSG-free.
+ There's no need to compare word for word (which would be impossible
+ for some licenses anyway), but you should spot the biggest mistakes.
- 6. Are there any sections of the DFSG or Social Contract that you
- might like to see changed? If so, which ones, and why?
+PHa. Are there any sections of the DFSG or Social Contract that you
+ might like to see changed? If so, which ones, and why?
Do you agree to uphold the Social Contract and the DFSG in your Debian
@@ -80,18 +89,60 @@
satisfactory, I will send you phase II of the P&P test.
-URLs:
-[1] http://www.debian.org/devel/constitution
- Constitution for the Debian Project
+Interesting URLs
+----------------
-[2] http://www.debian.org/social_contract.en.html
- Debian Social Contract
+Finally, some important web links:
-[3] http://www.debian.org/doc/developers-reference/
- Debian Developer's Reference
+ http://www.debian.org/devel/
+ The Developer's Corner. Contains links and on-line versions
+ of the stuff I mentioned before.
-[4] http://www.debian.org/doc/debian-policy/
- Debian Policy Manual
+ http://db.debian.org/
+ Queries about developers and machines.
-[5] http://people.debian.org/~bap/dfsg-faq.html
- DFSG and Software License FAQ
+ http://www.debian.org/devel/wnpp/
+ The Work Needing and Prospective Packages list. Sort of a
+ big TODO list for Debian packaging stuff: what's orphaned,
+ what needs new maintainers, what's being adopted, what's
+ being packaged and what would be nice to have packaged.
+
+ http://qa.debian.org/
+ The Debian Quality Assurance headquarters. Help is appreciated!
+
+ http://bugs.debian.org/
+ Bug related info.
+
+ http://www.debian.org/security/
+ Security related info. Please, read the FAQ, as it will save
+ you (and others) a lot of headaches.
+
+ http://packages.debian.org/
+ Package related info.
+
+ http://buildd.debian.org/
+ Build status of Debian packages.
+
+ http://lists.debian.org/
+ Mailing list subscription and archives.
+
+ http://qa.debian.org/developer.php
+ An interesting place to keep track of your packages.
+
+ http://lintian.debian.org/
+ Automated lintian tests on all packages in the Debian Archive.
+
+ http://www.netfort.gr.jp/~dancer/column/libpkg-guide/
+ Debian Library Packaging guide.
+
+ http://packages.qa.debian.org/
+ The Package Tracking System.
+
+ http://people.debian.org/~walters/descriptions.html
+ A small Guide "Writing Debian package descriptions".
+
+ http://people.debian.org/~igloo/status.php
+ Watch your package status.
+
+ http://ftp-master.debian.org/REJECT-FAQ.html
+ Reject FAQ for NEW Debian packages
Index: nm_pp2.txt
===================================================================
RCS file: /cvsroot/nm-templates/templates/nm_pp2.txt,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -d -r1.12 -r1.13
--- nm_pp2.txt 26 Dec 2006 20:17:31 -0000 1.12
+++ nm_pp2.txt 26 Dec 2006 23:04:33 -0000 1.13
@@ -6,146 +6,130 @@
understanding of basic Debian rules and the proper method of interacting
with Debian resources.
-I'm sure you have read the documents I mentioned in the first half of
-P&P. They should help you to answer these questions, but you may also
-look at the bottom of this mail, where I list a few other URLs to help
-you.
-
-
- 1. What are Non-Maintainer Uploads (NMUs) and when would you do an NMU?
- Please list the usual procedure for a NMU.
-
- 2. Please tell me 3 different methods to close a bug in the BTS, the
- difference between them, and when to use which method.
+I assume you have read the documents I had mentioned in the first half
+of P&P, they should help you answer the following questions. At the
+bottom of this mail I also list some interesting packages and point to
+mailing lists you might want to subscribe to.
- 3. Each bugreport has a severity and optionally one or more tags. What's
- the difference between these two (severity and tags)? How do you set
- them?
- 4. How do tags and severities affect the release status of a debian package?
- Please also give a short explanation about the other tags.
+Bug Tracking System
+-------------------
- 5. Where can you find the list of defined BTS pseudo packages?
- Explain to me what a pseudo package is.
+BT1. Please tell me 3 different methods to close a bug in the BTS, the
+ difference between them, and when to use which method.
- 6. You just discovered a bug in many packages. What are your next
- steps?
+BT2. You have a package (current version 1.3), with a set of open bugs:
- 7. What would you do if a bug was reported against your package and
- you are not able to fix it yourself?
+ #123: eats lots of memory (fixed in 1.2)
+ #345: please package version 1.4
+ #567: typo in package description
+ #789: segfaults every Sunday (fixed in 1.4)
+ #901: please move config file to /usr/local/etc
- 8. You've just heard about this great program and would like to package
- it, what are your next steps?
+ Some of them are fixed by the new upstream version (which you are
+ about to upload), some of them aren't valid bugs, or are not
+ relevant anymore (because they were fixed ages ago, for example).
+ Please write a changelog entry for the upload.
- 9. How do you check a package before you upload? Please explain to me
- why and how you perform the checks.
+BT3. Each bugreport has a severity and optionally one or more tags. What's
+ the difference between these two (severity and tags)? How do you set
+ them? How do they affect the release status of a debian package?
+ Are there restrictions who can/should set some tags?
-10. What does version 2:3.4-2.1 mean? What Debian control file would you
- put this in?
+BT4. Someone files a bug against a package that you maintain. However, the
+ problem in the bug report does not come from a bug in your package, but
+ rather a bug in another maintainer's package. What do you do?
-11. You have a new package, and you finally find that it will be in
- contrib. Why would it be there? What could you do (in theory at
- least) to get it into main?
+BT5. What would you do if a bug was reported against your package and
+ you are not able to fix it yourself?
-12. If you had a file in your package which usually gets changed by a
- administrator for local settings, how do you make sure your next version
- of the package doesn't overwrite it?
+BT6. What do you do if you want to reach the submitter of a bug and keep a
+ copy of the mail in the BTS?
-13. What is an autobuilder? Where can you find information about your
- package's build status on different architectures? What can you do
- if you think there is a problem with the autobuilder?
+BT7. Where can you find the list of defined BTS pseudo packages?
+ Explain to me what a pseudo package is.
-14. There are many Debian suites, like "stable", "unstable", "testing",
- "experimental", "sarge", "etch" and "sid". Can you explain why there
- are so many and what the differences are? How (and when) does a
- package get from one to the other?
-15. How can you ensure your package's description is in a good state and
- in a valid format?
+Procedures
+----------
-16. What should you do when a security bug is discovered in one of your
- packages?
+PR1. Although English is doubtless the "lingua franca" nowadays, which means
+ that it is understood nearly everywhere, there are users who do not
+ understand it properly. Which efforts does the Debian project make
+ to help these people?
-17. Imagine you maintain a package which depends very closely on some
- other package. How would you keep track of the development of other
- packages, even if you are not the maintainer?
+PR2. Please list some tasks that belong to the scope of duties of the Debian
+ Quality Assurance group.
-18. Should you happily sign another developer's GPG key? If not,
- please explain the checks you will make before signing it.
+PR3. What should you do when a security bug is discovered in one of your
+ packages? What steps do you need to fix a problem in one of your
+ packages in the stable release?
-19. Do you know how to create a revocation certificate for your GPG key?
- Do you have one? Why can it be meaningful to set a key expiration date?
+PR4. At regular intervals, we arrange the so called "Bug Squashing Parties".
+ What are they good for and what happens during such a BSP?
-20. What would you do if you wanted to retire from the project?
+PR5. What are Non-Maintainer Uploads (NMUs) and when would you do an NMU?
+ Please list the usual procedure for a NMU.
-21. You need to fix a problem in one of your packages in the stable
- distribution. Please list all steps you have to do.
+PR6. You've just heard about this great program and would like to package
+ it, what are your next steps?
-22. Someone files a bug against a package that you maintain. However, the
- problem in the bug report does not come from a bug in your package, but
- rather a bug in another maintainer's package. How should you handle
- the bug that was filed against your package?
+PR7. You can't/wont maintain a package properly anymore because
+ you have a lack of time/don't use it anymore. What are your
+ options to handle this situation?
-23. What do you do if you want to reach the submitter of a bug and keep a
- copy of the mail in the BTS?
+PR8. You just discovered a bug in many packages. What are your next
+ steps? Are there alternatives to filing bugs?
-24. Again, something BTS related: Consider you have a package, with a
- set of open bugs. Some of them fixed by the new upstream version
- (which you are about to upload), some of them aren't really bugs, or
- are not relevant anymore (because they were fixed ages ago, for
- example). How would you handle them?
+PR9. Should you happily sign another developer's GPG key? If not,
+ please explain the checks you will make before signing it.
-25. At regular intervals, we arrange the so called "Bug Squashing Parties".
- What are they good for and what happens during such a BSP?
+PRa. Do you know how to create a revocation certificate for your GPG key?
+ Do you have one? Why can it be meaningful to set a key expiration date?
-26. Although English is doubtless the "lingua franca" nowadays, which means
- that it is understood nearly everywhere, there are users who do not
- understand it properly. Which efforts does the Debian project make
- to help these people?
+PRb. What would you do if you wanted to retire from the project?
-27. Please list some tasks that belong to the scope of duties of the Debian
- Quality Assurance group.
-28. What does the version string in the Standards-Version field of a
- package's control file represent? Why is it useful?
+That's the second part of P&P. When we are done with this, we will
+continue with T&S, the Tasks and Skills.
-29. If one of your packages had serious problems like that either
- a) the current version in the archive is not "mature" enough
- to be in a Debian release but it is developing and you still
- want maintain it
- b) the software got abandoned upstream or got obsolete due to
- external reasons and you consider it not "worthy" anymore
- to be included in Debian.
- How would you proceed in these cases?
-30. You can't/wont maintain a package properly anymore because
- you have a lack of time/don't use it anymore. What are your
- options to handle this situation?
+Mailing Lists
+-------------
A word on mailing lists: there are quite a lot of Debian mailing lists
now as well as packaging-related packages, and I'd just like to check with
you whether you know about the key ones.
-debian-announce: Major public announcements
-debian-devel-announce: Major announcements to the developer community
+ debian-announce: Major public announcements
+
+ debian-devel-announce: Major announcements to the developer community
These two lists are must-subscribes. Everything else is optional. I
abbreviate 'debian-' to '-' from now on.
--security-announce: security updates to stable
--private: you'll be subscribed automatically when your new-maintainer
- application is accepted (but you can unsubscribe if you wish);
- the list is used for sensitive discussions, etc.
--devel: general mailing list for developer issues
--policy: where possible changes to debian-policy are discussed
--mentors: helping newbie Developers and maintainers.
--project: project related discussions
+ -security-announce: security updates to stable
+
+ -private: you'll be subscribed automatically when your new-maintainer
+ application is accepted (but you can unsubscribe if you wish);
+ the list is used for sensitive discussions, etc.
+
+ -devel: general mailing list for developer issues
+
+ -policy: where possible changes to debian-policy are discussed
+
+ -mentors: helping newbie Developers and maintainers.
+
+ -project: project related discussions
There are many others; check the mailing list page on the web site
for details.
-Now lets take a look at some important packages for a upcoming Debian
+Important Packages
+------------------
+
+Now lets take a look at some important packages for an upcoming Debian
Developer. There are many of them, I will try to list the more important
ones.
@@ -154,11 +138,14 @@
essential list. It's useful to make sure everything in the list
is installed on the system when building and testing your own
packages.
+
dpkg-dev All of the primary tools needed to put a Debian package
together: dpkg-buildpackage, dpkg-source, etc.
+
debhelper A very useful set of scripts designed to make
debian/rules files more readable and uniform.
But you should be able to build a package without it.
+
debian-policy
Describes the policy relating to packages and details of
the packaging mechanism. Covers everything from
@@ -168,84 +155,46 @@
/usr/share/doc/debian-policy/upgrading-checklist.txt.gz,
which lists changes between versions of policy.
You must read and understand it.
+
doc-debian Lots of useful Debian-specific documentation: the
constitution and DFSG, explanation of the Bug Tracking
System (BTS), etc.
+
maint-guide
The New Maintainer's Guide to making Debian packages.
+
devscripts Lots of useful (and not-so-useful) scripts to help build
packages.
+
developers-reference
Lots of information on procedures and suchlike.
+ (http://www.debian.org/doc/developers-reference/ is often
+ more up-to-date.)
+
dupload or dput
- Automatically upload packages to the archive once they
- are built.
+ Uploads packages to the archive once they are built.
+
fakeroot Build packages without having to be root.
+
reportbug Tool to report bugs.
+
debootstrap
Allows you to "install" Debian's base on a given directory
anywhere on the filesystem. Combined with a chroot and
build-essential, this makes for a nice way to have a clean
environment where you can build your packages.
+
pbuilder Gives you an easy way to use debootstrap to test your
packages in a sane environment.
+
sbuild Tool to build your packages in a chroot (useful for
verifying build-deps).
+
lintian
linda Two packages to check your package for commonly made
errors. You should never upload a package which is not
checked by one of these tools.
- piuparts Gives an easy way to install, upgrade and remove your
- package in a clean Debian system. Helps to find leftovers
- after removal due to broken maintainer scripts.
-
-Finally, some important web links:
- http://www.debian.org/devel/
- The Developer's Corner. Contains links and on-line versions
- of the stuff I mentioned before.
-
- http://db.debian.org/
- Queries about developers and machines.
-
- http://www.debian.org/devel/wnpp/
- The Work Needing and Prospective Packages list. Sort of a
- big TODO list for Debian packaging stuff: what's orphaned,
- what needs new maintainers, what's being adopted, what's
- being packaged and what would be nice to have packaged.
- http://qa.debian.org/
- The Debian Quality Assurance headquarters. Help is appreciated!
-
- http://bugs.debian.org/
- Bug related info.
-
- http://www.debian.org/security/
- Security related info. Please, read the FAQ, as it will save
- you (and others) a lot of headaches.
-
- http://packages.debian.org/
- Package related info.
-
- http://buildd.debian.org/
- Build status of Debian packages.
-
- http://lists.debian.org/
- Mailing list subscription and archives.
-
- http://qa.debian.org/developer.php
- An interesting place to keep track of your packages.
-
- http://lintian.debian.org/
- Automated lintian tests on all packages in the Debian Archive.
-
- http://www.netfort.gr.jp/~dancer/column/libpkg-guide/
- Debian Library Packaging guide.
-
- http://packages.qa.debian.org/
- The Package Tracking System.
-
- http://people.debian.org/~walters/descriptions.html
- A small Guide "Writing Debian package descriptions".
-
- http://people.debian.org/~igloo/status.php
- Watch your package status.
+ piuparts Gives an easy way to test installing, upgrading, and
+ removing your package in a clean Debian system. Helps to
+ find leftovers due to broken maintainer scripts.
Index: nm_ts1.txt
===================================================================
RCS file: /cvsroot/nm-templates/templates/nm_ts1.txt,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -d -r1.4 -r1.5
--- nm_ts1.txt 31 Mar 2006 18:00:30 -0000 1.4
+++ nm_ts1.txt 26 Dec 2006 23:04:33 -0000 1.5
@@ -8,7 +8,7 @@
There is a place where you can go and upload your package for testing. The
archive at that site works exactly the same as the Debian archive, as
-it uses the same software behind the scene. So you can take this as
+it uses the same software behind the scene. You can take this as
the opportunity to get used to uploads and the stuff that happens with
your packages, so you are not just left alone after your NM without any
knowledge what exactly you need to do to get a package into the
@@ -23,81 +23,154 @@
package(s) you uploaded to that archive and check that. So please use the
time until then to prepare the best package(s) you can do. :)
-
Finally, the first half of the questions:
-If you have filed bugreports (with patches) to the BTS with respect to
-packaging issues, please tell me bug numbers, so I can check them.
+RC Bug Fixing
+-------------
- 0. What is the best way to check that your Build-Depends Line contains
- everything required to build your package?
+(Feel free to reply to this section in a separate message, as RC bug
+ fixing and developing a good patch may use some time.)
- 1. Please explain me what a virtual package is. Where can you find a
- list of defined virtual packages?
+RC1. Have you ever written a manpage? If so, please tell me which. If not,
+ please take a look at http://qa.debian.org/man-pages.html and
+ choose a package listed there. Then please write a man page for it,
+ submit it to the BTS and tell me the bug number for it.
- 2. What does it mean for a package to have a line like
- "Architecture: i386 alpha powerpc" in the control file?
- Do you have to provide binary packages for all these
- architectures when you upload your package?
- What is the difference between "Architecture: all" and
- "Architecture: any"?
+RC2. Please look at http://bugs.debian.org/release-critical/debian/all.html,
+ choose a bug listed there (please try to find one older than a few
+ days), try to create a patch to fix it and submit this patch to
+ the BTS. If you can't fix the bug, you should document what
+ you've found out about the bug in the BTS.
+ Then prepare, if possible, a NMU and send me a pointer to your NMU patch.
- 3. How do you manage new upstream releases?
+ Do the same thing again for 2 other bugs with severity Important
+ or higher. If you couldn't fix a bug, you should send me
+ the bug numbers of the bugs you tried to fix.
- 4. There is a bug in your package, fixed in upstream's CVS/development
- branch. What do you do with it?
- 5. What do you do if upstream releases a tarball once every year and
- then distributes minor revisions only in the form of patches? How do
- you manage your package then?
+Debian Package Format
+---------------------
- 6. What is the difference between native packages and non-native
- packages?
+PF1. What does version 2:3.4~rc1-2.1 mean? What Debian control file
+ would you put this in?
- 7. What is an epoch? When would you use one?
+PF2. What does the version string in the Standards-Version field of a
+ package's control file represent? Why is it useful?
- 8. Explain the difference between Depends, Recommends and Suggests.
+PF3. What is the difference between native packages and non-native
+ packages?
- 9. How does Debian handle run levels? What runlevels are related? How does
- this interact with the user's local modifications? What should packages
- which require starting up and shutting down (like daemons do) do?
+PF4. There are many Debian suites, like "stable", "unstable", "testing",
+ "experimental", "sarge", "etch" and "sid". Can you explain why there
+ are so many and what the differences are? How (and when) does a
+ package get from one to the other?
- A. Tell me the differences between /usr/share and /usr/lib.
+PF5. What does the "urgency" field in changelog affect? When would you use
+ which urgency?
- B. Please list some good reasons for a package split.
+PF6. What are base, standard, optional and extra? Why are they useful?
- C. What would you need to do if upstream changed the name of the
- application? What would you do to assure smooth upgrades?
+PF7. What is Essential: yes? Why isn't libc Essential and why can't it
+ be? Why does it not need to be Essential? Why isn't the kernel
+ Essential?
- D. What is Pre-depends for? Why should you avoid it?
+PF8. Explain the difference between Depends, Recommends and Suggests.
- E. Have you ever written a manpage? If so, please tell me which. If not,
- please take a look at http://qa.debian.org/man-pages.html and
- choose a package listed there. Then please write a man page for it,
- submit it to the BTS and tell me the bug number for it please.
+PF9. What is Pre-depends for? Why should you avoid it?
- F. Please look at http://bugs.debian.org/release-critical/debian/all.html,
- choose a bug listed there (please try to find one older than a few
- days), try to create a patch to fix it and submit this patch to
- the BTS. If you can't fix the bug, you should document what
- you've found out about the bug in the BTS.
- Then prepare, if possible, a NMU and send me a pointer to your NMU patch.
- Do the same thing again for 2 other bugs with severity Important
- or higher again.
- If you couldn't fix a bug, you should send me the bug number of the
- one you tried to fix.
+PFa. Please explain me what a virtual package is. Where can you find a
+ list of defined virtual packages?
- G. Write a small shell script which does the following two things:
- a. prints whether a Debian package archive file has a copyright file
- in the appropriate location.
- b. prints out the package version from the control file which is
- inside the .deb.
- You may use tar, ar, grep, etc., but not any middle or high-level
- dpkg tools.
+PFb. There is a minimal set of packages you never need to Build-Depend
+ on. Tell me which and why.
+
+PFc. What are maintainer scripts? What arguments does each get?
+ What is the meaning of the arguments? What can each of them
+ assume about the system?
+
+PFd. If you had a file in your package which usually gets changed by a
+ administrator for local settings, how do you make sure your next version
+ of the package doesn't overwrite it?
+
+PFe. How should packages that require special permissions (such as suid bits
+ or new local system users) be handled? How do you ensure that local
+ permission changes aren't overwritten by upgrades?
+
+PFf. Write a small shell script which does the following two things:
+ a. prints whether a Debian binary package has a copyright file
+ in the appropriate location.
+ b. prints out the package version from the control file which is
+ inside the .deb.
+ You may use tar, ar, grep, etc., but not any middle or high-level
+ dpkg tools.
+
+
+Practical packaging
+-------------------
+
+If you have filed bugreports (with patches) to the BTS with respect to
+packaging issues, please tell me bug numbers, so I can check them.
+
+PP1. Imagine you maintain a package which depends very closely on some
+ other package. How would you keep track of the development of other
+ packages, even if you are not the maintainer?
+
+PP2. How can you ensure your package's description is in a good state and
+ in a valid format?
+
+PP3. You have a new package, and you finally find that it will be in
+ contrib. Why would it be there? What could you do (in theory at
+ least) to get it into main?
+
+PP4. If one of your packages had serious problems like that either
+ a) the current version in the archive is not "mature" enough
+ to be in a Debian release but it is developing and you still
+ want to maintain it
+ b) the software got abandoned upstream or got obsolete due to
+ external reasons and you consider it not "worthy" anymore
+ to be included in Debian.
+ How would you proceed in these cases?
+
+PP5. There is a bug in your package, fixed in upstream's CVS/development
+ branch. What do you do with it?
+
+PP6. What do you do if upstream releases a tarball once every year and
+ then distributes minor revisions only in the form of patches? How do
+ you manage your package then?
+
+PP7. Please list some good reasons for a package split.
+
+PP8. What would you need to do if upstream changed the name of the
+ application? What would you do to assure smooth upgrades?
+
+PP9. What would you do if a package has no sane default configuration?
+ (There is *no* default configuration that works on most systems!)
+
+PPa. What would you do if your package contains an Emacs major mode?
+ If you don't use/know Emacs then this: What would you do if your
+ package contains a perl module? Or if it is python? No Emacs, no Perl,
+ no Python? Go away. Or tell me what to do if you package something Java
+ related. :) Where would you look for more information on that?
- H. How do you check that your package can install, upgrade and remove
- itself cleanly?
Weeh, that is the first half. Take your time to answer them, but please
don't take forever. There is more waiting for you and we all want to get
this to a good end, do we?
+
+
+Bonus section
+-------------
+
+The following is part of a "bonus" section. You are not required to
+answer them, but it will help you to understand some areas/things you may
+encounter as DD. If you answer them I will give you any advice you
+need to fully understand the topic of the questions, like I do for the
+mandatory questions.
+
+PPB1. What does automake's AM_MAINTAINER_MODE do? Why is it useful for
+ Debian packages? How do you work around when your package does not
+ use it? What do you have to do when you want to enable it in your
+ package?
+
+PFB2. Dpkg does not support versioned provides.
+ Explain what that means, and list common workarounds.
Index: nm_ts2.txt
===================================================================
RCS file: /cvsroot/nm-templates/templates/nm_ts2.txt,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -d -r1.8 -r1.9
--- nm_ts2.txt 11 May 2006 20:46:37 -0000 1.8
+++ nm_ts2.txt 26 Dec 2006 23:04:33 -0000 1.9
@@ -5,93 +5,93 @@
on with the second half, which contains additional stuff I want to know
from you.
- 1. Why does a foo-dev package depend on foo?
- Why is it fooX-dev and not foo-dev in some cases?
- 2. When would you use the alternatives system, and how?
+Package Building and Uploading
+------------------------------
- 3. How can you minimize the downtime of a service during upgrade?
- Be specific about how you'd use the maintainer scripts.
+BU1. How do you manage new upstream releases?
- 4. What are FTBFS bugs? How would you avoid them?
+BU2. What are FTBFS bugs? How can you try to avoid them?
- 5. What would you do if a package has no sane default configuration?
- (There is *no* default configuration that works on most systems!)
+BU3. What is the best way to check that your Build-Depends Line contains
+ everything required to build your package?
- 6. What would you do if your package contains an Emacs major mode?
- If you don't use/know Emacs then this: What would you do if your
- package contains a perl module? Or if it is python? No Emacs, no Perl,
- no Python? Go away. Or tell me what to do if you package something Java
- related. :) Where would you look for more information on that?
+BU4. How do you check a package before you upload? How do you check that
+ your package can install, upgrade and remove itself cleanly? Please
+ explain to me why and how you perform the checks.
- 7. How does Debian maintain consistency between different window manager
- menus?
+BU5. If you want to sponsor a package upload, what do you need to do?
+ Please take a random package out of the archive and send me the
+ .changes file as it would look if you're sponsoring the upload
+ of this package.
-8a. What are base, standard, optional and extra? Why are they useful?
-8b. What is Essential: yes? Why isn't libc Essential? Why isn't the
- kernel? Why can't libc be essential? Why does libc not need to be
- essential?
+Architectures and Libraries
+---------------------------
- 9. What does the "urgency" field in changelog affect? When would you use
- which urgency?
+AL1. What does it mean for a package to have a line like
+ "Architecture: i386 alpha powerpc" in the control file?
+ What is the difference between "Architecture: all" and
+ "Architecture: any"?
- A. What are maintainer scripts? What arguments does each get?
- What is the meaning of the arguments? What can each of them
- assume about the system?
+AL2. What is an autobuilder? Where can you find information about your
+ package's build status on different architectures? What can you do
+ if you think there is a problem with the autobuilder?
- B. How does a porter handle a rebuild?
+AL3. How does a porter handle a rebuild?
-Ca. If you want to sponsor a package upload, what do you need to do?
+AL4. Tell me the differences between /usr/share and /usr/lib.
+ What would you do if you had a package which includes a mix of
+ architecture-dependent and architecture-independent files?
-Cb. Please take a random package out of the archive and send me the
- .changes file as it would look if you're sponsoring the upload
- of this package.
+AL5. What build target would you use in debian/rules to build a package
+ which includes only non-architecture-dependent files? What is the
+ "Architecture:" section for this package?
- D. What is the difference between experimental and unstable?
+AL6. What is endianess and why does it matter when supporting multiple
+ architectures?
- E. What would you do if you had a package which includes a mix of
- architecture-dependent and architecture-independent files?
+AL7. Why does a foo-dev package depend on foo?
+ Why is it fooX-dev and not foo-dev in some cases?
+ (When) is fooX-dev preferable over foo-dev?
- F. Dpkg does not support versioned provides.
- Explain what that means, and list common workarounds.
+AL8. What are library sonames, and what are they used for? What is the
+ "ELF" format?
- G. There is a minimal set of packages you never need to Build-Depend
- on. Tell me which and why.
+AL9. How does the utility "fakeroot" work? How is that tied to
+ LD_PRELOAD, and the runtime linker?
- H. What build target would you use in debian/rules to build a package
- which includes only non-architecture-dependent files? What is the
- "Architecture:" section for this package?
- I. Fundamental runtime linker knowledge:
- I0. What are library sonames, and what are they used for? What is the
- "ELF" format?
+Operating System
+----------------
- I1. How does the utility "fakeroot" work? How is that tied to
- LD_PRELOAD, and the runtime linker?
+OS1. How does Debian handle run levels? What runlevels are related? How does
+ this interact with the user's local modifications? What should packages
+ which require starting up and shutting down (like daemons do) do?
- I2. What is a symbol-versioned library? Why are libdb2, libdb3 and libc6
- compiled using symbol versioning? What problems does symbol-versioning
- solve?
+OS2. When would you use the alternatives system, and how?
- I3. What is the -Bsymbolic ld flag, what does it do exactly, and how
- does that differ from library symbol versioning? What problems
- does -Bsymbolic linking solve? Why is libc6 not compiled with
- -Bsymbolic?
+OS3. How can you minimize the downtime of a service during upgrade?
+ Be specific about how you'd use the maintainer scripts.
- J. What is endianess and why does it matter when supporting multiple
- architectures?
+OS4. How does Debian maintain consistency between different window manager
+ menus?
- K. How should packages that require special permissions (such as suid bits
- or new local system users) be handled? How do you ensure that local
- permission changes aren't overwritten by upgrades?
- L. What does automake's AM_MAINTAINER_MODE do? Why is it useful for
- Debian packages? How do you work around when your package does not
- use it? What do you have to do when you want to enable it in your
- package?
+Bonus Section
+-------------
+ALB1. What is a symbol-versioned library? Why are libdb2, libdb3 and libc6
+ compiled using symbol versioning? What problems does symbol-versioning
+ solve?
+
+ALB2. What is the -Bsymbolic ld flag, exactly what does it do, and how
+ does that differ from library symbol versioning? Which problem does
+ -Bsymbolic linking solve? Why is libc6 not compiled with -Bsymbolic?
+
+
You are finished with the questions. As I already announced with my
first T&S mail, I will check your package(s) after you've answered the
questions above. So please upload the latest and greatest version to the
archive at dak.ganneff.de and tell me the name of your package(s).
+
More information about the Nm-templates-discuss
mailing list