DOKK / manpages / debian 13 / devscripts / cowpoke.1.fr
COWPOKE(1) General Commands Manual COWPOKE(1)

cowpoke - Construire un paquet source Debian dans une instance de cowbuilder distante

cowpoke [options] paquet.dsc

Envoyer un paquet source Debian à un hôte cowbuilder et construire le paquet. Le paquet résultant peut également être signé et envoyé dans une file d’attente.

Les options suivantes sont disponibles :

Indiquer la ou les architectures Debian pour lesquelles le paquet doit être construit. Une liste d’architectures séparées par des espaces peut être utilisée pour construire le paquet pour toutes ces architectures en une seule passe. Les noms d’architecture supportés sont ceux renvoyés par dpkg-architecture(1) pour DEB_BUILD_ARCH.

Indiquer la ou les distributions Debian pour lesquelles le paquet doit être construit. Une liste de distributions séparées par des espaces peut être utilisée pour construire le paquet pour toutes ces distributions en une seule passe. Des noms de code (comme sid ou squeeze) ou des noms de distribution (comme unstable ou experimental) peuvent être utilisés, mais vous devriez toujours utiliser un type de noms ou l’autre parce que c’est ce nom qui est utilisé pour les chemins de fichier et pour trouver les anciens paquets utilisés pour les rapports de comparaison.

Utiliser des noms définis localement est maintenant aussi possible avec cette option, quand elle est utilisée conjointement à l’option BASE_DIST dans un fichier de configuration. Cela permet la maintenance et l’utilisation de chroots de construction configurés spécialement, afin par exemple de fournir les dépendances de paquet des archives de rétroportages ou d’un dépôt local, ou de définir des options de configuration non habituelles, sans polluer les chroots propres utilisés pour les constructions de paquet à destination des dépôts principaux. Consultez la description de BASE_DIST ci-dessous.

Indiquer l’hôte distant sur lequel se fera la construction.

Indiquer l’utilisateur distant à utiliser pour la construction.

Créer la racine cowbuilder distante si elle n’existe pas encore. Si cette option n’est pas fournie, une distribution ou architecture (indiquées par --dist ou --arch) qui n’aurait pas de racine cowbuilder sera considérée comme une erreur.

L’utilisateur indiqué par --buildd-user doit avoir le droit de créer RESULT_DIR sur l’hôte de construction, sinon un administrateur avec les droits nécessaires doit d’abord le créer et donner à cet utilisateur (ou à un groupe dont il fait partie) accès en écriture à ce répertoire, afin que cette option réussisse.

Copier les fichiers résultant de la construction vers chemin. Si aucun chemin n’est indiqué, ils sont alors renvoyés vers le répertoire actuel. Le chemin donné doit exister, il ne sera pas créé.

Ne pas copier le résultat de la construction vers RETURN_DIR (écrase le chemin configuré dans les fichiers de configuration).

Indiquer des options supplémentaires à fournir à dpkg-buildpackage(1). les différentes options sont séparées par des espaces. Cela remplacera toute option fournie par la variable DEBBUILDOPTS du fichier pbuilderrc de la machine de construction.

Indiquer des arguments supplémentaires à passer directement à cowbuilder quand un chroot est créé (en utilisant l’option --create précédente). Si plusieurs arguments doivent être passés, cette option devrait être indiquée séparément pour chacun.

Par exemple, --create-opts "--othermirror" --create-opts "deb http:// ..."

Cette option remplacera toutes les CREATE_OPTS indiquées pour un chroot dans les fichiers de configuration de cowpoke.

Indiquer des arguments supplémentaires à passer directement à cowbuilder si la base du chroot est mise à jour. Si plusieurs arguments doivent être passés, cette option devrait être indiquée séparément pour chacun.

Cette option remplacera toutes les UPDATE_OPTS indiquées pour un chroot dans les fichiers de configuration de cowpoke.

Indiquer des arguments supplémentaires à passer directement à cowbuilder quand un paquet est construit. Si plusieurs arguments doivent être passés, cette option devrait être indiquée séparément pour chacun.

Cette option remplacera toutes les BUILD_OPTS indiquées pour un chroot dans les fichiers de configuration de cowpoke.

Indiquer la clef à utiliser pour signer les paquets. Cela remplacera toutes les SIGN_KEYID indiquées pour un chroot dans les fichiers de configuration de cowpoke.

Indiquer la file dput à utiliser pour envoyer les paquets signés. Cela remplacera toutes les UPLOAD_QUEUE indiquées pour un chroot dans les fichiers de configuration de cowpoke.

Afficher un bref résumé des options disponibles et de la configuration en cours.

Afficher les informations sur la version.

Quand cowpoke est exécuté, les options de configuration suivantes sont lues dans le fichier de configuration global, celui de l’utilisateur et du projet, s’ils sont présents. Les chemins peuvent être indiqués de façon absolue ou relative (les chemins étant alors relatifs au répertoire personnel de l’utilisateur BUILDD_USER). Les chemins étant généralement fournis entre guillemets, l’expansion des tildes ne sera pas réalisée.

Elles s’appliquent à chaque architecture et distribution lors d’un appel à cowpoke.

L’adresse réseau ou le nom complètement qualifié (FQDN) de la machine de construction où cowbuilder est configuré. Elle peut être modifiée avec l’option en ligne de commande --buildd.
Le nom de l’utilisateur, non privilégié, sur la machine de construction. Le nom par défaut est le nom de l’utilisateur local qui exécute cowpoke (ou le nom d’utilisateur précisé dans la configuration SSH pour BUILDD_HOST), et le nom fournit par la variable d’environnement peut être remplacé avec l’option --buildd-user en ligne de commande.
La ou les architectures Debian pour lesquelles il faut construire les paquets. Cela doit correspondre à la valeur de DEB_BUILD_ARCH du chroot de construction utilisé. La valeur par défaut est l’architecture de la machine sur laquelle cowpoke est exécutée, et l’architecture peut être remplacée avec l’option --arch en ligne de commande. Une liste d’architectures séparées par des espaces (il peut être nécessaire de fournir le tout entre guillemets) peut être utilisée pour construire les paquets pour toutes ces architectures en une seule passe.
La ou les distributions Debian pour lesquelles il faut construire les paquets. Une liste de distributions séparées par des espaces (il peut être nécessaire de fournir le tout entre guillemets) peut être utilisée pour construire les paquets pour toutes ces architectures en une seule passe. La ou les distributions peuvent être remplacées avec l’option --dist en ligne de commande.

Le chemin du répertoire sur la machine de construction où sont placés initialement les paquets source. Il doit être accessible en écriture par l’utilisateur BUILDD_USER.
La racine du système de fichiers pour tous les fichiers CoW et les fichiers résultats. Des sous-répertoires spécifiques aux architectures et aux distributions seront normalement créés sous cette racine. Le cache d’apt et les répertoires temporaires de construction se trouveront également sous ce chemin.

Si cette option est activée, elle doit contenir l’identifiant de la clef OpenPGP à fournir à debsign(1) si les paquets doivent être signés sur la machine distante. Il vous sera demandé si vous souhaitez signer les paquets après que toutes les constructions sont finies. Si cette option n’est pas activée ou si elle contient une chaîne vide, aucune tentative de signature ne sera effectuée. Elle peut être remplacée de façon spécifique à une architecture et une distribution avec l’option arch_dist_SIGN_KEYID décrite ci-dessous, ou par invocation avec l’option --sign en ligne de commande.

Si cette option est activée, elle doit contenir une indication d’hôte pour dput(1) qui sera utilisée pour envoyer les paquets après qu’ils ont été signés. Il vous sera demandé de confirmer si vous souhaitez envoyer les paquets après qu’ils ont été signés. Si cette option n’est pas activée ou si elle contient une chaîne vide, aucune tentative d’envoi ne sera effectuée. Si SIGN_KEYID n’est pas activée, cette option sera complètement ignorée. Elle peut être remplacée de façon spécifique à une architecture et une distribution avec l’option arch_dist_UPLOAD_QUEUE décrite ci-dessous, ou par invocation avec l’option --upload en ligne de commande.

La commande à utiliser pour obtenir les droits du superutilisateur sur la machine distante de construction. Si elle n’est pas définie, la commande par défaut est sudo(8). Elle n’est nécessaire que pour appeler cowbuilder et lui permettre d’entrer dans son chroot. Vous pouvez donc n’autoriser cet utilisateur à acquérir des droits supplémentaires que pour l’exécution de cette commande. La ligne suivante dans sudoers permettra d’appeler cowbuilder sans avoir à fournir de mot de passe :
utilisateur ALL = NOPASSWD: /usr/sbin/cowbuilder
Autrement, vous pouvez utiliser SSH avec une clef ou tout autre mécanisme correspondant à votre politique locale. su -c n’est pas vraiment utilisable ici parce qu’il nécessite de placer des guillemets autour, contrairement aux autres.

L’utilitaire à utiliser pour créer une nouvelle racine de construction. Les possibilités sont debootstrap ou cdebootstrap.

Si elle est définie, les fichiers de paquet issus de la construction seront copiés à l’endroit (local ou distant) configuré, une fois la construction terminée. Le chemin doit exister, il ne sera pas créé. Cette option n’est pas définie par défaut et peut être écrasée par --return ou --no-return.

Ce sont des variables de la forme $arch_$dist_VAR qui ne s’appliquent qu’à une cible de construction spécifique à une architecture et à une distribution.

Le chemin du répertoire de la machine de construction où les paquets résultants (source et binaires) seront trouvés, et où les versions ultérieures des paquets ayant été précédemment construits pourront être trouvées. Si des anciens paquets sont trouvés, debdiff sera utilisé pour comparer le nouveau paquet avec la version précédente une fois la construction finie, et le résultat se trouvera dans le journal de construction. Les fichiers du répertoire doivent être lisibles par BUILDD_USER pour les vérifications par lintian(1) et debdiff(1) ainsi que pour les envois par dput(1). Si cette option n’est pas définie pour certaines combinaisons d’architectures et de distributions, alors le chemin par défaut sera $PBUILDER_BASE/$arch/$dist/result

Le répertoire ou les fichiers CoW maîtres se trouvent (ou là où ils sont créés si l’option en ligne de commande --create est utilisée). Si cette option n’est pas définie pour une combinaison d’architecture et de distribution, alors le chemin par défaut est $PBUILDER_BASE/$arch/$dist/base.cow

Le nom de code à passer à l’option --distribution de cowbuilder à la place de dist. C’est nécessaire quand dist est un nom localement significatif utilisé pour un chroot de construction configuré spécialement, comme par exemple "wheezy_backports", et non le nom de suite formel d’une distribution connue de debootstrap. Cette option ne peut pas être remplacée en ligne de commande, puisqu’il n’y pas vraiment de raison de la modifier pour les appels individuels de cowpoke. Si cette option n’est pas indiquée pour une combinaison d’architecture et de distribution, alors la distribution est utilisée par défaut.

Un tableau bash contenant des options supplémentaires à passer directement à cowbuilder quand un chroot est créé (en utilisant l’option --create). C’est pratique quand des options comme --othermirror sont voulues pour créer des configurations spéciales de chroot, comme par exemple "wheezy_backports". Par défaut il n’est pas défini. Toutes les valeurs définie dans ce tableaux seront ignorées si l’option --create-opts est passée en ligne de commande.

Chaque élément de ce tableau correspond à un seul argument (dans le sens de ARGV) qui sera passé à cowbuilder. Cela permet à ces arguments, qui pourraient contenir des espaces, avoir des besoins de protection bizarre ou d’autres caractères spéciaux, de pas ne pas être déformés avant d’atteindre cowbuilder.

Les tableaux bash sont initialisés un utilisant le format suivant :


OPTS=( "arg1" "arg 2" "--option" "value" "--opt=val" "etc. etc." )

Un tableau bash contenant des options supplémentaires à passer directement à cowbuilder à chaque fois que la base de ce chroot est mise à jour. Le comportement est similaire à l’option CREATE_OPTS précédente, à part qu’il est déclenché quand le chroot est mis à jour.

Un tableau bash contenant des options supplémentaires à passer directement à cowbuilder quand un paquet est construit. C’est pratique pour utiliser une option comme --twice que cowpoke n’a pas besoin de gérer directement. Le comportement est sinon similaire à l’option UPDATE_OPTS précédente, à part qu’il est déclenché pendant la phase de construction par cowbuilder.

Un remplacement facultatif de l’option SIGN_KEYID globale, spécifique à une architecture et une distribution.

Un remplacement facultatif de l’option UPLOAD_QUEUE globale, spécifique à une architecture et une distribution.

/etc/cowpoke.conf
Options de configuration globales. Elles remplaceront les valeurs par défaut codées en dur.
~/.cowpoke
Options de configuration de l’utilisateur. Elles remplaceront les valeurs des options de configuration globales.
.cowpoke
Options de configuration du projet. Elles remplaceront les valeurs des options de configuration globale ou de l’utilisateur si cowpoke est appelé depuis le répertoire où se trouve le fichier.

Si la variable d’environnement COWPOKE_CONF est définie, elle indique un fichier de configuration supplémentaire qui remplacera tous les autres. Les options utilisées explicitement sur la ligne de commande remplacent les options provenant des fichiers de configuration.

Il n’y a rien de particulier à faire pour configurer une instance de cowbuilder pour qu’elle puisse être utilisée avec cowpoke. Créez-la simplement telle que vous en avez besoin avec "cowbuilder --create" en suivant la documentation de cowbuilder, puis configurez cowpoke avec les informations sur l’utilisateur, l’architecture et le chemin nécessaire pour y accéder sur les machines où vous souhaitez l’appeler (ou configurez cowpoke avec les informations sur le chemin, l’architecture et la distribution et fournissez lui l’option --create lors du premier appel). L’hôte de construction sur lequel cowbuilder tourne n’a pas besoin que cowpoke soit installé localement.

La machine de construction doit avoir les paquets lintian et devscripts installés pour les vérifications en fin de construction. Une fois la construction finie, un journal et les résultats des tests automatiques seront enregistrés dans INCOMING_DIR. Si vous souhaitez envoyer des paquets signés, dput(1) devra également être installé sur la machine de construction et devra être configuré pour utiliser l’alias hôte indiqué par UPLOAD_QUEUE. Si rsync(1) est disponible à la fois sur la machine locale et la machine de construction, alors il peut être utilisé pour transférer le paquet source (cela permet d’économiser quelques échanges de orig.tar.* lors de la construction des révisions Debian suivantes).

L’utilisateur qui exécute cowpoke doit avoir un accès SSH à la machine de construction en tant que BUILDD_USER. Cet utilisateur doit pouvoir exécuter cowbuilder en tant que superutilisateur en utilisant BUILDD_ROOTCMD. Les clefs pour les signatures n’ont pas nécessairement à être installées sur la machine de construction (et elles seront ignorées si elles le sont). Si un paquet est signé, les clefs seront nécessaires sur la machine qui exécute cowpoke.

Quand cowpoke est appelé, il cherche d’abord à mettre à jour l’image cowbuilder si cela n’a pas déjà été fait le même jour. Cette vérification se base sur la présence d’un fichier cowbuilder-$arch-$dist-update-log-$date dans le répertoire INCOMING_DIR. Vous pouvez déplacer, renommer ou toucher ce fichier si vous souhaitez que l’image soit mise à jour plus ou moins souvent. Son contenu liste les sorties de cowbuilder pendant la mise à jour (ou la création) de la racine de construction.

Puisque cowbuilder crée un chroot, et qu’il faut pour cela être superutilisateur, cowpoke nécessite également certains des droits du superutilisateur. Et toutes les horreurs qui peuvent arriver à cause de ça pourront vous arriver un jour. cowbuilder est connu pour avoir accidentellement écrasé des systèmes de fichiers montés avec l’option "bind" en dehors de son chroot, et pire encore peut arriver. Soyez prudents, conservez des sauvegardes de ce que vous ne souhaitez pas perdre sur vos machines de construction et utilisez cowpoke pour isoler tous ces problèmes sur une machine qui n’est pas votre machine de développement avec vos quelques heures de travail non committé.

cowbuilder(1), pbuilder(1), ssh-agent(1), sudoers(5)

cowpoke a été écrit par Ron <ron@debian.org>.

Ce document est une traduction, maintenue à lʼaide de lʼoutil po4a <https://po4a.org/> par lʼéquipe de traduction francophone du projet Debian.

Plusieurs traducteurs dont Nicolas François, Guillaume Delacour, Cyril Brulebois, Thomas Huriaux, David Prévot et Xavier Guimard ont contribué aux traductions.

Lʼéquipe de traduction a fait le maximum pour réaliser une adaptation française de qualité. Veuillez signaler toute erreur de traduction en écrivant à <debian-l10n-french@lists.debian.org> ou par un rapport de bogue sur le paquet devscripts.

La version anglaise la plus à jour de ce document est toujours consultable en ajoutant lʼoption « -L C » à la commande man.

28 avril 2008