Charles-Antoine Couret: Du test de Fedora à une contribution pour Yocto / OpenEmbedded

Comme vous le savez certainement, je suis un amateur de Fedora depuis
longtemps (merci papa), je prépare des dépêches de sortie depuis Fedora 9, et
je teste les versions instables sur ma machine principale depuis Fedora 15.
Cela est un moyen efficace de trouver des bogues pour les corriger avant la
sortie finale (et ainsi améliorer la qualité pour tout le monde). La rédaction
des dépêches permettant de voir l’ensemble des changements opérés à chaque fois
en avance.

À l’occasion de la sortie de Fedora 28 Bêta, j’ai voulu préparer le terrain
pour ma machine professionnelle pour m’assurer que mon travail serait possible
dans cet environnement sans perdre de temps. Si globalement le système tourne
bien, restait à s’assurer que mon travail compilerait toujours. Avec des
changements de versions pour GLibc et GCC, rien n’est garanti.

Contexte

Pour le compte de mon
employeur,
le client actuel il y a deux Yocto utilisés (un par projet).
L’un est un Yocto Pyro fourni par Toradex pour une plateforme iMX7D, l’autre un Yocto Rocko fourni par
Variscite pour une plateforme iMX6. Comme ce sont des versions
récentes, la probabilité que le comportement diverge est faible (et en réalité,
ce sera le cas, seule un correctif supplémentaire sera nécessaire pour le Yocto
Pyro).

Yocto est un système de génération de distribution. Grâce à un système de
recettes et de couches, nous pouvons intégrer des logiciels provenant de
différentes sources, les configurer et les assembler pour générer différentes
images et des paquets. Pour cela, comme pour tout système similaire (comme
buildroot), Yocto récupère les sources des compilateurs, des bibliothèques de
base, etc. Il compile une chaîne de compilation croisée ce qui permet
d’exécuter par exemple un compilateur comme GCC sur mon ordinateur de travail
(d’architecture x86_64 Intel) mais dont le résultat sera exploitable sur la
carte cible donc des processeurs ARM dans mon cas. Ensuite cette chaîne de
compilation servira à générer l’ensemble des paquets et l’image finale pour la
carte électronique du projet.

Pour la génération de la chaîne de compilation croisée, Yocto a besoin
d’utiliser des outils déjà présents dans ma machine. Typiquement le compilateur
GCC de mon architecture. C’est pour cette étape que changer de version de
Fedora peut être risqué. Car si GCC change, le comportement pour générer la
chaîne de compilation croisée aussi. Exemple : quand GCC active par défaut
l’usage de CPP 14 certains programmes ne sont plus compilables en l’état car
ils ne respectent pas cette nouvelle version du langage et il faut dans ce cas
préciser à GCC de ne pas utiliser le comportement par défaut, ou rendre le
programme compilé compatible CPP 14.

Et le soucis avec Fedora 28 ?

Pour minimiser les différences entre les distributions (Ubuntu, Fedora,
Debian, etc.), Yocto a introduit par défaut un paquet yocto-uninative
qui est un glibc-native précompilé pour la machine hôte (ici mon Fedora
x86_64). Cela autorise par exemple à deux distributions de partager le cache de
Yocto et que la compilation aboutisse malgré des glibc qui diffèrent. Cela
n’est possible que parce que Glibc est globalement rétrocompatible dans les
symboles.

Mais avec Fedora 28, le paquet yocto-uninative de Yocto ne
fonctionne plus. Il faut compiler glibc-native à la main. Si cela ne constitue
pas un frein pour travailler mais c’est une régression importante qu’il
convient de corriger avant la sortie officielle de Fedora 28. D’autant que
Yocto prépare la sortie de sa nouvelle version sumo et être compatible
avec Fedora 28 est un gros plus.

Le problème survient lors de la compilation de bibliothèques Perl, qui se
plaignent que le symbole XCRYPT_2.0 de la bibliothèque
libcrypt n’existe pas. Et en effet, dans le glibc fournit par
yocto-uninative, ce symbole n’existe pas alors qu’il existe dans la
version de mon système. En somme, il y a une incompatibilité entre les deux en
terme de symboles alors qu’il est nécessaire que cela corresponde pour
continuer.

Je regarde dans les changements de Fedora 28 pour comprendre et je retombe
sur cette page. Des développeurs de Fedora ont proposé de
séparer glibc et libcrypt. Le but est de permettre de faire évoluer ce
dernier plus facilement et rapidement. libcrypt serait fournie par le biais du
programme libxcrypt. Mais l’équipe de glibc n’a pas encore intégré ce
changement, Fedora est ainsi la seule distribution à avoir ce comportement par
défaut.

Et c’est là d’où vienne les ennuis, si libxcrypt est rétro-compatible avec
l’ancien libcrypt (il fournit les symboles que libcrypt fournissaient),
l’inverse n’est pas vrai et on le voit par l’ajout du symbole
XCRYPT_2.0.

Travail en amont

Pour corriger cela, il faut agir au niveau de Yocto. Je rejoins donc le
canal IRC de #yocto sur Freenode pour expliquer le problème et qu’on élabore
une marche à suivre. C’est ainsi que Joshua Watt de Garmin et Richard Purdie
d’Intel, deux contributeurs de Yocto ont souhaité m’aider à résoudre ce
problème.

Étape 1, générer un yocto-uninative depuis Fedora 28 et l’utiliser
localement pour vérifier si cela résout mon soucis. Il faut donc créer la
recette pour compiler libxcrypt, puis modifier celui de glibc pour ne pas
compiler et de ne pas utiliser son libcrypt interne quand on souhaite générer
un SDK. Je dois également corriger Perl (via un correctif déjà
existant dans le paquet RPM de Fedora) pour utiliser libxcrypt convenablement
avec.

Cela fonctionne bien. Du coup étape 2, j’envoie aux deux développeurs mon
yocto-uninative pour qu’ils le testent de leur côté que la
compatibilité est bonne sur Ubuntu ou Fedora 27. Cela fonctionne bien
aussi.

Étape 3, nettoyer mon travail et l’envoyer en amont pour que tout le monde
en bénéficie. Et les prochains yocto-uninative seront compatibles avec
Fedora 28. Richard Purdie ira plus loin dans l’utilisation de libxcrypt en
utilisant le concept de virtual/crypt. Sachant que ce travail devrait
finir par disparaître quand Glibc officiel intégrera le changement de Fedora,
normalement cette année.

Et quelques jours plus tard, le travail est publié ici et .

Conclusion

Tout d’abord que le Logiciel Libre est un travail d’équipe, vraiment. Grâce
à Joshua et Richard j’ai gagné du temps en recherche d’info, de solution et
dans la réalisation des tests. Leur aide a été précieuse. Et eux ont pu
bénéficier un retour de Yocto sur Fedora 28 avant sa sortie, permettant de
corriger des soucis avant qu’une horde d’utilisateurs ne viennent se
plaindre que cela ne fonctionne pas. Et bien entendu les futurs utilisateurs de
Fedora 28 et de Yocto pourront se contenter d’utiliser Yocto sans soucis et
sans rien faire.

Ensuite, les tests c’est important. En testant les Fedora instables, on
découvre des soucis et on peut les résoudre avant que l’utilisateur lambda ne
s’en serve. Cela améliore grandement le confort d’utiliser la distribution. Et
comme ce changement sera dans glibc officiel, cela permet de préparer le reste
du Logiciel Libre à l’arrivée de ce genre de changements majeurs sous le
capot.

Pour finir, tester Fedora et écrire les dépêches de sortie me permettent
d’être à l’aise avec la distribution au fil du temps. J’ai pu identifier et
corriger le soucis plus vite que si je ne maîtrisais pas mon système, car je
sais où chercher l’information


Source From: fedoraplanet.org.
Original article title: Charles-Antoine Couret: Du test de Fedora à une contribution pour Yocto / OpenEmbedded.
This full article can be read at: Charles-Antoine Couret: Du test de Fedora à une contribution pour Yocto / OpenEmbedded.

Advertisement
directory-software-online-bussiness-script


Random Article You May Like

Leave a Reply

Your email address will not be published. Required fields are marked *

*
*