Introduction

Nous avons vu dans un précédent article comment facilement ajouter un paquetage à buildroot. Ce n'est pas bien compliqué mais, maintenant que vous avez créé ce nouveau paquetage, il est souhaitable de contribuer à la communauté Buildroot et de participer à l'effort commun.

Buildroot étant un projet animé par des volontaires, participer à l'effort commun en partageant vos modifications fait partie du savoir vivre normal dans le monde du logiciel libre. Ce n'est pourtant pas la seule raison de le faire.

• Maintenir des modifications locales est un processus compliqué, long et source d'erreurs. C'est également une tâche de fond qu'il faut recommencer régulièrement pour suivre les évolutions de Buildroot. Plus on attend, plus c'est difficile. Toute modification logicielle doit être maintenue et tout ce que vous ne contribuez pas doit donc être maintenu par vos soins.
• Les contributions à Buildroot sont relues et critiquées par les auteurs de Buildroot, donc par les meilleurs experts du domaine. Leurs critiques sont sans doute la meilleure façon d'apprendre et c'est un gage de qualité pour vos modifications.
• En participant activement à la communauté vous serez considéré comme une personne utile en non pas juste un utilisateur. Le jour où vos aurez des problèmes plus compliqués avec Buildroot ou que vous souhaiterez intégrer des modifications plus complexes, la communauté sera plus réceptive à vos problèmes.

Prendre contact avec la communauté.

Avant toute chose il est recommandé de prendre contact avec la communauté Buildroot. Le développement de Buildroot a principalement lieu sur la mailing-list ( ici ). Il va donc falloir s'y abonner. Cette mailing-list est très active ( une cinquantaine de mails par jour ) et très sympathique. Le niveau d'anglais y est raisonnable car la plupart des contributeurs de Buildroot ne viennent pas de pays anglophones. Si vous avez fait de l'anglais au lycée vous devriez être à votre aise et quelques jours à lire les mails devraient vous donner une idée de l'ambiance amicale de cette communauté.

Il est également intéressant de se connecter sur le canal IRC de buildroot ( #buildroot sur freenode ). Si vous avez des questions précises il peut être plus rapide de passer par IRC que par la mailing list.

Vérifier vos modifications.

Avant toute chose nous allons revoir les modifications que vous avez apportées à Buildroot pour ajouter votre paquetage. Il s'agit ici d'éviter d'avoir trop de problèmes à corriger lorsque votre patch sera revu sur la mailing-list Buildroot. Un peu de temps passé à se relire vous fera gagner beaucoup de temps, ainsi qu'à vos relecteurs.

• Vérifiez l'indentation dans votre fichier Config.in. L'indentation doit être d'une tabulation pour les lignes normales, et d'un tabulation et deux espaces pour la section d'aide.
• La section d'aide doit décrire le programme, suivi d'une ligne blanche puis de l'URL du projet que vous intégrez.
• votre fichier .mk positionne différentes variables. Vérifiez que vous ne positionnez pas de variables à leur valeur par défaut. C'est inutile et cela complique la lisibilité.
• vérifiez que vous avez positionné correctement la variable <paquetage>_LICENSE La liste des valeurs standards se trouve ici.
• de même, remplissez le champs <paquetage>_LICENSE_FILE, il s'agit généralement d'un lien vers le fichier COPYING de votre paquetage
• Vérifiez vos dépendances. En particulier l'utilisation des mots clés depends et select dans votre Config.in. La différence entre ces deux mots clé est expliquée ici. Si vous utilisez select pour sélectionner un paquetage, vérifiez également que vous avez bien un depends pour chaque depends du paquet en question.
• Si vous avez des depends, pensez à ajouter un commentaire à afficher quand la dépendance n'est pas satisfaite, comme dans l'exemple ici
• Vérifiez que votre paquet est correctement placé dans la liste des paquets de package/Config.in. Êtes vous dans la bonne section ? Avez vous respecté l'ordre alphabétique ?
• Si votre paquetage utilise l'appel système fork pensez à mettre un depends sur BR2_USE_MMU.
• Vérifiez qu'il y a bien une ligne blanche entre les entêtes et les variables de votre fichier .mk
• Si votre paquetage peut être téléchargé dans différents formats, privilégiez le plus compressé  ( .xz pusi .bz puis .gz)
• Vérifiez que vous n'avez pas d'espaces en fin de lignes dans vos différents fichiers
• Harmonisez le nom de votre paquetage. Faites attention de le capitaliser de la même façon partout (et de préférence tout en minuscules)
• Enfin, vérifiez que toutes vos dépendances sont également positionnées dans le fichier .mk. Buildroot utilise cette information pour décider dans quel ordre compiler les paquetages.
• Vérifiez que votre projet fonctionne également avec uClibc, vérifiez si il a besoin de MMU et de threading. Si c'est le cas, mettez les dépendances correspondantes dans le Config.in

Commiter votre contribution localement.

Je ne reviendrai pas en détail sur l'ajout du paquetage lui même qui a été détaillé dans un autre article. Ici nous allons plutôt étudier comment préparer votre paquetage pour pouvoir l'envoyer à la communauté Buildroot.

Normalement toutes vos modifications ont étés sauvegardées proprement dans git et dans une branche portant le nom de votre paquetage... non ? pas de panique il est toujours temps de rattraper le coup..

D'abord, nous allons créer une branche git nommée d'après votre paquetage

git checkout -b <nom du paquetage>

Ensuite, nous allons ajouter vos modifications à git

git add -u # mise à jour des fichiers déjà gérés par git
git add <liste des nouveaux fichiers> # ajout des fichiers de votre paquetage
git status # pour vérifier que tout est bien en place

La dernière ligne nous permet de vérifier que tout se passe bien. Sa sortie ressemble à l'exemple ci-dessous

# On branch uncompressed_linux
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
#	modified:   Config.in
#
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#	modified:   package/Config.in

Nous pouvons vérifier :

• Que nous sommes sur la bonne branche
• Que tous les fichiers à envoyer sont bien dans la section "changes to be commited"
• Que les fichiers dans la section "changes not staged for commit" ne sont pas à envoyer

Une fois ces petites vérifications faites, il est temps de commiter nos modifications

git commit -s

Cette commande ouvrira un éditeur de texte qui vous permettra de saisir votre message de commit. Vous pourrez également vérifier la liste des fichiers qui seront commités.

Votre message de commit devrait ressembler à l'exemple ci-dessous :

<mon paquetage>: new package

 Signed-off-by: Jérémy Rosen <jeremy.rosen@openwide.fr>
---
v0: initial commit
 <mon paquetage> is an awesome package that does everything you need

Ici, il y a quelques conventions particulières à respecter

• La première ligne du commit suit un format précis.
• une ligne blanche
• la ligne de signature (qui est rempli automatiquement par git grâce à l'option -s, mais que vous pouvez corriger)
• une ligne avec trois tirets
• Tout ce qui suit le tiret ne sera pas pris en compte lorsque les mainteneurs buildroot intégrerons vos modifications. Vous pouvez donc y saisir des informations secondaires comme une petite description du paquetage ou un message pour la mailing list

Et voila, nos modifications ont étés commitées localement. L'étape suivante consiste à récupérer la dernière version de buildroot et à mettre à jour nos modifications.

Tout d'abord il faut récupérer les dernières modifications venant du projet

git fetch origin

ensuite nous devons actualiser nos modifications pour être à jour par rapport à la dernière version de buildroot

git branch
#vérifiez que vous êtes bien dans la branche de votre paquetage
git rebase origin/master

Si tout se passe bien, votre commit est prêt à être envoyé.

Si git rebase vous signale des conflits à corriger, la liste des fichiers en conflit peut être obtenue par la commande git status

Éditez les fichiers en conflit en cherchant les marqueurs (<<< puis === puis >>> suivant les conventions de la plupart des outils de gestion de configuration) et corrigez les différents problèmes. Testez à nouveau votre paquetage jusqu'à ce que tout fonctione puis, une fois les conflits résolu, utilisez la commande suivant pour signaler à git que les fichiers ne sont plus en conflit

git add <fichier en conflit>

une fois tous les conflits résolus, utilisez la commande suivante pour poursuivre le merge

git rebase --continue

Si vous êtes perdu et que vous voulez recommencer à zéro il suffit d'utiliser la commande suivante pour annuler toute l'opération

git rebase --abort

après ces petites manipulations, votre contribution est prête à être envoyée.

git format-patch -M -n -s -o outgoing origin/master

git send-email [options] --to buildroot@busybox.net outgoing/*

git add -u # mise à jour des fichiers à commiter
git commit --amend # modification du dernier commit

v1: added suggestions by <personne ayant soumis les critiques>

Tested-by: <quelqu'un d'important>

Acked-by: <quelqu'un d'important>