From b86570f63e533abcbcb97c2572e0e5732a96307b Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Sat, 27 Apr 2024 11:40:31 +0200 Subject: Adding upstream version 1.20.13. Signed-off-by: Daniel Baumann --- man/fr/deb-changes.pod | 208 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 208 insertions(+) create mode 100644 man/fr/deb-changes.pod (limited to 'man/fr/deb-changes.pod') diff --git a/man/fr/deb-changes.pod b/man/fr/deb-changes.pod new file mode 100644 index 0000000..79cb830 --- /dev/null +++ b/man/fr/deb-changes.pod @@ -0,0 +1,208 @@ + + ***************************************************** + * GENERATED FILE, DO NOT EDIT * + * THIS IS NO SOURCE FILE, BUT RESULT OF COMPILATION * + ***************************************************** + +This file was generated by po4a(7). Do not store it (in VCS, for example), +but store the PO file used as source file by po4a-translate. + +In fact, consider this as a binary, and the PO file as a regular .c file: +If the PO get lost, keeping this translation up-to-date will be harder. + +=encoding UTF-8 + +=head1 NOM + +deb-changes - Format des fichiers S<« .changes »> Debian + +=head1 SYNOPSIS + +IB<.changes> + +=head1 DESCRIPTION + +Each Debian upload is composed of a .changes control file, which contains a +number of fields in L format. + +Each field begins with a tag, such as B or B (case +insensitive), followed by a colon, and the body of the field (case sensitive +unless stated otherwise). Fields are delimited only by field tags. In +other words, field text may be multiple lines in length, but the +installation tools will generally join lines when processing the body of the +field (except in case of the multiline fields B, B, +B, B and B, see below). + +Les données de contrôle pourraient être incluses dans une signature OpenPGP +S<« ASCII> S comme spécifié dans RFC4880. + +=head1 LES CHAMPS + +=over + +=item B I (requis) + +La valeur de ce champ déclare la version du format du fichier. La syntaxe de +la valeur du champ est un numéro de version avec un composant majeur et +mineur. Les modifications incompatibles avec les versions précédentes du +format incrémenteront la version majeure, tandis que les modifications +compatibles (telles que les ajouts de champ) incrémenteront la version +mineure. La version de format actuelle est B<1.8>. + +=item B I (requis) + +La date à laquelle le paquet a été construit ou modifié pour la dernière +fois. Elle doit avoir le même format que la date dans l'entrée de +B(5). + +La valeur de ce champ est habituellement extraite du fichier +I. + +=item B I [B<(>IB<)>] (requis) + +Le nom du paquet source. Si la version du source diffère de la version +binaire, alors le I sera suivi par une I entre +parenthèses. Cela peut arriver quand il s'agit d'un envoi seulement binaire +NMU S<(« non-maintainer> S + +=item B I (requis selon le contexte) + +Ce champ coupé est une liste, séparée par des espaces, de paquets binaires à +envoyer. Si l'envoi ne concerne que les sources, le champ est omis (depuis +S + +=item B I + +Liste des architectures des fichiers actuellement envoyés. Voici quelques +architectures S B, B, S, etc.> Remarquez que +l'option B signifie que le paquet est indépendant de toute +architecture. Si les sources du paquet sont également envoyées, l'entrée +spéciale B est aussi présente. Les architectures joker ne doivent +jamais être présentes dans la liste. + +=item B I (requis) + +C'est classiquement le numéro de version du paquet d'origine dans la forme +choisie par l'auteur du programme. Il peut y avoir aussi un numéro de +révision Debian (pour les paquets non natifs). Le format exact et +l'algorithme de tri sont décrits dans B(7). + +=item B Is (requis) + +Liste une ou plusieurs distributions, séparées par des espaces, dans +lesquelles cette version peut être installée après envoi dans l'archive. + +=item B I (recommandé) + +L'urgence de l'envoi. Les valeurs actuelles reconnues sont, par ordre +croissant S B, B, B, B et +B. + +=item B I (requis) + +Le format de ce champ sera S<« Jean> Dupont Sjdupont@example.orgE » ;> +et c'est bien sûr le créateur du paquet, par opposition à l'auteur du +programme mis en paquet. + +=item B I + +Le format de ce champ sera S<« Jean> Dupont Sjdupont@example.orgE » ;> +et c'est bien sûr celui qui a préparé les modifications du paquet pour cette +version. + +=item B (recommandé) + +=item S< >I B<-> I + +Ce champ à lignes multiples contient une liste de noms de paquets binaires +suivis d'une espace, d'un tiret S<(« B<-> »)> et de leur description courte +éventuellement tronquée. Si l'envoi ne concerne que les sources, le champ +est omis (depuis S + +=item B I + +A space-separated list of bug report numbers for bug reports that have been +resolved with this upload. The distribution archive software might use this +field to automatically close the referred bug numbers in the distribution +bug tracking system. + +=item B + +Ce champ indique que l'envoi est une construction seulement binaire +indépendante (NMU). Il est issu de la paire clé/valeur B de +l'entrée metadata du changelog. + +=item B I + +Ce champ définit une liste, séparée par des espaces, de profils de +construction avec lesquels cet envoi a été construit. + +=item B (requis) + +=item S< >I + +Ce champ à lignes multiples fournit le texte concaténé de toutes les entrées +de changelog faisant partie de cet envoi. Pour rendre ce champ à lignes +multiples valable, les lignes vides sont remplacées par un point S<« B<.> »> et +toutes les lignes sont indentées par une seule espace. Le contenu exact +dépend du format du changelog. + +=item B (requis) + +=item S< >I I I
I I + +Ce champ à lignes multiples fournit une liste de fichiers avec la md5sum, la +taille, la section et la priorité de chacun. + +La première ligne de la valeur du champ (la partie sur la même ligne que le +nom du champ suivi par deux-points) est toujours vide. Le contenu du champ +est exprimé sous la forme de lignes de continuation, un ligne par +fichier. Chaque ligne consiste en des entrées, séparées par des espaces, +décrivant le S la md5sum, la taille du fichier, sa section, sa +priorité et son nom. + +Ce champ liste tous les fichiers qui composent l'envoi. La liste de fichiers +de ce champ doit correspondre à celle présente dans les autres champs +relatifs aux B. + +=item B (requis) + +=item B (requis) + +=item S< >I I I + +Ces champs à lignes multiples fournissent une liste de fichiers avec la +somme de contrôle et la taille de chacun. Ces champs ont la même syntaxe et +ne diffèrent que par l'algorithme de somme de contrôle S SHA-1 pour +B et SHA-256 pour B. + +La première ligne de la valeur du champ (la partie sur la même ligne que le +nom du champ suivi par deux-points) est toujours vide. Le contenu du champ +est exprimé par des lignes de continuation, une ligne par fichier. Chaque +ligne consiste en des entrées séparées par des espaces décrivant le +S somme de contrôle, la taille du fichier et le nom du fichier. + +Ces champs listent tous les fichiers qui composent l'envoi. La liste de +fichiers de ce champ doit correspondre à celle présente dans le champ +B et les autres champs relatifs aux B. + +=back + +=head1 BOGUES + +Le champ B n'est pas cohérent avec des autres champs +B. Les champs B et B ont des noms qui +provoquent la confusion. Le champ B fournit des informations +sur ce à quoi une suite fait référence habituellement. + +=head1 VOIR AUSSI + +L, B(5), B(7). + + +=head1 TRADUCTION + +Ariel VARDI , 2002. +Philippe Batailler, 2006. +Nicolas François, 2006. +Veuillez signaler toute erreur à . -- cgit v1.2.3