Guide d’empaquetage pour Ubuntu¶
Bienvenue dans le Guide d’empaquetage et de développement dans Ubunutu ! Il s’agit de l’endroit officiel pour tout apprendre sur le développement et l’empaquetage dans Ubuntu. Après avoir lu ce guide, vous aurez :
entendu parler des plus importants lecteurs, processus et outils dans le développement d’Ubuntu,
configuré correctement votre environnement de développement,
une meilleure idée de la façon de rejoindre notre communauté,
corrigé un vrai bogue Ubuntu dans une partie des tutoriels.
Ubuntu n’est pas seulement un système d’exploitation libre et open source, sa plate-forme est également ouverte et développée de manière transparente. Le code source de chaque composant s’obtient aisément et chaque modification de la plate-forme Ubuntu peut être examinée.
Cela signifie que vous pouvez activement participer à son amélioration et que la communauté des développeurs de la plate-forme Ubuntu se sent toujours concernée pour aider ses pairs à démarrer.
Ubuntu est également une communauté de personnes formidables qui croient au logiciel libre afin qu’il reste accessible au plus grand nombre. Ses membres sont accueillants et souhaitent également votre participation. Nous souhaitons que vous vous impliquiez, posiez des questions, rendiez Ubuntu meilleur avec nous.
Si vous rencontrez des problèmes : pas de panique ! Vérifiez l’article de communication et vous découvrirez comment rentrer plus facilement en contact avec d’autres développeurs.
Le guide est divisé en deux sections :
Une liste d’articles basés sur les tâches ou les choses que vous souhaiteriez voir traitées.
Un ensemble d’articles composant une base de connaissances plus approfondies sur des parties spécifiques de nos outils et nos flux de travail.
Ce guide met l’accent sur la méthode d’empaquetage du Développement des Distributions Ubuntu. Il s’agit d’une nouvelle manière d’empaqueter qui utilise des branches avec un Contrôle de Version Distribuée. Elle comporte actuellement quelques limitations ce qui signifie que beaucoup d’équipes dans Ubuntu utilisent encore les méthodes traditionnelles d’empaquetage. Voir la page Introduction à UDD pour une introduction aux différences.
Articles¶
Introduction au Développement d’Ubuntu¶
Ubuntu est constitué de milliers de composants différents, écrits dans de multiples langages de programmation. Chaque composant - pouvant être une bibliothèque logicielle, un outil ou une application graphique - est disponible sous forme d’un paquet source. Dans la plupart des cas, les paquets sources se composent de deux parties : le code source réel et les métadonnées. Ces dernières comprennent les dépendances du paquet, les droits d’auteur et les informations de licence, ainsi que des instructions sur la façon de construire le paquet. Une fois ce paquet source compilé, le processus de construction fournit les paquets binaires, en d’autres termes, les fichiers .deb que les utilisateurs peuvent installer.
A chaque sortie d’une nouvelle version, ou lorsqu’une personne applique des modifications au code source à destination d’Ubuntu, le paquet source doit être téléchargé vers les machines de construction de Launchpad en vue d’être compilé. Les paquets binaires en résultant sont alors distribués vers une archive et ses miroirs dans différents pays. Les adresses dans /etc/apt/sources.list pointent vers une archive ou un miroir. Chaque jour, des images sont construites pour une sélection des différentes versions d’Ubuntu. Elles peuvent être utilisées dans des circonstances diverses. Ces images peuvent être placées sur une clé USB, gravées sur des DVD, vous pouvez utiliser des images pour un miniportable ou même adaptées à votre téléphone ou à votre tablette. Ubuntu Desktop, Ubuntu Server, Kubuntu et les autres versions précisent la liste des paquets requis pour leur image. Ces images sont utilisées pour les tests d’installation et fournissent le retour d’information sur la planification des livraisons ultérieures.
Le développement d’Ubuntu est très dépendant de la phase actuelle du cycle de sortie. Nous publions une nouvelle version d’Ubuntu tous les six mois, ce qui est rendu possible par l’établissement dates strictement figées. À chaque échéance atteinte, les développeurs doivent faire moins de modifications, ou les moins intrusives possibles. Le gel des fonctionnalités est la première grosse échéance après la première moitié du cycle. À ce stade, les nouvelles fonctionnalités doivent être largement appliquées. Le reste du cycle est censé se concentrer sur la correction des bogues. Ensuite, l’interface utilisateur, puis la documentation, le noyau, etc. sont gelés, puis la version bêta est mise en ligne pour recevoir un maximum de tests. À partir de la version bêta, seuls les bogues critiques sont corrigés, une version candidate est créée et lorsqu’elle ne contient pas de problèmes graves, elle devient la version finale.

Des milliers de paquets sources, des milliards de lignes de code, des centaines de contributeurs exigent beaucoup de communication et de planification pour maintenir des normes élevées de qualité. Au début et au milieu de chaque cycle de version, nous avons le Sommet des Développeurs Ubuntu, où les développeurs et les contributeurs sont réunis pour planifier les fonctionnalités des prochaines versions. Chaque fonctionnalité est décrite par ses intervenants et un cahier des charges est écrit, contenant des informations détaillées sur ses hypothèses, sa mise en œuvre, les modifications nécessaires à d’autres endroits, la façon de la tester, etc. Tout cela est fait de manière ouverte et transparente, afin que vous puissiez participer à distance et regarder un flux vidéo, discuter avec les participants et adhérer aux modifications de spécifications, de sorte que vous soyez toujours informé.
Chaque modification ne peut malgré tout pas être abordée lors d’une réunion, en particulier parce qu’Ubuntu repose sur des modifications effectuées dans d’autres projets. C’est pourquoi les contributeurs à Ubuntu restent constamment en contact. La plupart des équipes ou des projets utilisent des listes de diffusion dédiées en vue d’éviter trop de perturbations inutiles. Pour la coordination plus immédiate, les développeurs et les contributeurs utilisent Internet Relay Chat (IRC). Toutes les discussions y sont ouvertes et publiques.
Un autre outil important en matière de communication est le rapport de bogue. Chaque fois qu’un défaut est décelé dans un paquet ou une partie de l’infrastructure, un rapport de bogue est déposé dans Launchpad. Toutes les informations sont recueillies dans ce rapport et l’importance, le statut et l’affectation du bogue sont mis à jour si nécessaire. Cela en fait un outil efficace pour surmonter les bogues dans un paquet ou un projet et pour organiser la charge de travail.
La plupart des logiciels disponibles dans Ubuntu ne sont pas écrits par les développeurs d’Ubuntu eux-mêmes. Une grande partie est écrite par les développeurs d’autres projets Open Source et ensuite intégrés dans Ubuntu. Ces projets sont appelés “amonts”, parce que leurs codes sources se déversent dans Ubuntu, où nous faisons “juste” leur intégration. La relation avec les projets en amonts est extrêmement importante pour Ubuntu. Ce n’est pas uniquement le code qu’Ubuntu reçoit des projets en amont, ceux-ci profitent également des utilisateurs, des rapports de bogues et des correctifs de la part d’Ubuntu (et des autres distributions).
L’amont le plus important pour Ubuntu est Debian. Debian est la distribution sur laquelle Ubuntu est basée et la plupart des décisions de conception relatives à l’infrastructure d’empaquetage sont prises là. Traditionnellement, Debian a toujours eu des responsables dédiés pour chaque paquet ou des équipes de maintenance dédiées. Dans Ubuntu, ce sont également des équipes qui s’intéressent à un sous-ensemble de paquets et, naturellement, chaque développeur possède un domaine d’expertise, mais la participation (et les droits de téléchargement) est généralement ouverte à tous ceux qui prouvent leur talent et leur volonté.
Obtenir une modification dans Ubuntu en tant que nouveau collaborateur n’est pas aussi intimidant qu’il n’y paraît et peut même s’avérer une expérience très enrichissante. Il ne s’agit pas seulement d’apprendre quelque chose de nouveau et d’excitant, mais également de partager une solution et de résoudre un problème pour des millions d’utilisateurs.
Le développement Open Source intervient dans un monde partagé selon différents objectifs et différents domaines d’intérêt. Par exemple, cela pourrait être le cas d’un Amont particulier intéressé par le travail sur une nouvelle fonctionnalité importante, alors qu’Ubuntu, en raison de son échéancier serré de sortie, est intéressé par la fourniture d’une version robuste avec juste quelques corrections supplémentaires de bogues. C’est pourquoi nous utilisons le “Développement Distribué”, où le code est en cours d’élaboration dans différentes branches qui sont fusionnées les unes avec les autres, après des révisions du code et des discussions adéquates.

Dans l’exemple mentionné ci-dessus, il serait logique de fournir Ubuntu avec la version existante du projet, d’ajouter le correctif, de l’inclure à l’amont pour leur prochaine version et de fournir de nouveau le projet (s’il est convenable) avec la prochaine version d’Ubuntu. Ce serait le meilleur compromis possible et une situation gagnant-gagnant.
Pour corriger un bogue dans Ubuntu, vous devrez d’abord obtenir le code source pour le paquet, puis travailler sur le correctif, le documenter pour qu’il soit simple à comprendre pour les autres développeurs et utilisateurs, puis construire le paquet pour le tester. Après l’avoir testé, vous pouvez aisément proposer que la modification soit incluse dans la version d’Ubuntu actuellement en développement. Un développeur ayant les droits de téléchargement l’examinera pour vous puis l’intégrera dans Ubuntu.

En cherchant une solution, il est généralement intelligent de vérifier avec l’amont et de voir si le problème (ou une solution possible) est connu et, dans le cas contraire, de faire de votre mieux pour que la solution soit un effort concerté.
Des étapes supplémentaires pourraient induire le rétroportage des modifications vers une ancienne version d’Ubuntu encore prise en charge et leur transmission vers l’amont.
Les pré-requis les plus importants pour réussir dans le développement d’Ubuntu sont les suivants : avoir un talent pour “faire que les choses fonctionnent de nouveau”, ne pas avoir peur de lire la documentation et de poser des questions, jouer collectif et apprécier le travail de détective.
Deux bons endroits pour poser vos questions sont ubuntu-motu@lists.ubuntu.com et #ubuntu-motu sur irc.freenode.net. Vous trouverez facilement beaucoup de nouveaux amis et des personnes ayant la même passion que vous : rendre le monde meilleur en produisant de meilleurs logiciels Open Source.
Mise en route¶
Un certain nombre de choses doivent être accomplies pour commencer à développer pour Ubuntu. Cet article est conçu pour configurer votre ordinateur de sorte que vous puissiez commencer à travailler avec des paquets, puis télécharger vos paquets vers la plate-forme d’hébergement d’Ubuntu, Launchpad. Voici ce que nous allons aborder :
Installation des logiciels relatifs à l’empaquetage. Cela comprend :
Les utilitaires d’empaquetage spécifiques à Ubuntu
Logiciel de chiffrement afin que votre travail soit reconnu comme étant bien réalisé par vous
Logiciel de chiffrement supplémentaire afin de transférer des fichiers en toute sécurité
Création et configuration de votre compte sur Launchpad
Configuration de votre environnement de développement pour vous aider à construire des paquets localement, à interagir avec d’autres développeurs, et à proposer vos modifications sur Launchpad.
Note
Il est conseillé de travailler sur l’empaquetage en utilisant la version de développement actuelle d’Ubuntu. Procéder ainsi vous permettra de tester les modifications dans le même environnement où elles seront effectivement appliquées et utilisées.
Ne vous inquiétez pas outre mesure, vous pouvez utiliser Testdrive ou chroots pour utiliser la version de développement en toute sécurité.
Installer les logiciels d’empaquetage de base¶
Il existe de nombreux outils qui simplifieront votre vie de développeur d’Ubuntu. Vous croiserez ces outils plus loin dans ce guide. Pour installer la plupart des outils dont vous aurez besoin, exécutez cette commande :
$ sudo apt-get install gnupg pbuilder ubuntu-dev-tools bzr-builddeb apt-file
Remarque : Depuis Ubuntu 11.10 “Ocelot Onirique” (ou si vous avez des rétroportages activés sur une version actuellement prise en charge), la commande suivante installe les outils ci-dessus et quelques autres, assez communs dans le développement d’Ubuntu :
$ sudo apt-get install packaging-dev
Cette commande va installer les logiciels suivants :
gnupg – GNU Privacy Guard contient les outils dont vous aurez besoin pour créer une clé de chiffrement avec laquelle vous signerez les fichiers que vous souhaiterez télécharger vers Launchpad.
pbuilder – un outil pour réaliser des constructions reproductibles d’un paquet dans un environnement propre et isolé.
ubuntu-dev-tools (et devscripts, sa dépendance directe) – une collection d’outils simplifiant les nombreuses tâches d’empaquetage.
bzr-builddeb (et bzr, une dépendance) – contrôle de la version distribuée avec Bazaar, une nouvelle façon de travailler avec les paquets pour Ubuntu facilitant la collaboration de nombreux développeurs sur le même code, tout en gardant la simplicité de fusionner le travail de chacun.
apt-file donne un moyen facile de trouver le paquet binaire contenant un fichier donné.
Créez votre clé GPG¶
GPG signifie GNU Privacy Guard et implémente le standard OpenPGP vous permettant de signer et de crypter des messages et des fichiers. Ceci est utile pour plusieurs raisons. Dans notre cas, il est important que vous puissiez signer des fichiers avec votre clé afin qu’ils puissent être identifiés comme quelque chose sur laquelle vous avez travaillé. Si vous téléchargez un paquet source vers Launchpad, ce dernier n’acceptera le paquet que s’il peut formellement déterminer qui l’a envoyé.
Pour générer une nouvelle clé GPG, exécutez :
$ gpg --gen-key
GPG vous demandera d’abord le type de clé que vous souhaitez générer. Le choix par défaut (RSA et DSA) convient. Ensuite, il vous demandera la taille de clé. La valeur par défaut (actuellement 2048) est correcte, mais 4096 est plus sécurisé. Par la suite, il vous sera demandé si vous souhaitez faire expirer la clé à un certain stade. Vous pouvez sans danger indiquer “0”, ce qui signifie que la clé n’expirera jamais. Les dernières questions seront à propos de votre nom et de votre adresse de courriel. Il suffit ici de choisir ceux que vous allez utiliser pour le développement d’Ubuntu, vous pourrez ajouter des adresses de courriel supplémentaires plus tard. Ajouter un commentaire n’est pas nécessaire. Ensuite, vous devrez définir une phrase secrète, choisissez-en une sûre (une phrase secrète est juste un mot de passe qui autorise les espaces).
GPG va maintenant vous créer une clé, ce qui peut prendre un peu de temps ; comme GPG a besoin d’octets aléatoires, il serait souhaitable que vous donniez quelques tâches à réaliser au système. Déplacez le curseur, tapez quelques paragraphes de texte aléatoire, chargez quelques pages dans votre navigateur internet, etc.
Une fois cela fait, vous obtiendrez un message similaire à celui-ci :
pub 4096R/43CDE61D 2010-12-06
Key fingerprint = 5C28 0144 FB08 91C0 2CF3 37AC 6F0B F90F 43CD E61D
uid Daniel Holbach <dh@mailempfang.de>
sub 4096R/51FBE68C 2010-12-06
Dans ce cas 43CDE61D est l’identifiant clé.
Ensuite, vous devez envoyer la partie publique de votre clé à un serveur de sorte que tout le monde puisse identifier vos messages et fichiers. Pour ce faire, entrez :
$ gpg --send-keys --keyserver keyserver.ubuntu.com <KEY ID>
Cela enverra votre clé au serveur de trousseau d’Ubuntu, inclus dans un réseau d’autres serveurs de trousseaux qui se synchroniseront entre eux. Une fois cette synchronisation terminée, votre clé publique signée sera prête à vérifier vos contributions partout dans le monde.
Créez votre clé SSH¶
SSH signifie Secure Shell , le protocole permettant d’échanger des données de façon sécurisée sur un réseau. Il est courant d’utiliser SSH pour accéder à un environnement, l’ouvrir sur un autre ordinateur et l’utiliser pour transférer des fichiers en toute sécurité. Dans notre cas, nous allons principalement utiliser SSH pour télécharger en toute sécurité nos paquets source vers Launchpad.
Pour générer une clé SSH, saisissez :
$ ssh-keygen -t rsa
Le nom de fichier par défaut est généralement logique, vous pouvez donc simplement le laisser tel quel. Pour des raisons de sécurité, il est fortement recommandé d’utiliser une phrase secrète.
Configurer pbuilder¶
pbuilder vous permet de construire des paquets en local sur votre machine. Il dispose de différentes fonctions :
La construction se fera dans un environnement minimal et propre. Cela vous aide à vous assurer que vos constructions réussiront de façon reproductible, mais sans modifier votre système local
Il est inutile d’installer toutes les dépendances de construction nécessaires en local
Vous pouvez configurer plusieurs instances pour différentes versions d’Ubuntu et de Debian
Configurer pbuilder est très simple, lancez :
$ pbuilder-dist <release> create
where <release> is for example raring, saucy, trusty or in the case of Debian maybe sid. This will take a while as it will download all the necessary packages for a “minimal installation”. These will be cached though.
Mettez vous en place pour travailler avec Launchpad¶
Avec l’installation d’une configuration de base en local, la prochaine étape sera de configurer votre système pour travailler avec Launchpad. Cette section portera sur les sujets suivants :
Description de Launchpad et création d’un compte Launchpad
Téléversement de vos clés GPG et SSH vers Launchpad
Configurer Bazaar pour travailler avec Launchpad
Configurer Bash pour travailler avec Bazaar
À propos de Launchpad¶
Launchpad est la pièce maîtresse de l’infrastructure que nous utilisons dans Ubuntu. Il stocke non seulement nos paquets et notre code, mais également d’autres choses comme les traductions, les rapports de bogues et les informations sur les personnes qui travaillent sur Ubuntu et leurs équipiers. Vous pourrez également utiliser Launchpad pour publier vos propositions de corrections et obtenir leur examen et leur parrainage par d’autres développeurs d’Ubuntu.
Vous devez vous inscrire à Launchpad et fournir un minimum d’informations. Cela vous permettra de télécharger du code depuis et vers Launchpad, de soumettre des rapports de bogues et plus encore.
Outre l’hébergement d’Ubuntu, Launchpad peut accueillir tout projet de logiciel libre. Pour plus d’informations, voir le wiki Aide de Launchpad.
Créer un compte Launchpad¶
Si vous ne possédez pas encore de compte Launchpad, vous pouvez facilement en créer un. Si vous avez un compte Launchpad, dont vous ne vous rappelez plus l’identifiant, vous pouvez le retrouver en allant sur https://launchpad.net/~ et rechercher la partie après le ~ de l’URL.
Le processus d’inscription à Launchpad vous demandera de choisir un nom à afficher. Il vous est recommandé d’utiliser votre vrai nom, afin que vos collègues développeurs sur Ubuntu soient en mesure de mieux vous connaître.
Lorsque vous enregistrez un nouveau compte, Launchpad envoie un courriel avec un lien que vous devez ouvrir dans votre navigateur afin de faire vérifier votre adresse de courriel. Si vous ne le recevez pas, vérifiez dans votre dossier de pourriel.
La page d’aide nouveau compte sur Launchpad contient plus d’informations sur le processus et les paramètres supplémentaires que vous pouvez modifier.
Téléversez votre clé GPG sur Launchpad¶
First, you will need to get your fingerprint and key ID.
Pour connaître votre empreinte GPG, exécutez :
$ gpg --fingerprint email@address.com
et cela affichera quelque chose comme :
pub 4096R/43CDE61D 2010-12-06
Key fingerprint = 5C28 0144 FB08 91C0 2CF3 37AC 6F0B F90F 43CD E61D
uid Daniel Holbach <dh@mailempfang.de>
sub 4096R/51FBE68C 2010-12-06
Then run this command to submit your key to Ubuntu keyserver:
$ gpg --keyserver keyserver.ubuntu.com --send-keys 43CDE61D
where 43CDE61D should be replaced by your key ID (which is in the first line of output of the previous command). Now you can import your key to Launchpad.
Dirigez-vous vers https://launchpad.net/~/+editpgpkeys et copiez le fichier “Key fingerprint” dans la zone de texte. Dans le cas ci-dessus ce serait 5C28 0144 FB08 91C0 2CF3 37AC 6F0B F90F 43CD E61D. Ensuite, cliquez sur “Importer la clé”.
Launchpad utilise l’empreinte pour vérifier votre clé sur le serveur de trousseau d’Ubuntu et, en cas de succès, vous envoie un courriel crypté vous demandant de confirmer l’import de la clé. Vérifiez votre compte de messagerie et lisez le courriel envoyé par Launchpad. Si votre client de messagerie prend en charge le chiffrement OpenPGP, il vous demandera d’entrer le mot de passe choisi pour la clé lors de la génération GPG. Entrez le mot de passe, puis cliquez sur le lien pour confirmer que la clé est la vôtre.
Launchpad chiffre le courriel en utilisant votre clé publique, ce qui assure que votre clé vous est propre. Si vous utilisez Thunderbird, le client de messagerie par défaut d’Ubuntu, vous pouvez installer le greffon Enigmail pour déchiffrer aisément le message. Si votre logiciel de messagerie ne prend pas OpenPGP en charge, copiez le contenu du courriel chiffré, tapez gpg dans une fenêtre de terminal, puis collez-y le contenu du courriel.
De retour sur le site Launchpad, utilisez le bouton “Confirmer” et Launchpad terminera l’import de votre clé OpenPGP.
Vous trouverez plus d’informations sur https://help.launchpad.net/YourAccount/ImportingYourPGPKey
Téléchargez votre clé SSH vers Launchpad¶
Ouvrez https://launchpad.net/~/+editsshkeys dans un navigateur internet, ainsi que ~/.ssh/id_rsa.pub dans un éditeur de texte. Il s’agit de la partie publique de votre clé SSH, il est donc sûr de la partager avec Launchpad. Copiez le contenu du fichier et collez-le dans la zone de texte sur la page Web affichant “Ajouter une clé SSH”. Ensuite, cliquez sur “Importer la clé publique”.
Pour plus d’informations sur ce processus, veuillez consulter la page créer une paire de clés SSH sur Launchpad.
Configurer Bazaar¶
Bazaar est l’outil que nous utilisons pour stocker de manière logique les modifications de code, échanger des propositions de modifications et les fusionner, même si le développement est en cours. Il est utilisé dans la nouvelle méthode de Développement des Distributions Ubuntu pour travailler avec les paquets Ubuntu.
Pour dire à Bazaar qui vous êtes, il suffit de lancer :
$ bzr whoami "Bob Dobbs <subgenius@example.com>"
$ bzr launchpad-login subgenius
Whoami renseigne Bazaar sur le nom et l’adresse courriel qu’il doit utiliser pour vos messages participatifs. Avec launchpad-login vous définissez votre identifiant Launchpad. De cette façon, le code que vous publiez dans Launchpad vous sera associé.
Remarque : Si vous ne vous souvenez plus de l’identifiant, allez à https://launchpad.net/~ et regardez où cela vous redirige. La partie après le “~” de l’URL est votre identifiant Launchpad.
Configurez votre shell¶
De manière similaire à Bazaar, les outils de gestion des paquets de Debian/Ubuntu ont également besoin de vous connaître. Il suffit d’ouvrir votre fichier ~/.bashrc dans un éditeur de texte et d’y rajouter à la fin quelques lignes comme :
export DEBFULLNAME="Bob Dobbs"
export DEBEMAIL="subgenius@example.com"
Maintenant, sauvegardez le fichier et redémarrez votre terminal ou exécutez :
$ source ~/.bashrc
(Si vous n’utilisez pas l’environnement par défaut, bash, veuillez modifier en conséquence le fichier de configuration pour cet environnement.)
Développement Distribué d’Ubuntu — Introduction¶
Ce guide se consacre à l’empaquetage utilisant la méthode Développement Distribué d’Ubuntu (UDD).
Ubuntu Développement Distribué (UDD) est une nouvelle technique de développement de paquets Ubuntu utilisant des outils, des processus et des flux de travail similaires à ceux du développement de logiciels basé sur des Systèmes de Contrôle de Version Distribuée (DVCS) génériques. Le DVCS utilisé pour UDD est Bazaar.
Limites de l’empaquetage traditionnel¶
Traditionnellement, les paquets Ubuntu ont été conservés dans des fichiers d’archive tar. Un paquet source traditionnel est composé de la source de l’archive tar de l’amont, d’une archive tar « debian » (ou d’un fichier compressé diff pour les paquets les plus anciens) contenant le paquet et un fichier .dsc de méta-données. Pour voir un paquet traditionnel, lancez :
$ apt-get source kdetoys
Cela va télécharger la source de l’amont kdetoys_4.6.5.orig.tar.bz2, l’empaquetage kdetoys_4.6.5-0ubuntu1.debian.tar.gz et les méta-données kdetoys_4.6.5-0ubuntu1~ppa1.dsc. En supposant que vous avez installé dpkg-dev, cela les décompressera et vous donnera le paquet source.
L’empaquetage traditionnel éditerait ces fichiers et les téléchargerait. Cependant, cela limite les occasions de collaborer avec d’autres développeurs, les modifications doivent être passées sous forme de fichiers diff sans moyen centralisé de les tracer et deux développeurs ne peuvent pas apporter des modifications au même instant. Ainsi, la plupart des équipes ont déplacé leurs empaquetages dans un système de contrôle de révision. Cela facilite le travail commun de plusieurs développeurs sur un paquet. Cependant, il n’existe aucun lien direct entre le système de contrôle de révision et les paquets d’archive, ainsi les deux doivent être synchronisés manuellement. Depuis que chaque équipe travaille dans son propre système de contrôle de révision, un potentiel développeur doit d’abord déterminer la localisation et comment obtenir l’empaquetage avant de pouvoir travailler sur le paquet.
Développement Distribué Ubuntu¶
Avec le Développement Distribué Ubuntu, tous les paquets de l’archive Ubuntu (et Debian) sont automatiquement importés sous forme de branches Bazaar sur notre site Launchpad d’hébergement de code. Les modifications sont apportées directement à ces branches en étapes successives par toute personne ayant une autorisation d’engagement. Les modifications peuvent aussi être réalisées dans des branches dérivées puis fusionnées de nouveau avec Fusionner les Propositions, lorsqu’elles sont assez grandes pour nécessiter une relecture ou si elles sont engagées par une personne sans autorisation directe d’engagement.
Les branches UDD sont toutes dans un emplacement standard, facilitant leur extraction :
$ bzr branch ubuntu:kdetoys
L’historique des fusions inclut deux branches distinctes, l’une pour la source de l’amont, et l’autre qui ajoute le répertoire d’empaquetage debian/ :
$ cd kdetoys
$ bzr qlog
(Cette commande utilise qbzr. Pour une interface graphique utilisateur, exécutez log au lieu de qlog pour une interface console.)

Cette branche UDD de kdetoys montre l’empaquetage complet pour chaque version téléchargée vers Ubuntu avec des cercles gris et les versions sources de l’amont avec des cercles verts. Les versions sont étiquetées soit avec leur version dans Ubuntu telle que 4:4.2.29-0ubuntu1 ou pour la branche de l’amont, avec leur version de l’amont upstream-4.2.96.
De nombreux paquets Ubuntu sont basés sur des paquets de Debian, UDD importe aussi les paquets Debian dans nos branches. Dans la branche kdetoys ci-dessus, les versions Debian à partir de unstable sont depuis la fusion avec des cercles bleus alors que ceux de Debian experimental sont avec des cercles jaunes. Les versions Debian sont étiquetées avec leur numéro de version, par exemple, 4:4.2.2-1.
Ainsi, depuis une branche UDD, vous pouvez voir l’historique complet des modifications du paquet et comparer n’importe quelle version entre elles. Par exemple, pour voir les changements entre la version 4.2.2 dans Debian et la 4.2.2 dans Ubuntu, utilisez :
$ bzr qdiff -r tag:4:4.2.2-1..tag:4:4.2.2-1ubuntu1
(Cette commande utilise qbzr. Pour une interface graphique utilisateur, exécutez diff au lieu de qdiff pour une interface console.)

A partir de là, nous pouvons clairement voir ce qui a changé dans Ubuntu par rapport à Debian, très pratique.
Bazaar¶
Les branches UDD utilisent Bazaar, un système de contrôle des versions distribuées conçu pour être facile à utiliser pour les familiers de systèmes populaires comme Subversion, tout en offrant la puissance de Git.
Pour réaliser des empaquetages avec UDD, vous devrez connaître les bases de l’utilisation de Bazaar pour gérer les fichiers. En guise d’introduction à Bazaar, regardez le Tutoriel Bazaar en Cinq Minutes et le Guide de l’utilisateur Bazaar.
Limites de l’UDD¶
Le Développement Distribué d’Ubuntu est une nouvelle méthode de travail avec les paquets Ubuntu. Elle compte actuellement quelques limitations importantes :
Réaliser une branche complète avec historique peut prendre beaucoup de temps et de ressources réseau. Vous trouverez plus rapide d’effectuer une vérification allégée avec bzr checkout --lightweight ubuntu:kdetoys mais cela nécessitera un accès réseau pour les opérations bzr ultérieures.
Travailler avec des correctifs est fastidieux. Les correctifs peuvent êtres considérés comme un Système de Contrôle de Révision ramifié, ainsi nous nous retrouvons avec un SCR par-dessus un SCR.
Il est impossible de construire directement depuis les branches. Vous devez créer un paquet source et le télécharger.
Certains paquets n’ont pas été importés correctement dans les branches UDD. Les versions récentes de Bazaar vous l’indiqueront automatiquement le cas échéant. Vous pouvez également vérifier manuellement le statut de l’importateur de paquet avant de travailler sur une branche.
Tout ce qui précède est en cours d’élaboration et UDD est appelé à devenir prochainement le principal moyen de travailler sur les paquets Ubuntu. Cependant, la plupart des équipes actuellement dans Ubuntu ne travaille pas encore avec les branches UDD pour leur développement. Toutefois, puisque les branches UDD sont les mêmes que les paquets dans l’archive, n’importe quelle équipe devrait être en mesure d’accepter leurs fusions respectives.
Correction d’un bogue dans Ubuntu¶
Introduction¶
Si vous avez suivi les instructions pour obtenir la configuration de Ubuntu Développement, vous devriez être configuré et prêt à commencer.

Comme vous pouvez le constater dans l’image ci-dessus, il n’y a pas de surprises dans le processus de correction des bogues dans Ubuntu : vous découvrez un problème, vous obtenez le code, vous travaillez sur le correctif, le testez, soumettez vos modifications dans Launchpad et demandez à ce qu’elles soient examinées puis fusionnées. Dans ce guide, nous allons passer toutes les étapes nécessaires une par une.
Trouver le problème¶
Il existe de nombreuses façons de trouver des choses sur lesquelles travailler. Ce sera peut-être un rapport de bogue que vous-même pouvez rencontrer (ce qui vous donne une bonne occasion de tester le correctif), ou un problème relevé par ailleurs, éventuellement dans un rapport de bogue.
Harvest est l’endroit où nous gardons la trace des différentes listes de choses à faire en matière de développement Ubuntu. Harvest répertorie les bogues déjà résolus en amont ou dans Debian, ainsi que les petits bogues (que nous appelons « bitesize »), etc. Regardez cela et trouvez votre premier bogue à corriger.
Déterminer ce qu’il faut corriger¶
Si vous ne connaissez pas le paquet source contenant le code problématique, mais que vous connaissez le chemin du programme concerné sur votre système, vous pouvez découvrir sur quel paquet source vous pourrez travailler.
Admettons que vous ayez trouvé un bogue dans Tomboy, une application de prise de notes sur le bureau. L’application Tomboy peut être démarrée en exécutant /usr/bin/tomboy en ligne de commande. Pour trouver le paquet binaire contenant cette application, utilisez la commande :
$ apt-file find /usr/bin/tomboy
Cela affichera :
tomboy: /usr/bin/tomboy
Notez que la partie précédant les deux points est le nom du paquet binaire. Il arrive souvent que le paquet source et le paquet binaire aient des noms différents. Ceci est généralisé lorsqu’un paquet source unique est utilisé pour construire plusieurs paquets binaires différents. Pour trouver le paquet source d’un paquet binaire particulier, tapez :
$ apt-cache showsrc tomboy | grep ^Package:
Package: tomboy
$ apt-cache showsrc python-vigra | grep ^Package:
Package: libvigraimpex
apt-cache fait partie de l’installation standard d’Ubuntu.
Obtenir le code¶
Une fois que vous connaissez le paquet source à corriger, vous souhaiterez obtenir une copie du code sur votre système, de sorte que vous puissiez le déboguer. Dans le développement de la distribution Ubuntu, on y arrive par ramification du paquet source vers une branche correspondant au paquet source. Launchpad gère les branches de paquets source pour tous les paquets dans Ubuntu.
Une fois que vous avez obtenu une branche locale du paquet source, vous pouvez étudier le bogue, créer un correctif et télécharger votre proposition de correction vers Launchpad sous la forme d’une branche Bazaar. Lorsque vous êtes satisfait de votre solution, vous pouvez soumettre une proposition de fusion, qui demande à d’autres développeurs d’Ubuntu d’examiner et approuver la modification. S’ils sont d’accord avec vos modifications, un développeur Ubuntu téléchargera la nouvelle version du paquet vers Ubuntu afin que chacun obtienne le bénéfice de votre excellente solution - et vous gagnez un peu en crédit. Vous êtes désormais sur la bonne voie pour devenir un développeur Ubuntu !
Nous allons décrire en détail la façon de ramifier le code, de soumettre votre solution et d’en demander un examen dans les sections suivantes.
Travailler sur un correctif¶
Il existe des livres entiers sur la façon de trouver des bogues, de les corriger, de les tester, etc. Si vous êtes complètement novice en programmation, essayez en premier lieu de corriger les bogues simples comme les fautes de frappe évidentes. Essayez de minimiser les changements autant que possible et documentez clairement vos modifications et hypothèses.
Avant de travailler sur un correctif vous-même, assurez-vous de vérifier que personne d’autre ne l’a déjà corrigé ou est en train de le faire. Les bonnes sources à vérifier sont :
Traceur de bogues en amont (et dans Debian) (bogues ouverts et fermés),
Historique des révisions en amont (ou version plus récente) pourrait avoir résolu le problème,
des bogues ou des ajouts de paquets de distributions Debian ou autres.
Vous souhaitez maintenant créer un correctif incluant la solution. La commande edit-patch est une façon simple d’ajouter un correctif à un paquet. Lancez :
$ edit-patch 99-new-patch
Cela va copier l’empaquetage dans un répertoire temporaire. Vous pouvez maintenant éditer les fichiers avec un éditeur de texte ou appliquer des correctifs en amont, par exemple:
$ patch -p1 < ../bugfix.patch
Après avoir modifié le fichier, saisissez exit ou appuyez sur ctrl-d pour quitter l’environnement temporaire. Le nouveau correctif a été ajouté dans debian/patches.
Tester le correctif¶
Pour construire un paquet de test avec vos modifications, exécutez ces commandes:
$ bzr builddeb -- -S -us -uc
$ pbuilder-dist <release> build ../<package>_<version>.dsc
Cela créera un paquet source à partir des contenus de la ramification (-us -uc permettra de s’affranchir de l’étape de signature du paquet source) et pbuilder-dist construira le paquet à partir des sources de la version de votre choix.
Une fois la construction réussie, installez le paquet depuis ~/pbuilder/<release>_result/ (en utilisant sudo dpkg -i <paquet>_<version>.deb). Puis testez pour vérifier si le bogue est corrigé.
Documenter le correctif¶
Il est très important de documenter abondamment vos modifications afin que les développeurs qui reliront votre code dans le futur n’aient pas à deviner ce qu’étaient votre raisonnement et vos hypothèses. Chaque paquet source Debian et Ubuntu inclut debian/changelog, où les modifications de chaque paquet téléchargé sont suivies.
Le moyen le plus simple de mettre à jour est d’exécuter :
$ dch -i
Cela vous ajoute une entrée passe-partout du changelog et lance un éditeur dans lequel vous pourrez remplir les blancs. Un exemple de ceci pourrait être :
specialpackage (1.2-3ubuntu4) trusty; urgency=low
* debian/control: updated description to include frobnicator (LP: #123456)
-- Emma Adams <emma.adams@isp.com> Sat, 17 Jul 2010 02:53:39 +0200
dch doit déjà remplir pour vous la première et la dernière ligne d’une telle entrée du changelog. La ligne 1 se compose du nom du paquet source, du numéro de version, de la version d’Ubuntu vers laquelle le paquet est transféré, du niveau d’urgence (qui est presque toujours «{nbsp]faible »). La dernière ligne contient toujours le nom, l’adresse électronique et l’horodatage du changement (au format RFC 5322).
Ces préoccupations en moins, concentrons-nous sur l’entrée effective du changelog elle-même : il est très important de renseigner :
où la modification a été apportée
ce qui a été modifié
où le débat sur la modification s’est passé
Dans notre (très rare) exemple, le dernier point est couvert par (LP: #123456) se référant au bogue Launchpad 123456. Les rapports de bogues ou des fils de listes de diffusion ou les spécifications sont généralement de bonnes informations à fournir comme justification d’un changement. En prime, si vous utilisez la notation LP: #<numéro> pour les bogues sur Launchpad, le bogue sera automatiquement fermé quand le paquet correctif sera téléchargé vers Ubuntu.
Soumettre le correctif¶
Avec l’entrée du changelog écrite et enregistrée, il vous suffit de lancer :
debcommit
et la modification sera soumise (localement) avec votre entrée changelog comme message de soumission.
Pour le soumettre à Launchpad, en tant que nom de la branche distante, vous devez vous conformer à la nomenclature suivante :
lp:~<yourlpid>/ubuntu/<release>/<package>/<branchname>
Cela pourrait être, par exemple :
lp:~emmaadams/ubuntu/trusty/specialpackage/fix-for-123456
Donc, si vous lancez simplement :
bzr push lp:~emmaadams/ubuntu/trusty/specialpackage/fix-for-123456
bzr lp-propose
vous devriez être entièrement configuré. La commande push doit le soumettre à Launchpad et la seconde commande ouvre la page Launchpad de la branche distante dans votre navigateur. Trouvez alors le lien « (+) Proposer à la fusion », cliquez dessus afin que quelqu’un examine les modifications et qu’elles soient incluses dans Ubuntu.
Notre article sur la recherche de sponsors explique plus en détail comment obtenir des commentaires sur vos modifications proposées.
Si votre branche résout des problèmes dans les versions stables ou s’il s’agit d’un correctif de sécurité, vous pouvez jeter un œil à notre article sur mises à jour de sécurité et versions stables.
Tutoriel : Correction d’un bogue dans Ubuntu¶
Alors que les mécanismes pour corriger un bogue sont les mêmes pour tous les bogues, chaque problème que vous examinez est susceptible d’être différent des autres. Un exemple de problème concret aide à se faire une idée de ce qu’il faut considérer en général.
Note
Au moment de la rédaction de cet article, ce n’était pas encore corrigé. Lorsque vous lirez l’article ce pourrait effectivement être corrigé. Prenez ceci comme un exemple et essayez de l’adapter au problème spécifique auquel vous faites face.
Confirmer le problème¶
Supposons que le paquet bumprace n’a pas de page d’accueil dans sa description de paquet. Dans un premier temps, vous vérifiez si le problème n’est pas déjà résolu. C’est facile à vérifier, soit en jetant un coup d’œil à la Logithèque Ubuntu, soit en exécutant :
apt-cache show bumprace
La sortie devrait être similaire à ceci :
Package: bumprace
Priority: optional
Section: universe/games
Installed-Size: 136
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Original-Maintainer: Christian T. Steigies <cts@debian.org>
Architecture: amd64
Version: 1.5.4-1
Depends: bumprace-data, libc6 (>= 2.4), libsdl-image1.2 (>= 1.2.10),
libsdl-mixer1.2, libsdl1.2debian (>= 1.2.10-1)
Filename: pool/universe/b/bumprace/bumprace_1.5.4-1_amd64.deb
Size: 38122
MD5sum: 48c943863b4207930d4a2228cedc4a5b
SHA1: 73bad0892be471bbc471c7a99d0b72f0d0a4babc
SHA256: 64ef9a45b75651f57dc76aff5b05dd7069db0c942b479c8ab09494e762ae69fc
Description-en: 1 or 2 players race through a multi-level maze
In BumpRacer, 1 player or 2 players (team or competitive) choose among 4
vehicles and race through a multi-level maze. The players must acquire
bonuses and avoid traps and enemy fire in a race against the clock.
For more info, see the homepage at http://www.linux-games.com/bumprace/
Description-md5: 3225199d614fba85ba2bc66d5578ff15
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Origin: Ubuntu
Un contre-exemple serait gedit, qui dispose d’une page d’accueil :
$ apt-cache show gedit | grep ^Homepage
Homepage: http://www.gnome.org/projects/gedit/
$
Parfois, vous constaterez qu’un problème particulier sur lequel vous vous penchez est déjà corrigé. Pour éviter le gaspillage des efforts et le travail en doublon, il est logique de commencer par un petit travail de détective.
Localisation de bogue¶
En premier lieu, nous devons vérifier l’existence préalable d’un bogue pour ce problème dans Ubuntu. Peut-être que quelqu’un travaille déjà sur un correctif, ou nous pouvons contribuer à la solution d’une manière ou d’une autre. Pour Ubuntu, nous jetons un coup d’œil à https://bugs.launchpad.net/ubuntu/+source/bumprace et constatons qu’aucun bogue n’y est ouvert avec notre problème.
Note
Pour Ubuntu, l’URL https://bugs.launchpad.net/ubuntu/+source/<paquet> devrait toujours afficher la page concernant les bogues du paquet source en question.
Pour Debian, qui est la principale source des paquets d’Ubuntu, nous jetons un œil sur http://bugs.debian.org/src:bumprace et nous ne pouvons de nouveau pas trouver de rapport de bogue pour notre problème.
Note
Pour Debian, l’URL http://bugs.debian.org/src:<paquet> devrait toujours afficher la page concernant les bogues du paquet source en question.
Le problème sur lequel nous travaillons est spécifique, car il concerne uniquement les bits d’empaquetage liés à bumprace. Si le problème se trouvait dans le code source, il serait utile de vérifier également le traceur de bogues en amont. Malheureusement, il arrive souvent que cela soit différent à chaque paquet examiné ; mais si vous effectuez une recherche sur internet, vous devriez le trouver facilement dans la plupart des cas.
Offrir de l’aide¶
Si vous avez trouvé un bogue ouvert, qu’il n’est affecté à personne et que vous êtes en mesure de régler le problème, vous pouvez le commenter avec votre solution. N’oubliez pas d’inclure autant d’informations que possible : dans quelles circonstances se produit le bogue ? Comment avez-vous résolu le problème ? Avez-vous testé votre solution ?
Si aucun rapport de bogue n’a été déposé, vous pouvez en déposer un. Une chose que vous devriez garder à l’esprit est : Le problème est-il si petit qu’une simple demande de réalisation serait suffisante ? Avez-vous réussi à partiellement résoudre le problème et vous voulez au moins partager votre partie de la solution ?
C’est très bien si vous pouvez offrir votre aide, et elle sera assurément appréciée.
Résoudre le problème¶
Pour cet exemple spécifique, il suffit de chercher bumprace sur internet et de trouver sa page d’accueil. Assurez-vous qu’il s’agisse du vrai site et non d’un simple catalogue de logiciels. http://www.linux-games.com/bumprace/ semble être sa bonne localisation.
Pour résoudre le problème dans le paquet source, nous avons d’abord besoin de la source et nous pouvons facilement l’obtenir en exécutant :
bzr branch ubuntu:bumprace
Si vous avez précédemment lu la Présentation du répertoire Debian, vous vous rappellerez que la page d’accueil d’un paquet est spécifiée dans la première partie de debian/control, la section débutant par Source:.
Ainsi, nous lançons ensuite :
cd bumprace
et modifions debian/control pour y ajouter Homepage: http://www.linux-games.com/bumprace/. La fin de la première section est un bon endroit pour cela. Une fois que vous avez réalisé cela, enregistrez le fichier.
Si désormais vous exécutez :
bzr diff
vous devriez voir quelque chose ressemblant à ceci :
=== modified file 'debian/control'
--- debian/control 2012-05-14 23:38:14 +0000
+++ debian/control 2012-09-03 15:45:30 +0000
@@ -12,6 +12,7 @@
libtool,
zlib1g-dev
Standards-Version: 3.9.3
+Homepage: http://www.linux-games.com/bumprace/
Package: bumprace
Architecture: any
La différence est assez simple à comprendre. Le + indique une ligne rajoutée. Dans notre cas, elle a été ajoutée juste avant la seconde section, débutant par Package, qui indique le paquet binaire résultant.
Documenter le correctif¶
Il est important d’expliquer à vos collègues développeurs ce que vous avez fait exactement. Si vous exécutez :
dch -i
cela lance un éditeur avec une entrée passe-partout de changelog que vous avez juste à compléter. Dans notre cas, quelque chose comme debian/control: Added project's homepage. devrait le faire. Enregistrez ensuite le fichier. Pour revérifier la prise en compte, exécutez :
bzr diff debian/changelog
et vous verrez quelque chose comme ceci :
=== modified file 'debian/changelog'
--- debian/changelog 2012-05-14 23:38:14 +0000
+++ debian/changelog 2012-09-03 15:53:52 +0000
@@ -1,3 +1,9 @@
+bumprace (1.5.4-1ubuntu1) UNRELEASED; urgency=low
+
+ * debian/control: Added project's homepage.
+
+ -- Peggy Sue <peggy.sue@example.com> Mon, 03 Sep 2012 17:53:12 +0200
+
bumprace (1.5.4-1) unstable; urgency=low
* new upstream version, sound and music have been removed (closes: #613344)
Quelques remarques complémentaires :
Si vous faites référence à un numéro Launchpad du bogue résolu par votre publication, ajoutez (LP: #<numéro de bogue>) sur la ligne d’entrée du changelog, c’est à dire : (LP: #123456).
Si vous souhaitez que votre correctif soit inclus dans Debian, la syntaxe pour un bogue Debian est (Closes: #<numéro de bogue>), c’est à dire : (Closes: #123456).
S’il s’agit d’une référence à un bogue amont ou un bogue Debian ou encore une discussion par liste de diffusion email, vous pouvez le mentionner également.
Essayez de limiter vos lignes à 80 caractères.
Essayez d’être concis, pas de roman, mais suffisamment pour que quelqu’un (qui ne s’est pas profondément penché sur la question) puisse comprendre.
Indiquez comment vous avez résolu le problème et où.
Tester le correctif¶
Pour tester le correctif, vous devez avoir configuré votre environnement de développement, puis pour construire le paquet, l’installer et vérifier que le problème est résolu. Dans notre cas, ce serait :
bzr bd -- -S
pbuilder-dist <current Ubuntu release> build ../bumprace_*.dsc
dpkg -I ~/pbuilder/*_result/bumprace_*.deb
Dans la première étape nous construisons le paquet source depuis la ramification, puis le construisons en utilisant pbuilder, et inspectons ensuite le paquet résultant pour vérifier si le champ « Page d’accueil » a été correctement ajouté.
Note
Dans de nombreux cas vous devrez réellement installer le paquet pour vous assurer qu’il fonctionne comme prévu. Notre cas est largement plus simple. Si la construction réussit, vous trouverez les paquets binaires dans ~/pbuilder/<release>_result. Installez-les à l’aide de la commande sudo dpkg -i <package>.deb ou en double-cliquant dessus dans votre gestionnaire de fichiers.
Puisque nous l’avons vérifié, le problème est désormais résolu. La prochaine étape est de partager notre solution avec tout le monde.
Obtenir l’inclusion du correctif¶
Cela permet d’inclure le correctif le plus en amont possible. Procéder ainsi garantit que chacun puisse prendre la source en amont telle quelle et n’ait pas besoin d’effectuer des modifications en local pour la corriger.
Dans notre cas, nous avons établi que nous avions un problème avec l’empaquetage, à la fois dans Ubuntu et Debian. Comme Ubuntu est basé sur Debian, nous ferons parvenir le correctif à Debian. Une fois que celui-ci y sera inclus, il sera repris par la suite dans Ubuntu. Le problème dans notre tutoriel est clairement non critique, donc cette approche est logique. S’il est important de corriger le problème dès que possible, vous devrez envoyer la solution à plusieurs traceurs de bogues. Pourvu que le problème affecte toutes les parties en cause.
Pour soumettre le patch à Debian, lancez simplement :
submittodebian
Cela vous mènera à travers une série de mesures pour vous assurer que le bogue se retrouve au bon endroit. Assurez-vous de contrôler de nouveau la différence pour être certain qu’elle ne comprenne aucune modification antérieure non désirée.
La communication est importante, lorsque vous ajoutez une description à votre demande d’inclusion, soyez gentil de bien l’expliquer.
Si tout s’est bien déroulé, vous obtenez un message du système de suivi des bogues Debian avec plus d’informations. Cela peut parfois prendre quelques minutes.
Note
Si le problème est uniquement dans Ubuntu, vous pourriez envisager de Rechercher des relectures et des parrainages pour obtenir l’inclusion du correctif.
Considérations supplémentaires¶
Si vous trouvez qu’il y a un certain nombre de choses triviales possibles à corriger en même temps dans un paquet, faites-le. Cela permettra d’accélérer l’examen et l’inclusion.
S’il y a plusieurs choses importantes que vous souhaitez corriger, il pourrait être plus judicieux d’envoyer des correctifs individuels ou de fusionner des propositions. S’il y a déjà des bogues individuels déposés sur le sujet, cela rend la chose encore plus aisée.
L’empaquetage de nouveaux logiciels¶
Bien qu’il existe des milliers de paquets dans l’archive d’Ubuntu, il y en reste encore beaucoup que personne n’a pu obtenir jusqu’à maintenant. S’il existe une nouvelle et passionnante partie de logiciel pour laquelle vous sentez le besoin d’une exposition plus large, peut-être voudriez-vous vous essayer à la création d’un paquet pour Ubuntu ou d’un PPA. Ce guide vous mènera à travers les étapes d’empaquetage de nouveaux logiciels.
Vous aurez envie en premier lieu de lire l’article Mise en route afin de préparer votre environnement de développement.
Vérification du programme¶
La première étape de l’empaquetage est d’obtenir le fichier .tar issu de l’amont (nous appelons les auteurs d’applications « l’amont ») et de vérifier qu’il se compile et s’exécute.
Ce guide vous mènera à travers l’empaquetage d’une application simple, appelée GNU Bonjour, postée sur GNU.org.
Si vous n’avez pas les outils de compilation, assurez-vous de les obtenir au préalable. De même, si vous n’avez pas les dépendances requises, installez-les également.
Installez les outils de compilation :
$ sudo apt-get install build-essential
Téléchargez le paquet principal :
$ wget -O hello-2.7.tar.gz "http://ftp.gnu.org/gnu/hello/hello-2.7.tar.gz"
Maintenant, décompressez le paquet principal :
$ tar xf hello-2.7.tar.gz
$ cd hello-2.7
Cette application utilise le système de construction autoconf, nous exécuterons donc ./configure pour préparer la compilation.
Cela vérifiera les dépendances de construction nécessaires. Comme bonjour est un exemple simple, build-essential doit fournir tout ce dont nous avons besoin. Pour les programmes plus complexes, la commande échouera si vous n’avez pas les bibliothèques et les fichiers de développement nécessaires. Installez les paquets nécessaires et recommencez jusqu’à ce que la commande s’exécute avec succès.:
$ ./configure
Maintenant vous pouvez compiler la source :
$ make
Si la compilation se termine avec succès, vous pouvez installer et exécuter le programme :
$ sudo make install
$ hello
Commencer un paquet¶
bzr-builddeb inclut un greffon pour créer un nouveau paquet à partir d’un modèle. Ce greffon est une surcouche de la commande dh_make. Ces programmes devraient déjà être présents si vous avez installé packaging-dev. Exécutez la commande fournissant le nom du paquet, le numéro de version et le chemin vers l’archive de l’amont :
$ sudo apt-get install dh-make
$ cd ..
$ bzr dh-make hello 2.7 hello-2.7.tar.gz
Lorsqu’il vous est demandé le type de paquet, entrez s pour binaire unique. Ceci importera le code dans une branche et ajoutera le répertoire d’empaquetage debian/. Jetez un œil sur son contenu. La plupart des fichiers ajoutés ne sont nécessaires que pour les paquets spécialisés (tels que les modules d’Emacs) de sorte que vous pouvez commencer par supprimer les fichiers optionnels d’exemple :
$ cd hello/debian
$ rm *ex *EX
Vous devriez maintenant personnaliser chacun des fichiers.
In debian/changelog change the version number to an Ubuntu version: 2.7-0ubuntu1 (upstream version 2.7, Debian version 0, Ubuntu version 1). Also change unstable to the current development Ubuntu release such as trusty.
Le gros du travail de construction de paquet est réalisé par une série de scripts appelée debhelper. Le comportement exact de debhelper change avec les nouvelles versions majeures, le fichier compat indique à debhelper à quelle version se conformer. Vous souhaiterez généralement régler ce paramètre à la version la plus récente qui est 9.
control contient toutes les métadonnées du paquet. Le premier paragraphe décrit le paquet source. Les paragraphes suivants décrivent les paquets binaires à construire. Nous aurons besoin d’ajouter à Build-Depends: les paquets nécessaires pour compiler l’application. Pour bonjour, assurez-vous qu’il comprend au moins :
Build-Depends: debhelper (>= 9)
Vous devrez également remplir une description du programme dans le champ Description:.
Le copyright doit être rempli pour suivre la licence de la source en amont. Selon le fichier bonjour/COPYING, il s’agit de la licence GNU GPL 3 ou ultérieure.
docs contient les fichiers de documentation de l’amont qui, selon vous, devraient être inclus dans le paquet final.
README.source et README.Debian ne sont nécessaires que si votre paquet possède une caractéristique non standard, ce qui n’est pas le cas donc vous pouvez les supprimer.
source/format peut être laissé tel quel, il décrit le format de version du paquet source et devrait être 3.0 (quilt).
rules est le fichier le plus complexe. Il s’agit d’un Makefile qui compile le code et le transforme en un paquet binaire. Heureusement, le gros du travail se fait de nos jours automatiquement à l’aide de debhelper 7 de telle sorte que la cible universelle % du Makefile lance uniquement le script dh qui exécute toutes les opérations nécessaires.
Tous ces fichiers sont expliqués plus en détail dans l’article aperçu du répertoire Debian.
Enfin, soumettez le code à votre branche d’empaquetage :
$ bzr commit -m "Initial commit of Debian packaging."
Construisez le paquet¶
Maintenant, nous devons vérifier que notre empaquetage compile le paquet correctement et construit le paquet binaire .deb :
$ bzr builddeb -- -us -uc
$ cd ../../
bzr builddeb est une commande pour construire le paquet dans son emplacement actuel. Le -us -uc indique que GPG n’a pas besoin de signer le paquet. Le résultat sera placé dans le dossier ...
Vous pouvez afficher le contenu du paquet avec :
$ lesspipe hello_2.7-0ubuntu1_amd64.deb
Install the package and check it works (later you will be able to uninstall it using sudo apt-get remove hello if you want):
$ sudo dpkg --install hello_2.7-0ubuntu1_amd64.deb
You can also install all packages at once using:
$ sudo debi
Étapes suivantes¶
Même si votre paquet binaire .deb est construit, l’empaquetage peut contenir des bogues. De nombreuses erreurs peuvent être détectées automatiquement par notre outil lintian pouvant être exécuté soit sur le fichier source de métadonnées .dsc, soit sur le paquet binaire .deb :
$ lintian hello_2.7-0ubuntu1.dsc
$ lintian hello_2.7-0ubuntu1_amd64.deb
Une description de chacun des problèmes rapportés est disponible sur le site Internet lintian.
Après avoir établi un correctif pour l’empaquetage, vous pouvez le reconstruire en utilisant -nc pour « no clean » afin d’éviter d’avoir à le reconstruire à partir de zéro :
$ bzr builddeb -- -nc -us -uc
Après avoir vérifié que le paquet est construit localement, vous devez vous assurer qu’il peut se compiler sur un système propre à l’aide de pbuilder. Puisque nous allons bientôt l’ajouter à un PPA (Personal Package Archives), ce téléchargement doit être signé pour permettre à Launchpad de vérifier que le téléchargement émane de vous (vous pouvez dire que le téléchargement sera signé car les options -us et -uc ne sont pas transmises à bzr builddeb comme auparavant). Pour que la signature fonctionne, vous devez avoir configuré GPG. Si vous n’avez pas encore configuré pbuilder-dist ou GPG, faites le maintenant :
$ bzr builddeb -S
$ cd ../build-area
$ pbuilder-dist trusty build hello_2.7-0ubuntu1.dsc
Lorsque vous serez satisfait de votre paquet, vous souhaiterez en obtenir la relecture par d’autres. Vous pouvez télécharger la branche vers Launchpad pour la relecture :
$ bzr push lp:~<lp-username>/+junk/hello-package
Le télécharger vers un PPA assurera qu’il se construit et donnera un moyen aisé pour vous et les autres de tester les paquets binaires. Vous avez besoin de configurer un PPA dans Launchpad puis de télécharger avec dput :
$ dput ppa:<lp-username>/<ppa-name> hello_2.7-0ubuntu1.changes
Voir téléchargement pour plus d’informations.
Vous pouvez demander des relectures sur le canal IRC #ubuntu-motu, ou sur la liste de diffusion MOTU. Vous pourriez également interroger une équipe plus spécifique, comme l’équipe de GNU pour des questions plus pointues.
Soumettez pour inclusion¶
Il existe nombre de chemins que peut emprunter un paquet pour entrer dans Ubuntu. Dans la plupart des cas, passer par Debian en premier peut s’avérer la meilleure voie. Cette façon vous assure que votre paquet atteindra le plus grand nombre d’utilisateurs, car il sera disponible non seulement dans Debian et Ubuntu, mais également dans l’ensemble de leurs dérivés. Voici quelques liens utiles pour soumettre de nouveaux paquets à Debian :
La foire aux questions Debian Mentors FAQ des tuteurs Debian existe pour le tutorat des nouveaux et futurs développeurs Debian. C’est là que vous trouverez un parrain pour télécharger votre paquet vers l’archive.
Paquets en devenir ou en cours de travail - Renseignements sur la façon de déposer des « intentions de Paquets » et des « Requêtes pour les bogues de Paquet » mais aussi la liste de ces Intentions et Requêtes actuellement ouvertes.
Référence du développeur Debian, 5.1. Les nouveaux paquets - L’ensemble du document est inestimable tout autant pour les empaqueteurs Ubuntu ou Debian. Cette section documente les processus de soumission de nouveaux paquets.
Dans certains cas, il peut être judicieux d’aller directement dans Ubuntu en premier. Par exemple, Debian peut se trouver en phase de gel rendant peu probable le fait que votre paquet fasse partie d’Ubuntu à temps pour la prochaine version. Ce processus est documenté dans la section « Nouveaux paquets » du wiki d’Ubuntu.
Captures d’écran¶
Une fois que vous avez téléversé un paquet vers debian, vous devez ajouter des captures d’écran pour permettre aux utilisateurs potentiels de voir à quoi le programme ressemble. Elles doivent être téléversées sur http://screenshots.debian.net/upload.
Mises à jour de sécurité et de version stable¶
Correction d’un bogue de sécurité dans Ubuntu¶
Introduction¶
La résolution de bogues de sécurité dans Ubuntu n’est pas vraiment différente de :doc:` la résolution d’un bogue normal dans Ubuntu<./fixing-a-bug>`, et nous présumons que vous êtes familier avec la correction de bogues normaux. Pour montrer où les choses diffèrent, nous mettrons à jour le paquet dbus dans Ubuntu 12.04 LTS (Precise Pangolin) pour une mise à jour de sécurité.
L’obtention de la source¶
Dans cet exemple, nous savons déjà que nous souhaitons solutionner le paquet dbus dans Ubuntu 12.04 LTS (Precise Pangolin). Ainsi en premier lieu, vous devez déterminer la version du paquet que vous souhaiter télécharger. Nous pouvons utiliser le rmadison pour y parvenir :
$ rmadison dbus | grep precise
dbus | 1.4.18-1ubuntu1 | precise | source, amd64, armel, armhf, i386, powerpc
dbus | 1.4.18-1ubuntu1.4 | precise-security | source, amd64, armel, armhf, i386, powerpc
dbus | 1.4.18-1ubuntu1.4 | precise-updates | source, amd64, armel, armhf, i386, powerpc
Typiquement, vous souhaiterez choisir la plus récente des versions pour la corriger qui n’est ni dans -proposed ni dans -backports. Puisque nous sommes en train de mettre à jour le dbus de Precise, vous téléchargerez 1.4.18-1ubuntu1.4 depuis precise-updates :
$ bzr branch ubuntu:precise-updates/dbus
Correction de la source¶
Maintenant que nous avons le paquet source, nous avons besoin de le réparer pour corriger la vulnérabilité. Vous pouvez utiliser n’importe quelle méthode de réparation appropriée au paquet, y compris les techniques UDD, mais cet exemple va utiliser edit-patch (du paquet ubuntu-dev-tools). edit-patch est le moyen le plus aisé de corriger les paquets et il est essentiellement une surcouche de chaque système de réparation que vous pouvez imaginer.
Pour créer votre correctif en utilisant edit-patch :
$ cd dbus
$ edit-patch 99-fix-a-vulnerability
Cela appliquera les correctifs existants, et placera l’empaquetage dans un répertoire temporaire. Ensuite, éditez les fichiers nécessaires pour corriger la vulnérabilité. Souvent, l’amont a fourni un correctif afin que vous puissiez l’appliquer :
$ patch -p1 < /home/user/dbus-vulnerability.diff
Après avoir effectué les modifications nécessaires, vous appuyez simplement sur Ctrl-D ou tapez exit pour quitter l’environnement temporaire.
Formatage du changelog et des correctifs¶
Après avoir appliqué vos correctifs vous devrez mettre à jour le changelog. La commande dch est utilisée pour modifier le fichier debian/changelog et edit-patch lancera automatiquement dch après ne pas avoir appliqué tous les correctifs. Si vous n’utilisez pas edit-patch, vous pouvez lancer manuellement dch -i. Contrairement aux correctifs normaux, vous devrez utiliser le format suivant (notez que le nom de distribution utilise precise-security puisqu’il s’agit d’un mise à jour de sécurité pour Precise) pour les mises à jour de sécurité :
dbus (1.4.18-2ubuntu1.5) precise-security; urgency=low
* SECURITY UPDATE: [DESCRIBE VULNERABILITY HERE]
- debian/patches/99-fix-a-vulnerability.patch: [DESCRIBE CHANGES HERE]
- [CVE IDENTIFIER]
- [LINK TO UPSTREAM BUG OR SECURITY NOTICE]
- LP: #[BUG NUMBER]
...
Mettez à jour votre correctif pour utiliser les balises de correctifs appropriées. Votre correctif devrait avoir au minimum les balises Origine, Description et Bug-Ubuntu. Par exemple, éditer debian/patches/99-fix-a-vulnerability.patch pour obtenir quelque chose comme :
## Description: [DESCRIBE VULNERABILITY HERE]
## Origin/Author: [COMMIT ID, URL OR EMAIL ADDRESS OF AUTHOR]
## Bug: [UPSTREAM BUG URL]
## Bug-Ubuntu: https://launchpad.net/bugs/[BUG NUMBER]
Index: dbus-1.4.18/dbus/dbus-marshal-validate.c
...
De multiples vulnérabilités peuvent être corrigées dans le même téléchargement de sécurité ; il suffit de s’assurer d’utiliser des correctifs différents pour les différentes vulnérabilités.
Testez et soumettez votre travail¶
À ce stade, le processus est le même que pour corriger un bogue normal dans Ubuntu. Plus précisément, vous devrez :
Créer votre paquet et vérifier qu’il se compile sans erreur et sans aucun avertissement additionnel du compilateur
Mettre à niveau vers la nouvelle version du paquet à partir de la version précédente
Vérifier que le nouveau paquet corrige la vulnérabilité et n’introduit pas de régression
Soumettre votre travail par le biais d’une proposition de fusion sur Launchpad et déposer un rapport de bogue Launchpad en vous assurant tout d’abord de marquer le bogue comme étant un bogue de sécurité et ensuite de vous inscrire à ubuntu-security-sponsors
Si le problème de sécurité n’est pas encore public alors ne déposez pas une proposition de fusion mais assurez-vous de marquer le bogue comme privé.
Le bogue déposé doit inclure un cas de test, c’est à dire un commentaire qui explique clairement comment recréer le bogue en exécutant l’ancienne version, puis comment s’assurer que le bogue n’existe plus dans la nouvelle version.
Le rapport de bogue doit également confirmer que le problème est corrigé dans les versions Ubuntu ultérieures à celle proposée à la correction (dans l’exemple ci-dessus, plus récentes que Précise). Si le problème n’est pas corrigé dans les nouvelles versions, vous devrez préparer les mises à jour pour ces versions également.
Mises à jour vers Version Stable¶
Nous permettons aussi les mises à jour de versions où un paquet bogué a un lourd impact, comme une régression sévère depuis une version antérieure, ou un bogue qui cause des pertes de données. En raison de la capacité de telles mises à jour à introduire elles-mêmes des bogues, nous ne les autorisons que lorsque les modifications peuvent être facilement comprises et vérifiées.
Le processus des Mises à jour de version stable est exactement le même que celui des bogues de sécurité, hormis que vous devez vous inscrire à ubuntu-sru pour le bogue.
La mise à jour ira dans l’archive proposed (par exemple precise-proposed) où il sera vérifié qu’elle corrige le problème et n’introduit pas de nouveaux problèmes. Après une semaine sans problème rapporté, elle peut être déplacée vers updates.
Voir la page wiki Mises à jour vers Version Stable pour plus d’informations.
Correctifs aux paquets¶
Parfois, les mainteneurs de paquets d’Ubuntu doivent modifier le code source en amont afin de le faire fonctionner correctement avec Ubuntu. Les exemples incluent les correctifs vers l’amont qui n’ont pas encore été repris dans une version finale, ou les modifications du système de compilation de l’amont uniquement nécessaires pour la compilation avec Ubuntu. Nous pourrions modifier le code source en amont directement (mais en faisant cela il devient plus difficile d’enlever les correctifs plus tard, lorsque l’amont les a intégré) ou extraire les modifications pour les soumettre au projet de l’amont. Au lieu de ça, nous gardons ces modifications comme des correctifs séparés, sous la forme de fichiers diff.
Il existe de nombreuses façons différentes de gérer les correctifs dans les paquets Debian. Heureusement, nous sommes en cours de standardisation sur un système, Quilt, qui est désormais utilisé par la majorité des paquets.
Let’s look at an example package, kamoso in Trusty:
$ bzr branch ubuntu:trusty/kamoso
Les correctifs sont conservés dans debian/patches. Ce paquet a un correctif kubuntu_01_fix_qmax_on_armel.diff pour résoudre un échec de compilation sur ARM. Le correctif a un nom explicite pour décrire ce qu’il fait, un numéro pour garder les correctifs dans l’ordre (deux correctifs peuvent se chevaucher s’ils modifient le même fichier) et dans ce cas l’équipe de Kubuntu ajoute son propre préfixe pour montrer que le correctif provient d’eux plutôt que de Debian.
L’ordre des correctifs à appliquer est conservé dans debian/patches/series.
Les correctifs avec Quilt¶
Avant de travailler avec Quilt, vous devrez lui dire où trouver les correctifs. Ajoutez ceci à votre ~/.bashrc :
export QUILT_PATCHES=debian/patches
Et renseignez sur quel fichier appliquer le nouvel export :
$ . ~/.bashrc
Par défaut, tous les correctifs sont déjà appliqués sur les vérifications UDD ou les paquets téléchargés. Vous pouvez le vérifier avec :
$ quilt applied
kubuntu_01_fix_qmax_on_armel.diff
Si vous voulez supprimer le correctif, vous lancerez pop :
$ quilt pop
Removing patch kubuntu_01_fix_qmax_on_armel.diff
Restoring src/kamoso.cpp
No patches applied
Et pour appliquer un correctif, vous utiliserez push :
$ quilt push
Applying patch kubuntu_01_fix_qmax_on_armel.diff
patching file src/kamoso.cpp
Now at patch kubuntu_01_fix_qmax_on_armel.diff
Ajout d’un nouveau correctif¶
Pour ajouter un nouveau correctif, vous devez dire à Quilt de créer un nouveau correctif, lui dire quels sont les fichiers que le correctif doit modifier, éditer les fichiers et ensuite actualiser le correctif :
$ quilt new kubuntu_02_program_description.diff
Patch kubuntu_02_program_description.diff is now on top
$ quilt add src/main.cpp
File src/main.cpp added to patch kubuntu_02_program_description.diff
$ sed -i "s,Webcam picture retriever,Webcam snapshot program,"
src/main.cpp
$ quilt refresh
Refreshed patch kubuntu_02_program_description.diff
L’étape quilt add est importante, si vous l’oubliez les fichiers ne se retrouveront pas dans le correctif.
La modification sera désormais dans debian/patches/kubuntu_02_program_description.diff et le dossier series sera complété par le nouveau correctif. Vous devez ajouter le nouveau fichier à l’empaquetage :
$ bzr add debian/patches/kubuntu_02_program_description.diff
$ bzr add .pc/*
$ dch -i "Add patch kubuntu_02_program_description.diff to improve the program description"
$ bzr commit
Quilt conserve ses métadonnées dans le répertoire .pc/, vous devez donc actuellement l’ajouter également à l’empaquetage. Cela devrait être amélioré à l’avenir.
Comme règle générale, vous devez rester prudent dans l’ajout de correctifs aux programmes à moins qu’ils ne proviennent de l’amont, car il existe souvent une bonne raison pour que la modification n’ait pas encore été faite. L’exemple ci-dessus modifie une chaîne de l’interface par exemple, elle pourrait donc briser toutes les traductions. En cas de doute, n’hésitez pas à consulter l’auteur de l’amont avant d’ajouter un patch.
En-têtes de correctifs¶
Nous vous recommandons de marquer chaque correctif avec des en-têtes DEP-3, en les plaçant au début du fichier de correctif. Voici quelques en-têtes que vous pouvez utiliser :
Description: | Description of what the patch does. It is formatted like Description field in debian/control: first line is short description, starting with lowercase letter, the next lines are long description, indented with a space. |
---|---|
Author: | Qui a écrit le correctif (par exemple, « Jane Doe <packager@example.com> »). |
Origin: | D’où provient ce correctif (par exemple « de l’amont »), lorsque Auteur n’est pas renseigné. |
Bug-Ubuntu: | Un lien vers le traceur de bogues Launchpad, un format court étant préférable (comme https://bugs.launchpad.net/bugs/XXXXXXX). S’il existe également des bogues dans les traceurs de bogues de l’amont ou de Debian, ajoutez les en-têtes Bug ou Bug-Debian. |
Forwarded: | Si le correctif a été transmis à l’amont. Soit « yes », « no » ou « not-needed ». |
Last-Update: | Date de la dernière révision (au format “AAAA-MM-JJ”). |
Mise à niveau vers les nouvelles versions de l’amont¶
Pour mettre à niveau vers la nouvelle version, vous pouvez utiliser la commande bzr merge-upstream :
$ bzr merge-upstream --version 2.0.2 https://launchpad.net/ubuntu/+archive/primary/+files/kamoso_2.0.2.orig.tar.bz2
Lorsque vous lancez cette commande, tous les correctifs ne seront pas appliqués, car ils peuvent devenir obsolètes. Ils pourraient avoir besoin d’être actualisés, pour correspondre à la nouvelle source de l’amont, ou entièrement supprimés. Pour vérifier les problèmes, appliquez les correctifs un par un :
$ quilt push
Applying patch kubuntu_01_fix_qmax_on_armel.diff
patching file src/kamoso.cpp
Hunk #1 FAILED at 398.
1 out of 1 hunk FAILED -- rejects in file src/kamoso.cpp
Patch kubuntu_01_fix_qmax_on_armel.diff can be reverse-applied
S’il peut être rétro-appliqué, cela signifie que le correctif a déjà été appliqué par l’amont, nous pouvons donc le supprimer :
$ quilt delete kubuntu_01_fix_qmax_on_armel
Removed patch kubuntu_01_fix_qmax_on_armel.diff
Ensuite, continuons :
$ quilt push
Applied kubuntu_02_program_description.diff
C’est une bonne idée de lancer l’actualisation, cela va mettre à jour le correctif relatif à la source modifiée par l’amont :
$ quilt refresh
Refreshed patch kubuntu_02_program_description.diff
Ensuite, soumettez comme d’habitude :
$ bzr commit -m "new upstream version"
Réaliser un Paquet avec Quilt¶
Les paquets modernes utilisent Quilt par défaut, il est intégré dans le format d’empaquetage. Vérifiez dans debian/source/format que ce dernier est 3.0 (quilt).
Les paquets plus anciens utilisant le format source 1.0 vous obligent à utiliser Quilt explicitement, généralement en incluant un fichier makefile dans debian/rules.
Configurer Quilt¶
Vous pouvez utiliser le fichier ~/.quiltrc pour configurer quilt. Voici quelques options pouvant s’avérer utiles pour l’utilisation de quilt avec debian/packages :
# Set the patches directory
QUILT_PATCHES="debian/patches"
# Remove all useless formatting from the patches
QUILT_REFRESH_ARGS="-p ab --no-timestamps --no-index"
# The same for quilt diff command, and use colored output
QUILT_DIFF_ARGS="-p ab --no-timestamps --no-index --color=auto"
Autres systèmes de correctifs¶
Les autres systèmes de correctifs utilisés par les paquets incluent dpatch et cdbs simple-patchsys, qui travaillent de manière similaire à Quilt en conservant les correctifs dans debian/patches, mais possèdent des commandes différentes pour rendre applicables, non-applicables ou créer des correctifs. Vous pouvez savoir quel système de correctif est utilisé par un paquet en utilisant la commande what-patch (issue du paquet ubuntu-dev-tools). Vous pouvez utiliser edit-patch, illustré dans un chapitre précédent, comme un moyen fiable pour travailler avec tous les systèmes de correctifs.
Dans des paquets encore plus anciens, les modifications sont incluses directement aux sources et conservées dans le fichier source diff.gz. Cela rend difficile leur mise à niveau vers les nouvelles versions de l’amont ou la différenciation des correctifs. Il vaut mieux l’éviter.
Ne modifiez pas un système de correctif d’un paquet sans en discuter avec le responsable Debian ou l’équipe Ubuntu adéquate. S’il n’existe pas de système de correctif existant, alors n’hésitez pas à ajouter Quilt.
Réparation de paquets FTBFS¶
Avant qu’un paquet puisse être utilisé dans Ubuntu, il doit être compilé depuis le source. S’il échoue (on le qualifie en anglais de FTBFS « Fails To Build From Source »), il attendra probablement dans -proposed et ne sera pas disponible dans les archives Ubuntu. Vous trouverez une liste complète des paquets qui échouent à compiler depuis le source sur http://qa.ubuntuwire.org/ftbfs/. Il y a 5 catégories principales affichées sur la page :
Package failed to build (F) : (Compilation du paquet a échoué) Quelque chose s’est réellement mal passé pendant la compilation.
Cancelled build (X) : (Compilation annulée) Le processus de compilation a été annulé pour une raison ou une autre. Il faudrait probablement éviter de débuter avec.
Package is waiting on another package (M): (Le paquet attend un autre paquet) Ce paquet attend un autre paquet pour compiler, être mis à jour ou (si le paquet est dans main) une de ses dépendances est dans une mauvaise partie de l’archive.
Failure in the chroot (C) : (Échec dans le chroot) Une partie du chroot a échoué, cela a de bonnes chances d’être réparé par une recompilation. Demandez à un développeur de recompiler le paquet et il devrait être réparé.
Failed to upload (U) : (Échec du téléversement) Le paquet n’a pas pu être téléversé. Habituellement, il suffit juste de recompiler, mais vérifiez d’abord le journal de compilation.
Premiers pas¶
La première chose que vous devrez faire est de voir si vous pouvez reproduire vous-même le FTBFS. Récupérez le code soit en exécutant bzr branch lp:ubuntu/PACKAGE et en récupérant le tarball, soit en exécutant ``dget PACKAGE_DSC``sur le fichier .dsc depuis la page launchpad. Une fois que vous l’avez, compilez-le dans un schroot.
Vous devriez pouvoir reproduire le FTBFS. Sinon, vérifiez si la compilation télécharge une dépendance manquante, ce qui signifie que vous avez juste besoin d’en faire une dépendance de compilation dans debian/control. Compiler le paquet localement peut aussi aider à trouver si le problème est causé par une dépendance manquante, non listée (compile localement mais échoue sur un schroot).
Vérification de Debian¶
Une fois que vous avez reproduit le problème, il est temps d’essayer de trouver une solution. Si le paquet est aussi dans Debian, vous pouvez vérifier s’il y compile en allant à http://packages.qa.debian.org/PACKAGE. Si Debian a une version plus récente, vous devriez la fusionner. Sinon, recherchez dans les journaux de compilation et les bogues répertoriés sur cette page s’il y a des informations supplémentaires sur les ftbfs ou les correctifs. Debian tient aussi à jour une liste de commandes FTBFS (commandes qui font échouer la compilation) et ce qu’il convient de faire pour les corriger que vous trouverez à https://wiki.debian.org/qa.debian.org/FTBFS, vous devez aussi y rechercher des solutions.
ARM64¶
Ubuntu a récemment ajouté l’architecture arm64, mais de nombreux paquets échouent à compiler dessus. Une liste complète des paquets qui ne compilent pas se trouve à qa.ubuntuwire.org/ftbfs/arm64.html. Beaucoup d’entre eux sont dûs à des fichiers d’assistant autotools obsolètes. Tout paquet ayant l’avertissement lintian ancient-autotools-helper-file ou outdated-autotools-helper-file aura ce problème. En général, ajouter autotools-dev ou dh-autoreconf au processus de compilation corrige ce problème.
Autres causes de paquets FTBFS¶
Si un paquet se trouvant dans main a une dépendance manquante qui n’est pas dans main, vous devrez déposer un rapport de bogue MIR. https://wiki.ubuntu.com/MainInclusionProcess explique la procédure.
Résoudre le problème¶
Une fois que vous avez trouvé comment corriger le problème, suivez la même démarche que pour tout autre bogue. Créez un correctif, ajoutez-le à une branche bzr ou à un bogue, abonnez-y ubuntu-sponsors, puis essayez de le faire inclure en amont et/ou dans Debian.
Rétroportage de mises à jour logicielles¶
Parfois, vous souhaitez ajouter une nouvelle fonctionnalité qui ne concerne pas la correction de bug critique. Pour ce scénario, vous avez deux options : soit vous le soumettez à un PPA soit vous préparez un rétroportage.
Personal Package Archive (PPA)¶
L’utilisation d’un PPA a un certain nombre d’avantages. C’est assez simple, vous n’avez besoin d’aucune approbation, mais l’inconvénient, c’est que vos utilisateurs devront l’activer manuellement. C’est une source de logiciels non standard.
La documentation sur les PPA sur Launchpad est assez complète et devrait vous permettre d’être opérationnel en un rien de temps.
Rétroportages officiels d’Ubuntu¶
Le projet Backports est un moyen d’offrir de nouvelles fonctionnalités aux utilisateurs. En raison des risques inhérents à la stabilité du rétroportage des paquets, les utilisateurs n’obtiennent pas les paquets rétroportés sans action explicite de leur part. Cela rend généralement le rétroportage inapproprié pour corriger les bogues. Si un paquet dans une mise à jour de Ubuntu comporte un bogue, il doit être réparé par la Mise à jour de Sécurité ou le Processus de Mise à jour en Version Stable, selon le cas.
Une fois que vous avez déterminé un paquet à rétroporter vers une version stable, vous aurez besoin de le tester y compris en construction sur la version stable donnée. pbuilder-dist (dans le paquet ubuntu-dev-tools) est un outil très pratique pour y arriver facilement.
Pour signaler la demande de rétroportage et la faire traiter par l’équipe Backporters, vous pouvez utiliser l’outil requestbackport (également dans le paquet ubuntu-dev-tools). Il déterminera les versions intermédiaires dans lesquelles le paquet doit être rétroporté, énumérera toutes les dépendances inverses, et déposera la demande de rétroportage. Il inclura également une liste de vérification des tests dans le bogue.
Base de connaissances¶
Communication dans Ubuntu développement¶
Dans un projet où des milliers de lignes de code sont modifiées, de nombreuses décisions sont prises et des centaines de personnes interagissent chaque jour, il est important de communiquer efficacement.
Listes de diffusion¶
Les listes de diffusion sont un outil très important si vous voulez communiquer des idées à une plus large équipe et vous assurer d’atteindre tout le monde, quels que soient les fuseaux horaires.
En termes de développement, ce sont les plus importants :
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce (annonces uniquement, les annonces de développement les plus importantes vont ici)
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel (discussion générale sur le développement Ubuntu)
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu (discussion de l’équipe MOTU, obtenir de l’aide avec l’empaquetage)
Canaux IRC¶
Pour discuter en temps réel, connectez-vous à irc.freenode.net et rejoignez un ou plusieurs de ces canaux :
#ubuntu-devel (pour une discussion générale sur le développement)
#ubuntu-motu (pour une discussion avec l’équipe MOTU et généralement obtenir de l’aide)
Aperçu élémentaire du dossier debian/¶
Cet article va vous expliquer brièvement les différents fichiers importants pour l’empaquetage des paquets Ubuntu, contenus dans le répertoire debian/. Les plus importants d’entre eux sont changelog, control, copyright et rules. Ceux-ci sont nécessaires pour tous les paquets. Certains fichiers supplémentaires dans debian/ peuvent être utilisés afin de personnaliser et de configurer le comportement du paquet. Certains de ces fichiers sont décrits dans cet article, mais il n’est pas censé constituer une liste exhaustive.
Le changelog¶
Ce fichier est, comme son nom l’indique, une liste des modifications apportées à chaque version. Il possède un format spécifique donnant le nom du paquet, la version, la distribution, les modifications, et qui les a apportées à un moment donné. Si vous avez une clé GPG (voir : Obtenir configuration), assurez-vous d’utiliser les mêmes nom et adresse email dans le changelog que dans votre clé. Ce qui suit est un modèle de changelog :
package (version) distribution; urgency=urgency
* change details
- more change details
* even more change details
-- maintainer name <email address>[two spaces] date
Le format (particulièrement celui de la date) est important. La date doit être au format RFC 5322, obtenu en utilisant la commande date -R. Pour plus de commodité, la commande dch est utilisée pour éditer le changelog. Elle mettra automatiquement la date à jour.
Les points mineurs sont indiquées par un tiret “-”, tandis que les points majeurs utilisent un astérisque “*”.
Si vous êtes parti de zéro pour l’empaquetage, dch --create (dch est dans le paquet devscripts) vous créera un debian /changelog standard.
Voici un exemple de fichier changelog pour bonjour:
hello (2.8-0ubuntu1) trusty; urgency=low
* New upstream release with lots of bug fixes and feature improvements.
-- Jane Doe <packager@example.com> Thu, 21 Oct 2013 11:12:00 -0400
Notez que la version comporte un -0ubuntu1 annexé, c’est la révision de la distribution, utilisée de telle sorte que l’empaquetage peut être mis à jour (pour par exemple corriger des bogues) avec de nouveaux ajouts dans la même version de la source.
Ubuntu et Debian ont des systèmes légèrement différents d’incrémentation de version de paquets pour éviter que des paquets issus d’une source de même version entrent en conflit. Lorsqu’un paquet Debian a été modifié dans Ubuntu, il présente un ubuntuX (où X est le numéro de révision Ubuntu) annexé à la fin de la version Debian. Donc, si le paquet Debian hello 2.6-1 a été modifié par Ubuntu, la chaîne de version indiquera 2.6-1ubuntu1. Si ce paquet pour l’application n’existe pas dans Debian, la révision Debian est 0 (par exemple, hello 2.6-0ubuntu1).
Pour plus d’informations, consultez la section changelog (Section 4.4) de la Charte Debian.
Le fichier de contrôle.¶
Le fichier control contient les informations que les gestionnaires de paquets (comme apt-get, synaptic ou adept) utilisent, les moments de construction des dépendances, les informations concernant les mainteneurs et plus encore.
Pour le paquet hello de Ubuntu, le fichier control ressemble à ceci :
Source: hello
Section: devel
Priority: optional
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
XSBC-Original-Maintainer: Jane Doe <packager@example.com>
Standards-Version: 3.9.5
Build-Depends: debhelper (>= 7)
Vcs-Bzr: lp:ubuntu/hello
Homepage: http://www.gnu.org/software/hello/
Package: hello
Architecture: any
Depends: ${shlibs:Depends}
Description: The classic greeting, and a good example
The GNU hello program produces a familiar, friendly greeting. It
allows non-programmers to use a classic computer science tool which
would otherwise be unavailable to them. Seriously, though: this is
an example of how to do a Debian package. It is the Debian version of
the GNU Project's `hello world' program (which is itself an example
for the GNU Project).
Le premier paragraphe décrit le paquet source, y compris la liste des paquets nécessaires pour construire le paquet depuis son source dans le champ Build-Depends. Il contient également des méta-informations comme le nom du mainteneur, la version de la Charte Debian à laquelle le paquet se conforme, l’emplacement du dépôt du contrôle de version de l’empaquetage et la page d’accueil en amont.
Notez que dans Ubuntu, nous avons laissé le champ Maintainer pointer vers une adresse générale, car n’importe qui peut changer n’importe quel paquet (ceci diffère de Debian où le changement des paquets est généralement limité à une personne ou une équipe). Les paquets dans Ubuntu devraient avoir le champ Maintainer indiquant Développeurs Ubuntu <ubuntu-devel-discuss@lists.ubuntu.com>. Si ce champ Maintainer est modifié, l’ancienne valeur doit être enregistrée dans le champ XSBC-Original-Maintainer. Cela peut être fait automatiquement avec le script update-maintainer disponible dans le paquet ubuntu-dev-tools. Pour plus d’informations, reportez-vous aux Spécifications Debian du Champ Mainteneur sur le wiki d’Ubuntu.
Chaque paragraphe supplémentaire décrit un paquet binaire à compiler.
Pour plus d’informations, consultez la section fichier control (Chapitre 5) de la Charte Debian.
Le fichier de copyright¶
Ce fichier donne les informations de copyright à la fois pour la source en amont et pour l’empaquetage. Les chartes Ubuntu et Debian (Section 12.5) exigent que chaque paquet installe une copie intégrale de son copyright et de ses informations de licence dans /usr/share/doc/$(package_name)/copyright.
En règle générale, les informations de copyright se trouvent dans le fichier COPYING du répertoire source du programme. Ce fichier doit contenir des informations telles que les noms des auteurs et de l’empaqueteur, l’URL de provenance de la source, une ligne Copyright indiquant l’année et le titulaire du copyright, et le texte du copyright lui-même. Un exemple pouvant servir de modèle serait :
Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: Hello
Source: ftp://ftp.example.com/pub/games
Files: *
Copyright: Copyright 1998 John Doe <jdoe@example.com>
License: GPL-2+
Files: debian/*
Copyright: Copyright 1998 Jane Doe <packager@example.com>
License: GPL-2+
License: GPL-2+
This program is free software; you can redistribute it
and/or modify it under the terms of the GNU General Public
License as published by the Free Software Foundation; either
version 2 of the License, or (at your option) any later
version.
.
This program is distributed in the hope that it will be
useful, but WITHOUT ANY WARRANTY; without even the implied
warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE. See the GNU General Public License for more
details.
.
You should have received a copy of the GNU General Public
License along with this package; if not, write to the Free
Software Foundation, Inc., 51 Franklin St, Fifth Floor,
Boston, MA 02110-1301 USA
.
On Debian systems, the full text of the GNU General Public
License version 2 can be found in the file
`/usr/share/common-licenses/GPL-2'.
Cet exemple suit le format du Droit d’auteur Debian lisible par la machine. Vous êtes également encouragés à utiliser ce format.
Le fichier des règles¶
Le dernier fichier que nous devons examiner est rules. Il complète tout le travail de création de notre paquet. Il s’agit d’un Makefile ayant pour objectifs de compiler et d’installer l’application, puis de créer le fichier .deb à partir des fichiers installés. Il a également pour objectif de nettoyer tous les fichiers de construction de telle sorte que vous vous retrouvez au final uniquement avec un paquet source.
Voici une version simplifiée du fichier de règles créé par dh_make (qui peut être trouvé dans le paquet dh-make):
#!/usr/bin/make -f
# -*- makefile -*-
# Uncomment this to turn on verbose mode.
#export DH_VERBOSE=1
%:
dh $@
Passons ce fichier en revue de détails. Tout ce qu’il fait est de passer chaque cible construite qu’appelle ce debian/rules comme argument à /usr/bin/dh, qui appelle lui-même toutes les commandes dh_* nécessaires.
dh exécute une séquence de commandes de debhelper. Les séquences prises en charge correspondent aux objectifs du fichier « debian/rules » : « build », « clean », « install », « binary-arch », « binary-indep » et « binary ». Afin de voir quelles commandes sont lancées dans chaque cible, exécutez :
$ dh binary-arch --no-act
Les commandes de la séquence binary-indep sont passées avec l’option « -i » pour s’assurer qu’elles ne fonctionnent que sur des paquets binaires indépendants, et les commandes de la séquence binary-arch sont passées avec l’option « -a » pour s’assurer qu’elles ne fonctionnent que sur les paquets dépendants de l’architecture.
Chaque commande debhelper s’enregistrera après une exécution réussie dans debian/package.debhelper.log. (Que dh_clean efface.) Ainsi, dh peut révéler quelles commandes ont déjà été exécutées, pour quels paquets, et ignorera une nouvelle instance d’exécution de ces commandes.
A chaque exécution de dh, il examine le journal, et retrouve les dernières commandes historisées dans une séquence spécifiée. Il continue ensuite avec la commande suivante de la séquence. Les options --until, --before, --after, et --remaining modifient ce comportement.
Si debian/rules contient une cible nommée override_dh_command, alors quand il arrive à cette commande de la séquence, dh traitera cette cible à partir du fichier de règles, plutôt que de lancer la commande réelle. La cible modifiée peut ensuite exécuter la commande avec des options supplémentaires, ou exécuter des commandes complètement différentes à la place. (Notez que pour utiliser cette fonctionnalité, vous devez construire les dépendances à partir de debhelper 7.0.50 ou supérieur.)
Jetez un œil à usr/share/doc/debhelper/examples/ et man dh pour plus d’exemples. Voir également la section rules (Section 4.9) de la Charte Debian.
Les fichiers additionnels¶
Le fichier d’installation¶
Le fichier install est utilisé par dh_install pour installer les fichiers dans le paquet binaire. Il s’utilise classiquement dans deux cas :
Pour installer des fichiers dans votre paquet lorsqu’ils ne sont pas gérés par le système de construction en amont.
Fractionner un important et unique paquet source en plusieurs paquets binaires.
Dans le premier cas, le fichier install doit comporter une ligne par fichier installé, en précisant à la fois le fichier et le répertoire d’installation. Par exemple, le fichier install suivant installera le script foo dans le répertoire racine du paquet source de usr/bin et un fichier desktop dans le répertoire debian de usr/share/applications :
foo usr/bin
debian/bar.desktop usr/share/applications
Lorsqu’un paquet source produit plusieurs paquets binaires dh va installer les fichiers dans debian/tmp plutôt que directement dans debian/<paquet>. Les fichiers installés dans debian/tmp peuvent alors être déplacés en paquets binaires séparés en utilisant plusieurs fichiers $package_name.install. Cela est couramment utilisé pour sortir de grandes quantités de données indépendantes de l’architecture hors de paquets dépendants de l’architecture ainsi qu’à l’intérieur de paquets Architecture : all. Dans ce cas, seul le nom des fichiers (ou des répertoires) à installer sont nécessaires, en omettant le répertoire d’installation. Par exemple, foo.install contenant uniquement des fichiers dépendants de l’architecture pourrait ressembler à :
usr/bin/
usr/lib/foo/*.so
Alors que le foo-common.install contenant uniquement des fichiers indépendants de l’architecture pourrait ressembler à :
/usr/share/doc/
/usr/share/icons/
/usr/share/foo/
/usr/share/locale/
Cela créera deux paquets binaires, `` foo`` et foo-common. Les deux exigeraient leur propre paragraphe dans debian/control.
Voir man dh_install et la section du fichier install (Section 5.11) du Nouveau Guide des Mainteneurs Debian pour plus de détails.
Le fichier watch¶
Le fichier debian/watch nous permet de vérifier automatiquement les nouvelles versions amont en utilisant l’outil uscan se trouvant dans le paquet devscripts. La première ligne du fichier doit être la version du format (3, au moment d’écrire ces lignes), tandis que les lignes suivantes contiennent des URL à analyser. Par exemple:
version=3
http://ftp.gnu.org/gnu/hello/hello-(.*).tar.gz
L’exécution de uscan dans le répertoire racine source ira comparer le numéro de version amont dans debian/changelog avec celui de la dernière version amont disponible. Si une nouvelle version amont est trouvée, elle sera automatiquement téléchargée. Par exemple :
$ uscan
hello: Newer version (2.7) available on remote site:
http://ftp.gnu.org/gnu/hello/hello-2.7.tar.gz
(local version is 2.6)
hello: Successfully downloaded updated package hello-2.7.tar.gz
and symlinked hello_2.7.orig.tar.gz to it
Si vos archives tar sont en direct sur Launchpad, le fichier debian/watch sera un peu plus compliqué (la Question 21146 et le Bogue 231797 montrent de quoi il s’agit). Dans ce cas, utilisez quelque chose comme :
version=3
https://launchpad.net/flufl.enum/+download http://launchpad.net/flufl.enum/.*/flufl.enum-(.+).tar.gz
Pour plus d’informations, consultez man uscan et la section fichier watch (Section 4.11) de la Charte Debian.
Pour une liste de paquets où les fichiers de rapport watch ne sont pas synchronisés avec l’amont, voir Etat de santé externe Ubuntu.
Le fichier source/format¶
Ce fichier indique le format du paquet source. Il doit contenir une seule ligne indiquant le format désiré :
3.0 (native) pour les paquets Debian natifs (pas de version amont)
3.0 (quilt) pour les paquets avec une archive séparée en amont
1.0 pour les paquets souhaitant déclarer explicitement le format par défaut
Actuellement, le format de paquet source sera 1.0 par défaut si ce fichier n’existe pas. Vous pouvez rendre cela explicite dans le fichier source/format. Si vous choisissez de ne pas utiliser ce fichier pour définir le format de la source, Lintian vous avertira de ce fichier manquant. Cet avertissement est purement informatif et peut être ignoré en toute sécurité.
Nous vous encourageons à utiliser le nouveau format de source 3.0. Il fournit un certain nombre de nouvelles fonctionnalités :
Prise en charge de formats de compression supplémentaires : bzip2, lzma et xz
Prise en charge de plusieurs archives amont
Il n’est pas nécessaire de rempaqueter l’archive amont pour dépouiller le répertoire debian
Les changements spécifiques à Debian ne sont plus stockés dans un seul fichier .diff.gz, mais dans plusieurs correctifs compatibles avec quilt dans debian/patches/
http://wiki.debian.org/Projects/DebSrc3.0 résume l’information supplémentaire concernant le passage à la version 3.0 des formats de paquets source.
Voir man dpkg-source et la section source/format (Section 5.21) du Nouveau Guide des Mainteneurs Debian afin d’obtenir des détails supplémentaires.
Ressources supplémentaires¶
En complément des liens vers la Charte Debian de chaque section ci-dessus, le Nouveau Guide des Mainteneurs Debian décrit plus en détail chaque fichier. Notamment, Chapitre 4, « Fichiers nécessaires dans le répertoire debian » examine en profondeur les fichiers control, changelog, copyright et rules. Le Chapitre 5, « Autres fichiers dans le répertoire debian » examine les fichiers supplémentaires pouvant être utilisés.
autopkgtest : tests automatiques pour les paquets¶
La spécification DEP 8 définit la façon dont les tests automatiques peuvent être très facilement intégrés dans les paquets. Pour intégrer un test dans un paquet, tout ce que vous devez faire est de :
ajoutez ce qui suit à la section Source dans debian/control:
XS-Testsuite: autopkgtest
ajoutez un fichier appelé debian/tests/control qui spécifie les exigences pour le banc d’essai,
ajoutez les tests dans debian/tests/.
Exigences du banc d’essai¶
Dans debian/tests/control vous spécifiez ce que vous attendez du banc d’essai. Ainsi, par exemple, vous listez tous les paquets nécessaires pour les tests, si le banc d’essai se casse lors de la construction ou si les autorisations root sont nécessaires. La spécification DEP 8 répertorie toutes les options disponibles.
Ci-dessous, nous voyons un aperçu du paquet source glib2.0. Dans un cas très simple, le fichier devrait ressembler à ceci:
Tests: build
Depends: libglib2.0-dev, build-essential
Pour le test dans debian/tests/build, cela permettrait de s’assurer que les paquets libglib2.0-dev et build-essential sont installés.
Note
Vous pouvez utiliser @ de la ligne Depends pour indiquer que vous souhaitez tous les paquets installés construits par la paquet source en question.
Les tests réels¶
Le test accompagnant l’exemple ci-dessus pourrait être :
#!/bin/sh
# autopkgtest check: Build and run a program against glib, to verify that the
# headers and pkg-config file are installed correctly
# (C) 2012 Canonical Ltd.
# Author: Martin Pitt <martin.pitt@ubuntu.com>
set -e
WORKDIR=$(mktemp -d)
trap "rm -rf $WORKDIR" 0 INT QUIT ABRT PIPE TERM
cd $WORKDIR
cat <<EOF > glibtest.c
#include <glib.h>
int main()
{
g_assert_cmpint (g_strcmp0 (NULL, "hello"), ==, -1);
g_assert_cmpstr (g_find_program_in_path ("bash"), ==, "/bin/bash");
return 0;
}
EOF
gcc -o glibtest glibtest.c `pkg-config --cflags --libs glib-2.0`
echo "build: OK"
[ -x glibtest ]
./glibtest
echo "run: OK"
Ici, un morceau très simple de code C est écrit dans un répertoire temporaire. C’est ensuite compilé avec les bibliothèques système (en utilisant les drapeaux et chemins des bibliothèques fournis par pkg-config). Ensuite, le binaire compilé, qui fait juste appel à quelques fonctionnalités glib de parties du noyau, est exécuté.
Bien que ce test soit très petit et basique, il teste un grand nombre de composantes du noyau d’un système. Cela peut aider à découvrir plus tôt des problèmes critiques.
Exécution du test¶
Le script de test peut être facilement exécuté tout seul, mais si vous voulez être sûr que le banc d’essai est correctement configuré, il est préférable d’utiliser adt-run depuis le paquet autopkgtest pour exécuter le test. La plus simple façon de le faire est de lancer cette commande dans l’arbre source:
sudo adt-run --no-built-binaries --built-tree=. --- adt-virt-null
L’inconvénient de cette approche est que vous le testez en local, mais vous ne pouvez pas être sûr que cela fonctionnera dans un environnement minimal. Il sera par exemple difficile de s’assurer que tous les paquets requis sont installés pour les tests. Avec lp:auto-package-testing nous avons un outil de test bien plus complet. Il utilise une machine virtuelle toute fraîche pour exécuter les tests. Pour le paramétrer, commencez par installer les dépendances nécessaires:
sudo apt-get install qemu-utils kvm eatmydata
Ensuite, récupérez le code source sur Launchpad:
bzr branch lp:auto-package-testing
cd auto-package-testing
And provision a Trusty AMD64 system:
./bin/prepare-testbed -r trusty amd64
This command will create a pristine Trusty AMD64 VM from a cloud image. To run the tests, simply run:
./bin/run-adt-test -r trusty -a amd64 \
-S file:///tmp/glib2.0-2.35.7/ glib2.0
Cela utilisera le paquet source dans /tmp/glib2.0-2.35.7/ et lancera les tests de cet arbre sur le paquet glib2.0 de l’archive. L’ option -S gère aussi les schémas pour les sources bzr, git et apt. Si vous spécifiez seulement une source avec -S sans spécifier le nom du paquet, à la place, cela construira la branche et installera les binaires construits ; C’est plus pratique si vous voulez lancer les tests sur une version plus récente que celle empaquetée dans Ubuntu, ou si le paquet n’est pas du tout dans Ubuntu. Si vous utilisez le drapeau -k vous pouvez vous connecter dans une machine virtuelle après l’exécution des tests. Cela rend le débogage des problèmes très facile.
La documentation auto-package-testing a beaucoup plus d’informations utiles sur les autres options de tests.
Exemples complémentaires¶
Cette liste n’est pas exhaustive mais elle peut vous aider à mieux comprendre comment les tests automatiques sont implémentés et utilisés dans Ubuntu.
Les tests libxml2 sont très similaires. Ils effectuent aussi un test de compilation d’un simple morceau de code C et l’exécutent.
Les tests gtk +3.0 font également une compilation/link/run vérifier dans le dossier “build” test. Il y a un test supplémentaire “python3-gi” qui vérifie que la bibliothèque GTK peut également être utilisé par l’introspection.
Dans les tests ubiquity la suite de test en amont est exécutée.
Les tests gvfs ont un test complet de leur fonctionnalité et sont très intéressants car ils émulent l’utilisation de CD, Samba, DAV et autres bricoles.
infrastructure Ubuntu¶
Les paquets autorisés en autopkgtest seront testés à chaque téléchargement ou modification de leurs dépendances. Les produits des tests autopkgtest à exécution automatique peuvent être consultés sur internet et sont régulièrement mis à jour.
Bien que Debian n’a pas encore mis en place une infrastructure de test automatique, ils doivent encore être soumis à Debian, car DEP-8 est une spécification Debian et les développeurs ou les utilisateurs Debian peuvent toujours exécuter manuellement les tests.
Les paquets dans Debian avec un en-tête testsuite seront également ajoutés automatiquement quand ils sont synchronisés avec Ubuntu.
Faire passer le test dans Ubuntu¶
Le processus de soumission d’un autopkgtest pour un paquet est très similaire à corriger un bogue dans Ubuntu. Essentiellement, il vous suffit de :
exécuter bzr branch ubuntu:<nomdupaquet>,
modifier debian/control pour activer les tests,
ajouter le répertoire debian/tests,
écrire le debian/tests/control basé sur la spécification DEP 8,
ajouter votre cas de test(s) à debian/tests,
valider vos modifications, les téléverser vers Launchpad, proposer une fusion et obtenir son examen, exactement comme pour toute autre amélioration dans un paquet source.
Ce que vous pouvez faire¶
L’équipe d’ingénierie Ubuntu a dressé une liste des cas nécessaires de test, où les paquets nécessitant d’être testés sont placés dans différentes catégories. Ici vous pouvez trouver des exemples de ces tests et vous les attribuer aisément.
Si vous rencontrez des problèmes, vous pouvez rejoindre le canal IRC #ubuntu-quality pour entrer en contact avec les développeurs qui peuvent vous aider.
Obtenir la source¶
Les URLs des paquets source¶
Bazaar fournit quelques astucieux raccourcis pour accéder aux branches source Launchpad des paquets Ubuntu ou Debian.
Pour se référer aux branches source, utilisez :
ubuntu:package
où paquet désigne le nom du paquet qui vous intéresse. Cette URL se réfère au paquet dans l’actuelle version de développement d’Ubuntu. Pour faire référence à la branche de Tomboy dans la version de développement, vous devez utiliser :
ubuntu:tomboy
To refer to the version of a source package in an older release of Ubuntu, just prefix the package name with the release’s code name. E.g. to refer to Tomboy’s source package in Saucy use:
ubuntu:saucy/tomboy
Puisqu’il est unique, vous pouvez aussi abréger le nom de série de la distribution :
ubuntu:s/tomboy
Vous pouvez utiliser un schéma similaire pour accéder aux branches source dans Debian, bien qu’il n’y ait pas de raccourci pour les noms de série de distribution. Pour accéder à la branche Tomboy dans les actuelles séries en développement pour Debian, utilisez :
debianlp:tomboy
et pour accéder à Tomboy dans Debian Wheezy utilisez :
debianlp:wheezy/tomboy
Obtenir les sources¶
Chaque paquet source dans Ubuntu a une branche source associée sur Launchpad. Ces branches source sont mises à jour automatiquement par Launchpad, même si le processus n’est actuellement pas infaillible.
Il existe plusieurs choses à faire en premier pour rendre la force de travail plus efficace ultérieurement. Une fois que vous serez habitué à ce processus, vous apprendrez à quel moment il est possible de se passer de ces étapes.
Obtenir la branche commune¶
Nous utilisons la commande bzr branch pour créer une branche locale du paquet. Nous allons nommer le répertoire cible tomboy.dev juste pour faciliter sa mémorisation :
$ bzr branch ubuntu:tomboy tomboy.dev
Le répertoire tomboy.dev représente la version de Tomboy dans la version de développement d’Ubuntu, et vous pouvez toujours vous placer avec cd dans ce répertoire et lancer un bzr pull pour obtenir les éventuelles mises à jour ultérieures.
S’assurer que la version est à jour¶
Lorsque vous lancez votre bzr branch, vous recevez un message vous indiquant si la branche du paquet est à jour. Par exemple :
$ bzr branch ubuntu:tomboy
Most recent Ubuntu version: 1.8.0-1ubuntu1.2
Packaging branch status: CURRENT
Branched 86 revisions.
Parfois, l’importation échoue et les branches de paquets ne correspondent pas à ce qui est dans l’archive. Un message disant :
Packaging branch status: OUT-OF-DATE
signifie que l’importation a échoué. Vous pouvez trouver pourquoi sur http://package-import.ubuntu.com/status/ et déposer un bogue sur le projet UDD pour faire résoudre ce problème.
Archive de l’amont¶
Vous pouvez obtenir l’archive de l’amont en exécutant :
bzr get-orig-source
Ceci essayera un certain nombre de méthodes pour obtenir l’archive de l’amont, d’une part en la recréant à partir de la balise upstream-x.y de l’archive bzr, puis en la téléchargeant à partir de l’archive Ubuntu, enfin en exécutant debian/rules get-orig-source. L’archive de l’amont sera alors recréée en utilisant bzr pour construire le paquet :
bzr builddeb
Le greffon builddeb a plusieurs options de configuration.
Obtenir une branche pour une version particulière¶
Lorsque vous voulez réaliser quelque chose comme une mise à jour de version stable (SRU), ou simplement si vous voulez examiner le code d’une version plus ancienne, vous devrez récupérer la branche correspondant à une version particulière d’Ubuntu. Par exemple, pour obtenir le paquet Tomboy pour Quantal, faites :
$ bzr branch ubuntu:m/tomboy quantal
Importation d’un paquet source Debian¶
Si le paquet sur lequel vous souhaitez travailler est disponible dans Debian et pas dans Ubuntu, il est toujours simple d’en importer le code vers une branche bzr locale de développement. Disons que vous souhaitez importer le paquet source newpackage. Nous commençons par créer un dépôt partagé comme d’habitude, mais nous devons également créer une arborescence de travail vers laquelle sera importée le paquet source (rappelez-vous de sortir du répertoire tomboy créé ci-dessus) :
$ bzr init-repo newpackage
$ cd newpackage
$ bzr init debian
$ cd debian
$ bzr import-dsc http://ftp.de.debian.org/debian/pool/main/n/newpackage/newpackage_1.0-1.dsc
Comme vous pouvez le voir, nous devons juste indiquer l’emplacement distant du fichier dsc, et Bazaar fera le reste. Vous avez désormais une branche source Bazaar.
Travail sur un paquet¶
Une fois que vous avez la branche du paquet source dans un dépôt partagé, vous devrez créer des branches supplémentaires pour les correctifs ou les autres travaux que vous comptez faire. Vous pouvez baser votre branche hors de la branche du paquet source de la version de distribution vers laquelle vous envisagez de télécharger. Habituellement, c’est vers la version en cours de développement, mais cela peut être vers d’anciennes versions si vous effectuez un rétroportage SRU par exemple.
Ramifier pour une modification¶
La première chose à faire est de vous assurer que votre branche du paquet source est à jour. Elle le sera si vous venez juste de l’extraire, sinon faites :
$ cd tomboy.dev
$ bzr pull
Toute mise à jour apportée et téléchargée vers le paquet depuis votre extraction sera désormais rapatriée. N’apportez pas de modification à cette branche. Au lieu de cela, créez une branche qui contiendra uniquement les modifications que vous allez apporter. Disons que vous voulez corriger le bogue 12345 du projet Tomboy. Lorsque vous êtes dans le dépôt partagé précédemment créé pour Tomboy, vous pouvez créer votre correctif de bogue ainsi :
$ bzr branch tomboy.dev bug-12345
$ cd bug-12345
Maintenant, vous pouvez effectuer mon travail dans le répertoire bug-12345. Vous apportez les modifications nécessaires, en soumettant au fur et à mesure. C’est exactement comme n’importe quel développement de logiciel avec Bazaar. Vous pouvez soumettre aussi souvent que vous le souhaitez, et lorsque vos modifications sont terminées, vous utiliserez la commande dch (du paquet devscripts) :
$ dch -i
Cela vous ouvre un éditeur pour ajouter une entrée au fichier debian/changelog.
Lorsque vous avez ajouté votre entrée au debian/changelog, vous avez dû inclure une balise de correction de bogue qui indiquera quel numéro de bogue Launchpad vous corrigez. Le format de cette balise textuelle est assez strict : LP: #12345. L’espace entre le : et le # est indispensable et vous devez évidemment utiliser le numéro réel du bogue que vous êtes en train de corriger. Votre entrée de debian/changelog doit ressembler à :
tomboy (1.12.0-1ubuntu3) trusty; urgency=low
* Don't fubar the frobnicator. (LP: #12345)
-- Bob Dobbs <subgenius@example.com> Mon, 10 Sep 2013 16:10:01 -0500
Soumettez avec l’habituel :
bzr commit
Une accroche dans bzr-builddeb utilisera le texte du debian/changelog comme message pour la commande commit et marquera « corrigé » sur l’étiquette du bogue #12345.
Cela ne fonctionne qu’avec bzr-builddeb 2.7.5 et bzr 2.4, pour les versions plus anciennes, utilisez debcommit.
Construisez le paquet¶
Tout au long du développement, vous devrez compiler votre branche de manière à la tester pour être sûr qu’elle corrige réellement le bogue.
De manière à construire le paquet, vous pouvez utiliser la commande bzr builddeb du paquet bzr-builddeb. Vous pouvez construire un paquet source avec :
$ bzr builddeb -S
(bd est un alias pour builddeb.) Vous pouvez laisser le paquet non signé en ajoutant les paramètres -- -uc -us à la commande.
Il est également possible d’utiliser vos outils habituels, aussi longtemps qu’ils sont capables d’extraire les répertoires .bzr depuis le paquet, par exemple :
$ debuild -i -I
S’il vous arrive d’apercevoir une erreur relative à la tentative de construction d’un paquet natif sans archive, vérifiez si un fichier .bzr-builddeb/default.conf ne spécifie pas le paquet comme natif par erreur. Si la version du changelog comporte un tiret, alors ce n’est pas un paquet natif, donc supprimez le fichier de configuration. Notez que bien que bzr builddeb comporte une option --native, il n’a pas d’option --no-native.
Une fois que vous avez obtenu le paquet source, vous pouvez le construire comme d’habitude avec pbuilder-dist (ou pbuilder ou sbuild).
A la recherche de Relectures et de Parrainages¶
Un des plus gros avantages de l’utilisation du flux de travail UDD est d’améliorer la qualité en recherchant la relecture des modifications par des pairs. Cela est vrai que vous ayez ou non les droits de téléchargement. Bien entendu, si vous n’avez aucun droit de téléchargement, vous devrez trouver des parrainages.
Une fois satisfait de votre correctif, et que vous avez une branche prête, les étapes suivantes peuvent être utilisées pour publier votre branche sur Launchpad, la relier à une solution de bogue, et créer une proposition de fusion pour que les autres puissent la relire, et que les parrains la téléchargent.
Publier vers Launchpad¶
Nous vous avons déjà montré comment associer votre branche au bogue en utilisant dch et bzr commit. Toutefois, la branche et le bogue ne sont réellement liés qu’après publication de la branche vers Launchpad.
Il n’est pas essentiel d’avoir un lien vers un bogue pour chaque modification que vous apportez, mais si vous corrigez des bogues déjà rapportés, les relier sera utile.
La forme générale de l’URL pour publier votre branche est :
lp:~<user-id>/ubuntu/<distroseries>/<package>/<branch-name>
For example, to push your fix for bug 12345 in the Tomboy package for Trusty, you’d use:
$ bzr push lp:~subgenius/ubuntu/trusty/tomboy/bug-12345
Le dernier élément du chemin est arbitraire ; c’est à vous de choisir quelque chose de significatif.
Toutefois, ce n’est généralement pas suffisant pour obtenir la relecture et le parrainage de vos modifications pas les développeurs d’Ubuntu. Vous devez ensuite soumettre une * proposition de fusion*.
Pour ce faire, ouvrez la page de bogue dans un navigateur, par exemple :
$ bzr lp-open
En cas d’échec, vous pouvez utiliser :
$ xdg-open https://code.launchpad.net/~subgenius/ubuntu/trusty/tomboy/bug-12345
où la plus grande partie de l’URL correspond à ce que vous avez utilisé pour bzr push. Sur cette page, vous verrez un lien Proposer la fusion vers une autre branche. Tapez une explication de votre modification dans la boîte de dialogue Commentaire initial. Enfin, cliquez sur Proposer la fusion pour terminer le processus.
Les propositions de fusion pour les branches source de paquets vont automatiquement solliciter l’équipe des ~ubuntu-branches, ce qui sera suffisant pour joindre un développeur Ubuntu pour relire et parrainer votre modification de paquet.
Génération d’un debdiff¶
Comme indiqué précédemment, certains parrains préfèrent toujours relire un debdiff attaché à un rapport de bogue plutôt qu’une proposition de fusion. S’il vous est demandé d’inclure un debdiff, vous pouvez en générer un comme ceci (depuis l’intérieur de votre branche bug-12345 :
$ bzr diff -rbranch:../tomboy.dev
Une autre méthode consiste à ouvrir la proposition de fusion et télécharger le diff.
Vous devriez vous assurer que le diff présente les modifications que vous attendez, ni plus ni moins. Nommez le diff de façon appropriée, par exemple foobar-12345.debdiff et joignez-le au rapport de bogue.
Gestion des retours des parrains¶
Si un parrain relit votre branche et vous demande d’y modifier quelque chose, vous pouvez le faire assez facilement. Allez simplement dans la branche sur laquelle vous travailliez au préalable, procédez aux modifications demandées, et soumettez de nouveau :
$ bzr commit
Maintenant que vous avez publié votre branche dans Launchpad, Bazaar se souvient de l’emplacement de votre publication, et mettra à jour la branche sur Launchpad avec vos dernières réalisations. Tout ce que vous avez à faire est :
$ bzr push
Vous pouvez alors répondre au courriel de relecture de la proposition de fusion en expliquant ce que vous avez changé, et en demandant une nouvelle relecture, ou vous pouvez répondre sur la page de proposition de fusion sur Launchpad.
Notez que si vous êtes parrainé via un debdiff joint à un rapport de bogue, vous devez manuellement mettre à jour en générant un nouveau diff et en le joignant au rapport de bogue.
Attentes¶
Les développeurs d’Ubuntu ont mis en place un calendrier des « pilotes de correctif », qui examinent régulièrement la file d’attente de parrainage et fournissent des retours d’information sur les branches et les correctifs. Même si cette mesure a été mise en place, il peut s’écouler plusieurs jours jusqu’à ce que vous constatiez un retour. Cela dépend de la charge de travail de chacun, si la version de développement est actuellement gelée, ou d’autres facteurs.
Si vous n’avez pas eu de nouvelles depuis un moment, n’hésitez pas à rejoindre le canal #ubuntu-devel sur irc.freenode.net pour découvrir si quelqu’un peut vous y aider.
Pour plus d’informations sur le processus de parrainage général, consultez également la documentation sur notre wiki : https://wiki.ubuntu.com/SponsorshipProcess
Envoi d’un paquet¶
Une fois votre proposition de fusion relue et approuvée, vous devez envoyer le paquet, que ce soit à l’archive (si vous avez l’autorisation) ou à votre Archive Personnelle de Paquet (PPA). Vous devrez également faire un téléchargement si vous parrainez les modifications de quelqu’un d’autre.
Envoi d’une de vos modifications¶
Lorsque vous avez une branche avec un changement que vous souhaitez envoyer, vous devez de nouveau obtenir ce changement sur la branche principale source, construire un paquet source, puis le télécharger.
En premier lieu, vérifiez si vous avez la dernière version du paquet dans votre extraction du tronc de paquet en développement :
$ cd tomboy/tomboy.dev
$ bzr pull
Cela récupère tout changement pouvant avoir été soumis pendant que vous mettiez votre correctif au point. A partir de ce point, vous disposez de plusieurs options. Si les modifications sur le tronc sont importantes et que vous pensez qu’elles devraient être testées en même temps que vos modifications, vous pouvez les fusionner dans votre branche de correction de bogue et tester là-bas. Dans le cas contraire, vous pouvez continuer à fusionner votre branche de correction de bogue dans la branche du tronc en développement. Avec bzr 2.5 et bzr-builddeb 2.8.1, cela fonctionne juste avec la commande merge :
$ bzr merge ../bug-12345
Pour les versions plus anciennes de bzr, vous pouvez utiliser la commande merge-package à la place :
$ bzr merge-package ../bug-12345
Cela fusionnera les deux arbres, éventuellement en produisant des conflits, que vous devrez résoudre manuellement.
Ensuite, vous devriez vous assurer que le debian/changelog est comme vous le souhaitez, avec une distribution conforme, un numéro de version correct, etc.
Une fois que c’est fait, vous devriez examiner la modification que vous êtes sur le point d’engager avec bzr diff. Cela devrait vous montrer les mêmes changements qu’un debdiff ferait avant de télécharger le paquet source.
L’étape suivante consiste à construire et tester le paquet source modifié comme vous le feriez normalement :
$ bzr builddeb -S
Lorsque vous êtes finalement satisfait avec votre branche, assurez-vous d’avoir engagé toutes vos modifications, puis marquez la branche avec le numéro de version du changelog. La commande bzr tag le fera pour vous automatiquement lorsqu’elle n’a aucun argument fourni :
$ bzr tag
Cette balise indique à l’importateur du paquet que le contenu de la branche Bazaar est le même que celui de l’archive.
Maintenant, vous pouvez publier de nouveau vos modifications dans Launchpad :
$ bzr push ubuntu:tomboy
(Modifiez la destination si vous télécharger une SRU ou similaire.)
Vous avez encore une dernière étape pour obtenir le téléchargement de vos modifications vers Ubuntu ou votre PPA; vous devez exécuter dput sur le paquet source vers l’emplacement approprié. Par exemple, si vous souhaitez télécharger vos modifications vers votre PPA, vous lancerez :
$ dput ppa:imasponsor/myppa tomboy_1.5.2-1ubuntu5_source.changes
ou, si vous avez la permission de téléverser vers l’archive principale:
$ dput tomboy_1.5.2-1ubuntu5_source.changes
Vous êtes maintenant libre de supprimer votre branche de fonction, puisqu’elle est fusionnée, et peut être re-téléchargée à partir de Launchpad si nécessaire.
Parrainage d’un changement¶
Parrainer les modifications de quelqu’un d’autre est exactement identique à la procédure décrite ci-dessus, mais au lieu de fusionner depuis une branche que vous créez, vous fusionnez depuis la branche créée dans la proposition de fusion :
$ bzr merge lp:~subgenius/ubuntu/trusty/tomboy/bug-12345
Si de trop nombreux conflits de fusion apparaissent, vous devrez probablement demander au contributeur de les corriger. Regardez le prochain paragraphe pour apprendre à annuler une fusion en attente.
Mais si les modifications paraissent correctes, engagez et suivez le reste du processus de téléversement :
$ bzr commit --author "Bob Dobbs <subgenius@example.com>"
Annulation d’un téléchargement¶
À tout moment avant d’exécuter dput sur le paquet source, vous pouvez décider d’annuler un téléchargement et de revenir sur les modifications :
$ bzr revert
Vous pouvez le faire si vous constatez que quelque chose semble nécessiter plus de travail, ou si vous souhaitez demander au contributeur de résoudre des conflits quand vous parrainez quelque chose.
Parrainer quelque chose et effectuer vos propres modifications¶
Si vous vous apprêtez à parrainer le travail de quelqu’un, mais que vous souhaitez y apporter quelques changements de votre propre initiative, alors vous pouvez au préalable fusionner son travail en une branche séparée.
Si vous possédez déjà une branche dans laquelle vous mettez au point un paquet, et que vous souhaitez inclure ses modifications, exécutez simplement la commande bzr merge depuis cette branche, au lieu d’extraire depuis le paquet en développement. Vous pouvez ensuite effectuer les modifications, puis engager et continuer avec vos modifications apportées au paquet.
Si vous ne possédez pas de branche existante, mais que vous aimeriez apporter des changements basés sur ce que le contributeur a fourni, alors vous devez commencer par récupérer sa branche :
$ bzr branch lp:~subgenius/ubuntu/trusty/tomboy/bug-12345
ensuite, travaillez dans cette branche, puis fusionnez-la à la branche principale et téléchargez-la comme si c’était votre propre travail. Le contributeur est toujours mentionné dans le changelog et Bazaar attribue correctement les modifications à celui qui les a réalisées.
Obtention des dernières nouveautés¶
Si quelqu’un a apporté de récentes modifications sur un paquet, vous devrez intégrer ces modifications dans vos propres copies de la branche du paquet.
Mise à jour de votre branche principale¶
Mettre à jour votre copie de branche correspondant au paquet dans une version particulière est très simple, utilisez bzr pull depuis le répertoire approprié :
$ cd tomboy/tomboy.dev
$ bzr pull
This works wherever you have a checkout of a branch, so it will work for things like branches of saucy, trusty-proposed, etc.
Obtention des dernières nouveautés dans vos branches de travail¶
Une fois que vous avez mis à jour votre copie d’une branche de distribution sérialisée, alors vous la fusionnerez dans vos branches de travail, de sorte qu’elles soient basées sur la dernière version du code.
Malgré tout, vous n’avez pas à faire cela à chaque fois. Vous pouvez travailler sur du code un peu plus ancien sans aucun problème. L’inconvénient viendrait si vous travaillez sur du code que quelqu’un d’autre a modifié entre temps. Si vous ne travaillez pas sur la dernière version alors vos modifications pourraient ne pas être correctes, et même potentiellement engendrer des conflits.
Cependant, la fusion doit être réalisée à un certain moment. Plus ce dernier est repoussé, plus difficile pourrait être la fusion. La réaliser régulièrement devrait conserver sa simplicité de réalisation. Même si cela génère de nombreuses fusions, l’effort global sera heureusement réduit.
Pour fusionner les modifications que vous avez juste besoin d’utiliser bzr merge, mais vous devez avoir consacré votre travail actuel premier:
$ cd tomboy/bug-12345
$ bzr merge ../tomboy.dev
Chaque conflit sera rapporté, et vous pourrez les corriger. Pour examiner les modifications que vous venez juste de fusionner utilisez bzr diff. Pour annuler l’utilisation de la fusion utilisez bzr revert. Une fois que vous êtes satisfait des modifications, utilisez bzr commit.
Se référer aux versions d’un paquet¶
Vous penserez souvent en termes de version de paquet, plutôt qu’en numéro sous-jacent de révision Bazaar. bzr-builddeb fournit un spécificateur de révision très pratique pour cela. Toute commande acceptant un argument -r pour spécifier une révision ou une plage de révisions fonctionnera avec ce spécificateur. Par exemple, bzr log, bzr diff, etc. Pour visualiser les versions d’un paquet, utilisez le spécificateur package: :
$ bzr diff -r package:0.1-1..package:0.1-2
Ceci vous montre les différences entre les versions 0.1-1 et 0.1-2 du paquet.
Fusion — Mise à jour à partir de Debian et de l’Amont¶
La fusion est l’un des points forts de Bazaar, et fréquemment utilisée dans le développement Ubuntu. Les mises à jour peuvent fusionner depuis Debian, depuis une nouvelle version de l’amont, ou depuis d’autres développeurs Ubuntu. Réaliser cela dans Bazaar est assez simple, et entièrement basé sur la commande bzr merge [1].
Lorsque vous êtes dans n’importe quel répertoire de travail d’une branche, vous pouvez fusionner une branche depuis un emplacement différent. Vérifiez tout d’abord que vous n’avez pas de modifications non validées :
$ bzr status
Si cela signale quelque chose, vous devrez soit soumettre les modifications, les inverser ou les classer pour y revenir ultérieurement.
Fusion depuis Debian¶
Exécutez ensuite bzr merge en donnant l’URL de la branche à partir de laquelle fusionner. Par exemple, pour fusionner depuis la version du paquet dans Debian Unstable, lancez [2] :
$ bzr merge lp:debian/tomboy
Cela fusionnera les modifications depuis le dernier point de fusion et vous laissera avec les modifications à revoir. Cela pourrait engendrer quelques conflits. Vous pouvez voir tout ce que la commande merge a réalisé en exécutant :
$ bzr status
$ bzr diff
Si des conflits sont signalés alors vous devrez éditer ces fichiers pour les faire paraître comme ils devraient, en supprimant les marqueurs de conflit. Une fois que vous l’avez fait, exécutez :
$ bzr resolve
$ bzr conflicts
Ceci permet de résoudre tout conflit de fichier que vous avez corrigé, et vous indique ensuite ce qu’il vous reste à traiter.
Une fois que tous les conflits sont résolus, et que vous avez effectué toutes les autres modifications nécessaires, ajoutez une nouvelle entrée au changelog, et soumettez :
$ dch -i
$ bzr commit
comme décrit précédemment.
Toutefois, avant de soumettre, il est toujours bon de vérifier toutes les modifications d’Ubuntu en exécutant :
$ bzr diff -r tag:0.6.10-5
qui montre les différences entre les versions Debian (0.6.10-5) et Ubuntu (0.6.10-5ubuntu1). D’une manière similaire, vous pouvez comparer chacune des autres versions. Pour voir toutes les versions disponibles, exécutez :
$ bzr tags
Après avoir testé et soumis votre fusion, vous devrez rechercher un parrainage ou télécharger vers l’archive de la manière habituelle.
Si vous êtes sur le point de construire le paquet source depuis cette branche fusionnée, vous devez utiliser l’option -S à la commande bd. Vous devez également prendre en considération l’utilisation de l’option --package-merge. Cela ajoutera le cas échéant les options -v et -sa au paquet source, de telle sorte que toutes les entrées du changelog depuis la dernière modification Ubuntu seront incluses dans votre fichier _source.changes. Par exemple :
$ bzr builddeb -S --package-merge
Fusion d’une nouvelle version de l’amont¶
Lorsque l’amont livre une nouvelle version (ou si vous souhaitez empaqueter un instantané), vous devez fusionner une archive dans votre branche.
Ceci est réalisé en utilisant la commande bzr merge-upstream. Si votre paquet possède un fichier debian/watch valide, depuis l’intérieur de la branche que vous souhaitez fusionner, tapez simplement :
$ bzr merge-upstream
Cela va télécharger l’archive et la fusionner à votre branche, vous ajoutant automatiquement une entrée debian/changelog pour vous. bzr-builddeb inspecte le fichier debian/watch pour localiser l’archive de l’amont.
Si vous n’avez pas de fichier debian/watch, vous devez spécifier manuellement la localisation de l’archive de l’amont, et sa version :
$ bzr merge-upstream --version 1.2 http://example.org/releases/foo-1.2.tar.gz
L’option --version est utilisée pour spécifier la version de l’amont qui est en cours de fusion, puisque la commande n’est pas (encore) capable de la déduire.
Le dernier paramètre est l’emplacement de l’archive que vous mettez à niveau ; cela peut être soit un chemin du système de fichiers local, soit une URI http, ftp, sftp, etc. comme indiqué. La commande va vous télécharger automatiquement l’archive. Elle sera renommée convenablement et, si nécessaire, convertie en .gz.
La commande merge-upstream va vous indiquer sa réussite ou si il y a eu des conflits. De toute façon, vous serez en mesure d’examiner les modifications avant la soumission habituelle.
Si vous fusionnez une version amont dans une branche Bazaar existante qui n’a pas antérieurement utilisé le format UDD, bzr merge-upstream va échouer avec une erreur indiquant que la balise de la version précédente de l’amont n’est pas disponible ; la fusion ne peut être terminée sans connaître la version de base pour la fusion. Pour contourner ce problème, créez une balise dans votre dépôt existant pour la dernière version de l’amont présente ici ; par exemple, si la dernière version Ubuntu est 1.1-0ubuntu3, créer la balise upstream-1.1 pointant vers la révision bzr que vous voulez utiliser comme la pointe de la branche amont.
[1] | Vous aurez besoin des dernières version de bzr et de bzr-builddeb pour que la commande merge fonctionne. Utilisez les versions d’Ubuntu 12.04 (Precise) ou les versions de développement depuis le PPA bzr. Spécifiquement, vous prendrez bzr version 2.5 beta 5 ou plus récent et bzr-builddeb version 2.8.1 ou plus récent. Pour les versions plus anciennes, utilisez plutôt la commande bzr merge-package. |
[2] | Pour vérifier les autres branches disponibles d’un paquet dans Debian, voir la page de code du paquet. Par exemple, https://code.launchpad.net/debian/+source/tomboy |
Utilisation des environnements Chroots¶
Si vous utilisez une version d’Ubuntu, mais que vous travaillez sur les paquets pour une autre version, vous pouvez créer l’environnement de l’autre version avec un chroot.
Un environnement chroot vous permet d’avoir un système de fichiers complet d’une autre distribution avec lequel vous pouvez travailler tout à fait normalement. Il évite la surcharge engendrée par l’exécution d’une machine virtuelle complète.
Créer un environnement Chroot¶
Utilisez la commande debootstrap pour créer un nouvel environnement chroot:
$ sudo debootstrap trusty trusty/
This will create a directory trusty and install a minimal trusty system into it.
If your version of debootstrap does not know about Trusty you can try upgrading to the version in backports.
Vous pouvez alors travailler dans l’environnement chroot:
$ sudo chroot trusty
Où vous pouvez installer ou désinstaller le paquet que vous souhaitez sans affecter votre système principal.
Vous devriez copier vos clés GPG/ssh et votre configuration Bazaar dans l’environnement chroot de manière à accéder aux paquets et les signer directement:
$ sudo mkdir trusty/home/<username>
$ sudo cp -r ~/.gnupg ~/.ssh ~/.bazaar trusty/home/<username>
Pour empêcher apt et d’autres programmes de se plaindre de l’absence d’informations linguistiques, vous pouvez installer les paquets linguistiques adéquats:
$ apt-get install language-pack-en
Si vous voulez exécuter des programmes X, vous devez lier le répertoire /tmp dans le chroot, en dehors de chroot, exécutez:
$ sudo mount -t none -o bind /tmp trusty/tmp
$ xhost +
Certains programmes peuvent nécessiter que vous liez /dev ou /proc.
Pour plus d’informations sur chroot consultez notre page wiki debootstrap chroot.
Alternatives¶
SBuild est un système similaire à PBuilder pour la création d’un environnement d’exécution de tests de construction de paquets. Il correspond plus à celui utilisé par Launchpad pour créer des paquets, mais nécessite un peu plus de paramètres que PBuilder. Voir la page wiki de l’équipe de sécurité de construction d’ environnement pour une explication complète.
Les machines virtuelles complètes sont utiles pour tester et empaqueter les programmes. TestDrive est un programme automatisant la synchronisation et l’exécution quotidienne d’images ISO, reportez-vous à la page wiki TestDrive pour de plus amples informations.
Vous pouvez également configurer pbuilder pour marquer un arrêt lorsqu’il rencontre un échec de compilation. Copiez C10shell depuis /usr/share/doc/pbuilder/examples dans un répertoire et utilisez l’argument --hookdir= pour désigner ce dernier.
Les ordinateurs EC2 cloud d’Amazon vous permettent de louer un ordinateur contre quelques cents américains de l’heure, vous pourrez régler les machines Ubuntu pour toute version prise en charge ou tout paquet sur ces ordinateurs. Ceci est utile lorsque vous voulez compiler de nombreux paquets en même temps ou surmonter les contraintes de bande passante.
Empaquetage traditionnel¶
La majorité de ce guide traite du Développement Distribué d’Ubuntu (UDD) qui utilise le système de contrôle de version distribuée (DVCS) Bazaar pour récupérer les paquets sources et soumettre les correctifs à l’aide de fusions de propositions. Cet article va présenter ce que nous allons appeler les méthodes d’empaquetage traditionnelles, en l’absence d’une meilleure définition. Avant que Bazaar ne soit adopté pour le développement d’Ubuntu, celles-ci étaient les méthodes classiques pour contribuer à Ubuntu.
Dans certains cas, vous devrez peut-être utiliser ces outils au lieu de l’UDD. Ainsi, il est bon de s’y familiariser. Avant de commencer, vous devriez déjà avoir lu l’article Mise en place.
Obtenir la source¶
Afin d’obtenir un paquet source, vous pouvez simplement lancer :
$ apt-get source <package_name>
Cette méthode a cependant quelques inconvénients. Elle télécharge la version de la source disponible sur votre système. Vous exécutez très probablement la version stable actuelle, mais vous souhaitez contribuer aux modifications concernant les paquets dans la version de développement. Heureusement, le paquet ubuntu-dev-tools fournit un script d’assistance :
$ pull-lp-source <package_name>
Par défaut, la version la plus récente de la version de développement sera téléchargée. Vous pouvez également spécifier une version ou une version d’Ubuntu comme :
$ pull-lp-source <package_name> trusty
to pull the source from the trusty release, or:
$ pull-lp-source <package_name> 1.0-1ubuntu1
pour télécharger la version 1.0-1ubuntu1 du paquet. Pour plus d’informations sur la commande, voir man pull-lp-source.
Pour notre exemple, supposons que nous avons un rapport de bogue disant que « colour » dans la description du xicc devrait être « color », et que nous souhaitions y remédier. (Note : Ceci est juste un exemple de quelque chose à changer et pas réellement un bogue.) Pour obtenir le code source, exécutez :
$ pull-lp-source xicc 0.2-3
Création d’un Debdiff¶
Un debdiff montre la différence entre deux paquets Debian. Le nom de la commande utilisée pour en générer un est également debdiff. Elle fait partie du paquet devscripts. Voir man debdiff pour tous les détails. Pour comparer deux paquets sources, passez les deux fichiers dsc en arguments :
$ debdiff <package_name>_1.0-1.dsc <package_name>_1.0-1ubuntu1.dsc
Pour continuer avec notre exemple, éditons le debian/control et « corrigeons » notre « bogue » :
$ cd xicc-0.2
$ sed -i 's/colour/color/g' debian/control
Nous devons également respecter le Champ de Spécification du Mainteneur Debian et éditer debian/control pour remplacer :
Maintainer: Ross Burton <ross@debian.org>
par :
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
XSBC-Original-Maintainer: Ross Burton <ross@debian.org>
Nous pouvons utiliser l’outil update-maintainer (dans le paquet ubuntu-dev-tools) pour le faire.
N’oubliez pas de documenter vos modifications dans debian/changelog en utilisant dch-i et générons ensuite un nouveau paquet source :
$ debuild -S
Maintenant, nous pouvons examiner nos modifications à l’aide de debdiff :
$ cd ..
$ debdiff xicc_0.2-3.dsc xicc_0.2-3ubuntu1.dsc | less
Pour créer un fichier de correctif que vous pourrez envoyer aux autres ou joindre à un rapport de bogue pour le parrainage, exécutez :
$ debdiff xicc_0.2-3.dsc xicc_0.2-3ubuntu1.dsc > xicc_0.2-3ubuntu1.debdiff
Application d’un Debdiff¶
En vue d’appliquer un debdiff, assurez-vous en premier lieu d’avoir le code source de la version avec laquelle il a été créé :
$ pull-lp-source xicc 0.2-3
Puis dans un terminal, modifiez le répertoire pour celui où a été décompressée la source :
$ cd xicc-0.2
Un debdiff est exactement comme un fichier correctif normal. Appliquez-le comme d’habitude avec|nbsp]:
$ patch -p1 < ../xicc_0.2.2ubuntu1.debdiff
Empaquetage de modules et d’applications Python¶
Nos empaquetages suivent la Charte Python de Debian. Nous allons utiliser le paquet python-markdown comme un exemple, qui peut être téléchargé à partir de PyPI. Vous pouvez examiner son empaquetage dans son dépôt Subversion.
Il existe deux types de paquets Python — modules et apps.
Au moment d’écrire ces lignes, Ubuntu dispose de deux versions incompatibles de Python 2.x et 3.x. /usr/bin/python est un lien symbolique vers une version par défaut de Python 2.x, et /usr/bin/python3 vers une version par défaut de Python 3.x. Les modules Python devraient être construits pour toutes les versions de Python prises en charge.
Si vous vous apprêtez à empaqueter un nouveau module Python, vous pourriez trouver l’outil py2dsc très utile (disponible dans le paquet python-stdeb).
debian/control¶
Les versions Python 2.x et 3.x du paquet doivent se trouver en paquets binaires séparés. Les noms doivent être formatés en python{,3}-nomdemodule (comme : python3-dbus.mainloop.qt). Ici, nous allons utiliser python-markdown et python3-markdown pour les paquets de module et python-markdown-doc pour la documentation du paquet.
Les choses de debian/control spécifiques à un paquet Python :
La section des paquets de module doit être python, et doc pour les paquets de documentation. Pour une application, un simple paquet binaire suffira.
Il convient d’ajouter les dépendances de construction sur python-all (>= 2.6.6-3~) et python3-all (>= 3.1.2-7~) pour s’assurer que les aides Python sont disponibles (voir la section suivante pour plus de détails).
Il est recommandé d’ajouter les champs X-Python-Version et X-python3-version — voir la section “Spécification des Versions Prises en Charge”de la charte pour des détails. Par exemple :
X-Python-Version: >= 2.6 X-Python3-Version: >= 3.1
Si votre paquet fonctionne seulement avec Python 2.x ou 3.x, la compilation dépend seulement d’un paquet -all et n’utilisez qu’un seul champ -Version.
Les paquets de modules doivent avoir les variables de substitution {python:Depends} et `` {python3:Depends}`` (respectivement) dans leurs listes de dépendances.
debian/rules¶
Les aides recommandées pour les modules python sont dh_python2 et dh_python3. Malheureusement, debhelper ne compile pas encore automatiquement des paquets Python 3.x (voir le bogue 597105 dans le Système de Traçage de Bogues Debian), de sorte que nous aurons besoin de le faire manuellement dans les sections de remplacement (les sauter si votre paquet ne prend pas en charge Python 3.x).
Voici notre fichier debian/rules (avec annotations) :
# These commands build the list of supported Python 3 versions
# The last version should be just “python3” so that the scripts
# get a correct shebang.
# Use just “PYTHON3 := $(shell py3versions -r)” if your package
# doesn’t contain scripts
PY3REQUESTED := $(shell py3versions -r)
PY3DEFAULT := $(shell py3versions -d)
PYTHON3 := $(filter-out $(PY3DEFAULT),$(PY3REQUESTED)) python3
%:
# Adding the required helpers
dh $@ --with python2,python3
override_dh_auto_clean:
dh_auto_clean
rm -rf build/
override_dh_auto_build:
# Build for each Python 3 version
set -ex; for python in $(PYTHON3); do \
$$python setup.py build; \
done
dh_auto_build
override_dh_auto_install:
# The same for install; note the --install-layout=deb option
set -ex; for python in $(PYTHON3); do \
$$python setup.py install --install-layout=deb --root=debian/tmp; \
done
dh_auto_install
C’est également une bonne pratique d’effectuer des tests lors de la construction, si ils sont fournis par l’amont. Habituellement, les tests peuvent être appelés à l’aide de setup.py test ou setup.py check.
debian/*.install¶
Les modules Python 2.x sont installés dans le répertoire /usr/share/pyshared/, et les liens symboliques sont créés dans /usr/lib/python2.x/dist-packages/ pour chaque version d’interpréteur, alors que ceux de Python 3.x sont tous installés dans /usr/lib/python3/dist-packages/.
Si votre paquet est une application et possède des modules Python privés, ils doivent être installés dans /usr/share/module, ou ``/usr/lib/module``si ces modules sont dépendants de l’architecture (par exemple, des extensions) (voir le paragraphe « Programmes fournissant des Modules Privés » de la Charte).
Ainsi, notre fichier python-markdown.install devrait ressembler à ceci (nous voulons aussi installer un markdown_py exécutable) :
usr/lib/python2.*/
usr/bin/
et python3-markdown.install comportera une seule ligne :
usr/lib/python3/
Le paquet -doc¶
L’outil le plus couramment utilisé pour la construction des documentations Python est Sphinx. Pour ajouter la documentation Sphinx à votre paquet (en utilisant l’aide dh_sphinxdoc), vous devez :
Ajouter à votre compilation une dépendance à python-sphinx ou python3-sphinx (selon la version de Python souhaitée) ;
Annexer sphinxdoc à la ligne dh --with ;
Lancer setup.py build_sphinx dans override_dh_auto_build (pas toujours nécessaire) ;
Ajouter {sphinxdoc:Depends} à la liste des dépendances de votre paquet -doc;
Ajouter le chemin du répertoire des documents intégrés (généralement build/sphinx/html) à votre fichier .docs.
Dans notre cas, les documents sont créés automatiquement dans le répertoire build/docs/ lorsque nous exécutons setup.py build, ainsi nous pouvons simplement les mettre dans le fichier python-markdown-doc.docs :
build/docs/
En raison de la présence de fichiers source .txt dans docs, nous allons aussi dire à dh_compress de ne pas les compresser — en ajoutant cela à debian/rules :
override_dh_compress:
dh_compress -X.txt
Vérification des erreurs d’empaquetage¶
Avec lintian, il existe un outil spécifique pour vérifier les paquets Python — lintian4py. Il est disponible dans le paquet lintian4python. Par exemple, ces deux commandes invoquent les deux versions de lintian et vérifient les paquets sources et binaires :
lintian -EI --pedantic *.dsc *.deb
lintian4py -EI --pedantic *.dsc *.deb
Ici, l’option -EI est utilisée pour activer les balises expérimentales et informatives.
Voir aussi¶
La Charte Python ;
L’article Python/Packaging sur le wiki Debian ;
Les articles Python/LibraryStyleGuide et Python/AppStyleGuide sur le wiki Debian ;
Les équipes Debian python-modules et python-apps.
Empaquetage pour KDE¶
L’empaquetage de programmes KDE dans Ubuntu est géré par les équipes Kubuntu et MOTU. Vous pouvez contacter l’équipe Kubuntu sur la liste de diffusion Kubuntu et le canal IRC Freenode #kubuntu-devel. Vous trouverez de plus amples informations sur le développement Kubuntu sur la page de wiki Kubuntu.
Notre empaquetage est conforme aux pratiques de l’Équipe Debian Qt/KDE et de l’équipe Debian KDE Extras. La plupart de nos paquets sont dérivés de l’empaquetage de ces équipes Debian.
Politique de correction¶
Kubuntu n’ajoute aucun correctif aux programmes KDE, sauf s’ils proviennent des auteurs de l’amont ou soumis à l’amont dans l’espoir qu’ils soient fusionnés au plus tôt, ou si nous avons consulté le problème avec les auteurs de l’amont.
Kubuntu ne modifie pas l’image de marque des paquets sauf si l’amont y compte (comme le logo en haut à gauche du menu Kickoff) ou si cela simplifie (comme la suppression des écrans de démarrage).
debian/rules¶
Les paquets Debian comprennent des ajouts à l’utilisation basique de Debhelper. Ceux-ci sont conservés dans le paquet pkg-kde-tools.
Les paquets utilisant Debhelper 7 doivent ajouter l’option --with=kde. Cela permettra de s’assurer que les options correctes de compilation sont utilisées et ajoutera des options telles que la gestion des souches kdeinit et traductions :
%:
dh $@ --with=kde
Quelques récents paquets KDE utilisent le système dhmk, une alternative à dh créé par l’équipe Debian Qt /KDE. Vous pouvez lire à ce sujet /usr/share/pkg-kde-tools/qt-kde-team/2/README. Les paquets utilisant ce système inclueront /usr/share/pkg-kde-tools/qt-kde-team/2/debian-qt-kde.mk au lieu d’éxecuter dh.
Traductions¶
Les traductions des paquets principaux sont importées dans Launchpad et exportés de Launchpad vers Ubuntu dans les paquets de langues.
Ainsi, tout paquet KDE principal doit générer des modèles de traduction, inclure ou mettre à disposition les traductions de l’amont et gérer les traductions du fichier .desktop.
Pour générer des modèles de traduction le paquet doit comprendre un fichier Messages.sh ; demandez à l’amont, s’il n’existe pas. Vous pouvez vérifier qu’il fonctionne en exécutant extract-messages.sh qui devrait produire un ou plusieurs fichiers .pot``dans le dossier ``po/. Cela se fera automatiquement lors de la compilation si vous utilisez l’option --with=kde de dh.
L’amont met généralement les fichiers .po de traduction dans le répertoire po/. S’ils n’y sont pas, vérifiez s’ils sont dans des paquets de langue séparés de l’amont tels que les paquets de langue KDE SC. S’ils sont dans des paquets de langue séparés, Launchpad devra les associer manuellement, contactez dpm pour cela.
Si un paquet est déplacé du dépôt « universe » au dépôt « main », il devra être téléchargé de nouveau avant que les traductions soient importées vers Launchpad.
Les fichiers .desktop ont également besoin de traductions. Nous corrigeons KDElibs pour lire les traductions depuis les fichiers .po désignés par une ligne X-Ubuntu-Gettext-Domain= ajoutée aux fichiers .desktop au moment de la compilation du paquet. Un fichier .pot est généré pour chaque paquet lors de la compilation et les fichiers .po sont téléchargés depuis l’amont et inclus dans le paquet ou dans nos paquets de langue. La liste des fichiers .po à télécharger depuis les dépôts KDE se trouve dans /usr/lib/kubuntu-desktop-i18n/desktop-template-list.
Bibliothèque de symboles¶
La bibliothèque de symboles est suivie par les fichiers .symbols pour vous assurer qu’aucun ne sera porté disparu pour les nouvelles versions. KDE utilise des bibliothèques C++ qui agissent un peu différemment des bibliothèques C. L’équipe Debian Qt/KDE possède des scripts pour gérer cela. Voir Travailler avec les fichiers de symboles pour savoir comment créer et maintenir ces fichiers à jour.
Lectures complémentaires¶
Vous pouvez consulter ce guide hors-ligne dans différents formats, si vous installez un des paquets binaires.
Si vous souhaitez en savoir plus à propos de la construction de paquets Debian, voici quelques ressources Debian que vous trouverez utiles :
Le Guide des Nouveaux Mainteneurs Debian — disponible en plusieurs langues ;
Tutoriel d’empaquetage (également disponible comme paquet).
Nous cherchons toujours à améliorer ce guide. Si vous relevez le moindre problème ou avez quelques suggestions, veuillez rapporter un bogue sur Launchpad. Si vous souhaitez apporter votre aide au travail sur ce guide, vous pouvez tout à fait récupérer la source.