Ubuntu Wiki

Dev Week -- Getting Started -- French -- Mon, Jan 19

[ gpocentek] (log en direct)
[ huats] Bonjour et tout d'abord merci d'être ici pour participer à cette session Francophone de la Ubuntu Developper Week.
[ huats] C'est la première fois que la UDW propose des sessions dans d'autres langues que l'anglais, ce qui bien sur nous réjouit, nous autres francophones de ubuntu-fr.
[ huats] Et d'abord c'est quoi l'UDW ?
[ huats] C'est une série d'ateliers qui se déroulent sur IRC pour permettre de mieux comprendre le monde du développement Ubuntu.
[ huats] Toutes les sessions seront en anglais, sauf celle là bien sur. Plus d'informations sur les autres sessions ici : https://wiki.ubuntu.com/UbuntuDeveloperWeek.
[ huats] D'ailleurs vous trouverez à cette page les logs de toutes les sessions, si jamais vous en manquez certaines.
[ huats] Je vous laisse donc avec gpocentek et Lutin, 2 illustres membres du collectif u-classroom (plus d'infos sur http://www.u-classroom.net), pour faire cette session pour ubuntu-fr qui portera sur :
[ huats] * Comment s'organise le développement d'ubuntu
[ huats] * GPG
[ huats] * Aperçu des outils de packaging
[ huats] * Votre premier paquet
[ huats] * Questions / Réponses
[ huats] Ah oui une dernière chose : veuillez ne pas poser de questions directement ici.
[ huats] Utilisez le channel #u-classroom-chat mis à disposition pour cela, en commençant votre question par QUESTION: . je me chargerai de faire passer les questions ici.
[ huats] Bref gpocentek et Lutin c'est à vous :)
[ gpocentek] merci huats :)
[ gpocentek] Juste une petite note avant de commencer
[ gpocentek] on va 'pratiquer' un peu durant la session, il y a quelques petits prérequis :
[ gpocentek] - avoir une système ubuntu sous la main
[ gpocentek] - connaitre un minimum la console
[ gpocentek] (les bases, cd, mkdir, rien de bien méchant)
[ gpocentek] - avoir un éditeur de texte installé
[ gpocentek] Vous pouvez vous contenter de suivre ce qui se passe, la pratique est optionnelle
[ gpocentek] Beaucoup de choses vont être abordées pendant la session, certaines uniquement survolées.
[ gpocentek] Le but est de proposer un aperçu de ce qui se passe chez Ubuntu et sur les PCs de ses développeurs. D'autres sessions auront lieu pour rentrer dans le détail.
[ gpocentek] Pour commencer, voyons comment s'organise Ubuntu pour son développement
[ gpocentek] * L'archive
[ gpocentek] L'archive (l'ensemble des paquets disponibles) est commune à toutes les variantes Ubuntu (Kubuntu, Xubuntu, etc.). Installer Kubuntu vous donne accès aux mêmes paquets qu'une installation Ubuntu. Seul le choix des paquets par défaut diffère.
[ gpocentek] L'archive est organisée en "composants", en fonction de la licence et du support. Deux équipes différentes gèrent ces dépôts, mais l'infrastructure reste identique et est fournie par Canonical.
[ gpocentek] (Canonical étant la société éditrice d'Ubuntu, Launchpad, Bzr...)
[ gpocentek] ces composants sont donc :
[ gpocentek] * main : logiciels libres, supportés par Canonical, maintenus par les 'core developers'
[ gpocentek] * restricted : logiciels non libres, supportés par Canonical, maintenus par les 'core developers'
[ gpocentek] * universe : logiciels libres, non supportés par Canonical, maintenus par les MOTUs (Masters Of The Universe)
[ gpocentek] * multiverse : logiciels non libres, non supportés par Canonical, maintenus par les MOTUs
[ gpocentek] Il faut savoir qu'une réorganisation des dépôts est en cours
[ gpocentek] il se peut qu'elle change d'ici peu
[ gpocentek] Il existe donc 2 équipes 'officielles' :
[ gpocentek] - core-devs : surtout des développeurs payés par Canonical, mais pas uniquement ; des membres de la communauté sont également core-dev. Ils ont accès à l'ensemble de l'archive Ubuntu.
[ gpocentek] (Accès en 'écriture' s'entend. Il peuvent uploader n'importe quel paquet dans l'archive)
[ gpocentek] - MOTUs : surtout des développeurs issus de la communauté. Ils ont accès aux dépôts Universe et Multiverse
[ gpocentek] * Une équipe non-officielle existe : tous les autres contributeurs (vous !). Vous pouvez tout à fait proposer des changements sans être officiellement développeur. Votre travail sera revu par un MOTU ou core-dev qui se chargera d'uploader vos changements dans l'archive.
[ gpocentek] huats: des questions ?
[ huats] QUESTION: Pourquoi réorganisé les dépots?
[ gpocentek] kusa: les accès par composant ne sont pas logiques
[ huats] QUESTION : comment sera la nouvelle organisation ?
[ gpocentek] par exemple des gens de la communauté travaillent sur KDE, et pourraient avoir accès aux paquets kde de tous les composants (main comme universe)
[ gpocentek] Coolgeek: ce n'est pas encore fixé, mais à priori la distinction main/universe n'existera plus
[ gpocentek] et des accès plus pointus devraient êtres mis en place
[ gpocentek] des accès plus précis (par type d'applications par exemple)
[ gpocentek] OK
[ gpocentek] Le cycle de développement d'Ubuntu pour continuer
[ gpocentek] Le cycle de développement de 6 mois est défini en début de nouveau cycle.
[ gpocentek] Pour Jaunty (la prochaine version) toutes les étapes sont déjà décidées : https://wiki.ubuntu.com/JauntyReleaseSchedule
[ gpocentek] Les grandes étapes sont les suivantes :
[ gpocentek] - snapshot de debian sid, synchronisation automatique pendant quelques semaines jusqu'au DIF (Debian Import Freeze)
[ gpocentek] pendant la release d'ubuntu précédente, les versions des logiciels ont évolué chez Debian
[ gpocentek] Ubuntu se sert de cet avancement pour se mettre à jour
[ gpocentek] pendant cette étape il existe 2 types de traitement des paquets :
[ gpocentek] * soit les paquets n'ont pas eu de modification ubuntu dans la release précédente et ils sont synchronisés ('sync')
[ gpocentek] (c'est fait automatiquement)
[ gpocentek] * soit des modifications existent et il faut manuellement réappliquer les modifications sur les nouvelles versions des paquets ('merge')
[ gpocentek] cette étape dure environ 3 mois
[ gpocentek] c'est le moment idéal pour commencer à jouer avec le packaging :)
[ gpocentek] ensuite :
[ gpocentek] - feature freeze : plus de nouvelles fonctionnalités, plus de nouvelles versions 'upstream' (sauf si elles corrigent uniquement des bugs). Le but est de commencer à stabiliser la distribution (https://wiki.ubuntu.com/FeatureFreeze)
[ gpocentek] si l'on continue à intégrer des nouveautés, on ne peut pas obtenir un ensemble stable et cohérent
[ gpocentek] le feature freeze est un tournant dans le processus de développement
[ gpocentek] - stabilisation : on se concentre sur les corrections de bugs uniquement
[ gpocentek] - release candidate : cette version est à priori la version finale, elle est très largement testée pour découvrir d'éventuels bugs bloquants
[ gpocentek] - release finale : celle que vous attendez avec impatience
[ gpocentek] Une fois la release faite, des mises à jours apparaissent. Elles sont limitées.
[ gpocentek] * Les SRU (https://wiki.ubuntu.com/StableReleaseUpdates) sont des mises à jours pour des corrections de bugs iportants
[ gpocentek] des mises à jour comme openoffice 2.4 -> 3.0 ne sont pas envisageables
[ gpocentek] le risque de créer des bugs et des régressions est bien trop important
[ gpocentek] * security updates (https://wiki.ubuntu.com/SecurityUpdateProcedures) : ces mises à jour corrigent des failles de sécurité
[ gpocentek] huats: des questions ?
[ huats] QUESTION: 1 seul jour entre la RC et la finale, c'est pas un peu court pour corriger d'éventuels bugs?
[ gpocentek] il y a une semaine entre la RC et la version finale
[ huats] QUESTION : plein de paquets sont creer pour Ubuntu (ex : instalation des drivers proprio), il ne sont pas traiter durant la periode de synchronisation ?
[ gpocentek] si, tous les nouveaux paquets créés pour ubuntu sont intégré durant cette période
[ gpocentek] intégrés*
[ gpocentek] (même s'ils ne viennent pas de debian)
[ gpocentek] ok
[ huats] QUESTION: La migration OpenOffice 2.4 -> 3.0 est possible au vu des autres distributions, pourquoi ubuntu ne le fait pas?
[ gpocentek] c'est un choix, souvent critiqué mais assez compréhensible...
[ gpocentek] une nouvelle version majeure est un *risque*
[ gpocentek] elle corrige certainement des bugs, apportent des nouvelles fonctionnalités mais très certainement de nouveaux bugs
[ gpocentek] (aussi)
[ huats] QUESTION : une version tout les 6 mois.. ca fait peu comme delais entre chaque version...
[ gpocentek] ubuntu a choisi de ne pas riquer de nouveaux bugs
[ gpocentek] Coolgeek: c'est pour ça qu'existent des versions LTS
[ gpocentek] (Long Term Support)
[ gpocentek] les releases intermédiaires permettent justement de palier au court laps de temps entre 2 releases 'standard'
[ gpocentek] on apporte des nouveautés tout en garantissant qu'une version définie restera stable
[ huats] QUESTION : donc ce ne sont que des betas les versions entre les LTS ?
[ gpocentek] je ne le dirais pas comme ça, mais on peut considérer que les releases intermédiaires sont plus 'cutting edge' que les LTS en effet
[ gpocentek] ça ne gênera pas un utiliseur 'geek', ça gênera par contre une entreprise qui gardera la version LTS
[ gpocentek] ok
[ gpocentek] je vais vous présenter rapidement quelques outils en ligne qui sont utilisés par les développeurs quotidiennement
[ gpocentek] - L'outil principal de développement est LaunchPad (http://launchpad.net)
[ gpocentek] -> launchpad gère les bugs, les paquets (build, publications), les équipes, les utilisateurs, les spécifications, les branches bzr (code)...
[ gpocentek] il a été développé pour ubuntu mais est utilisé maintenant par de nombreux projets
[ gpocentek] -> c'est un outil développé par Canonical (qui sera bien open source)
[ gpocentek] La première chose à faire si vous voulez contribuer à Ubuntu est très certainement de vous créer un compte sur LP
[ gpocentek] - qa.ubuntu.com est le site dédié à la QA (Quality Assurance) d'Ubuntu
[ gpocentek] qa.ubuntu.com et launchpad sont gérés par canonical
[ huats] QUESTION : launchpas SERA bientot open source ? il ne l'est pas déja ? pourquoi ?
[ gpocentek] d'autres outils sont gérés par la communauté :
[ gpocentek] Coolgeek: je ne saurais pas te dire... Canonical a ses raisons
[ gpocentek] LP sera open source dans le courant de l'année (cet été je crois, ça a été annoncé)
[ huats] (le 21 juillet)
[ gpocentek] Les outils communautaire sont donc :
[ gpocentek] - REVU : https://wiki.ubuntu.com/MOTU/Packages/REVU
[ gpocentek] -> REVU est un outil permettant aux contributeurs de mettre en ligne de nouveaux paquets, afin qu'ils soient revus et commentés par les développeur
[ gpocentek] - UbuntuWire est également un espace communautaire proposant plusieurs outils (http://ubuntuwire.com)
[ huats] QUESTION: quelle est la différence concrete entre launchpad et QA, la recherche de qualité n'est pas elle meme la recherche de bugs et autres?
[ gpocentek] bonne question...
[ gpocentek] les 2 outils sont liés
[ gpocentek] Je dirais que Launchpad est utilisés pour réaliser, appliquer, faire les choses, alors que les outils de QA servent à faire un état des lieus
[ gpocentek] lieux*
[ huats] QUESTION : des mises a jour entre versions donne parfois des resultats etonnant (perte du son, perte de la video,...) ce point est aussi testé dans la QA ?
[ gpocentek] c'est le rôle des équipes de QA de tester ce genre de régression
[ gpocentek] ces problèmes arrivent, malheureusement, c'est pourquoi les mises à jours restent limitées
[ gpocentek] les problèmes liés au matériel sont particulièrement difficile à tester
[ gpocentek] difficiles*
[ gpocentek] huats: d'autres questions ?
[ huats] gpocentek: non c'est bon :)
[ gpocentek] ok
[ gpocentek] juste un mot sur les procédures
[ gpocentek] vous verrez que de nombreuses procédures pour faire telle ou telle chose sont définies chez Ubuntu
[ gpocentek] en tant que contributeur il y a de quoi s'y perdre
[ gpocentek] c'est pour ça que des procédures particulières existent, 2 en particulier :
[ gpocentek] - le sponsoring -> le travail que vous proposez est revu et corrigé par un développeur Ubuntu
[ gpocentek] - le mentoring -> une personne de la communauté vous aide à comprendre toutes ces procédures, en plus de vous aider dans le travail de développement en soi
[ gpocentek] je laisse la parole à huats qui va vous en dire plus sur le mentorig :)
[ gpocentek] (questions avant ?)
[ huats] ok
[ huats] questions :
[ huats] QUESTION : lors des mises a jour ca ne marchent pas alors que la reinstallation complete du systeme résoud ces problèmes la. une MAJ de versions n'est pas simplement le rempalcement des paquets ?
[ gpocentek] une MAJ n'implique pas juste un remplacement de fichiers...
[ gpocentek] il faut gérer tout ce qu'a pu faire l'utilisateur sur les fichiers contenus dans le paquet précédent
[ gpocentek] on a parfois de mauvaises surprises parce qu'on n'a pas pensé à telle ou telle modification
[ huats] QUestion :Quelles sont les solutions pour les utilisateurs Ubuntu quand un régression apparait lors d'une mise à jour majeur d'ubuntu
[ Lutin] (sans compter des potentiels mois de bidouille de la part de l'utilisateur qui ne sont pas gérable au niveau du système de paquets)
[ gpocentek] sam[cOe]: la première chose à faire est de rapporter le problème aux développeurs
[ gpocentek] les développeurs fourniront des solutions pour rétablir le système
[ huats] gpocentek: c'est tout :)
[ gpocentek] huats: à toi :)
[ huats] Pour permettre une entrée dans le monde du devel ubuntu plus simple, il existe depuis plusieurs années un système de mentoring (https://wiki.ubuntu.com/MOTU/Mentoring)
[ huats] Le principe de base est qu'il est souvent plus simple (surtout pour des personnes un peu réservées) de parler avec un interlocuteur bien identifié (le mentor).
[ huats] Normalement tout se passe en anglais, puisque nous essayons de faire des paires de avec toujours un mentor et un padawan de langue différente (mais vivant dans les même zones horraires).
[ huats] Le mentoring se décompose en 2 étapes.
[ huats] Dans la partie junior, le mentor est là pour "initier" le 'padawan' au méthodes de travail, aux équipes, au différents processus évoqués par gpocentek
[ huats] alors que dans la partie senior, il est plus un guide pour préparer son application à MOTU, et donc aider à affiner son investissement dans Ubuntu.
[ huats] Ce qui sépare le junior du senior est le titre de "Ubuntu Universe Contributor", donné par le MOTU Council
[ huats] Je ne vais pas plus détailler car on peut en parler pendant des heures
[ huats] mais si vous avez des questions sur le mentoring, n'hésitez pas à me les poser.
[ huats] J'y répondrai avec plaisir, puisque ce programme me tient particulièrement à coeur (normal j'en suis le coordinateur ...).
[ gpocentek] QUESTION : le fait que les langues soit differente, si le raporteur de bug ne connais pas bien l'anglais, ne risque t'il pas d'avoir une incompréhension et une non résolution du bug ?
[ huats] ça arrive
[ huats] c'est pour celà que les bugs doivent etre 'vérifiés' et reproduit
[ huats] celà fait partie du travail de la gestion des bugs
[ huats] QUESTION: qui peut trouver un intérêt à demander un mentor ? plutôt un coder ?
[ huats] BramCI: non pas forcément
[ huats] toute personne qui veut commencer à participer au dével ubuntu peut y trouver un intéret
[ huats] car un mentor te guidera dans tes premiers pas aussi
[ huats] en te disant te faisant travailler sur des bugs à ton niveau...
[ huats] et d'ailleurs beaucoup de bugs ne sont pas du code à proprement parlé.
[ huats] donc le mentoring va plus etre là pour un apprentissage des procédures et techniques dans le cadre de ubuntu (et du packaging ubuntu)
[ gpocentek] QUESTION: Est-ce que Ubuntu manque de contributeurs et si oui, est-ce dans un domaine particulier?
[ huats] on a toujours besoin de plus de contributeurs....
[ gpocentek] (il y a plus de 35000 paquets dans l'archive, ça fait du boulot...)
[ huats] les efforts de traduction sont enormes. Même si c'est vrai qu'en France nous sommes vraiment gatés par le travail de l'équipe
[ huats] au niveau tri des bugs un travail énorme est à faire aussi...
[ gpocentek] QUESTION: Est-ce qu'un debutant en programmation python peut contribuer a Ubuntu, si oui, comment trouver des projets auquel s'intégrer?
[ huats] et puis le packaging, comme vient de le dire gpocentek : 35000 paquets c'est enorme...
[ huats] bref on est toujours d'accord pour accueillir plus de monde :)
[ huats] un débutant en programmation python peut tout à fait contribuer...
[ huats] d'ailleurs pour participer au packaging il n'est pas indispensable de connaitre TOUS les languages
[ huats] mais c'est vrai que pour ubuntu, python c'est symap
[ huats] il n'y a pas de règle absolue pour trouver des projets où participer
[ huats] des solutions pour trouver des choses à faire existent (comme harvest de daniel holbach à taper dans google)
[ huats] sinon c'est vrai que le mentoring est une bonne approche :) (comment ça de la pub s'est glissée dans cette phrase)
[ huats] bon
[ huats] je pense que l'on va passer à la suite :)
[ huats] gpocentek: / Lutin: j'arrete de parler :)
[ gpocentek] les questions sont les bienvenues après la session s'il y en a d'autre
[ huats] bien sur !
[ gpocentek] Pour la suite on va s'attaquer à des choses plus techniques
[ gpocentek] La première étant GnuPG
[ gpocentek] Chaque développeur ou contributeur Ubuntu est identifié par une carte d'identité numérique, une clé GPG
[ gpocentek] Pour les curieux, GPG signifie GNU Privacy Guard, c'est une implémentation du protocole OpenPGP (RFC4880), qui utilisele principe de la cryptographie asymétrique
[ gpocentek] pour les encore plus curieux : http://fr.wikipedia.org/wiki/Cryptographie_asymétrique)
[ gpocentek] GPG a plusieurs intérêts :
[ gpocentek] - signer des documents (mails par exemple). Le destinataire qui possède la clé publique pourra vérifier que vous êtes bien l'auteur du mail. Dans le cadre d'Ubuntu, GPG est particulièrement utilisé pour déterminer si vous avez les autorisations nécessaires pour mettre à jour des paquets: seuls les fichiers signés par la clé d'un developpeur Ubuntu sont acceptés dans l'archive.
[ gpocentek] oops, j'ai oublié une chose :
[ gpocentek] Une clé GPG se divise en 2 parties, une clé privée (personnelle, à garder au chaud), et une clé publique à publier (sur un serveur de clés).
[ gpocentek] donc les intérêtes de GPG (bis) :
[ gpocentek] - signer des documents (mails par exemple). Le destinataire qui possède la clé publique pourra vérifier que vous êtes bien l'auteur du mail. Dans le cadre d'Ubuntu, GPG est particulièrement utilisé pour déterminer si vous avez les autorisations nécessaires pour mettre à jour des paquets: seuls les fichiers signés par la clé d'un developpeur Ubuntu sont acceptés dans l'archive.
[ gpocentek] crypter un document. La clé publique du destinataire est utilisée pour crypter le document, et ne pourra être décrypté que par le possesseur de la clé privée correspondante (à moins d'un 'vol' de clé, ce sera le destinataire).
[ gpocentek] - non-répudiabilité. L'expéditeur d'un mail signé avec sa clé privée ne peut pas nier avoir envoyé le mail
[ gpocentek] (je ne vais pas entrer plus que ça dans le détail pour cette session)
[ gpocentek] est-ce qu'il y a des questions ?
[ gpocentek] si non je propose de vous créer votre propre clé GPG
[ huats] gpocentek: non
[ huats] pas de question
[ gpocentek] je vais vous donner la marche à suivre, s'il y a des problèmes on pourra les régler après la session
[ gpocentek] la première chose à faire si ce n'est pas déjà fait est d'installer gpg :
[ gpocentek] sudo apt-get install gnupg
[ gpocentek] Pour créer votre clé utilisez la commande suivante :
[ gpocentek] gpg --gen-key
[ gpocentek] Une série de choix vont vous être proposés, je vous conseille d'utiliser les choix par défaut
[ gpocentek] les champs importants à renseigner sont votre nom, votre email, et éventuellement un commentaire
[ gpocentek] l'étape suivante est d'envoyer votre clé publique sur un serveur de clés (keyserver.ubuntu.com par exemple) :
[ gpocentek] gpg --keyserver keyserver.ubuntu.com --send-key adresse@mail.foo
[ gpocentek] la clé publique sera disponible, et vos mails signés pourront être vérifiés
[ gpocentek] vous aurez sans doute un jour à vérifier une signature de clé. Pour récupérer la clé à vérifier, la commande suivante est à utiliser :
[ gpocentek] gpg --keyserver keyserver.ubuntu.com --recv-keys
[ gpocentek] vous pourrez ensuite vérifier la signature du mail/fichier avec :
[ gpocentek] gpg --verify nom_du_fichier
[ huats] QUESTION: Lors de la création d'une clé, dans quels cas vaut il mieux choisir RSA que DSA? (et inversement)
[ gpocentek] MatToufoutu: très bonne question à laquelle je ne saurais pas répondre...
[ huats] QUESTION: Pourquoi lors de la création de la clé GPG il faut faire travailler le disque dur?
[ gpocentek] MatToufoutu: je te conseille de poser la question à gapz (sur ce chan) après la session
[ gpocentek] kusa: la génération de la clé utilise un grand nombre d'informations aléatoire
[ gpocentek] créer des évènements système permet de générer ces éléments
[ gpocentek] ok
[ gpocentek] je ne vais pas rentrer plus dans le détail, le temps passe vite...
[ gpocentek] je vais laisser la parole à Lutin qui va rentrer dans le vif du sujet 'packaging'
[ Lutin] avant que je démarre, plus d'autres questions ?
[ huats] Lutin: non c'est bon vas y
[ Lutin] d'accord.
[ Lutin] maintenant que nous avons le cycle de release ubuntu, nous allons nous intéresser à la façon dont sont faits les paquets consituant la distribution
[ Lutin] * Il existe deux types de paquets :
[ Lutin] - les paquets binaires sont les fichiers .deb installables sur votre pc. Ces paquets peuvent
[ Lutin] être installés par apt grâce aux lignes 'deb http://...' de votre sources.list
[ Lutin] - les paquets sources contiennent le code source du logiciel, et les scripts/données nécessaires
[ Lutin] à la construction des paquets binaires. Pour pouvoir récupérer des paquets source en utilisant
[ Lutin] apt, vous devez avoir des lignes de la forme 'deb-src http://x.y.z'
[ Lutin] cependant, un paquet source donné peut produire plusieurs paquets binaires
[ Lutin] par exemple, le paquet source 'xmoto' génère 2 paquets binaires, 'xmoto' et 'xmoto-data'
[ Lutin] * Tous les paquets .deb publiés dans les dépôts sont compilés depuis un "paquet source", dans un environnement minimal.
[ Lutin] La préparation du paquet dans cet environnement minimal est fortement conseillée, afin de s'assurer que les paquets installés sur votre système n'influencent pas la création (on parle de "build") du paquet.
[ Lutin] Pour éviter des erreurs de construction lors de l'upload dans les dépôts, il est nécessaire de tester vous même que le paquet est valide. pbuilder est un outil qui permet ceci.
[ Lutin] pour la suite, nous allons donc avoir besoin de quelques outils, vous allez donc devoir installer quelques paquets :)
[ Lutin] sudo aptitude install ubuntu-dev-tools build-essential pbuilder lintian
[ gpocentek] Question : deb peut t'il suffire ou faut t'il touours deb et deb-src ? pour une simple utilisation et non en tant que développeur
[ Lutin] pour une utilisation simple, les fichiers .deb sont suffisants
[ Lutin] les paquets sources sont utiles surtout si on s'intéresse à la création et la modifications de paquets
[ gpocentek] Question: Les paquets binaires sont compilé par le dev ubuntu puis envoyé dans l'archive ou le paquet binaire est généré automagiquement à partir du paquet source?
[ Lutin] dans ubuntu, seuls les paquets sources sont envoyés ("uploadés") par le developpeur. ces paquets sont ensuite compilés pour toutes les architectures par des machines de compilation ("buildd")
[ gpocentek] question: Ubuntu conseil apt. Or, je lit quelque fois que aptitude est meilleur. Quel est le mieux ? question de gouts ? (ceci n'est pas un troll mais une reelle question)
[ Lutin] cependant, ce n'est pas le cas de debian, ou les uploads ne peuvent pes être uniquement consituté de paquets source: le developpeur doit également uploader des paquets binaires
[ Lutin] majoritairement une question de goût
[ huats] Question: j'ai entendu dire que les paquets trouvé dans deb-src étaient rarement à jours ou du moins synchronisé avec les deb. Ne vaut-il pas mieux aller chercher les sources sur les sites des dev ?
[ Lutin] les paquets deb-src tels que fournis dans l'archive ubuntu sont ceux qui sont utilisés pour créer les debs que vous installez chez vous
[ Lutin] par conséquent, un deb-src ne peut pas être moins récente que les deb
[ Lutin] (l'inverse est cependant possible, si un paquet défecteux est uploadé, mais nous en reparlerons)
[ Lutin] d'autres questions ?
[ gpocentek] non
[ Lutin] dans ce cas, je vais rapidement exposer le principe de fonctionnement de pbuilder, qui, donc, vous permet de compiler vos paquets binaires a partir d'un paquet source
[ Lutin] Afin de garantir que les paquets sont compilés dans un environnement "propre", pbuilder utilise ce qu'on appelle un chroot.
[ Lutin] Le principe consiste à télécharger une image système minimale dans un dossier de votre système. Pbuilder crée ensuite un tarball de ce système minimal. A chaque nouvelle utilisation, ce tarball est décompressé, et pbuilder "chroot" dans ce dossier: son nouveau / se situe à l'intérieur du dossier qu'il vient de créer. Les paquets nécessaires à la compilation (notez que le terme 'compiler' n'est pas exact, de nombreux paquets
[ Lutin] Pour pouvoir utiliser pbuilder, il faut donc auparavant créer les fichiers nécessaires: vous pouvez lancer la commande $ sudo pbuilder create pour créer le pbuilder dont la configuration se trouve dans ~/.pbuilderrc si ce fichier existe, et dans /etc/pbuilderrc sinon. Cette étape est longue (téléchargement des paquets, décompression), nous n'allons donc pas nous attarder sur la création du pbuilder (mais nous serons ravis de rép
[ gpocentek] Lutin: on a perdu un bout de paragraphe
[ gpocentek] Les paquets nécessaires à la compilation (notez que le terme 'compiler' n'est pas exact, de nombreux paquets ne nécessitent aucune compilation) de votre paquet sont ensuite installés, le paquet est compilé et copié hors du chroot, qui est ensuite supprimé.
[ gpocentek] et le paragraphe suivant a été tronqué aussi
[ gpocentek] (désolés, aléas du direct)
[ Lutin] je vais le recoller, puisque ça ne passer pas chez tout le monde apparemment :)
[ Lutin] Afin de garantir que les paquets sont compilés dans un environnement "propre", pbuilder utilise ce qu'on appelle un chroot.
[ Lutin] Le principe consiste à télécharger une image système minimale dans un dossier de votre système.
[ Lutin] Pbuilder crée ensuite un tarball de ce système minimal. A chaque nouvelle utilisation, ce tarball est décompressé,
[ Lutin] et pbuilder "chroot" dans ce dossier: son nouveau / se situe à l'intérieur du dossier qu'il vient de créer.
[ Lutin] Les paquets nécessaires à la compilation (notez que le terme 'compiler' n'est pas exact, de nombreux paquets
[ Lutin] ne nécessitent aucune compilation) de votre paquet sont ensuite installés, le paquet est compilé et copié
[ Lutin] hors du chroot, qui est ensuite supprimé.
[ Lutin] pbuilder permet donc de compiler le paquet dans un environnement ou seul le strict minimum est installé, afin de garantir que la création du paquet soit reproductible
[ huats] Question: On peut bien installer un programme via le paquet source sans passer par l'étape chroot pbuilder etc?
[ Lutin] si on veur installer un paquet via le paquet source, il va falloir compiler les paquets binaires auparavant
[ Lutin] pour celà, pbuilder n'est en effet pas obligatoire
[ Lutin] simplement, si on se place dans l'optique de compiler un paquet afin de vérifier qu'il est d'assez bonne qualité dans l'archive, c'est fortement recommandé afin de garantir que le paquet compile bien
[ Lutin] c'est à peu près clair ?
[ gpocentek] ça a l'air
[ Lutin] ok, je vais donc laisser la main a gpocentek, qui va vous faire une présentation du dossier debian/, qui permet de créer les paquets
[ gpocentek] merci Lutin
[ gpocentek] pour que ce soit assez parlant je vous propose de récupérer le paquet source nommé 'hello-debhelper'
[ gpocentek] si vous avez des entrées deb-src dans votre sources.list, créez un nouveau dossier :
[ gpocentek] mkdir hello
[ gpocentek] cd hello
[ gpocentek] et récupérez le paquet source avec
[ gpocentek] apt-get source hello-debhelper
[ gpocentek] c'est la méthode recommandée pour récupérer un paquet source, mais il y a d'autres méthodes
[ gpocentek] J'utilise très souvent http://packages.ubuntu.com
[ gpocentek] http://packages.ubuntu.com/source/jaunty/hello-debhelper
[ gpocentek] dans la section 'download' vous pouvez voir 3 fichiers à récupérer
[ gpocentek] pour récupérer les 3 en une fois utilisez la commande :
[ gpocentek] dget http://archive.ubuntu.com/ubuntu/pool/main/h/hello-debhelper/hello-debhelper_2.2-3.dsc
[ gpocentek] 3 fichiers sont donc téléchargés :
[ gpocentek] hello-debhelper_2.2-3.dsc est le fichier de description du paquet source
[ gpocentek] hello-debhelper_2.2.orig.tar.gz est une archive contenant les sources du logiciel
[ gpocentek] enfin hello-debhelper_2.2-3.diff.gz est un patch (compressé) qui contient toutes les informations nécessaires à la création du paquet
[ gpocentek] On fera un cours dédié au packaging qui rentrera dans le détail. L'important est de voir que les sources 'originales', et le code de construction du paquet sont clairement séparés
[ gpocentek] un paquet source doit être extrait
[ gpocentek] apt-get le fait automatiquement, pas dget
[ gpocentek] pour extraire le paquet source, utilisez la commande :
[ gpocentek] dpkg-source -x hello-debhelper_2.2-3.dsc
[ gpocentek] un dossier sera créé, contenant les sources, auxquelles sont ajoutées une dossier debian/
[ gpocentek] rentrons dans ce dossier :
[ huats] Question: Le tar.gz orig est celui des développeurs d'origine (celui qu'on pourra trouver sur leur site)?
[ gpocentek] cd hello-debhelper-2.2/debian/
[ gpocentek] alpheb: exactement
[ gpocentek] dans ce dossier vous avez 5 fichiers :
[ gpocentek] gauvain@zero:~/hello/hello-debhelper-2.2/debian$ ls
[ gpocentek] changelog compat control copyright rules
[ gpocentek] - le changelog décrit tous les changements faits sur le paquet
[ gpocentek] - compat est un fichier particulier lié à debhelper (un ensemble d'outil d'aide au packaging)
[ gpocentek] - control est le fichier de description du paquet. Il indique sa section, ses dépendances, sa description...
[ gpocentek] - copyright liste les différents copyright et licenses des sources du logiciel
[ gpocentek] - rules est le 'moteur' de compilation du paquet. C'est un fichier Makefile qui décrit toutes les étapes de création du paquet, afin que cette création soit entièrement automatisée
[ gpocentek] questions ?
[ gpocentek] Lutin va vous montrer maintenant comment modifier ce paquet, et comment le recompiler (faire votre premier paquet)
[ gpocentek] Lutin s'est perdu apparemment ;)
[ Lutin] non, je suis là :)
[ Lutin] Passons a un exemple de modification d'un paquet source. Admettons que le champ Description du
[ Lutin] paquet (ce qui est affiché quand vous lancez la commande 'apt-cache search ') ne nous
[ Lutin] plaise pas, nous allons donc détailler les étapes nécessaires pour pouvoir le changer.
[ Lutin] tout d'abord, nous allons devoir éditer le fichier debian/control, qui contient ce champ Description:
[ Lutin] (vous pouvez utiliser votre éditeur favori, ou lire le cours sur vim :p)
[ Lutin] ramplcons la description par "Ceci est le paquet qui nous sert d'illustration pour le cours dans le cadre de l'Ubuntu Developper Week"
[ Lutin] remplaçons, pardon
[ Lutin] une fois cette modification effectuée, il va falloir l'indiquer dans le fichier changelog, afin de garder l'historique des modifications
[ Lutin] pour celà, un outil appelé "dch" existe: il vous suffit de lancer la commande "dch -i"
[ Lutin] ceci va ouvrir un éditeur de texte, il ne vous reste plus qu'a ecrire une crève description du changement que vous avez effectué, puis sauvegarder
[ Lutin] brève, pas crève, vous aurez tous compris.
[ Lutin] Vous pouvez remarquer au passage que dch a incrémenté automatiquement le numéro de version: la nouvelle version est 2.2-3ubuntu1. La partie 'ubuntu1' a été ajoutée pour montrer que ce changement est spécifique à ubuntu. Dans le cas ou le paquet aurait auparavant des modifications spécifiques à ubuntu, le nouveau numéro aurait été 2.2-3ubuntu2 par exemple.
[ Lutin] (pause, histoire de ne pas perdre tout le monde)
[ gpocentek] QUESTION : dch est un outil qui marche pour tout ou spécifique au dev ubuntu?
[ Lutin] dch est un outil spécifique à debian à l'origine, qui a été adapté pour ubuntu et les autres distributions dérivées de debian
[ Lutin] il n'est utilisable que pour le packaging, car le format du fichier debian/changelog est spécifique, et dch ne sait pas parcourir d'autre format
[ Lutin] reprenons ... maintenant que vous avez effectué les modifications nécessaires, il va falloir regénérer le paquet source
[ Lutin] afin de générer le nouveau diff.gz et le nouveau fichier .dsc, vous pouvez utiliser la commande suivante:
[ Lutin] debuild -S -sa -k $KEY, ou $KEY est l'ID de votre clé GPG, si vous en avez une
[ Lutin] sinon, utilisez debuild -S -sa -uc -us. ceci va dire à debuild de ne pas signer le paquet source, ce qui vous évitera des soucis dans le cas ou vous n'avez pas de clé
[ Lutin] maintenant, vous pouvez vous rendre dans le dossier parent pour la suite des opérations : cd ..
[ Lutin] Afin de vérifier que vous n'avez pas effectué de modification non voulue par inadvertence, vous pouvez utiliser la commande 'debdiff': celle-ci vous permet de lister les différences entre le paquet
[ Lutin] source que vous venez de créer et le précédent
[ Lutin] par exemple: debdiff hello-debhelper_2.2-3.dsc hello-debhelper_2.2-3ubuntu1.dsc vous liste les changements que vous venez de faire
[ Lutin] une fois que vous avez vérifié que vous n'avez changé que les parties que vous vouliez changer, vous pouvez passer à la compilation du paquet:
[ Lutin] cd hello-debhelper-2.2
[ Lutin] dpkg-buildpackage -rfakeroot
[ Lutin] une fois le build fini, votre paquet binaire se trouve dans le dossier parent
[ Lutin] de nombreuses autres méthodes de compilation et vérification des paquets existent, mais nous n'avons pas vraiment le temps de les aborder, ce sera très probablement abordé dans un cours à venir consqcré au packaging
[ Lutin] désolé d'aller si vite en cette fin de cours, mais ne vous inquiétez pas si ça ne fonctionne pas, nous sommes ici pour répondre à vos questions
[ didrocks] Merci tout le monde pour cette session en particulier, gpocentek, Lutin et huats.
[ didrocks] Je suis persuadé que les principes de base du développement sont maintenant mieux compris. Vous êtes donc armés pour déjà commencer à participer activement et suivre les autres sessions de l'Ubuntu Developer Week :
[ didrocks] https://wiki.ubuntu.com/UbuntuDeveloperWeek
[ didrocks] N'oubliez pas que ceci n'est qu'une introduction et vous donne les clefs pour aller plus loin, notamment, quels termes chercher. N'oubliez pas qu'un bon développeur est tout d'abord quelqu'un qui lit beaucoup de documentation.
[ didrocks] (en gros, si vous n'avez pas tout compris, c'est tout à fait normal :))
[ didrocks] Et puis surtout n'hésitez pas à venir nous poser des questions
[ didrocks] sur IRC (nous sommes normalement sur #u-classroom).
[ gpocentek] et sur #ubuntu-fr-devel
[ didrocks] aussi ^^
[ didrocks] De plus, dans un futur proche (le week-end du 21/22 février), vous pourrez assister à la Ubuntu Global Bug Jam qui sera un moyen sympathique de continuer votre initiation au devel ubuntu (et à launchpad en particulier) près de chez vous (au moins à Toulouse et Paris pour le moment). Mais nous en reparlerons d'ici là.
[ didrocks] Merci encore d'être venu à ce cours, en espérant qu'il vous ait plus. À très bientôt pour de nouveaux cours sur #u-classroom!
[ gpocentek] merci didrocks (qui a géré l'organisation du cours, et la relation avec dholbach chez Ubuntu)
[ huats] merci didrocks :)
[ didrocks] gpocentek & huats : you're welcome :)
[ Lutin] didrocks: ROCK ON!