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 là.

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

Original post of Renault.Votez pour ce billet sur Planet Libre.

Qui dit nouvelle version d'OpenBSD dit nouvelle version d'isotop.
Pour les bavards du fond, isotop est une OpenBSD "simplifiée" qui permet d'avoir rapidement un environnement de travail sur un pc de bureau pour découvrir ce système. Autant que possible, les outils de base dans OpenBSD sont utilisés, et sont accompagnés par quelques scripts qui se veulent aussi légers que possible. Une série de programmes courants sont présents, comme par exemple la suite bureautique libreoffice ou encore le navigateur Firefox.
L'objectif d'isotop n'est pas d'être la plus rapide ni proposer les programmes les plus récents. Je souhaite faciliter l'accès à ce système réputé robuste et sûr, ce qui n'est pas une mince affaire de nos jours.

Pour récupérer la dernière version, vous pouvez lire la page de téléchargement ou bien la suite :

Cliquez sur un des magnets suivants :

• isotop-0.3.2-amd64-full.fs.gz
• isotop-0.3.2-amd64-full.iso.gz
• isotop-0.3.2-amd64-netinst.fs.gz
• isotop-0.3.2-amd64-netinst.iso.gz
• isotop-0.3.2-i386-full.fs.gz
• isotop-0.3.2-i386-full.iso.gz
• isotop-0.3.2-i386-netinst.fs.gz
• isotop-0.3.2-i386-netinst.iso.gz

Ou alors, les copains hébergent les isos sur leurs serveurs :

• isotop chez moutonlibre.net
• isotop chez arpinux
• isotop chez PengouinBSD
• isotop chez obsd4a.net

Outre les améliorations déjà présentes dans OpenBSD 6.3, on pourra entre autres noter les points suivants dans isotop :

• Xenodm, le gestionnaire de connexion est plus joli.
• Un outil pour configurer Xenodm est disponible. Il permet de changer le fond d'écran, en définir plusieurs aléatoirements ou bien configurer une connexion automatique pour un utilisateur (⚠️)
• Une interface simple pour qu'un utilisateur puisse accéder à des privilèges root est intégrée. Ça évite de configurer doas pour chaque application nécessitant ces droits. On peut voir ça comme un "gksu" simplifié, qui ne retire rien à doas.
• La possibilité de traduire l'interface est présente. Pour l'instant, c'est le français et l'anglais seulement, selon l'agencement du clavier définit à l'installation.
• Les médias insérés sont automatiquement montés dans /vol. Un raccourci dans le dossier utilisateur est présent pour y faciliter l'accès.
• Un peu moins de programmes sont présents par défaut, ça allège les images.
• L'apparence est plus sobre, libre à chacun de personnaliser le thème à son goût.
• Si un utilisateur décide d'envoyer aux développeurs d'OpenBSD son "dmesg" (ça aide à améliorer le support matériel), un message de confirmation lui est affiché.
• Unbound est toujours présent pour se charger des résolutions DNS en local, le FAI n'a pas à savoir ces choses-là.
• Ffom est intégré pour trouver un miroir rapide.
• De nouveaux fonds d'écran (merci péhä!)

J'aurais souhaité proposer une installation automatisée. À vrai dire, ce n'est pas si compliqué à mettre en place. J'ai toutefois dû revoir ma copie, puisque cela imposait des choix par défaut à l'utilisateur qui peuvent s'avérer aussi perturbants voire plus que l'installateur normal. Normalement, tout le monde est capable de lire les quelques instructions pour l'installation, à savoir :

• Laisser au moins de 4G pour les programmes installés avec isotop (je compte large) ;
• Bien installer le set site63.tgz lors de l'installation.

Par ailleurs, c'est Firefox ESR 52 qui est installé par défaut, simplement pour assurer un support convenable dans le temps au cas où on installerait isotop dans 3 mois. Rien ne vous empêche d'installer la version 59 avec pkg_add.

Bref, j'espère que ça vous donnera envie de découvrir OpenBSD et que les petits ajouts vous feront plaisir :)

Original post of Thuban.Votez pour ce billet sur Planet Libre.

Aujourd'hui, ce mercredi 11 avril, est une journée dédiée à un test précis : sur l'image Atomic / Cloud de Fedora. En effet, durant le cycle de développement, l'équipe d'assurance qualité dédie quelques journées autours de certains composants ou nouveautés afin de remonter un maximum de problèmes sur le sujet.

Elle fournit en plus une liste de tests précis à effectuer. Il vous suffit de les suivre, comparer votre résultat au résultat attendu et le notifier.

En quoi consiste ce test ?

La version Cloud de Fedora est un des trois produits officiels du projet avec Workstation et Server. Son but est d'être une image très minimale pour être instanciée de nombreuses fois dans le cadre d'un infrastructure Cloud afin de remplir le rôle d'un service. Cependant, contrairement aux deux autres produits, la version Cloud est mise à jour très régulièrement (de nouvelles images sont disponibles toutes les quelques semaines seulement, contre 6-7 mois en moyenne pour les autres).

Une nouveauté qui commence à s'installer est la mise à disposition de Fedora Workstation Atomic. Jusque là, seule l'image Cloud bénéficiait de ce système. Ce travail provient du projet Atomic qui repose lui même sur rpm-ostree dont l'un des buts est de versionner le système pour améliorer la fiabilité du système en cas d'installation ou de mise à jour d'un programme en autorisant un retour en arrière très simplement et avec des opérations qui sont atomiques (d'où le nom). Il est également aisé de voir ce qui a changé dans le système, notamment si l'utilisateur a changé des fichiers de configuration importants et ce qu'il a appliqué. Le système est également plus orienté utilisation d'applications dans un conteneur (comme les Flatpak) et les répertoires systèmes sont mieux isolés, par exemple /usr est par défaut en lecture seule.

Les tests du jour couvrent :

• Est-ce que l'image démarre correctement, permet de se connecter et si les services se base se lancent bien et que SELinux remplit son rôle ;
• Vérifier si la gestion de Docker ou Atomic (installation, mise à jour, retour en arrière) fonctionne correctement ;
• Lancement des applications ;
• Vérifier la compatibilité avec le cloud Amazon et OpenStack ;
• S'assurer que l'image Atomic Workstation fonctionne avec ses spécificités : installation du système, Flatpak et GNOME Logiciels pour les notifications et installer des programmes.

Si vous êtes intéressés par l'aspect Cloud de cette image ou par l'ajout d'Atomic dans Fedora Workstation, je vous invite à les tester, elles bénéficient en effet de relativement peu de retours pour le moment. La moindre aide est appréciée, merci.

Comment y participer ?

Vous pouvez vous rendre sur la page des tests pour lister les tests disponibles et rapporter vos résultats. La page wiki récapitule les modalités de la journée.

Si vous avez besoin d'aide lors du déroulement des tests, n'hésitez pas de faire un tour sur IRC pour recevoir un coup de main sur les canaux #fedora-test-days et #fedora-fr (respectivement en anglais et en français) sur le serveur Freenode.

En cas de bogue, il est nécessaire de le rapporter sur le BugZilla. Si vous ne savez pas faire, n'hésitez pas à consulter la documentation correspondante.

De plus, si une journée est dédiée à ces tests, il reste possible de les effectuer quelques jours plus tard sans problème ! Les résultats seront globalement d'actualité.

Original post of Renault.Votez pour ce billet sur Planet Libre.

Depuis quelques jours, je teste Apache Camel pour la mise en œuvre  de médiations.

Apache Camel est un framework assez ancien. Il est similaire à Spring Intégration et permet l’ implémentation de patterns d’intégration.

Les patterns d’intégration

Qu’est-ce qu’un pattern d’intégration allez-vous me dire ? C’est une solution d’architecture ou plus simplement une recette de cuisine permettant d’avoir une solution toute prête à une problématique d’intégration donnée. L’ensemble de ces patterns est décrit sur ce site ( ne vous attardez pas sur le look des années 90 … ).

Exemple :

 

Camel permet simplement de gérer l’intégration via un DSL.

Choix d’implémentations

On peut faire pas mal de choses avec ce FRAMEWORK et de plusieurs manières. J’ai fait les choix d’implémentation suivants :

• Tout se fera avec SPRING … et pas en XML
• Il faut que toutes les médiations soient testables
• J’exécute le code dans un FATJAR ( pourquoi avec springboot )

Configuration de la route

Apache Camel définit les médiations dans des routes. Elles se définissent assez rapidement .

Les routes commencent par une instruction from et se terminent par une ou plusieurs instructions to.

Pour mon exemple, j’extrais les données d’une table et les stocke dans un fichier.

Tout se configure par des URLs. La première permet d’extraire les données via JPA/HIBERNATE. Une entité Address permet le requêtage. La seconde permet le stockage dans un fichier texte JSON.

Elles sont externalisées dans des fichiers de configuration pour faciliter les tests et accessibles via SPRING.

Lancement de la route

Le lancement de la route se fait dans une méthode main() :

Tests

Camel fournit une API de test assez bien fournie. Elle permet notamment de mocker des endpoints existants (ex. : le fichier de sortie de mon cas de test).

Dans mon cas, j’ai décidé de remplacer la base de données que j’interroge en input par une base HSQLDB chargée en mémoire. Le fichier de sortie est, lui, remplacé dynamiquement par un mock. Pour ce faire, j’ai utilisé les « adviceWith »

Pour aller plus loin

Il y a pas mal d’exemples sur le GITHUB de CAMEL. Vous pouvez également acheter le livre « Camel In Action ». Ca ne vaut pas Effective Java , mais vu qu’il est écrit par le principal développeur, c’est une très bonne référence.

 

 

Original post of Littlewing.Votez pour ce billet sur Planet Libre.

Je fais de la veille depuis un moment mais je me suis fait la réflexion il y a seulement un mois que je devais suivre les mises à jour des logiciels/outils que j’utilise. Quelques raisons à cela :

• Suivre l’actualité, surveiller le développement et les nouveautés des logiciels/outils qu’on utilise est sage et fort utile
• Pour un sysadmin/architecte/dev, ça permet d’avoir une bonne visibilité des dernières solutions/features dans le domaine et de garder un œil sur les bugs résolus
• Intéressant de voir ce « panaché » de différents projets, comment ils travaillent (cycle de dev, release notes, communication, outils utilisés…), comment ça évolue
• Mieux comprendre mes outils, leur fonctionnement, leurs limites et bugs. J’aime beaucoup lire les news Coreutils notamment
• Accessoirement ça peut aider à la prise de décision pour choisir un logiciel. En environnement professionnel un projet avec des commits fréquents, une communauté active peut faire la différence par exemple

RSS comme d’hab

J’ai voulu réutiliser l’outil principal me servant pour ma veille, le lecteur RSS. J’utilise FreshRSS (le meilleur !), il propose les avantages suivants :

• Il permet de créer une catégorie où on rangera spécifiquement certains flux RSS, j’ai créé la catégorie Releases
• Il permet lors de l’ajout du flux RSS de spécifier où envoyer le flux RSS (dans quelle catégorie), si on veut l’afficher dans le flux principal ou seulement dans une catégorie précise (Visibilité > Afficher dans sa catégorie) et de choisir la période de rafraîchissement (Ne pas automatiquement rafraîchir plus souvent que 12h pour ma part)
• Lorsqu’on veut ajouter un flux RSS, il va chercher le flux sur le site. Et c’est très utile vu que la plupart des projets se foutent complètement d’indiquer l’adresse du flux RSS. Par exemple je lui donne https://secure.php.net/releases/, il me propose comme flux RSS https://secure.php.net/releases/feed.php

Bazar comme d’hab

J’ai commencé à lister tous les outils que je voulais suivre, ceux que j’utilise en tant qu’utilisateur (BorgBackup, Raspbian, Termux, Coreutils…), ceux sur lesquels je bosse (MariaDB, PHP, systemd, rsyslog…). Ensuite je me suis penché sur chaque projet, je m’attendais à quelque chose de plus carré et simple… c’est le bazar et pas du tout la cathédrale.

Voici ma liste par ordre alphabétique, je vais attendre un peu (work in progress) et j’en ferai un Mémo. Le premier lien concerne la page releases, le second lien le flux RSS, le troisième (quand il y a besoin) le changelog (news, release notes).

Ansible RSS Changelog
BorgBackup RSS Changelog
Chrony ML
Coreutils RSS
dnsdist RSS Changelog
Elixir RSS Changelog
Etcher RSS Changelog
FreshRSS RSS
Glances RSS
Guake RSS
HAProxy Changelog
MariaDB RSS Changelog
ncdu RSS
Nix RSS
Node.js RSS
peco RSS
PHP RSS
Python RSS
ranger RSS Changelog
Raspbian
rsyslog RSS Changelog
Ruby RSS
scrcpy RSS
Shaarli RSS Changelog
Signal RSS
Syncthing RSS
systemd RSS Changelog
Terminator RSS
Termux RSS
Tilix RSS

Ce que j’ai appris et compris

Le lecteur voit le résultat final qu’on lui présente élégamment dans un article, vous verrez difficilement certains points. Voici ce que j’ai appris et compris :

• Il m’a fallu plus de 3h pour 30 projets entre lister mes outils, ah j’ai oublié celui-là, il est où le flux RSS, bordel le changelog !
• Les 2/3 des projets sont sur GitHub… l’occasion de se remémorer l’article de Carl : Le danger GitHub
• Pour ceux qui ne le savent pas, sur GitHub il suffit en général d’ajouter .atom à la fin de l’URL pour avoir le flux RSS. Ainsi https://github.com/peco/peco/releases devient https://github.com/peco/peco/releases.atom
• Beaucoup de projets publient la release sur GitHub mais ne mettent aucune information. Par exemple rsyslog v8.34.0 (il faut cliquer pour comprendre) : v8.34.0. Dit autrement suivre certains flux RSS ne vous apportera aucune information sauf une date de sortie… il vous faudra systématiquement aller sur la page Changelog. C’est bien pour ça que je les ai donné
• On pourrait croire que les projets plus importants sont mieux lotis ou plus carré, pas du tout ! Pour moi une référence c’est le changelog de Shaarli : 1/ Changelog versionné, nommé CHANGELOG.md bien voyant et à la racine du projet sur GitHub 2/ Une URL qui ne change pas ! https://github.com/shaarli/Shaarli/blob/master/CHANGELOG.md contrairement à https://github.com/borgbackup/borg/blob/1.1.5/docs/changes.rst#changelog avec le numéro de version dedans, ce qui veut dire que ça va changer 3/ Où on renseigne comment est pensé le changelog : The format is based on Keep a Changelog and this project adheres to Semantic Versioning
• A comparer avec Raspbian par exemple, je n’ai pas trouvé de flux RSS… raspbian.org existe mais le changelog est chez raspberrypi.org…
• Citons aussi dnsdist, un sous-projet de PowerDNS. Les releases de PowerDNS et dnsdist sont mises ensemble… donc mélangées : https://github.com/PowerDNS/pdns/releases
• Parfois pas le choix, il faut passer par une mailing list : https://chrony.tuxfamily.org/lists.html https://www.mail-archive.com/haproxy@formilux.org/msg28004.html (on peut se brancher en RSS dessus mais il faudra filtrer sur ANNOUNCE)
• Pour vous rendre compte de la difficulté et du bazar pour trouver les bonnes URL : http://feeds.feedburner.com/PythonInsider https://dev.yorhel.nl/ncdu/changes https://savannah.gnu.org/news/atom.php?group=coreutils https://github.com/systemd/systemd/blob/master/NEWS https://www.haproxy.org/download/1.8/src/CHANGELOG https://elixir-lang.org/blog/categories.html#Releases

Cheminement

Souvent les informations récoltées via flux RSS sont insuffisantes, il faut alors aller chercher le changelog qui peut être difficile à retrouver…

Pour ma part je garde un fichier nommé releases sous la main où j’ai répertorié les URL des projets. Concrètement le cheminement donne 1/ Je suis averti de la nouvelle version du logiciel par flux RSS 2/ Je consulte le changelog ou 3/ J’ouvre mon fichier releases, je clique sur le lien du changelog. C’est une solution peu satisfaisante et perfectible. Comment vous faites de votre côté ? Une meilleure solution ? Partagez !

En conclusion

Il reste encore beaucoup de chemin à parcourir aussi bien côté projets pour qu’ils informent correctement et de manière simple que côté utilisateurs cherchant « juste » à s’informer. Chaque projet gère sa barque comme il l’entend, il faut gérer les priorités et faire avec les moyens du bord mais communiquer, améliorer ou juste fournir un changelog et un flux RSS corrects ne devrait pas être négligé.

Les modèles du genre sont Python, MariaDB, Shaarli. Développeurs au boulot

Original post of blog-libre.Votez pour ce billet sur Planet Libre.