From 8a77d09ebb4f5b985db6da174892a3a66d5aa272 Mon Sep 17 00:00:00 2001 From: debacle Date: Tue, 26 Jun 2007 17:46:56 +0000 Subject: [PATCH 1/1] First files for developers-reference in DocBook XML plus translation file using po4a. git-svn-id: svn://anonscm.debian.org/ddp/developers-reference/trunk@4902 313b444b-1b9f-4f58-a734-7bb04f332e8d --- Makefile | 133 + README-contrib | 71 + best-pkging-practices.dbk | 1750 +++++++++++ beyond-pkging.dbk | 388 +++ debian/TODO | 21 + debian/changelog | 1392 +++++++++ debian/compat | 1 + debian/control | 41 + debian/copyright | 29 + debian/developers-reference-fr.doc-base | 17 + debian/developers-reference-ja.doc-base | 14 + debian/developers-reference.doc-base | 20 + debian/rules | 106 + debian/tocsubstvars | 37 + developer-duties.dbk | 212 ++ index.dbk | 101 + l10n.dbk | 238 ++ new-maintainer.dbk | 217 ++ pkgs.dbk | 2608 +++++++++++++++++ po4a/fr/best-pkging-practices.po | 2506 ++++++++++++++++ po4a/fr/beyond-pkging.po | 572 ++++ po4a/fr/developer-duties.po | 314 ++ po4a/fr/index.po | 87 + po4a/fr/l10n.po | 342 +++ po4a/fr/new-maintainer.po | 333 +++ po4a/fr/pkgs.po | 3519 +++++++++++++++++++++++ po4a/fr/resources.po | 1995 +++++++++++++ po4a/fr/scope.po | 72 + po4a/fr/tools.po | 654 +++++ po4a/ja/best-pkging-practices.po | 2506 ++++++++++++++++ po4a/ja/beyond-pkging.po | 572 ++++ po4a/ja/developer-duties.po | 314 ++ po4a/ja/index.po | 87 + po4a/ja/l10n.po | 342 +++ po4a/ja/new-maintainer.po | 333 +++ po4a/ja/pkgs.po | 3519 +++++++++++++++++++++++ po4a/ja/resources.po | 1995 +++++++++++++ po4a/ja/scope.po | 72 + po4a/ja/tools.po | 654 +++++ po4a/po/best-pkging-practices.pot | 2506 ++++++++++++++++ po4a/po/beyond-pkging.pot | 572 ++++ po4a/po/developer-duties.pot | 314 ++ po4a/po/index.pot | 87 + po4a/po/l10n.pot | 342 +++ po4a/po/new-maintainer.pot | 333 +++ po4a/po/pkgs.pot | 3519 +++++++++++++++++++++++ po4a/po/resources.pot | 1995 +++++++++++++ po4a/po/scope.pot | 72 + po4a/po/tools.pot | 654 +++++ resources.dbk | 1531 ++++++++++ scope.dbk | 41 + tools.dbk | 543 ++++ 52 files changed, 40693 insertions(+) create mode 100644 Makefile create mode 100644 README-contrib create mode 100644 best-pkging-practices.dbk create mode 100644 beyond-pkging.dbk create mode 100644 debian/TODO create mode 100644 debian/changelog create mode 100644 debian/compat create mode 100644 debian/control create mode 100644 debian/copyright create mode 100644 debian/developers-reference-fr.doc-base create mode 100644 debian/developers-reference-ja.doc-base create mode 100644 debian/developers-reference.doc-base create mode 100755 debian/rules create mode 100755 debian/tocsubstvars create mode 100644 developer-duties.dbk create mode 100644 index.dbk create mode 100644 l10n.dbk create mode 100644 new-maintainer.dbk create mode 100644 pkgs.dbk create mode 100644 po4a/fr/best-pkging-practices.po create mode 100644 po4a/fr/beyond-pkging.po create mode 100644 po4a/fr/developer-duties.po create mode 100644 po4a/fr/index.po create mode 100644 po4a/fr/l10n.po create mode 100644 po4a/fr/new-maintainer.po create mode 100644 po4a/fr/pkgs.po create mode 100644 po4a/fr/resources.po create mode 100644 po4a/fr/scope.po create mode 100644 po4a/fr/tools.po create mode 100644 po4a/ja/best-pkging-practices.po create mode 100644 po4a/ja/beyond-pkging.po create mode 100644 po4a/ja/developer-duties.po create mode 100644 po4a/ja/index.po create mode 100644 po4a/ja/l10n.po create mode 100644 po4a/ja/new-maintainer.po create mode 100644 po4a/ja/pkgs.po create mode 100644 po4a/ja/resources.po create mode 100644 po4a/ja/scope.po create mode 100644 po4a/ja/tools.po create mode 100644 po4a/po/best-pkging-practices.pot create mode 100644 po4a/po/beyond-pkging.pot create mode 100644 po4a/po/developer-duties.pot create mode 100644 po4a/po/index.pot create mode 100644 po4a/po/l10n.pot create mode 100644 po4a/po/new-maintainer.pot create mode 100644 po4a/po/pkgs.pot create mode 100644 po4a/po/resources.pot create mode 100644 po4a/po/scope.pot create mode 100644 po4a/po/tools.pot create mode 100644 resources.dbk create mode 100644 scope.dbk create mode 100644 tools.dbk diff --git a/Makefile b/Makefile new file mode 100644 index 0000000..c3f5a82 --- /dev/null +++ b/Makefile @@ -0,0 +1,133 @@ +# Makefile, used for the DDP manuals.sgml area + +MANUAL := $(notdir $(shell pwd)) +PUBLISHDIR := /org/www.debian.org/www/doc/manuals + +SOURCES := $(wildcard *.sgml) + +LANGS := fr +TARGETS := $(foreach fmt,html txt pdf,developers-reference.$(fmt)) \ + $(foreach langext,$(LANGS), \ + $(foreach fmt,html txt pdf,developers-reference.$(langext).$(fmt))) + +# programs for creating output +DEBIANDOC2HTML := debiandoc2html -c +DEBIANDOC2TEXT := debiandoc2text +DEBIANDOC2LATEX := debiandoc2latex +DEBIANDOC2PS := debiandoc2latexps +DEBIANDOC2PDF := debiandoc2latexpdf + +htmllink := echo "" > dynamic.ent +nohtmllink := echo "" > 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 + + +.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) + +.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 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: diff --git a/README-contrib b/README-contrib new file mode 100644 index 0000000..226b5a9 --- /dev/null +++ b/README-contrib @@ -0,0 +1,71 @@ +* Useful Makefile targets + +The following 'make' targets exist for your convenience: + + make validate + validate the well-formedness of all SGML materials + + make all + build all languages in all formats + + make developers-reference.sgml.validate + validate the well-formedness of the English manual + + make developers-reference.html + build the English manual + + +* Contacting + +To contain the maintainers of this package, email +. + + +* Contributing + +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. + +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. + + +* CVS + +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 +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 +. + + +* Translators + +We have tried to keep language-independant bits of text in common.ent. +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 + + diff --git a/best-pkging-practices.dbk b/best-pkging-practices.dbk new file mode 100644 index 0000000..f1130c2 --- /dev/null +++ b/best-pkging-practices.dbk @@ -0,0 +1,1750 @@ + + + +Best Packaging Practices + +Debian's quality is largely due to the 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. + + +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. + +
+Best practices for <filename>debian/rules</filename> + +The following recommendations apply to the debian/rules +file. Since debian/rules 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. + +
+Helper scripts + +The rationale for using helper scripts in debian/rules 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 /usr/lib/menu (or /usr/lib/menu +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. + + +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. + + + contains a couple of different helpers. The most +common and best (in our opinion) helper system is debhelper. Previous helper systems, such as +debmake, 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. debhelper, +however, is a number of separate little dh_* programs. For +instance, dh_installman installs and compresses man pages, +dh_installmenu 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 +debian/rules. + + +You can get started with debhelper by +reading debhelper +1 , and looking at the examples that come +with the package. dh_make, from the dh-make package (see ), +can be used to convert a vanilla source package to a debhelperized package. This shortcut, though, +should not convince you that you do not need to bother understanding the +individual dh_* 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. + + +Some people feel that vanilla debian/rules 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 debian/rules files are available at . + +
+ +
+Separating your patches into multiple files + +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 .diff.gz) and work out which patch sets +to back out as a unit as bugs are fixed upstream. + + +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 +(.diff.gz), usually within the +debian/ directory. The only difference is that they +aren't applied immediately by dpkg-source, but by the build +rule of debian/rules. Conversely, they are reverted in +the clean rule. + + +dbs 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 dbs for more +information and hello-dbs for an +example. + + +dpatch also provides these facilities, but it's intended to +be even easier to use. See the package dpatch for documentation and examples (in +/usr/share/doc/dpatch). + +
+ +
+Multiple binary packages + +A single source package will often build several binary packages, either to +provide several flavors of the same software (e.g., the vim 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). + + +The second case can be easily managed in debian/rules. +You just need to move the appropriate files from the build directory into the +package's temporary trees. You can do this using install or +dh_install from debhelper. Be sure to check the different +permutations of the various packages, ensuring that you have the inter-package +dependencies set right in debian/control. + + +The first case is a bit more difficult since it involves multiple recompiles of +the same software but with different configuration options. The vim source package is an example of how to manage +this using an hand-crafted debian/rules file. + +
+ +
+ +
+Best practices for <filename>debian/control</filename> + +The following practices are relevant to the debian/control +file. They supplement the Policy +on package descriptions. + + +The description of the package, as defined by the corresponding field in the +control file, contains both the package synopsis and the +long description for the package. describes +common guidelines for both parts of the package description. Following that, + provides guidelines specific to the +synopsis, and contains guidelines specific to +the description. + +
+General guidelines for package descriptions + +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. + + +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. + + +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. + + +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. + + +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. + + +If you are having problems writing your description, you may wish to send it +along to debian-l10n-english@lists.debian.org and request +feedback. + +
+ +
+The package synopsis, or short description + +The synopsis line (the short description) should be concise. It must not +repeat the package's name (this is policy). + + +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). + + +It might help to imagine that the synopsis is combined with the package name in +the following way: + + +package-name is a synopsis. + + +Alternatively, it might make sense to think of it as + + +package-name is synopsis. + + +or, if the package name itself is a plural (such as developers-tools) + + +package-name are synopsis. + + +This way of forming a sentence from the package name and synopsis should be +considered as a heuristic and not a strict rule. There are some cases where it +doesn't make sense to try to form a sentence. + +
+ +
+The long description + +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. + + +The long description should consist of full and complete sentences. + + +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. + + +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)? + + +Be careful to avoid spelling and grammar mistakes. Ensure that you spell-check +it. Both ispell and aspell have special +modes for checking debian/control files: + + + -d american -g debian/control + + + -d en -D -c debian/control + + +Users usually expect these questions to be answered in the package description: + + + + +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. + + + + +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). + + + + +If this package should not be installed directly, but is pulled in by another +package, this should be mentioned. + + + + +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. + + + + +How is this package different from the competition? Is it a better +implementation? more features? different features? Why should I choose this +package. + + + +
+ +
+Upstream home page + +We recommend that you add the URL for the package's home page to the package +description in debian/control. This information should be +added at the end of description, using the following format: + + + . + Homepage: http://some-project.some-place.org/ + + +Note the spaces prepending the line, which serves to break the lines correctly. +To see an example of how this displays, see . + + +If there is no home page for the software, this should naturally be left out. + + +Note that we expect this field will eventually be replaced by a proper +debian/control field understood by dpkg +and packages.debian.org. 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 /^ Homepage: [^ ]*$/, as this allows +packages.debian.org to parse it correctly. + +
+ +
+Version Control System location + +There are additional fields for the location of the Version Control System in +debian/control. + +
+XS-Vcs-Browser + +Value of this field should be a http:// URL pointing to a +web-browsable copy of the Version Control System repository used to maintain +the given package, if available. + + +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 pending in the bug tracking system). + +
+ +
+XS-Vcs-* + +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. * identify the Version Control System; currently +the following systems are supported by the package tracking system: +arch, bzr (Bazaar), +cvs, darcs, git, +hg (Mercurial), mtn (Monotone), +svn (Subversion). It is allowed to specify different VCS +fields for the same package: they will all be shown in the PTS web interface. + + +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. + + +In the following example, an instance of the field for a Subversion repository +of the vim package is shown. Note how +the URL is in the svn:// scheme (instead of +svn+ssh://) and how it points to the +trunk/ branch. The use of the +XS-Vcs-Browser field described above is also shown. + + + Source: vim + Section: editors + Priority: optional + <snip> + XS-Vcs-Svn: svn://svn.debian.org/svn/pkg-vim/trunk/packages/vim + XS-Vcs-Browser: http://svn.debian.org/wsvn/pkg-vim/trunk/packages/vim + +
+ +
+ +
+ +
+Best practices for <filename>debian/changelog</filename> + +The following practices supplement the Policy +on changelog files. + +
+Writing useful changelog entries + +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. + + +Focus on what 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). + + +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 README.Debian file. + + +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. + + +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. + + +When referring to bugs, don't assume anything. Say what the problem was, how +it was fixed, and append the closes: #nnnnn string. See for more information. + +
+ +
+Common misconceptions about changelog entries + +The changelog entries should not 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. + + +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 . + + +The changelog entries should not 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 + for more information on how to use the bug +tracking system. + + +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. + +
+ +
+Common errors in changelog entries + +The following examples demonstrate some common errors or examples of bad style +in changelog entries. + + + * Fixed all outstanding bugs. + + +This doesn't tell readers anything too useful, obviously. + + + * Applied patch from Jane Random. + + +What was the patch about? + + + * Late night install target overhaul. + + +Overhaul which accomplished what? Is the mention of late night supposed to +remind us that we shouldn't trust that code? + + + * Fix vsync FU w/ ancient CRTs. + + +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. + + + * This is not a bug, closes: #nnnnnn. + + +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. + + + * Has been fixed for ages, but I forgot to close; closes: #54321. + + +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). + + + * Closes: #12345, #12346, #15432 + + +Where's the description? If you can't think of a descriptive message, start by +inserting the title of each different bug. + +
+ +
+Supplementing changelogs with NEWS.Debian files + +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. + + +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: + + + (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 + + +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. + + +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! + +
+ +
+ +
+Best practices for maintainer scripts + +Maintainer scripts include the files debian/postinst, +debian/preinst, debian/prerm and +debian/postrm. 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 +Debian Policy. + + +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. + + +Standard input and output may be redirected (e.g. into pipes) for logging +purposes, so don't rely on them being a tty. + + +All prompting or interactive configuration should be kept to a minimum. When +it is necessary, you should use the debconf package for the interface. Remember that +prompting in any case can only be in the configure stage of +the postinst script. + + +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 debhelper to easily add bits to the scripts. + + +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. + + +If you need to check for the existence of a command, you should use something +like + + + [ -x /usr/sbin/install-docs ]; then ... + + +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: + + +() { + OLDIFS=$IFS + IFS=: + for p in $PATH; do + if [ -x $p/$* ]; then + IFS=$OLDIFS + return 0 + fi + done + IFS=$OLDIFS + return 1 +} + + +You can use this function to search $PATH 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 command +-v, type, and which are not +POSIX. + + +While which is an acceptable alternative, since it is from +the required debianutils package, it's +not on the root partition. That is, it's in /usr/bin +rather than /bin, so one can't use it in scripts which are +run before the /usr partition is mounted. Most scripts +won't have this problem, though. + +
+ +
+Configuration management with <systemitem role="package">debconf</systemitem> + +Debconf is a configuration management +system which can be used by all the various packaging scripts +(postinst mainly) to request feedback from the user +concerning how to configure the package. Direct user interactions must now be +avoided in favor of debconf +interaction. This will enable non-interactive installations in the future. + + +Debconf is a great tool but it is often poorly used. Many common mistakes are +listed in the debconf-devel +7 man page. It is something that you +must read if you decide to use debconf. Also, we document some best practices +here. + + +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). + +
+Do not abuse debconf + +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. + + +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. + + +Carefully choose the questions priorities in maintainer scripts. See + debconf-devel +7 for details about priorities. Most +questions should use medium and low priorities. + +
+ +
+General recommendations for authors and translators +
+Write correct English + +Most Debian package maintainers are not native English speakers. So, writing +properly phrased templates may not be easy for them. + + +Please use (and abuse) debian-l10n-english@lists.debian.org +mailing list. Have your templates proofread. + + +Badly written templates give a poor image of your package, of your work...or +even of Debian itself. + + +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. + +
+ +
+Be kind to translators + +Debconf templates may be translated. Debconf, along with its sister package +po-debconf offers a simple framework for getting templates +translated by translation teams or even individuals. + + +Please use gettext-based templates. Install po-debconf on your development system and read its +documentation (man po-debconf is a good start). + + +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. + + +The use of the podebconf-report-po from the po-debconf +package is highly recommended to warn translators which have incomplete +translations and request them for updates. + + +If in doubt, you may also contact the translation team for a given language +(debian-l10n-xxxxx@lists.debian.org), or the +debian-i18n@lists.debian.org mailing list. + + +Calls for translations posted to debian-i18n@lists.debian.org +with the debian/po/templates.pot 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. + +
+ +
+Unfuzzy complete translations when correcting typos and spelling + +When the text of a debconf template is corrected and you are sure that the change does not affect translations, please be kind to translators +and unfuzzy their translations. + + +If you don't do so, the whole template will not be translated as long as a +translator will send you an update. + + +To unfuzzy translations, you can proceed the +following way: + + + + +Put all incomplete PO files out of the way. You can check the completeness by +using (needs the gettext package +installed): + + + i in debian/po/*po; do echo -n $i: ; msgfmt -o /dev/null +--statistics $i; done + + + + +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. + + + + +now and now only, modify the template for +the typos and check again that translation are not impacted (typos, spelling +errors, sometimes typographical corrections are usually OK) + + + + +run debconf-updatepo. This will fuzzy all strings you +modified in translations. You can see this by running the above again + + + + +use the following command: + + + i in debian/po/*po; do msgattrib --output-file=$i --clear-fuzzy $i; done + + + + +move back to debian/po the files which showed fuzzy strings in the first step + + + + +run debconf-updatepo again + + + +
+ +
+Do not make assumptions about interfaces + +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. + + +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). + + +More generally speaking, try to avoid referring to user actions. Just give +facts. + +
+ +
+Do not use first person + +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 .... + +
+ +
+Be gender neutral + +The world is made of men and women. Please use gender-neutral constructions in +your writing. + +
+ +
+ +
+Templates fields definition + +This part gives some information which is mostly taken from the +debconf-devel 7 + manual page. + +
+Type +
+string: + +Results in a free-form input field that the user can type any string into. + +
+ +
+password: + +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. + +
+ +
+boolean: + +A true/false choice. Remember: true/false, not +yes/no... + +
+ +
+select: + +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 + +
+ +
+multiselect: + +Like the select data type, except the user can choose any number of items from +the choices list (or chose none of them). + +
+ +
+note: + +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. + +
+ +
+text: + +This type is now considered obsolete: don't use it. + +
+ +
+error: + +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). + + +It is recommended to use this type for any message that needs user attention +for a correction of any kind. + +
+ +
+ +
+Description: short and extended description + +Template descriptions have two parts: short and extended. The short +description is in the Description: line of the template. + + +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. + + +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? + + +The short description does not necessarily have to be a full sentence. This is +part of the keep it short and efficient recommendation. + + +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. + + +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. + + +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. + + +The extended description should never +include a question. + + +For specific rules depending on templates type (string, boolean, etc.), please +read below. + +
+ +
+Choices + +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. + +
+ +
+Default + +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. + +
+ +
+ +
+Templates fields specific style guide +
+Type field + +No specific indication except: use the appropriate type by referring to the +previous section. + +
+ +
+Description field + +Below are specific instructions for properly writing the Description (short and +extended) depending on the template type. + +
+String/password templates + + + +The short description is a prompt and not a +title. Avoid question style prompts (IP Address?) in favour of opened prompts +(IP address:). The use of colons is recommended. + + + + +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. + + + +
+ +
+Boolean templates + + + +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) + + + + +Again, please avoid referring to specific interface widgets. A common mistake +for such templates is if you answer Yes-type constructions. + + + +
+ +
+Select/Multiselect + + + +The short description is a prompt and not a +title. Do not use useless Please choose... +constructions. Users are clever enough to figure out they have to choose +something...:) + + + + +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). + + + +
+ +
+Notes + + + +The short description should be considered to be a *title*. + + + + +The extended description is what will be displayed as a more detailed +explanation of the note. Phrases, no terse writing style. + + + + +Do not abuse debconf. 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. + + + +
+ +
+ +
+Choices field + +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. + +
+ +
+Default field + +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. + + +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. + + +Example, taken from the geneweb package templates: + + +: 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: + + +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. + + +The comments are needed as the DefaultChoice trick is a bit confusing: the +translators may put their own choice + +
+ +
+Default field + +Do NOT use empty default field. If you don't want to use default values, do +not use Default at all. + + +If you use po-debconf (and you should, see +2.2), consider making this field translatable, if you think it may be +translated. + + +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 po-debconf +7 ). + +
+ +
+ +
+ +
+Internationalization +
+Handling debconf translations + +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. + + +The goal of debconf was to make +packages configuration easier for maintainers and for users. Originally, +translation of debconf templates was handled with +debconf-mergetemplate. However, that technique is now +deprecated; the best way to accomplish debconf internationalization is by using the +po-debconf package. This method is +easier both for maintainer and translators; transition scripts are provided. + + +Using po-debconf, the translation is +stored in po files (drawing from +gettext 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 +debconf-updatepo, the translation is marked as needing +attention from the translators. Then, at build time, the +dh_installdebconf 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 +po-debconf 7 + manual page for details. + +
+ +
+Internationalized documentation + +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. + + +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 doc-check in the boot-floppies 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. + + +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. + +
+ +
+ +
+Common packaging situations +
+Packages using <command>autoconf</command>/<command>automake</command> + +Keeping autoconf's config.sub and +config.guess files up to date is critical for porters, +especially on more volatile architectures. Some very good packaging practices +for any package using autoconf and/or +automake have been synthesized in +/usr/share/doc/autotools-dev/README.Debian.gz from the +autotools-dev package. You're strongly +encouraged to read this file and to follow the given recommendations. + +
+ +
+Libraries + +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. + + +Good practices for library packaging have been grouped in the library +packaging guide. + +
+ +
+Documentation + +Be sure to follow the Policy on +documentation. + + +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. + + +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. + + +Major shipped manuals should register themselves with doc-base on installation. See the doc-base package documentation for more +information. + +
+ +
+Specific types of packages + +Several specific types of packages have special sub-policies and corresponding +packaging rules and practices: + + + + +Perl related packages have a Perl +policy, some examples of packages following that policy are libdbd-pg-perl (binary perl module) or libmldbm-perl (arch independent perl module). + + + + +Python related packages have their python policy; see +/usr/share/doc/python/python-policy.txt.gz in the +python package. + + + + +Emacs related packages have the emacs +policy. + + + + +Java related packages have their java +policy. + + + + +Ocaml related packages have their own policy, found in +/usr/share/doc/ocaml/ocaml_packaging_policy.gz from the +ocaml package. A good example is the +camlzip source package. + + + + +Packages providing XML or SGML DTDs should conform to the recommendations found +in the sgml-base-doc package. + + + + +Lisp packages should register themselves with common-lisp-controller, about which see +/usr/share/doc/common-lisp-controller/README.packaging. + + + +
+ +
+Architecture-independent data + +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. + + +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 +Packages files, it saves a lot of disk space on Debian +mirrors. Separating out architecture-independent data also reduces processing +time of lintian or linda (see ) when run over the entire Debian archive. + +
+ +
+Needing a certain locale during build + +If you need a certain locale during build, you can create a temporary file via +this trick: + + +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: + + +=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 + +
+ +
+Make transition packages deborphan compliant + +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. + + +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. + + +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: + + +-cache search .|grep dummy + + +or + + +-cache search .|grep transitional + + +. + +
+ +
+Best practices for <filename>orig.tar.gz</filename> files + +There are two kinds of original source tarballs: Pristine source and repackaged +upstream source. + +
+Pristine source + +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. 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 currently +distributing at any point in time. All that can be expected is that it is +identical to something that upstream once did distribute. +If a difference arises later (say, if upstream notices that he wasn't using +maximal comression in his original distribution and then +re-gzips 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. 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. + + +There is no universally accepted guidelines that upstream authors follow +regarding to the directory structure inside their tarball, but +dpkg-source is nevertheless able to deal with most upstream +tarballs as pristine source. Its strategy is equivalent to the following: + + + + +It unpacks the tarball in an empty temporary directory by doing + + + path/to/<packagename>_<upstream-version>.orig.tar.gz | tar xf - + + + + +If, after this, the temporary directory contains nothing but one directory and +no other files, dpkg-source renames that directory to +<packagename>-<upstream-version>(.orig). The +name of the top-level directory in the tarball does not matter, and is +forgotten. + + + + +Otherwise, the upstream tarball must have been packaged without a common +top-level directory (shame on the upstream author!). In this case, +dpkg-source renames the temporary directory +itself to +<packagename>-<upstream-version>(.orig). + + + +
+ +
+Repackaged upstream source + +You should 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. + + +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 +.diff.gz and still has a version number composed of +<upstream-version> and +<debian-revision>. + + +There may be cases where it is desirable to repackage the source even though +upstream distributes a .tar.gz that could in principle be +used in its pristine form. The most obvious is if +significant 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. + + +A repackaged .orig.tar.gz + + + + +must contain detailed information how the +repackaged source was obtained, and how this can be reproduced in the +debian/copyright. It is also a good idea to provide a +get-orig-source target in your +debian/rules file that repeats the process, as described +in the Policy Manual, Main +building script: debian/rules. + + + + +should not contain any file that does not +come from the upstream author(s), or whose contents has been changed by you. + 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. + + + + +should, 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 debian/rules does is to overwrite it by running a +configure script. + + +(Rationale: 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). + + + + +should use +<packagename>-<upstream-version>.orig as the +name of the top-level directory in its tarball. This makes it possible to +distinguish pristine tarballs from repackaged ones. + + + + +should be gzipped with maximal compression. + + + + +The canonical way to meet the latter two points is to let dpkg-source +-b construct the repackaged tarball from an unpacked directory. + +
+ +
+Changing binary files in <literal>diff.gz</literal> + +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, +dpkg-source 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 orig.tar.gz. Instead, +include the file in the debian directory in +uuencoded (or similar) form 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 sharutils to get the uudecode +program if you use perl's pack function. +The code could look like -file: perl -ne 'print(pack u, $$_);' +$(file) > $(file).uuencoded uudecode-file: perl -ne 'print(unpack u, $$_);' +$(file).uuencoded > $(file) . The file would then be +decoded and copied to its place during the build process. Thus the change will +be visible quite easy. + + +Some packages use dbs to manage patches to their upstream +source, and always create a new orig.tar.gz file that +contains the real orig.tar.gz 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 orig.tar.gz file, besides the +real one, and copy them to the right place during the build process. + +
+ +
+ +
+Best practices for debug packages + +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. + + +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. + + +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 /usr/lib/debug/path, where +path is the path to the executable or library. For +example, debugging symbols for /usr/bin/foo go in +/usr/lib/debug/usr/bin/foo, and debugging symbols for +/usr/lib/libfoo.so.1 go in +/usr/lib/debug/usr/lib/libfoo.so.1. + + +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. + objcopy 1 + explains in detail how this works. + + +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. + + +Note that the Debian package should depend on the package that it provides +debugging symbols for, and this dependency should be versioned. For example: + + +: libfoo-dbg (= ${binary:Version}) + +
+ +
+ + + diff --git a/beyond-pkging.dbk b/beyond-pkging.dbk new file mode 100644 index 0000000..ffbfd3a --- /dev/null +++ b/beyond-pkging.dbk @@ -0,0 +1,388 @@ + + + +Beyond Packaging + +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. + + +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. + +
+Bug reporting + +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. + + +Read the instructions for +reporting bugs in the Debian bug tracking system. + + +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. + + +You can use a tool like reportbug +1 to submit bugs. It can automate and +generally ease the process. + + +Make sure the bug is not already filed against a package. Each package has a +bug list easily reachable at +http://bugs.debian.org/packagename +Utilities like querybts +1 can also provide you with this +information (and reportbug will usually invoke +querybts before sending, too). + + +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 both of those packages in order to avoid filing +duplicate bug reports. + + +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). + + +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 +http://bugs.debian.org/from:<your-email-addr>. + +
+Reporting lots of bugs at once (mass bug filing) + +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 lintian so that an error or warning is emitted. + + +If you report more than 10 bugs on the same topic at once, it is recommended +that you send a message to debian-devel@lists.debian.org +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. + + +Please use the programms dd-list and if appropriate +whodepends (from the package devscripts) to generate a list +of all affected packages, and include the output in your mail to +debian-devel@lists.debian.org. + + +Note that when sending lots of bugs on the same subject, you should send the +bug report to maintonly@bugs.debian.org so that the bug report +is not forwarded to the bug distribution mailing list. + +
+ +
+ +
+Quality Assurance effort +
+Daily work + +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 ) as possible. If you do not find that possible, then you +should consider orphaning some of your packages (see ). 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 debian-qa@lists.debian.org or +debian-devel@lists.debian.org). At the same time, you can look +for co-maintainers (see ). + +
+ +
+Bug squashing parties + +From time to time the QA group organizes bug squashing parties to get rid of as +many problems as possible. They are announced on +debian-devel-announce@lists.debian.org 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). + + +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. + + +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. + + +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. + +
+ +
+ +
+Contacting other maintainers + +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. + + +Looking up the email address of the maintainer for the package can be +distracting. Fortunately, there is a simple email alias, +<package>@packages.debian.org, which provides a way to +email the maintainer, whatever their individual email address (or addresses) +may be. Replace <package> with the name of a source +or a binary package. + + +You may also be interested in contacting the persons who are subscribed to a +given source package via . You can do so +by using the <package>@packages.qa.debian.org email +address. + +
+ +
+Dealing with inactive and/or unreachable maintainers + +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. + + +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 mia-query. Use + + +-query --help + + +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. + + +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. + + +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: + + + + +The echelon information available through the 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. + + + + +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. + + + + +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. + + + + +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. + + +It is also allowed to post a query to +debian-devel@lists.debian.org, asking if anyone is aware of the +whereabouts of the missing maintainer. Please Cc: the person in question. + + +Once you have gathered all of this, you can contact +mia@qa.debian.org. 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. + + +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! + + +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. + + +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 +mia@qa.debian.org. + +
+ +
+Interacting with prospective Debian developers + +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. + +
+Sponsoring packages + +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. + + +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.) + + +Sponsoring merely by signing the upload or just recompiling is definitely not recommended. 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. + + +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. + +
+ +
+Managing sponsored packages + +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. + + +You cannot simply upload a binary .deb 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 .orig.tar.gz file that they're +providing. + + +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. + + +Once the package meets Debian standards, build and sign it with + + +-buildpackage -kKEY-ID + + +before uploading it to the incoming directory. Of course, you can also use any +part of your KEY-ID, as long as it's unique in your +secret keyring. + + +The Maintainer field of the control file and the +changelog should list the person who did the packaging, +i.e., the sponsoree. The sponsoree will therefore get all the BTS mail about +the package. + + +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. + + +You are encouraged to keep tabs on the package you sponsor using . + +
+ +
+Advocating new developers + +See the page about advocating a prospective +developer at the Debian web site. + +
+ +
+Handling new maintainer applications + +Please see Checklist for Application +Managers at the Debian web site. + +
+ +
+ + + diff --git a/debian/TODO b/debian/TODO new file mode 100644 index 0000000..4698bef --- /dev/null +++ b/debian/TODO @@ -0,0 +1,21 @@ +NMU -- sec "Source NMUs and the Bug Tracking System" should talk about +changelog entries -- dinstall works that out depending on whether the +maintainer in the control and changelog match. + +db/LDAP thing email gate @ + http://www.debian.org/Lists-Archives/debian-devel-9912/msg00627.html + +critique from herzog: +http://www.debian.org/vote/2002/platforms/raphael + + Robot101: do you have a URL describing new incoming system? + http://lists.debian.org/debian-devel-announce/2002/debian-devel-announce-200202/msg00006.html + + we'll be able to include a blurb about the PTS in the Resources part + we just need to wait the text from the guy who proposed his help + We need to think about other "simplifications" too + for example, all that stuff about upload queues is mostly useless + +http://people.debian.org/~walters/descriptions.html + Colin Walters approved + diff --git a/debian/changelog b/debian/changelog new file mode 100644 index 0000000..acadb63 --- /dev/null +++ b/debian/changelog @@ -0,0 +1,1392 @@ +developers-reference (3.3.9) unstable; urgency=low + + * Packaging changes: + - bump standards-version to 3.7.2 (no change) + - fix debian/copyright + - move debhelper to Build-Depends. + - add pdf for French version. + * Document changes to stable release management. Closes: #414291 + * Debconf error templates no longer discouraged. Thanks, + Christian Perrier. Closes: #427832 + * Keyring now uses RT. Closes: #428846 + * Document -dbg-packages within BPs. Thanks, Joey Hess. Closes: #420540 + * NMUs now also close bugs. Thanks, Lucas Nussbaum. Closes: #419507 + * Fix documentation about gender neutral. Closes: #384178 + * Fix typo. Closes: #405453 + * More details on how to write documentation. Thanks, Josh Triplett. + Closes: #422750 + * Add XS-Vcs-*. Thanks to Stefano Zacchiroli. Closes: #391023 + * Small brushup to debconf description. Thanks, Thomas Huriaux. + Closes: #401415 + * Document Team-Maintainence better. Thanks, Lucas Nussbaum. + Closes: #410159 + * Add link to more removal ressources. Thanks, Adam D. Barratt, + Justin Pryzby. Closes: #412757, #356720 + * Repacking source packages need to be documented in copyright. + Thanks, Russ Allbery. Closes: #413320 + * Better describe version of debian native packages NMUs. Closes: #405818 + + -- Andreas Barth Sat, 16 Jun 2007 11:41:41 -0600 + +developers-reference (3.3.8) unstable; urgency=low + + * mia-history is replaced by mia-query. Thanks, Christoph Berg. + Closes: #350792 + * fix missing quite. Thanks, Frank Küster. Closes: #365994 + * use gnugp instead of gpg. Thanks, Justin Pryzby, Jon Dowland. + Closes: #376411 + * better destinction between maintainer and developer. Thanks for + the suggestion to Colin Tuckley. Closes: #380458 + * irc.d.o points to oftc. Thanks, Christoph Biedl, Jon Dowland. + Closes: #382721 + * Bugs are now always closed thanks to version tracking. + Closes: #339552, #353447, #376199 + * Clarify what "a conflicts b" means in testing migration. + Closes: #361311 + * Packages in testing disappear if they're removed from unstable. + Thanks, Frank Küster, Al Stone. Closes: #365993 + * Document only the most recent changelog entry is used. Thanks + to Kevin Glynn to the suggestion. Closes: #374738 + * Add more tools for reverse depends. Close: #376582 + * delayed-queue on gluck is uploaded more often now. Closes: #397907 + * stop using capitals, minor fixes, language fixes. + Thanks, Thijs Kinkhorst, Colin Tuckley, Russ Allbery. + Closes: #368046, #378929, #361744 + * add CVE Ids to your changelog. Closes: #376961 + * add reasoning why debconf questions shouldn't be longer than + 20 lines. Thanks, Thijs Kinkhorst, Christian Perrier, Russ Allbery. + Closes: #382477 + * section changing needs re-uploading orig.tar.gz. + Thanks, Adam D. Barratt. Closes: #387154 + * binary files in diffs could be en/decoded with perl. + Thanks, Frank Küster. Closes: #397786 + * Add pointer to new-reject-FAQ. Closes: #324967 + * Hint to dd-list/whodepends. Closes: #353874 + * Don't use too generic mail ids. Closes: #355725 + * pts/summary is actually used. Thanks, Holger Levsen. Closes: #387108 + * clarify that one should append the NMU-diff to a bug. Closes: #394033 + * more detailed instructions on binary package removals. + Closes: #356643 + + * Frédéric Bothamy + - French translation updated to version 3.3.8 + + -- Andreas Barth Sat, 11 Nov 2006 10:55:44 -0700 + +developers-reference (3.3.7) unstable; urgency=low + + * Andreas Barth: + - adjust information about distributions with reality. + - add note on alioth accounts. Thanks, Phillip Kern. Closes: #306630 + - correct manpage section of dpkg-scanpackages. Closes: #297069 + - fix RFC 2440 URL. Closes: #308103 + - add $arch@buildd information. Closes: #295483 + - link to keyring.d.o for key replacement. Thanks, Martin Michlmayr. + Closes: #298016 + - add information about Packages-arch-specific. Thanks, Frank Küster. + Closes: #302000 + - add hint about LWN subscription. Thanks, Martin Michlmayr. + Closes: #299217 + - more about debconf-style translation. Thanks, Christian Perrier. + Closes: #309502 + - non-us discontinued. + - document nmu changes wrt version tracking. Thanks, Justin Pryzby. + Closes: #341197 + - fix spelling issues. Thanks to various people. + Closes: #336146, #326857, #338660 + - update menu policy helpers. Thanks, Florian Ernst. Closes: #340024 + - send mia-mail to mia@qa. Thanks, Adam D. Barratt. Closes: #341568 + - Joerg Jaspert is now freenode contact. Closes: #344303 + - give a clearer description of the gpg v4-key issues. Thanks, + Martin Michlmayr and Peter Palfrader. Closes: #317411 + - more verbose about Homepage. Closes: #339826 + - add sarge and etch. Closes: #327682 + - document severity of RoM-request bugs. Closes: #305947 + - update FSF address. Closes: #334820 + - fix P-a-s link. Closes: #341195 + - reflect binNMU changes. Closes: #349493 + - new security upload queue. Closes: #352749 + - fix experimental's sources.list entry. Closes: #347229 + - remove deprecated "Closes:..." to ACK NMU bug fixes. Closes: #353447 + - when resigning, gpg-sign your mail. Closes: #348160 + - make pristine source and repackaged origtargz anchors work. + Closes: #351255 + - same number of RC bugs is ok. Closes: #351944 + - dpkg-source doesn't keep permissions. Thanks, Enrico Zini. + Closes: #306120 + - also mention aspell. Closes: #320981 + + * Frédéric Bothamy + - French translation updated to version 3.3.7, proofread by Bernard Adrian + + -- Andreas Barth Sun, 09 Apr 2006 11:31:52 -0600 + +developers-reference (3.3.6) unstable; urgency=low + + * Andreas Barth + - closes: and NMUs/experimental uploads. Closes: #284714 + - madison is on merkel. + - more gender-neutral. Closes: #290583, #290584, #263114 + - explain current incoming. Closes: #290019 + - remove broken sponsoring URL. Closes: #291698 + - add handling hints about orig.tar.gz. Thanks, Frank. Closes: #278524 + - duplicate bug reports should be merged. Closes: #285381 + - if you're on vacation, please check whether someone needs keysigning. + Closes: #285458 + - freenode has developer cloacks. Closes: #285687 + - cleaned up uploaders / maintainer field + - explain how dak detects NMUs. Closes: #292354 + - add "mass" to lots of bugs. Closes: #292946 + - sync NM rules with reality. + * Frédéric Bothamy + - French translation updated to version 3.3.6 + + -- Andreas Barth Sun, 23 Jan 2005 16:08:49 -0700 + +developers-reference (3.3.5) unstable; urgency=low + + * Andreas Barth + - uploads to more than one dist are not possible. + - updated upload queues. Closes: #235213 + - updated URL of vanilla rules files. Closes: #237557, #252048 + - please speak with stable RM before uploading to stable. Closes: #261464 + - information on wnpp usage synced with wnpp. Closes: #255298 + - spelling, grammer fixes. + Closes: #202444, #202499, #203202, #203378, #221902, #226208 + - add hint about partitial key id. Closes: #243968 + - spohr is restriced, and also ftp-master. Closes: #255814 + - bpp: Hint about locale generation as non-root. Closes: #208021 + - bpp: deborphan-compliant transition packages. Closes: #183654 + - add myself to uploaders. + - add chapter about i10n. Closes: #208156 + - add information about dchroot. Closes: #211845 + - add information about NEWS.Debian. Closes: #212402 + - add information about mia-database. Closes: #213961 + - add link to debian-mentors FAQ. + - add verbose information about the package description. Closes: #214792 + - add hint about -v to experimental. Closes: #232930 + - update information about yada. Closes: #217956 + - urgency is sticky. Closes: #261914 + - updated information about testing distribution. Closes: #266649. + - rewrote the NMU section, and + + made the possible severities of "target bugs" clearer. Closes: #233088. + + mention QA uploads. Closes: #202416. + + add -B for binNMUs, and local debsign usage. Closes: #208839. + + warning about breaking all-packages by binNMU. Closes: #213348. + - add information about gpg usage. Closes: #175815. + - make key replacement instructions more details. Closes: #275921 + - typo and language fixes. Thanks, Era Eriksson. Closes: #277576 + - add hints about debconf templates from Christian Perrier. + * Matt Zimmerman + - Security uploads get urgency=high + - Be even more explicit about not uploading security updates + * Frédéric Bothamy + - French translation updated to version 3.3.5 + + -- Andreas Barth Mon, 22 Nov 2004 19:07:26 +0100 + +developers-reference (3.3.4) unstable; urgency=low + + * Josip Rodin: + - fixed language in the PTS section, prompted by a patch from + Romain FRANCOISE, thank you; closes: #197741 + - updated the mailing lists section (again) + - documented Alioth, somewhat + * Frédéric Bothamy + - French translation updated to version 3.3.3 (more or less) + - proofread by Patrice Karatchentzeff + * Matt Zimmerman + - 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 + - More explicit instructions about what is appropriate for a security + upload + + * Adam Di Carlo + - replace with and other SGML hygenics + - build refinements + - Release this package as is to flush changes between June and now. + Yes, its been an age between releases here, for which I apologize. + Since CVS upstream for this package is back, I'm working on closing + bugs in this package now, I just wanted to get it out as is before I + started. + + -- Adam Di Carlo Sun, 29 Feb 2004 14:09:48 -0500 + +developers-reference (3.3.3) unstable; urgency=low + + * Frédéric Bothamy + - corrections by Michel Grentzinger + * Raphaël Hertzog + - updated documentation concerning the PTS + - added a paragraph about the PTS web interface + - documented how to add custom news item in the PTS + * Matt Zimmerman + - updates and clarifications to instructions for security bugs + - deprecate uploads to stable for security fixes, reference + section on security bugs; closes: #196516 + - use dpkg-buildpackage -B to test binary-arch, not -b; + closes: #196555 + * Adam Di Carlo + - Sec "Managing sponsored packages": remove unnecessary 'debsign' cmd; + closes: #192417 + - fix debconf-devel(7) man page section; closes: #189512 + - Sec "Responding to bugs": mention what FTBFS means; closes: #186605 + - Sec "Distribution directories" renamed "Distributions" + - Sec "The testing distribution" moved under Sec "Distribution + directories" and renamed "More information about the testing + distribution" + - Secs "Uploads to {stable,testing-proposed-updates}" retitled to make + it clear these are special cases + - Sec "Uploading to ftp-master": xref to "Delayed incoming"; + closes: #195997 + - check compliance with Policy version 3.5.10 + + -- Adam Di Carlo Mon, 16 Jun 2003 04:08:29 -0400 + +developers-reference (3.3.2) unstable; urgency=low + + * Frédéric Bothamy: + - French translation updated to version 3.3.1 + - proofread by Philippe Batailler and Patrice Karatchentzeff + * Adam Di Carlo: + - French translation requires debiandoc-sgml 1.1.76 or better + + -- Adam Di Carlo Fri, 18 Apr 2003 09:48:59 -0400 + +developers-reference (3.3.1) unstable; urgency=low + + * Josip Rodin: + - package description said it contained French and Japanese, fixed, + closes: #182614 + - Sec "Experimental": sources.list entries + - Sec "Basic rules for [mailing list] use": cosmetic, link to this sec + - Sec "Handling bugs": retitle and expand section + * Adam Di Carlo: + - more improvements to package synopsis and description + - the synopsis formula changed to either + is a + or + is + or + are + closes: #182956 + - the synopsis itself should not start with an article + - Sec "Best practices for debian/control": expand intro + - fix doc-check URL; closes: #187144 + - Sec "Multiple binary packages": fix awkward wording about vim source + package; closes: #187143 + + -- Adam Di Carlo Fri, 4 Apr 2003 14:26:52 -0500 + +developers-reference (3.3) unstable; urgency=low + + * Frédéric Bothamy: + - French translation updated to version 3.2.2 (more or less) + - proofread by Philippe Batailler + * Raphaël Hertzog: + - added "ddtp" keyword in the PTS documentation + * Josip Rodin: + - split out the doc-files per language, closes: #177448 + - shuffled stuff around in the packages chapter + - added a section describing how to handle large amounts of + architecture-independent data bundled with programs + - added best practices on debian/changelog files, based on a patch + kindly provided by Daniel Kobras, closes: #166388 + - described debdiff and dpkg-depcheck, and linked to them from the + right places in the document, closes: #172897 + - describe the current practice in writing synopsis lines, + closes: #174161 + * Adam Di Carlo: + - update (c) year + - convert to debhelper (compat mode 4); maintainer scripts no longer + needed + - split -ja and -fr versions out into separate packages + - top-level makefile deletes targets on error; clean is cleaner + - replace the manual debian/control processing to show the document's + table of contents (TOC) with a new script 'debian/tocsubstvars'; + note that the TOC displayed in the developers-reference-{fr,ja} + package descriptions are in English until UTF8 control files are + allowed; proper escaping of single quotes here requires newest + debhelper + - editorial changes on material added in this version + - reorder "Best Packaging Practices" a bit + - rework "Best practices for debian/control" based on contributions + from Colin Walters, Branden Robinson, Sebastian Rittau and others; + closes: #139957, #108416 + - primary author is developers-reference@packages.debian.org; remove + emails from other authors to prevent spam and confusion + + -- Adam Di Carlo Mon, 24 Feb 2003 13:29:07 -0500 + +developers-reference (3.2.2) unstable; urgency=low + + * Josip Rodin: + - slightly rewrote and updated links in the mirrors section + * Adam Di Carlo: + - Policy compliance checked and updated to 3.5.8, no changes needed + - TODO: remove some tasks which are done + - ship README-contrib and TODO in the doc dir + - 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 + + -- Adam Di Carlo Thu, 12 Dec 2002 13:45:23 -0500 + +developers-reference (3.2.1) unstable; urgency=low + + * Adam Di Carlo: + - 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 + - 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 + - stop shipping SGML source -- use 'apt-get source developers-reference' + after all, this is supposed to be a binary package, right? + - simply PS and PDF building rules + + -- Adam Di Carlo Mon, 9 Dec 2002 03:04:19 -0500 + +developers-reference (3.2) unstable; urgency=low + + * Josip Rodin: + - merged a bit misplaced lintian-reports section within the lintian + section and adjusted links + - added the missing description of dh-make and adjusted links + * Adam Di Carlo: + - ChangeLog attribution updates + - fix typos, closes: #171781 + - expand the doc-base abstract and authors + - 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 packaging situations" + - Sec "Packages using autoconf/automake" rewritten + - Sec "Configuration management" moved forward in practices chapter + - Sec "Other specific packages" renamed to "Specific types of + packages", add info for SGML/XML and Lisp packages + - Sec "Writing useful descriptions" heavily edited + - 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 + - Apdx "Overview of Debian Maintainer Tools": remove debget, it's + rather useless and broken + - normalize up-casing on sections, which should only up-case proper + names and the first word + - new 'translation-status' script to check status of translations, + adapted from doc-check in boot-floppies, source pkg only -- + oh my, French translation is 54 CVS revisions behind, and Japanese + is 108 behind + - postinst: don't set /usr/doc symlink, aesthetics + - prerm: don't use 'command -v', it's not POSIX + - rules: produce md5sums file; break out a 'test' target + + -- Adam Di Carlo Sat, 7 Dec 2002 02:28:06 -0500 + +developers-reference (3.1.2) unstable; urgency=low + + * Josip Rodin: + - DDP publishing update + * Adam Di Carlo: + - doc-base file includes French and Japanese files + - debsign invocation was slightly wrong, closes: #170523 + - Sec "Handling debconf translations", updates from Martin Quinson + for po-debconf with minimal editorial changes, closes: #169007 + + -- Adam Di Carlo Wed, 27 Nov 2002 21:16:30 -0500 + +developers-reference (3.1.1) unstable; urgency=low + + * Josip Rodin: + - updated IRC stuff, thanks to Ben Armstrong, closes: #161403 + - fixed/updated/extended stuff about bugs, hoping to address the + issue of people abusing the changelog bug closing feature + * Raphaël Hertzog: + - added myself as co-author + - fix a typo in Sec "Collaborative maintenance", closes: #161488 + * Matt Zimmerman: + - updated security information, merging in Joey's stuff from the + Security Team FAQ and various updates and clarifications + * Adam Di Carlo + - fix some bad URLs, closes: #168357 + - fix a grammar typo, closes: #166098 + + -- Adam Di Carlo Tue, 12 Nov 2002 23:15:03 -0500 + +developers-reference (3.1) unstable; urgency=low + + * Raphaël Hertzog: + - Corrected several errors with — + - Applied patch from Peter Palfrader, correcting + the URL for the Debian Voting Information page. closes: #150427 + - Applied patch from Matej Vela, dpkg-buildpackage does no more + require -sa for version -0.1. closes: #150861 + - Applied the reformulations proposed by David Kimdon. closes: #150572 + - Applied the patch of Matt Zimmerman. Thanks Matt! closes: #145287 + - 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 + - Added a section about "Bug Squashing Parties". + * Josip Rodin: + - removed obsolete, needless dupload variables + - applied linguistic fixes from David Kimdon, closes: #150572 + - random proofreading, mostly changing he -> they + - added people.d.o and non-us.d.o to the Debian servers section, and + mostly rewrote it to exclude real machine names and be better organized + - updated the mailing lists section + * Adam Di Carlo + - debian/changelog: remove obsolete Emacs variables + - editorial review of the changes above, minor tagging changes, + spelling fixes + + -- Adam Di Carlo Tue, 10 Sep 2002 21:57:41 -0400 + +developers-reference (3.0) unstable; urgency=low + + * Adam Di Carlo: + - welcome Manoj Srivastava as a co-maintainer + - welcome Raphael Hertzog as a co-maintainer + + - 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 "The Developers Database" added under Resources + - new Sec "Collaborative Maintenance" concerning multiple maintainers + for one package + + - Sec "Getting started": add link to New Maintainers' Guide + - Sec "Debian Mentors" renamed to "Debian Mentors and Sponsors", + we add some info on sponsoring; also in Sec "Sponsoring packages" + - Section's first word capitalized, rest are normal case + - purge a reference to the Packaging Manual; closes: #145039 + - misc. cross-referencing with new or moved sections + - change some literal quotes to ‘, ”, etc. + - tagging improvements: replace with for files and + directories; since and doesn't look right, + work-around with <...> + - entity'ize master.debian.org, us-upload-dir, non-us-upload-dir + - update copyright date + - some simplifications on the TeX suffix rule + - spell check and grammar corrections + - s/GPG/GnuPG/ + + * Raphael Hertzog: + - changed -e by -m in the dpkg-buildpackage command line example; + closes: #110310 + - clarify wording between "porter upload", "binary-only NMU", "simple + recompile"; closes: #102626 + - extended "removing a package"; closes: #135560 + - Ch "Best Packaging Practices": new chapter, including new + Sec "Writing useful descriptions" as a first entry in that + chapter; closes: #53109, #129848 + - indicate 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 + - explain how 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/, + http://bugs.debian.org/ 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 + - Sec "The Incoming system" in "Resources", describe how it works and + also speak of the DELAYED directory; closes: #135562, #136774 + - 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 pain 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" + - 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 + - new Sec "Bug housekeeping"; closes: #39519 + - new Sec "Voting" + - new Sec "Documentation" + - added Sec "IRC channels" in the Resources chapter + - added Sec "pbuilder" in the appendix. Mention it in the section + "Being kind to porter" too + - extended Sec "devscripts" with info about "bts" and "uscan" + - completed Sec "Helper scripts" + - 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 + - integrated Sec "Handling debconf translations" contributed by + Denis Barbier -- thanks, Denis! + + * Antoine Hulin: + - update French translation + + -- Adam Di Carlo Fri, 14 Jun 2002 01:18:19 -0400 + +developers-reference (2.11) unstable; urgency=low + + * Antoine Hulin: + - some grammar corrections + - update French translation + * Martin Michlmayr: + - changes in upload situation, not possible to remove from Incoming + anymore; closes: #135559 + - also talk about dput a tiny bit + * Adam Di Carlo: + - Ch "Overview of Debian Maintainer Tools": + - improve the intro + - Charles Briscoe-Smith deprecates yada (I think new maintainers of + that would be welcome) + - 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 + - dpkg-dev-el: new section + - other minor wording changes + - Sec "Mailing Lists": where to find private archives, closes: #96780 + - 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" + * old bugs closed out, closes: #110573 + + -- Adam Di Carlo Sun, 7 Apr 2002 23:34:08 -0700 + +developers-reference (2.10.0) unstable; urgency=low + + * from Martin Michlmayr + - update the "Applying to Become a New Maintainer" section, with + review by Raphael Hertzog, closes: #133965 + - bugs closed in NMUs should uses 'closes' changelog entries, + closes: #133951 + - developers are not required to subscribe to debian-private + closes: #133955 + - some suggestions on places to use the proper term, Debian GNU/Linux, + closes: #133953 + - fix some typos, closes: #133956 + * Adam Di Carlo: + - frozen doesn't exist anymore, just testing; note, however, that + there is a way to upload to 'woody-proposed-updates' -- if I can + find some description of that, I'll document it; closes: #133948 + - minor build tweaks + - minor cosmetics + - isolate a few more language-independent bits + * from Chris Tillman + - change /usr/doc to /usr/share/doc, and typo in debian/copyright, + closes: #126924 + + -- Adam Di Carlo Sun, 24 Feb 2002 14:46:46 -0500 + +developers-reference (2.9.0) unstable; urgency=low + + * Josip Rodin: + - 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) + - replaced the nonexistent term "Security Manager" with "security officer" + - uploading to stable and unstable is deprecated; updated the section + about the experimental distribution; other fixes in the section + talking about uploading to distributions + - better organize some subsections in the section about package uploads + - replaced some bogus s with s + - noted how there is an upload queue on pandora, too + * Antoine Hulin: + - French translation updated + * Adam Di Carlo: + - normalize '--' as — for prettier output + - integrate changes from James Troup, part of #102626 + - typo fix thanks to Mark Hodge + + -- Adam Di Carlo Sun, 21 Oct 2001 01:03:01 -0400 + +developers-reference (2.8.8) unstable; urgency=low + + * from Josip Rodin: + - a few more strong words about sponsoring + - started a new chapter about the relationship between old and new + developers + + -- Adam Di Carlo Fri, 20 Jul 2001 17:53:47 -0400 + +developers-reference (2.8.7) unstable; urgency=low + + * French updates + * fix a typo in a link + * dpkg-buildpackage -m flag was changed for -e when NMU'ing; + update documentation accordingly + closes: #101676 + * Matt Zimmerman fixes up some wording in the section talking about + forwarding bugs upstream + closes: #98312 + * provide proper l10n for SGML date entities; now we have &date- + entities which should be used + * debian/rules: fixes for new debiandoc-sgml + * debian/control: depend on debiandoc-sgml 1.1.48 or better + + -- Adam Di Carlo Thu, 21 Jun 2001 14:43:42 -0400 + +developers-reference (2.8.6) unstable; urgency=low + + * fix a typo, thanks to Antoine Hulin + * French version: completely up-to-date now + * Makefile: add a 'validate' target + * prepare and ship "upstream" ChangeLog; move the debian changelog to + changelog.Debian.gz + * all versions: change the email address to use when orphaning + closes: #93727 + + -- Adam Di Carlo Fri, 13 Apr 2001 03:32:08 -0400 + +developers-reference (2.8.5) unstable; urgency=low + + * expunge references to the Debian Packaging Manual, which is now in the + Policy + * Japanese version: also comment out some references packaging manual; + this translation needs updating + * 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) + * debian/control: Build-Depends should have been Build-Depends-Indep + * French version: First complete translation of the Debian developer's + reference guide. Much work done by Antoine Hulin. Reviewed by Nicolas + Bertolissio. + * Portuguese version: work is started by Carlos Laviola, nothing + included yet, however + + -- Adam Di Carlo Sun, 8 Apr 2001 01:25:51 -0400 + +developers-reference (2.8.4) unstable; urgency=low + + * debian/control: remove reference to obsolete packaging-manual package + (closes: Bug#86505) + * debian/control: fill in the description a bit more + * doc-base: index.html corrected to be index.en.html + (closes: Bug#85933) + * Makefile: clean is cleaner + + -- Adam Di Carlo Sun, 25 Feb 2001 12:47:06 -0500 + +developers-reference (2.8.3) unstable; urgency=low + + * build and provide French and Japanese versions + * devolve build logic from debian/rules to top-level Makefile + * developers-reference.jp.sgml: minor changes so it will build (is out + of date) + * debian/rules: stop making useless /usr/share/developers-reference dir + + -- Adam Di Carlo Mon, 22 Jan 2001 02:02:02 -0500 + +developers-reference (2.8.2) unstable; urgency=low + + * Josip Rodin: + - fix typographic errors reported by David Martinez (closes: Bug#80740) + - common.ent: upped the numbers a little bit, updated lintian reports URL + - 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/ + - replaced evil latin1-only quotation marks, replaced mentions of + important severity (in RCB context) with serious severity, some + details fixed + - common.ent (1.10): fixed email-debian-user alias; updated + sample-dist-dirtree (with more to come) + - 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 + - another update WRT sid/unstable/testing, from Colin Watson + (closes: Bug#80896) + * debian/control: add Recommends for debian-policy, packaging-manual + * update copyright notice for 2001 + * fix for WNPP bug filing severities from David Schleef + * clarify the status of the Developers's reference as "normative" + * add a reference to debconf (closes: Bug#82413) + + -- Adam Di Carlo Sun, 21 Jan 2001 18:10:21 -0500 + +developers-reference (2.8.1) unstable; urgency=low + + * update WNPP instructions, based on patch from Marcelo E. Magallon + (closes: Bug#69435) + * spelling corrections, awkward grammar suggestions from Andreas Krueger + (closes: Bug#72810) + * debian/rules: remove some obsolete source-depends stuff + + -- Adam Di Carlo Sat, 4 Nov 2000 13:22:21 -0500 + +developers-reference (2.8.0) unstable; urgency=low + + * Almost all changes for this release are from Josip Rodin + . Thanks, Josip! + + * debian/control, postinst, prerm, rules: Policy 3.2.1 (closes: + Bug#68929, Bug#70384) + * fixed bug closing example (closes: Bug#71198) + * update the perl regexp from current /usr/lib/dpkg/parsechangelog/debian + * updated keyring/keyserver information (closes: Bug#67783) + * updated new-maintainer stuff (closes: Bug#67841) + * updated for master -> ftp-master move (closes: Bug#68369) + * noted www.d.o is the right host for web pages, but all other machines + could be used if necessary + * 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 + * fixed orphaning/adopting instructions with regard to the new WNPP + * common.ent: fix urls for cvs.d.o, wnpp, Debian machines page, + lists-archives, www.d.o BTS + * common.ent: changed link for machines from devel/maintainer_contacts + to the db.d.o CGI + * Makefile: remove unnecessary subshell + + * Adam's change: update debian/copyright for new Policy, and put my name + in there a bit with updated years; update doc-base file for FHS + + -- Adam Di Carlo Sun, 15 Oct 2000 03:25:21 -0400 + +developers-reference (2.7.2) frozen unstable; urgency=medium + + * I believe this should go into frozen because (a) it's only + documentation, so it can't introduce RC bugs, and (b) it fixes an + error which prevented it from building properly; however, whatever + ftpmaster feels is best is fine + * + * include common.ent as well as version.ent + (closes: Bug#52582, Bug#48926) + * debian/rules: fix build error caused by newer debiandoc-sgml; remove + constitution.en.html, since that is now located in the doc-debian + package (closes: Bug#54778, Bug#42014); don't compress .pdf file + * + * All changes below from Raphael Hertzog + * + * Sec. "Uploading to master" and "Uploading to pandora": + explained dinstall -n (closes: Bug#45079) + * Sec. "Picking a distribution": added reference to the debian-release + team (closes: Bug#52906) + * Sec. "Announcing package uploads": rewrote it to take care of the fact + that dinstall is doing it automatically (closes: Bug#43877) + * Sec. "Mailing lists": added a paragraph about debian-email + (closes: Bug#40258) + * Changed the "Maintaining Your Debian Information" into "Debian + Developer's Duties" (closes: Bug#28908) + - added a section about the LDAP database + - added a section about the "on vacation" message + - added a section about the coordination with upstream developers + (closes: Bug#43878) + - added a section about managing Release Critical bugs + - added a section about Quality Assurance effort + + -- Adam Di Carlo Sun, 16 Apr 2000 23:24:33 -0400 + +developers-reference (2.7.1) unstable; urgency=low + + * Sec. "Registering as a Debian developer": we are transitioning away + from non-free PGP -- remove allusions to non-free software such as + PGPv2 or v5 insofar as possible; recommend use of DSS keys rather than + RSA + * Sec. "Maintaining Your Public Key": remove PGP-centric stuff + * Sec. "When bugs are closed by new uploads": describe how to close bugs + via a magic changelog entry (closes: Bug#43690) + * Sec. "Generating the changes file": refer to Sec. "When bugs are + closed by new uploads" for closing bugs via a changelog entry + * developers-reference.sgml: re-enable RCS variables in CVS sources + * debian/control,rules: dynamically generate the TOC in the package + description from developers-reference.sgml + + -- Adam Di Carlo Sun, 12 Sep 1999 18:15:59 -0400 + +developers-reference (2.7.0) unstable; urgency=low + + * developers-reference.sgml: separated out language-independant elements + into common.ent (not content changes); misc minor grammar changes + throughout + * doc-base: change section for *constitution* to Debian (not 'debian') + (closes Bug#37392) + * Sec. "Stable, unstable, and sometimes frozen": mention how old stable + releases are available at archive.debian.org + * Sec. "Uploading to pandora (non-us)" added, remove stale + information about the old anonymous ftp area (closes Bug#39541); + Sec. "Other Upload Queues" added about that upload queues, added + samosa and master.debian.org.jp (closes Bug#37804) + * Sec. "Yada": mention that yada might not be as robust as other package + producing systems, at request of the author; Sec. "equivs" added + * Sec. "Moving packages": at the request of Guy Maor, clarify that this + procedure is for moving packages in sections (i.e., free, contrib) + only + * Sec. "Registering as a Debian developer": talk about RSA keys rather + than PGP keys, since I think GPG can create/handle them now; mention + that the official pkg maintainer address much match an ID on your key; + * Sec. "Maintaining Your Public Key": beef up the warnings a bit; point + to the PGP FAQ + * Sec. "Mailing Lists, Servers, and Other Machines": clean up and + clarify section; mention that all developers are expected to be + subscribed to debian-private and debian-devel-announce + * Sec. "Other Debian Machines": remove list of machines; point to + http://www.debian.org/devel/machines instead + * Sec. "Release code names": potato is 2.2 + * Sec. "Guidelines for Porter Uploads": talk about recompile only + uploads and version numbers for this (i.e., foo_2.4-1.0.1), from a + suggestion from James Troup + * Sec. "buildd": mention andrea, and buildd.debian.org + * Sec. "Removing packages": correct apt-cache usage + * debain/rules: update standards to 3.0.1 -- since I'm not moving + /usr/doc to /usr/share/doc yet, no changes were required except in the + text here and there + + -- Adam Di Carlo Mon, 16 Aug 1999 23:29:45 -0400 + +developers-reference (2.6.8) unstable; urgency=low + + * when applying as a new user, the login name can be *eight* characters, + not seven (thanks to Rafael Caetano dos Santos) + + -- Adam Di Carlo Fri, 21 May 1999 21:50:04 -0400 + +developers-reference (2.6.7) unstable; urgency=low + + * SGML'ish: normalize SGML elements, refill paragraphs (closes Bug#37987) + * doc-base: change section to Debian -- hmm, this looks like a doc-base + bug, really, but hey, who am I to refile bugs to another one of my own + packages? (closes Bug#37392) + * 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) + + -- Adam Di Carlo Fri, 21 May 1999 01:41:45 -0400 + +developers-reference (2.6.6) unstable; urgency=low + + * 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) + * debian/rules: re-enable letter-sized PDFs + + -- Adam Di Carlo Sun, 9 May 1999 01:17:29 -0400 + +developers-reference (2.6.5) unstable; urgency=low + + * 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. + + -- Adam Di Carlo Tue, 4 May 1999 03:32:21 -0400 + +developers-reference (2.6.4) unstable; urgency=low + + * debian/rules: 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 + + -- Adam Di Carlo Fri, 9 Apr 1999 20:04:04 -0400 + +developers-reference (2.6.3) unstable; urgency=low + + * correction from James Troup -- is indeed the correct + address for PGP key updates + + -- Adam Di Carlo Sun, 4 Apr 1999 13:28:58 -0400 + +developers-reference (2.6.2) unstable; urgency=low + + * Sec. "fakeroot": libtricks is not replacing anything after all + * developers-reference.sgml: use public declaration + * BTW, if any maintainers of translated versions of this document would + like to talk to me about folding your version into the + developers-reference CVS area, please get in touch with me + + -- Adam Di Carlo Sun, 4 Apr 1999 04:42:29 -0400 + +developers-reference (2.6.1) unstable; urgency=low + + * include Debian constitution (closes Bug#30694) + * Sec. "fakeroot": libtricks is replacing fakeroot, not libtool + * 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 + instead) + * Ch. "Overview of Debian Maintainer Tools" -- add Sec. "debget" + * developers-reference.sgml: minor typo correction from Tril + + * doc-base stuff: add abstract to developers-reference, new file for + constitution + * debian/rules: minor cleanup and consistency; build PDF, not PS file; + ship PDF file;.text file now has .txt extension + * debian/control: set priority to optional, matching archive + + -- Adam Di Carlo Sat, 3 Apr 1999 17:17:06 -0500 + +developers-reference (2.6.0) frozen unstable; urgency=low + + * would be nice to sneak this into slink; it's just documentation! + * 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 elements to where appropriate + + -- Adam Di Carlo Thu, 11 Feb 1999 02:53:55 -0500 + +developers-reference (2.5.0.5) unstable; urgency=low + + * add version.ent to docdir, needed to reconstruct from SGML + (closes Bug#31034) + + -- Adam Di Carlo Tue, 29 Dec 1998 02:42:50 -0500 + +developers-reference (2.5.0.4) unstable; urgency=low + + * not officially released + * more spelling corrections + * s/ppc/powerpc/ (thanks, James Troup) + + -- Adam Di Carlo Fri, 18 Dec 1998 00:07:40 -0500 + +developers-reference (2.5.0.3) unstable; urgency=low + + * not officially released + * 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 + + -- Adam Di Carlo Wed, 25 Nov 1998 00:01:27 -0500 + +developers-reference (2.5.0.2) frozen unstable; urgency=low + + * not officially released + * maintainer name change (but it's still me) + * Ch. "Non-Maintainer Uploads (NMUs) and Porters": new chapter + discussing NMUs and porters; Section "Interim Releases" integrated out + of existance. New TOC for this section is: + * 6 Non-Maintainer Uploads (NMUs) and Porters + + 6.1 Who can do a port or an NMU + + 6.2 When to do a port or an NMU + o 6.2.1 When to do an NMU if you are a porter + + 6.3 How to do an NMU + o 6.3.1 NMU version numbering + o 6.3.2 NMUs must create a changelog entry + o 6.3.3 NMUs must send patches, if any, to the BTS + o 6.3.4 Building the NMU + + 6.4 Guidelines for Porters + + * Sec. "Maintainer changes": renamed to "Adopting a package" and moved + to Chapter "Moving, Removing, Renaming, Adopting, and Orphaning + Packages". + * Sec. "Reporting lots of bugs at once": more forcefully deprecate this + practice + * Sec. "Adopting a package": mention that the BTS maintainer update can + take a couple of weeks + * Sec. "Overview of Debian Maintainer Tools": give credit where credit + is due and attribute current maintainers; add `apt'; add `quinn-diff'; + add mention of as yet unreleased 'buildd' package, since I'm so + excited about it and can't wait + * Sec. "Removing packages": talk about how apt-cache can be used to look + at reverse depends, a good step to take prior to removing a package + from the archive + * show *full* TOC, including sect2 + * of course the obligatory typo, grammar, and spelling corrections + + * Makefile: small changes to accomodate DDP autobuild + * debian/dirs: obsolete, removed + * debian/rules: use changelog date for SGML timestamping, not current date + + -- Adam Di Carlo Fri, 20 Nov 1998 12:27:53 -0500 + +developers-reference (2.5.0) frozen unstable; urgency=low + + * move to 3-level version number: + top-level version number probably won't change for a while, it is the + "major", the second-level number means significant content changes, + and the third-level change means corrections and minor improvements. + Since this version has significant content changes, we are now 2.5.0. + Since I'm going to put porter instructions in the next major rev, that + will be 2.6.0... + + * use new tag where appropriate (Ardo, you rock) + * replace 'm86k' with 'm68k' + * rename 'Whirlwind Tour of ...' section to 'Overview of ...' (suggested + by James Troup) + * typos and "red-pen" corrections, fix cosmetic problems in PostScript + version + * remove the one case I use an URL fragment identifier, since + debiandoc-sgml doesn't like it (bug filed against debiandoc-sgml) + * debian/rules: cosmetic cleanups, loosen check for root + * debian/rules: build PostScript version during build, since it's nice + to have all my debiandoc2* scripts together + * debian/control: policy compliant to 2.5.0 + + * advise against uploading when a package has lintian problems of + severity 'E' + * "Mailing Lists and Servers": + - "The master server": mention how master is the home of the BTS; + mention how users need to take care with their accounts on master + - "The WWW servers": fill in www.debian.org, first pass, and discuss + how to put up your own web pages on va or master + - "The CVS server": new section added + - "Mirrors of Debian servers": new section added; point to info about + how to mirror + * "Applying to Become a Maintainer": do not advise resending initial + application; instead, simply mail a followup asking new maintainers + whether they go the initial application (closes Bug #28739); mention + that calls usually come in the evening; mention that if you use PGP + v5, you need to generate an RSA key (right?); clarify our intentions + with respect to GPG. + * "Release code names": Debian 2.2 is 'potato' + * "Distribution directories": give concrete examples, hopefully making + it clearer where to look in Debian archives for specific stuff; + mention that old distributions are moved to archive servers (is there + a canonical location?) + * "The override file": new section, added under "Notification that a new + package has been installed"; fill it out quite a bit + * "Uploading to *": reiterate thrice not to upload export + controlled-software to master, or the European queues on erlangen and + chiark + * "Picking a distribution": section broken out from "Generating the + changes file" + * "Uploading to frozen": new section, almost straight from Brian White + (hope you don't mind!) -- isn't that topical? + * "Interim releases": if you NMU a new upstream version (0.1), run + 'dpkg-buildpackage -sa' + + -- Adam P. Harris Thu, 12 Nov 1998 00:03:43 -0500 + +developers-reference (2.4.1.5) unstable; urgency=low + + * 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" chapter which helps delineate what should + and should not be included in this Reference. + * Add a new chapter, "Whirlwind Tour of Debian Maintainer Tools". Let + me know what useful tools I forgot -- remember, Debian-specific + maintainer tools only! + * Add discussion of the "experimental" distribution, culled from an email + from Guy Maor on debian-devel. + * Incorporated suggestions from Branden Robinson (closes Bug#27211). + * Point to doc-debian's mailing list instructions where relevant. + * Made references to online documentation into URLs where possible. + * Little corrections here and there. + * add a Makefile for use in the DDP manual hierarchy + * debian/rules: comment out my 'source-depends' hack; it's just slowing + things down + + -- Adam P. Harris Thu, 1 Oct 1998 03:42:43 -0400 + +developers-reference (2.4.1.4) unstable; urgency=low + + * fill in Section "The master server" a bit; other servers to follow + * in Section "Distribution directories", mention that distributions + are always in 'dists' subdir of the Debian archive; talk about + 'proposed-updates' + * in Section "Release code names", talk about 'sid' a bit + * in Section "Interim releases", talk about how non-maintainers should + use the BTS, and bug severity "fixed" (closes Bug#17524) + * in Section "Generating the changes file", talk about how to set the + distribution in the debian/changelog file (i.e., "frozen unstable") + * add a new Section "Checking the package prior to upload" to Section + "Uploading a package", mentioning lintian and other tests one should + do prior to uploading + * add new Section "Notification that a new package has been installed" + in Section "Uploading a package", talking about dinstall and the + override file a bit + * add new Sections "Moving packages", "Removing packages", "Replacing or + renaming packages", and "Orphaning a package" (closes Bug#26650) + * add new Section "Bugs in your packages", talking about maintainer + duties with respect to bugs + * add new Section "Lintian reports" under "Handling bugs reports", + talking about how maintainers should check their packages with lintian + every now and then, alternatively pointing them to the lintian web + pages + * clarify, a bit, the use of "section" and "subsection", bringing it + into line with the usage in the Policy Manual and Packaging Manual + * grammar and markup changes throughout + * debian/rules: added a crude source-depends rule, which renders more + explicit what is used to build this package + + -- Adam P. Harris Mon, 21 Sep 1998 00:51:46 -0400 + +developers-reference (2.4.1.3) unstable; urgency=low + + * new maintainer + * version number and date are automatically populated now + * changed doc-base section to "debian" + * debian/rules: better abstraction and organization + * reformat SGML like I happen to like it + * utilize the new URL tag + * build PostScript on letter size, I hear thats better for A4 and US + letter printing + + -- Adam P. Harris Thu, 16 Jul 1998 00:52:35 -0400 + +developers-reference (2.4.1.2) frozen unstable; urgency=low + + * non-maintainer release + * rebuilt since HTML versions of Chapters 1 and 2 were truncated + (important bug, no number yet, bugs.debian.org isn't working; + regardless, this should go in hamm because a broken developers + reference won't win us many friends in hamm, and after all, it's just + text, it can't hurt you.) + * no content changes, except that the version number in the SGML file + reflect this packages version number + * debian/rule: clean is cleaner now + + -- Adam P. Harris Tue, 16 Jun 1998 01:35:39 -0400 + +developers-reference (2.4.1.1) frozen unstable; urgency=low + + * Orphaned package + + -- Christian Schwarz Thu, 14 May 1998 21:56:36 +0200 + +developers-reference (2.4.1.0) frozen unstable; urgency=low + + * New version numbering scheme: + + - The version numbers are independent of dpkg now, but all policy + manuals (the Debian Policy Manual, the Debian Packaging Manual, and + the Debian Developer's Reference) share the same version numbering + scheme. + + - The first three digits of the version number specify the + `Standards-Version.' This number is incremented with each policy + change. The fourth digit represents the `patch-level,' which may + differ between the manuals. + + If only the patch-level digit is incremented, no changes in policy + have been made, except bug fixes and clarifications. Packages only + have to specify the first three digits of the version number in the + `Standards-Version' field of their source packages. + + * Uploaded to frozen and unstable. This is a documentation-only + package and the changes to the manual are relevant for hamm. + + * No changes to the Developer's Reference + + -- Christian Schwarz Mon, 13 Apr 1998 17:54:43 +0200 + +developers-reference (0.5) unstable; urgency=low + + * Changes to the Developer's Reference: + + - Changed section 1.2 Registering as a Debian developer: + + signatures from formal certification service are _NOT_ accepted + anymore + + images of ID documents have to be PGP or RSA signed + (as requested by James Troup) + + - Use current date instead of in manual + + * Updated FSF's address (reported by Lintian) + + -- Christian Schwarz Sat, 7 Mar 1998 13:52:15 +0100 + +developers-reference (0.4) unstable; urgency=low + + * Changes to the Developer's Reference: + + - Renamed chapter 4 into `Package uploads' + + - New section 4.2.5 Uploading to the non-us server + + - Changed section 4.4 Interim releases: + + non-maintainer releases should not close bugs + + normal maintainer must at least read the patch provided with + the non-maintainer release + + - New chapter 5 Handling bug reports: + + when reporting more then 10 bugs on the same topic, a message + has to be sent to debian-devel and the `maintonly' address + should be used + + - Lots of typos fixed + + * Compressed SGML source code + + * Added support for doc-base to register the Developer's Reference + to the online documentation systems dwww and dhelp + + * Upgraded to standards version 2.4.0.0 (no changes) + + -- Christian Schwarz Fri, 30 Jan 1998 21:58:34 +0100 + +developers-reference (0.3) unstable; urgency=low + + * Put lost sections from Policy Manual 2.1.3.3 back in: + - Generating the changes file (for uploads) + - Announcing package uploads + * New section about Debian Mentors + * debian/rules: Don't use debstd anymore + * debian/rules: Compress changelog file (fixes:#15441) + * Fixed link to WNPP list (fixes:#16201) + * Added menu entry (fixes:#15708) + + -- Christian Schwarz Wed, 24 Dec 1997 13:54:33 +0100 + +developers-reference (0.2) unstable; urgency=low + + * New chapter about `The Debian Archive' describing the structure + of our FTP server and the development process + * Added note that new maintainers have to read the Social Contract + and have to know where to find the Policy and Packaging Manuals + * PGP key ring is not distributed via dpkg but in doc/ of the FTP + server + * Added note that cross posting between Debian lists is depreciated + * New list of advantages why new packages should be discussed on + debian-devel before they are uploaded + * Added section about how packages are uploaded + * Added note that the Security Managers may do interim releases without + contacting the maintainer + * Removed chapter about bug tracking system (will be included in + a new manual released soon) + * Some minor changes + * Include SGML source in package + * Don't use `2-up' style for PostScript version + * Upgraded to Standards 2.3.0.1 + + -- Christian Schwarz Sun, 2 Nov 1997 20:53:26 +0100 + +developers-reference (0.1) unstable; urgency=low + + * Initial Release. + + -- Christian Schwarz Tue, 8 Jul 1997 00:19:49 +0200 + diff --git a/debian/compat b/debian/compat new file mode 100644 index 0000000..b8626c4 --- /dev/null +++ b/debian/compat @@ -0,0 +1 @@ +4 diff --git a/debian/control b/debian/control new file mode 100644 index 0000000..bf8e7c1 --- /dev/null +++ b/debian/control @@ -0,0 +1,41 @@ +Source: developers-reference +Section: doc +Priority: optional +Maintainer: Debian Documentation Project +Uploaders: Andreas Barth +Standards-Version: 3.7.2 +Build-Depends-Indep: docbook-xsl (>= 1.71.0), dblatex (>= 0.2) +Build-Depends: debhelper (>= 4.1.32) + +Package: developers-reference +Architecture: all +Recommends: debian-policy +Suggests: doc-base +Description: guidelines and information for Debian developers + This package contains the Debian Developer's Reference, a set of + guidelines and best practices which has been established by and for + the community of Debian developers. If you are not a Debian + developer, you probably do not need this package. + . + Table of Contents: + . + ${TOC:en} + . + This package contains the English version of the Developer's + Reference. The French translation is available in + developers-reference-fr. + +Package: developers-reference-fr +Architecture: all +Recommends: debian-policy +Suggests: doc-base +Description: guidelines and information for Debian developers, in French + This package contains the French translation of Debian Developer's + Reference (package: developers-reference), a set of guidelines and + best practices which has been established by and for the community of + Debian developers. If you are not a Debian developer, you probably + do not need this package. + . + Table of Contents (in English): + . + ${TOC:en} diff --git a/debian/copyright b/debian/copyright new file mode 100644 index 0000000..039af5a --- /dev/null +++ b/debian/copyright @@ -0,0 +1,29 @@ + +This is the Debian package of the Debian Developer's Reference. It +was assembled by Christian Schwarz , has been maintained +by Adam Di Carlo and is now maintained by Andreas Barth +. + +------------------------------------------------------------------------------ +Copyright of the Debian Developer's Reference: + +Copyright (c) 1997, 1998 Christian Schwarz; + (c) 2002 - 2003 Raphaël Hertzog + (c) 1998 - 2003 Adam Di Carlo + (c) 2004 - 2007 Andreas Barth + +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. + +This is distributed in the hope that it will be useful, but without +any warranty; without even the implied warranty of merchantability or +fitness for a particular purpose. See the GNU General Public License +for more details. + +A copy of the GNU General Public License is available as +`/usr/share/common-licenses/GPL' in the Debian GNU/Linux distribution +or on the World Wide Web at . +You can also obtain it by writing to the Free Software Foundation, Inc., +51 Franklin St, Fifth Floor, Boston, MA 02110, USA diff --git a/debian/developers-reference-fr.doc-base b/debian/developers-reference-fr.doc-base new file mode 100644 index 0000000..40ed300 --- /dev/null +++ b/debian/developers-reference-fr.doc-base @@ -0,0 +1,17 @@ +Document: developers-reference-fr +Title: Debian Developer's Reference, French translation +Author: Adam Di Carlo, Josip Rodin, Raphaël Hertzog, et al +Abstract: Overview of available resources, standard package + maintenance procedures, duties and best practices for Debian + developers. This document describes, for instance, how to orphan a + package, how to maintain your public key, how to rename a package, + how to do an NMU, guidelines for porters, available packaging tools, + and the like. +Section: Debian + +Format: HTML +Index: /usr/share/doc/developers-reference-fr/index.fr.html +Files: /usr/share/doc/developers-reference-fr/*.html + +Format: PDF +Files: /usr/share/doc/developers-reference-fr/developers-reference.fr.pdf diff --git a/debian/developers-reference-ja.doc-base b/debian/developers-reference-ja.doc-base new file mode 100644 index 0000000..6da6b18 --- /dev/null +++ b/debian/developers-reference-ja.doc-base @@ -0,0 +1,14 @@ +Document: developers-reference-ja +Title: Debian Developer's Reference, Japanese translation +Author: Adam Di Carlo, Josip Rodin, Raphaël Hertzog, et al +Abstract: Overview of available resources, standard package + maintenance procedures, duties and best practices for Debian + developers. This document describes, for instance, how to orphan a + package, how to maintain your public key, how to rename a package, + how to do an NMU, guidelines for porters, available packaging tools, + and the like. +Section: Debian + +Format: HTML +Index: /usr/share/doc/developers-reference-ja/index.ja.html +Files: /usr/share/doc/developers-reference-ja/*.html diff --git a/debian/developers-reference.doc-base b/debian/developers-reference.doc-base new file mode 100644 index 0000000..362024a --- /dev/null +++ b/debian/developers-reference.doc-base @@ -0,0 +1,20 @@ +Document: developers-reference +Title: Debian Developer's Reference +Author: Adam Di Carlo, Josip Rodin, Raphaël Hertzog, et al +Abstract: Overview of available resources, standard package + maintenance procedures, duties and best practices for Debian + developers. This document describes, for instance, how to orphan a + package, how to maintain your public key, how to rename a package, + how to do an NMU, guidelines for porters, available packaging tools, + and the like. +Section: Debian + +Format: text +Files: /usr/share/doc/developers-reference/developers-reference.txt.gz + +Format: HTML +Index: /usr/share/doc/developers-reference/index.en.html +Files: /usr/share/doc/developers-reference/*.html + +Format: PDF +Files: /usr/share/doc/developers-reference/developers-reference.pdf diff --git a/debian/rules b/debian/rules new file mode 100755 index 0000000..4311407 --- /dev/null +++ b/debian/rules @@ -0,0 +1,106 @@ +#!/usr/bin/make -f +# rules file for developers-reference + +package := developers-reference + +# directory abstraction +prefix := debian/$(package) +docdir := $(prefix)/usr/share/doc/$(package) +docbaserel := /usr/share/doc-base +docbasedir := $(prefix)$(docbaserel) + +# list of language packages, in the form pkg-LANG; must jibe +# with debian/control, see also DATE_uc(LANG) below +langs := fr + +# tool abstraction +install_file := install -o root -g root -m 644 -p +install_script := install -o root -g root -m 755 -p +make_directory := install -d -o root -g root -m 755 + +# version 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') + +# debhelper verbose mode +#export DH_VERBOSE=1 + +version.ent: debian/changelog + :> version.ent + echo "" >> version.ent + echo "" >> version.ent + echo "" >> version.ent + echo "" >> version.ent + +build: + $(checkdir) + $(MAKE) + touch build + +.PHONY: clean +clean: + $(checkdir) + $(MAKE) clean + rm -f build + dh_clean + +.PHONY: test +test: +# nothing to test ATM + +.PHONY: install +install: build + $(checkdir) + $(checkroot) + dh_clean -k + + dh_installdocs -p$(package) README-contrib developers-reference.txt \ + developers-reference.pdf developers-reference.html/* + + 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/* ;\ + done + + +.PHONY: binary-indep +binary-indep: test install + $(checkdir) + $(checkroot) + dh_installdirs -i + dh_installchangelogs -i + dh_compress -i -X.pdf + dh_fixperms -i + debian/tocsubstvars -i + dh_installdeb -i + dh_gencontrol -i + dh_md5sums -i + dh_builddeb -i + + +.PHONY: binary-arch +binary-arch: build install +# There are no architecture-dependent files to be uploaded +# generated by this package. + +define checkdir + test -f debian/rules + test -f developers-reference.sgml +endef + +# Below here is fairly generic really + +define checkroot + test `id -u` = 0 +endef + +.PHONY: binary +binary: binary-indep binary-arch + +#Local variables: +#mode: makefile +#End: diff --git a/debian/tocsubstvars b/debian/tocsubstvars new file mode 100755 index 0000000..ac7fed6 --- /dev/null +++ b/debian/tocsubstvars @@ -0,0 +1,37 @@ +#!/usr/bin/perl -w + +use strict; +use Debian::Debhelper::Dh_Lib; + +init(); + +sub gettoc { + my $f = shift; + my @toc; + + open(FILE, "<$f") || die("opening $f: $!\n"); + while () { + chomp; + /^\d+\.\s/ && push(@toc, $_); + } + close(FILE) || die("closing $f: $!\n"); + return @toc; +} + +my @entoc = gettoc("developers-reference.txt"); + +# sanity test +if ( $#entoc == -1 ) { + error("found no entries in the TOC, aborting"); +} elsif ( $#entoc < 4 ) { + error("only found " . $#entoc . " entries in the TOC, aborting"); +} +verbose_print("found " . $#entoc . " entries in TOC"); + +my $entoc = " " . join('${Newline} ', @entoc); + +foreach my $package (@{$dh{DOPACKAGES}}) { + addsubstvar($package, "TOC:en", $entoc); +} + + diff --git a/developer-duties.dbk b/developer-duties.dbk new file mode 100644 index 0000000..899b567 --- /dev/null +++ b/developer-duties.dbk @@ -0,0 +1,212 @@ + + + +Debian Developer's Duties +
+Maintaining your Debian information + +There's a LDAP database containing information about Debian developers at +. 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. + + +For more information about the database, please see +. + +
+ +
+Maintaining your public key + +Be very careful with your private keys. Do not place them on any public +servers or multiuser machines, such as the Debian servers (see ). Back your keys up; keep a copy offline. Read +the documentation that comes with your software; read the PGP FAQ. + + +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. + + +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 +keyring.debian.org. + + +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 . + + +The same key extraction routines discussed in +apply. + + +You can find a more in-depth discussion of Debian key maintenance in the +documentation of the debian-keyring +package. + +
+ +
+Voting + +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 Debian +Constitution. + + +Other than the yearly leader election, votes are not routinely held, and they +are not undertaken lightly. Each proposal is first discussed on the +debian-vote@lists.debian.org mailing list and it requires +several endorsements before the project secretary starts the voting procedure. + + +You don't have to track the pre-vote discussions, as the secretary will issue +several calls for votes on +debian-devel-announce@lists.debian.org (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. + + +The list of all proposals (past and current) is available on the Debian Voting Information page, along +with information on how to make, second and vote on proposals. + +
+ +
+Going on vacation gracefully + +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. + + +Usually this means that other developers are allowed to NMU (see ) 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. + + +In order to inform the other developers, there are two things that you should +do. First send a mail to debian-private@lists.debian.org with +[VAC] prepended to the subject of your message This is so that +the message can be easily filtered by people who don't want to read vacation +notices. 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. + + +The other thing to do is to mark yourself as on vacation in the +Debian developers' LDAP database (this +information is only accessible to Debian developers). Don't forget to remove +the on vacation flag when you come back! + + +Ideally, you should sign up at the 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. + +
+ +
+Coordination with upstream developers + +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. + + +While it's not your job to fix non-Debian specific bugs, you may freely do so +if you're able. When you make such fixes, be sure to pass them on to the +upstream maintainers as well. Debian users and developers will sometimes +submit patches to fix upstream bugs — you should evaluate and forward these +patches upstream. + + +If you need to modify the upstream sources in order to build a policy compliant +package, then you should propose a nice fix to the upstream 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. + +
+ +
+Managing release-critical bugs + +Generally you should deal with bug reports on your packages as described in + . 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 critical, +grave or serious 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. + + +Developers who are part of the 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 +debian-qa@lists.debian.org, 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 ) 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). + +
+ +
+Retiring + +If you choose to leave the Debian project, you should make sure you do the +following steps: + + + + +Orphan all your packages, as described in . + + + + +Send an gpg-signed email about why you are leaving the project to +debian-private@lists.debian.org. + + + + +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). + + + +
+ + + diff --git a/index.dbk b/index.dbk new file mode 100644 index 0000000..07036fc --- /dev/null +++ b/index.dbk @@ -0,0 +1,101 @@ + + + + +Debian Developer's Reference + + +Developer's Reference Team +developers-reference@packages.debian.org + + +Andreas Barth + + +Adam Di Carlo + + +Raphaël Hertzog + + +Christian Schwarz + + +Ian Jackson + +ver. 3.3.9, 16 June, 2007 + + +2004 +2005 +2006 +2007 +Andreas Barth + + +1998 +1999 +2000 +2001 +2002 +2003 +Adam Di Carlo + + +2002 +2003 +Raphaël Hertzog + + +1997 +1998 +Christian Schwarz + + + +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. + + +This is distributed in the hope that it will be useful, but without +any warranty; without even the implied warranty of merchantability +or fitness for a particular purpose. See the GNU General Public License for +more details. + + +A copy of the GNU General Public License is available as +/usr/share/common-licenses/GPL in the Debian GNU/Linux +distribution or on the World Wide Web at the GNU web site. You can +also obtain it by writing to the Free Software Foundation, Inc., 51 Franklin +Street, Fifth Floor, Boston, MA 02110-1301, USA. + + +If you want to print this reference, you should use the pdf version. This page is also +available in French. + + + + + + + + + + + + + + diff --git a/l10n.dbk b/l10n.dbk new file mode 100644 index 0000000..76203f3 --- /dev/null +++ b/l10n.dbk @@ -0,0 +1,238 @@ + + + +Internationalizing, translating, being internationalized and being translated + +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. + + +According to 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. + + +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. + + +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. + +
+How translations are handled within Debian + +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. + + +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 +Free Translation +Project, the Gnome translation +Project or the KDE one. The +only centralized resource within Debian is the 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. + + +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 +DDTP. + + +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 Central Debian translation +statistics site (about what is integrated in the packages). + + +For web pages, each l10n team has access to the relevant CVS, and the +statistics are available from the Central Debian translation statistics site. + + +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. + + +For package-specific documentation (man pages, info documents, other formats), +almost everything remains to be done. + + +Most notably, the KDE project handles translation of its documentation in the +same way as its program messages. + + +There is an effort to handle Debian-specific man pages within a specific CVS +repository. + +
+ +
+I18N & L10N FAQ for maintainers + +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. + +
+How to get a given text translated + +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. + + +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. + +
+ +
+How to get a given translation reviewed + +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. + +
+ +
+How to get a given translation updated + +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. + + +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. + + +Avoid removing a translation completely because it is outdated. Old +documentation is often better than no documentation at all for non-English +speakers. + +
+ +
+How to handle a bug report concerning a translation + +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). + +
+ +
+ +
+I18N & L10N FAQ for translators + +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. + +
+How to help the translation effort + +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). + +
+ +
+How to provide a translation for inclusion in a package + +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. + + +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. + +
+ +
+ +
+Best current practice concerning l10n + + + +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. + + + + +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. + + + + +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 :) + + + + +In any case, cooperation can only be achieved with mutual respect. + + + +
+ + + diff --git a/new-maintainer.dbk b/new-maintainer.dbk new file mode 100644 index 0000000..e277466 --- /dev/null +++ b/new-maintainer.dbk @@ -0,0 +1,217 @@ + + + +Applying to Become a Maintainer +
+Getting started + +So, you've read all the documentation, you've gone through the Debian New Maintainers' +Guide, understand what everything in the hello 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? + + +Firstly, subscribe to debian-devel@lists.debian.org if you +haven't already. Send the word subscribe in the +Subject of an email to +debian-devel-REQUEST@lists.debian.org. In case of problems, +contact the list administrator at listmaster@lists.debian.org. +More information on available mailing lists can be found in . +debian-devel-announce@lists.debian.org is another list which is +mandatory for anyone who wishes to follow Debian's development. + + +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. + + +Another good list to subscribe to is +debian-mentors@lists.debian.org. See +for details. The IRC channel #debian can also be helpful; +see . + + +When you know how you want to contribute to Debian GNU/Linux, 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 +debian-mentors@lists.debian.org mailing list, describing your +package and yourself and asking for a sponsor (see +and 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. + + +One pitfall could be a too-generic local part in your mailadress: Terms like +mail, admin, root, master should be avoided, please see for details. + +
+ +
+Debian mentors and sponsors + +The mailing list debian-mentors@lists.debian.org 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 for details). + + +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. + + +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 first. + + +If you wish to be a mentor and/or sponsor, more information is available in + . + +
+ +
+Registering as a Debian developer + +Before you decide to register with Debian GNU/Linux, you will need to read all +the information available at the 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 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 GNU/Linux. +Reading the GNU +Manifesto would also be a good idea. + + +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 GNU/Linux has grown to over 900 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. + + +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! + + +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 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 identification page for +more information.) + + +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 for more information on maintaining your public key. + + +Debian uses the GNU Privacy Guard (package gnupg 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 RFC 2440. + + +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. 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). 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. 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 +5B00 C96D 5D54 AEE1 206B  AF84 DE7A AF6E 94C0 9C7F +then it's a v4 key. Another possibility is to pipe the key into +pgpdump, which will say something like Public Key Packet - +Ver 4. 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. + + +If your public key isn't on a public key server such as +subkeys.pgp.net, please read the documentation available at +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. + + +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. + + +To apply as a new maintainer, you need an existing Debian Developer to support +your application (an advocate). 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. + + +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 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 applications status board. + + +For more details, please consult 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. + +
+ + + diff --git a/pkgs.dbk b/pkgs.dbk new file mode 100644 index 0000000..68e24f1 --- /dev/null +++ b/pkgs.dbk @@ -0,0 +1,2608 @@ + + + +Managing Packages + +This chapter contains information related to creating, uploading, maintaining, +and porting packages. + +
+New packages + +If you want to create a new package for the Debian distribution, you should +first check the 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 WNPP web +pages for more information. + + +Assuming no one else is already working on your prospective package, you must +then submit a bug report ( ) against the +pseudo-package wnpp 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. + + +You should set the subject of the bug to ``ITP: foo +-- short description'', substituting the name of the +new package for foo. The severity of the bug report +must be set to wishlist. If you feel it's necessary, send +a copy to debian-devel@lists.debian.org 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). + + +Please include a Closes: +bug#nnnnn 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 ). + + +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. + + +There are a number of reasons why we ask maintainers to announce their +intentions: + + + + +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. + + + + +It lets other people thinking about working on the package know that there +already is a volunteer, so efforts may be shared. + + + + +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 debian-devel-changes. + + + + +It is helpful to the people who live off unstable (and form our first line of +testers). We should encourage these people. + + + + +The announcements give maintainers and other interested parties a better feel +of what is going on, and what is new, in the project. + + + + +Please see +for common rejection reasons for a new package. + +
+ +
+Recording changes in the package + +Changes that you make to the package need to be recorded in the +debian/changelog. 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 +/usr/share/doc/package/changelog.Debian.gz, +or +/usr/share/doc/package/changelog.gz +for native packages. + + +The debian/changelog file conforms to a certain structure, +with a number of different fields. One field of note, the +distribution, is described in . More information about the structure of this file +can be found in the Debian Policy section titled +debian/changelog. + + +Changelog entries can be used to automatically close Debian bugs when the +package is installed into the archive. See . + + +It is conventional that the changelog entry of a package that contains a new +upstream version of the software looks like this: + + + * new upstream version + + +There are tools to help you create entries and finalize the +changelog for release — see +and . + + +See also . + +
+ +
+Testing the package + +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): + + + + +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. + + + + +Run lintian over the package. You can run +lintian as follows: lintian -v +package-version.changes. This will check +the source package as well as the binary package. If you don't understand the +output that lintian generates, try adding the +-i switch, which will cause lintian to +output a very verbose description of the problem. + + +Normally, a package should not be uploaded if it causes +lintian to emit errors (they will start with E). + + +For more information on lintian, see . + + + + +Optionally run to analyze changes from an older +version, if one exists. + + + + +Downgrade the package to the previous version (if one exists) — this tests +the postrm and prerm scripts. + + + + +Remove the package, then reinstall it. + + + + +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. + + + +
+ +
+Layout of the source package + +There are two types of Debian source packages: + + + + +the so-called native packages, where there is no +distinction between the original sources and the patches applied for Debian + + + + +the (more common) packages where there's an original source tarball file +accompanied by another file that contains the patches applied for Debian + + + + +For the native packages, the source package includes a Debian source control +file (.dsc) and the source tarball +(.tar.gz). A source package of a non-native package +includes a Debian source control file, the original source tarball +(.orig.tar.gz) and the Debian patches +(.diff.gz). + + +Whether a package is native or not is determined when it is built by + dpkg-buildpackage +1 . The rest of this section relates +only to non-native packages. + + +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 +.changes file. Subsequently, this very same tar file +should be used to build the new diffs and .dsc files, and +will not need to be re-uploaded. + + +By default, dpkg-genchanges and +dpkg-buildpackage 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 +-sa to always include it or -sd to always +leave it out. + + +If no original source is included in the upload, the original source tar-file +used by dpkg-source when constructing the +.dsc file and diff to be uploaded +must be byte-for-byte identical with the one already in +the archive. + + +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. + +
+ +
+Picking a distribution + +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 +debian/changelog file and places it in the +Distribution field of the .changes file. + + +There are several possible values for this field: `stable', `unstable', +`testing-proposed-updates' and `experimental'. Normally, packages are uploaded +into unstable. + + +Actually, there are two other possible distributions: `stable-security' and +`testing-security', but read for more +information on those. + + +It is not possible to upload a package into several distributions at the same +time. + +
+Special case: uploads to the <emphasis>stable</emphasis> distribution + +Uploading to stable means that the package will transfered +to the p-u-new-queue for review by the stable release +managers, and if approved will be installed in +stable-proposed-updates directory of the Debian archive. +From there, it will be included in stable with the next +point release. + + +Extra care should be taken when uploading to stable. +Basically, a package should only be uploaded to stable if one of the following +happens: + + + + +a truly critical functionality problem + + + + +the package becomes uninstallable + + + + +a released architecture lacks the package + + + + +In the past, uploads to stable 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 +proposed-updates archive when the advisory is released. +See for detailed information on handling +security problems. + + +Changing anything else in the package that isn't important is discouraged, +because even trivial fixes can cause bugs later on. + + +Packages uploaded to stable need to be compiled on systems +running stable, so that their dependencies are limited to +the libraries (and other packages) available in stable; +for example, a package uploaded to stable that depends on +a library package that only exists in unstable will be rejected. Making +changes to dependencies of other packages (by messing with +Provides or shlibs files), possibly making those other +packages uninstallable, is strongly discouraged. + + +The Release Team (which can be reached at +debian-release@lists.debian.org) will regularly evaluate the +uploads To stable-proposed-updates and decide if your +package can be included in stable. Please be clear (and +verbose, if necessary) in your changelog entries for uploads to +stable, because otherwise the package won't be considered +for inclusion. + + +It's best practice to speak with the stable release manager +before uploading to +stable/stable-proposed-updates, so +that the uploaded package fits the needs of the next point release. + +
+ +
+Special case: uploads to <emphasis>testing/testing-proposed-updates</emphasis> + +Please see the information in the testing +section for details. + +
+ +
+ +
+Uploading a package +
+Uploading to <literal>ftp-master</literal> + +To upload a package, you should upload the files (including the signed changes +and dsc-file) with anonymous ftp to ftp-master.debian.org in +the directory /pub/UploadQueue/. +To get the files processed there, they need to be signed with a key in the +debian keyring. + + +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. + + +You may also find the Debian packages or useful when uploading packages. These handy programs help +automate the process of uploading packages into Debian. + + +For removing packages, please see the README file in that ftp directory, and +the Debian package . + +
+ +
+Uploading to <literal>non-US</literal> + +Note: non-us was discontinued with the release of sarge. + +
+ +
+Delayed uploads + +Delayed uploads are done for the moment via the delayed queue at gluck. The +upload-directory is gluck:~tfheen/DELAYED/[012345678]-day. +0-day is uploaded multiple times per day to ftp-master. + + +With a fairly recent dput, this section + + +[tfheen_delayed] +method = scp +fqdn = gluck.debian.org +incoming = ~tfheen + + +in ~/.dput.cf should work fine for uploading to the DELAYED queue. + + +Note: Since this upload queue goes to +ftp-master, the prescription found in applies here as well. + +
+ +
+Security uploads + +Do NOT upload a package to the security +upload queue (oldstable-security, stable-security, etc.) without prior +authorization from the security team. If the package does not exactly meet the +team's requirements, it will cause many problems and delays in dealing with the +unwanted upload. For details, please see section . + +
+ +
+Other upload queues + +The scp queues on ftp-master, and security are mostly unusable due to the login +restrictions on those hosts. + + +The anonymous queues on ftp.uni-erlangen.de and ftp.uk.debian.org are currently +down. Work is underway to resurrect them. + + +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. + + +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. + +
+ +
+Notification that a new package has been installed + +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, katie. 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. + + +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. + + +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. + + +Note that if you upload via queues, the queue daemon software will also send +you a notification by email. + +
+ +
+ +
+Specifying the package section, subsection and priority + +The debian/control file's Section and +Priority 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 debian/control file are +actually just hints. + + +The archive maintainers keep track of the canonical sections and priorities for +packages in the override file. If there is a disparity +between the override file and the package's fields as +indicated in debian/control, then you will receive an +email noting the divergence when the package is installed into the archive. +You can either correct your debian/control file for your +next upload, or else you may wish to make a change in the override +file. + + +To alter the actual section that a package is put in, you need to first make +sure that the debian/control file in your package is +accurate. Next, send an email override-change@debian.org or +submit a bug against ftp.debian.org +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. + + +For more information about override files, see + dpkg-scanpackages +1 and . + + +Note that the Section field describes both the section as +well as the subsection, which are described in . If the section is main, it should be omitted. +The list of allowable subsections can be found in . + +
+ +
+Handling bugs + +Every developer has to be able to work with the Debian bug tracking system. This includes +knowing how to file bug reports properly (see ), +how to update them and reorder them, and how to process and close them. + + +The bug tracking system's features are described in the BTS documentation for +developers. This includes closing bugs, sending followup messages, +assigning severities and tags, marking bugs as forwarded, and other issues. + + +Operations such as reassigning bugs to other packages, merging separate bug +reports about the same issue, or reopening bugs when they are prematurely +closed, are handled using the so-called control mail server. All of the +commands available on this server are described in the BTS control server +documentation. + +
+Monitoring bugs + +If you want to be a good maintainer, you should periodically check the 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: +http://bugs.debian.org/yourlogin@debian.org. + + +Maintainers interact with the BTS via email addresses at +bugs.debian.org. Documentation on available commands can be +found at , or, if you have +installed the doc-debian package, you +can look at the local files /usr/share/doc/debian/bug-*. + + +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: + + +# ask for weekly reports of bugs in my packages +0 17 * * fri echo index maint address | mail request@bugs.debian.org + + +Replace address with your official Debian maintainer +address. + +
+ +
+Responding to bugs + +When responding to bugs, make sure that any discussion you have about bugs is +sent both to the original submitter of the bug, and to the bug itself (e.g., +123@bugs.debian.org). If you're writing a new mail and you +don't remember the submitter email address, you can use the +123-submitter@bugs.debian.org email to contact the submitter +and to record your mail within the bug log (that means you +don't need to send a copy of the mail to 123@bugs.debian.org). + + +If you get a bug which mentions FTBFS, this means Fails to build from source. +Porters frequently use this acronym. + + +Once you've dealt with a bug report (e.g. fixed it), mark it as +done (close it) by sending an explanation message to +123-done@bugs.debian.org. If you're fixing a bug by changing +and uploading the package, you can automate bug closing as described in . + + +You should never close bugs via the bug server +close command sent to +control@bugs.debian.org. If you do so, the original submitter +will not receive any information about why the bug was closed. + +
+ +
+Bug housekeeping + +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 BTS documentation for Debian +developers. Operations such as reassigning, merging, and tagging bug +reports are described in the BTS control server +documentation. This section contains some guidelines for managing your +own bugs, based on the collective Debian developer experience. + + +Filing bugs for problems that you find in other packages is one of the civic +obligations of maintainership, see for details. +However, handling the bugs in your own packages is even more important. + + +Here's a list of steps that you may follow to handle a bug report: + + + + +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. + + +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 wontfix 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 tech-ctte (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 recommended +procedure. + + + + +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 IRC or +on debian-devel@lists.debian.org. Please make sure that the +maintainer(s) of the package the bug is reassigned to know why you reassigned +it. + + +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. + + + + +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. + + + + +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 +moreinfo tag to mark the bug as such. Moreover if you can't +reproduce the bug, you tag it unreproducible. 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. + + + + +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 help. You can also +ask for help on debian-devel@lists.debian.org or +debian-qa@lists.debian.org. 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 patch. + + + + +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 pending to let +people know that the bug is corrected and that it will be closed with the next +upload (add the closes: in the +changelog). This is particularly useful if you are +several developers working on the same package. + + + + +Once a corrected package is available in the unstable +distribution, you can close the bug. This can be done automatically, read + . + + + +
+ +
+When bugs are closed by new uploads + +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. + + +However, it's possible to avoid having to manually close bugs after the upload +— just list the fixed bugs in your debian/changelog +file, following a certain syntax, and the archive maintenance software will +close the bugs for you. For example: + + +-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. + + +Technically speaking, the following Perl regular expression describes how bug +closing changelogs are identified: + + + /closes:\s*(?:bug)?\#\s*\d+(?:,\s*(?:bug)?\#\s*\d+)*/ig + + +We prefer the closes: #XXX +syntax, as it is the most concise entry and the easiest to integrate with the +text of the changelog. Unless specified different by the +-v-switch to dpkg-buildpackage, +only the bugs closed in the most recent changelog entry are closed (basically, +exactly the bugs mentioned in the changelog-part in the +.changes file are closed). + + +Historically, uploads identified as Non-maintainer +upload (NMU) were tagged fixed instead of being +closed, but that practice was ceased with the advent of version-tracking. The +same applied to the tag fixed-in-experimental. + + +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 reopen XXX command +to the bug tracking system's control address, +control@bugs.debian.org. To close any remaining bugs that were +fixed by your upload, email the .changes file to +XXX-done@bugs.debian.org, where XXX +is the bug number, and put Version: YYY and an empty line as the first two +lines of the body of the email, where YYY is the +first version where the bug has been fixed. + + +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 +XXX-done@bugs.debian.org. Do not 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. + + +For general information on how to write your changelog entries, see . + +
+ +
+Handling security-related bugs + +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. + + +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 +team@security.debian.org as soon as possible. DO NOT UPLOAD any packages for stable; the security +team will do that. Useful information includes, for example: + + + + +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. + + + + +The nature of the fix, if any is available (patches are especially helpful) + + + + +Any fixed packages that you have prepared yourself (send only the +.diff.gz and .dsc files and read first) + + + + +Any assistance you can provide to help with testing (exploits, regression +testing, etc.) + + + + +Any information needed for the advisory (see ) + + + +
+Confidentiality + +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. + + +There are several ways developers can learn of a security problem: + + + + +they notice it on a public forum (mailing list, web site, etc.) + + + + +someone files a bug report + + + + +someone informs them via private email + + + + +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: + + + + +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. + + + + +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. + + + + +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. + + +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. + + +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. + +
+ +
+Security Advisories + +Security advisories are only issued for the current, released stable +distribution, and not for testing or unstable. When +released, advisories are sent to the +debian-security-announce@lists.debian.org mailing list and +posted on 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: + + + + +A description of the problem and its scope, including: + + + + +The type of problem (privilege escalation, denial of service, etc.) + + + + +What privileges may be gained, and by whom (if any) + + + + +How it can be exploited + + + + +Whether it is remotely or locally exploitable + + + + +How the problem was fixed + + + + +This information allows users to assess the threat to their systems. + + + + +Version numbers of affected packages + + + + +Version numbers of fixed packages + + + + +Information on where to obtain the updated packages (usually from the Debian +security archive) + + + + +References to upstream advisories, CVE identifiers, and any other information +useful in cross-referencing the vulnerability + + + +
+ +
+Preparing packages to address security issues + +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. + + +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. + + +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. + + +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. + + +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. + + +Do NOT 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. + + +Review and test your changes as much as possible. Check the differences from +the previous version repeatedly (interdiff from the +patchutils package and +debdiff from devscripts are useful tools for this, see ). + + +Be sure to verify the following items: + + + + +Target the right distribution in your debian/changelog. +For stable this is stable-security and for testing this is +testing-security, and for the previous stable release, this +is oldstable-security. Do not target +distribution-proposed-updates or +stable! + + + + +The upload should have urgency=high. + + + + +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. + + + + +Make sure the version number is proper. It must be greater than the current +package, but less than package versions in later distributions. If in doubt, +test it with dpkg --compare-versions. Be careful not to +re-use a version number that you have already used for a previous upload. For +testing, there must be a higher version in +unstable. If there is none yet (for example, if +testing and unstable have the same +version) you must upload a new version to unstable first. + + + + +Do not make source-only uploads if your package has any binary-all packages (do +not use the -S option to +dpkg-buildpackage). The buildd +infrastructure will not build those. This point applies to normal package +uploads as well. + + + + +Unless the upstream source has been uploaded to security.debian.org before (by +a previous security update), build the upload with full upstream source +(dpkg-buildpackage -sa). If there has been a previous +upload to security.debian.org with the same upstream version, you may upload +without upstream source (dpkg-buildpackage -sd). + + + + +Be sure to use the exact same *.orig.tar.gz as used in the +normal archive, otherwise it is not possible to move the security fix into the +main archives later. + + + + +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 ) or +setup a chroot (see and ). + + + +
+ +
+Uploading the fixed package + +Do NOT upload a package to the security +upload queue (oldstable-security, stable-security, etc.) without prior +authorization from the security team. If the package does not exactly meet the +team's requirements, it will cause many problems and delays in dealing with the +unwanted upload. + + +Do NOT upload your fix to proposed-updates +without 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. + + +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 +ftp://security-master.debian.org/pub/SecurityUploadQueue/ . + + +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. + + +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. + + +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 +distribution-proposed-updates on ftp-master. + +
+ +
+ +
+ +
+Moving, removing, renaming, adopting, and orphaning packages + +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. + +
+Moving packages + +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'. See the Debian Policy Manual for +guidelines on what section a package belongs in. + + +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 Debian Policy Manual for +details). You must ensure that you include the +.orig.tar.gz 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. + + +If, on the other hand, you need to change the subsection +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 . + +
+ +
+Removing packages + +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 ftp.debian.org 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 unstable and +experimental. Packages are not removed from +testing directly. Rather, they will be removed +automatically after the package has been removed from +unstable and no package in testing +depends on it. + + +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. + + +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. + + +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. + + +Further information relating to these and other package removal related topics +may be found at +and . + + +If in doubt concerning whether a package is disposable, email +debian-devel@lists.debian.org asking for opinions. Also of +interest is the apt-cache program from the apt package. When invoked as apt-cache +showpkg package, the program will show +details for package, including reverse depends. +Other useful programs include apt-cache rdepends, +apt-rdepends and grep-dctrl. Removal of +orphaned packages is discussed on debian-qa@lists.debian.org. + + +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. libfoo12 was +removed because libfoo13 supersedes it) or closed if the +software is simply no longer part of Debian. + +
+Removing packages from <filename>Incoming</filename> + +In the past, it was possible to remove packages from +incoming. 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 unstable 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. + +
+ +
+ +
+Replacing or renaming packages + +When you make a mistake naming your package, you should follow a two-step +process to rename it. First, set your debian/control file +to replace and conflict with the obsolete name of the package (see the Debian Policy Manual for +details). Once you've uploaded the package and the package has moved into the +archive, file a bug against ftp.debian.org asking to remove +the package with the obsolete name. Do not forget to properly reassign the +package's bugs at the same time. + + +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 +foo_1.00.orig.tar.gz with +foo_1.00+0.orig.tar.gz. This restriction gives each file +on the ftp site a unique name, which helps to ensure consistency across the +mirror network. + +
+ +
+Orphaning a package + +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 Debian QA Group <packages@qa.debian.org> and submit +a bug report against the pseudo package wnpp. The bug report should be titled O: +package -- short +description indicating that the package is now +orphaned. The severity of the bug should be set to +normal; 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 debian-devel@lists.debian.org 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). + + +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 wnpp and title it RFA: +package -- short +description. RFA stands for +Request For Adoption. + + +More information is on the WNPP +web pages. + +
+ +
+Adopting a package + +A list of packages in need of a new maintainer is available in the Work-Needing and Prospective Packages +list (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. + + +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 . + + +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 technical committee web +page for more information). + + +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 +Maintainer: 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 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. + +
+ +
+ +
+Porting and being ported + +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. + + +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 +i386 binary package, there must be a recompile for each +architecture, which amounts to 12 more builds. + +
+Being kind to porters + +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. + + +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. + + +By far, most of the problems encountered by porters are caused by +packaging bugs in the source packages. Here is a +checklist of things you should check or be aware of. + + + + +Make sure that your Build-Depends and +Build-Depends-Indep settings in +debian/control are set properly. The best way to validate +this is to use the debootstrap package +to create an unstable chroot environment (see ). +Within that chrooted environment, install the build-essential package and any package +dependencies mentioned in Build-Depends and/or +Build-Depends-Indep. Finally, try building your package +within that chrooted environment. These steps can be automated by the use of +the pbuilder program which is provided by the package of the +same name (see ). + + +If you can't set up a proper chroot, dpkg-depcheck may be of +assistance (see ). + + +See the Debian Policy +Manual for instructions on setting build dependencies. + + + + +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 Debian Policy +Manual. Setting your architecture to ``i386'' is usually incorrect. + + + + +Make sure your source package is correct. Do dpkg-source -x +package.dsc to make sure your source +package unpacks properly. Then, in there, try building your package from +scratch with dpkg-buildpackage. + + + + +Make sure you don't ship your source package with the +debian/files or debian/substvars +files. They should be removed by the `clean' target of +debian/rules. + + + + +Make sure you don't rely on locally installed or hacked configurations or +programs. For instance, you should never be calling programs in +/usr/local/bin 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. + + + + +Don't depend on the package you're building being installed already (a sub-case +of the above issue). + + + + +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. + + + + +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 +dpkg-buildpackage -B. + + + +
+ +
+Guidelines for porter uploads + +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 instead. + + +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 +debian/changelog. + + +The way to invoke dpkg-buildpackage is as +dpkg-buildpackage -B +-mporter-email. Of course, set +porter-email 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 debian/rules. + + +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 +debsign on your .changes file to have +it signed conveniently, or use the remote signing mode of +dpkg-sig. + +
+Recompilation or binary-only NMU + +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 +(katie refuses to install new packages if they don't have a +version number greater than the currently available one). + + +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). + + +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. + + +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). + + +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''. 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. + + +Similar to initial porter uploads, the correct way of invoking +dpkg-buildpackage is dpkg-buildpackage -B +to only build the architecture-dependent parts of the package. + +
+ +
+When to do a source NMU if you are a porter + +Porters doing a source NMU generally follow the guidelines found in , 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. + + +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. + + +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. + + +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 #ifdef your work properly; also, +document your kludge so that people know to remove it once the external +problems have been fixed. + + +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. + +
+ +
+ +
+Porting infrastructure and automation + +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. + +
+Mailing lists and web pages + +Web pages containing the status of each port can be found at . + + +Each port of Debian has a mailing list. The list of porting mailing lists can +be found at . These +lists are used to coordinate porters, and to connect the users of a given port +with the porters. + +
+ +
+Porter tools + +Descriptions of several porting tools can be found in . + +
+ +
+<systemitem role="package">buildd</systemitem> + +The buildd system is used as a +distributed, client-server build distribution system. It is usually used in +conjunction with auto-builders, 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. + + +buildd 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 sbuild, see its description +in . The complete buildd system also collects a number of as yet +unpackaged components which are currently very useful and in use continually, +such as andrea and wanna-build. + + +Some of the data produced by buildd +which is generally useful to porters is available on the web at . This data includes nightly updated +information from andrea (source dependencies) and +quinn-diff (packages needing +recompilation). + + +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 gcc bounds checking). It will +also enable Debian to recompile entire distributions quickly. + + +The buildds admins of each arch can be contacted at the mail address +$arch@buildd.debian.org. + +
+ +
+ +
+When your package is <emphasis>not</emphasis> portable + +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. + + +In order to prevent broken packages from being uploaded to the archive, and +wasting buildd time, you need to do a few things: + + + + +First, make sure your package does 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. + + +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. + + + + +In order to prevent autobuilders from needlessly trying to build your package, +it must be included in packages-arch-specific, a list used +by the wanna-build script. The current version is available +as ; +please see the top of the file for whom to contact for changes. + + + + +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 ftp.debian.org + +
+ +
+ +
+Non-Maintainer Uploads (NMUs) + +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. + + +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 . If a buildd builds and uploads a package, that +too is strictly speaking a binary NMU. See for some +more information. + + +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. + + +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 +not be made in a non-maintainer upload. + + +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. + +
+How to do a NMU + +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. + + +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. + + +A NMU should follow all conventions, written down in this section. For an +upload to testing or unstable, this order of steps is recommended: + + + + +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. + + + + +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. + + + + +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. ). 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. + + + + +Upload your package to incoming in DELAYED/7-day (cf. + ), 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. + + + + +Follow what happens, you're responsible for any bug that you introduced with +your NMU. You should probably use (PTS) +to stay informed of the state of the package after your NMU. + + + + +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 for details. + + +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. + + +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. + + +When a security bug is detected, the security team may do an NMU, using their +own rules. Please refer to for more +information. + + +For the differences for Porters NMUs, please see . + + +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). + +
+ +
+NMU version numbering + +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. + + +If you are doing a non-maintainer upload (NMU), you should add a new minor +version number to the debian-revision 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 +foo_1.1-3.dsc. 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 +foo_1.1-3.1.dsc. + + +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. + + +If there is no debian-revision 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 debian-revision value `0.1'. The usual +maintainer of a package should start their +debian-revision numbering at `1'. + + +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. + +
+ +
+Source NMUs must have a new changelog entry + +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. + + +By convention, source NMU changelog entries start with the line + + + * Non-maintainer upload + +
+ +
+Source NMUs and the Bug Tracking System + +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 (diff -u) detailing their changes to +the Bug Tracking System. + + +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 + 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. + + +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. + + +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. + + +In addition, the normal maintainer should always 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. + +
+ +
+Building source NMUs + +Source NMU packages are built normally. Pick a distribution using the same +rules as found in , follow the other +instructions in . + + +Make sure you do not change the value of the maintainer in +the debian/control file. Your name as given in the NMU +entry of the debian/changelog file will be used for +signing the changes file. + +
+ +
+Acknowledging an NMU + +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 +-v option of dpkg-buildpackage, 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 closes: #nnnn in the changelog +entry of your next upload. + + +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 ). + +
+ +
+NMU vs QA uploads + +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 . If you perform an NMU on an +improperly orphaned package, please set the maintainer to ``Debian QA Group +<packages@qa.debian.org>''. + +
+ +
+Who can do an NMU + +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. + +
+ +
+Terminology + +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 +non-maintainer upload. + + +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 +debian/changelog). 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. + + +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. + + +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. + +
+ +
+ +
+Collaborative maintenance + +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 +Standard or which are part of the base set have +co-maintainers. + + +Generally there is a primary maintainer and one or more co-maintainers. The +primary maintainer is the person whose name is listed in the +Maintainer field of the debian/control +file. Co-maintainers are all the other maintainers. + + +In its most basic form, the process of adding a new co-maintainer is quite +easy: + + + + +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 CVS or Subversion. Alioth (see + ) provides such tools, amongst others. + + + + +Add the co-maintainer's correct maintainer name and address to the +Uploaders field in the global part of the +debian/control file. + + +: John Buzz <jbuzz@debian.org>, Adam Rex <arex@debian.org> + + + + +Using the PTS ( ), the co-maintainers +should subscribe themselves to the appropriate source package. + + + + +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: + + + + +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. + + + + +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). + + + + +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 + ) with packages one doesn't really care for, and creates +a false sense of good maintenance. + +
+ +
+The testing distribution +
+Basics + +Packages are usually installed into the `testing' distribution after they have +undergone some degree of testing in unstable. + + +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. + +
+ +
+Updates from unstable + +The scripts that update the testing distribution are run +each day after the installation of the updated packages; these scripts are +called britney. They generate the +Packages files for the testing +distribution, but they do so in an intelligent manner; they try to avoid any +inconsistency and to use only non-buggy packages. + + +The inclusion of a package from unstable is conditional on +the following: + + + + +The package must have been available in unstable 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; + + + + +It must have the same number or fewer release-critical bugs than the version +currently available in testing; + + + + +It must be available on all architectures on which it has previously been built +in unstable. may be of interest to check that +information; + + + + +It must not break any dependency of a package which is already available in +testing; + + + + +The packages on which it depends must either be available in +testing or they must be accepted into +testing at the same time (and they will be if they fulfill +all the necessary criteria); + + + + +To find out whether a package is progressing into testing or not, see the +testing script output on the web page of the testing +distribution, or use the program grep-excuses which +is in the devscripts package. This +utility can easily be used in a +crontab 5 +to keep yourself informed of the progression of your packages into +testing. + + +The update_excuses 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 testing web page gives some +more information about the usual problems which may be causing such troubles. + + +Sometimes, some packages never enter testing because the +set of inter-relationship is too complicated and cannot be sorted out by the +scripts. See below for details. + + +Some further dependency analysis is shown on — but be warned, this page also +shows build dependencies which are not considered by britney. + +
+out-of-date + +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. + + +Consider this example: + + + + + + +alpha +arm + + + + +testing +1 +- + + +unstable +1 +2 + + + + + +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. + + +However, if ftp-master removes a package in unstable (here on arm): + + + + + + +alpha +arm +hurd-i386 + + + + +testing +1 +1 +- + + +unstable +2 +- +1 + + + + + +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). + + +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.) + +
+ +
+Removals from testing + +Sometimes, a package is removed to allow another package in: This happens only +to allow another package to go in if it's ready in every +other sense. Suppose e.g. that a cannot be installed +with the new version of b; then a may +be removed to allow b in. + + +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). + + +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. + +
+ +
+circular dependencies + +A situation which is not handled very well by britney is if package +a depends on the new version of package +b, and vice versa. + + +An example of this is: + + + + + + +testing +unstable + + + + +a +1; depends: b=1 +2; depends: b=2 + + +b +1; depends: a=1 +2; depends: a=2 + + + + + +Neither package a nor package b is +considered for update. + + +Currently, this requires some manual hinting from the release team. Please +contact them by sending mail to debian-release@lists.debian.org +if this happens to one of your packages. + +
+ +
+influence of package in testing + +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. + + +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. + +
+ +
+details + +If you are interested in details, this is how britney works: + + +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.) + + +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.) + + +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 + + +The hints are available via . + +
+ +
+ +
+Direct updates to testing + +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 +testing-proposed-updates. + + +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 debian-devel-announce@lists.debian.org. + + +You should not upload to testing-proposed-updates when you +can update your packages through unstable. 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. + + +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. + + +Please make sure you didn't miss any of these items in your upload: + + + + +Make sure that your package really needs to go through +testing-proposed-updates, and can't go through unstable; + + + + +Make sure that you included only the minimal amount of changes; + + + + +Make sure that you included an appropriate explanation in the changelog; + + + + +Make sure that you've written testing or +testing-proposed-updates into your target distribution; + + + + +Make sure that you've built and tested your package in +testing, not in unstable; + + + + +Make sure that your version number is higher than the version in +testing and testing-proposed-updates, +and lower than in unstable; + + + + +After uploading and successful build on all platforms, contact the release team +at debian-release@lists.debian.org and ask them to approve your +upload. + + + +
+ +
+Frequently asked questions +
+What are release-critical bugs, and how do they get counted? + +All bugs of some higher severities are by default considered release-critical; +currently, these are critical, grave, and serious bugs. + + +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. + + +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. + + +This will change post-sarge, as soon as we have versions in the bug tracking +system. + +
+ +
+How could installing a package into testing possibly break other packages? + +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. + + +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. + + +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. + + +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. + + +If you are having problems with complicated groups of packages like this, +contact debian-devel or debian-release for help. + +
+ +
+ +
+ + + diff --git a/po4a/fr/best-pkging-practices.po b/po4a/fr/best-pkging-practices.po new file mode 100644 index 0000000..afae0ad --- /dev/null +++ b/po4a/fr/best-pkging-practices.po @@ -0,0 +1,2506 @@ +# SOME DESCRIPTIVE TITLE +# Copyright (C) YEAR Free Software Foundation, Inc. +# FIRST AUTHOR , YEAR. +# +#, fuzzy +msgid "" +msgstr "" +"Project-Id-Version: PACKAGE VERSION\n" +"POT-Creation-Date: 2007-06-26 16:13+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=utf-8\n" +"Content-Transfer-Encoding: ENCODING" + +# type: Content of: +#: best-pkging-practices.dbk:5 +msgid "Best Packaging Practices" +msgstr "" + +# type: Content of: <chapter><para> +#: best-pkging-practices.dbk:7 +msgid "" +"Debian's quality is largely due to the <ulink " +"url=\"http://www.debian.org/doc/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:16 +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:22 +msgid "Best practices for <filename>debian/rules</filename>" +msgstr "" + +# type: Content of: <chapter><section><para> +#: best-pkging-practices.dbk:24 +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:30 +msgid "Helper scripts" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:32 +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:43 +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:50 +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:64 +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:77 +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=\"http://arch.debian.org/arch/private/srivasta/\"></ulink>." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: best-pkging-practices.dbk:86 +msgid "Separating your patches into multiple files" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:88 +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:97 +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:107 +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:114 +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:122 +msgid "Multiple binary packages" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:124 +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:131 +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:140 +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:150 +msgid "Best practices for <filename>debian/control</filename>" +msgstr "" + +# type: Content of: <chapter><section><para> +#: best-pkging-practices.dbk:152 +msgid "" +"The following practices are relevant to the " +"<filename>debian/control</filename> file. They supplement the <ulink " +"url=\"http://www.debian.org/doc/debian-policy/ch-binary.html#s-descriptions\">Policy " +"on package descriptions</ulink>." +msgstr "" + +# type: Content of: <chapter><section><para> +#: best-pkging-practices.dbk:158 +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:167 +msgid "General guidelines for package descriptions" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:169 +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:176 +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:182 +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:189 +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:194 +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:201 +msgid "" +"If you are having problems writing your description, you may wish to send it " +"along to <email>debian-l10n-english@lists.debian.org</email> and request " +"feedback." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: best-pkging-practices.dbk:208 +msgid "The package synopsis, or short description" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:210 +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:214 +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:223 +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:227 +#, no-wrap +msgid "" +"<replaceable>package-name</replaceable> is a " +"<replaceable>synopsis</replaceable>." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:230 +msgid "Alternatively, it might make sense to think of it as" +msgstr "" + +# type: Content of: <chapter><section><section><screen> +#: best-pkging-practices.dbk:233 +#, no-wrap +msgid "" +"<replaceable>package-name</replaceable> is " +"<replaceable>synopsis</replaceable>." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:236 +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:239 +#, no-wrap +msgid "" +"<replaceable>package-name</replaceable> are " +"<replaceable>synopsis</replaceable>." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:242 +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:249 +msgid "The long description" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:251 +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:257 +msgid "The long description should consist of full and complete sentences." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:260 +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:266 +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:274 +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:279 +#, no-wrap +msgid "-d american -g debian/control" +msgstr "" + +# type: Content of: <chapter><section><section><screen> +#: best-pkging-practices.dbk:282 +#, no-wrap +msgid "-d en -D -c debian/control" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:285 +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:290 +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:296 +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:303 +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:309 +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:316 +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:325 +msgid "Upstream home page" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:327 +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:332 +#, no-wrap +msgid "" +".\n" +" Homepage: http://some-project.some-place.org/" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:336 +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=\"http://packages.debian.org/unstable/web/wml\"></ulink>." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:341 +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:344 +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.debian.org</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.debian.org</filename> to " +"parse it correctly." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: best-pkging-practices.dbk:355 +msgid "Version Control System location" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:357 +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:361 +msgid "XS-Vcs-Browser" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:363 +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:368 +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:375 +msgid "XS-Vcs-*" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:377 +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:388 +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:399 +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:407 +#, 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:421 +msgid "Best practices for <filename>debian/changelog</filename>" +msgstr "" + +# type: Content of: <chapter><section><para> +#: best-pkging-practices.dbk:423 +msgid "" +"The following practices supplement the <ulink " +"url=\"http://www.debian.org/doc/debian-policy/ch-docs.html#s-changelogs\">Policy " +"on changelog files</ulink>." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: best-pkging-practices.dbk:428 +msgid "Writing useful changelog entries" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:430 +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:435 +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:441 +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:448 +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:454 +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:460 +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:467 +msgid "Common misconceptions about changelog entries" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:469 +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:477 +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:482 +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:493 +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:501 +msgid "Common errors in changelog entries" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:503 +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:507 +#, no-wrap +msgid "* Fixed all outstanding bugs." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:510 +msgid "This doesn't tell readers anything too useful, obviously." +msgstr "" + +# type: Content of: <chapter><section><section><screen> +#: best-pkging-practices.dbk:513 +#, no-wrap +msgid "* Applied patch from Jane Random." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:516 +msgid "What was the patch about?" +msgstr "" + +# type: Content of: <chapter><section><section><screen> +#: best-pkging-practices.dbk:519 +#, no-wrap +msgid "* Late night install target overhaul." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:522 +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:526 +#, no-wrap +msgid "* Fix vsync FU w/ ancient CRTs." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:529 +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:533 +#, no-wrap +msgid "* This is not a bug, closes: #nnnnnn." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:536 +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:541 +#, 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:544 +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:551 +#, no-wrap +msgid "* Closes: #12345, #12346, #15432" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:554 +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:560 +msgid "Supplementing changelogs with NEWS.Debian files" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:562 +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:571 +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:579 +#, no-wrap +msgid "" +"(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:589 +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:595 +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:605 +msgid "Best practices for maintainer scripts" +msgstr "" + +# type: Content of: <chapter><section><para> +#: best-pkging-practices.dbk:607 +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=\"http://www.debian.org/doc/debian-policy/\">Debian Policy</ulink>." +msgstr "" + +# type: Content of: <chapter><section><para> +#: best-pkging-practices.dbk:615 +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:620 +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:624 +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:631 +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:638 +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:644 +msgid "" +"If you need to check for the existence of a command, you should use " +"something like" +msgstr "" + +# type: Content of: <chapter><section><screen> +#: best-pkging-practices.dbk:648 +#, no-wrap +msgid "[ -x /usr/sbin/install-docs ]; then ..." +msgstr "" + +# type: Content of: <chapter><section><para> +#: best-pkging-practices.dbk:651 +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><screen> +#: best-pkging-practices.dbk:655 +#, no-wrap +msgid "" +"() {\n" +" OLDIFS=$IFS\n" +" IFS=:\n" +" for p in $PATH; do\n" +" if [ -x $p/$* ]; then\n" +" IFS=$OLDIFS\n" +" return 0\n" +" fi\n" +" done\n" +" IFS=$OLDIFS\n" +" return 1\n" +"}" +msgstr "" + +# type: Content of: <chapter><section><para> +#: best-pkging-practices.dbk:669 +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:676 +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:686 +msgid "" +"Configuration management with <systemitem " +"role=\"package\">debconf</systemitem>" +msgstr "" + +# type: Content of: <chapter><section><para> +#: best-pkging-practices.dbk:688 +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:696 +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:703 +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:709 +msgid "Do not abuse debconf" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:711 +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:717 +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:723 +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:731 +msgid "General recommendations for authors and translators" +msgstr "" + +# type: Content of: <chapter><section><section><section><title> +#: best-pkging-practices.dbk:733 +msgid "Write correct English" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:735 +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:739 +msgid "" +"Please use (and abuse) <email>debian-l10n-english@lists.debian.org</email> " +"mailing list. Have your templates proofread." +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:743 +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:747 +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:755 +msgid "Be kind to translators" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:757 +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:762 +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:767 +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:776 +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:781 +msgid "" +"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@lists.debian.org</email> mailing list." +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:786 +msgid "" +"Calls for translations posted to <email>debian-i18n@lists.debian.org</email> " +"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:795 +msgid "Unfuzzy complete translations when correcting typos and spelling" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:797 +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:803 +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:807 +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:813 +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><screen> +#: best-pkging-practices.dbk:818 +#, no-wrap +msgid "" +"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:824 +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:831 +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:838 +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:844 +msgid "use the following command:" +msgstr "" + +# type: Content of: <chapter><section><section><section><orderedlist><listitem><screen> +#: best-pkging-practices.dbk:847 +#, no-wrap +msgid "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:852 +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:857 +msgid "run <command>debconf-updatepo</command> again" +msgstr "" + +# type: Content of: <chapter><section><section><section><title> +#: best-pkging-practices.dbk:864 +msgid "Do not make assumptions about interfaces" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:866 +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:871 +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:877 +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:883 +msgid "Do not use first person" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:885 +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:895 +msgid "Be gender neutral" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:897 +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:905 +msgid "Templates fields definition" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:907 +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:912 +msgid "Type" +msgstr "" + +# type: Content of: <chapter><section><section><section><section><title> +#: best-pkging-practices.dbk:914 +msgid "string:" +msgstr "" + +# type: Content of: <chapter><section><section><section><section><para> +#: best-pkging-practices.dbk:916 +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:921 +msgid "password:" +msgstr "" + +# type: Content of: <chapter><section><section><section><section><para> +#: best-pkging-practices.dbk:923 +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:930 +msgid "boolean:" +msgstr "" + +# type: Content of: <chapter><section><section><section><section><para> +#: best-pkging-practices.dbk:932 +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:938 +msgid "select:" +msgstr "" + +# type: Content of: <chapter><section><section><section><section><para> +#: best-pkging-practices.dbk:940 +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:947 +msgid "multiselect:" +msgstr "" + +# type: Content of: <chapter><section><section><section><section><para> +#: best-pkging-practices.dbk:949 +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:955 +msgid "note:" +msgstr "" + +# type: Content of: <chapter><section><section><section><section><para> +#: best-pkging-practices.dbk:957 +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:966 +msgid "text:" +msgstr "" + +# type: Content of: <chapter><section><section><section><section><para> +#: best-pkging-practices.dbk:968 +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:973 +msgid "error:" +msgstr "" + +# type: Content of: <chapter><section><section><section><section><para> +#: best-pkging-practices.dbk:975 +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:980 +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:988 +msgid "Description: short and extended description" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:990 +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:994 +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:1000 +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:1006 +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:1010 +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:1017 +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:1022 +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:1028 +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:1032 +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:1038 +msgid "Choices" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:1040 +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:1047 +msgid "Default" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:1049 +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:1058 +msgid "Templates fields specific style guide" +msgstr "" + +# type: Content of: <chapter><section><section><section><title> +#: best-pkging-practices.dbk:1060 +msgid "Type field" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:1062 +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:1068 +msgid "Description field" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:1070 +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:1074 +msgid "String/password templates" +msgstr "" + +# type: Content of: <chapter><section><section><section><section><itemizedlist><listitem><para> +#: best-pkging-practices.dbk:1078 +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:1085 +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:1095 +msgid "Boolean templates" +msgstr "" + +# type: Content of: <chapter><section><section><section><section><itemizedlist><listitem><para> +#: best-pkging-practices.dbk:1099 +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:1107 +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:1115 +msgid "Select/Multiselect" +msgstr "" + +# type: Content of: <chapter><section><section><section><section><itemizedlist><listitem><para> +#: best-pkging-practices.dbk:1119 +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:1127 +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:1137 +msgid "Notes" +msgstr "" + +# type: Content of: <chapter><section><section><section><section><itemizedlist><listitem><para> +#: best-pkging-practices.dbk:1141 +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:1146 +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:1152 +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:1167 +msgid "Choices field" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:1169 +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:1176 best-pkging-practices.dbk:1214 +msgid "Default field" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:1178 +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:1183 +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:1189 +msgid "Example, taken from the geneweb package templates:" +msgstr "" + +# type: Content of: <chapter><section><section><section><screen> +#: best-pkging-practices.dbk:1192 +#, no-wrap +msgid "" +": 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:1203 +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:1208 +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:1216 +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:1220 +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:1225 +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:1237 +msgid "Internationalization" +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: best-pkging-practices.dbk:1239 +msgid "Handling debconf translations" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:1241 +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:1247 +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:1257 +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:1273 +msgid "Internationalized documentation" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:1275 +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:1280 +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=\"http://cvs.debian.org/boot-floppies/documentation/doc-check?rev=HEAD\\|[amp " +"]\\|content-type=text/vnd.viewcvs-markup\">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:1295 +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:1305 +msgid "Common packaging situations" +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: best-pkging-practices.dbk:1307 +msgid "Packages using <command>autoconf</command>/<command>automake</command>" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:1309 +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 " +"<filename>/usr/share/doc/autotools-dev/README.Debian.gz</filename> 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:1321 +msgid "Libraries" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:1323 +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:1329 +msgid "" +"Good practices for library packaging have been grouped in <ulink " +"url=\"http://www.netfort.gr.jp/~dancer/column/libpkg-guide/\">the library " +"packaging guide</ulink>." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: best-pkging-practices.dbk:1336 +msgid "Documentation" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:1338 +msgid "" +"Be sure to follow the <ulink " +"url=\"http://www.debian.org/doc/debian-policy/ch-docs.html\">Policy on " +"documentation</ulink>." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:1343 +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:1348 +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:1355 +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:1363 +msgid "Specific types of packages" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:1365 +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:1371 +msgid "" +"Perl related packages have a <ulink " +"url=\"http://www.debian.org/doc/packaging-manuals/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:1380 +msgid "" +"Python related packages have their python policy; see " +"<filename>/usr/share/doc/python/python-policy.txt.gz</filename> in the " +"<systemitem role=\"package\">python</systemitem> package." +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: best-pkging-practices.dbk:1387 +msgid "" +"Emacs related packages have the <ulink " +"url=\"http://www.debian.org/doc/packaging-manuals/debian-emacs-policy\">emacs " +"policy</ulink>." +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: best-pkging-practices.dbk:1394 +msgid "" +"Java related packages have their <ulink " +"url=\"http://www.debian.org/doc/packaging-manuals/java-policy/\">java " +"policy</ulink>." +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: best-pkging-practices.dbk:1401 +msgid "" +"Ocaml related packages have their own policy, found in " +"<filename>/usr/share/doc/ocaml/ocaml_packaging_policy.gz</filename> 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:1409 +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:1415 +msgid "" +"Lisp packages should register themselves with <systemitem " +"role=\"package\">common-lisp-controller</systemitem>, about which see " +"<filename>/usr/share/doc/common-lisp-controller/README.packaging</filename>." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: best-pkging-practices.dbk:1424 +msgid "Architecture-independent data" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:1426 +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:1433 +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:1445 +msgid "Needing a certain locale during build" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:1447 +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:1451 +msgid "" +"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:" +msgstr "" + +# type: Content of: <chapter><section><section><screen> +#: best-pkging-practices.dbk:1456 +#, no-wrap +msgid "" +"=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:1469 +msgid "Make transition packages deborphan compliant" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:1471 +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:1478 +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:1484 +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:" +msgstr "" + +# type: Content of: <chapter><section><section><screen> +#: best-pkging-practices.dbk:1488 +#, no-wrap +msgid "-cache search .|grep dummy" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:1491 +msgid "or" +msgstr "" + +# type: Content of: <chapter><section><section><screen> +#: best-pkging-practices.dbk:1494 +#, no-wrap +msgid "-cache search .|grep transitional" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:1497 +msgid "." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: best-pkging-practices.dbk:1502 +msgid "Best practices for <filename>orig.tar.gz</filename> files" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:1504 +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:1508 +msgid "Pristine source" +msgstr "" + +# type: Content of: <chapter><section><section><section><para><footnote> +#: best-pkging-practices.dbk:1510 +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:1512 +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:1522 +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:1530 +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:1538 +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:1541 +#, no-wrap +msgid "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:1546 +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:1555 +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:1566 +msgid "Repackaged upstream source" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:1568 +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:1575 +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:1584 +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:1593 +msgid "A repackaged .orig.tar.gz" +msgstr "" + +# type: Content of: <chapter><section><section><section><orderedlist><listitem><para> +#: best-pkging-practices.dbk:1598 +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=\"http://www.debian.org/doc/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:1610 +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> +#: best-pkging-practices.dbk:1612 +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:1623 +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:1632 +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:1639 +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:1647 +msgid "" +"<emphasis role=\"strong\">should</emphasis> be gzipped with maximal " +"compression." +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:1652 +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:1658 +msgid "Changing binary files in <literal>diff.gz</literal>" +msgstr "" + +# type: Content of: <chapter><section><section><section><para><footnote> +#: best-pkging-practices.dbk:1660 +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:1667 +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><footnote><screen> +#: best-pkging-practices.dbk:1673 +#, no-wrap +msgid "" +"-file: perl -ne 'print(pack u, $$_);'\n" +"$(file) > $(file).uuencoded uudecode-file: perl -ne 'print(unpack u, " +"$$_);'\n" +"$(file).uuencoded > $(file)" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:1675 +msgid "" +"</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:1680 +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:1693 +msgid "Best practices for debug packages" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:1695 +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:1703 +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:1713 +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:1725 +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:1732 +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:1739 +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:1743 +#, no-wrap +msgid ": libfoo-dbg (= ${binary:Version})" +msgstr "" diff --git a/po4a/fr/beyond-pkging.po b/po4a/fr/beyond-pkging.po new file mode 100644 index 0000000..586c3ca --- /dev/null +++ b/po4a/fr/beyond-pkging.po @@ -0,0 +1,572 @@ +# 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-06-26 16:13+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:5 +msgid "Beyond Packaging" +msgstr "" + +# type: Content of: <chapter><para> +#: beyond-pkging.dbk:7 +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:12 +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:17 +msgid "Bug reporting" +msgstr "" + +# type: Content of: <chapter><section><para> +#: beyond-pkging.dbk:19 +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:24 +msgid "" +"Read the <ulink url=\"http://www.debian.org/Bugs/Reporting\">instructions " +"for reporting bugs</ulink> in the Debian <ulink " +"url=\"http://www.debian.org/Bugs/\">bug tracking system</ulink>." +msgstr "" + +# type: Content of: <chapter><section><para> +#: beyond-pkging.dbk:29 +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:34 +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:39 +msgid "" +"Make sure the bug is not already filed against a package. Each package has " +"a bug list easily reachable at " +"<literal>http://bugs.debian.org/<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:48 +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:54 +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:61 +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.debian.org/from:<replaceable><your-email-addr></replaceable></literal>." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: beyond-pkging.dbk:68 +msgid "Reporting lots of bugs at once (mass bug filing)" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: beyond-pkging.dbk:70 +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:77 +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@lists.debian.org</email> " +"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:85 +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@lists.debian.org</email>." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: beyond-pkging.dbk:91 +msgid "" +"Note that when sending lots of bugs on the same subject, you should send the " +"bug report to <email>maintonly@bugs.debian.org</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:100 +msgid "Quality Assurance effort" +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: beyond-pkging.dbk:102 +msgid "Daily work" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: beyond-pkging.dbk:104 +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@lists.debian.org</email> or " +"<email>debian-devel@lists.debian.org</email>). 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:118 +msgid "Bug squashing parties" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: beyond-pkging.dbk:120 +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@lists.debian.org</email> 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:129 +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:138 +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:145 +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:153 +msgid "Contacting other maintainers" +msgstr "" + +# type: Content of: <chapter><section><para> +#: beyond-pkging.dbk:155 +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:161 +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.debian.org</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:169 +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>@packages.qa.debian.org</literal> " +"email address." +msgstr "" + +# type: Content of: <chapter><section><title> +#: beyond-pkging.dbk:177 +msgid "Dealing with inactive and/or unreachable maintainers" +msgstr "" + +# type: Content of: <chapter><section><para> +#: beyond-pkging.dbk:179 +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:186 +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" +msgstr "" + +# type: Content of: <chapter><section><screen> +#: beyond-pkging.dbk:194 +#, no-wrap +msgid "-query --help" +msgstr "" + +# type: Content of: <chapter><section><para> +#: beyond-pkging.dbk:197 +msgid "" +"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:202 +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:208 +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:216 +msgid "" +"The echelon information available through the <ulink " +"url=\"https://db.debian.org/\">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:225 +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:234 +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:241 +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:249 +msgid "" +"It is also allowed to post a query to " +"<email>debian-devel@lists.debian.org</email>, 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:254 +msgid "" +"Once you have gathered all of this, you can contact " +"<email>mia@qa.debian.org</email>. 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:262 +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:270 +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:276 +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@qa.debian.org</email>." +msgstr "" + +# type: Content of: <chapter><section><title> +#: beyond-pkging.dbk:284 +msgid "Interacting with prospective Debian developers" +msgstr "" + +# type: Content of: <chapter><section><para> +#: beyond-pkging.dbk:286 +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:292 +msgid "Sponsoring packages" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: beyond-pkging.dbk:294 +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:299 +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:306 +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:313 +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:320 +msgid "Managing sponsored packages" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: beyond-pkging.dbk:322 +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:327 +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:336 +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:341 +msgid "Once the package meets Debian standards, build and sign it with" +msgstr "" + +# type: Content of: <chapter><section><section><screen> +#: beyond-pkging.dbk:344 +#, no-wrap +msgid "-buildpackage -k<replaceable>KEY-ID</replaceable>" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: beyond-pkging.dbk:347 +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:352 +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:358 +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:362 +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:368 +msgid "Advocating new developers" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: beyond-pkging.dbk:370 +msgid "" +"See the page about <ulink " +"url=\"http://www.debian.org/devel/join/nm-advocate\">advocating a " +"prospective developer</ulink> at the Debian web site." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: beyond-pkging.dbk:377 +msgid "Handling new maintainer applications" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: beyond-pkging.dbk:379 +msgid "" +"Please see <ulink " +"url=\"http://www.debian.org/devel/join/nm-amchecklist\">Checklist for " +"Application Managers</ulink> at the Debian web site." +msgstr "" diff --git a/po4a/fr/developer-duties.po b/po4a/fr/developer-duties.po new file mode 100644 index 0000000..487ca81 --- /dev/null +++ b/po4a/fr/developer-duties.po @@ -0,0 +1,314 @@ +# 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-06-26 16:13+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:5 +msgid "Debian Developer's Duties" +msgstr "" + +# type: Content of: <chapter><section><title> +#: developer-duties.dbk:7 +msgid "Maintaining your Debian information" +msgstr "" + +# type: Content of: <chapter><section><para> +#: developer-duties.dbk:9 +msgid "" +"There's a LDAP database containing information about Debian developers at " +"<ulink url=\"https://db.debian.org/\"></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:17 +msgid "" +"For more information about the database, please see <xref " +"linkend=\"devel-db\"/> ." +msgstr "" + +# type: Content of: <chapter><section><title> +#: developer-duties.dbk:23 +msgid "Maintaining your public key" +msgstr "" + +# type: Content of: <chapter><section><para> +#: developer-duties.dbk:25 +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=\"http://www.cam.ac.uk.pgp.net/pgpnet/pgp-faq/\">PGP FAQ</ulink>." +msgstr "" + +# type: Content of: <chapter><section><para> +#: developer-duties.dbk:32 +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:38 +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>keyring.debian.org</literal>." +msgstr "" + +# type: Content of: <chapter><section><para> +#: developer-duties.dbk:43 +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://keyring.debian.org/replacing_keys.html\"></ulink>." +msgstr "" + +# type: Content of: <chapter><section><para> +#: developer-duties.dbk:51 +msgid "" +"The same key extraction routines discussed in <xref " +"linkend=\"registering\"/> apply." +msgstr "" + +# type: Content of: <chapter><section><para> +#: developer-duties.dbk:55 +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:62 +msgid "Voting" +msgstr "" + +# type: Content of: <chapter><section><para> +#: developer-duties.dbk:64 +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=\"http://www.debian.org/devel/constitution\">Debian " +"Constitution</ulink>." +msgstr "" + +# type: Content of: <chapter><section><para> +#: developer-duties.dbk:70 +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@lists.debian.org</email> 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:76 +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@lists.debian.org</email> (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:84 +msgid "" +"The list of all proposals (past and current) is available on the <ulink " +"url=\"http://www.debian.org/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:91 +msgid "Going on vacation gracefully" +msgstr "" + +# type: Content of: <chapter><section><para> +#: developer-duties.dbk:93 +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:100 +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:107 +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.debian.org</email> with [VAC] prepended to the " +"subject of your message<footnote>" +msgstr "" + +# type: Content of: <chapter><section><para><footnote><para> +#: developer-duties.dbk:109 +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:111 +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:116 +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:122 +msgid "" +"Ideally, you should sign up at the <ulink " +"url=\"http://nm.debian.org/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:131 +msgid "Coordination with upstream developers" +msgstr "" + +# type: Content of: <chapter><section><para> +#: developer-duties.dbk:133 +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:140 +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:147 +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:156 +msgid "Managing release-critical bugs" +msgstr "" + +# type: Content of: <chapter><section><para> +#: developer-duties.dbk:158 +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:169 +msgid "" +"Developers who are part of the <ulink url=\"http://qa.debian.org/\">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.debian.org</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:184 +msgid "Retiring" +msgstr "" + +# type: Content of: <chapter><section><para> +#: developer-duties.dbk:186 +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:192 +msgid "Orphan all your packages, as described in <xref linkend=\"orphaning\"/> ." +msgstr "" + +# type: Content of: <chapter><section><orderedlist><listitem><para> +#: developer-duties.dbk:197 +msgid "" +"Send an gpg-signed email about why you are leaving the project to " +"<email>debian-private@lists.debian.org</email>." +msgstr "" + +# type: Content of: <chapter><section><orderedlist><listitem><para> +#: developer-duties.dbk:203 +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 "" diff --git a/po4a/fr/index.po b/po4a/fr/index.po new file mode 100644 index 0000000..b328a2e --- /dev/null +++ b/po4a/fr/index.po @@ -0,0 +1,87 @@ +# 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-06-26 16:13+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:4 +msgid "en" +msgstr "" + +# type: Content of: <book><title> +#: index.dbk:6 +msgid "Debian Developer's Reference" +msgstr "" + +# type: Content of: <book><bookinfo><releaseinfo> +#: index.dbk:27 +msgid "ver. 3.3.9, 16 June, 2007" +msgstr "" + +# type: Content of: <book><bookinfo><copyright><holder> +#: index.dbk:34 +msgid "Andreas Barth" +msgstr "" + +# type: Content of: <book><bookinfo><copyright><holder> +#: index.dbk:43 +msgid "Adam Di Carlo" +msgstr "" + +# type: Content of: <book><bookinfo><copyright><holder> +#: index.dbk:48 +msgid "Raphaël Hertzog" +msgstr "" + +# type: Content of: <book><bookinfo><copyright><holder> +#: index.dbk:53 +msgid "Christian Schwarz" +msgstr "" + +# type: Content of: <book><bookinfo><legalnotice><para> +#: index.dbk:57 +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:62 +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:68 +msgid "" +"A copy of the GNU General Public License is available as " +"<filename>/usr/share/common-licenses/GPL</filename> in the Debian GNU/Linux " +"distribution or on the World Wide Web at <ulink " +"url=\"http://www.gnu.org/copyleft/gpl.html\">the GNU web site</ulink>. You " +"can also obtain it by writing to the Free Software Foundation, Inc., 51 " +"Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA." +msgstr "" + +# type: Content of: <book><bookinfo><legalnotice><para> +#: index.dbk:76 +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 "" diff --git a/po4a/fr/l10n.po b/po4a/fr/l10n.po new file mode 100644 index 0000000..d09b196 --- /dev/null +++ b/po4a/fr/l10n.po @@ -0,0 +1,342 @@ +# 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-06-26 16:13+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:5 +msgid "" +"Internationalizing, translating, being internationalized and being " +"translated" +msgstr "" + +# type: Content of: <chapter><para> +#: l10n.dbk:7 +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:15 +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:24 +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:32 +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:38 +msgid "How translations are handled within Debian" +msgstr "" + +# type: Content of: <chapter><section><para> +#: l10n.dbk:40 +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:44 +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:57 +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:64 +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:72 +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:76 +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:81 +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:85 +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:89 +msgid "" +"There is an effort to handle Debian-specific man pages within a <ulink " +"url=\"http://cvs.debian.org/manpages/?cvsroot=debian-doc\">specific CVS " +"repository</ulink>." +msgstr "" + +# type: Content of: <chapter><section><title> +#: l10n.dbk:96 +msgid "I18N & L10N FAQ for maintainers" +msgstr "" + +# type: Content of: <chapter><section><para> +#: l10n.dbk:98 +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:105 +msgid "How to get a given text translated" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: l10n.dbk:107 +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:112 +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:122 +msgid "How to get a given translation reviewed" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: l10n.dbk:124 +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:134 +msgid "How to get a given translation updated" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: l10n.dbk:136 +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:142 +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:148 +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:155 +msgid "How to handle a bug report concerning a translation" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: l10n.dbk:157 +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:166 +msgid "I18N & L10N FAQ for translators" +msgstr "" + +# type: Content of: <chapter><section><para> +#: l10n.dbk:168 +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:173 +msgid "How to help the translation effort" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: l10n.dbk:175 +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:183 +msgid "How to provide a translation for inclusion in a package" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: l10n.dbk:185 +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:191 +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:201 +msgid "Best current practice concerning l10n" +msgstr "" + +# type: Content of: <chapter><section><itemizedlist><listitem><para> +#: l10n.dbk:205 +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:213 +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:220 +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:230 +msgid "" +"In any case, cooperation can only be achieved with <emphasis " +"role=\"strong\">mutual respect</emphasis>." +msgstr "" diff --git a/po4a/fr/new-maintainer.po b/po4a/fr/new-maintainer.po new file mode 100644 index 0000000..a48fcef --- /dev/null +++ b/po4a/fr/new-maintainer.po @@ -0,0 +1,333 @@ +# 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-06-26 16:13+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:5 +msgid "Applying to Become a Maintainer" +msgstr "" + +# type: Content of: <chapter><section><title> +#: new-maintainer.dbk:7 +msgid "Getting started" +msgstr "" + +# type: Content of: <chapter><section><para> +#: new-maintainer.dbk:9 +msgid "" +"So, you've read all the documentation, you've gone through the <ulink " +"url=\"http://www.debian.org/doc/maint-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:17 +msgid "" +"Firstly, subscribe to <email>debian-devel@lists.debian.org</email> if you " +"haven't already. Send the word <literal>subscribe</literal> in the " +"<emphasis>Subject</emphasis> of an email to " +"<email>debian-devel-REQUEST@lists.debian.org</email>. In case of problems, " +"contact the list administrator at " +"<email>listmaster@lists.debian.org</email>. More information on available " +"mailing lists can be found in <xref linkend=\"mailing-lists\"/> . " +"<email>debian-devel-announce@lists.debian.org</email> 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:28 +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:33 +msgid "" +"Another good list to subscribe to is " +"<email>debian-mentors@lists.debian.org</email>. 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:39 +msgid "" +"When you know how you want to contribute to Debian GNU/Linux, 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@lists.debian.org</email> mailing list, describing your " +"package and yourself and asking for a sponsor (see <xref " +"linkend=\"sponsoring\"/> and <ulink " +"url=\"http://people.debian.org/~mpalmer/debian-mentors_FAQ.html\"></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=\"http://www.debian.org/MailingLists/\"></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@lists.debian.org</email> 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> +#: 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=\"http://people.debian.org/~mpalmer/debian-mentors_FAQ.html\"></ulink> " +"first." +msgstr "" + +# type: Content of: <chapter><section><para> +#: new-maintainer.dbk:84 +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:90 +msgid "Registering as a Debian developer" +msgstr "" + +# type: Content of: <chapter><section><para> +#: new-maintainer.dbk:92 +msgid "" +"Before you decide to register with Debian GNU/Linux, you will need to read " +"all the information available at the <ulink " +"url=\"http://www.debian.org/devel/join/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=\"http://www.debian.org/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 GNU/Linux. " +"Reading the <ulink url=\"http://www.gnu.org/gnu/manifesto.html\">GNU " +"Manifesto</ulink> would also be a good idea." +msgstr "" + +# type: Content of: <chapter><section><para> +#: new-maintainer.dbk:105 +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 GNU/Linux has grown to over 900 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:113 +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:122 +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=\"http://nm.debian.org/gpg.php\">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=\"http://www.debian.org/devel/join/nm-step2\">identification " +"page</ulink> for more information.)" +msgstr "" + +# type: Content of: <chapter><section><para> +#: new-maintainer.dbk:135 +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:143 +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=\"http://www.rfc-editor.org/rfc/rfc2440.txt\">RFC 2440</ulink>." +msgstr "" + +# type: Content of: <chapter><section><para><footnote> +#: new-maintainer.dbk:150 +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:152 +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:156 +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:160 +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 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 " +"<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:167 +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:169 +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:175 +msgid "" +"If your public key isn't on a public key server such as " +"<literal>subkeys.pgp.net</literal>, please read the documentation available " +"at <ulink url=\"http://www.debian.org/devel/join/nm-step2\">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:183 +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:191 +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:198 +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=\"http://nm.debian.org/newnm.php\">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=\"http://nm.debian.org/\">applications status board</ulink>." +msgstr "" + +# type: Content of: <chapter><section><para> +#: new-maintainer.dbk:208 +msgid "" +"For more details, please consult <ulink " +"url=\"http://www.debian.org/devel/join/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 "" diff --git a/po4a/fr/pkgs.po b/po4a/fr/pkgs.po new file mode 100644 index 0000000..994e65d --- /dev/null +++ b/po4a/fr/pkgs.po @@ -0,0 +1,3519 @@ +# 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-06-26 16:13+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:5 +msgid "Managing Packages" +msgstr "" + +# type: Content of: <chapter><para> +#: pkgs.dbk:7 +msgid "" +"This chapter contains information related to creating, uploading, " +"maintaining, and porting packages." +msgstr "" + +# type: Content of: <chapter><section><title> +#: pkgs.dbk:11 +msgid "New packages" +msgstr "" + +# type: Content of: <chapter><section><para> +#: pkgs.dbk:13 +msgid "" +"If you want to create a new package for the Debian distribution, you should " +"first check the <ulink " +"url=\"http://www.debian.org/devel/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=\"http://www.debian.org/devel/wnpp/\">WNPP " +"web pages</ulink> for more information." +msgstr "" + +# type: Content of: <chapter><section><para> +#: pkgs.dbk:21 +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:29 +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@lists.debian.org</email> 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:39 +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:45 +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:53 +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:59 +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:65 +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:71 +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:78 +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:84 +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:90 +msgid "" +"Please see <ulink " +"url=\"http://ftp-master.debian.org/REJECT-FAQ.html\"></ulink> for common " +"rejection reasons for a new package." +msgstr "" + +# type: Content of: <chapter><section><title> +#: pkgs.dbk:96 +msgid "Recording changes in the package" +msgstr "" + +# type: Content of: <chapter><section><para> +#: pkgs.dbk:98 +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:109 +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:117 +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:121 +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:125 +#, no-wrap +msgid "* new upstream version" +msgstr "" + +# type: Content of: <chapter><section><para> +#: pkgs.dbk:128 +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:133 +msgid "See also <xref linkend=\"bpp-debian-changelog\"/> ." +msgstr "" + +# type: Content of: <chapter><section><title> +#: pkgs.dbk:138 +msgid "Testing the package" +msgstr "" + +# type: Content of: <chapter><section><para> +#: pkgs.dbk:140 +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:147 +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:154 +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:163 +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:167 +msgid "" +"For more information on <command>lintian</command>, see <xref " +"linkend=\"lintian\"/> ." +msgstr "" + +# type: Content of: <chapter><section><itemizedlist><listitem><para> +#: pkgs.dbk:173 +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:179 +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:185 +msgid "Remove the package, then reinstall it." +msgstr "" + +# type: Content of: <chapter><section><itemizedlist><listitem><para> +#: pkgs.dbk:190 +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:200 +msgid "Layout of the source package" +msgstr "" + +# type: Content of: <chapter><section><para> +#: pkgs.dbk:202 +msgid "There are two types of Debian source packages:" +msgstr "" + +# type: Content of: <chapter><section><itemizedlist><listitem><para> +#: pkgs.dbk:207 +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:213 +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:219 +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:227 +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:233 +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:240 +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:248 +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:255 +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:262 +msgid "Picking a distribution" +msgstr "" + +# type: Content of: <chapter><section><para> +#: pkgs.dbk:264 +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:270 +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:275 +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:280 +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:284 +msgid "Special case: uploads to the <emphasis>stable</emphasis> distribution" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:286 +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:294 +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:301 +msgid "a truly critical functionality problem" +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: pkgs.dbk:306 +msgid "the package becomes uninstallable" +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: pkgs.dbk:311 +msgid "a released architecture lacks the package" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:316 +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:324 +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:328 +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:338 +msgid "" +"The Release Team (which can be reached at " +"<email>debian-release@lists.debian.org</email>) 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:347 +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:355 +msgid "" +"Special case: uploads to " +"<emphasis>testing/testing-proposed-updates</emphasis>" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:357 +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:365 +msgid "Uploading a package" +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: pkgs.dbk:367 +msgid "Uploading to <literal>ftp-master</literal>" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:369 +msgid "" +"To upload a package, you should upload the files (including the signed " +"changes and dsc-file) with anonymous ftp to " +"<literal>ftp-master.debian.org</literal> in the directory <ulink " +"url=\"ftp://ftp-master.debian.org/pub/UploadQueue/\">/pub/UploadQueue/</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:377 +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:382 +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:387 +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:393 +msgid "Uploading to <literal>non-US</literal>" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:395 +msgid "" +"<emphasis>Note:</emphasis> non-us was discontinued with the release of " +"sarge." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: pkgs.dbk:400 +msgid "Delayed uploads" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:402 +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:407 +msgid "With a fairly recent dput, this section" +msgstr "" + +# type: Content of: <chapter><section><section><screen> +#: pkgs.dbk:410 +#, 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:416 +msgid "in ~/.dput.cf should work fine for uploading to the DELAYED queue." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:419 +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:426 +msgid "Security uploads" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:428 +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:438 +msgid "Other upload queues" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:440 +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:444 +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:448 +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:454 +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:461 +msgid "Notification that a new package has been installed" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:463 +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:472 +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:478 +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:483 +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:491 +msgid "Specifying the package section, subsection and priority" +msgstr "" + +# type: Content of: <chapter><section><para> +#: pkgs.dbk:493 +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:501 +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:511 +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-change@debian.org</email> 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:519 +msgid "" +"For more information about <emphasis>override files</emphasis>, see " +"<citerefentry> <refentrytitle>dpkg-scanpackages</refentrytitle> " +"<manvolnum>1</manvolnum> </citerefentry> and <ulink " +"url=\"http://www.debian.org/Bugs/Developer#maintincorrect\"></ulink>." +msgstr "" + +# type: Content of: <chapter><section><para> +#: pkgs.dbk:525 +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=\"http://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections\"></ulink>." +msgstr "" + +# type: Content of: <chapter><section><title> +#: pkgs.dbk:534 +msgid "Handling bugs" +msgstr "" + +# type: Content of: <chapter><section><para> +#: pkgs.dbk:536 +msgid "" +"Every developer has to be able to work with the Debian <ulink " +"url=\"http://www.debian.org/Bugs/\">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:542 +msgid "" +"The bug tracking system's features are described in the <ulink " +"url=\"http://www.debian.org/Bugs/Developer\">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:548 +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=\"http://www.debian.org/Bugs/server-control\">BTS control server " +"documentation</ulink>." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: pkgs.dbk:556 +msgid "Monitoring bugs" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:558 +msgid "" +"If you want to be a good maintainer, you should periodically check the " +"<ulink url=\"http://www.debian.org/Bugs/\">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.debian.org/<replaceable>yourlogin</replaceable>@debian.org</literal>." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:565 +msgid "" +"Maintainers interact with the BTS via email addresses at " +"<literal>bugs.debian.org</literal>. Documentation on available commands can " +"be found at <ulink url=\"http://www.debian.org/Bugs/\"></ulink>, or, if you " +"have installed the <systemitem role=\"package\">doc-debian</systemitem> " +"package, you can look at the local files " +"<filename>/usr/share/doc/debian/bug-*</filename>." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:572 +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:577 +#, no-wrap +msgid "" +"# ask for weekly reports of bugs in my packages\n" +"0 17 * * fri echo index maint <replaceable>address</replaceable> | mail " +"request@bugs.debian.org" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:581 +msgid "" +"Replace <replaceable>address</replaceable> with your official Debian " +"maintainer address." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: pkgs.dbk:587 +msgid "Responding to bugs" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:589 +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.debian.org</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.debian.org</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.debian.org</email>)." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:598 +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:602 +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.debian.org</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:609 +msgid "" +"You should <emphasis>never</emphasis> close bugs via the bug server " +"<literal>close</literal> command sent to " +"<email>control@bugs.debian.org</email>. 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:617 +msgid "Bug housekeeping" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:619 +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=\"http://www.debian.org/Bugs/Developer\">BTS documentation for Debian " +"developers</ulink>. Operations such as reassigning, merging, and tagging " +"bug reports are described in the <ulink " +"url=\"http://www.debian.org/Bugs/server-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:630 +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:635 +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:640 +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:650 +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=\"http://www.debian.org/devel/tech-ctte\">recommended procedure</ulink>." +msgstr "" + +# type: Content of: <chapter><section><section><orderedlist><listitem><para> +#: pkgs.dbk:664 +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@lists.debian.org</email>. 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:672 +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:680 +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:691 +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:702 +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@lists.debian.org</email> or " +"<email>debian-qa@lists.debian.org</email>. 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:716 +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:726 +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:735 +msgid "When bugs are closed by new uploads" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:737 +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:745 +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:751 +#, no-wrap +msgid "" +"-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:759 +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:763 +#, no-wrap +msgid "/closes:\\s*(?:bug)?\\#\\s*\\d+(?:,\\s*(?:bug)?\\#\\s*\\d+)*/ig" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:766 +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:775 +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:781 +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>control@bugs.debian.org</email>. To close " +"any remaining bugs that were fixed by your upload, email the " +"<filename>.changes</filename> file to " +"<email>XXX-done@bugs.debian.org</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:793 +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.debian.org</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:801 +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:807 +msgid "Handling security-related bugs" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:809 +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:816 +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>team@security.debian.org</email> 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:826 +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:833 +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:838 +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:845 +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:851 +msgid "" +"Any information needed for the advisory (see <xref " +"linkend=\"bug-security-advisories\"/> )" +msgstr "" + +# type: Content of: <chapter><section><section><section><title> +#: pkgs.dbk:857 +msgid "Confidentiality" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:859 +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:866 +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:871 +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:876 +msgid "someone files a bug report" +msgstr "" + +# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> +#: pkgs.dbk:881 +msgid "someone informs them via private email" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:886 +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:894 +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:900 +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:907 +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:914 +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:920 +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:927 +msgid "Security Advisories" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:929 +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@lists.debian.org</email> mailing list and " +"posted on <ulink url=\"http://www.debian.org/security/\">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:942 +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:947 +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:952 +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:957 +msgid "How it can be exploited" +msgstr "" + +# type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para> +#: pkgs.dbk:962 +msgid "Whether it is remotely or locally exploitable" +msgstr "" + +# type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para> +#: pkgs.dbk:967 +msgid "How the problem was fixed" +msgstr "" + +# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> +#: pkgs.dbk:972 +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:977 +msgid "Version numbers of affected packages" +msgstr "" + +# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> +#: pkgs.dbk:982 +msgid "Version numbers of fixed packages" +msgstr "" + +# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> +#: pkgs.dbk:987 +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:993 +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:1002 +msgid "Preparing packages to address security issues" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:1004 +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:1009 +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:1017 +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:1023 +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:1030 +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:1037 +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:1047 +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:1055 +msgid "Be sure to verify the following items:" +msgstr "" + +# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> +#: pkgs.dbk:1060 +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:1070 +msgid "The upload should have urgency=high." +msgstr "" + +# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> +#: pkgs.dbk:1075 +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:1087 +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:1099 +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:1108 +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:1117 +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:1124 +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:1135 +msgid "Uploading the fixed package" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:1137 +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:1144 +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:1153 +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:1159 +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:1164 +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:1169 +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:1180 +msgid "Moving, removing, renaming, adopting, and orphaning packages" +msgstr "" + +# type: Content of: <chapter><section><para> +#: pkgs.dbk:1182 +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:1187 +msgid "Moving packages" +msgstr "" + +# type: Content of: <chapter><section><section><para><footnote> +#: pkgs.dbk:1189 +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:1191 +msgid "" +"See the <ulink url=\"http://www.debian.org/doc/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:1196 +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=\"http://www.debian.org/doc/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:1208 +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:1217 +msgid "Removing packages" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:1219 +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:1232 +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:1241 +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:1247 +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:1252 +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=\"http://qa.debian.org/howto-remove.html\"></ulink>." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:1257 +msgid "" +"If in doubt concerning whether a package is disposable, email " +"<email>debian-devel@lists.debian.org</email> 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@lists.debian.org</email>." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:1268 +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:1275 +msgid "Removing packages from <filename>Incoming</filename>" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:1277 +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:1292 +msgid "Replacing or renaming packages" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:1294 +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=\"http://www.debian.org/doc/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:1304 +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:1318 +msgid "Orphaning a package" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:1320 +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 " +"<packages@qa.debian.org></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@lists.debian.org</email> 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:1335 +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:1343 +msgid "" +"More information is on the <ulink " +"url=\"http://www.debian.org/devel/wnpp/\">WNPP web pages</ulink>." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: pkgs.dbk:1349 +msgid "Adopting a package" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:1351 +msgid "" +"A list of packages in need of a new maintainer is available in the <ulink " +"url=\"http://www.debian.org/devel/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:1358 +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:1364 +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=\"http://www.debian.org/devel/tech-ctte\">technical committee web " +"page</ulink> for more information)." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:1374 +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:1388 +msgid "Porting and being ported" +msgstr "" + +# type: Content of: <chapter><section><para> +#: pkgs.dbk:1390 +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:1396 +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 12 more builds." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: pkgs.dbk:1404 +msgid "Being kind to porters" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:1406 +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:1414 +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:1421 +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:1428 +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:1442 +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:1446 +msgid "" +"See the <ulink url=\"http://www.debian.org/doc/debian-policy/\">Debian " +"Policy Manual</ulink> for instructions on setting build dependencies." +msgstr "" + +# type: Content of: <chapter><section><section><orderedlist><listitem><para> +#: pkgs.dbk:1452 +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=\"http://www.debian.org/doc/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:1460 +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:1468 +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:1476 +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:1485 +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:1491 +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:1499 +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:1510 +msgid "Guidelines for porter uploads" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:1512 +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:1520 +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:1525 +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:1533 +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:1540 +msgid "Recompilation or binary-only NMU" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:1542 +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:1551 +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:1557 +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:1562 +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:1569 +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:1574 +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:1582 +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:1589 +msgid "When to do a source NMU if you are a porter" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:1591 +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:1600 +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:1611 +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:1619 +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:1627 +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:1637 +msgid "Porting infrastructure and automation" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:1639 +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:1644 +msgid "Mailing lists and web pages" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:1646 +msgid "" +"Web pages containing the status of each port can be found at <ulink " +"url=\"http://www.debian.org/ports/\"></ulink>." +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:1650 +msgid "" +"Each port of Debian has a mailing list. The list of porting mailing lists " +"can be found at <ulink url=\"http://lists.debian.org/ports.html\"></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:1658 +msgid "Porter tools" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:1660 +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:1668 +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:1677 +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:1687 +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=\"http://buildd.debian.org/\"></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:1695 +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:1702 +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:1710 +msgid "When your package is <emphasis>not</emphasis> portable" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:1712 +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:1719 +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:1725 +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:1733 +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:1741 +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=\"http://cvs.debian.org/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:1751 +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:1764 +msgid "Non-Maintainer Uploads (NMUs)" +msgstr "" + +# type: Content of: <chapter><section><para> +#: pkgs.dbk:1766 +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:1771 +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:1778 +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:1783 +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:1792 +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:1797 +msgid "How to do a NMU" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:1799 +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:1805 +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:1811 +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:1817 +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:1824 +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:1831 +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:1841 +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:1849 +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:1856 +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:1865 +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:1870 +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:1876 +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:1881 +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:1885 +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:1892 +msgid "NMU version numbering" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:1894 +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:1898 +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:1909 +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:1915 +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:1925 +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:1932 +msgid "Source NMUs must have a new changelog entry" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:1934 +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:1940 +msgid "By convention, source NMU changelog entries start with the line" +msgstr "" + +# type: Content of: <chapter><section><section><screen> +#: pkgs.dbk:1943 +#, no-wrap +msgid "* Non-maintainer upload" +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: pkgs.dbk:1948 +msgid "Source NMUs and the Bug Tracking System" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:1950 +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:1956 +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:1963 +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:1968 +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:1979 +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:1987 +msgid "Building source NMUs" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:1989 +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:1994 +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:2002 +msgid "Acknowledging an NMU" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:2004 +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:2015 +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:2025 +msgid "NMU vs QA uploads" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:2027 +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=\"http://qa.debian.org/orphaned.html\"></ulink>. If you perform " +"an NMU on an improperly orphaned package, please set the maintainer to " +"``Debian QA Group <packages@qa.debian.org>''." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: pkgs.dbk:2037 +msgid "Who can do an NMU" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:2039 +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:2049 +msgid "Terminology" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:2051 +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:2059 +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:2068 +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:2078 +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:2088 +msgid "Collaborative maintenance" +msgstr "" + +# type: Content of: <chapter><section><para> +#: pkgs.dbk:2090 +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:2098 +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:2104 +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:2110 +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:2118 +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:2123 +#, no-wrap +msgid ": John Buzz <jbuzz@debian.org>, Adam Rex <arex@debian.org>" +msgstr "" + +# type: Content of: <chapter><section><itemizedlist><listitem><para> +#: pkgs.dbk:2128 +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:2134 +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:2143 +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:2150 +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:2158 +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:2166 +msgid "The testing distribution" +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: pkgs.dbk:2168 +msgid "Basics" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:2170 +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:2174 +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:2183 +msgid "Updates from unstable" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:2185 +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:2193 +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:2199 +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:2208 +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:2214 +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:2221 +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:2227 +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:2235 +msgid "" +"To find out whether a package is progressing into testing or not, see the " +"testing script output on the <ulink " +"url=\"http://www.debian.org/devel/testing\">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:2246 +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=\"http://www.debian.org/devel/testing\">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:2253 +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:2258 +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:2263 +msgid "out-of-date" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:2265 +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:2272 +msgid "Consider this example:" +msgstr "" + +# type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry> +#: pkgs.dbk:2279 pkgs.dbk:2310 +msgid "alpha" +msgstr "" + +# type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry> +#: pkgs.dbk:2280 pkgs.dbk:2311 +msgid "arm" +msgstr "" + +# type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry> +#: pkgs.dbk:2285 pkgs.dbk:2317 pkgs.dbk:2377 +msgid "testing" +msgstr "" + +# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry> +#: pkgs.dbk:2286 pkgs.dbk:2291 pkgs.dbk:2318 pkgs.dbk:2319 pkgs.dbk:2326 +msgid "1" +msgstr "" + +# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry> +#: pkgs.dbk:2287 pkgs.dbk:2320 pkgs.dbk:2325 +msgid "-" +msgstr "" + +# type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry> +#: pkgs.dbk:2290 pkgs.dbk:2323 pkgs.dbk:2378 +msgid "unstable" +msgstr "" + +# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry> +#: pkgs.dbk:2292 pkgs.dbk:2324 +msgid "2" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:2298 +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:2303 +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:2312 +msgid "hurd-i386" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:2332 +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:2337 +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:2344 +msgid "Removals from testing" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:2346 +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:2353 +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:2357 +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:2363 +msgid "circular dependencies" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:2365 +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:2370 +msgid "An example of this is:" +msgstr "" + +# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry> +#: pkgs.dbk:2383 +msgid "a" +msgstr "" + +# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry> +#: pkgs.dbk:2384 +msgid "1; depends: b=1" +msgstr "" + +# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry> +#: pkgs.dbk:2385 +msgid "2; depends: b=2" +msgstr "" + +# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry> +#: pkgs.dbk:2388 +msgid "b" +msgstr "" + +# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry> +#: pkgs.dbk:2389 +msgid "1; depends: a=1" +msgstr "" + +# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry> +#: pkgs.dbk:2390 +msgid "2; depends: a=2" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:2396 +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:2400 +msgid "" +"Currently, this requires some manual hinting from the release team. Please " +"contact them by sending mail to " +"<email>debian-release@lists.debian.org</email> if this happens to one of " +"your packages." +msgstr "" + +# type: Content of: <chapter><section><section><section><title> +#: pkgs.dbk:2407 +msgid "influence of package in testing" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:2409 +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:2419 +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:2426 +msgid "details" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:2428 +msgid "If you are interested in details, this is how britney works:" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:2431 +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:2440 +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:2448 +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.debian.org/testing/update_out_code/\"></ulink>" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:2455 +msgid "" +"The hints are available via <ulink " +"url=\"http://ftp-master.debian.org/testing/hints/\"></ulink>." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: pkgs.dbk:2463 +msgid "Direct updates to testing" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:2465 +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:2471 +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@lists.debian.org</email>." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:2478 +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:2487 +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:2492 +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:2497 +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:2503 +msgid "Make sure that you included only the minimal amount of changes;" +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: pkgs.dbk:2508 +msgid "Make sure that you included an appropriate explanation in the changelog;" +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: pkgs.dbk:2513 +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:2519 +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:2525 +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:2532 +msgid "" +"After uploading and successful build on all platforms, contact the release " +"team at <email>debian-release@lists.debian.org</email> and ask them to " +"approve your upload." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: pkgs.dbk:2541 +msgid "Frequently asked questions" +msgstr "" + +# type: Content of: <chapter><section><section><section><title> +#: pkgs.dbk:2543 +msgid "What are release-critical bugs, and how do they get counted?" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:2545 +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:2549 +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:2555 +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:2562 +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:2568 +msgid "How could installing a package into testing possibly break other packages?" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:2570 +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:2577 +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:2582 +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:2588 +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:2598 +msgid "" +"If you are having problems with complicated groups of packages like this, " +"contact debian-devel or debian-release for help." +msgstr "" diff --git a/po4a/fr/resources.po b/po4a/fr/resources.po new file mode 100644 index 0000000..856c359 --- /dev/null +++ b/po4a/fr/resources.po @@ -0,0 +1,1995 @@ +# 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-06-26 16:13+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:5 +msgid "Resources for Debian Developers" +msgstr "" + +# type: Content of: <chapter><para> +#: resources.dbk:7 +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:12 +msgid "Mailing lists" +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:14 +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.debian.org/\">lists.debian.org</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=\"http://www.debian.org/MailingLists/\"></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:24 +msgid "Basic rules for use" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:26 +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:32 +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:37 +msgid "" +"Please read the <ulink " +"url=\"http://www.debian.org/MailingLists/#codeofconduct\">code of " +"conduct</ulink> for more information." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: resources.dbk:44 +msgid "Core development mailing lists" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:46 +msgid "The core Debian mailing lists that developers should use are:" +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: resources.dbk:51 +msgid "" +"<email>debian-devel-announce@lists.debian.org</email>, 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:58 +msgid "" +"<email>debian-devel@lists.debian.org</email>, used to discuss various " +"development related technical issues." +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: resources.dbk:64 +msgid "" +"<email>debian-policy@lists.debian.org</email>, where the Debian Policy is " +"discussed and voted on." +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: resources.dbk:70 +msgid "" +"<email>debian-project@lists.debian.org</email>, used to discuss various " +"non-technical issues related to the project." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:76 +msgid "" +"There are other mailing lists available for a variety of special topics; see " +"<ulink url=\"http://lists.debian.org/\"></ulink> for a list." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: resources.dbk:82 +msgid "Special lists" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:84 +msgid "" +"<email>debian-private@lists.debian.org</email> 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@lists.debian.org</email> 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.debian.org</literal> and looking in the " +"<filename>~debian/archive/debian-private</filename> directory." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:96 +msgid "" +"<email>debian-email@lists.debian.org</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:104 +msgid "Requesting new development-related lists" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:106 +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:114 +msgid "" +"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 <ulink " +"url=\"http://www.debian.org/MailingLists/HOWTO_start_list\">the " +"HOWTO</ulink>." +msgstr "" + +# type: Content of: <chapter><section><title> +#: resources.dbk:123 +msgid "IRC channels" +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:125 +msgid "" +"Several IRC channels are dedicated to Debian's development. They are mainly " +"hosted on the <ulink url=\"http://www.oftc.net/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:131 +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:139 +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:147 +msgid "" +"Since <emphasis>#debian-devel</emphasis> is an open channel, you should not " +"speak there of issues that are discussed in " +"<email>debian-private@lists.debian.org</email>. 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:~debian/archive/debian-private/</filename>, " +"just <command>zgrep</command> for <emphasis>#debian-private</emphasis> in " +"all the files." +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:157 +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:169 +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:174 +msgid "" +"Channels dedicated to Debian also exist on other IRC networks, notably on " +"the <ulink url=\"http://www.freenode.net/\">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:179 +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:190 +msgid "Documentation" +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:192 +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=\"http://www.debian.org/devel/\">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:201 +msgid "Debian machines" +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:203 +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:208 +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=\"http://www.debian.org/devel/dmup\">Debian Machine Usage " +"Policies</ulink>." +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:213 +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:220 +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:225 +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:229 +msgid "" +"The current list of Debian machines is available at <ulink " +"url=\"http://db.debian.org/machines.cgi\"></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:235 +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.debian.org</email>." +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:241 +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:248 +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:252 +msgid "The bugs server" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:254 +msgid "" +"<literal>bugs.debian.org</literal> is the canonical location for the Bug " +"Tracking System (BTS)." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:258 resources.dbk:276 +msgid "It is restricted; a mirror is available on <literal>merkel</literal>." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:261 +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@lists.debian.org</email> before implementing anything, " +"however, to reduce unnecessary duplication of effort or wasted processing " +"time." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: resources.dbk:269 +msgid "The ftp-master server" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:271 +msgid "" +"The <literal>ftp-master.debian.org</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:279 +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@debian.org</email>, but also " +"see the procedures in <xref linkend=\"archive-manip\"/> ." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: resources.dbk:287 +msgid "The non-US server" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:289 +msgid "" +"The non-US server <literal>non-us.debian.org</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:296 +msgid "The www-master server" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:298 +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:302 +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.debian.org/www.debian.org\">Bug Tracking System</ulink>." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: resources.dbk:311 +msgid "The people web server" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:313 +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:317 +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:324 +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:328 +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:333 +msgid "" +"Send mail to <email>debian-devel@lists.debian.org</email> if you have any " +"questions." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: resources.dbk:339 +msgid "The CVS server" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:341 +msgid "Our CVS server is located on <literal>cvs.debian.org</literal>." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:344 +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:349 +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=\"http://cvs.debian.org/\"></ulink>." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:355 +msgid "" +"To request a CVS area, send a request via email to " +"<email>debian-admin@debian.org</email>. 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:363 +msgid "chroots to different distributions" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:365 +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:369 +#, no-wrap +msgid "" +"% dchroot unstable\n" +"Executing shell in chroot: /org/vore.debian.org/chroots/user/unstable" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:373 +msgid "" +"In all chroots, the normal user home directories are available. You can " +"find out which chroots are available via " +"<literal>http://db.debian.org/machines.cgi</literal>." +msgstr "" + +# type: Content of: <chapter><section><title> +#: resources.dbk:382 +msgid "The Developers Database" +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:384 +msgid "" +"The Developers Database, at <ulink url=\"https://db.debian.org/\"></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:391 +msgid "" +"Developers can <ulink url=\"https://db.debian.org/login.html\">log into the " +"database</ulink> to change various information about themselves, such as:" +msgstr "" + +# type: Content of: <chapter><section><itemizedlist><listitem><para> +#: resources.dbk:397 +msgid "forwarding address for your debian.org email" +msgstr "" + +# type: Content of: <chapter><section><itemizedlist><listitem><para> +#: resources.dbk:402 +msgid "subscription to debian-private" +msgstr "" + +# type: Content of: <chapter><section><itemizedlist><listitem><para> +#: resources.dbk:407 +msgid "whether you are on vacation" +msgstr "" + +# type: Content of: <chapter><section><itemizedlist><listitem><para> +#: resources.dbk:412 +msgid "" +"personal information such as your address, country, the latitude and " +"longitude of the place where you live for use in <ulink " +"url=\"http://www.debian.org/devel/developers.loc\">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:420 +msgid "password and preferred shell on Debian Project machines" +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:425 +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=\"http://db.debian.org/doc-general.html\"></ulink>." +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:430 +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=\"http://db.debian.org/doc-mail.html\"></ulink>." +msgstr "" + +# type: Content of: <chapter><section><title> +#: resources.dbk:438 +msgid "The Debian archive" +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:440 +msgid "" +"The Debian GNU/Linux distribution consists of a lot of packages " +"(<filename>.deb</filename>'s, currently around 9000) and a few additional " +"files (such as documentation and installation disk images)." +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:445 +msgid "Here is an example directory tree of a complete Debian archive:" +msgstr "" + +# type: Content of: <chapter><section><screen> +#: resources.dbk:448 +#, no-wrap +msgid "" +"/stable/main/\n" +"dists/stable/main/binary-i386/\n" +"dists/stable/main/binary-m68k/\n" +"dists/stable/main/binary-alpha/\n" +" ...\n" +"dists/stable/main/source/\n" +" ...\n" +"dists/stable/main/disks-i386/\n" +"dists/stable/main/disks-m68k/\n" +"dists/stable/main/disks-alpha/\n" +" ...\n" +"\n" +"dists/stable/contrib/\n" +"dists/stable/contrib/binary-i386/\n" +"dists/stable/contrib/binary-m68k/\n" +"dists/stable/contrib/binary-alpha/\n" +" ...\n" +"dists/stable/contrib/source/\n" +"\n" +"dists/stable/non-free/\n" +"dists/stable/non-free/binary-i386/\n" +"dists/stable/non-free/binary-m68k/\n" +"dists/stable/non-free/binary-alpha/\n" +" ...\n" +"dists/stable/non-free/source/\n" +"\n" +"dists/testing/\n" +"dists/testing/main/\n" +" ...\n" +"dists/testing/contrib/\n" +" ...\n" +"dists/testing/non-free/\n" +" ...\n" +"\n" +"dists/unstable\n" +"dists/unstable/main/\n" +" ...\n" +"dists/unstable/contrib/\n" +" ...\n" +"dists/unstable/non-free/\n" +" ...\n" +"\n" +"pool/\n" +"pool/main/a/\n" +"pool/main/a/apt/\n" +" ...\n" +"pool/main/b/\n" +"pool/main/b/bash/\n" +" ...\n" +"pool/main/liba/\n" +"pool/main/liba/libalias-perl/\n" +" ...\n" +"pool/main/m/\n" +"pool/main/m/mailx/\n" +" ...\n" +"pool/non-free/n/\n" +"pool/non-free/n/netscape/\n" +" ..." +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:508 +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:522 +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:527 +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:532 +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:538 +msgid "Sections" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:540 +msgid "" +"The <emphasis>main</emphasis> section of the Debian archive is what makes up " +"the <emphasis role=\"strong\">official Debian GNU/Linux " +"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 GNU/Linux." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:548 +msgid "" +"Every package in the main section must fully comply with the <ulink " +"url=\"http://www.debian.org/social_contract#guidelines\">Debian Free " +"Software Guidelines</ulink> (DFSG) and with all other policy requirements as " +"described in the <ulink " +"url=\"http://www.debian.org/doc/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:556 +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:561 +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:568 +msgid "" +"The <ulink url=\"http://www.debian.org/doc/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:573 +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:581 +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:587 +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:597 +msgid "Architectures" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:599 +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:604 +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:618 +msgid "" +"Debian GNU/Linux 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:629 +msgid "" +"Information for developers and users about the specific ports are available " +"at the <ulink url=\"http://www.debian.org/ports/\">Debian Ports web " +"pages</ulink>." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: resources.dbk:635 +msgid "Packages" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:637 +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:641 +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:647 +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:657 +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:664 +msgid "Distributions" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:666 +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:672 +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:679 +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:687 +msgid "Stable, testing, and unstable" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: resources.dbk:689 +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:696 +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:705 +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:712 +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.debian.org</literal>)." +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: resources.dbk:729 +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:746 +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:753 +msgid "More information about the testing distribution" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: resources.dbk:755 +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:759 +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:765 +msgid "Experimental" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: resources.dbk:767 +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:778 +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><screen> +#: resources.dbk:783 +#, no-wrap +msgid "" +"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:787 +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:793 +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:803 +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:813 +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:817 +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:821 +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:830 +msgid "Release code names" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:832 +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:844 +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:853 +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:861 +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:875 +msgid "Debian mirrors" +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:877 +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:888 +msgid "" +"All the information on Debian mirrors, including a list of the available " +"public FTP/HTTP servers, can be found at <ulink " +"url=\"http://www.debian.org/mirror/\"></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:895 +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:902 +msgid "The Incoming system" +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:904 +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.debian.org</literal>." +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:909 +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:928 +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=\"http://incoming.debian.org/\"></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:940 +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@lists.debian.org</email>. If a package is released " +"with <literal>Distribution:</literal> set to `unstable' or `experimental', " +"the announcement will be posted to " +"<email>debian-devel-changes@lists.debian.org</email> instead." +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:950 +msgid "" +"Though ftp-master is restricted, a copy of the installation is available to " +"all developers on <literal>merkel.debian.org</literal>." +msgstr "" + +# type: Content of: <chapter><section><title> +#: resources.dbk:956 +msgid "Package information" +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: resources.dbk:958 +msgid "On the web" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:960 +msgid "" +"Each package has several dedicated web pages. " +"<literal>http://packages.debian.org/<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:967 +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.debian.org/<replaceable>package-name</replaceable></literal>." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: resources.dbk:974 +msgid "The <command>madison</command> utility" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:976 +msgid "" +"<command>madison</command> is a command-line utility that is available on " +"<literal>ftp-master.debian.org</literal>, and on the mirror on " +"<literal>merkel.debian.org</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:984 +#, 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:991 +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:1001 +msgid "The Package Tracking System" +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:1003 +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:1008 +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:1012 +msgid "By default you will get:" +msgstr "" + +# type: Content of: <chapter><section><variablelist><varlistentry><listitem><para> +#: resources.dbk:1019 +msgid "All the bug reports and following discussions." +msgstr "" + +# type: Content of: <chapter><section><variablelist><varlistentry><listitem><para> +#: resources.dbk:1027 +msgid "" +"The email notifications from <email>control@bugs.debian.org</email> about " +"bug report status changes." +msgstr "" + +# type: Content of: <chapter><section><variablelist><varlistentry><listitem><para> +#: resources.dbk:1036 +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:1045 +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:1054 +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>@packages.qa.debian.org</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:1066 +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:1073 +msgid "You can also decide to receive additional information:" +msgstr "" + +# type: Content of: <chapter><section><variablelist><varlistentry><listitem><para> +#: resources.dbk:1080 +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:1091 +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:1100 +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:1109 +msgid "" +"Information about changes made to the package in derivative distributions " +"(for example Ubuntu)." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: resources.dbk:1116 +msgid "The PTS email interface" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:1118 +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:1126 +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:1139 +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:1149 +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:1158 +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:1167 +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:1174 +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:1179 +msgid "" +"<literal>bts-control</literal>: reply to mails sent to " +"<email>control@bugs.debian.org</email>" +msgstr "" + +# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><itemizedlist><listitem><para> +#: resources.dbk:1185 +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:1191 +msgid "<literal>cvs</literal>: notification of CVS commits" +msgstr "" + +# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><itemizedlist><listitem><para> +#: resources.dbk:1196 +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:1201 +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:1207 +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:1213 +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:1219 +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:1225 +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:1235 +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:1244 +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:1254 +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:1264 +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:1273 +msgid "Stops processing commands. All following lines are ignored by the bot." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:1279 +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:1287 +msgid "Filtering PTS mails" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:1289 +msgid "" +"Once you are subscribed to a package, you will get the mails sent to " +"<literal><replaceable>sourcepackage</replaceable>@packages.qa.debian.org</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:1297 +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:1301 +#, no-wrap +msgid "" +"-Loop: dpkg@packages.qa.debian.org\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:1309 +msgid "Forwarding CVS commits in the PTS" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:1311 +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:1317 +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@packages.qa.debian.org</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:1326 +msgid "The PTS web interface" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:1328 +msgid "" +"The PTS has a web interface at <ulink " +"url=\"http://packages.qa.debian.org/\"></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:1338 +msgid "" +"You can jump directly to the web page concerning a specific source package " +"with a URL like " +"<literal>http://packages.qa.debian.org/<replaceable>sourcepackage</replaceable></literal>." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:1343 +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:1349 +msgid "Static news items can be used to indicate:" +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: resources.dbk:1354 +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:1360 +msgid "a link to the upstream web site" +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: resources.dbk:1365 +msgid "a link to the upstream bug tracker" +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: resources.dbk:1370 +msgid "the existence of an IRC channel dedicated to the software" +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: resources.dbk:1375 +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:1381 +msgid "Usual news items may be used to announce that:" +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: resources.dbk:1386 +msgid "beta packages are available for testing" +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: resources.dbk:1391 +msgid "final packages are expected for next week" +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: resources.dbk:1396 +msgid "the packaging is about to be redone from scratch" +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: resources.dbk:1401 +msgid "backports are available" +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: resources.dbk:1406 +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:1411 +msgid "a NMU is being worked on" +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: resources.dbk:1416 +msgid "something important will affect the package" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:1421 +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:1432 +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:1437 +#, no-wrap +msgid "" +": 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: http://cvs.debian.org/debian-cd/" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:1445 +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:1450 +#, no-wrap +msgid "" +": Raphael Hertzog <hertzog@debian.org>\n" +"To: debian-gtk-gnome@lists.debian.org\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:1463 +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:1473 +msgid "Developer's packages overview" +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:1475 +msgid "" +"A QA (quality assurance) web portal is available at <ulink " +"url=\"http://qa.debian.org/developer.php\"></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:1484 +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:1491 +msgid "Debian *Forge: Alioth" +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:1493 +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:1500 +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:1506 +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:1511 +msgid "" +"For more information please visit <ulink " +"url=\"http://alioth.debian.org/\"></ulink>." +msgstr "" + +# type: Content of: <chapter><section><title> +#: resources.dbk:1517 +msgid "Goodies for Developers" +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: resources.dbk:1519 +msgid "LWN Subscriptions" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:1521 +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.debian.org/debian-devel-announce/2002/10/msg00018.html\"></ulink>." +msgstr "" diff --git a/po4a/fr/scope.po b/po4a/fr/scope.po new file mode 100644 index 0000000..2154e96 --- /dev/null +++ b/po4a/fr/scope.po @@ -0,0 +1,72 @@ +# 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-06-26 16:12+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:5 +msgid "Scope of This Document" +msgstr "" + +# type: Content of: <chapter><para> +#: scope.dbk:7 +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:11 +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:20 +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:28 +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=\"http://www.debian.org/doc/debian-policy/\">Debian Policy " +"Manual</ulink>." +msgstr "" + +# type: Content of: <chapter><para> +#: scope.dbk:35 +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 "" diff --git a/po4a/fr/tools.po b/po4a/fr/tools.po new file mode 100644 index 0000000..7cca30a --- /dev/null +++ b/po4a/fr/tools.po @@ -0,0 +1,654 @@ +# 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-06-26 16:13+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:5 +msgid "Overview of Debian Maintainer Tools" +msgstr "" + +# type: Content of: <appendix><para> +#: tools.dbk:7 +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:12 +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:16 +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:24 +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 " +"<literal>apt-cache show <package-name></literal>." +msgstr "" + +# type: Content of: <appendix><section><title> +#: tools.dbk:30 +msgid "Core tools" +msgstr "" + +# type: Content of: <appendix><section><para> +#: tools.dbk:32 +msgid "The following tools are pretty much required for any maintainer." +msgstr "" + +# type: Content of: <appendix><section><section><para> +#: tools.dbk:37 +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:48 +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:54 +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:58 +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:68 +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:79 +msgid "Package lint tools" +msgstr "" + +# type: Content of: <appendix><section><para> +#: tools.dbk:81 +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:89 +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:95 +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:102 +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:106 +msgid "" +"You can also see a summary of all problems reported by Lintian on your " +"packages at <ulink url=\"http://lintian.debian.org/\"></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:116 +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:125 +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:134 +msgid "You can run it over a pair of binary packages:" +msgstr "" + +# type: Content of: <appendix><section><section><screen> +#: tools.dbk:137 +#, no-wrap +msgid "package_1-1_arch.deb package_2-1_arch.deb" +msgstr "" + +# type: Content of: <appendix><section><section><para> +#: tools.dbk:140 +msgid "Or even a pair of changes files:" +msgstr "" + +# type: Content of: <appendix><section><section><screen> +#: tools.dbk:143 +#, no-wrap +msgid "package_1-1_arch.changes package_2-1_arch.changes" +msgstr "" + +# type: Content of: <appendix><section><section><para> +#: tools.dbk:146 +msgid "" +"For more information please see <citerefentry> " +"<refentrytitle>debdiff</refentrytitle> <manvolnum>1</manvolnum> " +"</citerefentry>." +msgstr "" + +# type: Content of: <appendix><section><title> +#: tools.dbk:155 +msgid "Helpers for <filename>debian/rules</filename>" +msgstr "" + +# type: Content of: <appendix><section><para> +#: tools.dbk:157 +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:165 +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:173 +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:179 +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:188 +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:198 +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:209 +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:217 +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:227 +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:237 +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:245 +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:256 +msgid "Package builders" +msgstr "" + +# type: Content of: <appendix><section><para> +#: tools.dbk:258 +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:264 +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:270 +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:281 +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:287 +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:297 +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:303 +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:312 +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=\"http://buildd.debian.org/\"></ulink> to see the system in action." +msgstr "" + +# type: Content of: <appendix><section><title> +#: tools.dbk:324 +msgid "Package uploaders" +msgstr "" + +# type: Content of: <appendix><section><para> +#: tools.dbk:326 +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:332 +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:342 +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:354 +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:362 +msgid "Maintenance automation" +msgstr "" + +# type: Content of: <appendix><section><para> +#: tools.dbk:364 +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:371 +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:385 +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:394 +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:405 +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:411 +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:420 +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:429 +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:437 +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:448 +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:454 +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:460 +#, no-wrap +msgid "-depcheck -b debian/rules build" +msgstr "" + +# type: Content of: <appendix><section><section><para> +#: tools.dbk:463 +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:467 +msgid "" +"For more information please see <citerefentry> " +"<refentrytitle>dpkg-depcheck</refentrytitle> <manvolnum>1</manvolnum> " +"</citerefentry>." +msgstr "" + +# type: Content of: <appendix><section><title> +#: tools.dbk:476 +msgid "Porting tools" +msgstr "" + +# type: Content of: <appendix><section><para> +#: tools.dbk:478 +msgid "The following tools are helpful for porters and for cross-compilation." +msgstr "" + +# type: Content of: <appendix><section><section><para> +#: tools.dbk:483 +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:493 +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:504 +msgid "Documentation and information" +msgstr "" + +# type: Content of: <appendix><section><para> +#: tools.dbk:506 +msgid "" +"The following packages provide information for maintainers or help with " +"building documentation." +msgstr "" + +# type: Content of: <appendix><section><section><para> +#: tools.dbk:512 +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:518 +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:526 +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:534 +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 "" diff --git a/po4a/ja/best-pkging-practices.po b/po4a/ja/best-pkging-practices.po new file mode 100644 index 0000000..afae0ad --- /dev/null +++ b/po4a/ja/best-pkging-practices.po @@ -0,0 +1,2506 @@ +# 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-06-26 16:13+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:5 +msgid "Best Packaging Practices" +msgstr "" + +# type: Content of: <chapter><para> +#: best-pkging-practices.dbk:7 +msgid "" +"Debian's quality is largely due to the <ulink " +"url=\"http://www.debian.org/doc/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:16 +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:22 +msgid "Best practices for <filename>debian/rules</filename>" +msgstr "" + +# type: Content of: <chapter><section><para> +#: best-pkging-practices.dbk:24 +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:30 +msgid "Helper scripts" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:32 +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:43 +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:50 +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:64 +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:77 +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=\"http://arch.debian.org/arch/private/srivasta/\"></ulink>." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: best-pkging-practices.dbk:86 +msgid "Separating your patches into multiple files" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:88 +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:97 +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:107 +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:114 +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:122 +msgid "Multiple binary packages" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:124 +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:131 +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:140 +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:150 +msgid "Best practices for <filename>debian/control</filename>" +msgstr "" + +# type: Content of: <chapter><section><para> +#: best-pkging-practices.dbk:152 +msgid "" +"The following practices are relevant to the " +"<filename>debian/control</filename> file. They supplement the <ulink " +"url=\"http://www.debian.org/doc/debian-policy/ch-binary.html#s-descriptions\">Policy " +"on package descriptions</ulink>." +msgstr "" + +# type: Content of: <chapter><section><para> +#: best-pkging-practices.dbk:158 +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:167 +msgid "General guidelines for package descriptions" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:169 +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:176 +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:182 +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:189 +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:194 +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:201 +msgid "" +"If you are having problems writing your description, you may wish to send it " +"along to <email>debian-l10n-english@lists.debian.org</email> and request " +"feedback." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: best-pkging-practices.dbk:208 +msgid "The package synopsis, or short description" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:210 +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:214 +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:223 +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:227 +#, no-wrap +msgid "" +"<replaceable>package-name</replaceable> is a " +"<replaceable>synopsis</replaceable>." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:230 +msgid "Alternatively, it might make sense to think of it as" +msgstr "" + +# type: Content of: <chapter><section><section><screen> +#: best-pkging-practices.dbk:233 +#, no-wrap +msgid "" +"<replaceable>package-name</replaceable> is " +"<replaceable>synopsis</replaceable>." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:236 +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:239 +#, no-wrap +msgid "" +"<replaceable>package-name</replaceable> are " +"<replaceable>synopsis</replaceable>." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:242 +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:249 +msgid "The long description" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:251 +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:257 +msgid "The long description should consist of full and complete sentences." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:260 +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:266 +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:274 +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:279 +#, no-wrap +msgid "-d american -g debian/control" +msgstr "" + +# type: Content of: <chapter><section><section><screen> +#: best-pkging-practices.dbk:282 +#, no-wrap +msgid "-d en -D -c debian/control" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:285 +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:290 +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:296 +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:303 +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:309 +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:316 +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:325 +msgid "Upstream home page" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:327 +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:332 +#, no-wrap +msgid "" +".\n" +" Homepage: http://some-project.some-place.org/" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:336 +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=\"http://packages.debian.org/unstable/web/wml\"></ulink>." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:341 +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:344 +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.debian.org</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.debian.org</filename> to " +"parse it correctly." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: best-pkging-practices.dbk:355 +msgid "Version Control System location" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:357 +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:361 +msgid "XS-Vcs-Browser" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:363 +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:368 +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:375 +msgid "XS-Vcs-*" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:377 +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:388 +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:399 +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:407 +#, 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:421 +msgid "Best practices for <filename>debian/changelog</filename>" +msgstr "" + +# type: Content of: <chapter><section><para> +#: best-pkging-practices.dbk:423 +msgid "" +"The following practices supplement the <ulink " +"url=\"http://www.debian.org/doc/debian-policy/ch-docs.html#s-changelogs\">Policy " +"on changelog files</ulink>." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: best-pkging-practices.dbk:428 +msgid "Writing useful changelog entries" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:430 +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:435 +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:441 +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:448 +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:454 +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:460 +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:467 +msgid "Common misconceptions about changelog entries" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:469 +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:477 +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:482 +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:493 +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:501 +msgid "Common errors in changelog entries" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:503 +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:507 +#, no-wrap +msgid "* Fixed all outstanding bugs." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:510 +msgid "This doesn't tell readers anything too useful, obviously." +msgstr "" + +# type: Content of: <chapter><section><section><screen> +#: best-pkging-practices.dbk:513 +#, no-wrap +msgid "* Applied patch from Jane Random." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:516 +msgid "What was the patch about?" +msgstr "" + +# type: Content of: <chapter><section><section><screen> +#: best-pkging-practices.dbk:519 +#, no-wrap +msgid "* Late night install target overhaul." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:522 +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:526 +#, no-wrap +msgid "* Fix vsync FU w/ ancient CRTs." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:529 +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:533 +#, no-wrap +msgid "* This is not a bug, closes: #nnnnnn." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:536 +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:541 +#, 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:544 +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:551 +#, no-wrap +msgid "* Closes: #12345, #12346, #15432" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:554 +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:560 +msgid "Supplementing changelogs with NEWS.Debian files" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:562 +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:571 +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:579 +#, no-wrap +msgid "" +"(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:589 +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:595 +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:605 +msgid "Best practices for maintainer scripts" +msgstr "" + +# type: Content of: <chapter><section><para> +#: best-pkging-practices.dbk:607 +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=\"http://www.debian.org/doc/debian-policy/\">Debian Policy</ulink>." +msgstr "" + +# type: Content of: <chapter><section><para> +#: best-pkging-practices.dbk:615 +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:620 +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:624 +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:631 +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:638 +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:644 +msgid "" +"If you need to check for the existence of a command, you should use " +"something like" +msgstr "" + +# type: Content of: <chapter><section><screen> +#: best-pkging-practices.dbk:648 +#, no-wrap +msgid "[ -x /usr/sbin/install-docs ]; then ..." +msgstr "" + +# type: Content of: <chapter><section><para> +#: best-pkging-practices.dbk:651 +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><screen> +#: best-pkging-practices.dbk:655 +#, no-wrap +msgid "" +"() {\n" +" OLDIFS=$IFS\n" +" IFS=:\n" +" for p in $PATH; do\n" +" if [ -x $p/$* ]; then\n" +" IFS=$OLDIFS\n" +" return 0\n" +" fi\n" +" done\n" +" IFS=$OLDIFS\n" +" return 1\n" +"}" +msgstr "" + +# type: Content of: <chapter><section><para> +#: best-pkging-practices.dbk:669 +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:676 +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:686 +msgid "" +"Configuration management with <systemitem " +"role=\"package\">debconf</systemitem>" +msgstr "" + +# type: Content of: <chapter><section><para> +#: best-pkging-practices.dbk:688 +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:696 +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:703 +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:709 +msgid "Do not abuse debconf" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:711 +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:717 +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:723 +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:731 +msgid "General recommendations for authors and translators" +msgstr "" + +# type: Content of: <chapter><section><section><section><title> +#: best-pkging-practices.dbk:733 +msgid "Write correct English" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:735 +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:739 +msgid "" +"Please use (and abuse) <email>debian-l10n-english@lists.debian.org</email> " +"mailing list. Have your templates proofread." +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:743 +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:747 +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:755 +msgid "Be kind to translators" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:757 +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:762 +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:767 +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:776 +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:781 +msgid "" +"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@lists.debian.org</email> mailing list." +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:786 +msgid "" +"Calls for translations posted to <email>debian-i18n@lists.debian.org</email> " +"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:795 +msgid "Unfuzzy complete translations when correcting typos and spelling" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:797 +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:803 +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:807 +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:813 +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><screen> +#: best-pkging-practices.dbk:818 +#, no-wrap +msgid "" +"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:824 +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:831 +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:838 +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:844 +msgid "use the following command:" +msgstr "" + +# type: Content of: <chapter><section><section><section><orderedlist><listitem><screen> +#: best-pkging-practices.dbk:847 +#, no-wrap +msgid "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:852 +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:857 +msgid "run <command>debconf-updatepo</command> again" +msgstr "" + +# type: Content of: <chapter><section><section><section><title> +#: best-pkging-practices.dbk:864 +msgid "Do not make assumptions about interfaces" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:866 +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:871 +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:877 +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:883 +msgid "Do not use first person" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:885 +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:895 +msgid "Be gender neutral" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:897 +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:905 +msgid "Templates fields definition" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:907 +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:912 +msgid "Type" +msgstr "" + +# type: Content of: <chapter><section><section><section><section><title> +#: best-pkging-practices.dbk:914 +msgid "string:" +msgstr "" + +# type: Content of: <chapter><section><section><section><section><para> +#: best-pkging-practices.dbk:916 +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:921 +msgid "password:" +msgstr "" + +# type: Content of: <chapter><section><section><section><section><para> +#: best-pkging-practices.dbk:923 +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:930 +msgid "boolean:" +msgstr "" + +# type: Content of: <chapter><section><section><section><section><para> +#: best-pkging-practices.dbk:932 +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:938 +msgid "select:" +msgstr "" + +# type: Content of: <chapter><section><section><section><section><para> +#: best-pkging-practices.dbk:940 +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:947 +msgid "multiselect:" +msgstr "" + +# type: Content of: <chapter><section><section><section><section><para> +#: best-pkging-practices.dbk:949 +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:955 +msgid "note:" +msgstr "" + +# type: Content of: <chapter><section><section><section><section><para> +#: best-pkging-practices.dbk:957 +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:966 +msgid "text:" +msgstr "" + +# type: Content of: <chapter><section><section><section><section><para> +#: best-pkging-practices.dbk:968 +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:973 +msgid "error:" +msgstr "" + +# type: Content of: <chapter><section><section><section><section><para> +#: best-pkging-practices.dbk:975 +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:980 +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:988 +msgid "Description: short and extended description" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:990 +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:994 +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:1000 +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:1006 +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:1010 +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:1017 +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:1022 +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:1028 +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:1032 +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:1038 +msgid "Choices" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:1040 +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:1047 +msgid "Default" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:1049 +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:1058 +msgid "Templates fields specific style guide" +msgstr "" + +# type: Content of: <chapter><section><section><section><title> +#: best-pkging-practices.dbk:1060 +msgid "Type field" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:1062 +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:1068 +msgid "Description field" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:1070 +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:1074 +msgid "String/password templates" +msgstr "" + +# type: Content of: <chapter><section><section><section><section><itemizedlist><listitem><para> +#: best-pkging-practices.dbk:1078 +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:1085 +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:1095 +msgid "Boolean templates" +msgstr "" + +# type: Content of: <chapter><section><section><section><section><itemizedlist><listitem><para> +#: best-pkging-practices.dbk:1099 +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:1107 +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:1115 +msgid "Select/Multiselect" +msgstr "" + +# type: Content of: <chapter><section><section><section><section><itemizedlist><listitem><para> +#: best-pkging-practices.dbk:1119 +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:1127 +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:1137 +msgid "Notes" +msgstr "" + +# type: Content of: <chapter><section><section><section><section><itemizedlist><listitem><para> +#: best-pkging-practices.dbk:1141 +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:1146 +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:1152 +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:1167 +msgid "Choices field" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:1169 +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:1176 best-pkging-practices.dbk:1214 +msgid "Default field" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:1178 +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:1183 +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:1189 +msgid "Example, taken from the geneweb package templates:" +msgstr "" + +# type: Content of: <chapter><section><section><section><screen> +#: best-pkging-practices.dbk:1192 +#, no-wrap +msgid "" +": 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:1203 +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:1208 +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:1216 +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:1220 +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:1225 +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:1237 +msgid "Internationalization" +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: best-pkging-practices.dbk:1239 +msgid "Handling debconf translations" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:1241 +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:1247 +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:1257 +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:1273 +msgid "Internationalized documentation" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:1275 +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:1280 +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=\"http://cvs.debian.org/boot-floppies/documentation/doc-check?rev=HEAD\\|[amp " +"]\\|content-type=text/vnd.viewcvs-markup\">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:1295 +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:1305 +msgid "Common packaging situations" +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: best-pkging-practices.dbk:1307 +msgid "Packages using <command>autoconf</command>/<command>automake</command>" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:1309 +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 " +"<filename>/usr/share/doc/autotools-dev/README.Debian.gz</filename> 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:1321 +msgid "Libraries" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:1323 +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:1329 +msgid "" +"Good practices for library packaging have been grouped in <ulink " +"url=\"http://www.netfort.gr.jp/~dancer/column/libpkg-guide/\">the library " +"packaging guide</ulink>." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: best-pkging-practices.dbk:1336 +msgid "Documentation" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:1338 +msgid "" +"Be sure to follow the <ulink " +"url=\"http://www.debian.org/doc/debian-policy/ch-docs.html\">Policy on " +"documentation</ulink>." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:1343 +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:1348 +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:1355 +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:1363 +msgid "Specific types of packages" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:1365 +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:1371 +msgid "" +"Perl related packages have a <ulink " +"url=\"http://www.debian.org/doc/packaging-manuals/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:1380 +msgid "" +"Python related packages have their python policy; see " +"<filename>/usr/share/doc/python/python-policy.txt.gz</filename> in the " +"<systemitem role=\"package\">python</systemitem> package." +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: best-pkging-practices.dbk:1387 +msgid "" +"Emacs related packages have the <ulink " +"url=\"http://www.debian.org/doc/packaging-manuals/debian-emacs-policy\">emacs " +"policy</ulink>." +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: best-pkging-practices.dbk:1394 +msgid "" +"Java related packages have their <ulink " +"url=\"http://www.debian.org/doc/packaging-manuals/java-policy/\">java " +"policy</ulink>." +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: best-pkging-practices.dbk:1401 +msgid "" +"Ocaml related packages have their own policy, found in " +"<filename>/usr/share/doc/ocaml/ocaml_packaging_policy.gz</filename> 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:1409 +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:1415 +msgid "" +"Lisp packages should register themselves with <systemitem " +"role=\"package\">common-lisp-controller</systemitem>, about which see " +"<filename>/usr/share/doc/common-lisp-controller/README.packaging</filename>." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: best-pkging-practices.dbk:1424 +msgid "Architecture-independent data" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:1426 +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:1433 +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:1445 +msgid "Needing a certain locale during build" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:1447 +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:1451 +msgid "" +"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:" +msgstr "" + +# type: Content of: <chapter><section><section><screen> +#: best-pkging-practices.dbk:1456 +#, no-wrap +msgid "" +"=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:1469 +msgid "Make transition packages deborphan compliant" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:1471 +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:1478 +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:1484 +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:" +msgstr "" + +# type: Content of: <chapter><section><section><screen> +#: best-pkging-practices.dbk:1488 +#, no-wrap +msgid "-cache search .|grep dummy" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:1491 +msgid "or" +msgstr "" + +# type: Content of: <chapter><section><section><screen> +#: best-pkging-practices.dbk:1494 +#, no-wrap +msgid "-cache search .|grep transitional" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:1497 +msgid "." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: best-pkging-practices.dbk:1502 +msgid "Best practices for <filename>orig.tar.gz</filename> files" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:1504 +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:1508 +msgid "Pristine source" +msgstr "" + +# type: Content of: <chapter><section><section><section><para><footnote> +#: best-pkging-practices.dbk:1510 +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:1512 +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:1522 +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:1530 +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:1538 +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:1541 +#, no-wrap +msgid "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:1546 +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:1555 +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:1566 +msgid "Repackaged upstream source" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:1568 +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:1575 +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:1584 +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:1593 +msgid "A repackaged .orig.tar.gz" +msgstr "" + +# type: Content of: <chapter><section><section><section><orderedlist><listitem><para> +#: best-pkging-practices.dbk:1598 +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=\"http://www.debian.org/doc/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:1610 +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> +#: best-pkging-practices.dbk:1612 +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:1623 +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:1632 +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:1639 +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:1647 +msgid "" +"<emphasis role=\"strong\">should</emphasis> be gzipped with maximal " +"compression." +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:1652 +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:1658 +msgid "Changing binary files in <literal>diff.gz</literal>" +msgstr "" + +# type: Content of: <chapter><section><section><section><para><footnote> +#: best-pkging-practices.dbk:1660 +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:1667 +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><footnote><screen> +#: best-pkging-practices.dbk:1673 +#, no-wrap +msgid "" +"-file: perl -ne 'print(pack u, $$_);'\n" +"$(file) > $(file).uuencoded uudecode-file: perl -ne 'print(unpack u, " +"$$_);'\n" +"$(file).uuencoded > $(file)" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:1675 +msgid "" +"</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:1680 +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:1693 +msgid "Best practices for debug packages" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:1695 +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:1703 +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:1713 +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:1725 +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:1732 +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:1739 +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:1743 +#, no-wrap +msgid ": libfoo-dbg (= ${binary:Version})" +msgstr "" diff --git a/po4a/ja/beyond-pkging.po b/po4a/ja/beyond-pkging.po new file mode 100644 index 0000000..586c3ca --- /dev/null +++ b/po4a/ja/beyond-pkging.po @@ -0,0 +1,572 @@ +# 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-06-26 16:13+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:5 +msgid "Beyond Packaging" +msgstr "" + +# type: Content of: <chapter><para> +#: beyond-pkging.dbk:7 +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:12 +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:17 +msgid "Bug reporting" +msgstr "" + +# type: Content of: <chapter><section><para> +#: beyond-pkging.dbk:19 +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:24 +msgid "" +"Read the <ulink url=\"http://www.debian.org/Bugs/Reporting\">instructions " +"for reporting bugs</ulink> in the Debian <ulink " +"url=\"http://www.debian.org/Bugs/\">bug tracking system</ulink>." +msgstr "" + +# type: Content of: <chapter><section><para> +#: beyond-pkging.dbk:29 +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:34 +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:39 +msgid "" +"Make sure the bug is not already filed against a package. Each package has " +"a bug list easily reachable at " +"<literal>http://bugs.debian.org/<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:48 +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:54 +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:61 +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.debian.org/from:<replaceable><your-email-addr></replaceable></literal>." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: beyond-pkging.dbk:68 +msgid "Reporting lots of bugs at once (mass bug filing)" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: beyond-pkging.dbk:70 +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:77 +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@lists.debian.org</email> " +"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:85 +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@lists.debian.org</email>." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: beyond-pkging.dbk:91 +msgid "" +"Note that when sending lots of bugs on the same subject, you should send the " +"bug report to <email>maintonly@bugs.debian.org</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:100 +msgid "Quality Assurance effort" +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: beyond-pkging.dbk:102 +msgid "Daily work" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: beyond-pkging.dbk:104 +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@lists.debian.org</email> or " +"<email>debian-devel@lists.debian.org</email>). 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:118 +msgid "Bug squashing parties" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: beyond-pkging.dbk:120 +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@lists.debian.org</email> 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:129 +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:138 +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:145 +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:153 +msgid "Contacting other maintainers" +msgstr "" + +# type: Content of: <chapter><section><para> +#: beyond-pkging.dbk:155 +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:161 +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.debian.org</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:169 +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>@packages.qa.debian.org</literal> " +"email address." +msgstr "" + +# type: Content of: <chapter><section><title> +#: beyond-pkging.dbk:177 +msgid "Dealing with inactive and/or unreachable maintainers" +msgstr "" + +# type: Content of: <chapter><section><para> +#: beyond-pkging.dbk:179 +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:186 +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" +msgstr "" + +# type: Content of: <chapter><section><screen> +#: beyond-pkging.dbk:194 +#, no-wrap +msgid "-query --help" +msgstr "" + +# type: Content of: <chapter><section><para> +#: beyond-pkging.dbk:197 +msgid "" +"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:202 +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:208 +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:216 +msgid "" +"The echelon information available through the <ulink " +"url=\"https://db.debian.org/\">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:225 +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:234 +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:241 +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:249 +msgid "" +"It is also allowed to post a query to " +"<email>debian-devel@lists.debian.org</email>, 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:254 +msgid "" +"Once you have gathered all of this, you can contact " +"<email>mia@qa.debian.org</email>. 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:262 +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:270 +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:276 +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@qa.debian.org</email>." +msgstr "" + +# type: Content of: <chapter><section><title> +#: beyond-pkging.dbk:284 +msgid "Interacting with prospective Debian developers" +msgstr "" + +# type: Content of: <chapter><section><para> +#: beyond-pkging.dbk:286 +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:292 +msgid "Sponsoring packages" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: beyond-pkging.dbk:294 +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:299 +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:306 +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:313 +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:320 +msgid "Managing sponsored packages" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: beyond-pkging.dbk:322 +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:327 +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:336 +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:341 +msgid "Once the package meets Debian standards, build and sign it with" +msgstr "" + +# type: Content of: <chapter><section><section><screen> +#: beyond-pkging.dbk:344 +#, no-wrap +msgid "-buildpackage -k<replaceable>KEY-ID</replaceable>" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: beyond-pkging.dbk:347 +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:352 +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:358 +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:362 +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:368 +msgid "Advocating new developers" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: beyond-pkging.dbk:370 +msgid "" +"See the page about <ulink " +"url=\"http://www.debian.org/devel/join/nm-advocate\">advocating a " +"prospective developer</ulink> at the Debian web site." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: beyond-pkging.dbk:377 +msgid "Handling new maintainer applications" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: beyond-pkging.dbk:379 +msgid "" +"Please see <ulink " +"url=\"http://www.debian.org/devel/join/nm-amchecklist\">Checklist for " +"Application Managers</ulink> at the Debian web site." +msgstr "" diff --git a/po4a/ja/developer-duties.po b/po4a/ja/developer-duties.po new file mode 100644 index 0000000..487ca81 --- /dev/null +++ b/po4a/ja/developer-duties.po @@ -0,0 +1,314 @@ +# 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-06-26 16:13+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:5 +msgid "Debian Developer's Duties" +msgstr "" + +# type: Content of: <chapter><section><title> +#: developer-duties.dbk:7 +msgid "Maintaining your Debian information" +msgstr "" + +# type: Content of: <chapter><section><para> +#: developer-duties.dbk:9 +msgid "" +"There's a LDAP database containing information about Debian developers at " +"<ulink url=\"https://db.debian.org/\"></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:17 +msgid "" +"For more information about the database, please see <xref " +"linkend=\"devel-db\"/> ." +msgstr "" + +# type: Content of: <chapter><section><title> +#: developer-duties.dbk:23 +msgid "Maintaining your public key" +msgstr "" + +# type: Content of: <chapter><section><para> +#: developer-duties.dbk:25 +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=\"http://www.cam.ac.uk.pgp.net/pgpnet/pgp-faq/\">PGP FAQ</ulink>." +msgstr "" + +# type: Content of: <chapter><section><para> +#: developer-duties.dbk:32 +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:38 +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>keyring.debian.org</literal>." +msgstr "" + +# type: Content of: <chapter><section><para> +#: developer-duties.dbk:43 +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://keyring.debian.org/replacing_keys.html\"></ulink>." +msgstr "" + +# type: Content of: <chapter><section><para> +#: developer-duties.dbk:51 +msgid "" +"The same key extraction routines discussed in <xref " +"linkend=\"registering\"/> apply." +msgstr "" + +# type: Content of: <chapter><section><para> +#: developer-duties.dbk:55 +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:62 +msgid "Voting" +msgstr "" + +# type: Content of: <chapter><section><para> +#: developer-duties.dbk:64 +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=\"http://www.debian.org/devel/constitution\">Debian " +"Constitution</ulink>." +msgstr "" + +# type: Content of: <chapter><section><para> +#: developer-duties.dbk:70 +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@lists.debian.org</email> 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:76 +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@lists.debian.org</email> (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:84 +msgid "" +"The list of all proposals (past and current) is available on the <ulink " +"url=\"http://www.debian.org/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:91 +msgid "Going on vacation gracefully" +msgstr "" + +# type: Content of: <chapter><section><para> +#: developer-duties.dbk:93 +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:100 +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:107 +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.debian.org</email> with [VAC] prepended to the " +"subject of your message<footnote>" +msgstr "" + +# type: Content of: <chapter><section><para><footnote><para> +#: developer-duties.dbk:109 +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:111 +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:116 +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:122 +msgid "" +"Ideally, you should sign up at the <ulink " +"url=\"http://nm.debian.org/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:131 +msgid "Coordination with upstream developers" +msgstr "" + +# type: Content of: <chapter><section><para> +#: developer-duties.dbk:133 +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:140 +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:147 +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:156 +msgid "Managing release-critical bugs" +msgstr "" + +# type: Content of: <chapter><section><para> +#: developer-duties.dbk:158 +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:169 +msgid "" +"Developers who are part of the <ulink url=\"http://qa.debian.org/\">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.debian.org</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:184 +msgid "Retiring" +msgstr "" + +# type: Content of: <chapter><section><para> +#: developer-duties.dbk:186 +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:192 +msgid "Orphan all your packages, as described in <xref linkend=\"orphaning\"/> ." +msgstr "" + +# type: Content of: <chapter><section><orderedlist><listitem><para> +#: developer-duties.dbk:197 +msgid "" +"Send an gpg-signed email about why you are leaving the project to " +"<email>debian-private@lists.debian.org</email>." +msgstr "" + +# type: Content of: <chapter><section><orderedlist><listitem><para> +#: developer-duties.dbk:203 +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 "" diff --git a/po4a/ja/index.po b/po4a/ja/index.po new file mode 100644 index 0000000..b328a2e --- /dev/null +++ b/po4a/ja/index.po @@ -0,0 +1,87 @@ +# 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-06-26 16:13+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:4 +msgid "en" +msgstr "" + +# type: Content of: <book><title> +#: index.dbk:6 +msgid "Debian Developer's Reference" +msgstr "" + +# type: Content of: <book><bookinfo><releaseinfo> +#: index.dbk:27 +msgid "ver. 3.3.9, 16 June, 2007" +msgstr "" + +# type: Content of: <book><bookinfo><copyright><holder> +#: index.dbk:34 +msgid "Andreas Barth" +msgstr "" + +# type: Content of: <book><bookinfo><copyright><holder> +#: index.dbk:43 +msgid "Adam Di Carlo" +msgstr "" + +# type: Content of: <book><bookinfo><copyright><holder> +#: index.dbk:48 +msgid "Raphaël Hertzog" +msgstr "" + +# type: Content of: <book><bookinfo><copyright><holder> +#: index.dbk:53 +msgid "Christian Schwarz" +msgstr "" + +# type: Content of: <book><bookinfo><legalnotice><para> +#: index.dbk:57 +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:62 +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:68 +msgid "" +"A copy of the GNU General Public License is available as " +"<filename>/usr/share/common-licenses/GPL</filename> in the Debian GNU/Linux " +"distribution or on the World Wide Web at <ulink " +"url=\"http://www.gnu.org/copyleft/gpl.html\">the GNU web site</ulink>. You " +"can also obtain it by writing to the Free Software Foundation, Inc., 51 " +"Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA." +msgstr "" + +# type: Content of: <book><bookinfo><legalnotice><para> +#: index.dbk:76 +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 "" diff --git a/po4a/ja/l10n.po b/po4a/ja/l10n.po new file mode 100644 index 0000000..d09b196 --- /dev/null +++ b/po4a/ja/l10n.po @@ -0,0 +1,342 @@ +# 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-06-26 16:13+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:5 +msgid "" +"Internationalizing, translating, being internationalized and being " +"translated" +msgstr "" + +# type: Content of: <chapter><para> +#: l10n.dbk:7 +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:15 +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:24 +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:32 +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:38 +msgid "How translations are handled within Debian" +msgstr "" + +# type: Content of: <chapter><section><para> +#: l10n.dbk:40 +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:44 +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:57 +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:64 +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:72 +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:76 +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:81 +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:85 +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:89 +msgid "" +"There is an effort to handle Debian-specific man pages within a <ulink " +"url=\"http://cvs.debian.org/manpages/?cvsroot=debian-doc\">specific CVS " +"repository</ulink>." +msgstr "" + +# type: Content of: <chapter><section><title> +#: l10n.dbk:96 +msgid "I18N & L10N FAQ for maintainers" +msgstr "" + +# type: Content of: <chapter><section><para> +#: l10n.dbk:98 +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:105 +msgid "How to get a given text translated" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: l10n.dbk:107 +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:112 +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:122 +msgid "How to get a given translation reviewed" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: l10n.dbk:124 +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:134 +msgid "How to get a given translation updated" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: l10n.dbk:136 +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:142 +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:148 +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:155 +msgid "How to handle a bug report concerning a translation" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: l10n.dbk:157 +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:166 +msgid "I18N & L10N FAQ for translators" +msgstr "" + +# type: Content of: <chapter><section><para> +#: l10n.dbk:168 +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:173 +msgid "How to help the translation effort" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: l10n.dbk:175 +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:183 +msgid "How to provide a translation for inclusion in a package" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: l10n.dbk:185 +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:191 +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:201 +msgid "Best current practice concerning l10n" +msgstr "" + +# type: Content of: <chapter><section><itemizedlist><listitem><para> +#: l10n.dbk:205 +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:213 +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:220 +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:230 +msgid "" +"In any case, cooperation can only be achieved with <emphasis " +"role=\"strong\">mutual respect</emphasis>." +msgstr "" diff --git a/po4a/ja/new-maintainer.po b/po4a/ja/new-maintainer.po new file mode 100644 index 0000000..a48fcef --- /dev/null +++ b/po4a/ja/new-maintainer.po @@ -0,0 +1,333 @@ +# 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-06-26 16:13+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:5 +msgid "Applying to Become a Maintainer" +msgstr "" + +# type: Content of: <chapter><section><title> +#: new-maintainer.dbk:7 +msgid "Getting started" +msgstr "" + +# type: Content of: <chapter><section><para> +#: new-maintainer.dbk:9 +msgid "" +"So, you've read all the documentation, you've gone through the <ulink " +"url=\"http://www.debian.org/doc/maint-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:17 +msgid "" +"Firstly, subscribe to <email>debian-devel@lists.debian.org</email> if you " +"haven't already. Send the word <literal>subscribe</literal> in the " +"<emphasis>Subject</emphasis> of an email to " +"<email>debian-devel-REQUEST@lists.debian.org</email>. In case of problems, " +"contact the list administrator at " +"<email>listmaster@lists.debian.org</email>. More information on available " +"mailing lists can be found in <xref linkend=\"mailing-lists\"/> . " +"<email>debian-devel-announce@lists.debian.org</email> 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:28 +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:33 +msgid "" +"Another good list to subscribe to is " +"<email>debian-mentors@lists.debian.org</email>. 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:39 +msgid "" +"When you know how you want to contribute to Debian GNU/Linux, 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@lists.debian.org</email> mailing list, describing your " +"package and yourself and asking for a sponsor (see <xref " +"linkend=\"sponsoring\"/> and <ulink " +"url=\"http://people.debian.org/~mpalmer/debian-mentors_FAQ.html\"></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=\"http://www.debian.org/MailingLists/\"></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@lists.debian.org</email> 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> +#: 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=\"http://people.debian.org/~mpalmer/debian-mentors_FAQ.html\"></ulink> " +"first." +msgstr "" + +# type: Content of: <chapter><section><para> +#: new-maintainer.dbk:84 +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:90 +msgid "Registering as a Debian developer" +msgstr "" + +# type: Content of: <chapter><section><para> +#: new-maintainer.dbk:92 +msgid "" +"Before you decide to register with Debian GNU/Linux, you will need to read " +"all the information available at the <ulink " +"url=\"http://www.debian.org/devel/join/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=\"http://www.debian.org/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 GNU/Linux. " +"Reading the <ulink url=\"http://www.gnu.org/gnu/manifesto.html\">GNU " +"Manifesto</ulink> would also be a good idea." +msgstr "" + +# type: Content of: <chapter><section><para> +#: new-maintainer.dbk:105 +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 GNU/Linux has grown to over 900 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:113 +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:122 +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=\"http://nm.debian.org/gpg.php\">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=\"http://www.debian.org/devel/join/nm-step2\">identification " +"page</ulink> for more information.)" +msgstr "" + +# type: Content of: <chapter><section><para> +#: new-maintainer.dbk:135 +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:143 +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=\"http://www.rfc-editor.org/rfc/rfc2440.txt\">RFC 2440</ulink>." +msgstr "" + +# type: Content of: <chapter><section><para><footnote> +#: new-maintainer.dbk:150 +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:152 +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:156 +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:160 +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 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 " +"<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:167 +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:169 +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:175 +msgid "" +"If your public key isn't on a public key server such as " +"<literal>subkeys.pgp.net</literal>, please read the documentation available " +"at <ulink url=\"http://www.debian.org/devel/join/nm-step2\">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:183 +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:191 +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:198 +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=\"http://nm.debian.org/newnm.php\">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=\"http://nm.debian.org/\">applications status board</ulink>." +msgstr "" + +# type: Content of: <chapter><section><para> +#: new-maintainer.dbk:208 +msgid "" +"For more details, please consult <ulink " +"url=\"http://www.debian.org/devel/join/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 "" diff --git a/po4a/ja/pkgs.po b/po4a/ja/pkgs.po new file mode 100644 index 0000000..994e65d --- /dev/null +++ b/po4a/ja/pkgs.po @@ -0,0 +1,3519 @@ +# 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-06-26 16:13+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:5 +msgid "Managing Packages" +msgstr "" + +# type: Content of: <chapter><para> +#: pkgs.dbk:7 +msgid "" +"This chapter contains information related to creating, uploading, " +"maintaining, and porting packages." +msgstr "" + +# type: Content of: <chapter><section><title> +#: pkgs.dbk:11 +msgid "New packages" +msgstr "" + +# type: Content of: <chapter><section><para> +#: pkgs.dbk:13 +msgid "" +"If you want to create a new package for the Debian distribution, you should " +"first check the <ulink " +"url=\"http://www.debian.org/devel/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=\"http://www.debian.org/devel/wnpp/\">WNPP " +"web pages</ulink> for more information." +msgstr "" + +# type: Content of: <chapter><section><para> +#: pkgs.dbk:21 +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:29 +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@lists.debian.org</email> 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:39 +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:45 +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:53 +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:59 +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:65 +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:71 +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:78 +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:84 +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:90 +msgid "" +"Please see <ulink " +"url=\"http://ftp-master.debian.org/REJECT-FAQ.html\"></ulink> for common " +"rejection reasons for a new package." +msgstr "" + +# type: Content of: <chapter><section><title> +#: pkgs.dbk:96 +msgid "Recording changes in the package" +msgstr "" + +# type: Content of: <chapter><section><para> +#: pkgs.dbk:98 +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:109 +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:117 +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:121 +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:125 +#, no-wrap +msgid "* new upstream version" +msgstr "" + +# type: Content of: <chapter><section><para> +#: pkgs.dbk:128 +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:133 +msgid "See also <xref linkend=\"bpp-debian-changelog\"/> ." +msgstr "" + +# type: Content of: <chapter><section><title> +#: pkgs.dbk:138 +msgid "Testing the package" +msgstr "" + +# type: Content of: <chapter><section><para> +#: pkgs.dbk:140 +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:147 +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:154 +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:163 +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:167 +msgid "" +"For more information on <command>lintian</command>, see <xref " +"linkend=\"lintian\"/> ." +msgstr "" + +# type: Content of: <chapter><section><itemizedlist><listitem><para> +#: pkgs.dbk:173 +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:179 +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:185 +msgid "Remove the package, then reinstall it." +msgstr "" + +# type: Content of: <chapter><section><itemizedlist><listitem><para> +#: pkgs.dbk:190 +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:200 +msgid "Layout of the source package" +msgstr "" + +# type: Content of: <chapter><section><para> +#: pkgs.dbk:202 +msgid "There are two types of Debian source packages:" +msgstr "" + +# type: Content of: <chapter><section><itemizedlist><listitem><para> +#: pkgs.dbk:207 +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:213 +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:219 +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:227 +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:233 +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:240 +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:248 +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:255 +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:262 +msgid "Picking a distribution" +msgstr "" + +# type: Content of: <chapter><section><para> +#: pkgs.dbk:264 +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:270 +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:275 +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:280 +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:284 +msgid "Special case: uploads to the <emphasis>stable</emphasis> distribution" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:286 +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:294 +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:301 +msgid "a truly critical functionality problem" +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: pkgs.dbk:306 +msgid "the package becomes uninstallable" +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: pkgs.dbk:311 +msgid "a released architecture lacks the package" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:316 +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:324 +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:328 +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:338 +msgid "" +"The Release Team (which can be reached at " +"<email>debian-release@lists.debian.org</email>) 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:347 +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:355 +msgid "" +"Special case: uploads to " +"<emphasis>testing/testing-proposed-updates</emphasis>" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:357 +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:365 +msgid "Uploading a package" +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: pkgs.dbk:367 +msgid "Uploading to <literal>ftp-master</literal>" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:369 +msgid "" +"To upload a package, you should upload the files (including the signed " +"changes and dsc-file) with anonymous ftp to " +"<literal>ftp-master.debian.org</literal> in the directory <ulink " +"url=\"ftp://ftp-master.debian.org/pub/UploadQueue/\">/pub/UploadQueue/</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:377 +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:382 +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:387 +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:393 +msgid "Uploading to <literal>non-US</literal>" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:395 +msgid "" +"<emphasis>Note:</emphasis> non-us was discontinued with the release of " +"sarge." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: pkgs.dbk:400 +msgid "Delayed uploads" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:402 +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:407 +msgid "With a fairly recent dput, this section" +msgstr "" + +# type: Content of: <chapter><section><section><screen> +#: pkgs.dbk:410 +#, 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:416 +msgid "in ~/.dput.cf should work fine for uploading to the DELAYED queue." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:419 +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:426 +msgid "Security uploads" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:428 +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:438 +msgid "Other upload queues" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:440 +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:444 +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:448 +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:454 +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:461 +msgid "Notification that a new package has been installed" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:463 +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:472 +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:478 +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:483 +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:491 +msgid "Specifying the package section, subsection and priority" +msgstr "" + +# type: Content of: <chapter><section><para> +#: pkgs.dbk:493 +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:501 +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:511 +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-change@debian.org</email> 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:519 +msgid "" +"For more information about <emphasis>override files</emphasis>, see " +"<citerefentry> <refentrytitle>dpkg-scanpackages</refentrytitle> " +"<manvolnum>1</manvolnum> </citerefentry> and <ulink " +"url=\"http://www.debian.org/Bugs/Developer#maintincorrect\"></ulink>." +msgstr "" + +# type: Content of: <chapter><section><para> +#: pkgs.dbk:525 +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=\"http://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections\"></ulink>." +msgstr "" + +# type: Content of: <chapter><section><title> +#: pkgs.dbk:534 +msgid "Handling bugs" +msgstr "" + +# type: Content of: <chapter><section><para> +#: pkgs.dbk:536 +msgid "" +"Every developer has to be able to work with the Debian <ulink " +"url=\"http://www.debian.org/Bugs/\">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:542 +msgid "" +"The bug tracking system's features are described in the <ulink " +"url=\"http://www.debian.org/Bugs/Developer\">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:548 +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=\"http://www.debian.org/Bugs/server-control\">BTS control server " +"documentation</ulink>." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: pkgs.dbk:556 +msgid "Monitoring bugs" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:558 +msgid "" +"If you want to be a good maintainer, you should periodically check the " +"<ulink url=\"http://www.debian.org/Bugs/\">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.debian.org/<replaceable>yourlogin</replaceable>@debian.org</literal>." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:565 +msgid "" +"Maintainers interact with the BTS via email addresses at " +"<literal>bugs.debian.org</literal>. Documentation on available commands can " +"be found at <ulink url=\"http://www.debian.org/Bugs/\"></ulink>, or, if you " +"have installed the <systemitem role=\"package\">doc-debian</systemitem> " +"package, you can look at the local files " +"<filename>/usr/share/doc/debian/bug-*</filename>." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:572 +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:577 +#, no-wrap +msgid "" +"# ask for weekly reports of bugs in my packages\n" +"0 17 * * fri echo index maint <replaceable>address</replaceable> | mail " +"request@bugs.debian.org" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:581 +msgid "" +"Replace <replaceable>address</replaceable> with your official Debian " +"maintainer address." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: pkgs.dbk:587 +msgid "Responding to bugs" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:589 +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.debian.org</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.debian.org</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.debian.org</email>)." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:598 +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:602 +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.debian.org</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:609 +msgid "" +"You should <emphasis>never</emphasis> close bugs via the bug server " +"<literal>close</literal> command sent to " +"<email>control@bugs.debian.org</email>. 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:617 +msgid "Bug housekeeping" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:619 +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=\"http://www.debian.org/Bugs/Developer\">BTS documentation for Debian " +"developers</ulink>. Operations such as reassigning, merging, and tagging " +"bug reports are described in the <ulink " +"url=\"http://www.debian.org/Bugs/server-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:630 +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:635 +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:640 +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:650 +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=\"http://www.debian.org/devel/tech-ctte\">recommended procedure</ulink>." +msgstr "" + +# type: Content of: <chapter><section><section><orderedlist><listitem><para> +#: pkgs.dbk:664 +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@lists.debian.org</email>. 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:672 +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:680 +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:691 +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:702 +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@lists.debian.org</email> or " +"<email>debian-qa@lists.debian.org</email>. 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:716 +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:726 +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:735 +msgid "When bugs are closed by new uploads" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:737 +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:745 +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:751 +#, no-wrap +msgid "" +"-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:759 +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:763 +#, no-wrap +msgid "/closes:\\s*(?:bug)?\\#\\s*\\d+(?:,\\s*(?:bug)?\\#\\s*\\d+)*/ig" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:766 +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:775 +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:781 +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>control@bugs.debian.org</email>. To close " +"any remaining bugs that were fixed by your upload, email the " +"<filename>.changes</filename> file to " +"<email>XXX-done@bugs.debian.org</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:793 +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.debian.org</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:801 +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:807 +msgid "Handling security-related bugs" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:809 +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:816 +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>team@security.debian.org</email> 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:826 +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:833 +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:838 +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:845 +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:851 +msgid "" +"Any information needed for the advisory (see <xref " +"linkend=\"bug-security-advisories\"/> )" +msgstr "" + +# type: Content of: <chapter><section><section><section><title> +#: pkgs.dbk:857 +msgid "Confidentiality" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:859 +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:866 +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:871 +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:876 +msgid "someone files a bug report" +msgstr "" + +# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> +#: pkgs.dbk:881 +msgid "someone informs them via private email" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:886 +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:894 +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:900 +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:907 +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:914 +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:920 +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:927 +msgid "Security Advisories" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:929 +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@lists.debian.org</email> mailing list and " +"posted on <ulink url=\"http://www.debian.org/security/\">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:942 +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:947 +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:952 +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:957 +msgid "How it can be exploited" +msgstr "" + +# type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para> +#: pkgs.dbk:962 +msgid "Whether it is remotely or locally exploitable" +msgstr "" + +# type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para> +#: pkgs.dbk:967 +msgid "How the problem was fixed" +msgstr "" + +# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> +#: pkgs.dbk:972 +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:977 +msgid "Version numbers of affected packages" +msgstr "" + +# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> +#: pkgs.dbk:982 +msgid "Version numbers of fixed packages" +msgstr "" + +# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> +#: pkgs.dbk:987 +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:993 +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:1002 +msgid "Preparing packages to address security issues" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:1004 +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:1009 +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:1017 +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:1023 +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:1030 +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:1037 +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:1047 +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:1055 +msgid "Be sure to verify the following items:" +msgstr "" + +# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> +#: pkgs.dbk:1060 +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:1070 +msgid "The upload should have urgency=high." +msgstr "" + +# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> +#: pkgs.dbk:1075 +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:1087 +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:1099 +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:1108 +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:1117 +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:1124 +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:1135 +msgid "Uploading the fixed package" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:1137 +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:1144 +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:1153 +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:1159 +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:1164 +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:1169 +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:1180 +msgid "Moving, removing, renaming, adopting, and orphaning packages" +msgstr "" + +# type: Content of: <chapter><section><para> +#: pkgs.dbk:1182 +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:1187 +msgid "Moving packages" +msgstr "" + +# type: Content of: <chapter><section><section><para><footnote> +#: pkgs.dbk:1189 +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:1191 +msgid "" +"See the <ulink url=\"http://www.debian.org/doc/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:1196 +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=\"http://www.debian.org/doc/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:1208 +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:1217 +msgid "Removing packages" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:1219 +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:1232 +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:1241 +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:1247 +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:1252 +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=\"http://qa.debian.org/howto-remove.html\"></ulink>." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:1257 +msgid "" +"If in doubt concerning whether a package is disposable, email " +"<email>debian-devel@lists.debian.org</email> 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@lists.debian.org</email>." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:1268 +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:1275 +msgid "Removing packages from <filename>Incoming</filename>" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:1277 +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:1292 +msgid "Replacing or renaming packages" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:1294 +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=\"http://www.debian.org/doc/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:1304 +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:1318 +msgid "Orphaning a package" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:1320 +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 " +"<packages@qa.debian.org></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@lists.debian.org</email> 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:1335 +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:1343 +msgid "" +"More information is on the <ulink " +"url=\"http://www.debian.org/devel/wnpp/\">WNPP web pages</ulink>." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: pkgs.dbk:1349 +msgid "Adopting a package" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:1351 +msgid "" +"A list of packages in need of a new maintainer is available in the <ulink " +"url=\"http://www.debian.org/devel/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:1358 +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:1364 +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=\"http://www.debian.org/devel/tech-ctte\">technical committee web " +"page</ulink> for more information)." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:1374 +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:1388 +msgid "Porting and being ported" +msgstr "" + +# type: Content of: <chapter><section><para> +#: pkgs.dbk:1390 +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:1396 +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 12 more builds." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: pkgs.dbk:1404 +msgid "Being kind to porters" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:1406 +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:1414 +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:1421 +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:1428 +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:1442 +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:1446 +msgid "" +"See the <ulink url=\"http://www.debian.org/doc/debian-policy/\">Debian " +"Policy Manual</ulink> for instructions on setting build dependencies." +msgstr "" + +# type: Content of: <chapter><section><section><orderedlist><listitem><para> +#: pkgs.dbk:1452 +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=\"http://www.debian.org/doc/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:1460 +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:1468 +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:1476 +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:1485 +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:1491 +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:1499 +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:1510 +msgid "Guidelines for porter uploads" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:1512 +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:1520 +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:1525 +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:1533 +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:1540 +msgid "Recompilation or binary-only NMU" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:1542 +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:1551 +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:1557 +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:1562 +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:1569 +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:1574 +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:1582 +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:1589 +msgid "When to do a source NMU if you are a porter" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:1591 +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:1600 +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:1611 +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:1619 +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:1627 +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:1637 +msgid "Porting infrastructure and automation" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:1639 +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:1644 +msgid "Mailing lists and web pages" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:1646 +msgid "" +"Web pages containing the status of each port can be found at <ulink " +"url=\"http://www.debian.org/ports/\"></ulink>." +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:1650 +msgid "" +"Each port of Debian has a mailing list. The list of porting mailing lists " +"can be found at <ulink url=\"http://lists.debian.org/ports.html\"></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:1658 +msgid "Porter tools" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:1660 +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:1668 +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:1677 +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:1687 +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=\"http://buildd.debian.org/\"></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:1695 +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:1702 +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:1710 +msgid "When your package is <emphasis>not</emphasis> portable" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:1712 +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:1719 +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:1725 +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:1733 +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:1741 +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=\"http://cvs.debian.org/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:1751 +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:1764 +msgid "Non-Maintainer Uploads (NMUs)" +msgstr "" + +# type: Content of: <chapter><section><para> +#: pkgs.dbk:1766 +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:1771 +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:1778 +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:1783 +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:1792 +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:1797 +msgid "How to do a NMU" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:1799 +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:1805 +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:1811 +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:1817 +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:1824 +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:1831 +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:1841 +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:1849 +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:1856 +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:1865 +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:1870 +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:1876 +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:1881 +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:1885 +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:1892 +msgid "NMU version numbering" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:1894 +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:1898 +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:1909 +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:1915 +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:1925 +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:1932 +msgid "Source NMUs must have a new changelog entry" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:1934 +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:1940 +msgid "By convention, source NMU changelog entries start with the line" +msgstr "" + +# type: Content of: <chapter><section><section><screen> +#: pkgs.dbk:1943 +#, no-wrap +msgid "* Non-maintainer upload" +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: pkgs.dbk:1948 +msgid "Source NMUs and the Bug Tracking System" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:1950 +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:1956 +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:1963 +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:1968 +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:1979 +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:1987 +msgid "Building source NMUs" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:1989 +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:1994 +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:2002 +msgid "Acknowledging an NMU" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:2004 +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:2015 +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:2025 +msgid "NMU vs QA uploads" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:2027 +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=\"http://qa.debian.org/orphaned.html\"></ulink>. If you perform " +"an NMU on an improperly orphaned package, please set the maintainer to " +"``Debian QA Group <packages@qa.debian.org>''." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: pkgs.dbk:2037 +msgid "Who can do an NMU" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:2039 +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:2049 +msgid "Terminology" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:2051 +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:2059 +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:2068 +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:2078 +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:2088 +msgid "Collaborative maintenance" +msgstr "" + +# type: Content of: <chapter><section><para> +#: pkgs.dbk:2090 +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:2098 +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:2104 +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:2110 +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:2118 +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:2123 +#, no-wrap +msgid ": John Buzz <jbuzz@debian.org>, Adam Rex <arex@debian.org>" +msgstr "" + +# type: Content of: <chapter><section><itemizedlist><listitem><para> +#: pkgs.dbk:2128 +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:2134 +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:2143 +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:2150 +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:2158 +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:2166 +msgid "The testing distribution" +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: pkgs.dbk:2168 +msgid "Basics" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:2170 +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:2174 +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:2183 +msgid "Updates from unstable" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:2185 +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:2193 +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:2199 +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:2208 +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:2214 +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:2221 +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:2227 +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:2235 +msgid "" +"To find out whether a package is progressing into testing or not, see the " +"testing script output on the <ulink " +"url=\"http://www.debian.org/devel/testing\">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:2246 +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=\"http://www.debian.org/devel/testing\">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:2253 +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:2258 +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:2263 +msgid "out-of-date" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:2265 +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:2272 +msgid "Consider this example:" +msgstr "" + +# type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry> +#: pkgs.dbk:2279 pkgs.dbk:2310 +msgid "alpha" +msgstr "" + +# type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry> +#: pkgs.dbk:2280 pkgs.dbk:2311 +msgid "arm" +msgstr "" + +# type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry> +#: pkgs.dbk:2285 pkgs.dbk:2317 pkgs.dbk:2377 +msgid "testing" +msgstr "" + +# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry> +#: pkgs.dbk:2286 pkgs.dbk:2291 pkgs.dbk:2318 pkgs.dbk:2319 pkgs.dbk:2326 +msgid "1" +msgstr "" + +# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry> +#: pkgs.dbk:2287 pkgs.dbk:2320 pkgs.dbk:2325 +msgid "-" +msgstr "" + +# type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry> +#: pkgs.dbk:2290 pkgs.dbk:2323 pkgs.dbk:2378 +msgid "unstable" +msgstr "" + +# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry> +#: pkgs.dbk:2292 pkgs.dbk:2324 +msgid "2" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:2298 +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:2303 +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:2312 +msgid "hurd-i386" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:2332 +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:2337 +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:2344 +msgid "Removals from testing" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:2346 +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:2353 +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:2357 +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:2363 +msgid "circular dependencies" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:2365 +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:2370 +msgid "An example of this is:" +msgstr "" + +# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry> +#: pkgs.dbk:2383 +msgid "a" +msgstr "" + +# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry> +#: pkgs.dbk:2384 +msgid "1; depends: b=1" +msgstr "" + +# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry> +#: pkgs.dbk:2385 +msgid "2; depends: b=2" +msgstr "" + +# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry> +#: pkgs.dbk:2388 +msgid "b" +msgstr "" + +# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry> +#: pkgs.dbk:2389 +msgid "1; depends: a=1" +msgstr "" + +# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry> +#: pkgs.dbk:2390 +msgid "2; depends: a=2" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:2396 +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:2400 +msgid "" +"Currently, this requires some manual hinting from the release team. Please " +"contact them by sending mail to " +"<email>debian-release@lists.debian.org</email> if this happens to one of " +"your packages." +msgstr "" + +# type: Content of: <chapter><section><section><section><title> +#: pkgs.dbk:2407 +msgid "influence of package in testing" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:2409 +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:2419 +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:2426 +msgid "details" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:2428 +msgid "If you are interested in details, this is how britney works:" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:2431 +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:2440 +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:2448 +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.debian.org/testing/update_out_code/\"></ulink>" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:2455 +msgid "" +"The hints are available via <ulink " +"url=\"http://ftp-master.debian.org/testing/hints/\"></ulink>." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: pkgs.dbk:2463 +msgid "Direct updates to testing" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:2465 +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:2471 +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@lists.debian.org</email>." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:2478 +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:2487 +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:2492 +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:2497 +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:2503 +msgid "Make sure that you included only the minimal amount of changes;" +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: pkgs.dbk:2508 +msgid "Make sure that you included an appropriate explanation in the changelog;" +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: pkgs.dbk:2513 +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:2519 +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:2525 +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:2532 +msgid "" +"After uploading and successful build on all platforms, contact the release " +"team at <email>debian-release@lists.debian.org</email> and ask them to " +"approve your upload." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: pkgs.dbk:2541 +msgid "Frequently asked questions" +msgstr "" + +# type: Content of: <chapter><section><section><section><title> +#: pkgs.dbk:2543 +msgid "What are release-critical bugs, and how do they get counted?" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:2545 +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:2549 +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:2555 +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:2562 +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:2568 +msgid "How could installing a package into testing possibly break other packages?" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:2570 +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:2577 +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:2582 +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:2588 +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:2598 +msgid "" +"If you are having problems with complicated groups of packages like this, " +"contact debian-devel or debian-release for help." +msgstr "" diff --git a/po4a/ja/resources.po b/po4a/ja/resources.po new file mode 100644 index 0000000..856c359 --- /dev/null +++ b/po4a/ja/resources.po @@ -0,0 +1,1995 @@ +# 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-06-26 16:13+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:5 +msgid "Resources for Debian Developers" +msgstr "" + +# type: Content of: <chapter><para> +#: resources.dbk:7 +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:12 +msgid "Mailing lists" +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:14 +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.debian.org/\">lists.debian.org</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=\"http://www.debian.org/MailingLists/\"></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:24 +msgid "Basic rules for use" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:26 +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:32 +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:37 +msgid "" +"Please read the <ulink " +"url=\"http://www.debian.org/MailingLists/#codeofconduct\">code of " +"conduct</ulink> for more information." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: resources.dbk:44 +msgid "Core development mailing lists" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:46 +msgid "The core Debian mailing lists that developers should use are:" +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: resources.dbk:51 +msgid "" +"<email>debian-devel-announce@lists.debian.org</email>, 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:58 +msgid "" +"<email>debian-devel@lists.debian.org</email>, used to discuss various " +"development related technical issues." +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: resources.dbk:64 +msgid "" +"<email>debian-policy@lists.debian.org</email>, where the Debian Policy is " +"discussed and voted on." +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: resources.dbk:70 +msgid "" +"<email>debian-project@lists.debian.org</email>, used to discuss various " +"non-technical issues related to the project." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:76 +msgid "" +"There are other mailing lists available for a variety of special topics; see " +"<ulink url=\"http://lists.debian.org/\"></ulink> for a list." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: resources.dbk:82 +msgid "Special lists" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:84 +msgid "" +"<email>debian-private@lists.debian.org</email> 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@lists.debian.org</email> 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.debian.org</literal> and looking in the " +"<filename>~debian/archive/debian-private</filename> directory." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:96 +msgid "" +"<email>debian-email@lists.debian.org</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:104 +msgid "Requesting new development-related lists" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:106 +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:114 +msgid "" +"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 <ulink " +"url=\"http://www.debian.org/MailingLists/HOWTO_start_list\">the " +"HOWTO</ulink>." +msgstr "" + +# type: Content of: <chapter><section><title> +#: resources.dbk:123 +msgid "IRC channels" +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:125 +msgid "" +"Several IRC channels are dedicated to Debian's development. They are mainly " +"hosted on the <ulink url=\"http://www.oftc.net/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:131 +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:139 +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:147 +msgid "" +"Since <emphasis>#debian-devel</emphasis> is an open channel, you should not " +"speak there of issues that are discussed in " +"<email>debian-private@lists.debian.org</email>. 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:~debian/archive/debian-private/</filename>, " +"just <command>zgrep</command> for <emphasis>#debian-private</emphasis> in " +"all the files." +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:157 +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:169 +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:174 +msgid "" +"Channels dedicated to Debian also exist on other IRC networks, notably on " +"the <ulink url=\"http://www.freenode.net/\">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:179 +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:190 +msgid "Documentation" +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:192 +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=\"http://www.debian.org/devel/\">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:201 +msgid "Debian machines" +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:203 +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:208 +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=\"http://www.debian.org/devel/dmup\">Debian Machine Usage " +"Policies</ulink>." +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:213 +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:220 +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:225 +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:229 +msgid "" +"The current list of Debian machines is available at <ulink " +"url=\"http://db.debian.org/machines.cgi\"></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:235 +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.debian.org</email>." +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:241 +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:248 +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:252 +msgid "The bugs server" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:254 +msgid "" +"<literal>bugs.debian.org</literal> is the canonical location for the Bug " +"Tracking System (BTS)." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:258 resources.dbk:276 +msgid "It is restricted; a mirror is available on <literal>merkel</literal>." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:261 +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@lists.debian.org</email> before implementing anything, " +"however, to reduce unnecessary duplication of effort or wasted processing " +"time." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: resources.dbk:269 +msgid "The ftp-master server" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:271 +msgid "" +"The <literal>ftp-master.debian.org</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:279 +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@debian.org</email>, but also " +"see the procedures in <xref linkend=\"archive-manip\"/> ." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: resources.dbk:287 +msgid "The non-US server" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:289 +msgid "" +"The non-US server <literal>non-us.debian.org</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:296 +msgid "The www-master server" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:298 +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:302 +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.debian.org/www.debian.org\">Bug Tracking System</ulink>." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: resources.dbk:311 +msgid "The people web server" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:313 +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:317 +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:324 +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:328 +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:333 +msgid "" +"Send mail to <email>debian-devel@lists.debian.org</email> if you have any " +"questions." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: resources.dbk:339 +msgid "The CVS server" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:341 +msgid "Our CVS server is located on <literal>cvs.debian.org</literal>." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:344 +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:349 +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=\"http://cvs.debian.org/\"></ulink>." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:355 +msgid "" +"To request a CVS area, send a request via email to " +"<email>debian-admin@debian.org</email>. 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:363 +msgid "chroots to different distributions" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:365 +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:369 +#, no-wrap +msgid "" +"% dchroot unstable\n" +"Executing shell in chroot: /org/vore.debian.org/chroots/user/unstable" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:373 +msgid "" +"In all chroots, the normal user home directories are available. You can " +"find out which chroots are available via " +"<literal>http://db.debian.org/machines.cgi</literal>." +msgstr "" + +# type: Content of: <chapter><section><title> +#: resources.dbk:382 +msgid "The Developers Database" +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:384 +msgid "" +"The Developers Database, at <ulink url=\"https://db.debian.org/\"></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:391 +msgid "" +"Developers can <ulink url=\"https://db.debian.org/login.html\">log into the " +"database</ulink> to change various information about themselves, such as:" +msgstr "" + +# type: Content of: <chapter><section><itemizedlist><listitem><para> +#: resources.dbk:397 +msgid "forwarding address for your debian.org email" +msgstr "" + +# type: Content of: <chapter><section><itemizedlist><listitem><para> +#: resources.dbk:402 +msgid "subscription to debian-private" +msgstr "" + +# type: Content of: <chapter><section><itemizedlist><listitem><para> +#: resources.dbk:407 +msgid "whether you are on vacation" +msgstr "" + +# type: Content of: <chapter><section><itemizedlist><listitem><para> +#: resources.dbk:412 +msgid "" +"personal information such as your address, country, the latitude and " +"longitude of the place where you live for use in <ulink " +"url=\"http://www.debian.org/devel/developers.loc\">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:420 +msgid "password and preferred shell on Debian Project machines" +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:425 +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=\"http://db.debian.org/doc-general.html\"></ulink>." +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:430 +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=\"http://db.debian.org/doc-mail.html\"></ulink>." +msgstr "" + +# type: Content of: <chapter><section><title> +#: resources.dbk:438 +msgid "The Debian archive" +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:440 +msgid "" +"The Debian GNU/Linux distribution consists of a lot of packages " +"(<filename>.deb</filename>'s, currently around 9000) and a few additional " +"files (such as documentation and installation disk images)." +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:445 +msgid "Here is an example directory tree of a complete Debian archive:" +msgstr "" + +# type: Content of: <chapter><section><screen> +#: resources.dbk:448 +#, no-wrap +msgid "" +"/stable/main/\n" +"dists/stable/main/binary-i386/\n" +"dists/stable/main/binary-m68k/\n" +"dists/stable/main/binary-alpha/\n" +" ...\n" +"dists/stable/main/source/\n" +" ...\n" +"dists/stable/main/disks-i386/\n" +"dists/stable/main/disks-m68k/\n" +"dists/stable/main/disks-alpha/\n" +" ...\n" +"\n" +"dists/stable/contrib/\n" +"dists/stable/contrib/binary-i386/\n" +"dists/stable/contrib/binary-m68k/\n" +"dists/stable/contrib/binary-alpha/\n" +" ...\n" +"dists/stable/contrib/source/\n" +"\n" +"dists/stable/non-free/\n" +"dists/stable/non-free/binary-i386/\n" +"dists/stable/non-free/binary-m68k/\n" +"dists/stable/non-free/binary-alpha/\n" +" ...\n" +"dists/stable/non-free/source/\n" +"\n" +"dists/testing/\n" +"dists/testing/main/\n" +" ...\n" +"dists/testing/contrib/\n" +" ...\n" +"dists/testing/non-free/\n" +" ...\n" +"\n" +"dists/unstable\n" +"dists/unstable/main/\n" +" ...\n" +"dists/unstable/contrib/\n" +" ...\n" +"dists/unstable/non-free/\n" +" ...\n" +"\n" +"pool/\n" +"pool/main/a/\n" +"pool/main/a/apt/\n" +" ...\n" +"pool/main/b/\n" +"pool/main/b/bash/\n" +" ...\n" +"pool/main/liba/\n" +"pool/main/liba/libalias-perl/\n" +" ...\n" +"pool/main/m/\n" +"pool/main/m/mailx/\n" +" ...\n" +"pool/non-free/n/\n" +"pool/non-free/n/netscape/\n" +" ..." +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:508 +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:522 +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:527 +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:532 +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:538 +msgid "Sections" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:540 +msgid "" +"The <emphasis>main</emphasis> section of the Debian archive is what makes up " +"the <emphasis role=\"strong\">official Debian GNU/Linux " +"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 GNU/Linux." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:548 +msgid "" +"Every package in the main section must fully comply with the <ulink " +"url=\"http://www.debian.org/social_contract#guidelines\">Debian Free " +"Software Guidelines</ulink> (DFSG) and with all other policy requirements as " +"described in the <ulink " +"url=\"http://www.debian.org/doc/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:556 +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:561 +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:568 +msgid "" +"The <ulink url=\"http://www.debian.org/doc/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:573 +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:581 +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:587 +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:597 +msgid "Architectures" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:599 +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:604 +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:618 +msgid "" +"Debian GNU/Linux 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:629 +msgid "" +"Information for developers and users about the specific ports are available " +"at the <ulink url=\"http://www.debian.org/ports/\">Debian Ports web " +"pages</ulink>." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: resources.dbk:635 +msgid "Packages" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:637 +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:641 +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:647 +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:657 +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:664 +msgid "Distributions" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:666 +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:672 +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:679 +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:687 +msgid "Stable, testing, and unstable" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: resources.dbk:689 +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:696 +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:705 +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:712 +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.debian.org</literal>)." +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: resources.dbk:729 +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:746 +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:753 +msgid "More information about the testing distribution" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: resources.dbk:755 +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:759 +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:765 +msgid "Experimental" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: resources.dbk:767 +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:778 +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><screen> +#: resources.dbk:783 +#, no-wrap +msgid "" +"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:787 +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:793 +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:803 +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:813 +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:817 +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:821 +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:830 +msgid "Release code names" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:832 +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:844 +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:853 +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:861 +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:875 +msgid "Debian mirrors" +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:877 +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:888 +msgid "" +"All the information on Debian mirrors, including a list of the available " +"public FTP/HTTP servers, can be found at <ulink " +"url=\"http://www.debian.org/mirror/\"></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:895 +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:902 +msgid "The Incoming system" +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:904 +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.debian.org</literal>." +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:909 +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:928 +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=\"http://incoming.debian.org/\"></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:940 +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@lists.debian.org</email>. If a package is released " +"with <literal>Distribution:</literal> set to `unstable' or `experimental', " +"the announcement will be posted to " +"<email>debian-devel-changes@lists.debian.org</email> instead." +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:950 +msgid "" +"Though ftp-master is restricted, a copy of the installation is available to " +"all developers on <literal>merkel.debian.org</literal>." +msgstr "" + +# type: Content of: <chapter><section><title> +#: resources.dbk:956 +msgid "Package information" +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: resources.dbk:958 +msgid "On the web" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:960 +msgid "" +"Each package has several dedicated web pages. " +"<literal>http://packages.debian.org/<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:967 +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.debian.org/<replaceable>package-name</replaceable></literal>." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: resources.dbk:974 +msgid "The <command>madison</command> utility" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:976 +msgid "" +"<command>madison</command> is a command-line utility that is available on " +"<literal>ftp-master.debian.org</literal>, and on the mirror on " +"<literal>merkel.debian.org</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:984 +#, 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:991 +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:1001 +msgid "The Package Tracking System" +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:1003 +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:1008 +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:1012 +msgid "By default you will get:" +msgstr "" + +# type: Content of: <chapter><section><variablelist><varlistentry><listitem><para> +#: resources.dbk:1019 +msgid "All the bug reports and following discussions." +msgstr "" + +# type: Content of: <chapter><section><variablelist><varlistentry><listitem><para> +#: resources.dbk:1027 +msgid "" +"The email notifications from <email>control@bugs.debian.org</email> about " +"bug report status changes." +msgstr "" + +# type: Content of: <chapter><section><variablelist><varlistentry><listitem><para> +#: resources.dbk:1036 +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:1045 +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:1054 +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>@packages.qa.debian.org</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:1066 +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:1073 +msgid "You can also decide to receive additional information:" +msgstr "" + +# type: Content of: <chapter><section><variablelist><varlistentry><listitem><para> +#: resources.dbk:1080 +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:1091 +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:1100 +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:1109 +msgid "" +"Information about changes made to the package in derivative distributions " +"(for example Ubuntu)." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: resources.dbk:1116 +msgid "The PTS email interface" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:1118 +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:1126 +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:1139 +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:1149 +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:1158 +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:1167 +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:1174 +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:1179 +msgid "" +"<literal>bts-control</literal>: reply to mails sent to " +"<email>control@bugs.debian.org</email>" +msgstr "" + +# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><itemizedlist><listitem><para> +#: resources.dbk:1185 +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:1191 +msgid "<literal>cvs</literal>: notification of CVS commits" +msgstr "" + +# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><itemizedlist><listitem><para> +#: resources.dbk:1196 +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:1201 +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:1207 +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:1213 +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:1219 +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:1225 +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:1235 +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:1244 +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:1254 +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:1264 +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:1273 +msgid "Stops processing commands. All following lines are ignored by the bot." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:1279 +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:1287 +msgid "Filtering PTS mails" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:1289 +msgid "" +"Once you are subscribed to a package, you will get the mails sent to " +"<literal><replaceable>sourcepackage</replaceable>@packages.qa.debian.org</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:1297 +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:1301 +#, no-wrap +msgid "" +"-Loop: dpkg@packages.qa.debian.org\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:1309 +msgid "Forwarding CVS commits in the PTS" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:1311 +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:1317 +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@packages.qa.debian.org</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:1326 +msgid "The PTS web interface" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:1328 +msgid "" +"The PTS has a web interface at <ulink " +"url=\"http://packages.qa.debian.org/\"></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:1338 +msgid "" +"You can jump directly to the web page concerning a specific source package " +"with a URL like " +"<literal>http://packages.qa.debian.org/<replaceable>sourcepackage</replaceable></literal>." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:1343 +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:1349 +msgid "Static news items can be used to indicate:" +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: resources.dbk:1354 +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:1360 +msgid "a link to the upstream web site" +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: resources.dbk:1365 +msgid "a link to the upstream bug tracker" +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: resources.dbk:1370 +msgid "the existence of an IRC channel dedicated to the software" +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: resources.dbk:1375 +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:1381 +msgid "Usual news items may be used to announce that:" +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: resources.dbk:1386 +msgid "beta packages are available for testing" +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: resources.dbk:1391 +msgid "final packages are expected for next week" +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: resources.dbk:1396 +msgid "the packaging is about to be redone from scratch" +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: resources.dbk:1401 +msgid "backports are available" +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: resources.dbk:1406 +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:1411 +msgid "a NMU is being worked on" +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: resources.dbk:1416 +msgid "something important will affect the package" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:1421 +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:1432 +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:1437 +#, no-wrap +msgid "" +": 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: http://cvs.debian.org/debian-cd/" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:1445 +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:1450 +#, no-wrap +msgid "" +": Raphael Hertzog <hertzog@debian.org>\n" +"To: debian-gtk-gnome@lists.debian.org\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:1463 +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:1473 +msgid "Developer's packages overview" +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:1475 +msgid "" +"A QA (quality assurance) web portal is available at <ulink " +"url=\"http://qa.debian.org/developer.php\"></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:1484 +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:1491 +msgid "Debian *Forge: Alioth" +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:1493 +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:1500 +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:1506 +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:1511 +msgid "" +"For more information please visit <ulink " +"url=\"http://alioth.debian.org/\"></ulink>." +msgstr "" + +# type: Content of: <chapter><section><title> +#: resources.dbk:1517 +msgid "Goodies for Developers" +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: resources.dbk:1519 +msgid "LWN Subscriptions" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:1521 +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.debian.org/debian-devel-announce/2002/10/msg00018.html\"></ulink>." +msgstr "" diff --git a/po4a/ja/scope.po b/po4a/ja/scope.po new file mode 100644 index 0000000..2154e96 --- /dev/null +++ b/po4a/ja/scope.po @@ -0,0 +1,72 @@ +# 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-06-26 16:12+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:5 +msgid "Scope of This Document" +msgstr "" + +# type: Content of: <chapter><para> +#: scope.dbk:7 +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:11 +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:20 +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:28 +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=\"http://www.debian.org/doc/debian-policy/\">Debian Policy " +"Manual</ulink>." +msgstr "" + +# type: Content of: <chapter><para> +#: scope.dbk:35 +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 "" diff --git a/po4a/ja/tools.po b/po4a/ja/tools.po new file mode 100644 index 0000000..7cca30a --- /dev/null +++ b/po4a/ja/tools.po @@ -0,0 +1,654 @@ +# 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-06-26 16:13+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:5 +msgid "Overview of Debian Maintainer Tools" +msgstr "" + +# type: Content of: <appendix><para> +#: tools.dbk:7 +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:12 +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:16 +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:24 +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 " +"<literal>apt-cache show <package-name></literal>." +msgstr "" + +# type: Content of: <appendix><section><title> +#: tools.dbk:30 +msgid "Core tools" +msgstr "" + +# type: Content of: <appendix><section><para> +#: tools.dbk:32 +msgid "The following tools are pretty much required for any maintainer." +msgstr "" + +# type: Content of: <appendix><section><section><para> +#: tools.dbk:37 +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:48 +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:54 +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:58 +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:68 +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:79 +msgid "Package lint tools" +msgstr "" + +# type: Content of: <appendix><section><para> +#: tools.dbk:81 +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:89 +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:95 +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:102 +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:106 +msgid "" +"You can also see a summary of all problems reported by Lintian on your " +"packages at <ulink url=\"http://lintian.debian.org/\"></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:116 +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:125 +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:134 +msgid "You can run it over a pair of binary packages:" +msgstr "" + +# type: Content of: <appendix><section><section><screen> +#: tools.dbk:137 +#, no-wrap +msgid "package_1-1_arch.deb package_2-1_arch.deb" +msgstr "" + +# type: Content of: <appendix><section><section><para> +#: tools.dbk:140 +msgid "Or even a pair of changes files:" +msgstr "" + +# type: Content of: <appendix><section><section><screen> +#: tools.dbk:143 +#, no-wrap +msgid "package_1-1_arch.changes package_2-1_arch.changes" +msgstr "" + +# type: Content of: <appendix><section><section><para> +#: tools.dbk:146 +msgid "" +"For more information please see <citerefentry> " +"<refentrytitle>debdiff</refentrytitle> <manvolnum>1</manvolnum> " +"</citerefentry>." +msgstr "" + +# type: Content of: <appendix><section><title> +#: tools.dbk:155 +msgid "Helpers for <filename>debian/rules</filename>" +msgstr "" + +# type: Content of: <appendix><section><para> +#: tools.dbk:157 +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:165 +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:173 +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:179 +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:188 +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:198 +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:209 +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:217 +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:227 +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:237 +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:245 +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:256 +msgid "Package builders" +msgstr "" + +# type: Content of: <appendix><section><para> +#: tools.dbk:258 +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:264 +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:270 +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:281 +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:287 +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:297 +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:303 +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:312 +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=\"http://buildd.debian.org/\"></ulink> to see the system in action." +msgstr "" + +# type: Content of: <appendix><section><title> +#: tools.dbk:324 +msgid "Package uploaders" +msgstr "" + +# type: Content of: <appendix><section><para> +#: tools.dbk:326 +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:332 +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:342 +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:354 +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:362 +msgid "Maintenance automation" +msgstr "" + +# type: Content of: <appendix><section><para> +#: tools.dbk:364 +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:371 +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:385 +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:394 +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:405 +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:411 +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:420 +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:429 +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:437 +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:448 +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:454 +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:460 +#, no-wrap +msgid "-depcheck -b debian/rules build" +msgstr "" + +# type: Content of: <appendix><section><section><para> +#: tools.dbk:463 +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:467 +msgid "" +"For more information please see <citerefentry> " +"<refentrytitle>dpkg-depcheck</refentrytitle> <manvolnum>1</manvolnum> " +"</citerefentry>." +msgstr "" + +# type: Content of: <appendix><section><title> +#: tools.dbk:476 +msgid "Porting tools" +msgstr "" + +# type: Content of: <appendix><section><para> +#: tools.dbk:478 +msgid "The following tools are helpful for porters and for cross-compilation." +msgstr "" + +# type: Content of: <appendix><section><section><para> +#: tools.dbk:483 +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:493 +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:504 +msgid "Documentation and information" +msgstr "" + +# type: Content of: <appendix><section><para> +#: tools.dbk:506 +msgid "" +"The following packages provide information for maintainers or help with " +"building documentation." +msgstr "" + +# type: Content of: <appendix><section><section><para> +#: tools.dbk:512 +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:518 +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:526 +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:534 +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 "" diff --git a/po4a/po/best-pkging-practices.pot b/po4a/po/best-pkging-practices.pot new file mode 100644 index 0000000..afae0ad --- /dev/null +++ b/po4a/po/best-pkging-practices.pot @@ -0,0 +1,2506 @@ +# 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-06-26 16:13+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:5 +msgid "Best Packaging Practices" +msgstr "" + +# type: Content of: <chapter><para> +#: best-pkging-practices.dbk:7 +msgid "" +"Debian's quality is largely due to the <ulink " +"url=\"http://www.debian.org/doc/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:16 +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:22 +msgid "Best practices for <filename>debian/rules</filename>" +msgstr "" + +# type: Content of: <chapter><section><para> +#: best-pkging-practices.dbk:24 +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:30 +msgid "Helper scripts" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:32 +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:43 +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:50 +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:64 +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:77 +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=\"http://arch.debian.org/arch/private/srivasta/\"></ulink>." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: best-pkging-practices.dbk:86 +msgid "Separating your patches into multiple files" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:88 +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:97 +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:107 +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:114 +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:122 +msgid "Multiple binary packages" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:124 +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:131 +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:140 +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:150 +msgid "Best practices for <filename>debian/control</filename>" +msgstr "" + +# type: Content of: <chapter><section><para> +#: best-pkging-practices.dbk:152 +msgid "" +"The following practices are relevant to the " +"<filename>debian/control</filename> file. They supplement the <ulink " +"url=\"http://www.debian.org/doc/debian-policy/ch-binary.html#s-descriptions\">Policy " +"on package descriptions</ulink>." +msgstr "" + +# type: Content of: <chapter><section><para> +#: best-pkging-practices.dbk:158 +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:167 +msgid "General guidelines for package descriptions" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:169 +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:176 +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:182 +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:189 +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:194 +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:201 +msgid "" +"If you are having problems writing your description, you may wish to send it " +"along to <email>debian-l10n-english@lists.debian.org</email> and request " +"feedback." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: best-pkging-practices.dbk:208 +msgid "The package synopsis, or short description" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:210 +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:214 +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:223 +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:227 +#, no-wrap +msgid "" +"<replaceable>package-name</replaceable> is a " +"<replaceable>synopsis</replaceable>." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:230 +msgid "Alternatively, it might make sense to think of it as" +msgstr "" + +# type: Content of: <chapter><section><section><screen> +#: best-pkging-practices.dbk:233 +#, no-wrap +msgid "" +"<replaceable>package-name</replaceable> is " +"<replaceable>synopsis</replaceable>." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:236 +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:239 +#, no-wrap +msgid "" +"<replaceable>package-name</replaceable> are " +"<replaceable>synopsis</replaceable>." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:242 +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:249 +msgid "The long description" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:251 +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:257 +msgid "The long description should consist of full and complete sentences." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:260 +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:266 +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:274 +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:279 +#, no-wrap +msgid "-d american -g debian/control" +msgstr "" + +# type: Content of: <chapter><section><section><screen> +#: best-pkging-practices.dbk:282 +#, no-wrap +msgid "-d en -D -c debian/control" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:285 +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:290 +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:296 +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:303 +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:309 +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:316 +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:325 +msgid "Upstream home page" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:327 +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:332 +#, no-wrap +msgid "" +".\n" +" Homepage: http://some-project.some-place.org/" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:336 +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=\"http://packages.debian.org/unstable/web/wml\"></ulink>." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:341 +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:344 +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.debian.org</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.debian.org</filename> to " +"parse it correctly." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: best-pkging-practices.dbk:355 +msgid "Version Control System location" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:357 +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:361 +msgid "XS-Vcs-Browser" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:363 +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:368 +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:375 +msgid "XS-Vcs-*" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:377 +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:388 +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:399 +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:407 +#, 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:421 +msgid "Best practices for <filename>debian/changelog</filename>" +msgstr "" + +# type: Content of: <chapter><section><para> +#: best-pkging-practices.dbk:423 +msgid "" +"The following practices supplement the <ulink " +"url=\"http://www.debian.org/doc/debian-policy/ch-docs.html#s-changelogs\">Policy " +"on changelog files</ulink>." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: best-pkging-practices.dbk:428 +msgid "Writing useful changelog entries" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:430 +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:435 +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:441 +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:448 +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:454 +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:460 +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:467 +msgid "Common misconceptions about changelog entries" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:469 +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:477 +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:482 +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:493 +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:501 +msgid "Common errors in changelog entries" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:503 +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:507 +#, no-wrap +msgid "* Fixed all outstanding bugs." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:510 +msgid "This doesn't tell readers anything too useful, obviously." +msgstr "" + +# type: Content of: <chapter><section><section><screen> +#: best-pkging-practices.dbk:513 +#, no-wrap +msgid "* Applied patch from Jane Random." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:516 +msgid "What was the patch about?" +msgstr "" + +# type: Content of: <chapter><section><section><screen> +#: best-pkging-practices.dbk:519 +#, no-wrap +msgid "* Late night install target overhaul." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:522 +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:526 +#, no-wrap +msgid "* Fix vsync FU w/ ancient CRTs." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:529 +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:533 +#, no-wrap +msgid "* This is not a bug, closes: #nnnnnn." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:536 +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:541 +#, 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:544 +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:551 +#, no-wrap +msgid "* Closes: #12345, #12346, #15432" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:554 +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:560 +msgid "Supplementing changelogs with NEWS.Debian files" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:562 +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:571 +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:579 +#, no-wrap +msgid "" +"(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:589 +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:595 +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:605 +msgid "Best practices for maintainer scripts" +msgstr "" + +# type: Content of: <chapter><section><para> +#: best-pkging-practices.dbk:607 +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=\"http://www.debian.org/doc/debian-policy/\">Debian Policy</ulink>." +msgstr "" + +# type: Content of: <chapter><section><para> +#: best-pkging-practices.dbk:615 +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:620 +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:624 +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:631 +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:638 +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:644 +msgid "" +"If you need to check for the existence of a command, you should use " +"something like" +msgstr "" + +# type: Content of: <chapter><section><screen> +#: best-pkging-practices.dbk:648 +#, no-wrap +msgid "[ -x /usr/sbin/install-docs ]; then ..." +msgstr "" + +# type: Content of: <chapter><section><para> +#: best-pkging-practices.dbk:651 +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><screen> +#: best-pkging-practices.dbk:655 +#, no-wrap +msgid "" +"() {\n" +" OLDIFS=$IFS\n" +" IFS=:\n" +" for p in $PATH; do\n" +" if [ -x $p/$* ]; then\n" +" IFS=$OLDIFS\n" +" return 0\n" +" fi\n" +" done\n" +" IFS=$OLDIFS\n" +" return 1\n" +"}" +msgstr "" + +# type: Content of: <chapter><section><para> +#: best-pkging-practices.dbk:669 +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:676 +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:686 +msgid "" +"Configuration management with <systemitem " +"role=\"package\">debconf</systemitem>" +msgstr "" + +# type: Content of: <chapter><section><para> +#: best-pkging-practices.dbk:688 +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:696 +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:703 +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:709 +msgid "Do not abuse debconf" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:711 +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:717 +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:723 +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:731 +msgid "General recommendations for authors and translators" +msgstr "" + +# type: Content of: <chapter><section><section><section><title> +#: best-pkging-practices.dbk:733 +msgid "Write correct English" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:735 +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:739 +msgid "" +"Please use (and abuse) <email>debian-l10n-english@lists.debian.org</email> " +"mailing list. Have your templates proofread." +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:743 +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:747 +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:755 +msgid "Be kind to translators" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:757 +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:762 +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:767 +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:776 +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:781 +msgid "" +"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@lists.debian.org</email> mailing list." +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:786 +msgid "" +"Calls for translations posted to <email>debian-i18n@lists.debian.org</email> " +"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:795 +msgid "Unfuzzy complete translations when correcting typos and spelling" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:797 +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:803 +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:807 +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:813 +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><screen> +#: best-pkging-practices.dbk:818 +#, no-wrap +msgid "" +"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:824 +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:831 +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:838 +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:844 +msgid "use the following command:" +msgstr "" + +# type: Content of: <chapter><section><section><section><orderedlist><listitem><screen> +#: best-pkging-practices.dbk:847 +#, no-wrap +msgid "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:852 +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:857 +msgid "run <command>debconf-updatepo</command> again" +msgstr "" + +# type: Content of: <chapter><section><section><section><title> +#: best-pkging-practices.dbk:864 +msgid "Do not make assumptions about interfaces" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:866 +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:871 +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:877 +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:883 +msgid "Do not use first person" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:885 +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:895 +msgid "Be gender neutral" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:897 +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:905 +msgid "Templates fields definition" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:907 +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:912 +msgid "Type" +msgstr "" + +# type: Content of: <chapter><section><section><section><section><title> +#: best-pkging-practices.dbk:914 +msgid "string:" +msgstr "" + +# type: Content of: <chapter><section><section><section><section><para> +#: best-pkging-practices.dbk:916 +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:921 +msgid "password:" +msgstr "" + +# type: Content of: <chapter><section><section><section><section><para> +#: best-pkging-practices.dbk:923 +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:930 +msgid "boolean:" +msgstr "" + +# type: Content of: <chapter><section><section><section><section><para> +#: best-pkging-practices.dbk:932 +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:938 +msgid "select:" +msgstr "" + +# type: Content of: <chapter><section><section><section><section><para> +#: best-pkging-practices.dbk:940 +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:947 +msgid "multiselect:" +msgstr "" + +# type: Content of: <chapter><section><section><section><section><para> +#: best-pkging-practices.dbk:949 +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:955 +msgid "note:" +msgstr "" + +# type: Content of: <chapter><section><section><section><section><para> +#: best-pkging-practices.dbk:957 +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:966 +msgid "text:" +msgstr "" + +# type: Content of: <chapter><section><section><section><section><para> +#: best-pkging-practices.dbk:968 +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:973 +msgid "error:" +msgstr "" + +# type: Content of: <chapter><section><section><section><section><para> +#: best-pkging-practices.dbk:975 +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:980 +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:988 +msgid "Description: short and extended description" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:990 +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:994 +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:1000 +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:1006 +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:1010 +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:1017 +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:1022 +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:1028 +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:1032 +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:1038 +msgid "Choices" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:1040 +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:1047 +msgid "Default" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:1049 +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:1058 +msgid "Templates fields specific style guide" +msgstr "" + +# type: Content of: <chapter><section><section><section><title> +#: best-pkging-practices.dbk:1060 +msgid "Type field" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:1062 +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:1068 +msgid "Description field" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:1070 +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:1074 +msgid "String/password templates" +msgstr "" + +# type: Content of: <chapter><section><section><section><section><itemizedlist><listitem><para> +#: best-pkging-practices.dbk:1078 +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:1085 +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:1095 +msgid "Boolean templates" +msgstr "" + +# type: Content of: <chapter><section><section><section><section><itemizedlist><listitem><para> +#: best-pkging-practices.dbk:1099 +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:1107 +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:1115 +msgid "Select/Multiselect" +msgstr "" + +# type: Content of: <chapter><section><section><section><section><itemizedlist><listitem><para> +#: best-pkging-practices.dbk:1119 +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:1127 +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:1137 +msgid "Notes" +msgstr "" + +# type: Content of: <chapter><section><section><section><section><itemizedlist><listitem><para> +#: best-pkging-practices.dbk:1141 +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:1146 +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:1152 +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:1167 +msgid "Choices field" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:1169 +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:1176 best-pkging-practices.dbk:1214 +msgid "Default field" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:1178 +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:1183 +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:1189 +msgid "Example, taken from the geneweb package templates:" +msgstr "" + +# type: Content of: <chapter><section><section><section><screen> +#: best-pkging-practices.dbk:1192 +#, no-wrap +msgid "" +": 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:1203 +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:1208 +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:1216 +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:1220 +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:1225 +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:1237 +msgid "Internationalization" +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: best-pkging-practices.dbk:1239 +msgid "Handling debconf translations" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:1241 +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:1247 +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:1257 +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:1273 +msgid "Internationalized documentation" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:1275 +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:1280 +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=\"http://cvs.debian.org/boot-floppies/documentation/doc-check?rev=HEAD\\|[amp " +"]\\|content-type=text/vnd.viewcvs-markup\">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:1295 +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:1305 +msgid "Common packaging situations" +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: best-pkging-practices.dbk:1307 +msgid "Packages using <command>autoconf</command>/<command>automake</command>" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:1309 +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 " +"<filename>/usr/share/doc/autotools-dev/README.Debian.gz</filename> 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:1321 +msgid "Libraries" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:1323 +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:1329 +msgid "" +"Good practices for library packaging have been grouped in <ulink " +"url=\"http://www.netfort.gr.jp/~dancer/column/libpkg-guide/\">the library " +"packaging guide</ulink>." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: best-pkging-practices.dbk:1336 +msgid "Documentation" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:1338 +msgid "" +"Be sure to follow the <ulink " +"url=\"http://www.debian.org/doc/debian-policy/ch-docs.html\">Policy on " +"documentation</ulink>." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:1343 +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:1348 +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:1355 +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:1363 +msgid "Specific types of packages" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:1365 +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:1371 +msgid "" +"Perl related packages have a <ulink " +"url=\"http://www.debian.org/doc/packaging-manuals/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:1380 +msgid "" +"Python related packages have their python policy; see " +"<filename>/usr/share/doc/python/python-policy.txt.gz</filename> in the " +"<systemitem role=\"package\">python</systemitem> package." +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: best-pkging-practices.dbk:1387 +msgid "" +"Emacs related packages have the <ulink " +"url=\"http://www.debian.org/doc/packaging-manuals/debian-emacs-policy\">emacs " +"policy</ulink>." +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: best-pkging-practices.dbk:1394 +msgid "" +"Java related packages have their <ulink " +"url=\"http://www.debian.org/doc/packaging-manuals/java-policy/\">java " +"policy</ulink>." +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: best-pkging-practices.dbk:1401 +msgid "" +"Ocaml related packages have their own policy, found in " +"<filename>/usr/share/doc/ocaml/ocaml_packaging_policy.gz</filename> 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:1409 +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:1415 +msgid "" +"Lisp packages should register themselves with <systemitem " +"role=\"package\">common-lisp-controller</systemitem>, about which see " +"<filename>/usr/share/doc/common-lisp-controller/README.packaging</filename>." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: best-pkging-practices.dbk:1424 +msgid "Architecture-independent data" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:1426 +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:1433 +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:1445 +msgid "Needing a certain locale during build" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:1447 +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:1451 +msgid "" +"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:" +msgstr "" + +# type: Content of: <chapter><section><section><screen> +#: best-pkging-practices.dbk:1456 +#, no-wrap +msgid "" +"=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:1469 +msgid "Make transition packages deborphan compliant" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:1471 +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:1478 +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:1484 +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:" +msgstr "" + +# type: Content of: <chapter><section><section><screen> +#: best-pkging-practices.dbk:1488 +#, no-wrap +msgid "-cache search .|grep dummy" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:1491 +msgid "or" +msgstr "" + +# type: Content of: <chapter><section><section><screen> +#: best-pkging-practices.dbk:1494 +#, no-wrap +msgid "-cache search .|grep transitional" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:1497 +msgid "." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: best-pkging-practices.dbk:1502 +msgid "Best practices for <filename>orig.tar.gz</filename> files" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:1504 +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:1508 +msgid "Pristine source" +msgstr "" + +# type: Content of: <chapter><section><section><section><para><footnote> +#: best-pkging-practices.dbk:1510 +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:1512 +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:1522 +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:1530 +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:1538 +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:1541 +#, no-wrap +msgid "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:1546 +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:1555 +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:1566 +msgid "Repackaged upstream source" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:1568 +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:1575 +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:1584 +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:1593 +msgid "A repackaged .orig.tar.gz" +msgstr "" + +# type: Content of: <chapter><section><section><section><orderedlist><listitem><para> +#: best-pkging-practices.dbk:1598 +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=\"http://www.debian.org/doc/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:1610 +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> +#: best-pkging-practices.dbk:1612 +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:1623 +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:1632 +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:1639 +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:1647 +msgid "" +"<emphasis role=\"strong\">should</emphasis> be gzipped with maximal " +"compression." +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:1652 +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:1658 +msgid "Changing binary files in <literal>diff.gz</literal>" +msgstr "" + +# type: Content of: <chapter><section><section><section><para><footnote> +#: best-pkging-practices.dbk:1660 +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:1667 +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><footnote><screen> +#: best-pkging-practices.dbk:1673 +#, no-wrap +msgid "" +"-file: perl -ne 'print(pack u, $$_);'\n" +"$(file) > $(file).uuencoded uudecode-file: perl -ne 'print(unpack u, " +"$$_);'\n" +"$(file).uuencoded > $(file)" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: best-pkging-practices.dbk:1675 +msgid "" +"</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:1680 +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:1693 +msgid "Best practices for debug packages" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: best-pkging-practices.dbk:1695 +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:1703 +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:1713 +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:1725 +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:1732 +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:1739 +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:1743 +#, no-wrap +msgid ": libfoo-dbg (= ${binary:Version})" +msgstr "" diff --git a/po4a/po/beyond-pkging.pot b/po4a/po/beyond-pkging.pot new file mode 100644 index 0000000..586c3ca --- /dev/null +++ b/po4a/po/beyond-pkging.pot @@ -0,0 +1,572 @@ +# 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-06-26 16:13+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:5 +msgid "Beyond Packaging" +msgstr "" + +# type: Content of: <chapter><para> +#: beyond-pkging.dbk:7 +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:12 +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:17 +msgid "Bug reporting" +msgstr "" + +# type: Content of: <chapter><section><para> +#: beyond-pkging.dbk:19 +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:24 +msgid "" +"Read the <ulink url=\"http://www.debian.org/Bugs/Reporting\">instructions " +"for reporting bugs</ulink> in the Debian <ulink " +"url=\"http://www.debian.org/Bugs/\">bug tracking system</ulink>." +msgstr "" + +# type: Content of: <chapter><section><para> +#: beyond-pkging.dbk:29 +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:34 +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:39 +msgid "" +"Make sure the bug is not already filed against a package. Each package has " +"a bug list easily reachable at " +"<literal>http://bugs.debian.org/<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:48 +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:54 +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:61 +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.debian.org/from:<replaceable><your-email-addr></replaceable></literal>." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: beyond-pkging.dbk:68 +msgid "Reporting lots of bugs at once (mass bug filing)" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: beyond-pkging.dbk:70 +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:77 +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@lists.debian.org</email> " +"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:85 +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@lists.debian.org</email>." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: beyond-pkging.dbk:91 +msgid "" +"Note that when sending lots of bugs on the same subject, you should send the " +"bug report to <email>maintonly@bugs.debian.org</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:100 +msgid "Quality Assurance effort" +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: beyond-pkging.dbk:102 +msgid "Daily work" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: beyond-pkging.dbk:104 +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@lists.debian.org</email> or " +"<email>debian-devel@lists.debian.org</email>). 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:118 +msgid "Bug squashing parties" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: beyond-pkging.dbk:120 +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@lists.debian.org</email> 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:129 +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:138 +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:145 +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:153 +msgid "Contacting other maintainers" +msgstr "" + +# type: Content of: <chapter><section><para> +#: beyond-pkging.dbk:155 +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:161 +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.debian.org</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:169 +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>@packages.qa.debian.org</literal> " +"email address." +msgstr "" + +# type: Content of: <chapter><section><title> +#: beyond-pkging.dbk:177 +msgid "Dealing with inactive and/or unreachable maintainers" +msgstr "" + +# type: Content of: <chapter><section><para> +#: beyond-pkging.dbk:179 +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:186 +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" +msgstr "" + +# type: Content of: <chapter><section><screen> +#: beyond-pkging.dbk:194 +#, no-wrap +msgid "-query --help" +msgstr "" + +# type: Content of: <chapter><section><para> +#: beyond-pkging.dbk:197 +msgid "" +"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:202 +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:208 +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:216 +msgid "" +"The echelon information available through the <ulink " +"url=\"https://db.debian.org/\">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:225 +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:234 +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:241 +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:249 +msgid "" +"It is also allowed to post a query to " +"<email>debian-devel@lists.debian.org</email>, 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:254 +msgid "" +"Once you have gathered all of this, you can contact " +"<email>mia@qa.debian.org</email>. 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:262 +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:270 +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:276 +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@qa.debian.org</email>." +msgstr "" + +# type: Content of: <chapter><section><title> +#: beyond-pkging.dbk:284 +msgid "Interacting with prospective Debian developers" +msgstr "" + +# type: Content of: <chapter><section><para> +#: beyond-pkging.dbk:286 +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:292 +msgid "Sponsoring packages" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: beyond-pkging.dbk:294 +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:299 +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:306 +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:313 +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:320 +msgid "Managing sponsored packages" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: beyond-pkging.dbk:322 +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:327 +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:336 +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:341 +msgid "Once the package meets Debian standards, build and sign it with" +msgstr "" + +# type: Content of: <chapter><section><section><screen> +#: beyond-pkging.dbk:344 +#, no-wrap +msgid "-buildpackage -k<replaceable>KEY-ID</replaceable>" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: beyond-pkging.dbk:347 +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:352 +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:358 +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:362 +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:368 +msgid "Advocating new developers" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: beyond-pkging.dbk:370 +msgid "" +"See the page about <ulink " +"url=\"http://www.debian.org/devel/join/nm-advocate\">advocating a " +"prospective developer</ulink> at the Debian web site." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: beyond-pkging.dbk:377 +msgid "Handling new maintainer applications" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: beyond-pkging.dbk:379 +msgid "" +"Please see <ulink " +"url=\"http://www.debian.org/devel/join/nm-amchecklist\">Checklist for " +"Application Managers</ulink> at the Debian web site." +msgstr "" diff --git a/po4a/po/developer-duties.pot b/po4a/po/developer-duties.pot new file mode 100644 index 0000000..487ca81 --- /dev/null +++ b/po4a/po/developer-duties.pot @@ -0,0 +1,314 @@ +# 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-06-26 16:13+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:5 +msgid "Debian Developer's Duties" +msgstr "" + +# type: Content of: <chapter><section><title> +#: developer-duties.dbk:7 +msgid "Maintaining your Debian information" +msgstr "" + +# type: Content of: <chapter><section><para> +#: developer-duties.dbk:9 +msgid "" +"There's a LDAP database containing information about Debian developers at " +"<ulink url=\"https://db.debian.org/\"></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:17 +msgid "" +"For more information about the database, please see <xref " +"linkend=\"devel-db\"/> ." +msgstr "" + +# type: Content of: <chapter><section><title> +#: developer-duties.dbk:23 +msgid "Maintaining your public key" +msgstr "" + +# type: Content of: <chapter><section><para> +#: developer-duties.dbk:25 +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=\"http://www.cam.ac.uk.pgp.net/pgpnet/pgp-faq/\">PGP FAQ</ulink>." +msgstr "" + +# type: Content of: <chapter><section><para> +#: developer-duties.dbk:32 +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:38 +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>keyring.debian.org</literal>." +msgstr "" + +# type: Content of: <chapter><section><para> +#: developer-duties.dbk:43 +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://keyring.debian.org/replacing_keys.html\"></ulink>." +msgstr "" + +# type: Content of: <chapter><section><para> +#: developer-duties.dbk:51 +msgid "" +"The same key extraction routines discussed in <xref " +"linkend=\"registering\"/> apply." +msgstr "" + +# type: Content of: <chapter><section><para> +#: developer-duties.dbk:55 +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:62 +msgid "Voting" +msgstr "" + +# type: Content of: <chapter><section><para> +#: developer-duties.dbk:64 +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=\"http://www.debian.org/devel/constitution\">Debian " +"Constitution</ulink>." +msgstr "" + +# type: Content of: <chapter><section><para> +#: developer-duties.dbk:70 +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@lists.debian.org</email> 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:76 +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@lists.debian.org</email> (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:84 +msgid "" +"The list of all proposals (past and current) is available on the <ulink " +"url=\"http://www.debian.org/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:91 +msgid "Going on vacation gracefully" +msgstr "" + +# type: Content of: <chapter><section><para> +#: developer-duties.dbk:93 +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:100 +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:107 +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.debian.org</email> with [VAC] prepended to the " +"subject of your message<footnote>" +msgstr "" + +# type: Content of: <chapter><section><para><footnote><para> +#: developer-duties.dbk:109 +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:111 +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:116 +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:122 +msgid "" +"Ideally, you should sign up at the <ulink " +"url=\"http://nm.debian.org/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:131 +msgid "Coordination with upstream developers" +msgstr "" + +# type: Content of: <chapter><section><para> +#: developer-duties.dbk:133 +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:140 +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:147 +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:156 +msgid "Managing release-critical bugs" +msgstr "" + +# type: Content of: <chapter><section><para> +#: developer-duties.dbk:158 +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:169 +msgid "" +"Developers who are part of the <ulink url=\"http://qa.debian.org/\">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.debian.org</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:184 +msgid "Retiring" +msgstr "" + +# type: Content of: <chapter><section><para> +#: developer-duties.dbk:186 +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:192 +msgid "Orphan all your packages, as described in <xref linkend=\"orphaning\"/> ." +msgstr "" + +# type: Content of: <chapter><section><orderedlist><listitem><para> +#: developer-duties.dbk:197 +msgid "" +"Send an gpg-signed email about why you are leaving the project to " +"<email>debian-private@lists.debian.org</email>." +msgstr "" + +# type: Content of: <chapter><section><orderedlist><listitem><para> +#: developer-duties.dbk:203 +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 "" diff --git a/po4a/po/index.pot b/po4a/po/index.pot new file mode 100644 index 0000000..b328a2e --- /dev/null +++ b/po4a/po/index.pot @@ -0,0 +1,87 @@ +# 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-06-26 16:13+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:4 +msgid "en" +msgstr "" + +# type: Content of: <book><title> +#: index.dbk:6 +msgid "Debian Developer's Reference" +msgstr "" + +# type: Content of: <book><bookinfo><releaseinfo> +#: index.dbk:27 +msgid "ver. 3.3.9, 16 June, 2007" +msgstr "" + +# type: Content of: <book><bookinfo><copyright><holder> +#: index.dbk:34 +msgid "Andreas Barth" +msgstr "" + +# type: Content of: <book><bookinfo><copyright><holder> +#: index.dbk:43 +msgid "Adam Di Carlo" +msgstr "" + +# type: Content of: <book><bookinfo><copyright><holder> +#: index.dbk:48 +msgid "Raphaël Hertzog" +msgstr "" + +# type: Content of: <book><bookinfo><copyright><holder> +#: index.dbk:53 +msgid "Christian Schwarz" +msgstr "" + +# type: Content of: <book><bookinfo><legalnotice><para> +#: index.dbk:57 +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:62 +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:68 +msgid "" +"A copy of the GNU General Public License is available as " +"<filename>/usr/share/common-licenses/GPL</filename> in the Debian GNU/Linux " +"distribution or on the World Wide Web at <ulink " +"url=\"http://www.gnu.org/copyleft/gpl.html\">the GNU web site</ulink>. You " +"can also obtain it by writing to the Free Software Foundation, Inc., 51 " +"Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA." +msgstr "" + +# type: Content of: <book><bookinfo><legalnotice><para> +#: index.dbk:76 +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 "" diff --git a/po4a/po/l10n.pot b/po4a/po/l10n.pot new file mode 100644 index 0000000..d09b196 --- /dev/null +++ b/po4a/po/l10n.pot @@ -0,0 +1,342 @@ +# 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-06-26 16:13+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:5 +msgid "" +"Internationalizing, translating, being internationalized and being " +"translated" +msgstr "" + +# type: Content of: <chapter><para> +#: l10n.dbk:7 +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:15 +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:24 +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:32 +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:38 +msgid "How translations are handled within Debian" +msgstr "" + +# type: Content of: <chapter><section><para> +#: l10n.dbk:40 +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:44 +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:57 +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:64 +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:72 +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:76 +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:81 +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:85 +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:89 +msgid "" +"There is an effort to handle Debian-specific man pages within a <ulink " +"url=\"http://cvs.debian.org/manpages/?cvsroot=debian-doc\">specific CVS " +"repository</ulink>." +msgstr "" + +# type: Content of: <chapter><section><title> +#: l10n.dbk:96 +msgid "I18N & L10N FAQ for maintainers" +msgstr "" + +# type: Content of: <chapter><section><para> +#: l10n.dbk:98 +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:105 +msgid "How to get a given text translated" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: l10n.dbk:107 +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:112 +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:122 +msgid "How to get a given translation reviewed" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: l10n.dbk:124 +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:134 +msgid "How to get a given translation updated" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: l10n.dbk:136 +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:142 +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:148 +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:155 +msgid "How to handle a bug report concerning a translation" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: l10n.dbk:157 +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:166 +msgid "I18N & L10N FAQ for translators" +msgstr "" + +# type: Content of: <chapter><section><para> +#: l10n.dbk:168 +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:173 +msgid "How to help the translation effort" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: l10n.dbk:175 +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:183 +msgid "How to provide a translation for inclusion in a package" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: l10n.dbk:185 +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:191 +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:201 +msgid "Best current practice concerning l10n" +msgstr "" + +# type: Content of: <chapter><section><itemizedlist><listitem><para> +#: l10n.dbk:205 +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:213 +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:220 +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:230 +msgid "" +"In any case, cooperation can only be achieved with <emphasis " +"role=\"strong\">mutual respect</emphasis>." +msgstr "" diff --git a/po4a/po/new-maintainer.pot b/po4a/po/new-maintainer.pot new file mode 100644 index 0000000..a48fcef --- /dev/null +++ b/po4a/po/new-maintainer.pot @@ -0,0 +1,333 @@ +# 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-06-26 16:13+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:5 +msgid "Applying to Become a Maintainer" +msgstr "" + +# type: Content of: <chapter><section><title> +#: new-maintainer.dbk:7 +msgid "Getting started" +msgstr "" + +# type: Content of: <chapter><section><para> +#: new-maintainer.dbk:9 +msgid "" +"So, you've read all the documentation, you've gone through the <ulink " +"url=\"http://www.debian.org/doc/maint-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:17 +msgid "" +"Firstly, subscribe to <email>debian-devel@lists.debian.org</email> if you " +"haven't already. Send the word <literal>subscribe</literal> in the " +"<emphasis>Subject</emphasis> of an email to " +"<email>debian-devel-REQUEST@lists.debian.org</email>. In case of problems, " +"contact the list administrator at " +"<email>listmaster@lists.debian.org</email>. More information on available " +"mailing lists can be found in <xref linkend=\"mailing-lists\"/> . " +"<email>debian-devel-announce@lists.debian.org</email> 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:28 +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:33 +msgid "" +"Another good list to subscribe to is " +"<email>debian-mentors@lists.debian.org</email>. 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:39 +msgid "" +"When you know how you want to contribute to Debian GNU/Linux, 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@lists.debian.org</email> mailing list, describing your " +"package and yourself and asking for a sponsor (see <xref " +"linkend=\"sponsoring\"/> and <ulink " +"url=\"http://people.debian.org/~mpalmer/debian-mentors_FAQ.html\"></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=\"http://www.debian.org/MailingLists/\"></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@lists.debian.org</email> 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> +#: 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=\"http://people.debian.org/~mpalmer/debian-mentors_FAQ.html\"></ulink> " +"first." +msgstr "" + +# type: Content of: <chapter><section><para> +#: new-maintainer.dbk:84 +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:90 +msgid "Registering as a Debian developer" +msgstr "" + +# type: Content of: <chapter><section><para> +#: new-maintainer.dbk:92 +msgid "" +"Before you decide to register with Debian GNU/Linux, you will need to read " +"all the information available at the <ulink " +"url=\"http://www.debian.org/devel/join/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=\"http://www.debian.org/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 GNU/Linux. " +"Reading the <ulink url=\"http://www.gnu.org/gnu/manifesto.html\">GNU " +"Manifesto</ulink> would also be a good idea." +msgstr "" + +# type: Content of: <chapter><section><para> +#: new-maintainer.dbk:105 +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 GNU/Linux has grown to over 900 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:113 +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:122 +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=\"http://nm.debian.org/gpg.php\">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=\"http://www.debian.org/devel/join/nm-step2\">identification " +"page</ulink> for more information.)" +msgstr "" + +# type: Content of: <chapter><section><para> +#: new-maintainer.dbk:135 +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:143 +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=\"http://www.rfc-editor.org/rfc/rfc2440.txt\">RFC 2440</ulink>." +msgstr "" + +# type: Content of: <chapter><section><para><footnote> +#: new-maintainer.dbk:150 +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:152 +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:156 +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:160 +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 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 " +"<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:167 +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:169 +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:175 +msgid "" +"If your public key isn't on a public key server such as " +"<literal>subkeys.pgp.net</literal>, please read the documentation available " +"at <ulink url=\"http://www.debian.org/devel/join/nm-step2\">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:183 +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:191 +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:198 +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=\"http://nm.debian.org/newnm.php\">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=\"http://nm.debian.org/\">applications status board</ulink>." +msgstr "" + +# type: Content of: <chapter><section><para> +#: new-maintainer.dbk:208 +msgid "" +"For more details, please consult <ulink " +"url=\"http://www.debian.org/devel/join/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 "" diff --git a/po4a/po/pkgs.pot b/po4a/po/pkgs.pot new file mode 100644 index 0000000..994e65d --- /dev/null +++ b/po4a/po/pkgs.pot @@ -0,0 +1,3519 @@ +# 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-06-26 16:13+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:5 +msgid "Managing Packages" +msgstr "" + +# type: Content of: <chapter><para> +#: pkgs.dbk:7 +msgid "" +"This chapter contains information related to creating, uploading, " +"maintaining, and porting packages." +msgstr "" + +# type: Content of: <chapter><section><title> +#: pkgs.dbk:11 +msgid "New packages" +msgstr "" + +# type: Content of: <chapter><section><para> +#: pkgs.dbk:13 +msgid "" +"If you want to create a new package for the Debian distribution, you should " +"first check the <ulink " +"url=\"http://www.debian.org/devel/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=\"http://www.debian.org/devel/wnpp/\">WNPP " +"web pages</ulink> for more information." +msgstr "" + +# type: Content of: <chapter><section><para> +#: pkgs.dbk:21 +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:29 +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@lists.debian.org</email> 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:39 +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:45 +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:53 +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:59 +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:65 +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:71 +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:78 +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:84 +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:90 +msgid "" +"Please see <ulink " +"url=\"http://ftp-master.debian.org/REJECT-FAQ.html\"></ulink> for common " +"rejection reasons for a new package." +msgstr "" + +# type: Content of: <chapter><section><title> +#: pkgs.dbk:96 +msgid "Recording changes in the package" +msgstr "" + +# type: Content of: <chapter><section><para> +#: pkgs.dbk:98 +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:109 +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:117 +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:121 +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:125 +#, no-wrap +msgid "* new upstream version" +msgstr "" + +# type: Content of: <chapter><section><para> +#: pkgs.dbk:128 +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:133 +msgid "See also <xref linkend=\"bpp-debian-changelog\"/> ." +msgstr "" + +# type: Content of: <chapter><section><title> +#: pkgs.dbk:138 +msgid "Testing the package" +msgstr "" + +# type: Content of: <chapter><section><para> +#: pkgs.dbk:140 +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:147 +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:154 +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:163 +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:167 +msgid "" +"For more information on <command>lintian</command>, see <xref " +"linkend=\"lintian\"/> ." +msgstr "" + +# type: Content of: <chapter><section><itemizedlist><listitem><para> +#: pkgs.dbk:173 +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:179 +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:185 +msgid "Remove the package, then reinstall it." +msgstr "" + +# type: Content of: <chapter><section><itemizedlist><listitem><para> +#: pkgs.dbk:190 +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:200 +msgid "Layout of the source package" +msgstr "" + +# type: Content of: <chapter><section><para> +#: pkgs.dbk:202 +msgid "There are two types of Debian source packages:" +msgstr "" + +# type: Content of: <chapter><section><itemizedlist><listitem><para> +#: pkgs.dbk:207 +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:213 +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:219 +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:227 +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:233 +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:240 +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:248 +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:255 +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:262 +msgid "Picking a distribution" +msgstr "" + +# type: Content of: <chapter><section><para> +#: pkgs.dbk:264 +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:270 +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:275 +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:280 +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:284 +msgid "Special case: uploads to the <emphasis>stable</emphasis> distribution" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:286 +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:294 +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:301 +msgid "a truly critical functionality problem" +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: pkgs.dbk:306 +msgid "the package becomes uninstallable" +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: pkgs.dbk:311 +msgid "a released architecture lacks the package" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:316 +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:324 +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:328 +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:338 +msgid "" +"The Release Team (which can be reached at " +"<email>debian-release@lists.debian.org</email>) 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:347 +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:355 +msgid "" +"Special case: uploads to " +"<emphasis>testing/testing-proposed-updates</emphasis>" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:357 +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:365 +msgid "Uploading a package" +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: pkgs.dbk:367 +msgid "Uploading to <literal>ftp-master</literal>" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:369 +msgid "" +"To upload a package, you should upload the files (including the signed " +"changes and dsc-file) with anonymous ftp to " +"<literal>ftp-master.debian.org</literal> in the directory <ulink " +"url=\"ftp://ftp-master.debian.org/pub/UploadQueue/\">/pub/UploadQueue/</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:377 +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:382 +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:387 +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:393 +msgid "Uploading to <literal>non-US</literal>" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:395 +msgid "" +"<emphasis>Note:</emphasis> non-us was discontinued with the release of " +"sarge." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: pkgs.dbk:400 +msgid "Delayed uploads" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:402 +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:407 +msgid "With a fairly recent dput, this section" +msgstr "" + +# type: Content of: <chapter><section><section><screen> +#: pkgs.dbk:410 +#, 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:416 +msgid "in ~/.dput.cf should work fine for uploading to the DELAYED queue." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:419 +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:426 +msgid "Security uploads" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:428 +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:438 +msgid "Other upload queues" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:440 +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:444 +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:448 +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:454 +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:461 +msgid "Notification that a new package has been installed" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:463 +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:472 +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:478 +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:483 +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:491 +msgid "Specifying the package section, subsection and priority" +msgstr "" + +# type: Content of: <chapter><section><para> +#: pkgs.dbk:493 +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:501 +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:511 +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-change@debian.org</email> 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:519 +msgid "" +"For more information about <emphasis>override files</emphasis>, see " +"<citerefentry> <refentrytitle>dpkg-scanpackages</refentrytitle> " +"<manvolnum>1</manvolnum> </citerefentry> and <ulink " +"url=\"http://www.debian.org/Bugs/Developer#maintincorrect\"></ulink>." +msgstr "" + +# type: Content of: <chapter><section><para> +#: pkgs.dbk:525 +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=\"http://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections\"></ulink>." +msgstr "" + +# type: Content of: <chapter><section><title> +#: pkgs.dbk:534 +msgid "Handling bugs" +msgstr "" + +# type: Content of: <chapter><section><para> +#: pkgs.dbk:536 +msgid "" +"Every developer has to be able to work with the Debian <ulink " +"url=\"http://www.debian.org/Bugs/\">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:542 +msgid "" +"The bug tracking system's features are described in the <ulink " +"url=\"http://www.debian.org/Bugs/Developer\">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:548 +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=\"http://www.debian.org/Bugs/server-control\">BTS control server " +"documentation</ulink>." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: pkgs.dbk:556 +msgid "Monitoring bugs" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:558 +msgid "" +"If you want to be a good maintainer, you should periodically check the " +"<ulink url=\"http://www.debian.org/Bugs/\">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.debian.org/<replaceable>yourlogin</replaceable>@debian.org</literal>." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:565 +msgid "" +"Maintainers interact with the BTS via email addresses at " +"<literal>bugs.debian.org</literal>. Documentation on available commands can " +"be found at <ulink url=\"http://www.debian.org/Bugs/\"></ulink>, or, if you " +"have installed the <systemitem role=\"package\">doc-debian</systemitem> " +"package, you can look at the local files " +"<filename>/usr/share/doc/debian/bug-*</filename>." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:572 +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:577 +#, no-wrap +msgid "" +"# ask for weekly reports of bugs in my packages\n" +"0 17 * * fri echo index maint <replaceable>address</replaceable> | mail " +"request@bugs.debian.org" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:581 +msgid "" +"Replace <replaceable>address</replaceable> with your official Debian " +"maintainer address." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: pkgs.dbk:587 +msgid "Responding to bugs" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:589 +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.debian.org</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.debian.org</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.debian.org</email>)." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:598 +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:602 +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.debian.org</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:609 +msgid "" +"You should <emphasis>never</emphasis> close bugs via the bug server " +"<literal>close</literal> command sent to " +"<email>control@bugs.debian.org</email>. 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:617 +msgid "Bug housekeeping" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:619 +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=\"http://www.debian.org/Bugs/Developer\">BTS documentation for Debian " +"developers</ulink>. Operations such as reassigning, merging, and tagging " +"bug reports are described in the <ulink " +"url=\"http://www.debian.org/Bugs/server-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:630 +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:635 +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:640 +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:650 +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=\"http://www.debian.org/devel/tech-ctte\">recommended procedure</ulink>." +msgstr "" + +# type: Content of: <chapter><section><section><orderedlist><listitem><para> +#: pkgs.dbk:664 +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@lists.debian.org</email>. 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:672 +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:680 +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:691 +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:702 +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@lists.debian.org</email> or " +"<email>debian-qa@lists.debian.org</email>. 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:716 +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:726 +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:735 +msgid "When bugs are closed by new uploads" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:737 +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:745 +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:751 +#, no-wrap +msgid "" +"-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:759 +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:763 +#, no-wrap +msgid "/closes:\\s*(?:bug)?\\#\\s*\\d+(?:,\\s*(?:bug)?\\#\\s*\\d+)*/ig" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:766 +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:775 +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:781 +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>control@bugs.debian.org</email>. To close " +"any remaining bugs that were fixed by your upload, email the " +"<filename>.changes</filename> file to " +"<email>XXX-done@bugs.debian.org</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:793 +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.debian.org</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:801 +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:807 +msgid "Handling security-related bugs" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:809 +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:816 +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>team@security.debian.org</email> 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:826 +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:833 +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:838 +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:845 +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:851 +msgid "" +"Any information needed for the advisory (see <xref " +"linkend=\"bug-security-advisories\"/> )" +msgstr "" + +# type: Content of: <chapter><section><section><section><title> +#: pkgs.dbk:857 +msgid "Confidentiality" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:859 +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:866 +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:871 +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:876 +msgid "someone files a bug report" +msgstr "" + +# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> +#: pkgs.dbk:881 +msgid "someone informs them via private email" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:886 +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:894 +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:900 +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:907 +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:914 +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:920 +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:927 +msgid "Security Advisories" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:929 +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@lists.debian.org</email> mailing list and " +"posted on <ulink url=\"http://www.debian.org/security/\">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:942 +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:947 +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:952 +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:957 +msgid "How it can be exploited" +msgstr "" + +# type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para> +#: pkgs.dbk:962 +msgid "Whether it is remotely or locally exploitable" +msgstr "" + +# type: Content of: <chapter><section><section><section><itemizedlist><listitem><itemizedlist><listitem><para> +#: pkgs.dbk:967 +msgid "How the problem was fixed" +msgstr "" + +# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> +#: pkgs.dbk:972 +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:977 +msgid "Version numbers of affected packages" +msgstr "" + +# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> +#: pkgs.dbk:982 +msgid "Version numbers of fixed packages" +msgstr "" + +# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> +#: pkgs.dbk:987 +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:993 +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:1002 +msgid "Preparing packages to address security issues" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:1004 +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:1009 +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:1017 +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:1023 +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:1030 +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:1037 +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:1047 +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:1055 +msgid "Be sure to verify the following items:" +msgstr "" + +# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> +#: pkgs.dbk:1060 +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:1070 +msgid "The upload should have urgency=high." +msgstr "" + +# type: Content of: <chapter><section><section><section><itemizedlist><listitem><para> +#: pkgs.dbk:1075 +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:1087 +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:1099 +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:1108 +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:1117 +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:1124 +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:1135 +msgid "Uploading the fixed package" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:1137 +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:1144 +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:1153 +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:1159 +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:1164 +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:1169 +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:1180 +msgid "Moving, removing, renaming, adopting, and orphaning packages" +msgstr "" + +# type: Content of: <chapter><section><para> +#: pkgs.dbk:1182 +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:1187 +msgid "Moving packages" +msgstr "" + +# type: Content of: <chapter><section><section><para><footnote> +#: pkgs.dbk:1189 +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:1191 +msgid "" +"See the <ulink url=\"http://www.debian.org/doc/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:1196 +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=\"http://www.debian.org/doc/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:1208 +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:1217 +msgid "Removing packages" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:1219 +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:1232 +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:1241 +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:1247 +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:1252 +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=\"http://qa.debian.org/howto-remove.html\"></ulink>." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:1257 +msgid "" +"If in doubt concerning whether a package is disposable, email " +"<email>debian-devel@lists.debian.org</email> 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@lists.debian.org</email>." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:1268 +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:1275 +msgid "Removing packages from <filename>Incoming</filename>" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:1277 +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:1292 +msgid "Replacing or renaming packages" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:1294 +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=\"http://www.debian.org/doc/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:1304 +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:1318 +msgid "Orphaning a package" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:1320 +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 " +"<packages@qa.debian.org></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@lists.debian.org</email> 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:1335 +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:1343 +msgid "" +"More information is on the <ulink " +"url=\"http://www.debian.org/devel/wnpp/\">WNPP web pages</ulink>." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: pkgs.dbk:1349 +msgid "Adopting a package" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:1351 +msgid "" +"A list of packages in need of a new maintainer is available in the <ulink " +"url=\"http://www.debian.org/devel/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:1358 +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:1364 +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=\"http://www.debian.org/devel/tech-ctte\">technical committee web " +"page</ulink> for more information)." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:1374 +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:1388 +msgid "Porting and being ported" +msgstr "" + +# type: Content of: <chapter><section><para> +#: pkgs.dbk:1390 +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:1396 +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 12 more builds." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: pkgs.dbk:1404 +msgid "Being kind to porters" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:1406 +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:1414 +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:1421 +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:1428 +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:1442 +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:1446 +msgid "" +"See the <ulink url=\"http://www.debian.org/doc/debian-policy/\">Debian " +"Policy Manual</ulink> for instructions on setting build dependencies." +msgstr "" + +# type: Content of: <chapter><section><section><orderedlist><listitem><para> +#: pkgs.dbk:1452 +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=\"http://www.debian.org/doc/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:1460 +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:1468 +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:1476 +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:1485 +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:1491 +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:1499 +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:1510 +msgid "Guidelines for porter uploads" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:1512 +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:1520 +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:1525 +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:1533 +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:1540 +msgid "Recompilation or binary-only NMU" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:1542 +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:1551 +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:1557 +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:1562 +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:1569 +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:1574 +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:1582 +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:1589 +msgid "When to do a source NMU if you are a porter" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:1591 +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:1600 +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:1611 +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:1619 +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:1627 +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:1637 +msgid "Porting infrastructure and automation" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:1639 +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:1644 +msgid "Mailing lists and web pages" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:1646 +msgid "" +"Web pages containing the status of each port can be found at <ulink " +"url=\"http://www.debian.org/ports/\"></ulink>." +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:1650 +msgid "" +"Each port of Debian has a mailing list. The list of porting mailing lists " +"can be found at <ulink url=\"http://lists.debian.org/ports.html\"></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:1658 +msgid "Porter tools" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:1660 +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:1668 +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:1677 +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:1687 +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=\"http://buildd.debian.org/\"></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:1695 +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:1702 +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:1710 +msgid "When your package is <emphasis>not</emphasis> portable" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:1712 +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:1719 +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:1725 +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:1733 +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:1741 +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=\"http://cvs.debian.org/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:1751 +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:1764 +msgid "Non-Maintainer Uploads (NMUs)" +msgstr "" + +# type: Content of: <chapter><section><para> +#: pkgs.dbk:1766 +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:1771 +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:1778 +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:1783 +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:1792 +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:1797 +msgid "How to do a NMU" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:1799 +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:1805 +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:1811 +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:1817 +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:1824 +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:1831 +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:1841 +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:1849 +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:1856 +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:1865 +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:1870 +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:1876 +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:1881 +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:1885 +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:1892 +msgid "NMU version numbering" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:1894 +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:1898 +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:1909 +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:1915 +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:1925 +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:1932 +msgid "Source NMUs must have a new changelog entry" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:1934 +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:1940 +msgid "By convention, source NMU changelog entries start with the line" +msgstr "" + +# type: Content of: <chapter><section><section><screen> +#: pkgs.dbk:1943 +#, no-wrap +msgid "* Non-maintainer upload" +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: pkgs.dbk:1948 +msgid "Source NMUs and the Bug Tracking System" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:1950 +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:1956 +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:1963 +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:1968 +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:1979 +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:1987 +msgid "Building source NMUs" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:1989 +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:1994 +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:2002 +msgid "Acknowledging an NMU" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:2004 +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:2015 +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:2025 +msgid "NMU vs QA uploads" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:2027 +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=\"http://qa.debian.org/orphaned.html\"></ulink>. If you perform " +"an NMU on an improperly orphaned package, please set the maintainer to " +"``Debian QA Group <packages@qa.debian.org>''." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: pkgs.dbk:2037 +msgid "Who can do an NMU" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:2039 +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:2049 +msgid "Terminology" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:2051 +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:2059 +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:2068 +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:2078 +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:2088 +msgid "Collaborative maintenance" +msgstr "" + +# type: Content of: <chapter><section><para> +#: pkgs.dbk:2090 +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:2098 +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:2104 +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:2110 +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:2118 +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:2123 +#, no-wrap +msgid ": John Buzz <jbuzz@debian.org>, Adam Rex <arex@debian.org>" +msgstr "" + +# type: Content of: <chapter><section><itemizedlist><listitem><para> +#: pkgs.dbk:2128 +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:2134 +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:2143 +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:2150 +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:2158 +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:2166 +msgid "The testing distribution" +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: pkgs.dbk:2168 +msgid "Basics" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:2170 +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:2174 +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:2183 +msgid "Updates from unstable" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:2185 +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:2193 +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:2199 +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:2208 +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:2214 +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:2221 +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:2227 +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:2235 +msgid "" +"To find out whether a package is progressing into testing or not, see the " +"testing script output on the <ulink " +"url=\"http://www.debian.org/devel/testing\">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:2246 +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=\"http://www.debian.org/devel/testing\">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:2253 +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:2258 +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:2263 +msgid "out-of-date" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:2265 +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:2272 +msgid "Consider this example:" +msgstr "" + +# type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry> +#: pkgs.dbk:2279 pkgs.dbk:2310 +msgid "alpha" +msgstr "" + +# type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry> +#: pkgs.dbk:2280 pkgs.dbk:2311 +msgid "arm" +msgstr "" + +# type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry> +#: pkgs.dbk:2285 pkgs.dbk:2317 pkgs.dbk:2377 +msgid "testing" +msgstr "" + +# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry> +#: pkgs.dbk:2286 pkgs.dbk:2291 pkgs.dbk:2318 pkgs.dbk:2319 pkgs.dbk:2326 +msgid "1" +msgstr "" + +# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry> +#: pkgs.dbk:2287 pkgs.dbk:2320 pkgs.dbk:2325 +msgid "-" +msgstr "" + +# type: Content of: <chapter><section><section><section><informaltable><tgroup><thead><row><entry> +#: pkgs.dbk:2290 pkgs.dbk:2323 pkgs.dbk:2378 +msgid "unstable" +msgstr "" + +# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry> +#: pkgs.dbk:2292 pkgs.dbk:2324 +msgid "2" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:2298 +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:2303 +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:2312 +msgid "hurd-i386" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:2332 +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:2337 +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:2344 +msgid "Removals from testing" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:2346 +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:2353 +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:2357 +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:2363 +msgid "circular dependencies" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:2365 +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:2370 +msgid "An example of this is:" +msgstr "" + +# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry> +#: pkgs.dbk:2383 +msgid "a" +msgstr "" + +# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry> +#: pkgs.dbk:2384 +msgid "1; depends: b=1" +msgstr "" + +# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry> +#: pkgs.dbk:2385 +msgid "2; depends: b=2" +msgstr "" + +# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry> +#: pkgs.dbk:2388 +msgid "b" +msgstr "" + +# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry> +#: pkgs.dbk:2389 +msgid "1; depends: a=1" +msgstr "" + +# type: Content of: <chapter><section><section><section><informaltable><tgroup><tbody><row><entry> +#: pkgs.dbk:2390 +msgid "2; depends: a=2" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:2396 +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:2400 +msgid "" +"Currently, this requires some manual hinting from the release team. Please " +"contact them by sending mail to " +"<email>debian-release@lists.debian.org</email> if this happens to one of " +"your packages." +msgstr "" + +# type: Content of: <chapter><section><section><section><title> +#: pkgs.dbk:2407 +msgid "influence of package in testing" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:2409 +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:2419 +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:2426 +msgid "details" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:2428 +msgid "If you are interested in details, this is how britney works:" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:2431 +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:2440 +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:2448 +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.debian.org/testing/update_out_code/\"></ulink>" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:2455 +msgid "" +"The hints are available via <ulink " +"url=\"http://ftp-master.debian.org/testing/hints/\"></ulink>." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: pkgs.dbk:2463 +msgid "Direct updates to testing" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:2465 +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:2471 +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@lists.debian.org</email>." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: pkgs.dbk:2478 +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:2487 +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:2492 +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:2497 +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:2503 +msgid "Make sure that you included only the minimal amount of changes;" +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: pkgs.dbk:2508 +msgid "Make sure that you included an appropriate explanation in the changelog;" +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: pkgs.dbk:2513 +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:2519 +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:2525 +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:2532 +msgid "" +"After uploading and successful build on all platforms, contact the release " +"team at <email>debian-release@lists.debian.org</email> and ask them to " +"approve your upload." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: pkgs.dbk:2541 +msgid "Frequently asked questions" +msgstr "" + +# type: Content of: <chapter><section><section><section><title> +#: pkgs.dbk:2543 +msgid "What are release-critical bugs, and how do they get counted?" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:2545 +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:2549 +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:2555 +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:2562 +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:2568 +msgid "How could installing a package into testing possibly break other packages?" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: pkgs.dbk:2570 +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:2577 +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:2582 +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:2588 +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:2598 +msgid "" +"If you are having problems with complicated groups of packages like this, " +"contact debian-devel or debian-release for help." +msgstr "" diff --git a/po4a/po/resources.pot b/po4a/po/resources.pot new file mode 100644 index 0000000..856c359 --- /dev/null +++ b/po4a/po/resources.pot @@ -0,0 +1,1995 @@ +# 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-06-26 16:13+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:5 +msgid "Resources for Debian Developers" +msgstr "" + +# type: Content of: <chapter><para> +#: resources.dbk:7 +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:12 +msgid "Mailing lists" +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:14 +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.debian.org/\">lists.debian.org</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=\"http://www.debian.org/MailingLists/\"></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:24 +msgid "Basic rules for use" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:26 +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:32 +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:37 +msgid "" +"Please read the <ulink " +"url=\"http://www.debian.org/MailingLists/#codeofconduct\">code of " +"conduct</ulink> for more information." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: resources.dbk:44 +msgid "Core development mailing lists" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:46 +msgid "The core Debian mailing lists that developers should use are:" +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: resources.dbk:51 +msgid "" +"<email>debian-devel-announce@lists.debian.org</email>, 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:58 +msgid "" +"<email>debian-devel@lists.debian.org</email>, used to discuss various " +"development related technical issues." +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: resources.dbk:64 +msgid "" +"<email>debian-policy@lists.debian.org</email>, where the Debian Policy is " +"discussed and voted on." +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: resources.dbk:70 +msgid "" +"<email>debian-project@lists.debian.org</email>, used to discuss various " +"non-technical issues related to the project." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:76 +msgid "" +"There are other mailing lists available for a variety of special topics; see " +"<ulink url=\"http://lists.debian.org/\"></ulink> for a list." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: resources.dbk:82 +msgid "Special lists" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:84 +msgid "" +"<email>debian-private@lists.debian.org</email> 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@lists.debian.org</email> 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.debian.org</literal> and looking in the " +"<filename>~debian/archive/debian-private</filename> directory." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:96 +msgid "" +"<email>debian-email@lists.debian.org</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:104 +msgid "Requesting new development-related lists" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:106 +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:114 +msgid "" +"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 <ulink " +"url=\"http://www.debian.org/MailingLists/HOWTO_start_list\">the " +"HOWTO</ulink>." +msgstr "" + +# type: Content of: <chapter><section><title> +#: resources.dbk:123 +msgid "IRC channels" +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:125 +msgid "" +"Several IRC channels are dedicated to Debian's development. They are mainly " +"hosted on the <ulink url=\"http://www.oftc.net/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:131 +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:139 +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:147 +msgid "" +"Since <emphasis>#debian-devel</emphasis> is an open channel, you should not " +"speak there of issues that are discussed in " +"<email>debian-private@lists.debian.org</email>. 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:~debian/archive/debian-private/</filename>, " +"just <command>zgrep</command> for <emphasis>#debian-private</emphasis> in " +"all the files." +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:157 +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:169 +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:174 +msgid "" +"Channels dedicated to Debian also exist on other IRC networks, notably on " +"the <ulink url=\"http://www.freenode.net/\">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:179 +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:190 +msgid "Documentation" +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:192 +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=\"http://www.debian.org/devel/\">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:201 +msgid "Debian machines" +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:203 +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:208 +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=\"http://www.debian.org/devel/dmup\">Debian Machine Usage " +"Policies</ulink>." +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:213 +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:220 +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:225 +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:229 +msgid "" +"The current list of Debian machines is available at <ulink " +"url=\"http://db.debian.org/machines.cgi\"></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:235 +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.debian.org</email>." +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:241 +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:248 +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:252 +msgid "The bugs server" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:254 +msgid "" +"<literal>bugs.debian.org</literal> is the canonical location for the Bug " +"Tracking System (BTS)." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:258 resources.dbk:276 +msgid "It is restricted; a mirror is available on <literal>merkel</literal>." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:261 +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@lists.debian.org</email> before implementing anything, " +"however, to reduce unnecessary duplication of effort or wasted processing " +"time." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: resources.dbk:269 +msgid "The ftp-master server" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:271 +msgid "" +"The <literal>ftp-master.debian.org</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:279 +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@debian.org</email>, but also " +"see the procedures in <xref linkend=\"archive-manip\"/> ." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: resources.dbk:287 +msgid "The non-US server" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:289 +msgid "" +"The non-US server <literal>non-us.debian.org</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:296 +msgid "The www-master server" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:298 +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:302 +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.debian.org/www.debian.org\">Bug Tracking System</ulink>." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: resources.dbk:311 +msgid "The people web server" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:313 +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:317 +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:324 +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:328 +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:333 +msgid "" +"Send mail to <email>debian-devel@lists.debian.org</email> if you have any " +"questions." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: resources.dbk:339 +msgid "The CVS server" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:341 +msgid "Our CVS server is located on <literal>cvs.debian.org</literal>." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:344 +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:349 +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=\"http://cvs.debian.org/\"></ulink>." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:355 +msgid "" +"To request a CVS area, send a request via email to " +"<email>debian-admin@debian.org</email>. 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:363 +msgid "chroots to different distributions" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:365 +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:369 +#, no-wrap +msgid "" +"% dchroot unstable\n" +"Executing shell in chroot: /org/vore.debian.org/chroots/user/unstable" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:373 +msgid "" +"In all chroots, the normal user home directories are available. You can " +"find out which chroots are available via " +"<literal>http://db.debian.org/machines.cgi</literal>." +msgstr "" + +# type: Content of: <chapter><section><title> +#: resources.dbk:382 +msgid "The Developers Database" +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:384 +msgid "" +"The Developers Database, at <ulink url=\"https://db.debian.org/\"></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:391 +msgid "" +"Developers can <ulink url=\"https://db.debian.org/login.html\">log into the " +"database</ulink> to change various information about themselves, such as:" +msgstr "" + +# type: Content of: <chapter><section><itemizedlist><listitem><para> +#: resources.dbk:397 +msgid "forwarding address for your debian.org email" +msgstr "" + +# type: Content of: <chapter><section><itemizedlist><listitem><para> +#: resources.dbk:402 +msgid "subscription to debian-private" +msgstr "" + +# type: Content of: <chapter><section><itemizedlist><listitem><para> +#: resources.dbk:407 +msgid "whether you are on vacation" +msgstr "" + +# type: Content of: <chapter><section><itemizedlist><listitem><para> +#: resources.dbk:412 +msgid "" +"personal information such as your address, country, the latitude and " +"longitude of the place where you live for use in <ulink " +"url=\"http://www.debian.org/devel/developers.loc\">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:420 +msgid "password and preferred shell on Debian Project machines" +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:425 +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=\"http://db.debian.org/doc-general.html\"></ulink>." +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:430 +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=\"http://db.debian.org/doc-mail.html\"></ulink>." +msgstr "" + +# type: Content of: <chapter><section><title> +#: resources.dbk:438 +msgid "The Debian archive" +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:440 +msgid "" +"The Debian GNU/Linux distribution consists of a lot of packages " +"(<filename>.deb</filename>'s, currently around 9000) and a few additional " +"files (such as documentation and installation disk images)." +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:445 +msgid "Here is an example directory tree of a complete Debian archive:" +msgstr "" + +# type: Content of: <chapter><section><screen> +#: resources.dbk:448 +#, no-wrap +msgid "" +"/stable/main/\n" +"dists/stable/main/binary-i386/\n" +"dists/stable/main/binary-m68k/\n" +"dists/stable/main/binary-alpha/\n" +" ...\n" +"dists/stable/main/source/\n" +" ...\n" +"dists/stable/main/disks-i386/\n" +"dists/stable/main/disks-m68k/\n" +"dists/stable/main/disks-alpha/\n" +" ...\n" +"\n" +"dists/stable/contrib/\n" +"dists/stable/contrib/binary-i386/\n" +"dists/stable/contrib/binary-m68k/\n" +"dists/stable/contrib/binary-alpha/\n" +" ...\n" +"dists/stable/contrib/source/\n" +"\n" +"dists/stable/non-free/\n" +"dists/stable/non-free/binary-i386/\n" +"dists/stable/non-free/binary-m68k/\n" +"dists/stable/non-free/binary-alpha/\n" +" ...\n" +"dists/stable/non-free/source/\n" +"\n" +"dists/testing/\n" +"dists/testing/main/\n" +" ...\n" +"dists/testing/contrib/\n" +" ...\n" +"dists/testing/non-free/\n" +" ...\n" +"\n" +"dists/unstable\n" +"dists/unstable/main/\n" +" ...\n" +"dists/unstable/contrib/\n" +" ...\n" +"dists/unstable/non-free/\n" +" ...\n" +"\n" +"pool/\n" +"pool/main/a/\n" +"pool/main/a/apt/\n" +" ...\n" +"pool/main/b/\n" +"pool/main/b/bash/\n" +" ...\n" +"pool/main/liba/\n" +"pool/main/liba/libalias-perl/\n" +" ...\n" +"pool/main/m/\n" +"pool/main/m/mailx/\n" +" ...\n" +"pool/non-free/n/\n" +"pool/non-free/n/netscape/\n" +" ..." +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:508 +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:522 +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:527 +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:532 +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:538 +msgid "Sections" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:540 +msgid "" +"The <emphasis>main</emphasis> section of the Debian archive is what makes up " +"the <emphasis role=\"strong\">official Debian GNU/Linux " +"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 GNU/Linux." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:548 +msgid "" +"Every package in the main section must fully comply with the <ulink " +"url=\"http://www.debian.org/social_contract#guidelines\">Debian Free " +"Software Guidelines</ulink> (DFSG) and with all other policy requirements as " +"described in the <ulink " +"url=\"http://www.debian.org/doc/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:556 +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:561 +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:568 +msgid "" +"The <ulink url=\"http://www.debian.org/doc/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:573 +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:581 +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:587 +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:597 +msgid "Architectures" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:599 +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:604 +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:618 +msgid "" +"Debian GNU/Linux 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:629 +msgid "" +"Information for developers and users about the specific ports are available " +"at the <ulink url=\"http://www.debian.org/ports/\">Debian Ports web " +"pages</ulink>." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: resources.dbk:635 +msgid "Packages" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:637 +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:641 +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:647 +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:657 +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:664 +msgid "Distributions" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:666 +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:672 +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:679 +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:687 +msgid "Stable, testing, and unstable" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: resources.dbk:689 +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:696 +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:705 +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:712 +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.debian.org</literal>)." +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: resources.dbk:729 +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:746 +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:753 +msgid "More information about the testing distribution" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: resources.dbk:755 +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:759 +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:765 +msgid "Experimental" +msgstr "" + +# type: Content of: <chapter><section><section><section><para> +#: resources.dbk:767 +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:778 +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><screen> +#: resources.dbk:783 +#, no-wrap +msgid "" +"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:787 +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:793 +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:803 +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:813 +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:817 +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:821 +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:830 +msgid "Release code names" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:832 +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:844 +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:853 +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:861 +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:875 +msgid "Debian mirrors" +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:877 +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:888 +msgid "" +"All the information on Debian mirrors, including a list of the available " +"public FTP/HTTP servers, can be found at <ulink " +"url=\"http://www.debian.org/mirror/\"></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:895 +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:902 +msgid "The Incoming system" +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:904 +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.debian.org</literal>." +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:909 +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:928 +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=\"http://incoming.debian.org/\"></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:940 +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@lists.debian.org</email>. If a package is released " +"with <literal>Distribution:</literal> set to `unstable' or `experimental', " +"the announcement will be posted to " +"<email>debian-devel-changes@lists.debian.org</email> instead." +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:950 +msgid "" +"Though ftp-master is restricted, a copy of the installation is available to " +"all developers on <literal>merkel.debian.org</literal>." +msgstr "" + +# type: Content of: <chapter><section><title> +#: resources.dbk:956 +msgid "Package information" +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: resources.dbk:958 +msgid "On the web" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:960 +msgid "" +"Each package has several dedicated web pages. " +"<literal>http://packages.debian.org/<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:967 +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.debian.org/<replaceable>package-name</replaceable></literal>." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: resources.dbk:974 +msgid "The <command>madison</command> utility" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:976 +msgid "" +"<command>madison</command> is a command-line utility that is available on " +"<literal>ftp-master.debian.org</literal>, and on the mirror on " +"<literal>merkel.debian.org</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:984 +#, 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:991 +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:1001 +msgid "The Package Tracking System" +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:1003 +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:1008 +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:1012 +msgid "By default you will get:" +msgstr "" + +# type: Content of: <chapter><section><variablelist><varlistentry><listitem><para> +#: resources.dbk:1019 +msgid "All the bug reports and following discussions." +msgstr "" + +# type: Content of: <chapter><section><variablelist><varlistentry><listitem><para> +#: resources.dbk:1027 +msgid "" +"The email notifications from <email>control@bugs.debian.org</email> about " +"bug report status changes." +msgstr "" + +# type: Content of: <chapter><section><variablelist><varlistentry><listitem><para> +#: resources.dbk:1036 +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:1045 +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:1054 +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>@packages.qa.debian.org</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:1066 +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:1073 +msgid "You can also decide to receive additional information:" +msgstr "" + +# type: Content of: <chapter><section><variablelist><varlistentry><listitem><para> +#: resources.dbk:1080 +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:1091 +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:1100 +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:1109 +msgid "" +"Information about changes made to the package in derivative distributions " +"(for example Ubuntu)." +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: resources.dbk:1116 +msgid "The PTS email interface" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:1118 +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:1126 +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:1139 +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:1149 +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:1158 +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:1167 +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:1174 +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:1179 +msgid "" +"<literal>bts-control</literal>: reply to mails sent to " +"<email>control@bugs.debian.org</email>" +msgstr "" + +# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><itemizedlist><listitem><para> +#: resources.dbk:1185 +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:1191 +msgid "<literal>cvs</literal>: notification of CVS commits" +msgstr "" + +# type: Content of: <chapter><section><section><variablelist><varlistentry><listitem><itemizedlist><listitem><para> +#: resources.dbk:1196 +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:1201 +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:1207 +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:1213 +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:1219 +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:1225 +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:1235 +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:1244 +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:1254 +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:1264 +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:1273 +msgid "Stops processing commands. All following lines are ignored by the bot." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:1279 +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:1287 +msgid "Filtering PTS mails" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:1289 +msgid "" +"Once you are subscribed to a package, you will get the mails sent to " +"<literal><replaceable>sourcepackage</replaceable>@packages.qa.debian.org</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:1297 +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:1301 +#, no-wrap +msgid "" +"-Loop: dpkg@packages.qa.debian.org\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:1309 +msgid "Forwarding CVS commits in the PTS" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:1311 +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:1317 +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@packages.qa.debian.org</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:1326 +msgid "The PTS web interface" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:1328 +msgid "" +"The PTS has a web interface at <ulink " +"url=\"http://packages.qa.debian.org/\"></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:1338 +msgid "" +"You can jump directly to the web page concerning a specific source package " +"with a URL like " +"<literal>http://packages.qa.debian.org/<replaceable>sourcepackage</replaceable></literal>." +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:1343 +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:1349 +msgid "Static news items can be used to indicate:" +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: resources.dbk:1354 +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:1360 +msgid "a link to the upstream web site" +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: resources.dbk:1365 +msgid "a link to the upstream bug tracker" +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: resources.dbk:1370 +msgid "the existence of an IRC channel dedicated to the software" +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: resources.dbk:1375 +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:1381 +msgid "Usual news items may be used to announce that:" +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: resources.dbk:1386 +msgid "beta packages are available for testing" +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: resources.dbk:1391 +msgid "final packages are expected for next week" +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: resources.dbk:1396 +msgid "the packaging is about to be redone from scratch" +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: resources.dbk:1401 +msgid "backports are available" +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: resources.dbk:1406 +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:1411 +msgid "a NMU is being worked on" +msgstr "" + +# type: Content of: <chapter><section><section><itemizedlist><listitem><para> +#: resources.dbk:1416 +msgid "something important will affect the package" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:1421 +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:1432 +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:1437 +#, no-wrap +msgid "" +": 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: http://cvs.debian.org/debian-cd/" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:1445 +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:1450 +#, no-wrap +msgid "" +": Raphael Hertzog <hertzog@debian.org>\n" +"To: debian-gtk-gnome@lists.debian.org\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:1463 +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:1473 +msgid "Developer's packages overview" +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:1475 +msgid "" +"A QA (quality assurance) web portal is available at <ulink " +"url=\"http://qa.debian.org/developer.php\"></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:1484 +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:1491 +msgid "Debian *Forge: Alioth" +msgstr "" + +# type: Content of: <chapter><section><para> +#: resources.dbk:1493 +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:1500 +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:1506 +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:1511 +msgid "" +"For more information please visit <ulink " +"url=\"http://alioth.debian.org/\"></ulink>." +msgstr "" + +# type: Content of: <chapter><section><title> +#: resources.dbk:1517 +msgid "Goodies for Developers" +msgstr "" + +# type: Content of: <chapter><section><section><title> +#: resources.dbk:1519 +msgid "LWN Subscriptions" +msgstr "" + +# type: Content of: <chapter><section><section><para> +#: resources.dbk:1521 +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.debian.org/debian-devel-announce/2002/10/msg00018.html\"></ulink>." +msgstr "" diff --git a/po4a/po/scope.pot b/po4a/po/scope.pot new file mode 100644 index 0000000..2154e96 --- /dev/null +++ b/po4a/po/scope.pot @@ -0,0 +1,72 @@ +# 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-06-26 16:12+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:5 +msgid "Scope of This Document" +msgstr "" + +# type: Content of: <chapter><para> +#: scope.dbk:7 +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:11 +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:20 +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:28 +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=\"http://www.debian.org/doc/debian-policy/\">Debian Policy " +"Manual</ulink>." +msgstr "" + +# type: Content of: <chapter><para> +#: scope.dbk:35 +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 "" diff --git a/po4a/po/tools.pot b/po4a/po/tools.pot new file mode 100644 index 0000000..7cca30a --- /dev/null +++ b/po4a/po/tools.pot @@ -0,0 +1,654 @@ +# 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-06-26 16:13+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:5 +msgid "Overview of Debian Maintainer Tools" +msgstr "" + +# type: Content of: <appendix><para> +#: tools.dbk:7 +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:12 +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:16 +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:24 +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 " +"<literal>apt-cache show <package-name></literal>." +msgstr "" + +# type: Content of: <appendix><section><title> +#: tools.dbk:30 +msgid "Core tools" +msgstr "" + +# type: Content of: <appendix><section><para> +#: tools.dbk:32 +msgid "The following tools are pretty much required for any maintainer." +msgstr "" + +# type: Content of: <appendix><section><section><para> +#: tools.dbk:37 +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:48 +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:54 +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:58 +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:68 +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:79 +msgid "Package lint tools" +msgstr "" + +# type: Content of: <appendix><section><para> +#: tools.dbk:81 +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:89 +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:95 +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:102 +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:106 +msgid "" +"You can also see a summary of all problems reported by Lintian on your " +"packages at <ulink url=\"http://lintian.debian.org/\"></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:116 +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:125 +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:134 +msgid "You can run it over a pair of binary packages:" +msgstr "" + +# type: Content of: <appendix><section><section><screen> +#: tools.dbk:137 +#, no-wrap +msgid "package_1-1_arch.deb package_2-1_arch.deb" +msgstr "" + +# type: Content of: <appendix><section><section><para> +#: tools.dbk:140 +msgid "Or even a pair of changes files:" +msgstr "" + +# type: Content of: <appendix><section><section><screen> +#: tools.dbk:143 +#, no-wrap +msgid "package_1-1_arch.changes package_2-1_arch.changes" +msgstr "" + +# type: Content of: <appendix><section><section><para> +#: tools.dbk:146 +msgid "" +"For more information please see <citerefentry> " +"<refentrytitle>debdiff</refentrytitle> <manvolnum>1</manvolnum> " +"</citerefentry>." +msgstr "" + +# type: Content of: <appendix><section><title> +#: tools.dbk:155 +msgid "Helpers for <filename>debian/rules</filename>" +msgstr "" + +# type: Content of: <appendix><section><para> +#: tools.dbk:157 +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:165 +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:173 +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:179 +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:188 +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:198 +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:209 +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:217 +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:227 +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:237 +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:245 +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:256 +msgid "Package builders" +msgstr "" + +# type: Content of: <appendix><section><para> +#: tools.dbk:258 +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:264 +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:270 +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:281 +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:287 +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:297 +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:303 +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:312 +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=\"http://buildd.debian.org/\"></ulink> to see the system in action." +msgstr "" + +# type: Content of: <appendix><section><title> +#: tools.dbk:324 +msgid "Package uploaders" +msgstr "" + +# type: Content of: <appendix><section><para> +#: tools.dbk:326 +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:332 +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:342 +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:354 +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:362 +msgid "Maintenance automation" +msgstr "" + +# type: Content of: <appendix><section><para> +#: tools.dbk:364 +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:371 +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:385 +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:394 +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:405 +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:411 +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:420 +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:429 +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:437 +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:448 +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:454 +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:460 +#, no-wrap +msgid "-depcheck -b debian/rules build" +msgstr "" + +# type: Content of: <appendix><section><section><para> +#: tools.dbk:463 +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:467 +msgid "" +"For more information please see <citerefentry> " +"<refentrytitle>dpkg-depcheck</refentrytitle> <manvolnum>1</manvolnum> " +"</citerefentry>." +msgstr "" + +# type: Content of: <appendix><section><title> +#: tools.dbk:476 +msgid "Porting tools" +msgstr "" + +# type: Content of: <appendix><section><para> +#: tools.dbk:478 +msgid "The following tools are helpful for porters and for cross-compilation." +msgstr "" + +# type: Content of: <appendix><section><section><para> +#: tools.dbk:483 +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:493 +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:504 +msgid "Documentation and information" +msgstr "" + +# type: Content of: <appendix><section><para> +#: tools.dbk:506 +msgid "" +"The following packages provide information for maintainers or help with " +"building documentation." +msgstr "" + +# type: Content of: <appendix><section><section><para> +#: tools.dbk:512 +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:518 +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:526 +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:534 +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 "" diff --git a/resources.dbk b/resources.dbk new file mode 100644 index 0000000..a167915 --- /dev/null +++ b/resources.dbk @@ -0,0 +1,1531 @@ +<?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"> +<chapter id="resources"> +<title>Resources for Debian Developers + +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. + +
+Mailing lists + +Much of the conversation between Debian developers (and users) is managed +through a wide array of mailing lists we host at lists.debian.org. To find out +more on how to subscribe or unsubscribe, how to post and how not to post, where +to find old posts and how to search them, how to contact the list maintainers +and see various other information about the mailing lists, please read . This section will only +cover aspects of mailing lists that are of particular interest to developers. + +
+Basic rules for use + +When replying to messages on the mailing list, please do not send a carbon copy +(CC) to the original poster unless they explicitly request +to be copied. Anyone who posts to a mailing list should read it to see the +responses. + + +Cross-posting (sending the same message to multiple lists) is discouraged. As +ever on the net, please trim down the quoting of articles you're replying to. +In general, please adhere to the usual conventions for posting messages. + + +Please read the code of conduct +for more information. + +
+ +
+Core development mailing lists + +The core Debian mailing lists that developers should use are: + + + + +debian-devel-announce@lists.debian.org, used to announce +important things to developers. All developers are expected to be subscribed +to this list. + + + + +debian-devel@lists.debian.org, used to discuss various +development related technical issues. + + + + +debian-policy@lists.debian.org, where the Debian Policy is +discussed and voted on. + + + + +debian-project@lists.debian.org, used to discuss various +non-technical issues related to the project. + + + + +There are other mailing lists available for a variety of special topics; see + for a list. + +
+ +
+Special lists + +debian-private@lists.debian.org 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 +debian-private@lists.debian.org unless it is really necessary. +Moreover, do not 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 lists.debian.org +and looking in the ~debian/archive/debian-private +directory. + + +debian-email@lists.debian.org 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. + +
+ +
+Requesting new development-related lists + +Before requesting a mailing list that relates to the development of a package +(or a small group of related packages), please consider if using an alias (via +a .forward-aliasname file on master.debian.org, which translates into a +reasonably nice you-aliasname@debian.org address) or +a self-managed mailing list on Alioth is +more appropriate. + + +If you decide that a regular mailing list on lists.debian.org is really what +you want, go ahead and fill in a request, following the HOWTO. + +
+ +
+ +
+IRC channels + +Several IRC channels are dedicated to Debian's development. They are mainly +hosted on the Open and free technology +community (OFTC) network. The irc.debian.org DNS +entry is an alias to irc.oftc.net. + + +The main channel for Debian in general is #debian. This +is a large, general-purpose channel where users can find recent news in the +topic and served by bots. #debian is for English +speakers; there are also #debian.de, +#debian-fr, #debian-br and other +similarly named channels for speakers of other languages. + + +The main channel for Debian development is #debian-devel. +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 #debian for that). It is however open to anyone +who wants to lurk (and learn). Its topic is commonly full of interesting +information for developers. + + +Since #debian-devel is an open channel, you should not +speak there of issues that are discussed in +debian-private@lists.debian.org. There's another channel for +this purpose, it's called #debian-private and it's +protected by a key. This key is available in the archives of debian-private in +master.debian.org:~debian/archive/debian-private/, just +zgrep for #debian-private in all the +files. + + +There are other additional channels dedicated to specific subjects. +#debian-bugs is used for coordinating bug squashing +parties. #debian-boot is used to coordinate the work on +the debian-installer. #debian-doc 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: +#debian-bsd, #debian-kde, +#debian-jr, #debian-edu, +#debian-sf (SourceForge package), +#debian-oo (OpenOffice package) ... + + +Some non-English developers' channels exist as well, for example +#debian-devel-fr for French speaking people interested in +Debian's development. + + +Channels dedicated to Debian also exist on other IRC networks, notably on the +freenode IRC network, which was +pointed at by the irc.debian.org alias until 4th June 2006. + + +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: Nick Setup Page. The +mail needs to be signed by a key in the Debian keyring. Please see Freenodes +documentation for more information about cloaks. + +
+ +
+Documentation + +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 The +Developers' Corner. Take the time to browse all the links, you will +learn many more things. + +
+ +
+Debian machines + +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. + + +Most of the machines are available for individual developers to use, as long as +the developers follow the rules set forth in the Debian Machine Usage Policies. + + +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. + + +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. + + +Please do not put any material that doesn't relate to Debian on the Debian +servers, unless you have prior permission. + + +The current list of Debian machines is available at . That web page contains +machine names, contact information, information about who can log in, SSH keys +etc. + + +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 +debian-admin@lists.debian.org. + + +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 for information on how to +submit bugs. + + +Some of the core servers are restricted, but the information from there is +mirrored to another server. + +
+The bugs server + +bugs.debian.org is the canonical location for the Bug +Tracking System (BTS). + + +It is restricted; a mirror is available on merkel. + + +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 +debian-devel@lists.debian.org before implementing anything, +however, to reduce unnecessary duplication of effort or wasted processing time. + +
+ +
+The ftp-master server + +The ftp-master.debian.org server holds the canonical copy of +the Debian archive (excluding the non-US packages). Generally, package uploads +go to this server; see . + + +It is restricted; a mirror is available on merkel. + + +Problems with the Debian FTP archive generally need to be reported as bugs +against the ftp.debian.org +pseudo-package or an email to ftpmaster@debian.org, but also see +the procedures in . + +
+ +
+The non-US server + +The non-US server non-us.debian.org was discontinued with +the release of sarge. The pseudo-package nonus.debian.org still exists for now. + +
+ +
+The www-master server + +The main web server is www-master.debian.org. It holds the +official web pages, the face of Debian for most newbies. + + +If you find a problem with the Debian web server, you should generally submit a +bug against the pseudo-package, www.debian.org. Remember to check whether or not +someone else has already reported the problem to the Bug Tracking System. + +
+ +
+The people web server + +people.debian.org is the server used for developers' own web +pages about anything related to Debian. + + +If you have some Debian-specific information which you want to serve on the +web, you can do this by putting material in the +public_html directory under your home directory on +people.debian.org. This will be accessible at the URL +http://people.debian.org/~your-user-id/. + + +You should only use this particular location because it will be backed up, +whereas on other hosts it won't. + + +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. + + +Send mail to debian-devel@lists.debian.org if you have any +questions. + +
+ +
+The CVS server + +Our CVS server is located on cvs.debian.org. + + +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. + + +Generally, cvs.debian.org offers a combination of local CVS +access, anonymous client-server read-only access, and full client-server access +through ssh. Also, the CVS area can be accessed read-only +via the Web at . + + +To request a CVS area, send a request via email to +debian-admin@debian.org. Include the name of the requested CVS +area, the Debian account that should own the CVS root area, and why you need +it. + +
+ +
+chroots to different distributions + +On some machines, there are chroots to different distributions available. You +can use them like this: + + +% dchroot unstable +Executing shell in chroot: /org/vore.debian.org/chroots/user/unstable + + +In all chroots, the normal user home directories are available. You can find +out which chroots are available via +http://db.debian.org/machines.cgi. + +
+ +
+ +
+The Developers Database + +The Developers Database, at , 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 +finger yourlogin@db.debian.org to see what it reports. + + +Developers can log into the +database to change various information about themselves, such as: + + + + +forwarding address for your debian.org email + + + + +subscription to debian-private + + + + +whether you are on vacation + + + + +personal information such as your address, country, the latitude and longitude +of the place where you live for use in the world map of Debian +developers, phone and fax numbers, IRC nickname and web page + + + + +password and preferred shell on Debian Project machines + + + + +Most of the information is not accessible to the public, naturally. For more +information please read the online documentation that you can find at . + + +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 . + +
+ +
+The Debian archive + +The Debian GNU/Linux distribution consists of a lot of packages +(.deb's, currently around 9000) and a few additional files +(such as documentation and installation disk images). + + +Here is an example directory tree of a complete Debian archive: + + +/stable/main/ +dists/stable/main/binary-i386/ +dists/stable/main/binary-m68k/ +dists/stable/main/binary-alpha/ + ... +dists/stable/main/source/ + ... +dists/stable/main/disks-i386/ +dists/stable/main/disks-m68k/ +dists/stable/main/disks-alpha/ + ... + +dists/stable/contrib/ +dists/stable/contrib/binary-i386/ +dists/stable/contrib/binary-m68k/ +dists/stable/contrib/binary-alpha/ + ... +dists/stable/contrib/source/ + +dists/stable/non-free/ +dists/stable/non-free/binary-i386/ +dists/stable/non-free/binary-m68k/ +dists/stable/non-free/binary-alpha/ + ... +dists/stable/non-free/source/ + +dists/testing/ +dists/testing/main/ + ... +dists/testing/contrib/ + ... +dists/testing/non-free/ + ... + +dists/unstable +dists/unstable/main/ + ... +dists/unstable/contrib/ + ... +dists/unstable/non-free/ + ... + +pool/ +pool/main/a/ +pool/main/a/apt/ + ... +pool/main/b/ +pool/main/b/bash/ + ... +pool/main/liba/ +pool/main/liba/libalias-perl/ + ... +pool/main/m/ +pool/main/m/mailx/ + ... +pool/non-free/n/ +pool/non-free/n/netscape/ + ... + + +As you can see, the top-level directory contains two directories, +dists/ and pool/. 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, stable, +testing and unstable. The +Packages and Sources files in the +distribution subdirectories can reference files in the +pool/ directory. The directory tree below each of the +distributions is arranged in an identical manner. What we describe below for +stable is equally applicable to the +unstable and testing distributions. + + +dists/stable contains three directories, namely +main, contrib, and +non-free. + + +In each of the areas, there is a directory for the source packages +(source) and a directory for each supported architecture +(binary-i386, binary-m68k, etc.). + + +The main area contains additional directories which hold +the disk images and some essential pieces of documentation required for +installing the Debian distribution on a specific architecture +(disks-i386, disks-m68k, etc.). + +
+Sections + +The main section of the Debian archive is what makes up +the official Debian GNU/Linux distribution. +The main section is official because it fully complies +with all our guidelines. The other two sections do not, to different degrees; +as such, they are not officially part of +Debian GNU/Linux. + + +Every package in the main section must fully comply with the Debian Free Software +Guidelines (DFSG) and with all other policy requirements as described +in the Debian Policy +Manual. The DFSG is our definition of “free software.” Check out +the Debian Policy Manual for details. + + +Packages in the contrib section have to comply with the +DFSG, but may fail other requirements. For instance, they may depend on +non-free packages. + + +Packages which do not conform to the DFSG are placed in the +non-free 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. + + +The Debian Policy +Manual contains a more exact definition of the three sections. The +above discussion is just an introduction. + + +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 +main and contrib sections, one can +avoid any legal risks. Some packages in the non-free +section do not allow commercial distribution, for example. + + +On the other hand, a CD-ROM vendor could easily check the individual package +licenses of the packages in non-free 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.) + + +Note that the term section is also used to refer to categories which simplify +the organization and browsing of available packages, e.g. +admin, net, +utils 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. + +
+ +
+Architectures + +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. + + +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 i386 (our name for Intel x86), there +is m68k, alpha, +powerpc, sparc, +hurd-i386, arm, +ia64, hppa, +s390, mips, +mipsel and sh as of this writing. + + +Debian GNU/Linux 1.3 is only available as i386. Debian +2.0 shipped for i386 and m68k +architectures. Debian 2.1 ships for the i386, +m68k, alpha, and +sparc architectures. Debian 2.2 added support for the +powerpc and arm architectures. +Debian 3.0 added support of five new architectures: ia64, +hppa, s390, mips +and mipsel. + + +Information for developers and users about the specific ports are available at +the Debian Ports web pages. + +
+ +
+Packages + +There are two types of Debian packages, namely source and +binary packages. + + +Source packages consist of either two or three files: a +.dsc file, and either a .tar.gz file +or both an .orig.tar.gz and a +.diff.gz file. + + +If a package is developed specially for Debian and is not distributed outside +of Debian, there is just one .tar.gz file which contains +the sources of the program. If a package is distributed elsewhere too, the +.orig.tar.gz file stores the so-called upstream +source code, that is the source code that's distributed by the +upstream maintainer (often the author of the software). +In this case, the .diff.gz contains the changes made by +the Debian maintainer. + + +The .dsc file lists all the files in the source package +together with checksums (md5sums) and some additional info +about the package (maintainer, version, etc.). + +
+ +
+Distributions + +The directory system described in the previous chapter is itself contained +within distribution directories. Each distribution is +actually contained in the pool directory in the top-level +of the Debian archive itself. + + +To summarize, the Debian archive has a root directory within an FTP server. +For instance, at the mirror site, ftp.us.debian.org, the +Debian archive itself is contained in /debian, which is a common +location (another is /pub/debian). + + +A distribution comprises Debian source and binary packages, and the respective +Sources and Packages index files, +containing the header information from all those packages. The former are kept +in the pool/ directory, while the latter are kept in the +dists/ directory of the archive (for backwards +compatibility). + +
+Stable, testing, and unstable + +There are always distributions called stable (residing in +dists/stable), testing (residing in +dists/testing), and unstable +(residing in dists/unstable). This reflects the +development process of the Debian project. + + +Active development is done in the unstable distribution +(that's why this distribution is sometimes called the development +distribution). 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. + + +The testing 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 . + + +After a period of development, once the release manager deems fit, the +testing distribution is frozen, meaning that the policies +which control how packages move from unstable to +testing are tightened. Packages which are too buggy are +removed. No changes are allowed into testing except for +bug fixes. After some time has elapsed, depending on progress, the +testing 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 +testing is renamed to stable, and a +new copy is created for the new testing, and the previous +stable is renamed to oldstable and +stays there until it is finally archived. On archiving, the contents are moved +to archive.debian.org). + + +This development cycle is based on the assumption that the +unstable distribution becomes stable +after passing a period of being in testing. 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 stable in the +proposed-updates directory. Those packages in +proposed-updates 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 +uploads to the stable +distribution for details. + + +Note that development under unstable continues during the +freeze period, since the unstable distribution remains in +place in parallel with testing. + +
+ +
+More information about the testing distribution + +Packages are usually installed into the `testing' distribution after they have +undergone some degree of testing in unstable. + + +For more details, please see the information about +the testing distribution. + +
+ +
+Experimental + +The experimental 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 unstable +distribution (but there is a reason to package it nevertheless). Users who +download and install packages from experimental are +expected to have been duly warned. In short, all bets are off for the +experimental distribution. + + +These are the sources.list +5 lines for +experimental: + + + http://ftp.xy.debian.org/debian/ experimental main +deb-src http://ftp.xy.debian.org/debian/ experimental main + + +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 experimental. For +instance, an experimental compressed file system should probably go into +experimental. + + +Whenever there is a new upstream version of a package that introduces new +features but breaks a lot of old ones, it should either not be uploaded, or be +uploaded to experimental. A new, beta, version of some +software which uses a completely different configuration can go into +experimental, at the maintainer's discretion. If you are +working on an incompatible or complex upgrade situation, you can also use +experimental as a staging area, so that testers can get +early access. + + +Some experimental software can still go into unstable, +with a few warnings in the description, but that isn't recommended because +packages from unstable are expected to propagate to +testing and thus to stable. You +should not be afraid to use experimental since it does not +cause any pain to the ftpmasters, the experimental packages are automatically +removed once you upload the package in unstable with a +higher version number. + + +New software which isn't likely to damage your system can go directly into +unstable. + + +An alternative to experimental is to use your personal web +space on people.debian.org. + + +When uploading to unstable a package which had bugs fixed in experimental, +please consider using the option -v to +dpkg-buildpackage to finally get them closed. + +
+ +
+ +
+Release code names + +Every released Debian distribution has a code name: 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. + + +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). + + +On the other hand, if we called the distribution directories +Debian-x.y from the beginning, people would think that +Debian release x.y 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.) + + +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 +code names, while symbolic links for +stable, testing, and +unstable point to the appropriate release directories. + +
+ +
+ +
+Debian mirrors + +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). + + +All the information on Debian mirrors, including a list of the available public +FTP/HTTP servers, can be found at . 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. + + +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. + +
+ +
+The Incoming system + +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 ftp-master.debian.org. + + +Packages are uploaded by all the maintainers into a directory called +UploadQueue. This directory is scanned every few minutes +by a daemon called queued, +*.command-files are executed, and remaining and correctly +signed *.changes-files are moved together with their +corresponding files to the unchecked directory. This +directory is not visible for most Developers, as ftp-master is restricted; it +is scanned every 15 minutes by the katie script, which +verifies the integrity of the uploaded packages and their cryptographic +signatures. If the package is considered ready to be installed, it is moved +into the accepted directory. If this is the first upload +of the package (or it has new binary packages), it is moved to the +new directory, where it waits for approval by the +ftpmasters. If the package contains files to be installed by hand it is moved +to the byhand 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 reject directory. + + +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 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 Packages and +Sources index files for example) have been made, a special +script is called to ask all the primary mirrors to update themselves. + + +The archive maintenance software will also send the OpenPGP/GnuPG signed +.changes file that you uploaded to the appropriate mailing +lists. If a package is released with the Distribution: set +to `stable', the announcement is sent to +debian-changes@lists.debian.org. If a package is released with +Distribution: set to `unstable' or `experimental', the +announcement will be posted to +debian-devel-changes@lists.debian.org instead. + + +Though ftp-master is restricted, a copy of the installation is available to all +developers on merkel.debian.org. + +
+ +
+Package information +
+On the web + +Each package has several dedicated web pages. +http://packages.debian.org/package-name +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. + + +The bug tracking system tracks bugs for each package. You can view the bugs of +a given package at the URL +http://bugs.debian.org/package-name. + +
+ +
+The <command>madison</command> utility + +madison is a command-line utility that is available on +ftp-master.debian.org, and on the mirror on +merkel.debian.org. 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. + + +$ 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 + + +In this example, you can see that the version in unstable +differs from the version in testing 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. + +
+ +
+ +
+The Package Tracking System + +The Package Tracking System (PTS) is an email-based tool to track the activity +of a source package. This really means that you can get the same emails that +the package maintainer gets, simply by subscribing to the package in the PTS. + + +Each email sent through the PTS is classified under one of the keywords listed +below. This will let you select the mails that you want to receive. + + +By default you will get: + + + +bts + + +All the bug reports and following discussions. + + + + +bts-control + + +The email notifications from control@bugs.debian.org about bug +report status changes. + + + + +upload-source + + +The email notification from katie when an uploaded source +package is accepted. + + + + +katie-other + + +Other warning and error emails from katie (such as an +override disparity for the section and/or the priority field). + + + + +default + + +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 +sourcepackage@packages.qa.debian.org. +In order to prevent spam, all messages sent to these addresses must contain the +X-PTS-Approved header with a non-empty value. + + + + +summary + + +Regular summary emails about the package's status. Currently, only progression +in testing is sent. + + + + + +You can also decide to receive additional information: + + + +upload-binary + + +The email notification from katie when an uploaded binary +package is accepted. In other words, whenever a build daemon or a porter +uploads your package for another architecture, you can get an email to track +how your package gets recompiled for all architectures. + + + + +cvs + + +CVS commit notifications, if the package has a CVS repository and the +maintainer has set up forwarding commit notifications to the PTS. + + + + +ddtp + + +Translations of descriptions or debconf templates submitted to the Debian +Description Translation Project. + + + + +derivatives + + +Information about changes made to the package in derivative distributions (for +example Ubuntu). + + + + +
+The PTS email interface + +You can control your subscription(s) to the PTS by sending various commands to +pts@qa.debian.org. + + + +subscribe <sourcepackage> [<email>] + + +Subscribes email to communications related to the +source package sourcepackage. Sender address is +used if the second argument is not present. If +sourcepackage is not a valid source package, you'll +get a warning. However if it's a valid binary package, the PTS will subscribe +you to the corresponding source package. + + + + +unsubscribe <sourcepackage> [<email>] + + +Removes a previous subscription to the source package +sourcepackage using the specified email address or +the sender address if the second argument is left out. + + + + +unsubscribeall [<email>] + + +Removes all subscriptions of the specified email address or the sender address +if the second argument is left out. + + + + +which [<email>] + + +Lists all subscriptions for the sender or the email address optionally +specified. + + + + +keyword [<email>] + + +Tells you the keywords that you are accepting. For an explanation of keywords, +see above. Here's a quick +summary: + + + + +bts: mails coming from the Debian Bug Tracking System + + + + +bts-control: reply to mails sent to +control@bugs.debian.org + + + + +summary: automatic summary mails about the state of a +package + + + + +cvs: notification of CVS commits + + + + +ddtp: translations of descriptions and debconf templates + + + + +derivatives: changes made on the package by derivative +distributions + + + + +upload-source: announce of a new source upload that has been +accepted + + + + +upload-binary: announce of a new binary-only upload +(porting) + + + + +katie-other: other mails from ftpmasters (override +disparity, etc.) + + + + +default: all the other mails (those which aren't automatic) + + + + + + +keyword <sourcepackage> [<email>] + + +Same as the previous item but for the given source package, since you may +select a different set of keywords for each source package. + + + + +keyword [<email>] {+|-|=} <list of keywords> + + +Accept (+) or refuse (-) mails classified under the given keyword(s). Define +the list (=) of accepted keywords. This changes the default set of keywords +accepted by a user. + + + + +keywordall [<email>] {+|-|=} <list of keywords> + + +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. + + + + +keyword <sourcepackage> [<email>] {+|-|=} <list of keywords> + + +Same as previous item but overrides the keywords list for the indicated source +package. + + + + +quit | thanks | -- + + +Stops processing commands. All following lines are ignored by the bot. + + + + + +The pts-subscribe command-line utility (from the devscripts package) can be handy to temporarily +subscribe to some packages, for example after having made an non-maintainer +upload. + +
+ +
+Filtering PTS mails + +Once you are subscribed to a package, you will get the mails sent to +sourcepackage@packages.qa.debian.org. +Those mails have special headers appended to let you filter them in a special +mailbox (e.g. with procmail). The added headers are +X-Loop, X-PTS-Package, +X-PTS-Keyword and X-Unsubscribe. + + +Here is an example of added headers for a source upload notification on the +dpkg package: + + +-Loop: dpkg@packages.qa.debian.org +X-PTS-Package: dpkg +X-PTS-Keyword: upload-source +X-Unsubscribe: echo 'unsubscribe dpkg' | mail pts@qa.debian.org + +
+ +
+Forwarding CVS commits in the PTS + +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. + + +Once you set up the CVS repository to generate commit notifications, you just +have to make sure it sends a copy of those mails to +sourcepackage_cvs@packages.qa.debian.org. +Only the people who accept the cvs keyword will receive +these notifications. + +
+ +
+The PTS web interface + +The PTS has a web interface at that puts together a lot of +information about each source package. It features many useful links (BTS, QA +stats, contact information, DDTP translation status, buildd logs) and gathers +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. + + +You can jump directly to the web page concerning a specific source package with +a URL like +http://packages.qa.debian.org/sourcepackage. + + +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. + + +Static news items can be used to indicate: + + + + +the availability of a project hosted on +Alioth for co-maintaining the package + + + + +a link to the upstream web site + + + + +a link to the upstream bug tracker + + + + +the existence of an IRC channel dedicated to the software + + + + +any other available resource that could be useful in the maintenance of the +package + + + + +Usual news items may be used to announce that: + + + + +beta packages are available for testing + + + + +final packages are expected for next week + + + + +the packaging is about to be redone from scratch + + + + +backports are available + + + + +the maintainer is on vacation (if they wish to publish this information) + + + + +a NMU is being worked on + + + + +something important will affect the package + + + + +Both kinds of news are generated in a similar manner: you just have to send an +email either to pts-static-news@qa.debian.org or to +pts-news@qa.debian.org. The mail should indicate which package +is concerned by having the name of the source package in a +X-PTS-Package mail header or in a Package +pseudo-header (like the BTS reports). If a URL is available in the +X-PTS-Url mail header or in the Url +pseudo-header, then the result is a link to that URL instead of a complete news +item. + + +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: + + +: 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/ + + +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. + + +: 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: +... + + +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. + +
+ +
+ +
+Developer's packages overview + +A QA (quality assurance) web portal is available at 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. + + +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. + +
+ +
+Debian *Forge: Alioth + +Alioth is a fairly new Debian service, based on a slightly modified version of +the GForge software (which evolved from SourceForge). This software offers +developers access to easy-to-use tools such as bug trackers, patch manager, +project/task managers, file hosting services, mailing lists, CVS repositories +etc. All these tools are managed via a web interface. + + +It is intended to provide facilities to free software projects backed or led by +Debian, facilitate contributions from external developers to projects started +by Debian, and help projects whose goals are the promotion of Debian or its +derivatives. + + +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. + + +For more information please visit . + +
+ +
+Goodies for Developers +
+LWN Subscriptions + +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 . + +
+ +
+ + + diff --git a/scope.dbk b/scope.dbk new file mode 100644 index 0000000..5e706c2 --- /dev/null +++ b/scope.dbk @@ -0,0 +1,41 @@ + + + +Scope of This Document + +The purpose of this document is to provide an overview of the recommended +procedures and the available resources for Debian developers. + + +The procedures discussed within include how to become a maintainer ( ); how to create new packages ( ) and how to upload packages ( +); how to handle bug reports ( ); how to move, +remove, or orphan packages ( ); how to port +packages ( ); and how and when to do interim releases +of other maintainers' packages ( ). + + +The resources discussed in this reference include the mailing lists ( ) and servers ( ); a +discussion of the structure of the Debian archive ( ); +explanation of the different servers which accept package uploads ( ); and a discussion of resources which can help +maintainers with the quality of their packages ( ). + + +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 Debian Policy Manual. + + +Furthermore, this document is not an expression of formal +policy. It contains documentation for the Debian system and +generally agreed-upon best practices. Thus, it is not what is called a +``normative'' document. + + + diff --git a/tools.dbk b/tools.dbk new file mode 100644 index 0000000..7f18532 --- /dev/null +++ b/tools.dbk @@ -0,0 +1,543 @@ + + + +Overview of Debian Maintainer Tools + +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. + + +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. + + +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. + + +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 +apt-cache show <package-name>. + +
+Core tools + +The following tools are pretty much required for any maintainer. + +
+<systemitem role="package">dpkg-dev</systemitem> + +dpkg-dev contains the tools (including +dpkg-source) 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. + +
+ +
+<systemitem role="package">debconf</systemitem> + +debconf 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. + + +You can find documentation for this package in the debconf-doc package. + + +Many feel that this system should be used for all packages which require +interactive configuration; see . debconf is not currently required by Debian Policy, +but that may change in the future. + +
+ +
+<systemitem role="package">fakeroot</systemitem> + +fakeroot simulates root privileges. +This enables you to build packages without being root (packages usually want to +install files with root ownership). If you have fakeroot installed, you can build packages as a +regular user: dpkg-buildpackage -rfakeroot. + +
+ +
+ +
+Package lint tools + +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. + +
+<systemitem role="package">lintian</systemitem> + +lintian 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. + + +You should periodically get the newest lintian from `unstable' and check over all your +packages. Notice that the -i 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. + + +Refer to for more information on how and when to +use Lintian. + + +You can also see a summary of all problems reported by Lintian on your packages +at . These reports contain the +latest lintian output for the whole development distribution +(unstable). + +
+ +
+<systemitem role="package">linda</systemitem> + +linda is another package linter. It is +similar to lintian but has a different +set of checks. Its written in Python rather than Perl. + +
+ +
+<systemitem role="package">debdiff</systemitem> + +debdiff (from the devscripts package, ) +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. + + +You can run it over a pair of binary packages: + + + package_1-1_arch.deb package_2-1_arch.deb + + +Or even a pair of changes files: + + + package_1-1_arch.changes package_2-1_arch.changes + + +For more information please see +debdiff 1 +. + +
+ +
+ +
+Helpers for <filename>debian/rules</filename> + +Package building tools make the process of writing +debian/rules files easier. See for more information about why these might or might +not be desired. + +
+<systemitem role="package">debhelper</systemitem> + +debhelper is a collection of programs +which can be used in debian/rules to automate common tasks +related to building binary Debian packages. debhelper includes programs to install various +files into your package, compress files, fix file permissions, and integrate +your package with the Debian menu system. + + +Unlike some approaches, debhelper 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. + + +There are a number of little debhelper +add-on packages, too transient to document. You can see the list of most of +them by doing apt-cache search ^dh-. + +
+ +
+<systemitem role="package">debmake</systemitem> + +debmake, a precursor to debhelper, is a more coarse-grained +debian/rules assistant. It includes two main programs: +deb-make, which can be used to help a maintainer convert a +regular (non-Debian) source archive into a Debian source package; and +debstd, which incorporates in one big shot the same sort of +automated functions that one finds in debhelper. + + +The consensus is that debmake is now +deprecated in favor of debhelper. It +is a bug to use debmake in new +packages. New packages using debmake +will be rejected from the archive. + +
+ +
+<systemitem role="package">dh-make</systemitem> + +The dh-make package contains +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, dh_make is a rewrite of debmake and its template files use dh_* programs +from debhelper. + + +While the rules files generated by 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. + +
+ +
+<systemitem role="package">yada</systemitem> + +yada is another packaging helper tool. +It uses a debian/packages file to auto-generate +debian/rules and other necessary files in the +debian/ subdirectory. The +debian/packages file contains instruction to build +packages and there is no need to create any Makefile +files. There is possibility to use macro engine similar to the one used in +SPECS files from RPM source packages. + + +For more informations see YADA site. + +
+ +
+<systemitem role="package">equivs</systemitem> + +equivs 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. + +
+ +
+ +
+Package builders + +The following packages help with the package building process, general driving +dpkg-buildpackage as well as handling supporting tasks. + +
+<systemitem role="package">cvs-buildpackage</systemitem> + +cvs-buildpackage 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. + + +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 stable, unstable and possibly +experimental distributions, along with the other benefits +of a version control system. + +
+ +
+<systemitem role="package">debootstrap</systemitem> + +The debootstrap 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. + + +Having a system like this can be useful in many ways. For instance, you can +chroot 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. + +
+ +
+<systemitem role="package">pbuilder</systemitem> + +pbuilder 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. + + +A related package is pbuilder-uml, +which goes even further by doing the build within a User Mode Linux +environment. + +
+ +
+<systemitem role="package">sbuild</systemitem> + +sbuild 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 for more information, and to see the system in action. + +
+ +
+ +
+Package uploaders + +The following packages help automate or simplify the process of uploading +packages into the official archive. + +
+<systemitem role="package">dupload</systemitem> + +dupload 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. + +
+ +
+<systemitem role="package">dput</systemitem> + +The dput package and script does much +the same thing as dupload, but in a +different way. It has some features over dupload, such as the ability to check the GnuPG +signature and checksums before uploading, and the possibility of running +dinstall in dry-run mode after the upload. + +
+ +
+<systemitem role="package">dcut</systemitem> + +The dcut script (part of the package + ) helps in removing files from the ftp upload directory. + +
+ +
+ +
+Maintenance automation + +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 config.sub. + +
+<systemitem role="package">devscripts</systemitem> + +devscripts is a package containing +wrappers and tools which are very helpful for maintaining your Debian packages. +Example scripts include debchange and +dch, which manipulate your +debian/changelog file from the command-line, and +debuild, which is a wrapper around +dpkg-buildpackage. The bts utility is +also very helpful to update the state of bug reports on the command line. +uscan can be used to watch for new upstream versions of your +packages. debrsign 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. + + +See the devscripts +1 manual page for a complete list of +available scripts. + +
+ +
+<systemitem role="package">autotools-dev</systemitem> + +autotools-dev contains best practices +for people who maintain packages which use autoconf and/or +automake. Also contains canonical +config.sub and config.guess files +which are known to work on all Debian ports. + +
+ +
+<systemitem role="package">dpkg-repack</systemitem> + +dpkg-repack 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 /etc were modified), +the new package will inherit the changes. + + +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. + +
+ +
+<systemitem role="package">alien</systemitem> + +alien converts binary packages between various packaging +formats, including Debian, RPM (RedHat), LSB (Linux Standard Base), Solaris, +and Slackware packages. + +
+ +
+<systemitem role="package">debsums</systemitem> + +debsums checks installed packages against their MD5 sums. +Note that not all packages have MD5 sums, since they aren't required by Policy. + +
+ +
+<systemitem role="package">dpkg-dev-el</systemitem> + +dpkg-dev-el is an Emacs lisp package +which provides assistance when editing some of the files in the +debian 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 debian/changelog file. + +
+ +
+<systemitem role="package">dpkg-depcheck</systemitem> + +dpkg-depcheck (from the devscripts package, ) +runs a command under strace to determine all the packages +that were used by the said command. + + +For Debian packages, this is useful when you have to compose a +Build-Depends line for your new package: running the build +process through dpkg-depcheck will provide you with a good +first approximation of the build-dependencies. For example: + + +-depcheck -b debian/rules build + + +dpkg-depcheck can also be used to check for run-time +dependencies, especially if your package uses exec(2) to run other programs. + + +For more information please see +dpkg-depcheck 1 +. + +
+ +
+ +
+Porting tools + +The following tools are helpful for porters and for cross-compilation. + +
+<systemitem role="package">quinn-diff</systemitem> + +quinn-diff 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 Y, +based on architecture X. + +
+ +
+<systemitem role="package">dpkg-cross</systemitem> + +dpkg-cross is a tool for installing +libraries and headers for cross-compiling in a way similar to dpkg. Furthermore, the functionality of +dpkg-buildpackage and dpkg-shlibdeps is +enhanced to support cross-compiling. + +
+ +
+ +
+Documentation and information + +The following packages provide information for maintainers or help with +building documentation. + +
+<systemitem role="package">debiandoc-sgml</systemitem> + +debiandoc-sgml 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. + + +Documentation for the DTD can be found in the debiandoc-sgml-doc package. + +
+ +
+<systemitem role="package">debian-keyring</systemitem> + +Contains the public GPG and PGP keys of Debian developers. See and the package documentation for more information. + +
+ +
+<systemitem role="package">debview</systemitem> + +debview provides an Emacs mode for +viewing Debian binary packages. This lets you examine a package without +unpacking it. + +
+ +
+ + + -- 2.30.2