+++ /dev/null
-*.aux
-*.html
-*.log
-*.lout
-*.lout.ld
-*.out
-*.pdf
-*.ps
-*.sasp
-*.sgml.validate
-*.tex
-*.text
-*.toc
-*.tpt
-*.txt
-build
-developers-reference.sasp-html
-lout.li
-version.ent
+++ /dev/null
-2004-02-29 14:10 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.174): mention build refinements
-
-2004-02-29 14:09 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.173): reburn date
-
-2004-02-29 14:09 Adam Di Carlo <aph@debian.org>
-
- * debian/rules (1.42): upcase ENTITY here too
-
-2004-02-29 14:08 Adam Di Carlo <aph@debian.org>
-
- * Makefile (1.26): enable french build
-
-2004-02-29 11:58 Adam Di Carlo <aph@debian.org>
-
- * ChangeLog (1.19): update for next release
-
-2004-02-29 11:57 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.172): prepare next release, more or less "as
- is"
-
-2003-10-19 21:09 Matt Zimmerman <mdz@debian.org>
-
- * developers-reference.sgml (1.223), debian/changelog (1.171): -
- More explicit instructions about what is appropriate for a
- security
- upload
-
-2003-08-30 06:00 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.222): nitpicking
-
-2003-08-29 11:14 Adam Di Carlo <aph@debian.org>
-
- * Makefile (1.25): split prepare from ChangeLog rules
-
-2003-08-29 11:12 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.170): remove conflict artifact
-
-2003-08-28 15:11 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.221): cleanup patch from Adam
- Garside, some of it fine tuned by myself, closes: #203202
-
-2003-08-28 14:57 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.220): cleanup patch from Adam
- Garside, some of it fine tuned by myself, closes: #202499
-
-2003-08-28 14:44 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.219): updated a policy chapter name,
- by Gustavo Franco
-
-2003-08-26 14:47 Osamu Aoki <osamu@debian.org>
-
- * developers-reference.sgml (1.218): Per Bartosz Fe?ski aka fEnIo
- <fenio@o2.pl>: typo "to to" --> "to"
-
-2003-07-30 19:17 Matt Zimmerman <mdz@debian.org>
-
- * debian/changelog (1.169): More security updates
-
-2003-07-30 19:14 Matt Zimmerman <mdz@debian.org>
-
- * developers-reference.sgml (1.217): - Don't upload security
- updates directly to stable - Always include an external reference
- in security changelog entries - Be careful not to re-use a
- version number in security uploads
-
-2003-07-24 11:06 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.168): consistency
-
-2003-07-17 20:43 Fr?d?ric Bothamy <fbothamy@mail.dotcom.fr>
-
- * debian/changelog (1.167): Update french translation to version
- 3.3.3 (more or less)
-
-2003-07-17 20:41 Fr?d?ric Bothamy <fbothamy@mail.dotcom.fr>
-
- * developers-reference.fr.sgml (1.38): Synchronize with 1.216 and
- proof-reading by Patrice Karatchentzeff
-
-2003-07-11 05:21 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.216): thinko reported by Neil Spring
-
-2003-07-11 05:18 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.215): typo reported by Neil Spring
-
-2003-07-02 12:05 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.214), debian/changelog (1.166):
- Alioth
-
-2003-07-02 07:34 Josip Rodin <joy@debian.org>
-
- * debian/changelog (1.165): updates
-
-2003-07-02 07:33 Josip Rodin <joy@debian.org>
-
- * common.ent (1.59), developers-reference.sgml (1.213):
- rearranged/updated the mailing lists section
-
-2003-07-02 07:11 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.212): thinko
-
-2003-07-02 07:10 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.211): various language issues fixed,
- based on a patch from Romain FRANCOISE
-
-2003-07-02 06:16 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.210): tiny cleanups
-
-2003-07-02 06:09 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.209): a bit of a stylistic
- clarification -- forwarding is primary, the rest is secondary
-
-2003-07-01 14:33 Adam Di Carlo <aph@debian.org>
-
- * common.ent (1.58): remove spurious CDATA notation
-
-2003-06-20 13:28 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.208): s/entity/ENTITY/
-
-2003-06-20 13:25 Adam Di Carlo <aph@debian.org>
-
- * common.ent (1.57): ampersand in URL should be &
-
-2003-06-20 13:24 Adam Di Carlo <aph@debian.org>
-
- * common.ent (1.56): s/entity/ENTITY/ (debiandoc-tidy)
-
-2003-06-17 14:33 Josip Rodin <joy@debian.org>
-
- * Makefile (1.24): removed .fr from build while broken
-
-2003-06-16 04:24 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.164): 3.3.3 is released; start 3.3.4 working
- version in case anyone wants to commit stuff
-
-2003-06-16 04:12 Adam Di Carlo <aph@debian.org>
-
- * ChangeLog (1.18): update for next release
-
-2003-06-16 04:10 Adam Di Carlo <aph@debian.org>
-
- * debian/: changelog (1.163), control (1.21): check compliance with
- Policy version 3.5.10
-
-2003-06-16 04:08 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.207), debian/changelog (1.162): Sec
- "Uploading to ftp-master": xref to "Delayed incoming"; closes:
- #195997
-
-2003-06-16 04:03 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.206), debian/changelog (1.161): Sec
- "Responding to bugs": mention what FTBFS means; closes: #186605
-
-2003-06-16 03:47 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.160): [no log message]
-
-2003-06-16 03:13 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.205): Secs "Uploads to
- {stable,testing-proposed-updates}" retitled to make it clear
- these are special cases
-
-2003-06-16 03:09 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.204): Sec "Distribution directories"
- renamed "Distributions"
-
- Sec "The testing distribution" moved under Sec "Distribution
- directories" and renamed "More information about the testing
- distribution"
-
-2003-06-16 02:52 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.159): changes so far
-
-2003-06-16 02:49 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.203): fix debconf-devel(7) man page
- section; closes: #189512
-
-2003-06-16 02:47 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.202): Sec "Managing sponsored
- packages": remove unnecessary 'debsign' cmd; closes: #192417
-
-2003-06-16 02:14 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.158): cosmetics, mark as not yet released
-
-2003-06-12 11:58 Matt Zimmerman <mdz@debian.org>
-
- * developers-reference.sgml (1.201), debian/changelog (1.157): Use
- dpkg-buildpackage -B to test binary-arch target
-
-2003-06-12 11:31 Matt Zimmerman <mdz@debian.org>
-
- * debian/changelog (1.156): Security updates
-
-2003-06-12 08:59 Matt Zimmerman <mdz@debian.org>
-
- * developers-reference.sgml (1.200): Misc. clarifications and
- additions to the section on security bugs
-
- Deprecate security uploads to stable, and point to the security
- instructions instead
-
-2003-05-24 16:25 Raphaël Hertzog <hertzog@debian.org>
-
- * developers-reference.sgml (1.199), debian/changelog (1.155): -
- Documented how to add custom content to the PTS.
-
-2003-05-04 11:09 Raphaël Hertzog <hertzog@debian.org>
-
- * developers-reference.sgml (1.198), debian/changelog (1.154): -
- Updated PTS documentation. - Added a paragraph about the PTS web
- interface.
-
-2003-05-04 10:32 Osamu Aoki <osamu@debian.org>
-
- * developers-reference.fr.sgml (1.37): put </translator> to prevent
- errors under older debiandoc-sgml
-
-2003-05-01 19:00 Fr?d?ric Bothamy <fbothamy@mail.dotcom.fr>
-
- * developers-reference.fr.sgml (1.36): Corrections thanks to Michel
- Grentzinger
-
-2003-05-01 18:58 Fr?d?ric Bothamy <fbothamy@mail.dotcom.fr>
-
- * debian/changelog (1.153): Minor corrections to french translation
-
-2003-04-18 09:50 Adam Di Carlo <aph@debian.org>
-
- * ChangeLog (1.17): update for next release
-
-2003-04-18 09:49 Adam Di Carlo <aph@debian.org>
-
- * debian/: changelog (1.152), control (1.20): debiandoc-sgml 1.1.76
- source depends
-
-2003-04-18 09:30 Adam Di Carlo <aph@debian.org>
-
- * ChangeLog (1.16): update for next release
-
-2003-04-18 09:21 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.151): prepare 3.3.2
-
-2003-04-17 17:47 Fr?d?ric Bothamy <fbothamy@mail.dotcom.fr>
-
- * developers-reference.fr.sgml (1.35): Synchronize with 1.197
- (version 3.3.1) and proof-reading by Philippe Batailler and
- Patrice Karatchentzeff
-
-2003-04-17 17:43 Fr?d?ric Bothamy <fbothamy@mail.dotcom.fr>
-
- * debian/changelog (1.150): Update french translation to version
- 3.3.1
-
-2003-04-04 16:03 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.149): start next version
-
-2003-04-04 14:28 Adam Di Carlo <aph@debian.org>
-
- * ChangeLog (1.15): update for next release
-
-2003-04-04 14:27 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.148): 3.3.1 ready for release
-
-2003-04-02 15:13 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.147): Josip's recent changes
-
-2003-04-02 15:05 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.146): some of my recent changes
-
-2003-04-02 15:04 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.197): Sec "Multiple binary
- packages": fix awkward wording about vim source package; closes:
- #187143; some notes and FIXMES which need to be dealt with
-
-2003-04-02 14:52 Adam Di Carlo <aph@debian.org>
-
- * common.ent (1.55): fix doc-check URL; closes: #187144
-
-2003-03-24 08:38 Josip Rodin <joy@debian.org>
-
- * common.ent (1.54), developers-reference.sgml (1.196): fixed up
- the section on reporting bugs
-
-2003-03-24 08:16 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.195): improved the general bugs
- section
-
-2003-03-19 14:18 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.194): added an id for linking to the
- description of experimental, and sources.list lines for it
-
-2003-03-14 11:53 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.193): more noticeable separated
-
-2003-03-01 14:09 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.192), debian/changelog (1.145): the
- synopsis formula changed to either <package-name> is a
- <synopsis> or <package-name> is <synopsis> or <package-name>
- are <synopsis> closes: #182956
-
- the synopsis itself should not start with an article
-
-2003-03-01 13:58 Adam Di Carlo <aph@debian.org>
-
- * debian/: changelog (1.144), control (1.19): try to comply with
- our own recommendations on package synopsis; improve the package
- descriptions
-
-2003-02-26 17:17 Josip Rodin <joy@debian.org>
-
- * debian/: changelog (1.143), control (1.18): fixed package
- descriptions, closes: #182614
-
-2003-02-24 14:59 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.142): start next version
-
-2003-02-24 13:50 Adam Di Carlo <aph@debian.org>
-
- * ChangeLog (1.14): update for next release
-
-2003-02-24 13:29 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.141): prepare 3.3 for release
-
-2003-02-24 13:12 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.191): two little updates
-
-2003-02-23 13:54 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.140): recent changes, date burn the changelog
- entry -- I think we are ready for release
-
-2003-02-23 13:54 Adam Di Carlo <aph@debian.org>
-
- * common.ent (1.53), developers-reference.sgml (1.190): primary
- author is developers-reference@packages.debian.org; remove emails
- from other authors to prevent spam
-
-2003-02-23 13:44 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.189): bpp-debian-maint-scripts -
- move down to where debconf is, no content changes at all
-
- bpp-debian-control - more suggestions from IRC
-
-2003-02-23 12:59 Adam Di Carlo <aph@debian.org>
-
- * Makefile (1.23): clean is cleaner
-
-2003-02-23 12:58 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.188): some changes to
- bpp-debian-control from Sebastian Rittau
-
-2003-02-23 03:53 Adam Di Carlo <aph@debian.org>
-
- * .cvsignore (1.7): [no log message]
-
-2003-02-23 03:48 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.187), debian/changelog (1.139):
- rework "Best practices for debian/control" based on contributions
- from Colin Walters, Branden Robinson, and discussions on bugs
- 139957 and 108416
-
-2003-02-22 17:16 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.186): another typo fix and a
- clarification of my sentence
-
-2003-02-22 17:12 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.185): removed the extra copy of
- life, universe and everything ;) and tidied up another paragraph
-
-2003-02-22 16:05 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.184): Sec bpp-archindepdata:
- editorial changes
-
-2003-02-22 15:59 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.183): bpp-archindepdata: eliminate
- leading space, no change in content at all
-
-2003-02-22 15:57 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.182): move bpp-debian-changelog to
- be right after bpp-debian-control section
-
-2003-02-22 15:54 Adam Di Carlo <aph@debian.org>
-
- * debian/: changelog (1.138), control (1.17), tocsubstvars (1.3):
- proper escaping of single quotes in the pkg description/TOC
- requires newest debhelper
-
-2003-02-22 15:51 Adam Di Carlo <aph@debian.org>
-
- * common.ent (1.52), developers-reference.sgml (1.181):
- s|bugs.debian.org|&bugs-host;|
- s|<email>control@bugs.debian.org</email>|&email-bts-control;|
-
- <sect1>When bugs are closed by new uploads -- minor editorial
- changes
-
- <sect>Best practices for debian/changelog -- substantial editing,
- although mostly editorial, few content changes
-
- in "Tools", debdiff and dpkg-depcheck link to their package,
- devscripts
-
-2003-02-22 14:15 Josip Rodin <joy@debian.org>
-
- * common.ent (1.51), developers-reference.sgml (1.180): tidied up
- the db.d.o stuff
-
-2003-02-22 13:54 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.179): tidied up the vacation section
-
-2003-02-22 13:36 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.178): rephrased and expanded the
- voting section a little bit
-
-2003-02-22 13:14 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.177): moved the remaining sections
- that aren't just about uploads up one level
-
-2003-02-19 05:50 Josip Rodin <joy@debian.org>
-
- * debian/rules (1.41): dpkg-parsechangelog is noisy when you make a
- syntax error, but we don't need that noisiness here
-
-2003-02-19 05:48 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.176): plug bpp-debian-changelog a
- little bit
-
-2003-02-15 20:47 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.175), debian/changelog (1.137):
- minor typographical changes
-
-2003-02-15 07:03 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.174), debian/changelog (1.136):
- added a link to the policy, and explained the current practice in
- the synopsis section. this is a compromise as it doesn't
- expressly conflict with Manoj's or jaq's POV :) closes: #174161
-
-2003-02-15 06:29 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.173), debian/changelog (1.135):
- debdiff and dpkg-depcheck, closes: #172897
-
-2003-02-14 10:02 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.172): better phrased
-
-2003-02-14 09:52 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.171), debian/changelog (1.134):
- added best practices for debian/changelog, based on a patch from
- Daniel Kobras, closes: #166388
-
-2003-02-14 05:40 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.170): another sentence to clarify it
- further
-
-2003-02-12 09:42 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.169), debian/changelog (1.133):
- added a section describing how to handle large amounts of
- architecture-independent data bundled with programs
-
-2003-01-27 15:21 Adam Di Carlo <aph@debian.org>
-
- * debian/: rules (1.40), tocsubstvars (1.2): use of tocsubstvars,
- minor cosmetics and notes
-
-2003-01-27 14:45 Adam Di Carlo <aph@debian.org>
-
- * debian/: .cvsignore (1.2), changelog (1.132): recent changes
-
-2003-01-27 14:41 Adam Di Carlo <aph@debian.org>
-
- * debian/tocsubstvars (1.1): script to make the manual TOC into a
- substvar for debian/control description use
-
-2003-01-26 06:01 Josip Rodin <joy@debian.org>
-
- * debian/rules (1.39): :)
-
-2003-01-26 04:19 Adam Di Carlo <aph@debian.org>
-
- * debian/control (1.16): multiple packages, use the english TOC for
- all until we can use UTF8 data here
-
-2003-01-26 04:18 Adam Di Carlo <aph@debian.org>
-
- * Makefile (1.22): top-level makefile deletes target on error
-
-2003-01-26 04:16 Adam Di Carlo <aph@debian.org>
-
- * .cvsignore (1.6), developers-reference.desc (1.13),
- developers-reference.fr.desc (1.2), developers-reference.ja.desc
- (1.2), debian/.cvsignore (1.1), debian/changelog (1.131),
- debian/compat (1.1), debian/developers-reference-fr.doc-base
- (1.1), debian/developers-reference-ja.doc-base (1.1),
- debian/developers-reference.doc-base (1.1), debian/postinst
- (1.8), debian/prerm (1.7), debian/rules (1.38): convert to
- debhelper (compat mode 4); maintainer scripts no longer needed
-
- split -ja and -fr versions out into separate packages
-
-2003-01-22 20:16 Josip Rodin <joy@debian.org>
-
- * developers-reference.fr.sgml (1.34), developers-reference.ja.sgml
- (1.12): removing old tags from translations. hope it isn't a
- major screwup for .ja
-
-2003-01-22 20:13 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.168), common.ent (1.50):
- file-bts-mailing (server-request) doesn't really provide more
- information on override files, and file-bts-info (Developer) now
- has a maintincorrect anchor in it, so use that
-
-2003-01-22 20:04 Josip Rodin <joy@debian.org>
-
- * debian/TODO (1.7): oh, look, i fixed that.
-
-2003-01-22 20:02 Josip Rodin <joy@debian.org>
-
- * debian/changelog (1.130): update
-
-2003-01-22 19:59 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.167): the ordering of sections and
- their content in the packages chapter was SNAFU; this should fix
- most of that. (note to translators: the bottom, larger part of
- this diff is because of moving sections around, no content
- changes)
-
-2003-01-22 17:42 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.166): alleviating some of the
- confusion with sections and subsections, prompted by Florian
- Hinzmann's mail on -policy; fixing some weird sections (the
- package uploads chapter needs more work...)
-
-2003-01-19 17:17 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.165): a better explanation for the
- which(1) situation
-
-2003-01-19 17:09 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.164): irc alias was updated to
- freenode; mention oftc
-
-2003-01-19 17:05 Josip Rodin <joy@debian.org>
-
- * common.ent (1.49), developers-reference.sgml (1.163): slightly
- rearranged the db.d.o section
-
-2003-01-19 16:44 Josip Rodin <joy@debian.org>
-
- * common.ent (1.48): hmm, www.d.o wasn't in the entity
-
-2003-01-19 16:42 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.162): describe/plug the testing web
- page better
-
-2003-01-19 15:57 Josip Rodin <joy@debian.org>
-
- * developers-reference.desc (1.12), developers-reference.fr.desc
- (1.1), developers-reference.ja.desc (1.1), debian/changelog
- (1.129), debian/postinst (1.7), debian/prerm (1.6), debian/rules
- (1.37): split translations into different doc-base files
-
-2003-01-18 11:25 Raphaël Hertzog <hertzog@debian.org>
-
- * developers-reference.sgml (1.161), debian/changelog (1.128): -
- Updated the PTS doc with the "ddtp" keyword.
-
-2003-01-02 12:55 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.160): oops
-
-2003-01-02 08:26 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.159): updated sect1 multiple-patches
- to have a better title/introduction and to mention dpatch
- (prompted by Joerg Jaspert)
-
-2003-01-02 04:21 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.158): commented out changes only:
- remove todo items
-
-2003-01-02 04:10 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.157), debian/changelog (1.127),
- debian/copyright (1.5): update copyright year
-
-2003-01-01 18:57 Fr?d?ric Bothamy <fbothamy@mail.dotcom.fr>
-
- * debian/changelog (1.126): Update french version to latest
- version.
-
-2003-01-01 18:54 Fr?d?ric Bothamy <fbothamy@mail.dotcom.fr>
-
- * developers-reference.fr.sgml (1.33): Synchronize with 1.153 and
- proofread by P. Batailler.
-
-2002-12-21 14:03 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.156): noted that debian-devel (not
- -private! boo!) can be contacted to ask about a missing
- maintainer; rephrased the stuff about conflicts and mentioned the
- ways of resolving such issues
-
-2002-12-21 13:53 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.155): replaced the mia-qa section
- with what Martin Michlmayr wrote, plus proofreading by myself
-
-2002-12-21 13:36 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.154): moved the contacting
- maintainers section above the one about being unable to contact
- maintainers (mmmh, logic)
-
-2002-12-12 15:08 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.153): replaced ASCII with plain
- text, since not all plain text is ASCII
-
-2002-12-12 13:47 Adam Di Carlo <aph@debian.org>
-
- * ChangeLog (1.13): update for next release
-
-2002-12-12 13:45 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.125): prepare 3.2.2
-
-2002-12-12 13:44 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.152): Sec "Upstream home page": some
- revisions based on discussion on policy list
-
- Sec "Documentation" added under Sec "Common packaging situations"
- for best practices for documentation
-
- Add tools entries for autotools-dev, dpkg-repack, alien, debsums;
- new Sec "Documentation and information", add entries there for
- debview, debiandoc-sgml, debian-keyring; we believe this manual
- now covers all of the established, general Debian maintainer tool
- packages
-
- spell-checking pass
-
-2002-12-12 13:42 Adam Di Carlo <aph@debian.org>
-
- * debian/rules (1.36): ship README-contrib and TODO in the doc dir
-
-2002-12-12 13:41 Adam Di Carlo <aph@debian.org>
-
- * debian/TODO (1.6): remove some todo items which are done
-
-2002-12-09 14:26 Adam Di Carlo <aph@debian.org>
-
- * debian/: changelog (1.124), control (1.15): Policy compliance
- checked and updated to 3.5.8, no changes needed
-
-2002-12-09 08:14 Josip Rodin <joy@debian.org>
-
- * debian/changelog (1.123): update
-
-2002-12-09 08:09 Josip Rodin <joy@debian.org>
-
- * common.ent (1.47): merged url-debian-mirror{s,ing}, the ftplist
- page is deprecated and the mirror page lists all
-
-2002-12-09 08:08 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.151): slightly rewrote the mirrors
- section and moved it below the description of the archive (seems
- more logical)
-
-2002-12-09 03:05 Adam Di Carlo <aph@debian.org>
-
- * ChangeLog (1.12): update for next release
-
-2002-12-09 03:04 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.122): prepare 3.2.1
-
-2002-12-09 03:00 Adam Di Carlo <aph@debian.org>
-
- * Makefile (1.21): use the debiandoc2* tools for PS and PDF
- generation
-
-2002-12-09 02:23 Adam Di Carlo <aph@debian.org>
-
- * debian/rules (1.35): stop shipping SGML source, what's the point,
- this is a binary pkg, the SGML doesn't have the proper build
- depends, you can't build it in those dirs anyway -- much better
- to do 'apt-get source developers-reference'
-
-2002-12-09 02:16 Adam Di Carlo <aph@debian.org>
-
- * debian/rules (1.34): eliminate the ByHand stuff, I'm pretty sure
- it's not needed now with the DDP builder process, or if it is
- needed, it's a probably that can be fixed by DDP folks
-
-2002-12-09 02:15 Adam Di Carlo <aph@debian.org>
-
- * common.ent (1.46), developers-reference.sgml (1.150): - Sec
- "Best practices for debian/control" added, Sec "Writing useful
- descriptions" moved under there
- - Sec "Upstream home page" added in debian/control section
- - Sec "Miscellaneous advice" empty, removed
- - Sec "Overview of maintainer tools": tools now categorized
- into
- subgroups; do cross-linking from this section into other
- parts of
- the document where these tools are discussed
- - Sec "Overview of maintainer tools": add entries for sbuild,
- build-essential, linda; improved entries for pbuilder,
- devscripts
- - Sec "Tools for porters" renamed and readapted to "Porting
- infrastructure and automation"; move tool discussion down
- to the
- appendix; improve Sec "buildd" a bit
- - README-contrib added giving information for authors,
- contributors,
- and translators
-
-2002-12-09 02:08 Adam Di Carlo <aph@debian.org>
-
- * README-contrib (1.1): readme for contributores, including
- translators
-
-2002-12-08 17:54 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.149): Internationalized
- documentation had the wrong sectional capitalization
-
-2002-12-07 02:28 Adam Di Carlo <aph@debian.org>
-
- * ChangeLog (1.11): update for next release
-
-2002-12-07 02:27 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.121): all my recent changes, and call it
- version 3.2
-
-2002-12-07 02:26 Adam Di Carlo <aph@debian.org>
-
- * common.ent (1.45), developers-reference.sgml (1.148): Sec "Best
- practices for maintainer scripts" added, special credit here to
- Charles Briscoe-Smith for work dating back to 1998; include a
- POSIX shell snippet showing how to check if a command is the
- PATH, closes: #150384
-
-2002-12-07 01:53 Adam Di Carlo <aph@debian.org>
-
- * Makefile (1.20): validation suffix rule now requires version.ent
-
-2002-12-07 01:49 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.147): remove debget from tools
- section, add notes on more tools to document
-
-2002-12-07 01:35 Adam Di Carlo <aph@debian.org>
-
- * debian/prerm (1.5): don't use 'command -v', it's not POSIX,
- hardcode /usr/sbin/install-docs
-
-2002-12-07 01:34 Adam Di Carlo <aph@debian.org>
-
- * debian/postinst (1.6): why even have a case stmt -- strip it down
- more
-
-2002-12-07 01:26 Adam Di Carlo <aph@debian.org>
-
- * debian/rules (1.33): produce md5sums file; break out a 'test'
- target
-
-2002-12-07 01:21 Adam Di Carlo <aph@debian.org>
-
- * debian/postinst (1.5): move configure stuff under configure case;
- don't make usr/doc symlink
-
-2002-12-06 15:45 Adam Di Carlo <aph@debian.org>
-
- * common.ent (1.44), developers-reference.sgml (1.146): - Sec
- "Common situations" renamed to "Common packaging situations" -
- Sec "Other specific packages" renamed to "Specific types of
- packages", add info for SGML/XML and Lisp packages - Sec "Writing
- useful descriptions" heavily edited
-
-2002-12-06 05:22 Adam Di Carlo <aph@debian.org>
-
- * translation-status (1.4): damn cvs keywords, inhibit
-
-2002-12-06 05:10 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.145): - Ch "Packaging Practices"
- rewritten intro - Sec "Packaging tools and common cases" renamed
- to "Best Practices for debian/rules", and write an intro - Sec
- "Helper scripts" in practices section rewritten, giving
- arguments for and against debhelper, mostly for :) - Sec "Package
- with multiple patches" renamed to "Patching source versus
- patching at build time" and rewritten - Sec "Multiple binary
- packages" rewritten - Sec "Handling debconf translations" moved
- under an "Internationalization" section, and some edits - Sec
- "Internationalized Documentation" added under Sec
- "Internationalization" - Sec "Specific packaging practices"
- renamed to "Common Situations" - Sec "Packages using
- autoconf/automake" rewritten - Sec "Configuration management"
- moved forward in practices chapter
-
-2002-12-06 05:00 Adam Di Carlo <aph@debian.org>
-
- * translation-status (1.3): retab, no content changes
-
-2002-12-06 04:59 Adam Di Carlo <aph@debian.org>
-
- * translation-status (1.2): adapt script to local context, strip
- out useless -V option too
-
-2002-12-06 04:56 Adam Di Carlo <aph@debian.org>
-
- * common.ent (1.43): doc-check reference for best-practices, doc
- translations
-
-2002-12-06 04:50 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.desc (1.11): expand the doc-base abstract
- and authors
-
-2002-12-06 04:49 Adam Di Carlo <aph@debian.org>
-
- * translation-status (1.1): translation status checking tool, based
- on documentation/doc-check from boot-floppies source, rev 1.12
-
-2002-12-05 18:21 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.144): fix typo, closes: #171781
-
-2002-12-05 16:19 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.143): typo fix, thanks Alfie Costa
-
-2002-12-03 11:36 Josip Rodin <joy@debian.org>
-
- * debian/changelog (1.120): update
-
-2002-12-03 11:30 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.142): added spaces between ©
- and the first year (wonder if that was intentional?); merged a
- bit misplaced lintian-reports section within the lintian section
- and adjusted links; added the missing description of dh-make and
- adjusted links
-
-2002-11-27 21:17 Adam Di Carlo <aph@debian.org>
-
- * ChangeLog (1.10): update for next release
-
-2002-11-27 21:16 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.119): prepare 3.1.2
-
-2002-11-27 21:14 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.141): Sec "Handling debconf
- translations", updates from Martin Quinson for po-debconf with
- minimal editorial changes, closes: #169007
-
-2002-11-27 19:40 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.desc (1.10): doc-base file includes French
- and Japanese files
-
-2002-11-27 19:40 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.140): debsign invocation was
- slightly wrong, closes: #170523
-
-2002-11-18 14:53 Josip Rodin <joy@debian.org>
-
- * Makefile (1.19): updated PUBLISHDIR
-
-2002-11-12 23:23 Adam Di Carlo <aph@debian.org>
-
- * ChangeLog (1.9): update for next release
-
-2002-11-12 23:18 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.118): finalize version 3.1.1
-
-2002-11-11 15:38 Adam Di Carlo <aph@debian.org>
-
- * common.ent (1.42), developers-reference.sgml (1.139),
- debian/changelog (1.117): fix some bad URLs, notably the testing
- FAQ -- checkbot reports all is well now
-
-2002-11-11 13:40 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.138), debian/changelog (1.116): fix
- a grammar typo, closes: #166098
-
-2002-11-11 13:37 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.115): don't use caps or fullstops in
- changelog entries -- a bug I fixed
-
-2002-11-11 13:33 Adam Di Carlo <aph@debian.org>
-
- * common.ent (1.41): fix bad debian emacs policy, closes: #168357
-
-2002-10-21 12:07 Matt Zimmerman <mdz@debian.org>
-
- * developers-reference.sgml (1.137), debian/changelog (1.114):
- Security updates
-
-2002-10-10 17:09 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.136): the version of dpkg-dev that
- supports this feature is no longer new, so skip that; also
- rephrased the sentence better while i was at it
-
-2002-10-10 17:01 Josip Rodin <joy@debian.org>
-
- * debian/changelog (1.113): update
-
-2002-10-10 17:00 Josip Rodin <joy@debian.org>
-
- * common.ent (1.40), developers-reference.sgml (1.135):
- fixed/updated/extended stuff about bugs. this should probably
- address the issue of people abusing the changelog bug closing
- stuff.
-
-2002-09-21 10:58 Raphaël Hertzog <hertzog@debian.org>
-
- * developers-reference.sgml (1.134), debian/changelog (1.112): -
- Added myself as co-author. - Fix a typo in Sec "Collaborative
- maintenance". Closes: #161488
-
-2002-09-19 07:01 Josip Rodin <joy@debian.org>
-
- * debian/changelog (1.111): update for my last change
-
-2002-09-19 06:50 Josip Rodin <joy@debian.org>
-
- * common.ent (1.39), developers-reference.sgml (1.133): updated IRC
- stuff based on patch from SynrG, closes: #161403
-
-2002-09-11 12:32 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.132): tagging improvements and
- editorial improvements in config-wise-debconf
-
-2002-09-10 22:02 Adam Di Carlo <aph@debian.org>
-
- * ChangeLog (1.8): update for next release
-
-2002-09-10 21:58 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.110): my changes
-
-2002-09-10 21:56 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.131): spell checking, tag fixes,
- editorial review -- no new content
-
-2002-09-09 06:08 Raphaël Hertzog <hertzog@debian.org>
-
- * developers-reference.sgml (1.130): - Also mentions sending patchs
- in the BSP section.
-
-2002-09-09 05:46 Raphaël Hertzog <hertzog@debian.org>
-
- * developers-reference.sgml (1.129), debian/changelog (1.109):
- - Added a section about "Bug Squashing Parties".
-
-2002-09-08 14:42 Raphaël Hertzog <hertzog@debian.org>
-
- * common.ent (1.38), developers-reference.sgml (1.128),
- debian/changelog (1.108): - Added the explanation about how to
- replace an .orig.tar.gz. closes: #150392 - Mostly deleted the
- paragraph about security upload in the section explaining
- source NMU. Just added a link to point to "Handling
- security-related bugs". closes: #159935 - Added a link to the
- Technical Committee web page (in the "Bug housekeeping"
- section). closes: #151365 - Explain uploads to
- testing-proposed-updates, mentions briefly stable-security and
- testing-security. closes: #149666 Removed the comment about
- uploads to frozen. - Documented the "Developer's packages
- overview" web portal. closes: #158650 - Added a reference to
- debian-l10n-english in "Writing useful descriptions". closes:
- #158609 - Added a Best Packaging Practice section for "Packages
- using autoconf/automake". closes: #158045 - Documented
- associated features to db.debian.org like SSH key replication
- and *.debian.net DNS entry. closes: #155389
-
-2002-09-03 06:44 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.127): updated the
- when-to-do-source-NMUs section a little bit, prompted by Elie
- Rosenblum's complaint on -devel
-
-2002-08-29 11:47 Matt Zimmerman <mdz@debian.org>
-
- * developers-reference.sgml (1.126): Update security instructions
- to specify that uploads should not be made to the security queue
- without approval Misc fixes and cleanups to security section
-
-2002-08-29 11:36 Raphaël Hertzog <hertzog@debian.org>
-
- * common.ent (1.37), developers-reference.sgml (1.125),
- debian/changelog (1.107): * Applied patch from Matt Zimmerman for
- handling security related bugs.
-
-2002-08-17 15:37 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.124): renamed the testing scripts
- section to a more generic testing distribution, and added missing
- <em>s around some references to it (which were potentially
- confusing without that)
-
-2002-08-17 15:22 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.123): HTTP is not just usually, it's
- always
-
-2002-08-17 13:31 Josip Rodin <joy@debian.org>
-
- * common.ent (1.36), developers-reference.fr.sgml (1.32),
- developers-reference.ja.sgml (1.11), developers-reference.sgml
- (1.122): oopsie, that URL was pointing to the wrong place :)
-
-2002-08-16 11:26 Josip Rodin <joy@debian.org>
-
- * debian/changelog (1.106): update
-
-2002-08-16 10:39 Josip Rodin <joy@debian.org>
-
- * common.ent (1.35): changed needlessly FTP URIs to HTTP; added
- debian-project
-
-2002-08-16 10:23 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.121): rewrote the mailing lists
- section to have logical subsections; expanded on the meanings of
- the core mailing lists
-
-2002-08-16 07:34 Josip Rodin <joy@debian.org>
-
- * debian/changelog (1.105): update
-
-2002-08-16 07:30 Josip Rodin <joy@debian.org>
-
- * common.ent (1.34), developers-reference.sgml (1.120): following
- Ryan Murray's advice, removed servers' real names and used only
- service names.
-
-2002-08-07 07:58 Josip Rodin <joy@debian.org>
-
- * debian/changelog (1.104): updated
-
-2002-08-07 07:57 Josip Rodin <joy@debian.org>
-
- * common.ent (1.33), developers-reference.sgml (1.119): updated
- (people.d.o->gluck), expanded (non-US) and mostly rewrote the
- Debian servers section
-
-2002-08-07 06:52 Josip Rodin <joy@debian.org>
-
- * debian/changelog (1.103): added some of my June 20th changes to
- the changelog
-
-2002-06-24 15:28 Raphaël Hertzog <hertzog@debian.org>
-
- * developers-reference.sgml (1.118), debian/changelog (1.102): *
- Applied several patches.
-
-2002-06-20 16:59 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.117): language fixes in a paragraph
-
-2002-06-20 16:34 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.116): linguistic fixes from David
- Kimdon; other proofreading by myself, mostly changing he -> they
-
-2002-06-19 15:58 Raphaël Hertzog <hertzog@debian.org>
-
- * developers-reference.sgml (1.115), debian/changelog (1.101): *
- New changelog entry. * Fixed some entities (missing ";" in
- "—"). * Applied patch from Peter Palfrader. closes:
- #150427
-
-2002-06-19 15:16 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.114): removed obsolete, needless
- dupload variables
-
-2002-06-15 20:30 Raphaël Hertzog <hertzog@debian.org>
-
- * developers-reference.sgml (1.113): * Sec "Writing useful
- descriptions". Added a sentence about the capitalization of the
- first letter.
-
-2002-06-14 02:27 Adam Di Carlo <aph@debian.org>
-
- * ChangeLog (1.7): update for next release
-
-2002-06-14 02:26 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.100): my changes; standardize Raphael's
- changelog entries
-
-2002-06-14 02:19 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.112): populate Sec "Collaborative
- maintenance"
-
-2002-06-14 01:15 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.111): spelling fixes and some
- awkward wordings fixed
-
-2002-06-14 00:29 Adam Di Carlo <aph@debian.org>
-
- * debian/TODO (1.5): more notes to myself, many probably obsolete
-
-2002-06-10 03:31 Raphaël Hertzog <hertzog@debian.org>
-
- * common.ent (1.32), developers-reference.sgml (1.110),
- debian/changelog (1.99): - Integrated Sec "Handling debconf
- translations" contributed by Denis Barbier. Thanks Denis !
-
-2002-06-08 16:29 Raphaël Hertzog <hertzog@debian.org>
-
- * common.ent (1.31), developers-reference.sgml (1.109),
- debian/changelog (1.98): - Completed Sec "Package with multiple
- patches", "Multiple binary packages", "Libraries", "Other
- specific packages", "The wise use of debconf". All those are
- quite simplistic, they can be improved ...
-
-2002-05-23 20:17 Raphaël Hertzog <hertzog@debian.org>
-
- * common.ent (1.30), developers-reference.sgml (1.108),
- debian/changelog (1.97): - Completed Sec "Voting" - Completed Sec
- "Documentation" - Added Sec "IRC channels" in the Resources
- chapter. - Added Sec "pbuilder" in the appendix. Mention it in
- the being kind to porter too. - Extended the explanation about
- devscripts. - Completed Sec "Helper scripts"
-
-2002-05-23 16:03 Raphaël Hertzog <hertzog@debian.org>
-
- * developers-reference.sgml (1.107), debian/changelog (1.96): -
- Completed Sec Bug housekeeping. closes: #39519 - Stubbed sections
- for all ideas for "Best Packaging Practices". We have to either
- fill them or comment them out. I've put some notes about the
- content of each of those sections to help the writers.
-
-2002-05-12 04:36 Raphaël Hertzog <hertzog@debian.org>
-
- * developers-reference.sgml (1.106): - Fixed the URL in Sec "Bug
- Reporting"
-
-2002-05-11 23:33 Osamu Aoki <osamu@debian.org>
-
- * developers-reference.ja.sgml (1.10): Sorry, this bugs broke DDP
- site build process.
-
- I saw simple typos (missing ";") and <ftppath>-tags which does
- not exist in English. This was good iontension but used in
- conflict with the current common.ent.
-
- I hopefully used 8-bit clean editor (vimand mcedit in LC_ALL=C).
- I do not have LANG=ja_JP in my system :( Shame on me.
-
- Now DDP site shall build :)
-
-2002-05-11 16:10 Adam Di Carlo <aph@debian.org>
-
- * common.ent (1.29), developers-reference.sgml (1.105),
- debian/changelog (1.95): entity'ize master.debian.org,
- us-upload-dir, non-us-upload-dir
-
- tagging improvements: replace <tt> with <file> for files and
- directories; since <tt><var> and <example><var> doesn't look
- right, work-around with <...>
-
- fix some awkward working from recent updates
-
-2002-05-10 16:27 Raphaël Hertzog <hertzog@debian.org>
-
- * developers-reference.sgml (1.104): * Sec "Writing useful
- descriptions": added a blurb about spell-checking.
-
-2002-05-09 18:24 Raphaël Hertzog <hertzog@debian.org>
-
- * developers-reference.sgml (1.103), debian/changelog (1.94): - Sec
- "The Package Tracking System": filled with content from
- Francesco Paolo Lovergine. Heavily updated by myself. - New
- Section "Managing sponsored packages" contributed by Francesco
- Paolo Lovergine. Slightly updated by myself.
-
-2002-05-09 13:43 Raphaël Hertzog <hertzog@debian.org>
-
- * common.ent (1.28), developers-reference.sgml (1.102),
- debian/changelog (1.93): - Various spelling fixes. - Sec
- "Developer Database": added a sentence about finger
- login@debian.org. - Update the total number of packages and the
- example directory tree of a Debian archive. - Updated the list
- of available architectures. - Commented out the "Subsections"
- section since it will RSN have nothing to with the Debian
- archive. It's just a generic information field of the package
- and nothing more. - Added more incentive to use experimental
- since it doesn't cause any pains to the ftpmasters. - Sec
- "When to do a source NMU": updated the NMU "protocol" and suggest
- the use of the delayed queue. - New Section "Acknowledging the
- NMUs" to explain the need to integrate the changes introduced
- by NMUs. Insists on the fact that one shouldn't be upset by a
- NMU. - Stubbed in new Section "Collaborative maintenance". -
- Stubbed in new Section "The Package Tracking System".
-
-2002-05-09 05:45 Raphaël Hertzog <hertzog@debian.org>
-
- * common.ent (1.27), developers-reference.sgml (1.101),
- debian/changelog (1.92): - Sec "The Incoming system" in
- "Resources", describe how it works and also speak of the
- DELAYED directory. closes: #135562, #136774
-
-2002-05-08 18:27 Raphaël Hertzog <hertzog@debian.org>
-
- * common.ent (1.26), developers-reference.sgml (1.100),
- debian/changelog (1.91): - Explain to reassign/close bugs of
- removed packages. closes: #130255 - Updates the note about
- software subject to US patents. closes: #142798 - New Section
- "Contacting other maintainers" under "Beyond packaging"
- Document the package@packages.debian.org alias; closes: #114553 -
- New Section "Package's information" under Resources Document
- http://packages.debian.org/<package>,
- http://bugs.debian.org/<package> and the madison utility. - Sec
- "Reporting bugs": added http://bugs.debian.org/from:email@isp.com
- - Sec "Handling bugs": added
- http://bugs.debian.org/login@debian.org
-
-2002-05-08 16:07 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.90): standardizing some of Raphael's entries
-
-2002-05-08 11:34 Raphaël Hertzog <hertzog@debian.org>
-
- * common.ent (1.25), developers-reference.sgml (1.99),
- debian/changelog (1.89): - Indicated that the list of subsections
- is defined in the policy. Closes: #123586 - Removed some
- cruft in `Announcing package uploads'. - Document the testing
- scripts. Closes: #129445
-
-2002-05-08 06:29 Raphaël Hertzog <hertzog@debian.org>
-
- * developers-reference.sgml (1.98), debian/changelog (1.88): -
- Added best packaging practices chapter. - Added "Writing useful
- descriptions" as a first entry in that chapter. Closes: #53109,
- #129848
-
-2002-05-07 18:39 Raphaël Hertzog <hertzog@debian.org>
-
- * developers-reference.sgml (1.97): - Little typo: s/you/your/.
-
-2002-05-06 23:37 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.96), debian/changelog (1.87): trim
- the bad submit-bugs chapter; s/GPG/GnuPG/
-
-2002-05-06 23:09 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.95), debian/changelog (1.86): spell
- check and some awkward grammar
-
-2002-05-06 22:52 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.85): cosmetics and Antoine's updates
-
-2002-05-06 19:25 Raphaël Hertzog <hertzog@debian.org>
-
- * developers-reference.sgml (1.94), debian/changelog (1.84): -
- Changed -e by -m in the dpkg-buildpackage command line. - Remove
- all references explaining that the upstream orig tarball can be
- changed during lifetime. - Deleted "binary NMU" when we really
- mean "porter upload" or "simple recompile". - Elaborated more
- about "binary-only NMU". - Detail more things about the removal
- of package. - Fix other issues from #102626.
-
-2002-05-06 10:59 Antoine Hulin <antoine@origan.fdn.fr>
-
- * developers-reference.fr.sgml (1.31): Finally in sync with 1.91
- (aph updated the original before me).
-
-2002-05-06 10:54 Antoine Hulin <antoine@origan.fdn.fr>
-
- * developers-reference.sgml (1.93): Small changes.
-
-2002-05-06 10:38 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.83): new stubbed section I missed
-
-2002-05-06 10:32 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.82): recent changes
-
-2002-05-06 10:31 Antoine Hulin <antoine@origan.fdn.fr>
-
- * developers-reference.fr.sgml (1.30): Synchronized with 1.92.
-
-2002-05-06 10:29 Adam Di Carlo <aph@debian.org>
-
- * common.ent (1.24), developers-reference.sgml (1.92): - new
- Chapter "Resource for Debian Developers", incorporating
- the former chapters
- Ch "Mailing Lists, Servers, and Other Machines"
- Ch "The Debian Archive"
-
- - new Chapter "Managing Packages", incorporating former
- chapters
- Ch "Package uploads"
- Ch "Non-Maintainer Uploads (NMUs)"
- Ch "Porting and Being Ported"
- Ch "Moving, Removing, Renaming, Adopting, and Orphaning
- Packages"
- Ch "Handling Bugs" (retitled "Handling package bugs")
- Sec "Bug housekeeping" (new section, some parts stubbed
- out)
-
- - new Chapter "Beyond Packaging" recommends ways to
- contribute
- to Debian beyond issues of package maintenance; incoporates
- Ch "Interaction with Prospective Developers", retitled to
- Sec "Interacting with Prospective Debian Developers"
- Sec "Submitting Bugs", renamed to "Reporting Bugs"
- Sec "QA" moved here from old Sec "Quality Assurance effort"
- Sec "Dealing with unreachable maintainers"
-
- - Sec "Voting" stubbed in Developer Duties
- - Sec "The Developers Database" added under Resources
-
-2002-05-06 10:28 Adam Di Carlo <aph@debian.org>
-
- * Makefile (1.18): depend for developers-reference.html/*
-
-2002-05-05 16:44 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.91), debian/changelog (1.81): -
- new Chapter "Beyond Packaging" for recommended ways to contribute
- to Debian beyond issues of package maintenance; Ch
- "Interaction with
- Prospective Developers" moved into this chapter and renamed
- to Sec
- "Interacting with Prospective Debian Developers"
- - Section's first word capitalized, rest are normal case
- - purge a reference to the Packaging Manual; closes: #145039
-
-2002-05-05 14:12 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.90): chapter titles need caps
-
-2002-05-05 14:10 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.80): recent changes
-
-2002-05-05 14:10 Adam Di Carlo <aph@debian.org>
-
- * debian/control (1.14): add hertzog as co-maintainer
-
-2002-05-05 14:10 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.89): - Sec "Getting started":
- link to New Maintainers' Guide
- - Sec "Debian Mentors" renamed to "Debian Mentors and
- Sponsors",
- we add some info on sponsoring
-
-2002-05-05 14:09 Adam Di Carlo <aph@debian.org>
-
- * common.ent (1.23): newmaint guide and sponsor coordination page
-
-2002-05-03 13:21 Adam Di Carlo <aph@debian.org>
-
- * debian/: changelog (1.79), control (1.13): makefile change; manoj
- is a co-maintainer
-
-2002-05-03 13:20 Adam Di Carlo <aph@debian.org>
-
- * Makefile (1.17): simplifications to the tex prefix rules; they
- are completely irrelevant now though since debiandoc-sgml does it
- right
-
-2002-04-13 18:46 Antoine Hulin <antoine@origan.fdn.fr>
-
- * developers-reference.fr.sgml (1.29): Small corrections.
-
-2002-04-13 18:18 Antoine Hulin <antoine@origan.fdn.fr>
-
- * developers-reference.fr.sgml (1.28): Synchronized with 1.88.
-
-2002-04-13 18:14 Antoine Hulin <antoine@origan.fdn.fr>
-
- * developers-reference.sgml (1.88): Miscellaneous corrections
-
-2002-04-08 02:57 Adam Di Carlo <aph@debian.org>
-
- * ChangeLog (1.6): update for next release
-
-2002-04-08 02:57 Adam Di Carlo <aph@debian.org>
-
- * debian/TODO (1.4): yet more todo
-
-2002-04-08 02:53 Adam Di Carlo <aph@debian.org>
-
- * debian/TODO (1.3): more todo
-
-2002-04-08 02:35 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.87), debian/changelog (1.78):
- - dpkg-dev-el: new section
- - Ch "Package uploads":
- - new Sec "Adding an entry to debian/changelog"
- - rename Sec "Announcing new packages" to "New packages"
- - crypto is in main, non-US is for patent restrictions, so:
- - excise some text from "Registering as a Debian developer"
- - changes in Sec "Uploading to ftp-master"
- - changes in Sec "Uploading to non-US"
-
-2002-04-08 01:44 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.86), debian/changelog (1.77): Sec
- "Mailing Lists": where to find private archives, closes: #96780
-
-2002-04-08 01:33 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.85): FIXME for more programs to
- document
-
-2002-04-08 01:23 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.84), debian/changelog (1.76): -
- Ch "Overview of Debian Maintainer Tools":
- - improve the intro
- - debconf-doc mentioned for debconf
- - debhelper: don't talk about debmake; mention how to get
- info on the dh-* pkgs
- - dput: new section, closes: #129378
- - debootstrap: new section, closes: #129377
- - other minor wording changes
-
-2002-04-07 03:02 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.75): recent changes
-
-2002-04-01 10:50 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.83): Charles Briscoe-Smith
- deprecates yada
-
-2002-03-31 17:09 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.74): changes for next version, not yet ready
- for release though
-
-2002-03-31 17:08 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.82): from Martin Michlmayr: changes
- in upload situation, not possible to remove from Incoming
- anymore, talk about dput a bit; closes: #135559
-
-2002-03-15 13:14 Antoine Hulin <antoine@origan.fdn.fr>
-
- * developers-reference.fr.sgml (1.27): Increment the cvs-en-rev
- entity
-
-2002-03-15 12:45 Antoine Hulin <antoine@origan.fdn.fr>
-
- * common.ent (1.22), developers-reference.fr.sgml (1.26),
- developers-reference.sgml (1.81): Miscellaneous corrections
-
-2002-03-11 17:03 Antoine Hulin <antoine@origan.fdn.fr>
-
- * developers-reference.fr.sgml (1.25): Synchronized with version
- 1.80
-
-2002-02-24 15:03 Adam Di Carlo <aph@debian.org>
-
- * ChangeLog (1.5): update for next release
-
-2002-02-24 14:57 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.73): prepare 2.10.0
-
-2002-02-24 14:51 Adam Di Carlo <aph@debian.org>
-
- * debian/copyright (1.4): fix a typo
-
-2002-02-24 14:51 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.fr.sgml (1.24), developers-reference.ja.sgml
- (1.9): use new language-independant entities
-
-2002-02-24 14:49 Adam Di Carlo <aph@debian.org>
-
- * common.ent (1.21), developers-reference.sgml (1.80): isolate a
- few more language-independent bits; change /usr/doc to
- /usr/share/doc, and typo in debian/copyright, closes: #126924
-
-2002-02-24 14:32 Adam Di Carlo <aph@debian.org>
-
- * common.ent (1.20), developers-reference.sgml (1.79): some
- suggestions on places to use the proper term, Debian GNU/Linux,
- closes: #133953; use a new entity, debian-formal for the term
-
-2002-02-24 14:15 Adam Di Carlo <aph@debian.org>
-
- * Makefile (1.16): distclean, and clean is cleaner
-
-2002-02-24 14:13 Adam Di Carlo <aph@debian.org>
-
- * common.ent (1.19), developers-reference.sgml (1.78): purge
- references to 'frozen' distribution, which doesn't exist anymore
-
-2002-02-24 12:48 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.77): bugs closed in NMUs should uses
- 'closes' changelog entries, closes: #133951
-
-2002-02-24 12:40 Adam Di Carlo <aph@debian.org>
-
- * common.ent (1.18), developers-reference.sgml (1.76): update the
- "Applying to Become a New Maintainer" section, with review by
- Raphael Hertzog, closes: #133965
-
-2002-02-24 11:56 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.75): some minor cosmetics
-
-2002-02-23 10:22 Antoine Hulin <antoine@origan.fdn.fr>
-
- * developers-reference.sgml (1.74): Added ';' at the end of an
- entity.
-
-2002-02-20 17:53 Gustavo Noronha Silva <kov@debian.org>
-
- * developers-reference.sgml (1.73): added a section on how to deal
- with unreachable (maybe-MIA) maintainers
-
-2001-12-27 01:48 Antoine Hulin <antoine@origan.fdn.fr>
-
- * developers-reference.fr.sgml (1.23): Synchronised with 1.72 (no
- real change needed, updated french version number)
-
-2001-12-26 08:00 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.72): wrong tense, noticed by Chris
- Tillman
-
-2001-12-19 05:55 Antoine Hulin <antoine@origan.fdn.fr>
-
- * developers-reference.fr.sgml (1.22): Modified translation of
- 'General Public license'
-
-2001-12-17 18:41 Antoine Hulin <antoine@origan.fdn.fr>
-
- * developers-reference.fr.sgml (1.21): Last modifications reviewed
- by P. Batailler
-
-2001-12-12 08:46 Antoine Hulin <antoine@origan.fdn.fr>
-
- * developers-reference.fr.sgml (1.20): Miscellaneous changes to
- enhance overall coherence of the french translations
-
-2001-12-12 02:18 Antoine Hulin <antoine@origan.fdn.fr>
-
- * developers-reference.fr.sgml (1.19): Synchronised with 1.71
-
-2001-12-09 07:55 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.71): mention how the vacation
- notices should include [VAC] in the subject; change the full stop
- into an exclamation sign in the sentence about removing the
- on-vacation flag, many people forget this (i myself had the flag
- turned on for weeks after return at one time :)
-
-2001-11-05 23:22 Antoine Hulin <antoine@origan.fdn.fr>
-
- * developers-reference.fr.sgml (1.18): Removed some mistakes.
-
-2001-10-27 01:56 Antoine Hulin <antoine@origan.fdn.fr>
-
- * developers-reference.fr.sgml (1.17): Synchronised with 1.70.
-
-2001-10-21 01:24 Adam Di Carlo <aph@debian.org>
-
- * Makefile (1.15): clean is cleaner
-
-2001-10-21 01:06 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.72): perpare next version as 2.9.0
-
-2001-10-21 00:57 Adam Di Carlo <aph@debian.org>
-
- * ChangeLog (1.4): update for next release
-
-2001-10-18 15:37 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.70): further cleanups in the section
- about picking the distribution
-
-2001-10-17 20:38 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.69): reordered some subsections in
- the section about package uploads, it wasn't organized
-
-2001-10-17 20:21 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.68): combining stable with unstable
- is deprecated in another section, this paragraph needs to be
- removed
-
-2001-10-17 20:17 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.67): updated the section about
- experimental (better late than never)
-
-2001-10-17 20:02 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.66): created a new subsection about
- uploading to stable, and elaborated about that subject; removed a
- stray sentence about stable from the paragraph about security
- uploads (which apply to all distributions equally), and replaced
- the nonexistent term Security Manager with security officer which
- I saw used
-
-2001-10-03 00:37 Antoine Hulin <antoine@origan.fdn.fr>
-
- * developers-reference.fr.sgml (1.16): Replaced "sévérité" by
- "gravité" which is a better translation of "severity". Since
- "gravité" is also used on the debian website, this replacement
- also helps coherence throughout the french documentation.
-
-2001-10-02 03:21 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.71): shipping 2.8.9
-
-2001-10-02 03:21 Adam Di Carlo <aph@debian.org>
-
- * ChangeLog (1.3): update for next release
-
-2001-09-26 19:35 Antoine Hulin <antoine@origan.fdn.fr>
-
- * developers-reference.fr.sgml (1.15): Updates reviewed by P.
- Batailler.
-
-2001-09-08 18:44 Antoine Hulin <antoine@origan.fdn.fr>
-
- * developers-reference.fr.sgml (1.14): In sync with version 1.65...
- without bug.
-
-2001-09-08 17:57 Antoine Hulin <antoine@origan.fdn.fr>
-
- * developers-reference.fr.sgml (1.13): In sync with version 1.65 of
- developers-reference.sgml.
-
-2001-08-24 12:08 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.65), debian/changelog (1.70): typo
- fix thanks to Mark Hodge
-
-2001-08-24 12:03 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.69): recent changes
-
-2001-08-24 11:52 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.64): integrate many changes from
- James Troup, part of #102626
-
-2001-08-24 11:48 Adam Di Carlo <aph@debian.org>
-
- * common.ent (1.17): break out &number-of-arches as a variable, god
- that changes a lot !
-
-2001-08-22 00:42 Antoine Hulin <antoine@origan.fdn.fr>
-
- * developers-reference.fr.sgml (1.12): Removed a brown-paper-bag
- mistake.
-
-2001-08-19 23:05 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.68): prepare version 2.8.9
-
-2001-08-18 20:37 Antoine Hulin <antoine@origan.fdn.fr>
-
- * developers-reference.fr.sgml (1.11): Synchronized with cvs
- version 1.63 of developers-reference.sgml
-
-2001-07-30 08:15 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.63): replaced some bogus <ftppath>s
- with <tt>s; noted how there's an upload queue on pandora, too
-
-2001-07-20 17:56 Adam Di Carlo <aph@debian.org>
-
- * ChangeLog (1.2): update
-
-2001-07-20 17:56 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.67): prepare 2.8.8
-
-2001-07-20 17:55 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.62): upcase chapter titles
-
-2001-07-17 08:06 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.61): a few more strong words about
- sponsoring
-
-2001-07-16 18:20 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.60), common.ent (1.16): started a
- new chapter about the relationship between old and new developers
-
-2001-07-15 11:43 Josip Rodin <joy@debian.org>
-
- * debian/TODO (1.2): this TODO item is fixed, the reference now
- explains how people.d.o works
-
-2001-07-15 11:07 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.59): explained how to CC:
- debian-devel and how it's not completely obligatory
-
-2001-06-21 14:43 Adam Di Carlo <aph@debian.org>
-
- * Makefile (1.14), debian/changelog (1.66), debian/control (1.12):
- update for and require debiandoc-sgml 1.1.48 or better
-
-2001-06-21 14:35 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.fr.sgml (1.10), developers-reference.ja.sgml
- (1.8), developers-reference.sgml (1.58), debian/changelog (1.65),
- debian/rules (1.32): provide proper l10n for SGML date entities;
- now we have &date-<LANG> entities which should be used
-
-2001-06-21 13:20 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.57), debian/changelog (1.64): Matt
- Zimmerman fixes up some wording in the section talking about
- forwarding bugs upstream
-
- closes: #98312
-
-2001-06-21 13:02 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.56), debian/changelog (1.63):
- dpkg-buildpackage -m<addr> flag was changed for -e<addr> when
- NMU'ing; update documentation accordingly
-
- closes: #101676
-
-2001-05-15 10:59 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.55), debian/changelog (1.62): fix a
- small typo in a link
-
-2001-05-12 20:27 Antoine Hulin <antoine@origan.fdn.fr>
-
- * developers-reference.fr.sgml (1.9): Reviewed by P. Bataille. Some
- more changes.
-
-2001-05-04 20:02 Antoine Hulin <antoine@origan.fdn.fr>
-
- * developers-reference.fr.sgml (1.8): Reviewed by P. Batailler
-
-2001-04-23 13:02 Adam Di Carlo <aph@debian.org>
-
- * common.ent (1.15): sample-dist-dirtree had some english in it,
- bad bad
-
-2001-04-16 19:44 Antoine Hulin <antoine@origan.fdn.fr>
-
- * developers-reference.fr.sgml (1.7): cvs-en-rev entity updated
-
-2001-04-16 19:16 Antoine Hulin <antoine@origan.fdn.fr>
-
- * developers-reference.fr.sgml (1.6): Some changes from P.
- Batailler, N. Bertolissio and me.
-
-2001-04-15 17:41 Josip Rodin <joy@debian.org>
-
- * common.ent (1.14): updated the general numbers
-
-2001-04-13 03:32 Adam Di Carlo <aph@debian.org>
-
- * ChangeLog (1.1): update for next release
-
-2001-04-13 03:32 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.61): prepare 2.8.6
-
-2001-04-13 03:31 Adam Di Carlo <aph@debian.org>
-
- * debian/rules (1.31): utilze new changelog file
-
-2001-04-13 03:30 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.54): utilize orphan-address and
- cosmetics
-
-2001-04-13 03:30 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.fr.sgml (1.5), developers-reference.ja.sgml
- (1.7): utilize orphan-address
-
-2001-04-13 03:29 Adam Di Carlo <aph@debian.org>
-
- * common.ent (1.13): add orphan-address as the email address for
- orphaning pkgs
-
-2001-04-13 03:29 Adam Di Carlo <aph@debian.org>
-
- * .cvsignore (1.5): ignore validate stuff
-
-2001-04-13 03:18 Adam Di Carlo <aph@debian.org>
-
- * Makefile (1.13): add a 'validate' rule
-
-2001-04-13 03:17 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.53): fix a typo, thanks to Antoine
- Hulin
-
-2001-04-12 16:59 Adam Di Carlo <aph@debian.org>
-
- * Makefile (1.12): add a 'prepare' target to update ChangeLog
-
-2001-04-11 18:51 Antoine Hulin <antoine@origan.fdn.fr>
-
- * developers-reference.fr.sgml (1.4): Integrate the second review
- of N. Bertolissio. This version is in sync with
- developers-reference.sgml RCS version 1.52.
-
-2001-04-08 01:41 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.fr.sgml (1.3), developers-reference.ja.sgml
- (1.6): more purging of url-pkg-manual references
-
-2001-04-08 01:41 Adam Di Carlo <aph@debian.org>
-
- * .cvsignore (1.4): update ignorables
-
-2001-04-08 01:28 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.60): re-prepare 2.8.5, including some French
- updates; hopefully it is valid SGML
-
-2001-04-08 01:27 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.ja.sgml (1.5): expunge some references to
- url-pkg-manual; this version needs updating
-
-2001-04-07 21:28 Antoine Hulin <antoine@origan.fdn.fr>
-
- * developers-reference.fr.sgml (1.2): First complete translation of
- the Debian developer's reference guide. Reviewed by Nicolas
- Bertolissio. I will integrate 2 patches (from N. Bertolissio and
- P. Batailler) ASAP.
-
-2001-04-07 20:24 Adam Di Carlo <aph@debian.org>
-
- * debian/: changelog (1.59), control (1.11): fix
- build-depends(-indep) issue, prepare 2.8.5
-
-2001-04-05 10:02 Adam Di Carlo <aph@debian.org>
-
- * debian/TODO (1.1): new file
-
-2001-04-05 10:01 Adam Di Carlo <aph@debian.org>
-
- * common.ent (1.12), developers-reference.sgml (1.52),
- debian/changelog (1.58): * expunge references to the Debian
- Packaging Manual, which is now in the
- Policy
- * deny request to shut down non-maintainer bug maintenance bug
- closure
- practices (closes: Bug#88623)
- * add some advice about U.S. citizens uploading to non-US
- (closes: Bug#89694)
-
-2001-03-27 10:41 Adam Di Carlo <aph@debian.org>
-
- * common.ent (1.11), developers-reference.sgml (1.51): expunge
- url-pkg-manual
-
-2001-02-25 12:48 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.57): prepare next version
-
-2001-02-25 12:47 Adam Di Carlo <aph@debian.org>
-
- * debian/control (1.10): fill in the description a bit more; remove
- reference to obsolete packaging-manual package (closes:
- Bug#86505)
-
-2001-02-25 12:46 Adam Di Carlo <aph@debian.org>
-
- * Makefile (1.11): clean is cleaner
-
-2001-02-25 12:44 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.desc (1.9): index.html corrected to be
- index.en.html (closes: Bug#85933)
-
-2001-02-11 08:31 Josip Rodin <joy@debian.org>
-
- * Makefile (1.10): just a convenience alias, saves typing :)
-
-2001-01-22 02:10 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.56): prepare 2.8.3 for release
-
-2001-01-22 02:09 Adam Di Carlo <aph@debian.org>
-
- * debian/rules (1.30): remove a useless dir,
- /usr/share/developers-reference; fix install rule for i18n
-
-2001-01-22 02:08 Adam Di Carlo <aph@debian.org>
-
- * Makefile (1.9): eliminate japanese PDF which doesn't seem to work
- properly; some hygenics; proper deps for version.ent
-
-2001-01-22 00:14 Adam Di Carlo <aph@debian.org>
-
- * Makefile (1.8), debian/rules (1.29): build and clean stuff with
- the top-level makefile, not debian/rules; build support for
- non-English languages, and build those by default as well
-
-2001-01-22 00:12 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.ja.sgml (1.4): disable some references to
- files which no longer exist
-
-2001-01-21 18:10 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.55): sorry, last changelog entry on this file
- was wrong; prepare 2.8.2 version, document Josip's changes, and
- bugs to be closed
-
-2001-01-21 18:09 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.54), developers-reference.sgml (1.50): *
- clarify the status of the Developers's reference as "normative"
- * add a reference to debconf (closes: Bug#82413)
-
-2001-01-21 17:54 Adam Di Carlo <aph@debian.org>
-
- * debian/control (1.9): add recommends for debian-policy and
- packaging-manual
-
-2001-01-21 17:53 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.49), debian/copyright (1.3): add
- 2001 copyright
-
-2000-12-30 11:07 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.48): another update WRT
- sid/unstable/testing, from Colin Watson
-
-2000-12-28 17:00 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.47): included fixes from bug #80740;
- described testing; described package pools (this particular part
- required quite a bit of changes, and it might be a bit rough, but
- it's a start); described the frozen test cycles et al; some other
- smaller fixes
-
-2000-12-28 14:35 Josip Rodin <joy@debian.org>
-
- * common.ent (1.10): fixed email-debian-user alias; updated
- sample-dist-dirtree (with more to come)
-
-2000-12-18 19:04 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.46): replaced evil latin1-only «»
- quotation marks, replaced mentions of important severity (in RCB
- context) with serious severity, some details fixed
-
-2000-12-18 18:13 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.45): updated regarding va->klecker
- move, and www->people move, changed most mentions of dinstall to
- a generic term "archive maintenance software", removed full path
- to it because it is in PATH now, mentioned "dak" and "katie"
- (somewhat vaguely), changed week to month regarding FTP archive
- waiting time since that\'s more often the case, and changed weeks
- to hours regarding Maintainers file updates since that\'s also
- more often the case now, updated some URLs to entities,
- s/debian-doc/doc-debian/
-
-2000-12-18 17:26 Josip Rodin <joy@debian.org>
-
- * common.ent (1.9): upped the numbers a little bit, updated lintian
- reports URL
-
-2000-12-06 10:25 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.44): fix for WNPP bug filing
- severities from David Schleef <ds@stm.lbl.gov>
-
-2000-11-04 13:22 Adam Di Carlo <aph@debian.org>
-
- * debian/: changelog (1.53), rules (1.28): remove some obsolete
- source-depends stuff
-
-2000-11-04 13:14 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.52): changes for 2.8.1
-
-2000-11-04 13:13 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.43): * update WNPP instructions,
- based on patch from Marcelo E. Magallon
- (closes: Bug#69435)
- * spelling corrections, awkward grammar suggestions from
- Andreas Krueger
- (closes: Bug#72810)
-
-2000-10-15 05:04 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.desc (1.8), debian/changelog (1.51): update
- doc-base file for FHS
-
-2000-10-15 05:04 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.50): break up this file a bit
-
-2000-10-15 03:25 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.49): update from CVS Changelogs mostly
-
-2000-10-15 03:25 Adam Di Carlo <aph@debian.org>
-
- * debian/copyright (1.2): update for new copyright file location;
- add 2000 copyright dates and mention I am the maintainer [sic]
-
-2000-09-20 11:31 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.42): fixed bug closing example,
- closes: #71198 ;) and updated the perl regexp from current
- /usr/lib/dpkg/parsechangelog/debian file
-
-2000-09-20 11:17 Josip Rodin <joy@debian.org>
-
- * debian/: control (1.8), postinst (1.4), prerm (1.4), rules
- (1.27): compliance with Policy 3.2.1
-
-2000-09-20 10:55 Josip Rodin <joy@debian.org>
-
- * common.ent (1.8), developers-reference.sgml (1.41): updated
- keyring/keyserver stuff; updated lists-archives URL; changed link
- for machines from devel/maintainer_contacts to the db.d.o CGI;
- updated new-maintainer stuff; updated for master->ftp-master
- move; noted www.d.o is the right host for web pages, but all
- other machines could be used if necessary; fixed www.d.o BTS URL;
- reorder mentions of scp to come before FTP, as it is more secure;
- mention the rsync dupload method; reorder mentions of pandora <->
- non-us, canonical name non-us is better; other small corrections
-
-2000-09-19 19:08 Josip Rodin <joy@debian.org>
-
- * common.ent (1.7): fixed cvs.d.o web path
-
-2000-09-19 18:59 Josip Rodin <joy@debian.org>
-
- * common.ent (1.6): fixed wnpp url
-
-2000-09-19 18:45 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.40): fixed orphaning/adopting
- instructions with regard to the new WNPP
-
-2000-09-19 15:35 Josip Rodin <joy@debian.org>
-
- * Makefile (1.7): set build as the default rule, made clean a phony
- rule
-
-2000-07-30 15:44 Josip Rodin <joy@debian.org>
-
- * common.ent (1.5): fixed link to Debian machines page
-
-2000-07-29 08:11 Josip Rodin <joy@debian.org>
-
- * developers-reference.sgml (1.39): fixed broken link
-
-2000-07-29 07:30 Josip Rodin <joy@debian.org>
-
- * Makefile (1.6): no need to fork a shell, $(notdir) does the job
-
-2000-04-16 23:36 Adam Di Carlo <aph@debian.org>
-
- * debian/: changelog (1.48), rules (1.26): don't compress PDF
-
-2000-04-16 22:42 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.47): first cut 2.7.2
-
-2000-04-16 22:34 Adam Di Carlo <aph@debian.org>
-
- * constitution.en.html (1.3), debian-constitution.desc (1.3),
- debian/postinst (1.3), debian/prerm (1.3), debian/rules (1.25):
- purge the constitution
-
-2000-04-16 22:32 Adam Di Carlo <aph@debian.org>
-
- * debian/rules (1.24): install common.ent and housekeeping
-
-2000-04-16 22:24 Adam Di Carlo <aph@debian.org>
-
- * common.ent (1.4), constitution.en.html (1.2),
- developers-reference.sgml (1.38): changes from Raphael Hertzog
- <hertzog@debian.org>, 25 Mar 2000
-
-2000-03-06 20:17 Josip Rodin <joy@debian.org>
-
- * debian/rules (1.23): Changed debiandoc2latex2epdf to
- debiandoc2latexpdf, otherwise it doesn't build with
- debiandoc-sgml 1.1.40.
-
-2000-01-07 11:45 Yoshizumi Endo <y-endo@ceres.dti.ne.jp>
-
- * developers-reference.ja.sgml (1.3): Improved translation (thanks
- Seiji Kaneko).
-
-1999-10-28 13:38 Yoshizumi Endo <y-endo@ceres.dti.ne.jp>
-
- * developers-reference.ja.sgml (1.2): Improved translation (thanks
- Seiji Kaneko and Hiroshi KISE).
-
-1999-10-04 13:49 Yoshizumi Endo <y-endo@ceres.dti.ne.jp>
-
- * developers-reference.ja.sgml (1.1): Initial translation.
-
-1999-09-12 18:17 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.46): it helps to sign the changelog
-
-1999-09-12 18:12 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.37), debian/changelog (1.45): add
- stuff for dinstall bug closing; note alternate names for DSA
-
-1999-09-11 21:55 Adam Di Carlo <aph@debian.org>
-
- * debian/rules (1.22): fix a bug in how we deal with debian/control
-
-1999-09-11 21:33 Adam Di Carlo <aph@debian.org>
-
- * debian/: changelog (1.44), control (1.7), rules (1.21):
- dynamically generate the TOC in the package description from
- developers-reference.sgml
-
-1999-09-11 18:55 Adam Di Carlo <aph@debian.org>
-
- * common.ent (1.3), developers-reference.sgml (1.36),
- debian/changelog (1.43): pgp to rsa changes, 2.7.1 first cut
-
-1999-08-16 23:59 Adam Di Carlo <aph@debian.org>
-
- * common.ent (1.2), developers-reference.sgml (1.35),
- debian/changelog (1.42), debian/control (1.6), debian/rules
- (1.20): 2.7.0 update, see the changelog
-
-1999-08-15 19:43 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.41): document bug 37392 closing
-
-1999-08-15 19:26 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.40): first cut of next version
-
-1999-08-15 19:24 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.34): start effort to split out
- common entities
-
-1999-08-15 19:22 Adam Di Carlo <aph@debian.org>
-
- * common.ent (1.1): file added
-
-1999-08-11 13:22 Adam Di Carlo <aph@debian.org>
-
- * debian-constitution.desc (1.2): fix section, closing bug 37392
-
-1999-07-27 15:38 Christophe Le Bars <clebars@debian.org>
-
- * developers-reference.fr.sgml (1.1): add old french translations
-
-1999-05-21 21:47 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.39): 2.6.8, first cut
-
-1999-05-21 21:45 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.33): correction about login name on
- master -- eight chars or less, not seven (and remove the footnote
- asking why seven)
-
-1999-05-21 01:39 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.38): version 2.6.7
-
-1999-05-21 01:39 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.32): Ch. "Overview of Debian
- Maintainer Tools": new section for yada (um, someone who uses
- this should check my description), correct build -> debuild
- in the devscripts section (closes Bug#38053)
-
-1999-05-21 01:36 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.desc (1.7): capitalize section name (closes
- Bug#37392)
-
-1999-05-09 18:11 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.31): normalize SGML elements which
- were <foo/.../ to <foo>...</foo>; re-fill paragraphs -- NO
- CONTENT CHANGES
-
-1999-05-09 01:10 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.37): 2nd cut
-
-1999-05-09 01:08 Adam Di Carlo <aph@debian.org>
-
- * debian/rules (1.19): re-enable letter-sized PDFs
-
-1999-05-09 00:44 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.36): first cut 2.6.6
-
-1999-05-09 00:34 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.30): * Sec. "The master server":
- note that problems on Debian ftp can be sent
- to ftpmaster@debian.org also
- * Secs. "Uploads via chiark" and "Uploads via erlangen": remove
- 'cron-driven' (thanks Roman Hodek)
- * Sec. "Being Kind to Porters": typos corrected, note that
- binary-arch
- and binary-indep targets should work independantly (thanks
- Roman
- Hodek)
- * Sec. "buildd": remove erroneous reference to debbuild,
- reorganize the
- section and correct typos (thank again Roman -- boy, this is
- the all
- Roman release)
-
-1999-05-04 03:32 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.29), debian/changelog (1.35),
- debian/rules (1.18): * Sec. "Architectures": correction on
- supported architecture in Linux
- 2.2, from Job Bogan
- * Sec. "Experimental": other reasons to use or not use the
- experiment
- archive "section", from comments by Guy Maor
- * Sec. "Being Kind to Porters": replace x86 with i386 (closes
- Bug#36485)
- * debian/rules: date printing protected from local l10n (closes
- Bug#36891)
- * Ch. "Mailing Lists, Servers, and Other Machines": renamed
- chapter; add
- intro paragraph
- * Sec. "Debian Servers": new, for talking about the standard
- servers,
- with intro; demoted server sections under that
- * Sec. "The FTP servers": was empty, removed
- * Sec. "The master server": fill in more info and cross-refs on
- how to
- report problems
- * Sec. "The CVS server": add some more detail which should be
- included
- when requesting cvs areas; mention the cvsweb URL
- * Sec. "Other Debian Machines": new section, list the machines
- for which
- a normal developer may have access.
-
-1999-04-09 21:20 Adam Di Carlo <aph@debian.org>
-
- * .cvsignore (1.3): ignorable
-
-1999-04-09 21:18 Adam Di Carlo <aph@debian.org>
-
- * debian/: changelog (1.34), rules (1.17): hack 'byhand' file
- entries to include debian version number in it, so subsequent
- uploads of the package into Incoming don't step all over each
- other
-
-1999-04-04 13:35 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.28), debian/changelog (1.33): 2.6.3:
- correction from James Troup -- <keyring-maint> is indeed the
- correct address for PGP key updates
-
-1999-04-04 04:42 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.27), debian/changelog (1.32): Sec.
- "fakeroot": libtricks is not replacing anything after all; use
- public declaration
-
-1999-04-03 17:15 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.31): 2nd cut
-
-1999-04-03 17:13 Adam Di Carlo <aph@debian.org>
-
- * debian/control (1.5): match priority in override files on archive
-
-1999-04-03 17:12 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.desc (1.6): fix typo
-
-1999-04-03 16:15 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.30): first cut 2.6.1
-
-1999-04-03 16:15 Adam Di Carlo <aph@debian.org>
-
- * debian/rules (1.16): making PDF now, not PS; deal with new
- debiandoc-sgml output naming
-
-1999-04-03 16:14 Adam Di Carlo <aph@debian.org>
-
- * debian/: postinst (1.2), prerm (1.2): deal with
- debian-constitution docreg files
-
-1999-04-03 16:11 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.26): * Sec. "Maintaining Your
- Public Key" -- give email addresses as
- {pgp,gpg}-update@debian.org, at James Troup's request (note
- to Jameas,
- if you see this: /usr/doc/debian-keyring/README.gz talks
- about
- <keyring-maint> instead)
- * Ch. "Overview of Debian Maintainer Tools" -- add Sec.
- "debget"
-
-1999-04-03 16:08 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.desc (1.5): cope with new file name
- extensions and PDF file
-
-1999-04-03 16:01 Adam Di Carlo <aph@debian.org>
-
- * debian-constitution.desc (1.1): new file
-
-1999-04-03 14:43 Adam Di Carlo <aph@debian.org>
-
- * constitution.en.html (1.1): Initial revision
-
-1999-04-03 14:43 Adam Di Carlo <aph@debian.org>
-
- * constitution.en.html (1.1.1.1): import from webml
- (www.debian.org)
-
-1999-03-03 15:22 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.29): 2.6.0.1 pre version (will be changed to
- 2.6.1 when I release officially)
-
-1999-03-03 15:21 Adam Di Carlo <aph@debian.org>
-
- * debian/rules (1.15): housekeeping
-
-1999-03-03 15:20 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.25): <chapt id="scope">Scope of This
- Document -- typo correction
-
- <sect id="fakeroot"> -- it's libtricks, not libtool
-
-1999-03-03 15:06 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.desc (1.4): add abstract
-
-1999-02-11 03:10 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.28): plea for frozen too
-
-1999-02-11 03:06 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.27): ver 2.6.0
-
-1999-02-11 03:06 Adam Di Carlo <aph@debian.org>
-
- * debian/rules (1.14): remove menu file
-
-1999-02-11 03:05 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.24): * Ch. "Porting and Being
- Ported": porter information broken out into it's
- own chapter, Sec. "Guidelines for Porter Uploads" and "When
- to do a
- source NMU if you are a porter" moved to this chapter; porter
- tool
- descriptions such as 'quinn-diff' moved to this section.
- Sec. "Being
- Kind to Porters" added, with tips for how to avoid making
- problems for
- porters.
- * Ch. "Non-Maintainer Uploads (NMUs)": update for the new
- chapter, and
- tighten up the language a bit
- * Sec. "Monitoring bugs": add a little cron job to get an
- 'index maint'
- of outstanding bugs (closes Bug#31259), loosen language a
- tiny bit
- w.r.t. non-maintainers or submitters closing bugs (closes
- Bug#30394)
- * Sec. "Scope of This Document": point out that this file is
- not
- official policy
- * Ch. "Handling Bugs": renamed from "Handling Bug Reports",
- incorporate
- some suggestions from James Troup, namely, don't mail from
- your root
- account, don't close bugs via control@bugs.debian.org; break
- out new
- sections, "Submitting Bugs" and "Responding to Bugs"
- * Ch. "Overview of Debian Maintainer Tools": remove attribution
- for
- package maintainers, since I can't keep up; add entries for
- fakeroot
- and devscripts
- * Ch. "Maintaining Your Debian Information": new chapter, quite
- small
- right now; it mentions keyring-maint@debian.org for key
- modification,
- warns against putting private keys on multi-user machines,
- and talks
- about how to depart Debian gracefully
- * typo correction from Christian Hudon (closes Bug#32052)
- * menu file removed, obsoleted by doc-base file
- * parameterize some often-changing values with SGML entities,
- update
- number of available packages
- * use new way of notating multiple copyrights
- * change <tt> elements to <file> where appropriate
-
-1999-02-11 03:04 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.desc (1.3): fix maintainer name
-
-1999-02-11 00:02 Adam Di Carlo <aph@debian.org>
-
- * debian/menu (1.2): obsoleted by doc-base file
-
-1999-01-19 04:08 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.23), debian/changelog (1.26): fix
- for Bug#32052
-
-1998-12-29 02:46 Adam Di Carlo <aph@debian.org>
-
- * debian/: changelog (1.25), rules (1.13): added version.ent to
- docdir for Bug#31034
-
-1998-12-18 00:10 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.22): s/ppc/powerpc/, other
- spellfixes
-
-1998-12-18 00:09 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.24): early cut 2.5.0.3
-
-1998-11-25 05:40 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.23): [no log message]
-
-1998-11-25 05:39 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.21): * Sec. "Removing a package
- from Incoming": tiny section added
- * some PGP-centricity removed
- * Sec. "Adopting a package": point out that hijacking packages
- is not ok
- * Ch. "Non-Maintainer Uploads (NMUs) and Porters": change NMU
- to
- source NMU, port to binary NMU, shorten the window for
- porters a
- tad; fix spelling; stress that non-maintainer patches must be
- non-disruptive and that aesthetic issues are not suitable for
- fixing
- by non-maintainers; other fixes as suggested by interested
- parties
-
-1998-11-21 13:13 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.20), debian/changelog (1.22): finish
- 1st draft filling in NMU/porter chapter
-
-1998-11-19 17:49 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.19): more work on the NMU/porters
- chapter
-
-1998-11-19 17:31 Adam Di Carlo <aph@debian.org>
-
- * debian/: changelog (1.21), rules (1.12): use changelog date for
- SGML timestamping, not current date
-
-1998-11-16 00:46 Adam Di Carlo <aph@debian.org>
-
- * debian/: changelog (1.20), dirs (1.2): remove obsolete 'dirs'
- file
-
-1998-11-16 00:41 Adam Di Carlo <aph@debian.org>
-
- * debian/control (1.4): name change
-
-1998-11-16 00:40 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.19): [no log message]
-
-1998-11-16 00:39 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.18): name change
-
- fix SGML nit
-
-1998-11-16 00:10 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.18): [no log message]
-
-1998-11-15 20:17 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.17): Sec. "Maintainer changes":
- renamed to "Adopting a package" and moved to Chapter "Moving,
- Removing, Renaming, Adopting, and Orphaning Packages".
-
- Ch. "Non-Maintainer Uploads (NMUs) and Porters": new chapter
- discussing NMUs and porters; Section "Interim Releases"
- integrated out of existance
-
- of course the obligatory typo, grammar, and spelling corrections
-
-1998-11-15 04:23 Adam Di Carlo <aph@debian.org>
-
- * Makefile (1.5): fix semantics to match PUBLISHDIR
-
-1998-11-12 00:48 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.17): tweaking for release
-
-1998-11-12 00:47 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.16): fix copyright byline
-
- remove URL to fragment identifier
-
-1998-11-11 22:56 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.16): final release version
-
-1998-11-09 05:11 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.15), debian/changelog (1.15):
- "Interim releases": if you NMU a new upstream version (0.1), run
- 'dpkg-buildpackage -sa'
-
-1998-11-09 03:09 Adam Di Carlo <aph@debian.org>
-
- * debian/control (1.3): bump stds version
-
-1998-11-09 03:07 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.14): pre-release for 2.5.0
-
-1998-11-09 03:06 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.14): many many changes, see the
- changelog, I'm too tired...
-
-1998-11-07 21:12 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.13): correct new maintainer
- instructions pretty heavily (see changelog)
-
- red-pen corrections
-
-1998-11-07 21:08 Adam Di Carlo <aph@debian.org>
-
- * debian/rules (1.11): debiandoc2ps done in build, not binary-indep
-
-1998-11-07 21:07 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.13): correct some new-maintainer directions
-
- red-pen corrections
-
-1998-11-07 21:06 Adam Di Carlo <aph@debian.org>
-
- * .cvsignore (1.2): [no log message]
-
-1998-11-07 16:58 Adam Di Carlo <aph@debian.org>
-
- * debian/rules (1.10): why bother checking for root, don't be a
- fascist
-
-1998-11-05 02:34 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.12): fill in servers section
-
-1998-11-05 02:24 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.12): first cut
-
-1998-11-01 17:40 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.11): s/m86k/m68k/
-
-1998-11-01 17:27 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.10): use new <package> tag where
- appropriate (Ardo, you rock)
-
- advise against uploading when a package has lintian problems of
- severity 'E'
-
- rename 'Whirlwind Tour' section to 'Overview of...'
-
-1998-10-19 00:41 Adam Di Carlo <aph@debian.org>
-
- * debian/rules (1.9): cosmetic changes
-
-1998-10-01 03:45 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.11): note the new chapter on maintainer tools
-
-1998-10-01 03:44 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.9): spell check
-
-1998-10-01 03:28 Adam Di Carlo <aph@debian.org>
-
- * Makefile (1.4): rename html rule to build rule, since it doesn't
- just make html
-
-1998-10-01 03:25 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.8), debian/changelog (1.10):
- incorporated suggestions from or inspired by Branden Robinson
-
-1998-09-28 06:19 olly
-
- * Makefile (1.3): Correction to makefile target
-
-1998-09-28 01:46 Adam Di Carlo <aph@debian.org>
-
- * Makefile (1.2): make ddp publish rule really publish
-
-1998-09-28 00:59 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.9): minor changes
-
-1998-09-28 00:58 Adam Di Carlo <aph@debian.org>
-
- * debian/rules (1.8): remove source-depends rule, not needed....
-
-1998-09-28 00:57 Adam Di Carlo <aph@debian.org>
-
- * Makefile (1.1): initial
-
-1998-09-27 22:39 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.8): First cut for 2.4.1.5 version
-
-1998-09-27 22:39 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.7): Fix instructions for new
- maintainers, incorporating the actual text sent to prospective
- new maintainers. Improve this text a bit for readability,
- coverage, and organization. Significant changes were patched
- back to the new-maintainers group, if they care to use them.
- (closes Bug#26948)
-
- Add an introductory "Scope" section which helps delineate what
- should and should not be included in this Reference.
-
- Add discussion of the "experimental" distribution, culled from an
- email from Guy Maor on debian-devel.
-
- Point to doc-debian's mailing list instructions where relevant.
-
- Made references to online documentation into URLs where possible.
-
- Little corrections here and there.
-
-1998-09-21 04:16 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.6), debian/changelog (1.7): complete
- stuff for this round of textual overhauls, notably adding section
- on removing, renaming, orphaning packages
-
-1998-09-20 19:43 Adam Di Carlo <aph@debian.org>
-
- * debian/rules (1.7): fix source-depends
-
- fix dependancy for build
-
-1998-09-20 19:42 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.5): first cut for 2.4.1.4, which is
- a lot of changes. Still need to fix terminology for "section"
- and "distribution" and the like
-
-1998-09-20 19:41 Adam Di Carlo <aph@debian.org>
-
- * .cvsignore (1.1): ignorables
-
-1998-07-28 01:02 Adam Di Carlo <aph@debian.org>
-
- * debian/: rules (1.6), changelog (1.6): added source depends
- hackery
-
-1998-07-16 00:55 Adam Di Carlo <aph@debian.org>
-
- * debian/rules (1.5): lotsa bugfixing
-
-1998-07-16 00:54 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.5): [no log message]
-
-1998-07-15 23:57 Adam Di Carlo <aph@debian.org>
-
- * debian/rules (1.4): radical aph'ification of rules
-
-1998-07-15 23:50 Adam Di Carlo <aph@debian.org>
-
- * debian/changelog (1.4): bump
-
-1998-07-14 22:49 Adam Di Carlo <aph@debian.org>
-
- * debian/control (1.2): update mainter name
-
-1998-07-14 22:46 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.4): plaster my name all over it
-
- format the SGML like I like it
-
-1998-07-14 22:45 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.desc (1.2): switch section
-
-1998-07-14 17:31 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.3), debian/changelog (1.3),
- debian/rules (1.3): dynamic version numbering and date
-
-1998-07-14 16:31 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.sgml (1.2), debian/changelog (1.2),
- debian/rules (1.2): non-maintainer release 2.4.1.2
-
-1998-07-14 15:27 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.desc (1.1), developers-reference.sgml (1.1),
- debian/changelog (1.1), debian/control (1.1), debian/copyright
- (1.1), debian/dirs (1.1), debian/menu (1.1), debian/postinst
- (1.1), debian/prerm (1.1), debian/rules (1.1): Initial revision
-
-1998-07-14 15:27 Adam Di Carlo <aph@debian.org>
-
- * developers-reference.desc (1.1.1.1), developers-reference.sgml
- (1.1.1.1), debian/changelog (1.1.1.1), debian/control (1.1.1.1),
- debian/copyright (1.1.1.1), debian/dirs (1.1.1.1), debian/menu
- (1.1.1.1), debian/postinst (1.1.1.1), debian/prerm (1.1.1.1),
- debian/rules (1.1.1.1): \Initial Import\\
-
+++ /dev/null
-
-This CVS repository is no more used. We switched to Subversion.
-Grab the new repository here:
-
-Anonymous checkout:
-svn co svn://svn.debian.org/ddp/developers-reference/trunk
-
-Authenticated checkout for DDP members:
-svn co svn+ssh://svn.debian.org/svn/ddp/developers-reference/trunk
-
-Browse the new repo on the web:
-http://svn.debian.org/wsvn/ddp/developers-reference/trunk/
-
--- Raphael Hertzog
-
-# Makefile, used for the DDP manuals.sgml area
+# Makefile, used for the developers-reference in DocBook XML
-MANUAL := $(notdir $(shell pwd))
-PUBLISHDIR := /org/www.debian.org/www/doc/manuals
+# Note: This Makefile should work perfectly without the debian/ directory.
-SOURCES := $(wildcard *.sgml)
+SOURCES := $(wildcard *.dbk) common.ent version.ent
-LANGS := fr
-TARGETS := $(foreach fmt,html txt pdf,developers-reference.$(fmt)) \
- $(foreach langext,$(LANGS), \
- $(foreach fmt,html txt pdf,developers-reference.$(langext).$(fmt)))
+FORMATS := html txt pdf
+LANGS := fr ja
+TARGETS := $(foreach fmt,$(FORMATS),developers-reference.$(fmt)) \
+ $(foreach lng,$(LANGS), \
+ $(foreach fmt,$(FORMATS), \
+ $(lng)/developers-reference.$(fmt)))
+# list of targets, that currently cannot build
+BLACKLIST := ja/developers-reference.pdf
-# programs for creating output
-DEBIANDOC2HTML := debiandoc2html -c
-DEBIANDOC2TEXT := debiandoc2text
-DEBIANDOC2LATEX := debiandoc2latex
-DEBIANDOC2PS := debiandoc2latexps
-DEBIANDOC2PDF := debiandoc2latexpdf
-
-htmllink := echo "<!entity % htmltext \"INCLUDE\">" > dynamic.ent
-nohtmllink := echo "<!entity % htmltext \"IGNORE\">" > dynamic.ent
-
-make_directory := install -d -m 755
-install_file := install -m 644 -p
-
-MAX_TEX_RECURSION := 5
-
-.PHONY: all dropold
-all: $(TARGETS) dropold
-
-dropold:
- -rm -rf developers-reference.ja.html
+# hopefully overwritten by caller, e.g. debian/rules
+VERSION=unknown
+PUBDATE=unknown
+# programs for creating output
+XP=xsltproc --nonet --novalid --xinclude
+XL=xmllint --nonet --noout --postvalid --xinclude
+# dblatex 0.2.8 has some problems (e.g. #465221 and Japanese does
+# not build)
+# Alternatives:
+# - docbook2pdf (seems to die on UTF-8, #431085); and
+# - fop is currently in contrib, but can go to main, see #366783
+# - xmlroff (not mature enough, #182445)
+DBLATEX=dblatex --style=db2latex
+# The "--keep 0" should be removed as soon as the translations are ready
+TRANSLATE=po4a-translate --format docbook --keep 0
+
+# XSL files and parameters
+# note: the URL is used as identifier, no HTTP is used!
+DOCBOOK_XSL=http://docbook.sourceforge.net/release/xsl/current
+# for HTML output
+DBK2HTML=$(PWD)/html.xsl
+# all in one file for text output
+DBK2HTML1=$(PWD)/txt.xsl
+
+.PHONY: all
+all: $(filter-out $(BLACKLIST), $(TARGETS))
.PHONY: validate
-validate: $(addsuffix .validate,$(SOURCES))
-
-# hmmm, this rule may need to be revised/tested
-.PHONY: publish
-publish: all
- [ -d $(PUBLISHDIR) ] || exit 1
- rm -f $(PUBLISHDIR)/$(MANUAL)/*.html
- $(make_directory) $(PUBLISHDIR)/$(MANUAL)
- $(install_file) developers-reference*.html/*.html developers-reference*pdf \
- $(PUBLISHDIR)/$(MANUAL)
- ln -sf index.en.html $(PUBLISHDIR)/$(MANUAL)/index.html
- ln -sf developers-reference.pdf $(PUBLISHDIR)/$(MANUAL)/developers-reference.en.pdf
-
-developers-reference.html: developers-reference.sgml
- $(htmllink)
- $(DEBIANDOC2HTML) -l en $<
-
-developers-reference.html/*: developers-reference.html
-
-developers-reference.%.html: developers-reference.%.sgml
- $(htmllink)
- $(DEBIANDOC2HTML) -l $* $<
-
-developers-reference.txt: developers-reference.sgml
- $(nohtmllink)
- $(DEBIANDOC2TEXT) -l en -O $< > $@
-
-developers-reference.%.txt: developers-reference.%.sgml
- $(nohtmllink)
- $(DEBIANDOC2TEXT) -l $* -O $< > $@
-
-developers-reference.tex: developers-reference.sgml
- $(nohtmllink)
- $(DEBIANDOC2LATEX) -l en -O $< > $@
-
-developers-reference.%.tex: developers-reference.%.sgml
- $(nohtmllink)
- $(DEBIANDOC2LATEX) -l $* -O $< > $@
-
-developers-reference.ps: developers-reference.sgml
- $(nohtmllink)
- $(DEBIANDOC2PS) -l en $<
-
-developers-reference.%.ps: developers-reference.%.sgml
- $(nohtmllink)
- $(DEBIANDOC2PS) -l $* $<
-
-developers-reference.pdf: developers-reference.sgml
- $(nohtmllink)
- $(DEBIANDOC2PDF) -l en $<
-
-developers-reference.%.pdf: developers-reference.%.sgml
- $(nohtmllink)
- $(DEBIANDOC2PDF) -l $* $<
-
-version.ent: debian/changelog
- ./debian/rules $@
-
-%.validate : % version.ent
- nsgmls -wall -gues $<
- touch $@
-
-USERMAP := ../../ddp/CVSROOT/users
-.PHONY: prepare
-prepare: ChangeLog
- cvs ci -m "update for next release" ChangeLog
-
-.PHONY: ChangeLog
-ChangeLog:
- @[ -f CVS/Root -a -f $(USERMAP) ] || \
- ( echo "usermap file '$(USERMAP)' not found" 1>&2; exit 1 )
- cvs2cl -r --usermap $(USERMAP)
+validate: $(SOURCES)
+ $(XL) index.dbk
+
+%/validate: $(addprefix %/,$(SOURCES))
+ cd $(@D) && $(XL) index.dbk
+
+.PHONY: developers-reference.html %/developers-reference.html
+developers-reference.html: $(PWD)/index.html
+%/developers-reference.html: $(addprefix %/,index.html)
+ @true
+
+.PRECIOUS: %/index.html
+index.html: $(PWD)/developers-reference.html
+%/index.html: $(addprefix %/,$(SOURCES))
+ cd $(@D) && $(XP) $(DBK2HTML) index.dbk
+
+# There must be an easier way than recursive make!
+.PRECIOUS: %.dbk %.ent
+ifndef LINGUA
+%.dbk %.ent: FORCE
+ $(MAKE) $@ LINGUA=$(@D)
+
+FORCE:
+else
+$(LINGUA)/%.dbk: %.dbk $(patsubst %.dbk,po4a/$(LINGUA)/%.po,%.dbk)
+ $(TRANSLATE) -m $< -p po4a/$(@:.dbk=.po) -l $@
+
+$(LINGUA)/common.ent: common.ent
+ cd $(@D) && ln -sf ../$(@F) .
+endif
+
+developers-reference.txt: $(PWD)/developers-reference.txt
+%/developers-reference.txt: $(addprefix %/,$(SOURCES))
+ $(XP) $(DBK2HTML1) $(@D)/index.dbk \
+ | w3m -cols 65 -dump -T text/html > $@
+
+developers-reference.pdf: $(PWD)/developers-reference.pdf
+%/developers-reference.pdf: $(addprefix %/,$(SOURCES))
+ TOP=`pwd` && cd $(@D) && $(DBLATEX) index.dbk \
+ && mv index.dbk.pdf $(@F)
+
+.PHONY: pot
+pot: $(patsubst %.dbk,po4a/po/%.pot,$(SOURCES))
+po4a/po/%.pot: %.dbk
+ po4a-gettextize --format docbook --master $< --po $@
+
+ifdef LINGUA
+.PHONY: updatepo
+updatepo: $(patsubst %.dbk,po4a/$(LINGUA)/%.po,$(SOURCES))
+po4a/$(LINGUA)/%.po: %.dbk
+ po4a-updatepo --format docbook --master $< --po $@
+endif
+
+%/version.ent:
+ echo '<!ENTITY version "$(VERSION)">' > $@
+ echo '<!ENTITY pubdate "$(PUBDATE)">' >> $@
.PHONY: clean
clean:
- rm -rf developers-reference*.html
- rm -f developers-reference*.txt developers-reference*.pdf \
- developers-reference*.ps developers-reference*.lout* lout.li \
- developers-reference*.sasp* developers-reference*.tex \
- developers-reference*.aux developers-reference*.toc \
- developers-reference*.idx developers-reference*.log \
- developers-reference*.out developers-reference*.dvi \
- developers-reference*.tpt
+ rm -f *.fo *.html *.pdf *.txt
+ for L in $(LANGS); do rm -rf `basename ./"$$L"/`; done
rm -f version.ent
rm -f `find . -name "*~" -o -name "*.bak"`
- rm -f *.validate
rm -f *~ *.bak .#* core
.PHONY: distclean
distclean: clean
rm -f *.rej *.orig
-developers-reference$(SRCEXT).sgml: version.ent common.ent
-
-html: $(MANUAL).html
-
# if rule bomb out, delete the target
.DELETE_ON_ERROR:
The following 'make' targets exist for your convenience:
make validate
- validate the well-formedness of all SGML materials
+ validate the well-formedness of all XML materials
- make all
+ make or make all (optional: VERSION=x.y.z PUBDATE=2007-07-01)
build all languages in all formats
- make developers-reference.sgml.validate
- validate the well-formedness of the English manual
+ make index.html
+ build the English manual in HTML format
- make developers-reference.html
- build the English manual
+ make fr/developers-reference.pdf
+ build the French manual in PDF format
+
+ make ja/developers-reference.txt
+ build the Japanese manual in text format
+
+ make pot
+ generate .pot files from .dbk sources
+
+ make updatepo LINGUA=xx (with xx=language code)
+ update .po files for language xx
* Contacting
If you want to contribute to the Developer's Reference, it's best to
first submit a few patches as bug reports. Writing patches for
existing bugs are also always appreciated. You may wish to make
-patches against the CVS sources, about which see below.
+patches against the SVN sources, about which see below.
Do not commit patches to the developers reference yourself unless
authorized to do so. Patches need to be finalized and common opinion
before they are applied. This is even true if you happen to have
-cvs access for other reasons.
+SVN access for other reasons.
-* CVS
+* SVN
If you're interested in ongoing maintenance, once you've shown that
you've mastered the style of the manual with a couple accepted
-patches, you can be given CVS pserver access. If you have already
-access to the CVS server for other reasons, do not use it unless
+patches, you can be given SVN access. If you have already
+access to the SVN server for other reasons, do not use it unless
authorized to do so.
-Instructions on how to get the CVS version of this software, including
-how to get CVS access, can be found at
-<URL:http://www.debian.org/doc/cvs>.
+Instructions on how to get the SVN version of this software, including
+how to get SVN access, can be found at
+<URL:http://svn.debian.org/>.
* Translators
Feel free to truck stuff out of the English manual into common.ent if
it's useful, or else report the problem.
-You should exploit CVS to see the diffs between when the document was
-last translated and the latest version. Be sure to set the cvs-en-rev
-entity as appropriate when you do update a translation.
-
-We have provided commands to help with this. To see the difference in
-numbers between the latest translated version and the latest version,
-do, for instance:
-
- ./translation-status fr
-
-To get the diff between the latest translated version and the latest
-version:
-
- ./translation-status -d fr
-
-
+The translation .po files are in po4a/fr/ and po4a/ja/ for French and
+Japanese. We hope very much for more translations.
--- /dev/null
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
+ "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
+ <!ENTITY % commondata SYSTEM "common.ent" > %commondata;
+]>
+<chapter id="best-pkging-practices">
+<title>Best Packaging Practices</title>
+<para>
+Debian's quality is largely due to the <ulink
+url="&url-debian-policy;">Debian Policy</ulink>, which
+defines explicit baseline requirements which all Debian packages must fulfill.
+Yet there is also a shared history of experience which goes beyond the Debian
+Policy, an accumulation of years of experience in packaging. Many very
+talented people have created great tools, tools which help you, the Debian
+maintainer, create and maintain excellent packages.
+</para>
+<para>
+This chapter provides some best practices for Debian developers. All
+recommendations are merely that, and are not requirements or policy. These are
+just some subjective hints, advice and pointers collected from Debian
+developers. Feel free to pick and choose whatever works best for you.
+</para>
+<section id="bpp-debian-rules">
+<title>Best practices for <filename>debian/rules</filename></title>
+<para>
+The following recommendations apply to the <filename>debian/rules</filename>
+file. Since <filename>debian/rules</filename> controls the build process and
+selects the files which go into the package (directly or indirectly), it's
+usually the file maintainers spend the most time on.
+</para>
+<section id="helper-scripts">
+<title>Helper scripts</title>
+<para>
+The rationale for using helper scripts in <filename>debian/rules</filename> is
+that they let maintainers use and share common logic among many packages. Take
+for instance the question of installing menu entries: you need to put the file
+into <filename>/usr/lib/menu</filename> (or <filename>/usr/lib/menu</filename>
+for executable binary menufiles, if this is needed), and add commands to the
+maintainer scripts to register and unregister the menu entries. Since this is
+a very common thing for packages to do, why should each maintainer rewrite all
+this on their own, sometimes with bugs? Also, supposing the menu directory
+changed, every package would have to be changed.
+</para>
+<para>
+Helper scripts take care of these issues. Assuming you comply with the
+conventions expected by the helper script, the helper takes care of all the
+details. Changes in policy can be made in the helper script; then packages
+just need to be rebuilt with the new version of the helper and no other
+changes.
+</para>
+<para>
+<xref linkend="tools"/> contains a couple of different helpers. The most
+common and best (in our opinion) helper system is <systemitem
+role="package">debhelper</systemitem>. Previous helper systems, such as
+<systemitem role="package">debmake</systemitem>, were monolithic: you couldn't
+pick and choose which part of the helper you found useful, but had to use the
+helper to do everything. <systemitem role="package">debhelper</systemitem>,
+however, is a number of separate little <command>dh_*</command> programs. For
+instance, <command>dh_installman</command> installs and compresses man pages,
+<command>dh_installmenu</command> installs menu files, and so on. Thus, it
+offers enough flexibility to be able to use the little helper scripts, where
+useful, in conjunction with hand-crafted commands in
+<filename>debian/rules</filename>.
+</para>
+<para>
+You can get started with <systemitem role="package">debhelper</systemitem> by
+reading <citerefentry> <refentrytitle>debhelper</refentrytitle>
+<manvolnum>1</manvolnum> </citerefentry>, and looking at the examples that come
+with the package. <command>dh_make</command>, from the <systemitem
+role="package">dh-make</systemitem> package (see <xref linkend="dh-make"/> ),
+can be used to convert a vanilla source package to a <systemitem
+role="package">debhelper</systemitem>ized package. This shortcut, though,
+should not convince you that you do not need to bother understanding the
+individual <command>dh_*</command> helpers. If you are going to use a helper,
+you do need to take the time to learn to use that helper, to learn its
+expectations and behavior.
+</para>
+<para>
+Some people feel that vanilla <filename>debian/rules</filename> files are
+better, since you don't have to learn the intricacies of any helper system.
+This decision is completely up to you. Use what works for you. Many examples
+of vanilla <filename>debian/rules</filename> files are available at <ulink
+url="&url-rules-files;"></ulink>.
+</para>
+</section>
+
+<section id="multiple-patches">
+<title>Separating your patches into multiple files</title>
+<para>
+Big, complex packages may have many bugs that you need to deal with. If you
+correct a number of bugs directly in the source, and you're not careful, it can
+get hard to differentiate the various patches that you applied. It can get
+quite messy when you have to update the package to a new upstream version which
+integrates some of the fixes (but not all). You can't take the total set of
+diffs (e.g., from <filename>.diff.gz</filename>) and work out which patch sets
+to back out as a unit as bugs are fixed upstream.
+</para>
+<para>
+Unfortunately, the packaging system as such currently doesn't provide for
+separating the patches into several files. Nevertheless, there are ways to
+separate patches: the patch files are shipped within the Debian patch file
+(<filename>.diff.gz</filename>), usually within the
+<filename>debian/</filename> directory. The only difference is that they
+aren't applied immediately by dpkg-source, but by the <literal>build</literal>
+rule of <filename>debian/rules</filename>. Conversely, they are reverted in
+the <literal>clean</literal> rule.
+</para>
+<para>
+<command>dbs</command> is one of the more popular approaches to this. It does
+all of the above, and provides a facility for creating new and updating old
+patches. See the package <systemitem role="package">dbs</systemitem> for more
+information and <systemitem role="package">hello-dbs</systemitem> for an
+example.
+</para>
+<para>
+<command>dpatch</command> also provides these facilities, but it's intended to
+be even easier to use. See the package <systemitem
+role="package">dpatch</systemitem> for documentation and examples (in
+<filename>/usr/share/doc/dpatch</filename>).
+</para>
+</section>
+
+<section id="multiple-binary">
+<title>Multiple binary packages</title>
+<para>
+A single source package will often build several binary packages, either to
+provide several flavors of the same software (e.g., the <systemitem
+role="package">vim</systemitem> source package) or to make several small
+packages instead of a big one (e.g., so the user can install only the subset
+needed, and thus save some disk space).
+</para>
+<para>
+The second case can be easily managed in <filename>debian/rules</filename>.
+You just need to move the appropriate files from the build directory into the
+package's temporary trees. You can do this using <command>install</command> or
+<command>dh_install</command> from <systemitem
+role="package">debhelper</systemitem>. Be sure to check the different
+permutations of the various packages, ensuring that you have the inter-package
+dependencies set right in <filename>debian/control</filename>.
+</para>
+<para>
+The first case is a bit more difficult since it involves multiple recompiles of
+the same software but with different configuration options. The <systemitem
+role="package">vim</systemitem> source package is an example of how to manage
+this using an hand-crafted <filename>debian/rules</filename> file.
+</para>
+<!-- FIXME: Find a good debhelper example with multiple configure/make
+ cycles -->
+</section>
+
+</section>
+
+<section id="bpp-debian-control">
+<title>Best practices for <filename>debian/control</filename></title>
+<para>
+The following practices are relevant to the <filename>debian/control</filename>
+file. They supplement the <ulink
+url="&url-debian-policy;ch-binary.html#s-descriptions">Policy
+on package descriptions</ulink>.
+</para>
+<para>
+The description of the package, as defined by the corresponding field in the
+<filename>control</filename> file, contains both the package synopsis and the
+long description for the package. <xref linkend="bpp-desc-basics"/> describes
+common guidelines for both parts of the package description. Following that,
+<xref linkend="bpp-pkg-synopsis"/> provides guidelines specific to the
+synopsis, and <xref linkend="bpp-pkg-desc"/> contains guidelines specific to
+the description.
+</para>
+<section id="bpp-desc-basics">
+<title>General guidelines for package descriptions</title>
+<para>
+The package description should be written for the average likely user, the
+average person who will use and benefit from the package. For instance,
+development packages are for developers, and can be technical in their
+language. More general-purpose applications, such as editors, should be
+written for a less technical user.
+</para>
+<para>
+Our review of package descriptions lead us to conclude that most package
+descriptions are technical, that is, are not written to make sense for
+non-technical users. Unless your package really is only for technical users,
+this is a problem.
+</para>
+<para>
+How do you write for non-technical users? Avoid jargon. Avoid referring to
+other applications or frameworks that the user might not be familiar with —
+GNOME or KDE is fine, since users are probably familiar with these terms, but
+GTK+ is probably not. Try not to assume any knowledge at all. If you must use
+technical terms, introduce them.
+</para>
+<para>
+Be objective. Package descriptions are not the place for advocating your
+package, no matter how much you love it. Remember that the reader may not care
+about the same things you care about.
+</para>
+<para>
+References to the names of any other software packages, protocol names,
+standards, or specifications should use their canonical forms, if one exists.
+For example, use X Window System, X11, or X; not X Windows, X-Windows, or X
+Window. Use GTK+, not GTK or gtk. Use GNOME, not Gnome. Use PostScript, not
+Postscript or postscript.
+</para>
+<para>
+If you are having problems writing your description, you may wish to send it
+along to &email-debian-l10n-english; and request feedback.
+</para>
+</section>
+
+<section id="bpp-pkg-synopsis">
+<title>The package synopsis, or short description</title>
+<para>
+The synopsis line (the short description) should be concise. It must not
+repeat the package's name (this is policy).
+</para>
+<para>
+It's a good idea to think of the synopsis as an appositive clause, not a full
+sentence. An appositive clause is defined in WordNet as a grammatical relation
+between a word and a noun phrase that follows, e.g., Rudolph the red-nosed
+reindeer. The appositive clause here is red-nosed reindeer. Since the
+synopsis is a clause, rather than a full sentence, we recommend that it neither
+start with a capital nor end with a full stop (period). It should also not
+begin with an article, either definite (the) or indefinite (a or an).
+</para>
+<para>
+It might help to imagine that the synopsis is combined with the package name in
+the following way:
+</para>
+<screen>
+<replaceable>package-name</replaceable> is a <replaceable>synopsis</replaceable>.
+</screen>
+<para>
+Alternatively, it might make sense to think of it as
+</para>
+<screen>
+<replaceable>package-name</replaceable> is <replaceable>synopsis</replaceable>.
+</screen>
+<para>
+or, if the package name itself is a plural (such as developers-tools)
+</para>
+<screen>
+<replaceable>package-name</replaceable> are <replaceable>synopsis</replaceable>.
+</screen>
+<para>
+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 sentence.
+</para>
+</section>
+
+<section id="bpp-pkg-desc">
+<title>The long description</title>
+<para>
+The long description is the primary information available to the user about a
+package before they install it. It should provide all the information needed
+to let the user decide whether to install the package. Assume that the user
+has already read the package synopsis.
+</para>
+<para>
+The long description should consist of full and complete sentences.
+</para>
+<para>
+The first paragraph of the long description should answer the following
+questions: what does the package do? what task does it help the user
+accomplish? It is important to describe this in a non-technical way, unless of
+course the audience for the package is necessarily technical.
+</para>
+<para>
+The following paragraphs should answer the following questions: Why do I as a
+user need this package? What other features does the package have? What
+outstanding features and deficiencies are there compared to other packages
+(e.g., if you need X, use Y instead)? Is this package related to other
+packages in some way that is not handled by the package manager (e.g., this is
+the client for the foo server)?
+</para>
+<para>
+Be careful to avoid spelling and grammar mistakes. Ensure that you spell-check
+it. Both <command>ispell</command> and <command>aspell</command> have special
+modes for checking <filename>debian/control</filename> files:
+</para>
+<screen>
+ispell -d american -g debian/control
+</screen>
+<screen>
+aspell -d en -D -c debian/control
+</screen>
+<para>
+Users usually expect these questions to be answered in the package description:
+</para>
+<itemizedlist>
+<listitem>
+<para>
+What does the package do? If it is an add-on to another package, then the
+short description of the package we are an add-on to should be put in here.
+</para>
+</listitem>
+<listitem>
+<para>
+Why should I want this package? This is related to the above, but not the same
+(this is a mail user agent; this is cool, fast, interfaces with PGP and LDAP
+and IMAP, has features X, Y, and Z).
+</para>
+</listitem>
+<listitem>
+<para>
+If this package should not be installed directly, but is pulled in by another
+package, this should be mentioned.
+</para>
+</listitem>
+<listitem>
+<para>
+If the package is experimental, or there are other reasons it should not be
+used, if there are other packages that should be used instead, it should be
+here as well.
+</para>
+</listitem>
+<listitem>
+<para>
+How is this package different from the competition? Is it a better
+implementation? more features? different features? Why should I choose this
+package.
+</para>
+</listitem>
+<!-- FIXME: what's this?
+(the second questions is about the class of packages, and
+this about this particular package, if you have information related to both).
+-->
+</itemizedlist>
+</section>
+
+<section id="bpp-upstream-info">
+<title>Upstream home page</title>
+<para>
+We recommend that you add the URL for the package's home page in the
+<literal>Homepage</literal> field of the <literal>Source</literal> section
+in <filename>debian/control</filename>. Adding this information in the
+package description itself is considered deprecated.
+</para>
+</section>
+
+<section id="bpp-vcs">
+<title>Version Control System location</title>
+<para>
+There are additional fields for the location of the Version Control System in
+<filename>debian/control</filename>.
+</para>
+<section id="s6.2.5.1">
+<title>Vcs-Browser</title>
+<para>
+Value of this field should be a <literal>http://</literal> URL pointing to a
+web-browsable copy of the Version Control System repository used to maintain
+the given package, if available.
+</para>
+<para>
+The information is meant to be useful for the final user, willing to browse the
+latest work done on the package (e.g. when looking for the patch fixing a bug
+tagged as <literal>pending</literal> in the bug tracking system).
+</para>
+</section>
+
+<section id="s6.2.5.2">
+<title>Vcs-*</title>
+<para>
+Value of this field should be a string identifying unequivocally the location
+of the Version Control System repository used to maintain the given package, if
+available. <literal>*</literal> identify the Version Control System; currently
+the following systems are supported by the package tracking system:
+<literal>arch</literal>, <literal>bzr</literal> (Bazaar),
+<literal>cvs</literal>, <literal>darcs</literal>, <literal>git</literal>,
+<literal>hg</literal> (Mercurial), <literal>mtn</literal> (Monotone),
+<literal>svn</literal> (Subversion). It is allowed to specify different VCS
+fields for the same package: they will all be shown in the PTS web interface.
+</para>
+<para>
+The information is meant to be useful for a user knowledgeable in the given
+Version Control System and willing to build the current version of a package
+from the VCS sources. Other uses of this information might include automatic
+building of the latest VCS version of the given package. To this end the
+location pointed to by the field should better be version agnostic and point to
+the main branch (for VCSs supporting such a concept). Also, the location
+pointed to should be accessible to the final user; fulfilling this requirement
+might imply pointing to an anonymous access of the repository instead of
+pointing to an SSH-accessible version of the same.
+</para>
+<para>
+In the following example, an instance of the field for a Subversion repository
+of the <systemitem role="package">vim</systemitem> package is shown. Note how
+the URL is in the <literal>svn://</literal> scheme (instead of
+<literal>svn+ssh://</literal>) and how it points to the
+<filename>trunk/</filename> branch. The use of the
+<literal>Vcs-Browser</literal> and <literal>Homepage</literal> fields
+described above is also shown.
+</para>
+<screen>
+ Source: vim
+ Section: editors
+ Priority: optional
+ <snip>
+ Vcs-Svn: svn://svn.debian.org/svn/pkg-vim/trunk/packages/vim
+ Vcs-Browser: http://svn.debian.org/wsvn/pkg-vim/trunk/packages/vim
+ Homepage: http://www.vim.org
+</screen>
+</section>
+
+</section>
+
+</section>
+
+<section id="bpp-debian-changelog">
+<title>Best practices for <filename>debian/changelog</filename></title>
+<para>
+The following practices supplement the <ulink
+url="&url-debian-policy;ch-docs.html#s-changelogs">Policy
+on changelog files</ulink>.
+</para>
+<section id="bpp-changelog-do">
+<title>Writing useful changelog entries</title>
+<para>
+The changelog entry for a package revision documents changes in that revision,
+and only them. Concentrate on describing significant and user-visible changes
+that were made since the last version.
+</para>
+<para>
+Focus on <emphasis>what</emphasis> was changed — who, how and when are
+usually less important. Having said that, remember to politely attribute
+people who have provided notable help in making the package (e.g., those who
+have sent in patches).
+</para>
+<para>
+There's no need to elaborate the trivial and obvious changes. You can also
+aggregate several changes in one entry. On the other hand, don't be overly
+terse if you have undertaken a major change. Be especially clear if there are
+changes that affect the behaviour of the program. For further explanations,
+use the <filename>README.Debian</filename> file.
+</para>
+<para>
+Use common English so that the majority of readers can comprehend it. Avoid
+abbreviations, tech-speak and jargon when explaining changes that close bugs,
+especially for bugs filed by users that did not strike you as particularly
+technically savvy. Be polite, don't swear.
+</para>
+<para>
+It is sometimes desirable to prefix changelog entries with the names of the
+files that were changed. However, there's no need to explicitly list each and
+every last one of the changed files, especially if the change was small or
+repetitive. You may use wildcards.
+</para>
+<para>
+When referring to bugs, don't assume anything. Say what the problem was, how
+it was fixed, and append the closes: #nnnnn string. See <xref
+linkend="upload-bugfix"/> for more information.
+</para>
+</section>
+
+<section id="bpp-changelog-misconceptions">
+<title>Common misconceptions about changelog entries</title>
+<para>
+The changelog entries should <emphasis role="strong">not</emphasis> document
+generic packaging issues (Hey, if you're looking for foo.conf, it's in
+/etc/blah/.), since administrators and users are supposed to be at least
+remotely acquainted with how such things are generally arranged on Debian
+systems. Do, however, mention if you change the location of a configuration
+file.
+</para>
+<para>
+The only bugs closed with a changelog entry should be those that are actually
+fixed in the same package revision. Closing unrelated bugs in the changelog is
+bad practice. See <xref linkend="upload-bugfix"/> .
+</para>
+<para>
+The changelog entries should <emphasis role="strong">not</emphasis> be used for
+random discussion with bug reporters (I don't see segfaults when starting foo
+with option bar; send in more info), general statements on life, the universe
+and everything (sorry this upload took me so long, but I caught the flu), or
+pleas for help (the bug list on this package is huge, please lend me a hand).
+Such things usually won't be noticed by their target audience, but may annoy
+people who wish to read information about actual changes in the package. See
+<xref linkend="bug-answering"/> for more information on how to use the bug
+tracking system.
+</para>
+<para>
+It is an old tradition to acknowledge bugs fixed in non-maintainer uploads in
+the first changelog entry of the proper maintainer upload. As we have version
+tracking now, it is enough to keep the NMUed changelog entries and just mention
+this fact in your own changelog entry.
+</para>
+</section>
+
+<section id="bpp-changelog-errors">
+<title>Common errors in changelog entries</title>
+<para>
+The following examples demonstrate some common errors or examples of bad style
+in changelog entries.
+</para>
+<screen>
+ * Fixed all outstanding bugs.
+</screen>
+<para>
+This doesn't tell readers anything too useful, obviously.
+</para>
+<screen>
+ * Applied patch from Jane Random.
+</screen>
+<para>
+What was the patch about?
+</para>
+<screen>
+ * Late night install target overhaul.
+</screen>
+<para>
+Overhaul which accomplished what? Is the mention of late night supposed to
+remind us that we shouldn't trust that code?
+</para>
+<screen>
+ * Fix vsync FU w/ ancient CRTs.
+</screen>
+<para>
+Too many acronyms, and it's not overly clear what the, uh, fsckup (oops, a
+curse word!) was actually about, or how it was fixed.
+</para>
+<screen>
+ * This is not a bug, closes: #nnnnnn.
+</screen>
+<para>
+First of all, there's absolutely no need to upload the package to convey this
+information; instead, use the bug tracking system. Secondly, there's no
+explanation as to why the report is not a bug.
+</para>
+<screen>
+ * Has been fixed for ages, but I forgot to close; closes: #54321.
+</screen>
+<para>
+If for some reason you didn't mention the bug number in a previous changelog
+entry, there's no problem, just close the bug normally in the BTS. There's no
+need to touch the changelog file, presuming the description of the fix is
+already in (this applies to the fixes by the upstream authors/maintainers as
+well, you don't have to track bugs that they fixed ages ago in your changelog).
+</para>
+<screen>
+ * Closes: #12345, #12346, #15432
+</screen>
+<para>
+Where's the description? If you can't think of a descriptive message, start by
+inserting the title of each different bug.
+</para>
+</section>
+
+<section id="bpp-news-debian">
+<title>Supplementing changelogs with NEWS.Debian files</title>
+<para>
+Important news about changes in a package can also be put in NEWS.Debian files.
+The news will be displayed by tools like apt-listchanges, before all the rest
+of the changelogs. This is the preferred means to let the user know about
+significant changes in a package. It is better than using debconf notes since
+it is less annoying and the user can go back and refer to the NEWS.Debian file
+after the install. And it's better than listing major changes in
+README.Debian, since the user can easily miss such notes.
+</para>
+<para>
+The file format is the same as a debian changelog file, but leave off the
+asterisks and describe each news item with a full paragraph when necessary
+rather than the more concise summaries that would go in a changelog. It's a
+good idea to run your file through dpkg-parsechangelog to check its formatting
+as it will not be automatically checked during build as the changelog is. Here
+is an example of a real NEWS.Debian file:
+</para>
+<screen>
+cron (3.0pl1-74) unstable; urgency=low
+
+ The checksecurity script is no longer included with the cron package:
+ it now has its own package, checksecurity. If you liked the
+ functionality provided with that script, please install the new
+ package.
+
+ -- Steve Greenland <stevegr@debian.org> Sat, 6 Sep 2003 17:15:03 -0500
+</screen>
+<para>
+The NEWS.Debian file is installed as
+/usr/share/doc/<package>/NEWS.Debian.gz. It is compressed, and always
+has that name even in Debian native packages. If you use debhelper,
+dh_installchangelogs will install debian/NEWS files for you.
+</para>
+<para>
+Unlike changelog files, you need not update NEWS.Debian files with every
+release. Only update them if you have something particularly newsworthy that
+user should know about. If you have no news at all, there's no need to ship a
+NEWS.Debian file in your package. No news is good news!
+</para>
+</section>
+
+</section>
+
+<!--
+<section id="pkg-mgmt-cvs">
+<title>Managing a package with CVS</title>
+<para>
+FIXME: presentation of cvs-buildpackage, updating sources
+via CVS (debian/rules refresh).
+<ulink url="&url-devel-docs;cvs_packages">"&url-devel-docs;cvs_packages"</ulink>
+</para>
+</section>
+-->
+
+<section id="bpp-debian-maint-scripts">
+<title>Best practices for maintainer scripts</title>
+<para>
+Maintainer scripts include the files <filename>debian/postinst</filename>,
+<filename>debian/preinst</filename>, <filename>debian/prerm</filename> and
+<filename>debian/postrm</filename>. These scripts take care of any package
+installation or deinstallation setup which isn't handled merely by the creation
+or removal of files and directories. The following instructions supplement the
+<ulink url="&url-debian-policy;">Debian Policy</ulink>.
+</para>
+<para>
+Maintainer scripts must be idempotent. That means that you need to make sure
+nothing bad will happen if the script is called twice where it would usually be
+called once.
+</para>
+<para>
+Standard input and output may be redirected (e.g. into pipes) for logging
+purposes, so don't rely on them being a tty.
+</para>
+<para>
+All prompting or interactive configuration should be kept to a minimum. When
+it is necessary, you should use the <systemitem
+role="package">debconf</systemitem> package for the interface. Remember that
+prompting in any case can only be in the <literal>configure</literal> stage of
+the <filename>postinst</filename> script.
+</para>
+<para>
+Keep the maintainer scripts as simple as possible. We suggest you use pure
+POSIX shell scripts. Remember, if you do need any bash features, the
+maintainer script must have a bash shebang line. POSIX shell or Bash are
+preferred to Perl, since they enable <systemitem
+role="package">debhelper</systemitem> to easily add bits to the scripts.
+</para>
+<para>
+If you change your maintainer scripts, be sure to test package removal, double
+installation, and purging. Be sure that a purged package is completely gone,
+that is, it must remove any files created, directly or indirectly, in any
+maintainer script.
+</para>
+<para>
+If you need to check for the existence of a command, you should use something
+like
+</para>
+<programlisting>if [ -x /usr/sbin/install-docs ]; then ...</programlisting>
+<para>
+If you don't wish to hard-code the path of a command in your maintainer script,
+the following POSIX-compliant shell function may help:
+</para>
+&example-pathfind;
+<para>
+You can use this function to search <literal>$PATH</literal> for a command
+name, passed as an argument. It returns true (zero) if the command was found,
+and false if not. This is really the most portable way, since <literal>command
+-v</literal>, <command>type</command>, and <command>which</command> are not
+POSIX.
+</para>
+<para>
+While <command>which</command> is an acceptable alternative, since it is from
+the required <systemitem role="package">debianutils</systemitem> package, it's
+not on the root partition. That is, it's in <filename>/usr/bin</filename>
+rather than <filename>/bin</filename>, so one can't use it in scripts which are
+run before the <filename>/usr</filename> partition is mounted. Most scripts
+won't have this problem, though.
+</para>
+</section>
+
+<section id="bpp-config-mgmt">
+<title>Configuration management with <systemitem role="package">debconf</systemitem></title>
+<para>
+<systemitem role="package">Debconf</systemitem> is a configuration management
+system which can be used by all the various packaging scripts
+(<filename>postinst</filename> mainly) to request feedback from the user
+concerning how to configure the package. Direct user interactions must now be
+avoided in favor of <systemitem role="package">debconf</systemitem>
+interaction. This will enable non-interactive installations in the future.
+</para>
+<para>
+Debconf is a great tool but it is often poorly used. Many common mistakes are
+listed in the <citerefentry> <refentrytitle>debconf-devel</refentrytitle>
+<manvolnum>7</manvolnum> </citerefentry> man page. It is something that you
+must read if you decide to use debconf. Also, we document some best practices
+here.
+</para>
+<para>
+These guidelines include some writing style and typography recommendations,
+general considerations about debconf usage as well as more specific
+recommendations for some parts of the distribution (the installation system for
+instance).
+</para>
+<section id="s6.5.1">
+<title>Do not abuse debconf</title>
+<para>
+Since debconf appeared in Debian, it has been widely abused and several
+criticisms received by the Debian distribution come from debconf abuse with the
+need of answering a wide bunch of questions before getting any little thing
+installed.
+</para>
+<para>
+Keep usage notes to what they belong: the NEWS.Debian, or README.Debian file.
+Only use notes for important notes which may directly affect the package
+usability. Remember that notes will always block the install until confirmed
+or bother the user by email.
+</para>
+<para>
+Carefully choose the questions priorities in maintainer scripts. See
+<citerefentry> <refentrytitle>debconf-devel</refentrytitle>
+<manvolnum>7</manvolnum> </citerefentry> for details about priorities. Most
+questions should use medium and low priorities.
+</para>
+</section>
+
+<section id="s6.5.2">
+<title>General recommendations for authors and translators</title>
+<section id="s6.5.2.1">
+<title>Write correct English</title>
+<para>
+Most Debian package maintainers are not native English speakers. So, writing
+properly phrased templates may not be easy for them.
+</para>
+<para>
+Please use (and abuse) &email-debian-l10n-english; mailing
+list. Have your templates proofread.
+</para>
+<para>
+Badly written templates give a poor image of your package, of your work...or
+even of Debian itself.
+</para>
+<para>
+Avoid technical jargon as much as possible. If some terms sound common to you,
+they may be impossible to understand for others. If you cannot avoid them, try
+to explain them (use the extended description). When doing so, try to balance
+between verbosity and simplicity.
+</para>
+</section>
+
+<section id="s6.5.2.2">
+<title>Be kind to translators</title>
+<para>
+Debconf templates may be translated. Debconf, along with its sister package
+<command>po-debconf</command> offers a simple framework for getting templates
+translated by translation teams or even individuals.
+</para>
+<para>
+Please use gettext-based templates. Install <systemitem
+role="package">po-debconf</systemitem> on your development system and read its
+documentation (man po-debconf is a good start).
+</para>
+<para>
+Avoid changing templates too often. Changing templates text induces more work
+to translators which will get their translation fuzzied. If you plan changes
+to your original templates, please contact translators. Most active
+translators are very responsive and getting their work included along with your
+modified templates will save you additional uploads. If you use gettext-based
+templates, the translator's name and e-mail addresses are mentioned in the po
+files headers.
+</para>
+<para>
+The use of the <command>podebconf-report-po</command> from the po-debconf
+package is highly recommended to warn translators which have incomplete
+translations and request them for updates.
+</para>
+<para>
+If in doubt, you may also contact the translation team for a given language
+(debian-l10n-xxxxx@&lists-host;), or the
+&email-debian-i18n; mailing list.
+</para>
+<para>
+Calls for translations posted to &email-debian-i18n; with the
+<filename>debian/po/templates.pot</filename> file attached or referenced in a
+URL are encouraged. Be sure to mentions in these calls for new translations
+which languages you have existing translations for, in order to avoid duplicate
+work.
+</para>
+</section>
+
+<section id="s6.5.2.3">
+<title>Unfuzzy complete translations when correcting typos and spelling</title>
+<para>
+When the text of a debconf template is corrected and you are <emphasis
+role="strong">sure</emphasis> that the change does <emphasis
+role="strong">not</emphasis> affect translations, please be kind to translators
+and unfuzzy their translations.
+</para>
+<para>
+If you don't do so, the whole template will not be translated as long as a
+translator will send you an update.
+</para>
+<para>
+To <emphasis role="strong">unfuzzy</emphasis> translations, you can proceed the
+following way:
+</para>
+<orderedlist numeration="arabic">
+<listitem>
+<para>
+Put all incomplete PO files out of the way. You can check the completeness by
+using (needs the <systemitem role="package">gettext</systemitem> package
+installed):
+</para>
+<programlisting>for i in debian/po/*po; do echo -n $i: ; msgfmt -o /dev/null
+--statistics $i; done</programlisting>
+</listitem>
+<listitem>
+<para>
+move all files which report either fuzzy strings to a temporary place. Files
+which report no fuzzy strings (only translated and untranslated) will be kept
+in place.
+</para>
+</listitem>
+<listitem>
+<para>
+now <emphasis role="strong">and now only</emphasis>, modify the template for
+the typos and check again that translation are not impacted (typos, spelling
+errors, sometimes typographical corrections are usually OK)
+</para>
+</listitem>
+<listitem>
+<para>
+run <command>debconf-updatepo</command>. This will fuzzy all strings you
+modified in translations. You can see this by running the above again
+</para>
+</listitem>
+<listitem>
+<para>
+use the following command:
+</para>
+<programlisting>for i in debian/po/*po; do msgattrib --output-file=$i --clear-fuzzy $i; done</programlisting>
+</listitem>
+<listitem>
+<para>
+move back to debian/po the files which showed fuzzy strings in the first step
+</para>
+</listitem>
+<listitem>
+<para>
+run <command>debconf-updatepo</command> again
+</para>
+</listitem>
+</orderedlist>
+</section>
+
+<section id="s6.5.2.4">
+<title>Do not make assumptions about interfaces</title>
+<para>
+Templates text should not make reference to widgets belonging to some debconf
+interfaces. Sentences like If you answer Yes... have no meaning for users of
+graphical interfaces which use checkboxes for boolean questions.
+</para>
+<para>
+String templates should also avoid mentioning the default values in their
+description. First, because this is redundant with the values seen by the
+users. Also, because these default values may be different from the maintainer
+choices (for instance, when the debconf database was preseeded).
+</para>
+<para>
+More generally speaking, try to avoid referring to user actions. Just give
+facts.
+</para>
+</section>
+
+<section id="s6.5.2.5">
+<title>Do not use first person</title>
+<para>
+You should avoid the use of first person (I will do this... or We
+recommend...). The computer is not a person and the Debconf templates do not
+speak for the Debian developers. You should use neutral construction. Those
+of you who already wrote scientific publications, just write your templates
+like you would write a scientific paper. However, try using action voice if
+still possible, like Enable this if ... instead of This can be enabled if ....
+</para>
+</section>
+
+<section id="s6.5.2.6">
+<title>Be gender neutral</title>
+<para>
+The world is made of men and women. Please use gender-neutral constructions in
+your writing.
+</para>
+</section>
+
+</section>
+
+<section id="s6.5.3">
+<title>Templates fields definition</title>
+<para>
+This part gives some information which is mostly taken from the <citerefentry>
+<refentrytitle>debconf-devel</refentrytitle> <manvolnum>7</manvolnum>
+</citerefentry> manual page.
+</para>
+<section id="s6.5.3.1">
+<title>Type</title>
+<section id="s6.5.3.1.1">
+<title>string:</title>
+<para>
+Results in a free-form input field that the user can type any string into.
+</para>
+</section>
+
+<section id="s6.5.3.1.2">
+<title>password:</title>
+<para>
+Prompts the user for a password. Use this with caution; be aware that the
+password the user enters will be written to debconf's database. You should
+probably clean that value out of the database as soon as is possible.
+</para>
+</section>
+
+<section id="s6.5.3.1.3">
+<title>boolean:</title>
+<para>
+A true/false choice. Remember: true/false, <emphasis role="strong">not
+yes/no</emphasis>...
+</para>
+</section>
+
+<section id="s6.5.3.1.4">
+<title>select:</title>
+<para>
+A choice between one of a number of values. The choices must be specified in a
+field named 'Choices'. Separate the possible values with commas and spaces,
+like this: Choices: yes, no, maybe
+</para>
+</section>
+
+<section id="s6.5.3.1.5">
+<title>multiselect:</title>
+<para>
+Like the select data type, except the user can choose any number of items from
+the choices list (or chose none of them).
+</para>
+</section>
+
+<section id="s6.5.3.1.6">
+<title>note:</title>
+<para>
+Rather than being a question per se, this datatype indicates a note that can be
+displayed to the user. It should be used only for important notes that the
+user really should see, since debconf will go to great pains to make sure the
+user sees it; halting the install for them to press a key, and even mailing the
+note to them in some cases.
+</para>
+</section>
+
+<section id="s6.5.3.1.7">
+<title>text:</title>
+<para>
+This type is now considered obsolete: don't use it.
+</para>
+</section>
+
+<section id="s6.5.3.1.8">
+<title>error:</title>
+<para>
+This type is designed to handle error messages. It is mostly similar to the
+note type. Frontends may present it differently (for instance, the dialog
+frontend of cdebconf draws a red screen instead of the usual blue one).
+</para>
+<para>
+It is recommended to use this type for any message that needs user attention
+for a correction of any kind.
+</para>
+</section>
+
+</section>
+
+<section id="s6.5.3.2">
+<title>Description: short and extended description</title>
+<para>
+Template descriptions have two parts: short and extended. The short
+description is in the Description: line of the template.
+</para>
+<para>
+The short description should be kept short (50 characters or so) so that it may
+be accomodated by most debconf interfaces. Keeping it short also helps
+translators, as usually translations tend to end up being longer than the
+original.
+</para>
+<para>
+The short description should be able to stand on its own. Some interfaces do
+not show the long description by default, or only if the user explicitely asks
+for it or even do not show it at all. Avoid things like What do you want to
+do?
+</para>
+<para>
+The short description does not necessarily have to be a full sentence. This is
+part of the keep it short and efficient recommendation.
+</para>
+<para>
+The extended description should not repeat the short description word for word.
+If you can't think up a long description, then first, think some more. Post to
+debian-devel. Ask for help. Take a writing class! That extended description
+is important. If after all that you still can't come up with anything, leave
+it blank.
+</para>
+<para>
+The extended description should use complete sentences. Paragraphs should be
+kept short for improved readability. Do not mix two ideas in the same
+paragraph but rather use another paragraph.
+</para>
+<para>
+Don't be too verbose. User tend to ignore too long screens. 20 lines are by
+experience a border you shouldn't cross, because that means that in the
+classical dialog interface, people will need to scroll, and lot of people just
+don't do that.
+</para>
+<para>
+The extended description should <emphasis role="strong">never</emphasis>
+include a question.
+</para>
+<para>
+For specific rules depending on templates type (string, boolean, etc.), please
+read below.
+</para>
+</section>
+
+<section id="s6.5.3.3">
+<title>Choices</title>
+<para>
+This field should be used for Select and Multiselect types. It contains the
+possible choices which will be presented to users. These choices should be
+separated by commas.
+</para>
+</section>
+
+<section id="s6.5.3.4">
+<title>Default</title>
+<para>
+This field is optional. It contains the default answer for string, select and
+multiselect templates. For multiselect templates, it may contain a
+comma-separated list of choices.
+</para>
+</section>
+
+</section>
+
+<section id="s6.5.4">
+<title>Templates fields specific style guide</title>
+<section id="s6.5.4.1">
+<title>Type field</title>
+<para>
+No specific indication except: use the appropriate type by referring to the
+previous section.
+</para>
+</section>
+
+<section id="s6.5.4.2">
+<title>Description field</title>
+<para>
+Below are specific instructions for properly writing the Description (short and
+extended) depending on the template type.
+</para>
+<section id="s6.5.4.2.1">
+<title>String/password templates</title>
+<itemizedlist>
+<listitem>
+<para>
+The short description is a prompt and <emphasis role="strong">not</emphasis> a
+title. Avoid question style prompts (IP Address?) in favour of opened prompts
+(IP address:). The use of colons is recommended.
+</para>
+</listitem>
+<listitem>
+<para>
+The extended description is a complement to the short description. In the
+extended part, explain what is being asked, rather than ask the same question
+again using longer words. Use complete sentences. Terse writing style is
+strongly discouraged.
+</para>
+</listitem>
+</itemizedlist>
+</section>
+
+<section id="s6.5.4.2.2">
+<title>Boolean templates</title>
+<itemizedlist>
+<listitem>
+<para>
+The short description should be phrased in the form of a question which should
+be kept short and should generally end with a question mark. Terse writing
+style is permitted and even encouraged if the question is rather long (remember
+that translations are often longer than original versions)
+</para>
+</listitem>
+<listitem>
+<para>
+Again, please avoid referring to specific interface widgets. A common mistake
+for such templates is if you answer Yes-type constructions.
+</para>
+</listitem>
+</itemizedlist>
+</section>
+
+<section id="s6.5.4.2.3">
+<title>Select/Multiselect</title>
+<itemizedlist>
+<listitem>
+<para>
+The short description is a prompt and <emphasis role="strong">not</emphasis> a
+title. Do <emphasis role="strong">not</emphasis> use useless Please choose...
+constructions. Users are clever enough to figure out they have to choose
+something...:)
+</para>
+</listitem>
+<listitem>
+<para>
+The extended description will complete the short description. It may refer to
+the available choices. It may also mention that the user may choose more than
+one of the available choices, if the template is a multiselect one (although
+the interface often makes this clear).
+</para>
+</listitem>
+</itemizedlist>
+</section>
+
+<section id="s6.5.4.2.4">
+<title>Notes</title>
+<itemizedlist>
+<listitem>
+<para>
+The short description should be considered to be a *title*.
+</para>
+</listitem>
+<listitem>
+<para>
+The extended description is what will be displayed as a more detailed
+explanation of the note. Phrases, no terse writing style.
+</para>
+</listitem>
+<listitem>
+<para>
+<emphasis role="strong">Do not abuse debconf.</emphasis> Notes are the most
+common way to abuse debconf. As written in debconf-devel manual page: it's
+best to use them only for warning about very serious problems. The NEWS.Debian
+or README.Debian files are the appropriate location for a lot of notes. If, by
+reading this, you consider converting your Note type templates to entries in
+NEWS/Debian or README.Debian, plus consider keeping existing translations for
+the future.
+</para>
+</listitem>
+</itemizedlist>
+</section>
+
+</section>
+
+<section id="s6.5.4.3">
+<title>Choices field</title>
+<para>
+If the Choices are likely to change often, please consider using the __Choices
+trick. This will split each individual choice into a single string, which will
+considerably help translators for doing their work.
+</para>
+</section>
+
+<section id="s6.5.4.4">
+<title>Default field</title>
+<para>
+If the default value, for a select template, is likely to vary depending on the
+user language (for instance, if the choice is a language choice), please use
+the _DefaultChoice trick.
+</para>
+<para>
+This special field allow translators to put the most appropriate choice
+according to their own language. It will become the default choice when their
+language is used while your own mentioned Default Choice will be used chan
+using English.
+</para>
+<para>
+Example, taken from the geneweb package templates:
+</para>
+<screen>
+Template: geneweb/lang
+Type: select
+__Choices: Afrikaans (af), Bulgarian (bg), Catalan (ca), Chinese (zh), Czech (cs), Danish (da), Dutch (nl), English (en), Esperanto (eo), Estonian (et), Finnish (fi), French (fr), German (de), Hebrew (he), Icelandic (is), Italian (it), Latvian (lv), Norwegian (no), Polish (pl), Portuguese (pt), Romanian (ro), Russian (ru), Spanish (es), Swedish (sv)
+# This is the default choice. Translators may put their own language here
+# instead of the default.
+# WARNING : you MUST use the ENGLISH FORM of your language
+# For instance, the french translator will need to put French (fr) here.
+_DefaultChoice: English (en)[ translators, please see comment in PO files]
+_Description: Geneweb default language:
+</screen>
+<para>
+Note the use of brackets which allow internal comments in debconf fields. Also
+note the use of comments which will show up in files the translators will work
+with.
+</para>
+<para>
+The comments are needed as the DefaultChoice trick is a bit confusing: the
+translators may put their own choice
+</para>
+</section>
+
+<section id="s6.5.4.5">
+<title>Default field</title>
+<para>
+Do NOT use empty default field. If you don't want to use default values, do
+not use Default at all.
+</para>
+<para>
+If you use po-debconf (and you <emphasis role="strong">should</emphasis>, see
+2.2), consider making this field translatable, if you think it may be
+translated.
+</para>
+<para>
+If the default value may vary depending on language/country (for instance the
+default value for a language choice), consider using the special _DefaultChoice
+type documented in <citerefentry> <refentrytitle>po-debconf</refentrytitle>
+<manvolnum>7</manvolnum> </citerefentry>).
+</para>
+</section>
+
+</section>
+
+</section>
+
+<section id="bpp-i18n">
+<title>Internationalization</title>
+<section id="bpp-i18n-debconf">
+<title>Handling debconf translations</title>
+<para>
+Like porters, translators have a difficult task. They work on many packages
+and must collaborate with many different maintainers. Moreover, most of the
+time, they are not native English speakers, so you may need to be particularly
+patient with them.
+</para>
+<para>
+The goal of <systemitem role="package">debconf</systemitem> was to make
+packages configuration easier for maintainers and for users. Originally,
+translation of debconf templates was handled with
+<command>debconf-mergetemplate</command>. However, that technique is now
+deprecated; the best way to accomplish <systemitem
+role="package">debconf</systemitem> internationalization is by using the
+<systemitem role="package">po-debconf</systemitem> package. This method is
+easier both for maintainer and translators; transition scripts are provided.
+</para>
+<para>
+Using <systemitem role="package">po-debconf</systemitem>, the translation is
+stored in <filename>po</filename> files (drawing from
+<command>gettext</command> translation techniques). Special template files
+contain the original messages and mark which fields are translatable. When you
+change the value of a translatable field, by calling
+<command>debconf-updatepo</command>, the translation is marked as needing
+attention from the translators. Then, at build time, the
+<command>dh_installdebconf</command> program takes care of all the needed magic
+to add the template along with the up-to-date translations into the binary
+packages. Refer to the <citerefentry>
+<refentrytitle>po-debconf</refentrytitle> <manvolnum>7</manvolnum>
+</citerefentry> manual page for details.
+</para>
+</section>
+
+<section id="bpp-i18n-docs">
+<title>Internationalized documentation</title>
+<para>
+Internationalizing documentation is crucial for users, but a lot of labor.
+There's no way to eliminate all that work, but you can make things easier for
+translators.
+</para>
+<para>
+If you maintain documentation of any size, its easier for translators if they
+have access to a source control system. That lets translators see the
+differences between two versions of the documentation, so, for instance, they
+can see what needs to be retranslated. It is recommended that the translated
+documentation maintain a note about what source control revision the
+translation is based on. An interesting system is provided by <ulink
+url="&url-i18n-doc-check;">doc-check</ulink> in the
+<systemitem role="package">boot-floppies</systemitem> package, which shows an
+overview of the translation status for any given language, using structured
+comments for the current revision of the file to be translated and, for a
+translated file, the revision of the original file the translation is based on.
+You might wish to adapt and provide that in your CVS area.
+</para>
+<para>
+If you maintain XML or SGML documentation, we suggest that you isolate any
+language-independent information and define those as entities in a separate
+file which is included by all the different translations. This makes it much
+easier, for instance, to keep URLs up to date across multiple files.
+</para>
+</section>
+
+</section>
+
+<section id="bpp-common-situations">
+<title>Common packaging situations</title>
+<!--
+<section id="bpp-kernel">
+<title>Kernel modules/patches</title>
+<para>
+FIXME: Heavy use of kernel-package. provide files in
+/etc/modutils/ for module configuration.
+</para>
+</section>
+-->
+<section id="bpp-autotools">
+<title>Packages using <command>autoconf</command>/<command>automake</command></title>
+<para>
+Keeping <command>autoconf</command>'s <filename>config.sub</filename> and
+<filename>config.guess</filename> files up to date is critical for porters,
+especially on more volatile architectures. Some very good packaging practices
+for any package using <command>autoconf</command> and/or
+<command>automake</command> have been synthesized in
+&file-bpp-autotools; from the
+<systemitem role="package">autotools-dev</systemitem> package. You're strongly
+encouraged to read this file and to follow the given recommendations.
+</para>
+</section>
+
+<section id="bpp-libraries">
+<title>Libraries</title>
+<para>
+Libraries are always difficult to package for various reasons. The policy
+imposes many constraints to ease their maintenance and to make sure upgrades
+are as simple as possible when a new upstream version comes out. Breakage in a
+library can result in dozens of dependent packages breaking.
+</para>
+<para>
+Good practices for library packaging have been grouped in <ulink
+url="&url-libpkg-guide;">the library
+packaging guide</ulink>.
+</para>
+</section>
+
+<section id="bpp-docs">
+<title>Documentation</title>
+<para>
+Be sure to follow the <ulink
+url="&url-debian-policy;ch-docs.html">Policy on
+documentation</ulink>.
+</para>
+<para>
+If your package contains documentation built from XML or SGML, we recommend you
+not ship the XML or SGML source in the binary package(s). If users want the
+source of the documentation, they should retrieve the source package.
+</para>
+<para>
+Policy specifies that documentation should be shipped in HTML format. We also
+recommend shipping documentation in PDF and plain text format if convenient and
+if output of reasonable quality is possible. However, it is generally not
+appropriate to ship plain text versions of documentation whose source format is
+HTML.
+</para>
+<para>
+Major shipped manuals should register themselves with <systemitem
+role="package">doc-base</systemitem> on installation. See the <systemitem
+role="package">doc-base</systemitem> package documentation for more
+information.
+</para>
+</section>
+
+<section id="bpp-other">
+<title>Specific types of packages</title>
+<para>
+Several specific types of packages have special sub-policies and corresponding
+packaging rules and practices:
+</para>
+<itemizedlist>
+<listitem>
+<para>
+Perl related packages have a <ulink
+url="&url-perl-policy;">Perl
+policy</ulink>, some examples of packages following that policy are <systemitem
+role="package">libdbd-pg-perl</systemitem> (binary perl module) or <systemitem
+role="package">libmldbm-perl</systemitem> (arch independent perl module).
+</para>
+</listitem>
+<listitem>
+<para>
+Python related packages have their python policy; see
+&file-python-policy; in the <systemitem
+role="package">python</systemitem> package.
+</para>
+</listitem>
+<listitem>
+<para>
+Emacs related packages have the <ulink
+url="&url-emacs-policy;">emacs
+policy</ulink>.
+</para>
+</listitem>
+<listitem>
+<para>
+Java related packages have their <ulink
+url="&url-java-policy;">java
+policy</ulink>.
+</para>
+</listitem>
+<listitem>
+<para>
+Ocaml related packages have their own policy, found in
+&file-ocaml-policy; from the <systemitem
+role="package">ocaml</systemitem> package. A good example is the <systemitem
+role="package">camlzip</systemitem> source package.
+</para>
+</listitem>
+<listitem>
+<para>
+Packages providing XML or SGML DTDs should conform to the recommendations found
+in the <systemitem role="package">sgml-base-doc</systemitem> package.
+</para>
+</listitem>
+<listitem>
+<para>
+Lisp packages should register themselves with <systemitem
+role="package">common-lisp-controller</systemitem>, about which see
+&file-lisp-controller;.
+</para>
+</listitem>
+<!-- TODO: mozilla extension policy, once that becomes available -->
+</itemizedlist>
+</section>
+
+<!--
+<section id="custom-config-files">
+<title>Custom configuration files</title>
+<para>
+FIXME: speak of "ucf", explain solution with a template,
+explain conf.d directories
+</para>
+</section>
+<section id="config-with-db">
+<title>Use of an external database</title>
+<para>
+FIXME: The software may require a database that you need to setup.
+But the database may be local or distant. Thus you can't depend
+on a database server but just on the corresponding library.
+
+sympa may be an example package
+</para>
+</section>
+-->
+
+<section id="bpp-archindepdata">
+<title>Architecture-independent data</title>
+<para>
+It is not uncommon to have a large amount of architecture-independent data
+packaged with a program. For example, audio files, a collection of icons,
+wallpaper patterns, or other graphic files. If the size of this data is
+negligible compared to the size of the rest of the package, it's probably best
+to keep it all in a single package.
+</para>
+<para>
+However, if the size of the data is considerable, consider splitting it out
+into a separate, architecture-independent package (_all.deb). By doing this,
+you avoid needless duplication of the same data into eleven or more .debs, one
+per each architecture. While this adds some extra overhead into the
+<filename>Packages</filename> files, it saves a lot of disk space on Debian
+mirrors. Separating out architecture-independent data also reduces processing
+time of <command>lintian</command> or <command>linda</command> (see <xref
+linkend="tools-lint"/> ) when run over the entire Debian archive.
+</para>
+</section>
+
+<section id="bpp-locale">
+<title>Needing a certain locale during build</title>
+<para>
+If you need a certain locale during build, you can create a temporary file via
+this trick:
+</para>
+<para>
+If you set <varname>LOCPATH</varname> to the equivalent of <filename>/usr/lib/locale</filename>, and <varname>LC_ALL</varname> to the name
+of the locale you generate, you should get what you want without being root.
+Something like this:
+</para>
+<screen>
+LOCALE_PATH=debian/tmpdir/usr/lib/locale
+LOCALE_NAME=en_IN
+LOCALE_CHARSET=UTF-8
+
+mkdir -p $LOCALE_PATH
+localedef -i $LOCALE_NAME.$LOCALE_CHARSET -f $LOCALE_CHARSET $LOCALE_PATH/$LOCALE_NAME.$LOCALE_CHARSET
+
+# Using the locale
+LOCPATH=$LOCALE_PATH LC_ALL=$LOCALE_NAME.$LOCALE_CHARSET date
+</screen>
+</section>
+
+<section id="bpp-transition">
+<title>Make transition packages deborphan compliant</title>
+<para>
+Deborphan is a program for helping users to detect which packages can safely be
+removed from the system, i.e. the ones that have no packages depending on
+them. The default operation is to search only within the libs and oldlibs
+sections, to hunt down unused libraries. But when passed the right argument,
+it tries to catch other useless packages.
+</para>
+<para>
+For example, with --guess-dummy, deborphan tries to search all transitional
+packages which were needed for upgrade but which can now safely be removed.
+For that, it looks for the string dummy or transitional in their short
+description.
+</para>
+<para>
+So, when you are creating such a package, please make sure to add this text to
+your short description. If you are looking for examples, just run:
+<command>apt-cache search .|grep dummy</command> or
+<command>apt-cache search .|grep transitional</command>.
+</para>
+</section>
+
+<section id="bpp-origtargz">
+<title>Best practices for <filename>orig.tar.gz</filename> files</title>
+<para>
+There are two kinds of original source tarballs: Pristine source and repackaged
+upstream source.
+</para>
+<section id="pristinesource">
+<title>Pristine source</title>
+<para>
+The defining characteristic of a pristine source tarball is that the
+.orig.tar.gz file is byte-for-byte identical to a tarball officially
+distributed by the upstream author. <footnote><para> We cannot prevent
+upstream authors from changing the tarball they distribute without also
+incrementing the version number, so there can be no guarantee that a pristine
+tarball is identical to what upstream <emphasis>currently</emphasis>
+distributing at any point in time. All that can be expected is that it is
+identical to something that upstream once <emphasis>did</emphasis> distribute.
+If a difference arises later (say, if upstream notices that he wasn't using
+maximal comression in his original distribution and then
+re-<literal>gzip</literal>s it), that's just too bad. Since there is no good
+way to upload a new .orig.tar.gz for the same version, there is not even any
+point in treating this situation as a bug. </para> </footnote> This makes it
+possible to use checksums to easily verify that all changes between Debian's
+version and upstream's are contained in the Debian diff. Also, if the original
+source is huge, upstream authors and others who already have the upstream
+tarball can save download time if they want to inspect your packaging in
+detail.
+</para>
+<para>
+There is no universally accepted guidelines that upstream authors follow
+regarding to the directory structure inside their tarball, but
+<command>dpkg-source</command> is nevertheless able to deal with most upstream
+tarballs as pristine source. Its strategy is equivalent to the following:
+</para>
+<orderedlist numeration="arabic">
+<listitem>
+<para>
+It unpacks the tarball in an empty temporary directory by doing
+</para>
+<screen>
+zcat path/to/<packagename>_<upstream-version>.orig.tar.gz | tar xf -
+</screen>
+</listitem>
+<listitem>
+<para>
+If, after this, the temporary directory contains nothing but one directory and
+no other files, <command>dpkg-source</command> renames that directory to
+<literal><packagename>-<upstream-version>(.orig)</literal>. The
+name of the top-level directory in the tarball does not matter, and is
+forgotten.
+</para>
+</listitem>
+<listitem>
+<para>
+Otherwise, the upstream tarball must have been packaged without a common
+top-level directory (shame on the upstream author!). In this case,
+<command>dpkg-source</command> renames the temporary directory
+<emphasis>itself</emphasis> to
+<literal><packagename>-<upstream-version>(.orig)</literal>.
+</para>
+</listitem>
+</orderedlist>
+</section>
+
+<section id="repackagedorigtargz">
+<title>Repackaged upstream source</title>
+<para>
+You <emphasis role="strong">should</emphasis> upload packages with a pristine
+source tarball if possible, but there are various reasons why it might not be
+possible. This is the case if upstream does not distribute the source as
+gzipped tar at all, or if upstream's tarball contains non-DFSG-free material
+that you must remove before uploading.
+</para>
+<para>
+In these cases the developer must construct a suitable .orig.tar.gz file
+himself. We refer to such a tarball as a repackaged upstream source. Note
+that a repackaged upstream source is different from a Debian-native package. A
+repackaged source still comes with Debian-specific changes in a separate
+<literal>.diff.gz</literal> and still has a version number composed of
+<literal><upstream-version></literal> and
+<literal><debian-revision></literal>.
+</para>
+<para>
+There may be cases where it is desirable to repackage the source even though
+upstream distributes a <literal>.tar.gz</literal> that could in principle be
+used in its pristine form. The most obvious is if
+<emphasis>significant</emphasis> space savings can be achieved by recompressing
+the tar archive or by removing genuinely useless cruft from the upstream
+archive. Use your own discretion here, but be prepared to defend your decision
+if you repackage source that could have been pristine.
+</para>
+<para>
+A repackaged .orig.tar.gz
+</para>
+<orderedlist numeration="arabic">
+<listitem>
+<para>
+<emphasis role="strong">must</emphasis> contain detailed information how the
+repackaged source was obtained, and how this can be reproduced in the
+<filename>debian/copyright</filename>. It is also a good idea to provide a
+<literal>get-orig-source</literal> target in your
+<filename>debian/rules</filename> file that repeats the process, as described
+in the Policy Manual, <ulink
+url="&url-debian-policy;ch-source.html#s-debianrules">Main
+building script: debian/rules</ulink>.
+</para>
+</listitem>
+<listitem>
+<para>
+<emphasis role="strong">should not</emphasis> contain any file that does not
+come from the upstream author(s), or whose contents has been changed by you.
+<footnote><para> As a special exception, if the omission of non-free files
+would lead to the source failing to build without assistance from the Debian
+diff, it might be appropriate to instead edit the files, omitting only the
+non-free parts of them, and/or explain the situation in a README.Debian-source
+<!-- or similarly named -->
+file in the root of the source tree. But in that case please also urge the
+upstream author to make the non-free components easier seperable from the rest
+of the source. </para> </footnote>
+</para>
+</listitem>
+<listitem>
+<para>
+<emphasis role="strong">should</emphasis>, except where impossible for legal
+reasons, preserve the entire building and portablility infrastructure provided
+by the upstream author. For example, it is not a sufficient reason for
+omitting a file that it is used only when building on MS-DOS. Similarly, a
+Makefile provided by upstream should not be omitted even if the first thing
+your <filename>debian/rules</filename> does is to overwrite it by running a
+configure script.
+</para>
+<para>
+(<emphasis>Rationale:</emphasis> It is common for Debian users who need to
+build software for non-Debian platforms to fetch the source from a Debian
+mirror rather than trying to locate a canonical upstream distribution point).
+</para>
+</listitem>
+<listitem>
+<para>
+<emphasis role="strong">should</emphasis> use
+<literal><packagename>-<upstream-version>.orig</literal> as the
+name of the top-level directory in its tarball. This makes it possible to
+distinguish pristine tarballs from repackaged ones.
+</para>
+</listitem>
+<listitem>
+<para>
+<emphasis role="strong">should</emphasis> be gzipped with maximal compression.
+</para>
+</listitem>
+</orderedlist>
+<para>
+The canonical way to meet the latter two points is to let <literal>dpkg-source
+-b</literal> construct the repackaged tarball from an unpacked directory.
+</para>
+</section>
+
+<section id="changed-binfiles">
+<title>Changing binary files in <literal>diff.gz</literal></title>
+<para>
+Sometimes it is necessary to change binary files contained in the original
+tarball, or to add binary files that are not in it. If this is done by simply
+copying the files into the debianized source tree,
+<command>dpkg-source</command> will not be able to handle this. On the other
+hand, according to the guidelines given above, you cannot include such a
+changed binary file in a repackaged <filename>orig.tar.gz</filename>. Instead,
+include the file in the <filename>debian</filename> directory in
+<command>uuencode</command>d (or similar) form <footnote><para> The file should
+have a name that makes it clear which binary file it encodes. Usually, some
+postfix indicating the encoding should be appended to the original filename.
+Note that you don't need to depend on <systemitem
+role="package">sharutils</systemitem> to get the <command>uudecode</command>
+program if you use <command>perl</command>'s <literal>pack</literal> function.
+The code could look like
+</para>
+&example-uu;
+</footnote>. The file would then be
+decoded and copied to its place during the build process. Thus the change will
+be visible quite easy.
+</para>
+<para>
+Some packages use <command>dbs</command> to manage patches to their upstream
+source, and always create a new <literal>orig.tar.gz</literal> file that
+contains the real <literal>orig.tar.gz</literal> in its toplevel directory.
+This is questionable with respect to the preference for pristine source. On
+the other hand, it is easy to modify or add binary files in this case: Just put
+them into the newly created <literal>orig.tar.gz</literal> file, besides the
+real one, and copy them to the right place during the build process.
+</para>
+</section>
+
+</section>
+
+<section id="bpp-dbg">
+<title>Best practices for debug packages</title>
+<para>
+A debug package is a package with a name ending in -dbg, that contains
+additional information that gdb can use. Since Debian binaries are stripped by
+default, debugging information, including function names and line numbers, is
+otherwise not available when running gdb on Debian binaries. Debug packages
+allow users who need this additional debugging information to install it,
+without bloating a regular system with the information.
+</para>
+<para>
+It is up to a package's maintainer whether to create a debug package or not.
+Maintainers are encouraged to create debug packages for library packages, since
+this can aid in debugging many programs linked to a library. In general, debug
+packages do not need to be added for all programs; doing so would bloat the
+archive. But if a maintainer finds that users often need a debugging version
+of a program, it can be worthwhile to make a debug package for it. Programs
+that are core infrastructure, such as apache and the X server are also good
+candidates for debug packages.
+</para>
+<para>
+Some debug packages may contain an entire special debugging build of a library
+or other binary, but most of them can save space and build time by instead
+containing separated debugging symbols that gdb can find and load on the fly
+when debugging a program or library. The convention in Debian is to keep these
+symbols in <filename>/usr/lib/debug/path</filename>, where
+<emphasis>path</emphasis> is the path to the executable or library. For
+example, debugging symbols for <filename>/usr/bin/foo</filename> go in
+<filename>/usr/lib/debug/usr/bin/foo</filename>, and debugging symbols for
+<filename>/usr/lib/libfoo.so.1</filename> go in
+<filename>/usr/lib/debug/usr/lib/libfoo.so.1</filename>.
+</para>
+<para>
+The debugging symbols can be extracted from an object file using objcopy
+--only-keep-debug. Then the object file can be stripped, and objcopy
+--add-gnu-debuglink used to specify the path to the debugging symbol file.
+<citerefentry> <refentrytitle>objcopy</refentrytitle> <manvolnum>1</manvolnum>
+</citerefentry> explains in detail how this works.
+</para>
+<para>
+The dh_strip command in debhelper supports creating debug packages, and can
+take care of using objcopy to separate out the debugging symbols for you. If
+your package uses debhelper, all you need to do is call dh_strip
+--dbg-package=libfoo-dbg, and add an entry to debian/control for the debug
+package.
+</para>
+<para>
+Note that the Debian package should depend on the package that it provides
+debugging symbols for, and this dependency should be versioned. For example:
+</para>
+<screen>
+Depends: libfoo-dbg (= ${binary:Version})
+</screen>
+</section>
+
+</section>
+
+</chapter>
+
--- /dev/null
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
+ "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
+ <!ENTITY % commondata SYSTEM "common.ent" > %commondata;
+]>
+<chapter id="beyond-pkging">
+<title>Beyond Packaging</title>
+<para>
+Debian is about a lot more than just packaging software and maintaining those
+packages. This chapter contains information about ways, often really critical
+ways, to contribute to Debian beyond simply creating and maintaining packages.
+</para>
+<para>
+As a volunteer organization, Debian relies on the discretion of its members in
+choosing what they want to work on and in choosing the most critical thing to
+spend their time on.
+</para>
+<section id="submit-bug">
+<title>Bug reporting</title>
+<para>
+We encourage you to file bugs as you find them in Debian packages. In fact,
+Debian developers are often the first line testers. Finding and reporting bugs
+in other developers' packages improves the quality of Debian.
+</para>
+<para>
+Read the <ulink url="&url-bts-report;">instructions for
+reporting bugs</ulink> in the Debian <ulink
+url="&url-bts;">bug tracking system</ulink>.
+</para>
+<para>
+Try to submit the bug from a normal user account at which you are likely to
+receive mail, so that people can reach you if they need further information
+about the bug. Do not submit bugs as root.
+</para>
+<para>
+You can use a tool like <citerefentry> <refentrytitle>reportbug</refentrytitle>
+<manvolnum>1</manvolnum> </citerefentry> to submit bugs. It can automate and
+generally ease the process.
+</para>
+<para>
+Make sure the bug is not already filed against a package. Each package has a
+bug list easily reachable at
+<literal>http://&bugs-host;/<replaceable>packagename</replaceable></literal>
+Utilities like <citerefentry> <refentrytitle>querybts</refentrytitle>
+<manvolnum>1</manvolnum> </citerefentry> can also provide you with this
+information (and <command>reportbug</command> will usually invoke
+<command>querybts</command> before sending, too).
+</para>
+<para>
+Try to direct your bugs to the proper location. When for example your bug is
+about a package which overwrites files from another package, check the bug
+lists for <emphasis>both</emphasis> of those packages in order to avoid filing
+duplicate bug reports.
+</para>
+<para>
+For extra credit, you can go through other packages, merging bugs which are
+reported more than once, or tagging bugs `fixed' when they have already been
+fixed. Note that when you are neither the bug submitter nor the package
+maintainer, you should not actually close the bug (unless you secure permission
+from the maintainer).
+</para>
+<para>
+From time to time you may want to check what has been going on with the bug
+reports that you submitted. Take this opportunity to close those that you
+can't reproduce anymore. To find out all the bugs you submitted, you just have
+to visit
+<literal>http://&bugs-host;/from:<replaceable><your-email-addr></replaceable></literal>.
+</para>
+<section id="submit-many-bugs">
+<title>Reporting lots of bugs at once (mass bug filing)</title>
+<para>
+Reporting a great number of bugs for the same problem on a great number of
+different packages — i.e., more than 10 — is a deprecated practice. Take
+all possible steps to avoid submitting bulk bugs at all. For instance, if
+checking for the problem can be automated, add a new check to <systemitem
+role="package">lintian</systemitem> so that an error or warning is emitted.
+</para>
+<para>
+If you report more than 10 bugs on the same topic at once, it is recommended
+that you send a message to &email-debian-devel; describing
+your intention before submitting the report, and mentioning the fact in the
+subject of your mail. This will allow other developers to verify that the bug
+is a real problem. In addition, it will help prevent a situation in which
+several maintainers start filing the same bug report simultaneously.
+</para>
+<para>
+Please use the programms <command>dd-list</command> and if appropriate
+<command>whodepends</command> (from the package devscripts) to generate a list
+of all affected packages, and include the output in your mail to
+&email-debian-devel;.
+</para>
+<para>
+Note that when sending lots of bugs on the same subject, you should send the
+bug report to <email>maintonly@&bugs-host;</email> so that the bug report
+is not forwarded to the bug distribution mailing list.
+</para>
+</section>
+
+</section>
+
+<section id="qa-effort">
+<title>Quality Assurance effort</title>
+<section id="qa-daily-work">
+<title>Daily work</title>
+<para>
+Even though there is a dedicated group of people for Quality Assurance, QA
+duties are not reserved solely for them. You can participate in this effort by
+keeping your packages as bug-free as possible, and as lintian-clean (see <xref
+linkend="lintian"/> ) as possible. If you do not find that possible, then you
+should consider orphaning some of your packages (see <xref
+linkend="orphaning"/> ). Alternatively, you may ask the help of other people
+in order to catch up with the backlog of bugs that you have (you can ask for
+help on &email-debian-qa; or
+&email-debian-devel;). At the same time, you can look for
+co-maintainers (see <xref linkend="collaborative-maint"/> ).
+</para>
+</section>
+
+<section id="qa-bsp">
+<title>Bug squashing parties</title>
+<para>
+From time to time the QA group organizes bug squashing parties to get rid of as
+many problems as possible. They are announced on
+&email-debian-devel-announce; and the announcement explains
+which area will be the focus of the party: usually they focus on release
+critical bugs but it may happen that they decide to help finish a major upgrade
+(like a new perl version which requires recompilation of all the binary
+modules).
+</para>
+<para>
+The rules for non-maintainer uploads differ during the parties because the
+announcement of the party is considered prior notice for NMU. If you have
+packages that may be affected by the party (because they have release critical
+bugs for example), you should send an update to each of the corresponding bug
+to explain their current status and what you expect from the party. If you
+don't want an NMU, or if you're only interested in a patch, or if you will deal
+yourself with the bug, please explain that in the BTS.
+</para>
+<para>
+People participating in the party have special rules for NMU, they can NMU
+without prior notice if they upload their NMU to DELAYED/3-day at least. All
+other NMU rules apply as usually; they should send the patch of the NMU to the
+BTS (to one of the open bugs fixed by the NMU, or to a new bug, tagged fixed).
+They should also respect any particular wishes of the maintainer.
+</para>
+<para>
+If you don't feel confident about doing an NMU, just send a patch to the BTS.
+It's far better than a broken NMU.
+</para>
+</section>
+
+</section>
+
+<section id="contacting-maintainers">
+<title>Contacting other maintainers</title>
+<para>
+During your lifetime within Debian, you will have to contact other maintainers
+for various reasons. You may want to discuss a new way of cooperating between
+a set of related packages, or you may simply remind someone that a new upstream
+version is available and that you need it.
+</para>
+<para>
+Looking up the email address of the maintainer for the package can be
+distracting. Fortunately, there is a simple email alias,
+<literal><package>@&packages-host;</literal>, which provides a way to
+email the maintainer, whatever their individual email address (or addresses)
+may be. Replace <literal><package></literal> with the name of a source
+or a binary package.
+</para>
+<para>
+You may also be interested in contacting the persons who are subscribed to a
+given source package via <xref linkend="pkg-tracking-system"/> . You can do so
+by using the <literal><package>@&pts-host;</literal> email
+address.
+</para>
+<!-- FIXME: moo@packages.d.o is easily confused with moo@packages.qa.d.o -->
+</section>
+
+<section id="mia-qa">
+<title>Dealing with inactive and/or unreachable maintainers</title>
+<para>
+If you notice that a package is lacking maintenance, you should make sure that
+the maintainer is active and will continue to work on their packages. It is
+possible that they are not active any more, but haven't registered out of the
+system, so to speak. On the other hand, it is also possible that they just
+need a reminder.
+</para>
+<para>
+There is a simple system (the MIA database) in which information about
+maintainers who are deemed Missing In Action is recorded. When a member of the
+QA group contacts an inactive maintainer or finds more information about one,
+this is recorded in the MIA database. This system is available in
+/org/qa.debian.org/mia on the host qa.debian.org, and can be queried with a
+tool known as <command>mia-query</command>. Use <command>mia-query --help</command>
+to see how to query the database. If you find that no information has been
+recorded about an inactive maintainer yet, or that you can add more
+information, you should generally proceed as follows.
+</para>
+<para>
+The first step is to politely contact the maintainer, and wait a reasonable
+time for a response. It is quite hard to define reasonable time, but it is
+important to take into account that real life is sometimes very hectic. One
+way to handle this would be to send a reminder after two weeks.
+</para>
+<para>
+If the maintainer doesn't reply within four weeks (a month), one can assume
+that a response will probably not happen. If that happens, you should
+investigate further, and try to gather as much useful information about the
+maintainer in question as possible. This includes:
+</para>
+<itemizedlist>
+<listitem>
+<para>
+The echelon information available through the <ulink
+url="&url-debian-db;">developers' LDAP database</ulink>, which indicates
+when the developer last posted to a Debian mailing list. (This includes
+uploads via debian-*-changes lists.) Also, remember to check whether the
+maintainer is marked as on vacation in the database.
+</para>
+</listitem>
+<listitem>
+<para>
+The number of packages this maintainer is responsible for, and the condition of
+those packages. In particular, are there any RC bugs that have been open for
+ages? Furthermore, how many bugs are there in general? Another important
+piece of information is whether the packages have been NMUed, and if so, by
+whom.
+</para>
+</listitem>
+<listitem>
+<para>
+Is there any activity of the maintainer outside of Debian? For example, they
+might have posted something recently to non-Debian mailing lists or news
+groups.
+</para>
+</listitem>
+</itemizedlist>
+<para>
+A bit of a problem are packages which were sponsored — the maintainer is not
+an official Debian developer. The echelon information is not available for
+sponsored people, for example, so you need to find and contact the Debian
+developer who has actually uploaded the package. Given that they signed the
+package, they're responsible for the upload anyhow, and are likely to know what
+happened to the person they sponsored.
+</para>
+<para>
+It is also allowed to post a query to &email-debian-devel;,
+asking if anyone is aware of the whereabouts of the missing maintainer. Please
+Cc: the person in question.
+</para>
+<para>
+Once you have gathered all of this, you can contact
+&email-mia;. People on this alias will use the
+information you provide in order to decide how to proceed. For example, they
+might orphan one or all of the packages of the maintainer. If a package has
+been NMUed, they might prefer to contact the NMUer before orphaning the package
+— perhaps the person who has done the NMU is interested in the package.
+</para>
+<para>
+One last word: please remember to be polite. We are all volunteers and cannot
+dedicate all of our time to Debian. Also, you are not aware of the
+circumstances of the person who is involved. Perhaps they might be seriously
+ill or might even have died — you do not know who may be on the receiving
+side. Imagine how a relative will feel if they read the e-mail of the deceased
+and find a very impolite, angry and accusing message!
+</para>
+<para>
+On the other hand, although we are volunteers, we do have a responsibility. So
+you can stress the importance of the greater good — if a maintainer does not
+have the time or interest anymore, they should let go and give the package to
+someone with more time.
+</para>
+<para>
+If you are interested in working in the MIA team, please have a look at the
+README file in /org/qa.debian.org/mia on qa.debian.org where the technical
+details and the MIA procedures are documented and contact
+&email-mia;.
+</para>
+</section>
+
+<section id="newmaint">
+<title>Interacting with prospective Debian developers</title>
+<para>
+Debian's success depends on its ability to attract and retain new and talented
+volunteers. If you are an experienced developer, we recommend that you get
+involved with the process of bringing in new developers. This section
+describes how to help new prospective developers.
+</para>
+<section id="sponsoring">
+<title>Sponsoring packages</title>
+<para>
+Sponsoring a package means uploading a package for a maintainer who is not able
+to do it on their own, a new maintainer applicant. Sponsoring a package also
+means accepting responsibility for it.
+</para>
+<!-- FIXME: service down
+<para>
+If you wish to volunteer as a sponsor, you can sign up at <ulink
+url="http://www.internatif.org/bortzmeyer/debian/sponsor/">http://www.internatif.org/bortzmeyer/debian/sponsor/</ulink>.
+</para>
+-->
+<para>
+New maintainers usually have certain difficulties creating Debian packages —
+this is quite understandable. That is why the sponsor is there, to check the
+package and verify that it is good enough for inclusion in Debian. (Note that
+if the sponsored package is new, the ftpmasters will also have to inspect it
+before letting it in.)
+</para>
+<para>
+Sponsoring merely by signing the upload or just recompiling is <emphasis
+role="strong">definitely not recommended</emphasis>. You need to build the
+source package just like you would build a package of your own. Remember that
+it doesn't matter that you left the prospective developer's name both in the
+changelog and the control file, the upload can still be traced to you.
+</para>
+<para>
+If you are an application manager for a prospective developer, you can also be
+their sponsor. That way you can also verify how the applicant is handling the
+'Tasks and Skills' part of their application.
+</para>
+</section>
+
+<section id="s7.5.2">
+<title>Managing sponsored packages</title>
+<para>
+By uploading a sponsored package to Debian, you are certifying that the package
+meets minimum Debian standards. That implies that you must build and test the
+package on your own system before uploading.
+</para>
+<para>
+You cannot simply upload a binary <filename>.deb</filename> from the sponsoree.
+In theory, you should only ask for the diff file and the location of the
+original source tarball, and then you should download the source and apply the
+diff yourself. In practice, you may want to use the source package built by
+your sponsoree. In that case, you have to check that they haven't altered the
+upstream files in the <filename>.orig.tar.gz</filename> file that they're
+providing.
+</para>
+<para>
+Do not be afraid to write the sponsoree back and point out changes that need to
+be made. It often takes several rounds of back-and-forth email before the
+package is in acceptable shape. Being a sponsor means being a mentor.
+</para>
+<para>
+Once the package meets Debian standards, build and sign it with
+</para>
+<screen>
+dpkg-buildpackage -k<replaceable>KEY-ID</replaceable>
+</screen>
+<para>
+before uploading it to the incoming directory. Of course, you can also use any
+part of your <replaceable>KEY-ID</replaceable>, as long as it's unique in your
+secret keyring.
+</para>
+<para>
+The Maintainer field of the <filename>control</filename> file and the
+<filename>changelog</filename> should list the person who did the packaging,
+i.e., the sponsoree. The sponsoree will therefore get all the BTS mail about
+the package.
+</para>
+<para>
+If you prefer to leave a more evident trace of your sponsorship job, you can
+add a line stating it in the most recent changelog entry.
+</para>
+<para>
+You are encouraged to keep tabs on the package you sponsor using <xref
+linkend="pkg-tracking-system"/> .
+</para>
+</section>
+
+<section id="s7.5.3">
+<title>Advocating new developers</title>
+<para>
+See the page about <ulink
+url="&url-newmaint-advocate;">advocating a prospective
+developer</ulink> at the Debian web site.
+</para>
+</section>
+
+<section id="s7.5.4">
+<title>Handling new maintainer applications</title>
+<para>
+Please see <ulink url="&url-newmaint-amchecklist;">Checklist
+for Application Managers</ulink> at the Debian web site.
+</para>
+</section>
+
+</section>
+
+</chapter>
+
<!-- standard information -->
<!ENTITY fsf-addr "Free Software Foundation, Inc.,
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA">
-<!ENTITY file-GPL "<file>/usr/share/common-licenses/GPL</file>">
+<!ENTITY file-GPL "<filename>/usr/share/common-licenses/GPL</filename>">
<!ENTITY debian-formal "Debian GNU/Linux">
<!--
-->
<!ENTITY www-debian-org "www.debian.org">
<!ENTITY ftp-debian-org "ftp.debian.org">
-<!ENTITY ftp-host "&ftp-debian-org;">
-<!ENTITY www-host "&www-debian-org;">
<!ENTITY lists-host "lists.debian.org">
<!ENTITY archive-host "archive.debian.org">
<!ENTITY keyserver-host "keyring.debian.org">
<!ENTITY pts-host "packages.qa.debian.org">
<!ENTITY ftp-master-host "ftp-master.debian.org">
<!ENTITY ftp-master-mirror "merkel.debian.org">
-<!ENTITY non-us-host "non-us.debian.org">
-<!ENTITY upload-queue "<ftppath>/pub/UploadQueue/</ftppath>">
+<!ENTITY upload-queue "/pub/UploadQueue/">
<!ENTITY url-debian-policy "http://&www-debian-org;/doc/debian-policy/">
<!ENTITY url-perl-policy "http://&www-debian-org;/doc/packaging-manuals/perl-policy/">
<!ENTITY url-constitution "http://&www-debian-org;/devel/constitution">
<!ENTITY url-dfsg "&url-social-contract;#guidelines">
<!ENTITY url-debian-lists "http://&www-debian-org;/MailingLists/">
-<!ENTITY url-debian-lists-txt "http://&ftp-debian-org;/debian/doc/mailing-lists.txt">
-<!ENTITY url-debian-lists-subscribe "http://&www-debian-org;/MailingLists/subscribe">
-<!ENTITY url-debian-lists-new "http://&www-debian-org;/MailingLists/HOWTO_start_list">
-<!ENTITY url-lists-archives "http://&lists-host;/">
+<!ENTITY url-debian-lists-new "&url-debian-lists;HOWTO_start_list">
<!ENTITY url-bts "http://&www-debian-org;/Bugs/">
<!ENTITY url-bts-report "&url-bts;Reporting">
<!ENTITY url-bts-devel "&url-bts;Developer">
<!ENTITY url-bts-control "&url-bts;server-control">
<!ENTITY url-debian-mirrors "http://&www-debian-org;/mirror/">
-<!ENTITY url-debian-mirroring "&url-debian-mirrors;">
<!ENTITY url-debian-ports "http://&www-debian-org;/ports/">
<!ENTITY url-debian-port-lists "http://&lists-host;/ports.html">
<!ENTITY url-wnpp "http://&www-debian-org;/devel/wnpp/">
<!ENTITY url-buildd "http://buildd.debian.org/">
<!ENTITY url-lintian "http://lintian.debian.org/">
<!ENTITY url-debian-qa "http://qa.debian.org/">
-<!ENTITY url-debian-qa-orphaned "http://qa.debian.org/orphaned.html">
+<!ENTITY url-debian-qa-orphaned "&url-debian-qa;orphaned.html">
<!ENTITY url-debian-db "https://db.debian.org/">
-<!ENTITY url-debian-db-login "https://db.debian.org/login.html">
+<!ENTITY url-debian-db-login "&url-debian-db;login.html">
<!ENTITY url-debian-db-mail-gw "http://db.debian.org/doc-mail.html">
<!ENTITY url-debian-db-doc "http://db.debian.org/doc-general.html">
-<!ENTITY url-newmaint "http://&www-debian-org;/devel/join/newmaint">
-<!ENTITY url-newmaint-checklist "http://&www-debian-org;/devel/join/nm-checklist">
+<!ENTITY url-newmaint "&url-devel-docs;join/newmaint">
<!ENTITY url-newmaint-db "http://nm.debian.org/">
-<!ENTITY url-newmaint-advocate "http://&www-debian-org;/devel/join/nm-advocate">
-<!ENTITY url-newmaint-amchecklist "http://&www-debian-org;/devel/join/nm-amchecklist">
+<!ENTITY url-newmaint-advocate "&url-devel-docs;join/nm-advocate">
+<!ENTITY url-newmaint-amchecklist "&url-devel-docs;join/nm-amchecklist">
<!ENTITY url-newmaint-apply "http://nm.debian.org/newnm.php">
<!ENTITY url-newmaint-id "http://&www-debian-org;/devel/join/nm-step2">
<!ENTITY url-newmaint-guide "http://&www-debian-org;/doc/maint-guide/">
<!ENTITY url-dcg "http://people.debian.org/~enrico/dcg/">
<!ENTITY url-rt "https://rt.debian.org/">
-<!ENTITY url-debian-keyring "http://&ftp-debian-org;/debian/doc/debian-keyring.tar.gz">
-<!ENTITY url-readme-non-us "http://&ftp-debian-org;/debian/README.non-US">
<!ENTITY url-incoming "http://incoming.debian.org/">
<!ENTITY url-testing-maint "http://www.debian.org/devel/testing">
<!-- deprecated -->
-<!ENTITY url-testing-faq "&url-testing-maint;">
-
-<!ENTITY us-upload-dir "<file>/org/ftp.debian.org/incoming/</file>">
-<!ENTITY non-us-upload-dir "<file>/org/non-us.debian.org/incoming/</file>">
-<!ENTITY url-chiark-readme "ftp://ftp.chiark.greenend.org.uk/pub/debian/private/project/README.how-to-upload">
-<!ENTITY url-upload-erlangen "ftp://ftp.uni-erlangen.de/pub/Linux/debian/UploadQueue/">
-<!ENTITY url-upload-samosa "ftp://samosa.debian.org/pub/UploadQueue/">
-<!ENTITY url-upload-jp "ftp://master.debian.or.jp/pub/Incoming/upload/">
<!ENTITY url-mentors "http://people.debian.org/~mpalmer/debian-mentors_FAQ.html">
-<!ENTITY url-sponsors "http://www.internatif.org/bortzmeyer/debian/sponsor/">
<!ENTITY url-rules-files "http://arch.debian.org/arch/private/srivasta/">
-<!ENTITY url-debconf-l10n-help "http://&www-debian-org;/intl/l10n/templates/hints">
-
<!ENTITY url-dmup "http://&www-debian-org;/devel/dmup">
<!ENTITY url-worldmap "http://&www-debian-org;/devel/developers.loc">
<!ENTITY url-alioth-wiki "http://wiki.debian.org/Alioth">
<!ENTITY url-alioth-faq "http://wiki.debian.org/Alioth/FAQ">
-
<!--
URLs, non-debian
-->
<!ENTITY url-gpl "http://www.gnu.org/copyleft/gpl.html">
<!ENTITY url-pgp-faq "http://www.cam.ac.uk.pgp.net/pgpnet/pgp-faq/">
<!ENTITY url-rfc2440 "http://www.rfc-editor.org/rfc/rfc2440.txt">
-<!ENTITY url-u.s.-export "http://www.bxa.doc.gov/Encryption/PubAvailEncSourceCodeNofify.html">
-<!ENTITY url-notification-of-export "http://www.bxa.doc.gov/Encryption/">
<!ENTITY url-openprojects "http://www.freenode.net/">
<!ENTITY url-oftc "http://www.oftc.net/oftc/">
<!-- Debian email addresses -->
<!ENTITY email-listmaster "<email>listmaster@&lists-host;</email>">
-<!ENTITY email-debian-announce "<email>debian-announce@&lists-host;</email>">
<!ENTITY email-devel-ref "<email>developers-reference@&packages-host;</email>">
<!ENTITY email-debian-changes "<email>debian-changes@lists.debian.org</email>">
<!ENTITY email-debian-devel "<email>debian-devel@&lists-host;</email>">
<!ENTITY email-debian-private "<email>debian-private@&lists-host;</email>">
<!ENTITY email-debian-project "<email>debian-project@&lists-host;</email>">
<!ENTITY email-debian-policy "<email>debian-policy@&lists-host;</email>">
-<!ENTITY email-debian-user "<email>debian-user@&lists-host;</email>">
<!ENTITY orphan-address "<packages@qa.debian.org>">
<!ENTITY email-debian-qa "<email>debian-qa@&lists-host;</email>">
<!ENTITY email-debian-release "<email>debian-release@&lists-host;</email>">
<!ENTITY email-debian-l10n-english "<email>debian-l10n-english@&lists-host;</email>">
<!ENTITY email-mia "<email>mia@qa.debian.org</email>">
-<!ENTITY email-new-maintainer "<email>new-maintainer@debian.org</email>">
-<!ENTITY email-debian-keyring "<email>keyring-maint@debian.org</email>">
-<!ENTITY email-debian-admin "<email>debian-admin@debian.org</email>">
+<!ENTITY email-rt-dsa "<email>admin@rt.debian.org</email>">
<!ENTITY email-ftpmaster "<email>ftpmaster@debian.org</email>">
<!ENTITY email-override "<email>override-change@debian.org</email>">
-<!ENTITY email-wnpp "<email>wnpp@debian.org</email>">
<!ENTITY email-bts-control "<email>control@&bugs-host;</email>">
<!ENTITY email-security-team "<email>team@security.debian.org</email>">
<!-- misc Debian info -->
-<!ENTITY file-mail-lists "<file>/usr/share/doc/debian/mailing-lists.txt</file>">
-<!ENTITY file-bts-docs "<file>/usr/share/doc/debian/bug-*</file>">
-<!ENTITY file-python-policy "<file>/usr/share/doc/python/python-policy.txt.gz</file>">
-<!ENTITY file-ocaml-policy "<file>/usr/share/doc/ocaml/ocaml_packaging_policy.gz</file>">
-<!ENTITY file-lisp-controller "<file>/usr/share/doc/common-lisp-controller/README.packaging</file>">
+<!ENTITY file-bts-docs "<filename>/usr/share/doc/debian/bug-*</filename>">
+<!ENTITY file-python-policy "<filename>/usr/share/doc/python/python-policy.txt.gz</filename>">
+<!ENTITY file-ocaml-policy "<filename>/usr/share/doc/ocaml/ocaml_packaging_policy.gz</filename>">
+<!ENTITY file-lisp-controller "<filename>/usr/share/doc/common-lisp-controller/README.packaging</filename>">
<!ENTITY file-debian-private-archive "~debian/archive/debian-private/">
-<!ENTITY file-bpp-autotools "<file>/usr/share/doc/autotools-dev/README.Debian.gz</file>">
-
-<!ENTITY cron-bug-report '0 17 * * fri echo "index maint <var>address</var>" | mail request@&bugs-host;'>
+<!ENTITY file-bpp-autotools "<filename>/usr/share/doc/autotools-dev/README.Debian.gz</filename>">
-<!ENTITY control-file-fields "<list compact>
- <item><tt>Format</tt>
- <item><tt>Date</tt>
- <item><tt>Source</tt>
- <item><tt>Binary</tt>
- <item><tt>Architecture</tt>
- <item><tt>Version</tt>
- <item><tt>Distribution</tt>
- <item><tt>Urgency</tt>
- <item><tt>Maintainer</tt>
- <item><tt>Description</tt>
- <item><tt>Changes</tt>
- <item><tt>Files</tt>
- </list>">
+<!ENTITY cron-bug-report '0 17 * * fri echo "index maint <replaceable>address</replaceable>" | mail request@&bugs-host;'>
<!--
misc, non-debian
-->
-<!ENTITY pgp-keyserv "<tt>subkeys.pgp.net</tt>">
+<!ENTITY pgp-keyserv "<literal>subkeys.pgp.net</literal>">
-<!ENTITY sample-dist-dirtree "<example>
-dists/stable/main/
+<!ENTITY sample-dist-dirtree "<screen>dists/stable/main/
dists/stable/main/binary-i386/
dists/stable/main/binary-m68k/
dists/stable/main/binary-alpha/
...
pool/non-free/n/
pool/non-free/n/netscape/
- ...
-</example>">
+ ...</screen>">
+
+<!ENTITY example-uu "<programlisting>uuencode-file:
+ perl -ne 'print(pack "u", $$_);' $(file) > $(file).uuencoded
+
+uudecode-file:
+ perl -ne 'print(unpack "u", $$_);' $(file).uuencoded > $(file)</programlisting>">
-<!ENTITY example-pathfind '<example>pathfind() {
+<!ENTITY example-pathfind '<programlisting>pathfind() {
OLDIFS="$IFS"
IFS=:
for p in $PATH; do
done
IFS="$OLDIFS"
return 1
-}</example>'>
+}</programlisting>'>
+++ /dev/null
-*.debhelper
-*.substvars
-developers-reference
-developers-reference-fr
-developers-reference-ja
-files
[ Andreas Barth ]
* Packaging changes:
- - bump standards-version to 3.7.2 (no change)
+ - bump standards-version to 3.7.3 (no change)
- fix debian/copyright
- move debhelper to Build-Depends.
- add pdf for French version.
* Repacking source packages need to be documented in copyright.
Thanks, Russ Allbery. Closes: #413320
* Better describe version of debian native packages NMUs. Closes: #405818
+ * Source, HTML and text are now encoded in UTF-8. Thanks, Jörg Sommer.
+ Closes: #373816
+ * Source is now DocBook XML instead of debiandoc. Closes: #374220
[ Raphael Hertzog ]
* Add a link to enrico's excellent Debian Community Guidelines.
* Recommend the use of DSA's request tracker instead of mailing them.
- * Remove reference to #debian-sf which doesn't exist anymore.
+ * Remove reference to #debian-sf, #debian-bsd which don't exist anymore. Put
+ a reference to #debian-dpkg instead.
* Remove all stuff concerning non-US.
- * Put myself back in Uploaders.
- * Generaly wrap lines longer than 78 characters. Closes: #278267
- Not done for translations. I leave that up to translators if they want to
- do it.
- * Update information concerning the Package Tracking System.
* Update information concerning Alioth.
+ * Update information concerning the Package Tracking System.
* Mention Alioth as the main resource for VCS repositories and deprecate
cvs.debian.org.
* Remove XS- prefix for Vcs-* fields since dpkg now supports them.
- * Document the Homepage field. Thanks, Christian Perrier. Closes: #445642
- * Update URL of Alioth related wiki pages.
+ * Document the Homepage field. Thanks, Christian Perrier. Closes:
+ #445642
+ * Add Vcs-Svn and Vcs-Browser fields pointing to the new SVN
+ repository.
- -- Raphael Hertzog <hertzog@debian.org> Sat, 04 Aug 2007 17:51:06 +0200
+ -- W. Martin Borgert <debacle@debian.org> Thu, 28 Feb 2008 10:16:40 +0000
developers-reference (3.3.8) unstable; urgency=low
Source: developers-reference
Section: doc
Priority: optional
-Maintainer: Andreas Barth <aba@not.so.argh.org>
-Standards-Version: 3.7.2
-Build-Depends-Indep: debiandoc-sgml (>= 1.1.76), tetex-bin, tetex-extra
+Maintainer: Debian Documentation Project <debian-doc@lists.debian.org>
+Uploaders: Andreas Barth <aba@not.so.argh.org>
+Standards-Version: 3.7.3
+Build-Depends-Indep: docbook-xsl (>= 1.71.0), dblatex (>= 0.2), xsltproc, libxml2-utils, po4a, w3m
Build-Depends: debhelper (>= 4.1.32)
+Vcs-Svn: svn://svn.debian.org/ddp/developers-reference/trunk
+Vcs-Browser: http://svn.debian.org/wsvn/ddp/developers-reference/trunk?op=log
Package: developers-reference
Architecture: all
Section: Debian
Format: HTML
-Index: /usr/share/doc/developers-reference-fr/index.fr.html
+Index: /usr/share/doc/developers-reference-fr/index.html
Files: /usr/share/doc/developers-reference-fr/*.html
Format: PDF
-Files: /usr/share/doc/developers-reference-fr/developers-reference.fr.pdf
+Files: /usr/share/doc/developers-reference-fr/developers-reference.pdf
Section: Debian
Format: HTML
-Index: /usr/share/doc/developers-reference-ja/index.ja.html
+Index: /usr/share/doc/developers-reference-ja/index.html
Files: /usr/share/doc/developers-reference-ja/*.html
Files: /usr/share/doc/developers-reference/developers-reference.txt.gz
Format: HTML
-Index: /usr/share/doc/developers-reference/index.en.html
+Index: /usr/share/doc/developers-reference/index.html
Files: /usr/share/doc/developers-reference/*.html
Format: PDF
docbasedir := $(prefix)$(docbaserel)
# list of language packages, in the form pkg-LANG; must jibe
-# with debian/control, see also DATE_uc(LANG) below
+# with debian/control
langs := fr
# tool abstraction
DEB_VERSION := $(shell awk -F '[()]' '/^$(package)/{ print $$2; exit }' debian/changelog)
DEB_DATE := $(shell dpkg-parsechangelog 2>/dev/null | sed -n 's/^Date: *//p')
# pretty-print the date; I wish this was dynamic like the top-level makefile but oh well
-DATE_EN := $(shell LC_ALL=C date --date="$(DEB_DATE)" '+%d %B, %Y')
-DATE_FR := $(shell LC_ALL=fr_FR date --date="$(DEB_DATE)" '+%d %B %Y')
-DATE_JA := $(shell LC_ALL=ja_JP date --date="$(DEB_DATE)" '+%x')
+PUBDATE := $(shell LC_ALL=C date --date="$(DEB_DATE)" -I)
# debhelper verbose mode
#export DH_VERBOSE=1
-version.ent: debian/changelog
- :> version.ent
- echo "<!ENTITY version \"$(DEB_VERSION)\">" >> version.ent
- echo "<!ENTITY date-en \"$(DATE_EN)\">" >> version.ent
- echo "<!ENTITY date-fr \"$(DATE_FR)\">" >> version.ent
- echo "<!ENTITY date-ja \"$(DATE_JA)\">" >> version.ent
-
build:
$(checkdir)
- $(MAKE)
+ rm -f version.ent
+ $(MAKE) VERSION=$(DEB_VERSION) PUBDATE=$(PUBDATE) LANGS="$(langs)"
touch build
.PHONY: clean
$(checkroot)
dh_clean -k
- dh_installdocs -p$(package) README-contrib developers-reference.txt \
- developers-reference.pdf developers-reference.html/*
+ dh_installdocs -p$(package) README-contrib \
+ *.html \
+ developers-reference.txt \
+ developers-reference.pdf
set -e; for lang in $(langs); do \
- dh_installdocs -p$(package)-$$lang README-contrib developers-reference.$$lang.txt \
- developers-reference.$$lang.pdf developers-reference.$$lang.html/* ;\
+ dh_installdocs -p$(package)-$$lang README-contrib \
+ $$lang/*.html \
+ $$lang/developers-reference.txt \
+ $$lang/developers-reference.pdf; \
done
define checkdir
test -f debian/rules
- test -f developers-reference.sgml
+ test -f index.dbk
endef
# Below here is fairly generic really
.PHONY: binary
binary: binary-indep binary-arch
-
-#Local variables:
-#mode: makefile
-#End:
--- /dev/null
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
+ "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
+ <!ENTITY % commondata SYSTEM "common.ent" > %commondata;
+]>
+<chapter id="developer-duties">
+<title>Debian Developer's Duties</title>
+<section id="user-maint">
+<title>Maintaining your Debian information</title>
+<para>
+There's a LDAP database containing information about Debian developers at
+<ulink url="&url-debian-db;"></ulink>. You should enter your
+information there and update it as it changes. Most notably, make sure that
+the address where your debian.org email gets forwarded to is always up to date,
+as well as the address where you get your debian-private subscription if you
+choose to subscribe there.
+</para>
+<para>
+For more information about the database, please see <xref linkend="devel-db"/>
+.
+</para>
+</section>
+
+<section id="key-maint">
+<title>Maintaining your public key</title>
+<para>
+Be very careful with your private keys. Do not place them on any public
+servers or multiuser machines, such as the Debian servers (see <xref
+linkend="server-machines"/> ). Back your keys up; keep a copy offline. Read
+the documentation that comes with your software; read the <ulink
+url="&url-pgp-faq;">PGP FAQ</ulink>.
+</para>
+<para>
+You need to ensure not only that your key is secure against being stolen, but
+also that it is secure against being lost. Generate and make a copy (best also
+in paper form) of your revocation certificate; this is needed if your key is
+lost.
+</para>
+<para>
+If you add signatures to your public key, or add user identities, you can
+update the Debian key ring by sending your key to the key server at
+<literal>&keyserver-host;</literal>.
+</para>
+<para>
+If you need to add a completely new key or remove an old key, you need to get
+the new key signed by another developer. If the old key is compromised or
+invalid, you also have to add the revocation certificate. If there is no real
+reason for a new key, the Keyring Maintainers might reject the new key.
+Details can be found at <ulink
+url="http://&keyserver-host;/replacing_keys.html"></ulink>.
+</para>
+<para>
+The same key extraction routines discussed in <xref linkend="registering"/>
+apply.
+</para>
+<para>
+You can find a more in-depth discussion of Debian key maintenance in the
+documentation of the <systemitem role="package">debian-keyring</systemitem>
+package.
+</para>
+</section>
+
+<section id="voting">
+<title>Voting</title>
+<para>
+Even though Debian isn't really a democracy, we use a democratic process to
+elect our leaders and to approve general resolutions. These procedures are
+defined by the <ulink url="&url-constitution;">Debian
+Constitution</ulink>.
+</para>
+<para>
+Other than the yearly leader election, votes are not routinely held, and they
+are not undertaken lightly. Each proposal is first discussed on the
+&email-debian-vote; mailing list and it requires several
+endorsements before the project secretary starts the voting procedure.
+</para>
+<para>
+You don't have to track the pre-vote discussions, as the secretary will issue
+several calls for votes on &email-debian-devel-announce; (and
+all developers are expected to be subscribed to that list). Democracy doesn't
+work well if people don't take part in the vote, which is why we encourage all
+developers to vote. Voting is conducted via GPG-signed/encrypted email
+messages.
+</para>
+<para>
+The list of all proposals (past and current) is available on the <ulink
+url="&url-vote;">Debian Voting Information</ulink> page, along
+with information on how to make, second and vote on proposals.
+</para>
+</section>
+
+<section id="inform-vacation">
+<title>Going on vacation gracefully</title>
+<para>
+It is common for developers to have periods of absence, whether those are
+planned vacations or simply being buried in other work. The important thing to
+notice is that other developers need to know that you're on vacation so that
+they can do whatever is needed if a problem occurs with your packages or other
+duties in the project.
+</para>
+<para>
+Usually this means that other developers are allowed to NMU (see <xref
+linkend="nmu"/> ) your package if a big problem (release critical bug, security
+update, etc.) occurs while you're on vacation. Sometimes it's nothing as
+critical as that, but it's still appropriate to let others know that you're
+unavailable.
+</para>
+<para>
+In order to inform the other developers, there are two things that you should
+do. First send a mail to <email>debian-private@&lists-host;</email> with
+[VAC] prepended to the subject of your message<footnote><para> This is so that
+the message can be easily filtered by people who don't want to read vacation
+notices. </para> </footnote> and state the period of time when you will be on
+vacation. You can also give some special instructions on what to do if a
+problem occurs.
+</para>
+<para>
+The other thing to do is to mark yourself as on vacation in the
+<link linkend="devel-db">Debian developers' LDAP database</link> (this
+information is only accessible to Debian developers). Don't forget to remove
+the on vacation flag when you come back!
+</para>
+<para>
+Ideally, you should sign up at the <ulink
+url="&url-newmaint-db;gpg.php">GPG coordination site</ulink> when booking a
+holiday and check if anyone there is looking for signing. This is especially
+important when people go to exotic places where we don't have any developers
+yet but where there are people who are interested in applying.
+</para>
+</section>
+
+<section id="upstream-coordination">
+<title>Coordination with upstream developers</title>
+<para>
+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 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.
+</para>
+<para>
+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.
+</para>
+<para>
+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 developers which
+can be included there, so that you won't have to modify the sources of the next
+upstream version. Whatever changes you need, always try not to fork from the
+upstream sources.
+</para>
+</section>
+
+<section id="rc-bugs">
+<title>Managing release-critical bugs</title>
+<para>
+Generally you should deal with bug reports on your packages as described in
+<xref linkend="bug-handling"/> . However, there's a special category of bugs
+that you need to take care of — the so-called release-critical bugs (RC
+bugs). All bug reports that have severity <emphasis>critical</emphasis>,
+<emphasis>grave</emphasis> or <emphasis>serious</emphasis> are considered to
+have an impact on whether the package can be released in the next stable
+release of Debian. These bugs can delay the Debian release and/or can justify
+the removal of a package at freeze time. That's why these bugs need to be
+corrected as quickly as possible.
+</para>
+<para>
+Developers who are part of the <ulink url="&url-debian-qa;">Quality
+Assurance</ulink> group are following all such bugs, and trying to help
+whenever possible. If, for any reason, you aren't able fix an RC bug in a
+package of yours within 2 weeks, you should either ask for help by sending a
+mail to the Quality Assurance (QA) group
+<email>debian-qa@&lists-host;</email>, or explain your difficulties and
+present a plan to fix them by sending a mail to the bug report. Otherwise,
+people from the QA group may want to do a Non-Maintainer Upload (see <xref
+linkend="nmu"/> ) after trying to contact you (they might not wait as long as
+usual before they do their NMU if they have seen no recent activity from you in
+the BTS).
+</para>
+</section>
+
+<section id="s3.7">
+<title>Retiring</title>
+<para>
+If you choose to leave the Debian project, you should make sure you do the
+following steps:
+</para>
+<orderedlist numeration="arabic">
+<listitem>
+<para>
+Orphan all your packages, as described in <xref linkend="orphaning"/> .
+</para>
+</listitem>
+<listitem>
+<para>
+Send an gpg-signed email about why you are leaving the project to
+<email>debian-private@&lists-host;</email>.
+</para>
+</listitem>
+<listitem>
+<para>
+Notify the Debian key ring maintainers that you are leaving by opening a ticket
+in Debian RT by sending a mail to keyring@rt.debian.org with the words 'Debian
+RT' somewhere in the subject line (case doesn't matter).
+</para>
+</listitem>
+</orderedlist>
+</section>
+
+</chapter>
+
+++ /dev/null
-<!DOCTYPE debiandoc PUBLIC "-//DebianDoc//DTD DebianDoc//EN" [
- <!-- include version information so we don't have to hard code it
- within the document -->
- <!ENTITY % versiondata SYSTEM "version.ent"> %versiondata;
- <!-- common, language independent entities -->
- <!ENTITY % commondata SYSTEM "common.ent" > %commondata;
- <!ENTITY % dynamicdata SYSTEM "dynamic.ent" > %dynamicdata;
-
- <!-- CVS revision of this document -->
- <!ENTITY cvs-rev "$Revision: 1.64 $">
-
- <!-- if you are translating this document, please notate the CVS
- revision of the original developer's reference in cvs-en-rev -->
- <!-- <!ENTITY cvs-en-rev "1.315"> -->
-
- <!-- how to mark a section that needs more work -->
- <!ENTITY FIXME "<em>FIXME:</em> ">
-
-]>
-<debiandoc>
- <book>
- <titlepag>
- <title>
- Référence du développeur Debian
- </title>
- <author>
- <name>L'équipe de la Référence du développeur</name>&email-devel-ref;
- </author>
- <author>
- <name>Andreas Barth </name>
- </author>
- <author>
- <name>Adam Di Carlo </name>
- </author>
- <author>
- <name>Raphaël Hertzog </name>
- </author>
- <author>
- <name>Christian Schwarz </name>
- </author>
- <author>
- <name>Ian Jackson </name>
- </author>
-<translator>
- version française par Frédéric Bothamy (traducteur actuel)
-</translator>
-<translator>et Antoine Hulin (ancien traducteur)</translator>
-<translator>
- et les membres de la liste <email>debian-l10n-french@lists.debian.org</email>
-</translator>
- <version>
- Version &version;, &date-fr; (version française 20061130).
- </version>
- <copyright>
- <copyrightsummary>
- Copyright © 2004—2006 Andreas Barth
- </copyrightsummary>
- <copyrightsummary>
- Copyright © 1998—2003 Adam Di Carlo
- </copyrightsummary>
- <copyrightsummary>
- Copyright © 2002—2003 Raphaël Hertzog
- </copyrightsummary>
- <copyrightsummary>
- Copyright © 1997, 1998 Christian Schwarz.
- </copyrightsummary>
- <p>
- Ce manuel est un logiciel libre ; il peut être redistribué et/ou
- modifié selon les termes de la licence publique générale du projet GNU
- (GNU GPL), telle que publiée par la « Free Software
- Foundation » (version 2 ou toute version postérieure).
- </p>
- <p>
- Il est distribué dans l'espoir qu'il sera utile, mais <em>sans aucune
- garantie</em>, sans même la garantie implicite d'une possible valeur
- marchande ou d'une adéquation à un besoin particulier. Consultez la
- licence publique générale du projet GNU pour plus de détails.
- </p>
- <p>
- Une copie de la licence publique générale du projet GNU est disponible
- dans le fichier &file-GPL; de la distribution &debian-formal; ou sur
- la toile : <url id="http://www.gnu.org/copyleft/gpl.html"
- name="la licence publique générale du projet GNU">. Vous pouvez
- également l'obtenir en écrivant à la &fsf-addr;. <![ %htmltext [
- </p>
- <p>
- Si vous désirez imprimer cette référence, vous devriez utiliser la
- <url id="developers-reference.pdf" name="version PDF">. Cette page est
- également disponible en <url id="index.en.html" name="anglais">. ]]>
- </p>
- </copyright>
- </titlepag>
- <toc detail="sect1">
-
- <chapt id="scope">
- <heading>
- Portée de ce document
- </heading>
- <p>
- Le but de ce document est de donner une vue d'ensemble des procédures à
- suivre et des ressources mises à la disposition des développeurs Debian.
- </p>
- <p>
- Les procédures décrites ci-après expliquent comment devenir responsable
- Debian (<ref id="new-maintainer">), comment créer de nouveaux paquets
- (<ref id="newpackage">) et comment les installer dans l'archive (<ref
- id="upload">), comment gérer les rapports de bogues (<ref
- id="bug-handling">), comment déplacer, effacer ou abandonner un paquet
- (<ref id="archive-manip">), comment faire le portage d'un paquet (<ref
- id="porting">), quand et comment faire la mise à jour du paquet d'un
- autre responsable (<ref id="nmu">).
- </p>
- <p>
- Les ressources présentées dans ce manuel incluent les listes de
- diffusion (<ref id="mailing-lists">) et les serveurs (<ref
- id="server-machines">), une présentation de la structure de l'archive
- Debian (<ref id="archive">), des explications sur les serveurs qui
- acceptent les mises à jour de paquets (<ref id="upload-ftp-master">) et
- une présentation des outils qui peuvent aider un responsable à améliorer
- la qualité de ses paquets (<ref id="tools">).
- </p>
- <p>
- Ce manuel de référence ne présente pas les aspects techniques liés aux
- paquets Debian, ni comment les créer. Il ne décrit pas non plus les
- règles que doivent respecter les paquets Debian. Cette information est
- disponible dans la <url id="&url-debian-policy;" name="charte Debian">.
- </p>
- <p>
- De plus ce document <em>n'est pas l'expression d'une politique
- officielle</em>. Il contient de la documentation sur le système Debian
- et des conseils pratiques largement suivis. Ce n'est donc pas une sorte
- de guide de normes.
- </p>
- <sect>Introduction à la version française
-
- <sect1>Avertissement
-
-<p>
-Bien que ce document soit en français, l'activité de responsable Debian implique
-une maîtrise de la langue anglaise. Le projet Debian est un projet international
-auquel participent des japonais, néo-zélandais, américains, allemands,
-finlandais, français, espagnols, danois, etc.
-
-<p>
-En conséquence, la langue utilisée dans toutes les listes de diffusion destinées
-aux développeurs (à l'exception de la liste
-<email>debian-devel-french@&lists-host;</email>) est l'anglais et les rapports
-de bogue doivent être rédigés en anglais. En fait, sauf exception rare, tout
-dialogue avec les autres responsables Debian se fera en anglais quel que soit le
-média.
-
-
- <sect1>Glossaire
-
-<p>
-Cette section liste les termes techniques qui ont un sens spécifique dans le
-projet Debian. Pour chacune de ces expressions, vous trouverez la traduction
-française utilisée dans ce manuel, une définition et une référence à la section
-du manuel qui traite de ce sujet.
-
-
-<list>
- <item><em>Upload</em> : mise à jour, téléchargement (parfois
- livraison). Opération qui consiste à télécharger un nouveau paquet ou
- une nouvelle version de paquet dans l'archive Debian (<ref
- id="upload">).
-
- <item><em>Non-maintainer upload (NMU)</em> : mise à jour
- indépendante. Téléchargement d'une nouvelle version de paquet dans
- l'archive Debian par une personne qui n'est pas officiellement
- responsable de ce paquet (<ref id="nmu">).
-
- <item><em>Source NMU</em> : mise à jour indépendante source. Il
- s'agit d'une mise à jour indépendante pour un paquet source (<ref
- id="nmu-terms">).
-
- <item><em>Binary NMU</em> : mise à jour indépendante binaire. Mise
- à jour indépendante pour un paquet binaire (<ref id="nmu-terms">).
-
- <item><em>Bug Tracking System (BTS)</em> : système de suivi des
- bogues. Il s'agit du système utilisé par le projet Debian pour suivre
- les bogues et leur correction (<ref id="bug-handling">).
-
- <item><em>Bug submitter</em> : rapporteur du bogue. Personne qui
- envoie un rapport de bogue au système de suivi des bogues (<ref
- id="submit-bug">).
-
- <item><em>Release critical bug</em> : bogue empêchant l'intégration
- du paquet dans la distribution. Bogues de gravité <em>critique</em>,
- <em>grave</em> et <em>sérieuse</em>. Ces bogues ne doivent pas
- apparaître dans une distribution <em>stable</em>. Ils doivent être
- corrigés ou bien les paquets en cause doivent être supprimés (<ref
- id="rc-bugs">).
-
- <item><em>Package Tracking System (PTS)</em> : système de suivi des
- paquets. Il s'agit du système utilisé par le projet Debian pour suivre
- les paquets sources des différentes distributions (<ref
- id="pkg-tracking-system">).
-
- <item><em>Unstable</em> : nom de la distribution en cours
- de développement. Cette distribution contient les paquets
- envoyés par les développeurs. Ceux-ci n'étant que des êtres
- humains, elle est parfois cassée (<ref id="sec-dists">).
-
- <item><em>Testing</em> : nom de la distribution en test. Cette
- distribution reçoit les paquets des développeurs qui ont passé une
- période de deux semaines dans <em>unstable</em> et pour lesquels aucun
- bogue remettant en cause la distribution (cf. <em>Release critical
- bug</em>) n'a été découvert. Cette distribution n'a pas été testée en
- profondeur. Elle est cependant censée être plus stable
- qu'<em>unstable</em> (<ref id="sec-dists">).
-
- <item><em>Stable</em> : nom de la distribution stable. Cette
- distribution a été testée, validée et diffusée (<ref id="sec-dists">).
-
- <item><em>Debian maintainer</em> : responsable Debian, développeur
- Debian (parfois mainteneur). Personne qui fait officiellement partie du
- projet Debian. Elle a accès aux serveurs Debian et participe au
- développement — au sens large — de la distribution (<ref
- id="developer-duties">). La plupart des responsables font de la mise en
- paquet, mais il existe d'autres activités telles que la documentation,
- la gestion du site web, la création des cédéroms, l'administration des
- serveurs, etc.
-
- <item><em>Upstream version</em> : version amont. Il s'agit du
- logiciel tel qu'il est fourni par le responsable amont — par
- opposition à la version fournie par la distribution Debian. (Voir <ref
- id="upstream-coordination">.)
-
- <item><em>Upstream maintainer</em> : responsable amont ou
- développeur amont. Personne responsable du développement ou de la
- maintenance d'un logiciel. En général, le responsable amont n'a rien à
- voir avec le projet Debian (<ref id="upstream-coordination">).
-
- <item><em>Debian keyring</em> : porte-clés Debian. Le porte-clés
- Debian contient les clés publiques de tous les responsables Debian (<ref
- id="key-maint">).
-
- <item><em>Work-needing and prospective packages (WNPP)</em> :
- paquets en souffrance et paquets souhaités. La liste des paquets en
- souffrance indique les paquets qui n'ont plus de responsable. La liste
- des paquets souhaités indique les logiciels que des utilisateurs
- aimeraient bien voir dans la distribution (<ref id="upload">).
-
- </list>
- </chapt>
- <chapt id="new-maintainer">
- <heading>
- Devenir responsable Debian
- </heading>
- <sect id="getting-started">
- <heading>
- Pour commencer
- </heading>
- <p>
- Vous avez lu toute la documentation, vous avez examiné le <url
- id="&url-newmaint-guide;" name="guide du nouveau responsable">, vous
- comprenez l'intérêt de tout ce qui se trouve dans le paquet d'exemple
- <package>hello</package> et vous vous apprêtez à mettre en paquet votre
- logiciel préféré. Comment devenir responsable Debian et intégrer votre
- travail au projet ?
- </p>
- <p>
- Si vous ne l'avez pas encore fait, commencez par vous inscrire à la
- liste &email-debian-devel;. Pour cela, envoyez un courrier à l'adresse
- &email-debian-devel-req; avec le mot <tt>subscribe</tt> dans la ligne
- <em>Objet</em><footnote><p><em>Subject</em> en anglais</p></footnote>
- de votre message. En cas de problème, contactez l'administrateur de la
- liste &email-listmaster;. Vous trouverez plus d'informations dans la
- section <ref id="mailing-lists">. &email-debian-devel-announce; est une
- autre liste incontournable pour qui veut suivre les développements de
- Debian.
- </p>
- <p>
- Vous suivrez les discussions de cette liste (sans poster) pendant
- quelque temps avant de coder quoi que ce soit et vous informerez la
- liste de votre intention de travailler sur quelque chose pour éviter de
- dupliquer le travail d'un autre.
- </p>
- <p>
- Une autre liste intéressante est &email-debian-mentors;. Voir la
- section <ref id="mentors"> pour les détails. Le canal IRC
- <tt>#debian</tt> pourra aussi être utile ; voir <ref
- id="irc-channels">.
- </p>
- <p>
- Quand vous avez choisi la manière dont vous contribuerez au projet
- &debian-formal;, prenez contact avec les responsables Debian qui
- travaillent sur des tâches similaires. Ainsi, vous pourrez apprendre
- auprès de personnes expérimentées. Si, par exemple, vous voulez mettre
- en paquet des logiciels existants, trouvez-vous un parrain. Un parrain
- est une personne qui travaillera sur vos paquets avec vous et les
- téléchargera dans l'archive Debian une fois qu'il sera satisfait de
- votre mise en paquet. Pour trouver un parrain, envoyez une demande de
- parrainage à la liste &email-debian-mentors; en vous présentant et en
- décrivant votre paquet (voir <ref id="sponsoring"> et <url
- id="&url-mentors;"> pour en savoir plus sur le sujet). Si vous préférez
- porter Debian sur une architecture ou un noyau alternatif, abonnez-vous
- aux listes dédiées au portage et demandez-y comment
- démarrer. Finalement, si vous êtes intéressé par la documentation ou
- l'assurance qualité (QA), vous pouvez contacter les responsables qui
- travaillent déjà sur ces tâches et proposer des correctifs et des
- améliorations.
- </p>
- <p>
- Un écueil à éviter est d'avoir la partie locale de votre adresse
- électronique trop générique : des termes comme mail, admin, root ou
- master devraient être évitées. Veuillez consulter <url
- id="http://www.debian.org/MailingLists/"> pour plus de détails.
- </p>
- </sect>
- <sect id="mentors">
- <heading>
- Mentors et parrains Debian
- </heading>
- <p>
- La liste de diffusion &email-debian-mentors; a été mise en place pour
- les responsables débutants recherchant de l'aide avec l'empaquetage
- initial et d'autres problèmes de développeur. Chaque nouveau
- développeur est invité à s'abonner à cette liste (voir <ref
- id="mailing-lists"> pour les détails).
- </p>
- <p>
- Ceux qui préfèrent recevoir une aide plus personnalisée (par exemple,
- par courriels privés) devraient également envoyer des messages à cette
- liste et un développeur expérimenté se proposera de les aider.
- </p>
- <p>
- De plus, si vous avez des paquets prêts à être inclus dans Debian, mais
- que vous attendez que votre demande pour devenir responsable soit
- acceptée, vous pouvez trouver un parrain pour envoyer vos paquets pour
- vous. Les parrains sont des développeurs Debian officiels qui sont
- volontaires pour critiquer et envoyer vos paquets pour vous. Veuillez
- lire en premier la FAQ non officielle de debian-mentors à <url
- id="&url-mentors;">.
- </p>
- <p>
- Si vous désirez être un mentor et/ou un parrain, vous pouvez trouver
- plus d'informations à <ref id="newmaint">.
- </p>
- </sect>
- <sect id="registering">
- <heading>
- S'enregistrer comme responsable Debian
- </heading>
- <p>
- Avant de décider de devenir responsable Debian, il vous faudra lire
- toute la documentation disponible dans le <url id="&url-newmaint;"
- name="coin du nouveau responsable">. Elle décrit en détail toutes les
- étapes préparatoires qu'il vous faudra franchir avant de déposer votre
- candidature. Par exemple, avant d'être candidat, il vous faudra lire le
- <url id="&url-social-contract;" name="contrat social Debian">. Devenir
- responsable Debian implique que vous adhériez à ce contrat social et
- que vous vous engagiez à le soutenir ; il est très important que
- les responsables soient en accord avec les principes fondamentaux qui
- animent le projet &debian-formal;. Lire le <url
- id="&url-gnu-manifesto;" name="Manifeste GNU"> est aussi une bonne
- idée.
- </p>
- <p>
- Le processus d'enregistrement a pour but de vérifier votre identité,
- vos intentions et vos compétences. Le nombre de personnes travaillant
- pour &debian-formal; a atteint &number-of-maintainers; et notre système
- est utilisé dans plusieurs endroits très importants : nous devons
- rester vigilants pour éviter un acte malveillant. C'est pourquoi nous
- contrôlons les nouveaux responsables avant de leur donner un compte sur
- nos serveurs et de les autoriser à ajouter des paquets dans l'archive.
- </p>
- <p>
- Pour devenir responsable, il faudra montrer que vous pouvez faire du
- bon travail et que vous serez un bon contributeur. Pour cela, vous
- pourrez proposer des correctifs par le système de suivi des bogues
- (BTS) et maintenir un paquet parrainé par un responsable Debian pendant
- un temps. Nous attendons
- aussi des contributeurs qu'ils soient intéressés par le projet dans son
- ensemble et pas uniquement par leurs propres paquets. Si vous pouvez
- aider d'autres responsables en fournissant des informations sur un
- bogue ou même avec un correctif, faites-le !
- </p>
- <p>
- Pour votre candidature, vous devrez être familiarisé avec la
- philosophie du projet Debian et avec sa documentation technique. Il
- vous faudra aussi une clé GnuPG signée par un responsable Debian. Si
- votre clé GnuPG n'est pas encore signée, vous devriez essayer de
- rencontrer un responsable Debian pour le faire. La <url
- id="&url-gpg-coord;" name="page de coordination des signatures de clé
- GnuPG"> devrait vous aider à trouver un responsable Debian près de chez
- vous. (S'il n'y a pas de responsable près de chez vous, il peut y avoir
- des moyens alternatifs pour valider votre identité en tant qu'exception
- absolue étudiée au cas par cas. Veuillez vous reporter à la <url
- id="&url-newmaint-id;" name="page d'identification"> pour en savoir
- plus).
- </p>
- <p>
- Si vous n'avez pas de clé OpenPGP, créez-la. Tout responsable a besoin
- d'une clé OpenPGP pour signer et vérifier les mises à jour de
- paquets. Vous lirez la documentation du logiciel de cryptographie que
- vous utiliserez car elle contient des informations indispensables pour
- la sécurité de votre clé. Les défaillances de sécurité sont bien plus
- souvent dues à des erreurs humaines qu'à des problèmes logiciels ou à
- des techniques d'espionnage avancées. Voir <ref id="key-maint"> pour
- plus d'informations sur la gestion de votre clé publique.
- </p>
- <p>
- Debian utilise <prgn>GNU Privacy Guard</prgn> (paquet
- <package>gnupg</package> version 1 ou supérieure) comme standard de
- base. Vous pouvez aussi utiliser une autre implémentation
- d'OpenPGP. OpenPGP est un standard ouvert basé sur la <url
- id="&url-rfc2440;" name="RFC 2440">.
- </p>
- <p>
- Vous avez besoin d'une clé en version 4 à utiliser pour le
- développement Debian. La longueur de votre clé doit être d'au moins
- 1024 ;bits ; il n'y a pas de raison d'utiliser une clé plus
- petite et faire cela serait bien moins sûr. <footnote><p>Les clés en
- version 4 sont des clés conformes au standard OpenPGP défini dans
- la RFC 2440. La version 4 est le type de clé qui a toujours
- été créé avec GnuPG. Les versions de PGP depuis la version 5
- peuvent également créer des clés version 4, l'autre choix ayant
- été des clés compatibles pgp 2.6.x (également appelées
- « legacy RSA » par PGP).</p><p>Les clés (primaires) en
- version 4 peuvent soit utiliser l'algorithme RSA, soit
- l'algorithme DSA, cela n'a donc rien à voir avec la question de GnuPG à
- propos de « quel type de clé voulez-vous : (1) DSA et
- Elgamal, (2) DSA (signature seule), (5) RSA (signature seule). Si vous
- n'avez pas des besoins spécifiques, choisissez simplement la valeur par
- défaut ».</p><p>Le moyen le plus simple de dire si une clé
- existante est une clé v4 ou une clé v3 (ou v2) est de regarder son
- empreinte : les empreintes des clés en version 4 sont des
- hachés SHA-1 d'une partie de la clé, il s'agit donc d'une suite de
- 40 chiffres hexadécimaux, habituellement groupés par blocs de
- 4. Les empreintes des anciennes versions de clé utilisaient MD5 et sont
- généralement affichées par blocs de 2 chiffres hexadécimaux. Par
- exemple, si votre empreinte ressemble à ceci :
- <tt>5B00 C96D 5D54 AEE1 206B AF84 DE7A AF6E 94C0 9C7F</tt>,
- alors il s'agit d'une clé v4.</p><p>Une autre possibilité est d'envoyer
- la clé dans <prgn>pgpdump</prgn>, qui dira quelque chose comme
- « Public Key Packet - Ver 4 ».</p><p>Notez également que
- votre clé doit être auto-signée (c.-à-d. elle doit signer tous ses
- propres identifiants d'utilisateur ; cela empêche la falsification
- d'identité). Tous les logiciels OpenPGP modernes font cela
- automatiquement, mais si vous avez une ancienne clé, il se peut que
- vous deviez ajouter manuellement ces signatures.</p></footnote>
- </p>
- <p>
- Si votre clé publique n'est pas sur un serveur public tel que
- &pgp-keyserv;, reportez-vous à la documentation disponible à
- <url id="&url-newmaint-id;" name="Étape 2 : Vérification d'identité">.
- Cette documentation explique comment mettre votre
- clé publique sur un serveur. L'équipe <em>New maintainer</em> mettra
- votre clé publique sur les serveurs de clés si elle n'y est pas déjà.
- </p>
- <p>
- Certains pays limitent l'usage des logiciels de cryptographie. Cela ne
- devrait cependant pas avoir d'impact sur l'activité d'un responsable de
- paquet car il peut être tout à fait légal d'utiliser des logiciels de
- cryptographie pour l'authentification plutôt que pour le
- chiffrement. Si vous vivez dans un pays où l'utilisation de la
- cryptographie pour authentification est interdite, contactez-nous pour
- que nous prenions des dispositions particulières.
- </p>
- <p>
- Pour faire acte de candidature, il vous faut un responsable Debian qui
- soutiendra votre candidature (un <em>avocat</em>). Après avoir contribué
- au projet Debian pendant un temps, quand vous choisissez de devenir un
- responsable Debian officiel, un responsable déjà enregistré avec qui
- vous aurez travaillé dans les derniers mois devra exprimer que, d'après
- lui, vous pouvez contribuer avec succès au projet Debian.
- </p>
- <p>
- Quand vous avez trouvé un <em>avocat</em>, quand votre clé GnuPG est
- signée et quand vous avez déjà contribué au projet, vous êtes prêt à
- faire acte de candidature. Il vous suffit pour cela de vous enregistrer
- sur notre <url id="&url-newmaint-apply;" name="page de
- candidature">. Ensuite, votre avocat devra confirmer votre
- candidature. Quand il aura accompli cette tâche, un responsable de
- candidature<footnote><p>Application manager</p></footnote> sera désigné
- pour vous accompagner dans le processus d'enregistrement. Vous pouvez
- toujours consulter le <url id="&url-newmaint-db;" name="tableau de bord
- des candidatures"> pour connaître l'état de votre candidature.
- </p>
- <p>
- Pour en savoir plus, consultez le <url id="&url-newmaint;" name="coin
- des nouveaux responsables"> sur le site Debian. Assurez-vous de bien
- connaître les étapes nécessaires au processus d'enregistrement avant de
- vous porter candidat. Vous gagnerez beaucoup de temps si vous êtes bien
- préparé.
- </p>
- </sect>
- </chapt>
- <chapt id="developer-duties">
- <heading>
- Les charges du responsable Debian
- </heading>
- <sect id="user-maint">
- <heading>
- Mise à jour de vos références Debian
- </heading>
- <p>
- Il existe une base de données LDAP contenant des informations
- concernant les développeurs Debian à <url id="&url-debian-db;">. Vous
- devriez y entrer vos informations et les mettre à jour quand elles
- changent. Le plus important est de vous assurer que l'adresse vers
- laquelle est redirigée votre adresse debian.org est toujours à jour, de
- même que l'adresse à laquelle vous recevez votre abonnement à
- debian-private si vous choisissez d'être abonné à cette liste.
- </p>
- <p>
- Pour plus d'informations à propos de cette base de données, veuillez
- consulter <ref id="devel-db">.
- </p>
- </sect>
- <sect id="key-maint">
- <heading>
- Gérer votre clé publique
- </heading>
- <p>
- Soyez très vigilant en utilisant votre clé privée. Ne la placez pas sur
- un serveur public ou sur des machines multi-utilisateurs telles que les
- serveurs Debian (voir <ref id="server-machines">). Sauvegardez vos clés
- et gardez-en une copie hors connexion. Lisez la documentation fournie
- avec votre logiciel et la <url id="&url-pgp-faq;" name="FAQ PGP">.
- </p>
- <p>
- Vous devez vous assurer que non seulement votre clé est à l'abri des
- vols, mais également à l'abri d'une perte. Générez et faites une copie
- (et également sur papier) de votre certificat de révocation ; il
- est nécessaire si votre clé est perdue.
- </p>
- <p>
- Si vous ajoutez des signatures ou des identifiants à votre clé
- publique, vous pouvez mettre à jour le porte-clés Debian en envoyant
- votre clé publique à <tt>&keyserver-host;</tt>.
- </p>
- <p>
- Si vous voulez ajouter une nouvelle clé ou supprimer une ancienne clé,
- vous devez faire signer la nouvelle clé par un autre développeur. Si
- l'ancienne clé est compromise ou invalide, vous devez également ajouter
- la certification de révocation. S'il n'y pas de vraie raison pour une
- nouvelle clé, les responsables du trousseau de clés peuvent rejeter la
- nouvelle clé. Vous pouvez trouver plus de détails à <url
- id="http://keyring.debian.org/replacing_keys.html">.
- </p>
- <p>
- Les mêmes routines d'extraction de clé décrites dans <ref
- id="registering"> s'appliquent.
- </p>
- <p>
- Vous pouvez trouver une présentation approfondie de la gestion de clé
- Debian dans la documentation du paquet
- <package>debian-keyring</package>.
- </p>
- </sect>
- <sect id="voting">
- <heading>
- Voter
- </heading>
- <p>
- Bien que Debian ne soit pas vraiment une démocratie, nous disposons
- d'un processus démocratique pour élire nos chefs et pour approuver les
- résolutions générales. Ces procédures sont définies par la <url
- id="&url-constitution;" name="charte Debian">.
- </p>
- <p>
- En dehors de l'élection annuelle du chef, les votes ne se tiennent pas
- régulièrement et ils ne sont pas entrepris à la légère. Chaque
- proposition est tout d'abord discutée sur la liste de diffusion
- &email-debian-vote; et elle a besoin de plusieurs approbations avant
- que le secrétaire du projet n'entame la procédure de vote.
- </p>
- <p>
- Vous n'avez pas besoin de suivre les discussions précédant le vote car
- le secrétaire enverra plusieurs appels au vote sur la liste
- &email-debian-devel-announce; (et tous les développeurs devraient être
- inscrits à cette liste). La démocratie ne fonctionne pas si les
- personnes ne prennent pas part au vote, c'est pourquoi nous
- encourageons tous les développeurs à voter. Le vote est conduit par
- messages signés ou chiffrés par GPG.
- </p>
- <p>
- La liste de toutes les propositions (passées et présentes) est
- disponible à la page <url id="&url-vote;" name="Informations sur les
- votes Debian">, ainsi que des informations complémentaires sur la
- procédure à suivre pour effectuer une proposition, la soutenir et voter
- pour elle.
- </p>
- </sect>
- <sect id="inform-vacation">
- <heading>
- Prendre des vacances courtoisement
- </heading>
- <p>
- Il est courant pour les développeurs de s'absenter, que ce soit pour
- des vacances prévues ou parce qu'ils sont submergés de travail. La
- chose importante à noter est que les autres développeurs ont besoin de
- savoir que vous êtes en vacances pour qu'ils puissent agir en
- conséquence si un problème se produit pendant vos vacances.
- </p>
- <p>
- Habituellement, cela veut dire que les autres développeurs peuvent
- faire des NMU (voir <ref id="nmu">) sur votre paquet si un gros
- problème (bogue empêchant l'intégration dans la distribution, mise à
- jour de sécurité, etc.) se produit pendant que vous êtes en
- vacances. Parfois, ce n'est pas très important, mais il est de toute
- façon approprié d'indiquer aux autres que vous n'êtes pas disponible.
- </p>
- <p>
- Il y a deux choses à faire pour informer les autres
- développeurs. Premièrement, envoyez un courrier électronique à
- &email-debian-private; en commençant le sujet de votre message par
- « [VAC] »<footnote><p>Ainsi, le message peut être facilement
- filtré par les personnes qui ne veulent pas lire ces annonces de
- vacances.</p></footnote> et donnez la période de vos vacances. Vous
- pouvez également donner quelques instructions pour indiquer comment
- agir si un problème survenait.
- </p>
- <p>
- L'autre chose à faire est de vous signaler comme « en
- vacances »<footnote><p><em>on vacation</em> en
- anglais</p></footnote> dans la <qref id="devel-db">base de données
- Debian LDAP</qref> (l'accès à cette information est réservé aux
- développeurs). N'oubliez pas de retirer votre indicateur « en
- vacances » lorsque celles-ci sont terminées !
- </p>
- <p>
- Idéalement, vous devriez vous connecter sur le <url
- id="http://nm.debian.org/gpg.php" name="site de coordination GPG">
- quand vous réservez pour des vacances et vérifier si quelqu'un
- recherche un échange de signatures. Cela est particulièrement important
- quand des personnes vont à des endroits exotiques où nous n'avons pas
- encore de développeurs, mais où il y a des personnes intéressées pour
- poser leur candidature.
- </p>
- </sect>
- <sect id="upstream-coordination">
- <heading>
- Coordination avec les développeurs amont
- </heading>
- <p>
- Une grande part de votre travail de responsable Debian sera de rester
- en contact avec les développeurs amont. Parfois, les utilisateurs
- établissent des rapports de bogue qui ne sont pas spécifiques à
- Debian. Vous devez transmettre ces rapports de bogue aux développeurs
- amont pour qu'ils soient corrigés dans les prochaines versions.
- </p>
- <p>
- Bien qu'il ne soit pas de votre responsabilité de corriger les bogues
- non spécifiques à Debian, vous pouvez le faire si vous en êtes
- capable. Quand vous faites de telles corrections, assurez-vous de les
- envoyer également au développeur amont. Les utilisateurs et
- responsables Debian proposent souvent des correctifs pour corriger des
- bogues amont, il vous faudra alors évaluer ce correctif puis le
- transmettre aux développeurs amont.
- </p>
- <p>
- Si vous avez besoin de modifier les sources d'un logiciel pour
- fabriquer un paquet conforme à la charte Debian, alors vous devriez
- proposer un correctif aux développeurs amont pour qu'il soit inclus
- dans leur version. Ainsi, vous n'aurez plus besoin de modifier les
- sources lors des mises à jour amont suivantes. Quels que soient les
- changements dont vous avez besoin, il faut toujours essayer de rester
- dans la lignée des sources amont.
- </p>
- </sect>
- <sect id="rc-bugs">
- <heading>
- Comment gérer les bogues empêchant l'intégration du paquet dans la
- distribution ?
- </heading>
- <p>
- Habituellement, vous devriez traiter les rapports de bogue sur vos
- paquets tel que cela est décrit dans <ref
- id="bug-handling">. Cependant, il y a une catégorie spéciale de bogues
- qui nécessite particulièrement votre attention : les bogues
- empêchant l'intégration du paquet dans la
- distribution<footnote><p>Traduction de l'anglais <em>Release-critical
- bug (RC Bugs)</em></p></footnote>. Tous les rapports de bogue de
- gravité <em>critique</em>, <em>grave</em> et
- <em>sérieuse</em><footnote><p>Respectivement <em>critical</em>,
- <em>grave</em> et <em>serious</em> en anglais</p></footnote> sont
- considérés comme ayant un impact sur la présence du paquet dans la
- prochaine version stable de Debian. Ces bogues peuvent retarder la
- publication d'une distribution Debian ou peuvent justifier la suppression
- d'un paquet d'une distribution gelée. C'est pourquoi ces bogues doivent
- être corrigés au plus vite.
- </p>
- <p>
- Les développeurs faisant partie de l'équipe d'<url id="&url-debian-qa;"
- name="assurance qualité Debian"> surveillent ces bogues et essaient de
- vous aider chaque fois qu'ils le peuvent. Si vous ne pouvez pas
- corriger un bogue de ce type dans les deux semaines, vous devriez soit
- demander de l'aide en envoyant un courrier à l'équipe d'assurance
- qualité (<em>QA group</em>) à &email-debian-qa;, soit expliquer vos
- difficultés et présenter un plan pour corriger le problème en répondant
- au rapport de bogue concerné. Si rien n'est fait, des personnes de
- l'équipe d'assurance qualité pourraient chercher à corriger votre
- paquet (voir <ref id="nmu">) après avoir tenté de vous contacter (ils
- pourraient attendre moins longtemps que d'habitude pour faire leur mise
- à jour s'il n'y a pas trace d'activité récente de votre part dans le
- système de suivi des bogues).
- </p>
- </sect>
- <sect>
- <heading>
- Démissionner
- </heading>
- <p>
- Si vous choisissez de quitter le projet Debian, procédez comme
- suit :
- <enumlist numeration="arabic">
- <item>
- <p>
- abandonnez tous vos paquets comme décrit dans <ref
- id="orphaning"> ;
- </p>
- </item>
- <item>
- <p>
- envoyez un courrier électronique signé par GnuPG à
- &email-debian-private; indiquant pourquoi vous quittez le
- projet ;
- </p>
- </item>
- <item>
- <p>
- signalez aux responsables du porte-clés Debian que vous quittez le
- projet en écrivant à &email-debian-keyring;.
- </p>
- </item>
- </enumlist>
- </p>
- </sect>
- </chapt>
- <chapt id="resources">
- <heading>
- Ressources pour le responsable Debian
- </heading>
- <p>
- Dans ce chapitre, vous trouverez une brève description des listes de
- diffusion, des machines Debian qui seront à votre disposition en tant
- que responsable Debian ainsi que toutes les autres ressources à votre
- disposition pour vous aider dans votre travail de responsable.
- </p>
- <sect id="mailing-lists">
- <heading>
- Les listes de diffusion
- </heading>
- <p>
- Une grande partie des discussions entre les développeurs Debian (et les
- utilisateurs) est gérée par un vaste éventail de listes de diffusion
- que nous hébergeons à <tt><url id="http://&lists-host;/"
- name="&lists-host;"></tt>. Pour en savoir plus sur comment s'abonner ou
- se désabonner, comment envoyer un message et comment ne pas en envoyer,
- comment retrouver d'anciens messages et comment les rechercher, comment
- contacter les responsables des listes et pour savoir d'autres
- informations sur les listes de diffusion, veuillez lire <url
- id="&url-debian-lists;">. Cette section ne couvrira que les aspects des
- listes de diffusion qui ont un intérêt particulier pour les
- développeurs.
- </p>
- <sect1 id="mailing-lists-rules">
- <heading>
- Règles de base d'utilisation
- </heading>
- <p>
- Lorsque vous répondez sur une liste de diffusion, veuillez ne pas
- envoyer de copie (<tt>CC</tt>) à l'auteur d'origine sauf s'il le
- demande explicitement. Toute personne envoyant un message à une liste
- de diffusion devrait la suivre pour voir les réponses.
- </p>
- <p>
- Le multi-postage (cross-posting) (envoyer le même message à plusieurs
- listes) est découragé. Comme toujours sur le net, veuillez réduire la
- citation des articles auxquels vous répondez. En général, veuillez
- adhérez aux conventions usuelles d'envoi de messages.
- </p>
- <p>
- Veuillez lire le <url id="&url-debian-lists;#codeofconduct" name="code
- de conduite"> pour plus d'informations.
- </p>
- </sect1>
- <sect1 id="core-devel-mailing-lists">
- <heading>
- Principales listes pour les responsables
- </heading>
- <p>
- Les principales listes de diffusion de Debian que les développeurs
- devraient suivre sont :
- <list>
- <item>
- <p>
- &email-debian-devel-announce;, utilisée pour les annonces
- importantes faites aux responsables. Tous les responsables Debian
- sont censés être inscrits à cette liste,
- </p>
- </item>
- <item>
- <p>
- &email-debian-devel;, utilisée pour discuter de diverses questions
- techniques relatives au développement,
- </p>
- </item>
- <item>
- <p>
- &email-debian-policy; où l'on discute et vote les modifications de
- la charte Debian,
- </p>
- </item>
- <item>
- <p>
- &email-debian-project;, utilisée pour discuter de questions non
- techniques.
- </p>
- </item>
- </list>
- </p>
- <p>
- Il existe d'autres listes de diffusion spécialisées dans différents
- thèmes. Reportez-vous à la page <url id="http://&lists-host;/"> pour
- en obtenir la liste complète.
- </p>
- </sect1>
- <sect1 id="mailing-lists-special">
- <heading>
- Listes spéciales
- </heading>
- <p>
- &email-debian-private; est une liste de diffusion destinée aux
- discussions privées entre développeurs Debian. Elle doit être utilisée
- pour tout message qui ne doit pas être publié, quelle qu'en soit la
- raison. C'est une liste à faible trafic et les utilisateurs sont priés
- de ne l'utiliser qu'en cas de réelle nécessité. De plus, il ne faut
- <em>jamais</em> faire suivre un courrier de cette liste à qui que ce
- soit. Pour des raisons évidentes, les archives de cette liste ne sont
- pas disponibles sur la toile. Vous pouvez les consulter en visitant le
- répertoire <file>~debian/archive/debian-private</file> avec votre
- compte sur <tt>lists.debian.org</tt>.
- </p>
- <p>
- &email-debian-email; est une liste de diffusion fourre-tout. Elle est
- utilisée pour les correspondances relatives à Debian qu'il serait
- utile d'archiver, telles que des échanges avec les auteurs amont à
- propos de licences, de bogues ou encore des discussions sur le projet
- avec d'autres personnes.
- </p>
- </sect1>
- <sect1 id="mailing-lists-new">
- <heading>
- Demander une nouvelle liste relative au développement
- </heading>
- <p>
- Avant de demander une liste de diffusion liée au développement d'un
- paquet (ou d'un petit groupe de paquets liés), veuillez considérer si
- l'utilisation d'un alias (via un fichier .forward-aliasname sur
- master.debian.org, ce qui se traduit en une adresse raisonnablement
- agréable <var>you-aliasname@debian.org</var>) ou une liste de
- diffusion auto-gérée sur <qref id="alioth">Alioth</qref> serait plus
- appropriée.
- </p>
- <p>
- Si vous décidez qu'une liste de diffusion standard sur
- lists.debian.org est vraiment ce que vous voulez, lancez-vous et
- faites une demande en suivant <url id="&url-debian-lists-new;"
- name="le guide">.
- </p>
- </sect1>
- </sect>
- <sect id="irc-channels">
- <heading>
- Canaux IRC
- </heading>
- <p>
- Plusieurs canaux IRC sont dédiés au développement Debian. Ils sont
- principalement hébergés sur le réseau <url id="&url-oftc;"
- name="Open and free technology community (OFTC)">. L'entrée DNS
- <tt>irc.debian.org</tt> est simplement un alias vers
- <tt>irc.oftc.net</tt>.
- </p>
- <p>
- Le principal canal pour Debian est <em>#debian</em>. Il s'agit d'un
- canal important, généraliste, où les utilisateurs peuvent trouver des
- nouvelles récentes dans le sujet et qui est administré par des
- robots. <em>#debian</em> est destiné aux anglophones ; il existe
- également <em>#debian.de</em>, <em>#debian-fr</em>, <em>#debian-br</em>
- et d'autres canaux avec des noms semblables pour les personnes parlant
- d'autres langues.
- </p>
- <p>
- Le canal principal pour le développement Debian est
- <em>#debian-devel</em>. C'est un canal très actif avec habituellement
- plus de 150 personnes connectées en permanence. C'est un canal pour les
- personnes qui travaillent sur Debian, ce n'est pas un canal d'aide (il
- existe <em>#debian</em> pour cela). Il est cependant ouvert à tous ceux
- qui veulent écouter (et apprendre). Le sujet est toujours rempli
- d'informations intéressantes.
- </p>
- <p>
- Comme <em>#debian-devel</em> est un canal ouvert, vous ne devriez pas y
- parler de problèmes discutés sur &email-debian-private;. Il existe un
- canal protégé par clé <em>#debian-private</em> dans ce but. La clé est
- disponible dans les archives de debian-private à
- <file>master.debian.org:&file-debian-private-archive;</file>, effectuez
- simplement un <prgn>zgrep</prgn> avec <em>#debian-private</em> dans
- tous les fichiers.
- </p>
- <p>
- Il existe d'autres canaux dédiés à des sujets
- spécifiques. <em>#debian-bugs</em> est utilisé pour la coordination des
- <em>chasses aux bogues</em>. <em>#debian-boot</em> est utilisé pour la
- coordination du travail sur l'installateur Debian. <em>#debian-doc</em>
- est utilisé occasionnellement pour travailler sur la documentation
- comme celle que vous lisez actuellement. D'autres canaux sont dédiés à
- une architecture ou un ensemble de paquets : <em>#debian-bsd</em>,
- <em>#debian-kde</em>, <em>#debian-jr</em>, <em>#debian-edu</em>,
- <em>#debian-sf</em> (paquet SourceForge), <em>#debian-oo</em> (paquet
- OpenOffice), etc.
- </p>
- <p>
- Certains canaux pour développeurs non anglophones existent, par
- exemple, <em>#debian-devel-fr</em> pour les francophones intéressés
- dans le développement de Debian.
- </p>
- <p>
- Il existe également des canaux dédiés pour Debian sur d'autres réseaux
- IRC, notamment sur le réseau IRC <url id="&url-openprojects;"
- name="Freenode">, sur lequel pointait l'alias <tt>irc.debian.org</tt>
- jusqu'au 4 juin 2006.
- </p>
- <p>
- Pour obtenir un uniforme (« cloak ») sur freenode, vous devez
- envoyer un courriel signé à Jörg Jaspert <joerg@debian.org>
- dans lequel vous indiquez quel est votre pseudonyme
- (« nick »). Mettez « cloak » quelque part dans le
- sujet. Votre pseudonyme devra être enregistré : <url
- id="http://freenode.net/faq.shtml#nicksetup" name="Page de
- configuration des pseudonymes">. Le courriel doit être signé par une
- clé du porte-clés Debian. Veuillez consulter la <url
- id="http://freenode.net/faq.shtml#projectcloak" name="documentation de
- Freenode"> pour plus d'informations sur les uniformes.
- </p>
- </sect>
- <sect id="doc-rsrcs">
- <heading>
- Documentation
- </heading>
- <p>
- Ce document contient beaucoup d'informations très utiles aux
- développeurs Debian, mais il ne peut pas tout contenir. La plupart des
- autres documents intéressants sont référencés dans le <url
- id="&url-devel-docs;" name="coin du développeur Debian">. Prenez le
- temps de parcourir tous les liens, vous apprendrez encore beaucoup de
- choses.
- </p>
- </sect>
- <sect id="server-machines">
- <heading>
- Les serveurs Debian
- </heading>
- <p>
- Debian possède plusieurs ordinateurs employés comme serveurs, dont la
- plupart hébergent les fonctions critiques du projet Debian. La plupart
- des machines sont utilisées pour des activités de portage et elles ont
- toutes un accès permanent à Internet.
- </p>
- <p>
- La plupart des machines peuvent être utilisées par les développeurs
- tant qu'ils respectent les règles définies dans la <url id="&url-dmup;"
- name="charte d'utilisation des machines Debian">.
- </p>
- <p>
- Dans l'ensemble, vous pouvez faire usage de ces machines pour des buts
- relatifs à Debian comme vous l'entendez. Veuillez cependant être gentil
- avec les administrateurs système et ne pas utiliser de grandes
- quantités d'espace disque, de ressource réseau ou CPU sans obtenir
- auparavant l'accord des administrateurs. Habituellement, ces machines
- sont administrées par des volontaires.
- </p>
- <p>
- Veuillez prendre soin de votre mot de passe Debian ainsi que des clés
- SSH installées sur les machines Debian. Évitez les méthodes de
- connexion ou d'envoi de données qui envoient les mots de passe en clair
- par l'Internet comme telnet, FTP, POP, etc.
- </p>
- <p>
- Veuillez ne pas déposer de données non relatives à Debian sur les
- serveurs Debian à moins que vous n'ayez préalablement obtenu la
- permission de le faire.
- </p>
- <p>
- La liste actuelle des machines Debian est disponible à <url
- id="&url-devel-machines;">. Cette page web contient les noms des
- machines, les informations de contact, les informations sur qui peut
- s'y connecter, les clés SSH, etc.
- </p>
- <p>
- Si vous avez un problème en utilisant un serveur Debian et si vous
- estimez que les administrateurs système devraient en être avertis,
- l'équipe des administrateurs système peut être jointe à
- <email>debian-admin@lists.debian.org</email>.
- </p>
- <p>
- Si votre problème est lié à un certain service ou n'est pas lié au
- système (paquet à supprimer de l'archive ou suggestion pour le site web
- par exemple), il vous faudra en général ouvrir un rapport de bogue sur
- un « pseudo-paquet ». Reportez-vous à la section <ref
- id="submit-bug"> pour connaître la procédure à suivre.
- </p>
- <p>
- Certains des serveurs de base sont à accès restreint, mais les
- informations de ceux-ci sont fournies par d'autres serveurs miroirs.
- </p>
- <sect1 id="servers-bugs">
- <heading>
- Le serveur pour les rapports de bogues
- </heading>
- <p>
- <tt>&bugs-host;</tt> est le serveur maître du système de suivi des
- bogues (BTS<footnote><p>Système de suivi des bogues se dit <em>Bug
- Tracking System</em> en anglais</p></footnote>).
- </p>
- <p>
- Ce serveur est à accès restreint ; un miroir est disponible sur
- <tt>merkel</tt>.
- </p>
- <p>
- Si vous envisagez de manipuler les rapports de bogue ou d'en faire une
- analyse statistique, ce sera le bon endroit pour le faire. Informez la
- liste &email-debian-devel; de votre intention avant d'implémenter quoi
- que ce soit afin d'éviter un travail en double ou un gaspillage de
- temps machine.
- </p>
- </sect1>
- <sect1 id="servers-ftp-master">
- <heading>
- Le serveur ftp-master
- </heading>
- <p>
- Le serveur <tt>ftp-master.debian.org</tt> est le serveur maître de
- l'archive Debian (exception faite des paquets non-US). En général, les
- mises à jour de paquets se font sur ce serveur. Reportez-vous à la
- section <ref id="upload"> pour en savoir plus.
- </p>
- <p>
- Ce serveur est à accès restreint ; un miroir est disponible sur
- <tt>merkel</tt>.
- </p>
- <p>
- Les problèmes avec l'archive Debian FTP doivent généralement être
- rapportés comme bogues sur le pseudo-paquet
- <package>ftp.debian.org</package> ou par courrier électronique à
- &email-ftpmaster; ; reportez-vous à la section <ref
- id="archive-manip"> pour connaître la procédure à suivre.
- </p>
- </sect1>
- <sect1 id="servers-non-us">
- <heading>
- Le serveur non-US
- </heading>
- <p>
- Le serveur non-US <tt>non-us.debian.org</tt> a été interrompu avec la
- publication de <em>Sarge</em>. Le pseudo-paquet
- <package>nonus.debian.org</package> existe encore pour le moment.
- </p>
- </sect1>
- <sect1 id="servers-www">
- <heading>
- Le serveur www-master
- </heading>
- <p>
- Le serveur web principal est <tt>www-master.debian.org</tt>. Il
- héberge les pages web officielles, la façade de Debian pour la plupart
- des débutants.
- </p>
- <p>
- Si vous rencontrez un problème avec un serveur web Debian, vous devez
- généralement envoyer un rapport de bogue sur le pseudo-paquet
- <package>www.debian.org</package>. Vérifiez d'abord sur le <url
- id="http://&bugs-host;/www.debian.org" name="système de suivi des
- bogues"> que personne ne l'a déjà rapporté avant vous.
- </p>
- </sect1>
- <sect1 id="servers-people">
- <heading>
- Le serveur web people
- </heading>
- <p>
- <tt>people.debian.org</tt> est le serveur utilisé par les développeurs
- pour leurs pages concernant Debian.
- </p>
- <p>
- Si vous avez des informations spécifiques Debian que vous voulez
- rendre disponibles sur le web, vous pouvez le faire en les plaçant
- dans le répertoire <file>public_html</file> de votre répertoire
- personnel sur <tt>people.debian.org</tt>. Elles seront accessibles à
- l'adresse
- <tt>http://people.debian.org/~<var>votre-user-id</var>/</tt>.
- </p>
- <p>
- Vous ne devriez utiliser que cet emplacement particulier car il sera
- sauvegardé alors que sur les autres serveurs, ce ne sera pas le cas.
- </p>
- <p>
- Habituellement, la seule raison pour utiliser un serveur différent est
- que vous avez besoin de publier des informations soumises aux
- restrictions d'exportation américaines, dans ce cas, vous pouvez
- utiliser l'un des autres serveurs situés en dehors des États-Unis.
- </p>
- <p>
- Veuillez envoyer un courrier à &email-debian-devel; si vous avez une
- question.
- </p>
- </sect1>
- <sect1 id="servers-cvs">
- <heading>
- Le serveur CVS
- </heading>
- <p>
- Notre serveur CVS est situé sur <tt>cvs.debian.org</tt>.
- </p>
- <p>
- Si vous avez besoin d'un serveur CVS accessible par tous pour, par
- exemple, coordonner le travail de plusieurs développeurs sur un
- paquet, vous pouvez demander un espace CVS sur ce serveur.
- </p>
- <p>
- Le serveur <tt>cvs.debian.org</tt> autorise les accès CVS locaux, les
- accès en lecture seule pour les connexions client-serveur anonymes et
- les accès client-serveur complets pour les connexions
- <prgn>ssh</prgn>. L'espace CVS peut aussi être consulté par la toile à
- l'adresse <url id="&url-cvsweb;">.
- </p>
- <p>
- Pour obtenir un espace CVS, envoyez une demande à l'adresse
- &email-debian-admin; en précisant le nom de l'espace, le compte Debian
- propriétaire du répertoire racine et pourquoi vous en avez besoin.
- </p>
- </sect1>
- <sect1 id="dchroot">
- <heading>
- Chroots de différentes distributions
- </heading>
- <p>
- Sur certaines machines, des chroots de différentes distributions sont
- disponibles. Vous pouvez les utiliser comme ceci :
- <example>
-vore% dchroot unstable
-Executing shell in chroot: /org/vore.debian.org/chroots/user/unstable
-</example>
- Dans tous les chroots, les répertoires normaux des utilisateurs sont
- disponibles. Vous pouvez trouver quels chroots sont disponibles à
- <tt>&url-devel-machines;</tt>.
- </p>
- </sect1>
- </sect>
- <sect id="devel-db">
- <heading>
- La base de données des développeurs
- </heading>
- <p>
- La base de données des développeurs à <url id="&url-debian-db;"> est un
- annuaire LDAP de gestion des informations des développeurs Debian. Vous
- pouvez utiliser cette ressource pour rechercher la liste des
- développeurs Debian. Une partie de ces informations est également
- disponible à travers le service <prgn>finger</prgn> sur les serveurs
- Debian, essayez <prgn>finger yourlogin@debian.org</prgn> pour voir ce
- qu'il indique.
- </p>
- <p>
- Les développeurs peuvent <url id="&url-debian-db-login;" name="se
- connecter à la base de données"> pour modifier différentes informations
- les concernant, comme :
- <list>
- <item>
- <p>
- l'adresse de suivi pour leur adresse debian.org,
- </p>
- </item>
- <item>
- <p>
- l'abonnement à debian-private,
- </p>
- </item>
- <item>
- <p>
- l'état en vacances ou non,
- </p>
- </item>
- <item>
- <p>
- des informations personnelles comme les adresse, pays, latitude et
- longitude de l'endroit où ils vivent pour utilisation dans la <url
- id="http://www.debian.org/devel/developers.loc" name="carte mondiale
- des développeurs Debian">, numéros de téléphone et de fax, surnom
- IRC et page web,
- </p>
- </item>
- <item>
- <p>
- le mot de passe et le shell préféré sur les machines du projet
- Debian.
- </p>
- </item>
- </list>
- </p>
- <p>
- La plupart des informations ne sont naturellement pas accessibles
- publiquement. Pour plus d'informations, veuillez lire la documentation
- en ligne que vous pouvez trouver à <url id="&url-debian-db-doc;">.
- </p>
- <p>
- Les développeurs peuvent également envoyer leurs clés SSH pour qu'elles
- soient utilisées pour autorisation sur les machines Debian officielles
- et même ajouter de nouvelles entrées DNS du type *.debian.net. Ces
- fonctionnalités sont documentées à <url id="&url-debian-db-mail-gw;">.
- </p>
- </sect>
- <sect id="archive">
- <heading>
- L'archive Debian
- </heading>
- <p>
- La distribution &debian-formal; est composée d'un grand nombre de
- paquets (fichiers <tt>.deb</tt> : actuellement, à peu près
- &number-of-pkgs;) et de quelques autres fichiers (comme la
- documentation et des images des disquettes d'installation).
- </p>
- <p>
- Voici un exemple d'arborescence pour une archive Debian complète :
- </p>
- <p>
- &sample-dist-dirtree;
-
- </p>
- <p>
- Comme vous pouvez le voir, le répertoire racine contient deux
- répertoires, <file>dists/</file> et <file>pool/</file>. Le second est
- un ensemble de répertoires où sont stockés les paquets. Ceux-ci sont
- manipulés grâce à la base de données de l'archive et aux logiciels qui
- l'accompagnent. Le premier répertoire contient les distributions
- <em>stable</em>, <em>testing</em> et <em>unstable</em>. Les fichiers
- <file>Packages</file> et <file>Sources</file> qui se trouvent dans les
- répertoires de distribution peuvent faire référence à des fichiers du
- répertoire <file>pool/</file>. Le découpage en sous-répertoires est
- identique d'un répertoire de distribution à l'autre . Ce que nous
- exposerons ci-dessous pour la distribution <em>stable</em> est
- également applicable aux distributions <em>unstable</em> et
- <em>testing</em>.
- </p>
- <p>
- Le répertoire <file>dists/stable</file> contient trois répertoires
- nommés <file>main</file>, <file>contrib</file> et
- <file>non-free</file>.
- </p>
- <p>
- Dans chacune de ces sections, se trouve un répertoire contenant les
- paquets sources (<file>source/</file>) et un répertoire pour chaque
- architecture acceptée (<file>binary-i386/</file>,
- <file>binary-m68k/</file>, etc.).
- </p>
- <p>
- La section <em>main</em> contient d'autres répertoires destinés aux
- images de disquettes et à plusieurs documents essentiels pour installer
- la distribution Debian sur une architecture particulière
- (<file>disk-i386/</file>, <file>disk-m68k/</file>, etc.).
- </p>
- <sect1 id="archive-sections">
- <heading>
- Les sections
- </heading>
- <p>
- La section <em>main</em> constitue la <strong>distribution
- &debian-formal; officielle</strong>. Elle est officielle parce qu'elle
- est entièrement conforme à toutes nos recommandations. Les deux autres
- sections divergent de ces recommandations à différents degrés, elles
- <strong>ne</strong> font donc <strong>pas</strong> officiellement
- partie de &debian-formal;.
- </p>
- <p>
- Chaque paquet de la section <em>main</em> doit être conforme aux <url
- id="&url-dfsg;" name="directives Debian pour le logiciel
- libre"><footnote><p>Debian Free Software Guidelines</p></footnote> et
- à toutes les autres recommandations décrites dans <url
- id="&url-debian-policy;" name="la charte Debian"><footnote><p>Debian
- Policy Manual</p></footnote>. Les DFSG<footnote><p><em>Debian Free
- Software Guidelines</em></p></footnote> constituent notre définition
- de « logiciel libre ». Reportez-vous à la <em>charte
- Debian</em> pour en savoir plus.
- </p>
- <p>
- Les paquets de la section <em>contrib</em> doivent être conformes aux
- DFSG, mais ne respectent pas d'autres contraintes. Ils peuvent, par
- exemple, dépendre de paquets de la section <em>non-free</em>.
- </p>
- <p>
- Les paquets qui ne sont pas conformes aux DFSG sont rangés dans la
- section <em>non-free</em>. Bien que nous supportions l'usage de ces
- paquets et qu'ils bénéficient de nos infrastructures (système de suivi
- des bogues, listes de diffusion, etc.), ces paquets <em>non-free</em>
- ne font pas partie de la distribution Debian.
- </p>
- <p>
- La <em>charte Debian</em> donne des définitions plus précises pour ces
- trois sections. Les paragraphes précédents ne constituent qu'une
- introduction.
- </p>
- <p>
- La séparation de l'archive en trois sections est importante pour toute
- personne qui désire distribuer Debian, que ce soit par serveur FTP ou
- sur cédérom. Il suffit de distribuer les sections <em>main</em> et
- <em>contrib</em> pour éviter tout problème légal. Certains paquets de
- la section <em>non-free</em> interdisent leur distribution à titre
- commercial par exemple.
- </p>
- <p>
- D'un autre côté, un distributeur de cédérom pourra facilement vérifier
- la licence de chacun des paquets de la section <em>non-free</em> et
- inclure tous les paquets qu'il lui sera autorisé (dans la mesure où
- cela varie énormément d'un distributeur à l'autre, ce travail ne peut
- être fait par les développeurs Debian).
- </p>
- <p>
- Notez que le terme « section » est également utilisé pour
- faire référence aux catégories qui simplifient l'organisation des
- paquets disponibles et leur recherche, e.g. <em>admin</em>,
- <em>net</em>, <em>utils</em> etc. Il fut un temps où ces sections
- (sous-sections, plutôt) existaient sous la forme de sous-répertoires
- dans l'archive Debian. Actuellement, elles n'existent plus que dans le
- champ en-tête « Section » des paquets.
- </p>
- </sect1>
- <sect1>
- <heading>
- Les architectures
- </heading>
- <p>
- À ses débuts, le noyau Linux existait uniquement pour les
- architectures Intel x86 ; il en était de même pour Debian. Linux
- devenant de plus en plus populaire, il a été porté vers d'autres
- architectures.
- </p>
- <p>
- Le noyau 2.0 existe pour les architectures Intel x86, DEC Alpha,
- SPARC, Motorola, 680x0 (Atari, Amiga, et Macintosh), MIPS et
- PowerPC. Le noyau 2.2 reconnaît de nouvelles architectures, comme ARM
- et UltraSPARC. Puisque Linux reconnaît ces architectures, le projet
- Debian a décidé qu'il devait également les accepter. C'est pourquoi
- plusieurs portages sont en cours ; en fait, il y a aussi des
- portages vers d'autres noyaux non-Linux. À côté d'<em>i386</em> (notre
- nom pour Intel x86), nous avons, au moment où j'écris, <em>m68k</em>,
- <em>alpha</em>, <em>powerpc</em>, <em>sparc</em>, <em>hurd-i386</em>,
- <em>arm</em>, <em>ia64</em>, <em>hppa</em>, <em>s390</em>,
- <em>mips</em>, <em>mipsel</em> et <em>sh</em>.
- </p>
- <p>
- &debian-formal; 1.3 est disponible uniquement pour
- <em>i386</em>. Debian 2.0 reconnaît les architectures <em>i386</em> et
- <em>m68k</em>. Debian 2.1 reconnaît les architectures <em>i386</em>,
- <em>m68k</em>, <em>alpha</em> et <em>sparc</em>. Debian 2.2 accepte en
- plus les architectures <em>powerpc</em> et <em>arm</em>. Debian 3.0 a
- ajouté cinq nouvelles architectures : <em>ia64</em>,
- <em>hppa</em>, <em>s390</em>, <em>mips</em> et <em>mipsel</em>.
- </p>
- <p>
- Pour chaque portage, vous trouverez des informations destinées aux
- développeurs et utilisateurs sur la page <url id="&url-debian-ports;"
- name="Portage Debian">.
- </p>
- </sect1>
- <sect1>
- <heading>
- Les paquets
- </heading>
- <p>
- Il existe deux types de paquets Debian : les paquets sources et
- les paquets binaires.
- </p>
- <p>
- Les paquets sources sont constitués de deux ou trois fichiers :
- un fichier <file>.dsc</file> et soit un fichier <file>.tar.gz</file>,
- soit un fichier <file>.orig.tar.gz</file> et un fichier
- <file>.diff.gz</file>.
- </p>
- <p>
- Si un paquet est développé spécifiquement pour le projet Debian et
- n'est pas distribué en dehors de Debian, il n'y a qu'un fichier
- <file>.tar.gz</file> qui contient les sources du programme. Si un
- paquet est distribué ailleurs, le fichier <file>.orig.tar.gz</file>
- contient ce que l'on appelle <em>code source amont</em>, c'est-à-dire,
- le code source distribué par le <em>responsable amont</em> (il s'agit
- souvent de l'auteur du logiciel). Dans ce cas, le fichier
- <file>.diff.gz</file> contient les modifications faites par le
- responsable Debian.
- </p>
- <p>
- Le fichier <file>.dsc</file> liste tous les fichiers sources avec
- leurs sommes de contrôle (<prgn>md5sums</prgn>) et quelques
- informations supplémentaires concernant le paquet (responsable,
- version, etc.).
- </p>
- </sect1>
- <sect1>
- <heading>
- Les distributions
- </heading>
- <p>
- L'organisation des répertoires présentée précédemment est elle-même
- englobée par les <em>répertoires des distributions</em>. Chaque
- distribution est incluse dans le répertoire <file>pool</file> à la
- racine de l'archive Debian.
- </p>
- <p>
- Pour résumer, une archive Debian a un répertoire racine sur un serveur
- FTP. Par exemple, sur le site miroir
- <ftpsite>ftp.us.debian.org</ftpsite>, l'archive Debian se trouve dans
- <ftppath>/debian</ftppath> ce qui est un emplacement courant. Un autre
- emplacement courant est <file>/pub/debian</file>.
- </p>
- <p>
- Une distribution est composée de paquets sources et binaires et des
- fichiers <file>Sources</file> et <file>Packages</file> correspondants
- qui contiennent toutes les méta-informations sur les paquets. Les
- premiers sont conservés dans le répertoire <file>pool/</file> tandis
- que les seconds sont conservés dans le répertoire <file>dists/</file>
- de l'archive (pour compatibilité descendante).
- </p>
- <sect2 id="sec-dists">
- <heading>
- <em>Stable</em>, <em>testing</em> et <em>unstable</em>
- </heading>
- <p>
- Il y a toujours une distribution appelée <em>stable</em> (dans le
- répertoire <file>dists/stable</file>), une distribution appelée
- <em>testing</em> (dans le répertoire <file>dists/testing</file>) et
- une distribution appelée <em>unstable</em> (dans le répertoire
- <file>dists/unstable</file>). Ceci reflète le processus de
- développement du projet Debian.
- </p>
- <p>
- Les développements se font sur la distribution
- <em>unstable</em><footnote><p><em>unstable</em> signifie
- « instable »</p></footnote> (c'est pourquoi elle est aussi
- appelée <em>distribution de développement</em>). Chaque développeur
- Debian peut modifier ses paquets à tout moment dans cette
- distribution. Ainsi son contenu change tous les jours. Comme aucun
- effort particulier n'est fait pour s'assurer que tout fonctionne
- correctement dans cette distribution, elle est parfois littéralement
- « instable ».
- </p>
- <p>
- La distribution <qref id="testing">« testing »</qref> est
- générée automatiquement en prenant les paquets d'<em>unstable</em>
- s'ils satisfont à certains critères. Ces critères garantissent que
- les paquets de <em>testing</em> sont de bonne qualité. La mise à jour
- de <em>testing</em> est lancée chaque jour après que les nouveaux
- paquets ont été installés. Voir <ref id="testing">.
- </p>
- <p>
- Après une période de développement, quand le responsable de
- distribution<footnote><p><em>Release manager</em></p></footnote> le
- juge opportun, la distribution <em>testing</em> est gelée, ce qui
- signifie que les conditions à remplir pour qu'un paquet passe
- d'<em>unstable</em> à <em>testing</em> sont durcies. Les paquets trop
- bogués sont supprimés et les seules mises à jours autorisées
- concernent les corrections de bogues. Après quelque temps, selon
- l'avancement, la distribution <em>testing</em> est gelée encore
- plus. Les détails de la gestion de la distribution <em>testing</em>
- sont publiées par l'équipe de publication sur la liste
- debian-devel-announce. Après la résolution des problèmes restants à
- la satisfaction de l'équipe de publication, la distribution est
- publiée. La publication veut dire que <em>testing</em> est renommée
- en <em>stable</em>, une nouvelle copie est créée pour la nouvelle
- <em>testing</em> et l'ancienne <em>stable</em> est renommée en
- <em>oldstable</em> et y reste jusqu'à ce qu'elle soit finalement
- archivée. Lors de l'archivage, son contenu est déplacé sur
- <tt>&archive-host;</tt>.
- </p>
- <p>
- Ce cycle de développement est basé sur l'idée que la distribution
- <em>unstable</em> devient <em>stable</em> après une période de test
- (<em>testing</em>). Une distribution contient inévitablement des
- bogues, même si elle est classée stable. C'est pourquoi les
- distributions stables sont mises à jour de temps en temps. Les
- corrections introduites sont testées avec une grande attention et
- sont ajoutées une à une à l'archive pour diminuer les risques
- d'introduire de nouveaux bogues. Vous pouvez trouver des paquets
- proposés pour les mises à jour de <em>stable</em> dans le répertoire
- <file>proposed-updates</file>. De temps en temps, les paquets de ce
- répertoire qui ne présentent pas de problème sont installés dans la
- distribution <em>stable</em> et le numéro de révision de cette
- distribution est incrémenté (« 3.0 » devient
- « 3.0r1 », « 2.2r4 » devient « 2.2r5 »
- et ainsi de suite). Veuillez vous référer aux <qref
- id="upload-stable">envois dans la distribution <em>stable</em></qref>
- pour plus de détails.
- </p>
- <p>
- Notez que, pendant la période de gel, les développements continuent
- sur la distribution <em>unstable</em> car cette distribution reste en
- place.
- </p>
- </sect2>
- <sect2>
- <heading>
- Informations complémentaires sur la distribution
- « testing »
- </heading>
- <p>
- Les paquets sont habituellement installés dans la distribution
- <em>testing</em> après avoir atteint un certain degré de test dans
- <em>unstable</em>.
- </p>
- <p>
- Pour plus de détails, veuillez consulter les <qref
- id="testing">informations à propos de la distribution
- <em>testing</em></qref>.
- </p>
- </sect2>
- <sect2 id="experimental">
- <heading>
- Experimental
- </heading>
- <p>
- La distribution <em>experimental</em> est une distribution
- particulière. Ce n'est pas une distribution à part entière comme le
- sont <em>stable</em> et <em>unstable</em>. Elle est prévue pour
- servir de plate-forme de développement pour les projets expérimentaux
- qui risquent vraiment de détruire le système ou bien pour des
- logiciels qui sont vraiment trop instables pour être inclus dans la
- distribution <em>unstable</em> (mais pour lesquels une mise en paquet
- est justifiée). Les utilisateurs qui téléchargent et installent des
- paquets depuis <em>experimental</em> sont prévenus : on ne peut
- pas faire confiance à la distribution <em>experimental</em>.
- </p>
- <p>
- Voici les lignes de <manref section="5" name="sources.list"> pour
- <em>experimental</em> :
- <example>
-deb http://ftp.<var>xy</var>.debian.org/debian/ experimental main
-deb-src http://ftp.<var>xy</var>.debian.org/debian/ experimental main
-</example>
- </p>
- <p>
- Si un logiciel peut causer des dégâts importants, il sera sûrement
- préférable de le mettre dans la distribution
- <em>experimental</em>. Un système de fichiers compacté expérimental,
- par exemple, devrait probablement aller dans <em>experimental</em>.
- </p>
- <p>
- Une nouvelle version amont qui ajoute de nouvelles fonctions tout en
- supprimant de nombreuses autres ne devra pas être téléchargée dans
- l'archive Debian, elle pourra cependant être téléchargée dans
- <em>experimental</em>. Une nouvelle version non finalisée d'un
- logiciel qui utilise une méthode de configuration complètement
- différente pourrait aller dans <em>experimental</em> au gré du
- responsable. Si vous travaillez sur un cas de mise à jour complexe ou
- incompatible, vous pouvez aussi utiliser <em>experimental</em> comme
- plate-forme d'intégration et ainsi fournir un accès aux testeurs.
- </p>
- <p>
- Quelques logiciels expérimentaux peuvent cependant aller dans
- <em>unstable</em>, avec un avertissement dans la description, mais ce
- n'est pas recommandé car les paquets d'<em>unstable</em> se propagent
- dans <em>testing</em> et aboutissent dans <em>stable</em>. Vous ne
- devriez pas avoir peur d'utiliser <em>experimental</em> car ceci ne
- cause aucun souci aux ftpmasters, les paquets expérimentaux sont
- automatiquement enlevés quand vous envoyez le paquet dans
- <em>unstable</em> avec un numéro de version supérieur.
- </p>
- <p>
- Un nouveau logiciel qui ne risque pas d'endommager le système ira
- directement dans <em>unstable</em>.
- </p>
- <p>
- Une solution de rechange à <em>experimental</em> consiste à utiliser
- vos pages personnelles sur le serveur <tt>people.debian.org</tt>.
- </p>
- <p>
- Veuillez considérer l'utilisation de l'option <tt>-v</tt> de
- <prgn>dpkg-buildpackage</prgn> si l'envoi d'un paquet dans
- <em>unstable</em> ferme finalement des bogues qui ont d'abord été
- corrigés dans <em>experimental</em>. Lors de l'envoi vers
- <em>unstable</em> d'un paquet contenant des bogues corrigés dans
- <em>experimental</em>, veuillez considérer l'utilisation de l'option
- <tt>-v</tt> de <prgn>dpkg-buildpackage</prgn> pour qu'ils soient
- finalement fermés.
- </p>
- </sect2>
- </sect1>
- <sect1 id="codenames">
- <heading>
- Les noms de distribution
- </heading>
- <p>
- Chaque distribution Debian diffusée a un <em>nom de code</em> :
- Debian 1.1 s'appelle « Buzz » ; Debian 1.2,
- « Rex » ; Debian 1.3, « Bo » ;
- Debian 2.0, « Hamm » ; Debian 2.1,
- « Slink »; Debian 2.2, « Potato » ;
- Debian 3.0, « Woody » ; Debian 3.1,
- « Sarge » ; Debian 4.0,
- « Etch ». Il y a aussi une pseudo-distribution nommée
- « Sid », il s'agit de la distribution
- <em>unstable</em> ; comme les paquets vont d'<em>unstable</em> à
- <em>testing</em> quand ils approchent de la stabilité, la distribution
- « Sid » n'est jamais diffusée. En plus du contenu habituel
- d'une distribution Debian, « Sid » contient des paquets pour
- des architectures qui ne sont pas encore officiellement prises en
- charge ou pour lesquelles la distribution n'a pas encore été
- publiée. Ces architectures seront intégrées ultérieurement à la
- distribution principale.
- </p>
- <p>
- Comme Debian est un projet de développement ouvert (i.e. tout le monde
- peut participer et suivre les développements), même les distributions
- <em>unstable</em> et <em>testing</em> sont disponibles sur les
- serveurs HTTP et FTP de Debian. Si nous avions nommé le répertoire qui
- contient la prochaine distribution à diffuser « testing »,
- il aurait fallu changer son nom en « stable » au moment de
- la publication, ce qui aurait forcé les miroirs FTP à télécharger à
- nouveau la distribution complète (qui est plutôt volumineuse).
- </p>
- <p>
- D'un autre côté, si une distribution s'appelait <em>Debian-x.y</em>
- dès le départ, des personnes pourraient s'imaginer que la distribution
- Debian <em>x.y</em> est disponible. (Cela s'est produit par le passé,
- un distributeur avait gravé des cédéroms Debian 1.0 en utilisant une
- version de développement pré-1.0. C'est pour cette raison que la
- première version officielle était la version 1.1 et non la 1.0).
- </p>
- <p>
- En conséquence, les noms de répertoire des distributions dans
- l'archive sont déterminés par leur nom de code et non par leur statut
- (exemple : slink). Ces noms sont identiques pendant la période de
- développement et une fois la distribution diffusée ; des liens
- symboliques, qui peuvent être modifiés facilement, indiquent la
- distribution stable actuelle. Tout ceci explique pourquoi les
- répertoires des distributions sont nommés à partir des noms de code
- des distributions alors que <em>stable</em>, <em>testing</em> et
- <em>unstable</em> sont des liens symboliques qui pointent vers les
- répertoires appropriés.
- </p>
- </sect1>
- </sect>
- <sect id="mirrors">
- <heading>
- Les miroirs Debian
- </heading>
- <p>
- Les différentes archives de téléchargement et le site web disposent de
- plusieurs miroirs pour soulager les serveurs principaux d'une lourde
- charge. En fait, certains de ces serveurs ne sont pas
- publics — la charge est répartie sur une première série de
- serveurs. De cette façon, les utilisateurs ont toujours accès aux
- miroirs et s'y habituent, ce qui permet à Debian de mieux répartir les
- besoins en bande passante sur plusieurs serveurs et plusieurs réseaux
- différents et évite aux utilisateurs de surcharger l'emplacement
- primaire. Notez que, dans cette première série, les serveurs sont aussi
- à jour que possible car la mise à jour est déclenchée par les sites
- maîtres internes.
- </p>
- <p>
- Toutes les informations sur les miroirs Debian peuvent être trouvées à
- <url id="&url-debian-mirrors;">, y compris une liste des miroirs
- publics disponibles FTP/HTTP. Cette page utile inclut également des
- informations et des outils pour créer son propre miroir, soit en
- interne soit pour un accès public.
- </p>
- <p>
- Les miroirs sont en général mis en œuvre par des tiers qui
- veulent aider Debian. C'est pourquoi les développeurs n'ont en général
- pas de compte sur ces machines.
- </p>
- </sect>
- <sect id="incoming-system">
- <heading>
- Le système Incoming
- </heading>
- <p>
- Le système Incoming est responsable de la collecte des paquets mis à
- jour et de leur installation dans l'archive Debian. Il est constitué
- d'un ensemble de répertoires et de scripts qui sont installés sur
- <tt>&ftp-master-host;</tt>.
- </p>
- <p>
- Les paquets sont envoyés par tous les responsables Debian dans un
- répertoire nommé <file>UploadQueue</file>. Ce répertoire est parcouru
- toutes les quelques minutes par un démon appelé <prgn>queued</prgn>,
- les fichiers <file>*.command</file> sont exécutés et les fichiers
- <file>*.changes</file> restants et correctement signés sont déplacés
- avec leurs fichiers correspondants dans le répertoire
- <file>unchecked</file>. Ce répertoire n'est pas visible de la plupart
- des développeurs car ftp-master est à accès restreint ; il est
- parcouru toutes les 15 minutes par le script <prgn>katie</prgn> qui
- vérifie l'intégrité des paquets envoyés et leurs signatures de
- chiffrage. Si le paquet est considéré comme prêt à être installé, il
- est déplacé dans le répertoire <file>accepted</file>. S'il s'agit du
- premier envoi du paquet (ou s'il a de nouveaux paquets binaire), il est
- déplacé dans le répertoire <file>new</file> où il attend l'approbation
- des ftpmasters. Si le paquet contient des fichiers devant être
- installés <em>à la main</em>, il est déplacé dans le répertoire
- <file>byhand</file> où il attend une installation manuelle par les
- ftpmasters. Sinon, si une erreur a été détectée, le paquet est refusé
- et il est déplacé dans le répertoire <file>reject</file>.
- </p>
- <p>
- Une fois que le paquet est accepté, le système envoie une confirmation
- par courrier au responsable et ferme les bogues corrigés par l'envoi,
- puis les compilateurs automatiques peuvent commencer la
- recompilation. Le paquet est maintenant accessible publiquement à <url
- id="&url-incoming;"> jusqu'à ce qu'il soit vraiment installé dans
- l'archive Debian. Cela se produit seulement une fois par jour (et c'est
- également appelé une « exécution dinstall » pour des raisons
- historiques) ; le paquet est alors supprimé de
- <file>Incoming</file> et installé dans le pool avec les autres
- paquets. Une fois que toutes les autres mises à jour (fabrication des
- nouveaux fichiers d'index <file>Packages</file> et <file>Sources</file>
- par exemple) ont été effectuées, un script spécial est appelé pour
- demander aux miroirs primaires de se mettre à jour.
- </p>
- <p>
- Le logiciel de maintenance de l'archive enverra également le fichier
- <file>.changes</file> signé avec OpenPGP/GnuPG que vous avez envoyé, à
- la liste de diffusion appropriée. Si un paquet est diffusé avec le
- champ <tt>Distribution:</tt> positionné à « stable »,
- l'annonce sera envoyée à &email-debian-changes;. Si un paquet est
- diffusé avec le champ <tt>Distribution:</tt> positionné à
- « unstable » ou « experimental », l'annonce sera à
- la place envoyée à &email-debian-devel-changes;.
- </p>
- <p>
- Bien que ftp-master soit à accès restreint, une copie de l'installation
- est disponible à tous les développeurs sur
- <tt>&ftp-master-mirror;</tt>.
- </p>
- </sect>
- <sect id="pkg-info">
- <heading>
- Informations sur un paquet
- </heading>
- <p>
- </p>
- <sect1 id="pkg-info-web">
- <heading>
- Sur le web
- </heading>
- <p>
- Chaque paquet a plusieurs pages web
- dédiées. <tt>http://&packages-host;/<var>nom-paquet</var></tt> affiche
- chaque version du paquet disponible dans les différentes
- distributions. Les informations détaillées par version incluent la
- description du paquet, les dépendances et des liens pour télécharger
- le paquet.
- </p>
- <p>
- Le système de suivi des bogues trie les bogues par paquet. Vous pouvez
- regarder les bogues de chaque paquet à
- <tt>http://&bugs-host;/<var>nom-paquet</var></tt>.
- </p>
- </sect1>
- <sect1 id="madison">
- <heading>
- L'outil <prgn>madison</prgn>
- </heading>
- <p>
- <prgn>madison</prgn> est un outil en ligne de commande qui est
- disponible sur <tt>&ftp-master-host;</tt> et sur le miroir
- <tt>&ftp-master-mirror;</tt>. Il utilise un seul paramètre qui
- correspond au nom du paquet. Il affiche comme résultat quelle version
- du paquet est disponible pour chaque combinaison d'architecture et de
- distribution. Un exemple l'expliquera mieux.
- </p>
- <p>
- <example>
-$ madison libdbd-mysql-perl
-libdbd-mysql-perl | 1.2202-4 | stable | source, alpha, arm, i386, m68k, powerpc, sparc
-libdbd-mysql-perl | 1.2216-2 | testing | source, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
-libdbd-mysql-perl | 1.2216-2.0.1| testing | alpha
-libdbd-mysql-perl | 1.2219-1 | unstable | source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
-</example>
- </p>
- <p>
- Dans cet exemple, vous pouvez voir que la version dans
- <em>unstable</em> diffère de celle de <em>testing</em> et qu'il y a eu
- une NMU binaire seulement pour l'architecture alpha. Chaque version du
- paquet a été recompilée sur la plupart des architectures.
- </p>
- </sect1>
- </sect>
- <sect id="pkg-tracking-system">
- <heading>
- Système de suivi des paquets
- </heading>
- <p>
- Le système de suivi des paquets (PTS)<footnote><p>« Package
- Tracking System »</p></footnote> est un outil pour suivre par
- courrier l'activité concernant un paquet source. Cela veut vraiment
- dire que vous pourrez recevoir les mêmes courriers que le responsable,
- simplement en vous inscrivant au paquet dans le PTS.
- </p>
- <p>
- Chaque courrier envoyé par le PTS est classé sous l'un des mots-clés
- listés ci-dessous. Ceci vous permettra de sélectionner les courriers
- que vous voulez recevoir.
- </p>
- <p>
- Par défaut, vous recevrez :
- <taglist>
- <tag>
- <tt>bts</tt>
- </tag>
- <item>
- <p>
- Tous les rapports de bogue et les discussions qui suivent.
- </p>
- </item>
- <tag>
- <tt>bts-control</tt>
- </tag>
- <item>
- <p>
- Les courriers de notification de
- <email>control@bugs.debian.org</email> sur les changement d'état de
- l'un des rapports de bogue.
- </p>
- </item>
- <tag>
- <tt>upload-source</tt>
- </tag>
- <item>
- <p>
- Le courrier de notification de <prgn>katie</prgn> quand un paquet
- source envoyé a été accepté.
- </p>
- </item>
- <tag>
- <tt>katie-other</tt>
- </tag>
- <item>
- <p>
- Les autres courriers d'avertissement et d'erreur de
- <prgn>katie</prgn> (comme une incohérence de passage en force pour
- les champs section ou priorité).
- </p>
- </item>
- <tag>
- <tt>default</tt>
- </tag>
- <item>
- <p>
- Tout courrier non automatique envoyé au PTS par les personnes qui
- veulent contacter les inscrits au paquet. Ceci peut être fait en
- envoyant un courrier à
- <tt><var>paquet-source</var>@&pts-host;</tt>. Pour prévenir l'envoi
- de pourriels, tous les courriers envoyés à ces adresses doivent
- contenir l'en-tête <tt>X-PTS-Approved</tt> avec une valeur non vide.
- </p>
- </item>
- <tag>
- <tt>summary</tt>
- </tag>
- <item>
- <p>
- Des courriers de résumé réguliers sur l'état du paquet. Actuellement,
- seule la progression du paquet dans <em>testing</em> est envoyée.
- </p>
- </item>
- </taglist>
- </p>
- <p>
- Vous pouvez également décider de recevoir des informations
- supplémentaires :
- <taglist>
- <tag>
- <tt>upload-binary</tt>
- </tag>
- <item>
- <p>
- Le courrier d'information de <prgn>katie</prgn> quand un paquet
- binaire envoyé est accepté. En d'autres termes, à chaque fois qu'un
- démon de compilation ou un porteur envoie votre paquet pour une
- autre architecture, vous recevez un courrier pour suivre comment
- votre paquet est recompilé pour toutes les architectures.
- </p>
- </item>
- <tag>
- <tt>cvs</tt>
- </tag>
- <item>
- <p>
- Les notifications de modifications CVS<footnote><p><em>CVS
- commits</em></p></footnote> si le responsable a mis en place un
- système pour faire suivre les notifications de modifications vers le
- PTS.
- </p>
- </item>
- <tag>
- <tt>ddtp</tt>
- </tag>
- <item>
- <p>
- Les traductions des descriptions ou des questionnaires debconf
- soumis au Projet de traduction des descriptions de paquets
- Debian<footnote><p><em>Debian Description Translation Project,
- DDTP</em></p></footnote>.
- </p>
- </item>
- <tag>
- <tt>derivatives</tt>
- </tag>
- <item>
- <p>
- Des informations sur les changements effectués sur le paquet dans les
- distributions dérivées (par exemple, Ubuntu).
- </p>
- </item>
- </taglist>
- </p>
- <sect1 id="pts-commands">
- <heading>
- L'interface de courrier du PTS
- </heading>
- <p>
- Vous pouvez contrôler votre (vos) inscription(s) au PTS en envoyant
- différentes commandes à <email>pts@qa.debian.org</email>.
- <taglist>
- <tag>
- <tt>subscribe <paquet source> [<adresse>]</tt>
- </tag>
- <item>
- <p>
- Inscrit <var>adresse</var> aux communications liées au paquet
- source <var>paquet source</var>. L'adresse de l'expéditeur est
- utilisée si le second paramètre n'est pas présent. Si <var>paquet
- source</var> n'est pas un paquet source valide, vous obtiendrez un
- avertissement. Cependant, s'il s'agit d'un paquet binaire valide,
- le PTS vous inscrira pour le paquet source correspondant.
- </p>
- </item>
- <tag>
- <tt>unsubscribe <paquet source> [<adresse>]</tt>
- </tag>
- <item>
- <p>
- Supprime une inscription précédente au paquet source <var>paquet
- source</var> en utilisant l'adresse spécifiée ou l'adresse de
- l'expéditeur si le second paramètre n'est pas rempli.
- </p>
- </item>
- <tag>
- <tt>unsubscribeall [<adresse>]</tt>
- </tag>
- <item>
- <p>
- Supprime toutes les inscriptions précédentes de l'adresse spécifiée
- ou de l'adresse de l'expéditeur si le second paramètre n'est pas
- rempli.
- </p>
- </item>
- <tag>
- <tt>which [<adresse>]</tt>
- </tag>
- <item>
- <p>
- Liste les inscriptions pour l'expéditeur ou pour l'adresse indiquée
- si elle est spécifiée.
- </p>
- </item>
- <tag>
- <tt>keyword [<adresse>]</tt>
- </tag>
- <item>
- <p>
- Donne les mots-clés que vous acceptez. Pour une explication des ces
- mots-clés, <qref id="pkg-tracking-system">voir
- ci-dessus</qref>. Voici un rapide résumé :
- <list>
- <item>
- <p>
- <tt>bts</tt> : courriers venant du système de gestion de
- bogues (BTS) Debian
- </p>
- </item>
- <item>
- <p>
- <tt>bts-control</tt> : réponses aux courriers envoyés à
- &bugs-host;&email-bts-control;
- </p>
- </item>
- <item>
- <p>
- <tt>summary</tt> : courriers de résumé automatique sur
- l'état d'un paquet
- </p>
- </item>
- <item>
- <p>
- <tt>cvs</tt> : notifications de modifications CVS
- </p>
- </item>
- <item>
- <p>
- <tt>ddtp</tt> : traductions des descriptions et
- questionnaires debconf
- </p>
- </item>
- <item>
- <p>
- <tt>derivatives</tt> : changements effectués sur le paquet
- dans des distributions dérivées
- </p>
- </item>
- <item>
- <p>
- <tt>upload-source</tt> : annonce d'un nouvel envoi de
- paquet source qui a été accepté
- </p>
- </item>
- <item>
- <p>
- <tt>upload-binary</tt> : annonce d'un nouvel envoi de
- binaire seulement (portage)
- </p>
- </item>
- <item>
- <p>
- <tt>katie-other</tt> : autres courriers des ftpmasters
- (incohérence de passage en force, etc.)
- </p>
- </item>
- <item>
- <p>
- <tt>default</tt> : tous les autres courriers (ceux qui ne
- sont pas automatiques)
- </p>
- </item>
- </list>
- </p>
- </item>
- <tag>
- <tt>keyword <paquet source> [<adresse>]</tt>
- </tag>
- <item>
- <p>
- Identique à l'élément précédent, mais pour un paquet source donné
- car vous pouvez sélectionner un ensemble de mots-clés différent
- pour chaque paquet source.
- </p>
- </item>
- <tag>
- <tt>keyword [<adresse>] {+|-|=} <liste de
- mots-clés></tt>
- </tag>
- <item>
- <p>
- Accepte (+) ou refuse (-) les courriers classés sous le(s)
- mot(s)-clé(s). Définit la liste (=) des mots-clés acceptés. Ceci
- change l'ensemble par défaut des mots-clés acceptés par un
- utilisateur.
- </p>
- </item>
- <tag>
- <tt>keywordall [<adresse>] {+|-|=} <liste de
- mots-clés></tt>
- </tag>
- <item>
- <p>
- Accepte (+) ou refuse (-) les courriers classés sous le(s)
- mot(s)-clé(s). Définit la liste (=) des mots-clés acceptés. Ceci
- change les mots-clés de toutes les inscriptions actuellement en cours
- d'un utilisateur.
- </p>
- </item>
- <tag>
- <tt>keyword <paquet source> [<adresse>] {+|-|=}
- <liste de mots-clés></tt>
- </tag>
- <item>
- <p>
- Identique à l'élément précédent, mais remplace la liste des
- mots-clés pour le paquet source indiqué.
- </p>
- </item>
- <tag>
- <tt>quit | thanks | --</tt>
- </tag>
- <item>
- <p>
- Arrête le traitement des commandes. Toutes les lignes suivantes
- sont ignorées par le robot.
- </p>
- </item>
- </taglist>
- </p>
- <p>
- L'utilitaire en ligne de commande <prgn>pts-subscribe</prgn> (du paquet
- <package>devscripts</package>) peut être pratique pour s'inscrire
- temporairement à certains paquets, par exemple après avoir fait une mise
- à jour indépendante (NMU).
- </p>
-
- </sect1>
- <sect1 id="pts-mail-filtering">
- <heading>
- Filtrer les courriers du PTS
- </heading>
- <p>
- Une fois que vous vous êtes inscrit à un paquet, vous recevrez les
- courriers envoyés à <tt><var>paquet
- source</var>@packages.qa.debian.org</tt>. Ces courriers ont des
- en-têtes spéciaux ajoutés pour vous permettre de les filtrer dans des
- boîtes aux lettres (par exemple, avec <prgn>procmail</prgn>). Les
- en-têtes ajoutés sont <tt>X-Loop</tt>, <tt>X-PTS-Package</tt>,
- <tt>X-PTS-Keyword</tt> et <tt>X-Unsubscribe</tt>.
- </p>
- <p>
- Voici un exemple d'en-têtes ajoutés pour une notification d'envoi de
- source sur le paquet <package>dpkg</package> :
- <example>
-X-Loop: dpkg@&pts-host;
-X-PTS-Package: dpkg
-X-PTS-Keyword: upload-source
-X-Unsubscribe: echo 'unsubscribe dpkg' | mail pts@qa.debian.org
-</example>
- </p>
- </sect1>
- <sect1 id="pts-cvs-commit">
- <heading>
- Faire suivre les modifications de CVS vers le PTS
- </heading>
- <p>
- Si vous utilisez un référentiel CVS accessible publiquement pour
- maintenir votre paquet Debian, vous pouvez vouloir faire suivre les
- notifications de modifications vers le PTS pour que les inscrits
- (ainsi que des possibles co-responsables) puissent suivre de près
- l'évolution du paquet.
- </p>
- <p>
- Une fois que votre référentiel génère des notifications de
- modifications, vous devez simplement vous assurer qu'il envoie une
- copie de tous ces courriers à <tt><var>paquet
- source</var>_cvs@&pts-host;</tt>. Seules les personnes qui ont accepté
- le mot-clé <em>cvs</em> recevront les notifications.
- </p>
- </sect1>
- <sect1 id="pts-web">
- <heading>
- L'interface web du PTS
- </heading>
- <p>
- Le PTS possède une interface web à <url id="http://&pts-host;/"> qui
- réunit beaucoup d'informations au même endroit à propos de chaque
- paquet source. Il propose plusieurs liens utiles (BTS, statistiques
- QA, informations de contact, état de traduction DDTP, journaux de
- compilation automatique) et il regroupe beaucoup d'autres informations
- provenant de différents endroits (les 30 dernières entrées de
- changelog, l'état dans <em>testing</em>, etc.). Il s'agit d'un outil
- très pratique si vous désirez connaître ce qu'il en est d'un paquet
- source spécifique. De plus, il y a un formulaire qui permet de
- facilement s'inscrire au PTS par courrier.
- </p>
- <p>
- Vous pouvez aller directement à la page web concernant un paquet
- source avec une URL comme <tt>http://&pts-host;/<var>paquet
- source</var></tt>.
- </p>
- <p>
- Cette interface a été conçue comme un portail pour le développements
- des paquets : vous pouvez ajouter du contenu personnalisé aux
- pages de vos paquets. Vous pouvez ajouter des « informations
- statiques »<footnote><p><em>Static
- information</em></p></footnote> (des annonces qui sont destinées à
- rester disponibles indéfiniment) et des nouvelles dans la section
- « dernières nouvelles »<footnote><p><em>Latest
- news</em></p></footnote>.
- </p>
- <p>
- Les annonces statiques peuvent être utilisées pour indiquer :
- <list>
- <item>
- <p>
- la disponibilité d'un projet hébergé sur <qref
- id="alioth">Alioth</qref> pour la co-maintenance du paquet,
- </p>
- </item>
- <item>
- <p>
- un lien vers le site web amont,
- </p>
- </item>
- <item>
- <p>
- un lien vers le suivi de bogues amont,
- </p>
- </item>
- <item>
- <p>
- l'existence d'un canal IRC dédié au logiciel,
- </p>
- </item>
- <item>
- <p>
- toute autre ressource disponible qui peut être utile à la
- maintenance du paquet.
- </p>
- </item>
- </list>
- Les nouvelles usuelles peuvent être utilisées pour annoncer que :
- <list>
- <item>
- <p>
- des paquets bêta sont disponibles pour test,
- </p>
- </item>
- <item>
- <p>
- des paquets finaux sont attendus pour la semaine prochaine,
- </p>
- </item>
- <item>
- <p>
- l'empaquetage est sur le point d'être intégralement refait,
- </p>
- </item>
- <item>
- <p>
- des rétroportages sont disponibles,
- </p>
- </item>
- <item>
- <p>
- le responsable est en vacance (s'il désire publier cette
- information),
- </p>
- </item>
- <item>
- <p>
- une mise à jour indépendante (NMU) est en cours de réalisation,
- </p>
- </item>
- <item>
- <p>
- quelque chose d'important va affecter le paquet.
- </p>
- </item>
- </list>
- </p>
- <p>
- Les deux types d'informations sont fabriqués de façon similaire :
- il vous suffit d'envoyer un courrier soit à
- <email>pts-static-news@qa.debian.org</email> (pour les annonces
- statiques), soit à <email>pts-news@qa.debian.org</email> (pour les
- nouvelles usuelles). Le courrier devrait indiquer quel paquet est
- concerné par la nouvelle en donnant le nom du paquet source dans un
- en-tête de courrier <tt>X-PTS-Package</tt> ou dans un pseudo-en-tête
- <tt>Package</tt> (comme pour les rapports de bogue du BTS). Si une URL
- est disponible dans l'en-tête de courrier <tt>X-PTS-Url</tt> ou dans
- un pseudo-en-tête <tt>Url</tt>, le résultat est un lien vers cette URL
- au lieu d'une nouvelle complète.
- </p>
- <p>
- Voici quelques exemples de courriers valides utilisés pour générer des
- nouvelles dans le PTS. Le premier ajoute un lien vers l'interface
- cvsweb de debian-cd dans la section « Informations
- statiques » :
- <example>
-From: Raphael Hertzog <hertzog@debian.org>
-To: pts-static-news@qa.debian.org
-Subject: Browse debian-cd CVS repository with cvsweb
-
-Package: debian-cd
-Url: http://cvs.debian.org/debian-cd/
-</example>
- </p>
- <p>
- Le second est une annonce envoyée à une liste de diffusion et
- également envoyée au PTS pour qu'elle soit publiée sur la page web du
- PTS du paquet. Notez l'utilisation du champ BCC pour éviter que des
- réponses ne soient envoyées par erreur au PTS.
- <example>
-From: Raphael Hertzog <hertzog@debian.org>
-To: debian-gtk-gnome@lists.debian.org
-Bcc: pts-news@qa.debian.org
-Subject: Galeon 2.0 backported for woody
-X-PTS-Package: galeon
-
-Hello gnomers!
-
-I'm glad to announce that galeon has been backported for woody. You'll find
-everything here:
-...
-</example>
- </p>
- <p>
- Réfléchissez-y à deux fois avant d'ajouter une nouvelle au PTS car
- vous ne pourrez pas l'enlever par la suite et vous ne pourrez pas non
- plus l'éditer. La seule chose que vous puissiez faire est d'envoyer
- une deuxième nouvelle qui va déprécier l'information contenue dans la
- précédente.
- </p>
- </sect1>
- </sect>
- <sect id="ddpo">
- <heading>
- Vue d'ensemble des paquets d'un développeur
- </heading>
- <p>
- Un portail web pour l'Assurance Qualité (QA) est disponible à <url
- id="&url-ddpo;"> qui affiche un tableau de tous les paquets d'un
- développeur (y compris ceux pour lequel il est co-responsable). Le
- tableau donne un bon résumé sur les paquets d'un développeur :
- nombre de bogues par gravité, liste des versions disponibles, état des
- tests et des liens vers d'autres informations utiles.
- </p>
- <p>
- C'est une bonne idée de vérifier régulièrement vos données pour ne pas
- oublier de bogues ouverts et pour ne pas oublier quels paquets sont
- sous votre responsabilité.
- </p>
- </sect>
- <sect id="alioth">
- <heading>
- Debian *Forge : Alioth
- </heading>
- <p>
- Alioth est un service de Debian plutôt récent, basé sur une version
- légèrement modifiée du logiciel GForge (qui a évolué à partir de
- SourceForge). Ce logiciel offre aux développeurs l'accès à des outils
- faciles d'utilisation comme un gestionnaire de suivi de bogues, un
- gestionnaire de correctifs, un gestionnaire de tâches et de projets, un
- service d'hébergement de fichiers, des listes de diffusion, des dépôts
- CVS, etc. Tous ces outils sont gérés par une interface web.
- </p>
- <p>
- Alioth est destiné à fournir des facilités pour des projets de
- logiciels soutenus ou dirigés par Debian, à faciliter les contributions
- de développeurs externes aux projets initiés par Debian et à aider des
- projets dont les buts sont de promouvoir Debian ou ses dérivés.
- </p>
- <p>
- Tous les développeurs Debian ont automatiquement un compte sur
- Alioth. Ils peuvent l'activer en utilisant la fonctionnalité de
- récupération des mots de passe. Les développeurs externes peuvent
- demander un compte invité sur Alioth.
- </p>
- <p>
- Pour plus d'informations, veuillez visiter <url id="&url-alioth;">.
- </p>
- </sect>
- <sect id="developer-misc">
- <heading>
- « Goodies » pour les développeurs
- </heading>
- <p>
- </p>
- <sect1 id="lwn">
- <heading>
- Abonnements LWN
- </heading>
- <p>
- Depuis octobre 2002, HP parraine l'abonnement à LWN pour tous les
- développeurs Debian intéressés. Les détails sur les moyens d'accéder à
- cet avantage sont expliqués dans <url
- id="http://lists.debian.org/debian-devel-announce/2002/10/msg00018.html">.
- </p>
- </sect1>
- </sect>
- </chapt>
- <chapt id="pkgs">
- <heading>
- Gestion des paquets
- </heading>
- <p>
- Ce chapitre contient des informations relatives à la création, l'envoi,
- la maintenance et le portage des paquets.
- </p>
- <sect id="newpackage">
- <heading>
- Nouveaux paquets
- </heading>
- <p>
- Si vous voulez créer un nouveau paquet pour la distribution Debian,
- vous devriez commencer par consulter la liste des <url id="&url-wnpp;"
- name="paquets en souffrance et paquets souhaités">. Vous pourrez ainsi
- vérifier que personne ne travaille déjà sur ce paquet et éviter un
- double travail. Consultez aussi cette page si vous voulez en savoir
- plus.
- </p>
- <p>
- Supposons que personne ne travaille sur le paquet que vous visez, vous
- devez alors envoyer un rapport de bogue (voir <ref id="submit-bug">)
- concernant le pseudo-paquet <package>wnpp</package>. Ce courrier devra
- décrire le paquet que vous projetez de créer, la licence de ce paquet
- et l'URL à laquelle le source peut être téléchargé. Cette liste n'est
- pas limitative.
- </p>
- <p>
- Le sujet de votre rapport de bogue devra être
- <ITP<footnote><p><em>Intent To Package</em> : intention
- d'empaquetage</p></footnote> : <var>NomDuPaquet</var> —
- <var>courte description</var>>, en remplaçant <var>NomDuPaquet</var>
- par le nom du paquet. La gravité du bogue sera <em>wishlist</em>. Si
- vous le jugez nécessaire, envoyez une copie à &email-debian-devel; en
- mettant cette adresse dans le champ <tt>X-Debbugs-CC:</tt> de l'en-tête
- du message. N'utilisez pas le champ <tt>CC:</tt> car de cette manière
- le sujet du message ne contiendrait pas le numéro du bogue.
- </p>
- <p>
- Il faudra aussi ajouter une entrée <tt>Closes:
- bug#<var>nnnnn</var></tt> dans le fichier <file>changelog</file> du
- nouveau paquet. Cette indication fermera automatiquement le rapport de
- bogue à l'installation du nouveau paquet sur les serveurs d'archivage
- (voir <ref id="upload-bugfix">).
- </p>
- <p>
- Lors de la fermeture de bogues de sécurité, incluez les numéros CVS ainsi
- que « Closes: #nnnnn ». Ceci est utile l'équipe de sécurité
- pour suivre les failles de sécurité. Si un envoi est effectué pour
- corriger le bogue avant que l'identifiant de l'alerte soit connu, il est
- conseillé de modifier l'entrée de changelog historique lors du prochain
- envoi. Même dans ce cas, veuillez inclure tous les pointeurs disponibles
- vers les informations de contexte dans l'entrée de changelog d'origine.
- </p>
- <p>
- Plusieurs raisons nous poussent à demander aux responsables d'annoncer
- leur intention :
- <list compact="compact">
- <item>
- <p>
- Les responsables ont ainsi la possibilité de puiser dans
- l'expérience des autres responsables et cela leur permet de savoir
- si une autre personne travaille déjà dessus.
- </p>
- </item>
- <item>
- <p>
- D'autres personnes qui envisagent de travailler sur le même paquet
- apprendront ainsi qu'il existe déjà un volontaire, l'effort peut
- alors être partagé.
- </p>
- </item>
- <item>
- <p>
- Cela permet aux autres responsables de connaître le nouveau paquet
- mieux que ne le permettent la description d'une ligne et
- l'habituelle entrée de type changelog <em>Initial release</em>
- postée sur <tt>debian-devel-changes</tt>.
- </p>
- </item>
- <item>
- <p>
- C'est une information utile pour les gens qui utilisent la
- distribution <em>unstable</em> et qui sont nos premiers
- testeurs. Nous devons leur faciliter la tâche.
- </p>
- </item>
- <item>
- <p>
- Avec ces annonces, les développeurs Debian et toutes les autres
- personnes intéressées peuvent se faire une meilleure idée des
- évolutions et des nouveautés du projet.
- </p>
- </item>
- </list>
- </p>
- <p>
- Veuillez consulter <url
- id="http://ftp-master.debian.org/REJECT-FAQ.html"> pour les raisons
- courantes de rejet des nouveaux paquets.
- </p>
- </sect>
- <sect id="changelog-entries">
- <heading>
- Enregistrer les modifications dans le paquet
- </heading>
- <p>
- Les modifications que vous apportez au paquet doivent être notifiées
- dans le fichier <file>debian/changelog</file>. Ces notes doivent donner
- une description concise des changements, expliquer les raisons de
- ceux-ci (si ce n'est pas clair) et indiquer si des rapports de bogue
- ont été clos. Il faut aussi indiquer quand le paquet a été terminé. Ce
- fichier sera installé dans
- <file>/usr/share/doc/<var>paquet</var>/changelog.Debian.gz</file> ou
- <file>/usr/share/doc/<var>paquet</var>/changelog.gz</file> pour un
- paquet natif.
- </p>
- <p>
- Le fichier <file>debian/changelog</file> a une structure précise
- comportant différents champs. Le champ <em>distribution</em> est décrit
- dans <ref id="distribution">. Vous trouverez plus d'informations sur la
- structure de ce fichier dans la section
- « <file>debian/changelog</file> » de la <em>charte
- Debian</em>.
- </p>
- <p>
- Les entrées du fichier <file>changelog</file> peuvent être utilisées
- pour fermer des rapports de bogue au moment où le paquet est installé
- dans l'archive. Voir la section <ref id="upload-bugfix">.
- </p>
- <p>
- Par convention, l'entrée changelog d'un paquet contenant une nouvelle
- version amont ressemble à :
- <example>
- * new upstream version
-</example>
- </p>
- <p>
- Quelques outils peuvent vous aider à créer des entrées et à finaliser
- le fichier <file>changelog</file> pour une livraison — voir les
- sections <ref id="devscripts"> et <ref id="dpkg-dev-el">.
- </p>
- <p>
- Voir aussi <ref id="bpp-debian-changelog">.
- </p>
- </sect>
- <sect id="sanitycheck">
- <heading>
- Tester le paquet
- </heading>
- <p>
- Avant d'envoyer votre paquet, vous devriez faire quelques tests de
- base. Vous devriez au moins faire les tests suivants (il vous faut une
- ancienne version du paquet) :
- <list>
- <item>
- <p>
- Installez le paquet et vérifiez que le logiciel fonctionne. Si le
- paquet existait déjà dans une version plus ancienne, faites une mise
- à jour.
- </p>
- </item>
- <item>
- <p>
- Exécutez <prgn>lintian</prgn> sur votre paquet. Vous pouvez exécuter
- <prgn>lintian</prgn> comme suit : <tt>lintian -v
- <var>version-paquet</var>.changes</tt>. Ce programme fera une
- vérification sur les paquets source et binaire. Si vous ne comprenez
- pas les messages retournés par <prgn>lintian</prgn>, essayez
- l'option <tt>-i</tt>. Cette option rendra <prgn>lintian</prgn>
- beaucoup plus bavard dans sa description du problème.
- </p>
- <p>
- En principe, un paquet pour lequel <prgn>lintian</prgn> renvoie des
- erreurs (elles commencent par <tt>E</tt>) <em>ne doit pas</em> être
- installé dans l'archive.
- </p>
- <p>
- Pour en savoir plus sur <prgn>lintian</prgn>, reportez-vous à la
- section <ref id="lintian">.
- </p>
- </item>
- <item>
- <p>
- Vous pouvez facultativement exécuter <ref id="debdiff"> pour
- analyser les modifications depuis une ancienne version si celle-ci
- existe.
- </p>
- </item>
- <item>
- <p>
- Faites régresser le paquet vers sa version précédente si elle existe
- — cela permet de tester les scripts <file>postrm</file> et
- <file>prerm</file>.
- </p>
- </item>
- <item>
- <p>
- Désinstallez le paquet et réinstallez-le.
- </p>
- </item>
- <item>
- <p>
- Copiez le paquet source dans une répertoire différent et tentez de
- le décompacter et de le reconstruire. Ceci teste si le paquet repose
- sur des fichiers existants en dehors de ceux du paquet ou s'il
- repose sur des permissions préservées des fichiers livrés dans le
- fichier .diff.gz.
- </p>
- </item>
- </list>
- </p>
- </sect>
- <sect id="sourcelayout">
- <heading>
- Disposition du paquet source
- </heading>
- <p>
- Il existe deux types de paquets source Debian :
- <list>
- <item>
- <p>
- les paquets appelés <em>natifs</em> pour lesquels il n'y a pas de
- distinction entre les sources d'origine et les correctifs appliqués
- pour Debian
- </p>
- </item>
- <item>
- <p>
- les paquets (plus courants) où il y a un fichier archive source
- d'origine accompagné par un autre fichier contenant les correctifs
- pour Debian.
- </p>
- </item>
- </list>
- </p>
- <p>
- Pour les paquets natifs, le paquet source inclut un fichier de contrôle
- source Debian (<tt>.dsc</tt>) et l'archive source
- (<tt>.tar.gz</tt>). Un paquet source d'un paquet non natif inclut un
- fichier de contrôle source Debian, l'archive source d'origine
- (<tt>.orig.tar.gz</tt>) et les correctifs Debian (<tt>.diff.gz</tt>).
- </p>
- <p>
- Le caractère natif d'un paquet est déterminé lorsqu'il est construit
- par <manref section="1" name="dpkg-buildpackage">. Le reste de cette
- section ne se rapporte qu'aux paquets non natifs.
- </p>
- <p>
- La première fois qu'un paquet est installé dans l'archive pour une
- version amont donnée, le fichier <file>tar</file> de cette version
- amont doit être téléchargé et mentionné dans le fichier
- <file>.changes</file>. Par la suite, ce fichier <file>tar</file> sera
- utilisé pour générer les fichiers <file>diff</file> et
- <file>.dsc</file> et il ne sera pas nécessaire de le télécharger à
- nouveau.
- </p>
- <p>
- Par défaut, <prgn>dpkg-genchanges</prgn> et
- <prgn>dpkg-buildpackage</prgn> incluront le fichier <file>tar</file>
- amont si et seulement si le numéro de révision du paquet source est 0
- ou 1, ce qui indique une nouvelle version amont. Ce comportement peut
- être modifié en utilisant <tt>-sa</tt> pour l'inclure systématiquement
- ou <tt>-sd</tt> pour ne jamais l'inclure.
- </p>
- <p>
- Si la mise à jour ne contient pas le fichier <file>tar</file> des
- sources originaux, <prgn>dpkg-source</prgn> <em>doit</em>, pour
- construire les fichiers <file>.dsc</file> et <file>diff</file> de la
- mise à jour, utiliser un fichier <tt>tar</tt> identique à l'octet près
- à celui déjà présent dans l'archive.
- </p>
- <p>
- Veuillez noter que, dans des paquets non natifs, les permissions sur
- des fichiers qui ne sont pas présents dans l'archive .orig.tar.gz ne
- seront pas préservées car diff ne stocke pas les permissions de fichier
- dans le correctif.
- </p>
- </sect>
- <sect id="distribution">
- <heading>
- Choisir une distribution
- </heading>
- <p>
- Chaque envoi doit spécifier à quelle distribution le paquet est
- destiné. Le processus de construction de paquet extrait cette
- information à partir de la première ligne du fichier
- <file>debian/changelog</file> et la place dans le champ
- <tt>Distribution</tt> du fichier <tt>.changes</tt>.
- </p>
- <p>
- Il existe plusieurs valeurs possibles pour ce champ :
- « stable », « unstable »,
- « testing-proposed-updates » et « experimental ».
- </p>
- <p>
- En fait, il y a deux autres possibilités :
- « stable-security » et « testing-security », mais
- veuillez lire <ref id="bug-security"> pour plus d'informations sur
- celles-ci.
- </p>
- <p>
- Il n'est pas possible d'envoyer un paquet dans plusieurs distributions
- en même temps.
- </p>
- <sect1 id="upload-stable">
- <heading>
- Cas spécial : mise à jour d'un paquet de la distribution
- <em>stable</em>
- </heading>
- <p>
- Livrer un paquet pour la distribution <em>stable</em> signifie que le
- paquet sera dirigé vers le répertoire
- <file>stable-proposed-updates</file> des archives Debian pour y être
- testé avant d'être effectivement inclus dans <em>stable</em>.
- </p>
- <p>
- Une livraison pour la distribution <em>stable</em> requiert des soins
- supplémentaires. Un paquet de cette distribution ne devrait être mis à
- jour que dans les cas suivants :
- <list>
- <item>
- <p>
- un problème fonctionnel vraiment critique,
- </p>
- </item>
- <item>
- <p>
- un paquet devenu non installable,
- </p>
- </item>
- <item>
- <p>
- un paquet indisponible pour une architecture.
- </p>
- </item>
- </list>
- </p>
- <p>
- Par le passé, des envois vers <em>stable</em> étaient également
- utilisés pour corriger les problèmes de sécurité. Cependant, cette
- pratique est dépréciée car les envois utilisés pour les avis de
- sécurité Debian<footnote><p>Debian security advisory</p></footnote>
- sont automatiquement copiés dans l'archive
- <file>proposed-updates</file> appropriée quand l'avis est
- publié. Reportez-vous à <ref id="bug-security"> pour des informations
- plus détaillées sur la gestion des problèmes de sécurité.
- </p>
- <p>
- Il est fortement déconseillé de changer quoi que ce soit si ce n'est
- pas important car même une modification triviale peut provoquer un
- bogue.
- </p>
- <p>
- Les paquets livrés pour <em>stable</em> doivent être compilés avec la
- distribution <em>stable</em> pour que leurs dépendances se limitent
- aux bibliothèques (et autres paquets) disponibles dans
- <em>stable</em> ; un paquet livré pour la distribution
- <em>stable</em> qui dépend d'une bibliothèque qui n'est disponible que
- dans <em>unstable</em> sera rejeté. Modifier les dépendances d'autres
- paquets (en manipulant le champ <tt>Provides</tt> ou les fichiers
- shlibs) et, peut-être, rendre ces paquets non installables, est
- fortement déconseillé.
- </p>
- <p>
- L'équipe responsable de la distribution<footnote><p><em>the Release
- team</em></p></footnote> (joignable à l'adresse
- &email-debian-release;) évaluera régulièrement le contenu de
- <em>stable-proposed-updates</em> et décidera si votre paquet peut être
- inclus dans la distribution <em>stable</em>. Soyez précis (et, si
- nécessaire, prolixe) quand vous décrivez, dans le fichier changelog,
- vos changements pour une livraison vers <em>stable</em>, sinon le
- paquet ne sera pas pris en considération.
- </p>
- <p>
- Il est fortement conseillé de discuter avec le responsable de la
- version stable <em>avant</em> de réaliser un envoi dans
- <em>stable</em>/<em>stable-proposed-updates</em>, pour que le paquet
- envoyé corresponde aux besoins de la prochaine révision de
- <em>stable</em>.
- </p>
- </sect1>
- <sect1 id="upload-t-p-u">
- <heading>
- Cas spécial : mise à jour d'un paquet de la distribution
- <em>testing</em>/<em>testing-proposed-updates</em>
- </heading>
- <p>
- Veuillez consulter les informations dans la <qref id="t-p-u">section
- sur <em>testing</em></qref> pour des détails.
- </p>
- </sect1>
- </sect>
- <sect id="upload">
- <heading>
- Mettre à jour un paquet
- </heading>
- <sect1 id="upload-ftp-master">
- <heading>
- Installer un paquet sur <tt>ftp-master</tt>
- </heading>
- <p>
- Pour installer un paquet, vous devez envoyer les fichiers (y compris
- les fichiers changes et dsc signés) par ftp anonyme sur
- <ftpsite>&ftp-master-host;</ftpsite> dans le répertoire
- &upload-queue;. Pour que les fichiers y soient traités, ils doivent
- être signés avec une clé du porte-clés (<em>keyring</em>) Debian.
- </p>
- <p>
- Attention, il est préférable de transférer le fichier <tt>changes</tt>
- en dernier. Dans le cas contraire, votre livraison pourrait être
- rejetée car l'outil de maintenance de l'archive pourrait lire le
- fichier <tt>changes</tt> et constater que les fichiers ne sont pas
- tous présents.
- </p>
- <p>
- Les paquets <ref id="dupload"> ou <ref id="dput"> pourront vous
- faciliter le travail lors du téléchargement. Ces programmes bien
- pratiques aident à automatiser le processus d'envoi de paquets vers
- Debian
- </p>
- <p>
- Pour supprimer des paquets, veuillez lire le fichier README dans ce
- répertoire FTP et le paquet Debian <ref id="dcut">.
- </p>
- </sect1>
- <sect1 id="upload-non-us">
- <heading>
- Installer un paquet sur <tt>non-US</tt>
- </heading>
- <p>
- <em>Note :</em> non-us a été interrompu avec la publication de
- <em>Sarge</em>.
- </p>
- </sect1>
- <sect1 id="delayed-incoming">
- <heading>
- Envois différés
- </heading>
- <p>
- Les envois différés sont pour le moment réalisés <em>via</em> la file
- différée sur gluck. Le répertoire d'envoi est
- <ftpsite>gluck:~tfheen/DELAYED/[012345678]-day</ftpsite>. 0-day est
- envoyé approximativement plusieurs fois par jour vers ftp-master.
- </p>
- <p>
- Avec une version assez récente de dput, cette section
- <example>
-[tfheen_delayed]
-method = scp
-fqdn = gluck.debian.org
-incoming = ~tfheen
-</example>
- dans votre fichier ~/.dput.cf devrait fonctionner correctement pour
- réaliser des envois dans la file DELAYED.
- </p>
- <p>
- <em>Note :</em> Comme la file d'envoi va sur <tt>ftp-master</tt>,
- la prescription que l'on trouve dans <ref id="upload-ftp-master">
- s'applique également ici.
- </p>
- </sect1>
- <sect1>
- <heading>
- Envois de sécurité
- </heading>
- <p>
- N'envoyez <strong>PAS</strong> un paquet vers la file d'envoi de sécurité
- (<em>oldstable-security</em>, <em>stable-security</em>, etc.) sans
- avoir obtenu au préalable l'autorisation de l'équipe de sécurité. Si
- le paquet ne correspond pas tout à fait aux besoins de cette équipe,
- il entraînera beaucoup de problèmes et de délais dans la gestion de
- cet envoi non désiré. Pour plus de détails, consultez la section <ref
- id="bug-security">.
- </p>
- </sect1>
- <sect1>
- <heading>
- Les autres files d'envoi
- </heading>
- <p>
- Les files scp sur ftp-master et security sont pratiquement
- inutilisables à cause des restrictions de connexion sur ces hôtes.
- </p>
- <p>
- Les files anonymes sur ftp.uni-erlangen.de et ftp.uk.debian.org sont
- actuellement arrêtées. Un travail est en cours pour les restaurer.
- </p>
- <p>
- Les files sur master.debian.org, samosa.debian.org,
- master.debian.or.jp et ftp.chiark.greenend.org.uk sont arrêtées de
- façon permanente et ne seront pas restaurées. La file du Japon sera
- remplacée par une nouvelle file sur hp.debian.or.jp un jour.
- </p>
- <p>
- À l'heure actuelle, la file en ftp anonyme sur auric.debian.org (le
- précédent ftp-master) fonctionne, mais elle est déconseillée et sera
- supprimée à un moment donné.
- </p>
- </sect1>
- <sect1 id="upload-notification">
- <heading>
- Notification de l'installation d'un nouveau paquet
- </heading>
- <p>
- Les administrateurs de l'archive Debian sont responsables de
- l'installation des mises à jour. La plupart des mises à jour sont
- gérées quotidiennement par le logiciel de gestion de l'archive
- <prgn>katie</prgn>. Les mises à jour de paquets sur la distribution
- <em>unstable</em> sont installées ainsi. Dans les autres cas et
- notamment dans le cas d'un nouveau paquet, celui-ci sera installé
- manuellement. Il peut s'écouler jusqu'à un mois entre le
- téléchargement d'un paquet vers un serveur et son installation
- effective. Soyez patient.
- </p>
- <p>
- Dans tous les cas, vous recevrez un accusé de réception par courrier
- électronique indiquant que votre paquet a été installé et quels
- rapports de bogues ont été clos. Lisez attentivement ce courrier et
- vérifiez que tous les rapports de bogue que vous vouliez clore sont
- bien dans cette liste.
- </p>
- <p>
- L'accusé de réception indique aussi la section dans laquelle le paquet
- a été installé. S'il ne s'agit pas de votre choix, vous recevrez un
- second courrier qui vous informera de cette différence (voir
- ci-dessous).
- </p>
- <p>
- Notez que si vous envoyez <em>via</em> les files, le logiciel de démon
- de file vous enverra également une notification par courriel.
- </p>
- </sect1>
- </sect>
- <sect id="override-file">
- <heading>
- Spécifier la section, la sous-section et la priorité d'un paquet
- </heading>
- <p>
- Les champs <tt>Section</tt> et <tt>Priority</tt> du fichier
- <file>debian/control</file> n'indiquent ni où le paquet sera installé
- dans l'archive Debian, ni sa priorité. Afin de conserver la cohérence
- de l'archive, ce sont les administrateurs qui contrôlent ces
- champs. Les valeurs du fichier <file>debian/control</file> sont juste
- des indications.
- </p>
- <p>
- Les administrateurs de l'archive indiquent les sections et priorités
- des paquets dans le fichier <em>override</em>. Si ce fichier
- <em>override</em> et le fichier <file>debian/control</file> de votre
- paquet diffèrent, vous en serez informé par courrier électronique quand
- votre paquet sera installé dans l'archive. Vous pourrez corriger votre
- fichier <em>debian/control</em> avant votre prochain téléchargement ou
- alors vous pourrez vouloir modifier le fichier <em>override</em>.
- </p>
- <p>
- Pour modifier la section dans laquelle un paquet est archivé, vous
- devez d'abord vérifier que fichier <file>debian/control</file> est
- correct. Ensuite, envoyez un courrier à &email-override; ou un rapport
- de bogue sur le pseudo-paquet <package>ftp.debian.org</package>
- demandant la modification de la section ou de la priorité de votre
- paquet. Exposez bien les raisons qui vous amènent à demander ces
- changements.
- </p>
- <p>
- Pour en savoir plus sur les <em>fichiers override</em>, reportez-vous à
- <manref section="1" name="dpkg-scanpackages"> et <url
- id="&url-bts-devel;#maintincorrect">.
- </p>
- <p>
- Notez que le champ <tt>Section</tt> décrit à la fois la section et la
- sous-section, comme décrit dans <ref id="archive-sections">. Si la
- section est « main », elle devrait être omise. La liste des
- sous-sections autorisées peut être trouvée dans <url
- id="&url-debian-policy;ch-archive.html#s-subsections">.
- </p>
- </sect>
- <sect id="bug-handling">
- <heading>
- Gérer les bogues
- </heading>
- <p>
- Chaque développeur doit être capable de travailler avec le <url
- id="&url-bts;" name="système de suivi des bogues"> Debian. Il faut
- savoir comment remplir des rapports de bogue correctement (voir <ref
- id="submit-bug">), comment les mettre à jour et les réordonner et
- comment les traiter et les fermer.
- </p>
- <p>
- Les fonctionnalités du système de suivi des bogues sont décrites dans
- la <url id="&url-bts-devel;" name="documentation du BTS pour les
- développeurs">. Ceci inclut la fermeture des bogues, l'envoi des
- messages de suivi, l'assignation des niveaux de gravité et des marques,
- l'indication que les bogues ont été envoyés au développeur amont et
- autres problèmes.
- </p>
- <p>
- Des opérations comme réassigner des bogues à d'autres paquets, réunir
- des rapports de bogues séparés traitant du même problème ou rouvrir des
- bogues quand ils ont été prématurément fermés, sont gérées en utilisant
- le serveur de courrier de contrôle. Toutes les commandes disponibles
- pour ce serveur sont décrites dans la <url id="&url-bts-control;"
- name="documentation du serveur de contrôle du BTS">.
- </p>
- <sect1 id="bug-monitoring">
- <heading>
- Superviser les rapports de bogue
- </heading>
- <p>
- Si vous voulez être un bon responsable, consultez régulièrement la
- page du <url id="&url-bts;" name="système de suivi des bogues">. Cette
- page contient tous les rapports de bogue qui concernent vos
- paquets. Vous pouvez les vérifier avec cette page :
- <tt>http://&bugs-host;/<var>votre_compte</var>@debian.org</tt>.
- </p>
- <p>
- Les responsables interagissent avec le système de suivi des bogues en
- utilisant l'adresse électronique <tt>&bugs-host;</tt>. Vous trouverez
- une documentation sur les commandes disponibles à l'adresse <url
- id="&url-bts;"> ou, si vous avez installé le paquet
- <package>doc-debian</package>, dans les fichiers locaux
- &file-bts-docs;.
- </p>
- <p>
- Certains trouvent utile de recevoir régulièrement une synthèse des
- rapports de bogues ouverts. Si vous voulez recevoir une synthèse
- hebdomadaire relevant tous les rapports de bogue ouverts pour vos
- paquets, vous pouvez configurer <prgn>cron</prgn> comme suit :
- <example>
-# Synthèse hebdomadaire des rapports de bogue qui me concernent
-&cron-bug-report;
-</example>
- Remplacez <var>address</var> par votre adresse officielle de
- responsable Debian.
- </p>
- </sect1>
- <sect1 id="bug-answering">
- <heading>
- Répondre à des rapports de bogue
- </heading>
- <p>
- Lorsque vous répondez à des rapports de bogue, assurez-vous que toutes
- vos discussions concernant les bogues sont envoyées au rapporteur du
- bogue et au bogue lui-même (<email>123@&bugs-host;</email> par
- exemple). Si vous rédigez un nouveau courrier et si vous ne vous
- souvenez plus de l'adresse du rapporteur de bogue, vous pouvez
- utiliser l'adresse <email>123-submitter@&bugs-host;</email> pour
- contacter le rapporteur <em>et</em> enregistrer votre courrier dans le
- journal du bogue (ce qui veut dire que vous n'avez pas besoin
- d'envoyer une copie du courrier à <email>123@&bugs-host;</email>).
- </p>
- <p>
- Si vous recevez un bogue mentionnant « FTBFS », cela veut
- dire « Fails To Build From Source » (Erreur de construction
- à partir du source). Les porteurs emploient fréquemment cet acronyme.
- </p>
- <p>
- Une fois que vous avez traité un rapport de bogue (i.e. que vous
- l'avez corrigé), marquez-le comme <em>done</em> (fermez-le) en
- envoyant un message d'explication à
- <email>123-done@&bugs-host;</email>. Si vous corrigez un bogue en
- changeant et en envoyant une nouvelle version du paquet, vous pouvez
- fermer le bogue automatiquement comme décrit dans <ref
- id="upload-bugfix">.
- </p>
- <p>
- Vous ne devez <em>jamais</em> fermer un rapport de bogue en envoyant
- la commande <tt>close</tt> à l'adresse &email-bts-control;.Si vous le
- faites, le rapporteur n'aura aucune information sur la clôture de son
- rapport.
- </p>
- </sect1>
- <sect1 id="bug-housekeeping">
- <heading>
- Gestion générale des bogues
- </heading>
- <p>
- En tant que responsable de paquet, vous trouverez fréquemment des
- bogues dans d'autres paquets ou vous aurez des bogues sur vos paquets
- qui sont en fait des bogues sur d'autres paquets. Les fonctions
- intéressantes du système de suivi des bogues sont décrites dans la
- <url id="&url-bts-devel;" name="documentation du BTS pour les
- développeurs Debian">. Les <url id="&url-bts-control;"
- name="instructions du serveur de contrôle du BTS"> documentent les
- opérations techniques du BTS, telles que comment remplir, réassigner,
- regrouper et marquer des bogues. Cette section contient des lignes
- directrices pour gérer vos propres bogues, définies à partir de
- l'expérience collective des développeurs Debian.
- </p>
- <p>
- Remplir des rapports de bogue pour des problèmes que vous trouvez dans
- d'autres paquet est l'une des « obligations civiques » du
- responsable, reportez-vous à <ref id="submit-bug"> pour les
- détails. Cependant, gérer les bogues de vos propres paquets est encore
- plus important.
- </p>
- <p>
- Voici une liste des étapes que vous pouvez suivre pour gérer un
- rapport de bogue :
- <enumlist numeration="arabic">
- <item>
- <p>
- Décider si le rapport correspond à un bogue réel ou non. Parfois,
- les utilisateurs exécutent simplement un programme de la mauvaise
- façon car ils n'ont pas lu la documentation. Si c'est votre
- diagnostic, fermez simplement le bogue avec assez d'informations
- pour laisser l'utilisateur corriger son problème (donnez des
- indications vers la bonne documentation et ainsi de suite). Si le
- rapport de bogue revient régulièrement, vous devriez vous demander
- si la documentation est assez bonne ou si le programme ne devrait
- pas détecter une mauvaise utilisation pour donner un message
- d'erreur informatif. Il s'agit d'un problème qui peut être discuté
- avec l'auteur amont.
- </p>
- <p>
- Si le rapporteur de bogue n'est pas d'accord avec votre décision de
- fermeture du bogue, il peut le ré-ouvrir jusqu'à ce que vous
- trouviez un accord sur la façon de le gérer. Si vous n'en trouvez
- pas, vous pouvez marquer le bogue avec <tt>wontfix</tt> pour
- indiquer aux personnes que le bogue existe, mais ne sera pas
- corrigé. Si cette situation n'est pas acceptable, vous (ou le
- rapporteur) pouvez vouloir demander une décision par le comité
- technique en réattribuant le bogue à <package>tech-ctte</package>
- (vous pouvez utiliser la commande <tt>clone</tt> du BTS si vous
- désirez garder le bogue comme rapporté sur votre paquet). Avant de
- faire cela, veuillez lire la <url id="&url-tech-ctte;"
- name="procédure recommandée">.
- </p>
- </item>
- <item>
- <p>
- Si le bogue est réel, mais est causé par un autre paquet,
- réattribuez simplement le bogue à l'autre paquet. Si vous ne savez
- pas à quel paquet il doit être réattribué, vous pouvez demander de
- l'aide sur <qref id="irc-channels">IRC</qref> ou sur
- &email-debian-devel;. Veuillez vous assurer que le (ou les)
- responsable(s) du paquet sur lequel est réattribué le paquet sait
- pourquoi vous l'avez ainsi réattribué.
- </p>
- <p>
- Parfois, vous devez également ajuster la gravité du bogue pour
- qu'elle corresponde à notre définition de gravité des bogues. C'est
- dû au fait que les gens tendent à augmenter la gravité des bogues
- pour s'assurer que leurs bogues seront corrigés rapidement. La
- gravité de certains bogues peut même être rétrogradée en
- <em>wishlist</em> (souhait) quand le changement demandé est
- seulement d'ordre cosmétique.
- </p>
- </item>
- <item>
- <p>
- Si le bogue est réel, mais que le problème a déjà été rapporté par
- quelqu'un d'autre, les deux rapports de bogues pertinents devraient
- être fusionnés en un seul en utilisant la commande <tt>merge</tt>
- (fusion) du BTS. Ainsi, quand le bogue sera corrigé, tous les
- créateurs de rapport de bogue en seront informés (notez, cependant,
- que les courriels envoyés à l'un des créateurs de rapport de bogue
- ne seront pas automatiquement envoyés aux autres créateurs de
- rapport de bogue). Pour plus de détails sur les technicités de la
- commande de fusion et sa voisine, la commande <tt>unmerge</tt>
- (séparation), veuillez consulter la documentation du serveur de
- contrôle du BTS.
- </p>
- </item>
- <item>
- <p>
- Le rapporteur de bogue peut avoir oublié de fournir certaines
- informations. Dans ce cas, vous devez lui demander les informations
- nécessaires. Vous pouvez utiliser la marque <tt>moreinfo</tt> (plus
- d'information) sur le bogue. De plus, si vous ne pouvez pas
- reproduire le bogue, vous pouvez le marquer comme
- <tt>unreproducible</tt> (non reproductible). Une personne qui
- arriverait à reproduire le bogue est alors invitée à fournir plus
- d'informations sur la façon de le reproduire. Après quelques mois,
- si cette information n'a été envoyée par personne, le bogue peut
- être fermé.
- </p>
- </item>
- <item>
- <p>
- Si le bogue est lié à l'empaquetage, vous devez simplement le
- corriger. Si vous ne pouvez pas le corriger vous-même, marquez
- alors le bogue avec <tt>help</tt> (aide). Vous pouvez également
- demander de l'aide sur &email-debian-devel; ou
- &email-debian-qa;. S'il s'agit d'un problème amont, vous devez
- faire suivre le rapport à l'auteur amont. Faire suivre un bogue
- n'est pas suffisant, vous devez vérifier à chaque version si le
- bogue a été corrigé ou non. S'il a été corrigé, vous le fermez
- simplement, sinon vous devez le rappeler à l'auteur. Si vous avez
- les compétences nécessaires, vous pouvez préparer un correctif pour
- corriger le bogue et l'envoyer en même temps à
- l'auteur. Assurez-vous d'envoyer le correctif au BTS et marquez le
- bogue avec <tt>patch</tt> (correctif).
- </p>
- </item>
- <item>
- <p>
- Si vous avez corrigé un bogue sur votre copie locale ou si un
- correctif a été inclus dans le référentiel CVS, vous pouvez marquer
- le bogue avec <tt>pending</tt> (en attente) pour informer que le
- bogue est corrigé et qu'il sera fermé lors du prochain envoi
- (ajoutez le <tt>closes:</tt> dans le <file>changelog</file>). C'est
- particulièrement utile si plusieurs développeurs travaillent sur le
- même paquet.
- </p>
- </item>
- <item>
- <p>
- Une fois que le paquet corrigé est disponible dans la distribution
- <em>unstable</em>, vous pouvez fermer le bogue. Ceci peut être fait
- automatiquement, pour cela, reportez-vous à <ref
- id="upload-bugfix">.
- </p>
- </item>
- </enumlist>
- </p>
- </sect1>
- <sect1 id="upload-bugfix">
- <heading>
- Quand les rapports de bogue sont-ils fermés par une mise à jour ?
- </heading>
- <p>
- Au fur et à mesure que les bogues et problèmes sont corrigés dans vos
- paquets, il est de votre responsabilité en tant que responsable du
- paquet de fermer les rapports de bogue associés. Cependant, vous ne
- devez pas les fermer avant que le paquet n'ait été accepté dans
- l'archive Debian. C'est pourquoi, vous pouvez et vous devez clore les
- rapports dans le système de suivi des bogues une fois que vous avez
- reçu l'avis indiquant que votre nouveau paquet a été installé dans
- l'archive. Le bogue devrait être fermé avec la bonne version.
- </p>
- <p>
- Cependant, il est possible d'éviter d'avoir à fermer manuellement les
- bogues après l'envoi — indiquez simplement les bogues corrigés
- dans le fichier <file>changelog</file> en suivant une syntaxe
- précise. Par exemple :
- <example>
-acme-cannon (3.1415) unstable; urgency=low
-
- * Frobbed with options (closes: Bug#98339)
- * Added safety to prevent operator dismemberment, closes: bug#98765,
- bug#98713, #98714.
- * Added man page. Closes: #98725.
-</example>
- Techniquement parlant, l'expression rationnelle Perl suivante décrit
- comment les lignes de <em>changelogs</em> de fermeture de bogues sont
- identifiées :
- <example>
- /closes:\s*(?:bug)?\#\s*\d+(?:,\s*(?:bug)?\#\s*\d+)*/ig
-</example>
- Nous préférons la syntaxe <tt>closes: #<var>XXX</var></tt>, car c'est
- l'entrée la plus concise et la plus facile à intégrer dans le texte du
- fichier <file>changelog</file>.
- </p>
- <p>
- À moins que cela soit spécifié différemment par l'option <var>-v</var> de
- <prgn>dpkg-buildpackage</prgn>, seuls les bogues fermés dans l'entrée de
- changelog la plus récente sont fermés (fondamentalement, seuls les
- bogues mentionnés dans la partie de changelog du fichier
- <file>.changes</file> sont fermés).
- </p>
- <p>
- <!-- les bogues des envois ... ? -->
- Historiquement, les envois identifiés comme <qref id="nmu">Mise à jour
- indépendante</qref> (« Non-maintainer upload » ou NMU) étaient
- marqués comme <tt>fixed</tt> au lieu d'être fermés, mais cette pratique
- a cassé avec l'ajout du suivi des versions. Le même raisonnement
- s'applique à l'étiquette <tt>fixed-in-experimental</tt>.
- </p>
- <p>
- Si vous entrez un numéro de bogue incorrect ou si vous oubliez un
- bogue dans les entrées du fichier <file>changelog</file>, n'hésitez
- pas à annuler tout dommage que l'erreur a entraîné. Pour rouvrir un
- bogue fermé par erreur, envoyez une commande <tt>reopen
- <var>XXX</var></tt> à l'adresse de contrôle du système de suivi des
- bogues, &email-bts-control;. Pour fermer tous les bogues restants qui
- ont été corrigés par votre envoi, envoyez le fichier
- <file>.changes</file> à <email>XXX-done@&bugs-host;</email> où
- <var>XXX</var> est le numéro du bogue et placez « Version:
- YYY » et une ligne vide dans les deux premières lignes du corps du
- courrier où <var>YYY</var> est la première version dans laquelle le
- bogue a été corrigé.
- </p>
- <p>
- Rappelez-vous qu'il n'est pas obligatoire de fermer les bogues en
- utilisant le <file>changelog</file> tel que décrit ci-dessus. Si vous
- désirez simplement fermer les bogues qui n'ont rien à voir avec l'un
- de vos envois, faites-le simplement en envoyant une explication à
- <email>XXX-done@&bugs-host;</email>. Vous <strong>ne devez
- pas</strong> pas fermer des bogues dans une entrée de changelog d'une
- version si les changements dans cette version n'ont rien à voir avec
- le bogue.
- </p>
- <p>
- Pour une information plus générale sur ce qu'il faut mettre dans les
- entrées de changelog, veuillez vous reporter aux <ref
- id="bpp-debian-changelog">.
- </p>
- </sect1>
- <sect1 id="bug-security">
- <heading>
- Gérer les bogues de sécurité
- </heading>
- <p>
- À cause de leur nature sensible, les bogues liés à la sécurité doivent
- être soigneusement traités. L'équipe de sécurité de Debian est là pour
- coordonner cette activité, pour faire le suivi des problèmes de
- sécurité en cours, pour aider les responsables ayant des problèmes de
- sécurité ou pour les corriger elle-même, pour envoyer les annonces de
- sécurité et pour maintenir le site security.debian.org.
- </p>
- <p>
- Si vous prenez connaissance d'un bogue lié à un problème de sécurité
- sur un paquet Debian, que vous soyez ou non le responsable, regroupez
- les informations pertinentes sur le problème et contactez rapidement
- l'équipe de sécurité à &email-security-team; dès que
- possible. <strong>N'ENVOYEZ PAS</strong> de paquet pour
- <em>stable</em> ; l'équipe de sécurité le fera. Les informations
- utiles incluent, par exemple :
- <list compact="compact">
- <item>
- <p>
- les versions du paquet connues pour être affectées par le
- bogue. Vérifiez chaque version présente dans les distributions
- maintenues par Debian ainsi que dans <em>testing</em> et dans
- <em>unstable</em>,
- </p>
- </item>
- <item>
- <p>
- la nature d'une solution si elle est disponible (les correctifs
- sont particulièrement utiles),
- </p>
- </item>
- <item>
- <p>
- tout paquet corrigé que vous avez vous-même préparé (envoyez
- seulement les fichiers <file>.diff.gz</file> et <file>.dsc</file>
- et lisez d'abord <ref id="bug-security-building">),
- </p>
- </item>
- <item>
- <p>
- toute assistance que vous pouvez fournir pour aider les tests
- (exploits, tests de régression, etc.),
- </p>
- </item>
- <item>
- <p>
- toute information nécessaire pour l'annonce de sécurité (voir <ref
- id="bug-security-advisories">).
- </p>
- </item>
- </list>
- </p>
- <sect2 id="bug-security-confidentiality">
- <heading>
- Confidentialité
- </heading>
- <p>
- À la différence de la plupart des autres activités au sein de Debian,
- les informations sur les problèmes de sécurité doivent parfois être
- gardées en privé pour un certain temps. Ceci permet aux distributeurs
- de logiciels de coordonner leur dévoilement afin de minimiser
- l'exposition de leurs utilisateurs. Cette décision dépend de la
- nature du problème et de l'existence d'une solution correspondante et
- également s'il s'agit d'un fait connu publiquement.
- </p>
- <p>
- Il existe plusieurs façons pour un développeur de prendre
- connaissance d'un problème de sécurité :
- <list compact="compact">
- <item>
- <p>
- il le remarque sur un forum public (liste de diffusion, site web,
- etc.),
- </p>
- </item>
- <item>
- <p>
- quelqu'un remplit un rapport de bogue,
- </p>
- </item>
- <item>
- <p>
- quelqu'un l'informe par courrier privé.
- </p>
- </item>
- </list>
- Dans les deux premiers cas, l'information est publique et il est
- important d'avoir une solution le plus vite possible. Dans le dernier
- cas, cependant, ce n'est peut-être pas une information publique. Dans
- ce cas, il existe quelques options possibles pour traiter le
- problème :
- <list>
- <item>
- <p>
- si l'exposition de sécurité est mineure, il n'y a parfois pas
- besoin de garder le secret sur le problème et une correction
- devrait être effectuée et diffusée,
- </p>
- </item>
- <item>
- <p>
- si le problème est grave, il est préférable de partager cette
- information avec d'autres vendeurs et de coordonner une
- publication. L'équipe de sécurité reste en contact avec les
- différentes organisations et individus et peut prendre soin des
- actions à mener.
- </p>
- </item>
- </list>
- </p>
- <p>
- Dans tous les cas, si la personne qui indique le problème demande à
- ce que l'information ne soit pas diffusée, cela devrait être respecté
- avec l'évidente exception d'informer l'équipe de sécurité pour qu'une
- correction puisse être effectuée pour la version stable de
- Debian. Quand vous envoyez des informations confidentielles à
- l'équipe de sécurité, assurez-vous de bien mentionner ce fait.
- </p>
- <p>
- Veuillez noter que si le secret est nécessaire, vous ne pourrez pas
- envoyer un correctif vers <em>unstable</em> (ou ailleurs) puisque les
- informations de changelog et de diff sont publiques pour
- <em>unstable</em>.
- </p>
- <p>
- Il existe deux raisons pour diffuser l'information même si le secret
- est demandé : le problème est connu depuis un certain temps ou
- le problème ou son exploitation est devenu public.
- </p>
- </sect2>
- <sect2 id="bug-security-advisories">
- <heading>
- Annonces de sécurité
- </heading>
- <p>
- Les annonces de sécurité ne sont émises que pour la distribution
- actuelle diffusée <em>stable</em>, <em>PAS</em> pour <em>testing</em>
- ou <em>unstable</em>. Quand elle est diffusée, l'annonce est envoyée
- à la liste de diffusion &email-debian-security-announce; et elle est
- postée sur <url id="&url-debian-security-advisories;" name="la page
- de sécurité">. Les annonces de sécurité sont écrites et postées par
- les membres de l'équipe de sécurité. Cependant, ils ne verront aucun
- inconvénient à ce qu'un responsable leur apporte des informations ou
- écrive une partie du texte. Les informations qui devraient être
- présentes dans une annonce incluent :
- <list compact="compact">
- <item>
- <p>
- une description du problème et de sa portée, y compris :
- <list>
- <item>
- <p>
- le type du problème (usurpation de privilège, déni de service,
- etc.),
- </p>
- </item>
- <item>
- <p>
- quels sont les privilèges obtenus et par quels utilisateurs (si
- c'est le cas)
- </p>
- </item>
- <item>
- <p>
- comment il peut être exploité,
- </p>
- </item>
- <item>
- <p>
- si le problème peut être exploité à distance ou localement,
- </p>
- </item>
- <item>
- <p>
- comment le problème a été corrigé,
- </p>
- </item>
- </list>
- Ces informations permettent aux utilisateurs d'estimer la menace
- pesant sur leurs systèmes.
- </p>
- </item>
- <item>
- <p>
- les numéros de version des paquets affectés,
- </p>
- </item>
- <item>
- <p>
- les numéros de version des paquets corrigés,
- </p>
- </item>
- <item>
- <p>
- une information sur la façon de récupérer les paquets mis à jour
- (habituellement l'archive de sécurité Debian),
- </p>
- </item>
- <item>
- <p>
- des références à des annonces amont, des identifiants <url
- id="http://cve.mitre.org" name="CVE"> et toute autre information
- utile pour recouper les références de la vulnérabilité.
- </p>
- </item>
- </list>
- </p>
- </sect2>
- <sect2 id="bug-security-building">
- <heading>
- Préparer les paquets pour corriger des problèmes de sécurité
- </heading>
- <p>
- Une façon d'aider l'équipe de sécurité dans ses travaux est de lui
- fournir des paquets corrigés convenables pour une annonce de sécurité
- pour la version <em>stable</em> de Debian
- </p>
- <p>
- Quand une mise à jour de la version <em>stable</em> est effectuée, un
- soin particulier doit être apporté pour éviter de modifier le
- comportement du système ou d'introduire de nouveaux bogues. Pour
- cela, faites le moins de changements possibles pour corriger le
- bogue. Les utilisateurs et les administrateurs s'attendent à un
- comportement identique dans une version lorsque celle-ci est
- diffusée, donc tout changement qui est fait est susceptible de casser
- le système de quelqu'un. Ceci est spécialement vrai pour les
- bibliothèques : assurez-vous ne de jamais changer l'API ou
- l'ABI, aussi minimal que soit le changement.
- </p>
- <p>
- Cela veut dire que passer à une version amont supérieure n'est pas
- une bonne solution. À la place, les changements pertinents devraient
- être rétroportés vers la version présente dans la distribution
- <em>stable</em> de Debian. Habituellement, les développeurs amont
- veulent bien aider. Sinon, l'équipe de sécurité Debian peut le faire.
- </p>
- <p>
- Dans certains cas, il n'est pas possible de rétroporter un correctif
- de sécurité, par exemple, quand de grandes quantités de code source
- doivent être modifiées ou récrites. Si cela se produit, il peut être
- nécessaire de passer à une nouvelle version amont. Cependant, ceci
- n'est fait que dans des situations extrêmes et vous devez toujours
- coordonner cela avec l'équipe de sécurité au préalable.
- </p>
- <p>
- Il existe une autre règle de conduite liée à cela : testez
- toujours vos changements. Si une exploitation du problème existe,
- essayez-la et vérifiez qu'elle réussit sur le paquet non corrigé et
- échoue sur le paquet corrigé. Testez aussi les autres actions
- normales car parfois un correctif de sécurité peut casser de manière
- subtile des fonctionnalités qui ne semblent pas liées.
- </p>
- <p>
- N'incluez <strong>PAS</strong> de changements dans votre paquet qui
- ne soient pas liés directement à la correction de la
- vulnérabilité. Ceux-ci devraient être ensuite enlevés et cela perd du
- temps. S'il y a d'autres bogues dans votre paquet que vous aimeriez
- corriger, faites un envoi vers proposed-updates de la façon
- habituelle, après l'envoi de l'alerte de sécurité. Le mécanisme de
- mise à jour de sécurité n'est pas un moyen d'introduire des
- changements dans votre paquet qui seraient sinon rejetés de la
- distribution stable, n'essayez donc pas de faire cela, s'il vous
- plaît.
- </p>
- <p>
- Examinez et testez autant que possible vos changements. Vérifiez les
- différences avec la version précédente de manière répétée
- (<prgn>interdiff</prgn> du paquet <package>patchutils</package> et
- <prgn>debdiff</prgn> du paquet <package>devscripts</package> sont des
- outils utiles pour cela, voir <ref id="debdiff">).
- </p>
- <p>
- Assurez-vous de conserver les points suivants à l'esprit :
- <list>
- <item>
- <p>
- Ciblez la bonne distribution dans votre fichier
- <file>debian/changelog</file>. Pour <em>stable</em>, il s'agit de
- <tt>stable-security</tt> et pour <em>testing</em>, c'est
- <tt>testing-security</tt> et pour l'ancienne distribution stable,
- c'est <tt>oldstable-security</tt>. Ne ciblez ni
- <var>distribution</var>-proposed-updates, ni
- <tt>stable</tt> !
- </p>
- </item>
- <item>
- <p>
- L'envoi devra avoir « urgency=high ».
- </p>
- </item>
- <item>
- <p>
- Fournissez des entrées de changelog descriptives et
- complètes. D'autres personnes se baseront dessus pour déterminer
- si un bogue particulier a été corrigé. Incluez toujours une
- référence externe, de préférence un identifiant CVE, pour qu'elle
- puisse être recoupée. Incluez la même information dans le
- changelog pour <em>unstable</em> pour qu'il soit clair que le même
- bogue a été corrigé car cela est très utile pour vérifier que le
- bogue a été corrigé pour la prochaine version stable. Si aucun
- identifiant CVE n'a encore été assigné, l'équipe de sécurité en
- demandera un pour qu'il puisse être inclus dans le paquet et dans
- le changelog.
- </p>
- </item>
- <item>
- <p>
- Assurez-vous que le numéro de version est correct. Il doit être
- plus élevé que celui du paquet actuel, mais moins que ceux des
- paquets des versions des distributions suivantes. En cas de doute,
- testez-le avec <tt>dpkg --compare-versions</tt>. Soyez attentif à
- ne pas ré-utiliser un numéro de version que vous auriez déjà
- utilisé pour un précédent envoi. Pour <em>testing</em>, il doit y
- avoir un numéro de version supérieur dans <em>unstable</em>. S'il
- n'y en a pas encore (par exemple, si <em>testing</em> et
- <em>unstable</em> ont la même version), vous devez envoyer une
- nouvelle version vers <em>unstable</em> en premier.
- </p>
- </item>
- <item>
- <p>
- Ne faites pas d'envoi de source seul si votre paquet possède un ou
- plusieurs paquets binary-all (n'utilisez pas l'option <tt>-S</tt>
- de <prgn>dpkg-buildpackage</prgn>). L'infrastructure
- <prgn>buildd</prgn> ne construira pas ceux-ci. Ce point s'applique
- aux envois de paquets normaux également.
- </p>
- </item>
- <item>
- <p>
- Sauf si la source amont a été envoyée auparavant à
- security.debian.org (par une précédente mise à jour de sécurité),
- construisez le paquet avec la source amont complète
- (<tt>dpkg-buildpackage -sa</tt>). S'il y a déjà eu un précédent
- envoi à security.debian.org, vous pouvez faire un envoi sans le
- paquet source (<tt>dpkg-buildpackage -sd</tt>).
- </p>
- </item>
- <item>
- <p>
- Assurez-vous d'utiliser exactement le même nom
- <file>*.orig.tar.gz</file> que celui utilisé dans l'archive
- normale, sinon il ne sera pas possible de déplacer plus tard le
- correctif de sécurité dans l'archive principale.
- </p>
- </item>
- <item>
- <p>
- Compilez le paquet sur un système propre, dont tous les paquets
- appartiennent à la distribution pour laquelle vous construisez le
- paquet. Si vous n'avez pas un tel système, vous pouvez utiliser
- l'une des machines de debian.org (voir <ref id="server-machines">)
- ou mettez en place un chroot (voir <ref id="pbuilder"> et <ref
- id="debootstrap">).
- </p>
- </item>
- </list>
- </p>
- </sect2>
- <sect2 id="bug-security-upload">
- <heading>
- Mettre à jour le paquet corrigé
- </heading>
- <p>
- Vous <em>NE</em> devez <em>PAS</em> envoyer un paquet dans la file
- d'attente des envois de sécurité (oldstable-security,
- stable-security, etc.) sans l'accord préalable de l'équipe de
- sécurité. Si le paquet ne remplit pas exactement les exigences de
- l'équipe, il causera beaucoup de problèmes, ainsi que des délais dans
- la gestion de l'envoi indésirable.
- </p>
- <p>
- Vous <em>NE</em> devez <em>PAS</em> envoyer votre correction dans
- <em>proposed-updates</em> sans vous coordonner avec l'équipe de
- sécurité. Les paquets seront copiés de security.debian.org dans le
- répertoire <file>proposed-updates</file> automatiquement. Si un
- paquet avec le même numéro de version ou un numéro plus grand est
- déjà installé dans l'archive, la mise à jour de sécurité sera rejetée
- par le système d'archive. Ainsi, la distribution <em>stable</em> se
- retrouvera à la place sans la mise à jour de sécurité de ce paquet.
- </p>
- <p>
- Une fois que vous avez créé et testé le nouveau paquet et qu'il a été
- approuvé par l'équipe de sécurité, il doit être envoyé pour être
- installé dans les archives. Pour les envois de sécurité, l'adresse
- d'envoi est
- <tt>ftp://security-master.debian.org/pub/SecurityUploadQueue/</tt>.
- </p>
- <p>
- Une fois que l'envoi vers la file d'attente de sécurité a été
- accepté, le paquet sera automatiquement recompilé pour toutes les
- architectures et stocké pour vérification par l'équipe de sécurité.
- </p>
- <p>
- Les envois en attente d'acceptation ou de vérification ne sont
- accessibles que par l'équipe de sécurité. C'est nécessaire car il
- pourrait y avoir des correctifs pour des problèmes de sécurité qui ne
- peuvent pas encore être diffusés.
- </p>
- <p>
- Si une personne de l'équipe de sécurité accepte un paquet, il sera
- installé sur security.debian.org et proposé pour le répertoire
- <var>distribution</var>-proposed-updates qui convient sur ftp-master.
- </p>
- </sect2>
- </sect1>
- </sect>
- <sect id="archive-manip">
- <heading>
- Déplacer, effacer, changer le nom, adopter et abandonner des paquets
- </heading>
- <p>
- Certaines manipulations de l'archive ne sont pas possibles avec le
- processus de mise à jour automatisé. Elles sont appliquées manuellement
- par les développeurs. Ce chapitre décrit ce qu'il faut faire dans ces
- situations.
- </p>
- <sect1 id="moving-pkgs">
- <heading>
- Déplacer des paquets
- </heading>
- <p>
- Il se peut qu'un paquet puisse changer de section. Une nouvelle
- version d'un paquet de la section <tt>non-free</tt> pourrait, par
- exemple, être distribuée sous licence GNU GPL ; dans ce cas, le
- paquet doit être déplacé dans la section <tt>main</tt> ou
- <tt>contrib</tt><footnote><p>Reportez-vous à la <url
- id="&url-debian-policy;" name="charte Debian"> pour savoir dans quelle
- section un paquet doit être classé.</p></footnote>.
- </p>
- <p>
- Si vous avez besoin de modifier la section de l'un de vos paquets,
- modifiez les informations de contrôle du paquet pour le placer dans la
- section désirée et téléchargez à nouveau votre paquet dans
- l'archive. Reportez-vous à la <url id="&url-debian-policy;"
- name="charte Debian"> pour en savoir plus. Vous devez vous assurer
- d'inclure le fichier <file>.orig.tar.gz</file> dans votre envoi (même si
- vous n'envoyez pas de nouvelle version amon) ou il n'apparaîtra pas dans
- la nouvelle section avec le reste du paquet. Si votre nouvelle section
- est valide, il sera déplacé automatiquement. Si ce n'est pas le cas,
- contactez les responsables ftp pour comprendre ce qui s'est passé.
- </p>
- <p>
- Si vous avez besoin de modifier la sous-section de l'un de vos paquets
- (<tt>devel</tt> ou <tt>admin</tt> par exemple), la procédure est
- légèrement différente. Modifiez la sous-section dans le fichier de
- contrôle de votre paquet et téléchargez-le. Il vous faudra ensuite
- demander la modification du fichier <em>override</em> comme décrit
- dans la section <ref id="override-file">.
- </p>
- </sect1>
- <sect1 id="removing-pkgs">
- <heading>
- Supprimer des paquets
- </heading>
- <p>
- Si, pour une raison ou une autre, vous avez besoin de supprimer
- complètement un paquet de l'archive (disons qu'il s'agit d'une vieille
- bibliothèque devenue inutile que l'on conservait pour des raisons de
- compatibilité), il vous faudra envoyer un rapport de bogue concernant
- le pseudo-paquet <tt>ftp.debian.org</tt> et demander sa
- suppression ; comme pour tous les bogues, ce bogue devrait être
- de gravité normale. N'oubliez pas de préciser de quelle distribution
- le paquet doit être supprimé. Normalement, vous ne devriez avoir à
- supprimer que des paquets d'<em>unstable</em> ou
- d'<em>experimental</em>. Les paquets de <em>testing</em> ne sont pas
- supprimés directement. Ils sont plutôt enlevés automatiquement après
- que le paquet a été supprimé d'<em>unstable</em> et si aucun paquet de
- <em>testing</em> n'en dépend.
- </p>
- <p>
- Il existe une exception pour laquelle il n'est pas nécessaire de faire
- une demande explicite de suppression : si un paquet (source ou
- binaire) est orphelin, il sera supprimé de façon semi-automatique. Pour
- un paquet binaire, cela veut dire s'il n'y a plus de paquet source
- produisant le paquet binaire ; si le paquet binaire n'est
- simplement plus produit pour certaines architectures, une demande de
- suppression est toujours nécessaire. Pour un paquet source, cela veut
- dire que tous les paquets binaires auxquels il se réfère ont été
- récupérés par un autre paquet source.
- </p>
- <p>
- Vous devez détailler dans votre demande de suppressions les raisons
- justifiant cette
- demande. Ceci a pour but d'éviter les suppressions non désirées et de
- garder une trace de la raison pour laquelle un paquet a été
- supprimé. Par exemple, vous pouvez fournir le nom du paquet qui
- remplace celui à supprimer.
- </p>
- <p>
- Vous ne pouvez demander la suppression d'un paquet que si vous en êtes
- le responsable. Si vous voulez supprimer un autre paquet, vous devez
- obtenir l'accord de son responsable.
- </p>
- <p>
- Si vous ne savez pas bien si un paquet peut être supprimé, demandez
- l'avis des autres développeurs sur la liste &email-debian-devel;. Le
- programme <prgn>apt-cache</prgn> du paquet <package>apt</package>
- pourra aussi vous être utile. La commande <tt>apt-cache showpkg
- <var>paquet</var> </tt> vous indiquera, entre autres, les paquets qui
- dépendent de <var>paquet</var>.
- Parmi d'autres programmes utiles, citons <tt>apt-cache rdepends</tt>,
- <prgn>apt-rdepends</prgn> et <prgn>grep-dctrl</prgn>.
- Le retrait de paquets orphelins est discuté sur &email-debian-qa;.
- </p>
- <p>
- Une fois que le paquet a été supprimé, les bogues du paquet doivent
- être gérés. Soit ils sont réattribués à un autre paquet dans le cas où
- le code actuel a évolué en un autre paquet (par exemple,
- <tt>libfoo12</tt> a été supprimé parce que <tt>libfoo13</tt> le
- remplace) ou ils sont fermés si le logiciel ne fait simplement plus
- partie de Debian.
- </p>
- <sect2>
- <heading>
- Supprimer des paquets dans <tt>Incoming</tt>
- </heading>
- <p>
- Par le passé, il était possible de supprimer un paquet de
- <file>Incoming</file>. Cependant, ce n'est plus possible depuis la
- mise en place du nouveau système de file d'attente. Il vous faudra
- télécharger une nouvelle version de votre paquet avec un numéro de
- version plus élevé que celui que vous voulez remplacer. Les deux
- versions seront installées dans l'archive mais seule la plus récente
- sera accessible dans <em>unstable</em> car la précédente sera
- immédiatement remplacée par la nouvelle. Toutefois, si vous testez
- correctement vos paquets, le besoin d'en remplacer un ne devrait pas
- être trop fréquent.
- </p>
- </sect2>
- </sect1>
- <sect1>
- <heading>
- Remplacer un paquet ou changer son nom
- </heading>
- <p>
- Si vous vous trompez en nommant un paquet, vous devrez intervenir en
- deux étapes pour changer son nom. D'abord, modifiez votre fichier
- <file>debian/control</file> pour que votre nouveau paquet remplace et
- entre en conflit avec l'ancien paquet que vous voulez remplacer
- (reportez-vous à la <url id="&url-debian-policy;" name="charte
- Debian"> pour les détails). Une fois que votre paquet est installé
- dans l'archive, faites un rapport de bogue concernant le pseudo-paquet
- <tt>ftp.debian.org</tt> et demandez la suppression du paquet mal
- nommé. N'oubliez pas de réattribuer correctement les bogues du paquet
- en même temps.
- </p>
- <p>
- D'autres fois, vous pouvez commettre une erreur en construisant le
- paquet et vous désirez le remplacer. La seule façon de faire est
- d'incrémenter le numéro de version et d'envoyer une nouvelle
- version. L'ancienne version expirera de la façon habituelle. Notez que
- ceci s'applique à chaque partie de votre paquet, y compris les
- sources : si vous désirez remplacer l'archive source amont de
- votre paquet, vous devez l'envoyer avec un numéro de version
- différent. Une possibilité simple est de remplacer
- <file>foo_1.00.orig.tar.gz</file> par
- <file>foo_1.00+0.orig.tar.gz</file>. Cette restriction donne à chaque
- fichier du site ftp un nom unique, ce qui aide à garantir la
- consistance dans le réseau des miroirs.
- </p>
- </sect1>
- <sect1 id="orphaning">
- <heading>
- Abandonner un paquet
- </heading>
- <p>
- Si vous ne pouvez plus maintenir un paquet, vous devez en informer les
- autres et faire le nécessaire pour qu'il soit marqué
- <em>abandonné</em> (i.e. <em>orphaned</em>). Vous devriez aussi
- remplacer votre nom par <tt>Debian QA Group &orphan-address;</tt> dans
- le champ <tt>maintainer</tt> du paquet et faire un rapport de bogue
- sur le pseudo-paquet <package>wnpp</package>. Le titre de votre
- rapport de bogue devrait être
- « <tt>O<footnote><p><em>Orphaned</em> :
- abandonné.</p></footnote>: <var>paquet</var> — <var>courte
- description</var></tt> » pour indiquer que le paquet est
- abandonné. La gravité du bogue sera <em>normale</em> ; si le
- paquet a une priorité standard ou supérieure, elle devrait être
- <em>importante</em>. Si vous le jugez nécessaire, envoyez une copie à
- &email-debian-devel; en mettant cette adresse dans le champ
- X-Debbugs-CC: de l'en-tête du message. N'utilisez pas le champ CC: car
- de cette manière le sujet du message ne contiendra pas le numéro du
- bogue.
- </p>
- <p>
- Si vous avez simplement l'intention de donner le paquet, mais que vous
- pouvez conserver sa maintenance pour le moment, vous devriez à la
- place soumettre un rapport de bogue sur <package>wnpp</package> et
- l'intituler <tt>RFA: <var>paquet</var> -- <var>description
- courte</var></tt>. <tt>RFA</tt> veut dire <em>Request For
- Adoption</em> (demande d'adoption).
- </p>
- <p>
- Vous pouvez trouver plus d'informations sur les <url id="&url-wnpp;"
- name="pages web WNPP"><footnote><p><em>Work-needing and prospective
- packages</em> : paquets en souffrance et paquets
- souhaités.</p></footnote>.
- </p>
- </sect1>
- <sect1 id="adopting">
- <heading>
- Adopter un paquet
- </heading>
- <p>
- Une liste des paquets en attente de nouveau responsable est disponible
- à la page <url id="&url-wnpp;" name="paquets en souffrance et paquets
- souhaités">. Si vous voulez prendre en charge un paquet de cette
- liste, reportez-vous à la page mentionnée ci-dessus pour connaître la
- procédure à suivre.
- </p>
- <p>
- Prendre un paquet parce qu'il vous semble que celui-ci est négligé
- n'est pas correct — ce serait un détournement de
- paquet. Vous pouvez prendre contact avec le responsable actuel et lui
- demander si vous pouvez prendre en charge ce paquet. Si vous avez le
- sentiment qu'un responsable est parti sans prévenir depuis un moment,
- veuillez vous reporter à <ref id="mia-qa">).
- </p>
- <p>
- Généralement, vous ne pouvez pas adopter un paquet sans l'accord du
- responsable actuel. Même s'il vous ignore, ce n'est pas une raison
- pour le faire. Les plaintes à propos des responsables devraient être
- portées sur la liste de diffusion des développeurs. Si la discussion
- ne se termine pas par une conclusion positive et que le problème est
- de nature technique, envisagez de porter le cas à l'attention du
- comité technique (voir la <url id="&url-tech-ctte;" name="page web du
- comité technique"> pour plus d'information).
- </p>
- <p>
- Si vous reprenez un vieux paquet, vous voudrez sûrement que le système
- de suivi des bogues indique que vous êtes le responsable du
- paquet. Cela se produira automatiquement une fois que vous aurez
- installé une nouvelle version du paquet dans l'archive avec le champ
- <tt>Maintainer</tt> à jour. Cela peut prendre quelques heures après le
- téléchargement. Si vous pensez ne pas avoir de mise à jour à faire
- pour un moment, vous pouvez utiliser le <ref id="pkg-tracking-system">
- pour recevoir les rapports de bogue. Cependant, assurez-vous que cela
- ne pose aucun problème à l'ancien responsable de continuer à recevoir
- les bogues durant ce temps.
- </p>
- </sect1>
- </sect>
- <sect id="porting">
- <heading>
- Le portage
- </heading>
- <p>
- Debian accepte un nombre croissant d'architectures. Même si vous n'êtes
- pas un porteur et même si vous n'utilisez qu'une architecture, il est
- de votre responsabilité de développeur d'être attentif aux questions de
- portabilité. C'est pourquoi il est important que vous lisiez ce
- chapitre même si vous n'êtes pas un porteur.
- </p>
- <p>
- Porter un paquet consiste à faire un paquet binaire pour des
- architectures différentes de celle du paquet binaire fait par le
- responsable du paquet. C'est une activité remarquable et
- essentielle. En fait, les porteurs sont à l'origine de la plupart des
- compilations de paquets Debian. Pour un paquet binaire <em>i386</em>,
- par exemple, il faut compter une recompilation pour chaque autre
- architecture, soit un total de &number-of-arches; recompilations.
- </p>
- <sect1 id="kind-to-porters">
- <heading>
- Être courtois avec les porteurs
- </heading>
- <p>
- Les porteurs ont une tâche remarquable et difficile car ils doivent
- gérer un grand nombre de paquets. Idéalement, tout paquet source
- devrait compiler sans modification. Malheureusement, c'est rarement le
- cas. Cette section contient une liste d'erreurs commises régulièrement
- par les responsables Debian — problèmes courants qui bloquent
- souvent les porteurs et compliquent inutilement leur travail.
- </p>
- <p>
- Ici, la première et la plus importante chose est de répondre
- rapidement aux rapports de bogues et remarques soulevées par les
- porteurs. Traitez-les courtoisement, comme s'ils étaient
- co-responsables de vos paquets (ce qu'ils sont d'une certaine
- manière). Merci pour votre indulgence envers des rapports de bogue
- succincts ou peu clairs ; faites de votre mieux pour éliminer le
- problème.
- </p>
- <p>
- Les problèmes les plus couramment rencontrés par les porteurs sont
- causés par des erreurs de mise en paquet dans le paquet source. Voici
- un pense-bête pour les choses auxquelles vous devez être
- attentif :
- <enumlist numeration="arabic">
- <item>
- <p>
- Vérifiez que les champs <tt>Build-Depends</tt> et
- <tt>Build-Depends-Indep</tt> du fichier <file>debian/control</file>
- sont corrects. Le meilleur moyen de le vérifier est d'utiliser le
- paquet <package>debootstrap</package> pour créer un environnement
- <em>unstable</em> <em>chrooté</em> (voir <ref
- id="debootstrap">). Dans cet environnement <em>chrooté</em>, il
- faudra installer le paquet <package>build-essential</package> et
- tous les paquets mentionnés dans les champs <tt>Build-Depends</tt>
- et <tt>Build-Depends-Indep</tt>. Ensuite, vous essayerez de
- fabriquer votre paquet dans cet environnement. Ces étapes peuvent
- être automatisées en utilisant le programme <prgn>pbuilder</prgn>
- qui est fourni par le paquet de même nom (voir <ref
- id="pbuilder">).
- </p>
- <p>
- Si vous n'arrivez pas à installer un environnement
- <em>chrooté</em>, <prgn>dpkg-depcheck</prgn> pourra peut-être vous
- aider (voir <ref id="dpkg-depcheck">).
- </p>
- <p>
- Consultez la <url id="&url-debian-policy;" name="charte Debian">
- pour en savoir plus sur les dépendances de fabrication.
- </p>
- </item>
- <item>
- <p>
- Ne choisissez pas d'autres valeurs que <em>all</em> ou <em>any</em>
- pour le champ architecture sans avoir de bonnes raisons pour le
- faire. Trop souvent, les développeurs ne respectent pas les
- instructions de la <url id="&url-debian-policy;" name="charte
- Debian">. Choisir la valeur « i386 » est la plupart du
- temps incorrect.
- </p>
- </item>
- <item>
- <p>
- Vérifiez que votre paquet source est bon. Faites <tt>dpkg-source -x
- <var>paquet</var>.dsc</tt> pour vous assurer que le paquet se
- décompresse correctement. En utilisant le résultat de ce test,
- construisez votre paquet binaire à l'aide de la commande
- <prgn>dpkg-buildpackage</prgn>.
- </p>
- </item>
- <item>
- <p>
- Vérifiez que les fichiers <file>debian/files</file> et
- <file>debian/substvars</file> ne sont pas dans votre paquet
- source. Ils doivent être effacés par la cible <em>clean</em> de
- <file>debian/rules</file>.
- </p>
- </item>
- <item>
- <p>
- Assurez-vous que vous ne vous appuyez pas sur des éléments de
- configuration ou des logiciels installés ou modifiés
- localement. Par exemple, vous ne devriez jamais appeler des
- programmes du répertoire <file>/usr/local/bin</file> ou de
- répertoires équivalents. Essayez de ne pas vous appuyer sur des
- logiciels configurés de manière spéciale. Essayez de construire
- votre paquet sur une autre machine, même s'il s'agit de la même
- architecture.
- </p>
- </item>
- <item>
- <p>
- Ne vous appuyez pas sur une installation préexistante de votre
- paquet (un sous-cas de la remarque précédente).
- </p>
- </item>
- <item>
- <p>
- Si possible, ne vous appuyez pas sur une particularité présente
- dans un compilateur précis ou dans une certaine version d'un
- compilateur. Si vous ne pouvez pas faire autrement, assurez-vous
- que les dépendances de fabrication reflètent bien cette
- restriction. Dans ce cas, vous cherchez sûrement les problèmes car
- quelques architectures pourraient choisir un compilateur différent.
- </p>
- </item>
- <item>
- <p>
- Vérifiez que votre fichier <file>debian/rules</file> distingue les
- cibles <em>binary-arch</em> et <em>binary-indep</em> comme l'exige
- la charte Debian. Vérifiez que ces cibles sont indépendantes l'une
- de l'autre, c'est-à-dire, qu'il n'est pas nécessaire d'invoquer
- l'une de ces cibles avant d'invoquer l'autre. Pour vérifier cela,
- essayez d'exécuter <tt>dpkg-buildpackage -B</tt>.
- </p>
- </item>
- </enumlist>
- </p>
- </sect1>
- <sect1 id="porter-guidelines">
- <heading>
- Instructions pour les mises à jour des porteurs
- </heading>
- <p>
- Si le paquet se construit tel quel sur l'architecture que vous visez,
- vous avez de la chance et votre travail est facile. Cette section
- s'applique dans ce cas ; elle décrit comment construire et
- installer correctement votre paquet binaire dans l'archive Debian. Si
- vous devez modifier le paquet pour le rendre compilable sur votre
- architecture cible vous devez faire une mise à jour des sources,
- consultez la section <ref id="nmu-guidelines">.
- </p>
- <p>
- Pour un envoi de portage, ne faites pas de changement dans les
- sources. Vous n'avez pas besoin de modifier les fichiers du paquet
- source (cela inclut le fichier <file>debian/changelog</file>).
- </p>
- <p>
- La manière d'invoquer <prgn>dpkg-buildpackage</prgn> est la
- suivante : <tt>dpkg-buildpackage -B
- -m<var>adresse-porteur</var></tt>. Bien sûr, remplacez
- <var>adresse-porteur</var> par votre adresse électronique. Cette
- commande construira les parties du paquet qui dépendent de
- l'architecture, en utilisant la cible <em>binary-arch</em> de
- <file>debian/rules</file>.
- </p>
- <p>
- Si vous travaillez sur une machine Debian pour vos efforts de portage
- et que vous devez signer votre envoi localement pour son acceptation
- dans l'archive, vous pouvez exécuter <prgn>debsign</prgn> sur votre
- fichier <file>.changes</file> pour qu'il soit signé de manière commode
- ou utilisez le mode de signature à distance de <prgn>dpkg-sig</prgn>.
- </p>
- <sect2 id="binary-only-nmu">
- <heading>
- Mises à jour indépendantes binaires ou recompilations
- </heading>
- <p>
- Parfois, l'envoi du portage initial pose problème car l'environnement
- dans lequel le paquet a été construit n'était pas bon (bibliothèques
- plus à jour ou obsolètes, mauvais compilateur, etc.). Il se peut que
- vous ayez à le recompiler dans un environnement mis à
- jour. Cependant, dans ce cas, vous devez changer le numéro de version
- pour que les mauvais anciens paquets soient remplacés dans l'archive
- Debian (<prgn>katie</prgn> refuse d'installer de nouveaux paquets
- s'ils n'ont pas un numéro de version supérieur à celui actuellement
- disponible).
- </p>
- <p>
- Vous devez vous assurer que votre mise à jour indépendante binaire ne
- rend pas le paquet non installable. Cela peut arriver si un paquet
- source génère des paquets dépendants et indépendants de
- l'architecture qui dépendent les uns des autres <em>via</em>
- $(Source-Version).
- </p>
- <p>
- Malgré les modifications nécessaires du changelog, ce type de mise à
- jour reste une mise à jour indépendante binaire — il n'est
- pas nécessaire de reconsidérer le statut des paquets binaires des
- autres architectures pour les marquer périmés ou à recompiler.
- </p>
- <p>
- Ces recompilations nécessitent des numéros de version
- « magiques » pour que le système de maintenance de
- l'archive comprenne que, bien qu'il y ait une nouvelle version, il
- n'y a pas eu de modification des sources. Si vous ne faites pas cela
- correctement, les administrateurs de l'archive rejetteront votre mise
- à jour (car il n'y aura pas de code source associé).
- </p>
- <p>
- La « magie » d'une mise à jour indépendante par
- recompilation uniquement est déclenchée par l'utilisation d'un
- suffixe ajouté au numéro de version du paquet de la forme
- b<numéro>. Par exemple, si la dernière version que vous avez
- recompilée était la version 2.9.3, votre mise à jour indépendante
- aura le numéro de version 2.9-3+b1. Si la dernière version était
- 3.4+b1 (i.e. un paquet natif avec une précédente mise à jour
- indépendante par recompilation), votre mise à jour indépendant aura
- le numéro de version 3.4+b2. <footnote><p>Par le passé, de telles
- mises à jour indépendantes utilisaient le numéro de troisième niveau
- de la partie Debian de la révision pour dénoter l'état de
- recompilation uniquement ; cependant, cette syntaxe était
- ambigüe pour les paquets natifs et ne permettait pas un ordre correct
- des mises à jour indépendantes par recompilation uniquement, des
- mises à jour indépendantes de source et des mises à jour
- indépendantes de sécurité sur le même paquet et elle a donc été
- abandonnée en faveur de cette nouvelle syntaxe.</p></footnote>
- </p>
- <p>
- De manière similaire aux envois du porteur initial, la façon correcte
- d'invoquer <prgn>dpkg-buildpackage</prgn> est <tt>dpkg-buildpackage
- -B</tt> pour ne construire que les parties dépendant de
- l'architecture du paquet.
- </p>
- </sect2>
- <sect2 id="source-nmu-when-porter">
- <heading>
- Quand faire une mise à jour indépendante source pour un
- portage ?
- </heading>
- <p>
- Les porteurs qui font des mises à jour indépendantes sources suivent
- généralement les instructions de la section <ref id="nmu"> tout comme
- les non-porteurs. Les délais d'attente sont cependant plus courts car
- les porteurs doivent manipuler un grand nombre de paquets. À nouveau,
- la situation diffère selon la distribution visée. Elle varie
- également selon que l'architecture est candidate pour inclusion dans
- la prochaine version stable ; les responsables de publication
- décident et annoncent quelles architectures sont candidates.
- </p>
- <p>
- Si vous êtes porteur et faites une mise à jour pour
- <em>unstable</em>, les instructions précédentes sont applicables à
- deux différences près. Tout d'abord, le temps d'attente raisonnable
- — délai entre le moment où vous envoyez un rapport au
- système de suivi des bogues et le moment où vous pouvez faire une
- mise à jour indépendante <em>(NMU)</em> — est de sept
- jours. Ce délai peut être raccourci si le problème est crucial et met
- l'effort de portage en difficulté : c'est à la discrétion de l'équipe
- de portage. (Souvenez-vous, il ne s'agit pas d'un règlement, mais de
- recommandations communément acceptées). Pour les envois de
- <em>stable</em> ou <em>testing</em>, veuillez tout d'abord vous
- coordonner avec l'équipe de publication appropriée.
- </p>
- <p>
- Deuxième différence, les porteurs qui font des mises à jour
- indépendantes sources doivent choisir une gravité <em>sérieuse</em>
- (i.e. <em>serious</em>) ou supérieure quand ils envoient leur rapport
- au système de suivi des bogues. Ceci assure qu'un paquet source
- unique permet de produire un paquet binaire pour chaque architecture
- supportée au moment de la sortie de la distribution. Il est très
- important d'avoir un paquet source et un paquet binaire pour toutes
- les architectures pour être conforme à plusieurs licences.
- </p>
- <p>
- Les porteurs doivent éviter d'implémenter des contournements pour des
- bogues de l'environnement de compilation, du noyau ou de la
- libc. Quelques fois, ces contournements sont inévitables. Si vous
- devez faire quelque chose de ce genre, marquez proprement vos
- modifications avec des <tt>#ifdef</tt> et documentez votre
- contournement pour que l'on sache le retirer une fois que le problème
- aura disparu.
- </p>
- <p>
- Les porteurs peuvent aussi avoir une adresse où ils publient le
- résultat de leur travail pendant le délai d'attente. Ainsi, d'autres
- personnes peuvent bénéficier du travail du porteur même pendant ce
- délai. Bien sûr, ces adresses n'ont rien d'officiel, alors soyez sur
- vos gardes si vous les utilisez.
- </p>
- </sect2>
- </sect1>
- <sect1 id="porter-automation">
- <heading>
- Infrastructure de portage et automatisation
- </heading>
- <p>
- Il existe une infrastructure et plusieurs outils pour faciliter
- l'automatisation du portage des paquets. Cette section contient un
- bref aperçu de cette automatisation et du portage de ces outils ;
- veuillez vous reporter à la documentation des paquets ou les
- références pour une information complète.
- </p>
- <sect2>
- <heading>
- Listes de diffusion et pages web
- </heading>
- <p>
- Les pages web contenant l'état de chaque portage peuvent être
- trouvées à <url id="&url-debian-ports;">.
- </p>
- <p>
- Chaque portage de Debian possède sa propre liste de diffusion. La
- liste des listes de diffusion de portage peut être trouvée à <url
- id="&url-debian-port-lists;">. Ces listes sont utilisées pour
- coordonner les porteurs et pour mettre en relation les utilisateurs
- d'un portage donné avec les porteurs.
- </p>
- </sect2>
- <sect2>
- <heading>
- Outils pour les porteurs
- </heading>
- <p>
- Les descriptions de plusieurs outils de portage peuvent être trouvées
- dans les <ref id="tools-porting">.
- </p>
- </sect2>
- <sect2 id="buildd">
- <heading>
- <package>buildd</package>
- </heading>
- <p>
- Le système <package>buildd</package> est un système distribué pour la
- compilation d'une distribution. Il est habituellement utilisé en
- conjonction avec des automates de compilation ; ce sont des
- machines « esclaves » qui récupèrent des paquets sources et
- tentent de les compiler. Il est aussi possible d'interagir par
- courrier électronique avec ce système. Cette interface est utilisée
- par les porteurs pour récupérer un paquet source (en général, un
- paquet qui ne peut être compilé automatiquement) et travailler
- dessus.
- </p>
- <p>
- <package>buildd</package> n'est pas disponible sous forme de
- paquet ; pourtant, la plupart des équipes de porteurs
- l'utilisent aujourd'hui ou ont prévu de l'utiliser bientôt. L'outil
- de construction automatisé réel est dans le paquet
- <package>sbuild</package>, voir la description dans <ref
- id="sbuild">. Le système <package>buildd</package> regroupe également
- un ensemble de composants très utiles, continuellement utilisés, mais
- non encore mis en paquet, tels que <prgn>andrea</prgn> et
- <prgn>wanna-build</prgn>.
- </p>
- <p>
- Une partie des informations produites par <package>buildd</package>
- — utiles pour les porteurs — est disponible sur
- la toile à l'adresse <url id="&url-buildd;">. Ces informations
- incluent les résultats produits toutes les nuits par
- <prgn>andrea</prgn> (dépendances des sources) et
- <prgn>quinn-diff</prgn> (paquets à recompiler).
- </p>
- <p>
- Nous sommes très fiers de ce système car il a de nombreux usages
- potentiels. Des groupes de développeurs indépendants peuvent utiliser
- ce système pour créer différentes saveurs de Debian — qui
- peuvent être ou ne pas être intéressantes pour tous (par exemple, une
- version de Debian compilée avec des vérifications relatives à
- <prgn>gcc</prgn>). Ce système nous permettra aussi de recompiler
- rapidement toute une distribution.
- </p>
- <p>
- Les administrateurs des buildds pour chaque architecture peuvent être
- contactés à l'adresse électronique $arch@buildd.debian.org.
- </p>
- </sect2>
- </sect1>
- <sect1 id="packages-arch-specific">
- <heading>
- Quand votre paquet <em>n'est pas</em> portable
- </heading>
- <p>
- Certains paquets ont encore des problèmes pour être construits et/ou
- pour fonctionner sur certaines des architectures prises en charge par
- Debian et ne peuvent pas du tout être portés, ou pas dans un laps de
- temps raisonnable. Un exemple est un paquet qui est spécifique SGVA
- (i386 seulement) ou qui utilise des fonctionnalités spécifiques au
- matériel qui ne sont pas gérées sur toutes les architectures.
- </p>
- <p>
- Pour éviter que des paquets cassés soient envoyés dans l'archive et
- qu'ils fassent perdre du temps des buildd, vous devez faire plusieurs
- choses :
- </p>
- <p>
- <list>
- <item>
- <p>
- Tout d'abord, assurez-vous que votre paquet <em>échoue</em> à la
- compilation sur les architectures qu'il ne gère pas. Il y a
- plusieurs moyens de faire cela. Le moyen préféré est d'avoir une
- petite suite de tests pendant la construction qui testera la
- fonctionnalité et qui échouera si cela ne fonctionne pas. C'est de
- toute façon une bonne idée et empêchera des (certains) envois
- cassés pour toutes les architectures, et cela permettra également
- au paquet d'être construit dès que la fonctionnalité nécessaire est
- disponible.
- </p>
- <p>
- De plus, si vous croyez que la liste des architectures gérées est
- plutôt constante, vous devriez changer « any » en une
- liste des architectures gérées dans le fichier
- <file>debian/control</file>. Ainsi, la construction échouera
- également et l'indiquera à un lecteur humain sans vraiment essayer.
- </p>
- </item>
- <item>
- <p>
- Pour empêcher les compilateurs automatiques de tenter sans raison
- de construire votre paquet, il doit être inclus dans
- <file>packages-arch-specific</file>, une liste utilisée par le
- script <prgn>wanna-build</prgn>. La version actuelle est disponible
- à <url
- id="http://cvs.debian.org/srcdep/Packages-arch-specific?cvsroot=dak"> ;
- veuillez consulter le début du fichier pour savoir qui contacter
- pour le modifier.
- </p>
- </item>
- </list>
- </p>
- <p>
- Veuillez noter qu'il est insuffisant de simplement ajouter votre
- paquet à Packages-arch-specific sans le faire également échouer lors
- de compilation sur les architectures non gérées : un porteur ou
- toute autre personne essayant de construire votre paquet peut
- accidentellement l'envoyer sans remarquer qu'il ne fonctionne pas. Si
- dans le passé, certains paquets binaires ont été envoyés pour des
- architectures non gérées, demandez leur suppression en remplissant un
- bogue sur <package>ftp.debian.org</package>.
- </p>
- </sect1>
- </sect>
- <sect id="nmu">
- <heading>
- Mise à jour indépendante
- </heading>
- <p>
- Dans certaines circonstances, il est nécessaire qu'une personne autre
- que le responsable d'un paquet fasse une mise à jour de ce paquet. Ce
- type de mise à jour est désigné en anglais par l'expression
- <em>non-maintainer upload (NMU)</em>. Dans le présent document, nous
- traduisons librement cette expression par « mise à jour
- indépendante ».
- </p>
- <p>
- Cette section ne traite que des mises à jour indépendantes de source,
- c.-à-d., les mises à jour qui envoient une nouvelle version d'un
- paquet. Pour les mises à jour indépendantes par des porteurs ou des
- membres de la QA, veuillez consulter <ref id="binary-only-nmu">. Si un
- buildd construit et envoie un paquet, cela est également à strictement
- parler une NMU binaire. Veuillez consulter <ref id="buildd"> pour plus
- d'informations.
- </p>
- <p>
- La raison principale pour laquelle une mise à jour indépendante est
- réalisée est quand un développeur a besoin de corriger le paquet d'un
- autre développeur pour résoudre des problèmes sérieux ou des bogues
- paralysants ou quand le responsable d'un paquet ne peut pas fournir une
- correction dans un délai raisonnable.
- </p>
- <p>
- Tout d'abord, il est capital que ces mises à jour indépendantes soient
- aussi peu intrusives que possible. Ne faites pas de ménage, ne modifiez
- pas le nom des modules ou des fichiers, ne déplacez pas les
- répertoires ; plus généralement, ne corrigez pas ce qui n'est pas
- cassé. Faites un correctif aussi petit que possible. Si certaines
- choses froissent votre sens de l'esthétique, parlez-en au responsable
- du paquet, au responsable amont ou soumettez un rapport de
- bogue. Quoiqu'il en soit, les changements esthétiques <em>ne doivent
- pas</em> être effectués lors d'une mise à jour indépendante.
- </p>
- <p>
- Et souvenez-vous du Serment d'Hippocrate « Par dessus tout,
- ne pas faire de mal ». Il est préférable de laisser un paquet avec
- un bogue ouvert grave plutôt qu'appliquer un correctif non fonctionnel
- ou un correctif qui cache le bogue sans le résoudre.
- </p>
- <sect1 id="nmu-guidelines">
- <heading>
- Comment faire une mise à jour indépendante ?
- </heading>
- <p>
- Les mises à jour indépendantes qui corrigent des bogues de gravité
- importante, sérieuse et plus élevée sont encouragées et
- acceptées. Vous devriez vous efforcer de contacter le responsable
- actuel du paquet : il est peut-être sur le point d'envoyer un
- correctif pour le problème ou il a peut-être une meilleure solution.
- </p>
- <p>
- Les mises à jour indépendantes doivent être réalisées pour assister un
- responsable de paquet à résoudre des bogues. Les responsables
- devraient être reconnaissants pour cette aide et les personnes faisant
- la mise à jour indépendante devraient respecter les décisions du
- responsable et tenter d'aider personnellement le responsable dans son
- travail.
- </p>
- <p>
- Une mise à jour indépendante devrait suivre toutes les conventions
- décrites dans cette section. Pour un envoi vers <em>testing</em> ou
- <em>unstable</em>, l'ordre suivant des étapes est recommandé :
- </p>
- <p>
- <list>
- <item>
- <p>
- Vérifiez que les bogues du paquet qui devraient être corrigés par
- la mise à jour indépendante sont bien référencés dans le système de
- suivi des bogues. S'ils n'y sont pas, faites des rapports de bogue
- immédiatement.
- </p>
- </item>
- <item>
- <p>
- Attendez la réponse du responsable quelques jours. Si vous
- n'obtenez aucune réponse, vous pouvez l'aider en lui envoyant le
- correctif qui corrige le bogue. N'oubliez pas de marquer le bogue
- avec le mot-clé « patch ».
- </p>
- </item>
- <item>
- <p>
- Patientez quelques jours. Si vous n'avez toujours aucune réponse du
- responsable, envoyez-lui un courrier annonçant votre intention
- d'effectuer une mise à jour indépendante du paquet. Préparez la NMU
- comme décrit dans cette section et testez-la soigneusement sur
- votre machine (cf. <ref id="sanitycheck">). Re-vérifiez que votre
- correctif n'a aucun effet de bord inattendu. Assurez-vous que votre
- correctif est aussi minimaliste et non intrusif que possible.
- </p>
- </item>
- <item>
- <p>
- Envoyez votre paquet à incoming dans <file>DELAYED/7-day</file>
- (cf. <ref id="delayed-incoming">), envoyez le correctif final au
- responsable par le BTS et expliquez-lui qu'il a 7 jours pour réagir
- s'il veut annuler la NMU.
- </p>
- </item>
- <item>
- <p>
- Suivez ce qui se passe, vous êtes responsable pour tout bogue que
- vous auriez introduit avec votre NMU. Vous devriez probablement
- utiliser le <ref id="pkg-tracking-system"> (PTS) pour vous tenir
- informé de l'état du paquet après votre NMU.
- </p>
- </item>
- </list>
- </p>
- <p>
- Parfois, le responsable de version ou un groupe organisé de
- développeurs peut annoncer une certaine période de temps au cours de
- laquelle les règles de mise à jour indépendante seront plus
- souples. Ceci implique habituellement une période plus courte
- d'attente avant d'envoyer des correctifs et une période de délai plus
- courte. Il est important de noter que, même au cours de ces
- « chasses aux bogues », la personne désirant faire la mise à
- jour indépendante doit remplir des bogues et contacter en premier le
- développeur, et ensuite seulement passer à l'action. Veuillez vous
- reporter à <ref id="qa-bsp"> pour des détails.
- </p>
- <p>
- Pour la distribution <em>testing</em>, les règles peuvent être
- changées par les responsables de publication. Veuillez porter une
- attention spéciale au fait que le moyen habituel pour un paquet
- d'entrer dans <em>testing</em> est de passer par <em>unstable</em>.
- </p>
- <p>
- Pour la distribution <em>stable</em>, veuillez y apporter une
- attention supplémentaire. Bien sûr, les responsables de publication
- peuvent également modifier les règles ici. Veuillez vérifier avant
- votre envoi que tous vos changements sont acceptables pour inclusion
- dans la prochaine version stable par le responsable de publication.
- </p>
- <p>
- Quand un bogue de sécurité est détecté, l'équipe de sécurité peut
- effectuer une mise à jour indépendante en utilisant ses propres
- règles. Veuillez vous référer à <ref id="bug-security"> pour plus
- d'informations.
- </p>
- <p>
- Pour les différences concernant les mises à jour indépendantes par les
- porteurs, veuillez voir <ref id="source-nmu-when-porter">.
- </p>
- <p>
- Bien sûr, il est toujours possible de s'accorder avec un responsable
- pour des règles spéciales (comme quand le responsable demande
- « merci d'envoyer le correctif directement pour moi et pas de
- diff nécessaire »).
- </p>
- </sect1>
- <sect1 id="nmu-version">
- <heading>
- Numéro de version pour les mises à jour indépendantes
- </heading>
- <p>
- Chaque fois que vous modifiez un paquet, le numéro de version de ce
- paquet doit changer, même pour la plus triviale des
- modifications. Notre système de gestion de paquets s'appuie sur ces
- numéros de version.
- </p>
- <p>
- Si vous faites une mise à jour indépendante <em>(NMU)</em>, vous devez
- ajouter un numéro de version mineur à la partie
- <var>révision-debian</var> du numéro de version (la partie qui suit le
- dernier trait d'union). Ce numéro supplémentaire débutera à
- « 1 ». Prenons pour exemple le paquet « foo » qui
- porte le numéro de version 1.1-3. Dans l'archive, le fichier de
- contrôle du paquet source serait <file>foo_1.1-3.dsc</file>. La
- version amont est « 1.1 » et la révision Debian est
- « 3 ». La mise à jour indépendante suivante ajouterait le
- numéro de version mineur « .1 » au numéro de révision
- Debian ; le nouveau fichier de contrôle du paquet source serait
- alors <file>foo_1.1-3.1.dsc</file>.
- </p>
- <p>
- Le numéro de révision mineur est nécessaire pour éviter de prendre un
- numéro de version au responsable officiel du paquet, ce qui pourrait
- perturber son travail. Cela a aussi l'avantage de montrer clairement
- que le paquet n'a pas été livré par le responsable officiel.
- </p>
- <p>
- S'il n'y a pas de partie <var>révision-debian</var> dans le numéro de
- version du paquet, il faut en créer une en démarrant à
- « 0.1 ». S'il est absolument nécessaire qu'une personne qui
- n'est pas responsable d'un paquet fasse une livraison basée sur une
- nouvelle version amont, cette personne doit choisir « 0.1 »
- comme numéro de révision Debian. Le responsable du paquet doit, lui,
- démarrer sa numérotation à « 1 ».
- </p>
- <p>
- Si vous envoyez un paquet vers <em>testing</em> ou <em>stable</em>,
- vous devrez parfois créer une branche (« fork ») dans
- l'arbre de numéro des version. Pour cela, vous pouvez utiliser des
- numéros de version comme 1.1-3sarge0.1.
- </p>
- </sect1>
- <sect1 id="nmu-changelog">
- <heading>
- Les mises à jour indépendantes sources doivent être mentionnées dans
- le fichier changelog
- </heading>
- <p>
- Une personne qui fait une mise à jour indépendante source doit ajouter
- une entrée dans le fichier <file>changelog</file> qui indique les
- bogues corrigés et qui précise pourquoi cette mise à jour était
- nécessaire. Cette entrée comportera l'adresse de la personne ayant
- fait l'envoi ainsi que la version livrée.
- </p>
- <p>
- Par convention, dans le cas d'une mise à jour indépendante source
- <em>(NMU)</em>, l'entrée du fichier changelog débute par la
- ligne :
- <example>
- * Non-maintainer upload
-</example>
- </p>
- </sect1>
- <sect1 id="nmu-patch">
- <heading>
- Mise à jour indépendante source et système de suivi des bogues
- </heading>
- <p>
- Un développeur qui n'est pas responsable d'un paquet doit faire aussi
- peu de modifications que possible et doit toujours envoyer ses
- modifications au système de suivi des bogues au format diff unifié
- (<tt>diff -u</tt>).
- </p>
- <p>
- Et si vous recompilez simplement le paquet ? Si vous avez
- simplement besoin de recompiler le paquet pour une seule architecture,
- vous pouvez faire une NMU binaire seulement comme décrit dans <ref
- id="binary-only-nmu"> qui ne nécessite pas qu'un correctif soit
- envoyé. Si vous désirez que le paquet soit recompilé pour toutes les
- architectures, vous devez alors faire une NMU source et vous devrez
- envoyer un correctif.
- </p>
- <p>
- Si la mise à jour indépendante source (<em>source NMU</em>) corrige
- des bogues, ceux-ci doivent être marqués <em>fixed</em> (corrigé) dans
- le système de suivi des bogues plutôt que clos. Par convention, seul
- le responsable du paquet et la personne qui a ouvert le rapport de
- bogue ferment les rapports. Heureusement, le système d'archivage
- Debian reconnaît les mises à jours indépendantes et positionne
- correctement le statut des bogues à <em>fixed</em> si la personne qui
- fait la mise à jour a listé tous les bogues dans le fichier changelog
- en utilisant la syntaxe <tt>Closes: bug#<var>nnnnn</var></tt> (voir
- <ref id="upload-bugfix"> pour en savoir plus sur la fermeture de bogue
- par le fichier <file>changelog</file>). Ce passage au statut
- <em>fixed</em> assure que chacun sait que le bogue est corrigé par une
- mise à jour indépendante tout en laissant le rapport de bogue ouvert
- jusqu'à ce que le responsable du paquet incorpore les modifications de
- cette mise à jour dans la version officielle du paquet.
- </p>
- <p>
- Après avoir fait une mise à jour indépendante, il vous faudra aussi
- envoyer l'information aux bogues existants que vous avez corrigés
- par votre NMU en incluant le diff unifié. Historiquement, c'était une
- habitude de créer un
- nouveau rapport de bogue et inclure un correctif comprenant toutes les
- modifications que vous avez réalisées. Le responsable officiel pourra
- choisir d'appliquer le correctif, il pourra aussi employer une autre
- méthode pour régler le problème. Certains bogues sont corrigés dans la
- version amont, ce qui est une bonne raison pour annuler les
- modifications d'une mise à jour indépendante. Si le responsable
- choisit de mettre à jour le paquet plutôt que d'utiliser les
- correctifs de la mise à jour indépendante, il devra s'assurer que
- cette nouvelle version corrige effectivement chacun des bogues
- corrigés dans la mise à jour indépendante.
- </p>
- <p>
- De plus, le responsable officiel devrait <em>toujours</em> conserver
- les entrées documentant une mise à jour indépendante dans le fichier
- <file>changelog</file> — et bien sûr, également conserver les
- modifications. Si vous annulez certaines des modifications, veuillez
- réouvrir les rapports de bogue correspondants.
- </p>
- </sect1>
- <sect1 id="nmu-build">
- <heading>
- Fabriquer une mise à jour indépendante source
- </heading>
- <p>
- Les paquets faisant l'objet d'une mise à jour indépendante source sont
- construits comme les autres. Sélectionnez une distribution en
- utilisant les règles décrites dans la section <ref id="distribution">
- en suivant toutes les instructions de la section <ref id="upload">.
- </p>
- <p>
- Vérifiez que vous n'avez pas modifié la valeur du champ
- <tt>maintainer</tt> dans le fichier <file>debian/control</file>. Votre
- nom, mentionné dans l'entrée du fichier <file>debian/changelog</file>
- concernant la mise à jour, sera utilisé pour signer le fichier
- <file>.changes</file>.
- </p>
- </sect1>
- <sect1 id="ack-nmu">
- <heading>
- Valider une mise à jour indépendante
- </heading>
- <p>
- Si l'un de vos paquets a subi une mise à jour indépendante, vous devez
- récupérer les changements dans votre copie des sources. Ceci est aisé,
- vous avez simplement à appliquer le correctif qui vous a été
- envoyé. Une fois ceci fait, vous devez fermer les bogues qui ont été
- marqués comme fixés par la mise à jour. Le moyen le plus simple est
- d'utiliser l'option <tt>-v</tt> de <prgn>dpkg-buildpackage</prgn> car
- cela vous permet d'inclure tous les changements depuis votre dernier
- envoi de responsable. Sinon, vous pouvez soit les fermer manuellement
- en envoyant les courriers nécessaires au BTS soit ajouter les
- <tt>closes: #nnnn</tt> nécessaires dans l'entrée du changelog de votre
- prochain envoi.
- </p>
- <p>
- Dans tous les cas, vous ne devriez pas être perturbé par la NMU. Une
- NMU n'est pas une attaque personnelle contre le responsable. C'est une
- preuve que le paquet est important pour quelqu'un et qu'il est
- désireux de vous aider dans votre travail, vous devriez donc lui être
- reconnaissant. Vous pouvez également lui demander s'il serait
- intéressé pour vous aider sur une base plus régulière comme
- co-responsable ou responsable de secours (cf. <ref
- id="collaborative-maint">).
- </p>
- </sect1>
- <sect1 id="nmu-vs-qa">
- <heading>
- Mise à jour indépendante ou envoi de QA ?
- </heading>
- <p>
- Sauf si vous savez que le responsable est toujours actif, il est sage
- de vérifier le paquet pour voir s'il n'a pas été abandonné. La liste
- actuelle des paquets orphelins pour lesquels le champ responsable n'a
- pas été positionné correctement est disponible à <url
- id="&url-debian-qa-orphaned;">. Si vous effectuez une mise à jour
- indépendante sur un paquet incorrectement orphelin, veuillez
- positionner le responsable à « Debian QA Group
- <packages@qa.debian.org> ».
- </p>
- </sect1>
- <sect1 id="nmu-who">
- <heading>
- Qui peut faire une mise à jour indépendante ?
- </heading>
- <p>
- Seuls les responsables Debian officiels peuvent faire des mises à jour
- indépendantes binaire ou source. Un responsable officiel est une
- personne dont la clé est dans le porte-clés Debian. Tout autre
- personne est toutefois invitée à télécharger les paquets sources pour
- corriger des bogues ; au lieu de faire des mises à jour
- indépendantes, ils pourront soumettre les correctifs qui le méritent
- au système de suivi des bogues. Les responsables apprécient presque
- toujours les correctifs et les rapports de bogue soignés.
- </p>
- </sect1>
- <sect1 id="nmu-terms">
- <heading>
- Terminologie
- </heading>
- <p>
- Deux nouvelles expressions sont introduites dans cette section :
- « mise à jour indépendante source » et « mise à jour
- indépendante binaire ». Ces deux expressions ont une
- signification technique précise dans ce document. Elles correspondent
- toutes deux au même type d'activité ; elles impliquent toutes
- deux qu'une personne fait une mise à jour d'un paquet alors qu'elle
- n'est pas officiellement responsable de ce paquet. C'est pourquoi nous
- qualifions ces mises à jours
- d'<em>indépendantes</em><footnote><p>Contrairement à ce que pourrait
- laisser entendre cette traduction de <em>non-maintainer upload</em>,
- il n'est pas question d'agir sans prévenir le responsable au préalable
- (voir <ref id="nmu-guidelines">).</p></footnote>.
- </p>
- <p>
- Une mise à jour indépendante source est une livraison de paquet faite
- par une personne qui n'est pas le responsable officiel de ce paquet
- avec pour objectif de corriger un bogue dans le paquet. Une mise à
- jour indépendante source implique toujours une modification des
- sources du paquet, même s'il ne s'agit que d'un changement dans le
- fichier <file>debian/changelog</file>. Ce changement peut tout aussi
- bien concerner la partie amont du source que la partie spécifique à
- Debian. Une mise à jour indépendante source peut aussi inclure des
- paquets spécifiques à une architecture tout comme un fichier
- <em>diff</em> modifié.
- </p>
- <p>
- Une mise à jour indépendante binaire est constituée par la
- recompilation et l'archivage d'un paquet pour une architecture
- donnée. Il s'agit souvent du résultat d'un effort de portage. Une mise
- à jour indépendante binaire est la livraison d'un paquet compilé
- (souvent pour une autre architecture) à condition que cette
- compilation n'ait pas nécessité de modifications des sources. Dans de
- nombreux cas, les porteurs sont obligés de modifier les sources pour
- les rendre compilables sur leur architecture cible ; il s'agira
- alors d'une mise à jour indépendante source et non d'une mise à jour
- indépendante binaire. Comme vous pouvez le remarquer, nous ne faisons
- pas de distinction entre les mises à jour indépendantes faites par des
- porteurs et les autres mises à jour indépendantes.
- </p>
- <p>
- Les mises à jour indépendantes sources et binaires sont toutes deux
- couvertes par l'expression « mise à jour indépendante »
- (NMU<footnote><p>Non-maintainer upload</p></footnote>). Pourtant, cela
- conduit souvent à des confusions car beaucoup associent « mise à
- jour indépendante » et « mise à jour indépendante
- source ». Il faut donc rester vigilant : utilisez toujours
- « mise à jour indépendante binaire » ou «NMU binaire »
- pour les mises à jour indépendantes de binaires seuls.
- </p>
- </sect1>
- </sect>
- <sect id="collaborative-maint">
- <heading>
- Maintenance collective
- </heading>
- <p>
- « Maintenance collective » est un terme décrivant le partage
- des devoirs de la maintenance d'un paquet Debian par plusieurs
- personnes. Cette collaboration est presque toujours une bonne idée car
- il en résulte généralement une meilleure qualité et un temps de
- correction de bogues plus petit. Il est fortement recommandé que les
- paquets de priorité <tt>Standard</tt> ou qui font partie de la base
- aient des co-responsables.
- </p>
- <p>
- Habituellement, il y a un responsable principal et un ou plusieurs
- co-responsables. Le responsable principal est la personne dont le nom
- est indiqué dans le champ <tt>Maintainer</tt> du fichier
- <file>debian/control</file>. Les co-responsables sont tous les autres
- responsables.
- </p>
- <p>
- Dans sa forme la plus simple, ajouter un nouveau co-responsable est
- assez simple :
- <list>
- <item>
- <p>
- Donner au co-responsable un accès aux sources à partir desquelles
- vous construisez le paquet. Habituellement, cela implique que vous
- utilisiez un système de contrôle de version comme <prgn>CVS</prgn>
- ou <prgn>Subversion</prgn>.
- </p>
- </item>
- <item>
- <p>
- Ajouter les nom et adresse correctes du co-responsable au champ
- <tt>Uploaders</tt> dans la partie globale du fichier
- <file>debian/control</file>.
- <example>
-Uploaders: John Buzz <jbuzz@debian.org>, Adam Rex <arex@debian.org>
-</example>
- </p>
- </item>
- <item>
- <p>
- En utilisant le PTS (<ref id="pkg-tracking-system">), les
- co-responsables devraient s'inscrire eux-mêmes aux paquets sources
- appropriés.
- </p>
- </item>
- </list>
- </p>
- <p>
- La maintenance collective peut souvent être facilitée par l'utilisation
- d'outils sur Alioth (voir <ref id="alioth">).
- </p>
- </sect>
- <sect id="testing">
- <heading>
- La distribution <em>testing</em>
- </heading>
- <p>
- </p>
- <sect1 id="testing-basics">
- <heading>
- Bases
- </heading>
- <p>
- Les paquets sont habituellement installés dans la distribution
- <em>testing</em> après avoir atteint un certain degré de test dans
- <em>unstable</em>.
- </p>
- <p>
- Ils doivent être en synchronisation pour toutes les architectures et
- ne doivent pas avoir de dépendances qui les rendraient non
- installables ; ils doivent également n'avoir aucun bogue bloquant
- l'inclusion du paquet dans une version stable
- (« release-critical ») au moment où ils sont installés dans
- <em>testing</em>. Ainsi, <em>testing</em> devrait toujours être prête
- pour être une version candidate stable. Veuillez voir ci-dessous pour
- les détails.
- </p>
- </sect1>
- <sect1 id="testing-unstable">
- <heading>
- Mises à jour depuis <em>unstable</em>
- </heading>
- <p>
- Les scripts qui mettent à jour la distribution <em>testing</em> sont
- exécutés chaque jour après l'installation des paquets mis à
- jour ; ces scripts sont appelés <em>britney</em>. Ils fabriquent
- les fichiers <file>Packages</file> pour la distribution
- <em>testing</em>, mais ils le font d'une manière intelligente pour
- éviter toute incohérence et essayer de n'utiliser que des paquets sans
- bogue.
- </p>
- <p>
- L'inclusion d'un paquet d'<em>unstable</em> est soumise aux conditions
- suivantes :
- <list>
- <item>
- <p>
- Le paquet doit avoir été disponible dans <em>unstable</em> depuis
- 2, 5 ou 10 jours selon le champ d'urgence de l'envoi (élevée,
- moyenne ou basse). Veuillez noter que cette urgence est
- « collante » (« sticky »), ce qui veut dire que
- l'envoi avec l'urgence la plus élevée depuis la précédente
- transition dans <em>testing</em> est prise en compte. Ces délais
- peuvent être doublés lors d'un gel de distribution, ou les
- transitions dans <em>testing</em> peuvent être complètement
- désactivées ;
- </p>
- </item>
- <item>
- <p>
- Il doit avoir autant ou moins de bogues empêchant l'intégration
- dans la distribution que la version actuellement disponible dans
- <em>testing</em> ;
- </p>
- </item>
- <item>
- <p>
- Il doit être disponible pour toutes les architectures pour
- lesquelles il a été auparavant construit. <ref id="madison"> peut
- être intéressant pour vérifier cette information ;
- </p>
- </item>
- <item>
- <p>
- Il ne doit pas casser les dépendances d'un paquet qui est déjà
- disponible dans <em>testing</em> ;
- </p>
- </item>
- <item>
- <p>
- Les paquets dont il dépend doivent soit être déjà disponibles dans
- <em>testing</em> soit être acceptés dans <em>testing</em> au même
- moment (et ils doivent remplir tous les critères nécessaires).
- </p>
- </item>
- </list>
- </p>
- <p>
- Pour savoir si un paquet a progressé ou non dans <em>testing</em>,
- veuillez voir la sortie du script de <em>testing</em> sur la <url
- id="&url-testing-maint;" name="page web de la distribution testing">
- ou utilisez le programme <prgn>grep-excuses</prgn> inclus dans le
- paquet <package>devscripts</package>. Si vous voulez rester informé de
- la progression de vos paquets dans <em>testing</em>, vous pouvez
- facilement le mettre dans la <manref section="5" name="crontab">.
- </p>
- <p>
- Le fichier <file>update_excuses</file> ne donne pas toujours la raison
- précise pour laquelle un paquet est refusé ; on peut avoir à la
- chercher soi-même en regardant ce qui serait cassé avec l'inclusion du
- paquet. La <url id="&url-testing-maint;" name="page web de la
- distribution testing"> donne plus d'informations à propos des
- problèmes courants qui peuvent occasionner cela.
- </p>
- <p>
- Parfois, certains paquets n'entrent jamais dans <em>testing</em> parce
- que le jeu des inter-relations est trop compliqué et ne peut être
- résolu par le script. Voir ci-dessous pour des détails.
- </p>
- <p>
- Des analyses de dépendances plus avancées sont présentées sur <url
- id="http://bjorn.haxx.se/debian/"> — mais, attention, cette page
- affiche également les dépendances de construction qui ne sont pas
- considérées par britney.
- </p>
- <sect2 id="outdated">
- <heading>
- Désynchronisation
- </heading>
- <p>
- Pour le script de migration dans <em>testing</em>,
- « désynchronisé » (<em>outdated</em> veut dire ceci :
- il y a différentes versions dans <em>unstable</em> pour les
- architectures de version (à l'exception des architectures dans
- fuckedarches ; fuckedarches est une liste des architectures qui
- ne suivent pas le rythme (dans update_out.py), mais actuellement
- cette liste est vide). « Désynchronisé » n'a rien à voir
- avec les architectures que le paquet fournit pour <em>testing</em>.
- </p>
- <p>
- Considérons cet exemple :
- </p>
- <p>
- <example>
-foo | alpha | arm
----------+-------+----
-testing | 1 | -
-unstable | 1 | 2
-</example>
- </p>
- <p>
- Le paquet est désynchronisé pour alpha dans <em>unstable</em> et
- n'entrera pas dans <em>testing</em>. Supprimer foo de
- <em>testing</em> n'aiderait en rien, le paquet serait toujours
- désynchronisé pour alpha et ne se propagerait pas dans
- <em>testing</em>.
- </p>
- <p>
- Cependant, si ftp-master supprime un paquet d'<em>unstable</em> (ici
- pour arm) :
- </p>
- <p>
- <example>
-foo | alpha | arm | hurd-i386
----------+-------+-----+----------
-testing | 1 | 1 | -
-unstable | 2 | - | 1
- </example>
- </p>
- <p>
- Dans ce cas, le paquet est synchronisé pour toutes les architectures
- de version dans <em>unstable</em> (et l'architecture supplémentaire
- hurd-i386 ne compte pas car ce n'est pas une architecture de
- version).
- </p>
- <p>
- Quelquefois, la question est soulevée pour savoir s'il est possible
- de permettre à des paquets de passer dans <em>testing</em> qui ne
- sont pas encore construits pour toutes les architectures :
- non. Simplement non. (Excepté si vous êtes responsable de glibc ou
- équivalent).
- </p>
- </sect2>
- <sect2 id="removals">
- <heading>
- Suppressions de <em>testing</em>
- </heading>
- <p>
- Parfois, un paquet est supprimé pour permettre l'inclusion d'un autre
- paquet : ceci ne se produit que pour permettre à un
- <em>autre</em> paquet d'entrer, ce dernier doit être prêt pour tous
- les autres critères. Considérons, par exemple, qu'un paquet
- <em>a</em> ne peut pas être installé avec la nouvelle version de
- <em>b</em> alors <em>a</em> peut être supprimé pour permettre
- l'entrée de <em>b</em>.
- </p>
- <p>
- Bien sûr, il existe une autre raison pour supprimer un paquet de
- <em>testing</em> : le paquet est trop bogué (et avoir un seul
- bogue RC est suffisant pour être dans cet état).
- </p>
- <p>
- De plus, si un paquet a été supprimé d'<em>unstable</em> et qu'aucun
- paquet de <em>testing</em> n'en dépend plus, il sera alors
- automatiquement supprimé.
- </p>
-
- </sect2>
- <sect2 id="circular">
- <heading>
- Dépendances circulaires
- </heading>
- <p>
- Une situation qui n'est pas très bien gérée par britney est si un
- paquet <em>a</em> dépend de la nouvelle version d'un paquet
- <em>b</em> et vice versa.
- </p>
- <p>
- Voici un exemple :
- </p>
- <p>
- <example>
- | testing | unstable
---+-----------------+------------
-a | 1; dépend: b=1 | 2; dépend: b=2
-b | 1; dépend: a=1 | 2; dépend: a=2
- </example>
- </p>
- <p>
- Aucun des paquets <em>a</em> et <em>b</em> ne sera considéré pour
- mise à jour.
- </p>
- <p>
- Actuellement, ceci nécessite un coup de pouce manuel de l'équipe de
- publication. Veuillez les contacter en envoyant un courrier
- électronique à debian-release@lists.debian.org si cela se produit
- pour l'un de vos paquets.
- </p>
- </sect2>
- <sect2>
- <heading>
- Influence d'un paquet dans <em>testing</em>
- </heading>
- <p>
- Généralement, l'état d'un paquet dans <em>testing</em> ne change rien
- pour la transition de la prochaine version d'<em>unstable</em> vers
- <em>testing</em>, avec deux exceptions : si le nombre de bogues
- RC du paquet est réduit, le paquet peut migrer même s'il a encore des
- bogues RC. La seconde exception est que si la version du paquet dans
- <em>testing</em> est désynchronisée entre les différentes
- architectures, alors toute architecture peut être mise à jour vers la
- version du paquet source ; cependant, cela ne peut se produire
- que si le paquet a été précédemment forcé, si l'architecture est dans
- fuckedarches ou s'il n'y avait pas du tout de paquet binaire de cette
- architecture présent dans <em>unstable</em> lors de la migration dans
- <em>testing</em>.
- </p>
- <p>
- En résumé, cela veut dire : la seule influence qu'un paquet de
- <em>testing</em> a sur la nouvelle version du même paquet est que la
- nouvelle version peut rentrer plus facilement.
- </p>
- </sect2>
- <sect2 id="details">
- <heading>
- Détails
- </heading>
- <p>
- Si vous êtes intéressé par les détails, voici comment fonctionne
- britney :
- </p>
- <p>
- Les paquets sont examinés pour savoir si ce sont des candidats
- valides. Cela donne le fichier « update excuses ». Les
- raisons les plus communes pour lesquelles un paquet n'est pas
- considéré sont la jeunesse du paquet, le nombre de bogues RC et la
- désynchronisation pour certaines architectures. Pour cette partie de britney,
- les responsables de version ont des marteaux de toute taille pour
- forcer britney à considérer un paquet. (Le gel de la base est
- également codé dans cette partie de britney.) (Il y a une chose
- semblable pour les mises à jour binaires pures, mais cela n'est pas
- décrit ici. Si vous êtes intéressé par cela, veuillez étudier
- attentivement le code.)
- </p>
- <p>
- Maintenant, la partie la plus complexe se produit : britney
- tente de mettre à jour <em>testing</em> avec des candidats
- valides ; en premier, chaque paquet individuellement, puis des
- groupes de plus en plus larges de paquets ensemble. Chaque tentative
- est acceptée si <em>testing</em> n'est pas moins non installable
- après la mise à jour qu'avant celle-ci. (Avant et après cette partie,
- certains coups de pouce (« hints ») sont traités ;
- mais, comme seuls les responsables de version peuvent positionner des
- coups de pouce, cela n'est probablement pas très important pour
- vous.)
- </p>
- <p>
- Si vous voulez voir plus de détails, vous pouvez le voir dans
- merkel:/org/ftp.debian.org/testing/update_out/ (ou dans
- ~aba/testing/update_out pour voir une configuration avec un fichier
- de paquets plus petit). Par le web, c'est à <url
- id="http://ftp-master.debian.org/testing/update_out_code/">.
- </p>
- <p>
- Les coups de pouce sont visibles sur <url
- id="http://ftp-master.debian.org/testing/hints/">.
- </p>
- </sect2>
- </sect1>
- <sect1 id="t-p-u">
- <heading>
- Mises à jour directes dans <em>testing</em>
- </heading>
- <p>
- La distribution <em>testing</em> est peuplée avec des paquets en
- provenance d'<em>unstable</em> selon des règles expliquées
- ci-dessus. Cependant, dans certains cas, il est nécessaire d'envoyer
- des paquets construits seulement pour <em>testing</em>. Pour cela,
- vous pouvez envoyer vos paquets vers
- <em>testing-proposed-updates</em>.
- </p>
- <p>
- Souvenez-vous que les paquets envoyés là ne sont pas traités
- automatiquement, ils doivent passer entre les mains du responsable de
- distribution. Vous devez donc avoir une bonne raison pour les y
- envoyer. Pour savoir ce que représente une bonne raison aux yeux des
- responsables de distribution, vous devriez lire les instructions
- données qu'ils envoient régulièrement sur
- &email-debian-devel-announce;.
- </p>
- <p>
- Vous ne devriez pas envoyer un paquet à
- <em>testing-proposed-updates</em> quand vous pouvez le mettre à jour
- par <em>unstable</em>. Si vous ne pouvez faire autrement (par exemple,
- parce que vous avez une nouvelle version de développement dans
- <em>unstable</em>), vous pouvez utiliser cette facilité, mais il est
- recommandé de demander l'autorisation du responsable de distribution
- auparavant. Même si un paquet est gelé, des mises à jour par
- <em>unstable</em> sont possibles si l'envoi dans <em>unstable</em> ne
- tire pas de nouvelles dépendances.
- </p>
- <p>
- Les numéros de version sont habituellement choisis en ajoutant le nom
- de code de la distribution <em>testing</em> et un numéro incrémenté,
- comme 1.2sarge1 pour le premier envoi dans
- <em>testing-proposed-updates</em> du paquet en version 1.2.
- </p>
- <p>
- Veuillez vous assurer que vous n'oubliez aucun des éléments suivants
- lors de votre envoi :
- <list>
- <item>
- <p>
- vérifiez que votre paquet doit vraiment aller dans
- <em>testing-proposed-updates</em> et ne peut pas passer par
- <em>unstable</em> ;
- </p>
- </item>
- <item>
- <p>
- vérifiez que vous n'incluez que le minimum de changements ;
- </p>
- </item>
- <item>
- <p>
- vérifiez que vous incluez une explication appropriée dans le
- changelog ;
- </p>
- </item>
- <item>
- <p>
- vérifiez que vous avez bien indiqué <em>testing</em> ou
- <em>testing-proposed-updates</em> comme votre distribution
- cible ;
- </p>
- </item>
- <item>
- <p>
- vérifiez que vous avez construit et testé votre paquet dans
- <em>testing</em> et non dans <em>unstable</em> ;
- </p>
- </item>
- <item>
- <p>
- vérifiez que votre numéro de version est plus élevé que les
- versions de <em>testing</em> et de
- <em>testing-proposed-updates</em> et moins élevé que celle de
- <em>unstable</em> ;
- </p>
- </item>
- <item>
- <p>
- après l'envoi et la construction réussie sur toutes les
- plates-formes, contactez l'équipe de publication à
- &email-debian-release; et demandez-leur d'approuver votre envoi.
- </p>
- </item>
- </list>
- </p>
- </sect1>
- <sect1 id="faq">
- <heading>
- Questions fréquemment posées
- </heading>
- <p>
- </p>
- <sect2 id="rc">
- <heading>
- Quels sont les bogues bloquant l'intégration dans la version stable
- et comment sont-ils comptés ?
- </heading>
- <p>
- Tous les bogues de gravité assez élevée sont par défaut considérés
- comme bloquant l'intégration du paquet dans la version stable ;
- actuellement, ce sont les bogues critiques, graves et sérieux.
- </p>
- <p>
- Certains bogues sont supposés avoir un impact sur les chances que le
- paquet a d'être diffusé dans la version stable de Debian : en
- général, si un paquet a des bogues bloquants, il n'ira pas dans
- <em>testing</em> et par conséquent, ne pourra pas être diffusé dans
- <em>stable</em>.
- </p>
- <p>
- Le compte des bogues d'<em>unstable</em> est effectué avec tous les
- bogues bloquants sans étiquette de version (comme <em>potato</em>,
- <em>woody</em>) ou avec une étiquette <em>sid</em> et également s'ils
- ne sont ni corrigés ou marqués avec <em>sarge-ignore</em>. Le compte
- des bogues de <em>testing</em> pour un paquet est considéré comme à
- peu près le nombre de bogues d'<em>unstable</em> lors du dernier
- pointage quand la version <em>testing</em> a été égale à la version
- <em>unstable</em>.
- </p>
- <p>
- Cela changera après la sortie de <em>Sarge</em> dès que nous aurons
- des versions dans le système de suivi des bogues.
- </p>
- </sect2>
- <sect2>
- <heading>
- Comment est-ce que l'installation d'un paquet dans <em>testing</em>
- peut casser d'autres paquets ?
- </heading>
- <p>
- La structure des archives de la distribution est faite de telle façon
- qu'elles ne peuvent contenir qu'une version d'un paquet ; un
- paquet est défini par son nom. Donc, quand le paquet source acmefoo
- est installé dans <em>testing</em> avec ses paquets binaires
- acme-foo-bin, acme-bar-bin, libacme-foo1 et libacme-foo-dev,
- l'ancienne version est supprimée.
- </p>
- <p>
- Cependant, l'ancienne version pouvait fournir à un paquet binaire un
- vieux soname d'une bibliothèque, comme libacme-foo0. Supprimer
- l'ancien acmefoo va supprimer libacme-foo0, ce qui va casser tout
- paquet qui en dépend.
- </p>
- <p>
- Évidemment, cela touche principalement des paquets qui fournissent
- des jeux changeant de paquets binaires dans différentes versions (par
- suite, principalement des bibliothèques). Cependant, cela va aussi
- toucher des paquets sur lesquels une dépendance versionnée a été
- déclarée du type ==, <= ou <<.
- </p>
- <p>
- Quand le jeu de paquets binaires fournis par un paquet source change
- de cette façon, tous les paquets qui dépendent des anciens binaires
- doivent être mis à jour pour dépendre de la nouvelle version à la
- place. Comme l'installation d'un tel paquet source dans
- <em>testing</em> casse tous les paquets qui en dépendent dans
- <em>testing</em>, une certaine attention doit y être portée :
- tous les paquets en dépendant doivent être mis à jour et prêts à être
- installés eux-même pour qu'ils ne cassent pas et, une fois que tout
- est prêt, une intervention manuelle du responsable de version ou d'un
- de ses assistants est normalement requise.
- </p>
- <p>
- Si vous avez des problèmes avec des groupes compliqués de paquets
- comme ceci, contactez debian-devel ou debian-release en demandant de
- l'aide.
- </p>
- </sect2>
- </sect1>
- </sect>
- </chapt>
- <chapt id="best-pkging-practices">
- <heading>
- Les meilleurs pratiques pour la construction des paquets
- </heading>
- <p>
- La qualité de Debian est principalement due à la <url
- id="&url-debian-policy;" name="charte Debian"> qui définit explicitement
- les obligations que tous les paquets doivent suivre. Mais c'est
- également grâce à une histoire partagée d'expériences qui va au-delà de
- la charte Debian, une accumulation d'années d'expérience pour la
- construction des paquets ; des développeurs de grand talent ont
- créé de bons outils qui vous aideront, vous, responsable Debian, à créer
- et maintenir d'excellents paquets.
- </p>
- <p>
- Ce chapitre fournit les meilleurs pratiques pour les développeurs
- Debian. Ce ne sont que des recommandations, non pas des obligations ou
- des règles. Ce sont seulement des astuces et conseils subjectifs et des
- liens collectés pour les développeurs Debian. Prenez et choisissez ce
- qui vous convient le mieux.
- </p>
- <sect id="bpp-debian-rules">
- <heading>
- Les meilleures pratiques pour le fichier <file>debian/rules</file>
- </heading>
- <p>
- Les recommandations suivantes s'appliquent au fichier
- <file>debian/rules</file>. Comme ce fichier contrôle le processus de
- compilation et qu'il sélectionne les fichiers inclus dans le paquet
- (directement ou indirectement), il s'agit habituellement du fichier sur
- lequel les responsables passent le plus de temps.
- </p>
- <sect1 id="helper-scripts">
- <heading>
- Scripts d'aide
- </heading>
- <p>
- La raison sous-jacente à l'utilisation des scripts d'aide dans le
- fichier <file>debian/rules</file> est que cela permet aux responsables
- d'utiliser et de partager une logique commune pour un grand nombre de
- paquets. Prenez, par exemple, la question de l'installation des
- entrées de menu : vous avez besoin de placer un fichier dans
- <file>/usr/share/menu</file> (ou <file>/usr/lib/menu</file> pour des
- fichiers de menu binaires exécutables, si nécessaire) et d'ajouter des
- commandes aux scripts de maintenance pour enregistrer et
- désenregistrer ces entrées de menu. Comme il s'agit d'une chose très
- commune, pourquoi chaque responsable devrait-il écrire sa propre
- version, parfois avec des bogues ? Supposons également que le
- répertoire de menu soit modifié, chaque paquet devrait être modifié.
- </p>
- <p>
- Les scripts d'aide peuvent résoudre ces problèmes. En supposant que
- vous vous conformiez aux conventions attendues par le script d'aide,
- celui-ci prend soin de tous les détails. Les changements dans la
- charte peuvent alors être faits dans le script d'aide ; les
- paquets ont alors simplement besoin d'être reconstruits avec la
- nouvelle version du script et sans aucun changement supplémentaire.
- </p>
- <p>
- L'<ref id="tools"> contient plusieurs systèmes d'aide. Le plus courant
- et le meilleur (à notre avis) système est
- <package>debhelper</package>. Les précédents systèmes d'aide comme
- <package>debmake</package> étaient « monolithiques » :
- vous ne pouviez pas choisir quelles parties intéressantes vous pouviez
- utiliser, mais vous étiez obligé de choisir le système pour tout
- faire. <package>debhelper</package>, à l'inverse, consiste en un
- certain nombre de petits programmes <prgn>dh_*</prgn>. Par exemple,
- <prgn>dh_installman</prgn> installe et compacte les pages de manuel,
- <prgn>dh_installmenu</prgn> installe les fichiers de menu et ainsi de
- suite. Ainsi, il offre une flexibilité suffisante pour pouvoir
- utiliser les scripts d'aide quand ils sont utiles, en complément de
- commandes définies manuellement dans le fichier
- <file>debian/rules</file>.
- </p>
- <p>
- Vous pouvez débuter avec <package>debhelper</package> en lisant
- <manref section="1" name="debhelper"> et en regardant les exemples
- fournis avec le paquet. <prgn>dh_make</prgn> du paquet
- <package>dh-make</package> (voir <ref id="dh-make">) peut être utilisé
- pour convertir un paquet source « vierge » en une version
- utilisant <package>debhelper</package>. Ce raccourci ne devrait
- cependant pas vous faire croire que vous n'avez pas besoin de
- comprendre les scripts individuels <prgn>dh_*</prgn>. Si vous comptez
- utiliser un système d'aide, vous devez prendre le temps d'apprendre à
- utiliser ce système pour savoir ce que vous pouvez en attendre ainsi
- que son comportement.
- </p>
- <p>
- Plusieurs personnes pensent que des fichiers <file>debian/rules</file>
- vierges sont préférables car vous n'avez pas à apprendre les détails
- internes d'un quelconque système d'aide. La décision vous appartient
- complètement. Utilisez ce qui vous convient. Plusieurs exemples de
- fichiers <file>debian/rules</file> sont disponibles à <url
- id="&url-rules-files;">.
- </p>
- </sect1>
- <sect1 id="multiple-patches">
- <heading>
- Séparer vos correctifs en plusieurs fichiers
- </heading>
- <p>
- Les gros paquets peuvent avoir plusieurs bogues que vous devez
- gérer. Si vous corrigez sans faire attention les bogues dans les
- sources, vous ne pourrez pas différencier facilement les nombreux
- correctifs que vous aurez appliqués. Cela peut devenir très compliqué
- de mettre à jour le paquet avec une nouvelle version amont qui intègre
- certains correctifs (mais pas tous). Vous ne pouvez pas prendre
- l'ensemble des correctifs (par exemple, dans les fichiers
- <file>.diff.gz</file>) et décider quels correctifs il vous faut
- enlever parce que les bogues ont été corrigés en amont.
- </p>
- <p>
- Malheureusement, le système de création des paquets tel qu'il est
- actuellement ne fournit pas de moyen de séparer les correctifs en
- plusieurs fichiers. Cependant, il existe des moyens de séparer les
- correctifs : les fichiers correctifs sont livrés dans le fichier
- correctif Debian (<file>.diff.gz</file>), habituellement dans le
- répertoire <file>debian/</file>. La seule différence est qu'ils ne
- sont pas appliqués immédiatement par dpkg-source, mais par la règle
- <tt>build</tt> du fichier <file>debian/rules</file>. Inversement, ils
- sont annulés par la règle <tt>clean</tt>.
- </p>
- <p>
- <prgn>dbs</prgn> est l'une des approches les plus populaires pour
- cela. Il fait ce qui est décrit ci-dessus et fournit la possibilité de
- créer de nouveaux correctifs et de mettre à jour d'anciens
- correctifs. Veuillez vous reporter au paquet <package>dbs</package>
- pour plus d'informations et au paquet <package>hello-dbs</package>
- pour un exemple.
- </p>
- <p>
- <prgn>Dpatch</prgn> fournit également ces fonctions, mais il est prévu
- pour être encore plus facile d'utilisation. Veuillez voir le paquet
- <package>dpatch</package> pour la documentation et des exemples (dans
- <file>/usr/share/doc/dpatch</file>).
- </p>
- </sect1>
- <sect1 id="multiple-binary">
- <heading>
- Paquets binaires multiples
- </heading>
- <p>
- Un simple paquet source va souvent permettre de construire plusieurs
- paquets binaires différents, que ce soit pour fournir plusieurs
- saveurs du même paquet (par exemple, le paquet source
- <package>vim</package>) ou pour créer plusieurs petits paquets au lieu
- d'un seul gros (afin, par exemple, que l'utilisateur puisse n'installer
- que la partie nécessaire et ainsi économiser de l'espace disque).
- </p>
- <p>
- Le second cas peut facilement être géré dans le fichier
- <file>debian/rules</file>. Vous avez simplement besoin de déplacer les
- fichiers appropriés du répertoire de construction dans les
- arborescence temporaires du paquet. Vous pouvez le faire en utilisant
- <prgn>install</prgn> ou <prgn>dh_install</prgn> du paquet
- <package>debhelper</package>. Assurez-vous de vérifier les différentes
- permutations de paquets, en garantissant que vous avez bien défini les
- dépendances entre les paquets dans le fichier
- <file>debian/control</file>.
- </p>
- <p>
- Le premier cas est un peu plus difficile car il implique de multiples
- recompilations du même logiciel, mais avec différentes options de
- configuration. Le paquet source <package>vim</package> est un exemple
- de la façon de gérer cela avec un fichier <file>rules</file> écrit à
- la main.
- </p>
- </sect1>
- </sect>
- <sect id="bpp-debian-control">
- <heading>
- Les meilleures pratiques pour le fichier <file>debian/control</file>
- </heading>
- <p>
- Les pratiques suivantes sont relatives au fichier
- <file>debian/control</file>. Elles viennent en complément des <url
- id="&url-debian-policy;ch-binary.html#s-descriptions" name="règles pour
- les descriptions des paquets">.
- </p>
- <p>
- La description du paquet, telle qu'elle est définie par le champ
- correspondant dans le fichier <file>control</file>, contient à la fois
- le résumé du paquet et la description longue pour le paquet. <ref
- id="bpp-desc-basics"> décrit des lignes générales pour les deux parties
- de la description. Ensuite, <ref id="bpp-pkg-synopsis"> fournit des
- principes spécifiques pour le résumé et <ref id="bpp-pkg-desc">
- contient des principes spécifiques pour la description longue.
- </p>
- <sect1 id="bpp-desc-basics">
- <heading>
- Les règles générales pour les descriptions des paquets
- </heading>
- <p>
- La description du paquet devrait être écrite pour l'utilisateur moyen,
- l'utilisateur qui va utiliser et bénéficier du paquet. Par exemple,
- les paquets de développement sont pour les développeurs et leur
- description peut utiliser un langage technique. Pour les applications
- à but plus général comme un éditeur, la description devrait être
- écrite pour un non-spécialiste.
- </p>
- <p>
- Notre critique des descriptions des paquets nous amène à conclure que
- la plupart des descriptions des paquets sont techniques, c'est-à-dire,
- qu'elles ne sont pas écrites pour être comprises par les
- non-spécialistes. À moins que votre paquet ne soit que pour les
- techniciens, c'est un problème.
- </p>
- <p>
- Comment écrire pour les non-spécialistes ? Évitez le
- jargon. Évitez de vous référer à d'autres applications et cadres de
- travail avec lesquels l'utilisateur n'est pas forcément familier
- — « GNOME » ou « KDE » sont corrects
- car les utilisateurs sont probablement familiers avec ces termes, mais
- « GTK+ » ne l'est probablement pas. Ne supposez aucune
- connaissance. Si vous devez utiliser des termes techniques,
- introduisez-les.
- </p>
- <p>
- Soyez objectif. Les descriptions de paquet ne sont pas un endroit pour
- promouvoir votre paquet, quel que soit l'amour que vous lui
- portez. Rappelez-vous que le lecteur n'a pas forcément les mêmes
- priorités que vous.
- </p>
- <p>
- Des références aux noms de tout autre paquet de logiciels, noms de
- protocoles, standards ou spécifications devraient utiliser leurs
- formes canoniques si elles existent. Par exemple, utilisez « X
- Window System », « X11 » ou « X » et non
- « X Windows », « X-Windows » ou « X
- Window ». Utilisez « GTK+ » et non « GTK » ou
- « gtk ». Utilisez « GNOME » et non
- « Gnome ». Utilisez « PostScript » et non
- « Postscript » ou « postscript ».
- </p>
- <p>
- Si vous avez des problèmes pour écrire votre description, vous pouvez
- l'envoyer à &email-debian-l10n-english; et demander un retour
- d'informations.
- </p>
- </sect1>
- <sect1 id="bpp-pkg-synopsis">
- <heading>
- Le résumé du paquet ou description courte
- </heading>
- <p>
- La ligne de résumé (la description courte) devrait être concise. Elle
- ne doit pas répéter le nom du paquet (c'est une règle).
- </p>
- <p>
- C'est une bonne idée de penser au résumé comme à une clause apposée et
- non une phrase complète. Une clause apposée est définie dans WordNet
- comme une relation grammaticale entre un mot et une phrase pronominale
- qui la suit, par exemple « Rudolph, le renne au nez
- rouge ». La clause apposée ici est « le renne au nez
- rouge ». Comme le résumé est une clause et non une phrase
- complète, nous recommandons de ne pas la commencer par une majuscule
- et de ne pas la finir par un point. Il ne doit pas non plus commencer
- avec un article, défini (« le ») ou indéfini
- (« un »).
- </p>
- <p>
- Cela peut vous aider d'imaginer le résumé combiné avec le nom du
- paquet de la façon suivante :
- <example><var>nom-paquet</var> est un <var>résumé</var>.</example>
- Sinon, il peut être plus compréhensible de le voir comme
- <example><var>nom-paquet</var> est <var>résumé</var>.</example>
- ou, si le nom du paquet est lui-même un pluriel (comme
- « developer-tools »)
- <example><var>nom-paquet</var> sont <var>résumé</var>.</example>
- Cette façon de former une phrase à partir du nom du paquet et du
- résumé devrait être considérée comme une heuristique et non comme une
- règle stricte. Il y a certains cas où cela n'a aucun sens de former
- une phrase.
- </p>
- </sect1>
- <sect1 id="bpp-pkg-desc">
- <heading>
- La description longue
- </heading>
- <p>
- La description longue du paquet est la première information dont
- dispose l'utilisateur avant d'installer un paquet. Aussi, elle devrait
- fournir toutes les informations nécessaires pour le laisser décider de
- l'installation du paquet. Vous pouvez supposer que l'utilisateur a
- déjà lu le résumé du paquet.
- </p>
- <p>
- La description longue devrait toujours être constituée de phrases
- complètes.
- </p>
- <p>
- Le premier paragraphe de la description longue devrait répondre aux
- questions suivantes : qu'est-ce que fait le paquet ? Quelle
- tâche aide-t-il l'utilisateur à accomplir ? Il est important de
- décrire ceci d'une manière non technique, à moins que le paquet ne
- s'adresse qu'à un auditoire de techniciens.
- </p>
- <p>
- Les paragraphes suivants devraient répondre aux questions
- suivantes : Pourquoi, en tant qu'utilisateur, ai-je besoin de ce
- paquet ? Quelles sont les autres fonctionnalités dont dispose le
- paquet ? Quelles sont les fonctionnalités marquantes et les
- déficiences de ce paquet comparé à d'autres paquets (par exemple,
- « si vous avez besoin de X, utilisez Y à la place ») ?
- Est-ce que le paquet est lié à d'autres paquets d'une certaine façon
- qui n'est pas gérée par le gestionnaire de paquet (par exemple,
- « il s'agit d'un client pour le serveur foo ») ?
- </p>
- <p>
- Soyez attentif à éviter les fautes d'orthographe et de
- grammaire. N'oubliez pas votre vérificateur orthographique. Les deux
- programmes <prgn>ispell</prgn> et <prgn>aspell</prgn> possèdent des
- modes spéciaux pour vérifier les fichiers
- <file>debian/control</file> :
- <example>ispell -d american -g debian/control</example>
- <example>aspell -d en -D -c debian/control</example>
- </p>
- <p>
- Les utilisateurs s'attendent habituellement à ce que les réponses aux
- questions suivantes soient présentes dans la description du
- paquet :
- <list>
- <item>
- <p>
- Qu'est-ce que fait le paquet ? Si c'est un ajout d'un autre
- paquet, la description courte du paquet dont c'est un ajout devrait
- le spécifier.
- </p>
- </item>
- <item>
- <p>
- Pourquoi est-ce qu'il voudrait installer ce paquet ? Ceci est
- lié à ce qui est ci-dessus, mais pas tout à fait (c'est un client
- de messagerie ; il est cool, rapide, s'interface avec PGP,
- LDAP et IMAP, a les fonctionnalités X, Y et Z).
- </p>
- </item>
- <item>
- <p>
- Si ce paquet ne devrait pas être installé directement, mais être
- tiré par un autre paquet, cela devrait être mentionné.
- </p>
- </item>
- <item>
- <p>
- Si le paquet est expérimental, ou s'il y a d'autres raisons pour
- lesquelles il ne devrait pas être utilisé, si un autre paquet
- devrait être utilisé à la place, cela devrait également être
- présent.
- </p>
- </item>
- <item>
- <p>
- En quoi le paquet est différent des paquets concurrents ?
- Est-ce que c'est une meilleure implémentation ? A-t-il plus de
- fonctionnalités, des fonctionnalités différentes ? Pourquoi
- devrait-il choisir ce paquet ?
- </p>
- </item>
- </list>
- </p>
- </sect1>
- <sect1 id="bpp-upstream-info">
- <heading>
- Page d'accueil amont
- </heading>
- <p>
- Nous vous recommandons d'ajouter l'adresse de la page d'accueil du
- paquet à la description du paquet dans le fichier
- <file>debian/control</file>. Cette information devrait être ajoutée à
- la fin de la description en utilisant le format suivant :
- <example> .
- Homepage: http://some-project.some-place.org/</example>
- Veuillez noter les espaces au début de la ligne, ils servent à séparer
- les lignes correctement. Pour voir un exemple de ce que cela affiche,
- veuillez vous reporter à <url id="&url-eg-desc-upstream-info;">.
- </p>
- <p>
- Ne mettez rien s'il n'existe pas de page pour le logiciel.
- </p>
- <p>
- Veuillez noter que nous espérons que ce champ sera remplacé par un
- vrai champ de <file>debian/control</file> qui serait compris par
- <prgn>dpkg</prgn> et <tt>&packages-host;</tt>. Si vous ne voulez pas
- vous embêter à déplacer la page d'accueil depuis la description vers
- ce nouveau champ, vous devriez probablement attendre qu'il soit
- disponible. Veuillez vous assurer que cette ligne correspond à
- l'expression rationnelle <tt>/^ Homepage: [^ ]*$/</tt> car cela permet
- à <file>packages.debian.org</file> de l'analyser correctement.
- </p>
- </sect1>
- </sect>
- <sect id="bpp-debian-changelog">
- <heading>
- Les meilleures pratiques pour le fichier <file>debian/changelog</file>
- </heading>
- <p>
- Les pratiques suivantes viennent en complément de la <url
- id="&url-debian-policy;ch-docs.html#s-changelogs" name="directive sur
- les fichiers changelog">.
- </p>
- <sect1 id="bpp-changelog-do">
- <heading>
- Écrire des entrées de changelog utiles
- </heading>
- <p>
- L'entrée de changelog pour une révision de paquet documente les
- changements dans cette révision et seulement ceux-ci. Concentrez-vous
- sur la description des changements significatifs et visibles de
- l'utilisateur qui ont été effectués depuis la dernière version.
- </p>
- <p>
- Ciblez <em>ce</em> qui a été changé — qui, comment et quand
- cela a été fait est généralement de moindre importance. Ceci dit,
- rappelez-vous de nommer poliment les personnes qui ont fourni une aide
- notable pour réaliser le paquet (par exemple, ceux qui ont envoyé des
- correctifs).
- </p>
- <p>
- Vous n'avez pas besoin de détailler les changements triviaux et
- évidents. Vous pouvez également regrouper plusieurs de ces changements
- dans une seule entrée. D'un autre côté, ne soyez pas trop concis si
- vous avez entrepris un changement majeur. Soyez tout spécialement
- clair s'il y a des changements qui modifient le comportement du
- programme. Pour plus d'explications, utilisez le fichier
- <file>README.Debian</file>.
- </p>
- <p>
- Utilisez un langage anglais commun pour que la majorité des lecteur
- puissent le comprendre. Évitez les abréviations, le parler technique
- et le jargon quand vous expliquez des changements fermant un bogue,
- spécialement pour les rapports de bogue créés par des utilisateurs qui
- ne vous paraissent pas particulièrement à l'aise techniquement. Vous
- devez être poli et ne pas jurer.
- </p>
- <p>
- Il est parfois désirable de préfixer les entrées de changelog avec le
- nom des fichiers qui ont été modifiés. Cependant, il n'est pas besoin
- de lister explicitement tous les fichiers modifiés, particulièrement
- si la modification est petite ou répétitive. Vous pouvez utiliser les
- caractères génériques.
- </p>
- <p>
- Quand vous faites référence aux bogues, ne supposez rien a
- priori. Dites ce qu'était le problème, comment il a été résolu et
- ajoutez la chaîne de caractères « closes: #nnnnn ». Veuillez
- voir <ref id="upload-bugfix"> pour plus d'informations.
- </p>
- </sect1>
- <sect1 id="bpp-changelog-misconceptions">
- <heading>
- idées fausses communes sur les entrées de changelog
- </heading>
- <p>
- Les entrées de changelog <strong>ne devraient pas</strong> documenter
- des problèmes génériques d'empaquetage (« Hé, si vous cherchez
- foo.conf, il est dans /etc/blah/. ») car les administrateurs et
- utilisateurs sont supposés être au moins vaguement rompus à la façon
- dont les choses sont arrangées sur un système Debian. Mentionnez
- cependant tout changement d'emplacement d'un fichier de configuration.
- </p>
- <p>
- Les seuls bogues fermés par une entrée de changelog devraient être
- ceux qui sont vraiment corrigés dans la même révision du
- paquet. Fermer des bogues non liés par le fichier changelog est
- considéré comme une très mauvaise pratique. Veuillez voir <ref
- id="upload-bugfix">.
- </p>
- <p>
- Les entrées de changelog <strong>ne devraient pas</strong> être le
- lieu de discussions avec les émetteurs de bogues (« Je ne vois
- pas de segfaults lors du lancement de foo avec l'option bar ;
- envoyez-moi plus d'informations. »), ni celui de phrases
- génériques sur la vie, l'univers et tout le reste (« Désolé, cet
- envoi m'a pris du temps, mais j'avais attrapé la grippe ») ou
- celui de demandes d'aide (« La liste des bogues sur ce paquet est
- énorme, donnez-moi un coup de main »). Ceci ne sera généralement
- pas remarqué par les personnes ciblées, mais peut ennuyer les
- personnes qui désirent lire des informations sur les changements réels
- du paquet. Veuillez vous reporter à <ref id="bug-answering"> pour plus
- d'informations sur la façon d'utiliser le système de suivi des bogues.
- </p>
- <p>
- C'est une vieille tradition de valider les bogues fixés par une mise à
- jour indépendante dans la première entrée du changelog de l'envoi du
- vrai responsable. Comme nous avons maintenant le suivi des versions, il
- est suffisant de garder les entrées de changelog des mises à jour
- indépendantes et de simplement mentionner ce fait dans votre propre
- entrée de changelog.
- </p>
- </sect1>
- <sect1 id="bpp-changelog-errors">
- <heading>
- Erreurs communes dans les entrées de changelogs
- </heading>
- <p>
- Les exemples suivants montrent des erreurs communes ou des exemples de
- mauvais style dans les entrées de changelog<footnote><p>NdT : Les
- entrées de changelog sont ici affichées en français pour faciliter la
- compréhension, mais vos entrées devront naturellement être rédigées en
- anglais.</p></footnote>.
- </p>
- <p>
- <example>
- * Corrige tous les bogues restants.
-</example>
- Ceci n'indique visiblement rien d'utile au lecteur.
- </p>
- <p>
- <example>
- * Correctif de Jane Random appliqué.
-</example>
- Sur quoi portait le correctif ?
- </p>
- <p>
- <example>
- * Révision de cible d'installation la nuit dernière.
-</example>
- Qu'a accompli la révision ? Est-ce que la mention de la nuit
- dernière est supposée nous rappeler que nous ne devons pas faire
- confiance à ce code ?
- </p>
- <p>
- <example>
- * Corrige MRD vsync av. anciens CRTs.
-</example>
- Trop d'acronymes et il n'est pas très clair de ce qu'était vraiment
- cette... euh... merde (oups, un mot interdit !) ou comment cela a
- été corrigé.
- </p>
- <p>
- <example>
- * Ceci n'est pas un bogue. Closes: #nnnnnn.
-</example>
- Premièrement, il n'y a absolument pas besoin d'envoyer un paquet pour
- communiquer cette information ; à la place, utilisez le système
- de suivi des bogues. Deuxièmement, il n'y a aucune explication
- concernant la raison pour laquelle le rapport n'était pas un bogue.
- </p>
- <p>
- <example>
- * A été fixé il y a longtemps, mais j'ai oublié de le fermer. Closes: #54321.
-</example>
- Si, pour toute raison, vous n'aviez pas indiqué le numéro du bogue
- dans une précédente entrée de changelog, ceci n'est pas un problème,
- fermez simplement le bogue normalement dans le BTS. Il n'y a pas
- besoin de modifier le fichier changelog, en supposant que la
- description de la correction est déjà intégrée (ceci s'applique aux
- correctifs par les auteurs/responsables amont également, vous n'avez
- pas à suivre les bogues qui ont été corrigés il y a longtemps dans
- votre changelog).
- </p>
- <p>
- <example>
- * Closes: #12345, #12346, #15432.
-</example>
- Où est la description ?! Si vous n'arrivez pas à trouver un
- message descriptif, commencez par insérer le titre de chacun des
- différents bogues.
- </p>
- </sect1>
- <sect1 id="bpp-news-debian">
- <heading>
- Compléter les changelogs avec les fichiers NEWS.Debian
- </heading>
- <p>
- Les nouvelles importantes à propos des changements dans un paquet
- peuvent également être placées dans les fichiers NEWS.Debian. Ces
- nouvelles seront affichées par des outils comme apt-listchanges, avant
- le reste des changelogs. Ceci est le moyen préféré pour informer les
- utilisateurs des changements significatifs dans un paquet. Il est
- préférable d'utiliser ce fichier plutôt que d'utiliser des notes
- debconf car c'est moins ennuyeux et l'utilisateur peut y revenir et se
- référer au fichier NEWS.Debian après l'installation. Et c'est mieux
- que de lister les changements principaux dans README.Debian car
- l'utilisateur peut facilement rater de telles notes.
- </p>
- <p>
- Le format du fichier est le même que pour un fichier de changelog
- Debian, mais il n'utilise pas d'astérisques et décrit chaque élément
- de nouvelle dans un paragraphe complet si nécessaire plutôt que les
- résumés concis qui iraient dans un changelog. C'est une bonne idée de
- passer votre fichier par dpkg-parsechangelog pour vérifier son
- formatage car il n'est pas vérifié automatiquement pendant la
- construction comme le changelog. Voici un exemple d'un vrai fichier
- NEWS.Debian :
- <example>
-cron (3.0pl1-74) unstable; urgency=low
-
- The checksecurity script is no longer included with the cron package:
- it now has its own package, "checksecurity". If you liked the
- functionality provided with that script, please install the new
- package.
-
- -- Steve Greenland <stevegr@debian.org> Sat, 6 Sep 2003 17:15:03 -0500
-</example>
- </p>
- <p>
- Le fichier NEWS.Debian est installé comme
- /usr/share/doc/<package>/NEWS.Debian.gz. Il est compressé et a
- toujours ce nom même dans les paquets natifs Debian. Si vous utilisez
- debhelper, dh_installchangelogs installera les fichiers debian/NEWS
- pour vous.
- </p>
- <p>
- À la différence des fichiers changelog, vous n'avez pas besoin de
- mettre à jour les fichiers NEWS.Debian à chaque nouvelle version. Ne
- les mettez à jour que si vous avez quelque chose de particulièrement
- important que l'utilisateur a besoin de savoir. Si vous n'avez pas de
- nouvelles du tout, il n'est pas nécessaire de fournir de fichier
- NEWS.Debian dans votre paquet. Pas de nouvelles, bonne nouvelle !
- </p>
- </sect1>
- </sect>
- <sect id="bpp-debian-maint-scripts">
- <heading>
- Les meilleures pratiques pour les scripts de maintenance
- </heading>
- <p>
- Les scripts de maintenance incluent les fichiers
- <file>debian/postinst</file>, <file>debian/preinst</file>,
- <file>debian/prerm</file> et <file>debian/postrm</file>. Ces scripts
- prennent en charge la configuration d'installation ou de
- désinstallation des paquets, ce qui n'est pas simplement créer ou
- supprimer des fichiers et des répertoires. Les instructions suivantes
- complètent la <url id="&url-debian-policy;" name="charte Debian">.
- </p>
- <p>
- Les scripts de maintenance doivent être idempotents. Cela veut dire que
- vous devez vous assurer que rien de grave ne se produit si un script
- est appelé deux fois là où il ne devrait habituellement être appelé
- qu'une fois.
- </p>
- <p>
- Les entrée et sortie standard peuvent être redirigées (par exemple,
- dans des tubes<footnote><p>pipes</p></footnote>) pour des besoins
- d'enregistrement d'activité, donc vous ne devez pas supposer que ce
- sont des tty.
- </p>
- <p>
- Tous les affichages et les configurations interactives devraient être
- minimisées. Quand cela est nécessaire, vous devriez utiliser le paquet
- <package>debconf</package> pour l'interface. Rappelez-vous que, dans
- tous les cas, l'affichage ne doit se faire que dans l'étape de
- configuration, <tt>configure</tt> du script de post-installation,
- <file>postinst</file>.
- </p>
- <p>
- Gardez les scripts de maintenance aussi simples que possible. Nous vous
- suggérons d'utiliser des scripts shell POSIX purs. Rappelez-vous, que
- si vous avez besoin d'une fonctionnalité de Bash, le script de
- maintenance doit préciser bash dans sa première ligne. Un shell POSIX
- ou Bash sont préférés à Perl car ils permettent à
- <package>debhelper</package> d'ajouter facilement des parties aux
- scripts.
- </p>
- <p>
- Si vous modifiez les scripts de maintenance, assurez-vous de tester la
- suppression du paquet, la double installation et la purge
- complète. Assurez-vous qu'il ne reste rien d'un paquet purgé,
- c'est-à-dire, que la purge doit enlever tout fichier créé, directement
- ou indirectement, par les scripts de maintenance.
- </p>
- <p>
- Si vous avez besoin de vérifier l'existence d'une commande, vous
- devriez utiliser quelque chose comme :
- <example>if [ -x /usr/sbin/install-docs ]; then ...</example>
- Si vous ne désirez pas mettre en dur le chemin d'une commande dans le
- script de maintenance, la fonction de shell suivante conforme à POSIX
- peut vous aider : &example-pathfind; Vous pouvez utiliser cette
- fonction pour rechercher le <tt>$PATH</tt> pour un nom de commande
- passé en paramètre. Il renvoie vrai (zéro) si la commande a été trouvée
- et faux sinon. Il s'agit réellement de la façon la plus portable de
- faire car <tt>command -v</tt>, <prgn>type</prgn> et <prgn>which</prgn>
- ne sont pas POSIX.
- </p>
- <p>
- Bien que <prgn>which</prgn> soit une alternative acceptable car il est
- présent dans le paquet classé <em>required</em>
- <package>debianutils</package>, il n'est pas présent dans la partition
- racine. Autrement dit, il est placé dans <file>/usr/bin</file> au lieu
- de <file>/bin</file>, il n'est donc pas possible de l'utiliser dans les
- scripts qui sont exécutés avant que la partition <file>/usr</file> soit
- montée. Cependant, la plupart des scripts n'auront pas ce problème.
- </p>
- </sect>
- <sect id="bpp-config-mgmt">
- <heading>
- Gestion de la configuration avec <package>debconf</package>
- </heading>
- <p>
- <package>Debconf</package> est un système de gestion de configuration
- qui peut être utilisé par les divers scripts de maintenance
- (principalement en post-installation dans le fichier
- <file>postinst</file>) pour demander à l'utilisateur des informations
- concernant la configuration du paquet. Il faut maintenant éviter les
- interactions directes avec l'utilisateur et préférer les interactions
- utilisant <package>debconf</package>. Ceci permettra à l'avenir des
- installations non interactives.
- </p>
- <p>
- Debconf est un bon outil, mais il est souvent mal utilisé. Plusieurs
- erreurs communes sont référencées dans la page de manuel <manref
- section="7" name="debconf-devel">. Vous devriez vraiment lire cette
- page si vous décidez d'utiliser debconf. Nous documentons également
- plusieurs des meilleures pratiques ici.
- </p>
- <p>
- Ces lignes directives incluent plusieurs recommandations de style
- d'écriture et de typographie, des considérations générales à propos de
- l'utilisation de debconf ainsi que des recommandations plus spécifiques
- pour certaines parties de la distribution (par exemple, le système
- d'installation).
- </p>
- <sect1>
- <heading>
- N'abusez pas de debconf
- </heading>
- <p>
- Depuis que debconf est apparu dans Debian, il a été largement abusé et
- plusieurs critiques reçues par la distribution Debian proviennent
- d'utilisation abusive de debconf avec la nécessité de répondre à un
- grand nombre de questions avant d'avoir n'importe quel petit logiciel
- d'installé.
- </p>
- <p>
- Garder les notes d'utilisation à leur place : le fichier
- NEWS.Debian ou le fichier README.Debian. N'utilisez des notes que pour
- des notes importantes qui peuvent directement concerner l'utilisation
- du paquet. Rappelez-vous que les notes bloqueront toujours
- l'installation avant leur confirmation ou qu'elles embêtent
- l'utilisateur par un courriel.
- </p>
- <p>
- Choisissez avec soin les priorités des questions dans les scripts de
- responsable. Reportez-vous à <manref section="7" name="debconf-devel">
- pour plus de détails sur les priorités. La plupart des questions
- devraient utiliser un priorité moyenne ou basse.
- </p>
- </sect1>
- <sect1>
- <heading>
- Recommandations générales pour les auteurs et traducteurs
- </heading>
- <p>
- </p>
- <sect2>
- <heading>
- Écrivez un anglais correct
- </heading>
- <p>
- La plupart des responsables de paquets Debian n'ont pas l'anglais
- comme langue maternelle. Écrire des modèles correctement rédigés peut
- donc ne pas être facile pour eux.
- </p>
- <p>
- Veuillez utiliser (et abuser de) la liste de discussions
- &email-debian-l10n-english;. Faites relire vos questionnaires.
- </p>
- <p>
- Des questionnaires écrits incorrectement donnent une pauvre image de
- votre paquet, de votre travail... ou même de Debian elle-même.
- </p>
- <p>
- Évitez le jargon technique autant que possible. Si certains termes
- vous semblent courants, ils peuvent être impossibles à expliquer à
- d'autres personnes. Si vous ne pouvez pas les éviter, essayez de les
- expliquer (en utilisant la description étendue). Quand vous faites
- cela, essayez d'équilibrer la verbosité et la simplicité.
- </p>
- </sect2>
- <sect2>
- <heading>
- Être courtois avec les traducteurs
- </heading>
- <p>
- Les questionnaires debconf peuvent être traduits. Debconf, avec son
- paquet-frêre <package>po-debconf</package>, offre un cadre de travail
- simple pour obtenir des questionnaires traduits par les équipes de
- traduction ou même par des individus isolés.
- </p>
- <p>
- Veuillez utiliser les questionnaires basés sur gettext. Installez
- <package>po-debconf</package> sur votre système de développement et
- lisez sa documentation (« man po-debconf » est un bon
- début).
- </p>
- <p>
- Évitez de changer vos questionnaires trop souvent. Modifier le texte
- des questionnaires entraîne plus de travail pour les traducteurs dont
- les traductions seront rendues « floues »
- (« fuzzy »). Si vous prévoyez des modifications dans vos
- questionnaires d'origine, veuillez contacter les traducteurs. La
- plupart des traducteurs actifs sont très réactifs et obtenir leur
- travail inclus avec vos questionnaires modifiés vous économisera des
- envois supplémentaires. Si vous utilisez des modèles basés sur
- gettext, le nom et l'adresse électronique du traducteur sont
- mentionnés dans les en-têtes des fichiers PO.
- </p>
- <p>
- L'utilisation de <prgn>podebconf-report-po</prgn> du paquet
- <package>po-debconf</package> est hautement recommandée pour avertir
- les traducteurs qui ont des traductions incomplètes et pour leur
- demander des mises à jour.
- </p>
- <p>
- En cas de doutes, vous pouvez également contacter l'équipe de
- traduction pour une langue donnée
- (debian-l10n-xxxxx@lists.debian.org) ou la liste de discussions
- &email-debian-i18n;.
- </p>
- <p>
- Les appels à traductions postés sur &email-debian-i18n; avec le
- fichier <file>debian/po/templates.pot</file> attaché ou référencé
- dans une URL sont encouragés. Assurez-vous de mentionner dans ces
- appels pour de nouvelles traductions quelles sont les langues pour
- lesquelles vous avez déjà des traductions existantes, pour éviter
- toute duplication de travail.
- </p>
- </sect2>
- <sect2>
- <heading>
- « Dé-fuzzy-fiez » les traductions complètes lors des
- corrections de typos et d'orthographe
- </heading>
- <p>
- Quand le texte d'un questionnaire debconf est corrigé et que vous
- êtes <strong>certain</strong> que les changements <strong>n'ont
- aucun</strong> effet sur les traductions, soyez courtois avec les
- traducteurs et dé-fuzzy-fiez leurs traductions.
- </p>
- <p>
- Si vous ne le faites pas, le questionnaire entier ne sera pas traduit
- jusqu'à ce qu'un traducteur vous envoie une mise à jour.
- </p>
- <p>
- Pour <strong>dé-fuzzy-fier</strong> les traductions, vous pouvez
- procéder ainsi :
- <enumlist numeration="arabic">
- <item>
- <p>
- enlevez tous les fichiers PO incomplets. Vous pouvez vérifier si
- les fichiers sont complets en utilisant (il faut que le paquet
- <package>gettext</package> soit installé) :
- <example>for i in debian/po/*po; do echo -n $i: ; msgfmt -o /dev/null
---statistics $i; done</example>
- </p>
- </item>
- <item>
- <p>
- déplacez tous les fichiers ayant des chaînes floues
- (« fuzzy ») dans un emplacement temporaire. Les fichiers
- n'ayant aucune chaîne floue (seulement des chaînes traduites et
- non traduites) seront conservées où ils sont placés,
- </p>
- </item>
- <item>
- <p>
- maintenant <strong>et seulement maintenant</strong>, corrigez les
- typos dans le questionnaire et vérifiez que les traductions ne
- sont pas impactées (les typos, les fautes d'orthographe et parfois
- les corrections de typographie sont généralement acceptables),
- </p>
- </item>
- <item>
- <p>
- exécutez <prgn>debconf-updatepo</prgn>. Cela va fuzzifier toutes
- les chaînes que vous avez modifiées dans les traductions. Vous
- pouvez constater cela en exécutant à nouveau la commande
- ci-dessus,
- </p>
- </item>
- <item>
- <p>
- utilisez la commande suivante :
- <example>for i in debian/po/*po; do msgattrib --output-file=$i --clear-fuzzy $i; done</example>
- </p>
- </item>
- <item>
- <p>
- déplacez dans debian/po les fichiers qui avaient des chaînes
- floues dans la première étape,
- </p>
- </item>
- <item>
- <p>
- exécutez à nouveau <prgn>debconf-updatepo</prgn>.
- </p>
- </item>
- </enumlist>
- </p>
- </sect2>
- <sect2>
- <heading>
- Ne faites pas de suppositions à propos des interfaces
- </heading>
- <p>
- Le texte des modèles ne doit pas faire référence aux composants
- appartenant à l'une des interfaces debconf. Des phrases comme
- « If you answer Yes... » n'a aucun sens pour les
- utilisateurs d'interfaces graphiques qui utilisent des cases à cocher
- pour les questions booléennes.
- </p>
- <p>
- Les modèles de chaînes de caractères devraient éviter de mentionner
- les valeurs par défaut dans leur description. Tout d'abord, parce que
- cela est redondant avec les valeurs lues par les
- utilisateurs. Ensuite, parce ces valeurs par défaut peuvent être
- différentes selon les choix du responsable (par exemple, quand la
- base de données debconf a été préremplie).
- </p>
- <p>
- Plus généralement, essayez d'éviter de vous référer à toute action de
- l'utilisation. Donnez simplement des faits.
- </p>
- </sect2>
- <sect2>
- <heading>
- N'utilisez pas la première personne
- </heading>
- <p>
- Vous devriez éviter d'utiliser la première personne (« I will do
- this... » ou « We recommend... »). L'ordinateur n'est
- pas une personne et les questionnaires debconf ne parlent pas pour
- les développeurs Debian. Vous devriez utiliser une construction
- neutre et souvent une forme passive. Pour ceux d'entre vous qui
- écrivent déjà des publications scientifiques, écrivez simplement vos
- questionnaires comme vous écririez un papier scientifique.
- </p>
- </sect2>
- <sect2>
- <heading>
- Soyez neutre dans le genre
- </heading>
- <p>
- Le monde est fait d'hommes et de femmes. Veuillez utiliser des
- constructions neutres dans le genre dans votre texte. Ce n'est pas du
- politiquement correct, c'est simplement montrer du respect pour toute
- l'humanité.
- </p>
- </sect2>
- </sect1>
- <sect1>
- <heading>
- Définition des champs de questionnaires
- </heading>
- <p>
- Cette partie donne plusieurs informations qui sont principalement
- extraites de la page de manuel <manref section="7"
- name="debconf-devel">.
- </p>
- <sect2>
- <heading>
- Type
- </heading>
- <p>
- </p>
- <sect3>
- <heading>
- string: (chaîne de caractères)
- </heading>
- <p>
- Résulte en un champ d'entrée libre dans lequel l'utilisateur peut
- écrire toute chaîne.
- </p>
- </sect3>
- <sect3>
- <heading>
- password: (mot de passe)
- </heading>
- <p>
- Demande un mot de passe à l'utilisateur. Veuillez utiliser ce champ
- avec précaution ; soyez conscient que le mot de passe que
- l'utilisateur entre sera écrit dans la base de données debconf. Vous
- devriez probablement enlever cette valeur de la base de données dès
- que possible.
- </p>
- </sect3>
- <sect3>
- <heading>
- boolean: (booléen)
- </heading>
- <p>
- Un choix vrai/faux. Rappelez-vous : vrai/faux, <strong>pas oui/non</strong>...
- </p>
- </sect3>
- <sect3>
- <heading>
- select: (sélection)
- </heading>
- <p>
- Un choix parmi un certain nombre de valeurs. Les choix doivent être
- spécifiés dans un champ nommé « Choices ». Séparez les
- valeurs possibles par des virgules et des espaces ainsi :
- Choices: yes, no, maybe
- </p>
- </sect3>
- <sect3>
- <heading>
- multiselect: (sélection multiple)
- </heading>
- <p>
- Comme le type de données select, excepté que l'utilisateur peut
- choisir un nombre quelconque d'éléments dans la liste de choix (ou
- aucun d'entre eux).
- </p>
- </sect3>
- <sect3>
- <heading>
- note: (note)
- </heading>
- <p>
- Plutôt que d'être une question en tant que telle, ce type de donnée
- indiqué une note qui peut être affichée à l'utilisateur. Il ne
- devrait être utilisé que pour des données importantes que
- l'utilisateur doit réellement voir, car debconf fera tout ce qu'il
- peut pour s'assurer que l'utilisateur le voit ; il stoppera
- l'installation en attendant que l'utilisateur appuie sur une touche
- ou il leur enverra même la note par courrier dans certains cas.
- </p>
- </sect3>
- <sect3>
- <heading>
- text: (texte)
- </heading>
- <p>
- Ce type est maintenant considéré comme obsolète : ne l'utilisez
- pas.
- </p>
- </sect3>
- <sect3>
- <heading>
- error: (erreur)
- </heading>
- <p>
- <strong>CE TYPE DE MODÈLE N'EST PAS ENCORE GÉRÉ PAR
- DEBCONF.</strong>
- </p>
- <p>
- Il a été ajouté à cdebconf, la version C de debconf, utilisé en
- premier dans l'installateur Debian.
- </p>
- <p>
- Veuillez ne pas l'utiliser à moins que debconf ne le prenne en
- charge.
- </p>
- <p>
- Ce type est conçu pour gérer des messages d'erreur. Il est presque
- semblable au type « note ». Des interfaces peuvent le
- présenter différemment (par exemple, l'interface dialog de cdebconf
- affiche un écran rouge au lieu de l'écran bleu habituel).
- </p>
- </sect3>
- </sect2>
- <sect2>
- <heading>
- Description: description courte et étendue
- </heading>
- <p>
- Les descriptions des modèles sont composées de deux parties :
- une courte et une étendue. La description courte est dans la ligne
- « Description: » du questionnaire.
- </p>
- <p>
- La description courte devrait être gardée courte (50 caractères
- ou moins) pour qu'elle puisse être ajustée par la plupart des
- interfaces debconf. La garder courte aide également les traducteurs,
- car les traductions ont tendance à être plus longues que l'original.
- </p>
- <p>
- La description courte devrait se suffire à elle-même. Certaines
- interfaces n'affichent pas la description longue par défaut ou
- seulement si l'utilisateur la demande explicitement ou même ne
- l'affichent pas du tout. Évitez des choses comme « What do you
- want to do ? ».
- </p>
- <p>
- Il n'est pas nécessaire que la description courte soit une phrase
- complète. Cela fait partie de la recommandation « gardez-la
- courte et efficace ».
- </p>
- <p>
- La description étendue ne devrait pas répéter la description courte
- mot pour mot. Si vous ne trouvez pas de description longue, commencez
- par à y réfléchir plus. Envoyez un message sur debian-devel. Demandez
- de l'aide. Suivez un cours d'écriture ! La description étendue
- est importante. Si, après tout cela, vous ne trouvez toujours rien,
- laissez-la vide.
- </p>
- <p>
- La description étendue devrait utiliser des phrases complètes. Des
- paragraphes devraient être gardés court pour améliorer la
- lisibilité. Ne mélangez pas deux idées dans le même paragraphe, mais
- utilisez plutôt un autre paragraphe.
- </p>
- <p>
- Ne soyez pas trop verbeux. Les utilisateurs ont tendance à ignorer les
- écrans trop longs. Par expérience, 20 lignes est la limite à
- éviter de dépasser car cela veut dire sinon que, dans l'interface dialogue
- classique, les utilisateurs devront faire défiler le texte et un grand
- nombre de personnes ne le font simplement pas.
- </p>
- <p>
- Pour des règles spécifiques selon le type de questionnaire (chaîne de
- caractères, booléen, etc.), veuillez lire ci-dessous.
- </p>
- </sect2>
- <sect2>
- <heading>
- Choices (choix)
- </heading>
- <p>
- Ce champ devrait utilisé pour des types Select et Multiselect. Il
- contient les choix possibles qui seront présentés aux
- utilisateurs. Ces choix devraient être séparés par des virgules.
- </p>
- </sect2>
- <sect2>
- <heading>
- Default (valeur par défaut)
- </heading>
- <p>
- Ce champ est facultatif. Il contient la réponse par défaut pour les
- modèles chaîne de caractères, sélection et multi-sélection. Pour des
- questionnaires multi-sélection, il peut contenir une liste de choix
- séparés par des virgules.
- </p>
- </sect2>
- </sect1>
- <sect1>
- <heading>
- Guide de style spécifique par champ de questionnaires
- </heading>
- <p>
- </p>
- <sect2>
- <heading>
- Champ Type
- </heading>
- <p>
- Aucune indication spécifique excepté : utilisez le type
- approprié en vous référant à la section précédente.
- </p>
- </sect2>
- <sect2>
- <heading>
- Champ Description
- </heading>
- <p>
- Voici ci-dessous des instructions spécifiques pour écrire
- correctement la description (courte et étendue) selon le type de
- questionnaire.
- </p>
- <sect3>
- <heading>
- questionnaire chaîne de caractères/mot de passe
- </heading>
- <p>
- <list>
- <item>
- <p>
- La description courte est une invite et <strong>non</strong> un
- titre. Évitez des invites de style question (« IP
- Address? ») en faveur d'invites « ouvertes »à
- (« IP address: »). L'utilisation des deux-points est
- recommandée.
- </p>
- </item>
- <item>
- <p>
- La description étendue est un complément à la description
- courte. Dans la partie étendue, expliquez ce qui est demandé,
- plutôt que de poser la même question à nouveau en utilisant des
- mots plus longs. Utilisez des phrases complètes. Un style
- d'écriture trop concis est fortement découragé.
- </p>
- </item>
- </list>
- </p>
- </sect3>
- <sect3>
- <heading>
- modèles booléens
- </heading>
- <p>
- <list>
- <item>
- <p>
- La description courte devrait être rédigée sous la forme d'une
- question qui devrait être gardée courte et devrait généralement
- se terminer par un point d'interrogation. Un style d'écriture
- concis est permis et même encouragé si la question est plutôt
- longue (rappelez-vous que les traductions sont souvent plus
- longue que les versions d'origine)
- </p>
- </item>
- <item>
- <p>
- La description étendue ne devrait <strong>pas</strong> inclure de
- question.
- </p>
- </item>
- <item>
- <p>
- À nouveau, veuillez éviter de vous référer à des composants
- d'interface spécifiques. Une erreur courante pour de telles
- questionnaires est les constructions du type « if you answer
- Yes ».
- </p>
- </item>
- </list>
- </p>
- </sect3>
- <sect3>
- <heading>
- sélection/multi-sélection
- </heading>
- <p>
- <list>
- <item>
- <p>
- La description courte est une invite et <strong>non</strong> un
- titre. N'utilisez <strong>pas</strong> des constructions inutiles
- du type « Please choose... ». Les utilisateurs sont assez
- intelligents pour réaliser qu'ils doivent choisir quelque chose...:)
- </p>
- </item>
- <item>
- <p>
- La description étendue devra compléter la description
- courte. Elle peut se référer aux choix disponibles. Elle peut
- également mentionner que l'utilisateur peut choisir plus d'un des
- choix disponibles si le questionnaire est du type sélection
- multiple (bien que l'interface rende souvent cela clair).
- </p>
- </item>
- </list>
- </p>
- </sect3>
- <sect3>
- <heading>
- Notes
- </heading>
- <p>
- <list>
- <item>
- <p>
- La description courte devrait être considéré comme un *titre*.
- </p>
- </item>
- <item>
- <p>
- La description étendue est ce qui sera affiché comme une
- description plus détaillée de la note. Faites des phrases,
- n'utilisez pas un style d'écriture trop concis.
- </p>
- </item>
- <item>
- <p>
- <strong>N'abusez pas de debconf.</strong> Les notes sont le moyen le plus courant
- d'abus de debconf. Comme il est écrit dans la page de manuel de
- debconf-devel : il est préférable de ne les utiliser que
- pour des avertissements à propos de problèmes très sérieux. Les
- fichiers NEWS.Debian ou README.Debian sont les endroits
- appropriés pour un grand nombre de notes. Si, en lisant ceci,
- vous envisagez de convertir vos modèles de type note en entrées
- dans NEWS/Debian ou README.Debian, veuillez considérer de
- conserver les traductions existantes pour une utilisation future.
- </p>
- </item>
- </list>
- </p>
- </sect3>
- </sect2>
- <sect2>
- <heading>
- Champ de choix
- </heading>
- <p>
- S'il est probable que les choix changent souvent, veuillez considérer
- l'utilisation de l'astuce « __Choices ». Cela séparera
- chaque choix individuel en une chaîne de caractères seule, ce qui
- aidera considérablement les traducteurs à faire leur travail.
- </p>
- </sect2>
- <sect2>
- <heading>
- Champ par défaut
- </heading>
- <p>
- S'il est probable que la valeur par défaut d'un modèle
- « select » change selon la langue de l'utilisateur (par
- exemple, s'il s'agit d'un choix de langue), veuillez utiliser
- l'astuce « _DefaultChoice ».
- </p>
- <p>
- Ce champ spécial permet aux traducteurs de positionner le choix le
- plus approprié selon leur propre langue. Cela deviendra le choix par
- défaut quand leur langue sera sélectionnée alors votre choix par
- défaut sera utilisé pour l'anglais.
- </p>
- <p>
- Un exemple tiré des modèles du paquet geneweb :
- <example>
-Template: geneweb/lang
-Type: select
-__Choices: Afrikaans (af), Bulgarian (bg), Catalan (ca), Chinese (zh), Czech (cs), Danish (da), Dutch (nl), English (en), Esperanto (eo), Estonian (et), Finnish (fi), French (fr), German (de), Hebrew (he), Icelandic (is), Italian (it), Latvian (lv), Norwegian (no), Polish (pl), Portuguese (pt), Romanian (ro), Russian (ru), Spanish (es), Swedish (sv)
-# This is the default choice. Translators may put their own language here
-# instead of the default.
-# WARNING : you MUST use the ENGLISH FORM of your language
-# For instance, the french translator will need to put "French (fr)" here.
-_DefaultChoice: English (en)[ translators, please see comment in PO files]
-_Description: Geneweb default language:
-</example>
- </p>
- <p>
- Notez l'utilisation de crochets qui permettent des commentaires
- internes dans les champs debconf. Notez également l'utilisation de
- commentaires qui apparaîtront dans les fichiers sur lesquels
- travailleront les traducteurs.
- </p>
- <p>
- Les commentaires sont nécessaires car l'astuce DefaultChoice est un
- peu déroutante : les traducteurs peuvent y placer leur propre
- choix.
- </p>
- </sect2>
- <sect2>
- <heading>
- Champ par défaut
- </heading>
- <p>
- N'utilisez PAS de champ par défaut vide. Si vous ne voulez pas
- utiliser de valeurs par défaut, n'utilisez simplement pas du tout
- Default.
- </p>
- <p>
- Si vous utilisez po-debconf (et vous <strong>devriez</strong> le faire, voir 2.2),
- veuillez considérer de rendre ce champ traduisible, si vous pensez
- qu'il peut être traduit.
- </p>
- <p>
- Si la valeur par défaut peut varier selon la langue ou le pays (par
- exemple, la valeur par défaut pour un choix de langue), veuillez
- considérer l'utilisation du type spécial « _DefaultChoice »
- documenté dans <manref section="7" name="po-debconf">).
- </p>
- </sect2>
- </sect1>
- </sect>
- <sect id="bpp-i18n">
- <heading>
- Internationalisation
- </heading>
- <sect1 id="bpp-i18n-debconf">
- <heading>
- Gestion des traductions de debconf
- </heading>
- <p>
- Comme les porteurs, les traducteurs ont une tâche difficile. Ils
- travaillent sur un grand nombre de paquets et doivent donc collaborer
- avec plusieurs responsables différents. De plus, la plupart du temps,
- l'anglais n'est pas leur langue maternelle, il se peut que vous deviez
- être particulièrement patient avec eux.
- </p>
- <p>
- Le but de <package>debconf</package> était de faciliter la
- configuration des paquets aux responsables et aux utilisateurs. À
- l'origine, les traductions des questionnaires debconf étaient gérées
- avec <prgn>debconf-mergetemplate</prgn>. Cependant, cette technique
- est maintenant déconseillée ; la meilleure façon pour
- l'internationalisation de <package>debconf</package> est d'utiliser le
- paquet <package>po-debconf</package>. Cette méthode est plus facile
- pour le responsable et pour les traducteurs ; des scripts de
- transition sont fournis.
- </p>
- <p>
- Lors de l'utilisation de <package>po-debconf</package>, la traduction
- est stockée dans des fichiers <file>po</file> (à l'instar des
- techniques de traduction de <prgn>gettext</prgn>). Des fichiers
- modèles contiennent les messages d'origine et indiquent quels sont les
- champs traduisibles. Quand vous modifiez l'état d'un champ traduisible
- en appelant <prgn>debconf-updatepo</prgn>, la traduction est marquée
- comme ayant besoin de l'attention des traducteurs. Puis, lors de la
- construction du paquet, le programme <prgn>dh_installdebconf</prgn>
- prendra soin de toute la magie nécessaire à l'ajout du modèle avec les
- traductions à jour dans les paquets binaires. Veuillez vous reporter à
- la page de manuel <manref section="7" name="po-debconf"> pour les
- détails.
- </p>
- </sect1>
- <sect1 id="bpp-i18n-docs">
- <heading>
- Documentation traduite
- </heading>
- <p>
- La traduction de la documentation est cruciale pour les utilisateurs,
- mais elle représente un important travail. Il n'existe aucun moyen
- d'éliminer ce travail, mais vous pouvez faciliter les choses pour les
- traducteurs.
- </p>
- <p>
- Si vous êtes responsable d'une documentation quelle que soit sa
- taille, il est plus facile pour les traducteurs d'avoir accès à un
- système de contrôle de source. Ceci permet aux traducteurs de voir les
- différences entre deux versions de la documentation, pour, par
- exemple, qu'ils puissent voir ce qui a besoin d'être retraduit. Il est
- recommandé que le document traduit inclue une note à propos de la
- révision de contrôle du source sur laquelle la traduction est
- basée. Un système intéressant est fourni par <url
- id="&url-i18n-doc-check;" name="doc-check"> dans le paquet
- <package>boot-floppies</package> qui donne un aperçu de l'état de la
- traduction pour une langue donnée, en utilisant les commentaires
- structurés pour une révision donnée du fichier à traduire et, pour un
- fichier traduit, la révision du fichier d'origine sur laquelle la
- traduction est basée. Vous pouvez vouloir adapter et fournir ceci dans
- votre référentiel CVS.
- </p>
- <p>
- Si vous maintenez de la documentation au format XML ou SGML, nous vous
- suggérons d'isoler les informations indépendantes de la langue et de
- les définir comme des entités dans un fichier séparé qui sera inclus
- par les différentes traductions. Ceci aide, par exemple, à garder à
- jour les adresses pour plusieurs fichiers.
- </p>
- </sect1>
- </sect>
- <sect id="bpp-common-situations">
- <heading>
- Pratiques communes d'empaquetage
- </heading>
- <sect1 id="bpp-autotools">
- <heading>
- Paquets utilisant <prgn>autoconf</prgn>/<prgn>automake</prgn>
- </heading>
- <p>
- Conserver à jour les fichiers d'<prgn>autoconf</prgn>,
- <file>config.sub</file> et <file>config.guess</file>, est critique
- pour les porteurs, spécialement pour les architectures plus
- changeantes. De très bonnes pratiques d'empaquetage utilisant
- <prgn>autoconf</prgn> et/ou <prgn>automake</prgn> ont été regroupées
- dans &file-bpp-autotools; du paquet
- <package>autotools-dev</package>. Vous êtes vivement encouragé à lire
- ce fichier et à suivre les recommandations indiquées.
- </p>
- </sect1>
- <sect1 id="bpp-libraries">
- <heading>
- Bibliothèques
- </heading>
- <p>
- Pour diverses raisons, il a toujours été difficile d'empaqueter les
- bibliothèques. La charte impose plusieurs contraintes pour faciliter
- la maintenance et pour garantir que les mises à jour sont aussi
- simples que possible quand une nouvelle version amont est
- disponible. Une erreur dans une bibliothèque peut rendre défectueux
- une douzaine de paquets qui en dépendent.
- </p>
- <p>
- Les bonnes pratiques d'empaquetage des bibliothèques ont été
- regroupées dans <url id="&url-libpkg-guide;" name="le guide
- d'empaquetage des bibliothèques">.
- </p>
- </sect1>
- <sect1 id="bpp-docs">
- <heading>
- Documentation
- </heading>
- <p>
- Assurez-vous de suivre les <url id="&url-debian-policy;ch-docs.html"
- name="règles sur la documentation">.
- </p>
- <p>
- Si votre paquet contient de la documentation construite à partir de
- XML ou SGML, nous vous recommandons de ne pas fournir le source XML ou
- SGML dans le(s) paquet(s) binaire(s). Si les utilisateurs désirent
- avoir le source de la documentation, ils peuvent récupérer le paquet
- source.
- </p>
- <p>
- La Charte spécifie que la documentation doit être fournie au format
- HTML. Nous vous recommandons également de la fournir au format PDF et
- texte simple si c'est adapté et qu'une sortie de qualité raisonnable
- est possible. Cependant, il n'est généralement pas approprié de
- fournir des versions en texte simple pour la documentation dont le
- format source est du HTML.
- </p>
- <p>
- Les principaux manuels fournis devraient être enregistrés par le
- paquet <package>doc-base</package> à l'installation. Reportez-vous à
- la documentation du paquet <package>doc-base</package> pour plus
- d'information.
- </p>
- </sect1>
- <sect1 id="bpp-other">
- <heading>
- Types spécifiques de paquets
- </heading>
- <p>
- Plusieurs types spécifiques de paquets ont des sous-chartes spéciales
- et des règles et pratiques d'empaquetage correspondantes :
- <list>
- <item>
- <p>
- Les paquets liés à Perl ont leur <url id="&url-perl-policy;"
- name="charte Perl">, quelques exemples de paquets qui suivent cette
- charte sont <package>libdbd-pg-perl</package> (module perl binaire)
- ou <package>libmldbm-perl</package> (module perl indépendant de
- l'architecture).
- </p>
- </item>
- <item>
- <p>
- Les paquets liés à Python ont leur charte Python ; voir
- &file-python-policy; dans le paquet <package>python</package>.
- </p>
- </item>
- <item>
- <p>
- Les paquets liés à Emacs ont leur <url id="&url-emacs-policy;"
- name="charte Emacs">.
- </p>
- </item>
- <item>
- <p>
- Les paquets liés à Java ont leur <url id="&url-java-policy;"
- name="charte Java">.
- </p>
- </item>
- <item>
- <p>
- Les paquets liés à Ocaml ont leur propre charte que l'on trouve
- dans &file-ocaml-policy; du paquet <package>ocaml</package>. Un bon
- exemple est le paquet source <package>camlzip</package>.
- </p>
- </item>
- <item>
- <p>
- Les paquets fournissant des DTD XML ou SGML devraient se conformer
- aux recommandations que l'on peut trouver dans le paquet
- <package>sgml-base-doc</package>
- </p>
- </item>
- <item>
- <p>
- Les paquets Lisp devraient s'enregistrer avec le paquet
- <package>common-lisp-controller</package> pour lequel vous pouvez
- vous reporter au fichier &file-lisp-controller;.
- </p>
- </item>
- </list>
- </p>
- </sect1>
- <sect1 id="bpp-archindepdata">
- <heading>
- Données indépendantes de l'architecture
- </heading>
- <p>
- Il n'est pas rare d'avoir une grande quantité de données indépendantes
- de l'architecture fournie avec un programme. Par exemple, des fichiers
- audio, une collection d'icônes, des motifs de papiers peints ou autres
- fichiers graphiques. Si la taille des données est négligeable par
- rapport à la taille du reste du paquet, il est probablement mieux de
- tout garder dans le même paquet.
- </p>
- <p>
- Cependant, si la taille des données est considérable, vous devez
- envisager de les partager dans un paquet séparé et indépendant de
- l'architecture (« _all.deb »). Ainsi, en faisant cela, vous
- évitez une duplication inutile des mêmes données dans onze fichiers
- .debs pour chaque architecture. Bien que ceci ajoute une surcharge
- supplémentaire aux fichiers <file>Packages</file>, ceci sauve beaucoup
- d'espace disque sur les miroirs Debian. Séparer les données
- indépendantes de l'architecture réduit également le temps de
- traitement de <prgn>lintian</prgn> ou de <prgn>linda</prgn> (voir <ref
- id="tools-lint">) quand ils sont exécutés sur l'ensemble de l'archive
- Debian.
- </p>
- </sect1>
- <sect1 id="bpp-locale">
- <heading>
- Avoir besoin d'une certaine locale pendant la construction
- </heading>
- <p>
- Si vous avez besoin d'une certaine locale pendant la construction,
- vous pouvez créer un fichier temporaire par cette astuce :
- </p>
- <p>
- Si vous positionnez LOCPATH à l'équivalent de /usr/lib/locale, et
- LC_ALL au nom de la locale que vous générez, vous devriez obtenir ce
- que vous voulez sans être root. Quelque chose comme ceci :
- <example>
-LOCALE_PATH=debian/tmpdir/usr/lib/locale
-LOCALE_NAME=en_IN
-LOCALE_CHARSET=UTF-8
-
-mkdir -p $LOCALE_PATH
-localedef -i "$LOCALE_NAME.$LOCALE_CHARSET" -f "$LOCALE_CHARSET" "$LOCALE_PATH/$LOCALE_NAME.$LOCALE_CHARSET"
-
-# Using the locale
-LOCPATH=$LOCALE_PATH LC_ALL=$LOCALE_NAME.$LOCALE_CHARSET date
-</example>
- </p>
- </sect1>
- <sect1 id="bpp-transition">
- <heading>
- Rendre les paquets de transition conformes avec deborphan
- </heading>
- <p>
- Deborphan est un programme pour aider les utilisateurs à détecter
- quels paquets peuvent être enlevés sans problème du système, i.e. ceux
- dont aucun paquet ne dépend. L'opération par défaut est de chercher
- seulement parmi les sections libs et oldlibs pour débusquer les
- bibliothèques inutilisées. Mais si l'on passe le bon paramètre, il
- tente d'attraper d'autres paquets inutiles.
- </p>
- <p>
- Par exemple, avec --guess-dummy, deborphan cherche tous les paquets de
- transition qui étaient nécessaires pour une mise à jour, mais qui
- peuvent sans problème être supprimés. Pour cela, il recherche la
- chaîne de caractères « dummy » ou « transitional »
- dans la description courte.
- </p>
- <p>
- Ainsi, quand vous créez un tel paquet, assurez-vous d'ajouter ce texte
- dans la description courte. Si vous cherchez des exemples, exécutez
- simplement :
- <example>apt-cache search .|grep dummy</example>
- or
- <example>apt-cache search .|grep transitional</example>
- .
- </p>
- </sect1>
- <sect1 id="bpp-origtargz">
- <heading>
- Les meilleures pratiques pour les fichiers <file>orig.tar.gz</file>
- </heading>
- <p>
- Il existe deux types d'archives tar (« tarball ») source
- d'origine : les sources vierges et les sources amont
- réempaquetées.
- </p>
- <sect2 id="pristinesource">
- <heading>
- Sources vierges
- </heading>
- <p>
- La caractéristique définissant une archive source vierge est que le
- fichier .orig.tar.gz est identique octet-pour-octet à l'archive tar
- officielle distribuée par l'auteur amont. <footnote><p>Nous ne
- pouvons pas empêcher les auteurs amont de changer l'archive tar
- qu'ils distribuent sans également incrémenter le numéro de version,
- il ne peut donc pas y avoir de garantie qu'une archive vierge est
- identique à ce que l'auteur amont distribue <em>actuellement</em> à
- tout moment. La seule chose à laquelle on peut s'attendre est que
- c'est identique à quelque chose que l'amont <em>a</em> un jour
- distribuée. Si une différence se produit plus tard (par exemple, si
- l'amont remarque qu'il n'a pas utilisé la compression maximale pour
- sa distribution d'origine et qu'il la recompresse), c'est vraiment
- trop dommage. Comme il n'y a pas de bonne façon d'envoyer un nouveau
- .orig.tar.gz pour la même version, il n'y a même pas de raison de
- traiter cette situation comme un bogue.</p></footnote> Cela rend
- possible d'utiliser des vérifications de somme pour vérifier
- facilement que tous les changements entre la version Debian et celle
- de l'amont sont contenus dans le fichier diff Debian. Également, si
- le source amont est énorme, les auteurs amont et d'autres qui ont
- déjà l'archive tar amont peuvent économiser du temps de
- téléchargement s'ils veulent inspecter votre empaquetage en détail.
- </p>
- <p>
- Il n'y a pas de règles universellement acceptées suivies par les
- auteurs amont concernant la structure des répertoires dans leur
- archive tar, mais <prgn>dpkg-source</prgn> est cependant capable de
- traiter la plupart des archives tar comme source vierge. Sa stratégie
- est équivalente à la suivante :
- </p>
- <p>
- <enumlist numeration="arabic">
- <item>
- <p>
- Il décompacte l'archive tar dans un répertoire temporaire vide par
- <example>
-zcat chemin/vers/<nom-du-paquet>_<version-amont>.orig.tar.gz | tar xf -
- </example>
- </p>
- </item>
- <item>
- <p>
- Si, après cela, le répertoire temporaire ne contient qu'un
- répertoire et pas d'autres fichiers, <prgn>dpkg-source</prgn>
- renomme ce répertoire en
- <tt><packagename>-<version-amont>(.orig)</tt>. Le nom
- du répertoire de premier niveau dans l'archive tar n'a pas
- d'importance et est oublié.
- </p>
- </item>
- <item>
- <p>
- Sinon, l'archive tar a dû être empaqueté sans répertoire de
- premier niveau commun (honte à l'auteur amont !). Dans ce
- cas, <prgn>dpkg-source</prgn> renomme le répertoire temporaire
- <em>lui-même</em> en
- <tt><packagename>-<version-amont>(.orig)</tt>.
- </p>
- </item>
- </enumlist>
- </p>
- </sect2>
- <sect2 id="repackagedorigtargz">
- <heading>
- Réempaquetage des sources amont
- </heading>
- <p>
- Vous <strong>devriez</strong> envoyer des paquets sources avec une
- archive tar vierge si possible, mais il peut y avoir diverses raisons
- pour lesquelles cela n'est pas possible. C'est le cas si l'amont ne
- distribue pas le source comme un tar gzipé du tout ou si l'archive
- tar amont contient du matériel non libre au sens des DFSG que vous
- devez supprimer avant l'envoi.
- </p>
- <p>
- Dans tous ces cas, le développeur doit construire un fichier
- .orig.tar.gz convenable lui-même. Nous nous référerons à une telle
- archive tar comme un « source amont réempaqueté ». Notez
- qu'un « source amont réempaqueté » est différent d'un
- paquet natif Debian. Un source réempaqueté est toujours fourni avec
- des changements spécifiques Debian dans un fichier <tt>.diff.gz</tt>
- séparé et il a toujours un numéro de version composé de
- <tt><source-amont></tt> et de <tt><debian-revision></tt>.
- </p>
- <p>
- Il peut y avoir des cas où il est souhaitable de réempaqueter le
- source même si l'amont distribue un fichier <tt>.tar.gz</tt> qui
- pourrait en principe être utilisé dans sa forme vierge. Le plus
- évident est si des économies d'espaces <em>significatives</em>
- peuvent être réalisées en recompressant l'archive tar ou en
- supprimant des parties fondamentalement inutiles de l'archive
- source. Agissez à votre guise à cet endroit, mais soyez prêt à
- défendre votre décision si vous réempaquetez un source qui aurait pu
- être vierge.
- </p>
- <p>
- Un .orig.tar.gz réempaqueté :
- </p>
- <p>
- <enumlist numeration="arabic">
- <item>
- <p>
- <strong>doit</strong> contenir des informations détaillées sur la
- façon dont a été obtenu le source réempaqueté et comment cela peut
- être reproduit dans le fichier <file>README.Debian-source</file>
- ou un fichier similaire. Ce fichier devrait être dans la partie
- <file>diff.gz</file> du paquet source Debian, habituellement dans
- le répertoire <file>debian</file>, <em>pas</em> dans le
- <file>orig.tar.gz</file> réempaqueté. C'est également une bonne
- idée de fournir une cible <tt>get-orig-source</tt> dans votre
- fichier <file>debian/rules</file> qui répète le processus, comme
- décrit dans la Charte, <url
- id="&url-debian-policy;ch-source.html#s-debianrules"
- name="debian/rules, le principal script de construction">.
- </p>
- </item>
- <item>
- <p>
- <strong>ne devrait pas</strong> contenir de fichiers qui ne
- viennent pas de l'auteur amont ou dont vous avez changé le
- contenu. <footnote><p>Comme exception spéciale, si l'omission d'un
- fichier non libre devait entraîner l'échec de la compilation du
- source sans assistance du diff Debian, il peut être approprié au
- lieu de cela d'éditer les fichiers, en omettant seulement les
- parties non libres de ceux-ci et/ou d'expliquer la situation dans
- un fichier README.Debian-source à la racine de l'arborescence du
- source. Mais dans ce cas, veuillez également demander instamment à
- l'auteur amont de faciliter la séparation des composants non
- libres du reste du source.</p></footnote>
- </p>
- </item>
- <item>
- <p>
- <strong>devrait</strong>, sauf cas impossible pour des raisons
- légales, préserver l'infrastructure de construction entière et de
- portabilité fournie par l'auteur amont. Par exemple, ce n'est pas
- une raison suffisante pour omettre un fichier qui n'est utilisé
- que pour la construction sur MS-DOS. De manière similaire, un
- Makefile fourni par l'amont ne devrait pas être réécrit en
- exécutant un script configure.
- </p>
- <p>
- (<em>Explication :</em> il est courant que les utilisateurs
- Debian qui ont besoin de reconstruire un logiciel pour des
- plates-formes non-Debian récupèrent le source d'un miroir Debian
- plutôt que de chercher à localiser un point de distribution
- amont).
- </p>
- </item>
- <item>
- <p>
- <strong>devrait</strong> utiliser
- <tt><nom-du-paquet>-<version-amont>.orig</tt> comme
- nom du répertoire de premier niveau dans son archive tar. Cela
- rend possible la distinction entre des archives tar vierges
- d'archives réempaquetées.
- </p>
- </item>
- <item>
- <p>
- <strong>devrait</strong> être gzipé avec une compression maximale.
- </p>
- </item>
- </enumlist>
- </p>
- <p>
- La façon canonique de réaliser les deux derniers points est de
- laisser <tt>dpkg-source -b</tt> construire l'archive tar réempaquetée
- à partir du répertoire décompacté.
- </p>
- </sect2>
- <sect2 id="changed-binfiles">
- <heading>
- Changer des fichiers binaires dans le <tt>diff.gz</tt>
- </heading>
- <p>
- Il est parfois nécessaire de changer des fichiers binaires contenus
- dans l'archive tar d'origine ou d'ajouter des fichiers binaires qui
- ne sont pas dans celle-ci. Si cela est fait en copiant simplement les
- fichiers dans l'arborescence de l'archive debianisée,
- <prgn>dpkg-source</prgn> ne pourra pas gérer cela. D'un autre côté,
- selon les règles détaillées ci-dessus, vous ne pouvez pas inclure un
- tel fichier binaire modifié dans un fichier <file>orig.tar.gz</file>
- réempaqueté. Au lieu de cela, incluez le fichier dans le répertoire
- <file>debian</file> dans un format <prgn>uuencode</prgn> (ou
- semblable) <footnote><p>Le fichier devrait avoir un nom qui indique
- clairement quel fichier binaire il encode. Habituellement, un
- postfixe indiquant le codage devrait être ajouté au nom du fichier
- d'origine. Notez que vous n'avez pas besoin de dépendre de
- <package>sharutils</package> pour avoir le programme
- <prgn>uudecode</prgn> si vous utilisez la fonction <tt>pack</tt> de
- <prgn>perl</prgn>. Le code pourrait ressembler à ceci :
- <example>
-uuencode-file:
- perl -ne 'print(pack "u", $$_);' $(file) > $(file).uuencoded
-
-uudecode-file:
- perl -ne 'print(unpack "u", $$_);' $(file).uuencoded > $(file)
- </example>
- </p></footnote>. Le fichier sera ensuite décodé et copié à
- son emplacement pendant l'étape de construction. Le changement sera
- donc visible assez facilement.
- </p>
- <p>
- Certains paquets utilisent <prgn>dbs</prgn> pour gérer les correctifs
- à leur source amont et créent toujours un nouveau fichier
- <tt>orig.tar.gz</tt> contenant le vrai <tt>orig.tar.gz</tt> dans son
- répertoire de premier niveau. Cela est discutable concernant la
- préférence pour un source vierge. D'un autre côté, il est facile de
- modifier ou d'ajouter des fichiers binaires dans ce cas : placez
- les simplement dans le fichier <tt>orig.tar.gz</tt> nouvellement créé
- à côté du vrai et copiez les au bon endroit pendant l'étape de
- construction.
- </p>
- </sect2>
- </sect1>
- </sect>
- </chapt>
- <chapt id="beyond-pkging">
- <heading>
- Au-delà de l'empaquetage
- </heading>
- <p>
- Debian, c'est beaucoup plus que de l'empaquetage de logiciels et de la
- maintenance de paquets. Ce chapitre contient des informations sur les
- façons, souvent vraiment importantes, de contribuer à Debian au-delà de
- la simple création et maintenance de paquets.
- </p>
- <p>
- En tant qu'organisation de volontaires, Debian repose sur la liberté de
- choisir ce sur quoi l'on désire travailler et de choisir la partie la
- plus importante à laquelle on veut consacrer son temps.
- </p>
- <sect id="submit-bug">
- <heading>
- Rapporter des bogues
- </heading>
- <p>
- Nous vous encourageons à remplir des rapports de bogue quand vous
- trouvez des bogues dans les paquets Debian. En fait, les développeurs
- Debian sont souvent les testeurs de première ligne. Trouver et
- rapporter les bogues dans les paquets d'autres développeurs améliore la
- qualité de Debian.
- </p>
- <p>
- Lisez les <url id="&url-bts-report;" name="instructions pour créer un
- rapport de bogue"> dans le <url id="&url-bts;" name="système de suivi
- des bogues"> Debian.
- </p>
- <p>
- Essayez de soumettre le bogue à partir d'un compte utilisateur normal
- sur lequel vous pouvez recevoir des courriers, pour que les personnes
- puissent vous joindre s'ils ont besoin de plus d'informations à propos
- du bogue. Ne soumettez pas de bogues en tant que root.
- </p>
- <p>
- Vous pouvez utiliser un outil comme <manref section="1"
- name="reportbug"> pour soumettre des bogues. Il peut automatiser et
- dans l'ensemble faciliter le processus.
- </p>
- <p>
- Assurez-vous que le bogue n'a pas déjà été rapporté. Chaque paquet
- dispose d'une liste de bogues facilement accessible à
- <tt>http://&bugs-host;/<var>nom_paquet</var></tt>. Des outils comme
- <manref section="1" name="querybts"> peuvent également vous fournir ces
- informations (et <prgn>reportbug</prgn> invoquera également
- habituellement <prgn>querybts</prgn> avant l'envoi).
- </p>
- <p>
- Essayez d'envoyer vos bogues au bon emplacement. Quand, par exemple,
- votre bogue concerne un paquet qui réécrit des fichiers d'un autre
- paquet, vérifiez les listes des bogues pour les <em>deux</em> paquets
- pour éviter de créer des rapports de bogues dupliqués.
- </p>
- <p>
- Vous pouvez également parcourir les bogues d'autres paquets, en les
- regroupant s'ils sont indiqués plus d'une fois, ou en les marquant avec
- « fixed » quand ils ont déjà été corrigés. Notez cependant
- que si vous n'êtes ni le rapporteur du bogue, ni le responsable du
- paquet, vous ne devriez pas fermer réellement le bogue (à moins que
- vous n'ayez obtenu la permission du responsable).
- </p>
- <p>
- De temps en temps, vous pourrez vouloir vérifier ce qui s'est passé à
- propos des bogues que vous avez rapportés. Saisissez cette occasion
- pour fermer les bogues que vous ne pouvez plus reproduire. Pour trouver
- tous les bogues que vous avez rapportés, vous avez simplement besoin
- d'aller à
- <tt>http://&bugs-host;/from:<var><votre-adresse-de-courrier></var></tt>.
- </p>
- <sect1 id="submit-many-bugs">
- <heading>
- Ouvrir un grand nombre de rapports en une seule fois (« mass bug
- filing »)
- </heading>
- <p>
- Ouvrir un grand nombre de rapports pour le même problème sur un grand
- nombre de paquets — plus de dix — est une
- pratique que nous déconseillons. Prenez toutes les mesures possibles
- pour éviter cette situation. Si le problème peut être détecté
- automatiquement par exemple, ajoutez un nouveau test dans le paquet
- <package>lintian</package> pour générer une erreur ou un
- avertissement.
- </p>
- <p>
- Si vous ouvrez plus de dix rapports sur le même sujet, il est
- préférable d'indiquer votre intention sur la liste
- &email-debian-devel; et de mentionner le fait dans le sujet de votre
- message. Cela donnera à d'autres développeurs la possibilité de
- vérifier que le problème existe vraiment. De plus, cela permet
- d'éviter que plusieurs responsables ne rédigent les mêmes rapports de
- bogue simultanément.
- </p>
- <p>
- Veuillez utiliser les programmes <prgn>dd-list</prgn> et si nécessaire,
- <prgn>whodepends</prgn> (du paquet <package>devscripts</package>) pour
- générer une liste de tous les paquets concernés et incluez la sortie
- dans votre courrier à &email-debian-devel;.
- </p>
- <p>
- Quand vous envoyez un grand nombre de rapports sur le même sujet, vous
- devriez les envoyer à <email>maintonly@&bugs-host;</email> pour qu'ils
- ne soient pas redirigés vers les listes de diffusion.
- </p>
- </sect1>
- </sect>
- <sect id="qa-effort">
- <heading>
- Effort d'assurance qualité
- </heading>
- <sect1 id="qa-daily-work">
- <heading>
- Travail journalier
- </heading>
- <p>
- Bien qu'il y ait un groupe de personnes dédié à l'assurance qualité,
- les devoirs de QA ne leur sont pas exclusivement réservés. Vous pouvez
- participer à cet effort en conservant vos paquets aussi exempts de
- bogues que possible et aussi corrects que possible selon
- <prgn>lintian</prgn> (reportez-vous à <ref id="lintian">). Si cela
- vous paraît impossible, vous devriez alors envisager d'abandonner
- certains de vos paquets (reportez-vous à <ref id="orphaning">). Sinon,
- vous pouvez demander de l'aide à d'autres personnes pour qu'elles
- puissent rattraper votre retard dans la correction des bogues (vous
- pouvez demander de l'aide sur &email-debian-qa; ou
- &email-debian-devel;). En même temps, vous pouvez rechercher des
- co-responsables (reportez-vous à <ref id="collaborative-maint">).
- </p>
- </sect1>
- <sect1 id="qa-bsp">
- <heading>
- Les chasses aux bogues
- </heading>
- <p>
- De temps en temps, le groupe d'assurance qualité organise des chasses
- aux bogues<footnote><p><em>Bug Squashing Party</em></p></footnote>
- pour essayer de supprimer le plus de problèmes possible. Elles sont
- annoncées sur &email-debian-devel-announce; et l'annonce explique quel
- domaine sera visé pendant la chasse : habituellement, il s'agit
- des bogues empêchant l'intégration du paquet dans la distribution
- (« Release Critical »), mais il peut arriver qu'ils décident
- d'aider à finir une transition majeure (comme une nouvelle version de
- Perl qui demande la recompilation de tous les modules binaires).
- </p>
- <p>
- Les règles pour les mises à jour indépendantes sont différentes au
- cours de la chasse parce que l'annonce de la chasse est considérée
- comme une annonce préalable pour les mises à jour indépendantes. Si
- vous avez des paquets qui peuvent être affectées par la chasse (parce
- qu'ils ont des bogues critiques par exemple), vous devriez envoyer une
- mise à jour pour chaque bogue correspondant pour expliquer leur état
- actuel et ce que vous attendez de la chasse. Si vous ne voulez pas
- d'une mise à jour indépendante ou si vous n'êtes intéressé que par un
- correctif ou si vous voulez gérer vous-même le bogue, veuillez
- l'expliquer dans le BTS.
- </p>
- <p>
- Les personnes qui participent à la chasse ont des règles spécifiques
- pour les mises à jour indépendantes, ils peuvent en faire une sans
- avertissement préalable s'ils envoient leur paquet avec un délai d'au
- moins 3 jours dans DELAYED/3-day. Toutes les autres règles de mise à
- jour indépendante s'appliquent comme d'habitude ; ils devraient
- envoyer le correctif de la mise à jour dans le BTS (pour l'un des
- bogues ouverts corrigé par la mise à jour ou pour un nouveau bogue
- marqué comme fixé). Ils devraient également respecter tout souhait du
- responsable s'il en a exprimé.
- </p>
- <p>
- Si vous ne vous sentez pas à l'aise avec une mise à jour indépendante,
- envoyez simplement un correctif au BTS. C'est de loin meilleur qu'une
- mise à jour défectueuse.
- </p>
- </sect1>
- </sect>
- <sect id="contacting-maintainers">
- <heading>
- Contacter d'autres responsables
- </heading>
- <p>
- Pendant vos activités dans Debian, vous aurez à contacter d'autres
- responsables pour différentes raisons. Vous pourrez vouloir discuter
- d'une nouvelle façon de coopérer au sein d'un ensemble de paquets liés,
- ou vous pouvez simplement rappeler à quelqu'un qu'une nouvelle version
- est disponible et que vous en avez besoin.
- </p>
- <p>
- Chercher l'adresse d'un responsable d'un paquet peut être
- fastidieux. Heureusement, il existe un alias de courrier simple,
- <tt><paquet>@&packages-host;</tt>, qui fournit un moyen d'envoyer
- un courrier à un responsable, quelle que soit son adresse (ou ses
- adresses). Remplacez <tt><paquet></tt> par le nom du paquet
- source ou binaire.
- </p>
- <p>
- Vous pouvez également vouloir contacter les personnes qui sont
- inscrites à un paquet de source donné par le <ref
- id="pkg-tracking-system">. Vous pouvez le faire en utilisant l'adresse
- <tt><paquet>@&pts-host;</tt>.
- </p>
- </sect>
- <sect id="mia-qa">
- <heading>
- Gérer les responsables non joignables
- </heading>
- <p>
- Si vous remarquez qu'un paquet manque de maintenance, vous devriez vous
- assurer que le responsable est toujours actif et qu'il continue à
- travailler sur ses paquets. Il est possible qu'il ne soit plus actif,
- mais qu'il ne se soit pas désenregistré du système. D'un autre côté, il
- est possible qu'il ait simplement besoin d'un rappel.
- </p>
- <p>
- Il y a un système simple (la base de données MIA) dans laquelle les
- informations sur les responsables supposés Absents En Exercice
- (« Missing In Action) sont enregistrées. Quand un membre du groupe
- QA contacte un responsable inactif ou trouve plus d'informations sur
- celui-ci, c'est enregistré dans la base de données MIA. Ce système est
- disponible dans /org/qa.debian.org/mia sur l'hôte qa.debian.org et peut
- être interrogé avec un outil de nom <prgn>mia-query</prgn>.
- Utilisez <example>mia-query --help</example> pour voir comment interroger
- la base de données. Si vous déterminez qu'aucune
- information n'a encore été enregistrée pour un responsable inactif ou
- si vous voulez ajouter plus d'informations, vous deviez utiliser la
- procédure suivante.
- </p>
- <p>
- La première étape est de contacter poliment le responsable et
- d'attendre une réponse pendant un temps raisonnable. Il est assez
- difficile de définir le « temps raisonnable », mais il est
- important de prendre en compte que la vraie vie est parfois assez
- mouvementée. Une façon de gérer cela pourrait être d'envoyer un rappel
- après deux semaines.
- </p>
- <p>
- Si le responsable ne répond pas après quatre semaines (un mois), on
- peut supposer qu'il n'y aura probablement pas de réponse. Si ceci se
- produit, vous devriez poursuivre vos investigations et essayer de
- réunir toutes les informations utiles sur ce responsable. Ceci
- inclut :
- </p>
- <p>
- <list>
- <item>
- <p>
- Les informations « echelon » disponibles dans la <url
- id="&url-debian-db;" name="base de données LDAP des développeurs">,
- qui indiquent quand le développeur a envoyé un message pour la
- dernière fois sur une liste de diffusion Debian (cela inclut les
- envois via les listes debian-*-changes). Rappelez-vous également de
- vérifier si le responsable est indiqué comme en vacances dans la
- base de données.
- </p>
- </item>
- <item>
- <p>
- Le nombre de paquets de ce responsable et les conditions de ces
- paquets. En particulier, reste-t-il des bogues empêchant
- l'intégration du paquet dans la distribution qui sont ouverts depuis
- des lustres ? De plus, combien de bogues y a-t-il en
- général ? Un autre point d'information important est si les
- paquets ont subi des mises à jour indépendantes et si oui, par qui.
- </p>
- </item>
- <item>
- <p>
- Est-ce que le responsable est actif en dehors de Debian ? Par
- exemple, il peut avoir envoyé des messages récemment à des listes de
- diffusion non-Debian ou des groupes de discussion.
- </p>
- </item>
- </list>
- </p>
- <p>
- Un problème particulier est représenté par les paquets parrainés
- — le responsable n'est pas un développeur Debian
- officiel. Les informations « echelon » ne sont pas
- disponibles pour les personnes parrainées, par exemple, vous devez donc
- trouver et contacter le responsable Debian qui a réellement envoyé le
- paquet. Étant donné qu'il a signé le paquet, il est responsable de
- l'envoi de toute façon et il est probable qu'il sait ce qui s'est passé
- avec la personne qu'il parraine.
- </p>
- <p>
- Il est également permis d'envoyer une demande à &email-debian-devel;
- demandant si quelqu'un est au courant d'information sur le responsable
- manquant. Veuillez mettre en CC: la personne en question.
- </p>
- <p>
- Une fois que vous avez réuni toutes ces informations, vous pouvez
- contacter &email-mia;. Les personnes de cet alias utiliseront les
- informations que vous aurez fournies pour décider comment procéder. Par
- exemple, ils peuvent abandonner un ou tous les paquets du
- responsable. Si un paquet a subi une mise à jour indépendante, ils
- peuvent préférer contacter le responsable ayant fait cette mise à jour
- — il est peut-être intéressé par le paquet.
- </p>
- <p>
- Un dernier mot : veuillez vous souvenir d'être poli. Nous sommes
- tous des volontaires et nous ne pouvons dédier l'intégralité de notre
- temps à Debian. Vous n'êtes pas non plus au courant des circonstances
- de la personne impliquée. Elle est peut-être sérieusement malade ou
- pourrait même nous avoir quitté — vous ne savez pas qui
- recevra vos courriers. Imaginez comme un proche se sentira s'il lit un
- courrier pour la personne décédée et trouve un message très impoli, en
- colère et accusateur !
- </p>
- <p>
- D'un autre côté, bien que nous soyons tous volontaires, nous avons une
- responsabilité. Vous pouvez donc insister sur l'importance du plus
- grand intérêt — si un responsable n'a plus le temps ou
- l'envie, il devrait « laisser filer » et donner le paquet à
- quelqu'un ayant plus de temps.
- </p>
- <p>
- Si vous êtes intéressé pour travailler dans l'équipe MIA, veuillez
- étudier le fichier README dans /org/qa.debian.org/mia sur qa.debian.org
- où les détails techniques et les procédures MIA sont documentées et
- contactez &email-mia;.
- </p>
- </sect>
- <sect id="newmaint">
- <heading>
- Interagir avec de futurs développeurs Debian
- </heading>
- <p>
- Le succès de Debian dépend de sa capacité à attirer et retenir de
- nouveaux et talentueux volontaires. Si vous êtes un développeur
- expérimenté, nous vous recommandons de vous impliquer dans le processus
- d'apport des nouveaux responsables. Cette section décrit comment aider
- les futurs développeurs.
- </p>
- <sect1 id="sponsoring">
- <heading>
- Parrainer des paquets
- </heading>
- <p>
- Parrainer un paquet veut dire envoyer un paquet pour un responsable
- qui n'est pas encore autorisé à le faire lui-même, un candidat nouveau
- responsable. Parrainer un paquet veut aussi dire que vous en acceptez
- la responsabilité.
- </p>
- <p>
- Les nouveaux responsables ont habituellement certaines difficultés à
- créer des paquets Debian — ceci est bien
- compréhensible. C'est pourquoi le parrain est là pour vérifier que le
- paquet parrainé est assez bon pour être inclus dans Debian. (Notez que
- si le paquet parrainé est nouveau, les ftpmasters devront également
- l'inspecter avant de l'intégrer)
- </p>
- <p>
- Effectuer un parrainage en signant simplement l'envoi ou en
- recompilant le paquet <strong>n'est définitivement pas
- recommandé</strong>. Vous devez construire le paquet source comme si
- vous vouliez construire l'un de vos paquets. Rappelez-vous que cela ne
- change rien si vous avez laissé le nom du candidat développeur dans le
- changelog et dans le fichier de contrôle, il est toujours possible de
- savoir que c'est vous qui avez fait l'envoi.
- </p>
- <p>
- Si vous êtes un gestionnaire de candidature pour un futur développeur,
- vous pouvez également être son parrain. Ainsi, vous pourrez vérifier
- comment le candidat gère la partie « Tâches et
- Capacités »<footnote><p>Tasks and Skills</p></footnote> de sa
- candidature.
- </p>
- </sect1>
- <sect1>
- <heading>
- Gérer les paquets parrainés
- </heading>
- <p>
- En envoyant un paquet sponsorisé vers Debian, vous certifiez que le
- paquet atteint les standards minimum de Debian. Ceci implique que vous
- devez construire et tester le paquet sur votre propre système avant
- l'envoi.
- </p>
- <p>
- Vous ne pouvez pas simplement envoyer un fichier <file>.deb</file>
- binaire d'un filleul. En théorie, vous devriez seulement demander le
- fichier diff et l'emplacement de l'archive source d'origine et ensuite
- vous devriez récupérer le source et appliquer le diff vous-même. En
- pratique, vous pouvez vouloir utiliser le paquet source construit par
- votre filleul. Dans ce cas, vous devez vérifier qu'il n'a pas modifié
- les fichiers sources du fichier <file>.orig.tar.gz</file> qu'il
- fournit.
- </p>
- <p>
- N'ayez pas peur de répondre au filleul et de lui indiquer les
- changements qu'il doit faire. Cela prend souvent plusieurs échanges de
- courriers avant que le paquet ne soit dans un état acceptable. Être un
- parrain veut dire être un mentor.
- </p>
- <p>
- Une fois que le paquet a atteint les standards Debian, construisez et
- signez le paquet avec
- <example>dpkg-buildpackage -k<var>KEY-ID</var></example>
- avant de l'envoyer dans le répertoire incoming. Bien sûr, vous pouvez
- également utiliser toute partie de votre <var>KEY-ID</var>, tant
- qu'elle est unique dans votre porte-clés secret.
- </p>
- <p>
- Le champ Maintainer du fichier <file>control</file> et le fichier
- <file>changelog</file> devraient afficher la personne qui a fait
- l'empaquetage, c'est-à-dire, le filleul. Celui-ci recevra donc tous
- les courriers du système de suivi des bogues (BTS) à propos de son
- paquet.
- </p>
- <p>
- Si vous préférez laisser une trace plus visible de votre travail de
- parrainage, vous pouvez ajouter une ligne l'indiquant dans la plus
- récente entrée du changelog.
- </p>
- <p>
- Vous êtes encouragé à garder un œil sur le suivi des paquets que
- vous parrainez en utilisant le <ref id="pkg-tracking-system">.
- </p>
- </sect1>
- <sect1>
- <heading>
- Recommander un nouveau développeur
- </heading>
- <p>
- Reportez-vous à la page sur les <url id="&url-newmaint-advocate;"
- name="recommandations pour un développeur prospectif"> sur le site web
- Debian.
- </p>
- </sect1>
- <sect1>
- <heading>
- Gérer les candidatures des nouveaux candidats
- </heading>
- <p>
- Veuillez vous reporter à la <url id="&url-newmaint-amchecklist;"
- name="liste à vérifier pour les responsables de candidatures"> sur le
- site web Debian.
- </p>
- </sect1>
- </sect>
- </chapt>
- <chapt id="l10n">
- <heading>
- Internationalisation, traduction, être internationalisé et être traduit
- </heading>
- <p>
- Debian prend en charge un nombre toujours croissant de langues
- naturelles. Même si l'anglais est votre langue maternelle et que vous ne
- parlez pas d'autre langue, il est de votre devoir de responsable d'être
- conscient des problèmes d'internationalisation (abrégé en i18n à cause
- des 18 lettres entre le i et le n dans internationalisation). C'est
- pourquoi, même si des programmes seulement en anglais vous suffisent,
- vous devriez lire la plupart de ce chapitre.
- </p>
- <p>
- Selon l'<url id="http://www.debian.org/doc/manuals/intro-i18n/"
- name="introduction à l'i18n"> de Tomohiro KUBOTA, « I18N
- (internationalisation) veut dire la modification d'un logiciel ou de
- technologies liées pour qu'un logiciel puisse potentiellement gérer des
- langues multiples, des conventions multiples et ainsi de suite dans le
- monde entier » alors que « L10N (localisation) veut dire
- l'implémentation dans une langue spécifique pour un logiciel déjà
- internationalisé ».
- </p>
- <p>
- La l10n et l'i18n sont interconnectées, mais les difficultés liées à
- chacune sont très différentes. Il n'est pas vraiment difficile de
- permettre à un programme de changer la langue dans laquelle sont
- affichés les textes selon les paramètres de l'utilisateur, mais il est
- très coûteux en temps de traduire réellement ces messages. D'un autre
- côté, définir le codage des caractères est trivial, mais adapter le code
- pour utiliser des codages de caractères différents est un problème
- vraiment difficile.
- </p>
- <p>
- En laissant de côté les problèmes d'i18n pour lesquels il n'existe pas
- de règle générale, il n'y a pas actuellement d'infrastructure
- centralisée pour la l10n dans Debian qui puisse être comparée au
- mécanisme dbuild pour le portage. Le plus gros du travail doit donc être
- réalisé manuellement.
- </p>
- <sect id="l10n-handling">
- <heading>
- Comment sont gérées les traductions au sein de Debian
- </heading>
- <p>
- La gestion des traductions des textes contenus dans un paquet est
- encore une tâche manuelle et le processus dépend du type de texte que
- vous désirez voir traduit.
- </p>
- <p>
- Pour les messages des programmes, l'infrastructure gettext est utilisée
- pour la plupart d'entre eux. La plupart du temps, la traduction est
- gérée en amont dans des projets comme le <url
- id="http://www.iro.umontreal.ca/contrib/po/HTML/" name="projet de
- traduction libre">, le <url
- id="http://developer.gnome.org/projects/gtp/" name="projet de
- traduction de Gnome"> ou <url id="http://i18n.kde.org/" name="celui de
- KDE">. La seule ressource centralisée dans Debian est les <url
- id="http://www.debian.org/intl/l10n/" name="statistiques de traduction
- Debian centralisées"> où vous pouvez trouver des statistiques sur les
- fichiers de traduction trouvés dans les paquets, mais il n'y a aucune
- infrastructure pour faciliter le processus de traduction.
- </p>
- <p>
- Un effort pour traduire les descriptions de paquet a démarré il y a
- longtemps, même si les outils fournissent très peu de prise en charge
- pour les utiliser vraiment (i.e., seul APT peut les utiliser quand il
- est configuré convenablement). Les responsables n'ont rien à faire de
- particulier pour gérer les traductions des descriptions de
- paquets ; les traducteurs devraient utiliser le <url
- id="http://ddtp.debian.org/" name="DDTP">.
- </p>
- <p>
- Pour les questionnaires debconf, les responsable devraient utiliser le
- paquet po-debconf pour faciliter le travail des traducteurs, qui
- peuvent utiliser le DDTP pour faire leur travail (mais les équipes
- française et brésilienne ne le font pas). On peut trouver certaines
- statistiques à la fois sur le site du DDTP (à propos de ce qui est
- vraiment traduit) et sur le site des <url
- id="http://www.debian.org/intl/l10n/" name="statistiques de traduction
- Debian centralisées"> (à propos de ce qui est intégré dans les
- paquets).
- </p>
- <p>
- Pour les pages web, chaque équipe l10n a accès au CVS correspondant et
- les statistiques sont disponibles sur le site des statistiques de
- traduction Debian centralisées.
- </p>
- <p>
- Pour la documentation générale à propos de Debian, le processus est
- plus ou moins le même que pour les pages web (les traducteurs ont accès
- au CVS), mais il n'y a pas de page de statistiques.
- </p>
- <p>
- Pour la documentation spécifique aux paquets (pages de manuel,
- documents info, autres formats), presque tout est encore à faire.
- </p>
- <p>
- Le plus notablement, le projet KDE gère la traduction de ses
- documentations de la même façon que ses messages de programme.
- </p>
- <p>
- Il existe un effort pour gérer les pages de manuel spécifiques Debian
- au sein d'un <url
- id="http://cvs.debian.org/manpages/?cvsroot=debian-doc" name="dépôt CVS
- spécifique">.
- </p>
- </sect>
- <sect id="l10n-faqm">
- <heading>
- FAQ I18N & L10N pour les responsables
- </heading>
- <p>
- Voici une liste des problèmes que les responsables peuvent rencontrer
- concernant l'i18n et la l10n. Lorsque vous lirez cela, gardez à
- l'esprit qu'il n'y a pas de consensus sur ces points au sein de Debian
- et que ce ne sont que des conseils. Si vous avez une meilleure idée
- pour un problème donné ou si vous êtes en désaccord avec certains
- points, vous êtes libre de fournir vos impressions pour que ce document
- puisse être amélioré.
- </p>
- <sect1 id="l10n-faqm-tr">
- <heading>
- Comment faire en sorte qu'un texte soit traduit
- </heading>
- <p>
- Pour traduire des descriptions de paquet ou des questionnaires
- debconf, vous n'avez rien à faire, l'infrastructure du DDTP répartira
- le matériel à traduire aux volontaires sans besoin d'interaction de
- votre part.
- </p>
- <p>
- Pour tous les autres matériels (fichiers gettext, pages de manuel ou
- autre documentation), la meilleure solution est de placer votre texte
- quelque part sur l'Internet et de demander sur debian-i18n la
- traduction dans différentes langues. Certains membres des équipes de
- traduction sont abonnés à cette liste et ils prendront soin de la
- traduction et du processus de relecture. Une fois qu'ils ont fini,
- vous recevrez de leur part votre document traduit dans votre boîte aux
- lettres.
- </p>
- </sect1>
- <sect1 id="l10n-faqm-rev">
- <heading>
- Comment faire en sorte qu'une traduction donnée soit relue
- </heading>
- <p>
- De temps en temps, des personnes indépendantes traduiront certains
- textes inclus dans votre paquet et vous demanderont d'inclure la
- traduction dans le paquet. Cela peut devenir problématique si vous
- n'êtes pas familier avec la langue donnée. C'est une bonne idée
- d'envoyer le document à la liste de diffusion l10n correspondante en
- demandant une relecture. Une fois celle-ci faite, vous devriez avoir
- plus confiance dans la qualité de la traduction et l'inclure sans
- crainte dans votre paquet.
- </p>
- </sect1>
- <sect1 id="l10n-faqm-update">
- <heading>
- Comment faire en sorte qu'une traduction donnée soit mise à jour
- </heading>
- <p>
- Si vous avez certaines traductions d'un texte donné qui traînent,
- chaque fois que vous mettez à jour l'original, vous devriez demander
- au précédent traducteur de mettre à jour sa traduction avec vos
- nouveaux changements. Gardez à l'esprit que cette tâche demande du
- temps ; au moins une semaine pour obtenir une mise à jour relue.
- </p>
- <p>
- Si votre traducteur ne répond pas, vous pouvez demander de l'aide sur
- la liste de diffusion correspondante. Si tout échoue, n'oubliez pas de
- mettre un avertissement dans le document traduit, indiquant que la
- traduction est un peu obsolète et que le lecteur devrait se référer au
- document d'origine si possible.
- </p>
- <p>
- Évitez de supprimer complètement une traduction à cause de son
- obsolescence. Un vieux document est souvent mieux que pas de
- documentation du tout pour les personnes non anglophones.
- </p>
- </sect1>
- <sect1 id="l10n-faqm-bug">
- <heading>
- Comment gérer un rapport de bogue concernant une traduction
- </heading>
- <p>
- La meilleure solution peut être de marquer le bogue comme « suivi
- au développeur amont » (<em>forwarded to upstream</em>) et de
- faire suivre le bogue à la fois au précédent traducteur et à son
- équipe (en utilisant la liste de diffusion debian-l10n-XXX
- correspondante).
- </p>
- </sect1>
- </sect>
- <sect id="l10n-faqtr">
- <heading>
- FAQ I18N & L10N pour les traducteurs
- </heading>
- <p>
- Lorsque vous lirez cela, gardez à l'esprit qu'il n'y a pas de procédure
- générale dans Debian concernant ces points et que, dans tous les cas,
- vous devriez collaborer avec votre équipe et les responsables des
- paquets.
- </p>
- <sect1 id="l10n-faqtr-help">
- <heading>
- Comment aider l'effort de traduction
- </heading>
- <p>
- Choisissez ce que vous désirez traduire, assurez-vous que personne ne
- travaille déjà dessus (en utilisant votre liste de diffusion
- debian-l10n-XXX), traduisez-le, faites-le relire par d'autres
- personnes dont c'est également la langue maternelle sur votre liste de
- diffusion l10n et fournissez-le au responsable du paquet (voir le
- point suivant).
- </p>
- </sect1>
- <sect1 id="l10n-faqtr-inc">
- <heading>
- Comment fournir une traduction pour inclusion dans un paquet
- </heading>
- <p>
- Assurez-vous que votre traduction est correcte (en demandant une
- relecture sur votre liste de discussion l10n) avant de la fournir pour
- inclusion. Cela gagnera du temps à tout le monde et évitera le chaos
- qui résulterait d'avoir plusieurs versions du même document dans les
- rapports de bogue.
- </p>
- <p>
- La meilleure solution est de créer un rapport de bogue standard
- contenant la traduction sur le paquet. Assurez-vous d'utiliser
- l'étiquette « patch » et n'utilisez pas une gravité
- supérieure à « wishlist » car l'absence de traduction n'a
- jamais empêché un programme de fonctionner.
- </p>
- </sect1>
- </sect>
- <sect id="l10n-best">
- <heading>
- Meilleures pratiques actuelles concernant la l10n
- </heading>
- <p>
- <list>
- <item>
- <p>
- En tant que responsable, ne modifiez jamais les traductions en
- aucune façon (même pour reformater l'affichage) sans demander à la
- liste de diffusion l10n correspondante. Vous risquez, par exemple,
- de casser le codage du fichier en agissant ainsi. De plus, ce que
- vous considérez comme une erreur peut être correct (ou même
- nécessaire) pour une langue donnée.
- </p>
- </item>
- <item>
- <p>
- En tant que traducteur, si vous trouvez une erreur dans le texte
- d'origine, assurez-vous de l'indiquer. Les traducteurs sont souvent
- les lecteurs les plus attentifs d'un texte donné et s'ils ne rendent
- pas compte des erreurs qu'ils trouvent, personne ne le fera.
- </p>
- </item>
- <item>
- <p>
- Dans tous les cas, rappelez-vous que le problème principal avec la
- l10n est qu'elle demande la coopération de plusieurs personnes et
- qu'il est très facile de démarrer une guerre incendiaire à propos de
- petits problèmes dûs à des incompréhensions. Donc, si vous avez des
- problèmes avec votre interlocuteur, demandez de l'aide sur la liste
- de diffusion l10n correspondante, sur debian-i18n ou même sur
- debian-devel (attention, cependant, les discussions sur la l10n
- tournent très souvent à l'incendie sur cette liste :)
- </p>
- </item>
- <item>
- <p>
- Dans tous les cas, la coopération ne peut être atteinte qu'avec un
- <strong>respect mutuel</strong>.
- </p>
- </item>
- </list>
- </p>
- </sect>
- </chapt>
- <appendix id="tools">
- <heading>
- Aperçu des outils du responsable Debian
- </heading>
- <p>
- Cette section contient un aperçu rapide des outils dont dispose le
- responsable. Cette liste n'est ni complète, ni définitive, il s'agit
- juste d'un guide des outils les plus utilisés.
- </p>
- <p>
- Les outils du responsable Debian sont destinés à aider les responsables
- et libérer leur temps pour des tâches plus cruciales. Comme le dit Larry
- Wall, il y a plus d'une manière de le faire.
- </p>
- <p>
- Certaines personnes préfèrent utiliser des outils de haut niveau,
- d'autres pas. Debian n'a pas de position officielle sur la
- question ; tout outil conviendra du moment qu'il fait le
- boulot. C'est pourquoi cette section n'a pas été conçue pour indiquer à
- chacun quel outil il doit utiliser ou comment il devrait faire pour
- gérer sa charge de responsable Debian. Elle n'est pas non plus destinée
- à favoriser l'utilisation d'un outil aux dépens d'un autre.
- </p>
- <p>
- La plupart des descriptions de ces outils proviennent des descriptions
- de leurs paquets. Vous trouverez plus d'informations dans les
- documentations de ces paquets. Vous pouvez aussi obtenir plus
- d'informations avec la commande <tt>apt-cache show
- <nom_paquet></tt>.
- </p>
- <sect id="tools-core">
- <heading>
- Outils de base
- </heading>
- <p>
- Les outils suivants sont pratiquement nécessaires à tout responsable.
- </p>
- <sect1 id="dpkg-dev">
- <heading>
- <package>dpkg-dev</package>
- </heading>
- <p>
- Le paquet <package>dpkg-dev</package> contient les outils (y compris
- <prgn>dpkg-source</prgn>) nécessaires pour déballer, fabriquer et
- livrer des paquets Debian source. Ces utilitaires fournissent les
- fonctionnalités de bas niveau indispensables pour créer et manipuler
- les paquets ; en tant que tels, ils sont essentiels à tout
- responsable Debian.
- </p>
- </sect1>
- <sect1 id="debconf">
- <heading>
- <package>debconf</package>
- </heading>
- <p>
- Le paquet <package>debconf</package> fournit une interface unifiée
- pour configurer les paquets interactivement. Il est indépendant de
- l'interface et permet une configuration en mode texte, par une
- interface HTML ou par boîtes de dialogue. D'autres types d'interface
- peuvent être ajoutés sous forme de modules.
- </p>
- <p>
- Vous trouverez la documentation de ce paquet dans le paquet
- <package>debconf-doc</package>.
- </p>
- <p>
- Beaucoup pensent que ce système devrait être utilisé pour tout paquet
- nécessitant une configuration interactive ; reportez-vous à la
- <ref id="bpp-config-mgmt">. <package>debconf</package> n'est pas
- requis par la <em>charte Debian</em> pour le moment ; cependant,
- cela pourra changer.
- </p>
- </sect1>
- <sect1 id="fakeroot">
- <heading>
- <package>fakeroot</package>
- </heading>
- <p>
- <package>fakeroot</package> simule les privilèges <em>root</em>. Cela
- permet de fabriquer un paquet sans être root (en général, les paquets
- installent des fichiers appartenant à <em>root</em>). Si vous avez
- installé <package>fakeroot</package>, vous pouvez construire un paquet
- en tant que simple utilisateur avec : <tt>dpkg-buildpackage
- -rfakeroot</tt>.
- </p>
- </sect1>
- </sect>
- <sect id="tools-lint">
- <heading>
- Outils du paquet lint
- </heading>
- <p>
- Selon le « Free On-line Dictionary of Computing » (FOLDOC),
- « lint » est « un outil de traitement de langage C qui
- contient beaucoup plus de tests complets sur le code que n'en font
- habituellement les compilateurs C. ». Les outils du paquet lint
- aide les responsables de paquet à trouver automatiquement des problèmes
- habituels et des violations de charte dans leurs paquets
- </p>
- <sect1 id="lintian">
- <heading>
- <package>lintian</package>
- </heading>
- <p>
- <package>lintian</package> dissèque les paquets pour y repérer des
- bogues et des manquements aux règles de développement. Il contient des
- tests automatisés pour vérifier de nombreuses règles et quelques
- erreurs courantes.
- </p>
- <p>
- Vous devriez récupérer la dernière version de
- <package>lintian</package> depuis <em>unstable</em> régulièrement et
- vérifier tous vos paquets. Notez que l'option <tt>-i</tt> donne des
- explications détaillées sur la signification de chaque erreur, la
- partie concernée dans la charte et le moyen habituel de régler le
- problème.
- </p>
- <p>
- Veuillez vous reporter à <ref id="sanitycheck"> pour plus
- d'informations sur comment et quand utiliser Lintian.
- </p>
- <p>
- Vous pouvez aussi obtenir un résumé de tous les problèmes reportés par
- Lintian sur vos paquets à <url id="&url-lintian;">. Ces rapports
- contiennent la sortie de la dernière version de <prgn>lintian</prgn>
- pour l'ensemble de la distribution de développement
- (<em>unstable</em>).
- </p>
- </sect1>
- <sect1 id="linda">
- <heading>
- <package>linda</package>
- </heading>
- <p>
- <package>linda</package> est un autre vérificateur de paquet. Il est
- semblable à <package>lintian</package>, mais il a un ensemble de tests
- différents. Il est écrit en Python plutôt qu'en Perl.
- </p>
- </sect1>
- <sect1 id="debdiff">
- <heading>
- <package>debdiff</package>
- </heading>
- <p>
- <prgn>debdiff</prgn> (du paquet <package>devscripts</package>, <ref
- id="devscripts">) compare des listes de fichiers et des fichiers de
- contrôle de deux paquets. C'est un simple test de régression qui peut
- vous aider à remarquer si le nombre de paquets binaires a changé
- depuis le dernier envoi ou si autre chose a changé dans le fichier de
- contrôle. Bien sûr, certains des changements qu'il indique sont
- normaux, mais il peut aider à empêcher différents accidents.
- </p>
- <p>
- Vous pouvez l'exécuter sur un couple de paquets binaires :
- <example>
-debdiff package_1-1_arch.deb package_2-1_arch.deb
-</example>
- </p>
- <p>
- Ou même sur un couple de fichiers de changements :
- <example>
-debdiff package_1-1_arch.changes package_2-1_arch.changes
-</example>
- </p>
- <p>
- Pour plus d'informations, veuillez voir <manref section="1"
- name="debdiff">.
- </p>
- </sect1>
- </sect>
- <sect id="tools-helpers">
- <heading>
- Aides pour le fichier <file>debian/rules</file>
- </heading>
- <p>
- Des outils de construction de paquets rendent le processus d'écriture
- du fichier <file>debian/rules</file> plus facile. Veuillez voir les
- <ref id="helper-scripts"> pour plus d'informations sur les raisons pour
- lesquelles ils peuvent être désirables ou non.
- </p>
- <sect1 id="debhelper">
- <heading>
- <package>debhelper</package>
- </heading>
- <p>
- Le paquet <package>debhelper</package> regroupe un ensemble de
- programmes qui peuvent être utilisés dans <file>debian/rules</file>
- pour automatiser les tâches courantes relatives à la fabrication des
- paquets Debian binaires. <package>debhelper</package> inclut des
- programmes pour installer différents fichiers, les compresser, ajuster
- leurs droits et intégrer votre paquet dans le système de menu Debian.
- </p>
- <p>
- À la différence d'autres approches, <package>debhelper</package> est
- divisé en plusieurs petits utilitaires simples qui agissent de manière
- cohérente. Ce découpage permet un contrôle des opérations plus fin que
- certains des autres « <em>outils debian/rules</em> ».
- </p>
- <p>
- Il existe aussi un certain nombre de petites extensions
- <package>debhelper</package> trop éphémères pour être
- documentées. Vous en listerez la plupart en faisant <tt>apt-cache
- search ^dh-</tt>.
- </p>
- </sect1>
- <sect1 id="debmake">
- <heading>
- <package>debmake</package>
- </heading>
- <p>
- <package>debmake</package> — un précurseur de
- <package>debhelper</package> — est un assistant moins modulaire
- pour manipuler le fichier <file>debian/rules</file>. Il inclut deux
- programmes principaux : <prgn>deb-make</prgn>, utile au
- développeur Debian pour convertir un paquet source normal (non-Debian)
- en paquet source Debian, et <prgn>debstd</prgn> qui regroupe le type
- de fonction que l'on trouve dans <package>debhelper</package>.
- </p>
- <p>
- Le consensus actuel est que l'utilisation de
- <package>debmake</package> est déconseillée au profit de
- <package>debhelper</package>. C'est un bogue d'utiliser
- <package>debmake</package> pour les nouveaux paquets. Les nouveaux
- paquets utilisant <package>debmake</package> seront rejetés de
- l'archive.
- </p>
- </sect1>
- <sect1 id="dh-make">
- <heading>
- <package>dh-make</package>
- </heading>
- <p>
- Le paquet <package>dh-make</package> contient <prgn>dh_make</prgn>, un
- programme qui crée un squelette de fichiers nécessaires à la
- construction d'un paquet Debian à partir d'une arborescence
- source. Comme le nom le suggère, <prgn>dh_make</prgn> est une
- réécriture de <package>debmake</package> et ses fichiers modèles
- utilisent les programmes dh_* de <package>debhelper</package>.
- </p>
- <p>
- Quoique les fichiers de règles fabriqués par <prgn>dh_make</prgn>
- constituent en général une base suffisante pour un paquet fonctionnel,
- ce ne sont que les fondations : la charge incombe toujours au
- responsable d'affiner les fichiers générés et de rendre le paquet
- complètement fonctionnel et en conformité avec la charte.
- </p>
- </sect1>
- <sect1 id="yada">
- <heading>
- <package>yada</package>
- </heading>
- <p>
- Le paquet <package>yada</package> est un autre assistant pour la
- création de paquets. Il utilise un fichier
- <file>debian/packages</file> pour générer <file>debian/rules</file> et
- d'autres fichiers nécessaires dans le sous-répertoire
- <file>debian/</file>. Le fichier <file>debian/packages</file> contient
- des instructions pour construire les paquets et il n'y a pas besoin de
- créer de fichiers <file>Makefile</file>. Il existe la possibilité
- d'utiliser un moteur de macros semblable à celui utilisé dans les
- fichiers SPECS des paquets source RPM.
- </p>
- <p>
- Pour plus d'informations, voir le <tt><url
- id="http://yada.alioth.debian.org/" name="site de YADA"></tt>.
- </p>
- </sect1>
- <sect1 id="equivs">
- <heading>
- <package>equivs</package>
- </heading>
- <p>
- <package>equivs</package> est un autre paquet pour faire des
- paquets. Il est souvent conseillé pour un usage local, si vous avez
- besoin de faire un paquet pour satisfaire des dépendances. Il est
- aussi parfois utilisé pour faire des « méta-paquets » qui
- sont des paquets dont l'unique objet est de dépendre d'autres paquets.
- </p>
- </sect1>
- </sect>
- <sect id="tools-builders">
- <heading>
- Constructeurs de paquets
- </heading>
- <p>
- Les paquets suivants aident le processus de construction des paquets,
- en général en contrôlant <prgn>dpkg-buildpackage</prgn> ainsi que la
- gestion du support de tâches.
- </p>
- <sect1 id="cvs-buildpackage">
- <heading>
- <package>cvs-buildpackage</package>
- </heading>
- <p>
- Le paquet <package>cvs-buildpackage</package> permet de mettre à jour
- ou de récupérer des paquets sources dans un référentiel CVS, il permet
- de fabriquer un paquet Debian depuis le référentiel CVS et il assiste
- le développeur lors de l'intégration de modifications amont dans le
- référentiel.
- </p>
- <p>
- Ce paquet fournit l'infrastructure facilitant l'utilisation de CVS
- pour le responsable Debian. Il permet de conserver des branches CVS
- distinctes pour les distributions <em>stable</em>, <em>unstable</em>
- et probablement <em>experimental</em> et de bénéficier des avantages
- d'un système de contrôle de version.
- </p>
- </sect1>
- <sect1 id="debootstrap">
- <heading>
- <package>debootstrap</package>
- </heading>
- <p>
- Le paquet <package>debootstrap</package> vous permet d'amorcer un
- système Debian de base à n'importe quel endroit dans votre système de
- fichiers. Par « système de base », nous entendons le strict
- minimum nécessaire pour fonctionner et installer le reste du système.
- </p>
- <p>
- Avoir un système comme celui-ci peut vous servir de différentes
- manières. Vous pouvez, par exemple, déplacer votre racine dans ce
- système avec <prgn>chroot</prgn> pour tester vos dépendances de
- construction. Vous pouvez aussi l'utiliser pour voir comment se
- comporte votre paquet quand il est installé dans un environnement
- minimum.
- </p>
- </sect1>
- <sect1 id="pbuilder">
- <heading>
- <package>pbuilder</package>
- </heading>
- <p>
- <package>pbuilder</package> construit un système « chrooté »
- et compile des paquets dans ce système. Ceci est très utile pour
- vérifier que les dépendances de compilation de votre paquet sont
- correctes et pour vous assurer qu'aucune dépendance de construction
- inutile ou incorrecte n'existe dans le paquet résultant.
- </p>
- <p>
- Un paquet lié est <package>pbuilder-uml</package>, qui va même plus
- loin en réalisant la construction au sein d'un environnement
- « User Mode Linux ».
- </p>
- </sect1>
- <sect1 id="sbuild">
- <heading>
- <package>sbuild</package>
- </heading>
- <p>
- <package>sbuild</package> est un autre compilateur automatique. Il
- peut aussi être utilisé dans un environnement
- « chrooté ». Il peut être utilisé seul ou comme partie d'un
- environnement de compilation distribué en réseau. Comme le précédent,
- c'est une partie du système utilisé par les porteurs pour construire
- des paquets binaires pour toutes les architectures
- disponibles. Veuillez vous reporter à <ref id="buildd"> pour plus
- d'informations et à <url id="&url-buildd;"> pour voir le système en
- fonctionnement.
- </p>
- </sect1>
- </sect>
- <sect id="uploaders">
- <heading>
- Téléchargeurs de paquets
- </heading>
- <p>
- Les paquets suivants aident à automatiser ou à simplifier le processus
- d'envoi de paquets dans l'archive officielle.
- </p>
- <sect1 id="dupload">
- <heading>
- <package>dupload</package>
- </heading>
- <p>
- Le paquet <package>dupload</package> contient un script du même nom
- pour mettre à jour des paquets dans l'archive Debian, tracer les mises
- à jour et les annoncer par courrier électronique automatiquement. Vous
- pouvez le configurer pour faire des mises à jour à d'autres endroits
- et avec d'autres méthodes.
- </p>
- </sect1>
- <sect1 id="dput">
- <heading>
- <package>dput</package>
- </heading>
- <p>
- Le script <package>dput</package> fait à peu près la même chose que
- <package>dupload</package>, mais il le fait différemment. Il a aussi
- quelques fonctions supplémentaires telles que la possibilité de
- vérifier la signature GnuPG et les sommes de contrôles avant le
- téléchargement et la possibilité de démarrer <prgn>dinstall</prgn> en
- mode simulation (<em>dry-run</em>) après le téléchargement.
- </p>
- </sect1>
- <sect1 id="dcut">
- <heading>
- <package>dcut</package>
- </heading>
- <p>
- Le script <package>dcut</package> (faisant partie du paquet <ref
- id="dput">) aide à la suppression de fichiers du répertoire d'envoi
- ftp.
- </p>
- </sect1>
- </sect>
- <sect id="tools-maint-automate">
- <heading>
- Automatisation de la maintenance
- </heading>
- <p>
- Les outils suivants aident à automatiser les différentes tâches de
- maintenance par l'ajout des entrées de changelog ou de lignes de
- signatures, par la recherche de bogues à partir d'Emacs et par
- l'utilisation du fichier officiel <file>config.sub</file> le plus
- récent.
- </p>
- <sect1 id="devscripts">
- <heading>
- <package>devscripts</package>
- </heading>
- <p>
- Le paquet <package>devscripts</package> contient des scripts et outils
- qui sont très utiles pour maintenir vos paquets Debian. Parmi ces
- scripts, vous trouverez <prgn>debchange</prgn> et <prgn>dch</prgn> qui
- manipulent votre fichier <file>debian/changelog</file> depuis la ligne
- de commande et <prgn>debuild</prgn> qui est construit au-dessus de
- <prgn>dpkg-buildpackage</prgn>. L'outil <prgn>bts</prgn> est également
- très utile pour mettre à jour l'état des rapports de bogue depuis la
- ligne de commande. Le programme <prgn>uscan</prgn> peut être utilisé
- pour suivre les nouvelles versions amont de vos paquets. Le programme
- <prgn>debrsign</prgn> peut être utilisé pour signer à distance un
- paquet avant de l'envoyer, ce qui est agréable quand la machine sur
- laquelle vous construisez le paquet est différente de celle où
- résident vos clés GPG.
- </p>
- <p>
- Vérifiez la page de manuel <manref section="1" name="devscripts"> pour
- une liste complète des scripts disponibles.
- </p>
- </sect1>
- <sect1 id="autotools-dev">
- <heading>
- <package>autotools-dev</package>
- </heading>
- <p>
- <package>autotools-dev</package> contient les meilleurs pratiques pour
- des personnes assurant la maintenance de paquets qui utilisent
- <prgn>autoconf</prgn> et/ou <prgn>automake</prgn>. Contient également
- des fichiers canoniques <file>config.sub</file> et
- <file>config.guess</file> qui sont connus pour fonctionner avec tous
- les portages Debian.
- </p>
- </sect1>
- <sect1 id="dpkg-repack">
- <heading>
- <package>dpkg-repack</package>
- </heading>
- <p>
- <prgn>dpkg-repack</prgn> crée un paquet Debian à partir d'un paquet
- qui a déjà été installé. Si des changements ont été effectués sur le
- paquet quand il a été décompacté (par exemple, des fichiers dans
- <file>/etc</file> ont été modifiés), le nouveau paquet héritera de ces
- changements.
- </p>
- <p>
- Cet utilitaire peut faciliter la copie de paquet d'un ordinateur vers
- un autre ou la re-création de paquets installés sur un système, mais
- qui ne sont plus disponibles ailleurs ou pour sauvegarder l'état
- actuel d'un paquet avant de le mettre à jour.
- </p>
- </sect1>
- <sect1 id="alien">
- <heading>
- <package>alien</package>
- </heading>
- <p>
- <prgn>alien</prgn> convertit des paquets binaires entre différents
- formats de paquets, y compris des paquets Debian, RPM (RedHat), LSB
- (Linux Standard Base), Solaris et Slackware.
- </p>
- </sect1>
- <sect1 id="debsums">
- <heading>
- <package>debsums</package>
- </heading>
- <p>
- <prgn>debsums</prgn> vérifie des paquets installés par rapport à leur
- somme de hachage MD5. Veuillez noter que tous les paquets n'ont pas de
- sommes MD5 car elles ne sont pas requises par la charte.
- </p>
- </sect1>
- <sect1 id="dpkg-dev-el">
- <heading>
- <package>dpkg-dev-el</package>
- </heading>
- <p>
- <package>dpkg-dev-el</package> fournit des macros Emacs Lisp qui
- apportent une aide lors de l'édition des fichiers du répertoire
- <file>debian</file> de votre paquet. Par exemple, il y a des fonctions
- pratiques pour lister les bogues actuels d'un paquet et pour finaliser
- la dernière entrée d'un fichier <file>debian/changelog</file> file.
- </p>
- </sect1>
- <sect1 id="dpkg-depcheck">
- <heading>
- <package>dpkg-depcheck</package>
- </heading>
- <p>
- <prgn>dpkg-depcheck</prgn> (du paquet <package>devscripts</package>,
- <ref id="devscripts">) exécute une commande sous <prgn>strace</prgn>
- pour déterminer tous les paquets utilisés par la commande.
- </p>
- <p>
- Pour les paquets Debian, c'est utile quand vous devez créer une ligne
- <tt>Build-Depends</tt> pour votre nouveau paquet : exécuter le
- processus de compilation avec <prgn>dpkg-depcheck</prgn> vous fournira
- une bonne première approximation des dépendances de compilation. Par
- exemple :
- <example>
-dpkg-depcheck -b debian/rules build
-</example>
- </p>
- <p>
- <prgn>dpkg-depcheck</prgn> peut aussi être utilisé pour vérifier les
- dépendances d'exécution, particulièrement si votre paquet utilise
- exec(2) pour exécuter d'autres programmes.
- </p>
- <p>
- Pour plus d'informations, veuillez voir <manref section="1"
- name="dpkg-depcheck">.
- </p>
- </sect1>
- </sect>
- <sect id="tools-porting">
- <heading>
- Outils de portage
- </heading>
- <p>
- Les outils suivants facilitent le travail des porteurs et la
- compilation croisée.
- </p>
- <sect1 id="quinn-diff">
- <heading>
- <package>quinn-diff</package>
- </heading>
- <p>
- <package>quinn-diff</package> est utilisé pour localiser les
- différences d'une architecture à l'autre. Il pourrait vous dire, par
- exemple, quels paquets de l'architecture <var>X</var> doivent être
- portés sur l'architecture <var>Y</var>.
- </p>
- </sect1>
- <sect1 id="dpkg-cross">
- <heading>
- <package>dpkg-cross</package>
- </heading>
- <p>
- <package>dpkg-cross</package> est un outil qui installe les
- bibliothèques et les en-têtes nécessaires à une compilation
- croisée<footnote><p><em>cross-compilation</em></p></footnote> d'une
- manière similaire à <package>dpkg</package>. De plus, les paquets
- <prgn>dpkg-buildpackage</prgn> et <prgn>dpkg-shlibdeps</prgn> ont été
- améliorés pour accepter les compilations croisées.
- </p>
- </sect1>
- </sect>
- <sect id="tools-doc">
- <heading>
- Documentation et information
- </heading>
- <p>
- Les paquets suivants fournissent des informations pour les responsables
- ou de l'aide pour construire de la documentation
- </p>
- <sect1 id="debiandoc-sgml">
- <heading>
- <package>debiandoc-sgml</package>
- </heading>
- <p>
- <package>debiandoc-sgml</package> fournit la DTD DebianDoc SGML qui
- est habituellement utilisée pour la documentation Debian. Ce manuel,
- par exemple, est écrit en DebianDoc. Il fournit également des scripts
- pour construire et décliner le source en de multiples formats de
- sortie.
- </p>
- <p>
- La documentation sur la DTD peut être trouvée dans le paquet
- <package>debiandoc-sgml-doc</package>.
- </p>
- </sect1>
- <sect1 id="debian-keyring">
- <heading>
- <package>debian-keyring</package>
- </heading>
- <p>
- Contient les clés publiques GPG et PGP des développeurs Debian. Voir
- <ref id="key-maint"> et la documentation du paquet pour plus
- d'informations.
- </p>
- </sect1>
- <sect1 id="debview">
- <heading>
- <package>debview</package>
- </heading>
- <p>
- <package>debview</package> fournit un mode Emacs pour voir les paquets
- binaires Debian. Il vous permet d'examiner un paquet sans le
- décompresser.
- </p>
- </sect1>
- </sect>
- </appendix>
-</book>
-</debiandoc>
+++ /dev/null
-<!DOCTYPE debiandoc PUBLIC "-//DebianDoc//DTD DebianDoc//EN" [
- <!-- include version information so we don't have to hard code it
- within the document -->
- <!entity % versiondata SYSTEM "version.ent"> %versiondata;
- <!-- common, language independant entities -->
- <!entity % commondata SYSTEM "common.ent" > %commondata;
- <!-- CVS revision of this document -->
- <!entity cvs-rev "$Revision: 1.13 $">
-
- <!-- if you are translating this document, please notate the RCS
- revision of the developers reference here -->
- <!--
- <!entity cvs-en-rev "1.37">
- -->
-]>
-<debiandoc>
-<!--
- TODO:
- - bugs in upstream versions should be reported upstream!
- - add information on how to get accounts on different architectures
- - talk about CVS access, other ways to submit problems
- - add information on how you can contribute w/o being an official
- developer
- - "official port maintainer" ? (cf. glibc-pre2.1)
- -->
-
- <book>
-
- <title>Debian ¥Ç¥Ù¥í¥Ã¥Ñ¡¼¥º¥ê¥Õ¥¡¥ì¥ó¥¹
- <author>Adam Di Carlo, current maintainer <email>aph@debian.org</email>
- <author>Christian Schwarz <email>schwarz@debian.org</email>
- <author>Ian Jackson <email>ijackson@gnu.ai.mit.edu</email>
- <version>ver. &version;, &date-ja;
-
- <copyright>
- <copyrightsummary>
-copyright (c)1998, 1999 Adam Di Carlo</copyrightsummary>
- <copyrightsummary>
-copyright (c)1997, 1998 Christian Schwarz</copyrightsummary>
- <p>
-¤³¤Î¥Þ¥Ë¥å¥¢¥ë¤Ï¥Õ¥ê¡¼¥½¥Õ¥È¥¦¥§¥¢¤Ç¤¹¡£¤¢¤Ê¤¿¤Ï¡¢Free Software Foundation
-¤¬¸øɽ¤·¤¿ GNU °ìÈ̸øÍ»ÈÍѵöÂú¤ÎÂèÆóÈǤ¢¤ë¤¤¤Ï¤½¤ì°Ê¹ß¤Î¤¤¤º¤ì¤«¤ÎÈǤÎ
-¾ò·ï¤Ë´ð¤Å¤¤¤Æ¡¢ËÜʸ½ñ¤ÎºÆÇÛÉÕ¤ª¤è¤ÓÊѹ¹¤ò¹Ô¤¦¤³¤È¤¬²Äǽ¤Ç¤¹¡£
- <p>
-ËÜʸ½ñ¤Ï¤½¤ÎÍÍÑÀ¤¬´üÂÔ¤µ¤ì¤ÆÇÛÉÕ¤µ¤ì¤ë¤â¤Î¤Ç¤¹¤¬¡¢
-»Ô¾ìÀ¤äÆÃÄê¤ÎÌÜŪ¤Ø¤ÎŬ¹çÀ¤Ë´Ø¤¹¤ë°ÅÌÛ¤ÎÊݾڤâ´Þ¤á¡¢
-<em>¤¤¤«¤Ê¤ëÊݾڤâ¹Ô¤Ê¤¤¤Þ¤»¤ó</em>¡£
-¾ÜºÙ¤Ë¤Ä¤¤¤Æ¤Ï GNU °ìÈ̸øÍ»ÈÍѵöÂú½ñ¤ò¤ªÆɤߤ¯¤À¤µ¤¤¡£
- <p>
-GNU °ìÈ̸øÍ»ÈÍѵöÂú¤Î¼Ì¤·¤Ï¡¢Debian GNU/Linux ¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤Î
-&file-GPL; ¤ä¡¢WWW ¾å¤Ç¤Ï <url id="&url-gpl;" name="GNU ¥¦¥§¥Ö¥µ¥¤¥È">
-¤Ë¤¢¤ê¤Þ¤¹¡£¤Þ¤¿ &fsf-addr; ¤Ø¼ê»æ (±Ñ¸ì) ¤Ç°ÍÍꤷÆþ¼ê¤¹¤ë¤³¤È¤â¤Ç¤¤Þ¤¹¡£
- <p>
-¤Ê¤ª¡¢¤³¤ÎÆüËܸìÌõ¤Ë¤Ä¤¤¤Æ¤Ï±óÆ£ Èþ½ã (1999 ǯ) ¤ËÃøºî¸¢¤¬¤¢¤ê¤Þ¤¹¡£
-
- <toc detail="sect2">
-
- <chapt id="scope">¤³¤Îʸ½ñ¤¬°·¤¦Îΰè
- <p>
-¤³¤Îʸ½ñ¤ÎÌÜŪ¤Ï¡¢Debian ³«È¯¼Ô¤Ë¿ä¾©¤µ¤ì¤ë¼ê³¤¤ÈÍøÍѲÄǽ¤Ê¥ê¥½¡¼¥¹¤È¤Ë
-´Ø¤¹¤ë³µ´Ñ¤òÄ󶡤¹¤ë¤³¤È¤Ë¤¢¤ê¤Þ¤¹¡£
- <p>
-¤³¤Á¤é¤Ç°·¤¦½ô¼ê³¤¤Ï¡¢
-³«È¯¼Ô¤Ë¤Ê¤ëÊýË¡ (<ref id="new-maintainer">) ¤ä¡¢
-¿·¤¿¤Ê¥Ñ¥Ã¥±¡¼¥¸¤ò¥¢¥Ã¥×¥í¡¼¥É¤¹¤ëÊýË¡ (<ref id="upload">)¡¢
-¾¤Î³«È¯¼Ô¤Ë¤è¤ë¥Ñ¥Ã¥±¡¼¥¸¤ò°Ü¿¢¤·¤¿¤êÎ×»þ¥ê¥ê¡¼¥¹¤¹¤ë¤Ë¤Ï
-¤¤¤Ä¤É¤Î¤è¤¦¤Ë¤·¤¿¤é¤è¤¤¤Î¤« (<ref id="nmu">)¡¢
-¥Ñ¥Ã¥±¡¼¥¸¤ò°ÜÆ°¡¢ºï½ü¡¢¤ß¤Ê¤·¤´²½ (orphan) ¤¹¤ëÊýË¡ (<ref
-id="archive-manip">)¡¢¥Ð¥°Êó¹ð¤Î°·¤¤Êý (<ref id="bug-handling">)
-¤Ë¤ï¤¿¤ê¤Þ¤¹¡£
- <p>
-¤Þ¤¿¡¢¤³¤Î¥ê¥Õ¥¡¥ì¥ó¥¹¤Ç¿¨¤ì¤ë¥ê¥½¡¼¥¹¤Ë¤Ï¡¢
-¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤È¥µ¡¼¥Ð (<ref id="servers">)¡¢
-Debian ¥¢¡¼¥«¥¤¥Ö¤Î¹½À®¤Ë´Ø¤¹¤ë²òÀâ (<ref id="archive">)¡¢
-¥Ñ¥Ã¥±¡¼¥¸¥¢¥Ã¥×¥í¡¼¥É¤ò¼õ¤±ÉÕ¤±¤ë¤µ¤Þ¤¶¤Þ¤Ê¥µ¡¼¥Ð¤ÎÀâÌÀ
-(<ref id="upload-master">)¡¢
-¥Ñ¥Ã¥±¡¼¥¸¤ÎÉʼÁ¤ò¹â¤á¤ë¤¿¤á¤Ë³«È¯¼Ô¤¬ÍøÍѤǤ¤ë¥ê¥½¡¼¥¹¤Ë¤Ä¤¤¤Æ¤Î²òÀâ
-(<ref id="tools">) ¤Ê¤É¤¬¤¢¤ê¤Þ¤¹¡£
- <p>
-½é¤á¤ËÌÀ¤é¤«¤Ë¤·¤Æ¤ª¤¤¿¤¤¤Î¤Ç¤¹¤¬¡¢
-¤³¤Î¥ê¥Õ¥¡¥ì¥ó¥¹¤Ï¡¢Debian ¥Ñ¥Ã¥±¡¼¥¸¤Ë´Ø¤¹¤ëµ»½ÑŪ¤Ê¾ÜºÙ¤ä¡¢
-Debian ¥Ñ¥Ã¥±¡¼¥¸¤ÎºîÀ®ÊýË¡¤òÀâÌÀ¤¹¤ë¤â¤Î¤Ç¤Ï¤¢¤ê¤Þ¤»¤ó¡£
-¤½¤Î¾ðÊó¤Ë¤Ä¤¤¤Æ¤Ï¡¢<!-- OBSOLETE, please update translation
-<url id="&url-pkg-manual;"
-name="Debian ¥Ñ¥Ã¥±¡¼¥¸¥ó¥°¥Þ¥Ë¥å¥¢¥ë"> --> ¤Ë¤ÆÏÀ¤¸¤é¤ì¤Æ¤¤¤Þ¤¹¡£
-¤Þ¤¿¡¢¤³¤Î¥ê¥Õ¥¡¥ì¥ó¥¹¤Ï Debian
-¥½¥Õ¥È¥¦¥§¥¢¤¬½àµò¤¹¤Ù¤´ð½à¤ò¾ÜºÙ¤Ë²òÀ⤹¤ë¤è¤¦¤Ê¤â¤Î¤Ç¤â¤¢¤ê¤Þ¤»¤ó¡£
-¤½¤Î¾ðÊó¤Ë¤Ä¤¤¤Æ¤Ï¡¢<url id="&url-debian-policy;"
-name="Debian ¥Ý¥ê¥·¡¼¥Þ¥Ë¥å¥¢¥ë"> ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£
- <p>
-¤µ¤é¤Ë¡¢¤³¤Îʸ½ñ¤Ï<em>¸ø¼°¤Ê¥Ý¥ê¥·¡¼¤òÌÀ¤é¤«¤Ë¤¹¤ë¤â¤Î¤Ç¤Ï¤¢¤ê¤Þ¤»¤ó</em>¡£
-¤³¤Á¤é¤Ë´Þ¤Þ¤ì¤ë¤Î¤Ï Debian ¥·¥¹¥Æ¥à¤Ë´Ø¤¹¤ëµ½Ò¤È¡¢
-°ìÈÌŪ¤Ëǧ¤á¤é¤ì¤Æ¤¤¤ë´·½¬¤Ë´Ø¤¹¤ëµ½Ò¤Ç¤¹¡£
-
- <chapt id="new-maintainer">³«È¯¼Ô¤Ë¤Ê¤ë¤¿¤á¤Î¿½¤·¹þ¤ß
-
- <sect>¤Ï¤¸¤á¤è¤¦
- <p>
-¤¢¤Ê¤¿¤Ï¡¢¤¹¤Ç¤Ë¤¹¤Ù¤Æ¤Îʸ½ñ¤òÆɤߡ¢ÎãÂê¤Î <package>hello</package>
-¥Ñ¥Ã¥±¡¼¥¸¤ÎÆâÍƤò¤¹¤Ù¤ÆÍý²ò¤·¡¢
-¤µ¤¡¤³¤ì¤«¤é¤ªµ¤¤ËÆþ¤ê¤Î¥½¥Õ¥È¥¦¥§¥¢¤ò Debianize ¤·¤è¤¦¤È¤·¤Æ¤¤¤ë¤È¤·¤Þ¤¹¡£
-¤Ç¤Ï¡¢Debian ³«È¯¼Ô¤Ë¤Ê¤Ã¤Æ¡¢¼«Ê¬¤Çºî¤Ã¤¿¥Ñ¥Ã¥±¡¼¥¸¤ò Debian ¥×¥í¥¸¥§¥¯¥È
-¤ËÁȤßÆþ¤ì¤ë¤¿¤á¤Ë¤Ï¡¢¼ÂºÝ¤Î¤È¤³¤í¤É¤¦¤¹¤ì¤Ð¤è¤¤¤Î¤Ç¤·¤ç¤¦¤«¡©
- <p>
-¤Þ¤À &email-debian-devel; ¤ò¹ØÆɤ·¤Æ¤¤¤Ê¤¤¤Ê¤é¤Ð¡¢
-¤Þ¤ººÇ½é¤Ë¤³¤Á¤é¤ò¹ØÆɤ·¤Þ¤·¤ç¤¦¡£
-<em>Subject</em> ¤Ë <tt>subscribe</tt> ¤È½ñ¤¤¤¿ÅŻҥ᡼¥ë¤ò
-&email-debian-devel-req; ¤ËÁ÷¤Ã¤Æ¤¯¤À¤µ¤¤¡£
-¤Ê¤Ë¤«ÌäÂ꤬¤¢¤Ã¤¿¤é¡¢¥á¡¼¥ê¥ó¥°¥ê¥¹¥È´ÉÍý¼Ô
-&email-listmaster; ¤ÈÏ¢Íí¤ò¤È¤Ã¤Æ¤¯¤À¤µ¤¤¡£
-ÍøÍѲÄǽ¤Ê¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤Ë¤Ä¤¤¤Æ¤Î¾ðÊó¤Ï
-<ref id="mailing-lists"> ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£
- <p>
-¼ÂºÝ¤Ë¹ÔÆ°¤òµ¯¤³¤·¤¿¤ê¥³¡¼¥É¤ò½ñ¤¤¤¿¤ê¤¹¤ëÁ°¤Ë¡¢
-¤Þ¤º¤Ï¤³¤Á¤é¤ò¹ØÆɤ·¡¢¤·¤Ð¤é¤¯¤ÏÍͻҤò¸«¤Æ
-(¤Ä¤Þ¤êÆɤà¤À¤±¤ÇÅê¹Æ¤Ï¹µ¤¨¤Æ) ¤ß¤Þ¤·¤ç¤¦¡£
-¤½¤¦¤·¤¿¤éºî¶È¤¬½ÅÊ£¤·¤Ê¤¤¤è¤¦¤Ë¡¢
-¤¢¤Ê¤¿¤¬¤É¤ó¤Êºî¶È¤ò¹Ô¤Ê¤¦¤«¤Ë¤Ä¤¤¤Æ¤ÎÅê¹Æ¤ò¤·¤Æ¤¯¤À¤µ¤¤¡£
- <p>
-&email-debian-mentors; ¤ò¹ØÆɤ¹¤ë¤Î¤â¤è¤¤¹Í¤¨¤Ç¤¹¡£
-¾Ü¤·¤¯¤Ï <ref id="mentors"> ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£
-¤Þ¤¿ Linux People IRC ¥Í¥Ã¥È¥ï¡¼¥¯ (Î㤨¤Ð <tt>irc.debian.org</tt>) ¾å¤Î
-<tt>#debian</tt> IRC ¥Á¥ã¥ó¥Í¥ë¤âÌò¤ËΩ¤Ä¤Ç¤·¤ç¤¦¡£
-
- <sect id="registering">Debian ³«È¯¼Ô¤È¤·¤Æ¤ÎÅÐÏ¿
- <p>
-Debian ¥×¥í¥¸¥§¥¯¥È¤Ø¤ÎÅÐÏ¿¤ò·è¤á¤ë¤Þ¤¨¤Ë¡¢<url id="&url-social-contract;"
-name="Debian ¤Î¼Ò²ñ·ÀÌó">¤òÆɤàɬÍפ¬¤¢¤ê¤Þ¤¹¡£
-³«È¯¼Ô¤È¤·¤ÆÅÐÏ¿¤¹¤ë¤È¤¤¤¦¤³¤È¤Ï¡¢
-Debian ¤Î¼Ò²ñ·ÀÌó¤ËƱ°Õ¤·¡¢¤½¤Î»Ù»ý¤òÀÀÌ󤹤뤳¤È¤ò°ÕÌ£¤·¤Þ¤¹¡£
-Debian GNU/Linux ¤ÎÇطʤˤ¢¤ë¹Í¤¨Êý¤ÎËܼÁ¤ËÂФ·¤Æ¡¢
-³«È¯¼Ô¤¬Æ±°Õ¤ò¤¹¤ë¤³¤È¤Ï¶Ë¤á¤Æ½ÅÍפǤ¹¡£
-¤Þ¤¿ <url id="&url-gnu-manifesto;" name="GNU Àë¸À">
-¤âÆɤó¤Ç¤ª¤¯¤È¤è¤¤¤Ç¤·¤ç¤¦¡£
- <p>
-³«È¯¼Ô¤È¤·¤ÆÅÐÏ¿¤¹¤ë¤¿¤á¤Ë¤Ï¡¢
-¤¢¤Ê¤¿¤Î¿È¸µ (identity) ¤È¥×¥í¥¸¥§¥¯¥È¤Ç²¿¤ò¤¹¤ë¤Î¤«
-¤Ë¤Ä¤¤¤Æ¤Î³Îǧ¤ò¹Ô¤Ê¤¤¤Þ¤¹¡£
-
-Debian GNU/Linux ¤Ë´Ø¤ï¤ëºî¶È¤ò¹Ô¤Ê¤¦¿Í¡¹¤Î¿ô¤Ï
-&number-of-maintainers; ¿Í¤ò±Û¤¨¤ë¤Þ¤Ç¤ËÁý¤¨¡¢
-»ä¤¿¤Á¤Î¥·¥¹¥Æ¥à¤Ï¶Ë¤á¤Æ½ÅÍפʤµ¤Þ¤¶¤Þ¤ÊÎΰè¤ÇÍøÍѤµ¤ì¤Æ¤¤¤ë¤¿¤á¤Ë¡¢
-°°Õ¤ò»ý¤Ã¤¿Â¸ºß¤ËÂФ·¤Æ¿µ½Å¤Ë¤Ê¤ëɬÍפ¬¤¢¤ê¤Þ¤¹¡£
-¤½¤Î¤¿¤á¡¢¿·¥á¥ó¥Æ¥Ê¤Ë¥µ¡¼¥Ð¤Î¥¢¥«¥¦¥ó¥È¤òÍ¿¤¨¥Ñ¥Ã¥±¡¼¥¸¤Î¥¢¥Ã¥×¥í¡¼¥É¤ò
-µö²Ä¤¹¤ëÁ°¤Ë¡¢¤½¤Î¿·¥á¥ó¥Æ¥Ê¤ò³Î¤«¤á¤ëɬÍפ¬¤¢¤ë¤Î¤Ç¤¹¡£
- <p>
-ÅÐÏ¿¤ËºÝ¤·¤Æ¤Ï¡¢¤½¤Î¼ê³¤¤Î°ì¤Ä¤È¤·¤Æ¡¢°Ê²¼¤Î¾ðÊó¤ò
-&email-new-maintainer; ¤ËÁ÷¤ëɬÍפ¬¤¢¤ê¤Þ¤¹¡£
-<list>
- <item>
-¤¢¤Ê¤¿¤Î»á̾
- <item>
-´õ˾¤¹¤ë <tt>master</tt> ¥µ¡¼¥Ð¤Î¥í¥°¥¤¥ó̾ (8 ʸ»ú°Ê²¼) ¤È¡¢
-&email-debian-private; ¤ò¹ØÆɤ¹¤ëºÝ¤ÎÅŻҥ᡼¥ë¥¢¥É¥ì¥¹
-(°ìÈÌŪ¤Ë¡¢¤³¤Á¤é¤Ï¤¢¤Ê¤¿¤¬ÉáÃʻȤäƤ¤¤ëÅŻҥ᡼¥ë¥¢¥É¥ì¥¹¤«¡¢
-¤¢¤Ê¤¿¤Î¿·¤·¤¤ <tt>debian.org</tt> ¥¢¥É¥ì¥¹¤Ë¤Ê¤ê¤Þ¤¹¡£)
- <item>
-Ï¢Íí²Äǽ¤ÊÅÅÏÃÈֹ档
-Ãí°Õ¤·¤Æ¤¤¤¿¤À¤¤¿¤¤¤Î¤Ç¤¹¤¬¡¢
-¿·¥á¥ó¥Æ¥Ê¥Á¡¼¥à¤Ïŵ÷Î¥ÄÌÏÃÎÁ¤òÀáÌ󤹤뤿¤á¤Ë¡¢Ä̾ï¤ÏÌë¤ËÅÅÏäò¤«¤±¤Þ¤¹¡£
-Ìë¤Ë¶Ð̳Àè¤Ë¤¤¤ë¤Î¤¬ÉáÄ̤Ǥʤ¤¸Â¤ê¡¢¶Ð̳Àè¤ÎÅÅÏÃÈÖ¹æ¤Ï½ñ¤«¤Ê¤¤¤Ç¤¯¤À¤µ¤¤¡£
- <item>
-¥×¥í¥¸¥§¥¯¥È»²²Ã¤Î°Õ¿Þ¤Ë´Ø¤¹¤ëÀë¸À¡£
-¤³¤Á¤é¤Ë¤Ï¤É¤ó¤Ê¥Ñ¥Ã¥±¡¼¥¸¤òºîÀ®¤·¤è¤¦¤È¤·¤Æ¤¤¤ë¤«¡¢
-¤É¤Î Debian °Ü¿¢ÈǤò¼êÅÁ¤ª¤¦¤È¤·¤Æ¤¤¤ë¤Î¤«¡¢
-¤É¤Î¤è¤¦¤Ë Debian ¤Ë¹×¸¥¤·¤è¤¦¤È¹Í¤¨¤Æ¤¤¤ë¤Î¤«¤ò½ñ¤¤Þ¤¹¡£
- <item>
-<url id="&url-social-contract;" name="Debian ¼Ò²ñ·ÀÌó"> ¤òÆɤߡ¢
-¤½¤ì¤ò»Ù»ý¤¹¤ë¤³¤È¤ËƱ°Õ¤¹¤ë»Ý¤ÎÀë¸À
- <item>
-¤¢¤Ê¤¿¤Î¼ÂÀ¸³è¤Ç¤Î¿È¸µ¤ò³Îǧ¤¹¤ë¤¿¤á¤Î¼êÃÊ¡£
-Î㤨¤Ð°Ê²¼¤Ëµó¤²¤ë¼êÃʤʤé¤ÐÌäÂꤢ¤ê¤Þ¤»¤ó¡£
-<list>
- <item>
-°Ê²¼¤Î¤â¤Î¤Ë¤è¤ë¡¢»ä¤¿¤Á¤¬³Îǧ²Äǽ¤Ê½ð̾¤Ë¤è¤Ã¤Æ¥µ¥¤¥ó¤µ¤ì¤¿ OpenPGP ¸°
-<list>
- <item>
-<em>¼ÂÀ¸³è¾å</em>¤Ç²ñ¤Ã¤¿¤³¤È¤¬¤¢¤ë¸½¹Ô¤Î Debian ³«È¯¼Ô
- <item>
-¤¢¤Ê¤¿¤Î¿È¸µ¤ò¾ÚÌÀ¤¹¤ë (Verisign ¤Ê¤É¤Î¤è¤¦¤Ê) ¸ø¼°¤Êǧ¾Ú¥µ¡¼¥Ó¥¹¡£
-ÅŻҥ᡼¥ë¥¢¥É¥ì¥¹¤Ë´Ø¤¹¤ë¾ÚÌÀ¤Ç¡¢
-¤¢¤Ê¤¿¤Î¿È¸µ¤ò¾ÚÌÀ¤¹¤ë¤â¤Î¤Ç¤Ê¤¤¤â¤Î¤Ç¤Ï¡¢ÉÔ½½Ê¬¤Ç¤¹¡£
- </list>
- <item>
-¤Þ¤¿¡¢¤´¼«¿È¤Î¿È¸µ¤¬³Îǧ¤Ç¤¤ë¸ø¼°¾ÚÌÀ½ñ
-(½ÐÀ¸¾ÚÌÀ½ñ¡¢¹ṉ̃¾ÚÌÀ½ñ¡¢¥¢¥á¥ê¥«¹ç½°¹ñ±¿Å¾Ìȵö¾Ú¤Ê¤É) ¤Î¼Ì¤·¤ò¥¹¥¥ã¥ó
-(¤¢¤ë¤¤¤Ï͹Á÷)¡¢¤¹¤ë¤³¤È¤Ë¤è¤Ã¤Æ¿È¸µ¤ò¾ÚÌÀ¤¹¤ë¤³¤È¤â¤Ç¤¤Þ¤¹¡£
-¤Ê¤ª¡¢¤³¤Á¤é¤òÅŻҥ᡼¥ë¤ÇÁ÷¤ë¾ì¹ç¤Ï¡¢¤¢¤Ê¤¿¤Î OpenPGP ¸°¤Ç½ð̾¤·¤Æ¤¯¤À¤µ¤¤¡£
- </list>
- </list>
- <p>
-¤â¤·¤Þ¤À OpenPGP ¸°¤ò»ý¤Ã¤Æ¤¤¤Ê¤¤¤Ê¤é¤Ð¡¢¤½¤ì¤òÀ¸À®¤·¤Æ¤¯¤À¤µ¤¤¡£
-¥¢¥Ã¥×¥í¡¼¥É¤¹¤ë¥Ñ¥Ã¥±¡¼¥¸¤Ë½ð̾¤·¡¢¤½¤ì¤ò³Îǧ¤¹¤ë¤¿¤á¤Ë¡¢
-³«È¯¼Ô¤Ë¤ÏÁ´°÷ OpenPGP ¸°¤¬É¬ÍפǤ¹¡£
-¤ª»È¤¤¤Ë¤Ê¤ë¥½¥Õ¥È¥¦¥§¥¢¤Î¥Þ¥Ë¥å¥¢¥ë
-¤Ë¤Ï¥»¥¥å¥ê¥Æ¥£¤Ë´Ø¤¹¤ë¶Ë¤á¤Æ½ÅÍפʾðÊ󤬽ñ¤«¤ì¤Æ¤¤¤Þ¤¹¤Î¤Ç¡¢
-¤½¤Á¤é¤Ï¤è¤¯Æɤó¤Ç¤ª¤¤¤Æ¤¯¤À¤µ¤¤¡£
-¥»¥¥å¥ê¥Æ¥£¾å¤ÎÌäÂê¤Î¤Û¤È¤ó¤É¤Ï¡¢
-¥½¥Õ¥È¥¦¥§¥¢¾å¤Î·ç´Ù¤ä¹âÅ٤ʥ¯¥é¥Ã¥¯µ»½Ñ¤Ë¤è¤ë¤â¤Î¤È¤¤¤¦¤è¤ê¤Ï¡¢
-¿Í´Ö¤Î¥ß¥¹¤Ë¤è¤ë¤â¤Î¤Ê¤Î¤Ç¤¹¡£
-¤ª»È¤¤¤Ë¤Ê¤ë¸ø³«¸°¤Î´ÉÍý¤Ë´Ø¤¹¤ë¤è¤ê¾ÜºÙ¤Ê¾ðÊó¤Ë¤Ä¤¤¤Æ¤Ï
-<ref id="key-maint"> ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£
- <p>
-Debian ¤Ï¤½¤Î´ð½à¤È¤Ê¤ëɸ½à¤È¤·¤Æ <prgn>GNU Privacy Guard</prgn>
-(<package>gnupg</package> ¥Ñ¥Ã¥±¡¼¥¸¤Î¥Ð¡¼¥¸¥ç¥ó 1 °Ê¹ß) ¤òÍøÍѤ·¤Þ¤¹¡£
-ƱÍÍ¤Ë OpenPGP ¤Î¾¤Î¼ÂÁõ¤òÍøÍѤµ¤ì¤Æ¤â·ë¹½¤Ç¤¹¡£
-¤Ê¤ª¡¢OpenPGP ¤Ï <url id="&url-rfc2440;" name="RFC2440">
-¤Ë¤ª¤±¤ë¥ª¡¼¥×¥ó¤Êɸ½à¤Ë´ð¤Å¤¯¤â¤Î¤Ç¤¹¡£
- <p>
-Debian ¤Î³«È¯ºî¶È¤Ë¤ª¤¤¤ÆÍѤ¤¤é¤ì¤ë¸ø³«¸°¥¢¥ë¥´¥ê¥º¥à¤È¤·¤Æ¿ä¾©¤µ¤ì¤ë¤Î¤Ï¡¢
-DSA (¤³¤Á¤é¤Ï ``DSS'' ¤ä ``DH/ElGamal'' ¤È¸Æ¤Ð¤ì¤ë¤³¤È¤â¤¢¤ê¤Þ¤¹) ¤Ç¤¹¡£
-¤Ê¤ª¡¢Â¾¤Î¼ïÎà¤Î¸°¤ò¤ª»È¤¤¤Ë¤Ê¤Ã¤Æ¤â·ë¹½¤Ç¤¹¡£
-¤·¤«¤·¡¢¤ª»È¤¤¤Ë¤Ê¤ë¸°¤ÎŤµ¤Ï¡¢¾¯¤Ê¤¯¤È¤â 1024 ¥Ó¥Ã¥È¤Ç¤Ê¤¯¤Æ¤Ï¤Ê¤ê¤Þ¤»¤ó¡£
-¤³¤ì¤è¤êû¤¤¸°¤Ï¥»¥¥å¥ê¥Æ¥£¤¬Ä㤤¤Î¤Ç¡¢¤½¤ì¤ò¤ï¤¶¤ï¤¶»È¤¦É¬ÍפϤ¢¤ê¤Þ¤»¤ó¡£
-¤Þ¤¿¡¢¤ª»È¤¤¤Ë¤Ê¤ë¸°¤Ë¤Ï¡¢¾¯¤Ê¤¯¤È¤â¤¢¤Ê¤¿¤Î¥æ¡¼¥¶
-ID ¤òÍѤ¤¤Æ½ð̾¤·¤Æ¤ª¤¤¤Æ¤¯¤À¤µ¤¤¡£
-¤³¤¦¤¹¤ë¤³¤È¤Ë¤è¤Ã¤Æ ¥æ¡¼¥¶ ID ¤Î²þãâ¤òËɤ°¤³¤È¤¬¤Ç¤¤Þ¤¹¡£
-<prgn>gpg</prgn> ¤Ï¤³¤Á¤é¤ò¼«Æ°Åª¤Ë¹Ô¤Ê¤¤¤Þ¤¹¡£
- <p>
-¤Þ¤¿ ¤ª»È¤¤¤Ë¤Ê¤ë¸°¾å¤Î̾Á°¤Î°ì¤Ä¤¬¡¢
-ºîÀ®¤·¤¿¥Ñ¥Ã¥±¡¼¥¸¤Ç¤¢¤Ê¤¿¤¬¸ø¼°³«È¯¼Ô¤È¤·¤ÆÍѤ¤¤ë
-ÅŻҥ᡼¥ë¥¢¥É¥ì¥¹¤È°ìÃפ¹¤ë¤è¤¦¤Ë¤·¤Æ¤¯¤À¤µ¤¤¡£
-Î㤨¤Ð¡¢»ä¤Ï <package>developers-reference</package> ¥Ñ¥Ã¥±¡¼¥¸¤Î³«È¯¼Ô¤ò
-``Adam Di Carlo <aph@debian.org>'' ¤È¤·¤Æ¤¤¤Þ¤¹¤¬¡¢
-¤½¤ì¤æ¤¨¡¢»ä¤Î¸°¤Î¥æ¡¼¥¶ ID ¤Î°ì¤Ä¤Ï¡¢¤³¤ì¤ÈƱ¤¸ÃÍ
-``Adam Di Carlo <aph@debian.org>'' ¤ò»ý¤Ã¤Æ¤¤¤Þ¤¹¡£
- <p>
-¤Þ¤À¤¢¤Ê¤¿¤Î¸ø³«¸°¤ò &pgp-keyserv; ¤Î¤è¤¦¤Ê¸ø³«¸°¥µ¡¼¥Ð¤Ë
-ÅÐÏ¿¤·¤Æ¤¤¤Ê¤¤¾ì¹ç¤Ï¡¢¤ª¼ê¸µ¤Î¥³¥ó¥Ô¥å¡¼¥¿¤ÇÍøÍѤǤ¤ë
-&file-keyservs; ¤È¤¤¤¦Ê¸½ñ¤ò¤ªÆɤߤ¯¤À¤µ¤¤¡£
-¤³¤Îʸ½ñ¤Ë¤Ï¼«Ê¬¤Î¸°¤ò¸ø³«¸°¥µ¡¼¥Ð¤ËÅÐÏ¿¤¹¤ëÊýË¡¤¬ÀâÌÀ¤µ¤ì¤Æ¤¤¤Þ¤¹¡£
-¤¢¤Ê¤¿¤Î¸ø³«¸°¤¬¸ø³«¥µ¡¼¥Ð¤ËÅÐÏ¿¤µ¤ì¤Æ¤¤¤Ê¤«¤Ã¤¿¾ì¹ç¤Ï¡¢
-New Maintainer ¥°¥ë¡¼¥×¤¬¤½¤ÎÅÐÏ¿¤ò¹Ô¤Ê¤¤¤Þ¤¹¡£
- <p>
-¥¢¥á¥ê¥«¹ç½°¹ñ¤ÎÍ¢½ÐÀ©¸Â¤Î¤¿¤á¤Ë <package>gnupg</package>
-¤ò´Þ¤à¤¤¤¯¤Ä¤«¤Î¥Ñ¥Ã¥±¡¼¥¸¤Ï¡¢¹ç½°¹ñ³°¤Î ftp ¥µ¡¼¥Ð¤ËÃÖ¤¤¤Æ¤¢¤ê¤Þ¤¹¡£
-¤³¤ì¤é¤Î¥Ñ¥Ã¥±¡¼¥¸¤¬¸½ºßÃÖ¤«¤ì¤Æ¤¤¤ë¾ì½ê¤Ë´Ø¤·¤Æ¤Ï¡¢
-<url id="&url-readme-non-us;"> ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£
- <p>
-¹ñ¤Ë¤è¤Ã¤Æ¤Ï¡¢°Å¹æ¥½¥Õ¥È¥¦¥§¥¢¤ÎÍøÍѤò¹ṉ̃¤Ë¶Ø¤¸¤Æ¤¤¤ë¤È¤³¤í¤â¤¢¤ê¤Þ¤¹¡£
-¤·¤«¤·¡¢(¥Õ¥é¥ó¥¹¤Î¾ì¹ç¤Ê¤É) °Å¹æ¤ò°·¤¦À½Éʤò¡¢°Å¹æ¤ÎÍøÍѤΤ¿¤á¤Ç¤Ï¤Ê¤¯Ç§
-¾Ú¤Î¤¿¤á¤ËÍøÍѤ¹¤ë¤³¤È¤Ï´°Á´¤Ë¹çË¡¤Ç¤¹¤«¤é¡¢¤³¤Á¤é¤â Debian ¥Ñ¥Ã¥±¡¼¥¸³«È¯
-¼Ô¤Î³èÆ°¤ò˸¤²¤ë¤â¤Î¤Ç¤Ï¤¢¤ê¤Þ¤»¤ó¡£
-Debian ¥×¥í¥¸¥§¥¯¥È¤Ç¤Ï¡¢°Å¹æ¤ÎÀ¸À®¡¢²òÆɤΤ¿¤á¤Ë¡¢
-¤½¤ì¤òÍøÍѤ¹¤ë¤³¤È¤Ïµá¤á¤é¤ì¤Þ¤»¤ó¡£
-¤Ê¤ª¡¢Ç§¾Ú¤Î¤¿¤á¤Î°Å¹æÍøÍѤ¬¶Ø»ß¤µ¤ì¤Æ¤¤¤ë¹ñ¤Ë½»¤ó¤Ç¤¤¤ë¾ì¹ç¤Ï¡¢
-ÆÃÊ̤ÊÁ¼ÃÖ¤ò¹Ö¤¸¤Þ¤¹¤Î¤Ç¤´Ï¢Íí¤¯¤À¤µ¤¤¡£
- <p>
-¤¢¤Ê¤¿¤Ë´Ø¤¹¤ë¾ðÊó¤ò¤¹¤Ù¤ÆÍÑ°Õ¤·¤ª¤ï¤ê¸ø³«¸°¤¬¸ø³«¸°¥µ¡¼¥Ð¤ËÅÐÏ¿¤µ¤ì¤¿¤é¡¢
-¤¢¤Ê¤¿¤Î¥Ñ¥Ã¥±¡¼¥¸¤ò¥¢¥Ã¥×¥í¡¼¥É¤Ç¤¤ë¤è¤¦
-¸ø¼° Debian ³«È¯¼Ô¤ÎÅÐÏ¿¤ò¹Ô¤Ê¤¦¤¿¤á¤Ë¡¢
-&email-new-maintainer; °¸¤Æ¤ËÅŻҥ᡼¥ë¤òÁ÷¤Ã¤Æ¤¯¤À¤µ¤¤¡£
-¤³¤ÎÅŻҥ᡼¥ë¤Ë¤Ï¡¢¾åµ¤Î¾ðÊ󤬤¹¤Ù¤Æ´Þ¤Þ¤ì¤Æ¤¤¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¡£
-¤Þ¤¿¡¢¤³¤Î¥á¡¼¥ë¤Ë¤Ï <url id="&url-debian-keyring;"> ¤ä¡¢
-<package>debian-keyring</package> ¥Ñ¥Ã¥±¡¼¥¸¤ÇÇÛÉÛ¤µ¤ì¤ë¸°¥Ç¡¼¥¿¥Ù¡¼¥¹ÍѤˡ¢
-¤¢¤Ê¤¿¤Î¸ø³«¸°¤òź¤¨¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¡£
-(<prgn>gpg</prgn> ¤Î¾ì¹ç¤Ï <tt>gpg --armor --export <var>user_id</var></tt>
-¤È¤·¤Æ¸°¤ò¼è¤ê½Ð¤·¤Æ¤¯¤À¤µ¤¤¡£)
-¤Ê¤ª¡¢¤³¤Î¿½ÀÁ¥á¡¼¥ë¤Ë¤Ï¼«Ê¬¤ÇÁª¤ó¤À¸ø³«¸°¤Çɬ¤º½ð̾¤·¤Æ¤¯¤À¤µ¤¤¡£
- <p>
-¤³¤ì¤é¤Î¾ðÊ󤬼õ¤±¼è¤é¤ì¤Æ½èÍý¤µ¤ì¤ì¤Ð¡¢¤¢¤Ê¤¿¤Î Debian
-³«È¯¼Ô¤È¤·¤Æ¤Î¿·¤¿¤Ê¥¢¥«¥¦¥ó¥È¤Ë´Ø¤¹¤ë¾ðÊó¤¬Ï¢Íí¤µ¤ì¤ë¤Ï¤º¤Ç¤¹¡£
-¤â¤·°ì¥ö·î°ÊÆâ¤Ë²¿¤âÏ¢Íí¤¬¤Ê¤«¤Ã¤¿¤é¡¢
-¿½ÀÁ¥á¡¼¥ë¤¬ÆϤ¤¤Æ¤¤¤ë¤«¤É¤¦¤«¿Ò¤Í¤ë¤¿¤á¤Ë¡¢
-¥Õ¥©¥í¡¼¥¢¥Ã¥×¥á¥Ã¥»¡¼¥¸¤òÁ÷¤Ã¤Æ¤¯¤À¤µ¤¤¡£
-¿½ÀÁ¥á¡¼¥ë¤ò·«¤êÊÖ¤·¤ÆÁ÷¤ë¤è¤¦¤Ê¤³¤È¤Ï¡¢
-New Maintainer ¥Á¡¼¥à¤¬º®Í𤹤ë¤À¤±¤Ç¤¹¤Î¤Ç¡¢
-·è¤·¤Æ<em>¤·¤Ê¤¤</em>¤Ç¤¯¤À¤µ¤¤¡£
-Æä˥ê¥ê¡¼¥¹¤¬¶á¤Å¤¤¤Æ¤¤¤ë¾ì¹ç¤Ê¤É¤Ï¡¢
-´Ö°ã¤¤¤âµ¯¤³¤ê¤ä¤¹¤¯¡¢Ã´Åö¼Ô¤â»þ´Ö¤ËÄɤï¤ì¤Æ¤¤¤ë¤Î¤Ç¡¢
-¿ÉÊú¶¯¤¯¤ªÂÔ¤Á¤¯¤À¤µ¤¤¡£
-
- <sect id="mentors">Debian Mentors (»ØƳ¼Ô)
- <p>
-¿·ÊƳ«È¯¼Ô¤¬½é¤á¤Æ¥Ñ¥Ã¥±¡¼¥¸¤òºîÀ®¤·¤¿¤ê¡¢
-³«È¯¤Ë´ØÏ¢¤¹¤ë¾¤ÎÌäÂê¤ò²ò·è¤¹¤ëºÝ¤Ë¡¢¤½¤Î¼ê½õ¤±¤¬¤Ç¤¤ë¤è¤¦
-¥á¡¼¥ê¥ó¥°¥ê¥¹¥È &email-debian-mentors; ¤¬ÍÑ°Õ¤µ¤ì¤Æ¤¤¤Þ¤¹¡£
-¿·µ¬³«È¯¼Ô¤Ë¤Ï¤³¤Î¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤Î¹ØÆɤ¬¿Ê¤á¤é¤ì¤Æ¤¤¤Þ¤¹¡£
-(¾ÜºÙ¤Ï <ref id="mailing-lists"> ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£)
- <p>
-(Î㤨¤Ð¡¢»äŪ¤ÊÅŻҥ᡼¥ë¤Î¤ä¤ê¤È¤ê¤Ê¤É) °ìÂаì¤Î±ç½õ¤ò˾¤Þ¤ì¤ë¾ì¹ç¤â¡¢
-¤³¤Î¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤òÍøÍѤ·¤Æ¤¯¤À¤µ¤¤¡£
-·Ð¸³ËÉ٤ʳ«È¯¼Ô¤¬¼ê½õ¤±¤ò¿½¤·½Ð¤Æ¤¯¤ì¤ë¤Ç¤·¤ç¤¦¡£
-
-
- <chapt id="user-maint">Debian ¤ËÅÐÏ¿¤·¤¿¼«Ê¬¤Î¾ðÊó¤ò´ÉÍý¤¹¤ë
-
- <sect id="key-maint">¼«Ê¬¤Î¸ø³«¸°¤ò´ÉÍý¤¹¤ë
- <p>
-³Æ¼«¤ÎÈëÌ©¸°¤Î°·¤¤¤Ë¤Ä¤¤¤Æ¤Ï½½Ê¬¤ËÃí°Õ¤·¤Æ¤¯¤À¤µ¤¤¡£
-¤½¤ì¤ò¸ø³«¥µ¡¼¥Ð¤ä <tt>master.debian.org</tt>
-¤Î¤è¤¦¤Ê¥Þ¥ë¥Á¥æ¡¼¥¶¤Î¥Þ¥·¥ó¤ËÃÖ¤¤¤¿¤ê¤·¤Æ¤Ï¤¤¤±¤Þ¤»¤ó¡£
-¤Þ¤¿¤½¤Î¥Ð¥Ã¥¯¥¢¥Ã¥×¤ò¼è¤ê¡¢¤½¤Î¼Ì¤·¤ò¥ª¥Õ¥é¥¤¥ó¤ÇÊÝ»ý¤·¤Æ¤ª¤¤¤Æ¤¯¤À¤µ¤¤¡£
-¤µ¤é¤Ë¡¢¤ª»È¤¤¤Ë¤Ê¤ë¥½¥Õ¥È¥¦¥§¥¢¤ËÉÕ°¤¹¤ëÀâÌÀ½ñ¤ä¡¢
-<url id="&url-pgp-faq;" name="PGP FAQ"> ¤Ë¤âÌܤòÄ̤·¤Æ¤¯¤À¤µ¤¤¡£
- <p>
-¤¢¤Ê¤¿¤Î¸ø³«¸°¤Ë½ð̾¤ä¥æ¡¼¥¶ ID ¤ò²Ã¤¨¤¿¤êºï½ü¤·¤¿¾ì¹ç¤Ë¤Ï
-¸°¥µ¡¼¥Ð¾å¤Î¸ø³«¸°¤ò¹¹¿·¤¹¤ë¤È¤È¤â¤Ë¡¢
-¤¢¤Ê¤¿¤Î¸ø³«¸°¤ò &email-debian-keyring;
-¤ËÅŻҥ᡼¥ë¤ÇÁ÷ÉÕ¤¹¤ëɬÍפ¬¤¢¤ê¤Þ¤¹¡£
-¤½¤Î¸°¤ò¼è¤ê½Ð¤¹ÊýË¡¤Ë¤Ä¤¤¤Æ¤Ï <ref id="registering">
-¤ÇÀâÌÀ¤·¤Æ¤¢¤ê¤Þ¤¹¡£
- <p>
-Debian ¤Ë¤ª¤±¤ë¸°´ÉÍý¤Ë¤Ä¤¤¤Æ¤Î¤è¤ê¾ÜºÙ¤Ê¸¡Æ¤¤Ë¤Ä¤¤¤Æ¤Ï¡¢
-<package>debian-keyring</package>
-¥Ñ¥Ã¥±¡¼¥¸¤Î¥É¥¥å¥á¥ó¥È¤ò¤´Í÷¤¯¤À¤µ¤¤¡£
-
- <sect>Ãú½Å¤ËæÂह¤ë
- <p>
-Debian ¥×¥í¥¸¥§¥¯¥È¤«¤éæÂà¤ò·è¤á¤¿¾ì¹ç¤Ï¡¢
-ɬ¤º°Ê²¼¤Î¼ê³¤¤ò¹Ô¤Ê¤¦¤Ù¤¤Ç¤¹¡£
-<enumlist>
- <item>
-<ref id="orphaning"> ¤ÎÀâÌÀ¤Ë¤·¤¿¤¬¤¤¡¢
-¼«Ê¬¤Î¥Ñ¥Ã¥±¡¼¥¸¤¹¤Ù¤Æ¤ò¤ß¤Ê¤·¤´²½¤¹¤ë
- <item>
-¥×¥í¥¸¥§¥¯¥ÈæÂà¤ÎÍýͳ¤Ë´Ø¤¹¤ëÅŻҥ᡼¥ë¤ò
-&email-debian-private; ¤ËÁ÷¤ë
- <item>
-&email-debian-keyring; °¸¤Æ¤ËÅŻҥ᡼¥ë¤òÁ÷¤ê¡¢
-Debian ¥¡¼¥ê¥ó¥°´ÉÍý¼Ô¤Ë¥×¥í¥¸¥§¥¯¥ÈæÂà¤òÅÁ¤¨¤ë
- </enumlist>
-
-
- <chapt id="servers">¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤ä¡¢¥µ¡¼¥Ð¡¢Â¾¤Î¥Þ¥·¥ó
- <p>
-
-¤³¤Î¾Ï¤Ç¤Ï¡¢³«È¯¼Ô¤¬ÍøÍѤǤ¤ë Debian ¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤ª¤è¤Ó¼ç¤Ê Debian
-¥µ¡¼¥Ð¤ä¾¤Î Debian ¥Þ¥·¥ó¤Ë´Ø¤¹¤ë´Êñ¤Ê¾Ò²ð¤ò¹Ô¤Ê¤¤¤Þ¤¹¡£
-
- <sect id="mailing-lists">¥á¡¼¥ê¥ó¥°¥ê¥¹¥È
- <p>
-¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¥µ¡¼¥Ð¤Ï <tt>&lists-host;</tt> ¤Ë¤¢¤ê¤Þ¤¹¡£
-¹ØÆɤ¹¤ë¾ì¹ç¤Ï <tt>subscribe</tt> ¤ò¹ØÆɤò¼è¤ê¾Ã¤¹¾ì¹ç¤Ï
-<tt>unsubscribe</tt> ¤È <em>Subject</em> ¤Ë½ñ¤¤¤Æ¡¢
-<tt>debian-<var>foo</var>-REQUEST@&lists-host;</tt>
-¤ËÅŻҥ᡼¥ë¤òÁ÷¤Ã¤Æ¤¯¤À¤µ¤¤¡£
-¤½¤ÎºÝ <tt>debian-<var>foo</var></tt>
-¤Ë¤Ï¤½¤Î¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤Î̾Á°¤òÅö¤Æ¤Ï¤á¤Æ¤¯¤À¤µ¤¤¡£
-¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤Î¹ØÆɤȤ½¤Î¹ØÆɼè¤ê¾Ã¤·¤Ë´Ø¤¹¤ë¤è¤ê¾ÜºÙ¤ÊÀâÌÀ¤Ë¤Ä¤¤¤Æ¤Ï¡¢
-<url id="&url-debian-lists-subscribe;">¤ä
-<url id="&url-debian-lists-txt;">¡¢¤Þ¤¿
-<package>doc-debian</package> ¥Ñ¥Ã¥±¡¼¥¸¤ò¥¤¥ó¥¹¥È¡¼¥ë¤·¤Æ¤¤¤ë¾ì¹ç¤Ï¡¢
-¤ª¼ê¸µ¤Î¥Þ¥·¥ó¤Î &file-mail-lists; ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£
- <p>
-¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤Î¥á¥Ã¥»¡¼¥¸¤ËÊÖ¿®¤ò¤¹¤ë¾ì¹ç¡¢
-¥«¡¼¥Ü¥ó¥³¥Ô¡¼ (<tt>CC</tt>) ¤ò¥ª¥ê¥¸¥Ê¥ë¤Îȯ¿®¼Ô¤ËÁ÷¤ë¤³¤È¤Ï¡¢
-¤½¤¦¤¹¤ë¤³¤È¤¬ÌÀ¼¨Åª¤Ëµá¤á¤é¤ì¤Æ¤¤¤Ê¤¤¸Â¤ê¤Ï¤·¤Ê¤¤¤Ç¤¯¤À¤µ¤¤¡£
-¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤ËÅê¹Æ¤·¤¿¿Í¤Ï¡¢¤½¤ÎÊÖ¿®¤ò¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¾å¤ÇÆɤà¤Ï¤º¤Ç¤¹¡£
- <p>
-Debian ¤ÎÃæ³ËŪ¤Ê¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤Ë¤Ï¡¢&email-debian-devel; ¤ä¡¢
-&email-debian-policy;¡¢&email-debian-user;¡¢&email-debian-private;¡¢
-&email-debian-announce;¡¢&email-debian-devel-announce; ¤¬¤¢¤ê¤Þ¤¹¡£
-³«È¯¼Ô¤ÏÁ´°÷¾¯¤Ê¤¯¤È¤â &email-debian-private ¤È
-&email-debian-devel-announce; ¤ò¹ØÆɤ¹¤ë¤³¤È¤¬´üÂÔ¤µ¤ì¤Þ¤¹¡£
-ÆÃÊ̤ÊÌÜŪ¤ò»ý¤Ä¾¤Î¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤Ë´Ø¤·¤Æ¤Ï¡¢
-<url id="&url-debian-lists-subscribe;"> ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£
-¤Þ¤¿¡¢¥¯¥í¥¹¥Ý¥¹¥È (Ʊ¤¸¥á¥Ã¥»¡¼¥¸¤òÊ£¿ô¤Î¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤ØÅê¹Æ¤¹¤ë¤³¤È)
-¤Ï¤Ê¤ë¤Ù¤¯Èò¤±¤Æ¤¯¤À¤µ¤¤¡£
- <p>
-&email-debian-private; ¤Ï¡¢Debian ³«È¯¼Ô´Ö¤Î»äŪ¤ÊµÄÏÀ¤Î¤¿¤á¤Ë
-ÍÑ°Õ¤µ¤ì¤¿ÆÃÊ̤ʥ᡼¥ê¥ó¥°¥ê¥¹¥È¤Ç¤¹¡£
-¤³¤Á¤é¤Ï¡¢¤¤¤«¤Ê¤ëÍýͳ¤¬¤¢¤Ã¤¿¤È¤·¤Æ¤â¡¢
-¸ø¤Ë¤Ï¸ø³«¤·¤Ê¤¤Åê¹Æ¤Î¤¿¤á¤ËÍѤ¤¤é¤ì¤ë¤â¤Î¤Ç¤¹¡£
-¤½¤Î¤¿¤á¡¢¤³¤Á¤é¤Ï¾®µ¬ÌϤʥ᡼¥ê¥ó¥°¥ê¥¹¥È¤Ç¡¢
-ËÜÅö¤ËɬÍפʾì¹ç¤ò½ü¤¤¤Æ &email-debian-private; ¤ÎÍøÍѤϴ«¤á¤é¤ì¤Þ¤»¤ó¡£
-¤µ¤é¤Ë¡¢¤³¤Î¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤ÎÅŻҥ᡼¥ë¤ò¾¼Ô¤ËžÁ÷¤·¤Æ¤Ï
-<em>¤¤¤±¤Þ¤»¤ó</em>¡£
- <p>
-¥Í¥Ã¥È¥ï¡¼¥¯¤Ë¤ª¤±¤ëÄÌÎãÄ̤ê¤Ë¡¢
-ÊÖ¿®¤¹¤ë¾ì¹ç¤Îµ»ö¤Î°úÍѤϹµ¤¨Ìܤˤ·¤Æ¤¯¤À¤µ¤¤¡£
-¤Þ¤¿¡¢°ìÈÌŪ¤Ë¥á¥Ã¥»¡¼¥¸Åê¹Æ¤Ë´Ø¤·¤Æ¤ÏÄÌÎã¤Î´·½¬¤Ë¤·¤¿¤¬¤Ã¤Æ¤¯¤À¤µ¤¤¡£
- <p>
-¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤Î¥ª¥ó¥é¥¤¥ó¥¢¡¼¥«¥¤¥Ö¤Ï
-<url id="&url-lists-archives;"> ¤Ë¤ÆÍøÍѤǤ¤Þ¤¹¡£
-
- <sect id="server-machines">Debian ¥µ¡¼¥Ð·²
- <p>
-Debian ¥µ¡¼¥Ð·²¤Ï¤è¤¯ÃΤé¤ì¤Æ¤¤¤Þ¤¹¤¬¡¢
-Debian ¥×¥í¥¸¥§¥¯¥È¤Ë¤ª¤¤¤Æ¶Ë¤á¤Æ½ÅÍפʵ¡Ç½¤ò²Ì¤¿¤·¤Æ¤¤¤Þ¤¹¡£
-³Æ³«È¯¼Ô¤Ï³Æ¥µ¡¼¥Ð¤¬¤É¤Î¤è¤¦¤Ê¤â¤Î¤Ç¡¢²¿¤ò¹Ô¤Ê¤Ã¤Æ¤¤¤ë¤Î¤«¤ò
-ÃΤäƤª¤¯¤Ù¤¤Ç¤·¤ç¤¦¡£
- <p>
-¤â¤· Debian ¥µ¡¼¥Ð¤ÎÍøÍѤËÌäÂ꤬¤¢¤ê¡¢
-¤½¤ÎÌäÂê¤ò¥·¥¹¥Æ¥à´ÉÍý¼Ô¤ËÃΤ餻¤ëɬÍפ¬¤¢¤ë¤È»×¤ï¤ì¤ë¾ì¹ç¤Ï¡¢
-<!-- Adam disabled, not used <url id="&url-debian-contacts;"> -->
-¤ò¤´Í÷¤Ë¤Ê¤Ã¤Æ¡¢¤½¤ÎôÅö¼Ô¤ÎÏ¢ÍíÀè¤ò³Îǧ¤·¤Æ¤¯¤À¤µ¤¤¡£
-¤Þ¤¿¡¢¥µ¡¼¥Ð¤ÎÍøÍѤ˴ؤ¹¤ë¤â¤Î°Ê³°¤ÎÌäÂê
-(Î㤨¤Ð¥Ñ¥Ã¥±¡¼¥¸¤Îºï½ü¤ä¡¢¥¦¥§¥Ö¥µ¥¤¥È¤Ø¤ÎÄó°Æ¤Ê¤É) ¤¬¤¢¤ë¾ì¹ç¤Ï¡¢
-°ìÈÌŪ¤Ë¤Ï¡Ö²¾Áۥѥ屡¼¥¸¡×¤ËÂФ¹¤ë¥Ð¥°¤È¤·¤ÆÊó¹ð¤ò¹Ô¤Ê¤Ã¤Æ¤¯¤À¤µ¤¤¡£
-¥Ð¥°Êó¹ð¤Ë´Ø¤¹¤ë¾ðÊó¤Ë¤Ä¤¤¤Æ¤Ï <ref id="submit-bug"> ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£
-
- <sect1 id="servers-master">master ¥µ¡¼¥Ð
- <p>
-master ¥µ¡¼¥Ð <tt>master.debian.org</tt> ¤Ë¤Ï¡¢
-(non-U.S. ¥Ñ¥Ã¥±¡¼¥¸¤ò½ü¤¯) Debian
-¥¢¡¼¥«¥¤¥Ö¤ÎÀµ¼°¤Ê¼Ì¤·¤¬ÊÝ»ý¤µ¤ì¤Æ¤¤¤Þ¤¹¡£
-°ìÈÌŪ¤Ë¥Ñ¥Ã¥±¡¼¥¸¤Ï¤³¤Î¥µ¡¼¥Ð¤Ë¥¢¥Ã¥×¥í¡¼¥É¤µ¤ì¤Þ¤¹¡£
-<ref id="upload"> ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£
- <p>
-¤Þ¤¿¡¢¥Ð¥°ÄÉÀ×¥·¥¹¥Æ¥à (BTS) ¤¬Àµ¼°¤Ë¤ª¤«¤ì¤Æ¤¤¤ë¤Î¤â¡¢
-¤³¤Î <tt>master.debian.org</tt> ¤Ç¤¹¡£
-Debian ¥Ð¥°¤ÎÅý·×Ū¤ÊʬÀϤä½èÍý¤ò¹Ô¤Ê¤¤¤¿¤¤¾ì¹ç¤Ë¡¢
-¤½¤ì¤ò¹Ô¤Ê¤¦¤Î¤â¤³¤Á¤é¤Ë¤Ê¤ê¤Þ¤¹¡£
-¤·¤«¤·¤Ê¤¬¤é¡¢¤½¤³¤Ë²¿¤«¤ò¼ÂÁõ¤¹¤ëÁ°¤Ë¤Ï¡¢
-̵Â̤ÊÏ«ÎϤä»þ´Ö¤ÎϲÈñ¤òÈò¤±¤ë¤¿¤á¤Ë¡¢
-&email-debian-devel; ¤Ë¤Æ¤¢¤Ê¤¿¤Î¥×¥é¥ó¤òÀâÌÀ¤·¤Æ¤¯¤À¤µ¤¤¡£
- <p>
-Debian ³«È¯¼Ô¤Ï¤¹¤Ù¤Æ <tt>master.debian.org</tt> ¤Ë¥¢¥«¥¦¥ó¥È¤ò»ý¤Á¤Þ¤¹¡£
-¤³¤Î¥Þ¥·¥ó¤Î¥Ñ¥¹¥ï¡¼¥É¤Î´ÉÍý¤Ë¤ÏÃí°Õ¤·¤Æ¤¯¤À¤µ¤¤¡£
-´í¸±¤òÈȤ·¤Æ¥¤¥ó¥¿¡¼¥Í¥Ã¥È±Û¤·¤Ë¥Ñ¥¹¥ï¡¼¥É¤òÁ÷¤ë¤è¤¦¤Ê¡¢
-¥í¥°¥¤¥ó¤ä¥¢¥Ã¥×¥í¡¼¥É¥á¥½¥Ã¥É¤ÏÈò¤±¤ë¤è¤¦¤Ë¤·¤Æ¤¯¤À¤µ¤¤¡£
- <p>
-<tt>master.debian.org</tt> ¤Ç¥Ç¥£¥¹¥¯¥Õ¥ë¡¢ÉÔ¿³¤ÊÆ°ºî¤Ê¤É¤ò¸«¤«¤±¤¿¾ì¹ç¤Ï¡¢
-&email-debian-admin; °¸¤Æ¤ËÅŻҥ᡼¥ë¤òÁ÷¤Ã¤Æ¤¯¤À¤µ¤¤¡£
-Debian FTP ¥¢¡¼¥«¥¤¥Ö¤Ë´Ø¤¹¤ëÌäÂê¤Ë¤Ä¤¤¤Æ¤Ï¡¢Ä̾ï
-<package>ftp.debian.org</package>
-²¾Áۥѥ屡¼¥¸¤ËÂФ¹¤ë¥Ð¥°¤È¤·¤ÆÊó¹ð¤¹¤ë¤«¡¢
-&email-ftpmaster; °¸¤Æ¤ËÅŻҥ᡼¥ë¤òÁ÷¤ëɬÍפ¬¤¢¤ê¤Þ¤¹¡£
-¤Ê¤ª¡¢¤½¤Î¼ê³¤¤Ë¤Ä¤¤¤Æ¤Ï <ref id="archive-manip"> ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£
-
- <sect1 id="servers-www">WWW ¥µ¡¼¥Ð
- <p>
-¥á¥¤¥ó¥¦¥§¥Ö¥µ¡¼¥Ð¤Ç¤¢¤ë <tt>www.debian.org</tt>
-¤Ï¡¢<tt>va.debian.org</tt> ¤È¤·¤Æ¤âÃΤé¤ì¤Æ¤¤¤ë¤â¤Î¤Ç¤¹¡£
-³«È¯¼Ô¤Ë¤ÏÁ´°÷¤Ë¤³¤Î¥Þ¥·¥ó¤Î¥¢¥«¥¦¥ó¥È¤¬ÉÕÍ¿¤µ¤ì¤Þ¤¹¡£
- <p>
-¥¦¥§¥Ö¾å¤Ç¤â¤Ã¤Ñ¤é Debian ¤Ë´ØÏ¢¤¹¤ë¾ðÊó¤òÄ󶡤·¤¿¤¤¾ì¹ç¤Ï¡¢
-¤¢¤Ê¤¿¤Î¥Û¡¼¥à¥Ç¥£¥ì¥¯¥È¥êÇÛ²¼¤Î <file>public_html</file>
-¥Ç¥£¥ì¥¯¥È¥ê¤Ë¥Õ¥¡¥¤¥ë¤òÀßÃÖ¤¹¤ì¤Ð²Äǽ¤Ç¤¹¡£
-¤³¤Á¤é¤Ë´Ø¤·¤Æ¤Ï <tt>va.debian.org</tt> ¤È
-<tt>master.debian.org</tt> ¤Î¤É¤Á¤é¤Ç¹Ô¤Ê¤Ã¤Æ¤â·ë¹½¤Ç¤¹¡£
-¤½¤Î¾ì½ê¤ËÀßÃÖ¤·¤¿¥Õ¥¡¥¤¥ë¤Ï¡¢
-<tt>http://www.debian.org/~<var>user-id</var>/</tt> ¤«
-<tt>http://master.debian.org/~<var>user-id</var>/</tt> ¤È¤¤¤¦
-URL ·Ðͳ¤Ç¤½¤ì¤¾¤ì¥¢¥¯¥»¥¹¤¹¤ë¤³¤È¤¬¤Ç¤¤Þ¤¹¡£
-¾ì¹ç¤Ë¤è¤Ã¤Æ¤Ï <tt>master</tt>
-¾å¤Ë¥Õ¥¡¥¤¥ë¤òÀßÃÖ¤¹¤ëɬÍפ¬¤¢¤ë¤«¤â¤·¤ì¤Þ¤»¤ó¤¬¡¢
-°ìÈÌŪ¤Ë¤Ï <tt>www.debian.org</tt> ¥¢¥É¥ì¥¹ÍÑ¤Ë <tt>va</tt>
-¤ò¤´ÍøÍѤˤʤꤿ¤¤¤Ç¤·¤ç¤¦¡£
-Á°¤â¤Ã¤Æµö²Ä¤òÆÀ¤Æ¤¤¤Ê¤¤¸Â¤ê¡¢Debian ¤Ë´Ø·¸¤Î¤Ê¤¤¥³¥ó¥Æ¥ó¥Ä¤ò
-Debian ¥µ¡¼¥Ð¾å¤Ë¤ÏÀßÃÖ¤·¤Ê¤¤¤¯¤À¤µ¤¤¡£
-²¿¤«¼ÁÌ䤬¤¢¤ë¤È¤¤Ë¤Ï &email-debian-devel; ¤ØÅŻҥ᡼¥ë¤òÁ÷¤Ã¤Æ¤¯¤À¤µ¤¤¡£
- <p>
-Debian ¥¦¥§¥Ö¥µ¡¼¥Ð¤ËÌäÂê¤ò¸«¤Ä¤±¤¿¾ì¹ç¡¢Ä̾ï¤Ï
-<package>www.debian.org</package>
-²¾Áۥѥ屡¼¥¸¤ËÂФ¹¤ë¥Ð¥°¤È¤·¤ÆÊó¹ð¤·¤Æ¤¯¤À¤µ¤¤¡£
-¤Ê¤ª¡¢¤Þ¤º½é¤á¤Ë狼¤¬¤¹¤Ç¤ËƱ¤¸ÌäÂê¤òÊó¹ð¤·¤Æ¤¤¤Ê¤¤¤«¤É¤¦¤«¤ò
-<url id="&url-bts;db/pa/lwww.debian.org.html" name="¥Ð¥°ÄÉÀ×¥·¥¹¥Æ¥à">
-¤Ç³Îǧ¤·¤Æ¤¯¤À¤µ¤¤¡£
-
- <sect1 id="servers-cvs">CVS ¥µ¡¼¥Ð
- <p>
-<tt>cvs.debian.org</tt> ¤ÏÁ°½Ò¤Î
-<tt>va.debian.org</tt> ¤È¤·¤Æ¤âÃΤé¤ì¤Æ¤¤¤ë¤â¤Î¤Ç¤¹¡£
-³«È¯¼Ô¤¬Ê£¿ô¤¤¤ë¥Ñ¥Ã¥±¡¼¥¸¤Î¶¨Æ±ºî¶È¤ò¼êÅÁ¤¦¾ì¹ç¤Ê¤É¡¢
-CVS ¥µ¡¼¥Ð¤Ø¤Î¸ø³«¥¢¥¯¥»¥¹¤òÍøÍѤ·¤¿¤¤¾ì¹ç¤Ï¡¢
-¤³¤Î¥µ¡¼¥Ð¤Î CVS ¥¨¥ê¥¢ÍøÍѤò°ÍÍꤹ¤ë¤³¤È¤¬¤Ç¤¤Þ¤¹¡£
- <p>
-°ìÈÌŪ¤Ë <tt>cvs.debian.org</tt> ¤Ï¡¢¥í¡¼¥«¥ë CVS ¥¢¥¯¥»¥¹¤ä¡¢
-¥¯¥é¥¤¥¢¥ó¥È/¥µ¡¼¥Ð¼°¥¢¥Î¥Ë¥Þ¥¹Æɤ߹þ¤ßÀìÍÑ¥¢¥¯¥»¥¹¡¢
-<prgn>ssh</prgn> ·Ðͳ¥¯¥é¥¤¥¢¥ó¥È/¥µ¡¼¥Ð¼°¥Õ¥ë¥¢¥¯¥»¥¹¤ò
-ÁȤ߹ç¤ï¤»¤ÆÄ󶡤·¤Þ¤¹¡£
-¤Þ¤¿¡¢¤³¤Î CVS ¥¨¥ê¥¢¤Ë¤Ï <url id="&url-cvsweb;">
-¤«¤é¥¦¥§¥Ö·Ðͳ¤ÇÆɤ߹þ¤ßÀìÍÑ¥¢¥¯¥»¥¹¤ò¤¹¤ë¤³¤È¤¬¤Ç¤¤Þ¤¹¡£
- <p>
-CVS ¥¨¥ê¥¢ÍøÍѤΰÍÍê¤ò¤¹¤ë¾ì¹ç¤Ï¡¢&email-debian-admin;
-°¸¤Æ¤ËÅŻҥ᡼¥ë¤Ç°ÍÍꤷ¤Æ¤¯¤À¤µ¤¤¡£
-¤½¤ÎºÝ¤Ë¤Ï¡¢É¬ÍפȤ¹¤ë CVS ¥¨¥ê¥¢¤Î̾Á°¤ä¡¢CVSROOT ¤Î½êͼԤȤʤë
-<tt>va.debian.org</tt> ¾å¤Î¥æ¡¼¥¶¥¢¥«¥¦¥ó¥È¡¢
-¤³¤Á¤é¤òɬÍפȤ¹¤ëÍýͳ¤ò½ñ¤Åº¤¨¤Æ¤¯¤À¤µ¤¤¡£
-
- <sect1 id="servers-mirrors">Debian ¥µ¡¼¥Ð¤Î¥ß¥é¡¼
- <p>
-¥¦¥§¥Ö¥µ¡¼¥Ð¤ª¤è¤Ó FTP ¥µ¡¼¥Ð¤Ë¤Ï¡¢ÍøÍѲÄǽ¤Ê¥ß¥é¡¼¥µ¡¼¥Ð¤¬Ê£¿ô¤¢¤ê¤Þ¤¹¡£
-Ãæ³Ë¤È¤Ê¤ë FTP ¥µ¡¼¥Ð¤ä¥¦¥§¥Ö¥µ¡¼¥Ð¤Ë¤Ï¹â¤¤Éé²Ù¤òÍ¿¤¨¤Ê¤¤¤Ç¤¯¤À¤µ¤¤¡£
-ÍýÁÛŪ¤Ë¤Ï¡¢Ãæ³Ë¤È¤Ê¤ë¥µ¡¼¥Ð¤ÏÂè°ì¿Ø¤Î¥ß¥é¡¼¥µ¡¼¥Ð¤Ë¥ß¥é¡¼¤ò¹Ô¤Ê¤¦¤Î¤ß¤Ç¡¢
-¥æ¡¼¥¶¤Ï¤¹¤Ù¤Æ¥ß¥é¡¼¤Ë¥¢¥¯¥»¥¹¤¹¤ë¤³¤È¤¬Ë¾¤Þ¤·¤¤¤Ç¤¹¡£
-¤³¤¦¤¹¤ì¤Ð Debian ¤ÏɬÍפȤ¹¤ë¥Í¥Ã¥È¥ï¡¼¥¯ÂÓ°è¤ò¡¢
-Ê£¿ô¤Î¥µ¡¼¥Ð¤ä¥Í¥Ã¥È¥ï¡¼¥¯¤Ë¤è¤êŬÀÚ¤Ëʬ»¶¤µ¤»¤ë¤³¤È¤¬¤Ç¤¤Þ¤¹¡£
-¤Ê¤ª¡¢¤è¤ê¿·¤·¤¤¥ß¥é¡¼¥ê¥ó¥°Á÷½Ðµ»½Ñ¤Ë¤è¤Ã¤Æ¡¢
-¥ß¥é¡¼¤¬²Äǽ¤Ê¸Â¤êºÇ¿·¤Ç¤¢¤ë¤³¤È¤¬Êݾڤµ¤ì¤Þ¤¹¡£
- <p>
-ÍøÍѲÄǽ¤Ê¸ø³« FTP (¤ª¤è¤Ó¡¢Ä̾ï¤Ï¡¢HTTP)
-¥µ¡¼¥Ð¤Î°ìÍ÷¤ò·ÇºÜ¤¹¤ë¥á¥¤¥ó¥¦¥§¥Ö¥Ú¡¼¥¸¤Ï
-<url id="&url-debian-mirrors;"> ¤Ë¤¢¤ê¤Þ¤¹¡£
-Debian ¥ß¥é¡¼¤Ë´Ø¤¹¤ë¤è¤ê¾Ü¤·¤¤¾ðÊó¤Ë¤Ä¤¤¤Æ¤Ï
-<url id="&url-debian-mirroring;"> ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£
-¤³¤Îͱפʥڡ¼¥¸¤Ë¤Ï¡¢ÆâÉô¸þ¤±¥¢¥¯¥»¥¹¤ä¸øŪ¥¢¥¯¥»¥¹¤Î¤É¤Á¤é¤Ë¤ª¤¤¤Æ¤â¡¢
-Æȼ«¤Ë¥ß¥é¡¼¤òÀßÃÖ¤¹¤ë¤³¤È¤Ë´Ø¿´¤¬¤¢¤ë¾ì¹ç¤Ë
-ÌòΩ¤Ä¾ðÊó¤ä¥Ä¡¼¥ë¤¬´Þ¤Þ¤ì¤Æ¤¤¤Þ¤¹¡£
- <p>
-ÉáÄ̤³¤ì¤é¤Î¥ß¥é¡¼¤Ï Debian
-¤Ø¤Î¶¨ÎϤ˴ؿ´¤Î¤¢¤ë¥µ¡¼¥É¥Ñ¡¼¥Æ¥£¡¼¤Ë¤è¤Ã¤Æ±¿±Ä¤µ¤ì¤Æ¤¤¤Þ¤¹¡£
-¤½¤Î¤¿¤áÄ̾³«È¯¼Ô¤Ï¤³¤ì¤é¤Î¥Þ¥·¥ó¤Ë¥¢¥«¥¦¥ó¥È¤¬¤¢¤ê¤Þ¤»¤ó¡£
- <p>
-<tt>master.debian.org</tt> ¤Î¥ß¥é¡¼¤ò¤È¤ë¤³¤È¤Ï¤·¤Ê¤¤¤Ç¤¯¤À¤µ¤¤¡£
-¤³¤Î¥Û¥¹¥È¤Ï¤¹¤Ç¤ËÁêÅö¹â¤¤Éé²Ù¤òÉé¤Ã¤Æ¤¤¤Þ¤¹¡£
-¤½¤Î¾ðÊó¤Ë¤Ä¤¤¤Æ¤Ï¾åµ¤Î¥µ¥¤¥È¤ò³Îǧ¤¹¤ë¤«¡¢
-<email>debian-devel@lists.debian.org</email>
-°¸¤Æ¤ËÅŻҥ᡼¥ë¤òÁ÷¤Ã¤Æ¤¯¤À¤µ¤¤¡£
-
- <sect id="other-machines">Debian ¤Î¾¤Î¥Þ¥·¥ó
- <p>
-³«È¯¼Ô¤¬ÍøÍѤǤ¤ë Debian ¥Þ¥·¥ó¤Ï¾¤Ë¤â¤¢¤ê¤Þ¤¹¡£
-¤³¤ì¤é¤Î¥Þ¥·¥ó¤Ï¡¢ÍøÍѼԤ¬Å¬ÀڤǤ¢¤ë¤ÈȽÃǤ¹¤ëÈÏ°ÏÆâ¤Ç¡¢
-Debian ¤Ë´ØÏ¢¤¹¤ëÌÜŪ¤ËÍøÍѤǤ¤Þ¤¹¡£
-¤Ê¤ª¡¢³Æ¥·¥¹¥Æ¥à´ÉÍý¼Ô¤ËÌÂÏǤò¤«¤±¤Ê¤¤¤è¤¦¤ËÃí°Õ¤·¤Æ¤¯¤À¤µ¤¤¡£
-¤Þ¤¿¡¢¤Þ¤ººÇ½é¤Ë¥í¡¼¥«¥ë¥á¥ó¥Æ¥Ê¤Ëλ²ò¤òÆÀ¤Ê¤¤¸Â¤ê¤Ï¡¢
-¥Ç¥£¥¹¥¯¥¹¥Ú¡¼¥¹¤ä¡¢¥Í¥Ã¥È¥ï¡¼¥¯ÂÓ°è¡¢CPU ¤Ê¤É¤ò¤à¤ä¤ß¤Ë»È¤ï¤Ê¤¤¤Ç¤¯¤À¤µ¤¤¡£
-ÉáÄ̤³¤ì¤é¤Î¥Þ¥·¥ó¤Ï¥Ü¥é¥ó¥Æ¥£¥¢¤Ë¤è¤Ã¤Æ±¿±Ä¤µ¤ì¤Æ¤¤¤Þ¤¹¡£
-¤³¤ì¤é¤Î¥Þ¥·¥ó¤Ï°ìÈÌŪ¤Ë°Ü¿¢ºî¶ÈÍѤǤ¹¡£
- <p>
-<ref id="server-machines"> ¤Ç¿¨¤ì¤¿³Æ¥µ¡¼¥Ð¤È¤ÏÊ̤ˡ¢
-Debian ³«È¯¼Ô¤¬ÍøÍѤǤ¤ë¥Þ¥·¥ó¤Î°ìÍ÷¤¬
-<url id="&url-devel-machines;"> ¤Ë¤¢¤ê¤Þ¤¹
-
-
- <chapt id="archive">Debian ¥¢¡¼¥«¥¤¥Ö
-
- <sect>³µ´Ñ
- <p>
-Debian GNU/Linux ¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤Ï¡¢¿ô¿¤¯¤Î Debian ¥Ñ¥Ã¥±¡¼¥¸
-(¸½ºßÌó &number-of-pkgs; ¤¢¤ë <tt>.deb</tt> ¥Õ¥¡¥¤¥ë)
-¤È¤¤¤¯¤Ä¤«¤ÎÉÕ²ÃŪ¤Ê¥Õ¥¡¥¤¥ë (¥É¥¥å¥á¥ó¥È¤ä¥¤¥ó¥¹¥È¡¼¥ë¥Ç¥£¥¹¥¯¥¤¥á¡¼¥¸¤Ê¤É)
-¤«¤é¹½À®¤µ¤ì¤Æ¤¤¤Þ¤¹¡£
- <p>
-°Ê²¼¤Ï´°Á´¤Ê Debian ¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤Î¥Ç¥£¥ì¥¯¥È¥ê¥Ä¥ê¡¼¤Î°ìÎã¤Ç¤¹¡£
- <p>
-&sample-dist-dirtree;
- <p>
-¤´Í÷¤ÎÄ̤ê¤Ë¡¢¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤Î¥È¥Ã¥×¥ì¥Ù¥ë¥Ç¥£¥ì¥¯¥È¥ê¤Ë¤Ï¡¢
-<em>main</em>¡¢<em>contrib</em>¡¢<em>non-free</em>
-¤Î»°¤Ä¤Î¥Ç¥£¥ì¥¯¥È¥ê¤¬¤¢¤ê¤Þ¤¹¡£
-¤³¤ì¤é¤Î¥Ç¥£¥ì¥¯¥È¥ê¤Ï <em>sections</em> ¤È¸Æ¤Ð¤ì¤Æ¤¤¤Þ¤¹¡£
- <p>
-³Æ¥»¥¯¥·¥ç¥ó¤Ë¤Ï¡¢¥½¡¼¥¹¥Ñ¥Ã¥±¡¼¥¸ÍѤΥǥ£¥ì¥¯¥È¥ê
-(<tt>source</tt>)¡¢¥µ¥Ý¡¼¥È¤µ¤ì¤Æ¤¤¤ë³Æ¥¢¡¼¥¥Æ¥¯¥Á¥ãÍѤΥǥ£¥ì¥¯¥È¥ê
-(<tt>binary-i386</tt>¡¢<tt>binary-m68k</tt> ¤Ê¤É)¡¢
-¥¢¡¼¥¥Æ¥¯¥Á¥ãÈó°Í¸¤Î¥Ñ¥Ã¥±¡¼¥¸ÍѤΥǥ£¥ì¥¯¥È¥ê
-(<tt>binary-all</tt>) ¤¬¤¢¤ê¤Þ¤¹¡£
- <p>
-<em>main</em> ¥»¥¯¥·¥ç¥ó¤Ë¤Ï¡¢ÆÃÄê¤Î¥¢¡¼¥¥Æ¥¯¥Á¥ã¤Ë¤ª¤¤¤Æ Debian ¥Ç¥£¥¹¥È
-¥ê¥Ó¥å¡¼¥·¥ç¥ó¤ò¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ëºÝ¤ËɬÍפȤʤë¥Ç¥£¥¹¥¯¥¤¥á¡¼¥¸¤È¡¢
-¤¤¤¯¤Ä¤«¤Î´ðËÜŪ¤Êʸ½ñ¤ò¼ýÏ¿¤¹¤ë¤¿¤á¤ÎÉÕ²ÃŪ¤Ê¥Ç¥£¥ì¥¯¥È¥ê
-(<tt>disks-i386</tt>¡¢<tt>disks-m68k</tt> ¤Ê¤É) ¤¬´Þ¤Þ¤ì¤Æ¤¤¤Þ¤¹¡£
- <p>
-<em>binary</em> ¤ª¤è¤Ó <em>source</em> ¥Ç¥£¥ì¥¯¥È¥ê¤Ï¡¢
-¤µ¤é¤Ë <em>subsections</em> ¤Ëʬ¤«¤ì¤Æ¤¤¤Þ¤¹¡£
-
- <sect>¥»¥¯¥·¥ç¥ó
- <p>
-<em>¸ø¼° Debian GNU/Linux ¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó</em>
-¤ò¹½À®¤¹¤ë¤Î¤¬ <em>main</em> ¥»¥¯¥·¥ç¥ó¤Ç¤¹¡£
-<em>main</em> ¥»¥¯¥·¥ç¥ó¤Ï¡¢
-»ä¤¿¤Á¤Î¥¬¥¤¥É¥é¥¤¥ó¤¹¤Ù¤Æ¤Ë´°Á´¤ËŬ¹ç¤¹¤ë¤¬¤æ¤¨¤Ë¸ø¼°¤Ê¤â¤Î¤Ç¤¹¡£
-¾¤ÎÆó¤Ä¤Î¥»¥¯¥·¥ç¥ó¤ÏÄøÅ٤ΰ㤤¤Ï¤¢¤ê¤Þ¤¹¤¬¡¢
-¤³¤Î¥¬¥¤¥É¥é¥¤¥ó¤ËŬ¹ç¤·¤Ê¤¤¤¿¤á¤Ë¡¢
-Debian ¤Î¸ø¼°¤Ê¹½À®Í×ÁǤǤϤ¢¤ê¤Þ¤»¤ó¡£
- <p>
-<em>main</em> ¥»¥¯¥·¥ç¥ó¤ÎÁ´¥Ñ¥Ã¥±¡¼¥¸¤Ï
-<url id="&url-dfsg;" name="Debian ¥Õ¥ê¡¼¥½¥Õ¥È¥¦¥§¥¢¥¬¥¤¥É¥é¥¤¥ó">(DFSG) ¤È
-<url id="&url-debian-policy;" name="Debian ¥Ý¥ê¥·¡¼¥Þ¥Ë¥å¥¢¥ë">
-¤ËµºÜ¤µ¤ì¤Æ¤¤¤ë¾¤Î¥Ý¥ê¥·¡¼¾å¤ÎÍ×·ï¤ò´°Á´¤ËËþ¤¿¤·¤Æ¤¤¤Þ¤¹¡£
-DEFS ¤Ï¡Ö¥Õ¥ê¡¼¥½¥Õ¥È¥¦¥§¥¢¡×¤Ë´Ø¤¹¤ë»ä¤¿¤Á¤ÎÄêµÁ¤Ç¤¹¡£
-¾Ü¤·¤¯¤Ï Debian ¥Ý¥ê¥·¡¼¥Þ¥Ë¥å¥¢¥ë¤ò¤´Í÷¤¯¤À¤µ¤¤¡£
- <p>
-DFSG ¤ËŬ¹ç¤·¤Ê¤¤¥Ñ¥Ã¥±¡¼¥¸¤Ï
-<em>non-free</em> ¥»¥¯¥·¥ç¥ó¤ËÃÖ¤«¤ì¤Þ¤¹¡£
-¤³¤ì¤é¤Î¥Ñ¥Ã¥±¡¼¥¸¤Ë´Ø¤·¤Æ¤Ï¡¢¤½¤ÎÍøÍѤΥµ¥Ý¡¼¥È¤ä
-<em>non-free</em> ¥½¥Õ¥È¥¦¥§¥¢¥Ñ¥Ã¥±¡¼¥¸¤Î¤¿¤á¤Î¥¤¥ó¥Õ¥é
-(¥Ð¥°ÄÉÀ×¥·¥¹¥Æ¥à¤ä¡¢¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤Ê¤É)¤ÏÄ󶡤·¤Þ¤¹¤¬¡¢
-Debian ¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤Î°ìÉô¤È¤Ï¸«¤Ê¤µ¤ì¤Þ¤»¤ó¡£
- <p>
-<em>contrib</em> ¥»¥¯¥·¥ç¥ó¤Î¥Ñ¥Ã¥±¡¼¥¸¤Ï
-DFSG ¤ËŬ¹ç¤·¤Æ¤¤¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¤¬¡¢
-¾¤ÎÍ×·ï¤òËþ¤¿¤»¤Ê¤¤¤â¤Î¤¬Åö¤Æ¤Ï¤Þ¤ê¤Þ¤¹¡£
-Î㤨¤Ð <em>non-free</em> ¥Ñ¥Ã¥±¡¼¥¸¤Ë°Í¸¤¹¤ë¥Ñ¥Ã¥±¡¼¥¸¤Ê¤É¤Ç¤¹¡£
- <p>
-¤³¤Î»°¤Ä¤Î¥»¥¯¥·¥ç¥ó¤Ë´Ø¤·¤Æ¤Ï¡¢
-<url id="&url-debian-policy;" name="Debian ¥Ý¥ê¥·¡¼¥Þ¥Ë¥å¥¢¥ë">
-¤Ë¤è¤êÀµ³Î¤ÊÄêµÁ¤¬µ½Ò¤µ¤ì¤Æ¤¤¤Þ¤¹¡£
-¾åµ¤ÎÀâÌÀ¤Ï´Ê°×Ū¤Ê¤â¤Î¤Ç¤¹¡£
- <p>
-¥¢¡¼¥«¥¤¥Ö¤Î¥È¥Ã¥×¥ì¥Ù¥ë¤ò»°¤Ä¤Î¥»¥¯¥·¥ç¥ó¤Ëʬ¤±¤Æ¤¤¤ë¤³¤È¤Ï¡¢
-¥¤¥ó¥¿¡¼¥Í¥Ã¥È¾å¤Î FTP ¥µ¡¼¥Ð¤ä CD-ROM ¤Ê¤É¤ò·Ðͳ¤·¤Æ
-Debian ¤òÇÛÉÛ¤·¤¿¤¤¤È¹Í¤¨¤ë¿Í¡¹¤Ë¤È¤Ã¤Æ½ÅÍפǤ¹¡£
-¤È¤¤¤¦¤Î¤â¡¢<em>main</em> ¤ª¤è¤Ó <em>contrib</em>
-¥»¥¯¥·¥ç¥ó¤Î¤ß¤òÇÛÉÛ¤¹¤ë¤Ê¤é¤Ð¡¢
-¤¢¤é¤æ¤ëˡŪ¤Ê´í¸±¤òÈò¤±¤ë¤³¤È¤¬¤Ç¤¤ë¤«¤é¤Ç¤¹¡£
-Î㤨¤Ð <em>non-free</em> ¥»¥¯¥·¥ç¥ó¤Î¥Ñ¥Ã¥±¡¼¥¸¤Î¤¤¤¯¤Ä¤«¤Ï
-¾¦¶ÈÇÛÉÛ¤¬¶Ø¤¸¤é¤ì¤Æ¤¤¤Þ¤¹¡£
- <p>
-°ìÊý¡¢CD-ROM ¥Ù¥ó¥À¤Ë¤È¤Ã¤Æ¤Ï <em>non-free</em>
-¥Ñ¥Ã¥±¡¼¥¸¤Î¸Ä¡¹¤Î¥é¥¤¥»¥ó¥¹¤ò¥Á¥§¥Ã¥¯¤·¡¢µö²Ä¤òÆÀ¤¿¤â¤Î¤ò
-CD-ROM ¤Ë¼ýÏ¿¤¹¤ë¤³¤È¤¬Íưפˤʤê¤Þ¤¹¡£
-(¤³¤Î°·¤¤¤Ï¥Ù¥ó¥À¤Ë¤è¤Ã¤Æ¤µ¤Þ¤¶¤Þ¤Ç¤·¤ç¤¦¤«¤é¡¢
-¤³¤Îºî¶È¤Ï Debian ³«È¯¼Ô¤Ë¤è¤Ã¤Æ¤Ï¹Ô¤Ê¤ï¤ì¤Þ¤»¤ó¡£)
-
- <sect>¥¢¡¼¥¥Æ¥¯¥Á¥ã
- <p>
-Åö½é Linux ¥«¡¼¥Í¥ë¤¬ÍøÍѤǤ¤¿¤Î¤Ï Intel i386 (¤ª¤è¤Ó¤½¤ì°Ê¹ß)
-¥×¥é¥Ã¥È¥Õ¥©¡¼¥à¤Î¤ß¤Ç¡¢Debian ¤âƱÍͤǤ·¤¿¡£
-¤·¤«¤· Linux ¤¬¤è¤êÉáµÚ¤¹¤ë¤È¡¢
-¥«¡¼¥Í¥ë¤â¾¤Î¥¢¡¼¥¥Æ¥¯¥Á¥ã¤Ø¤È°Ü¿¢¤µ¤ì¤ë¤è¤¦¤Ë¤Ê¤ê¤Þ¤·¤¿¡£
- <p>
-Linux 2.0 ¥«¡¼¥Í¥ë¤Ï Intel x86 ¤ä¡¢DEC Alpha¡¢SPARC¡¢(Atari ¤ä¡¢
-Amiga¡¢Macintoshes ¤È¤¤¤Ã¤¿) Motorola 680x0 ¡¢MIPS¡¢PowerPC
-¤Ê¤É¤ò¥µ¥Ý¡¼¥È¤·¤Æ¤¤¤Þ¤¹¡£
-Linux 2.2 ¥«¡¼¥Í¥ë¤Ï¤µ¤é¤Ë¡¢ARM ¤ä UltraSPARC
-¤ò´Þ¤à¤è¤ê¿¤¯¤Î¥¢¡¼¥¥Æ¥¯¥Á¥ã¤ò¥µ¥Ý¡¼¥È¤·¤Þ¤¹¡£
-Debian ¤Ï¡¢Linux ¤¬¥µ¥Ý¡¼¥È¤¹¤ë¥×¥é¥Ã¥È¥Õ¥©¡¼¥à¤ò
-ƱÍͤ˥µ¥Ý¡¼¥È¤¹¤Ù¤¤À¤È¤·¤Æ¤¤¤Þ¤¹¡£
-¤½¤Î¤¿¤á Debian ¤Ë¤Ïºî¶ÈÃæ¤Î°Ü¿¢ÈǤ¬¤¢¤ê¡¢
-¤Þ¤¿¼ÂºÝ¤Î¤È¤³¤íÈó Linux ¥«¡¼¥Í¥ë¤Ø¤Î°Ü¿¢ÈǤâºî¶ÈÃæ¤Ç¤¹¡£
-<em>i386</em> (Intel x86 ¤Î»ä¤¿¤Á¤Î¸Æ¤Ó̾) ¤ÏÊ̤ˤ·¤Æ¡¢
-¤³¤Îʸ½ñ¤¬½ñ¤«¤ì¤Æ¤¤¤ë¸½ºß¡¢<em>m68k</em> ¤ä¡¢<em>alpha</em>¡¢
-<em>powerpc</em>¡¢<em>sparc</em>¡¢<em>hurd-i386</em> <em>arm</em>
-¤Ê¤É¤¬ºî¶ÈÃæ¤Ç¤¹¡£
- <p>
-Debian GNU/Linux 1.3 ¤Ï <em>i386</em> ÈǤΤߤ¬ÍøÍѲÄǽ¤Ç¤·¤¿¡£
-Debian 2.0 ¤Ç¤Ï <em>i386</em> ¤ª¤è¤Ó <em>m68k</em>
-¥¢¡¼¥¥Æ¥¯¥Á¥ãÈǤ¬Ä󶡤µ¤ì¤Þ¤·¤¿¡£
-Debian 2.1 ¤Ç¤Ï <em>i386</em>¡¢<em>m68k</em>¡¢<em>alpha</em>¡¢¤ª¤è¤Ó
-<em>sparc</em> ¥¢¡¼¥¥Æ¥¯¥Á¥ãÈǤ¬Ä󶡤µ¤ì¤Þ¤·¤¿¡£
-Debian 2.1 ¤Ç¤Ï <em>powerpc</em> ¥¢¡¼¥¥Æ¥¯¥Á¥ã¤Î¥µ¥Ý¡¼¥È¤¬Äɲ䵤ì¤Þ¤¹¡£
- <p>
-ÆÃÄê¤Î°Ü¿¢ÈǤ˴ؤ¹¤ë³«È¯¼Ô¸þ¤±¡¢¤¢¤ë¤¤¤Ï¥æ¡¼¥¶¸þ¤Î¾ðÊó¤Ï
-<url id="&url-debian-ports;" name="Debian °Ü¿¢ÈÇ¥¦¥§¥Ö¥Ú¡¼¥¸">
-¤ò¤´Í÷¤¯¤À¤µ¤¤¡£
-
- <sect>¥µ¥Ö¥»¥¯¥·¥ç¥ó
- <p>
-<em>main</em>¡¢<em>contrib</em>¡¢<em>non-free</em> ¤Î³Æ¥»¥¯¥·¥ç¥ó¤Ï¡¢
-¥¤¥ó¥¹¥È¡¼¥ë¥×¥í¥»¥¹¤ä¥¢¡¼¥«¥¤¥Ö¤Î¥á¥ó¥Æ¥Ê¥ó¥¹¤òñ½ã²½¤¹¤ë¤¿¤á¤Ë
-<em>subsections</em> ¤Ëʬ³ä¤µ¤ì¤Þ¤¹¡£
-¥µ¥Ö¥»¥¯¥·¥ç¥ó¤Ï¡¢`base' ¥µ¥Ö¥»¥¯¥·¥ç¥ó¤ò½ü¤±¤Ð¡¢
-Àµ¼°¤Ë¤ÏÄêµÁ¤µ¤ì¤Æ¤¤¤Þ¤»¤ó¡£
-¥µ¥Ö¥»¥¯¥·¥ç¥ó¤Ïñ¤Ë¡¢
-ÍøÍѲÄǽ¤Ê¥Ñ¥Ã¥±¡¼¥¸¤ÎÀ°Íý¤È±ÜÍ÷¤òÍưפˤ¹¤ë¤¿¤á¤Ë¸ºß¤·¤Æ¤¤¤Þ¤¹¡£
-¤É¤Î¥»¥¯¥·¥ç¥ó¤¬ÍøÍѲÄǽ¤«¤É¤¦¤«¤Ï¡¢
-¸½¹Ô¤Î Debian ¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤ò¥Á¥§¥Ã¥¯¤·¤Æ¤¯¤À¤µ¤¤¡£
-
- <sect>¥Ñ¥Ã¥±¡¼¥¸
- <p>
-Debian ¥Ñ¥Ã¥±¡¼¥¸¤Ë¤Ï¡¢<em>source</em> ¥Ñ¥Ã¥±¡¼¥¸¤È
-<em>binary</em> ¥Ñ¥Ã¥±¡¼¥¸¤ÎÆó¼ïÎब¤¢¤ê¤Þ¤¹¡£
- <p>
-¥½¡¼¥¹¥Ñ¥Ã¥±¡¼¥¸¤Ï¡¢<tt>.dsc</tt> ¥Õ¥¡¥¤¥ë¤È
-<tt>.tar.gz</tt> ¥Õ¥¡¥¤¥ë¡¢¤¢¤ë¤¤¤Ï¡¢<tt>.dsc</tt> ¥Õ¥¡¥¤¥ë¤È
-<tt>.orig.tar.gz</tt>¡¢<tt>.diff.gz</tt>
-¥Õ¥¡¥¤¥ë¤È¤¤¤Ã¤¿Æó¤Ä¤Ê¤¤¤·»°¤Ä¤Î¥Õ¥¡¥¤¥ë¤«¤é¹½À®¤µ¤ì¤Æ¤¤¤Þ¤¹¡£
- <p>
-Debian ÀìÍѤ˳«È¯¤µ¤ì Debian °Ê³°¤ÇÇÛÉÛ¤µ¤ì¤Æ¤¤¤Ê¤¤¥Ñ¥Ã¥±¡¼¥¸¤Ç¤Ï¡¢
-¥×¥í¥°¥é¥à¤Î¥½¡¼¥¹¤ò´Þ¤à¥Õ¥¡¥¤¥ë¤Ï <tt>.tar.gz</tt> ¥Õ¥¡¥¤¥ë¤Î¤ß¤Ç¤¹¡£
-°ìÊý Debian °Ê³°¤Ç¤âÇÛÉÛ¤µ¤ì¤Æ¤¤¤ë¥Ñ¥Ã¥±¡¼¥¸¤Î¾ì¹ç¤Ï¡¢
-<tt>.orig.tar.gz</tt> ¥Õ¥¡¥¤¥ë¤Ë¤¤¤ï¤æ¤ë <em>upstream source code</em>
-¤ò¼ý¤á¤Þ¤¹¡£¤³¤ì¤Ï <em>upstream maintainer</em>
-(¤¿¤¤¤Æ¤¤¤Ï¤½¤Î¥½¥Õ¥È¥¦¥§¥¢¤Îºî¼Ô) ¤Ë¤è¤Ã¤ÆÇÛÉÛ¤µ¤ì¤Æ¤¤¤ë¥½¡¼¥¹¥³¡¼¥É¤Ç¤¹¡£
-¤³¤Î¾ì¹ç¡¢Debian ³«È¯¼Ô¤Ë¤è¤Ã¤Æ²Ã¤¨¤é¤ì¤¿Êѹ¹¤Ï
-<tt>.diff.gz</tt> ¥Õ¥¡¥¤¥ë¤Ë¼ý¤á¤é¤ì¤Þ¤¹¡£
- <p>
-<tt>.dsc</tt> ¥Õ¥¡¥¤¥ë¤Ë¤Ï¡¢¥½¡¼¥¹¥Ñ¥Ã¥±¡¼¥¸¤Î¥Õ¥¡¥¤¥ë°ìÍ÷¤ä¡¢
-¥Á¥§¥Ã¥¯¥µ¥à (<prgn>md5sums</prgn>)¡¢¥Ñ¥Ã¥±¡¼¥¸¤Ë´Ø¤¹¤ë¤¤¤¯¤é¤«¤ÎÄɲþðÊó
-(¥Ñ¥Ã¥±¡¼¥¸³«È¯¼Ô¤ä¥Ð¡¼¥¸¥ç¥ó¤Ê¤É) ¤¬¼ý¤á¤é¤ì¤Þ¤¹¡£
-
- <sect>¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¥Ç¥£¥ì¥¯¥È¥ê
- <p>
-Á°¾Ï¤ÇÀâÌÀ¤·¤¿¥Ç¥£¥ì¥¯¥È¥ê¥·¥¹¥Æ¥à¤Ï¡¢
-<em>distribution directories</em> ¤Ë´Þ¤Þ¤ì¤ë¤â¤Î¤Ç¤¹¡£
-Á´¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤Ï Debian ¥¢¡¼¥«¥¤¥Ö¤Î¥È¥Ã¥×¥ì¥Ù¥ë¥Ç¥£¥ì¥¯¥È¥ê
-¤Ë¤¢¤ë <tt>dists</tt> ¥Ç¥£¥ì¥¯¥È¥ê¤Ë¼ý¤á¤é¤ì¤Æ¤¤¤Þ¤¹¡£
-(¥È¥Ã¥×¥ì¥Ù¥ë¥Ç¥£¥ì¥¯¥È¥ê¤«¤é³Æ¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤ËÄ¥¤é¤ì¤Æ¤¤¤ë
-¥·¥ó¥Ü¥ê¥Ã¥¯¥ê¥ó¥¯¤Ï¡¢²¼°Ì¸ß´¹¤Î¤¿¤á¤Ë¤¢¤ë¤â¤Î¤Ç¡¢½ÅÍפʤâ¤Î¤Ç¤Ï¤¢¤ê¤Þ¤»¤ó¡£)
- <p>
-Í×Ì󤹤ì¤Ð¡¢Debian ¥¢¡¼¥«¥¤¥Ö¤Ï FTP
-¥µ¡¼¥Ð¤Ë¥ë¡¼¥È¥Ç¥£¥ì¥¯¥È¥ê¤ò»ý¤Ã¤Æ¤¤¤ë¤È¤¤¤¨¤Þ¤¹¡£
-Î㤨¤Ð¡¢¥ß¥é¡¼¥µ¥¤¥È <ftpsite>ftp.us.debian.org</ftpsite> ¤Ç¤Ï¡¢
-Debian ¥¢¡¼¥«¥¤¥ÖÁ´ÂÎ¤Ï <ftppath>/debian</ftppath>
-¤Ë¼ý¤á¤é¤ì¤Æ¤¤¤Þ¤¹¤¬¡¢¤½¤Î°ÌÃ֤϶¦Ä̤·¤Æ¤¤¤Þ¤¹¡£
-(<ftppath>/pub/debian</ftppath> ¤Ë¤¢¤ë¾ì¹ç¤â¤¢¤ê¤Þ¤¹¡£)
- <p>
-¼ÂºÝ¤Î¸Ä¡¹¤Î¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤Ï
-¤½¤Î¥¢¡¼¥«¥¤¥Ö¤Î¥ë¡¼¥È¤Ë¤¢¤ë
-<tt>dists</tt> ¥Ç¥£¥ì¥¯¥È¥ê¤Ë¼ý¤á¤é¤ì¤Æ¤¤¤Þ¤¹¡£
-°Ê²¼¤Ï¤½¤Î¥ì¥¤¥¢¥¦¥È¤Î³µÍפǤ¹¡£
- <p>
-<example>
-<var>archive root</var>/dists/<var>distribution</var>/<var>section</var>/<var>architecture</var>/<var>subsection</var>/<var>packages</var>
-</example>
-
-¤³¤Î¥ì¥¤¥¢¥¦¥È¤«¤é¿ä»¡¤·¤Æ¡¢
-<em>slink</em> ¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤Î i386 ¥Ù¡¼¥¹¥Ñ¥Ã¥±¡¼¥¸¤òõ¤¹¤Ë¤Ï
-<ftppath>/debian/dists/slink/main/binary-i386/base/</ftppath>
-¤ò¸«¤ì¤Ð¤¤¤¤¤³¤È¤¬Ê¬¤«¤ë¤Ç¤·¤ç¤¦¡£
-
-
- <sect1>°ÂÄêÈÇ¡¢³«È¯ÈÇ¡¢(»þ¤Ë) ¥Õ¥ê¡¼¥ºÈÇ
- <p>
-Debian ¤Î¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤Ë¤Ï (<tt>dists/stable</tt> ¤Ë¤¢¤ë)
-<em>stable</em> (°ÂÄêÈÇ) ¤È¸Æ¤Ð¤ì¤ë¤â¤Î¤È¡¢
-(<tt>dists/unstable</tt> ¤Ë¤¢¤ë)
-<em>unstable</em> (³«È¯ÈÇ)¤È¸Æ¤Ð¤ì¤ë¤â¤Î¤ÎÆó¤Ä¤¬¾ï¤Ë¸ºß¤·¤Þ¤¹¡£
-¤³¤Á¤é¤Ï Debian ¥×¥í¥¸¥§¥¯¥È¤Î³«È¯¥×¥í¥»¥¹¤òÈ¿±Ç¤·¤Æ¤¤¤Þ¤¹¡£
- <p>
-³èȯ¤Ê³«È¯¤Ï¡¢<em>unstable</em> ¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤Ç¹Ô¤Ê¤ï¤ì¤Þ¤¹¡£
-(¤½¤Î¤¿¤á¤³¤Î¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤Ï¤È¤¤Ë <em>development
-distribution</em> ¤È¤â¸Æ¤Ð¤ì¤Þ¤¹¡£)
-Á´ Debian ³«È¯¼Ô¤Ï¤¤¤Ä¤Ç¤â¡¢
-¤³¤Î¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤Ç¼«Ê¬¤Î¥Ñ¥Ã¥±¡¼¥¸¤ò¹¹¿·¤¹¤ë¤³¤È¤¬¤Ç¤¤Þ¤¹¡£
-¤½¤Î¤¿¤á¡¢¤³¤Î¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤ÎÆâÍƤÏÆü¤ËÆü¤ËÊѤï¤Ã¤Æ¤¤¤¤Þ¤¹¡£
-¤³¤Î¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤ÏÆÃÊ̤˥ƥ¹¥È¤µ¤ì¤Æ¤¤¤ë¤â¤Î¤Ç¤Ï¤Ê¤¤¤Î¤Ç¡¢
-»þ¤Ë¡ÖÉÔ°ÂÄê¡×¤Ê¤â¤Î¤Ç¤¹¡£
- <p>
-³«È¯´ü´Ö¤¬½ªÎ»¤¹¤ë¤È¡¢<em>unstable</em> ¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤Ï
-<em>frozen</em> ¤È¸Æ¤Ð¤ì¤ë¿·¤¿¤Ê¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¥Ç¥£¥ì¥¯¥È¥ê¤Ë
-¥³¥Ô¡¼¤µ¤ì¤Þ¤¹¡£
-¤³¤Î¸å¤Ï¡¢¥Ð¥°¥Õ¥£¥Ã¥¯¥¹¤ò½ü¤¯¤¤¤«¤Ê¤ëÊѹ¹¤â
-frozen ¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤ËÂФ·¤Æ¤Ï¤Ç¤¤Þ¤»¤ó¡£
-¤³¤Á¤é¤¬¡Ö¥Õ¥ê¡¼¥ºÈÇ frozen¡×¤È¸Æ¤Ð¤ì¤ë¤Î¤Ï¤½¤Î¤¿¤á¤Ç¤¹¡£
-°ì¥ö·î¤¢¤ë¤¤¤Ï¤â¤¦¤¹¤³¤·°Ê¾å·Ð¤Ä¤È¡¢
-<em>frozen</em> ¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤Ï
-<em>stable</em> ¤Ë̾Á°¤òÊѤ¨¤Þ¤¹¡£
-¸Å¤¤ <em>stable</em> ¤Ï¾å½ñ¤¤µ¤ì¡¢¤³¤Î»þÅÀ¤Ç¾Ãµî¤µ¤ì¤Þ¤¹¡£
- <p>
-¤³¤Î³«È¯¥µ¥¤¥¯¥ë¤Ï <em>unstable</em> ¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤¬¡¢
-<em>frozen</em> ¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤È¤·¤Æ¤Î¥Æ¥¹¥È´ü´Ö¤ò·Ð¤Æ¡¢
-<em>stable</em> ¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤Ë¤Ê¤ë¤È¤Î²¾Äê¤Ë´ð¤Å¤¤¤¿¤â¤Î¤Ç¤¹¡£
-¤¢¤ë¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤¬°ÂÄꤷ¤Æ¤¤¤ë¤È¸«¤Ê¤µ¤ì¤¿¤È¤·¤Æ¤â¡¢
-Æ󻰤ΥХ°¤Ïɬ¤º»Ä¤Ã¤Æ¤¤¤ë¤â¤Î¤Ç¤¹¡£
-<em>stable</em> ¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤¬»þ¡¹¹¹¿·¤µ¤ì¤ë¤Î¤Ï¤³¤Î¤¿¤á¤Ç¤¹¡£
-¤·¤«¤·¤Ê¤¬¤é¡¢¤³¤ì¤é¤Î¹¹¿·¤Ï¶Ë¤á¤ÆÃí°Õ¿¼¤¯¥Æ¥¹¥È¤µ¤ì¡¢
-¿·¤¿¤Ê¥Ð¥°¤ò»ý¤Á¹þ¤à´í¸±¤òÈò¤±¤Ê¤¬¤é¸Ä¡¹¤Ë¥¢¡¼¥«¥¤¥Ö¤ËƳÆþ¤µ¤ì¤Í¤Ð¤Ê¤ê¤Þ¤»¤ó¡£
-<em>stable</em> ¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤Ø¤ÎÄɲÿ侩¥Ñ¥Ã¥±¡¼¥¸¤Ï¡¢
-<tt>proposed-updates</tt> ¥Ç¥£¥ì¥¯¥È¥ê¤Ë¤¢¤ê¤Þ¤¹¡£
-¸¡ºº¤Ë¹ç³Ê¤·¤¿ <tt>proposed-updates</tt> ¤Ë¤¢¤ë¤³¤ì¤é¤Î¥Ñ¥Ã¥±¡¼¥¸¤Ï¡¢
-Äê´üŪ¤Ë¤Þ¤È¤á¤Æ <em>stable</em> ¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤Ë°ÜÆ°¤µ¤ì¡¢
-<em>stable</em> ¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤Î¥ê¥Ó¥¸¥ç¥ó¥ì¥Ù¥ë¤¬¾å¤²¤é¤ì¤Þ¤¹¡£
-(Î㤨¤Ð¡¢`1.3' ¤Ï `1.3r1' ¤Ë¡¢`2.0r2' ¤Ï `2.0r3' ¤È¤Ê¤Ã¤Æ¤¤¤¤Þ¤¹¡£)
- <p>
-¸Å¤¤ <em>unstable</em> ¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤¬ <em>frozen</em>
-¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤Ë°ÜÆ°¤µ¤ì¤ë¤È¡¢¿·¤¿¤Ê <em>unstable</em>
-¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤¬ºî¤é¤ì¤ë¤¿¤á¡¢``freeze'' ´ü´Ö¤Î´Ö¤â
-<em>unstable</em> ¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤Î³«È¯¤Ï³¤±¤é¤ì¤Þ¤¹¡£
-¤Þ¤¿Â¾¤ÎÊѹ¹ÅÀ¤È¤·¤Æ¤Ï¡¢<em>frozen</em> ¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤¬¸ø¼°¤Ë
-¥ê¥ê¡¼¥¹¤µ¤ì¤¿ºÝ¡¢Debian ¥¢¡¼¥«¥¤¥Ö¤«¤é¸Å¤¤ <em>stable</em>
-¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤¬ (<tt>&archive-host;</tt>
-¤Ë¤Ï»Ä¤µ¤ì¤Þ¤¹¤¬) ´°Á´¤Ë¾Ãµî¤µ¤ì¤ë¤³¤È¤¬¤¢¤²¤é¤ì¤Þ¤¹¡£
- <p>
-Í×Ì󤹤ì¤Ð¡¢¾ï¤Ë <em>stable</em> ¤ª¤è¤Ó <em>unstable</em>
-¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤¬ÍøÍѲÄǽ¤Ç¡¢
-»þ¡¹ <em>frozen</em> ¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤¬°ì¥ö·î¤«¤â¤·¤¯¤Ï¤½¤ì°Ê¾å¤Î´Ö
-ÀßÃÖ¤µ¤ì¤ë¤È¤¤¤¦¤³¤È¤Ç¤¹¡£
-
- <sect1>¼Â¸³ÈÇ
- <p>
-<em>experimental</em> ¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó (¼Â¸³ÈÇ) ¤Ï
-ÆÃÊ̤ʥǥ£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤Ç¤¹¡£
-¤³¤Á¤é¤Ï `stable' ¤ä `unstable' ¤È¤Ï°Û¤Ê¤ê¡¢
-´°Á´¤Ê¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤Ç¤Ï¤¢¤ê¤Þ¤»¤ó¡£
-¤³¤Á¤é¤Ï¤½¤ÎÂå¤ï¤ê¤Ë¡¢
-¤ª»È¤¤¤Î¥·¥¹¥Æ¥à¤òÇ˲õ¤·¤«¤Í¤Ê¤¤¶Ë¤á¤Æ¼Â¸³Åª¤Ê¥½¥Õ¥È¥¦¥§¥¢¤Î¤¿¤á¤Î¡¢
-°ì»þŪ¤ÊÀßÃÖÎΰè¤Ç¤¢¤ë¤³¤È¤ò°ÕÌ£¤·¤Þ¤¹¡£
-<em>experimental</em> ¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤«¤é¥Ñ¥Ã¥±¡¼¥¸¤ò
-¥À¥¦¥ó¥í¡¼¥É¤·¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ë¥æ¡¼¥¶¤Ï¡¢
-¤³¤Î¤³¤È¤ò½½Ê¬¤ËÃí°Õ¤¹¤Ù¤¤³¤È¤¬Ë¾¤Þ¤ì¤Þ¤¹¡£
-¤Ä¤Þ¤ê¡¢<em>experimental</em> ¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤ËÅÒ¤±¤ë¤³¤È¤Ï
-´Ö°ã¤Ã¤Æ¤¤¤ë¤È¤¤¤¦¤³¤È¤Ç¤¹¡£
- <p>
-<em>experimental</em> ¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤ÎÍøÍѤòÁªÂò¤¹¤ëºÝ¡¢
-³«È¯¼Ô¤Ï½½Ê¬¤ËÃí°Õ¤¹¤Ù¤¤Ç¤¹¡£
-¤â¤·¤¢¤ë¥Ñ¥Ã¥±¡¼¥¸¤¬¶Ë¤á¤ÆÉÔ°ÂÄê¤Ê¤â¤Î¤À¤Ã¤¿¤È¤·¤Æ¤â¡¢
-description (¥Ñ¥Ã¥±¡¼¥¸²òÀâʸ) ¤ËÆ󻰤ηٹð¤ò·ÇºÜ¤¹¤ë¤Ê¤É¤·¤Æ¡¢
-<em>unstable</em> ¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤Ë¥¢¥Ã¥×¥í¡¼¥É¤¹¤ëÊý¤¬¤è¤¤¤Ç¤·¤ç¤¦¡£
-¤·¤«¤·¤Ê¤¬¤é¡¢¥·¥¹¥Æ¥à¤Ë¶Ë¤á¤Æ¿¼¹ï¤Ê»³²¤òÍ¿¤¨¤«¤Í¤Ê¤¤¥½¥Õ¥È¥¦¥§¥¢¤Ë´Ø¤·¤Æ¤Ï¡¢
-<em>experimental</em> ¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤Ë¥¢¥Ã¥×¥í¡¼¥É¤¹¤ë¤Û¤¦¤¬
-ŬÀڤǤ·¤ç¤¦¡£
- <p>
-Î㤨¤Ð¼Â¸³Åª¤Ê°Å¹æ¥Õ¥¡¥¤¥ë¥·¥¹¥Æ¥à¤Ê¤É¤Ï¡¢¤ª¤½¤é¤¯
-<em>experimental</em> ¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¸þ¤¤Ç¤·¤ç¤¦¡£
-´°Á´¤Ë°Û¤Ê¤ëÀßÄê¤òÍѤ¤¤ë¿·¤·¤¤¥Ù¡¼¥¿ÈǤΥ½¥Õ¥È¥¦¥§¥¢¤Ê¤É¤â¡¢
-³«È¯¼Ô¤ÎºÛÎ̤ˤè¤ê¤Þ¤¹¤¬ <em>experimental</em>
-¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¸þ¤¤Ç¤·¤ç¤¦¡£
-¿·¤·¤¯¤Æ¤â¥·¥¹¥Æ¥à¤Ë»³²¤òÍ¿¤¨¤ë¤è¤¦¤Ê¤³¤È¤¬¤Ê¤¤¥½¥Õ¥È¥¦¥§¥¢¤Ï¡¢
-<em>unstable</em> ¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤Ë¥¢¥Ã¥×¥í¡¼¥É²Äǽ¤Ç¤¹¡£
-¤ª»È¤¤¤Î¥·¥¹¥Æ¥à¤Î¥¢¥Ã¥×¥°¥ì¡¼¥É¤¬ÉÔ´°Á´¤Ê¾ì¹ç¤ä¤½¤Î¾õ¶·¤¬Ê£»¨¤Ê¾ì¹ç¤Ï¡¢
-¥Æ¥¹¥¿¤¿¤Á¤¬ÍѰդ˥¢¥¯¥»¥¹¤Ç¤¤ë¤è¤¦¤Ë
-<em>experimental</em> ¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤ò
-°ì»þŪ¤ÊÎΰè¤È¤·¤ÆÍøÍѤ¹¤ë¤³¤È¤â¤Ç¤¤Þ¤¹¡£
- <p>
-¤·¤«¤·¤Ê¤¬¤é¡¢<em>experimental</em> ¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤ò
-¸Ä¿ÍŪ¤Ê°ì»þÎΰè¤È¤·¤ÆÍøÍѤ¹¤ë¤³¤È¤Ï¡¢¾ï¤Ë¤è¤¤¹Í¤¨¤Ç¤¢¤ë¤È¤Ï¸Â¤ê¤Þ¤»¤ó¡£
-¤½¤³¤ËÀßÃÖ¤·¤¿¥Õ¥¡¥¤¥ë¤ò¼«Ê¬¤ÇÃÖ¤´¹¤¨¤¿¤ê¹¹¿·¤·¤¿¤ê¤Ç¤¤Ê¤¤¤«¤é¤Ç¤¹¡£
-(<prgn>dinstall</prgn> ¤ä Debian ¥¢¡¼¥«¥¤¥Ö¥á¥ó¥Æ¥Ê¤¬¤½¤ì¤ò¹Ô¤Ê¤¤¤Þ¤¹¡£)
-¤µ¤é¤Ë¡¢¤½¤Î¥Ñ¥Ã¥±¡¼¥¸¤ò <em>unstable</em>
-¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤Ë¥¢¥Ã¥×¥í¡¼¥É¤·¤¿¾ì¹ç¤Ë¤Ï¡¢
-<em>experimental</em> ¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¾å¤«¤é¤½¤ì¤òºï½ü¤¹¤ë¤è¤¦
-¥¢¡¼¥«¥¤¥Ö¥á¥ó¥Æ¥Ê¤Ë°ÍÍꤹ¤ë¤³¤È¤ò³Ð¤¨¤Æ¤ª¤«¤Ê¤¯¤Æ¤Ï¤¤¤±¤Ê¤¤¤Ç¤·¤ç¤¦¡£
-Debian ¥¢¡¼¥«¥¤¥Ö¥á¥ó¥Æ¥Ê¤ÎÉéô¤ò¸º¤é¤¹¤¿¤á¤Ë¤â¡¢
-¤³¤Á¤é¤Ë´Ø¤·¤Æ¤Ï°ìÈÌŪ¤Ë <tt>va.debian.org</tt>
-¾å¤Ë¤¢¤ë¸Ä¿ÍÍÑ¥¦¥§¥Ö¥¹¥Ú¡¼¥¹¤òÍøÍѤ¹¤ë¤³¤È¤¬¤è¤êŬÀڤǤ¹¡£
-
- <sect id="codenames">¥ê¥ê¡¼¥¹¥³¡¼¥É̾
- <p>
-¥ê¥ê¡¼¥¹¤µ¤ì¤¿³Æ Debian ¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤Ë¤Ï <em>code name</em>
-¤¬ÉÕ¤±¤é¤ì¤Þ¤¹¡£
-Debian 1.1 ¤Ë¤Ï `buzz'¡¢Debian 1.2 ¤Ë¤Ï `rex'¡¢Debian 1.3 ¤Ë¤Ï `bo'¡¢
-Debian 2.0 ¤Ë¤Ï `hamm'¡¢Debian 2.1¤Ë¤Ï `slink'¡¢¤½¤·¤Æ Debian 2.2
-¤Ë¤Ï `potato' ¤È¤¤¤¦ <em>code name</em> ¤¬ÉÕ¤±¤é¤ì¤Æ¤¤¤Þ¤¹¡£
-¤Þ¤¿¡¢`sid' ¤È̾¤Å¤±¤é¤ì¤¿¡Ö²¾Áۥǥ£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¡×¤â¤¢¤ê¤Þ¤¹¡£
-¤³¤Á¤é¤Ë¤Ï¡¢Debian ¤Ë¤è¤Ã¤Æ¸ø¼°¤Ë¤Ï¥µ¥Ý¡¼¥È¤ª¤è¤Ó¥ê¥ê¡¼¥¹¤µ¤ì¤Æ¤¤¤Ê¤¤
-¥¢¡¼¥¥Æ¥¯¥Á¥ã¤Î¥Ñ¥Ã¥±¡¼¥¸¤¬¼ýÏ¿¤µ¤ì¤Þ¤¹¡£
-¤³¤ì¤é¤Î¥¢¡¼¥¥Æ¥¯¥Á¥ã¤Ï¡¢
-¾ÍèŪ¤Ë¤Ï¥á¥¤¥ó¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤ËÅý¹ç¤µ¤ì¤ë·×²è¤Ë¤¢¤ê¤Þ¤¹¡£
- <p>
-Debian ¤Ï¥ª¡¼¥×¥ó¤Ê³«È¯¥â¥Ç¥ë¤ò¼è¤Ã¤Æ¤¤¤ë¤Î¤Ç¡¢
-<em>unstable</em> ¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤Ç¤µ¤¨¤â
-Debian FTP¡¢HTTP ¥µ¡¼¥Ð¥Í¥Ã¥È¥ï¡¼¥¯¤«¤é¥¤¥ó¥¿¡¼¥Í¥Ã¥È·Ðͳ¤Ç
-ÇÛÉÛ¤µ¤ì¤Æ¤¤¤Þ¤¹¡£
-¤½¤Î¤¿¤á¡¢³«È¯¥Ð¡¼¥¸¥ç¥ó¤ò¼ýÏ¿¤·¤¿¥Ç¥£¥ì¥¯¥È¥ê¤Î̾Á°¤ò
-`unstable' ¤È¤·¤¿¤Ê¤é¤Ð¡¢¤½¤Î¥Ð¡¼¥¸¥ç¥ó¤ò¥ê¥ê¡¼¥¹¤¹¤ëºÝ¤Ë¤Ï¤½¤Î̾Á°¤ò
-`stable' ¤ËÊѹ¹¤·¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¤¬¡¢
-¤³¤Î¤³¤È¤Ë¤è¤Ã¤Æ FTP ¥ß¥é¡¼¤Ï¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥óÁ´ÂÎ
-(¤¹¤Ç¤Ë¶Ë¤á¤ÆµðÂç¤Ç¤¹!) ¤òºÆ¼èÆÀ¤·¤Ê¤±¤ì¤Ð¤Ê¤é¤Ê¤¯¤Ê¤ê¤Þ¤¹¡£
- <p>
-°ìÊý½é¤á¤«¤é¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¥Ç¥£¥ì¥¯¥È¥ê¤ò
-<em>Debian-x.y</em> ¤È¤·¤¿¤Ê¤é¤Ð¡¢Debian ¥ê¥ê¡¼¥¹ <em>x.y</em>
-¤¬ÍøÍѲÄǽ¤À¤È¼õ¤±»ß¤á¤é¤ì¤Æ¤·¤Þ¤¦¤Ç¤·¤ç¤¦¡£
-(²áµî¤Ë¤¢¤ë CD-ROM ¥Ù¥ó¥À¤¬¡¢pre-1.0 ³«È¯¥Ð¡¼¥¸¥ç¥ó¤ò¥Ù¡¼¥¹¤Ë
-Debian 1.0 CD-ROM ¤òºîÀ®¤·¤¿¤³¤È¤¬¤¢¤ê¤Þ¤·¤¿¡£
-Debian ºÇ½é¤Î¸ø¼°¥ê¥ê¡¼¥¹¤¬ 1.0 ¤Ç¤Ï¤Ê¤¯ 1.1 ¤À¤Ã¤¿¤Î¤Ï¤³¤Î¤¿¤á¤Ç¤·¤¿¡£)
-
- <p>
-¤½¤Î¤¿¤á¡¢¥¢¡¼¥«¥¤¥ÖÃæ¤Î¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¥Ç¥£¥ì¥¯¥È¥ê¤Î̾Á°¤Ï¡¢
-¤½¤Î¥ê¥ê¡¼¥¹¾õÂ֤ǤϤʤ¯ (`slink' ¤Î¤è¤¦¤Ê) ¥³¡¼¥É̾¤Ë¤è¤Ã¤ÆÄê¤á¤é¤ì¤Æ¤¤¤Þ¤¹¡£
-¤³¤ì¤é¤Î̾Á°¤Ï¡¢³«È¯´ü´ÖÃæ¤â¥ê¥ê¡¼¥¹¤Î¸å¤âƱ¤¸¤â¤Î¤Ë¤Ê¤Ã¤Æ¤ª¤ê¡¢
-Êѹ¹²Äǽ¤Ê¥·¥ó¥Ü¥ê¥Ã¥¯¥ê¥ó¥¯¤¬¡¢
-¸½¹Ô¤Î¥ê¥ê¡¼¥¹ºÑ¤ß°ÂÄê¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤ò»Ø¤·¼¨¤·¤Þ¤¹¡£
-¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¥Ç¥£¥ì¥¯¥È¥ê¤Î¼ÂÂÎ¤Ë <em>code names</em> ¤òÍѤ¤¡¢
-ŬÀڤʥê¥ê¡¼¥¹¥Ç¥£¥ì¥¯¥È¥ê¤ò»Ø¤¹¤¿¤á¤Ë <em>stable</em>¡¢<em>unstable</em>¡¢
-<em>frozen</em> ¤Ø¤Î¥·¥ó¥Ü¥ê¥Ã¥¯¥ê¥ó¥¯¤òÍѤ¤¤ë¤Î¤Ï¤³¤Î¤¿¤á¤Ç¤¹¡£
-
-
- <chapt id="upload">¥Ñ¥Ã¥±¡¼¥¸¤Î¥¢¥Ã¥×¥í¡¼¥É
-
- <sect>¿·µ¬¥Ñ¥Ã¥±¡¼¥¸¤Î¥¢¥Ê¥¦¥ó¥¹
- <p>
-Debian ¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥óÍѤ˿·¤¿¤Ê¥Ñ¥Ã¥±¡¼¥¸¤òºîÀ®¤·¤è¤¦¤È¹Í¤¨¤¿¤é¡¢
-¤Þ¤ººÇ½é¤Ë
-<url id="&url-wnpp;" name="Work-Needing and Prospective Packages (WNPP)">
-¤Î°ìÍ÷¤ò¥Á¥§¥Ã¥¯¤·¤Æ¤¯¤À¤µ¤¤¡£
-WNPP ¤ò¥Á¥§¥Ã¥¯¤¹¤ë¤³¤È¤Ë¤è¤Ã¤Æ¡¢
-¤Þ¤Àï¤â¤½¤Î¥½¥Õ¥È¥¦¥§¥¢¤Î¥Ñ¥Ã¥±¡¼¥¸¥ó¥°ºî¶È¤ò¹Ô¤Ê¤Ã¤Æ¤¤¤Ê¤¤¤³¤È¡¢
-ºî¶È¤¬½ÅÊ£¤·¤Æ¤¤¤Ê¤¤¤³¤È¤¬³Îǧ¤Ç¤¤Þ¤¹¡£
-¤¢¤Ê¤¿¤¬ºî¶È¤òͽÄꤷ¤Æ¤¤¤ë¥Ñ¥Ã¥±¡¼¥¸¤Ë¤Þ¤Àï¤â¼ê¤ò¤Ä¤±¤Æ¤¤¤Ê¤¤¤³¤È¤¬
-ʬ¤«¤Ã¤¿¤é¡¢¿·¤¿¤Ê¥Ñ¥Ã¥±¡¼¥¸ºîÀ®¤Ë´Ø¤¹¤ë¤¢¤Ê¤¿¤Î·×²è¤òÀâÌÀ¤¹¤ë¤¿¤á¤Ë
-´Ê·é¤ÊÅŻҥ᡼¥ë¤ò &email-debian-devel; °¸¤Æ¤ËÁ÷¤ê¤Þ¤¹¡£
-¤½¤ÎÅŻҥ᡼¥ë¤Î¥µ¥Ö¥¸¥§¥¯¥È¤Ï ``intent to package <var>foo</var>''
-¤È¤¹¤ë¤Ù¤¤Ç¤¹¡£
-<var>foo</var> ¤Î¤È¤³¤í¤Ë¤Ï¿·¤¿¤Ê¥Ñ¥Ã¥±¡¼¥¸¤Î̾Á°¤òÅö¤Æ¤Ï¤á¤Æ¤¯¤À¤µ¤¤
- <p>
-¤³¤Î¤è¤¦¤Ê¼ê½ç¤òƧ¤à¤³¤È¤ò³«È¯¼Ô¤Ë¤ª´ê¤¤¤¹¤ë¤Î¤Ï¡¢
-°Ê²¼¤Î¤è¤¦¤Ê¤¤¤¯¤Ä¤«¤ÎÍýͳ¤Î¤¿¤á¤Ç¤¹¡£
-
- <list compact>
- <item>
-¤³¤Î¼ê½ç¤Ï (ÀøºßŪ¤Ê¿·) ³«È¯¼Ô¤¬¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤Î¿Í¡¹¤Î·Ð¸³¤ËÍ¿¤ë½õ¤±¤Ë¤Ê¤ê¡¢
-¤Þ¤¿´û¤Ë狼¤¬ºî¶È¤·¤Æ¤¤¤¿¾ì¹ç¤½¤Î¿Í¤ËÏ¢Íí¤¹¤ë¤³¤È¤Ë¤â¤Ê¤ê¤Þ¤¹¡£
- <item>
-¤½¤Î¥Ñ¥Ã¥±¡¼¥¸¤Îºî¶È¤ò¹Í¤¨¤Æ¤¤¤¿Â¾¤Î¿Í¡¹¤Ë¡¢
-¤½¤Îºî¶È¤Î»Ö´ê¼Ô¤¬¤¤¤ë¤³¤È¤ä¤Þ¤¿¤½¤Îºî¶È¤ò¶¨Æ±¤·¤Æ¹Ô¤Ê¤¨¤ë¤³¤È¤ò
-ÃΤ餷¤á¤ë¤³¤È¤¬¤Ç¤¤Þ¤¹¡£
-&email-debian-devel; ¤Ø¤Î ``intent to package'' ¥á¥Ã¥»¡¼¥¸¤Ï WNPP
-¥á¥ó¥Æ¥Ê¤Ë¤è¤Ã¤Æ¼ý½¸¤µ¤ì¡¢¤½¤Î¿½¤·½Ð¤Ï WNPP ʸ½ñ¤Î²þÄûÈǤǸø³«¤µ¤ì¤Þ¤¹¡£
- <item>
-¾¤Î³«È¯¼Ô¤Ë¡¢¥Ñ¥Ã¥±¡¼¥¸°ì¹Ô²òÀâʸ¤ä¡¢
-ÉáḀ̈ǥե©¥ë¥È¤Ç <tt>debian-devel-changes</tt> ¤ËÅê¹Æ¤µ¤ì¤ë
-``Initial version'' ¤Î changelog ¥¨¥ó¥È¥ê
-¤è¤ê¤â¾Ü¤·¤¤¥Ñ¥Ã¥±¡¼¥¸¾ðÊó¤òÅÁ¤¨¤ë¤³¤È¤¬¤Ç¤¤Þ¤¹¡£
- <item>
-¤³¤Î¤³¤È¤Ï (¥Æ¥¹¥¿¤ÎÂè°ì¿Ø¤ò·ÁÀ®¤·¤Æ¤¤¤ë) ³«È¯ÈǤò¾ï»þ»È¤Ã¤Æ¤¤¤ë¿Í¡¹¤Ë
-ÌòΩ¤Á¤Þ¤¹¡£»ä¤¿¤Á¤Ï¤³¤Î¤è¤¦¤Ê¿Í¡¹¤ò¸ÝÉñ¤¹¤Ù¤¤Ç¤¹¡£
- <item>
-¤³¤Î¥¢¥Ê¥¦¥ó¥¹¤Ï¡¢³«È¯¼Ô¤ä´Ø¿´¤Î¹â¤¤Â¾¤Î¥°¥ë¡¼¥×¤ËÂФ·¤Æ¡¢
-Åö¥×¥í¥¸¥§¥¯¥È¤Ç¹Ô¤Ê¤ï¤ì¤Æ¤¤¤ë¤³¤È¡¢¿·¤·¤¯µ¯¤³¤Ã¤Æ¤¤¤ë¤³¤È¤Ë¤Ä¤¤¤Æ¤Î
-¤è¤ê¤è¤¤¹¥´¶¤ò¤â¤¿¤é¤·¤Þ¤¹¡£
- </list>
-
- <sect id="uploading">¥Ñ¥Ã¥±¡¼¥¸¤ò¥¢¥Ã¥×¥í¡¼¥É¤¹¤ë
-
- <sect1>changes ¥Õ¥¡¥¤¥ë¤ÎºîÀ®
- <p>
-Debian FTP ¥¢¡¼¥«¥¤¥Ö¤Ë¥Ñ¥Ã¥±¡¼¥¸¤ò¥¢¥Ã¥×¥í¡¼¥É¤¹¤ëºÝ¤Ë¤Ï¡¢
-¥¢¡¼¥«¥¤¥Ö¥á¥ó¥Æ¥Ê¤Ë¤½¤Î°·¤¤¤ò»Ø¼¨¤¹¤ë¤¿¤á¤Î
-<tt>.changes</tt> ¤òź¤¨¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¡£
-¤³¤Á¤é¤ÏÉáÄÌ¡¢Ä̾ï¤Î¥Ñ¥Ã¥±¡¼¥¸¹½ÃÛ¥×¥í¥»¥¹¤ÎºÇÃæ¤Ë
-<prgn>dpkg-genchanges</prgn> ¤Ë¤è¤Ã¤ÆÀ¸À®¤µ¤ì¤Þ¤¹¡£
- <p>
-¤³¤Î changes ¥Õ¥¡¥¤¥ë¤Ï°Ê²¼¤Î¥Õ¥£¡¼¥ë¥É¤ò¤â¤ÄÀ©¸æ¥Õ¥¡¥¤¥ë¤Ç¤¹¡£
- <p>
-&control-file-fields;
- <p>
-Debian ¥¢¥Ã¥×¥í¡¼¥É¤ÎºÝ¡¢¤³¤ì¤é¤Î¥Õ¥£¡¼¥ë¥É¤Ï¤¹¤Ù¤Æɬ¿Ü¤Ç¤¹¡£
-¤³¤ì¤é¤Î¥Õ¥£¡¼¥ë¥É¤ÎÆâÍƤˤĤ¤¤Æ¤Ï
-<!-- OBSOLETE, please update translation
-<url id="&url-pkg-manual;" name="Debian ¥Ñ¥Ã¥±¡¼¥¸¥ó¥°¥Þ¥Ë¥å¥¢¥ë"> -->
-¤ÎÀ©¸æ¥Õ¥£¡¼¥ë¥É¤Î°ìÍ÷¤ò¤´Í÷¤¯¤À¤µ¤¤¡£
-¤Þ¤¿¡¢<tt>Description</tt> ¥Õ¥£¡¼¥ë¥É¤òÍѤ¤¤ì¤Ð
-¼«Æ°Åª¤Ë¥Ð¥°¤ò¥¯¥í¡¼¥º¤¹¤ë¤³¤È¤¬²Äǽ¤Ç¤¹¡£
-¤³¤Á¤é¤Ë´Ø¤·¤Æ¤Ï <ref id="upload-bugfix"> ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£
-¤Ê¤ª¡¢¤³¤ÎÀá¤Ç¤Ï¥¢¡¼¥«¥¤¥Ö¥á¥ó¥Æ¥Ê¥ó¥¹¤Î¥Ý¥ê¥·¡¼¤Ë´Ø¤ï¤ë
-<tt>Distribution</tt> ¥Õ¥£¡¼¥ë¥É¤Î¤ß¤ò¼è¤ê¾å¤²¤Þ¤¹¡£
-
- <sect1 id="upload-dist">¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤ÎÁªÂò
- <p>
-¤È¤ê¤ï¤± <file>debian/changelog</file> ¥Õ¥¡¥¤¥ë¤«¤éÀ¸À®¤µ¤ì¤ë
-<tt>Distribution</tt> ¥Õ¥£¡¼¥ë¥É¤Ï¡¢
-¤½¤Î¥Ñ¥Ã¥±¡¼¥¸¤¬¤É¤Î¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¸þ¤±¤Î¤â¤Î¤Ê¤Î¤«¤ò¼¨¤·¤Þ¤¹¡£
-¤³¤Î¥Õ¥£¡¼¥ë¥É¤ÎÃͤˤϡ¢`stable'¡¢`unstable'¡¢`frozen'¡¢`experimental'
-¤Î»Í¤Ä¤¬Åö¤Æ¤Ï¤Þ¤ê¤¨¤Þ¤¹¡£
-¤Þ¤¿¤³¤ì¤é¤ÎÃͤÏÁȤ߹ç¤ï¤»¤ÆÅö¤Æ¤Ï¤á¤é¤ì¤ë¾ì¹ç¤â¤¢¤ê¤Þ¤¹¡£
-Î㤨¤Ð¡¢¶Ë¤á¤Æ½ÅÍפʥ»¥¥å¥ê¥Æ¥£¾å¤Î½¤Àµ¤ò»Ü¤·¤¿¥Ñ¥Ã¥±¡¼¥¸¤Î¥ê¥ê¡¼¥¹¤¬¤¢¤ê¡¢
-¤½¤Î¥Ñ¥Ã¥±¡¼¥¸¤¬ <em>stable</em> ¤ª¤è¤Ó <em>unstable</em>
-¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤ÎÁÐÊý¤ËɬÍפʤâ¤Î¤Ç¤¢¤Ã¤¿¤Ê¤é¤Ð¡¢
-<file>changelog</file> ¤Î <tt>Distribution</tt> ¥Õ¥£¡¼¥ë¥É¤Ë¤Ï
-`stable unstable' ¤ÈµÆþ¤·¤Þ¤¹¡£
-¤¢¤ë¤¤¤Ï¡¢Debian ¤¬¥Õ¥ê¡¼¥º¤µ¤ì¤Æ¤ª¤ê <em>frozen</em>
-¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤Ë¥Ð¥°½¤Àµ¥ê¥ê¡¼¥¹¤ò¼ýÏ¿¤·¤¿¤¤¾ì¹ç¤Ï¡¢
-¤½¤Î¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤Ï `frozen unstable' ¤È¤·¤Þ¤¹¡£
-(<em>frozen</em> ¤Ø¥¢¥Ã¥×¥í¡¼¥É¤¹¤ëºÝ¤Î¤è¤ê¾ÜºÙ¤Ê¾ðÊó¤Ë¤Ä¤¤¤Æ¤Ï
-<ref id="upload-frozen"> ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£)
-¤Ê¤ªÃí°Õ¤·¤Æ¤¤¤¿¤À¤¤¿¤¤¤Î¤Ç¤¹¤¬¡¢¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤ò
-`stable' ¤ËÀßÄꤹ¤ë¤³¤È¤Ï¡¢¼ÂºÝ¤Ë <em>stable</em>
-¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤Ë¼ýÏ¿¤µ¤ì¤ëÁ°¤Ë¡¢
-¤½¤Î¥Ñ¥Ã¥±¡¼¥¸¤¬¤µ¤é¤Ê¤ë¥Æ¥¹¥È¤Î¤¿¤á¤Ë Debian ¥¢¡¼¥«¥¤¥Ö¤Î
-<tt>proposed-updates</tt> ¥Ç¥£¥ì¥¯¥È¥ê¤Ë¼ýÏ¿¤µ¤ì¤ë¤³¤È¤ò°ÕÌ£¤·¤Æ¤¤¤Þ¤¹¡£
-¤Þ¤¿ <em>experimental</em> ¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤ò
-¾¤Î¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤ÈÁȤ߹ç¤ï¤»¤ë¤³¤È¤Ï¤Þ¤Ã¤¿¤¯°ÕÌ£¤¬¤¢¤ê¤Þ¤»¤ó¡£
-Ãí°Õ¤·¤Æ¤¯¤À¤µ¤¤¡£
- <p>
-ÆÃÄê¤Î¥¢¥Ã¥×¥¹¥È¥ê¡¼¥à¥Ð¡¼¥¸¥ç¥ó¤ËÂбþ¤¹¤ë¥Ð¡¼¥¸¥ç¥ó¤ò
-½é¤á¤Æ¥¢¥Ã¥×¥í¡¼¥É¤¹¤ëºÝ¤Ë¤Ï¡¢
-¥ª¥ê¥¸¥Ê¥ë¥½¡¼¥¹¤Î tar ¥Õ¥¡¥¤¥ë¤ò <tt>.changes</tt> ¥Õ¥¡¥¤¥ë¤òź¤¨¤Æ
-¥¢¥Ã¥×¥í¡¼¥É¤·¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¡£
-³¤¤¤Æ¿·¤·¤¤ diff ¤È <tt>.dsc</tt> ¥Õ¥¡¥¤¥ë¤òÀ¸À®¤¹¤ëºÝ¤Ë¤Ï¡¢
-¤³¤ì¤È¤Þ¤Ã¤¿¤¯Æ±¤¸ tar ¥Õ¥¡¥¤¥ë¤òÍѤ¤¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¤¬¡¢
-¤½¤ÎºÝ¤Ë¤Ï¤³¤Î tar ¥Õ¥¡¥¤¥ë¤ò¥¢¥Ã¥×¥í¡¼¥É¤¹¤ëɬÍפϤ¢¤ê¤Þ¤»¤ó¡£
- <p>
-Debian ¥½¡¼¥¹¥Ð¡¼¥¸¥ç¥óÈÖ¹æ¤Î¥ê¥Ó¥¸¥ç¥óÉôʬ¤¬ 0 ¤¢¤ë¤¤¤Ï 1 ¤Ç¤¢¤ë¤³¤È¤Ï¡¢
-¤½¤ì¤¬¿·¤¿¤Ê¥¢¥Ã¥×¥¹¥È¥ê¡¼¥à¥Ð¡¼¥¸¥ç¥ó¤Ç¤¢¤ë¤³¤È¤ò¼¨¤·¤Þ¤¹¤¬¡¢
-¤³¤Î¾ì¹ç (¤Î¤ß) <prgn>dpkg-genchanges</prgn> ¤È
-<prgn>dpkg-buildpackage</prgn> ¤Ï¡¢¥Ç¥Õ¥©¥ë¥È¤Ç¥ª¥ê¥¸¥Ê¥ë¥½¡¼¥¹¤Î
-tar ¥Õ¥¡¥¤¥ë¤ò¼ýÏ¿¤·¤Þ¤¹¡£
-¤³¤ÎÆ°ºî¤Ï¡¢¾ï¤Ë¤³¤Á¤é¤ò¼ýÏ¿¤¹¤ë¤Ë¤Ï <tt>-sa</tt> ¤ò¡¢
-¾ï¤Ë¤½¤ì¤ò̵»ë¤¹¤ë¤Ë¤Ï <tt>-sd</tt> ¤òÍѤ¤¤ë¤³¤È¤Ë¤è¤Ã¤Æ
-Êѹ¹¤¹¤ë¤³¤È¤¬¤Ç¤¤Þ¤¹¡£
- <p>
-¤¿¤À¡¢¥ª¥ê¥¸¥Ê¥ë¥½¡¼¥¹¤¬¤½¤Î¥¢¥Ã¥×¥í¡¼¥É¤Ë´Þ¤Þ¤ì¤Ê¤¤¾ì¹ç¤Ï¡¢
-¥¢¥Ã¥×¥í¡¼¥É¤¹¤ë <tt>.dsc</tt> ¥Õ¥¡¥¤¥ë¤È diff ¤òÀ¸À®¤¹¤ëºÝ¤Ë
-<prgn>dpkg-source</prgn> ¤¬ÍѤ¤¤ë¥ª¥ê¥¸¥Ê¥ë tar ¥Õ¥¡¥¤¥ë¤Ï¡¢
-¤¹¤Ç¤Ë¥¢¡¼¥«¥¤¥Ö¤Ë¤¢¤ë¤â¤Î¤È 1 ¥Ð¥¤¥È¤¿¤ê¤È¤â°ã¤ï¤Ê¤¤
-Ʊ°ì¤Î¤â¤Î¤Ç¤Ê¤±¤ì¤Ð<em>¤Ê¤ê¤Þ¤»¤ó</em>¡£
-¤Ê¤ª²¿¤é¤«¤ÎÆüì¤ÊÍýͳ¤¬¤¢¤ë¾ì¹ç¤Ï¡¢¤ª¤½¤é¤¯ <tt>-sa</tt> ¥Õ¥é¥°¤òÍѤ¤¤Æ¡¢
-¿·¤·¤¤¥Ð¡¼¥¸¥ç¥ó¤Î¥ª¥ê¥¸¥Ê¥ë¥½¡¼¥¹¤ò¥¢¥Ã¥×¥í¡¼¥É¤·¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¡£
-
- <sect2 id="upload-frozen"><em>frozen</em> ¤Ø¤Î¥¢¥Ã¥×¥í¡¼¥É
- <p>
-Debian ¥Õ¥ê¡¼¥º¤Ï Debian ¤Ë¤È¤Ã¤Æ½ÅÍפʴü´Ö¤Ç¤¹¡£
-¤³¤Î´ü´Ö¤Ï¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥óÁ´ÂΤòĴϤµ¤»°ÂÄê²½¤µ¤»¤ëµ¡²ñ¤Ê¤Î¤Ç¤¹¡£
-¤½¤ì¤æ¤¨¡¢<em>frozen</em> ¤Ø¥¢¥Ã¥×¥í¡¼¥É¤¹¤ëºÝ¤Ë¤ÏÃí°Õ¤òÍפ·¤Þ¤¹¡£
- <p>
-ºÇ¿·¤Î¥½¥Õ¥È¥¦¥§¥¢¤ò¾ï¤Ë¥ê¥ê¡¼¥¹¤Ë¼ýÏ¿¤¹¤ë¤È¤¤¤¦»î¤ß¤Ï¡¢
-Ì¥ÏÇŪ¤Ê¤³¤È¤Ç¤¹¡£
-¤·¤«¤·¤Ê¤¬¤é¡¢¥·¥¹¥Æ¥à¤¬Á´ÂΤȤ·¤Æ°ÂÄꤷ¡¢
-´üÂÔ¤·¤Æ¤¤¤ëÄ̤ê¤ËÆ°ºî¤¹¤ë¤³¤È¤ÎÊý¤¬¤è¤ê½ÅÍפʤ³¤È¤Ç¤¹¡£
- <p>
-<em>frozen</em> ¤Ø¤Î¥¢¥Ã¥×¥í¡¼¥É¤Î¥â¥Ã¥È¡¼¤Ï
-¡Ö<strong>¿·¤¿¤Ê¥³¡¼¥É¤ÏÆþ¤ì¤Ê¤¤</strong>¡×¤Ç¤¹¡£
-¤½¤Î´ð½à¤òÄê¤á¤ë¤³¤È¤ÏÆñ¤·¤¤¤³¤È¤Ç¤¹¤¬¡¢
-°Ê²¼¤Î¤è¤¦¤Ê¤¤¤¯¤Ä¤«¤Î¥¬¥¤¥É¥é¥¤¥ó¤¬¤¢¤ê¤Þ¤¹¡£
- <p>
-<list>
- <item>
-<em>critical</em>¡¢<em>grave</em> ¤È¤¤¤Ã¤¿¿¼¹ï¤Ê¥Ð¥°¤ä¡¢
-½ÅÍ×¤Ê <em>important</em> ¥Ð¥°¤Ê¤É¤Î½¤Àµ¤Ï¡¢ºÇ½ª¥ê¥ê¡¼¥¹»þ¤Ë
-¼ýÏ¿¤·¤Ê¤±¤ì¤Ð¤Ê¤é¤Ê¤¤¥Ñ¥Ã¥±¡¼¥¸¤ËÂФ·¤Æ¤Ï¾ï¤Ë²Äǽ¤Ç¤¹¡£
- <item>
-ɬ¤º¤·¤â¼ýÏ¿¤ÎɬÍפΤʤ¤¥Ñ¥Ã¥±¡¼¥¸¤ËÂФ·¤Æ¤Ï¡¢
-<em>critical</em> ¤ä¡¢<em>grave</em>¡¢<em>important</em>
-¤Ê¥Ð¥°¤Î½¤Àµ¤Ï¡¢¿·¤¿¤Êµ¡Ç½¤ò°ìÀÚÄɲ䷤ʤ¤¾ì¹ç¤Î¤ß²Äǽ¤Ç¤¹¡£
- <item>
-<em>normal</em> ¥Ð¥°¤Î½¤Àµ¤Ï (¿ä¾©¤Ï¤µ¤ì¤Þ¤»¤ó¤¬)
-¿·¤¿¤Êµ¡Ç½¤òÄɲ䷤ʤ¤¾ì¹ç (¤Î¤ß) ²Äǽ¤Ç¤¹¡£
- <item>
-<em>wishlist</em> ¤Ë´Ø¤¹¤ë½¤Àµ¤Ï¤Ç¤¤Þ¤»¤ó¡£
-(¤½¤ì¤Ï·ë¶É¤Î¤È¤³¤í¥Ð¥°¤Ç¤Ï¤Ê¤¤¤«¤é¤Ç¤¹¡£)
- <item>
-ʸ½ñ¤¬Í¥¤ì¤Æ¤¤¤ë¤³¤È¤Ï½ÅÍפǤ¹¤«¤é¡¢Ê¸½ñ¤Ë´Ø¤¹¤ë¥Ð¥°½¤Àµ¤Ï²Äǽ¤Ç¤¹¡£
- </list>
- <p>
-¿·¤¿¤Ê¥Ð¥°¤ò¾·¤¤¤Æ¤·¤Þ¤¦²ÄǽÀ¤¬¡¢¤É¤ó¤Ê¥Ð¥°½¤Àµ¤Ë¤Ç¤â
-Åý·×Ū¤Ë 15% ¤Ï¤¢¤ë¤³¤È¤ò¿´¤Ëα¤á¤Æ¤ª¤¤¤Æ¤¯¤À¤µ¤¤¡£
-¿·¤¿¤Ê¥Ð¥°¤Îº®Æþ¤äȯ¸«¤Ï¡¢¥ê¥ê¡¼¥¹¤òÃ٤餻¤¿¤ê¡¢
-ºÇ½ªÅª¤Ê¥×¥í¥À¥¯¥È¤ÎÉʼÁ¤òÄã²¼¤µ¤»¤¿¤ê¤¹¤ë¤Î¤Ç¤¹¡£
-¸µ¡¹¤Î¥Ð¥°¤Î½ÅÂ礵¤È¿·¤¿¤Ëº®Æþ¤·¤¿¥Ð¥°¤Î½ÅÂ礵¤È¤Î´Ö¤Ë¡¢
-Áê´Ø´Ø·¸¤Ï¤Û¤È¤ó¤É¤¢¤ê¤Þ¤»¤ó¡£
-
- <sect1 id="upload-checking">¥¢¥Ã¥×¥í¡¼¥É¤ÎÁ°¤Ë¥Ñ¥Ã¥±¡¼¥¸¤ò¥Á¥§¥Ã¥¯¤¹¤ë
- <p>
-¤¢¤Ê¤¿¤Î¥Ñ¥Ã¥±¡¼¥¸¤ò¥¢¥Ã¥×¥í¡¼¥É¤¹¤ëÁ°¤Ë¡¢
-¤½¤ì¤ËÂФ·¤Æ´ðËÜŪ¤Ê¥Æ¥¹¥È¤ò¹Ô¤Ê¤¦¤Ù¤¤Ç¤¹¡£
-ɬ¤º°Ê²¼¤Îºî¶È¤ò¹Ô¤Ê¤¦¤è¤¦¤Ë¤·¤Æ¤¯¤À¤µ¤¤¡£
-(¸½¹Ô¤Î Debian ¥Ñ¥Ã¥±¡¼¥¸¤¬¤¢¤ì¤Ð¡¢¤½¤Î¸Å¤¤¥Ð¡¼¥¸¥ç¥ó¤âɬÍפˤʤë¤Ç¤·¤ç¤¦¡£)
-<list>
- <item>
-¥Ñ¥Ã¥±¡¼¥¸¤ò¥¤¥ó¥¹¥È¡¼¥ë¤·¡¢
-¤½¤Î¥½¥Õ¥È¥¦¥§¥¢¤¬Æ°ºî¤¹¤ë¤«¤É¤¦¤«¤ò³Îǧ¤·¤Æ¤¯¤À¤µ¤¤¡£
-¤Þ¤¿¡¢¤¹¤Ç¤Ë¤½¤Î Debian ¥Ñ¥Ã¥±¡¼¥¸¤¬Â¸ºß¤¹¤ë¾ì¹ç¤Ï¡¢
-¤½¤Î¥Ñ¥Ã¥±¡¼¥¸¤ò¸Å¤¤¥Ð¡¼¥¸¥ç¥ó¤«¤éºîÀ®¤·¤¿¿·¤·¤¤¥Ð¡¼¥¸¥ç¥ó¤Ë
-¥¢¥Ã¥×¥°¥ì¡¼¥É¤·¤Æ¤ß¤Æ¤¯¤À¤µ¤¤¡£
- <item>
-¤½¤Î¥Ñ¥Ã¥±¡¼¥¸¤ËÂФ·¤Æ <prgn>lintian</prgn> ¤ò¼Â¹Ô¤·¤Æ¤¯¤À¤µ¤¤¡£
-<prgn>lintian</prgn> ¤Ï¡¢
-<tt>lintian -v <var>package-version</var>.changes</tt>
-¤È¤·¤Æ¼Â¹Ô¤·¤Þ¤¹¡£
-¤³¤Á¤é¤Ï¡¢¥Ð¥¤¥Ê¥ê¥Ñ¥Ã¥±¡¼¥¸¤â¥½¡¼¥¹¥Ñ¥Ã¥±¡¼¥¸¤â¥Á¥§¥Ã¥¯¤·¤Þ¤¹¡£
-<prgn>lintian</prgn> ¤¬À¸À®¤¹¤ë½ÐÎϤ¬Íý²ò¤Ç¤¤Ê¤¤¾ì¹ç¤Ï¡¢
-<tt>-i</tt> ¥¹¥¤¥Ã¥Á¤òÄɲ䷤Ƥ´Í÷¤¯¤À¤µ¤¤¡£
-¤³¤¦¤¹¤ì¤Ð <prgn>lintian</prgn> ¤Ï¡¢
-¤½¤Î¥×¥í¥°¥é¥à¤Ë´Ø¤¹¤ëÂçÊѾéĹ¤Ê²òÀâ¤ò½ÐÎϤ·¤Þ¤¹¡£
- <p>
-<prgn>lintian</prgn> ¤¬¥¨¥é¡¼¤ò½Ð¤·¤¿¾ì¹ç
-(¤½¤Î¹Ô¤Ï <tt>E</tt> ¤«¤é»Ï¤Þ¤ê¤Þ¤¹)¡¢
-Ä̾ï¤Ï¤½¤Î¥Ñ¥Ã¥±¡¼¥¸¤ò¥¢¥Ã¥×¥í¡¼¥É¤¹¤Ù¤¤Ç¤Ï<em>¤¢¤ê¤Þ¤»¤ó</em>¡£
- <p>
-<prgn>lintian</prgn> ¤Ë´Ø¤¹¤ë¤è¤ê¾ÜºÙ¤Ê¾ðÊó¤Ë¤Ä¤¤¤Æ¤Ï
-<ref id="lintian"> ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£
- <item>
-¤½¤Î¥Ñ¥Ã¥±¡¼¥¸¤ò (¤â¤·Â¸ºß¤¹¤ì¤Ð)
-°ÊÁ°¤Î¥Ð¡¼¥¸¥ç¥ó¤Ë¥À¥¦¥ó¥°¥ì¡¼¥É¤·¤Æ¤ß¤Æ¤¯¤À¤µ¤¤¡£
--- ¤³¤Á¤é¤Ï <tt>postrm</tt> ¤ª¤è¤Ó <tt>prerm</tt>
-¥¹¥¯¥ê¥×¥È¤Î¥Æ¥¹¥È¤Ë¤Ê¤ê¤Þ¤¹¡£
- <item>
-¤½¤Î¥Ñ¥Ã¥±¡¼¥¸¤òºï½ü¤·¡¢¤½¤ì¤òºÆ¥¤¥ó¥¹¥È¡¼¥ë¤·¤Æ¤ß¤Æ¤¯¤À¤µ¤¤¡£
- </list>
-
- <sect1 id="upload-master"><tt>master</tt> ¤Ø¤Î¥¢¥Ã¥×¥í¡¼¥É
- <p>
-¥Ñ¥Ã¥±¡¼¥¸¤ò¥¢¥Ã¥×¥í¡¼¥É¤¹¤ë¤¿¤á¤Ë¤Ï¡¢
-<ftpsite>master.debian.org</ftpsite> ¤Ë¸Ä¿Í¥¢¥«¥¦¥ó¥È¤¬É¬ÍפǤ¹¡£
-³«È¯¼Ô¤Ï¤¹¤Ç¤ËÁ´°÷¤³¤Î¥¢¥«¥¦¥ó¥È¤ò»ý¤Ã¤Æ¤¤¤ë¤Ï¤º¤Ç¤¹¡£
-¤³¤Á¤é¤Ë´Ø¤·¤Æ¤Ï <ref id="servers-master"> ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£
-¤½¤Î¥Õ¥¡¥¤¥ë·²¤òžÁ÷¤¹¤ë¤Ë¤Ï <prgn>scp</prgn> ¤È <prgn>ftp</prgn>
-¤Î¤¤¤º¤ì¤âÍøÍѤǤ¤Þ¤¹¡£
-
-¤É¤Á¤é¤ò»È¤¦¾ì¹ç¤Ç¤â¡¢¤½¤Î¥Õ¥¡¥¤¥ë·²¤Ï
-<url id="&url-upload-samosa;"> ¤ËÀßÃÖ¤¹¤ëɬÍפ¬¤¢¤ê¤Þ¤¹¡£
-ƿ̾ FTP ¤òÍøÍѤ·¤Æ master ¾å¤Î Incoming
-¤Ë¥¢¥Ã¥×¥í¡¼¥É¤¹¤ë¤³¤È¤Ï¤Ç¤¤Þ¤»¤ó¡£
--- ¤¢¤Ê¤¿¤Î¥æ¡¼¥¶Ì¾¤È¥Ñ¥¹¥ï¡¼¥É¤ò»È¤ï¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¡£)
- <p>
-<em>Ãí°Õ:</em> ¥¢¥á¥ê¥«¹ç½°¹ñÀ¯Éܤˤè¤Ã¤ÆÍ¢½Ðµ¬À©¤µ¤ì¤Æ¤¤¤ë¥½¥Õ¥È¥¦¥§¥¢¤ò
-¥Ñ¥Ã¥±¡¼¥¸¤¬´Þ¤à¾ì¹ç¤Ï¡¢¤½¤ì¤ò <tt>master</tt> ¤ä¡¢³¤³°¤Ë¤¢¤ë
-<tt>chiark</tt> ¤ä <tt>erlangen</tt> ¤Î¥¢¥Ã¥×¥í¡¼¥É¥¥å¡¼¤Ë¤Ï
-¥¢¥Ã¥×¥í¡¼¥É¤·¤Ê¤¤¤Ç¤¯¤À¤µ¤¤¡£
-¤³¤Îµ¬À©¤Ï¡¢¤Û¤Ü¤¹¤Ù¤Æ¤Î°Å¹æ¥½¥Õ¥È¥¦¥§¥¢¤ä¡¢
-»þ¤Ë¤ÏPGP °Å¹æ¤ª¤è¤Óǧ¾Ú¤ò¥µ¥Ý¡¼¥ÈÅŻҥ᡼¥ë¥ê¡¼¥À¤Î¤è¤¦¤Ê
-°Å¹æ¥½¥Õ¥È¥¦¥§¥¢¤ò¡ÖÍøÍѤ¹¤ë¡×¥½¥Õ¥È¥¦¥§¥¢¤Ë¤âµÚ¤Ó¤Þ¤¹¡£
-¤³¤Î¤è¤¦¤Ê¥½¥Õ¥È¤Î¥¢¥Ã¥×¥í¡¼¥É¤Ï <tt>non-us</tt> ¤Ë¹Ô¤Ê¤Ã¤Æ¤¯¤À¤µ¤¤¡£
-(<ref id="upload-non-us"> ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£)
-¥¢¥á¥ê¥«¹ç½°¹ñ¤ÎÍ¢½Ðµ¬À©¤¬¤¢¤Ê¤¿¤Î¥Ñ¥Ã¥±¡¼¥¸¤ËŬÍѤµ¤ì¤ë¤«¤É¤¦¤«
-¤Ï¤Ã¤¤ê¤·¤Ê¤¤¾ì¹ç¤Ï¡¢&email-debian-devel;
-¤Ë¥á¥Ã¥»¡¼¥¸¤òÅê¹Æ¤·¼ÁÌ䤷¤Æ¤¯¤À¤µ¤¤¡£
- <p>
-¤Þ¤¿¡¢¥Ñ¥Ã¥±¡¼¥¸¤ò¥¢¥Ã¥×¥í¡¼¥É¤¹¤ëºÝ¡¢
-Debian package <package>dupload</package>
-¤¬ÊØÍø¤Ê¤³¤È¤Ë¤ªµ¤¤Å¤¤Ë¤Ê¤ë¤Ç¤·¤ç¤¦¡£
-¤³¤ÎÊØÍø¤Ê¥×¥í¥°¥é¥à¤Ï¡¢¥Ç¥Õ¥©¥ë¥È¤Ç
-<prgn>ftp</prgn> ¤ò·Ðͳ¤· <tt>master</tt> ¤ä¡¢<tt>chiark</tt>¡¢
-<tt>erlangen</tt> ¤Ø¤Î¥¢¥Ã¥×¥í¡¼¥É¤¬¤Ç¤¤ë¤è¤¦¤Ë¤Ê¤Ã¤Æ¤¤¤Þ¤¹¡£
-¤³¤Á¤é¤Ï <prgn>ssh</prgn> ¤òÍøÍѤ¹¤ë¤è¤¦¤ËÀßÄꤹ¤ë¤³¤È¤â¤Ç¤¤Þ¤¹¡£
-¤è¤ê¾ÜºÙ¤Ê¾ðÊó¤Ë¤Ä¤¤¤Æ¤Ï <manref name="dupload" section="1"> ¤È
-<manref name="dupload" section="5"> ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£
-
- <sect1 id="upload-non-us"><tt>pandora</tt> (non-us) ¤Ø¤Î¥¢¥Ã¥×¥í¡¼¥É
- <p>
-Á°½Ò¤ÎÄ̤ꡢ͢½Ðµ¬À©¤µ¤ì¤Æ¤¤¤ë¥½¥Õ¥È¥¦¥§¥¢¤Ï
-<tt>master</tt> ¤Ë¥¢¥Ã¥×¥í¡¼¥É¤·¤Æ¤Ï¤¤¤±¤Þ¤»¤ó¡£
-¤½¤ÎÂå¤ï¤ê¤Ë Èóƿ̾ FTP ¤« <prgn>scp</prgn> ¤ò»È¤Ã¤Æ¡¢
-¥Ñ¥Ã¥±¡¼¥¸¤ò <ftpsite>pandora.debian.org</ftpsite> ¤Ë¥³¥Ô¡¼¤·¡¢
-¤½¤Î¥Õ¥¡¥¤¥ë·²¤ò &non-us-upload-dir; ¤ËÀßÃÖ¤·¤Æ¤¯¤À¤µ¤¤¡£
-¥Ç¥Õ¥©¥ë¥È¤Ç <tt>master</tt> ¤ÈƱ¤¸¥¢¥«¥¦¥ó¥È¤¬»È¤¨¤Þ¤¹¡£
- <p>
-<prgn>dupload</prgn> ¥×¥í¥°¥é¥à¤Ï <tt>pandora</tt>
-¤Ø¤Î¥¢¥Ã¥×¥í¡¼¥É¤ò¥µ¥Ý¡¼¥È¤·¤Æ¤¤¤Þ¤¹¡£
-¾ÜºÙ¤Ï¥×¥í¥°¥é¥àÉÕ°¤Î¥É¥¥å¥á¥ó¥È¤ò»²¾È¤·¤Æ¤¯¤À¤µ¤¤¡£
-
- <sect1><tt>chiark</tt> ·Ðͳ¤Î¥¢¥Ã¥×¥í¡¼¥É
- <p>
-<tt>master</tt> ¤Ø¤Î¥Í¥Ã¥È¥ï¡¼¥¯Àܳ¤¬ÃÙ¤¤¾ì¹ç¡¢
-¤½¤ÎÂå¤ï¤ê¤È¤Ê¤ë¤â¤Î¤¬¤¢¤ê¤Þ¤¹¡£
-¤½¤Î°ì¤Ä¤¬¡¢<tt>chiark</tt> ¾å¤Ë¤¢¤ë¥è¡¼¥í¥Ã¥Ñ¤Î¥¢¥Ã¥×¥í¡¼¥É¥¥å¡¼·Ðͳ¤Ç
-<tt>Incoming</tt> ¤Ë¥Õ¥¡¥¤¥ë·²¤ò¥¢¥Ã¥×¥í¡¼¥É¤¹¤ëÊýË¡¤Ç¤¹¡£
-¤½¤Î¾ÜºÙ¤Ë¤Ä¤¤¤Æ¤Ï <url id="&url-chiark-readme;"> ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£
- <p>
-<em>Ãí°Õ:</em>¥¢¥á¥ê¥«¹ç½°¹ñÀ¯Éܤˤè¤Ã¤ÆÍ¢½Ðµ¬À©¤µ¤ì¤Æ¤¤¤ë
-¥½¥Õ¥È¥¦¥§¥¢¤ò´Þ¤à¥Ñ¥Ã¥±¡¼¥¸¤ò <tt>chiark</tt>
-¤Î¥¥å¡¼¤Ë¥¢¥Ã¥×¥í¡¼¥É¤·¤Ê¤¤¤Ç¤¯¤À¤µ¤¤¡£
-¤³¤Î¥¢¥Ã¥×¥í¡¼¥É¥¥å¡¼¤Ï <tt>master</tt> ¤Ë¸þ¤±¤é¤ì¤¿¤â¤Î¤Ç¤¹¤Î¤Ç¡¢
-<ref id="upload-master"> ¤ÇÀâÌÀ¤·¤¿Ë¡µ¬¤¬¤³¤³¤Ç¤âƱÍͤËŬÍѤµ¤ì¤Þ¤¹¡£
- <p>
-<prgn>dupload</prgn> ¥×¥í¥°¥é¥à¤Ï <tt>chiark</tt>
-¤Ø¤Î¥¢¥Ã¥×¥í¡¼¥É¤ò¥µ¥Ý¡¼¥È¤·¤Æ¤¤¤Þ¤¹¡£
-¾ÜºÙ¤Ï¥×¥í¥°¥é¥àÉÕ°¤Î¥É¥¥å¥á¥ó¥È¤ò»²¾È¤·¤Æ¤¯¤À¤µ¤¤¡£
-
- <sect1><tt>erlangen</tt> ·Ðͳ¤Î¥¢¥Ã¥×¥í¡¼¥É
- <p>
-¾¤Ë¤â¥É¥¤¥Ä¤Ë¤¢¤ë¥¢¥Ã¥×¥í¡¼¥É¥¥å¡¼¤¬ÍøÍѤǤ¤Þ¤¹¡£
-ƿ̾ FTP ·Ðͳ¤Ç <url id="&url-upload-erlangen;">
-¤Ë¥Õ¥¡¥¤¥ë·²¤ò¥¢¥Ã¥×¥í¡¼¥É¤·¤Æ¤¯¤À¤µ¤¤¡£
- <p>
-¤½¤Î¥¢¥Ã¥×¥í¡¼¥É¤Ï¡¢
-<tt>master</tt> ¤Î <tt>Incoming</tt> ¤Ø¤Î¥¢¥Ã¥×¥í¡¼¥É¤ÈƱ¤¸¤è¤¦¤Ë¡¢
-´°Á´¤Ê Debian ¥¢¥Ã¥×¥í¡¼¥É¤Ç¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¡£
-¤Ä¤Þ¤ê¡¢<tt>.changes</tt> ¥Õ¥¡¥¤¥ë¤Ç¿¨¤ì¤Æ¤¤¤ë¾¤Î¥Õ¥¡¥¤¥ë¤òź¤¨¤Æ
-<tt>.changes</tt> ¥Õ¥¡¥¤¥ë¤ò¥¢¥Ã¥×¥í¡¼¥É¤·¤Þ¤¹¡£
-¤½¤Î¥¥å¡¼¥Ç¡¼¥â¥ó¤Ï <tt>.changes</tt> ¤¬ Debian ³«È¯¼Ô¤Ë¤è¤Ã¤Æ
-Àµ¤·¤¯ PGP ½ð̾¤µ¤ì¤Æ¤¤¤ë¤«¤É¤¦¤«¤ò¥Á¥§¥Ã¥¯¤·¡¢
-ÉÔÀµ¤Ê¥Õ¥¡¥¤¥ë¤Ï¤½¤Î¥¥å¡¼·Ðͳ¤Ç¤Ï <tt>master</tt> ¤ØžÁ÷¤·¤Þ¤»¤ó¡£
-<tt>.changes</tt> ¤Î <tt>Maintainer</tt> ¥Õ¥£¡¼¥ë¥É¤Ë¡¢
-<em>¤¢¤Ê¤¿</em>¤ÎÅŻҥ᡼¥ë¥¢¥É¥ì¥¹¤¬¤¢¤ë¤«¤É¤¦¤«¤â³Îǧ¤·¤Æ¤¯¤À¤µ¤¤¡£
-¤½¤³¤Ëµ½Ò¤µ¤ì¤¿¥¢¥É¥ì¥¹¤Ï
-<tt>master</tt> ¤ÈƱÍͤ¢¤é¤æ¤ë¥ê¥×¥é¥¤¤Ë»ÈÍѤµ¤ì¤Þ¤¹¡£
- <p>
-<tt>chiark</tt> ¤ÈƱÍͤˡ¢¥¢¥Ã¥×¥í¡¼¥É¤Î¤¢¤È¤¢¤Ê¤¿¤Î¥Õ¥¡¥¤¥ë¤ò
-¥»¥«¥ó¥É¥Ç¥£¥ì¥¯¥È¥ê¤Ë°ÜÆ°¤¹¤ëɬÍפϤ¢¤ê¤Þ¤»¤ó¡£
-¤Þ¤¿¡¢¤É¤ó¤Ê¾ì¹ç¤Ç¤â¥¢¥Ã¥×¥í¡¼¥É¤¬¤É¤¦¤Ê¤Ã¤¿¤«¤Ë¤Ä¤¤¤Æ¡¢
-¥¥å¡¼¥Ç¡¼¥â¥ó¤«¤éÊÖ¿®¥á¡¼¥ë¤ò¼õ¤±¼è¤ë¤Ï¤º¤Ç¤¹¡£
-¤¢¤Ê¤¿°¸¤Æ¤Ë¥¨¥é¡¼¤¬ÄÌÃΤµ¤ì¤Ê¤¤¸Â¤ê
-¤ª¤½¤é¤¯¤³¤Á¤é¤â <tt>master</tt> ¤Ø°ÜÆ°¤µ¤ì¤ë¤Ï¤º¤Ç¤¹¡£
- <p>
-<em>Ãí°Õ:</em>¥¢¥á¥ê¥«¹ç½°¹ñÀ¯Éܤˤè¤Ã¤ÆÍ¢½Ðµ¬À©¤µ¤ì¤Æ¤¤¤ë
-¥½¥Õ¥È¥¦¥§¥¢¤ò´Þ¤à¥Ñ¥Ã¥±¡¼¥¸¤ò <tt>erlangen</tt>
-¤Î¥¥å¡¼¤Ë¥¢¥Ã¥×¥í¡¼¥É¤·¤Ê¤¤¤Ç¤¯¤À¤µ¤¤¡£
-¤³¤Î¥¢¥Ã¥×¥í¡¼¥É¥¥å¡¼¤Ï <tt>master</tt> ¤Ë¸þ¤±¤é¤ì¤¿¤â¤Î¤Ç¤¹¤Î¤Ç¡¢
-<ref id="upload-master"> ¤ÇÀâÌÀ¤·¤¿Ë¡µ¬¤¬¤³¤³¤Ç¤âƱÍͤËŬÍѤµ¤ì¤Þ¤¹¡£
- <p>
-<prgn>dupload</prgn> ¥×¥í¥°¥é¥à¤Ï <tt>erlangen</tt>
-¤Ø¤Î¥¢¥Ã¥×¥í¡¼¥É¤ò¥µ¥Ý¡¼¥È¤·¤Æ¤¤¤Þ¤¹¡£
-¾ÜºÙ¤Ï¥×¥í¥°¥é¥àÉÕ°¤Î¥É¥¥å¥á¥ó¥È¤ò»²¾È¤·¤Æ¤¯¤À¤µ¤¤¡£
-
- <sect1>¾¤Î¥¢¥Ã¥×¥í¡¼¥É¥¥å¡¼
- <p>
-¥¢¥á¥ê¥«¹ç½°¹ñ¤Ë¤¢¤ë¾¤Î¥¢¥Ã¥×¥í¡¼¥É¥¥å¡¼¤âÍøÍѤǤ¤Þ¤¹¡£
-¤³¤Á¤é¤Ï <tt>master</tt> ¤ËÀܳ¤Ç¤¤Ê¤¤ÌäÂ꤬ȯÀ¸¤·¤¿ºÝ¤Î
-Í¥¤ì¤¿¥Ð¥Ã¥¯¥¢¥Ã¥×¼êÃʤǤ¹¡£
-<tt>erlangen</tt> ¤ÈƱÍÍ¤Ë <url id="&url-upload-samosa;">
-¤Ë¥Õ¥¡¥¤¥ë·²¤ò¥¢¥Ã¥×¥í¡¼¥É¤¹¤ë¤³¤È¤¬¤Ç¤¤Þ¤¹¡£
- <p>
-ÆüËܤǤ⥢¥Ã¥×¥í¡¼¥É¥¥å¡¼¤¬ÍøÍѤǤ¤Þ¤¹¡£<url id="&url-upload-jp;">
-¤Ø¤Îƿ̾ FTP ·Ðͳ¤Ç¥Õ¥¡¥¤¥ë·²¤ò¥¢¥Ã¥×¥í¡¼¥É¤·¤Æ¤¯¤À¤µ¤¤¡£
-
- <sect id="upload-announce">¥Ñ¥Ã¥±¡¼¥¸¥¢¥Ã¥×¥í¡¼¥É¤Î¥¢¥Ê¥¦¥ó¥¹
- <p>
-¥Ñ¥Ã¥±¡¼¥¸¤ò¥¢¥Ã¥×¥í¡¼¥É¤·¤¿¤é¡¢
-¤½¤Î¥¢¥Ê¥¦¥ó¥¹¤ò``debian-changes''
-¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤Î°ì¤Ä¤ËÅê¹Æ¤·¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¡£
-¤½¤Î¥¢¥Ê¥¦¥ó¥¹¤Î <em>Subject</em> ¥Õ¥£¡¼¥ë¥É¤Ë¤Ï
-(¥½¡¼¥¹) ¥Ñ¥Ã¥±¡¼¥¸Ì¾¡¢¥Ð¡¼¥¸¥ç¥óÈֹ桢Êѹ¹»ö¹à¤Î¶Ë¤á¤Æ´Ê·é¤ÊÍ×Ìó¤ò´Þ¤á¡¢
-¤½¤ÎËÜʸ¤Ë¤Ï PGP ¤Ç½ð̾¤µ¤ì¤¿ <tt>.changes</tt> ¥Õ¥¡¥¤¥ë¤ò´Þ¤á¤Þ¤¹¡£
-ÉÕ²ÃŪ¤ÊÀâÌÀʸ¤Ï <tt>.changes</tt> ¥Õ¥¡¥¤¥ë¤ÎÁ°¤ËÉÕ¤±²Ã¤¨¤Þ¤¹¡£
-
- <p>
-¤¢¤ë¥Ñ¥Ã¥±¡¼¥¸¤¬¡¢¤½¤Î <tt>Distribution:</tt> ¥Õ¥£¡¼¥ë¥É¤Ë
-`stable' ¤Èµ½Ò¤µ¤ì¤Æ¥ê¥ê¡¼¥¹¤µ¤ì¤ë¾ì¹ç¡¢
-¤½¤Î¥¢¥Ê¥¦¥ó¥¹¤Ï &email-debian-changes; ¤ËÁ÷¤ê¤Þ¤¹¡£
-°ìÊý¤¢¤ë¥Ñ¥Ã¥±¡¼¥¸¤¬¡¢¤½¤Î <tt>Distribution:</tt> ¥Õ¥£¡¼¥ë¥É¤Ë
-`unstable' ¤ä¡¢`experimental'¡¢(¤â¤·¤¢¤ì¤Ð) `frozen'
-¤Ê¤É¤¬µ½Ò¤µ¤ì¤Æ¥ê¥ê¡¼¥¹¤µ¤ì¤ë¾ì¹ç¡¢
-¤½¤Î¥¢¥Ê¥¦¥ó¥¹¤Ï &email-debian-devel-changes; ¤ËÁ÷¤é¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¡£
- <p>
-¾ì¹ç¤Ë¤è¤Ã¤Æ¤Ï¡¢<em>stable</em> ¤È <em>unstable</em>
-¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤ÎξÊý¤Ë¥Ñ¥Ã¥±¡¼¥¸¤ò¥¢¥Ã¥×¥í¡¼¥É¤¹¤ëɬÍפ¬¤¢¤ê¤Þ¤¹¤¬¡¢
-¤³¤Î¾ì¹ç¤Ï <tt>Distribution:</tt> ¥Õ¥£¡¼¥ë¥É¤Ë
-ξÊý¤Î¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó̾¤òµ½Ò¤·¤Æ¤¯¤À¤µ¤¤¡£
-¤³¤Î¾ì¹ç¥¢¥Ã¥×¥í¡¼¥É¥¢¥Ê¥¦¥ó¥¹¤Ï¡¢
-¾åµ¤Î¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤ÎξÊý¤ËÅê¹Æ¤·¤Æ¤¯¤À¤µ¤¤¡£
- <p>
-¤Ê¤ª¡¢<prgn>dupload</prgn> ¥×¥í¥°¥é¥à¤Ï¡¢
-¥¢¥Ê¥¦¥ó¥¹¤ò¤É¤³¤ØÅê¹Æ¤¹¤Ù¤¤«¤òȽÃǤ·
-ŬÀڤʥ᡼¥ê¥ó¥°¥ê¥¹¥È¤Ë¼«Æ°Åª¤Ë¥¢¥Ê¥¦¥ó¥¹¤òÅê¹Æ¤·¤Æ¤¯¤ì¤Þ¤¹¡£
-<ref id="dupload"> ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£
-
- <sect id="upload-notification">
- <heading>¿·µ¬¥Ñ¥Ã¥±¡¼¥¸¥¤¥ó¥¹¥È¡¼¥ë¤ÎÄÌÃÎ</heading>
- <p>
-Debian ¥¢¡¼¥«¥¤¥Ö¥á¥ó¥Æ¥Ê¤¬¡¢
-¥¢¥Ã¥×¥í¡¼¥É¤µ¤ì¤¿¥Ñ¥Ã¥±¡¼¥¸¤Î½èÍý¤ËÀÕǤ¤ò»ý¤Á¤Þ¤¹¡£
-¤Û¤È¤ó¤É¤Î¾ì¹ç¥¢¥Ã¥×¥í¡¼¥É¤Ï¡¢
-<prgn>dinstall</prgn> ¤È¤¤¤¦¥¢¡¼¥«¥¤¥Ö¥á¥ó¥Æ¥Ê¥ó¥¹¥Ä¡¼¥ë¤Ë¤è¤Ã¤Æ
-´ðËÜŪ¤ËËèÆü¼«Æ°Åª¤Ë½èÍý¤µ¤ì¤Þ¤¹¡£
-ÆÃ¤Ë `unstable' ¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤Ë¸ºß¤¹¤ë¥Ñ¥Ã¥±¡¼¥¸¤Î¥¢¥Ã¥×¥í¡¼¥É¤Ï¡¢
-¼«Æ°Åª¤Ë½èÍý¤µ¤ì¤Þ¤¹¡£
-¤¿¤À¡¢¤½¤Î¾¤Î¾ì¹ç¡¢Æä˿·µ¬¥Ñ¥Ã¥±¡¼¥¸¤Î¤è¤¦¤Ê¾ì¹ç¤Ë¤Ï¡¢
-ÆÃÄê¤Î¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤Ø¤Î¥Ñ¥Ã¥±¡¼¥¸¥¢¥Ã¥×¥í¡¼¥É¤Ï¼êÆ°¤Ç½èÍý¤µ¤ì¤Þ¤¹¡£
-¥¢¥Ã¥×¥í¡¼¥É¤µ¤ì¤¿¥Ñ¥Ã¥±¡¼¥¸¤¬¼êÆ°¤Ç½èÍý¤µ¤ì¤ë¾ì¹ç¡¢
-¥¢¡¼¥«¥¤¥Ö¤ÎÊѹ¹¤Ë¤Ï°ì½µ´Ö¤Û¤É»þ´Ö¤¬¤«¤«¤ê¤Þ¤¹¡£
-(¿ÉÊú¶¯¤¯¤ªÂÔ¤Á¤¯¤À¤µ¤¤¡£)
- <p>
-¤É¤ó¤Ê¾ì¹ç¤Ç¤â¡¢¥Ñ¥Ã¥±¡¼¥¸¥¢¥Ã¥×¥í¡¼¥É¤ÎÄÌÃΤòÅŻҥ᡼¥ë¤Ç¼õ¤±¼è¤ì¤Þ¤¹¡£
-¤³¤ÎÄÌÃΤÎÆâÍƤϽ½Ê¬Ãí°Õ¤·¤Æ¤ª³Î¤«¤á¤¯¤À¤µ¤¤¡£
-¥Ñ¥Ã¥±¡¼¥¸¤¬¤¢¤Ê¤¿¤ÎÁÛÄꤷ¤Æ¤¤¤¿¥»¥¯¥·¥ç¥ó¤ËÀßÃÖ¤µ¤ì¤Ê¤«¤Ã¤¿¾ì¹ç¡¢
-¤½¤Î¤³¤È¤¬¤³¤Á¤é¤ÇÄÌÃΤµ¤ì¤ë¤Ç¤·¤ç¤¦¡£
-¤½¤ÎÍýͳ¤Ë´Ø¤·¤Æ¤Ï¤³¤Á¤é¤ò¤è¤¯¤ªÆɤߤ¯¤À¤µ¤¤¡£
-
- <sect1 id="override-file">¥ª¡¼¥Ð¥é¥¤¥É¥Õ¥¡¥¤¥ë
- <p>
-<file>debian/control</file> ¥Õ¥¡¥¤¥ë¤Î
-<tt>Section</tt> ¤ª¤è¤Ó <tt>Priority</tt> ¥Õ¥£¡¼¥ë¥É¤Ï¡¢
-¤½¤Î¥Õ¥¡¥¤¥ë¤¬¥¢¡¼¥«¥¤¥Ö¤Î¤É¤³¤ËÀßÃÖ¤µ¤ì¤ë¤«¤ä¡¢¤½¤Î priority ¤ò
-¼ÂºÝ¤ËÆÃÄꤹ¤ë¤â¤Î¤Ç¤Ï¤¢¤ê¤Þ¤»¤ó¡£
-¥¢¡¼¥«¥¤¥ÖÁ´ÂΤòÀ°Íý¤µ¤ì¤¿¾õÂ֤ˤ·¤Æ¤ª¤¯¤¿¤á¤Ë¡¢
-¤³¤ì¤é¤Î¥Õ¥£¡¼¥ë¥É¤Î´ÉÍý¤Ï¥¢¡¼¥«¥¤¥Ö¥á¥ó¥Æ¥Ê¤¬¹Ô¤Ê¤¤¤Þ¤¹¡£
-¤½¤Î¤¿¤á <file>debian/control</file> ¥Õ¥¡¥¤¥ë¤ËÀßÄꤵ¤ì¤¿Ãͤϡ¢
-¼ÂºÝ¤Ï¤½¤Î¥Ò¥ó¥È¤Ë¤Ê¤ë¤À¤±¤Ç¤¹¡£
- <p>
-¥¢¡¼¥«¥¤¥Ö¥á¥ó¥Æ¥Ê¤Ï¡¢¥Ñ¥Ã¥±¡¼¥¸¤ÎÀµ¼°¤Ê¥»¥¯¥·¥ç¥ó¤ä¥×¥é¥¤¥ª¥ê¥Æ¥£¤ò
-<em>override file</em> ¤Ë¤Æ´ÉÍý¤·¤Þ¤¹¡£
-¾ì¹ç¤Ë¤è¤Ã¤Æ¤Ï <em>override file</em> ¤Ï½¤Àµ¤¬É¬Íפˤʤê¤Þ¤¹¡£
-¤¿¤À¡¢¥Ñ¥Ã¥±¡¼¥¸¤Î <file>control</file>
-¥Õ¥¡¥¤¥ë¤òñ¤ËÊѹ¹¤·¤Æ¤â¸ú²Ì¤Ï¤¢¤ê¤Þ¤»¤ó¡£
-¤½¤ÎÂå¤ï¤ê¤Ë &email-override; ¤ËÅŻҥ᡼¥ë¤òÁ÷¤ë¤«¡¢
-<package>ftp.debian.org</package>
-¤ËÂФ¹¤ë¥Ð¥°¤È¤·¤ÆÊó¹ð¤ò¹Ô¤Ê¤ï¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó
- <p>
-<em>override files</em> ¤Ë´Ø¤¹¤ë¤è¤ê¾ÜºÙ¤Ê¾ðÊó¤Ë¤Ä¤¤¤Æ¤Ï¡¢
-<manref name="dpkg-scanpackages" section="8"> ¤ä¡¢
-<url id="&url-bts-devel;#maintincorrect"> ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£
-
- <chapt id="nmu">¥Î¥ó¥á¥ó¥Æ¥Ê¥¢¥Ã¥×¥í¡¼¥É (NMU)
- <p>
-¾õ¶·¤Ë¤è¤Ã¤Æ¤Ï¡¢¤¢¤ë¥Ñ¥Ã¥±¡¼¥¸¤ò¤½¤Î¸ø¼°¤Ê³«È¯¼Ô°Ê³°¤Î狼¤¬
-¥ê¥ê¡¼¥¹¤·¤Ê¤±¤ì¤Ð¤Ê¤é¤Ê¤¤¤³¤È¤¬¤¢¤ê¤Þ¤¹¡£
-¤³¤Î¤³¤È¤Ï¥Î¥ó¥á¥ó¥Æ¥Ê¥¢¥Ã¥×¥í¡¼¥É¡¢¤¹¤Ê¤ï¤Á NMU ¤È¸Æ¤Ð¤ì¤Æ¤¤¤Þ¤¹¡£
- <p>
-°Û¤Ê¤ë¥¢¡¼¥¥Æ¥¯¥Á¥ã¸þ¤±¤Î¥Ñ¥Ã¥±¡¼¥¸¤òºîÀ®¤¹¤ë¤È¤¤¤¦
-Debian ¤Î°Ü¿¢ºî¶È¤Ë·È¤ï¤ë¿Í¤Ë¤È¤Ã¤Æ¤Ï¡¢
-¤³¤Î NMU ¤ÏÀµµ¬¤Î°Ü¿¢ºî¶È¤Î°ì´Ä¤Ë¤¢¤ê¤Þ¤¹¡£
-(<ref id="porting"> ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£)
-¾¤Ë¤â¡¢Æä˥ե꡼¥º´ü´Ö¤Ê¤É¤Ë¡¢
-¥»¥¥å¥ê¥Æ¥£¤äµ¡Ç½¤Ë´Ø¤¹¤ë¿¼¹ï¤ÊÌäÂê¤ò½èÍý¤¹¤ë¤¿¤á¤Ë¡¢
-Debian ³«È¯¼Ô¤¬Â¾¤Î³«È¯¼Ô¤Î¥Ñ¥Ã¥±¡¼¥¸¤ò½¤Àµ¤¹¤ëɬÍפ¬¤¢¤ë¾ì¹ç¡¢
-¤Ä¤Þ¤ê¡¢¥Ñ¥Ã¥±¡¼¥¸³«È¯¼Ô¤¬½¤ÀµÈǤò¨ºÂ¤Ë¥ê¥ê¡¼¥¹¤Ç¤¤Ê¤¤¾ì¹ç¤Ë¤Ï
-NMU ¤¬¹Ô¤Ê¤ï¤ì¤Þ¤¹¡£
- <p>
-¤³¤Î¾Ï¤Ç¤Ï¡¢NMU ¤¬¤¤¤Ä¤É¤Î¤è¤¦¤Ë¹Ô¤Ê¤ï¤ì¤ë¤Ù¤¤«¤Ë¤Ä¤¤¤Æ¤Î
-¥¬¥¤¥É¥é¥¤¥ó¤ò°·¤¤¤Þ¤¹¡£
-¤Ê¤ª¼¡Àá¤ÇÀâÌÀ¤·¤Þ¤¹¤¬¡¢¤³¤Î NMU ¤Ë¤Ï source NMU ¤È binary NMU
-¤ÎÆó¤Ä¤¬¤¢¤ê¤Þ¤¹¡£
-
- <sect id="nmu-terms">ÍѸì
- <p>
-¤³¤ÎÀá¤ÎÁ´ÂΤˤ錄¤Ã¤ÆÆó¤Ä¤Î¿·¤¿¤ÊÍѸ졢``binary NMU'' ¤È ``source NMU''
-¤òÍѤ¤¤Þ¤¹¡£
-¤³¤ì¤é¤ÎÍѸì¤Ï¡¢¤³¤Îʸ½ñ¤ÎÃæ¤Ç¤Ïµ»½Ñ¾å¤ÎÆÃÊ̤ʰÕÌ£¤ò¼¨¤¹¤â¤Î¤È¤·¤ÆÍѤ¤¤Þ¤¹¡£
-binary NMU ¤È source NMU ¤Ï¡¢¤¢¤ë¥Ñ¥Ã¥±¡¼¥¸¤¬¸ø¼°¤Ê³«È¯¼Ô°Ê³°¤Î³«È¯¼Ô
-¤Ë¤è¤Ã¤Æ¥¢¥Ã¥×¥í¡¼¥É¤µ¤ì¤ëÅÀ¤Ç¤ÏƱ¤¸¤Ç¤¹¡£
-<em>¥Î¥ó¥á¥ó¥Æ¥Ê</em>¥¢¥Ã¥×¥í¡¼¥É¤È¸Æ¤Ð¤ì¤ë¤Î¤Ï¤³¤Î¤¿¤á¤Ç¤¹¡£
- <p>
-source NMU ¤È¤Ï¡¢¤¢¤ë¥Ñ¥Ã¥±¡¼¥¸¤¬¤½¤Î¥Ð¥°½¤Àµ¤Î¤¿¤á¤Ë¡¢
-¸ø¼°³«È¯¼Ô°Ê³°¤Î³«È¯¼Ô¤Ë¤è¤Ã¤Æ¥¢¥Ã¥×¥í¡¼¥É¤µ¤ì¤ë¤³¤È¤ò»Ø¤·¤Þ¤¹¡£
-source NMU ¤Ï¡¢(<file>debian/changelog</file> ¤Î²þÊѤΤߤ«¤â¤·¤ì¤Þ¤»¤ó¤¬¡¢)
-¾ï¤Ë¥½¡¼¥¹¤Î²þÊѤòȼ¤¤¤Þ¤¹¡£
-¤³¤Î²þÊѤϥ¢¥Ã¥×¥¹¥È¥ê¡¼¥à¥½¡¼¥¹¤È¡¢
-Debian ¤Ç²Ã¤¨¤é¤ì¤¿¥½¡¼¥¹¤Î¤É¤Á¤é¤ËÂФ·¤Æ¹Ô¤Ê¤¦¤³¤È¤¬¤Ç¤¤Þ¤¹¡£
- <p>
-binary NMU ¤Ï¡¢¿·¤¿¤Ê¥¢¡¼¥¥Æ¥¯¥Á¥ã¸þ¤±¤Ë¥Ð¥¤¥Ê¥ê¥Ñ¥Ã¥±¡¼¥¸¤ò
-ºÆ¥³¥ó¥Ñ¥¤¥ë¤·¥¢¥Ã¥×¥í¡¼¥É¤¹¤ë¤³¤È¤ò»Ø¤·¤Þ¤¹¡£
-¤½¤Î¤¿¤á¡¢¤³¤Á¤é¤Ï°Ü¿¢¤Ë´Ø¤¹¤ëÀµµ¬¤Îºî¶È°ì´Ä¤Ë¤¢¤ë¤â¤Î¤Ç¤¹¡£
-¤Ä¤Þ¤ê binary NMU ¤È¤Ï¡¢¥½¡¼¥¹²þÊѤòɬÍפȤ·¤Ê¤¤¡¢
-(ÉáÄ̤Ͼ¥¢¡¼¥¥Æ¥¯¥Á¥ãÍÑ) ¥Ñ¥Ã¥±¡¼¥¸¤Î¥Ð¥¤¥Ê¥ê¥Ð¡¼¥¸¥ç¥ó¤¬
-¥Î¥ó¥á¥ó¥Æ¥Ê¥¢¥Ã¥×¥í¡¼¥É¤µ¤ì¤¿¤â¤Î¤Ç¤¹¡£
-¤¿¤À¡¢¥¿¡¼¥²¥Ã¥È¤È¤¹¤ë¥¢¡¼¥¥Æ¥¯¥Á¥ã¤Ç¥³¥ó¥Ñ¥¤¥ë¤òÄ̤¹¤¿¤á¤Ë¡¢
-°Ü¿¢ºî¶È¼Ô¤¬¥½¡¼¥¹¾å¤ÎÌäÂê¤ò½¤Àµ¤¹¤ë¤³¤È¤Ï¤è¤¯¤¢¤ë¤³¤È¤Ç¤¹¡£
-¤½¤Î¤¿¤á¡¢¤³¤Á¤é¤Ï binary NMU ¤È¤¤¤¦¤è¤ê¤â¤à¤·¤í source NMU
-¤È¤ß¤Ê¤µ¤ì¤ë¤â¤Î¤Ç¤¹¡£
-¤³¤Î¤è¤¦¤Ë¡¢»ä¤¿¤Á¤Ï¡¢°Ü¿¢ºî¶È¼Ô¤Ë¤è¤ë NMU ¤ÈÈó°Ü¿¢ºî¶È¼Ô¤Ë¤è¤ë
-NMU ¤òÍѸì¤Î¾å¤Ç¤Ï¶èÊ̤·¤Æ¤¤¤Þ¤»¤ó¡£
- <p>
-source ¤ª¤è¤Ó binary ¤Îξ NMU ¤Ï¡¢``NMU'' ¤È¤¤¤¦ÍѸì¤Ç°ì³ç¤ê¤µ¤ì¤¨¤Þ¤¹¡£
-¤·¤«¤·¤Ê¤¬¤é¡¢``NMU'' ¤È¤¤¤¦ÍѸ줬»È¤ï¤ì¤ëºÝ¤Ë¿¤¯¤Î¿Í¡¹¤Ï
-``source NMU''¤òÁÛÄꤹ¤ë¤¿¤á¤Ë¡¢¤³¤Î¤³¤È¤Ï¤·¤Ð¤·¤Ðº®Íð¤ò¤â¤¿¤é¤·¤¬¤Á¤Ç¤¹¡£
-¤½¤Î¤¿¤á¤³¤Î¶èÊ̤ˤĤ¤¤Æ¤ÏÃí°Õ¤òʧ¤Ã¤Æ¤ª¤¯¤Ù¤¤Ç¤·¤ç¤¦¡£
-¤³¤Î¾Ï¤Ç»ä¤¬ÉÔÆÃÄê¤Ë ``NMU'' ¤È¤¤¤¦ÍѸì¤ò»È¤¦¾ì¹ç¡¢
-¤½¤ì¤Ï source ¤ª¤è¤Ó binary ¤Îξ NMU ¤ò»Ø¤¹¤â¤Î¤È¤·¤Þ¤¹¡£
-
- <sect id="nmu-who">NMU ¤ò¹Ô¤Ê¤¦¤³¤È¤¬¤Ç¤¤ë¤Î¤Ï狼
- <p>
-Debian ³«È¯¼Ô¤È¤·¤ÆÀµ¼°¤ËÅÐÏ¿¤µ¤ì¤¿¼Ô¤Î¤ß¤¬
-binary NMU ¤¢¤ë¤¤¤Ï source NMU ¤ò¹Ô¤Ê¤¦¤³¤È¤¬¤Ç¤¤Þ¤¹¡£
-¸ø¼°¤Ê³«È¯¼Ô¤È¤Ï¡¢Debian ¥¡¼¥ê¥ó¥°¤Ë¼«Ê¬¤Î¸°¤¬ÅÐÏ¿¤µ¤ì¤Æ¤¤¤ë¼Ô¤Î¤³¤È¤Ç¤¹¡£
-¤â¤Á¤í¤ó¡¢Èó³«È¯¼Ô¤Î¾ì¹ç¤â¥½¡¼¥¹¥Ñ¥Ã¥±¡¼¥¸¤ò¥À¥¦¥ó¥í¡¼¥É¤·¤Æ¡¢
-ÌäÂê¤ò½¤Àµ¤¹¤ë¤¿¤á¤Ë¤½¤Î¥Ï¥Ã¥¯¤ò»Ï¤á¤ë¤³¤È¤Ï¾©Î夵¤ì¤Æ¤¤¤Þ¤¹¡£
-¤¿¤À¤½¤ÎºÝ¤Ë¤Ï¡¢NMU ¤ò¹Ô¤Ê¤¦Âå¤ï¤ê¤Ë
-¥Ð¥°ÄÉÀ×¥·¥¹¥Æ¥à¤ØŬÀڤʥѥåÁ¤òÅÐÏ¿¤¹¤ë¤Ù¤¤Ç¤¹¡£
-³«È¯¼Ô¤Ï¼Á¤Î¹â¤¤¥Ñ¥Ã¥Á¤ä¥Ð¥°Êó¹ð¤ËÂФ·¤ÆÉáÄ̤¤¤Ä¤Ç¤â´¶¼Õ¤·¤Æ¤¤¤Þ¤¹¡£
-
- <sect id="nmu-when">source NMU ¤ò¹Ô¤Ê¤¦¾ì¹ç¤Ë¤Ï
- <p>
-source NMU ¤ò¹Ô¤Ê¤¦¾ì¹ç¤Î¥¬¥¤¥É¥é¥¤¥ó¤Ï¡¢
-¥¿¡¼¥²¥Ã¥È¤È¤¹¤ë¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó
-(¤Ä¤Þ¤ê stable ¤ä¡¢unstable ¤¢¤ë¤¤¤Ï frozen) ¤Ë¤è¤Ã¤Æ°Û¤Ê¤ê¤Þ¤¹¡£
-¤Ê¤ª¡¢°Ü¿¢ºî¶È¼Ô¤¬½¾¤¦¥ë¡¼¥ë¤Ï¡¢¤½¤ÎÆÃÊ̤ʾõ¶·
-(<ref id="source-nmu-when-porter"> ¤ò¤´Í÷¤¯¤À¤µ¤¤)
-¤Î¤¿¤á¤Ë¡¢Èó°Ü¿¢ºî¶È¼Ô¤Î¾ì¹ç¤È¤Ï¼ã´³°Û¤Ê¤ê¤Þ¤¹¡£
- <p>
-stable ÈǤËÂФ·¤Æ¹Ô¤Ê¤¨¤ë¤â¤Î¤Ï¡¢critical ¤Ê¥Ð¥°¤Î½¤Àµ¤ä¡¢
-¥»¥¥å¥ê¥Æ¥£¾å¤Î¥Ð¥°¤Ë´Ø¤¹¤ë½¤Àµ¤Î¤ß¤Ç¤¹¡£
-¥»¥¥å¥ê¥Æ¥£¾å¤Î¥Ð¥°¤¬È¯³Ð¤·¤¿¾ì¹ç¡¢
-½¤ÀµÈǥѥ屡¼¥¸¤Ï²Äǽ¤Ê¸Â¤êÁ᤯¥¢¥Ã¥×¥í¡¼¥É¤µ¤ì¤ë¤Ù¤¤Ç¤¹¡£
-¤³¤Î¾ì¹ç¡¢Debian ¥»¥¥å¥ê¥Æ¥£¥Þ¥Í¡¼¥¸¥ã¤Ï¡¢
-½¤ÀµÈǥѥ屡¼¥¸¤òŬÀڤʴü¸ÂÆâ (48 »þ´Ö°ÊÆâ)
-¤Ë³Î¼Â¤Ë¥¢¥Ã¥×¥í¡¼¥É¤Ç¤¤ë¤è¤¦³ºÅö¥Ñ¥Ã¥±¡¼¥¸¤Î³«È¯¼Ô¤ÈÏ¢Íí¤ò¤È¤ë¤Ù¤¤Ç¤¹¡£
-
-¥Ñ¥Ã¥±¡¼¥¸³«È¯¼Ô¤¬½¤ÀµÈǥѥ屡¼¥¸¤ò½½Ê¬¤ËÁ᤯¤ÏÄ󶡤Ǥ¤Ê¤¤¾ì¹ç¤ä¡¢
-¤½¤Î³«È¯¼Ô¤Ë¤¹¤°¤ËÏ¢Íí¤Î¼è¤ì¤Ê¤¤¾ì¹ç¤Ë¤Ï¡¢
-¥»¥¥å¥ê¥Æ¥£¥Þ¥Í¡¼¥¸¥ã¤¬½¤ÀµÈǥѥ屡¼¥¸ (¤Ä¤Þ¤ê source NMU )
-¤ò¥¢¥Ã¥×¥í¡¼¥É¤¹¤ë¤³¤È¤¬¤Ç¤¤Þ¤¹¡£
- <p>
-¥ê¥ê¡¼¥¹¤Î¥Õ¥ê¡¼¥º´ü´Ö (<ref id="upload-frozen"> ¤ò¤´Í÷¤¯¤À¤µ¤¤) ¤Ë¤Ï¡¢
-important ¥Ð¥°¤ä½ÅÍ×Å٤ι⤤¥Ð¥°¤Î½¤Àµ¤Ï¾©Î夵¤ì¤Æ¤ª¤êǧ¤á¤é¤ì¤Þ¤¹¡£
-¤·¤«¤·¡¢¤³¤Î´ü´Ö¤Ë¤ª¤¤¤Æ¤â¡¢
-¤½¤Î¥Ñ¥Ã¥±¡¼¥¸¤Î¸½¹Ô³«È¯¼Ô¤ÈÏ¢Íí¤ò¤È¤ë¤è¤¦Åؤá¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¡£
-¸½¹Ô³«È¯¼Ô¤¬¤½¤ÎÌäÂê¤Î½¤Àµ¤ò¤Á¤ç¤¦¤É¥¢¥Ã¥×¥í¡¼¥É¤·¤è¤¦¤È¤·¤Æ¤¤¤ë¤È¤³¤í
-¤Ê¤Î¤«¤â¤·¤ì¤Ê¤¤¤«¤é¤Ç¤¹¡£
-¤Þ¤¿¡¢¤¤¤«¤Ê¤ë source NMU ¤ò¹Ô¤Ê¤¦¾ì¹ç¤Ç¤â¡¢<ref id="nmu-guidelines">
-¤Ë¤Æ·Ç¤²¤é¤ì¤Æ¤¤¤ë¥¬¥¤¥É¥é¥¤¥ó¤Ë¤Ï½¾¤¦É¬Íפ¬¤¢¤ê¤Þ¤¹¡£
- <p>
-Èó³«È¯¼Ô¤Ë¤è¤ë unstable ÈǤؤΥХ°½¤Àµ¤â¡¢
-ºÇ½ª¼êÃʤȤ·¤Æ¹Ô¤Ê¤ï¤ì¤ë¾ì¹ç¤äµö²Ä¤¬¤¢¤ë¾ì¹ç¤Î¤ß
-ǧ¤á¤é¤ì¤Æ¤¤¤Þ¤¹¡£
-°Ê²¼¤Î³Æ¥¹¥Æ¥Ã¥×¤òƧ¤ó¤Ç¤ß¤Æ¡¢
-¤½¤Î·ë²Ì¤½¤ì¤¬¾å¼ê¤¯¤¤¤«¤Ê¤¤¾ì¹ç¤Ë¤Ï¡¢
-¤ª¤½¤é¤¯ NMU ¤ò¹Ô¤Ê¤¦¤ËÌäÂê¤Ï¤Ê¤¤¤Ç¤·¤ç¤¦¡£
- <p>
-<list>
- <item>
-¤½¤Î¥Ñ¥Ã¥±¡¼¥¸¤Î¥Ð¥°¤¬ Debian ¥Ð¥°ÄÉÀ×¥·¥¹¥Æ¥à (BTS)
-¤ËÅÐÏ¿¤µ¤ì¤Æ¤¤¤ë¤«¤É¤¦¤«¤ò³Îǧ¤·¤Þ¤¹¡£
-¤â¤·ÅÐÏ¿¤µ¤ì¤Æ¤¤¤Ê¤¤¾ì¹ç¤Ï¡¢¥Ð¥°ÅÐÏ¿¤ò¹Ô¤Ê¤Ã¤Æ¤¯¤À¤µ¤¤¡£
- <item>
-¤½¤Î³«È¯¼Ô¤ËÅŻҥ᡼¥ë¤òÁ÷¤ê¡¢
-¤½¤Î¥Ñ¥Ã¥±¡¼¥¸¤Î¥Ð¥°½¤Àµ¤ò±ç½õ¤¹¤ë»Ý¿½¤·½Ð¤Þ¤¹¡£
-ÊÖ¿®¤ò¤â¤é¤¦¤Þ¤Ç¤ËÆó»°Æü¤ÏÂԤäƤ¯¤À¤µ¤¤¡£
- <item>
-ºî¶È¤ò³«»Ï¤·¥Ð¥°¤ò½¤Àµ¤·¤Þ¤¹¡£
-BTS ¤ËÅÐÏ¿¤µ¤ì¤¿Å¬ÀڤʥХ°¤ËÂФ·¤Æ¥Ñ¥Ã¥Á¤òÅÐÏ¿¤·¤Æ¤¯¤À¤µ¤¤¡£
-¤½¤Î¥Ñ¥Ã¥±¡¼¥¸¤ò <ref id="upload-checking">
-¤ÎÀâÌÀ¤Ë¤·¤¿¤¬¤Ã¤Æ¹½ÃÛ¤ª¤è¤Ó¥Æ¥¹¥È¤·¤Þ¤¹¡£
-¤³¤Á¤é¤Ï¥í¡¼¥«¥ë¤Ç¹Ô¤Ê¤Ã¤Æ¤¯¤À¤µ¤¤¡£
- <item>
-³«È¯¼Ô¤ÎÂбþ¤òÆó»°½µ´ÖÂÔ¤Á¤Þ¤¹¡£
- <item>
-NMU ¤ò¹Ô¤Ê¤Ã¤Æ¤è¤¤¤«¤É¤¦¤«¿Ò¤Í¤ë¤¿¤á¤Ë¡¢
-³«È¯¼Ô¤ËÅŻҥ᡼¥ë¤òÁ÷¤ê¤Þ¤¹¡£
- <item>
-¤¢¤Ê¤¿¤Î¥Ñ¥Ã¥Á¤¬Í½´ü¤·¤Ê¤¤ÉûºîÍѤò»ý¤Ã¤Æ¤¤¤Ê¤¤¤«¤É¤¦¤«¤ò
-½Å¤Í¤Æ¥Á¥§¥Ã¥¯¤·¤Þ¤¹¡£
-¤½¤ÎºÝ¤¢¤Ê¤¿¤Î¥Ñ¥Ã¥Á¤¬¤Ç¤¤ë¤À¤±¾®¤µ¤Ê¤â¤Î¤È¤Ê¤ë¤è¤¦¤Ë¡¢
-¤Þ¤¿¸µ¤Î¥½¡¼¥¹¤ò¤Ê¤ë¤Ù¤¯²þÊѤ·¤Ê¤¤¤â¤Î¤È¤Ê¤ë¤è¤¦³Îǧ¤·¤Æ¤¯¤À¤µ¤¤¡£
- <item>
-³«È¯¼Ô¤ÎÂбþ¤ò¤â¤¦°ì½µ´ÖÂÔ¤Á¤Þ¤¹¡£
- <item>
-ºî¶È¤ò¿Ê¤á¡¢<ref id="nmu-guidelines"> ¤ÎÀâÌÀ¤Ë¤·¤¿¤¬¤¤
-source NMU ¤ò¹Ô¤Ê¤¤¤Þ¤¹¡£
- </list>
-
- <sect id="nmu-guidelines">source NMU ¤ò¹Ô¤Ê¤¦¤Ë¤Ï
- <p>
-°Ê²¼¤Îµ½Ò¤Ï¡¢°Ü¿¢ºî¶È¼Ô¤¬
-¥Ñ¥Ã¥±¡¼¥¸¤Î¥Ð¥°½¤Àµ¤Ê¤é¤Ó¤Ë¥Ñ¥Ã¥±¡¼¥¸¤Î°Ü¿¢¤ÎξÊý¤ÎÌò³ä¤ò²Ì¤¿¤¹¾ì¹ç¤Î¤ß
-Åö¤Æ¤Ï¤Þ¤ê¤Þ¤¹¡£
-°Ü¿¢ºî¶È¼Ô¤¬ Debian ¥½¡¼¥¹¥¢¡¼¥«¥¤¥Ö¤ËÊѹ¹¤ò²Ã¤¨¤ëɬÍפ¬¤¢¤ë¾ì¹ç¡¢
-¤½¤Î¥¢¥Ã¥×¥í¡¼¥É¤Ï¤¹¤Ê¤ï¤Á source NMU ¤Ç¤¢¤ê¡¢
-¤½¤ÎºÝ¤Ë¤Ï source NMU ¤Ë´Ø¤¹¤ë¥ë¡¼¥ë¤Ë¤·¤¿¤¬¤ï¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¡£
-ñ¤ËºÆ¥³¥ó¥Ñ¥¤¥ë¤·¤¿¥Ð¥¤¥Ê¥ê¥Ñ¥Ã¥±¡¼¥¸¤ò¥¢¥Ã¥×¥í¡¼¥É¤¹¤ë¾ì¹ç¡¢
-ŬÍѤµ¤ì¤ë¥ë¡¼¥ë¤Ï°Û¤Ê¤Ã¤Æ¤¤Þ¤¹¡£
-¤³¤Á¤é¤Ë´Ø¤·¤Æ¤Ï <ref id="porter-guidelines"> ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£
- <p>
-¤Þ¤ºÂè°ì¤Ë¡¢¥½¡¼¥¹¤ËÂФ¹¤ë NMU ¥Ñ¥Ã¥Á¤Ï¡¢
-¸µ¤Î¥½¡¼¥¹¤ò¤Ê¤ë¤Ù¤¯²þÊѤ·¤Ê¤¤¤â¤Î¤Ç¤¢¤ë¤³¤È¤¬½ÅÍפǤ¹¡£
-¤¢¤ì¤³¤ì¤È¥½¡¼¥¹¤òÀ°Íý¤·¤¿¤ê¤·¤Ê¤¤¤Ç¤¯¤À¤µ¤¤¡£
-¥â¥¸¥å¡¼¥ë̾¤ä¥Õ¥¡¥¤¥ë̾¤ÏÊѹ¹¤·¤Ê¤¤¤Ç¤¯¤À¤µ¤¤¡£
-¥Ç¥£¥ì¥¯¥È¥ê¤Ï°ÜÆ°¤·¤Ê¤¤¤Ç¤¯¤À¤µ¤¤¡£
-¤Ä¤Þ¤ê¡¢°ìÈÌŪ¤Ë¤ÏÌäÂê¤Î¤Ê¤¤²Õ½ê¤ËÊѹ¹¤ò²Ã¤¨¤Ê¤¤¤Ç¤¯¤À¤µ¤¤¡£
-¥Ñ¥Ã¥Á¤Ï¤Ê¤ë¤Ù¤¯¾®¤µ¤Ê¤â¤Î¤È¤Ê¤ë¤è¤¦¤Ë¤·¤Æ¤¯¤À¤µ¤¤¡£
-¤¢¤Ê¤¿¤Î¿³ÈþŪ¤Ê´ÑÅÀ¤«¤é²¿¤È¤«¤·¤¿¤¤¤³¤È¤¬¤¢¤ë¤Ê¤é¤Ð¡¢
-Debian ³«È¯¼Ô¤ä¥¢¥Ã¥×¥¹¥È¥ê¡¼¥à³«È¯¼Ô¤ËÏ¢Íí¤ò¼è¤ë¤«¡¢
-¥Ð¥°Êó¹ð¤ò¹Ô¤Ê¤Ã¤Æ¤¯¤À¤µ¤¤¡£
-¤È¤â¤¢¤ì¡¢¿³ÈþŪ¤Ê´ÑÅÀ¤«¤é¤ÎÊѹ¹¤Ï
-¥Î¥ó¥á¥ó¥Æ¥Ê¥¢¥Ã¥×¥í¡¼¥É¤Ç¹Ô¤Ê¤¦¤Ù¤¤Ç¤Ï<em>¤¢¤ê¤Þ¤»¤ó</em>¡£
-
- <sect1 id="nmu-version">source NMU ¤Î¥Ð¡¼¥¸¥ç¥óÈÖ¹æ¤Å¤±
- <p>
-¥Ñ¥Ã¥±¡¼¥¸¤ËÊѹ¹¤ò²Ã¤¨¤ëºÝ¤Ë¤Ï¾ï¤Ë¡¢
-¤½¤ì¤¬¤É¤ó¤Ê¤Ëº³ºÙ¤Ê¤â¤Î¤Ç¤¢¤í¤¦¤È¤â¡¢
-¥Ð¡¼¥¸¥ç¥óÈÖ¹æ¤òÊѹ¹¤·¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¡£
-¤½¤¦¤·¤Ê¤±¤ì¤Ð¡¢¥Ñ¥Ã¥±¡¼¥¸¥ó¥°¥·¥¹¥Æ¥à¤¬Àµ¤·¤¯µ¡Ç½¤·¤Þ¤»¤ó¡£
- <p>
-¥Î¥ó¥á¥ó¥Æ¥Ê¥¢¥Ã¥×¥í¡¼¥É (NMU) ¤ò¹Ô¤Ê¤¦¾ì¹ç¡¢
-¥Ð¡¼¥¸¥ç¥óÈÖ¹æ¤Î <var>debian-revision</var> Éôʬ (ºÇ¸å¤Î¥Ï¥¤¥Õ¥ó°Ê¹ß¤ÎÉôʬ)
-¤Ë¿·¤¿¤Ê¥Þ¥¤¥Ê¡¼¥Ð¡¼¥¸¥ç¥óÈÖ¹æ¤òÄɲ䷤ʤ±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó
-¤³¤Î³ÈÄ¥¥Þ¥¤¥Ê¡¼ÈÖ¹æ¤Ï `1' ¤«¤é»Ï¤á¤é¤ì¤Þ¤¹¡£
-Î㤨¤Ð¡¢1.1-3 ¤È¤¤¤¦¥Ð¡¼¥¸¥ç¥ó¤Î `foo'
-¤È¤¤¤¦¥Ñ¥Ã¥±¡¼¥¸¤Î¾ì¹ç¤ò¹Í¤¨¤Æ¤ß¤Þ¤·¤ç¤¦¡£
-Debian ¥¢¡¼¥«¥¤¥Ö¤Ë¤ª¤¤¤Æ¤Ï¡¢¤½¤Î¥½¡¼¥¹¥Ñ¥Ã¥±¡¼¥¸¤ÎÀ©¸æ¥Õ¥¡¥¤¥ë¤Ï¡¢
-<file>foo_1.1-3.dsc</file> ¤Ë¤Ê¤ê¤Þ¤¹¡£
-¤Ä¤Þ¤ê¡¢¥¢¥Ã¥×¥¹¥È¥ê¡¼¥à¥Ð¡¼¥¸¥ç¥ó¤Ï `1.1' ¤Ç¡¢
-Debian ¥Ð¡¼¥¸¥ç¥ó¤Ï `3' ¤Ç¤¹¡£
-¤½¤·¤Æ¡¢¼¡¤Î NMU ¤Ç¤Ï¿·¤¿¤Ê¥Þ¥¤¥Ê¡¼ÈÖ¹æ `.1' ¤ò Debian
-¥ê¥Ó¥¸¥ç¥ó¤ËÄɲ乤뤳¤È¤Ë¤Ê¤ê¤Þ¤¹¡£
-¤Ä¤Þ¤ê¡¢¿·¤¿¤Ê¥½¡¼¥¹À©¸æ¥Õ¥¡¥¤¥ë¤Ï <file>foo_1.1-3.1.dsc</file> ¤Ë¤Ê¤ê¤Þ¤¹¡£
- <p>
-Debian ¥ê¥Ó¥¸¥ç¥ó¥Þ¥¤¥Ê¡¼ÈÖ¹æ¤Ï¡¢¥Ñ¥Ã¥±¡¼¥¸³«È¯¼Ô¤Î¥Ð¡¼¥¸¥ç¥óÈÖ¹æ¤Î
-¤¤¤º¤ì¤«¤È¾×Æͤ·¤Ê¤¤¤è¤¦¤Ë¤¹¤ë¤¿¤á¤ËɬÍפˤʤë¤â¤Î¤Ç¤¹¡£
-¤³¤ì¤¬¤Ê¤±¤ì¤Ð¥Ñ¥Ã¥±¡¼¥¸³«È¯¼Ô¤Îºî¶È¤¬º®Í𤷤Ƥ·¤Þ¤¤¤Þ¤¹¡£
-¤Þ¤¿¡¢¤³¤¦¤¹¤ë¤³¤È¤Ë¤Ï¡¢
-Debian ¥¢¡¼¥«¥¤¥ÖÃæ¤Î¤¢¤ë¥Ñ¥Ã¥±¡¼¥¸¤¬¸ø¼°¤Ê³«È¯¼Ô¤Ë¤è¤ë¤â¤Î
-¤Ç¤Ê¤¤¤³¤È¤¬¸«¤Æ¤¹¤°¤ï¤«¤ë¤È¤¤¤¦ÍøÅÀ¤â¤¢¤ê¤Þ¤¹¡£
- <p>
-¤â¤·¥Ð¡¼¥¸¥ç¥óÈÖ¹æ¤Ë <var>debian-revision</var> Éôʬ¤¬¤Ê¤¤¾ì¹ç¤Ï¡¢
-`0.1' ¤Ç»Ï¤Þ¤ë¤è¤¦¤ËÄɲ䷤ʤ±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¡£
-Àµµ¬¤Î³«È¯¼Ô°Ê³°¤Î狼¤¬¡¢¿·¤¿¤Ê¥¢¥Ã¥×¥¹¥È¥ê¡¼¥à¥Ð¡¼¥¸¥ç¥ó¥Ù¡¼¥¹¤Î¥ê¥ê¡¼¥¹
-¤ò¤É¤¦¤·¤Æ¤â¹Ô¤Ê¤¦É¬Íפ¬¤¢¤ë¾ì¹ç¤Ï¡¢`0.1' ¤È¤¤¤¦ <var>debian-revision</var>
-¤òÉÕ¤±¤Æ¥ê¥ê¡¼¥¹¤ò¹Ô¤Ê¤Ã¤Æ¤¯¤À¤µ¤¤¡£
-Àµµ¬¤Î¥Ñ¥Ã¥±¡¼¥¸³«È¯¼Ô¤Î¾ì¹ç¤Ï¡¢
-<var>debian-revision</var> ¤ò `1' ¤«¤é»Ï¤á¤Æ¤¯¤À¤µ¤¤¡£
-¤¿¤À¤³¤Á¤é¤ò¹Ô¤Ê¤¦¾ì¹ç¡¢
-¹½ÃÛ¥·¥¹¥Æ¥à¤Ë¿·¤¿¤Ê¥½¡¼¥¹¥Ñ¥Ã¥±¡¼¥¸¤ò¶¯À©Åª¤ËÁªÂò¤µ¤»¤ë¤¿¤á¤Ë¡¢
-<tt>-sa</tt> ¥¹¥¤¥Ã¥Á¤òÉÕ¤±¤Æ <prgn>dpkg-buildpackage</prgn>
-¤òµ¯Æ°¤¹¤ëɬÍפ¬¤¢¤ë¤Ç¤·¤ç¤¦¡£
-(ÉáÄ̤³¤Î¥×¥í¥°¥é¥à¤Ï¡¢Debian ¥ê¥Ó¥¸¥ç¥ó ¤¬ '0' ¤¢¤ë¤¤¤Ï '1'
-¤«¤É¤¦¤«¤Î¤ß¤ò³Îǧ¤·¤Þ¤¹¡£
--- `0.1' ¤È¤¤¤¦¿ô»ú¤òǧ¼±¤¹¤ë¤Û¤É¤Ë¤Ï¤Þ¤À¸¤¯¤Ê¤¤¤Î¤Ç¤¹¡£)
- <p>
-Ãí°Õ¤·¤Æ¤¤¤¿¤À¤¤¿¤¤¤Î¤Ç¤¹¤¬¡¢°Ü¿¢ºî¶È¼Ô¤¬°Û¤Ê¤ë¥¢¡¼¥¥Æ¥¯¥Á¥ã¸þ¤±¤Ë
-¥Ñ¥Ã¥±¡¼¥¸¤òñ¤ËºÆ¥³¥ó¥Ñ¥¤¥ë¤¹¤ë¾ì¹ç¤Ï¡¢
-¥Ð¡¼¥¸¥ç¥óÈÖ¹æ¤òÉÕ¤±Ä¾¤¹É¬ÍפϤ¢¤ê¤Þ¤»¤ó¡£
-°Ü¿¢ºî¶È¼Ô¤Ï¡¢²¿¤é¤«¤ÎÊýË¡¤Ç¥½¡¼¥¹¥Ñ¥Ã¥±¡¼¥¸¤ËÊѹ¹¤ò²Ã¤¨¤¿¾ì¹ç¡¢
-¤Ä¤Þ¤ê¡¢binary NMU ¤Ç¤Ï¤Ê¤¯ source NMU ¤ò¹Ô¤Ê¤¦¾ì¹ç (¤Î¤ß)¡¢
-¿·¤¿¤Ê¥Ð¡¼¥¸¥ç¥óÈÖ¹æ¤òÍѤ¤¤ë¤Ù¤¤Ç¤¹¡£
-
- <sect1 id="nmu-changelog">
- <heading>source NMU ¤Ï¿·¤¿¤Ê changelog ¥¨¥ó¥È¥ê¤òɬÍפȤ¹¤ë</heading>
- <p>
-source NMU ¤ò¹Ô¤Ê¤¦Èó¸ø¼°³«È¯¼Ô¤Ï¡¢
-NMU ¤Ë¤è¤Ã¤Æ¤É¤Î¥Ð¥°¤¬½¤Àµ¤µ¤ì¤¿¤Î¤«¡¢
-¤Þ¤¿Ä̾ï¤Ï NMU ¤¬¤Ê¤¼É¬ÍפǤɤ³¤ò½¤Àµ¤·¤¿¤Î¤«¤òÀâÌÀ¤¹¤ë
-changelog ¥¨¥ó¥È¥ê¤òºîÀ®¤·¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¡£
-changelog ¥¨¥ó¥È¥ê¤Î log ¥¨¥ó¥È¥ê¤Ë¤Ï¡¢
-¤½¤ÎÈó¸ø¼°³«È¯¼Ô¤ÎÅŻҥ᡼¥ë¥¢¥É¥ì¥¹¤È NMU ¥Ð¡¼¥¸¥ç¥óÈֹ椬´Þ¤á¤é¤ì¤Þ¤¹¡£</p>
- <p>
-´·Îã¤Ë¤è¤Ã¤Æ¡¢source NMU ¤Î changelog ¥¨¥ó¥È¥ê¤Ï¼¡¤Î¹Ô¤Ç»Ï¤á¤é¤ì¤Þ¤¹¡£
-
-<example>
- * Non-maintainer upload
-</example></p></sect1>
-
- <sect1 id="nmu-patch">source NMU ¤È¥Ð¥°ÄÉÀ×¥·¥¹¥Æ¥à
- <p>
-¸ø¼°¤Ê¥Ñ¥Ã¥±¡¼¥¸³«È¯¼Ô°Ê³°¤Î³«È¯¼Ô¤¬¥Ñ¥Ã¥±¡¼¥¸¤ËÊѹ¹¤ò²Ã¤¨¤ë¾ì¹ç¡¢
-¤½¤ÎÊѹ¹¤Ï¤Ê¤ë¤Ù¤¯¾®¤µ¤Ê¤â¤Î¤Ëα¤á¤ë¤Ù¤¤Ç¤¹¡£
-¤Þ¤¿¡¢Êѹ¹²Õ½ê¤ò¾Ü¤·¤¯ÀâÌÀ¤¹¤ë¤¿¤á¤Ëɬ¤º¡¢
-¤½¤Î¥Ñ¥Ã¥Á¤ò unified context diff (<tt>diff -u</tt>)
-¤Î·Á¤Ç¥Ð¥°ÄÉÀ×¥·¥¹¥Æ¥à¤ËÁ÷¤ë¤Ù¤¤Ç¤¹¡£
- <p>
-ñ¤Ë¥Ñ¥Ã¥±¡¼¥¸¤òºÆ¥³¥ó¥Ñ¥¤¥ë¤¹¤ë¾ì¹ç¤Ï¤É¤¦¤¹¤ë¤Î¤Ç¤·¤ç¤¦¤«¡©
-¤³¤Î¾ì¹ç¡¢¤¹¤Ç¤Ë½Ò¤Ù¤¿¤è¤¦¤Ë°Ü¿¢ºî¶È¼Ô¤Î¾ì¹ç¤ÈÈó°Ü¿¢ºî¶È¼Ô¤Î¾ì¹ç¤Ç¤Ï
-¤½¤Î¼ê½ç¤¬°Û¤Ê¤ê¤Þ¤¹¡£
-°Ü¿¢ºî¶È¼Ô¤Ç¤Ï¤Ê¤¤³«È¯¼Ô¤¬Ã±¤ËºÆ¥³¥ó¥Ñ¥¤¥ë¤¬É¬ÍפʤÀ¤±¤Î NMU ¤ò¹Ô¤Ê¤¦¾ì¹ç¡¢
-(¤Ä¤Þ¤ê¡¢¿·¤¿¤Ê¶¦Í¥é¥¤¥Ö¥é¥ê¤¬ÍøÍѤǤ¤ë¤è¤¦¤Ë¤Ê¤Ã¤¿¾ì¹ç¤ä
-<package>debhelper</package> ¤Ç¥Ð¥°½¤Àµ¤¬¹Ô¤Ê¤ï¤ì¤¿¾ì¹ç)
-¤ä¤Ï¤ê changelog ¥¨¥ó¥È¥ê¤¬É¬Íפˤʤꡢ
-¤½¤ì¤æ¤¨¥Ñ¥Ã¥Á¤¬Â¸ºß¤¹¤ë¤³¤È¤Ë¤Ê¤ê¤Þ¤¹¡£
-°ìÊý¡¢°Ü¿¢ºî¶È¼Ô¤Î¾ì¹ç¤Ï¡¢¤ª¤½¤é¤¯Ã±¤Ë binary NMU ¤ò¹Ô¤Ê¤¦¤³¤È¤Ë¤Ê¤ê¤Þ¤¹¡£
-(Ãí°Õ: ¤³¤Î¤³¤È¤Ï¡¢ËÜÍèºÆ¥³¥ó¥Ñ¥¤¥ë¤ò¤·¤Ê¤±¤ì¤Ð¤Ê¤é¤Ê¤¤°Ü¿¢ºî¶È¼Ô¤¬
-¤½¤ì¤ò¹Ô¤Ê¤ï¤Ê¤¤¤³¤È¤Ë´Ø¤·¤Æ¤Ï¹Íθ¤·¤Æ¤¤¤Þ¤»¤ó¡£
--- ¤³¤Á¤é¤Ï¡¢»ä¤¿¤Á¤Î¥¢¡¼¥«¥¤¥Ö´ÉÍý¤Ë´Ø¤¹¤ëÌäÂêÅÀ¤Î°ì¤Ä¤Ç¤·¤ç¤¦¡£)
- <p>
-source NMU (¥Î¥ó¥á¥ó¥Æ¥Ê¥¢¥Ã¥×¥í¡¼¥É) ¤Ë¤è¤Ã¤Æ
-¥Ð¥°ÄÉÀ×¥·¥¹¥Æ¥à¤ËÅÐÏ¿¤µ¤ì¤Æ¤¤¤ë´û¸¤Î¥Ð¥°¤ò½¤Àµ¤·¤¿¾ì¹ç¡¢
-Èó¸ø¼°³«È¯¼Ô¤Ï¤½¤Î¥Ð¥°¤ò<em>¥¯¥í¡¼¥º</em>¤¹¤ë¤Î¤Ç¤Ï¤Ê¤¯¡¢
-¤½¤Î»Ý¤ò<em>ÄÌÃÎ</em>¤·¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¡£
-µ¬Â§¤Î¾å¤Ç¤Ï¡¢¥Ð¥°¤ò¥¯¥í¡¼¥º¤¹¤ë¤³¤È¤¬¤Ç¤¤ë¤Î¤Ï¡¢
-¸ø¼°¥Ñ¥Ã¥±¡¼¥¸³«È¯¼Ô¤«¸µ¤Î¥Ð¥°Êó¹ð¼Ô¤Î¤ß¤Ç¤¹¡£
-¤·¤«¤·¤Ê¤¬¤é¡¢¥Î¥ó¥á¥ó¥Æ¥Ê¥ê¥ê¡¼¥¹¤ò¹Ô¤Ê¤Ã¤¿¼Ô¤Ï¡¢Å¬ÀڤʥХ°¤ËÂФ·¤Æ¡¢
-¤½¤Î¥Ð¥°¤¬ NMU ¤Ë¤è¤Ã¤Æ½¤Àµ¤µ¤ì¤¿¤³¤È¤òÀâÌÀ¤¹¤ë
-¼êû¤Ê¥á¥Ã¥»¡¼¥¸¤òÁ÷ÉÕ¤·¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¡£
-¤Þ¤¿¡¢<email>control@bugs.debian.org</email> ¤òÍøÍѤ¹¤ë¾ì¹ç¡¢
-NMU ¤ò¹Ô¤Ê¤Ã¤¿Åö»ö¼Ô¤Ï NMU ¤Ç½¤Àµ¤·¤¿¥Ð¥°¤Î½ÅÍ×ÅÙ¤ò `fixed'
-¤ËÀßÄꤷ¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¡£
-¤³¤¦¤¹¤ë¤³¤È¤Ë¤è¤Ã¤Æ¡¢¤½¤Î¥Ð¥°¤¬ NMU ¤Ë¤è¤Ã¤Æ½¤Àµ¤µ¤ì¤¿¤³¤È¤ò¡¢
-³Î¼Â¤Ë³§¤ËÃΤ餻¤ë¤³¤È¤¬¤Ç¤¤ë¤ï¤±¤Ç¤¹¡£
-¤¿¤À¡¢NMU ¤Ç²Ã¤¨¤é¤ì¤¿Êѹ¹¤¬¡¢¸ø¼°¤Ê¥Ñ¥Ã¥±¡¼¥¸³«È¯¼Ô¤Ë¤è¤Ã¤ÆÀµ¼°¤ËºÎÍѤµ¤ì
-¤ë¤Þ¤Ç¡¢¤½¤Î¥Ð¥°¤Ï³«¤«¤ì¤¿¤Þ¤Þ¤Ç¤¹¡£
-¤Þ¤¿¡¢¤½¤ÎÌäÂê¤ò½¤Àµ¤¹¤ë¤¿¤á¤ËɬÍפȤʤë¥Ñ¥Ã¥Á¤òź¤¨¤Æ¥Ð¥°¤ò¥ª¡¼¥×¥ó¤¹¤ë¤«¡¢
-(¤¹¤Ç¤Ë¥ª¡¼¥×¥ó¤µ¤ì¤Æ¤¤¤ë)
-¾¤Î¥Ð¥°Êó¹ð¤Î¤¤¤º¤ì¤«¤Ë¤½¤Î¥Ñ¥Ã¥Á¤òÄɲ䷤Ƥ¯¤À¤µ¤¤¡£
- <p>
-Àµµ¬¤Î³«È¯¼Ô¤Ï¡¢¤½¤Î¥Ñ¥Ã¥Á¤òºÎÍѤ¹¤ë¤«¡¢
-¤¢¤ë¤¤¤Ï¤½¤ÎÌäÂê¤ò½¤Àµ¤¹¤ë¾¤ÎÊýÅÓ¤òÍѤ¤¤ë¤³¤È¤Ë¤Ê¤ê¤Þ¤¹¡£
-»þ¤Ë¤Ï¥Ð¥°¤¬¥¢¥Ã¥×¥¹¥È¥ê¡¼¥à¤ÇÆȼ«¤Ë½¤Àµ¤µ¤ì¤ë¤³¤È¤â¤¢¤ê¤Þ¤¹¡£
-¤³¤Î¤³¤È¤Ï NMU ¤Ë¤è¤ë¥Ñ¥Ã¥Á¤¬Âऱ¤é¤ì¤ë½½Ê¬¤ÊÍýͳ¤Î¤Ò¤È¤Ä¤Ç¤¹¡£
-¿·¤¿¤Ê¥Ð¡¼¥¸¥ç¥ó¤ò¥ê¥ê¡¼¥¹¤¹¤ëºÝ¤Ë¡¢
-Àµµ¬¤Î³«È¯¼Ô¤¬ NMU ¤Ë¤è¤ë¥Ñ¥Ã¥Á¤òºÎÍѤ·¤Ê¤¤¾ì¹ç¡¢
-¤½¤Î³«È¯¼Ô¤Ï¥Î¥ó¥á¥ó¥Æ¥Ê¥ê¥ê¡¼¥¹¤Ç½¤Àµ¤µ¤ì¤¿ÌäÂê¤Î¤½¤ì¤¾¤ì¤¬
-¿·¤¿¤Ê¥¢¥Ã¥×¥¹¥È¥ê¡¼¥à¥Ð¡¼¥¸¥ç¥ó¤Ç³Î¼Â¤Ë½¤Àµ¤µ¤ì¤Æ¤¤¤ë¤³¤È
-¤òÊݾڤ·¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¡£
- <p>
-¤µ¤é¤ËÀµµ¬¤Î³«È¯¼Ô¤Ï¡¢changelog ¥Õ¥¡¥¤¥ë¤Î¥¨¥ó¥È¥ê¤Ë
-¥Î¥ó¥á¥ó¥Æ¥Ê¥¢¥Ã¥×¥í¡¼¥É¤Ë´Ø¤¹¤ëµ½Ò¤ò
-<em>¾ï¤Ë</em>»Ä¤¹¤è¤¦¤Ë¤·¤Æ¤ª¤«¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¡£
-
- <sect1 id="nmu-build">source NMU ¤Î¹½ÃÛ
- <p>
-source NMU ¥Ñ¥Ã¥±¡¼¥¸¤Ï¡¢Ä̾ï¤É¤ª¤ê¤Ë¹½ÃÛ¤µ¤ì¤Þ¤¹¡£
-¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤ÎÁªÂò¤Ë¤Ï¡¢
-<ref id="upload-dist"> ¤ÇÀâÌÀ¤·¤¿¤â¤Î¤ÈƱ¤¸¥ë¡¼¥ë¤¬Å¬ÍѤµ¤ì¤Þ¤¹¡£
-¤Þ¤¿ <ref id="uploading"> ¤ÇÀâÌÀ¤·¤¿¤È¤ª¤ê¡¢
-Ä̾ï¤Î changes ¥Õ¥¡¥¤¥ë¤Ê¤É¤¬¹½ÃÛ¤µ¤ì¤Þ¤¹¡£
-¼ÂºÝ¡¢<ref id="upload"> ¤ÇÀâÌÀ¤·¤¿¥ë¡¼¥ë¤Ï¡¢
-ŬÀڤʥ᡼¥ê¥ó¥°¥ê¥¹¥È¤Ø¤Î NMU ¤Î¥¢¥Ê¥¦¥ó¥¹¤ÎɬÍ×À¤â´Þ¤á¤Æ
-¤¹¤Ù¤ÆŬÍѤµ¤ì¤Þ¤¹¡£
- <p>
-<file>debian/control</file> ¥Õ¥¡¥¤¥ë¤Ë¤¢¤ë³«È¯¼Ô¤Î̾Á°¤Ï¡¢
-Êѹ¹¤·<em>¤Ê¤¤</em>¤è¤¦¤Ëµ¤¤ò¤Ä¤±¤Æ¤¯¤À¤µ¤¤¡£
-¤Ê¤ª¡¢<file>debian/changelog</file> ¥Õ¥¡¥¤¥ë¤Î NMU ¥¨¥ó¥È¥ê¤Ë¤¢¤ë
-¤¢¤Ê¤¿¤Î̾Á°¤Ï¡¢changes ¥Õ¥¡¥¤¥ë¤Ë½ð̾¤¹¤ëºÝ¤ËÍѤ¤¤é¤ì¤Þ¤¹¡£
-
- <chapt id="porting">°Ü¿¢ºî¶È¤È°Ü¿¢ÈÇ
- <p>
-Debian ¤¬¥µ¥Ý¡¼¥È¤¹¤ë¥¢¡¼¥¥Æ¥¯¥Á¥ã¤Ïº£¤Ê¤ªÁý²Ã¤·¤Æ¤¤¤Þ¤¹¡£
-°Ü¿¢ºî¶È¼Ô¤Ç¤Ê¤¤¾ì¹ç¤ä¡¢ÆÃÄê¤Î¥¢¡¼¥¥Æ¥¯¥Á¥ã°Ê³°¤òÍøÍѤ·¤Ê¤¤¾ì¹ç¤Ç¤â¡¢
-³«È¯¼Ô¤È¤·¤Æ¥Ý¡¼¥¿¥Ó¥ê¥Æ¥£¤ÎÌäÂê¤ò°Õ¼±¤·¤Æ¤ª¤¯¤³¤È¤ÏɬÍפǤ·¤ç¤¦¡£
-¤½¤Î¤¿¤á¡¢°Ü¿¢ºî¶È¼Ô¤Ç¤Ê¤¤Êý¤â¡¢¤³¤Á¤é¤Î¾Ï¤Ï¤¢¤é¤«¤¿Æɤó¤Ç¤ª¤¯¤Ù¤¤Ç¤¹¡£
- <p>
-°Ü¿¢ºî¶È¤È¤Ï¡¢¥Ñ¥Ã¥±¡¼¥¸³«È¯¼Ô¤Î¥Ð¥¤¥Ê¥ê¥Ñ¥Ã¥±¡¼¥¸¤¬¹½ÃÛ¤µ¤ì¤¿
-¸µ¤Î¥¢¡¼¥¥Æ¥¯¥Á¥ã¤È¤Ï°Û¤Ê¤ë¥¢¡¼¥¥Æ¥¯¥Á¥ã¸þ¤±¤Ë Debian
-¥Ñ¥Ã¥±¡¼¥¸¤ò¹½ÃÛ¤¹¤ë¤³¤È¤ò»Ø¤·¤Þ¤¹¡£
-¤³¤Á¤é¤ÏÆȼ«¤ÎɬÍפʳèÆ°¤Ç¤¹¡£
-»ö¼Â¡¢ÂçȾ¤Î Debian ¥Ñ¥Ã¥±¡¼¥¸¤ò¼ÂºÝ¤Ë¥³¥ó¥Ñ¥¤¥ë¤·¤Æ¤¤¤ë¤Î¤Ï°Ü¿¢ºî¶È¼Ô¤Ç¤¹¡£
-Î㤨¤Ð¡¢<em>i386</em> ÍѤ˥³¥ó¥Ñ¥¤¥ë¤µ¤ì¤¿¥Ð¥¤¥Ê¥ê¥Ñ¥Ã¥±¡¼¥¸¤ò
-³Æ¥¢¡¼¥¥Æ¥¯¥Á¥ãÍѤ˺ƥ³¥ó¥Ñ¥¤¥ë¤¹¤ëɬÍפ¬¤¢¤ê¤Þ¤¹¤·¡¢
-¤½¤Î¤¿¤á¤Ë¤Ï¤ª¤è¤½¸Þ²ó°Ê¾å¹½ÃÛ¤ò¹Ô¤Ê¤ï¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¡£
-
- <sect id="kind-to-porters">°Ü¿¢ºî¶È¼Ô¤Ø¤ÎÇÛθ
- <p>
-°Ü¿¢ºî¶È¼Ô¤Ï¡¢ËÄÂç¤Ê¿ô¤Î¥Ñ¥Ã¥±¡¼¥¸¤ò½èÍý¤·¤Ê¤±¤ì¤Ð¤Ê¤é¤Ê¤¤¤¿¤á¤Ë¡¢
-º¤Æñ¤ÊÆȼ«¤Îºî¶È¤ò¹Ô¤Ê¤¤¤Þ¤¹¡£
-ÍýÁۤȤ·¤Æ¤Ï¡¢Á´¥½¡¼¥¹¥Ñ¥Ã¥±¡¼¥¸¤¬¤µ¤Þ¤¶¤Þ¤Ê¥¢¡¼¥¥Æ¥¯¥Á¥ã¤Ç
-ŬÀڤ˹½ÃÛ¤µ¤ì¤ë¤Ù¤¤Ê¤Î¤Ç¤¹¤¬¡¢»ÄÇ°¤Ê¤¬¤é¤½¤¦¤¦¤Þ¤¯¤Ï¹Ô¤¤Þ¤»¤ó¡£
-¤³¤ÎÀá¤Ç¤Ï¡¢Debian ³«È¯¼Ô¤é¤Ë¤è¤Ã¤Æ¤·¤Ð¤·¤Ð»ØŦ¤µ¤ì¤ë¡Ö´ûÃΡפγÎǧ¹àÌÜ
--- °Ü¿¢ºî¶È¼Ô¤òº¤¤é¤»¤¿¤ê¡¢
-¤½¤Îºî¶È¤òÉÔɬÍפ˺¤Æñ¤Ë¤µ¤»¤ë¶¦Ä̤ÎÌäÂê¤ò¼è¤ê¾å¤²¤Þ¤¹¡£
- <p>
-¤Þ¤ºÂè°ì¤Ë¾å¤²¤é¤ì¤ëºÇ¤â½ÅÍפʥâ¥Ã¥È¡¼¤Ï¡¢
-°Ü¿¢ºî¶È¼Ô¤Ë¤è¤Ã¤Æ»ØŦ¤µ¤ì¤¿¥Ð¥°¤äÌäÂê¤Ë¤ÏÁÇÁ᤯Âбþ¤¹¤ë¤È¤¤¤¦¤³¤È¤Ç¤¹¡£
-°Ü¿¢ºî¶È¼Ô¤ËÂФ·¤Æ¤Ï¡¢
-¤¢¤Ê¤¿¤Î¥Ñ¥Ã¥±¡¼¥¸¤Î¼ÂºÝ¤Î¶¨Æ±³«È¯¼Ô¤ËÂФ¹¤ë¤Î¤ÈƱ¤¸¤è¤¦¤Ë¡¢
-Ãú½Å¤ËÂбþ¤·¤Æ¤¯¤À¤µ¤¤¡£(¤¢¤ë°ÕÌ£¤Ç¤ÏÈà¤é¤Ï¶¨Æ±³«È¯¼Ô¤Ç¤¹¡£)
- <p>
-¼ÂºÝ¡¢°Ü¿¢ºî¶È¼Ô¤¬½Ð¤¯¤ï¤¹ÌäÂê¤ÎÂçȾ¤Ï¡¢
-¥½¡¼¥¹¥Ñ¥Ã¥±¡¼¥¸¤Ë¤ª¤±¤ë<em>¥Ñ¥Ã¥±¡¼¥¸¥ó¥°¾å¤Î¥Ð¥°</em>¤Ê¤Î¤Ç¤¹¡£
-°Ê²¼¤¬³Îǧ¤·Ãí°Õ¤¹¤Ù¤»öÊÁ¤Î³Îǧ¹àÌܤǤ¹¡£
-<enumlist>
- <item>
-``all'' ¤ä ``any'' °Ê³°¤ÎÃͤò¥¢¡¼¥¥Æ¥¯¥Á¥ã¤È¤·¤ÆÀßÄꤹ¤ë¤³¤È¤Ï¡¢
-¤½¤Î¤³¤È¤òËÜÅö¤Ë°Õ¿Þ¤·¤Æ¤¤¤Ê¤¤¸Â¤ê¡¢¹Ô¤Ê¤ï¤Ê¤¤¤Ç¤¯¤À¤µ¤¤¡£
-ÂçÊÑ¿¤¯¤Î¥±¡¼¥¹¤Ç¡¢³«È¯¼Ô¤¬
-<url id="http://www.debian.org/doc/packaging-manuals/packaging.html/"
-name="Debian ¥Ñ¥Ã¥±¡¼¥¸¥ó¥°¥Þ¥Ë¥å¥¢¥ë">
-¤ÎÀâÌÀ¤Ë¤·¤¿¤¬¤Ã¤Æ¤¤¤Þ¤»¤ó¡£
-¥¢¡¼¥¥Æ¥¯¥Á¥ã¤ò ``i386'' ¤ËÀßÄꤹ¤ë¤³¤È¤Ï¡¢¤¿¤¤¤Æ¤¤¤Î¤È¤³¤í´Ö°ã¤¤¤Ç¤¹¡£
- <item>
-ºîÀ®¤·¤¿¥½¡¼¥¹¥Ñ¥Ã¥±¡¼¥¸¤¬Àµ¤·¤¤¤â¤Î¤Ç¤¢¤ë¤³¤È¤ò³Îǧ¤·¤Æ¤¯¤À¤µ¤¤¡£
-<tt>dpkg-source -x <var>package</var>.dsc</tt> ¤ò¼Â¹Ô¤·¤Æ¡¢
-¤¢¤Ê¤¿¤Î¥½¡¼¥¹¥Ñ¥Ã¥±¡¼¥¸¤¬Å¬Àڤ˟³«¤Ç¤¤ë¤³¤È¤ò³Îǧ¤·¤Æ¤¯¤À¤µ¤¤¡£
-¤½¤ì¤«¤é¡¢¤½¤³¤Ç <tt>dpkg-buildpackage</tt> ¤òÍѤ¤¡¢
-°ì¤«¤é¤¢¤Ê¤¿¤Î¥Ñ¥Ã¥±¡¼¥¸¤ò¹½ÃÛ¤·¤Æ¤ß¤Æ¤¯¤À¤µ¤¤¡£
- <item>
-<file>debian/files</file> ¥Õ¥¡¥¤¥ë¤ä <file>debian/substvars</file>
-¥Õ¥¡¥¤¥ë¤ò»Ä¤·¤¿¤Þ¤Þ¡¢¥½¡¼¥¹¥Ñ¥Ã¥±¡¼¥¸¤ò¥¢¥Ã¥×¥í¡¼¥É¤·¤Ê¤¤¤Ç¤¯¤À¤µ¤¤¡£
-¤³¤ì¤é¤Î¥Õ¥¡¥¤¥ë¤Ï¡¢<file>debian/rules</file> ¤Î `clean'
-¥¿¡¼¥²¥Ã¥È¤Ë¤è¤Ã¤Æ¾Ãµî¤µ¤ì¤Æ¤¤¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¡£
- <item>
-¥í¡¼¥«¥ë¤Ë¥¤¥ó¥¹¥È¡¼¥ë¤µ¤ì¤¿¤ê¼ê¤ò²Ã¤¨¤é¤ì¤¿
-ÀßÄê¤ä¥×¥í¥°¥é¥à¤Ë°Í¸¤·¤Æ¤¤¤Ê¤¤¤³¤È¤ò³Î¤«¤á¤Æ¤¯¤À¤µ¤¤¡£
-Î㤨¤Ð¡¢<file>/usr/local/bin</file>
-¤ä¤½¤ì¤ËÎह¤ë¥Ç¥£¥ì¥¯¥È¥ê¤Ë¤¢¤ë¥×¥í¥°¥é¥à¤ò¸Æ¤Ó½Ð¤·¤Æ¤Ï¤¤¤±¤Þ¤»¤ó¡£
-¥×¥í¥°¥é¥à¤¬Æüì¤ÊÊýË¡¤Ç¥»¥Ã¥È¥¢¥Ã¥×¤µ¤ì¤ë¤³¤È¤ò
-Åö¤Æ¤Ë¤·¤Ê¤¤¤Ç¤¯¤À¤µ¤¤¡£
-¤Þ¤¿¡¢¤¢¤Ê¤¿¤Î¥Ñ¥Ã¥±¡¼¥¸¤ò¡¢
-Ʊ°ì¥¢¡¼¥¥Æ¥¯¥Á¥ã¤Ç¤â¤«¤Þ¤¤¤Þ¤»¤ó¤Î¤Ç¡¢Â¾¤Î¥Þ¥·¥ó¤Ç¹½ÃÛ¤·¤Æ¤ß¤Æ¤¯¤À¤µ¤¤¡£
- <item>
-(¾åµ¤Î¤³¤È¤Ë¤â´Þ¤Þ¤ì¤ë¤³¤È¤Ç¤¹¤¬¡¢)
-¤¢¤Ê¤¿¤Ç¹½ÃÛ¤µ¤ì¤¿¥Ñ¥Ã¥±¡¼¥¸¤ò¤¹¤Ç¤Ë¥¤¥ó¥¹¥È¡¼¥ë¤µ¤ì¤Æ¤¤¤ë¤â¤Î¤È
-²¾Äꤷ¤Æ¤Ï¤¤¤±¤Þ¤»¤ó¡£
- <item>
-<prgn>egcc</prgn> ¤¬ÍøÍѤǤ¤ë¤â¤Î¤È²¾Äꤷ¤Æ¤Ï¤¤¤±¤Þ¤»¤ó¡£
-¤Þ¤¿¡¢ÆÃÄê¤Î¥Ð¡¼¥¸¥ç¥ó¤Î <prgn>gcc</prgn> ¤Ë°Í¸¤·¤Æ¤Ï¤¤¤±¤Þ¤»¤ó¡£
- <item>
-Debian ¥Ñ¥Ã¥±¡¼¥¸¥ó¥°¥Þ¥Ë¥å¥¢¥ë¤ÇÍ׵ᤵ¤ì¤Æ¤¤¤ëÄ̤ê¤Ë¡¢
-``binary-arch'' ¥¿¡¼¥²¥Ã¥È¤È ``binary-indep'' ¥¿¡¼¥²¥Ã¥È¤Ï
-debian/rules ¤ËÊÌ¡¹¤Ë¼ýÏ¿¤·¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¡£
-¤³¤Îξ¥¿¡¼¥²¥Ã¥È¤¬¤½¤ì¤¾¤ìÆÈΩ¤·¤ÆÆ°ºî¤¹¤ë¤³¤È¡¢
-¤Ä¤Þ¤ê¡¢¤¢¤ë¥¿¡¼¥²¥Ã¥È¤ò¸Æ¤Ó½Ð¤¹ºÝ¤Ë
-¾¤Î¥¿¡¼¥²¥Ã¥È¤òÁ°¤â¤Ã¤Æ¸Æ¤Ó½Ð¤·¤Æ¤¤¤Ê¤¤¤³¤È¤ò³Îǧ¤·¤Æ¤¯¤À¤µ¤¤¡£
-¤³¤Á¤é¤ò¥Æ¥¹¥È¤¹¤ë¤Ë¤Ï¡¢<tt>dpkg-buildpackage -b</tt>
-¤ò¼Â¹Ô¤·¤Æ¤ß¤Æ¤¯¤À¤µ¤¤¡£
- </enumlist>
-
- <sect id="porter-guidelines">°Ü¿¢ºî¶È¼Ô¤Ë¤è¤ë¥¢¥Ã¥×¥í¡¼¥É¤Ë´Ø¤¹¤ë¥¬¥¤¥É¥é¥¤¥ó
- <p>
-°Ü¿¢Àè¤Î¥¢¡¼¥¥Æ¥¯¥Á¥ãÍѤΥХ¤¥Ê¥ê¤ò¼è¤ê½Ð¤·¤¿¤È¤¤Î¤Þ¤Þ¤Ç¹½ÃۤǤ¤ë¤Ê¤é¡¢
-ºî¶È¤â¤Ï¤«¤É¤ë¤Ç¤·¤ç¤¦¡£
-¤³¤ÎÀá¤Ç°·¤¦¤Î¤Ï¤³¤Î¤è¤¦¤Ê¾ì¹ç¤Ç¡¢¸ÀÍÕ¤òÊѤ¨¤ì¤Ð¡¢
-ŬÀڤ˥¢¡¼¥«¥¤¥Ö¤Ë¥¤¥ó¥¹¥È¡¼¥ë¤Ç¤¤ë¤è¤¦¤Ë¡¢
-¥Ð¥¤¥Ê¥ê¤ò¹½ÃÛ¤· binary NMU ¤ò¥¢¥Ã¥×¥í¡¼¥É¤¹¤ëÊýË¡¤òÀâÌÀ¤·¤Þ¤¹¡£
-¾¤Î¥¢¡¼¥¥Æ¥¯¥Á¥ã¸þ¤±¤Ë¥³¥ó¥Ñ¥¤¥ë¤òÄ̤¹¤¿¤á¤Ë¡¢
-¥Ñ¥Ã¥±¡¼¥¸¤Ë¥Ñ¥Ã¥Á¤òÅö¤Æ¤Ê¤¯¤Æ¤Ï¤Ê¤é¤Ê¤¤¾ì¹ç¤Ï¡¢
-source NMU ¤ò¹Ô¤Ê¤ï¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¡£
-¤³¤Á¤é¤Ë´Ø¤·¤Æ¤Ï <ref id="nmu-guidelines"> ¤ò¤´»²¾È¤¯¤À¤µ¤¤¡£
- <p>
-binary NMU ¤ò¹Ô¤Ê¤¦¾ì¹ç¡¢¤½¤Î¥½¡¼¥¹¤ËÂФ·¤Æ¤Ï°ìÀÚÊѹ¹¤ò¹Ô¤Ê¤¤¤Þ¤»¤ó¡£
-¥½¡¼¥¹¥Ñ¥Ã¥±¡¼¥¸Ãæ¤Î¤¤¤«¤Ê¤ë¥Õ¥¡¥¤¥ë¤ËÂФ·¤Æ¤â¼ê¤ò¤Ä¤±¤ëɬÍפϤ¢¤ê¤Þ¤»¤ó¡£
-<file>debian/changelog</file> ¤âÁ³¤ê¤Ç¤¹¡£
- <p>
-¾ì¹ç¤Ë¤è¤Ã¤Æ¤Ï¡¢¥é¥¤¥Ö¥é¥ê¤Ê¤É¤Î¹¹¿·ºÑ¤ß¤Î¾¥Ñ¥Ã¥±¡¼¥¸¤ËÂФ·¤Æ¡¢
-¤¢¤ë¥Ñ¥Ã¥±¡¼¥¸¤òºÆ¥³¥ó¥Ñ¥¤¥ë¤¹¤ëɬÍפ¬¤¢¤ë¤Ç¤·¤ç¤¦¡£
-¤³¤Î¾ì¹ç¤Ï¡¢¥¢¥Ã¥×¥°¥ì¡¼¥É¥·¥¹¥Æ¥à¤¬Å¬ÀÚ¤ËÆ°ºî¤¹¤ë¤è¤¦¤Ë¡¢
-¥Ð¡¼¥¸¥ç¥óÈÖ¹æ¤ò¾å¤²¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¡£
-¤·¤«¤·¤Ê¤¬¤é¡¢¤¿¤È¤¨¤½¤¦¤Ç¤â¡¢¤³¤ì¤é¤Ï binary ¤Î¤ß¤Î NMU ¤È¤ß¤Ê¤µ¤ì¤Þ¤¹¡£
--- ¤³¤Î¾ì¹ç¡¢Á´¥¢¡¼¥¥Æ¥¯¥Á¥ã¤ÇºÆ¥³¥ó¥Ñ¥¤¥ë¤¹¤ëɬÍפϤʤ¤¤«¤é¤Ç¤¹¡£
-NMU ¤Î¾ì¹ç¤ÈƱÍͤ˥С¼¥¸¥ç¥óÈÖ¹æ¤òÀßÄꤷ¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¤¬¡¢
-¤³¤Î¾ì¹ç¤Ï NMU ¥Ð¡¼¥¸¥ç¥ó¤ÎÁ°¤Ë ``.0.'' ¤òÉÕ¤±²Ã¤¨¤Þ¤¹¡£
-Î㤨¤Ð¡¢``foo_1.3-1'' ¤È¤¤¤¦¥½¡¼¥¹¥Ñ¥Ã¥±¡¼¥¸¤òñ¤ËºÆ¥³¥ó¥Ñ¥¤¥ë¤·¤Æ NMU
-¤¹¤ë¾ì¹ç¡¢¤½¤ÎÈÖ¹æ¤Ï ``foo_1.3-1.0.1'' ¤Ë¤Ê¤ê¤Þ¤¹¡£
- <p>
-<prgn>dpkg-buildpackage</prgn> ¤òµ¯Æ°¤¹¤ë¤Ë¤Ï¡¢
-<tt>dpkg-buildpackage -B -m<var>porter-email</var></tt>
-¤È¤·¤Æ¤¯¤À¤µ¤¤¡£
-¤â¤Á¤í¤ó <var>porter-email</var> ¤Î²Õ½ê¤Ë¤Ï
-¤¢¤Ê¤¿¤ÎÅŻҥ᡼¥ë¥¢¥É¥ì¥¹¤òÅö¤Æ¤Ï¤á¤Æ¤¯¤À¤µ¤¤¡£
-¤³¤¦¤¹¤ì¤Ð¡¢<file>debian/rules</file> ¤Î `binary-arch'
-¥¿¡¼¥²¥Ã¥È¤òÍѤ¤¤Æ¡¢³ºÅö¥Ñ¥Ã¥±¡¼¥¸¤ÎÆÃÄꥢ¡¼¥¥Æ¥¯¥Á¥ã°Í¸Éôʬ¤Ë¸Â¤Ã¤¿
-¥Ð¥¤¥Ê¥ê¹½ÃۤΤߤ¬¹Ô¤Ê¤ï¤ì¤Þ¤¹¡£
-
- <sect1 id="source-nmu-when-porter">
- <heading>°Ü¿¢ºî¶È¼Ô¤¬ source NMU ¤ò¹Ô¤Ê¤¦¾ì¹ç¤Ë¤Ï</heading>
- <p>
-°Ü¿¢ºî¶È¼Ô¤¬ source NMU ¤ò¹Ô¤Ê¤¦¾ì¹ç¡¢
-Èó°Ü¿¢ºî¶È¼Ô¤Î¾ì¹ç¤ÈƱÍͤˡ¢°ìÈÌŪ¤Ë¤Ï
-<ref id="nmu"> ¤Ë¤Æ¿¨¤ì¤¿¥¬¥¤¥É¥é¥¤¥ó¤Ë½¾¤¤¤Þ¤¹¡£
-¤·¤«¤·¤Ê¤¬¤é¡¢°Ü¿¢ºî¶È¼Ô¤Î¾ì¹ç¡¢
-ÁêÅö¤ÊÎ̤Υѥ屡¼¥¸¤ò½èÍý¤·¤Ê¤±¤ì¤Ð¤Ê¤é¤Ê¤¤¤³¤È¤«¤é¡¢
-source NMU ¤ò¤¹¤ëºÝ¤Ë¾¤Î³«È¯¼Ô¤ÎÂбþ¤òÂԤĻþ´Ö¤Ï¡¢
-Èó°Ü¿¢ºî¶È¼Ô¤Î¾ì¹ç¤è¤ê¤âû¤¤¤³¤È¤¬Ë¾¤Þ¤ì¤Æ¤¤¤Þ¤¹¡£
- <p>
-¤µ¤é¤Ë¡¢¤½¤Î¾õ¶·¤Ï
-¥¢¥Ã¥×¥í¡¼¥ÉÀè¤Î¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤Ë¤è¤Ã¤Æ¤â°Û¤Ê¤Ã¤Æ¤¤Þ¤¹¡£
-`frozen' ¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤Ø¤Î½ÅÍפʽ¤Àµ
-(¤¹¤Ê¤ï¤Á¡¢¥ê¥ê¡¼¥¹¤¬Í½Äꤵ¤ì¤Æ¤¤¤ë¥¢¡¼¥¥Æ¥¯¥Á¥ã¤Ç
-¥½¡¼¥¹¥Ñ¥Ã¥±¡¼¥¸¤Î¥³¥ó¥Ñ¥¤¥ë¤òÄ̤¹¤¿¤á¤ËɬÍפȤʤ뽤Àµ) ¤Ï¡¢
-ÂÔ¤Á»þ´Ö¤ò<em>ÃÖ¤«¤º</em>¤Ë¥¢¥Ã¥×¥í¡¼¥É¤¹¤ë¤³¤È¤¬¤Ç¤¤Þ¤¹¡£
- <p>
-°Ü¿¢ºî¶È¼Ô¤¬ `unstable' ¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤Ø¤Î NMU ¤ò¹Ô¤Ê¤¦¾ì¹ç¤â¡¢
-¾åµ¤Î°Ü¿¢ºî¶È¤Ë´Ø¤¹¤ë¥¬¥¤¥É¥é¥¤¥ó¤Ë½¾¤ï¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¤¬¡¢
-ÆóÅÀ¤Û¤É°Û¤Ê¤ëÅÀ¤â¤¢¤ê¤Þ¤¹¡£
-¤Þ¤º°ìÅÀÌܤϡ¢½½Ê¬¤È¤µ¤ì¤ëÂÔ¤Á»þ´Ö -- BTS ¤Ë¥Ð¥°¤¬Êó¹ð¤µ¤ì¤Æ¤«¤é¡¢NMU
-¤¬Ç§¤á¤é¤ì¤ë¤Þ¤Ç¤Î»þ´Ö -- ¤¬¡¢`unstable'
-¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤Ë´Ø¤¹¤ëºî¶È¤ò¹Ô¤Ê¤¦°Ü¿¢ºî¶È¼Ô¤Î¾ì¹ç¡¢7
-Æü´Ö¤Ç¤¢¤ë¤È¤¤¤¦¤³¤È¤Ç¤¹¡£
-¤Ê¤ª¡¢¤³¤Î´ü´Ö¤â¡¢
-Ã×̿Ū¤ÊÌäÂê¤ä°Ü¿¢ºî¶È¤ÎÉéô¤È¤Ê¤ëÌäÂ꤬¤¢¤ë¾ì¹ç¤Ï¡¢
-°Ü¿¢ºî¶È¥°¥ë¡¼¥×¤ÎºÛÎ̤Çû¤¯¤µ¤ì¤ë¤³¤È¤â¤¢¤ê¤¨¤Þ¤¹¡£
-(¤³¤ì¤Ï¥Ý¥ê¥·¡¼¤Ç¤Ï¤Ê¤¯¡¢
-¤¢¤¯¤Þ¤Ç¤â¥¬¥¤¥É¥é¥¤¥ó¤Ë±è¤Ã¤ÆÁê¸ß¤Ëλ¾µ¤µ¤ì¤Æ¤¤¤ë¤â¤Î¤Ç¤¹¡£
-¤´Ãí°Õ¤¯¤À¤µ¤¤¡£)
- <p>
-ÆóÅÀÌܤϡ¢source NMU ¤ò¹Ô¤Ê¤¦°Ü¿¢ºî¶È¼Ô¤¬ BTS ¤ËÊó¹ð¤¹¤ëºÝ¡¢
-¤½¤Î¥Ð¥°¤Î½ÅÍ×ÅÙ¤ò `important' °Ê¾å¤Ë¤·¤Ê¤±¤ì¤Ð¤Ê¤é¤Ê¤¤¤È¤¤¤¦¤³¤È¤Ç¤¹¡£
-¤³¤¦¤¹¤ë¤³¤È¤Ë¤è¤Ã¤Æ¡¢¥ê¥ê¡¼¥¹»þ¤Ë Debian
-¤Ç¥µ¥Ý¡¼¥È¤µ¤ì¤ëÁ´¥¢¡¼¥¥Æ¥¯¥Á¥ãÍѤΥХ¤¥Ê¥ê¤¬¡¢
-³Î¼Â¤Ëñ°ì¤Î¥½¡¼¥¹¥Ñ¥Ã¥±¡¼¥¸¤«¤é¹½ÃÛ¤µ¤ì¤ë¤³¤È¤¬Êݾڤµ¤ì¤Þ¤¹¡£
-¤µ¤Þ¤¶¤Þ¤Ê¥é¥¤¥»¥ó¥¹¤Ë½àµò¤¹¤ë¤¿¤á¤Ë¤â¡¢
-Á´¥¢¡¼¥¥Æ¥¯¥Á¥ã¤Ë¤ï¤¿¤ë¥Ð¥¤¥Ê¥ê¤ª¤è¤Ó¥½¡¼¥¹¥Ñ¥Ã¥±¡¼¥¸¤ò
-ñ°ì¤Î¥Ð¡¼¥¸¥ç¥ó¤Ç´ÉÍý¤¹¤ë¤³¤È¤Ï¡¢¶Ë¤á¤Æ½ÅÍפǤ¹¡£
- <p>
-°Ü¿¢ºî¶È¼Ô¤Ï¡¢¸½¹Ô¥Ð¡¼¥¸¥ç¥ó¤Î¥³¥ó¥Ñ¥¤¥ë´Ä¶¤ä¡¢¥«¡¼¥Í¥ë¡¢libc
-¤Ë¤ª¤¤¤Æ¤Î¤ß¥Ð¥°¤¬²óÈò¤Ç¤¤ë¤è¤¦¤Ê¥Ñ¥Ã¥Á¤ò¡¢
-Èò¤±¤ë¤è¤¦¤ËÅؤá¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¡£
-¤¿¤À¡¢¤³¤Î¤è¤¦¤Ê±þµÞ½èÃÖ¤¬É¬Íפˤʤë¾ì¹ç¤â¤¢¤ë¤Ç¤·¤ç¤¦¡£
-¥³¥ó¥Ñ¥¤¥é¤Î¥Ð¥°¤ä¤½¤ÎÎत¤ò²óÈò¤·¤Ê¤±¤ì¤Ð¤Ê¤é¤Ê¤¤¾ì¹ç¡¢
-¤½¤Î¤¿¤á¤ËÄɲä·¤¿¥³¡¼¥É¤Ë¤ÏŬÀÚ¤Ë <tt>#ifdef</tt> ¤òÍѤ¤¤Æ¤¯¤À¤µ¤¤¡£
-¤Þ¤¿¡¢¤½¤Î³°Åª¤ÊÌäÂ꤬½¤Àµ¤µ¤ì¤¿ºÝ¤Ëï¤â¤¬¤½¤Î²Õ½ê¤ò½üµî¤Ç¤¤ë¤è¤¦¤Ë¡¢
-¤¢¤Ê¤¿¤¬¹Ô¤Ê¤Ã¤¿±þµÞ½èÃÖ¤òʸ½ñ¤Ë»Ä¤·¤Æ¤ª¤¤¤Æ¤¯¤À¤µ¤¤¡£
- <p>
-¾¤Î³«È¯¼Ô¤ÎÂбþ¤òÂԤĴ֤ˡ¢°Ü¿¢ºî¶È¼Ô¤Ï
-¼«¿È¤Îºî¶È·ë²Ì¤ò¸ø³«¤¹¤ë¤¿¤á¤ËÈó¸ø¼°¤Ê¾ì½ê¤ò¹½¤¨¤ë¤³¤È¤â¤¢¤ê¤Þ¤¹¡£
-
-¤³¤Î¤³¤È¤Ï¡¢Â¾¤Î³«È¯¼Ô¤ÎÂбþ¤òÂԤĴ֤ˤª¤¤¤Æ¤â¡¢
-¤½¤Î°Ü¿¢ºî¶È¤ÎÍø±×¤ò¡¢Æ±¤¸ºî¶È¤Ë·È¤ï¤ë¾¤Î³«È¯¼Ô¤¬
-¼õ¤±¼è¤ì¤ëÍøÅÀ¤¬¤¢¤ê¤Þ¤¹¡£
-¤â¤Á¤í¤ó¡¢¤³¤Î¤è¤¦¤Ê¾ì½ê¤Ï¸ø¼°¤Ë¿ä¾©¤µ¤ì¤ë¤â¤Î¤Ç¤â
-¸ø¼°¤ÊÃϰ̤òÍ¿¤¨¤é¤ì¤¿¤â¤Î¤Ç¤â¤¢¤ê¤Þ¤»¤ó¤Î¤Ç¡¢
-¤³¤Á¤é¤òÍøÍѤµ¤ì¤ë¾ì¹ç¤Ï¤´Ãí°Õ¤¯¤À¤µ¤¤¡£
-
- <sect>°Ü¿¢ºî¶È¼ÔÍѤΥġ¼¥ë·²
- <p>
-°Ü¿¢ºî¶È¤ËÍÍѤʥġ¼¥ë¤¬¤¤¤¯¤Ä¤«ÍÑ°Õ¤µ¤ì¤Æ¤¤¤Þ¤¹¡£
-¤³¤ÎÀá¤Ç¤Ï¤³¤ì¤é¥Ä¡¼¥ë·²¤Î´Êñ¤Ê¾Ò²ð¤ò¹Ô¤Ê¤¤¤Þ¤¹¡£
-¤Ê¤ª¡¢¤³¤ì¤é¤Ë´Ø¤¹¤ë´°Á´¤Ê¾ðÊó¤Ë¤Ä¤¤¤Æ¤Ï¡¢
-³Æ¥Ñ¥Ã¥±¡¼¥¸¤Îʸ½ñ¤ä¥ê¥Õ¥¡¥ì¥ó¥¹¤ò¤´Í÷¤¯¤À¤µ¤¤¡£
-
- <sect1 id="quinn-diff">
- <heading><package>quinn-diff</package>
- <p>
-<package>quinn-diff</package> ¤Ï¡¢
-°Û¤Ê¤ë¥¢¡¼¥¥Æ¥¯¥Á¥ã´Ö¤Îº¹°Û¤ò locate ¤¹¤ë¤¿¤á¤ËÍѤ¤¤é¤ì¤Þ¤¹¡£
-Î㤨¤Ð¡¢¥¢¡¼¥¥Æ¥¯¥Á¥ã <var>X</var> ¤«¤é¥¢¡¼¥¥Æ¥¯¥Á¥ã <var>Y</var> ¤Ø¡¢
-¤É¤Î¥Ñ¥Ã¥±¡¼¥¸¤ò°Ü¿¢¤¹¤ëɬÍפ¬¤¢¤ë¤Î¤«¤ò¶µ¤¨¤Æ¤¯¤ì¤Þ¤¹¡£
-
- <sect1 id="buildd">
- <heading><package>buildd</package>
- <p>
-<package>buildd</package> ¥·¥¹¥Æ¥à¤Ï¡¢Ê¬»¶ÇÛÃÖ¤µ¤ì¤ë
-¥¯¥é¥¤¥¢¥ó¥È/¥µ¡¼¥Ð¼°¤Î¹½ÃÛ¤ª¤è¤Ó¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¥·¥¹¥Æ¥à
-¤È¤·¤ÆÍѤ¤¤é¤ì¤Þ¤¹¡£
-¤³¤Á¤é¤ÏÄ̾ï <em>auto-builders</em> ¤È¶¦¤ËÍøÍѤµ¤ì¤Þ¤¹¡£
-¤³¤Î <em>auto-builders</em> ¤Ï¡¢Ã±¤Ë°Ü¿¢¤ÎɬÍפʥѥ屡¼¥¸¤Î¥Á¥§¥Ã¥¯¥¢¥¦¥È¤È
-¼«Æ°¹½ÃÛ¤ò¹Ô¤Ê¤¦¡Ö¥¹¥ì¡¼¥Ö¡×¥Û¥¹¥È¤Ç¤¹¡£
-¤³¤Î¥·¥¹¥Æ¥à¤Ë¤Ï¡¢
-°Ü¿¢ºî¶È¼Ô¤¬¥½¡¼¥¹¥Ñ¥Ã¥±¡¼¥¸¤ò¡Ö¥Á¥§¥Ã¥¯¥¢¥¦¥È¡×¤·¤Æºî¶È¤ò¹Ô¤Ê¤¦¤¿¤á¤Î
-ÅŻҥ᡼¥ë¥¤¥ó¥¿¡¼¥Õ¥§¥¤¥¹¤â¤¢¤ê¤Þ¤¹¡£
- <p>
-<package>buildd</package> ¤Ï¤Þ¤À¥Ñ¥Ã¥±¡¼¥¸¤È¤·¤Æ¤ÏÍøÍѤǤ¤Þ¤»¤ó¤¬¡¢
-°Ü¿¢ºî¶È¤Î¿¤¯¤Ë¤ª¤¤¤Æ¸½¤ËÍøÍѤµ¤ì¤Æ¤ª¤ê¡¢
-¤Þ¤¿¶á¤¤¾ÍèÍøÍѤµ¤ì¤ë¤³¤È¤¬·×²è¤µ¤ì¤Æ¤¤¤Þ¤¹¡£
-¤³¤Á¤é¤Ë¤Ï¡¢¸½¤Ë¶Ë¤á¤ÆÍÍѤÇÉÑÈˤËÍøÍѤµ¤ì¤Æ¤¤¤ë
-<prgn>andrea</prgn> ¤ä¡¢<prgn>sbuild</prgn>¡¢
-<prgn>wanna-build</prgn>
-¤È¤¤¤Ã¤¿¥Ñ¥Ã¥±¡¼¥¸²½¤µ¤ì¤Æ¤¤¤Ê¤¤¿ô¡¹¤Î¥³¥ó¥Ý¡¼¥Í¥ó¥È¤¬´Þ¤Þ¤ì¤Æ¤¤¤Þ¤¹¡£
- <p>
-<package>buildd</package> ¤Ë¤è¤Ã¤ÆÀ¸À®¤µ¤ì¤¿
-°Ü¿¢ºî¶È¼Ô¤Ë¤È¤Ã¤Æ°ìÈÌŪ¤Ëͱפʥǡ¼¥¿¤Î¤¤¤¯¤Ä¤«¤Ï¡¢
-¥¦¥§¥Ö¾å¤Î <url id="&url-buildd;"> ¤ÇÍøÍѤǤ¤Þ¤¹¡£
-¤³¤Á¤é¤Î¥Ç¡¼¥¿¤Ë¤Ï¡¢ËèÈÕ <prgn>andrea</prgn> (¥½¡¼¥¹¤Î°Í¸´Ø·¸) ¤È
-<package>quinn-diff</package> (ºÆ¥³¥ó¥Ñ¥¤¥ë¤ÎɬÍפʥѥ屡¼¥¸)
-¤«¤é¹¹¿·¤µ¤ì¤ë¾ðÊó¤â¼ýÏ¿¤µ¤ì¤Æ¤¤¤Þ¤¹¡£
- <p>
-¤µ¤Þ¤¶¤Þ¤ÊÍÑÅÓ¤ËÌòΩ¤Ä²ÄǽÀ¤òÈë¤á¤Æ¤¤¤ë¤³¤Î¥·¥¹¥Æ¥à¤Ë¡¢
-»ä¤¿¤Á¤ÏÂ礤ʴüÂÔ¤ò´ó¤»¤Æ¤¤¤Þ¤¹¡£
-°ìÈÌŪŪ¤Ê´Ø¿´¤ò¸Æ¤Ö¤«¤É¤¦¤«¤ÏÊ̤Ǥ¹¤¬¡¢ÆÈΩ¤·¤¿³Æ³«È¯¥°¥ë¡¼¥×¤¬¡¢
-Debian ¤Î°Û¤Ê¤ë¥µ¥Ö flavor ÍѤΥ·¥¹¥Æ¥à
-(Î㤨¤Ð¡¢gcc ¥Ð¥¦¥ó¥º¥Á¥§¥Ã¥¯ÉÕ¤¤Ç¹½ÃÛ¤µ¤ì¤¿ Debian ¤Î¤¢¤ë flavor ¤Ê¤É)
-¤òÍøÍѤ¹¤ë¤³¤È¤â¤Ç¤¤Þ¤¹¡£
-¤Þ¤¿¡¢¤³¤Á¤é¤Ï Debian ¤¬¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥óÁ´ÂΤòÁÇÁ᤯ºÆ¥³¥ó¥Ñ¥¤¥ë
-¤¹¤ë¤³¤È¤â²Äǽ¤Ë¤¹¤ë¤Î¤Ç¤¹¡£
-
- <sect1 id="dpkg-cross">
- <heading><package>dpkg-cross</package>
- <p>
-<package>dpkg-cross</package> ¤Ï¡¢
-<package>dpkg</package> ¤Ë»÷¤¿ÊýË¡¤Ç¡¢
-¥¯¥í¥¹¥³¥ó¥Ñ¥¤¥ëÍѤΥ饤¥Ö¥é¥ê¤ä¥Ø¥Ã¥À¤ò¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ë¥Ä¡¼¥ë¤Ç¤¹¡£
-¤µ¤é¤Ë¡¢¥¯¥í¥¹¥³¥ó¥Ñ¥¤¥ë¤ò¥µ¥Ý¡¼¥È¤¹¤ë¤¿¤á¤Ë
-<prgn>dpkg-buildpackage</prgn> ¤ä <prgn>dpkg-shlibdeps</prgn>
-¤Îµ¡Ç½À¤â¹â¤á¤é¤ì¤Æ¤¤¤Þ¤¹¡£
-
-
- <chapt id="archive-manip">
- <heading>¥Ñ¥Ã¥±¡¼¥¸¤Î°ÜÆ°¡¢ºï½ü¡¢²þ̾¡¢°ú¤·Ñ¤®¡¢¤ß¤Ê¤·¤´²½</heading>
- <p>
-Debian ¤Î¥¢¥Ã¥×¥í¡¼¥É¼ê³¤¤Ë¤ª¤¤¤Æ¡¢
-¥¢¡¼¥«¥¤¥ÖÁàºî¤Îºî¶È¤Î¤¹¤Ù¤Æ¤¬¼«Æ°²½¤µ¤ì¤Æ¤¤¤ë¤ï¤±¤Ç¤Ï¤¢¤ê¤Þ¤»¤ó¡£
-¼«Æ°²½¤µ¤ì¤Æ¤¤¤Ê¤¤ºî¶È¤Ë´Ø¤·¤Æ¤Ï¡¢³«È¯¼Ô¤¬¼êÆ°¤Ç¹Ô¤Ê¤ï¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¡£
-¤³¤Î¾Ï¤Ç¤Ï¤½¤Î¤è¤¦¤Êºî¶È¤ÎºÝ¤Ë½¾¤¦¤Ù¤¥¬¥¤¥É¥é¥¤¥ó¤ò°·¤¤¤Þ¤¹¡£
-
- <sect>¥Ñ¥Ã¥±¡¼¥¸¤Î°ÜÆ°
- <p>
-¥Ñ¥Ã¥±¡¼¥¸¤Ï¤½¤Î¥»¥¯¥·¥ç¥ó¤¬Êѹ¹¤µ¤ì¤ë¤³¤È¤â¤¢¤ê¤Þ¤¹¡£
-Î㤨¤Ð `non-free' ¥»¥¯¥·¥ç¥ó¤Î¥Ñ¥Ã¥±¡¼¥¸¤¬¸å¤Î¥Ð¡¼¥¸¥ç¥ó¤Ç GPL
-½àµò¤È¤Ê¤Ã¤¿¾ì¹ç¡¢¤½¤Î¥Ñ¥Ã¥±¡¼¥¸¤Ï
-`main' ¤¢¤ë¤¤¤Ï `contrib' ¤Ë°ÜÆ°¤µ¤ì¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó
- <footnote>
-¤¢¤ë¥Ñ¥Ã¥±¡¼¥¸¤ò¤É¤Î¥»¥¯¥·¥ç¥ó¤Ë¼ý¤á¤ë¤Ù¤¤«¤Ë´Ø¤¹¤ë¥¬¥¤¥É¥é¥¤¥ó¤Ë¤Ä¤¤¤Æ¤Ï
-<url id="&url-debian-policy;" name="Debian ¥Ý¥ê¥·¡¼¥Þ¥Ë¥å¥¢¥ë">
-¤ò¤´Í÷¤¯¤À¤µ¤¤¡£
- </footnote>¡£
- <p>
-¤¢¤Ê¤¿¤Î¥Ñ¥Ã¥±¡¼¥¸¤Î¥»¥¯¥·¥ç¥ó¤òÊѹ¹¤·¤Ê¤±¤ì¤Ð¤Ê¤é¤Ê¤¤¾ì¹ç¡¢
-Êѹ¹Àè¤Î¥»¥¯¥·¥ç¥ó¤Ë¥Ñ¥Ã¥±¡¼¥¸¤òÀßÃÖ¤¹¤ë¤¿¤á¤Ë¡¢
-¥Ñ¥Ã¥±¡¼¥¸¤ÎÀ©¸æ¾ðÊó¤òÊѹ¹¤·¡¢
-¤½¤Î¥Ñ¥Ã¥±¡¼¥¸¤òºÆ¥¢¥Ã¥×¥í¡¼¥É¤·¤Æ¤¯¤À¤µ¤¤¡£
-<!-- OBSOLETE, please update translation
-(¾Ü¤·¤¯¤Ï <url id="&url-pkg-manual;" name="Debian ¥Ñ¥Ã¥±¡¼¥¸¥ó¥°¥Þ¥Ë¥å¥¢¥ë">
-¤ò¤´Í÷¤¯¤À¤µ¤¤¡£) -->
-¥Ñ¥Ã¥±¡¼¥¸¤¬¥¢¡¼¥«¥¤¥Ö¤Ë¥¤¥ó¥¹¥È¡¼¥ë¤µ¤ì¤ëºÝ¤ËÁ÷¤é¤ì¤Æ¤¯¤ë
-¥¤¥ó¥¹¥È¥ì¡¼¥·¥ç¥ó¥í¥°¤ò½½Ê¬¤Ë³Îǧ¤·¤Æ¤¯¤À¤µ¤¤¡£
-¤â¤·²¿¤é¤«¤ÎÍýͳ¤Ç¥Ñ¥Ã¥±¡¼¥¸¤¬Êѹ¹Á°¤Î¾ì½ê¤Ë¤â»Ä¤Ã¤Æ¤¤¤¿¾ì¹ç¤Ï¡¢
-<tt>ftp.debian.org</tt> ¤ËÂФ·¤Æ¥Ð¥°Êó¹ð¤ò¹Ô¤Ê¤¤¡¢
-Êѹ¹Á°¤Î¾ì½ê¤Ë¤¢¤ë¥Ñ¥Ã¥±¡¼¥¸¤òºï½ü¤¹¤ë¤è¤¦°ÍÍꤷ¤Æ¤¯¤À¤µ¤¤¡£
-¤â¤·¤«¤¹¤ë¤È <prgn>dinstall</prgn> ¤Î¥Ð¥°¤«¤â¤·¤ì¤Ê¤¤¤Î¤Ç¡¢
-¤½¤ÎºÝ¤Ë¤Ï¤¢¤Ê¤¿¤Ç¹Ô¤Ê¤Ã¤¿¤³¤È¤Î¾ÜºÙ¤òź¤¨¤Æ¤¯¤À¤µ¤¤¡£
- <p>
-°ìÊý¡¢¥Ñ¥Ã¥±¡¼¥¸¤Î <em>subsection</em> (Î㤨¤Ð ``devel'' ¤ä ``admin'' ¤Ê¤É)
-¤òÊѹ¹¤¹¤ëɬÍפ¬¤¢¤ë¾ì¹ç¡¢¤½¤Î¼ê³¤¤Ï¼ã´³°Û¤Ê¤ê¤Þ¤¹¡£
-¤³¤Î¾ì¹ç¤Ï¡¢¤½¤Î¥Ñ¥Ã¥±¡¼¥¸¤ÎÀ©¸æ¥Õ¥¡¥¤¥ë¤Ë¤¢¤ë subsection ¤ò½¤Àµ¤·¡¢
-ºÆ¥¢¥Ã¥×¥í¡¼¥É¤·¤Æ¤¯¤À¤µ¤¤¡£
-¤Þ¤¿¡¢<ref id="override-file"> ¤ÇÀâÌÀ¤·¤¿¤è¤¦¤Ë¡¢
-¥ª¡¼¥Ð¥é¥¤¥É¥Õ¥¡¥¤¥ë¤ò¹¹¿·¤¹¤ëɬÍפ⤢¤ê¤Þ¤¹¡£
-
- <sect id="removing-pkgs">¥Ñ¥Ã¥±¡¼¥¸¤Îºï½ü
- <p>
-¤¢¤ë¥Ñ¥Ã¥±¡¼¥¸ (Î㤨¤Ð¡¢¤â¤Ï¤äÉÔÍפˤʤ俸Ť¤¸ß´¹¥é¥¤¥Ö¥é¥ê¤Ê¤É¤ò)
-¤ò²¿¤é¤«¤ÎÍýͳ¤Î¤¿¤á¤Ë´°Á´¤Ëºï½ü¤·¤¿¤¤¾ì¹ç¤Ï¡¢<tt>ftp.debian.org</tt>
-¤ËÂФ·¤Æ¥Ð¥°Êó¹ð¤ò¹Ô¤Ê¤¤¡¢
-¤½¤Î¥Ñ¥Ã¥±¡¼¥¸¤òºï½ü¤¹¤ë¤è¤¦°ÍÍꤷ¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¡£
-¤½¤ÎºÝ¡¢¤½¤Î¥Ñ¥Ã¥±¡¼¥¸¤ò¤É¤Î¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤«¤é
-ºï½ü¤¹¤ë¤Î¤«¤òɬ¤ºÌÀµ¤·¤Æ¤¯¤À¤µ¤¤¡£
- <p>
-¤Ê¤ª¡¢¤½¤Î¥Ñ¥Ã¥±¡¼¥¸¤¬ÉÔÍפʤâ¤Î¤«¤É¤¦¤«¤Ï¤Ã¤¤ê¤·¤Ê¤¤¾ì¹ç¤Ï¡¢
-&email-debian-devel; ¤ËÅŻҥ᡼¥ë¤òÁ÷¤ê°Õ¸«¤òµá¤á¤Æ¤¯¤À¤µ¤¤¡£
-¤Þ¤¿¡¢¤³¤Á¤é¤Ë´Ø¤·¤Æ¤Ï <package>apt</package> ¥Ñ¥Ã¥±¡¼¥¸¤Î
-<prgn>apt-cache</prgn> ¥×¥í¥°¥é¥à¤òÍøÍѤ·¤Æ³Îǧ¤·¤Æ¤ß¤Æ¤â¤è¤¤¤Ç¤·¤ç¤¦¡£
-<tt>apt-cache showpkg <var>package</var></tt> ¤È¤¹¤ì¤Ð¡¢reverse
-depends ¾ðÊó¤ò´Þ¤à <var>package</var> ¾ÜºÙ¤¬É½¼¨¤µ¤ì¤Þ¤¹¡£
-
- <sect1><tt>Incoming</tt> ¤«¤é¤Î¥Ñ¥Ã¥±¡¼¥¸ºï½ü
- <p>
-¤¢¤ë¥Ñ¥Ã¥±¡¼¥¸¤ò <tt>Incoming</tt> ¤«¤éºï½ü¤·¤¿¤¤¾ì¹ç¤Ï¡¢
-µÁ̳¤Ç¤Ï¤¢¤ê¤Þ¤»¤ó¤¬¡¢Å¬Àڤʥ¢¥Ê¥¦¥ó¥¹Íѥ᡼¥ê¥ó¥°¥ê¥¹¥È
-(&email-debian-changes; ¤« &email-debian-devel-changes;)
-¤Ë¤½¤Î»Ý¤òÄÌÃΤ·¤Æ¤ª¤¯¤È¤è¤¤¤Ç¤·¤ç¤¦¡£
-
- <sect>¥Ñ¥Ã¥±¡¼¥¸¤ÎÃÖ¤´¹¤¨¤ä²þ̾
- <p>
-¥Ñ¥Ã¥±¡¼¥¸¤Î̾Á°¤ò´Ö°ã¤¨¤ÆÉÕ¤±¤Æ¤·¤Þ¤¤¡¢
-¤½¤ì¤ò²þ̾¤·¤Ê¤±¤ì¤Ð¤Ê¤é¤Ê¤¤¤³¤È¤¬¤¢¤ë¤«¤â¤·¤ì¤Þ¤»¤ó¡£
-¤³¤Î¾ì¹ç¡¢¼¡¤ÎÆó¤Ä¤Î¼ê½ç¤òƧ¤àɬÍפ¬¤¢¤ê¤Þ¤¹¡£
-¤Þ¤º½é¤á¤Ë¡¢¤½¤Î¥Ñ¥Ã¥±¡¼¥¸¤Î¸Å¤¤Ì¾Á°¤ËÂФ·¤Æ
-replace ¤ª¤è¤Ó conflict ¤È¤Ê¤ë¤è¤¦
-<file>debian/control</file> ¥Õ¥¡¥¤¥ë¤ËÀßÄê¤ò¹Ô¤Ê¤¤¤Þ¤¹¡£
-<!-- OBSOLETE, please update translation
-(¾ÜºÙ¤Ï <url id="&url-pkg-manual;" name="Debian ¥Ñ¥Ã¥±¡¼¥¸¥ó¥°¥Þ¥Ë¥å¥¢¥ë"> -->
-¤ò¤´Í÷¤¯¤À¤µ¤¤¡£)
-¤½¤·¤Æ¡¢¤³¤Î¥Ñ¥Ã¥±¡¼¥¸¤ò¥¢¥Ã¥×¥í¡¼¥É¤·¡¢¤½¤ì¤ò¥¢¡¼¥«¥¤¥Ö¤Ë°ÜÆ°¤·¤¿¤é¡¢
-<tt>ftp.debian.org</tt> ¤ËÂФ¹¤ë¥Ð¥°Êó¹ð¤ò¹Ô¤Ê¤¤¡¢
-¸Å¤¤Ì¾Á°¤Î¥Ñ¥Ã¥±¡¼¥¸¤òºï½ü¤¹¤ë¤è¤¦°ÍÍꤷ¤Æ¤¯¤À¤µ¤¤¡£
-
- <sect id="orphaning">¥Ñ¥Ã¥±¡¼¥¸¤Î¤ß¤Ê¤·¤´²½
- <p>
-¤¢¤ë¥Ñ¥Ã¥±¡¼¥¸¤Î¥á¥ó¥Æ¥Ê¥ó¥¹¤¬¤Ç¤¤Ê¤¯¤Ê¤Ã¤¿¾ì¹ç¤Ï¡¢¤½¤Î¥Ñ¥Ã¥±¡¼¥¸³«È¯¼Ô¤ò
-<tt>Debian QA Group &orphan-address;</tt> ¤ËÀßÄꤷľ¤·¡¢
-&email-wnpp; °¸¤Æ¤Ë¤½¤Î¥Ñ¥Ã¥±¡¼¥¸¤ò¤ß¤Ê¤·¤´²½¤¹¤ë»Ý¤ò
-ÅŻҥ᡼¥ë¤ÇÄÌÃΤ·¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¡£
-¤¿¤À¡¢¤½¤Î¥Ñ¥Ã¥±¡¼¥¸¤¬ Debian ¤Ë¤È¤Ã¤Æ¶Ë¤á¤Æ½ÅÍפʤâ¤Î¤Ç¤¢¤ë¾ì¹ç¤Ï¡¢
-Âå¤ï¤ê¤Ë &email-debian-devel; °¸¤Æ¤ËÅŻҥ᡼¥ë¤òÁ÷¤ê¡¢
-¿·³«È¯¼Ô¤òÊ罸¤¹¤Ù¤¤Ç¤·¤ç¤¦¡£
-
- <sect id="adopting">¥Ñ¥Ã¥±¡¼¥¸¤Î°ú¤·Ñ¤®
- <p>
-¿·³«È¯¼Ô¤¬É¬Íפʥѥ屡¼¥¸¤Î°ìÍ÷¤¬¡¢Äê´üŪ¤Ë
-&email-debian-devel ¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤Ëή¤µ¤ì¤Þ¤¹¡£
-¤³¤Î°ìÍ÷¤Ï <url id="&url-wnpp;"> ¤Ë¤¢¤ë
-Work-Needing and Prospective Packages document (WNPP)
-¤«¤é¤âÆþ¼ê¤Ç¤¤Þ¤¹¡£
-WNPP ¤Î°ìÍ÷¤Ë¤¢¤ë¥Ñ¥Ã¥±¡¼¥¸¤Î¥á¥ó¥Æ¥Ê¥ó¥¹¤ò°ú¤·Ñ¤®¤¿¤¤¾ì¹ç¤ä¡¢
-¤¢¤Ê¤¿¤Î¥Ñ¥Ã¥±¡¼¥¸¤Î¥á¥ó¥Æ¥Ê¥ó¥¹¤òÊü´þ¤¹¤ë¾ì¹ç¡¢
-¿·µ¬¥Ñ¥Ã¥±¡¼¥¸¤Îºî¶È¤ò郎¹Ô¤Ê¤Ã¤Æ¤¤¤ë¤«¤É¤¦¤«Ã±¤Ë³Îǧ¤·¤¿¾ì¹ç¤Ï¡¢
-&email-wnpp; ¤ËÅŻҥ᡼¥ë¤òÁ÷¤Ã¤Æ¤¯¤À¤µ¤¤¡£
- <p>
-¤³¤Î¤³¤È¤ò¤ª¤í¤½¤«¤Ë¤·¤Æ¡¢¤¢¤ë¥Ñ¥Ã¥±¡¼¥¸¤òñ¤Ë°ú¤·Ñ¤°¤À¤±¤Ç¤Ï¤¤¤±¤Þ¤»¤ó¡£
--- ¤³¤ì¤Ç¤Ï¥Ñ¥Ã¥±¡¼¥¸¥Ï¥¤¥¸¥ã¥Ã¥¯¤Ç¤¹¡£
-¤â¤Á¤í¤ó¡¢¸½¹Ô¤Î³«È¯¼Ô¤ËÏ¢Íí¤ò¼è¤ê¡¢
-¤½¤Î¥Ñ¥Ã¥±¡¼¥¸¤Î°ú¤·Ñ¤®¤ò°ÍÍꤹ¤ë¤³¤È¤Ï²Äǽ¤Ç¤¹¡£
-¤·¤«¤·¤Ê¤¬¤é¡¢¤½¤ÎºÝ¤ËƱ°Õ¤òÆÀ¤é¤ì¤Ê¤±¤ì¤Ð¡¢
-¤½¤Î¥Ñ¥Ã¥±¡¼¥¸¤ò°ú¤·Ñ¤°¤³¤È¤Ï¤Ç¤¤Þ¤»¤ó¡£
-¤¿¤È¤¨¤¢¤Ê¤¿¤Î¿½¤·½Ð¤¬Ìµ»ë¤µ¤ì¤¿¤È¤·¤Æ¤â¡¢
-¤½¤ì¤Ï¥Ñ¥Ã¥±¡¼¥¸°ú¤·Ñ¤®¤ÎÍýͳ¤È¤Ï¤Ê¤ê¤Þ¤»¤ó¡£
-¸½¹Ô³«È¯¼Ô¤¬²»º»ÂÁ¤â¤Ê¤¯¤½¤Îºî¶È¤òÊü´þ¤·¤Æ¤¤¤ë¤È³Î¿®¤Ç¤¤ë¾ì¹ç¤Ï¡¢
-¤½¤Î»Ý¤ò &email-debian-private; ¤Ë¤Æ¿Ò¤Í¤Æ¤ß¤Æ¤¯¤À¤µ¤¤¡£
- <p>
-¤Ê¤ª¡¢¸Å¤¤¥Ñ¥Ã¥±¡¼¥¸¤ò°ú¤·Ñ¤¤¤À¾ì¹ç¤Ï¡¢
-¤¢¤Ê¤¿¤ò¤½¤Î¥Ñ¥Ã¥±¡¼¥¸¤Î¸ø¼°³«È¯¼Ô¤È¤·¤Æ
-¥Ð¥°ÄÉÀ×¥·¥¹¥Æ¥à¤ËÅÐÏ¿¤Ê¤µ¤ê¤¿¤¤¤Ç¤·¤ç¤¦¡£
-<tt>Maintainer:</tt> ¥Õ¥£¡¼¥ë¥É¤ò¹¹¿·¤·¤¿¿·¥Ð¡¼¥¸¥ç¥ó¤ò¥¢¥Ã¥×¥í¡¼¥É¤¹¤ì¤Ð¡¢
-Æ󽵴֤ۤɻþ´Ö¤¬¤«¤«¤ê¤Þ¤¹¤¬¡¢¤½¤Î½èÍý¤Ï¼«Æ°Åª¤Ë¹Ô¤Ê¤ï¤ì¤Þ¤¹¡£
-¤¿¤À¡¢¤·¤Ð¤é¤¯¤Î´Ö¡¢¿·¥Ð¡¼¥¸¥ç¥ó¤ò¥¢¥Ã¥×¥í¡¼¥É¤Ç¤¤Ê¤¤¾ì¹ç¤Ï¡¢
-¥Ð¥°Êó¹ð¤¬¤¢¤Ê¤¿¤Î¸µ¤ØÀµ¤·¤¯Á÷ÉÕ¤µ¤ì¤ë¤è¤¦¤Ë¤¹¤ë¤¿¤á¤Ë¡¢
-&email-override; ¤ËÅŻҥ᡼¥ë¤òÁ÷¤Ã¤Æ¤¯¤À¤µ¤¤¡£
-
-
- <chapt id="bug-handling">¥Ð¥°¤Î°·¤¤
-
- <sect>¥Ð¥°¤ò´Æ»ë¤¹¤ë
- <p>
-Í¥¤ì¤¿³«È¯¼Ô¤Ç¤¢¤ë¤¿¤á¤Ë¤Ï¡¢Äê´üŪ¤Ë
-<url id="&url-bts;" name="Debian ¥Ð¥°ÄÉÀ×¥·¥¹¥Æ¥à (BTS)">
-¤Ç¼«Ê¬¤Î¥Ñ¥Ã¥±¡¼¥¸¤Ë´Ø¤¹¤ë¤â¤Î¤ò¥Á¥§¥Ã¥¯¤¹¤ë¤ÈÎɤ¤¤Ç¤·¤ç¤¦¡£
-BTS ¤Ë¤Ï¡¢¤¢¤Ê¤¿¤Î¥Ñ¥Ã¥±¡¼¥¸¤ËÂФ·¤Æ¥ª¡¼¥×¥ó¤µ¤ì¤¿
-Á´¥Ð¥°Êó¹ð¤¬ÅÐÏ¿¤µ¤ì¤Æ¤¤¤Þ¤¹¡£
- <p>
-³«È¯¼Ô¤Ï¡¢<tt>bugs.debian.org</tt> °¸¤Æ¤Ë
-ÅŻҥ᡼¥ë¤ò½Ð¤¹¤³¤È¤Ë¤è¤Ã¤Æ BTS ¤òÍøÍѤ¹¤ë¤³¤È¤â¤Ç¤¤Þ¤¹¡£
-¤½¤ÎºÝ¤ËÍøÍѤǤ¤ë¥³¥Þ¥ó¥É¤Ë´Ø¤¹¤ë¥É¥¥å¥á¥ó¥È¤Ï
-<url id="&url-bts;"> ¤Ë¤¢¤ê¤Þ¤¹¡£
-¤Þ¤¿ <package>debian-doc</package> ¥Ñ¥Ã¥±¡¼¥¸¤¬¥¤¥ó¥¹¥È¡¼¥ëºÑ¤ß¤Ê¤é¤Ð¡¢
-¥í¡¼¥«¥ë¤Ë¤¢¤ë &file-bts-docs;
-¥Õ¥¡¥¤¥ë¤ò¤´Í÷¤Ë¤Ê¤ë¤³¤È¤â¤Ç¤¤Þ¤¹¡£
- <p>
-¤Þ¤¿¡¢¥ª¡¼¥×¥ó¤µ¤ì¤¿¥Ð¥°Êó¹ð¤òÄê´üŪ¤Ë¼è¤ê¹þ¤à¤³¤È¤âͱפǤ¹¡£
-¤Þ¤¿¡¢¤¢¤Ê¤¿¤Î¥Ñ¥Ã¥±¡¼¥¸¤ËÂФ·¤Æ¥ª¡¼¥×¥ó¤µ¤ì¤¿¥Ð¥°Êó¹ð¤Î³µÎ¬¤ò
-Ëè½µÅŻҥ᡼¥ë¤Ç¼õ¤±¼è¤ê¤¿¤¤¤Ê¤é¤Ð¡¢
-cron ¥¸¥ç¥Ö¤Ë°Ê²¼¤Î¹Ô¤òÄɲ䷤Ƥâ¤è¤¤¤Ç¤·¤ç¤¦¡£
-
-<example>
-# Ëè½µ¼«Ê¬¤Î¥Ñ¥Ã¥±¡¼¥¸¤ËÂФ¹¤ë¥Ð¥°Êó¹ð¤òÄ´¤Ù¤ë
-&cron-bug-report;
-</example>
-
-<var>maintainer-address</var> ¤Î²Õ½ê¤Ë¤Ï¡¢¤¢¤Ê¤¿¤Î
-Debian ¸ø¼°³«È¯¼Ô¤È¤·¤Æ¤ÎÅŻҥ᡼¥ë¥¢¥É¥ì¥¹¤òÅö¤Æ¤Ï¤á¤Æ¤¯¤À¤µ¤¤¡£
-
- <sect id="submit-bug">¥Ð¥°¤òÊó¹ð¤¹¤ë
- <p>
-¥Ñ¥Ã¥±¡¼¥¸³«È¯¼Ô¤È¤·¤Æ¡¢Â¾¤Î¥Ñ¥Ã¥±¡¼¥¸¤Î¥Ð¥°¤òȯ¸«¤¹¤ë¤³¤È¤ä¡¢
-¤¢¤Ê¤¿¤Î¥Ñ¥Ã¥±¡¼¥¸¤ËÂФ·¤ÆÊó¹ð¤µ¤ì¤Æ¤Ï¤¤¤ë¤¬¡¢¤½¤ÎÂоݥѥ屡¼¥¸¤òÊѹ¹
-(reassign) ¤¹¤Ù¤¥Ð¥°Êó¹ð¤ò¼õ¤±¤ë¤³¤È¤â¤¢¤ë¤Ç¤·¤ç¤¦¡£
-¤³¤ì¤é¤Î¥Ð¥°¤ÏÅÐÏ¿¤·¤Æ¤ª¤¯É¬Íפ¬¤¢¤ê¤Þ¤¹¡£
-¤³¤Á¤é¤ò¤É¤Î¤è¤¦¤Ë¹Ô¤Ê¤¦¤«¤Ë¤Ä¤¤¤Æ¤ÎÀâÌÀ¤Ï¡¢
-<url id="&url-bts-control;" name="¥Ð¥°¥³¥ó¥È¥í¡¼¥ë¥á¡¼¥ë¥µ¡¼¥ÐÆþÌç">
-¤Ë¤¢¤ê¤Þ¤¹¡£
- <p>
-ÌäÂ꤬¤¢¤Ã¤¿¾ì¹ç¡¢¤½¤Î¥Ð¥°¤òÅÐÏ¿¤¹¤ë¤³¤È¤¬¾©Î夵¤ì¤Æ¤¤¤Þ¤¹¡£
-ÅŻҥ᡼¥ë¤ò¼õ¤±¼è¤ë¤È¤¤ËÍѤ¤¤Æ¤¤¤ëÄ̾ï¤Î¥æ¡¼¥¶¥¢¥«¥¦¥ó¥È¤«¤é¡¢
-¥Ð¥°¤òÊó¹ð¤·¤Æ¤¯¤À¤µ¤¤¡£
-root ¥¢¥«¥¦¥ó¥È¤«¤é¥Ð¥°¤òÊó¹ð¤·¤Æ¤Ï¤¤¤±¤Þ¤»¤ó¡£
- <p>
-Åö³º¥Ñ¥Ã¥±¡¼¥¸¤Ë´Ø¤¹¤ëÌäÂê¤Î¥Ð¥°¤¬¡¢
-¤Þ¤ÀÊó¹ð¤µ¤ì¤Æ¤¤¤Ê¤¤¤³¤È¤ò³Îǧ¤·¤Æ¤¯¤À¤µ¤¤¡£
-¤½¤Î¾å¤Ç¡¢¤½¤Î¥Ð¥°¤òŬÀڤʤȤ³¤í¤ØÊó¹ð¤·¤Æ¤¯¤À¤µ¤¤¡£
-ÆÃÊ̤˵ö²Ä¤òÆÀ¤Æ¤¤¤ë¾ì¹ç¡¢Â¾¤Î¥Ñ¥Ã¥±¡¼¥¸¤ËÂФ·¤Æ¤â¡¢
-²¿ÅÙ¤âÊó¹ð¤ò¼õ¤±¤Æ¤¤¤ë¥Ð¥°¤ò¥Þ¡¼¥¸¤·¡¢¤½¤Î½¤Àµ¤¬´°Î»¤·¤¿ºÝ¡¢
-¤½¤Î¥Ð¥°¤Î½ÅÍ×ÅÙ¤ò `fixed' ¤ËÀßÄꤹ¤ë¤³¤È¤â¤Ç¤¤Þ¤¹¡£
-¤Ê¤ª¡¢¥Ð¥°Êó¹ð¼Ô¤«¤½¤Î¥Ñ¥Ã¥±¡¼¥¸¤Î³«È¯¼Ô¤Ç¤Ê¤±¤ì¤Ð¡¢
-(³«È¯¼Ô¤«¤é¸¢¸Â¤òÉÕÍ¿¤µ¤ì¤Æ¤¤¤Ê¤¤¸Â¤ê¡¢)
-¤½¤Î¥Ð¥°¤ò¼ÂºÝ¤Ë¥¯¥í¡¼¥º¤¹¤ë¤³¤È¤Ï¤Ç¤¤Þ¤»¤ó¡£
-
- <sect>¥Ð¥°Êó¹ð¤ËÊÖ¿®¤¹¤ë
- <p>
-¥Ð¥°Êó¹ð¤ËÂФ¹¤ëÊÖ¿®¤Ï¡¢É¬¤º¤½¤Î¥Ð¥°¤Î¸µ¤ÎÊó¹ð¼Ô¤È¡¢
-¥Ð¥°Êó¹ð¤½¤Î¤â¤Î (Î㤨¤Ð <email>123@bugs.debian.org</email>)
-¤Îξ¼Ô¤ËÁ÷ÉÕ¤µ¤ì¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¡£
- <p>
-¥Ð¥°¥µ¡¼¥Ð·Ðͳ¤Ç &email-bts-control; ¤Ë `close' ¥³¥Þ¥ó¥É¤òÁ÷¤Ã¤Æ
-¥Ð¥°¤ò¥¯¥í¡¼¥º¤¹¤ë¤³¤È¤Ï<em>·è¤·¤Æ</em>¤·¤Ê¤¤¤Ç¤¯¤À¤µ¤¤¡£
-¤½¤¦¤·¤Æ¤·¤Þ¤¦¤È¡¢¸µ¤ÎÊó¹ð¼Ô¤Ï¡¢¤½¤Î¥Ð¥°¤¬¥¯¥í¡¼¥º¤µ¤ì¤¿Íýͳ¤Ë´Ø¤·¤Æ
-²¿¤Î¥Õ¥£¡¼¥É¥Ð¥Ã¥¯¤âÆÀ¤ë¤³¤È¤¬¤Ç¤¤Þ¤»¤ó¡£
-
- <sect id="upload-bugfix">¿·µ¬¥¢¥Ã¥×¥í¡¼¥É¤Ë¤è¤Ã¤Æ¥Ð¥°¤ò¥¯¥í¡¼¥º¤¹¤ë¾ì¹ç¤Ë¤Ï
- <p>
-¤¢¤Ê¤¿¤Î¥Ñ¥Ã¥±¡¼¥¸¤Î¥Ð¥°¤ò½¤Àµ¤¹¤ë¾ì¹ç¡¢
-¤½¤Î½¤Àµ¤¬´°Î»¤·¤¿ºÝ¤Ë¥Ð¥°¤ò¥¯¥í¡¼¥º¤¹¤ë¤³¤È¤Ï¡¢
-¥Ñ¥Ã¥±¡¼¥¸³«È¯¼Ô¤È¤·¤Æ¤ÎÀÕǤ¤Ç¤¹¡£
-¤·¤«¤·¤Ê¤¬¤é¡¢½¤Àµ¤µ¤ì¤¿¥Ñ¥Ã¥±¡¼¥¸¤¬ Debian ¥¢¡¼¥«¥¤¥Ö¤Ë¼ý¤á¤é¤ì¤ë¤Þ¤Ç¤Ï¡¢
-¤½¤Î¥Ð¥°¤ò¥¯¥í¡¼¥º¤·¤Æ¤Ï¤¤¤±¤Þ¤»¤ó¡£
-¤½¤Î¤¿¤á¡¢¥¢¥Ã¥×¥í¡¼¥É¤·¤¿¥Ñ¥Ã¥±¡¼¥¸¤¬¥¢¡¼¥«¥¤¥Ö¤Ë¥¤¥ó¥¹¥È¡¼¥ë¤µ¤ì¤¿¤È¤Î
-ÄÌÃΤò¼õ¤±¤Æ¤«¤é¡¢BTS ¤ËÅÐÏ¿¤µ¤ì¤Æ¤¤¤ë¥Ð¥°¤ò¥¯¥í¡¼¥º¤·¤Æ¤¯¤À¤µ¤¤¡£
- <p>
-<package>dpkg-dev</package> ¤Î¿·¤·¤¤¥Ð¡¼¥¸¥ç¥ó¤òÍøÍѤ·¡¢
-changelog ¥¨¥ó¥È¥ê¤òŬÀÚ¤ËÀßÄꤷ¤Æ¤¤¤ì¤Ð¡¢
-<prgn>dinstall</prgn> ¤Ï¼«Æ°Åª¤Ë¤½¤Î¥Ð¥°¤ò¥¯¥í¡¼¥º¤·¤Þ¤¹¡£
-¤½¤Î¤¿¤á¤Ë¤Ï¡¢°Ê²¼¤Î¤è¤¦¤Ë <file>debian/changelog</file>
-¥Õ¥¡¥¤¥ë¤Îµ½Ò¤¬Àµ¤·¤¤Ê¸Ë¡¤Ë¤·¤¿¤¬¤Ã¤Æ¤¤¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¡£
-
-<example>
-acme-cannon (3.1415) unstable; urgency=low
-
- * Frobbed with options (closes: Bug#98339)
- * Added safety to prevent operator dismemberment, closes: bug #98765,
- bug #98713, #98714.
- * Added manpage. closes: #98725.
-</example>
-
-µ»½ÑŪ¤Ê´ÑÅÀ¤«¤é¤¤¤¨¤Ð¡¢°Ê²¼¤Î Perl Àµµ¬É½¸½¤¬ÍѤ¤¤é¤ì¤Þ¤¹¡£
-
-<example>
- /closes:\s*(bug)?\#\d+(,\s*(bug)?\#\d+)*/gi
-</example>
-
-¤³¤Î¥Ñ¥Ã¥±¡¼¥¸¤Î³«È¯¼Ô¤Ï¡¢Â¾¤Î changelog ¥¨¥ó¥È¥ê¤È¶èÊ̤·¤ä¤¹¤¤¤³¤È¤«¤é¡¢
-<tt>(closes: Bug#<var>XXX</var>)</tt> ¤È¤¤¤¦Ê¸Ë¡¤ò¹¥¤ó¤Ç»È¤Ã¤Æ¤¤¤ë¤è¤¦¤Ç¤¹¡£
- <p>
-¥Ð¥°¤Î¥¯¥í¡¼¥º¤ò¼êÆ°¤È¤¤¤¦¸Å¤¤Î®µ·¤Ç¹Ô¤Ê¤¤¤¿¤¤¾ì¹ç¤Ï¡¢
-<tt>.changes</tt> ¥Õ¥¡¥¤¥ë¤ò
-<email>XXX-done@bugs.debian.org</email> °¸¤Æ¤ËÁ÷¤ì¤Ð·ë¹½¤Ç¤¹¡£
-¤½¤ÎºÝ¤³¤Á¤é¤Î <var>XXX</var> ¤Î²Õ½ê¤Ë¤Ï¥Ð¥°ÈÖ¹æ¤òÅö¤Æ¤Ï¤á¤Æ¤¯¤À¤µ¤¤¡£
-
- <sect id="lintian-reports">Lintian ¤Ë¤è¤ëÊó¹ð
- <p>
-¥Ñ¥Ã¥±¡¼¥¸³«È¯¼Ô¤Ï¡¢Äê´üŪ¤ËºÇ¿·¤Î <package>lintian</package> ¤ò
-`unstable' ¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤«¤éÆþ¼ê¤·¡¢
-¼«¤é¤Î¥Ñ¥Ã¥±¡¼¥¸¤¹¤Ù¤Æ¤ò¥Á¥§¥Ã¥¯¤¹¤Ù¤¤Ç¤¹¡£
-¤¢¤ë¤¤¤Ï¡¢<url id="&url-lintian;" name="¥ª¥ó¥é¥¤¥ó lintian Êó¹ð">¾å¤Ç¡¢
-¼«Ê¬¤¬³«È¯¼Ô¤È¤·¤ÆÅÐÏ¿¤·¤Æ¤¤¤ëÅŻҥ᡼¥ë¥¢¥É¥ì¥¹¤Î²Õ½ê¤ò
-¥Á¥§¥Ã¥¯¤·¤Æ¤â¤è¤¤¤Ç¤·¤ç¤¦¡£
-¤³¤Á¤é¤ÎÊó¹ð¤Ï¼«Æ°Åª¤Ë¹¹¿·¤µ¤ì¤Þ¤¹¤¬¡¢
-ºÇ¿·¤Î <package>lintian</package> ¤òÍøÍѤ·¤Æ¡¢
-¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤ÎºÇ¿·¥Ð¡¼¥¸¥ç¥ó (Ä̾ï¤Ï 'unstable') ¤ËÂФ¹¤ë
-<prgn>lintian</prgn> Êó¹ð¤ò¼ýÏ¿¤·¤Æ¤¤¤Þ¤¹¡£
-
- <sect>°ìÅ٤ˤ¿¤¯¤µ¤ó¤Î¥Ð¥°Êó¹ð¤ò¹Ô¤Ê¤¦
- <p>
-¤¿¤¯¤µ¤ó¤Î°Û¤Ê¤ë¥Ñ¥Ã¥±¡¼¥¸¾å¤Ë¤¢¤ëƱ°ì¤ÎÌäÂê¤ËÂФ·¤Æ¡¢
-¤¿¤¯¤µ¤ó¤Î¥Ð¥°Êó¹ð¤ò -- ¤Ä¤Þ¤ê 10 °Ê¾å¤â --
-¹Ô¤Ê¤¦¤³¤È¤Ï¡¢´ªÊ۴ꤤ¤¿¤¤ºî¶È¤Ç¤¹¡£
-¤¿¤À¡¢¤È¤â¤¢¤ì°ìÅ٤ˤ¿¤¯¤µ¤ó¤Î¥Ð¥°Êó¹ð¤ò¤·¤Ê¤¯¤ÆºÑ¤à¤è¤¦¤Ë¡¢
-¤Ç¤¤¦¤ë¤³¤È¤Ï¹Ô¤Ê¤Ã¤Æ¤¯¤À¤µ¤¤¡£
-Î㤨¤Ð¡¢¤½¤ÎÌäÂê¤Î¥Á¥§¥Ã¥¯¤¬¼«Æ°²½¤Ç¤¤ë¤â¤Î¤Ê¤é¤Ð¡¢
-¥¨¥é¡¼¤ä·Ù¹ð¤òȯ¹Ô¤¹¤ë¤è¤¦¤Ë
-<package>lintian</package> ¤Ë¿·¤¿¤Ê¥Á¥§¥Ã¥¯¤òÉÕ¤±²Ã¤¨¤Æ¤¯¤À¤µ¤¤¡£
- <p>
-Ʊ¤¸ÌäÂê¤Ë´Ø¤¹¤ë 10 ¸Ä°Ê¾å¤Î¥Ð¥°¤ò°ìÅÙ¤ËÊó¹ð¤¹¤ë¾ì¹ç¤Ï¡¢
-¤½¤Î¥Ð¥°¤òÊó¹ð¤¹¤ëÁ°¤Ë¡¢¤½¤Î°Õ¿Þ¤¹¤ë¤È¤³¤í¤òź¤¨¤Æ
-&email-debian-devel; °¸¤Æ¤Ë¥á¥Ã¥»¡¼¥¸¤òÁ÷¤ë¤³¤È¤¬¿ä¾©¤µ¤ì¤Æ¤¤¤Þ¤¹¡£
-¤³¤Î¤³¤È¤Ë¤è¤Ã¤Æ¡¢Â¾¤Î³«È¯¼Ô¤Ï¤½¤Î¥Ð¥°¤¬ËÜÅö¤ËÌäÂê¤Î¤¢¤ë¤â¤Î¤Ê¤Î¤«¤É¤¦¤«¤ò
-³Î¤«¤á¤ë¤³¤È¤¬¤Ç¤¤Þ¤¹¡£
-¤µ¤é¤Ë¡¢¤³¤Î¤³¤È¤Ï¡¢
-Ê£¿ô¤Î³«È¯¼Ô¤¬Æ±¤¸¥Ð¥°¤òƱ»þ¤ËÊó¹ð¤¹¤ë¤È¤¤¤¦»öÂÖ¤âËɤ®¤Þ¤¹¡£
- <p>
-¤Ê¤ª¡¢¤¿¤¯¤µ¤ó¤Î¥Ð¥°¤òƱ°ì¤Î¥µ¥Ö¥¸¥§¥¯¥È¤ÇÊó¹ð¤¹¤ëºÝ¤Ë¤Ï¡¢
-¥Ð¥°Êó¹ð¤¬ÇÛÁ÷¤µ¤ì¤ë¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤ËžÁ÷¤µ¤ì¤Ê¤¤¤è¤¦¡¢
-¤½¤Î¥Ð¥°Êó¹ð¤Ï <email>maintonly@bugs.debian.org</email> ¤ØÁ÷¤Ã¤Æ¤¯¤À¤µ¤¤¡£
-
-
- <chapt id="tools">Debian ³«È¯¼ÔÍѥġ¼¥ë¤Î³µ´Ñ
- <p>
-¤³¤Î¾Ï¤Ç¤Ï¡¢³«È¯¼Ô¤¬ÍøÍѤǤ¤ë¥Ä¡¼¥ë·²¤òÂç¤Þ¤«¤ËÀâÌÀ¤·¤Þ¤¹¡£
-¤³¤ì¤é¤Î¥Ä¡¼¥ë·²¤Ï¡¢³«È¯¼Ô¤ÎÊص¹¤ò¿Þ¤ê¡¢
-¤³¤ì¤é¤ò»È¤¦¤³¤È¤Ë¤è¤Ã¤Æ¶õ¤¤¤¿»þ´Ö¤ò¤è¤ê½ÅÍפÊ
-ºî¶È¤Ë¤Þ¤ï¤»¤ë¤è¤¦ÍÑ°Õ¤µ¤ì¤Æ¤¤¤Þ¤¹¡£
- <p>
-¹â¥ì¥Ù¥ë¤Î¥Ñ¥Ã¥±¡¼¥¸³«È¯¥Ä¡¼¥ë¤ÎÍøÍѤò¹¥¤à¿Í¤â¤¤¤ì¤Ð¡¢¹¥¤Þ¤Ê¤¤¿Í¤â¤¤¤Þ¤¹¡£
-Debian ¤Ç¤Ï¡¢¤³¤ÎÌäÂê¤Ë´Ø¤·¤Æ¸ø¼°¤Ê¼è¤ê·è¤á¤Ï¤¢¤ê¤Þ¤»¤ó¡£
-¤Ä¤Þ¤ê¡¢¤É¤Î¥Ä¡¼¥ë¤òÍѤ¤¤Æ¤âºî¶È¤ò¹Ô¤Ê¤¦¤³¤È¤¬¤Ç¤¤ë¤Ê¤é¤ÐÌäÂꤢ¤ê¤Þ¤»¤ó¡£
-¤½¤Î¤¿¤á¡¢¤³¤Î¾Ï¤Ï¡¢¤É¤Î¥Ä¡¼¥ë¤ò»È¤¦¤Ù¤¤Ê¤Î¤«¡¢
-³«È¯¤Ëȼ¤¦ºî¶È¤Ë¤É¤Î¤è¤¦¤Ë¼è¤êÁȤà¤Ù¤¤Ê¤Î¤«¡¢
-¤Ë¤Ä¤¤¤Æµ¬Äꤹ¤ë¤â¤Î¤Ç¤Ï¤¢¤ê¤Þ¤»¤ó¡£
-¤Þ¤¿¡¢¶¥¹ç¤¹¤ë¥Ä¡¼¥ë¤ÎÇÓ½ü¤òÈò¤±¤ë¤¿¤á¤Ë¡¢
-ÆÃÄê¤Î¥Ä¡¼¥ë¤ò¿ä¾©¤¹¤ë¤³¤È¤â¤·¤Þ¤»¤ó¡£
- <p>
-¤³¤ì¤é¥Ñ¥Ã¥±¡¼¥¸¤ÎÀâÌÀʸ¤ÎÂçȾ¤Ï¡¢
-¼ÂºÝ¤Î¥Ñ¥Ã¥±¡¼¥¸ÀâÌÀʸ¤½¤Î¤â¤Î¤ò»²¹Í¤Ë¤·¤¿¤â¤Î¤Ç¤¹¡£
-¤è¤ê¾ÜºÙ¤Ê¾ðÊó¤Ï³Æ¥Ñ¥Ã¥±¡¼¥¸¤Î¥É¥¥å¥á¥ó¥È¤ò¤´Í÷¤¯¤À¤µ¤¤¡£
-
- <sect id="dpkg-dev">
- <heading><package>dpkg-dev</package>
- <p>
-<package>dpkg-dev</package> ¤Ë¤Ï¡¢Debian ¥½¡¼¥¹¥Ñ¥Ã¥±¡¼¥¸¤ÎŸ³«¡¢
-¹½ÃÛ¡¢¥¢¥Ã¥×¥í¡¼¥É¤ËɬÍפȤʤë (<prgn>dpkg-source</prgn> ¤ò´Þ¤à)
-¥Ä¡¼¥ë·²¤¬¼ýÏ¿¤µ¤ì¤Æ¤¤¤Þ¤¹¡£
-¤³¤ì¤é¤Î¥æ¡¼¥Æ¥£¥ê¥Æ¥£·²¤Ï¡¢¥Ñ¥Ã¥±¡¼¥¸¤ÎºîÀ®¤ª¤è¤ÓÁàºî¤ËɬÍפȤʤë
-´ðËÜŪ¤ÇÄã¥ì¥Ù¥ë¤Êµ¡Ç½¤òÄ󶡤·¤Þ¤¹¡£
-¤½¤Î¤¿¤á¡¢¤³¤Á¤é¤Ï¤¤¤º¤ì¤Î Debian ³«È¯¼Ô¤Ë¤âɬÍפȤʤë¤â¤Î¤Ç¤¹¡£
-
- <sect id="lintian">
- <heading><package>lintian</package>
- <p>
-<package>lintian</package> ¤Ï Debian ¥Ñ¥Ã¥±¡¼¥¸¤òÀººº¤·¡¢
-¥Ð¥°¤ä¥Ý¥ê¥·¡¼°ãÈ¿¤òÊó¹ð¤·¤Þ¤¹¡£
-<package>lintian</package> ¤Ï¡¢°ìÈÌŪ¤Ê¥¨¥é¡¼¤Î¥Á¥§¥Ã¥¯¤È¤È¤â¤Ë¡¢
-Debian ¥Ý¥ê¥·¡¼¤Î¿³ÑŪ¤Ê¼«Æ°¥Á¥§¥Ã¥¯¤â¹Ô¤Ê¤¤¤Þ¤¹¡£
-<package>lintian</package> ¤Î»È¤¤Êý¤Ë¤Ä¤¤¤Æ¤Ï¡¢
-<ref id="upload-checking"> ¤ª¤è¤Ó <ref id="lintian-reports">
-¤Ç¤¹¤Ç¤ËÀâÌÀ¤·¤Æ¤¢¤ê¤Þ¤¹¡£
-
- <sect id="debhelper">
- <heading><package>debhelper</package>
- <p>
-<package>debhelper</package>¤Ï¡¢
-¥Ð¥¤¥Ê¥ê Debian ¥Ñ¥Ã¥±¡¼¥¸¤Î¹½Ãۤ˴ØÏ¢¤¹¤ë
-°ìÈÌŪ¤Êºî¶È¤ò¼«Æ°²½¤¹¤ë¤¿¤á¤Ë¡¢
-<file>debian/rules</file> ¤ÇÍøÍѤǤ¤ë¥×¥í¥°¥é¥à½¸¤Ç¤¹¡£
-¤³¤Î¥×¥í¥°¥é¥à½¸¤Ë¤Ï¡¢ºîÀ®¤¹¤ë¥Ñ¥Ã¥±¡¼¥¸¤Ø¤Î¤µ¤Þ¤¶¤Þ¤Ê¥Õ¥¡¥¤¥ë¤Î¥¤¥ó¥¹¥È¡¼¥ë¤ä¡¢
-¥Õ¥¡¥¤¥ë¤Î°µ½Ì¡¢¥Õ¥¡¥¤¥ë¥Ñ¡¼¥ß¥Ã¥·¥ç¥ó¤Î½¤Àµ¡¢ºîÀ®¤¹¤ë¥Ñ¥Ã¥±¡¼¥¸¤Î
-Debian menu ¥·¥¹¥Æ¥à¤Ø¤ÎÅý¹ç¤ò¹Ô¤Ê¤¦¥×¥í¥°¥é¥à·²¤¬´Þ¤Þ¤ì¤Æ¤¤¤Þ¤¹¡£
- <p>
-<package>debmake</package> ¤È¤Ï°Û¤Ê¤ê¡¢<package>debhelper</package> ¤Ï¡¢
-°ì´Ó¤·¤¿Î®µ·¤ÇÆ°ºî¤·¤Ê¤¬¤é¤â¡¢¾®¤µ¤¯¡¢
-ÆÈΩ¤·¤Æ¤¤¤ë¿¿ô¤Î¥³¥Þ¥ó¥É·²¤«¤é¹½À®¤µ¤ì¤Æ¤¤¤Þ¤¹¡£
-¤½¤Î¤¿¤á¡¢<package>debhelper</package> ¤Ï <package>debmake</package>
-¤è¤êºÙ¤«¤Ê´ÉÍý¤ò¹Ô¤Ê¤¦¤³¤È¤¬¤Ç¤¤Þ¤¹¡£
-
- <sect id="debmake">
- <heading><package>debmake</package>
- <p>
-<package>debmake</package> ¤Ï¡¢<package>debhelper</package>
-¤ËÀè¹Ô¤·¤Æ³«È¯¤µ¤ì¤¿¤â¤Î¤Ç¡¢¤è¤êÂç¤Þ¤«¤Ê¥³¥Þ¥ó¥É¤Ç
-<file>debian/rules</file> ¤ÎÊä½õ¤ò¹Ô¤Ê¤¦¤â¤Î¤Ç¤¹
-<package>debmake</package> ¤Ë¤Ï¼ç¤ËÆó¤Ä¤Î¥×¥í¥°¥é¥à¤¬´Þ¤Þ¤ì¤Æ¤¤¤Þ¤¹¡£
-°ì¤Ä¤Ï <prgn>deb-make</prgn> ¤Ç¡¢
-¤³¤Á¤é¤Ï¡¢³«È¯¼Ô¤¬Ä̾ï¤Î (Debian Ū¤Ç¤Ï¤Ê¤¤)
-¥½¡¼¥¹¥¢¡¼¥«¥¤¥Ö¤ò Debian ¥½¡¼¥¹¥Ñ¥Ã¥±¡¼¥¸¤ØÊÑ´¹¤¹¤ëÊä½õ¤ò¤·¤Þ¤¹¡£
-¤â¤¦°ì¤Ä¤Ï <prgn>debstd</prgn> ¤Ç¡¢
-¤³¤Á¤é¤Ï <package>debhelper</package> ¤Ë¤ª¤¤¤Æ¤ÏÊ£¿ô¤Î¥³¥Þ¥ó¥É¤Ë¤è¤Ã¤Æ
-¼Â¸½¤µ¤ì¤Æ¤¤¤ë¼«Æ°²½¤µ¤ì¤¿µ¡Ç½¤ò°ì¤Ä¤Ë¤Þ¤È¤á¤¿¤â¤Î¤Ç¤¹¡£
-
- <p>
-º£¤Ç¤Ï <package>debhelper</package> ¤ÎÍøÍѤ¬¹¥¤Þ¤ì¡¢
-<package>debmake</package> ¤ÎÍøÍѤÏÈò¤±¤è¤¦¤È¤Î¹ç°Õ¤¬¤¢¤ê¤Þ¤¹¡£
-¿·¤¿¤Ê¥Ñ¥Ã¥±¡¼¥¸¤Ë¡¡<package>debmake</package>
-¤ò»È¤¦¤³¤È¤Ï¥Ð¥°¤È¤·¤Æ°·¤ï¤ì¤Þ¤¹¡£<package>debmake</package>¡¡¤ò»È¤Ã¤¿
-¿·¤¿¤Ê¥Ñ¥Ã¥±¡¼¥¸¤Ïº£¸å¥¢¡¼¥«¥¤¥Ö¤«¤éµñÈݤµ¤ì¤Þ¤¹¡£
-
- <sect id="yada">
- <heading><package>yada</package>
- <p>
-<package>yada</package> ¤Ï¼ã´³°Û¤Ê¤ë»×ÁÛ¤ò»ý¤Ä¡¢
-¿·¤¿¤Ê¥Ñ¥Ã¥±¡¼¥¸¥ó¥°Êä½õ¥Ä¡¼¥ë¤Ç¤¹¡£
-<file>debian/packages</file> ¥Õ¥¡¥¤¥ë¤òÍѤ¤¤Æ¡¢
-<file>debian/</file> ¥µ¥Ö¥Ç¥£¥ì¥¯¥È¥ê°Ê²¼¤ËÀßÃÖ¤µ¤ì¤ë
-¾¤ÎɬÍפʥե¡¥¤¥ë¤ò¼«Æ°À¸À®¤·¤Þ¤¹¡£
- <p>
-¤Ê¤ª <package>yada</package> ¤Ï¤Þ¤À¤Þ¤À¿·¤·¤¤¤â¤Î¤Ç¤¹¤Î¤Ç¡¢
-¾¤Î¥·¥¹¥Æ¥à¤ËÈæ¤Ù¤ì¤ÐÌäÂ꤬»Ä¤Ã¤Æ¤¤¤ë²ÄǽÀ¤¬¤¢¤ê¤Þ¤¹¡£
-
- <sect id="equivs">
- <heading><package>equivs</package>
- <p>
-<package>equivs</package> ¤Ï¡¢¥Ñ¥Ã¥±¡¼¥¸ºîÀ®ÍѤË
-ÍÑ°Õ¤µ¤ì¤Æ¤¤¤ë¥Ñ¥Ã¥±¡¼¥¸¤Ç¤¹¡£
-<package>equivs</package> ¤Ï¡¢
-ñ¤Ë°Í¸´Ø·¸¤òËþ¤¿¤¹¤¿¤á¤Ë¥Ñ¥Ã¥±¡¼¥¸¤òºîÀ®¤·¤Ê¤±¤ì¤Ð¤Ê¤é¤Ê¤¤¾ì¹ç¤Ê¤É¤Î¡¢
-¥í¡¼¥«¥ë¤ÊÍøÍѤˤ·¤Ð¤·¤Ð¿ä¾©¤µ¤ì¤Æ¤¤¤ë¤â¤Î¤Ç¤¹¡£
-¤Þ¤¿¡¢Â¾¥Ñ¥Ã¥±¡¼¥¸¤Ë°Í¸¤¹¤ë¤³¤È¤Î¤ß¤òÌÜŪ¤È¤·¤¿¥Ñ¥Ã¥±¡¼¥¸
-``meta-packages'' ¤òºîÀ®¤¹¤ë¾ì¹ç¤Ê¤É¤Ë¤âÍøÍѤµ¤ì¤Þ¤¹¡£
-
- <sect id="cvs-buildpackage">
- <heading><package>cvs-buildpackage</package>
- <p>
-<package>cvs-buildpackage</package> ¤Ï¡¢
-Debian ¥½¡¼¥¹¥Ñ¥Ã¥±¡¼¥¸¤Î CVS ¥ê¥Ý¥¸¥È¥ê¤Ø¤ÎƳÆþ¤ä¥¤¥ó¥Ý¡¼¥È¡¢
-CVS ¥ê¥Ý¥¸¥È¥ê¤«¤é¤Î Debian ¥Ñ¥Ã¥±¡¼¥¸¤Î¹½ÃÛ¡¢
-¥¢¥Ã¥×¥¹¥È¥ê¡¼¥à¤Ë¤ª¤±¤ëÊѹ¹¤Î¥ê¥Ý¥¸¥È¥ê¤Ø¤ÎÅý¹ç¤ÎÊä½õ
-¤È¤¤¤Ã¤¿µ¡Ç½¤òÄ󶡤·¤Þ¤¹¡£
- <p>
-¤³¤ì¤é¤Î¥æ¡¼¥Æ¥£¥ê¥Æ¥£¤Ï¡¢Debian ³«È¯¼Ô¤Ë¤è¤ë CVS
-¤ÎÍøÍѤòÍưפˤ¹¤ë¥¤¥ó¥Õ¥é¤òÄ󶡤·¤Þ¤¹¡£
-<package>cvs-buildpackage</package> ¤òÍøÍѤ¹¤ì¤Ð¡¢
-<em>stable</em> ¤ä¡¢<em>unstable</em>¡¢¾ì¹ç¤Ë¤è¤Ã¤Æ¤Ï <em>experimental</em>
-¤È¤¤¤Ã¤¿¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¸þ¤±¤Ë¡¢
-¤¢¤ë¥Ñ¥Ã¥±¡¼¥¸¤òÆÈΩ¤·¤¿Ê£¿ô¤Î CVS ¥Ö¥é¥ó¥Á¤Ë¤Æ´ÉÍý¤·¤¿¤ê¡¢
-¤½¤Î¤Û¤«¤Î¥Ð¡¼¥¸¥ç¥ó¥³¥ó¥È¥í¡¼¥ë¥·¥¹¥Æ¥à¤Î²¸·Ã¤ò¼õ¤±¤ë¤³¤È¤¬¤Ç¤¤Þ¤¹
-
-
- <sect id="dupload">
- <heading><package>dupload</package>
- <p>
-<package>dupload</package> ¤Ï¡¢
-Debian ¥Ñ¥Ã¥±¡¼¥¸¤ò Debian ¥¢¡¼¥«¥¤¥Ö¤Ë¼«Æ°¥¢¥Ã¥×¥í¡¼¥É¤·¤¿¤ê¡¢
-¥¢¥Ã¥×¥í¡¼¥É¤Î¥í¥°¤ò¤È¤Ã¤¿¤ê¡¢
-¥¢¥Ã¥×¥í¡¼¥É¤Ë´Ø¤¹¤ëÅŻҥ᡼¥ë¤òÁ÷¿®¤·¤¿¤ê¤¹¤ë¡¢
-¥¹¥¯¥ê¥×¥È¤ª¤è¤Ó¥Ñ¥Ã¥±¡¼¥¸¤Ç¤¹¡£
-<package>dupload</package> ¤Ç¤Ï¡¢¿·µ¬¥¢¥Ã¥×¥í¡¼¥É¤ò¹Ô¤Ê¤¦Àè¤Î¾ì½ê¤ä¡¢
-¤½¤ÎÊýË¡¤òÀßÄꤹ¤ë¤³¤È¤â²Äǽ¤Ç¤¹¡£
-
- <sect id="fakeroot">
- <heading><package>fakeroot</package>
- <p>
-<package>fakeroot</package> ¤Ï root ¸¢¸Â¤ò¥·¥ß¥å¥ì¡¼¥È¤·¤Þ¤¹¡£
-<package>fakeroot</package> ¤òÍøÍѤ¹¤ì¤Ð¡¢root
-¤Ë¤Ê¤é¤º¤Ë¥Ñ¥Ã¥±¡¼¥¸¤ò¹½ÃۤǤ¤Þ¤¹¡£
-(³Æ¥Ñ¥Ã¥±¡¼¥¸¤Ç¤Ï¡¢Ä̾ï root
- ¤Î½ê͸¢¤Ç¥Õ¥¡¥¤¥ë¤¬¥¤¥ó¥¹¥È¡¼¥ë¤µ¤ì¤Æ¤¤¤ëɬÍפ¬¤¢¤ê¤Þ¤¹¡£)
-<package>fakeroot</package> ¤¬¥¤¥ó¥¹¥È¡¼¥ë¤µ¤ì¤Æ¤¤¤ì¤Ð¡¢
-°ìÈ̥桼¥¶¤Ç¡¢Î㤨¤Ð <tt>dpkg-buildpackage -rfakeroot</tt>
-¤È¤¹¤ë¤³¤È¤¬¤Ç¤¤Þ¤¹¡£
-
- <sect id="devscripts">
- <heading><package>devscripts</package>
- <p>
-<package>devscripts</package> ¤Ï¡¢Debian ¥Ñ¥Ã¥±¡¼¥¸³«È¯¤ËÌòΩ¤Ä
-¥é¥Ã¥Ñ¡¼¤ä¥Ä¡¼¥ë¤ò¼ýÏ¿¤·¤¿¥Ñ¥Ã¥±¡¼¥¸¤Ç¤¹¡£
-Î㤨¤Ð¡¢<file>debian/changelog</file>
-¥Õ¥¡¥¤¥ë¤ò¥³¥Þ¥ó¥É¥é¥¤¥ó¤«¤éÁàºî¤¹¤ë¤¿¤á¤Î <prgn>debchange</prgn>
-¤ä¡¢<prgn>dpkg-buildpackage</prgn> ¤Î¥é¥Ã¥Ñ¡¼¤Ç¤¢¤ë <prgn>debuild</prgn>
-¤È¤¤¤Ã¤¿¥¹¥¯¥ê¥×¥È¤¬´Þ¤Þ¤ì¤Æ¤¤¤Þ¤¹¡£
-
- <sect id="debget">
- <heading><package>debget</package>
- <p>
-<package>debget</package> ¤Ï¡¢Debian
-¥¢¡¼¥«¥¤¥Ö¤«¤é¥Õ¥¡¥¤¥ë¤ò¥À¥¦¥ó¥í¡¼¥É¤¹¤ëºÝ¤ËÌòΩ¤Ä
-ÊØÍø¤Ê¥¹¥¯¥ê¥×¥È¤ò¼ýÏ¿¤·¤¿¥Ñ¥Ã¥±¡¼¥¸¤Ç¤¹¡£
-Î㤨¤Ð¡¢¥½¡¼¥¹¥Ñ¥Ã¥±¡¼¥¸¤Î¥À¥¦¥ó¥í¡¼¥É¤Ë¤³¤Á¤é¤òÍøÍѤ¹¤ë¤³¤È¤¬¤Ç¤¤Þ¤¹¡£
-
- </book>
-</debiandoc>
-
-<!-- Keep this comment at the end of the file
-Local variables:
-mode: sgml
-sgml-omittag:t
-sgml-shorttag:t
-sgml-minimize-attributes:nil
-sgml-always-quote-attributes:t
-sgml-indent-step:2
-sgml-indent-data:nil
-sgml-parent-document:nil
-sgml-exposed-tags:nil
-sgml-declaration:nil
-sgml-local-catalogs:nil
-sgml-local-ecat-files:nil
-End:
--->
+++ /dev/null
-<!DOCTYPE debiandoc PUBLIC "-//DebianDoc//DTD DebianDoc//EN" [
- <!-- include version information so we don't have to hard code it
- within the document -->
- <!ENTITY % versiondata SYSTEM "version.ent"> %versiondata;
- <!-- common, language independent entities -->
- <!ENTITY % commondata SYSTEM "common.ent" > %commondata;
- <!ENTITY % dynamicdata SYSTEM "dynamic.ent" > %dynamicdata;
-
- <!-- CVS revision of this document -->
- <!ENTITY cvs-rev "$Revision: 1.336 $">
-
- <!-- if you are translating this document, please notate the CVS
- revision of the original developer's reference in cvs-en-rev -->
- <!-- <!ENTITY cvs-en-rev "X.YZW"> -->
-
- <!-- how to mark a section that needs more work -->
- <!ENTITY FIXME "<em>FIXME:</em> ">
-
-]>
-<debiandoc>
- <book>
- <title>Debian Developer's Reference
-
- <author>Developer's Reference Team &email-devel-ref;
- <author>Andreas Barth
- <author>Adam Di Carlo
- <author>Raphaël Hertzog
- <author>Christian Schwarz
- <author>Ian Jackson
- <version>ver. &version;, &date-en;
-
- <copyright>
- <copyrightsummary>
-copyright © 2004—2007 Andreas Barth</copyrightsummary>
- <copyrightsummary>
-copyright © 1998—2003 Adam Di Carlo</copyrightsummary>
- <copyrightsummary>
-copyright © 2002—2003 Raphaël Hertzog</copyrightsummary>
- <copyrightsummary>
-copyright © 1997, 1998 Christian Schwarz</copyrightsummary>
- <p>
-This manual is free software; you may redistribute it and/or modify it
-under the terms of the GNU General Public License as published by the
-Free Software Foundation; either version 2, or (at your option) any
-later version.
- <p>
-This is distributed in the hope that it will be useful, but
-<em>without any warranty</em>; without even the implied warranty of
-merchantability or fitness for a particular purpose. See the GNU
-General Public License for more details.
- <p>
-A copy of the GNU General Public License is available as &file-GPL; in
-the &debian-formal; distribution or on the World Wide Web at <url
-id="&url-gpl;" name="the GNU web site">. You can also obtain it by
-writing to the &fsf-addr;.
-
-<![ %htmltext [
- <p>
-If you want to print this reference, you should use the <url
-id="developers-reference.pdf" name="pdf version">.
-This page is also available in <url id="index.fr.html" name="French">.
-]]>
-
- <toc detail="sect1">
-
- <chapt id="scope">Scope of This Document
- <p>
-The purpose of this document is to provide an overview of the
-recommended procedures and the available resources for Debian
-developers.
-
-<!-- FIXME: rewrites -->
- <p>
-The procedures discussed within include how to become a maintainer
-(<ref id="new-maintainer">); how to create new packages
-(<ref id="newpackage">) and how to upload packages (<ref id="upload">);
-how to handle bug reports (<ref id="bug-handling">); how to move,
-remove, or orphan packages (<ref id="archive-manip">); how to port
-packages (<ref id="porting">); and how and when to do interim
-releases of other maintainers' packages (<ref id="nmu">).
- <p>
-The resources discussed in this reference include the mailing lists
-(<ref id="mailing-lists">) and servers (<ref id="server-machines">); a
-discussion of the structure of the Debian archive (<ref
-id="archive">); explanation of the different servers which accept
-package uploads (<ref id="upload-ftp-master">); and a discussion of
-resources which can help maintainers with the quality of their
-packages (<ref id="tools">).
- <p>
-It should be clear that this reference does not discuss the technical
-details of Debian packages nor how to generate them.
-Nor does this reference detail the standards to which Debian software
-must comply. All of such information can be found in the <url
-id="&url-debian-policy;" name="Debian Policy Manual">.
- <p>
-Furthermore, this document is <em>not an expression of formal
-policy</em>. It contains documentation for the Debian system and
-generally agreed-upon best practices. Thus, it is not what is called a
-``normative'' document.
-
-
- <chapt id="new-maintainer">Applying to Become a Maintainer
-
- <sect id="getting-started">Getting started
- <p>
-So, you've read all the documentation, you've gone through the <url
-id="&url-newmaint-guide;" name="Debian New Maintainers' Guide">,
-understand what everything in the <package>hello</package> example
-package is for, and you're about to Debianize your favorite piece of
-software. How do you actually become a Debian developer so that your
-work can be incorporated into the Project?
- <p>
-Firstly, subscribe to &email-debian-devel; if you haven't already.
-Send the word <tt>subscribe</tt> in the <em>Subject</em> of an email
-to &email-debian-devel-req;. In case of problems, contact the list
-administrator at &email-listmaster;. More information on available
-mailing lists can be found in <ref id="mailing-lists">.
-&email-debian-devel-announce; is another list which is mandatory
-for anyone who wishes to follow Debian's development.
- <p>
-You should subscribe and lurk (that is, read without posting) for a
-bit before doing any coding, and you should post about your intentions
-to work on something to avoid duplicated effort.
- <p>
-Another good list to subscribe to is &email-debian-mentors;. See <ref
-id="mentors"> for details. The IRC channel <tt>#debian</tt> can also be
-helpful; see <ref id="irc-channels">.
-
- <p>
-When you know how you want to contribute to &debian-formal;, you
-should get in contact with existing Debian maintainers who are working
-on similar tasks. That way, you can learn from experienced developers.
-For example, if you are interested in packaging existing software for
-Debian, you should try to get a sponsor. A sponsor will work together
-with you on your package and upload it to the Debian archive once they
-are happy with the packaging work you have done. You can find a sponsor
-by mailing the &email-debian-mentors; mailing list, describing your
-package and yourself and asking for a sponsor (see <ref id="sponsoring">
-and <url id="&url-mentors;"> for more information on sponsoring).
-On the other hand, if you are
-interested in porting Debian to alternative architectures or kernels
-you can subscribe to port specific mailing lists and ask there how to
-get started. Finally, if you are interested in documentation or
-Quality Assurance (QA) work you can join maintainers already working on
-these tasks and submit patches and improvements.
-
- <p>
-One pitfall could be a too-generic local part in your mailadress:
-Terms like mail, admin, root, master should be avoided, please
-see <url id="http://www.debian.org/MailingLists/"> for details.
-
-
- <sect id="mentors">Debian mentors and sponsors
- <p>
-The mailing list &email-debian-mentors; has been set up for novice
-maintainers who seek help with initial packaging and other
-developer-related issues. Every new developer is invited to subscribe
-to that list (see <ref id="mailing-lists"> for details).
- <p>
-Those who prefer one-on-one help (e.g., via private email) should also
-post to that list and an experienced developer will volunteer to help.
- <p>
-In addition, if you have some packages ready for inclusion in Debian,
-but are waiting for your new maintainer application to go through, you
-might be able find a sponsor to upload your package for you. Sponsors
-are people who are official Debian Developers, and who are willing to
-criticize and upload your packages for you.
-<!-- FIXME - out of order
-Those who are seeking a
-sponsor can request one at <url id="&url-sponsors;">.
--->
-Please read the
-unofficial debian-mentors FAQ at <url id="&url-mentors;"> first.
- <p>
-If you wish to be a mentor and/or sponsor, more information is
-available in <ref id="newmaint">.
-
-
- <sect id="registering">Registering as a Debian developer
- <p>
-Before you decide to register with &debian-formal;, you will need to
-read all the information available at the <url id="&url-newmaint;"
-name="New Maintainer's Corner">. It describes in detail the
-preparations you have to do before you can register to become a Debian
-developer.
-
-For example, before you apply, you have to read the <url
-id="&url-social-contract;" name="Debian Social Contract">.
-Registering as a developer means that you agree with and pledge to
-uphold the Debian Social Contract; it is very important that
-maintainers are in accord with the essential ideas behind
-&debian-formal;. Reading the <url id="&url-gnu-manifesto;" name="GNU
-Manifesto"> would also be a good idea.
- <p>
-The process of registering as a developer is a process of verifying
-your identity and intentions, and checking your technical skills. As
-the number of people working on &debian-formal; has grown to over
-&number-of-maintainers; and our systems are used in several
-very important places, we have to be careful about being compromised.
-Therefore, we need to verify new maintainers before we can give them
-accounts on our servers and let them upload packages.
- <p>
-Before you actually register you should have shown that you can do
-competent work and will be a good contributor.
-You show this by submitting patches through the Bug Tracking System
-and having a package
-sponsored by an existing Debian Developer for a while.
-Also, we expect that
-contributors are interested in the whole project and not just in
-maintaining their own packages. If you can help other maintainers by
-providing further information on a bug or even a patch, then do so!
- <p>
-Registration requires that you are familiar with Debian's philosophy
-and technical documentation. Furthermore, you need a GnuPG key which
-has been signed by an existing Debian maintainer. If your GnuPG key
-is not signed yet, you should try to meet a Debian Developer in
-person to get your key signed. There's a <url id="&url-gpg-coord;"
-name="GnuPG Key Signing Coordination page"> which should help you find
-a Debian Developer close to you.
-(If there is no Debian Developer close to you,
-alternative ways to pass the ID check may be permitted
-as an absolute exception on a case-by-case-basis.
-See the <url id="&url-newmaint-id;" name="identification page">
-for more information.)
-
- <p>
-If you do not have an OpenPGP key yet, generate one. Every developer
-needs an OpenPGP key in order to sign and verify package uploads. You
-should read the manual for the software you are using, since it has
-much important information which is critical to its security. Many
-more security failures are due to human error than to software failure
-or high-powered spy techniques. See <ref id="key-maint"> for more
-information on maintaining your public key.
- <p>
-Debian uses the <prgn>GNU Privacy Guard</prgn> (package
-<package>gnupg</package> version 1 or better) as its baseline standard.
-You can use some other implementation of OpenPGP as well. Note that
-OpenPGP is an open standard based on <url id="&url-rfc2440;" name="RFC
-2440">.
- <p>
-You need a version 4 key for use in Debian Development.
-Your key length must be at least 1024
-bits; there is no reason to use a smaller key, and doing so would be
-much less secure.
-<footnote>Version 4 keys are keys conforming to
-the OpenPGP standard as defined in RFC 2440. Version 4 is the key
-type that has always been created when using GnuPG. PGP versions
-since 5.x also could create v4 keys, the other choice having beein
-pgp 2.6.x compatible v3 keys (also called "legacy RSA" by PGP).
-<p>
-Version 4 (primary) keys can either use the RSA or the DSA algorithms,
-so this has nothing to do with GnuPG's question about "which kind
-of key do you want: (1) DSA and Elgamal, (2) DSA (sign only), (5)
-RSA (sign only)". If you don't have any special requirements just pick
-the default.
-<p>
-The easiest way to tell whether an existing key is a v4 key or a v3
-(or v2) key is to look at the fingerprint:
-Fingerprints of version 4 keys are the SHA-1 hash of some key matieral,
-so they are 40 hex digits, usually grouped in blocks of 4. Fingerprints
-of older key format versions used MD5 and are generally shown in blocks
-of 2 hex digits. For example if your fingerprint looks like
-<tt>5B00 C96D 5D54 AEE1 206B AF84 DE7A AF6E 94C0 9C7F</tt>
-then it's a v4 key.
-<p>
-Another possibility is to pipe the key into <prgn>pgpdump</prgn>,
-which will say something like "Public Key Packet - Ver 4".
-<p>
-Also note that your key must be self-signed (i.e. it has to sign
-all its own user IDs; this prevents user ID tampering). All
-modern OpenPGP software does that automatically, but if you
-have an older key you may have to manually add those signatures.
-</footnote>
- <p>
-If your public key isn't on a public key server such as &pgp-keyserv;,
-please read the documentation available at
-<url id="&url-newmaint-id;" name="NM Step 2: Identification">.
-That document contains instructions on how to put your key on the
-public key servers. The New Maintainer Group will put your public key
-on the servers if it isn't already there.
- <p>
-Some countries restrict the use of cryptographic software by their
-citizens. This need not impede one's activities as a Debian package
-maintainer however, as it may be perfectly legal to use cryptographic
-products for authentication, rather than encryption purposes.
-If you live in a country where use of
-cryptography even for authentication is forbidden
-then please contact us so we can make special arrangements.
- <p>
-To apply as a new maintainer, you need an existing Debian Developer
-to support your application (an <em>advocate</em>). After you have
-contributed to Debian for a while, and you want to apply to become a
-registered developer, an existing developer with whom you
-have worked over the past months has to express their belief that you
-can contribute to Debian successfully.
- <p>
-When you have found an advocate, have your GnuPG key signed and have
-already contributed to Debian for a while, you're ready to apply.
-You can simply register on our <url id="&url-newmaint-apply;"
-name="application page">. After you have signed up, your advocate
-has to confirm your application. When your advocate has completed
-this step you will be assigned an Application Manager who will
-go with you through the necessary steps of the New Maintainer process.
-You can always check your status on the <url id="&url-newmaint-db;"
-name="applications status board">.
- <p>
-For more details, please consult <url id="&url-newmaint;" name="New
-Maintainer's Corner"> at the Debian web site. Make sure that you
-are familiar with the necessary steps of the New Maintainer process
-before actually applying. If you are well prepared, you can save
-a lot of time later on.
-
-
- <chapt id="developer-duties">Debian Developer's Duties
-
- <sect id="user-maint">Maintaining your Debian information
- <p>
-There's a LDAP database containing information about Debian developers at
-<url id="&url-debian-db;">. You should enter your information there and
-update it as it changes. Most notably, make sure that the address where your
-debian.org email gets forwarded to is always up to date, as well as the
-address where you get your debian-private subscription if you choose to
-subscribe there.
- <p>
-For more information about the database, please see <ref id="devel-db">.
-
-
-
- <sect id="key-maint">Maintaining your public key
- <p>
-Be very careful with your private keys. Do not place them on any
-public servers or multiuser machines, such as the Debian servers
-(see <ref id="server-machines">). Back your keys up; keep a copy offline.
-Read the documentation that comes with your software; read the <url
-id="&url-pgp-faq;" name="PGP FAQ">.
- <p>
-You need to ensure not only that your key is secure against being stolen,
-but also that it is secure against being lost. Generate and make a copy
-(best also in paper form) of your revocation certificate; this is needed if
-your key is lost.
- <p>
-If you add signatures to your public key, or add user identities, you
-can update the Debian key ring by sending your key to the key server at
-<tt>&keyserver-host;</tt>.
- <p>
-If you need to add a completely new key or remove an old key, you need
-to get the new key signed by another developer.
-If the old key is compromised or invalid, you
-also have to add the revocation certificate. If there is no real
-reason for a new key, the Keyring Maintainers might reject the new key.
-Details can be found at
-<url id="http://keyring.debian.org/replacing_keys.html">.
- <p>
-The same key extraction routines discussed in <ref id="registering">
-apply.
- <p>
-You can find a more in-depth discussion of Debian key maintenance in
-the documentation of the <package>debian-keyring</package> package.
-
-
- <sect id="voting">Voting
- <p>
-Even though Debian isn't really a democracy, we use a democratic
-process to elect our leaders and to approve general resolutions.
-These procedures are defined by the
-<url id="&url-constitution;" name="Debian Constitution">.
- <p>
-Other than the yearly leader election, votes are not routinely held, and
-they are not undertaken lightly. Each proposal is first discussed on
-the &email-debian-vote; mailing list and it requires several endorsements
-before the project secretary starts the voting procedure.
- <p>
-You don't have to track the pre-vote discussions, as the secretary will
-issue several calls for votes on &email-debian-devel-announce; (and all
-developers are expected to be subscribed to that list). Democracy doesn't
-work well if people don't take part in the vote, which is why we encourage
-all developers to vote. Voting is conducted via GPG-signed/encrypted email
-messages.
- <p>
-The list of all proposals (past and current) is available on the
-<url id="&url-vote;" name="Debian Voting Information"> page, along with
-information on how to make, second and vote on proposals.
-
-
- <sect id="inform-vacation">Going on vacation gracefully
- <p>
-It is common for developers to have periods of absence, whether those are
-planned vacations or simply being buried in other work. The important thing
-to notice is that other developers need to know that you're on vacation
-so that they can do whatever is needed if a problem occurs with your
-packages or other duties in the project.
- <p>
-Usually this means that other developers are allowed to NMU (see
-<ref id="nmu">) your package if a big problem (release critical bug,
-security update, etc.) occurs while you're on vacation. Sometimes it's
-nothing as critical as that, but it's still appropriate to let others
-know that you're unavailable.
- <p>
-In order to inform the other developers, there are two things that you
-should do. First send a mail to &email-debian-private; with "[VAC] "
-prepended to the subject of your message<footnote>This is so that the
-message can be easily filtered by people who don't want to read vacation
-notices.</footnote> and state the period of time when you will be on
-vacation. You can also give some special instructions on what to do if a
-problem occurs.
- <p>
-The other thing to do is to mark yourself as "on vacation" in the
-<qref id="devel-db">Debian developers' LDAP database</qref> (this
-information is only accessible to Debian developers).
-Don't forget to remove the "on vacation" flag when you come back!
- <p>
-Ideally, you should sign up at the
-<url id="http://nm.debian.org/gpg.php" name="GPG coordination site">
-when booking a holiday and check if anyone there is looking for signing.
-This is especially important when people go to exotic places
-where we don't have any developers yet but
-where there are people who are interested in applying.
-
-
- <sect id="upstream-coordination">Coordination with upstream developers
- <p>
-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
-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.
- <p>
-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.
- <p>
-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
-developers which can be included there, so that you won't have to
-modify the sources of the next upstream version. Whatever changes you
-need, always try not to fork from the upstream sources.
-
-
- <sect id="rc-bugs">Managing release-critical bugs
- <p>
-Generally you should deal with bug reports on your packages as described in
-<ref id="bug-handling">. However, there's a special category of bugs that
-you need to take care of — the so-called release-critical bugs (RC
-bugs). All bug reports that have severity <em>critical</em>,
-<em>grave</em> or <em>serious</em> are considered to have an impact on
-whether the package can be released in the next stable release of Debian.
-These bugs can delay the Debian release and/or can justify the removal of
-a package at freeze time. That's why these bugs need to be corrected as
-quickly as possible.
- <p>
-Developers who are part of the <url id="&url-debian-qa;"
-name="Quality Assurance"> group are following all such bugs, and trying
-to help whenever possible. If, for any reason, you aren't able fix an
-RC bug in a package of yours within 2 weeks, you should either ask for help
-by sending a mail to the Quality Assurance (QA) group
-&email-debian-qa;, or explain your difficulties and present a plan to fix
-them by sending a mail to the bug report. Otherwise, people
-from the QA group may want to do a Non-Maintainer Upload (see
-<ref id="nmu">) after trying to contact you (they might not wait as long as
-usual before they do their NMU if they have seen no recent activity from you
-in the BTS).
-
-
- <sect>Retiring
- <p>
-If you choose to leave the Debian project, you should make sure you do
-the following steps:
-<enumlist>
- <item>
-Orphan all your packages, as described in <ref id="orphaning">.
- <item>
-Send an gpg-signed email about why you are leaving the project to
-&email-debian-private;.
- <item>
-Notify the Debian key ring maintainers that you are leaving by
-opening a ticket in Debian RT by sending a mail
-to keyring@rt.debian.org with the words 'Debian RT' somewhere in the subject
-line (case doesn't matter).
-</enumlist>
-
-
-
- <chapt id="resources">Resources for Debian Developers
- <p>
-In this chapter you will find a very brief road map of the Debian
-mailing lists, the Debian machines
-which may be available to you as a developer, and all the other
-resources that are available to help you in your maintainer work.
-
- <sect id="mailing-lists">Mailing lists
- <p>
-Much of the conversation between Debian developers (and users) is managed
-through a wide array of mailing lists we host at
-<tt><url id="http://&lists-host;/" name="&lists-host;"></tt>.
-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 <url id="&url-debian-lists;">. This section will only cover
-aspects of mailing lists that are of particular interest to developers.
-
- <sect1 id="mailing-lists-rules">Basic rules for use
- <p>
-When replying to messages on the mailing list, please do not send a
-carbon copy (<tt>CC</tt>) 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.
- <p>
-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.
- <p>
-Please read the <url name="code of conduct"
-id="&url-debian-lists;#codeofconduct"> for more information. The <url
-name="Debian Community Guidelines" id="&url-dcg;">
-are also worth reading.
-
- <sect1 id="core-devel-mailing-lists">Core development mailing lists
- <p>
-The core Debian mailing lists that developers should use are:
-<list>
- <item>&email-debian-devel-announce;, used to announce important things to
- developers.
- All developers are expected to be subscribed to this list.
- </item>
- <item>&email-debian-devel;, used to discuss various development related
- technical issues.
- </item>
- <item>&email-debian-policy;, where the Debian Policy is discussed and
- voted on.
- </item>
- <item>&email-debian-project;, used to discuss various non-technical
- issues related to the project.
- </item>
-</list>
- <p>
-There are other mailing lists available for a variety of special topics;
-see <url id="http://&lists-host;/"> for a list.
-
- <sect1 id="mailing-lists-special">Special lists
- <p>
-&email-debian-private; is a special mailing list for private
-discussions amongst Debian developers. It is meant to be used for
-posts which for whatever reason should not be published publicly.
-As such, it is a low volume list, and users are urged not to use
-&email-debian-private; unless it is really necessary. Moreover, do
-<em>not</em> forward email from that list to anyone. Archives of this
-list are not available on the web for obvious reasons, but you can see
-them using your shell account on <tt>lists.debian.org</tt> and looking
-in the <file>~debian/archive/debian-private</file> directory.
- <p>
-&email-debian-email; is a special mailing list used as a grab-bag
-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.
-
- <sect1 id="mailing-lists-new">Requesting new development-related lists
- <p>
-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 <var>you-aliasname@debian.org</var>
-address) or a self-managed mailing list on <qref id="alioth">Alioth</qref>
-is more appropriate.
- <p>
-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 <url name="the HOWTO"
-id="&url-debian-lists-new;">.
-
- <sect id="irc-channels">IRC channels
- <p>
-Several IRC channels are dedicated to Debian's development. They are mainly
-hosted on the <url id="&url-oftc;" name="Open and free technology community
-(OFTC)"> network. The <tt>irc.debian.org</tt> DNS entry is an alias to
-<tt>irc.oftc.net</tt>.
- <p>
-The main channel for Debian in general is <em>#debian</em>. This is a large,
-general-purpose channel where users can find recent news in the topic and
-served by bots. <em>#debian</em> is for English speakers; there are also
-<em>#debian.de</em>, <em>#debian-fr</em>, <em>#debian-br</em> and other
-similarly named channels for speakers of other languages.
- <p>
-The main channel for Debian development is <em>#debian-devel</em>.
-It is a very active channel since usually over 150 people are always
-logged in. It's a channel for people who work
-on Debian, it's not a support channel (there's <em>#debian</em> for that).
-It is however open to anyone who wants to lurk (and learn). Its topic is
-commonly full of interesting information for developers.
- <p>
-Since <em>#debian-devel</em> is an open channel, you
-should not speak there of issues that are discussed in
-&email-debian-private;. There's another channel for this purpose,
-it's called <em>#debian-private</em> and it's protected by a key.
-This key is available in the archives of debian-private in
-<file>master.debian.org:&file-debian-private-archive;</file>,
-just <prgn>zgrep</prgn> for <em>#debian-private</em> in
-all the files.
- <p>
-There are other additional channels dedicated to specific subjects.
-<em>#debian-bugs</em> is used for coordinating bug squashing parties.
-<em>#debian-boot</em> is used to coordinate the work on the debian-installer.
-<em>#debian-doc</em> is
-occasionally used to talk about documentation, like the document you are
-reading. Other channels are dedicated to an architecture or a set of
-packages: <em>#debian-bsd</em>, <em>#debian-kde</em>, <em>#debian-jr</em>,
-<em>#debian-edu</em>,
-<em>#debian-oo</em> (OpenOffice
-package) ...
- <p>
-Some non-English developers' channels exist as well, for example
-<em>#debian-devel-fr</em> for
-French speaking people interested in Debian's development.
- <p>
-Channels dedicated to Debian also exist on other IRC networks, notably on
-the <url id="&url-openprojects;" name="freenode"> IRC network, which was
-pointed at by the <tt>irc.debian.org</tt> alias until 4th June 2006.
- <p>
-To get a cloak on freenode, you send Jörg Jaspert
-<joerg@debian.org> a signed mail where you tell what your nick is.
-Put "cloak" somewhere in the Subject: header.
-The nick should be registered:
-<url id="http://freenode.net/faq.shtml#nicksetup" name="Nick Setup Page">.
-The mail needs to be signed by a key in the Debian keyring.
-Please see
-<url id="http://freenode.net/faq.shtml#projectcloak" name="Freenodes
-documentation"> for more information about cloaks.
-
-
- <sect id="doc-rsrcs">Documentation
- <p>
-This document contains a lot of information
-which is useful to Debian developers,
-but it cannot contain everything. Most of the other interesting documents
-are linked from <url id="&url-devel-docs;" name="The Developers' Corner">.
-Take the time to browse all the links, you will learn many more things.
-
-
- <sect id="server-machines">Debian machines
- <p>
-Debian has several computers working as servers, most of which serve
-critical functions in the Debian project. Most of the machines are used
-for porting activities, and they all have a permanent connection to the
-Internet.
- <p>
-Some of the machines are available for individual developers to use,
-as long as the developers follow the rules set forth in the
-<url name="Debian Machine Usage Policies" id="&url-dmup;">.
- <p>
-Generally speaking, you can use these machines for Debian-related purposes
-as you see fit. Please be kind to system administrators, and do not use
-up tons and tons of disk space, network bandwidth, or CPU without first
-getting the approval of the system administrators. Usually these machines
-are run by volunteers.
- <p>
-Please take care to protect your Debian passwords and SSH keys installed on
-Debian machines. Avoid login or upload methods which send passwords over
-the Internet in the clear, such as telnet, FTP, POP etc.
- <p>
-Please do not put any material that doesn't relate to Debian on the Debian
-servers, unless you have prior permission.
- <p>
-The current list of Debian machines is available at
-<url id="&url-devel-machines;">. That web page contains machine names,
-contact information, information about who can log in, SSH keys etc.
- <p>
-If you have a problem with the operation of a Debian server, and you
-think that the system operators need to be notified of this problem,
-you can check the list of open issues in the DSA queue of our request
-tracker at <url id="&url-rt;"> (you can login with user "guest" and
-password "readonly"). To report a new problem, simply send a mail to
-<email>admin@rt.debian.org</email> and make sure to put the string
-"Debian RT" somewhere in the subject.
- <p>
-If you have a problem with a certain service, not related to the system
-administration (such as packages to be removed from the archive,
-suggestions for the web site, etc.),
-generally you'll report a bug against a ``pseudo-package''. See <ref
-id="submit-bug"> for information on how to submit bugs.
- <p>
-Some of the core servers are restricted, but the information from there
-is mirrored to another server.
-
- <sect1 id="servers-bugs">The bugs server
- <p>
-<tt>&bugs-host;</tt> is the canonical location for the Bug Tracking
-System (BTS).
- <p>
-It is restricted; a mirror is available on <tt>merkel</tt>.
- <p>
-If you plan on doing some statistical analysis or
-processing of Debian bugs, this would be the place to do it. Please
-describe your plans on &email-debian-devel; before implementing
-anything, however, to reduce unnecessary duplication of effort or
-wasted processing time.
-
- <sect1 id="servers-ftp-master">The ftp-master server
- <p>
-The <tt>ftp-master.debian.org</tt> server holds the canonical copy of the
-Debian archive. Generally, package uploads
-go to this server; see <ref id="upload">.
- <p>
-It is restricted; a mirror is available on <tt>merkel</tt>.
- <p>
-Problems with the Debian FTP archive generally need to be reported as
-bugs against the <package>ftp.debian.org</package> pseudo-package or
-an email to &email-ftpmaster;, but also see the procedures in
-<ref id="archive-manip">.
-
- <sect1 id="servers-www">The www-master server
- <p>
-The main web server is <tt>www-master.debian.org</tt>.
-It holds the official web pages, the face
-of Debian for most newbies.
- <p>
-If you find a problem with the Debian web server, you should generally
-submit a bug against the pseudo-package,
-<package>www.debian.org</package>. Remember to check whether or not someone
-else has already reported the problem to the
-<url id="http://&bugs-host;/www.debian.org" name="Bug Tracking System">.
-
- <sect1 id="servers-people">The people web server
- <p>
-<tt>people.debian.org</tt> is the server used
-for developers' own web pages about anything related to Debian.
- <p>
-If you have some Debian-specific information which you want to serve
-on the web, you can do this by putting material in the
-<file>public_html</file> directory under your home directory on
-<tt>people.debian.org</tt>.
-This will be accessible at the URL
-<tt>http://people.debian.org/~<var>your-user-id</var>/</tt>.
- <p>
-You should only use this particular location because it will be backed up,
-whereas on other hosts it won't.
- <p>
-Usually the only reason to use a different host is when you need to publish
-materials subject to the U.S. export restrictions, in which case you can use
-one of the other servers located outside the United States.
- <p>
-Send mail to &email-debian-devel; if you have any questions.
-
- <sect1 id="servers-vcs">The VCS servers
- <p>
-If you need to use a Version Control System for any of your Debian work,
-you can use one the existing repositories hosted on Alioth or you can
-request a new project and ask for the VCS repository of your choice.
-Alioth supports CVS (alioth.debian.org), Subversion
-(svn.debian.org), Arch (tla/baz, both on arch.debian.org), Bazaar
-(bzr.debian.org), Mercurial (hg.debian.org) and Git (git.debian.org).
-Checkout <url id="&url-alioth-pkg;"> if you plan
-to maintain packages in a VCS repository. See <ref id="alioth"> for
-information on the services provided by Alioth.
- <p>
-Historically, Debian first used <tt>cvs.debian.org</tt> to host CVS
-repositories. But that service is deprecated in favor of Alioth.
-Only a few projects are still using it.
-
- <sect1 id="dchroot">chroots to different distributions
- <p>
-On some machines, there are chroots to different distributions available.
-You can use them like this:
-
-<example>
-vore% dchroot unstable
-Executing shell in chroot: /org/vore.debian.org/chroots/user/unstable
-</example>
-
-In all chroots, the normal user home directories are available.
-You can find out which chroots are available via
-<tt>&url-devel-machines;</tt>.
-
-
- <sect id="devel-db">The Developers Database
- <p>
-The Developers Database, at <url id="&url-debian-db;">, is an LDAP
-directory for managing Debian developer attributes. You can use this
-resource to search the list of Debian developers.
-Part of this information is also available through
-the finger service on Debian servers, try
-<prgn>finger yourlogin@db.debian.org</prgn> to see what it reports.
- <p>
-Developers can <url name="log into the database" id="&url-debian-db-login;">
-to change various information about themselves, such as:
-<list>
- <item>forwarding address for your debian.org email
- <item>subscription to debian-private
- <item>whether you are on vacation
- <item>personal information such as your address, country,
- the latitude and longitude of the place where you live
- for use in <url name="the world map of Debian developers"
- id="&url-worldmap;">, phone and fax numbers, IRC nickname
- and web page
- <item>password and preferred shell on Debian Project machines
-</list>
- <p>
-Most of the information is not accessible to the public, naturally.
-For more information please read the online documentation that you can find
-at <url id="&url-debian-db-doc;">.
- <p>
-Developers can also submit their SSH keys to be used for authorization on the
-official Debian machines, and even add new *.debian.net DNS entries.
-Those features are documented at <url id="&url-debian-db-mail-gw;">.
-
-
- <sect id="archive">The Debian archive
- <p>
-The &debian-formal; distribution consists of a lot of packages
-(<file>.deb</file>'s, currently around &number-of-pkgs;) and a few
-additional files (such as documentation and installation disk images).
- <p>
-Here is an example directory tree of a complete Debian archive:
- <p>
-&sample-dist-dirtree;
- <p>
-As you can see, the top-level directory contains two directories,
-<file>dists/</file> and <file>pool/</file>. The latter is a
-“pool” in which the
-packages actually are, and which is handled by the archive maintenance
-database and the accompanying programs. The former contains the
-distributions, <em>stable</em>, <em>testing</em> and <em>unstable</em>.
-The <file>Packages</file> and <file>Sources</file> files in the
-distribution subdirectories can reference files in the <file>pool/</file>
-directory. The directory tree below each of the distributions is arranged
-in an identical manner. What we describe below for <em>stable</em> is
-equally applicable to the <em>unstable</em> and <em>testing</em>
-distributions.
- <p>
-<file>dists/stable</file> contains three directories, namely
-<file>main</file>, <file>contrib</file>, and <file>non-free</file>.
- <p>
-In each of the areas, there is a directory for the source packages
-(<file>source</file>) and a directory for each supported architecture
-(<file>binary-i386</file>, <file>binary-m68k</file>, etc.).
- <p>
-The <file>main</file> 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
-(<file>disks-i386</file>, <file>disks-m68k</file>, etc.).
-
-
- <sect1 id="archive-sections">Sections
- <p>
-The <em>main</em> section of the Debian archive is what makes up the
-<strong>official &debian-formal; distribution</strong>. The
-<em>main</em> section is official because it fully complies with all
-our guidelines. The other two sections do not, to different degrees;
-as such, they are <strong>not</strong> officially part of
-&debian-formal;.
- <p>
-Every package in the main section must fully comply with the <url
-id="&url-dfsg;" name="Debian Free Software Guidelines"> (DFSG) and
-with all other policy requirements as described in the <url
-id="&url-debian-policy;" name="Debian Policy Manual">. The DFSG is
-our definition of “free software.” Check out the Debian Policy
-Manual for details.
- <p>
-Packages in the <em>contrib</em> section have to comply with the DFSG,
-but may fail other requirements. For instance, they may depend on
-non-free packages.
- <p>
-Packages which do not conform to the DFSG are placed in the
-<em>non-free</em> section. These packages are not considered as part
-of the Debian distribution, though we support their use, and we
-provide infrastructure (such as our bug-tracking system and mailing
-lists) for non-free software packages.
- <p>
-The <url id="&url-debian-policy;" name="Debian Policy Manual">
-contains a more exact definition of the three sections. The above
-discussion is just an introduction.
- <p>
-The separation of the three sections at the top-level of the archive
-is important for all people who want to distribute Debian, either via
-FTP servers on the Internet or on CD-ROMs: by distributing only the
-<em>main</em> and <em>contrib</em> sections, one can avoid any legal
-risks. Some packages in the <em>non-free</em> section do not allow
-commercial distribution, for example.
- <p>
-On the other hand, a CD-ROM vendor could easily check the individual
-package licenses of the packages in <em>non-free</em> and include as
-many on the CD-ROMs as it's allowed to. (Since this varies greatly from
-vendor to vendor, this job can't be done by the Debian developers.)
- <p>
-Note that the term "section" is also used to refer to categories
-which simplify the organization and browsing of available packages, e.g.
-<em>admin</em>, <em>net</em>, <em>utils</em> etc. Once upon a time, these
-sections (subsections, rather) existed in the form of subdirectories within
-the Debian archive. Nowadays, these exist only in the "Section" header
-fields of packages.
-
-
- <sect1>Architectures
- <p>
-In the first days, the Linux kernel was only available for Intel
-i386 (or greater) platforms, and so was Debian. But as Linux became
-more and more popular, the kernel was ported to other architectures,
-too.
- <p>
-The Linux 2.0 kernel supports Intel x86, DEC Alpha, SPARC, Motorola
-680x0 (like Atari, Amiga and Macintoshes), MIPS, and PowerPC. The
-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 kernels. Aside from
-<em>i386</em> (our name for Intel x86), there is <em>m68k</em>,
-<em>alpha</em>, <em>powerpc</em>, <em>sparc</em>, <em>hurd-i386</em>,
-<em>arm</em>, <em>ia64</em>, <em>hppa</em>, <em>s390</em>, <em>mips</em>,
-<em>mipsel</em> and <em>sh</em> as of this writing.
- <p>
-&debian-formal; 1.3 is only available as <em>i386</em>. Debian 2.0
-shipped for <em>i386</em> and <em>m68k</em> architectures. Debian 2.1
-ships for the <em>i386</em>, <em>m68k</em>, <em>alpha</em>, and
-<em>sparc</em> architectures. Debian 2.2 added support for the
-<em>powerpc</em> and <em>arm</em> architectures. Debian 3.0 added
-support of five new architectures: <em>ia64</em>, <em>hppa</em>,
-<em>s390</em>, <em>mips</em> and <em>mipsel</em>.
- <p>
-Information for developers and users about the specific ports are
-available at the <url id="&url-debian-ports;" name="Debian Ports web
-pages">.
-
-
-
- <sect1>Packages
- <p>
-There are two types of Debian packages, namely <em>source</em> and
-<em>binary</em> packages.
- <p>
-Source packages consist of either two or three files: a <file>.dsc</file>
-file, and either a <file>.tar.gz</file> file or both an
-<file>.orig.tar.gz</file> and a <file>.diff.gz</file> file.
- <p>
-If a package is developed specially for Debian and is not distributed
-outside of Debian, there is just one <file>.tar.gz</file> file which
-contains the sources of the program. If a package is distributed
-elsewhere too, the <file>.orig.tar.gz</file> file stores the so-called
-<em>upstream source code</em>, that is the source code that's
-distributed by the <em>upstream maintainer</em> (often the author of
-the software). In this case, the <file>.diff.gz</file> contains the
-changes made by the Debian maintainer.
- <p>
-The <file>.dsc</file> file lists all the files in the source package together
-with checksums (<prgn>md5sums</prgn>) and some additional info about
-the package (maintainer, version, etc.).
-
-
- <sect1>Distributions
- <p>
-The directory system described in the previous chapter is itself
-contained within <em>distribution directories</em>. Each
-distribution is actually contained in the <file>pool</file> directory in the
-top-level of the Debian archive itself.
- <p>
-To summarize, the Debian archive has a root directory within an FTP
-server. For instance, at the mirror site,
-<ftpsite>ftp.us.debian.org</ftpsite>, the Debian archive itself is
-contained in <ftppath>/debian</ftppath>, which is a common location
-(another is <file>/pub/debian</file>).
- <p>
-A distribution comprises Debian source and binary packages, and the
-respective <file>Sources</file> and <file>Packages</file> index files,
-containing the header information from all those packages. The former are
-kept in the <file>pool/</file> directory, while the latter are kept in the
-<file>dists/</file> directory of the archive (for backwards
-compatibility).
-
-
- <sect2 id="sec-dists">Stable, testing, and unstable
- <p>
-There are always distributions called <em>stable</em> (residing in
-<file>dists/stable</file>), <em>testing</em> (residing in
-<file>dists/testing</file>), and <em>unstable</em> (residing in
-<file>dists/unstable</file>). This reflects the development process of the
-Debian project.
- <p>
-Active development is done in the <em>unstable</em> distribution
-(that's why this distribution is sometimes called the <em>development
-distribution</em>). Every Debian developer can update his or her
-packages in this distribution at any time. Thus, the contents of this
-distribution change from day to day. Since no special effort is made
-to make sure everything in this distribution is working properly, it is
-sometimes literally unstable.
- <p>
-The <qref id="testing">"testing"</qref> distribution 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. See <ref id="testing">.
- <p>
-After a period of development, once the release manager deems fit, the
-<em>testing</em> distribution is frozen, meaning that the policies
-which control how packages move from <em>unstable</em> to <em>testing</em>
-are tightened. Packages which are too buggy are removed. No changes are
-allowed into <em>testing</em> except for bug fixes. After some time has
-elapsed, depending on progress, the <em>testing</em> distribution is
-frozen even further. Details of the handling of the testing distribution
-are published by the Release Team on debian-devel-announce. After the
-open issues are solved to the satisfaction of the Release Team, the
-distribution is released. Releasing means that <em>testing</em> is
-renamed to <em>stable</em>, and a new copy is created for the new
-<em>testing</em>, and the previous <em>stable</em> is renamed to
-<em>oldstable</em> and stays there until it is finally archived. On
-archiving, the contents are moved to <tt>&archive-host;</tt>).
- <p>
-This development cycle is based on the assumption that the
-<em>unstable</em> distribution becomes <em>stable</em> after passing a
-period of being in <em>testing</em>. Even once a distribution is
-considered stable, a few bugs inevitably remain — that's why the
-stable distribution is updated every now and then. However, these
-updates are tested very carefully and have to be introduced into the
-archive individually to reduce the risk of introducing new bugs. You
-can find proposed additions to <em>stable</em> in the
-<file>proposed-updates</file> directory. Those packages in
-<file>proposed-updates</file> that pass muster are periodically moved as a
-batch into the stable distribution and the revision level of the
-stable distribution is incremented (e.g., ‘3.0’ becomes
-‘3.0r1’, ‘2.2r4’ becomes ‘2.2r5’, and
-so forth).
-Please refer to
-<qref id="upload-stable">uploads to the <em>stable</em> distribution</qref>
-for details.
- <p>
-Note that development under <em>unstable</em> continues during the
-freeze period, since the <em>unstable</em> distribution remains in
-place in parallel with <em>testing</em>.
-
- <sect2>
- <heading>More information about the testing distribution</heading>
- <p>
-Packages are usually installed into the `testing' distribution after they
-have undergone some degree of testing in unstable.
- <p>
-For more details, please see the <qref id="testing">information about the
-testing distribution</qref>.
-
- <sect2 id="experimental">Experimental
- <p>
-The <em>experimental</em> distribution is a special distribution.
-It is not a full distribution in the same sense as `stable' and
-`unstable' are. Instead, it is meant to be a temporary staging area
-for highly experimental software where there's a good chance that the
-software could break your system, or software that's just too unstable
-even for the <em>unstable</em> distribution (but there is a reason to
-package it nevertheless). Users who download and install
-packages from <em>experimental</em> are expected to have been duly
-warned. In short, all bets are off for the <em>experimental</em>
-distribution.
- <p>
-These are the <manref name="sources.list" section="5"> lines for
-<em>experimental</em>:
-<example>
-deb http://ftp.<var>xy</var>.debian.org/debian/ experimental main
-deb-src http://ftp.<var>xy</var>.debian.org/debian/ experimental main
-</example>
- <p>
-If there is a chance that the software could do grave damage to a system,
-it is likely to be better to put it into <em>experimental</em>.
-For instance, an experimental compressed file system should probably go
-into <em>experimental</em>.
- <p>
-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 <em>experimental</em>. A new, beta, version of some software
-which uses a completely different configuration can go into
-<em>experimental</em>, at the maintainer's discretion. If you are working
-on an incompatible or complex upgrade situation, you can also use
-<em>experimental</em> as a staging area, so that testers can get early
-access.
- <p>
-Some experimental software can still go into <em>unstable</em>, with a few
-warnings in the description, but that isn't recommended because packages
-from <em>unstable</em> are expected to propagate to <em>testing</em> and
-thus to <em>stable</em>. You should not be afraid to use
-<em>experimental</em> since it does not cause any pain to the ftpmasters,
-the experimental packages are automatically removed once you upload
-the package in <em>unstable</em> with a higher version number.
- <p>
-New software which isn't likely to damage your system can go directly into
-<em>unstable</em>.
- <p>
-An alternative to <em>experimental</em> is to use your personal web space
-on <tt>people.debian.org</tt>.
- <p>
-When uploading to unstable a package which had bugs fixed in experimental,
-please consider using the option <tt>-v</tt> to
-<prgn>dpkg-buildpackage</prgn> to finally get them closed.
-
- <sect1 id="codenames">Release code names
- <p>
-Every released Debian distribution has a <em>code name</em>: Debian
-1.1 is called `buzz'; Debian 1.2, `rex'; Debian 1.3, `bo'; Debian 2.0,
-`hamm'; Debian 2.1, `slink'; Debian 2.2, `potato'; Debian 3.0, `woody';
-Debian 3.1, "sarge";
-Debian 4.0, "etch".
-There is also a ``pseudo-distribution'', called `sid', which is the current
-`unstable' distribution; since packages are moved from `unstable' to
-`testing' as they approach stability, `sid' itself is never released.
-As well as the usual contents of a Debian distribution, `sid' contains
-packages for architectures which are not yet officially supported or
-released by Debian. These architectures are planned to be integrated
-into the mainstream distribution at some future date.
- <p>
-Since Debian has an open development model (i.e., everyone can
-participate and follow the development) even the `unstable' and `testing'
-distributions are distributed to the Internet through the Debian FTP and
-HTTP server network. Thus, if we had called the directory which contains
-the release candidate version `testing', then we would have to rename it
-to `stable' when the version is released, which would cause all FTP
-mirrors to re-retrieve the whole distribution (which is quite large).
- <p>
-On the other hand, if we called the distribution directories
-<em>Debian-x.y</em> from the beginning, people would think that Debian
-release <em>x.y</em> is available. (This happened in the past, where a
-CD-ROM vendor built a Debian 1.0 CD-ROM based on a pre-1.0 development
-version. That's the reason why the first official Debian release was
-1.1, and not 1.0.)
- <p>
-Thus, the names of the distribution directories in the archive are
-determined by their code names and not their release status (e.g.,
-`slink'). These names stay the same during the development period and
-after the release; symbolic links, which can be changed easily,
-indicate the currently released stable distribution. That's why the
-real distribution directories use the <em>code names</em>, while
-symbolic links for <em>stable</em>, <em>testing</em>, and
-<em>unstable</em> point to the appropriate release directories.
-
-
- <sect id="mirrors">Debian mirrors
- <p>
-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 — 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.
-Note that the first tier of mirrors is as up-to-date as it can be since
-they update when triggered from the internal sites (we call this
-"push mirroring").
- <p>
-All the information on Debian mirrors, including a list of the available
-public FTP/HTTP servers, can be found at <url id="&url-debian-mirrors;">.
-This useful page also includes information and tools which can be helpful if
-you are interested in setting up your own mirror, either for internal or
-public access.
- <p>
-Note that mirrors are generally run by third-parties who are
-interested in helping Debian. As such, developers generally do not
-have accounts on these machines.
-
-
- <sect id="incoming-system">
- <heading>The Incoming system
- <p>
-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 on <tt>&ftp-master-host;</tt>.
- <p>
-Packages are uploaded by all the maintainers into a directory called
-<file>UploadQueue</file>.
-This directory is scanned every few minutes by a daemon called
-<prgn>queued</prgn>, <file>*.command</file>-files are executed, and
-remaining and correctly signed <file>*.changes</file>-files are moved
-together with their corresponding files to the <file>unchecked</file>
-directory.
-This directory is not visible for most Developers, as ftp-master is
-restricted; it is scanned every 15 minutes by the <prgn>katie</prgn>
-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 <file>accepted</file> directory. If this
-is the first upload of the package (or it has new binary packages), it is
-moved to the <file>new</file> directory, where it waits for approval by
-the ftpmasters. If the package contains files to be installed "by hand"
-it is moved to the <file>byhand</file> directory, where it waits for
-manual installation by the ftpmasters. Otherwise, if any error has been
-detected, the package is refused and is moved to the <file>reject</file>
-directory.
- <p>
-Once the package is accepted, the system sends a confirmation
-mail to the maintainer and closes all the bugs marked as fixed by the upload,
-and the auto-builders may start recompiling it. The package is now publicly
-accessible at <url id="&url-incoming;">
-until it is really installed
-in the Debian archive.
-This happens only once a day
-(and is also called the `dinstall run' for historical reasons);
-the package
-is then removed from incoming and installed in the pool along with all
-the other packages. Once all the other updates (generating new
-<file>Packages</file> and <file>Sources</file> index files for example)
-have been made, a special script is called to ask all the primary mirrors
-to update themselves.
- <p>
-The archive maintenance software will also send the OpenPGP/GnuPG signed
-<file>.changes</file> file that you uploaded to the appropriate mailing
-lists. If a package is released with the <tt>Distribution:</tt> set to
-`stable', the announcement is sent to &email-debian-changes;.
-If a package is released with <tt>Distribution:</tt> set to `unstable'
-or `experimental', the announcement will be posted to
-&email-debian-devel-changes; instead.
- <p>
-Though ftp-master is restricted, a copy of the installation is available
-to all developers on <tt>&ftp-master-mirror;</tt>.
-<!-- FIXME: delete it or keep it for historical purposes?
- <p>
-All Debian developers have write access to the <file>unchecked</file>
-directory in order to upload their packages; they also have that access
-to the <file>reject</file> directory in order to remove their bad uploads
-or to move some files back to the <file>unchecked</file> directory. But
-all the other directories are only writable by the ftpmasters, which is
-why you cannot remove an upload once it has been accepted.
-
- <sect1 id="delayed-incoming-broken">Delayed incoming
- <p>
-<em>Note:</em> This description here is currently not working, because
-ftp-master is restricted. Please see <ref id="delayed-incoming"> for
-the currently working way.
- <p>
-The <file>unchecked</file> directory has a special <file>DELAYED</file>
-subdirectory. It is itself subdivided in nine directories
-called <file>1-day</file> to <file>9-day</file>. Packages which are
-uploaded to one of those directories will be moved to the real unchecked
-directory after the corresponding number of days.
-This is done by a script which is run each day and which moves the
-packages between the directories. Those which are in "1-day" are
-installed in <file>unchecked</file> while the others are moved to the
-adjacent directory (for example, a package in <file>5-day</file> will
-be moved to <file>4-day</file>). This feature is particularly useful
-for people who are doing non-maintainer uploads. Instead of
-waiting before uploading a NMU, it is uploaded as soon as it is
-ready, but to one of those <file>DELAYED/<var>x</var>-day</file> directories.
-That leaves the corresponding number of days for the maintainer
-to react and upload another fix themselves if they are not
-completely satisfied with the NMU. Alternatively they can remove
-the NMU.
- <p>
-The use of that delayed feature can be simplified with a bit
-of integration with your upload tool. For instance, if you use
-<prgn>dupload</prgn> (see <ref id="dupload">), you can add this
-snippet to your configuration file:
-<example>
-$delay = ($ENV{DELAY} || 7);
-$cfg{'delayed'} = {
- fqdn => "&ftp-master-host;",
- login => "yourdebianlogin",
- incoming => "/org/ftp.debian.org/incoming/DELAYED/$delay-day/",
- dinstall_runs => 1,
- method => "scpb"
-};
-</example>
-Once you've made that change, <prgn>dupload</prgn> can be used to
-easily upload a package in one of the delayed directories:
-<example>DELAY=5 dupload -X-to delayed <changes-file></example>
--->
-
-
- <sect id="pkg-info">Package information
- <p>
-
- <sect1 id="pkg-info-web">On the web
- <p>
-Each package has several dedicated web pages.
-<tt>http://&packages-host;/<var>package-name</var></tt>
-displays each version of the package
-available in the various distributions. Each version links to a page
-which provides information, including the package description,
-the dependencies, and package download links.
- <p>
-The bug tracking system tracks bugs for each package.
-You can view the bugs of a given package at the URL
-<tt>http://&bugs-host;/<var>package-name</var></tt>.
-
- <sect1 id="madison">The <prgn>madison</prgn> utility
- <p>
-<prgn>madison</prgn> is a command-line utility that is available
-on <tt>&ftp-master-host;</tt>, and on
-the mirror on <tt>&ftp-master-mirror;</tt>. It
-uses a single argument corresponding to a package name. In result
-it displays which version of the package is available for each
-architecture and distribution combination. An example will explain
-it better.
- <p>
-<example>
-$ madison libdbd-mysql-perl
-libdbd-mysql-perl | 1.2202-4 | stable | source, alpha, arm, i386, m68k, powerpc, sparc
-libdbd-mysql-perl | 1.2216-2 | testing | source, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
-libdbd-mysql-perl | 1.2216-2.0.1 | testing | alpha
-libdbd-mysql-perl | 1.2219-1 | unstable | source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
-</example>
- <p>
-In this example, you can see that the version in <em>unstable</em> differs
-from the version in <em>testing</em> and that there has been a binary-only
-NMU of the package for the alpha architecture. Each version of the package
-has been recompiled on most of the architectures.
-
- <sect id="pkg-tracking-system">The Package Tracking System
- <p>
-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.
- <p>
-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.
- <p>
-By default you will get:
-<taglist>
- <tag><tt>bts</tt>
- <item>
-All the bug reports and following discussions.
-
- <tag><tt>bts-control</tt>
- <item>
-The email notifications from <email>control@bugs.debian.org</email>
-about bug report status changes.
-
- <tag><tt>upload-source</tt>
- <item>
-The email notification from <prgn>katie</prgn> when an uploaded source
-package is accepted.
-
- <tag><tt>katie-other</tt>
- <item>
-Other warning and error emails from <prgn>katie</prgn> (such as an
-override disparity for the section and/or the priority field).
-
- <tag><tt>default</tt>
- <item>
-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 <tt><var>sourcepackage</var>@&pts-host;</tt>. In order to prevent spam,
-all messages sent to these addresses must contain the <tt>X-PTS-Approved</tt>
-header with a non-empty value.
-
- <tag><tt>contact</tt>
- <item>
-Mails sent to the maintainer through the *@packages.debian.org email
-aliases.
-
- <tag><tt>summary</tt>
- <item>
-Regular summary emails about the package's status.
-Currently, only progression in <em>testing</em> is sent.
-
-</taglist>
-
- <p>
-You can also decide to receive additional information:
-<taglist>
- <tag><tt>upload-binary</tt>
- <item>
-The email notification from <prgn>katie</prgn> 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.
-
- <tag><tt>cvs</tt>
- <item>
-VCS commit notifications, if the package has a VCS repository and the
-maintainer has set up forwarding of commit notifications to the PTS. The
-"cvs" name is historic, in most cases commit notifications will come
-from some other VCS like subversion or git.
-
- <tag><tt>ddtp</tt>
- <item>
-Translations of descriptions or debconf templates
-submitted to the Debian Description Translation Project.
-
- <tag><tt>derivatives</tt>
- <item>
-Information about changes made to the package in derivative distributions
-(for example Ubuntu).
-</taglist>
-
- <sect1 id="pts-commands">The PTS email interface
- <p>
-You can control your subscription(s) to the PTS by sending
-various commands to <email>pts@qa.debian.org</email>.
-
-<taglist>
-
-<tag><tt>subscribe <sourcepackage> [<email>]</tt>
-<item>
- Subscribes <var>email</var> to communications related to the source package
- <var>sourcepackage</var>. Sender address is used if the second argument is
- not present. If <var>sourcepackage</var> 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.
-
-<tag><tt>unsubscribe <sourcepackage> [<email>]</tt>
-<item>
- Removes a previous subscription to the source package
- <var>sourcepackage</var> using the specified email address or the sender
- address if the second argument is left out.
-
-<tag><tt>unsubscribeall [<email>]</tt>
-<item>
- Removes all subscriptions of the specified email address or the sender
- address if the second argument is left out.
-
-<tag><tt>which [<email>]</tt>
-<item>
- Lists all subscriptions for the sender or the email address optionally
- specified.
-
-<tag><tt>keyword [<email>]</tt>
-<item>
- Tells you the keywords that you are accepting.
- For an explanation of keywords, <qref id="pkg-tracking-system">see
- above</qref>. Here's a quick summary:
- <list>
- <item><tt>bts</tt>: mails coming from the Debian Bug Tracking System
- <item><tt>bts-control</tt>: reply to mails sent to &email-bts-control;
- <item><tt>summary</tt>: automatic summary mails about the state of a
- package
- <item><tt>contact</tt>: mails sent to the maintainer through the
- *@packages.debian.org aliases
- <item><tt>cvs</tt>: notification of VCS commits
- <item><tt>ddtp</tt>: translations of descriptions and debconf templates
- <item><tt>derivatives</tt>: changes made on the package by derivative
- distributions
- <item><tt>upload-source</tt>: announce of a new source upload that
- has been accepted
- <item><tt>upload-binary</tt>: announce of a new binary-only upload
- (porting)
- <item><tt>katie-other</tt>: other mails from ftpmasters
- (override disparity, etc.)
- <item><tt>default</tt>: all the other mails (those which aren't
- "automatic")
-</list>
-
-<tag><tt>keyword <sourcepackage> [<email>]</tt>
-<item>
- Same as the previous item but for the given source package, since
- you may select a different set of keywords for each source package.
-
-<tag><tt>keyword [<email>] {+|-|=} <list of keywords></tt>
-<item>
- Accept (+) or refuse (-) mails classified under the given keyword(s).
- Define the list (=) of accepted keywords. This changes the default set
- of keywords accepted by a user.
-
-<tag><tt>keywordall [<email>] {+|-|=} <list of keywords></tt>
-<item>
- Accept (+) or refuse (-) mails classified under the given keyword(s).
- Define the list (=) of accepted keywords. This changes the set of
- accepted keywords of all the currently active subscriptions of a user.
-
-<tag><tt>keyword <sourcepackage> [<email>] {+|-|=} <list of keywords></tt>
-<item>
- Same as previous item but overrides the keywords list for the
- indicated source package.
-
-<tag><tt>quit | thanks | --</tt>
-<item>
- Stops processing commands. All following lines are ignored by
- the bot.
-</taglist>
-
- <p>
-The <prgn>pts-subscribe</prgn> command-line utility (from the
-<package>devscripts</package> package) can be handy to temporarily
-subscribe to some packages, for example after having made an
-non-maintainer upload.
-
- <sect1 id="pts-mail-filtering">Filtering PTS mails
- <p>
-Once you are subscribed to a package, you will get the mails sent to
-<tt><var>sourcepackage</var>@packages.qa.debian.org</tt>. Those mails
-have special headers appended to let you filter them in a special
-mailbox (e.g. with <prgn>procmail</prgn>). The added headers are
-<tt>X-Loop</tt>, <tt>X-PTS-Package</tt>, <tt>X-PTS-Keyword</tt> and
-<tt>X-Unsubscribe</tt>.
- <p>
-Here is an example of added headers for a source upload notification
-on the <package>dpkg</package> package:
-<example>
-X-Loop: dpkg@&pts-host;
-X-PTS-Package: dpkg
-X-PTS-Keyword: upload-source
-List-Unsubscribe: <mailto:pts@qa.debian.org?body=unsubscribe+dpkg>
-</example>
-
- <sect1 id="pts-vcs-commit">Forwarding VCS commits in the PTS
- <p>
-If you use a publicly accessible VCS repository for maintaining
-your Debian package, you may want to forward the commit notification
-to the PTS so that the subscribers (and possible co-maintainers) can
-closely follow the package's evolution.
- <p>
-Once you set up the VCS repository to generate commit notifications,
-you just have to make sure it sends a copy of those mails
-to <tt><var>sourcepackage</var>_cvs@&pts-host;</tt>. Only the people
-who accept the <em>cvs</em> keyword will receive these notifications.
-Note that the mail need to be sent from a <tt>debian.org</tt> machine,
-otherwise you'll have to add the <tt>X-PTS-Approved: 1</tt> header.
- <p>
-For Subversion repositories, the usage of svnmailer is recommended.
-See <url id="&url-alioth-pkg;"> for an example on how to do it.
-
- <sect1 id="pts-web">The PTS web interface
- <p>
-The PTS has a web interface at <url id="http://&pts-host;/"> 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 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 allows easy subscription to
-the PTS via email.
- <p>
-You can jump directly to the web page concerning a specific source package
-with a URL like <tt>http://&pts-host;/<var>sourcepackage</var></tt>.
- <p>
-This web interface has been designed like a portal for the development of
-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.
- <p>
-Static news items can be used to indicate:
-<list>
-<item>the availability of a project hosted on <qref
-id="alioth">Alioth</qref> for co-maintaining the package
-<item>a link to the upstream web site
-<item>a link to the upstream bug tracker
-<item>the existence of an IRC channel dedicated to the software
-<item>any other available resource that could be useful in the maintenance
-of the package
-</list>
-Usual news items may be used to announce that:
-<list>
-<item>beta packages are available for testing
-<item>final packages are expected for next week
-<item>the packaging is about to be redone from scratch
-<item>backports are available
-<item>the maintainer is on vacation (if they wish to publish this
- information)
-<item>a NMU is being worked on
-<item>something important will affect the package
-</list>
- <p>
-Both kinds of news are generated in a similar manner: you just have to send
-an email either to <email>pts-static-news@qa.debian.org</email> or to
-<email>pts-news@qa.debian.org</email>. The mail should indicate which
-package is concerned by having the name of the source package in a
-<tt>X-PTS-Package</tt> mail header or in a <tt>Package</tt> pseudo-header
-(like the BTS reports). If a URL is available in the <tt>X-PTS-Url</tt>
-mail header or in the <tt>Url</tt> pseudo-header, then the result is a
-link to that URL instead of a complete news item.
- <p>
-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:
-<example>
-From: Raphael Hertzog <hertzog@debian.org>
-To: pts-static-news@qa.debian.org
-Subject: Browse debian-cd CVS repository with cvsweb
-
-Package: debian-cd
-Url: http://cvs.debian.org/debian-cd/
-</example>
- <p>
-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.
-<example>
-From: Raphael Hertzog <hertzog@debian.org>
-To: debian-gtk-gnome@lists.debian.org
-Bcc: pts-news@qa.debian.org
-Subject: Galeon 2.0 backported for woody
-X-PTS-Package: galeon
-
-Hello gnomers!
-
-I'm glad to announce that galeon has been backported for woody. You'll find
-everything here:
-...
-</example>
- <p>
-Think twice before adding a news item to the PTS because you won't be able
-to remove it later and you won'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.
-
- <sect id="ddpo">Developer's packages overview
- <p>
-A QA (quality assurance) web portal is available at <url
- id="&url-ddpo;"> which displays a table listing all the packages
-of a single developer (including those where the party is listed as
-a co-maintainer). The table gives a good summary about the developer's
-packages: number of bugs by severity, list of available versions in each
-distribution, testing status and much more including links to any other
-useful information.
- <p>
-It is a good idea to look up your own data regularly so that
-you don't forget any open bugs, and so that you don't forget which
-packages are your responsibility.
-
- <sect id="alioth">Debian's GForge installation: Alioth
- <p>
-Alioth is a 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.
- <p>
-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. It's heavily used by many Debian teams and provides
-hosting for all sorts of VCS repositories.
- <p>
-All Debian developers automatically have an account on Alioth.
-They can activate it by using the recover password facility.
-External developers can request guest accounts on Alioth.
- <p>
-For more information please visit the following links:
-<list>
-<item><url id="&url-alioth-wiki;">
-<item><url id="&url-alioth-faq;">
-<item><url id="&url-alioth-pkg;">
-<item><url id="&url-alioth;">
-</list>
-
- <sect id="developer-misc">Goodies for Developers
- <p>
- <sect1 id="lwn">LWN Subscriptions
- <p>
-Since October of 2002, HP has sponsored a subscription to LWN for all
-interested Debian developers.
-
-Details on how to get access to this benefit are in
-<url id="http://lists.debian.org/debian-devel-announce/2002/10/msg00018.html">.
-
-
-
- <chapt id="pkgs">Managing Packages
- <p>
-This chapter contains information related to creating, uploading,
-maintaining, and porting packages.
-
-
- <sect id="newpackage">New packages
- <p>
-If you want to create a new package for the Debian distribution, you
-should first check the <url id="&url-wnpp;" name="Work-Needing and
-Prospective Packages (WNPP)"> list. Checking the WNPP list ensures that
-no one is already working on packaging that software, and that effort is
-not duplicated. Read the <url id="&url-wnpp;" name="WNPP web pages"> for
-more information.
- <p>
-Assuming no one else is already working on your prospective package,
-you must then submit a bug report (<ref id="submit-bug">) against the
-pseudo-package <package>wnpp</package>
-describing your plan to create a new package, including, but not
-limiting yourself to, a description of the package, the license of the
-prospective package, and the current URL where it can be downloaded
-from.
- <p>
-You should set the subject of the bug to ``ITP: <var>foo</var>
--- <var>short description</var>'', substituting the name of the new
-package for <var>foo</var>. The severity of the bug report must be set
-to <em>wishlist</em>. If you feel it's necessary, send a copy to
-&email-debian-devel; by putting the address in the <tt>X-Debbugs-CC:</tt>
-header of the message (no, don't use <tt>CC:</tt>, because that way the
-message's subject won't indicate the bug number).
- <p>
-Please include a <tt>Closes: bug#<var>nnnnn</var></tt> entry in the
-changelog of the new package in order for the bug report to be
-automatically closed once the new package is installed in the archive
-(see <ref id="upload-bugfix">).
- <p>
-When closing security bugs include CVE numbers as well as the
-"Closes: #nnnnn".
-This is useful for the security team to track vulnerabilities.
-If an upload is made to fix the bug before the advisory ID is known,
-it is encouraged to modify the historical changelog entry with the next
-upload. Even in this case, please include all available pointers to
-background information in the original changelog entry.
-
- <p>
-There are a number of reasons why we ask maintainers to announce their
-intentions:
- <list compact>
- <item>
-It helps the (potentially new) maintainer to tap into the experience
-of people on the list, and lets them know if anyone else is working
-on it already.
- <item>
-It lets other people thinking about working on the package know that
-there already is a volunteer, so efforts may be shared.
- <item>
-It lets the rest of the maintainers know more about the package than
-the one line description and the usual changelog entry ``Initial release''
-that gets posted to <tt>debian-devel-changes</tt>.
- <item>
-It is helpful to the people who live off unstable (and form our first
-line of testers). We should encourage these people.
- <item>
-The announcements give maintainers and other interested parties a
-better feel of what is going on, and what is new, in the project.
- </list>
- <p>
-Please see <url id="http://ftp-master.debian.org/REJECT-FAQ.html">
-for common rejection reasons for a new package.
-
- <sect id="changelog-entries">Recording changes in the package
- <p>
-Changes that you make to the package need to be recorded in the
-<file>debian/changelog</file>. These changes should provide a concise
-description of what was changed, why (if it's in doubt), and note if
-any bugs were closed. They also record when the package was
-completed. This file will be installed in
-<file>/usr/share/doc/<var>package</var>/changelog.Debian.gz</file>, or
-<file>/usr/share/doc/<var>package</var>/changelog.gz</file> for native
-packages.
- <p>
-The <file>debian/changelog</file> file conforms to a certain structure,
-with a number of different fields. One field of note, the
-<em>distribution</em>, is described in <ref id="distribution">. More
-information about the structure of this file can be found in
-the Debian Policy section titled "<file>debian/changelog</file>".
- <p>
-Changelog entries can be used to automatically close Debian bugs when
-the package is installed into the archive. See <ref
-id="upload-bugfix">.
- <p>
-It is conventional that the changelog entry of a package that
-contains a new upstream version of the software looks like this:
-<example>
- * new upstream version
-</example>
- <p>
-There are tools to help you create entries and finalize the
-<file>changelog</file> for release — see <ref id="devscripts">
-and <ref id="dpkg-dev-el">.
- <p>
-See also <ref id="bpp-debian-changelog">.
-
-
- <sect id="sanitycheck">Testing the package
- <p>
-Before you upload your package, you should do basic testing on it. At
-a minimum, you should try the following activities (you'll need to
-have an older version of the same Debian package around):
-<list>
- <item>
-Install the package and make sure the software works, or upgrade the
-package from an older version to your new version if a Debian package
-for it already exists.
- <item>
-Run <prgn>lintian</prgn> over the package. You can run
-<prgn>lintian</prgn> as follows: <tt>lintian -v
-<var>package-version</var>.changes</tt>. This will check the source
-package as well as the binary package. If you don't understand the
-output that <prgn>lintian</prgn> generates, try adding the <tt>-i</tt>
-switch, which will cause <prgn>lintian</prgn> to output a very verbose
-description of the problem.
- <p>
-Normally, a package should <em>not</em> be uploaded if it causes lintian
-to emit errors (they will start with <tt>E</tt>).
- <p>
-For more information on <prgn>lintian</prgn>, see <ref id="lintian">.
- <item>
-Optionally run <ref id="debdiff"> to analyze changes from an older version,
-if one exists.
- <item>
-Downgrade the package to the previous version (if one exists) — this
-tests the <file>postrm</file> and <file>prerm</file> scripts.
- <item>
-Remove the package, then reinstall it.
- <item>
-Copy the source package in a different directory and try unpacking it and
-rebuilding it. This tests if the package relies on existing files outside of
-it, or if it relies on permissions being preserved on the files shipped
-inside the .diff.gz file.
- </list>
-
-
- <sect id="sourcelayout">Layout of the source package
- <p>
-There are two types of Debian source packages:
- <list>
- <item>the so-called <em>native</em> packages, where there is no
- distinction between the original sources and the patches
- applied for Debian
- <item>the (more common) packages where there's an original source
- tarball file accompanied by another file that contains the
- patches applied for Debian
- </list>
- <p>
-For the native packages, the source package includes a Debian source control
-file (<tt>.dsc</tt>) and the source tarball (<tt>.tar.gz</tt>). A source
-package of a non-native package includes a Debian source control file, the
-original source tarball (<tt>.orig.tar.gz</tt>) and the Debian patches
-(<tt>.diff.gz</tt>).
- <p>
-Whether a package is native or not is determined when it is built by
-<manref name="dpkg-buildpackage" section="1">. The rest of this section
-relates only to non-native packages.
- <p>
-The first time a version is uploaded which corresponds to a particular
-upstream version, the original source tar file should be uploaded and
-included in the <file>.changes</file> file. Subsequently, this very same
-tar file should be used to build the new diffs and <file>.dsc</file>
-files, and will not need to be re-uploaded.
- <p>
-By default, <prgn>dpkg-genchanges</prgn> and
-<prgn>dpkg-buildpackage</prgn> will include the original source tar
-file if and only if the Debian revision part of the source version
-number is 0 or 1, indicating a new upstream version. This behavior
-may be modified by using <tt>-sa</tt> to always include it or
-<tt>-sd</tt> to always leave it out.
- <p>
-If no original source is included in the upload, the original
-source tar-file used by <prgn>dpkg-source</prgn> when constructing the
-<file>.dsc</file> file and diff to be uploaded <em>must</em> be
-byte-for-byte identical with the one already in the archive.
- <p>
-Please notice that, in non-native packages, permissions on files that are
-not present in the .orig.tar.gz will not be preserved, as diff does not
-store file permissions in the patch.
-
-
- <sect id="distribution">Picking a distribution
- <p>
-Each upload needs to specify which distribution the package is intended
-for. The package build process extracts this information from the first
-line of the <file>debian/changelog</file> file and places it in the
-<tt>Distribution</tt> field of the <tt>.changes</tt> file.
- <p>
-There are several possible values for this field: `stable', `unstable',
-`testing-proposed-updates' and `experimental'. Normally, packages are
-uploaded into <em>unstable</em>.
- <p>
-Actually, there are two other possible distributions: `stable-security' and
-`testing-security', but read <ref id="bug-security"> for more information on
-those.
- <p>
-It is not possible to upload a package into several distributions
-at the same time.
-
- <sect1 id="upload-stable">
- <heading>Special case: uploads to the <em>stable</em> distribution</heading>
- <p>
-Uploading to <em>stable</em> means that the package will transfered to the
-<em>p-u-new</em>-queue for review by the stable release managers, and
-if approved will be installed in
-<file>stable-proposed-updates</file> directory of the Debian archive.
-From there, it will be included in <em>stable</em> with the next point
-release.
- <p>
-Extra care should be taken when uploading to <em>stable</em>. Basically, a
-package should only be uploaded to stable if one of the following happens:
-<list>
- <item>a truly critical functionality problem
- <item>the package becomes uninstallable
- <item>a released architecture lacks the package
-</list>
-<p>
-In the past, uploads to <em>stable</em> were used to address security
-problems as well. However, this practice is deprecated, as uploads
-used for Debian security advisories are automatically copied to the
-appropriate <file>proposed-updates</file> archive when the advisory is
-released. See <ref id="bug-security"> for detailed information on
-handling security problems.
- <p>
-Changing anything else in the package that isn't important is discouraged,
-because even trivial fixes can cause bugs later on.
- <p>
-Packages uploaded to <em>stable</em> need to be compiled on systems running
-<em>stable</em>, so that their dependencies are limited to the libraries
-(and other packages) available in <em>stable</em>; for example, a package
-uploaded to <em>stable</em> that depends on a library package that only
-exists in unstable will be rejected. Making changes to dependencies of other
-packages (by messing with <tt>Provides</tt> or shlibs files), possibly making
-those other packages uninstallable, is strongly discouraged.
- <p>
-The Release Team (which can be reached at &email-debian-release;) will
-regularly evaluate the uploads To <em>stable-proposed-updates</em> and
-decide if your package can be included in <em>stable</em>. Please be clear
-(and verbose, if necessary) in your changelog entries for uploads to
-<em>stable</em>, because otherwise the package won't be considered for
-inclusion.
- <p>
-It's best practice to speak with the stable release manager <em>before</em>
-uploading to <em>stable</em>/<em>stable-proposed-updates</em>, so that the
-uploaded package fits the needs of the next point release.
-
- <sect1 id="upload-t-p-u">
- <heading>Special case: uploads to <em>testing/testing-proposed-updates</em></heading>
- <p>
-Please see the information in the <qref id="t-p-u">testing section</qref>
-for details.
-
-
- <sect id="upload">Uploading a package
-
- <sect1 id="upload-ftp-master">Uploading to <tt>ftp-master</tt>
- <p>
-To upload a package, you should upload the files (including the signed
-changes and dsc-file) with anonymous ftp to
-<ftpsite>&ftp-master-host;</ftpsite> in the directory &upload-queue;.
-To get the files processed there, they need to be signed with a key in the
-debian keyring.
- <p>
-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
-all files have been uploaded.
- <p>
-You may also find the Debian packages <ref id="dupload"> or
-<ref id="dput"> useful
-when uploading packages. These handy programs help automate the
-process of uploading packages into Debian.
- <p>
-For removing packages, please see the README file in that ftp directory,
-and the Debian package <ref id="dcut">.
-
- <sect1 id="delayed-incoming">Delayed uploads
- <p>
-Delayed uploads are done for the moment via the delayed queue at
-gluck. The upload-directory is
-<ftpsite>gluck:~tfheen/DELAYED/[012345678]-day</ftpsite>.
-0-day is uploaded multiple times per day to ftp-master.
- <p>
-With a fairly recent dput, this section
-<example>
-[tfheen_delayed]
-method = scp
-fqdn = gluck.debian.org
-incoming = ~tfheen
-</example>
-in ~/.dput.cf should work fine for uploading to the DELAYED queue.
- <p>
-<em>Note:</em>
-Since this upload queue goes to <tt>ftp-master</tt>, the
-prescription found in <ref id="upload-ftp-master"> applies here as well.
-
- <sect1>Security uploads
- <p>
-Do <strong>NOT</strong> 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.
-For details, please see section <ref id="bug-security">.
-
- <sect1>Other upload queues
- <p>
-The scp queues on ftp-master, and security are mostly unusable
-due to the login restrictions on those hosts.
- <p>
-The anonymous queues on ftp.uni-erlangen.de and ftp.uk.debian.org are
-currently down. Work is underway to resurrect them.
- <p>
-The queues on master.debian.org, samosa.debian.org, master.debian.or.jp,
-and ftp.chiark.greenend.org.uk are down permanently, and will not be
-resurrected. The queue in Japan will be replaced with a new queue on
-hp.debian.or.jp some day.
- <p>
-For the time being, the anonymous ftp queue on auric.debian.org (the
-former ftp-master) works, but it is deprecated and will be removed at
-some point in the future.
-
- <sect1 id="upload-notification">
- <heading>Notification that a new package has been installed</heading>
- <p>
-The Debian archive maintainers are responsible for handling package
-uploads. For the most part, uploads are automatically handled on a
-daily basis by the archive maintenance tools, <prgn>katie</prgn>.
-Specifically, updates to existing packages to
-the `unstable' distribution are handled automatically. In other cases,
-notably new packages, placing the uploaded package into the
-distribution is handled manually. When uploads are handled manually,
-the change to the archive may take up to a month to occur. Please be
-patient.
- <p>
-In any case, you will receive an email notification indicating that the
-package has been added to the archive, which also indicates which bugs will
-be closed by the upload. Please examine this notification carefully,
-checking if any bugs you meant to close didn't get triggered.
- <p>
-The installation notification also includes information on what
-section the package was inserted into. If there is a disparity, you
-will receive a separate email notifying you of that. Read on below.
- <p>
-Note that if you upload via queues, the queue daemon software will
-also send you a notification by email.
-
- <sect id="override-file">Specifying the package section, subsection and priority
- <p>
-The <file>debian/control</file> file's <tt>Section</tt> and
-<tt>Priority</tt> fields do not actually specify where the file will
-be placed in the archive, nor its priority. In order to retain the
-overall integrity of the archive, it is the archive maintainers who
-have control over these fields. The values in the
-<file>debian/control</file> file are actually just hints.
- <p>
-The archive maintainers keep track of the canonical sections and
-priorities for packages in the <em>override file</em>. If there is a
-disparity between the <em>override file</em> and the package's fields
-as indicated in <file>debian/control</file>, then you will receive an
-email noting the divergence when the package is installed into the
-archive. You can either correct your <file>debian/control</file> file
-for your next upload, or else you may wish to make a change in the
-<em>override file</em>.
- <p>
-To alter the actual section that a package is put in, you need to
-first make sure that the <file>debian/control</file> file in your package
-is accurate. Next, send an email &email-override; or submit a bug
-against <package>ftp.debian.org</package> requesting that the section
-or priority for your package be changed from the old section or
-priority to the new one. Be sure to explain your reasoning.
- <p>
-For more information about <em>override files</em>, see <manref
-name="dpkg-scanpackages" section="1"> and
-<url id="&url-bts-devel;#maintincorrect">.
- <p>
-Note that the <tt>Section</tt> field describes both the section as
-well as the subsection, which are described in <ref
-id="archive-sections">. If the section is "main", it should be
-omitted. The list of allowable subsections can be found in <url
-id="&url-debian-policy;ch-archive.html#s-subsections">.
-
-
- <sect id="bug-handling">Handling bugs
- <p>
-Every developer has to be able to work with the Debian <url name="bug
-tracking system" id="&url-bts;">. This includes knowing how to file bug
-reports properly (see <ref id="submit-bug">), how to update them and
-reorder them, and how to process and close them.
- <p>
-The bug tracking system's features are described
-in the <url id="&url-bts-devel;" name="BTS documentation for developers">.
-This includes closing bugs, sending followup messages, assigning severities
-and tags, marking bugs as forwarded, and other issues.
- <p>
-Operations such as reassigning bugs to other packages, merging separate
-bug reports about the same issue, or reopening bugs when they are
-prematurely closed, are handled using the so-called control mail server.
-All of the commands available on this server are described in the
-<url id="&url-bts-control;" name="BTS control server documentation">.
-
- <sect1 id="bug-monitoring">Monitoring bugs
- <p>
-If you want to be a good maintainer, you should periodically check the
-<url id="&url-bts;" name="Debian bug tracking system (BTS)"> for your
-packages. The BTS contains all the open bugs against your packages.
-You can check them by browsing this page:
-<tt>http://&bugs-host;/<var>yourlogin</var>@debian.org</tt>.
- <p>
-Maintainers interact with the BTS via email addresses at
-<tt>&bugs-host;</tt>. Documentation on available commands can be
-found at <url id="&url-bts;">, or, if you have installed the
-<package>doc-debian</package> package, you can look at the local files
-&file-bts-docs;.
- <p>
-Some find it useful to get periodic reports on open bugs. You can add
-a cron job such as the following if you want to get a weekly email
-outlining all the open bugs against your packages:
-<example>
-# ask for weekly reports of bugs in my packages
-&cron-bug-report;
-</example>
-Replace <var>address</var> with your official Debian
-maintainer address.
-
- <sect1 id="bug-answering">Responding to bugs
- <p>
-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., <email>123@&bugs-host;</email>). If you're writing a new
-mail and you don't remember the submitter email address, you can
-use the <email>123-submitter@&bugs-host;</email> email to
-contact the submitter <em>and</em> to record your mail within the
-bug log (that means you don't need to send a copy of the mail to
-<email>123@&bugs-host;</email>).
- <p>
-If you get a bug which mentions "FTBFS", this means "Fails to build
-from source". Porters frequently use this acronym.
- <p>
-Once you've dealt with a bug report (e.g. fixed it), mark it as
-<em>done</em> (close it) by sending an explanation message to
-<email>123-done@&bugs-host;</email>. If you're fixing a bug by
-changing and uploading the package, you can automate bug closing as
-described in <ref id="upload-bugfix">.
- <p>
-You should <em>never</em> close bugs via the bug server <tt>close</tt>
-command sent to &email-bts-control;. If you do so, the original
-submitter will not receive any information about why the bug was
-closed.
-
- <sect1 id="bug-housekeeping">Bug housekeeping
- <p>
-As a package maintainer, you will often find bugs in other packages or
-have bugs reported against your packages which are actually bugs in
-other packages. The bug tracking system's features
-are described in the <url id="&url-bts-devel;" name="BTS documentation for
-Debian developers">. Operations such as reassigning, merging, and tagging
-bug reports are described in the <url id="&url-bts-control;" name="BTS
-control server documentation">. This section contains
-some guidelines for managing your own bugs, based on the collective
-Debian developer experience.
- <p>
-Filing bugs for problems that you find in other packages is one of
-the "civic obligations" of maintainership, see <ref id="submit-bug">
-for details. However, handling the bugs in your own packages is
-even more important.
- <p>
-Here's a list of steps that you may follow to handle a bug report:
-<enumlist>
- <item>
-Decide whether the report corresponds to a real bug or not. Sometimes
-users are just calling a program in the wrong way because they haven't
-read the documentation. If you diagnose this, just close the bug with
-enough information to let the user correct their problem (give pointers
-to the good documentation and so on). If the same report comes up
-again and again you may ask yourself if the documentation is good
-enough or if the program shouldn't detect its misuse in order to
-give an informative error message. This is an issue that may need
-to be brought up with the upstream author.
- <p>
-If the bug submitter disagrees with your decision to close the bug,
-they may reopen it until you find an agreement on how to handle it.
-If you don't find any, you may want to tag the bug <tt>wontfix</tt>
-to let people know that the bug exists but that it won't be corrected.
-If this situation is unacceptable, you (or the submitter) may want to
-require a decision of the technical committee by reassigning the bug
-to <package>tech-ctte</package> (you may use the clone command of
-the BTS if you wish to keep it reported against your package). Before
-doing so, please read the <url id="&url-tech-ctte;" name="recommended
-procedure">.
- <item>
-If the bug is real but it's caused by another package, just reassign
-the bug to the right package. If you don't know which package it should
-be reassigned to, you should ask for help on
-<qref id="irc-channels">IRC</qref> or on &email-debian-devel;.
-Please make sure that the maintainer(s) of the package
-the bug is reassigned to
-know why you reassigned it.
- <p>
-Sometimes you also have to adjust the severity of the bug so that it
-matches our definition of the severity. That's because people tend to
-inflate the severity of bugs to make sure their bugs are fixed quickly.
-Some bugs may even be dropped to wishlist severity when the requested
-change is just cosmetic.
- <item>
-If the bug is real but the same problem has already been reported by
-someone else, then the two relevant bug reports should be merged
-into one using the merge command of the BTS.
-In this way, when the
-bug is fixed, all of the submitters will be informed of this.
-(Note, however, that emails sent to one bug report's submitter won't
-automatically be sent to the other report's submitter.)
-For more
-details on the technicalities of the merge command and its relative,
-the unmerge command, see the BTS control server documentation.
- <item>
-The bug submitter may have forgotten to provide some information, in which
-case you have to ask them for the required information. You may use the
-<tt>moreinfo</tt> tag to mark the bug as such. Moreover if you can't
-reproduce the bug, you tag it <tt>unreproducible</tt>. Anyone who
-can reproduce the bug is then invited to provide more information
-on how to reproduce it. After a few months, if this information has not
-been sent by someone, the bug may be closed.
- <item>
-If the bug is related to the packaging, you just fix it. If you are not
-able to fix it yourself, then tag the bug as <tt>help</tt>. You can
-also ask for help on &email-debian-devel; or &email-debian-qa;. If it's an
-upstream problem, you have to forward it to the upstream author.
-Forwarding a bug is not enough, you have to check at each release if
-the bug has been fixed or not. If it has, you just close it, otherwise
-you have to remind the author about it. If you have the required skills
-you can prepare a patch that fixes the bug and
-send it to the author at the same time.
-Make sure to send the patch to the BTS and to
-tag the bug as <tt>patch</tt>.
- <item>
-If you have fixed a bug in your local copy, or if a fix has been
-committed to the CVS repository, you may tag the bug as
-<tt>pending</tt> to let people know that the bug is corrected and that
-it will be closed with the next upload (add the <tt>closes:</tt> in
-the <file>changelog</file>). This is particularly useful if you
-are several developers working on the same package.
- <item>
-Once a corrected package is available in the <em>unstable</em>
-distribution, you can close the bug. This can be done automatically,
-read <ref id="upload-bugfix">.
-</enumlist>
-
- <sect1 id="upload-bugfix">When bugs are closed by new uploads
- <p>
-As bugs and problems are fixed in your packages, it is your
-responsibility as the package maintainer to close these bugs. However,
-you should not close a bug until the package which fixes the bug has
-been accepted into the Debian archive. Therefore, once you get
-notification that your updated package has been installed into the
-archive, you can and should close the bug in the BTS.
-Also, the bug should be closed with the correct version.
- <p>
-However, it's possible to avoid having to manually close bugs after the
-upload — just list the fixed bugs in your <file>debian/changelog</file>
-file, following a certain syntax, and the archive maintenance software
-will close the bugs for you. For example:
-
-<example>
-acme-cannon (3.1415) unstable; urgency=low
-
- * Frobbed with options (closes: Bug#98339)
- * Added safety to prevent operator dismemberment, closes: bug#98765,
- bug#98713, #98714.
- * Added man page. Closes: #98725.
-</example>
-
-Technically speaking, the following Perl regular expression describes
-how bug closing changelogs are identified:
-<example>
- /closes:\s*(?:bug)?\#\s*\d+(?:,\s*(?:bug)?\#\s*\d+)*/ig
-</example>
-
-We prefer the <tt>closes: #<var>XXX</var></tt> syntax, as it is the
-most concise entry and the easiest to integrate with the text of the
-<file>changelog</file>.
-Unless specified different by the <var>-v</var>-switch to
-<prgn>dpkg-buildpackage</prgn>, only the bugs closed in the
-most recent changelog entry are closed (basically, exactly
-the bugs mentioned in the changelog-part
-in the <file>.changes</file> file are closed).
- <p>
-Historically, uploads identified as
-<qref id="nmu">Non-maintainer upload (NMU)</qref>
-were tagged <tt>fixed</tt> instead of being closed,
-but that practice was ceased with the advent of version-tracking.
-The same applied to the tag <tt>fixed-in-experimental</tt>.
- <p>
-If you happen to mistype a bug number or forget a bug in the changelog
-entries, don't hesitate to undo any damage the error caused. To reopen
-wrongly closed bugs, send a <tt>reopen <var>XXX</var></tt> command to
-the bug tracking system's control address, &email-bts-control;. To
-close any remaining bugs that were fixed by your upload, email the
-<file>.changes</file> file to <email>XXX-done@&bugs-host;</email>,
-where <var>XXX</var> is the bug number, and
-put "Version: YYY" and an empty line as the first two lines
-of the body of the email,
-where <var>YYY</var> is the first version
-where the bug has been fixed.
-
- <p>
-Bear in mind that it is not obligatory to close bugs using the
-changelog as described above. If you simply want to close bugs that
-don't have anything to do with an upload you made, do it by emailing
-an explanation to <email>XXX-done@&bugs-host;</email>. Do
-<strong>not</strong> close bugs in the changelog entry of a version if
-the changes in that version of the package don't have any bearing on
-the bug.
- <p>
-For general information on how to write your changelog entries, see
-<ref id="bpp-debian-changelog">.
-
-
- <sect1 id="bug-security">Handling security-related bugs
- <p>
-Due to their sensitive nature, security-related bugs must be handled
-carefully. The Debian Security Team exists to coordinate this
-activity, keeping track of outstanding security problems, helping
-maintainers with security problems or fixing them themselves, sending
-security advisories, and maintaining security.debian.org.
-
-<!-- information about the security database goes here once it's ready -->
-<!-- (mdz) -->
-
-<p>
-When you become aware of a security-related bug in a Debian package,
-whether or not you are the maintainer, collect pertinent information
-about the problem, and promptly contact the security team at
-&email-security-team; as soon as possible. <strong>DO NOT UPLOAD</strong>
-any packages for stable; the security team will do that.
-
-Useful information includes, for example:
-
-<list compact>
- <item>Which versions of the package are known to be affected by the
- bug. Check each version that is present in a supported Debian
- release, as well as testing and unstable.
-
- <item>The nature of the fix, if any is available (patches are
- especially helpful)
-
- <item>Any fixed packages that you have prepared yourself (send only
- the <tt>.diff.gz</tt> and <tt>.dsc</tt> files and read <ref
- id="bug-security-building"> first)
-
- <item>Any assistance you can provide to help with testing (exploits,
- regression testing, etc.)
-
- <item>Any information needed for the advisory (see <ref
- id="bug-security-advisories">)
-
-</list>
-
- <sect2 id="bug-security-confidentiality">Confidentiality
- <p>
-Unlike most other activities within Debian, information about security
-issues must sometimes be kept private for a time.
-This allows software distributors to coordinate their disclosure in
-order to minimize their users' exposure. Whether this is the
-case depends on the nature of the problem and corresponding fix, and
-whether it is already a matter of public knowledge.
-
-<p>
-There are several ways developers can learn of a security problem:
-
-<list compact>
- <item>they notice it on a public forum (mailing list, web site, etc.)
- <item>someone files a bug report
- <item>someone informs them via private email
-</list>
-
- In the first two cases, the information is public and it is important
- to have a fix as soon as possible. In the last case, however, it
- might not be public information. In that case there are a few
- possible options for dealing with the problem:
-
-<list>
- <item>If the security exposure is minor, there is sometimes no need
- to keep the problem a secret and a fix should be made and released.
-
- <item>If the problem is severe, it is preferable to share the
- information with
- other vendors and coordinate a release. The security team keeps
- in contact with the various organizations and individuals and can take
- care of that.
-</list>
-
-<p>
- In all cases if the person who reports the problem asks that it not
- be disclosed, such requests should be honored, with the obvious
- exception of informing the security team in order that a fix may be
- produced for a stable release of Debian. When sending confidential
- information to the security team, be sure to mention this fact.
-
-<p>
-Please note that if secrecy is needed you may not upload a fix to
-unstable (or anywhere else, such as a public CVS repository). It is
-not sufficient to obfuscate the details of the change, as the code
-itself is public, and can (and will) be examined by the general public.
-
-<p>
-There are two reasons for releasing information even though secrecy is
-requested: the problem has been known for a while, or the problem
-or exploit has become public.
-
- <sect2 id="bug-security-advisories">Security Advisories
- <p>
-Security advisories are only issued for the current, released stable
-distribution, and <em>not</em> for testing or unstable. When released,
-advisories
-are sent to the &email-debian-security-announce;
-
-mailing list and posted on <url
-id="&url-debian-security-advisories;" name="the security web page">.
-Security advisories are written and posted by the security
-team. However they certainly do not mind if a
-maintainer can supply some of the information for them, or write part
-of the text. Information that should be in an advisory includes:
-
-<list compact>
- <item>A description of the problem and its scope, including:
- <list>
- <item>The type of problem (privilege escalation, denial of
- service, etc.)
- <item>What privileges may be gained, and by whom (if any)
- <item>How it can be exploited
- <item>Whether it is remotely or locally exploitable
- <item>How the problem was fixed
- </list>
-
- This information allows users to assess the threat to their systems.
-
- <item>Version numbers of affected packages
- <item>Version numbers of fixed packages
- <item>Information on where to obtain the updated packages
- (usually from the Debian security archive)
- <item>References to upstream advisories, <url
- id="http://cve.mitre.org" name="CVE"> identifiers, and any other
- information useful in cross-referencing the vulnerability
-</list>
-
- <sect2 id="bug-security-building">
- <heading>Preparing packages to address security issues</heading>
- <p>
-One way that you can assist the security team in their duties is to
-provide them with fixed packages suitable for a security advisory for
-the stable
-Debian release.
- <p>
- When an update is made to the stable release, care must be taken to
- avoid changing system behavior or introducing new bugs. In order to
- do this, make as few changes as possible to fix the bug. Users and
- administrators rely on the exact behavior of a release once it is
- made, so any change that is made might break someone's system. This
- is especially true of libraries: make sure you never change the API or
- ABI, no matter how small the change.
-<p>
-This means that moving to a new upstream version is not a good
-solution. Instead, the relevant changes should be back-ported to the
-version present in the current stable Debian release. Generally,
-upstream maintainers are willing to help if needed. If not, the
-Debian security team may be able to help.
-<p>
-In some cases, it is not possible to back-port a security fix, for
-example when large amounts of source code need to be modified or
-rewritten. If this happens, it may be necessary to move to a new
-upstream version. However, this is only done in extreme situations,
-and you must always coordinate that with the security team beforehand.
-<p>
-Related to this is another important guideline: always test your
-changes. If you have an exploit available, try it and see if it
-indeed succeeds on the unpatched package and fails on the fixed
-package. Test other, normal actions as well, as sometimes a security
-fix can break seemingly unrelated features in subtle ways.
-<p>
-Do <strong>NOT</strong> include any changes in your package which are
-not directly related to fixing the vulnerability. These will only
-need to be reverted, and this wastes time. If there are other bugs in
-your package that you would like to fix, make an upload to
-proposed-updates in the usual way, after the security advisory is
-issued. The security update mechanism is not a means for introducing
-changes to your package which would otherwise be rejected from the
-stable release, so please do not attempt to do this.
-<p>
-Review and test your changes as much as possible. Check the
-differences from the previous version repeatedly
-(<prgn>interdiff</prgn> from the <package>patchutils</package> package
-and <prgn>debdiff</prgn> from <package>devscripts</package> are useful
-tools for this, see <ref id="debdiff">).
-<p>
-Be sure to verify the following items:
-
-<list>
- <item>Target the right distribution in your
- <file>debian/changelog</file>. For stable this is
- <tt>stable-security</tt> and for testing this is
- <tt>testing-security</tt>, and for the previous
- stable release, this is <tt>oldstable-security</tt>. Do not target
- <var>distribution</var>-proposed-updates or <tt>stable</tt>!
-
- <item>The upload should have urgency=high.
-
- <item>Make descriptive, meaningful changelog entries. Others will
- rely on them to determine whether a particular bug was fixed.
- 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.
-
- <item>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 <tt>dpkg
- --compare-versions</tt>. Be careful not to re-use a version
- number that you have already used for a previous upload. For
- <em>testing</em>, there must be
- a higher version in <em>unstable</em>. If there is none yet (for
- example, if <em>testing</em> and <em>unstable</em> have the same
- version) you must upload a new version to unstable first.
-
- <item>Do not make source-only uploads if your package has any
- binary-all packages (do not use the <tt>-S</tt> option to
- <prgn>dpkg-buildpackage</prgn>). The <prgn>buildd</prgn>
- infrastructure will not build those. This point applies to normal
- package uploads as well.
-
- <item>Unless the upstream source has been uploaded to
- security.debian.org before (by a previous security update), build
- the upload with full upstream source (<tt>dpkg-buildpackage
- -sa</tt>). If there has been a previous upload to
- security.debian.org with the same upstream version, you may upload
- without upstream source (<tt>dpkg-buildpackage -sd</tt>).
-
- <item>Be sure to use the exact same <file>*.orig.tar.gz</file> as used
- in the normal archive, otherwise it is not possible to move the
- security fix into the main archives later.
-
- <item>Build the package on a clean
- system which only has packages installed from the distribution you
- are building for. If you do not have such a system yourself, you
- can use a debian.org machine (see <ref id="server-machines">)
- or setup a chroot (see <ref id="pbuilder"> and
- <ref id="debootstrap">).
-</list>
-
- <sect2 id="bug-security-upload">Uploading the fixed package
-<p>
-Do <strong>NOT</strong> 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.
-<p>
-Do <strong>NOT</strong> 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
-is already installed into the archive, the security update will be
-rejected by the archive system. That way, the stable distribution
-will end up without a security update for this package instead.
-<p>
-Once you have created and tested the new package and it has been
-approved by the security team, it needs to be uploaded so that it can
-be installed in the archives. For security uploads, the place to
-upload to is
-<tt>ftp://security-master.debian.org/pub/SecurityUploadQueue/</tt> .
-
-<p>
-Once an upload to the security queue has been accepted, the package
-will automatically be rebuilt for all architectures and stored for
-verification by the security team.
-
-<p>
-Uploads which are waiting for acceptance or verification are only
-accessible by the security team. This is necessary since there might
-be fixes for security problems that cannot be disclosed yet.
-
-<p>
-If a member of the security team accepts a package, it will be
-installed on security.debian.org as well as proposed for the proper
-<var>distribution</var>-proposed-updates on ftp-master.
-
- <sect id="archive-manip">
- <heading>Moving, removing, renaming, adopting, and orphaning
- packages</heading>
- <p>
-Some archive manipulation operations are not automated in the Debian
-upload process. These procedures should be manually followed by
-maintainers. This chapter gives guidelines on what to do in these
-cases.
-
- <sect1 id="moving-pkgs">Moving packages
- <p>
-Sometimes a package will change its section. For instance, a
-package from the `non-free' section might be GPL'd in a later version,
-in which case the package should be moved to `main' or
-`contrib'.<footnote> See the <url id="&url-debian-policy;"
-name="Debian Policy Manual"> for guidelines on what section a package
-belongs in.
- </footnote>
- <p>
-If you need to change the section for one of your packages, change the
-package control information to place the package in the desired
-section, and re-upload the package (see the <url id="&url-debian-policy;"
-name="Debian Policy Manual"> for details).
-You must ensure that you include the <file>.orig.tar.gz</file> in your upload
-(even if you are not uploading a new upstream version),
-or it will not appear in the new section together with the rest of the
-package. If your new section is valid, it will be moved automatically. If
-it does not, then contact the ftpmasters in order to understand what
-happened.
- <p>
-If, on the other hand, you need to change the <em>subsection</em> of
-one of your packages (e.g., ``devel'', ``admin''), the procedure is
-slightly different. Correct the subsection as found in the control
-file of the package, and re-upload that. Also, you'll need to get the
-override file updated, as described in <ref id="override-file">.
-
-
- <sect1 id="removing-pkgs">Removing packages
- <p>
-If for some reason you want to completely remove a package (say, if it
-is an old compatibility library which is no longer required), you
-need to file a bug against <tt>ftp.debian.org</tt> asking that the
-package be removed;
-as all bugs, this bug should normally have normal severity.
-Make sure you indicate which distribution the
-package should be removed from. Normally, you can only have packages
-removed from <em>unstable</em> and <em>experimental</em>. Packages
-are not removed from <em>testing</em> directly. Rather, they will be
-removed automatically after the package has been removed from
-<em>unstable</em> and no package in <em>testing</em> depends on it.
- <p>
-There is one exception when an explicit removal request is not necessary:
-If a (source or binary) package is an orphan, it will be removed
-semi-automatically.
-For a binary-package, this means if there is no longer any source package
-producing this binary package;
-if the binary package is just no longer produced on some architectures,
-a removal request is still necessary.
-For a source-package, this means that all binary packages it refers to
-have been taken over by another source package.
- <p>
-In your removal request, you have to detail the reasons justifying the
-request. This is to
-avoid unwanted removals and to keep a trace of why a package has been
-removed. For example, you can provide the name of the package that
-supersedes the one to be removed.
- <p>
-Usually you only ask for the removal of a package maintained by yourself.
-If you want to remove another package, you have to get the approval
-of its maintainer.
- <p>
-Further information relating to these and other package removal related
-topics may be found at <url
-id="http://wiki.debian.org/ftpmaster_Removals"> and <url
-id="http://qa.debian.org/howto-remove.html">.
- <p>
-If in doubt concerning whether a package is disposable, email
-&email-debian-devel; asking for opinions. Also of interest is the
-<prgn>apt-cache</prgn> program from the <package>apt</package>
-package. When invoked as <tt>apt-cache showpkg
-<var>package</var></tt>, the program will show details for
-<var>package</var>, including reverse depends.
-Other useful programs include
-<tt>apt-cache rdepends</tt>,
-<prgn>apt-rdepends</prgn> and
-<prgn>grep-dctrl</prgn>.
-Removal of orphaned packages is discussed on &email-debian-qa;.
- <p>
-Once the package has been removed, the package's bugs should be handled.
-They should either be reassigned to another package in the case where
-the actual code has evolved into another package (e.g. <tt>libfoo12</tt>
-was removed because <tt>libfoo13</tt> supersedes it) or closed if the
-software is simply no longer part of Debian.
-
- <sect2>Removing packages from <file>Incoming</file>
- <p>
-In the past, it was possible to remove packages from <file>incoming</file>.
-However, with the introduction of the new incoming system, this is no longer
-possible. Instead, you have to upload a new revision of your package with
-a higher version than the package you want to replace. Both versions will be
-installed in the archive but only the higher version will actually be
-available in <em>unstable</em> since the previous version will immediately
-be replaced by the higher. However, if you do proper testing of your
-packages, the need to replace a package should not occur too often anyway.
-
- <sect1>Replacing or renaming packages
- <p>
-When you make a mistake naming your package, you should follow a two-step
-process to rename it. First, set
-your <file>debian/control</file> file to replace and conflict with the
-obsolete name of the package (see the <url id="&url-debian-policy;"
-name="Debian Policy Manual"> for details). Once you've uploaded
-the package and the package has moved into the archive, file a bug
-against <tt>ftp.debian.org</tt> asking to remove the package with the
-obsolete name. Do not forget to properly reassign the package's bugs
-at the same time.
- <p>
-At other times, you may make a mistake in constructing your package and
-wish to replace it. The only way to do this is to increase the version
-number and upload a new version. The old version will be expired in
-the usual manner. Note that this applies to each part of your package,
-including the sources: if you wish to replace the upstream source tarball
-of your package, you will need to upload it with a different version. An
-easy possibility is to replace <file>foo_1.00.orig.tar.gz</file> with
-<file>foo_1.00+0.orig.tar.gz</file>. This restriction gives each file
-on the ftp site a unique name, which helps to ensure consistency across the
-mirror network.
-
- <sect1 id="orphaning">Orphaning a package
- <p>
-If you can no longer maintain a package, you need to inform others,
-and see that the package is marked as orphaned.
-You should set the package maintainer to <tt>Debian QA Group
-&orphan-address;</tt> and submit a bug report
-against the pseudo package <package>wnpp</package>. The bug report should be
-titled <tt>O: <var>package</var> -- <var>short description</var></tt>
-indicating that the package is now orphaned. The severity of the bug
-should be set to <em>normal</em>; if the package has a priority of standard
-or higher, it should be set to important.
-If you feel it's necessary, send a copy
-to &email-debian-devel; by putting the address in the X-Debbugs-CC: header
-of the message (no, don't use CC:, because that way the message's subject
-won't indicate the bug number).
- <p>
-If you just intend to give the package away, but you can keep maintainership
-for the moment, then you should instead submit
-a bug against <package>wnpp</package> and title it <tt>RFA:
-<var>package</var> -- <var>short description</var></tt>.
-<tt>RFA</tt> stands for <em>Request For Adoption</em>.
- <p>
-More information is on the <url id="&url-wnpp;" name="WNPP web pages">.
-
- <sect1 id="adopting">Adopting a package
- <p>
-A list of packages in need of a new maintainer is available in the
-<url name="Work-Needing and Prospective Packages list (WNPP)"
-id="&url-wnpp;">. If you wish to take over maintenance of any of the
-packages listed in the WNPP, please take a look at the aforementioned
-page for information and procedures.
- <p>
-It is not OK to simply take over a package that you feel is neglected
-— that would be package hijacking. You can, of course, contact the
-current maintainer and ask them if you may take over the package.
-If you have reason to believe a maintainer has gone AWOL
-(absent without leave), see <ref id="mia-qa">.
- <p>
-Generally, you may not take over the package without the assent of the
-current maintainer. Even if they ignore you, that is still not grounds to
-take over a package. Complaints about maintainers should be brought up on
-the developers' mailing list. If the discussion doesn't end with a positive
-conclusion, and the issue is of a technical nature, consider bringing it to
-the attention of the technical committee (see the <url name="technical
-committee web page" id="&url-tech-ctte;"> for more information).
- <p>
-If you take over an old package, you probably want to be listed as the
-package's official maintainer in the bug system. This will happen
-automatically once you upload a new version with an updated
-<tt>Maintainer:</tt> field, although it can take a few hours after the
-upload is done. If you do not expect to upload a new version for a while,
-you can use <ref id="pkg-tracking-system"> to get the bug reports. However,
-make sure that the old maintainer has no problem with the fact that
-they will continue to receive the bugs during that time.
-
-
- <sect id="porting">Porting and being ported
- <p>
-Debian supports an ever-increasing number of architectures. Even if
-you are not a porter, and you don't use any architecture but one, it
-is part of your duty as a maintainer to be aware of issues of
-portability. Therefore, even if you are not a porter, you should read
-most of this chapter.
- <p>
-Porting is the act of building Debian packages for architectures that
-are different from the original architecture of the package
-maintainer's binary package. It is a unique and essential activity.
-In fact, porters do most of the actual compiling of Debian packages.
-For instance, for a single <em>i386</em> binary package, there must be
-a recompile for each architecture, which amounts to
-&number-of-arches; more builds.
-
-
- <sect1 id="kind-to-porters">Being kind to porters
- <p>
-Porters have a difficult and unique task, since they are required to
-deal with a large volume of packages. Ideally, every source package
-should build right out of the box. Unfortunately, this is often not
-the case. This section contains a checklist of ``gotchas'' often
-committed by Debian maintainers — common problems which often stymie
-porters, and make their jobs unnecessarily difficult.
- <p>
-The first and most important thing is to respond quickly to bug or
-issues raised by porters. Please treat porters with courtesy, as if
-they were in fact co-maintainers of your package (which, in a way, they
-are). Please be tolerant of succinct or even unclear bug reports;
-do your best to hunt down whatever the problem is.
- <p>
-By far, most of the problems encountered by porters are caused by
-<em>packaging bugs</em> in the source packages. Here is a checklist
-of things you should check or be aware of.
-
-<enumlist>
- <item>
-Make sure that your <tt>Build-Depends</tt> and
-<tt>Build-Depends-Indep</tt> settings in <file>debian/control</file>
-are set properly. The best way to validate this is to use the
-<package>debootstrap</package> package to create an unstable chroot
-environment (see <ref id="debootstrap">).
-Within that chrooted environment, install the
-<package>build-essential</package> package and any package
-dependencies mentioned in <tt>Build-Depends</tt> and/or
-<tt>Build-Depends-Indep</tt>. Finally, try building your package
-within that chrooted environment. These steps can be automated
-by the use of the <prgn>pbuilder</prgn> program which is provided by
-the package of the same name (see <ref id="pbuilder">).
- <p>
-If you can't set up a proper chroot, <prgn>dpkg-depcheck</prgn> may be
-of assistance (see <ref id="dpkg-depcheck">).
- <p>
-See the <url id="&url-debian-policy;" name="Debian Policy
-Manual"> for instructions on setting build dependencies.
- <item>
-Don't set architecture to a value other than ``all'' or ``any'' unless
-you really mean it. In too many cases, maintainers don't follow the
-instructions in the <url id="&url-debian-policy;" name="Debian Policy
-Manual">. Setting your architecture to ``i386'' is usually incorrect.
- <item>
-Make sure your source package is correct. Do <tt>dpkg-source -x
-<var>package</var>.dsc</tt> to make sure your source package unpacks
-properly. Then, in there, try building your package from scratch with
-<prgn>dpkg-buildpackage</prgn>.
- <item>
-Make sure you don't ship your source package with the
-<file>debian/files</file> or <file>debian/substvars</file> files.
-They should be removed by the `clean' target of
-<file>debian/rules</file>.
- <item>
-Make sure you don't rely on locally installed or hacked configurations
-or programs. For instance, you should never be calling programs in
-<file>/usr/local/bin</file> or the like. Try not to rely on programs
-being setup in a special way. Try building your package on another
-machine, even if it's the same architecture.
- <item>
-Don't depend on the package you're building being installed already (a
-sub-case of the above issue).
- <item>
-Don't rely on the compiler being a certain version, if possible. If
-not, then make sure your build dependencies reflect the restrictions,
-although you are probably asking for trouble, since different
-architectures sometimes standardize on different compilers.
- <item>
-Make sure your debian/rules contains separate ``binary-arch'' and
-``binary-indep'' targets, as the Debian Policy Manual requires.
-Make sure that both targets work independently, that is, that you can
-call the target without having called the other before. To test this,
-try to run <tt>dpkg-buildpackage -B</tt>.
- </enumlist>
-
-
- <sect1 id="porter-guidelines">Guidelines for porter uploads
- <p>
-If the package builds out of the box for the architecture to be ported
-to, you are in luck and your job is easy. This section applies to
-that case; it describes how to build and upload your binary package so
-that it is properly installed into the archive. If you do have to
-patch the package in order to get it to compile for the other
-architecture, you are actually doing a source NMU, so consult <ref
-id="nmu-guidelines"> instead.
- <p>
-For a porter upload, no changes are being made to the source. You do
-not need to touch any of the files in the source package. This
-includes <file>debian/changelog</file>.
- <p>
-The way to invoke <prgn>dpkg-buildpackage</prgn> is as
-<tt>dpkg-buildpackage -B -m<var>porter-email</var></tt>. Of course,
-set <var>porter-email</var> to your email address. This will do a
-binary-only build of only the architecture-dependent portions of the
-package, using the `binary-arch' target in <file>debian/rules</file>.
- <p>
-If you are working on a Debian machine for your porting efforts and you
-need to sign your upload locally for its acceptance in the archive, you
-can run <prgn>debsign</prgn> on your <file>.changes</file> file to have
-it signed conveniently, or use the remote signing mode of
-<prgn>dpkg-sig</prgn>.
-
-
- <sect2 id="binary-only-nmu">
- <heading>Recompilation or binary-only NMU</heading>
- <p>
-Sometimes the initial porter upload is problematic because the environment
-in which the package was built was not good enough (outdated or obsolete
-library, bad compiler, ...). Then you may just need to recompile it in
-an updated environment. However, you have to bump the version number in
-this case, so that the old bad package can be replaced in the Debian archive
-(<prgn>katie</prgn> refuses to install new packages if they don't have a
-version number greater than the currently available one).
- <p>
-You have to make sure that your binary-only NMU doesn't render the package
-uninstallable. This could happen when a source package generates
-arch-dependent and arch-independent packages that depend on each other via
-$(Source-Version).
- <p>
-Despite the
-required modification of the changelog, these are called binary-only NMUs
-— there is no need in this case to trigger all other architectures
-to consider themselves out of date or requiring recompilation.
- <p>
-Such recompilations require special ``magic'' version numbering, so that
-the archive maintenance tools recognize that, even though there is a
-new Debian version, there is no corresponding source update. If you
-get this wrong, the archive maintainers will reject your upload (due
-to lack of corresponding source code).
- <p>
-The ``magic'' for a recompilation-only NMU is triggered by using a
-suffix appended to the package version number,
-following the form b<number>.
-For instance, if the latest version you are
-recompiling against was version ``2.9-3'', your NMU should carry a
-version of ``2.9-3+b1''. If the latest version was ``3.4+b1'' (i.e, a
-native package with a previous recompilation NMU), your NMU should have
-a version number of ``3.4+b2''.
-
-<footnote>
-In the past, such NMUs used the third-level number on the Debian part of
-the revision to denote their recompilation-only status; however, this
-syntax was ambiguous with native packages and did not allow proper
-ordering of recompile-only NMUs, source NMUs, and security NMUs on the
-same package, and has therefore been abandoned in favor of this new
-syntax.</footnote>
- <p>
-Similar to initial porter uploads, the correct way of invoking
-<prgn>dpkg-buildpackage</prgn> is <tt>dpkg-buildpackage -B</tt> to only
-build the architecture-dependent parts of the package.
-
-
- <sect2 id="source-nmu-when-porter">
- <heading>When to do a source NMU if you are a porter</heading>
- <p>
-Porters doing a source NMU generally follow the guidelines found in
-<ref id="nmu">, just like non-porters. However, it is expected that
-the wait cycle for a porter's source NMU is smaller than for a
-non-porter, since porters have to cope with a large quantity of
-packages.
-Again, the situation varies depending on the distribution they are
-uploading to. It also varies whether the architecture is a candidate
-for inclusion into the next stable release; the release managers
-decide and announce which architectures are candidates.
- <p>
-If you are a porter doing an NMU for `unstable', the above
-guidelines for porting should be followed, with two variations.
-Firstly, the acceptable waiting period — the time between when the
-bug is submitted to the BTS and when it is OK to do an NMU — is seven
-days for porters working on the unstable distribution. This period
-can be shortened if the problem is critical and imposes hardship on
-the porting effort, at the discretion of the porter group. (Remember,
-none of this is Policy, just mutually agreed upon guidelines.)
-For uploads to stable or testing, please coordinate with the appropriate
-release team first.
- <p>
-Secondly, porters doing source NMUs should make sure that the bug they
-submit to the BTS should be of severity `serious' or greater. This
-ensures that a single source package can be used to compile every
-supported Debian architecture by release time. It is very important
-that we have one version of the binary and source package for all
-architecture in order to comply with many licenses.
- <p>
-Porters should try to avoid patches which simply kludge around bugs in
-the current version of the compile environment, kernel, or libc.
-Sometimes such kludges can't be helped. If you have to kludge around
-compiler bugs and the like, make sure you <tt>#ifdef</tt> your work
-properly; also, document your kludge so that people know to remove it
-once the external problems have been fixed.
- <p>
-Porters may also have an unofficial location where they can put the
-results of their work during the waiting period. This helps others
-running the port have the benefit of the porter's work, even during
-the waiting period. Of course, such locations have no official
-blessing or status, so buyer beware.
-
-
- <sect1 id="porter-automation">
- <heading>Porting infrastructure and automation</heading>
- <p>
-There is infrastructure and several tools to help automate package
-porting. This section contains a brief overview of this automation and
-porting to these tools; see the package documentation or references for
-full information.</p>
-
- <sect2>
- <heading>Mailing lists and web pages</heading>
- <p>
-Web pages containing the status of each port can be found at <url
-id="&url-debian-ports;">.
- <p>
-Each port of Debian has a mailing list. The list of porting mailing
-lists can be found at <url id="&url-debian-port-lists;">. These lists
-are used to coordinate porters, and to connect the users of a given
-port with the porters.</p>
- </sect2>
-
- <sect2>
- <heading>Porter tools</heading>
- <p>
-Descriptions of several porting tools can be found in <ref
-id="tools-porting">.</p>
- </sect2>
-
- <sect2 id="buildd">
- <heading><package>buildd</package></heading>
- <p>
-The <package>buildd</package> system is used as a distributed,
-client-server build distribution system. It is usually used in
-conjunction with <em>auto-builders</em>, which are ``slave'' hosts
-which simply check out and attempt to auto-build packages which need
-to be ported. There is also an email interface to the system, which
-allows porters to ``check out'' a source package (usually one which
-cannot yet be auto-built) and work on it.
- <p>
-<package>buildd</package> is not yet available as a package; however,
-most porting efforts are either using it currently or planning to use
-it in the near future. The actual automated builder is packaged as
-<package>sbuild</package>, see its description in <ref id="sbuild">.
-The complete <package>buildd</package> system also collects a number of as
-yet unpackaged components which are currently very useful and in use
-continually, such as <prgn>andrea</prgn> and <prgn>wanna-build</prgn>.
- <p>
-Some of the data produced by <package>buildd</package> which is
-generally useful to porters is available on the web at <url
-id="&url-buildd;">. This data includes nightly updated information
-from <prgn>andrea</prgn> (source dependencies) and
-<package>quinn-diff</package> (packages needing recompilation).
- <p>
-We are quite proud of this system, since it has so
-many possible uses. Independent development groups can use the system for
-different sub-flavors of Debian, which may or may not really be of
-general interest (for instance, a flavor of Debian built with
-<prgn>gcc</prgn> bounds checking). It will also enable Debian to
-recompile entire distributions quickly.
- <p>
-The buildds admins of each arch can be contacted at the mail address
-$arch@buildd.debian.org.
-
- <sect1 id="packages-arch-specific">When your package is <em>not</em> portable
- <p>
-Some packages still have issues with building and/or working on some
-of the architectures supported by Debian, and cannot be ported at all,
-or not within a reasonable amount of time. An example is a package that
-is SVGA-specific (only i386), or uses other hardware-specific features
-not supported on all architectures.
- <p>
-In order to prevent broken packages from being uploaded to the archive, and
-wasting buildd time, you need to do a few things:
- <p>
- <list>
- <item>
- <p>
-First, make sure your package <em>does</em> fail to build on
-architectures that it cannot support.
-There are a few ways to achieve this.
-The preferred way is to have a small testsuite during build time
-that will test the functionality, and fail if it doesn't work.
-This is a good idea anyway,
-as this will prevent (some) broken uploads on all architectures,
-and also will allow the package to build
-as soon as the required functionality is available.
- <p>
-Additionally, if you believe the list of supported architectures is
-pretty constant, you should change 'any' to a list of supported
-architectures in debian/control. This way, the build will fail also,
-and indicate this to a human reader without actually trying.
- <item>
- <p>
-In order to prevent autobuilders from needlessly trying to build your
-package, it must be included in <file>packages-arch-specific</file>, a
-list used by the <prgn>wanna-build</prgn> script.
-The current version is available as
-<url id="http://cvs.debian.org/srcdep/Packages-arch-specific?cvsroot=dak">;
-please see the top of the file for whom to contact for changes.
- </list>
- <p>
-Please note that it is insufficient to only add your package to
-Packages-arch-specific
-without making it fail to build on unsupported architectures:
-A porter or any other person trying to build your package might
-accidently upload it without noticing it doesn't work.
-If in the past some binary packages were uploaded on unsupported
-architectures, request their removal by filing a bug against
-<package>ftp.debian.org</package>
-
-
- <sect id="nmu">Non-Maintainer Uploads (NMUs)
- <p>
-Under certain circumstances it is necessary for someone other than the
-official package maintainer to make a release of a package. This is
-called a non-maintainer upload, or NMU.
- <p>
-This section handles only source NMUs, i.e. NMUs which upload a new
-version of the package. For binary-only NMUs by porters or QA members,
-please see <ref id="binary-only-nmu">.
-If a buildd builds and uploads a package,
-that too is strictly speaking a binary NMU.
-See <ref id="buildd"> for some more information.
- <p>
-The main reason why NMUs are done is when a
-developer needs to fix another developer's package in order to
-address serious problems or crippling bugs
-or when the package maintainer is unable to release a fix
-in a timely fashion.
- <p>
-First and foremost, it is critical that NMU patches to source should
-be as non-disruptive as possible. Do not do housekeeping tasks, do
-not change the name of modules or files, do not move directories; in
-general, do not fix things which are not broken. Keep the patch as
-small as possible. If things bother you aesthetically, talk to the
-Debian maintainer, talk to the upstream maintainer, or submit a bug.
-However, aesthetic changes must <em>not</em> be made in a non-maintainer
-upload.
- <p>
-And please remember the Hippocratic Oath: "Above all, do no harm." It
-is better to leave a package with an open grave bug than applying a
-non-functional patch, or one that hides the bug instead of resolving
-it.
-
-
- <sect1 id="nmu-guidelines">How to do a NMU
- <p>
-NMUs which fix important, serious or higher severity bugs are encouraged
-and accepted.
-You should endeavor to reach the current maintainer of the package; they
-might be just about to upload a fix for the problem, or have a better
-solution.
- <p>
-NMUs should be made to assist a package's maintainer in resolving bugs.
-Maintainers should be thankful for that help, and NMUers should respect
-the decisions of maintainers, and try to personally help the maintainer by
-their work.
- <p>
-A NMU should follow all conventions, written down in this section.
-For an upload to testing or unstable, this order of steps is recommended:
- <p>
-<list>
- <item>
-Make sure that the package's bugs that the NMU is meant to address are all
-filed in the Debian Bug Tracking System (BTS).
-If they are not, submit them immediately.
- <item>
-Wait a few days for the response from the maintainer. If you don't get
-any response, you may want to help them by sending the patch that fixes
-the bug. Don't forget to tag the bug with the "patch" keyword.
- <item>
-Wait a few more days. If you still haven't got an answer from the
-maintainer, send them a mail announcing your intent to NMU the package.
-Prepare an NMU as described in this section, and test it
-carefully on your machine (cf. <ref id="sanitycheck">).
-Double check that your patch doesn't have any unexpected side effects.
-Make sure your patch is as small and as non-disruptive as it can be.
- <item>
-Upload your package to incoming in <file>DELAYED/7-day</file> (cf.
-<ref id="delayed-incoming">), send the final patch to the maintainer via
-the BTS, and explain to them that they have 7 days to react if they want
-to cancel the NMU.
- <item>
-Follow what happens, you're responsible for any bug that you introduced
-with your NMU. You should probably use <ref id="pkg-tracking-system"> (PTS)
-to stay informed of the state of the package after your NMU.
-</list>
- <p>
-At times, the release manager or an organized group of developers can
-announce a certain period of time in which the NMU rules are relaxed.
-This usually involves shortening the period during which one is to wait
-before uploading the fixes, and shortening the DELAYED period. It is
-important to notice that even in these so-called "bug squashing party"
-times, the NMU'er has to file bugs and contact the developer first,
-and act later.
-Please see <ref id="qa-bsp"> for details.
- <p>
-For the testing distribution, the rules may be changed by the release
-managers. Please take additional care, and acknowledge that the usual way
-for a package to enter testing is through unstable.
- <p>
-For the stable distribution, please take extra care. Of course, the release
-managers may also change the rules here. Please verify before you upload that
-all your changes are OK for inclusion into the next stable release by the
-release manager.
- <p>
-When a security bug is detected, the security team may do an NMU, using
-their own rules. Please refer to <ref id="bug-security"> for more
-information.
- <p>
-For the differences for Porters NMUs, please see
-<ref id="source-nmu-when-porter">.
- <p>
-Of course, it is always possible to agree on special rules with a maintainer
-(like the maintainer asking "please upload this fix directly for me, and no
-diff required").
-
-
- <sect1 id="nmu-version">NMU version numbering
- <p>
-Whenever you have made a change to a package, no matter how trivial,
-the version number needs to change. This enables our packing system
-to function.
- <p>
-If you are doing a non-maintainer upload (NMU), you should add a new
-minor version number to the <var>debian-revision</var> part of the
-version number (the portion after the last hyphen). This extra minor
-number will start at `1'. For example, consider the package `foo',
-which is at version 1.1-3. In the archive, the source package control
-file would be <file>foo_1.1-3.dsc</file>. The upstream version is
-`1.1' and the Debian revision is `3'. The next NMU would add a new
-minor number `.1' to the Debian revision; the new source control file
-would be <file>foo_1.1-3.1.dsc</file>.
- <p>
-The Debian revision minor number is needed to avoid stealing one of
-the package maintainer's version numbers, which might disrupt their
-work. It also has the benefit of making it visually clear that a
-package in the archive was not made by the official maintainer.
- <p>
-If there is no <var>debian-revision</var> component in the version
-number then one should be created, starting at `0.1' (but in case
-of a debian native package still upload it as native package).
-If it is
-absolutely necessary for someone other than the usual maintainer to
-make a release based on a new upstream version then the person making
-the release should start with the <var>debian-revision</var> value
-`0.1'. The usual maintainer of a package should start their
-<var>debian-revision</var> numbering at `1'.
- <p>
-If you upload a package to testing or stable, sometimes, you need to
-"fork" the version number tree. For this, version numbers like
-1.1-3sarge0.1 could be used.
-
-
- <sect1 id="nmu-changelog">
- <heading>Source NMUs must have a new changelog entry</heading>
- <p>
-Anyone who is doing a source NMU must create a changelog entry,
-describing which bugs are fixed by the NMU, and generally why the NMU
-was required and what it fixed. The changelog entry will have the
-email address of the person who uploaded it in the log entry
-and the NMU version number in it.
- <p>
-By convention, source NMU changelog entries start with the line
-<example>
- * Non-maintainer upload
-</example>
-
-
- <sect1 id="nmu-patch">Source NMUs and the Bug Tracking System
- <p>
-Maintainers other than the official package maintainer should make as
-few changes to the package as possible, and they should always send a
-patch as a unified context diff (<tt>diff -u</tt>) detailing their
-changes to the Bug Tracking System.
- <p>
-What if you are simply recompiling the package? If you just need to
-recompile it for a single architecture, then you may do a binary-only
-NMU as described in <ref id="binary-only-nmu"> which doesn't require any
-patch to be sent. If you want the package to be recompiled for all
-architectures, then you do a source NMU as usual and you will have to
-send a patch.
- <p>
-Bugs fixed by source NMUs used to be tagged fixed instead of closed,
-but since version tracking is in place, such bugs are now also
-closed with the NMU version.
- <p>
-Also, after doing an NMU, you have to send
-the information to the existing bugs that are fixed by your NMU,
-including the unified diff.
-Historically, it was custom to open a new bug and include a
-patch showing all the changes you have made.
-The normal maintainer will either apply the patch or employ an alternate
-method of fixing the problem. Sometimes bugs are fixed independently
-upstream, which is another good reason to back out an NMU's patch.
-If the maintainer decides not to apply the NMU's patch but to release a
-new version, the maintainer needs to ensure that the new upstream version
-really fixes each problem that was fixed in the non-maintainer release.
- <p>
-In addition, the normal maintainer should <em>always</em> retain the
-entry in the changelog file documenting the non-maintainer upload --
-and of course, also keep the changes.
-If you revert some of the changes,
-please reopen the relevant bug reports.
-
-
- <sect1 id="nmu-build">Building source NMUs
- <p>
-Source NMU packages are built normally. Pick a distribution using the
-same rules as found in <ref id="distribution">, follow the other
-instructions in <ref id="upload">.
- <p>
-Make sure you do <em>not</em> change the value of the maintainer in
-the <file>debian/control</file> file. Your name as given in the NMU entry of
-the <file>debian/changelog</file> file will be used for signing the
-changes file.
-
- <sect1 id="ack-nmu">Acknowledging an NMU
- <p>
-If one of your packages has been NMU'ed, you have to incorporate the
-changes in your copy of the sources. This is easy, you just have
-to apply the patch that has been sent to you. Once this is done, you
-have to close the bugs that have been tagged fixed by the NMU. The easiest
-way is to use the <tt>-v</tt> option of <prgn>dpkg-buildpackage</prgn>,
-as this allows you to include just all changes since your last maintainer
-upload. Alternatively, you
-can close them manually by sending the required mails to the
-BTS or by adding the required <tt>closes: #nnnn</tt> in the changelog
-entry of your next upload.
- <p>
-In any case, you should not be upset by the NMU. An NMU is not a
-personal attack against the maintainer. It is a proof that
-someone cares enough about the package that they were willing to help
-you in your work, so you should be thankful. You may also want to
-ask them if they would be interested in helping you on a more frequent
-basis as co-maintainer or backup maintainer
-(see <ref id="collaborative-maint">).
-
- <sect1 id="nmu-vs-qa">NMU vs QA uploads
- <p>
-Unless you know the maintainer is still active, it is wise to check the
-package to see if it has been orphaned. The current list of orphaned
-packages which haven't had their maintainer set correctly is available at
-<url id="&url-debian-qa-orphaned;">. If you perform an NMU on an
-improperly orphaned package, please set the maintainer to ``Debian QA Group
-<packages@qa.debian.org>''.
-
- <sect1 id="nmu-who">Who can do an NMU
- <p>
-Only official, registered Debian Developers can do binary or source
-NMUs. A Debian Developer is someone who has their key in the
-Debian key ring. Non-developers, however, are encouraged to download
-the source package and start hacking on it to fix problems; however,
-rather than doing an NMU, they should just submit worthwhile patches
-to the Bug Tracking System. Maintainers almost always appreciate
-quality patches and bug reports.
-
- <sect1 id="nmu-terms">Terminology
- <p>
-There are two new terms used throughout this section: ``binary-only NMU''
-and ``source NMU''. These terms are used with specific technical
-meaning throughout this document. Both binary-only and source NMUs are
-similar, since they involve an upload of a package by a developer who
-is not the official maintainer of that package. That is why it's a
-<em>non-maintainer</em> upload.
- <p>
-A source NMU is an upload of a package by a developer who is not the
-official maintainer, for the purposes of fixing a bug in the package.
-Source NMUs always involves changes to the source (even if it is just
-a change to <file>debian/changelog</file>). This can be either a
-change to the upstream source, or a change to the Debian bits of the
-source. Note, however, that source NMUs may also include
-architecture-dependent packages, as well as an updated Debian diff.
- <p>
-A binary-only NMU is a recompilation and upload of a binary package
-for a given architecture. As such, it is usually part of a porting
-effort. A binary-only NMU is a non-maintainer uploaded binary version
-of a package, with no source changes required. There are many cases
-where porters must fix problems in the source in order to get them to
-compile for their target architecture; that would be considered a
-source NMU rather than a binary-only NMU. As you can see, we don't
-distinguish in terminology between porter NMUs and non-porter NMUs.
- <p>
-Both classes of NMUs, source and binary-only, can be lumped under the
-term ``NMU''. However, this often leads to confusion, since most
-people think ``source NMU'' when they think ``NMU''. So it's best to
-be careful: always use ``binary NMU'' or ``binNMU'' for binary-only
-NMUs.
-
-
- <sect id="collaborative-maint">
- <heading>Collaborative maintenance</heading>
- <p>
-"Collaborative maintenance" is a term describing the sharing of Debian
-package maintenance duties by several people. This collaboration is
-almost always a good idea, since it generally results in higher quality and
-faster bug fix turnaround times. It is strongly recommended that
-packages with a priority of <tt>Standard</tt> or which are part of
-the base set have co-maintainers.</p>
- <p>
-Generally there is a primary maintainer and one or more
-co-maintainers. The primary maintainer is the person whose name is listed in
-the <tt>Maintainer</tt> field of the <file>debian/control</file> file.
-Co-maintainers are all the other maintainers.</p>
- <p>
-In its most basic form, the process of adding a new co-maintainer is
-quite easy:
-<list>
- <item>
- <p>
-Setup the co-maintainer with access to the sources you build the
-package from. Generally this implies you are using a network-capable
-version control system, such as <prgn>CVS</prgn> or
-<prgn>Subversion</prgn>. Alioth (see <ref id="alioth">) provides such
-tools, amongst others.</p>
- </item>
- <item>
- <p>
-Add the co-maintainer's correct maintainer name and address to the
-<tt>Uploaders</tt> field in the global part of the
-<file>debian/control</file> file.
-<example>
-Uploaders: John Buzz <jbuzz@debian.org>, Adam Rex <arex@debian.org>
-</example>
-</p>
- </item>
- <item>
- <p>
-Using the PTS (<ref id="pkg-tracking-system">), the co-maintainers
-should subscribe themselves to the appropriate source package.</p>
- </item>
- </list></p>
- <p>
-Another form of collaborative maintenance is team maintenance, which is
-recommended if you maintain several packages with the same group of
-developers. In that case, the Maintainer and Uploaders field of each
-package must be managed with care. It is recommended to choose between
-one of the two following schemes:
- <enumlist>
- <item>
- <p>
-Put the team member mainly responsible for the package in the Maintainer
-field. In the Uploaders, put the mailing list address, and the team members
-who care for the package.
- </item>
- <item>
- <p>
-Put the mailing list address in the Maintainer field. In the Uploaders
-field, put the team members who care for the package.
-In this case, you must make sure the mailing list accept bug reports
-without any human interaction (like moderation for non-subscribers).
- </item>
- </enumlist>
- <p>
-In any case, it is a bad idea to automatically put all team members in
-the Uploaders field. It clutters the Developer's Package Overview listing
-(see <ref id="ddpo">) with packages one doesn't really care for, and
-creates a false sense of good maintenance.
- </sect>
-
- <sect id="testing">
- <heading>The testing distribution</heading>
- <p>
- <sect1 id="testing-basics">
- <heading>Basics</heading>
- <p>
-Packages are usually installed into the `testing' distribution after they
-have undergone some degree of testing in unstable.
- <p>
-They must be in sync on all architectures and
-mustn't have dependencies that make them uninstallable; they also have to
-have generally no known release-critical bugs at the time they're
-installed into testing.
-This way, `testing' should always be close to being a release candidate.
-Please see below for details.
- <sect1 id="testing-unstable">
- <heading>Updates from unstable</heading>
- <p>
-The scripts that update the <em>testing</em> distribution are run each
-day after the installation of the updated packages;
-these scripts are called <em>britney</em>.
-They generate the
-<file>Packages</file> files for the <em>testing</em> distribution, but
-they do so in an intelligent manner; they try to avoid any inconsistency
-and to use only non-buggy packages.
- <p>
-The inclusion of a package from <em>unstable</em> is conditional on
-the following:
-<list>
- <item>
-The package must have been available in <em>unstable</em> for 2, 5 or 10
-days, depending on the urgency (high, medium or low).
-Please note that the urgency is sticky, meaning that the highest
-urgency uploaded since the previous testing transition is taken into account.
-Those delays may be doubled during a freeze, or testing transitions may be
-switched off altogether;
- <item>
-It must have the same number or fewer release-critical bugs than the
-version currently available in <em>testing</em>;
- <item>
-It must be available on all architectures on which it has previously
-been built in unstable. <ref id="madison"> may be of interest to
-check that information;
- <item>
-It must not break any dependency of a package which is already available
-in <em>testing</em>;
- <item>
-The packages on which it depends must either be available in <em>testing</em>
-or they must be accepted into <em>testing</em> at the same time (and they
-will be if they fulfill all the necessary criteria);
-</list>
- <p>
-To find out whether a package is progressing into testing or not, see the
-testing script output on the <url name="web page of the testing distribution"
-id="&url-testing-maint;">, or use the program <prgn>grep-excuses</prgn>
-which is in the <package>devscripts</package> package. This utility can
-easily be used in a <manref name="crontab" section="5"> to keep yourself
-informed of the progression of your packages into <em>testing</em>.
- <p>
-The <file>update_excuses</file> file does not always give the precise reason
-why the package is refused; you may have to find it on your own by looking
-for what would break with the inclusion of the package. The
-<url id="&url-testing-maint;" name="testing web page"> gives some more
-information about the usual problems which may be causing such troubles.
- <p>
-Sometimes, some packages never enter <em>testing</em> because the set of
-inter-relationship is too complicated and cannot be sorted out
-by the scripts. See below for details.
- <p>
-Some further dependency analysis is shown on
-<url id="http://bjorn.haxx.se/debian/"> — but be warned,
-this page also shows build dependencies which
-are not considered by britney.
-
- <sect2 id="outdated">
- <heading>out-of-date</heading>
- <p>
-<!-- FIXME: better rename this file than document rampant professionalism?
--->
-For the testing migration script, "outdated" means: There are different
-versions in unstable for the release architectures (except for the
-architectures in fuckedarches; fuckedarches is a list of architectures
-that don't keep up (in update_out.py), but currently, it's empty).
-"outdated" has nothing whatsoever to do with the architectures this package
-has in testing.
- <p>
-Consider this example:
- <p>
- <example>
-foo | alpha | arm
----------+-------+----
-testing | 1 | -
-unstable | 1 | 2
-</example>
- <p>
-The package is out of date on alpha in unstable, and will not go to
-testing. And removing foo from testing would not help at all, the package
-is still out of date on alpha, and will not propagate to testing.
- <p>
-However, if ftp-master removes a package in unstable (here on arm):
- <p>
- <example>
-foo | alpha | arm | hurd-i386
----------+-------+-----+----------
-testing | 1 | 1 | -
-unstable | 2 | - | 1
- </example>
- <p>
-In this case, the package is up to date on all release architectures in
-unstable (and the extra hurd-i386 doesn't matter, as it's not a release
-architecture).
- <p>
-Sometimes, the question is raised if it is possible to allow packages in
-that are not yet built on all architectures: No. Just plainly no. (Except
-if you maintain glibc or so.)
-
- <sect2 id="removals">
- <heading>Removals from testing</heading>
- <p>
-Sometimes, a package is removed to allow another package in: This happens
-only to allow <em>another</em> package to go in if it's ready in every other
-sense. Suppose e.g. that <em>a</em> cannot be installed with the new
-version of <em>b</em>; then <em>a</em> may be removed to allow <em>b</em>
-in.
- <p>
-Of course, there is another reason to remove a package from testing: It's
-just too buggy (and having a single RC-bug is enough to be in this state).
- <p>
-Furthermore, if a package has been removed from unstable,
-and no package in testing depends on it any more,
-then it will automatically be removed.
-
-
- <sect2 id="circular">
- <heading>circular dependencies</heading>
- <p>
-A situation which is not handled very well by britney is if package
-<em>a</em> depends on the new version of package <em>b</em>, and vice
-versa.
- <p>
-An example of this is:
- <p>
- <example>
- | testing | unstable
---+-----------------+------------
-a | 1; depends: b=1 | 2; depends: b=2
-b | 1; depends: a=1 | 2; depends: a=2
- </example>
- <p>
-Neither package <em>a</em> nor package <em>b</em> is considered for update.
- <p>
-Currently, this requires some manual hinting from the release team.
-Please contact them by sending mail to &email-debian-release; if this
-happens to one of your packages.
-
-
- <sect2>
- <heading>influence of package in testing</heading>
- <p>
-Generally, there is nothing that the status of a package in testing means
-for transition of the next version from unstable to testing, with two
-exceptions: If the RC-bugginess of the package goes down, it may go in
-even if it is still RC-buggy. The second exception is if the version
-of the package in testing is out of sync on the different arches: Then
-any arch might just upgrade to the version of the source package;
-however, this can happen only if the package was previously forced
-through, the arch is in fuckedarches, or there was no binary package of that
-arch present in unstable at all during the testing migration.
- <p>
-In summary this means: The only influence that a package being in testing
-has on a new version of the same package is that the new version might
-go in easier.
-
- <sect2 id="details">
- <heading>details</heading>
- <p>
-If you are interested in details, this is how britney works:
- <p>
-The packages are looked at to determine whether they are valid
-candidates. This gives the "update excuses". The most common reasons
-why a package is not considered are too young, RC-bugginess, and out of
-date on some arches. For this part of britney,
-the release managers have hammers
-of various sizes to force britney to consider a package. (Also, the base
-freeze is coded in that part of britney.) (There is a similar thing
-for binary-only updates, but this is not described here. If you're
-interested in that, please peruse the code.)
- <p>
-Now, the more complex part happens: Britney tries to update testing with
-the valid candidates; first, each package alone, and then larger and even
-larger sets of packages together. Each try is accepted if testing is not
-more uninstallable after the update than before. (Before and after this part,
-some hints are processed; but as only release masters can hint, this is
-probably not so important for you.)
- <p>
-If you want to see more details, you can look it up on
-merkel:/org/ftp.debian.org/testing/update_out/ (or there in
-~aba/testing/update_out to see a setup with a smaller packages file). Via
-web, it's at <url
-id="http://ftp-master.debian.org/testing/update_out_code/">
- <p>
-The hints are available via <url
-id="http://ftp-master.debian.org/testing/hints/">.
-
-
- <sect1 id="t-p-u">
- <heading>Direct updates to testing</heading>
- <p>
-The testing distribution is fed with packages from unstable according to
-the rules explained above. However, in some cases, it is necessary to
-upload packages built only for testing. For that, you may want to upload
-to <em>testing-proposed-updates</em>.
- <p>
-Keep in mind that packages uploaded there are not automatically processed,
-they have to go through the hands of the release manager. So you'd better
-have a good reason to upload there. In order to know what a good reason is
-in the release managers' eyes, you should read the instructions that they
-regularly give on &email-debian-devel-announce;.
- <p>
-You should not upload to <em>testing-proposed-updates</em> when you can
-update your packages through <em>unstable</em>. If you can't (for example
-because you have a newer development version in unstable), you may use
-this facility, but it is recommended that you ask for authorization from
-the release manager first. Even if a package is frozen, updates through
-unstable are possible, if the upload via unstable does not pull in any new
-dependencies.
- <p>
-Version numbers are usually selected by adding the codename of the testing
-distribution and a running number, like 1.2sarge1 for the first upload
-through testing-proposed-updates of package version 1.2.
- <p>
-Please make sure you didn't miss any of these items in your upload:
-<list>
-<item> Make sure that your package really needs to go through
-<em>testing-proposed-updates</em>, and can't go through unstable;
-<item> Make sure that you included only the minimal amount of changes;
-<item> Make sure that you included an appropriate explanation in the
-changelog;
-<item> Make sure that you've written <em>testing</em> or
-<em>testing-proposed-updates</em> into your target distribution;
-<item> Make sure that you've built and tested your package in
-<em>testing</em>, not in <em>unstable</em>;
-<item> Make sure that your version number is higher than the version in
-<em>testing</em> and <em>testing-proposed-updates</em>, and lower than in
-<em>unstable</em>;
-<item> After uploading and successful build on all platforms, contact the
-release team at &email-debian-release; and ask them to approve your upload.
-</list>
-
-
- <sect1 id="faq">
- <heading>Frequently asked questions</heading>
- <p>
-
- <sect2 id="rc">
- <heading>What are release-critical bugs, and how do they get counted?</heading>
- <p>
-All bugs of some higher severities are by default considered
-release-critical; currently, these are critical, grave, and serious bugs.
- <p>
-Such bugs are presumed to have an impact on the chances that the package
-will be released with the stable release of Debian: in general, if a
-package has open release-critical bugs filed on it, it won't get into
-"testing", and consequently won't be released in "stable".
- <p>
-The unstable bug count are all release-critical bugs without either any
-release-tag (such as potato, woody) or with release-tag sid;
-also, only if they are neither fixed nor set to sarge-ignore.
-The "testing" bug count for a package is considered to be roughly
-the bug count of unstable count at the last point
-when the "testing" version equalled the "unstable" version.
- <p>
-This will change post-sarge, as soon as we have versions in the bug
-tracking system.
-
-
- <sect2>
- <heading>How could installing a package into "testing" possibly
- break other packages?</heading>
- <p>
-The structure of the distribution archives is such that they can only
-contain one version of a package; a package is defined by its name. So
-when the source package acmefoo is installed into "testing", along with
-its binary packages acme-foo-bin, acme-bar-bin, libacme-foo1 and
-libacme-foo-dev, the old version is removed.
- <p>
-However, the old version may have provided a binary package with an old
-soname of a library, such as libacme-foo0. Removing the old acmefoo will
-remove libacme-foo0, which will break any packages which depend on it.
- <p>
-Evidently, this mainly affects packages which provide changing sets of
-binary packages in different versions (in turn, mainly libraries).
-However, it will also affect packages upon which versioned dependencies
-have been declared of the ==, <=, or << varieties.
- <p>
-When the set of binary packages provided by a source package change in
-this way, all the packages that depended on the old binaries will have to
-be updated to depend on the new binaries instead. Because installing such
-a source package into "testing" breaks all the packages that depended on
-it in "testing", some care has to be taken now: all the depending packages
-must be updated and ready to be installed themselves so that they won't be
-broken, and, once everything is ready, manual intervention by the release
-manager or an assistant is normally required.
- <p>
-If you are having problems with complicated groups of packages like this,
-contact debian-devel or debian-release for help.
- </sect>
-
- <chapt id="best-pkging-practices">
- <heading>Best Packaging Practices</heading>
- <p>
-Debian's quality is largely due to the <url id="&url-debian-policy;"
-name="Debian Policy">, which defines explicit baseline requirements
-which all Debian packages must fulfill. Yet there is also a shared
-history of experience which goes beyond the Debian Policy, an
-accumulation of years of experience in packaging. Many very
-talented people have created great tools, tools which help you, the
-Debian maintainer, create and maintain excellent packages.
- <p>
-This chapter provides some best practices for Debian developers. All
-recommendations are merely that, and are not requirements or policy.
-These are just some subjective hints, advice and pointers collected
-from Debian developers. Feel free to pick and choose whatever works
-best for you.
-
- <sect id="bpp-debian-rules">
- <heading>Best practices for <file>debian/rules</file></heading>
- <p>
-The following recommendations apply to the <file>debian/rules</file>
-file. Since <file>debian/rules</file> controls the build process and
-selects the files which go into the package (directly or indirectly),
-it's usually the file maintainers spend the most time on.
-
- <sect1 id="helper-scripts">Helper scripts
- <p>
-The rationale for using helper scripts in <file>debian/rules</file> is
-that they let maintainers use and share common logic among many packages.
-Take for instance the question of installing menu entries: you need to
-put the file into <file>/usr/lib/menu</file> (or
-<file>/usr/lib/menu</file> for executable binary menufiles, if this is
-needed), and add commands to the maintainer scripts to register and
-unregister the menu entries. Since this is a very common thing for
-packages to do, why should each maintainer rewrite all this on their own,
-sometimes with bugs? Also, supposing the menu directory changed, every
-package would have to be changed.
- <p>
-Helper scripts take care of these issues. Assuming you comply with
-the conventions expected by the helper script, the helper takes care
-of all the details. Changes in policy can be made in the helper
-script; then packages just need to be rebuilt with the new version of
-the helper and no other changes.
- <p>
-<ref id="tools"> contains a couple of different helpers. The most
-common and best (in our opinion) helper system is
-<package>debhelper</package>. Previous helper systems, such as
-<package>debmake</package>, were "monolithic": you couldn't pick and
-choose which part of the helper you found useful, but had to use the
-helper to do everything. <package>debhelper</package>, however, is a
-number of separate little <prgn>dh_*</prgn> programs. For instance,
-<prgn>dh_installman</prgn> installs and compresses man pages,
-<prgn>dh_installmenu</prgn> installs menu files, and so on. Thus, it
-offers enough flexibility to be able to use the little helper scripts,
-where useful, in conjunction with hand-crafted commands in
-<file>debian/rules</file>.
- <p>
-You can get started with <package>debhelper</package> by reading
-<manref name="debhelper" section="1">, and looking at the examples
-that come with the package. <prgn>dh_make</prgn>, from the
-<package>dh-make</package> package (see <ref id="dh-make">), can be
-used to convert a "vanilla" source package to a
-<package>debhelper</package>ized package. This shortcut, though,
-should not convince you that you do not need to bother understanding
-the individual <prgn>dh_*</prgn> helpers. If you are going to use a
-helper, you do need to take the time to learn to use that helper, to
-learn its expectations and behavior.
- <p>
-Some people feel that vanilla <file>debian/rules</file> files are
-better, since you don't have to learn the intricacies of any helper
-system. This decision is completely up to you. Use what works for
-you. Many examples of vanilla <file>debian/rules</file> files are
-available at <url id="&url-rules-files;">.
-
-
- <sect1 id="multiple-patches">
- <heading>Separating your patches into multiple files</heading>
- <p>
-Big, complex packages may have many bugs that you need to deal with.
-If you correct a number of bugs directly in the source, and you're not
-careful, it can get hard to differentiate the various patches that you
-applied. It can get quite messy when you have to update the package
-to a new upstream version which integrates some of the fixes (but not
-all). You can't take the total set of diffs (e.g., from
-<file>.diff.gz</file>) and work out which patch sets to back out as a
-unit as bugs are fixed upstream.
- <p>
-Unfortunately, the packaging system as such currently doesn't provide for
-separating the patches into several files. Nevertheless, there are ways to
-separate patches: the patch files are shipped within the Debian patch file
-(<file>.diff.gz</file>), usually within the <file>debian/</file> directory.
-The only difference is that they aren't applied immediately by dpkg-source,
-but by the <tt>build</tt> rule of <file>debian/rules</file>. Conversely,
-they are reverted in the <tt>clean</tt> rule.
- <p>
-<prgn>dbs</prgn> is one of the more popular approaches to this. It does all
-of the above, and provides a facility for creating new and updating old
-patches. See the package <package>dbs</package> for more information and
-<package>hello-dbs</package> for an example.
- <p>
-<prgn>dpatch</prgn> also provides these facilities, but it's intended to be
-even easier to use. See the package <package>dpatch</package> for
-documentation and examples (in <file>/usr/share/doc/dpatch</file>).
-
-
- <sect1 id="multiple-binary">Multiple binary packages
- <p>
-A single source package will often build several binary packages,
-either to provide several flavors of the same software (e.g.,
-the <package>vim</package> source package) or to make several small
-packages instead of a big one (e.g., so the user can install only the
-subset needed, and thus save some disk space).
- <p>
-The second case can be easily managed in <file>debian/rules</file>.
-You just need to move the appropriate files from the build directory
-into the package's temporary trees. You can do this using
-<prgn>install</prgn> or <prgn>dh_install</prgn>
-from <package>debhelper</package>. Be sure to check the different
-permutations of the various packages, ensuring that you have the
-inter-package dependencies set right in <file>debian/control</file>.
- <p>
-The first case is a bit more difficult since it involves multiple
-recompiles of the same software but with different configuration
-options. The <package>vim</package> source package is an example of how to
-manage this using an hand-crafted <file>debian/rules</file> file.
-
-<!-- &FIXME; Find a good debhelper example with multiple configure/make
- cycles -->
- </sect1>
- </sect>
-
-
- <sect id="bpp-debian-control">
- <heading>Best practices for <file>debian/control</file></heading>
- <p>
-The following practices are relevant to the
-<file>debian/control</file> file. They supplement the <url
-id="&url-debian-policy;ch-binary.html#s-descriptions"
-name="Policy on package descriptions">.
- <p>
-The description of the package, as defined by the corresponding field
-in the <file>control</file> file, contains both the package synopsis
-and the long description for the package. <ref id="bpp-desc-basics">
-describes common guidelines for both parts of the package description.
-Following that, <ref id="bpp-pkg-synopsis"> provides guidelines
-specific to the synopsis, and <ref id="bpp-pkg-desc"> contains
-guidelines specific to the description.
-
- <sect1 id="bpp-desc-basics">
- <heading>General guidelines for package descriptions</heading>
- <p>
-The package description should be written for the average likely user,
-the average person who will use and benefit from the package. For
-instance, development packages are for developers, and can be
-technical in their language. More general-purpose applications, such
-as editors, should be written for a less technical user.
- <p>
-Our review of package descriptions lead us to conclude that most
-package descriptions are technical, that is, are not written to make
-sense for non-technical users. Unless your package really is only for
-technical users, this is a problem.
- <p>
-How do you write for non-technical users? Avoid jargon. Avoid
-referring to other applications or frameworks that the user might not
-be familiar with — "GNOME" or "KDE" is fine, since users are
-probably familiar with these terms, but "GTK+" is
-probably not. Try not to assume any knowledge at all. If you must
-use technical terms, introduce them.
- <p>
-Be objective. Package descriptions are not the place for advocating
-your package, no matter how much you love it. Remember that the
-reader may not care about the same things you care about.
- <p>
-References to the names of any other software packages, protocol names,
-standards, or specifications should use their canonical forms, if one
-exists. For example, use "X Window System", "X11", or "X"; not "X
-Windows", "X-Windows", or "X Window". Use "GTK+", not "GTK" or "gtk".
-Use "GNOME", not "Gnome". Use "PostScript", not "Postscript" or
-"postscript".
- <p>
-If you are having problems writing your description, you may wish to
-send it along to &email-debian-l10n-english; and request feedback.
- </sect1>
-
-
- <sect1 id="bpp-pkg-synopsis">
- <heading>The package synopsis, or short description</heading>
- <p>
-The synopsis line (the short description) should be concise. It
-must not repeat the package's name (this is policy).
- <p>
-It's a good idea to think of the synopsis as an appositive clause, not
-a full sentence. An appositive clause is defined in WordNet as a
-grammatical relation between a word and a noun phrase that follows,
-e.g., "Rudolph the red-nosed reindeer". The appositive clause here is
-"red-nosed reindeer". Since the synopsis is a clause, rather than a
-full sentence, we recommend that it neither start with a capital nor
-end with a full stop (period). It should also not begin with an
-article, either definite ("the") or indefinite ("a" or "an").
- <p>
-It might help to imagine that the synopsis is combined with the
-package name in the following way:
-
-<example><var>package-name</var> is a <var>synopsis</var>.</example>
-
-Alternatively, it might make sense to think of it as
-
-<example><var>package-name</var> is <var>synopsis</var>.</example>
-
-or, if the package name itself is a plural (such as
-"developers-tools")
-
-<example><var>package-name</var> are <var>synopsis</var>.</example>
-
-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 sentence.
- </sect1>
-
- <sect1 id="bpp-pkg-desc">
- <heading>The long description</heading>
- <p>
-The long description is the primary information available to the user
-about a package before they install it. It should provide all the
-information needed to let the user decide whether to install the
-package. Assume that the user has already read the package synopsis.
- <p>
-The long description should consist of full and complete sentences.
- <p>
-The first paragraph of the long description should answer the
-following questions: what does the package do? what task does it help
-the user accomplish? It is important to describe this in a
-non-technical way, unless of course the audience for the package is
-necessarily technical.
- <p>
-The following paragraphs should answer the following questions: Why do
-I as a user need this package? What other features does the package
-have? What outstanding features and deficiencies are there compared
-to other packages (e.g., "if you need X, use Y instead")? Is this
-package related to other packages in some way that is not handled by
-the package manager (e.g., "this is the client for the foo server")?
- <p>
-Be careful to avoid spelling and grammar mistakes. Ensure that you
-spell-check it. Both <prgn>ispell</prgn> and <prgn>aspell</prgn>
-have special modes for checking <file>debian/control</file> files:
-
-<example>ispell -d american -g debian/control</example>
-<example>aspell -d en -D -c debian/control</example>
- <p>
-Users usually expect these questions to be answered in the package
-description:
- <list>
- <item>
-What does the package do? If it is an add-on to another package,
-then the short description of the package we are an add-on to
-should be put in here.
- <item>
-Why should I want this package? This is related to the above,
-but not the same (this is a mail user agent; this is cool, fast,
-interfaces with PGP and LDAP and IMAP, has features X, Y, and Z).
- <item>
-If this package should not be installed directly, but is pulled in
-by another package, this should be mentioned.
- <item>
-If the package is experimental, or there are other reasons it
-should not be used, if there are other packages that should be
-used instead, it should be here as well.
- <item>
-How is this package different from the competition? Is it a better
-implementation? more features? different features? Why should I
-choose this package.
-<!-- FIXME: what's this?
-(the second questions is about the class of packages, and
-this about this particular package, if you have information related to both).
--->
- </list>
-
- </sect1>
-
-
- <sect1 id="bpp-upstream-info">
- <heading>Upstream home page</heading>
- <p>
-We recommend that you add the URL for the package's home page in the
-<tt>Homepage</tt> field of the <tt>Source</tt> section in
-<file>debian/control</file>. Adding this information in the package
-description itself is considered deprecated.
- </sect1>
-
- <sect1 id="bpp-vcs">
- <heading>Version Control System location</heading>
- <p>
-There are additional fields for the location of the Version Control System
-in <file>debian/control</file>.
- <sect2><heading>Vcs-Browser</heading>
- <p>
-Value of this field should be a <tt>http://</tt> URL pointing to a
-web-browsable copy of the Version Control System repository used to
-maintain the given package, if available.
- <p>
-The information is meant to be useful for the final user, willing to
-browse the latest work done on the package (e.g. when looking for the
-patch fixing a bug tagged as <tt>pending</tt> in the bug tracking
-system).
- <sect2><heading>Vcs-*</heading>
- <p>
-Value of this field should be a string identifying unequivocally the
-location of the Version Control System repository used to maintain the
-given package, if available. <tt>*</tt> identify the Version Control
-System; currently the following systems are supported by the package
-tracking system: <tt>arch</tt>, <tt>bzr</tt> (Bazaar), <tt>cvs</tt>,
-<tt>darcs</tt>, <tt>git</tt>, <tt>hg</tt> (Mercurial), <tt>mtn</tt>
-(Monotone), <tt>svn</tt> (Subversion). It is allowed to specify different
-VCS fields for the same package: they will all be shown in the PTS web
-interface.
- <p>
-The information is meant to be useful for a user knowledgeable in the
-given Version Control System and willing to build the current version of
-a package from the VCS sources. Other uses of this information might
-include automatic building of the latest VCS version of the given
-package. To this end the location pointed to by the field should better
-be version agnostic and point to the main branch (for VCSs supporting
-such a concept). Also, the location pointed to should be accessible to
-the final user; fulfilling this requirement might imply pointing to an
-anonymous access of the repository instead of pointing to an
-SSH-accessible version of the same.
- <p>
-In the following example, an instance of the field for a Subversion
-repository of the <package>vim</package> package is shown. Note how the
-URL is in the <tt>svn://</tt> scheme (instead of <tt>svn+ssh://</tt>) and
-how it points to the <file>trunk/</file> branch. The use of the
-<tt>Vcs-Browser</tt> and <tt>Homepage</tt> fields described above is
-also shown.
-<example>
- Source: vim
- Section: editors
- Priority: optional
- <snip>
- Vcs-Svn: svn://svn.debian.org/svn/pkg-vim/trunk/packages/vim
- Vcs-Browser: http://svn.debian.org/wsvn/pkg-vim/trunk/packages/vim
- Homepage: http://www.vim.org
-</example>
- </sect1>
- </sect>
-
-
- <sect id="bpp-debian-changelog">
- <heading>Best practices for <file>debian/changelog</file></heading>
- <p>
-The following practices supplement the <url name="Policy on changelog
-files" id="&url-debian-policy;ch-docs.html#s-changelogs">.</p>
-
- <sect1 id="bpp-changelog-do">
- <heading>Writing useful changelog entries</heading>
- <p>
-The changelog entry for a package revision documents changes in that
-revision, and only them. Concentrate on describing significant and
-user-visible changes that were made since the last version.
- <p>
-Focus on <em>what</em> was changed — who, how and when are
-usually less important. Having said that, remember to politely
-attribute people who have provided notable help in making the package
-(e.g., those who have sent in patches).
- <p>
-There's no need to elaborate the trivial and obvious changes. You can
-also aggregate several changes in one entry. On the other hand, don't
-be overly terse if you have undertaken a major change. Be especially
-clear if there are changes that affect the behaviour of the program.
-For further explanations, use the <file>README.Debian</file> file.
- <p>
-Use common English so that the majority of readers can comprehend it.
-Avoid abbreviations, "tech-speak" and jargon when explaining changes
-that close bugs, especially for bugs filed by users that did not
-strike you as particularly technically savvy. Be polite, don't swear.
- <p>
-It is sometimes desirable to prefix changelog entries with the names
-of the files that were changed. However, there's no need to
-explicitly list each and every last one of the changed files,
-especially if the change was small or repetitive. You may use
-wildcards.
- <p>
-When referring to bugs, don't assume anything. Say what the problem
-was, how it was fixed, and append the "closes: #nnnnn" string. See
-<ref id="upload-bugfix"> for more information.
-
-
- <sect1 id="bpp-changelog-misconceptions">
- <heading>Common misconceptions about changelog entries</heading>
- <p>
-The changelog entries should <strong>not</strong> document generic
-packaging issues ("Hey, if you're looking for foo.conf, it's in
-/etc/blah/."), since administrators and users are supposed to be at
-least remotely acquainted with how such things are generally arranged
-on Debian systems. Do, however, mention if you change the location of
-a configuration file.
- <p>
-The only bugs closed with a changelog entry should be those that are
-actually fixed in the same package revision. Closing unrelated bugs
-in the changelog is bad practice. See <ref id="upload-bugfix">.
- <p>
-The changelog entries should <strong>not</strong> be used for random
-discussion with bug reporters ("I don't see segfaults when starting
-foo with option bar; send in more info"), general statements on life,
-the universe and everything ("sorry this upload took me so long, but I
-caught the flu"), or pleas for help ("the bug list on this package is
-huge, please lend me a hand"). Such things usually won't be noticed
-by their target audience, but may annoy people who wish to read
-information about actual changes in the package. See <ref
-id="bug-answering"> for more information on how to use the bug
-tracking system.
- <p>
-It is an old tradition to acknowledge bugs fixed in non-maintainer
-uploads in the first changelog entry of the proper maintainer upload.
-As we have version tracking now,
-it is enough to keep the NMUed changelog entries and
-just mention this fact in your own changelog entry.
- </sect1>
-
- <sect1 id="bpp-changelog-errors">
- <heading>Common errors in changelog entries</heading>
- <p>
-The following examples demonstrate some common errors or examples of
-bad style in changelog entries.
-
- <p>
-<example>
- * Fixed all outstanding bugs.
-</example>
-This doesn't tell readers anything too useful, obviously.
-
- <p>
-<example>
- * Applied patch from Jane Random.
-</example>
-What was the patch about?
-
- <p>
-<example>
- * Late night install target overhaul.
-</example>
-Overhaul which accomplished what? Is the mention of late night
-supposed to remind us that we shouldn't trust that code?
-
- <p>
-<example>
- * Fix vsync FU w/ ancient CRTs.
-</example>
-Too many acronyms, and it's not overly clear what the, uh, fsckup (oops,
-a curse word!) was actually about, or how it was fixed.
-
- <p>
-<example>
- * This is not a bug, closes: #nnnnnn.
-</example>
-First of all, there's absolutely no need to upload the package to
-convey this information; instead, use the bug tracking system.
-Secondly, there's no explanation as to why the report is not a bug.
-
- <p>
-<example>
- * Has been fixed for ages, but I forgot to close; closes: #54321.
-</example>
-If for some reason you didn't mention the bug number in a previous changelog
-entry, there's no problem, just close the bug normally in the BTS. There's
-no need to touch the changelog file, presuming the description of the fix is
-already in (this applies to the fixes by the upstream authors/maintainers as
-well, you don't have to track bugs that they fixed ages ago in your
-changelog).
-
- <p>
-<example>
- * Closes: #12345, #12346, #15432
-</example>
-Where's the description? If you can't think of a descriptive message,
-start by inserting the title of each different bug.
- </sect1>
-
- <sect1 id="bpp-news-debian">
- <heading>Supplementing changelogs with NEWS.Debian files</heading>
- <p>
-Important news about changes in a package can also be put in NEWS.Debian
-files. The news will be displayed by tools like apt-listchanges, before
-all the rest of the changelogs. This is the preferred means to let the user
-know about significant changes in a package. It is better than using
-debconf notes since it is less annoying and the user can go back and refer
-to the NEWS.Debian file after the install. And it's better than listing
-major changes in README.Debian, since the user can easily miss such notes.
- <p>
-The file format is the same as a debian changelog file, but leave off
-the asterisks and describe each news item with a full paragraph when
-necessary rather than the more concise summaries that would go in a
-changelog. It's a good idea to run your file through dpkg-parsechangelog to
-check its formatting as it will not be automatically checked during build
-as the changelog is. Here is an example of a real NEWS.Debian file:
-<example>
-cron (3.0pl1-74) unstable; urgency=low
-
- The checksecurity script is no longer included with the cron package:
- it now has its own package, "checksecurity". If you liked the
- functionality provided with that script, please install the new
- package.
-
- -- Steve Greenland <stevegr@debian.org> Sat, 6 Sep 2003 17:15:03 -0500
-</example>
- <p>
-The NEWS.Debian file is installed as
-/usr/share/doc/<package>/NEWS.Debian.gz. It is compressed, and
-always has that name even in Debian native packages. If you use debhelper,
-dh_installchangelogs will install debian/NEWS files for you.
- <p>
-Unlike changelog files, you need not update NEWS.Debian files with every
-release. Only update them if you have something particularly newsworthy
-that user should know about. If you have no news at all, there's no need
-to ship a NEWS.Debian file in your package. No news is good news!
- </sect>
-
-<!--
- <sect1 id="pkg-mgmt-cvs">Managing a package with CVS
- <p>
- &FIXME; presentation of cvs-buildpackage, updating sources
- via CVS (debian/rules refresh).
- <url id="http://www.debian.org/devel/cvs_packages">
--->
-
-
- <sect id="bpp-debian-maint-scripts">
- <heading>Best practices for maintainer scripts</heading>
- <p>
-Maintainer scripts include the files <file>debian/postinst</file>,
-<file>debian/preinst</file>, <file>debian/prerm</file> and
-<file>debian/postrm</file>. These scripts take care of any package
-installation or deinstallation setup which isn't handled merely by the
-creation or removal of files and directories. The following
-instructions supplement the <url id="&url-debian-policy;" name="Debian
-Policy">.
- <p>
-Maintainer scripts must be idempotent. That means that you need to
-make sure nothing bad will happen if the script is called twice where
-it would usually be called once.
- <p>
-Standard input and output may be redirected (e.g. into pipes) for
-logging purposes, so don't rely on them being a tty.
- <p>
-All prompting or interactive configuration should be kept to a
-minimum. When it is necessary, you should use the
-<package>debconf</package> package for the interface. Remember that
-prompting in any case can only be in the <tt>configure</tt> stage of
-the <file>postinst</file> script.
- <p>
-Keep the maintainer scripts as simple as possible. We suggest you use
-pure POSIX shell scripts. Remember, if you do need any bash features,
-the maintainer script must have a bash shebang line. POSIX shell or
-Bash are preferred to Perl, since they enable
-<package>debhelper</package> to easily add bits to the scripts.
- <p>
-If you change your maintainer scripts, be sure to test package
-removal, double installation, and purging. Be sure that a purged
-package is completely gone, that is, it must remove any files created,
-directly or indirectly, in any maintainer script.
- <p>
-If you need to check for the existence of a command, you should use
-something like
-<example>if [ -x /usr/sbin/install-docs ]; then ...</example>
-
-If you don't wish to hard-code the path of a command in your
-maintainer script, the following POSIX-compliant shell function may
-help:
-
-&example-pathfind;
-
-You can use this function to search <tt>$PATH</tt> for a command name,
-passed as an argument. It returns true (zero) if the command was
-found, and false if not. This is really the most portable way, since
-<tt>command -v</tt>, <prgn>type</prgn>, and <prgn>which</prgn> are not
-POSIX.
- <p>
-While <prgn>which</prgn> is an acceptable alternative, since
-it is from the required <package>debianutils</package> package, it's
-not on the root partition. That is, it's in <file>/usr/bin</file> rather
-than <file>/bin</file>, so one can't use it in scripts which are run
-before the <file>/usr</file> partition is mounted. Most scripts won't have
-this problem, though.
- </sect>
-
-
- <sect id="bpp-config-mgmt">
- <heading>Configuration management with <package>debconf</package></heading>
- <p>
-<package>Debconf</package> is a configuration management system which
-can be used by all the various packaging scripts
-(<file>postinst</file> mainly) to request feedback from the user
-concerning how to configure the package. Direct user interactions must
-now be avoided in favor of <package>debconf</package>
-interaction. This will enable non-interactive installations in the
-future.
- <p>
-Debconf is a great tool but it is often poorly used. Many common mistakes
-are listed in the <manref name="debconf-devel" section="7"> man page.
-It is something that you must read if you decide to use debconf.
-Also, we document some best practices here.
- <p>
-These guidelines include some writing style and typography
-recommendations, general considerations about debconf usage as well as
-more specific recommendations for some parts of the distribution (the
-installation system for instance).
-
- <sect1>Do not abuse debconf
- <p>
-Since debconf appeared in Debian, it has been widely abused and
-several criticisms received by the Debian distribution come from
-debconf abuse with the need of answering a wide bunch of questions
-before getting any little thing installed.
- <p>
-Keep usage notes to what they belong: the NEWS.Debian, or
-README.Debian file. Only use notes for important notes which may
-directly affect the package usability. Remember that notes will always
-block the install until confirmed or bother the user by email.
- <p>
-Carefully choose the questions priorities in maintainer scripts. See
-<manref name="debconf-devel" section="7"> for details about priorities.
-Most questions should use medium and low priorities.
-
- <sect1>General recommendations for authors and translators
- <p>
- <sect2>Write correct English
- <p>
-Most Debian package maintainers are not native English speakers. So,
-writing properly phrased templates may not be easy for them.
- <p>
-Please use (and abuse) &email-debian-l10n-english; mailing
-list. Have your templates proofread.
- <p>
-Badly written templates give a poor image of your package, of your
-work...or even of Debian itself.
- <p>
-Avoid technical jargon as much as possible. If some terms sound common
-to you, they may be impossible to understand for others. If you cannot
-avoid them, try to explain them (use the extended description). When
-doing so, try to balance between verbosity and simplicity.
-
- <sect2>Be kind to translators
- <p>
-Debconf templates may be translated. Debconf, along with its sister
-package <prgn>po-debconf</prgn> offers a simple framework for getting
-templates translated by translation teams or even individuals.
- <p>
-Please use gettext-based templates. Install <package>po-debconf</package>
-on your development system and read its documentation ("man po-debconf" is
-a good start).
- <p>
-Avoid changing templates too often. Changing templates text induces
-more work to translators which will get their translation "fuzzied". If
-you plan changes to your original templates, please contact
-translators. Most active translators are very responsive and getting
-their work included along with your modified templates will save you
-additional uploads. If you use gettext-based templates, the
-translator's name and e-mail addresses are mentioned in the po files
-headers.
- <p>
-The use of the <prgn>podebconf-report-po</prgn> from the
-po-debconf package is highly recommended to warn translators which
-have incomplete translations and request them for updates.
- <p>
-If in doubt, you may also contact the translation team for a given
-language (debian-l10n-xxxxx@lists.debian.org), or the
-&email-debian-i18n; mailing list.
- <p>
-Calls for translations posted to
-&email-debian-i18n; with the <file>debian/po/templates.pot</file> file
-attached or referenced in a URL are encouraged. Be sure to mentions in
-these calls for new translations which languages you have existing
-translations for, in order to avoid duplicate work.
- <sect2>Unfuzzy complete translations when correcting typos and spelling
- <p>
-
-When the text of a debconf template is corrected and you are
-<strong>sure</strong> that the change does <strong>not</strong> affect
-translations, please be kind to translators and unfuzzy their
-translations.
- <p>
-If you don't do so, the whole template will not be translated as long
-as a translator will send you an update.
- <p>
-To <strong>unfuzzy</strong> translations, you can proceed the following way:
- <enumlist>
- <item>
-Put all incomplete PO files out of the way. You can check the
-completeness by using (needs the <package>gettext</package> package
-installed):
-<example>for i in debian/po/*po; do echo -n $i: ; msgfmt -o /dev/null
---statistics $i; done</example>
- <item>
-move all files which report either fuzzy strings to a temporary
-place. Files which report no fuzzy strings (only translated and
-untranslated) will be kept in place.
- <item>
-now <strong>and now only</strong>, modify the template for the typos
-and check again that translation are not impacted (typos, spelling
-errors, sometimes typographical corrections are usually OK)
- <item>
-run <prgn>debconf-updatepo</prgn>. This will fuzzy all strings
-you modified in translations. You can see this by running the above
-again
- <item>
-use the following command:
-<example>for i in debian/po/*po; do msgattrib --output-file=$i --clear-fuzzy $i; done</example>
- <item>
-move back to debian/po the files which showed fuzzy strings in the first step
- <item>
-run <prgn>debconf-updatepo</prgn> again
- </enumlist>
- <sect2>Do not make assumptions about interfaces
- <p>
-Templates text should not make reference to widgets belonging to some
-debconf interfaces. Sentences like "If you answer Yes..." have no
-meaning for users of graphical interfaces which use checkboxes for
-boolean questions.
- <p>
-String templates should also avoid mentioning the default values in
-their description. First, because this is redundant with the values
-seen by the users. Also, because these default values may be different
-from the maintainer choices (for instance, when the debconf database
-was preseeded).
- <p>
-More generally speaking, try to avoid referring to user actions.
-Just give facts.
-
- <sect2>Do not use first person
- <p>
-You should avoid the use of first person ("I will do this..." or "We
-recommend..."). The computer is not a person and the Debconf templates
-do not speak for the Debian developers. You should use neutral
-construction. Those of you who already
-wrote scientific publications, just write your templates like you
-would write a scientific paper.
-However, try using action voice if still possible, like
-"Enable this if ..."
-instead of
-"This can be enabled if ...".
-
- <sect2>Be gender neutral
- <p>
-The world is made of men and women. Please use gender-neutral
-constructions in your writing.
-
-
- <sect1>Templates fields definition
- <p>
-This part gives some information which is mostly taken from the
-<manref name="debconf-devel" section="7"> manual page.
-
- <sect2>Type
- <p>
-
- <sect3>string:
- <p>
-Results in a free-form input field that the user can type any string into.
-
- <sect3>password:
- <p>
-Prompts the user for a password. Use this with caution; be aware that
-the password the user enters will be written to debconf's
-database. You should probably clean that value out of the database as
-soon as is possible.
-
- <sect3>boolean:
- <p>
-A true/false choice. Remember: true/false, <strong>not yes/no</strong>...
-
- <sect3>select:
- <p>
-A choice between one of a number of values. The choices must be
-specified in a field named 'Choices'. Separate the possible values
-with commas and spaces, like this: Choices: yes, no, maybe
-
- <sect3>multiselect:
- <p>
-Like the select data type, except the user can choose any number of
-
- items from the choices list (or chose none of them).
-
- <sect3>note:
- <p>
-Rather than being a question per se, this datatype indicates a note
-that can be displayed to the user. It should be used only for
-important notes that the user really should see, since debconf will go
-to great pains to make sure the user sees it; halting the install for
-them to press a key, and even mailing the note to them in some
-cases.
-
- <sect3>text:
- <p>
-This type is now considered obsolete: don't use it.
-
- <sect3>error:
- <p>
-This type is designed to handle error messages. It is mostly similar to
-the "note" type. Frontends may present it differently (for instance,
-the dialog frontend of cdebconf draws a red screen instead of the
-usual blue one).
- <p>
-It is recommended to use this type for any message that needs user
-attention for a correction of any kind.
-
-
- <sect2>Description: short and extended description
- <p>
-Template descriptions have two parts: short and extended. The short
-description is in the "Description:" line of the template.
- <p>
-The short description should be kept short (50 characters or so) so
-that it may be accomodated by most debconf interfaces. Keeping it
-short also helps translators, as usually translations tend to end up
-being longer than the original.
- <p>
-The short description should be able to stand on its own. Some
-interfaces do not show the long description by default, or only if the
-user explicitely asks for it or even do not show it at all. Avoid
-things like "What do you want to do?"
- <p>
-The short description does not necessarily have to be a full
-sentence. This is part of the "keep it short and efficient"
-recommendation.
- <p>
-The extended description should not repeat the short description word
-for word. If you can't think up a long description, then first, think
-some more. Post to debian-devel. Ask for help. Take a writing class!
-That extended description is important. If after all that you still
-can't come up with anything, leave it blank.
- <p>
-The extended description should use complete sentences. Paragraphs
-should be kept short for improved readability. Do not mix two ideas
-in the same paragraph but rather use another paragraph.
- <p>
-Don't be too verbose. User tend to ignore too long screens.
-20 lines are by experience a border you shouldn't cross,
-because that means that in the classical dialog interface,
-people will need to scroll, and lot of people just don't do that.
- <p>
-The extended description should <strong>never</strong> include a question.
- <p>
-For specific rules depending on templates type (string, boolean,
-etc.), please read below.
-
- <sect2>Choices
- <p>
-This field should be used for Select and Multiselect types. It
-contains the possible choices which will be presented to users. These
-choices should be separated by commas.
-
-
- <sect2>Default
- <p>
-This field is optional. It contains the default answer for string,
-select and multiselect templates. For multiselect templates, it may
-contain a comma-separated list of choices.
-
- <sect1>Templates fields specific style guide
- <p>
-
- <sect2>Type field
- <p>
-No specific indication except: use the appropriate type by referring
-to the previous section.
-
- <sect2>Description field
- <p>
-Below are specific instructions for properly writing the Description
-(short and extended) depending on the template type.
-
- <sect3>String/password templates
- <p>
-<list>
-<item> The short description is a prompt and <strong>not</strong> a title.
- Avoid question style prompts ("IP Address?") in favour of "opened"
- prompts ("IP address:"). The use of colons is recommended.
-
-<item> The extended description is a complement to the short description.
- In the extended part, explain what is being asked, rather than ask
- the same question again using longer words. Use complete sentences.
- Terse writing style is strongly discouraged.
-</list>
-
- <sect3>Boolean templates
- <p>
-<list>
-<item> The short description should be phrased in the form of a question
- which should be kept short and should generally end with a question
- mark. Terse writing style is permitted and even encouraged if the
- question is rather long (remember that translations are often longer
- than original versions)
-
-<item> Again, please avoid referring to specific interface widgets. A common
- mistake for such templates is "if you answer Yes"-type
- constructions.
-</list>
-
- <sect3>Select/Multiselect
- <p>
-<list>
-<item> The short description is a prompt and <strong>not</strong> a title.
- Do <strong>not</strong> use useless
- "Please choose..." constructions. Users are clever enough to figure
- out they have to choose something...:)
-
-<item> The extended description will complete the short description. It may
- refer to the available choices. It may also mention that the user
- may choose more than one of the available choices, if the template
- is a multiselect one (although the interface often makes this
- clear).
-</list>
-
- <sect3>Notes
- <p>
-<list>
-<item> The short description should be considered to be a *title*.
-
-<item> The extended description is what will be displayed as a more detailed
- explanation of the note. Phrases, no terse writing style.
-
-<item> <strong>Do not abuse debconf.</strong>
- Notes are the most common way to abuse
- debconf. As written in debconf-devel manual page: it's best to use them
- only for warning about very serious problems. The NEWS.Debian or
- README.Debian files are the appropriate location for a lot of notes.
- If, by reading this, you consider converting your Note type templates
- to entries in NEWS/Debian or README.Debian, plus consider keeping
- existing translations for the future.
-</list>
-
-
- <sect2>Choices field
- <p>
-If the Choices are likely to change often, please consider using the
-"__Choices" trick. This will split each individual choice into a
-single string, which will considerably help translators for doing
-their work.
-
- <sect2>Default field
- <p>
-If the default value, for a "select" template, is likely to vary
-depending on the user language (for instance, if the choice is a
-language choice), please use the "_DefaultChoice" trick.
- <p>
-This special field allow translators to put the most appropriate
-choice according to their own language. It will become the default
-choice when their language is used while your own mentioned Default
-Choice will be used chan using English.
- <p>
-Example, taken from the geneweb package templates:
-<example>
-Template: geneweb/lang
-Type: select
-__Choices: Afrikaans (af), Bulgarian (bg), Catalan (ca), Chinese (zh), Czech (cs), Danish (da), Dutch (nl), English (en), Esperanto (eo), Estonian (et), Finnish (fi), French (fr), German (de), Hebrew (he), Icelandic (is), Italian (it), Latvian (lv), Norwegian (no), Polish (pl), Portuguese (pt), Romanian (ro), Russian (ru), Spanish (es), Swedish (sv)
-# This is the default choice. Translators may put their own language here
-# instead of the default.
-# WARNING : you MUST use the ENGLISH FORM of your language
-# For instance, the french translator will need to put "French (fr)" here.
-_DefaultChoice: English (en)[ translators, please see comment in PO files]
-_Description: Geneweb default language:
-</example>
- <p>
-Note the use of brackets which allow internal comments in debconf
-fields. Also note the use of comments which will show up in files the
-translators will work with.
- <p>
-The comments are needed as the DefaultChoice trick is a bit
-confusing: the translators may put their own choice
-
- <sect2>Default field
- <p>
-Do NOT use empty default field. If you don't want to use default
-values, do not use Default at all.
- <p>
-If you use po-debconf (and you <strong>should</strong>, see 2.2), consider
-making this field translatable, if you think it may be translated.
- <p>
-If the default value may vary depending on language/country (for
-instance the default value for a language choice), consider using the
-special "_DefaultChoice" type documented in <manref name="po-debconf"
-section="7">).
- </sect>
-
-
- <sect id="bpp-i18n">
- <heading>Internationalization</heading>
-
- <sect1 id="bpp-i18n-debconf">
- <heading>Handling debconf translations</heading>
- <p>
-Like porters, translators have a difficult task. They work on many
-packages and must collaborate with many different
-maintainers. Moreover, most of the time, they are not native English
-speakers, so you may need to be particularly patient with them.
- <p>
-The goal of <package>debconf</package> was to make packages
-configuration easier for maintainers and for users. Originally,
-translation of debconf templates was handled with
-<prgn>debconf-mergetemplate</prgn>. However, that technique is now
-deprecated; the best way to accomplish <package>debconf</package>
-internationalization is by using the <package>po-debconf</package>
-package. This method is easier both for maintainer and translators;
-transition scripts are provided.
- <p>
-Using <package>po-debconf</package>, the translation is stored in
-<file>po</file> files (drawing from <prgn>gettext</prgn> translation
-techniques). Special template files contain the original messages and
-mark which fields are translatable. When you change the value of a
-translatable field, by calling <prgn>debconf-updatepo</prgn>, the
-translation is marked as needing attention from the translators. Then,
-at build time, the <prgn>dh_installdebconf</prgn> program takes care
-of all the needed magic to add the template along with the up-to-date
-translations into the binary packages. Refer to the <manref
-name="po-debconf" section="7"> manual page for details.
- </sect1>
-
- <sect1 id="bpp-i18n-docs">
- <heading>Internationalized documentation</heading>
- <p>
-Internationalizing documentation is crucial for users, but a lot of
-labor. There's no way to eliminate all that work, but you can make things
-easier for translators.
- <p>
-If you maintain documentation of any size, its easier for translators
-if they have access to a source control system. That lets translators
-see the differences between two versions of the documentation, so, for
-instance, they can see what needs to be retranslated. It is
-recommended that the translated documentation maintain a note about
-what source control revision the translation is based on. An
-interesting system is provided by <url id="&url-i18n-doc-check;"
-name="doc-check"> in the <package>boot-floppies</package> package,
-which shows an overview of the translation status for any given
-language, using structured comments for the current revision of the
-file to be translated and, for a translated file, the revision of the
-original file the translation is based on. You might wish to adapt
-and provide that in your CVS area.
- <p>
-If you maintain XML or SGML documentation, we suggest that you isolate
-any language-independent information and define those as entities in a
-separate file which is included by all the different
-translations. This makes it much easier, for instance, to keep URLs
-up to date across multiple files.
- </sect1>
- </sect>
-
- <sect id="bpp-common-situations">
- <heading>Common packaging situations</heading>
-
-<!--
- <sect1 id="bpp-kernel">Kernel modules/patches
- <p>
- &FIXME; Heavy use of kernel-package. provide files in
- /etc/modutils/ for module configuration.
--->
-
- <sect1 id="bpp-autotools">
- <heading>Packages using
- <prgn>autoconf</prgn>/<prgn>automake</prgn></heading>
- <p>
-Keeping <prgn>autoconf</prgn>'s <file>config.sub</file> and
-<file>config.guess</file> files up to date is critical for porters,
-especially on more volatile architectures. Some very good packaging
-practices for any package using <prgn>autoconf</prgn> and/or
-<prgn>automake</prgn> have been synthesized in
-&file-bpp-autotools; from the <package>autotools-dev</package>
-package. You're strongly encouraged to read this file and
-to follow the given recommendations.
-
-
- <sect1 id="bpp-libraries">Libraries
- <p>
-Libraries are always difficult to package for various reasons. The policy
-imposes many constraints to ease their maintenance and to make sure
-upgrades are as simple as possible when a new upstream version comes out.
-Breakage in a library can result in dozens of dependent packages
-breaking.
- <p>
-Good practices for library packaging have been grouped in
-<url id="&url-libpkg-guide;" name="the library packaging guide">.
-
-
- <sect1 id="bpp-docs">Documentation
- <p>
-Be sure to follow the <url id="&url-debian-policy;ch-docs.html"
- name="Policy on documentation">.</p>
- <p>
-If your package contains documentation built from XML or SGML, we
-recommend you not ship the XML or SGML source in the binary
-package(s). If users want the source of the documentation, they
-should retrieve the source package.</p>
- <p>
-Policy specifies that documentation should be shipped in HTML format.
-We also recommend shipping documentation in PDF and plain text format if
-convenient and if output of reasonable quality is possible. However, it
-is generally not appropriate to ship plain text versions of documentation
-whose source format is HTML.</p>
- <p>
-Major shipped manuals should register themselves with
-<package>doc-base</package> on installation. See the
-<package>doc-base</package> package documentation for more
-information.</p>
-
-
- <sect1 id="bpp-other">Specific types of packages
- <p>
-Several specific types of packages have special sub-policies and
-corresponding packaging rules and practices:
-<list>
- <item>
-Perl related packages have a <url name="Perl policy"
-id="&url-perl-policy;">, some examples of packages following that
-policy are <package>libdbd-pg-perl</package> (binary perl module) or
-<package>libmldbm-perl</package> (arch independent perl module).
- <item>
-Python related packages have their python policy; see
-&file-python-policy; in the <package>python</package> package.
- <item>
-Emacs related packages have the <url id="&url-emacs-policy;"
-name="emacs policy">.
- <item>
-Java related packages have their <url id="&url-java-policy;"
-name="java policy">.
- <item>
-Ocaml related packages have their own policy, found in
-&file-ocaml-policy; from the <package>ocaml</package> package. A good
-example is the <package>camlzip</package> source package.
- <item>
-Packages providing XML or SGML DTDs should conform to the
-recommendations found in the <package>sgml-base-doc</package>
-package.
- <item>
-Lisp packages should register themselves with
-<package>common-lisp-controller</package>, about which see
-&file-lisp-controller;.
-<!-- TODO: mozilla extension policy, once that becomes available -->
-</list>
- </sect1>
-
-<!--
- <sect1 id="custom-config-files">Custom configuration files
- <p>
- &FIXME; speak of "ucf", explain solution with a template,
- explain conf.d directories
-
- <sect1 id="config-with-db">Use of an external database
- <p>
- &FIXME; The software may require a database that you need to setup.
- But the database may be local or distant. Thus you can't depend
- on a database server but just on the corresponding library.
-
- sympa may be an example package
--->
-
- <sect1 id="bpp-archindepdata">
- <heading>Architecture-independent data</heading>
- <p>
-It is not uncommon to have a large amount of architecture-independent
-data packaged with a program. For example, audio files, a collection
-of icons, wallpaper patterns, or other graphic files. If the size of
-this data is negligible compared to the size of the rest of the
-package, it's probably best to keep it all in a single package.
- <p>
-However, if the size of the data is considerable, consider splitting
-it out into a separate, architecture-independent package ("_all.deb").
-By doing this, you avoid needless duplication of the same data into
-eleven or more .debs, one per each architecture. While this
-adds some extra overhead into the <file>Packages</file> files, it
-saves a lot of disk space on Debian mirrors. Separating out
-architecture-independent data also reduces processing time of
-<prgn>lintian</prgn> or <prgn>linda</prgn> (see <ref id="tools-lint">)
-when run over the entire Debian archive.
- </sect1>
-
-
- <sect1 id="bpp-locale">
- <heading>Needing a certain locale during build</heading>
- <p>
-If you need a certain locale during build, you can create a temporary
-file via this trick:
- <p>
-If you set LOCPATH to the equivalent of /usr/lib/locale, and LC_ALL to
-the name of the locale you generate, you should get what you want
-without being root. Something like this:
-
-<example>
-LOCALE_PATH=debian/tmpdir/usr/lib/locale
-LOCALE_NAME=en_IN
-LOCALE_CHARSET=UTF-8
-
-mkdir -p $LOCALE_PATH
-localedef -i "$LOCALE_NAME.$LOCALE_CHARSET" -f "$LOCALE_CHARSET" "$LOCALE_PATH/$LOCALE_NAME.$LOCALE_CHARSET"
-
-# Using the locale
-LOCPATH=$LOCALE_PATH LC_ALL=$LOCALE_NAME.$LOCALE_CHARSET date
-</example>
- </sect1>
-
- <sect1 id="bpp-transition">
- <heading>Make transition packages deborphan compliant</heading>
- <p>
-Deborphan is a program for helping users to detect which packages can
-safely be removed from the system, i.e. the ones that have no packages
-depending on them. The default operation is to search only within the libs
-and oldlibs sections, to hunt down unused libraries. But when passed the
-right argument, it tries to catch other useless packages.
- <p>
-For example, with --guess-dummy, deborphan tries to search all
-transitional packages which were needed for upgrade but which can now
-safely be removed. For that, it looks for the string "dummy" or
-"transitional" in their short description.
- <p>
-So, when you are creating such a package, please make sure to add this text
-to your short description. If you are looking for examples, just run:
- <example>apt-cache search .|grep dummy</example> or
- <example>apt-cache search .|grep transitional</example>.
- </sect1>
-
-
- <sect1 id="bpp-origtargz">
- <heading>Best practices for <file>orig.tar.gz</file> files</heading>
- <p>
- There are two kinds of original source tarballs: Pristine source
- and repackaged upstream source.
- </p>
- <sect2 id="pristinesource">
- <heading>Pristine source</heading>
- <p>
-The defining characteristic of a pristine source tarball is that the
-.orig.tar.gz file is byte-for-byte identical to a tarball officially
-distributed by the upstream author.
-<footnote>
-We cannot prevent upstream authors from changing the tarball
-they distribute without also incrementing the version number, so
-there can be no guarantee that a pristine tarball is identical
-to what upstream <em>currently</em> distributing at any point in
-time. All that can be expected is that it is identical to
-something that upstream once <em>did</em> distribute.
-
-If a difference arises later (say, if upstream notices that he wasn't
-using maximal comression in his original distribution and then
-re-<tt>gzip</tt>s it), that's just too bad. Since there is no good way
-to upload a new .orig.tar.gz for the same version, there is not even
-any point in treating this situation as a bug.
-</footnote>
-This makes it possible to use checksums to easily verify that all
-changes between Debian's version and upstream's are contained in the
-Debian diff. Also, if the original source is huge, upstream authors
-and others who already have the upstream tarball can save download
-time if they want to inspect your packaging in detail.
- </p>
- <p>
-There is no universally accepted guidelines that upstream authors
-follow regarding to the directory structure inside their tarball, but
-<prgn>dpkg-source</prgn> is nevertheless able to deal with most
-upstream tarballs as pristine source. Its strategy is equivalent to
-the following:
- </p>
- <p>
- <enumlist>
- <item>
-It unpacks the tarball in an empty temporary directory by doing
-
-<example>
-zcat path/to/<packagename>_<upstream-version>.orig.tar.gz | tar xf -
-</example>
- </item>
- <item>
-If, after this, the temporary directory contains nothing but one
-directory and no other files, <prgn>dpkg-source</prgn> renames that
-directory to
-<tt><packagename>-<upstream-version>(.orig)</tt>. The name
-of the top-level directory in the tarball does not matter, and is
-forgotten.
- </item>
- <item>
-Otherwise, the upstream tarball must have been packaged without a
-common top-level directory (shame on the upstream author!). In this
-case, <prgn>dpkg-source</prgn> renames the temporary directory
-<em>itself</em> to
-<tt><packagename>-<upstream-version>(.orig)</tt>.
- </item>
- </enumlist>
- </p>
- </sect2>
- <sect2 id="repackagedorigtargz">
- <heading>Repackaged upstream source</heading>
- <p>
-You <strong>should</strong> upload packages with a pristine source
-tarball if possible, but there are various reasons why it might not be
-possible. This is the case if upstream does not distribute the source
-as gzipped tar at all, or if upstream's tarball contains non-DFSG-free
-material that you must remove before uploading.
- </p>
- <p>
-In these cases the developer must construct a suitable .orig.tar.gz
-file himself. We refer to such a tarball as a "repackaged upstream
-source". Note that a "repackaged upstream source" is different from a
-Debian-native package. A repackaged source still comes with
-Debian-specific changes in a separate <tt>.diff.gz</tt> and still has
-a version number composed of <tt><upstream-version></tt> and
-<tt><debian-revision></tt>.
- </p>
- <p>
-There may be cases where it is desirable to repackage the source even
-though upstream distributes a <tt>.tar.gz</tt> that could in principle
-be used in its pristine form. The most obvious is if
-<em>significant</em> space savings can be achieved by recompressing
-the tar archive or by removing genuinely useless cruft from the
-upstream archive. Use your own discretion here, but be prepared to
-defend your decision if you repackage source that could have been
-pristine.
- </p>
- <p>
-A repackaged .orig.tar.gz
- </p>
- <p>
- <enumlist>
- <item>
-<p>
-<strong>must</strong> contain detailed information how
-the repackaged source was obtained, and how this can be reproduced
-in the <file>debian/copyright</file>.
-It is also a good idea to provide a
-<tt>get-orig-source</tt> target in your <file>debian/rules</file> file
-that repeats the process, as described in the Policy Manual, <url
-id="&url-debian-policy;ch-source.html#s-debianrules" name="Main
-building script: debian/rules">.
-</p>
- </item>
- <item>
-<strong>should not</strong> contain any file that does not come from the
-upstream author(s), or whose contents has been changed by you.
-<footnote>
-As a special exception, if the omission of non-free files would lead
-to the source failing to build without assistance from the Debian
-diff, it might be appropriate to instead edit the files, omitting only
-the non-free parts of them, and/or explain the situation in a
-README.Debian-source <!-- or similarly named --> file in the root of the
-source tree. But in that case please also urge the upstream author to make
-the non-free components easier seperable from the rest of the source.
-</footnote>
- </item>
- <item>
-<p>
-<strong>should</strong>, except where impossible for legal reasons,
-preserve the entire building and portablility infrastructure provided
-by the upstream author. For example, it is not a sufficient reason for
-omitting a file that it is used only when building on
-MS-DOS. Similarly, a Makefile provided by upstream should not be
-omitted even if the first thing your <file>debian/rules</file> does is
-to overwrite it by running a configure script.
-</p>
-<p>
-(<em>Rationale:</em> It is common for Debian users who need to build
-software for non-Debian platforms to fetch the source from a Debian
-mirror rather than trying to locate a canonical upstream distribution
-point).
-</p> </item>
- <item>
-<strong>should</strong> use
-<tt><packagename>-<upstream-version>.orig</tt> as the name
-of the top-level directory in its tarball. This makes it possible to
-distinguish pristine tarballs from repackaged ones.
- </item>
- <item>
-<strong>should</strong> be gzipped with maximal compression.
- </item>
- </enumlist>
- </p>
- <p>
-The canonical way to meet the latter two points is to let
-<tt>dpkg-source -b</tt> construct the repackaged tarball from an
-unpacked directory.
- </p>
- </sect2>
- <sect2 id="changed-binfiles">
- <heading>Changing binary files in <tt>diff.gz</tt></heading>
- <p>
-Sometimes it is necessary to change binary files contained in the
-original tarball, or to add binary files that are not in it.
-If this is done by simply copying the files into the debianized source
-tree, <prgn>dpkg-source</prgn> will not be able to handle this. On the
-other hand, according to the guidelines given above, you cannot
-include such a changed binary file in a repackaged
-<file>orig.tar.gz</file>. Instead, include the file in the
-<file>debian</file> directory in <prgn>uuencode</prgn>d (or similar)
-form
-<footnote>
-The file should have a name that makes it clear which binary file it
-encodes. Usually, some postfix indicating the encoding should be
-appended to the original filename.
-Note that you don't need to depend on <package>sharutils</package> to get
-the <prgn>uudecode</prgn> program if you use <prgn>perl</prgn>'s
-<tt>pack</tt> function.
-The code could look like
-<example>
-uuencode-file:
- perl -ne 'print(pack "u", $$_);' $(file) > $(file).uuencoded
-
-uudecode-file:
- perl -ne 'print(unpack "u", $$_);' $(file).uuencoded > $(file)
-</example>
-</footnote>.
-The file would then be decoded and copied to its place during the
-build process. Thus the change will be visible quite easy.
-</p>
-<p>
-Some packages use <prgn>dbs</prgn> to manage patches to their upstream
-source, and always create a new <tt>orig.tar.gz</tt> file that
-contains the real <tt>orig.tar.gz</tt> in its toplevel directory. This
-is questionable with respect to the preference for pristine source. On
-the other hand, it is easy to modify or add binary files in this case:
-Just put them into the newly created <tt>orig.tar.gz</tt> file,
-besides the real one, and copy them to the right place during the
-build process.
- </p>
- </sect2>
- </sect1>
- <sect1 id="bpp-dbg">
- <heading>Best practices for debug packages</heading>
- <p>
-A debug package is a package with a name ending in "-dbg", that contains
-additional information that gdb can use. Since Debian binaries are
-stripped by default, debugging information, including function names and
-line numbers, is otherwise not available when running gdb on Debian binaries.
-Debug packages allow users who need this additional debugging information to
-install it, without bloating a regular system with the information.
- <p>
-It is up to a package's maintainer whether to create a debug package or
-not. Maintainers are encouraged to create debug packages for library
-packages, since this can aid in debugging many programs linked to a
-library. In general, debug packages do not need to be added for all
-programs; doing so would bloat the archive. But if a maintainer finds
-that users often need a debugging version of a program, it can be
-worthwhile to make a debug package for it. Programs that are core
-infrastructure, such as apache and the X server are also good candidates
-for debug packages.
- <p>
-Some debug packages may contain an entire special debugging build of a
-library or other binary, but most of them can save space and build time
-by instead containing separated debugging symbols that gdb can find and
-load on the fly when debugging a program or library. The convention in
-Debian is to keep these symbols in <file>/usr/lib/debug/<em>path</em></file>,
-where <em>path</em> is the path to the executable or library. For example,
-debugging symbols for <file>/usr/bin/foo</file> go in
-<file>/usr/lib/debug/usr/bin/foo</file>, and
-debugging symbols for <file>/usr/lib/libfoo.so.1</file> go in
-<file>/usr/lib/debug/usr/lib/libfoo.so.1</file>.
- <p>
-The debugging symbols can be extracted from an object file using
-"objcopy --only-keep-debug". Then the object file can be stripped, and
-"objcopy --add-gnu-debuglink" used to specify the path to the debugging
-symbol file. <manref name="objcopy" section="1"> explains in detail how this
-works.
- <p>
-The dh_strip command in debhelper supports creating debug packages, and
-can take care of using objcopy to separate out the debugging symbols for
-you. If your package uses debhelper, all you need to do is call
-"dh_strip --dbg-package=libfoo-dbg", and add an entry to debian/control
-for the debug package.
- <p>
-Note that the Debian package should depend on the package that it
-provides debugging symbols for, and this dependency should be versioned.
-For example:
-
-<example>
-Depends: libfoo-dbg (= ${binary:Version})
-</example>
-
-
- </sect>
- </chapt>
-
-
- <chapt id="beyond-pkging">
- <heading>Beyond Packaging</heading>
- <p>
-Debian is about a lot more than just packaging software and
-maintaining those packages. This chapter contains information about
-ways, often really critical ways, to contribute to Debian beyond
-simply creating and maintaining packages.
- <p>
-As a volunteer organization, Debian relies on the discretion of its
-members in choosing what they want to work on and in choosing
-the most critical thing to spend their time on.
-
- <sect id="submit-bug">
- <heading>Bug reporting</heading>
- <p>
-We encourage you to file bugs as you find them in Debian packages. In
-fact, Debian developers are often the first line testers. Finding and
-reporting bugs in other developers' packages improves the quality of
-Debian.
- <p>
-Read the <url name="instructions for reporting bugs"
-id="&url-bts-report;"> in the Debian <url name="bug tracking system"
-id="&url-bts;">.
- <p>
-Try to submit the bug from a normal user account at which you are
-likely to receive mail, so that people can reach you if they need
-further information about the bug. Do not submit bugs as root.
- <p>
-You can use a tool like <manref name="reportbug" section="1"> to
-submit bugs. It can automate and generally ease the process.
- <p>
-Make sure the bug is not already filed against a package.
-Each package has a bug list easily reachable at
-<tt>http://&bugs-host;/<var>packagename</var></tt>
-Utilities like <manref name="querybts" section="1"> can also
-provide you with this information (and <prgn>reportbug</prgn>
-will usually invoke <prgn>querybts</prgn> before sending, too).
- <p>
-Try to direct your bugs to the proper location. When for example
-your bug is about a package which overwrites files from another package,
-check the bug lists for <em>both</em> of those packages in order to
-avoid filing duplicate bug reports.
- <p>
-For extra credit, you can go through other packages, merging bugs
-which are reported more than once, or tagging bugs `fixed'
-when they have already been fixed. Note that when you are
-neither the bug submitter nor the package maintainer, you should
-not actually close the bug (unless you secure permission from the
-maintainer).
- <p>
-From time to time you may want to check what has been going on
-with the bug reports that you submitted. Take this opportunity to
-close those that you can't reproduce anymore. To find
-out all the bugs you submitted, you just have to visit
-<tt>http://&bugs-host;/from:<var><your-email-addr></var></tt>.
-
- <sect1 id="submit-many-bugs">Reporting lots of bugs at once (mass bug filing)
- <p>
-Reporting a great number of bugs for the same problem on a great
-number of different packages — i.e., more than 10 — is a
-deprecated practice. Take all possible steps to avoid submitting bulk
-bugs at all. For instance, if checking for the problem can be automated,
-add a new check to <package>lintian</package> so that an error or warning
-is emitted.
- <p>
-If you report more than 10 bugs on the same topic at once, it is
-recommended that you send a message to &email-debian-devel; describing
-your intention before submitting the report, and mentioning the
-fact in the subject of your mail. This will allow other
-developers to verify that the bug is a real problem. In addition, it
-will help prevent a situation in which several maintainers start
-filing the same bug report simultaneously.
- <p>
-Please use the programms <prgn>dd-list</prgn> and
-if appropriate <prgn>whodepends</prgn>
-(from the package devscripts)
-to generate a list of all affected packages, and include the
-output in your mail to &email-debian-devel;.
- <p>
-Note that when sending lots of bugs on the same subject, you should
-send the bug report to <email>maintonly@&bugs-host;</email> so
-that the bug report is not forwarded to the bug distribution mailing
-list.
-
-
- <sect id="qa-effort">Quality Assurance effort
-
- <sect1 id="qa-daily-work">Daily work
- <p>
-Even though there is a dedicated group of people for Quality
-Assurance, QA duties are not reserved solely for them. You can
-participate in this effort by keeping your packages as bug-free as
-possible, and as lintian-clean (see <ref id="lintian">) as
-possible. If you do not find that possible, then you should consider
-orphaning some of your packages (see <ref
-id="orphaning">). Alternatively, you may ask the help of other people
-in order to catch up with the backlog of bugs that you have (you can ask
-for help on &email-debian-qa; or &email-debian-devel;). At the same
-time, you can look for co-maintainers (see <ref id="collaborative-maint">).
-
- <sect1 id="qa-bsp">Bug squashing parties
- <p>
-From time to time the QA group organizes bug squashing parties to get rid of
-as many problems as possible. They are announced on
-&email-debian-devel-announce; and the announcement explains which area
-will be the focus of the party: usually they focus on release critical
-bugs but it may happen that they decide to help finish a major upgrade
-(like a new perl version which requires recompilation of all the binary
-modules).
- <p>
-The rules for non-maintainer uploads differ during the parties because
-the announcement of the party is considered prior notice for NMU. If
-you have packages that may be affected by the party (because they have
-release critical bugs for example), you should send an update to each of
-the corresponding bug to explain their current status and what you expect
-from the party. If you don't want an NMU, or if you're only interested in a
-patch, or if you will deal yourself with the bug, please explain that in
-the BTS.
- <p>
-People participating in the party have special rules for NMU, they can
-NMU without prior notice if they upload their NMU to
-DELAYED/3-day at least. All other NMU rules apply as usually; they
-should send the patch of the NMU to the BTS (to one of the open bugs
-fixed by the NMU, or to a new bug, tagged fixed). They should
-also respect any particular wishes of the maintainer.
- <p>
-If you don't feel confident about doing an NMU, just send a patch
-to the BTS. It's far better than a broken NMU.
-
-
- <sect id="contacting-maintainers">Contacting other maintainers
- <p>
-During your lifetime within Debian, you will have to contact other
-maintainers for various reasons. You may want to discuss a new
-way of cooperating between a set of related packages, or you may
-simply remind someone that a new upstream version is available
-and that you need it.
- <p>
-Looking up the email address of the maintainer for the package can be
-distracting. Fortunately, there is a simple email alias,
-<tt><package>@&packages-host;</tt>, which provides a way to
-email the maintainer, whatever their individual email address (or
-addresses) may be. Replace <tt><package></tt> with the name of
-a source or a binary package.
- <p>
-You may also be interested in contacting the persons who are
-subscribed to a given source package via <ref id="pkg-tracking-system">.
-You can do so by using the <tt><package>@&pts-host;</tt>
-email address.
-<!-- FIXME: moo@packages.d.o is easily confused with moo@packages.qa.d.o -->
-
- <sect id="mia-qa">Dealing with inactive and/or unreachable maintainers
- <p>
-If you notice that a package is lacking maintenance, you should
-make sure that the maintainer is active and will continue to work on
-their packages. It is possible that they are not active any more, but
-haven't registered out of the system, so to speak. On the other hand,
-it is also possible that they just need a reminder.
- <p>
-There is a simple system (the MIA database) in which information about
-maintainers who are deemed Missing In Action is recorded.
-When a member of the
-QA group contacts an inactive maintainer or finds more information about
-one, this is recorded in the MIA database. This system is available
-in /org/qa.debian.org/mia on the host qa.debian.org, and can be queried
-with a tool known as <prgn>mia-query</prgn>.
-Use <example>mia-query --help</example> to see how to query the database.
-If you find that no information has been recorded
-about an inactive maintainer yet, or that you can add more information,
-you should generally proceed as follows.
- <p>
-The first step is to politely contact the maintainer,
-and wait a reasonable time for a response.
-It is quite hard to define "reasonable
-time", but it is important to take into account that real life is sometimes
-very hectic. One way to handle this would be to send a reminder after two
-weeks.
- <p>
-If the maintainer doesn't reply within four weeks (a month), one can
-assume that a response will probably not happen. If that happens, you
-should investigate further, and try to gather as much useful information
-about the maintainer in question as possible. This includes:
- <p>
- <list>
- <item>The "echelon" information available through the
- <url id="&url-debian-db;" name="developers' LDAP database">,
- which indicates when the developer last posted to
- a Debian mailing list. (This includes uploads via
- debian-*-changes lists.) Also, remember to check whether the
- maintainer is marked as "on vacation" in the database.
-
- <item>The number of packages this maintainer is responsible for,
- and the condition of those packages. In particular, are there
- any RC bugs that have been open for ages? Furthermore, how
- many bugs are there in general? Another important piece of
- information is whether the packages have been NMUed, and if
- so, by whom.
-
- <item>Is there any activity of the maintainer outside of Debian?
- For example, they might have posted something recently to
- non-Debian mailing lists or news groups.
- </list>
- <p>
-A bit of a problem are packages which were sponsored — the
-maintainer is not an official Debian developer. The echelon information is
-not available for sponsored people, for example, so you need to find and
-contact the Debian developer who has actually uploaded the package. Given
-that they signed the package, they're responsible for the upload anyhow,
-and are likely to know what happened to the person they sponsored.
- <p>
-It is also allowed to post a query to &email-debian-devel;, asking if anyone
-is aware of the whereabouts of the missing maintainer.
-Please Cc: the person in question.
- <p>
-Once you have gathered all of this, you can contact &email-mia;.
-People on this alias will use the information you provide in order to
-decide how to proceed. For example, they might orphan one or all of the
-packages of the maintainer. If a package has been NMUed, they might prefer
-to contact the NMUer before orphaning the package — perhaps the
-person who has done the NMU is interested in the package.
- <p>
-One last word: please remember to be polite. We are all volunteers and
-cannot dedicate all of our time to Debian. Also, you are not aware of the
-circumstances of the person who is involved. Perhaps they might be
-seriously ill or might even have died — you do not know who may be
-on the receiving side. Imagine how a relative will feel if they read the
-e-mail of the deceased and find a very impolite, angry and accusing
-message!
- <p>
-On the other hand, although we are volunteers, we do have a responsibility.
-So you can stress the importance of the greater good — if a
-maintainer does not have the time or interest anymore, they should "let
-go" and give the package to someone with more time.
- <p>
-If you are interested in working in the MIA team, please have a look at the
-README file in /org/qa.debian.org/mia on qa.debian.org where the technical
-details and the MIA procedures are documented and contact &email-mia;.
-
-
- <sect id="newmaint">
- <heading>Interacting with prospective Debian developers</heading>
- <p>
-Debian's success depends on its ability to attract and retain new and
-talented volunteers. If you are an experienced developer, we
-recommend that you get involved with the process of bringing in new
-developers. This section describes how to help new prospective
-developers.
-
-
- <sect1 id="sponsoring">Sponsoring packages
- <p>
-Sponsoring a package means uploading a package for a maintainer who is not
-able to do it on their own, a new maintainer applicant. Sponsoring a package
-also means accepting responsibility for it.
- <p>
- <!-- FIXME: service down
-If you wish to volunteer as a sponsor, you can sign up at <url
-id="&url-sponsors;">.
- <p>
- -->
-New maintainers usually have certain difficulties creating Debian packages
-— this is quite understandable. That is why the sponsor is there, to
-check the package and verify that it is good enough for inclusion in
-Debian. (Note that if the sponsored package is new, the ftpmasters will
-also have to inspect it before letting it in.)
- <p>
-Sponsoring merely by signing the upload or just recompiling is
-<strong>definitely not recommended</strong>. You need to build the source
-package just like you would build a package of your own. Remember that it
-doesn't matter that you left the prospective developer's name both in the
-changelog and the control file, the upload can still be traced to you.
- <p>
-If you are an application manager for a prospective developer, you can also
-be their sponsor. That way you can also verify how the applicant is
-handling the 'Tasks and Skills' part of their application.
-
- <sect1>Managing sponsored packages
- <p>
-By uploading a sponsored package to Debian, you are certifying that
-the package meets minimum Debian standards. That implies that you
-must build and test the package on your own system before uploading.
- <p>
-You cannot simply upload a binary <file>.deb</file> from the sponsoree. In
-theory, you should only ask for the diff file and the location of the
-original source tarball, and then you should download the source and apply
-the diff yourself. In practice, you may want to use the source package
-built by your sponsoree. In that case, you have to check that they haven't
-altered the upstream files in the <file>.orig.tar.gz</file> file that
-they're providing.
- <p>
-Do not be afraid to write the sponsoree back and point out changes
-that need to be made. It often takes several rounds of back-and-forth
-email before the package is in acceptable shape. Being a sponsor
-means being a mentor.
- <p>
-Once the package meets Debian standards, build and sign it with
-<example>dpkg-buildpackage -k<var>KEY-ID</var></example>
-before uploading it to the incoming directory. Of course, you can also
-use any part of your <var>KEY-ID</var>, as long as it's unique in your
-secret keyring.
- <p>
-The Maintainer field of the <file>control</file> file and the
-<file>changelog</file> should list the person who did the packaging, i.e.,
-the sponsoree. The sponsoree will therefore get all the BTS mail about the
-package.
- <p>
-If you prefer to leave a more evident trace of your sponsorship job, you
-can add a line stating it in the most recent changelog entry.
- <p>
-You are encouraged to keep tabs on the package you sponsor using
-<ref id="pkg-tracking-system">.
-
- <sect1>Advocating new developers
- <p>
-See the page about <url id="&url-newmaint-advocate;"
-name="advocating a prospective developer"> at the Debian web site.
-
- <sect1>Handling new maintainer applications
- <p>
-Please see <url id="&url-newmaint-amchecklist;" name="Checklist for
-Application Managers"> at the Debian web site.
-
-
- <chapt id="l10n">Internationalizing, translating, being internationalized
- and being translated
- <p>
-Debian supports an ever-increasing number of natural languages. Even if
-you are a native English speaker and do not speak any other language, it
-is part of your duty as a maintainer to be aware of issues of
-internationalization (abbreviated i18n because there are 18 letters
-between the 'i' and the 'n' in internationalization). Therefore, even if
-you are ok with English-only programs, you should read most of this
-chapter.
- <p>
-According to <url id="http://www.debian.org/doc/manuals/intro-i18n/"
-name="Introduction to i18n"> from Tomohiro KUBOTA, "I18N
-(internationalization) means modification of a software or related
-technologies so that a software can potentially handle multiple languages,
-customs, and so on in the world." while "L10N (localization) means
-implementation of a specific language for an already internationalized
-software."
- <p>
-l10n and i18n are interconnected, but the difficulties related to each of
-them are very different. It's not really difficult to allow a program to
-change the language in which texts are displayed based on user settings,
-but it is very time consuming to actually translate these messages. On the
-other hand, setting the character encoding is trivial, but adapting the
-code to use several character encodings is a really hard problem.
- <p>
-Setting aside the i18n problems, where no general guideline can be given,
-there is actually no central infrastructure for l10n within Debian which
-could be compared to the dbuild mechanism for porting. So most of the work
-has to be done manually.
-
-
- <sect id="l10n-handling">How translations are handled within Debian
- <p>
-Handling translation of the texts contained in a package is still a manual
-task, and the process depends on the kind of text you want to see translated.
- <p>
-For program messages, the gettext infrastructure is used most of the time.
-Most of the time, the translation is handled upstream within projects like
-the <url id="http://www.iro.umontreal.ca/contrib/po/HTML/" name="Free
-Translation Project">, the <url
-id="http://developer.gnome.org/projects/gtp/" name="Gnome translation
-Project"> or the <url id="http://i18n.kde.org/" name="KDE one">.
-The only centralized resource within Debian is the <url
-id="http://www.debian.org/intl/l10n/" name="Central Debian translation
-statistics">, where you can find some statistics about the translation
-files found in the actual packages, but no real infrastructure to ease the
-translation process.
- <p>
-An effort to translate the package descriptions started long ago, even if
-very little support is offered by the tools to actually use them (i.e.,
-only APT can use them, when configured correctly). Maintainers don't need
-to do anything special to support translated package descriptions;
-translators should use the <url id="http://ddtp.debian.org/"
-name="DDTP">.
- <p>
-For debconf templates, maintainers should use the po-debconf package to
-ease the work of translators, who could use the DDTP to do their work (but
-the French and Brazilian teams don't). Some statistics can be found both
-on the DDTP site (about what is actually translated), and on the <url
-id="http://www.debian.org/intl/l10n/" name="Central Debian translation
-statistics"> site (about what is integrated in the packages).
- <p>
-For web pages, each l10n team has access to the relevant CVS, and the
-statistics are available from the Central Debian translation statistics
-site.
- <p>
-For general documentation about Debian, the process is more or less the
-same as for the web pages (the translators have access to the CVS), but
-there are no statistics pages.
- <p>
-For package-specific documentation (man pages, info documents, other
-formats), almost everything remains to be done.
- <p>
-Most notably, the KDE project handles translation of its documentation in
-the same way as its program messages.
- <p>
-There is an effort to handle Debian-specific man pages
-within a <url
-id="http://cvs.debian.org/manpages/?cvsroot=debian-doc" name="specific CVS
-repository">.
-
-
- <sect id="l10n-faqm">I18N & L10N FAQ for maintainers
- <p>
-This is a list of problems that maintainers may face concerning i18n and
-l10n. While reading this, keep in mind that there is no real consensus on
-these points within Debian, and that this is only advice. If you have a
-better idea for a given problem, or if you disagree on some points, feel
-free to provide your feedback, so that this document can be enhanced.
-
- <sect1 id="l10n-faqm-tr">How to get a given text translated
- <p>
-To translate package descriptions or debconf templates, you have nothing
-to do; the DDTP infrastructure will dispatch the material to translate to
-volunteers with no need for interaction from your part.
- <p>
-For all other material (gettext files, man pages, or other documentation),
-the best solution is to put your text somewhere on the Internet, and ask
-on debian-i18n for a translation in different languages. Some translation
-team members are subscribed to this list, and they will take care of the
-translation and of the reviewing process. Once they are done, you will get
-your translated document from them in your mailbox.
-
- <sect1 id="l10n-faqm-rev">How to get a given translation reviewed
- <p>
-From time to time, individuals translate some texts in your package
-and will ask you for inclusion of the translation in the package. This can
-become problematic if you are not fluent in the given language. It is a
-good idea to send the document to the corresponding l10n mailing list,
-asking for a review. Once it has been done, you should feel more confident
-in the quality of the translation, and feel safe to include it in your
-package.
-
- <sect1 id="l10n-faqm-update">How to get a given translation updated
- <p>
-If you have some translations of a given text lying around, each time you
-update the original, you should ask the previous translator to update
-the translation with your new changes.
-Keep in mind that this task takes time; at least one week to get
-the update reviewed and all.
- <p>
-If the translator is unresponsive, you may ask for help on the
-corresponding l10n mailing list. If everything fails, don't forget to put
-a warning in the translated document, stating that the translation is
-somehow outdated, and that the reader should refer to the original
-document if possible.
- <p>
-Avoid removing a translation completely because it is outdated. Old
-documentation is often better than no documentation at all for non-English
-speakers.
-
- <sect1 id="l10n-faqm-bug">How to handle a bug report concerning a translation
- <p>
-The best solution may be to mark the bug as "forwarded to upstream", and
-forward it to both the previous translator and his/her team (using the
-corresponding debian-l10n-XXX mailing list).
-<!-- TODO: add the i18n tag to the bug? -->
-
- <sect id="l10n-faqtr">I18N & L10N FAQ for translators
- <p>
-While reading this, please keep in mind that there is no general procedure
-within Debian concerning these points, and that in any case, you should
-collaborate with your team and the package maintainer.
-
- <sect1 id="l10n-faqtr-help">How to help the translation effort
- <p>
-Choose what you want to translate, make sure that nobody is already
-working on it (using your debian-l10n-XXX mailing list), translate it, get
-it reviewed by other native speakers on your l10n mailing list, and
-provide it to the maintainer of the package (see next point).
-
- <sect1 id="l10n-faqtr-inc">How to provide a translation for inclusion in a package
- <p>
-Make sure your translation is correct (asking for review on your l10n mailing
-list) before providing it for inclusion. It will save time for everyone, and
-avoid the chaos resulting in having several versions of the same document in
-bug reports.
- <p>
-The best solution is to file a regular bug containing the translation
-against the package. Make sure to use the 'PATCH' tag, and to not use a
-severity higher than 'wishlist', since the lack of translation never
-prevented a program from running.
-
- <sect id="l10n-best">Best current practice concerning l10n
- <p>
-<list>
- <item>
-As a maintainer, never edit the translations in any way (even to reformat the
-layout) without asking on the corresponding l10n mailing list. You risk for
-example breaksing the encoding of the file by doing so. Moreover, what you
-consider an error can be right (or even needed) in the given language.
- <item>
-As a translator, if you find an error in the original text, make sure to
-report it. Translators are often the most attentive readers of a given
-text, and if they don't report the errors they find, nobody will.
- <item>
-In any case, remember that the major issue with l10n is that it requires
-several people to cooperate, and that it is very easy to start a flamewar
-about small problems because of misunderstandings. So if you have problems
-with your interlocutor, ask for help on the corresponding l10n mailing
-list, on debian-i18n, or even on debian-devel (but beware, l10n
-discussions very often become flamewars on that list :)
- <item>
-In any case, cooperation can only be achieved with <strong>mutual
-respect</strong>.
-</list>
-
-
- <appendix id="tools">Overview of Debian Maintainer Tools
- <p>
-This section contains a rough overview of the tools available to
-maintainers. The following is by no means complete or definitive, but
-just a guide to some of the more popular tools.
- <p>
-Debian maintainer tools are meant to aid developers and
-free their time for critical tasks. As Larry Wall says, there's more
-than one way to do it.
- <p>
-Some people prefer to use high-level package maintenance tools and
-some do not. Debian is officially agnostic on this issue; any tool
-which gets the job done is fine. Therefore, this section is not meant
-to stipulate to anyone which tools they should use or how they should
-go about their duties of maintainership. Nor is it meant to
-endorse any particular tool to the exclusion of a competing tool.
- <p>
-Most of the descriptions of these packages come from the actual
-package descriptions themselves. Further information can be found in
-the package documentation itself. You can also see more info with the
-command <tt>apt-cache show <package-name></tt>.</p>
-
- <sect id="tools-core">
- <heading>Core tools</heading>
- <p>
-The following tools are pretty much required for any maintainer.</p>
-
- <sect1 id="dpkg-dev">
- <heading><package>dpkg-dev</package>
- <p>
-<package>dpkg-dev</package> contains the tools (including
-<prgn>dpkg-source</prgn>) required to unpack, build, and upload Debian
-source packages. These utilities contain the fundamental, low-level
-functionality required to create and manipulate packages; as such,
-they are essential for any Debian maintainer.
-
- <sect1 id="debconf">
- <heading><package>debconf</package></heading>
- <p>
-<package>debconf</package> provides a consistent interface to
-configuring packages interactively. It is user interface
-independent, allowing end-users to configure packages with a
-text-only interface, an HTML interface, or a dialog interface. New
-interfaces can be added as modules.
- <p>
-You can find documentation for this package in the
-<package>debconf-doc</package> package.
- <p>
-Many feel that this system should be used for all packages which require
-interactive configuration; see <ref id="bpp-config-mgmt">.
-<package>debconf</package> is not currently required by Debian Policy,
-but that may change in the future.
- </sect1>
-
- <sect1 id="fakeroot">
- <heading><package>fakeroot</package>
- <p>
-<package>fakeroot</package> simulates root privileges. This enables
-you to build packages without being root (packages usually want to
-install files with root ownership). If you have
-<package>fakeroot</package> installed, you can build packages as a
-regular user: <tt>dpkg-buildpackage -rfakeroot</tt>.
- </sect1>
- </sect>
-
- <sect id="tools-lint">
- <heading>Package lint tools</heading>
- <p>
-According to the Free On-line Dictionary of Computing (FOLDOC), `lint'
-is "a Unix C language processor which carries out more thorough checks
-on the code than is usual with C compilers." Package lint tools help
-package maintainers by automatically finding common problems and
-policy violations in their packages.</p>
-
- <sect1 id="lintian">
- <heading><package>lintian</package></heading>
- <p>
-<package>lintian</package> dissects Debian packages and emits
-information about bugs
-and policy violations. It contains automated checks for many aspects
-of Debian policy as well as some checks for common errors.
- <p>
-You should periodically get the newest <package>lintian</package> from
-`unstable' and check over all your packages. Notice that the <tt>-i</tt>
-option provides detailed explanations of what each error or warning means,
-what its basis in Policy is, and commonly how you can fix the problem.
- <p>
-Refer to <ref id="sanitycheck"> for more information on how and when
-to use Lintian.
- <p>
-You can also see a summary of all problems reported by Lintian on your
-packages at <url id="&url-lintian;">. These reports contain the latest
-<prgn>lintian</prgn> output for the whole development distribution
-("unstable").
- </sect1>
-
- <sect1 id="linda">
- <heading><package>linda</package></heading>
- <p>
-<package>linda</package> is another package linter. It is similar to
-<package>lintian</package> but has a different set of checks. Its
-written in Python rather than Perl.</p>
- </sect1>
-
- <sect1 id="debdiff">
- <heading><package>debdiff</package></heading>
- <p>
-<prgn>debdiff</prgn> (from the <package>devscripts</package> package, <ref
-id="devscripts">) compares file lists and control files of two packages.
-It is a simple regression test, as it will help you notice if the number
-of binary packages has changed since the last upload, or if something has
-changed in the control file. Of course, some of the changes it reports
-will be all right, but it can help you prevent various accidents.
- <p>
-You can run it over a pair of binary packages:
-<example>
-debdiff package_1-1_arch.deb package_2-1_arch.deb
-</example>
- <p>
-Or even a pair of changes files:
-<example>
-debdiff package_1-1_arch.changes package_2-1_arch.changes
-</example>
- <p>
-For more information please see <manref name="debdiff" section="1">.
- </sect1>
-
- </sect>
-
-
- <sect id="tools-helpers">
- <heading>Helpers for <file>debian/rules</file></heading>
- <p>
-Package building tools make the process of writing
-<file>debian/rules</file> files easier. See <ref id="helper-scripts">
-for more information about why these might or might not be desired.
-
- <sect1 id="debhelper">
- <heading><package>debhelper</package></heading>
- <p>
-<package>debhelper</package> is a collection of programs which can be
-used in <file>debian/rules</file> to automate common tasks related to
-building binary Debian packages. <package>debhelper</package> includes
-programs to install
-various files into your package, compress files, fix file permissions,
-and integrate your package with the Debian menu system.
- <p>
-Unlike some approaches, <package>debhelper</package> is broken into
-several small, simple commands which act in a consistent manner. As
-such, it allows more fine-grained control than some of the
-other "debian/rules tools".
- <p>
-There are a number of little <package>debhelper</package> add-on
-packages, too transient to document. You can see the list of most of
-them by doing <tt>apt-cache search ^dh-</tt>.
- </sect1>
-
- <sect1 id="debmake">
- <heading><package>debmake</package>
- <p>
-<package>debmake</package>, a precursor to
-<package>debhelper</package>, is a more coarse-grained
-<file>debian/rules</file> assistant. It includes two main programs:
-<prgn>deb-make</prgn>, which can be used to help a maintainer convert
-a regular (non-Debian) source archive into a Debian source package;
-and <prgn>debstd</prgn>, which incorporates in one big shot the same
-sort of automated functions that one finds in
-<package>debhelper</package>.
- <p>
-The consensus is that <package>debmake</package> is now deprecated in
-favor of <package>debhelper</package>. It is a bug to use
-<package>debmake</package> in new packages. New packages using
-<package>debmake</package> will be rejected from the archive.
- </sect1>
-
- <sect1 id="dh-make">
- <heading><package>dh-make</package>
- <p>
-The <package/dh-make/ package contains <prgn/dh_make/, a program that
-creates a skeleton of files necessary to build a Debian package out of
-a source tree. As the name suggests, <prgn/dh_make/ is a rewrite of
-<package/debmake/ and its template files use dh_* programs from
-<package/debhelper/.
- <p>
-While the rules files generated by <prgn/dh_make/ are in general a
-sufficient basis for a working package, they are still just the groundwork:
-the burden still lies on the maintainer to finely tune the generated files
-and make the package entirely functional and Policy-compliant.
- </sect1>
-
- <sect1 id="yada">
- <heading><package>yada</package>
- <p>
-<package>yada</package> is another packaging helper tool. It uses a
-<file>debian/packages</file> file to auto-generate
-<file>debian/rules</file> and other necessary files in the
-<file>debian/</file> subdirectory. The <file>debian/packages</file> file
-contains instruction to build packages and there is no need to create any
-<file>Makefile</file> files. There is possibility to
-use macro engine similar to the one used in SPECS files from RPM
-source packages.</p>
- <p>
-For more informations see
-<tt><url id="http://yada.alioth.debian.org/" name="YADA site"></tt>.</p>
- </sect1>
-
- <sect1 id="equivs">
- <heading><package>equivs</package>
- <p>
-<package>equivs</package> is another package for making packages. It
-is often suggested for local use if you need to make a package simply
-to fulfill dependencies. It is also sometimes used when making
-``meta-packages'', which are packages whose only purpose is to depend
-on other packages.</p>
- </sect1>
- </sect>
-
-
-
- <sect id="tools-builders">
- <heading>Package builders</heading>
- <p>
-The following packages help with the package building process, general
-driving <prgn>dpkg-buildpackage</prgn> as well as handling supporting
-tasks.</p>
-
- <sect1 id="cvs-buildpackage">
- <heading><package>cvs-buildpackage</package>
- <p>
-<package>cvs-buildpackage</package> provides the capability to inject
-or import Debian source packages into a CVS repository, build a Debian
-package from the CVS repository, and helps in integrating upstream
-changes into the repository.
- <p>
-These utilities provide an infrastructure to facilitate the use of CVS
-by Debian maintainers. This allows one to keep separate CVS branches
-of a package for <em>stable</em>, <em>unstable</em> and possibly
-<em>experimental</em> distributions, along with the other benefits of
-a version control system.
- </sect1>
-
- <sect1 id="debootstrap">
- <heading><package>debootstrap</package></heading>
- <p>
-The <package>debootstrap</package> package and script allows you to
-"bootstrap" a Debian base system into any part of your filesystem.
-By "base system", we mean the bare minimum of packages required to
-operate and install the rest of the system.
- <p>
-Having a system like this can be useful in many ways. For instance,
-you can <prgn>chroot</prgn> into it if you want to test your build
-dependencies. Or you can test how your package behaves when installed
-into a bare base system. Chroot builders use this package; see below.
- </sect1>
-
- <sect1 id="pbuilder">
- <heading><package>pbuilder</package></heading>
- <p>
-<package>pbuilder</package> constructs a chrooted system, and builds a
-package inside the chroot. It is very useful to check that a package's
-build-dependencies are correct, and to be sure that unnecessary and
-wrong build dependencies will not exist in the resulting package.</p>
- <p>
-A related package is <package>pbuilder-uml</package>, which goes even
-further by doing the build within a User Mode Linux environment.</p>
- </sect1>
-
- <sect1 id="sbuild">
- <heading><package>sbuild</package></heading>
- <p>
-<package>sbuild</package> is another automated builder. It can use
-chrooted environments as well. It can be used stand-alone, or as part
-of a networked, distributed build environment. As the latter, it is
-part of the system used by porters to build binary packages for all
-the available architectures. See <ref id="buildd"> for more
-information, and <url id="&url-buildd;"> to see the system in
-action.</p>
- </sect1>
- </sect>
-
- <sect id="uploaders">
- <heading>Package uploaders</heading>
- <p>
-The following packages help automate or simplify the process of
-uploading packages into the official archive.</p>
-
- <sect1 id="dupload">
- <heading><package>dupload</package></heading>
- <p>
-<package>dupload</package> is a package and a script to automatically
-upload Debian packages to the Debian archive, to log the upload, and
-to send mail about the upload of a package. You can configure it for
-new upload locations or methods.
- </sect1>
-
- <sect1 id="dput">
- <heading><package>dput</package></heading>
- <p>
-The <package>dput</package> package and script does much the same
-thing as <package>dupload</package>, but in a different way. It has
-some features over <package>dupload</package>, such as the ability to
-check the GnuPG signature and checksums before uploading, and the
-possibility of running <prgn>dinstall</prgn> in dry-run mode after the
-upload.
- </sect1>
- <sect1 id="dcut">
- <heading><package>dcut</package></heading>
- <p>
-The <package>dcut</package> script (part of the package <ref id="dput">)
-helps in removing files from the ftp upload directory.
- </sect1>
- </sect>
-
- <sect id="tools-maint-automate">
- <heading>Maintenance automation</heading>
- <p>
-The following tools help automate different maintenance tasks, from
-adding changelog entries or signature lines and looking up bugs in Emacs
-to making use of the newest and official
-<file>config.sub</file>.</p>
-
- <sect1 id="devscripts">
- <heading><package>devscripts</package></heading>
- <p>
-<package>devscripts</package> is a package containing wrappers
-and tools which are very helpful for maintaining your Debian
-packages. Example scripts include <prgn>debchange</prgn> and
-<prgn>dch</prgn>, which manipulate your <file>debian/changelog</file>
-file from the command-line, and <prgn>debuild</prgn>, which is a
-wrapper around <prgn>dpkg-buildpackage</prgn>. The <prgn>bts</prgn>
-utility is also very helpful to update the state of bug reports on the
-command line. <prgn>uscan</prgn> can be used to watch for new upstream
-versions of your packages. <prgn>debrsign</prgn> can be used to
-remotely sign a package prior to upload, which is nice when the
-machine you build the package on is different from where your GPG keys
-are.</p>
- <p>
-See the <manref name="devscripts" section="1"> manual page for a
-complete list of available scripts.</p>
- </sect1>
-
- <sect1 id="autotools-dev">
- <heading><package>autotools-dev</package></heading>
- <p>
-<package>autotools-dev</package>
-contains best practices for people who maintain packages which use
-<prgn>autoconf</prgn> and/or <prgn>automake</prgn>. Also contains
-canonical <file>config.sub</file> and <file>config.guess</file> files
-which are known to work on all Debian ports.</p>
- </sect1>
-
- <sect1 id="dpkg-repack">
- <heading><package>dpkg-repack</package></heading>
- <p>
-<prgn>dpkg-repack</prgn> creates Debian package file out of a package
-that has already been installed. If any changes have been made to the
-package while it was unpacked (e.g., files in <file>/etc</file> were
-modified), the new package will inherit the changes.</p>
- <p>
-This utility can make it easy to copy packages from one computer to
-another, or to recreate packages which are installed on your system
-but no longer available elsewhere, or to save the current state of a
-package before you upgrade it.</p>
- </sect1>
-
- <sect1 id="alien">
- <heading><package>alien</package></heading>
- <p>
-<prgn>alien</prgn> converts binary packages between various packaging
-formats, including Debian, RPM (RedHat), LSB (Linux Standard Base),
-Solaris, and Slackware packages.</p>
- </sect1>
-
- <sect1 id="debsums">
- <heading><package>debsums</package></heading>
- <p>
-<prgn>debsums</prgn> checks installed packages against their MD5 sums.
-Note that not all packages have MD5 sums, since they aren't required
-by Policy.</p>
- </sect1>
-
- <sect1 id="dpkg-dev-el">
- <heading><package>dpkg-dev-el</package></heading>
- <p>
-<package>dpkg-dev-el</package> is an Emacs lisp package which provides
-assistance when editing some of the files in the <file>debian</file>
-directory of your package. For instance,
-there are handy functions for
-listing a package's current bugs,
-and for finalizing the latest entry in a
-<file>debian/changelog</file> file.
- </sect1>
-
- <sect1 id="dpkg-depcheck">
- <heading><package>dpkg-depcheck</package></heading>
- <p>
-<prgn>dpkg-depcheck</prgn> (from the <package>devscripts</package>
-package, <ref id="devscripts">)
-runs a command under <prgn>strace</prgn> to determine all the packages that
-were used by the said command.
- <p>
-For Debian packages, this is useful when you have to compose a
-<tt>Build-Depends</tt> line for your new package: running the build
-process through <prgn>dpkg-depcheck</prgn> will provide you with a
-good first approximation of the build-dependencies. For example:
-<example>
-dpkg-depcheck -b debian/rules build
-</example>
- <p>
-<prgn>dpkg-depcheck</prgn> can also be used to check for run-time
-dependencies, especially if your package uses exec(2) to run other
-programs.
- <p>
-For more information please see <manref name="dpkg-depcheck" section="1">.
- </sect1>
-
- </sect>
-
-
- <sect id="tools-porting">
- <heading>Porting tools</heading>
- <p>
-The following tools are helpful for porters and for
-cross-compilation.</p>
-
- <sect1 id="quinn-diff">
- <heading><package>quinn-diff</package>
- <p>
-<package>quinn-diff</package> is used to locate the differences from
-one architecture to another. For instance, it could tell you which
-packages need to be ported for architecture <var>Y</var>, based on
-architecture <var>X</var>.
-
- <sect1 id="dpkg-cross">
- <heading><package>dpkg-cross</package>
- <p>
-<package>dpkg-cross</package> is a tool for installing libraries and
-headers for cross-compiling in a way similar to
-<package>dpkg</package>. Furthermore, the functionality of
-<prgn>dpkg-buildpackage</prgn> and <prgn>dpkg-shlibdeps</prgn> is
-enhanced to support cross-compiling.
- </sect1>
-
-
- <sect id="tools-doc">
- <heading>Documentation and information</heading>
- <p>
-The following packages provide information for maintainers or help
-with building documentation.
-
- <sect1 id="debiandoc-sgml">
- <heading><package>debiandoc-sgml</package></heading>
- <p>
-<package>debiandoc-sgml</package> provides the DebianDoc SGML DTD,
-which is commonly used for Debian documentation. This manual, for
-instance, is written in DebianDoc. It also provides scripts for
-building and styling the source to various output formats.</p>
- <p>
-Documentation for the DTD can be found in the
-<package>debiandoc-sgml-doc</package> package.</p>
- </sect1>
-
- <sect1 id="debian-keyring">
- <heading><package>debian-keyring</package></heading>
- <p>
-Contains the public GPG and PGP keys of Debian developers. See <ref
-id="key-maint"> and the package documentation for more
-information.</p>
- </sect1>
-
- <sect1 id="debview">
- <heading><package>debview</package></heading>
- <p>
-<package>debview</package> provides an Emacs mode for viewing Debian
-binary packages. This lets you examine a package without unpacking
-it.</p>
- </sect1>
- </sect>
-
-<!-- FIXME: add the following
-
-questionable:
- dbs (referred to above)
- dpatch (referred to above)
- debarchiver
- ucf
- dpkg-awk
- grep-dctrl
- d-shlibs
- wajig
- magpie
- apt-dpkg-ref
- apt-show-source
- apt-show-versions
- pdbv
- epm
- apt-src
- apt-build
-
-rejected:
- debaux: too new, unmaintained?
- dh-make-perl: too new, unmaintained?
--->
-
- </appendix>
- </book>
-</debiandoc>
-
-<!-- Keep this comment at the end of the file
-Local variables:
-mode: sgml
-sgml-omittag:t
-sgml-shorttag:t
-sgml-minimize-attributes:nil
-sgml-always-quote-attributes:t
-sgml-indent-step:2
-sgml-indent-data:nil
-sgml-parent-document:nil
-sgml-exposed-tags:nil
-sgml-declaration:nil
-sgml-local-catalogs:nil
-sgml-local-ecat-files:nil
-End:
--->
--- /dev/null
+<?xml version="1.0"?>
+<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
+ version="1.0">
+ <xsl:import
+ href="http://docbook.sourceforge.net/release/xsl/current/xhtml/chunk.xsl"/>
+ <xsl:param name="chunk.section.depth">0</xsl:param>
+ <xsl:param name="section.autolabel">1</xsl:param>
+ <xsl:param name="section.label.includes.component.label">1</xsl:param>
+ <xsl:param name="use.id.as.filename">1</xsl:param>
+</xsl:stylesheet>
--- /dev/null
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
+ "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
+ <!ENTITY % commondata SYSTEM "common.ent" > %commondata;
+ <!ENTITY % versiondata SYSTEM "version.ent"> %versiondata;
+]>
+<book lang="en">
+
+<title>Debian Developer's Reference</title>
+<bookinfo>
+<author>
+<othername>Developer's Reference Team</othername>
+<email>&email-devel-ref;</email>
+</author>
+<author>
+<firstname>Andreas</firstname> <surname>Barth</surname>
+</author>
+<author>
+<firstname>Adam</firstname> <surname>Di Carlo</surname>
+</author>
+<author>
+<firstname>Raphaël</firstname> <surname>Hertzog</surname>
+</author>
+<author>
+<firstname>Christian</firstname> <surname>Schwarz</surname>
+</author>
+<author>
+<firstname>Ian</firstname> <surname>Jackson</surname>
+</author>
+<releaseinfo>ver. &version;</releaseinfo>
+<pubdate>&pubdate;</pubdate>
+<copyright>
+<year>2004</year>
+<year>2005</year>
+<year>2006</year>
+<year>2007</year>
+<holder>Andreas Barth</holder>
+</copyright>
+<copyright>
+<year>1998</year>
+<year>1999</year>
+<year>2000</year>
+<year>2001</year>
+<year>2002</year>
+<year>2003</year>
+<holder>Adam Di Carlo</holder>
+</copyright>
+<copyright>
+<year>2002</year>
+<year>2003</year>
+<holder>Raphaël Hertzog</holder>
+</copyright>
+<copyright>
+<year>1997</year>
+<year>1998</year>
+<holder>Christian Schwarz</holder>
+</copyright>
+<legalnotice>
+<para>
+This manual is free software; you may redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free Software
+Foundation; either version 2, or (at your option) any later version.
+</para>
+<para>
+This is distributed in the hope that it will be useful, but <emphasis>without
+any warranty</emphasis>; without even the implied warranty of merchantability
+or fitness for a particular purpose. See the GNU General Public License for
+more details.
+</para>
+<para>
+A copy of the GNU General Public License is available as
+&file-GPL; in the &debian-formal;
+distribution or on the World Wide Web at <ulink
+url="&url-gpl;">the GNU web site</ulink>. You can also obtain
+it by writing to the &fsf-addr;.
+</para>
+<para>
+If you want to print this reference, you should use the <ulink
+url="developers-reference.pdf">pdf version</ulink>. This page is also
+available in <ulink url="index.fr.html">French</ulink>.
+<!-- TODO: Maybe better: "This document has originally been written
+in English. Translations into different languages are available." -->
+</para>
+</legalnotice>
+<!-- toc -->
+</bookinfo>
+<xi:include href="scope.dbk"
+ xmlns:xi="http://www.w3.org/2003/XInclude"/>
+<xi:include href="new-maintainer.dbk"
+ xmlns:xi="http://www.w3.org/2003/XInclude"/>
+<xi:include href="developer-duties.dbk"
+ xmlns:xi="http://www.w3.org/2003/XInclude"/>
+<xi:include href="resources.dbk"
+ xmlns:xi="http://www.w3.org/2003/XInclude"/>
+<xi:include href="pkgs.dbk"
+ xmlns:xi="http://www.w3.org/2003/XInclude"/>
+<xi:include href="best-pkging-practices.dbk"
+ xmlns:xi="http://www.w3.org/2003/XInclude"/>
+<xi:include href="beyond-pkging.dbk"
+ xmlns:xi="http://www.w3.org/2003/XInclude"/>
+<xi:include href="l10n.dbk"
+ xmlns:xi="http://www.w3.org/2003/XInclude"/>
+<xi:include href="tools.dbk"
+ xmlns:xi="http://www.w3.org/2003/XInclude"/>
+</book>
--- /dev/null
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
+ "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
+ <!ENTITY % commondata SYSTEM "common.ent" > %commondata;
+]>
+<chapter id="l10n">
+<title>Internationalizing, translating, being internationalized and being translated</title>
+<para>
+Debian supports an ever-increasing number of natural languages. Even if you
+are a native English speaker and do not speak any other language, it is part of
+your duty as a maintainer to be aware of issues of internationalization
+(abbreviated i18n because there are 18 letters between the 'i' and the 'n' in
+internationalization). Therefore, even if you are ok with English-only
+programs, you should read most of this chapter.
+</para>
+<para>
+According to <ulink
+url="http://&www-debian-org;/doc/manuals/intro-i18n/">Introduction to
+i18n</ulink> from Tomohiro KUBOTA, I18N (internationalization) means
+modification of a software or related technologies so that a software can
+potentially handle multiple languages, customs, and so on in the world. while
+L10N (localization) means implementation of a specific language for an already
+internationalized software.
+</para>
+<para>
+l10n and i18n are interconnected, but the difficulties related to each of them
+are very different. It's not really difficult to allow a program to change the
+language in which texts are displayed based on user settings, but it is very
+time consuming to actually translate these messages. On the other hand,
+setting the character encoding is trivial, but adapting the code to use several
+character encodings is a really hard problem.
+</para>
+<para>
+Setting aside the i18n problems, where no general guideline can be given, there
+is actually no central infrastructure for l10n within Debian which could be
+compared to the dbuild mechanism for porting. So most of the work has to be
+done manually.
+</para>
+<section id="l10n-handling">
+<title>How translations are handled within Debian</title>
+<para>
+Handling translation of the texts contained in a package is still a manual
+task, and the process depends on the kind of text you want to see translated.
+</para>
+<para>
+For program messages, the gettext infrastructure is used most of the time.
+Most of the time, the translation is handled upstream within projects like the
+<ulink url="http://www.iro.umontreal.ca/contrib/po/HTML/">Free Translation
+Project</ulink>, the <ulink
+url="http://developer.gnome.org/projects/gtp/">Gnome translation
+Project</ulink> or the <ulink url="http://i18n.kde.org/">KDE one</ulink>. The
+only centralized resource within Debian is the <ulink
+url="http://&www-debian-org;/intl/l10n/">Central Debian translation
+statistics</ulink>, where you can find some statistics about the translation
+files found in the actual packages, but no real infrastructure to ease the
+translation process.
+</para>
+<para>
+An effort to translate the package descriptions started long ago, even if very
+little support is offered by the tools to actually use them (i.e., only APT can
+use them, when configured correctly). Maintainers don't need to do anything
+special to support translated package descriptions; translators should use the
+<ulink url="http://ddtp.debian.org/">DDTP</ulink>.
+</para>
+<para>
+For debconf templates, maintainers should use the po-debconf package to ease
+the work of translators, who could use the DDTP to do their work (but the
+French and Brazilian teams don't). Some statistics can be found both on the
+DDTP site (about what is actually translated), and on the <ulink
+url="http://&www-debian-org;/intl/l10n/">Central Debian translation
+statistics</ulink> site (about what is integrated in the packages).
+</para>
+<para>
+For web pages, each l10n team has access to the relevant CVS, and the
+statistics are available from the Central Debian translation statistics site.
+</para>
+<para>
+For general documentation about Debian, the process is more or less the same as
+for the web pages (the translators have access to the CVS), but there are no
+statistics pages.
+</para>
+<para>
+For package-specific documentation (man pages, info documents, other formats),
+almost everything remains to be done.
+</para>
+<para>
+Most notably, the KDE project handles translation of its documentation in the
+same way as its program messages.
+</para>
+<para>
+There is an effort to handle Debian-specific man pages within a <ulink
+url="&url-cvsweb;manpages/?cvsroot=debian-doc">specific CVS
+repository</ulink>.
+</para>
+</section>
+
+<section id="l10n-faqm">
+<title>I18N & L10N FAQ for maintainers</title>
+<para>
+This is a list of problems that maintainers may face concerning i18n and l10n.
+While reading this, keep in mind that there is no real consensus on these
+points within Debian, and that this is only advice. If you have a better idea
+for a given problem, or if you disagree on some points, feel free to provide
+your feedback, so that this document can be enhanced.
+</para>
+<section id="l10n-faqm-tr">
+<title>How to get a given text translated</title>
+<para>
+To translate package descriptions or debconf templates, you have nothing to do;
+the DDTP infrastructure will dispatch the material to translate to volunteers
+with no need for interaction from your part.
+</para>
+<para>
+For all other material (gettext files, man pages, or other documentation), the
+best solution is to put your text somewhere on the Internet, and ask on
+debian-i18n for a translation in different languages. Some translation team
+members are subscribed to this list, and they will take care of the translation
+and of the reviewing process. Once they are done, you will get your translated
+document from them in your mailbox.
+</para>
+</section>
+
+<section id="l10n-faqm-rev">
+<title>How to get a given translation reviewed</title>
+<para>
+From time to time, individuals translate some texts in your package and will
+ask you for inclusion of the translation in the package. This can become
+problematic if you are not fluent in the given language. It is a good idea to
+send the document to the corresponding l10n mailing list, asking for a review.
+Once it has been done, you should feel more confident in the quality of the
+translation, and feel safe to include it in your package.
+</para>
+</section>
+
+<section id="l10n-faqm-update">
+<title>How to get a given translation updated</title>
+<para>
+If you have some translations of a given text lying around, each time you
+update the original, you should ask the previous translator to update the
+translation with your new changes. Keep in mind that this task takes time; at
+least one week to get the update reviewed and all.
+</para>
+<para>
+If the translator is unresponsive, you may ask for help on the corresponding
+l10n mailing list. If everything fails, don't forget to put a warning in the
+translated document, stating that the translation is somehow outdated, and that
+the reader should refer to the original document if possible.
+</para>
+<para>
+Avoid removing a translation completely because it is outdated. Old
+documentation is often better than no documentation at all for non-English
+speakers.
+</para>
+</section>
+
+<section id="l10n-faqm-bug">
+<title>How to handle a bug report concerning a translation</title>
+<para>
+The best solution may be to mark the bug as forwarded to upstream, and forward
+it to both the previous translator and his/her team (using the corresponding
+debian-l10n-XXX mailing list).
+<!-- TODO: add the i18n tag to the bug? -->
+</para>
+</section>
+
+</section>
+
+<section id="l10n-faqtr">
+<title>I18N & L10N FAQ for translators</title>
+<para>
+While reading this, please keep in mind that there is no general procedure
+within Debian concerning these points, and that in any case, you should
+collaborate with your team and the package maintainer.
+</para>
+<section id="l10n-faqtr-help">
+<title>How to help the translation effort</title>
+<para>
+Choose what you want to translate, make sure that nobody is already working on
+it (using your debian-l10n-XXX mailing list), translate it, get it reviewed by
+other native speakers on your l10n mailing list, and provide it to the
+maintainer of the package (see next point).
+</para>
+</section>
+
+<section id="l10n-faqtr-inc">
+<title>How to provide a translation for inclusion in a package</title>
+<para>
+Make sure your translation is correct (asking for review on your l10n mailing
+list) before providing it for inclusion. It will save time for everyone, and
+avoid the chaos resulting in having several versions of the same document in
+bug reports.
+</para>
+<para>
+The best solution is to file a regular bug containing the translation against
+the package. Make sure to use the 'PATCH' tag, and to not use a severity
+higher than 'wishlist', since the lack of translation never prevented a program
+from running.
+</para>
+</section>
+
+</section>
+
+<section id="l10n-best">
+<title>Best current practice concerning l10n</title>
+<itemizedlist>
+<listitem>
+<para>
+As a maintainer, never edit the translations in any way (even to reformat the
+layout) without asking on the corresponding l10n mailing list. You risk for
+example breaksing the encoding of the file by doing so. Moreover, what you
+consider an error can be right (or even needed) in the given language.
+</para>
+</listitem>
+<listitem>
+<para>
+As a translator, if you find an error in the original text, make sure to report
+it. Translators are often the most attentive readers of a given text, and if
+they don't report the errors they find, nobody will.
+</para>
+</listitem>
+<listitem>
+<para>
+In any case, remember that the major issue with l10n is that it requires
+several people to cooperate, and that it is very easy to start a flamewar about
+small problems because of misunderstandings. So if you have problems with your
+interlocutor, ask for help on the corresponding l10n mailing list, on
+debian-i18n, or even on debian-devel (but beware, l10n discussions very often
+become flamewars on that list :)
+</para>
+</listitem>
+<listitem>
+<para>
+In any case, cooperation can only be achieved with <emphasis
+role="strong">mutual respect</emphasis>.
+</para>
+</listitem>
+</itemizedlist>
+</section>
+
+</chapter>
+
--- /dev/null
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
+ "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
+ <!ENTITY % commondata SYSTEM "common.ent" > %commondata;
+]>
+<chapter id="new-maintainer">
+<title>Applying to Become a Maintainer</title>
+<section id="getting-started">
+<title>Getting started</title>
+<para>
+So, you've read all the documentation, you've gone through the <ulink
+url="&url-newmaint-guide;">Debian New Maintainers'
+Guide</ulink>, understand what everything in the <systemitem
+role="package">hello</systemitem> example package is for, and you're about to
+Debianize your favorite piece of software. How do you actually become a Debian
+developer so that your work can be incorporated into the Project?
+</para>
+<para>
+Firstly, subscribe to &email-debian-devel; if you haven't
+already. Send the word <literal>subscribe</literal> in the
+<emphasis>Subject</emphasis> of an email to
+&email-debian-devel-req;. In case of problems, contact the
+list administrator at &email-listmaster;. More information on
+available mailing lists can be found in <xref linkend="mailing-lists"/> .
+&email-debian-devel-announce; is another list which is
+mandatory for anyone who wishes to follow Debian's development.
+</para>
+<para>
+You should subscribe and lurk (that is, read without posting) for a bit before
+doing any coding, and you should post about your intentions to work on
+something to avoid duplicated effort.
+</para>
+<para>
+Another good list to subscribe to is &email-debian-mentors;.
+See <xref linkend="mentors"/> for details. The IRC channel
+<literal>#debian</literal> can also be helpful; see <xref
+linkend="irc-channels"/> .
+</para>
+<para>
+When you know how you want to contribute to &debian-formal;,
+you should get in contact with existing Debian maintainers who are working on
+similar tasks. That way, you can learn from experienced developers. For
+example, if you are interested in packaging existing software for Debian, you
+should try to get a sponsor. A sponsor will work together with you on your
+package and upload it to the Debian archive once they are happy with the
+packaging work you have done. You can find a sponsor by mailing the
+&email-debian-mentors; mailing list, describing your package
+and yourself and asking for a sponsor (see <xref linkend="sponsoring"/> and
+<ulink url="&url-mentors;"></ulink> for more information on
+sponsoring). On the other hand, if you are interested in porting Debian to
+alternative architectures or kernels you can subscribe to port specific mailing
+lists and ask there how to get started. Finally, if you are interested in
+documentation or Quality Assurance (QA) work you can join maintainers already
+working on these tasks and submit patches and improvements.
+</para>
+<para>
+One pitfall could be a too-generic local part in your mailadress: Terms like
+mail, admin, root, master should be avoided, please see <ulink
+url="&url-debian-lists;"></ulink> for details.
+</para>
+</section>
+
+<section id="mentors">
+<title>Debian mentors and sponsors</title>
+<para>
+The mailing list &email-debian-mentors; has been set up for
+novice maintainers who seek help with initial packaging and other
+developer-related issues. Every new developer is invited to subscribe to that
+list (see <xref linkend="mailing-lists"/> for details).
+</para>
+<para>
+Those who prefer one-on-one help (e.g., via private email) should also post to
+that list and an experienced developer will volunteer to help.
+</para>
+<para>
+In addition, if you have some packages ready for inclusion in Debian, but are
+waiting for your new maintainer application to go through, you might be able
+find a sponsor to upload your package for you. Sponsors are people who are
+official Debian Developers, and who are willing to criticize and upload your
+packages for you.
+<!-- FIXME - out of order
+Those who are seeking a
+sponsor can request one at <ulink url="http://www.internatif.org/bortzmeyer/debian/sponsor/"></ulink>.
+-->
+Please read the unofficial debian-mentors FAQ at <ulink
+url="&url-mentors;"></ulink> first.
+</para>
+<para>
+If you wish to be a mentor and/or sponsor, more information is available in
+<xref linkend="newmaint"/> .
+</para>
+</section>
+
+<section id="registering">
+<title>Registering as a Debian developer</title>
+<para>
+Before you decide to register with &debian-formal;, you will
+need to read all the information available at the <ulink
+url="&url-newmaint;">New Maintainer's Corner</ulink>. It
+describes in detail the preparations you have to do before you can register to
+become a Debian developer. For example, before you apply, you have to read the
+<ulink url="&url-social-contract;">Debian Social
+Contract</ulink>. Registering as a developer means that you agree with and
+pledge to uphold the Debian Social Contract; it is very important that
+maintainers are in accord with the essential ideas behind
+&debian-formal;. Reading the <ulink
+url="&url-gnu-manifesto;">GNU Manifesto</ulink> would also be
+a good idea.
+</para>
+<para>
+The process of registering as a developer is a process of verifying your
+identity and intentions, and checking your technical skills. As the number of
+people working on &debian-formal; has grown to over
+&number-of-maintainers; and our systems are used in several
+very important places, we have to be careful about being compromised.
+Therefore, we need to verify new maintainers before we can give them accounts
+on our servers and let them upload packages.
+</para>
+<para>
+Before you actually register you should have shown that you can do competent
+work and will be a good contributor. You show this by submitting patches
+through the Bug Tracking System and having a package sponsored by an existing
+Debian Developer for a while. Also, we expect that contributors are interested
+in the whole project and not just in maintaining their own packages. If you
+can help other maintainers by providing further information on a bug or even a
+patch, then do so!
+</para>
+<para>
+Registration requires that you are familiar with Debian's philosophy and
+technical documentation. Furthermore, you need a GnuPG key which has been
+signed by an existing Debian maintainer. If your GnuPG key is not signed yet,
+you should try to meet a Debian Developer in person to get your key signed.
+There's a <ulink url="&url-gpg-coord;">GnuPG Key Signing
+Coordination page</ulink> which should help you find a Debian Developer close
+to you. (If there is no Debian Developer close to you, alternative ways to
+pass the ID check may be permitted as an absolute exception on a
+case-by-case-basis. See the <ulink
+url="&url-newmaint-id;">identification page</ulink> for more
+information.)
+</para>
+<para>
+If you do not have an OpenPGP key yet, generate one. Every developer needs an
+OpenPGP key in order to sign and verify package uploads. You should read the
+manual for the software you are using, since it has much important information
+which is critical to its security. Many more security failures are due to
+human error than to software failure or high-powered spy techniques. See <xref
+linkend="key-maint"/> for more information on maintaining your public key.
+</para>
+<para>
+Debian uses the <command>GNU Privacy Guard</command> (package <systemitem
+role="package">gnupg</systemitem> version 1 or better) as its baseline
+standard. You can use some other implementation of OpenPGP as well. Note that
+OpenPGP is an open standard based on <ulink
+url="&url-rfc2440;">RFC 2440</ulink>.
+</para>
+<para>
+You need a version 4 key for use in Debian Development. Your key length must
+be at least 1024 bits; there is no reason to use a smaller key, and doing so
+would be much less secure. <footnote><para> Version 4 keys are keys conforming
+to the OpenPGP standard as defined in RFC 2440. Version 4 is the key type that
+has always been created when using GnuPG. PGP versions since 5.x also could
+create v4 keys, the other choice having beein pgp 2.6.x compatible v3 keys
+(also called legacy RSA by PGP). </para> <para> Version 4 (primary) keys can
+either use the RSA or the DSA algorithms, so this has nothing to do with
+GnuPG's question about which kind of key do you want: (1) DSA and Elgamal, (2)
+DSA (sign only), (5) RSA (sign only). If you don't have any special
+requirements just pick the default. </para> <para> The easiest way to tell
+whether an existing key is a v4 key or a v3 (or v2) key is to look at the
+fingerprint: Fingerprints of version 4 keys are the SHA-1 hash of some key
+material, so they are 40 hex digits, usually grouped in blocks of 4.
+Fingerprints of older key format versions used MD5 and are generally shown in
+blocks of 2 hex digits. For example if your fingerprint looks like
+<literal>5B00 C96D 5D54 AEE1 206B AF84 DE7A AF6E 94C0 9C7F</literal>
+then it's a v4 key. </para> <para> Another possibility is to pipe the key into
+<command>pgpdump</command>, which will say something like Public Key Packet -
+Ver 4. </para> <para> Also note that your key must be self-signed (i.e. it
+has to sign all its own user IDs; this prevents user ID tampering). All modern
+OpenPGP software does that automatically, but if you have an older key you may
+have to manually add those signatures. </para> </footnote>
+</para>
+<para>
+If your public key isn't on a public key server such as
+&pgp-keyserv;, please read the documentation available at
+<ulink url="&url-newmaint-id;">NM Step 2:
+Identification</ulink>. That document contains instructions on how to put your
+key on the public key servers. The New Maintainer Group will put your public
+key on the servers if it isn't already there.
+</para>
+<para>
+Some countries restrict the use of cryptographic software by their citizens.
+This need not impede one's activities as a Debian package maintainer however,
+as it may be perfectly legal to use cryptographic products for authentication,
+rather than encryption purposes. If you live in a country where use of
+cryptography even for authentication is forbidden then please contact us so we
+can make special arrangements.
+</para>
+<para>
+To apply as a new maintainer, you need an existing Debian Developer to support
+your application (an <emphasis>advocate</emphasis>). After you have
+contributed to Debian for a while, and you want to apply to become a registered
+developer, an existing developer with whom you have worked over the past months
+has to express their belief that you can contribute to Debian successfully.
+</para>
+<para>
+When you have found an advocate, have your GnuPG key signed and have already
+contributed to Debian for a while, you're ready to apply. You can simply
+register on our <ulink url="&url-newmaint-apply;">application
+page</ulink>. After you have signed up, your advocate has to confirm your
+application. When your advocate has completed this step you will be assigned
+an Application Manager who will go with you through the necessary steps of the
+New Maintainer process. You can always check your status on the <ulink
+url="&url-newmaint-db;">applications status board</ulink>.
+</para>
+<para>
+For more details, please consult <ulink
+url="&url-newmaint;">New Maintainer's Corner</ulink> at the
+Debian web site. Make sure that you are familiar with the necessary steps of
+the New Maintainer process before actually applying. If you are well prepared,
+you can save a lot of time later on.
+</para>
+</section>
+
+</chapter>
+
--- /dev/null
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
+ "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
+ <!ENTITY % commondata SYSTEM "common.ent" > %commondata;
+]>
+<chapter id="pkgs">
+<title>Managing Packages</title>
+<para>
+This chapter contains information related to creating, uploading, maintaining,
+and porting packages.
+</para>
+<section id="newpackage">
+<title>New packages</title>
+<para>
+If you want to create a new package for the Debian distribution, you should
+first check the <ulink url="&url-wnpp;">Work-Needing and
+Prospective Packages (WNPP)</ulink> list. Checking the WNPP list ensures that
+no one is already working on packaging that software, and that effort is not
+duplicated. Read the <ulink url="&url-wnpp;">WNPP web
+pages</ulink> for more information.
+</para>
+<para>
+Assuming no one else is already working on your prospective package, you must
+then submit a bug report (<xref linkend="submit-bug"/> ) against the
+pseudo-package <systemitem role="package">wnpp</systemitem> describing your
+plan to create a new package, including, but not limiting yourself to, a
+description of the package, the license of the prospective package, and the
+current URL where it can be downloaded from.
+</para>
+<para>
+You should set the subject of the bug to ``ITP: <replaceable>foo</replaceable>
+-- <replaceable>short description</replaceable>'', substituting the name of the
+new package for <replaceable>foo</replaceable>. The severity of the bug report
+must be set to <emphasis>wishlist</emphasis>. If you feel it's necessary, send
+a copy to &email-debian-devel; by putting the address in the
+<literal>X-Debbugs-CC:</literal> header of the message (no, don't use
+<literal>CC:</literal>, because that way the message's subject won't indicate
+the bug number).
+</para>
+<para>
+Please include a <literal>Closes:
+bug#<replaceable>nnnnn</replaceable></literal> entry in the changelog of the
+new package in order for the bug report to be automatically closed once the new
+package is installed in the archive (see <xref linkend="upload-bugfix"/> ).
+</para>
+<para>
+When closing security bugs include CVE numbers as well as the Closes: #nnnnn.
+This is useful for the security team to track vulnerabilities. If an upload is
+made to fix the bug before the advisory ID is known, it is encouraged to modify
+the historical changelog entry with the next upload. Even in this case, please
+include all available pointers to background information in the original
+changelog entry.
+</para>
+<para>
+There are a number of reasons why we ask maintainers to announce their
+intentions:
+</para>
+<itemizedlist>
+<listitem>
+<para>
+It helps the (potentially new) maintainer to tap into the experience of people
+on the list, and lets them know if anyone else is working on it already.
+</para>
+</listitem>
+<listitem>
+<para>
+It lets other people thinking about working on the package know that there
+already is a volunteer, so efforts may be shared.
+</para>
+</listitem>
+<listitem>
+<para>
+It lets the rest of the maintainers know more about the package than the one
+line description and the usual changelog entry ``Initial release'' that gets
+posted to <literal>debian-devel-changes</literal>.
+</para>
+</listitem>
+<listitem>
+<para>
+It is helpful to the people who live off unstable (and form our first line of
+testers). We should encourage these people.
+</para>
+</listitem>
+<listitem>
+<para>
+The announcements give maintainers and other interested parties a better feel
+of what is going on, and what is new, in the project.
+</para>
+</listitem>
+</itemizedlist>
+<para>
+Please see <ulink url="http://&ftp-master-host;/REJECT-FAQ.html"></ulink>
+for common rejection reasons for a new package.
+</para>
+</section>
+
+<section id="changelog-entries">
+<title>Recording changes in the package</title>
+<para>
+Changes that you make to the package need to be recorded in the
+<filename>debian/changelog</filename>. These changes should provide a concise
+description of what was changed, why (if it's in doubt), and note if any bugs
+were closed. They also record when the package was completed. This file will
+be installed in
+<filename>/usr/share/doc/<replaceable>package</replaceable>/changelog.Debian.gz</filename>,
+or
+<filename>/usr/share/doc/<replaceable>package</replaceable>/changelog.gz</filename>
+for native packages.
+</para>
+<para>
+The <filename>debian/changelog</filename> file conforms to a certain structure,
+with a number of different fields. One field of note, the
+<emphasis>distribution</emphasis>, is described in <xref
+linkend="distribution"/> . More information about the structure of this file
+can be found in the Debian Policy section titled
+<filename>debian/changelog</filename>.
+</para>
+<para>
+Changelog entries can be used to automatically close Debian bugs when the
+package is installed into the archive. See <xref linkend="upload-bugfix"/> .
+</para>
+<para>
+It is conventional that the changelog entry of a package that contains a new
+upstream version of the software looks like this:
+</para>
+<screen>
+ * new upstream version
+</screen>
+<para>
+There are tools to help you create entries and finalize the
+<filename>changelog</filename> for release — see <xref linkend="devscripts"/>
+and <xref linkend="dpkg-dev-el"/> .
+</para>
+<para>
+See also <xref linkend="bpp-debian-changelog"/> .
+</para>
+</section>
+
+<section id="sanitycheck">
+<title>Testing the package</title>
+<para>
+Before you upload your package, you should do basic testing on it. At a
+minimum, you should try the following activities (you'll need to have an older
+version of the same Debian package around):
+</para>
+<itemizedlist>
+<listitem>
+<para>
+Install the package and make sure the software works, or upgrade the package
+from an older version to your new version if a Debian package for it already
+exists.
+</para>
+</listitem>
+<listitem>
+<para>
+Run <command>lintian</command> over the package. You can run
+<command>lintian</command> as follows: <literal>lintian -v
+<replaceable>package-version</replaceable>.changes</literal>. This will check
+the source package as well as the binary package. If you don't understand the
+output that <command>lintian</command> generates, try adding the
+<literal>-i</literal> switch, which will cause <command>lintian</command> to
+output a very verbose description of the problem.
+</para>
+<para>
+Normally, a package should <emphasis>not</emphasis> be uploaded if it causes
+lintian to emit errors (they will start with <literal>E</literal>).
+</para>
+<para>
+For more information on <command>lintian</command>, see <xref
+linkend="lintian"/> .
+</para>
+</listitem>
+<listitem>
+<para>
+Optionally run <xref linkend="debdiff"/> to analyze changes from an older
+version, if one exists.
+</para>
+</listitem>
+<listitem>
+<para>
+Downgrade the package to the previous version (if one exists) — this tests
+the <filename>postrm</filename> and <filename>prerm</filename> scripts.
+</para>
+</listitem>
+<listitem>
+<para>
+Remove the package, then reinstall it.
+</para>
+</listitem>
+<listitem>
+<para>
+Copy the source package in a different directory and try unpacking it and
+rebuilding it. This tests if the package relies on existing files outside of
+it, or if it relies on permissions being preserved on the files shipped inside
+the .diff.gz file.
+</para>
+</listitem>
+</itemizedlist>
+</section>
+
+<section id="sourcelayout">
+<title>Layout of the source package</title>
+<para>
+There are two types of Debian source packages:
+</para>
+<itemizedlist>
+<listitem>
+<para>
+the so-called <emphasis>native</emphasis> packages, where there is no
+distinction between the original sources and the patches applied for Debian
+</para>
+</listitem>
+<listitem>
+<para>
+the (more common) packages where there's an original source tarball file
+accompanied by another file that contains the patches applied for Debian
+</para>
+</listitem>
+</itemizedlist>
+<para>
+For the native packages, the source package includes a Debian source control
+file (<literal>.dsc</literal>) and the source tarball
+(<literal>.tar.gz</literal>). A source package of a non-native package
+includes a Debian source control file, the original source tarball
+(<literal>.orig.tar.gz</literal>) and the Debian patches
+(<literal>.diff.gz</literal>).
+</para>
+<para>
+Whether a package is native or not is determined when it is built by
+<citerefentry> <refentrytitle>dpkg-buildpackage</refentrytitle>
+<manvolnum>1</manvolnum> </citerefentry>. The rest of this section relates
+only to non-native packages.
+</para>
+<para>
+The first time a version is uploaded which corresponds to a particular upstream
+version, the original source tar file should be uploaded and included in the
+<filename>.changes</filename> file. Subsequently, this very same tar file
+should be used to build the new diffs and <filename>.dsc</filename> files, and
+will not need to be re-uploaded.
+</para>
+<para>
+By default, <command>dpkg-genchanges</command> and
+<command>dpkg-buildpackage</command> will include the original source tar file
+if and only if the Debian revision part of the source version number is 0 or 1,
+indicating a new upstream version. This behavior may be modified by using
+<literal>-sa</literal> to always include it or <literal>-sd</literal> to always
+leave it out.
+</para>
+<para>
+If no original source is included in the upload, the original source tar-file
+used by <command>dpkg-source</command> when constructing the
+<filename>.dsc</filename> file and diff to be uploaded
+<emphasis>must</emphasis> be byte-for-byte identical with the one already in
+the archive.
+</para>
+<para>
+Please notice that, in non-native packages, permissions on files that are not
+present in the .orig.tar.gz will not be preserved, as diff does not store file
+permissions in the patch.
+</para>
+</section>
+
+<section id="distribution">
+<title>Picking a distribution</title>
+<para>
+Each upload needs to specify which distribution the package is intended for.
+The package build process extracts this information from the first line of the
+<filename>debian/changelog</filename> file and places it in the
+<literal>Distribution</literal> field of the <literal>.changes</literal> file.
+</para>
+<para>
+There are several possible values for this field: `stable', `unstable',
+`testing-proposed-updates' and `experimental'. Normally, packages are uploaded
+into <emphasis>unstable</emphasis>.
+</para>
+<para>
+Actually, there are two other possible distributions: `stable-security' and
+`testing-security', but read <xref linkend="bug-security"/> for more
+information on those.
+</para>
+<para>
+It is not possible to upload a package into several distributions at the same
+time.
+</para>
+<section id="upload-stable">
+<title>Special case: uploads to the <emphasis>stable</emphasis> distribution</title>
+<para>
+Uploading to <emphasis>stable</emphasis> means that the package will transfered
+to the <emphasis>p-u-new</emphasis>-queue for review by the stable release
+managers, and if approved will be installed in
+<filename>stable-proposed-updates</filename> directory of the Debian archive.
+From there, it will be included in <emphasis>stable</emphasis> with the next
+point release.
+</para>
+<para>
+Extra care should be taken when uploading to <emphasis>stable</emphasis>.
+Basically, a package should only be uploaded to stable if one of the following
+happens:
+</para>
+<itemizedlist>
+<listitem>
+<para>
+a truly critical functionality problem
+</para>
+</listitem>
+<listitem>
+<para>
+the package becomes uninstallable
+</para>
+</listitem>
+<listitem>
+<para>
+a released architecture lacks the package
+</para>
+</listitem>
+</itemizedlist>
+<para>
+In the past, uploads to <emphasis>stable</emphasis> were used to address
+security problems as well. However, this practice is deprecated, as uploads
+used for Debian security advisories are automatically copied to the appropriate
+<filename>proposed-updates</filename> archive when the advisory is released.
+See <xref linkend="bug-security"/> for detailed information on handling
+security problems.
+</para>
+<para>
+Changing anything else in the package that isn't important is discouraged,
+because even trivial fixes can cause bugs later on.
+</para>
+<para>
+Packages uploaded to <emphasis>stable</emphasis> need to be compiled on systems
+running <emphasis>stable</emphasis>, so that their dependencies are limited to
+the libraries (and other packages) available in <emphasis>stable</emphasis>;
+for example, a package uploaded to <emphasis>stable</emphasis> that depends on
+a library package that only exists in unstable will be rejected. Making
+changes to dependencies of other packages (by messing with
+<literal>Provides</literal> or shlibs files), possibly making those other
+packages uninstallable, is strongly discouraged.
+</para>
+<para>
+The Release Team (which can be reached at
+&email-debian-release;) will regularly evaluate the uploads To
+<emphasis>stable-proposed-updates</emphasis> and decide if your package can be
+included in <emphasis>stable</emphasis>. Please be clear (and verbose, if
+necessary) in your changelog entries for uploads to
+<emphasis>stable</emphasis>, because otherwise the package won't be considered
+for inclusion.
+</para>
+<para>
+It's best practice to speak with the stable release manager
+<emphasis>before</emphasis> uploading to
+<emphasis>stable</emphasis>/<emphasis>stable-proposed-updates</emphasis>, so
+that the uploaded package fits the needs of the next point release.
+</para>
+</section>
+
+<section id="upload-t-p-u">
+<title>Special case: uploads to <emphasis>testing/testing-proposed-updates</emphasis></title>
+<para>
+Please see the information in the <link linkend="t-p-u">testing
+section</link> for details.
+</para>
+</section>
+
+</section>
+
+<section id="upload">
+<title>Uploading a package</title>
+<section id="upload-ftp-master">
+<title>Uploading to <literal>ftp-master</literal></title>
+<para>
+To upload a package, you should upload the files (including the signed changes
+and dsc-file) with anonymous ftp to <literal>&ftp-master-host;</literal> in
+the directory <ulink
+url="ftp://&ftp-master-host;&upload-queue;">&upload-queue;</ulink>.
+To get the files processed there, they need to be signed with a key in the
+debian keyring.
+</para>
+<para>
+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 all files have been uploaded.
+</para>
+<para>
+You may also find the Debian packages <xref linkend="dupload"/> or <xref
+linkend="dput"/> useful when uploading packages. These handy programs help
+automate the process of uploading packages into Debian.
+</para>
+<para>
+For removing packages, please see the README file in that ftp directory, and
+the Debian package <xref linkend="dcut"/> .
+</para>
+</section>
+
+<section id="delayed-incoming">
+<title>Delayed uploads</title>
+<para>
+Delayed uploads are done for the moment via the delayed queue at gluck. The
+upload-directory is <literal>gluck:~tfheen/DELAYED/[012345678]-day</literal>.
+0-day is uploaded multiple times per day to ftp-master.
+</para>
+<para>
+With a fairly recent dput, this section
+</para>
+<screen>
+[tfheen_delayed]
+method = scp
+fqdn = gluck.debian.org
+incoming = ~tfheen
+</screen>
+<para>
+in ~/.dput.cf should work fine for uploading to the DELAYED queue.
+</para>
+<para>
+<emphasis>Note:</emphasis> Since this upload queue goes to
+<literal>ftp-master</literal>, the prescription found in <xref
+linkend="upload-ftp-master"/> applies here as well.
+</para>
+</section>
+
+<section id="s5.6.4">
+<title>Security uploads</title>
+<para>
+Do <emphasis role="strong">NOT</emphasis> 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. For details, please see section <xref
+linkend="bug-security"/> .
+</para>
+</section>
+
+<section id="s5.6.5">
+<title>Other upload queues</title>
+<para>
+The scp queues on ftp-master, and security are mostly unusable due to the login
+restrictions on those hosts.
+</para>
+<para>
+The anonymous queues on ftp.uni-erlangen.de and ftp.uk.debian.org are currently
+down. Work is underway to resurrect them.
+</para>
+<para>
+The queues on master.debian.org, samosa.debian.org, master.debian.or.jp, and
+ftp.chiark.greenend.org.uk are down permanently, and will not be resurrected.
+The queue in Japan will be replaced with a new queue on hp.debian.or.jp some
+day.
+</para>
+<para>
+For the time being, the anonymous ftp queue on auric.debian.org (the former
+ftp-master) works, but it is deprecated and will be removed at some point in
+the future.
+</para>
+</section>
+
+<section id="upload-notification">
+<title>Notification that a new package has been installed</title>
+<para>
+The Debian archive maintainers are responsible for handling package uploads.
+For the most part, uploads are automatically handled on a daily basis by the
+archive maintenance tools, <command>katie</command>. Specifically, updates to
+existing packages to the `unstable' distribution are handled automatically. In
+other cases, notably new packages, placing the uploaded package into the
+distribution is handled manually. When uploads are handled manually, the
+change to the archive may take up to a month to occur. Please be patient.
+</para>
+<para>
+In any case, you will receive an email notification indicating that the package
+has been added to the archive, which also indicates which bugs will be closed
+by the upload. Please examine this notification carefully, checking if any
+bugs you meant to close didn't get triggered.
+</para>
+<para>
+The installation notification also includes information on what section the
+package was inserted into. If there is a disparity, you will receive a
+separate email notifying you of that. Read on below.
+</para>
+<para>
+Note that if you upload via queues, the queue daemon software will also send
+you a notification by email.
+</para>
+</section>
+
+</section>
+
+<section id="override-file">
+<title>Specifying the package section, subsection and priority</title>
+<para>
+The <filename>debian/control</filename> file's <literal>Section</literal> and
+<literal>Priority</literal> fields do not actually specify where the file will
+be placed in the archive, nor its priority. In order to retain the overall
+integrity of the archive, it is the archive maintainers who have control over
+these fields. The values in the <filename>debian/control</filename> file are
+actually just hints.
+</para>
+<para>
+The archive maintainers keep track of the canonical sections and priorities for
+packages in the <emphasis>override file</emphasis>. If there is a disparity
+between the <emphasis>override file</emphasis> and the package's fields as
+indicated in <filename>debian/control</filename>, then you will receive an
+email noting the divergence when the package is installed into the archive.
+You can either correct your <filename>debian/control</filename> file for your
+next upload, or else you may wish to make a change in the <emphasis>override
+file</emphasis>.
+</para>
+<para>
+To alter the actual section that a package is put in, you need to first make
+sure that the <filename>debian/control</filename> file in your package is
+accurate. Next, send an email &email-override; or submit a
+bug against <systemitem role="package">ftp.debian.org</systemitem> requesting
+that the section or priority for your package be changed from the old section
+or priority to the new one. Be sure to explain your reasoning.
+</para>
+<para>
+For more information about <emphasis>override files</emphasis>, see
+<citerefentry> <refentrytitle>dpkg-scanpackages</refentrytitle>
+<manvolnum>1</manvolnum> </citerefentry> and <ulink
+url="&url-bts-devel;#maintincorrect"></ulink>.
+</para>
+<para>
+Note that the <literal>Section</literal> field describes both the section as
+well as the subsection, which are described in <xref
+linkend="archive-sections"/> . If the section is main, it should be omitted.
+The list of allowable subsections can be found in <ulink
+url="&url-debian-policy;ch-archive.html#s-subsections"></ulink>.
+</para>
+</section>
+
+<section id="bug-handling">
+<title>Handling bugs</title>
+<para>
+Every developer has to be able to work with the Debian <ulink
+url="&url-bts;">bug tracking system</ulink>. This includes
+knowing how to file bug reports properly (see <xref linkend="submit-bug"/> ),
+how to update them and reorder them, and how to process and close them.
+</para>
+<para>
+The bug tracking system's features are described in the <ulink
+url="&url-bts-devel;">BTS documentation for
+developers</ulink>. This includes closing bugs, sending followup messages,
+assigning severities and tags, marking bugs as forwarded, and other issues.
+</para>
+<para>
+Operations such as reassigning bugs to other packages, merging separate bug
+reports about the same issue, or reopening bugs when they are prematurely
+closed, are handled using the so-called control mail server. All of the
+commands available on this server are described in the <ulink
+url="&url-bts-control;">BTS control server
+documentation</ulink>.
+</para>
+<section id="bug-monitoring">
+<title>Monitoring bugs</title>
+<para>
+If you want to be a good maintainer, you should periodically check the <ulink
+url="&url-bts;">Debian bug tracking system (BTS)</ulink> for
+your packages. The BTS contains all the open bugs against your packages. You
+can check them by browsing this page:
+<literal>http://&bugs-host;/<replaceable>yourlogin</replaceable>@debian.org</literal>.
+</para>
+<para>
+Maintainers interact with the BTS via email addresses at
+<literal>&bugs-host;</literal>. Documentation on available
+commands can be found at <ulink url="&url-bts;"></ulink>, or,
+if you have installed the <systemitem role="package">doc-debian</systemitem>
+package, you can look at the local files &file-bts-docs;.
+</para>
+<para>
+Some find it useful to get periodic reports on open bugs. You can add a cron
+job such as the following if you want to get a weekly email outlining all the
+open bugs against your packages:
+</para>
+<screen>
+# ask for weekly reports of bugs in my packages
+&cron-bug-report;
+</screen>
+<para>
+Replace <replaceable>address</replaceable> with your official Debian maintainer
+address.
+</para>
+</section>
+
+<section id="bug-answering">
+<title>Responding to bugs</title>
+<para>
+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.,
+<email>123@&bugs-host;</email>). If you're writing a new mail and you
+don't remember the submitter email address, you can use the
+<email>123-submitter@&bugs-host;</email> email to contact the submitter
+<emphasis>and</emphasis> to record your mail within the bug log (that means you
+don't need to send a copy of the mail to <email>123@&bugs-host;</email>).
+</para>
+<para>
+If you get a bug which mentions FTBFS, this means Fails to build from source.
+Porters frequently use this acronym.
+</para>
+<para>
+Once you've dealt with a bug report (e.g. fixed it), mark it as
+<emphasis>done</emphasis> (close it) by sending an explanation message to
+<email>123-done@&bugs-host;</email>. If you're fixing a bug by changing
+and uploading the package, you can automate bug closing as described in <xref
+linkend="upload-bugfix"/> .
+</para>
+<para>
+You should <emphasis>never</emphasis> close bugs via the bug server
+<literal>close</literal> command sent to &email-bts-control;.
+If you do so, the original submitter will not receive any information about why
+the bug was closed.
+</para>
+</section>
+
+<section id="bug-housekeeping">
+<title>Bug housekeeping</title>
+<para>
+As a package maintainer, you will often find bugs in other packages or have
+bugs reported against your packages which are actually bugs in other packages.
+The bug tracking system's features are described in the <ulink
+url="&url-bts-devel;">BTS documentation for Debian
+developers</ulink>. Operations such as reassigning, merging, and tagging bug
+reports are described in the <ulink
+url="&url-bts-control;">BTS control server
+documentation</ulink>. This section contains some guidelines for managing your
+own bugs, based on the collective Debian developer experience.
+</para>
+<para>
+Filing bugs for problems that you find in other packages is one of the civic
+obligations of maintainership, see <xref linkend="submit-bug"/> for details.
+However, handling the bugs in your own packages is even more important.
+</para>
+<para>
+Here's a list of steps that you may follow to handle a bug report:
+</para>
+<orderedlist numeration="arabic">
+<listitem>
+<para>
+Decide whether the report corresponds to a real bug or not. Sometimes users
+are just calling a program in the wrong way because they haven't read the
+documentation. If you diagnose this, just close the bug with enough
+information to let the user correct their problem (give pointers to the good
+documentation and so on). If the same report comes up again and again you may
+ask yourself if the documentation is good enough or if the program shouldn't
+detect its misuse in order to give an informative error message. This is an
+issue that may need to be brought up with the upstream author.
+</para>
+<para>
+If the bug submitter disagrees with your decision to close the bug, they may
+reopen it until you find an agreement on how to handle it. If you don't find
+any, you may want to tag the bug <literal>wontfix</literal> to let people know
+that the bug exists but that it won't be corrected. If this situation is
+unacceptable, you (or the submitter) may want to require a decision of the
+technical committee by reassigning the bug to <systemitem
+role="package">tech-ctte</systemitem> (you may use the clone command of the BTS
+if you wish to keep it reported against your package). Before doing so, please
+read the <ulink url="&url-tech-ctte;">recommended
+procedure</ulink>.
+</para>
+</listitem>
+<listitem>
+<para>
+If the bug is real but it's caused by another package, just reassign the bug to
+the right package. If you don't know which package it should be reassigned to,
+you should ask for help on <link linkend="irc-channels">IRC</link> or
+on &email-debian-devel;. Please make sure that the
+maintainer(s) of the package the bug is reassigned to know why you reassigned
+it.
+</para>
+<para>
+Sometimes you also have to adjust the severity of the bug so that it matches
+our definition of the severity. That's because people tend to inflate the
+severity of bugs to make sure their bugs are fixed quickly. Some bugs may even
+be dropped to wishlist severity when the requested change is just cosmetic.
+</para>
+</listitem>
+<listitem>
+<para>
+If the bug is real but the same problem has already been reported by someone
+else, then the two relevant bug reports should be merged into one using the
+merge command of the BTS. In this way, when the bug is fixed, all of the
+submitters will be informed of this. (Note, however, that emails sent to one
+bug report's submitter won't automatically be sent to the other report's
+submitter.) For more details on the technicalities of the merge command and its
+relative, the unmerge command, see the BTS control server documentation.
+</para>
+</listitem>
+<listitem>
+<para>
+The bug submitter may have forgotten to provide some information, in which case
+you have to ask them for the required information. You may use the
+<literal>moreinfo</literal> tag to mark the bug as such. Moreover if you can't
+reproduce the bug, you tag it <literal>unreproducible</literal>. Anyone who
+can reproduce the bug is then invited to provide more information on how to
+reproduce it. After a few months, if this information has not been sent by
+someone, the bug may be closed.
+</para>
+</listitem>
+<listitem>
+<para>
+If the bug is related to the packaging, you just fix it. If you are not able
+to fix it yourself, then tag the bug as <literal>help</literal>. You can also
+ask for help on &email-debian-devel; or
+&email-debian-qa;. If it's an upstream problem, you have to
+forward it to the upstream author. Forwarding a bug is not enough, you have to
+check at each release if the bug has been fixed or not. If it has, you just
+close it, otherwise you have to remind the author about it. If you have the
+required skills you can prepare a patch that fixes the bug and send it to the
+author at the same time. Make sure to send the patch to the BTS and to tag the
+bug as <literal>patch</literal>.
+</para>
+</listitem>
+<listitem>
+<para>
+If you have fixed a bug in your local copy, or if a fix has been committed to
+the CVS repository, you may tag the bug as <literal>pending</literal> to let
+people know that the bug is corrected and that it will be closed with the next
+upload (add the <literal>closes:</literal> in the
+<filename>changelog</filename>). This is particularly useful if you are
+several developers working on the same package.
+</para>
+</listitem>
+<listitem>
+<para>
+Once a corrected package is available in the <emphasis>unstable</emphasis>
+distribution, you can close the bug. This can be done automatically, read
+<xref linkend="upload-bugfix"/> .
+</para>
+</listitem>
+</orderedlist>
+</section>
+
+<section id="upload-bugfix">
+<title>When bugs are closed by new uploads</title>
+<para>
+As bugs and problems are fixed in your packages, it is your responsibility as
+the package maintainer to close these bugs. However, you should not close a
+bug until the package which fixes the bug has been accepted into the Debian
+archive. Therefore, once you get notification that your updated package has
+been installed into the archive, you can and should close the bug in the BTS.
+Also, the bug should be closed with the correct version.
+</para>
+<para>
+However, it's possible to avoid having to manually close bugs after the upload
+— just list the fixed bugs in your <filename>debian/changelog</filename>
+file, following a certain syntax, and the archive maintenance software will
+close the bugs for you. For example:
+</para>
+<screen>
+acme-cannon (3.1415) unstable; urgency=low
+
+ * Frobbed with options (closes: Bug#98339)
+ * Added safety to prevent operator dismemberment, closes: bug#98765,
+ bug#98713, #98714.
+ * Added man page. Closes: #98725.
+</screen>
+<para>
+Technically speaking, the following Perl regular expression describes how bug
+closing changelogs are identified:
+</para>
+<screen>
+ /closes:\s*(?:bug)?\#\s*\d+(?:,\s*(?:bug)?\#\s*\d+)*/ig
+</screen>
+<para>
+We prefer the <literal>closes: #<replaceable>XXX</replaceable></literal>
+syntax, as it is the most concise entry and the easiest to integrate with the
+text of the <filename>changelog</filename>. Unless specified different by the
+<replaceable>-v</replaceable>-switch to <command>dpkg-buildpackage</command>,
+only the bugs closed in the most recent changelog entry are closed (basically,
+exactly the bugs mentioned in the changelog-part in the
+<filename>.changes</filename> file are closed).
+</para>
+<para>
+Historically, uploads identified as <link linkend="nmu">Non-maintainer
+upload (NMU)</link> were tagged <literal>fixed</literal> instead of being
+closed, but that practice was ceased with the advent of version-tracking. The
+same applied to the tag <literal>fixed-in-experimental</literal>.
+</para>
+<para>
+If you happen to mistype a bug number or forget a bug in the changelog entries,
+don't hesitate to undo any damage the error caused. To reopen wrongly closed
+bugs, send a <literal>reopen <replaceable>XXX</replaceable></literal> command
+to the bug tracking system's control address,
+&email-bts-control;. To close any remaining bugs that were
+fixed by your upload, email the <filename>.changes</filename> file to
+<email>XXX-done@&bugs-host;</email>, where <replaceable>XXX</replaceable>
+is the bug number, and put Version: YYY and an empty line as the first two
+lines of the body of the email, where <replaceable>YYY</replaceable> is the
+first version where the bug has been fixed.
+</para>
+<para>
+Bear in mind that it is not obligatory to close bugs using the changelog as
+described above. If you simply want to close bugs that don't have anything to
+do with an upload you made, do it by emailing an explanation to
+<email>XXX-done@&bugs-host;</email>. Do <emphasis
+role="strong">not</emphasis> close bugs in the changelog entry of a version if
+the changes in that version of the package don't have any bearing on the bug.
+</para>
+<para>
+For general information on how to write your changelog entries, see <xref
+linkend="bpp-debian-changelog"/> .
+</para>
+</section>
+
+<section id="bug-security">
+<title>Handling security-related bugs</title>
+<para>
+Due to their sensitive nature, security-related bugs must be handled carefully.
+The Debian Security Team exists to coordinate this activity, keeping track of
+outstanding security problems, helping maintainers with security problems or
+fixing them themselves, sending security advisories, and maintaining
+security.debian.org.
+</para>
+<!-- information about the security database goes here once it's ready -->
+<!-- (mdz) -->
+<para>
+When you become aware of a security-related bug in a Debian package, whether or
+not you are the maintainer, collect pertinent information about the problem,
+and promptly contact the security team at
+&email-security-team; as soon as possible. <emphasis
+role="strong">DO NOT UPLOAD</emphasis> any packages for stable; the security
+team will do that. Useful information includes, for example:
+</para>
+<itemizedlist>
+<listitem>
+<para>
+Which versions of the package are known to be affected by the bug. Check each
+version that is present in a supported Debian release, as well as testing and
+unstable.
+</para>
+</listitem>
+<listitem>
+<para>
+The nature of the fix, if any is available (patches are especially helpful)
+</para>
+</listitem>
+<listitem>
+<para>
+Any fixed packages that you have prepared yourself (send only the
+<literal>.diff.gz</literal> and <literal>.dsc</literal> files and read <xref
+linkend="bug-security-building"/> first)
+</para>
+</listitem>
+<listitem>
+<para>
+Any assistance you can provide to help with testing (exploits, regression
+testing, etc.)
+</para>
+</listitem>
+<listitem>
+<para>
+Any information needed for the advisory (see <xref
+linkend="bug-security-advisories"/> )
+</para>
+</listitem>
+</itemizedlist>
+<section id="bug-security-confidentiality">
+<title>Confidentiality</title>
+<para>
+Unlike most other activities within Debian, information about security issues
+must sometimes be kept private for a time. This allows software distributors
+to coordinate their disclosure in order to minimize their users' exposure.
+Whether this is the case depends on the nature of the problem and corresponding
+fix, and whether it is already a matter of public knowledge.
+</para>
+<para>
+There are several ways developers can learn of a security problem:
+</para>
+<itemizedlist>
+<listitem>
+<para>
+they notice it on a public forum (mailing list, web site, etc.)
+</para>
+</listitem>
+<listitem>
+<para>
+someone files a bug report
+</para>
+</listitem>
+<listitem>
+<para>
+someone informs them via private email
+</para>
+</listitem>
+</itemizedlist>
+<para>
+In the first two cases, the information is public and it is important to have a
+fix as soon as possible. In the last case, however, it might not be public
+information. In that case there are a few possible options for dealing with
+the problem:
+</para>
+<itemizedlist>
+<listitem>
+<para>
+If the security exposure is minor, there is sometimes no need to keep the
+problem a secret and a fix should be made and released.
+</para>
+</listitem>
+<listitem>
+<para>
+If the problem is severe, it is preferable to share the information with other
+vendors and coordinate a release. The security team keeps in contact with the
+various organizations and individuals and can take care of that.
+</para>
+</listitem>
+</itemizedlist>
+<para>
+In all cases if the person who reports the problem asks that it not be
+disclosed, such requests should be honored, with the obvious exception of
+informing the security team in order that a fix may be produced for a stable
+release of Debian. When sending confidential information to the security team,
+be sure to mention this fact.
+</para>
+<para>
+Please note that if secrecy is needed you may not upload a fix to unstable (or
+anywhere else, such as a public CVS repository). It is not sufficient to
+obfuscate the details of the change, as the code itself is public, and can (and
+will) be examined by the general public.
+</para>
+<para>
+There are two reasons for releasing information even though secrecy is
+requested: the problem has been known for a while, or the problem or exploit
+has become public.
+</para>
+</section>
+
+<section id="bug-security-advisories">
+<title>Security Advisories</title>
+<para>
+Security advisories are only issued for the current, released stable
+distribution, and <emphasis>not</emphasis> for testing or unstable. When
+released, advisories are sent to the
+&email-debian-security-announce; mailing list and posted on
+<ulink url="&url-debian-security-advisories;">the security web
+page</ulink>. Security advisories are written and posted by the security team.
+However they certainly do not mind if a maintainer can supply some of the
+information for them, or write part of the text. Information that should be in
+an advisory includes:
+</para>
+<itemizedlist>
+<listitem>
+<para>
+A description of the problem and its scope, including:
+</para>
+<itemizedlist>
+<listitem>
+<para>
+The type of problem (privilege escalation, denial of service, etc.)
+</para>
+</listitem>
+<listitem>
+<para>
+What privileges may be gained, and by whom (if any)
+</para>
+</listitem>
+<listitem>
+<para>
+How it can be exploited
+</para>
+</listitem>
+<listitem>
+<para>
+Whether it is remotely or locally exploitable
+</para>
+</listitem>
+<listitem>
+<para>
+How the problem was fixed
+</para>
+</listitem>
+</itemizedlist>
+<para>
+This information allows users to assess the threat to their systems.
+</para>
+</listitem>
+<listitem>
+<para>
+Version numbers of affected packages
+</para>
+</listitem>
+<listitem>
+<para>
+Version numbers of fixed packages
+</para>
+</listitem>
+<listitem>
+<para>
+Information on where to obtain the updated packages (usually from the Debian
+security archive)
+</para>
+</listitem>
+<listitem>
+<para>
+References to upstream advisories, <ulink
+url="http://cve.mitre.org">CVE</ulink> identifiers, and any other information
+useful in cross-referencing the vulnerability
+</para>
+</listitem>
+</itemizedlist>
+</section>
+
+<section id="bug-security-building">
+<title>Preparing packages to address security issues</title>
+<para>
+One way that you can assist the security team in their duties is to provide
+them with fixed packages suitable for a security advisory for the stable Debian
+release.
+</para>
+<para>
+When an update is made to the stable release, care must be taken to avoid
+changing system behavior or introducing new bugs. In order to do this, make as
+few changes as possible to fix the bug. Users and administrators rely on the
+exact behavior of a release once it is made, so any change that is made might
+break someone's system. This is especially true of libraries: make sure you
+never change the API or ABI, no matter how small the change.
+</para>
+<para>
+This means that moving to a new upstream version is not a good solution.
+Instead, the relevant changes should be back-ported to the version present in
+the current stable Debian release. Generally, upstream maintainers are willing
+to help if needed. If not, the Debian security team may be able to help.
+</para>
+<para>
+In some cases, it is not possible to back-port a security fix, for example when
+large amounts of source code need to be modified or rewritten. If this
+happens, it may be necessary to move to a new upstream version. However, this
+is only done in extreme situations, and you must always coordinate that with
+the security team beforehand.
+</para>
+<para>
+Related to this is another important guideline: always test your changes. If
+you have an exploit available, try it and see if it indeed succeeds on the
+unpatched package and fails on the fixed package. Test other, normal actions
+as well, as sometimes a security fix can break seemingly unrelated features in
+subtle ways.
+</para>
+<para>
+Do <emphasis role="strong">NOT</emphasis> include any changes in your package
+which are not directly related to fixing the vulnerability. These will only
+need to be reverted, and this wastes time. If there are other bugs in your
+package that you would like to fix, make an upload to proposed-updates in the
+usual way, after the security advisory is issued. The security update
+mechanism is not a means for introducing changes to your package which would
+otherwise be rejected from the stable release, so please do not attempt to do
+this.
+</para>
+<para>
+Review and test your changes as much as possible. Check the differences from
+the previous version repeatedly (<command>interdiff</command> from the
+<systemitem role="package">patchutils</systemitem> package and
+<command>debdiff</command> from <systemitem
+role="package">devscripts</systemitem> are useful tools for this, see <xref
+linkend="debdiff"/> ).
+</para>
+<para>
+Be sure to verify the following items:
+</para>
+<itemizedlist>
+<listitem>
+<para>
+Target the right distribution in your <filename>debian/changelog</filename>.
+For stable this is <literal>stable-security</literal> and for testing this is
+<literal>testing-security</literal>, and for the previous stable release, this
+is <literal>oldstable-security</literal>. Do not target
+<replaceable>distribution</replaceable>-proposed-updates or
+<literal>stable</literal>!
+</para>
+</listitem>
+<listitem>
+<para>
+The upload should have urgency=high.
+</para>
+</listitem>
+<listitem>
+<para>
+Make descriptive, meaningful changelog entries. Others will rely on them to
+determine whether a particular bug was fixed. 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.
+</para>
+</listitem>
+<listitem>
+<para>
+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 <literal>dpkg --compare-versions</literal>. Be careful not to
+re-use a version number that you have already used for a previous upload. For
+<emphasis>testing</emphasis>, there must be a higher version in
+<emphasis>unstable</emphasis>. If there is none yet (for example, if
+<emphasis>testing</emphasis> and <emphasis>unstable</emphasis> have the same
+version) you must upload a new version to unstable first.
+</para>
+</listitem>
+<listitem>
+<para>
+Do not make source-only uploads if your package has any binary-all packages (do
+not use the <literal>-S</literal> option to
+<command>dpkg-buildpackage</command>). The <command>buildd</command>
+infrastructure will not build those. This point applies to normal package
+uploads as well.
+</para>
+</listitem>
+<listitem>
+<para>
+Unless the upstream source has been uploaded to security.debian.org before (by
+a previous security update), build the upload with full upstream source
+(<literal>dpkg-buildpackage -sa</literal>). If there has been a previous
+upload to security.debian.org with the same upstream version, you may upload
+without upstream source (<literal>dpkg-buildpackage -sd</literal>).
+</para>
+</listitem>
+<listitem>
+<para>
+Be sure to use the exact same <filename>*.orig.tar.gz</filename> as used in the
+normal archive, otherwise it is not possible to move the security fix into the
+main archives later.
+</para>
+</listitem>
+<listitem>
+<para>
+Build the package on a clean system which only has packages installed from the
+distribution you are building for. If you do not have such a system yourself,
+you can use a debian.org machine (see <xref linkend="server-machines"/> ) or
+setup a chroot (see <xref linkend="pbuilder"/> and <xref
+linkend="debootstrap"/> ).
+</para>
+</listitem>
+</itemizedlist>
+</section>
+
+<section id="bug-security-upload">
+<title>Uploading the fixed package</title>
+<para>
+Do <emphasis role="strong">NOT</emphasis> 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.
+</para>
+<para>
+Do <emphasis role="strong">NOT</emphasis> 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 is already installed into the archive,
+the security update will be rejected by the archive system. That way, the
+stable distribution will end up without a security update for this package
+instead.
+</para>
+<para>
+Once you have created and tested the new package and it has been approved by
+the security team, it needs to be uploaded so that it can be installed in the
+archives. For security uploads, the place to upload to is
+<literal>ftp://security-master.debian.org/pub/SecurityUploadQueue/</literal> .
+</para>
+<para>
+Once an upload to the security queue has been accepted, the package will
+automatically be rebuilt for all architectures and stored for verification by
+the security team.
+</para>
+<para>
+Uploads which are waiting for acceptance or verification are only accessible by
+the security team. This is necessary since there might be fixes for security
+problems that cannot be disclosed yet.
+</para>
+<para>
+If a member of the security team accepts a package, it will be installed on
+security.debian.org as well as proposed for the proper
+<replaceable>distribution</replaceable>-proposed-updates on ftp-master.
+</para>
+</section>
+
+</section>
+
+</section>
+
+<section id="archive-manip">
+<title>Moving, removing, renaming, adopting, and orphaning packages</title>
+<para>
+Some archive manipulation operations are not automated in the Debian upload
+process. These procedures should be manually followed by maintainers. This
+chapter gives guidelines on what to do in these cases.
+</para>
+<section id="moving-pkgs">
+<title>Moving packages</title>
+<para>
+Sometimes a package will change its section. For instance, a package from the
+`non-free' section might be GPL'd in a later version, in which case the package
+should be moved to `main' or `contrib'.<footnote><para> See the <ulink
+url="&url-debian-policy;">Debian Policy Manual</ulink> for
+guidelines on what section a package belongs in. </para> </footnote>
+</para>
+<para>
+If you need to change the section for one of your packages, change the package
+control information to place the package in the desired section, and re-upload
+the package (see the <ulink
+url="&url-debian-policy;">Debian Policy Manual</ulink> for
+details). You must ensure that you include the
+<filename>.orig.tar.gz</filename> in your upload (even if you are not uploading
+a new upstream version), or it will not appear in the new section together with
+the rest of the package. If your new section is valid, it will be moved
+automatically. If it does not, then contact the ftpmasters in order to
+understand what happened.
+</para>
+<para>
+If, on the other hand, you need to change the <emphasis>subsection</emphasis>
+of one of your packages (e.g., ``devel'', ``admin''), the procedure is slightly
+different. Correct the subsection as found in the control file of the package,
+and re-upload that. Also, you'll need to get the override file updated, as
+described in <xref linkend="override-file"/> .
+</para>
+</section>
+
+<section id="removing-pkgs">
+<title>Removing packages</title>
+<para>
+If for some reason you want to completely remove a package (say, if it is an
+old compatibility library which is no longer required), you need to file a bug
+against <literal>ftp.debian.org</literal> asking that the package be removed;
+as all bugs, this bug should normally have normal severity. Make sure you
+indicate which distribution the package should be removed from. Normally, you
+can only have packages removed from <emphasis>unstable</emphasis> and
+<emphasis>experimental</emphasis>. Packages are not removed from
+<emphasis>testing</emphasis> directly. Rather, they will be removed
+automatically after the package has been removed from
+<emphasis>unstable</emphasis> and no package in <emphasis>testing</emphasis>
+depends on it.
+</para>
+<para>
+There is one exception when an explicit removal request is not necessary: If a
+(source or binary) package is an orphan, it will be removed semi-automatically.
+For a binary-package, this means if there is no longer any source package
+producing this binary package; if the binary package is just no longer produced
+on some architectures, a removal request is still necessary. For a
+source-package, this means that all binary packages it refers to have been
+taken over by another source package.
+</para>
+<para>
+In your removal request, you have to detail the reasons justifying the request.
+This is to avoid unwanted removals and to keep a trace of why a package has
+been removed. For example, you can provide the name of the package that
+supersedes the one to be removed.
+</para>
+<para>
+Usually you only ask for the removal of a package maintained by yourself. If
+you want to remove another package, you have to get the approval of its
+maintainer.
+</para>
+<para>
+Further information relating to these and other package removal related topics
+may be found at <ulink url="http://wiki.debian.org/ftpmaster_Removals"></ulink>
+and <ulink url="&url-debian-qa;howto-remove.html"></ulink>.
+</para>
+<para>
+If in doubt concerning whether a package is disposable, email
+&email-debian-devel; asking for opinions. Also of interest is
+the <command>apt-cache</command> program from the <systemitem
+role="package">apt</systemitem> package. When invoked as <literal>apt-cache
+showpkg <replaceable>package</replaceable></literal>, the program will show
+details for <replaceable>package</replaceable>, including reverse depends.
+Other useful programs include <literal>apt-cache rdepends</literal>,
+<command>apt-rdepends</command> and <command>grep-dctrl</command>. Removal of
+orphaned packages is discussed on &email-debian-qa;.
+</para>
+<para>
+Once the package has been removed, the package's bugs should be handled. They
+should either be reassigned to another package in the case where the actual
+code has evolved into another package (e.g. <literal>libfoo12</literal> was
+removed because <literal>libfoo13</literal> supersedes it) or closed if the
+software is simply no longer part of Debian.
+</para>
+<section id="s5.9.2.1">
+<title>Removing packages from <filename>Incoming</filename></title>
+<para>
+In the past, it was possible to remove packages from
+<filename>incoming</filename>. However, with the introduction of the new
+incoming system, this is no longer possible. Instead, you have to upload a new
+revision of your package with a higher version than the package you want to
+replace. Both versions will be installed in the archive but only the higher
+version will actually be available in <emphasis>unstable</emphasis> since the
+previous version will immediately be replaced by the higher. However, if you
+do proper testing of your packages, the need to replace a package should not
+occur too often anyway.
+</para>
+</section>
+
+</section>
+
+<section id="s5.9.3">
+<title>Replacing or renaming packages</title>
+<para>
+When you make a mistake naming your package, you should follow a two-step
+process to rename it. First, set your <filename>debian/control</filename> file
+to replace and conflict with the obsolete name of the package (see the <ulink
+url="&url-debian-policy;">Debian Policy Manual</ulink> for
+details). Once you've uploaded the package and the package has moved into the
+archive, file a bug against <literal>ftp.debian.org</literal> asking to remove
+the package with the obsolete name. Do not forget to properly reassign the
+package's bugs at the same time.
+</para>
+<para>
+At other times, you may make a mistake in constructing your package and wish to
+replace it. The only way to do this is to increase the version number and
+upload a new version. The old version will be expired in the usual manner.
+Note that this applies to each part of your package, including the sources: if
+you wish to replace the upstream source tarball of your package, you will need
+to upload it with a different version. An easy possibility is to replace
+<filename>foo_1.00.orig.tar.gz</filename> with
+<filename>foo_1.00+0.orig.tar.gz</filename>. This restriction gives each file
+on the ftp site a unique name, which helps to ensure consistency across the
+mirror network.
+</para>
+</section>
+
+<section id="orphaning">
+<title>Orphaning a package</title>
+<para>
+If you can no longer maintain a package, you need to inform others, and see
+that the package is marked as orphaned. You should set the package maintainer
+to <literal>Debian QA Group &orphan-address;</literal> and
+submit a bug report against the pseudo package <systemitem
+role="package">wnpp</systemitem>. The bug report should be titled <literal>O:
+<replaceable>package</replaceable> -- <replaceable>short
+description</replaceable></literal> indicating that the package is now
+orphaned. The severity of the bug should be set to
+<emphasis>normal</emphasis>; if the package has a priority of standard or
+higher, it should be set to important. If you feel it's necessary, send a copy
+to &email-debian-devel; by putting the address in the
+X-Debbugs-CC: header of the message (no, don't use CC:, because that way the
+message's subject won't indicate the bug number).
+</para>
+<para>
+If you just intend to give the package away, but you can keep maintainership
+for the moment, then you should instead submit a bug against <systemitem
+role="package">wnpp</systemitem> and title it <literal>RFA:
+<replaceable>package</replaceable> -- <replaceable>short
+description</replaceable></literal>. <literal>RFA</literal> stands for
+<emphasis>Request For Adoption</emphasis>.
+</para>
+<para>
+More information is on the <ulink url="&url-wnpp;">WNPP
+web pages</ulink>.
+</para>
+</section>
+
+<section id="adopting">
+<title>Adopting a package</title>
+<para>
+A list of packages in need of a new maintainer is available in the <ulink
+url="&url-wnpp;">Work-Needing and Prospective Packages
+list (WNPP)</ulink>. If you wish to take over maintenance of any of the
+packages listed in the WNPP, please take a look at the aforementioned page for
+information and procedures.
+</para>
+<para>
+It is not OK to simply take over a package that you feel is neglected — that
+would be package hijacking. You can, of course, contact the current maintainer
+and ask them if you may take over the package. If you have reason to believe a
+maintainer has gone AWOL (absent without leave), see <xref linkend="mia-qa"/> .
+</para>
+<para>
+Generally, you may not take over the package without the assent of the current
+maintainer. Even if they ignore you, that is still not grounds to take over a
+package. Complaints about maintainers should be brought up on the developers'
+mailing list. If the discussion doesn't end with a positive conclusion, and
+the issue is of a technical nature, consider bringing it to the attention of
+the technical committee (see the <ulink
+url="&url-tech-ctte;">technical committee web page</ulink> for
+more information).
+</para>
+<para>
+If you take over an old package, you probably want to be listed as the
+package's official maintainer in the bug system. This will happen
+automatically once you upload a new version with an updated
+<literal>Maintainer:</literal> field, although it can take a few hours after
+the upload is done. If you do not expect to upload a new version for a while,
+you can use <xref linkend="pkg-tracking-system"/> to get the bug reports.
+However, make sure that the old maintainer has no problem with the fact that
+they will continue to receive the bugs during that time.
+</para>
+</section>
+
+</section>
+
+<section id="porting">
+<title>Porting and being ported</title>
+<para>
+Debian supports an ever-increasing number of architectures. Even if you are
+not a porter, and you don't use any architecture but one, it is part of your
+duty as a maintainer to be aware of issues of portability. Therefore, even if
+you are not a porter, you should read most of this chapter.
+</para>
+<para>
+Porting is the act of building Debian packages for architectures that are
+different from the original architecture of the package maintainer's binary
+package. It is a unique and essential activity. In fact, porters do most of
+the actual compiling of Debian packages. For instance, for a single
+<emphasis>i386</emphasis> binary package, there must be a recompile for each
+architecture, which amounts to &number-of-arches; more builds.
+</para>
+<section id="kind-to-porters">
+<title>Being kind to porters</title>
+<para>
+Porters have a difficult and unique task, since they are required to deal with
+a large volume of packages. Ideally, every source package should build right
+out of the box. Unfortunately, this is often not the case. This section
+contains a checklist of ``gotchas'' often committed by Debian maintainers —
+common problems which often stymie porters, and make their jobs unnecessarily
+difficult.
+</para>
+<para>
+The first and most important thing is to respond quickly to bug or issues
+raised by porters. Please treat porters with courtesy, as if they were in fact
+co-maintainers of your package (which, in a way, they are). Please be tolerant
+of succinct or even unclear bug reports; do your best to hunt down whatever the
+problem is.
+</para>
+<para>
+By far, most of the problems encountered by porters are caused by
+<emphasis>packaging bugs</emphasis> in the source packages. Here is a
+checklist of things you should check or be aware of.
+</para>
+<orderedlist numeration="arabic">
+<listitem>
+<para>
+Make sure that your <literal>Build-Depends</literal> and
+<literal>Build-Depends-Indep</literal> settings in
+<filename>debian/control</filename> are set properly. The best way to validate
+this is to use the <systemitem role="package">debootstrap</systemitem> package
+to create an unstable chroot environment (see <xref linkend="debootstrap"/> ).
+Within that chrooted environment, install the <systemitem
+role="package">build-essential</systemitem> package and any package
+dependencies mentioned in <literal>Build-Depends</literal> and/or
+<literal>Build-Depends-Indep</literal>. Finally, try building your package
+within that chrooted environment. These steps can be automated by the use of
+the <command>pbuilder</command> program which is provided by the package of the
+same name (see <xref linkend="pbuilder"/> ).
+</para>
+<para>
+If you can't set up a proper chroot, <command>dpkg-depcheck</command> may be of
+assistance (see <xref linkend="dpkg-depcheck"/> ).
+</para>
+<para>
+See the <ulink url="&url-debian-policy;">Debian Policy
+Manual</ulink> for instructions on setting build dependencies.
+</para>
+</listitem>
+<listitem>
+<para>
+Don't set architecture to a value other than ``all'' or ``any'' unless you
+really mean it. In too many cases, maintainers don't follow the instructions
+in the <ulink url="&url-debian-policy;">Debian Policy
+Manual</ulink>. Setting your architecture to ``i386'' is usually incorrect.
+</para>
+</listitem>
+<listitem>
+<para>
+Make sure your source package is correct. Do <literal>dpkg-source -x
+<replaceable>package</replaceable>.dsc</literal> to make sure your source
+package unpacks properly. Then, in there, try building your package from
+scratch with <command>dpkg-buildpackage</command>.
+</para>
+</listitem>
+<listitem>
+<para>
+Make sure you don't ship your source package with the
+<filename>debian/files</filename> or <filename>debian/substvars</filename>
+files. They should be removed by the `clean' target of
+<filename>debian/rules</filename>.
+</para>
+</listitem>
+<listitem>
+<para>
+Make sure you don't rely on locally installed or hacked configurations or
+programs. For instance, you should never be calling programs in
+<filename>/usr/local/bin</filename> or the like. Try not to rely on programs
+being setup in a special way. Try building your package on another machine,
+even if it's the same architecture.
+</para>
+</listitem>
+<listitem>
+<para>
+Don't depend on the package you're building being installed already (a sub-case
+of the above issue).
+</para>
+</listitem>
+<listitem>
+<para>
+Don't rely on the compiler being a certain version, if possible. If not, then
+make sure your build dependencies reflect the restrictions, although you are
+probably asking for trouble, since different architectures sometimes
+standardize on different compilers.
+</para>
+</listitem>
+<listitem>
+<para>
+Make sure your debian/rules contains separate ``binary-arch'' and
+``binary-indep'' targets, as the Debian Policy Manual requires. Make sure that
+both targets work independently, that is, that you can call the target without
+having called the other before. To test this, try to run
+<literal>dpkg-buildpackage -B</literal>.
+</para>
+</listitem>
+</orderedlist>
+</section>
+
+<section id="porter-guidelines">
+<title>Guidelines for porter uploads</title>
+<para>
+If the package builds out of the box for the architecture to be ported to, you
+are in luck and your job is easy. This section applies to that case; it
+describes how to build and upload your binary package so that it is properly
+installed into the archive. If you do have to patch the package in order to
+get it to compile for the other architecture, you are actually doing a source
+NMU, so consult <xref linkend="nmu-guidelines"/> instead.
+</para>
+<para>
+For a porter upload, no changes are being made to the source. You do not need
+to touch any of the files in the source package. This includes
+<filename>debian/changelog</filename>.
+</para>
+<para>
+The way to invoke <command>dpkg-buildpackage</command> is as
+<literal>dpkg-buildpackage -B
+-m<replaceable>porter-email</replaceable></literal>. Of course, set
+<replaceable>porter-email</replaceable> to your email address. This will do a
+binary-only build of only the architecture-dependent portions of the package,
+using the `binary-arch' target in <filename>debian/rules</filename>.
+</para>
+<para>
+If you are working on a Debian machine for your porting efforts and you need to
+sign your upload locally for its acceptance in the archive, you can run
+<command>debsign</command> on your <filename>.changes</filename> file to have
+it signed conveniently, or use the remote signing mode of
+<command>dpkg-sig</command>.
+</para>
+<section id="binary-only-nmu">
+<title>Recompilation or binary-only NMU</title>
+<para>
+Sometimes the initial porter upload is problematic because the environment in
+which the package was built was not good enough (outdated or obsolete library,
+bad compiler, ...). Then you may just need to recompile it in an updated
+environment. However, you have to bump the version number in this case, so
+that the old bad package can be replaced in the Debian archive
+(<command>katie</command> refuses to install new packages if they don't have a
+version number greater than the currently available one).
+</para>
+<para>
+You have to make sure that your binary-only NMU doesn't render the package
+uninstallable. This could happen when a source package generates
+arch-dependent and arch-independent packages that depend on each other via
+$(Source-Version).
+</para>
+<para>
+Despite the required modification of the changelog, these are called
+binary-only NMUs — there is no need in this case to trigger all other
+architectures to consider themselves out of date or requiring recompilation.
+</para>
+<para>
+Such recompilations require special ``magic'' version numbering, so that the
+archive maintenance tools recognize that, even though there is a new Debian
+version, there is no corresponding source update. If you get this wrong, the
+archive maintainers will reject your upload (due to lack of corresponding
+source code).
+</para>
+<para>
+The ``magic'' for a recompilation-only NMU is triggered by using a suffix
+appended to the package version number, following the form b<number>.
+For instance, if the latest version you are recompiling against was version
+``2.9-3'', your NMU should carry a version of ``2.9-3+b1''. If the latest
+version was ``3.4+b1'' (i.e, a native package with a previous recompilation
+NMU), your NMU should have a version number of ``3.4+b2''. <footnote><para> In
+the past, such NMUs used the third-level number on the Debian part of the
+revision to denote their recompilation-only status; however, this syntax was
+ambiguous with native packages and did not allow proper ordering of
+recompile-only NMUs, source NMUs, and security NMUs on the same package, and
+has therefore been abandoned in favor of this new syntax. </para> </footnote>
+</para>
+<para>
+Similar to initial porter uploads, the correct way of invoking
+<command>dpkg-buildpackage</command> is <literal>dpkg-buildpackage -B</literal>
+to only build the architecture-dependent parts of the package.
+</para>
+</section>
+
+<section id="source-nmu-when-porter">
+<title>When to do a source NMU if you are a porter</title>
+<para>
+Porters doing a source NMU generally follow the guidelines found in <xref
+linkend="nmu"/> , just like non-porters. However, it is expected that the wait
+cycle for a porter's source NMU is smaller than for a non-porter, since porters
+have to cope with a large quantity of packages. Again, the situation varies
+depending on the distribution they are uploading to. It also varies whether
+the architecture is a candidate for inclusion into the next stable release; the
+release managers decide and announce which architectures are candidates.
+</para>
+<para>
+If you are a porter doing an NMU for `unstable', the above guidelines for
+porting should be followed, with two variations. Firstly, the acceptable
+waiting period — the time between when the bug is submitted to the BTS and
+when it is OK to do an NMU — is seven days for porters working on the
+unstable distribution. This period can be shortened if the problem is critical
+and imposes hardship on the porting effort, at the discretion of the porter
+group. (Remember, none of this is Policy, just mutually agreed upon
+guidelines.) For uploads to stable or testing, please coordinate with the
+appropriate release team first.
+</para>
+<para>
+Secondly, porters doing source NMUs should make sure that the bug they submit
+to the BTS should be of severity `serious' or greater. This ensures that a
+single source package can be used to compile every supported Debian
+architecture by release time. It is very important that we have one version of
+the binary and source package for all architecture in order to comply with many
+licenses.
+</para>
+<para>
+Porters should try to avoid patches which simply kludge around bugs in the
+current version of the compile environment, kernel, or libc. Sometimes such
+kludges can't be helped. If you have to kludge around compiler bugs and the
+like, make sure you <literal>#ifdef</literal> your work properly; also,
+document your kludge so that people know to remove it once the external
+problems have been fixed.
+</para>
+<para>
+Porters may also have an unofficial location where they can put the results of
+their work during the waiting period. This helps others running the port have
+the benefit of the porter's work, even during the waiting period. Of course,
+such locations have no official blessing or status, so buyer beware.
+</para>
+</section>
+
+</section>
+
+<section id="porter-automation">
+<title>Porting infrastructure and automation</title>
+<para>
+There is infrastructure and several tools to help automate package porting.
+This section contains a brief overview of this automation and porting to these
+tools; see the package documentation or references for full information.
+</para>
+<section id="s5.10.3.1">
+<title>Mailing lists and web pages</title>
+<para>
+Web pages containing the status of each port can be found at <ulink
+url="&url-debian-ports;"></ulink>.
+</para>
+<para>
+Each port of Debian has a mailing list. The list of porting mailing lists can
+be found at <ulink url="&url-debian-port-lists;"></ulink>. These
+lists are used to coordinate porters, and to connect the users of a given port
+with the porters.
+</para>
+</section>
+
+<section id="s5.10.3.2">
+<title>Porter tools</title>
+<para>
+Descriptions of several porting tools can be found in <xref
+linkend="tools-porting"/> .
+</para>
+</section>
+
+<section id="buildd">
+<title><systemitem role="package">buildd</systemitem></title>
+<para>
+The <systemitem role="package">buildd</systemitem> system is used as a
+distributed, client-server build distribution system. It is usually used in
+conjunction with <emphasis>auto-builders</emphasis>, which are ``slave'' hosts
+which simply check out and attempt to auto-build packages which need to be
+ported. There is also an email interface to the system, which allows porters
+to ``check out'' a source package (usually one which cannot yet be auto-built)
+and work on it.
+</para>
+<para>
+<systemitem role="package">buildd</systemitem> is not yet available as a
+package; however, most porting efforts are either using it currently or
+planning to use it in the near future. The actual automated builder is
+packaged as <systemitem role="package">sbuild</systemitem>, see its description
+in <xref linkend="sbuild"/> . The complete <systemitem
+role="package">buildd</systemitem> system also collects a number of as yet
+unpackaged components which are currently very useful and in use continually,
+such as <command>andrea</command> and <command>wanna-build</command>.
+</para>
+<para>
+Some of the data produced by <systemitem role="package">buildd</systemitem>
+which is generally useful to porters is available on the web at <ulink
+url="&url-buildd;"></ulink>. This data includes nightly updated
+information from <command>andrea</command> (source dependencies) and
+<systemitem role="package">quinn-diff</systemitem> (packages needing
+recompilation).
+</para>
+<para>
+We are quite proud of this system, since it has so many possible uses.
+Independent development groups can use the system for different sub-flavors of
+Debian, which may or may not really be of general interest (for instance, a
+flavor of Debian built with <command>gcc</command> bounds checking). It will
+also enable Debian to recompile entire distributions quickly.
+</para>
+<para>
+The buildds admins of each arch can be contacted at the mail address
+$arch@buildd.debian.org.
+</para>
+</section>
+
+</section>
+
+<section id="packages-arch-specific">
+<title>When your package is <emphasis>not</emphasis> portable</title>
+<para>
+Some packages still have issues with building and/or working on some of the
+architectures supported by Debian, and cannot be ported at all, or not within a
+reasonable amount of time. An example is a package that is SVGA-specific (only
+i386), or uses other hardware-specific features not supported on all
+architectures.
+</para>
+<para>
+In order to prevent broken packages from being uploaded to the archive, and
+wasting buildd time, you need to do a few things:
+</para>
+<itemizedlist>
+<listitem>
+<para>
+First, make sure your package <emphasis>does</emphasis> fail to build on
+architectures that it cannot support. There are a few ways to achieve this.
+The preferred way is to have a small testsuite during build time that will test
+the functionality, and fail if it doesn't work. This is a good idea anyway, as
+this will prevent (some) broken uploads on all architectures, and also will
+allow the package to build as soon as the required functionality is available.
+</para>
+<para>
+Additionally, if you believe the list of supported architectures is pretty
+constant, you should change 'any' to a list of supported architectures in
+debian/control. This way, the build will fail also, and indicate this to a
+human reader without actually trying.
+</para>
+</listitem>
+<listitem>
+<para>
+In order to prevent autobuilders from needlessly trying to build your package,
+it must be included in <filename>packages-arch-specific</filename>, a list used
+by the <command>wanna-build</command> script. The current version is available
+as <ulink
+url="&url-cvsweb;srcdep/Packages-arch-specific?cvsroot=dak"></ulink>;
+please see the top of the file for whom to contact for changes.
+</para>
+</listitem>
+</itemizedlist>
+<para>
+Please note that it is insufficient to only add your package to
+Packages-arch-specific without making it fail to build on unsupported
+architectures: A porter or any other person trying to build your package might
+accidently upload it without noticing it doesn't work. If in the past some
+binary packages were uploaded on unsupported architectures, request their
+removal by filing a bug against <systemitem
+role="package">ftp.debian.org</systemitem>
+</para>
+</section>
+
+</section>
+
+<section id="nmu">
+<title>Non-Maintainer Uploads (NMUs)</title>
+<para>
+Under certain circumstances it is necessary for someone other than the official
+package maintainer to make a release of a package. This is called a
+non-maintainer upload, or NMU.
+</para>
+<para>
+This section handles only source NMUs, i.e. NMUs which upload a new version of
+the package. For binary-only NMUs by porters or QA members, please see <xref
+linkend="binary-only-nmu"/> . If a buildd builds and uploads a package, that
+too is strictly speaking a binary NMU. See <xref linkend="buildd"/> for some
+more information.
+</para>
+<para>
+The main reason why NMUs are done is when a developer needs to fix another
+developer's package in order to address serious problems or crippling bugs or
+when the package maintainer is unable to release a fix in a timely fashion.
+</para>
+<para>
+First and foremost, it is critical that NMU patches to source should be as
+non-disruptive as possible. Do not do housekeeping tasks, do not change the
+name of modules or files, do not move directories; in general, do not fix
+things which are not broken. Keep the patch as small as possible. If things
+bother you aesthetically, talk to the Debian maintainer, talk to the upstream
+maintainer, or submit a bug. However, aesthetic changes must
+<emphasis>not</emphasis> be made in a non-maintainer upload.
+</para>
+<para>
+And please remember the Hippocratic Oath: Above all, do no harm. It is better
+to leave a package with an open grave bug than applying a non-functional patch,
+or one that hides the bug instead of resolving it.
+</para>
+<section id="nmu-guidelines">
+<title>How to do a NMU</title>
+<para>
+NMUs which fix important, serious or higher severity bugs are encouraged and
+accepted. You should endeavor to reach the current maintainer of the package;
+they might be just about to upload a fix for the problem, or have a better
+solution.
+</para>
+<para>
+NMUs should be made to assist a package's maintainer in resolving bugs.
+Maintainers should be thankful for that help, and NMUers should respect the
+decisions of maintainers, and try to personally help the maintainer by their
+work.
+</para>
+<para>
+A NMU should follow all conventions, written down in this section. For an
+upload to testing or unstable, this order of steps is recommended:
+</para>
+<itemizedlist>
+<listitem>
+<para>
+Make sure that the package's bugs that the NMU is meant to address are all
+filed in the Debian Bug Tracking System (BTS). If they are not, submit them
+immediately.
+</para>
+</listitem>
+<listitem>
+<para>
+Wait a few days for the response from the maintainer. If you don't get any
+response, you may want to help them by sending the patch that fixes the bug.
+Don't forget to tag the bug with the patch keyword.
+</para>
+</listitem>
+<listitem>
+<para>
+Wait a few more days. If you still haven't got an answer from the maintainer,
+send them a mail announcing your intent to NMU the package. Prepare an NMU as
+described in this section, and test it carefully on your machine (cf. <xref
+linkend="sanitycheck"/> ). Double check that your patch doesn't have any
+unexpected side effects. Make sure your patch is as small and as
+non-disruptive as it can be.
+</para>
+</listitem>
+<listitem>
+<para>
+Upload your package to incoming in <filename>DELAYED/7-day</filename> (cf.
+<xref linkend="delayed-incoming"/> ), send the final patch to the maintainer
+via the BTS, and explain to them that they have 7 days to react if they want to
+cancel the NMU.
+</para>
+</listitem>
+<listitem>
+<para>
+Follow what happens, you're responsible for any bug that you introduced with
+your NMU. You should probably use <xref linkend="pkg-tracking-system"/> (PTS)
+to stay informed of the state of the package after your NMU.
+</para>
+</listitem>
+</itemizedlist>
+<para>
+At times, the release manager or an organized group of developers can announce
+a certain period of time in which the NMU rules are relaxed. This usually
+involves shortening the period during which one is to wait before uploading the
+fixes, and shortening the DELAYED period. It is important to notice that even
+in these so-called bug squashing party times, the NMU'er has to file bugs and
+contact the developer first, and act later. Please see <xref
+linkend="qa-bsp"/> for details.
+</para>
+<para>
+For the testing distribution, the rules may be changed by the release managers.
+Please take additional care, and acknowledge that the usual way for a package
+to enter testing is through unstable.
+</para>
+<para>
+For the stable distribution, please take extra care. Of course, the release
+managers may also change the rules here. Please verify before you upload that
+all your changes are OK for inclusion into the next stable release by the
+release manager.
+</para>
+<para>
+When a security bug is detected, the security team may do an NMU, using their
+own rules. Please refer to <xref linkend="bug-security"/> for more
+information.
+</para>
+<para>
+For the differences for Porters NMUs, please see <xref
+linkend="source-nmu-when-porter"/> .
+</para>
+<para>
+Of course, it is always possible to agree on special rules with a maintainer
+(like the maintainer asking please upload this fix directly for me, and no diff
+required).
+</para>
+</section>
+
+<section id="nmu-version">
+<title>NMU version numbering</title>
+<para>
+Whenever you have made a change to a package, no matter how trivial, the
+version number needs to change. This enables our packing system to function.
+</para>
+<para>
+If you are doing a non-maintainer upload (NMU), you should add a new minor
+version number to the <replaceable>debian-revision</replaceable> part of the
+version number (the portion after the last hyphen). This extra minor number
+will start at `1'. For example, consider the package `foo', which is at
+version 1.1-3. In the archive, the source package control file would be
+<filename>foo_1.1-3.dsc</filename>. The upstream version is `1.1' and the
+Debian revision is `3'. The next NMU would add a new minor number `.1' to the
+Debian revision; the new source control file would be
+<filename>foo_1.1-3.1.dsc</filename>.
+</para>
+<para>
+The Debian revision minor number is needed to avoid stealing one of the package
+maintainer's version numbers, which might disrupt their work. It also has the
+benefit of making it visually clear that a package in the archive was not made
+by the official maintainer.
+</para>
+<para>
+If there is no <replaceable>debian-revision</replaceable> component in the
+version number then one should be created, starting at `0.1' (but in case of a
+debian native package still upload it as native package). If it is absolutely
+necessary for someone other than the usual maintainer to make a release based
+on a new upstream version then the person making the release should start with
+the <replaceable>debian-revision</replaceable> value `0.1'. The usual
+maintainer of a package should start their
+<replaceable>debian-revision</replaceable> numbering at `1'.
+</para>
+<para>
+If you upload a package to testing or stable, sometimes, you need to fork the
+version number tree. For this, version numbers like 1.1-3sarge0.1 could be
+used.
+</para>
+</section>
+
+<section id="nmu-changelog">
+<title>Source NMUs must have a new changelog entry</title>
+<para>
+Anyone who is doing a source NMU must create a changelog entry, describing
+which bugs are fixed by the NMU, and generally why the NMU was required and
+what it fixed. The changelog entry will have the email address of the person
+who uploaded it in the log entry and the NMU version number in it.
+</para>
+<para>
+By convention, source NMU changelog entries start with the line
+</para>
+<screen>
+ * Non-maintainer upload
+</screen>
+</section>
+
+<section id="nmu-patch">
+<title>Source NMUs and the Bug Tracking System</title>
+<para>
+Maintainers other than the official package maintainer should make as few
+changes to the package as possible, and they should always send a patch as a
+unified context diff (<literal>diff -u</literal>) detailing their changes to
+the Bug Tracking System.
+</para>
+<para>
+What if you are simply recompiling the package? If you just need to recompile
+it for a single architecture, then you may do a binary-only NMU as described in
+<xref linkend="binary-only-nmu"/> which doesn't require any patch to be sent.
+If you want the package to be recompiled for all architectures, then you do a
+source NMU as usual and you will have to send a patch.
+</para>
+<para>
+Bugs fixed by source NMUs used to be tagged fixed instead of closed, but since
+version tracking is in place, such bugs are now also closed with the NMU
+version.
+</para>
+<para>
+Also, after doing an NMU, you have to send the information to the existing bugs
+that are fixed by your NMU, including the unified diff. Historically, it was
+custom to open a new bug and include a patch showing all the changes you have
+made. The normal maintainer will either apply the patch or employ an alternate
+method of fixing the problem. Sometimes bugs are fixed independently upstream,
+which is another good reason to back out an NMU's patch. If the maintainer
+decides not to apply the NMU's patch but to release a new version, the
+maintainer needs to ensure that the new upstream version really fixes each
+problem that was fixed in the non-maintainer release.
+</para>
+<para>
+In addition, the normal maintainer should <emphasis>always</emphasis> retain
+the entry in the changelog file documenting the non-maintainer upload -- and of
+course, also keep the changes. If you revert some of the changes, please
+reopen the relevant bug reports.
+</para>
+</section>
+
+<section id="nmu-build">
+<title>Building source NMUs</title>
+<para>
+Source NMU packages are built normally. Pick a distribution using the same
+rules as found in <xref linkend="distribution"/> , follow the other
+instructions in <xref linkend="upload"/> .
+</para>
+<para>
+Make sure you do <emphasis>not</emphasis> change the value of the maintainer in
+the <filename>debian/control</filename> file. Your name as given in the NMU
+entry of the <filename>debian/changelog</filename> file will be used for
+signing the changes file.
+</para>
+</section>
+
+<section id="ack-nmu">
+<title>Acknowledging an NMU</title>
+<para>
+If one of your packages has been NMU'ed, you have to incorporate the changes in
+your copy of the sources. This is easy, you just have to apply the patch that
+has been sent to you. Once this is done, you have to close the bugs that have
+been tagged fixed by the NMU. The easiest way is to use the
+<literal>-v</literal> option of <command>dpkg-buildpackage</command>, as this
+allows you to include just all changes since your last maintainer upload.
+Alternatively, you can close them manually by sending the required mails to the
+BTS or by adding the required <literal>closes: #nnnn</literal> in the changelog
+entry of your next upload.
+</para>
+<para>
+In any case, you should not be upset by the NMU. An NMU is not a personal
+attack against the maintainer. It is a proof that someone cares enough about
+the package that they were willing to help you in your work, so you should be
+thankful. You may also want to ask them if they would be interested in helping
+you on a more frequent basis as co-maintainer or backup maintainer (see <xref
+linkend="collaborative-maint"/> ).
+</para>
+</section>
+
+<section id="nmu-vs-qa">
+<title>NMU vs QA uploads</title>
+<para>
+Unless you know the maintainer is still active, it is wise to check the package
+to see if it has been orphaned. The current list of orphaned packages which
+haven't had their maintainer set correctly is available at <ulink
+url="&url-debian-qa-orphaned;"></ulink>. If you perform an NMU on an
+improperly orphaned package, please set the maintainer to <literal>Debian QA Group
+<packages@qa.debian.org></literal>.
+</para>
+</section>
+
+<section id="nmu-who">
+<title>Who can do an NMU</title>
+<para>
+Only official, registered Debian Developers can do binary or source NMUs. A
+Debian Developer is someone who has their key in the Debian key ring.
+Non-developers, however, are encouraged to download the source package and
+start hacking on it to fix problems; however, rather than doing an NMU, they
+should just submit worthwhile patches to the Bug Tracking System. Maintainers
+almost always appreciate quality patches and bug reports.
+</para>
+</section>
+
+<section id="nmu-terms">
+<title>Terminology</title>
+<para>
+There are two new terms used throughout this section: ``binary-only NMU'' and
+``source NMU''. These terms are used with specific technical meaning
+throughout this document. Both binary-only and source NMUs are similar, since
+they involve an upload of a package by a developer who is not the official
+maintainer of that package. That is why it's a
+<emphasis>non-maintainer</emphasis> upload.
+</para>
+<para>
+A source NMU is an upload of a package by a developer who is not the official
+maintainer, for the purposes of fixing a bug in the package. Source NMUs
+always involves changes to the source (even if it is just a change to
+<filename>debian/changelog</filename>). This can be either a change to the
+upstream source, or a change to the Debian bits of the source. Note, however,
+that source NMUs may also include architecture-dependent packages, as well as
+an updated Debian diff.
+</para>
+<para>
+A binary-only NMU is a recompilation and upload of a binary package for a given
+architecture. As such, it is usually part of a porting effort. A binary-only
+NMU is a non-maintainer uploaded binary version of a package, with no source
+changes required. There are many cases where porters must fix problems in the
+source in order to get them to compile for their target architecture; that
+would be considered a source NMU rather than a binary-only NMU. As you can
+see, we don't distinguish in terminology between porter NMUs and non-porter
+NMUs.
+</para>
+<para>
+Both classes of NMUs, source and binary-only, can be lumped under the term
+``NMU''. However, this often leads to confusion, since most people think
+``source NMU'' when they think ``NMU''. So it's best to be careful: always use
+``binary NMU'' or ``binNMU'' for binary-only NMUs.
+</para>
+</section>
+
+</section>
+
+<section id="collaborative-maint">
+<title>Collaborative maintenance</title>
+<para>
+Collaborative maintenance is a term describing the sharing of Debian package
+maintenance duties by several people. This collaboration is almost always a
+good idea, since it generally results in higher quality and faster bug fix
+turnaround times. It is strongly recommended that packages with a priority of
+<literal>Standard</literal> or which are part of the base set have
+co-maintainers.
+</para>
+<para>
+Generally there is a primary maintainer and one or more co-maintainers. The
+primary maintainer is the person whose name is listed in the
+<literal>Maintainer</literal> field of the <filename>debian/control</filename>
+file. Co-maintainers are all the other maintainers.
+</para>
+<para>
+In its most basic form, the process of adding a new co-maintainer is quite
+easy:
+</para>
+<itemizedlist>
+<listitem>
+<para>
+Setup the co-maintainer with access to the sources you build the package from.
+Generally this implies you are using a network-capable version control system,
+such as <command>CVS</command> or <command>Subversion</command>. Alioth (see
+<xref linkend="alioth"/> ) provides such tools, amongst others.
+</para>
+</listitem>
+<listitem>
+<para>
+Add the co-maintainer's correct maintainer name and address to the
+<literal>Uploaders</literal> field in the global part of the
+<filename>debian/control</filename> file.
+</para>
+<screen>
+Uploaders: John Buzz <jbuzz@debian.org>, Adam Rex <arex@debian.org>
+</screen>
+</listitem>
+<listitem>
+<para>
+Using the PTS (<xref linkend="pkg-tracking-system"/> ), the co-maintainers
+should subscribe themselves to the appropriate source package.
+</para>
+</listitem>
+</itemizedlist>
+<para>
+Another form of collaborative maintenance is team maintenance, which is
+recommended if you maintain several packages with the same group of developers.
+In that case, the Maintainer and Uploaders field of each package must be
+managed with care. It is recommended to choose between one of the two
+following schemes:
+</para>
+<orderedlist numeration="arabic">
+<listitem>
+<para>
+Put the team member mainly responsible for the package in the Maintainer field.
+In the Uploaders, put the mailing list address, and the team members who care
+for the package.
+</para>
+</listitem>
+<listitem>
+<para>
+Put the mailing list address in the Maintainer field. In the Uploaders field,
+put the team members who care for the package. In this case, you must make
+sure the mailing list accept bug reports without any human interaction (like
+moderation for non-subscribers).
+</para>
+</listitem>
+</orderedlist>
+<para>
+In any case, it is a bad idea to automatically put all team members in the
+Uploaders field. It clutters the Developer's Package Overview listing (see
+<xref linkend="ddpo"/> ) with packages one doesn't really care for, and creates
+a false sense of good maintenance.
+</para>
+</section>
+
+<section id="testing">
+<title>The testing distribution</title>
+<section id="testing-basics">
+<title>Basics</title>
+<para>
+Packages are usually installed into the `testing' distribution after they have
+undergone some degree of testing in unstable.
+</para>
+<para>
+They must be in sync on all architectures and mustn't have dependencies that
+make them uninstallable; they also have to have generally no known
+release-critical bugs at the time they're installed into testing. This way,
+`testing' should always be close to being a release candidate. Please see
+below for details.
+</para>
+</section>
+
+<section id="testing-unstable">
+<title>Updates from unstable</title>
+<para>
+The scripts that update the <emphasis>testing</emphasis> distribution are run
+each day after the installation of the updated packages; these scripts are
+called <emphasis>britney</emphasis>. They generate the
+<filename>Packages</filename> files for the <emphasis>testing</emphasis>
+distribution, but they do so in an intelligent manner; they try to avoid any
+inconsistency and to use only non-buggy packages.
+</para>
+<para>
+The inclusion of a package from <emphasis>unstable</emphasis> is conditional on
+the following:
+</para>
+<itemizedlist>
+<listitem>
+<para>
+The package must have been available in <emphasis>unstable</emphasis> for 2, 5
+or 10 days, depending on the urgency (high, medium or low). Please note that
+the urgency is sticky, meaning that the highest urgency uploaded since the
+previous testing transition is taken into account. Those delays may be doubled
+during a freeze, or testing transitions may be switched off altogether;
+</para>
+</listitem>
+<listitem>
+<para>
+It must have the same number or fewer release-critical bugs than the version
+currently available in <emphasis>testing</emphasis>;
+</para>
+</listitem>
+<listitem>
+<para>
+It must be available on all architectures on which it has previously been built
+in unstable. <xref linkend="madison"/> may be of interest to check that
+information;
+</para>
+</listitem>
+<listitem>
+<para>
+It must not break any dependency of a package which is already available in
+<emphasis>testing</emphasis>;
+</para>
+</listitem>
+<listitem>
+<para>
+The packages on which it depends must either be available in
+<emphasis>testing</emphasis> or they must be accepted into
+<emphasis>testing</emphasis> at the same time (and they will be if they fulfill
+all the necessary criteria);
+</para>
+</listitem>
+</itemizedlist>
+<para>
+To find out whether a package is progressing into testing or not, see the
+testing script output on the <ulink
+url="&url-testing-maint;">web page of the testing
+distribution</ulink>, or use the program <command>grep-excuses</command> which
+is in the <systemitem role="package">devscripts</systemitem> package. This
+utility can easily be used in a <citerefentry>
+<refentrytitle>crontab</refentrytitle> <manvolnum>5</manvolnum> </citerefentry>
+to keep yourself informed of the progression of your packages into
+<emphasis>testing</emphasis>.
+</para>
+<para>
+The <filename>update_excuses</filename> file does not always give the precise
+reason why the package is refused; you may have to find it on your own by
+looking for what would break with the inclusion of the package. The <ulink
+url="&url-testing-maint;">testing web page</ulink> gives some
+more information about the usual problems which may be causing such troubles.
+</para>
+<para>
+Sometimes, some packages never enter <emphasis>testing</emphasis> because the
+set of inter-relationship is too complicated and cannot be sorted out by the
+scripts. See below for details.
+</para>
+<para>
+Some further dependency analysis is shown on <ulink
+url="http://bjorn.haxx.se/debian/"></ulink> — but be warned, this page also
+shows build dependencies which are not considered by britney.
+</para>
+<section id="outdated">
+<title>out-of-date</title>
+<para>
+<!-- FIXME: better rename this file than document rampant professionalism? -->
+For the testing migration script, outdated means: There are different versions
+in unstable for the release architectures (except for the architectures in
+fuckedarches; fuckedarches is a list of architectures that don't keep up (in
+update_out.py), but currently, it's empty). outdated has nothing whatsoever to
+do with the architectures this package has in testing.
+</para>
+<para>
+Consider this example:
+</para>
+<informaltable pgwide="1">
+<tgroup cols="3">
+<thead>
+<row>
+<entry></entry>
+<entry>alpha</entry>
+<entry>arm</entry>
+</row>
+</thead>
+<tbody>
+<row>
+<entry>testing</entry>
+<entry>1</entry>
+<entry>-</entry>
+</row>
+<row>
+<entry>unstable</entry>
+<entry>1</entry>
+<entry>2</entry>
+</row>
+</tbody>
+</tgroup>
+</informaltable>
+<para>
+The package is out of date on alpha in unstable, and will not go to testing.
+And removing foo from testing would not help at all, the package is still out
+of date on alpha, and will not propagate to testing.
+</para>
+<para>
+However, if ftp-master removes a package in unstable (here on arm):
+</para>
+<informaltable pgwide="1">
+<tgroup cols="4">
+<thead>
+<row>
+<entry></entry>
+<entry>alpha</entry>
+<entry>arm</entry>
+<entry>hurd-i386</entry>
+</row>
+</thead>
+<tbody>
+<row>
+<entry>testing</entry>
+<entry>1</entry>
+<entry>1</entry>
+<entry>-</entry>
+</row>
+<row>
+<entry>unstable</entry>
+<entry>2</entry>
+<entry>-</entry>
+<entry>1</entry>
+</row>
+</tbody>
+</tgroup>
+</informaltable>
+<para>
+In this case, the package is up to date on all release architectures in
+unstable (and the extra hurd-i386 doesn't matter, as it's not a release
+architecture).
+</para>
+<para>
+Sometimes, the question is raised if it is possible to allow packages in that
+are not yet built on all architectures: No. Just plainly no. (Except if you
+maintain glibc or so.)
+</para>
+</section>
+
+<section id="removals">
+<title>Removals from testing</title>
+<para>
+Sometimes, a package is removed to allow another package in: This happens only
+to allow <emphasis>another</emphasis> package to go in if it's ready in every
+other sense. Suppose e.g. that <emphasis>a</emphasis> cannot be installed
+with the new version of <emphasis>b</emphasis>; then <emphasis>a</emphasis> may
+be removed to allow <emphasis>b</emphasis> in.
+</para>
+<para>
+Of course, there is another reason to remove a package from testing: It's just
+too buggy (and having a single RC-bug is enough to be in this state).
+</para>
+<para>
+Furthermore, if a package has been removed from unstable, and no package in
+testing depends on it any more, then it will automatically be removed.
+</para>
+</section>
+
+<section id="circular">
+<title>circular dependencies</title>
+<para>
+A situation which is not handled very well by britney is if package
+<emphasis>a</emphasis> depends on the new version of package
+<emphasis>b</emphasis>, and vice versa.
+</para>
+<para>
+An example of this is:
+</para>
+<informaltable pgwide="1">
+<tgroup cols="3">
+<thead>
+<row>
+<entry></entry>
+<entry>testing</entry>
+<entry>unstable</entry>
+</row>
+</thead>
+<tbody>
+<row>
+<entry>a</entry>
+<entry>1; depends: b=1</entry>
+<entry>2; depends: b=2</entry>
+</row>
+<row>
+<entry>b</entry>
+<entry>1; depends: a=1</entry>
+<entry>2; depends: a=2</entry>
+</row>
+</tbody>
+</tgroup>
+</informaltable>
+<para>
+Neither package <emphasis>a</emphasis> nor package <emphasis>b</emphasis> is
+considered for update.
+</para>
+<para>
+Currently, this requires some manual hinting from the release team. Please
+contact them by sending mail to &email-debian-release; if this
+happens to one of your packages.
+</para>
+</section>
+
+<section id="s5.13.2.4">
+<title>influence of package in testing</title>
+<para>
+Generally, there is nothing that the status of a package in testing means for
+transition of the next version from unstable to testing, with two exceptions:
+If the RC-bugginess of the package goes down, it may go in even if it is still
+RC-buggy. The second exception is if the version of the package in testing is
+out of sync on the different arches: Then any arch might just upgrade to the
+version of the source package; however, this can happen only if the package was
+previously forced through, the arch is in fuckedarches, or there was no binary
+package of that arch present in unstable at all during the testing migration.
+</para>
+<para>
+In summary this means: The only influence that a package being in testing has
+on a new version of the same package is that the new version might go in
+easier.
+</para>
+</section>
+
+<section id="details">
+<title>details</title>
+<para>
+If you are interested in details, this is how britney works:
+</para>
+<para>
+The packages are looked at to determine whether they are valid candidates.
+This gives the update excuses. The most common reasons why a package is not
+considered are too young, RC-bugginess, and out of date on some arches. For
+this part of britney, the release managers have hammers of various sizes to
+force britney to consider a package. (Also, the base freeze is coded in that
+part of britney.) (There is a similar thing for binary-only updates, but this
+is not described here. If you're interested in that, please peruse the code.)
+</para>
+<para>
+Now, the more complex part happens: Britney tries to update testing with the
+valid candidates; first, each package alone, and then larger and even larger
+sets of packages together. Each try is accepted if testing is not more
+uninstallable after the update than before. (Before and after this part, some
+hints are processed; but as only release masters can hint, this is probably not
+so important for you.)
+</para>
+<para>
+If you want to see more details, you can look it up on
+merkel:/org/&ftp-debian-org;/testing/update_out/ (or there in
+~aba/testing/update_out to see a setup with a smaller packages file). Via web,
+it's at <ulink
+url="http://&ftp-master-host;/testing/update_out_code/"></ulink>
+</para>
+<para>
+The hints are available via <ulink
+url="http://&ftp-master-host;/testing/hints/"></ulink>.
+</para>
+</section>
+
+</section>
+
+<section id="t-p-u">
+<title>Direct updates to testing</title>
+<para>
+The testing distribution is fed with packages from unstable according to the
+rules explained above. However, in some cases, it is necessary to upload
+packages built only for testing. For that, you may want to upload to
+<emphasis>testing-proposed-updates</emphasis>.
+</para>
+<para>
+Keep in mind that packages uploaded there are not automatically processed, they
+have to go through the hands of the release manager. So you'd better have a
+good reason to upload there. In order to know what a good reason is in the
+release managers' eyes, you should read the instructions that they regularly
+give on &email-debian-devel-announce;.
+</para>
+<para>
+You should not upload to <emphasis>testing-proposed-updates</emphasis> when you
+can update your packages through <emphasis>unstable</emphasis>. If you can't
+(for example because you have a newer development version in unstable), you may
+use this facility, but it is recommended that you ask for authorization from
+the release manager first. Even if a package is frozen, updates through
+unstable are possible, if the upload via unstable does not pull in any new
+dependencies.
+</para>
+<para>
+Version numbers are usually selected by adding the codename of the testing
+distribution and a running number, like 1.2sarge1 for the first upload through
+testing-proposed-updates of package version 1.2.
+</para>
+<para>
+Please make sure you didn't miss any of these items in your upload:
+</para>
+<itemizedlist>
+<listitem>
+<para>
+Make sure that your package really needs to go through
+<emphasis>testing-proposed-updates</emphasis>, and can't go through unstable;
+</para>
+</listitem>
+<listitem>
+<para>
+Make sure that you included only the minimal amount of changes;
+</para>
+</listitem>
+<listitem>
+<para>
+Make sure that you included an appropriate explanation in the changelog;
+</para>
+</listitem>
+<listitem>
+<para>
+Make sure that you've written <emphasis>testing</emphasis> or
+<emphasis>testing-proposed-updates</emphasis> into your target distribution;
+</para>
+</listitem>
+<listitem>
+<para>
+Make sure that you've built and tested your package in
+<emphasis>testing</emphasis>, not in <emphasis>unstable</emphasis>;
+</para>
+</listitem>
+<listitem>
+<para>
+Make sure that your version number is higher than the version in
+<emphasis>testing</emphasis> and <emphasis>testing-proposed-updates</emphasis>,
+and lower than in <emphasis>unstable</emphasis>;
+</para>
+</listitem>
+<listitem>
+<para>
+After uploading and successful build on all platforms, contact the release team
+at &email-debian-release; and ask them to approve your upload.
+</para>
+</listitem>
+</itemizedlist>
+</section>
+
+<section id="faq">
+<title>Frequently asked questions</title>
+<section id="rc">
+<title>What are release-critical bugs, and how do they get counted?</title>
+<para>
+All bugs of some higher severities are by default considered release-critical;
+currently, these are critical, grave, and serious bugs.
+</para>
+<para>
+Such bugs are presumed to have an impact on the chances that the package will
+be released with the stable release of Debian: in general, if a package has
+open release-critical bugs filed on it, it won't get into testing, and
+consequently won't be released in stable.
+</para>
+<para>
+The unstable bug count are all release-critical bugs without either any
+release-tag (such as potato, woody) or with release-tag sid; also, only if they
+are neither fixed nor set to sarge-ignore. The testing bug count for a package
+is considered to be roughly the bug count of unstable count at the last point
+when the testing version equalled the unstable version.
+</para>
+<para>
+This will change post-sarge, as soon as we have versions in the bug tracking
+system.
+</para>
+</section>
+
+<section id="s5.13.4.2">
+<title>How could installing a package into testing possibly break other packages?</title>
+<para>
+The structure of the distribution archives is such that they can only contain
+one version of a package; a package is defined by its name. So when the source
+package acmefoo is installed into testing, along with its binary packages
+acme-foo-bin, acme-bar-bin, libacme-foo1 and libacme-foo-dev, the old version
+is removed.
+</para>
+<para>
+However, the old version may have provided a binary package with an old soname
+of a library, such as libacme-foo0. Removing the old acmefoo will remove
+libacme-foo0, which will break any packages which depend on it.
+</para>
+<para>
+Evidently, this mainly affects packages which provide changing sets of binary
+packages in different versions (in turn, mainly libraries). However, it will
+also affect packages upon which versioned dependencies have been declared of
+the ==, <=, or << varieties.
+</para>
+<para>
+When the set of binary packages provided by a source package change in this
+way, all the packages that depended on the old binaries will have to be updated
+to depend on the new binaries instead. Because installing such a source
+package into testing breaks all the packages that depended on it in testing,
+some care has to be taken now: all the depending packages must be updated and
+ready to be installed themselves so that they won't be broken, and, once
+everything is ready, manual intervention by the release manager or an assistant
+is normally required.
+</para>
+<para>
+If you are having problems with complicated groups of packages like this,
+contact debian-devel or debian-release for help.
+</para>
+</section>
+
+</section>
+
+</section>
+
+</chapter>
+
--- /dev/null
+# SOME DESCRIPTIVE TITLE
+# Copyright (C) 2007 Free Software Foundation, Inc.
+# <>, 2007.
+# , fuzzy
+#
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: PACKAGE VERSION\n"
+"Report-Msgid-Bugs-To: \n"
+"POT-Creation-Date: 2007-07-01 21:16+0000\n"
+"PO-Revision-Date: 2007-07-01 23:09+0000\n"
+"Last-Translator: <>\n"
+"Language-Team: \n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: "
+
+# type: Content of: <chapter><title>
+#: best-pkging-practices.dbk:7
+msgid "Best Packaging Practices"
+msgstr "Les meilleurs pratiques pour la construction des paquets"
+
+# type: Content of: <chapter><para>
+#: best-pkging-practices.dbk:9
+msgid ""
+"Debian's quality is largely due to the <ulink url=\"&url-debian-policy;"
+"\">Debian Policy</ulink>, which defines explicit baseline requirements which "
+"all Debian packages must fulfill. Yet there is also a shared history of "
+"experience which goes beyond the Debian Policy, an accumulation of years of "
+"experience in packaging. Many very talented people have created great "
+"tools, tools which help you, the Debian maintainer, create and maintain "
+"excellent packages."
+msgstr ""
+
+# type: Content of: <chapter><para>
+#: best-pkging-practices.dbk:18
+msgid ""
+"This chapter provides some best practices for Debian developers. All "
+"recommendations are merely that, and are not requirements or policy. These "
+"are just some subjective hints, advice and pointers collected from Debian "
+"developers. Feel free to pick and choose whatever works best for you."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: best-pkging-practices.dbk:24
+msgid "Best practices for <filename>debian/rules</filename>"
+msgstr "Les meilleures pratiques pour le fichier <filename>debian/rules</filename>"
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:26
+msgid ""
+"The following recommendations apply to the <filename>debian/rules</filename> "
+"file. Since <filename>debian/rules</filename> controls the build process "
+"and selects the files which go into the package (directly or indirectly), "
+"it's usually the file maintainers spend the most time on."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:32
+msgid "Helper scripts"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:34
+msgid ""
+"The rationale for using helper scripts in <filename>debian/rules</filename> "
+"is that they let maintainers use and share common logic among many "
+"packages. Take for instance the question of installing menu entries: you "
+"need to put the file into <filename>/usr/lib/menu</filename> (or <filename>/"
+"usr/lib/menu</filename> for executable binary menufiles, if this is needed), "
+"and add commands to the maintainer scripts to register and unregister the "
+"menu entries. Since this is a very common thing for packages to do, why "
+"should each maintainer rewrite all this on their own, sometimes with bugs? "
+"Also, supposing the menu directory changed, every package would have to be "
+"changed."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:45
+msgid ""
+"Helper scripts take care of these issues. Assuming you comply with the "
+"conventions expected by the helper script, the helper takes care of all the "
+"details. Changes in policy can be made in the helper script; then packages "
+"just need to be rebuilt with the new version of the helper and no other "
+"changes."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:52
+msgid ""
+"<xref linkend=\"tools\"/> contains a couple of different helpers. The most "
+"common and best (in our opinion) helper system is <systemitem role=\"package"
+"\">debhelper</systemitem>. Previous helper systems, such as <systemitem "
+"role=\"package\">debmake</systemitem>, were monolithic: you couldn't pick "
+"and choose which part of the helper you found useful, but had to use the "
+"helper to do everything. <systemitem role=\"package\">debhelper</"
+"systemitem>, however, is a number of separate little <command>dh_*</command> "
+"programs. For instance, <command>dh_installman</command> installs and "
+"compresses man pages, <command>dh_installmenu</command> installs menu files, "
+"and so on. Thus, it offers enough flexibility to be able to use the little "
+"helper scripts, where useful, in conjunction with hand-crafted commands in "
+"<filename>debian/rules</filename>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:66
+msgid ""
+"You can get started with <systemitem role=\"package\">debhelper</systemitem> "
+"by reading <citerefentry> <refentrytitle>debhelper</refentrytitle> "
+"<manvolnum>1</manvolnum> </citerefentry>, and looking at the examples that "
+"come with the package. <command>dh_make</command>, from the <systemitem "
+"role=\"package\">dh-make</systemitem> package (see <xref linkend=\"dh-make\"/"
+"> ), can be used to convert a vanilla source package to a <systemitem role="
+"\"package\">debhelper</systemitem>ized package. This shortcut, though, "
+"should not convince you that you do not need to bother understanding the "
+"individual <command>dh_*</command> helpers. If you are going to use a "
+"helper, you do need to take the time to learn to use that helper, to learn "
+"its expectations and behavior."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:79
+msgid ""
+"Some people feel that vanilla <filename>debian/rules</filename> files are "
+"better, since you don't have to learn the intricacies of any helper system. "
+"This decision is completely up to you. Use what works for you. Many "
+"examples of vanilla <filename>debian/rules</filename> files are available at "
+"<ulink url=\"&url-rules-files;\"></ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:88
+msgid "Separating your patches into multiple files"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:90
+msgid ""
+"Big, complex packages may have many bugs that you need to deal with. If you "
+"correct a number of bugs directly in the source, and you're not careful, it "
+"can get hard to differentiate the various patches that you applied. It can "
+"get quite messy when you have to update the package to a new upstream "
+"version which integrates some of the fixes (but not all). You can't take "
+"the total set of diffs (e.g., from <filename>.diff.gz</filename>) and work "
+"out which patch sets to back out as a unit as bugs are fixed upstream."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:99
+msgid ""
+"Unfortunately, the packaging system as such currently doesn't provide for "
+"separating the patches into several files. Nevertheless, there are ways to "
+"separate patches: the patch files are shipped within the Debian patch file "
+"(<filename>.diff.gz</filename>), usually within the <filename>debian/</"
+"filename> directory. The only difference is that they aren't applied "
+"immediately by dpkg-source, but by the <literal>build</literal> rule of "
+"<filename>debian/rules</filename>. Conversely, they are reverted in the "
+"<literal>clean</literal> rule."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:109
+msgid ""
+"<command>dbs</command> is one of the more popular approaches to this. It "
+"does all of the above, and provides a facility for creating new and updating "
+"old patches. See the package <systemitem role=\"package\">dbs</systemitem> "
+"for more information and <systemitem role=\"package\">hello-dbs</systemitem> "
+"for an example."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:116
+msgid ""
+"<command>dpatch</command> also provides these facilities, but it's intended "
+"to be even easier to use. See the package <systemitem role=\"package"
+"\">dpatch</systemitem> for documentation and examples (in <filename>/usr/"
+"share/doc/dpatch</filename>)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:124
+msgid "Multiple binary packages"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:126
+msgid ""
+"A single source package will often build several binary packages, either to "
+"provide several flavors of the same software (e.g., the <systemitem role="
+"\"package\">vim</systemitem> source package) or to make several small "
+"packages instead of a big one (e.g., so the user can install only the subset "
+"needed, and thus save some disk space)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:133
+msgid ""
+"The second case can be easily managed in <filename>debian/rules</filename>. "
+"You just need to move the appropriate files from the build directory into "
+"the package's temporary trees. You can do this using <command>install</"
+"command> or <command>dh_install</command> from <systemitem role=\"package"
+"\">debhelper</systemitem>. Be sure to check the different permutations of "
+"the various packages, ensuring that you have the inter-package dependencies "
+"set right in <filename>debian/control</filename>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:142
+msgid ""
+"The first case is a bit more difficult since it involves multiple recompiles "
+"of the same software but with different configuration options. The "
+"<systemitem role=\"package\">vim</systemitem> source package is an example "
+"of how to manage this using an hand-crafted <filename>debian/rules</"
+"filename> file."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: best-pkging-practices.dbk:154
+msgid "Best practices for <filename>debian/control</filename>"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:156
+msgid ""
+"The following practices are relevant to the <filename>debian/control</"
+"filename> file. They supplement the <ulink url=\"&url-debian-policy;ch-"
+"binary.html#s-descriptions\">Policy on package descriptions</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:162
+msgid ""
+"The description of the package, as defined by the corresponding field in the "
+"<filename>control</filename> file, contains both the package synopsis and "
+"the long description for the package. <xref linkend=\"bpp-desc-basics\"/> "
+"describes common guidelines for both parts of the package description. "
+"Following that, <xref linkend=\"bpp-pkg-synopsis\"/> provides guidelines "
+"specific to the synopsis, and <xref linkend=\"bpp-pkg-desc\"/> contains "
+"guidelines specific to the description."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:171
+msgid "General guidelines for package descriptions"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:173
+msgid ""
+"The package description should be written for the average likely user, the "
+"average person who will use and benefit from the package. For instance, "
+"development packages are for developers, and can be technical in their "
+"language. More general-purpose applications, such as editors, should be "
+"written for a less technical user."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:180
+msgid ""
+"Our review of package descriptions lead us to conclude that most package "
+"descriptions are technical, that is, are not written to make sense for non-"
+"technical users. Unless your package really is only for technical users, "
+"this is a problem."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:186
+msgid ""
+"How do you write for non-technical users? Avoid jargon. Avoid referring to "
+"other applications or frameworks that the user might not be familiar with — "
+"GNOME or KDE is fine, since users are probably familiar with these terms, "
+"but GTK+ is probably not. Try not to assume any knowledge at all. If you "
+"must use technical terms, introduce them."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:193
+msgid ""
+"Be objective. Package descriptions are not the place for advocating your "
+"package, no matter how much you love it. Remember that the reader may not "
+"care about the same things you care about."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:198
+msgid ""
+"References to the names of any other software packages, protocol names, "
+"standards, or specifications should use their canonical forms, if one "
+"exists. For example, use X Window System, X11, or X; not X Windows, X-"
+"Windows, or X Window. Use GTK+, not GTK or gtk. Use GNOME, not Gnome. Use "
+"PostScript, not Postscript or postscript."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:205
+msgid ""
+"If you are having problems writing your description, you may wish to send it "
+"along to &email-debian-l10n-english; and request feedback."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:211
+msgid "The package synopsis, or short description"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:213
+msgid ""
+"The synopsis line (the short description) should be concise. It must not "
+"repeat the package's name (this is policy)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:217
+msgid ""
+"It's a good idea to think of the synopsis as an appositive clause, not a "
+"full sentence. An appositive clause is defined in WordNet as a grammatical "
+"relation between a word and a noun phrase that follows, e.g., Rudolph the "
+"red-nosed reindeer. The appositive clause here is red-nosed reindeer. "
+"Since the synopsis is a clause, rather than a full sentence, we recommend "
+"that it neither start with a capital nor end with a full stop (period). It "
+"should also not begin with an article, either definite (the) or indefinite "
+"(a or an)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:226
+msgid ""
+"It might help to imagine that the synopsis is combined with the package name "
+"in the following way:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: best-pkging-practices.dbk:230
+#, no-wrap
+msgid "<replaceable>package-name</replaceable> is a <replaceable>synopsis</replaceable>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:233
+msgid "Alternatively, it might make sense to think of it as"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: best-pkging-practices.dbk:236
+#, no-wrap
+msgid "<replaceable>package-name</replaceable> is <replaceable>synopsis</replaceable>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:239
+msgid "or, if the package name itself is a plural (such as developers-tools)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: best-pkging-practices.dbk:242
+#, no-wrap
+msgid "<replaceable>package-name</replaceable> are <replaceable>synopsis</replaceable>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:245
+msgid ""
+"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 sentence."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:252
+msgid "The long description"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:254
+msgid ""
+"The long description is the primary information available to the user about "
+"a package before they install it. It should provide all the information "
+"needed to let the user decide whether to install the package. Assume that "
+"the user has already read the package synopsis."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:260
+msgid "The long description should consist of full and complete sentences."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:263
+msgid ""
+"The first paragraph of the long description should answer the following "
+"questions: what does the package do? what task does it help the user "
+"accomplish? It is important to describe this in a non-technical way, unless "
+"of course the audience for the package is necessarily technical."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:269
+msgid ""
+"The following paragraphs should answer the following questions: Why do I as "
+"a user need this package? What other features does the package have? What "
+"outstanding features and deficiencies are there compared to other packages "
+"(e.g., if you need X, use Y instead)? Is this package related to other "
+"packages in some way that is not handled by the package manager (e.g., this "
+"is the client for the foo server)?"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:277
+msgid ""
+"Be careful to avoid spelling and grammar mistakes. Ensure that you spell-"
+"check it. Both <command>ispell</command> and <command>aspell</command> have "
+"special modes for checking <filename>debian/control</filename> files:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: best-pkging-practices.dbk:282
+#, no-wrap
+msgid "ispell -d american -g debian/control"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: best-pkging-practices.dbk:285
+#, no-wrap
+msgid "aspell -d en -D -c debian/control"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:288
+msgid ""
+"Users usually expect these questions to be answered in the package "
+"description:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:293
+msgid ""
+"What does the package do? If it is an add-on to another package, then the "
+"short description of the package we are an add-on to should be put in here."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:299
+msgid ""
+"Why should I want this package? This is related to the above, but not the "
+"same (this is a mail user agent; this is cool, fast, interfaces with PGP and "
+"LDAP and IMAP, has features X, Y, and Z)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:306
+msgid ""
+"If this package should not be installed directly, but is pulled in by "
+"another package, this should be mentioned."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:312
+msgid ""
+"If the package is experimental, or there are other reasons it should not be "
+"used, if there are other packages that should be used instead, it should be "
+"here as well."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:319
+msgid ""
+"How is this package different from the competition? Is it a better "
+"implementation? more features? different features? Why should I choose this "
+"package."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:332
+msgid "Upstream home page"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:334
+msgid ""
+"We recommend that you add the URL for the package's home page to the package "
+"description in <filename>debian/control</filename>. This information should "
+"be added at the end of description, using the following format:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: best-pkging-practices.dbk:339
+#, no-wrap
+msgid ""
+".\n"
+" Homepage: http://some-project.some-place.org/"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:343
+msgid ""
+"Note the spaces prepending the line, which serves to break the lines "
+"correctly. To see an example of how this displays, see <ulink url=\"&url-eg-"
+"desc-upstream-info;\"></ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:348
+msgid ""
+"If there is no home page for the software, this should naturally be left out."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:351
+msgid ""
+"Note that we expect this field will eventually be replaced by a proper "
+"<filename>debian/control</filename> field understood by <command>dpkg</"
+"command> and <literal>&packages-host;</literal>. If you don't want to "
+"bother migrating the home page from the description to this field, you "
+"should probably wait until that is available. Please make sure that this "
+"line matches the regular expression <literal>/^ Homepage: [^ ]*$/</literal>, "
+"as this allows <filename>&packages-host;</filename> to parse it correctly."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:362
+msgid "Version Control System location"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:364
+msgid ""
+"There are additional fields for the location of the Version Control System "
+"in <filename>debian/control</filename>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:368
+msgid "XS-Vcs-Browser"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:370
+msgid ""
+"Value of this field should be a <literal>http://</literal> URL pointing to a "
+"web-browsable copy of the Version Control System repository used to maintain "
+"the given package, if available."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:375
+msgid ""
+"The information is meant to be useful for the final user, willing to browse "
+"the latest work done on the package (e.g. when looking for the patch fixing "
+"a bug tagged as <literal>pending</literal> in the bug tracking system)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:382
+msgid "XS-Vcs-*"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:384
+msgid ""
+"Value of this field should be a string identifying unequivocally the "
+"location of the Version Control System repository used to maintain the given "
+"package, if available. <literal>*</literal> identify the Version Control "
+"System; currently the following systems are supported by the package "
+"tracking system: <literal>arch</literal>, <literal>bzr</literal> (Bazaar), "
+"<literal>cvs</literal>, <literal>darcs</literal>, <literal>git</literal>, "
+"<literal>hg</literal> (Mercurial), <literal>mtn</literal> (Monotone), "
+"<literal>svn</literal> (Subversion). It is allowed to specify different VCS "
+"fields for the same package: they will all be shown in the PTS web interface."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:395
+msgid ""
+"The information is meant to be useful for a user knowledgeable in the given "
+"Version Control System and willing to build the current version of a package "
+"from the VCS sources. Other uses of this information might include "
+"automatic building of the latest VCS version of the given package. To this "
+"end the location pointed to by the field should better be version agnostic "
+"and point to the main branch (for VCSs supporting such a concept). Also, "
+"the location pointed to should be accessible to the final user; fulfilling "
+"this requirement might imply pointing to an anonymous access of the "
+"repository instead of pointing to an SSH-accessible version of the same."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:406
+msgid ""
+"In the following example, an instance of the field for a Subversion "
+"repository of the <systemitem role=\"package\">vim</systemitem> package is "
+"shown. Note how the URL is in the <literal>svn://</literal> scheme (instead "
+"of <literal>svn+ssh://</literal>) and how it points to the <filename>trunk/</"
+"filename> branch. The use of the <literal>XS-Vcs-Browser</literal> field "
+"described above is also shown."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><screen>
+#: best-pkging-practices.dbk:414
+#, no-wrap
+msgid ""
+"Source: vim\n"
+" Section: editors\n"
+" Priority: optional\n"
+" <snip>\n"
+" XS-Vcs-Svn: svn://svn.debian.org/svn/pkg-vim/trunk/packages/vim\n"
+" XS-Vcs-Browser: http://svn.debian.org/wsvn/pkg-vim/trunk/packages/vim"
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: best-pkging-practices.dbk:428
+msgid "Best practices for <filename>debian/changelog</filename>"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:430
+msgid ""
+"The following practices supplement the <ulink url=\"&url-debian-policy;ch-"
+"docs.html#s-changelogs\">Policy on changelog files</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:435
+msgid "Writing useful changelog entries"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:437
+msgid ""
+"The changelog entry for a package revision documents changes in that "
+"revision, and only them. Concentrate on describing significant and user-"
+"visible changes that were made since the last version."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:442
+msgid ""
+"Focus on <emphasis>what</emphasis> was changed — who, how and when are "
+"usually less important. Having said that, remember to politely attribute "
+"people who have provided notable help in making the package (e.g., those who "
+"have sent in patches)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:448
+msgid ""
+"There's no need to elaborate the trivial and obvious changes. You can also "
+"aggregate several changes in one entry. On the other hand, don't be overly "
+"terse if you have undertaken a major change. Be especially clear if there "
+"are changes that affect the behaviour of the program. For further "
+"explanations, use the <filename>README.Debian</filename> file."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:455
+msgid ""
+"Use common English so that the majority of readers can comprehend it. Avoid "
+"abbreviations, tech-speak and jargon when explaining changes that close "
+"bugs, especially for bugs filed by users that did not strike you as "
+"particularly technically savvy. Be polite, don't swear."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:461
+msgid ""
+"It is sometimes desirable to prefix changelog entries with the names of the "
+"files that were changed. However, there's no need to explicitly list each "
+"and every last one of the changed files, especially if the change was small "
+"or repetitive. You may use wildcards."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:467
+msgid ""
+"When referring to bugs, don't assume anything. Say what the problem was, "
+"how it was fixed, and append the closes: #nnnnn string. See <xref linkend="
+"\"upload-bugfix\"/> for more information."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:474
+msgid "Common misconceptions about changelog entries"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:476
+msgid ""
+"The changelog entries should <emphasis role=\"strong\">not</emphasis> "
+"document generic packaging issues (Hey, if you're looking for foo.conf, it's "
+"in /etc/blah/.), since administrators and users are supposed to be at least "
+"remotely acquainted with how such things are generally arranged on Debian "
+"systems. Do, however, mention if you change the location of a configuration "
+"file."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:484
+msgid ""
+"The only bugs closed with a changelog entry should be those that are "
+"actually fixed in the same package revision. Closing unrelated bugs in the "
+"changelog is bad practice. See <xref linkend=\"upload-bugfix\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:489
+msgid ""
+"The changelog entries should <emphasis role=\"strong\">not</emphasis> be "
+"used for random discussion with bug reporters (I don't see segfaults when "
+"starting foo with option bar; send in more info), general statements on "
+"life, the universe and everything (sorry this upload took me so long, but I "
+"caught the flu), or pleas for help (the bug list on this package is huge, "
+"please lend me a hand). Such things usually won't be noticed by their "
+"target audience, but may annoy people who wish to read information about "
+"actual changes in the package. See <xref linkend=\"bug-answering\"/> for "
+"more information on how to use the bug tracking system."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:500
+msgid ""
+"It is an old tradition to acknowledge bugs fixed in non-maintainer uploads "
+"in the first changelog entry of the proper maintainer upload. As we have "
+"version tracking now, it is enough to keep the NMUed changelog entries and "
+"just mention this fact in your own changelog entry."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:508
+msgid "Common errors in changelog entries"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:510
+msgid ""
+"The following examples demonstrate some common errors or examples of bad "
+"style in changelog entries."
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: best-pkging-practices.dbk:514
+#, no-wrap
+msgid "* Fixed all outstanding bugs."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:517
+msgid "This doesn't tell readers anything too useful, obviously."
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: best-pkging-practices.dbk:520
+#, no-wrap
+msgid "* Applied patch from Jane Random."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:523
+msgid "What was the patch about?"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: best-pkging-practices.dbk:526
+#, no-wrap
+msgid "* Late night install target overhaul."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:529
+msgid ""
+"Overhaul which accomplished what? Is the mention of late night supposed to "
+"remind us that we shouldn't trust that code?"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: best-pkging-practices.dbk:533
+#, no-wrap
+msgid "* Fix vsync FU w/ ancient CRTs."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:536
+msgid ""
+"Too many acronyms, and it's not overly clear what the, uh, fsckup (oops, a "
+"curse word!) was actually about, or how it was fixed."
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: best-pkging-practices.dbk:540
+#, no-wrap
+msgid "* This is not a bug, closes: #nnnnnn."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:543
+msgid ""
+"First of all, there's absolutely no need to upload the package to convey "
+"this information; instead, use the bug tracking system. Secondly, there's "
+"no explanation as to why the report is not a bug."
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: best-pkging-practices.dbk:548
+#, no-wrap
+msgid "* Has been fixed for ages, but I forgot to close; closes: #54321."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:551
+msgid ""
+"If for some reason you didn't mention the bug number in a previous changelog "
+"entry, there's no problem, just close the bug normally in the BTS. There's "
+"no need to touch the changelog file, presuming the description of the fix is "
+"already in (this applies to the fixes by the upstream authors/maintainers as "
+"well, you don't have to track bugs that they fixed ages ago in your "
+"changelog)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: best-pkging-practices.dbk:558
+#, no-wrap
+msgid "* Closes: #12345, #12346, #15432"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:561
+msgid ""
+"Where's the description? If you can't think of a descriptive message, start "
+"by inserting the title of each different bug."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:567
+msgid "Supplementing changelogs with NEWS.Debian files"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:569
+msgid ""
+"Important news about changes in a package can also be put in NEWS.Debian "
+"files. The news will be displayed by tools like apt-listchanges, before all "
+"the rest of the changelogs. This is the preferred means to let the user "
+"know about significant changes in a package. It is better than using "
+"debconf notes since it is less annoying and the user can go back and refer "
+"to the NEWS.Debian file after the install. And it's better than listing "
+"major changes in README.Debian, since the user can easily miss such notes."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:578
+msgid ""
+"The file format is the same as a debian changelog file, but leave off the "
+"asterisks and describe each news item with a full paragraph when necessary "
+"rather than the more concise summaries that would go in a changelog. It's a "
+"good idea to run your file through dpkg-parsechangelog to check its "
+"formatting as it will not be automatically checked during build as the "
+"changelog is. Here is an example of a real NEWS.Debian file:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: best-pkging-practices.dbk:586
+#, no-wrap
+msgid ""
+"cron (3.0pl1-74) unstable; urgency=low\n"
+"\n"
+" The checksecurity script is no longer included with the cron package:\n"
+" it now has its own package, checksecurity. If you liked the\n"
+" functionality provided with that script, please install the new\n"
+" package.\n"
+"\n"
+" -- Steve Greenland <stevegr@debian.org> Sat, 6 Sep 2003 17:15:03 -0500"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:596
+msgid ""
+"The NEWS.Debian file is installed as /usr/share/doc/<package>/NEWS."
+"Debian.gz. It is compressed, and always has that name even in Debian native "
+"packages. If you use debhelper, dh_installchangelogs will install debian/"
+"NEWS files for you."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:602
+msgid ""
+"Unlike changelog files, you need not update NEWS.Debian files with every "
+"release. Only update them if you have something particularly newsworthy "
+"that user should know about. If you have no news at all, there's no need to "
+"ship a NEWS.Debian file in your package. No news is good news!"
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: best-pkging-practices.dbk:623
+msgid "Best practices for maintainer scripts"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:625
+msgid ""
+"Maintainer scripts include the files <filename>debian/postinst</filename>, "
+"<filename>debian/preinst</filename>, <filename>debian/prerm</filename> and "
+"<filename>debian/postrm</filename>. These scripts take care of any package "
+"installation or deinstallation setup which isn't handled merely by the "
+"creation or removal of files and directories. The following instructions "
+"supplement the <ulink url=\"&url-debian-policy;\">Debian Policy</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:633
+msgid ""
+"Maintainer scripts must be idempotent. That means that you need to make "
+"sure nothing bad will happen if the script is called twice where it would "
+"usually be called once."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:638
+msgid ""
+"Standard input and output may be redirected (e.g. into pipes) for logging "
+"purposes, so don't rely on them being a tty."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:642
+msgid ""
+"All prompting or interactive configuration should be kept to a minimum. "
+"When it is necessary, you should use the <systemitem role=\"package"
+"\">debconf</systemitem> package for the interface. Remember that prompting "
+"in any case can only be in the <literal>configure</literal> stage of the "
+"<filename>postinst</filename> script."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:649
+msgid ""
+"Keep the maintainer scripts as simple as possible. We suggest you use pure "
+"POSIX shell scripts. Remember, if you do need any bash features, the "
+"maintainer script must have a bash shebang line. POSIX shell or Bash are "
+"preferred to Perl, since they enable <systemitem role=\"package\">debhelper</"
+"systemitem> to easily add bits to the scripts."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:656
+msgid ""
+"If you change your maintainer scripts, be sure to test package removal, "
+"double installation, and purging. Be sure that a purged package is "
+"completely gone, that is, it must remove any files created, directly or "
+"indirectly, in any maintainer script."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:662
+msgid ""
+"If you need to check for the existence of a command, you should use "
+"something like"
+msgstr ""
+
+# type: Content of: <chapter><section><programlisting>
+#: best-pkging-practices.dbk:665
+#, no-wrap
+msgid "if [ -x /usr/sbin/install-docs ]; then ..."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:667
+msgid ""
+"If you don't wish to hard-code the path of a command in your maintainer "
+"script, the following POSIX-compliant shell function may help:"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:672
+msgid ""
+"You can use this function to search <literal>$PATH</literal> for a command "
+"name, passed as an argument. It returns true (zero) if the command was "
+"found, and false if not. This is really the most portable way, since "
+"<literal>command -v</literal>, <command>type</command>, and <command>which</"
+"command> are not POSIX."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:679
+msgid ""
+"While <command>which</command> is an acceptable alternative, since it is "
+"from the required <systemitem role=\"package\">debianutils</systemitem> "
+"package, it's not on the root partition. That is, it's in <filename>/usr/"
+"bin</filename> rather than <filename>/bin</filename>, so one can't use it in "
+"scripts which are run before the <filename>/usr</filename> partition is "
+"mounted. Most scripts won't have this problem, though."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: best-pkging-practices.dbk:689
+msgid ""
+"Configuration management with <systemitem role=\"package\">debconf</"
+"systemitem>"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:691
+msgid ""
+"<systemitem role=\"package\">Debconf</systemitem> is a configuration "
+"management system which can be used by all the various packaging scripts "
+"(<filename>postinst</filename> mainly) to request feedback from the user "
+"concerning how to configure the package. Direct user interactions must now "
+"be avoided in favor of <systemitem role=\"package\">debconf</systemitem> "
+"interaction. This will enable non-interactive installations in the future."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:699
+msgid ""
+"Debconf is a great tool but it is often poorly used. Many common mistakes "
+"are listed in the <citerefentry> <refentrytitle>debconf-devel</"
+"refentrytitle> <manvolnum>7</manvolnum> </citerefentry> man page. It is "
+"something that you must read if you decide to use debconf. Also, we "
+"document some best practices here."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:706
+msgid ""
+"These guidelines include some writing style and typography recommendations, "
+"general considerations about debconf usage as well as more specific "
+"recommendations for some parts of the distribution (the installation system "
+"for instance)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:712
+msgid "Do not abuse debconf"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:714
+msgid ""
+"Since debconf appeared in Debian, it has been widely abused and several "
+"criticisms received by the Debian distribution come from debconf abuse with "
+"the need of answering a wide bunch of questions before getting any little "
+"thing installed."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:720
+msgid ""
+"Keep usage notes to what they belong: the NEWS.Debian, or README.Debian "
+"file. Only use notes for important notes which may directly affect the "
+"package usability. Remember that notes will always block the install until "
+"confirmed or bother the user by email."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:726
+msgid ""
+"Carefully choose the questions priorities in maintainer scripts. See "
+"<citerefentry> <refentrytitle>debconf-devel</refentrytitle> <manvolnum>7</"
+"manvolnum> </citerefentry> for details about priorities. Most questions "
+"should use medium and low priorities."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:734
+msgid "General recommendations for authors and translators"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:736
+msgid "Write correct English"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:738
+msgid ""
+"Most Debian package maintainers are not native English speakers. So, "
+"writing properly phrased templates may not be easy for them."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:742
+msgid ""
+"Please use (and abuse) &email-debian-l10n-english; mailing list. Have your "
+"templates proofread."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:746
+msgid ""
+"Badly written templates give a poor image of your package, of your work...or "
+"even of Debian itself."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:750
+msgid ""
+"Avoid technical jargon as much as possible. If some terms sound common to "
+"you, they may be impossible to understand for others. If you cannot avoid "
+"them, try to explain them (use the extended description). When doing so, "
+"try to balance between verbosity and simplicity."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:758
+msgid "Be kind to translators"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:760
+msgid ""
+"Debconf templates may be translated. Debconf, along with its sister package "
+"<command>po-debconf</command> offers a simple framework for getting "
+"templates translated by translation teams or even individuals."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:765
+msgid ""
+"Please use gettext-based templates. Install <systemitem role=\"package\">po-"
+"debconf</systemitem> on your development system and read its documentation "
+"(man po-debconf is a good start)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:770
+msgid ""
+"Avoid changing templates too often. Changing templates text induces more "
+"work to translators which will get their translation fuzzied. If you plan "
+"changes to your original templates, please contact translators. Most active "
+"translators are very responsive and getting their work included along with "
+"your modified templates will save you additional uploads. If you use "
+"gettext-based templates, the translator's name and e-mail addresses are "
+"mentioned in the po files headers."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:779
+msgid ""
+"The use of the <command>podebconf-report-po</command> from the po-debconf "
+"package is highly recommended to warn translators which have incomplete "
+"translations and request them for updates."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:784
+msgid ""
+"If in doubt, you may also contact the translation team for a given language "
+"(debian-l10n-xxxxx@&lists-host;), or the &email-debian-i18n; mailing list."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:789
+msgid ""
+"Calls for translations posted to &email-debian-i18n; with the "
+"<filename>debian/po/templates.pot</filename> file attached or referenced in "
+"a URL are encouraged. Be sure to mentions in these calls for new "
+"translations which languages you have existing translations for, in order to "
+"avoid duplicate work."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:798
+msgid "Unfuzzy complete translations when correcting typos and spelling"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:800
+msgid ""
+"When the text of a debconf template is corrected and you are <emphasis role="
+"\"strong\">sure</emphasis> that the change does <emphasis role=\"strong"
+"\">not</emphasis> affect translations, please be kind to translators and "
+"unfuzzy their translations."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:806
+msgid ""
+"If you don't do so, the whole template will not be translated as long as a "
+"translator will send you an update."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:810
+msgid ""
+"To <emphasis role=\"strong\">unfuzzy</emphasis> translations, you can "
+"proceed the following way:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
+#: best-pkging-practices.dbk:816
+msgid ""
+"Put all incomplete PO files out of the way. You can check the completeness "
+"by using (needs the <systemitem role=\"package\">gettext</systemitem> "
+"package installed):"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><programlisting>
+#: best-pkging-practices.dbk:820
+#, no-wrap
+msgid ""
+"for i in debian/po/*po; do echo -n $i: ; msgfmt -o /dev/null\n"
+"--statistics $i; done"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
+#: best-pkging-practices.dbk:825
+msgid ""
+"move all files which report either fuzzy strings to a temporary place. "
+"Files which report no fuzzy strings (only translated and untranslated) will "
+"be kept in place."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
+#: best-pkging-practices.dbk:832
+msgid ""
+"now <emphasis role=\"strong\">and now only</emphasis>, modify the template "
+"for the typos and check again that translation are not impacted (typos, "
+"spelling errors, sometimes typographical corrections are usually OK)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
+#: best-pkging-practices.dbk:839
+msgid ""
+"run <command>debconf-updatepo</command>. This will fuzzy all strings you "
+"modified in translations. You can see this by running the above again"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
+#: best-pkging-practices.dbk:845
+msgid "use the following command:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><programlisting>
+#: best-pkging-practices.dbk:847
+#, no-wrap
+msgid "for i in debian/po/*po; do msgattrib --output-file=$i --clear-fuzzy $i; done"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
+#: best-pkging-practices.dbk:851
+msgid ""
+"move back to debian/po the files which showed fuzzy strings in the first step"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
+#: best-pkging-practices.dbk:856
+msgid "run <command>debconf-updatepo</command> again"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:863
+msgid "Do not make assumptions about interfaces"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:865
+msgid ""
+"Templates text should not make reference to widgets belonging to some "
+"debconf interfaces. Sentences like If you answer Yes... have no meaning "
+"for users of graphical interfaces which use checkboxes for boolean questions."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:870
+msgid ""
+"String templates should also avoid mentioning the default values in their "
+"description. First, because this is redundant with the values seen by the "
+"users. Also, because these default values may be different from the "
+"maintainer choices (for instance, when the debconf database was preseeded)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:876
+msgid ""
+"More generally speaking, try to avoid referring to user actions. Just give "
+"facts."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:882
+msgid "Do not use first person"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:884
+msgid ""
+"You should avoid the use of first person (I will do this... or We "
+"recommend...). The computer is not a person and the Debconf templates do "
+"not speak for the Debian developers. You should use neutral construction. "
+"Those of you who already wrote scientific publications, just write your "
+"templates like you would write a scientific paper. However, try using "
+"action voice if still possible, like Enable this if ... instead of This can "
+"be enabled if ...."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:894
+msgid "Be gender neutral"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:896
+msgid ""
+"The world is made of men and women. Please use gender-neutral constructions "
+"in your writing."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:904
+msgid "Templates fields definition"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:906
+msgid ""
+"This part gives some information which is mostly taken from the "
+"<citerefentry> <refentrytitle>debconf-devel</refentrytitle> <manvolnum>7</"
+"manvolnum> </citerefentry> manual page."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:911
+msgid "Type"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><title>
+#: best-pkging-practices.dbk:913
+msgid "string:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><para>
+#: best-pkging-practices.dbk:915
+msgid ""
+"Results in a free-form input field that the user can type any string into."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><title>
+#: best-pkging-practices.dbk:920
+msgid "password:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><para>
+#: best-pkging-practices.dbk:922
+msgid ""
+"Prompts the user for a password. Use this with caution; be aware that the "
+"password the user enters will be written to debconf's database. You should "
+"probably clean that value out of the database as soon as is possible."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><title>
+#: best-pkging-practices.dbk:929
+msgid "boolean:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><para>
+#: best-pkging-practices.dbk:931
+msgid ""
+"A true/false choice. Remember: true/false, <emphasis role=\"strong\">not "
+"yes/no</emphasis>..."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><title>
+#: best-pkging-practices.dbk:937
+msgid "select:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><para>
+#: best-pkging-practices.dbk:939
+msgid ""
+"A choice between one of a number of values. The choices must be specified "
+"in a field named 'Choices'. Separate the possible values with commas and "
+"spaces, like this: Choices: yes, no, maybe"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><title>
+#: best-pkging-practices.dbk:946
+msgid "multiselect:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><para>
+#: best-pkging-practices.dbk:948
+msgid ""
+"Like the select data type, except the user can choose any number of items "
+"from the choices list (or chose none of them)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><title>
+#: best-pkging-practices.dbk:954
+msgid "note:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><para>
+#: best-pkging-practices.dbk:956
+msgid ""
+"Rather than being a question per se, this datatype indicates a note that can "
+"be displayed to the user. It should be used only for important notes that "
+"the user really should see, since debconf will go to great pains to make "
+"sure the user sees it; halting the install for them to press a key, and even "
+"mailing the note to them in some cases."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><title>
+#: best-pkging-practices.dbk:965
+msgid "text:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><para>
+#: best-pkging-practices.dbk:967
+msgid "This type is now considered obsolete: don't use it."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><title>
+#: best-pkging-practices.dbk:972
+msgid "error:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><para>
+#: best-pkging-practices.dbk:974
+msgid ""
+"This type is designed to handle error messages. It is mostly similar to the "
+"note type. Frontends may present it differently (for instance, the dialog "
+"frontend of cdebconf draws a red screen instead of the usual blue one)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><para>
+#: best-pkging-practices.dbk:979
+msgid ""
+"It is recommended to use this type for any message that needs user attention "
+"for a correction of any kind."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:987
+msgid "Description: short and extended description"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:989
+msgid ""
+"Template descriptions have two parts: short and extended. The short "
+"description is in the Description: line of the template."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:993
+msgid ""
+"The short description should be kept short (50 characters or so) so that it "
+"may be accomodated by most debconf interfaces. Keeping it short also helps "
+"translators, as usually translations tend to end up being longer than the "
+"original."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:999
+msgid ""
+"The short description should be able to stand on its own. Some interfaces "
+"do not show the long description by default, or only if the user explicitely "
+"asks for it or even do not show it at all. Avoid things like What do you "
+"want to do?"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1005
+msgid ""
+"The short description does not necessarily have to be a full sentence. This "
+"is part of the keep it short and efficient recommendation."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1009
+msgid ""
+"The extended description should not repeat the short description word for "
+"word. If you can't think up a long description, then first, think some "
+"more. Post to debian-devel. Ask for help. Take a writing class! That "
+"extended description is important. If after all that you still can't come "
+"up with anything, leave it blank."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1016
+msgid ""
+"The extended description should use complete sentences. Paragraphs should "
+"be kept short for improved readability. Do not mix two ideas in the same "
+"paragraph but rather use another paragraph."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1021
+msgid ""
+"Don't be too verbose. User tend to ignore too long screens. 20 lines are "
+"by experience a border you shouldn't cross, because that means that in the "
+"classical dialog interface, people will need to scroll, and lot of people "
+"just don't do that."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1027
+msgid ""
+"The extended description should <emphasis role=\"strong\">never</emphasis> "
+"include a question."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1031
+msgid ""
+"For specific rules depending on templates type (string, boolean, etc.), "
+"please read below."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:1037
+msgid "Choices"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1039
+msgid ""
+"This field should be used for Select and Multiselect types. It contains the "
+"possible choices which will be presented to users. These choices should be "
+"separated by commas."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:1046
+msgid "Default"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1048
+msgid ""
+"This field is optional. It contains the default answer for string, select "
+"and multiselect templates. For multiselect templates, it may contain a "
+"comma-separated list of choices."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:1057
+msgid "Templates fields specific style guide"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:1059
+msgid "Type field"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1061
+msgid ""
+"No specific indication except: use the appropriate type by referring to the "
+"previous section."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:1067
+msgid "Description field"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1069
+msgid ""
+"Below are specific instructions for properly writing the Description (short "
+"and extended) depending on the template type."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><title>
+#: best-pkging-practices.dbk:1073
+msgid "String/password templates"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:1077
+msgid ""
+"The short description is a prompt and <emphasis role=\"strong\">not</"
+"emphasis> a title. Avoid question style prompts (IP Address?) in favour of "
+"opened prompts (IP address:). The use of colons is recommended."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:1084
+msgid ""
+"The extended description is a complement to the short description. In the "
+"extended part, explain what is being asked, rather than ask the same "
+"question again using longer words. Use complete sentences. Terse writing "
+"style is strongly discouraged."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><title>
+#: best-pkging-practices.dbk:1094
+msgid "Boolean templates"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:1098
+msgid ""
+"The short description should be phrased in the form of a question which "
+"should be kept short and should generally end with a question mark. Terse "
+"writing style is permitted and even encouraged if the question is rather "
+"long (remember that translations are often longer than original versions)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:1106
+msgid ""
+"Again, please avoid referring to specific interface widgets. A common "
+"mistake for such templates is if you answer Yes-type constructions."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><title>
+#: best-pkging-practices.dbk:1114
+msgid "Select/Multiselect"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:1118
+msgid ""
+"The short description is a prompt and <emphasis role=\"strong\">not</"
+"emphasis> a title. Do <emphasis role=\"strong\">not</emphasis> use useless "
+"Please choose... constructions. Users are clever enough to figure out they "
+"have to choose something...:)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:1126
+msgid ""
+"The extended description will complete the short description. It may refer "
+"to the available choices. It may also mention that the user may choose more "
+"than one of the available choices, if the template is a multiselect one "
+"(although the interface often makes this clear)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><title>
+#: best-pkging-practices.dbk:1136
+msgid "Notes"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:1140
+msgid "The short description should be considered to be a *title*."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:1145
+msgid ""
+"The extended description is what will be displayed as a more detailed "
+"explanation of the note. Phrases, no terse writing style."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:1151
+msgid ""
+"<emphasis role=\"strong\">Do not abuse debconf.</emphasis> Notes are the "
+"most common way to abuse debconf. As written in debconf-devel manual page: "
+"it's best to use them only for warning about very serious problems. The "
+"NEWS.Debian or README.Debian files are the appropriate location for a lot of "
+"notes. If, by reading this, you consider converting your Note type "
+"templates to entries in NEWS/Debian or README.Debian, plus consider keeping "
+"existing translations for the future."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:1166
+msgid "Choices field"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1168
+msgid ""
+"If the Choices are likely to change often, please consider using the "
+"__Choices trick. This will split each individual choice into a single "
+"string, which will considerably help translators for doing their work."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:1175 best-pkging-practices.dbk:1213
+msgid "Default field"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1177
+msgid ""
+"If the default value, for a select template, is likely to vary depending on "
+"the user language (for instance, if the choice is a language choice), please "
+"use the _DefaultChoice trick."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1182
+msgid ""
+"This special field allow translators to put the most appropriate choice "
+"according to their own language. It will become the default choice when "
+"their language is used while your own mentioned Default Choice will be used "
+"chan using English."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1188
+msgid "Example, taken from the geneweb package templates:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><screen>
+#: best-pkging-practices.dbk:1191
+#, no-wrap
+msgid ""
+"Template: geneweb/lang\n"
+"Type: select\n"
+"__Choices: Afrikaans (af), Bulgarian (bg), Catalan (ca), Chinese (zh), Czech (cs), Danish (da), Dutch (nl), English (en), Esperanto (eo), Estonian (et), Finnish (fi), French (fr), German (de), Hebrew (he), Icelandic (is), Italian (it), Latvian (lv), Norwegian (no), Polish (pl), Portuguese (pt), Romanian (ro), Russian (ru), Spanish (es), Swedish (sv)\n"
+"# This is the default choice. Translators may put their own language here\n"
+"# instead of the default.\n"
+"# WARNING : you MUST use the ENGLISH FORM of your language\n"
+"# For instance, the french translator will need to put French (fr) here.\n"
+"_DefaultChoice: English (en)[ translators, please see comment in PO files]\n"
+"_Description: Geneweb default language:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1202
+msgid ""
+"Note the use of brackets which allow internal comments in debconf fields. "
+"Also note the use of comments which will show up in files the translators "
+"will work with."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1207
+msgid ""
+"The comments are needed as the DefaultChoice trick is a bit confusing: the "
+"translators may put their own choice"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1215
+msgid ""
+"Do NOT use empty default field. If you don't want to use default values, do "
+"not use Default at all."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1219
+msgid ""
+"If you use po-debconf (and you <emphasis role=\"strong\">should</emphasis>, "
+"see 2.2), consider making this field translatable, if you think it may be "
+"translated."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1224
+msgid ""
+"If the default value may vary depending on language/country (for instance "
+"the default value for a language choice), consider using the special "
+"_DefaultChoice type documented in <citerefentry> <refentrytitle>po-debconf</"
+"refentrytitle> <manvolnum>7</manvolnum> </citerefentry>)."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: best-pkging-practices.dbk:1236
+msgid "Internationalization"
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:1238
+msgid "Handling debconf translations"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1240
+msgid ""
+"Like porters, translators have a difficult task. They work on many packages "
+"and must collaborate with many different maintainers. Moreover, most of the "
+"time, they are not native English speakers, so you may need to be "
+"particularly patient with them."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1246
+msgid ""
+"The goal of <systemitem role=\"package\">debconf</systemitem> was to make "
+"packages configuration easier for maintainers and for users. Originally, "
+"translation of debconf templates was handled with <command>debconf-"
+"mergetemplate</command>. However, that technique is now deprecated; the "
+"best way to accomplish <systemitem role=\"package\">debconf</systemitem> "
+"internationalization is by using the <systemitem role=\"package\">po-"
+"debconf</systemitem> package. This method is easier both for maintainer and "
+"translators; transition scripts are provided."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1256
+msgid ""
+"Using <systemitem role=\"package\">po-debconf</systemitem>, the translation "
+"is stored in <filename>po</filename> files (drawing from <command>gettext</"
+"command> translation techniques). Special template files contain the "
+"original messages and mark which fields are translatable. When you change "
+"the value of a translatable field, by calling <command>debconf-updatepo</"
+"command>, the translation is marked as needing attention from the "
+"translators. Then, at build time, the <command>dh_installdebconf</command> "
+"program takes care of all the needed magic to add the template along with "
+"the up-to-date translations into the binary packages. Refer to the "
+"<citerefentry> <refentrytitle>po-debconf</refentrytitle> <manvolnum>7</"
+"manvolnum> </citerefentry> manual page for details."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:1272
+msgid "Internationalized documentation"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1274
+msgid ""
+"Internationalizing documentation is crucial for users, but a lot of labor. "
+"There's no way to eliminate all that work, but you can make things easier "
+"for translators."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1279
+msgid ""
+"If you maintain documentation of any size, its easier for translators if "
+"they have access to a source control system. That lets translators see the "
+"differences between two versions of the documentation, so, for instance, "
+"they can see what needs to be retranslated. It is recommended that the "
+"translated documentation maintain a note about what source control revision "
+"the translation is based on. An interesting system is provided by <ulink "
+"url=\"&url-i18n-doc-check;\">doc-check</ulink> in the <systemitem role="
+"\"package\">boot-floppies</systemitem> package, which shows an overview of "
+"the translation status for any given language, using structured comments for "
+"the current revision of the file to be translated and, for a translated "
+"file, the revision of the original file the translation is based on. You "
+"might wish to adapt and provide that in your CVS area."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1293
+msgid ""
+"If you maintain XML or SGML documentation, we suggest that you isolate any "
+"language-independent information and define those as entities in a separate "
+"file which is included by all the different translations. This makes it "
+"much easier, for instance, to keep URLs up to date across multiple files."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: best-pkging-practices.dbk:1303
+msgid "Common packaging situations"
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:1314
+msgid "Packages using <command>autoconf</command>/<command>automake</command>"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1316
+msgid ""
+"Keeping <command>autoconf</command>'s <filename>config.sub</filename> and "
+"<filename>config.guess</filename> files up to date is critical for porters, "
+"especially on more volatile architectures. Some very good packaging "
+"practices for any package using <command>autoconf</command> and/or "
+"<command>automake</command> have been synthesized in &file-bpp-autotools; "
+"from the <systemitem role=\"package\">autotools-dev</systemitem> package. "
+"You're strongly encouraged to read this file and to follow the given "
+"recommendations."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:1328
+msgid "Libraries"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1330
+msgid ""
+"Libraries are always difficult to package for various reasons. The policy "
+"imposes many constraints to ease their maintenance and to make sure upgrades "
+"are as simple as possible when a new upstream version comes out. Breakage "
+"in a library can result in dozens of dependent packages breaking."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1336
+msgid ""
+"Good practices for library packaging have been grouped in <ulink url=\"&url-"
+"libpkg-guide;\">the library packaging guide</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:1343
+msgid "Documentation"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1345
+msgid ""
+"Be sure to follow the <ulink url=\"&url-debian-policy;ch-docs.html\">Policy "
+"on documentation</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1350
+msgid ""
+"If your package contains documentation built from XML or SGML, we recommend "
+"you not ship the XML or SGML source in the binary package(s). If users want "
+"the source of the documentation, they should retrieve the source package."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1355
+msgid ""
+"Policy specifies that documentation should be shipped in HTML format. We "
+"also recommend shipping documentation in PDF and plain text format if "
+"convenient and if output of reasonable quality is possible. However, it is "
+"generally not appropriate to ship plain text versions of documentation whose "
+"source format is HTML."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1362
+msgid ""
+"Major shipped manuals should register themselves with <systemitem role="
+"\"package\">doc-base</systemitem> on installation. See the <systemitem role="
+"\"package\">doc-base</systemitem> package documentation for more information."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:1370
+msgid "Specific types of packages"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1372
+msgid ""
+"Several specific types of packages have special sub-policies and "
+"corresponding packaging rules and practices:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:1378
+msgid ""
+"Perl related packages have a <ulink url=\"&url-perl-policy;\">Perl policy</"
+"ulink>, some examples of packages following that policy are <systemitem role="
+"\"package\">libdbd-pg-perl</systemitem> (binary perl module) or <systemitem "
+"role=\"package\">libmldbm-perl</systemitem> (arch independent perl module)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:1387
+msgid ""
+"Python related packages have their python policy; see &file-python-policy; "
+"in the <systemitem role=\"package\">python</systemitem> package."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:1394
+msgid ""
+"Emacs related packages have the <ulink url=\"&url-emacs-policy;\">emacs "
+"policy</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:1401
+msgid ""
+"Java related packages have their <ulink url=\"&url-java-policy;\">java "
+"policy</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:1408
+msgid ""
+"Ocaml related packages have their own policy, found in &file-ocaml-policy; "
+"from the <systemitem role=\"package\">ocaml</systemitem> package. A good "
+"example is the <systemitem role=\"package\">camlzip</systemitem> source "
+"package."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:1416
+msgid ""
+"Packages providing XML or SGML DTDs should conform to the recommendations "
+"found in the <systemitem role=\"package\">sgml-base-doc</systemitem> package."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:1422
+msgid ""
+"Lisp packages should register themselves with <systemitem role=\"package"
+"\">common-lisp-controller</systemitem>, about which see &file-lisp-"
+"controller;."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:1452
+msgid "Architecture-independent data"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1454
+msgid ""
+"It is not uncommon to have a large amount of architecture-independent data "
+"packaged with a program. For example, audio files, a collection of icons, "
+"wallpaper patterns, or other graphic files. If the size of this data is "
+"negligible compared to the size of the rest of the package, it's probably "
+"best to keep it all in a single package."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1461
+msgid ""
+"However, if the size of the data is considerable, consider splitting it out "
+"into a separate, architecture-independent package (_all.deb). By doing "
+"this, you avoid needless duplication of the same data into eleven or more ."
+"debs, one per each architecture. While this adds some extra overhead into "
+"the <filename>Packages</filename> files, it saves a lot of disk space on "
+"Debian mirrors. Separating out architecture-independent data also reduces "
+"processing time of <command>lintian</command> or <command>linda</command> "
+"(see <xref linkend=\"tools-lint\"/> ) when run over the entire Debian "
+"archive."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:1473
+msgid "Needing a certain locale during build"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1475
+msgid ""
+"If you need a certain locale during build, you can create a temporary file "
+"via this trick:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1479
+msgid ""
+"If you set <varname>LOCPATH</varname> to the equivalent of <filename>/usr/"
+"lib/locale</filename>, and <varname>LC_ALL</varname> to the name of the "
+"locale you generate, you should get what you want without being root. "
+"Something like this:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: best-pkging-practices.dbk:1484
+#, no-wrap
+msgid ""
+"LOCALE_PATH=debian/tmpdir/usr/lib/locale\n"
+"LOCALE_NAME=en_IN\n"
+"LOCALE_CHARSET=UTF-8\n"
+"\n"
+"mkdir -p $LOCALE_PATH\n"
+"localedef -i $LOCALE_NAME.$LOCALE_CHARSET -f $LOCALE_CHARSET $LOCALE_PATH/$LOCALE_NAME.$LOCALE_CHARSET\n"
+"\n"
+"# Using the locale\n"
+"LOCPATH=$LOCALE_PATH LC_ALL=$LOCALE_NAME.$LOCALE_CHARSET date"
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:1497
+msgid "Make transition packages deborphan compliant"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1499
+msgid ""
+"Deborphan is a program for helping users to detect which packages can safely "
+"be removed from the system, i.e. the ones that have no packages depending "
+"on them. The default operation is to search only within the libs and "
+"oldlibs sections, to hunt down unused libraries. But when passed the right "
+"argument, it tries to catch other useless packages."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1506
+msgid ""
+"For example, with --guess-dummy, deborphan tries to search all transitional "
+"packages which were needed for upgrade but which can now safely be removed. "
+"For that, it looks for the string dummy or transitional in their short "
+"description."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1512
+msgid ""
+"So, when you are creating such a package, please make sure to add this text "
+"to your short description. If you are looking for examples, just run: "
+"<command>apt-cache search .|grep dummy</command> or <command>apt-cache "
+"search .|grep transitional</command>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:1520
+msgid "Best practices for <filename>orig.tar.gz</filename> files"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1522
+msgid ""
+"There are two kinds of original source tarballs: Pristine source and "
+"repackaged upstream source."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:1526
+msgid "Pristine source"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para><footnote>
+#: best-pkging-practices.dbk:1528
+msgid ""
+"The defining characteristic of a pristine source tarball is that the .orig."
+"tar.gz file is byte-for-byte identical to a tarball officially distributed "
+"by the upstream author. <footnote>"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para><footnote><para>
+#: best-pkging-practices.dbk:1530
+msgid ""
+"We cannot prevent upstream authors from changing the tarball they distribute "
+"without also incrementing the version number, so there can be no guarantee "
+"that a pristine tarball is identical to what upstream <emphasis>currently</"
+"emphasis> distributing at any point in time. All that can be expected is "
+"that it is identical to something that upstream once <emphasis>did</"
+"emphasis> distribute. If a difference arises later (say, if upstream "
+"notices that he wasn't using maximal comression in his original distribution "
+"and then re-<literal>gzip</literal>s it), that's just too bad. Since there "
+"is no good way to upload a new .orig.tar.gz for the same version, there is "
+"not even any point in treating this situation as a bug."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1540
+msgid ""
+"</footnote> This makes it possible to use checksums to easily verify that "
+"all changes between Debian's version and upstream's are contained in the "
+"Debian diff. Also, if the original source is huge, upstream authors and "
+"others who already have the upstream tarball can save download time if they "
+"want to inspect your packaging in detail."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1548
+msgid ""
+"There is no universally accepted guidelines that upstream authors follow "
+"regarding to the directory structure inside their tarball, but <command>dpkg-"
+"source</command> is nevertheless able to deal with most upstream tarballs as "
+"pristine source. Its strategy is equivalent to the following:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
+#: best-pkging-practices.dbk:1556
+msgid "It unpacks the tarball in an empty temporary directory by doing"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><screen>
+#: best-pkging-practices.dbk:1559
+#, no-wrap
+msgid "zcat path/to/<packagename>_<upstream-version>.orig.tar.gz | tar xf -"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
+#: best-pkging-practices.dbk:1564
+msgid ""
+"If, after this, the temporary directory contains nothing but one directory "
+"and no other files, <command>dpkg-source</command> renames that directory to "
+"<literal><packagename>-<upstream-version>(.orig)</literal>. The "
+"name of the top-level directory in the tarball does not matter, and is "
+"forgotten."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
+#: best-pkging-practices.dbk:1573
+msgid ""
+"Otherwise, the upstream tarball must have been packaged without a common top-"
+"level directory (shame on the upstream author!). In this case, "
+"<command>dpkg-source</command> renames the temporary directory "
+"<emphasis>itself</emphasis> to <literal><packagename>-<upstream-"
+"version>(.orig)</literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:1584
+msgid "Repackaged upstream source"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1586
+msgid ""
+"You <emphasis role=\"strong\">should</emphasis> upload packages with a "
+"pristine source tarball if possible, but there are various reasons why it "
+"might not be possible. This is the case if upstream does not distribute the "
+"source as gzipped tar at all, or if upstream's tarball contains non-DFSG-"
+"free material that you must remove before uploading."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1593
+msgid ""
+"In these cases the developer must construct a suitable .orig.tar.gz file "
+"himself. We refer to such a tarball as a repackaged upstream source. Note "
+"that a repackaged upstream source is different from a Debian-native "
+"package. A repackaged source still comes with Debian-specific changes in a "
+"separate <literal>.diff.gz</literal> and still has a version number composed "
+"of <literal><upstream-version></literal> and <literal><debian-"
+"revision></literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1602
+msgid ""
+"There may be cases where it is desirable to repackage the source even though "
+"upstream distributes a <literal>.tar.gz</literal> that could in principle be "
+"used in its pristine form. The most obvious is if <emphasis>significant</"
+"emphasis> space savings can be achieved by recompressing the tar archive or "
+"by removing genuinely useless cruft from the upstream archive. Use your own "
+"discretion here, but be prepared to defend your decision if you repackage "
+"source that could have been pristine."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1611
+msgid "A repackaged .orig.tar.gz"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
+#: best-pkging-practices.dbk:1616
+msgid ""
+"<emphasis role=\"strong\">must</emphasis> contain detailed information how "
+"the repackaged source was obtained, and how this can be reproduced in the "
+"<filename>debian/copyright</filename>. It is also a good idea to provide a "
+"<literal>get-orig-source</literal> target in your <filename>debian/rules</"
+"filename> file that repeats the process, as described in the Policy Manual, "
+"<ulink url=\"&url-debian-policy;ch-source.html#s-debianrules\">Main building "
+"script: debian/rules</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para><footnote>
+#: best-pkging-practices.dbk:1628
+msgid ""
+"<emphasis role=\"strong\">should not</emphasis> contain any file that does "
+"not come from the upstream author(s), or whose contents has been changed by "
+"you. <footnote>"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para><footnote><para>
+#. or similarly named
+#: best-pkging-practices.dbk:1630
+msgid ""
+"As a special exception, if the omission of non-free files would lead to the "
+"source failing to build without assistance from the Debian diff, it might be "
+"appropriate to instead edit the files, omitting only the non-free parts of "
+"them, and/or explain the situation in a README.Debian-source file in the "
+"root of the source tree. But in that case please also urge the upstream "
+"author to make the non-free components easier seperable from the rest of the "
+"source."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
+#: best-pkging-practices.dbk:1642
+msgid ""
+"<emphasis role=\"strong\">should</emphasis>, except where impossible for "
+"legal reasons, preserve the entire building and portablility infrastructure "
+"provided by the upstream author. For example, it is not a sufficient reason "
+"for omitting a file that it is used only when building on MS-DOS. "
+"Similarly, a Makefile provided by upstream should not be omitted even if the "
+"first thing your <filename>debian/rules</filename> does is to overwrite it "
+"by running a configure script."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
+#: best-pkging-practices.dbk:1651
+msgid ""
+"(<emphasis>Rationale:</emphasis> It is common for Debian users who need to "
+"build software for non-Debian platforms to fetch the source from a Debian "
+"mirror rather than trying to locate a canonical upstream distribution point)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
+#: best-pkging-practices.dbk:1658
+msgid ""
+"<emphasis role=\"strong\">should</emphasis> use <literal><packagename>-"
+"<upstream-version>.orig</literal> as the name of the top-level "
+"directory in its tarball. This makes it possible to distinguish pristine "
+"tarballs from repackaged ones."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
+#: best-pkging-practices.dbk:1666
+msgid ""
+"<emphasis role=\"strong\">should</emphasis> be gzipped with maximal "
+"compression."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1671
+msgid ""
+"The canonical way to meet the latter two points is to let <literal>dpkg-"
+"source -b</literal> construct the repackaged tarball from an unpacked "
+"directory."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:1677
+msgid "Changing binary files in <literal>diff.gz</literal>"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para><footnote>
+#: best-pkging-practices.dbk:1679
+msgid ""
+"Sometimes it is necessary to change binary files contained in the original "
+"tarball, or to add binary files that are not in it. If this is done by "
+"simply copying the files into the debianized source tree, <command>dpkg-"
+"source</command> will not be able to handle this. On the other hand, "
+"according to the guidelines given above, you cannot include such a changed "
+"binary file in a repackaged <filename>orig.tar.gz</filename>. Instead, "
+"include the file in the <filename>debian</filename> directory in "
+"<command>uuencode</command>d (or similar) form <footnote>"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para><footnote><para>
+#: best-pkging-practices.dbk:1686
+msgid ""
+"The file should have a name that makes it clear which binary file it "
+"encodes. Usually, some postfix indicating the encoding should be appended "
+"to the original filename. Note that you don't need to depend on <systemitem "
+"role=\"package\">sharutils</systemitem> to get the <command>uudecode</"
+"command> program if you use <command>perl</command>'s <literal>pack</"
+"literal> function. The code could look like"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1694
+msgid ""
+"&example-uu; </footnote>. The file would then be decoded and copied to its "
+"place during the build process. Thus the change will be visible quite easy."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1700
+msgid ""
+"Some packages use <command>dbs</command> to manage patches to their upstream "
+"source, and always create a new <literal>orig.tar.gz</literal> file that "
+"contains the real <literal>orig.tar.gz</literal> in its toplevel directory. "
+"This is questionable with respect to the preference for pristine source. On "
+"the other hand, it is easy to modify or add binary files in this case: Just "
+"put them into the newly created <literal>orig.tar.gz</literal> file, besides "
+"the real one, and copy them to the right place during the build process."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:1713
+msgid "Best practices for debug packages"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1715
+msgid ""
+"A debug package is a package with a name ending in -dbg, that contains "
+"additional information that gdb can use. Since Debian binaries are stripped "
+"by default, debugging information, including function names and line "
+"numbers, is otherwise not available when running gdb on Debian binaries. "
+"Debug packages allow users who need this additional debugging information to "
+"install it, without bloating a regular system with the information."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1723
+msgid ""
+"It is up to a package's maintainer whether to create a debug package or "
+"not. Maintainers are encouraged to create debug packages for library "
+"packages, since this can aid in debugging many programs linked to a "
+"library. In general, debug packages do not need to be added for all "
+"programs; doing so would bloat the archive. But if a maintainer finds that "
+"users often need a debugging version of a program, it can be worthwhile to "
+"make a debug package for it. Programs that are core infrastructure, such as "
+"apache and the X server are also good candidates for debug packages."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1733
+msgid ""
+"Some debug packages may contain an entire special debugging build of a "
+"library or other binary, but most of them can save space and build time by "
+"instead containing separated debugging symbols that gdb can find and load on "
+"the fly when debugging a program or library. The convention in Debian is to "
+"keep these symbols in <filename>/usr/lib/debug/path</filename>, where "
+"<emphasis>path</emphasis> is the path to the executable or library. For "
+"example, debugging symbols for <filename>/usr/bin/foo</filename> go in "
+"<filename>/usr/lib/debug/usr/bin/foo</filename>, and debugging symbols for "
+"<filename>/usr/lib/libfoo.so.1</filename> go in <filename>/usr/lib/debug/usr/"
+"lib/libfoo.so.1</filename>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1745
+msgid ""
+"The debugging symbols can be extracted from an object file using objcopy --"
+"only-keep-debug. Then the object file can be stripped, and objcopy --add-"
+"gnu-debuglink used to specify the path to the debugging symbol file. "
+"<citerefentry> <refentrytitle>objcopy</refentrytitle> <manvolnum>1</"
+"manvolnum> </citerefentry> explains in detail how this works."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1752
+msgid ""
+"The dh_strip command in debhelper supports creating debug packages, and can "
+"take care of using objcopy to separate out the debugging symbols for you. "
+"If your package uses debhelper, all you need to do is call dh_strip --dbg-"
+"package=libfoo-dbg, and add an entry to debian/control for the debug package."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1759
+msgid ""
+"Note that the Debian package should depend on the package that it provides "
+"debugging symbols for, and this dependency should be versioned. For example:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: best-pkging-practices.dbk:1763
+#, no-wrap
+msgid "Depends: libfoo-dbg (= ${binary:Version})"
+msgstr ""
+
--- /dev/null
+# SOME DESCRIPTIVE TITLE
+# Copyright (C) 2007 Free Software Foundation, Inc.
+# <>, 2007.
+# , fuzzy
+#
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: PACKAGE VERSION\n"
+"Report-Msgid-Bugs-To: \n"
+"POT-Creation-Date: 2007-07-01 21:16+0000\n"
+"PO-Revision-Date: 2007-07-01 23:09+0000\n"
+"Last-Translator: <>\n"
+"Language-Team: \n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: "
+
+# type: Content of: <chapter><title>
+#: beyond-pkging.dbk:7
+msgid "Beyond Packaging"
+msgstr "Au-delà de l'empaquetage"
+
+# type: Content of: <chapter><para>
+#: beyond-pkging.dbk:9
+msgid ""
+"Debian is about a lot more than just packaging software and maintaining "
+"those packages. This chapter contains information about ways, often really "
+"critical ways, to contribute to Debian beyond simply creating and "
+"maintaining packages."
+msgstr ""
+
+# type: Content of: <chapter><para>
+#: beyond-pkging.dbk:14
+msgid ""
+"As a volunteer organization, Debian relies on the discretion of its members "
+"in choosing what they want to work on and in choosing the most critical "
+"thing to spend their time on."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: beyond-pkging.dbk:19
+msgid "Bug reporting"
+msgstr "Rapporter des bogues"
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:21
+msgid ""
+"We encourage you to file bugs as you find them in Debian packages. In fact, "
+"Debian developers are often the first line testers. Finding and reporting "
+"bugs in other developers' packages improves the quality of Debian."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:26
+msgid ""
+"Read the <ulink url=\"&url-bts-report;\">instructions for reporting bugs</"
+"ulink> in the Debian <ulink url=\"&url-bts;\">bug tracking system</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:31
+msgid ""
+"Try to submit the bug from a normal user account at which you are likely to "
+"receive mail, so that people can reach you if they need further information "
+"about the bug. Do not submit bugs as root."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:36
+msgid ""
+"You can use a tool like <citerefentry> <refentrytitle>reportbug</"
+"refentrytitle> <manvolnum>1</manvolnum> </citerefentry> to submit bugs. It "
+"can automate and generally ease the process."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:41
+msgid ""
+"Make sure the bug is not already filed against a package. Each package has "
+"a bug list easily reachable at <literal>http://&bugs-host;/"
+"<replaceable>packagename</replaceable></literal> Utilities like "
+"<citerefentry> <refentrytitle>querybts</refentrytitle> <manvolnum>1</"
+"manvolnum> </citerefentry> can also provide you with this information (and "
+"<command>reportbug</command> will usually invoke <command>querybts</command> "
+"before sending, too)."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:50
+msgid ""
+"Try to direct your bugs to the proper location. When for example your bug "
+"is about a package which overwrites files from another package, check the "
+"bug lists for <emphasis>both</emphasis> of those packages in order to avoid "
+"filing duplicate bug reports."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:56
+msgid ""
+"For extra credit, you can go through other packages, merging bugs which are "
+"reported more than once, or tagging bugs `fixed' when they have already been "
+"fixed. Note that when you are neither the bug submitter nor the package "
+"maintainer, you should not actually close the bug (unless you secure "
+"permission from the maintainer)."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:63
+msgid ""
+"From time to time you may want to check what has been going on with the bug "
+"reports that you submitted. Take this opportunity to close those that you "
+"can't reproduce anymore. To find out all the bugs you submitted, you just "
+"have to visit <literal>http://&bugs-host;/from:<replaceable><your-email-"
+"addr></replaceable></literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: beyond-pkging.dbk:70
+msgid "Reporting lots of bugs at once (mass bug filing)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:72
+msgid ""
+"Reporting a great number of bugs for the same problem on a great number of "
+"different packages — i.e., more than 10 — is a deprecated practice. Take "
+"all possible steps to avoid submitting bulk bugs at all. For instance, if "
+"checking for the problem can be automated, add a new check to <systemitem "
+"role=\"package\">lintian</systemitem> so that an error or warning is emitted."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:79
+msgid ""
+"If you report more than 10 bugs on the same topic at once, it is recommended "
+"that you send a message to &email-debian-devel; describing your intention "
+"before submitting the report, and mentioning the fact in the subject of your "
+"mail. This will allow other developers to verify that the bug is a real "
+"problem. In addition, it will help prevent a situation in which several "
+"maintainers start filing the same bug report simultaneously."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:87
+msgid ""
+"Please use the programms <command>dd-list</command> and if appropriate "
+"<command>whodepends</command> (from the package devscripts) to generate a "
+"list of all affected packages, and include the output in your mail to &email-"
+"debian-devel;."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:93
+msgid ""
+"Note that when sending lots of bugs on the same subject, you should send the "
+"bug report to <email>maintonly@&bugs-host;</email> so that the bug report is "
+"not forwarded to the bug distribution mailing list."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: beyond-pkging.dbk:102
+msgid "Quality Assurance effort"
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: beyond-pkging.dbk:104
+msgid "Daily work"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:106
+msgid ""
+"Even though there is a dedicated group of people for Quality Assurance, QA "
+"duties are not reserved solely for them. You can participate in this effort "
+"by keeping your packages as bug-free as possible, and as lintian-clean (see "
+"<xref linkend=\"lintian\"/> ) as possible. If you do not find that "
+"possible, then you should consider orphaning some of your packages (see "
+"<xref linkend=\"orphaning\"/> ). Alternatively, you may ask the help of "
+"other people in order to catch up with the backlog of bugs that you have "
+"(you can ask for help on &email-debian-qa; or &email-debian-devel;). At the "
+"same time, you can look for co-maintainers (see <xref linkend="
+"\"collaborative-maint\"/> )."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: beyond-pkging.dbk:120
+msgid "Bug squashing parties"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:122
+msgid ""
+"From time to time the QA group organizes bug squashing parties to get rid of "
+"as many problems as possible. They are announced on &email-debian-devel-"
+"announce; and the announcement explains which area will be the focus of the "
+"party: usually they focus on release critical bugs but it may happen that "
+"they decide to help finish a major upgrade (like a new perl version which "
+"requires recompilation of all the binary modules)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:131
+msgid ""
+"The rules for non-maintainer uploads differ during the parties because the "
+"announcement of the party is considered prior notice for NMU. If you have "
+"packages that may be affected by the party (because they have release "
+"critical bugs for example), you should send an update to each of the "
+"corresponding bug to explain their current status and what you expect from "
+"the party. If you don't want an NMU, or if you're only interested in a "
+"patch, or if you will deal yourself with the bug, please explain that in the "
+"BTS."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:140
+msgid ""
+"People participating in the party have special rules for NMU, they can NMU "
+"without prior notice if they upload their NMU to DELAYED/3-day at least. "
+"All other NMU rules apply as usually; they should send the patch of the NMU "
+"to the BTS (to one of the open bugs fixed by the NMU, or to a new bug, "
+"tagged fixed). They should also respect any particular wishes of the "
+"maintainer."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:147
+msgid ""
+"If you don't feel confident about doing an NMU, just send a patch to the "
+"BTS. It's far better than a broken NMU."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: beyond-pkging.dbk:155
+msgid "Contacting other maintainers"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:157
+msgid ""
+"During your lifetime within Debian, you will have to contact other "
+"maintainers for various reasons. You may want to discuss a new way of "
+"cooperating between a set of related packages, or you may simply remind "
+"someone that a new upstream version is available and that you need it."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:163
+msgid ""
+"Looking up the email address of the maintainer for the package can be "
+"distracting. Fortunately, there is a simple email alias, <literal><"
+"package>@&packages-host;</literal>, which provides a way to email the "
+"maintainer, whatever their individual email address (or addresses) may be. "
+"Replace <literal><package></literal> with the name of a source or a "
+"binary package."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:171
+msgid ""
+"You may also be interested in contacting the persons who are subscribed to a "
+"given source package via <xref linkend=\"pkg-tracking-system\"/> . You can "
+"do so by using the <literal><package>@&pts-host;</literal> email "
+"address."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: beyond-pkging.dbk:180
+msgid "Dealing with inactive and/or unreachable maintainers"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:182
+msgid ""
+"If you notice that a package is lacking maintenance, you should make sure "
+"that the maintainer is active and will continue to work on their packages. "
+"It is possible that they are not active any more, but haven't registered out "
+"of the system, so to speak. On the other hand, it is also possible that "
+"they just need a reminder."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:189
+msgid ""
+"There is a simple system (the MIA database) in which information about "
+"maintainers who are deemed Missing In Action is recorded. When a member of "
+"the QA group contacts an inactive maintainer or finds more information about "
+"one, this is recorded in the MIA database. This system is available in /org/"
+"qa.debian.org/mia on the host qa.debian.org, and can be queried with a tool "
+"known as <command>mia-query</command>. Use <command>mia-query --help</"
+"command> to see how to query the database. If you find that no information "
+"has been recorded about an inactive maintainer yet, or that you can add more "
+"information, you should generally proceed as follows."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:200
+msgid ""
+"The first step is to politely contact the maintainer, and wait a reasonable "
+"time for a response. It is quite hard to define reasonable time, but it is "
+"important to take into account that real life is sometimes very hectic. One "
+"way to handle this would be to send a reminder after two weeks."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:206
+msgid ""
+"If the maintainer doesn't reply within four weeks (a month), one can assume "
+"that a response will probably not happen. If that happens, you should "
+"investigate further, and try to gather as much useful information about the "
+"maintainer in question as possible. This includes:"
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: beyond-pkging.dbk:214
+msgid ""
+"The echelon information available through the <ulink url=\"&url-debian-db;"
+"\">developers' LDAP database</ulink>, which indicates when the developer "
+"last posted to a Debian mailing list. (This includes uploads via debian-*-"
+"changes lists.) Also, remember to check whether the maintainer is marked as "
+"on vacation in the database."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: beyond-pkging.dbk:223
+msgid ""
+"The number of packages this maintainer is responsible for, and the condition "
+"of those packages. In particular, are there any RC bugs that have been open "
+"for ages? Furthermore, how many bugs are there in general? Another important "
+"piece of information is whether the packages have been NMUed, and if so, by "
+"whom."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: beyond-pkging.dbk:232
+msgid ""
+"Is there any activity of the maintainer outside of Debian? For example, they "
+"might have posted something recently to non-Debian mailing lists or news "
+"groups."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:239
+msgid ""
+"A bit of a problem are packages which were sponsored — the maintainer is not "
+"an official Debian developer. The echelon information is not available for "
+"sponsored people, for example, so you need to find and contact the Debian "
+"developer who has actually uploaded the package. Given that they signed the "
+"package, they're responsible for the upload anyhow, and are likely to know "
+"what happened to the person they sponsored."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:247
+msgid ""
+"It is also allowed to post a query to &email-debian-devel;, asking if anyone "
+"is aware of the whereabouts of the missing maintainer. Please Cc: the "
+"person in question."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:252
+msgid ""
+"Once you have gathered all of this, you can contact &email-mia;. People on "
+"this alias will use the information you provide in order to decide how to "
+"proceed. For example, they might orphan one or all of the packages of the "
+"maintainer. If a package has been NMUed, they might prefer to contact the "
+"NMUer before orphaning the package — perhaps the person who has done the NMU "
+"is interested in the package."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:260
+msgid ""
+"One last word: please remember to be polite. We are all volunteers and "
+"cannot dedicate all of our time to Debian. Also, you are not aware of the "
+"circumstances of the person who is involved. Perhaps they might be "
+"seriously ill or might even have died — you do not know who may be on the "
+"receiving side. Imagine how a relative will feel if they read the e-mail of "
+"the deceased and find a very impolite, angry and accusing message!"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:268
+msgid ""
+"On the other hand, although we are volunteers, we do have a responsibility. "
+"So you can stress the importance of the greater good — if a maintainer does "
+"not have the time or interest anymore, they should let go and give the "
+"package to someone with more time."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:274
+msgid ""
+"If you are interested in working in the MIA team, please have a look at the "
+"README file in /org/qa.debian.org/mia on qa.debian.org where the technical "
+"details and the MIA procedures are documented and contact &email-mia;."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: beyond-pkging.dbk:282
+msgid "Interacting with prospective Debian developers"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:284
+msgid ""
+"Debian's success depends on its ability to attract and retain new and "
+"talented volunteers. If you are an experienced developer, we recommend that "
+"you get involved with the process of bringing in new developers. This "
+"section describes how to help new prospective developers."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: beyond-pkging.dbk:290
+msgid "Sponsoring packages"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:292
+msgid ""
+"Sponsoring a package means uploading a package for a maintainer who is not "
+"able to do it on their own, a new maintainer applicant. Sponsoring a "
+"package also means accepting responsibility for it."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:303
+msgid ""
+"New maintainers usually have certain difficulties creating Debian packages — "
+"this is quite understandable. That is why the sponsor is there, to check "
+"the package and verify that it is good enough for inclusion in Debian. "
+"(Note that if the sponsored package is new, the ftpmasters will also have to "
+"inspect it before letting it in.)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:310
+msgid ""
+"Sponsoring merely by signing the upload or just recompiling is <emphasis "
+"role=\"strong\">definitely not recommended</emphasis>. You need to build "
+"the source package just like you would build a package of your own. "
+"Remember that it doesn't matter that you left the prospective developer's "
+"name both in the changelog and the control file, the upload can still be "
+"traced to you."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:317
+msgid ""
+"If you are an application manager for a prospective developer, you can also "
+"be their sponsor. That way you can also verify how the applicant is "
+"handling the 'Tasks and Skills' part of their application."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: beyond-pkging.dbk:324
+msgid "Managing sponsored packages"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:326
+msgid ""
+"By uploading a sponsored package to Debian, you are certifying that the "
+"package meets minimum Debian standards. That implies that you must build "
+"and test the package on your own system before uploading."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:331
+msgid ""
+"You cannot simply upload a binary <filename>.deb</filename> from the "
+"sponsoree. In theory, you should only ask for the diff file and the "
+"location of the original source tarball, and then you should download the "
+"source and apply the diff yourself. In practice, you may want to use the "
+"source package built by your sponsoree. In that case, you have to check "
+"that they haven't altered the upstream files in the <filename>.orig.tar.gz</"
+"filename> file that they're providing."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:340
+msgid ""
+"Do not be afraid to write the sponsoree back and point out changes that need "
+"to be made. It often takes several rounds of back-and-forth email before "
+"the package is in acceptable shape. Being a sponsor means being a mentor."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:345
+msgid "Once the package meets Debian standards, build and sign it with"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: beyond-pkging.dbk:348
+#, no-wrap
+msgid "dpkg-buildpackage -k<replaceable>KEY-ID</replaceable>"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:351
+msgid ""
+"before uploading it to the incoming directory. Of course, you can also use "
+"any part of your <replaceable>KEY-ID</replaceable>, as long as it's unique "
+"in your secret keyring."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:356
+msgid ""
+"The Maintainer field of the <filename>control</filename> file and the "
+"<filename>changelog</filename> should list the person who did the packaging, "
+"i.e., the sponsoree. The sponsoree will therefore get all the BTS mail "
+"about the package."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:362
+msgid ""
+"If you prefer to leave a more evident trace of your sponsorship job, you can "
+"add a line stating it in the most recent changelog entry."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:366
+msgid ""
+"You are encouraged to keep tabs on the package you sponsor using <xref "
+"linkend=\"pkg-tracking-system\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: beyond-pkging.dbk:372
+msgid "Advocating new developers"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:374
+msgid ""
+"See the page about <ulink url=\"&url-newmaint-advocate;\">advocating a "
+"prospective developer</ulink> at the Debian web site."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: beyond-pkging.dbk:381
+msgid "Handling new maintainer applications"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:383
+msgid ""
+"Please see <ulink url=\"&url-newmaint-amchecklist;\">Checklist for "
+"Application Managers</ulink> at the Debian web site."
+msgstr ""
+
--- /dev/null
+# SOME DESCRIPTIVE TITLE
+# Copyright (C) 2007 Free Software Foundation, Inc.
+# <>, 2007.
+# , fuzzy
+#
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: PACKAGE VERSION\n"
+"Report-Msgid-Bugs-To: \n"
+"POT-Creation-Date: 2007-07-01 21:16+0000\n"
+"PO-Revision-Date: 2007-07-01 23:10+0000\n"
+"Last-Translator: <>\n"
+"Language-Team: \n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: "
+
+# type: Content of: <chapter><title>
+#: developer-duties.dbk:7
+msgid "Debian Developer's Duties"
+msgstr "Les charges du responsable Debian"
+
+# type: Content of: <chapter><section><title>
+#: developer-duties.dbk:9
+msgid "Maintaining your Debian information"
+msgstr "Mise à jour de vos références Debian"
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:11
+msgid ""
+"There's a LDAP database containing information about Debian developers at "
+"<ulink url=\"&url-debian-db;\"></ulink>. You should enter your information "
+"there and update it as it changes. Most notably, make sure that the address "
+"where your debian.org email gets forwarded to is always up to date, as well "
+"as the address where you get your debian-private subscription if you choose "
+"to subscribe there."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:19
+msgid ""
+"For more information about the database, please see <xref linkend=\"devel-db"
+"\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: developer-duties.dbk:25
+msgid "Maintaining your public key"
+msgstr "Gérer votre clé publique"
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:27
+msgid ""
+"Be very careful with your private keys. Do not place them on any public "
+"servers or multiuser machines, such as the Debian servers (see <xref linkend="
+"\"server-machines\"/> ). Back your keys up; keep a copy offline. Read the "
+"documentation that comes with your software; read the <ulink url=\"&url-pgp-"
+"faq;\">PGP FAQ</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:34
+msgid ""
+"You need to ensure not only that your key is secure against being stolen, "
+"but also that it is secure against being lost. Generate and make a copy "
+"(best also in paper form) of your revocation certificate; this is needed if "
+"your key is lost."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:40
+msgid ""
+"If you add signatures to your public key, or add user identities, you can "
+"update the Debian key ring by sending your key to the key server at "
+"<literal>&keyserver-host;</literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:45
+msgid ""
+"If you need to add a completely new key or remove an old key, you need to "
+"get the new key signed by another developer. If the old key is compromised "
+"or invalid, you also have to add the revocation certificate. If there is no "
+"real reason for a new key, the Keyring Maintainers might reject the new "
+"key. Details can be found at <ulink url=\"http://&keyserver-host;/"
+"replacing_keys.html\"></ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:53
+msgid ""
+"The same key extraction routines discussed in <xref linkend=\"registering\"/"
+"> apply."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:57
+msgid ""
+"You can find a more in-depth discussion of Debian key maintenance in the "
+"documentation of the <systemitem role=\"package\">debian-keyring</"
+"systemitem> package."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: developer-duties.dbk:64
+msgid "Voting"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:66
+msgid ""
+"Even though Debian isn't really a democracy, we use a democratic process to "
+"elect our leaders and to approve general resolutions. These procedures are "
+"defined by the <ulink url=\"&url-constitution;\">Debian Constitution</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:72
+msgid ""
+"Other than the yearly leader election, votes are not routinely held, and "
+"they are not undertaken lightly. Each proposal is first discussed on the "
+"&email-debian-vote; mailing list and it requires several endorsements before "
+"the project secretary starts the voting procedure."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:78
+msgid ""
+"You don't have to track the pre-vote discussions, as the secretary will "
+"issue several calls for votes on &email-debian-devel-announce; (and all "
+"developers are expected to be subscribed to that list). Democracy doesn't "
+"work well if people don't take part in the vote, which is why we encourage "
+"all developers to vote. Voting is conducted via GPG-signed/encrypted email "
+"messages."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:86
+msgid ""
+"The list of all proposals (past and current) is available on the <ulink url="
+"\"&url-vote;\">Debian Voting Information</ulink> page, along with "
+"information on how to make, second and vote on proposals."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: developer-duties.dbk:93
+msgid "Going on vacation gracefully"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:95
+msgid ""
+"It is common for developers to have periods of absence, whether those are "
+"planned vacations or simply being buried in other work. The important thing "
+"to notice is that other developers need to know that you're on vacation so "
+"that they can do whatever is needed if a problem occurs with your packages "
+"or other duties in the project."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:102
+msgid ""
+"Usually this means that other developers are allowed to NMU (see <xref "
+"linkend=\"nmu\"/> ) your package if a big problem (release critical bug, "
+"security update, etc.) occurs while you're on vacation. Sometimes it's "
+"nothing as critical as that, but it's still appropriate to let others know "
+"that you're unavailable."
+msgstr ""
+
+# type: Content of: <chapter><section><para><footnote>
+#: developer-duties.dbk:109
+msgid ""
+"In order to inform the other developers, there are two things that you "
+"should do. First send a mail to <email>debian-private@&lists-host;</email> "
+"with [VAC] prepended to the subject of your message<footnote>"
+msgstr ""
+
+# type: Content of: <chapter><section><para><footnote><para>
+#: developer-duties.dbk:111
+msgid ""
+"This is so that the message can be easily filtered by people who don't want "
+"to read vacation notices."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:113
+msgid ""
+"</footnote> and state the period of time when you will be on vacation. You "
+"can also give some special instructions on what to do if a problem occurs."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:118
+msgid ""
+"The other thing to do is to mark yourself as on vacation in the <link "
+"linkend=\"devel-db\">Debian developers' LDAP database</link> (this "
+"information is only accessible to Debian developers). Don't forget to "
+"remove the on vacation flag when you come back!"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:124
+msgid ""
+"Ideally, you should sign up at the <ulink url=\"&url-newmaint-db;gpg.php"
+"\">GPG coordination site</ulink> when booking a holiday and check if anyone "
+"there is looking for signing. This is especially important when people go "
+"to exotic places where we don't have any developers yet but where there are "
+"people who are interested in applying."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: developer-duties.dbk:133
+msgid "Coordination with upstream developers"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:135
+msgid ""
+"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 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."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:142
+msgid ""
+"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."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:149
+msgid ""
+"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 "
+"developers which can be included there, so that you won't have to modify the "
+"sources of the next upstream version. Whatever changes you need, always try "
+"not to fork from the upstream sources."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: developer-duties.dbk:158
+msgid "Managing release-critical bugs"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:160
+msgid ""
+"Generally you should deal with bug reports on your packages as described in "
+"<xref linkend=\"bug-handling\"/> . However, there's a special category of "
+"bugs that you need to take care of — the so-called release-critical bugs (RC "
+"bugs). All bug reports that have severity <emphasis>critical</emphasis>, "
+"<emphasis>grave</emphasis> or <emphasis>serious</emphasis> are considered to "
+"have an impact on whether the package can be released in the next stable "
+"release of Debian. These bugs can delay the Debian release and/or can "
+"justify the removal of a package at freeze time. That's why these bugs need "
+"to be corrected as quickly as possible."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:171
+msgid ""
+"Developers who are part of the <ulink url=\"&url-debian-qa;\">Quality "
+"Assurance</ulink> group are following all such bugs, and trying to help "
+"whenever possible. If, for any reason, you aren't able fix an RC bug in a "
+"package of yours within 2 weeks, you should either ask for help by sending a "
+"mail to the Quality Assurance (QA) group <email>debian-qa@&lists-host;</"
+"email>, or explain your difficulties and present a plan to fix them by "
+"sending a mail to the bug report. Otherwise, people from the QA group may "
+"want to do a Non-Maintainer Upload (see <xref linkend=\"nmu\"/> ) after "
+"trying to contact you (they might not wait as long as usual before they do "
+"their NMU if they have seen no recent activity from you in the BTS)."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: developer-duties.dbk:186
+msgid "Retiring"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:188
+msgid ""
+"If you choose to leave the Debian project, you should make sure you do the "
+"following steps:"
+msgstr ""
+
+# type: Content of: <chapter><section><orderedlist><listitem><para>
+#: developer-duties.dbk:194
+msgid ""
+"Orphan all your packages, as described in <xref linkend=\"orphaning\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><orderedlist><listitem><para>
+#: developer-duties.dbk:199
+msgid ""
+"Send an gpg-signed email about why you are leaving the project to "
+"<email>debian-private@&lists-host;</email>."
+msgstr ""
+
+# type: Content of: <chapter><section><orderedlist><listitem><para>
+#: developer-duties.dbk:205
+msgid ""
+"Notify the Debian key ring maintainers that you are leaving by opening a "
+"ticket in Debian RT by sending a mail to keyring@rt.debian.org with the "
+"words 'Debian RT' somewhere in the subject line (case doesn't matter)."
+msgstr ""
+
--- /dev/null
+# SOME DESCRIPTIVE TITLE
+# Copyright (C) 2007 Free Software Foundation, Inc.
+# debacle <>, 2007.
+# , fuzzy
+#
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: PACKAGE VERSION\n"
+"Report-Msgid-Bugs-To: \n"
+"POT-Creation-Date: 2007-07-01 22:28+0000\n"
+"PO-Revision-Date: 2007-07-01 23:36+0000\n"
+"Last-Translator: debacle <>\n"
+"Language-Team: English <en@li.org>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit"
+
+# type: Attribute 'lang' of: <book>
+#: index.dbk:7
+msgid "en"
+msgstr "fr"
+
+# type: Content of: <book><title>
+#: index.dbk:9
+msgid "Debian Developer's Reference"
+msgstr "Référence du développeur Debian"
+
+# type: Content of: <book><bookinfo><releaseinfo>
+#: index.dbk:30
+msgid "ver. &version;"
+msgstr "ver.·&version;"
+
+# type: Content of: <book><bookinfo><pubdate>
+#: index.dbk:31
+msgid "&pubdate;"
+msgstr "&pubdate;"
+
+# type: Content of: <book><bookinfo><copyright><holder>
+#: index.dbk:37
+msgid "Andreas Barth"
+msgstr "Andreas Barth"
+
+# type: Content of: <book><bookinfo><copyright><holder>
+#: index.dbk:46
+msgid "Adam Di Carlo"
+msgstr "Adam Di Carlo"
+
+# type: Content of: <book><bookinfo><copyright><holder>
+#: index.dbk:51
+msgid "Raphaël Hertzog"
+msgstr "Raphaël Hertzog"
+
+# type: Content of: <book><bookinfo><copyright><holder>
+#: index.dbk:56
+msgid "Christian Schwarz"
+msgstr "Christian Schwarz"
+
+# type: Content of: <book><bookinfo><legalnotice><para>
+#: index.dbk:60
+msgid ""
+"This manual is free software; you may redistribute it and/or modify it under "
+"the terms of the GNU General Public License as published by the Free "
+"Software Foundation; either version 2, or (at your option) any later version."
+msgstr ""
+"Ce manuel est un logiciel libre; il peut être redistribué et/ou modifié "
+"selon les termes de la licence publique générale du projet GNU (GNU GPL), "
+"telle que publiée par la «Free Software Foundation» (version 2 ou toute "
+"version postérieure)."
+
+# type: Content of: <book><bookinfo><legalnotice><para>
+#: index.dbk:65
+msgid ""
+"This is distributed in the hope that it will be useful, but "
+"<emphasis>without any warranty</emphasis>; without even the implied warranty "
+"of merchantability or fitness for a particular purpose. See the GNU General "
+"Public License for more details."
+msgstr ""
+"Il est distribué dans l'espoir qu'il sera utile, mais <emphasis>sans aucune "
+"garantie</emphasis>, sans même la garantie implicite d'une possible valeur "
+"marchande ou d'une adéquation à un besoin particulier. Consultez la licence "
+"publique générale du projet GNU pour plus de détails."
+
+# type: Content of: <book><bookinfo><legalnotice><para>
+#: index.dbk:71
+msgid ""
+"A copy of the GNU General Public License is available as &file-GPL; in the "
+"&debian-formal; distribution or on the World Wide Web at <ulink url=\"&url-"
+"gpl;\">the GNU web site</ulink>. You can also obtain it by writing to the "
+"&fsf-addr;."
+msgstr ""
+"Une copie de la licence publique générale du projet GNU est disponible dans "
+"le fichier &file-GPL; de la distribution &debian-formal; ou sur la toile: "
+"<ulink url=\"&url-gpl;\">la licence publique générale du projet GNU</ulink>. "
+"Vous pouvez également l'obtenir en écrivant à la &fsf-addr;."
+
+# type: Content of: <book><bookinfo><legalnotice><para>
+#. TODO: Maybe better: "This document has originally been written
+#. in English. Translations into different languages are available."
+#: index.dbk:78
+msgid ""
+"If you want to print this reference, you should use the <ulink url="
+"\"developers-reference.pdf\">pdf version</ulink>. This page is also "
+"available in <ulink url=\"index.fr.html\">French</ulink>."
+msgstr ""
+"Si vous désirez imprimer cette référence, vous devriez utiliser la <ulink "
+"url=\"developers-reference.pdf\">version PDF</ulink>. Cette page est "
+"également disponible en <ulink url=\"index.html\">anglais</ulink>."
+
+# type: Content of: <book><bookinfo><releaseinfo>
+#~ msgid "ver. 3.3.9, 16 June, 2007"
+#~ msgstr "ver. 3.3.9, 16 June, 2007"
--- /dev/null
+# SOME DESCRIPTIVE TITLE
+# Copyright (C) 2007 Free Software Foundation, Inc.
+# <>, 2007.
+# , fuzzy
+#
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: PACKAGE VERSION\n"
+"Report-Msgid-Bugs-To: \n"
+"POT-Creation-Date: 2007-07-01 21:16+0000\n"
+"PO-Revision-Date: 2007-07-01 23:14+0000\n"
+"Last-Translator: <>\n"
+"Language-Team: \n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: "
+
+# type: Content of: <chapter><title>
+#: l10n.dbk:7
+msgid ""
+"Internationalizing, translating, being internationalized and being translated"
+msgstr "Internationalisation, traduction, être internationalisé et être traduit"
+
+# type: Content of: <chapter><para>
+#: l10n.dbk:9
+msgid ""
+"Debian supports an ever-increasing number of natural languages. Even if you "
+"are a native English speaker and do not speak any other language, it is part "
+"of your duty as a maintainer to be aware of issues of internationalization "
+"(abbreviated i18n because there are 18 letters between the 'i' and the 'n' "
+"in internationalization). Therefore, even if you are ok with English-only "
+"programs, you should read most of this chapter."
+msgstr ""
+
+# type: Content of: <chapter><para>
+#: l10n.dbk:17
+msgid ""
+"According to <ulink url=\"http://&www-debian-org;/doc/manuals/intro-i18n/"
+"\">Introduction to i18n</ulink> from Tomohiro KUBOTA, I18N "
+"(internationalization) means modification of a software or related "
+"technologies so that a software can potentially handle multiple languages, "
+"customs, and so on in the world. while L10N (localization) means "
+"implementation of a specific language for an already internationalized "
+"software."
+msgstr "Selon l'<ulink url=\"http://www.debian.org/doc/manuals/intro-i18n/\">introduction à l'i18n</ulink> de Tomohiro KUBOTA, «I18N"
+"(internationalisation) veut dire la modification d'un logiciel ou de"
+"technologies liées pour qu'un logiciel puisse potentiellement gérer des"
+"langues multiples, des conventions multiples et ainsi de suite dans le"
+"monde entier» alors que «L10N (localisation) veut dire"
+"l'implémentation dans une langue spécifique pour un logiciel déjà"
+"internationalisé»."
+
+# type: Content of: <chapter><para>
+#: l10n.dbk:26
+msgid ""
+"l10n and i18n are interconnected, but the difficulties related to each of "
+"them are very different. It's not really difficult to allow a program to "
+"change the language in which texts are displayed based on user settings, but "
+"it is very time consuming to actually translate these messages. On the "
+"other hand, setting the character encoding is trivial, but adapting the code "
+"to use several character encodings is a really hard problem."
+msgstr ""
+
+# type: Content of: <chapter><para>
+#: l10n.dbk:34
+msgid ""
+"Setting aside the i18n problems, where no general guideline can be given, "
+"there is actually no central infrastructure for l10n within Debian which "
+"could be compared to the dbuild mechanism for porting. So most of the work "
+"has to be done manually."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: l10n.dbk:40
+msgid "How translations are handled within Debian"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: l10n.dbk:42
+msgid ""
+"Handling translation of the texts contained in a package is still a manual "
+"task, and the process depends on the kind of text you want to see translated."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: l10n.dbk:46
+msgid ""
+"For program messages, the gettext infrastructure is used most of the time. "
+"Most of the time, the translation is handled upstream within projects like "
+"the <ulink url=\"http://www.iro.umontreal.ca/contrib/po/HTML/\">Free "
+"Translation Project</ulink>, the <ulink url=\"http://developer.gnome.org/"
+"projects/gtp/\">Gnome translation Project</ulink> or the <ulink url=\"http://"
+"i18n.kde.org/\">KDE one</ulink>. The only centralized resource within "
+"Debian is the <ulink url=\"http://&www-debian-org;/intl/l10n/\">Central "
+"Debian translation statistics</ulink>, where you can find some statistics "
+"about the translation files found in the actual packages, but no real "
+"infrastructure to ease the translation process."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: l10n.dbk:59
+msgid ""
+"An effort to translate the package descriptions started long ago, even if "
+"very little support is offered by the tools to actually use them (i.e., only "
+"APT can use them, when configured correctly). Maintainers don't need to do "
+"anything special to support translated package descriptions; translators "
+"should use the <ulink url=\"http://ddtp.debian.org/\">DDTP</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: l10n.dbk:66
+msgid ""
+"For debconf templates, maintainers should use the po-debconf package to ease "
+"the work of translators, who could use the DDTP to do their work (but the "
+"French and Brazilian teams don't). Some statistics can be found both on the "
+"DDTP site (about what is actually translated), and on the <ulink url="
+"\"http://&www-debian-org;/intl/l10n/\">Central Debian translation "
+"statistics</ulink> site (about what is integrated in the packages)."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: l10n.dbk:74
+msgid ""
+"For web pages, each l10n team has access to the relevant CVS, and the "
+"statistics are available from the Central Debian translation statistics site."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: l10n.dbk:78
+msgid ""
+"For general documentation about Debian, the process is more or less the same "
+"as for the web pages (the translators have access to the CVS), but there are "
+"no statistics pages."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: l10n.dbk:83
+msgid ""
+"For package-specific documentation (man pages, info documents, other "
+"formats), almost everything remains to be done."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: l10n.dbk:87
+msgid ""
+"Most notably, the KDE project handles translation of its documentation in "
+"the same way as its program messages."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: l10n.dbk:91
+msgid ""
+"There is an effort to handle Debian-specific man pages within a <ulink url="
+"\"&url-cvsweb;manpages/?cvsroot=debian-doc\">specific CVS repository</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: l10n.dbk:98
+msgid "I18N & L10N FAQ for maintainers"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: l10n.dbk:100
+msgid ""
+"This is a list of problems that maintainers may face concerning i18n and "
+"l10n. While reading this, keep in mind that there is no real consensus on "
+"these points within Debian, and that this is only advice. If you have a "
+"better idea for a given problem, or if you disagree on some points, feel "
+"free to provide your feedback, so that this document can be enhanced."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: l10n.dbk:107
+msgid "How to get a given text translated"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: l10n.dbk:109
+msgid ""
+"To translate package descriptions or debconf templates, you have nothing to "
+"do; the DDTP infrastructure will dispatch the material to translate to "
+"volunteers with no need for interaction from your part."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: l10n.dbk:114
+msgid ""
+"For all other material (gettext files, man pages, or other documentation), "
+"the best solution is to put your text somewhere on the Internet, and ask on "
+"debian-i18n for a translation in different languages. Some translation team "
+"members are subscribed to this list, and they will take care of the "
+"translation and of the reviewing process. Once they are done, you will get "
+"your translated document from them in your mailbox."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: l10n.dbk:124
+msgid "How to get a given translation reviewed"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: l10n.dbk:126
+msgid ""
+"From time to time, individuals translate some texts in your package and will "
+"ask you for inclusion of the translation in the package. This can become "
+"problematic if you are not fluent in the given language. It is a good idea "
+"to send the document to the corresponding l10n mailing list, asking for a "
+"review. Once it has been done, you should feel more confident in the "
+"quality of the translation, and feel safe to include it in your package."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: l10n.dbk:136
+msgid "How to get a given translation updated"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: l10n.dbk:138
+msgid ""
+"If you have some translations of a given text lying around, each time you "
+"update the original, you should ask the previous translator to update the "
+"translation with your new changes. Keep in mind that this task takes time; "
+"at least one week to get the update reviewed and all."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: l10n.dbk:144
+msgid ""
+"If the translator is unresponsive, you may ask for help on the corresponding "
+"l10n mailing list. If everything fails, don't forget to put a warning in "
+"the translated document, stating that the translation is somehow outdated, "
+"and that the reader should refer to the original document if possible."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: l10n.dbk:150
+msgid ""
+"Avoid removing a translation completely because it is outdated. Old "
+"documentation is often better than no documentation at all for non-English "
+"speakers."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: l10n.dbk:157
+msgid "How to handle a bug report concerning a translation"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#. TODO: add the i18n tag to the bug?
+#: l10n.dbk:159
+msgid ""
+"The best solution may be to mark the bug as forwarded to upstream, and "
+"forward it to both the previous translator and his/her team (using the "
+"corresponding debian-l10n-XXX mailing list)."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: l10n.dbk:169
+msgid "I18N & L10N FAQ for translators"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: l10n.dbk:171
+msgid ""
+"While reading this, please keep in mind that there is no general procedure "
+"within Debian concerning these points, and that in any case, you should "
+"collaborate with your team and the package maintainer."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: l10n.dbk:176
+msgid "How to help the translation effort"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: l10n.dbk:178
+msgid ""
+"Choose what you want to translate, make sure that nobody is already working "
+"on it (using your debian-l10n-XXX mailing list), translate it, get it "
+"reviewed by other native speakers on your l10n mailing list, and provide it "
+"to the maintainer of the package (see next point)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: l10n.dbk:186
+msgid "How to provide a translation for inclusion in a package"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: l10n.dbk:188
+msgid ""
+"Make sure your translation is correct (asking for review on your l10n "
+"mailing list) before providing it for inclusion. It will save time for "
+"everyone, and avoid the chaos resulting in having several versions of the "
+"same document in bug reports."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: l10n.dbk:194
+msgid ""
+"The best solution is to file a regular bug containing the translation "
+"against the package. Make sure to use the 'PATCH' tag, and to not use a "
+"severity higher than 'wishlist', since the lack of translation never "
+"prevented a program from running."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: l10n.dbk:204
+msgid "Best current practice concerning l10n"
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: l10n.dbk:208
+msgid ""
+"As a maintainer, never edit the translations in any way (even to reformat "
+"the layout) without asking on the corresponding l10n mailing list. You risk "
+"for example breaksing the encoding of the file by doing so. Moreover, what "
+"you consider an error can be right (or even needed) in the given language."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: l10n.dbk:216
+msgid ""
+"As a translator, if you find an error in the original text, make sure to "
+"report it. Translators are often the most attentive readers of a given "
+"text, and if they don't report the errors they find, nobody will."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: l10n.dbk:223
+msgid ""
+"In any case, remember that the major issue with l10n is that it requires "
+"several people to cooperate, and that it is very easy to start a flamewar "
+"about small problems because of misunderstandings. So if you have problems "
+"with your interlocutor, ask for help on the corresponding l10n mailing list, "
+"on debian-i18n, or even on debian-devel (but beware, l10n discussions very "
+"often become flamewars on that list :)"
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: l10n.dbk:233
+msgid ""
+"In any case, cooperation can only be achieved with <emphasis role=\"strong"
+"\">mutual respect</emphasis>."
+msgstr ""
+
--- /dev/null
+# SOME DESCRIPTIVE TITLE
+# Copyright (C) 2007 Free Software Foundation, Inc.
+# <>, 2007.
+#
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: PACKAGE VERSION\n"
+"Report-Msgid-Bugs-To: \n"
+"POT-Creation-Date: 2007-07-01 21:16+0000\n"
+"PO-Revision-Date: 2007-07-01 23:07+0000\n"
+"Last-Translator: <>\n"
+"Language-Team: \n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit"
+
+# type: Content of: <chapter><title>
+#: new-maintainer.dbk:7
+msgid "Applying to Become a Maintainer"
+msgstr "Devenir responsable Debian"
+
+# type: Content of: <chapter><section><title>
+#: new-maintainer.dbk:9
+msgid "Getting started"
+msgstr "Pour commencer"
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:11
+msgid "So, you've read all the documentation, you've gone through the <ulink url=\"&url-newmaint-guide;\">Debian New Maintainers' Guide</ulink>, understand what everything in the <systemitem role=\"package\">hello</systemitem> example package is for, and you're about to Debianize your favorite piece of software. How do you actually become a Debian developer so that your work can be incorporated into the Project?"
+msgstr "Vous avez lu toute la documentation, vous avez examiné le <ulink url=\"&url-newmaint-guide;\">guide du nouveau responsable</ulink>, vous"
+"comprenez l'intérêt de tout ce qui se trouve dans le paquet d'exemple"
+"<systemitem role=\"package\">hello</systemitem> et vous vous apprêtez à mettre en paquet votre"
+"logiciel préféré. Comment devenir responsable Debian et intégrer votre"
+"travail au projet?"
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:19
+msgid "Firstly, subscribe to &email-debian-devel; if you haven't already. Send the word <literal>subscribe</literal> in the <emphasis>Subject</emphasis> of an email to &email-debian-devel-req;. In case of problems, contact the list administrator at &email-listmaster;. More information on available mailing lists can be found in <xref linkend=\"mailing-lists\"/> . &email-debian-devel-announce; is another list which is mandatory for anyone who wishes to follow Debian's development."
+msgstr "Si vous ne l'avez pas encore fait, commencez par vous inscrire à la"
+"liste &email-debian-devel;. Pour cela, envoyez un courrier à l'adresse"
+"&email-debian-devel-req; avec le mot <literal>subscribe</literal> dans la ligne"
+"<emphasis>Objet</emphasis><footnote><para><emphasis>Subject</emphasis> en anglais</para></footnote>"
+"de votre message. En cas de problème, contactez l'administrateur de la"
+"liste &email-listmaster;. Vous trouverez plus d'informations dans la"
+"section <xref linkend=\"mailing-lists\"/>. &email-debian-devel-announce; est une"
+"autre liste incontournable pour qui veut suivre les développements de"
+"Debian."
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:29
+msgid "You should subscribe and lurk (that is, read without posting) for a bit before doing any coding, and you should post about your intentions to work on something to avoid duplicated effort."
+msgstr "Vous suivrez les discussions de cette liste (sans poster) pendant"
+"quelque temps avant de coder quoi que ce soit et vous informerez la"
+"liste de votre intention de travailler sur quelque chose pour éviter de"
+"dupliquer le travail d'un autre."
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:34
+msgid "Another good list to subscribe to is &email-debian-mentors;. See <xref linkend=\"mentors\"/> for details. The IRC channel <literal>#debian</literal> can also be helpful; see <xref linkend=\"irc-channels\"/> ."
+msgstr "Une autre liste intéressante est &email-debian-mentors;. Voir la"
+"section <xref linkend=\"mentors\"/> pour les détails. Le canal IRC"
+"<literal>#debian</literal> pourra aussi être utile ; voir <xref linkend=\"irc-channels\"/>."
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:40
+msgid "When you know how you want to contribute to &debian-formal;, you should get in contact with existing Debian maintainers who are working on similar tasks. That way, you can learn from experienced developers. For example, if you are interested in packaging existing software for Debian, you should try to get a sponsor. A sponsor will work together with you on your package and upload it to the Debian archive once they are happy with the packaging work you have done. You can find a sponsor by mailing the &email-debian-mentors; mailing list, describing your package and yourself and asking for a sponsor (see <xref linkend=\"sponsoring\"/> and <ulink url=\"&url-mentors;\"></ulink> for more information on sponsoring). On the other hand, if you are interested in porting Debian to alternative architectures or kernels you can subscribe to port specific mailing lists and ask there how to get started. Finally, if you are interested in documentation or Quality Assurance (QA) work you can join maintainers already working on these tasks and submit patches and improvements."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:57
+msgid "One pitfall could be a too-generic local part in your mailadress: Terms like mail, admin, root, master should be avoided, please see <ulink url=\"&url-debian-lists;\"></ulink> for details."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: new-maintainer.dbk:64
+msgid "Debian mentors and sponsors"
+msgstr "Mentors et parrains Debian"
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:66
+msgid "The mailing list &email-debian-mentors; has been set up for novice maintainers who seek help with initial packaging and other developer-related issues. Every new developer is invited to subscribe to that list (see <xref linkend=\"mailing-lists\"/> for details)."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:72
+msgid "Those who prefer one-on-one help (e.g., via private email) should also post to that list and an experienced developer will volunteer to help."
+msgstr ""
+
+#
+#
+#
+#
+# type: Content of: <chapter><section><para>
+#. FIXME - out of order
+#. Those who are seeking a
+#. sponsor can request one at <ulink url="http://www.internatif.org/bortzmeyer/debian/sponsor/"></ulink>.
+#: new-maintainer.dbk:76
+msgid "In addition, if you have some packages ready for inclusion in Debian, but are waiting for your new maintainer application to go through, you might be able find a sponsor to upload your package for you. Sponsors are people who are official Debian Developers, and who are willing to criticize and upload your packages for you. Please read the unofficial debian-mentors FAQ at <ulink url=\"&url-mentors;\"></ulink> first."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:89
+msgid "If you wish to be a mentor and/or sponsor, more information is available in <xref linkend=\"newmaint\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: new-maintainer.dbk:95
+msgid "Registering as a Debian developer"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:97
+msgid "Before you decide to register with &debian-formal;, you will need to read all the information available at the <ulink url=\"&url-newmaint;\">New Maintainer's Corner</ulink>. It describes in detail the preparations you have to do before you can register to become a Debian developer. For example, before you apply, you have to read the <ulink url=\"&url-social-contract;\">Debian Social Contract</ulink>. Registering as a developer means that you agree with and pledge to uphold the Debian Social Contract; it is very important that maintainers are in accord with the essential ideas behind &debian-formal;. Reading the <ulink url=\"&url-gnu-manifesto;\">GNU Manifesto</ulink> would also be a good idea."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:111
+msgid "The process of registering as a developer is a process of verifying your identity and intentions, and checking your technical skills. As the number of people working on &debian-formal; has grown to over &number-of-maintainers; and our systems are used in several very important places, we have to be careful about being compromised. Therefore, we need to verify new maintainers before we can give them accounts on our servers and let them upload packages."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:120
+msgid "Before you actually register you should have shown that you can do competent work and will be a good contributor. You show this by submitting patches through the Bug Tracking System and having a package sponsored by an existing Debian Developer for a while. Also, we expect that contributors are interested in the whole project and not just in maintaining their own packages. If you can help other maintainers by providing further information on a bug or even a patch, then do so!"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:129
+msgid "Registration requires that you are familiar with Debian's philosophy and technical documentation. Furthermore, you need a GnuPG key which has been signed by an existing Debian maintainer. If your GnuPG key is not signed yet, you should try to meet a Debian Developer in person to get your key signed. There's a <ulink url=\"&url-gpg-coord;\">GnuPG Key Signing Coordination page</ulink> which should help you find a Debian Developer close to you. (If there is no Debian Developer close to you, alternative ways to pass the ID check may be permitted as an absolute exception on a case-by-case-basis. See the <ulink url=\"&url-newmaint-id;\">identification page</ulink> for more information.)"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:142
+msgid "If you do not have an OpenPGP key yet, generate one. Every developer needs an OpenPGP key in order to sign and verify package uploads. You should read the manual for the software you are using, since it has much important information which is critical to its security. Many more security failures are due to human error than to software failure or high-powered spy techniques. See <xref linkend=\"key-maint\"/> for more information on maintaining your public key."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:150
+msgid "Debian uses the <command>GNU Privacy Guard</command> (package <systemitem role=\"package\">gnupg</systemitem> version 1 or better) as its baseline standard. You can use some other implementation of OpenPGP as well. Note that OpenPGP is an open standard based on <ulink url=\"&url-rfc2440;\">RFC 2440</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><para><footnote>
+#: new-maintainer.dbk:157
+msgid "You need a version 4 key for use in Debian Development. Your key length must be at least 1024 bits; there is no reason to use a smaller key, and doing so would be much less secure. <footnote>"
+msgstr ""
+
+# type: Content of: <chapter><section><para><footnote><para>
+#: new-maintainer.dbk:159
+msgid "Version 4 keys are keys conforming to the OpenPGP standard as defined in RFC 2440. Version 4 is the key type that has always been created when using GnuPG. PGP versions since 5.x also could create v4 keys, the other choice having beein pgp 2.6.x compatible v3 keys (also called legacy RSA by PGP)."
+msgstr ""
+
+# type: Content of: <chapter><section><para><footnote><para>
+#: new-maintainer.dbk:163
+msgid "Version 4 (primary) keys can either use the RSA or the DSA algorithms, so this has nothing to do with GnuPG's question about which kind of key do you want: (1) DSA and Elgamal, (2) DSA (sign only), (5) RSA (sign only). If you don't have any special requirements just pick the default."
+msgstr ""
+
+# type: Content of: <chapter><section><para><footnote><para>
+#: new-maintainer.dbk:167
+msgid "The easiest way to tell whether an existing key is a v4 key or a v3 (or v2) key is to look at the fingerprint: Fingerprints of version 4 keys are the SHA-1 hash of some key material, so they are 40 hex digits, usually grouped in blocks of 4. Fingerprints of older key format versions used MD5 and are generally shown in blocks of 2 hex digits. For example if your fingerprint looks like <literal>5B00 C96D 5D54 AEE1 206B AF84 DE7A AF6E 94C0 9C7F</literal> then it's a v4 key."
+msgstr ""
+
+# type: Content of: <chapter><section><para><footnote><para>
+#: new-maintainer.dbk:174
+msgid "Another possibility is to pipe the key into <command>pgpdump</command>, which will say something like Public Key Packet - Ver 4."
+msgstr ""
+
+# type: Content of: <chapter><section><para><footnote><para>
+#: new-maintainer.dbk:176
+msgid "Also note that your key must be self-signed (i.e. it has to sign all its own user IDs; this prevents user ID tampering). All modern OpenPGP software does that automatically, but if you have an older key you may have to manually add those signatures."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:182
+msgid "If your public key isn't on a public key server such as &pgp-keyserv;, please read the documentation available at <ulink url=\"&url-newmaint-id;\">NM Step 2: Identification</ulink>. That document contains instructions on how to put your key on the public key servers. The New Maintainer Group will put your public key on the servers if it isn't already there."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:190
+msgid "Some countries restrict the use of cryptographic software by their citizens. This need not impede one's activities as a Debian package maintainer however, as it may be perfectly legal to use cryptographic products for authentication, rather than encryption purposes. If you live in a country where use of cryptography even for authentication is forbidden then please contact us so we can make special arrangements."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:198
+msgid "To apply as a new maintainer, you need an existing Debian Developer to support your application (an <emphasis>advocate</emphasis>). After you have contributed to Debian for a while, and you want to apply to become a registered developer, an existing developer with whom you have worked over the past months has to express their belief that you can contribute to Debian successfully."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:205
+msgid "When you have found an advocate, have your GnuPG key signed and have already contributed to Debian for a while, you're ready to apply. You can simply register on our <ulink url=\"&url-newmaint-apply;\">application page</ulink>. After you have signed up, your advocate has to confirm your application. When your advocate has completed this step you will be assigned an Application Manager who will go with you through the necessary steps of the New Maintainer process. You can always check your status on the <ulink url=\"&url-newmaint-db;\">applications status board</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:215
+msgid "For more details, please consult <ulink url=\"&url-newmaint;\">New Maintainer's Corner</ulink> at the Debian web site. Make sure that you are familiar with the necessary steps of the New Maintainer process before actually applying. If you are well prepared, you can save a lot of time later on."
+msgstr ""
+
--- /dev/null
+# SOME DESCRIPTIVE TITLE
+# Copyright (C) 2007 Free Software Foundation, Inc.
+# <>, 2007.
+# , fuzzy
+#
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: PACKAGE VERSION\n"
+"Report-Msgid-Bugs-To: \n"
+"POT-Creation-Date: 2007-07-01 21:16+0000\n"
+"PO-Revision-Date: 2007-07-01 23:15+0000\n"
+"Last-Translator: <>\n"
+"Language-Team: \n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: "
+
+# type: Content of: <chapter><title>
+#: pkgs.dbk:7
+msgid "Managing Packages"
+msgstr "Gestion des paquets"
+
+# type: Content of: <chapter><para>
+#: pkgs.dbk:9
+msgid ""
+"This chapter contains information related to creating, uploading, "
+"maintaining, and porting packages."
+msgstr "Ce chapitre contient des informations relatives à la création, l'envoi,"
+"la maintenance et le portage des paquets."
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:13
+msgid "New packages"
+msgstr "Nouveaux paquets"
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:15
+msgid ""
+"If you want to create a new package for the Debian distribution, you should "
+"first check the <ulink url=\"&url-wnpp;\">Work-Needing and Prospective "
+"Packages (WNPP)</ulink> list. Checking the WNPP list ensures that no one is "
+"already working on packaging that software, and that effort is not "
+"duplicated. Read the <ulink url=\"&url-wnpp;\">WNPP web pages</ulink> for "
+"more information."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:23
+msgid ""
+"Assuming no one else is already working on your prospective package, you "
+"must then submit a bug report (<xref linkend=\"submit-bug\"/> ) against the "
+"pseudo-package <systemitem role=\"package\">wnpp</systemitem> describing "
+"your plan to create a new package, including, but not limiting yourself to, "
+"a description of the package, the license of the prospective package, and "
+"the current URL where it can be downloaded from."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:31
+msgid ""
+"You should set the subject of the bug to ``ITP: <replaceable>foo</"
+"replaceable> -- <replaceable>short description</replaceable>'', substituting "
+"the name of the new package for <replaceable>foo</replaceable>. The "
+"severity of the bug report must be set to <emphasis>wishlist</emphasis>. If "
+"you feel it's necessary, send a copy to &email-debian-devel; by putting the "
+"address in the <literal>X-Debbugs-CC:</literal> header of the message (no, "
+"don't use <literal>CC:</literal>, because that way the message's subject "
+"won't indicate the bug number)."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:41
+msgid ""
+"Please include a <literal>Closes: bug#<replaceable>nnnnn</replaceable></"
+"literal> entry in the changelog of the new package in order for the bug "
+"report to be automatically closed once the new package is installed in the "
+"archive (see <xref linkend=\"upload-bugfix\"/> )."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:47
+msgid ""
+"When closing security bugs include CVE numbers as well as the Closes: "
+"#nnnnn. This is useful for the security team to track vulnerabilities. If "
+"an upload is made to fix the bug before the advisory ID is known, it is "
+"encouraged to modify the historical changelog entry with the next upload. "
+"Even in this case, please include all available pointers to background "
+"information in the original changelog entry."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:55
+msgid ""
+"There are a number of reasons why we ask maintainers to announce their "
+"intentions:"
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:61
+msgid ""
+"It helps the (potentially new) maintainer to tap into the experience of "
+"people on the list, and lets them know if anyone else is working on it "
+"already."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:67
+msgid ""
+"It lets other people thinking about working on the package know that there "
+"already is a volunteer, so efforts may be shared."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:73
+msgid ""
+"It lets the rest of the maintainers know more about the package than the one "
+"line description and the usual changelog entry ``Initial release'' that gets "
+"posted to <literal>debian-devel-changes</literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:80
+msgid ""
+"It is helpful to the people who live off unstable (and form our first line "
+"of testers). We should encourage these people."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:86
+msgid ""
+"The announcements give maintainers and other interested parties a better "
+"feel of what is going on, and what is new, in the project."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:92
+msgid ""
+"Please see <ulink url=\"http://&ftp-master-host;/REJECT-FAQ.html\"></ulink> "
+"for common rejection reasons for a new package."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:98
+msgid "Recording changes in the package"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:100
+msgid ""
+"Changes that you make to the package need to be recorded in the "
+"<filename>debian/changelog</filename>. These changes should provide a "
+"concise description of what was changed, why (if it's in doubt), and note if "
+"any bugs were closed. They also record when the package was completed. "
+"This file will be installed in <filename>/usr/share/doc/"
+"<replaceable>package</replaceable>/changelog.Debian.gz</filename>, or "
+"<filename>/usr/share/doc/<replaceable>package</replaceable>/changelog.gz</"
+"filename> for native packages."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:111
+msgid ""
+"The <filename>debian/changelog</filename> file conforms to a certain "
+"structure, with a number of different fields. One field of note, the "
+"<emphasis>distribution</emphasis>, is described in <xref linkend="
+"\"distribution\"/> . More information about the structure of this file can "
+"be found in the Debian Policy section titled <filename>debian/changelog</"
+"filename>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:119
+msgid ""
+"Changelog entries can be used to automatically close Debian bugs when the "
+"package is installed into the archive. See <xref linkend=\"upload-bugfix\"/"
+"> ."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:123
+msgid ""
+"It is conventional that the changelog entry of a package that contains a new "
+"upstream version of the software looks like this:"
+msgstr ""
+
+# type: Content of: <chapter><section><screen>
+#: pkgs.dbk:127
+#, no-wrap
+msgid "* new upstream version"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:130
+msgid ""
+"There are tools to help you create entries and finalize the "
+"<filename>changelog</filename> for release — see <xref linkend=\"devscripts"
+"\"/> and <xref linkend=\"dpkg-dev-el\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:135
+msgid "See also <xref linkend=\"bpp-debian-changelog\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:140
+msgid "Testing the package"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:142
+msgid ""
+"Before you upload your package, you should do basic testing on it. At a "
+"minimum, you should try the following activities (you'll need to have an "
+"older version of the same Debian package around):"
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:149
+msgid ""
+"Install the package and make sure the software works, or upgrade the package "
+"from an older version to your new version if a Debian package for it already "
+"exists."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:156
+msgid ""
+"Run <command>lintian</command> over the package. You can run "
+"<command>lintian</command> as follows: <literal>lintian -v "
+"<replaceable>package-version</replaceable>.changes</literal>. This will "
+"check the source package as well as the binary package. If you don't "
+"understand the output that <command>lintian</command> generates, try adding "
+"the <literal>-i</literal> switch, which will cause <command>lintian</"
+"command> to output a very verbose description of the problem."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:165
+msgid ""
+"Normally, a package should <emphasis>not</emphasis> be uploaded if it causes "
+"lintian to emit errors (they will start with <literal>E</literal>)."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:169
+msgid ""
+"For more information on <command>lintian</command>, see <xref linkend="
+"\"lintian\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:175
+msgid ""
+"Optionally run <xref linkend=\"debdiff\"/> to analyze changes from an older "
+"version, if one exists."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:181
+msgid ""
+"Downgrade the package to the previous version (if one exists) — this tests "
+"the <filename>postrm</filename> and <filename>prerm</filename> scripts."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:187
+msgid "Remove the package, then reinstall it."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:192
+msgid ""
+"Copy the source package in a different directory and try unpacking it and "
+"rebuilding it. This tests if the package relies on existing files outside "
+"of it, or if it relies on permissions being preserved on the files shipped "
+"inside the .diff.gz file."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:202
+msgid "Layout of the source package"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:204
+msgid "There are two types of Debian source packages:"
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:209
+msgid ""
+"the so-called <emphasis>native</emphasis> packages, where there is no "
+"distinction between the original sources and the patches applied for Debian"
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:215
+msgid ""
+"the (more common) packages where there's an original source tarball file "
+"accompanied by another file that contains the patches applied for Debian"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:221
+msgid ""
+"For the native packages, the source package includes a Debian source control "
+"file (<literal>.dsc</literal>) and the source tarball (<literal>.tar.gz</"
+"literal>). A source package of a non-native package includes a Debian "
+"source control file, the original source tarball (<literal>.orig.tar.gz</"
+"literal>) and the Debian patches (<literal>.diff.gz</literal>)."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:229
+msgid ""
+"Whether a package is native or not is determined when it is built by "
+"<citerefentry> <refentrytitle>dpkg-buildpackage</refentrytitle> "
+"<manvolnum>1</manvolnum> </citerefentry>. The rest of this section relates "
+"only to non-native packages."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:235
+msgid ""
+"The first time a version is uploaded which corresponds to a particular "
+"upstream version, the original source tar file should be uploaded and "
+"included in the <filename>.changes</filename> file. Subsequently, this very "
+"same tar file should be used to build the new diffs and <filename>.dsc</"
+"filename> files, and will not need to be re-uploaded."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:242
+msgid ""
+"By default, <command>dpkg-genchanges</command> and <command>dpkg-"
+"buildpackage</command> will include the original source tar file if and only "
+"if the Debian revision part of the source version number is 0 or 1, "
+"indicating a new upstream version. This behavior may be modified by using "
+"<literal>-sa</literal> to always include it or <literal>-sd</literal> to "
+"always leave it out."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:250
+msgid ""
+"If no original source is included in the upload, the original source tar-"
+"file used by <command>dpkg-source</command> when constructing the <filename>."
+"dsc</filename> file and diff to be uploaded <emphasis>must</emphasis> be "
+"byte-for-byte identical with the one already in the archive."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:257
+msgid ""
+"Please notice that, in non-native packages, permissions on files that are "
+"not present in the .orig.tar.gz will not be preserved, as diff does not "
+"store file permissions in the patch."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:264
+msgid "Picking a distribution"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:266
+msgid ""
+"Each upload needs to specify which distribution the package is intended "
+"for. The package build process extracts this information from the first "
+"line of the <filename>debian/changelog</filename> file and places it in the "
+"<literal>Distribution</literal> field of the <literal>.changes</literal> "
+"file."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:272
+msgid ""
+"There are several possible values for this field: `stable', `unstable', "
+"`testing-proposed-updates' and `experimental'. Normally, packages are "
+"uploaded into <emphasis>unstable</emphasis>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:277
+msgid ""
+"Actually, there are two other possible distributions: `stable-security' and "
+"`testing-security', but read <xref linkend=\"bug-security\"/> for more "
+"information on those."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:282
+msgid ""
+"It is not possible to upload a package into several distributions at the "
+"same time."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:286
+msgid "Special case: uploads to the <emphasis>stable</emphasis> distribution"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:288
+msgid ""
+"Uploading to <emphasis>stable</emphasis> means that the package will "
+"transfered to the <emphasis>p-u-new</emphasis>-queue for review by the "
+"stable release managers, and if approved will be installed in "
+"<filename>stable-proposed-updates</filename> directory of the Debian "
+"archive. From there, it will be included in <emphasis>stable</emphasis> "
+"with the next point release."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:296
+msgid ""
+"Extra care should be taken when uploading to <emphasis>stable</emphasis>. "
+"Basically, a package should only be uploaded to stable if one of the "
+"following happens:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:303
+msgid "a truly critical functionality problem"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:308
+msgid "the package becomes uninstallable"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:313
+msgid "a released architecture lacks the package"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:318
+msgid ""
+"In the past, uploads to <emphasis>stable</emphasis> were used to address "
+"security problems as well. However, this practice is deprecated, as uploads "
+"used for Debian security advisories are automatically copied to the "
+"appropriate <filename>proposed-updates</filename> archive when the advisory "
+"is released. See <xref linkend=\"bug-security\"/> for detailed information "
+"on handling security problems."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:326
+msgid ""
+"Changing anything else in the package that isn't important is discouraged, "
+"because even trivial fixes can cause bugs later on."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:330
+msgid ""
+"Packages uploaded to <emphasis>stable</emphasis> need to be compiled on "
+"systems running <emphasis>stable</emphasis>, so that their dependencies are "
+"limited to the libraries (and other packages) available in <emphasis>stable</"
+"emphasis>; for example, a package uploaded to <emphasis>stable</emphasis> "
+"that depends on a library package that only exists in unstable will be "
+"rejected. Making changes to dependencies of other packages (by messing with "
+"<literal>Provides</literal> or shlibs files), possibly making those other "
+"packages uninstallable, is strongly discouraged."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:340
+msgid ""
+"The Release Team (which can be reached at &email-debian-release;) will "
+"regularly evaluate the uploads To <emphasis>stable-proposed-updates</"
+"emphasis> and decide if your package can be included in <emphasis>stable</"
+"emphasis>. Please be clear (and verbose, if necessary) in your changelog "
+"entries for uploads to <emphasis>stable</emphasis>, because otherwise the "
+"package won't be considered for inclusion."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:349
+msgid ""
+"It's best practice to speak with the stable release manager "
+"<emphasis>before</emphasis> uploading to <emphasis>stable</emphasis>/"
+"<emphasis>stable-proposed-updates</emphasis>, so that the uploaded package "
+"fits the needs of the next point release."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:357
+msgid ""
+"Special case: uploads to <emphasis>testing/testing-proposed-updates</"
+"emphasis>"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:359
+msgid ""
+"Please see the information in the <link linkend=\"t-p-u\">testing section</"
+"link> for details."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:367
+msgid "Uploading a package"
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:369
+msgid "Uploading to <literal>ftp-master</literal>"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:371
+msgid ""
+"To upload a package, you should upload the files (including the signed "
+"changes and dsc-file) with anonymous ftp to <literal>&ftp-master-host;</"
+"literal> in the directory <ulink url=\"ftp://&ftp-master-host;&upload-queue;"
+"\">&upload-queue;</ulink>. To get the files processed there, they need to "
+"be signed with a key in the debian keyring."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:379
+msgid ""
+"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 all files have been uploaded."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:384
+msgid ""
+"You may also find the Debian packages <xref linkend=\"dupload\"/> or <xref "
+"linkend=\"dput\"/> useful when uploading packages. These handy programs "
+"help automate the process of uploading packages into Debian."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:389
+msgid ""
+"For removing packages, please see the README file in that ftp directory, and "
+"the Debian package <xref linkend=\"dcut\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:395
+msgid "Uploading to <literal>non-US</literal>"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:397
+msgid ""
+"<emphasis>Note:</emphasis> non-us was discontinued with the release of sarge."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:402
+msgid "Delayed uploads"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:404
+msgid ""
+"Delayed uploads are done for the moment via the delayed queue at gluck. The "
+"upload-directory is <literal>gluck:~tfheen/DELAYED/[012345678]-day</"
+"literal>. 0-day is uploaded multiple times per day to ftp-master."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:409
+msgid "With a fairly recent dput, this section"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: pkgs.dbk:412
+#, no-wrap
+msgid ""
+"[tfheen_delayed]\n"
+"method = scp\n"
+"fqdn = gluck.debian.org\n"
+"incoming = ~tfheen"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:418
+msgid "in ~/.dput.cf should work fine for uploading to the DELAYED queue."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:421
+msgid ""
+"<emphasis>Note:</emphasis> Since this upload queue goes to <literal>ftp-"
+"master</literal>, the prescription found in <xref linkend=\"upload-ftp-master"
+"\"/> applies here as well."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:428
+msgid "Security uploads"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:430
+msgid ""
+"Do <emphasis role=\"strong\">NOT</emphasis> 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. For details, please see section <xref linkend="
+"\"bug-security\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:440
+msgid "Other upload queues"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:442
+msgid ""
+"The scp queues on ftp-master, and security are mostly unusable due to the "
+"login restrictions on those hosts."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:446
+msgid ""
+"The anonymous queues on ftp.uni-erlangen.de and ftp.uk.debian.org are "
+"currently down. Work is underway to resurrect them."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:450
+msgid ""
+"The queues on master.debian.org, samosa.debian.org, master.debian.or.jp, and "
+"ftp.chiark.greenend.org.uk are down permanently, and will not be "
+"resurrected. The queue in Japan will be replaced with a new queue on hp."
+"debian.or.jp some day."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:456
+msgid ""
+"For the time being, the anonymous ftp queue on auric.debian.org (the former "
+"ftp-master) works, but it is deprecated and will be removed at some point in "
+"the future."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:463
+msgid "Notification that a new package has been installed"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:465
+msgid ""
+"The Debian archive maintainers are responsible for handling package "
+"uploads. For the most part, uploads are automatically handled on a daily "
+"basis by the archive maintenance tools, <command>katie</command>. "
+"Specifically, updates to existing packages to the `unstable' distribution "
+"are handled automatically. In other cases, notably new packages, placing "
+"the uploaded package into the distribution is handled manually. When "
+"uploads are handled manually, the change to the archive may take up to a "
+"month to occur. Please be patient."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:474
+msgid ""
+"In any case, you will receive an email notification indicating that the "
+"package has been added to the archive, which also indicates which bugs will "
+"be closed by the upload. Please examine this notification carefully, "
+"checking if any bugs you meant to close didn't get triggered."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:480
+msgid ""
+"The installation notification also includes information on what section the "
+"package was inserted into. If there is a disparity, you will receive a "
+"separate email notifying you of that. Read on below."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:485
+msgid ""
+"Note that if you upload via queues, the queue daemon software will also send "
+"you a notification by email."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:493
+msgid "Specifying the package section, subsection and priority"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:495
+msgid ""
+"The <filename>debian/control</filename> file's <literal>Section</literal> "
+"and <literal>Priority</literal> fields do not actually specify where the "
+"file will be placed in the archive, nor its priority. In order to retain "
+"the overall integrity of the archive, it is the archive maintainers who have "
+"control over these fields. The values in the <filename>debian/control</"
+"filename> file are actually just hints."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:503
+msgid ""
+"The archive maintainers keep track of the canonical sections and priorities "
+"for packages in the <emphasis>override file</emphasis>. If there is a "
+"disparity between the <emphasis>override file</emphasis> and the package's "
+"fields as indicated in <filename>debian/control</filename>, then you will "
+"receive an email noting the divergence when the package is installed into "
+"the archive. You can either correct your <filename>debian/control</"
+"filename> file for your next upload, or else you may wish to make a change "
+"in the <emphasis>override file</emphasis>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:513
+msgid ""
+"To alter the actual section that a package is put in, you need to first make "
+"sure that the <filename>debian/control</filename> file in your package is "
+"accurate. Next, send an email &email-override; or submit a bug against "
+"<systemitem role=\"package\">ftp.debian.org</systemitem> requesting that the "
+"section or priority for your package be changed from the old section or "
+"priority to the new one. Be sure to explain your reasoning."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:521
+msgid ""
+"For more information about <emphasis>override files</emphasis>, see "
+"<citerefentry> <refentrytitle>dpkg-scanpackages</refentrytitle> "
+"<manvolnum>1</manvolnum> </citerefentry> and <ulink url=\"&url-bts-devel;"
+"#maintincorrect\"></ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:527
+msgid ""
+"Note that the <literal>Section</literal> field describes both the section as "
+"well as the subsection, which are described in <xref linkend=\"archive-"
+"sections\"/> . If the section is main, it should be omitted. The list of "
+"allowable subsections can be found in <ulink url=\"&url-debian-policy;ch-"
+"archive.html#s-subsections\"></ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:536
+msgid "Handling bugs"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:538
+msgid ""
+"Every developer has to be able to work with the Debian <ulink url=\"&url-bts;"
+"\">bug tracking system</ulink>. This includes knowing how to file bug "
+"reports properly (see <xref linkend=\"submit-bug\"/> ), how to update them "
+"and reorder them, and how to process and close them."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:544
+msgid ""
+"The bug tracking system's features are described in the <ulink url=\"&url-"
+"bts-devel;\">BTS documentation for developers</ulink>. This includes "
+"closing bugs, sending followup messages, assigning severities and tags, "
+"marking bugs as forwarded, and other issues."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:550
+msgid ""
+"Operations such as reassigning bugs to other packages, merging separate bug "
+"reports about the same issue, or reopening bugs when they are prematurely "
+"closed, are handled using the so-called control mail server. All of the "
+"commands available on this server are described in the <ulink url=\"&url-bts-"
+"control;\">BTS control server documentation</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:558
+msgid "Monitoring bugs"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:560
+msgid ""
+"If you want to be a good maintainer, you should periodically check the "
+"<ulink url=\"&url-bts;\">Debian bug tracking system (BTS)</ulink> for your "
+"packages. The BTS contains all the open bugs against your packages. You "
+"can check them by browsing this page: <literal>http://&bugs-host;/"
+"<replaceable>yourlogin</replaceable>@debian.org</literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:567
+msgid ""
+"Maintainers interact with the BTS via email addresses at <literal>&bugs-host;"
+"</literal>. Documentation on available commands can be found at <ulink url="
+"\"&url-bts;\"></ulink>, or, if you have installed the <systemitem role="
+"\"package\">doc-debian</systemitem> package, you can look at the local files "
+"&file-bts-docs;."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:574
+msgid ""
+"Some find it useful to get periodic reports on open bugs. You can add a "
+"cron job such as the following if you want to get a weekly email outlining "
+"all the open bugs against your packages:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: pkgs.dbk:579
+#, no-wrap
+msgid ""
+"# ask for weekly reports of bugs in my packages\n"
+"&cron-bug-report;"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:583
+msgid ""
+"Replace <replaceable>address</replaceable> with your official Debian "
+"maintainer address."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:589
+msgid "Responding to bugs"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:591
+msgid ""
+"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., <email>123@&bugs-host;</email>). If you're writing a new mail and you "
+"don't remember the submitter email address, you can use the <email>123-"
+"submitter@&bugs-host;</email> email to contact the submitter <emphasis>and</"
+"emphasis> to record your mail within the bug log (that means you don't need "
+"to send a copy of the mail to <email>123@&bugs-host;</email>)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:600
+msgid ""
+"If you get a bug which mentions FTBFS, this means Fails to build from "
+"source. Porters frequently use this acronym."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:604
+msgid ""
+"Once you've dealt with a bug report (e.g. fixed it), mark it as "
+"<emphasis>done</emphasis> (close it) by sending an explanation message to "
+"<email>123-done@&bugs-host;</email>. If you're fixing a bug by changing and "
+"uploading the package, you can automate bug closing as described in <xref "
+"linkend=\"upload-bugfix\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:611
+msgid ""
+"You should <emphasis>never</emphasis> close bugs via the bug server "
+"<literal>close</literal> command sent to &email-bts-control;. If you do so, "
+"the original submitter will not receive any information about why the bug "
+"was closed."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:619
+msgid "Bug housekeeping"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:621
+msgid ""
+"As a package maintainer, you will often find bugs in other packages or have "
+"bugs reported against your packages which are actually bugs in other "
+"packages. The bug tracking system's features are described in the <ulink "
+"url=\"&url-bts-devel;\">BTS documentation for Debian developers</ulink>. "
+"Operations such as reassigning, merging, and tagging bug reports are "
+"described in the <ulink url=\"&url-bts-control;\">BTS control server "
+"documentation</ulink>. This section contains some guidelines for managing "
+"your own bugs, based on the collective Debian developer experience."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:632
+msgid ""
+"Filing bugs for problems that you find in other packages is one of the civic "
+"obligations of maintainership, see <xref linkend=\"submit-bug\"/> for "
+"details. However, handling the bugs in your own packages is even more "
+"important."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:637
+msgid "Here's a list of steps that you may follow to handle a bug report:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:642
+msgid ""
+"Decide whether the report corresponds to a real bug or not. Sometimes users "
+"are just calling a program in the wrong way because they haven't read the "
+"documentation. If you diagnose this, just close the bug with enough "
+"information to let the user correct their problem (give pointers to the good "
+"documentation and so on). If the same report comes up again and again you "
+"may ask yourself if the documentation is good enough or if the program "
+"shouldn't detect its misuse in order to give an informative error message. "
+"This is an issue that may need to be brought up with the upstream author."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:652
+msgid ""
+"If the bug submitter disagrees with your decision to close the bug, they may "
+"reopen it until you find an agreement on how to handle it. If you don't "
+"find any, you may want to tag the bug <literal>wontfix</literal> to let "
+"people know that the bug exists but that it won't be corrected. If this "
+"situation is unacceptable, you (or the submitter) may want to require a "
+"decision of the technical committee by reassigning the bug to <systemitem "
+"role=\"package\">tech-ctte</systemitem> (you may use the clone command of "
+"the BTS if you wish to keep it reported against your package). Before doing "
+"so, please read the <ulink url=\"&url-tech-ctte;\">recommended procedure</"
+"ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:666
+msgid ""
+"If the bug is real but it's caused by another package, just reassign the bug "
+"to the right package. If you don't know which package it should be "
+"reassigned to, you should ask for help on <link linkend=\"irc-channels"
+"\">IRC</link> or on &email-debian-devel;. Please make sure that the "
+"maintainer(s) of the package the bug is reassigned to know why you "
+"reassigned it."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:674
+msgid ""
+"Sometimes you also have to adjust the severity of the bug so that it matches "
+"our definition of the severity. That's because people tend to inflate the "
+"severity of bugs to make sure their bugs are fixed quickly. Some bugs may "
+"even be dropped to wishlist severity when the requested change is just "
+"cosmetic."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:682
+msgid ""
+"If the bug is real but the same problem has already been reported by someone "
+"else, then the two relevant bug reports should be merged into one using the "
+"merge command of the BTS. In this way, when the bug is fixed, all of the "
+"submitters will be informed of this. (Note, however, that emails sent to "
+"one bug report's submitter won't automatically be sent to the other report's "
+"submitter.) For more details on the technicalities of the merge command and "
+"its relative, the unmerge command, see the BTS control server documentation."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:693
+msgid ""
+"The bug submitter may have forgotten to provide some information, in which "
+"case you have to ask them for the required information. You may use the "
+"<literal>moreinfo</literal> tag to mark the bug as such. Moreover if you "
+"can't reproduce the bug, you tag it <literal>unreproducible</literal>. "
+"Anyone who can reproduce the bug is then invited to provide more information "
+"on how to reproduce it. After a few months, if this information has not "
+"been sent by someone, the bug may be closed."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:704
+msgid ""
+"If the bug is related to the packaging, you just fix it. If you are not "
+"able to fix it yourself, then tag the bug as <literal>help</literal>. You "
+"can also ask for help on &email-debian-devel; or &email-debian-qa;. If it's "
+"an upstream problem, you have to forward it to the upstream author. "
+"Forwarding a bug is not enough, you have to check at each release if the bug "
+"has been fixed or not. If it has, you just close it, otherwise you have to "
+"remind the author about it. If you have the required skills you can prepare "
+"a patch that fixes the bug and send it to the author at the same time. Make "
+"sure to send the patch to the BTS and to tag the bug as <literal>patch</"
+"literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:718
+msgid ""
+"If you have fixed a bug in your local copy, or if a fix has been committed "
+"to the CVS repository, you may tag the bug as <literal>pending</literal> to "
+"let people know that the bug is corrected and that it will be closed with "
+"the next upload (add the <literal>closes:</literal> in the "
+"<filename>changelog</filename>). This is particularly useful if you are "
+"several developers working on the same package."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:728
+msgid ""
+"Once a corrected package is available in the <emphasis>unstable</emphasis> "
+"distribution, you can close the bug. This can be done automatically, read "
+"<xref linkend=\"upload-bugfix\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:737
+msgid "When bugs are closed by new uploads"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:739
+msgid ""
+"As bugs and problems are fixed in your packages, it is your responsibility "
+"as the package maintainer to close these bugs. However, you should not "
+"close a bug until the package which fixes the bug has been accepted into the "
+"Debian archive. Therefore, once you get notification that your updated "
+"package has been installed into the archive, you can and should close the "
+"bug in the BTS. Also, the bug should be closed with the correct version."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:747
+msgid ""
+"However, it's possible to avoid having to manually close bugs after the "
+"upload — just list the fixed bugs in your <filename>debian/changelog</"
+"filename> file, following a certain syntax, and the archive maintenance "
+"software will close the bugs for you. For example:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: pkgs.dbk:753
+#, no-wrap
+msgid ""
+"acme-cannon (3.1415) unstable; urgency=low\n"
+"\n"
+" * Frobbed with options (closes: Bug#98339)\n"
+" * Added safety to prevent operator dismemberment, closes: bug#98765,\n"
+" bug#98713, #98714.\n"
+" * Added man page. Closes: #98725."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:761
+msgid ""
+"Technically speaking, the following Perl regular expression describes how "
+"bug closing changelogs are identified:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: pkgs.dbk:765
+#, no-wrap
+msgid "/closes:\\s*(?:bug)?\\#\\s*\\d+(?:,\\s*(?:bug)?\\#\\s*\\d+)*/ig"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:768
+msgid ""
+"We prefer the <literal>closes: #<replaceable>XXX</replaceable></literal> "
+"syntax, as it is the most concise entry and the easiest to integrate with "
+"the text of the <filename>changelog</filename>. Unless specified different "
+"by the <replaceable>-v</replaceable>-switch to <command>dpkg-buildpackage</"
+"command>, only the bugs closed in the most recent changelog entry are closed "
+"(basically, exactly the bugs mentioned in the changelog-part in the "
+"<filename>.changes</filename> file are closed)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:777
+msgid ""
+"Historically, uploads identified as <link linkend=\"nmu\">Non-maintainer "
+"upload (NMU)</link> were tagged <literal>fixed</literal> instead of being "
+"closed, but that practice was ceased with the advent of version-tracking. "
+"The same applied to the tag <literal>fixed-in-experimental</literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:783
+msgid ""
+"If you happen to mistype a bug number or forget a bug in the changelog "
+"entries, don't hesitate to undo any damage the error caused. To reopen "
+"wrongly closed bugs, send a <literal>reopen <replaceable>XXX</replaceable></"
+"literal> command to the bug tracking system's control address, &email-bts-"
+"control;. To close any remaining bugs that were fixed by your upload, email "
+"the <filename>.changes</filename> file to <email>XXX-done@&bugs-host;</"
+"email>, where <replaceable>XXX</replaceable> is the bug number, and put "
+"Version: YYY and an empty line as the first two lines of the body of the "
+"email, where <replaceable>YYY</replaceable> is the first version where the "
+"bug has been fixed."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:795
+msgid ""
+"Bear in mind that it is not obligatory to close bugs using the changelog as "
+"described above. If you simply want to close bugs that don't have anything "
+"to do with an upload you made, do it by emailing an explanation to "
+"<email>XXX-done@&bugs-host;</email>. Do <emphasis role=\"strong\">not</"
+"emphasis> close bugs in the changelog entry of a version if the changes in "
+"that version of the package don't have any bearing on the bug."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:803
+msgid ""
+"For general information on how to write your changelog entries, see <xref "
+"linkend=\"bpp-debian-changelog\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:809
+msgid "Handling security-related bugs"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:811
+msgid ""
+"Due to their sensitive nature, security-related bugs must be handled "
+"carefully. The Debian Security Team exists to coordinate this activity, "
+"keeping track of outstanding security problems, helping maintainers with "
+"security problems or fixing them themselves, sending security advisories, "
+"and maintaining security.debian.org."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:820
+msgid ""
+"When you become aware of a security-related bug in a Debian package, whether "
+"or not you are the maintainer, collect pertinent information about the "
+"problem, and promptly contact the security team at &email-security-team; as "
+"soon as possible. <emphasis role=\"strong\">DO NOT UPLOAD</emphasis> any "
+"packages for stable; the security team will do that. Useful information "
+"includes, for example:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:830
+msgid ""
+"Which versions of the package are known to be affected by the bug. Check "
+"each version that is present in a supported Debian release, as well as "
+"testing and unstable."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:837
+msgid ""
+"The nature of the fix, if any is available (patches are especially helpful)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:842
+msgid ""
+"Any fixed packages that you have prepared yourself (send only the <literal>."
+"diff.gz</literal> and <literal>.dsc</literal> files and read <xref linkend="
+"\"bug-security-building\"/> first)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:849
+msgid ""
+"Any assistance you can provide to help with testing (exploits, regression "
+"testing, etc.)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:855
+msgid ""
+"Any information needed for the advisory (see <xref linkend=\"bug-security-"
+"advisories\"/> )"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:861
+msgid "Confidentiality"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:863
+msgid ""
+"Unlike most other activities within Debian, information about security "
+"issues must sometimes be kept private for a time. This allows software "
+"distributors to coordinate their disclosure in order to minimize their "
+"users' exposure. Whether this is the case depends on the nature of the "
+"problem and corresponding fix, and whether it is already a matter of public "
+"knowledge."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:870
+msgid "There are several ways developers can learn of a security problem:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:875
+msgid "they notice it on a public forum (mailing list, web site, etc.)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:880
+msgid "someone files a bug report"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:885
+msgid "someone informs them via private email"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:890
+msgid ""
+"In the first two cases, the information is public and it is important to "
+"have a fix as soon as possible. In the last case, however, it might not be "
+"public information. In that case there are a few possible options for "
+"dealing with the problem:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:898
+msgid ""
+"If the security exposure is minor, there is sometimes no need to keep the "
+"problem a secret and a fix should be made and released."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:904
+msgid ""
+"If the problem is severe, it is preferable to share the information with "
+"other vendors and coordinate a release. The security team keeps in contact "
+"with the various organizations and individuals and can take care of that."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:911
+msgid ""
+"In all cases if the person who reports the problem asks that it not be "
+"disclosed, such requests should be honored, with the obvious exception of "
+"informing the security team in order that a fix may be produced for a stable "
+"release of Debian. When sending confidential information to the security "
+"team, be sure to mention this fact."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:918
+msgid ""
+"Please note that if secrecy is needed you may not upload a fix to unstable "
+"(or anywhere else, such as a public CVS repository). It is not sufficient "
+"to obfuscate the details of the change, as the code itself is public, and "
+"can (and will) be examined by the general public."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:924
+msgid ""
+"There are two reasons for releasing information even though secrecy is "
+"requested: the problem has been known for a while, or the problem or exploit "
+"has become public."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:931
+msgid "Security Advisories"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:933
+msgid ""
+"Security advisories are only issued for the current, released stable "
+"distribution, and <emphasis>not</emphasis> for testing or unstable. When "
+"released, advisories are sent to the &email-debian-security-announce; "
+"mailing list and posted on <ulink url=\"&url-debian-security-advisories;"
+"\">the security web page</ulink>. Security advisories are written and "
+"posted by the security team. However they certainly do not mind if a "
+"maintainer can supply some of the information for them, or write part of the "
+"text. Information that should be in an advisory includes:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:946
+msgid "A description of the problem and its scope, including:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para>
+#: pkgs.dbk:951
+msgid "The type of problem (privilege escalation, denial of service, etc.)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para>
+#: pkgs.dbk:956
+msgid "What privileges may be gained, and by whom (if any)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para>
+#: pkgs.dbk:961
+msgid "How it can be exploited"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para>
+#: pkgs.dbk:966
+msgid "Whether it is remotely or locally exploitable"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para>
+#: pkgs.dbk:971
+msgid "How the problem was fixed"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:976
+msgid "This information allows users to assess the threat to their systems."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:981
+msgid "Version numbers of affected packages"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:986
+msgid "Version numbers of fixed packages"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:991
+msgid ""
+"Information on where to obtain the updated packages (usually from the Debian "
+"security archive)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:997
+msgid ""
+"References to upstream advisories, <ulink url=\"http://cve.mitre.org\">CVE</"
+"ulink> identifiers, and any other information useful in cross-referencing "
+"the vulnerability"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:1006
+msgid "Preparing packages to address security issues"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1008
+msgid ""
+"One way that you can assist the security team in their duties is to provide "
+"them with fixed packages suitable for a security advisory for the stable "
+"Debian release."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1013
+msgid ""
+"When an update is made to the stable release, care must be taken to avoid "
+"changing system behavior or introducing new bugs. In order to do this, make "
+"as few changes as possible to fix the bug. Users and administrators rely on "
+"the exact behavior of a release once it is made, so any change that is made "
+"might break someone's system. This is especially true of libraries: make "
+"sure you never change the API or ABI, no matter how small the change."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1021
+msgid ""
+"This means that moving to a new upstream version is not a good solution. "
+"Instead, the relevant changes should be back-ported to the version present "
+"in the current stable Debian release. Generally, upstream maintainers are "
+"willing to help if needed. If not, the Debian security team may be able to "
+"help."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1027
+msgid ""
+"In some cases, it is not possible to back-port a security fix, for example "
+"when large amounts of source code need to be modified or rewritten. If this "
+"happens, it may be necessary to move to a new upstream version. However, "
+"this is only done in extreme situations, and you must always coordinate that "
+"with the security team beforehand."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1034
+msgid ""
+"Related to this is another important guideline: always test your changes. "
+"If you have an exploit available, try it and see if it indeed succeeds on "
+"the unpatched package and fails on the fixed package. Test other, normal "
+"actions as well, as sometimes a security fix can break seemingly unrelated "
+"features in subtle ways."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1041
+msgid ""
+"Do <emphasis role=\"strong\">NOT</emphasis> include any changes in your "
+"package which are not directly related to fixing the vulnerability. These "
+"will only need to be reverted, and this wastes time. If there are other "
+"bugs in your package that you would like to fix, make an upload to proposed-"
+"updates in the usual way, after the security advisory is issued. The "
+"security update mechanism is not a means for introducing changes to your "
+"package which would otherwise be rejected from the stable release, so please "
+"do not attempt to do this."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1051
+msgid ""
+"Review and test your changes as much as possible. Check the differences "
+"from the previous version repeatedly (<command>interdiff</command> from the "
+"<systemitem role=\"package\">patchutils</systemitem> package and "
+"<command>debdiff</command> from <systemitem role=\"package\">devscripts</"
+"systemitem> are useful tools for this, see <xref linkend=\"debdiff\"/> )."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1059
+msgid "Be sure to verify the following items:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1064
+msgid ""
+"Target the right distribution in your <filename>debian/changelog</"
+"filename>. For stable this is <literal>stable-security</literal> and for "
+"testing this is <literal>testing-security</literal>, and for the previous "
+"stable release, this is <literal>oldstable-security</literal>. Do not "
+"target <replaceable>distribution</replaceable>-proposed-updates or "
+"<literal>stable</literal>!"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1074
+msgid "The upload should have urgency=high."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1079
+msgid ""
+"Make descriptive, meaningful changelog entries. Others will rely on them to "
+"determine whether a particular bug was fixed. 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."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1091
+msgid ""
+"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 <literal>dpkg --compare-versions</literal>. Be careful "
+"not to re-use a version number that you have already used for a previous "
+"upload. For <emphasis>testing</emphasis>, there must be a higher version in "
+"<emphasis>unstable</emphasis>. If there is none yet (for example, if "
+"<emphasis>testing</emphasis> and <emphasis>unstable</emphasis> have the same "
+"version) you must upload a new version to unstable first."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1103
+msgid ""
+"Do not make source-only uploads if your package has any binary-all packages "
+"(do not use the <literal>-S</literal> option to <command>dpkg-buildpackage</"
+"command>). The <command>buildd</command> infrastructure will not build "
+"those. This point applies to normal package uploads as well."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1112
+msgid ""
+"Unless the upstream source has been uploaded to security.debian.org before "
+"(by a previous security update), build the upload with full upstream source "
+"(<literal>dpkg-buildpackage -sa</literal>). If there has been a previous "
+"upload to security.debian.org with the same upstream version, you may upload "
+"without upstream source (<literal>dpkg-buildpackage -sd</literal>)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1121
+msgid ""
+"Be sure to use the exact same <filename>*.orig.tar.gz</filename> as used in "
+"the normal archive, otherwise it is not possible to move the security fix "
+"into the main archives later."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1128
+msgid ""
+"Build the package on a clean system which only has packages installed from "
+"the distribution you are building for. If you do not have such a system "
+"yourself, you can use a debian.org machine (see <xref linkend=\"server-"
+"machines\"/> ) or setup a chroot (see <xref linkend=\"pbuilder\"/> and <xref "
+"linkend=\"debootstrap\"/> )."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:1139
+msgid "Uploading the fixed package"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1141
+msgid ""
+"Do <emphasis role=\"strong\">NOT</emphasis> 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."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1148
+msgid ""
+"Do <emphasis role=\"strong\">NOT</emphasis> 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 is "
+"already installed into the archive, the security update will be rejected by "
+"the archive system. That way, the stable distribution will end up without a "
+"security update for this package instead."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1157
+msgid ""
+"Once you have created and tested the new package and it has been approved by "
+"the security team, it needs to be uploaded so that it can be installed in "
+"the archives. For security uploads, the place to upload to is "
+"<literal>ftp://security-master.debian.org/pub/SecurityUploadQueue/</"
+"literal> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1163
+msgid ""
+"Once an upload to the security queue has been accepted, the package will "
+"automatically be rebuilt for all architectures and stored for verification "
+"by the security team."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1168
+msgid ""
+"Uploads which are waiting for acceptance or verification are only accessible "
+"by the security team. This is necessary since there might be fixes for "
+"security problems that cannot be disclosed yet."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1173
+msgid ""
+"If a member of the security team accepts a package, it will be installed on "
+"security.debian.org as well as proposed for the proper "
+"<replaceable>distribution</replaceable>-proposed-updates on ftp-master."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:1184
+msgid "Moving, removing, renaming, adopting, and orphaning packages"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:1186
+msgid ""
+"Some archive manipulation operations are not automated in the Debian upload "
+"process. These procedures should be manually followed by maintainers. This "
+"chapter gives guidelines on what to do in these cases."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1191
+msgid "Moving packages"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para><footnote>
+#: pkgs.dbk:1193
+msgid ""
+"Sometimes a package will change its section. For instance, a package from "
+"the `non-free' section might be GPL'd in a later version, in which case the "
+"package should be moved to `main' or `contrib'.<footnote>"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para><footnote><para>
+#: pkgs.dbk:1195
+msgid ""
+"See the <ulink url=\"&url-debian-policy;\">Debian Policy Manual</ulink> for "
+"guidelines on what section a package belongs in."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1200
+msgid ""
+"If you need to change the section for one of your packages, change the "
+"package control information to place the package in the desired section, and "
+"re-upload the package (see the <ulink url=\"&url-debian-policy;\">Debian "
+"Policy Manual</ulink> for details). You must ensure that you include the "
+"<filename>.orig.tar.gz</filename> in your upload (even if you are not "
+"uploading a new upstream version), or it will not appear in the new section "
+"together with the rest of the package. If your new section is valid, it "
+"will be moved automatically. If it does not, then contact the ftpmasters in "
+"order to understand what happened."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1212
+msgid ""
+"If, on the other hand, you need to change the <emphasis>subsection</"
+"emphasis> of one of your packages (e.g., ``devel'', ``admin''), the "
+"procedure is slightly different. Correct the subsection as found in the "
+"control file of the package, and re-upload that. Also, you'll need to get "
+"the override file updated, as described in <xref linkend=\"override-file\"/"
+"> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1221
+msgid "Removing packages"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1223
+msgid ""
+"If for some reason you want to completely remove a package (say, if it is an "
+"old compatibility library which is no longer required), you need to file a "
+"bug against <literal>ftp.debian.org</literal> asking that the package be "
+"removed; as all bugs, this bug should normally have normal severity. Make "
+"sure you indicate which distribution the package should be removed from. "
+"Normally, you can only have packages removed from <emphasis>unstable</"
+"emphasis> and <emphasis>experimental</emphasis>. Packages are not removed "
+"from <emphasis>testing</emphasis> directly. Rather, they will be removed "
+"automatically after the package has been removed from <emphasis>unstable</"
+"emphasis> and no package in <emphasis>testing</emphasis> depends on it."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1236
+msgid ""
+"There is one exception when an explicit removal request is not necessary: If "
+"a (source or binary) package is an orphan, it will be removed semi-"
+"automatically. For a binary-package, this means if there is no longer any "
+"source package producing this binary package; if the binary package is just "
+"no longer produced on some architectures, a removal request is still "
+"necessary. For a source-package, this means that all binary packages it "
+"refers to have been taken over by another source package."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1245
+msgid ""
+"In your removal request, you have to detail the reasons justifying the "
+"request. This is to avoid unwanted removals and to keep a trace of why a "
+"package has been removed. For example, you can provide the name of the "
+"package that supersedes the one to be removed."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1251
+msgid ""
+"Usually you only ask for the removal of a package maintained by yourself. "
+"If you want to remove another package, you have to get the approval of its "
+"maintainer."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1256
+msgid ""
+"Further information relating to these and other package removal related "
+"topics may be found at <ulink url=\"http://wiki.debian.org/ftpmaster_Removals"
+"\"></ulink> and <ulink url=\"&url-debian-qa;howto-remove.html\"></ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1261
+msgid ""
+"If in doubt concerning whether a package is disposable, email &email-debian-"
+"devel; asking for opinions. Also of interest is the <command>apt-cache</"
+"command> program from the <systemitem role=\"package\">apt</systemitem> "
+"package. When invoked as <literal>apt-cache showpkg <replaceable>package</"
+"replaceable></literal>, the program will show details for "
+"<replaceable>package</replaceable>, including reverse depends. Other useful "
+"programs include <literal>apt-cache rdepends</literal>, <command>apt-"
+"rdepends</command> and <command>grep-dctrl</command>. Removal of orphaned "
+"packages is discussed on &email-debian-qa;."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1272
+msgid ""
+"Once the package has been removed, the package's bugs should be handled. "
+"They should either be reassigned to another package in the case where the "
+"actual code has evolved into another package (e.g. <literal>libfoo12</"
+"literal> was removed because <literal>libfoo13</literal> supersedes it) or "
+"closed if the software is simply no longer part of Debian."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:1279
+msgid "Removing packages from <filename>Incoming</filename>"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1281
+msgid ""
+"In the past, it was possible to remove packages from <filename>incoming</"
+"filename>. However, with the introduction of the new incoming system, this "
+"is no longer possible. Instead, you have to upload a new revision of your "
+"package with a higher version than the package you want to replace. Both "
+"versions will be installed in the archive but only the higher version will "
+"actually be available in <emphasis>unstable</emphasis> since the previous "
+"version will immediately be replaced by the higher. However, if you do "
+"proper testing of your packages, the need to replace a package should not "
+"occur too often anyway."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1296
+msgid "Replacing or renaming packages"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1298
+msgid ""
+"When you make a mistake naming your package, you should follow a two-step "
+"process to rename it. First, set your <filename>debian/control</filename> "
+"file to replace and conflict with the obsolete name of the package (see the "
+"<ulink url=\"&url-debian-policy;\">Debian Policy Manual</ulink> for "
+"details). Once you've uploaded the package and the package has moved into "
+"the archive, file a bug against <literal>ftp.debian.org</literal> asking to "
+"remove the package with the obsolete name. Do not forget to properly "
+"reassign the package's bugs at the same time."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1308
+msgid ""
+"At other times, you may make a mistake in constructing your package and wish "
+"to replace it. The only way to do this is to increase the version number "
+"and upload a new version. The old version will be expired in the usual "
+"manner. Note that this applies to each part of your package, including the "
+"sources: if you wish to replace the upstream source tarball of your package, "
+"you will need to upload it with a different version. An easy possibility is "
+"to replace <filename>foo_1.00.orig.tar.gz</filename> with <filename>foo_1.00"
+"+0.orig.tar.gz</filename>. This restriction gives each file on the ftp site "
+"a unique name, which helps to ensure consistency across the mirror network."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1322
+msgid "Orphaning a package"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1324
+msgid ""
+"If you can no longer maintain a package, you need to inform others, and see "
+"that the package is marked as orphaned. You should set the package "
+"maintainer to <literal>Debian QA Group &orphan-address;</literal> and submit "
+"a bug report against the pseudo package <systemitem role=\"package\">wnpp</"
+"systemitem>. The bug report should be titled <literal>O: "
+"<replaceable>package</replaceable> -- <replaceable>short description</"
+"replaceable></literal> indicating that the package is now orphaned. The "
+"severity of the bug should be set to <emphasis>normal</emphasis>; if the "
+"package has a priority of standard or higher, it should be set to "
+"important. If you feel it's necessary, send a copy to &email-debian-devel; "
+"by putting the address in the X-Debbugs-CC: header of the message (no, don't "
+"use CC:, because that way the message's subject won't indicate the bug "
+"number)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1339
+msgid ""
+"If you just intend to give the package away, but you can keep maintainership "
+"for the moment, then you should instead submit a bug against <systemitem "
+"role=\"package\">wnpp</systemitem> and title it <literal>RFA: "
+"<replaceable>package</replaceable> -- <replaceable>short description</"
+"replaceable></literal>. <literal>RFA</literal> stands for <emphasis>Request "
+"For Adoption</emphasis>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1347
+msgid ""
+"More information is on the <ulink url=\"&url-wnpp;\">WNPP web pages</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1353
+msgid "Adopting a package"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1355
+msgid ""
+"A list of packages in need of a new maintainer is available in the <ulink "
+"url=\"&url-wnpp;\">Work-Needing and Prospective Packages list (WNPP)</"
+"ulink>. If you wish to take over maintenance of any of the packages listed "
+"in the WNPP, please take a look at the aforementioned page for information "
+"and procedures."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1362
+msgid ""
+"It is not OK to simply take over a package that you feel is neglected — that "
+"would be package hijacking. You can, of course, contact the current "
+"maintainer and ask them if you may take over the package. If you have "
+"reason to believe a maintainer has gone AWOL (absent without leave), see "
+"<xref linkend=\"mia-qa\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1368
+msgid ""
+"Generally, you may not take over the package without the assent of the "
+"current maintainer. Even if they ignore you, that is still not grounds to "
+"take over a package. Complaints about maintainers should be brought up on "
+"the developers' mailing list. If the discussion doesn't end with a positive "
+"conclusion, and the issue is of a technical nature, consider bringing it to "
+"the attention of the technical committee (see the <ulink url=\"&url-tech-"
+"ctte;\">technical committee web page</ulink> for more information)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1378
+msgid ""
+"If you take over an old package, you probably want to be listed as the "
+"package's official maintainer in the bug system. This will happen "
+"automatically once you upload a new version with an updated "
+"<literal>Maintainer:</literal> field, although it can take a few hours after "
+"the upload is done. If you do not expect to upload a new version for a "
+"while, you can use <xref linkend=\"pkg-tracking-system\"/> to get the bug "
+"reports. However, make sure that the old maintainer has no problem with the "
+"fact that they will continue to receive the bugs during that time."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:1392
+msgid "Porting and being ported"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:1394
+msgid ""
+"Debian supports an ever-increasing number of architectures. Even if you are "
+"not a porter, and you don't use any architecture but one, it is part of your "
+"duty as a maintainer to be aware of issues of portability. Therefore, even "
+"if you are not a porter, you should read most of this chapter."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:1400
+msgid ""
+"Porting is the act of building Debian packages for architectures that are "
+"different from the original architecture of the package maintainer's binary "
+"package. It is a unique and essential activity. In fact, porters do most "
+"of the actual compiling of Debian packages. For instance, for a single "
+"<emphasis>i386</emphasis> binary package, there must be a recompile for each "
+"architecture, which amounts to &number-of-arches; more builds."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1408
+msgid "Being kind to porters"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1410
+msgid ""
+"Porters have a difficult and unique task, since they are required to deal "
+"with a large volume of packages. Ideally, every source package should build "
+"right out of the box. Unfortunately, this is often not the case. This "
+"section contains a checklist of ``gotchas'' often committed by Debian "
+"maintainers — common problems which often stymie porters, and make their "
+"jobs unnecessarily difficult."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1418
+msgid ""
+"The first and most important thing is to respond quickly to bug or issues "
+"raised by porters. Please treat porters with courtesy, as if they were in "
+"fact co-maintainers of your package (which, in a way, they are). Please be "
+"tolerant of succinct or even unclear bug reports; do your best to hunt down "
+"whatever the problem is."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1425
+msgid ""
+"By far, most of the problems encountered by porters are caused by "
+"<emphasis>packaging bugs</emphasis> in the source packages. Here is a "
+"checklist of things you should check or be aware of."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:1432
+msgid ""
+"Make sure that your <literal>Build-Depends</literal> and <literal>Build-"
+"Depends-Indep</literal> settings in <filename>debian/control</filename> are "
+"set properly. The best way to validate this is to use the <systemitem role="
+"\"package\">debootstrap</systemitem> package to create an unstable chroot "
+"environment (see <xref linkend=\"debootstrap\"/> ). Within that chrooted "
+"environment, install the <systemitem role=\"package\">build-essential</"
+"systemitem> package and any package dependencies mentioned in <literal>Build-"
+"Depends</literal> and/or <literal>Build-Depends-Indep</literal>. Finally, "
+"try building your package within that chrooted environment. These steps can "
+"be automated by the use of the <command>pbuilder</command> program which is "
+"provided by the package of the same name (see <xref linkend=\"pbuilder\"/> )."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:1446
+msgid ""
+"If you can't set up a proper chroot, <command>dpkg-depcheck</command> may be "
+"of assistance (see <xref linkend=\"dpkg-depcheck\"/> )."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:1450
+msgid ""
+"See the <ulink url=\"&url-debian-policy;\">Debian Policy Manual</ulink> for "
+"instructions on setting build dependencies."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:1456
+msgid ""
+"Don't set architecture to a value other than ``all'' or ``any'' unless you "
+"really mean it. In too many cases, maintainers don't follow the "
+"instructions in the <ulink url=\"&url-debian-policy;\">Debian Policy Manual</"
+"ulink>. Setting your architecture to ``i386'' is usually incorrect."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:1464
+msgid ""
+"Make sure your source package is correct. Do <literal>dpkg-source -x "
+"<replaceable>package</replaceable>.dsc</literal> to make sure your source "
+"package unpacks properly. Then, in there, try building your package from "
+"scratch with <command>dpkg-buildpackage</command>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:1472
+msgid ""
+"Make sure you don't ship your source package with the <filename>debian/"
+"files</filename> or <filename>debian/substvars</filename> files. They "
+"should be removed by the `clean' target of <filename>debian/rules</filename>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:1480
+msgid ""
+"Make sure you don't rely on locally installed or hacked configurations or "
+"programs. For instance, you should never be calling programs in <filename>/"
+"usr/local/bin</filename> or the like. Try not to rely on programs being "
+"setup in a special way. Try building your package on another machine, even "
+"if it's the same architecture."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:1489
+msgid ""
+"Don't depend on the package you're building being installed already (a sub-"
+"case of the above issue)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:1495
+msgid ""
+"Don't rely on the compiler being a certain version, if possible. If not, "
+"then make sure your build dependencies reflect the restrictions, although "
+"you are probably asking for trouble, since different architectures sometimes "
+"standardize on different compilers."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:1503
+msgid ""
+"Make sure your debian/rules contains separate ``binary-arch'' and ``binary-"
+"indep'' targets, as the Debian Policy Manual requires. Make sure that both "
+"targets work independently, that is, that you can call the target without "
+"having called the other before. To test this, try to run <literal>dpkg-"
+"buildpackage -B</literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1514
+msgid "Guidelines for porter uploads"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1516
+msgid ""
+"If the package builds out of the box for the architecture to be ported to, "
+"you are in luck and your job is easy. This section applies to that case; it "
+"describes how to build and upload your binary package so that it is properly "
+"installed into the archive. If you do have to patch the package in order to "
+"get it to compile for the other architecture, you are actually doing a "
+"source NMU, so consult <xref linkend=\"nmu-guidelines\"/> instead."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1524
+msgid ""
+"For a porter upload, no changes are being made to the source. You do not "
+"need to touch any of the files in the source package. This includes "
+"<filename>debian/changelog</filename>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1529
+msgid ""
+"The way to invoke <command>dpkg-buildpackage</command> is as <literal>dpkg-"
+"buildpackage -B -m<replaceable>porter-email</replaceable></literal>. Of "
+"course, set <replaceable>porter-email</replaceable> to your email address. "
+"This will do a binary-only build of only the architecture-dependent portions "
+"of the package, using the `binary-arch' target in <filename>debian/rules</"
+"filename>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1537
+msgid ""
+"If you are working on a Debian machine for your porting efforts and you need "
+"to sign your upload locally for its acceptance in the archive, you can run "
+"<command>debsign</command> on your <filename>.changes</filename> file to "
+"have it signed conveniently, or use the remote signing mode of <command>dpkg-"
+"sig</command>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:1544
+msgid "Recompilation or binary-only NMU"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1546
+msgid ""
+"Sometimes the initial porter upload is problematic because the environment "
+"in which the package was built was not good enough (outdated or obsolete "
+"library, bad compiler, ...). Then you may just need to recompile it in an "
+"updated environment. However, you have to bump the version number in this "
+"case, so that the old bad package can be replaced in the Debian archive "
+"(<command>katie</command> refuses to install new packages if they don't have "
+"a version number greater than the currently available one)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1555
+msgid ""
+"You have to make sure that your binary-only NMU doesn't render the package "
+"uninstallable. This could happen when a source package generates arch-"
+"dependent and arch-independent packages that depend on each other via "
+"$(Source-Version)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1561
+msgid ""
+"Despite the required modification of the changelog, these are called binary-"
+"only NMUs — there is no need in this case to trigger all other architectures "
+"to consider themselves out of date or requiring recompilation."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1566
+msgid ""
+"Such recompilations require special ``magic'' version numbering, so that the "
+"archive maintenance tools recognize that, even though there is a new Debian "
+"version, there is no corresponding source update. If you get this wrong, "
+"the archive maintainers will reject your upload (due to lack of "
+"corresponding source code)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para><footnote>
+#: pkgs.dbk:1573
+msgid ""
+"The ``magic'' for a recompilation-only NMU is triggered by using a suffix "
+"appended to the package version number, following the form b<number>. "
+"For instance, if the latest version you are recompiling against was version "
+"``2.9-3'', your NMU should carry a version of ``2.9-3+b1''. If the latest "
+"version was ``3.4+b1'' (i.e, a native package with a previous recompilation "
+"NMU), your NMU should have a version number of ``3.4+b2''. <footnote>"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para><footnote><para>
+#: pkgs.dbk:1578
+msgid ""
+"In the past, such NMUs used the third-level number on the Debian part of the "
+"revision to denote their recompilation-only status; however, this syntax was "
+"ambiguous with native packages and did not allow proper ordering of "
+"recompile-only NMUs, source NMUs, and security NMUs on the same package, and "
+"has therefore been abandoned in favor of this new syntax."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1586
+msgid ""
+"Similar to initial porter uploads, the correct way of invoking <command>dpkg-"
+"buildpackage</command> is <literal>dpkg-buildpackage -B</literal> to only "
+"build the architecture-dependent parts of the package."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:1593
+msgid "When to do a source NMU if you are a porter"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1595
+msgid ""
+"Porters doing a source NMU generally follow the guidelines found in <xref "
+"linkend=\"nmu\"/> , just like non-porters. However, it is expected that the "
+"wait cycle for a porter's source NMU is smaller than for a non-porter, since "
+"porters have to cope with a large quantity of packages. Again, the "
+"situation varies depending on the distribution they are uploading to. It "
+"also varies whether the architecture is a candidate for inclusion into the "
+"next stable release; the release managers decide and announce which "
+"architectures are candidates."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1604
+msgid ""
+"If you are a porter doing an NMU for `unstable', the above guidelines for "
+"porting should be followed, with two variations. Firstly, the acceptable "
+"waiting period — the time between when the bug is submitted to the BTS and "
+"when it is OK to do an NMU — is seven days for porters working on the "
+"unstable distribution. This period can be shortened if the problem is "
+"critical and imposes hardship on the porting effort, at the discretion of "
+"the porter group. (Remember, none of this is Policy, just mutually agreed "
+"upon guidelines.) For uploads to stable or testing, please coordinate with "
+"the appropriate release team first."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1615
+msgid ""
+"Secondly, porters doing source NMUs should make sure that the bug they "
+"submit to the BTS should be of severity `serious' or greater. This ensures "
+"that a single source package can be used to compile every supported Debian "
+"architecture by release time. It is very important that we have one version "
+"of the binary and source package for all architecture in order to comply "
+"with many licenses."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1623
+msgid ""
+"Porters should try to avoid patches which simply kludge around bugs in the "
+"current version of the compile environment, kernel, or libc. Sometimes such "
+"kludges can't be helped. If you have to kludge around compiler bugs and the "
+"like, make sure you <literal>#ifdef</literal> your work properly; also, "
+"document your kludge so that people know to remove it once the external "
+"problems have been fixed."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1631
+msgid ""
+"Porters may also have an unofficial location where they can put the results "
+"of their work during the waiting period. This helps others running the port "
+"have the benefit of the porter's work, even during the waiting period. Of "
+"course, such locations have no official blessing or status, so buyer beware."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1641
+msgid "Porting infrastructure and automation"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1643
+msgid ""
+"There is infrastructure and several tools to help automate package porting. "
+"This section contains a brief overview of this automation and porting to "
+"these tools; see the package documentation or references for full "
+"information."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:1648
+msgid "Mailing lists and web pages"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1650
+msgid ""
+"Web pages containing the status of each port can be found at <ulink url="
+"\"&url-debian-ports;\"></ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1654
+msgid ""
+"Each port of Debian has a mailing list. The list of porting mailing lists "
+"can be found at <ulink url=\"&url-debian-port-lists;\"></ulink>. These "
+"lists are used to coordinate porters, and to connect the users of a given "
+"port with the porters."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:1662
+msgid "Porter tools"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1664
+msgid ""
+"Descriptions of several porting tools can be found in <xref linkend=\"tools-"
+"porting\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1672
+msgid ""
+"The <systemitem role=\"package\">buildd</systemitem> system is used as a "
+"distributed, client-server build distribution system. It is usually used in "
+"conjunction with <emphasis>auto-builders</emphasis>, which are ``slave'' "
+"hosts which simply check out and attempt to auto-build packages which need "
+"to be ported. There is also an email interface to the system, which allows "
+"porters to ``check out'' a source package (usually one which cannot yet be "
+"auto-built) and work on it."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1681
+msgid ""
+"<systemitem role=\"package\">buildd</systemitem> is not yet available as a "
+"package; however, most porting efforts are either using it currently or "
+"planning to use it in the near future. The actual automated builder is "
+"packaged as <systemitem role=\"package\">sbuild</systemitem>, see its "
+"description in <xref linkend=\"sbuild\"/> . The complete <systemitem role="
+"\"package\">buildd</systemitem> system also collects a number of as yet "
+"unpackaged components which are currently very useful and in use "
+"continually, such as <command>andrea</command> and <command>wanna-build</"
+"command>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1691
+msgid ""
+"Some of the data produced by <systemitem role=\"package\">buildd</"
+"systemitem> which is generally useful to porters is available on the web at "
+"<ulink url=\"&url-buildd;\"></ulink>. This data includes nightly updated "
+"information from <command>andrea</command> (source dependencies) and "
+"<systemitem role=\"package\">quinn-diff</systemitem> (packages needing "
+"recompilation)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1699
+msgid ""
+"We are quite proud of this system, since it has so many possible uses. "
+"Independent development groups can use the system for different sub-flavors "
+"of Debian, which may or may not really be of general interest (for instance, "
+"a flavor of Debian built with <command>gcc</command> bounds checking). It "
+"will also enable Debian to recompile entire distributions quickly."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1706
+msgid ""
+"The buildds admins of each arch can be contacted at the mail address "
+"$arch@buildd.debian.org."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1714
+msgid "When your package is <emphasis>not</emphasis> portable"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1716
+msgid ""
+"Some packages still have issues with building and/or working on some of the "
+"architectures supported by Debian, and cannot be ported at all, or not "
+"within a reasonable amount of time. An example is a package that is SVGA-"
+"specific (only i386), or uses other hardware-specific features not supported "
+"on all architectures."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1723
+msgid ""
+"In order to prevent broken packages from being uploaded to the archive, and "
+"wasting buildd time, you need to do a few things:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1729
+msgid ""
+"First, make sure your package <emphasis>does</emphasis> fail to build on "
+"architectures that it cannot support. There are a few ways to achieve "
+"this. The preferred way is to have a small testsuite during build time that "
+"will test the functionality, and fail if it doesn't work. This is a good "
+"idea anyway, as this will prevent (some) broken uploads on all "
+"architectures, and also will allow the package to build as soon as the "
+"required functionality is available."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1737
+msgid ""
+"Additionally, if you believe the list of supported architectures is pretty "
+"constant, you should change 'any' to a list of supported architectures in "
+"debian/control. This way, the build will fail also, and indicate this to a "
+"human reader without actually trying."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1745
+msgid ""
+"In order to prevent autobuilders from needlessly trying to build your "
+"package, it must be included in <filename>packages-arch-specific</filename>, "
+"a list used by the <command>wanna-build</command> script. The current "
+"version is available as <ulink url=\"&url-cvsweb;srcdep/Packages-arch-"
+"specific?cvsroot=dak\"></ulink>; please see the top of the file for whom to "
+"contact for changes."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1755
+msgid ""
+"Please note that it is insufficient to only add your package to Packages-"
+"arch-specific without making it fail to build on unsupported architectures: "
+"A porter or any other person trying to build your package might accidently "
+"upload it without noticing it doesn't work. If in the past some binary "
+"packages were uploaded on unsupported architectures, request their removal "
+"by filing a bug against <systemitem role=\"package\">ftp.debian.org</"
+"systemitem>"
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:1768
+msgid "Non-Maintainer Uploads (NMUs)"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:1770
+msgid ""
+"Under certain circumstances it is necessary for someone other than the "
+"official package maintainer to make a release of a package. This is called "
+"a non-maintainer upload, or NMU."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:1775
+msgid ""
+"This section handles only source NMUs, i.e. NMUs which upload a new version "
+"of the package. For binary-only NMUs by porters or QA members, please see "
+"<xref linkend=\"binary-only-nmu\"/> . If a buildd builds and uploads a "
+"package, that too is strictly speaking a binary NMU. See <xref linkend="
+"\"buildd\"/> for some more information."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:1782
+msgid ""
+"The main reason why NMUs are done is when a developer needs to fix another "
+"developer's package in order to address serious problems or crippling bugs "
+"or when the package maintainer is unable to release a fix in a timely "
+"fashion."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:1787
+msgid ""
+"First and foremost, it is critical that NMU patches to source should be as "
+"non-disruptive as possible. Do not do housekeeping tasks, do not change the "
+"name of modules or files, do not move directories; in general, do not fix "
+"things which are not broken. Keep the patch as small as possible. If "
+"things bother you aesthetically, talk to the Debian maintainer, talk to the "
+"upstream maintainer, or submit a bug. However, aesthetic changes must "
+"<emphasis>not</emphasis> be made in a non-maintainer upload."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:1796
+msgid ""
+"And please remember the Hippocratic Oath: Above all, do no harm. It is "
+"better to leave a package with an open grave bug than applying a non-"
+"functional patch, or one that hides the bug instead of resolving it."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1801
+msgid "How to do a NMU"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1803
+msgid ""
+"NMUs which fix important, serious or higher severity bugs are encouraged and "
+"accepted. You should endeavor to reach the current maintainer of the "
+"package; they might be just about to upload a fix for the problem, or have a "
+"better solution."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1809
+msgid ""
+"NMUs should be made to assist a package's maintainer in resolving bugs. "
+"Maintainers should be thankful for that help, and NMUers should respect the "
+"decisions of maintainers, and try to personally help the maintainer by their "
+"work."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1815
+msgid ""
+"A NMU should follow all conventions, written down in this section. For an "
+"upload to testing or unstable, this order of steps is recommended:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1821
+msgid ""
+"Make sure that the package's bugs that the NMU is meant to address are all "
+"filed in the Debian Bug Tracking System (BTS). If they are not, submit them "
+"immediately."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1828
+msgid ""
+"Wait a few days for the response from the maintainer. If you don't get any "
+"response, you may want to help them by sending the patch that fixes the "
+"bug. Don't forget to tag the bug with the patch keyword."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1835
+msgid ""
+"Wait a few more days. If you still haven't got an answer from the "
+"maintainer, send them a mail announcing your intent to NMU the package. "
+"Prepare an NMU as described in this section, and test it carefully on your "
+"machine (cf. <xref linkend=\"sanitycheck\"/> ). Double check that your "
+"patch doesn't have any unexpected side effects. Make sure your patch is as "
+"small and as non-disruptive as it can be."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1845
+msgid ""
+"Upload your package to incoming in <filename>DELAYED/7-day</filename> (cf. "
+"<xref linkend=\"delayed-incoming\"/> ), send the final patch to the "
+"maintainer via the BTS, and explain to them that they have 7 days to react "
+"if they want to cancel the NMU."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1853
+msgid ""
+"Follow what happens, you're responsible for any bug that you introduced with "
+"your NMU. You should probably use <xref linkend=\"pkg-tracking-system\"/> "
+"(PTS) to stay informed of the state of the package after your NMU."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1860
+msgid ""
+"At times, the release manager or an organized group of developers can "
+"announce a certain period of time in which the NMU rules are relaxed. This "
+"usually involves shortening the period during which one is to wait before "
+"uploading the fixes, and shortening the DELAYED period. It is important to "
+"notice that even in these so-called bug squashing party times, the NMU'er "
+"has to file bugs and contact the developer first, and act later. Please see "
+"<xref linkend=\"qa-bsp\"/> for details."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1869
+msgid ""
+"For the testing distribution, the rules may be changed by the release "
+"managers. Please take additional care, and acknowledge that the usual way "
+"for a package to enter testing is through unstable."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1874
+msgid ""
+"For the stable distribution, please take extra care. Of course, the release "
+"managers may also change the rules here. Please verify before you upload "
+"that all your changes are OK for inclusion into the next stable release by "
+"the release manager."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1880
+msgid ""
+"When a security bug is detected, the security team may do an NMU, using "
+"their own rules. Please refer to <xref linkend=\"bug-security\"/> for more "
+"information."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1885
+msgid ""
+"For the differences for Porters NMUs, please see <xref linkend=\"source-nmu-"
+"when-porter\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1889
+msgid ""
+"Of course, it is always possible to agree on special rules with a maintainer "
+"(like the maintainer asking please upload this fix directly for me, and no "
+"diff required)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1896
+msgid "NMU version numbering"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1898
+msgid ""
+"Whenever you have made a change to a package, no matter how trivial, the "
+"version number needs to change. This enables our packing system to function."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1902
+msgid ""
+"If you are doing a non-maintainer upload (NMU), you should add a new minor "
+"version number to the <replaceable>debian-revision</replaceable> part of the "
+"version number (the portion after the last hyphen). This extra minor number "
+"will start at `1'. For example, consider the package `foo', which is at "
+"version 1.1-3. In the archive, the source package control file would be "
+"<filename>foo_1.1-3.dsc</filename>. The upstream version is `1.1' and the "
+"Debian revision is `3'. The next NMU would add a new minor number `.1' to "
+"the Debian revision; the new source control file would be <filename>foo_1.1-"
+"3.1.dsc</filename>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1913
+msgid ""
+"The Debian revision minor number is needed to avoid stealing one of the "
+"package maintainer's version numbers, which might disrupt their work. It "
+"also has the benefit of making it visually clear that a package in the "
+"archive was not made by the official maintainer."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1919
+msgid ""
+"If there is no <replaceable>debian-revision</replaceable> component in the "
+"version number then one should be created, starting at `0.1' (but in case of "
+"a debian native package still upload it as native package). If it is "
+"absolutely necessary for someone other than the usual maintainer to make a "
+"release based on a new upstream version then the person making the release "
+"should start with the <replaceable>debian-revision</replaceable> value "
+"`0.1'. The usual maintainer of a package should start their "
+"<replaceable>debian-revision</replaceable> numbering at `1'."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1929
+msgid ""
+"If you upload a package to testing or stable, sometimes, you need to fork "
+"the version number tree. For this, version numbers like 1.1-3sarge0.1 could "
+"be used."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1936
+msgid "Source NMUs must have a new changelog entry"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1938
+msgid ""
+"Anyone who is doing a source NMU must create a changelog entry, describing "
+"which bugs are fixed by the NMU, and generally why the NMU was required and "
+"what it fixed. The changelog entry will have the email address of the "
+"person who uploaded it in the log entry and the NMU version number in it."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1944
+msgid "By convention, source NMU changelog entries start with the line"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: pkgs.dbk:1947
+#, no-wrap
+msgid "* Non-maintainer upload"
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1952
+msgid "Source NMUs and the Bug Tracking System"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1954
+msgid ""
+"Maintainers other than the official package maintainer should make as few "
+"changes to the package as possible, and they should always send a patch as a "
+"unified context diff (<literal>diff -u</literal>) detailing their changes to "
+"the Bug Tracking System."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1960
+msgid ""
+"What if you are simply recompiling the package? If you just need to "
+"recompile it for a single architecture, then you may do a binary-only NMU as "
+"described in <xref linkend=\"binary-only-nmu\"/> which doesn't require any "
+"patch to be sent. If you want the package to be recompiled for all "
+"architectures, then you do a source NMU as usual and you will have to send a "
+"patch."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1967
+msgid ""
+"Bugs fixed by source NMUs used to be tagged fixed instead of closed, but "
+"since version tracking is in place, such bugs are now also closed with the "
+"NMU version."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1972
+msgid ""
+"Also, after doing an NMU, you have to send the information to the existing "
+"bugs that are fixed by your NMU, including the unified diff. Historically, "
+"it was custom to open a new bug and include a patch showing all the changes "
+"you have made. The normal maintainer will either apply the patch or employ "
+"an alternate method of fixing the problem. Sometimes bugs are fixed "
+"independently upstream, which is another good reason to back out an NMU's "
+"patch. If the maintainer decides not to apply the NMU's patch but to "
+"release a new version, the maintainer needs to ensure that the new upstream "
+"version really fixes each problem that was fixed in the non-maintainer "
+"release."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1983
+msgid ""
+"In addition, the normal maintainer should <emphasis>always</emphasis> retain "
+"the entry in the changelog file documenting the non-maintainer upload -- and "
+"of course, also keep the changes. If you revert some of the changes, please "
+"reopen the relevant bug reports."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1991
+msgid "Building source NMUs"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1993
+msgid ""
+"Source NMU packages are built normally. Pick a distribution using the same "
+"rules as found in <xref linkend=\"distribution\"/> , follow the other "
+"instructions in <xref linkend=\"upload\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1998
+msgid ""
+"Make sure you do <emphasis>not</emphasis> change the value of the maintainer "
+"in the <filename>debian/control</filename> file. Your name as given in the "
+"NMU entry of the <filename>debian/changelog</filename> file will be used for "
+"signing the changes file."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:2006
+msgid "Acknowledging an NMU"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2008
+msgid ""
+"If one of your packages has been NMU'ed, you have to incorporate the changes "
+"in your copy of the sources. This is easy, you just have to apply the patch "
+"that has been sent to you. Once this is done, you have to close the bugs "
+"that have been tagged fixed by the NMU. The easiest way is to use the "
+"<literal>-v</literal> option of <command>dpkg-buildpackage</command>, as "
+"this allows you to include just all changes since your last maintainer "
+"upload. Alternatively, you can close them manually by sending the required "
+"mails to the BTS or by adding the required <literal>closes: #nnnn</literal> "
+"in the changelog entry of your next upload."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2019
+msgid ""
+"In any case, you should not be upset by the NMU. An NMU is not a personal "
+"attack against the maintainer. It is a proof that someone cares enough "
+"about the package that they were willing to help you in your work, so you "
+"should be thankful. You may also want to ask them if they would be "
+"interested in helping you on a more frequent basis as co-maintainer or "
+"backup maintainer (see <xref linkend=\"collaborative-maint\"/> )."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:2029
+msgid "NMU vs QA uploads"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2031
+msgid ""
+"Unless you know the maintainer is still active, it is wise to check the "
+"package to see if it has been orphaned. The current list of orphaned "
+"packages which haven't had their maintainer set correctly is available at "
+"<ulink url=\"&url-debian-qa-orphaned;\"></ulink>. If you perform an NMU on "
+"an improperly orphaned package, please set the maintainer to <literal>Debian "
+"QA Group <packages@qa.debian.org></literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:2041
+msgid "Who can do an NMU"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2043
+msgid ""
+"Only official, registered Debian Developers can do binary or source NMUs. A "
+"Debian Developer is someone who has their key in the Debian key ring. Non-"
+"developers, however, are encouraged to download the source package and start "
+"hacking on it to fix problems; however, rather than doing an NMU, they "
+"should just submit worthwhile patches to the Bug Tracking System. "
+"Maintainers almost always appreciate quality patches and bug reports."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:2053
+msgid "Terminology"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2055
+msgid ""
+"There are two new terms used throughout this section: ``binary-only NMU'' "
+"and ``source NMU''. These terms are used with specific technical meaning "
+"throughout this document. Both binary-only and source NMUs are similar, "
+"since they involve an upload of a package by a developer who is not the "
+"official maintainer of that package. That is why it's a <emphasis>non-"
+"maintainer</emphasis> upload."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2063
+msgid ""
+"A source NMU is an upload of a package by a developer who is not the "
+"official maintainer, for the purposes of fixing a bug in the package. "
+"Source NMUs always involves changes to the source (even if it is just a "
+"change to <filename>debian/changelog</filename>). This can be either a "
+"change to the upstream source, or a change to the Debian bits of the "
+"source. Note, however, that source NMUs may also include architecture-"
+"dependent packages, as well as an updated Debian diff."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2072
+msgid ""
+"A binary-only NMU is a recompilation and upload of a binary package for a "
+"given architecture. As such, it is usually part of a porting effort. A "
+"binary-only NMU is a non-maintainer uploaded binary version of a package, "
+"with no source changes required. There are many cases where porters must "
+"fix problems in the source in order to get them to compile for their target "
+"architecture; that would be considered a source NMU rather than a binary-"
+"only NMU. As you can see, we don't distinguish in terminology between "
+"porter NMUs and non-porter NMUs."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2082
+msgid ""
+"Both classes of NMUs, source and binary-only, can be lumped under the term "
+"``NMU''. However, this often leads to confusion, since most people think "
+"``source NMU'' when they think ``NMU''. So it's best to be careful: always "
+"use ``binary NMU'' or ``binNMU'' for binary-only NMUs."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:2092
+msgid "Collaborative maintenance"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:2094
+msgid ""
+"Collaborative maintenance is a term describing the sharing of Debian package "
+"maintenance duties by several people. This collaboration is almost always a "
+"good idea, since it generally results in higher quality and faster bug fix "
+"turnaround times. It is strongly recommended that packages with a priority "
+"of <literal>Standard</literal> or which are part of the base set have co-"
+"maintainers."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:2102
+msgid ""
+"Generally there is a primary maintainer and one or more co-maintainers. The "
+"primary maintainer is the person whose name is listed in the "
+"<literal>Maintainer</literal> field of the <filename>debian/control</"
+"filename> file. Co-maintainers are all the other maintainers."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:2108
+msgid ""
+"In its most basic form, the process of adding a new co-maintainer is quite "
+"easy:"
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2114
+msgid ""
+"Setup the co-maintainer with access to the sources you build the package "
+"from. Generally this implies you are using a network-capable version "
+"control system, such as <command>CVS</command> or <command>Subversion</"
+"command>. Alioth (see <xref linkend=\"alioth\"/> ) provides such tools, "
+"amongst others."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2122
+msgid ""
+"Add the co-maintainer's correct maintainer name and address to the "
+"<literal>Uploaders</literal> field in the global part of the "
+"<filename>debian/control</filename> file."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><screen>
+#: pkgs.dbk:2127
+#, no-wrap
+msgid "Uploaders: John Buzz <jbuzz@debian.org>, Adam Rex <arex@debian.org>"
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2132
+msgid ""
+"Using the PTS (<xref linkend=\"pkg-tracking-system\"/> ), the co-maintainers "
+"should subscribe themselves to the appropriate source package."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:2138
+msgid ""
+"Another form of collaborative maintenance is team maintenance, which is "
+"recommended if you maintain several packages with the same group of "
+"developers. In that case, the Maintainer and Uploaders field of each "
+"package must be managed with care. It is recommended to choose between one "
+"of the two following schemes:"
+msgstr ""
+
+# type: Content of: <chapter><section><orderedlist><listitem><para>
+#: pkgs.dbk:2147
+msgid ""
+"Put the team member mainly responsible for the package in the Maintainer "
+"field. In the Uploaders, put the mailing list address, and the team members "
+"who care for the package."
+msgstr ""
+
+# type: Content of: <chapter><section><orderedlist><listitem><para>
+#: pkgs.dbk:2154
+msgid ""
+"Put the mailing list address in the Maintainer field. In the Uploaders "
+"field, put the team members who care for the package. In this case, you "
+"must make sure the mailing list accept bug reports without any human "
+"interaction (like moderation for non-subscribers)."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:2162
+msgid ""
+"In any case, it is a bad idea to automatically put all team members in the "
+"Uploaders field. It clutters the Developer's Package Overview listing (see "
+"<xref linkend=\"ddpo\"/> ) with packages one doesn't really care for, and "
+"creates a false sense of good maintenance."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:2170
+msgid "The testing distribution"
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:2172
+msgid "Basics"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2174
+msgid ""
+"Packages are usually installed into the `testing' distribution after they "
+"have undergone some degree of testing in unstable."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2178
+msgid ""
+"They must be in sync on all architectures and mustn't have dependencies that "
+"make them uninstallable; they also have to have generally no known release-"
+"critical bugs at the time they're installed into testing. This way, "
+"`testing' should always be close to being a release candidate. Please see "
+"below for details."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:2187
+msgid "Updates from unstable"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2189
+msgid ""
+"The scripts that update the <emphasis>testing</emphasis> distribution are "
+"run each day after the installation of the updated packages; these scripts "
+"are called <emphasis>britney</emphasis>. They generate the "
+"<filename>Packages</filename> files for the <emphasis>testing</emphasis> "
+"distribution, but they do so in an intelligent manner; they try to avoid any "
+"inconsistency and to use only non-buggy packages."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2197
+msgid ""
+"The inclusion of a package from <emphasis>unstable</emphasis> is conditional "
+"on the following:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2203
+msgid ""
+"The package must have been available in <emphasis>unstable</emphasis> for 2, "
+"5 or 10 days, depending on the urgency (high, medium or low). Please note "
+"that the urgency is sticky, meaning that the highest urgency uploaded since "
+"the previous testing transition is taken into account. Those delays may be "
+"doubled during a freeze, or testing transitions may be switched off "
+"altogether;"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2212
+msgid ""
+"It must have the same number or fewer release-critical bugs than the version "
+"currently available in <emphasis>testing</emphasis>;"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2218
+msgid ""
+"It must be available on all architectures on which it has previously been "
+"built in unstable. <xref linkend=\"madison\"/> may be of interest to check "
+"that information;"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2225
+msgid ""
+"It must not break any dependency of a package which is already available in "
+"<emphasis>testing</emphasis>;"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2231
+msgid ""
+"The packages on which it depends must either be available in "
+"<emphasis>testing</emphasis> or they must be accepted into "
+"<emphasis>testing</emphasis> at the same time (and they will be if they "
+"fulfill all the necessary criteria);"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2239
+msgid ""
+"To find out whether a package is progressing into testing or not, see the "
+"testing script output on the <ulink url=\"&url-testing-maint;\">web page of "
+"the testing distribution</ulink>, or use the program <command>grep-excuses</"
+"command> which is in the <systemitem role=\"package\">devscripts</"
+"systemitem> package. This utility can easily be used in a <citerefentry> "
+"<refentrytitle>crontab</refentrytitle> <manvolnum>5</manvolnum> </"
+"citerefentry> to keep yourself informed of the progression of your packages "
+"into <emphasis>testing</emphasis>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2250
+msgid ""
+"The <filename>update_excuses</filename> file does not always give the "
+"precise reason why the package is refused; you may have to find it on your "
+"own by looking for what would break with the inclusion of the package. The "
+"<ulink url=\"&url-testing-maint;\">testing web page</ulink> gives some more "
+"information about the usual problems which may be causing such troubles."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2257
+msgid ""
+"Sometimes, some packages never enter <emphasis>testing</emphasis> because "
+"the set of inter-relationship is too complicated and cannot be sorted out by "
+"the scripts. See below for details."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2262
+msgid ""
+"Some further dependency analysis is shown on <ulink url=\"http://bjorn.haxx."
+"se/debian/\"></ulink> — but be warned, this page also shows build "
+"dependencies which are not considered by britney."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:2267
+msgid "out-of-date"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#. FIXME: better rename this file than document rampant professionalism?
+#: pkgs.dbk:2270
+msgid ""
+"For the testing migration script, outdated means: There are different "
+"versions in unstable for the release architectures (except for the "
+"architectures in fuckedarches; fuckedarches is a list of architectures that "
+"don't keep up (in update_out.py), but currently, it's empty). outdated has "
+"nothing whatsoever to do with the architectures this package has in testing."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2277
+msgid "Consider this example:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry>
+#: pkgs.dbk:2284 pkgs.dbk:2315
+msgid "alpha"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry>
+#: pkgs.dbk:2285 pkgs.dbk:2316
+msgid "arm"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry>
+#: pkgs.dbk:2290 pkgs.dbk:2322 pkgs.dbk:2382
+msgid "testing"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
+#: pkgs.dbk:2291 pkgs.dbk:2296 pkgs.dbk:2323 pkgs.dbk:2324 pkgs.dbk:2331
+msgid "1"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
+#: pkgs.dbk:2292 pkgs.dbk:2325 pkgs.dbk:2330
+msgid "-"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry>
+#: pkgs.dbk:2295 pkgs.dbk:2328 pkgs.dbk:2383
+msgid "unstable"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
+#: pkgs.dbk:2297 pkgs.dbk:2329
+msgid "2"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2303
+msgid ""
+"The package is out of date on alpha in unstable, and will not go to "
+"testing. And removing foo from testing would not help at all, the package "
+"is still out of date on alpha, and will not propagate to testing."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2308
+msgid "However, if ftp-master removes a package in unstable (here on arm):"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry>
+#: pkgs.dbk:2317
+msgid "hurd-i386"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2337
+msgid ""
+"In this case, the package is up to date on all release architectures in "
+"unstable (and the extra hurd-i386 doesn't matter, as it's not a release "
+"architecture)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2342
+msgid ""
+"Sometimes, the question is raised if it is possible to allow packages in "
+"that are not yet built on all architectures: No. Just plainly no. (Except "
+"if you maintain glibc or so.)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:2349
+msgid "Removals from testing"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2351
+msgid ""
+"Sometimes, a package is removed to allow another package in: This happens "
+"only to allow <emphasis>another</emphasis> package to go in if it's ready in "
+"every other sense. Suppose e.g. that <emphasis>a</emphasis> cannot be "
+"installed with the new version of <emphasis>b</emphasis>; then <emphasis>a</"
+"emphasis> may be removed to allow <emphasis>b</emphasis> in."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2358
+msgid ""
+"Of course, there is another reason to remove a package from testing: It's "
+"just too buggy (and having a single RC-bug is enough to be in this state)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2362
+msgid ""
+"Furthermore, if a package has been removed from unstable, and no package in "
+"testing depends on it any more, then it will automatically be removed."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:2368
+msgid "circular dependencies"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2370
+msgid ""
+"A situation which is not handled very well by britney is if package "
+"<emphasis>a</emphasis> depends on the new version of package <emphasis>b</"
+"emphasis>, and vice versa."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2375
+msgid "An example of this is:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
+#: pkgs.dbk:2388
+msgid "a"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
+#: pkgs.dbk:2389
+msgid "1; depends: b=1"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
+#: pkgs.dbk:2390
+msgid "2; depends: b=2"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
+#: pkgs.dbk:2393
+msgid "b"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
+#: pkgs.dbk:2394
+msgid "1; depends: a=1"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
+#: pkgs.dbk:2395
+msgid "2; depends: a=2"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2401
+msgid ""
+"Neither package <emphasis>a</emphasis> nor package <emphasis>b</emphasis> is "
+"considered for update."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2405
+msgid ""
+"Currently, this requires some manual hinting from the release team. Please "
+"contact them by sending mail to &email-debian-release; if this happens to "
+"one of your packages."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:2412
+msgid "influence of package in testing"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2414
+msgid ""
+"Generally, there is nothing that the status of a package in testing means "
+"for transition of the next version from unstable to testing, with two "
+"exceptions: If the RC-bugginess of the package goes down, it may go in even "
+"if it is still RC-buggy. The second exception is if the version of the "
+"package in testing is out of sync on the different arches: Then any arch "
+"might just upgrade to the version of the source package; however, this can "
+"happen only if the package was previously forced through, the arch is in "
+"fuckedarches, or there was no binary package of that arch present in "
+"unstable at all during the testing migration."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2424
+msgid ""
+"In summary this means: The only influence that a package being in testing "
+"has on a new version of the same package is that the new version might go in "
+"easier."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:2431
+msgid "details"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2433
+msgid "If you are interested in details, this is how britney works:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2436
+msgid ""
+"The packages are looked at to determine whether they are valid candidates. "
+"This gives the update excuses. The most common reasons why a package is not "
+"considered are too young, RC-bugginess, and out of date on some arches. For "
+"this part of britney, the release managers have hammers of various sizes to "
+"force britney to consider a package. (Also, the base freeze is coded in "
+"that part of britney.) (There is a similar thing for binary-only updates, "
+"but this is not described here. If you're interested in that, please peruse "
+"the code.)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2445
+msgid ""
+"Now, the more complex part happens: Britney tries to update testing with the "
+"valid candidates; first, each package alone, and then larger and even larger "
+"sets of packages together. Each try is accepted if testing is not more "
+"uninstallable after the update than before. (Before and after this part, "
+"some hints are processed; but as only release masters can hint, this is "
+"probably not so important for you.)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2453
+msgid ""
+"If you want to see more details, you can look it up on merkel:/org/&ftp-"
+"debian-org;/testing/update_out/ (or there in ~aba/testing/update_out to see "
+"a setup with a smaller packages file). Via web, it's at <ulink url=\"http://"
+"&ftp-master-host;/testing/update_out_code/\"></ulink>"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2460
+msgid ""
+"The hints are available via <ulink url=\"http://&ftp-master-host;/testing/"
+"hints/\"></ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:2468
+msgid "Direct updates to testing"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2470
+msgid ""
+"The testing distribution is fed with packages from unstable according to the "
+"rules explained above. However, in some cases, it is necessary to upload "
+"packages built only for testing. For that, you may want to upload to "
+"<emphasis>testing-proposed-updates</emphasis>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2476
+msgid ""
+"Keep in mind that packages uploaded there are not automatically processed, "
+"they have to go through the hands of the release manager. So you'd better "
+"have a good reason to upload there. In order to know what a good reason is "
+"in the release managers' eyes, you should read the instructions that they "
+"regularly give on &email-debian-devel-announce;."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2483
+msgid ""
+"You should not upload to <emphasis>testing-proposed-updates</emphasis> when "
+"you can update your packages through <emphasis>unstable</emphasis>. If you "
+"can't (for example because you have a newer development version in "
+"unstable), you may use this facility, but it is recommended that you ask for "
+"authorization from the release manager first. Even if a package is frozen, "
+"updates through unstable are possible, if the upload via unstable does not "
+"pull in any new dependencies."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2492
+msgid ""
+"Version numbers are usually selected by adding the codename of the testing "
+"distribution and a running number, like 1.2sarge1 for the first upload "
+"through testing-proposed-updates of package version 1.2."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2497
+msgid "Please make sure you didn't miss any of these items in your upload:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2502
+msgid ""
+"Make sure that your package really needs to go through <emphasis>testing-"
+"proposed-updates</emphasis>, and can't go through unstable;"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2508
+msgid "Make sure that you included only the minimal amount of changes;"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2513
+msgid ""
+"Make sure that you included an appropriate explanation in the changelog;"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2518
+msgid ""
+"Make sure that you've written <emphasis>testing</emphasis> or "
+"<emphasis>testing-proposed-updates</emphasis> into your target distribution;"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2524
+msgid ""
+"Make sure that you've built and tested your package in <emphasis>testing</"
+"emphasis>, not in <emphasis>unstable</emphasis>;"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2530
+msgid ""
+"Make sure that your version number is higher than the version in "
+"<emphasis>testing</emphasis> and <emphasis>testing-proposed-updates</"
+"emphasis>, and lower than in <emphasis>unstable</emphasis>;"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2537
+msgid ""
+"After uploading and successful build on all platforms, contact the release "
+"team at &email-debian-release; and ask them to approve your upload."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:2545
+msgid "Frequently asked questions"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:2547
+msgid "What are release-critical bugs, and how do they get counted?"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2549
+msgid ""
+"All bugs of some higher severities are by default considered release-"
+"critical; currently, these are critical, grave, and serious bugs."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2553
+msgid ""
+"Such bugs are presumed to have an impact on the chances that the package "
+"will be released with the stable release of Debian: in general, if a package "
+"has open release-critical bugs filed on it, it won't get into testing, and "
+"consequently won't be released in stable."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2559
+msgid ""
+"The unstable bug count are all release-critical bugs without either any "
+"release-tag (such as potato, woody) or with release-tag sid; also, only if "
+"they are neither fixed nor set to sarge-ignore. The testing bug count for a "
+"package is considered to be roughly the bug count of unstable count at the "
+"last point when the testing version equalled the unstable version."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2566
+msgid ""
+"This will change post-sarge, as soon as we have versions in the bug tracking "
+"system."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:2572
+msgid ""
+"How could installing a package into testing possibly break other packages?"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2574
+msgid ""
+"The structure of the distribution archives is such that they can only "
+"contain one version of a package; a package is defined by its name. So when "
+"the source package acmefoo is installed into testing, along with its binary "
+"packages acme-foo-bin, acme-bar-bin, libacme-foo1 and libacme-foo-dev, the "
+"old version is removed."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2581
+msgid ""
+"However, the old version may have provided a binary package with an old "
+"soname of a library, such as libacme-foo0. Removing the old acmefoo will "
+"remove libacme-foo0, which will break any packages which depend on it."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2586
+msgid ""
+"Evidently, this mainly affects packages which provide changing sets of "
+"binary packages in different versions (in turn, mainly libraries). However, "
+"it will also affect packages upon which versioned dependencies have been "
+"declared of the ==, <=, or << varieties."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2592
+msgid ""
+"When the set of binary packages provided by a source package change in this "
+"way, all the packages that depended on the old binaries will have to be "
+"updated to depend on the new binaries instead. Because installing such a "
+"source package into testing breaks all the packages that depended on it in "
+"testing, some care has to be taken now: all the depending packages must be "
+"updated and ready to be installed themselves so that they won't be broken, "
+"and, once everything is ready, manual intervention by the release manager or "
+"an assistant is normally required."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2602
+msgid ""
+"If you are having problems with complicated groups of packages like this, "
+"contact debian-devel or debian-release for help."
+msgstr ""
+
--- /dev/null
+# SOME DESCRIPTIVE TITLE
+# Copyright (C) 2007 Free Software Foundation, Inc.
+# <>, 2007.
+# , fuzzy
+#
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: PACKAGE VERSION\n"
+"Report-Msgid-Bugs-To: \n"
+"POT-Creation-Date: 2007-07-01 21:16+0000\n"
+"PO-Revision-Date: 2007-07-01 23:16+0000\n"
+"Last-Translator: <>\n"
+"Language-Team: \n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: "
+
+# type: Content of: <chapter><title>
+#: resources.dbk:7
+msgid "Resources for Debian Developers"
+msgstr "Ressources pour le responsable Debian"
+
+# type: Content of: <chapter><para>
+#: resources.dbk:9
+msgid ""
+"In this chapter you will find a very brief road map of the Debian mailing "
+"lists, the Debian machines which may be available to you as a developer, and "
+"all the other resources that are available to help you in your maintainer "
+"work."
+msgstr "Dans ce chapitre, vous trouverez une brève description des listes de"
+"diffusion, des machines Debian qui seront à votre disposition en tant"
+"que responsable Debian ainsi que toutes les autres ressources à votre"
+"disposition pour vous aider dans votre travail de responsable."
+
+# type: Content of: <chapter><section><title>
+#: resources.dbk:14
+msgid "Mailing lists"
+msgstr "Les listes de diffusion"
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:16
+msgid ""
+"Much of the conversation between Debian developers (and users) is managed "
+"through a wide array of mailing lists we host at <literal><ulink url="
+"\"http://&lists-host;/\">&lists-host;</ulink></literal>. 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 <ulink url=\"&url-debian-lists;\"></ulink>. This section will "
+"only cover aspects of mailing lists that are of particular interest to "
+"developers."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:27
+msgid "Basic rules for use"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:29
+msgid ""
+"When replying to messages on the mailing list, please do not send a carbon "
+"copy (<literal>CC</literal>) 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."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:35
+msgid ""
+"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."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:40
+msgid ""
+"Please read the <ulink url=\"&url-debian-lists;#codeofconduct\">code of "
+"conduct</ulink> for more information."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:47
+msgid "Core development mailing lists"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:49
+msgid "The core Debian mailing lists that developers should use are:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: resources.dbk:54
+msgid ""
+"&email-debian-devel-announce;, used to announce important things to "
+"developers. All developers are expected to be subscribed to this list."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: resources.dbk:61
+msgid ""
+"&email-debian-devel;, used to discuss various development related technical "
+"issues."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: resources.dbk:67
+msgid ""
+"&email-debian-policy;, where the Debian Policy is discussed and voted on."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: resources.dbk:73
+msgid ""
+"&email-debian-project;, used to discuss various non-technical issues related "
+"to the project."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:79
+msgid ""
+"There are other mailing lists available for a variety of special topics; see "
+"<ulink url=\"http://&lists-host;/\"></ulink> for a list."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:85
+msgid "Special lists"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:87
+msgid ""
+"&email-debian-private; is a special mailing list for private discussions "
+"amongst Debian developers. It is meant to be used for posts which for "
+"whatever reason should not be published publicly. As such, it is a low "
+"volume list, and users are urged not to use &email-debian-private; unless it "
+"is really necessary. Moreover, do <emphasis>not</emphasis> forward email "
+"from that list to anyone. Archives of this list are not available on the "
+"web for obvious reasons, but you can see them using your shell account on "
+"<literal>&lists-host;</literal> and looking in the <filename>&file-debian-"
+"private-archive;</filename> directory."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:99
+msgid ""
+"&email-debian-email; is a special mailing list used as a grab-bag 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."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:107
+msgid "Requesting new development-related lists"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:109
+msgid ""
+"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 <replaceable>you-aliasname@debian.org</replaceable> "
+"address) or a self-managed mailing list on <link linkend=\"alioth\">Alioth</"
+"link> is more appropriate."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:117
+msgid ""
+"If you decide that a regular mailing list on &lists-host; is really what you "
+"want, go ahead and fill in a request, following <ulink url=\"&url-debian-"
+"lists-new;\">the HOWTO</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: resources.dbk:126
+msgid "IRC channels"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:128
+msgid ""
+"Several IRC channels are dedicated to Debian's development. They are mainly "
+"hosted on the <ulink url=\"&url-oftc;\">Open and free technology community "
+"(OFTC)</ulink> network. The <literal>irc.debian.org</literal> DNS entry is "
+"an alias to <literal>irc.oftc.net</literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:134
+msgid ""
+"The main channel for Debian in general is <emphasis>#debian</emphasis>. "
+"This is a large, general-purpose channel where users can find recent news in "
+"the topic and served by bots. <emphasis>#debian</emphasis> is for English "
+"speakers; there are also <emphasis>#debian.de</emphasis>, <emphasis>#debian-"
+"fr</emphasis>, <emphasis>#debian-br</emphasis> and other similarly named "
+"channels for speakers of other languages."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:142
+msgid ""
+"The main channel for Debian development is <emphasis>#debian-devel</"
+"emphasis>. It is a very active channel since usually over 150 people are "
+"always logged in. It's a channel for people who work on Debian, it's not a "
+"support channel (there's <emphasis>#debian</emphasis> for that). It is "
+"however open to anyone who wants to lurk (and learn). Its topic is commonly "
+"full of interesting information for developers."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:150
+msgid ""
+"Since <emphasis>#debian-devel</emphasis> is an open channel, you should not "
+"speak there of issues that are discussed in &email-debian-private;. There's "
+"another channel for this purpose, it's called <emphasis>#debian-private</"
+"emphasis> and it's protected by a key. This key is available in the "
+"archives of debian-private in <filename>master.debian.org:&file-debian-"
+"private-archive;</filename>, just <command>zgrep</command> for "
+"<emphasis>#debian-private</emphasis> in all the files."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:160
+msgid ""
+"There are other additional channels dedicated to specific subjects. "
+"<emphasis>#debian-bugs</emphasis> is used for coordinating bug squashing "
+"parties. <emphasis>#debian-boot</emphasis> is used to coordinate the work "
+"on the debian-installer. <emphasis>#debian-doc</emphasis> is occasionally "
+"used to talk about documentation, like the document you are reading. Other "
+"channels are dedicated to an architecture or a set of packages: "
+"<emphasis>#debian-bsd</emphasis>, <emphasis>#debian-kde</emphasis>, "
+"<emphasis>#debian-jr</emphasis>, <emphasis>#debian-edu</emphasis>, "
+"<emphasis>#debian-sf</emphasis> (SourceForge package), <emphasis>#debian-oo</"
+"emphasis> (OpenOffice package) ..."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:172
+msgid ""
+"Some non-English developers' channels exist as well, for example "
+"<emphasis>#debian-devel-fr</emphasis> for French speaking people interested "
+"in Debian's development."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:177
+msgid ""
+"Channels dedicated to Debian also exist on other IRC networks, notably on "
+"the <ulink url=\"&url-openprojects;\">freenode</ulink> IRC network, which "
+"was pointed at by the <literal>irc.debian.org</literal> alias until 4th June "
+"2006."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:183
+msgid ""
+"To get a cloak on freenode, you send Jörg Jaspert <joerg@debian.org> a "
+"signed mail where you tell what your nick is. Put cloak somewhere in the "
+"Subject: header. The nick should be registered: <ulink url=\"http://"
+"freenode.net/faq.shtml#nicksetup\">Nick Setup Page</ulink>. The mail needs "
+"to be signed by a key in the Debian keyring. Please see <ulink url=\"http://"
+"freenode.net/faq.shtml#projectcloak\">Freenodes documentation</ulink> for "
+"more information about cloaks."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: resources.dbk:194
+msgid "Documentation"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:196
+msgid ""
+"This document contains a lot of information which is useful to Debian "
+"developers, but it cannot contain everything. Most of the other interesting "
+"documents are linked from <ulink url=\"&url-devel-docs;\">The Developers' "
+"Corner</ulink>. Take the time to browse all the links, you will learn many "
+"more things."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: resources.dbk:205
+msgid "Debian machines"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:207
+msgid ""
+"Debian has several computers working as servers, most of which serve "
+"critical functions in the Debian project. Most of the machines are used for "
+"porting activities, and they all have a permanent connection to the Internet."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:212
+msgid ""
+"Most of the machines are available for individual developers to use, as long "
+"as the developers follow the rules set forth in the <ulink url=\"&url-dmup;"
+"\">Debian Machine Usage Policies</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:217
+msgid ""
+"Generally speaking, you can use these machines for Debian-related purposes "
+"as you see fit. Please be kind to system administrators, and do not use up "
+"tons and tons of disk space, network bandwidth, or CPU without first getting "
+"the approval of the system administrators. Usually these machines are run "
+"by volunteers."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:224
+msgid ""
+"Please take care to protect your Debian passwords and SSH keys installed on "
+"Debian machines. Avoid login or upload methods which send passwords over "
+"the Internet in the clear, such as telnet, FTP, POP etc."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:229
+msgid ""
+"Please do not put any material that doesn't relate to Debian on the Debian "
+"servers, unless you have prior permission."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:233
+msgid ""
+"The current list of Debian machines is available at <ulink url=\"&url-devel-"
+"machines;\"></ulink>. That web page contains machine names, contact "
+"information, information about who can log in, SSH keys etc."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:239
+msgid ""
+"If you have a problem with the operation of a Debian server, and you think "
+"that the system operators need to be notified of this problem, the Debian "
+"system administrator team is reachable at <email>debian-admin@&lists-host;</"
+"email>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:245
+msgid ""
+"If you have a problem with a certain service, not related to the system "
+"administration (such as packages to be removed from the archive, suggestions "
+"for the web site, etc.), generally you'll report a bug against a ``pseudo-"
+"package''. See <xref linkend=\"submit-bug\"/> for information on how to "
+"submit bugs."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:252
+msgid ""
+"Some of the core servers are restricted, but the information from there is "
+"mirrored to another server."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:256
+msgid "The bugs server"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:258
+msgid ""
+"<literal>&bugs-host;</literal> is the canonical location for the Bug "
+"Tracking System (BTS)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:262 resources.dbk:280
+msgid "It is restricted; a mirror is available on <literal>merkel</literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:265
+msgid ""
+"If you plan on doing some statistical analysis or processing of Debian bugs, "
+"this would be the place to do it. Please describe your plans on &email-"
+"debian-devel; before implementing anything, however, to reduce unnecessary "
+"duplication of effort or wasted processing time."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:273
+msgid "The ftp-master server"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:275
+msgid ""
+"The <literal>&ftp-master-host;</literal> server holds the canonical copy of "
+"the Debian archive (excluding the non-US packages). Generally, package "
+"uploads go to this server; see <xref linkend=\"upload\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:283
+msgid ""
+"Problems with the Debian FTP archive generally need to be reported as bugs "
+"against the <systemitem role=\"package\">&ftp-debian-org;</systemitem> "
+"pseudo-package or an email to &email-ftpmaster;, but also see the procedures "
+"in <xref linkend=\"archive-manip\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:291
+msgid "The non-US server"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:293
+msgid ""
+"The non-US server <literal>&non-us-host;</literal> was discontinued with the "
+"release of sarge. The pseudo-package <systemitem role=\"package\">nonus."
+"debian.org</systemitem> still exists for now."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:300
+msgid "The www-master server"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:302
+msgid ""
+"The main web server is <literal>www-master.debian.org</literal>. It holds "
+"the official web pages, the face of Debian for most newbies."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:306
+msgid ""
+"If you find a problem with the Debian web server, you should generally "
+"submit a bug against the pseudo-package, <systemitem role=\"package\">www."
+"debian.org</systemitem>. Remember to check whether or not someone else has "
+"already reported the problem to the <ulink url=\"http://&bugs-host;/&www-"
+"debian-org;\">Bug Tracking System</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:315
+msgid "The people web server"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:317
+msgid ""
+"<literal>people.debian.org</literal> is the server used for developers' own "
+"web pages about anything related to Debian."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:321
+msgid ""
+"If you have some Debian-specific information which you want to serve on the "
+"web, you can do this by putting material in the <filename>public_html</"
+"filename> directory under your home directory on <literal>people.debian.org</"
+"literal>. This will be accessible at the URL <literal>http://people.debian."
+"org/~<replaceable>your-user-id</replaceable>/</literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:328
+msgid ""
+"You should only use this particular location because it will be backed up, "
+"whereas on other hosts it won't."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:332
+msgid ""
+"Usually the only reason to use a different host is when you need to publish "
+"materials subject to the U.S. export restrictions, in which case you can "
+"use one of the other servers located outside the United States."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:337
+msgid "Send mail to &email-debian-devel; if you have any questions."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:342
+msgid "The CVS server"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:345
+msgid "Our CVS server is located on <literal>cvs.debian.org</literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:348
+msgid ""
+"If you need to use a publicly accessible CVS server, for instance, to help "
+"coordinate work on a package between many different developers, you can "
+"request a CVS area on the server."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:353
+msgid ""
+"Generally, <literal>cvs.debian.org</literal> offers a combination of local "
+"CVS access, anonymous client-server read-only access, and full client-server "
+"access through <command>ssh</command>. Also, the CVS area can be accessed "
+"read-only via the Web at <ulink url=\"&url-cvsweb;\"></ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:359
+msgid ""
+"To request a CVS area, send a request via email to &email-debian-admin;. "
+"Include the name of the requested CVS area, the Debian account that should "
+"own the CVS root area, and why you need it."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:367
+msgid "chroots to different distributions"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:369
+msgid ""
+"On some machines, there are chroots to different distributions available. "
+"You can use them like this:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: resources.dbk:373
+#, no-wrap
+msgid ""
+"vore$ dchroot unstable\n"
+"Executing shell in chroot: /org/vore.debian.org/chroots/user/unstable"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:377
+msgid ""
+"In all chroots, the normal user home directories are available. You can "
+"find out which chroots are available via <literal>&url-devel-machines;</"
+"literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: resources.dbk:386
+msgid "The Developers Database"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:388
+msgid ""
+"The Developers Database, at <ulink url=\"&url-debian-db;\"></ulink>, is an "
+"LDAP directory for managing Debian developer attributes. You can use this "
+"resource to search the list of Debian developers. Part of this information "
+"is also available through the finger service on Debian servers, try "
+"<command>finger yourlogin@db.debian.org</command> to see what it reports."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:396
+msgid ""
+"Developers can <ulink url=\"&url-debian-db-login;\">log into the database</"
+"ulink> to change various information about themselves, such as:"
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: resources.dbk:402
+msgid "forwarding address for your debian.org email"
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: resources.dbk:407
+msgid "subscription to debian-private"
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: resources.dbk:412
+msgid "whether you are on vacation"
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: resources.dbk:417
+msgid ""
+"personal information such as your address, country, the latitude and "
+"longitude of the place where you live for use in <ulink url=\"&url-worldmap;"
+"\">the world map of Debian developers</ulink>, phone and fax numbers, IRC "
+"nickname and web page"
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: resources.dbk:425
+msgid "password and preferred shell on Debian Project machines"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:430
+msgid ""
+"Most of the information is not accessible to the public, naturally. For "
+"more information please read the online documentation that you can find at "
+"<ulink url=\"&url-debian-db-doc;\"></ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:435
+msgid ""
+"Developers can also submit their SSH keys to be used for authorization on "
+"the official Debian machines, and even add new *.debian.net DNS entries. "
+"Those features are documented at <ulink url=\"&url-debian-db-mail-gw;\"></"
+"ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: resources.dbk:443
+msgid "The Debian archive"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:445
+msgid ""
+"The &debian-formal; distribution consists of a lot of packages (<filename>."
+"deb</filename>'s, currently around &number-of-pkgs;) and a few additional "
+"files (such as documentation and installation disk images)."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:451
+msgid "Here is an example directory tree of a complete Debian archive:"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:455
+msgid ""
+"As you can see, the top-level directory contains two directories, "
+"<filename>dists/</filename> and <filename>pool/</filename>. The latter is a "
+"“pool” in which the packages actually are, and which is handled by the "
+"archive maintenance database and the accompanying programs. The former "
+"contains the distributions, <emphasis>stable</emphasis>, <emphasis>testing</"
+"emphasis> and <emphasis>unstable</emphasis>. The <filename>Packages</"
+"filename> and <filename>Sources</filename> files in the distribution "
+"subdirectories can reference files in the <filename>pool/</filename> "
+"directory. The directory tree below each of the distributions is arranged "
+"in an identical manner. What we describe below for <emphasis>stable</"
+"emphasis> is equally applicable to the <emphasis>unstable</emphasis> and "
+"<emphasis>testing</emphasis> distributions."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:469
+msgid ""
+"<filename>dists/stable</filename> contains three directories, namely "
+"<filename>main</filename>, <filename>contrib</filename>, and <filename>non-"
+"free</filename>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:474
+msgid ""
+"In each of the areas, there is a directory for the source packages "
+"(<filename>source</filename>) and a directory for each supported "
+"architecture (<filename>binary-i386</filename>, <filename>binary-m68k</"
+"filename>, etc.)."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:479
+msgid ""
+"The <filename>main</filename> 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 "
+"(<filename>disks-i386</filename>, <filename>disks-m68k</filename>, etc.)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:485
+msgid "Sections"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:487
+msgid ""
+"The <emphasis>main</emphasis> section of the Debian archive is what makes up "
+"the <emphasis role=\"strong\">official &debian-formal; distribution</"
+"emphasis>. The <emphasis>main</emphasis> section is official because it "
+"fully complies with all our guidelines. The other two sections do not, to "
+"different degrees; as such, they are <emphasis role=\"strong\">not</"
+"emphasis> officially part of &debian-formal;."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:495
+msgid ""
+"Every package in the main section must fully comply with the <ulink url="
+"\"&url-dfsg;\">Debian Free Software Guidelines</ulink> (DFSG) and with all "
+"other policy requirements as described in the <ulink url=\"&url-debian-"
+"policy;\">Debian Policy Manual</ulink>. The DFSG is our definition of “free "
+"software.” Check out the Debian Policy Manual for details."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:503
+msgid ""
+"Packages in the <emphasis>contrib</emphasis> section have to comply with the "
+"DFSG, but may fail other requirements. For instance, they may depend on non-"
+"free packages."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:508
+msgid ""
+"Packages which do not conform to the DFSG are placed in the <emphasis>non-"
+"free</emphasis> section. These packages are not considered as part of the "
+"Debian distribution, though we support their use, and we provide "
+"infrastructure (such as our bug-tracking system and mailing lists) for non-"
+"free software packages."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:515
+msgid ""
+"The <ulink url=\"&url-debian-policy;\">Debian Policy Manual</ulink> contains "
+"a more exact definition of the three sections. The above discussion is just "
+"an introduction."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:520
+msgid ""
+"The separation of the three sections at the top-level of the archive is "
+"important for all people who want to distribute Debian, either via FTP "
+"servers on the Internet or on CD-ROMs: by distributing only the "
+"<emphasis>main</emphasis> and <emphasis>contrib</emphasis> sections, one can "
+"avoid any legal risks. Some packages in the <emphasis>non-free</emphasis> "
+"section do not allow commercial distribution, for example."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:528
+msgid ""
+"On the other hand, a CD-ROM vendor could easily check the individual package "
+"licenses of the packages in <emphasis>non-free</emphasis> and include as "
+"many on the CD-ROMs as it's allowed to. (Since this varies greatly from "
+"vendor to vendor, this job can't be done by the Debian developers.)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:534
+msgid ""
+"Note that the term section is also used to refer to categories which "
+"simplify the organization and browsing of available packages, e.g. "
+"<emphasis>admin</emphasis>, <emphasis>net</emphasis>, <emphasis>utils</"
+"emphasis> etc. Once upon a time, these sections (subsections, rather) "
+"existed in the form of subdirectories within the Debian archive. Nowadays, "
+"these exist only in the Section header fields of packages."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:544
+msgid "Architectures"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:546
+msgid ""
+"In the first days, the Linux kernel was only available for Intel i386 (or "
+"greater) platforms, and so was Debian. But as Linux became more and more "
+"popular, the kernel was ported to other architectures, too."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:551
+msgid ""
+"The Linux 2.0 kernel supports Intel x86, DEC Alpha, SPARC, Motorola 680x0 "
+"(like Atari, Amiga and Macintoshes), MIPS, and PowerPC. The 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 kernels. Aside from <emphasis>i386</emphasis> (our name for "
+"Intel x86), there is <emphasis>m68k</emphasis>, <emphasis>alpha</emphasis>, "
+"<emphasis>powerpc</emphasis>, <emphasis>sparc</emphasis>, <emphasis>hurd-"
+"i386</emphasis>, <emphasis>arm</emphasis>, <emphasis>ia64</emphasis>, "
+"<emphasis>hppa</emphasis>, <emphasis>s390</emphasis>, <emphasis>mips</"
+"emphasis>, <emphasis>mipsel</emphasis> and <emphasis>sh</emphasis> as of "
+"this writing."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:565
+msgid ""
+"&debian-formal; 1.3 is only available as <emphasis>i386</emphasis>. Debian "
+"2.0 shipped for <emphasis>i386</emphasis> and <emphasis>m68k</emphasis> "
+"architectures. Debian 2.1 ships for the <emphasis>i386</emphasis>, "
+"<emphasis>m68k</emphasis>, <emphasis>alpha</emphasis>, and <emphasis>sparc</"
+"emphasis> architectures. Debian 2.2 added support for the "
+"<emphasis>powerpc</emphasis> and <emphasis>arm</emphasis> architectures. "
+"Debian 3.0 added support of five new architectures: <emphasis>ia64</"
+"emphasis>, <emphasis>hppa</emphasis>, <emphasis>s390</emphasis>, "
+"<emphasis>mips</emphasis> and <emphasis>mipsel</emphasis>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:576
+msgid ""
+"Information for developers and users about the specific ports are available "
+"at the <ulink url=\"&url-debian-ports;\">Debian Ports web pages</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:582
+msgid "Packages"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:584
+msgid ""
+"There are two types of Debian packages, namely <emphasis>source</emphasis> "
+"and <emphasis>binary</emphasis> packages."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:588
+msgid ""
+"Source packages consist of either two or three files: a <filename>.dsc</"
+"filename> file, and either a <filename>.tar.gz</filename> file or both an "
+"<filename>.orig.tar.gz</filename> and a <filename>.diff.gz</filename> file."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:594
+msgid ""
+"If a package is developed specially for Debian and is not distributed "
+"outside of Debian, there is just one <filename>.tar.gz</filename> file which "
+"contains the sources of the program. If a package is distributed elsewhere "
+"too, the <filename>.orig.tar.gz</filename> file stores the so-called "
+"<emphasis>upstream source code</emphasis>, that is the source code that's "
+"distributed by the <emphasis>upstream maintainer</emphasis> (often the "
+"author of the software). In this case, the <filename>.diff.gz</filename> "
+"contains the changes made by the Debian maintainer."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:604
+msgid ""
+"The <filename>.dsc</filename> file lists all the files in the source package "
+"together with checksums (<command>md5sums</command>) and some additional "
+"info about the package (maintainer, version, etc.)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:611
+msgid "Distributions"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:613
+msgid ""
+"The directory system described in the previous chapter is itself contained "
+"within <emphasis>distribution directories</emphasis>. Each distribution is "
+"actually contained in the <filename>pool</filename> directory in the top-"
+"level of the Debian archive itself."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:619
+msgid ""
+"To summarize, the Debian archive has a root directory within an FTP server. "
+"For instance, at the mirror site, <literal>ftp.us.debian.org</literal>, the "
+"Debian archive itself is contained in <ulink url=\"ftp://ftp.us.debian.org/"
+"debian\">/debian</ulink>, which is a common location (another is <filename>/"
+"pub/debian</filename>)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:626
+msgid ""
+"A distribution comprises Debian source and binary packages, and the "
+"respective <filename>Sources</filename> and <filename>Packages</filename> "
+"index files, containing the header information from all those packages. The "
+"former are kept in the <filename>pool/</filename> directory, while the "
+"latter are kept in the <filename>dists/</filename> directory of the archive "
+"(for backwards compatibility)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: resources.dbk:634
+msgid "Stable, testing, and unstable"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: resources.dbk:636
+msgid ""
+"There are always distributions called <emphasis>stable</emphasis> (residing "
+"in <filename>dists/stable</filename>), <emphasis>testing</emphasis> "
+"(residing in <filename>dists/testing</filename>), and <emphasis>unstable</"
+"emphasis> (residing in <filename>dists/unstable</filename>). This reflects "
+"the development process of the Debian project."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: resources.dbk:643
+msgid ""
+"Active development is done in the <emphasis>unstable</emphasis> distribution "
+"(that's why this distribution is sometimes called the <emphasis>development "
+"distribution</emphasis>). Every Debian developer can update his or her "
+"packages in this distribution at any time. Thus, the contents of this "
+"distribution change from day to day. Since no special effort is made to "
+"make sure everything in this distribution is working properly, it is "
+"sometimes literally unstable."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: resources.dbk:652
+msgid ""
+"The <link linkend=\"testing\">testing</link> distribution 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. See <xref linkend=\"testing\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: resources.dbk:659
+msgid ""
+"After a period of development, once the release manager deems fit, the "
+"<emphasis>testing</emphasis> distribution is frozen, meaning that the "
+"policies which control how packages move from <emphasis>unstable</emphasis> "
+"to <emphasis>testing</emphasis> are tightened. Packages which are too buggy "
+"are removed. No changes are allowed into <emphasis>testing</emphasis> "
+"except for bug fixes. After some time has elapsed, depending on progress, "
+"the <emphasis>testing</emphasis> distribution is frozen even further. "
+"Details of the handling of the testing distribution are published by the "
+"Release Team on debian-devel-announce. After the open issues are solved to "
+"the satisfaction of the Release Team, the distribution is released. "
+"Releasing means that <emphasis>testing</emphasis> is renamed to "
+"<emphasis>stable</emphasis>, and a new copy is created for the new "
+"<emphasis>testing</emphasis>, and the previous <emphasis>stable</emphasis> "
+"is renamed to <emphasis>oldstable</emphasis> and stays there until it is "
+"finally archived. On archiving, the contents are moved to <literal>&archive-"
+"host;</literal>)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: resources.dbk:676
+msgid ""
+"This development cycle is based on the assumption that the "
+"<emphasis>unstable</emphasis> distribution becomes <emphasis>stable</"
+"emphasis> after passing a period of being in <emphasis>testing</emphasis>. "
+"Even once a distribution is considered stable, a few bugs inevitably remain "
+"— that's why the stable distribution is updated every now and then. "
+"However, these updates are tested very carefully and have to be introduced "
+"into the archive individually to reduce the risk of introducing new bugs. "
+"You can find proposed additions to <emphasis>stable</emphasis> in the "
+"<filename>proposed-updates</filename> directory. Those packages in "
+"<filename>proposed-updates</filename> that pass muster are periodically "
+"moved as a batch into the stable distribution and the revision level of the "
+"stable distribution is incremented (e.g., ‘3.0’ becomes ‘3.0r1’, ‘2.2r4’ "
+"becomes ‘2.2r5’, and so forth). Please refer to <link linkend=\"upload-"
+"stable\">uploads to the <emphasis>stable</emphasis> distribution</link> for "
+"details."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: resources.dbk:693
+msgid ""
+"Note that development under <emphasis>unstable</emphasis> continues during "
+"the freeze period, since the <emphasis>unstable</emphasis> distribution "
+"remains in place in parallel with <emphasis>testing</emphasis>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: resources.dbk:700
+msgid "More information about the testing distribution"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: resources.dbk:702
+msgid ""
+"Packages are usually installed into the `testing' distribution after they "
+"have undergone some degree of testing in unstable."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: resources.dbk:706
+msgid ""
+"For more details, please see the <link linkend=\"testing\">information about "
+"the testing distribution</link>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: resources.dbk:712
+msgid "Experimental"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: resources.dbk:714
+msgid ""
+"The <emphasis>experimental</emphasis> distribution is a special "
+"distribution. It is not a full distribution in the same sense as `stable' "
+"and `unstable' are. Instead, it is meant to be a temporary staging area for "
+"highly experimental software where there's a good chance that the software "
+"could break your system, or software that's just too unstable even for the "
+"<emphasis>unstable</emphasis> distribution (but there is a reason to package "
+"it nevertheless). Users who download and install packages from "
+"<emphasis>experimental</emphasis> are expected to have been duly warned. In "
+"short, all bets are off for the <emphasis>experimental</emphasis> "
+"distribution."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: resources.dbk:725
+msgid ""
+"These are the <citerefentry> <refentrytitle>sources.list</refentrytitle> "
+"<manvolnum>5</manvolnum> </citerefentry> lines for <emphasis>experimental</"
+"emphasis>:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><programlisting>
+#: resources.dbk:730
+#, no-wrap
+msgid ""
+"deb http://ftp.<replaceable>xy</replaceable>.debian.org/debian/ experimental main\n"
+"deb-src http://ftp.<replaceable>xy</replaceable>.debian.org/debian/ experimental main"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: resources.dbk:734
+msgid ""
+"If there is a chance that the software could do grave damage to a system, it "
+"is likely to be better to put it into <emphasis>experimental</emphasis>. "
+"For instance, an experimental compressed file system should probably go into "
+"<emphasis>experimental</emphasis>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: resources.dbk:740
+msgid ""
+"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 <emphasis>experimental</emphasis>. A new, beta, version of "
+"some software which uses a completely different configuration can go into "
+"<emphasis>experimental</emphasis>, at the maintainer's discretion. If you "
+"are working on an incompatible or complex upgrade situation, you can also "
+"use <emphasis>experimental</emphasis> as a staging area, so that testers can "
+"get early access."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: resources.dbk:750
+msgid ""
+"Some experimental software can still go into <emphasis>unstable</emphasis>, "
+"with a few warnings in the description, but that isn't recommended because "
+"packages from <emphasis>unstable</emphasis> are expected to propagate to "
+"<emphasis>testing</emphasis> and thus to <emphasis>stable</emphasis>. You "
+"should not be afraid to use <emphasis>experimental</emphasis> since it does "
+"not cause any pain to the ftpmasters, the experimental packages are "
+"automatically removed once you upload the package in <emphasis>unstable</"
+"emphasis> with a higher version number."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: resources.dbk:760
+msgid ""
+"New software which isn't likely to damage your system can go directly into "
+"<emphasis>unstable</emphasis>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: resources.dbk:764
+msgid ""
+"An alternative to <emphasis>experimental</emphasis> is to use your personal "
+"web space on <literal>people.debian.org</literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: resources.dbk:768
+msgid ""
+"When uploading to unstable a package which had bugs fixed in experimental, "
+"please consider using the option <literal>-v</literal> to <command>dpkg-"
+"buildpackage</command> to finally get them closed."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:777
+msgid "Release code names"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:779
+msgid ""
+"Every released Debian distribution has a <emphasis>code name</emphasis>: "
+"Debian 1.1 is called `buzz'; Debian 1.2, `rex'; Debian 1.3, `bo'; Debian "
+"2.0, `hamm'; Debian 2.1, `slink'; Debian 2.2, `potato'; Debian 3.0, `woody'; "
+"Debian 3.1, sarge; Debian 4.0, etch. There is also a ``pseudo-"
+"distribution'', called `sid', which is the current `unstable' distribution; "
+"since packages are moved from `unstable' to `testing' as they approach "
+"stability, `sid' itself is never released. As well as the usual contents of "
+"a Debian distribution, `sid' contains packages for architectures which are "
+"not yet officially supported or released by Debian. These architectures are "
+"planned to be integrated into the mainstream distribution at some future "
+"date."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:791
+msgid ""
+"Since Debian has an open development model (i.e., everyone can participate "
+"and follow the development) even the `unstable' and `testing' distributions "
+"are distributed to the Internet through the Debian FTP and HTTP server "
+"network. Thus, if we had called the directory which contains the release "
+"candidate version `testing', then we would have to rename it to `stable' "
+"when the version is released, which would cause all FTP mirrors to re-"
+"retrieve the whole distribution (which is quite large)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:800
+msgid ""
+"On the other hand, if we called the distribution directories "
+"<emphasis>Debian-x.y</emphasis> from the beginning, people would think that "
+"Debian release <emphasis>x.y</emphasis> is available. (This happened in the "
+"past, where a CD-ROM vendor built a Debian 1.0 CD-ROM based on a pre-1.0 "
+"development version. That's the reason why the first official Debian "
+"release was 1.1, and not 1.0.)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:808
+msgid ""
+"Thus, the names of the distribution directories in the archive are "
+"determined by their code names and not their release status (e.g., "
+"`slink'). These names stay the same during the development period and after "
+"the release; symbolic links, which can be changed easily, indicate the "
+"currently released stable distribution. That's why the real distribution "
+"directories use the <emphasis>code names</emphasis>, while symbolic links "
+"for <emphasis>stable</emphasis>, <emphasis>testing</emphasis>, and "
+"<emphasis>unstable</emphasis> point to the appropriate release directories."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: resources.dbk:822
+msgid "Debian mirrors"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:824
+msgid ""
+"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 — 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. Note that the first tier of "
+"mirrors is as up-to-date as it can be since they update when triggered from "
+"the internal sites (we call this push mirroring)."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:835
+msgid ""
+"All the information on Debian mirrors, including a list of the available "
+"public FTP/HTTP servers, can be found at <ulink url=\"&url-debian-mirrors;"
+"\"></ulink>. This useful page also includes information and tools which can "
+"be helpful if you are interested in setting up your own mirror, either for "
+"internal or public access."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:842
+msgid ""
+"Note that mirrors are generally run by third-parties who are interested in "
+"helping Debian. As such, developers generally do not have accounts on these "
+"machines."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: resources.dbk:849
+msgid "The Incoming system"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:851
+msgid ""
+"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 on <literal>&ftp-master-host;</literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:856
+msgid ""
+"Packages are uploaded by all the maintainers into a directory called "
+"<filename>UploadQueue</filename>. This directory is scanned every few "
+"minutes by a daemon called <command>queued</command>, <filename>*.command</"
+"filename>-files are executed, and remaining and correctly signed <filename>*."
+"changes</filename>-files are moved together with their corresponding files "
+"to the <filename>unchecked</filename> directory. This directory is not "
+"visible for most Developers, as ftp-master is restricted; it is scanned "
+"every 15 minutes by the <command>katie</command> 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 "
+"<filename>accepted</filename> directory. If this is the first upload of the "
+"package (or it has new binary packages), it is moved to the <filename>new</"
+"filename> directory, where it waits for approval by the ftpmasters. If the "
+"package contains files to be installed by hand it is moved to the "
+"<filename>byhand</filename> directory, where it waits for manual "
+"installation by the ftpmasters. Otherwise, if any error has been detected, "
+"the package is refused and is moved to the <filename>reject</filename> "
+"directory."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:875
+msgid ""
+"Once the package is accepted, the system sends a confirmation mail to the "
+"maintainer and closes all the bugs marked as fixed by the upload, and the "
+"auto-builders may start recompiling it. The package is now publicly "
+"accessible at <ulink url=\"&url-incoming;\"></ulink> until it is really "
+"installed in the Debian archive. This happens only once a day (and is also "
+"called the `dinstall run' for historical reasons); the package is then "
+"removed from incoming and installed in the pool along with all the other "
+"packages. Once all the other updates (generating new <filename>Packages</"
+"filename> and <filename>Sources</filename> index files for example) have "
+"been made, a special script is called to ask all the primary mirrors to "
+"update themselves."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:887
+msgid ""
+"The archive maintenance software will also send the OpenPGP/GnuPG signed "
+"<filename>.changes</filename> file that you uploaded to the appropriate "
+"mailing lists. If a package is released with the <literal>Distribution:</"
+"literal> set to `stable', the announcement is sent to &email-debian-"
+"changes;. If a package is released with <literal>Distribution:</literal> "
+"set to `unstable' or `experimental', the announcement will be posted to "
+"&email-debian-devel-changes; instead."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:897
+msgid ""
+"Though ftp-master is restricted, a copy of the installation is available to "
+"all developers on <literal>&ftp-master-mirror;</literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: resources.dbk:960
+msgid "Package information"
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:962
+msgid "On the web"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:964
+msgid ""
+"Each package has several dedicated web pages. <literal>http://&packages-"
+"host;/<replaceable>package-name</replaceable></literal> displays each "
+"version of the package available in the various distributions. Each version "
+"links to a page which provides information, including the package "
+"description, the dependencies, and package download links."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:971
+msgid ""
+"The bug tracking system tracks bugs for each package. You can view the bugs "
+"of a given package at the URL <literal>http://&bugs-host;/"
+"<replaceable>package-name</replaceable></literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:978
+msgid "The <command>madison</command> utility"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:980
+msgid ""
+"<command>madison</command> is a command-line utility that is available on "
+"<literal>&ftp-master-host;</literal>, and on the mirror on <literal>&ftp-"
+"master-mirror;</literal>. It uses a single argument corresponding to a "
+"package name. In result it displays which version of the package is "
+"available for each architecture and distribution combination. An example "
+"will explain it better."
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: resources.dbk:988
+#, no-wrap
+msgid ""
+"$ madison libdbd-mysql-perl\n"
+"libdbd-mysql-perl | 1.2202-4 | stable | source, alpha, arm, i386, m68k, powerpc, sparc\n"
+"libdbd-mysql-perl | 1.2216-2 | testing | source, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc\n"
+"libdbd-mysql-perl | 1.2216-2.0.1 | testing | alpha\n"
+"libdbd-mysql-perl | 1.2219-1 | unstable | source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:995
+msgid ""
+"In this example, you can see that the version in <emphasis>unstable</"
+"emphasis> differs from the version in <emphasis>testing</emphasis> and that "
+"there has been a binary-only NMU of the package for the alpha architecture. "
+"Each version of the package has been recompiled on most of the architectures."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: resources.dbk:1005
+msgid "The Package Tracking System"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:1007
+msgid ""
+"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."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:1012
+msgid ""
+"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."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:1016
+msgid "By default you will get:"
+msgstr ""
+
+# type: Content of: <chapter><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1023
+msgid "All the bug reports and following discussions."
+msgstr ""
+
+# type: Content of: <chapter><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1031
+msgid ""
+"The email notifications from <email>control@&bugs-host;</email> about bug "
+"report status changes."
+msgstr ""
+
+# type: Content of: <chapter><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1040
+msgid ""
+"The email notification from <command>katie</command> when an uploaded source "
+"package is accepted."
+msgstr ""
+
+# type: Content of: <chapter><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1049
+msgid ""
+"Other warning and error emails from <command>katie</command> (such as an "
+"override disparity for the section and/or the priority field)."
+msgstr ""
+
+# type: Content of: <chapter><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1058
+msgid ""
+"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 "
+"<literal><replaceable>sourcepackage</replaceable>@&pts-host;</literal>. In "
+"order to prevent spam, all messages sent to these addresses must contain the "
+"<literal>X-PTS-Approved</literal> header with a non-empty value."
+msgstr ""
+
+# type: Content of: <chapter><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1070
+msgid ""
+"Regular summary emails about the package's status. Currently, only "
+"progression in <emphasis>testing</emphasis> is sent."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:1077
+msgid "You can also decide to receive additional information:"
+msgstr ""
+
+# type: Content of: <chapter><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1084
+msgid ""
+"The email notification from <command>katie</command> 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."
+msgstr ""
+
+# type: Content of: <chapter><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1095
+msgid ""
+"CVS commit notifications, if the package has a CVS repository and the "
+"maintainer has set up forwarding commit notifications to the PTS."
+msgstr ""
+
+# type: Content of: <chapter><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1104
+msgid ""
+"Translations of descriptions or debconf templates submitted to the Debian "
+"Description Translation Project."
+msgstr ""
+
+# type: Content of: <chapter><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1113
+msgid ""
+"Information about changes made to the package in derivative distributions "
+"(for example Ubuntu)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:1120
+msgid "The PTS email interface"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:1122
+msgid ""
+"You can control your subscription(s) to the PTS by sending various commands "
+"to <email>pts@qa.debian.org</email>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1130
+msgid ""
+"Subscribes <replaceable>email</replaceable> to communications related to the "
+"source package <replaceable>sourcepackage</replaceable>. Sender address is "
+"used if the second argument is not present. If <replaceable>sourcepackage</"
+"replaceable> 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."
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1143
+msgid ""
+"Removes a previous subscription to the source package "
+"<replaceable>sourcepackage</replaceable> using the specified email address "
+"or the sender address if the second argument is left out."
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1153
+msgid ""
+"Removes all subscriptions of the specified email address or the sender "
+"address if the second argument is left out."
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1162
+msgid ""
+"Lists all subscriptions for the sender or the email address optionally "
+"specified."
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1171
+msgid ""
+"Tells you the keywords that you are accepting. For an explanation of "
+"keywords, <link linkend=\"pkg-tracking-system\">see above</link>. Here's a "
+"quick summary:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><itemizedlist><listitem><para>
+#: resources.dbk:1178
+msgid ""
+"<literal>bts</literal>: mails coming from the Debian Bug Tracking System"
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><itemizedlist><listitem><para>
+#: resources.dbk:1183
+msgid ""
+"<literal>bts-control</literal>: reply to mails sent to &email-bts-control;"
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><itemizedlist><listitem><para>
+#: resources.dbk:1189
+msgid ""
+"<literal>summary</literal>: automatic summary mails about the state of a "
+"package"
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><itemizedlist><listitem><para>
+#: resources.dbk:1195
+msgid "<literal>cvs</literal>: notification of CVS commits"
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><itemizedlist><listitem><para>
+#: resources.dbk:1200
+msgid ""
+"<literal>ddtp</literal>: translations of descriptions and debconf templates"
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><itemizedlist><listitem><para>
+#: resources.dbk:1205
+msgid ""
+"<literal>derivatives</literal>: changes made on the package by derivative "
+"distributions"
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><itemizedlist><listitem><para>
+#: resources.dbk:1211
+msgid ""
+"<literal>upload-source</literal>: announce of a new source upload that has "
+"been accepted"
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><itemizedlist><listitem><para>
+#: resources.dbk:1217
+msgid ""
+"<literal>upload-binary</literal>: announce of a new binary-only upload "
+"(porting)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><itemizedlist><listitem><para>
+#: resources.dbk:1223
+msgid ""
+"<literal>katie-other</literal>: other mails from ftpmasters (override "
+"disparity, etc.)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><itemizedlist><listitem><para>
+#: resources.dbk:1229
+msgid ""
+"<literal>default</literal>: all the other mails (those which aren't "
+"automatic)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1239
+msgid ""
+"Same as the previous item but for the given source package, since you may "
+"select a different set of keywords for each source package."
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1248
+msgid ""
+"Accept (+) or refuse (-) mails classified under the given keyword(s). "
+"Define the list (=) of accepted keywords. This changes the default set of "
+"keywords accepted by a user."
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1258
+msgid ""
+"Accept (+) or refuse (-) mails classified under the given keyword(s). "
+"Define the list (=) of accepted keywords. This changes the set of accepted "
+"keywords of all the currently active subscriptions of a user."
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1268
+msgid ""
+"Same as previous item but overrides the keywords list for the indicated "
+"source package."
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1277
+msgid "Stops processing commands. All following lines are ignored by the bot."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:1283
+msgid ""
+"The <command>pts-subscribe</command> command-line utility (from the "
+"<systemitem role=\"package\">devscripts</systemitem> package) can be handy "
+"to temporarily subscribe to some packages, for example after having made an "
+"non-maintainer upload."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:1291
+msgid "Filtering PTS mails"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:1293
+msgid ""
+"Once you are subscribed to a package, you will get the mails sent to "
+"<literal><replaceable>sourcepackage</replaceable>@&pts-host;</literal>. "
+"Those mails have special headers appended to let you filter them in a "
+"special mailbox (e.g. with <command>procmail</command>). The added headers "
+"are <literal>X-Loop</literal>, <literal>X-PTS-Package</literal>, <literal>X-"
+"PTS-Keyword</literal> and <literal>X-Unsubscribe</literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:1301
+msgid ""
+"Here is an example of added headers for a source upload notification on the "
+"<systemitem role=\"package\">dpkg</systemitem> package:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: resources.dbk:1305
+#, no-wrap
+msgid ""
+"X-Loop: dpkg@&pts-host;\n"
+"X-PTS-Package: dpkg\n"
+"X-PTS-Keyword: upload-source\n"
+"X-Unsubscribe: echo 'unsubscribe dpkg' | mail pts@qa.debian.org"
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:1313
+msgid "Forwarding CVS commits in the PTS"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:1315
+msgid ""
+"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 (and possible co-maintainers) can closely follow the "
+"package's evolution."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:1321
+msgid ""
+"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 "
+"<literal><replaceable>sourcepackage</replaceable>_cvs@&pts-host;</literal>. "
+"Only the people who accept the <emphasis>cvs</emphasis> keyword will receive "
+"these notifications."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:1330
+msgid "The PTS web interface"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:1332
+msgid ""
+"The PTS has a web interface at <ulink url=\"http://&pts-host;/\"></ulink> "
+"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 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 allows easy subscription to the "
+"PTS via email."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:1342
+msgid ""
+"You can jump directly to the web page concerning a specific source package "
+"with a URL like <literal>http://&pts-host;/<replaceable>sourcepackage</"
+"replaceable></literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:1347
+msgid ""
+"This web interface has been designed like a portal for the development of "
+"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."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:1353
+msgid "Static news items can be used to indicate:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: resources.dbk:1358
+msgid ""
+"the availability of a project hosted on <link linkend=\"alioth\">Alioth</"
+"link> for co-maintaining the package"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: resources.dbk:1364
+msgid "a link to the upstream web site"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: resources.dbk:1369
+msgid "a link to the upstream bug tracker"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: resources.dbk:1374
+msgid "the existence of an IRC channel dedicated to the software"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: resources.dbk:1379
+msgid ""
+"any other available resource that could be useful in the maintenance of the "
+"package"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:1385
+msgid "Usual news items may be used to announce that:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: resources.dbk:1390
+msgid "beta packages are available for testing"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: resources.dbk:1395
+msgid "final packages are expected for next week"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: resources.dbk:1400
+msgid "the packaging is about to be redone from scratch"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: resources.dbk:1405
+msgid "backports are available"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: resources.dbk:1410
+msgid ""
+"the maintainer is on vacation (if they wish to publish this information)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: resources.dbk:1415
+msgid "a NMU is being worked on"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: resources.dbk:1420
+msgid "something important will affect the package"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:1425
+msgid ""
+"Both kinds of news are generated in a similar manner: you just have to send "
+"an email either to <email>pts-static-news@qa.debian.org</email> or to "
+"<email>pts-news@qa.debian.org</email>. The mail should indicate which "
+"package is concerned by having the name of the source package in a "
+"<literal>X-PTS-Package</literal> mail header or in a <literal>Package</"
+"literal> pseudo-header (like the BTS reports). If a URL is available in the "
+"<literal>X-PTS-Url</literal> mail header or in the <literal>Url</literal> "
+"pseudo-header, then the result is a link to that URL instead of a complete "
+"news item."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:1436
+msgid ""
+"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:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: resources.dbk:1441
+#, no-wrap
+msgid ""
+"From: Raphael Hertzog <hertzog@debian.org>\n"
+"To: pts-static-news@qa.debian.org\n"
+"Subject: Browse debian-cd CVS repository with cvsweb\n"
+"\n"
+"Package: debian-cd\n"
+"Url: &url-cvsweb;debian-cd/"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:1449
+msgid ""
+"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."
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: resources.dbk:1454
+#, no-wrap
+msgid ""
+": Raphael Hertzog <hertzog@debian.org>\n"
+"To: debian-gtk-gnome@&lists-host;\n"
+"Bcc: pts-news@qa.debian.org\n"
+"Subject: Galeon 2.0 backported for woody\n"
+"X-PTS-Package: galeon\n"
+"\n"
+"Hello gnomers!\n"
+"\n"
+"I'm glad to announce that galeon has been backported for woody. You'll find\n"
+"everything here:\n"
+"..."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:1467
+msgid ""
+"Think twice before adding a news item to the PTS because you won't be able "
+"to remove it later and you won'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."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: resources.dbk:1477
+msgid "Developer's packages overview"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:1479
+msgid ""
+"A QA (quality assurance) web portal is available at <ulink url=\"&url-ddpo;"
+"\"></ulink> which displays a table listing all the packages of a single "
+"developer (including those where the party is listed as a co-maintainer). "
+"The table gives a good summary about the developer's packages: number of "
+"bugs by severity, list of available versions in each distribution, testing "
+"status and much more including links to any other useful information."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:1488
+msgid ""
+"It is a good idea to look up your own data regularly so that you don't "
+"forget any open bugs, and so that you don't forget which packages are your "
+"responsibility."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: resources.dbk:1495
+msgid "Debian *Forge: Alioth"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:1497
+msgid ""
+"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."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:1504
+msgid ""
+"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."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:1510
+msgid ""
+"All Debian developers automatically have an account on Alioth. They can "
+"activate it by using the recover password facility. External developers can "
+"request guest accounts on Alioth."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:1515
+msgid "For more information please visit <ulink url=\"&url-alioth;\"></ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: resources.dbk:1521
+msgid "Goodies for Developers"
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:1523
+msgid "LWN Subscriptions"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:1525
+msgid ""
+"Since October of 2002, HP has sponsored a subscription to LWN for all "
+"interested Debian developers. Details on how to get access to this benefit "
+"are in <ulink url=\"http://&lists-host;/debian-devel-announce/2002/10/"
+"msg00018.html\"></ulink>."
+msgstr ""
+
--- /dev/null
+# SOME DESCRIPTIVE TITLE
+# Copyright (C) 2007 Free Software Foundation, Inc.
+# <>, 2007.
+# , fuzzy
+#
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: PACKAGE VERSION\n"
+"Report-Msgid-Bugs-To: \n"
+"POT-Creation-Date: 2007-07-01 21:16+0000\n"
+"PO-Revision-Date: 2007-07-01 22:30+0000\n"
+"Last-Translator: <>\n"
+"Language-Team: \n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: "
+
+# type: Content of: <chapter><title>
+#: scope.dbk:7
+msgid "Scope of This Document"
+msgstr "Portée de ce document"
+
+# type: Content of: <chapter><para>
+#: scope.dbk:9
+msgid ""
+"The purpose of this document is to provide an overview of the recommended "
+"procedures and the available resources for Debian developers."
+msgstr "Le but de ce document est de donner une vue d'ensemble des procédures à "
+"suivre et des ressources mises à la disposition des développeurs Debian."
+
+# type: Content of: <chapter><para>
+#: scope.dbk:14
+msgid ""
+"The procedures discussed within include how to become a maintainer (<xref "
+"linkend=\"new-maintainer\"/> ); how to create new packages (<xref linkend="
+"\"newpackage\"/> ) and how to upload packages (<xref linkend=\"upload\"/> ); "
+"how to handle bug reports (<xref linkend=\"bug-handling\"/> ); how to move, "
+"remove, or orphan packages (<xref linkend=\"archive-manip\"/> ); how to port "
+"packages (<xref linkend=\"porting\"/> ); and how and when to do interim "
+"releases of other maintainers' packages (<xref linkend=\"nmu\"/> )."
+msgstr "Les procédures décrites ci-après expliquent comment devenir responsable"
+"Debian (<xref linkend=\"new-maintainer\"/>), comment créer de nouveaux paquets"
+"(<xref linkend=\"newpackage\"/>) et comment les installer dans l'archive (<xref linkend=\"upload\"/>), comment gérer les rapports de bogues (<xref linkend=\"bug-handling\"/>), comment déplacer, effacer ou abandonner un paquet"
+"(<xref linkend=\"archive-manip\"/>), comment faire le portage d'un paquet (<xref linkend=\"porting\"/>), quand et comment faire la mise à jour du paquet d'un"
+"autre responsable (<xref linkend=\"nmu\"/>)."
+
+# type: Content of: <chapter><para>
+#: scope.dbk:23
+msgid ""
+"The resources discussed in this reference include the mailing lists (<xref "
+"linkend=\"mailing-lists\"/> ) and servers (<xref linkend=\"server-machines\"/"
+"> ); a discussion of the structure of the Debian archive (<xref linkend="
+"\"archive\"/> ); explanation of the different servers which accept package "
+"uploads (<xref linkend=\"upload-ftp-master\"/> ); and a discussion of "
+"resources which can help maintainers with the quality of their packages "
+"(<xref linkend=\"tools\"/> )."
+msgstr "Les ressources présentées dans ce manuel incluent les listes de"
+"diffusion (<xref linkend=\"mailing-lists\"/>) et les serveurs (<xref linkend=\"server-machines\"/>), une présentation de la structure de l'archive"
+"Debian (<xref linkend=\"archive\"/>), des explications sur les serveurs qui"
+"acceptent les mises à jour de paquets (<xref linkend=\"upload-ftp-master\"/>) et"
+"une présentation des outils qui peuvent aider un responsable à améliorer"
+"la qualité de ses paquets (<xref linkend=\"tools\"/>)."
+
+# type: Content of: <chapter><para>
+#: scope.dbk:31
+msgid ""
+"It should be clear that this reference does not discuss the technical "
+"details of Debian packages nor how to generate them. Nor does this "
+"reference detail the standards to which Debian software must comply. All of "
+"such information can be found in the <ulink url=\"&url-debian-policy;"
+"\">Debian Policy Manual</ulink>."
+msgstr "Ce manuel de référence ne présente pas les aspects techniques liés aux"
+"paquets Debian, ni comment les créer. Il ne décrit pas non plus les"
+"règles que doivent respecter les paquets Debian. Cette information est"
+"disponible dans la <ulink url=\"&url-debian-policy;\">charte Debian</ulink>."
+
+# type: Content of: <chapter><para>
+#: scope.dbk:38
+msgid ""
+"Furthermore, this document is <emphasis>not an expression of formal policy</"
+"emphasis>. It contains documentation for the Debian system and generally "
+"agreed-upon best practices. Thus, it is not what is called a ``normative'' "
+"document."
+msgstr "De plus ce document <emphasis>n'est pas l'expression d'une politique"
+"officielle</emphasis>. Il contient de la documentation sur le système Debian"
+"et des conseils pratiques largement suivis. Ce n'est donc pas une sorte"
+"de guide de normes."
+
--- /dev/null
+# SOME DESCRIPTIVE TITLE
+# Copyright (C) 2007 Free Software Foundation, Inc.
+# <>, 2007.
+# , fuzzy
+#
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: PACKAGE VERSION\n"
+"Report-Msgid-Bugs-To: \n"
+"POT-Creation-Date: 2007-07-01 21:16+0000\n"
+"PO-Revision-Date: 2007-07-01 23:19+0000\n"
+"Last-Translator: <>\n"
+"Language-Team: \n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: "
+
+# type: Content of: <appendix><title>
+#: tools.dbk:7
+msgid "Overview of Debian Maintainer Tools"
+msgstr "Aperçu des outils du responsable Debian"
+
+# type: Content of: <appendix><para>
+#: tools.dbk:9
+msgid ""
+"This section contains a rough overview of the tools available to "
+"maintainers. The following is by no means complete or definitive, but just "
+"a guide to some of the more popular tools."
+msgstr "Cette section contient un aperçu rapide des outils dont dispose le"
+"responsable. Cette liste n'est ni complète, ni définitive, il s'agit"
+"juste d'un guide des outils les plus utilisés."
+
+# type: Content of: <appendix><para>
+#: tools.dbk:14
+msgid ""
+"Debian maintainer tools are meant to aid developers and free their time for "
+"critical tasks. As Larry Wall says, there's more than one way to do it."
+msgstr "Les outils du responsable Debian sont destinés à aider les responsables"
+"et libérer leur temps pour des tâches plus cruciales. Comme le dit Larry"
+"Wall, il y a plus d'une manière de le faire."
+
+# type: Content of: <appendix><para>
+#: tools.dbk:18
+msgid ""
+"Some people prefer to use high-level package maintenance tools and some do "
+"not. Debian is officially agnostic on this issue; any tool which gets the "
+"job done is fine. Therefore, this section is not meant to stipulate to "
+"anyone which tools they should use or how they should go about their duties "
+"of maintainership. Nor is it meant to endorse any particular tool to the "
+"exclusion of a competing tool."
+msgstr "Certaines personnes préfèrent utiliser des outils de haut niveau,"
+"d'autres pas. Debian n'a pas de position officielle sur la"
+"question ; tout outil conviendra du moment qu'il fait le"
+"boulot. C'est pourquoi cette section n'a pas été conçue pour indiquer à"
+"chacun quel outil il doit utiliser ou comment il devrait faire pour"
+"gérer sa charge de responsable Debian. Elle n'est pas non plus destinée"
+"à favoriser l'utilisation d'un outil aux dépens d'un autre."
+
+# type: Content of: <appendix><para>
+#: tools.dbk:26
+msgid ""
+"Most of the descriptions of these packages come from the actual package "
+"descriptions themselves. Further information can be found in the package "
+"documentation itself. You can also see more info with the command "
+"<command>apt-cache show <package-name></command>."
+msgstr "La plupart des descriptions de ces outils proviennent des descriptions"
+"de leurs paquets. Vous trouverez plus d'informations dans les"
+"documentations de ces paquets. Vous pouvez aussi obtenir plus"
+"d'informations avec la commande <literal>apt-cache show"
+"<nom_paquet></literal>."
+
+# type: Content of: <appendix><section><title>
+#: tools.dbk:32
+msgid "Core tools"
+msgstr "Outils de base"
+
+# type: Content of: <appendix><section><para>
+#: tools.dbk:34
+msgid "The following tools are pretty much required for any maintainer."
+msgstr "Les outils suivants sont pratiquement nécessaires à tout responsable."
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:39
+msgid ""
+"<systemitem role=\"package\">dpkg-dev</systemitem> contains the tools "
+"(including <command>dpkg-source</command>) required to unpack, build, and "
+"upload Debian source packages. These utilities contain the fundamental, low-"
+"level functionality required to create and manipulate packages; as such, "
+"they are essential for any Debian maintainer."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:50
+msgid ""
+"<systemitem role=\"package\">debconf</systemitem> provides a consistent "
+"interface to configuring packages interactively. It is user interface "
+"independent, allowing end-users to configure packages with a text-only "
+"interface, an HTML interface, or a dialog interface. New interfaces can be "
+"added as modules."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:56
+msgid ""
+"You can find documentation for this package in the <systemitem role=\"package"
+"\">debconf-doc</systemitem> package."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:60
+msgid ""
+"Many feel that this system should be used for all packages which require "
+"interactive configuration; see <xref linkend=\"bpp-config-mgmt\"/> . "
+"<systemitem role=\"package\">debconf</systemitem> is not currently required "
+"by Debian Policy, but that may change in the future."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:70
+msgid ""
+"<systemitem role=\"package\">fakeroot</systemitem> simulates root "
+"privileges. This enables you to build packages without being root (packages "
+"usually want to install files with root ownership). If you have <systemitem "
+"role=\"package\">fakeroot</systemitem> installed, you can build packages as "
+"a regular user: <literal>dpkg-buildpackage -rfakeroot</literal>."
+msgstr ""
+
+# type: Content of: <appendix><section><title>
+#: tools.dbk:81
+msgid "Package lint tools"
+msgstr ""
+
+# type: Content of: <appendix><section><para>
+#: tools.dbk:83
+msgid ""
+"According to the Free On-line Dictionary of Computing (FOLDOC), `lint' is a "
+"Unix C language processor which carries out more thorough checks on the code "
+"than is usual with C compilers. Package lint tools help package maintainers "
+"by automatically finding common problems and policy violations in their "
+"packages."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:91
+msgid ""
+"<systemitem role=\"package\">lintian</systemitem> dissects Debian packages "
+"and emits information about bugs and policy violations. It contains "
+"automated checks for many aspects of Debian policy as well as some checks "
+"for common errors."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:97
+msgid ""
+"You should periodically get the newest <systemitem role=\"package\">lintian</"
+"systemitem> from `unstable' and check over all your packages. Notice that "
+"the <literal>-i</literal> option provides detailed explanations of what each "
+"error or warning means, what its basis in Policy is, and commonly how you "
+"can fix the problem."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:104
+msgid ""
+"Refer to <xref linkend=\"sanitycheck\"/> for more information on how and "
+"when to use Lintian."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:108
+msgid ""
+"You can also see a summary of all problems reported by Lintian on your "
+"packages at <ulink url=\"&url-lintian;\"></ulink>. These reports contain "
+"the latest <command>lintian</command> output for the whole development "
+"distribution (unstable)."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:118
+msgid ""
+"<systemitem role=\"package\">linda</systemitem> is another package linter. "
+"It is similar to <systemitem role=\"package\">lintian</systemitem> but has a "
+"different set of checks. Its written in Python rather than Perl."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:127
+msgid ""
+"<command>debdiff</command> (from the <systemitem role=\"package"
+"\">devscripts</systemitem> package, <xref linkend=\"devscripts\"/> ) "
+"compares file lists and control files of two packages. It is a simple "
+"regression test, as it will help you notice if the number of binary packages "
+"has changed since the last upload, or if something has changed in the "
+"control file. Of course, some of the changes it reports will be all right, "
+"but it can help you prevent various accidents."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:136
+msgid "You can run it over a pair of binary packages:"
+msgstr ""
+
+# type: Content of: <appendix><section><section><screen>
+#: tools.dbk:139
+#, no-wrap
+msgid "debdiff package_1-1_arch.deb package_2-1_arch.deb"
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:142
+msgid "Or even a pair of changes files:"
+msgstr ""
+
+# type: Content of: <appendix><section><section><screen>
+#: tools.dbk:145
+#, no-wrap
+msgid "debdiff package_1-1_arch.changes package_2-1_arch.changes"
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:148
+msgid ""
+"For more information please see <citerefentry> <refentrytitle>debdiff</"
+"refentrytitle> <manvolnum>1</manvolnum> </citerefentry>."
+msgstr ""
+
+# type: Content of: <appendix><section><title>
+#: tools.dbk:157
+msgid "Helpers for <filename>debian/rules</filename>"
+msgstr ""
+
+# type: Content of: <appendix><section><para>
+#: tools.dbk:159
+msgid ""
+"Package building tools make the process of writing <filename>debian/rules</"
+"filename> files easier. See <xref linkend=\"helper-scripts\"/> for more "
+"information about why these might or might not be desired."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:167
+msgid ""
+"<systemitem role=\"package\">debhelper</systemitem> is a collection of "
+"programs which can be used in <filename>debian/rules</filename> to automate "
+"common tasks related to building binary Debian packages. <systemitem role="
+"\"package\">debhelper</systemitem> includes programs to install various "
+"files into your package, compress files, fix file permissions, and integrate "
+"your package with the Debian menu system."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:175
+msgid ""
+"Unlike some approaches, <systemitem role=\"package\">debhelper</systemitem> "
+"is broken into several small, simple commands which act in a consistent "
+"manner. As such, it allows more fine-grained control than some of the other "
+"debian/rules tools."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:181
+msgid ""
+"There are a number of little <systemitem role=\"package\">debhelper</"
+"systemitem> add-on packages, too transient to document. You can see the "
+"list of most of them by doing <literal>apt-cache search ^dh-</literal>."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:190
+msgid ""
+"<systemitem role=\"package\">debmake</systemitem>, a precursor to "
+"<systemitem role=\"package\">debhelper</systemitem>, is a more coarse-"
+"grained <filename>debian/rules</filename> assistant. It includes two main "
+"programs: <command>deb-make</command>, which can be used to help a "
+"maintainer convert a regular (non-Debian) source archive into a Debian "
+"source package; and <command>debstd</command>, which incorporates in one big "
+"shot the same sort of automated functions that one finds in <systemitem role="
+"\"package\">debhelper</systemitem>."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:200
+msgid ""
+"The consensus is that <systemitem role=\"package\">debmake</systemitem> is "
+"now deprecated in favor of <systemitem role=\"package\">debhelper</"
+"systemitem>. It is a bug to use <systemitem role=\"package\">debmake</"
+"systemitem> in new packages. New packages using <systemitem role=\"package"
+"\">debmake</systemitem> will be rejected from the archive."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:211
+msgid ""
+"The <systemitem role=\"package\">dh-make</systemitem> package contains "
+"<command>dh_make</command>, a program that creates a skeleton of files "
+"necessary to build a Debian package out of a source tree. As the name "
+"suggests, <command>dh_make</command> is a rewrite of <systemitem role="
+"\"package\">debmake</systemitem> and its template files use dh_* programs "
+"from <systemitem role=\"package\">debhelper</systemitem>."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:219
+msgid ""
+"While the rules files generated by <command>dh_make</command> are in general "
+"a sufficient basis for a working package, they are still just the "
+"groundwork: the burden still lies on the maintainer to finely tune the "
+"generated files and make the package entirely functional and Policy-"
+"compliant."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:229
+msgid ""
+"<systemitem role=\"package\">yada</systemitem> is another packaging helper "
+"tool. It uses a <filename>debian/packages</filename> file to auto-generate "
+"<filename>debian/rules</filename> and other necessary files in the "
+"<filename>debian/</filename> subdirectory. The <filename>debian/packages</"
+"filename> file contains instruction to build packages and there is no need "
+"to create any <filename>Makefile</filename> files. There is possibility to "
+"use macro engine similar to the one used in SPECS files from RPM source "
+"packages."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:239
+msgid ""
+"For more informations see <literal><ulink url=\"http://yada.alioth.debian."
+"org/\">YADA site</ulink></literal>."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:247
+msgid ""
+"<systemitem role=\"package\">equivs</systemitem> is another package for "
+"making packages. It is often suggested for local use if you need to make a "
+"package simply to fulfill dependencies. It is also sometimes used when "
+"making ``meta-packages'', which are packages whose only purpose is to depend "
+"on other packages."
+msgstr ""
+
+# type: Content of: <appendix><section><title>
+#: tools.dbk:258
+msgid "Package builders"
+msgstr ""
+
+# type: Content of: <appendix><section><para>
+#: tools.dbk:260
+msgid ""
+"The following packages help with the package building process, general "
+"driving <command>dpkg-buildpackage</command> as well as handling supporting "
+"tasks."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:266
+msgid ""
+"<systemitem role=\"package\">cvs-buildpackage</systemitem> provides the "
+"capability to inject or import Debian source packages into a CVS repository, "
+"build a Debian package from the CVS repository, and helps in integrating "
+"upstream changes into the repository."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:272
+msgid ""
+"These utilities provide an infrastructure to facilitate the use of CVS by "
+"Debian maintainers. This allows one to keep separate CVS branches of a "
+"package for <emphasis>stable</emphasis>, <emphasis>unstable</emphasis> and "
+"possibly <emphasis>experimental</emphasis> distributions, along with the "
+"other benefits of a version control system."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:283
+msgid ""
+"The <systemitem role=\"package\">debootstrap</systemitem> package and script "
+"allows you to bootstrap a Debian base system into any part of your "
+"filesystem. By base system, we mean the bare minimum of packages required "
+"to operate and install the rest of the system."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:289
+msgid ""
+"Having a system like this can be useful in many ways. For instance, you can "
+"<command>chroot</command> into it if you want to test your build "
+"dependencies. Or you can test how your package behaves when installed into "
+"a bare base system. Chroot builders use this package; see below."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:299
+msgid ""
+"<systemitem role=\"package\">pbuilder</systemitem> constructs a chrooted "
+"system, and builds a package inside the chroot. It is very useful to check "
+"that a package's build-dependencies are correct, and to be sure that "
+"unnecessary and wrong build dependencies will not exist in the resulting "
+"package."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:305
+msgid ""
+"A related package is <systemitem role=\"package\">pbuilder-uml</systemitem>, "
+"which goes even further by doing the build within a User Mode Linux "
+"environment."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:314
+msgid ""
+"<systemitem role=\"package\">sbuild</systemitem> is another automated "
+"builder. It can use chrooted environments as well. It can be used stand-"
+"alone, or as part of a networked, distributed build environment. As the "
+"latter, it is part of the system used by porters to build binary packages "
+"for all the available architectures. See <xref linkend=\"buildd\"/> for "
+"more information, and <ulink url=\"&url-buildd;\"></ulink> to see the system "
+"in action."
+msgstr ""
+
+# type: Content of: <appendix><section><title>
+#: tools.dbk:326
+msgid "Package uploaders"
+msgstr ""
+
+# type: Content of: <appendix><section><para>
+#: tools.dbk:328
+msgid ""
+"The following packages help automate or simplify the process of uploading "
+"packages into the official archive."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:334
+msgid ""
+"<systemitem role=\"package\">dupload</systemitem> is a package and a script "
+"to automatically upload Debian packages to the Debian archive, to log the "
+"upload, and to send mail about the upload of a package. You can configure "
+"it for new upload locations or methods."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:344
+msgid ""
+"The <systemitem role=\"package\">dput</systemitem> package and script does "
+"much the same thing as <systemitem role=\"package\">dupload</systemitem>, "
+"but in a different way. It has some features over <systemitem role=\"package"
+"\">dupload</systemitem>, such as the ability to check the GnuPG signature "
+"and checksums before uploading, and the possibility of running "
+"<command>dinstall</command> in dry-run mode after the upload."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:356
+msgid ""
+"The <systemitem role=\"package\">dcut</systemitem> script (part of the "
+"package <xref linkend=\"dput\"/> ) helps in removing files from the ftp "
+"upload directory."
+msgstr ""
+
+# type: Content of: <appendix><section><title>
+#: tools.dbk:364
+msgid "Maintenance automation"
+msgstr ""
+
+# type: Content of: <appendix><section><para>
+#: tools.dbk:366
+msgid ""
+"The following tools help automate different maintenance tasks, from adding "
+"changelog entries or signature lines and looking up bugs in Emacs to making "
+"use of the newest and official <filename>config.sub</filename>."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:373
+msgid ""
+"<systemitem role=\"package\">devscripts</systemitem> is a package containing "
+"wrappers and tools which are very helpful for maintaining your Debian "
+"packages. Example scripts include <command>debchange</command> and "
+"<command>dch</command>, which manipulate your <filename>debian/changelog</"
+"filename> file from the command-line, and <command>debuild</command>, which "
+"is a wrapper around <command>dpkg-buildpackage</command>. The <command>bts</"
+"command> utility is also very helpful to update the state of bug reports on "
+"the command line. <command>uscan</command> can be used to watch for new "
+"upstream versions of your packages. <command>debrsign</command> can be used "
+"to remotely sign a package prior to upload, which is nice when the machine "
+"you build the package on is different from where your GPG keys are."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:387
+msgid ""
+"See the <citerefentry> <refentrytitle>devscripts</refentrytitle> "
+"<manvolnum>1</manvolnum> </citerefentry> manual page for a complete list of "
+"available scripts."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:396
+msgid ""
+"<systemitem role=\"package\">autotools-dev</systemitem> contains best "
+"practices for people who maintain packages which use <command>autoconf</"
+"command> and/or <command>automake</command>. Also contains canonical "
+"<filename>config.sub</filename> and <filename>config.guess</filename> files "
+"which are known to work on all Debian ports."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:407
+msgid ""
+"<command>dpkg-repack</command> creates Debian package file out of a package "
+"that has already been installed. If any changes have been made to the "
+"package while it was unpacked (e.g., files in <filename>/etc</filename> were "
+"modified), the new package will inherit the changes."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:413
+msgid ""
+"This utility can make it easy to copy packages from one computer to another, "
+"or to recreate packages which are installed on your system but no longer "
+"available elsewhere, or to save the current state of a package before you "
+"upgrade it."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:422
+msgid ""
+"<command>alien</command> converts binary packages between various packaging "
+"formats, including Debian, RPM (RedHat), LSB (Linux Standard Base), Solaris, "
+"and Slackware packages."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:431
+msgid ""
+"<command>debsums</command> checks installed packages against their MD5 "
+"sums. Note that not all packages have MD5 sums, since they aren't required "
+"by Policy."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:439
+msgid ""
+"<systemitem role=\"package\">dpkg-dev-el</systemitem> is an Emacs lisp "
+"package which provides assistance when editing some of the files in the "
+"<filename>debian</filename> directory of your package. For instance, there "
+"are handy functions for listing a package's current bugs, and for finalizing "
+"the latest entry in a <filename>debian/changelog</filename> file."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:450
+msgid ""
+"<command>dpkg-depcheck</command> (from the <systemitem role=\"package"
+"\">devscripts</systemitem> package, <xref linkend=\"devscripts\"/> ) runs a "
+"command under <command>strace</command> to determine all the packages that "
+"were used by the said command."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:456
+msgid ""
+"For Debian packages, this is useful when you have to compose a "
+"<literal>Build-Depends</literal> line for your new package: running the "
+"build process through <command>dpkg-depcheck</command> will provide you with "
+"a good first approximation of the build-dependencies. For example:"
+msgstr ""
+
+# type: Content of: <appendix><section><section><screen>
+#: tools.dbk:462
+#, no-wrap
+msgid "dpkg-depcheck -b debian/rules build"
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:465
+msgid ""
+"<command>dpkg-depcheck</command> can also be used to check for run-time "
+"dependencies, especially if your package uses exec(2) to run other programs."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:469
+msgid ""
+"For more information please see <citerefentry> <refentrytitle>dpkg-depcheck</"
+"refentrytitle> <manvolnum>1</manvolnum> </citerefentry>."
+msgstr ""
+
+# type: Content of: <appendix><section><title>
+#: tools.dbk:478
+msgid "Porting tools"
+msgstr ""
+
+# type: Content of: <appendix><section><para>
+#: tools.dbk:480
+msgid "The following tools are helpful for porters and for cross-compilation."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:485
+msgid ""
+"<systemitem role=\"package\">quinn-diff</systemitem> is used to locate the "
+"differences from one architecture to another. For instance, it could tell "
+"you which packages need to be ported for architecture <replaceable>Y</"
+"replaceable>, based on architecture <replaceable>X</replaceable>."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:495
+msgid ""
+"<systemitem role=\"package\">dpkg-cross</systemitem> is a tool for "
+"installing libraries and headers for cross-compiling in a way similar to "
+"<systemitem role=\"package\">dpkg</systemitem>. Furthermore, the "
+"functionality of <command>dpkg-buildpackage</command> and <command>dpkg-"
+"shlibdeps</command> is enhanced to support cross-compiling."
+msgstr ""
+
+# type: Content of: <appendix><section><title>
+#: tools.dbk:506
+msgid "Documentation and information"
+msgstr ""
+
+# type: Content of: <appendix><section><para>
+#: tools.dbk:508
+msgid ""
+"The following packages provide information for maintainers or help with "
+"building documentation."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:514
+msgid ""
+"<systemitem role=\"package\">debiandoc-sgml</systemitem> provides the "
+"DebianDoc SGML DTD, which is commonly used for Debian documentation. This "
+"manual, for instance, is written in DebianDoc. It also provides scripts for "
+"building and styling the source to various output formats."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:520
+msgid ""
+"Documentation for the DTD can be found in the <systemitem role=\"package"
+"\">debiandoc-sgml-doc</systemitem> package."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:544
+msgid ""
+"Contains the public GPG and PGP keys of Debian developers. See <xref "
+"linkend=\"key-maint\"/> and the package documentation for more information."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:552
+msgid ""
+"<systemitem role=\"package\">debview</systemitem> provides an Emacs mode for "
+"viewing Debian binary packages. This lets you examine a package without "
+"unpacking it."
+msgstr ""
+
--- /dev/null
+# SOME DESCRIPTIVE TITLE
+# Copyright (C) YEAR Free Software Foundation, Inc.
+# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
+#
+#, fuzzy
+msgid ""
+msgstr ""
+"Project-Id-Version: PACKAGE VERSION\n"
+"POT-Creation-Date: 2007-07-01 21:18+0000\n"
+"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
+"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
+"Language-Team: LANGUAGE <LL@li.org>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: ENCODING\n"
+
+# type: Content of: <chapter><title>
+#: best-pkging-practices.dbk:7
+msgid "Best Packaging Practices"
+msgstr ""
+
+# type: Content of: <chapter><para>
+#: best-pkging-practices.dbk:9
+msgid ""
+"Debian's quality is largely due to the <ulink url=\"&url-debian-policy;"
+"\">Debian Policy</ulink>, which defines explicit baseline requirements which "
+"all Debian packages must fulfill. Yet there is also a shared history of "
+"experience which goes beyond the Debian Policy, an accumulation of years of "
+"experience in packaging. Many very talented people have created great "
+"tools, tools which help you, the Debian maintainer, create and maintain "
+"excellent packages."
+msgstr ""
+
+# type: Content of: <chapter><para>
+#: best-pkging-practices.dbk:18
+msgid ""
+"This chapter provides some best practices for Debian developers. All "
+"recommendations are merely that, and are not requirements or policy. These "
+"are just some subjective hints, advice and pointers collected from Debian "
+"developers. Feel free to pick and choose whatever works best for you."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: best-pkging-practices.dbk:24
+msgid "Best practices for <filename>debian/rules</filename>"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:26
+msgid ""
+"The following recommendations apply to the <filename>debian/rules</filename> "
+"file. Since <filename>debian/rules</filename> controls the build process "
+"and selects the files which go into the package (directly or indirectly), "
+"it's usually the file maintainers spend the most time on."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:32
+msgid "Helper scripts"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:34
+msgid ""
+"The rationale for using helper scripts in <filename>debian/rules</filename> "
+"is that they let maintainers use and share common logic among many "
+"packages. Take for instance the question of installing menu entries: you "
+"need to put the file into <filename>/usr/lib/menu</filename> (or <filename>/"
+"usr/lib/menu</filename> for executable binary menufiles, if this is needed), "
+"and add commands to the maintainer scripts to register and unregister the "
+"menu entries. Since this is a very common thing for packages to do, why "
+"should each maintainer rewrite all this on their own, sometimes with bugs? "
+"Also, supposing the menu directory changed, every package would have to be "
+"changed."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:45
+msgid ""
+"Helper scripts take care of these issues. Assuming you comply with the "
+"conventions expected by the helper script, the helper takes care of all the "
+"details. Changes in policy can be made in the helper script; then packages "
+"just need to be rebuilt with the new version of the helper and no other "
+"changes."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:52
+msgid ""
+"<xref linkend=\"tools\"/> contains a couple of different helpers. The most "
+"common and best (in our opinion) helper system is <systemitem role=\"package"
+"\">debhelper</systemitem>. Previous helper systems, such as <systemitem "
+"role=\"package\">debmake</systemitem>, were monolithic: you couldn't pick "
+"and choose which part of the helper you found useful, but had to use the "
+"helper to do everything. <systemitem role=\"package\">debhelper</"
+"systemitem>, however, is a number of separate little <command>dh_*</command> "
+"programs. For instance, <command>dh_installman</command> installs and "
+"compresses man pages, <command>dh_installmenu</command> installs menu files, "
+"and so on. Thus, it offers enough flexibility to be able to use the little "
+"helper scripts, where useful, in conjunction with hand-crafted commands in "
+"<filename>debian/rules</filename>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:66
+msgid ""
+"You can get started with <systemitem role=\"package\">debhelper</systemitem> "
+"by reading <citerefentry> <refentrytitle>debhelper</refentrytitle> "
+"<manvolnum>1</manvolnum> </citerefentry>, and looking at the examples that "
+"come with the package. <command>dh_make</command>, from the <systemitem "
+"role=\"package\">dh-make</systemitem> package (see <xref linkend=\"dh-make\"/"
+"> ), can be used to convert a vanilla source package to a <systemitem role="
+"\"package\">debhelper</systemitem>ized package. This shortcut, though, "
+"should not convince you that you do not need to bother understanding the "
+"individual <command>dh_*</command> helpers. If you are going to use a "
+"helper, you do need to take the time to learn to use that helper, to learn "
+"its expectations and behavior."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:79
+msgid ""
+"Some people feel that vanilla <filename>debian/rules</filename> files are "
+"better, since you don't have to learn the intricacies of any helper system. "
+"This decision is completely up to you. Use what works for you. Many "
+"examples of vanilla <filename>debian/rules</filename> files are available at "
+"<ulink url=\"&url-rules-files;\"></ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:88
+msgid "Separating your patches into multiple files"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:90
+msgid ""
+"Big, complex packages may have many bugs that you need to deal with. If you "
+"correct a number of bugs directly in the source, and you're not careful, it "
+"can get hard to differentiate the various patches that you applied. It can "
+"get quite messy when you have to update the package to a new upstream "
+"version which integrates some of the fixes (but not all). You can't take "
+"the total set of diffs (e.g., from <filename>.diff.gz</filename>) and work "
+"out which patch sets to back out as a unit as bugs are fixed upstream."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:99
+msgid ""
+"Unfortunately, the packaging system as such currently doesn't provide for "
+"separating the patches into several files. Nevertheless, there are ways to "
+"separate patches: the patch files are shipped within the Debian patch file "
+"(<filename>.diff.gz</filename>), usually within the <filename>debian/</"
+"filename> directory. The only difference is that they aren't applied "
+"immediately by dpkg-source, but by the <literal>build</literal> rule of "
+"<filename>debian/rules</filename>. Conversely, they are reverted in the "
+"<literal>clean</literal> rule."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:109
+msgid ""
+"<command>dbs</command> is one of the more popular approaches to this. It "
+"does all of the above, and provides a facility for creating new and updating "
+"old patches. See the package <systemitem role=\"package\">dbs</systemitem> "
+"for more information and <systemitem role=\"package\">hello-dbs</systemitem> "
+"for an example."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:116
+msgid ""
+"<command>dpatch</command> also provides these facilities, but it's intended "
+"to be even easier to use. See the package <systemitem role=\"package"
+"\">dpatch</systemitem> for documentation and examples (in <filename>/usr/"
+"share/doc/dpatch</filename>)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:124
+msgid "Multiple binary packages"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:126
+msgid ""
+"A single source package will often build several binary packages, either to "
+"provide several flavors of the same software (e.g., the <systemitem role="
+"\"package\">vim</systemitem> source package) or to make several small "
+"packages instead of a big one (e.g., so the user can install only the subset "
+"needed, and thus save some disk space)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:133
+msgid ""
+"The second case can be easily managed in <filename>debian/rules</filename>. "
+"You just need to move the appropriate files from the build directory into "
+"the package's temporary trees. You can do this using <command>install</"
+"command> or <command>dh_install</command> from <systemitem role=\"package"
+"\">debhelper</systemitem>. Be sure to check the different permutations of "
+"the various packages, ensuring that you have the inter-package dependencies "
+"set right in <filename>debian/control</filename>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:142
+msgid ""
+"The first case is a bit more difficult since it involves multiple recompiles "
+"of the same software but with different configuration options. The "
+"<systemitem role=\"package\">vim</systemitem> source package is an example "
+"of how to manage this using an hand-crafted <filename>debian/rules</"
+"filename> file."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: best-pkging-practices.dbk:154
+msgid "Best practices for <filename>debian/control</filename>"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:156
+msgid ""
+"The following practices are relevant to the <filename>debian/control</"
+"filename> file. They supplement the <ulink url=\"&url-debian-policy;ch-"
+"binary.html#s-descriptions\">Policy on package descriptions</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:162
+msgid ""
+"The description of the package, as defined by the corresponding field in the "
+"<filename>control</filename> file, contains both the package synopsis and "
+"the long description for the package. <xref linkend=\"bpp-desc-basics\"/> "
+"describes common guidelines for both parts of the package description. "
+"Following that, <xref linkend=\"bpp-pkg-synopsis\"/> provides guidelines "
+"specific to the synopsis, and <xref linkend=\"bpp-pkg-desc\"/> contains "
+"guidelines specific to the description."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:171
+msgid "General guidelines for package descriptions"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:173
+msgid ""
+"The package description should be written for the average likely user, the "
+"average person who will use and benefit from the package. For instance, "
+"development packages are for developers, and can be technical in their "
+"language. More general-purpose applications, such as editors, should be "
+"written for a less technical user."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:180
+msgid ""
+"Our review of package descriptions lead us to conclude that most package "
+"descriptions are technical, that is, are not written to make sense for non-"
+"technical users. Unless your package really is only for technical users, "
+"this is a problem."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:186
+msgid ""
+"How do you write for non-technical users? Avoid jargon. Avoid referring to "
+"other applications or frameworks that the user might not be familiar with — "
+"GNOME or KDE is fine, since users are probably familiar with these terms, "
+"but GTK+ is probably not. Try not to assume any knowledge at all. If you "
+"must use technical terms, introduce them."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:193
+msgid ""
+"Be objective. Package descriptions are not the place for advocating your "
+"package, no matter how much you love it. Remember that the reader may not "
+"care about the same things you care about."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:198
+msgid ""
+"References to the names of any other software packages, protocol names, "
+"standards, or specifications should use their canonical forms, if one "
+"exists. For example, use X Window System, X11, or X; not X Windows, X-"
+"Windows, or X Window. Use GTK+, not GTK or gtk. Use GNOME, not Gnome. Use "
+"PostScript, not Postscript or postscript."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:205
+msgid ""
+"If you are having problems writing your description, you may wish to send it "
+"along to &email-debian-l10n-english; and request feedback."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:211
+msgid "The package synopsis, or short description"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:213
+msgid ""
+"The synopsis line (the short description) should be concise. It must not "
+"repeat the package's name (this is policy)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:217
+msgid ""
+"It's a good idea to think of the synopsis as an appositive clause, not a "
+"full sentence. An appositive clause is defined in WordNet as a grammatical "
+"relation between a word and a noun phrase that follows, e.g., Rudolph the "
+"red-nosed reindeer. The appositive clause here is red-nosed reindeer. "
+"Since the synopsis is a clause, rather than a full sentence, we recommend "
+"that it neither start with a capital nor end with a full stop (period). It "
+"should also not begin with an article, either definite (the) or indefinite "
+"(a or an)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:226
+msgid ""
+"It might help to imagine that the synopsis is combined with the package name "
+"in the following way:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: best-pkging-practices.dbk:230
+#, no-wrap
+msgid "<replaceable>package-name</replaceable> is a <replaceable>synopsis</replaceable>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:233
+msgid "Alternatively, it might make sense to think of it as"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: best-pkging-practices.dbk:236
+#, no-wrap
+msgid "<replaceable>package-name</replaceable> is <replaceable>synopsis</replaceable>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:239
+msgid "or, if the package name itself is a plural (such as developers-tools)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: best-pkging-practices.dbk:242
+#, no-wrap
+msgid "<replaceable>package-name</replaceable> are <replaceable>synopsis</replaceable>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:245
+msgid ""
+"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 sentence."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:252
+msgid "The long description"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:254
+msgid ""
+"The long description is the primary information available to the user about "
+"a package before they install it. It should provide all the information "
+"needed to let the user decide whether to install the package. Assume that "
+"the user has already read the package synopsis."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:260
+msgid "The long description should consist of full and complete sentences."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:263
+msgid ""
+"The first paragraph of the long description should answer the following "
+"questions: what does the package do? what task does it help the user "
+"accomplish? It is important to describe this in a non-technical way, unless "
+"of course the audience for the package is necessarily technical."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:269
+msgid ""
+"The following paragraphs should answer the following questions: Why do I as "
+"a user need this package? What other features does the package have? What "
+"outstanding features and deficiencies are there compared to other packages "
+"(e.g., if you need X, use Y instead)? Is this package related to other "
+"packages in some way that is not handled by the package manager (e.g., this "
+"is the client for the foo server)?"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:277
+msgid ""
+"Be careful to avoid spelling and grammar mistakes. Ensure that you spell-"
+"check it. Both <command>ispell</command> and <command>aspell</command> have "
+"special modes for checking <filename>debian/control</filename> files:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: best-pkging-practices.dbk:282
+#, no-wrap
+msgid "ispell -d american -g debian/control"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: best-pkging-practices.dbk:285
+#, no-wrap
+msgid "aspell -d en -D -c debian/control"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:288
+msgid ""
+"Users usually expect these questions to be answered in the package "
+"description:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:293
+msgid ""
+"What does the package do? If it is an add-on to another package, then the "
+"short description of the package we are an add-on to should be put in here."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:299
+msgid ""
+"Why should I want this package? This is related to the above, but not the "
+"same (this is a mail user agent; this is cool, fast, interfaces with PGP and "
+"LDAP and IMAP, has features X, Y, and Z)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:306
+msgid ""
+"If this package should not be installed directly, but is pulled in by "
+"another package, this should be mentioned."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:312
+msgid ""
+"If the package is experimental, or there are other reasons it should not be "
+"used, if there are other packages that should be used instead, it should be "
+"here as well."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:319
+msgid ""
+"How is this package different from the competition? Is it a better "
+"implementation? more features? different features? Why should I choose this "
+"package."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:332
+msgid "Upstream home page"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:334
+msgid ""
+"We recommend that you add the URL for the package's home page to the package "
+"description in <filename>debian/control</filename>. This information should "
+"be added at the end of description, using the following format:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: best-pkging-practices.dbk:339
+#, no-wrap
+msgid ""
+".\n"
+" Homepage: http://some-project.some-place.org/"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:343
+msgid ""
+"Note the spaces prepending the line, which serves to break the lines "
+"correctly. To see an example of how this displays, see <ulink url=\"&url-eg-"
+"desc-upstream-info;\"></ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:348
+msgid ""
+"If there is no home page for the software, this should naturally be left out."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:351
+msgid ""
+"Note that we expect this field will eventually be replaced by a proper "
+"<filename>debian/control</filename> field understood by <command>dpkg</"
+"command> and <literal>&packages-host;</literal>. If you don't want to "
+"bother migrating the home page from the description to this field, you "
+"should probably wait until that is available. Please make sure that this "
+"line matches the regular expression <literal>/^ Homepage: [^ ]*$/</literal>, "
+"as this allows <filename>&packages-host;</filename> to parse it correctly."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:362
+msgid "Version Control System location"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:364
+msgid ""
+"There are additional fields for the location of the Version Control System "
+"in <filename>debian/control</filename>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:368
+msgid "XS-Vcs-Browser"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:370
+msgid ""
+"Value of this field should be a <literal>http://</literal> URL pointing to a "
+"web-browsable copy of the Version Control System repository used to maintain "
+"the given package, if available."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:375
+msgid ""
+"The information is meant to be useful for the final user, willing to browse "
+"the latest work done on the package (e.g. when looking for the patch fixing "
+"a bug tagged as <literal>pending</literal> in the bug tracking system)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:382
+msgid "XS-Vcs-*"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:384
+msgid ""
+"Value of this field should be a string identifying unequivocally the "
+"location of the Version Control System repository used to maintain the given "
+"package, if available. <literal>*</literal> identify the Version Control "
+"System; currently the following systems are supported by the package "
+"tracking system: <literal>arch</literal>, <literal>bzr</literal> (Bazaar), "
+"<literal>cvs</literal>, <literal>darcs</literal>, <literal>git</literal>, "
+"<literal>hg</literal> (Mercurial), <literal>mtn</literal> (Monotone), "
+"<literal>svn</literal> (Subversion). It is allowed to specify different VCS "
+"fields for the same package: they will all be shown in the PTS web interface."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:395
+msgid ""
+"The information is meant to be useful for a user knowledgeable in the given "
+"Version Control System and willing to build the current version of a package "
+"from the VCS sources. Other uses of this information might include "
+"automatic building of the latest VCS version of the given package. To this "
+"end the location pointed to by the field should better be version agnostic "
+"and point to the main branch (for VCSs supporting such a concept). Also, "
+"the location pointed to should be accessible to the final user; fulfilling "
+"this requirement might imply pointing to an anonymous access of the "
+"repository instead of pointing to an SSH-accessible version of the same."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:406
+msgid ""
+"In the following example, an instance of the field for a Subversion "
+"repository of the <systemitem role=\"package\">vim</systemitem> package is "
+"shown. Note how the URL is in the <literal>svn://</literal> scheme (instead "
+"of <literal>svn+ssh://</literal>) and how it points to the <filename>trunk/</"
+"filename> branch. The use of the <literal>XS-Vcs-Browser</literal> field "
+"described above is also shown."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><screen>
+#: best-pkging-practices.dbk:414
+#, no-wrap
+msgid ""
+"Source: vim\n"
+" Section: editors\n"
+" Priority: optional\n"
+" <snip>\n"
+" XS-Vcs-Svn: svn://svn.debian.org/svn/pkg-vim/trunk/packages/vim\n"
+" XS-Vcs-Browser: http://svn.debian.org/wsvn/pkg-vim/trunk/packages/vim"
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: best-pkging-practices.dbk:428
+msgid "Best practices for <filename>debian/changelog</filename>"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:430
+msgid ""
+"The following practices supplement the <ulink url=\"&url-debian-policy;ch-"
+"docs.html#s-changelogs\">Policy on changelog files</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:435
+msgid "Writing useful changelog entries"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:437
+msgid ""
+"The changelog entry for a package revision documents changes in that "
+"revision, and only them. Concentrate on describing significant and user-"
+"visible changes that were made since the last version."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:442
+msgid ""
+"Focus on <emphasis>what</emphasis> was changed — who, how and when are "
+"usually less important. Having said that, remember to politely attribute "
+"people who have provided notable help in making the package (e.g., those who "
+"have sent in patches)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:448
+msgid ""
+"There's no need to elaborate the trivial and obvious changes. You can also "
+"aggregate several changes in one entry. On the other hand, don't be overly "
+"terse if you have undertaken a major change. Be especially clear if there "
+"are changes that affect the behaviour of the program. For further "
+"explanations, use the <filename>README.Debian</filename> file."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:455
+msgid ""
+"Use common English so that the majority of readers can comprehend it. Avoid "
+"abbreviations, tech-speak and jargon when explaining changes that close "
+"bugs, especially for bugs filed by users that did not strike you as "
+"particularly technically savvy. Be polite, don't swear."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:461
+msgid ""
+"It is sometimes desirable to prefix changelog entries with the names of the "
+"files that were changed. However, there's no need to explicitly list each "
+"and every last one of the changed files, especially if the change was small "
+"or repetitive. You may use wildcards."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:467
+msgid ""
+"When referring to bugs, don't assume anything. Say what the problem was, "
+"how it was fixed, and append the closes: #nnnnn string. See <xref linkend="
+"\"upload-bugfix\"/> for more information."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:474
+msgid "Common misconceptions about changelog entries"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:476
+msgid ""
+"The changelog entries should <emphasis role=\"strong\">not</emphasis> "
+"document generic packaging issues (Hey, if you're looking for foo.conf, it's "
+"in /etc/blah/.), since administrators and users are supposed to be at least "
+"remotely acquainted with how such things are generally arranged on Debian "
+"systems. Do, however, mention if you change the location of a configuration "
+"file."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:484
+msgid ""
+"The only bugs closed with a changelog entry should be those that are "
+"actually fixed in the same package revision. Closing unrelated bugs in the "
+"changelog is bad practice. See <xref linkend=\"upload-bugfix\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:489
+msgid ""
+"The changelog entries should <emphasis role=\"strong\">not</emphasis> be "
+"used for random discussion with bug reporters (I don't see segfaults when "
+"starting foo with option bar; send in more info), general statements on "
+"life, the universe and everything (sorry this upload took me so long, but I "
+"caught the flu), or pleas for help (the bug list on this package is huge, "
+"please lend me a hand). Such things usually won't be noticed by their "
+"target audience, but may annoy people who wish to read information about "
+"actual changes in the package. See <xref linkend=\"bug-answering\"/> for "
+"more information on how to use the bug tracking system."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:500
+msgid ""
+"It is an old tradition to acknowledge bugs fixed in non-maintainer uploads "
+"in the first changelog entry of the proper maintainer upload. As we have "
+"version tracking now, it is enough to keep the NMUed changelog entries and "
+"just mention this fact in your own changelog entry."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:508
+msgid "Common errors in changelog entries"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:510
+msgid ""
+"The following examples demonstrate some common errors or examples of bad "
+"style in changelog entries."
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: best-pkging-practices.dbk:514
+#, no-wrap
+msgid "* Fixed all outstanding bugs."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:517
+msgid "This doesn't tell readers anything too useful, obviously."
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: best-pkging-practices.dbk:520
+#, no-wrap
+msgid "* Applied patch from Jane Random."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:523
+msgid "What was the patch about?"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: best-pkging-practices.dbk:526
+#, no-wrap
+msgid "* Late night install target overhaul."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:529
+msgid ""
+"Overhaul which accomplished what? Is the mention of late night supposed to "
+"remind us that we shouldn't trust that code?"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: best-pkging-practices.dbk:533
+#, no-wrap
+msgid "* Fix vsync FU w/ ancient CRTs."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:536
+msgid ""
+"Too many acronyms, and it's not overly clear what the, uh, fsckup (oops, a "
+"curse word!) was actually about, or how it was fixed."
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: best-pkging-practices.dbk:540
+#, no-wrap
+msgid "* This is not a bug, closes: #nnnnnn."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:543
+msgid ""
+"First of all, there's absolutely no need to upload the package to convey "
+"this information; instead, use the bug tracking system. Secondly, there's "
+"no explanation as to why the report is not a bug."
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: best-pkging-practices.dbk:548
+#, no-wrap
+msgid "* Has been fixed for ages, but I forgot to close; closes: #54321."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:551
+msgid ""
+"If for some reason you didn't mention the bug number in a previous changelog "
+"entry, there's no problem, just close the bug normally in the BTS. There's "
+"no need to touch the changelog file, presuming the description of the fix is "
+"already in (this applies to the fixes by the upstream authors/maintainers as "
+"well, you don't have to track bugs that they fixed ages ago in your "
+"changelog)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: best-pkging-practices.dbk:558
+#, no-wrap
+msgid "* Closes: #12345, #12346, #15432"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:561
+msgid ""
+"Where's the description? If you can't think of a descriptive message, start "
+"by inserting the title of each different bug."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:567
+msgid "Supplementing changelogs with NEWS.Debian files"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:569
+msgid ""
+"Important news about changes in a package can also be put in NEWS.Debian "
+"files. The news will be displayed by tools like apt-listchanges, before all "
+"the rest of the changelogs. This is the preferred means to let the user "
+"know about significant changes in a package. It is better than using "
+"debconf notes since it is less annoying and the user can go back and refer "
+"to the NEWS.Debian file after the install. And it's better than listing "
+"major changes in README.Debian, since the user can easily miss such notes."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:578
+msgid ""
+"The file format is the same as a debian changelog file, but leave off the "
+"asterisks and describe each news item with a full paragraph when necessary "
+"rather than the more concise summaries that would go in a changelog. It's a "
+"good idea to run your file through dpkg-parsechangelog to check its "
+"formatting as it will not be automatically checked during build as the "
+"changelog is. Here is an example of a real NEWS.Debian file:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: best-pkging-practices.dbk:586
+#, no-wrap
+msgid ""
+"cron (3.0pl1-74) unstable; urgency=low\n"
+"\n"
+" The checksecurity script is no longer included with the cron package:\n"
+" it now has its own package, checksecurity. If you liked the\n"
+" functionality provided with that script, please install the new\n"
+" package.\n"
+"\n"
+" -- Steve Greenland <stevegr@debian.org> Sat, 6 Sep 2003 17:15:03 -0500"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:596
+msgid ""
+"The NEWS.Debian file is installed as /usr/share/doc/<package>/NEWS."
+"Debian.gz. It is compressed, and always has that name even in Debian native "
+"packages. If you use debhelper, dh_installchangelogs will install debian/"
+"NEWS files for you."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:602
+msgid ""
+"Unlike changelog files, you need not update NEWS.Debian files with every "
+"release. Only update them if you have something particularly newsworthy "
+"that user should know about. If you have no news at all, there's no need to "
+"ship a NEWS.Debian file in your package. No news is good news!"
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: best-pkging-practices.dbk:623
+msgid "Best practices for maintainer scripts"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:625
+msgid ""
+"Maintainer scripts include the files <filename>debian/postinst</filename>, "
+"<filename>debian/preinst</filename>, <filename>debian/prerm</filename> and "
+"<filename>debian/postrm</filename>. These scripts take care of any package "
+"installation or deinstallation setup which isn't handled merely by the "
+"creation or removal of files and directories. The following instructions "
+"supplement the <ulink url=\"&url-debian-policy;\">Debian Policy</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:633
+msgid ""
+"Maintainer scripts must be idempotent. That means that you need to make "
+"sure nothing bad will happen if the script is called twice where it would "
+"usually be called once."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:638
+msgid ""
+"Standard input and output may be redirected (e.g. into pipes) for logging "
+"purposes, so don't rely on them being a tty."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:642
+msgid ""
+"All prompting or interactive configuration should be kept to a minimum. "
+"When it is necessary, you should use the <systemitem role=\"package"
+"\">debconf</systemitem> package for the interface. Remember that prompting "
+"in any case can only be in the <literal>configure</literal> stage of the "
+"<filename>postinst</filename> script."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:649
+msgid ""
+"Keep the maintainer scripts as simple as possible. We suggest you use pure "
+"POSIX shell scripts. Remember, if you do need any bash features, the "
+"maintainer script must have a bash shebang line. POSIX shell or Bash are "
+"preferred to Perl, since they enable <systemitem role=\"package\">debhelper</"
+"systemitem> to easily add bits to the scripts."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:656
+msgid ""
+"If you change your maintainer scripts, be sure to test package removal, "
+"double installation, and purging. Be sure that a purged package is "
+"completely gone, that is, it must remove any files created, directly or "
+"indirectly, in any maintainer script."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:662
+msgid ""
+"If you need to check for the existence of a command, you should use "
+"something like"
+msgstr ""
+
+# type: Content of: <chapter><section><programlisting>
+#: best-pkging-practices.dbk:665
+#, no-wrap
+msgid "if [ -x /usr/sbin/install-docs ]; then ..."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:667
+msgid ""
+"If you don't wish to hard-code the path of a command in your maintainer "
+"script, the following POSIX-compliant shell function may help:"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:672
+msgid ""
+"You can use this function to search <literal>$PATH</literal> for a command "
+"name, passed as an argument. It returns true (zero) if the command was "
+"found, and false if not. This is really the most portable way, since "
+"<literal>command -v</literal>, <command>type</command>, and <command>which</"
+"command> are not POSIX."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:679
+msgid ""
+"While <command>which</command> is an acceptable alternative, since it is "
+"from the required <systemitem role=\"package\">debianutils</systemitem> "
+"package, it's not on the root partition. That is, it's in <filename>/usr/"
+"bin</filename> rather than <filename>/bin</filename>, so one can't use it in "
+"scripts which are run before the <filename>/usr</filename> partition is "
+"mounted. Most scripts won't have this problem, though."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: best-pkging-practices.dbk:689
+msgid ""
+"Configuration management with <systemitem role=\"package\">debconf</"
+"systemitem>"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:691
+msgid ""
+"<systemitem role=\"package\">Debconf</systemitem> is a configuration "
+"management system which can be used by all the various packaging scripts "
+"(<filename>postinst</filename> mainly) to request feedback from the user "
+"concerning how to configure the package. Direct user interactions must now "
+"be avoided in favor of <systemitem role=\"package\">debconf</systemitem> "
+"interaction. This will enable non-interactive installations in the future."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:699
+msgid ""
+"Debconf is a great tool but it is often poorly used. Many common mistakes "
+"are listed in the <citerefentry> <refentrytitle>debconf-devel</"
+"refentrytitle> <manvolnum>7</manvolnum> </citerefentry> man page. It is "
+"something that you must read if you decide to use debconf. Also, we "
+"document some best practices here."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:706
+msgid ""
+"These guidelines include some writing style and typography recommendations, "
+"general considerations about debconf usage as well as more specific "
+"recommendations for some parts of the distribution (the installation system "
+"for instance)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:712
+msgid "Do not abuse debconf"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:714
+msgid ""
+"Since debconf appeared in Debian, it has been widely abused and several "
+"criticisms received by the Debian distribution come from debconf abuse with "
+"the need of answering a wide bunch of questions before getting any little "
+"thing installed."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:720
+msgid ""
+"Keep usage notes to what they belong: the NEWS.Debian, or README.Debian "
+"file. Only use notes for important notes which may directly affect the "
+"package usability. Remember that notes will always block the install until "
+"confirmed or bother the user by email."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:726
+msgid ""
+"Carefully choose the questions priorities in maintainer scripts. See "
+"<citerefentry> <refentrytitle>debconf-devel</refentrytitle> <manvolnum>7</"
+"manvolnum> </citerefentry> for details about priorities. Most questions "
+"should use medium and low priorities."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:734
+msgid "General recommendations for authors and translators"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:736
+msgid "Write correct English"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:738
+msgid ""
+"Most Debian package maintainers are not native English speakers. So, "
+"writing properly phrased templates may not be easy for them."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:742
+msgid ""
+"Please use (and abuse) &email-debian-l10n-english; mailing list. Have your "
+"templates proofread."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:746
+msgid ""
+"Badly written templates give a poor image of your package, of your work...or "
+"even of Debian itself."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:750
+msgid ""
+"Avoid technical jargon as much as possible. If some terms sound common to "
+"you, they may be impossible to understand for others. If you cannot avoid "
+"them, try to explain them (use the extended description). When doing so, "
+"try to balance between verbosity and simplicity."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:758
+msgid "Be kind to translators"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:760
+msgid ""
+"Debconf templates may be translated. Debconf, along with its sister package "
+"<command>po-debconf</command> offers a simple framework for getting "
+"templates translated by translation teams or even individuals."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:765
+msgid ""
+"Please use gettext-based templates. Install <systemitem role=\"package\">po-"
+"debconf</systemitem> on your development system and read its documentation "
+"(man po-debconf is a good start)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:770
+msgid ""
+"Avoid changing templates too often. Changing templates text induces more "
+"work to translators which will get their translation fuzzied. If you plan "
+"changes to your original templates, please contact translators. Most active "
+"translators are very responsive and getting their work included along with "
+"your modified templates will save you additional uploads. If you use "
+"gettext-based templates, the translator's name and e-mail addresses are "
+"mentioned in the po files headers."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:779
+msgid ""
+"The use of the <command>podebconf-report-po</command> from the po-debconf "
+"package is highly recommended to warn translators which have incomplete "
+"translations and request them for updates."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:784
+msgid ""
+"If in doubt, you may also contact the translation team for a given language "
+"(debian-l10n-xxxxx@&lists-host;), or the &email-debian-i18n; mailing list."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:789
+msgid ""
+"Calls for translations posted to &email-debian-i18n; with the "
+"<filename>debian/po/templates.pot</filename> file attached or referenced in "
+"a URL are encouraged. Be sure to mentions in these calls for new "
+"translations which languages you have existing translations for, in order to "
+"avoid duplicate work."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:798
+msgid "Unfuzzy complete translations when correcting typos and spelling"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:800
+msgid ""
+"When the text of a debconf template is corrected and you are <emphasis role="
+"\"strong\">sure</emphasis> that the change does <emphasis role=\"strong"
+"\">not</emphasis> affect translations, please be kind to translators and "
+"unfuzzy their translations."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:806
+msgid ""
+"If you don't do so, the whole template will not be translated as long as a "
+"translator will send you an update."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:810
+msgid ""
+"To <emphasis role=\"strong\">unfuzzy</emphasis> translations, you can "
+"proceed the following way:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
+#: best-pkging-practices.dbk:816
+msgid ""
+"Put all incomplete PO files out of the way. You can check the completeness "
+"by using (needs the <systemitem role=\"package\">gettext</systemitem> "
+"package installed):"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><programlisting>
+#: best-pkging-practices.dbk:820
+#, no-wrap
+msgid ""
+"for i in debian/po/*po; do echo -n $i: ; msgfmt -o /dev/null\n"
+"--statistics $i; done"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
+#: best-pkging-practices.dbk:825
+msgid ""
+"move all files which report either fuzzy strings to a temporary place. "
+"Files which report no fuzzy strings (only translated and untranslated) will "
+"be kept in place."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
+#: best-pkging-practices.dbk:832
+msgid ""
+"now <emphasis role=\"strong\">and now only</emphasis>, modify the template "
+"for the typos and check again that translation are not impacted (typos, "
+"spelling errors, sometimes typographical corrections are usually OK)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
+#: best-pkging-practices.dbk:839
+msgid ""
+"run <command>debconf-updatepo</command>. This will fuzzy all strings you "
+"modified in translations. You can see this by running the above again"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
+#: best-pkging-practices.dbk:845
+msgid "use the following command:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><programlisting>
+#: best-pkging-practices.dbk:847
+#, no-wrap
+msgid "for i in debian/po/*po; do msgattrib --output-file=$i --clear-fuzzy $i; done"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
+#: best-pkging-practices.dbk:851
+msgid ""
+"move back to debian/po the files which showed fuzzy strings in the first step"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
+#: best-pkging-practices.dbk:856
+msgid "run <command>debconf-updatepo</command> again"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:863
+msgid "Do not make assumptions about interfaces"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:865
+msgid ""
+"Templates text should not make reference to widgets belonging to some "
+"debconf interfaces. Sentences like If you answer Yes... have no meaning "
+"for users of graphical interfaces which use checkboxes for boolean questions."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:870
+msgid ""
+"String templates should also avoid mentioning the default values in their "
+"description. First, because this is redundant with the values seen by the "
+"users. Also, because these default values may be different from the "
+"maintainer choices (for instance, when the debconf database was preseeded)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:876
+msgid ""
+"More generally speaking, try to avoid referring to user actions. Just give "
+"facts."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:882
+msgid "Do not use first person"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:884
+msgid ""
+"You should avoid the use of first person (I will do this... or We "
+"recommend...). The computer is not a person and the Debconf templates do "
+"not speak for the Debian developers. You should use neutral construction. "
+"Those of you who already wrote scientific publications, just write your "
+"templates like you would write a scientific paper. However, try using "
+"action voice if still possible, like Enable this if ... instead of This can "
+"be enabled if ...."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:894
+msgid "Be gender neutral"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:896
+msgid ""
+"The world is made of men and women. Please use gender-neutral constructions "
+"in your writing."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:904
+msgid "Templates fields definition"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:906
+msgid ""
+"This part gives some information which is mostly taken from the "
+"<citerefentry> <refentrytitle>debconf-devel</refentrytitle> <manvolnum>7</"
+"manvolnum> </citerefentry> manual page."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:911
+msgid "Type"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><title>
+#: best-pkging-practices.dbk:913
+msgid "string:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><para>
+#: best-pkging-practices.dbk:915
+msgid ""
+"Results in a free-form input field that the user can type any string into."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><title>
+#: best-pkging-practices.dbk:920
+msgid "password:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><para>
+#: best-pkging-practices.dbk:922
+msgid ""
+"Prompts the user for a password. Use this with caution; be aware that the "
+"password the user enters will be written to debconf's database. You should "
+"probably clean that value out of the database as soon as is possible."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><title>
+#: best-pkging-practices.dbk:929
+msgid "boolean:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><para>
+#: best-pkging-practices.dbk:931
+msgid ""
+"A true/false choice. Remember: true/false, <emphasis role=\"strong\">not "
+"yes/no</emphasis>..."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><title>
+#: best-pkging-practices.dbk:937
+msgid "select:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><para>
+#: best-pkging-practices.dbk:939
+msgid ""
+"A choice between one of a number of values. The choices must be specified "
+"in a field named 'Choices'. Separate the possible values with commas and "
+"spaces, like this: Choices: yes, no, maybe"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><title>
+#: best-pkging-practices.dbk:946
+msgid "multiselect:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><para>
+#: best-pkging-practices.dbk:948
+msgid ""
+"Like the select data type, except the user can choose any number of items "
+"from the choices list (or chose none of them)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><title>
+#: best-pkging-practices.dbk:954
+msgid "note:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><para>
+#: best-pkging-practices.dbk:956
+msgid ""
+"Rather than being a question per se, this datatype indicates a note that can "
+"be displayed to the user. It should be used only for important notes that "
+"the user really should see, since debconf will go to great pains to make "
+"sure the user sees it; halting the install for them to press a key, and even "
+"mailing the note to them in some cases."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><title>
+#: best-pkging-practices.dbk:965
+msgid "text:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><para>
+#: best-pkging-practices.dbk:967
+msgid "This type is now considered obsolete: don't use it."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><title>
+#: best-pkging-practices.dbk:972
+msgid "error:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><para>
+#: best-pkging-practices.dbk:974
+msgid ""
+"This type is designed to handle error messages. It is mostly similar to the "
+"note type. Frontends may present it differently (for instance, the dialog "
+"frontend of cdebconf draws a red screen instead of the usual blue one)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><para>
+#: best-pkging-practices.dbk:979
+msgid ""
+"It is recommended to use this type for any message that needs user attention "
+"for a correction of any kind."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:987
+msgid "Description: short and extended description"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:989
+msgid ""
+"Template descriptions have two parts: short and extended. The short "
+"description is in the Description: line of the template."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:993
+msgid ""
+"The short description should be kept short (50 characters or so) so that it "
+"may be accomodated by most debconf interfaces. Keeping it short also helps "
+"translators, as usually translations tend to end up being longer than the "
+"original."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:999
+msgid ""
+"The short description should be able to stand on its own. Some interfaces "
+"do not show the long description by default, or only if the user explicitely "
+"asks for it or even do not show it at all. Avoid things like What do you "
+"want to do?"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1005
+msgid ""
+"The short description does not necessarily have to be a full sentence. This "
+"is part of the keep it short and efficient recommendation."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1009
+msgid ""
+"The extended description should not repeat the short description word for "
+"word. If you can't think up a long description, then first, think some "
+"more. Post to debian-devel. Ask for help. Take a writing class! That "
+"extended description is important. If after all that you still can't come "
+"up with anything, leave it blank."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1016
+msgid ""
+"The extended description should use complete sentences. Paragraphs should "
+"be kept short for improved readability. Do not mix two ideas in the same "
+"paragraph but rather use another paragraph."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1021
+msgid ""
+"Don't be too verbose. User tend to ignore too long screens. 20 lines are "
+"by experience a border you shouldn't cross, because that means that in the "
+"classical dialog interface, people will need to scroll, and lot of people "
+"just don't do that."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1027
+msgid ""
+"The extended description should <emphasis role=\"strong\">never</emphasis> "
+"include a question."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1031
+msgid ""
+"For specific rules depending on templates type (string, boolean, etc.), "
+"please read below."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:1037
+msgid "Choices"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1039
+msgid ""
+"This field should be used for Select and Multiselect types. It contains the "
+"possible choices which will be presented to users. These choices should be "
+"separated by commas."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:1046
+msgid "Default"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1048
+msgid ""
+"This field is optional. It contains the default answer for string, select "
+"and multiselect templates. For multiselect templates, it may contain a "
+"comma-separated list of choices."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:1057
+msgid "Templates fields specific style guide"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:1059
+msgid "Type field"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1061
+msgid ""
+"No specific indication except: use the appropriate type by referring to the "
+"previous section."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:1067
+msgid "Description field"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1069
+msgid ""
+"Below are specific instructions for properly writing the Description (short "
+"and extended) depending on the template type."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><title>
+#: best-pkging-practices.dbk:1073
+msgid "String/password templates"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:1077
+msgid ""
+"The short description is a prompt and <emphasis role=\"strong\">not</"
+"emphasis> a title. Avoid question style prompts (IP Address?) in favour of "
+"opened prompts (IP address:). The use of colons is recommended."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:1084
+msgid ""
+"The extended description is a complement to the short description. In the "
+"extended part, explain what is being asked, rather than ask the same "
+"question again using longer words. Use complete sentences. Terse writing "
+"style is strongly discouraged."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><title>
+#: best-pkging-practices.dbk:1094
+msgid "Boolean templates"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:1098
+msgid ""
+"The short description should be phrased in the form of a question which "
+"should be kept short and should generally end with a question mark. Terse "
+"writing style is permitted and even encouraged if the question is rather "
+"long (remember that translations are often longer than original versions)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:1106
+msgid ""
+"Again, please avoid referring to specific interface widgets. A common "
+"mistake for such templates is if you answer Yes-type constructions."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><title>
+#: best-pkging-practices.dbk:1114
+msgid "Select/Multiselect"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:1118
+msgid ""
+"The short description is a prompt and <emphasis role=\"strong\">not</"
+"emphasis> a title. Do <emphasis role=\"strong\">not</emphasis> use useless "
+"Please choose... constructions. Users are clever enough to figure out they "
+"have to choose something...:)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:1126
+msgid ""
+"The extended description will complete the short description. It may refer "
+"to the available choices. It may also mention that the user may choose more "
+"than one of the available choices, if the template is a multiselect one "
+"(although the interface often makes this clear)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><title>
+#: best-pkging-practices.dbk:1136
+msgid "Notes"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:1140
+msgid "The short description should be considered to be a *title*."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:1145
+msgid ""
+"The extended description is what will be displayed as a more detailed "
+"explanation of the note. Phrases, no terse writing style."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:1151
+msgid ""
+"<emphasis role=\"strong\">Do not abuse debconf.</emphasis> Notes are the "
+"most common way to abuse debconf. As written in debconf-devel manual page: "
+"it's best to use them only for warning about very serious problems. The "
+"NEWS.Debian or README.Debian files are the appropriate location for a lot of "
+"notes. If, by reading this, you consider converting your Note type "
+"templates to entries in NEWS/Debian or README.Debian, plus consider keeping "
+"existing translations for the future."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:1166
+msgid "Choices field"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1168
+msgid ""
+"If the Choices are likely to change often, please consider using the "
+"__Choices trick. This will split each individual choice into a single "
+"string, which will considerably help translators for doing their work."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:1175 best-pkging-practices.dbk:1213
+msgid "Default field"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1177
+msgid ""
+"If the default value, for a select template, is likely to vary depending on "
+"the user language (for instance, if the choice is a language choice), please "
+"use the _DefaultChoice trick."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1182
+msgid ""
+"This special field allow translators to put the most appropriate choice "
+"according to their own language. It will become the default choice when "
+"their language is used while your own mentioned Default Choice will be used "
+"chan using English."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1188
+msgid "Example, taken from the geneweb package templates:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><screen>
+#: best-pkging-practices.dbk:1191
+#, no-wrap
+msgid ""
+"Template: geneweb/lang\n"
+"Type: select\n"
+"__Choices: Afrikaans (af), Bulgarian (bg), Catalan (ca), Chinese (zh), Czech (cs), Danish (da), Dutch (nl), English (en), Esperanto (eo), Estonian (et), Finnish (fi), French (fr), German (de), Hebrew (he), Icelandic (is), Italian (it), Latvian (lv), Norwegian (no), Polish (pl), Portuguese (pt), Romanian (ro), Russian (ru), Spanish (es), Swedish (sv)\n"
+"# This is the default choice. Translators may put their own language here\n"
+"# instead of the default.\n"
+"# WARNING : you MUST use the ENGLISH FORM of your language\n"
+"# For instance, the french translator will need to put French (fr) here.\n"
+"_DefaultChoice: English (en)[ translators, please see comment in PO files]\n"
+"_Description: Geneweb default language:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1202
+msgid ""
+"Note the use of brackets which allow internal comments in debconf fields. "
+"Also note the use of comments which will show up in files the translators "
+"will work with."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1207
+msgid ""
+"The comments are needed as the DefaultChoice trick is a bit confusing: the "
+"translators may put their own choice"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1215
+msgid ""
+"Do NOT use empty default field. If you don't want to use default values, do "
+"not use Default at all."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1219
+msgid ""
+"If you use po-debconf (and you <emphasis role=\"strong\">should</emphasis>, "
+"see 2.2), consider making this field translatable, if you think it may be "
+"translated."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1224
+msgid ""
+"If the default value may vary depending on language/country (for instance "
+"the default value for a language choice), consider using the special "
+"_DefaultChoice type documented in <citerefentry> <refentrytitle>po-debconf</"
+"refentrytitle> <manvolnum>7</manvolnum> </citerefentry>)."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: best-pkging-practices.dbk:1236
+msgid "Internationalization"
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:1238
+msgid "Handling debconf translations"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1240
+msgid ""
+"Like porters, translators have a difficult task. They work on many packages "
+"and must collaborate with many different maintainers. Moreover, most of the "
+"time, they are not native English speakers, so you may need to be "
+"particularly patient with them."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1246
+msgid ""
+"The goal of <systemitem role=\"package\">debconf</systemitem> was to make "
+"packages configuration easier for maintainers and for users. Originally, "
+"translation of debconf templates was handled with <command>debconf-"
+"mergetemplate</command>. However, that technique is now deprecated; the "
+"best way to accomplish <systemitem role=\"package\">debconf</systemitem> "
+"internationalization is by using the <systemitem role=\"package\">po-"
+"debconf</systemitem> package. This method is easier both for maintainer and "
+"translators; transition scripts are provided."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1256
+msgid ""
+"Using <systemitem role=\"package\">po-debconf</systemitem>, the translation "
+"is stored in <filename>po</filename> files (drawing from <command>gettext</"
+"command> translation techniques). Special template files contain the "
+"original messages and mark which fields are translatable. When you change "
+"the value of a translatable field, by calling <command>debconf-updatepo</"
+"command>, the translation is marked as needing attention from the "
+"translators. Then, at build time, the <command>dh_installdebconf</command> "
+"program takes care of all the needed magic to add the template along with "
+"the up-to-date translations into the binary packages. Refer to the "
+"<citerefentry> <refentrytitle>po-debconf</refentrytitle> <manvolnum>7</"
+"manvolnum> </citerefentry> manual page for details."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:1272
+msgid "Internationalized documentation"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1274
+msgid ""
+"Internationalizing documentation is crucial for users, but a lot of labor. "
+"There's no way to eliminate all that work, but you can make things easier "
+"for translators."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1279
+msgid ""
+"If you maintain documentation of any size, its easier for translators if "
+"they have access to a source control system. That lets translators see the "
+"differences between two versions of the documentation, so, for instance, "
+"they can see what needs to be retranslated. It is recommended that the "
+"translated documentation maintain a note about what source control revision "
+"the translation is based on. An interesting system is provided by <ulink "
+"url=\"&url-i18n-doc-check;\">doc-check</ulink> in the <systemitem role="
+"\"package\">boot-floppies</systemitem> package, which shows an overview of "
+"the translation status for any given language, using structured comments for "
+"the current revision of the file to be translated and, for a translated "
+"file, the revision of the original file the translation is based on. You "
+"might wish to adapt and provide that in your CVS area."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1293
+msgid ""
+"If you maintain XML or SGML documentation, we suggest that you isolate any "
+"language-independent information and define those as entities in a separate "
+"file which is included by all the different translations. This makes it "
+"much easier, for instance, to keep URLs up to date across multiple files."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: best-pkging-practices.dbk:1303
+msgid "Common packaging situations"
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:1314
+msgid "Packages using <command>autoconf</command>/<command>automake</command>"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1316
+msgid ""
+"Keeping <command>autoconf</command>'s <filename>config.sub</filename> and "
+"<filename>config.guess</filename> files up to date is critical for porters, "
+"especially on more volatile architectures. Some very good packaging "
+"practices for any package using <command>autoconf</command> and/or "
+"<command>automake</command> have been synthesized in &file-bpp-autotools; "
+"from the <systemitem role=\"package\">autotools-dev</systemitem> package. "
+"You're strongly encouraged to read this file and to follow the given "
+"recommendations."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:1328
+msgid "Libraries"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1330
+msgid ""
+"Libraries are always difficult to package for various reasons. The policy "
+"imposes many constraints to ease their maintenance and to make sure upgrades "
+"are as simple as possible when a new upstream version comes out. Breakage "
+"in a library can result in dozens of dependent packages breaking."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1336
+msgid ""
+"Good practices for library packaging have been grouped in <ulink url=\"&url-"
+"libpkg-guide;\">the library packaging guide</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:1343
+msgid "Documentation"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1345
+msgid ""
+"Be sure to follow the <ulink url=\"&url-debian-policy;ch-docs.html\">Policy "
+"on documentation</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1350
+msgid ""
+"If your package contains documentation built from XML or SGML, we recommend "
+"you not ship the XML or SGML source in the binary package(s). If users want "
+"the source of the documentation, they should retrieve the source package."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1355
+msgid ""
+"Policy specifies that documentation should be shipped in HTML format. We "
+"also recommend shipping documentation in PDF and plain text format if "
+"convenient and if output of reasonable quality is possible. However, it is "
+"generally not appropriate to ship plain text versions of documentation whose "
+"source format is HTML."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1362
+msgid ""
+"Major shipped manuals should register themselves with <systemitem role="
+"\"package\">doc-base</systemitem> on installation. See the <systemitem role="
+"\"package\">doc-base</systemitem> package documentation for more information."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:1370
+msgid "Specific types of packages"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1372
+msgid ""
+"Several specific types of packages have special sub-policies and "
+"corresponding packaging rules and practices:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:1378
+msgid ""
+"Perl related packages have a <ulink url=\"&url-perl-policy;\">Perl policy</"
+"ulink>, some examples of packages following that policy are <systemitem role="
+"\"package\">libdbd-pg-perl</systemitem> (binary perl module) or <systemitem "
+"role=\"package\">libmldbm-perl</systemitem> (arch independent perl module)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:1387
+msgid ""
+"Python related packages have their python policy; see &file-python-policy; "
+"in the <systemitem role=\"package\">python</systemitem> package."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:1394
+msgid ""
+"Emacs related packages have the <ulink url=\"&url-emacs-policy;\">emacs "
+"policy</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:1401
+msgid ""
+"Java related packages have their <ulink url=\"&url-java-policy;\">java "
+"policy</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:1408
+msgid ""
+"Ocaml related packages have their own policy, found in &file-ocaml-policy; "
+"from the <systemitem role=\"package\">ocaml</systemitem> package. A good "
+"example is the <systemitem role=\"package\">camlzip</systemitem> source "
+"package."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:1416
+msgid ""
+"Packages providing XML or SGML DTDs should conform to the recommendations "
+"found in the <systemitem role=\"package\">sgml-base-doc</systemitem> package."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:1422
+msgid ""
+"Lisp packages should register themselves with <systemitem role=\"package"
+"\">common-lisp-controller</systemitem>, about which see &file-lisp-"
+"controller;."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:1452
+msgid "Architecture-independent data"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1454
+msgid ""
+"It is not uncommon to have a large amount of architecture-independent data "
+"packaged with a program. For example, audio files, a collection of icons, "
+"wallpaper patterns, or other graphic files. If the size of this data is "
+"negligible compared to the size of the rest of the package, it's probably "
+"best to keep it all in a single package."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1461
+msgid ""
+"However, if the size of the data is considerable, consider splitting it out "
+"into a separate, architecture-independent package (_all.deb). By doing "
+"this, you avoid needless duplication of the same data into eleven or more ."
+"debs, one per each architecture. While this adds some extra overhead into "
+"the <filename>Packages</filename> files, it saves a lot of disk space on "
+"Debian mirrors. Separating out architecture-independent data also reduces "
+"processing time of <command>lintian</command> or <command>linda</command> "
+"(see <xref linkend=\"tools-lint\"/> ) when run over the entire Debian "
+"archive."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:1473
+msgid "Needing a certain locale during build"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1475
+msgid ""
+"If you need a certain locale during build, you can create a temporary file "
+"via this trick:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1479
+msgid ""
+"If you set <varname>LOCPATH</varname> to the equivalent of <filename>/usr/"
+"lib/locale</filename>, and <varname>LC_ALL</varname> to the name of the "
+"locale you generate, you should get what you want without being root. "
+"Something like this:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: best-pkging-practices.dbk:1484
+#, no-wrap
+msgid ""
+"LOCALE_PATH=debian/tmpdir/usr/lib/locale\n"
+"LOCALE_NAME=en_IN\n"
+"LOCALE_CHARSET=UTF-8\n"
+"\n"
+"mkdir -p $LOCALE_PATH\n"
+"localedef -i $LOCALE_NAME.$LOCALE_CHARSET -f $LOCALE_CHARSET $LOCALE_PATH/$LOCALE_NAME.$LOCALE_CHARSET\n"
+"\n"
+"# Using the locale\n"
+"LOCPATH=$LOCALE_PATH LC_ALL=$LOCALE_NAME.$LOCALE_CHARSET date"
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:1497
+msgid "Make transition packages deborphan compliant"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1499
+msgid ""
+"Deborphan is a program for helping users to detect which packages can safely "
+"be removed from the system, i.e. the ones that have no packages depending "
+"on them. The default operation is to search only within the libs and "
+"oldlibs sections, to hunt down unused libraries. But when passed the right "
+"argument, it tries to catch other useless packages."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1506
+msgid ""
+"For example, with --guess-dummy, deborphan tries to search all transitional "
+"packages which were needed for upgrade but which can now safely be removed. "
+"For that, it looks for the string dummy or transitional in their short "
+"description."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1512
+msgid ""
+"So, when you are creating such a package, please make sure to add this text "
+"to your short description. If you are looking for examples, just run: "
+"<command>apt-cache search .|grep dummy</command> or <command>apt-cache "
+"search .|grep transitional</command>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:1520
+msgid "Best practices for <filename>orig.tar.gz</filename> files"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1522
+msgid ""
+"There are two kinds of original source tarballs: Pristine source and "
+"repackaged upstream source."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:1526
+msgid "Pristine source"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para><footnote>
+#: best-pkging-practices.dbk:1528
+msgid ""
+"The defining characteristic of a pristine source tarball is that the .orig."
+"tar.gz file is byte-for-byte identical to a tarball officially distributed "
+"by the upstream author. <footnote>"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para><footnote><para>
+#: best-pkging-practices.dbk:1530
+msgid ""
+"We cannot prevent upstream authors from changing the tarball they distribute "
+"without also incrementing the version number, so there can be no guarantee "
+"that a pristine tarball is identical to what upstream <emphasis>currently</"
+"emphasis> distributing at any point in time. All that can be expected is "
+"that it is identical to something that upstream once <emphasis>did</"
+"emphasis> distribute. If a difference arises later (say, if upstream "
+"notices that he wasn't using maximal comression in his original distribution "
+"and then re-<literal>gzip</literal>s it), that's just too bad. Since there "
+"is no good way to upload a new .orig.tar.gz for the same version, there is "
+"not even any point in treating this situation as a bug."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1540
+msgid ""
+"</footnote> This makes it possible to use checksums to easily verify that "
+"all changes between Debian's version and upstream's are contained in the "
+"Debian diff. Also, if the original source is huge, upstream authors and "
+"others who already have the upstream tarball can save download time if they "
+"want to inspect your packaging in detail."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1548
+msgid ""
+"There is no universally accepted guidelines that upstream authors follow "
+"regarding to the directory structure inside their tarball, but <command>dpkg-"
+"source</command> is nevertheless able to deal with most upstream tarballs as "
+"pristine source. Its strategy is equivalent to the following:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
+#: best-pkging-practices.dbk:1556
+msgid "It unpacks the tarball in an empty temporary directory by doing"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><screen>
+#: best-pkging-practices.dbk:1559
+#, no-wrap
+msgid "zcat path/to/<packagename>_<upstream-version>.orig.tar.gz | tar xf -"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
+#: best-pkging-practices.dbk:1564
+msgid ""
+"If, after this, the temporary directory contains nothing but one directory "
+"and no other files, <command>dpkg-source</command> renames that directory to "
+"<literal><packagename>-<upstream-version>(.orig)</literal>. The "
+"name of the top-level directory in the tarball does not matter, and is "
+"forgotten."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
+#: best-pkging-practices.dbk:1573
+msgid ""
+"Otherwise, the upstream tarball must have been packaged without a common top-"
+"level directory (shame on the upstream author!). In this case, "
+"<command>dpkg-source</command> renames the temporary directory "
+"<emphasis>itself</emphasis> to <literal><packagename>-<upstream-"
+"version>(.orig)</literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:1584
+msgid "Repackaged upstream source"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1586
+msgid ""
+"You <emphasis role=\"strong\">should</emphasis> upload packages with a "
+"pristine source tarball if possible, but there are various reasons why it "
+"might not be possible. This is the case if upstream does not distribute the "
+"source as gzipped tar at all, or if upstream's tarball contains non-DFSG-"
+"free material that you must remove before uploading."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1593
+msgid ""
+"In these cases the developer must construct a suitable .orig.tar.gz file "
+"himself. We refer to such a tarball as a repackaged upstream source. Note "
+"that a repackaged upstream source is different from a Debian-native "
+"package. A repackaged source still comes with Debian-specific changes in a "
+"separate <literal>.diff.gz</literal> and still has a version number composed "
+"of <literal><upstream-version></literal> and <literal><debian-"
+"revision></literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1602
+msgid ""
+"There may be cases where it is desirable to repackage the source even though "
+"upstream distributes a <literal>.tar.gz</literal> that could in principle be "
+"used in its pristine form. The most obvious is if <emphasis>significant</"
+"emphasis> space savings can be achieved by recompressing the tar archive or "
+"by removing genuinely useless cruft from the upstream archive. Use your own "
+"discretion here, but be prepared to defend your decision if you repackage "
+"source that could have been pristine."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1611
+msgid "A repackaged .orig.tar.gz"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
+#: best-pkging-practices.dbk:1616
+msgid ""
+"<emphasis role=\"strong\">must</emphasis> contain detailed information how "
+"the repackaged source was obtained, and how this can be reproduced in the "
+"<filename>debian/copyright</filename>. It is also a good idea to provide a "
+"<literal>get-orig-source</literal> target in your <filename>debian/rules</"
+"filename> file that repeats the process, as described in the Policy Manual, "
+"<ulink url=\"&url-debian-policy;ch-source.html#s-debianrules\">Main building "
+"script: debian/rules</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para><footnote>
+#: best-pkging-practices.dbk:1628
+msgid ""
+"<emphasis role=\"strong\">should not</emphasis> contain any file that does "
+"not come from the upstream author(s), or whose contents has been changed by "
+"you. <footnote>"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para><footnote><para>
+#. or similarly named
+#: best-pkging-practices.dbk:1630
+msgid ""
+"As a special exception, if the omission of non-free files would lead to the "
+"source failing to build without assistance from the Debian diff, it might be "
+"appropriate to instead edit the files, omitting only the non-free parts of "
+"them, and/or explain the situation in a README.Debian-source file in the "
+"root of the source tree. But in that case please also urge the upstream "
+"author to make the non-free components easier seperable from the rest of the "
+"source."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
+#: best-pkging-practices.dbk:1642
+msgid ""
+"<emphasis role=\"strong\">should</emphasis>, except where impossible for "
+"legal reasons, preserve the entire building and portablility infrastructure "
+"provided by the upstream author. For example, it is not a sufficient reason "
+"for omitting a file that it is used only when building on MS-DOS. "
+"Similarly, a Makefile provided by upstream should not be omitted even if the "
+"first thing your <filename>debian/rules</filename> does is to overwrite it "
+"by running a configure script."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
+#: best-pkging-practices.dbk:1651
+msgid ""
+"(<emphasis>Rationale:</emphasis> It is common for Debian users who need to "
+"build software for non-Debian platforms to fetch the source from a Debian "
+"mirror rather than trying to locate a canonical upstream distribution point)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
+#: best-pkging-practices.dbk:1658
+msgid ""
+"<emphasis role=\"strong\">should</emphasis> use <literal><packagename>-"
+"<upstream-version>.orig</literal> as the name of the top-level "
+"directory in its tarball. This makes it possible to distinguish pristine "
+"tarballs from repackaged ones."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
+#: best-pkging-practices.dbk:1666
+msgid ""
+"<emphasis role=\"strong\">should</emphasis> be gzipped with maximal "
+"compression."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1671
+msgid ""
+"The canonical way to meet the latter two points is to let <literal>dpkg-"
+"source -b</literal> construct the repackaged tarball from an unpacked "
+"directory."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:1677
+msgid "Changing binary files in <literal>diff.gz</literal>"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para><footnote>
+#: best-pkging-practices.dbk:1679
+msgid ""
+"Sometimes it is necessary to change binary files contained in the original "
+"tarball, or to add binary files that are not in it. If this is done by "
+"simply copying the files into the debianized source tree, <command>dpkg-"
+"source</command> will not be able to handle this. On the other hand, "
+"according to the guidelines given above, you cannot include such a changed "
+"binary file in a repackaged <filename>orig.tar.gz</filename>. Instead, "
+"include the file in the <filename>debian</filename> directory in "
+"<command>uuencode</command>d (or similar) form <footnote>"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para><footnote><para>
+#: best-pkging-practices.dbk:1686
+msgid ""
+"The file should have a name that makes it clear which binary file it "
+"encodes. Usually, some postfix indicating the encoding should be appended "
+"to the original filename. Note that you don't need to depend on <systemitem "
+"role=\"package\">sharutils</systemitem> to get the <command>uudecode</"
+"command> program if you use <command>perl</command>'s <literal>pack</"
+"literal> function. The code could look like"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1694
+msgid ""
+"&example-uu; </footnote>. The file would then be decoded and copied to its "
+"place during the build process. Thus the change will be visible quite easy."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1700
+msgid ""
+"Some packages use <command>dbs</command> to manage patches to their upstream "
+"source, and always create a new <literal>orig.tar.gz</literal> file that "
+"contains the real <literal>orig.tar.gz</literal> in its toplevel directory. "
+"This is questionable with respect to the preference for pristine source. On "
+"the other hand, it is easy to modify or add binary files in this case: Just "
+"put them into the newly created <literal>orig.tar.gz</literal> file, besides "
+"the real one, and copy them to the right place during the build process."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:1713
+msgid "Best practices for debug packages"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1715
+msgid ""
+"A debug package is a package with a name ending in -dbg, that contains "
+"additional information that gdb can use. Since Debian binaries are stripped "
+"by default, debugging information, including function names and line "
+"numbers, is otherwise not available when running gdb on Debian binaries. "
+"Debug packages allow users who need this additional debugging information to "
+"install it, without bloating a regular system with the information."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1723
+msgid ""
+"It is up to a package's maintainer whether to create a debug package or "
+"not. Maintainers are encouraged to create debug packages for library "
+"packages, since this can aid in debugging many programs linked to a "
+"library. In general, debug packages do not need to be added for all "
+"programs; doing so would bloat the archive. But if a maintainer finds that "
+"users often need a debugging version of a program, it can be worthwhile to "
+"make a debug package for it. Programs that are core infrastructure, such as "
+"apache and the X server are also good candidates for debug packages."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1733
+msgid ""
+"Some debug packages may contain an entire special debugging build of a "
+"library or other binary, but most of them can save space and build time by "
+"instead containing separated debugging symbols that gdb can find and load on "
+"the fly when debugging a program or library. The convention in Debian is to "
+"keep these symbols in <filename>/usr/lib/debug/path</filename>, where "
+"<emphasis>path</emphasis> is the path to the executable or library. For "
+"example, debugging symbols for <filename>/usr/bin/foo</filename> go in "
+"<filename>/usr/lib/debug/usr/bin/foo</filename>, and debugging symbols for "
+"<filename>/usr/lib/libfoo.so.1</filename> go in <filename>/usr/lib/debug/usr/"
+"lib/libfoo.so.1</filename>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1745
+msgid ""
+"The debugging symbols can be extracted from an object file using objcopy --"
+"only-keep-debug. Then the object file can be stripped, and objcopy --add-"
+"gnu-debuglink used to specify the path to the debugging symbol file. "
+"<citerefentry> <refentrytitle>objcopy</refentrytitle> <manvolnum>1</"
+"manvolnum> </citerefentry> explains in detail how this works."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1752
+msgid ""
+"The dh_strip command in debhelper supports creating debug packages, and can "
+"take care of using objcopy to separate out the debugging symbols for you. "
+"If your package uses debhelper, all you need to do is call dh_strip --dbg-"
+"package=libfoo-dbg, and add an entry to debian/control for the debug package."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1759
+msgid ""
+"Note that the Debian package should depend on the package that it provides "
+"debugging symbols for, and this dependency should be versioned. For example:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: best-pkging-practices.dbk:1763
+#, no-wrap
+msgid "Depends: libfoo-dbg (= ${binary:Version})"
+msgstr ""
--- /dev/null
+# SOME DESCRIPTIVE TITLE
+# Copyright (C) YEAR Free Software Foundation, Inc.
+# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
+#
+#, fuzzy
+msgid ""
+msgstr ""
+"Project-Id-Version: PACKAGE VERSION\n"
+"POT-Creation-Date: 2007-07-01 21:18+0000\n"
+"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
+"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
+"Language-Team: LANGUAGE <LL@li.org>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: ENCODING\n"
+
+# type: Content of: <chapter><title>
+#: beyond-pkging.dbk:7
+msgid "Beyond Packaging"
+msgstr ""
+
+# type: Content of: <chapter><para>
+#: beyond-pkging.dbk:9
+msgid ""
+"Debian is about a lot more than just packaging software and maintaining "
+"those packages. This chapter contains information about ways, often really "
+"critical ways, to contribute to Debian beyond simply creating and "
+"maintaining packages."
+msgstr ""
+
+# type: Content of: <chapter><para>
+#: beyond-pkging.dbk:14
+msgid ""
+"As a volunteer organization, Debian relies on the discretion of its members "
+"in choosing what they want to work on and in choosing the most critical "
+"thing to spend their time on."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: beyond-pkging.dbk:19
+msgid "Bug reporting"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:21
+msgid ""
+"We encourage you to file bugs as you find them in Debian packages. In fact, "
+"Debian developers are often the first line testers. Finding and reporting "
+"bugs in other developers' packages improves the quality of Debian."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:26
+msgid ""
+"Read the <ulink url=\"&url-bts-report;\">instructions for reporting bugs</"
+"ulink> in the Debian <ulink url=\"&url-bts;\">bug tracking system</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:31
+msgid ""
+"Try to submit the bug from a normal user account at which you are likely to "
+"receive mail, so that people can reach you if they need further information "
+"about the bug. Do not submit bugs as root."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:36
+msgid ""
+"You can use a tool like <citerefentry> <refentrytitle>reportbug</"
+"refentrytitle> <manvolnum>1</manvolnum> </citerefentry> to submit bugs. It "
+"can automate and generally ease the process."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:41
+msgid ""
+"Make sure the bug is not already filed against a package. Each package has "
+"a bug list easily reachable at <literal>http://&bugs-host;/"
+"<replaceable>packagename</replaceable></literal> Utilities like "
+"<citerefentry> <refentrytitle>querybts</refentrytitle> <manvolnum>1</"
+"manvolnum> </citerefentry> can also provide you with this information (and "
+"<command>reportbug</command> will usually invoke <command>querybts</command> "
+"before sending, too)."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:50
+msgid ""
+"Try to direct your bugs to the proper location. When for example your bug "
+"is about a package which overwrites files from another package, check the "
+"bug lists for <emphasis>both</emphasis> of those packages in order to avoid "
+"filing duplicate bug reports."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:56
+msgid ""
+"For extra credit, you can go through other packages, merging bugs which are "
+"reported more than once, or tagging bugs `fixed' when they have already been "
+"fixed. Note that when you are neither the bug submitter nor the package "
+"maintainer, you should not actually close the bug (unless you secure "
+"permission from the maintainer)."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:63
+msgid ""
+"From time to time you may want to check what has been going on with the bug "
+"reports that you submitted. Take this opportunity to close those that you "
+"can't reproduce anymore. To find out all the bugs you submitted, you just "
+"have to visit <literal>http://&bugs-host;/from:<replaceable><your-email-"
+"addr></replaceable></literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: beyond-pkging.dbk:70
+msgid "Reporting lots of bugs at once (mass bug filing)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:72
+msgid ""
+"Reporting a great number of bugs for the same problem on a great number of "
+"different packages — i.e., more than 10 — is a deprecated practice. Take "
+"all possible steps to avoid submitting bulk bugs at all. For instance, if "
+"checking for the problem can be automated, add a new check to <systemitem "
+"role=\"package\">lintian</systemitem> so that an error or warning is emitted."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:79
+msgid ""
+"If you report more than 10 bugs on the same topic at once, it is recommended "
+"that you send a message to &email-debian-devel; describing your intention "
+"before submitting the report, and mentioning the fact in the subject of your "
+"mail. This will allow other developers to verify that the bug is a real "
+"problem. In addition, it will help prevent a situation in which several "
+"maintainers start filing the same bug report simultaneously."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:87
+msgid ""
+"Please use the programms <command>dd-list</command> and if appropriate "
+"<command>whodepends</command> (from the package devscripts) to generate a "
+"list of all affected packages, and include the output in your mail to &email-"
+"debian-devel;."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:93
+msgid ""
+"Note that when sending lots of bugs on the same subject, you should send the "
+"bug report to <email>maintonly@&bugs-host;</email> so that the bug report is "
+"not forwarded to the bug distribution mailing list."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: beyond-pkging.dbk:102
+msgid "Quality Assurance effort"
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: beyond-pkging.dbk:104
+msgid "Daily work"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:106
+msgid ""
+"Even though there is a dedicated group of people for Quality Assurance, QA "
+"duties are not reserved solely for them. You can participate in this effort "
+"by keeping your packages as bug-free as possible, and as lintian-clean (see "
+"<xref linkend=\"lintian\"/> ) as possible. If you do not find that "
+"possible, then you should consider orphaning some of your packages (see "
+"<xref linkend=\"orphaning\"/> ). Alternatively, you may ask the help of "
+"other people in order to catch up with the backlog of bugs that you have "
+"(you can ask for help on &email-debian-qa; or &email-debian-devel;). At the "
+"same time, you can look for co-maintainers (see <xref linkend="
+"\"collaborative-maint\"/> )."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: beyond-pkging.dbk:120
+msgid "Bug squashing parties"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:122
+msgid ""
+"From time to time the QA group organizes bug squashing parties to get rid of "
+"as many problems as possible. They are announced on &email-debian-devel-"
+"announce; and the announcement explains which area will be the focus of the "
+"party: usually they focus on release critical bugs but it may happen that "
+"they decide to help finish a major upgrade (like a new perl version which "
+"requires recompilation of all the binary modules)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:131
+msgid ""
+"The rules for non-maintainer uploads differ during the parties because the "
+"announcement of the party is considered prior notice for NMU. If you have "
+"packages that may be affected by the party (because they have release "
+"critical bugs for example), you should send an update to each of the "
+"corresponding bug to explain their current status and what you expect from "
+"the party. If you don't want an NMU, or if you're only interested in a "
+"patch, or if you will deal yourself with the bug, please explain that in the "
+"BTS."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:140
+msgid ""
+"People participating in the party have special rules for NMU, they can NMU "
+"without prior notice if they upload their NMU to DELAYED/3-day at least. "
+"All other NMU rules apply as usually; they should send the patch of the NMU "
+"to the BTS (to one of the open bugs fixed by the NMU, or to a new bug, "
+"tagged fixed). They should also respect any particular wishes of the "
+"maintainer."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:147
+msgid ""
+"If you don't feel confident about doing an NMU, just send a patch to the "
+"BTS. It's far better than a broken NMU."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: beyond-pkging.dbk:155
+msgid "Contacting other maintainers"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:157
+msgid ""
+"During your lifetime within Debian, you will have to contact other "
+"maintainers for various reasons. You may want to discuss a new way of "
+"cooperating between a set of related packages, or you may simply remind "
+"someone that a new upstream version is available and that you need it."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:163
+msgid ""
+"Looking up the email address of the maintainer for the package can be "
+"distracting. Fortunately, there is a simple email alias, <literal><"
+"package>@&packages-host;</literal>, which provides a way to email the "
+"maintainer, whatever their individual email address (or addresses) may be. "
+"Replace <literal><package></literal> with the name of a source or a "
+"binary package."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:171
+msgid ""
+"You may also be interested in contacting the persons who are subscribed to a "
+"given source package via <xref linkend=\"pkg-tracking-system\"/> . You can "
+"do so by using the <literal><package>@&pts-host;</literal> email "
+"address."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: beyond-pkging.dbk:180
+msgid "Dealing with inactive and/or unreachable maintainers"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:182
+msgid ""
+"If you notice that a package is lacking maintenance, you should make sure "
+"that the maintainer is active and will continue to work on their packages. "
+"It is possible that they are not active any more, but haven't registered out "
+"of the system, so to speak. On the other hand, it is also possible that "
+"they just need a reminder."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:189
+msgid ""
+"There is a simple system (the MIA database) in which information about "
+"maintainers who are deemed Missing In Action is recorded. When a member of "
+"the QA group contacts an inactive maintainer or finds more information about "
+"one, this is recorded in the MIA database. This system is available in /org/"
+"qa.debian.org/mia on the host qa.debian.org, and can be queried with a tool "
+"known as <command>mia-query</command>. Use <command>mia-query --help</"
+"command> to see how to query the database. If you find that no information "
+"has been recorded about an inactive maintainer yet, or that you can add more "
+"information, you should generally proceed as follows."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:200
+msgid ""
+"The first step is to politely contact the maintainer, and wait a reasonable "
+"time for a response. It is quite hard to define reasonable time, but it is "
+"important to take into account that real life is sometimes very hectic. One "
+"way to handle this would be to send a reminder after two weeks."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:206
+msgid ""
+"If the maintainer doesn't reply within four weeks (a month), one can assume "
+"that a response will probably not happen. If that happens, you should "
+"investigate further, and try to gather as much useful information about the "
+"maintainer in question as possible. This includes:"
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: beyond-pkging.dbk:214
+msgid ""
+"The echelon information available through the <ulink url=\"&url-debian-db;"
+"\">developers' LDAP database</ulink>, which indicates when the developer "
+"last posted to a Debian mailing list. (This includes uploads via debian-*-"
+"changes lists.) Also, remember to check whether the maintainer is marked as "
+"on vacation in the database."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: beyond-pkging.dbk:223
+msgid ""
+"The number of packages this maintainer is responsible for, and the condition "
+"of those packages. In particular, are there any RC bugs that have been open "
+"for ages? Furthermore, how many bugs are there in general? Another important "
+"piece of information is whether the packages have been NMUed, and if so, by "
+"whom."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: beyond-pkging.dbk:232
+msgid ""
+"Is there any activity of the maintainer outside of Debian? For example, they "
+"might have posted something recently to non-Debian mailing lists or news "
+"groups."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:239
+msgid ""
+"A bit of a problem are packages which were sponsored — the maintainer is not "
+"an official Debian developer. The echelon information is not available for "
+"sponsored people, for example, so you need to find and contact the Debian "
+"developer who has actually uploaded the package. Given that they signed the "
+"package, they're responsible for the upload anyhow, and are likely to know "
+"what happened to the person they sponsored."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:247
+msgid ""
+"It is also allowed to post a query to &email-debian-devel;, asking if anyone "
+"is aware of the whereabouts of the missing maintainer. Please Cc: the "
+"person in question."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:252
+msgid ""
+"Once you have gathered all of this, you can contact &email-mia;. People on "
+"this alias will use the information you provide in order to decide how to "
+"proceed. For example, they might orphan one or all of the packages of the "
+"maintainer. If a package has been NMUed, they might prefer to contact the "
+"NMUer before orphaning the package — perhaps the person who has done the NMU "
+"is interested in the package."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:260
+msgid ""
+"One last word: please remember to be polite. We are all volunteers and "
+"cannot dedicate all of our time to Debian. Also, you are not aware of the "
+"circumstances of the person who is involved. Perhaps they might be "
+"seriously ill or might even have died — you do not know who may be on the "
+"receiving side. Imagine how a relative will feel if they read the e-mail of "
+"the deceased and find a very impolite, angry and accusing message!"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:268
+msgid ""
+"On the other hand, although we are volunteers, we do have a responsibility. "
+"So you can stress the importance of the greater good — if a maintainer does "
+"not have the time or interest anymore, they should let go and give the "
+"package to someone with more time."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:274
+msgid ""
+"If you are interested in working in the MIA team, please have a look at the "
+"README file in /org/qa.debian.org/mia on qa.debian.org where the technical "
+"details and the MIA procedures are documented and contact &email-mia;."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: beyond-pkging.dbk:282
+msgid "Interacting with prospective Debian developers"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:284
+msgid ""
+"Debian's success depends on its ability to attract and retain new and "
+"talented volunteers. If you are an experienced developer, we recommend that "
+"you get involved with the process of bringing in new developers. This "
+"section describes how to help new prospective developers."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: beyond-pkging.dbk:290
+msgid "Sponsoring packages"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:292
+msgid ""
+"Sponsoring a package means uploading a package for a maintainer who is not "
+"able to do it on their own, a new maintainer applicant. Sponsoring a "
+"package also means accepting responsibility for it."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:303
+msgid ""
+"New maintainers usually have certain difficulties creating Debian packages — "
+"this is quite understandable. That is why the sponsor is there, to check "
+"the package and verify that it is good enough for inclusion in Debian. "
+"(Note that if the sponsored package is new, the ftpmasters will also have to "
+"inspect it before letting it in.)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:310
+msgid ""
+"Sponsoring merely by signing the upload or just recompiling is <emphasis "
+"role=\"strong\">definitely not recommended</emphasis>. You need to build "
+"the source package just like you would build a package of your own. "
+"Remember that it doesn't matter that you left the prospective developer's "
+"name both in the changelog and the control file, the upload can still be "
+"traced to you."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:317
+msgid ""
+"If you are an application manager for a prospective developer, you can also "
+"be their sponsor. That way you can also verify how the applicant is "
+"handling the 'Tasks and Skills' part of their application."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: beyond-pkging.dbk:324
+msgid "Managing sponsored packages"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:326
+msgid ""
+"By uploading a sponsored package to Debian, you are certifying that the "
+"package meets minimum Debian standards. That implies that you must build "
+"and test the package on your own system before uploading."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:331
+msgid ""
+"You cannot simply upload a binary <filename>.deb</filename> from the "
+"sponsoree. In theory, you should only ask for the diff file and the "
+"location of the original source tarball, and then you should download the "
+"source and apply the diff yourself. In practice, you may want to use the "
+"source package built by your sponsoree. In that case, you have to check "
+"that they haven't altered the upstream files in the <filename>.orig.tar.gz</"
+"filename> file that they're providing."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:340
+msgid ""
+"Do not be afraid to write the sponsoree back and point out changes that need "
+"to be made. It often takes several rounds of back-and-forth email before "
+"the package is in acceptable shape. Being a sponsor means being a mentor."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:345
+msgid "Once the package meets Debian standards, build and sign it with"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: beyond-pkging.dbk:348
+#, no-wrap
+msgid "dpkg-buildpackage -k<replaceable>KEY-ID</replaceable>"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:351
+msgid ""
+"before uploading it to the incoming directory. Of course, you can also use "
+"any part of your <replaceable>KEY-ID</replaceable>, as long as it's unique "
+"in your secret keyring."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:356
+msgid ""
+"The Maintainer field of the <filename>control</filename> file and the "
+"<filename>changelog</filename> should list the person who did the packaging, "
+"i.e., the sponsoree. The sponsoree will therefore get all the BTS mail "
+"about the package."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:362
+msgid ""
+"If you prefer to leave a more evident trace of your sponsorship job, you can "
+"add a line stating it in the most recent changelog entry."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:366
+msgid ""
+"You are encouraged to keep tabs on the package you sponsor using <xref "
+"linkend=\"pkg-tracking-system\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: beyond-pkging.dbk:372
+msgid "Advocating new developers"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:374
+msgid ""
+"See the page about <ulink url=\"&url-newmaint-advocate;\">advocating a "
+"prospective developer</ulink> at the Debian web site."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: beyond-pkging.dbk:381
+msgid "Handling new maintainer applications"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:383
+msgid ""
+"Please see <ulink url=\"&url-newmaint-amchecklist;\">Checklist for "
+"Application Managers</ulink> at the Debian web site."
+msgstr ""
--- /dev/null
+# Debian Developer's Reference (Japanese)
+# Hideki Yamane (Debian-JP) <henrich@debian.or.jp>, 2007.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: developers-reference _VERSION_\n"
+"POT-Creation-Date: 2007-07-01 21:18+0000\n"
+"PO-Revision-Date: 2007-08-02 20:04+0900\n"
+"Last-Translator: Hideki Yamane (Debian-JP) <henrich@debian.or.jp>\n"
+"Language-Team: Debian JP Project <debian-doc@debian.or.jp>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+# type: Content of: <chapter><title>
+#: developer-duties.dbk:7
+msgid "Debian Developer's Duties"
+msgstr "Debian 開発者の責務"
+
+# type: Content of: <chapter><section><title>
+#: developer-duties.dbk:9
+msgid "Maintaining your Debian information"
+msgstr "あなたの Debian に関する情報をメンテナンスする"
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:11
+msgid ""
+"There's a LDAP database containing information about Debian developers at "
+"<ulink url=\"&url-debian-db;\"></ulink>. You should enter your information "
+"there and update it as it changes. Most notably, make sure that the address "
+"where your debian.org email gets forwarded to is always up to date, as well "
+"as the address where you get your debian-private subscription if you choose "
+"to subscribe there."
+msgstr ""
+"Debian 開発者に関する情報が含まれた LDAP データベースが "
+"<ulink url=\"&url-debian-db;\"></ulink> にあります。"
+"ここに情報を入力して、情報に変更があった際に更新する必要があります。"
+"特に、あなたの debian.org アドレス宛メールの転送先アドレスが常に最新になっている"
+"のを必ず確認してください。debian-private の購読をここで設定した場合、そのメールを"
+"受け取るアドレスについても同様です。"
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:19
+msgid ""
+"For more information about the database, please see <xref linkend=\"devel-db"
+"\"/> ."
+msgstr ""
+"データベースについての詳細は <xref linkend=\"devel-db\"/> を参照してください。"
+
+# type: Content of: <chapter><section><title>
+#: developer-duties.dbk:25
+msgid "Maintaining your public key"
+msgstr "公開鍵をメンテナンスする"
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:27
+msgid ""
+"Be very careful with your private keys. Do not place them on any public "
+"servers or multiuser machines, such as the Debian servers (see <xref linkend="
+"\"server-machines\"/> ). Back your keys up; keep a copy offline. Read the "
+"documentation that comes with your software; read the <ulink url=\"&url-pgp-"
+"faq;\">PGP FAQ</ulink>."
+msgstr ""
+"秘密鍵の取扱いには十二分に注意してください。Debian サーバ "
+"(<xref linkend=\"server-machines\"/> 参照) のような公開サーバや複数のユーザが"
+"いるマシンには、どれにも置かないようにしてください。"
+"鍵をバックアップして、コピーはオフラインな場所に置きましょう。"
+"ソフトの使い方についてはドキュメントを参照してください。<ulink "
+"url=\"&url-pgp-faq;\">PGP FAQ</ulink> を読みましょう。"
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:34
+msgid ""
+"You need to ensure not only that your key is secure against being stolen, "
+"but also that it is secure against being lost. Generate and make a copy "
+"(best also in paper form) of your revocation certificate; this is needed if "
+"your key is lost."
+msgstr ""
+"鍵が盗難に対してだけではなく、紛失についても安全であることを保証する必要があります。"
+"失効証明書 (revocation certificate) を生成してコピーを作って下さい (紙にも出力して"
+"おくのがベストです)。これは鍵を紛失した場合に必要になります。"
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:40
+msgid ""
+"If you add signatures to your public key, or add user identities, you can "
+"update the Debian key ring by sending your key to the key server at "
+"<literal>&keyserver-host;</literal>."
+msgstr ""
+"公開鍵に対して、署名したり身元情報を追加したりなどしたら、鍵を "
+"<literal>&keyserver-host;</literal> の鍵サーバに送付することで "
+"Debian key ring を更新できます。"
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:45
+msgid ""
+"If you need to add a completely new key or remove an old key, you need to "
+"get the new key signed by another developer. If the old key is compromised "
+"or invalid, you also have to add the revocation certificate. If there is no "
+"real reason for a new key, the Keyring Maintainers might reject the new "
+"key. Details can be found at <ulink url=\"http://&keyserver-host;/"
+"replacing_keys.html\"></ulink>."
+msgstr ""
+"まったく新しい鍵を追加したりあるいは古い鍵を削除したりする必要がある時は、"
+"別の開発者に署名された新しい鍵が必要になります。"
+"以前の鍵が侵害されたり利用不可能になった場合には、失効証明書 (revocation certificate) "
+"も追加する必要があります。"
+"新しい鍵が本当に必要な理由が見当たらない場合は、Keyring メンテナは新しい鍵を拒否する"
+"ことがあります。詳細は <ulink url=\"http://&keyserver-host;/replacing_keys.html\">"
+"</ulink> で確認できます。"
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:53
+msgid ""
+"The same key extraction routines discussed in <xref linkend=\"registering\"/"
+"> apply."
+msgstr ""
+"同様に鍵の取り出し方について <xref linkend=\"registering\"/> で説明されています。"
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:57
+msgid ""
+"You can find a more in-depth discussion of Debian key maintenance in the "
+"documentation of the <systemitem role=\"package\">debian-keyring</"
+"systemitem> package."
+msgstr ""
+"Debian での鍵のメンテナンスについて、より突っ込んだ議論が <systemitem "
+"role=\"package\">debian-keyring</systemitem> パッケージ中のドキュメントで"
+"知ることができます。"
+
+# type: Content of: <chapter><section><title>
+#: developer-duties.dbk:64
+msgid "Voting"
+msgstr "投票をする"
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:66
+msgid ""
+"Even though Debian isn't really a democracy, we use a democratic process to "
+"elect our leaders and to approve general resolutions. These procedures are "
+"defined by the <ulink url=\"&url-constitution;\">Debian Constitution</ulink>."
+msgstr ""
+"Debian は本来の意味での民主主義ではありませんが、我々はリーダの選出や一般投票の承認"
+"において民主主義的なプロセスを利用しています。"
+"これらの手続きについては、<ulink url=\"&url-constitution;\">Debian 憲章</ulink>"
+"で規程されています。"
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:72
+msgid ""
+"Other than the yearly leader election, votes are not routinely held, and "
+"they are not undertaken lightly. Each proposal is first discussed on the "
+"&email-debian-vote; mailing list and it requires several endorsements before "
+"the project secretary starts the voting procedure."
+msgstr ""
+"毎年のリーダー選挙以外には、投票は定期的には実施されず、軽々しく提案されるものでは"
+"ありません。"
+"提案はそれぞれ &email-debian-vote; メーリングリストでまず議論され、プロジェクトの"
+"書記担当者が投票手順を開始する前に複数のエンドースメントを必要とします。"
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:78
+msgid ""
+"You don't have to track the pre-vote discussions, as the secretary will "
+"issue several calls for votes on &email-debian-devel-announce; (and all "
+"developers are expected to be subscribed to that list). Democracy doesn't "
+"work well if people don't take part in the vote, which is why we encourage "
+"all developers to vote. Voting is conducted via GPG-signed/encrypted email "
+"messages."
+msgstr ""
+"書記担当者が &email-debian-devel-announce; 上で複数回投票の呼びかけを行うので、"
+"投票前の議論を追いかける必要はありません (全開発者がこのメーリングリストを購読する"
+"ことが求められています)。"
+"民主主義は、人々が投票に参加しないと正常に機能しません。"
+"これが我々が全ての開発者に投票を勧める理由です。"
+"投票は GPG によって署名／暗号化されたメールによって行われます。"
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:86
+msgid ""
+"The list of all proposals (past and current) is available on the <ulink url="
+"\"&url-vote;\">Debian Voting Information</ulink> page, along with "
+"information on how to make, second and vote on proposals."
+msgstr ""
+"(過去と現在の) 全ての提案リストが <ulink url=\"&url-vote;\">Debian 投票情報"
+"</ulink>ページで閲覧できます。提案について、どの様に起案され、支持され、投票が"
+"行われたのかという関連情報の確認が可能になっています。"
+
+# type: Content of: <chapter><section><title>
+#: developer-duties.dbk:93
+msgid "Going on vacation gracefully"
+msgstr "優雅に休暇を取る"
+
+# type: Content of: <chapter><section><para>
+#, fuzzy
+#: developer-duties.dbk:95
+msgid ""
+"It is common for developers to have periods of absence, whether those are "
+"planned vacations or simply being buried in other work. The important thing "
+"to notice is that other developers need to know that you're on vacation so "
+"that they can do whatever is needed if a problem occurs with your packages "
+"or other duties in the project."
+msgstr ""
+"予定していた休暇なのかそれとも単に他の作業で忙しいのか、どちらにせよ開発者が不在に"
+"なることはごく普通のことです。"
+"注意すべき重要な点は、あなたが休暇中であるので、あなたのパッケージについて問題が"
+"起こった場合やプロジェクト内での責務を果たすのに問題が生じたという様な場合は必要で"
+"あることなら何でもして構わないと他の開発者達に知らせる必要があることです。"
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:102
+msgid ""
+"Usually this means that other developers are allowed to NMU (see <xref "
+"linkend=\"nmu\"/> ) your package if a big problem (release critical bug, "
+"security update, etc.) occurs while you're on vacation. Sometimes it's "
+"nothing as critical as that, but it's still appropriate to let others know "
+"that you're unavailable."
+msgstr ""
+"通常、これはあなたが休暇中にあなたのパッケージが大きな問題 (リリースクリティカルバグ"
+"やセキュリティ更新など) となっている場合に、他の開発者に対して NMU (<xref "
+"linkend=\"nmu\"/> 参照) を許可することを意味しています。"
+"大抵の場合はそれほど致命的なことはおきませんが、他の開発者に対してあなたが"
+"作業できない状態であることを知らせるのは重要です。"
+
+# type: Content of: <chapter><section><para><footnote>
+#: developer-duties.dbk:109
+msgid ""
+"In order to inform the other developers, there are two things that you "
+"should do. First send a mail to <email>debian-private@&lists-host;</email> "
+"with [VAC] prepended to the subject of your message<footnote>"
+msgstr ""
+"他の開発者に通知するために行わなければならないことが 2 つあります。"
+"まず、<email>debian-private@&lists-host;</email> にサブジェクトの先頭に [VAC] "
+"と付けたメール<footnote>"
+
+# type: Content of: <chapter><section><para><footnote><para>
+#: developer-duties.dbk:111
+msgid ""
+"This is so that the message can be easily filtered by people who don't want "
+"to read vacation notices."
+msgstr ""
+"これは、休暇のメッセージを読みたくない人がメッセージを簡単に振り分け可能にするためです。"
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:113
+msgid ""
+"</footnote> and state the period of time when you will be on vacation. You "
+"can also give some special instructions on what to do if a problem occurs."
+msgstr ""
+"</footnote>の本文に、いつまで休暇予定なのかを記述して休暇に行く際に送ってください。"
+"問題が起こった際にどうすれば良いのか、特別な指示を書いておくこともできます。"
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:118
+msgid ""
+"The other thing to do is to mark yourself as on vacation in the <link "
+"linkend=\"devel-db\">Debian developers' LDAP database</link> (this "
+"information is only accessible to Debian developers). Don't forget to "
+"remove the on vacation flag when you come back!"
+msgstr ""
+"他に行うべき事は <link linkend=\"devel-db\">Debian developers' LDAP "
+"database</link> 上 であなたを vacation とマークする事です "
+"(この情報は Debian 開発者のみがアクセスできます)。"
+"休暇から戻った時には vacation フラグを削除するのを忘れないように!"
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:124
+msgid ""
+"Ideally, you should sign up at the <ulink url=\"&url-newmaint-db;gpg.php"
+"\">GPG coordination site</ulink> when booking a holiday and check if anyone "
+"there is looking for signing. This is especially important when people go "
+"to exotic places where we don't have any developers yet but where there are "
+"people who are interested in applying."
+msgstr ""
+"理想的には、休暇にあわせて <ulink url=\"&url-newmaint-db;gpg.php\">GPG "
+"coordination site</ulink> に登録して、誰かサインを希望している人がいるかどうかを"
+"チェックします。開発者がまだ誰もいないけれども応募に興味を持っている人がいるような"
+"エキゾチックな場所に行く場合、これは特に重要です。"
+
+# type: Content of: <chapter><section><title>
+#: developer-duties.dbk:133
+msgid "Coordination with upstream developers"
+msgstr "上流 (upstream) の開発者との調整について"
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:135
+msgid ""
+"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 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."
+msgstr ""
+"Debian メンテナとしての仕事のうち重要な位置を占めるのは、上流 (upstream) の開発者"
+"との窓口であることです。Debian ユーザは、時折バグ報告システムに Debian 特有ではない"
+"バグを報告する事があります。"
+"Debian メンテナは、いつか上流のリリースで修正できるようにする為、このようなバグ報告"
+"を上流の開発者に転送しなくてはなりません。"
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:142
+msgid ""
+"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."
+msgstr ""
+"Debian 固有ではないバグの修正はあなたの義務ではないとはいえ、できるなら遠慮なく"
+"修正してください。"
+"そのような修正を行った際は、上流の開発者にも送ってください。"
+"時折 Debian ユーザ／開発者が上流のバグを修正するパッチを送ってくる事があります。"
+"その場合は、あなたはパッチを確認して上流へ転送する必要があります。"
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:149
+msgid ""
+"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 "
+"developers which can be included there, so that you won't have to modify the "
+"sources of the next upstream version. Whatever changes you need, always try "
+"not to fork from the upstream sources."
+msgstr ""
+"ポリシーに準拠したパッケージをビルドするために上流のソースに手を入れる必要がある場合、"
+"以降の上流でのリリースにおいて手を入れなくても済むために、ここで含まれる修正を"
+"上流の開発者にとって良い形で提案する必要があります。"
+"必要な変更が何であれ、上流のソースからフォークしないように常に試みてください。"
+
+# type: Content of: <chapter><section><title>
+#: developer-duties.dbk:158
+msgid "Managing release-critical bugs"
+msgstr "リリースクリティカルバグに対処する"
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:160
+msgid ""
+"Generally you should deal with bug reports on your packages as described in "
+"<xref linkend=\"bug-handling\"/> . However, there's a special category of "
+"bugs that you need to take care of — the so-called release-critical bugs (RC "
+"bugs). All bug reports that have severity <emphasis>critical</emphasis>, "
+"<emphasis>grave</emphasis> or <emphasis>serious</emphasis> are considered to "
+"have an impact on whether the package can be released in the next stable "
+"release of Debian. These bugs can delay the Debian release and/or can "
+"justify the removal of a package at freeze time. That's why these bugs need "
+"to be corrected as quickly as possible."
+msgstr ""
+"大抵の場合、パッケージに対するバグ報告については <xref linkend=\"bug-handling\"/>"
+"で記述されているように対応する必要があります。しかしながら、注意を必要とする特別な"
+"カテゴリのバグがあります - リリースクリティカルバグ (RC bug) と呼ばれるものです。"
+"<emphasis>critical</emphasis>、<emphasis>grave</emphasis>、<emphasis>serious"
+"</emphasis> の重要度が付けられている全てのバグ報告は、Debian の次期安定版リリース"
+"からパッケージに含めるかどうかについての影響を持つと見なされています。"
+"これらのバグは Debian のリリースを遅らせたり、フリーズ時にパッケージ削除の調整に"
+"使われるなどされることがあります。"
+"これが、これらのバグを可能な限り素早く修正する必要がある理由です。"
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:171
+msgid ""
+"Developers who are part of the <ulink url=\"&url-debian-qa;\">Quality "
+"Assurance</ulink> group are following all such bugs, and trying to help "
+"whenever possible. If, for any reason, you aren't able fix an RC bug in a "
+"package of yours within 2 weeks, you should either ask for help by sending a "
+"mail to the Quality Assurance (QA) group <email>debian-qa@&lists-host;</"
+"email>, or explain your difficulties and present a plan to fix them by "
+"sending a mail to the bug report. Otherwise, people from the QA group may "
+"want to do a Non-Maintainer Upload (see <xref linkend=\"nmu\"/> ) after "
+"trying to contact you (they might not wait as long as usual before they do "
+"their NMU if they have seen no recent activity from you in the BTS)."
+msgstr ""
+"<ulink url=\"&url-debian-qa;\">品質保証</ulink> グループに所属している開発者は"
+"そのようなバグ全てを取扱い、何時でも可能な時に修正を試みます。"
+"どの様な理由であれ、2 週間の間でパッケージの RC バグを修正出来なかったりする場合は"
+"品質保証 (QA) グループ <email>debian-qa@&lists-host;</email> にメールを送って"
+"協力を求めるか、困難な点を説明してどうやってそれを修正するつもりなのか、バグ報告"
+"に対してメールを送ってください。"
+"そうしない場合は、QA グループのメンバーはあなたにコンタクトを試みた後で "
+"Non-Maintainer アップロード (<xref linkend=\"nmu\"/> 参照) を行おうとします "
+"(BTS 上で最近の活動が見られない場合は、彼らは NMU を行う前にいつもの様には待とうとは"
+"しないでしょう)。"
+
+# type: Content of: <chapter><section><title>
+#: developer-duties.dbk:186
+msgid "Retiring"
+msgstr "脱退について"
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:188
+msgid ""
+"If you choose to leave the Debian project, you should make sure you do the "
+"following steps:"
+msgstr ""
+"Debian プロジェクトから去るのを決めた場合は、以下の手順に従ってください:"
+
+# type: Content of: <chapter><section><orderedlist><listitem><para>
+#: developer-duties.dbk:194
+msgid ""
+"Orphan all your packages, as described in <xref linkend=\"orphaning\"/> ."
+msgstr ""
+"<xref linkend=\"orphaning\"/> の記述にしたがって、全てのパッケージをみなしご化 "
+"(orphan) してください。"
+
+# type: Content of: <chapter><section><orderedlist><listitem><para>
+#: developer-duties.dbk:199
+msgid ""
+"Send an gpg-signed email about why you are leaving the project to "
+"<email>debian-private@&lists-host;</email>."
+msgstr ""
+"何故プロジェクトを去るのかについて GPG でサインされたメールを "
+"<email>debian-private@&lists-host;</email> に投げてください。"
+
+# type: Content of: <chapter><section><orderedlist><listitem><para>
+#: developer-duties.dbk:205
+msgid ""
+"Notify the Debian key ring maintainers that you are leaving by opening a "
+"ticket in Debian RT by sending a mail to keyring@rt.debian.org with the "
+"words 'Debian RT' somewhere in the subject line (case doesn't matter)."
+msgstr ""
+"'Debian RT' という単語 (大文字小文字は関係なし) が入ったメールを "
+"keyring@rt.debian.org に投げて Debian RT でチケットをオープンすることで、"
+"あなたがプロジェクトを去るのを Debian key ring メンテナに知らせてください。"
+
--- /dev/null
+# Debian Developer's Reference (Japanese)
+# 遠藤 美純, 1999
+# Hideki Yamane (Debian-JP) <henrich@debian.or.jp>, 2007.
+#
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: developers-reference _VERSION_\n"
+"Report-Msgid-Bugs-To: \n"
+"POT-Creation-Date: 2007-07-01 22:36+0000\n"
+"PO-Revision-Date: 2007-07-16 20:04+0000\n"
+"Last-Translator: Hideki Yamane (Debian-JP) <henrich@debian.or.jp>\n"
+"Language-Team: Debian JP Project <debian-doc@debian.or.jp>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+# type: Attribute 'lang' of: <book>
+#: index.dbk:7
+msgid "en"
+msgstr "ja"
+
+# type: Content of: <book><title>
+#: index.dbk:9
+msgid "Debian Developer's Reference"
+msgstr "Debian 開発者リファレンス"
+
+# type: Content of: <book><bookinfo><releaseinfo>
+#: index.dbk:30
+msgid "ver. &version;"
+msgstr "ver.·&version;"
+
+# type: Content of: <book><bookinfo><pubdate>
+#: index.dbk:31
+msgid "&pubdate;"
+msgstr "&pubdate;"
+
+# type: Content of: <book><bookinfo><copyright><holder>
+#: index.dbk:37
+msgid "Andreas Barth"
+msgstr "Andreas Barth"
+
+# type: Content of: <book><bookinfo><copyright><holder>
+#: index.dbk:46
+msgid "Adam Di Carlo"
+msgstr "Adam Di Carlo"
+
+# type: Content of: <book><bookinfo><copyright><holder>
+#: index.dbk:51
+msgid "Raphaël Hertzog"
+msgstr "Raphaël Hertzog"
+
+# type: Content of: <book><bookinfo><copyright><holder>
+#: index.dbk:56
+msgid "Christian Schwarz"
+msgstr "Christian Schwarz"
+
+# type: Content of: <book><bookinfo><legalnotice><para>
+#: index.dbk:60
+msgid ""
+"This manual is free software; you may redistribute it and/or modify it under "
+"the terms of the GNU General Public License as published by the Free "
+"Software Foundation; either version 2, or (at your option) any later version."
+msgstr ""
+"このマニュアルはフリーソフトウェアです。あなたは、Free Software Foundation が"
+"発行した GNU 一般公衆利用許諾契約書の第二版あるいはそれ以降のいずれかの版の条件に"
+"基づき、本文書の再配付および変更をすることができます。"
+
+# type: Content of: <book><bookinfo><legalnotice><para>
+#: index.dbk:65
+msgid ""
+"This is distributed in the hope that it will be useful, but "
+"<emphasis>without any warranty</emphasis>; without even the implied warranty "
+"of merchantability or fitness for a particular purpose. See the GNU General "
+"Public License for more details."
+msgstr ""
+"本文書はその有用性が期待されて配付されるものですが、市場性や特定の目的への適"
+"合性に関する暗黙の保証も含め、<emphasis>いかなる保証も行ないません</"
+"emphasis>。詳細については GNU 一般公衆利用許諾契約書をお読みください。"
+
+# type: Content of: <book><bookinfo><legalnotice><para>
+#: index.dbk:71
+msgid ""
+"A copy of the GNU General Public License is available as &file-GPL; in the "
+"&debian-formal; distribution or on the World Wide Web at <ulink url=\"&url-"
+"gpl;\">the GNU web site</ulink>. You can also obtain it by writing to the "
+"&fsf-addr;."
+msgstr ""
+"GNU 一般公衆利用許諾契約書の写しは、Debian GNU/Linux ディストリビューション中の "
+"&file-GPL; 、あるいは World Wide Web 上の <ulink url=\"&url-gpl;\">GNU "
+"ウェブサイト</ulink>で入手できます。また &fsf-addr; へ手紙 (英語) で依頼し"
+"入手することもできます。"
+
+# type: Content of: <book><bookinfo><legalnotice><para>
+#. TODO: Maybe better: "This document has originally been written
+#. in English. Translations into different languages are available."
+#: index.dbk:78
+msgid ""
+"If you want to print this reference, you should use the <ulink url="
+"\"developers-reference.pdf\">pdf version</ulink>. This page is also "
+"available in <ulink url=\"index.fr.html\">French</ulink>."
+msgstr ""
+"このリファレンスを印刷したい場合は、<ulink url=\"developers-reference.pdf\">"
+"PDF 版</ulink>を利用すると良いでしょう。このページは <ulink "
+"url=\"index.fr.html\">フランス語</ulink> でも閲覧可能です。"
+
+# type: Content of: <book><bookinfo><releaseinfo>
+#~ msgid "ver. 3.3.9, 16 June, 2007"
+#~ msgstr "ver.·3.3.9,·16·June,·2007"
--- /dev/null
+# SOME DESCRIPTIVE TITLE
+# Copyright (C) YEAR Free Software Foundation, Inc.
+# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
+#
+#, fuzzy
+msgid ""
+msgstr ""
+"Project-Id-Version: PACKAGE VERSION\n"
+"POT-Creation-Date: 2007-07-01 21:18+0000\n"
+"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
+"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
+"Language-Team: LANGUAGE <LL@li.org>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: ENCODING\n"
+
+# type: Content of: <chapter><title>
+#: l10n.dbk:7
+msgid ""
+"Internationalizing, translating, being internationalized and being translated"
+msgstr ""
+
+# type: Content of: <chapter><para>
+#: l10n.dbk:9
+msgid ""
+"Debian supports an ever-increasing number of natural languages. Even if you "
+"are a native English speaker and do not speak any other language, it is part "
+"of your duty as a maintainer to be aware of issues of internationalization "
+"(abbreviated i18n because there are 18 letters between the 'i' and the 'n' "
+"in internationalization). Therefore, even if you are ok with English-only "
+"programs, you should read most of this chapter."
+msgstr ""
+
+# type: Content of: <chapter><para>
+#: l10n.dbk:17
+msgid ""
+"According to <ulink url=\"http://&www-debian-org;/doc/manuals/intro-i18n/"
+"\">Introduction to i18n</ulink> from Tomohiro KUBOTA, I18N "
+"(internationalization) means modification of a software or related "
+"technologies so that a software can potentially handle multiple languages, "
+"customs, and so on in the world. while L10N (localization) means "
+"implementation of a specific language for an already internationalized "
+"software."
+msgstr ""
+
+# type: Content of: <chapter><para>
+#: l10n.dbk:26
+msgid ""
+"l10n and i18n are interconnected, but the difficulties related to each of "
+"them are very different. It's not really difficult to allow a program to "
+"change the language in which texts are displayed based on user settings, but "
+"it is very time consuming to actually translate these messages. On the "
+"other hand, setting the character encoding is trivial, but adapting the code "
+"to use several character encodings is a really hard problem."
+msgstr ""
+
+# type: Content of: <chapter><para>
+#: l10n.dbk:34
+msgid ""
+"Setting aside the i18n problems, where no general guideline can be given, "
+"there is actually no central infrastructure for l10n within Debian which "
+"could be compared to the dbuild mechanism for porting. So most of the work "
+"has to be done manually."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: l10n.dbk:40
+msgid "How translations are handled within Debian"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: l10n.dbk:42
+msgid ""
+"Handling translation of the texts contained in a package is still a manual "
+"task, and the process depends on the kind of text you want to see translated."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: l10n.dbk:46
+msgid ""
+"For program messages, the gettext infrastructure is used most of the time. "
+"Most of the time, the translation is handled upstream within projects like "
+"the <ulink url=\"http://www.iro.umontreal.ca/contrib/po/HTML/\">Free "
+"Translation Project</ulink>, the <ulink url=\"http://developer.gnome.org/"
+"projects/gtp/\">Gnome translation Project</ulink> or the <ulink url=\"http://"
+"i18n.kde.org/\">KDE one</ulink>. The only centralized resource within "
+"Debian is the <ulink url=\"http://&www-debian-org;/intl/l10n/\">Central "
+"Debian translation statistics</ulink>, where you can find some statistics "
+"about the translation files found in the actual packages, but no real "
+"infrastructure to ease the translation process."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: l10n.dbk:59
+msgid ""
+"An effort to translate the package descriptions started long ago, even if "
+"very little support is offered by the tools to actually use them (i.e., only "
+"APT can use them, when configured correctly). Maintainers don't need to do "
+"anything special to support translated package descriptions; translators "
+"should use the <ulink url=\"http://ddtp.debian.org/\">DDTP</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: l10n.dbk:66
+msgid ""
+"For debconf templates, maintainers should use the po-debconf package to ease "
+"the work of translators, who could use the DDTP to do their work (but the "
+"French and Brazilian teams don't). Some statistics can be found both on the "
+"DDTP site (about what is actually translated), and on the <ulink url="
+"\"http://&www-debian-org;/intl/l10n/\">Central Debian translation "
+"statistics</ulink> site (about what is integrated in the packages)."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: l10n.dbk:74
+msgid ""
+"For web pages, each l10n team has access to the relevant CVS, and the "
+"statistics are available from the Central Debian translation statistics site."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: l10n.dbk:78
+msgid ""
+"For general documentation about Debian, the process is more or less the same "
+"as for the web pages (the translators have access to the CVS), but there are "
+"no statistics pages."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: l10n.dbk:83
+msgid ""
+"For package-specific documentation (man pages, info documents, other "
+"formats), almost everything remains to be done."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: l10n.dbk:87
+msgid ""
+"Most notably, the KDE project handles translation of its documentation in "
+"the same way as its program messages."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: l10n.dbk:91
+msgid ""
+"There is an effort to handle Debian-specific man pages within a <ulink url="
+"\"&url-cvsweb;manpages/?cvsroot=debian-doc\">specific CVS repository</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: l10n.dbk:98
+msgid "I18N & L10N FAQ for maintainers"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: l10n.dbk:100
+msgid ""
+"This is a list of problems that maintainers may face concerning i18n and "
+"l10n. While reading this, keep in mind that there is no real consensus on "
+"these points within Debian, and that this is only advice. If you have a "
+"better idea for a given problem, or if you disagree on some points, feel "
+"free to provide your feedback, so that this document can be enhanced."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: l10n.dbk:107
+msgid "How to get a given text translated"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: l10n.dbk:109
+msgid ""
+"To translate package descriptions or debconf templates, you have nothing to "
+"do; the DDTP infrastructure will dispatch the material to translate to "
+"volunteers with no need for interaction from your part."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: l10n.dbk:114
+msgid ""
+"For all other material (gettext files, man pages, or other documentation), "
+"the best solution is to put your text somewhere on the Internet, and ask on "
+"debian-i18n for a translation in different languages. Some translation team "
+"members are subscribed to this list, and they will take care of the "
+"translation and of the reviewing process. Once they are done, you will get "
+"your translated document from them in your mailbox."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: l10n.dbk:124
+msgid "How to get a given translation reviewed"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: l10n.dbk:126
+msgid ""
+"From time to time, individuals translate some texts in your package and will "
+"ask you for inclusion of the translation in the package. This can become "
+"problematic if you are not fluent in the given language. It is a good idea "
+"to send the document to the corresponding l10n mailing list, asking for a "
+"review. Once it has been done, you should feel more confident in the "
+"quality of the translation, and feel safe to include it in your package."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: l10n.dbk:136
+msgid "How to get a given translation updated"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: l10n.dbk:138
+msgid ""
+"If you have some translations of a given text lying around, each time you "
+"update the original, you should ask the previous translator to update the "
+"translation with your new changes. Keep in mind that this task takes time; "
+"at least one week to get the update reviewed and all."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: l10n.dbk:144
+msgid ""
+"If the translator is unresponsive, you may ask for help on the corresponding "
+"l10n mailing list. If everything fails, don't forget to put a warning in "
+"the translated document, stating that the translation is somehow outdated, "
+"and that the reader should refer to the original document if possible."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: l10n.dbk:150
+msgid ""
+"Avoid removing a translation completely because it is outdated. Old "
+"documentation is often better than no documentation at all for non-English "
+"speakers."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: l10n.dbk:157
+msgid "How to handle a bug report concerning a translation"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#. TODO: add the i18n tag to the bug?
+#: l10n.dbk:159
+msgid ""
+"The best solution may be to mark the bug as forwarded to upstream, and "
+"forward it to both the previous translator and his/her team (using the "
+"corresponding debian-l10n-XXX mailing list)."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: l10n.dbk:169
+msgid "I18N & L10N FAQ for translators"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: l10n.dbk:171
+msgid ""
+"While reading this, please keep in mind that there is no general procedure "
+"within Debian concerning these points, and that in any case, you should "
+"collaborate with your team and the package maintainer."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: l10n.dbk:176
+msgid "How to help the translation effort"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: l10n.dbk:178
+msgid ""
+"Choose what you want to translate, make sure that nobody is already working "
+"on it (using your debian-l10n-XXX mailing list), translate it, get it "
+"reviewed by other native speakers on your l10n mailing list, and provide it "
+"to the maintainer of the package (see next point)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: l10n.dbk:186
+msgid "How to provide a translation for inclusion in a package"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: l10n.dbk:188
+msgid ""
+"Make sure your translation is correct (asking for review on your l10n "
+"mailing list) before providing it for inclusion. It will save time for "
+"everyone, and avoid the chaos resulting in having several versions of the "
+"same document in bug reports."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: l10n.dbk:194
+msgid ""
+"The best solution is to file a regular bug containing the translation "
+"against the package. Make sure to use the 'PATCH' tag, and to not use a "
+"severity higher than 'wishlist', since the lack of translation never "
+"prevented a program from running."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: l10n.dbk:204
+msgid "Best current practice concerning l10n"
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: l10n.dbk:208
+msgid ""
+"As a maintainer, never edit the translations in any way (even to reformat "
+"the layout) without asking on the corresponding l10n mailing list. You risk "
+"for example breaksing the encoding of the file by doing so. Moreover, what "
+"you consider an error can be right (or even needed) in the given language."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: l10n.dbk:216
+msgid ""
+"As a translator, if you find an error in the original text, make sure to "
+"report it. Translators are often the most attentive readers of a given "
+"text, and if they don't report the errors they find, nobody will."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: l10n.dbk:223
+msgid ""
+"In any case, remember that the major issue with l10n is that it requires "
+"several people to cooperate, and that it is very easy to start a flamewar "
+"about small problems because of misunderstandings. So if you have problems "
+"with your interlocutor, ask for help on the corresponding l10n mailing list, "
+"on debian-i18n, or even on debian-devel (but beware, l10n discussions very "
+"often become flamewars on that list :)"
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: l10n.dbk:233
+msgid ""
+"In any case, cooperation can only be achieved with <emphasis role=\"strong"
+"\">mutual respect</emphasis>."
+msgstr ""
--- /dev/null
+# Debian Developer's Reference (Japanese)
+# Hideki Yamane (Debian-JP) <henrich@debian.or.jp>, 2007.
+#
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: developers-reference _VERSION_\n"
+"Report-Msgid-Bugs-To: \n"
+"POT-Creation-Date: 2007-07-01 21:18+0000\n"
+"PO-Revision-Date: 2007-08-02 22:30+0900\n"
+"Last-Translator: Hideki Yamane (Debian-JP) <henrich@debian.or.jp>\n"
+"Language-Team: Debian JP Project <debian-doc@debian.or.jp>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+# type: Content of: <chapter><title>
+#: new-maintainer.dbk:7
+msgid "Applying to Become a Maintainer"
+msgstr "開発者になるために応募する"
+
+# type: Content of: <chapter><section><title>
+#: new-maintainer.dbk:9
+msgid "Getting started"
+msgstr "さあ、はじめよう"
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:11
+msgid ""
+"So, you've read all the documentation, you've gone through the <ulink url="
+"\"&url-newmaint-guide;\">Debian New Maintainers' Guide</ulink>, understand "
+"what everything in the <systemitem role=\"package\">hello</systemitem> "
+"example package is for, and you're about to Debianize your favorite piece of "
+"software. How do you actually become a Debian developer so that your work "
+"can be incorporated into the Project?"
+msgstr ""
+"さて、あなたは全てのドキュメントを読み終え、<ulink url=\"&url-newmaint-guide;\">"
+"Debian 新メンテナガイド</ulink>を通して例題の <systemitem role=\"package\">"
+"hello</systemitem> パッケージがどの様になっているのか全てを理解し、お気に入りの"
+"ソフトウェアの一つを Debianize (Debian パッケージ化) しようとしているところです。"
+"実際のところ、どうやったら Debian 開発者になってプロジェクトに成果を受け入れて"
+"もらえるようになるのでしょうか?"
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:19
+msgid ""
+"Firstly, subscribe to &email-debian-devel; if you haven't already. Send the "
+"word <literal>subscribe</literal> in the <emphasis>Subject</emphasis> of an "
+"email to &email-debian-devel-req;. In case of problems, contact the list "
+"administrator at &email-listmaster;. More information on available mailing "
+"lists can be found in <xref linkend=\"mailing-lists\"/> . &email-debian-"
+"devel-announce; is another list which is mandatory for anyone who wishes to "
+"follow Debian's development."
+msgstr ""
+"まず始めに、まだであれば &email-debian-devel; を購読しましょう。"
+"<literal>subscribe</literal> という単語を<emphasis>サブジェクト</emphasis>に"
+"書いた &email-debian-devel-req; へのメールを送ってください。"
+"何か問題がある場合は、&email-listmaster; のメーリングリスト管理者に確認を"
+"とりましょう。"
+"メーリングリストについての詳しい情報は <xref linkend=\"mailing-lists\"/> で"
+"見つけられます。"
+"それから &email-debian-devel-announce; は、Debian の開発に携わりたいという人は"
+"誰でも読む義務がある、もう一つのメーリングリストです。"
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:29
+msgid ""
+"You should subscribe and lurk (that is, read without posting) for a bit "
+"before doing any coding, and you should post about your intentions to work "
+"on something to avoid duplicated effort."
+msgstr ""
+"参加後、何かコーディングを始める前に、しばらくの間「待ち」(投稿せずに読むだけ) の"
+"状態でいるのが良いでしょう。それから、重複作業を避けるために何の作業をしようと"
+"しているのか表明をする必要があります。"
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:34
+msgid ""
+"Another good list to subscribe to is &email-debian-mentors;. See <xref "
+"linkend=\"mentors\"/> for details. The IRC channel <literal>#debian</"
+"literal> can also be helpful; see <xref linkend=\"irc-channels\"/> ."
+msgstr ""
+"もう一つ、購読すると良いのが &email-debian-mentors; です。"
+"詳細は <xref linkend=\"mentors\"/> を参照してください。"
+"IRC チャンネル <literal>#debian</literal> も役に立つでしょう。"
+"<xref linkend=\"irc-channels\"/> を見てください。"
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:40
+msgid ""
+"When you know how you want to contribute to &debian-formal;, you should get "
+"in contact with existing Debian maintainers who are working on similar "
+"tasks. That way, you can learn from experienced developers. For example, "
+"if you are interested in packaging existing software for Debian, you should "
+"try to get a sponsor. A sponsor will work together with you on your package "
+"and upload it to the Debian archive once they are happy with the packaging "
+"work you have done. You can find a sponsor by mailing the &email-debian-"
+"mentors; mailing list, describing your package and yourself and asking for a "
+"sponsor (see <xref linkend=\"sponsoring\"/> and <ulink url=\"&url-mentors;"
+"\"></ulink> for more information on sponsoring). On the other hand, if you "
+"are interested in porting Debian to alternative architectures or kernels you "
+"can subscribe to port specific mailing lists and ask there how to get "
+"started. Finally, if you are interested in documentation or Quality "
+"Assurance (QA) work you can join maintainers already working on these tasks "
+"and submit patches and improvements."
+msgstr ""
+"何らかの方法で &debian-formal; に対して貢献したいと思った時、同じような作業に従事"
+"している既存の Debian メンテナにコンタクトしてみてください。そうすれば経験豊かな"
+"開発者から学ぶことができます。例えば、既にあるソフトウェアを Debian 用にパッケージ"
+"化するのに興味を持っている場合、スポンサーを探しましょう。スポンサーはあなたと一緒"
+"にパッケージ化作業を手伝い、あなたの作業が満足する出来になったら Debian アーカイブ"
+"にパッケージをアップロードしてくれます。スポンサーは、&email-debian-mentors; "
+"メーリングリストへパッケージとあなた自身の説明とスポンサーを探していることをメール"
+"して見つけましょう (詳細については <xref linkend=\"sponsoring\"/> および "
+"<ulink url=\"&url-mentors;\"></ulink> を参照)。"
+"さらに、Debian を他のアーキテクチャやカーネルへ移植するのに興味を持っている場合、"
+"移植関連のメーリングリストに参加して、どうやって始めればいいのかを尋ねましょう。"
+"最後に、ドキュメントや品質保証 (Quality Assuarance、QA) の作業に興味がある場合は、"
+"この様な作業を行っているメンテナ達の集まりに参加して、パッチや改善案を送ってください。"
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:57
+msgid ""
+"One pitfall could be a too-generic local part in your mailadress: Terms like "
+"mail, admin, root, master should be avoided, please see <ulink url=\"&url-"
+"debian-lists;\"></ulink> for details."
+msgstr ""
+"メールアドレスのローカルパートが非常に一般的な場合、落とし穴にハマる可能性があります。"
+"mail、admin、root、master のような単語は使わないようにするべきです。"
+"詳しくは <ulink url=\"&url-debian-lists;\"></ulink> を参照してください。"
+
+# type: Content of: <chapter><section><title>
+#: new-maintainer.dbk:64
+msgid "Debian mentors and sponsors"
+msgstr "Debian メンター (mentors) とスポンサー (sponsors) について "
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:66
+msgid ""
+"The mailing list &email-debian-mentors; has been set up for novice "
+"maintainers who seek help with initial packaging and other developer-related "
+"issues. Every new developer is invited to subscribe to that list (see <xref "
+"linkend=\"mailing-lists\"/> for details)."
+msgstr ""
+"メーリングリスト &email-debian-mentors; が、パッケージ化の第一歩目や他の開発者と"
+"調整が必要な問題などで手助けを必要としている新米メンテナに用意されています。"
+"新たな開発者は皆、このメーリングリストに参加することをお勧めします "
+"(詳細は <xref linkend=\"mailing-lists\"/> を参照してください)。"
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:72
+msgid ""
+"Those who prefer one-on-one help (e.g., via private email) should also post "
+"to that list and an experienced developer will volunteer to help."
+msgstr ""
+"一対一での指導 (つまり、プライベートなメールのやり取りで) の方が良い、という人も"
+"このメーリングリストに投稿しましょう。経験豊かな開発者が助けになってくれるはずです。"
+
+#
+#
+#
+#
+# type: Content of: <chapter><section><para>
+#. FIXME - out of order
+#. Those who are seeking a
+#. sponsor can request one at <ulink url="http://www.internatif.org/bortzmeyer/debian/sponsor/"></ulink>.
+#: new-maintainer.dbk:76
+msgid ""
+"In addition, if you have some packages ready for inclusion in Debian, but "
+"are waiting for your new maintainer application to go through, you might be "
+"able find a sponsor to upload your package for you. Sponsors are people who "
+"are official Debian Developers, and who are willing to criticize and upload "
+"your packages for you. Please read the unofficial debian-mentors FAQ at "
+"<ulink url=\"&url-mentors;\"></ulink> first."
+msgstr ""
+"付け加えておくと、Debian にパッケージを含める準備が出来ているものの、新規メンテナ"
+"応募作業の完了を待っているような場合は、パッケージをアップロードしてくれるスポンサー"
+"を探すことも出来ます。スポンサーは公式 Debian 開発者で、あなたのパッケージに対して"
+"問題を探したりアップロードしようとしてくれる人達です。"
+"まずは <ulink url=\"&url-mentors;\"></ulink> にある非公式 debian-mentors FAQ "
+"を読んでください。"
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:89
+msgid ""
+"If you wish to be a mentor and/or sponsor, more information is available in "
+"<xref linkend=\"newmaint\"/> ."
+msgstr ""
+"メンターあるいはスポンサーになりたいという人は、<xref linkend=\"newmaint\"/> "
+"でより詳細な情報が手に入ります。"
+
+# type: Content of: <chapter><section><title>
+#: new-maintainer.dbk:95
+msgid "Registering as a Debian developer"
+msgstr "Debian 開発者への登録を行う"
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:97
+msgid ""
+"Before you decide to register with &debian-formal;, you will need to read "
+"all the information available at the <ulink url=\"&url-newmaint;\">New "
+"Maintainer's Corner</ulink>. It describes in detail the preparations you "
+"have to do before you can register to become a Debian developer. For "
+"example, before you apply, you have to read the <ulink url=\"&url-social-"
+"contract;\">Debian Social Contract</ulink>. Registering as a developer "
+"means that you agree with and pledge to uphold the Debian Social Contract; "
+"it is very important that maintainers are in accord with the essential ideas "
+"behind &debian-formal;. Reading the <ulink url=\"&url-gnu-manifesto;\">GNU "
+"Manifesto</ulink> would also be a good idea."
+msgstr ""
+" &debian-formal; への登録を決める前に、<ulink url=\"&url-newmaint;\">"
+"新メンテナのコーナー</ulink>で手に入る全ての情報に目を通してください。"
+"Debian 開発者になるための登録をする前に必要な準備がすべて記載されています。"
+"例えば、応募の前に <ulink url=\"&url-social-contract;\">Debian 社会契約</ulink>"
+"を読む必要があります。開発者として登録するということは、Debian 社会契約に同意し、"
+"遵守し続けることを意味します。メンテナにとって &debian-formal; の背景にある根本的な"
+"理念に従うのは大変重要な事です。<ulink url=\"&url-gnu-manifesto;\">"
+"GNU Manifesto</ulink>を読むのも良い考えでしょう。"
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:111
+msgid ""
+"The process of registering as a developer is a process of verifying your "
+"identity and intentions, and checking your technical skills. As the number "
+"of people working on &debian-formal; has grown to over &number-of-"
+"maintainers; and our systems are used in several very important places, we "
+"have to be careful about being compromised. Therefore, we need to verify "
+"new maintainers before we can give them accounts on our servers and let them "
+"upload packages."
+msgstr ""
+"開発者としての登録手順は、あなたのアイデンティティと意図と技術的なスキルレベル"
+"の確認手順でもあります。&debian-formal; について作業をする人の数は "
+"&number-of-maintainers; を越えて増えつづけています。そして、我々のシステムは"
+"幾多の重要な場所で使われており、セキュリティ侵害には十分に注意しなければなりません。"
+"つまり、我々のサーバのアカウントを与えたりパッケージのアップロードを許可したり"
+"する前には新たなメンテナを審査する必要があるのです。"
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:120
+msgid ""
+"Before you actually register you should have shown that you can do competent "
+"work and will be a good contributor. You show this by submitting patches "
+"through the Bug Tracking System and having a package sponsored by an "
+"existing Debian Developer for a while. Also, we expect that contributors "
+"are interested in the whole project and not just in maintaining their own "
+"packages. If you can help other maintainers by providing further "
+"information on a bug or even a patch, then do so!"
+msgstr ""
+"実際に登録する前に、あなたは良い仕事ができる貢献者となり得ることを示さねばなりません。"
+"バグ追跡システムを介してパッチを送ったり、既存の Debian 開発者のスポンサーによる"
+"パッケージの管理をしばらくの間行うなどして、これをアピールします。"
+"付け加えておくと、我々は貢献してくれる人達が単に自分のパッケージをメンテナンスする"
+"だけにではなく、プロジェクト全体について興味を持ってくれることを期待しています。"
+"バグについての追加情報、できればパッチの提供などによって他のメンテナを手助けできる"
+"のであれば、早速実行しましょう!"
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:129
+msgid ""
+"Registration requires that you are familiar with Debian's philosophy and "
+"technical documentation. Furthermore, you need a GnuPG key which has been "
+"signed by an existing Debian maintainer. If your GnuPG key is not signed "
+"yet, you should try to meet a Debian Developer in person to get your key "
+"signed. There's a <ulink url=\"&url-gpg-coord;\">GnuPG Key Signing "
+"Coordination page</ulink> which should help you find a Debian Developer "
+"close to you. (If there is no Debian Developer close to you, alternative "
+"ways to pass the ID check may be permitted as an absolute exception on a "
+"case-by-case-basis. See the <ulink url=\"&url-newmaint-id;\">identification "
+"page</ulink> for more information.)"
+msgstr ""
+"登録に際しては Debian の考え方と技術文書を充分理解している必要があります。"
+"さらに、既存のメンテナに署名をしてもらった GnuPG 鍵が必要です。"
+"まだ GnuPG 鍵に署名してもらっていない場合は、あなたの鍵に署名してくれる Debian "
+"開発者に会いましょう。"
+"<ulink url=\"&url-gpg-coord;\">GnuPG Key Signing Coordination page</ulink> "
+"が近くの Debian 開発者を探す手助けとなるでしょう。"
+"(近くに Debian 開発者がいない場合は、ID チェックを通過する別の方法として"
+"ケースバイケースで例外処理として扱うことも可能です。"
+"詳細については <ulink url=\"&url-newmaint-id;\">identification page</ulink> "
+"を参照してください)。"
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:142
+msgid ""
+"If you do not have an OpenPGP key yet, generate one. Every developer needs "
+"an OpenPGP key in order to sign and verify package uploads. You should read "
+"the manual for the software you are using, since it has much important "
+"information which is critical to its security. Many more security failures "
+"are due to human error than to software failure or high-powered spy "
+"techniques. See <xref linkend=\"key-maint\"/> for more information on "
+"maintaining your public key."
+msgstr ""
+"OpenPGP 鍵をまだ持っていない場合は生成してください。全ての開発者がパッケージを"
+"アップロードする際に署名と確認の為に OpenPGP 鍵を必要とします。"
+"必ず、使っているソフトのマニュアルを読んでおいてください。何故ならば、"
+"セキュリティに直結している重要な情報を含んでいるからです。"
+"多くのセキュリティ事故は、殆どがソフトウェアの問題や高度なスパイテクニックではなく、"
+"人間が犯すミスや勘違いによるものです。"
+"公開鍵の管理についての詳細は <xref linkend=\"key-maint\"/> を参照してください。"
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:150
+msgid ""
+"Debian uses the <command>GNU Privacy Guard</command> (package <systemitem "
+"role=\"package\">gnupg</systemitem> version 1 or better) as its baseline "
+"standard. You can use some other implementation of OpenPGP as well. Note "
+"that OpenPGP is an open standard based on <ulink url=\"&url-rfc2440;\">RFC "
+"2440</ulink>."
+msgstr ""
+"Debian では <command>GNU Privacy Guard</command> (<systemitem role=\"package\">"
+"gnupg</systemitem> パッケージ、バージョン 1 以降) を標準として利用しています。"
+"他の OpenPGP 実装も同様に利用できます。OpenPGP は <ulink url=\"&url-rfc2440;\">"
+"RFC 2440</ulink> に準拠した公開標準です。"
+
+# type: Content of: <chapter><section><para><footnote>
+#: new-maintainer.dbk:157
+msgid ""
+"You need a version 4 key for use in Debian Development. Your key length "
+"must be at least 1024 bits; there is no reason to use a smaller key, and "
+"doing so would be much less secure. <footnote>"
+msgstr ""
+"Debian での開発においては、バージョン 4 の鍵の利用が求められます。"
+"鍵の長さは少なくとも 1024 ビットが必要です。それより短い鍵を利用する理由は何も"
+"ありませんし、使った場合はあまり安全ではなくなります。<footnote>"
+
+# type: Content of: <chapter><section><para><footnote><para>
+#: new-maintainer.dbk:159
+msgid ""
+"Version 4 keys are keys conforming to the OpenPGP standard as defined in RFC "
+"2440. Version 4 is the key type that has always been created when using "
+"GnuPG. PGP versions since 5.x also could create v4 keys, the other choice "
+"having beein pgp 2.6.x compatible v3 keys (also called legacy RSA by PGP)."
+msgstr ""
+"バージョン 4 の鍵は、RFC 2440 で規定されているように OpenPGP 標準に適合します。"
+"GnuPG を使って鍵を作ると、鍵のタイプは常にバージョン 4 になります。"
+"PGP はバージョン 5.x からバージョン 4 の鍵を作ることもできるようになっています。"
+"別の選択肢としては、v3 の鍵 (PGP ではレガシー RSA とも呼ばれます) と互換性のある "
+"pgp 2.6.x になります。"
+
+# type: Content of: <chapter><section><para><footnote><para>
+#: new-maintainer.dbk:163
+msgid ""
+"Version 4 (primary) keys can either use the RSA or the DSA algorithms, so "
+"this has nothing to do with GnuPG's question about which kind of key do you "
+"want: (1) DSA and Elgamal, (2) DSA (sign only), (5) RSA (sign only). If "
+"you don't have any special requirements just pick the default."
+msgstr ""
+"バージョン 4 (primary) 鍵は RSA アルゴリズムか DSA アルゴリズムのどちらでも利用"
+"できます。"
+"つまり、GnuPG が (1) DSA and Elgamal, (2) DSA (sign only), (5) RSA (sign only) "
+"の中からどの種類の鍵を使いたいか質問してきても何も迷うことはありません。"
+"特別な理由がない限りは単にデフォルトを選んでください。"
+
+# type: Content of: <chapter><section><para><footnote><para>
+#: new-maintainer.dbk:167
+msgid ""
+"The easiest way to tell whether an existing key is a v4 key or a v3 (or v2) "
+"key is to look at the fingerprint: Fingerprints of version 4 keys are the "
+"SHA-1 hash of some key material, so they are 40 hex digits, usually grouped "
+"in blocks of 4. Fingerprints of older key format versions used MD5 and are "
+"generally shown in blocks of 2 hex digits. For example if your fingerprint "
+"looks like <literal>5B00 C96D 5D54 AEE1 206B AF84 DE7A AF6E 94C0 9C7F</"
+"literal> then it's a v4 key."
+msgstr ""
+"今ある鍵が v4 の鍵なのか v3 (あるいは v2) の鍵なのかを判断するもっとも簡単な方法"
+"はフィンガープリントを見ることです。バージョン 4 鍵のフィンガープリントは、鍵要素"
+"の一部を SHA-1 ハッシュにしたもので、通常 4 文字ごとに区切られた 40 文字の 16 進数"
+"になります。"
+"古いバージョンの鍵形式では、フィンガープリントは MD5 を使っており、2 文字ごとに"
+"区切られた 16 進数で表示されます。"
+"例えば、あなたのフィンガープリントが <literal>5B00 C96D 5D54 AEE1 206B AF84 "
+"DE7A AF6E 94C0 9C7F</literal> のようになっている場合は、v4 鍵です。"
+
+# type: Content of: <chapter><section><para><footnote><para>
+#: new-maintainer.dbk:174
+msgid ""
+"Another possibility is to pipe the key into <command>pgpdump</command>, "
+"which will say something like Public Key Packet - Ver 4."
+msgstr ""
+"別のやり方として、鍵をパイプで <command>pgpdump</command> に渡して "
+"Public Key Packet - Ver 4 のような出力を得るという方法もあります。"
+
+# type: Content of: <chapter><section><para><footnote><para>
+#: new-maintainer.dbk:176
+msgid ""
+"Also note that your key must be self-signed (i.e. it has to sign all its "
+"own user IDs; this prevents user ID tampering). All modern OpenPGP software "
+"does that automatically, but if you have an older key you may have to "
+"manually add those signatures."
+msgstr ""
+"もちろん、鍵が自己署名されている必要があります (つまり、全ての鍵は所有者の ID に"
+"よって署名されている必要があります。これによって、ユーザ ID の偽造 (タンパリング) "
+"を防いでいます)。"
+"最近の OpenPGP ソフトウェアは皆これを自動的に行いますが、古い鍵を持っているような"
+"場合は自分でこの署名を追加する必要があるでしょう。"
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:182
+msgid ""
+"If your public key isn't on a public key server such as &pgp-keyserv;, "
+"please read the documentation available at <ulink url=\"&url-newmaint-id;"
+"\">NM Step 2: Identification</ulink>. That document contains instructions "
+"on how to put your key on the public key servers. The New Maintainer Group "
+"will put your public key on the servers if it isn't already there."
+msgstr ""
+"あなたの公開鍵が &pgp-keyserv; などの公開鍵サーバにない場合は、<ulink "
+"url=\"&url-newmaint-id;\">新規メンテナ 手順 2: 身分証明</ulink> にあるドキュメント"
+"を読んでください。このドキュメントにはどうやって公開鍵サーバに鍵を登録するのかが"
+"記載されています。"
+"新規メンテナグループは、まだ登録されていない場合はあなたの公開鍵をサーバに登録します。"
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:190
+msgid ""
+"Some countries restrict the use of cryptographic software by their "
+"citizens. This need not impede one's activities as a Debian package "
+"maintainer however, as it may be perfectly legal to use cryptographic "
+"products for authentication, rather than encryption purposes. If you live "
+"in a country where use of cryptography even for authentication is forbidden "
+"then please contact us so we can make special arrangements."
+msgstr ""
+"幾つかの国では、一般市民の暗号関連ソフトウェアの使用について制限をかけています。"
+"しかし、このことは暗号関連ソフトウェアを暗号化ではなく認証に利用する際には完全に"
+"合法であるような場合には、Debian パッケージメンテナとしての活動を妨げることには"
+"なりません。"
+"あなたが認証目的にすら暗号技術の利用が制限される国に住んでいる、と言う場合は、"
+"我々に連絡をしていただければ特別な措置を講じることができます。"
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:198
+msgid ""
+"To apply as a new maintainer, you need an existing Debian Developer to "
+"support your application (an <emphasis>advocate</emphasis>). After you have "
+"contributed to Debian for a while, and you want to apply to become a "
+"registered developer, an existing developer with whom you have worked over "
+"the past months has to express their belief that you can contribute to "
+"Debian successfully."
+msgstr ""
+"新規メンテナの応募をするのであれば、既存の Debian 開発者にあなたの応募をサポート"
+"してもらう (<emphasis>支持者 (Advocate)</emphasis> になってもらう) 必要があります。"
+"ある程度の期間 Debian に対して貢献を行った後で、登録された開発者になるために応募を"
+"したい場合、過去何ヶ月かに渡って一緒に作業をした既存の開発者に、あなたが Debian "
+"に間違いなく貢献できることを信じている旨を表明してもらう必要があります。"
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:205
+msgid ""
+"When you have found an advocate, have your GnuPG key signed and have already "
+"contributed to Debian for a while, you're ready to apply. You can simply "
+"register on our <ulink url=\"&url-newmaint-apply;\">application page</"
+"ulink>. After you have signed up, your advocate has to confirm your "
+"application. When your advocate has completed this step you will be "
+"assigned an Application Manager who will go with you through the necessary "
+"steps of the New Maintainer process. You can always check your status on "
+"the <ulink url=\"&url-newmaint-db;\">applications status board</ulink>."
+msgstr ""
+"advocate を見つけ、GnuPG 鍵に署名をしてもらい、既にある程度の間 Debian に対して"
+"貢献的な作業をしているのであれば、応募の準備は完了です。"
+"すぐに <ulink url=\"&url-newmaint-apply;\">応募のページ</ulink>で登録できます。"
+"登録後、支持者 (Advocate) はあなたの応募に関してその意志を確認をする必要があります。"
+"支持者がこの手順を完了すると応募管理者 (Application Manager) に割り当てられます。"
+"応募管理者は、新規メンテナプロセスで必要となる手順をあなたと共に歩んでいく存在です。"
+"進捗状況については、常に <ulink url=\"&url-newmaint-db;\">"
+"applications status board</ulink> のページで確認ができます。"
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:215
+msgid ""
+"For more details, please consult <ulink url=\"&url-newmaint;\">New "
+"Maintainer's Corner</ulink> at the Debian web site. Make sure that you are "
+"familiar with the necessary steps of the New Maintainer process before "
+"actually applying. If you are well prepared, you can save a lot of time "
+"later on."
+msgstr ""
+"より詳しい内容については Debian ウェブサイトの <ulink url=\"&url-newmaint;\">"
+"新規メンテナのコーナー</ulink> を参考にしてください。"
+"実際の応募前に、新規メンテナプロセスでの必要な手順についてに詳しく理解しておいてください。"
+"十分に準備ができていたら、後で費やす時間を大いに減らすことができます。"
+
--- /dev/null
+# SOME DESCRIPTIVE TITLE
+# Copyright (C) YEAR Free Software Foundation, Inc.
+# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
+#
+#, fuzzy
+msgid ""
+msgstr ""
+"Project-Id-Version: PACKAGE VERSION\n"
+"POT-Creation-Date: 2007-07-01 21:18+0000\n"
+"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
+"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
+"Language-Team: LANGUAGE <LL@li.org>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: ENCODING\n"
+
+# type: Content of: <chapter><title>
+#: pkgs.dbk:7
+msgid "Managing Packages"
+msgstr ""
+
+# type: Content of: <chapter><para>
+#: pkgs.dbk:9
+msgid ""
+"This chapter contains information related to creating, uploading, "
+"maintaining, and porting packages."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:13
+msgid "New packages"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:15
+msgid ""
+"If you want to create a new package for the Debian distribution, you should "
+"first check the <ulink url=\"&url-wnpp;\">Work-Needing and Prospective "
+"Packages (WNPP)</ulink> list. Checking the WNPP list ensures that no one is "
+"already working on packaging that software, and that effort is not "
+"duplicated. Read the <ulink url=\"&url-wnpp;\">WNPP web pages</ulink> for "
+"more information."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:23
+msgid ""
+"Assuming no one else is already working on your prospective package, you "
+"must then submit a bug report (<xref linkend=\"submit-bug\"/> ) against the "
+"pseudo-package <systemitem role=\"package\">wnpp</systemitem> describing "
+"your plan to create a new package, including, but not limiting yourself to, "
+"a description of the package, the license of the prospective package, and "
+"the current URL where it can be downloaded from."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:31
+msgid ""
+"You should set the subject of the bug to ``ITP: <replaceable>foo</"
+"replaceable> -- <replaceable>short description</replaceable>'', substituting "
+"the name of the new package for <replaceable>foo</replaceable>. The "
+"severity of the bug report must be set to <emphasis>wishlist</emphasis>. If "
+"you feel it's necessary, send a copy to &email-debian-devel; by putting the "
+"address in the <literal>X-Debbugs-CC:</literal> header of the message (no, "
+"don't use <literal>CC:</literal>, because that way the message's subject "
+"won't indicate the bug number)."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:41
+msgid ""
+"Please include a <literal>Closes: bug#<replaceable>nnnnn</replaceable></"
+"literal> entry in the changelog of the new package in order for the bug "
+"report to be automatically closed once the new package is installed in the "
+"archive (see <xref linkend=\"upload-bugfix\"/> )."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:47
+msgid ""
+"When closing security bugs include CVE numbers as well as the Closes: "
+"#nnnnn. This is useful for the security team to track vulnerabilities. If "
+"an upload is made to fix the bug before the advisory ID is known, it is "
+"encouraged to modify the historical changelog entry with the next upload. "
+"Even in this case, please include all available pointers to background "
+"information in the original changelog entry."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:55
+msgid ""
+"There are a number of reasons why we ask maintainers to announce their "
+"intentions:"
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:61
+msgid ""
+"It helps the (potentially new) maintainer to tap into the experience of "
+"people on the list, and lets them know if anyone else is working on it "
+"already."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:67
+msgid ""
+"It lets other people thinking about working on the package know that there "
+"already is a volunteer, so efforts may be shared."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:73
+msgid ""
+"It lets the rest of the maintainers know more about the package than the one "
+"line description and the usual changelog entry ``Initial release'' that gets "
+"posted to <literal>debian-devel-changes</literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:80
+msgid ""
+"It is helpful to the people who live off unstable (and form our first line "
+"of testers). We should encourage these people."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:86
+msgid ""
+"The announcements give maintainers and other interested parties a better "
+"feel of what is going on, and what is new, in the project."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:92
+msgid ""
+"Please see <ulink url=\"http://&ftp-master-host;/REJECT-FAQ.html\"></ulink> "
+"for common rejection reasons for a new package."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:98
+msgid "Recording changes in the package"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:100
+msgid ""
+"Changes that you make to the package need to be recorded in the "
+"<filename>debian/changelog</filename>. These changes should provide a "
+"concise description of what was changed, why (if it's in doubt), and note if "
+"any bugs were closed. They also record when the package was completed. "
+"This file will be installed in <filename>/usr/share/doc/"
+"<replaceable>package</replaceable>/changelog.Debian.gz</filename>, or "
+"<filename>/usr/share/doc/<replaceable>package</replaceable>/changelog.gz</"
+"filename> for native packages."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:111
+msgid ""
+"The <filename>debian/changelog</filename> file conforms to a certain "
+"structure, with a number of different fields. One field of note, the "
+"<emphasis>distribution</emphasis>, is described in <xref linkend="
+"\"distribution\"/> . More information about the structure of this file can "
+"be found in the Debian Policy section titled <filename>debian/changelog</"
+"filename>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:119
+msgid ""
+"Changelog entries can be used to automatically close Debian bugs when the "
+"package is installed into the archive. See <xref linkend=\"upload-bugfix\"/"
+"> ."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:123
+msgid ""
+"It is conventional that the changelog entry of a package that contains a new "
+"upstream version of the software looks like this:"
+msgstr ""
+
+# type: Content of: <chapter><section><screen>
+#: pkgs.dbk:127
+#, no-wrap
+msgid "* new upstream version"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:130
+msgid ""
+"There are tools to help you create entries and finalize the "
+"<filename>changelog</filename> for release — see <xref linkend=\"devscripts"
+"\"/> and <xref linkend=\"dpkg-dev-el\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:135
+msgid "See also <xref linkend=\"bpp-debian-changelog\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:140
+msgid "Testing the package"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:142
+msgid ""
+"Before you upload your package, you should do basic testing on it. At a "
+"minimum, you should try the following activities (you'll need to have an "
+"older version of the same Debian package around):"
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:149
+msgid ""
+"Install the package and make sure the software works, or upgrade the package "
+"from an older version to your new version if a Debian package for it already "
+"exists."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:156
+msgid ""
+"Run <command>lintian</command> over the package. You can run "
+"<command>lintian</command> as follows: <literal>lintian -v "
+"<replaceable>package-version</replaceable>.changes</literal>. This will "
+"check the source package as well as the binary package. If you don't "
+"understand the output that <command>lintian</command> generates, try adding "
+"the <literal>-i</literal> switch, which will cause <command>lintian</"
+"command> to output a very verbose description of the problem."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:165
+msgid ""
+"Normally, a package should <emphasis>not</emphasis> be uploaded if it causes "
+"lintian to emit errors (they will start with <literal>E</literal>)."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:169
+msgid ""
+"For more information on <command>lintian</command>, see <xref linkend="
+"\"lintian\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:175
+msgid ""
+"Optionally run <xref linkend=\"debdiff\"/> to analyze changes from an older "
+"version, if one exists."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:181
+msgid ""
+"Downgrade the package to the previous version (if one exists) — this tests "
+"the <filename>postrm</filename> and <filename>prerm</filename> scripts."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:187
+msgid "Remove the package, then reinstall it."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:192
+msgid ""
+"Copy the source package in a different directory and try unpacking it and "
+"rebuilding it. This tests if the package relies on existing files outside "
+"of it, or if it relies on permissions being preserved on the files shipped "
+"inside the .diff.gz file."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:202
+msgid "Layout of the source package"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:204
+msgid "There are two types of Debian source packages:"
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:209
+msgid ""
+"the so-called <emphasis>native</emphasis> packages, where there is no "
+"distinction between the original sources and the patches applied for Debian"
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:215
+msgid ""
+"the (more common) packages where there's an original source tarball file "
+"accompanied by another file that contains the patches applied for Debian"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:221
+msgid ""
+"For the native packages, the source package includes a Debian source control "
+"file (<literal>.dsc</literal>) and the source tarball (<literal>.tar.gz</"
+"literal>). A source package of a non-native package includes a Debian "
+"source control file, the original source tarball (<literal>.orig.tar.gz</"
+"literal>) and the Debian patches (<literal>.diff.gz</literal>)."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:229
+msgid ""
+"Whether a package is native or not is determined when it is built by "
+"<citerefentry> <refentrytitle>dpkg-buildpackage</refentrytitle> "
+"<manvolnum>1</manvolnum> </citerefentry>. The rest of this section relates "
+"only to non-native packages."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:235
+msgid ""
+"The first time a version is uploaded which corresponds to a particular "
+"upstream version, the original source tar file should be uploaded and "
+"included in the <filename>.changes</filename> file. Subsequently, this very "
+"same tar file should be used to build the new diffs and <filename>.dsc</"
+"filename> files, and will not need to be re-uploaded."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:242
+msgid ""
+"By default, <command>dpkg-genchanges</command> and <command>dpkg-"
+"buildpackage</command> will include the original source tar file if and only "
+"if the Debian revision part of the source version number is 0 or 1, "
+"indicating a new upstream version. This behavior may be modified by using "
+"<literal>-sa</literal> to always include it or <literal>-sd</literal> to "
+"always leave it out."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:250
+msgid ""
+"If no original source is included in the upload, the original source tar-"
+"file used by <command>dpkg-source</command> when constructing the <filename>."
+"dsc</filename> file and diff to be uploaded <emphasis>must</emphasis> be "
+"byte-for-byte identical with the one already in the archive."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:257
+msgid ""
+"Please notice that, in non-native packages, permissions on files that are "
+"not present in the .orig.tar.gz will not be preserved, as diff does not "
+"store file permissions in the patch."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:264
+msgid "Picking a distribution"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:266
+msgid ""
+"Each upload needs to specify which distribution the package is intended "
+"for. The package build process extracts this information from the first "
+"line of the <filename>debian/changelog</filename> file and places it in the "
+"<literal>Distribution</literal> field of the <literal>.changes</literal> "
+"file."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:272
+msgid ""
+"There are several possible values for this field: `stable', `unstable', "
+"`testing-proposed-updates' and `experimental'. Normally, packages are "
+"uploaded into <emphasis>unstable</emphasis>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:277
+msgid ""
+"Actually, there are two other possible distributions: `stable-security' and "
+"`testing-security', but read <xref linkend=\"bug-security\"/> for more "
+"information on those."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:282
+msgid ""
+"It is not possible to upload a package into several distributions at the "
+"same time."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:286
+msgid "Special case: uploads to the <emphasis>stable</emphasis> distribution"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:288
+msgid ""
+"Uploading to <emphasis>stable</emphasis> means that the package will "
+"transfered to the <emphasis>p-u-new</emphasis>-queue for review by the "
+"stable release managers, and if approved will be installed in "
+"<filename>stable-proposed-updates</filename> directory of the Debian "
+"archive. From there, it will be included in <emphasis>stable</emphasis> "
+"with the next point release."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:296
+msgid ""
+"Extra care should be taken when uploading to <emphasis>stable</emphasis>. "
+"Basically, a package should only be uploaded to stable if one of the "
+"following happens:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:303
+msgid "a truly critical functionality problem"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:308
+msgid "the package becomes uninstallable"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:313
+msgid "a released architecture lacks the package"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:318
+msgid ""
+"In the past, uploads to <emphasis>stable</emphasis> were used to address "
+"security problems as well. However, this practice is deprecated, as uploads "
+"used for Debian security advisories are automatically copied to the "
+"appropriate <filename>proposed-updates</filename> archive when the advisory "
+"is released. See <xref linkend=\"bug-security\"/> for detailed information "
+"on handling security problems."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:326
+msgid ""
+"Changing anything else in the package that isn't important is discouraged, "
+"because even trivial fixes can cause bugs later on."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:330
+msgid ""
+"Packages uploaded to <emphasis>stable</emphasis> need to be compiled on "
+"systems running <emphasis>stable</emphasis>, so that their dependencies are "
+"limited to the libraries (and other packages) available in <emphasis>stable</"
+"emphasis>; for example, a package uploaded to <emphasis>stable</emphasis> "
+"that depends on a library package that only exists in unstable will be "
+"rejected. Making changes to dependencies of other packages (by messing with "
+"<literal>Provides</literal> or shlibs files), possibly making those other "
+"packages uninstallable, is strongly discouraged."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:340
+msgid ""
+"The Release Team (which can be reached at &email-debian-release;) will "
+"regularly evaluate the uploads To <emphasis>stable-proposed-updates</"
+"emphasis> and decide if your package can be included in <emphasis>stable</"
+"emphasis>. Please be clear (and verbose, if necessary) in your changelog "
+"entries for uploads to <emphasis>stable</emphasis>, because otherwise the "
+"package won't be considered for inclusion."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:349
+msgid ""
+"It's best practice to speak with the stable release manager "
+"<emphasis>before</emphasis> uploading to <emphasis>stable</emphasis>/"
+"<emphasis>stable-proposed-updates</emphasis>, so that the uploaded package "
+"fits the needs of the next point release."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:357
+msgid ""
+"Special case: uploads to <emphasis>testing/testing-proposed-updates</"
+"emphasis>"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:359
+msgid ""
+"Please see the information in the <link linkend=\"t-p-u\">testing section</"
+"link> for details."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:367
+msgid "Uploading a package"
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:369
+msgid "Uploading to <literal>ftp-master</literal>"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:371
+msgid ""
+"To upload a package, you should upload the files (including the signed "
+"changes and dsc-file) with anonymous ftp to <literal>&ftp-master-host;</"
+"literal> in the directory <ulink url=\"ftp://&ftp-master-host;&upload-queue;"
+"\">&upload-queue;</ulink>. To get the files processed there, they need to "
+"be signed with a key in the debian keyring."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:379
+msgid ""
+"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 all files have been uploaded."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:384
+msgid ""
+"You may also find the Debian packages <xref linkend=\"dupload\"/> or <xref "
+"linkend=\"dput\"/> useful when uploading packages. These handy programs "
+"help automate the process of uploading packages into Debian."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:389
+msgid ""
+"For removing packages, please see the README file in that ftp directory, and "
+"the Debian package <xref linkend=\"dcut\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:395
+msgid "Uploading to <literal>non-US</literal>"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:397
+msgid ""
+"<emphasis>Note:</emphasis> non-us was discontinued with the release of sarge."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:402
+msgid "Delayed uploads"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:404
+msgid ""
+"Delayed uploads are done for the moment via the delayed queue at gluck. The "
+"upload-directory is <literal>gluck:~tfheen/DELAYED/[012345678]-day</"
+"literal>. 0-day is uploaded multiple times per day to ftp-master."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:409
+msgid "With a fairly recent dput, this section"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: pkgs.dbk:412
+#, no-wrap
+msgid ""
+"[tfheen_delayed]\n"
+"method = scp\n"
+"fqdn = gluck.debian.org\n"
+"incoming = ~tfheen"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:418
+msgid "in ~/.dput.cf should work fine for uploading to the DELAYED queue."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:421
+msgid ""
+"<emphasis>Note:</emphasis> Since this upload queue goes to <literal>ftp-"
+"master</literal>, the prescription found in <xref linkend=\"upload-ftp-master"
+"\"/> applies here as well."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:428
+msgid "Security uploads"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:430
+msgid ""
+"Do <emphasis role=\"strong\">NOT</emphasis> 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. For details, please see section <xref linkend="
+"\"bug-security\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:440
+msgid "Other upload queues"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:442
+msgid ""
+"The scp queues on ftp-master, and security are mostly unusable due to the "
+"login restrictions on those hosts."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:446
+msgid ""
+"The anonymous queues on ftp.uni-erlangen.de and ftp.uk.debian.org are "
+"currently down. Work is underway to resurrect them."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:450
+msgid ""
+"The queues on master.debian.org, samosa.debian.org, master.debian.or.jp, and "
+"ftp.chiark.greenend.org.uk are down permanently, and will not be "
+"resurrected. The queue in Japan will be replaced with a new queue on hp."
+"debian.or.jp some day."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:456
+msgid ""
+"For the time being, the anonymous ftp queue on auric.debian.org (the former "
+"ftp-master) works, but it is deprecated and will be removed at some point in "
+"the future."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:463
+msgid "Notification that a new package has been installed"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:465
+msgid ""
+"The Debian archive maintainers are responsible for handling package "
+"uploads. For the most part, uploads are automatically handled on a daily "
+"basis by the archive maintenance tools, <command>katie</command>. "
+"Specifically, updates to existing packages to the `unstable' distribution "
+"are handled automatically. In other cases, notably new packages, placing "
+"the uploaded package into the distribution is handled manually. When "
+"uploads are handled manually, the change to the archive may take up to a "
+"month to occur. Please be patient."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:474
+msgid ""
+"In any case, you will receive an email notification indicating that the "
+"package has been added to the archive, which also indicates which bugs will "
+"be closed by the upload. Please examine this notification carefully, "
+"checking if any bugs you meant to close didn't get triggered."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:480
+msgid ""
+"The installation notification also includes information on what section the "
+"package was inserted into. If there is a disparity, you will receive a "
+"separate email notifying you of that. Read on below."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:485
+msgid ""
+"Note that if you upload via queues, the queue daemon software will also send "
+"you a notification by email."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:493
+msgid "Specifying the package section, subsection and priority"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:495
+msgid ""
+"The <filename>debian/control</filename> file's <literal>Section</literal> "
+"and <literal>Priority</literal> fields do not actually specify where the "
+"file will be placed in the archive, nor its priority. In order to retain "
+"the overall integrity of the archive, it is the archive maintainers who have "
+"control over these fields. The values in the <filename>debian/control</"
+"filename> file are actually just hints."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:503
+msgid ""
+"The archive maintainers keep track of the canonical sections and priorities "
+"for packages in the <emphasis>override file</emphasis>. If there is a "
+"disparity between the <emphasis>override file</emphasis> and the package's "
+"fields as indicated in <filename>debian/control</filename>, then you will "
+"receive an email noting the divergence when the package is installed into "
+"the archive. You can either correct your <filename>debian/control</"
+"filename> file for your next upload, or else you may wish to make a change "
+"in the <emphasis>override file</emphasis>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:513
+msgid ""
+"To alter the actual section that a package is put in, you need to first make "
+"sure that the <filename>debian/control</filename> file in your package is "
+"accurate. Next, send an email &email-override; or submit a bug against "
+"<systemitem role=\"package\">ftp.debian.org</systemitem> requesting that the "
+"section or priority for your package be changed from the old section or "
+"priority to the new one. Be sure to explain your reasoning."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:521
+msgid ""
+"For more information about <emphasis>override files</emphasis>, see "
+"<citerefentry> <refentrytitle>dpkg-scanpackages</refentrytitle> "
+"<manvolnum>1</manvolnum> </citerefentry> and <ulink url=\"&url-bts-devel;"
+"#maintincorrect\"></ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:527
+msgid ""
+"Note that the <literal>Section</literal> field describes both the section as "
+"well as the subsection, which are described in <xref linkend=\"archive-"
+"sections\"/> . If the section is main, it should be omitted. The list of "
+"allowable subsections can be found in <ulink url=\"&url-debian-policy;ch-"
+"archive.html#s-subsections\"></ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:536
+msgid "Handling bugs"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:538
+msgid ""
+"Every developer has to be able to work with the Debian <ulink url=\"&url-bts;"
+"\">bug tracking system</ulink>. This includes knowing how to file bug "
+"reports properly (see <xref linkend=\"submit-bug\"/> ), how to update them "
+"and reorder them, and how to process and close them."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:544
+msgid ""
+"The bug tracking system's features are described in the <ulink url=\"&url-"
+"bts-devel;\">BTS documentation for developers</ulink>. This includes "
+"closing bugs, sending followup messages, assigning severities and tags, "
+"marking bugs as forwarded, and other issues."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:550
+msgid ""
+"Operations such as reassigning bugs to other packages, merging separate bug "
+"reports about the same issue, or reopening bugs when they are prematurely "
+"closed, are handled using the so-called control mail server. All of the "
+"commands available on this server are described in the <ulink url=\"&url-bts-"
+"control;\">BTS control server documentation</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:558
+msgid "Monitoring bugs"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:560
+msgid ""
+"If you want to be a good maintainer, you should periodically check the "
+"<ulink url=\"&url-bts;\">Debian bug tracking system (BTS)</ulink> for your "
+"packages. The BTS contains all the open bugs against your packages. You "
+"can check them by browsing this page: <literal>http://&bugs-host;/"
+"<replaceable>yourlogin</replaceable>@debian.org</literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:567
+msgid ""
+"Maintainers interact with the BTS via email addresses at <literal>&bugs-host;"
+"</literal>. Documentation on available commands can be found at <ulink url="
+"\"&url-bts;\"></ulink>, or, if you have installed the <systemitem role="
+"\"package\">doc-debian</systemitem> package, you can look at the local files "
+"&file-bts-docs;."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:574
+msgid ""
+"Some find it useful to get periodic reports on open bugs. You can add a "
+"cron job such as the following if you want to get a weekly email outlining "
+"all the open bugs against your packages:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: pkgs.dbk:579
+#, no-wrap
+msgid ""
+"# ask for weekly reports of bugs in my packages\n"
+"&cron-bug-report;"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:583
+msgid ""
+"Replace <replaceable>address</replaceable> with your official Debian "
+"maintainer address."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:589
+msgid "Responding to bugs"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:591
+msgid ""
+"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., <email>123@&bugs-host;</email>). If you're writing a new mail and you "
+"don't remember the submitter email address, you can use the <email>123-"
+"submitter@&bugs-host;</email> email to contact the submitter <emphasis>and</"
+"emphasis> to record your mail within the bug log (that means you don't need "
+"to send a copy of the mail to <email>123@&bugs-host;</email>)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:600
+msgid ""
+"If you get a bug which mentions FTBFS, this means Fails to build from "
+"source. Porters frequently use this acronym."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:604
+msgid ""
+"Once you've dealt with a bug report (e.g. fixed it), mark it as "
+"<emphasis>done</emphasis> (close it) by sending an explanation message to "
+"<email>123-done@&bugs-host;</email>. If you're fixing a bug by changing and "
+"uploading the package, you can automate bug closing as described in <xref "
+"linkend=\"upload-bugfix\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:611
+msgid ""
+"You should <emphasis>never</emphasis> close bugs via the bug server "
+"<literal>close</literal> command sent to &email-bts-control;. If you do so, "
+"the original submitter will not receive any information about why the bug "
+"was closed."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:619
+msgid "Bug housekeeping"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:621
+msgid ""
+"As a package maintainer, you will often find bugs in other packages or have "
+"bugs reported against your packages which are actually bugs in other "
+"packages. The bug tracking system's features are described in the <ulink "
+"url=\"&url-bts-devel;\">BTS documentation for Debian developers</ulink>. "
+"Operations such as reassigning, merging, and tagging bug reports are "
+"described in the <ulink url=\"&url-bts-control;\">BTS control server "
+"documentation</ulink>. This section contains some guidelines for managing "
+"your own bugs, based on the collective Debian developer experience."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:632
+msgid ""
+"Filing bugs for problems that you find in other packages is one of the civic "
+"obligations of maintainership, see <xref linkend=\"submit-bug\"/> for "
+"details. However, handling the bugs in your own packages is even more "
+"important."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:637
+msgid "Here's a list of steps that you may follow to handle a bug report:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:642
+msgid ""
+"Decide whether the report corresponds to a real bug or not. Sometimes users "
+"are just calling a program in the wrong way because they haven't read the "
+"documentation. If you diagnose this, just close the bug with enough "
+"information to let the user correct their problem (give pointers to the good "
+"documentation and so on). If the same report comes up again and again you "
+"may ask yourself if the documentation is good enough or if the program "
+"shouldn't detect its misuse in order to give an informative error message. "
+"This is an issue that may need to be brought up with the upstream author."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:652
+msgid ""
+"If the bug submitter disagrees with your decision to close the bug, they may "
+"reopen it until you find an agreement on how to handle it. If you don't "
+"find any, you may want to tag the bug <literal>wontfix</literal> to let "
+"people know that the bug exists but that it won't be corrected. If this "
+"situation is unacceptable, you (or the submitter) may want to require a "
+"decision of the technical committee by reassigning the bug to <systemitem "
+"role=\"package\">tech-ctte</systemitem> (you may use the clone command of "
+"the BTS if you wish to keep it reported against your package). Before doing "
+"so, please read the <ulink url=\"&url-tech-ctte;\">recommended procedure</"
+"ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:666
+msgid ""
+"If the bug is real but it's caused by another package, just reassign the bug "
+"to the right package. If you don't know which package it should be "
+"reassigned to, you should ask for help on <link linkend=\"irc-channels"
+"\">IRC</link> or on &email-debian-devel;. Please make sure that the "
+"maintainer(s) of the package the bug is reassigned to know why you "
+"reassigned it."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:674
+msgid ""
+"Sometimes you also have to adjust the severity of the bug so that it matches "
+"our definition of the severity. That's because people tend to inflate the "
+"severity of bugs to make sure their bugs are fixed quickly. Some bugs may "
+"even be dropped to wishlist severity when the requested change is just "
+"cosmetic."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:682
+msgid ""
+"If the bug is real but the same problem has already been reported by someone "
+"else, then the two relevant bug reports should be merged into one using the "
+"merge command of the BTS. In this way, when the bug is fixed, all of the "
+"submitters will be informed of this. (Note, however, that emails sent to "
+"one bug report's submitter won't automatically be sent to the other report's "
+"submitter.) For more details on the technicalities of the merge command and "
+"its relative, the unmerge command, see the BTS control server documentation."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:693
+msgid ""
+"The bug submitter may have forgotten to provide some information, in which "
+"case you have to ask them for the required information. You may use the "
+"<literal>moreinfo</literal> tag to mark the bug as such. Moreover if you "
+"can't reproduce the bug, you tag it <literal>unreproducible</literal>. "
+"Anyone who can reproduce the bug is then invited to provide more information "
+"on how to reproduce it. After a few months, if this information has not "
+"been sent by someone, the bug may be closed."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:704
+msgid ""
+"If the bug is related to the packaging, you just fix it. If you are not "
+"able to fix it yourself, then tag the bug as <literal>help</literal>. You "
+"can also ask for help on &email-debian-devel; or &email-debian-qa;. If it's "
+"an upstream problem, you have to forward it to the upstream author. "
+"Forwarding a bug is not enough, you have to check at each release if the bug "
+"has been fixed or not. If it has, you just close it, otherwise you have to "
+"remind the author about it. If you have the required skills you can prepare "
+"a patch that fixes the bug and send it to the author at the same time. Make "
+"sure to send the patch to the BTS and to tag the bug as <literal>patch</"
+"literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:718
+msgid ""
+"If you have fixed a bug in your local copy, or if a fix has been committed "
+"to the CVS repository, you may tag the bug as <literal>pending</literal> to "
+"let people know that the bug is corrected and that it will be closed with "
+"the next upload (add the <literal>closes:</literal> in the "
+"<filename>changelog</filename>). This is particularly useful if you are "
+"several developers working on the same package."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:728
+msgid ""
+"Once a corrected package is available in the <emphasis>unstable</emphasis> "
+"distribution, you can close the bug. This can be done automatically, read "
+"<xref linkend=\"upload-bugfix\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:737
+msgid "When bugs are closed by new uploads"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:739
+msgid ""
+"As bugs and problems are fixed in your packages, it is your responsibility "
+"as the package maintainer to close these bugs. However, you should not "
+"close a bug until the package which fixes the bug has been accepted into the "
+"Debian archive. Therefore, once you get notification that your updated "
+"package has been installed into the archive, you can and should close the "
+"bug in the BTS. Also, the bug should be closed with the correct version."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:747
+msgid ""
+"However, it's possible to avoid having to manually close bugs after the "
+"upload — just list the fixed bugs in your <filename>debian/changelog</"
+"filename> file, following a certain syntax, and the archive maintenance "
+"software will close the bugs for you. For example:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: pkgs.dbk:753
+#, no-wrap
+msgid ""
+"acme-cannon (3.1415) unstable; urgency=low\n"
+"\n"
+" * Frobbed with options (closes: Bug#98339)\n"
+" * Added safety to prevent operator dismemberment, closes: bug#98765,\n"
+" bug#98713, #98714.\n"
+" * Added man page. Closes: #98725."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:761
+msgid ""
+"Technically speaking, the following Perl regular expression describes how "
+"bug closing changelogs are identified:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: pkgs.dbk:765
+#, no-wrap
+msgid "/closes:\\s*(?:bug)?\\#\\s*\\d+(?:,\\s*(?:bug)?\\#\\s*\\d+)*/ig"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:768
+msgid ""
+"We prefer the <literal>closes: #<replaceable>XXX</replaceable></literal> "
+"syntax, as it is the most concise entry and the easiest to integrate with "
+"the text of the <filename>changelog</filename>. Unless specified different "
+"by the <replaceable>-v</replaceable>-switch to <command>dpkg-buildpackage</"
+"command>, only the bugs closed in the most recent changelog entry are closed "
+"(basically, exactly the bugs mentioned in the changelog-part in the "
+"<filename>.changes</filename> file are closed)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:777
+msgid ""
+"Historically, uploads identified as <link linkend=\"nmu\">Non-maintainer "
+"upload (NMU)</link> were tagged <literal>fixed</literal> instead of being "
+"closed, but that practice was ceased with the advent of version-tracking. "
+"The same applied to the tag <literal>fixed-in-experimental</literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:783
+msgid ""
+"If you happen to mistype a bug number or forget a bug in the changelog "
+"entries, don't hesitate to undo any damage the error caused. To reopen "
+"wrongly closed bugs, send a <literal>reopen <replaceable>XXX</replaceable></"
+"literal> command to the bug tracking system's control address, &email-bts-"
+"control;. To close any remaining bugs that were fixed by your upload, email "
+"the <filename>.changes</filename> file to <email>XXX-done@&bugs-host;</"
+"email>, where <replaceable>XXX</replaceable> is the bug number, and put "
+"Version: YYY and an empty line as the first two lines of the body of the "
+"email, where <replaceable>YYY</replaceable> is the first version where the "
+"bug has been fixed."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:795
+msgid ""
+"Bear in mind that it is not obligatory to close bugs using the changelog as "
+"described above. If you simply want to close bugs that don't have anything "
+"to do with an upload you made, do it by emailing an explanation to "
+"<email>XXX-done@&bugs-host;</email>. Do <emphasis role=\"strong\">not</"
+"emphasis> close bugs in the changelog entry of a version if the changes in "
+"that version of the package don't have any bearing on the bug."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:803
+msgid ""
+"For general information on how to write your changelog entries, see <xref "
+"linkend=\"bpp-debian-changelog\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:809
+msgid "Handling security-related bugs"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:811
+msgid ""
+"Due to their sensitive nature, security-related bugs must be handled "
+"carefully. The Debian Security Team exists to coordinate this activity, "
+"keeping track of outstanding security problems, helping maintainers with "
+"security problems or fixing them themselves, sending security advisories, "
+"and maintaining security.debian.org."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:820
+msgid ""
+"When you become aware of a security-related bug in a Debian package, whether "
+"or not you are the maintainer, collect pertinent information about the "
+"problem, and promptly contact the security team at &email-security-team; as "
+"soon as possible. <emphasis role=\"strong\">DO NOT UPLOAD</emphasis> any "
+"packages for stable; the security team will do that. Useful information "
+"includes, for example:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:830
+msgid ""
+"Which versions of the package are known to be affected by the bug. Check "
+"each version that is present in a supported Debian release, as well as "
+"testing and unstable."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:837
+msgid ""
+"The nature of the fix, if any is available (patches are especially helpful)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:842
+msgid ""
+"Any fixed packages that you have prepared yourself (send only the <literal>."
+"diff.gz</literal> and <literal>.dsc</literal> files and read <xref linkend="
+"\"bug-security-building\"/> first)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:849
+msgid ""
+"Any assistance you can provide to help with testing (exploits, regression "
+"testing, etc.)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:855
+msgid ""
+"Any information needed for the advisory (see <xref linkend=\"bug-security-"
+"advisories\"/> )"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:861
+msgid "Confidentiality"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:863
+msgid ""
+"Unlike most other activities within Debian, information about security "
+"issues must sometimes be kept private for a time. This allows software "
+"distributors to coordinate their disclosure in order to minimize their "
+"users' exposure. Whether this is the case depends on the nature of the "
+"problem and corresponding fix, and whether it is already a matter of public "
+"knowledge."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:870
+msgid "There are several ways developers can learn of a security problem:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:875
+msgid "they notice it on a public forum (mailing list, web site, etc.)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:880
+msgid "someone files a bug report"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:885
+msgid "someone informs them via private email"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:890
+msgid ""
+"In the first two cases, the information is public and it is important to "
+"have a fix as soon as possible. In the last case, however, it might not be "
+"public information. In that case there are a few possible options for "
+"dealing with the problem:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:898
+msgid ""
+"If the security exposure is minor, there is sometimes no need to keep the "
+"problem a secret and a fix should be made and released."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:904
+msgid ""
+"If the problem is severe, it is preferable to share the information with "
+"other vendors and coordinate a release. The security team keeps in contact "
+"with the various organizations and individuals and can take care of that."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:911
+msgid ""
+"In all cases if the person who reports the problem asks that it not be "
+"disclosed, such requests should be honored, with the obvious exception of "
+"informing the security team in order that a fix may be produced for a stable "
+"release of Debian. When sending confidential information to the security "
+"team, be sure to mention this fact."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:918
+msgid ""
+"Please note that if secrecy is needed you may not upload a fix to unstable "
+"(or anywhere else, such as a public CVS repository). It is not sufficient "
+"to obfuscate the details of the change, as the code itself is public, and "
+"can (and will) be examined by the general public."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:924
+msgid ""
+"There are two reasons for releasing information even though secrecy is "
+"requested: the problem has been known for a while, or the problem or exploit "
+"has become public."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:931
+msgid "Security Advisories"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:933
+msgid ""
+"Security advisories are only issued for the current, released stable "
+"distribution, and <emphasis>not</emphasis> for testing or unstable. When "
+"released, advisories are sent to the &email-debian-security-announce; "
+"mailing list and posted on <ulink url=\"&url-debian-security-advisories;"
+"\">the security web page</ulink>. Security advisories are written and "
+"posted by the security team. However they certainly do not mind if a "
+"maintainer can supply some of the information for them, or write part of the "
+"text. Information that should be in an advisory includes:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:946
+msgid "A description of the problem and its scope, including:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para>
+#: pkgs.dbk:951
+msgid "The type of problem (privilege escalation, denial of service, etc.)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para>
+#: pkgs.dbk:956
+msgid "What privileges may be gained, and by whom (if any)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para>
+#: pkgs.dbk:961
+msgid "How it can be exploited"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para>
+#: pkgs.dbk:966
+msgid "Whether it is remotely or locally exploitable"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para>
+#: pkgs.dbk:971
+msgid "How the problem was fixed"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:976
+msgid "This information allows users to assess the threat to their systems."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:981
+msgid "Version numbers of affected packages"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:986
+msgid "Version numbers of fixed packages"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:991
+msgid ""
+"Information on where to obtain the updated packages (usually from the Debian "
+"security archive)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:997
+msgid ""
+"References to upstream advisories, <ulink url=\"http://cve.mitre.org\">CVE</"
+"ulink> identifiers, and any other information useful in cross-referencing "
+"the vulnerability"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:1006
+msgid "Preparing packages to address security issues"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1008
+msgid ""
+"One way that you can assist the security team in their duties is to provide "
+"them with fixed packages suitable for a security advisory for the stable "
+"Debian release."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1013
+msgid ""
+"When an update is made to the stable release, care must be taken to avoid "
+"changing system behavior or introducing new bugs. In order to do this, make "
+"as few changes as possible to fix the bug. Users and administrators rely on "
+"the exact behavior of a release once it is made, so any change that is made "
+"might break someone's system. This is especially true of libraries: make "
+"sure you never change the API or ABI, no matter how small the change."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1021
+msgid ""
+"This means that moving to a new upstream version is not a good solution. "
+"Instead, the relevant changes should be back-ported to the version present "
+"in the current stable Debian release. Generally, upstream maintainers are "
+"willing to help if needed. If not, the Debian security team may be able to "
+"help."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1027
+msgid ""
+"In some cases, it is not possible to back-port a security fix, for example "
+"when large amounts of source code need to be modified or rewritten. If this "
+"happens, it may be necessary to move to a new upstream version. However, "
+"this is only done in extreme situations, and you must always coordinate that "
+"with the security team beforehand."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1034
+msgid ""
+"Related to this is another important guideline: always test your changes. "
+"If you have an exploit available, try it and see if it indeed succeeds on "
+"the unpatched package and fails on the fixed package. Test other, normal "
+"actions as well, as sometimes a security fix can break seemingly unrelated "
+"features in subtle ways."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1041
+msgid ""
+"Do <emphasis role=\"strong\">NOT</emphasis> include any changes in your "
+"package which are not directly related to fixing the vulnerability. These "
+"will only need to be reverted, and this wastes time. If there are other "
+"bugs in your package that you would like to fix, make an upload to proposed-"
+"updates in the usual way, after the security advisory is issued. The "
+"security update mechanism is not a means for introducing changes to your "
+"package which would otherwise be rejected from the stable release, so please "
+"do not attempt to do this."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1051
+msgid ""
+"Review and test your changes as much as possible. Check the differences "
+"from the previous version repeatedly (<command>interdiff</command> from the "
+"<systemitem role=\"package\">patchutils</systemitem> package and "
+"<command>debdiff</command> from <systemitem role=\"package\">devscripts</"
+"systemitem> are useful tools for this, see <xref linkend=\"debdiff\"/> )."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1059
+msgid "Be sure to verify the following items:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1064
+msgid ""
+"Target the right distribution in your <filename>debian/changelog</"
+"filename>. For stable this is <literal>stable-security</literal> and for "
+"testing this is <literal>testing-security</literal>, and for the previous "
+"stable release, this is <literal>oldstable-security</literal>. Do not "
+"target <replaceable>distribution</replaceable>-proposed-updates or "
+"<literal>stable</literal>!"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1074
+msgid "The upload should have urgency=high."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1079
+msgid ""
+"Make descriptive, meaningful changelog entries. Others will rely on them to "
+"determine whether a particular bug was fixed. 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."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1091
+msgid ""
+"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 <literal>dpkg --compare-versions</literal>. Be careful "
+"not to re-use a version number that you have already used for a previous "
+"upload. For <emphasis>testing</emphasis>, there must be a higher version in "
+"<emphasis>unstable</emphasis>. If there is none yet (for example, if "
+"<emphasis>testing</emphasis> and <emphasis>unstable</emphasis> have the same "
+"version) you must upload a new version to unstable first."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1103
+msgid ""
+"Do not make source-only uploads if your package has any binary-all packages "
+"(do not use the <literal>-S</literal> option to <command>dpkg-buildpackage</"
+"command>). The <command>buildd</command> infrastructure will not build "
+"those. This point applies to normal package uploads as well."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1112
+msgid ""
+"Unless the upstream source has been uploaded to security.debian.org before "
+"(by a previous security update), build the upload with full upstream source "
+"(<literal>dpkg-buildpackage -sa</literal>). If there has been a previous "
+"upload to security.debian.org with the same upstream version, you may upload "
+"without upstream source (<literal>dpkg-buildpackage -sd</literal>)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1121
+msgid ""
+"Be sure to use the exact same <filename>*.orig.tar.gz</filename> as used in "
+"the normal archive, otherwise it is not possible to move the security fix "
+"into the main archives later."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1128
+msgid ""
+"Build the package on a clean system which only has packages installed from "
+"the distribution you are building for. If you do not have such a system "
+"yourself, you can use a debian.org machine (see <xref linkend=\"server-"
+"machines\"/> ) or setup a chroot (see <xref linkend=\"pbuilder\"/> and <xref "
+"linkend=\"debootstrap\"/> )."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:1139
+msgid "Uploading the fixed package"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1141
+msgid ""
+"Do <emphasis role=\"strong\">NOT</emphasis> 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."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1148
+msgid ""
+"Do <emphasis role=\"strong\">NOT</emphasis> 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 is "
+"already installed into the archive, the security update will be rejected by "
+"the archive system. That way, the stable distribution will end up without a "
+"security update for this package instead."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1157
+msgid ""
+"Once you have created and tested the new package and it has been approved by "
+"the security team, it needs to be uploaded so that it can be installed in "
+"the archives. For security uploads, the place to upload to is "
+"<literal>ftp://security-master.debian.org/pub/SecurityUploadQueue/</"
+"literal> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1163
+msgid ""
+"Once an upload to the security queue has been accepted, the package will "
+"automatically be rebuilt for all architectures and stored for verification "
+"by the security team."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1168
+msgid ""
+"Uploads which are waiting for acceptance or verification are only accessible "
+"by the security team. This is necessary since there might be fixes for "
+"security problems that cannot be disclosed yet."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1173
+msgid ""
+"If a member of the security team accepts a package, it will be installed on "
+"security.debian.org as well as proposed for the proper "
+"<replaceable>distribution</replaceable>-proposed-updates on ftp-master."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:1184
+msgid "Moving, removing, renaming, adopting, and orphaning packages"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:1186
+msgid ""
+"Some archive manipulation operations are not automated in the Debian upload "
+"process. These procedures should be manually followed by maintainers. This "
+"chapter gives guidelines on what to do in these cases."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1191
+msgid "Moving packages"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para><footnote>
+#: pkgs.dbk:1193
+msgid ""
+"Sometimes a package will change its section. For instance, a package from "
+"the `non-free' section might be GPL'd in a later version, in which case the "
+"package should be moved to `main' or `contrib'.<footnote>"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para><footnote><para>
+#: pkgs.dbk:1195
+msgid ""
+"See the <ulink url=\"&url-debian-policy;\">Debian Policy Manual</ulink> for "
+"guidelines on what section a package belongs in."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1200
+msgid ""
+"If you need to change the section for one of your packages, change the "
+"package control information to place the package in the desired section, and "
+"re-upload the package (see the <ulink url=\"&url-debian-policy;\">Debian "
+"Policy Manual</ulink> for details). You must ensure that you include the "
+"<filename>.orig.tar.gz</filename> in your upload (even if you are not "
+"uploading a new upstream version), or it will not appear in the new section "
+"together with the rest of the package. If your new section is valid, it "
+"will be moved automatically. If it does not, then contact the ftpmasters in "
+"order to understand what happened."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1212
+msgid ""
+"If, on the other hand, you need to change the <emphasis>subsection</"
+"emphasis> of one of your packages (e.g., ``devel'', ``admin''), the "
+"procedure is slightly different. Correct the subsection as found in the "
+"control file of the package, and re-upload that. Also, you'll need to get "
+"the override file updated, as described in <xref linkend=\"override-file\"/"
+"> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1221
+msgid "Removing packages"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1223
+msgid ""
+"If for some reason you want to completely remove a package (say, if it is an "
+"old compatibility library which is no longer required), you need to file a "
+"bug against <literal>ftp.debian.org</literal> asking that the package be "
+"removed; as all bugs, this bug should normally have normal severity. Make "
+"sure you indicate which distribution the package should be removed from. "
+"Normally, you can only have packages removed from <emphasis>unstable</"
+"emphasis> and <emphasis>experimental</emphasis>. Packages are not removed "
+"from <emphasis>testing</emphasis> directly. Rather, they will be removed "
+"automatically after the package has been removed from <emphasis>unstable</"
+"emphasis> and no package in <emphasis>testing</emphasis> depends on it."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1236
+msgid ""
+"There is one exception when an explicit removal request is not necessary: If "
+"a (source or binary) package is an orphan, it will be removed semi-"
+"automatically. For a binary-package, this means if there is no longer any "
+"source package producing this binary package; if the binary package is just "
+"no longer produced on some architectures, a removal request is still "
+"necessary. For a source-package, this means that all binary packages it "
+"refers to have been taken over by another source package."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1245
+msgid ""
+"In your removal request, you have to detail the reasons justifying the "
+"request. This is to avoid unwanted removals and to keep a trace of why a "
+"package has been removed. For example, you can provide the name of the "
+"package that supersedes the one to be removed."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1251
+msgid ""
+"Usually you only ask for the removal of a package maintained by yourself. "
+"If you want to remove another package, you have to get the approval of its "
+"maintainer."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1256
+msgid ""
+"Further information relating to these and other package removal related "
+"topics may be found at <ulink url=\"http://wiki.debian.org/ftpmaster_Removals"
+"\"></ulink> and <ulink url=\"&url-debian-qa;howto-remove.html\"></ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1261
+msgid ""
+"If in doubt concerning whether a package is disposable, email &email-debian-"
+"devel; asking for opinions. Also of interest is the <command>apt-cache</"
+"command> program from the <systemitem role=\"package\">apt</systemitem> "
+"package. When invoked as <literal>apt-cache showpkg <replaceable>package</"
+"replaceable></literal>, the program will show details for "
+"<replaceable>package</replaceable>, including reverse depends. Other useful "
+"programs include <literal>apt-cache rdepends</literal>, <command>apt-"
+"rdepends</command> and <command>grep-dctrl</command>. Removal of orphaned "
+"packages is discussed on &email-debian-qa;."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1272
+msgid ""
+"Once the package has been removed, the package's bugs should be handled. "
+"They should either be reassigned to another package in the case where the "
+"actual code has evolved into another package (e.g. <literal>libfoo12</"
+"literal> was removed because <literal>libfoo13</literal> supersedes it) or "
+"closed if the software is simply no longer part of Debian."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:1279
+msgid "Removing packages from <filename>Incoming</filename>"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1281
+msgid ""
+"In the past, it was possible to remove packages from <filename>incoming</"
+"filename>. However, with the introduction of the new incoming system, this "
+"is no longer possible. Instead, you have to upload a new revision of your "
+"package with a higher version than the package you want to replace. Both "
+"versions will be installed in the archive but only the higher version will "
+"actually be available in <emphasis>unstable</emphasis> since the previous "
+"version will immediately be replaced by the higher. However, if you do "
+"proper testing of your packages, the need to replace a package should not "
+"occur too often anyway."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1296
+msgid "Replacing or renaming packages"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1298
+msgid ""
+"When you make a mistake naming your package, you should follow a two-step "
+"process to rename it. First, set your <filename>debian/control</filename> "
+"file to replace and conflict with the obsolete name of the package (see the "
+"<ulink url=\"&url-debian-policy;\">Debian Policy Manual</ulink> for "
+"details). Once you've uploaded the package and the package has moved into "
+"the archive, file a bug against <literal>ftp.debian.org</literal> asking to "
+"remove the package with the obsolete name. Do not forget to properly "
+"reassign the package's bugs at the same time."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1308
+msgid ""
+"At other times, you may make a mistake in constructing your package and wish "
+"to replace it. The only way to do this is to increase the version number "
+"and upload a new version. The old version will be expired in the usual "
+"manner. Note that this applies to each part of your package, including the "
+"sources: if you wish to replace the upstream source tarball of your package, "
+"you will need to upload it with a different version. An easy possibility is "
+"to replace <filename>foo_1.00.orig.tar.gz</filename> with <filename>foo_1.00"
+"+0.orig.tar.gz</filename>. This restriction gives each file on the ftp site "
+"a unique name, which helps to ensure consistency across the mirror network."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1322
+msgid "Orphaning a package"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1324
+msgid ""
+"If you can no longer maintain a package, you need to inform others, and see "
+"that the package is marked as orphaned. You should set the package "
+"maintainer to <literal>Debian QA Group &orphan-address;</literal> and submit "
+"a bug report against the pseudo package <systemitem role=\"package\">wnpp</"
+"systemitem>. The bug report should be titled <literal>O: "
+"<replaceable>package</replaceable> -- <replaceable>short description</"
+"replaceable></literal> indicating that the package is now orphaned. The "
+"severity of the bug should be set to <emphasis>normal</emphasis>; if the "
+"package has a priority of standard or higher, it should be set to "
+"important. If you feel it's necessary, send a copy to &email-debian-devel; "
+"by putting the address in the X-Debbugs-CC: header of the message (no, don't "
+"use CC:, because that way the message's subject won't indicate the bug "
+"number)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1339
+msgid ""
+"If you just intend to give the package away, but you can keep maintainership "
+"for the moment, then you should instead submit a bug against <systemitem "
+"role=\"package\">wnpp</systemitem> and title it <literal>RFA: "
+"<replaceable>package</replaceable> -- <replaceable>short description</"
+"replaceable></literal>. <literal>RFA</literal> stands for <emphasis>Request "
+"For Adoption</emphasis>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1347
+msgid ""
+"More information is on the <ulink url=\"&url-wnpp;\">WNPP web pages</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1353
+msgid "Adopting a package"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1355
+msgid ""
+"A list of packages in need of a new maintainer is available in the <ulink "
+"url=\"&url-wnpp;\">Work-Needing and Prospective Packages list (WNPP)</"
+"ulink>. If you wish to take over maintenance of any of the packages listed "
+"in the WNPP, please take a look at the aforementioned page for information "
+"and procedures."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1362
+msgid ""
+"It is not OK to simply take over a package that you feel is neglected — that "
+"would be package hijacking. You can, of course, contact the current "
+"maintainer and ask them if you may take over the package. If you have "
+"reason to believe a maintainer has gone AWOL (absent without leave), see "
+"<xref linkend=\"mia-qa\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1368
+msgid ""
+"Generally, you may not take over the package without the assent of the "
+"current maintainer. Even if they ignore you, that is still not grounds to "
+"take over a package. Complaints about maintainers should be brought up on "
+"the developers' mailing list. If the discussion doesn't end with a positive "
+"conclusion, and the issue is of a technical nature, consider bringing it to "
+"the attention of the technical committee (see the <ulink url=\"&url-tech-"
+"ctte;\">technical committee web page</ulink> for more information)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1378
+msgid ""
+"If you take over an old package, you probably want to be listed as the "
+"package's official maintainer in the bug system. This will happen "
+"automatically once you upload a new version with an updated "
+"<literal>Maintainer:</literal> field, although it can take a few hours after "
+"the upload is done. If you do not expect to upload a new version for a "
+"while, you can use <xref linkend=\"pkg-tracking-system\"/> to get the bug "
+"reports. However, make sure that the old maintainer has no problem with the "
+"fact that they will continue to receive the bugs during that time."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:1392
+msgid "Porting and being ported"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:1394
+msgid ""
+"Debian supports an ever-increasing number of architectures. Even if you are "
+"not a porter, and you don't use any architecture but one, it is part of your "
+"duty as a maintainer to be aware of issues of portability. Therefore, even "
+"if you are not a porter, you should read most of this chapter."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:1400
+msgid ""
+"Porting is the act of building Debian packages for architectures that are "
+"different from the original architecture of the package maintainer's binary "
+"package. It is a unique and essential activity. In fact, porters do most "
+"of the actual compiling of Debian packages. For instance, for a single "
+"<emphasis>i386</emphasis> binary package, there must be a recompile for each "
+"architecture, which amounts to &number-of-arches; more builds."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1408
+msgid "Being kind to porters"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1410
+msgid ""
+"Porters have a difficult and unique task, since they are required to deal "
+"with a large volume of packages. Ideally, every source package should build "
+"right out of the box. Unfortunately, this is often not the case. This "
+"section contains a checklist of ``gotchas'' often committed by Debian "
+"maintainers — common problems which often stymie porters, and make their "
+"jobs unnecessarily difficult."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1418
+msgid ""
+"The first and most important thing is to respond quickly to bug or issues "
+"raised by porters. Please treat porters with courtesy, as if they were in "
+"fact co-maintainers of your package (which, in a way, they are). Please be "
+"tolerant of succinct or even unclear bug reports; do your best to hunt down "
+"whatever the problem is."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1425
+msgid ""
+"By far, most of the problems encountered by porters are caused by "
+"<emphasis>packaging bugs</emphasis> in the source packages. Here is a "
+"checklist of things you should check or be aware of."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:1432
+msgid ""
+"Make sure that your <literal>Build-Depends</literal> and <literal>Build-"
+"Depends-Indep</literal> settings in <filename>debian/control</filename> are "
+"set properly. The best way to validate this is to use the <systemitem role="
+"\"package\">debootstrap</systemitem> package to create an unstable chroot "
+"environment (see <xref linkend=\"debootstrap\"/> ). Within that chrooted "
+"environment, install the <systemitem role=\"package\">build-essential</"
+"systemitem> package and any package dependencies mentioned in <literal>Build-"
+"Depends</literal> and/or <literal>Build-Depends-Indep</literal>. Finally, "
+"try building your package within that chrooted environment. These steps can "
+"be automated by the use of the <command>pbuilder</command> program which is "
+"provided by the package of the same name (see <xref linkend=\"pbuilder\"/> )."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:1446
+msgid ""
+"If you can't set up a proper chroot, <command>dpkg-depcheck</command> may be "
+"of assistance (see <xref linkend=\"dpkg-depcheck\"/> )."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:1450
+msgid ""
+"See the <ulink url=\"&url-debian-policy;\">Debian Policy Manual</ulink> for "
+"instructions on setting build dependencies."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:1456
+msgid ""
+"Don't set architecture to a value other than ``all'' or ``any'' unless you "
+"really mean it. In too many cases, maintainers don't follow the "
+"instructions in the <ulink url=\"&url-debian-policy;\">Debian Policy Manual</"
+"ulink>. Setting your architecture to ``i386'' is usually incorrect."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:1464
+msgid ""
+"Make sure your source package is correct. Do <literal>dpkg-source -x "
+"<replaceable>package</replaceable>.dsc</literal> to make sure your source "
+"package unpacks properly. Then, in there, try building your package from "
+"scratch with <command>dpkg-buildpackage</command>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:1472
+msgid ""
+"Make sure you don't ship your source package with the <filename>debian/"
+"files</filename> or <filename>debian/substvars</filename> files. They "
+"should be removed by the `clean' target of <filename>debian/rules</filename>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:1480
+msgid ""
+"Make sure you don't rely on locally installed or hacked configurations or "
+"programs. For instance, you should never be calling programs in <filename>/"
+"usr/local/bin</filename> or the like. Try not to rely on programs being "
+"setup in a special way. Try building your package on another machine, even "
+"if it's the same architecture."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:1489
+msgid ""
+"Don't depend on the package you're building being installed already (a sub-"
+"case of the above issue)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:1495
+msgid ""
+"Don't rely on the compiler being a certain version, if possible. If not, "
+"then make sure your build dependencies reflect the restrictions, although "
+"you are probably asking for trouble, since different architectures sometimes "
+"standardize on different compilers."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:1503
+msgid ""
+"Make sure your debian/rules contains separate ``binary-arch'' and ``binary-"
+"indep'' targets, as the Debian Policy Manual requires. Make sure that both "
+"targets work independently, that is, that you can call the target without "
+"having called the other before. To test this, try to run <literal>dpkg-"
+"buildpackage -B</literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1514
+msgid "Guidelines for porter uploads"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1516
+msgid ""
+"If the package builds out of the box for the architecture to be ported to, "
+"you are in luck and your job is easy. This section applies to that case; it "
+"describes how to build and upload your binary package so that it is properly "
+"installed into the archive. If you do have to patch the package in order to "
+"get it to compile for the other architecture, you are actually doing a "
+"source NMU, so consult <xref linkend=\"nmu-guidelines\"/> instead."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1524
+msgid ""
+"For a porter upload, no changes are being made to the source. You do not "
+"need to touch any of the files in the source package. This includes "
+"<filename>debian/changelog</filename>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1529
+msgid ""
+"The way to invoke <command>dpkg-buildpackage</command> is as <literal>dpkg-"
+"buildpackage -B -m<replaceable>porter-email</replaceable></literal>. Of "
+"course, set <replaceable>porter-email</replaceable> to your email address. "
+"This will do a binary-only build of only the architecture-dependent portions "
+"of the package, using the `binary-arch' target in <filename>debian/rules</"
+"filename>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1537
+msgid ""
+"If you are working on a Debian machine for your porting efforts and you need "
+"to sign your upload locally for its acceptance in the archive, you can run "
+"<command>debsign</command> on your <filename>.changes</filename> file to "
+"have it signed conveniently, or use the remote signing mode of <command>dpkg-"
+"sig</command>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:1544
+msgid "Recompilation or binary-only NMU"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1546
+msgid ""
+"Sometimes the initial porter upload is problematic because the environment "
+"in which the package was built was not good enough (outdated or obsolete "
+"library, bad compiler, ...). Then you may just need to recompile it in an "
+"updated environment. However, you have to bump the version number in this "
+"case, so that the old bad package can be replaced in the Debian archive "
+"(<command>katie</command> refuses to install new packages if they don't have "
+"a version number greater than the currently available one)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1555
+msgid ""
+"You have to make sure that your binary-only NMU doesn't render the package "
+"uninstallable. This could happen when a source package generates arch-"
+"dependent and arch-independent packages that depend on each other via "
+"$(Source-Version)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1561
+msgid ""
+"Despite the required modification of the changelog, these are called binary-"
+"only NMUs — there is no need in this case to trigger all other architectures "
+"to consider themselves out of date or requiring recompilation."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1566
+msgid ""
+"Such recompilations require special ``magic'' version numbering, so that the "
+"archive maintenance tools recognize that, even though there is a new Debian "
+"version, there is no corresponding source update. If you get this wrong, "
+"the archive maintainers will reject your upload (due to lack of "
+"corresponding source code)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para><footnote>
+#: pkgs.dbk:1573
+msgid ""
+"The ``magic'' for a recompilation-only NMU is triggered by using a suffix "
+"appended to the package version number, following the form b<number>. "
+"For instance, if the latest version you are recompiling against was version "
+"``2.9-3'', your NMU should carry a version of ``2.9-3+b1''. If the latest "
+"version was ``3.4+b1'' (i.e, a native package with a previous recompilation "
+"NMU), your NMU should have a version number of ``3.4+b2''. <footnote>"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para><footnote><para>
+#: pkgs.dbk:1578
+msgid ""
+"In the past, such NMUs used the third-level number on the Debian part of the "
+"revision to denote their recompilation-only status; however, this syntax was "
+"ambiguous with native packages and did not allow proper ordering of "
+"recompile-only NMUs, source NMUs, and security NMUs on the same package, and "
+"has therefore been abandoned in favor of this new syntax."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1586
+msgid ""
+"Similar to initial porter uploads, the correct way of invoking <command>dpkg-"
+"buildpackage</command> is <literal>dpkg-buildpackage -B</literal> to only "
+"build the architecture-dependent parts of the package."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:1593
+msgid "When to do a source NMU if you are a porter"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1595
+msgid ""
+"Porters doing a source NMU generally follow the guidelines found in <xref "
+"linkend=\"nmu\"/> , just like non-porters. However, it is expected that the "
+"wait cycle for a porter's source NMU is smaller than for a non-porter, since "
+"porters have to cope with a large quantity of packages. Again, the "
+"situation varies depending on the distribution they are uploading to. It "
+"also varies whether the architecture is a candidate for inclusion into the "
+"next stable release; the release managers decide and announce which "
+"architectures are candidates."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1604
+msgid ""
+"If you are a porter doing an NMU for `unstable', the above guidelines for "
+"porting should be followed, with two variations. Firstly, the acceptable "
+"waiting period — the time between when the bug is submitted to the BTS and "
+"when it is OK to do an NMU — is seven days for porters working on the "
+"unstable distribution. This period can be shortened if the problem is "
+"critical and imposes hardship on the porting effort, at the discretion of "
+"the porter group. (Remember, none of this is Policy, just mutually agreed "
+"upon guidelines.) For uploads to stable or testing, please coordinate with "
+"the appropriate release team first."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1615
+msgid ""
+"Secondly, porters doing source NMUs should make sure that the bug they "
+"submit to the BTS should be of severity `serious' or greater. This ensures "
+"that a single source package can be used to compile every supported Debian "
+"architecture by release time. It is very important that we have one version "
+"of the binary and source package for all architecture in order to comply "
+"with many licenses."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1623
+msgid ""
+"Porters should try to avoid patches which simply kludge around bugs in the "
+"current version of the compile environment, kernel, or libc. Sometimes such "
+"kludges can't be helped. If you have to kludge around compiler bugs and the "
+"like, make sure you <literal>#ifdef</literal> your work properly; also, "
+"document your kludge so that people know to remove it once the external "
+"problems have been fixed."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1631
+msgid ""
+"Porters may also have an unofficial location where they can put the results "
+"of their work during the waiting period. This helps others running the port "
+"have the benefit of the porter's work, even during the waiting period. Of "
+"course, such locations have no official blessing or status, so buyer beware."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1641
+msgid "Porting infrastructure and automation"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1643
+msgid ""
+"There is infrastructure and several tools to help automate package porting. "
+"This section contains a brief overview of this automation and porting to "
+"these tools; see the package documentation or references for full "
+"information."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:1648
+msgid "Mailing lists and web pages"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1650
+msgid ""
+"Web pages containing the status of each port can be found at <ulink url="
+"\"&url-debian-ports;\"></ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1654
+msgid ""
+"Each port of Debian has a mailing list. The list of porting mailing lists "
+"can be found at <ulink url=\"&url-debian-port-lists;\"></ulink>. These "
+"lists are used to coordinate porters, and to connect the users of a given "
+"port with the porters."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:1662
+msgid "Porter tools"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1664
+msgid ""
+"Descriptions of several porting tools can be found in <xref linkend=\"tools-"
+"porting\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1672
+msgid ""
+"The <systemitem role=\"package\">buildd</systemitem> system is used as a "
+"distributed, client-server build distribution system. It is usually used in "
+"conjunction with <emphasis>auto-builders</emphasis>, which are ``slave'' "
+"hosts which simply check out and attempt to auto-build packages which need "
+"to be ported. There is also an email interface to the system, which allows "
+"porters to ``check out'' a source package (usually one which cannot yet be "
+"auto-built) and work on it."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1681
+msgid ""
+"<systemitem role=\"package\">buildd</systemitem> is not yet available as a "
+"package; however, most porting efforts are either using it currently or "
+"planning to use it in the near future. The actual automated builder is "
+"packaged as <systemitem role=\"package\">sbuild</systemitem>, see its "
+"description in <xref linkend=\"sbuild\"/> . The complete <systemitem role="
+"\"package\">buildd</systemitem> system also collects a number of as yet "
+"unpackaged components which are currently very useful and in use "
+"continually, such as <command>andrea</command> and <command>wanna-build</"
+"command>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1691
+msgid ""
+"Some of the data produced by <systemitem role=\"package\">buildd</"
+"systemitem> which is generally useful to porters is available on the web at "
+"<ulink url=\"&url-buildd;\"></ulink>. This data includes nightly updated "
+"information from <command>andrea</command> (source dependencies) and "
+"<systemitem role=\"package\">quinn-diff</systemitem> (packages needing "
+"recompilation)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1699
+msgid ""
+"We are quite proud of this system, since it has so many possible uses. "
+"Independent development groups can use the system for different sub-flavors "
+"of Debian, which may or may not really be of general interest (for instance, "
+"a flavor of Debian built with <command>gcc</command> bounds checking). It "
+"will also enable Debian to recompile entire distributions quickly."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1706
+msgid ""
+"The buildds admins of each arch can be contacted at the mail address "
+"$arch@buildd.debian.org."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1714
+msgid "When your package is <emphasis>not</emphasis> portable"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1716
+msgid ""
+"Some packages still have issues with building and/or working on some of the "
+"architectures supported by Debian, and cannot be ported at all, or not "
+"within a reasonable amount of time. An example is a package that is SVGA-"
+"specific (only i386), or uses other hardware-specific features not supported "
+"on all architectures."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1723
+msgid ""
+"In order to prevent broken packages from being uploaded to the archive, and "
+"wasting buildd time, you need to do a few things:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1729
+msgid ""
+"First, make sure your package <emphasis>does</emphasis> fail to build on "
+"architectures that it cannot support. There are a few ways to achieve "
+"this. The preferred way is to have a small testsuite during build time that "
+"will test the functionality, and fail if it doesn't work. This is a good "
+"idea anyway, as this will prevent (some) broken uploads on all "
+"architectures, and also will allow the package to build as soon as the "
+"required functionality is available."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1737
+msgid ""
+"Additionally, if you believe the list of supported architectures is pretty "
+"constant, you should change 'any' to a list of supported architectures in "
+"debian/control. This way, the build will fail also, and indicate this to a "
+"human reader without actually trying."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1745
+msgid ""
+"In order to prevent autobuilders from needlessly trying to build your "
+"package, it must be included in <filename>packages-arch-specific</filename>, "
+"a list used by the <command>wanna-build</command> script. The current "
+"version is available as <ulink url=\"&url-cvsweb;srcdep/Packages-arch-"
+"specific?cvsroot=dak\"></ulink>; please see the top of the file for whom to "
+"contact for changes."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1755
+msgid ""
+"Please note that it is insufficient to only add your package to Packages-"
+"arch-specific without making it fail to build on unsupported architectures: "
+"A porter or any other person trying to build your package might accidently "
+"upload it without noticing it doesn't work. If in the past some binary "
+"packages were uploaded on unsupported architectures, request their removal "
+"by filing a bug against <systemitem role=\"package\">ftp.debian.org</"
+"systemitem>"
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:1768
+msgid "Non-Maintainer Uploads (NMUs)"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:1770
+msgid ""
+"Under certain circumstances it is necessary for someone other than the "
+"official package maintainer to make a release of a package. This is called "
+"a non-maintainer upload, or NMU."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:1775
+msgid ""
+"This section handles only source NMUs, i.e. NMUs which upload a new version "
+"of the package. For binary-only NMUs by porters or QA members, please see "
+"<xref linkend=\"binary-only-nmu\"/> . If a buildd builds and uploads a "
+"package, that too is strictly speaking a binary NMU. See <xref linkend="
+"\"buildd\"/> for some more information."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:1782
+msgid ""
+"The main reason why NMUs are done is when a developer needs to fix another "
+"developer's package in order to address serious problems or crippling bugs "
+"or when the package maintainer is unable to release a fix in a timely "
+"fashion."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:1787
+msgid ""
+"First and foremost, it is critical that NMU patches to source should be as "
+"non-disruptive as possible. Do not do housekeeping tasks, do not change the "
+"name of modules or files, do not move directories; in general, do not fix "
+"things which are not broken. Keep the patch as small as possible. If "
+"things bother you aesthetically, talk to the Debian maintainer, talk to the "
+"upstream maintainer, or submit a bug. However, aesthetic changes must "
+"<emphasis>not</emphasis> be made in a non-maintainer upload."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:1796
+msgid ""
+"And please remember the Hippocratic Oath: Above all, do no harm. It is "
+"better to leave a package with an open grave bug than applying a non-"
+"functional patch, or one that hides the bug instead of resolving it."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1801
+msgid "How to do a NMU"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1803
+msgid ""
+"NMUs which fix important, serious or higher severity bugs are encouraged and "
+"accepted. You should endeavor to reach the current maintainer of the "
+"package; they might be just about to upload a fix for the problem, or have a "
+"better solution."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1809
+msgid ""
+"NMUs should be made to assist a package's maintainer in resolving bugs. "
+"Maintainers should be thankful for that help, and NMUers should respect the "
+"decisions of maintainers, and try to personally help the maintainer by their "
+"work."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1815
+msgid ""
+"A NMU should follow all conventions, written down in this section. For an "
+"upload to testing or unstable, this order of steps is recommended:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1821
+msgid ""
+"Make sure that the package's bugs that the NMU is meant to address are all "
+"filed in the Debian Bug Tracking System (BTS). If they are not, submit them "
+"immediately."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1828
+msgid ""
+"Wait a few days for the response from the maintainer. If you don't get any "
+"response, you may want to help them by sending the patch that fixes the "
+"bug. Don't forget to tag the bug with the patch keyword."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1835
+msgid ""
+"Wait a few more days. If you still haven't got an answer from the "
+"maintainer, send them a mail announcing your intent to NMU the package. "
+"Prepare an NMU as described in this section, and test it carefully on your "
+"machine (cf. <xref linkend=\"sanitycheck\"/> ). Double check that your "
+"patch doesn't have any unexpected side effects. Make sure your patch is as "
+"small and as non-disruptive as it can be."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1845
+msgid ""
+"Upload your package to incoming in <filename>DELAYED/7-day</filename> (cf. "
+"<xref linkend=\"delayed-incoming\"/> ), send the final patch to the "
+"maintainer via the BTS, and explain to them that they have 7 days to react "
+"if they want to cancel the NMU."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1853
+msgid ""
+"Follow what happens, you're responsible for any bug that you introduced with "
+"your NMU. You should probably use <xref linkend=\"pkg-tracking-system\"/> "
+"(PTS) to stay informed of the state of the package after your NMU."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1860
+msgid ""
+"At times, the release manager or an organized group of developers can "
+"announce a certain period of time in which the NMU rules are relaxed. This "
+"usually involves shortening the period during which one is to wait before "
+"uploading the fixes, and shortening the DELAYED period. It is important to "
+"notice that even in these so-called bug squashing party times, the NMU'er "
+"has to file bugs and contact the developer first, and act later. Please see "
+"<xref linkend=\"qa-bsp\"/> for details."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1869
+msgid ""
+"For the testing distribution, the rules may be changed by the release "
+"managers. Please take additional care, and acknowledge that the usual way "
+"for a package to enter testing is through unstable."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1874
+msgid ""
+"For the stable distribution, please take extra care. Of course, the release "
+"managers may also change the rules here. Please verify before you upload "
+"that all your changes are OK for inclusion into the next stable release by "
+"the release manager."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1880
+msgid ""
+"When a security bug is detected, the security team may do an NMU, using "
+"their own rules. Please refer to <xref linkend=\"bug-security\"/> for more "
+"information."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1885
+msgid ""
+"For the differences for Porters NMUs, please see <xref linkend=\"source-nmu-"
+"when-porter\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1889
+msgid ""
+"Of course, it is always possible to agree on special rules with a maintainer "
+"(like the maintainer asking please upload this fix directly for me, and no "
+"diff required)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1896
+msgid "NMU version numbering"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1898
+msgid ""
+"Whenever you have made a change to a package, no matter how trivial, the "
+"version number needs to change. This enables our packing system to function."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1902
+msgid ""
+"If you are doing a non-maintainer upload (NMU), you should add a new minor "
+"version number to the <replaceable>debian-revision</replaceable> part of the "
+"version number (the portion after the last hyphen). This extra minor number "
+"will start at `1'. For example, consider the package `foo', which is at "
+"version 1.1-3. In the archive, the source package control file would be "
+"<filename>foo_1.1-3.dsc</filename>. The upstream version is `1.1' and the "
+"Debian revision is `3'. The next NMU would add a new minor number `.1' to "
+"the Debian revision; the new source control file would be <filename>foo_1.1-"
+"3.1.dsc</filename>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1913
+msgid ""
+"The Debian revision minor number is needed to avoid stealing one of the "
+"package maintainer's version numbers, which might disrupt their work. It "
+"also has the benefit of making it visually clear that a package in the "
+"archive was not made by the official maintainer."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1919
+msgid ""
+"If there is no <replaceable>debian-revision</replaceable> component in the "
+"version number then one should be created, starting at `0.1' (but in case of "
+"a debian native package still upload it as native package). If it is "
+"absolutely necessary for someone other than the usual maintainer to make a "
+"release based on a new upstream version then the person making the release "
+"should start with the <replaceable>debian-revision</replaceable> value "
+"`0.1'. The usual maintainer of a package should start their "
+"<replaceable>debian-revision</replaceable> numbering at `1'."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1929
+msgid ""
+"If you upload a package to testing or stable, sometimes, you need to fork "
+"the version number tree. For this, version numbers like 1.1-3sarge0.1 could "
+"be used."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1936
+msgid "Source NMUs must have a new changelog entry"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1938
+msgid ""
+"Anyone who is doing a source NMU must create a changelog entry, describing "
+"which bugs are fixed by the NMU, and generally why the NMU was required and "
+"what it fixed. The changelog entry will have the email address of the "
+"person who uploaded it in the log entry and the NMU version number in it."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1944
+msgid "By convention, source NMU changelog entries start with the line"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: pkgs.dbk:1947
+#, no-wrap
+msgid "* Non-maintainer upload"
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1952
+msgid "Source NMUs and the Bug Tracking System"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1954
+msgid ""
+"Maintainers other than the official package maintainer should make as few "
+"changes to the package as possible, and they should always send a patch as a "
+"unified context diff (<literal>diff -u</literal>) detailing their changes to "
+"the Bug Tracking System."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1960
+msgid ""
+"What if you are simply recompiling the package? If you just need to "
+"recompile it for a single architecture, then you may do a binary-only NMU as "
+"described in <xref linkend=\"binary-only-nmu\"/> which doesn't require any "
+"patch to be sent. If you want the package to be recompiled for all "
+"architectures, then you do a source NMU as usual and you will have to send a "
+"patch."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1967
+msgid ""
+"Bugs fixed by source NMUs used to be tagged fixed instead of closed, but "
+"since version tracking is in place, such bugs are now also closed with the "
+"NMU version."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1972
+msgid ""
+"Also, after doing an NMU, you have to send the information to the existing "
+"bugs that are fixed by your NMU, including the unified diff. Historically, "
+"it was custom to open a new bug and include a patch showing all the changes "
+"you have made. The normal maintainer will either apply the patch or employ "
+"an alternate method of fixing the problem. Sometimes bugs are fixed "
+"independently upstream, which is another good reason to back out an NMU's "
+"patch. If the maintainer decides not to apply the NMU's patch but to "
+"release a new version, the maintainer needs to ensure that the new upstream "
+"version really fixes each problem that was fixed in the non-maintainer "
+"release."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1983
+msgid ""
+"In addition, the normal maintainer should <emphasis>always</emphasis> retain "
+"the entry in the changelog file documenting the non-maintainer upload -- and "
+"of course, also keep the changes. If you revert some of the changes, please "
+"reopen the relevant bug reports."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1991
+msgid "Building source NMUs"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1993
+msgid ""
+"Source NMU packages are built normally. Pick a distribution using the same "
+"rules as found in <xref linkend=\"distribution\"/> , follow the other "
+"instructions in <xref linkend=\"upload\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1998
+msgid ""
+"Make sure you do <emphasis>not</emphasis> change the value of the maintainer "
+"in the <filename>debian/control</filename> file. Your name as given in the "
+"NMU entry of the <filename>debian/changelog</filename> file will be used for "
+"signing the changes file."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:2006
+msgid "Acknowledging an NMU"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2008
+msgid ""
+"If one of your packages has been NMU'ed, you have to incorporate the changes "
+"in your copy of the sources. This is easy, you just have to apply the patch "
+"that has been sent to you. Once this is done, you have to close the bugs "
+"that have been tagged fixed by the NMU. The easiest way is to use the "
+"<literal>-v</literal> option of <command>dpkg-buildpackage</command>, as "
+"this allows you to include just all changes since your last maintainer "
+"upload. Alternatively, you can close them manually by sending the required "
+"mails to the BTS or by adding the required <literal>closes: #nnnn</literal> "
+"in the changelog entry of your next upload."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2019
+msgid ""
+"In any case, you should not be upset by the NMU. An NMU is not a personal "
+"attack against the maintainer. It is a proof that someone cares enough "
+"about the package that they were willing to help you in your work, so you "
+"should be thankful. You may also want to ask them if they would be "
+"interested in helping you on a more frequent basis as co-maintainer or "
+"backup maintainer (see <xref linkend=\"collaborative-maint\"/> )."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:2029
+msgid "NMU vs QA uploads"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2031
+msgid ""
+"Unless you know the maintainer is still active, it is wise to check the "
+"package to see if it has been orphaned. The current list of orphaned "
+"packages which haven't had their maintainer set correctly is available at "
+"<ulink url=\"&url-debian-qa-orphaned;\"></ulink>. If you perform an NMU on "
+"an improperly orphaned package, please set the maintainer to <literal>Debian "
+"QA Group <packages@qa.debian.org></literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:2041
+msgid "Who can do an NMU"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2043
+msgid ""
+"Only official, registered Debian Developers can do binary or source NMUs. A "
+"Debian Developer is someone who has their key in the Debian key ring. Non-"
+"developers, however, are encouraged to download the source package and start "
+"hacking on it to fix problems; however, rather than doing an NMU, they "
+"should just submit worthwhile patches to the Bug Tracking System. "
+"Maintainers almost always appreciate quality patches and bug reports."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:2053
+msgid "Terminology"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2055
+msgid ""
+"There are two new terms used throughout this section: ``binary-only NMU'' "
+"and ``source NMU''. These terms are used with specific technical meaning "
+"throughout this document. Both binary-only and source NMUs are similar, "
+"since they involve an upload of a package by a developer who is not the "
+"official maintainer of that package. That is why it's a <emphasis>non-"
+"maintainer</emphasis> upload."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2063
+msgid ""
+"A source NMU is an upload of a package by a developer who is not the "
+"official maintainer, for the purposes of fixing a bug in the package. "
+"Source NMUs always involves changes to the source (even if it is just a "
+"change to <filename>debian/changelog</filename>). This can be either a "
+"change to the upstream source, or a change to the Debian bits of the "
+"source. Note, however, that source NMUs may also include architecture-"
+"dependent packages, as well as an updated Debian diff."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2072
+msgid ""
+"A binary-only NMU is a recompilation and upload of a binary package for a "
+"given architecture. As such, it is usually part of a porting effort. A "
+"binary-only NMU is a non-maintainer uploaded binary version of a package, "
+"with no source changes required. There are many cases where porters must "
+"fix problems in the source in order to get them to compile for their target "
+"architecture; that would be considered a source NMU rather than a binary-"
+"only NMU. As you can see, we don't distinguish in terminology between "
+"porter NMUs and non-porter NMUs."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2082
+msgid ""
+"Both classes of NMUs, source and binary-only, can be lumped under the term "
+"``NMU''. However, this often leads to confusion, since most people think "
+"``source NMU'' when they think ``NMU''. So it's best to be careful: always "
+"use ``binary NMU'' or ``binNMU'' for binary-only NMUs."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:2092
+msgid "Collaborative maintenance"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:2094
+msgid ""
+"Collaborative maintenance is a term describing the sharing of Debian package "
+"maintenance duties by several people. This collaboration is almost always a "
+"good idea, since it generally results in higher quality and faster bug fix "
+"turnaround times. It is strongly recommended that packages with a priority "
+"of <literal>Standard</literal> or which are part of the base set have co-"
+"maintainers."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:2102
+msgid ""
+"Generally there is a primary maintainer and one or more co-maintainers. The "
+"primary maintainer is the person whose name is listed in the "
+"<literal>Maintainer</literal> field of the <filename>debian/control</"
+"filename> file. Co-maintainers are all the other maintainers."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:2108
+msgid ""
+"In its most basic form, the process of adding a new co-maintainer is quite "
+"easy:"
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2114
+msgid ""
+"Setup the co-maintainer with access to the sources you build the package "
+"from. Generally this implies you are using a network-capable version "
+"control system, such as <command>CVS</command> or <command>Subversion</"
+"command>. Alioth (see <xref linkend=\"alioth\"/> ) provides such tools, "
+"amongst others."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2122
+msgid ""
+"Add the co-maintainer's correct maintainer name and address to the "
+"<literal>Uploaders</literal> field in the global part of the "
+"<filename>debian/control</filename> file."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><screen>
+#: pkgs.dbk:2127
+#, no-wrap
+msgid "Uploaders: John Buzz <jbuzz@debian.org>, Adam Rex <arex@debian.org>"
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2132
+msgid ""
+"Using the PTS (<xref linkend=\"pkg-tracking-system\"/> ), the co-maintainers "
+"should subscribe themselves to the appropriate source package."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:2138
+msgid ""
+"Another form of collaborative maintenance is team maintenance, which is "
+"recommended if you maintain several packages with the same group of "
+"developers. In that case, the Maintainer and Uploaders field of each "
+"package must be managed with care. It is recommended to choose between one "
+"of the two following schemes:"
+msgstr ""
+
+# type: Content of: <chapter><section><orderedlist><listitem><para>
+#: pkgs.dbk:2147
+msgid ""
+"Put the team member mainly responsible for the package in the Maintainer "
+"field. In the Uploaders, put the mailing list address, and the team members "
+"who care for the package."
+msgstr ""
+
+# type: Content of: <chapter><section><orderedlist><listitem><para>
+#: pkgs.dbk:2154
+msgid ""
+"Put the mailing list address in the Maintainer field. In the Uploaders "
+"field, put the team members who care for the package. In this case, you "
+"must make sure the mailing list accept bug reports without any human "
+"interaction (like moderation for non-subscribers)."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:2162
+msgid ""
+"In any case, it is a bad idea to automatically put all team members in the "
+"Uploaders field. It clutters the Developer's Package Overview listing (see "
+"<xref linkend=\"ddpo\"/> ) with packages one doesn't really care for, and "
+"creates a false sense of good maintenance."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:2170
+msgid "The testing distribution"
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:2172
+msgid "Basics"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2174
+msgid ""
+"Packages are usually installed into the `testing' distribution after they "
+"have undergone some degree of testing in unstable."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2178
+msgid ""
+"They must be in sync on all architectures and mustn't have dependencies that "
+"make them uninstallable; they also have to have generally no known release-"
+"critical bugs at the time they're installed into testing. This way, "
+"`testing' should always be close to being a release candidate. Please see "
+"below for details."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:2187
+msgid "Updates from unstable"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2189
+msgid ""
+"The scripts that update the <emphasis>testing</emphasis> distribution are "
+"run each day after the installation of the updated packages; these scripts "
+"are called <emphasis>britney</emphasis>. They generate the "
+"<filename>Packages</filename> files for the <emphasis>testing</emphasis> "
+"distribution, but they do so in an intelligent manner; they try to avoid any "
+"inconsistency and to use only non-buggy packages."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2197
+msgid ""
+"The inclusion of a package from <emphasis>unstable</emphasis> is conditional "
+"on the following:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2203
+msgid ""
+"The package must have been available in <emphasis>unstable</emphasis> for 2, "
+"5 or 10 days, depending on the urgency (high, medium or low). Please note "
+"that the urgency is sticky, meaning that the highest urgency uploaded since "
+"the previous testing transition is taken into account. Those delays may be "
+"doubled during a freeze, or testing transitions may be switched off "
+"altogether;"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2212
+msgid ""
+"It must have the same number or fewer release-critical bugs than the version "
+"currently available in <emphasis>testing</emphasis>;"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2218
+msgid ""
+"It must be available on all architectures on which it has previously been "
+"built in unstable. <xref linkend=\"madison\"/> may be of interest to check "
+"that information;"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2225
+msgid ""
+"It must not break any dependency of a package which is already available in "
+"<emphasis>testing</emphasis>;"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2231
+msgid ""
+"The packages on which it depends must either be available in "
+"<emphasis>testing</emphasis> or they must be accepted into "
+"<emphasis>testing</emphasis> at the same time (and they will be if they "
+"fulfill all the necessary criteria);"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2239
+msgid ""
+"To find out whether a package is progressing into testing or not, see the "
+"testing script output on the <ulink url=\"&url-testing-maint;\">web page of "
+"the testing distribution</ulink>, or use the program <command>grep-excuses</"
+"command> which is in the <systemitem role=\"package\">devscripts</"
+"systemitem> package. This utility can easily be used in a <citerefentry> "
+"<refentrytitle>crontab</refentrytitle> <manvolnum>5</manvolnum> </"
+"citerefentry> to keep yourself informed of the progression of your packages "
+"into <emphasis>testing</emphasis>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2250
+msgid ""
+"The <filename>update_excuses</filename> file does not always give the "
+"precise reason why the package is refused; you may have to find it on your "
+"own by looking for what would break with the inclusion of the package. The "
+"<ulink url=\"&url-testing-maint;\">testing web page</ulink> gives some more "
+"information about the usual problems which may be causing such troubles."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2257
+msgid ""
+"Sometimes, some packages never enter <emphasis>testing</emphasis> because "
+"the set of inter-relationship is too complicated and cannot be sorted out by "
+"the scripts. See below for details."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2262
+msgid ""
+"Some further dependency analysis is shown on <ulink url=\"http://bjorn.haxx."
+"se/debian/\"></ulink> — but be warned, this page also shows build "
+"dependencies which are not considered by britney."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:2267
+msgid "out-of-date"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#. FIXME: better rename this file than document rampant professionalism?
+#: pkgs.dbk:2270
+msgid ""
+"For the testing migration script, outdated means: There are different "
+"versions in unstable for the release architectures (except for the "
+"architectures in fuckedarches; fuckedarches is a list of architectures that "
+"don't keep up (in update_out.py), but currently, it's empty). outdated has "
+"nothing whatsoever to do with the architectures this package has in testing."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2277
+msgid "Consider this example:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry>
+#: pkgs.dbk:2284 pkgs.dbk:2315
+msgid "alpha"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry>
+#: pkgs.dbk:2285 pkgs.dbk:2316
+msgid "arm"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry>
+#: pkgs.dbk:2290 pkgs.dbk:2322 pkgs.dbk:2382
+msgid "testing"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
+#: pkgs.dbk:2291 pkgs.dbk:2296 pkgs.dbk:2323 pkgs.dbk:2324 pkgs.dbk:2331
+msgid "1"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
+#: pkgs.dbk:2292 pkgs.dbk:2325 pkgs.dbk:2330
+msgid "-"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry>
+#: pkgs.dbk:2295 pkgs.dbk:2328 pkgs.dbk:2383
+msgid "unstable"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
+#: pkgs.dbk:2297 pkgs.dbk:2329
+msgid "2"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2303
+msgid ""
+"The package is out of date on alpha in unstable, and will not go to "
+"testing. And removing foo from testing would not help at all, the package "
+"is still out of date on alpha, and will not propagate to testing."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2308
+msgid "However, if ftp-master removes a package in unstable (here on arm):"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry>
+#: pkgs.dbk:2317
+msgid "hurd-i386"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2337
+msgid ""
+"In this case, the package is up to date on all release architectures in "
+"unstable (and the extra hurd-i386 doesn't matter, as it's not a release "
+"architecture)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2342
+msgid ""
+"Sometimes, the question is raised if it is possible to allow packages in "
+"that are not yet built on all architectures: No. Just plainly no. (Except "
+"if you maintain glibc or so.)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:2349
+msgid "Removals from testing"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2351
+msgid ""
+"Sometimes, a package is removed to allow another package in: This happens "
+"only to allow <emphasis>another</emphasis> package to go in if it's ready in "
+"every other sense. Suppose e.g. that <emphasis>a</emphasis> cannot be "
+"installed with the new version of <emphasis>b</emphasis>; then <emphasis>a</"
+"emphasis> may be removed to allow <emphasis>b</emphasis> in."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2358
+msgid ""
+"Of course, there is another reason to remove a package from testing: It's "
+"just too buggy (and having a single RC-bug is enough to be in this state)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2362
+msgid ""
+"Furthermore, if a package has been removed from unstable, and no package in "
+"testing depends on it any more, then it will automatically be removed."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:2368
+msgid "circular dependencies"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2370
+msgid ""
+"A situation which is not handled very well by britney is if package "
+"<emphasis>a</emphasis> depends on the new version of package <emphasis>b</"
+"emphasis>, and vice versa."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2375
+msgid "An example of this is:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
+#: pkgs.dbk:2388
+msgid "a"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
+#: pkgs.dbk:2389
+msgid "1; depends: b=1"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
+#: pkgs.dbk:2390
+msgid "2; depends: b=2"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
+#: pkgs.dbk:2393
+msgid "b"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
+#: pkgs.dbk:2394
+msgid "1; depends: a=1"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
+#: pkgs.dbk:2395
+msgid "2; depends: a=2"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2401
+msgid ""
+"Neither package <emphasis>a</emphasis> nor package <emphasis>b</emphasis> is "
+"considered for update."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2405
+msgid ""
+"Currently, this requires some manual hinting from the release team. Please "
+"contact them by sending mail to &email-debian-release; if this happens to "
+"one of your packages."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:2412
+msgid "influence of package in testing"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2414
+msgid ""
+"Generally, there is nothing that the status of a package in testing means "
+"for transition of the next version from unstable to testing, with two "
+"exceptions: If the RC-bugginess of the package goes down, it may go in even "
+"if it is still RC-buggy. The second exception is if the version of the "
+"package in testing is out of sync on the different arches: Then any arch "
+"might just upgrade to the version of the source package; however, this can "
+"happen only if the package was previously forced through, the arch is in "
+"fuckedarches, or there was no binary package of that arch present in "
+"unstable at all during the testing migration."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2424
+msgid ""
+"In summary this means: The only influence that a package being in testing "
+"has on a new version of the same package is that the new version might go in "
+"easier."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:2431
+msgid "details"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2433
+msgid "If you are interested in details, this is how britney works:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2436
+msgid ""
+"The packages are looked at to determine whether they are valid candidates. "
+"This gives the update excuses. The most common reasons why a package is not "
+"considered are too young, RC-bugginess, and out of date on some arches. For "
+"this part of britney, the release managers have hammers of various sizes to "
+"force britney to consider a package. (Also, the base freeze is coded in "
+"that part of britney.) (There is a similar thing for binary-only updates, "
+"but this is not described here. If you're interested in that, please peruse "
+"the code.)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2445
+msgid ""
+"Now, the more complex part happens: Britney tries to update testing with the "
+"valid candidates; first, each package alone, and then larger and even larger "
+"sets of packages together. Each try is accepted if testing is not more "
+"uninstallable after the update than before. (Before and after this part, "
+"some hints are processed; but as only release masters can hint, this is "
+"probably not so important for you.)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2453
+msgid ""
+"If you want to see more details, you can look it up on merkel:/org/&ftp-"
+"debian-org;/testing/update_out/ (or there in ~aba/testing/update_out to see "
+"a setup with a smaller packages file). Via web, it's at <ulink url=\"http://"
+"&ftp-master-host;/testing/update_out_code/\"></ulink>"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2460
+msgid ""
+"The hints are available via <ulink url=\"http://&ftp-master-host;/testing/"
+"hints/\"></ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:2468
+msgid "Direct updates to testing"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2470
+msgid ""
+"The testing distribution is fed with packages from unstable according to the "
+"rules explained above. However, in some cases, it is necessary to upload "
+"packages built only for testing. For that, you may want to upload to "
+"<emphasis>testing-proposed-updates</emphasis>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2476
+msgid ""
+"Keep in mind that packages uploaded there are not automatically processed, "
+"they have to go through the hands of the release manager. So you'd better "
+"have a good reason to upload there. In order to know what a good reason is "
+"in the release managers' eyes, you should read the instructions that they "
+"regularly give on &email-debian-devel-announce;."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2483
+msgid ""
+"You should not upload to <emphasis>testing-proposed-updates</emphasis> when "
+"you can update your packages through <emphasis>unstable</emphasis>. If you "
+"can't (for example because you have a newer development version in "
+"unstable), you may use this facility, but it is recommended that you ask for "
+"authorization from the release manager first. Even if a package is frozen, "
+"updates through unstable are possible, if the upload via unstable does not "
+"pull in any new dependencies."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2492
+msgid ""
+"Version numbers are usually selected by adding the codename of the testing "
+"distribution and a running number, like 1.2sarge1 for the first upload "
+"through testing-proposed-updates of package version 1.2."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2497
+msgid "Please make sure you didn't miss any of these items in your upload:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2502
+msgid ""
+"Make sure that your package really needs to go through <emphasis>testing-"
+"proposed-updates</emphasis>, and can't go through unstable;"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2508
+msgid "Make sure that you included only the minimal amount of changes;"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2513
+msgid ""
+"Make sure that you included an appropriate explanation in the changelog;"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2518
+msgid ""
+"Make sure that you've written <emphasis>testing</emphasis> or "
+"<emphasis>testing-proposed-updates</emphasis> into your target distribution;"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2524
+msgid ""
+"Make sure that you've built and tested your package in <emphasis>testing</"
+"emphasis>, not in <emphasis>unstable</emphasis>;"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2530
+msgid ""
+"Make sure that your version number is higher than the version in "
+"<emphasis>testing</emphasis> and <emphasis>testing-proposed-updates</"
+"emphasis>, and lower than in <emphasis>unstable</emphasis>;"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2537
+msgid ""
+"After uploading and successful build on all platforms, contact the release "
+"team at &email-debian-release; and ask them to approve your upload."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:2545
+msgid "Frequently asked questions"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:2547
+msgid "What are release-critical bugs, and how do they get counted?"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2549
+msgid ""
+"All bugs of some higher severities are by default considered release-"
+"critical; currently, these are critical, grave, and serious bugs."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2553
+msgid ""
+"Such bugs are presumed to have an impact on the chances that the package "
+"will be released with the stable release of Debian: in general, if a package "
+"has open release-critical bugs filed on it, it won't get into testing, and "
+"consequently won't be released in stable."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2559
+msgid ""
+"The unstable bug count are all release-critical bugs without either any "
+"release-tag (such as potato, woody) or with release-tag sid; also, only if "
+"they are neither fixed nor set to sarge-ignore. The testing bug count for a "
+"package is considered to be roughly the bug count of unstable count at the "
+"last point when the testing version equalled the unstable version."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2566
+msgid ""
+"This will change post-sarge, as soon as we have versions in the bug tracking "
+"system."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:2572
+msgid ""
+"How could installing a package into testing possibly break other packages?"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2574
+msgid ""
+"The structure of the distribution archives is such that they can only "
+"contain one version of a package; a package is defined by its name. So when "
+"the source package acmefoo is installed into testing, along with its binary "
+"packages acme-foo-bin, acme-bar-bin, libacme-foo1 and libacme-foo-dev, the "
+"old version is removed."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2581
+msgid ""
+"However, the old version may have provided a binary package with an old "
+"soname of a library, such as libacme-foo0. Removing the old acmefoo will "
+"remove libacme-foo0, which will break any packages which depend on it."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2586
+msgid ""
+"Evidently, this mainly affects packages which provide changing sets of "
+"binary packages in different versions (in turn, mainly libraries). However, "
+"it will also affect packages upon which versioned dependencies have been "
+"declared of the ==, <=, or << varieties."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2592
+msgid ""
+"When the set of binary packages provided by a source package change in this "
+"way, all the packages that depended on the old binaries will have to be "
+"updated to depend on the new binaries instead. Because installing such a "
+"source package into testing breaks all the packages that depended on it in "
+"testing, some care has to be taken now: all the depending packages must be "
+"updated and ready to be installed themselves so that they won't be broken, "
+"and, once everything is ready, manual intervention by the release manager or "
+"an assistant is normally required."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2602
+msgid ""
+"If you are having problems with complicated groups of packages like this, "
+"contact debian-devel or debian-release for help."
+msgstr ""
--- /dev/null
+# SOME DESCRIPTIVE TITLE
+# Copyright (C) YEAR Free Software Foundation, Inc.
+# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
+#
+#, fuzzy
+msgid ""
+msgstr ""
+"Project-Id-Version: PACKAGE VERSION\n"
+"POT-Creation-Date: 2007-07-01 21:18+0000\n"
+"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
+"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
+"Language-Team: LANGUAGE <LL@li.org>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: ENCODING\n"
+
+# type: Content of: <chapter><title>
+#: resources.dbk:7
+msgid "Resources for Debian Developers"
+msgstr ""
+
+# type: Content of: <chapter><para>
+#: resources.dbk:9
+msgid ""
+"In this chapter you will find a very brief road map of the Debian mailing "
+"lists, the Debian machines which may be available to you as a developer, and "
+"all the other resources that are available to help you in your maintainer "
+"work."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: resources.dbk:14
+msgid "Mailing lists"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:16
+msgid ""
+"Much of the conversation between Debian developers (and users) is managed "
+"through a wide array of mailing lists we host at <literal><ulink url="
+"\"http://&lists-host;/\">&lists-host;</ulink></literal>. 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 <ulink url=\"&url-debian-lists;\"></ulink>. This section will "
+"only cover aspects of mailing lists that are of particular interest to "
+"developers."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:27
+msgid "Basic rules for use"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:29
+msgid ""
+"When replying to messages on the mailing list, please do not send a carbon "
+"copy (<literal>CC</literal>) 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."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:35
+msgid ""
+"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."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:40
+msgid ""
+"Please read the <ulink url=\"&url-debian-lists;#codeofconduct\">code of "
+"conduct</ulink> for more information."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:47
+msgid "Core development mailing lists"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:49
+msgid "The core Debian mailing lists that developers should use are:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: resources.dbk:54
+msgid ""
+"&email-debian-devel-announce;, used to announce important things to "
+"developers. All developers are expected to be subscribed to this list."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: resources.dbk:61
+msgid ""
+"&email-debian-devel;, used to discuss various development related technical "
+"issues."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: resources.dbk:67
+msgid ""
+"&email-debian-policy;, where the Debian Policy is discussed and voted on."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: resources.dbk:73
+msgid ""
+"&email-debian-project;, used to discuss various non-technical issues related "
+"to the project."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:79
+msgid ""
+"There are other mailing lists available for a variety of special topics; see "
+"<ulink url=\"http://&lists-host;/\"></ulink> for a list."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:85
+msgid "Special lists"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:87
+msgid ""
+"&email-debian-private; is a special mailing list for private discussions "
+"amongst Debian developers. It is meant to be used for posts which for "
+"whatever reason should not be published publicly. As such, it is a low "
+"volume list, and users are urged not to use &email-debian-private; unless it "
+"is really necessary. Moreover, do <emphasis>not</emphasis> forward email "
+"from that list to anyone. Archives of this list are not available on the "
+"web for obvious reasons, but you can see them using your shell account on "
+"<literal>&lists-host;</literal> and looking in the <filename>&file-debian-"
+"private-archive;</filename> directory."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:99
+msgid ""
+"&email-debian-email; is a special mailing list used as a grab-bag 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."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:107
+msgid "Requesting new development-related lists"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:109
+msgid ""
+"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 <replaceable>you-aliasname@debian.org</replaceable> "
+"address) or a self-managed mailing list on <link linkend=\"alioth\">Alioth</"
+"link> is more appropriate."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:117
+msgid ""
+"If you decide that a regular mailing list on &lists-host; is really what you "
+"want, go ahead and fill in a request, following <ulink url=\"&url-debian-"
+"lists-new;\">the HOWTO</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: resources.dbk:126
+msgid "IRC channels"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:128
+msgid ""
+"Several IRC channels are dedicated to Debian's development. They are mainly "
+"hosted on the <ulink url=\"&url-oftc;\">Open and free technology community "
+"(OFTC)</ulink> network. The <literal>irc.debian.org</literal> DNS entry is "
+"an alias to <literal>irc.oftc.net</literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:134
+msgid ""
+"The main channel for Debian in general is <emphasis>#debian</emphasis>. "
+"This is a large, general-purpose channel where users can find recent news in "
+"the topic and served by bots. <emphasis>#debian</emphasis> is for English "
+"speakers; there are also <emphasis>#debian.de</emphasis>, <emphasis>#debian-"
+"fr</emphasis>, <emphasis>#debian-br</emphasis> and other similarly named "
+"channels for speakers of other languages."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:142
+msgid ""
+"The main channel for Debian development is <emphasis>#debian-devel</"
+"emphasis>. It is a very active channel since usually over 150 people are "
+"always logged in. It's a channel for people who work on Debian, it's not a "
+"support channel (there's <emphasis>#debian</emphasis> for that). It is "
+"however open to anyone who wants to lurk (and learn). Its topic is commonly "
+"full of interesting information for developers."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:150
+msgid ""
+"Since <emphasis>#debian-devel</emphasis> is an open channel, you should not "
+"speak there of issues that are discussed in &email-debian-private;. There's "
+"another channel for this purpose, it's called <emphasis>#debian-private</"
+"emphasis> and it's protected by a key. This key is available in the "
+"archives of debian-private in <filename>master.debian.org:&file-debian-"
+"private-archive;</filename>, just <command>zgrep</command> for "
+"<emphasis>#debian-private</emphasis> in all the files."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:160
+msgid ""
+"There are other additional channels dedicated to specific subjects. "
+"<emphasis>#debian-bugs</emphasis> is used for coordinating bug squashing "
+"parties. <emphasis>#debian-boot</emphasis> is used to coordinate the work "
+"on the debian-installer. <emphasis>#debian-doc</emphasis> is occasionally "
+"used to talk about documentation, like the document you are reading. Other "
+"channels are dedicated to an architecture or a set of packages: "
+"<emphasis>#debian-bsd</emphasis>, <emphasis>#debian-kde</emphasis>, "
+"<emphasis>#debian-jr</emphasis>, <emphasis>#debian-edu</emphasis>, "
+"<emphasis>#debian-sf</emphasis> (SourceForge package), <emphasis>#debian-oo</"
+"emphasis> (OpenOffice package) ..."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:172
+msgid ""
+"Some non-English developers' channels exist as well, for example "
+"<emphasis>#debian-devel-fr</emphasis> for French speaking people interested "
+"in Debian's development."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:177
+msgid ""
+"Channels dedicated to Debian also exist on other IRC networks, notably on "
+"the <ulink url=\"&url-openprojects;\">freenode</ulink> IRC network, which "
+"was pointed at by the <literal>irc.debian.org</literal> alias until 4th June "
+"2006."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:183
+msgid ""
+"To get a cloak on freenode, you send Jörg Jaspert <joerg@debian.org> a "
+"signed mail where you tell what your nick is. Put cloak somewhere in the "
+"Subject: header. The nick should be registered: <ulink url=\"http://"
+"freenode.net/faq.shtml#nicksetup\">Nick Setup Page</ulink>. The mail needs "
+"to be signed by a key in the Debian keyring. Please see <ulink url=\"http://"
+"freenode.net/faq.shtml#projectcloak\">Freenodes documentation</ulink> for "
+"more information about cloaks."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: resources.dbk:194
+msgid "Documentation"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:196
+msgid ""
+"This document contains a lot of information which is useful to Debian "
+"developers, but it cannot contain everything. Most of the other interesting "
+"documents are linked from <ulink url=\"&url-devel-docs;\">The Developers' "
+"Corner</ulink>. Take the time to browse all the links, you will learn many "
+"more things."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: resources.dbk:205
+msgid "Debian machines"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:207
+msgid ""
+"Debian has several computers working as servers, most of which serve "
+"critical functions in the Debian project. Most of the machines are used for "
+"porting activities, and they all have a permanent connection to the Internet."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:212
+msgid ""
+"Most of the machines are available for individual developers to use, as long "
+"as the developers follow the rules set forth in the <ulink url=\"&url-dmup;"
+"\">Debian Machine Usage Policies</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:217
+msgid ""
+"Generally speaking, you can use these machines for Debian-related purposes "
+"as you see fit. Please be kind to system administrators, and do not use up "
+"tons and tons of disk space, network bandwidth, or CPU without first getting "
+"the approval of the system administrators. Usually these machines are run "
+"by volunteers."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:224
+msgid ""
+"Please take care to protect your Debian passwords and SSH keys installed on "
+"Debian machines. Avoid login or upload methods which send passwords over "
+"the Internet in the clear, such as telnet, FTP, POP etc."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:229
+msgid ""
+"Please do not put any material that doesn't relate to Debian on the Debian "
+"servers, unless you have prior permission."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:233
+msgid ""
+"The current list of Debian machines is available at <ulink url=\"&url-devel-"
+"machines;\"></ulink>. That web page contains machine names, contact "
+"information, information about who can log in, SSH keys etc."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:239
+msgid ""
+"If you have a problem with the operation of a Debian server, and you think "
+"that the system operators need to be notified of this problem, the Debian "
+"system administrator team is reachable at <email>debian-admin@&lists-host;</"
+"email>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:245
+msgid ""
+"If you have a problem with a certain service, not related to the system "
+"administration (such as packages to be removed from the archive, suggestions "
+"for the web site, etc.), generally you'll report a bug against a ``pseudo-"
+"package''. See <xref linkend=\"submit-bug\"/> for information on how to "
+"submit bugs."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:252
+msgid ""
+"Some of the core servers are restricted, but the information from there is "
+"mirrored to another server."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:256
+msgid "The bugs server"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:258
+msgid ""
+"<literal>&bugs-host;</literal> is the canonical location for the Bug "
+"Tracking System (BTS)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:262 resources.dbk:280
+msgid "It is restricted; a mirror is available on <literal>merkel</literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:265
+msgid ""
+"If you plan on doing some statistical analysis or processing of Debian bugs, "
+"this would be the place to do it. Please describe your plans on &email-"
+"debian-devel; before implementing anything, however, to reduce unnecessary "
+"duplication of effort or wasted processing time."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:273
+msgid "The ftp-master server"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:275
+msgid ""
+"The <literal>&ftp-master-host;</literal> server holds the canonical copy of "
+"the Debian archive (excluding the non-US packages). Generally, package "
+"uploads go to this server; see <xref linkend=\"upload\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:283
+msgid ""
+"Problems with the Debian FTP archive generally need to be reported as bugs "
+"against the <systemitem role=\"package\">&ftp-debian-org;</systemitem> "
+"pseudo-package or an email to &email-ftpmaster;, but also see the procedures "
+"in <xref linkend=\"archive-manip\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:291
+msgid "The non-US server"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:293
+msgid ""
+"The non-US server <literal>&non-us-host;</literal> was discontinued with the "
+"release of sarge. The pseudo-package <systemitem role=\"package\">nonus."
+"debian.org</systemitem> still exists for now."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:300
+msgid "The www-master server"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:302
+msgid ""
+"The main web server is <literal>www-master.debian.org</literal>. It holds "
+"the official web pages, the face of Debian for most newbies."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:306
+msgid ""
+"If you find a problem with the Debian web server, you should generally "
+"submit a bug against the pseudo-package, <systemitem role=\"package\">www."
+"debian.org</systemitem>. Remember to check whether or not someone else has "
+"already reported the problem to the <ulink url=\"http://&bugs-host;/&www-"
+"debian-org;\">Bug Tracking System</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:315
+msgid "The people web server"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:317
+msgid ""
+"<literal>people.debian.org</literal> is the server used for developers' own "
+"web pages about anything related to Debian."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:321
+msgid ""
+"If you have some Debian-specific information which you want to serve on the "
+"web, you can do this by putting material in the <filename>public_html</"
+"filename> directory under your home directory on <literal>people.debian.org</"
+"literal>. This will be accessible at the URL <literal>http://people.debian."
+"org/~<replaceable>your-user-id</replaceable>/</literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:328
+msgid ""
+"You should only use this particular location because it will be backed up, "
+"whereas on other hosts it won't."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:332
+msgid ""
+"Usually the only reason to use a different host is when you need to publish "
+"materials subject to the U.S. export restrictions, in which case you can "
+"use one of the other servers located outside the United States."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:337
+msgid "Send mail to &email-debian-devel; if you have any questions."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:342
+msgid "The CVS server"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:345
+msgid "Our CVS server is located on <literal>cvs.debian.org</literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:348
+msgid ""
+"If you need to use a publicly accessible CVS server, for instance, to help "
+"coordinate work on a package between many different developers, you can "
+"request a CVS area on the server."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:353
+msgid ""
+"Generally, <literal>cvs.debian.org</literal> offers a combination of local "
+"CVS access, anonymous client-server read-only access, and full client-server "
+"access through <command>ssh</command>. Also, the CVS area can be accessed "
+"read-only via the Web at <ulink url=\"&url-cvsweb;\"></ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:359
+msgid ""
+"To request a CVS area, send a request via email to &email-debian-admin;. "
+"Include the name of the requested CVS area, the Debian account that should "
+"own the CVS root area, and why you need it."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:367
+msgid "chroots to different distributions"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:369
+msgid ""
+"On some machines, there are chroots to different distributions available. "
+"You can use them like this:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: resources.dbk:373
+#, no-wrap
+msgid ""
+"vore$ dchroot unstable\n"
+"Executing shell in chroot: /org/vore.debian.org/chroots/user/unstable"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:377
+msgid ""
+"In all chroots, the normal user home directories are available. You can "
+"find out which chroots are available via <literal>&url-devel-machines;</"
+"literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: resources.dbk:386
+msgid "The Developers Database"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:388
+msgid ""
+"The Developers Database, at <ulink url=\"&url-debian-db;\"></ulink>, is an "
+"LDAP directory for managing Debian developer attributes. You can use this "
+"resource to search the list of Debian developers. Part of this information "
+"is also available through the finger service on Debian servers, try "
+"<command>finger yourlogin@db.debian.org</command> to see what it reports."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:396
+msgid ""
+"Developers can <ulink url=\"&url-debian-db-login;\">log into the database</"
+"ulink> to change various information about themselves, such as:"
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: resources.dbk:402
+msgid "forwarding address for your debian.org email"
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: resources.dbk:407
+msgid "subscription to debian-private"
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: resources.dbk:412
+msgid "whether you are on vacation"
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: resources.dbk:417
+msgid ""
+"personal information such as your address, country, the latitude and "
+"longitude of the place where you live for use in <ulink url=\"&url-worldmap;"
+"\">the world map of Debian developers</ulink>, phone and fax numbers, IRC "
+"nickname and web page"
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: resources.dbk:425
+msgid "password and preferred shell on Debian Project machines"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:430
+msgid ""
+"Most of the information is not accessible to the public, naturally. For "
+"more information please read the online documentation that you can find at "
+"<ulink url=\"&url-debian-db-doc;\"></ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:435
+msgid ""
+"Developers can also submit their SSH keys to be used for authorization on "
+"the official Debian machines, and even add new *.debian.net DNS entries. "
+"Those features are documented at <ulink url=\"&url-debian-db-mail-gw;\"></"
+"ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: resources.dbk:443
+msgid "The Debian archive"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:445
+msgid ""
+"The &debian-formal; distribution consists of a lot of packages (<filename>."
+"deb</filename>'s, currently around &number-of-pkgs;) and a few additional "
+"files (such as documentation and installation disk images)."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:451
+msgid "Here is an example directory tree of a complete Debian archive:"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:455
+msgid ""
+"As you can see, the top-level directory contains two directories, "
+"<filename>dists/</filename> and <filename>pool/</filename>. The latter is a "
+"“pool” in which the packages actually are, and which is handled by the "
+"archive maintenance database and the accompanying programs. The former "
+"contains the distributions, <emphasis>stable</emphasis>, <emphasis>testing</"
+"emphasis> and <emphasis>unstable</emphasis>. The <filename>Packages</"
+"filename> and <filename>Sources</filename> files in the distribution "
+"subdirectories can reference files in the <filename>pool/</filename> "
+"directory. The directory tree below each of the distributions is arranged "
+"in an identical manner. What we describe below for <emphasis>stable</"
+"emphasis> is equally applicable to the <emphasis>unstable</emphasis> and "
+"<emphasis>testing</emphasis> distributions."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:469
+msgid ""
+"<filename>dists/stable</filename> contains three directories, namely "
+"<filename>main</filename>, <filename>contrib</filename>, and <filename>non-"
+"free</filename>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:474
+msgid ""
+"In each of the areas, there is a directory for the source packages "
+"(<filename>source</filename>) and a directory for each supported "
+"architecture (<filename>binary-i386</filename>, <filename>binary-m68k</"
+"filename>, etc.)."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:479
+msgid ""
+"The <filename>main</filename> 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 "
+"(<filename>disks-i386</filename>, <filename>disks-m68k</filename>, etc.)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:485
+msgid "Sections"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:487
+msgid ""
+"The <emphasis>main</emphasis> section of the Debian archive is what makes up "
+"the <emphasis role=\"strong\">official &debian-formal; distribution</"
+"emphasis>. The <emphasis>main</emphasis> section is official because it "
+"fully complies with all our guidelines. The other two sections do not, to "
+"different degrees; as such, they are <emphasis role=\"strong\">not</"
+"emphasis> officially part of &debian-formal;."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:495
+msgid ""
+"Every package in the main section must fully comply with the <ulink url="
+"\"&url-dfsg;\">Debian Free Software Guidelines</ulink> (DFSG) and with all "
+"other policy requirements as described in the <ulink url=\"&url-debian-"
+"policy;\">Debian Policy Manual</ulink>. The DFSG is our definition of “free "
+"software.” Check out the Debian Policy Manual for details."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:503
+msgid ""
+"Packages in the <emphasis>contrib</emphasis> section have to comply with the "
+"DFSG, but may fail other requirements. For instance, they may depend on non-"
+"free packages."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:508
+msgid ""
+"Packages which do not conform to the DFSG are placed in the <emphasis>non-"
+"free</emphasis> section. These packages are not considered as part of the "
+"Debian distribution, though we support their use, and we provide "
+"infrastructure (such as our bug-tracking system and mailing lists) for non-"
+"free software packages."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:515
+msgid ""
+"The <ulink url=\"&url-debian-policy;\">Debian Policy Manual</ulink> contains "
+"a more exact definition of the three sections. The above discussion is just "
+"an introduction."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:520
+msgid ""
+"The separation of the three sections at the top-level of the archive is "
+"important for all people who want to distribute Debian, either via FTP "
+"servers on the Internet or on CD-ROMs: by distributing only the "
+"<emphasis>main</emphasis> and <emphasis>contrib</emphasis> sections, one can "
+"avoid any legal risks. Some packages in the <emphasis>non-free</emphasis> "
+"section do not allow commercial distribution, for example."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:528
+msgid ""
+"On the other hand, a CD-ROM vendor could easily check the individual package "
+"licenses of the packages in <emphasis>non-free</emphasis> and include as "
+"many on the CD-ROMs as it's allowed to. (Since this varies greatly from "
+"vendor to vendor, this job can't be done by the Debian developers.)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:534
+msgid ""
+"Note that the term section is also used to refer to categories which "
+"simplify the organization and browsing of available packages, e.g. "
+"<emphasis>admin</emphasis>, <emphasis>net</emphasis>, <emphasis>utils</"
+"emphasis> etc. Once upon a time, these sections (subsections, rather) "
+"existed in the form of subdirectories within the Debian archive. Nowadays, "
+"these exist only in the Section header fields of packages."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:544
+msgid "Architectures"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:546
+msgid ""
+"In the first days, the Linux kernel was only available for Intel i386 (or "
+"greater) platforms, and so was Debian. But as Linux became more and more "
+"popular, the kernel was ported to other architectures, too."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:551
+msgid ""
+"The Linux 2.0 kernel supports Intel x86, DEC Alpha, SPARC, Motorola 680x0 "
+"(like Atari, Amiga and Macintoshes), MIPS, and PowerPC. The 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 kernels. Aside from <emphasis>i386</emphasis> (our name for "
+"Intel x86), there is <emphasis>m68k</emphasis>, <emphasis>alpha</emphasis>, "
+"<emphasis>powerpc</emphasis>, <emphasis>sparc</emphasis>, <emphasis>hurd-"
+"i386</emphasis>, <emphasis>arm</emphasis>, <emphasis>ia64</emphasis>, "
+"<emphasis>hppa</emphasis>, <emphasis>s390</emphasis>, <emphasis>mips</"
+"emphasis>, <emphasis>mipsel</emphasis> and <emphasis>sh</emphasis> as of "
+"this writing."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:565
+msgid ""
+"&debian-formal; 1.3 is only available as <emphasis>i386</emphasis>. Debian "
+"2.0 shipped for <emphasis>i386</emphasis> and <emphasis>m68k</emphasis> "
+"architectures. Debian 2.1 ships for the <emphasis>i386</emphasis>, "
+"<emphasis>m68k</emphasis>, <emphasis>alpha</emphasis>, and <emphasis>sparc</"
+"emphasis> architectures. Debian 2.2 added support for the "
+"<emphasis>powerpc</emphasis> and <emphasis>arm</emphasis> architectures. "
+"Debian 3.0 added support of five new architectures: <emphasis>ia64</"
+"emphasis>, <emphasis>hppa</emphasis>, <emphasis>s390</emphasis>, "
+"<emphasis>mips</emphasis> and <emphasis>mipsel</emphasis>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:576
+msgid ""
+"Information for developers and users about the specific ports are available "
+"at the <ulink url=\"&url-debian-ports;\">Debian Ports web pages</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:582
+msgid "Packages"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:584
+msgid ""
+"There are two types of Debian packages, namely <emphasis>source</emphasis> "
+"and <emphasis>binary</emphasis> packages."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:588
+msgid ""
+"Source packages consist of either two or three files: a <filename>.dsc</"
+"filename> file, and either a <filename>.tar.gz</filename> file or both an "
+"<filename>.orig.tar.gz</filename> and a <filename>.diff.gz</filename> file."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:594
+msgid ""
+"If a package is developed specially for Debian and is not distributed "
+"outside of Debian, there is just one <filename>.tar.gz</filename> file which "
+"contains the sources of the program. If a package is distributed elsewhere "
+"too, the <filename>.orig.tar.gz</filename> file stores the so-called "
+"<emphasis>upstream source code</emphasis>, that is the source code that's "
+"distributed by the <emphasis>upstream maintainer</emphasis> (often the "
+"author of the software). In this case, the <filename>.diff.gz</filename> "
+"contains the changes made by the Debian maintainer."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:604
+msgid ""
+"The <filename>.dsc</filename> file lists all the files in the source package "
+"together with checksums (<command>md5sums</command>) and some additional "
+"info about the package (maintainer, version, etc.)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:611
+msgid "Distributions"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:613
+msgid ""
+"The directory system described in the previous chapter is itself contained "
+"within <emphasis>distribution directories</emphasis>. Each distribution is "
+"actually contained in the <filename>pool</filename> directory in the top-"
+"level of the Debian archive itself."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:619
+msgid ""
+"To summarize, the Debian archive has a root directory within an FTP server. "
+"For instance, at the mirror site, <literal>ftp.us.debian.org</literal>, the "
+"Debian archive itself is contained in <ulink url=\"ftp://ftp.us.debian.org/"
+"debian\">/debian</ulink>, which is a common location (another is <filename>/"
+"pub/debian</filename>)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:626
+msgid ""
+"A distribution comprises Debian source and binary packages, and the "
+"respective <filename>Sources</filename> and <filename>Packages</filename> "
+"index files, containing the header information from all those packages. The "
+"former are kept in the <filename>pool/</filename> directory, while the "
+"latter are kept in the <filename>dists/</filename> directory of the archive "
+"(for backwards compatibility)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: resources.dbk:634
+msgid "Stable, testing, and unstable"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: resources.dbk:636
+msgid ""
+"There are always distributions called <emphasis>stable</emphasis> (residing "
+"in <filename>dists/stable</filename>), <emphasis>testing</emphasis> "
+"(residing in <filename>dists/testing</filename>), and <emphasis>unstable</"
+"emphasis> (residing in <filename>dists/unstable</filename>). This reflects "
+"the development process of the Debian project."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: resources.dbk:643
+msgid ""
+"Active development is done in the <emphasis>unstable</emphasis> distribution "
+"(that's why this distribution is sometimes called the <emphasis>development "
+"distribution</emphasis>). Every Debian developer can update his or her "
+"packages in this distribution at any time. Thus, the contents of this "
+"distribution change from day to day. Since no special effort is made to "
+"make sure everything in this distribution is working properly, it is "
+"sometimes literally unstable."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: resources.dbk:652
+msgid ""
+"The <link linkend=\"testing\">testing</link> distribution 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. See <xref linkend=\"testing\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: resources.dbk:659
+msgid ""
+"After a period of development, once the release manager deems fit, the "
+"<emphasis>testing</emphasis> distribution is frozen, meaning that the "
+"policies which control how packages move from <emphasis>unstable</emphasis> "
+"to <emphasis>testing</emphasis> are tightened. Packages which are too buggy "
+"are removed. No changes are allowed into <emphasis>testing</emphasis> "
+"except for bug fixes. After some time has elapsed, depending on progress, "
+"the <emphasis>testing</emphasis> distribution is frozen even further. "
+"Details of the handling of the testing distribution are published by the "
+"Release Team on debian-devel-announce. After the open issues are solved to "
+"the satisfaction of the Release Team, the distribution is released. "
+"Releasing means that <emphasis>testing</emphasis> is renamed to "
+"<emphasis>stable</emphasis>, and a new copy is created for the new "
+"<emphasis>testing</emphasis>, and the previous <emphasis>stable</emphasis> "
+"is renamed to <emphasis>oldstable</emphasis> and stays there until it is "
+"finally archived. On archiving, the contents are moved to <literal>&archive-"
+"host;</literal>)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: resources.dbk:676
+msgid ""
+"This development cycle is based on the assumption that the "
+"<emphasis>unstable</emphasis> distribution becomes <emphasis>stable</"
+"emphasis> after passing a period of being in <emphasis>testing</emphasis>. "
+"Even once a distribution is considered stable, a few bugs inevitably remain "
+"— that's why the stable distribution is updated every now and then. "
+"However, these updates are tested very carefully and have to be introduced "
+"into the archive individually to reduce the risk of introducing new bugs. "
+"You can find proposed additions to <emphasis>stable</emphasis> in the "
+"<filename>proposed-updates</filename> directory. Those packages in "
+"<filename>proposed-updates</filename> that pass muster are periodically "
+"moved as a batch into the stable distribution and the revision level of the "
+"stable distribution is incremented (e.g., ‘3.0’ becomes ‘3.0r1’, ‘2.2r4’ "
+"becomes ‘2.2r5’, and so forth). Please refer to <link linkend=\"upload-"
+"stable\">uploads to the <emphasis>stable</emphasis> distribution</link> for "
+"details."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: resources.dbk:693
+msgid ""
+"Note that development under <emphasis>unstable</emphasis> continues during "
+"the freeze period, since the <emphasis>unstable</emphasis> distribution "
+"remains in place in parallel with <emphasis>testing</emphasis>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: resources.dbk:700
+msgid "More information about the testing distribution"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: resources.dbk:702
+msgid ""
+"Packages are usually installed into the `testing' distribution after they "
+"have undergone some degree of testing in unstable."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: resources.dbk:706
+msgid ""
+"For more details, please see the <link linkend=\"testing\">information about "
+"the testing distribution</link>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: resources.dbk:712
+msgid "Experimental"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: resources.dbk:714
+msgid ""
+"The <emphasis>experimental</emphasis> distribution is a special "
+"distribution. It is not a full distribution in the same sense as `stable' "
+"and `unstable' are. Instead, it is meant to be a temporary staging area for "
+"highly experimental software where there's a good chance that the software "
+"could break your system, or software that's just too unstable even for the "
+"<emphasis>unstable</emphasis> distribution (but there is a reason to package "
+"it nevertheless). Users who download and install packages from "
+"<emphasis>experimental</emphasis> are expected to have been duly warned. In "
+"short, all bets are off for the <emphasis>experimental</emphasis> "
+"distribution."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: resources.dbk:725
+msgid ""
+"These are the <citerefentry> <refentrytitle>sources.list</refentrytitle> "
+"<manvolnum>5</manvolnum> </citerefentry> lines for <emphasis>experimental</"
+"emphasis>:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><programlisting>
+#: resources.dbk:730
+#, no-wrap
+msgid ""
+"deb http://ftp.<replaceable>xy</replaceable>.debian.org/debian/ experimental main\n"
+"deb-src http://ftp.<replaceable>xy</replaceable>.debian.org/debian/ experimental main"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: resources.dbk:734
+msgid ""
+"If there is a chance that the software could do grave damage to a system, it "
+"is likely to be better to put it into <emphasis>experimental</emphasis>. "
+"For instance, an experimental compressed file system should probably go into "
+"<emphasis>experimental</emphasis>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: resources.dbk:740
+msgid ""
+"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 <emphasis>experimental</emphasis>. A new, beta, version of "
+"some software which uses a completely different configuration can go into "
+"<emphasis>experimental</emphasis>, at the maintainer's discretion. If you "
+"are working on an incompatible or complex upgrade situation, you can also "
+"use <emphasis>experimental</emphasis> as a staging area, so that testers can "
+"get early access."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: resources.dbk:750
+msgid ""
+"Some experimental software can still go into <emphasis>unstable</emphasis>, "
+"with a few warnings in the description, but that isn't recommended because "
+"packages from <emphasis>unstable</emphasis> are expected to propagate to "
+"<emphasis>testing</emphasis> and thus to <emphasis>stable</emphasis>. You "
+"should not be afraid to use <emphasis>experimental</emphasis> since it does "
+"not cause any pain to the ftpmasters, the experimental packages are "
+"automatically removed once you upload the package in <emphasis>unstable</"
+"emphasis> with a higher version number."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: resources.dbk:760
+msgid ""
+"New software which isn't likely to damage your system can go directly into "
+"<emphasis>unstable</emphasis>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: resources.dbk:764
+msgid ""
+"An alternative to <emphasis>experimental</emphasis> is to use your personal "
+"web space on <literal>people.debian.org</literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: resources.dbk:768
+msgid ""
+"When uploading to unstable a package which had bugs fixed in experimental, "
+"please consider using the option <literal>-v</literal> to <command>dpkg-"
+"buildpackage</command> to finally get them closed."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:777
+msgid "Release code names"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:779
+msgid ""
+"Every released Debian distribution has a <emphasis>code name</emphasis>: "
+"Debian 1.1 is called `buzz'; Debian 1.2, `rex'; Debian 1.3, `bo'; Debian "
+"2.0, `hamm'; Debian 2.1, `slink'; Debian 2.2, `potato'; Debian 3.0, `woody'; "
+"Debian 3.1, sarge; Debian 4.0, etch. There is also a ``pseudo-"
+"distribution'', called `sid', which is the current `unstable' distribution; "
+"since packages are moved from `unstable' to `testing' as they approach "
+"stability, `sid' itself is never released. As well as the usual contents of "
+"a Debian distribution, `sid' contains packages for architectures which are "
+"not yet officially supported or released by Debian. These architectures are "
+"planned to be integrated into the mainstream distribution at some future "
+"date."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:791
+msgid ""
+"Since Debian has an open development model (i.e., everyone can participate "
+"and follow the development) even the `unstable' and `testing' distributions "
+"are distributed to the Internet through the Debian FTP and HTTP server "
+"network. Thus, if we had called the directory which contains the release "
+"candidate version `testing', then we would have to rename it to `stable' "
+"when the version is released, which would cause all FTP mirrors to re-"
+"retrieve the whole distribution (which is quite large)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:800
+msgid ""
+"On the other hand, if we called the distribution directories "
+"<emphasis>Debian-x.y</emphasis> from the beginning, people would think that "
+"Debian release <emphasis>x.y</emphasis> is available. (This happened in the "
+"past, where a CD-ROM vendor built a Debian 1.0 CD-ROM based on a pre-1.0 "
+"development version. That's the reason why the first official Debian "
+"release was 1.1, and not 1.0.)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:808
+msgid ""
+"Thus, the names of the distribution directories in the archive are "
+"determined by their code names and not their release status (e.g., "
+"`slink'). These names stay the same during the development period and after "
+"the release; symbolic links, which can be changed easily, indicate the "
+"currently released stable distribution. That's why the real distribution "
+"directories use the <emphasis>code names</emphasis>, while symbolic links "
+"for <emphasis>stable</emphasis>, <emphasis>testing</emphasis>, and "
+"<emphasis>unstable</emphasis> point to the appropriate release directories."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: resources.dbk:822
+msgid "Debian mirrors"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:824
+msgid ""
+"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 — 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. Note that the first tier of "
+"mirrors is as up-to-date as it can be since they update when triggered from "
+"the internal sites (we call this push mirroring)."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:835
+msgid ""
+"All the information on Debian mirrors, including a list of the available "
+"public FTP/HTTP servers, can be found at <ulink url=\"&url-debian-mirrors;"
+"\"></ulink>. This useful page also includes information and tools which can "
+"be helpful if you are interested in setting up your own mirror, either for "
+"internal or public access."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:842
+msgid ""
+"Note that mirrors are generally run by third-parties who are interested in "
+"helping Debian. As such, developers generally do not have accounts on these "
+"machines."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: resources.dbk:849
+msgid "The Incoming system"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:851
+msgid ""
+"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 on <literal>&ftp-master-host;</literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:856
+msgid ""
+"Packages are uploaded by all the maintainers into a directory called "
+"<filename>UploadQueue</filename>. This directory is scanned every few "
+"minutes by a daemon called <command>queued</command>, <filename>*.command</"
+"filename>-files are executed, and remaining and correctly signed <filename>*."
+"changes</filename>-files are moved together with their corresponding files "
+"to the <filename>unchecked</filename> directory. This directory is not "
+"visible for most Developers, as ftp-master is restricted; it is scanned "
+"every 15 minutes by the <command>katie</command> 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 "
+"<filename>accepted</filename> directory. If this is the first upload of the "
+"package (or it has new binary packages), it is moved to the <filename>new</"
+"filename> directory, where it waits for approval by the ftpmasters. If the "
+"package contains files to be installed by hand it is moved to the "
+"<filename>byhand</filename> directory, where it waits for manual "
+"installation by the ftpmasters. Otherwise, if any error has been detected, "
+"the package is refused and is moved to the <filename>reject</filename> "
+"directory."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:875
+msgid ""
+"Once the package is accepted, the system sends a confirmation mail to the "
+"maintainer and closes all the bugs marked as fixed by the upload, and the "
+"auto-builders may start recompiling it. The package is now publicly "
+"accessible at <ulink url=\"&url-incoming;\"></ulink> until it is really "
+"installed in the Debian archive. This happens only once a day (and is also "
+"called the `dinstall run' for historical reasons); the package is then "
+"removed from incoming and installed in the pool along with all the other "
+"packages. Once all the other updates (generating new <filename>Packages</"
+"filename> and <filename>Sources</filename> index files for example) have "
+"been made, a special script is called to ask all the primary mirrors to "
+"update themselves."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:887
+msgid ""
+"The archive maintenance software will also send the OpenPGP/GnuPG signed "
+"<filename>.changes</filename> file that you uploaded to the appropriate "
+"mailing lists. If a package is released with the <literal>Distribution:</"
+"literal> set to `stable', the announcement is sent to &email-debian-"
+"changes;. If a package is released with <literal>Distribution:</literal> "
+"set to `unstable' or `experimental', the announcement will be posted to "
+"&email-debian-devel-changes; instead."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:897
+msgid ""
+"Though ftp-master is restricted, a copy of the installation is available to "
+"all developers on <literal>&ftp-master-mirror;</literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: resources.dbk:960
+msgid "Package information"
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:962
+msgid "On the web"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:964
+msgid ""
+"Each package has several dedicated web pages. <literal>http://&packages-"
+"host;/<replaceable>package-name</replaceable></literal> displays each "
+"version of the package available in the various distributions. Each version "
+"links to a page which provides information, including the package "
+"description, the dependencies, and package download links."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:971
+msgid ""
+"The bug tracking system tracks bugs for each package. You can view the bugs "
+"of a given package at the URL <literal>http://&bugs-host;/"
+"<replaceable>package-name</replaceable></literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:978
+msgid "The <command>madison</command> utility"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:980
+msgid ""
+"<command>madison</command> is a command-line utility that is available on "
+"<literal>&ftp-master-host;</literal>, and on the mirror on <literal>&ftp-"
+"master-mirror;</literal>. It uses a single argument corresponding to a "
+"package name. In result it displays which version of the package is "
+"available for each architecture and distribution combination. An example "
+"will explain it better."
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: resources.dbk:988
+#, no-wrap
+msgid ""
+"$ madison libdbd-mysql-perl\n"
+"libdbd-mysql-perl | 1.2202-4 | stable | source, alpha, arm, i386, m68k, powerpc, sparc\n"
+"libdbd-mysql-perl | 1.2216-2 | testing | source, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc\n"
+"libdbd-mysql-perl | 1.2216-2.0.1 | testing | alpha\n"
+"libdbd-mysql-perl | 1.2219-1 | unstable | source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:995
+msgid ""
+"In this example, you can see that the version in <emphasis>unstable</"
+"emphasis> differs from the version in <emphasis>testing</emphasis> and that "
+"there has been a binary-only NMU of the package for the alpha architecture. "
+"Each version of the package has been recompiled on most of the architectures."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: resources.dbk:1005
+msgid "The Package Tracking System"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:1007
+msgid ""
+"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."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:1012
+msgid ""
+"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."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:1016
+msgid "By default you will get:"
+msgstr ""
+
+# type: Content of: <chapter><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1023
+msgid "All the bug reports and following discussions."
+msgstr ""
+
+# type: Content of: <chapter><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1031
+msgid ""
+"The email notifications from <email>control@&bugs-host;</email> about bug "
+"report status changes."
+msgstr ""
+
+# type: Content of: <chapter><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1040
+msgid ""
+"The email notification from <command>katie</command> when an uploaded source "
+"package is accepted."
+msgstr ""
+
+# type: Content of: <chapter><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1049
+msgid ""
+"Other warning and error emails from <command>katie</command> (such as an "
+"override disparity for the section and/or the priority field)."
+msgstr ""
+
+# type: Content of: <chapter><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1058
+msgid ""
+"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 "
+"<literal><replaceable>sourcepackage</replaceable>@&pts-host;</literal>. In "
+"order to prevent spam, all messages sent to these addresses must contain the "
+"<literal>X-PTS-Approved</literal> header with a non-empty value."
+msgstr ""
+
+# type: Content of: <chapter><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1070
+msgid ""
+"Regular summary emails about the package's status. Currently, only "
+"progression in <emphasis>testing</emphasis> is sent."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:1077
+msgid "You can also decide to receive additional information:"
+msgstr ""
+
+# type: Content of: <chapter><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1084
+msgid ""
+"The email notification from <command>katie</command> 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."
+msgstr ""
+
+# type: Content of: <chapter><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1095
+msgid ""
+"CVS commit notifications, if the package has a CVS repository and the "
+"maintainer has set up forwarding commit notifications to the PTS."
+msgstr ""
+
+# type: Content of: <chapter><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1104
+msgid ""
+"Translations of descriptions or debconf templates submitted to the Debian "
+"Description Translation Project."
+msgstr ""
+
+# type: Content of: <chapter><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1113
+msgid ""
+"Information about changes made to the package in derivative distributions "
+"(for example Ubuntu)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:1120
+msgid "The PTS email interface"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:1122
+msgid ""
+"You can control your subscription(s) to the PTS by sending various commands "
+"to <email>pts@qa.debian.org</email>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1130
+msgid ""
+"Subscribes <replaceable>email</replaceable> to communications related to the "
+"source package <replaceable>sourcepackage</replaceable>. Sender address is "
+"used if the second argument is not present. If <replaceable>sourcepackage</"
+"replaceable> 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."
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1143
+msgid ""
+"Removes a previous subscription to the source package "
+"<replaceable>sourcepackage</replaceable> using the specified email address "
+"or the sender address if the second argument is left out."
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1153
+msgid ""
+"Removes all subscriptions of the specified email address or the sender "
+"address if the second argument is left out."
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1162
+msgid ""
+"Lists all subscriptions for the sender or the email address optionally "
+"specified."
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1171
+msgid ""
+"Tells you the keywords that you are accepting. For an explanation of "
+"keywords, <link linkend=\"pkg-tracking-system\">see above</link>. Here's a "
+"quick summary:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><itemizedlist><listitem><para>
+#: resources.dbk:1178
+msgid ""
+"<literal>bts</literal>: mails coming from the Debian Bug Tracking System"
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><itemizedlist><listitem><para>
+#: resources.dbk:1183
+msgid ""
+"<literal>bts-control</literal>: reply to mails sent to &email-bts-control;"
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><itemizedlist><listitem><para>
+#: resources.dbk:1189
+msgid ""
+"<literal>summary</literal>: automatic summary mails about the state of a "
+"package"
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><itemizedlist><listitem><para>
+#: resources.dbk:1195
+msgid "<literal>cvs</literal>: notification of CVS commits"
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><itemizedlist><listitem><para>
+#: resources.dbk:1200
+msgid ""
+"<literal>ddtp</literal>: translations of descriptions and debconf templates"
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><itemizedlist><listitem><para>
+#: resources.dbk:1205
+msgid ""
+"<literal>derivatives</literal>: changes made on the package by derivative "
+"distributions"
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><itemizedlist><listitem><para>
+#: resources.dbk:1211
+msgid ""
+"<literal>upload-source</literal>: announce of a new source upload that has "
+"been accepted"
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><itemizedlist><listitem><para>
+#: resources.dbk:1217
+msgid ""
+"<literal>upload-binary</literal>: announce of a new binary-only upload "
+"(porting)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><itemizedlist><listitem><para>
+#: resources.dbk:1223
+msgid ""
+"<literal>katie-other</literal>: other mails from ftpmasters (override "
+"disparity, etc.)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><itemizedlist><listitem><para>
+#: resources.dbk:1229
+msgid ""
+"<literal>default</literal>: all the other mails (those which aren't "
+"automatic)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1239
+msgid ""
+"Same as the previous item but for the given source package, since you may "
+"select a different set of keywords for each source package."
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1248
+msgid ""
+"Accept (+) or refuse (-) mails classified under the given keyword(s). "
+"Define the list (=) of accepted keywords. This changes the default set of "
+"keywords accepted by a user."
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1258
+msgid ""
+"Accept (+) or refuse (-) mails classified under the given keyword(s). "
+"Define the list (=) of accepted keywords. This changes the set of accepted "
+"keywords of all the currently active subscriptions of a user."
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1268
+msgid ""
+"Same as previous item but overrides the keywords list for the indicated "
+"source package."
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1277
+msgid "Stops processing commands. All following lines are ignored by the bot."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:1283
+msgid ""
+"The <command>pts-subscribe</command> command-line utility (from the "
+"<systemitem role=\"package\">devscripts</systemitem> package) can be handy "
+"to temporarily subscribe to some packages, for example after having made an "
+"non-maintainer upload."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:1291
+msgid "Filtering PTS mails"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:1293
+msgid ""
+"Once you are subscribed to a package, you will get the mails sent to "
+"<literal><replaceable>sourcepackage</replaceable>@&pts-host;</literal>. "
+"Those mails have special headers appended to let you filter them in a "
+"special mailbox (e.g. with <command>procmail</command>). The added headers "
+"are <literal>X-Loop</literal>, <literal>X-PTS-Package</literal>, <literal>X-"
+"PTS-Keyword</literal> and <literal>X-Unsubscribe</literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:1301
+msgid ""
+"Here is an example of added headers for a source upload notification on the "
+"<systemitem role=\"package\">dpkg</systemitem> package:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: resources.dbk:1305
+#, no-wrap
+msgid ""
+"X-Loop: dpkg@&pts-host;\n"
+"X-PTS-Package: dpkg\n"
+"X-PTS-Keyword: upload-source\n"
+"X-Unsubscribe: echo 'unsubscribe dpkg' | mail pts@qa.debian.org"
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:1313
+msgid "Forwarding CVS commits in the PTS"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:1315
+msgid ""
+"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 (and possible co-maintainers) can closely follow the "
+"package's evolution."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:1321
+msgid ""
+"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 "
+"<literal><replaceable>sourcepackage</replaceable>_cvs@&pts-host;</literal>. "
+"Only the people who accept the <emphasis>cvs</emphasis> keyword will receive "
+"these notifications."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:1330
+msgid "The PTS web interface"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:1332
+msgid ""
+"The PTS has a web interface at <ulink url=\"http://&pts-host;/\"></ulink> "
+"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 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 allows easy subscription to the "
+"PTS via email."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:1342
+msgid ""
+"You can jump directly to the web page concerning a specific source package "
+"with a URL like <literal>http://&pts-host;/<replaceable>sourcepackage</"
+"replaceable></literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:1347
+msgid ""
+"This web interface has been designed like a portal for the development of "
+"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."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:1353
+msgid "Static news items can be used to indicate:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: resources.dbk:1358
+msgid ""
+"the availability of a project hosted on <link linkend=\"alioth\">Alioth</"
+"link> for co-maintaining the package"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: resources.dbk:1364
+msgid "a link to the upstream web site"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: resources.dbk:1369
+msgid "a link to the upstream bug tracker"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: resources.dbk:1374
+msgid "the existence of an IRC channel dedicated to the software"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: resources.dbk:1379
+msgid ""
+"any other available resource that could be useful in the maintenance of the "
+"package"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:1385
+msgid "Usual news items may be used to announce that:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: resources.dbk:1390
+msgid "beta packages are available for testing"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: resources.dbk:1395
+msgid "final packages are expected for next week"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: resources.dbk:1400
+msgid "the packaging is about to be redone from scratch"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: resources.dbk:1405
+msgid "backports are available"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: resources.dbk:1410
+msgid ""
+"the maintainer is on vacation (if they wish to publish this information)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: resources.dbk:1415
+msgid "a NMU is being worked on"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: resources.dbk:1420
+msgid "something important will affect the package"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:1425
+msgid ""
+"Both kinds of news are generated in a similar manner: you just have to send "
+"an email either to <email>pts-static-news@qa.debian.org</email> or to "
+"<email>pts-news@qa.debian.org</email>. The mail should indicate which "
+"package is concerned by having the name of the source package in a "
+"<literal>X-PTS-Package</literal> mail header or in a <literal>Package</"
+"literal> pseudo-header (like the BTS reports). If a URL is available in the "
+"<literal>X-PTS-Url</literal> mail header or in the <literal>Url</literal> "
+"pseudo-header, then the result is a link to that URL instead of a complete "
+"news item."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:1436
+msgid ""
+"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:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: resources.dbk:1441
+#, no-wrap
+msgid ""
+"From: Raphael Hertzog <hertzog@debian.org>\n"
+"To: pts-static-news@qa.debian.org\n"
+"Subject: Browse debian-cd CVS repository with cvsweb\n"
+"\n"
+"Package: debian-cd\n"
+"Url: &url-cvsweb;debian-cd/"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:1449
+msgid ""
+"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."
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: resources.dbk:1454
+#, no-wrap
+msgid ""
+": Raphael Hertzog <hertzog@debian.org>\n"
+"To: debian-gtk-gnome@&lists-host;\n"
+"Bcc: pts-news@qa.debian.org\n"
+"Subject: Galeon 2.0 backported for woody\n"
+"X-PTS-Package: galeon\n"
+"\n"
+"Hello gnomers!\n"
+"\n"
+"I'm glad to announce that galeon has been backported for woody. You'll find\n"
+"everything here:\n"
+"..."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:1467
+msgid ""
+"Think twice before adding a news item to the PTS because you won't be able "
+"to remove it later and you won'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."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: resources.dbk:1477
+msgid "Developer's packages overview"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:1479
+msgid ""
+"A QA (quality assurance) web portal is available at <ulink url=\"&url-ddpo;"
+"\"></ulink> which displays a table listing all the packages of a single "
+"developer (including those where the party is listed as a co-maintainer). "
+"The table gives a good summary about the developer's packages: number of "
+"bugs by severity, list of available versions in each distribution, testing "
+"status and much more including links to any other useful information."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:1488
+msgid ""
+"It is a good idea to look up your own data regularly so that you don't "
+"forget any open bugs, and so that you don't forget which packages are your "
+"responsibility."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: resources.dbk:1495
+msgid "Debian *Forge: Alioth"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:1497
+msgid ""
+"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."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:1504
+msgid ""
+"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."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:1510
+msgid ""
+"All Debian developers automatically have an account on Alioth. They can "
+"activate it by using the recover password facility. External developers can "
+"request guest accounts on Alioth."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:1515
+msgid "For more information please visit <ulink url=\"&url-alioth;\"></ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: resources.dbk:1521
+msgid "Goodies for Developers"
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:1523
+msgid "LWN Subscriptions"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:1525
+msgid ""
+"Since October of 2002, HP has sponsored a subscription to LWN for all "
+"interested Debian developers. Details on how to get access to this benefit "
+"are in <ulink url=\"http://&lists-host;/debian-devel-announce/2002/10/"
+"msg00018.html\"></ulink>."
+msgstr ""
--- /dev/null
+# Debian Developer's Reference (Japanese)
+# 遠藤 美純, 1999
+# Hideki Yamane (Debian-JP) <henrich@debian.or.jp>, 2007.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: developers-reference _VERSION_\n"
+"Report-Msgid-Bugs-To: \n"
+"POT-Creation-Date: 2007-07-01 21:18+0000\n"
+"PO-Revision-Date: 2007-07-16 20:04+0000\n"
+"Last-Translator: Hideki Yamane (Debian-JP) <henrich@debian.or.jp>\n"
+"Language-Team: Debian JP Project <debian-doc@debian.or.jp>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+# type: Content of: <chapter><title>
+#: scope.dbk:7
+msgid "Scope of This Document"
+msgstr "この文書が扱う範囲について"
+
+# type: Content of: <chapter><para>
+#: scope.dbk:9
+msgid ""
+"The purpose of this document is to provide an overview of the recommended "
+"procedures and the available resources for Debian developers."
+msgstr ""
+"この文書の目的は、Debian 開発者に推奨される手続きと利用可能なリソースに"
+"関する概要を提供することにあります。"
+
+# type: Content of: <chapter><para>
+#: scope.dbk:14
+msgid ""
+"The procedures discussed within include how to become a maintainer (<xref "
+"linkend=\"new-maintainer\"/> ); how to create new packages (<xref linkend="
+"\"newpackage\"/> ) and how to upload packages (<xref linkend=\"upload\"/> ); "
+"how to handle bug reports (<xref linkend=\"bug-handling\"/> ); how to move, "
+"remove, or orphan packages (<xref linkend=\"archive-manip\"/> ); how to port "
+"packages (<xref linkend=\"porting\"/> ); and how and when to do interim "
+"releases of other maintainers' packages (<xref linkend=\"nmu\"/> )."
+msgstr ""
+"ここで取り上げる手続きには、"
+"開発者になる方法 (<xref linkend=\"new-maintainer\"/>) 、"
+"新しいパッケージの作り方 (<xref linkend=\"newpackage\"/> ) とパッケージを"
+"アップロードする方法 (<xref linkend=\"upload\"/>)、"
+"バグ報告の取扱い方 (<xref linkend=\"bug-handling\"/> )、"
+"パッケージを移動、削除、みなしご化 (orphan) する方法 "
+"(<xref linkend=\"archive-manip\"/>)、"
+"パッケージ移植のやり方 (<xref linkend=\"porting\"/> )"
+"他のメンテナのパッケージを暫定的にリリースするのは、いつどの様にしたらよいのか "
+"(<xref linkend=\"nmu\"/>) が含まれます。"
+
+# type: Content of: <chapter><para>
+#: scope.dbk:23
+msgid ""
+"The resources discussed in this reference include the mailing lists (<xref "
+"linkend=\"mailing-lists\"/> ) and servers (<xref linkend=\"server-machines\"/"
+"> ); a discussion of the structure of the Debian archive (<xref linkend="
+"\"archive\"/> ); explanation of the different servers which accept package "
+"uploads (<xref linkend=\"upload-ftp-master\"/> ); and a discussion of "
+"resources which can help maintainers with the quality of their packages "
+"(<xref linkend=\"tools\"/> )."
+msgstr ""
+"また、このリファレンスで触れるリソースには、"
+"メーリングリスト (<xref linkend=\"mailing-lists\"/>) およびサーバ "
+"(<xref linkend=\"server-machines\"/> )、"
+"Debian アーカイブの構成に関する解説 (<xref linkend=\"archive\"/>)、"
+"パッケージのアップロードを受け付ける様々なサーバの説明 "
+"(<xref linkend=\"upload-ftp-master\"/>)、"
+"パッケージの品質を高めるために開発者が利用できるリソースについての解説 "
+"(<xref linkend=\"tools\"/>) などがあります。"
+
+# type: Content of: <chapter><para>
+#: scope.dbk:31
+msgid ""
+"It should be clear that this reference does not discuss the technical "
+"details of Debian packages nor how to generate them. Nor does this "
+"reference detail the standards to which Debian software must comply. All of "
+"such information can be found in the <ulink url=\"&url-debian-policy;"
+"\">Debian Policy Manual</ulink>."
+msgstr ""
+"初めに明らかにしておきたいのですが、このリファレンスは Debian パッケージに"
+"関する技術的な詳細や、Debian パッケージの作成方法を説明するものではありません。"
+"また、このリファレンスは Debian に含まれるソフトウェアが準拠すべき基準を詳細に"
+"解説するようなものでもありません。"
+"その様な情報については全て、<ulink url=\"&url-debian-policy;\">Debian "
+"ポリシーマニュアル</ulink> に記述されています。"
+
+# type: Content of: <chapter><para>
+#: scope.dbk:38
+msgid ""
+"Furthermore, this document is <emphasis>not an expression of formal policy</"
+"emphasis>. It contains documentation for the Debian system and generally "
+"agreed-upon best practices. Thus, it is not what is called a ``normative'' "
+"document."
+msgstr ""
+"さらに、この文書は<emphasis>公式なポリシーを明らかにするものではありません"
+"</emphasis>。含まれているのは Debian システムに関する記述と、一般的な合意が"
+"なされたベストプラクティスに関する記述です。"
+"すなわち「規範」文書と呼ばれるものではない、ということです。"
+
--- /dev/null
+# SOME DESCRIPTIVE TITLE
+# Copyright (C) YEAR Free Software Foundation, Inc.
+# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
+#
+#, fuzzy
+msgid ""
+msgstr ""
+"Project-Id-Version: PACKAGE VERSION\n"
+"POT-Creation-Date: 2007-07-01 21:18+0000\n"
+"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
+"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
+"Language-Team: LANGUAGE <LL@li.org>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: ENCODING\n"
+
+# type: Content of: <appendix><title>
+#: tools.dbk:7
+msgid "Overview of Debian Maintainer Tools"
+msgstr ""
+
+# type: Content of: <appendix><para>
+#: tools.dbk:9
+msgid ""
+"This section contains a rough overview of the tools available to "
+"maintainers. The following is by no means complete or definitive, but just "
+"a guide to some of the more popular tools."
+msgstr ""
+
+# type: Content of: <appendix><para>
+#: tools.dbk:14
+msgid ""
+"Debian maintainer tools are meant to aid developers and free their time for "
+"critical tasks. As Larry Wall says, there's more than one way to do it."
+msgstr ""
+
+# type: Content of: <appendix><para>
+#: tools.dbk:18
+msgid ""
+"Some people prefer to use high-level package maintenance tools and some do "
+"not. Debian is officially agnostic on this issue; any tool which gets the "
+"job done is fine. Therefore, this section is not meant to stipulate to "
+"anyone which tools they should use or how they should go about their duties "
+"of maintainership. Nor is it meant to endorse any particular tool to the "
+"exclusion of a competing tool."
+msgstr ""
+
+# type: Content of: <appendix><para>
+#: tools.dbk:26
+msgid ""
+"Most of the descriptions of these packages come from the actual package "
+"descriptions themselves. Further information can be found in the package "
+"documentation itself. You can also see more info with the command "
+"<command>apt-cache show <package-name></command>."
+msgstr ""
+
+# type: Content of: <appendix><section><title>
+#: tools.dbk:32
+msgid "Core tools"
+msgstr ""
+
+# type: Content of: <appendix><section><para>
+#: tools.dbk:34
+msgid "The following tools are pretty much required for any maintainer."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:39
+msgid ""
+"<systemitem role=\"package\">dpkg-dev</systemitem> contains the tools "
+"(including <command>dpkg-source</command>) required to unpack, build, and "
+"upload Debian source packages. These utilities contain the fundamental, low-"
+"level functionality required to create and manipulate packages; as such, "
+"they are essential for any Debian maintainer."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:50
+msgid ""
+"<systemitem role=\"package\">debconf</systemitem> provides a consistent "
+"interface to configuring packages interactively. It is user interface "
+"independent, allowing end-users to configure packages with a text-only "
+"interface, an HTML interface, or a dialog interface. New interfaces can be "
+"added as modules."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:56
+msgid ""
+"You can find documentation for this package in the <systemitem role=\"package"
+"\">debconf-doc</systemitem> package."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:60
+msgid ""
+"Many feel that this system should be used for all packages which require "
+"interactive configuration; see <xref linkend=\"bpp-config-mgmt\"/> . "
+"<systemitem role=\"package\">debconf</systemitem> is not currently required "
+"by Debian Policy, but that may change in the future."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:70
+msgid ""
+"<systemitem role=\"package\">fakeroot</systemitem> simulates root "
+"privileges. This enables you to build packages without being root (packages "
+"usually want to install files with root ownership). If you have <systemitem "
+"role=\"package\">fakeroot</systemitem> installed, you can build packages as "
+"a regular user: <literal>dpkg-buildpackage -rfakeroot</literal>."
+msgstr ""
+
+# type: Content of: <appendix><section><title>
+#: tools.dbk:81
+msgid "Package lint tools"
+msgstr ""
+
+# type: Content of: <appendix><section><para>
+#: tools.dbk:83
+msgid ""
+"According to the Free On-line Dictionary of Computing (FOLDOC), `lint' is a "
+"Unix C language processor which carries out more thorough checks on the code "
+"than is usual with C compilers. Package lint tools help package maintainers "
+"by automatically finding common problems and policy violations in their "
+"packages."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:91
+msgid ""
+"<systemitem role=\"package\">lintian</systemitem> dissects Debian packages "
+"and emits information about bugs and policy violations. It contains "
+"automated checks for many aspects of Debian policy as well as some checks "
+"for common errors."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:97
+msgid ""
+"You should periodically get the newest <systemitem role=\"package\">lintian</"
+"systemitem> from `unstable' and check over all your packages. Notice that "
+"the <literal>-i</literal> option provides detailed explanations of what each "
+"error or warning means, what its basis in Policy is, and commonly how you "
+"can fix the problem."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:104
+msgid ""
+"Refer to <xref linkend=\"sanitycheck\"/> for more information on how and "
+"when to use Lintian."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:108
+msgid ""
+"You can also see a summary of all problems reported by Lintian on your "
+"packages at <ulink url=\"&url-lintian;\"></ulink>. These reports contain "
+"the latest <command>lintian</command> output for the whole development "
+"distribution (unstable)."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:118
+msgid ""
+"<systemitem role=\"package\">linda</systemitem> is another package linter. "
+"It is similar to <systemitem role=\"package\">lintian</systemitem> but has a "
+"different set of checks. Its written in Python rather than Perl."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:127
+msgid ""
+"<command>debdiff</command> (from the <systemitem role=\"package"
+"\">devscripts</systemitem> package, <xref linkend=\"devscripts\"/> ) "
+"compares file lists and control files of two packages. It is a simple "
+"regression test, as it will help you notice if the number of binary packages "
+"has changed since the last upload, or if something has changed in the "
+"control file. Of course, some of the changes it reports will be all right, "
+"but it can help you prevent various accidents."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:136
+msgid "You can run it over a pair of binary packages:"
+msgstr ""
+
+# type: Content of: <appendix><section><section><screen>
+#: tools.dbk:139
+#, no-wrap
+msgid "debdiff package_1-1_arch.deb package_2-1_arch.deb"
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:142
+msgid "Or even a pair of changes files:"
+msgstr ""
+
+# type: Content of: <appendix><section><section><screen>
+#: tools.dbk:145
+#, no-wrap
+msgid "debdiff package_1-1_arch.changes package_2-1_arch.changes"
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:148
+msgid ""
+"For more information please see <citerefentry> <refentrytitle>debdiff</"
+"refentrytitle> <manvolnum>1</manvolnum> </citerefentry>."
+msgstr ""
+
+# type: Content of: <appendix><section><title>
+#: tools.dbk:157
+msgid "Helpers for <filename>debian/rules</filename>"
+msgstr ""
+
+# type: Content of: <appendix><section><para>
+#: tools.dbk:159
+msgid ""
+"Package building tools make the process of writing <filename>debian/rules</"
+"filename> files easier. See <xref linkend=\"helper-scripts\"/> for more "
+"information about why these might or might not be desired."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:167
+msgid ""
+"<systemitem role=\"package\">debhelper</systemitem> is a collection of "
+"programs which can be used in <filename>debian/rules</filename> to automate "
+"common tasks related to building binary Debian packages. <systemitem role="
+"\"package\">debhelper</systemitem> includes programs to install various "
+"files into your package, compress files, fix file permissions, and integrate "
+"your package with the Debian menu system."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:175
+msgid ""
+"Unlike some approaches, <systemitem role=\"package\">debhelper</systemitem> "
+"is broken into several small, simple commands which act in a consistent "
+"manner. As such, it allows more fine-grained control than some of the other "
+"debian/rules tools."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:181
+msgid ""
+"There are a number of little <systemitem role=\"package\">debhelper</"
+"systemitem> add-on packages, too transient to document. You can see the "
+"list of most of them by doing <literal>apt-cache search ^dh-</literal>."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:190
+msgid ""
+"<systemitem role=\"package\">debmake</systemitem>, a precursor to "
+"<systemitem role=\"package\">debhelper</systemitem>, is a more coarse-"
+"grained <filename>debian/rules</filename> assistant. It includes two main "
+"programs: <command>deb-make</command>, which can be used to help a "
+"maintainer convert a regular (non-Debian) source archive into a Debian "
+"source package; and <command>debstd</command>, which incorporates in one big "
+"shot the same sort of automated functions that one finds in <systemitem role="
+"\"package\">debhelper</systemitem>."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:200
+msgid ""
+"The consensus is that <systemitem role=\"package\">debmake</systemitem> is "
+"now deprecated in favor of <systemitem role=\"package\">debhelper</"
+"systemitem>. It is a bug to use <systemitem role=\"package\">debmake</"
+"systemitem> in new packages. New packages using <systemitem role=\"package"
+"\">debmake</systemitem> will be rejected from the archive."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:211
+msgid ""
+"The <systemitem role=\"package\">dh-make</systemitem> package contains "
+"<command>dh_make</command>, a program that creates a skeleton of files "
+"necessary to build a Debian package out of a source tree. As the name "
+"suggests, <command>dh_make</command> is a rewrite of <systemitem role="
+"\"package\">debmake</systemitem> and its template files use dh_* programs "
+"from <systemitem role=\"package\">debhelper</systemitem>."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:219
+msgid ""
+"While the rules files generated by <command>dh_make</command> are in general "
+"a sufficient basis for a working package, they are still just the "
+"groundwork: the burden still lies on the maintainer to finely tune the "
+"generated files and make the package entirely functional and Policy-"
+"compliant."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:229
+msgid ""
+"<systemitem role=\"package\">yada</systemitem> is another packaging helper "
+"tool. It uses a <filename>debian/packages</filename> file to auto-generate "
+"<filename>debian/rules</filename> and other necessary files in the "
+"<filename>debian/</filename> subdirectory. The <filename>debian/packages</"
+"filename> file contains instruction to build packages and there is no need "
+"to create any <filename>Makefile</filename> files. There is possibility to "
+"use macro engine similar to the one used in SPECS files from RPM source "
+"packages."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:239
+msgid ""
+"For more informations see <literal><ulink url=\"http://yada.alioth.debian."
+"org/\">YADA site</ulink></literal>."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:247
+msgid ""
+"<systemitem role=\"package\">equivs</systemitem> is another package for "
+"making packages. It is often suggested for local use if you need to make a "
+"package simply to fulfill dependencies. It is also sometimes used when "
+"making ``meta-packages'', which are packages whose only purpose is to depend "
+"on other packages."
+msgstr ""
+
+# type: Content of: <appendix><section><title>
+#: tools.dbk:258
+msgid "Package builders"
+msgstr ""
+
+# type: Content of: <appendix><section><para>
+#: tools.dbk:260
+msgid ""
+"The following packages help with the package building process, general "
+"driving <command>dpkg-buildpackage</command> as well as handling supporting "
+"tasks."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:266
+msgid ""
+"<systemitem role=\"package\">cvs-buildpackage</systemitem> provides the "
+"capability to inject or import Debian source packages into a CVS repository, "
+"build a Debian package from the CVS repository, and helps in integrating "
+"upstream changes into the repository."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:272
+msgid ""
+"These utilities provide an infrastructure to facilitate the use of CVS by "
+"Debian maintainers. This allows one to keep separate CVS branches of a "
+"package for <emphasis>stable</emphasis>, <emphasis>unstable</emphasis> and "
+"possibly <emphasis>experimental</emphasis> distributions, along with the "
+"other benefits of a version control system."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:283
+msgid ""
+"The <systemitem role=\"package\">debootstrap</systemitem> package and script "
+"allows you to bootstrap a Debian base system into any part of your "
+"filesystem. By base system, we mean the bare minimum of packages required "
+"to operate and install the rest of the system."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:289
+msgid ""
+"Having a system like this can be useful in many ways. For instance, you can "
+"<command>chroot</command> into it if you want to test your build "
+"dependencies. Or you can test how your package behaves when installed into "
+"a bare base system. Chroot builders use this package; see below."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:299
+msgid ""
+"<systemitem role=\"package\">pbuilder</systemitem> constructs a chrooted "
+"system, and builds a package inside the chroot. It is very useful to check "
+"that a package's build-dependencies are correct, and to be sure that "
+"unnecessary and wrong build dependencies will not exist in the resulting "
+"package."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:305
+msgid ""
+"A related package is <systemitem role=\"package\">pbuilder-uml</systemitem>, "
+"which goes even further by doing the build within a User Mode Linux "
+"environment."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:314
+msgid ""
+"<systemitem role=\"package\">sbuild</systemitem> is another automated "
+"builder. It can use chrooted environments as well. It can be used stand-"
+"alone, or as part of a networked, distributed build environment. As the "
+"latter, it is part of the system used by porters to build binary packages "
+"for all the available architectures. See <xref linkend=\"buildd\"/> for "
+"more information, and <ulink url=\"&url-buildd;\"></ulink> to see the system "
+"in action."
+msgstr ""
+
+# type: Content of: <appendix><section><title>
+#: tools.dbk:326
+msgid "Package uploaders"
+msgstr ""
+
+# type: Content of: <appendix><section><para>
+#: tools.dbk:328
+msgid ""
+"The following packages help automate or simplify the process of uploading "
+"packages into the official archive."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:334
+msgid ""
+"<systemitem role=\"package\">dupload</systemitem> is a package and a script "
+"to automatically upload Debian packages to the Debian archive, to log the "
+"upload, and to send mail about the upload of a package. You can configure "
+"it for new upload locations or methods."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:344
+msgid ""
+"The <systemitem role=\"package\">dput</systemitem> package and script does "
+"much the same thing as <systemitem role=\"package\">dupload</systemitem>, "
+"but in a different way. It has some features over <systemitem role=\"package"
+"\">dupload</systemitem>, such as the ability to check the GnuPG signature "
+"and checksums before uploading, and the possibility of running "
+"<command>dinstall</command> in dry-run mode after the upload."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:356
+msgid ""
+"The <systemitem role=\"package\">dcut</systemitem> script (part of the "
+"package <xref linkend=\"dput\"/> ) helps in removing files from the ftp "
+"upload directory."
+msgstr ""
+
+# type: Content of: <appendix><section><title>
+#: tools.dbk:364
+msgid "Maintenance automation"
+msgstr ""
+
+# type: Content of: <appendix><section><para>
+#: tools.dbk:366
+msgid ""
+"The following tools help automate different maintenance tasks, from adding "
+"changelog entries or signature lines and looking up bugs in Emacs to making "
+"use of the newest and official <filename>config.sub</filename>."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:373
+msgid ""
+"<systemitem role=\"package\">devscripts</systemitem> is a package containing "
+"wrappers and tools which are very helpful for maintaining your Debian "
+"packages. Example scripts include <command>debchange</command> and "
+"<command>dch</command>, which manipulate your <filename>debian/changelog</"
+"filename> file from the command-line, and <command>debuild</command>, which "
+"is a wrapper around <command>dpkg-buildpackage</command>. The <command>bts</"
+"command> utility is also very helpful to update the state of bug reports on "
+"the command line. <command>uscan</command> can be used to watch for new "
+"upstream versions of your packages. <command>debrsign</command> can be used "
+"to remotely sign a package prior to upload, which is nice when the machine "
+"you build the package on is different from where your GPG keys are."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:387
+msgid ""
+"See the <citerefentry> <refentrytitle>devscripts</refentrytitle> "
+"<manvolnum>1</manvolnum> </citerefentry> manual page for a complete list of "
+"available scripts."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:396
+msgid ""
+"<systemitem role=\"package\">autotools-dev</systemitem> contains best "
+"practices for people who maintain packages which use <command>autoconf</"
+"command> and/or <command>automake</command>. Also contains canonical "
+"<filename>config.sub</filename> and <filename>config.guess</filename> files "
+"which are known to work on all Debian ports."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:407
+msgid ""
+"<command>dpkg-repack</command> creates Debian package file out of a package "
+"that has already been installed. If any changes have been made to the "
+"package while it was unpacked (e.g., files in <filename>/etc</filename> were "
+"modified), the new package will inherit the changes."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:413
+msgid ""
+"This utility can make it easy to copy packages from one computer to another, "
+"or to recreate packages which are installed on your system but no longer "
+"available elsewhere, or to save the current state of a package before you "
+"upgrade it."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:422
+msgid ""
+"<command>alien</command> converts binary packages between various packaging "
+"formats, including Debian, RPM (RedHat), LSB (Linux Standard Base), Solaris, "
+"and Slackware packages."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:431
+msgid ""
+"<command>debsums</command> checks installed packages against their MD5 "
+"sums. Note that not all packages have MD5 sums, since they aren't required "
+"by Policy."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:439
+msgid ""
+"<systemitem role=\"package\">dpkg-dev-el</systemitem> is an Emacs lisp "
+"package which provides assistance when editing some of the files in the "
+"<filename>debian</filename> directory of your package. For instance, there "
+"are handy functions for listing a package's current bugs, and for finalizing "
+"the latest entry in a <filename>debian/changelog</filename> file."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:450
+msgid ""
+"<command>dpkg-depcheck</command> (from the <systemitem role=\"package"
+"\">devscripts</systemitem> package, <xref linkend=\"devscripts\"/> ) runs a "
+"command under <command>strace</command> to determine all the packages that "
+"were used by the said command."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:456
+msgid ""
+"For Debian packages, this is useful when you have to compose a "
+"<literal>Build-Depends</literal> line for your new package: running the "
+"build process through <command>dpkg-depcheck</command> will provide you with "
+"a good first approximation of the build-dependencies. For example:"
+msgstr ""
+
+# type: Content of: <appendix><section><section><screen>
+#: tools.dbk:462
+#, no-wrap
+msgid "dpkg-depcheck -b debian/rules build"
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:465
+msgid ""
+"<command>dpkg-depcheck</command> can also be used to check for run-time "
+"dependencies, especially if your package uses exec(2) to run other programs."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:469
+msgid ""
+"For more information please see <citerefentry> <refentrytitle>dpkg-depcheck</"
+"refentrytitle> <manvolnum>1</manvolnum> </citerefentry>."
+msgstr ""
+
+# type: Content of: <appendix><section><title>
+#: tools.dbk:478
+msgid "Porting tools"
+msgstr ""
+
+# type: Content of: <appendix><section><para>
+#: tools.dbk:480
+msgid "The following tools are helpful for porters and for cross-compilation."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:485
+msgid ""
+"<systemitem role=\"package\">quinn-diff</systemitem> is used to locate the "
+"differences from one architecture to another. For instance, it could tell "
+"you which packages need to be ported for architecture <replaceable>Y</"
+"replaceable>, based on architecture <replaceable>X</replaceable>."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:495
+msgid ""
+"<systemitem role=\"package\">dpkg-cross</systemitem> is a tool for "
+"installing libraries and headers for cross-compiling in a way similar to "
+"<systemitem role=\"package\">dpkg</systemitem>. Furthermore, the "
+"functionality of <command>dpkg-buildpackage</command> and <command>dpkg-"
+"shlibdeps</command> is enhanced to support cross-compiling."
+msgstr ""
+
+# type: Content of: <appendix><section><title>
+#: tools.dbk:506
+msgid "Documentation and information"
+msgstr ""
+
+# type: Content of: <appendix><section><para>
+#: tools.dbk:508
+msgid ""
+"The following packages provide information for maintainers or help with "
+"building documentation."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:514
+msgid ""
+"<systemitem role=\"package\">debiandoc-sgml</systemitem> provides the "
+"DebianDoc SGML DTD, which is commonly used for Debian documentation. This "
+"manual, for instance, is written in DebianDoc. It also provides scripts for "
+"building and styling the source to various output formats."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:520
+msgid ""
+"Documentation for the DTD can be found in the <systemitem role=\"package"
+"\">debiandoc-sgml-doc</systemitem> package."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:544
+msgid ""
+"Contains the public GPG and PGP keys of Debian developers. See <xref "
+"linkend=\"key-maint\"/> and the package documentation for more information."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:552
+msgid ""
+"<systemitem role=\"package\">debview</systemitem> provides an Emacs mode for "
+"viewing Debian binary packages. This lets you examine a package without "
+"unpacking it."
+msgstr ""
--- /dev/null
+# SOME DESCRIPTIVE TITLE
+# Copyright (C) YEAR Free Software Foundation, Inc.
+# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
+#
+#, fuzzy
+msgid ""
+msgstr ""
+"Project-Id-Version: PACKAGE VERSION\n"
+"POT-Creation-Date: 2007-07-01 21:01+0000\n"
+"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
+"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
+"Language-Team: LANGUAGE <LL@li.org>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=utf-8\n"
+"Content-Transfer-Encoding: ENCODING"
+
+# type: Content of: <chapter><title>
+#: best-pkging-practices.dbk:7
+msgid "Best Packaging Practices"
+msgstr ""
+
+# type: Content of: <chapter><para>
+#: best-pkging-practices.dbk:9
+msgid ""
+"Debian's quality is largely due to the <ulink "
+"url=\"&url-debian-policy;\">Debian Policy</ulink>, which defines explicit "
+"baseline requirements which all Debian packages must fulfill. Yet there is "
+"also a shared history of experience which goes beyond the Debian Policy, an "
+"accumulation of years of experience in packaging. Many very talented people "
+"have created great tools, tools which help you, the Debian maintainer, "
+"create and maintain excellent packages."
+msgstr ""
+
+# type: Content of: <chapter><para>
+#: best-pkging-practices.dbk:18
+msgid ""
+"This chapter provides some best practices for Debian developers. All "
+"recommendations are merely that, and are not requirements or policy. These "
+"are just some subjective hints, advice and pointers collected from Debian "
+"developers. Feel free to pick and choose whatever works best for you."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: best-pkging-practices.dbk:24
+msgid "Best practices for <filename>debian/rules</filename>"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:26
+msgid ""
+"The following recommendations apply to the <filename>debian/rules</filename> "
+"file. Since <filename>debian/rules</filename> controls the build process "
+"and selects the files which go into the package (directly or indirectly), "
+"it's usually the file maintainers spend the most time on."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:32
+msgid "Helper scripts"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:34
+msgid ""
+"The rationale for using helper scripts in <filename>debian/rules</filename> "
+"is that they let maintainers use and share common logic among many "
+"packages. Take for instance the question of installing menu entries: you "
+"need to put the file into <filename>/usr/lib/menu</filename> (or "
+"<filename>/usr/lib/menu</filename> for executable binary menufiles, if this "
+"is needed), and add commands to the maintainer scripts to register and "
+"unregister the menu entries. Since this is a very common thing for packages "
+"to do, why should each maintainer rewrite all this on their own, sometimes "
+"with bugs? Also, supposing the menu directory changed, every package would "
+"have to be changed."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:45
+msgid ""
+"Helper scripts take care of these issues. Assuming you comply with the "
+"conventions expected by the helper script, the helper takes care of all the "
+"details. Changes in policy can be made in the helper script; then packages "
+"just need to be rebuilt with the new version of the helper and no other "
+"changes."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:52
+msgid ""
+"<xref linkend=\"tools\"/> contains a couple of different helpers. The most "
+"common and best (in our opinion) helper system is <systemitem "
+"role=\"package\">debhelper</systemitem>. Previous helper systems, such as "
+"<systemitem role=\"package\">debmake</systemitem>, were monolithic: you "
+"couldn't pick and choose which part of the helper you found useful, but had "
+"to use the helper to do everything. <systemitem "
+"role=\"package\">debhelper</systemitem>, however, is a number of separate "
+"little <command>dh_*</command> programs. For instance, "
+"<command>dh_installman</command> installs and compresses man pages, "
+"<command>dh_installmenu</command> installs menu files, and so on. Thus, it "
+"offers enough flexibility to be able to use the little helper scripts, where "
+"useful, in conjunction with hand-crafted commands in "
+"<filename>debian/rules</filename>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:66
+msgid ""
+"You can get started with <systemitem role=\"package\">debhelper</systemitem> "
+"by reading <citerefentry> <refentrytitle>debhelper</refentrytitle> "
+"<manvolnum>1</manvolnum> </citerefentry>, and looking at the examples that "
+"come with the package. <command>dh_make</command>, from the <systemitem "
+"role=\"package\">dh-make</systemitem> package (see <xref "
+"linkend=\"dh-make\"/> ), can be used to convert a vanilla source package to "
+"a <systemitem role=\"package\">debhelper</systemitem>ized package. This "
+"shortcut, though, should not convince you that you do not need to bother "
+"understanding the individual <command>dh_*</command> helpers. If you are "
+"going to use a helper, you do need to take the time to learn to use that "
+"helper, to learn its expectations and behavior."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:79
+msgid ""
+"Some people feel that vanilla <filename>debian/rules</filename> files are "
+"better, since you don't have to learn the intricacies of any helper system. "
+"This decision is completely up to you. Use what works for you. Many "
+"examples of vanilla <filename>debian/rules</filename> files are available at "
+"<ulink url=\"&url-rules-files;\"></ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:88
+msgid "Separating your patches into multiple files"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:90
+msgid ""
+"Big, complex packages may have many bugs that you need to deal with. If you "
+"correct a number of bugs directly in the source, and you're not careful, it "
+"can get hard to differentiate the various patches that you applied. It can "
+"get quite messy when you have to update the package to a new upstream "
+"version which integrates some of the fixes (but not all). You can't take "
+"the total set of diffs (e.g., from <filename>.diff.gz</filename>) and work "
+"out which patch sets to back out as a unit as bugs are fixed upstream."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:99
+msgid ""
+"Unfortunately, the packaging system as such currently doesn't provide for "
+"separating the patches into several files. Nevertheless, there are ways to "
+"separate patches: the patch files are shipped within the Debian patch file "
+"(<filename>.diff.gz</filename>), usually within the "
+"<filename>debian/</filename> directory. The only difference is that they "
+"aren't applied immediately by dpkg-source, but by the "
+"<literal>build</literal> rule of <filename>debian/rules</filename>. "
+"Conversely, they are reverted in the <literal>clean</literal> rule."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:109
+msgid ""
+"<command>dbs</command> is one of the more popular approaches to this. It "
+"does all of the above, and provides a facility for creating new and updating "
+"old patches. See the package <systemitem role=\"package\">dbs</systemitem> "
+"for more information and <systemitem role=\"package\">hello-dbs</systemitem> "
+"for an example."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:116
+msgid ""
+"<command>dpatch</command> also provides these facilities, but it's intended "
+"to be even easier to use. See the package <systemitem "
+"role=\"package\">dpatch</systemitem> for documentation and examples (in "
+"<filename>/usr/share/doc/dpatch</filename>)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:124
+msgid "Multiple binary packages"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:126
+msgid ""
+"A single source package will often build several binary packages, either to "
+"provide several flavors of the same software (e.g., the <systemitem "
+"role=\"package\">vim</systemitem> source package) or to make several small "
+"packages instead of a big one (e.g., so the user can install only the subset "
+"needed, and thus save some disk space)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:133
+msgid ""
+"The second case can be easily managed in <filename>debian/rules</filename>. "
+"You just need to move the appropriate files from the build directory into "
+"the package's temporary trees. You can do this using "
+"<command>install</command> or <command>dh_install</command> from <systemitem "
+"role=\"package\">debhelper</systemitem>. Be sure to check the different "
+"permutations of the various packages, ensuring that you have the "
+"inter-package dependencies set right in <filename>debian/control</filename>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:142
+msgid ""
+"The first case is a bit more difficult since it involves multiple recompiles "
+"of the same software but with different configuration options. The "
+"<systemitem role=\"package\">vim</systemitem> source package is an example "
+"of how to manage this using an hand-crafted "
+"<filename>debian/rules</filename> file."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: best-pkging-practices.dbk:154
+msgid "Best practices for <filename>debian/control</filename>"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:156
+msgid ""
+"The following practices are relevant to the "
+"<filename>debian/control</filename> file. They supplement the <ulink "
+"url=\"&url-debian-policy;ch-binary.html#s-descriptions\">Policy on package "
+"descriptions</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:162
+msgid ""
+"The description of the package, as defined by the corresponding field in the "
+"<filename>control</filename> file, contains both the package synopsis and "
+"the long description for the package. <xref linkend=\"bpp-desc-basics\"/> "
+"describes common guidelines for both parts of the package description. "
+"Following that, <xref linkend=\"bpp-pkg-synopsis\"/> provides guidelines "
+"specific to the synopsis, and <xref linkend=\"bpp-pkg-desc\"/> contains "
+"guidelines specific to the description."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:171
+msgid "General guidelines for package descriptions"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:173
+msgid ""
+"The package description should be written for the average likely user, the "
+"average person who will use and benefit from the package. For instance, "
+"development packages are for developers, and can be technical in their "
+"language. More general-purpose applications, such as editors, should be "
+"written for a less technical user."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:180
+msgid ""
+"Our review of package descriptions lead us to conclude that most package "
+"descriptions are technical, that is, are not written to make sense for "
+"non-technical users. Unless your package really is only for technical "
+"users, this is a problem."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:186
+msgid ""
+"How do you write for non-technical users? Avoid jargon. Avoid referring to "
+"other applications or frameworks that the user might not be familiar with — "
+"GNOME or KDE is fine, since users are probably familiar with these terms, "
+"but GTK+ is probably not. Try not to assume any knowledge at all. If you "
+"must use technical terms, introduce them."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:193
+msgid ""
+"Be objective. Package descriptions are not the place for advocating your "
+"package, no matter how much you love it. Remember that the reader may not "
+"care about the same things you care about."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:198
+msgid ""
+"References to the names of any other software packages, protocol names, "
+"standards, or specifications should use their canonical forms, if one "
+"exists. For example, use X Window System, X11, or X; not X Windows, "
+"X-Windows, or X Window. Use GTK+, not GTK or gtk. Use GNOME, not Gnome. "
+"Use PostScript, not Postscript or postscript."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:205
+msgid ""
+"If you are having problems writing your description, you may wish to send it "
+"along to &email-debian-l10n-english; and request feedback."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:211
+msgid "The package synopsis, or short description"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:213
+msgid ""
+"The synopsis line (the short description) should be concise. It must not "
+"repeat the package's name (this is policy)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:217
+msgid ""
+"It's a good idea to think of the synopsis as an appositive clause, not a "
+"full sentence. An appositive clause is defined in WordNet as a grammatical "
+"relation between a word and a noun phrase that follows, e.g., Rudolph the "
+"red-nosed reindeer. The appositive clause here is red-nosed reindeer. "
+"Since the synopsis is a clause, rather than a full sentence, we recommend "
+"that it neither start with a capital nor end with a full stop (period). It "
+"should also not begin with an article, either definite (the) or indefinite "
+"(a or an)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:226
+msgid ""
+"It might help to imagine that the synopsis is combined with the package name "
+"in the following way:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: best-pkging-practices.dbk:230
+#, no-wrap
+msgid ""
+"<replaceable>package-name</replaceable> is a "
+"<replaceable>synopsis</replaceable>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:233
+msgid "Alternatively, it might make sense to think of it as"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: best-pkging-practices.dbk:236
+#, no-wrap
+msgid ""
+"<replaceable>package-name</replaceable> is "
+"<replaceable>synopsis</replaceable>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:239
+msgid "or, if the package name itself is a plural (such as developers-tools)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: best-pkging-practices.dbk:242
+#, no-wrap
+msgid ""
+"<replaceable>package-name</replaceable> are "
+"<replaceable>synopsis</replaceable>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:245
+msgid ""
+"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 sentence."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:252
+msgid "The long description"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:254
+msgid ""
+"The long description is the primary information available to the user about "
+"a package before they install it. It should provide all the information "
+"needed to let the user decide whether to install the package. Assume that "
+"the user has already read the package synopsis."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:260
+msgid "The long description should consist of full and complete sentences."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:263
+msgid ""
+"The first paragraph of the long description should answer the following "
+"questions: what does the package do? what task does it help the user "
+"accomplish? It is important to describe this in a non-technical way, unless "
+"of course the audience for the package is necessarily technical."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:269
+msgid ""
+"The following paragraphs should answer the following questions: Why do I as "
+"a user need this package? What other features does the package have? What "
+"outstanding features and deficiencies are there compared to other packages "
+"(e.g., if you need X, use Y instead)? Is this package related to other "
+"packages in some way that is not handled by the package manager (e.g., this "
+"is the client for the foo server)?"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:277
+msgid ""
+"Be careful to avoid spelling and grammar mistakes. Ensure that you "
+"spell-check it. Both <command>ispell</command> and "
+"<command>aspell</command> have special modes for checking "
+"<filename>debian/control</filename> files:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: best-pkging-practices.dbk:282
+#, no-wrap
+msgid "ispell -d american -g debian/control"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: best-pkging-practices.dbk:285
+#, no-wrap
+msgid "aspell -d en -D -c debian/control"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:288
+msgid ""
+"Users usually expect these questions to be answered in the package "
+"description:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:293
+msgid ""
+"What does the package do? If it is an add-on to another package, then the "
+"short description of the package we are an add-on to should be put in here."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:299
+msgid ""
+"Why should I want this package? This is related to the above, but not the "
+"same (this is a mail user agent; this is cool, fast, interfaces with PGP and "
+"LDAP and IMAP, has features X, Y, and Z)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:306
+msgid ""
+"If this package should not be installed directly, but is pulled in by "
+"another package, this should be mentioned."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:312
+msgid ""
+"If the package is experimental, or there are other reasons it should not be "
+"used, if there are other packages that should be used instead, it should be "
+"here as well."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:319
+msgid ""
+"How is this package different from the competition? Is it a better "
+"implementation? more features? different features? Why should I choose this "
+"package."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:332
+msgid "Upstream home page"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:334
+msgid ""
+"We recommend that you add the URL for the package's home page to the package "
+"description in <filename>debian/control</filename>. This information should "
+"be added at the end of description, using the following format:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: best-pkging-practices.dbk:339
+#, no-wrap
+msgid ""
+".\n"
+" Homepage: http://some-project.some-place.org/"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:343
+msgid ""
+"Note the spaces prepending the line, which serves to break the lines "
+"correctly. To see an example of how this displays, see <ulink "
+"url=\"&url-eg-desc-upstream-info;\"></ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:348
+msgid ""
+"If there is no home page for the software, this should naturally be left "
+"out."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:351
+msgid ""
+"Note that we expect this field will eventually be replaced by a proper "
+"<filename>debian/control</filename> field understood by "
+"<command>dpkg</command> and <literal>&packages-host;</literal>. If you "
+"don't want to bother migrating the home page from the description to this "
+"field, you should probably wait until that is available. Please make sure "
+"that this line matches the regular expression <literal>/^ Homepage: [^ "
+"]*$/</literal>, as this allows <filename>&packages-host;</filename> to parse "
+"it correctly."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:362
+msgid "Version Control System location"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:364
+msgid ""
+"There are additional fields for the location of the Version Control System "
+"in <filename>debian/control</filename>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:368
+msgid "XS-Vcs-Browser"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:370
+msgid ""
+"Value of this field should be a <literal>http://</literal> URL pointing to a "
+"web-browsable copy of the Version Control System repository used to maintain "
+"the given package, if available."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:375
+msgid ""
+"The information is meant to be useful for the final user, willing to browse "
+"the latest work done on the package (e.g. when looking for the patch fixing "
+"a bug tagged as <literal>pending</literal> in the bug tracking system)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:382
+msgid "XS-Vcs-*"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:384
+msgid ""
+"Value of this field should be a string identifying unequivocally the "
+"location of the Version Control System repository used to maintain the given "
+"package, if available. <literal>*</literal> identify the Version Control "
+"System; currently the following systems are supported by the package "
+"tracking system: <literal>arch</literal>, <literal>bzr</literal> (Bazaar), "
+"<literal>cvs</literal>, <literal>darcs</literal>, <literal>git</literal>, "
+"<literal>hg</literal> (Mercurial), <literal>mtn</literal> (Monotone), "
+"<literal>svn</literal> (Subversion). It is allowed to specify different VCS "
+"fields for the same package: they will all be shown in the PTS web "
+"interface."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:395
+msgid ""
+"The information is meant to be useful for a user knowledgeable in the given "
+"Version Control System and willing to build the current version of a package "
+"from the VCS sources. Other uses of this information might include "
+"automatic building of the latest VCS version of the given package. To this "
+"end the location pointed to by the field should better be version agnostic "
+"and point to the main branch (for VCSs supporting such a concept). Also, "
+"the location pointed to should be accessible to the final user; fulfilling "
+"this requirement might imply pointing to an anonymous access of the "
+"repository instead of pointing to an SSH-accessible version of the same."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:406
+msgid ""
+"In the following example, an instance of the field for a Subversion "
+"repository of the <systemitem role=\"package\">vim</systemitem> package is "
+"shown. Note how the URL is in the <literal>svn://</literal> scheme (instead "
+"of <literal>svn+ssh://</literal>) and how it points to the "
+"<filename>trunk/</filename> branch. The use of the "
+"<literal>XS-Vcs-Browser</literal> field described above is also shown."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><screen>
+#: best-pkging-practices.dbk:414
+#, no-wrap
+msgid ""
+"Source: vim\n"
+" Section: editors\n"
+" Priority: optional\n"
+" <snip>\n"
+" XS-Vcs-Svn: svn://svn.debian.org/svn/pkg-vim/trunk/packages/vim\n"
+" XS-Vcs-Browser: http://svn.debian.org/wsvn/pkg-vim/trunk/packages/vim"
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: best-pkging-practices.dbk:428
+msgid "Best practices for <filename>debian/changelog</filename>"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:430
+msgid ""
+"The following practices supplement the <ulink "
+"url=\"&url-debian-policy;ch-docs.html#s-changelogs\">Policy on changelog "
+"files</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:435
+msgid "Writing useful changelog entries"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:437
+msgid ""
+"The changelog entry for a package revision documents changes in that "
+"revision, and only them. Concentrate on describing significant and "
+"user-visible changes that were made since the last version."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:442
+msgid ""
+"Focus on <emphasis>what</emphasis> was changed — who, how and when are "
+"usually less important. Having said that, remember to politely attribute "
+"people who have provided notable help in making the package (e.g., those who "
+"have sent in patches)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:448
+msgid ""
+"There's no need to elaborate the trivial and obvious changes. You can also "
+"aggregate several changes in one entry. On the other hand, don't be overly "
+"terse if you have undertaken a major change. Be especially clear if there "
+"are changes that affect the behaviour of the program. For further "
+"explanations, use the <filename>README.Debian</filename> file."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:455
+msgid ""
+"Use common English so that the majority of readers can comprehend it. Avoid "
+"abbreviations, tech-speak and jargon when explaining changes that close "
+"bugs, especially for bugs filed by users that did not strike you as "
+"particularly technically savvy. Be polite, don't swear."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:461
+msgid ""
+"It is sometimes desirable to prefix changelog entries with the names of the "
+"files that were changed. However, there's no need to explicitly list each "
+"and every last one of the changed files, especially if the change was small "
+"or repetitive. You may use wildcards."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:467
+msgid ""
+"When referring to bugs, don't assume anything. Say what the problem was, "
+"how it was fixed, and append the closes: #nnnnn string. See <xref "
+"linkend=\"upload-bugfix\"/> for more information."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:474
+msgid "Common misconceptions about changelog entries"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:476
+msgid ""
+"The changelog entries should <emphasis role=\"strong\">not</emphasis> "
+"document generic packaging issues (Hey, if you're looking for foo.conf, it's "
+"in /etc/blah/.), since administrators and users are supposed to be at least "
+"remotely acquainted with how such things are generally arranged on Debian "
+"systems. Do, however, mention if you change the location of a configuration "
+"file."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:484
+msgid ""
+"The only bugs closed with a changelog entry should be those that are "
+"actually fixed in the same package revision. Closing unrelated bugs in the "
+"changelog is bad practice. See <xref linkend=\"upload-bugfix\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:489
+msgid ""
+"The changelog entries should <emphasis role=\"strong\">not</emphasis> be "
+"used for random discussion with bug reporters (I don't see segfaults when "
+"starting foo with option bar; send in more info), general statements on "
+"life, the universe and everything (sorry this upload took me so long, but I "
+"caught the flu), or pleas for help (the bug list on this package is huge, "
+"please lend me a hand). Such things usually won't be noticed by their "
+"target audience, but may annoy people who wish to read information about "
+"actual changes in the package. See <xref linkend=\"bug-answering\"/> for "
+"more information on how to use the bug tracking system."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:500
+msgid ""
+"It is an old tradition to acknowledge bugs fixed in non-maintainer uploads "
+"in the first changelog entry of the proper maintainer upload. As we have "
+"version tracking now, it is enough to keep the NMUed changelog entries and "
+"just mention this fact in your own changelog entry."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:508
+msgid "Common errors in changelog entries"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:510
+msgid ""
+"The following examples demonstrate some common errors or examples of bad "
+"style in changelog entries."
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: best-pkging-practices.dbk:514
+#, no-wrap
+msgid "* Fixed all outstanding bugs."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:517
+msgid "This doesn't tell readers anything too useful, obviously."
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: best-pkging-practices.dbk:520
+#, no-wrap
+msgid "* Applied patch from Jane Random."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:523
+msgid "What was the patch about?"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: best-pkging-practices.dbk:526
+#, no-wrap
+msgid "* Late night install target overhaul."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:529
+msgid ""
+"Overhaul which accomplished what? Is the mention of late night supposed to "
+"remind us that we shouldn't trust that code?"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: best-pkging-practices.dbk:533
+#, no-wrap
+msgid "* Fix vsync FU w/ ancient CRTs."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:536
+msgid ""
+"Too many acronyms, and it's not overly clear what the, uh, fsckup (oops, a "
+"curse word!) was actually about, or how it was fixed."
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: best-pkging-practices.dbk:540
+#, no-wrap
+msgid "* This is not a bug, closes: #nnnnnn."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:543
+msgid ""
+"First of all, there's absolutely no need to upload the package to convey "
+"this information; instead, use the bug tracking system. Secondly, there's "
+"no explanation as to why the report is not a bug."
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: best-pkging-practices.dbk:548
+#, no-wrap
+msgid "* Has been fixed for ages, but I forgot to close; closes: #54321."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:551
+msgid ""
+"If for some reason you didn't mention the bug number in a previous changelog "
+"entry, there's no problem, just close the bug normally in the BTS. There's "
+"no need to touch the changelog file, presuming the description of the fix is "
+"already in (this applies to the fixes by the upstream authors/maintainers as "
+"well, you don't have to track bugs that they fixed ages ago in your "
+"changelog)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: best-pkging-practices.dbk:558
+#, no-wrap
+msgid "* Closes: #12345, #12346, #15432"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:561
+msgid ""
+"Where's the description? If you can't think of a descriptive message, start "
+"by inserting the title of each different bug."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:567
+msgid "Supplementing changelogs with NEWS.Debian files"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:569
+msgid ""
+"Important news about changes in a package can also be put in NEWS.Debian "
+"files. The news will be displayed by tools like apt-listchanges, before all "
+"the rest of the changelogs. This is the preferred means to let the user "
+"know about significant changes in a package. It is better than using "
+"debconf notes since it is less annoying and the user can go back and refer "
+"to the NEWS.Debian file after the install. And it's better than listing "
+"major changes in README.Debian, since the user can easily miss such notes."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:578
+msgid ""
+"The file format is the same as a debian changelog file, but leave off the "
+"asterisks and describe each news item with a full paragraph when necessary "
+"rather than the more concise summaries that would go in a changelog. It's a "
+"good idea to run your file through dpkg-parsechangelog to check its "
+"formatting as it will not be automatically checked during build as the "
+"changelog is. Here is an example of a real NEWS.Debian file:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: best-pkging-practices.dbk:586
+#, no-wrap
+msgid ""
+"cron (3.0pl1-74) unstable; urgency=low\n"
+"\n"
+" The checksecurity script is no longer included with the cron package:\n"
+" it now has its own package, checksecurity. If you liked the\n"
+" functionality provided with that script, please install the new\n"
+" package.\n"
+"\n"
+" -- Steve Greenland <stevegr@debian.org> Sat, 6 Sep 2003 17:15:03 "
+"-0500"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:596
+msgid ""
+"The NEWS.Debian file is installed as "
+"/usr/share/doc/<package>/NEWS.Debian.gz. It is compressed, and always "
+"has that name even in Debian native packages. If you use debhelper, "
+"dh_installchangelogs will install debian/NEWS files for you."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:602
+msgid ""
+"Unlike changelog files, you need not update NEWS.Debian files with every "
+"release. Only update them if you have something particularly newsworthy "
+"that user should know about. If you have no news at all, there's no need to "
+"ship a NEWS.Debian file in your package. No news is good news!"
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: best-pkging-practices.dbk:623
+msgid "Best practices for maintainer scripts"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:625
+msgid ""
+"Maintainer scripts include the files <filename>debian/postinst</filename>, "
+"<filename>debian/preinst</filename>, <filename>debian/prerm</filename> and "
+"<filename>debian/postrm</filename>. These scripts take care of any package "
+"installation or deinstallation setup which isn't handled merely by the "
+"creation or removal of files and directories. The following instructions "
+"supplement the <ulink url=\"&url-debian-policy;\">Debian Policy</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:633
+msgid ""
+"Maintainer scripts must be idempotent. That means that you need to make "
+"sure nothing bad will happen if the script is called twice where it would "
+"usually be called once."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:638
+msgid ""
+"Standard input and output may be redirected (e.g. into pipes) for logging "
+"purposes, so don't rely on them being a tty."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:642
+msgid ""
+"All prompting or interactive configuration should be kept to a minimum. "
+"When it is necessary, you should use the <systemitem "
+"role=\"package\">debconf</systemitem> package for the interface. Remember "
+"that prompting in any case can only be in the <literal>configure</literal> "
+"stage of the <filename>postinst</filename> script."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:649
+msgid ""
+"Keep the maintainer scripts as simple as possible. We suggest you use pure "
+"POSIX shell scripts. Remember, if you do need any bash features, the "
+"maintainer script must have a bash shebang line. POSIX shell or Bash are "
+"preferred to Perl, since they enable <systemitem "
+"role=\"package\">debhelper</systemitem> to easily add bits to the scripts."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:656
+msgid ""
+"If you change your maintainer scripts, be sure to test package removal, "
+"double installation, and purging. Be sure that a purged package is "
+"completely gone, that is, it must remove any files created, directly or "
+"indirectly, in any maintainer script."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:662
+msgid ""
+"If you need to check for the existence of a command, you should use "
+"something like"
+msgstr ""
+
+# type: Content of: <chapter><section><programlisting>
+#: best-pkging-practices.dbk:665
+#, no-wrap
+msgid "if [ -x /usr/sbin/install-docs ]; then ..."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:667
+msgid ""
+"If you don't wish to hard-code the path of a command in your maintainer "
+"script, the following POSIX-compliant shell function may help:"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:672
+msgid ""
+"You can use this function to search <literal>$PATH</literal> for a command "
+"name, passed as an argument. It returns true (zero) if the command was "
+"found, and false if not. This is really the most portable way, since "
+"<literal>command -v</literal>, <command>type</command>, and "
+"<command>which</command> are not POSIX."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:679
+msgid ""
+"While <command>which</command> is an acceptable alternative, since it is "
+"from the required <systemitem role=\"package\">debianutils</systemitem> "
+"package, it's not on the root partition. That is, it's in "
+"<filename>/usr/bin</filename> rather than <filename>/bin</filename>, so one "
+"can't use it in scripts which are run before the <filename>/usr</filename> "
+"partition is mounted. Most scripts won't have this problem, though."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: best-pkging-practices.dbk:689
+msgid ""
+"Configuration management with <systemitem "
+"role=\"package\">debconf</systemitem>"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:691
+msgid ""
+"<systemitem role=\"package\">Debconf</systemitem> is a configuration "
+"management system which can be used by all the various packaging scripts "
+"(<filename>postinst</filename> mainly) to request feedback from the user "
+"concerning how to configure the package. Direct user interactions must now "
+"be avoided in favor of <systemitem role=\"package\">debconf</systemitem> "
+"interaction. This will enable non-interactive installations in the future."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:699
+msgid ""
+"Debconf is a great tool but it is often poorly used. Many common mistakes "
+"are listed in the <citerefentry> "
+"<refentrytitle>debconf-devel</refentrytitle> <manvolnum>7</manvolnum> "
+"</citerefentry> man page. It is something that you must read if you decide "
+"to use debconf. Also, we document some best practices here."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: best-pkging-practices.dbk:706
+msgid ""
+"These guidelines include some writing style and typography recommendations, "
+"general considerations about debconf usage as well as more specific "
+"recommendations for some parts of the distribution (the installation system "
+"for instance)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:712
+msgid "Do not abuse debconf"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:714
+msgid ""
+"Since debconf appeared in Debian, it has been widely abused and several "
+"criticisms received by the Debian distribution come from debconf abuse with "
+"the need of answering a wide bunch of questions before getting any little "
+"thing installed."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:720
+msgid ""
+"Keep usage notes to what they belong: the NEWS.Debian, or README.Debian "
+"file. Only use notes for important notes which may directly affect the "
+"package usability. Remember that notes will always block the install until "
+"confirmed or bother the user by email."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:726
+msgid ""
+"Carefully choose the questions priorities in maintainer scripts. See "
+"<citerefentry> <refentrytitle>debconf-devel</refentrytitle> "
+"<manvolnum>7</manvolnum> </citerefentry> for details about priorities. Most "
+"questions should use medium and low priorities."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:734
+msgid "General recommendations for authors and translators"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:736
+msgid "Write correct English"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:738
+msgid ""
+"Most Debian package maintainers are not native English speakers. So, "
+"writing properly phrased templates may not be easy for them."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:742
+msgid ""
+"Please use (and abuse) &email-debian-l10n-english; mailing list. Have your "
+"templates proofread."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:746
+msgid ""
+"Badly written templates give a poor image of your package, of your work...or "
+"even of Debian itself."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:750
+msgid ""
+"Avoid technical jargon as much as possible. If some terms sound common to "
+"you, they may be impossible to understand for others. If you cannot avoid "
+"them, try to explain them (use the extended description). When doing so, "
+"try to balance between verbosity and simplicity."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:758
+msgid "Be kind to translators"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:760
+msgid ""
+"Debconf templates may be translated. Debconf, along with its sister package "
+"<command>po-debconf</command> offers a simple framework for getting "
+"templates translated by translation teams or even individuals."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:765
+msgid ""
+"Please use gettext-based templates. Install <systemitem "
+"role=\"package\">po-debconf</systemitem> on your development system and read "
+"its documentation (man po-debconf is a good start)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:770
+msgid ""
+"Avoid changing templates too often. Changing templates text induces more "
+"work to translators which will get their translation fuzzied. If you plan "
+"changes to your original templates, please contact translators. Most active "
+"translators are very responsive and getting their work included along with "
+"your modified templates will save you additional uploads. If you use "
+"gettext-based templates, the translator's name and e-mail addresses are "
+"mentioned in the po files headers."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:779
+msgid ""
+"The use of the <command>podebconf-report-po</command> from the po-debconf "
+"package is highly recommended to warn translators which have incomplete "
+"translations and request them for updates."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:784
+msgid ""
+"If in doubt, you may also contact the translation team for a given language "
+"(debian-l10n-xxxxx@&lists-host;), or the &email-debian-i18n; mailing list."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:789
+msgid ""
+"Calls for translations posted to &email-debian-i18n; with the "
+"<filename>debian/po/templates.pot</filename> file attached or referenced in "
+"a URL are encouraged. Be sure to mentions in these calls for new "
+"translations which languages you have existing translations for, in order to "
+"avoid duplicate work."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:798
+msgid "Unfuzzy complete translations when correcting typos and spelling"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:800
+msgid ""
+"When the text of a debconf template is corrected and you are <emphasis "
+"role=\"strong\">sure</emphasis> that the change does <emphasis "
+"role=\"strong\">not</emphasis> affect translations, please be kind to "
+"translators and unfuzzy their translations."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:806
+msgid ""
+"If you don't do so, the whole template will not be translated as long as a "
+"translator will send you an update."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:810
+msgid ""
+"To <emphasis role=\"strong\">unfuzzy</emphasis> translations, you can "
+"proceed the following way:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
+#: best-pkging-practices.dbk:816
+msgid ""
+"Put all incomplete PO files out of the way. You can check the completeness "
+"by using (needs the <systemitem role=\"package\">gettext</systemitem> "
+"package installed):"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><programlisting>
+#: best-pkging-practices.dbk:820
+#, no-wrap
+msgid ""
+"for i in debian/po/*po; do echo -n $i: ; msgfmt -o /dev/null\n"
+"--statistics $i; done"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
+#: best-pkging-practices.dbk:825
+msgid ""
+"move all files which report either fuzzy strings to a temporary place. "
+"Files which report no fuzzy strings (only translated and untranslated) will "
+"be kept in place."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
+#: best-pkging-practices.dbk:832
+msgid ""
+"now <emphasis role=\"strong\">and now only</emphasis>, modify the template "
+"for the typos and check again that translation are not impacted (typos, "
+"spelling errors, sometimes typographical corrections are usually OK)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
+#: best-pkging-practices.dbk:839
+msgid ""
+"run <command>debconf-updatepo</command>. This will fuzzy all strings you "
+"modified in translations. You can see this by running the above again"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
+#: best-pkging-practices.dbk:845
+msgid "use the following command:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><programlisting>
+#: best-pkging-practices.dbk:847
+#, no-wrap
+msgid "for i in debian/po/*po; do msgattrib --output-file=$i --clear-fuzzy $i; done"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
+#: best-pkging-practices.dbk:851
+msgid ""
+"move back to debian/po the files which showed fuzzy strings in the first "
+"step"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
+#: best-pkging-practices.dbk:856
+msgid "run <command>debconf-updatepo</command> again"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:863
+msgid "Do not make assumptions about interfaces"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:865
+msgid ""
+"Templates text should not make reference to widgets belonging to some "
+"debconf interfaces. Sentences like If you answer Yes... have no meaning "
+"for users of graphical interfaces which use checkboxes for boolean "
+"questions."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:870
+msgid ""
+"String templates should also avoid mentioning the default values in their "
+"description. First, because this is redundant with the values seen by the "
+"users. Also, because these default values may be different from the "
+"maintainer choices (for instance, when the debconf database was preseeded)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:876
+msgid ""
+"More generally speaking, try to avoid referring to user actions. Just give "
+"facts."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:882
+msgid "Do not use first person"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:884
+msgid ""
+"You should avoid the use of first person (I will do this... or We "
+"recommend...). The computer is not a person and the Debconf templates do "
+"not speak for the Debian developers. You should use neutral construction. "
+"Those of you who already wrote scientific publications, just write your "
+"templates like you would write a scientific paper. However, try using "
+"action voice if still possible, like Enable this if ... instead of This can "
+"be enabled if ...."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:894
+msgid "Be gender neutral"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:896
+msgid ""
+"The world is made of men and women. Please use gender-neutral constructions "
+"in your writing."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:904
+msgid "Templates fields definition"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:906
+msgid ""
+"This part gives some information which is mostly taken from the "
+"<citerefentry> <refentrytitle>debconf-devel</refentrytitle> "
+"<manvolnum>7</manvolnum> </citerefentry> manual page."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:911
+msgid "Type"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><title>
+#: best-pkging-practices.dbk:913
+msgid "string:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><para>
+#: best-pkging-practices.dbk:915
+msgid "Results in a free-form input field that the user can type any string into."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><title>
+#: best-pkging-practices.dbk:920
+msgid "password:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><para>
+#: best-pkging-practices.dbk:922
+msgid ""
+"Prompts the user for a password. Use this with caution; be aware that the "
+"password the user enters will be written to debconf's database. You should "
+"probably clean that value out of the database as soon as is possible."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><title>
+#: best-pkging-practices.dbk:929
+msgid "boolean:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><para>
+#: best-pkging-practices.dbk:931
+msgid ""
+"A true/false choice. Remember: true/false, <emphasis role=\"strong\">not "
+"yes/no</emphasis>..."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><title>
+#: best-pkging-practices.dbk:937
+msgid "select:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><para>
+#: best-pkging-practices.dbk:939
+msgid ""
+"A choice between one of a number of values. The choices must be specified "
+"in a field named 'Choices'. Separate the possible values with commas and "
+"spaces, like this: Choices: yes, no, maybe"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><title>
+#: best-pkging-practices.dbk:946
+msgid "multiselect:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><para>
+#: best-pkging-practices.dbk:948
+msgid ""
+"Like the select data type, except the user can choose any number of items "
+"from the choices list (or chose none of them)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><title>
+#: best-pkging-practices.dbk:954
+msgid "note:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><para>
+#: best-pkging-practices.dbk:956
+msgid ""
+"Rather than being a question per se, this datatype indicates a note that can "
+"be displayed to the user. It should be used only for important notes that "
+"the user really should see, since debconf will go to great pains to make "
+"sure the user sees it; halting the install for them to press a key, and even "
+"mailing the note to them in some cases."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><title>
+#: best-pkging-practices.dbk:965
+msgid "text:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><para>
+#: best-pkging-practices.dbk:967
+msgid "This type is now considered obsolete: don't use it."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><title>
+#: best-pkging-practices.dbk:972
+msgid "error:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><para>
+#: best-pkging-practices.dbk:974
+msgid ""
+"This type is designed to handle error messages. It is mostly similar to the "
+"note type. Frontends may present it differently (for instance, the dialog "
+"frontend of cdebconf draws a red screen instead of the usual blue one)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><para>
+#: best-pkging-practices.dbk:979
+msgid ""
+"It is recommended to use this type for any message that needs user attention "
+"for a correction of any kind."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:987
+msgid "Description: short and extended description"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:989
+msgid ""
+"Template descriptions have two parts: short and extended. The short "
+"description is in the Description: line of the template."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:993
+msgid ""
+"The short description should be kept short (50 characters or so) so that it "
+"may be accomodated by most debconf interfaces. Keeping it short also helps "
+"translators, as usually translations tend to end up being longer than the "
+"original."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:999
+msgid ""
+"The short description should be able to stand on its own. Some interfaces "
+"do not show the long description by default, or only if the user explicitely "
+"asks for it or even do not show it at all. Avoid things like What do you "
+"want to do?"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1005
+msgid ""
+"The short description does not necessarily have to be a full sentence. This "
+"is part of the keep it short and efficient recommendation."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1009
+msgid ""
+"The extended description should not repeat the short description word for "
+"word. If you can't think up a long description, then first, think some "
+"more. Post to debian-devel. Ask for help. Take a writing class! That "
+"extended description is important. If after all that you still can't come "
+"up with anything, leave it blank."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1016
+msgid ""
+"The extended description should use complete sentences. Paragraphs should "
+"be kept short for improved readability. Do not mix two ideas in the same "
+"paragraph but rather use another paragraph."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1021
+msgid ""
+"Don't be too verbose. User tend to ignore too long screens. 20 lines are "
+"by experience a border you shouldn't cross, because that means that in the "
+"classical dialog interface, people will need to scroll, and lot of people "
+"just don't do that."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1027
+msgid ""
+"The extended description should <emphasis role=\"strong\">never</emphasis> "
+"include a question."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1031
+msgid ""
+"For specific rules depending on templates type (string, boolean, etc.), "
+"please read below."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:1037
+msgid "Choices"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1039
+msgid ""
+"This field should be used for Select and Multiselect types. It contains the "
+"possible choices which will be presented to users. These choices should be "
+"separated by commas."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:1046
+msgid "Default"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1048
+msgid ""
+"This field is optional. It contains the default answer for string, select "
+"and multiselect templates. For multiselect templates, it may contain a "
+"comma-separated list of choices."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:1057
+msgid "Templates fields specific style guide"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:1059
+msgid "Type field"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1061
+msgid ""
+"No specific indication except: use the appropriate type by referring to the "
+"previous section."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:1067
+msgid "Description field"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1069
+msgid ""
+"Below are specific instructions for properly writing the Description (short "
+"and extended) depending on the template type."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><title>
+#: best-pkging-practices.dbk:1073
+msgid "String/password templates"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:1077
+msgid ""
+"The short description is a prompt and <emphasis "
+"role=\"strong\">not</emphasis> a title. Avoid question style prompts (IP "
+"Address?) in favour of opened prompts (IP address:). The use of colons is "
+"recommended."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:1084
+msgid ""
+"The extended description is a complement to the short description. In the "
+"extended part, explain what is being asked, rather than ask the same "
+"question again using longer words. Use complete sentences. Terse writing "
+"style is strongly discouraged."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><title>
+#: best-pkging-practices.dbk:1094
+msgid "Boolean templates"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:1098
+msgid ""
+"The short description should be phrased in the form of a question which "
+"should be kept short and should generally end with a question mark. Terse "
+"writing style is permitted and even encouraged if the question is rather "
+"long (remember that translations are often longer than original versions)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:1106
+msgid ""
+"Again, please avoid referring to specific interface widgets. A common "
+"mistake for such templates is if you answer Yes-type constructions."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><title>
+#: best-pkging-practices.dbk:1114
+msgid "Select/Multiselect"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:1118
+msgid ""
+"The short description is a prompt and <emphasis "
+"role=\"strong\">not</emphasis> a title. Do <emphasis "
+"role=\"strong\">not</emphasis> use useless Please choose... constructions. "
+"Users are clever enough to figure out they have to choose something...:)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:1126
+msgid ""
+"The extended description will complete the short description. It may refer "
+"to the available choices. It may also mention that the user may choose more "
+"than one of the available choices, if the template is a multiselect one "
+"(although the interface often makes this clear)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><title>
+#: best-pkging-practices.dbk:1136
+msgid "Notes"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:1140
+msgid "The short description should be considered to be a *title*."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:1145
+msgid ""
+"The extended description is what will be displayed as a more detailed "
+"explanation of the note. Phrases, no terse writing style."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:1151
+msgid ""
+"<emphasis role=\"strong\">Do not abuse debconf.</emphasis> Notes are the "
+"most common way to abuse debconf. As written in debconf-devel manual page: "
+"it's best to use them only for warning about very serious problems. The "
+"NEWS.Debian or README.Debian files are the appropriate location for a lot of "
+"notes. If, by reading this, you consider converting your Note type "
+"templates to entries in NEWS/Debian or README.Debian, plus consider keeping "
+"existing translations for the future."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:1166
+msgid "Choices field"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1168
+msgid ""
+"If the Choices are likely to change often, please consider using the "
+"__Choices trick. This will split each individual choice into a single "
+"string, which will considerably help translators for doing their work."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:1175 best-pkging-practices.dbk:1213
+msgid "Default field"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1177
+msgid ""
+"If the default value, for a select template, is likely to vary depending on "
+"the user language (for instance, if the choice is a language choice), please "
+"use the _DefaultChoice trick."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1182
+msgid ""
+"This special field allow translators to put the most appropriate choice "
+"according to their own language. It will become the default choice when "
+"their language is used while your own mentioned Default Choice will be used "
+"chan using English."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1188
+msgid "Example, taken from the geneweb package templates:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><screen>
+#: best-pkging-practices.dbk:1191
+#, no-wrap
+msgid ""
+"Template: geneweb/lang\n"
+"Type: select\n"
+"__Choices: Afrikaans (af), Bulgarian (bg), Catalan (ca), Chinese (zh), Czech "
+"(cs), Danish (da), Dutch (nl), English (en), Esperanto (eo), Estonian (et), "
+"Finnish (fi), French (fr), German (de), Hebrew (he), Icelandic (is), Italian "
+"(it), Latvian (lv), Norwegian (no), Polish (pl), Portuguese (pt), Romanian "
+"(ro), Russian (ru), Spanish (es), Swedish (sv)\n"
+"# This is the default choice. Translators may put their own language here\n"
+"# instead of the default.\n"
+"# WARNING : you MUST use the ENGLISH FORM of your language\n"
+"# For instance, the french translator will need to put French (fr) here.\n"
+"_DefaultChoice: English (en)[ translators, please see comment in PO files]\n"
+"_Description: Geneweb default language:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1202
+msgid ""
+"Note the use of brackets which allow internal comments in debconf fields. "
+"Also note the use of comments which will show up in files the translators "
+"will work with."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1207
+msgid ""
+"The comments are needed as the DefaultChoice trick is a bit confusing: the "
+"translators may put their own choice"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1215
+msgid ""
+"Do NOT use empty default field. If you don't want to use default values, do "
+"not use Default at all."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1219
+msgid ""
+"If you use po-debconf (and you <emphasis role=\"strong\">should</emphasis>, "
+"see 2.2), consider making this field translatable, if you think it may be "
+"translated."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1224
+msgid ""
+"If the default value may vary depending on language/country (for instance "
+"the default value for a language choice), consider using the special "
+"_DefaultChoice type documented in <citerefentry> "
+"<refentrytitle>po-debconf</refentrytitle> <manvolnum>7</manvolnum> "
+"</citerefentry>)."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: best-pkging-practices.dbk:1236
+msgid "Internationalization"
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:1238
+msgid "Handling debconf translations"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1240
+msgid ""
+"Like porters, translators have a difficult task. They work on many packages "
+"and must collaborate with many different maintainers. Moreover, most of the "
+"time, they are not native English speakers, so you may need to be "
+"particularly patient with them."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1246
+msgid ""
+"The goal of <systemitem role=\"package\">debconf</systemitem> was to make "
+"packages configuration easier for maintainers and for users. Originally, "
+"translation of debconf templates was handled with "
+"<command>debconf-mergetemplate</command>. However, that technique is now "
+"deprecated; the best way to accomplish <systemitem "
+"role=\"package\">debconf</systemitem> internationalization is by using the "
+"<systemitem role=\"package\">po-debconf</systemitem> package. This method "
+"is easier both for maintainer and translators; transition scripts are "
+"provided."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1256
+msgid ""
+"Using <systemitem role=\"package\">po-debconf</systemitem>, the translation "
+"is stored in <filename>po</filename> files (drawing from "
+"<command>gettext</command> translation techniques). Special template files "
+"contain the original messages and mark which fields are translatable. When "
+"you change the value of a translatable field, by calling "
+"<command>debconf-updatepo</command>, the translation is marked as needing "
+"attention from the translators. Then, at build time, the "
+"<command>dh_installdebconf</command> program takes care of all the needed "
+"magic to add the template along with the up-to-date translations into the "
+"binary packages. Refer to the <citerefentry> "
+"<refentrytitle>po-debconf</refentrytitle> <manvolnum>7</manvolnum> "
+"</citerefentry> manual page for details."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:1272
+msgid "Internationalized documentation"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1274
+msgid ""
+"Internationalizing documentation is crucial for users, but a lot of labor. "
+"There's no way to eliminate all that work, but you can make things easier "
+"for translators."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1279
+msgid ""
+"If you maintain documentation of any size, its easier for translators if "
+"they have access to a source control system. That lets translators see the "
+"differences between two versions of the documentation, so, for instance, "
+"they can see what needs to be retranslated. It is recommended that the "
+"translated documentation maintain a note about what source control revision "
+"the translation is based on. An interesting system is provided by <ulink "
+"url=\"&url-i18n-doc-check;\">doc-check</ulink> in the <systemitem "
+"role=\"package\">boot-floppies</systemitem> package, which shows an overview "
+"of the translation status for any given language, using structured comments "
+"for the current revision of the file to be translated and, for a translated "
+"file, the revision of the original file the translation is based on. You "
+"might wish to adapt and provide that in your CVS area."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1293
+msgid ""
+"If you maintain XML or SGML documentation, we suggest that you isolate any "
+"language-independent information and define those as entities in a separate "
+"file which is included by all the different translations. This makes it "
+"much easier, for instance, to keep URLs up to date across multiple files."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: best-pkging-practices.dbk:1303
+msgid "Common packaging situations"
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:1314
+msgid "Packages using <command>autoconf</command>/<command>automake</command>"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1316
+msgid ""
+"Keeping <command>autoconf</command>'s <filename>config.sub</filename> and "
+"<filename>config.guess</filename> files up to date is critical for porters, "
+"especially on more volatile architectures. Some very good packaging "
+"practices for any package using <command>autoconf</command> and/or "
+"<command>automake</command> have been synthesized in &file-bpp-autotools; "
+"from the <systemitem role=\"package\">autotools-dev</systemitem> package. "
+"You're strongly encouraged to read this file and to follow the given "
+"recommendations."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:1328
+msgid "Libraries"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1330
+msgid ""
+"Libraries are always difficult to package for various reasons. The policy "
+"imposes many constraints to ease their maintenance and to make sure upgrades "
+"are as simple as possible when a new upstream version comes out. Breakage "
+"in a library can result in dozens of dependent packages breaking."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1336
+msgid ""
+"Good practices for library packaging have been grouped in <ulink "
+"url=\"&url-libpkg-guide;\">the library packaging guide</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:1343
+msgid "Documentation"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1345
+msgid ""
+"Be sure to follow the <ulink url=\"&url-debian-policy;ch-docs.html\">Policy "
+"on documentation</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1350
+msgid ""
+"If your package contains documentation built from XML or SGML, we recommend "
+"you not ship the XML or SGML source in the binary package(s). If users want "
+"the source of the documentation, they should retrieve the source package."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1355
+msgid ""
+"Policy specifies that documentation should be shipped in HTML format. We "
+"also recommend shipping documentation in PDF and plain text format if "
+"convenient and if output of reasonable quality is possible. However, it is "
+"generally not appropriate to ship plain text versions of documentation whose "
+"source format is HTML."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1362
+msgid ""
+"Major shipped manuals should register themselves with <systemitem "
+"role=\"package\">doc-base</systemitem> on installation. See the <systemitem "
+"role=\"package\">doc-base</systemitem> package documentation for more "
+"information."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:1370
+msgid "Specific types of packages"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1372
+msgid ""
+"Several specific types of packages have special sub-policies and "
+"corresponding packaging rules and practices:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:1378
+msgid ""
+"Perl related packages have a <ulink url=\"&url-perl-policy;\">Perl "
+"policy</ulink>, some examples of packages following that policy are "
+"<systemitem role=\"package\">libdbd-pg-perl</systemitem> (binary perl "
+"module) or <systemitem role=\"package\">libmldbm-perl</systemitem> (arch "
+"independent perl module)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:1387
+msgid ""
+"Python related packages have their python policy; see &file-python-policy; "
+"in the <systemitem role=\"package\">python</systemitem> package."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:1394
+msgid ""
+"Emacs related packages have the <ulink url=\"&url-emacs-policy;\">emacs "
+"policy</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:1401
+msgid ""
+"Java related packages have their <ulink url=\"&url-java-policy;\">java "
+"policy</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:1408
+msgid ""
+"Ocaml related packages have their own policy, found in &file-ocaml-policy; "
+"from the <systemitem role=\"package\">ocaml</systemitem> package. A good "
+"example is the <systemitem role=\"package\">camlzip</systemitem> source "
+"package."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:1416
+msgid ""
+"Packages providing XML or SGML DTDs should conform to the recommendations "
+"found in the <systemitem role=\"package\">sgml-base-doc</systemitem> "
+"package."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: best-pkging-practices.dbk:1422
+msgid ""
+"Lisp packages should register themselves with <systemitem "
+"role=\"package\">common-lisp-controller</systemitem>, about which see "
+"&file-lisp-controller;."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:1452
+msgid "Architecture-independent data"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1454
+msgid ""
+"It is not uncommon to have a large amount of architecture-independent data "
+"packaged with a program. For example, audio files, a collection of icons, "
+"wallpaper patterns, or other graphic files. If the size of this data is "
+"negligible compared to the size of the rest of the package, it's probably "
+"best to keep it all in a single package."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1461
+msgid ""
+"However, if the size of the data is considerable, consider splitting it out "
+"into a separate, architecture-independent package (_all.deb). By doing "
+"this, you avoid needless duplication of the same data into eleven or more "
+".debs, one per each architecture. While this adds some extra overhead into "
+"the <filename>Packages</filename> files, it saves a lot of disk space on "
+"Debian mirrors. Separating out architecture-independent data also reduces "
+"processing time of <command>lintian</command> or <command>linda</command> "
+"(see <xref linkend=\"tools-lint\"/> ) when run over the entire Debian "
+"archive."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:1473
+msgid "Needing a certain locale during build"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1475
+msgid ""
+"If you need a certain locale during build, you can create a temporary file "
+"via this trick:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1479
+msgid ""
+"If you set <varname>LOCPATH</varname> to the equivalent of "
+"<filename>/usr/lib/locale</filename>, and <varname>LC_ALL</varname> to the "
+"name of the locale you generate, you should get what you want without being "
+"root. Something like this:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: best-pkging-practices.dbk:1484
+#, no-wrap
+msgid ""
+"LOCALE_PATH=debian/tmpdir/usr/lib/locale\n"
+"LOCALE_NAME=en_IN\n"
+"LOCALE_CHARSET=UTF-8\n"
+"\n"
+"mkdir -p $LOCALE_PATH\n"
+"localedef -i $LOCALE_NAME.$LOCALE_CHARSET -f $LOCALE_CHARSET "
+"$LOCALE_PATH/$LOCALE_NAME.$LOCALE_CHARSET\n"
+"\n"
+"# Using the locale\n"
+"LOCPATH=$LOCALE_PATH LC_ALL=$LOCALE_NAME.$LOCALE_CHARSET date"
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:1497
+msgid "Make transition packages deborphan compliant"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1499
+msgid ""
+"Deborphan is a program for helping users to detect which packages can safely "
+"be removed from the system, i.e. the ones that have no packages depending "
+"on them. The default operation is to search only within the libs and "
+"oldlibs sections, to hunt down unused libraries. But when passed the right "
+"argument, it tries to catch other useless packages."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1506
+msgid ""
+"For example, with --guess-dummy, deborphan tries to search all transitional "
+"packages which were needed for upgrade but which can now safely be removed. "
+"For that, it looks for the string dummy or transitional in their short "
+"description."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1512
+msgid ""
+"So, when you are creating such a package, please make sure to add this text "
+"to your short description. If you are looking for examples, just run: "
+"<command>apt-cache search .|grep dummy</command> or <command>apt-cache "
+"search .|grep transitional</command>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:1520
+msgid "Best practices for <filename>orig.tar.gz</filename> files"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1522
+msgid ""
+"There are two kinds of original source tarballs: Pristine source and "
+"repackaged upstream source."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:1526
+msgid "Pristine source"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para><footnote>
+#: best-pkging-practices.dbk:1528
+msgid ""
+"The defining characteristic of a pristine source tarball is that the "
+".orig.tar.gz file is byte-for-byte identical to a tarball officially "
+"distributed by the upstream author. <footnote>"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para><footnote><para>
+#: best-pkging-practices.dbk:1530
+msgid ""
+"We cannot prevent upstream authors from changing the tarball they distribute "
+"without also incrementing the version number, so there can be no guarantee "
+"that a pristine tarball is identical to what upstream "
+"<emphasis>currently</emphasis> distributing at any point in time. All that "
+"can be expected is that it is identical to something that upstream once "
+"<emphasis>did</emphasis> distribute. If a difference arises later (say, if "
+"upstream notices that he wasn't using maximal comression in his original "
+"distribution and then re-<literal>gzip</literal>s it), that's just too bad. "
+"Since there is no good way to upload a new .orig.tar.gz for the same "
+"version, there is not even any point in treating this situation as a bug."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1540
+msgid ""
+"</footnote> This makes it possible to use checksums to easily verify that "
+"all changes between Debian's version and upstream's are contained in the "
+"Debian diff. Also, if the original source is huge, upstream authors and "
+"others who already have the upstream tarball can save download time if they "
+"want to inspect your packaging in detail."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1548
+msgid ""
+"There is no universally accepted guidelines that upstream authors follow "
+"regarding to the directory structure inside their tarball, but "
+"<command>dpkg-source</command> is nevertheless able to deal with most "
+"upstream tarballs as pristine source. Its strategy is equivalent to the "
+"following:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
+#: best-pkging-practices.dbk:1556
+msgid "It unpacks the tarball in an empty temporary directory by doing"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><screen>
+#: best-pkging-practices.dbk:1559
+#, no-wrap
+msgid ""
+"zcat path/to/<packagename>_<upstream-version>.orig.tar.gz | tar "
+"xf -"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
+#: best-pkging-practices.dbk:1564
+msgid ""
+"If, after this, the temporary directory contains nothing but one directory "
+"and no other files, <command>dpkg-source</command> renames that directory to "
+"<literal><packagename>-<upstream-version>(.orig)</literal>. The "
+"name of the top-level directory in the tarball does not matter, and is "
+"forgotten."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
+#: best-pkging-practices.dbk:1573
+msgid ""
+"Otherwise, the upstream tarball must have been packaged without a common "
+"top-level directory (shame on the upstream author!). In this case, "
+"<command>dpkg-source</command> renames the temporary directory "
+"<emphasis>itself</emphasis> to "
+"<literal><packagename>-<upstream-version>(.orig)</literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:1584
+msgid "Repackaged upstream source"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1586
+msgid ""
+"You <emphasis role=\"strong\">should</emphasis> upload packages with a "
+"pristine source tarball if possible, but there are various reasons why it "
+"might not be possible. This is the case if upstream does not distribute the "
+"source as gzipped tar at all, or if upstream's tarball contains "
+"non-DFSG-free material that you must remove before uploading."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1593
+msgid ""
+"In these cases the developer must construct a suitable .orig.tar.gz file "
+"himself. We refer to such a tarball as a repackaged upstream source. Note "
+"that a repackaged upstream source is different from a Debian-native "
+"package. A repackaged source still comes with Debian-specific changes in a "
+"separate <literal>.diff.gz</literal> and still has a version number composed "
+"of <literal><upstream-version></literal> and "
+"<literal><debian-revision></literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1602
+msgid ""
+"There may be cases where it is desirable to repackage the source even though "
+"upstream distributes a <literal>.tar.gz</literal> that could in principle be "
+"used in its pristine form. The most obvious is if "
+"<emphasis>significant</emphasis> space savings can be achieved by "
+"recompressing the tar archive or by removing genuinely useless cruft from "
+"the upstream archive. Use your own discretion here, but be prepared to "
+"defend your decision if you repackage source that could have been pristine."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1611
+msgid "A repackaged .orig.tar.gz"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
+#: best-pkging-practices.dbk:1616
+msgid ""
+"<emphasis role=\"strong\">must</emphasis> contain detailed information how "
+"the repackaged source was obtained, and how this can be reproduced in the "
+"<filename>debian/copyright</filename>. It is also a good idea to provide a "
+"<literal>get-orig-source</literal> target in your "
+"<filename>debian/rules</filename> file that repeats the process, as "
+"described in the Policy Manual, <ulink "
+"url=\"&url-debian-policy;ch-source.html#s-debianrules\">Main building "
+"script: debian/rules</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para><footnote>
+#: best-pkging-practices.dbk:1628
+msgid ""
+"<emphasis role=\"strong\">should not</emphasis> contain any file that does "
+"not come from the upstream author(s), or whose contents has been changed by "
+"you. <footnote>"
+msgstr ""
+
+#. or similarly named
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para><footnote><para>
+#: best-pkging-practices.dbk:1630
+msgid ""
+"As a special exception, if the omission of non-free files would lead to the "
+"source failing to build without assistance from the Debian diff, it might be "
+"appropriate to instead edit the files, omitting only the non-free parts of "
+"them, and/or explain the situation in a README.Debian-source file in the "
+"root of the source tree. But in that case please also urge the upstream "
+"author to make the non-free components easier seperable from the rest of the "
+"source."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
+#: best-pkging-practices.dbk:1642
+msgid ""
+"<emphasis role=\"strong\">should</emphasis>, except where impossible for "
+"legal reasons, preserve the entire building and portablility infrastructure "
+"provided by the upstream author. For example, it is not a sufficient reason "
+"for omitting a file that it is used only when building on MS-DOS. "
+"Similarly, a Makefile provided by upstream should not be omitted even if the "
+"first thing your <filename>debian/rules</filename> does is to overwrite it "
+"by running a configure script."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
+#: best-pkging-practices.dbk:1651
+msgid ""
+"(<emphasis>Rationale:</emphasis> It is common for Debian users who need to "
+"build software for non-Debian platforms to fetch the source from a Debian "
+"mirror rather than trying to locate a canonical upstream distribution "
+"point)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
+#: best-pkging-practices.dbk:1658
+msgid ""
+"<emphasis role=\"strong\">should</emphasis> use "
+"<literal><packagename>-<upstream-version>.orig</literal> as the "
+"name of the top-level directory in its tarball. This makes it possible to "
+"distinguish pristine tarballs from repackaged ones."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
+#: best-pkging-practices.dbk:1666
+msgid ""
+"<emphasis role=\"strong\">should</emphasis> be gzipped with maximal "
+"compression."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1671
+msgid ""
+"The canonical way to meet the latter two points is to let "
+"<literal>dpkg-source -b</literal> construct the repackaged tarball from an "
+"unpacked directory."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: best-pkging-practices.dbk:1677
+msgid "Changing binary files in <literal>diff.gz</literal>"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para><footnote>
+#: best-pkging-practices.dbk:1679
+msgid ""
+"Sometimes it is necessary to change binary files contained in the original "
+"tarball, or to add binary files that are not in it. If this is done by "
+"simply copying the files into the debianized source tree, "
+"<command>dpkg-source</command> will not be able to handle this. On the "
+"other hand, according to the guidelines given above, you cannot include such "
+"a changed binary file in a repackaged <filename>orig.tar.gz</filename>. "
+"Instead, include the file in the <filename>debian</filename> directory in "
+"<command>uuencode</command>d (or similar) form <footnote>"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para><footnote><para>
+#: best-pkging-practices.dbk:1686
+msgid ""
+"The file should have a name that makes it clear which binary file it "
+"encodes. Usually, some postfix indicating the encoding should be appended "
+"to the original filename. Note that you don't need to depend on <systemitem "
+"role=\"package\">sharutils</systemitem> to get the "
+"<command>uudecode</command> program if you use <command>perl</command>'s "
+"<literal>pack</literal> function. The code could look like"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1694
+msgid ""
+"&example-uu; </footnote>. The file would then be decoded and copied to its "
+"place during the build process. Thus the change will be visible quite easy."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: best-pkging-practices.dbk:1700
+msgid ""
+"Some packages use <command>dbs</command> to manage patches to their upstream "
+"source, and always create a new <literal>orig.tar.gz</literal> file that "
+"contains the real <literal>orig.tar.gz</literal> in its toplevel directory. "
+"This is questionable with respect to the preference for pristine source. On "
+"the other hand, it is easy to modify or add binary files in this case: Just "
+"put them into the newly created <literal>orig.tar.gz</literal> file, besides "
+"the real one, and copy them to the right place during the build process."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: best-pkging-practices.dbk:1713
+msgid "Best practices for debug packages"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1715
+msgid ""
+"A debug package is a package with a name ending in -dbg, that contains "
+"additional information that gdb can use. Since Debian binaries are stripped "
+"by default, debugging information, including function names and line "
+"numbers, is otherwise not available when running gdb on Debian binaries. "
+"Debug packages allow users who need this additional debugging information to "
+"install it, without bloating a regular system with the information."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1723
+msgid ""
+"It is up to a package's maintainer whether to create a debug package or "
+"not. Maintainers are encouraged to create debug packages for library "
+"packages, since this can aid in debugging many programs linked to a "
+"library. In general, debug packages do not need to be added for all "
+"programs; doing so would bloat the archive. But if a maintainer finds that "
+"users often need a debugging version of a program, it can be worthwhile to "
+"make a debug package for it. Programs that are core infrastructure, such as "
+"apache and the X server are also good candidates for debug packages."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1733
+msgid ""
+"Some debug packages may contain an entire special debugging build of a "
+"library or other binary, but most of them can save space and build time by "
+"instead containing separated debugging symbols that gdb can find and load on "
+"the fly when debugging a program or library. The convention in Debian is to "
+"keep these symbols in <filename>/usr/lib/debug/path</filename>, where "
+"<emphasis>path</emphasis> is the path to the executable or library. For "
+"example, debugging symbols for <filename>/usr/bin/foo</filename> go in "
+"<filename>/usr/lib/debug/usr/bin/foo</filename>, and debugging symbols for "
+"<filename>/usr/lib/libfoo.so.1</filename> go in "
+"<filename>/usr/lib/debug/usr/lib/libfoo.so.1</filename>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1745
+msgid ""
+"The debugging symbols can be extracted from an object file using objcopy "
+"--only-keep-debug. Then the object file can be stripped, and objcopy "
+"--add-gnu-debuglink used to specify the path to the debugging symbol file. "
+"<citerefentry> <refentrytitle>objcopy</refentrytitle> "
+"<manvolnum>1</manvolnum> </citerefentry> explains in detail how this works."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1752
+msgid ""
+"The dh_strip command in debhelper supports creating debug packages, and can "
+"take care of using objcopy to separate out the debugging symbols for you. "
+"If your package uses debhelper, all you need to do is call dh_strip "
+"--dbg-package=libfoo-dbg, and add an entry to debian/control for the debug "
+"package."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: best-pkging-practices.dbk:1759
+msgid ""
+"Note that the Debian package should depend on the package that it provides "
+"debugging symbols for, and this dependency should be versioned. For "
+"example:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: best-pkging-practices.dbk:1763
+#, no-wrap
+msgid "Depends: libfoo-dbg (= ${binary:Version})"
+msgstr ""
--- /dev/null
+# SOME DESCRIPTIVE TITLE
+# Copyright (C) YEAR Free Software Foundation, Inc.
+# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
+#
+#, fuzzy
+msgid ""
+msgstr ""
+"Project-Id-Version: PACKAGE VERSION\n"
+"POT-Creation-Date: 2007-07-01 21:01+0000\n"
+"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
+"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
+"Language-Team: LANGUAGE <LL@li.org>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=utf-8\n"
+"Content-Transfer-Encoding: ENCODING"
+
+# type: Content of: <chapter><title>
+#: beyond-pkging.dbk:7
+msgid "Beyond Packaging"
+msgstr ""
+
+# type: Content of: <chapter><para>
+#: beyond-pkging.dbk:9
+msgid ""
+"Debian is about a lot more than just packaging software and maintaining "
+"those packages. This chapter contains information about ways, often really "
+"critical ways, to contribute to Debian beyond simply creating and "
+"maintaining packages."
+msgstr ""
+
+# type: Content of: <chapter><para>
+#: beyond-pkging.dbk:14
+msgid ""
+"As a volunteer organization, Debian relies on the discretion of its members "
+"in choosing what they want to work on and in choosing the most critical "
+"thing to spend their time on."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: beyond-pkging.dbk:19
+msgid "Bug reporting"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:21
+msgid ""
+"We encourage you to file bugs as you find them in Debian packages. In fact, "
+"Debian developers are often the first line testers. Finding and reporting "
+"bugs in other developers' packages improves the quality of Debian."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:26
+msgid ""
+"Read the <ulink url=\"&url-bts-report;\">instructions for reporting "
+"bugs</ulink> in the Debian <ulink url=\"&url-bts;\">bug tracking "
+"system</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:31
+msgid ""
+"Try to submit the bug from a normal user account at which you are likely to "
+"receive mail, so that people can reach you if they need further information "
+"about the bug. Do not submit bugs as root."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:36
+msgid ""
+"You can use a tool like <citerefentry> "
+"<refentrytitle>reportbug</refentrytitle> <manvolnum>1</manvolnum> "
+"</citerefentry> to submit bugs. It can automate and generally ease the "
+"process."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:41
+msgid ""
+"Make sure the bug is not already filed against a package. Each package has "
+"a bug list easily reachable at "
+"<literal>http://&bugs-host;/<replaceable>packagename</replaceable></literal> "
+"Utilities like <citerefentry> <refentrytitle>querybts</refentrytitle> "
+"<manvolnum>1</manvolnum> </citerefentry> can also provide you with this "
+"information (and <command>reportbug</command> will usually invoke "
+"<command>querybts</command> before sending, too)."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:50
+msgid ""
+"Try to direct your bugs to the proper location. When for example your bug "
+"is about a package which overwrites files from another package, check the "
+"bug lists for <emphasis>both</emphasis> of those packages in order to avoid "
+"filing duplicate bug reports."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:56
+msgid ""
+"For extra credit, you can go through other packages, merging bugs which are "
+"reported more than once, or tagging bugs `fixed' when they have already been "
+"fixed. Note that when you are neither the bug submitter nor the package "
+"maintainer, you should not actually close the bug (unless you secure "
+"permission from the maintainer)."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:63
+msgid ""
+"From time to time you may want to check what has been going on with the bug "
+"reports that you submitted. Take this opportunity to close those that you "
+"can't reproduce anymore. To find out all the bugs you submitted, you just "
+"have to visit "
+"<literal>http://&bugs-host;/from:<replaceable><your-email-addr></replaceable></literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: beyond-pkging.dbk:70
+msgid "Reporting lots of bugs at once (mass bug filing)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:72
+msgid ""
+"Reporting a great number of bugs for the same problem on a great number of "
+"different packages — i.e., more than 10 — is a deprecated practice. Take "
+"all possible steps to avoid submitting bulk bugs at all. For instance, if "
+"checking for the problem can be automated, add a new check to <systemitem "
+"role=\"package\">lintian</systemitem> so that an error or warning is "
+"emitted."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:79
+msgid ""
+"If you report more than 10 bugs on the same topic at once, it is recommended "
+"that you send a message to &email-debian-devel; describing your intention "
+"before submitting the report, and mentioning the fact in the subject of your "
+"mail. This will allow other developers to verify that the bug is a real "
+"problem. In addition, it will help prevent a situation in which several "
+"maintainers start filing the same bug report simultaneously."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:87
+msgid ""
+"Please use the programms <command>dd-list</command> and if appropriate "
+"<command>whodepends</command> (from the package devscripts) to generate a "
+"list of all affected packages, and include the output in your mail to "
+"&email-debian-devel;."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:93
+msgid ""
+"Note that when sending lots of bugs on the same subject, you should send the "
+"bug report to <email>maintonly@&bugs-host;</email> so that the bug report is "
+"not forwarded to the bug distribution mailing list."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: beyond-pkging.dbk:102
+msgid "Quality Assurance effort"
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: beyond-pkging.dbk:104
+msgid "Daily work"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:106
+msgid ""
+"Even though there is a dedicated group of people for Quality Assurance, QA "
+"duties are not reserved solely for them. You can participate in this effort "
+"by keeping your packages as bug-free as possible, and as lintian-clean (see "
+"<xref linkend=\"lintian\"/> ) as possible. If you do not find that "
+"possible, then you should consider orphaning some of your packages (see "
+"<xref linkend=\"orphaning\"/> ). Alternatively, you may ask the help of "
+"other people in order to catch up with the backlog of bugs that you have "
+"(you can ask for help on &email-debian-qa; or &email-debian-devel;). At the "
+"same time, you can look for co-maintainers (see <xref "
+"linkend=\"collaborative-maint\"/> )."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: beyond-pkging.dbk:120
+msgid "Bug squashing parties"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:122
+msgid ""
+"From time to time the QA group organizes bug squashing parties to get rid of "
+"as many problems as possible. They are announced on "
+"&email-debian-devel-announce; and the announcement explains which area will "
+"be the focus of the party: usually they focus on release critical bugs but "
+"it may happen that they decide to help finish a major upgrade (like a new "
+"perl version which requires recompilation of all the binary modules)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:131
+msgid ""
+"The rules for non-maintainer uploads differ during the parties because the "
+"announcement of the party is considered prior notice for NMU. If you have "
+"packages that may be affected by the party (because they have release "
+"critical bugs for example), you should send an update to each of the "
+"corresponding bug to explain their current status and what you expect from "
+"the party. If you don't want an NMU, or if you're only interested in a "
+"patch, or if you will deal yourself with the bug, please explain that in the "
+"BTS."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:140
+msgid ""
+"People participating in the party have special rules for NMU, they can NMU "
+"without prior notice if they upload their NMU to DELAYED/3-day at least. "
+"All other NMU rules apply as usually; they should send the patch of the NMU "
+"to the BTS (to one of the open bugs fixed by the NMU, or to a new bug, "
+"tagged fixed). They should also respect any particular wishes of the "
+"maintainer."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:147
+msgid ""
+"If you don't feel confident about doing an NMU, just send a patch to the "
+"BTS. It's far better than a broken NMU."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: beyond-pkging.dbk:155
+msgid "Contacting other maintainers"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:157
+msgid ""
+"During your lifetime within Debian, you will have to contact other "
+"maintainers for various reasons. You may want to discuss a new way of "
+"cooperating between a set of related packages, or you may simply remind "
+"someone that a new upstream version is available and that you need it."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:163
+msgid ""
+"Looking up the email address of the maintainer for the package can be "
+"distracting. Fortunately, there is a simple email alias, "
+"<literal><package>@&packages-host;</literal>, which provides a way to "
+"email the maintainer, whatever their individual email address (or addresses) "
+"may be. Replace <literal><package></literal> with the name of a "
+"source or a binary package."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:171
+msgid ""
+"You may also be interested in contacting the persons who are subscribed to a "
+"given source package via <xref linkend=\"pkg-tracking-system\"/> . You can "
+"do so by using the <literal><package>@&pts-host;</literal> email "
+"address."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: beyond-pkging.dbk:180
+msgid "Dealing with inactive and/or unreachable maintainers"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:182
+msgid ""
+"If you notice that a package is lacking maintenance, you should make sure "
+"that the maintainer is active and will continue to work on their packages. "
+"It is possible that they are not active any more, but haven't registered out "
+"of the system, so to speak. On the other hand, it is also possible that "
+"they just need a reminder."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:189
+msgid ""
+"There is a simple system (the MIA database) in which information about "
+"maintainers who are deemed Missing In Action is recorded. When a member of "
+"the QA group contacts an inactive maintainer or finds more information about "
+"one, this is recorded in the MIA database. This system is available in "
+"/org/qa.debian.org/mia on the host qa.debian.org, and can be queried with a "
+"tool known as <command>mia-query</command>. Use <command>mia-query "
+"--help</command> to see how to query the database. If you find that no "
+"information has been recorded about an inactive maintainer yet, or that you "
+"can add more information, you should generally proceed as follows."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:200
+msgid ""
+"The first step is to politely contact the maintainer, and wait a reasonable "
+"time for a response. It is quite hard to define reasonable time, but it is "
+"important to take into account that real life is sometimes very hectic. One "
+"way to handle this would be to send a reminder after two weeks."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:206
+msgid ""
+"If the maintainer doesn't reply within four weeks (a month), one can assume "
+"that a response will probably not happen. If that happens, you should "
+"investigate further, and try to gather as much useful information about the "
+"maintainer in question as possible. This includes:"
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: beyond-pkging.dbk:214
+msgid ""
+"The echelon information available through the <ulink "
+"url=\"&url-debian-db;\">developers' LDAP database</ulink>, which indicates "
+"when the developer last posted to a Debian mailing list. (This includes "
+"uploads via debian-*-changes lists.) Also, remember to check whether the "
+"maintainer is marked as on vacation in the database."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: beyond-pkging.dbk:223
+msgid ""
+"The number of packages this maintainer is responsible for, and the condition "
+"of those packages. In particular, are there any RC bugs that have been open "
+"for ages? Furthermore, how many bugs are there in general? Another important "
+"piece of information is whether the packages have been NMUed, and if so, by "
+"whom."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: beyond-pkging.dbk:232
+msgid ""
+"Is there any activity of the maintainer outside of Debian? For example, they "
+"might have posted something recently to non-Debian mailing lists or news "
+"groups."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:239
+msgid ""
+"A bit of a problem are packages which were sponsored — the maintainer is not "
+"an official Debian developer. The echelon information is not available for "
+"sponsored people, for example, so you need to find and contact the Debian "
+"developer who has actually uploaded the package. Given that they signed the "
+"package, they're responsible for the upload anyhow, and are likely to know "
+"what happened to the person they sponsored."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:247
+msgid ""
+"It is also allowed to post a query to &email-debian-devel;, asking if anyone "
+"is aware of the whereabouts of the missing maintainer. Please Cc: the "
+"person in question."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:252
+msgid ""
+"Once you have gathered all of this, you can contact &email-mia;. People on "
+"this alias will use the information you provide in order to decide how to "
+"proceed. For example, they might orphan one or all of the packages of the "
+"maintainer. If a package has been NMUed, they might prefer to contact the "
+"NMUer before orphaning the package — perhaps the person who has done the NMU "
+"is interested in the package."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:260
+msgid ""
+"One last word: please remember to be polite. We are all volunteers and "
+"cannot dedicate all of our time to Debian. Also, you are not aware of the "
+"circumstances of the person who is involved. Perhaps they might be "
+"seriously ill or might even have died — you do not know who may be on the "
+"receiving side. Imagine how a relative will feel if they read the e-mail of "
+"the deceased and find a very impolite, angry and accusing message!"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:268
+msgid ""
+"On the other hand, although we are volunteers, we do have a responsibility. "
+"So you can stress the importance of the greater good — if a maintainer does "
+"not have the time or interest anymore, they should let go and give the "
+"package to someone with more time."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:274
+msgid ""
+"If you are interested in working in the MIA team, please have a look at the "
+"README file in /org/qa.debian.org/mia on qa.debian.org where the technical "
+"details and the MIA procedures are documented and contact &email-mia;."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: beyond-pkging.dbk:282
+msgid "Interacting with prospective Debian developers"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: beyond-pkging.dbk:284
+msgid ""
+"Debian's success depends on its ability to attract and retain new and "
+"talented volunteers. If you are an experienced developer, we recommend that "
+"you get involved with the process of bringing in new developers. This "
+"section describes how to help new prospective developers."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: beyond-pkging.dbk:290
+msgid "Sponsoring packages"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:292
+msgid ""
+"Sponsoring a package means uploading a package for a maintainer who is not "
+"able to do it on their own, a new maintainer applicant. Sponsoring a "
+"package also means accepting responsibility for it."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:303
+msgid ""
+"New maintainers usually have certain difficulties creating Debian packages — "
+"this is quite understandable. That is why the sponsor is there, to check "
+"the package and verify that it is good enough for inclusion in Debian. "
+"(Note that if the sponsored package is new, the ftpmasters will also have to "
+"inspect it before letting it in.)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:310
+msgid ""
+"Sponsoring merely by signing the upload or just recompiling is <emphasis "
+"role=\"strong\">definitely not recommended</emphasis>. You need to build "
+"the source package just like you would build a package of your own. "
+"Remember that it doesn't matter that you left the prospective developer's "
+"name both in the changelog and the control file, the upload can still be "
+"traced to you."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:317
+msgid ""
+"If you are an application manager for a prospective developer, you can also "
+"be their sponsor. That way you can also verify how the applicant is "
+"handling the 'Tasks and Skills' part of their application."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: beyond-pkging.dbk:324
+msgid "Managing sponsored packages"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:326
+msgid ""
+"By uploading a sponsored package to Debian, you are certifying that the "
+"package meets minimum Debian standards. That implies that you must build "
+"and test the package on your own system before uploading."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:331
+msgid ""
+"You cannot simply upload a binary <filename>.deb</filename> from the "
+"sponsoree. In theory, you should only ask for the diff file and the "
+"location of the original source tarball, and then you should download the "
+"source and apply the diff yourself. In practice, you may want to use the "
+"source package built by your sponsoree. In that case, you have to check "
+"that they haven't altered the upstream files in the "
+"<filename>.orig.tar.gz</filename> file that they're providing."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:340
+msgid ""
+"Do not be afraid to write the sponsoree back and point out changes that need "
+"to be made. It often takes several rounds of back-and-forth email before "
+"the package is in acceptable shape. Being a sponsor means being a mentor."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:345
+msgid "Once the package meets Debian standards, build and sign it with"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: beyond-pkging.dbk:348
+#, no-wrap
+msgid "dpkg-buildpackage -k<replaceable>KEY-ID</replaceable>"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:351
+msgid ""
+"before uploading it to the incoming directory. Of course, you can also use "
+"any part of your <replaceable>KEY-ID</replaceable>, as long as it's unique "
+"in your secret keyring."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:356
+msgid ""
+"The Maintainer field of the <filename>control</filename> file and the "
+"<filename>changelog</filename> should list the person who did the packaging, "
+"i.e., the sponsoree. The sponsoree will therefore get all the BTS mail "
+"about the package."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:362
+msgid ""
+"If you prefer to leave a more evident trace of your sponsorship job, you can "
+"add a line stating it in the most recent changelog entry."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:366
+msgid ""
+"You are encouraged to keep tabs on the package you sponsor using <xref "
+"linkend=\"pkg-tracking-system\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: beyond-pkging.dbk:372
+msgid "Advocating new developers"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:374
+msgid ""
+"See the page about <ulink url=\"&url-newmaint-advocate;\">advocating a "
+"prospective developer</ulink> at the Debian web site."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: beyond-pkging.dbk:381
+msgid "Handling new maintainer applications"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: beyond-pkging.dbk:383
+msgid ""
+"Please see <ulink url=\"&url-newmaint-amchecklist;\">Checklist for "
+"Application Managers</ulink> at the Debian web site."
+msgstr ""
--- /dev/null
+# SOME DESCRIPTIVE TITLE
+# Copyright (C) YEAR Free Software Foundation, Inc.
+# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
+#
+#, fuzzy
+msgid ""
+msgstr ""
+"Project-Id-Version: PACKAGE VERSION\n"
+"POT-Creation-Date: 2007-07-01 21:01+0000\n"
+"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
+"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
+"Language-Team: LANGUAGE <LL@li.org>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=utf-8\n"
+"Content-Transfer-Encoding: ENCODING"
+
+# type: Content of: <chapter><title>
+#: developer-duties.dbk:7
+msgid "Debian Developer's Duties"
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: developer-duties.dbk:9
+msgid "Maintaining your Debian information"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:11
+msgid ""
+"There's a LDAP database containing information about Debian developers at "
+"<ulink url=\"&url-debian-db;\"></ulink>. You should enter your information "
+"there and update it as it changes. Most notably, make sure that the address "
+"where your debian.org email gets forwarded to is always up to date, as well "
+"as the address where you get your debian-private subscription if you choose "
+"to subscribe there."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:19
+msgid ""
+"For more information about the database, please see <xref "
+"linkend=\"devel-db\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: developer-duties.dbk:25
+msgid "Maintaining your public key"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:27
+msgid ""
+"Be very careful with your private keys. Do not place them on any public "
+"servers or multiuser machines, such as the Debian servers (see <xref "
+"linkend=\"server-machines\"/> ). Back your keys up; keep a copy offline. "
+"Read the documentation that comes with your software; read the <ulink "
+"url=\"&url-pgp-faq;\">PGP FAQ</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:34
+msgid ""
+"You need to ensure not only that your key is secure against being stolen, "
+"but also that it is secure against being lost. Generate and make a copy "
+"(best also in paper form) of your revocation certificate; this is needed if "
+"your key is lost."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:40
+msgid ""
+"If you add signatures to your public key, or add user identities, you can "
+"update the Debian key ring by sending your key to the key server at "
+"<literal>&keyserver-host;</literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:45
+msgid ""
+"If you need to add a completely new key or remove an old key, you need to "
+"get the new key signed by another developer. If the old key is compromised "
+"or invalid, you also have to add the revocation certificate. If there is no "
+"real reason for a new key, the Keyring Maintainers might reject the new "
+"key. Details can be found at <ulink "
+"url=\"http://&keyserver-host;/replacing_keys.html\"></ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:53
+msgid ""
+"The same key extraction routines discussed in <xref "
+"linkend=\"registering\"/> apply."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:57
+msgid ""
+"You can find a more in-depth discussion of Debian key maintenance in the "
+"documentation of the <systemitem "
+"role=\"package\">debian-keyring</systemitem> package."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: developer-duties.dbk:64
+msgid "Voting"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:66
+msgid ""
+"Even though Debian isn't really a democracy, we use a democratic process to "
+"elect our leaders and to approve general resolutions. These procedures are "
+"defined by the <ulink url=\"&url-constitution;\">Debian "
+"Constitution</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:72
+msgid ""
+"Other than the yearly leader election, votes are not routinely held, and "
+"they are not undertaken lightly. Each proposal is first discussed on the "
+"&email-debian-vote; mailing list and it requires several endorsements before "
+"the project secretary starts the voting procedure."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:78
+msgid ""
+"You don't have to track the pre-vote discussions, as the secretary will "
+"issue several calls for votes on &email-debian-devel-announce; (and all "
+"developers are expected to be subscribed to that list). Democracy doesn't "
+"work well if people don't take part in the vote, which is why we encourage "
+"all developers to vote. Voting is conducted via GPG-signed/encrypted email "
+"messages."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:86
+msgid ""
+"The list of all proposals (past and current) is available on the <ulink "
+"url=\"&url-vote;\">Debian Voting Information</ulink> page, along with "
+"information on how to make, second and vote on proposals."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: developer-duties.dbk:93
+msgid "Going on vacation gracefully"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:95
+msgid ""
+"It is common for developers to have periods of absence, whether those are "
+"planned vacations or simply being buried in other work. The important thing "
+"to notice is that other developers need to know that you're on vacation so "
+"that they can do whatever is needed if a problem occurs with your packages "
+"or other duties in the project."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:102
+msgid ""
+"Usually this means that other developers are allowed to NMU (see <xref "
+"linkend=\"nmu\"/> ) your package if a big problem (release critical bug, "
+"security update, etc.) occurs while you're on vacation. Sometimes it's "
+"nothing as critical as that, but it's still appropriate to let others know "
+"that you're unavailable."
+msgstr ""
+
+# type: Content of: <chapter><section><para><footnote>
+#: developer-duties.dbk:109
+msgid ""
+"In order to inform the other developers, there are two things that you "
+"should do. First send a mail to <email>debian-private@&lists-host;</email> "
+"with [VAC] prepended to the subject of your message<footnote>"
+msgstr ""
+
+# type: Content of: <chapter><section><para><footnote><para>
+#: developer-duties.dbk:111
+msgid ""
+"This is so that the message can be easily filtered by people who don't want "
+"to read vacation notices."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:113
+msgid ""
+"</footnote> and state the period of time when you will be on vacation. You "
+"can also give some special instructions on what to do if a problem occurs."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:118
+msgid ""
+"The other thing to do is to mark yourself as on vacation in the <link "
+"linkend=\"devel-db\">Debian developers' LDAP database</link> (this "
+"information is only accessible to Debian developers). Don't forget to "
+"remove the on vacation flag when you come back!"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:124
+msgid ""
+"Ideally, you should sign up at the <ulink "
+"url=\"&url-newmaint-db;gpg.php\">GPG coordination site</ulink> when booking "
+"a holiday and check if anyone there is looking for signing. This is "
+"especially important when people go to exotic places where we don't have any "
+"developers yet but where there are people who are interested in applying."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: developer-duties.dbk:133
+msgid "Coordination with upstream developers"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:135
+msgid ""
+"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 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."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:142
+msgid ""
+"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."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:149
+msgid ""
+"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 "
+"developers which can be included there, so that you won't have to modify the "
+"sources of the next upstream version. Whatever changes you need, always try "
+"not to fork from the upstream sources."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: developer-duties.dbk:158
+msgid "Managing release-critical bugs"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:160
+msgid ""
+"Generally you should deal with bug reports on your packages as described in "
+"<xref linkend=\"bug-handling\"/> . However, there's a special category of "
+"bugs that you need to take care of — the so-called release-critical bugs (RC "
+"bugs). All bug reports that have severity <emphasis>critical</emphasis>, "
+"<emphasis>grave</emphasis> or <emphasis>serious</emphasis> are considered to "
+"have an impact on whether the package can be released in the next stable "
+"release of Debian. These bugs can delay the Debian release and/or can "
+"justify the removal of a package at freeze time. That's why these bugs need "
+"to be corrected as quickly as possible."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:171
+msgid ""
+"Developers who are part of the <ulink url=\"&url-debian-qa;\">Quality "
+"Assurance</ulink> group are following all such bugs, and trying to help "
+"whenever possible. If, for any reason, you aren't able fix an RC bug in a "
+"package of yours within 2 weeks, you should either ask for help by sending a "
+"mail to the Quality Assurance (QA) group "
+"<email>debian-qa@&lists-host;</email>, or explain your difficulties and "
+"present a plan to fix them by sending a mail to the bug report. Otherwise, "
+"people from the QA group may want to do a Non-Maintainer Upload (see <xref "
+"linkend=\"nmu\"/> ) after trying to contact you (they might not wait as long "
+"as usual before they do their NMU if they have seen no recent activity from "
+"you in the BTS)."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: developer-duties.dbk:186
+msgid "Retiring"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: developer-duties.dbk:188
+msgid ""
+"If you choose to leave the Debian project, you should make sure you do the "
+"following steps:"
+msgstr ""
+
+# type: Content of: <chapter><section><orderedlist><listitem><para>
+#: developer-duties.dbk:194
+msgid "Orphan all your packages, as described in <xref linkend=\"orphaning\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><orderedlist><listitem><para>
+#: developer-duties.dbk:199
+msgid ""
+"Send an gpg-signed email about why you are leaving the project to "
+"<email>debian-private@&lists-host;</email>."
+msgstr ""
+
+# type: Content of: <chapter><section><orderedlist><listitem><para>
+#: developer-duties.dbk:205
+msgid ""
+"Notify the Debian key ring maintainers that you are leaving by opening a "
+"ticket in Debian RT by sending a mail to keyring@rt.debian.org with the "
+"words 'Debian RT' somewhere in the subject line (case doesn't matter)."
+msgstr ""
--- /dev/null
+# SOME DESCRIPTIVE TITLE
+# Copyright (C) YEAR Free Software Foundation, Inc.
+# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
+#
+#, fuzzy
+msgid ""
+msgstr ""
+"Project-Id-Version: PACKAGE VERSION\n"
+"POT-Creation-Date: 2007-07-01 21:01+0000\n"
+"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
+"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
+"Language-Team: LANGUAGE <LL@li.org>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=utf-8\n"
+"Content-Transfer-Encoding: ENCODING"
+
+# type: Attribute 'lang' of: <book>
+#: index.dbk:6
+msgid "en"
+msgstr ""
+
+# type: Content of: <book><title>
+#: index.dbk:8
+msgid "Debian Developer's Reference"
+msgstr ""
+
+# type: Content of: <book><bookinfo><releaseinfo>
+#: index.dbk:29
+msgid "ver. 3.3.9, 16 June, 2007"
+msgstr ""
+
+# type: Content of: <book><bookinfo><copyright><holder>
+#: index.dbk:36
+msgid "Andreas Barth"
+msgstr ""
+
+# type: Content of: <book><bookinfo><copyright><holder>
+#: index.dbk:45
+msgid "Adam Di Carlo"
+msgstr ""
+
+# type: Content of: <book><bookinfo><copyright><holder>
+#: index.dbk:50
+msgid "Raphaël Hertzog"
+msgstr ""
+
+# type: Content of: <book><bookinfo><copyright><holder>
+#: index.dbk:55
+msgid "Christian Schwarz"
+msgstr ""
+
+# type: Content of: <book><bookinfo><legalnotice><para>
+#: index.dbk:59
+msgid ""
+"This manual is free software; you may redistribute it and/or modify it under "
+"the terms of the GNU General Public License as published by the Free "
+"Software Foundation; either version 2, or (at your option) any later "
+"version."
+msgstr ""
+
+# type: Content of: <book><bookinfo><legalnotice><para>
+#: index.dbk:64
+msgid ""
+"This is distributed in the hope that it will be useful, but "
+"<emphasis>without any warranty</emphasis>; without even the implied warranty "
+"of merchantability or fitness for a particular purpose. See the GNU General "
+"Public License for more details."
+msgstr ""
+
+# type: Content of: <book><bookinfo><legalnotice><para>
+#: index.dbk:70
+msgid ""
+"A copy of the GNU General Public License is available as &file-GPL; in the "
+"&debian-formal; distribution or on the World Wide Web at <ulink "
+"url=\"&url-gpl;\">the GNU web site</ulink>. You can also obtain it by "
+"writing to the &fsf-addr;."
+msgstr ""
+
+#. TODO: Maybe better: "This document has originally been written
+#
+#. in English. Translations into different languages are available."
+# type: Content of: <book><bookinfo><legalnotice><para>
+#: index.dbk:77
+msgid ""
+"If you want to print this reference, you should use the <ulink "
+"url=\"developers-reference.pdf\">pdf version</ulink>. This page is also "
+"available in <ulink url=\"index.fr.html\">French</ulink>."
+msgstr ""
--- /dev/null
+# SOME DESCRIPTIVE TITLE
+# Copyright (C) YEAR Free Software Foundation, Inc.
+# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
+#
+#, fuzzy
+msgid ""
+msgstr ""
+"Project-Id-Version: PACKAGE VERSION\n"
+"POT-Creation-Date: 2007-07-01 21:01+0000\n"
+"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
+"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
+"Language-Team: LANGUAGE <LL@li.org>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=utf-8\n"
+"Content-Transfer-Encoding: ENCODING"
+
+# type: Content of: <chapter><title>
+#: l10n.dbk:7
+msgid ""
+"Internationalizing, translating, being internationalized and being "
+"translated"
+msgstr ""
+
+# type: Content of: <chapter><para>
+#: l10n.dbk:9
+msgid ""
+"Debian supports an ever-increasing number of natural languages. Even if you "
+"are a native English speaker and do not speak any other language, it is part "
+"of your duty as a maintainer to be aware of issues of internationalization "
+"(abbreviated i18n because there are 18 letters between the 'i' and the 'n' "
+"in internationalization). Therefore, even if you are ok with English-only "
+"programs, you should read most of this chapter."
+msgstr ""
+
+# type: Content of: <chapter><para>
+#: l10n.dbk:17
+msgid ""
+"According to <ulink "
+"url=\"http://&www-debian-org;/doc/manuals/intro-i18n/\">Introduction to "
+"i18n</ulink> from Tomohiro KUBOTA, I18N (internationalization) means "
+"modification of a software or related technologies so that a software can "
+"potentially handle multiple languages, customs, and so on in the world. "
+"while L10N (localization) means implementation of a specific language for an "
+"already internationalized software."
+msgstr ""
+
+# type: Content of: <chapter><para>
+#: l10n.dbk:26
+msgid ""
+"l10n and i18n are interconnected, but the difficulties related to each of "
+"them are very different. It's not really difficult to allow a program to "
+"change the language in which texts are displayed based on user settings, but "
+"it is very time consuming to actually translate these messages. On the "
+"other hand, setting the character encoding is trivial, but adapting the code "
+"to use several character encodings is a really hard problem."
+msgstr ""
+
+# type: Content of: <chapter><para>
+#: l10n.dbk:34
+msgid ""
+"Setting aside the i18n problems, where no general guideline can be given, "
+"there is actually no central infrastructure for l10n within Debian which "
+"could be compared to the dbuild mechanism for porting. So most of the work "
+"has to be done manually."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: l10n.dbk:40
+msgid "How translations are handled within Debian"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: l10n.dbk:42
+msgid ""
+"Handling translation of the texts contained in a package is still a manual "
+"task, and the process depends on the kind of text you want to see "
+"translated."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: l10n.dbk:46
+msgid ""
+"For program messages, the gettext infrastructure is used most of the time. "
+"Most of the time, the translation is handled upstream within projects like "
+"the <ulink url=\"http://www.iro.umontreal.ca/contrib/po/HTML/\">Free "
+"Translation Project</ulink>, the <ulink "
+"url=\"http://developer.gnome.org/projects/gtp/\">Gnome translation "
+"Project</ulink> or the <ulink url=\"http://i18n.kde.org/\">KDE one</ulink>. "
+"The only centralized resource within Debian is the <ulink "
+"url=\"http://&www-debian-org;/intl/l10n/\">Central Debian translation "
+"statistics</ulink>, where you can find some statistics about the translation "
+"files found in the actual packages, but no real infrastructure to ease the "
+"translation process."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: l10n.dbk:59
+msgid ""
+"An effort to translate the package descriptions started long ago, even if "
+"very little support is offered by the tools to actually use them (i.e., only "
+"APT can use them, when configured correctly). Maintainers don't need to do "
+"anything special to support translated package descriptions; translators "
+"should use the <ulink url=\"http://ddtp.debian.org/\">DDTP</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: l10n.dbk:66
+msgid ""
+"For debconf templates, maintainers should use the po-debconf package to ease "
+"the work of translators, who could use the DDTP to do their work (but the "
+"French and Brazilian teams don't). Some statistics can be found both on the "
+"DDTP site (about what is actually translated), and on the <ulink "
+"url=\"http://&www-debian-org;/intl/l10n/\">Central Debian translation "
+"statistics</ulink> site (about what is integrated in the packages)."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: l10n.dbk:74
+msgid ""
+"For web pages, each l10n team has access to the relevant CVS, and the "
+"statistics are available from the Central Debian translation statistics "
+"site."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: l10n.dbk:78
+msgid ""
+"For general documentation about Debian, the process is more or less the same "
+"as for the web pages (the translators have access to the CVS), but there are "
+"no statistics pages."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: l10n.dbk:83
+msgid ""
+"For package-specific documentation (man pages, info documents, other "
+"formats), almost everything remains to be done."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: l10n.dbk:87
+msgid ""
+"Most notably, the KDE project handles translation of its documentation in "
+"the same way as its program messages."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: l10n.dbk:91
+msgid ""
+"There is an effort to handle Debian-specific man pages within a <ulink "
+"url=\"&url-cvsweb;manpages/?cvsroot=debian-doc\">specific CVS "
+"repository</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: l10n.dbk:98
+msgid "I18N & L10N FAQ for maintainers"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: l10n.dbk:100
+msgid ""
+"This is a list of problems that maintainers may face concerning i18n and "
+"l10n. While reading this, keep in mind that there is no real consensus on "
+"these points within Debian, and that this is only advice. If you have a "
+"better idea for a given problem, or if you disagree on some points, feel "
+"free to provide your feedback, so that this document can be enhanced."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: l10n.dbk:107
+msgid "How to get a given text translated"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: l10n.dbk:109
+msgid ""
+"To translate package descriptions or debconf templates, you have nothing to "
+"do; the DDTP infrastructure will dispatch the material to translate to "
+"volunteers with no need for interaction from your part."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: l10n.dbk:114
+msgid ""
+"For all other material (gettext files, man pages, or other documentation), "
+"the best solution is to put your text somewhere on the Internet, and ask on "
+"debian-i18n for a translation in different languages. Some translation team "
+"members are subscribed to this list, and they will take care of the "
+"translation and of the reviewing process. Once they are done, you will get "
+"your translated document from them in your mailbox."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: l10n.dbk:124
+msgid "How to get a given translation reviewed"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: l10n.dbk:126
+msgid ""
+"From time to time, individuals translate some texts in your package and will "
+"ask you for inclusion of the translation in the package. This can become "
+"problematic if you are not fluent in the given language. It is a good idea "
+"to send the document to the corresponding l10n mailing list, asking for a "
+"review. Once it has been done, you should feel more confident in the "
+"quality of the translation, and feel safe to include it in your package."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: l10n.dbk:136
+msgid "How to get a given translation updated"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: l10n.dbk:138
+msgid ""
+"If you have some translations of a given text lying around, each time you "
+"update the original, you should ask the previous translator to update the "
+"translation with your new changes. Keep in mind that this task takes time; "
+"at least one week to get the update reviewed and all."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: l10n.dbk:144
+msgid ""
+"If the translator is unresponsive, you may ask for help on the corresponding "
+"l10n mailing list. If everything fails, don't forget to put a warning in "
+"the translated document, stating that the translation is somehow outdated, "
+"and that the reader should refer to the original document if possible."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: l10n.dbk:150
+msgid ""
+"Avoid removing a translation completely because it is outdated. Old "
+"documentation is often better than no documentation at all for non-English "
+"speakers."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: l10n.dbk:157
+msgid "How to handle a bug report concerning a translation"
+msgstr ""
+
+#. TODO: add the i18n tag to the bug?
+# type: Content of: <chapter><section><section><para>
+#: l10n.dbk:159
+msgid ""
+"The best solution may be to mark the bug as forwarded to upstream, and "
+"forward it to both the previous translator and his/her team (using the "
+"corresponding debian-l10n-XXX mailing list)."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: l10n.dbk:169
+msgid "I18N & L10N FAQ for translators"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: l10n.dbk:171
+msgid ""
+"While reading this, please keep in mind that there is no general procedure "
+"within Debian concerning these points, and that in any case, you should "
+"collaborate with your team and the package maintainer."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: l10n.dbk:176
+msgid "How to help the translation effort"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: l10n.dbk:178
+msgid ""
+"Choose what you want to translate, make sure that nobody is already working "
+"on it (using your debian-l10n-XXX mailing list), translate it, get it "
+"reviewed by other native speakers on your l10n mailing list, and provide it "
+"to the maintainer of the package (see next point)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: l10n.dbk:186
+msgid "How to provide a translation for inclusion in a package"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: l10n.dbk:188
+msgid ""
+"Make sure your translation is correct (asking for review on your l10n "
+"mailing list) before providing it for inclusion. It will save time for "
+"everyone, and avoid the chaos resulting in having several versions of the "
+"same document in bug reports."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: l10n.dbk:194
+msgid ""
+"The best solution is to file a regular bug containing the translation "
+"against the package. Make sure to use the 'PATCH' tag, and to not use a "
+"severity higher than 'wishlist', since the lack of translation never "
+"prevented a program from running."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: l10n.dbk:204
+msgid "Best current practice concerning l10n"
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: l10n.dbk:208
+msgid ""
+"As a maintainer, never edit the translations in any way (even to reformat "
+"the layout) without asking on the corresponding l10n mailing list. You risk "
+"for example breaksing the encoding of the file by doing so. Moreover, what "
+"you consider an error can be right (or even needed) in the given language."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: l10n.dbk:216
+msgid ""
+"As a translator, if you find an error in the original text, make sure to "
+"report it. Translators are often the most attentive readers of a given "
+"text, and if they don't report the errors they find, nobody will."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: l10n.dbk:223
+msgid ""
+"In any case, remember that the major issue with l10n is that it requires "
+"several people to cooperate, and that it is very easy to start a flamewar "
+"about small problems because of misunderstandings. So if you have problems "
+"with your interlocutor, ask for help on the corresponding l10n mailing list, "
+"on debian-i18n, or even on debian-devel (but beware, l10n discussions very "
+"often become flamewars on that list :)"
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: l10n.dbk:233
+msgid ""
+"In any case, cooperation can only be achieved with <emphasis "
+"role=\"strong\">mutual respect</emphasis>."
+msgstr ""
--- /dev/null
+# SOME DESCRIPTIVE TITLE
+# Copyright (C) YEAR Free Software Foundation, Inc.
+# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
+#
+#, fuzzy
+msgid ""
+msgstr ""
+"Project-Id-Version: PACKAGE VERSION\n"
+"POT-Creation-Date: 2007-07-01 21:01+0000\n"
+"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
+"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
+"Language-Team: LANGUAGE <LL@li.org>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=utf-8\n"
+"Content-Transfer-Encoding: ENCODING"
+
+# type: Content of: <chapter><title>
+#: new-maintainer.dbk:7
+msgid "Applying to Become a Maintainer"
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: new-maintainer.dbk:9
+msgid "Getting started"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:11
+msgid ""
+"So, you've read all the documentation, you've gone through the <ulink "
+"url=\"&url-newmaint-guide;\">Debian New Maintainers' Guide</ulink>, "
+"understand what everything in the <systemitem "
+"role=\"package\">hello</systemitem> example package is for, and you're about "
+"to Debianize your favorite piece of software. How do you actually become a "
+"Debian developer so that your work can be incorporated into the Project?"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:19
+msgid ""
+"Firstly, subscribe to &email-debian-devel; if you haven't already. Send the "
+"word <literal>subscribe</literal> in the <emphasis>Subject</emphasis> of an "
+"email to &email-debian-devel-req;. In case of problems, contact the list "
+"administrator at &email-listmaster;. More information on available mailing "
+"lists can be found in <xref linkend=\"mailing-lists\"/> . "
+"&email-debian-devel-announce; is another list which is mandatory for anyone "
+"who wishes to follow Debian's development."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:29
+msgid ""
+"You should subscribe and lurk (that is, read without posting) for a bit "
+"before doing any coding, and you should post about your intentions to work "
+"on something to avoid duplicated effort."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:34
+msgid ""
+"Another good list to subscribe to is &email-debian-mentors;. See <xref "
+"linkend=\"mentors\"/> for details. The IRC channel "
+"<literal>#debian</literal> can also be helpful; see <xref "
+"linkend=\"irc-channels\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:40
+msgid ""
+"When you know how you want to contribute to &debian-formal;, you should get "
+"in contact with existing Debian maintainers who are working on similar "
+"tasks. That way, you can learn from experienced developers. For example, "
+"if you are interested in packaging existing software for Debian, you should "
+"try to get a sponsor. A sponsor will work together with you on your package "
+"and upload it to the Debian archive once they are happy with the packaging "
+"work you have done. You can find a sponsor by mailing the "
+"&email-debian-mentors; mailing list, describing your package and yourself "
+"and asking for a sponsor (see <xref linkend=\"sponsoring\"/> and <ulink "
+"url=\"&url-mentors;\"></ulink> for more information on sponsoring). On the "
+"other hand, if you are interested in porting Debian to alternative "
+"architectures or kernels you can subscribe to port specific mailing lists "
+"and ask there how to get started. Finally, if you are interested in "
+"documentation or Quality Assurance (QA) work you can join maintainers "
+"already working on these tasks and submit patches and improvements."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:57
+msgid ""
+"One pitfall could be a too-generic local part in your mailadress: Terms like "
+"mail, admin, root, master should be avoided, please see <ulink "
+"url=\"&url-debian-lists;\"></ulink> for details."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: new-maintainer.dbk:64
+msgid "Debian mentors and sponsors"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:66
+msgid ""
+"The mailing list &email-debian-mentors; has been set up for novice "
+"maintainers who seek help with initial packaging and other developer-related "
+"issues. Every new developer is invited to subscribe to that list (see <xref "
+"linkend=\"mailing-lists\"/> for details)."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:72
+msgid ""
+"Those who prefer one-on-one help (e.g., via private email) should also post "
+"to that list and an experienced developer will volunteer to help."
+msgstr ""
+
+#. FIXME - out of order
+#
+#. Those who are seeking a
+#
+#. sponsor can request one at <ulink url="http://www.internatif.org/bortzmeyer/debian/sponsor/"></ulink>.
+#
+#
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:76
+msgid ""
+"In addition, if you have some packages ready for inclusion in Debian, but "
+"are waiting for your new maintainer application to go through, you might be "
+"able find a sponsor to upload your package for you. Sponsors are people who "
+"are official Debian Developers, and who are willing to criticize and upload "
+"your packages for you. Please read the unofficial debian-mentors FAQ at "
+"<ulink url=\"&url-mentors;\"></ulink> first."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:89
+msgid ""
+"If you wish to be a mentor and/or sponsor, more information is available in "
+"<xref linkend=\"newmaint\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: new-maintainer.dbk:95
+msgid "Registering as a Debian developer"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:97
+msgid ""
+"Before you decide to register with &debian-formal;, you will need to read "
+"all the information available at the <ulink url=\"&url-newmaint;\">New "
+"Maintainer's Corner</ulink>. It describes in detail the preparations you "
+"have to do before you can register to become a Debian developer. For "
+"example, before you apply, you have to read the <ulink "
+"url=\"&url-social-contract;\">Debian Social Contract</ulink>. Registering "
+"as a developer means that you agree with and pledge to uphold the Debian "
+"Social Contract; it is very important that maintainers are in accord with "
+"the essential ideas behind &debian-formal;. Reading the <ulink "
+"url=\"&url-gnu-manifesto;\">GNU Manifesto</ulink> would also be a good idea."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:111
+msgid ""
+"The process of registering as a developer is a process of verifying your "
+"identity and intentions, and checking your technical skills. As the number "
+"of people working on &debian-formal; has grown to over "
+"&number-of-maintainers; and our systems are used in several very important "
+"places, we have to be careful about being compromised. Therefore, we need "
+"to verify new maintainers before we can give them accounts on our servers "
+"and let them upload packages."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:120
+msgid ""
+"Before you actually register you should have shown that you can do competent "
+"work and will be a good contributor. You show this by submitting patches "
+"through the Bug Tracking System and having a package sponsored by an "
+"existing Debian Developer for a while. Also, we expect that contributors "
+"are interested in the whole project and not just in maintaining their own "
+"packages. If you can help other maintainers by providing further "
+"information on a bug or even a patch, then do so!"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:129
+msgid ""
+"Registration requires that you are familiar with Debian's philosophy and "
+"technical documentation. Furthermore, you need a GnuPG key which has been "
+"signed by an existing Debian maintainer. If your GnuPG key is not signed "
+"yet, you should try to meet a Debian Developer in person to get your key "
+"signed. There's a <ulink url=\"&url-gpg-coord;\">GnuPG Key Signing "
+"Coordination page</ulink> which should help you find a Debian Developer "
+"close to you. (If there is no Debian Developer close to you, alternative "
+"ways to pass the ID check may be permitted as an absolute exception on a "
+"case-by-case-basis. See the <ulink url=\"&url-newmaint-id;\">identification "
+"page</ulink> for more information.)"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:142
+msgid ""
+"If you do not have an OpenPGP key yet, generate one. Every developer needs "
+"an OpenPGP key in order to sign and verify package uploads. You should read "
+"the manual for the software you are using, since it has much important "
+"information which is critical to its security. Many more security failures "
+"are due to human error than to software failure or high-powered spy "
+"techniques. See <xref linkend=\"key-maint\"/> for more information on "
+"maintaining your public key."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:150
+msgid ""
+"Debian uses the <command>GNU Privacy Guard</command> (package <systemitem "
+"role=\"package\">gnupg</systemitem> version 1 or better) as its baseline "
+"standard. You can use some other implementation of OpenPGP as well. Note "
+"that OpenPGP is an open standard based on <ulink url=\"&url-rfc2440;\">RFC "
+"2440</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><para><footnote>
+#: new-maintainer.dbk:157
+msgid ""
+"You need a version 4 key for use in Debian Development. Your key length "
+"must be at least 1024 bits; there is no reason to use a smaller key, and "
+"doing so would be much less secure. <footnote>"
+msgstr ""
+
+# type: Content of: <chapter><section><para><footnote><para>
+#: new-maintainer.dbk:159
+msgid ""
+"Version 4 keys are keys conforming to the OpenPGP standard as defined in RFC "
+"2440. Version 4 is the key type that has always been created when using "
+"GnuPG. PGP versions since 5.x also could create v4 keys, the other choice "
+"having beein pgp 2.6.x compatible v3 keys (also called legacy RSA by PGP)."
+msgstr ""
+
+# type: Content of: <chapter><section><para><footnote><para>
+#: new-maintainer.dbk:163
+msgid ""
+"Version 4 (primary) keys can either use the RSA or the DSA algorithms, so "
+"this has nothing to do with GnuPG's question about which kind of key do you "
+"want: (1) DSA and Elgamal, (2) DSA (sign only), (5) RSA (sign only). If "
+"you don't have any special requirements just pick the default."
+msgstr ""
+
+# type: Content of: <chapter><section><para><footnote><para>
+#: new-maintainer.dbk:167
+msgid ""
+"The easiest way to tell whether an existing key is a v4 key or a v3 (or v2) "
+"key is to look at the fingerprint: Fingerprints of version 4 keys are the "
+"SHA-1 hash of some key material, so they are 40 hex digits, usually grouped "
+"in blocks of 4. Fingerprints of older key format versions used MD5 and are "
+"generally shown in blocks of 2 hex digits. For example if your fingerprint "
+"looks like "
+"<literal>5B00 C96D 5D54 AEE1 206B AF84 DE7A AF6E 94C0 9C7F</literal> then "
+"it's a v4 key."
+msgstr ""
+
+# type: Content of: <chapter><section><para><footnote><para>
+#: new-maintainer.dbk:174
+msgid ""
+"Another possibility is to pipe the key into <command>pgpdump</command>, "
+"which will say something like Public Key Packet - Ver 4."
+msgstr ""
+
+# type: Content of: <chapter><section><para><footnote><para>
+#: new-maintainer.dbk:176
+msgid ""
+"Also note that your key must be self-signed (i.e. it has to sign all its "
+"own user IDs; this prevents user ID tampering). All modern OpenPGP software "
+"does that automatically, but if you have an older key you may have to "
+"manually add those signatures."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:182
+msgid ""
+"If your public key isn't on a public key server such as &pgp-keyserv;, "
+"please read the documentation available at <ulink "
+"url=\"&url-newmaint-id;\">NM Step 2: Identification</ulink>. That document "
+"contains instructions on how to put your key on the public key servers. The "
+"New Maintainer Group will put your public key on the servers if it isn't "
+"already there."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:190
+msgid ""
+"Some countries restrict the use of cryptographic software by their "
+"citizens. This need not impede one's activities as a Debian package "
+"maintainer however, as it may be perfectly legal to use cryptographic "
+"products for authentication, rather than encryption purposes. If you live "
+"in a country where use of cryptography even for authentication is forbidden "
+"then please contact us so we can make special arrangements."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:198
+msgid ""
+"To apply as a new maintainer, you need an existing Debian Developer to "
+"support your application (an <emphasis>advocate</emphasis>). After you have "
+"contributed to Debian for a while, and you want to apply to become a "
+"registered developer, an existing developer with whom you have worked over "
+"the past months has to express their belief that you can contribute to "
+"Debian successfully."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:205
+msgid ""
+"When you have found an advocate, have your GnuPG key signed and have already "
+"contributed to Debian for a while, you're ready to apply. You can simply "
+"register on our <ulink url=\"&url-newmaint-apply;\">application "
+"page</ulink>. After you have signed up, your advocate has to confirm your "
+"application. When your advocate has completed this step you will be "
+"assigned an Application Manager who will go with you through the necessary "
+"steps of the New Maintainer process. You can always check your status on "
+"the <ulink url=\"&url-newmaint-db;\">applications status board</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: new-maintainer.dbk:215
+msgid ""
+"For more details, please consult <ulink url=\"&url-newmaint;\">New "
+"Maintainer's Corner</ulink> at the Debian web site. Make sure that you are "
+"familiar with the necessary steps of the New Maintainer process before "
+"actually applying. If you are well prepared, you can save a lot of time "
+"later on."
+msgstr ""
--- /dev/null
+# SOME DESCRIPTIVE TITLE
+# Copyright (C) YEAR Free Software Foundation, Inc.
+# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
+#
+#, fuzzy
+msgid ""
+msgstr ""
+"Project-Id-Version: PACKAGE VERSION\n"
+"POT-Creation-Date: 2007-07-01 21:01+0000\n"
+"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
+"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
+"Language-Team: LANGUAGE <LL@li.org>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=utf-8\n"
+"Content-Transfer-Encoding: ENCODING"
+
+# type: Content of: <chapter><title>
+#: pkgs.dbk:7
+msgid "Managing Packages"
+msgstr ""
+
+# type: Content of: <chapter><para>
+#: pkgs.dbk:9
+msgid ""
+"This chapter contains information related to creating, uploading, "
+"maintaining, and porting packages."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:13
+msgid "New packages"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:15
+msgid ""
+"If you want to create a new package for the Debian distribution, you should "
+"first check the <ulink url=\"&url-wnpp;\">Work-Needing and Prospective "
+"Packages (WNPP)</ulink> list. Checking the WNPP list ensures that no one is "
+"already working on packaging that software, and that effort is not "
+"duplicated. Read the <ulink url=\"&url-wnpp;\">WNPP web pages</ulink> for "
+"more information."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:23
+msgid ""
+"Assuming no one else is already working on your prospective package, you "
+"must then submit a bug report (<xref linkend=\"submit-bug\"/> ) against the "
+"pseudo-package <systemitem role=\"package\">wnpp</systemitem> describing "
+"your plan to create a new package, including, but not limiting yourself to, "
+"a description of the package, the license of the prospective package, and "
+"the current URL where it can be downloaded from."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:31
+msgid ""
+"You should set the subject of the bug to ``ITP: "
+"<replaceable>foo</replaceable> -- <replaceable>short "
+"description</replaceable>'', substituting the name of the new package for "
+"<replaceable>foo</replaceable>. The severity of the bug report must be set "
+"to <emphasis>wishlist</emphasis>. If you feel it's necessary, send a copy "
+"to &email-debian-devel; by putting the address in the "
+"<literal>X-Debbugs-CC:</literal> header of the message (no, don't use "
+"<literal>CC:</literal>, because that way the message's subject won't "
+"indicate the bug number)."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:41
+msgid ""
+"Please include a <literal>Closes: "
+"bug#<replaceable>nnnnn</replaceable></literal> entry in the changelog of the "
+"new package in order for the bug report to be automatically closed once the "
+"new package is installed in the archive (see <xref "
+"linkend=\"upload-bugfix\"/> )."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:47
+msgid ""
+"When closing security bugs include CVE numbers as well as the Closes: "
+"#nnnnn. This is useful for the security team to track vulnerabilities. If "
+"an upload is made to fix the bug before the advisory ID is known, it is "
+"encouraged to modify the historical changelog entry with the next upload. "
+"Even in this case, please include all available pointers to background "
+"information in the original changelog entry."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:55
+msgid ""
+"There are a number of reasons why we ask maintainers to announce their "
+"intentions:"
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:61
+msgid ""
+"It helps the (potentially new) maintainer to tap into the experience of "
+"people on the list, and lets them know if anyone else is working on it "
+"already."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:67
+msgid ""
+"It lets other people thinking about working on the package know that there "
+"already is a volunteer, so efforts may be shared."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:73
+msgid ""
+"It lets the rest of the maintainers know more about the package than the one "
+"line description and the usual changelog entry ``Initial release'' that gets "
+"posted to <literal>debian-devel-changes</literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:80
+msgid ""
+"It is helpful to the people who live off unstable (and form our first line "
+"of testers). We should encourage these people."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:86
+msgid ""
+"The announcements give maintainers and other interested parties a better "
+"feel of what is going on, and what is new, in the project."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:92
+msgid ""
+"Please see <ulink url=\"http://&ftp-master-host;/REJECT-FAQ.html\"></ulink> "
+"for common rejection reasons for a new package."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:98
+msgid "Recording changes in the package"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:100
+msgid ""
+"Changes that you make to the package need to be recorded in the "
+"<filename>debian/changelog</filename>. These changes should provide a "
+"concise description of what was changed, why (if it's in doubt), and note if "
+"any bugs were closed. They also record when the package was completed. "
+"This file will be installed in "
+"<filename>/usr/share/doc/<replaceable>package</replaceable>/changelog.Debian.gz</filename>, "
+"or "
+"<filename>/usr/share/doc/<replaceable>package</replaceable>/changelog.gz</filename> "
+"for native packages."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:111
+msgid ""
+"The <filename>debian/changelog</filename> file conforms to a certain "
+"structure, with a number of different fields. One field of note, the "
+"<emphasis>distribution</emphasis>, is described in <xref "
+"linkend=\"distribution\"/> . More information about the structure of this "
+"file can be found in the Debian Policy section titled "
+"<filename>debian/changelog</filename>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:119
+msgid ""
+"Changelog entries can be used to automatically close Debian bugs when the "
+"package is installed into the archive. See <xref "
+"linkend=\"upload-bugfix\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:123
+msgid ""
+"It is conventional that the changelog entry of a package that contains a new "
+"upstream version of the software looks like this:"
+msgstr ""
+
+# type: Content of: <chapter><section><screen>
+#: pkgs.dbk:127
+#, no-wrap
+msgid "* new upstream version"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:130
+msgid ""
+"There are tools to help you create entries and finalize the "
+"<filename>changelog</filename> for release — see <xref "
+"linkend=\"devscripts\"/> and <xref linkend=\"dpkg-dev-el\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:135
+msgid "See also <xref linkend=\"bpp-debian-changelog\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:140
+msgid "Testing the package"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:142
+msgid ""
+"Before you upload your package, you should do basic testing on it. At a "
+"minimum, you should try the following activities (you'll need to have an "
+"older version of the same Debian package around):"
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:149
+msgid ""
+"Install the package and make sure the software works, or upgrade the package "
+"from an older version to your new version if a Debian package for it already "
+"exists."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:156
+msgid ""
+"Run <command>lintian</command> over the package. You can run "
+"<command>lintian</command> as follows: <literal>lintian -v "
+"<replaceable>package-version</replaceable>.changes</literal>. This will "
+"check the source package as well as the binary package. If you don't "
+"understand the output that <command>lintian</command> generates, try adding "
+"the <literal>-i</literal> switch, which will cause "
+"<command>lintian</command> to output a very verbose description of the "
+"problem."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:165
+msgid ""
+"Normally, a package should <emphasis>not</emphasis> be uploaded if it causes "
+"lintian to emit errors (they will start with <literal>E</literal>)."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:169
+msgid ""
+"For more information on <command>lintian</command>, see <xref "
+"linkend=\"lintian\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:175
+msgid ""
+"Optionally run <xref linkend=\"debdiff\"/> to analyze changes from an older "
+"version, if one exists."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:181
+msgid ""
+"Downgrade the package to the previous version (if one exists) — this tests "
+"the <filename>postrm</filename> and <filename>prerm</filename> scripts."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:187
+msgid "Remove the package, then reinstall it."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:192
+msgid ""
+"Copy the source package in a different directory and try unpacking it and "
+"rebuilding it. This tests if the package relies on existing files outside "
+"of it, or if it relies on permissions being preserved on the files shipped "
+"inside the .diff.gz file."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:202
+msgid "Layout of the source package"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:204
+msgid "There are two types of Debian source packages:"
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:209
+msgid ""
+"the so-called <emphasis>native</emphasis> packages, where there is no "
+"distinction between the original sources and the patches applied for Debian"
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:215
+msgid ""
+"the (more common) packages where there's an original source tarball file "
+"accompanied by another file that contains the patches applied for Debian"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:221
+msgid ""
+"For the native packages, the source package includes a Debian source control "
+"file (<literal>.dsc</literal>) and the source tarball "
+"(<literal>.tar.gz</literal>). A source package of a non-native package "
+"includes a Debian source control file, the original source tarball "
+"(<literal>.orig.tar.gz</literal>) and the Debian patches "
+"(<literal>.diff.gz</literal>)."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:229
+msgid ""
+"Whether a package is native or not is determined when it is built by "
+"<citerefentry> <refentrytitle>dpkg-buildpackage</refentrytitle> "
+"<manvolnum>1</manvolnum> </citerefentry>. The rest of this section relates "
+"only to non-native packages."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:235
+msgid ""
+"The first time a version is uploaded which corresponds to a particular "
+"upstream version, the original source tar file should be uploaded and "
+"included in the <filename>.changes</filename> file. Subsequently, this very "
+"same tar file should be used to build the new diffs and "
+"<filename>.dsc</filename> files, and will not need to be re-uploaded."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:242
+msgid ""
+"By default, <command>dpkg-genchanges</command> and "
+"<command>dpkg-buildpackage</command> will include the original source tar "
+"file if and only if the Debian revision part of the source version number is "
+"0 or 1, indicating a new upstream version. This behavior may be modified by "
+"using <literal>-sa</literal> to always include it or <literal>-sd</literal> "
+"to always leave it out."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:250
+msgid ""
+"If no original source is included in the upload, the original source "
+"tar-file used by <command>dpkg-source</command> when constructing the "
+"<filename>.dsc</filename> file and diff to be uploaded "
+"<emphasis>must</emphasis> be byte-for-byte identical with the one already in "
+"the archive."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:257
+msgid ""
+"Please notice that, in non-native packages, permissions on files that are "
+"not present in the .orig.tar.gz will not be preserved, as diff does not "
+"store file permissions in the patch."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:264
+msgid "Picking a distribution"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:266
+msgid ""
+"Each upload needs to specify which distribution the package is intended "
+"for. The package build process extracts this information from the first "
+"line of the <filename>debian/changelog</filename> file and places it in the "
+"<literal>Distribution</literal> field of the <literal>.changes</literal> "
+"file."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:272
+msgid ""
+"There are several possible values for this field: `stable', `unstable', "
+"`testing-proposed-updates' and `experimental'. Normally, packages are "
+"uploaded into <emphasis>unstable</emphasis>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:277
+msgid ""
+"Actually, there are two other possible distributions: `stable-security' and "
+"`testing-security', but read <xref linkend=\"bug-security\"/> for more "
+"information on those."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:282
+msgid ""
+"It is not possible to upload a package into several distributions at the "
+"same time."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:286
+msgid "Special case: uploads to the <emphasis>stable</emphasis> distribution"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:288
+msgid ""
+"Uploading to <emphasis>stable</emphasis> means that the package will "
+"transfered to the <emphasis>p-u-new</emphasis>-queue for review by the "
+"stable release managers, and if approved will be installed in "
+"<filename>stable-proposed-updates</filename> directory of the Debian "
+"archive. From there, it will be included in <emphasis>stable</emphasis> "
+"with the next point release."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:296
+msgid ""
+"Extra care should be taken when uploading to <emphasis>stable</emphasis>. "
+"Basically, a package should only be uploaded to stable if one of the "
+"following happens:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:303
+msgid "a truly critical functionality problem"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:308
+msgid "the package becomes uninstallable"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:313
+msgid "a released architecture lacks the package"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:318
+msgid ""
+"In the past, uploads to <emphasis>stable</emphasis> were used to address "
+"security problems as well. However, this practice is deprecated, as uploads "
+"used for Debian security advisories are automatically copied to the "
+"appropriate <filename>proposed-updates</filename> archive when the advisory "
+"is released. See <xref linkend=\"bug-security\"/> for detailed information "
+"on handling security problems."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:326
+msgid ""
+"Changing anything else in the package that isn't important is discouraged, "
+"because even trivial fixes can cause bugs later on."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:330
+msgid ""
+"Packages uploaded to <emphasis>stable</emphasis> need to be compiled on "
+"systems running <emphasis>stable</emphasis>, so that their dependencies are "
+"limited to the libraries (and other packages) available in "
+"<emphasis>stable</emphasis>; for example, a package uploaded to "
+"<emphasis>stable</emphasis> that depends on a library package that only "
+"exists in unstable will be rejected. Making changes to dependencies of "
+"other packages (by messing with <literal>Provides</literal> or shlibs "
+"files), possibly making those other packages uninstallable, is strongly "
+"discouraged."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:340
+msgid ""
+"The Release Team (which can be reached at &email-debian-release;) will "
+"regularly evaluate the uploads To "
+"<emphasis>stable-proposed-updates</emphasis> and decide if your package can "
+"be included in <emphasis>stable</emphasis>. Please be clear (and verbose, "
+"if necessary) in your changelog entries for uploads to "
+"<emphasis>stable</emphasis>, because otherwise the package won't be "
+"considered for inclusion."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:349
+msgid ""
+"It's best practice to speak with the stable release manager "
+"<emphasis>before</emphasis> uploading to "
+"<emphasis>stable</emphasis>/<emphasis>stable-proposed-updates</emphasis>, so "
+"that the uploaded package fits the needs of the next point release."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:357
+msgid ""
+"Special case: uploads to "
+"<emphasis>testing/testing-proposed-updates</emphasis>"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:359
+msgid ""
+"Please see the information in the <link linkend=\"t-p-u\">testing "
+"section</link> for details."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:367
+msgid "Uploading a package"
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:369
+msgid "Uploading to <literal>ftp-master</literal>"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:371
+msgid ""
+"To upload a package, you should upload the files (including the signed "
+"changes and dsc-file) with anonymous ftp to "
+"<literal>&ftp-master-host;</literal> in the directory <ulink "
+"url=\"ftp://&ftp-master-host;&upload-queue;\">&upload-queue;</ulink>. To "
+"get the files processed there, they need to be signed with a key in the "
+"debian keyring."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:379
+msgid ""
+"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 all files have been uploaded."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:384
+msgid ""
+"You may also find the Debian packages <xref linkend=\"dupload\"/> or <xref "
+"linkend=\"dput\"/> useful when uploading packages. These handy programs "
+"help automate the process of uploading packages into Debian."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:389
+msgid ""
+"For removing packages, please see the README file in that ftp directory, and "
+"the Debian package <xref linkend=\"dcut\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:395
+msgid "Uploading to <literal>non-US</literal>"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:397
+msgid ""
+"<emphasis>Note:</emphasis> non-us was discontinued with the release of "
+"sarge."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:402
+msgid "Delayed uploads"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:404
+msgid ""
+"Delayed uploads are done for the moment via the delayed queue at gluck. The "
+"upload-directory is "
+"<literal>gluck:~tfheen/DELAYED/[012345678]-day</literal>. 0-day is uploaded "
+"multiple times per day to ftp-master."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:409
+msgid "With a fairly recent dput, this section"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: pkgs.dbk:412
+#, no-wrap
+msgid ""
+"[tfheen_delayed]\n"
+"method = scp\n"
+"fqdn = gluck.debian.org\n"
+"incoming = ~tfheen"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:418
+msgid "in ~/.dput.cf should work fine for uploading to the DELAYED queue."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:421
+msgid ""
+"<emphasis>Note:</emphasis> Since this upload queue goes to "
+"<literal>ftp-master</literal>, the prescription found in <xref "
+"linkend=\"upload-ftp-master\"/> applies here as well."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:428
+msgid "Security uploads"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:430
+msgid ""
+"Do <emphasis role=\"strong\">NOT</emphasis> 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. For details, please see section <xref "
+"linkend=\"bug-security\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:440
+msgid "Other upload queues"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:442
+msgid ""
+"The scp queues on ftp-master, and security are mostly unusable due to the "
+"login restrictions on those hosts."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:446
+msgid ""
+"The anonymous queues on ftp.uni-erlangen.de and ftp.uk.debian.org are "
+"currently down. Work is underway to resurrect them."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:450
+msgid ""
+"The queues on master.debian.org, samosa.debian.org, master.debian.or.jp, and "
+"ftp.chiark.greenend.org.uk are down permanently, and will not be "
+"resurrected. The queue in Japan will be replaced with a new queue on "
+"hp.debian.or.jp some day."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:456
+msgid ""
+"For the time being, the anonymous ftp queue on auric.debian.org (the former "
+"ftp-master) works, but it is deprecated and will be removed at some point in "
+"the future."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:463
+msgid "Notification that a new package has been installed"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:465
+msgid ""
+"The Debian archive maintainers are responsible for handling package "
+"uploads. For the most part, uploads are automatically handled on a daily "
+"basis by the archive maintenance tools, <command>katie</command>. "
+"Specifically, updates to existing packages to the `unstable' distribution "
+"are handled automatically. In other cases, notably new packages, placing "
+"the uploaded package into the distribution is handled manually. When "
+"uploads are handled manually, the change to the archive may take up to a "
+"month to occur. Please be patient."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:474
+msgid ""
+"In any case, you will receive an email notification indicating that the "
+"package has been added to the archive, which also indicates which bugs will "
+"be closed by the upload. Please examine this notification carefully, "
+"checking if any bugs you meant to close didn't get triggered."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:480
+msgid ""
+"The installation notification also includes information on what section the "
+"package was inserted into. If there is a disparity, you will receive a "
+"separate email notifying you of that. Read on below."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:485
+msgid ""
+"Note that if you upload via queues, the queue daemon software will also send "
+"you a notification by email."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:493
+msgid "Specifying the package section, subsection and priority"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:495
+msgid ""
+"The <filename>debian/control</filename> file's <literal>Section</literal> "
+"and <literal>Priority</literal> fields do not actually specify where the "
+"file will be placed in the archive, nor its priority. In order to retain "
+"the overall integrity of the archive, it is the archive maintainers who have "
+"control over these fields. The values in the "
+"<filename>debian/control</filename> file are actually just hints."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:503
+msgid ""
+"The archive maintainers keep track of the canonical sections and priorities "
+"for packages in the <emphasis>override file</emphasis>. If there is a "
+"disparity between the <emphasis>override file</emphasis> and the package's "
+"fields as indicated in <filename>debian/control</filename>, then you will "
+"receive an email noting the divergence when the package is installed into "
+"the archive. You can either correct your "
+"<filename>debian/control</filename> file for your next upload, or else you "
+"may wish to make a change in the <emphasis>override file</emphasis>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:513
+msgid ""
+"To alter the actual section that a package is put in, you need to first make "
+"sure that the <filename>debian/control</filename> file in your package is "
+"accurate. Next, send an email &email-override; or submit a bug against "
+"<systemitem role=\"package\">ftp.debian.org</systemitem> requesting that the "
+"section or priority for your package be changed from the old section or "
+"priority to the new one. Be sure to explain your reasoning."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:521
+msgid ""
+"For more information about <emphasis>override files</emphasis>, see "
+"<citerefentry> <refentrytitle>dpkg-scanpackages</refentrytitle> "
+"<manvolnum>1</manvolnum> </citerefentry> and <ulink "
+"url=\"&url-bts-devel;#maintincorrect\"></ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:527
+msgid ""
+"Note that the <literal>Section</literal> field describes both the section as "
+"well as the subsection, which are described in <xref "
+"linkend=\"archive-sections\"/> . If the section is main, it should be "
+"omitted. The list of allowable subsections can be found in <ulink "
+"url=\"&url-debian-policy;ch-archive.html#s-subsections\"></ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:536
+msgid "Handling bugs"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:538
+msgid ""
+"Every developer has to be able to work with the Debian <ulink "
+"url=\"&url-bts;\">bug tracking system</ulink>. This includes knowing how to "
+"file bug reports properly (see <xref linkend=\"submit-bug\"/> ), how to "
+"update them and reorder them, and how to process and close them."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:544
+msgid ""
+"The bug tracking system's features are described in the <ulink "
+"url=\"&url-bts-devel;\">BTS documentation for developers</ulink>. This "
+"includes closing bugs, sending followup messages, assigning severities and "
+"tags, marking bugs as forwarded, and other issues."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:550
+msgid ""
+"Operations such as reassigning bugs to other packages, merging separate bug "
+"reports about the same issue, or reopening bugs when they are prematurely "
+"closed, are handled using the so-called control mail server. All of the "
+"commands available on this server are described in the <ulink "
+"url=\"&url-bts-control;\">BTS control server documentation</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:558
+msgid "Monitoring bugs"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:560
+msgid ""
+"If you want to be a good maintainer, you should periodically check the "
+"<ulink url=\"&url-bts;\">Debian bug tracking system (BTS)</ulink> for your "
+"packages. The BTS contains all the open bugs against your packages. You "
+"can check them by browsing this page: "
+"<literal>http://&bugs-host;/<replaceable>yourlogin</replaceable>@debian.org</literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:567
+msgid ""
+"Maintainers interact with the BTS via email addresses at "
+"<literal>&bugs-host;</literal>. Documentation on available commands can be "
+"found at <ulink url=\"&url-bts;\"></ulink>, or, if you have installed the "
+"<systemitem role=\"package\">doc-debian</systemitem> package, you can look "
+"at the local files &file-bts-docs;."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:574
+msgid ""
+"Some find it useful to get periodic reports on open bugs. You can add a "
+"cron job such as the following if you want to get a weekly email outlining "
+"all the open bugs against your packages:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: pkgs.dbk:579
+#, no-wrap
+msgid ""
+"# ask for weekly reports of bugs in my packages\n"
+"&cron-bug-report;"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:583
+msgid ""
+"Replace <replaceable>address</replaceable> with your official Debian "
+"maintainer address."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:589
+msgid "Responding to bugs"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:591
+msgid ""
+"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., <email>123@&bugs-host;</email>). If you're writing a new mail and "
+"you don't remember the submitter email address, you can use the "
+"<email>123-submitter@&bugs-host;</email> email to contact the submitter "
+"<emphasis>and</emphasis> to record your mail within the bug log (that means "
+"you don't need to send a copy of the mail to "
+"<email>123@&bugs-host;</email>)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:600
+msgid ""
+"If you get a bug which mentions FTBFS, this means Fails to build from "
+"source. Porters frequently use this acronym."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:604
+msgid ""
+"Once you've dealt with a bug report (e.g. fixed it), mark it as "
+"<emphasis>done</emphasis> (close it) by sending an explanation message to "
+"<email>123-done@&bugs-host;</email>. If you're fixing a bug by changing and "
+"uploading the package, you can automate bug closing as described in <xref "
+"linkend=\"upload-bugfix\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:611
+msgid ""
+"You should <emphasis>never</emphasis> close bugs via the bug server "
+"<literal>close</literal> command sent to &email-bts-control;. If you do so, "
+"the original submitter will not receive any information about why the bug "
+"was closed."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:619
+msgid "Bug housekeeping"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:621
+msgid ""
+"As a package maintainer, you will often find bugs in other packages or have "
+"bugs reported against your packages which are actually bugs in other "
+"packages. The bug tracking system's features are described in the <ulink "
+"url=\"&url-bts-devel;\">BTS documentation for Debian developers</ulink>. "
+"Operations such as reassigning, merging, and tagging bug reports are "
+"described in the <ulink url=\"&url-bts-control;\">BTS control server "
+"documentation</ulink>. This section contains some guidelines for managing "
+"your own bugs, based on the collective Debian developer experience."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:632
+msgid ""
+"Filing bugs for problems that you find in other packages is one of the civic "
+"obligations of maintainership, see <xref linkend=\"submit-bug\"/> for "
+"details. However, handling the bugs in your own packages is even more "
+"important."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:637
+msgid "Here's a list of steps that you may follow to handle a bug report:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:642
+msgid ""
+"Decide whether the report corresponds to a real bug or not. Sometimes users "
+"are just calling a program in the wrong way because they haven't read the "
+"documentation. If you diagnose this, just close the bug with enough "
+"information to let the user correct their problem (give pointers to the good "
+"documentation and so on). If the same report comes up again and again you "
+"may ask yourself if the documentation is good enough or if the program "
+"shouldn't detect its misuse in order to give an informative error message. "
+"This is an issue that may need to be brought up with the upstream author."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:652
+msgid ""
+"If the bug submitter disagrees with your decision to close the bug, they may "
+"reopen it until you find an agreement on how to handle it. If you don't "
+"find any, you may want to tag the bug <literal>wontfix</literal> to let "
+"people know that the bug exists but that it won't be corrected. If this "
+"situation is unacceptable, you (or the submitter) may want to require a "
+"decision of the technical committee by reassigning the bug to <systemitem "
+"role=\"package\">tech-ctte</systemitem> (you may use the clone command of "
+"the BTS if you wish to keep it reported against your package). Before doing "
+"so, please read the <ulink url=\"&url-tech-ctte;\">recommended "
+"procedure</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:666
+msgid ""
+"If the bug is real but it's caused by another package, just reassign the bug "
+"to the right package. If you don't know which package it should be "
+"reassigned to, you should ask for help on <link "
+"linkend=\"irc-channels\">IRC</link> or on &email-debian-devel;. Please make "
+"sure that the maintainer(s) of the package the bug is reassigned to know why "
+"you reassigned it."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:674
+msgid ""
+"Sometimes you also have to adjust the severity of the bug so that it matches "
+"our definition of the severity. That's because people tend to inflate the "
+"severity of bugs to make sure their bugs are fixed quickly. Some bugs may "
+"even be dropped to wishlist severity when the requested change is just "
+"cosmetic."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:682
+msgid ""
+"If the bug is real but the same problem has already been reported by someone "
+"else, then the two relevant bug reports should be merged into one using the "
+"merge command of the BTS. In this way, when the bug is fixed, all of the "
+"submitters will be informed of this. (Note, however, that emails sent to "
+"one bug report's submitter won't automatically be sent to the other report's "
+"submitter.) For more details on the technicalities of the merge command and "
+"its relative, the unmerge command, see the BTS control server documentation."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:693
+msgid ""
+"The bug submitter may have forgotten to provide some information, in which "
+"case you have to ask them for the required information. You may use the "
+"<literal>moreinfo</literal> tag to mark the bug as such. Moreover if you "
+"can't reproduce the bug, you tag it <literal>unreproducible</literal>. "
+"Anyone who can reproduce the bug is then invited to provide more information "
+"on how to reproduce it. After a few months, if this information has not "
+"been sent by someone, the bug may be closed."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:704
+msgid ""
+"If the bug is related to the packaging, you just fix it. If you are not "
+"able to fix it yourself, then tag the bug as <literal>help</literal>. You "
+"can also ask for help on &email-debian-devel; or &email-debian-qa;. If it's "
+"an upstream problem, you have to forward it to the upstream author. "
+"Forwarding a bug is not enough, you have to check at each release if the bug "
+"has been fixed or not. If it has, you just close it, otherwise you have to "
+"remind the author about it. If you have the required skills you can prepare "
+"a patch that fixes the bug and send it to the author at the same time. Make "
+"sure to send the patch to the BTS and to tag the bug as "
+"<literal>patch</literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:718
+msgid ""
+"If you have fixed a bug in your local copy, or if a fix has been committed "
+"to the CVS repository, you may tag the bug as <literal>pending</literal> to "
+"let people know that the bug is corrected and that it will be closed with "
+"the next upload (add the <literal>closes:</literal> in the "
+"<filename>changelog</filename>). This is particularly useful if you are "
+"several developers working on the same package."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:728
+msgid ""
+"Once a corrected package is available in the <emphasis>unstable</emphasis> "
+"distribution, you can close the bug. This can be done automatically, read "
+"<xref linkend=\"upload-bugfix\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:737
+msgid "When bugs are closed by new uploads"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:739
+msgid ""
+"As bugs and problems are fixed in your packages, it is your responsibility "
+"as the package maintainer to close these bugs. However, you should not "
+"close a bug until the package which fixes the bug has been accepted into the "
+"Debian archive. Therefore, once you get notification that your updated "
+"package has been installed into the archive, you can and should close the "
+"bug in the BTS. Also, the bug should be closed with the correct version."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:747
+msgid ""
+"However, it's possible to avoid having to manually close bugs after the "
+"upload — just list the fixed bugs in your "
+"<filename>debian/changelog</filename> file, following a certain syntax, and "
+"the archive maintenance software will close the bugs for you. For example:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: pkgs.dbk:753
+#, no-wrap
+msgid ""
+"acme-cannon (3.1415) unstable; urgency=low\n"
+"\n"
+" * Frobbed with options (closes: Bug#98339)\n"
+" * Added safety to prevent operator dismemberment, closes: bug#98765,\n"
+" bug#98713, #98714.\n"
+" * Added man page. Closes: #98725."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:761
+msgid ""
+"Technically speaking, the following Perl regular expression describes how "
+"bug closing changelogs are identified:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: pkgs.dbk:765
+#, no-wrap
+msgid "/closes:\\s*(?:bug)?\\#\\s*\\d+(?:,\\s*(?:bug)?\\#\\s*\\d+)*/ig"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:768
+msgid ""
+"We prefer the <literal>closes: #<replaceable>XXX</replaceable></literal> "
+"syntax, as it is the most concise entry and the easiest to integrate with "
+"the text of the <filename>changelog</filename>. Unless specified different "
+"by the <replaceable>-v</replaceable>-switch to "
+"<command>dpkg-buildpackage</command>, only the bugs closed in the most "
+"recent changelog entry are closed (basically, exactly the bugs mentioned in "
+"the changelog-part in the <filename>.changes</filename> file are closed)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:777
+msgid ""
+"Historically, uploads identified as <link linkend=\"nmu\">Non-maintainer "
+"upload (NMU)</link> were tagged <literal>fixed</literal> instead of being "
+"closed, but that practice was ceased with the advent of version-tracking. "
+"The same applied to the tag <literal>fixed-in-experimental</literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:783
+msgid ""
+"If you happen to mistype a bug number or forget a bug in the changelog "
+"entries, don't hesitate to undo any damage the error caused. To reopen "
+"wrongly closed bugs, send a <literal>reopen "
+"<replaceable>XXX</replaceable></literal> command to the bug tracking "
+"system's control address, &email-bts-control;. To close any remaining bugs "
+"that were fixed by your upload, email the <filename>.changes</filename> file "
+"to <email>XXX-done@&bugs-host;</email>, where <replaceable>XXX</replaceable> "
+"is the bug number, and put Version: YYY and an empty line as the first two "
+"lines of the body of the email, where <replaceable>YYY</replaceable> is the "
+"first version where the bug has been fixed."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:795
+msgid ""
+"Bear in mind that it is not obligatory to close bugs using the changelog as "
+"described above. If you simply want to close bugs that don't have anything "
+"to do with an upload you made, do it by emailing an explanation to "
+"<email>XXX-done@&bugs-host;</email>. Do <emphasis "
+"role=\"strong\">not</emphasis> close bugs in the changelog entry of a "
+"version if the changes in that version of the package don't have any bearing "
+"on the bug."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:803
+msgid ""
+"For general information on how to write your changelog entries, see <xref "
+"linkend=\"bpp-debian-changelog\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:809
+msgid "Handling security-related bugs"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:811
+msgid ""
+"Due to their sensitive nature, security-related bugs must be handled "
+"carefully. The Debian Security Team exists to coordinate this activity, "
+"keeping track of outstanding security problems, helping maintainers with "
+"security problems or fixing them themselves, sending security advisories, "
+"and maintaining security.debian.org."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:820
+msgid ""
+"When you become aware of a security-related bug in a Debian package, whether "
+"or not you are the maintainer, collect pertinent information about the "
+"problem, and promptly contact the security team at &email-security-team; as "
+"soon as possible. <emphasis role=\"strong\">DO NOT UPLOAD</emphasis> any "
+"packages for stable; the security team will do that. Useful information "
+"includes, for example:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:830
+msgid ""
+"Which versions of the package are known to be affected by the bug. Check "
+"each version that is present in a supported Debian release, as well as "
+"testing and unstable."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:837
+msgid "The nature of the fix, if any is available (patches are especially helpful)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:842
+msgid ""
+"Any fixed packages that you have prepared yourself (send only the "
+"<literal>.diff.gz</literal> and <literal>.dsc</literal> files and read <xref "
+"linkend=\"bug-security-building\"/> first)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:849
+msgid ""
+"Any assistance you can provide to help with testing (exploits, regression "
+"testing, etc.)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:855
+msgid ""
+"Any information needed for the advisory (see <xref "
+"linkend=\"bug-security-advisories\"/> )"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:861
+msgid "Confidentiality"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:863
+msgid ""
+"Unlike most other activities within Debian, information about security "
+"issues must sometimes be kept private for a time. This allows software "
+"distributors to coordinate their disclosure in order to minimize their "
+"users' exposure. Whether this is the case depends on the nature of the "
+"problem and corresponding fix, and whether it is already a matter of public "
+"knowledge."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:870
+msgid "There are several ways developers can learn of a security problem:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:875
+msgid "they notice it on a public forum (mailing list, web site, etc.)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:880
+msgid "someone files a bug report"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:885
+msgid "someone informs them via private email"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:890
+msgid ""
+"In the first two cases, the information is public and it is important to "
+"have a fix as soon as possible. In the last case, however, it might not be "
+"public information. In that case there are a few possible options for "
+"dealing with the problem:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:898
+msgid ""
+"If the security exposure is minor, there is sometimes no need to keep the "
+"problem a secret and a fix should be made and released."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:904
+msgid ""
+"If the problem is severe, it is preferable to share the information with "
+"other vendors and coordinate a release. The security team keeps in contact "
+"with the various organizations and individuals and can take care of that."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:911
+msgid ""
+"In all cases if the person who reports the problem asks that it not be "
+"disclosed, such requests should be honored, with the obvious exception of "
+"informing the security team in order that a fix may be produced for a stable "
+"release of Debian. When sending confidential information to the security "
+"team, be sure to mention this fact."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:918
+msgid ""
+"Please note that if secrecy is needed you may not upload a fix to unstable "
+"(or anywhere else, such as a public CVS repository). It is not sufficient "
+"to obfuscate the details of the change, as the code itself is public, and "
+"can (and will) be examined by the general public."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:924
+msgid ""
+"There are two reasons for releasing information even though secrecy is "
+"requested: the problem has been known for a while, or the problem or exploit "
+"has become public."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:931
+msgid "Security Advisories"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:933
+msgid ""
+"Security advisories are only issued for the current, released stable "
+"distribution, and <emphasis>not</emphasis> for testing or unstable. When "
+"released, advisories are sent to the &email-debian-security-announce; "
+"mailing list and posted on <ulink "
+"url=\"&url-debian-security-advisories;\">the security web page</ulink>. "
+"Security advisories are written and posted by the security team. However "
+"they certainly do not mind if a maintainer can supply some of the "
+"information for them, or write part of the text. Information that should be "
+"in an advisory includes:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:946
+msgid "A description of the problem and its scope, including:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para>
+#: pkgs.dbk:951
+msgid "The type of problem (privilege escalation, denial of service, etc.)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para>
+#: pkgs.dbk:956
+msgid "What privileges may be gained, and by whom (if any)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para>
+#: pkgs.dbk:961
+msgid "How it can be exploited"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para>
+#: pkgs.dbk:966
+msgid "Whether it is remotely or locally exploitable"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para>
+#: pkgs.dbk:971
+msgid "How the problem was fixed"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:976
+msgid "This information allows users to assess the threat to their systems."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:981
+msgid "Version numbers of affected packages"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:986
+msgid "Version numbers of fixed packages"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:991
+msgid ""
+"Information on where to obtain the updated packages (usually from the Debian "
+"security archive)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:997
+msgid ""
+"References to upstream advisories, <ulink "
+"url=\"http://cve.mitre.org\">CVE</ulink> identifiers, and any other "
+"information useful in cross-referencing the vulnerability"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:1006
+msgid "Preparing packages to address security issues"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1008
+msgid ""
+"One way that you can assist the security team in their duties is to provide "
+"them with fixed packages suitable for a security advisory for the stable "
+"Debian release."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1013
+msgid ""
+"When an update is made to the stable release, care must be taken to avoid "
+"changing system behavior or introducing new bugs. In order to do this, make "
+"as few changes as possible to fix the bug. Users and administrators rely on "
+"the exact behavior of a release once it is made, so any change that is made "
+"might break someone's system. This is especially true of libraries: make "
+"sure you never change the API or ABI, no matter how small the change."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1021
+msgid ""
+"This means that moving to a new upstream version is not a good solution. "
+"Instead, the relevant changes should be back-ported to the version present "
+"in the current stable Debian release. Generally, upstream maintainers are "
+"willing to help if needed. If not, the Debian security team may be able to "
+"help."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1027
+msgid ""
+"In some cases, it is not possible to back-port a security fix, for example "
+"when large amounts of source code need to be modified or rewritten. If this "
+"happens, it may be necessary to move to a new upstream version. However, "
+"this is only done in extreme situations, and you must always coordinate that "
+"with the security team beforehand."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1034
+msgid ""
+"Related to this is another important guideline: always test your changes. "
+"If you have an exploit available, try it and see if it indeed succeeds on "
+"the unpatched package and fails on the fixed package. Test other, normal "
+"actions as well, as sometimes a security fix can break seemingly unrelated "
+"features in subtle ways."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1041
+msgid ""
+"Do <emphasis role=\"strong\">NOT</emphasis> include any changes in your "
+"package which are not directly related to fixing the vulnerability. These "
+"will only need to be reverted, and this wastes time. If there are other "
+"bugs in your package that you would like to fix, make an upload to "
+"proposed-updates in the usual way, after the security advisory is issued. "
+"The security update mechanism is not a means for introducing changes to your "
+"package which would otherwise be rejected from the stable release, so please "
+"do not attempt to do this."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1051
+msgid ""
+"Review and test your changes as much as possible. Check the differences "
+"from the previous version repeatedly (<command>interdiff</command> from the "
+"<systemitem role=\"package\">patchutils</systemitem> package and "
+"<command>debdiff</command> from <systemitem "
+"role=\"package\">devscripts</systemitem> are useful tools for this, see "
+"<xref linkend=\"debdiff\"/> )."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1059
+msgid "Be sure to verify the following items:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1064
+msgid ""
+"Target the right distribution in your "
+"<filename>debian/changelog</filename>. For stable this is "
+"<literal>stable-security</literal> and for testing this is "
+"<literal>testing-security</literal>, and for the previous stable release, "
+"this is <literal>oldstable-security</literal>. Do not target "
+"<replaceable>distribution</replaceable>-proposed-updates or "
+"<literal>stable</literal>!"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1074
+msgid "The upload should have urgency=high."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1079
+msgid ""
+"Make descriptive, meaningful changelog entries. Others will rely on them to "
+"determine whether a particular bug was fixed. 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."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1091
+msgid ""
+"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 <literal>dpkg --compare-versions</literal>. Be careful "
+"not to re-use a version number that you have already used for a previous "
+"upload. For <emphasis>testing</emphasis>, there must be a higher version in "
+"<emphasis>unstable</emphasis>. If there is none yet (for example, if "
+"<emphasis>testing</emphasis> and <emphasis>unstable</emphasis> have the same "
+"version) you must upload a new version to unstable first."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1103
+msgid ""
+"Do not make source-only uploads if your package has any binary-all packages "
+"(do not use the <literal>-S</literal> option to "
+"<command>dpkg-buildpackage</command>). The <command>buildd</command> "
+"infrastructure will not build those. This point applies to normal package "
+"uploads as well."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1112
+msgid ""
+"Unless the upstream source has been uploaded to security.debian.org before "
+"(by a previous security update), build the upload with full upstream source "
+"(<literal>dpkg-buildpackage -sa</literal>). If there has been a previous "
+"upload to security.debian.org with the same upstream version, you may upload "
+"without upstream source (<literal>dpkg-buildpackage -sd</literal>)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1121
+msgid ""
+"Be sure to use the exact same <filename>*.orig.tar.gz</filename> as used in "
+"the normal archive, otherwise it is not possible to move the security fix "
+"into the main archives later."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1128
+msgid ""
+"Build the package on a clean system which only has packages installed from "
+"the distribution you are building for. If you do not have such a system "
+"yourself, you can use a debian.org machine (see <xref "
+"linkend=\"server-machines\"/> ) or setup a chroot (see <xref "
+"linkend=\"pbuilder\"/> and <xref linkend=\"debootstrap\"/> )."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:1139
+msgid "Uploading the fixed package"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1141
+msgid ""
+"Do <emphasis role=\"strong\">NOT</emphasis> 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."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1148
+msgid ""
+"Do <emphasis role=\"strong\">NOT</emphasis> 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 is "
+"already installed into the archive, the security update will be rejected by "
+"the archive system. That way, the stable distribution will end up without a "
+"security update for this package instead."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1157
+msgid ""
+"Once you have created and tested the new package and it has been approved by "
+"the security team, it needs to be uploaded so that it can be installed in "
+"the archives. For security uploads, the place to upload to is "
+"<literal>ftp://security-master.debian.org/pub/SecurityUploadQueue/</literal> "
+"."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1163
+msgid ""
+"Once an upload to the security queue has been accepted, the package will "
+"automatically be rebuilt for all architectures and stored for verification "
+"by the security team."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1168
+msgid ""
+"Uploads which are waiting for acceptance or verification are only accessible "
+"by the security team. This is necessary since there might be fixes for "
+"security problems that cannot be disclosed yet."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1173
+msgid ""
+"If a member of the security team accepts a package, it will be installed on "
+"security.debian.org as well as proposed for the proper "
+"<replaceable>distribution</replaceable>-proposed-updates on ftp-master."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:1184
+msgid "Moving, removing, renaming, adopting, and orphaning packages"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:1186
+msgid ""
+"Some archive manipulation operations are not automated in the Debian upload "
+"process. These procedures should be manually followed by maintainers. This "
+"chapter gives guidelines on what to do in these cases."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1191
+msgid "Moving packages"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para><footnote>
+#: pkgs.dbk:1193
+msgid ""
+"Sometimes a package will change its section. For instance, a package from "
+"the `non-free' section might be GPL'd in a later version, in which case the "
+"package should be moved to `main' or `contrib'.<footnote>"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para><footnote><para>
+#: pkgs.dbk:1195
+msgid ""
+"See the <ulink url=\"&url-debian-policy;\">Debian Policy Manual</ulink> for "
+"guidelines on what section a package belongs in."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1200
+msgid ""
+"If you need to change the section for one of your packages, change the "
+"package control information to place the package in the desired section, and "
+"re-upload the package (see the <ulink url=\"&url-debian-policy;\">Debian "
+"Policy Manual</ulink> for details). You must ensure that you include the "
+"<filename>.orig.tar.gz</filename> in your upload (even if you are not "
+"uploading a new upstream version), or it will not appear in the new section "
+"together with the rest of the package. If your new section is valid, it "
+"will be moved automatically. If it does not, then contact the ftpmasters in "
+"order to understand what happened."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1212
+msgid ""
+"If, on the other hand, you need to change the "
+"<emphasis>subsection</emphasis> of one of your packages (e.g., ``devel'', "
+"``admin''), the procedure is slightly different. Correct the subsection as "
+"found in the control file of the package, and re-upload that. Also, you'll "
+"need to get the override file updated, as described in <xref "
+"linkend=\"override-file\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1221
+msgid "Removing packages"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1223
+msgid ""
+"If for some reason you want to completely remove a package (say, if it is an "
+"old compatibility library which is no longer required), you need to file a "
+"bug against <literal>ftp.debian.org</literal> asking that the package be "
+"removed; as all bugs, this bug should normally have normal severity. Make "
+"sure you indicate which distribution the package should be removed from. "
+"Normally, you can only have packages removed from "
+"<emphasis>unstable</emphasis> and <emphasis>experimental</emphasis>. "
+"Packages are not removed from <emphasis>testing</emphasis> directly. "
+"Rather, they will be removed automatically after the package has been "
+"removed from <emphasis>unstable</emphasis> and no package in "
+"<emphasis>testing</emphasis> depends on it."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1236
+msgid ""
+"There is one exception when an explicit removal request is not necessary: If "
+"a (source or binary) package is an orphan, it will be removed "
+"semi-automatically. For a binary-package, this means if there is no longer "
+"any source package producing this binary package; if the binary package is "
+"just no longer produced on some architectures, a removal request is still "
+"necessary. For a source-package, this means that all binary packages it "
+"refers to have been taken over by another source package."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1245
+msgid ""
+"In your removal request, you have to detail the reasons justifying the "
+"request. This is to avoid unwanted removals and to keep a trace of why a "
+"package has been removed. For example, you can provide the name of the "
+"package that supersedes the one to be removed."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1251
+msgid ""
+"Usually you only ask for the removal of a package maintained by yourself. "
+"If you want to remove another package, you have to get the approval of its "
+"maintainer."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1256
+msgid ""
+"Further information relating to these and other package removal related "
+"topics may be found at <ulink "
+"url=\"http://wiki.debian.org/ftpmaster_Removals\"></ulink> and <ulink "
+"url=\"&url-debian-qa;howto-remove.html\"></ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1261
+msgid ""
+"If in doubt concerning whether a package is disposable, email "
+"&email-debian-devel; asking for opinions. Also of interest is the "
+"<command>apt-cache</command> program from the <systemitem "
+"role=\"package\">apt</systemitem> package. When invoked as "
+"<literal>apt-cache showpkg <replaceable>package</replaceable></literal>, the "
+"program will show details for <replaceable>package</replaceable>, including "
+"reverse depends. Other useful programs include <literal>apt-cache "
+"rdepends</literal>, <command>apt-rdepends</command> and "
+"<command>grep-dctrl</command>. Removal of orphaned packages is discussed on "
+"&email-debian-qa;."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1272
+msgid ""
+"Once the package has been removed, the package's bugs should be handled. "
+"They should either be reassigned to another package in the case where the "
+"actual code has evolved into another package (e.g. "
+"<literal>libfoo12</literal> was removed because <literal>libfoo13</literal> "
+"supersedes it) or closed if the software is simply no longer part of Debian."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:1279
+msgid "Removing packages from <filename>Incoming</filename>"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1281
+msgid ""
+"In the past, it was possible to remove packages from "
+"<filename>incoming</filename>. However, with the introduction of the new "
+"incoming system, this is no longer possible. Instead, you have to upload a "
+"new revision of your package with a higher version than the package you want "
+"to replace. Both versions will be installed in the archive but only the "
+"higher version will actually be available in <emphasis>unstable</emphasis> "
+"since the previous version will immediately be replaced by the higher. "
+"However, if you do proper testing of your packages, the need to replace a "
+"package should not occur too often anyway."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1296
+msgid "Replacing or renaming packages"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1298
+msgid ""
+"When you make a mistake naming your package, you should follow a two-step "
+"process to rename it. First, set your <filename>debian/control</filename> "
+"file to replace and conflict with the obsolete name of the package (see the "
+"<ulink url=\"&url-debian-policy;\">Debian Policy Manual</ulink> for "
+"details). Once you've uploaded the package and the package has moved into "
+"the archive, file a bug against <literal>ftp.debian.org</literal> asking to "
+"remove the package with the obsolete name. Do not forget to properly "
+"reassign the package's bugs at the same time."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1308
+msgid ""
+"At other times, you may make a mistake in constructing your package and wish "
+"to replace it. The only way to do this is to increase the version number "
+"and upload a new version. The old version will be expired in the usual "
+"manner. Note that this applies to each part of your package, including the "
+"sources: if you wish to replace the upstream source tarball of your package, "
+"you will need to upload it with a different version. An easy possibility is "
+"to replace <filename>foo_1.00.orig.tar.gz</filename> with "
+"<filename>foo_1.00+0.orig.tar.gz</filename>. This restriction gives each "
+"file on the ftp site a unique name, which helps to ensure consistency across "
+"the mirror network."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1322
+msgid "Orphaning a package"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1324
+msgid ""
+"If you can no longer maintain a package, you need to inform others, and see "
+"that the package is marked as orphaned. You should set the package "
+"maintainer to <literal>Debian QA Group &orphan-address;</literal> and submit "
+"a bug report against the pseudo package <systemitem "
+"role=\"package\">wnpp</systemitem>. The bug report should be titled "
+"<literal>O: <replaceable>package</replaceable> -- <replaceable>short "
+"description</replaceable></literal> indicating that the package is now "
+"orphaned. The severity of the bug should be set to "
+"<emphasis>normal</emphasis>; if the package has a priority of standard or "
+"higher, it should be set to important. If you feel it's necessary, send a "
+"copy to &email-debian-devel; by putting the address in the X-Debbugs-CC: "
+"header of the message (no, don't use CC:, because that way the message's "
+"subject won't indicate the bug number)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1339
+msgid ""
+"If you just intend to give the package away, but you can keep maintainership "
+"for the moment, then you should instead submit a bug against <systemitem "
+"role=\"package\">wnpp</systemitem> and title it <literal>RFA: "
+"<replaceable>package</replaceable> -- <replaceable>short "
+"description</replaceable></literal>. <literal>RFA</literal> stands for "
+"<emphasis>Request For Adoption</emphasis>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1347
+msgid "More information is on the <ulink url=\"&url-wnpp;\">WNPP web pages</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1353
+msgid "Adopting a package"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1355
+msgid ""
+"A list of packages in need of a new maintainer is available in the <ulink "
+"url=\"&url-wnpp;\">Work-Needing and Prospective Packages list "
+"(WNPP)</ulink>. If you wish to take over maintenance of any of the packages "
+"listed in the WNPP, please take a look at the aforementioned page for "
+"information and procedures."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1362
+msgid ""
+"It is not OK to simply take over a package that you feel is neglected — that "
+"would be package hijacking. You can, of course, contact the current "
+"maintainer and ask them if you may take over the package. If you have "
+"reason to believe a maintainer has gone AWOL (absent without leave), see "
+"<xref linkend=\"mia-qa\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1368
+msgid ""
+"Generally, you may not take over the package without the assent of the "
+"current maintainer. Even if they ignore you, that is still not grounds to "
+"take over a package. Complaints about maintainers should be brought up on "
+"the developers' mailing list. If the discussion doesn't end with a positive "
+"conclusion, and the issue is of a technical nature, consider bringing it to "
+"the attention of the technical committee (see the <ulink "
+"url=\"&url-tech-ctte;\">technical committee web page</ulink> for more "
+"information)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1378
+msgid ""
+"If you take over an old package, you probably want to be listed as the "
+"package's official maintainer in the bug system. This will happen "
+"automatically once you upload a new version with an updated "
+"<literal>Maintainer:</literal> field, although it can take a few hours after "
+"the upload is done. If you do not expect to upload a new version for a "
+"while, you can use <xref linkend=\"pkg-tracking-system\"/> to get the bug "
+"reports. However, make sure that the old maintainer has no problem with the "
+"fact that they will continue to receive the bugs during that time."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:1392
+msgid "Porting and being ported"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:1394
+msgid ""
+"Debian supports an ever-increasing number of architectures. Even if you are "
+"not a porter, and you don't use any architecture but one, it is part of your "
+"duty as a maintainer to be aware of issues of portability. Therefore, even "
+"if you are not a porter, you should read most of this chapter."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:1400
+msgid ""
+"Porting is the act of building Debian packages for architectures that are "
+"different from the original architecture of the package maintainer's binary "
+"package. It is a unique and essential activity. In fact, porters do most "
+"of the actual compiling of Debian packages. For instance, for a single "
+"<emphasis>i386</emphasis> binary package, there must be a recompile for each "
+"architecture, which amounts to &number-of-arches; more builds."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1408
+msgid "Being kind to porters"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1410
+msgid ""
+"Porters have a difficult and unique task, since they are required to deal "
+"with a large volume of packages. Ideally, every source package should build "
+"right out of the box. Unfortunately, this is often not the case. This "
+"section contains a checklist of ``gotchas'' often committed by Debian "
+"maintainers — common problems which often stymie porters, and make their "
+"jobs unnecessarily difficult."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1418
+msgid ""
+"The first and most important thing is to respond quickly to bug or issues "
+"raised by porters. Please treat porters with courtesy, as if they were in "
+"fact co-maintainers of your package (which, in a way, they are). Please be "
+"tolerant of succinct or even unclear bug reports; do your best to hunt down "
+"whatever the problem is."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1425
+msgid ""
+"By far, most of the problems encountered by porters are caused by "
+"<emphasis>packaging bugs</emphasis> in the source packages. Here is a "
+"checklist of things you should check or be aware of."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:1432
+msgid ""
+"Make sure that your <literal>Build-Depends</literal> and "
+"<literal>Build-Depends-Indep</literal> settings in "
+"<filename>debian/control</filename> are set properly. The best way to "
+"validate this is to use the <systemitem "
+"role=\"package\">debootstrap</systemitem> package to create an unstable "
+"chroot environment (see <xref linkend=\"debootstrap\"/> ). Within that "
+"chrooted environment, install the <systemitem "
+"role=\"package\">build-essential</systemitem> package and any package "
+"dependencies mentioned in <literal>Build-Depends</literal> and/or "
+"<literal>Build-Depends-Indep</literal>. Finally, try building your package "
+"within that chrooted environment. These steps can be automated by the use "
+"of the <command>pbuilder</command> program which is provided by the package "
+"of the same name (see <xref linkend=\"pbuilder\"/> )."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:1446
+msgid ""
+"If you can't set up a proper chroot, <command>dpkg-depcheck</command> may be "
+"of assistance (see <xref linkend=\"dpkg-depcheck\"/> )."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:1450
+msgid ""
+"See the <ulink url=\"&url-debian-policy;\">Debian Policy Manual</ulink> for "
+"instructions on setting build dependencies."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:1456
+msgid ""
+"Don't set architecture to a value other than ``all'' or ``any'' unless you "
+"really mean it. In too many cases, maintainers don't follow the "
+"instructions in the <ulink url=\"&url-debian-policy;\">Debian Policy "
+"Manual</ulink>. Setting your architecture to ``i386'' is usually incorrect."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:1464
+msgid ""
+"Make sure your source package is correct. Do <literal>dpkg-source -x "
+"<replaceable>package</replaceable>.dsc</literal> to make sure your source "
+"package unpacks properly. Then, in there, try building your package from "
+"scratch with <command>dpkg-buildpackage</command>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:1472
+msgid ""
+"Make sure you don't ship your source package with the "
+"<filename>debian/files</filename> or <filename>debian/substvars</filename> "
+"files. They should be removed by the `clean' target of "
+"<filename>debian/rules</filename>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:1480
+msgid ""
+"Make sure you don't rely on locally installed or hacked configurations or "
+"programs. For instance, you should never be calling programs in "
+"<filename>/usr/local/bin</filename> or the like. Try not to rely on "
+"programs being setup in a special way. Try building your package on another "
+"machine, even if it's the same architecture."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:1489
+msgid ""
+"Don't depend on the package you're building being installed already (a "
+"sub-case of the above issue)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:1495
+msgid ""
+"Don't rely on the compiler being a certain version, if possible. If not, "
+"then make sure your build dependencies reflect the restrictions, although "
+"you are probably asking for trouble, since different architectures sometimes "
+"standardize on different compilers."
+msgstr ""
+
+# type: Content of: <chapter><section><section><orderedlist><listitem><para>
+#: pkgs.dbk:1503
+msgid ""
+"Make sure your debian/rules contains separate ``binary-arch'' and "
+"``binary-indep'' targets, as the Debian Policy Manual requires. Make sure "
+"that both targets work independently, that is, that you can call the target "
+"without having called the other before. To test this, try to run "
+"<literal>dpkg-buildpackage -B</literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1514
+msgid "Guidelines for porter uploads"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1516
+msgid ""
+"If the package builds out of the box for the architecture to be ported to, "
+"you are in luck and your job is easy. This section applies to that case; it "
+"describes how to build and upload your binary package so that it is properly "
+"installed into the archive. If you do have to patch the package in order to "
+"get it to compile for the other architecture, you are actually doing a "
+"source NMU, so consult <xref linkend=\"nmu-guidelines\"/> instead."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1524
+msgid ""
+"For a porter upload, no changes are being made to the source. You do not "
+"need to touch any of the files in the source package. This includes "
+"<filename>debian/changelog</filename>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1529
+msgid ""
+"The way to invoke <command>dpkg-buildpackage</command> is as "
+"<literal>dpkg-buildpackage -B "
+"-m<replaceable>porter-email</replaceable></literal>. Of course, set "
+"<replaceable>porter-email</replaceable> to your email address. This will do "
+"a binary-only build of only the architecture-dependent portions of the "
+"package, using the `binary-arch' target in "
+"<filename>debian/rules</filename>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1537
+msgid ""
+"If you are working on a Debian machine for your porting efforts and you need "
+"to sign your upload locally for its acceptance in the archive, you can run "
+"<command>debsign</command> on your <filename>.changes</filename> file to "
+"have it signed conveniently, or use the remote signing mode of "
+"<command>dpkg-sig</command>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:1544
+msgid "Recompilation or binary-only NMU"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1546
+msgid ""
+"Sometimes the initial porter upload is problematic because the environment "
+"in which the package was built was not good enough (outdated or obsolete "
+"library, bad compiler, ...). Then you may just need to recompile it in an "
+"updated environment. However, you have to bump the version number in this "
+"case, so that the old bad package can be replaced in the Debian archive "
+"(<command>katie</command> refuses to install new packages if they don't have "
+"a version number greater than the currently available one)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1555
+msgid ""
+"You have to make sure that your binary-only NMU doesn't render the package "
+"uninstallable. This could happen when a source package generates "
+"arch-dependent and arch-independent packages that depend on each other via "
+"$(Source-Version)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1561
+msgid ""
+"Despite the required modification of the changelog, these are called "
+"binary-only NMUs — there is no need in this case to trigger all other "
+"architectures to consider themselves out of date or requiring recompilation."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1566
+msgid ""
+"Such recompilations require special ``magic'' version numbering, so that the "
+"archive maintenance tools recognize that, even though there is a new Debian "
+"version, there is no corresponding source update. If you get this wrong, "
+"the archive maintainers will reject your upload (due to lack of "
+"corresponding source code)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para><footnote>
+#: pkgs.dbk:1573
+msgid ""
+"The ``magic'' for a recompilation-only NMU is triggered by using a suffix "
+"appended to the package version number, following the form b<number>. "
+"For instance, if the latest version you are recompiling against was version "
+"``2.9-3'', your NMU should carry a version of ``2.9-3+b1''. If the latest "
+"version was ``3.4+b1'' (i.e, a native package with a previous recompilation "
+"NMU), your NMU should have a version number of ``3.4+b2''. <footnote>"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para><footnote><para>
+#: pkgs.dbk:1578
+msgid ""
+"In the past, such NMUs used the third-level number on the Debian part of the "
+"revision to denote their recompilation-only status; however, this syntax was "
+"ambiguous with native packages and did not allow proper ordering of "
+"recompile-only NMUs, source NMUs, and security NMUs on the same package, and "
+"has therefore been abandoned in favor of this new syntax."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1586
+msgid ""
+"Similar to initial porter uploads, the correct way of invoking "
+"<command>dpkg-buildpackage</command> is <literal>dpkg-buildpackage "
+"-B</literal> to only build the architecture-dependent parts of the package."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:1593
+msgid "When to do a source NMU if you are a porter"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1595
+msgid ""
+"Porters doing a source NMU generally follow the guidelines found in <xref "
+"linkend=\"nmu\"/> , just like non-porters. However, it is expected that the "
+"wait cycle for a porter's source NMU is smaller than for a non-porter, since "
+"porters have to cope with a large quantity of packages. Again, the "
+"situation varies depending on the distribution they are uploading to. It "
+"also varies whether the architecture is a candidate for inclusion into the "
+"next stable release; the release managers decide and announce which "
+"architectures are candidates."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1604
+msgid ""
+"If you are a porter doing an NMU for `unstable', the above guidelines for "
+"porting should be followed, with two variations. Firstly, the acceptable "
+"waiting period — the time between when the bug is submitted to the BTS and "
+"when it is OK to do an NMU — is seven days for porters working on the "
+"unstable distribution. This period can be shortened if the problem is "
+"critical and imposes hardship on the porting effort, at the discretion of "
+"the porter group. (Remember, none of this is Policy, just mutually agreed "
+"upon guidelines.) For uploads to stable or testing, please coordinate with "
+"the appropriate release team first."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1615
+msgid ""
+"Secondly, porters doing source NMUs should make sure that the bug they "
+"submit to the BTS should be of severity `serious' or greater. This ensures "
+"that a single source package can be used to compile every supported Debian "
+"architecture by release time. It is very important that we have one version "
+"of the binary and source package for all architecture in order to comply "
+"with many licenses."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1623
+msgid ""
+"Porters should try to avoid patches which simply kludge around bugs in the "
+"current version of the compile environment, kernel, or libc. Sometimes such "
+"kludges can't be helped. If you have to kludge around compiler bugs and the "
+"like, make sure you <literal>#ifdef</literal> your work properly; also, "
+"document your kludge so that people know to remove it once the external "
+"problems have been fixed."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1631
+msgid ""
+"Porters may also have an unofficial location where they can put the results "
+"of their work during the waiting period. This helps others running the port "
+"have the benefit of the porter's work, even during the waiting period. Of "
+"course, such locations have no official blessing or status, so buyer beware."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1641
+msgid "Porting infrastructure and automation"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1643
+msgid ""
+"There is infrastructure and several tools to help automate package porting. "
+"This section contains a brief overview of this automation and porting to "
+"these tools; see the package documentation or references for full "
+"information."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:1648
+msgid "Mailing lists and web pages"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1650
+msgid ""
+"Web pages containing the status of each port can be found at <ulink "
+"url=\"&url-debian-ports;\"></ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1654
+msgid ""
+"Each port of Debian has a mailing list. The list of porting mailing lists "
+"can be found at <ulink url=\"&url-debian-port-lists;\"></ulink>. These "
+"lists are used to coordinate porters, and to connect the users of a given "
+"port with the porters."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:1662
+msgid "Porter tools"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1664
+msgid ""
+"Descriptions of several porting tools can be found in <xref "
+"linkend=\"tools-porting\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1672
+msgid ""
+"The <systemitem role=\"package\">buildd</systemitem> system is used as a "
+"distributed, client-server build distribution system. It is usually used in "
+"conjunction with <emphasis>auto-builders</emphasis>, which are ``slave'' "
+"hosts which simply check out and attempt to auto-build packages which need "
+"to be ported. There is also an email interface to the system, which allows "
+"porters to ``check out'' a source package (usually one which cannot yet be "
+"auto-built) and work on it."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1681
+msgid ""
+"<systemitem role=\"package\">buildd</systemitem> is not yet available as a "
+"package; however, most porting efforts are either using it currently or "
+"planning to use it in the near future. The actual automated builder is "
+"packaged as <systemitem role=\"package\">sbuild</systemitem>, see its "
+"description in <xref linkend=\"sbuild\"/> . The complete <systemitem "
+"role=\"package\">buildd</systemitem> system also collects a number of as yet "
+"unpackaged components which are currently very useful and in use "
+"continually, such as <command>andrea</command> and "
+"<command>wanna-build</command>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1691
+msgid ""
+"Some of the data produced by <systemitem "
+"role=\"package\">buildd</systemitem> which is generally useful to porters is "
+"available on the web at <ulink url=\"&url-buildd;\"></ulink>. This data "
+"includes nightly updated information from <command>andrea</command> (source "
+"dependencies) and <systemitem role=\"package\">quinn-diff</systemitem> "
+"(packages needing recompilation)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1699
+msgid ""
+"We are quite proud of this system, since it has so many possible uses. "
+"Independent development groups can use the system for different sub-flavors "
+"of Debian, which may or may not really be of general interest (for instance, "
+"a flavor of Debian built with <command>gcc</command> bounds checking). It "
+"will also enable Debian to recompile entire distributions quickly."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:1706
+msgid ""
+"The buildds admins of each arch can be contacted at the mail address "
+"$arch@buildd.debian.org."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1714
+msgid "When your package is <emphasis>not</emphasis> portable"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1716
+msgid ""
+"Some packages still have issues with building and/or working on some of the "
+"architectures supported by Debian, and cannot be ported at all, or not "
+"within a reasonable amount of time. An example is a package that is "
+"SVGA-specific (only i386), or uses other hardware-specific features not "
+"supported on all architectures."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1723
+msgid ""
+"In order to prevent broken packages from being uploaded to the archive, and "
+"wasting buildd time, you need to do a few things:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1729
+msgid ""
+"First, make sure your package <emphasis>does</emphasis> fail to build on "
+"architectures that it cannot support. There are a few ways to achieve "
+"this. The preferred way is to have a small testsuite during build time that "
+"will test the functionality, and fail if it doesn't work. This is a good "
+"idea anyway, as this will prevent (some) broken uploads on all "
+"architectures, and also will allow the package to build as soon as the "
+"required functionality is available."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1737
+msgid ""
+"Additionally, if you believe the list of supported architectures is pretty "
+"constant, you should change 'any' to a list of supported architectures in "
+"debian/control. This way, the build will fail also, and indicate this to a "
+"human reader without actually trying."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1745
+msgid ""
+"In order to prevent autobuilders from needlessly trying to build your "
+"package, it must be included in <filename>packages-arch-specific</filename>, "
+"a list used by the <command>wanna-build</command> script. The current "
+"version is available as <ulink "
+"url=\"&url-cvsweb;srcdep/Packages-arch-specific?cvsroot=dak\"></ulink>; "
+"please see the top of the file for whom to contact for changes."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1755
+msgid ""
+"Please note that it is insufficient to only add your package to "
+"Packages-arch-specific without making it fail to build on unsupported "
+"architectures: A porter or any other person trying to build your package "
+"might accidently upload it without noticing it doesn't work. If in the past "
+"some binary packages were uploaded on unsupported architectures, request "
+"their removal by filing a bug against <systemitem "
+"role=\"package\">ftp.debian.org</systemitem>"
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:1768
+msgid "Non-Maintainer Uploads (NMUs)"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:1770
+msgid ""
+"Under certain circumstances it is necessary for someone other than the "
+"official package maintainer to make a release of a package. This is called "
+"a non-maintainer upload, or NMU."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:1775
+msgid ""
+"This section handles only source NMUs, i.e. NMUs which upload a new version "
+"of the package. For binary-only NMUs by porters or QA members, please see "
+"<xref linkend=\"binary-only-nmu\"/> . If a buildd builds and uploads a "
+"package, that too is strictly speaking a binary NMU. See <xref "
+"linkend=\"buildd\"/> for some more information."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:1782
+msgid ""
+"The main reason why NMUs are done is when a developer needs to fix another "
+"developer's package in order to address serious problems or crippling bugs "
+"or when the package maintainer is unable to release a fix in a timely "
+"fashion."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:1787
+msgid ""
+"First and foremost, it is critical that NMU patches to source should be as "
+"non-disruptive as possible. Do not do housekeeping tasks, do not change the "
+"name of modules or files, do not move directories; in general, do not fix "
+"things which are not broken. Keep the patch as small as possible. If "
+"things bother you aesthetically, talk to the Debian maintainer, talk to the "
+"upstream maintainer, or submit a bug. However, aesthetic changes must "
+"<emphasis>not</emphasis> be made in a non-maintainer upload."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:1796
+msgid ""
+"And please remember the Hippocratic Oath: Above all, do no harm. It is "
+"better to leave a package with an open grave bug than applying a "
+"non-functional patch, or one that hides the bug instead of resolving it."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1801
+msgid "How to do a NMU"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1803
+msgid ""
+"NMUs which fix important, serious or higher severity bugs are encouraged and "
+"accepted. You should endeavor to reach the current maintainer of the "
+"package; they might be just about to upload a fix for the problem, or have a "
+"better solution."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1809
+msgid ""
+"NMUs should be made to assist a package's maintainer in resolving bugs. "
+"Maintainers should be thankful for that help, and NMUers should respect the "
+"decisions of maintainers, and try to personally help the maintainer by their "
+"work."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1815
+msgid ""
+"A NMU should follow all conventions, written down in this section. For an "
+"upload to testing or unstable, this order of steps is recommended:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1821
+msgid ""
+"Make sure that the package's bugs that the NMU is meant to address are all "
+"filed in the Debian Bug Tracking System (BTS). If they are not, submit them "
+"immediately."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1828
+msgid ""
+"Wait a few days for the response from the maintainer. If you don't get any "
+"response, you may want to help them by sending the patch that fixes the "
+"bug. Don't forget to tag the bug with the patch keyword."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1835
+msgid ""
+"Wait a few more days. If you still haven't got an answer from the "
+"maintainer, send them a mail announcing your intent to NMU the package. "
+"Prepare an NMU as described in this section, and test it carefully on your "
+"machine (cf. <xref linkend=\"sanitycheck\"/> ). Double check that your "
+"patch doesn't have any unexpected side effects. Make sure your patch is as "
+"small and as non-disruptive as it can be."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1845
+msgid ""
+"Upload your package to incoming in <filename>DELAYED/7-day</filename> (cf. "
+"<xref linkend=\"delayed-incoming\"/> ), send the final patch to the "
+"maintainer via the BTS, and explain to them that they have 7 days to react "
+"if they want to cancel the NMU."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:1853
+msgid ""
+"Follow what happens, you're responsible for any bug that you introduced with "
+"your NMU. You should probably use <xref linkend=\"pkg-tracking-system\"/> "
+"(PTS) to stay informed of the state of the package after your NMU."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1860
+msgid ""
+"At times, the release manager or an organized group of developers can "
+"announce a certain period of time in which the NMU rules are relaxed. This "
+"usually involves shortening the period during which one is to wait before "
+"uploading the fixes, and shortening the DELAYED period. It is important to "
+"notice that even in these so-called bug squashing party times, the NMU'er "
+"has to file bugs and contact the developer first, and act later. Please see "
+"<xref linkend=\"qa-bsp\"/> for details."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1869
+msgid ""
+"For the testing distribution, the rules may be changed by the release "
+"managers. Please take additional care, and acknowledge that the usual way "
+"for a package to enter testing is through unstable."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1874
+msgid ""
+"For the stable distribution, please take extra care. Of course, the release "
+"managers may also change the rules here. Please verify before you upload "
+"that all your changes are OK for inclusion into the next stable release by "
+"the release manager."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1880
+msgid ""
+"When a security bug is detected, the security team may do an NMU, using "
+"their own rules. Please refer to <xref linkend=\"bug-security\"/> for more "
+"information."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1885
+msgid ""
+"For the differences for Porters NMUs, please see <xref "
+"linkend=\"source-nmu-when-porter\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1889
+msgid ""
+"Of course, it is always possible to agree on special rules with a maintainer "
+"(like the maintainer asking please upload this fix directly for me, and no "
+"diff required)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1896
+msgid "NMU version numbering"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1898
+msgid ""
+"Whenever you have made a change to a package, no matter how trivial, the "
+"version number needs to change. This enables our packing system to "
+"function."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1902
+msgid ""
+"If you are doing a non-maintainer upload (NMU), you should add a new minor "
+"version number to the <replaceable>debian-revision</replaceable> part of the "
+"version number (the portion after the last hyphen). This extra minor number "
+"will start at `1'. For example, consider the package `foo', which is at "
+"version 1.1-3. In the archive, the source package control file would be "
+"<filename>foo_1.1-3.dsc</filename>. The upstream version is `1.1' and the "
+"Debian revision is `3'. The next NMU would add a new minor number `.1' to "
+"the Debian revision; the new source control file would be "
+"<filename>foo_1.1-3.1.dsc</filename>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1913
+msgid ""
+"The Debian revision minor number is needed to avoid stealing one of the "
+"package maintainer's version numbers, which might disrupt their work. It "
+"also has the benefit of making it visually clear that a package in the "
+"archive was not made by the official maintainer."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1919
+msgid ""
+"If there is no <replaceable>debian-revision</replaceable> component in the "
+"version number then one should be created, starting at `0.1' (but in case of "
+"a debian native package still upload it as native package). If it is "
+"absolutely necessary for someone other than the usual maintainer to make a "
+"release based on a new upstream version then the person making the release "
+"should start with the <replaceable>debian-revision</replaceable> value "
+"`0.1'. The usual maintainer of a package should start their "
+"<replaceable>debian-revision</replaceable> numbering at `1'."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1929
+msgid ""
+"If you upload a package to testing or stable, sometimes, you need to fork "
+"the version number tree. For this, version numbers like 1.1-3sarge0.1 could "
+"be used."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1936
+msgid "Source NMUs must have a new changelog entry"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1938
+msgid ""
+"Anyone who is doing a source NMU must create a changelog entry, describing "
+"which bugs are fixed by the NMU, and generally why the NMU was required and "
+"what it fixed. The changelog entry will have the email address of the "
+"person who uploaded it in the log entry and the NMU version number in it."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1944
+msgid "By convention, source NMU changelog entries start with the line"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: pkgs.dbk:1947
+#, no-wrap
+msgid "* Non-maintainer upload"
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1952
+msgid "Source NMUs and the Bug Tracking System"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1954
+msgid ""
+"Maintainers other than the official package maintainer should make as few "
+"changes to the package as possible, and they should always send a patch as a "
+"unified context diff (<literal>diff -u</literal>) detailing their changes to "
+"the Bug Tracking System."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1960
+msgid ""
+"What if you are simply recompiling the package? If you just need to "
+"recompile it for a single architecture, then you may do a binary-only NMU as "
+"described in <xref linkend=\"binary-only-nmu\"/> which doesn't require any "
+"patch to be sent. If you want the package to be recompiled for all "
+"architectures, then you do a source NMU as usual and you will have to send a "
+"patch."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1967
+msgid ""
+"Bugs fixed by source NMUs used to be tagged fixed instead of closed, but "
+"since version tracking is in place, such bugs are now also closed with the "
+"NMU version."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1972
+msgid ""
+"Also, after doing an NMU, you have to send the information to the existing "
+"bugs that are fixed by your NMU, including the unified diff. Historically, "
+"it was custom to open a new bug and include a patch showing all the changes "
+"you have made. The normal maintainer will either apply the patch or employ "
+"an alternate method of fixing the problem. Sometimes bugs are fixed "
+"independently upstream, which is another good reason to back out an NMU's "
+"patch. If the maintainer decides not to apply the NMU's patch but to "
+"release a new version, the maintainer needs to ensure that the new upstream "
+"version really fixes each problem that was fixed in the non-maintainer "
+"release."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1983
+msgid ""
+"In addition, the normal maintainer should <emphasis>always</emphasis> retain "
+"the entry in the changelog file documenting the non-maintainer upload -- and "
+"of course, also keep the changes. If you revert some of the changes, please "
+"reopen the relevant bug reports."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:1991
+msgid "Building source NMUs"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1993
+msgid ""
+"Source NMU packages are built normally. Pick a distribution using the same "
+"rules as found in <xref linkend=\"distribution\"/> , follow the other "
+"instructions in <xref linkend=\"upload\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:1998
+msgid ""
+"Make sure you do <emphasis>not</emphasis> change the value of the maintainer "
+"in the <filename>debian/control</filename> file. Your name as given in the "
+"NMU entry of the <filename>debian/changelog</filename> file will be used for "
+"signing the changes file."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:2006
+msgid "Acknowledging an NMU"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2008
+msgid ""
+"If one of your packages has been NMU'ed, you have to incorporate the changes "
+"in your copy of the sources. This is easy, you just have to apply the patch "
+"that has been sent to you. Once this is done, you have to close the bugs "
+"that have been tagged fixed by the NMU. The easiest way is to use the "
+"<literal>-v</literal> option of <command>dpkg-buildpackage</command>, as "
+"this allows you to include just all changes since your last maintainer "
+"upload. Alternatively, you can close them manually by sending the required "
+"mails to the BTS or by adding the required <literal>closes: #nnnn</literal> "
+"in the changelog entry of your next upload."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2019
+msgid ""
+"In any case, you should not be upset by the NMU. An NMU is not a personal "
+"attack against the maintainer. It is a proof that someone cares enough "
+"about the package that they were willing to help you in your work, so you "
+"should be thankful. You may also want to ask them if they would be "
+"interested in helping you on a more frequent basis as co-maintainer or "
+"backup maintainer (see <xref linkend=\"collaborative-maint\"/> )."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:2029
+msgid "NMU vs QA uploads"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2031
+msgid ""
+"Unless you know the maintainer is still active, it is wise to check the "
+"package to see if it has been orphaned. The current list of orphaned "
+"packages which haven't had their maintainer set correctly is available at "
+"<ulink url=\"&url-debian-qa-orphaned;\"></ulink>. If you perform an NMU on "
+"an improperly orphaned package, please set the maintainer to <literal>Debian "
+"QA Group <packages@qa.debian.org></literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:2041
+msgid "Who can do an NMU"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2043
+msgid ""
+"Only official, registered Debian Developers can do binary or source NMUs. A "
+"Debian Developer is someone who has their key in the Debian key ring. "
+"Non-developers, however, are encouraged to download the source package and "
+"start hacking on it to fix problems; however, rather than doing an NMU, they "
+"should just submit worthwhile patches to the Bug Tracking System. "
+"Maintainers almost always appreciate quality patches and bug reports."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:2053
+msgid "Terminology"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2055
+msgid ""
+"There are two new terms used throughout this section: ``binary-only NMU'' "
+"and ``source NMU''. These terms are used with specific technical meaning "
+"throughout this document. Both binary-only and source NMUs are similar, "
+"since they involve an upload of a package by a developer who is not the "
+"official maintainer of that package. That is why it's a "
+"<emphasis>non-maintainer</emphasis> upload."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2063
+msgid ""
+"A source NMU is an upload of a package by a developer who is not the "
+"official maintainer, for the purposes of fixing a bug in the package. "
+"Source NMUs always involves changes to the source (even if it is just a "
+"change to <filename>debian/changelog</filename>). This can be either a "
+"change to the upstream source, or a change to the Debian bits of the "
+"source. Note, however, that source NMUs may also include "
+"architecture-dependent packages, as well as an updated Debian diff."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2072
+msgid ""
+"A binary-only NMU is a recompilation and upload of a binary package for a "
+"given architecture. As such, it is usually part of a porting effort. A "
+"binary-only NMU is a non-maintainer uploaded binary version of a package, "
+"with no source changes required. There are many cases where porters must "
+"fix problems in the source in order to get them to compile for their target "
+"architecture; that would be considered a source NMU rather than a "
+"binary-only NMU. As you can see, we don't distinguish in terminology "
+"between porter NMUs and non-porter NMUs."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2082
+msgid ""
+"Both classes of NMUs, source and binary-only, can be lumped under the term "
+"``NMU''. However, this often leads to confusion, since most people think "
+"``source NMU'' when they think ``NMU''. So it's best to be careful: always "
+"use ``binary NMU'' or ``binNMU'' for binary-only NMUs."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:2092
+msgid "Collaborative maintenance"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:2094
+msgid ""
+"Collaborative maintenance is a term describing the sharing of Debian package "
+"maintenance duties by several people. This collaboration is almost always a "
+"good idea, since it generally results in higher quality and faster bug fix "
+"turnaround times. It is strongly recommended that packages with a priority "
+"of <literal>Standard</literal> or which are part of the base set have "
+"co-maintainers."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:2102
+msgid ""
+"Generally there is a primary maintainer and one or more co-maintainers. The "
+"primary maintainer is the person whose name is listed in the "
+"<literal>Maintainer</literal> field of the "
+"<filename>debian/control</filename> file. Co-maintainers are all the other "
+"maintainers."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:2108
+msgid ""
+"In its most basic form, the process of adding a new co-maintainer is quite "
+"easy:"
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2114
+msgid ""
+"Setup the co-maintainer with access to the sources you build the package "
+"from. Generally this implies you are using a network-capable version "
+"control system, such as <command>CVS</command> or "
+"<command>Subversion</command>. Alioth (see <xref linkend=\"alioth\"/> ) "
+"provides such tools, amongst others."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2122
+msgid ""
+"Add the co-maintainer's correct maintainer name and address to the "
+"<literal>Uploaders</literal> field in the global part of the "
+"<filename>debian/control</filename> file."
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><screen>
+#: pkgs.dbk:2127
+#, no-wrap
+msgid ""
+"Uploaders: John Buzz <jbuzz@debian.org>, Adam Rex "
+"<arex@debian.org>"
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2132
+msgid ""
+"Using the PTS (<xref linkend=\"pkg-tracking-system\"/> ), the co-maintainers "
+"should subscribe themselves to the appropriate source package."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:2138
+msgid ""
+"Another form of collaborative maintenance is team maintenance, which is "
+"recommended if you maintain several packages with the same group of "
+"developers. In that case, the Maintainer and Uploaders field of each "
+"package must be managed with care. It is recommended to choose between one "
+"of the two following schemes:"
+msgstr ""
+
+# type: Content of: <chapter><section><orderedlist><listitem><para>
+#: pkgs.dbk:2147
+msgid ""
+"Put the team member mainly responsible for the package in the Maintainer "
+"field. In the Uploaders, put the mailing list address, and the team members "
+"who care for the package."
+msgstr ""
+
+# type: Content of: <chapter><section><orderedlist><listitem><para>
+#: pkgs.dbk:2154
+msgid ""
+"Put the mailing list address in the Maintainer field. In the Uploaders "
+"field, put the team members who care for the package. In this case, you "
+"must make sure the mailing list accept bug reports without any human "
+"interaction (like moderation for non-subscribers)."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: pkgs.dbk:2162
+msgid ""
+"In any case, it is a bad idea to automatically put all team members in the "
+"Uploaders field. It clutters the Developer's Package Overview listing (see "
+"<xref linkend=\"ddpo\"/> ) with packages one doesn't really care for, and "
+"creates a false sense of good maintenance."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: pkgs.dbk:2170
+msgid "The testing distribution"
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:2172
+msgid "Basics"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2174
+msgid ""
+"Packages are usually installed into the `testing' distribution after they "
+"have undergone some degree of testing in unstable."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2178
+msgid ""
+"They must be in sync on all architectures and mustn't have dependencies that "
+"make them uninstallable; they also have to have generally no known "
+"release-critical bugs at the time they're installed into testing. This way, "
+"`testing' should always be close to being a release candidate. Please see "
+"below for details."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:2187
+msgid "Updates from unstable"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2189
+msgid ""
+"The scripts that update the <emphasis>testing</emphasis> distribution are "
+"run each day after the installation of the updated packages; these scripts "
+"are called <emphasis>britney</emphasis>. They generate the "
+"<filename>Packages</filename> files for the <emphasis>testing</emphasis> "
+"distribution, but they do so in an intelligent manner; they try to avoid any "
+"inconsistency and to use only non-buggy packages."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2197
+msgid ""
+"The inclusion of a package from <emphasis>unstable</emphasis> is conditional "
+"on the following:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2203
+msgid ""
+"The package must have been available in <emphasis>unstable</emphasis> for 2, "
+"5 or 10 days, depending on the urgency (high, medium or low). Please note "
+"that the urgency is sticky, meaning that the highest urgency uploaded since "
+"the previous testing transition is taken into account. Those delays may be "
+"doubled during a freeze, or testing transitions may be switched off "
+"altogether;"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2212
+msgid ""
+"It must have the same number or fewer release-critical bugs than the version "
+"currently available in <emphasis>testing</emphasis>;"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2218
+msgid ""
+"It must be available on all architectures on which it has previously been "
+"built in unstable. <xref linkend=\"madison\"/> may be of interest to check "
+"that information;"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2225
+msgid ""
+"It must not break any dependency of a package which is already available in "
+"<emphasis>testing</emphasis>;"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2231
+msgid ""
+"The packages on which it depends must either be available in "
+"<emphasis>testing</emphasis> or they must be accepted into "
+"<emphasis>testing</emphasis> at the same time (and they will be if they "
+"fulfill all the necessary criteria);"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2239
+msgid ""
+"To find out whether a package is progressing into testing or not, see the "
+"testing script output on the <ulink url=\"&url-testing-maint;\">web page of "
+"the testing distribution</ulink>, or use the program "
+"<command>grep-excuses</command> which is in the <systemitem "
+"role=\"package\">devscripts</systemitem> package. This utility can easily "
+"be used in a <citerefentry> <refentrytitle>crontab</refentrytitle> "
+"<manvolnum>5</manvolnum> </citerefentry> to keep yourself informed of the "
+"progression of your packages into <emphasis>testing</emphasis>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2250
+msgid ""
+"The <filename>update_excuses</filename> file does not always give the "
+"precise reason why the package is refused; you may have to find it on your "
+"own by looking for what would break with the inclusion of the package. The "
+"<ulink url=\"&url-testing-maint;\">testing web page</ulink> gives some more "
+"information about the usual problems which may be causing such troubles."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2257
+msgid ""
+"Sometimes, some packages never enter <emphasis>testing</emphasis> because "
+"the set of inter-relationship is too complicated and cannot be sorted out by "
+"the scripts. See below for details."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2262
+msgid ""
+"Some further dependency analysis is shown on <ulink "
+"url=\"http://bjorn.haxx.se/debian/\"></ulink> — but be warned, this page "
+"also shows build dependencies which are not considered by britney."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:2267
+msgid "out-of-date"
+msgstr ""
+
+#. FIXME: better rename this file than document rampant professionalism?
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2270
+msgid ""
+"For the testing migration script, outdated means: There are different "
+"versions in unstable for the release architectures (except for the "
+"architectures in fuckedarches; fuckedarches is a list of architectures that "
+"don't keep up (in update_out.py), but currently, it's empty). outdated has "
+"nothing whatsoever to do with the architectures this package has in testing."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2277
+msgid "Consider this example:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry>
+#: pkgs.dbk:2284 pkgs.dbk:2315
+msgid "alpha"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry>
+#: pkgs.dbk:2285 pkgs.dbk:2316
+msgid "arm"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry>
+#: pkgs.dbk:2290 pkgs.dbk:2322 pkgs.dbk:2382
+msgid "testing"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
+#: pkgs.dbk:2291 pkgs.dbk:2296 pkgs.dbk:2323 pkgs.dbk:2324 pkgs.dbk:2331
+msgid "1"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
+#: pkgs.dbk:2292 pkgs.dbk:2325 pkgs.dbk:2330
+msgid "-"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry>
+#: pkgs.dbk:2295 pkgs.dbk:2328 pkgs.dbk:2383
+msgid "unstable"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
+#: pkgs.dbk:2297 pkgs.dbk:2329
+msgid "2"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2303
+msgid ""
+"The package is out of date on alpha in unstable, and will not go to "
+"testing. And removing foo from testing would not help at all, the package "
+"is still out of date on alpha, and will not propagate to testing."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2308
+msgid "However, if ftp-master removes a package in unstable (here on arm):"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry>
+#: pkgs.dbk:2317
+msgid "hurd-i386"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2337
+msgid ""
+"In this case, the package is up to date on all release architectures in "
+"unstable (and the extra hurd-i386 doesn't matter, as it's not a release "
+"architecture)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2342
+msgid ""
+"Sometimes, the question is raised if it is possible to allow packages in "
+"that are not yet built on all architectures: No. Just plainly no. (Except "
+"if you maintain glibc or so.)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:2349
+msgid "Removals from testing"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2351
+msgid ""
+"Sometimes, a package is removed to allow another package in: This happens "
+"only to allow <emphasis>another</emphasis> package to go in if it's ready in "
+"every other sense. Suppose e.g. that <emphasis>a</emphasis> cannot be "
+"installed with the new version of <emphasis>b</emphasis>; then "
+"<emphasis>a</emphasis> may be removed to allow <emphasis>b</emphasis> in."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2358
+msgid ""
+"Of course, there is another reason to remove a package from testing: It's "
+"just too buggy (and having a single RC-bug is enough to be in this state)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2362
+msgid ""
+"Furthermore, if a package has been removed from unstable, and no package in "
+"testing depends on it any more, then it will automatically be removed."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:2368
+msgid "circular dependencies"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2370
+msgid ""
+"A situation which is not handled very well by britney is if package "
+"<emphasis>a</emphasis> depends on the new version of package "
+"<emphasis>b</emphasis>, and vice versa."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2375
+msgid "An example of this is:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
+#: pkgs.dbk:2388
+msgid "a"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
+#: pkgs.dbk:2389
+msgid "1; depends: b=1"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
+#: pkgs.dbk:2390
+msgid "2; depends: b=2"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
+#: pkgs.dbk:2393
+msgid "b"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
+#: pkgs.dbk:2394
+msgid "1; depends: a=1"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry>
+#: pkgs.dbk:2395
+msgid "2; depends: a=2"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2401
+msgid ""
+"Neither package <emphasis>a</emphasis> nor package <emphasis>b</emphasis> is "
+"considered for update."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2405
+msgid ""
+"Currently, this requires some manual hinting from the release team. Please "
+"contact them by sending mail to &email-debian-release; if this happens to "
+"one of your packages."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:2412
+msgid "influence of package in testing"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2414
+msgid ""
+"Generally, there is nothing that the status of a package in testing means "
+"for transition of the next version from unstable to testing, with two "
+"exceptions: If the RC-bugginess of the package goes down, it may go in even "
+"if it is still RC-buggy. The second exception is if the version of the "
+"package in testing is out of sync on the different arches: Then any arch "
+"might just upgrade to the version of the source package; however, this can "
+"happen only if the package was previously forced through, the arch is in "
+"fuckedarches, or there was no binary package of that arch present in "
+"unstable at all during the testing migration."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2424
+msgid ""
+"In summary this means: The only influence that a package being in testing "
+"has on a new version of the same package is that the new version might go in "
+"easier."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:2431
+msgid "details"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2433
+msgid "If you are interested in details, this is how britney works:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2436
+msgid ""
+"The packages are looked at to determine whether they are valid candidates. "
+"This gives the update excuses. The most common reasons why a package is not "
+"considered are too young, RC-bugginess, and out of date on some arches. For "
+"this part of britney, the release managers have hammers of various sizes to "
+"force britney to consider a package. (Also, the base freeze is coded in "
+"that part of britney.) (There is a similar thing for binary-only updates, "
+"but this is not described here. If you're interested in that, please peruse "
+"the code.)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2445
+msgid ""
+"Now, the more complex part happens: Britney tries to update testing with the "
+"valid candidates; first, each package alone, and then larger and even larger "
+"sets of packages together. Each try is accepted if testing is not more "
+"uninstallable after the update than before. (Before and after this part, "
+"some hints are processed; but as only release masters can hint, this is "
+"probably not so important for you.)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2453
+msgid ""
+"If you want to see more details, you can look it up on "
+"merkel:/org/&ftp-debian-org;/testing/update_out/ (or there in "
+"~aba/testing/update_out to see a setup with a smaller packages file). Via "
+"web, it's at <ulink "
+"url=\"http://&ftp-master-host;/testing/update_out_code/\"></ulink>"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2460
+msgid ""
+"The hints are available via <ulink "
+"url=\"http://&ftp-master-host;/testing/hints/\"></ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:2468
+msgid "Direct updates to testing"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2470
+msgid ""
+"The testing distribution is fed with packages from unstable according to the "
+"rules explained above. However, in some cases, it is necessary to upload "
+"packages built only for testing. For that, you may want to upload to "
+"<emphasis>testing-proposed-updates</emphasis>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2476
+msgid ""
+"Keep in mind that packages uploaded there are not automatically processed, "
+"they have to go through the hands of the release manager. So you'd better "
+"have a good reason to upload there. In order to know what a good reason is "
+"in the release managers' eyes, you should read the instructions that they "
+"regularly give on &email-debian-devel-announce;."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2483
+msgid ""
+"You should not upload to <emphasis>testing-proposed-updates</emphasis> when "
+"you can update your packages through <emphasis>unstable</emphasis>. If you "
+"can't (for example because you have a newer development version in "
+"unstable), you may use this facility, but it is recommended that you ask for "
+"authorization from the release manager first. Even if a package is frozen, "
+"updates through unstable are possible, if the upload via unstable does not "
+"pull in any new dependencies."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2492
+msgid ""
+"Version numbers are usually selected by adding the codename of the testing "
+"distribution and a running number, like 1.2sarge1 for the first upload "
+"through testing-proposed-updates of package version 1.2."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: pkgs.dbk:2497
+msgid "Please make sure you didn't miss any of these items in your upload:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2502
+msgid ""
+"Make sure that your package really needs to go through "
+"<emphasis>testing-proposed-updates</emphasis>, and can't go through "
+"unstable;"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2508
+msgid "Make sure that you included only the minimal amount of changes;"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2513
+msgid "Make sure that you included an appropriate explanation in the changelog;"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2518
+msgid ""
+"Make sure that you've written <emphasis>testing</emphasis> or "
+"<emphasis>testing-proposed-updates</emphasis> into your target distribution;"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2524
+msgid ""
+"Make sure that you've built and tested your package in "
+"<emphasis>testing</emphasis>, not in <emphasis>unstable</emphasis>;"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2530
+msgid ""
+"Make sure that your version number is higher than the version in "
+"<emphasis>testing</emphasis> and "
+"<emphasis>testing-proposed-updates</emphasis>, and lower than in "
+"<emphasis>unstable</emphasis>;"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: pkgs.dbk:2537
+msgid ""
+"After uploading and successful build on all platforms, contact the release "
+"team at &email-debian-release; and ask them to approve your upload."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: pkgs.dbk:2545
+msgid "Frequently asked questions"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:2547
+msgid "What are release-critical bugs, and how do they get counted?"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2549
+msgid ""
+"All bugs of some higher severities are by default considered "
+"release-critical; currently, these are critical, grave, and serious bugs."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2553
+msgid ""
+"Such bugs are presumed to have an impact on the chances that the package "
+"will be released with the stable release of Debian: in general, if a package "
+"has open release-critical bugs filed on it, it won't get into testing, and "
+"consequently won't be released in stable."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2559
+msgid ""
+"The unstable bug count are all release-critical bugs without either any "
+"release-tag (such as potato, woody) or with release-tag sid; also, only if "
+"they are neither fixed nor set to sarge-ignore. The testing bug count for a "
+"package is considered to be roughly the bug count of unstable count at the "
+"last point when the testing version equalled the unstable version."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2566
+msgid ""
+"This will change post-sarge, as soon as we have versions in the bug tracking "
+"system."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: pkgs.dbk:2572
+msgid "How could installing a package into testing possibly break other packages?"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2574
+msgid ""
+"The structure of the distribution archives is such that they can only "
+"contain one version of a package; a package is defined by its name. So when "
+"the source package acmefoo is installed into testing, along with its binary "
+"packages acme-foo-bin, acme-bar-bin, libacme-foo1 and libacme-foo-dev, the "
+"old version is removed."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2581
+msgid ""
+"However, the old version may have provided a binary package with an old "
+"soname of a library, such as libacme-foo0. Removing the old acmefoo will "
+"remove libacme-foo0, which will break any packages which depend on it."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2586
+msgid ""
+"Evidently, this mainly affects packages which provide changing sets of "
+"binary packages in different versions (in turn, mainly libraries). However, "
+"it will also affect packages upon which versioned dependencies have been "
+"declared of the ==, <=, or << varieties."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2592
+msgid ""
+"When the set of binary packages provided by a source package change in this "
+"way, all the packages that depended on the old binaries will have to be "
+"updated to depend on the new binaries instead. Because installing such a "
+"source package into testing breaks all the packages that depended on it in "
+"testing, some care has to be taken now: all the depending packages must be "
+"updated and ready to be installed themselves so that they won't be broken, "
+"and, once everything is ready, manual intervention by the release manager or "
+"an assistant is normally required."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: pkgs.dbk:2602
+msgid ""
+"If you are having problems with complicated groups of packages like this, "
+"contact debian-devel or debian-release for help."
+msgstr ""
--- /dev/null
+# SOME DESCRIPTIVE TITLE
+# Copyright (C) YEAR Free Software Foundation, Inc.
+# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
+#
+#, fuzzy
+msgid ""
+msgstr ""
+"Project-Id-Version: PACKAGE VERSION\n"
+"POT-Creation-Date: 2007-07-01 21:01+0000\n"
+"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
+"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
+"Language-Team: LANGUAGE <LL@li.org>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=utf-8\n"
+"Content-Transfer-Encoding: ENCODING"
+
+# type: Content of: <chapter><title>
+#: resources.dbk:7
+msgid "Resources for Debian Developers"
+msgstr ""
+
+# type: Content of: <chapter><para>
+#: resources.dbk:9
+msgid ""
+"In this chapter you will find a very brief road map of the Debian mailing "
+"lists, the Debian machines which may be available to you as a developer, and "
+"all the other resources that are available to help you in your maintainer "
+"work."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: resources.dbk:14
+msgid "Mailing lists"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:16
+msgid ""
+"Much of the conversation between Debian developers (and users) is managed "
+"through a wide array of mailing lists we host at <literal><ulink "
+"url=\"http://&lists-host;/\">&lists-host;</ulink></literal>. 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 <ulink url=\"&url-debian-lists;\"></ulink>. This section will "
+"only cover aspects of mailing lists that are of particular interest to "
+"developers."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:27
+msgid "Basic rules for use"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:29
+msgid ""
+"When replying to messages on the mailing list, please do not send a carbon "
+"copy (<literal>CC</literal>) 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."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:35
+msgid ""
+"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."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:40
+msgid ""
+"Please read the <ulink url=\"&url-debian-lists;#codeofconduct\">code of "
+"conduct</ulink> for more information."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:47
+msgid "Core development mailing lists"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:49
+msgid "The core Debian mailing lists that developers should use are:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: resources.dbk:54
+msgid ""
+"&email-debian-devel-announce;, used to announce important things to "
+"developers. All developers are expected to be subscribed to this list."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: resources.dbk:61
+msgid ""
+"&email-debian-devel;, used to discuss various development related technical "
+"issues."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: resources.dbk:67
+msgid "&email-debian-policy;, where the Debian Policy is discussed and voted on."
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: resources.dbk:73
+msgid ""
+"&email-debian-project;, used to discuss various non-technical issues related "
+"to the project."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:79
+msgid ""
+"There are other mailing lists available for a variety of special topics; see "
+"<ulink url=\"http://&lists-host;/\"></ulink> for a list."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:85
+msgid "Special lists"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:87
+msgid ""
+"&email-debian-private; is a special mailing list for private discussions "
+"amongst Debian developers. It is meant to be used for posts which for "
+"whatever reason should not be published publicly. As such, it is a low "
+"volume list, and users are urged not to use &email-debian-private; unless it "
+"is really necessary. Moreover, do <emphasis>not</emphasis> forward email "
+"from that list to anyone. Archives of this list are not available on the "
+"web for obvious reasons, but you can see them using your shell account on "
+"<literal>&lists-host;</literal> and looking in the "
+"<filename>&file-debian-private-archive;</filename> directory."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:99
+msgid ""
+"&email-debian-email; is a special mailing list used as a grab-bag 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."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:107
+msgid "Requesting new development-related lists"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:109
+msgid ""
+"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 <replaceable>you-aliasname@debian.org</replaceable> "
+"address) or a self-managed mailing list on <link "
+"linkend=\"alioth\">Alioth</link> is more appropriate."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:117
+msgid ""
+"If you decide that a regular mailing list on &lists-host; is really what you "
+"want, go ahead and fill in a request, following <ulink "
+"url=\"&url-debian-lists-new;\">the HOWTO</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: resources.dbk:126
+msgid "IRC channels"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:128
+msgid ""
+"Several IRC channels are dedicated to Debian's development. They are mainly "
+"hosted on the <ulink url=\"&url-oftc;\">Open and free technology community "
+"(OFTC)</ulink> network. The <literal>irc.debian.org</literal> DNS entry is "
+"an alias to <literal>irc.oftc.net</literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:134
+msgid ""
+"The main channel for Debian in general is <emphasis>#debian</emphasis>. "
+"This is a large, general-purpose channel where users can find recent news in "
+"the topic and served by bots. <emphasis>#debian</emphasis> is for English "
+"speakers; there are also <emphasis>#debian.de</emphasis>, "
+"<emphasis>#debian-fr</emphasis>, <emphasis>#debian-br</emphasis> and other "
+"similarly named channels for speakers of other languages."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:142
+msgid ""
+"The main channel for Debian development is "
+"<emphasis>#debian-devel</emphasis>. It is a very active channel since "
+"usually over 150 people are always logged in. It's a channel for people who "
+"work on Debian, it's not a support channel (there's "
+"<emphasis>#debian</emphasis> for that). It is however open to anyone who "
+"wants to lurk (and learn). Its topic is commonly full of interesting "
+"information for developers."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:150
+msgid ""
+"Since <emphasis>#debian-devel</emphasis> is an open channel, you should not "
+"speak there of issues that are discussed in &email-debian-private;. There's "
+"another channel for this purpose, it's called "
+"<emphasis>#debian-private</emphasis> and it's protected by a key. This key "
+"is available in the archives of debian-private in "
+"<filename>master.debian.org:&file-debian-private-archive;</filename>, just "
+"<command>zgrep</command> for <emphasis>#debian-private</emphasis> in all the "
+"files."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:160
+msgid ""
+"There are other additional channels dedicated to specific subjects. "
+"<emphasis>#debian-bugs</emphasis> is used for coordinating bug squashing "
+"parties. <emphasis>#debian-boot</emphasis> is used to coordinate the work "
+"on the debian-installer. <emphasis>#debian-doc</emphasis> is occasionally "
+"used to talk about documentation, like the document you are reading. Other "
+"channels are dedicated to an architecture or a set of packages: "
+"<emphasis>#debian-bsd</emphasis>, <emphasis>#debian-kde</emphasis>, "
+"<emphasis>#debian-jr</emphasis>, <emphasis>#debian-edu</emphasis>, "
+"<emphasis>#debian-sf</emphasis> (SourceForge package), "
+"<emphasis>#debian-oo</emphasis> (OpenOffice package) ..."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:172
+msgid ""
+"Some non-English developers' channels exist as well, for example "
+"<emphasis>#debian-devel-fr</emphasis> for French speaking people interested "
+"in Debian's development."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:177
+msgid ""
+"Channels dedicated to Debian also exist on other IRC networks, notably on "
+"the <ulink url=\"&url-openprojects;\">freenode</ulink> IRC network, which "
+"was pointed at by the <literal>irc.debian.org</literal> alias until 4th June "
+"2006."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:183
+msgid ""
+"To get a cloak on freenode, you send Jörg Jaspert <joerg@debian.org> a "
+"signed mail where you tell what your nick is. Put cloak somewhere in the "
+"Subject: header. The nick should be registered: <ulink "
+"url=\"http://freenode.net/faq.shtml#nicksetup\">Nick Setup Page</ulink>. "
+"The mail needs to be signed by a key in the Debian keyring. Please see "
+"<ulink url=\"http://freenode.net/faq.shtml#projectcloak\">Freenodes "
+"documentation</ulink> for more information about cloaks."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: resources.dbk:194
+msgid "Documentation"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:196
+msgid ""
+"This document contains a lot of information which is useful to Debian "
+"developers, but it cannot contain everything. Most of the other interesting "
+"documents are linked from <ulink url=\"&url-devel-docs;\">The Developers' "
+"Corner</ulink>. Take the time to browse all the links, you will learn many "
+"more things."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: resources.dbk:205
+msgid "Debian machines"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:207
+msgid ""
+"Debian has several computers working as servers, most of which serve "
+"critical functions in the Debian project. Most of the machines are used for "
+"porting activities, and they all have a permanent connection to the "
+"Internet."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:212
+msgid ""
+"Most of the machines are available for individual developers to use, as long "
+"as the developers follow the rules set forth in the <ulink "
+"url=\"&url-dmup;\">Debian Machine Usage Policies</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:217
+msgid ""
+"Generally speaking, you can use these machines for Debian-related purposes "
+"as you see fit. Please be kind to system administrators, and do not use up "
+"tons and tons of disk space, network bandwidth, or CPU without first getting "
+"the approval of the system administrators. Usually these machines are run "
+"by volunteers."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:224
+msgid ""
+"Please take care to protect your Debian passwords and SSH keys installed on "
+"Debian machines. Avoid login or upload methods which send passwords over "
+"the Internet in the clear, such as telnet, FTP, POP etc."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:229
+msgid ""
+"Please do not put any material that doesn't relate to Debian on the Debian "
+"servers, unless you have prior permission."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:233
+msgid ""
+"The current list of Debian machines is available at <ulink "
+"url=\"&url-devel-machines;\"></ulink>. That web page contains machine "
+"names, contact information, information about who can log in, SSH keys etc."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:239
+msgid ""
+"If you have a problem with the operation of a Debian server, and you think "
+"that the system operators need to be notified of this problem, the Debian "
+"system administrator team is reachable at "
+"<email>debian-admin@&lists-host;</email>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:245
+msgid ""
+"If you have a problem with a certain service, not related to the system "
+"administration (such as packages to be removed from the archive, suggestions "
+"for the web site, etc.), generally you'll report a bug against a "
+"``pseudo-package''. See <xref linkend=\"submit-bug\"/> for information on "
+"how to submit bugs."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:252
+msgid ""
+"Some of the core servers are restricted, but the information from there is "
+"mirrored to another server."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:256
+msgid "The bugs server"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:258
+msgid ""
+"<literal>&bugs-host;</literal> is the canonical location for the Bug "
+"Tracking System (BTS)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:262 resources.dbk:280
+msgid "It is restricted; a mirror is available on <literal>merkel</literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:265
+msgid ""
+"If you plan on doing some statistical analysis or processing of Debian bugs, "
+"this would be the place to do it. Please describe your plans on "
+"&email-debian-devel; before implementing anything, however, to reduce "
+"unnecessary duplication of effort or wasted processing time."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:273
+msgid "The ftp-master server"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:275
+msgid ""
+"The <literal>&ftp-master-host;</literal> server holds the canonical copy of "
+"the Debian archive (excluding the non-US packages). Generally, package "
+"uploads go to this server; see <xref linkend=\"upload\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:283
+msgid ""
+"Problems with the Debian FTP archive generally need to be reported as bugs "
+"against the <systemitem role=\"package\">&ftp-debian-org;</systemitem> "
+"pseudo-package or an email to &email-ftpmaster;, but also see the procedures "
+"in <xref linkend=\"archive-manip\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:291
+msgid "The non-US server"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:293
+msgid ""
+"The non-US server <literal>&non-us-host;</literal> was discontinued with the "
+"release of sarge. The pseudo-package <systemitem "
+"role=\"package\">nonus.debian.org</systemitem> still exists for now."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:300
+msgid "The www-master server"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:302
+msgid ""
+"The main web server is <literal>www-master.debian.org</literal>. It holds "
+"the official web pages, the face of Debian for most newbies."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:306
+msgid ""
+"If you find a problem with the Debian web server, you should generally "
+"submit a bug against the pseudo-package, <systemitem "
+"role=\"package\">www.debian.org</systemitem>. Remember to check whether or "
+"not someone else has already reported the problem to the <ulink "
+"url=\"http://&bugs-host;/&www-debian-org;\">Bug Tracking System</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:315
+msgid "The people web server"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:317
+msgid ""
+"<literal>people.debian.org</literal> is the server used for developers' own "
+"web pages about anything related to Debian."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:321
+msgid ""
+"If you have some Debian-specific information which you want to serve on the "
+"web, you can do this by putting material in the "
+"<filename>public_html</filename> directory under your home directory on "
+"<literal>people.debian.org</literal>. This will be accessible at the URL "
+"<literal>http://people.debian.org/~<replaceable>your-user-id</replaceable>/</literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:328
+msgid ""
+"You should only use this particular location because it will be backed up, "
+"whereas on other hosts it won't."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:332
+msgid ""
+"Usually the only reason to use a different host is when you need to publish "
+"materials subject to the U.S. export restrictions, in which case you can "
+"use one of the other servers located outside the United States."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:337
+msgid "Send mail to &email-debian-devel; if you have any questions."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:342
+msgid "The CVS server"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:345
+msgid "Our CVS server is located on <literal>cvs.debian.org</literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:348
+msgid ""
+"If you need to use a publicly accessible CVS server, for instance, to help "
+"coordinate work on a package between many different developers, you can "
+"request a CVS area on the server."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:353
+msgid ""
+"Generally, <literal>cvs.debian.org</literal> offers a combination of local "
+"CVS access, anonymous client-server read-only access, and full client-server "
+"access through <command>ssh</command>. Also, the CVS area can be accessed "
+"read-only via the Web at <ulink url=\"&url-cvsweb;\"></ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:359
+msgid ""
+"To request a CVS area, send a request via email to &email-debian-admin;. "
+"Include the name of the requested CVS area, the Debian account that should "
+"own the CVS root area, and why you need it."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:367
+msgid "chroots to different distributions"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:369
+msgid ""
+"On some machines, there are chroots to different distributions available. "
+"You can use them like this:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: resources.dbk:373
+#, no-wrap
+msgid ""
+"vore$ dchroot unstable\n"
+"Executing shell in chroot: /org/vore.debian.org/chroots/user/unstable"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:377
+msgid ""
+"In all chroots, the normal user home directories are available. You can "
+"find out which chroots are available via "
+"<literal>&url-devel-machines;</literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: resources.dbk:386
+msgid "The Developers Database"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:388
+msgid ""
+"The Developers Database, at <ulink url=\"&url-debian-db;\"></ulink>, is an "
+"LDAP directory for managing Debian developer attributes. You can use this "
+"resource to search the list of Debian developers. Part of this information "
+"is also available through the finger service on Debian servers, try "
+"<command>finger yourlogin@db.debian.org</command> to see what it reports."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:396
+msgid ""
+"Developers can <ulink url=\"&url-debian-db-login;\">log into the "
+"database</ulink> to change various information about themselves, such as:"
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: resources.dbk:402
+msgid "forwarding address for your debian.org email"
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: resources.dbk:407
+msgid "subscription to debian-private"
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: resources.dbk:412
+msgid "whether you are on vacation"
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: resources.dbk:417
+msgid ""
+"personal information such as your address, country, the latitude and "
+"longitude of the place where you live for use in <ulink "
+"url=\"&url-worldmap;\">the world map of Debian developers</ulink>, phone and "
+"fax numbers, IRC nickname and web page"
+msgstr ""
+
+# type: Content of: <chapter><section><itemizedlist><listitem><para>
+#: resources.dbk:425
+msgid "password and preferred shell on Debian Project machines"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:430
+msgid ""
+"Most of the information is not accessible to the public, naturally. For "
+"more information please read the online documentation that you can find at "
+"<ulink url=\"&url-debian-db-doc;\"></ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:435
+msgid ""
+"Developers can also submit their SSH keys to be used for authorization on "
+"the official Debian machines, and even add new *.debian.net DNS entries. "
+"Those features are documented at <ulink "
+"url=\"&url-debian-db-mail-gw;\"></ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: resources.dbk:443
+msgid "The Debian archive"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:445
+msgid ""
+"The &debian-formal; distribution consists of a lot of packages "
+"(<filename>.deb</filename>'s, currently around &number-of-pkgs;) and a few "
+"additional files (such as documentation and installation disk images)."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:451
+msgid "Here is an example directory tree of a complete Debian archive:"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:455
+msgid ""
+"As you can see, the top-level directory contains two directories, "
+"<filename>dists/</filename> and <filename>pool/</filename>. The latter is a "
+"“pool” in which the packages actually are, and which is handled by the "
+"archive maintenance database and the accompanying programs. The former "
+"contains the distributions, <emphasis>stable</emphasis>, "
+"<emphasis>testing</emphasis> and <emphasis>unstable</emphasis>. The "
+"<filename>Packages</filename> and <filename>Sources</filename> files in the "
+"distribution subdirectories can reference files in the "
+"<filename>pool/</filename> directory. The directory tree below each of the "
+"distributions is arranged in an identical manner. What we describe below "
+"for <emphasis>stable</emphasis> is equally applicable to the "
+"<emphasis>unstable</emphasis> and <emphasis>testing</emphasis> "
+"distributions."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:469
+msgid ""
+"<filename>dists/stable</filename> contains three directories, namely "
+"<filename>main</filename>, <filename>contrib</filename>, and "
+"<filename>non-free</filename>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:474
+msgid ""
+"In each of the areas, there is a directory for the source packages "
+"(<filename>source</filename>) and a directory for each supported "
+"architecture (<filename>binary-i386</filename>, "
+"<filename>binary-m68k</filename>, etc.)."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:479
+msgid ""
+"The <filename>main</filename> 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 "
+"(<filename>disks-i386</filename>, <filename>disks-m68k</filename>, etc.)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:485
+msgid "Sections"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:487
+msgid ""
+"The <emphasis>main</emphasis> section of the Debian archive is what makes up "
+"the <emphasis role=\"strong\">official &debian-formal; "
+"distribution</emphasis>. The <emphasis>main</emphasis> section is official "
+"because it fully complies with all our guidelines. The other two sections "
+"do not, to different degrees; as such, they are <emphasis "
+"role=\"strong\">not</emphasis> officially part of &debian-formal;."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:495
+msgid ""
+"Every package in the main section must fully comply with the <ulink "
+"url=\"&url-dfsg;\">Debian Free Software Guidelines</ulink> (DFSG) and with "
+"all other policy requirements as described in the <ulink "
+"url=\"&url-debian-policy;\">Debian Policy Manual</ulink>. The DFSG is our "
+"definition of “free software.” Check out the Debian Policy Manual for "
+"details."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:503
+msgid ""
+"Packages in the <emphasis>contrib</emphasis> section have to comply with the "
+"DFSG, but may fail other requirements. For instance, they may depend on "
+"non-free packages."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:508
+msgid ""
+"Packages which do not conform to the DFSG are placed in the "
+"<emphasis>non-free</emphasis> section. These packages are not considered as "
+"part of the Debian distribution, though we support their use, and we provide "
+"infrastructure (such as our bug-tracking system and mailing lists) for "
+"non-free software packages."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:515
+msgid ""
+"The <ulink url=\"&url-debian-policy;\">Debian Policy Manual</ulink> contains "
+"a more exact definition of the three sections. The above discussion is just "
+"an introduction."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:520
+msgid ""
+"The separation of the three sections at the top-level of the archive is "
+"important for all people who want to distribute Debian, either via FTP "
+"servers on the Internet or on CD-ROMs: by distributing only the "
+"<emphasis>main</emphasis> and <emphasis>contrib</emphasis> sections, one can "
+"avoid any legal risks. Some packages in the <emphasis>non-free</emphasis> "
+"section do not allow commercial distribution, for example."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:528
+msgid ""
+"On the other hand, a CD-ROM vendor could easily check the individual package "
+"licenses of the packages in <emphasis>non-free</emphasis> and include as "
+"many on the CD-ROMs as it's allowed to. (Since this varies greatly from "
+"vendor to vendor, this job can't be done by the Debian developers.)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:534
+msgid ""
+"Note that the term section is also used to refer to categories which "
+"simplify the organization and browsing of available packages, e.g. "
+"<emphasis>admin</emphasis>, <emphasis>net</emphasis>, "
+"<emphasis>utils</emphasis> etc. Once upon a time, these sections "
+"(subsections, rather) existed in the form of subdirectories within the "
+"Debian archive. Nowadays, these exist only in the Section header fields of "
+"packages."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:544
+msgid "Architectures"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:546
+msgid ""
+"In the first days, the Linux kernel was only available for Intel i386 (or "
+"greater) platforms, and so was Debian. But as Linux became more and more "
+"popular, the kernel was ported to other architectures, too."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:551
+msgid ""
+"The Linux 2.0 kernel supports Intel x86, DEC Alpha, SPARC, Motorola 680x0 "
+"(like Atari, Amiga and Macintoshes), MIPS, and PowerPC. The 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 kernels. Aside from <emphasis>i386</emphasis> (our name for "
+"Intel x86), there is <emphasis>m68k</emphasis>, <emphasis>alpha</emphasis>, "
+"<emphasis>powerpc</emphasis>, <emphasis>sparc</emphasis>, "
+"<emphasis>hurd-i386</emphasis>, <emphasis>arm</emphasis>, "
+"<emphasis>ia64</emphasis>, <emphasis>hppa</emphasis>, "
+"<emphasis>s390</emphasis>, <emphasis>mips</emphasis>, "
+"<emphasis>mipsel</emphasis> and <emphasis>sh</emphasis> as of this writing."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:565
+msgid ""
+"&debian-formal; 1.3 is only available as <emphasis>i386</emphasis>. Debian "
+"2.0 shipped for <emphasis>i386</emphasis> and <emphasis>m68k</emphasis> "
+"architectures. Debian 2.1 ships for the <emphasis>i386</emphasis>, "
+"<emphasis>m68k</emphasis>, <emphasis>alpha</emphasis>, and "
+"<emphasis>sparc</emphasis> architectures. Debian 2.2 added support for the "
+"<emphasis>powerpc</emphasis> and <emphasis>arm</emphasis> architectures. "
+"Debian 3.0 added support of five new architectures: "
+"<emphasis>ia64</emphasis>, <emphasis>hppa</emphasis>, "
+"<emphasis>s390</emphasis>, <emphasis>mips</emphasis> and "
+"<emphasis>mipsel</emphasis>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:576
+msgid ""
+"Information for developers and users about the specific ports are available "
+"at the <ulink url=\"&url-debian-ports;\">Debian Ports web pages</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:582
+msgid "Packages"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:584
+msgid ""
+"There are two types of Debian packages, namely <emphasis>source</emphasis> "
+"and <emphasis>binary</emphasis> packages."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:588
+msgid ""
+"Source packages consist of either two or three files: a "
+"<filename>.dsc</filename> file, and either a <filename>.tar.gz</filename> "
+"file or both an <filename>.orig.tar.gz</filename> and a "
+"<filename>.diff.gz</filename> file."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:594
+msgid ""
+"If a package is developed specially for Debian and is not distributed "
+"outside of Debian, there is just one <filename>.tar.gz</filename> file which "
+"contains the sources of the program. If a package is distributed elsewhere "
+"too, the <filename>.orig.tar.gz</filename> file stores the so-called "
+"<emphasis>upstream source code</emphasis>, that is the source code that's "
+"distributed by the <emphasis>upstream maintainer</emphasis> (often the "
+"author of the software). In this case, the <filename>.diff.gz</filename> "
+"contains the changes made by the Debian maintainer."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:604
+msgid ""
+"The <filename>.dsc</filename> file lists all the files in the source package "
+"together with checksums (<command>md5sums</command>) and some additional "
+"info about the package (maintainer, version, etc.)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:611
+msgid "Distributions"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:613
+msgid ""
+"The directory system described in the previous chapter is itself contained "
+"within <emphasis>distribution directories</emphasis>. Each distribution is "
+"actually contained in the <filename>pool</filename> directory in the "
+"top-level of the Debian archive itself."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:619
+msgid ""
+"To summarize, the Debian archive has a root directory within an FTP server. "
+"For instance, at the mirror site, <literal>ftp.us.debian.org</literal>, the "
+"Debian archive itself is contained in <ulink "
+"url=\"ftp://ftp.us.debian.org/debian\">/debian</ulink>, which is a common "
+"location (another is <filename>/pub/debian</filename>)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:626
+msgid ""
+"A distribution comprises Debian source and binary packages, and the "
+"respective <filename>Sources</filename> and <filename>Packages</filename> "
+"index files, containing the header information from all those packages. The "
+"former are kept in the <filename>pool/</filename> directory, while the "
+"latter are kept in the <filename>dists/</filename> directory of the archive "
+"(for backwards compatibility)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: resources.dbk:634
+msgid "Stable, testing, and unstable"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: resources.dbk:636
+msgid ""
+"There are always distributions called <emphasis>stable</emphasis> (residing "
+"in <filename>dists/stable</filename>), <emphasis>testing</emphasis> "
+"(residing in <filename>dists/testing</filename>), and "
+"<emphasis>unstable</emphasis> (residing in "
+"<filename>dists/unstable</filename>). This reflects the development process "
+"of the Debian project."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: resources.dbk:643
+msgid ""
+"Active development is done in the <emphasis>unstable</emphasis> distribution "
+"(that's why this distribution is sometimes called the <emphasis>development "
+"distribution</emphasis>). Every Debian developer can update his or her "
+"packages in this distribution at any time. Thus, the contents of this "
+"distribution change from day to day. Since no special effort is made to "
+"make sure everything in this distribution is working properly, it is "
+"sometimes literally unstable."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: resources.dbk:652
+msgid ""
+"The <link linkend=\"testing\">testing</link> distribution 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. See <xref linkend=\"testing\"/> ."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: resources.dbk:659
+msgid ""
+"After a period of development, once the release manager deems fit, the "
+"<emphasis>testing</emphasis> distribution is frozen, meaning that the "
+"policies which control how packages move from <emphasis>unstable</emphasis> "
+"to <emphasis>testing</emphasis> are tightened. Packages which are too buggy "
+"are removed. No changes are allowed into <emphasis>testing</emphasis> "
+"except for bug fixes. After some time has elapsed, depending on progress, "
+"the <emphasis>testing</emphasis> distribution is frozen even further. "
+"Details of the handling of the testing distribution are published by the "
+"Release Team on debian-devel-announce. After the open issues are solved to "
+"the satisfaction of the Release Team, the distribution is released. "
+"Releasing means that <emphasis>testing</emphasis> is renamed to "
+"<emphasis>stable</emphasis>, and a new copy is created for the new "
+"<emphasis>testing</emphasis>, and the previous <emphasis>stable</emphasis> "
+"is renamed to <emphasis>oldstable</emphasis> and stays there until it is "
+"finally archived. On archiving, the contents are moved to "
+"<literal>&archive-host;</literal>)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: resources.dbk:676
+msgid ""
+"This development cycle is based on the assumption that the "
+"<emphasis>unstable</emphasis> distribution becomes "
+"<emphasis>stable</emphasis> after passing a period of being in "
+"<emphasis>testing</emphasis>. Even once a distribution is considered "
+"stable, a few bugs inevitably remain — that's why the stable distribution is "
+"updated every now and then. However, these updates are tested very "
+"carefully and have to be introduced into the archive individually to reduce "
+"the risk of introducing new bugs. You can find proposed additions to "
+"<emphasis>stable</emphasis> in the <filename>proposed-updates</filename> "
+"directory. Those packages in <filename>proposed-updates</filename> that "
+"pass muster are periodically moved as a batch into the stable distribution "
+"and the revision level of the stable distribution is incremented (e.g., "
+"‘3.0’ becomes ‘3.0r1’, ‘2.2r4’ becomes ‘2.2r5’, and so forth). Please refer "
+"to <link linkend=\"upload-stable\">uploads to the "
+"<emphasis>stable</emphasis> distribution</link> for details."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: resources.dbk:693
+msgid ""
+"Note that development under <emphasis>unstable</emphasis> continues during "
+"the freeze period, since the <emphasis>unstable</emphasis> distribution "
+"remains in place in parallel with <emphasis>testing</emphasis>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: resources.dbk:700
+msgid "More information about the testing distribution"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: resources.dbk:702
+msgid ""
+"Packages are usually installed into the `testing' distribution after they "
+"have undergone some degree of testing in unstable."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: resources.dbk:706
+msgid ""
+"For more details, please see the <link linkend=\"testing\">information about "
+"the testing distribution</link>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><title>
+#: resources.dbk:712
+msgid "Experimental"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: resources.dbk:714
+msgid ""
+"The <emphasis>experimental</emphasis> distribution is a special "
+"distribution. It is not a full distribution in the same sense as `stable' "
+"and `unstable' are. Instead, it is meant to be a temporary staging area for "
+"highly experimental software where there's a good chance that the software "
+"could break your system, or software that's just too unstable even for the "
+"<emphasis>unstable</emphasis> distribution (but there is a reason to package "
+"it nevertheless). Users who download and install packages from "
+"<emphasis>experimental</emphasis> are expected to have been duly warned. In "
+"short, all bets are off for the <emphasis>experimental</emphasis> "
+"distribution."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: resources.dbk:725
+msgid ""
+"These are the <citerefentry> <refentrytitle>sources.list</refentrytitle> "
+"<manvolnum>5</manvolnum> </citerefentry> lines for "
+"<emphasis>experimental</emphasis>:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><programlisting>
+#: resources.dbk:730
+#, no-wrap
+msgid ""
+"deb http://ftp.<replaceable>xy</replaceable>.debian.org/debian/ experimental "
+"main\n"
+"deb-src http://ftp.<replaceable>xy</replaceable>.debian.org/debian/ "
+"experimental main"
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: resources.dbk:734
+msgid ""
+"If there is a chance that the software could do grave damage to a system, it "
+"is likely to be better to put it into <emphasis>experimental</emphasis>. "
+"For instance, an experimental compressed file system should probably go into "
+"<emphasis>experimental</emphasis>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: resources.dbk:740
+msgid ""
+"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 <emphasis>experimental</emphasis>. A new, beta, version of "
+"some software which uses a completely different configuration can go into "
+"<emphasis>experimental</emphasis>, at the maintainer's discretion. If you "
+"are working on an incompatible or complex upgrade situation, you can also "
+"use <emphasis>experimental</emphasis> as a staging area, so that testers can "
+"get early access."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: resources.dbk:750
+msgid ""
+"Some experimental software can still go into <emphasis>unstable</emphasis>, "
+"with a few warnings in the description, but that isn't recommended because "
+"packages from <emphasis>unstable</emphasis> are expected to propagate to "
+"<emphasis>testing</emphasis> and thus to <emphasis>stable</emphasis>. You "
+"should not be afraid to use <emphasis>experimental</emphasis> since it does "
+"not cause any pain to the ftpmasters, the experimental packages are "
+"automatically removed once you upload the package in "
+"<emphasis>unstable</emphasis> with a higher version number."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: resources.dbk:760
+msgid ""
+"New software which isn't likely to damage your system can go directly into "
+"<emphasis>unstable</emphasis>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: resources.dbk:764
+msgid ""
+"An alternative to <emphasis>experimental</emphasis> is to use your personal "
+"web space on <literal>people.debian.org</literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><section><para>
+#: resources.dbk:768
+msgid ""
+"When uploading to unstable a package which had bugs fixed in experimental, "
+"please consider using the option <literal>-v</literal> to "
+"<command>dpkg-buildpackage</command> to finally get them closed."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:777
+msgid "Release code names"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:779
+msgid ""
+"Every released Debian distribution has a <emphasis>code name</emphasis>: "
+"Debian 1.1 is called `buzz'; Debian 1.2, `rex'; Debian 1.3, `bo'; Debian "
+"2.0, `hamm'; Debian 2.1, `slink'; Debian 2.2, `potato'; Debian 3.0, `woody'; "
+"Debian 3.1, sarge; Debian 4.0, etch. There is also a "
+"``pseudo-distribution'', called `sid', which is the current `unstable' "
+"distribution; since packages are moved from `unstable' to `testing' as they "
+"approach stability, `sid' itself is never released. As well as the usual "
+"contents of a Debian distribution, `sid' contains packages for architectures "
+"which are not yet officially supported or released by Debian. These "
+"architectures are planned to be integrated into the mainstream distribution "
+"at some future date."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:791
+msgid ""
+"Since Debian has an open development model (i.e., everyone can participate "
+"and follow the development) even the `unstable' and `testing' distributions "
+"are distributed to the Internet through the Debian FTP and HTTP server "
+"network. Thus, if we had called the directory which contains the release "
+"candidate version `testing', then we would have to rename it to `stable' "
+"when the version is released, which would cause all FTP mirrors to "
+"re-retrieve the whole distribution (which is quite large)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:800
+msgid ""
+"On the other hand, if we called the distribution directories "
+"<emphasis>Debian-x.y</emphasis> from the beginning, people would think that "
+"Debian release <emphasis>x.y</emphasis> is available. (This happened in the "
+"past, where a CD-ROM vendor built a Debian 1.0 CD-ROM based on a pre-1.0 "
+"development version. That's the reason why the first official Debian "
+"release was 1.1, and not 1.0.)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:808
+msgid ""
+"Thus, the names of the distribution directories in the archive are "
+"determined by their code names and not their release status (e.g., "
+"`slink'). These names stay the same during the development period and after "
+"the release; symbolic links, which can be changed easily, indicate the "
+"currently released stable distribution. That's why the real distribution "
+"directories use the <emphasis>code names</emphasis>, while symbolic links "
+"for <emphasis>stable</emphasis>, <emphasis>testing</emphasis>, and "
+"<emphasis>unstable</emphasis> point to the appropriate release directories."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: resources.dbk:822
+msgid "Debian mirrors"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:824
+msgid ""
+"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 — 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. Note that the first tier of "
+"mirrors is as up-to-date as it can be since they update when triggered from "
+"the internal sites (we call this push mirroring)."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:835
+msgid ""
+"All the information on Debian mirrors, including a list of the available "
+"public FTP/HTTP servers, can be found at <ulink "
+"url=\"&url-debian-mirrors;\"></ulink>. This useful page also includes "
+"information and tools which can be helpful if you are interested in setting "
+"up your own mirror, either for internal or public access."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:842
+msgid ""
+"Note that mirrors are generally run by third-parties who are interested in "
+"helping Debian. As such, developers generally do not have accounts on these "
+"machines."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: resources.dbk:849
+msgid "The Incoming system"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:851
+msgid ""
+"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 on <literal>&ftp-master-host;</literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:856
+msgid ""
+"Packages are uploaded by all the maintainers into a directory called "
+"<filename>UploadQueue</filename>. This directory is scanned every few "
+"minutes by a daemon called <command>queued</command>, "
+"<filename>*.command</filename>-files are executed, and remaining and "
+"correctly signed <filename>*.changes</filename>-files are moved together "
+"with their corresponding files to the <filename>unchecked</filename> "
+"directory. This directory is not visible for most Developers, as ftp-master "
+"is restricted; it is scanned every 15 minutes by the "
+"<command>katie</command> 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 "
+"<filename>accepted</filename> directory. If this is the first upload of the "
+"package (or it has new binary packages), it is moved to the "
+"<filename>new</filename> directory, where it waits for approval by the "
+"ftpmasters. If the package contains files to be installed by hand it is "
+"moved to the <filename>byhand</filename> directory, where it waits for "
+"manual installation by the ftpmasters. Otherwise, if any error has been "
+"detected, the package is refused and is moved to the "
+"<filename>reject</filename> directory."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:875
+msgid ""
+"Once the package is accepted, the system sends a confirmation mail to the "
+"maintainer and closes all the bugs marked as fixed by the upload, and the "
+"auto-builders may start recompiling it. The package is now publicly "
+"accessible at <ulink url=\"&url-incoming;\"></ulink> until it is really "
+"installed in the Debian archive. This happens only once a day (and is also "
+"called the `dinstall run' for historical reasons); the package is then "
+"removed from incoming and installed in the pool along with all the other "
+"packages. Once all the other updates (generating new "
+"<filename>Packages</filename> and <filename>Sources</filename> index files "
+"for example) have been made, a special script is called to ask all the "
+"primary mirrors to update themselves."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:887
+msgid ""
+"The archive maintenance software will also send the OpenPGP/GnuPG signed "
+"<filename>.changes</filename> file that you uploaded to the appropriate "
+"mailing lists. If a package is released with the "
+"<literal>Distribution:</literal> set to `stable', the announcement is sent "
+"to &email-debian-changes;. If a package is released with "
+"<literal>Distribution:</literal> set to `unstable' or `experimental', the "
+"announcement will be posted to &email-debian-devel-changes; instead."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:897
+msgid ""
+"Though ftp-master is restricted, a copy of the installation is available to "
+"all developers on <literal>&ftp-master-mirror;</literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: resources.dbk:960
+msgid "Package information"
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:962
+msgid "On the web"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:964
+msgid ""
+"Each package has several dedicated web pages. "
+"<literal>http://&packages-host;/<replaceable>package-name</replaceable></literal> "
+"displays each version of the package available in the various "
+"distributions. Each version links to a page which provides information, "
+"including the package description, the dependencies, and package download "
+"links."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:971
+msgid ""
+"The bug tracking system tracks bugs for each package. You can view the bugs "
+"of a given package at the URL "
+"<literal>http://&bugs-host;/<replaceable>package-name</replaceable></literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:978
+msgid "The <command>madison</command> utility"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:980
+msgid ""
+"<command>madison</command> is a command-line utility that is available on "
+"<literal>&ftp-master-host;</literal>, and on the mirror on "
+"<literal>&ftp-master-mirror;</literal>. It uses a single argument "
+"corresponding to a package name. In result it displays which version of the "
+"package is available for each architecture and distribution combination. An "
+"example will explain it better."
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: resources.dbk:988
+#, no-wrap
+msgid ""
+"$ madison libdbd-mysql-perl\n"
+"libdbd-mysql-perl | 1.2202-4 | stable | source, alpha, arm, i386, "
+"m68k, powerpc, sparc\n"
+"libdbd-mysql-perl | 1.2216-2 | testing | source, arm, hppa, i386, "
+"ia64, m68k, mips, mipsel, powerpc, s390, sparc\n"
+"libdbd-mysql-perl | 1.2216-2.0.1 | testing | alpha\n"
+"libdbd-mysql-perl | 1.2219-1 | unstable | source, alpha, arm, hppa, "
+"i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:995
+msgid ""
+"In this example, you can see that the version in "
+"<emphasis>unstable</emphasis> differs from the version in "
+"<emphasis>testing</emphasis> and that there has been a binary-only NMU of "
+"the package for the alpha architecture. Each version of the package has "
+"been recompiled on most of the architectures."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: resources.dbk:1005
+msgid "The Package Tracking System"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:1007
+msgid ""
+"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."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:1012
+msgid ""
+"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."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:1016
+msgid "By default you will get:"
+msgstr ""
+
+# type: Content of: <chapter><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1023
+msgid "All the bug reports and following discussions."
+msgstr ""
+
+# type: Content of: <chapter><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1031
+msgid ""
+"The email notifications from <email>control@&bugs-host;</email> about bug "
+"report status changes."
+msgstr ""
+
+# type: Content of: <chapter><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1040
+msgid ""
+"The email notification from <command>katie</command> when an uploaded source "
+"package is accepted."
+msgstr ""
+
+# type: Content of: <chapter><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1049
+msgid ""
+"Other warning and error emails from <command>katie</command> (such as an "
+"override disparity for the section and/or the priority field)."
+msgstr ""
+
+# type: Content of: <chapter><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1058
+msgid ""
+"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 "
+"<literal><replaceable>sourcepackage</replaceable>@&pts-host;</literal>. In "
+"order to prevent spam, all messages sent to these addresses must contain the "
+"<literal>X-PTS-Approved</literal> header with a non-empty value."
+msgstr ""
+
+# type: Content of: <chapter><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1070
+msgid ""
+"Regular summary emails about the package's status. Currently, only "
+"progression in <emphasis>testing</emphasis> is sent."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:1077
+msgid "You can also decide to receive additional information:"
+msgstr ""
+
+# type: Content of: <chapter><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1084
+msgid ""
+"The email notification from <command>katie</command> 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."
+msgstr ""
+
+# type: Content of: <chapter><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1095
+msgid ""
+"CVS commit notifications, if the package has a CVS repository and the "
+"maintainer has set up forwarding commit notifications to the PTS."
+msgstr ""
+
+# type: Content of: <chapter><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1104
+msgid ""
+"Translations of descriptions or debconf templates submitted to the Debian "
+"Description Translation Project."
+msgstr ""
+
+# type: Content of: <chapter><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1113
+msgid ""
+"Information about changes made to the package in derivative distributions "
+"(for example Ubuntu)."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:1120
+msgid "The PTS email interface"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:1122
+msgid ""
+"You can control your subscription(s) to the PTS by sending various commands "
+"to <email>pts@qa.debian.org</email>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1130
+msgid ""
+"Subscribes <replaceable>email</replaceable> to communications related to the "
+"source package <replaceable>sourcepackage</replaceable>. Sender address is "
+"used if the second argument is not present. If "
+"<replaceable>sourcepackage</replaceable> 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."
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1143
+msgid ""
+"Removes a previous subscription to the source package "
+"<replaceable>sourcepackage</replaceable> using the specified email address "
+"or the sender address if the second argument is left out."
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1153
+msgid ""
+"Removes all subscriptions of the specified email address or the sender "
+"address if the second argument is left out."
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1162
+msgid ""
+"Lists all subscriptions for the sender or the email address optionally "
+"specified."
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1171
+msgid ""
+"Tells you the keywords that you are accepting. For an explanation of "
+"keywords, <link linkend=\"pkg-tracking-system\">see above</link>. Here's a "
+"quick summary:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><itemizedlist><listitem><para>
+#: resources.dbk:1178
+msgid "<literal>bts</literal>: mails coming from the Debian Bug Tracking System"
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><itemizedlist><listitem><para>
+#: resources.dbk:1183
+msgid "<literal>bts-control</literal>: reply to mails sent to &email-bts-control;"
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><itemizedlist><listitem><para>
+#: resources.dbk:1189
+msgid ""
+"<literal>summary</literal>: automatic summary mails about the state of a "
+"package"
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><itemizedlist><listitem><para>
+#: resources.dbk:1195
+msgid "<literal>cvs</literal>: notification of CVS commits"
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><itemizedlist><listitem><para>
+#: resources.dbk:1200
+msgid "<literal>ddtp</literal>: translations of descriptions and debconf templates"
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><itemizedlist><listitem><para>
+#: resources.dbk:1205
+msgid ""
+"<literal>derivatives</literal>: changes made on the package by derivative "
+"distributions"
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><itemizedlist><listitem><para>
+#: resources.dbk:1211
+msgid ""
+"<literal>upload-source</literal>: announce of a new source upload that has "
+"been accepted"
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><itemizedlist><listitem><para>
+#: resources.dbk:1217
+msgid ""
+"<literal>upload-binary</literal>: announce of a new binary-only upload "
+"(porting)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><itemizedlist><listitem><para>
+#: resources.dbk:1223
+msgid ""
+"<literal>katie-other</literal>: other mails from ftpmasters (override "
+"disparity, etc.)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><itemizedlist><listitem><para>
+#: resources.dbk:1229
+msgid ""
+"<literal>default</literal>: all the other mails (those which aren't "
+"automatic)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1239
+msgid ""
+"Same as the previous item but for the given source package, since you may "
+"select a different set of keywords for each source package."
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1248
+msgid ""
+"Accept (+) or refuse (-) mails classified under the given keyword(s). "
+"Define the list (=) of accepted keywords. This changes the default set of "
+"keywords accepted by a user."
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1258
+msgid ""
+"Accept (+) or refuse (-) mails classified under the given keyword(s). "
+"Define the list (=) of accepted keywords. This changes the set of accepted "
+"keywords of all the currently active subscriptions of a user."
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1268
+msgid ""
+"Same as previous item but overrides the keywords list for the indicated "
+"source package."
+msgstr ""
+
+# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><para>
+#: resources.dbk:1277
+msgid "Stops processing commands. All following lines are ignored by the bot."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:1283
+msgid ""
+"The <command>pts-subscribe</command> command-line utility (from the "
+"<systemitem role=\"package\">devscripts</systemitem> package) can be handy "
+"to temporarily subscribe to some packages, for example after having made an "
+"non-maintainer upload."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:1291
+msgid "Filtering PTS mails"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:1293
+msgid ""
+"Once you are subscribed to a package, you will get the mails sent to "
+"<literal><replaceable>sourcepackage</replaceable>@&pts-host;</literal>. "
+"Those mails have special headers appended to let you filter them in a "
+"special mailbox (e.g. with <command>procmail</command>). The added headers "
+"are <literal>X-Loop</literal>, <literal>X-PTS-Package</literal>, "
+"<literal>X-PTS-Keyword</literal> and <literal>X-Unsubscribe</literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:1301
+msgid ""
+"Here is an example of added headers for a source upload notification on the "
+"<systemitem role=\"package\">dpkg</systemitem> package:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: resources.dbk:1305
+#, no-wrap
+msgid ""
+"X-Loop: dpkg@&pts-host;\n"
+"X-PTS-Package: dpkg\n"
+"X-PTS-Keyword: upload-source\n"
+"X-Unsubscribe: echo 'unsubscribe dpkg' | mail pts@qa.debian.org"
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:1313
+msgid "Forwarding CVS commits in the PTS"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:1315
+msgid ""
+"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 (and possible co-maintainers) can closely follow the "
+"package's evolution."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:1321
+msgid ""
+"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 "
+"<literal><replaceable>sourcepackage</replaceable>_cvs@&pts-host;</literal>. "
+"Only the people who accept the <emphasis>cvs</emphasis> keyword will receive "
+"these notifications."
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:1330
+msgid "The PTS web interface"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:1332
+msgid ""
+"The PTS has a web interface at <ulink url=\"http://&pts-host;/\"></ulink> "
+"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 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 allows easy subscription to the "
+"PTS via email."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:1342
+msgid ""
+"You can jump directly to the web page concerning a specific source package "
+"with a URL like "
+"<literal>http://&pts-host;/<replaceable>sourcepackage</replaceable></literal>."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:1347
+msgid ""
+"This web interface has been designed like a portal for the development of "
+"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."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:1353
+msgid "Static news items can be used to indicate:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: resources.dbk:1358
+msgid ""
+"the availability of a project hosted on <link "
+"linkend=\"alioth\">Alioth</link> for co-maintaining the package"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: resources.dbk:1364
+msgid "a link to the upstream web site"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: resources.dbk:1369
+msgid "a link to the upstream bug tracker"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: resources.dbk:1374
+msgid "the existence of an IRC channel dedicated to the software"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: resources.dbk:1379
+msgid ""
+"any other available resource that could be useful in the maintenance of the "
+"package"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:1385
+msgid "Usual news items may be used to announce that:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: resources.dbk:1390
+msgid "beta packages are available for testing"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: resources.dbk:1395
+msgid "final packages are expected for next week"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: resources.dbk:1400
+msgid "the packaging is about to be redone from scratch"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: resources.dbk:1405
+msgid "backports are available"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: resources.dbk:1410
+msgid "the maintainer is on vacation (if they wish to publish this information)"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: resources.dbk:1415
+msgid "a NMU is being worked on"
+msgstr ""
+
+# type: Content of: <chapter><section><section><itemizedlist><listitem><para>
+#: resources.dbk:1420
+msgid "something important will affect the package"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:1425
+msgid ""
+"Both kinds of news are generated in a similar manner: you just have to send "
+"an email either to <email>pts-static-news@qa.debian.org</email> or to "
+"<email>pts-news@qa.debian.org</email>. The mail should indicate which "
+"package is concerned by having the name of the source package in a "
+"<literal>X-PTS-Package</literal> mail header or in a "
+"<literal>Package</literal> pseudo-header (like the BTS reports). If a URL "
+"is available in the <literal>X-PTS-Url</literal> mail header or in the "
+"<literal>Url</literal> pseudo-header, then the result is a link to that URL "
+"instead of a complete news item."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:1436
+msgid ""
+"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:"
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: resources.dbk:1441
+#, no-wrap
+msgid ""
+"From: Raphael Hertzog <hertzog@debian.org>\n"
+"To: pts-static-news@qa.debian.org\n"
+"Subject: Browse debian-cd CVS repository with cvsweb\n"
+"\n"
+"Package: debian-cd\n"
+"Url: &url-cvsweb;debian-cd/"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:1449
+msgid ""
+"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."
+msgstr ""
+
+# type: Content of: <chapter><section><section><screen>
+#: resources.dbk:1454
+#, no-wrap
+msgid ""
+": Raphael Hertzog <hertzog@debian.org>\n"
+"To: debian-gtk-gnome@&lists-host;\n"
+"Bcc: pts-news@qa.debian.org\n"
+"Subject: Galeon 2.0 backported for woody\n"
+"X-PTS-Package: galeon\n"
+"\n"
+"Hello gnomers!\n"
+"\n"
+"I'm glad to announce that galeon has been backported for woody. You'll "
+"find\n"
+"everything here:\n"
+"..."
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:1467
+msgid ""
+"Think twice before adding a news item to the PTS because you won't be able "
+"to remove it later and you won'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."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: resources.dbk:1477
+msgid "Developer's packages overview"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:1479
+msgid ""
+"A QA (quality assurance) web portal is available at <ulink "
+"url=\"&url-ddpo;\"></ulink> which displays a table listing all the packages "
+"of a single developer (including those where the party is listed as a "
+"co-maintainer). The table gives a good summary about the developer's "
+"packages: number of bugs by severity, list of available versions in each "
+"distribution, testing status and much more including links to any other "
+"useful information."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:1488
+msgid ""
+"It is a good idea to look up your own data regularly so that you don't "
+"forget any open bugs, and so that you don't forget which packages are your "
+"responsibility."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: resources.dbk:1495
+msgid "Debian *Forge: Alioth"
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:1497
+msgid ""
+"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."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:1504
+msgid ""
+"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."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:1510
+msgid ""
+"All Debian developers automatically have an account on Alioth. They can "
+"activate it by using the recover password facility. External developers can "
+"request guest accounts on Alioth."
+msgstr ""
+
+# type: Content of: <chapter><section><para>
+#: resources.dbk:1515
+msgid "For more information please visit <ulink url=\"&url-alioth;\"></ulink>."
+msgstr ""
+
+# type: Content of: <chapter><section><title>
+#: resources.dbk:1521
+msgid "Goodies for Developers"
+msgstr ""
+
+# type: Content of: <chapter><section><section><title>
+#: resources.dbk:1523
+msgid "LWN Subscriptions"
+msgstr ""
+
+# type: Content of: <chapter><section><section><para>
+#: resources.dbk:1525
+msgid ""
+"Since October of 2002, HP has sponsored a subscription to LWN for all "
+"interested Debian developers. Details on how to get access to this benefit "
+"are in <ulink "
+"url=\"http://&lists-host;/debian-devel-announce/2002/10/msg00018.html\"></ulink>."
+msgstr ""
--- /dev/null
+# SOME DESCRIPTIVE TITLE
+# Copyright (C) YEAR Free Software Foundation, Inc.
+# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
+#
+#, fuzzy
+msgid ""
+msgstr ""
+"Project-Id-Version: PACKAGE VERSION\n"
+"POT-Creation-Date: 2007-07-01 21:01+0000\n"
+"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
+"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
+"Language-Team: LANGUAGE <LL@li.org>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=utf-8\n"
+"Content-Transfer-Encoding: ENCODING"
+
+# type: Content of: <chapter><title>
+#: scope.dbk:7
+msgid "Scope of This Document"
+msgstr ""
+
+# type: Content of: <chapter><para>
+#: scope.dbk:9
+msgid ""
+"The purpose of this document is to provide an overview of the recommended "
+"procedures and the available resources for Debian developers."
+msgstr ""
+
+# type: Content of: <chapter><para>
+#: scope.dbk:14
+msgid ""
+"The procedures discussed within include how to become a maintainer (<xref "
+"linkend=\"new-maintainer\"/> ); how to create new packages (<xref "
+"linkend=\"newpackage\"/> ) and how to upload packages (<xref "
+"linkend=\"upload\"/> ); how to handle bug reports (<xref "
+"linkend=\"bug-handling\"/> ); how to move, remove, or orphan packages (<xref "
+"linkend=\"archive-manip\"/> ); how to port packages (<xref "
+"linkend=\"porting\"/> ); and how and when to do interim releases of other "
+"maintainers' packages (<xref linkend=\"nmu\"/> )."
+msgstr ""
+
+# type: Content of: <chapter><para>
+#: scope.dbk:23
+msgid ""
+"The resources discussed in this reference include the mailing lists (<xref "
+"linkend=\"mailing-lists\"/> ) and servers (<xref "
+"linkend=\"server-machines\"/> ); a discussion of the structure of the Debian "
+"archive (<xref linkend=\"archive\"/> ); explanation of the different servers "
+"which accept package uploads (<xref linkend=\"upload-ftp-master\"/> ); and a "
+"discussion of resources which can help maintainers with the quality of their "
+"packages (<xref linkend=\"tools\"/> )."
+msgstr ""
+
+# type: Content of: <chapter><para>
+#: scope.dbk:31
+msgid ""
+"It should be clear that this reference does not discuss the technical "
+"details of Debian packages nor how to generate them. Nor does this "
+"reference detail the standards to which Debian software must comply. All of "
+"such information can be found in the <ulink "
+"url=\"&url-debian-policy;\">Debian Policy Manual</ulink>."
+msgstr ""
+
+# type: Content of: <chapter><para>
+#: scope.dbk:38
+msgid ""
+"Furthermore, this document is <emphasis>not an expression of formal "
+"policy</emphasis>. It contains documentation for the Debian system and "
+"generally agreed-upon best practices. Thus, it is not what is called a "
+"``normative'' document."
+msgstr ""
--- /dev/null
+# SOME DESCRIPTIVE TITLE
+# Copyright (C) YEAR Free Software Foundation, Inc.
+# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
+#
+#, fuzzy
+msgid ""
+msgstr ""
+"Project-Id-Version: PACKAGE VERSION\n"
+"POT-Creation-Date: 2007-07-01 21:01+0000\n"
+"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
+"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
+"Language-Team: LANGUAGE <LL@li.org>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=utf-8\n"
+"Content-Transfer-Encoding: ENCODING"
+
+# type: Content of: <appendix><title>
+#: tools.dbk:7
+msgid "Overview of Debian Maintainer Tools"
+msgstr ""
+
+# type: Content of: <appendix><para>
+#: tools.dbk:9
+msgid ""
+"This section contains a rough overview of the tools available to "
+"maintainers. The following is by no means complete or definitive, but just "
+"a guide to some of the more popular tools."
+msgstr ""
+
+# type: Content of: <appendix><para>
+#: tools.dbk:14
+msgid ""
+"Debian maintainer tools are meant to aid developers and free their time for "
+"critical tasks. As Larry Wall says, there's more than one way to do it."
+msgstr ""
+
+# type: Content of: <appendix><para>
+#: tools.dbk:18
+msgid ""
+"Some people prefer to use high-level package maintenance tools and some do "
+"not. Debian is officially agnostic on this issue; any tool which gets the "
+"job done is fine. Therefore, this section is not meant to stipulate to "
+"anyone which tools they should use or how they should go about their duties "
+"of maintainership. Nor is it meant to endorse any particular tool to the "
+"exclusion of a competing tool."
+msgstr ""
+
+# type: Content of: <appendix><para>
+#: tools.dbk:26
+msgid ""
+"Most of the descriptions of these packages come from the actual package "
+"descriptions themselves. Further information can be found in the package "
+"documentation itself. You can also see more info with the command "
+"<command>apt-cache show <package-name></command>."
+msgstr ""
+
+# type: Content of: <appendix><section><title>
+#: tools.dbk:32
+msgid "Core tools"
+msgstr ""
+
+# type: Content of: <appendix><section><para>
+#: tools.dbk:34
+msgid "The following tools are pretty much required for any maintainer."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:39
+msgid ""
+"<systemitem role=\"package\">dpkg-dev</systemitem> contains the tools "
+"(including <command>dpkg-source</command>) required to unpack, build, and "
+"upload Debian source packages. These utilities contain the fundamental, "
+"low-level functionality required to create and manipulate packages; as such, "
+"they are essential for any Debian maintainer."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:50
+msgid ""
+"<systemitem role=\"package\">debconf</systemitem> provides a consistent "
+"interface to configuring packages interactively. It is user interface "
+"independent, allowing end-users to configure packages with a text-only "
+"interface, an HTML interface, or a dialog interface. New interfaces can be "
+"added as modules."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:56
+msgid ""
+"You can find documentation for this package in the <systemitem "
+"role=\"package\">debconf-doc</systemitem> package."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:60
+msgid ""
+"Many feel that this system should be used for all packages which require "
+"interactive configuration; see <xref linkend=\"bpp-config-mgmt\"/> . "
+"<systemitem role=\"package\">debconf</systemitem> is not currently required "
+"by Debian Policy, but that may change in the future."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:70
+msgid ""
+"<systemitem role=\"package\">fakeroot</systemitem> simulates root "
+"privileges. This enables you to build packages without being root (packages "
+"usually want to install files with root ownership). If you have <systemitem "
+"role=\"package\">fakeroot</systemitem> installed, you can build packages as "
+"a regular user: <literal>dpkg-buildpackage -rfakeroot</literal>."
+msgstr ""
+
+# type: Content of: <appendix><section><title>
+#: tools.dbk:81
+msgid "Package lint tools"
+msgstr ""
+
+# type: Content of: <appendix><section><para>
+#: tools.dbk:83
+msgid ""
+"According to the Free On-line Dictionary of Computing (FOLDOC), `lint' is a "
+"Unix C language processor which carries out more thorough checks on the code "
+"than is usual with C compilers. Package lint tools help package maintainers "
+"by automatically finding common problems and policy violations in their "
+"packages."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:91
+msgid ""
+"<systemitem role=\"package\">lintian</systemitem> dissects Debian packages "
+"and emits information about bugs and policy violations. It contains "
+"automated checks for many aspects of Debian policy as well as some checks "
+"for common errors."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:97
+msgid ""
+"You should periodically get the newest <systemitem "
+"role=\"package\">lintian</systemitem> from `unstable' and check over all "
+"your packages. Notice that the <literal>-i</literal> option provides "
+"detailed explanations of what each error or warning means, what its basis in "
+"Policy is, and commonly how you can fix the problem."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:104
+msgid ""
+"Refer to <xref linkend=\"sanitycheck\"/> for more information on how and "
+"when to use Lintian."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:108
+msgid ""
+"You can also see a summary of all problems reported by Lintian on your "
+"packages at <ulink url=\"&url-lintian;\"></ulink>. These reports contain "
+"the latest <command>lintian</command> output for the whole development "
+"distribution (unstable)."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:118
+msgid ""
+"<systemitem role=\"package\">linda</systemitem> is another package linter. "
+"It is similar to <systemitem role=\"package\">lintian</systemitem> but has a "
+"different set of checks. Its written in Python rather than Perl."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:127
+msgid ""
+"<command>debdiff</command> (from the <systemitem "
+"role=\"package\">devscripts</systemitem> package, <xref "
+"linkend=\"devscripts\"/> ) compares file lists and control files of two "
+"packages. It is a simple regression test, as it will help you notice if the "
+"number of binary packages has changed since the last upload, or if something "
+"has changed in the control file. Of course, some of the changes it reports "
+"will be all right, but it can help you prevent various accidents."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:136
+msgid "You can run it over a pair of binary packages:"
+msgstr ""
+
+# type: Content of: <appendix><section><section><screen>
+#: tools.dbk:139
+#, no-wrap
+msgid "debdiff package_1-1_arch.deb package_2-1_arch.deb"
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:142
+msgid "Or even a pair of changes files:"
+msgstr ""
+
+# type: Content of: <appendix><section><section><screen>
+#: tools.dbk:145
+#, no-wrap
+msgid "debdiff package_1-1_arch.changes package_2-1_arch.changes"
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:148
+msgid ""
+"For more information please see <citerefentry> "
+"<refentrytitle>debdiff</refentrytitle> <manvolnum>1</manvolnum> "
+"</citerefentry>."
+msgstr ""
+
+# type: Content of: <appendix><section><title>
+#: tools.dbk:157
+msgid "Helpers for <filename>debian/rules</filename>"
+msgstr ""
+
+# type: Content of: <appendix><section><para>
+#: tools.dbk:159
+msgid ""
+"Package building tools make the process of writing "
+"<filename>debian/rules</filename> files easier. See <xref "
+"linkend=\"helper-scripts\"/> for more information about why these might or "
+"might not be desired."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:167
+msgid ""
+"<systemitem role=\"package\">debhelper</systemitem> is a collection of "
+"programs which can be used in <filename>debian/rules</filename> to automate "
+"common tasks related to building binary Debian packages. <systemitem "
+"role=\"package\">debhelper</systemitem> includes programs to install various "
+"files into your package, compress files, fix file permissions, and integrate "
+"your package with the Debian menu system."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:175
+msgid ""
+"Unlike some approaches, <systemitem role=\"package\">debhelper</systemitem> "
+"is broken into several small, simple commands which act in a consistent "
+"manner. As such, it allows more fine-grained control than some of the other "
+"debian/rules tools."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:181
+msgid ""
+"There are a number of little <systemitem "
+"role=\"package\">debhelper</systemitem> add-on packages, too transient to "
+"document. You can see the list of most of them by doing <literal>apt-cache "
+"search ^dh-</literal>."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:190
+msgid ""
+"<systemitem role=\"package\">debmake</systemitem>, a precursor to "
+"<systemitem role=\"package\">debhelper</systemitem>, is a more "
+"coarse-grained <filename>debian/rules</filename> assistant. It includes two "
+"main programs: <command>deb-make</command>, which can be used to help a "
+"maintainer convert a regular (non-Debian) source archive into a Debian "
+"source package; and <command>debstd</command>, which incorporates in one big "
+"shot the same sort of automated functions that one finds in <systemitem "
+"role=\"package\">debhelper</systemitem>."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:200
+msgid ""
+"The consensus is that <systemitem role=\"package\">debmake</systemitem> is "
+"now deprecated in favor of <systemitem "
+"role=\"package\">debhelper</systemitem>. It is a bug to use <systemitem "
+"role=\"package\">debmake</systemitem> in new packages. New packages using "
+"<systemitem role=\"package\">debmake</systemitem> will be rejected from the "
+"archive."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:211
+msgid ""
+"The <systemitem role=\"package\">dh-make</systemitem> package contains "
+"<command>dh_make</command>, a program that creates a skeleton of files "
+"necessary to build a Debian package out of a source tree. As the name "
+"suggests, <command>dh_make</command> is a rewrite of <systemitem "
+"role=\"package\">debmake</systemitem> and its template files use dh_* "
+"programs from <systemitem role=\"package\">debhelper</systemitem>."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:219
+msgid ""
+"While the rules files generated by <command>dh_make</command> are in general "
+"a sufficient basis for a working package, they are still just the "
+"groundwork: the burden still lies on the maintainer to finely tune the "
+"generated files and make the package entirely functional and "
+"Policy-compliant."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:229
+msgid ""
+"<systemitem role=\"package\">yada</systemitem> is another packaging helper "
+"tool. It uses a <filename>debian/packages</filename> file to auto-generate "
+"<filename>debian/rules</filename> and other necessary files in the "
+"<filename>debian/</filename> subdirectory. The "
+"<filename>debian/packages</filename> file contains instruction to build "
+"packages and there is no need to create any <filename>Makefile</filename> "
+"files. There is possibility to use macro engine similar to the one used in "
+"SPECS files from RPM source packages."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:239
+msgid ""
+"For more informations see <literal><ulink "
+"url=\"http://yada.alioth.debian.org/\">YADA site</ulink></literal>."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:247
+msgid ""
+"<systemitem role=\"package\">equivs</systemitem> is another package for "
+"making packages. It is often suggested for local use if you need to make a "
+"package simply to fulfill dependencies. It is also sometimes used when "
+"making ``meta-packages'', which are packages whose only purpose is to depend "
+"on other packages."
+msgstr ""
+
+# type: Content of: <appendix><section><title>
+#: tools.dbk:258
+msgid "Package builders"
+msgstr ""
+
+# type: Content of: <appendix><section><para>
+#: tools.dbk:260
+msgid ""
+"The following packages help with the package building process, general "
+"driving <command>dpkg-buildpackage</command> as well as handling supporting "
+"tasks."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:266
+msgid ""
+"<systemitem role=\"package\">cvs-buildpackage</systemitem> provides the "
+"capability to inject or import Debian source packages into a CVS repository, "
+"build a Debian package from the CVS repository, and helps in integrating "
+"upstream changes into the repository."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:272
+msgid ""
+"These utilities provide an infrastructure to facilitate the use of CVS by "
+"Debian maintainers. This allows one to keep separate CVS branches of a "
+"package for <emphasis>stable</emphasis>, <emphasis>unstable</emphasis> and "
+"possibly <emphasis>experimental</emphasis> distributions, along with the "
+"other benefits of a version control system."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:283
+msgid ""
+"The <systemitem role=\"package\">debootstrap</systemitem> package and script "
+"allows you to bootstrap a Debian base system into any part of your "
+"filesystem. By base system, we mean the bare minimum of packages required "
+"to operate and install the rest of the system."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:289
+msgid ""
+"Having a system like this can be useful in many ways. For instance, you can "
+"<command>chroot</command> into it if you want to test your build "
+"dependencies. Or you can test how your package behaves when installed into "
+"a bare base system. Chroot builders use this package; see below."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:299
+msgid ""
+"<systemitem role=\"package\">pbuilder</systemitem> constructs a chrooted "
+"system, and builds a package inside the chroot. It is very useful to check "
+"that a package's build-dependencies are correct, and to be sure that "
+"unnecessary and wrong build dependencies will not exist in the resulting "
+"package."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:305
+msgid ""
+"A related package is <systemitem role=\"package\">pbuilder-uml</systemitem>, "
+"which goes even further by doing the build within a User Mode Linux "
+"environment."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:314
+msgid ""
+"<systemitem role=\"package\">sbuild</systemitem> is another automated "
+"builder. It can use chrooted environments as well. It can be used "
+"stand-alone, or as part of a networked, distributed build environment. As "
+"the latter, it is part of the system used by porters to build binary "
+"packages for all the available architectures. See <xref "
+"linkend=\"buildd\"/> for more information, and <ulink "
+"url=\"&url-buildd;\"></ulink> to see the system in action."
+msgstr ""
+
+# type: Content of: <appendix><section><title>
+#: tools.dbk:326
+msgid "Package uploaders"
+msgstr ""
+
+# type: Content of: <appendix><section><para>
+#: tools.dbk:328
+msgid ""
+"The following packages help automate or simplify the process of uploading "
+"packages into the official archive."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:334
+msgid ""
+"<systemitem role=\"package\">dupload</systemitem> is a package and a script "
+"to automatically upload Debian packages to the Debian archive, to log the "
+"upload, and to send mail about the upload of a package. You can configure "
+"it for new upload locations or methods."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:344
+msgid ""
+"The <systemitem role=\"package\">dput</systemitem> package and script does "
+"much the same thing as <systemitem role=\"package\">dupload</systemitem>, "
+"but in a different way. It has some features over <systemitem "
+"role=\"package\">dupload</systemitem>, such as the ability to check the "
+"GnuPG signature and checksums before uploading, and the possibility of "
+"running <command>dinstall</command> in dry-run mode after the upload."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:356
+msgid ""
+"The <systemitem role=\"package\">dcut</systemitem> script (part of the "
+"package <xref linkend=\"dput\"/> ) helps in removing files from the ftp "
+"upload directory."
+msgstr ""
+
+# type: Content of: <appendix><section><title>
+#: tools.dbk:364
+msgid "Maintenance automation"
+msgstr ""
+
+# type: Content of: <appendix><section><para>
+#: tools.dbk:366
+msgid ""
+"The following tools help automate different maintenance tasks, from adding "
+"changelog entries or signature lines and looking up bugs in Emacs to making "
+"use of the newest and official <filename>config.sub</filename>."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:373
+msgid ""
+"<systemitem role=\"package\">devscripts</systemitem> is a package containing "
+"wrappers and tools which are very helpful for maintaining your Debian "
+"packages. Example scripts include <command>debchange</command> and "
+"<command>dch</command>, which manipulate your "
+"<filename>debian/changelog</filename> file from the command-line, and "
+"<command>debuild</command>, which is a wrapper around "
+"<command>dpkg-buildpackage</command>. The <command>bts</command> utility is "
+"also very helpful to update the state of bug reports on the command line. "
+"<command>uscan</command> can be used to watch for new upstream versions of "
+"your packages. <command>debrsign</command> can be used to remotely sign a "
+"package prior to upload, which is nice when the machine you build the "
+"package on is different from where your GPG keys are."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:387
+msgid ""
+"See the <citerefentry> <refentrytitle>devscripts</refentrytitle> "
+"<manvolnum>1</manvolnum> </citerefentry> manual page for a complete list of "
+"available scripts."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:396
+msgid ""
+"<systemitem role=\"package\">autotools-dev</systemitem> contains best "
+"practices for people who maintain packages which use "
+"<command>autoconf</command> and/or <command>automake</command>. Also "
+"contains canonical <filename>config.sub</filename> and "
+"<filename>config.guess</filename> files which are known to work on all "
+"Debian ports."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:407
+msgid ""
+"<command>dpkg-repack</command> creates Debian package file out of a package "
+"that has already been installed. If any changes have been made to the "
+"package while it was unpacked (e.g., files in <filename>/etc</filename> were "
+"modified), the new package will inherit the changes."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:413
+msgid ""
+"This utility can make it easy to copy packages from one computer to another, "
+"or to recreate packages which are installed on your system but no longer "
+"available elsewhere, or to save the current state of a package before you "
+"upgrade it."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:422
+msgid ""
+"<command>alien</command> converts binary packages between various packaging "
+"formats, including Debian, RPM (RedHat), LSB (Linux Standard Base), Solaris, "
+"and Slackware packages."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:431
+msgid ""
+"<command>debsums</command> checks installed packages against their MD5 "
+"sums. Note that not all packages have MD5 sums, since they aren't required "
+"by Policy."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:439
+msgid ""
+"<systemitem role=\"package\">dpkg-dev-el</systemitem> is an Emacs lisp "
+"package which provides assistance when editing some of the files in the "
+"<filename>debian</filename> directory of your package. For instance, there "
+"are handy functions for listing a package's current bugs, and for finalizing "
+"the latest entry in a <filename>debian/changelog</filename> file."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:450
+msgid ""
+"<command>dpkg-depcheck</command> (from the <systemitem "
+"role=\"package\">devscripts</systemitem> package, <xref "
+"linkend=\"devscripts\"/> ) runs a command under <command>strace</command> "
+"to determine all the packages that were used by the said command."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:456
+msgid ""
+"For Debian packages, this is useful when you have to compose a "
+"<literal>Build-Depends</literal> line for your new package: running the "
+"build process through <command>dpkg-depcheck</command> will provide you with "
+"a good first approximation of the build-dependencies. For example:"
+msgstr ""
+
+# type: Content of: <appendix><section><section><screen>
+#: tools.dbk:462
+#, no-wrap
+msgid "dpkg-depcheck -b debian/rules build"
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:465
+msgid ""
+"<command>dpkg-depcheck</command> can also be used to check for run-time "
+"dependencies, especially if your package uses exec(2) to run other programs."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:469
+msgid ""
+"For more information please see <citerefentry> "
+"<refentrytitle>dpkg-depcheck</refentrytitle> <manvolnum>1</manvolnum> "
+"</citerefentry>."
+msgstr ""
+
+# type: Content of: <appendix><section><title>
+#: tools.dbk:478
+msgid "Porting tools"
+msgstr ""
+
+# type: Content of: <appendix><section><para>
+#: tools.dbk:480
+msgid "The following tools are helpful for porters and for cross-compilation."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:485
+msgid ""
+"<systemitem role=\"package\">quinn-diff</systemitem> is used to locate the "
+"differences from one architecture to another. For instance, it could tell "
+"you which packages need to be ported for architecture "
+"<replaceable>Y</replaceable>, based on architecture "
+"<replaceable>X</replaceable>."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:495
+msgid ""
+"<systemitem role=\"package\">dpkg-cross</systemitem> is a tool for "
+"installing libraries and headers for cross-compiling in a way similar to "
+"<systemitem role=\"package\">dpkg</systemitem>. Furthermore, the "
+"functionality of <command>dpkg-buildpackage</command> and "
+"<command>dpkg-shlibdeps</command> is enhanced to support cross-compiling."
+msgstr ""
+
+# type: Content of: <appendix><section><title>
+#: tools.dbk:506
+msgid "Documentation and information"
+msgstr ""
+
+# type: Content of: <appendix><section><para>
+#: tools.dbk:508
+msgid ""
+"The following packages provide information for maintainers or help with "
+"building documentation."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:514
+msgid ""
+"<systemitem role=\"package\">debiandoc-sgml</systemitem> provides the "
+"DebianDoc SGML DTD, which is commonly used for Debian documentation. This "
+"manual, for instance, is written in DebianDoc. It also provides scripts for "
+"building and styling the source to various output formats."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:520
+msgid ""
+"Documentation for the DTD can be found in the <systemitem "
+"role=\"package\">debiandoc-sgml-doc</systemitem> package."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:544
+msgid ""
+"Contains the public GPG and PGP keys of Debian developers. See <xref "
+"linkend=\"key-maint\"/> and the package documentation for more information."
+msgstr ""
+
+# type: Content of: <appendix><section><section><para>
+#: tools.dbk:552
+msgid ""
+"<systemitem role=\"package\">debview</systemitem> provides an Emacs mode for "
+"viewing Debian binary packages. This lets you examine a package without "
+"unpacking it."
+msgstr ""
--- /dev/null
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
+ "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
+ <!ENTITY % commondata SYSTEM "common.ent" > %commondata;
+]>
+<chapter id="resources">
+<title>Resources for Debian Developers</title>
+<para>
+In this chapter you will find a very brief road map of the Debian mailing
+lists, the Debian machines which may be available to you as a developer, and
+all the other resources that are available to help you in your maintainer work.
+</para>
+<section id="mailing-lists">
+<title>Mailing lists</title>
+<para>
+Much of the conversation between Debian developers (and users) is managed
+through a wide array of mailing lists we host at <literal><ulink
+url="http://&lists-host;/">&lists-host;</ulink></literal>.
+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 <ulink url="&url-debian-lists;"></ulink>. This section
+will only cover aspects of mailing lists that are of particular interest to
+developers.
+</para>
+<section id="mailing-lists-rules">
+<title>Basic rules for use</title>
+<para>
+When replying to messages on the mailing list, please do not send a carbon copy
+(<literal>CC</literal>) 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.
+</para>
+<para>
+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.
+</para>
+<para>
+Please read the <ulink
+url="&url-debian-lists;#codeofconduct">code of conduct</ulink>
+for more information. The <ulink url="&url-dcg;">Debian Community
+Guidelines</ulink> are also worth reading.
+</para>
+</section>
+
+<section id="core-devel-mailing-lists">
+<title>Core development mailing lists</title>
+<para>
+The core Debian mailing lists that developers should use are:
+</para>
+<itemizedlist>
+<listitem>
+<para>
+&email-debian-devel-announce;, used to announce important
+things to developers. All developers are expected to be subscribed to this
+list.
+</para>
+</listitem>
+<listitem>
+<para>
+&email-debian-devel;, used to discuss various development
+related technical issues.
+</para>
+</listitem>
+<listitem>
+<para>
+&email-debian-policy;, where the Debian Policy is discussed
+and voted on.
+</para>
+</listitem>
+<listitem>
+<para>
+&email-debian-project;, used to discuss various non-technical
+issues related to the project.
+</para>
+</listitem>
+</itemizedlist>
+<para>
+There are other mailing lists available for a variety of special topics; see
+<ulink url="http://&lists-host;/"></ulink> for a list.
+</para>
+</section>
+
+<section id="mailing-lists-special">
+<title>Special lists</title>
+<para>
+&email-debian-private; is a special mailing list for private
+discussions amongst Debian developers. It is meant to be used for posts which
+for whatever reason should not be published publicly. As such, it is a low
+volume list, and users are urged not to use
+&email-debian-private; unless it is really necessary.
+Moreover, do <emphasis>not</emphasis> forward email from that list to anyone.
+Archives of this list are not available on the web for obvious reasons, but you
+can see them using your shell account on <literal>&lists-host;</literal>
+and looking in the <filename>&file-debian-private-archive;</filename>
+directory.
+</para>
+<para>
+&email-debian-email; is a special mailing list used as a
+grab-bag 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.
+</para>
+</section>
+
+<section id="mailing-lists-new">
+<title>Requesting new development-related lists</title>
+<para>
+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 <replaceable>you-aliasname@debian.org</replaceable> address) or
+a self-managed mailing list on <link linkend="alioth">Alioth</link> is
+more appropriate.
+</para>
+<para>
+If you decide that a regular mailing list on &lists-host; is really what
+you want, go ahead and fill in a request, following <ulink
+url="&url-debian-lists-new;">the HOWTO</ulink>.
+</para>
+</section>
+
+</section>
+
+<section id="irc-channels">
+<title>IRC channels</title>
+<para>
+Several IRC channels are dedicated to Debian's development. They are mainly
+hosted on the <ulink url="&url-oftc;">Open and free technology
+community (OFTC)</ulink> network. The <literal>irc.debian.org</literal> DNS
+entry is an alias to <literal>irc.oftc.net</literal>.
+</para>
+<para>
+The main channel for Debian in general is <emphasis>#debian</emphasis>. This
+is a large, general-purpose channel where users can find recent news in the
+topic and served by bots. <emphasis>#debian</emphasis> is for English
+speakers; there are also <emphasis>#debian.de</emphasis>,
+<emphasis>#debian-fr</emphasis>, <emphasis>#debian-br</emphasis> and other
+similarly named channels for speakers of other languages.
+</para>
+<para>
+The main channel for Debian development is <emphasis>#debian-devel</emphasis>.
+It is a very active channel since usually over 150 people are always logged in.
+It's a channel for people who work on Debian, it's not a support channel
+(there's <emphasis>#debian</emphasis> for that). It is however open to anyone
+who wants to lurk (and learn). Its topic is commonly full of interesting
+information for developers.
+</para>
+<para>
+Since <emphasis>#debian-devel</emphasis> is an open channel, you should not
+speak there of issues that are discussed in
+&email-debian-private;. There's another channel for this
+purpose, it's called <emphasis>#debian-private</emphasis> and it's protected by
+a key. This key is available in the archives of debian-private in
+<filename>master.debian.org:&file-debian-private-archive;</filename>,
+just <command>zgrep</command> for <emphasis>#debian-private</emphasis> in all
+the files.
+</para>
+<para>
+There are other additional channels dedicated to specific subjects.
+<emphasis>#debian-bugs</emphasis> is used for coordinating bug squashing
+parties. <emphasis>#debian-boot</emphasis> is used to coordinate the work on
+the debian-installer. <emphasis>#debian-doc</emphasis> is occasionally used to
+talk about documentation, like the document you are reading. Other channels
+are dedicated to an architecture or a set of packages:
+<emphasis>#debian-kde</emphasis>, <emphasis>#debian-dpkg</emphasis>,
+<emphasis>#debian-jr</emphasis>, <emphasis>#debian-edu</emphasis>,
+<emphasis>#debian-oo</emphasis> (OpenOffice package) ...
+</para>
+<para>
+Some non-English developers' channels exist as well, for example
+<emphasis>#debian-devel-fr</emphasis> for French speaking people interested in
+Debian's development.
+</para>
+<para>
+Channels dedicated to Debian also exist on other IRC networks, notably on the
+<ulink url="&url-openprojects;">freenode</ulink> IRC network,
+which was pointed at by the <literal>irc.debian.org</literal> alias until 4th
+June 2006.
+</para>
+<para>
+To get a cloak on freenode, you send Jörg Jaspert <joerg@debian.org> a
+signed mail where you tell what your nick is. Put cloak somewhere in the
+Subject: header. The nick should be registered: <ulink
+url="http://freenode.net/faq.shtml#nicksetup">Nick Setup Page</ulink>. The
+mail needs to be signed by a key in the Debian keyring. Please see <ulink
+url="http://freenode.net/faq.shtml#projectcloak">Freenodes
+documentation</ulink> for more information about cloaks.
+</para>
+</section>
+
+<section id="doc-rsrcs">
+<title>Documentation</title>
+<para>
+This document contains a lot of information which is useful to Debian
+developers, but it cannot contain everything. Most of the other interesting
+documents are linked from <ulink url="&url-devel-docs;">The
+Developers' Corner</ulink>. Take the time to browse all the links, you will
+learn many more things.
+</para>
+</section>
+
+<section id="server-machines">
+<title>Debian machines</title>
+<para>
+Debian has several computers working as servers, most of which serve critical
+functions in the Debian project. Most of the machines are used for porting
+activities, and they all have a permanent connection to the Internet.
+</para>
+<para>
+Some of the machines are available for individual developers to use, as long as
+the developers follow the rules set forth in the <ulink
+url="&url-dmup;">Debian Machine Usage Policies</ulink>.
+</para>
+<para>
+Generally speaking, you can use these machines for Debian-related purposes as
+you see fit. Please be kind to system administrators, and do not use up tons
+and tons of disk space, network bandwidth, or CPU without first getting the
+approval of the system administrators. Usually these machines are run by
+volunteers.
+</para>
+<para>
+Please take care to protect your Debian passwords and SSH keys installed on
+Debian machines. Avoid login or upload methods which send passwords over the
+Internet in the clear, such as telnet, FTP, POP etc.
+</para>
+<para>
+Please do not put any material that doesn't relate to Debian on the Debian
+servers, unless you have prior permission.
+</para>
+<para>
+The current list of Debian machines is available at <ulink
+url="&url-devel-machines;"></ulink>. That web page contains
+machine names, contact information, information about who can log in, SSH keys
+etc.
+</para>
+<para>
+If you have a problem with the operation of a Debian server, and you think that
+the system operators need to be notified of this problem, you can check
+the list of open issues in the DSA queue of our request tracker at <ulink
+url="&url-rt;" /> (you can login with user "guest" and password "readonly").
+To report a new problem, simply send a mail to &email-rt-dsa; and make
+sure to put the string "Debian RT" somewhere in the subject.
+</para>
+<para>
+If you have a problem with a certain service, not related to the system
+administration (such as packages to be removed from the archive, suggestions
+for the web site, etc.), generally you'll report a bug against a
+``pseudo-package''. See <xref linkend="submit-bug"/> for information on how to
+submit bugs.
+</para>
+<para>
+Some of the core servers are restricted, but the information from there is
+mirrored to another server.
+</para>
+<section id="servers-bugs">
+<title>The bugs server</title>
+<para>
+<literal>&bugs-host;</literal> is the canonical location for
+the Bug Tracking System (BTS).
+</para>
+<para>
+It is restricted; a mirror is available on <literal>merkel</literal>.
+</para>
+<para>
+If you plan on doing some statistical analysis or processing of Debian bugs,
+this would be the place to do it. Please describe your plans on
+&email-debian-devel; before implementing anything, however, to
+reduce unnecessary duplication of effort or wasted processing time.
+</para>
+</section>
+
+<section id="servers-ftp-master">
+<title>The ftp-master server</title>
+<para>
+The <literal>&ftp-master-host;</literal> server holds the canonical copy of
+the Debian archive. Generally, package uploads go to this server; see
+<xref linkend="upload"/>.
+</para>
+<para>
+It is restricted; a mirror is available on <literal>merkel</literal>.
+</para>
+<para>
+Problems with the Debian FTP archive generally need to be reported as bugs
+against the <systemitem role="package">&ftp-debian-org;</systemitem>
+pseudo-package or an email to &email-ftpmaster;, but also see
+the procedures in <xref linkend="archive-manip"/> .
+</para>
+</section>
+
+<section id="servers-www">
+<title>The www-master server</title>
+<para>
+The main web server is <literal>www-master.debian.org</literal>. It holds the
+official web pages, the face of Debian for most newbies.
+</para>
+<para>
+If you find a problem with the Debian web server, you should generally submit a
+bug against the pseudo-package, <systemitem
+role="package">www.debian.org</systemitem>. Remember to check whether or not
+someone else has already reported the problem to the <ulink
+url="http://&bugs-host;/&www-debian-org;">Bug Tracking System</ulink>.
+</para>
+</section>
+
+<section id="servers-people">
+<title>The people web server</title>
+<para>
+<literal>people.debian.org</literal> is the server used for developers' own web
+pages about anything related to Debian.
+</para>
+<para>
+If you have some Debian-specific information which you want to serve on the
+web, you can do this by putting material in the
+<filename>public_html</filename> directory under your home directory on
+<literal>people.debian.org</literal>. This will be accessible at the URL
+<literal>http://people.debian.org/~<replaceable>your-user-id</replaceable>/</literal>.
+</para>
+<para>
+You should only use this particular location because it will be backed up,
+whereas on other hosts it won't.
+</para>
+<para>
+Usually the only reason to use a different host is when you need to publish
+materials subject to the U.S. export restrictions, in which case you can use
+one of the other servers located outside the United States.
+</para>
+<para>
+Send mail to &email-debian-devel; if you have any questions.
+</para>
+</section>
+
+<section id="servers-vcs">
+<title>The VCS servers</title>
+<para>
+If you need to use a Version Control System for any of your Debian work,
+you can use one the existing repositories hosted on Alioth or you can
+request a new project and ask for the VCS repository of your choice.
+Alioth supports CVS (alioth.debian.org), Subversion
+(svn.debian.org), Arch (tla/baz, both on arch.debian.org), Bazaar
+(bzr.debian.org), Darcs (darcs.debian.org), Mercurial (hg.debian.org) and Git
+(git.debian.org). Checkout <ulink url="&url-alioth-pkg;" /> if you plan
+to maintain packages in a VCS repository. See <xref linkend="alioth"/> for
+information on the services provided by Alioth.
+</para>
+<para>
+Historically, Debian first used <literal>cvs.debian.org</literal> to host
+CVS repositories. But that service is deprecated in favor of Alioth.
+Only a few projects are still using it.
+</para>
+</section>
+
+<section id="dchroot">
+<title>chroots to different distributions</title>
+<para>
+On some machines, there are chroots to different distributions available. You
+can use them like this:
+</para>
+<screen>
+vore$ dchroot unstable
+Executing shell in chroot: /org/vore.debian.org/chroots/user/unstable
+</screen>
+<para>
+In all chroots, the normal user home directories are available. You can find
+out which chroots are available via
+<literal>&url-devel-machines;</literal>.
+</para>
+</section>
+
+</section>
+
+<section id="devel-db">
+<title>The Developers Database</title>
+<para>
+The Developers Database, at <ulink
+url="&url-debian-db;"></ulink>, is an LDAP directory for
+managing Debian developer attributes. You can use this resource to search the
+list of Debian developers. Part of this information is also available through
+the finger service on Debian servers, try <command>finger
+yourlogin@db.debian.org</command> to see what it reports.
+</para>
+<para>
+Developers can <ulink url="&url-debian-db-login;">log into the
+database</ulink> to change various information about themselves, such as:
+</para>
+<itemizedlist>
+<listitem>
+<para>
+forwarding address for your debian.org email
+</para>
+</listitem>
+<listitem>
+<para>
+subscription to debian-private
+</para>
+</listitem>
+<listitem>
+<para>
+whether you are on vacation
+</para>
+</listitem>
+<listitem>
+<para>
+personal information such as your address, country, the latitude and longitude
+of the place where you live for use in <ulink
+url="&url-worldmap;">the world map of Debian
+developers</ulink>, phone and fax numbers, IRC nickname and web page
+</para>
+</listitem>
+<listitem>
+<para>
+password and preferred shell on Debian Project machines
+</para>
+</listitem>
+</itemizedlist>
+<para>
+Most of the information is not accessible to the public, naturally. For more
+information please read the online documentation that you can find at <ulink
+url="&url-debian-db-doc;"></ulink>.
+</para>
+<para>
+Developers can also submit their SSH keys to be used for authorization on the
+official Debian machines, and even add new *.debian.net DNS entries. Those
+features are documented at <ulink
+url="&url-debian-db-mail-gw;"></ulink>.
+</para>
+</section>
+
+<section id="archive">
+<title>The Debian archive</title>
+<para>
+The &debian-formal; distribution consists of a lot of packages
+(<filename>.deb</filename>'s, currently around
+&number-of-pkgs;) and a few additional files (such as
+documentation and installation disk images).
+</para>
+<para>
+Here is an example directory tree of a complete Debian archive:
+</para>
+&sample-dist-dirtree;
+<para>
+As you can see, the top-level directory contains two directories,
+<filename>dists/</filename> and <filename>pool/</filename>. The latter is a
+“pool” in which the packages actually are, and which is handled by the
+archive maintenance database and the accompanying programs. The former
+contains the distributions, <emphasis>stable</emphasis>,
+<emphasis>testing</emphasis> and <emphasis>unstable</emphasis>. The
+<filename>Packages</filename> and <filename>Sources</filename> files in the
+distribution subdirectories can reference files in the
+<filename>pool/</filename> directory. The directory tree below each of the
+distributions is arranged in an identical manner. What we describe below for
+<emphasis>stable</emphasis> is equally applicable to the
+<emphasis>unstable</emphasis> and <emphasis>testing</emphasis> distributions.
+</para>
+<para>
+<filename>dists/stable</filename> contains three directories, namely
+<filename>main</filename>, <filename>contrib</filename>, and
+<filename>non-free</filename>.
+</para>
+<para>
+In each of the areas, there is a directory for the source packages
+(<filename>source</filename>) and a directory for each supported architecture
+(<filename>binary-i386</filename>, <filename>binary-m68k</filename>, etc.).
+</para>
+<para>
+The <filename>main</filename> 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
+(<filename>disks-i386</filename>, <filename>disks-m68k</filename>, etc.).
+</para>
+<section id="archive-sections">
+<title>Sections</title>
+<para>
+The <emphasis>main</emphasis> section of the Debian archive is what makes up
+the <emphasis role="strong">official &debian-formal; distribution</emphasis>.
+The <emphasis>main</emphasis> section is official because it fully complies
+with all our guidelines. The other two sections do not, to different degrees;
+as such, they are <emphasis role="strong">not</emphasis> officially part of
+&debian-formal;.
+</para>
+<para>
+Every package in the main section must fully comply with the <ulink
+url="&url-dfsg;">Debian Free Software
+Guidelines</ulink> (DFSG) and with all other policy requirements as described
+in the <ulink url="&url-debian-policy;">Debian Policy
+Manual</ulink>. The DFSG is our definition of “free software.” Check out
+the Debian Policy Manual for details.
+</para>
+<para>
+Packages in the <emphasis>contrib</emphasis> section have to comply with the
+DFSG, but may fail other requirements. For instance, they may depend on
+non-free packages.
+</para>
+<para>
+Packages which do not conform to the DFSG are placed in the
+<emphasis>non-free</emphasis> section. These packages are not considered as
+part of the Debian distribution, though we support their use, and we provide
+infrastructure (such as our bug-tracking system and mailing lists) for non-free
+software packages.
+</para>
+<para>
+The <ulink url="&url-debian-policy;">Debian Policy
+Manual</ulink> contains a more exact definition of the three sections. The
+above discussion is just an introduction.
+</para>
+<para>
+The separation of the three sections at the top-level of the archive is
+important for all people who want to distribute Debian, either via FTP servers
+on the Internet or on CD-ROMs: by distributing only the
+<emphasis>main</emphasis> and <emphasis>contrib</emphasis> sections, one can
+avoid any legal risks. Some packages in the <emphasis>non-free</emphasis>
+section do not allow commercial distribution, for example.
+</para>
+<para>
+On the other hand, a CD-ROM vendor could easily check the individual package
+licenses of the packages in <emphasis>non-free</emphasis> and include as many
+on the CD-ROMs as it's allowed to. (Since this varies greatly from vendor to
+vendor, this job can't be done by the Debian developers.)
+</para>
+<para>
+Note that the term section is also used to refer to categories which simplify
+the organization and browsing of available packages, e.g.
+<emphasis>admin</emphasis>, <emphasis>net</emphasis>,
+<emphasis>utils</emphasis> etc. Once upon a time, these sections (subsections,
+rather) existed in the form of subdirectories within the Debian archive.
+Nowadays, these exist only in the Section header fields of packages.
+</para>
+</section>
+
+<section id="s4.6.2">
+<title>Architectures</title>
+<para>
+In the first days, the Linux kernel was only available for Intel i386 (or
+greater) platforms, and so was Debian. But as Linux became more and more
+popular, the kernel was ported to other architectures, too.
+</para>
+<para>
+The Linux 2.0 kernel supports Intel x86, DEC Alpha, SPARC, Motorola 680x0 (like
+Atari, Amiga and Macintoshes), MIPS, and PowerPC. The 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
+kernels. Aside from <emphasis>i386</emphasis> (our name for Intel x86), there
+is <emphasis>m68k</emphasis>, <emphasis>alpha</emphasis>,
+<emphasis>powerpc</emphasis>, <emphasis>sparc</emphasis>,
+<emphasis>hurd-i386</emphasis>, <emphasis>arm</emphasis>,
+<emphasis>ia64</emphasis>, <emphasis>hppa</emphasis>,
+<emphasis>s390</emphasis>, <emphasis>mips</emphasis>,
+<emphasis>mipsel</emphasis> and <emphasis>sh</emphasis> as of this writing.
+</para>
+<para>
+&debian-formal; 1.3 is only available as <emphasis>i386</emphasis>. Debian
+2.0 shipped for <emphasis>i386</emphasis> and <emphasis>m68k</emphasis>
+architectures. Debian 2.1 ships for the <emphasis>i386</emphasis>,
+<emphasis>m68k</emphasis>, <emphasis>alpha</emphasis>, and
+<emphasis>sparc</emphasis> architectures. Debian 2.2 added support for the
+<emphasis>powerpc</emphasis> and <emphasis>arm</emphasis> architectures.
+Debian 3.0 added support of five new architectures: <emphasis>ia64</emphasis>,
+<emphasis>hppa</emphasis>, <emphasis>s390</emphasis>, <emphasis>mips</emphasis>
+and <emphasis>mipsel</emphasis>.
+</para>
+<para>
+Information for developers and users about the specific ports are available at
+the <ulink url="&url-debian-ports;">Debian Ports web pages</ulink>.
+</para>
+</section>
+
+<section id="s4.6.3">
+<title>Packages</title>
+<para>
+There are two types of Debian packages, namely <emphasis>source</emphasis> and
+<emphasis>binary</emphasis> packages.
+</para>
+<para>
+Source packages consist of either two or three files: a
+<filename>.dsc</filename> file, and either a <filename>.tar.gz</filename> file
+or both an <filename>.orig.tar.gz</filename> and a
+<filename>.diff.gz</filename> file.
+</para>
+<para>
+If a package is developed specially for Debian and is not distributed outside
+of Debian, there is just one <filename>.tar.gz</filename> file which contains
+the sources of the program. If a package is distributed elsewhere too, the
+<filename>.orig.tar.gz</filename> file stores the so-called <emphasis>upstream
+source code</emphasis>, that is the source code that's distributed by the
+<emphasis>upstream maintainer</emphasis> (often the author of the software).
+In this case, the <filename>.diff.gz</filename> contains the changes made by
+the Debian maintainer.
+</para>
+<para>
+The <filename>.dsc</filename> file lists all the files in the source package
+together with checksums (<command>md5sums</command>) and some additional info
+about the package (maintainer, version, etc.).
+</para>
+</section>
+
+<section id="s4.6.4">
+<title>Distributions</title>
+<para>
+The directory system described in the previous chapter is itself contained
+within <emphasis>distribution directories</emphasis>. Each distribution is
+actually contained in the <filename>pool</filename> directory in the top-level
+of the Debian archive itself.
+</para>
+<para>
+To summarize, the Debian archive has a root directory within an FTP server.
+For instance, at the mirror site, <literal>ftp.us.debian.org</literal>, the
+Debian archive itself is contained in <ulink
+url="ftp://ftp.us.debian.org/debian">/debian</ulink>, which is a common
+location (another is <filename>/pub/debian</filename>).
+</para>
+<para>
+A distribution comprises Debian source and binary packages, and the respective
+<filename>Sources</filename> and <filename>Packages</filename> index files,
+containing the header information from all those packages. The former are kept
+in the <filename>pool/</filename> directory, while the latter are kept in the
+<filename>dists/</filename> directory of the archive (for backwards
+compatibility).
+</para>
+<section id="sec-dists">
+<title>Stable, testing, and unstable</title>
+<para>
+There are always distributions called <emphasis>stable</emphasis> (residing in
+<filename>dists/stable</filename>), <emphasis>testing</emphasis> (residing in
+<filename>dists/testing</filename>), and <emphasis>unstable</emphasis>
+(residing in <filename>dists/unstable</filename>). This reflects the
+development process of the Debian project.
+</para>
+<para>
+Active development is done in the <emphasis>unstable</emphasis> distribution
+(that's why this distribution is sometimes called the <emphasis>development
+distribution</emphasis>). Every Debian developer can update his or her
+packages in this distribution at any time. Thus, the contents of this
+distribution change from day to day. Since no special effort is made to make
+sure everything in this distribution is working properly, it is sometimes
+literally unstable.
+</para>
+<para>
+The <link linkend="testing">testing</link> distribution 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. See <xref linkend="testing"/> .
+</para>
+<para>
+After a period of development, once the release manager deems fit, the
+<emphasis>testing</emphasis> distribution is frozen, meaning that the policies
+which control how packages move from <emphasis>unstable</emphasis> to
+<emphasis>testing</emphasis> are tightened. Packages which are too buggy are
+removed. No changes are allowed into <emphasis>testing</emphasis> except for
+bug fixes. After some time has elapsed, depending on progress, the
+<emphasis>testing</emphasis> distribution is frozen even further. Details of
+the handling of the testing distribution are published by the Release Team on
+debian-devel-announce. After the open issues are solved to the satisfaction of
+the Release Team, the distribution is released. Releasing means that
+<emphasis>testing</emphasis> is renamed to <emphasis>stable</emphasis>, and a
+new copy is created for the new <emphasis>testing</emphasis>, and the previous
+<emphasis>stable</emphasis> is renamed to <emphasis>oldstable</emphasis> and
+stays there until it is finally archived. On archiving, the contents are moved
+to <literal>&archive-host;</literal>).
+</para>
+<para>
+This development cycle is based on the assumption that the
+<emphasis>unstable</emphasis> distribution becomes <emphasis>stable</emphasis>
+after passing a period of being in <emphasis>testing</emphasis>. Even once a
+distribution is considered stable, a few bugs inevitably remain — that's why
+the stable distribution is updated every now and then. However, these updates
+are tested very carefully and have to be introduced into the archive
+individually to reduce the risk of introducing new bugs. You can find proposed
+additions to <emphasis>stable</emphasis> in the
+<filename>proposed-updates</filename> directory. Those packages in
+<filename>proposed-updates</filename> that pass muster are periodically moved
+as a batch into the stable distribution and the revision level of the stable
+distribution is incremented (e.g., ‘3.0’ becomes ‘3.0r1’, ‘2.2r4’
+becomes ‘2.2r5’, and so forth). Please refer to
+<link linkend="upload-stable">uploads to the <emphasis>stable</emphasis>
+distribution</link> for details.
+</para>
+<para>
+Note that development under <emphasis>unstable</emphasis> continues during the
+freeze period, since the <emphasis>unstable</emphasis> distribution remains in
+place in parallel with <emphasis>testing</emphasis>.
+</para>
+</section>
+
+<section id="s4.6.4.2">
+<title>More information about the testing distribution</title>
+<para>
+Packages are usually installed into the `testing' distribution after they have
+undergone some degree of testing in unstable.
+</para>
+<para>
+For more details, please see the <link linkend="testing">information about
+the testing distribution</link>.
+</para>
+</section>
+
+<section id="experimental">
+<title>Experimental</title>
+<para>
+The <emphasis>experimental</emphasis> distribution is a special distribution.
+It is not a full distribution in the same sense as `stable' and `unstable' are.
+Instead, it is meant to be a temporary staging area for highly experimental
+software where there's a good chance that the software could break your system,
+or software that's just too unstable even for the <emphasis>unstable</emphasis>
+distribution (but there is a reason to package it nevertheless). Users who
+download and install packages from <emphasis>experimental</emphasis> are
+expected to have been duly warned. In short, all bets are off for the
+<emphasis>experimental</emphasis> distribution.
+</para>
+<para>
+These are the <citerefentry> <refentrytitle>sources.list</refentrytitle>
+<manvolnum>5</manvolnum> </citerefentry> lines for
+<emphasis>experimental</emphasis>:
+</para>
+<programlisting>
+deb http://ftp.<replaceable>xy</replaceable>.debian.org/debian/ experimental main
+deb-src http://ftp.<replaceable>xy</replaceable>.debian.org/debian/ experimental main
+</programlisting>
+<para>
+If there is a chance that the software could do grave damage to a system, it is
+likely to be better to put it into <emphasis>experimental</emphasis>. For
+instance, an experimental compressed file system should probably go into
+<emphasis>experimental</emphasis>.
+</para>
+<para>
+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 <emphasis>experimental</emphasis>. A new, beta, version of some
+software which uses a completely different configuration can go into
+<emphasis>experimental</emphasis>, at the maintainer's discretion. If you are
+working on an incompatible or complex upgrade situation, you can also use
+<emphasis>experimental</emphasis> as a staging area, so that testers can get
+early access.
+</para>
+<para>
+Some experimental software can still go into <emphasis>unstable</emphasis>,
+with a few warnings in the description, but that isn't recommended because
+packages from <emphasis>unstable</emphasis> are expected to propagate to
+<emphasis>testing</emphasis> and thus to <emphasis>stable</emphasis>. You
+should not be afraid to use <emphasis>experimental</emphasis> since it does not
+cause any pain to the ftpmasters, the experimental packages are automatically
+removed once you upload the package in <emphasis>unstable</emphasis> with a
+higher version number.
+</para>
+<para>
+New software which isn't likely to damage your system can go directly into
+<emphasis>unstable</emphasis>.
+</para>
+<para>
+An alternative to <emphasis>experimental</emphasis> is to use your personal web
+space on <literal>people.debian.org</literal>.
+</para>
+<para>
+When uploading to unstable a package which had bugs fixed in experimental,
+please consider using the option <literal>-v</literal> to
+<command>dpkg-buildpackage</command> to finally get them closed.
+</para>
+</section>
+
+</section>
+
+<section id="codenames">
+<title>Release code names</title>
+<para>
+Every released Debian distribution has a <emphasis>code name</emphasis>: Debian
+1.1 is called `buzz'; Debian 1.2, `rex'; Debian 1.3, `bo'; Debian 2.0, `hamm';
+Debian 2.1, `slink'; Debian 2.2, `potato'; Debian 3.0, `woody'; Debian 3.1,
+sarge; Debian 4.0, etch. There is also a ``pseudo-distribution'', called
+`sid', which is the current `unstable' distribution; since packages are moved
+from `unstable' to `testing' as they approach stability, `sid' itself is never
+released. As well as the usual contents of a Debian distribution, `sid'
+contains packages for architectures which are not yet officially supported or
+released by Debian. These architectures are planned to be integrated into the
+mainstream distribution at some future date.
+</para>
+<para>
+Since Debian has an open development model (i.e., everyone can participate and
+follow the development) even the `unstable' and `testing' distributions are
+distributed to the Internet through the Debian FTP and HTTP server network.
+Thus, if we had called the directory which contains the release candidate
+version `testing', then we would have to rename it to `stable' when the version
+is released, which would cause all FTP mirrors to re-retrieve the whole
+distribution (which is quite large).
+</para>
+<para>
+On the other hand, if we called the distribution directories
+<emphasis>Debian-x.y</emphasis> from the beginning, people would think that
+Debian release <emphasis>x.y</emphasis> is available. (This happened in the
+past, where a CD-ROM vendor built a Debian 1.0 CD-ROM based on a pre-1.0
+development version. That's the reason why the first official Debian release
+was 1.1, and not 1.0.)
+</para>
+<para>
+Thus, the names of the distribution directories in the archive are determined
+by their code names and not their release status (e.g., `slink'). These names
+stay the same during the development period and after the release; symbolic
+links, which can be changed easily, indicate the currently released stable
+distribution. That's why the real distribution directories use the
+<emphasis>code names</emphasis>, while symbolic links for
+<emphasis>stable</emphasis>, <emphasis>testing</emphasis>, and
+<emphasis>unstable</emphasis> point to the appropriate release directories.
+</para>
+</section>
+
+</section>
+
+<section id="mirrors">
+<title>Debian mirrors</title>
+<para>
+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 — 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. Note that the first tier of mirrors is as up-to-date as it
+can be since they update when triggered from the internal sites (we call this
+push mirroring).
+</para>
+<para>
+All the information on Debian mirrors, including a list of the available public
+FTP/HTTP servers, can be found at <ulink
+url="&url-debian-mirrors;"></ulink>. This useful page also
+includes information and tools which can be helpful if you are interested in
+setting up your own mirror, either for internal or public access.
+</para>
+<para>
+Note that mirrors are generally run by third-parties who are interested in
+helping Debian. As such, developers generally do not have accounts on these
+machines.
+</para>
+</section>
+
+<section id="incoming-system">
+<title>The Incoming system</title>
+<para>
+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 on <literal>&ftp-master-host;</literal>.
+</para>
+<para>
+Packages are uploaded by all the maintainers into a directory called
+<filename>UploadQueue</filename>. This directory is scanned every few minutes
+by a daemon called <command>queued</command>,
+<filename>*.command</filename>-files are executed, and remaining and correctly
+signed <filename>*.changes</filename>-files are moved together with their
+corresponding files to the <filename>unchecked</filename> directory. This
+directory is not visible for most Developers, as ftp-master is restricted; it
+is scanned every 15 minutes by the <command>katie</command> 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 <filename>accepted</filename> directory. If this is the first upload
+of the package (or it has new binary packages), it is moved to the
+<filename>new</filename> directory, where it waits for approval by the
+ftpmasters. If the package contains files to be installed by hand it is moved
+to the <filename>byhand</filename> directory, where it waits for manual
+installation by the ftpmasters. Otherwise, if any error has been detected, the
+package is refused and is moved to the <filename>reject</filename> directory.
+</para>
+<para>
+Once the package is accepted, the system sends a confirmation mail to the
+maintainer and closes all the bugs marked as fixed by the upload, and the
+auto-builders may start recompiling it. The package is now publicly accessible
+at <ulink url="&url-incoming;"></ulink> until it is really
+installed in the Debian archive. This happens only once a day (and is also
+called the `dinstall run' for historical reasons); the package is then removed
+from incoming and installed in the pool along with all the other packages.
+Once all the other updates (generating new <filename>Packages</filename> and
+<filename>Sources</filename> index files for example) have been made, a special
+script is called to ask all the primary mirrors to update themselves.
+</para>
+<para>
+The archive maintenance software will also send the OpenPGP/GnuPG signed
+<filename>.changes</filename> file that you uploaded to the appropriate mailing
+lists. If a package is released with the <literal>Distribution:</literal> set
+to `stable', the announcement is sent to
+&email-debian-changes;. If a package is released with
+<literal>Distribution:</literal> set to `unstable' or `experimental', the
+announcement will be posted to &email-debian-devel-changes;
+instead.
+</para>
+<para>
+Though ftp-master is restricted, a copy of the installation is available to all
+developers on <literal>&ftp-master-mirror;</literal>.
+</para>
+<!-- FIXME: delete it or keep it for historical purposes?
+<para>
+All Debian developers have write access to the <filename>unchecked</filename>
+directory in order to upload their packages; they also have that access
+to the <filename>reject</filename> directory in order to remove their bad uploads
+or to move some files back to the <filename>unchecked</filename> directory. But
+all the other directories are only writable by the ftpmasters, which is
+why you cannot remove an upload once it has been accepted.
+</para>
+
+<section id="delayed-incoming-broken">
+<title>Delayed incoming</title>
+<para>
+<emphasis>Note:</emphasis> This description here is currently not working, because
+ftp-master is restricted. Please see <xref linkend="delayed-incoming"/> for
+the currently working way.
+</para>
+<para>
+The <filename>unchecked</filename> directory has a special <filename>DELAYED</filename>
+subdirectory. It is itself subdivided in nine directories
+called <filename>1-day</filename> to <filename>9-day</filename>. Packages which are uploaded to
+one of those directories will be moved to the real unchecked
+directory after the corresponding number of days.
+This is done by a script which is run each day and which moves the
+packages between the directories. Those which are in "1-day" are
+installed in <filename>unchecked</filename> while the others are moved to the
+adjacent directory (for example, a package in <filename>5-day</filename> will
+be moved to <filename>4-day</filename>). This feature is particularly useful
+for people who are doing non-maintainer uploads. Instead of
+waiting before uploading a NMU, it is uploaded as soon as it is
+ready, but to one of those <filename>DELAYED/<varname>x</varname>-day</filename> directories.
+That leaves the corresponding number of days for the maintainer
+to react and upload another fix themselves if they are not
+completely satisfied with the NMU. Alternatively they can remove
+the NMU.
+</para>
+<para>
+The use of that delayed feature can be simplified with a bit
+of integration with your upload tool. For instance, if you use
+<command>dupload</command> (see <xref linkend="dupload"/>), you can add this
+snippet to your configuration file:
+<programlisting>
+$delay = ($ENV{DELAY} || 7);
+$cfg{'delayed'} = {
+ fqdn => "&ftp-master-host;",
+ login => "yourdebianlogin",
+ incoming => "/org/&ftp-debian-org;/incoming/DELAYED/$delay-day/",
+ dinstall_runs => 1,
+ method => "scpb"
+};
+</programlisting>
+Once you've made that change, <command>dupload</command> can be used to
+easily upload a package in one of the delayed directories:
+<literal>DELAY=5 dupload -X-to delayed <changes-file></literal>
+</para>
+</section>
+-->
+</section>
+
+<section id="pkg-info">
+<title>Package information</title>
+<section id="pkg-info-web">
+<title>On the web</title>
+<para>
+Each package has several dedicated web pages.
+<literal>http://&packages-host;/<replaceable>package-name</replaceable></literal>
+displays each version of the package available in the various distributions.
+Each version links to a page which provides information, including the package
+description, the dependencies, and package download links.
+</para>
+<para>
+The bug tracking system tracks bugs for each package. You can view the bugs of
+a given package at the URL
+<literal>http://&bugs-host;/<replaceable>package-name</replaceable></literal>.
+</para>
+</section>
+
+<section id="madison">
+<title>The <command>madison</command> utility</title>
+<para>
+<command>madison</command> is a command-line utility that is available on
+<literal>&ftp-master-host;</literal>, and on the mirror on
+<literal>&ftp-master-mirror;</literal>. It uses a single argument corresponding
+to a package name. In result it displays which version of the package is
+available for each architecture and distribution combination. An example will
+explain it better.
+</para>
+<screen>
+$ madison libdbd-mysql-perl
+libdbd-mysql-perl | 1.2202-4 | stable | source, alpha, arm, i386, m68k, powerpc, sparc
+libdbd-mysql-perl | 1.2216-2 | testing | source, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
+libdbd-mysql-perl | 1.2216-2.0.1 | testing | alpha
+libdbd-mysql-perl | 1.2219-1 | unstable | source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
+</screen>
+<para>
+In this example, you can see that the version in <emphasis>unstable</emphasis>
+differs from the version in <emphasis>testing</emphasis> and that there has
+been a binary-only NMU of the package for the alpha architecture. Each version
+of the package has been recompiled on most of the architectures.
+</para>
+</section>
+
+</section>
+
+<section id="pkg-tracking-system">
+<title>The Package Tracking System</title>
+<para>
+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.
+</para>
+<para>
+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.
+</para>
+<para>
+By default you will get:
+</para>
+<variablelist>
+<varlistentry>
+<term><literal>bts</literal></term>
+<listitem>
+<para>
+All the bug reports and following discussions.
+</para>
+</listitem>
+</varlistentry>
+<varlistentry>
+<term><literal>bts-control</literal></term>
+<listitem>
+<para>
+The email notifications from <email>control@&bugs-host;</email> about bug
+report status changes.
+</para>
+</listitem>
+</varlistentry>
+<varlistentry>
+<term><literal>upload-source</literal></term>
+<listitem>
+<para>
+The email notification from <command>katie</command> when an uploaded source
+package is accepted.
+</para>
+</listitem>
+</varlistentry>
+<varlistentry>
+<term><literal>katie-other</literal></term>
+<listitem>
+<para>
+Other warning and error emails from <command>katie</command> (such as an
+override disparity for the section and/or the priority field).
+</para>
+</listitem>
+</varlistentry>
+<varlistentry>
+<term><literal>default</literal></term>
+<listitem>
+<para>
+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
+<literal><replaceable>sourcepackage</replaceable>@&pts-host;</literal>.
+In order to prevent spam, all messages sent to these addresses must contain the
+<literal>X-PTS-Approved</literal> header with a non-empty value.
+</para>
+</listitem>
+</varlistentry>
+<varlistentry>
+<term><literal>contact</literal></term>
+<listitem>
+<para>
+Mails sent to the maintainer through the *@packages.debian.org email
+aliases.
+</para>
+</listitem>
+</varlistentry>
+<varlistentry>
+<term><literal>summary</literal></term>
+<listitem>
+<para>
+Regular summary emails about the package's status. Currently, only progression
+in <emphasis>testing</emphasis> is sent.
+</para>
+</listitem>
+</varlistentry>
+</variablelist>
+<para>
+You can also decide to receive additional information:
+</para>
+<variablelist>
+<varlistentry>
+<term><literal>upload-binary</literal></term>
+<listitem>
+<para>
+The email notification from <command>katie</command> 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.
+</para>
+</listitem>
+</varlistentry>
+<varlistentry>
+<term><literal>cvs</literal></term>
+<listitem>
+<para>
+VCS commit notifications, if the package has a VCS repository and the
+maintainer has set up forwarding of commit notifications to the PTS. The
+"cvs" name is historic, in most cases commit notifications will come
+from some other VCS like subversion or git.
+</para>
+</listitem>
+</varlistentry>
+<varlistentry>
+<term><literal>ddtp</literal></term>
+<listitem>
+<para>
+Translations of descriptions or debconf templates submitted to the Debian
+Description Translation Project.
+</para>
+</listitem>
+</varlistentry>
+<varlistentry>
+<term><literal>derivatives</literal></term>
+<listitem>
+<para>
+Information about changes made to the package in derivative distributions (for
+example Ubuntu).
+</para>
+</listitem>
+</varlistentry>
+</variablelist>
+<section id="pts-commands">
+<title>The PTS email interface</title>
+<para>
+You can control your subscription(s) to the PTS by sending various commands to
+<email>pts@qa.debian.org</email>.
+</para>
+<variablelist>
+<varlistentry>
+<term><literal>subscribe <sourcepackage> [<email>]</literal></term>
+<listitem>
+<para>
+Subscribes <replaceable>email</replaceable> to communications related to the
+source package <replaceable>sourcepackage</replaceable>. Sender address is
+used if the second argument is not present. If
+<replaceable>sourcepackage</replaceable> 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.
+</para>
+</listitem>
+</varlistentry>
+<varlistentry>
+<term><literal>unsubscribe <sourcepackage> [<email>]</literal></term>
+<listitem>
+<para>
+Removes a previous subscription to the source package
+<replaceable>sourcepackage</replaceable> using the specified email address or
+the sender address if the second argument is left out.
+</para>
+</listitem>
+</varlistentry>
+<varlistentry>
+<term><literal>unsubscribeall [<email>]</literal></term>
+<listitem>
+<para>
+Removes all subscriptions of the specified email address or the sender address
+if the second argument is left out.
+</para>
+</listitem>
+</varlistentry>
+<varlistentry>
+<term><literal>which [<email>]</literal></term>
+<listitem>
+<para>
+Lists all subscriptions for the sender or the email address optionally
+specified.
+</para>
+</listitem>
+</varlistentry>
+<varlistentry>
+<term><literal>keyword [<email>]</literal></term>
+<listitem>
+<para>
+Tells you the keywords that you are accepting. For an explanation of keywords,
+<link linkend="pkg-tracking-system">see above</link>. Here's a quick
+summary:
+</para>
+<itemizedlist>
+<listitem>
+<para>
+<literal>bts</literal>: mails coming from the Debian Bug Tracking System
+</para>
+</listitem>
+<listitem>
+<para>
+<literal>bts-control</literal>: reply to mails sent to
+&email-bts-control;
+</para>
+</listitem>
+<listitem>
+<para>
+<literal>summary</literal>: automatic summary mails about the state of a
+package
+</para>
+</listitem>
+<listitem>
+<para>
+<literal>contact</literal>: mails sent to the maintainer through the
+*@packages.debian.org aliases
+</para>
+</listitem>
+<listitem>
+<para>
+<literal>cvs</literal>: notification of VCS commits
+</para>
+</listitem>
+<listitem>
+<para>
+<literal>ddtp</literal>: translations of descriptions and debconf templates
+</para>
+</listitem>
+<listitem>
+<para>
+<literal>derivatives</literal>: changes made on the package by derivative
+distributions
+</para>
+</listitem>
+<listitem>
+<para>
+<literal>upload-source</literal>: announce of a new source upload that has been
+accepted
+</para>
+</listitem>
+<listitem>
+<para>
+<literal>upload-binary</literal>: announce of a new binary-only upload
+(porting)
+</para>
+</listitem>
+<listitem>
+<para>
+<literal>katie-other</literal>: other mails from ftpmasters (override
+disparity, etc.)
+</para>
+</listitem>
+<listitem>
+<para>
+<literal>default</literal>: all the other mails (those which aren't automatic)
+</para>
+</listitem>
+</itemizedlist>
+</listitem>
+</varlistentry>
+<varlistentry>
+<term><literal>keyword <sourcepackage> [<email>]</literal></term>
+<listitem>
+<para>
+Same as the previous item but for the given source package, since you may
+select a different set of keywords for each source package.
+</para>
+</listitem>
+</varlistentry>
+<varlistentry>
+<term><literal>keyword [<email>] {+|-|=} <list of keywords></literal></term>
+<listitem>
+<para>
+Accept (+) or refuse (-) mails classified under the given keyword(s). Define
+the list (=) of accepted keywords. This changes the default set of keywords
+accepted by a user.
+</para>
+</listitem>
+</varlistentry>
+<varlistentry>
+<term><literal>keywordall [<email>] {+|-|=} <list of keywords></literal></term>
+<listitem>
+<para>
+Accept (+) or refuse (-) mails classified under the given keyword(s). Define
+the list (=) of accepted keywords. This changes the set of accepted keywords
+of all the currently active subscriptions of a user.
+</para>
+</listitem>
+</varlistentry>
+<varlistentry>
+<term><literal>keyword <sourcepackage> [<email>] {+|-|=} <list of keywords></literal></term>
+<listitem>
+<para>
+Same as previous item but overrides the keywords list for the indicated source
+package.
+</para>
+</listitem>
+</varlistentry>
+<varlistentry>
+<term><literal>quit | thanks | --</literal></term>
+<listitem>
+<para>
+Stops processing commands. All following lines are ignored by the bot.
+</para>
+</listitem>
+</varlistentry>
+</variablelist>
+<para>
+The <command>pts-subscribe</command> command-line utility (from the <systemitem
+role="package">devscripts</systemitem> package) can be handy to temporarily
+subscribe to some packages, for example after having made an non-maintainer
+upload.
+</para>
+</section>
+
+<section id="pts-mail-filtering">
+<title>Filtering PTS mails</title>
+<para>
+Once you are subscribed to a package, you will get the mails sent to
+<literal><replaceable>sourcepackage</replaceable>@&pts-host;</literal>.
+Those mails have special headers appended to let you filter them in a special
+mailbox (e.g. with <command>procmail</command>). The added headers are
+<literal>X-Loop</literal>, <literal>X-PTS-Package</literal>,
+<literal>X-PTS-Keyword</literal> and <literal>X-Unsubscribe</literal>.
+</para>
+<para>
+Here is an example of added headers for a source upload notification on the
+<systemitem role="package">dpkg</systemitem> package:
+</para>
+<screen>
+X-Loop: dpkg@&pts-host;
+X-PTS-Package: dpkg
+X-PTS-Keyword: upload-source
+List-Unsubscribe: <mailto:pts@qa.debian.org?body=unsubscribe+dpkg>
+</screen>
+</section>
+
+<section id="pts-vcs-commit">
+<title>Forwarding VCS commits in the PTS</title>
+<para>
+If you use a publicly accessible VCS repository for maintaining your Debian
+package, you may want to forward the commit notification to the PTS so that the
+subscribers (and possible co-maintainers) can closely follow the package's
+evolution.
+</para>
+<para>
+Once you set up the VCS repository to generate commit notifications, you just
+have to make sure it sends a copy of those mails to
+<literal><replaceable>sourcepackage</replaceable>_cvs@&pts-host;</literal>.
+Only the people who accept the <emphasis>cvs</emphasis> keyword will receive
+these notifications. Note that the mail need to be sent from a
+<literal>debian.org</literal> machine, otherwise you'll have to add
+the <literal>X-PTS-Approved: 1</literal> header.
+</para>
+<para>
+For Subversion repositories, the usage of svnmailer is recommended.
+See <ulink url="&url-alioth-pkg;" /> for an example on how to do it.
+</para>
+</section>
+
+<section id="pts-web">
+<title>The PTS web interface</title>
+<para>
+The PTS has a web interface at <ulink
+url="http://&pts-host;/"></ulink> 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
+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 allows easy
+subscription to the PTS via email.
+</para>
+<para>
+You can jump directly to the web page concerning a specific source package with
+a URL like
+<literal>http://&pts-host;/<replaceable>sourcepackage</replaceable></literal>.
+</para>
+<para>
+This web interface has been designed like a portal for the development of
+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.
+</para>
+<para>
+Static news items can be used to indicate:
+</para>
+<itemizedlist>
+<listitem>
+<para>
+the availability of a project hosted on
+<link linkend="alioth">Alioth</link> for co-maintaining the package
+</para>
+</listitem>
+<listitem>
+<para>
+a link to the upstream web site
+</para>
+</listitem>
+<listitem>
+<para>
+a link to the upstream bug tracker
+</para>
+</listitem>
+<listitem>
+<para>
+the existence of an IRC channel dedicated to the software
+</para>
+</listitem>
+<listitem>
+<para>
+any other available resource that could be useful in the maintenance of the
+package
+</para>
+</listitem>
+</itemizedlist>
+<para>
+Usual news items may be used to announce that:
+</para>
+<itemizedlist>
+<listitem>
+<para>
+beta packages are available for testing
+</para>
+</listitem>
+<listitem>
+<para>
+final packages are expected for next week
+</para>
+</listitem>
+<listitem>
+<para>
+the packaging is about to be redone from scratch
+</para>
+</listitem>
+<listitem>
+<para>
+backports are available
+</para>
+</listitem>
+<listitem>
+<para>
+the maintainer is on vacation (if they wish to publish this information)
+</para>
+</listitem>
+<listitem>
+<para>
+a NMU is being worked on
+</para>
+</listitem>
+<listitem>
+<para>
+something important will affect the package
+</para>
+</listitem>
+</itemizedlist>
+<para>
+Both kinds of news are generated in a similar manner: you just have to send an
+email either to <email>pts-static-news@qa.debian.org</email> or to
+<email>pts-news@qa.debian.org</email>. The mail should indicate which package
+is concerned by having the name of the source package in a
+<literal>X-PTS-Package</literal> mail header or in a <literal>Package</literal>
+pseudo-header (like the BTS reports). If a URL is available in the
+<literal>X-PTS-Url</literal> mail header or in the <literal>Url</literal>
+pseudo-header, then the result is a link to that URL instead of a complete news
+item.
+</para>
+<para>
+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:
+</para>
+<screen>
+From: Raphael Hertzog <hertzog@debian.org>
+To: pts-static-news@qa.debian.org
+Subject: Browse debian-cd SVN repository
+
+Package: debian-cd
+Url: http://svn.debian.org/viewsvn/debian-cd/trunk/
+</screen>
+<para>
+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.
+</para>
+<screen>
+From: Raphael Hertzog <hertzog@debian.org>
+To: debian-gtk-gnome@&lists-host;
+Bcc: pts-news@qa.debian.org
+Subject: Galeon 2.0 backported for woody
+X-PTS-Package: galeon
+
+Hello gnomers!
+
+I'm glad to announce that galeon has been backported for woody. You'll find
+everything here:
+...
+</screen>
+<para>
+Think twice before adding a news item to the PTS because you won't be able to
+remove it later and you won'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.
+</para>
+</section>
+
+</section>
+
+<section id="ddpo">
+<title>Developer's packages overview</title>
+<para>
+A QA (quality assurance) web portal is available at <ulink
+url="&url-ddpo;"></ulink> which displays a table listing all
+the packages of a single developer (including those where the party is listed
+as a co-maintainer). The table gives a good summary about the developer's
+packages: number of bugs by severity, list of available versions in each
+distribution, testing status and much more including links to any other useful
+information.
+</para>
+<para>
+It is a good idea to look up your own data regularly so that you don't forget
+any open bugs, and so that you don't forget which packages are your
+responsibility.
+</para>
+</section>
+
+<section id="alioth">
+<title>Debian's GForge installation: Alioth</title>
+<para>
+Alioth is a 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.
+</para>
+<para>
+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. It's heavily used by many Debian teams and provides
+hosting for all sorts of VCS repositories.
+</para>
+<para>
+All Debian developers automatically have an account on Alioth. They can
+activate it by using the recover password facility. External developers can
+request guest accounts on Alioth.
+</para>
+<para>
+For more information please visit the following links:
+</para>
+<itemizedlist>
+<listitem><para><ulink url="&url-alioth-wiki;" /></para></listitem>
+<listitem><para><ulink url="&url-alioth-faq;" /></para></listitem>
+<listitem><para><ulink url="&url-alioth-pkg;" /></para></listitem>
+<listitem><para><ulink url="&url-alioth;" /></para></listitem>
+</itemizedlist>
+</section>
+
+<section id="developer-misc">
+<title>Goodies for Developers</title>
+<section id="lwn">
+<title>LWN Subscriptions</title>
+<para>
+Since October of 2002, HP has sponsored a subscription to LWN for all
+interested Debian developers. Details on how to get access to this benefit are
+in <ulink
+url="http://&lists-host;/debian-devel-announce/2002/10/msg00018.html"></ulink>.
+</para>
+</section>
+
+</section>
+
+</chapter>
+
--- /dev/null
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
+ "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
+ <!ENTITY % commondata SYSTEM "common.ent" > %commondata;
+]>
+<chapter id="scope">
+<title>Scope of This Document</title>
+<para>
+The purpose of this document is to provide an overview of the recommended
+procedures and the available resources for Debian developers.
+</para>
+<!-- FIXME: rewrites -->
+<para>
+The procedures discussed within include how to become a maintainer (<xref
+linkend="new-maintainer"/> ); how to create new packages (<xref
+linkend="newpackage"/> ) and how to upload packages (<xref linkend="upload"/>
+); how to handle bug reports (<xref linkend="bug-handling"/> ); how to move,
+remove, or orphan packages (<xref linkend="archive-manip"/> ); how to port
+packages (<xref linkend="porting"/> ); and how and when to do interim releases
+of other maintainers' packages (<xref linkend="nmu"/> ).
+</para>
+<para>
+The resources discussed in this reference include the mailing lists (<xref
+linkend="mailing-lists"/> ) and servers (<xref linkend="server-machines"/> ); a
+discussion of the structure of the Debian archive (<xref linkend="archive"/> );
+explanation of the different servers which accept package uploads (<xref
+linkend="upload-ftp-master"/> ); and a discussion of resources which can help
+maintainers with the quality of their packages (<xref linkend="tools"/> ).
+</para>
+<para>
+It should be clear that this reference does not discuss the technical details
+of Debian packages nor how to generate them. Nor does this reference detail
+the standards to which Debian software must comply. All of such information
+can be found in the <ulink url="&url-debian-policy;">Debian
+Policy Manual</ulink>.
+</para>
+<para>
+Furthermore, this document is <emphasis>not an expression of formal
+policy</emphasis>. It contains documentation for the Debian system and
+generally agreed-upon best practices. Thus, it is not what is called a
+``normative'' document.
+</para>
+</chapter>
+
--- /dev/null
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
+ "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
+ <!ENTITY % commondata SYSTEM "common.ent" > %commondata;
+]>
+<appendix id="tools">
+<title>Overview of Debian Maintainer Tools</title>
+<para>
+This section contains a rough overview of the tools available to maintainers.
+The following is by no means complete or definitive, but just a guide to some
+of the more popular tools.
+</para>
+<para>
+Debian maintainer tools are meant to aid developers and free their time for
+critical tasks. As Larry Wall says, there's more than one way to do it.
+</para>
+<para>
+Some people prefer to use high-level package maintenance tools and some do not.
+Debian is officially agnostic on this issue; any tool which gets the job done
+is fine. Therefore, this section is not meant to stipulate to anyone which
+tools they should use or how they should go about their duties of
+maintainership. Nor is it meant to endorse any particular tool to the
+exclusion of a competing tool.
+</para>
+<para>
+Most of the descriptions of these packages come from the actual package
+descriptions themselves. Further information can be found in the package
+documentation itself. You can also see more info with the command
+<command>apt-cache show <package-name></command>.
+</para>
+<section id="tools-core">
+<title>Core tools</title>
+<para>
+The following tools are pretty much required for any maintainer.
+</para>
+<section id="dpkg-dev">
+<title><systemitem role="package">dpkg-dev</systemitem></title>
+<para>
+<systemitem role="package">dpkg-dev</systemitem> contains the tools (including
+<command>dpkg-source</command>) required to unpack, build, and upload Debian
+source packages. These utilities contain the fundamental, low-level
+functionality required to create and manipulate packages; as such, they are
+essential for any Debian maintainer.
+</para>
+</section>
+
+<section id="debconf">
+<title><systemitem role="package">debconf</systemitem></title>
+<para>
+<systemitem role="package">debconf</systemitem> provides a consistent interface
+to configuring packages interactively. It is user interface independent,
+allowing end-users to configure packages with a text-only interface, an HTML
+interface, or a dialog interface. New interfaces can be added as modules.
+</para>
+<para>
+You can find documentation for this package in the <systemitem
+role="package">debconf-doc</systemitem> package.
+</para>
+<para>
+Many feel that this system should be used for all packages which require
+interactive configuration; see <xref linkend="bpp-config-mgmt"/> . <systemitem
+role="package">debconf</systemitem> is not currently required by Debian Policy,
+but that may change in the future.
+</para>
+</section>
+
+<section id="fakeroot">
+<title><systemitem role="package">fakeroot</systemitem></title>
+<para>
+<systemitem role="package">fakeroot</systemitem> simulates root privileges.
+This enables you to build packages without being root (packages usually want to
+install files with root ownership). If you have <systemitem
+role="package">fakeroot</systemitem> installed, you can build packages as a
+regular user: <literal>dpkg-buildpackage -rfakeroot</literal>.
+</para>
+</section>
+
+</section>
+
+<section id="tools-lint">
+<title>Package lint tools</title>
+<para>
+According to the Free On-line Dictionary of Computing (FOLDOC), `lint' is a
+Unix C language processor which carries out more thorough checks on the code
+than is usual with C compilers. Package lint tools help package maintainers by
+automatically finding common problems and policy violations in their packages.
+</para>
+<section id="lintian">
+<title><systemitem role="package">lintian</systemitem></title>
+<para>
+<systemitem role="package">lintian</systemitem> dissects Debian packages and
+emits information about bugs and policy violations. It contains automated
+checks for many aspects of Debian policy as well as some checks for common
+errors.
+</para>
+<para>
+You should periodically get the newest <systemitem
+role="package">lintian</systemitem> from `unstable' and check over all your
+packages. Notice that the <literal>-i</literal> option provides detailed
+explanations of what each error or warning means, what its basis in Policy is,
+and commonly how you can fix the problem.
+</para>
+<para>
+Refer to <xref linkend="sanitycheck"/> for more information on how and when to
+use Lintian.
+</para>
+<para>
+You can also see a summary of all problems reported by Lintian on your packages
+at <ulink url="&url-lintian;"></ulink>. These reports contain the
+latest <command>lintian</command> output for the whole development distribution
+(unstable).
+</para>
+</section>
+
+<section id="linda">
+<title><systemitem role="package">linda</systemitem></title>
+<para>
+<systemitem role="package">linda</systemitem> is another package linter. It is
+similar to <systemitem role="package">lintian</systemitem> but has a different
+set of checks. Its written in Python rather than Perl.
+</para>
+</section>
+
+<section id="debdiff">
+<title><systemitem role="package">debdiff</systemitem></title>
+<para>
+<command>debdiff</command> (from the <systemitem
+role="package">devscripts</systemitem> package, <xref linkend="devscripts"/> )
+compares file lists and control files of two packages. It is a simple
+regression test, as it will help you notice if the number of binary packages
+has changed since the last upload, or if something has changed in the control
+file. Of course, some of the changes it reports will be all right, but it can
+help you prevent various accidents.
+</para>
+<para>
+You can run it over a pair of binary packages:
+</para>
+<screen>
+debdiff package_1-1_arch.deb package_2-1_arch.deb
+</screen>
+<para>
+Or even a pair of changes files:
+</para>
+<screen>
+debdiff package_1-1_arch.changes package_2-1_arch.changes
+</screen>
+<para>
+For more information please see <citerefentry>
+<refentrytitle>debdiff</refentrytitle> <manvolnum>1</manvolnum>
+</citerefentry>.
+</para>
+</section>
+
+</section>
+
+<section id="tools-helpers">
+<title>Helpers for <filename>debian/rules</filename></title>
+<para>
+Package building tools make the process of writing
+<filename>debian/rules</filename> files easier. See <xref
+linkend="helper-scripts"/> for more information about why these might or might
+not be desired.
+</para>
+<section id="debhelper">
+<title><systemitem role="package">debhelper</systemitem></title>
+<para>
+<systemitem role="package">debhelper</systemitem> is a collection of programs
+which can be used in <filename>debian/rules</filename> to automate common tasks
+related to building binary Debian packages. <systemitem
+role="package">debhelper</systemitem> includes programs to install various
+files into your package, compress files, fix file permissions, and integrate
+your package with the Debian menu system.
+</para>
+<para>
+Unlike some approaches, <systemitem role="package">debhelper</systemitem> is
+broken into several small, simple commands which act in a consistent manner.
+As such, it allows more fine-grained control than some of the other
+debian/rules tools.
+</para>
+<para>
+There are a number of little <systemitem role="package">debhelper</systemitem>
+add-on packages, too transient to document. You can see the list of most of
+them by doing <literal>apt-cache search ^dh-</literal>.
+</para>
+</section>
+
+<section id="debmake">
+<title><systemitem role="package">debmake</systemitem></title>
+<para>
+<systemitem role="package">debmake</systemitem>, a precursor to <systemitem
+role="package">debhelper</systemitem>, is a more coarse-grained
+<filename>debian/rules</filename> assistant. It includes two main programs:
+<command>deb-make</command>, which can be used to help a maintainer convert a
+regular (non-Debian) source archive into a Debian source package; and
+<command>debstd</command>, which incorporates in one big shot the same sort of
+automated functions that one finds in <systemitem
+role="package">debhelper</systemitem>.
+</para>
+<para>
+The consensus is that <systemitem role="package">debmake</systemitem> is now
+deprecated in favor of <systemitem role="package">debhelper</systemitem>. It
+is a bug to use <systemitem role="package">debmake</systemitem> in new
+packages. New packages using <systemitem role="package">debmake</systemitem>
+will be rejected from the archive.
+</para>
+</section>
+
+<section id="dh-make">
+<title><systemitem role="package">dh-make</systemitem></title>
+<para>
+The <systemitem role="package">dh-make</systemitem> package contains
+<command>dh_make</command>, a program that creates a skeleton of files
+necessary to build a Debian package out of a source tree. As the name
+suggests, <command>dh_make</command> is a rewrite of <systemitem
+role="package">debmake</systemitem> and its template files use dh_* programs
+from <systemitem role="package">debhelper</systemitem>.
+</para>
+<para>
+While the rules files generated by <command>dh_make</command> are in general a
+sufficient basis for a working package, they are still just the groundwork: the
+burden still lies on the maintainer to finely tune the generated files and make
+the package entirely functional and Policy-compliant.
+</para>
+</section>
+
+<section id="yada">
+<title><systemitem role="package">yada</systemitem></title>
+<para>
+<systemitem role="package">yada</systemitem> is another packaging helper tool.
+It uses a <filename>debian/packages</filename> file to auto-generate
+<filename>debian/rules</filename> and other necessary files in the
+<filename>debian/</filename> subdirectory. The
+<filename>debian/packages</filename> file contains instruction to build
+packages and there is no need to create any <filename>Makefile</filename>
+files. There is possibility to use macro engine similar to the one used in
+SPECS files from RPM source packages.
+</para>
+<para>
+For more informations see <literal><ulink
+url="http://yada.alioth.debian.org/">YADA site</ulink></literal>.
+</para>
+</section>
+
+<section id="equivs">
+<title><systemitem role="package">equivs</systemitem></title>
+<para>
+<systemitem role="package">equivs</systemitem> is another package for making
+packages. It is often suggested for local use if you need to make a package
+simply to fulfill dependencies. It is also sometimes used when making
+``meta-packages'', which are packages whose only purpose is to depend on other
+packages.
+</para>
+</section>
+
+</section>
+
+<section id="tools-builders">
+<title>Package builders</title>
+<para>
+The following packages help with the package building process, general driving
+<command>dpkg-buildpackage</command> as well as handling supporting tasks.
+</para>
+<section id="cvs-buildpackage">
+<title><systemitem role="package">cvs-buildpackage</systemitem></title>
+<para>
+<systemitem role="package">cvs-buildpackage</systemitem> provides the
+capability to inject or import Debian source packages into a CVS repository,
+build a Debian package from the CVS repository, and helps in integrating
+upstream changes into the repository.
+</para>
+<para>
+These utilities provide an infrastructure to facilitate the use of CVS by
+Debian maintainers. This allows one to keep separate CVS branches of a package
+for <emphasis>stable</emphasis>, <emphasis>unstable</emphasis> and possibly
+<emphasis>experimental</emphasis> distributions, along with the other benefits
+of a version control system.
+</para>
+</section>
+
+<section id="debootstrap">
+<title><systemitem role="package">debootstrap</systemitem></title>
+<para>
+The <systemitem role="package">debootstrap</systemitem> package and script
+allows you to bootstrap a Debian base system into any part of your filesystem.
+By base system, we mean the bare minimum of packages required to operate and
+install the rest of the system.
+</para>
+<para>
+Having a system like this can be useful in many ways. For instance, you can
+<command>chroot</command> into it if you want to test your build dependencies.
+Or you can test how your package behaves when installed into a bare base
+system. Chroot builders use this package; see below.
+</para>
+</section>
+
+<section id="pbuilder">
+<title><systemitem role="package">pbuilder</systemitem></title>
+<para>
+<systemitem role="package">pbuilder</systemitem> constructs a chrooted system,
+and builds a package inside the chroot. It is very useful to check that a
+package's build-dependencies are correct, and to be sure that unnecessary and
+wrong build dependencies will not exist in the resulting package.
+</para>
+<para>
+A related package is <systemitem role="package">pbuilder-uml</systemitem>,
+which goes even further by doing the build within a User Mode Linux
+environment.
+</para>
+</section>
+
+<section id="sbuild">
+<title><systemitem role="package">sbuild</systemitem></title>
+<para>
+<systemitem role="package">sbuild</systemitem> is another automated builder.
+It can use chrooted environments as well. It can be used stand-alone, or as
+part of a networked, distributed build environment. As the latter, it is part
+of the system used by porters to build binary packages for all the available
+architectures. See <xref linkend="buildd"/> for more information, and <ulink
+url="&url-buildd;"></ulink> to see the system in action.
+</para>
+</section>
+
+</section>
+
+<section id="uploaders">
+<title>Package uploaders</title>
+<para>
+The following packages help automate or simplify the process of uploading
+packages into the official archive.
+</para>
+<section id="dupload">
+<title><systemitem role="package">dupload</systemitem></title>
+<para>
+<systemitem role="package">dupload</systemitem> is a package and a script to
+automatically upload Debian packages to the Debian archive, to log the upload,
+and to send mail about the upload of a package. You can configure it for new
+upload locations or methods.
+</para>
+</section>
+
+<section id="dput">
+<title><systemitem role="package">dput</systemitem></title>
+<para>
+The <systemitem role="package">dput</systemitem> package and script does much
+the same thing as <systemitem role="package">dupload</systemitem>, but in a
+different way. It has some features over <systemitem
+role="package">dupload</systemitem>, such as the ability to check the GnuPG
+signature and checksums before uploading, and the possibility of running
+<command>dinstall</command> in dry-run mode after the upload.
+</para>
+</section>
+
+<section id="dcut">
+<title><systemitem role="package">dcut</systemitem></title>
+<para>
+The <systemitem role="package">dcut</systemitem> script (part of the package
+<xref linkend="dput"/> ) helps in removing files from the ftp upload directory.
+</para>
+</section>
+
+</section>
+
+<section id="tools-maint-automate">
+<title>Maintenance automation</title>
+<para>
+The following tools help automate different maintenance tasks, from adding
+changelog entries or signature lines and looking up bugs in Emacs to making use
+of the newest and official <filename>config.sub</filename>.
+</para>
+<section id="devscripts">
+<title><systemitem role="package">devscripts</systemitem></title>
+<para>
+<systemitem role="package">devscripts</systemitem> is a package containing
+wrappers and tools which are very helpful for maintaining your Debian packages.
+Example scripts include <command>debchange</command> and
+<command>dch</command>, which manipulate your
+<filename>debian/changelog</filename> file from the command-line, and
+<command>debuild</command>, which is a wrapper around
+<command>dpkg-buildpackage</command>. The <command>bts</command> utility is
+also very helpful to update the state of bug reports on the command line.
+<command>uscan</command> can be used to watch for new upstream versions of your
+packages. <command>debrsign</command> can be used to remotely sign a package
+prior to upload, which is nice when the machine you build the package on is
+different from where your GPG keys are.
+</para>
+<para>
+See the <citerefentry> <refentrytitle>devscripts</refentrytitle>
+<manvolnum>1</manvolnum> </citerefentry> manual page for a complete list of
+available scripts.
+</para>
+</section>
+
+<section id="autotools-dev">
+<title><systemitem role="package">autotools-dev</systemitem></title>
+<para>
+<systemitem role="package">autotools-dev</systemitem> contains best practices
+for people who maintain packages which use <command>autoconf</command> and/or
+<command>automake</command>. Also contains canonical
+<filename>config.sub</filename> and <filename>config.guess</filename> files
+which are known to work on all Debian ports.
+</para>
+</section>
+
+<section id="dpkg-repack">
+<title><systemitem role="package">dpkg-repack</systemitem></title>
+<para>
+<command>dpkg-repack</command> creates Debian package file out of a package
+that has already been installed. If any changes have been made to the package
+while it was unpacked (e.g., files in <filename>/etc</filename> were modified),
+the new package will inherit the changes.
+</para>
+<para>
+This utility can make it easy to copy packages from one computer to another, or
+to recreate packages which are installed on your system but no longer available
+elsewhere, or to save the current state of a package before you upgrade it.
+</para>
+</section>
+
+<section id="alien">
+<title><systemitem role="package">alien</systemitem></title>
+<para>
+<command>alien</command> converts binary packages between various packaging
+formats, including Debian, RPM (RedHat), LSB (Linux Standard Base), Solaris,
+and Slackware packages.
+</para>
+</section>
+
+<section id="debsums">
+<title><systemitem role="package">debsums</systemitem></title>
+<para>
+<command>debsums</command> checks installed packages against their MD5 sums.
+Note that not all packages have MD5 sums, since they aren't required by Policy.
+</para>
+</section>
+
+<section id="dpkg-dev-el">
+<title><systemitem role="package">dpkg-dev-el</systemitem></title>
+<para>
+<systemitem role="package">dpkg-dev-el</systemitem> is an Emacs lisp package
+which provides assistance when editing some of the files in the
+<filename>debian</filename> directory of your package. For instance, there are
+handy functions for listing a package's current bugs, and for finalizing the
+latest entry in a <filename>debian/changelog</filename> file.
+</para>
+</section>
+
+<section id="dpkg-depcheck">
+<title><systemitem role="package">dpkg-depcheck</systemitem></title>
+<para>
+<command>dpkg-depcheck</command> (from the <systemitem
+role="package">devscripts</systemitem> package, <xref linkend="devscripts"/> )
+runs a command under <command>strace</command> to determine all the packages
+that were used by the said command.
+</para>
+<para>
+For Debian packages, this is useful when you have to compose a
+<literal>Build-Depends</literal> line for your new package: running the build
+process through <command>dpkg-depcheck</command> will provide you with a good
+first approximation of the build-dependencies. For example:
+</para>
+<screen>
+dpkg-depcheck -b debian/rules build
+</screen>
+<para>
+<command>dpkg-depcheck</command> can also be used to check for run-time
+dependencies, especially if your package uses exec(2) to run other programs.
+</para>
+<para>
+For more information please see <citerefentry>
+<refentrytitle>dpkg-depcheck</refentrytitle> <manvolnum>1</manvolnum>
+</citerefentry>.
+</para>
+</section>
+
+</section>
+
+<section id="tools-porting">
+<title>Porting tools</title>
+<para>
+The following tools are helpful for porters and for cross-compilation.
+</para>
+<section id="quinn-diff">
+<title><systemitem role="package">quinn-diff</systemitem></title>
+<para>
+<systemitem role="package">quinn-diff</systemitem> is used to locate the
+differences from one architecture to another. For instance, it could tell you
+which packages need to be ported for architecture <replaceable>Y</replaceable>,
+based on architecture <replaceable>X</replaceable>.
+</para>
+</section>
+
+<section id="dpkg-cross">
+<title><systemitem role="package">dpkg-cross</systemitem></title>
+<para>
+<systemitem role="package">dpkg-cross</systemitem> is a tool for installing
+libraries and headers for cross-compiling in a way similar to <systemitem
+role="package">dpkg</systemitem>. Furthermore, the functionality of
+<command>dpkg-buildpackage</command> and <command>dpkg-shlibdeps</command> is
+enhanced to support cross-compiling.
+</para>
+</section>
+
+</section>
+
+<section id="tools-doc">
+<title>Documentation and information</title>
+<para>
+The following packages provide information for maintainers or help with
+building documentation.
+</para>
+<section id="debiandoc-sgml">
+<title><systemitem role="package">debiandoc-sgml</systemitem></title>
+<para>
+<systemitem role="package">debiandoc-sgml</systemitem> provides the DebianDoc
+SGML DTD, which is commonly used for Debian documentation. This manual, for
+instance, is written in DebianDoc. It also provides scripts for building and
+styling the source to various output formats.
+</para>
+<para>
+Documentation for the DTD can be found in the <systemitem
+role="package">debiandoc-sgml-doc</systemitem> package.
+</para>
+</section>
+<!-- TODO: Maybe better:
+<section id="docbook-xml">
+<title><systemitem role="package">docbook-xml</systemitem></title>
+<para>
+<systemitem role="package">docbook-xml</systemitem> provides the
+DocBook XML DTDs, which are commonly used for Debian documentation (as
+is the older debiandoc SGML DTD). This manual, for instance, is written
+in DocBook XML. The <systemitem
+role="package">docbook-xsl</systemitem> package provides the XSL files
+for building and styling the source to various output formats. You
+will need an XSLT processor, such as <systemitem
+role="package">xsltproc</systemitem>, and an FO processor, such as
+<systemitem role="package">fop</systemitem>, to generate documentation.
+</para>
+</section>
+-->
+
+<section id="debian-keyring">
+<title><systemitem role="package">debian-keyring</systemitem></title>
+<para>
+Contains the public GPG and PGP keys of Debian developers. See <xref
+linkend="key-maint"/> and the package documentation for more information.
+</para>
+</section>
+
+<section id="debview">
+<title><systemitem role="package">debview</systemitem></title>
+<para>
+<systemitem role="package">debview</systemitem> provides an Emacs mode for
+viewing Debian binary packages. This lets you examine a package without
+unpacking it.
+</para>
+</section>
+
+</section>
+<!-- FIXME: add the following
+
+questionable:
+ dbs (referred to above)
+ dpatch (referred to above)
+ debarchiver
+ ucf
+ dpkg-awk
+ grep-dctrl
+ d-shlibs
+ wajig
+ magpie
+ apt-dpkg-ref
+ apt-show-source
+ apt-show-versions
+ pdbv
+ epm
+ apt-src
+ apt-build
+
+rejected:
+ debaux: too new, unmaintained?
+ dh-make-perl: too new, unmaintained?
+-->
+</appendix>
+++ /dev/null
-#!/usr/bin/perl -w
-
-# This script checks if the translations of the documents are up to date.
-# When called with "-d" option, it also prints what has changed in the
-# original since last translation
-
-# SYNOPSIS:
-# ./translation-status [-d] [-v] [lang]
-#
-# (uses $lang set below if lang is not given on commandline)
-
-use Getopt::Std;
-$opt_d = $opt_v = 0;
-getopts('dv');
-# You may set this to your default language code
-$lang = shift || "fr";
-
-sub checkdiff {
- my ($plfname, $enfname) = (@_);
- my ($plrev, $enrev) = getrev($plfname, $enfname);
- $plrev and $enrev or return;
- if ( "$plrev" ne "$enrev" ) {
- if ($opt_d) {
- my $s = "cvs diff -b -u -r $plrev -r $enrev $enfname";
- warn "running $s:\n" if ($opt_v);
- system($s);
- } else {
- print "$enfname : $plrev -> $enrev\n";
- }
- }
-}
-
-sub getrev {
- my ($plfname, $enfname) = (@_);
- my ($plrev, $enrev) = (0, 0);
-
- warn "checking $plfname:\n" if $opt_v;
- open FILE, $plfname or warn "$plfname: $!\n" and return;
- while (<FILE>) {
- if (/<!entity\s*cvs-en-rev\s*"([\d\.]+)"/i) {
- $plrev = $1;
- last;
- }
- }
- warn "checking $enfname:\n" if $opt_v;
- open FILE, $enfname or warn "$enfname: $!\n" and return;
- while (<FILE>) {
- if (/\$Id: [^\s]+ ([\d\.]+) .* Exp \$/) {
- $enrev = $1;
- last;
- }
- if (/\$Revision: ([\d\.]+) \$/) {
- $enrev = $1;
- last;
- }
- }
- close FILE;
- warn "failed to find revision for $plfname\n" unless $plrev;
- warn "failed to find revision for $enfname\n" unless $enrev;
- return ($plrev, $enrev);
-}
-
-checkdiff("developers-reference.$lang.sgml", "developers-reference.sgml");
--- /dev/null
+<?xml version="1.0"?>
+<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
+ version="1.0">
+ <xsl:import
+ href="http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl"/>
+ <xsl:param name="section.autolabel">1</xsl:param>
+ <xsl:param name="section.label.includes.component.label">1</xsl:param>
+ <xsl:param name="generate.toc">
+ appendix title
+ article/appendix nop
+ article toc,title
+ book toc,title,figure,table,example,equation
+ chapter title
+ part toc,title
+ preface toc,title
+ qandadiv toc
+ qandaset toc
+ reference toc,title
+ sect1 toc
+ sect2 toc
+ sect3 toc
+ sect4 toc
+ sect5 toc
+ section toc
+ set toc,title
+ </xsl:param>
+</xsl:stylesheet>
~ianmdlvl / developers-reference.git / commitdiff