From Mageia wiki
Jump to: navigation, search


Drakconf multiflag.png
Autres langues
English ; Español ; Français ;
Résumé :
Cette page suppose que vous avez suivi complètement la procédure pour Devenir empaqueteur Mageia. Vous avez notamment suivi les didacticiels Empaquetage pour débutant et Construire des paquetages RPM.
Vous êtes un apprenti et vous avez un parrain. Dans le reste de cette page, nous décrirons le cheminement principal que vous devez suivre pour contribuer à Mageia en tant qu’apprenti.

Déroulement du travail de l’apprenti

Préparations

À partir du tutoriel que vous avez suivi, votre installation devrait déjà avoir les paquetages suivants et leur configuration conforme :

  • rpm : notre version patchée de Red Hat.
  • rpm-build : contiens les scripts utilisés pour construire les paquetages.
  • spec-helper : un outil pour minimiser les specfiles en automatisant certaines choses comme le dépouillement des binaires et la compression des pages de manuel.
  • libtool : utilisé par certains scripts de configuration pour construire des bibliothèques communes.
  • rpmlint : utilisé pour vérifier la validité des données générées src.rpm.

De plus, vous devriez installer :

  • rpmlint-mageia-policy : des directives Mageia spécifiques pour rpmlint.
  • mgarepo : pour les échanges avec le système git et de construction de Mageia.
  • bm : pour construire et reconstruire des paquetages.
  • nopaste : pour envoyer facilement des correctifs à votre parrain.

Pour faciliter la création d’un nouveau fichier de spécifications, installez

  • rpmdevtools : Ceci se fait à l’aide de la commande « rpmdev-newspec »

Pour Mageia Cauldron, vous pouvez installer le meta package pour empaqueteurs.

  • task-packager : Ce paquetage installera les outils dont vous aurez besoin pour démarrer.

Ce logiciel vous facilitera l’apprentissage.

Mise en place de mgarepo

mgarepo est le principal moyen permettant aux empaqueteurs d'interagir avec la distribution Mageia. En tant qu’apprenti sans droits de commiter, vous devez le configurer pour pouvoir utiliser la validation anonyme. Pour ce faire, vous devez éditer le fichier de configuration manuellement :

  • Créer un fichier de configuration de base :
mkdir ~/.mgarepo; cp /etc/mgarepo.conf ~/.mgarepo/config
  • Editer ~/.mgarepo/config et changer :
repository = git+ssh://git.mageia.org/git/packages/

vers

repository = git://git.mageia.org/git/packages/

Vous avez maintenant tous les outils nécessaires pour commencer à préparer les paquetages. Les deux tâches principales que vous pourriez avoir à effectuer sont les suivantes :

  1. Mise à jour d’un paquetage Mageia existant
  2. Importer un nouveau paquetage dans Mageia

Dans les prochains paragraphes, il est considéré que :

  • vous travaillez sur des paquetages Cauldron-fr;
  • vous êtes en contact avec votre parrain pour obtenir de l’aide en cas de doute ;
  • vous gardez à portée de main toute la documentation dont vous aurez besoin, en particulier cette page et ce tutoriel.

Mettre à jour un paquetage

Vous souhaitez (ou votre parrain vous l’a demandé) actualiser un paquetage Mageia Cauldron. Cela peut être pour corriger un bogue ou une lacune, ou pour le mettre à jour vers une version plus récente.

A.1. Vérifier le paquetage 
mgarepo co foo
  • cela devrait créer un répertoire avec les sous-répertoires SOURCES et SPECS. Allez dans ce répertoire :
cd foo
A.2. Mettre à jour les SPECS 
  • Cela se fait à l’aide de votre éditeur de texte préféré. Par exemple :
emacs SPECS/foo.spec
  • Essayez de réduire au minimum vos changements. Cela facilite le travail de votre parrain et réduit de ce fait la quantité de points à revoir.
  • Regardez les autres SPECS des paquetages pour vous en inspirer. Sophie peut aider.
  • Toute modification d’un paquetage existant doit inclure une mise à jour du paramètre %mkrel. Si vous modifiez un paquetage (mais pas de nouvelle version), augmentez simplement de 1 ce paramètre dans le cadre de vos changements. Par exemple :
%define release %mkrel 2
  • Si vous travaillez pour fournir une nouvelle version, remettez %mkrel à 1.


A.3. Pour une nouvelle version
  • Dans le fichier spec, mettez à jour le champ version et le lien Source. Par exemple :
%define version 1.2.3
Source0 : http://www.program.org/download/foo-%{version}.tar.gz
  • Vous devez télécharger les nouvelles sources dans le sous-répertoire SOURCES. Il est conseillé de le faire avec wget et d’utiliser le champ SOURCES que vous venez de mettre à jour dans le fichier spec. Par exemple :
cd SOURCES ; wget http://www.program.org/download/foo-1.2.3.tar.gz; cd ..
A.4. reconstruire
  • Une fois que vous avez fait quelques modifications sur votre paquetage, vous devriez le construire. Ceci peut être fait avec la commande
bm -l
  • Cette commande construit en fait à la fois le src.rpm et un rpm spécifique à l’architecture. Il crée et alimente les sous-répertoires. BUILD, BUILROOT, RPMS, SRPMS.
  • Si vous ne voulez que le fichier src.rpm, utilisez :
bm -ls
  • Il y a maintenant deux possibilités, soit il réussit et vous passez à l’étape A.5, soit il échoue et vous devriez regarder le message d’erreur et la plupart du temps retourner à l’étape A.2.
    • Certaines erreurs seront évidentes à résoudre pour vous : paquetages installés manquants, fautes de frappe.
    • D’autres erreurs nécessiteront plus de travail, comme la rediffusion des correctifs. Dans ce cas, demandez à votre parrain.
A.5. Vérifier le src.rpm
  • rpmlint est un outil qui aide à maintenir un certain contrôle de la qualité des RPM. Exécutez toujours rpmlint sur le fichier src.rpm que vous avez généré. Par exemple :
rpmlint SRPMS/foo-1.2.3-1.src.rpm
  • rpmlint vous affichera des erreurs et des avertissements. Essayez de réduire leur nombre autant que possible.
    • Certains avertissements sont inévitables à ce stade, tels que « pas de signature » ou « no-changelogname-tag ».
    • Certaines mises en garde (par exemple le mélange des espaces et des tabulations) sont simples à corriger. Dans le doute, demandez à votre parrain.
  • rpmlint peut également être exécuté directement sur la spec. Les vérifications sont moins approfondies, mais elles peuvent être utiles comme première étape.
A.6 Tester l’installation
  • Installez le paquetage rpm que vous venez de créer. Par exemple (en tant que root) :
urpmi RPMS/x86_64/foo-1.2.3-2.mga6.x86_64.rpm
  • Vérifiez qu’il fonctionne :
    • Est-ce qu’il apparaît dans le menu ? Est-ce qu’il se lance correctement depuis la ligne de commande ? Exécute-t-il les tâches habituelles qu’il est censé faire ?
  • Vérifiez la désinstallation. Par exemple (toujours en tant que root) :
urpme foo-1.2.3-2.mga2.x86_64.rpm
    • Est-ce qu’il s’est désinstallé sans problème ?
A.7 Vérifier et envoyer le patch
  • Une fois que vous avez confiance dans le paquetage que vous venez de produire, jetez un coup d’oeil à vos changements en faisant (dans le répertoire des paquetages) :
git diff
  • Cela vous permet de vérifier si vos changements sont tous intentionnels et que les multiples itérations à travers A. 2-5 n’ont pas enrichi la spécification par de nombreux ajouts inutiles. Essayez de rendre cette différence aussi petite que possible (en revenant à l’étape A.2).
  • Une fois que vous êtes satisfait du paquetage et de la différence, vous pouvez l’envoyer à votre parrain. Un outil très utile est nopaste. Par exemple :
git diff > foo.spec.patch
nopaste foo.spec.patch
nopaste produit une URL que vous pouvez donner à votre parrain par courriel ou IRC. Ils l’examineront ensuite, l’appliqueront sur leur machine, vous demanderont de corriger les erreurs que vous avez faites, puis le confient à Mageia git.
A.8 Profitez du système de construction
  • Une fois que votre parrain a accepté le patch, vous pouvez suivre la construction du paquetage sur le système de construction. Aller à http://pkgsubmit.mageia.org.
    • S’il apparaît vert : victoire ! Après quelques minutes, la nouvelle version de votre paquetage apparaîtra sur les miroirs et sera utilisée par l’ensemble des utilisateurs de Mageia.
    • Si elle est rouge : ne vous inquiétez pas, vous n’avez rien cassé. Regardez les messages d’erreur et essayez de résoudre le problème avec votre parrain.

Importation d’un paquetage

Vous souhaitez (ou votre parrain vous l’a demandé) importer un nouveau paquet dans Mageia Cauldron. Veuillez suivre ces étapes :

B.0 Préalablement
  • Pour importer un nouveau paquet, vous devez créer un nouveau src.rpm que vous devez envoyer à votre parrain.
  • Pour cela, vous devez travailler dans le répertoire rpm que vous avez créé.
    • Rappel (pour créer ces répertoires):
mkdir -p ~/rpm/{BUILD,BUILDROOT,RPMS/{$ARCH,noarch},SOURCES,SRPMS,SPECS,tmp}
où $ARCH représente le ou les archictures: i586 / x86_64
    • Vous pouvez commencer par supprimer tous les travaux précédents qui se trouvaient dans les sous-répertoires du rpm.
B.1 Il existe un src.rpm d'une autre distribution.
  • Cette situation est plus facile à gérer, car vous avez pu vous familiariser avec les différentes étapes du tutoriel.
  • Décompressez le src.rpm
rpm -Uvh path/to/the/file/foo-1.2.3-1.mdvsrc.rpm
Aller directement à B.3.
B.2 Le paquet ne figure dans aucune autre distribution basée sur le format RPM
  • En êtes-vous vraiment certain ? Il peut être sous un autre nom …
  • Allez dans le répertoire rpm et mettez le fichier source dans le sous-répertoire SOURCES.
cd SOURCES ; wget http://www.program.org/download/foo-1.2.3.tar.gz; cd ..
  • Créez un fichier spec :
emacs SPECS/foo.spec
  • Créez un fichier spec à partir de zéro n’est pas chose facile, alors inspirez-vous des fichiers de spec de paquets similaires.
  • Vous pouvez aussi utiliser la commande « rpmdev-newspec foo.spec » pour obtenir une base de construction pour votre nouveau paquet.
B.3 Effectuer les étapes comme pour une mise à jour
  • Suivez les étapes A.2 à A.6 de la section précédente.
B.4 Envoyer le src.rpm à votre parrain.
  • Une fois que vous êtes satisfait du résultat, vous devez envoyer le fichier src.rpm que vous avez produit à votre parrain.
  • Essayez d’utiliser un dépôt en ligne (comme une page personnelle) au lieu de l’envoyer par courriel.
  • Une fois que votre parrain l’aura reçu, il vous donnera son avis et vous demandera éventuellement de revenir à l’étape B.2.
    • Lorsque votre parrain sera satisfait, il importera le paquet dans Mageia et vous pourrez accéder à la version git par :
mgarepo co foo

Bilan de l’apprentissage

Les étapes A.1 à A.8 et B.1 à B.3 doivent être suivies tout au long de votre formation. Les empaqueteurs expérimentés les utilisent aussi !

Lorsque votre parrain décide que vous pourriez commiter, passez à la section suivante.

Les procédures resteront essentiellement les mêmes ; seules les étapes A.7 et B.3 seront sensiblement différentes.

Déroulement du travail du Confirmé

Vous êtes maintenant un confirmé, bien joué ! Avant d’aller plus loin, vous devez adapter votre configuration à la nouvelle situation.

Obtenir la mise à jour de votre compte pour commiter

Quand votre parrain pense que vous devriez commiter, il ouvre une demande de bug sur bugzilla, dans la partie « Infrastructure -> Account request » component. Le bug devrait mentionner :

  • the apprentice login on identity (la connexion de l’apprenti concernant son identité)
  • qu’il s’agit d’un compte d’apprenti empaqueteur (car il existe d’autres types de comptes qui peuvent être demandés)

Préparatifs

ssh
  • Une fois que votre compte a été mis à jour, vous devriez pouvoir télécharger votre clé ssh pour l’identité, en suivant les instructions à l’adresse Empaqueteur ssh. Une fois que c’est fait, vous devriez pouvoir accéder au git en utilisant votre compte.
mgarepo
  • Pour utiliser mgarepo avec votre identité, vous devez changer le fichier de configuration de mgarepo. Changer :
repository = git://git.mageia.org/git/packages/
binaries-repository = git://git.mageia.org/git/binrepos
vers
repository = git+ssh://git.mageia.org/git/packages/
binaries-repository = git+ssh://git.mageia.org/git/binrepos
Remarque :
Tout contrôle git que vous avez fait précédemment (avec une identité anonyme) ne vous permettra pas de commiter (car la connexion anonyme est mémorisée par git). Vous devez refaire de nouvelles vérifications.

Mettre à jour un paquetage

Vous devriez fondamentalement suivre les mêmes étapes qu’auparavant : A.1 à A.6

A.3' Pour une nouvelle version
  • La procédure change ici par rapport à la méthode précédente : une fois que vous avez configuré la nouvelle version et actualisé l’URL Source0, vous pouvez simplement ajouter la nouvelle source au dépôt en utilisant mgarepo. Plus besoin de wget. Faites-le, c’est tout :
mgarepo sync -d
et le nouveau fichier source sera téléchargé à partir de l’URL et vérifié dans le git.
A.7' Vérifier et valider le patch
  • Comme précédemment, une fois que vous avez confiance dans le paquet que vous venez de produire, jetez un coup d’œil à vos changements en faisant (dans le répertoire du paquet):
git diff
  • Suivre la même approche décrite au point A.7.
  • Une fois que vous êtes satisfait du paquet et de la différence, vous pouvez le valider :
mgarepo ci -m 'my commit message'
  • Les messages de validation sont importants car c’est le moyen de transmettre aux autres paquets les changements que vous venez d’apporter.
  • Si vous n’avez fait qu’une seule modification (par exemple, mise à jour vers la nouvelle version 1.2.3), un message de confirmation sur une ligne est suffisant :
mgarepo ci -m 'mise à jour vers la nouvelle version 1.2.3'
  • Si vous avez fait plusieurs changements sans rapport, écrivez-les sur plusieurs lignes précédées d’un tiret. La commande :
mgarepo ci

Ouvrira un éditeur (celui spécifié par votre variable d’environnement EDITOR). Là, vous pouvez écrire le message de validation que vous voulez. Par exemple : – mise à jour vers la nouvelle version 1.2.3 – ajout de BuildRequires pour python-devel – clean spec – Correction d’un problème d’icône manquante

  • N’hésitez pas à demander à votre parrain et consultez les messages de validation précédents pour vous encourager :
mgarepo log foo
donne l’historique des messages de validation pour les paquets foo.
A.8' Soumettre une demande
  • Après la validation, contactez votre parrain pour qu’il examine vos changements et soumette le paquetage.


Importation d’un paquetage

Vous devriez fondamentalement suivre les mêmes étapes qu’auparavant : B.0 à B.3. Ensuite, au lieu de B.4, utilisez B.5'.

B.5' Importation d’un paquetage
  • L’importation d’un paquet peut se faire une fois qu’un fichier src.rpm a été produit. Alors utilisez :
mgarepo import foo-1.2.3-1.src.rpm
  • Une fois importé, vous pouvez demander à votre parrain de l’examiner et de soumettre le paquetage.

Validation des acquis

Lorsque votre parrain estime que vous êtes prêt, il peut décider de vous promouvoir comme empaqueteur. Les restrictions d’accès au système de construction seront levées. Les procédures que vous devrez suivre resteront cependant les mêmes, sauf que vous pourrez soumettre les paquets vous-même.

Notez qu’être apprenti ne consiste pas seulement à apprendre à utiliser les différents outils mentionnés sur cette page. Cela comprend également :

  • de connaître les dépendances des paquets et la maintenance des bibliothèques
  • de savoir corriger des bogues
  • de connaître la gestion des correctifs

Et même après avoir été promu en tant qu’emballeur,

vous aurez encore beaucoup à apprendre…

Quelques conseils :

  • Regardez les liens suggérés au bas de cette page, notamment Mgarepo
  • Restez en contact avec les utilisateurs, les autres empaqueteurs et votre parrain.
  • Prendre en charge la maintenance des paquets
  • Bonne chance !

Suggestions de travail pour les Apprentis

Votre parrain ne vous proposera pas toujours des tâches : les apprentis doivent prendre l’initiative. Attention cependant, certains paquets peuvent déjà être pris en charge par d’autres personnes, et certaines mises à jour peuvent casser des choses. Il est préférable de parler à votre parrain des changements que vous envisagez d’apporter. Il vous dirigera vers la bonne personne à demander, sur le canal IRC #mageia-dev ou sur la liste de diffusion.

Quelques suggestions en priorité décroissante:

  1. Avant d’ajouter de nouveaux paquets à Mageia, commencez par corriger les bogues pour les paquets existants ou aider à prendre en charge la maintenance des paquets actuellement non maintenus.
    Consulter la liste actuelle des paquets non maintenus unmaintained et bien en vue en haut de la page d’accueil de notre page de présentation du système de construction
  2. aider l’équipe d’assurance qualité à valider les corrections de bogues et les mises à jour de sécurité, veuillez consulter Current Update candidates et Processus QA pour valider les mises à jour
  3. Bugzilla est le principal outil à consulter lorsque vous voulez contribuer, mais que vous n’avez pas de cible précise.
    Cherchez en particulier (mais ne vous limitez pas à ça) les marqueurs Junior_Jobs for existing packages (Tâches mineures pour les paquets existants) ou Correctifs pour les paquets existants (ou Junior_Jobs (Tâches mineures) ou le mot-clé PATCH (également si le champ assigné n’est pas le bugsquad).
    Voir all saved-searches pour des recherches plus efficaces dans bugzilla
  4. supprimer les catégories X-MandrivaLinux et X-Mageia de tous les fichiers.desktop, comme indiqué dans la section https://bugs.mageia.org/show_bug.cgi?id=2449#c11 (voir aussi quelques commentaires ci-dessus)
  5. supprimer « This package is in PLF because… » de tous les paquets où il est présent ou adapter le libellé pour dire « This package is in tainted/nonfree because… »
  6. http://check.mageia.org fournit plusieurs informations sur la qualité de la distribution actuelle. Si certaines dépendances sont brisées, certains paquets manquent ou ne sont pas à jour, vous pouvez y jeter un coup d’œil.
  7. Prendre en charge la maintenance d’un programme que vous utilisez souvent et, selon la situation, l’importer, le mettre à jour et corriger ses problèmes (exemple de query (demande)). Regardez notamment son statut en amont et sa situation dans d’autres distributions.
  8. New package requests (Nouveau paquetage demandé) dans Bugzilla

Voir également

Toutes les pages de la catégorie Empaqueteur sur le wiki sont pertinentes, notamment :

Un grand nombre de liens externes sont disponibles à l’adresse suivante Packagers linkpage.

Retour sur la page « Équipe Packageurs »