X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=developers-reference.git;a=blobdiff_plain;f=developers-reference.sgml;h=a4118fbd3303e9a32ef7cf8fa4fff1c9b874bd03;hp=53e34a1b3b6de72be077f7c80c1a35be4901128f;hb=057fd42386bdc2c5362a5732030935a12af47687;hpb=6df3ffbb9de1e0f5c6e89c3013799b168fa71550 diff --git a/developers-reference.sgml b/developers-reference.sgml index 53e34a1..a4118fb 100644 --- a/developers-reference.sgml +++ b/developers-reference.sgml @@ -1,20 +1,20 @@ - %versiondata; + %versiondata; - %commondata; + %commondata; - + - - FIXME: "> + + FIXME: "> ]> @@ -142,7 +142,7 @@ name="New Maintainer's Corner">. It describes exactly the preparations you have to do before you can register to become a Debian developer. -For example, before you apply, you have to to read the . Registering as a developer means that you agree with and pledge to uphold the Debian Social Contract; it is very important that @@ -350,14 +350,15 @@ Don't forget to remove the "on vacation" flag when you come back!

A big part of your job as Debian maintainer will be to stay in contact with the upstream developers. Debian users will sometimes report bugs -to the Bug Tracking System that are not specific to Debian. You -must forward these bug reports to the upstream developers so that -they can be fixed in a future release. It's not your job to fix -non-Debian specific bugs. However, if you are able to do so, you are -encouraged to contribute to upstream development of the package by -providing a fix for the bug. Debian users and developers will often -submit patches to fix upstream bugs, and you should evaluate and -forward these patches upstream. +that are not specific to Debian to our bug tracking system. You +have to forward these bug reports to the upstream developers so that +they can be fixed in a future upstream release. +

+While it's not your job to fix non-Debian specific bugs, you may freely +do so if you're able. When you make such fixes, be sure to pass them on +to the upstream maintainers as well. Debian users and developers will +sometimes submit patches to fix upstream bugs -- you should evaluate +and forward these patches upstream.

If you need to modify the upstream sources in order to build a policy compliant package, then you should propose a nice fix to the upstream @@ -417,10 +418,29 @@ resources that are available to help you in your maintainer work. Mailing lists

-The mailing list server is at &lists-host;. +Much of the conversation between Debian developers (and users) is managed +through a wide array of mailing lists we host at +. +To find out more on how to subscribe or unsubscribe, how to post and how not +to post, where to find old posts and how to search them, how to contact the +list maintainers and see various other information about the mailing lists, +please read . This section will only cover +aspects of mailing lists that are of particular interest to developers. + + Basic rules for use +

+When replying to messages on the mailing list, please do not send a +carbon copy (CC) to the original poster unless they explicitly +request to be copied. Anyone who posts to a mailing list should read +it to see the responses. +

+Cross-posting (sending the same message to multiple lists) is discouraged. +As ever on the net, please trim down the quoting of articles you're +replying to. In general, please adhere to the usual conventions for +posting messages.

-Online archives of mailing lists are available at . +Please read the +for more information. Core development mailing lists

@@ -441,40 +461,8 @@ The core Debian mailing lists that developers should use are:

-There are -other mailing lists available for a variety of special topics; see - for a list. - - Subscribing and unsubscribing -

-To subscribe to or unsubscribe from any of the Debian mailing lists, email -debian-foo-REQUEST@&lists-host;, where -debian-foo is the name of the list, with the word -subscribe in the Subject to subscribe to the list or -unsubscribe to unsubscribe. -

-If you prefer to use a web page to subscribe to multiple mailing lists, -there's one at . -

-You can download the current list of mailing lists and basic usage -instructions from -or install the doc-debian package and have it -locally in &file-mail-lists;. - - Basic rules for use -

-When replying to messages on the mailing list, please do not send a -carbon copy (CC) to the original poster unless they explicitly -request to be copied. Anyone who posts to a mailing list should read -it to see the responses. -

-Cross-posting (sending the same message to multiple lists) is discouraged. -As ever on the net, please trim down the quoting of articles you're -replying to. In general, please adhere to the usual conventions for -posting messages. -

-Please read the -for more information. +There are other mailing lists available for a variety of special topics; +see for a list. Special lists

@@ -493,6 +481,18 @@ for Debian related correspondence such as contacting upstream authors about licenses, bugs, etc. or discussing the project with others where it might be useful to have the discussion archived somewhere. + Requesting new development-related lists +

+Before requesting a mailing list that relates to the development of a +package (or a small group of related packages), please consider if using +an alias (via a .forward-aliasname file on master.debian.org, which +translates into a reasonably nice you-aliasname@debian.org +address) or a self-managed mailing list on Alioth +is more appropriate. +

+If you decide that a regular mailing list on lists.debian.org is really what +you want, go ahead and fill in a request, following . IRC channels

@@ -715,7 +715,7 @@ Those features are documented at .

The &debian-formal; distribution consists of a lot of packages (.deb's, currently around &number-of-pkgs;) and a few -additional files (such documentation and installation disk images). +additional files (such as documentation and installation disk images).

Here is an example directory tree of a complete Debian archive:

@@ -740,7 +740,7 @@ In each of the areas, there is a directory for the source packages (source) and a directory for each supported architecture (binary-i386, binary-m68k, etc.).

-The main area contains additional directories which holds +The main area contains additional directories which hold the disk images and some essential pieces of documentation required for installing the Debian distribution on a specific architecture (disks-i386, disks-m68k, etc.). @@ -808,7 +808,7 @@ The Linux 2.0 kernel supports Intel x86, DEC Alpha, SPARC, Motorola Linux 2.2 kernel supports even more architectures, including ARM and UltraSPARC. Since Linux supports these platforms, Debian decided that it should, too. Therefore, Debian has ports underway; in fact, we -also have ports underway to non-Linux kernel. Aside from +also have ports underway to non-Linux kernels. Aside from i386 (our name for Intel x86), there is m68k, alpha, powerpc, sparc, hurd-i386, arm, ia64, hppa, s390, mips, @@ -822,7 +822,7 @@ ships for the i386, m68k, alpha, and support of five new architectures: ia64, hppa, s390, mips and mipsel.

-Information for developers or uses about the specific ports are +Information for developers and users about the specific ports are available at the . @@ -887,11 +887,11 @@ distribution changes from day-to-day. Since no special effort is done to make sure everything in this distribution is working properly, it is sometimes literally unstable.

- is generated automatically by taking +"testing" is generated automatically by taking packages from unstable if they satisfy certain criteria. Those criteria should ensure a good quality for packages within testing. The update to testing is launched each day after the -new packages have been installed. +new packages have been installed. See .

After a period of development, once the release manager deems fit, the testing distribution is frozen, meaning that the policies @@ -957,7 +957,7 @@ in testing; The packages on which it depends must either be available in testing or they must be accepted into testing at the same time (and they will -if they respect themselves all the criteria); +if they respect all the necessary criteria);

To find out whether a package is progressing into testing or not, see the @@ -969,12 +969,12 @@ informed of the progression of their packages into testing.

The update_excuses file does not always give the precise reason why the package is refused, one may have to find it on their own by looking -what would break with the inclusion of the package. The gives some more information -about the usual problems which may be causing such troubles. +for what would break with the inclusion of the package. The + gives some more +information about the usual problems which may be causing such troubles.

Sometimes, some packages never enter testing because the set of -inter-relationship is too complicated and can not be sorted out +inter-relationship is too complicated and cannot be sorted out by the scripts. In that case, the release manager must be contacted, and he will force the inclusion of the packages.

@@ -1011,7 +1011,7 @@ into experimental. Whenever there is a new upstream version of a package that introduces new features but breaks a lot of old ones, it should either not be uploaded, or be uploaded to experimental. A new, beta, version of some software -which uses completely different configuration can go into +which uses a completely different configuration can go into experimental, at the maintainer's discretion. If you are working on an incompatible or complex upgrade situation, you can also use experimental as a staging area, so that testers can get early @@ -1074,8 +1074,8 @@ symbolic links for stable, testing, and

The various download archives and the web site have several mirrors available in order to relieve our canonical servers from heavy load. -In fact, some of the canonical servers aren't public, and instead a -first tier of mirrors balances the load. That way, users always access +In fact, some of the canonical servers aren't public — a first tier +of mirrors balances the load instead. That way, users always access the mirrors and get used to using them, which allows Debian to better spread its bandwidth requirements over several servers and networks, and basically makes users avoid hammering on one primary location. @@ -1097,15 +1097,16 @@ have accounts on these machines. The Incoming system

-The Incoming system is responsible of collecting updated packages and +The Incoming system is responsible for collecting updated packages and installing them in the Debian archive. It consists of a set of directories and scripts that are installed both on &ftp-master-host; and &non-us-host;.

Packages are uploaded by all the maintainers into a directory called unchecked. This directory is scanned every 15 minutes by -the katie script, which verifies the integrity of the uploaded packages and the cryptographic -signatures. If the package is considered ready to be installed, it +the katie script, which verifies the integrity of the uploaded +packages and their cryptographic signatures. +If the package is considered ready to be installed, it is moved into the accepted directory. If this is the first upload of the package, it is moved in the new directory, where it waits for an approval of the ftpmasters. If the package contains files to be installed @@ -1192,8 +1193,8 @@ available in the various distributions. Each version links to a page which provides information, including the package description, the dependencies and package download links.

-The bug tracking system track bugs for each package. You can -view the bugs of a given package at the URL +The bug tracking system tracks bugs for each package. +You can view the bugs of a given package at the URL http://&bugs-host;/package-name. The madison utility @@ -1220,12 +1221,13 @@ recompiled on most of the architectures. The Package Tracking System

-The Package Tracking System (PTS) is basically a tool to track by mail -the activity of a source package. You just have to subscribe -to a source package to start getting the mails related to it. -You get the same mails as the maintainer. Each mail -sent through the PTS is classified and associated to one of -the keyword listed below. This will let you select the mails that +The Package Tracking System (PTS) is an email-based tool to track +the activity of a source package. This really means that you can +get the same emails that the package maintainer gets, simply by +subscribing to the package in the PTS. +

+Each email sent through the PTS is classified under one of +the keywords listed below. This will let you select the mails that you want to receive.

By default you will get: @@ -1236,46 +1238,48 @@ All the bug reports and following discussions. bts-control -The control mails notifying a status change in one of the bugs. +The email notifications from control@bugs.debian.org +about bug report status changes. upload-source -The confirmation mail from katie when an uploaded source +The email notification from katie when an uploaded source package is accepted. katie-other -Other warning and error mails from katie (like the -override disparity for the section or priority field). +Other warning and error emails from katie (such as an +override disparity for the section and/or the priority field). default -Any non-automatic mail sent to the PTS by people who wanted to +Any non-automatic email sent to the PTS by people who wanted to contact the subscribers of the package. This can be done by sending mail -to srcpackage@&pts-host;. In order to prevent spam, -mails sent to these addresses must contain the header "X-PTS-Approved" -with a non-empty string. - +to sourcepackage@&pts-host;. In order to prevent spam, +all messages sent to these addresses must contain the X-PTS-Approved +header with a non-empty value. summary -In the future, you may receive regular summary mails to keep you -informed of the package's status (bug statistics, porting overview, -progression in testing, ...). +(This is a planned expansion.) +The regular summary emails about the package's status (bug statistics, +porting overview, progression in testing, ...). +

-You can also decide to receive some more information: +You can also decide to receive additional information: upload-binary -The confirmation mail from katie when an uploaded binary -package is accepted (to check that your package is recompiled for all -architectures). +The email notification from katie when an uploaded binary +package is accepted. In other words, whenever a build daemon or a porter +uploads your package for another architecture, you can get an email to +track how your package gets recompiled for all architectures. cvs -CVS commits if the maintainer has setup a system to forward commit -notification to the PTS. +CVS commit notifications, if the package has a CVS repository and the +maintainer has set up forwarding commit notifications to the PTS. ddtp @@ -1290,17 +1294,17 @@ various commands to pts@qa.debian.org. -subscribe <srcpackage> [<email>] +subscribe <sourcepackage> [<email>] Subscribes email to communications related to the source package - srcpackage. Sender address is used if the second argument is - not present. If srcpackage is not a valid source package, + sourcepackage. Sender address is used if the second argument is + not present. If sourcepackage is not a valid source package, you'll get a warning. However if it's a valid binary package, the PTS will subscribe you to the corresponding source package. -unsubscribe <srcpackage> [<email>] +unsubscribe <sourcepackage> [<email>] - Removes a previous subscription to the source package srcpackage + Removes a previous subscription to the source package sourcepackage using the specified email address or the sender address if the second argument is left out. @@ -1311,10 +1315,9 @@ various commands to pts@qa.debian.org. keyword [<email>] - Tells you the keywords that you are accepting. Each mail sent through - the Package Tracking System is associated to a keyword and you receive - only the mails associated to keywords that you are accepting. Here is - the list of available keywords: + Tells you the keywords that you are accepting. + For an explanation of keywords, see + above. Here's a quick summary: bts: mails coming from the Debian Bug Tracking System bts-control: reply to mails sent to &email-bts-control; @@ -1329,17 +1332,17 @@ various commands to pts@qa.debian.org. default: all the other mails (those which aren't "automatic") -keyword <srcpackage> [<email>] +keyword <sourcepackage> [<email>] - Same as previous item but for the given source package since + Same as the previous item but for the given source package, since you may select a different set of keywords for each source package. keyword [<email>] {+|-|=} <list of keywords> - Accept (+) or refuse (-) mails associated to the given keyword(s). + Accept (+) or refuse (-) mails classified under the given keyword(s). Define the list (=) of accepted keywords. -keyword <srcpackage> [<email>] {+|-|=} <list of keywords> +keyword <sourcepackage> [<email>] {+|-|=} <list of keywords> Same as previous item but overrides the keywords list for the indicated source package. @@ -1353,9 +1356,9 @@ various commands to pts@qa.debian.org. Filtering PTS mails

Once you are subscribed to a package, you will get the mails sent to -srcpackage@packages.qa.debian.org. Those mails +sourcepackage@packages.qa.debian.org. Those mails have special headers appended to let you filter them in a special -mailbox with procmail. The added headers are +mailbox (e.g. with procmail). The added headers are X-Loop, X-PTS-Package, X-PTS-Keyword and X-Unsubscribe.

@@ -1372,64 +1375,64 @@ X-Unsubscribe: echo 'unsubscribe dpkg' | mail pts@qa.debian.org

If you use a publicly accessible CVS repository for maintaining your Debian package you may want to forward the commit notification -to the PTS so that the subscribers (possible co-maintainers) can +to the PTS so that the subscribers (and possible co-maintainers) can closely follow the package's evolution.

-It's very easy to setup. Once your CVS repository generates commit -notifications, you just have to make sure it sends a copy of those mails -to srcpackage_cvs@&pts-host;. Only people who -accepts the cvs keyword will receive the notifications. +Once you set up the CVS repository to generate commit notifications, +you just have to make sure it sends a copy of those mails +to sourcepackage_cvs@&pts-host;. Only the people +who accept the cvs keyword will receive these notifications. The PTS web interface

-The PTS has been extended with a web interface that puts together -many information about each source package. It features many useful +The PTS has a web interface at that puts +together a lot of information about each source package. It features many useful links (BTS, QA stats, contact information, DDTP translation status, -buildd logs) and gathers many more information from various places +buildd logs) and gathers much more information from various places (30 latest changelog entries, testing status, ...). It's a very useful tool if you want to know what's going on with a specific source -package. Furthermore there's a form that let you easily subscribe to -the mail service offered by the PTS. +package. Furthermore there's a form that allows easy subscription to +the PTS via email.

You can jump directly to the web page concerning a specific source package -with an url like http://&pts-host;/srcpackage. Otherwise -you can go through the . +with a URL like http://&pts-host;/sourcepackage.

This web interface has been designed like a portal for the development of -packages: you can add custom content on the pages of your packages. You can -add "static information" (news item that are meant to stay available +packages: you can add custom content on your packages' pages. You can +add "static information" (news items that are meant to stay available indefinitely) and news items in the "latest news" section.

-Static news can be used to indicate: +Static news items can be used to indicate: -the availability of a project hosted on alioth.debian.org for co-maintaining the package -a link to the upstream website -a link to the upstream bugtracker +the availability of a project hosted on Alioth for co-maintaining the package +a link to the upstream web site +a link to the upstream bug tracker the existence of an IRC channel dedicated to the software any other available resource that could be useful in the maintenance of the package -Usual news item may be used to announce that: +Usual news items may be used to announce that: -beta packages are available for test +beta packages are available for testing final packages are expected for next week the packaging is about to be redone from scratch backports are available -the maintainer is on vacation (if he wishes to publish this information) +the maintainer is on vacation (if they wish to publish this information) a NMU is being worked on something important will affect the package

-Both kind of news are generated in a similar manner: you just have to send a mail -either to pts-static-news@qa.debian.org or to -pts-news@qa.debian.org. The mail should indicate which package is -concerned by the news by giving the name of the source package in a +Both kinds of news are generated in a similar manner: you just have to send +an email either to pts-static-news@qa.debian.org or to +pts-news@qa.debian.org. The mail should indicate which +package is concerned by having the name of the source package in a X-PTS-Package mail header or in a Package pseudo-header (like the -BTS reports). If an URL is available in the X-PTS-Url mail header or in +BTS reports). If a URL is available in the X-PTS-Url mail header or in the Url pseudo-header, then the result is a link to that URL instead of a complete news item.

-Some examples of valid mails used to generate news item in the PTS are following. The first one -adds a link to the cvsweb interface of debian-cd in the "Static information" section. +Here are a few examples of valid mails used to generate news items in +the PTS. The first one adds a link to the cvsweb interface of debian-cd +in the "Static information" section: From: Raphael Hertzog <hertzog@debian.org> To: pts-static-news@qa.debian.org @@ -1438,9 +1441,10 @@ Subject: Browse debian-cd CVS repository with cvsweb Package: debian-cd Url: http://cvs.debian.org/debian-cd/ -The second one is an announce sent to a mailing list which is also sent +

+The second one is an announcement sent to a mailing list which is also sent to the PTS so that it is published on the PTS web page of the package. Note the -use of the BCC field to avoid answers sent to the PTS by mistake ... +use of the BCC field to avoid answers sent to the PTS by mistake. From: Raphael Hertzog <hertzog@debian.org> To: debian-gtk-gnome@lists.debian.org @@ -1448,17 +1452,17 @@ Bcc: pts-news@qa.debian.org Subject: Galeon 2.0 backported for woody X-PTS-Package: galeon -Hello gnomers ! +Hello gnomers! I'm glad to announce that galeon has been backported for woody. You'll find everything here: ...

-Think twice before adding a news to the PTS because you won't be able to -remove it later and you wan't be able to edit it either. The only thing that you -can do is send a second news that will deprecate the information contained in -the first news. +Think twice before adding a news item to the PTS because you won't be able +to remove it later and you wan't be able to edit it either. The only thing +that you can do is send a second news item that will deprecate the +information contained in the previous one. Developer's packages overview

@@ -1474,6 +1478,21 @@ It is a good idea to look up your own data regularly so that you don't forget any open bug, and so that you don't forget which packages are under your responsibility. + Debian *Forge: Alioth +

+Alioth is a fairly new Debian service, based on a slightly modified version +of the GForge software (which evolved from SourceForge). This software +offers developers access to easy-to-use tools such as bug trackers, patch +manager, project/task managers, file hosting services, mailing lists, CVS +repositories etc. All these tools are managed via a web interface. +

+It is intended to provide facilities to free software projects backed or led +by Debian, facilitate contributions from external developers to projects +started by Debian, and help projects whose goals are the promotion of Debian +or its derivatives. +

+For more information please visit . + Managing Packages

@@ -1664,7 +1683,8 @@ because the dependencies of the package may vary with the distribution. In particular, it never makes sense to combine the experimental distribution with anything else (see ). - Uploads to stable + + Special case: uploads to the stable distribution

Uploading to stable means that the package will be placed into the stable-proposed-updates directory of the Debian archive for further @@ -1703,7 +1723,8 @@ verbose, if necessary) in your changelog entries for uploads to stable, because otherwise the package won't be considered for inclusion. - Uploads to testing-proposed-updates + + Special case: uploads to testing-proposed-updates

The testing distribution is fed with packages from unstable according to the rules explained in . However, the release manager may stop the testing @@ -1733,6 +1754,10 @@ to transfer the files, place them into &us-upload-dir;; if you use anonymous FTP to upload, place them into &upload-queue;.

+If you want to use feature described in , +you'll have to upload to ftp-master. It is the only upload +point that supports delayed incoming. +

Please note that you should transfer the changes file last. Otherwise, your upload may be rejected because the archive maintenance software will parse the changes file and see that not @@ -1937,8 +1962,8 @@ reorder them, and how to process and close them.

The bug tracking system's features interesting to developers are described in the . -This includes closing bugs, sending followup messages, assigning severities, -tags, marking bugs as forwarded and other issues. +This includes closing bugs, sending followup messages, assigning severities +and tags, marking bugs as forwarded and other issues.

Operations such as reassigning bugs to other packages, merging separate bug reports about the same issue, or reopening bugs when they are @@ -1972,15 +1997,18 @@ maintainer address. Responding to bugs

-Make sure that any discussion you have about bugs are sent both to -the original submitter of the bug, and the bug itself (e.g., -123@&bugs-host;). If you're writing a new +When responding to bugs, make sure that any discussion you have about +bugs is sent both to the original submitter of the bug, and to the bug +itself (e.g., 123@&bugs-host;). If you're writing a new mail and you don't remember the submitter email address, you can use the 123-submitter@&bugs-host; email to contact the submitter and to record your mail within the bug log (that means you don't need to send a copy of the mail to 123@&bugs-host;).

+If you get a bug which mentions "FTBFS", that means "Fails to build +from source". Porters frequently use this acronym. +

Once you've dealt with a bug report (e.g. fixed it), mark it as done (close it) by sending an explanation message to 123-done@&bugs-host;. If you're fixing a bug by @@ -2301,17 +2329,24 @@ When packaging the fix, keep the following points in mind: debian/changelog. For stable this is stable-security and for testing this is testing-security, and for the previous stable release, this is oldstable-security. Do not target - distribution-proposed-updates! + distribution-proposed-updates or stable! Make descriptive, meaningful changelog entries. Others will rely on them to determine whether a particular bug was fixed. - Whenever possible, include an external reference, preferably a CVE - identifier, so that it can be cross-referenced. + Always include an external reference, preferably a CVE + identifier, so that it can be cross-referenced. Include the same + information in the changelog for unstable, so that it is clear that + the same bug was fixed, as this is very helpful when verifying + that the bug is fixed in the next stable release. If a CVE + identifier has not yet been assigned, the security team will + request one so that it can be included in the package and in the advisory. Make sure the version number is proper. It must be greater than the current package, but less than package versions in later distributions. If in doubt, test it with dpkg - --compare-versions. For testing, there must be + --compare-versions. Be careful not to re-use a version + number that you have already used for a previous upload. For + testing, there must be a higher version in unstable. If there is none yet (for example, if testing and unstable have the same version) you must upload a new version to unstable first. @@ -2342,13 +2377,13 @@ When packaging the fix, keep the following points in mind: Uploading the fixed package

-DO NOT upload a package to the security upload queue +Do NOT upload a package to the security upload queue (oldstable-security, stable-security, etc.) without prior authorization from the security team. If the package does not exactly meet the team's requirements, it will cause many problems and delays in dealing with the unwanted upload.

-DO NOT upload your fix to proposed-updates without +Do NOT upload your fix to proposed-updates without coordinating with the security team. Packages from security.debian.org will be copied into the proposed-updates directory automatically. If a package with the same or a higher version number @@ -3059,7 +3094,8 @@ the Maintainer field of the debian/control file. Co-maintainers are all the other maintainers.

In its most basic form, the process of adding a new co-maintainer is -quite easy: +quite easy: +

Setup the co-maintainer with access to the sources you build the @@ -3083,10 +3119,12 @@ Using the PTS (), the co-maintainers should subscribe themselves to the appropriate source package.

+

+Collaborative maintenance can often be further eased with the use of +tools on Alioth (see ). - Best Packaging Practices

@@ -3223,7 +3261,7 @@ this using an hand-crafted debian/rules file.

The following practices are relevant to the debian/control file. They supplement the .

The description of the package, as defined by the corresponding field @@ -3300,9 +3338,9 @@ or, if the package name itself is a plural (such as package-name are synopsis. -This way of forming a sentance from the package name and synopsis +This way of forming a sentence from the package name and synopsis should be considered as a heuristic and not a strict rule. There are -some cases where it doesn't make sense to try to form a sentance. +some cases where it doesn't make sense to try to form a sentence.