-</list>
-
-Dans les deux premiers cas, l'information est publique et il est important
-d'avoir une solution le plus vite possible. Dans le dernier cas, cependant, ce
-n'est peut-être pas une information publique. Dans ce cas, il existe quelques
-options possibles pour traiter le problème :
-
-<list>
-<item>
- si l'exposition de sécurité est mineure, il n'y a parfois pas besoin de
- garder le secret sur le problème et une correction devrait être effectuée
- et diffusée,
-</item>
-<item>
- si le problème est grave, il est préférable de partager cette
- information avec d'autres vendeurs et de coordonner une diffusion.
- L'équipe de sécurité garde des contacts avec les différentes organisations
- et individus et peut prendre soin des actions à mener.
-</item>
-</list>
-
-<p>
-Dans tous les cas, si la personne qui indique le problème demande à ce que
-l'information ne soit pas diffusée, cela devrait être respecté avec l'évidente exception
-d'informer l'équipe de sécurité pour qu'une correction puisse être effectuée
-pour la version stable de Debian. Quand vous envoyez des informations
-confidentielles à l'équipe de sécurité, assurez-vous de bien mentionner ce fait.
-
-<p>Veuillez noter que si le secret est nécessaire, vous ne pourrez pas envoyer
-un correctif vers <em>unstable</em> (ou ailleurs) puisque les informations de
-changelog et de diff sont publiques pour <em>unstable</em>.
-
-<p>Il existe deux raisons pour diffuser l'information même si le secret est
-demandé : le problème est connu depuis un certain temps ou le problème ou
-son exploitation est devenu public.
-
- <sect2 id="bug-security-advisories">Annonces de sécurité
-<p>
-Les annonces de sécurité ne sont émises que pour la distribution actuelle
- diffusée <em>stable</em>, <em>PAS</em> pour <em>testing</em> ou <em>unstable</em>.
- Quand elle est diffusée, l'annonce est envoyée à la liste de diffusion
- &email-debian-security-announce; et elle est postée sur <url
- id="&url-debian-security-advisories;" name="la page de sécurité">. Les
- annonces de sécurité sont écrites et postées par les membres de l'équipe de sécurité.
- Cependant, ils ne verront aucun inconvénient à ce qu'un responsable leur
- apporte des informations ou écrive une partie du texte. Les informations qui
- devraient être présentes dans une annonce incluent :
-<list compact>
-<item>
- une description du problème et de sa portée, y compris :
- <list>
- <item>
- le type du problème (usurpation de privilège, déni de service,
- etc.),
- </item>
- <item>
- quels sont les privilèges obtenus et par quels utilisateurs (si c'est le
- cas)
- </item>
- <item>
- comment il peut être exploité,
- </item>
- <item>
- si le problème peut être exploité à distance ou localement,
- </item>
- <item>
- comment le problème a été corrigé,
- </item>
- </list>
- Ces informations permettent aux utilisateurs d'estimer la menace pesant
- sur leurs systèmes.
-
-</item>
-<item>
- les numéros de version des paquets affectés,
-</item>
-<item>
- les numéros de version des paquets corrigés,
-</item>
-<item>
- une information sur la façon de récupérer les paquets mis à jour
- (habituellement l'archive de sécurité Debian),
-</item>
-<item>
- des références à des annonces amont, des identifiants <url
- id="http://cve.mitre.org" name="CVE"> et toute autre information utile
- pour recouper les références de la vulnérabilité.
-</item>
-</list>
-
- <sect2 id="bug-security-building">
- <heading>Préparer les paquets pour corriger des problèmes de sécurité
-<p>
-Une façon d'aider l'équipe de sécurité dans ses travaux est de leur fournir des
- paquets corrigés convenables pour une annonce de sécurité pour la version
- <em>stable</em> de Debian
-<p>
-Quand une mise à jour de la version <em>stable</em> est effectuée, un soin
- particulier doit être apporté pour éviter de modifier le comportement du
- système ou d'introduire de nouveaux bogues. Pour cela, faites le moins de
- changements possibles pour corriger le bogue. Les utilisateurs et les
- administrateurs s'attendent à un comportement identique dans une version
- lorsque celle-ci est diffusée, donc tout changement qui est fait est
- susceptible de casser le système de quelqu'un. Ceci est spécialement vrai pour
- les bibliothèques : assurez-vous ne de jamais changer l'API ou l'ABI,
- quelque minimal que soit le changement.
-<p>
-Cela veut dire que passer à une version amont supérieure n'est pas une bonne
-solution. À la place, les changements pertinents devraient être rétroportés
-vers la version présente dans la distribution <em>stable</em> de Debian.
-Habituellement, les développeurs amont veulent bien aider. Sinon, l'équipe de
-sécurité Debian peut le faire.
-<p>
-Dans certains cas, il n'est pas possible de rétroporter un correctif de
-sécurité, par exemple, quand de grandes quantités de code source doivent être
-modifiées ou récrites. Si cela se produit, il peut être nécessaire de passer à
-une nouvelle version amont. Cependant, ceci n'est fait que dans des situations
-extrêmes et vous devez toujours coordonner cela avec l'équipe de sécurité au
-préalable.
-<p>
-Il existe une autre règle de conduite liée à cela : testez toujours vos
-changements. Si une exploitation du problème existe, essayez-la et
-vérifiez qu'elle réussit sur le paquet non corrigé et échoue sur le paquet
-corrigé. Testez aussi les autres actions normales car parfois un correctif de
-sécurité peut casser de manière subtile des fonctionnalités qui ne semblent pas
-liées.
-<p>
-N'incluez <strong>PAS</strong> de changements dans votre paquet qui ne soient
-pas liés directement à la correction de la vulnérabilité. Ceux-ci devraient être
-ensuite enlevés et cela perd du temps. S'il y a d'autres bogues dans votre
-paquet que vous aimeriez corriger, faites un envoi vers
-proposed-updates de la façon habituelle, après l'envoi de l'alerte de sécurité.
-Le mécanisme de mise à jour de sécurité n'est pas un moyen d'introduire des
-changements dans votre paquet qui seraient sinon rejetés de la distribution
-stable, n'essayez donc pas de faire cela, s'il vous plaît.
-<p>
-Examinez et testez autant que possible vos changements. Vérifiez les différences
-avec la version précédente de manière répétée (<prgn>interdiff</prgn> du
-paquet <package>patchutils</package> et <prgn>debdiff</prgn> du paquet
-<package>devscripts</package> sont des outils utiles pour cela, voir <ref
-id="debdiff">).
-<p>
-Assurez-vous de conserver les points suivants à l'esprit :
-
-<list>
-<item>
- Ciblez la bonne distribution dans votre
- fichier <file>debian/changelog</file>. Pour <em>stable</em>, il s'agit de
- <tt>stable-security</tt> et pour <em>testing</em>, c'est
- <tt>testing-security</tt> et pour l'ancienne distribution stable, c'est
- <tt>oldstable-security</tt>. Ne ciblez ni
- <var>distribution</var>-proposed-updates, ni <tt>stable</tt> !
-</item>
-<item>L'envoi devra avoir « urgency=high ».
-</item>
-<item>
- Fournissez des entrées de changelog descriptives et complètes. D'autres
- personnes se baseront dessus pour déterminer si un bogue particulier a été
- corrigé. Incluez toujours une référence externe, de préférence un
- identifiant CVE, pour qu'elle puisse être recoupée. Incluez la même
- information dans le changelog pour <em>unstable</em> pour qu'il soit clair
- que le même bogue a été corrigé car cela est très utile pour vérifier que
- le bogue a été corrigé pour la prochaine version stable. Si aucun
- identifiant CVE n'a encore été assigné, l'équipe de sécurité en demandera
- un pour qu'il puisse être inclus dans le paquet et dans le changelog.
-</item>
-<item>
- Fournissez des entrées de changelog descriptives et complètes. D'autres
- personnes se baseront dessus pour déterminer si un bogue particulier a été
- corrigé. Quand cela est possible, incluez une référence externe, de
- préférence, un identifiant CVE, pour qu'elle puisse être recoupée.
-</item>
-<item>
- Assurez-vous que le numéro de version est correct. Il doit être plus élevé
- que celui du paquet actuel, mais moins que ceux des paquets des versions
- des distributions suivantes. En cas de doute, testez-le avec <tt>dpkg
- --compare-versions</tt>. Soyez attentif à ne pas ré-utiliser un numéro de
- version que vous auriez déjà utilisé pour un précédent envoi.
- Pour <em>testing</em>, il doit y avoir un numéro
- de version supérieur dans <em>unstable</em>. S'il n'y en a pas encore (par
- exemple, si <em>testing</em> et <em>unstable</em> ont la même version),
- vous devez envoyer une nouvelle version vers <em>unstable</em> en premier.
-</item>
-<item>
- Ne faites pas d'envoi de source seul si votre paquet possède un ou
- plusieurs paquets binary-all (n'utilisez pas l'option <tt>-S</tt> de
- <prgn>dpkg-buildpackage</prgn>). L'infrastructure <prgn>buildd</prgn> ne
- construira pas ceux-ci. Ce point s'applique aux envois de paquets normaux
- également.
-</item>
-<item>
- Sauf si la source amont a été envoyée auparavant à security.debian.org (par une
- précédente mise à jour de sécurité), construisez le paquet avec la source
- amont complète (<tt>dpkg-buildpackage -sa</tt>). S'il y a déjà eu un
- précédent envoi à security.debian.org, vous pouvez faire un envoi sans le
- paquet source (<tt>dpkg-buildpackage -sd</tt>).
-</item>
-<item>
- Assurez-vous d'utiliser exactement le même nom <file>*.orig.tar.gz</file>
- que celui utilisé dans l'archive normale, sinon il ne sera pas possible de
- déplacer plus tard le correctif de sécurité dans l'archive principale.
-</item>
-<item>
- Compilez le paquet sur un système
- propre, dont tous les paquets appartiennent à la distribution pour laquelle vous
- construisez le paquet. Si vous n'avez pas un tel système, vous pouvez
- utiliser l'une des machines de debian.org (voir <ref
- id="server-machines">) ou mettez en place un chroot (voir <ref id=
- "pbuilder"> et <ref id="debootstrap">).
-</item>
-</list>
-
- <sect2 id="bug-security-upload">Mettre à jour le paquet corrigé
-<p>
-Vous <em>NE</em> devez <em>PAS</em> envoyer un paquet dans la file d'attente des envois de sécurité
-(oldstable-security, stable-security, etc.)
-sans l'accord préalable de l'équipe de sécurité. Si le paquet ne remplit pas
-exactement les exigences de l'équipe, il causera beaucoup de problèmes, ainsi
-que des délais dans la gestion de l'envoi indésirable.
-<p>
-Vous <em>NE</em> devez <em>PAS</em> envoyer votre correction dans
-<em>proposed-updates</em> sans vous coordonner avec l'équipe de sécurité. Les
-paquets seront copiés de security.debian.org dans le répertoire
-<file>proposed-updates</file> automatiquement. Si un paquet avec le même numéro
-de version ou un numéro plus grand est déjà installé dans l'archive, la mise à
-jour de sécurité sera rejetée par le système d'archive. Ainsi, la distribution
-<em>stable</em> se retrouvera à la place sans la mise à jour de sécurité de ce
-paquet.
-<p>
-Une fois que vous avez créé et testé le nouveau paquet et qu'il a été approuvé
-par l'équipe de sécurité, il doit être envoyé pour être installé dans les
-archives. Pour les envois de sécurité, l'adresse d'envoi est
-<tt>ftp://security.debian.org/pub/SecurityUploadQueue/</tt>.
-
-<p>
-Une fois que l'envoi vers la file d'attente de sécurité a été accepté, le paquet sera
-automatiquement recompilé pour toutes les architectures et stocké pour
-vérification par l'équipe de sécurité.
-
-<p>
-Les envois en attente d'acceptation ou de vérification ne sont accessibles que
-par l'équipe de sécurité. C'est nécessaire car il pourrait y avoir des
-correctifs pour des problèmes de sécurité qui ne peuvent pas encore être
-diffusés.
-
-<p>
-Si une personne de l'équipe de sécurité accepte un paquet, il sera installé sur
-security.debian.org ainsi que dans le répertoire
-<var>distribution</var>-proposed-updates qui convient sur ftp-master ou dans
-l'archive non-US.
-
- <sect id="archive-manip">
- <heading>Déplacer, effacer, changer le nom, adopter et abandonner des paquets
-<p>
-Certaines manipulations de l'archive ne sont pas possibles avec le processus
- de mise à jour automatisé. Elles sont appliquées manuellement par les
- développeurs. Ce chapitre décrit ce qu'il faut faire dans ces situations.
-
- <sect1 id="moving-pkgs">Déplacer des paquets
-<p>
-Il se peut qu'un paquet puisse changer de section. Une nouvelle version d'un paquet
- de la section <tt>non-free</tt> pourrait, par exemple, être distribuée sous
- licence GNU GPL ; dans ce cas, le paquet doit être déplacé dans la section
- <tt>main</tt> ou <tt>contrib</tt><footnote><p>Reportez-vous à la <url
- id="&url-debian-policy;" name="charte Debian"> pour savoir dans quelle section
- un paquet doit être classé.</footnote>.
-<p>
-Si vous avez besoin de modifier la section de l'un de vos paquets, modifiez les
- informations de contrôle du paquet pour le placer dans la section désirée et
- téléchargez à nouveau votre paquet dans l'archive. Reportez-vous à la <url
- id="&url-debian-policy;" name="charte Debian"> pour en savoir plus. Si votre
- nouvelle section est valide, il sera déplacé automatiquement. Si ce n'est pas
- le cas, contactez les responsables ftp pour comprendre ce qui s'est passé.
-<p>
-Si vous avez besoin de modifier la sous-section de l'un de vos paquets
- (<tt>devel</tt> ou <tt>admin</tt> par exemple), la procédure est légèrement
- différente. Modifiez la sous-section dans le fichier de contrôle de votre
- paquet et téléchargez-le. Il vous faudra ensuite demander la modification du
- fichier <em>override</em> comme décrit dans la section <ref
- id="override-file">.
-
-
- <sect1 id="removing-pkgs">Supprimer des paquets
-<p>
-Si, pour une raison ou une autre, vous avez besoin de supprimer un paquet de
- l'archive (disons qu'il s'agit d'une vieille bibliothèque devenue inutile, que
- l'on conservait pour des raisons de compatibilité), il vous faudra envoyer un
- rapport de bogue concernant le pseudo-paquet <tt>ftp.debian.org</tt> et
- demander sa suppression. N'oubliez pas de préciser de quelle distribution le
- paquet doit être supprimé. Normalement, vous ne devriez avoir à supprimer que
- des paquets d'<em>unstable</em> ou de <em>experimental</em>. Les paquets de
- <em>testing</em> ne sont pas supprimés directement. Ils sont plutôt enlevés
- automatiquement après que le paquet a été supprimé d'<em>unstable</em> et
- si aucun paquet de <em>testing</em> n'en dépend.
-<p>
-Vous devez également détailler les raisons justifiant cette demande. Ceci a pour
- but d'éviter les suppressions non désirées et de garder une trace de la raison
- pour laquelle un paquet a été supprimé. Par exemple, vous pouvez fournir le nom
- du paquet qui remplace celui à supprimer.
-<p>
-Vous ne pouvez demander la suppression d'un paquet que si vous en
- êtes le responsable. Si vous voulez supprimer un autre paquet, vous devez
- obtenir l'accord de son responsable.
-<p>
-Si vous ne savez pas bien si un paquet peut être supprimé, demandez l'avis des
- autres développeurs sur la liste &email-debian-devel;. Le programme
- <prgn>apt-cache</prgn> du paquet <package>apt</package> pourra aussi vous être
- utile. La commande <tt>apt-cache showpkg <var>paquet</var> </tt> vous
- indiquera, entre autres, les paquets qui dépendent de <var>paquet</var>.
- Le retrait de paquets orphelins est discuté sur &email-debian-qa;.
-<p>
-Une fois que le paquet a été supprimé, les bogues du paquet doivent être gérés.
- Soit ils sont réattribués à un autre paquet dans le cas où le code actuel a
- évolué en un autre paquet (par exemple, <tt>libfoo12</tt> a été supprimé parce
- que <tt>libfoo13</tt> le remplace) ou ils sont fermés si le logiciel ne fait
- simplement plus partie de Debian.
-
- <sect2>Supprimer des paquets dans <tt>Incoming</tt>
-<p>
-Par le passé, il était possible de supprimer un paquet de <file>Incoming</file>.
- Cependant, ce n'est plus possible depuis la mise en place du nouveau système
- de file d'attente. Il vous faudra télécharger une nouvelle version de votre
- paquet avec un numéro de version plus élevé que celui que vous voulez
- remplacer. Les deux versions seront installées dans l'archive mais seule la
- plus récente sera accessible dans <em>unstable</em> car la précédente sera
- immédiatement remplacée par la nouvelle. Toutefois, si vous testez
- correctement vos paquets, le besoin d'en remplacer un ne devrait pas être
- trop fréquent.
-
- <sect1>Remplacer un paquet ou changer son nom
-<p>
-Si vous vous trompez en nommant un paquet, vous devrez intervenir en deux
- étapes pour changer son nom. D'abord, modifiez
- votre fichier <file>debian/control</file> pour que votre nouveau paquet
- remplace et entre en conflit avec l'ancien paquet que vous voulez remplacer
- (reportez-vous à la <url id="&url-debian-policy;" name="charte Debian"> pour
- les détails). Une fois que votre paquet est installé dans l'archive, faites un
- rapport de bogue concernant le pseudo-paquet <tt>ftp.debian.org</tt> et
- demandez la suppression du paquet mal nommé. N'oubliez pas de réattribuer
- correctement les bogues du paquet en même temps.
-<p>
-D'autres fois, vous pouvez commettre une erreur en construisant le paquet et
-vous désirez le remplacer. La seule façon de faire est d'incrémenter le numéro de
- version et d'envoyer une nouvelle version. L'ancienne version expirera de la
- façon habituelle. Notez que ceci s'applique à chaque partie de votre paquet, y
- compris les sources : si vous désirez remplacer l'archive source amont de
- votre paquet, vous devez l'envoyer avec un numéro de version différent. Une
- possibilité simple est de remplacer <file>foo_1.00.orig.tar.gz</file> par
- <file>foo_1.00+0.orig.tar.gz</file>. Cette restriction donne à chaque fichier
- du site ftp un nom unique, ce qui aide à garantir la consistance dans le réseau
- des miroirs.
-
- <sect1 id="orphaning">Abandonner un paquet
-<p>
-Si vous ne pouvez plus maintenir un paquet, vous devez en informer les autres et
- faire le nécessaire pour qu'il soit marqué <em>abandonné</em> (i.e.
- <em>orphaned</em>). Vous devriez aussi remplacer votre nom par <tt>Debian QA
- Group &orphan-address;</tt> dans le champ <tt>maintainer</tt> du paquet et
- faire un rapport de bogue sur le pseudo-paquet <package>wnpp</package>. Le
- titre de votre rapport de bogue devrait être
- « <tt>O<footnote><p><em>Orphaned</em> : abandonné.</footnote>:
- <var>paquet</var> — <var>courte description</var></tt> » pour
- indiquer que le paquet est abandonné. La gravité du bogue sera
- <em>normale</em> ; si le paquet a une priorité standard ou supérieure,
- elle devrait être <em>importante</em>. Si vous le jugez nécessaire, envoyez une copie à
- &email-debian-devel; en mettant cette adresse dans le champ X-Debbugs-CC: de
- l'en-tête du message. N'utilisez pas le champ CC: car de cette manière le sujet
- du message ne contiendra pas le numéro du bogue.
-<p>
-Si vous avez simplement l'intention de donner le paquet, mais que vous pouvez
-conserver sa maintenance pour le moment, vous devriez à la place soumettre un
-rapport de bogue sur <package>wnpp</package> et l'intituler <tt>RFA: <var>paquet</var> --
-<var>description courte</var></tt>.
-<tt>RFA</tt> veut dire <em>Request For Adoption</em> (demande d'adoption).
- <p>
-Vous pouvez trouver plus d'informations sur les <url id="&url-wnpp;" name="pages
- web WNPP"><footnote><p><em>Work-needing and prospective
- packages</em> : paquets en souffrance et paquets
- souhaités.</footnote>.
-
- <sect1 id="adopting">Adopter un paquet
-<p>
-Une liste des paquets en attente de nouveau responsable est disponible à la page
- <url id="&url-wnpp;" name="paquets en souffrance et paquets souhaités">. Si
- vous voulez prendre en charge un paquet de cette liste, reportez-vous à la page
- mentionnée ci-dessus pour connaître la procédure à suivre.
-<p>
-Prendre un paquet parce qu'il vous semble que celui-ci est négligé n'est pas
- correct — ce serait un détournement de paquet. Vous pouvez prendre
- contact avec le responsable actuel et lui demander si vous pouvez prendre en
- charge ce paquet. Si vous avez le sentiment qu'un responsable est parti sans
- prévenir depuis un moment, veuillez vous reporter à <ref id="mia-qa">).
-<p>
-Généralement, vous ne pouvez pas adopter un paquet sans l'accord du responsable
-actuel. Même s'il vous ignore, ce n'est pas une raison pour le faire. Les
-plaintes à propos des responsables devraient être portées sur la liste de
-diffusion des développeurs. Si la discussion ne se termine pas par une
-conclusion positive et que le problème est de nature technique, considérez de
-porter le cas à l'attention du comité technique (voir la <url name="page web du
-comité technique" id="&url-tech-ctte;"> pour plus d'information).
-<p>
-Si vous reprenez un vieux paquet, vous voudrez sûrement que le système de suivi
- des bogues indique que vous êtes le responsable du paquet. Cela se produira
- automatiquement une fois que vous aurez installé une nouvelle version du paquet
- dans l'archive avec le champ <tt>Maintainer</tt> à jour. Cela peut prendre
- quelques heures après le téléchargement. Si vous pensez ne pas avoir de mise à
- jour à faire pour un moment, vous pouvez utiliser le <ref
- id="pkg-tracking-system"> pour recevoir les rapports de bogue. Cependant,
- assurez-vous que cela ne pose aucun problème à l'ancien responsable de
- continuer à recevoir les bogues durant ce temps.
-
- <sect id="porting">Le portage
-<p>
-Debian accepte un nombre croissant d'architectures. Même si vous n'êtes pas un
- porteur et même si vous n'utilisez qu'une architecture, il est de votre
- responsabilité de développeur d'être attentif aux questions de
- portabilité. C'est pourquoi il est important que vous lisiez ce chapitre
- même si vous n'êtes pas un porteur.
-<p>
-Porter un paquet consiste à faire un paquet binaire pour des architectures
- différentes de celle du paquet binaire fait par le responsable du paquet.
- C'est une activité remarquable et essentielle. En fait, les porteurs sont
- à l'origine de la plupart des compilations de paquets Debian. Pour un
- paquet binaire <em>i386</em>, par exemple, il faut compter une
- recompilation pour chaque autre architecture, soit un total de
- &number-of-arches; recompilations.
-
-
- <sect1 id="kind-to-porters">Être courtois avec les porteurs
-<p>
-Les porteurs ont une tâche remarquable et difficile car ils doivent gérer un
- grand nombre de paquets. Idéalement, tout paquet source devrait compiler sans
- modification. Malheureusement, c'est rarement le cas. Cette section contient
- une liste d'erreurs commises régulièrement par les responsables Debian —
- problèmes courants qui bloquent souvent les porteurs et compliquent inutilement
- leur travail.
-<p>
-Ici, la première et la plus importante chose est de répondre rapidement aux rapports de bogues et
- remarques soulevées par les porteurs. Traitez-les courtoisement, comme s'ils
- étaient co-responsables de vos paquets (ce qu'ils sont d'une certaine manière).
- Merci pour votre indulgence envers des rapports de bogue succincts ou peu
- clairs ; faites de votre mieux pour éliminer le problème.
-<p>
-Les problèmes les plus couramment rencontrés par les porteurs sont causés par
- des erreurs de mise en paquet dans le paquet source. Voici un
- pense-bête pour les choses auxquelles vous devez être attentif :
-<enumlist>
- <item>
- Vérifiez que les champs <tt>Build-Depends</tt> et
- <tt>Build-Depends-Indep</tt> du fichier <file>debian/control</file> sont
- corrects. Le meilleur moyen de le vérifier est d'utiliser le paquet
- <package>debootstrap</package> pour créer un environnement
- <em>unstable</em> <em>chrooté</em> (voir <ref id="debootstrap">). Dans
- cet environnement <em>chrooté</em>, il faudra installer le paquet
- <package>build-essential</package> et tous les paquets mentionnés dans
- les champs <tt>Build-Depends</tt> et <tt>Build-Depends-Indep</tt>.
- Ensuite, vous essayerez de fabriquer votre paquet dans cet
- environnement. Ces étapes peuvent être automatisées en utilisant le
- programme <prgn>pbuilder</prgn> qui est fourni par le paquet de même
- nom (voir <ref id="pbuilder">).
- <p>
- Si vous n'arrivez pas à installer un environnement <em>chrooté</em>,
- <prgn>dpkg-depcheck</prgn> pourra peut-être vous aider (voir <ref
- id="dpkg-depcheck">).
- <p>
- Consultez la <url id="&url-debian-policy;" name="charte Debian"> pour en
- savoir plus sur les dépendances de fabrication.
- </item>
- <item>
- Ne choisissez pas d'autres valeurs que <em>all</em> ou <em>any</em> pour
- le champ architecture sans avoir de bonnes raisons pour le faire. Trop
- souvent, les développeurs ne respectent pas les instructions de la <url
- id="&url-debian-policy;" name="charte Debian">. Choisir la valeur
- « i386 » est la plupart du temps incorrect.
- </item>
- <item>
- Vérifiez que votre paquet source est bon. Faites <tt>dpkg-source -x
- <var>paquet</var>.dsc</tt> pour vous assurer que le paquet se
- décompresse correctement. En utilisant le résultat de ce test,
- construisez votre paquet binaire à l'aide de la commande
- <prgn>dpkg-buildpackage</prgn>.
- </item>
- <item>
- Vérifiez que les fichiers <file>debian/files</file> et
- <file>debian/substvars</file> ne sont pas dans votre paquet source. Ils
- doivent être effacés par la cible <em>clean</em> de
- <file>debian/rules</file>.
- </item>
- <item>
- Assurez-vous que vous ne vous appuyez pas sur des éléments de
- configuration ou des logiciels installés ou modifiés localement. Par
- exemple, vous ne devriez jamais appeler des programmes du répertoire
- <file>/usr/local/bin</file> ou de répertoires équivalents. Essayez de ne
- pas vous appuyer sur des logiciels configurés de manière spéciale.
- Essayez de construire votre paquet sur une autre machine, même s'il
- s'agit de la même architecture.
- </item>
- <item>
- Ne vous appuyez pas sur une installation préexistante de votre paquet
- (un sous-cas de la remarque précédente).
- </item>
- <item>
- Si possible, ne vous appuyez pas sur une particularité présente dans un
- compilateur précis ou dans une certaine version d'un compilateur. Si
- vous ne pouvez pas faire autrement, assurez-vous que les dépendances de
- fabrication reflètent bien cette restriction. Dans ce cas, vous cherchez
- sûrement les problèmes car quelques architectures pourraient choisir un
- compilateur différent.
- </item>
- <item>
- Vérifiez que votre fichier <file>debian/rules</file> distingue les
- cibles <em>binary-arch</em> et <em>binary-indep</em> comme l'exige la
- charte Debian. Vérifiez que ces cibles sont indépendantes l'une de
- l'autre, c'est-à-dire, qu'il n'est pas nécessaire d'invoquer l'une de
- ces cibles avant d'invoquer l'autre. Pour vérifier cela, essayez
- d'exécuter <tt>dpkg-buildpackage -B</tt>.
- </item>
-</enumlist>
-
-
- <sect1 id="porter-guidelines">Instructions pour les mises à jour des
- porteurs
-<p>
-Si le paquet se construit tel quel sur l'architecture que vous visez, vous avez
- de la chance et votre travail est facile. Cette section s'applique dans ce
- cas ; elle décrit comment construire et installer correctement votre
- paquet binaire dans l'archive Debian. Si vous devez modifier le paquet pour le
- rendre compilable sur votre architecture cible vous devez faire une mise à jour
- des sources, consultez la section <ref id="nmu-guidelines">.
-<p>
-Pour un envoi de portage, ne faites pas de changement dans les sources. Vous
- n'avez pas besoin de modifier les fichiers du paquet source (cela inclut le
- fichier <file>debian/changelog</file>).
-<p>
-La manière d'invoquer <prgn>dpkg-buildpackage</prgn> est la suivante :
- <tt>dpkg-buildpackage -B -m<var>adresse-porteur</var></tt>. Bien sûr, remplacez
- <var>adresse-porteur</var> par votre adresse électronique. Cette commande
- construira les parties du paquet qui dépendent de l'architecture, en utilisant
- la cible <em>binary-arch</em> de <file>debian/rules</file>.
-<p>
-Si vous travaillez sur une machine Debian pour vos efforts de portage et que
-vous devez signer votre envoi localement pour son acceptation dans l'archive,
-vous pouvez exécuter <prgn>debsign</prgn> sur votre fichier
-<file>.changes</file> pour qu'il soit signé de manière commode ou utilisez le
-mode de signature à distance de <prgn>dpkg-sig</prgn>.
-
- <sect2 id="binary-only-nmu">
- Mises à jour indépendantes binaires ou recompilations
-<p>
-Parfois, l'envoi du portage initial pose problème car l'environnement dans lequel
- le paquet a été construit n'était pas bon (bibliothèques plus à jour ou
- obsolètes, mauvais compilateur, etc.). Il se peut que vous ayez à le recompiler
- dans un environnement mis à jour. Cependant, dans ce cas, vous devez changer
- le numéro de version pour que les mauvais anciens paquets soient remplacés dans
- l'archive Debian (<prgn>katie</prgn> refuse d'installer de nouveaux paquets
- s'ils n'ont pas un numéro de version supérieur à celui actuellement
- disponible).
-<p>
-Vous devez vous assurez que votre mise à jour indépendante binaire ne rend pas
- le paquet non installable. Cela peut arriver si un paquet source génère des
- paquets dépendants et indépendants de l'architecture qui dépendent
- les uns des autres <em>via</em> $(Source-Version).
-
-<p>
- Malgré les modifications nécessaires du changelog, ce type de mise
- à jour reste une mise à jour indépendante binaire — il n'est pas
- nécessaire de reconsidérer le statut des paquets binaires des autres
- architectures pour les marquer périmés ou à recompiler.
-<p>
-Ces recompilations nécessitent des numéros de version « magiques »
- pour que le système de maintenance de l'archive comprennent que, bien qu'il y
- ait une nouvelle version, il n'y a pas eu de modification des sources. Si vous
- ne faites pas cela correctement, les administrateurs de l'archive rejetteront
- votre mise à jour (car il n'y aura pas de code source associé).
-<p>
-Cette « magie » associée à une mise à jour par recompilation est déclenchée en
- utilisant un troisième nombre dans la partie debian du numéro de version. Si,
- par exemple, la dernière version du paquet que vous recompilez était
- « 2.9-3 », votre mise à jour portera le numéro
- « 2.9-3.0.1 ». Si cette version était « 3.4-2.1 » votre
- mise à jour portera le numéro « 3.4-2.1.1 ».
-<p>
-De manière similaire aux envois du porteur initial, la façon correcte d'invoquer
- <prgn>dpkg-buildpackage</prgn> est <tt>dpkg-buildpackage -B</tt> pour ne
- construire que les parties dépendant de l'architecture du paquet.
-
-
- <sect2 id="source-nmu-when-porter">
- Quand faire une mise à jour indépendante source pour un portage ?
-<p>
-Les porteurs qui font des mises à jour indépendantes sources suivent
- généralement les instructions de la section <ref id="nmu"> tout comme les
- non-porteurs. Les délais d'attente sont cependant plus courts car les
- porteurs doivent manipuler un grand nombre de paquets. À nouveau, la
- situation diffère selon la distribution visée. Elle varie également selon que
- l'architecture est candidate pour inclusion dans la prochaine version
- stable ; les responsables de diffusion décident et annoncent quelles
- architectures sont candidates.
-<p>
-Si vous êtes porteur et faites une mise à jour pour <em>unstable</em>, les
- instructions précédentes sont applicables à deux différences près. Tout
- d'abord, le temps d'attente raisonnable — délai entre le moment où vous
- envoyez un rapport au système de suivi des bogues et le moment où vous pouvez
- faire une mise à jour indépendante <em>(NMU)</em> — est de sept jours.
- Ce délai peut être raccourci si le problème est crucial et met l'effort de
- portage en difficulté : c'est à la discrétion de l'équipe de portage.
- (Souvenez-vous, il ne s'agit pas d'un règlement, mais de recommandations
- communément acceptées). Pour les envois de <em>stable</em> ou
- <em>testing</em>, veuillez tout d'abord vous coordonner avec l'équipe de
- diffusion appropriée.
-
-<p>
-Deuxième différence, les porteurs qui font des mises à jour indépendantes
- sources doivent choisir une gravité <em>sérieuse</em> (i.e. <em>serious</em>)
- ou supérieure quand ils envoient leur rapport au système de suivi des bogues.
- Ceci assure qu'un paquet source unique permet de produire un paquet binaire
- pour chaque architecture supportée au moment de la sortie de la distribution.
- Il est très important d'avoir un paquet source et un paquet binaire pour
- toutes les architectures pour être conforme à plusieurs licences.
-<p>
-Les porteurs doivent éviter d'implémenter des contournements pour des bogues de
- l'environnement de compilation, du noyau ou de la libc. Quelques fois, ces
- contournements sont inévitables. Si vous devez faire quelque chose de ce
- genre, marquez proprement vos modifications avec des <tt>#ifdef</tt> et
- documentez votre contournement pour que l'on sache le retirer une fois que le
- problème aura disparu.
-<p>
-Les porteurs peuvent aussi avoir une adresse où ils publient le résultat de leur
- travail pendant le délai d'attente. Ainsi, d'autres personnes peuvent
- bénéficier du travail du porteur même pendant ce délai. Bien sûr, ces
- adresses n'ont rien d'officiel, alors soyez sur vos gardes si vous les
- utilisez.
-
-
- <sect1 id="porter-automation">
- <heading>Infrastructure de portage et automatisation</heading>
- <p>
-Il existe une infrastructure et plusieurs outils pour faciliter l'automatisation
-du portage des paquets. Cette section contient un bref aperçu de cette
-automatisation et du portage de ces outils ; veuillez vous reporter à la
-documentation des paquets ou les références pour une information complète.</p>
-
- <sect2>
- <heading>Listes de diffusion et pages web</heading>
- <p>
-Les pages web contenant l'état de chaque portage peuvent être trouvées à <url
-id="&url-debian-ports;">.
- <p>
-Chaque portage de Debian possède sa propre liste de diffusion. La liste des
-listes de diffusion de portage peut être trouvée à <url
-id="&url-debian-port-lists;">. Ces listes sont utilisées pour coordonner les
-porteurs et pour mettre en relation les utilisateurs d'un portage donné avec les
-porteurs.</p>
- </sect2>
-
- <sect2>
- <heading>Outils pour les porteurs</heading>
-<p>
-Les descriptions de plusieurs outils de portage peuvent être trouvées dans les
-<ref id="tools-porting">.</p>
-
-
- <sect2 id="buildd">
- <heading><package>buildd</package></heading>
-<p>
-Le système <package>buildd</package> est un système distribué pour la
- compilation d'une distribution. Il est habituellement utilisé en conjonction
- avec des automates de compilation ; ce sont des machines
- « esclaves » qui récupèrent des paquets sources et tentent de les
- compiler. Il est aussi possible d'interagir par courrier électronique avec ce
- système. Cette interface est utilisée par les porteurs pour récupérer un
- paquet source (en général, un paquet qui ne peut être compilé
- automatiquement) et travailler dessus.
-<p>
-<package>buildd</package> n'est pas disponible sous forme de paquet ;
- pourtant, la plupart des équipes de porteurs l'utilisent aujourd'hui ou ont
- prévu de l'utiliser bientôt. L'outil de construction automatisé réel est dans
- le paquet <package>sbuild</package>, voir la description dans <ref
- id="sbuild">. Le système <package>buildd</package> regroupe également un
- ensemble de composants très utiles, continuellement utilisés, mais non encore
- mis en paquet, tels que <prgn>andrea</prgn> et <prgn>wanna-build</prgn>.
-<p>
-Une partie des informations produites par <package>buildd</package>
- — utiles pour les porteurs — est disponible sur la
- toile à l'adresse <url id="&url-buildd;">. Ces informations
- incluent les résultats produits toutes les nuits par
- <prgn>andrea</prgn> (dépendances des sources) et
- <prgn>quinn-diff</prgn> (paquets à recompiler).
-<p>
-Nous sommes très fiers de ce système car il a de nombreux usages potentiels. Des
- groupes de développeurs indépendants peuvent utiliser ce système pour créer
- différentes saveurs de Debian — qui peuvent être ou ne pas être
- intéressantes pour tous (par exemple, une version de Debian compilée avec des
- vérifications relatives à <prgn>gcc</prgn>). Ce système nous permettra aussi
- de recompiler rapidement toute une distribution.
-</sect2>
-
- <sect id="nmu">Mise à jour indépendante
-<p>
-Dans certaines circonstances, il est nécessaire qu'une personne autre que le
- responsable d'un paquet fasse une mise à jour de ce paquet. Ce type de
- mise à jour est désigné en anglais par l'expression <em>non-maintainer
- upload (NMU)</em>. Dans le présent document, nous traduisons librement
- cette expression par « mise à jour indépendante ».
-<p>
-Cette section ne traite que des mises à jour indépendantes de source, c.-à-d.,
- les mises à jour qui envoient une nouvelle version d'un paquet. Pour les
- mises à jour indépendantes par des porteurs ou des membres de la QA,
- veuillez consulter <ref id="binary-only-nmu">. Si un buildd construit et
- envoie un paquet, cela est également à strictement parler une NMU binaire.
- Veuillez consulter <ref id="buildd"> pour plus d'informations.
-<p>
-La raison principale pour laquelle une mise à jour indépendante est réalisée est
- quand un développeur a besoin de corriger des paquets d'un autre
- développeur pour résoudre des problèmes sérieux ou des bogues paralysants
- ou quand le responsable d'un paquet ne peut pas
- fournir une correction dans un délai raisonnable.
-<p>
-Tout d'abord, il est capital que ces mises à jour indépendantes soient aussi peu
- intrusives que possible. Ne faites pas de ménage, ne modifiez pas le nom des
- modules ou des fichiers, ne déplacez pas les répertoires ; plus
- généralement, ne corrigez pas ce qui n'est pas cassé. Faites un correctif aussi
- petit que possible. Si certaines choses froissent votre sens de l'esthétique,
- parlez-en au responsable du paquet, au responsable amont ou soumettez un
- rapport de bogue. Quoiqu'il en soit, les changements esthétiques <em>ne doivent
- pas</em> être effectués lors d'une mise à jour indépendante.
-
-<p>
-Et souvenez-vous du Serment d'Hippocrate « Par dessus tout, ne pas
-faire de mal ». Il est préférable qu'un paquet ait un bogue ouvert grave
-plutôt qu'un correctif non fonctionnel soit appliqué et que le bogue devienne
-caché, mais toujours non résolu.
-
- <sect1 id="nmu-guidelines">Comment faire une mise à jour indépendante ?
- <p>
-Les mises à jour indépendantes qui corrigent des bogues de gravité importante,
-sérieuse et plus élevée sont encouragées et acceptées. Vous devriez vous
-efforcer de contacter le responsable actuel du paquet : il est peut-être
-sur le point d'envoyer un correctif pour le problème ou il a peut-être une
-meilleure solution.
- <p>
-Les mises à jour indépendantes doivent être réalisées pour assister un
-responsable de paquet à résoudre des bogues. Les responsables devraient être
-reconnaissants pour cette aide et les personnes faisant la mise à jour
-indépendante devraient respecter les décisions du responsable et tenter
-d'aider personnellement le responsable dans son travail.
- <p>
-Une mise à jour indépendante devrait suivre toutes les conventions décrites dans
-cette section. Pour un envoi vers <em>testing</em> ou <em>unstable</em>, l'ordre
-suivant des étapes est recommandé :
- <p>
-
-<list>
-<item>Vérifiez que les bogues du paquet qui devraient être corrigés par la
- mise à jour indépendante sont bien référencés dans le système de suivi des
- bogues. S'ils n'y sont pas, faites des rapports de bogue
- immédiatement.
-<item>Attendez la réponse du responsable quelques jours. Si vous n'obtenez
- aucune réponse, vous pouvez l'aider en lui envoyant le correctif qui
- corrige le bogue. N'oubliez pas de marquer le bogue avec le mot-clé
- « patch ».
-<item>Patientez quelques jours. Si vous n'avez toujours aucune réponse du
- responsable, envoyez-lui un courrier annonçant votre intention
- d'effectuer une mise à jour indépendante du paquet. Préparez la NMU comme
- décrit dans cette section et testez-la soigneusement sur votre
- machine (cf. <ref id="sanitycheck">). Re-vérifiez que votre correctif
- n'a aucun effet de bord inattendu. Assurez-vous que votre correctif est
- aussi minimaliste et non intrusif que possible.
-<item>Envoyez votre paquet à incoming dans <file>DELAYED/7-day</file> (cf.
- <ref id="delayed-incoming">), envoyez le correctif final au responsable
- par le BTS et expliquez-lui qu'il a 7 jours pour réagir s'il veut annuler
- la NMU.
-<item>Suivez ce qui se passe, vous êtes responsable pour tout bogue que vous
- auriez introduit avec votre NMU. Vous devriez probablement utiliser le
- <ref id="pkg-tracking-system"> (PTS) pour vous tenir informé de l'état du
- paquet après votre NMU.
-</list>
-<p>
-Parfois, le responsable de version ou un groupe organisé de
- développeurs peut annoncer une certaine période de temps au cours de laquelle
- les règles de mise à jour indépendante seront plus souples. Ceci implique
- habituellement une période plus courte d'attente avant d'envoyer des
- correctifs et une période de délai plus courte. Il est important de noter que,
- même au cours de ces « chasses aux bogues », la personne
- désirant faire la mise à jour indépendante doit remplir des bogues et
- contacter en premier le développeur, et ensuite seulement passer à
- l'action.
-
-Veuillez vous reporter à <ref id="qa-bsp"> pour des détails.
-<p>
-Pour la distribution <em>testing</em>, les règles peuvent être changées par les
-responsables de diffusion. Veuillez porter une attention spéciale au fait que le
-moyen habituel pour un paquet d'entrer dans <em>testing</em> est de passer par
-<em>unstable</em>.
-<p>
-Pour la distribution <em>stable</em>, veuillez y apporter une attention
-supplémentaire. Bien sûr, les responsables de version peuvent également modifier
-les règles ici. Veuillez vérifier avant l'envoi que tous vos changements sont
-acceptables pour inclusion dans la prochaine version stable par le responsable
-de diffusion.
-<p>
-Quand un bogue de sécurité est détecté, l'équipe de sécurité peut effectuer une
-mise à jour indépendante en utilisant ses propres règles. Veuillez vous référer
-à <ref id="bug-security"> pour plus d'informations.
-<p>
-Pour les différences pour les mises à jour indépendantes par les porteurs,
-veuillez voir <ref id="source-nmu-when-porter">.
-<p>
-Bien sûr, il est toujours possible de s'accorder avec un responsable pour des
-règles spéciales (comme quand le responsable demande « merci d'envoyer le
-correctif directement pour moi et pas de diff nécessaire »).
-
- <sect1 id="nmu-version">Numéro de version pour les mises à jour
- indépendantes
-<p>
-Chaque fois que vous modifiez un paquet, le numéro de version de ce paquet doit
- changer, même pour la plus triviale des modifications. Notre système de
- gestion de paquets s'appuie sur ces numéros de version.
-<p>
-Si vous faites une mise à jour indépendante <em>(NMU)</em>, vous devez ajouter
- un numéro de version mineur à la partie <var>révision-debian</var> du numéro
- de version (la partie qui suit le dernier trait d'union). Ce numéro
- supplémentaire débutera à « 1 ». Prenons pour exemple le paquet
- « foo » qui porte le numéro de version 1.1-3. Dans l'archive, le
- fichier de contrôle du paquet source serait <file>foo_1.1-3.dsc</file>. La
- version amont est « 1.1 » et la révision Debian est
- « 3 ». La mise à jour indépendante suivante ajouterait le numéro de
- version mineur « .1 » au numéro de révision Debian ; le nouveau
- fichier de contrôle du paquet source serait alors
- <file>foo_1.1-3.1.dsc</file>.
-<p>
-Le numéro de révision mineur est nécessaire pour éviter de prendre un numéro de
- version au responsable officiel du paquet, ce qui pourrait perturber son
- travail. Cela a aussi l'avantage de montrer clairement que le paquet n'a pas
- été livré par le responsable officiel.
-<p>
-S'il n'y a pas de partie <var>révision-debian</var> dans le numéro de version du
- paquet, il faut en créer une en démarrant à « 0.1 ». S'il est
- absolument nécessaire qu'une personne qui n'est pas responsable d'un paquet
- fasse une livraison basée sur une nouvelle version amont, cette personne doit
- choisir « 0.1 » comme numéro de révision Debian. Le mainteneur du
- paquet doit, lui, démarrer sa numérotation à « 1 ».
-<p>
-Si vous envoyez un paquet vers <em>testing</em> ou <em>stable</em>, vous devrez
- parfois créer une branche (« fork ») dans l'arbre de numéro des version. Pour cela, vous
- pouvez utiliser des numéros de version comme 1.1-3sarge0.1.
-
-
- <sect1 id="nmu-changelog">
- <heading>Les mises à jour indépendantes sources doivent être
- mentionnées dans le fichier changelog</heading>
-<p>
-Une personne qui fait une mise à jour indépendante source doit ajouter une
- entrée dans le fichier <file>changelog</file> qui indique les bogues corrigés
- et qui précise pourquoi cette mise à jour était nécessaire. Cette entrée
- comportera l'adresse de la personne ayant fait la mise à jour ainsi que la
- version livrée.
-<p>
-Par convention, dans le cas d'une mise à jour indépendante source
- <em>(NMU)</em>, l'entrée du fichier changelog débute par la ligne :
-
-<example>
+ <item>
+ <p>
+ Vérifiez que les fichiers <file>debian/files</file> et
+ <file>debian/substvars</file> ne sont pas dans votre paquet
+ source. Ils doivent être effacés par la cible <em>clean</em> de
+ <file>debian/rules</file>.
+ </p>
+ </item>
+ <item>
+ <p>
+ Assurez-vous que vous ne vous appuyez pas sur des éléments de
+ configuration ou des logiciels installés ou modifiés
+ localement. Par exemple, vous ne devriez jamais appeler des
+ programmes du répertoire <file>/usr/local/bin</file> ou de
+ répertoires équivalents. Essayez de ne pas vous appuyer sur des
+ logiciels configurés de manière spéciale. Essayez de construire
+ votre paquet sur une autre machine, même s'il s'agit de la même
+ architecture.
+ </p>
+ </item>
+ <item>
+ <p>
+ Ne vous appuyez pas sur une installation préexistante de votre
+ paquet (un sous-cas de la remarque précédente).
+ </p>
+ </item>
+ <item>
+ <p>
+ Si possible, ne vous appuyez pas sur une particularité présente
+ dans un compilateur précis ou dans une certaine version d'un
+ compilateur. Si vous ne pouvez pas faire autrement, assurez-vous
+ que les dépendances de fabrication reflètent bien cette
+ restriction. Dans ce cas, vous cherchez sûrement les problèmes car
+ quelques architectures pourraient choisir un compilateur différent.
+ </p>
+ </item>
+ <item>
+ <p>
+ Vérifiez que votre fichier <file>debian/rules</file> distingue les
+ cibles <em>binary-arch</em> et <em>binary-indep</em> comme l'exige
+ la charte Debian. Vérifiez que ces cibles sont indépendantes l'une
+ de l'autre, c'est-à-dire, qu'il n'est pas nécessaire d'invoquer
+ l'une de ces cibles avant d'invoquer l'autre. Pour vérifier cela,
+ essayez d'exécuter <tt>dpkg-buildpackage -B</tt>.
+ </p>
+ </item>
+ </enumlist>
+ </p>
+ </sect1>
+ <sect1 id="porter-guidelines">
+ <heading>
+ Instructions pour les mises à jour des porteurs
+ </heading>
+ <p>
+ Si le paquet se construit tel quel sur l'architecture que vous visez,
+ vous avez de la chance et votre travail est facile. Cette section
+ s'applique dans ce cas ; elle décrit comment construire et
+ installer correctement votre paquet binaire dans l'archive Debian. Si
+ vous devez modifier le paquet pour le rendre compilable sur votre
+ architecture cible vous devez faire une mise à jour des sources,
+ consultez la section <ref id="nmu-guidelines">.
+ </p>
+ <p>
+ Pour un envoi de portage, ne faites pas de changement dans les
+ sources. Vous n'avez pas besoin de modifier les fichiers du paquet
+ source (cela inclut le fichier <file>debian/changelog</file>).
+ </p>
+ <p>
+ La manière d'invoquer <prgn>dpkg-buildpackage</prgn> est la
+ suivante : <tt>dpkg-buildpackage -B
+ -m<var>adresse-porteur</var></tt>. Bien sûr, remplacez
+ <var>adresse-porteur</var> par votre adresse électronique. Cette
+ commande construira les parties du paquet qui dépendent de
+ l'architecture, en utilisant la cible <em>binary-arch</em> de
+ <file>debian/rules</file>.
+ </p>
+ <p>
+ Si vous travaillez sur une machine Debian pour vos efforts de portage
+ et que vous devez signer votre envoi localement pour son acceptation
+ dans l'archive, vous pouvez exécuter <prgn>debsign</prgn> sur votre
+ fichier <file>.changes</file> pour qu'il soit signé de manière commode
+ ou utilisez le mode de signature à distance de <prgn>dpkg-sig</prgn>.
+ </p>
+ <sect2 id="binary-only-nmu">
+ <heading>
+ Mises à jour indépendantes binaires ou recompilations
+ </heading>
+ <p>
+ Parfois, l'envoi du portage initial pose problème car l'environnement
+ dans lequel le paquet a été construit n'était pas bon (bibliothèques
+ plus à jour ou obsolètes, mauvais compilateur, etc.). Il se peut que
+ vous ayez à le recompiler dans un environnement mis à
+ jour. Cependant, dans ce cas, vous devez changer le numéro de version
+ pour que les mauvais anciens paquets soient remplacés dans l'archive
+ Debian (<prgn>katie</prgn> refuse d'installer de nouveaux paquets
+ s'ils n'ont pas un numéro de version supérieur à celui actuellement
+ disponible).
+ </p>
+ <p>
+ Vous devez vous assurer que votre mise à jour indépendante binaire ne
+ rend pas le paquet non installable. Cela peut arriver si un paquet
+ source génère des paquets dépendants et indépendants de
+ l'architecture qui dépendent les uns des autres <em>via</em>
+ $(Source-Version).
+ </p>
+ <p>
+ Malgré les modifications nécessaires du changelog, ce type de mise à
+ jour reste une mise à jour indépendante binaire — il n'est
+ pas nécessaire de reconsidérer le statut des paquets binaires des
+ autres architectures pour les marquer périmés ou à recompiler.
+ </p>
+ <p>
+ Ces recompilations nécessitent des numéros de version
+ « magiques » pour que le système de maintenance de
+ l'archive comprenne que, bien qu'il y ait une nouvelle version, il
+ n'y a pas eu de modification des sources. Si vous ne faites pas cela
+ correctement, les administrateurs de l'archive rejetteront votre mise
+ à jour (car il n'y aura pas de code source associé).
+ </p>
+ <p>
+ La « magie » d'une mise à jour indépendante par
+ recompilation uniquement est déclenchée par l'utilisation d'un
+ suffixe ajouté au numéro de version du paquet de la forme
+ b<numéro>. Par exemple, si la dernière version que vous avez
+ recompilée était la version 2.9.3, votre mise à jour indépendante
+ aura le numéro de version 2.9-3+b1. Si la dernière version était
+ 3.4+b1 (i.e. un paquet natif avec une précédente mise à jour
+ indépendante par recompilation), votre mise à jour indépendant aura
+ le numéro de version 3.4+b2. <footnote><p>Par le passé, de telles
+ mises à jour indépendantes utilisaient le numéro de troisième niveau
+ de la partie Debian de la révision pour dénoter l'état de
+ recompilation uniquement ; cependant, cette syntaxe était
+ ambigüe pour les paquets natifs et ne permettait pas un ordre correct
+ des mises à jour indépendantes par recompilation uniquement, des
+ mises à jour indépendantes de source et des mises à jour
+ indépendantes de sécurité sur le même paquet et elle a donc été
+ abandonnée en faveur de cette nouvelle syntaxe.</p></footnote>
+ </p>
+ <p>
+ De manière similaire aux envois du porteur initial, la façon correcte
+ d'invoquer <prgn>dpkg-buildpackage</prgn> est <tt>dpkg-buildpackage
+ -B</tt> pour ne construire que les parties dépendant de
+ l'architecture du paquet.
+ </p>
+ </sect2>
+ <sect2 id="source-nmu-when-porter">
+ <heading>
+ Quand faire une mise à jour indépendante source pour un
+ portage ?
+ </heading>
+ <p>
+ Les porteurs qui font des mises à jour indépendantes sources suivent
+ généralement les instructions de la section <ref id="nmu"> tout comme
+ les non-porteurs. Les délais d'attente sont cependant plus courts car
+ les porteurs doivent manipuler un grand nombre de paquets. À nouveau,
+ la situation diffère selon la distribution visée. Elle varie
+ également selon que l'architecture est candidate pour inclusion dans
+ la prochaine version stable ; les responsables de publication
+ décident et annoncent quelles architectures sont candidates.
+ </p>
+ <p>
+ Si vous êtes porteur et faites une mise à jour pour
+ <em>unstable</em>, les instructions précédentes sont applicables à
+ deux différences près. Tout d'abord, le temps d'attente raisonnable
+ — délai entre le moment où vous envoyez un rapport au
+ système de suivi des bogues et le moment où vous pouvez faire une
+ mise à jour indépendante <em>(NMU)</em> — est de sept
+ jours. Ce délai peut être raccourci si le problème est crucial et met
+ l'effort de portage en difficulté : c'est à la discrétion de l'équipe
+ de portage. (Souvenez-vous, il ne s'agit pas d'un règlement, mais de
+ recommandations communément acceptées). Pour les envois de
+ <em>stable</em> ou <em>testing</em>, veuillez tout d'abord vous
+ coordonner avec l'équipe de publication appropriée.
+ </p>
+ <p>
+ Deuxième différence, les porteurs qui font des mises à jour
+ indépendantes sources doivent choisir une gravité <em>sérieuse</em>
+ (i.e. <em>serious</em>) ou supérieure quand ils envoient leur rapport
+ au système de suivi des bogues. Ceci assure qu'un paquet source
+ unique permet de produire un paquet binaire pour chaque architecture
+ supportée au moment de la sortie de la distribution. Il est très
+ important d'avoir un paquet source et un paquet binaire pour toutes
+ les architectures pour être conforme à plusieurs licences.
+ </p>
+ <p>
+ Les porteurs doivent éviter d'implémenter des contournements pour des
+ bogues de l'environnement de compilation, du noyau ou de la
+ libc. Quelques fois, ces contournements sont inévitables. Si vous
+ devez faire quelque chose de ce genre, marquez proprement vos
+ modifications avec des <tt>#ifdef</tt> et documentez votre
+ contournement pour que l'on sache le retirer une fois que le problème
+ aura disparu.
+ </p>
+ <p>
+ Les porteurs peuvent aussi avoir une adresse où ils publient le
+ résultat de leur travail pendant le délai d'attente. Ainsi, d'autres
+ personnes peuvent bénéficier du travail du porteur même pendant ce
+ délai. Bien sûr, ces adresses n'ont rien d'officiel, alors soyez sur
+ vos gardes si vous les utilisez.
+ </p>
+ </sect2>
+ </sect1>
+ <sect1 id="porter-automation">
+ <heading>
+ Infrastructure de portage et automatisation
+ </heading>
+ <p>
+ Il existe une infrastructure et plusieurs outils pour faciliter
+ l'automatisation du portage des paquets. Cette section contient un
+ bref aperçu de cette automatisation et du portage de ces outils ;
+ veuillez vous reporter à la documentation des paquets ou les
+ références pour une information complète.
+ </p>
+ <sect2>
+ <heading>
+ Listes de diffusion et pages web
+ </heading>
+ <p>
+ Les pages web contenant l'état de chaque portage peuvent être
+ trouvées à <url id="&url-debian-ports;">.
+ </p>
+ <p>
+ Chaque portage de Debian possède sa propre liste de diffusion. La
+ liste des listes de diffusion de portage peut être trouvée à <url
+ id="&url-debian-port-lists;">. Ces listes sont utilisées pour
+ coordonner les porteurs et pour mettre en relation les utilisateurs
+ d'un portage donné avec les porteurs.
+ </p>
+ </sect2>
+ <sect2>
+ <heading>
+ Outils pour les porteurs
+ </heading>
+ <p>
+ Les descriptions de plusieurs outils de portage peuvent être trouvées
+ dans les <ref id="tools-porting">.
+ </p>
+ </sect2>
+ <sect2 id="buildd">
+ <heading>
+ <package>buildd</package>
+ </heading>
+ <p>
+ Le système <package>buildd</package> est un système distribué pour la
+ compilation d'une distribution. Il est habituellement utilisé en
+ conjonction avec des automates de compilation ; ce sont des
+ machines « esclaves » qui récupèrent des paquets sources et
+ tentent de les compiler. Il est aussi possible d'interagir par
+ courrier électronique avec ce système. Cette interface est utilisée
+ par les porteurs pour récupérer un paquet source (en général, un
+ paquet qui ne peut être compilé automatiquement) et travailler
+ dessus.
+ </p>
+ <p>
+ <package>buildd</package> n'est pas disponible sous forme de
+ paquet ; pourtant, la plupart des équipes de porteurs
+ l'utilisent aujourd'hui ou ont prévu de l'utiliser bientôt. L'outil
+ de construction automatisé réel est dans le paquet
+ <package>sbuild</package>, voir la description dans <ref
+ id="sbuild">. Le système <package>buildd</package> regroupe également
+ un ensemble de composants très utiles, continuellement utilisés, mais
+ non encore mis en paquet, tels que <prgn>andrea</prgn> et
+ <prgn>wanna-build</prgn>.
+ </p>
+ <p>
+ Une partie des informations produites par <package>buildd</package>
+ — utiles pour les porteurs — est disponible sur
+ la toile à l'adresse <url id="&url-buildd;">. Ces informations
+ incluent les résultats produits toutes les nuits par
+ <prgn>andrea</prgn> (dépendances des sources) et
+ <prgn>quinn-diff</prgn> (paquets à recompiler).
+ </p>
+ <p>
+ Nous sommes très fiers de ce système car il a de nombreux usages
+ potentiels. Des groupes de développeurs indépendants peuvent utiliser
+ ce système pour créer différentes saveurs de Debian — qui
+ peuvent être ou ne pas être intéressantes pour tous (par exemple, une
+ version de Debian compilée avec des vérifications relatives à
+ <prgn>gcc</prgn>). Ce système nous permettra aussi de recompiler
+ rapidement toute une distribution.
+ </p>
+ <p>
+ Les administrateurs des buildds pour chaque architecture peuvent être
+ contactés à l'adresse électronique $arch@buildd.debian.org.
+ </p>
+ </sect2>
+ </sect1>
+ <sect1 id="packages-arch-specific">
+ <heading>
+ Quand votre paquet <em>n'est pas</em> portable
+ </heading>
+ <p>
+ Certains paquets ont encore des problèmes pour être construits et/ou
+ pour fonctionner sur certaines des architectures prises en charge par
+ Debian et ne peuvent pas du tout être portés, ou pas dans un laps de
+ temps raisonnable. Un exemple est un paquet qui est spécifique SGVA
+ (i386 seulement) ou qui utilise des fonctionnalités spécifiques au
+ matériel qui ne sont pas gérées sur toutes les architectures.
+ </p>
+ <p>
+ Pour éviter que des paquets cassés soient envoyés dans l'archive et
+ qu'ils fassent perdre du temps des buildd, vous devez faire plusieurs
+ choses :
+ </p>
+ <p>
+ <list>
+ <item>
+ <p>
+ Tout d'abord, assurez-vous que votre paquet <em>échoue</em> à la
+ compilation sur les architectures qu'il ne gère pas. Il y a
+ plusieurs moyens de faire cela. Le moyen préféré est d'avoir une
+ petite suite de tests pendant la construction qui testera la
+ fonctionnalité et qui échouera si cela ne fonctionne pas. C'est de
+ toute façon une bonne idée et empêchera des (certains) envois
+ cassés pour toutes les architectures, et cela permettra également
+ au paquet d'être construit dès que la fonctionnalité nécessaire est
+ disponible.
+ </p>
+ <p>
+ De plus, si vous croyez que la liste des architectures gérées est
+ plutôt constante, vous devriez changer « any » en une
+ liste des architectures gérées dans le fichier
+ <file>debian/control</file>. Ainsi, la construction échouera
+ également et l'indiquera à un lecteur humain sans vraiment essayer.
+ </p>
+ </item>
+ <item>
+ <p>
+ Pour empêcher les compilateurs automatiques de tenter sans raison
+ de construire votre paquet, il doit être inclus dans
+ <file>packages-arch-specific</file>, une liste utilisée par le
+ script <prgn>wanna-build</prgn>. La version actuelle est disponible
+ à <url
+ id="http://cvs.debian.org/srcdep/Packages-arch-specific?cvsroot=dak"> ;
+ veuillez consulter le début du fichier pour savoir qui contacter
+ pour le modifier.
+ </p>
+ </item>
+ </list>
+ </p>
+ <p>
+ Veuillez noter qu'il est insuffisant de simplement ajouter votre
+ paquet à Packages-arch-specific sans le faire également échouer lors
+ de compilation sur les architectures non gérées : un porteur ou
+ toute autre personne essayant de construire votre paquet peut
+ accidentellement l'envoyer sans remarquer qu'il ne fonctionne pas. Si
+ dans le passé, certains paquets binaires ont été envoyés pour des
+ architectures non gérées, demandez leur suppression en remplissant un
+ bogue sur <package>ftp.debian.org</package>.
+ </p>
+ </sect1>
+ </sect>
+ <sect id="nmu">
+ <heading>
+ Mise à jour indépendante
+ </heading>
+ <p>
+ Dans certaines circonstances, il est nécessaire qu'une personne autre
+ que le responsable d'un paquet fasse une mise à jour de ce paquet. Ce
+ type de mise à jour est désigné en anglais par l'expression
+ <em>non-maintainer upload (NMU)</em>. Dans le présent document, nous
+ traduisons librement cette expression par « mise à jour
+ indépendante ».
+ </p>
+ <p>
+ Cette section ne traite que des mises à jour indépendantes de source,
+ c.-à-d., les mises à jour qui envoient une nouvelle version d'un
+ paquet. Pour les mises à jour indépendantes par des porteurs ou des
+ membres de la QA, veuillez consulter <ref id="binary-only-nmu">. Si un
+ buildd construit et envoie un paquet, cela est également à strictement
+ parler une NMU binaire. Veuillez consulter <ref id="buildd"> pour plus
+ d'informations.
+ </p>
+ <p>
+ La raison principale pour laquelle une mise à jour indépendante est
+ réalisée est quand un développeur a besoin de corriger le paquet d'un
+ autre développeur pour résoudre des problèmes sérieux ou des bogues
+ paralysants ou quand le responsable d'un paquet ne peut pas fournir une
+ correction dans un délai raisonnable.
+ </p>
+ <p>
+ Tout d'abord, il est capital que ces mises à jour indépendantes soient
+ aussi peu intrusives que possible. Ne faites pas de ménage, ne modifiez
+ pas le nom des modules ou des fichiers, ne déplacez pas les
+ répertoires ; plus généralement, ne corrigez pas ce qui n'est pas
+ cassé. Faites un correctif aussi petit que possible. Si certaines
+ choses froissent votre sens de l'esthétique, parlez-en au responsable
+ du paquet, au responsable amont ou soumettez un rapport de
+ bogue. Quoiqu'il en soit, les changements esthétiques <em>ne doivent
+ pas</em> être effectués lors d'une mise à jour indépendante.
+ </p>
+ <p>
+ Et souvenez-vous du Serment d'Hippocrate « Par dessus tout,
+ ne pas faire de mal ». Il est préférable de laisser un paquet avec
+ un bogue ouvert grave plutôt qu'appliquer un correctif non fonctionnel
+ ou un correctif qui cache le bogue sans le résoudre.
+ </p>
+ <sect1 id="nmu-guidelines">
+ <heading>
+ Comment faire une mise à jour indépendante ?
+ </heading>
+ <p>
+ Les mises à jour indépendantes qui corrigent des bogues de gravité
+ importante, sérieuse et plus élevée sont encouragées et
+ acceptées. Vous devriez vous efforcer de contacter le responsable
+ actuel du paquet : il est peut-être sur le point d'envoyer un
+ correctif pour le problème ou il a peut-être une meilleure solution.
+ </p>
+ <p>
+ Les mises à jour indépendantes doivent être réalisées pour assister un
+ responsable de paquet à résoudre des bogues. Les responsables
+ devraient être reconnaissants pour cette aide et les personnes faisant
+ la mise à jour indépendante devraient respecter les décisions du
+ responsable et tenter d'aider personnellement le responsable dans son
+ travail.
+ </p>
+ <p>
+ Une mise à jour indépendante devrait suivre toutes les conventions
+ décrites dans cette section. Pour un envoi vers <em>testing</em> ou
+ <em>unstable</em>, l'ordre suivant des étapes est recommandé :
+ </p>
+ <p>
+ <list>
+ <item>
+ <p>
+ Vérifiez que les bogues du paquet qui devraient être corrigés par
+ la mise à jour indépendante sont bien référencés dans le système de
+ suivi des bogues. S'ils n'y sont pas, faites des rapports de bogue
+ immédiatement.
+ </p>
+ </item>
+ <item>
+ <p>
+ Attendez la réponse du responsable quelques jours. Si vous
+ n'obtenez aucune réponse, vous pouvez l'aider en lui envoyant le
+ correctif qui corrige le bogue. N'oubliez pas de marquer le bogue
+ avec le mot-clé « patch ».
+ </p>
+ </item>
+ <item>
+ <p>
+ Patientez quelques jours. Si vous n'avez toujours aucune réponse du
+ responsable, envoyez-lui un courrier annonçant votre intention
+ d'effectuer une mise à jour indépendante du paquet. Préparez la NMU
+ comme décrit dans cette section et testez-la soigneusement sur
+ votre machine (cf. <ref id="sanitycheck">). Re-vérifiez que votre
+ correctif n'a aucun effet de bord inattendu. Assurez-vous que votre
+ correctif est aussi minimaliste et non intrusif que possible.
+ </p>
+ </item>
+ <item>
+ <p>
+ Envoyez votre paquet à incoming dans <file>DELAYED/7-day</file>
+ (cf. <ref id="delayed-incoming">), envoyez le correctif final au
+ responsable par le BTS et expliquez-lui qu'il a 7 jours pour réagir
+ s'il veut annuler la NMU.
+ </p>
+ </item>
+ <item>
+ <p>
+ Suivez ce qui se passe, vous êtes responsable pour tout bogue que
+ vous auriez introduit avec votre NMU. Vous devriez probablement
+ utiliser le <ref id="pkg-tracking-system"> (PTS) pour vous tenir
+ informé de l'état du paquet après votre NMU.
+ </p>
+ </item>
+ </list>
+ </p>
+ <p>
+ Parfois, le responsable de version ou un groupe organisé de
+ développeurs peut annoncer une certaine période de temps au cours de
+ laquelle les règles de mise à jour indépendante seront plus
+ souples. Ceci implique habituellement une période plus courte
+ d'attente avant d'envoyer des correctifs et une période de délai plus
+ courte. Il est important de noter que, même au cours de ces
+ « chasses aux bogues », la personne désirant faire la mise à
+ jour indépendante doit remplir des bogues et contacter en premier le
+ développeur, et ensuite seulement passer à l'action. Veuillez vous
+ reporter à <ref id="qa-bsp"> pour des détails.
+ </p>
+ <p>
+ Pour la distribution <em>testing</em>, les règles peuvent être
+ changées par les responsables de publication. Veuillez porter une
+ attention spéciale au fait que le moyen habituel pour un paquet
+ d'entrer dans <em>testing</em> est de passer par <em>unstable</em>.
+ </p>
+ <p>
+ Pour la distribution <em>stable</em>, veuillez y apporter une
+ attention supplémentaire. Bien sûr, les responsables de publication
+ peuvent également modifier les règles ici. Veuillez vérifier avant
+ votre envoi que tous vos changements sont acceptables pour inclusion
+ dans la prochaine version stable par le responsable de publication.
+ </p>
+ <p>
+ Quand un bogue de sécurité est détecté, l'équipe de sécurité peut
+ effectuer une mise à jour indépendante en utilisant ses propres
+ règles. Veuillez vous référer à <ref id="bug-security"> pour plus
+ d'informations.
+ </p>
+ <p>
+ Pour les différences concernant les mises à jour indépendantes par les
+ porteurs, veuillez voir <ref id="source-nmu-when-porter">.
+ </p>
+ <p>
+ Bien sûr, il est toujours possible de s'accorder avec un responsable
+ pour des règles spéciales (comme quand le responsable demande
+ « merci d'envoyer le correctif directement pour moi et pas de
+ diff nécessaire »).
+ </p>
+ </sect1>
+ <sect1 id="nmu-version">
+ <heading>
+ Numéro de version pour les mises à jour indépendantes
+ </heading>
+ <p>
+ Chaque fois que vous modifiez un paquet, le numéro de version de ce
+ paquet doit changer, même pour la plus triviale des
+ modifications. Notre système de gestion de paquets s'appuie sur ces
+ numéros de version.
+ </p>
+ <p>
+ Si vous faites une mise à jour indépendante <em>(NMU)</em>, vous devez
+ ajouter un numéro de version mineur à la partie
+ <var>révision-debian</var> du numéro de version (la partie qui suit le
+ dernier trait d'union). Ce numéro supplémentaire débutera à
+ « 1 ». Prenons pour exemple le paquet « foo » qui
+ porte le numéro de version 1.1-3. Dans l'archive, le fichier de
+ contrôle du paquet source serait <file>foo_1.1-3.dsc</file>. La
+ version amont est « 1.1 » et la révision Debian est
+ « 3 ». La mise à jour indépendante suivante ajouterait le
+ numéro de version mineur « .1 » au numéro de révision
+ Debian ; le nouveau fichier de contrôle du paquet source serait
+ alors <file>foo_1.1-3.1.dsc</file>.
+ </p>
+ <p>
+ Le numéro de révision mineur est nécessaire pour éviter de prendre un
+ numéro de version au responsable officiel du paquet, ce qui pourrait
+ perturber son travail. Cela a aussi l'avantage de montrer clairement
+ que le paquet n'a pas été livré par le responsable officiel.
+ </p>
+ <p>
+ S'il n'y a pas de partie <var>révision-debian</var> dans le numéro de
+ version du paquet, il faut en créer une en démarrant à
+ « 0.1 ». S'il est absolument nécessaire qu'une personne qui
+ n'est pas responsable d'un paquet fasse une livraison basée sur une
+ nouvelle version amont, cette personne doit choisir « 0.1 »
+ comme numéro de révision Debian. Le responsable du paquet doit, lui,
+ démarrer sa numérotation à « 1 ».
+ </p>
+ <p>
+ Si vous envoyez un paquet vers <em>testing</em> ou <em>stable</em>,
+ vous devrez parfois créer une branche (« fork ») dans
+ l'arbre de numéro des version. Pour cela, vous pouvez utiliser des
+ numéros de version comme 1.1-3sarge0.1.
+ </p>
+ </sect1>
+ <sect1 id="nmu-changelog">
+ <heading>
+ Les mises à jour indépendantes sources doivent être mentionnées dans
+ le fichier changelog
+ </heading>
+ <p>
+ Une personne qui fait une mise à jour indépendante source doit ajouter
+ une entrée dans le fichier <file>changelog</file> qui indique les
+ bogues corrigés et qui précise pourquoi cette mise à jour était
+ nécessaire. Cette entrée comportera l'adresse de la personne ayant
+ fait l'envoi ainsi que la version livrée.
+ </p>
+ <p>
+ Par convention, dans le cas d'une mise à jour indépendante source
+ <em>(NMU)</em>, l'entrée du fichier changelog débute par la
+ ligne :
+ <example>