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'infomation

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é.

Aujourd'hui, ce mardi 10 avril est une journée dédiée à un test précis : sur la modularité. 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 modularité est le résultat de la réflexion de Fedora.next, amorcé en 2014. L'objectif est de découpler le cycle de vie des applications avec celui de Fedora afin qu'un utilisateur de Fedora bénéficie de plus de flexibilité. Il serait par exemple possible de choisir une version native de Python plus récente ou plus ancienne que celle disponible par défaut. Auparavant cela n'était possible qu'en choisissant une autre version de Fedora ce qui pouvait être contraignant.

Les modules se comportent comme des dépôts supplémentaires proposant un ensemble de paquets destinés à remplacer ceux des dépôts officiels. Mais bien entendu, tout cela est géré par le projet Fedora avec la même qualité et les mêmes mainteneurs.

Pour le moment Fedora propose quelques modules : Docker, Django, NodeJS et le langage Go.

Les tests du jour couvrent :

• Lister les modules disponibles et installés ;
• Installer un nouveau module ;
• Activer un nouveau module.

Comme vous pouvez le constater, ces tests sont assez simples et ne devraient prendre que quelques minutes seulement.

Il vous faudra bien évidemment installer le dépôt modular avant (paquet fedora-repos-modular).

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é.

Les RPM de PHPUnit version 7.1 sont disponibles dans le dépôt remi pour Fedora ≥ 25 et pour Enterprise Linux (CentOS, RHEL...)

Documentation :

• PHPUnit manual
• Release Announcement for version 7 of PHPUnit (en anglais)

Cette nouvelle version nécessite PHP ≥ 7.1 et n'est pas rétro-compatible avec les versions précédentes, donc s'installe en parallèle des versions 5 et 6.

Installation, Fedora :

dnf --enablerepo=remi install phpunit7

Installation, Enterprise Linux :

yum --enablerepo=remi install phpunit7

Remarque: cet outil est une pièce essentielle de la QA PHP dans Fedora. Cette version sera aussi disponible dans Fedora 28.

Les RPM pour installer la nouvelle version majeure de phpMyAdmin sont disponibles dans le dépôt remi pour Fedora et Enterprise Linux (RHEL, CentOS...).

Site officiel : http://www.phpmyadmin.net/

Annonce de la version : phpMyAdmin 4.8.0 is released

Je pense que cette nouvelle version sera aussi bientôt disponible dans Fedora, mais la version 4.0.x devrait rester dans EPEL-6 (pré-requis sur MySQL 5.5) et la version 4.4.x dans EPEL-7 (pré-requis sur PHP 5.4). Donc elle est déjà disponible pour fedora 25 à 28 et pour enterprise linux 6 à 7 dans le dépôt remi.

Cette version sera disponible dans Fedora 28, rien n'est encore décidé pour Fedora 27.

Comme toujours, pour Fedora :

dnf --enablerepo=remi install phpMyAdmin

Ou pour Enterprise Linux

yum --enablerepo=remi install phpMyAdmin

Je vous laisse découvrir cette nouvelle version qui intègre beaucoup de nouveautés, et remonter vos impressions.

Je parle pas souvent de packaging et de fabrication de RPM sur ce blog. La raison est toute simple : L'activité est hyper documentée. Ce week-end j'ai soumis trois nouveaux paquets pour le dépôt fedora, j'en suis à l'étape longue et lente d'ajout des RPMs dans le dépôt updates-testing, puis updates (stable). Longue mais pas difficile en soi. Il faut avouer que c'est hyper documenté.

Du coup, j'ai profité de ce temps d'attente pour faire du tri dans mes onglets firefox ouverts, sauf que cette fois je partage avec vous une petite sélection. À chaque fois je me fais la réflexion de bookmarker ces liens, et à chaque fois je ne le fais pas. Je m'exaspère. Mais bon, ces quelques liens, pourraient à coup sûr réveiller des vocations et déchainer les passions.

1. https://fedoraproject.org/wiki/Packaging:SourceURL#When_Upstream_uses_Prohibited_Code
2. https://fedoraproject.org/wiki/Packaging:Python_Appendix
3. https://fedoraproject.org/wiki/Packaging:Python
4. https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering
5. http://fedoraproject.org/wiki/Packaging:Python_Eggs
6. https://fedoraproject.org/wiki/Packaging:Guidelines#Version_and_Release
7. http://fedoraproject.org/wiki/Packaging:RPMMacros
8. http://fedoraproject.org/wiki/Packaging:Guidelines#Beware_of_Rpath
9. https://fedoraproject.org/wiki/Package_Review_Process
10. https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Import.2C_commit.2C_and_build_your_package
11. https://fedoraproject.org/wiki/Package_update_HOWTO
12. https://fedoraproject.org/wiki/Package_maintenance_guide

La conception de paquet RPM n'a rien à voir avec les 12 Travaux d'Astérix. Qu'on se le dise ;-)

Je parle pas souvent de packaging et de fabrication de RPM sur ce blog. La raison est toute simple : L'activité est hyper documentée. Ce week-end j'ai soumis trois nouveaux paquets pour le dépôt fedora, j'en suis à l'étape longue et lente d'ajout des RPMs dans le dépôt updates-testing, puis updates (stable). Longue mais pas difficile en soi. Il faut avouer que c'est hyper documenté.

Du coup, j'ai profité de ce temps d'attente pour faire du tri dans mes onglets firefox ouverts, sauf que cette fois je partage avec vous une petite sélection. À chaque fois je me fais la réflexion de bookmarker ces liens, et à chaque fois je ne le fais pas. Je m'exaspère. Mais bon, ces quelques liens, pourraient à coup sûr réveiller des vocations et déchainer les passions.

1. https://fedoraproject.org/wiki/Packaging:SourceURL#When_Upstream_uses_Prohibited_Code
2. https://fedoraproject.org/wiki/Packaging:Python_Appendix
3. https://fedoraproject.org/wiki/Packaging:Python
4. https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering
5. http://fedoraproject.org/wiki/Packaging:Python_Eggs
6. https://fedoraproject.org/wiki/Packaging:Guidelines#Version_and_Release
7. http://fedoraproject.org/wiki/Packaging:RPMMacros
8. http://fedoraproject.org/wiki/Packaging:Guidelines#Beware_of_Rpath
9. https://fedoraproject.org/wiki/Package_Review_Process
10. https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Import.2C_commit.2C_and_build_your_package
11. https://fedoraproject.org/wiki/Package_update_HOWTO
12. https://fedoraproject.org/wiki/Package_maintenance_guide

La conception de paquet RPM n'a rien à voir avec les 12 Travaux d'Astérix. Qu'on se le dise ;-)

Aujourd'hui, ce mercredi 4 avril est une journée dédiée à un test précis : sur les applications écrites en Rust. 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 ?

Le langage Rust est un langage de programmation moderne écrit par Mozilla pour remplacer le C++ en alliant les performances avec une meilleure fiabilité des applications en garantissant un maximum de propriété lors de la compilation.

Ce langage aux propriétés intéressantes a été utilisé pour écrire quelques applications disponibles dans Fedora. Le but de cette journée est de s'assurer que ces applications fonctionnent bien, permettant de valider le processus d'empaquetage des applications écrites en Rust.

Les tests du jour couvrent :

• L'application tokei qui génère des statistiques sur le code d'un projet logiciel ;
• L'application exa qui est l'équivalent d'un ls en plus élaboré (mais non POSIX) ;
• L'application ripgrep qui est l'équivalent d'un grep en plus moderne avec exécution parallèle nativement (mais non POSIX).

Comme vous pouvez le constater, ces tests sont assez simples et ne devraient prendre que quelques minutes seulement.

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é.

En ce mardi 3 avril, les utilisateurs du Projet Fedora seront ravis d'apprendre la disponibilité de la version Beta Fedora 28.

Malgré les risques concernant la stabilité dune version Beta, il est important de la tester ! En rapportant les bogues maintenant, vous découvrirez les nouveautés avant tout le monde, tout en améliorant la qualité de Fedora 28 et réduisez du même coup le risque de retard. Les versions en développement manquent de testeurs et de retours pour mener à bien leurs buts.

Notons que Fedora 28, avec ses quelques 51 changements officiels validés, est sans conteste la version comportant le plus de changements de son histoire. La version finale est pour le moment fixée pour la première semaine de mai (sortie le 1er ou le 8 mai).

Voici les nouveautés annoncées pour cette version :

Bureautique

• Passage à GNOME 3.28
• L'environnement Sugar est disponible en version 112.
• Mise à jour de Fontconfig à la version 2.13.
• Réduction de la redondance entre Anaconda et gnome-initial-setup dans la configuration demandée à l'utilisateur crée lors de l'installation. Le clavier, la date, l'heure et la langue resteront configurés par Anaconda, par contre la configuration du nom d'hôte est supprimée tout comme la création du compte root pour reprendre la politique d'Ubuntu. La création du premier utilisateur revient à gnome-initial-setup.
• Les modules invités de VirtualBox sont peu à peu intégrés dans le noyau officiel, Fedora propose ainsi dans ses dépôts officiels les paquets pour obtenir la résolution native ou le dossier partagé dans un système Fedora virtualisé dans Virtualbox.

Gestion du matériel

• Meilleure gestion de l'autonomie des ordinateurs portables avec un processeur Intel. Cela passe par une meilleure gestion de l'énergie des ports SATA pour disques durs et SSD (gain de 1-1,5 W), Intel HDA codec pour le multimédia est mis en sommeil après une seconde dinactivité (gain de 0,4 W) et activation de l'économie d'énergie pour les récepteurs Bluetooth en USB (gain de 0,4 W si tous les ports USB sont en repos). Sachant qu'un ordinateur portable récent non orienté puissance consomme moins de 10 W (7,5 W chez moi) en usage non intensif. Cela peut donner 20% d'autonomie supplémentaire.
• Intégration de la norme Thunderbolt 3 (concurrent à l'USB sur de nombreux points). La politique de sécurité liée à cette norme (pour éviter qu'un nouveau périphérique accède sans autorisation à des informations confidentielles) est intégrée à Gnome Shell pour notifier les demandes à l'utilisateur.
• Mise à jour de VA-API à la version 1.0.0, qui change l'API et l'ABI mais propose en contrepartie une meilleure exploitation de laccélération matérielle du matériel récent.
• Les appareils photo RealSens ont besoin de deux bibliothèques librealsense 1 et 2 pour exploiter l'entièreté de leur gamme historique. Le paquet librealsense réfèrera à la version 2 de la bibliothèque pour les versions modernes, un nouveau paquet librealsense1 sera nécessaire pour le matériel plus ancien.

Internationalisation

• Ibus Typing utilise maintenant la boîte de dialogue pour les emoji afin de proposer des symboles UNICODE en tapant leur description. Ainsi copyright sign propose le symbole ©.
• La bibliothèque libidn passe à la version 2.0.0 forçant le passage de la norme IDNA2003 à IDNA2008 qui ne sont pas compatibles et pouvaient être source d'attaque par redirection. Cette norme sert à transcrire un nom de domaine Internet UNICODE en une chaîne latine unique comme faß.de qui devient fass.de ou xn--fa-hia.de respectivement.
• Les données concernant linternationalisation de GLibc sont mises à jour à partir des fichiers ISO et CLDR de 2015 (Unicode 9.0) en remplacement de iso14651_t1_common qui avait 15 ans. Cela permettra de corriger pas mal d'erreurs, dont des tris alphabétiques dans des langages moins courants en Occident. Ou les symbole infini et ensemble vide qui étaient considérés comme identiques.
• Les langues asiatiques chinoises, coréennes et japonaises utiliseront par défaut les polices de Google Noto.

Administration système

• Anaconda, le programme d'installation, devient modulaire. La communication se fait via une API plus stable en DBus, permettant d'améliorer les tests, d'être utilisable sans les droits super utilisateur et d'être étendu par l'utilisateur.
• authselect remplace authconfig et devient l'outil de configuration par défaut pour le PAM et le fichier nsswitch.conf.
• Le paquet tcp_wrappers est supprimé. Son utilisation doit être remplacée par iptables, ou mieux par firewalld.
• libnsl et nss_nis sont proposés hors de GLibc comme recommandé par le projet officiel. libnsl passe à la version 2 au passage autorisant la compatibilité de NIS avec la norme IPv6.
• De même pour Sun RPC dont la gestion dans GLibc est supprimée pour libtirpc qui permet entre autre la gestion de l'IPv6 nativement.
• Le stockage par défaut des clés et autres certificats de sécurité par la bibliothèque NSS est le format de SQLite au lieu de DBM. Cela permet l'accès parallèle et diminue le risque de corruption de la base de données.
• OpenLDAP utilise OpenSSL au lieu de NSS, comme recommandée par le projet officiel.
• Les bibliothèques de OpenLDAP non compatibles multithread redirigent vers leur version compatibles multithread comme libldap qui pointe vers libldap_r.
• OpenLDAP abandonne la gestion de TCP Wrappers également.
• L'utilisateur et groupe nobody:nobody passent de UID et GUID 99:99 à 65534:65534, nfsnobody est supprimé, et nobody n'est plus utilisé de manière systématiquement par défaut pour certains services. Des utilisateurs dédiés seront crées.
• Nouvelle version de la politique de sécurité par défaut. Les clés RSA doivent être de minimum 2048 bits et DSA est désactivé par défaut. Le passage à TLS 1.2 minimum est repoussé pour le moment.
• Les paquets de gestion de Kerberos dans Python sont grandement remaniés. python-krbV, pykerberos et python-requests-kerberos sont remplacés par python-gssapi. Le premier n'est pas compatible Python 3, le second n'a pas de documentation et est trop minimaliste quant au dernier il n'est plus maintenu.
• libcurl utilisera libssh au lieu de libssh2 pour les protocoles SCP et SFTP ce qui permet l'utilisation de l'authentification GSS-API et l'usage d'algorithmes plus sécurisés par défaut.
• L'outil time passe à la version 1.8, qui change de licence vers GPLv3 et GFDL, qui a de nouveaux codes d'erreur et une nouvelle sortie par défaut. L'affichage conforme POSIX reste possible via l'option -p.
• Mise à disposition de l'application Stratis Storage qui est une application Python communiquant à travers DBus pour gérer l'espace de stockage du système. Reposant sur le système de fichier XFS pour le moment, son but est de proposer des fonctionnalités populaires chez Btrfs, ZFS ou LVM mais en plus simple pour l'utilisateur comme les clichés, l'intégrité des données ou mettre en place un système de cache.
• Facter passe de la version 2.4.3 à 3.9.2.

Développement

• Binutils passe à la version 2.29.1.
• GLibc 2.27 est utilisée par défaut.
• La partie cryptographique libcrypt de GLibc est remplacée par libcrypt.
• GCC 8 devient le compilateur de référence.
• Le framework Web de Python DJango dégaine à la version 2.0.
• Coup de Boost à la version 1.66.
• Ruby est polis à la version 2.5.
• Le compilateur Haskell GHC évolue à la version 8.2.
• De même pour le couple Erlang/OTP pour la version 20.
• Le langage Go court vers la version 1.10.
• L'éléphant PHP avance prudemment à la version 7.2.
• Mise à jour de giflib vers la version 5.1.4. Un paquet compat-giflib est proposé pour faciliter la transition aux utilisateurs.
• Les symboles de débogue PE pour les applications compilées avec MinGW (à destination de Windows donc) seront conservés pour simplifier le débogue natif. Les autres symboles seront bien conservés dans le dossier .debug à part. Cela a un sourcoût d'environ 17% d'espace disque pour une application compilée par ce biais.

Modularité

• Ajout des dépôts modular, modular-updates et modular-updates-testing pour proposer des composants dans des versions différentes que dans les dépôts natifs de Fedora. Ainsi l'utilisateur peut choisir d'utiliser une version plus récente (ou ancienne) de Python que celle proposée nativement. Mais seulement des composants toujours maintenus par le projet officiel sont proposés.

Projet Fedora

• L'architecture Aarch64 (ARM 64 bits) devient une architecture primaire pour Fedora Server, donnant lieu à une meilleure promotion et à une meilleure qualité des images officielles.
• L'architecture s390x est proposée aux images Cloud, Docker et Atomic.
• Les binaires empaquetés par Fedora et compilés avec GCC sont maintenant annotés pour permettre de plus facilement retrouver les options de compilations l'ayant généré ou les propriétés de son ABI.
• Renforcement des options de compilation par défaut pour une meilleure sécurité. Ajout de -fstack-clash-protection, D_GLIBCXX_ASSERTIONS, -fcf-protection=full -mcet, .got.plt et --enable-default-pie.
• Définition et empaquetage des applications écrites en Rust comme exa, ripgrep ou tokei.
• Activation de Python Generators pour permettre aux empaqueteurs de choisir d'utiliser ou non le générateur automatique de dépendance envers un module Python au lancement.
• Les scriptlets ldconfig sont supprimés, du moins pour les paquets installant les bibliothèques partagées dans des endroits standards. Cela simplifiera la maintenance des specs RPM et l'installation des paquets sera également plus rapide.

Si l'aventure vous intéresse, les images sont disponibles par Torrent ou via le site officiel. En cas de bogue, n'oubliez pas de relire la documentation pour signaler les anomalies sur le BugZilla ou de contribuer à la traduction sur Zanata.

Bons tests à tous !

L'état de la Beta de la future Fedora 28 a été jugée satisfaisant, elle sortira donc le 3 avril. Les versions Beta sont en générale bien stabilisées car la version rawhide, puis des versions alpha les précèdent. Les versions Beta permettent de remonter les derniers bugs et autres ajustements de dernière minutes. Il est donc important de la tester et de remonter les éventuels soucis.

Les changements de la Fedora 28

Dans les changements annoncés, et déjà tous en place, voici ce que nous propose la 28e édition de la Fedora.

Plus de modularité

La Fedora 28 reprend les travaux effectués sur le projet Modularity, qui veut proposer une base plus souple, et l'ensemble des logiciels proposés en modules. Les modules pourront permettre d'installer des logiciels dans des versions différentes plus facilement. Cela permettra aussi des mises à jour du système plus isolées du fonctionnement des programmes.

Ce n'est que le début. A priori, concrètement se seront des dépôts supplémentaires.

L'installeur Anaconda

Il s'agit d'un changement important mais plutôt invisible pour l'utilisateur lambda, car il s'agit du code d'Anaconda. Pour simplifier sa maintenance, et l'ajout de fonctionnalité, son code a été redécoupé en modules. La communication inter module passera par l'API DBus.

Annotations des binaires et mise à jour majeure du compilateur principale

Les binaires (programmes) possèderont un peu plus de métadonnées, des informations supplémentaires stockées directement dans le fichier, et qui permettront principalement de renforcer la sécurité. En effet, il sera possible de verifier que les binaires ont bien été compilés avec certaines options de renforcement, ce qui est toujours bon à prendre pour des scripts d'audit etc.

Cela reste dans la lignée de la philosophie de Fedora/RedHat, qui depuis toujours se bat sur ce genre de terrain. Compilation avec des options de plus en plus strictes, SELinux, nettoyages des bibliothèques embarquées et qui feraient double emploi avec celle du système, etc.

Le compilateur GCC passe en version majeure 8.x.x. C'est souvent lors de nouvelle version majeure de Fedora que ce changement opère. L'objectif est de recompiler 100% des binaires des paquets de la F28 avec ce nouveau GCC. Et si ce n'est pas possible (certains programmes pouvant ne pas être compatibles), de le faire en partie, et de reporter le reste pour le Fedora 29.

L'outil authselect remplace authconfig

Voilà tout est dit. Pour ceux qui utilisait authconfig pour selection/configurer vos méthodes d'authentification, il faudra maintenant faire avec authselect. J'espère qu'il fera aussi bien. A vérifier.

Les TCP wrappers deviennent obsolètes

Les outils comme inetd ou xinetd, qui avaient leurs places il y a 10 ou 20 ans, sont jugés maintenant comme étant quelque peu inutile. Ces outils étaient là pour principalement économiser quelques Ko/Mo de mémoire, quelques cycles CPU, mais avec la monté en puissance des machines d'aujourd'hui, et les programmes démons qui se sont bien améliorés, ce n'est plus pertinent. Surtout que le mécanisme principale, à savoir d'écouter sur un port pour lancer le démon correspondant en cas de besoin uniquement, peut complètement être remplacé par systemD nativement.

Toujours dans l'idée d'améliorer la sécurité, si ces outils sont inutiles, autant s'en débarasser. Ils sont donc maintenant indiqués comme obsolètes (deprecated), et disparaitront dans un futur proche.

Changement pour nobody

Le compte dédié aux usages ne nécessitant aucun droit particulier va légèrement changer. Il abandonne la paire d'uid/gid 99/99 pour utiliser la norme du Kernel quand celui-ci ne peut trouver d'UID/GID. Le compte nobody utilisera la paire 65534:65534, que vous avez peut être dû déjà rencontrer, par ex avec NFS. Du coup, le compte nfsnobody, qui fait maintenant doublon avec ce nouveau nobody, est supprimé. Là aussi, pour la sécurité, limiter le nombre de comptes présents et/ou les doubles usages, est toujours bon à prendre.

Amélioration de l'autonomie des batteries

Dans l'idée d'améliorer l'autonomie de nos PC portables, la Fedora 28 embarquera et activera de nombreuses options en ce sens. Cela concerne l'économie d'énergie sur les ports SATA et USB, ainsi qu'une fonctionnalité propre au carte son Intel (HDA). Si vous aviez l'habitude d'activer ses options, vous n'aurez plus à le faire ;)" class="smiley

Et le reste

Bien sûr beaucoup, si ce n'est pas l'ensemble des paquets seront mis à jour. Comme d'habitude une mise à jour majeure de Fedora est toujours l'occasion de faire des montées de version plus importante qu'en temps normal.

Il y a par exemple php qui passe en version 7.2.x, ruby qui passe en version 2.5. Mais aussi, que j'adore, le framework Django qui arrive en version majeure 2.0.x.

A noter aussi l'arrivée de nouveautés. Le fameux Stratis, une solution de gestion du stockage, qui remplace feu BTRFS pour RedHat. Je testerais sûrement ça en détail. Il y a l'activation du thunderbolt 3, et des drivers invités VirtualBox.

Bref, tout ça à tester !

Les RPM de PHP version 7.2.4 sont disponibles dans le dépôt remi pour Fedora 28 et dans le dépôt remi-php72 pour Fedora 25-27 et Enterprise Linux ≥ 6 (RHEL, CentOS).

Les RPM de PHP version 7.1.16 sont disponibles dans le dépôt remi pour Fedora 26-27 et dans le dépôt remi-php71 pour Fedora 25 et Enterprise Linux (RHEL, CentOS).

Les RPM de PHP version 7.0.29 sont disponibles dans le dépôt remi pour Fedora 25 et dans le dépôt  remi-php70 pour Enterprise Linux.

Les RPM de PHP version 5.6.35 sont disponibles dans le dépôt remi-php56 pour Enterprise Linux.

PHP version 5.5 a atteint sa fin de vie et n'est plus maintenu par le projet PHP.

Ces versions sont aussi disponibles en Software Collections dans le dépôt remi-safe.

Ces versions corrigent une faille de sécurité, la mise à jour est donc vivement recommandée.

Annonces des versions :

• PHP 7.2.4 Release Annoucement
• PHP 7.1.16 Release Annoucement
• PHP 7.0.29 Release Annoucement (securité uniquement)
• PHP 5.6.36 Release Annoucement (sécurité uniquement)

Installation : voir l'assistant de configuration et choisir la version et le mode d'installation.

Remplacement du PHP par défaut du système par la version 7.2 (le plus simple) :

yum-config-manager --enable remi-php72
yum update

Installation en parallèle, en Software Collection de PHP 7.2 (x86_64 uniquement) :

yum install php72

Remplacement du PHP par défaut du système par la version 7.1 (le plus simple) :

yum-config-manager --enable remi-php71
yum update

Installation en parallèle, en Software Collections de PHP 7.1 (x86_64 uniquement) :

yum install php71

Et bientôt dans les mises à jour officielles:

• Rawhide fournit PHP 7.2.4
• Fedora 28 - PHP 7.2.4
• Fedora 27 - PHP 7.1.16
• Fedora 26 - PHP 7.1.16

À noter :

• la version EL7 est construite avec RHEL-7.4
• la version EL6 est construite avec RHEL-6.9
• beaucoup de nouvelles extensions sont aussi disponible, voir PECL extension RPM status page

Informations, lire :

• Migration de PHP 5.5.x à PHP 5.6.x
• Migration de PHP 5.6.x à PHP 7.0.x
• Migration de PHP 7.0.x à PHP 7.1.x
• Migration de PHP 7.1.x à PHP 7.2.x

Paquets de base (php)

Software Collections (php56 / php70 / php71 / php72)

Il y a un mois était publiées les versions 5.6.34, 7.0.28, 7.1.15 et 7.2.3, j'en ai aussi profité pour rétro-porter quelques correctifs de sécurité sur les RPM des versions 5.4.45 et 5.5.38.

C'est donc l'occasion de regarder comment se répartissent les téléchargements, et leur évolution.

Les chiffres utilisés sont les téléchargements des paquets de base (php-common) sur 1 mois, soit un total d'environ 150 000 paquets.

Remarques:

• ces chiffres sont calculés à partir des journaux du serveur web de mon serveur et de la plupart des miroirs, il peut être faussé par les utilisateurs qui tirent la totalité du dépôt (reposync), mais ne tiennent pas compte des nombreux utilisateurs qui utilisent un dépôt interne privé (rsync).
• seuls les paquets de base sont comptabilisés, les SCL étant souvent utilisées dans un environnement multi-versions, donc impossible à agréger (environ 65 000 téléchargements).
• mon dépôt étant le seul à fournir les 6 versions pour EL-6 et EL-7, certains en sont devenu utilisateurs pour les versions EOL (gonflant leur chiffres), la version 5.4 étant aussi celle présente pas défaut dans le dépôt pricipal (remi).
• ces chiffres concernent uniquement mon dépôt de RPM, c'est à dire ceux qui ont choisis de mettre à jour la version fournie par défaut dans la distribution, donc ne reflète évidement pas la répartition réelle, mais peuvent en donner une idée.

1. Répartition par version

Soit:

• PHP 7.2.4: 12,7%
• PHP 7.1.15: 17,8%
• PHP 7.0.28: 14,2%
• PHP 5.6.34: 38,4%
• PHP 5.5.38: 10,3%
• PHP 5.4.45: 6.6%

On remarque qu'assez peu d'utilisateurs utilisent encore les versions EOL (17%) même si cela reste trop important. Plus de la moitié des utilisateurs sont restés en version 5, mais pour ceux qui sont passés en version 7, l'adoption des nouvelles versions mineures est plutôt bonne .

2. Évolution

Comparaison avec les chiffres de début février pour les versions 5.6.33, 7.0.27, 7.1.13 et 7.2.1 :

• PHP 7.2 : 9,8% => 15,3% (+56%)
• PHP 7.1 : 23,9% => 21,4% (-11%)
• PHP 7.0 : 18,7% => 17,1% (-9%)
• PHP 5.6 : 47,5% => 46,2% (-3%)

Ce qui confirme la bonne vitesse d'adoption des nouvelles versions mineures pour les utilisateurs des versions 7.x, et PHP 7.2 devrait assez vite dépasser la 7.0, puis la 7.1.

3. Support

Pour mémoire, les version 5.6 et 7.0 atteindront leur fin de vie en fin d'année, je recommande donc de planifier au plus vite la mise à jour vers une version maintenue.

Voir : Supported Versions

Aujourd'hui, ce lundi 25 mars, est une journée dédiée à un test précis : sur l'environnement de bureau GNOME. 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 ?

Nous sommes proches de la diffusion de la Fedora 28 beta. L'environnement de bureau GNOME est celui par défaut depuis les débuts de Fedora il y a 13 ans.

L'objectif est de s'assurer que l'ensemble de l'environnement et que ses applications sont fonctionnels.

Les tests du jour couvrent :

• La détection de la mise à niveau de Fedora par GNOME Logiciels ;
• Le bon fonctionnement du navigateur Web ;
• La connexion / déconnexion et changement d'utilisateurs ;
• Le fonctionnement du son, notamment détection de la connexion ou déconnexion d'écouteurs ou casques audios ;
• Possibilité de lancer les applications graphiques depuis le menu.

Comme vous pouvez le constater, ces tests sont assez simples et peuvent même se dérouler sans se forcer en utilisant simplement GNOME comme d'habitude. Donc n'hésitez pas de prendre quelques minutes pour vérifier les comportements et rapporter ce qui fonctionne ou non comme attendu.

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é.

Les versions Release Candidate sont disponibles dans le dépôt remi-test pour Fedora et Enterprise Linux (RHEL / CentOS) afin de permettre au plus grand nombre de les tester. Elles sont  fournit en Software Collections, pour une installation en parallèle, solution idéale pour ce type de tests. (uniquement pour x86_64) et également en paquets de base.

Les RPM de PHP version 7.2.4RC1 sont disponibles en SCL dans le dépôt remi-test et les paquets de base dans le dépôt remi-php72-test pour Fedora 25-27 et Enterprise Linux.

Les RPM de PHP version 7.1.16RC1 sont disponibles en SCL dans le dépôt remi-test et les paquets de base dans le dépôt remi-test pour Fedora 26-27 ou  remi-php71-test pour Fedora 25 et Enterprise Linux.

PHP Version 7.0 est désormais en mode maintenance de sécurité, il n'y aura donc plus de Release Candidate.

Installation : voir la Configuration du dépôt et choisir la version.

Installation en parallèle, en Software Collections de PHP 7.2 :

yum --enablerepo=remi-test install php72

Installation en parallèle, en Software Collections de PHP 7.1 :

yum --enablerepo=remi-test install php71

Mise à jour, de PHP 7.2 :

yum --enablerepo=remi-php72,remi-php72-test update php\*

Mise à jour, de PHP 7.1:

yum --enablerepo=remi-php71,remi-php71-test update php\*

A noter : la version 7.2.4RC1 est aussi disponible dans Fedora rawhide et la version 7.1.16RC1 dans updates-testing pour Fedora 27, pour la QA.

Les paquets pour EL-7 on été construit à partir de RHEL-7.4.

La version RC est généralement identique à la version finale (aucun changement accepté, à l'exception de correctifs de sécurité).

Software Collections (php71, php72)

Paquets standards (php)

Aujourd'hui, ce mardi 13 mars, est une journée dédiée à un test précis : sur l'internationalisation 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 ?

Comme chaque version de Fedora, la mise à jour de ses outils impliquent souvent lapparition de nouvelles chaînes de caractères à traduire et de nouveaux outils liés à la prise en charge de langues (en particulier asiatiques).

Pour favoriser l'usage de Fedora dans l'ensemble des pays du monde, il est préférable de s'assurer que tout ce qui touche à l'internationalisation de Fedora soit testée et fonctionne. Notamment parce qu'une partie doit être fonctionnelle dès le LiveCD d'installation (donc sans mise à jour).

Les tests du jour couvrent :

• Le bon fonctionnement d'ibus pour la gestion des entrées claviers ;
• La personnalisation des polices de caractères ;
• L'installation automatique des paquets de langues des logiciels installés suivant la langue du système ;
• La traduction fonctionnelle par défaut des applications ;
• Les nouvelles polices chinoises,japonaises et coréennes de Google Noto (changement de Fedora 28) ;
• Synchronisation de glibc avec les dernières normes CLDR (changement de Fedora 28) ;
• Boîte de dialogue IBus pour récupérer un Emoji à partir de son annotation et de sa description UNICODE (changement de Fedora 28) ;
• Test de Fontconfig 2.13 (changement de Fedora 28).

Bien entendu, étant donné les critères, à moins de savoir une langue chinoise, l'ensemble des tests n'est pas forcément réalisable. Mais en tant que francophones, de nombreuses problématiques nous concernent et remonter les problèmes est important. En effet, ce ne sont pas les autres communautés linguistiques qui identifieront les problèmes d'intégration de la langue française.

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é.

Récemment ce blog a dû se trouver un nouvel hébergement. Pour cela, j'ai fait le choix de Scaleway comme fournisseur de VPS. Je vais pas chercher des arguments dans tous les sens, ce qui a fait mouche, c'est le prix !

Voici un petit compte rendu après 1 mois d'utilisation.

Avantages :

• Le prix, on est moins cher que tout.
• C'est du free, il y a des APIs et des clients.
• La facturation est à la minute, idéal pour tester quelque chose.
• Le choix des produits (x68_64, ARM, ARM_64).
• Le choix des distros.
• L'interface web qui permet de faire plein de chose et de se connecter directement en virtual KVM.

Inconvénients :

• Les stocks... Il faut souvent attendre que quelqu'un libère un VPS pour pouvoir en upper un nouveau.
• La performances, en effet des benchs montrent les VPS de Scaleway moins performant que ceux d'OVH.
• La gestion des disques durs qui sont rajoutés comme des volumes qu'on empile.
• Le fait de ne pas avoir de kernel officiel de la distro... Mais on a un mainline, ce qui est bien aussi ;-).

Au début j'étais parti sur un simple starter à 2Go de RAM (VC1S) qui tenait très bien mon architecture : Apache 2.4 / PHP 7.2 / MariaDB 10.1 via Docker. Et puis, j'ai démarré mon container GitLab... Et là je dois avouer avoir eu tout le mal du monde à contenir GitLab à moins de 1.5Go, mais heurement StackOverflow est là...

Du coup j'ai du faire un snapshot de ma VM et démarrer ce snapshot avec une VPS de 4Go de RAM (VC1M) et hop j'avais un serveurs de 4 Go. Avec les optimisations, le container GitLab tourne nickel et je vais pouvoir faire évoluer mon architecture (Varnish pour WordPress par exemple).

Les RPM de QElectroTech version 0.6, une application pour réaliser des schémas électriques, sont disponibles dans le dépôt remi pour Fedora et Enterprise Linux 7.

Un peu plus de 2 ans après la sortie de la version 0.5, le projet vient de publier une nouvelle version de son éditeur de schéma électriques.

Site officiel : http://qelectrotech.org/  et l'annonce de version.

Bien sur l'installation se fait avec YUM :

yum --enablerepo=remi install qelectrotech

Les RPM (version 0.60-1) sont disponibles pour Fedora ≥ 25 et Enterprise Linux 7 (RHEL, CentOS, ...)

Les mises à jour sont aussi en route pour les dépôts officiels

• Fedora 28
• Fedora 27

À noter :il existe aussi un dépôt Copr / Qelectrotech avec les versions de "dévelopement" (actuellement la 0.7-dev).