Fedora-Fr - Communauté francophone Fedora - Linux

Planet de Fedora-Fr : la communauté francophone autour de la distribution Linux Fedora

A propos

Cette page est actualisée toutes les heures.

Cette page est une sélection de blogs autour de Fedora. Fedora-Fr.org décline toute responsabilité au sujet des propos tenus par les auteurs des blogs de ce planet. Leurs propos sont leur entière responsabilité.

Le contenu de ce planet appartient à leurs auteurs respectifs. Merci de consulter leur blogs pour obtenir les licences respectives.

Un processeur qui perd le nord

Charles-Antoine Couret

Retour trois années en arrière quand je me penchais sur la gestion du stockage de masse d'un projet professionnel. C'est toujours avec le fameux processeur 8148 de Texas Instrument, le même projet que pour l'épisode 1.

Le stockage de masse est assuré par une mémoire flash NOR. En réalité l'implémentation n'était pas le principal problème, je vais raconter à nouveau un bogue assez délicat à identifier.

Mais d'abord, contexte !

Contexte

Choix de la mémoire

Donc sur ce projet, comme tout projet avec un système embarqué, se pose la question du stockage du système d'exploitation, des données et de comment charger le tout.

Il y a en général plusieurs possibilités pour un tel système : une mémoire NAND, NOR, une carte SD, une mémoire eMMC (une carte SD soudée), une clé USB voire via Internet. Bien entendu, chaque support a son lot d'avantages et inconvénients, voici pourquoi le NOR a été choisi :

  • Il est très fiable sur la durée (bien plus que les flashs NAND ou les mémoires SD/eMMC) ;
  • Sa lenteur n'était pas impactant pour notre système (c'est en effet de tous la méthode d'accès la plus lente) ;
  • Son espace de stockage (256 Mio) pour son prix était suffisant, sachant que la NOR est plus cher au Gio que les autres dispositifs ;
  • Il est possible d'exécuter le système en place (c'est le mécanisme XIP pour eXecute In Place) ce qui économise de la RAM et simplifie la conception.

Le dernier point est une propriété intéressante. En fait le processeur est capable d'adresser directement dans la mémoire NOR, les instructions machine du genre exécuter la fonction de cette adresse n'a pas besoin d'être chargé en RAM, le processeur peut accéder à cette adresse depuis la NOR et exécuter la dite fonction sans charger le code au préalable.

Préparation

Cependant, la dite technique XIP nécessite d'être précautionneux. Tout d'abord, le processeur au départ n'a pas accès à tout l'espace de stockage que propose notre mémoire.

Car dans le monde ARM (ce qui suit reste plus ou moins valable avec d'autres architectures, potentiellement avec d'autres noms), quand nous appuyons sur le bouton d'alimentation de la carte, l'alimentation démarre le processeur qui lance un petit chargeur de démarrage située dans sa ROM et qui a été conçu par le fabricant de la puce, ici Texas Instrument. Il va initialiser le minimum nécessaire dans le SoC et essayer de charger du code depuis un espace de stockage (notre mémoire NOR bien entendu ici, mais cela peut être par Ethernet, USB, mémoire NAND, carte SD ou autre). Dans notre cas, nous avons configuré (matériellement, en mettant des pins du processeur à 1 et d'autres à 0) de sorte que ce chargeur de démarrage cherche notre système sur la carte SD (car durant le développement, nous avons une carte SD), et si rien n'est trouvé, charger depuis la NOR.

Ce sont des mécanismes assez simples derrière. Pour le démarrage SD, le processeur détecte si une carte est présente, essaye de trouver un fichier nommé MLO dans un système de fichier FAT de la première partition pour le charger. Pour la NOR, il vérifie si les 4 premiers octets (situés à l'adresse 0x08000000) sont non nuls (donc différents de 0xFFFFFFFF ou 0x00000000). Si le chargement est effectué mais que cela n'aboutit sur rien, le processeur sera bloqué. Donc il faut veiller à charger quelque chose de correct.

Et pour charger le code initial (dans notre cas notre propre chargeur de démarrage U-boot, qui chargera Linux, qui chargera le reste des applications), le chargeur de démarrage de Texas Instrument n'a pas besoin de tout charger. Essentiellement car c'est plus simple, mais aussi parce que c'est plus générique, toute mémoire NOR pourra être chargée à priori quelque soit sa taille réelle.

Donc il ne charge que les 4 premiers kiloctets disponibles. Ces premières instructions de U-boot vont servir principalement à initialiser le nécessaire pour accéder au reste de la mémoire NOR, initialiser également la pile, la vitesse du processeur, etc.

C'est pour cela que nous avons le code suivant situé dans les 4 premiers kiloctets. Puis il y a une subtilité technique à prendre en compte. Nous allons changer les paramètres d'accès à la mémoire NOR. Cela se fait par l'écriture sur 7 registres différents dans le processeur. Non seulement nous allons dire au processeur d'activer des lignes d'adresses supplémentaires (permettant l'accès à toute la mémoire disponible), mais en plus nous allons modifier la vitesse d'accès pour améliorer les performances globales.

Les paramètres d'accès à la NOR sont situés dans les registres GPMC (adresses 0x51000060 à 0x51000078). Nous pouvons indiquer au processeur, pour chaque caractéristique du signal pour dialoguer avec la NOR, le nombre de cycles d'horloge nécessaires. Ces valeurs dépendent donc de la vitesse d'un cycle d'horloge et des caractéristiques de la mémoire NOR.

Attention, quand je parle de la vitesse d'un cycle d'horloge, ce n'est pas directement celui du processeur lui même. En général au sein d'un circuit, il y a une chaîne d'horloge qui se met en place pour alimenter chaque sous-système avec une vitesse qui lui convient. Ainsi le réseau, le multimédia, l'USB, le PCIe ou le processeur lui même ont des horloges propres. Ces horloges sont construits à partir de quartz qui générèrent un signal entre 15 et 25 MHz. Ensuite une PLL va amplifier ce signal pour moduler sa vitesse afin d'atteindre parfois plusieurs GHz. Dans notre cas, le quartz OSC0 (à 20 MHz) alimente la DPLL L3 (jusqu'à 220 MHz) qui alimente l'horloge GPMC qui divise par quatre le signal précédent (jusqu'à 55 MHz donc). Je ferais sans doute un article complet sur le sujet des horloges. :-)" class="smiley

Et comme nous allons changer la vitesse d'accès à la mémoire, alors que nous exécutons le code depuis la NOR elle même, vous pouvez deviner un problème. Entre le changement du premier et du dernier registre, les temps d'accès à la NOR ne seront plus cohérents, le système va se bloquer faute de pouvoir lire les instructions suivantes. Du coup il est nécessaire de copier le bout de code qui fait ce changement dans la SRAM (une petite zone de mémoire interne au processeur à l'adresse 0x40400000, qui n'est pas impactée par nos changements) afin de l'exécuter depuis celle-ci avant de revenir exécuter le code dans la NOR une fois l'opération faite.

Cela est fait via les lignes suivantes (l'essentiel du code employé provient du code de Texas Instrument qu'il a fallu adapter à notre cas) :

 /**************************************************************************
  * cpy_nor_gpmc_code: relocates nor gpmc init code into ocmc0 where its
  * safer to execute
  * R2 is loaded wtih size of data to be copied, this should be calculated
  * if we are modifying nor_gpmc_init()
  *************************************************************************/
 .global cpy_nor_gpmc_code
 cpy_nor_gpmc_code:
         stmfd sp!, {r0 - r10}
         /* Copy NOR GPMC init code into SRAM */
         adr r0, nor_gpmc_init     /* get addr of nor gpmc init code */
         mov r2, #640    /* r2 <- copy size(% by 32 bytes:r3-r10 (8) regs used) */
         ldr r1, sram_pc_start     /* r1 <- dest address (passed in) */
         add r2, r2, r0      /* r2 <- source end address */
 next2:
         ldmia   r0!, {r3 - r10}     /* copy from source address r0 */
         stmia   r1!, {r3 - r10}     /* copy to   target address r1 */
         cmp r0, r2          /* until source end address r2 */
         bne next2
         ldmfd sp!, {r0 - r10}
         mov pc, lr          /* back to caller */

Ce code fonctionne comme attendu, les premières cartes venant de la série A fonctionnent tous sans encombres.

Les problèmes arrivent

Quelques mois plus tard, un second jeu de cartes électroniques arrive avec une révision matérielle pour corriger les premiers défauts relevés. Et au bout de quelques heures, nous détectons un problème fondamental : sur certaines de ces cartes, le démarrage depuis la NOR ne fonctionne pas du tout, sur d'autres c'est aléatoire (de 1 fois sur 2 à 1 fois sur 100) et sur un exemplaire, aucun problème.

C'est pourtant, à ce stade, le même code qui est exécuté que sur les premières cartes qui ne bronchent toujours pas dans cet exercice. Notons également que sur ces nouvelles cartes, le démarrage depuis une carte SD ne pose aucun problème. D'ailleurs charger U-boot depuis la carte SD et le reste depuis la NOR ne présente aucun problème non plus.

La première piste est évidemment de vérifier tous mes calculs pour les registres d'accès à la NOR. Nous tombons tous d'accord sur le fait que ces valeurs sont correctes. Nous vérifions également l'ensemble des changements matériels autour du processeur et de la NOR et il n'y a rien. Tout au mieux, le responsable du routage de la carte (celui qui est responsable de transformer les liaisons logiques entre les composants en un circuit avec les pistes dessinées sur le plan final) note une différence de quelques micro/millimètres sur la longueur de ces fils entre les deux versions.

Mais rien de très intéressant, le module n'a pas beaucoup bougé sur ces fonctions et pourtant, le comportement est aléatoire. Nous prenons donc la JTAG pour en savoir plus afin de voir à quel endroit le démarrage échoue. Sur la plupart des modèles, cela tourne autour des registres du Watchdog. Mais si on supprime cette section du code, cela apparaît plus loin. Il semble donc que les échecs se produisent autour d'un certain nombre d'instructions constant depuis le démarrage plutôt que sur une instruction particulière. La JTAG nous montre que à l'instruction de trop, il va charger l'instruction suivante à une adresse délirante avant de retomber sur le vecteur d'exceptions du processeur pour avoir accédé dans une zone mémoire invalide.

Pour essayer d'identifier la cause de l'échec, le concepteur de la carte prend son oscilloscope à bras le corps et fait les mesures pendant que j'exécute le logiciel avec la JTAG pas à pas. Il semble que par moment le processeur fasse des signaux d'accès à la NOR d'environ 10 nanosecondes (oui, nanosecondes) trop courts. Pourtant les valeurs des registres que nous avons indiqué sont bons.

La solution

Une première solution est d'abaisser significativement les performances d'accès à la NOR et cela semble fonctionner. Mais si la NOR n'était pas un soucis niveau performances, nous avons une exigence contractuelle de démarrer l'ensemble du système en moins d'une minute. Et avec ces réglages, ce n'était plus possible. Puis nous ne comprenons toujours pas la cause du problème ce qui est gênant.

Il me faudra près d'une semaine de recherche dans la documentation de Texas Instrument pour comprendre la cause du problème et ainsi comment le résoudre. Je tombe en effet sur l'information suivante (page 1027 du document technique de référence) :

Horloge-boot-NOR.png

Or, si on prend le document de référence condensé page 183, on a :

Horloge-OPP.png

Vous ne voyez pas ? Il y a pourtant une incohérence pour une source d'horloge : la DPLL L3 qui est pour l'OPP 100 de 220 MHz et de l'autre de 200 MHz.

Or, tous mes calculs ont été conçus pour un signal d'entrée de 50 MHz et non de 55 MHz, ce qui donne un temps d'accès par cycle respectivement de 18 à 20 nanosecondes, soit bien sûr 2 nanosecondes d'écart. Quand on sait que la quasi-totalité de la configuration du signal d'accès tourne autour de 4 à 6 cycles par élément du signal, on retombe sur les 10 nanosecondes environ plus court constatés plus haut.

En quoi la documentation / implémentation de Texas Instrument est étrange ? En fait il faut expliquer brièvement ce qu'est un OPP. Un OPP pour OPerating Point est une méthode pour gérer l'énergie. Il consiste à fixer les fréquences maximales des différentes horloges du système par rapport à la tension d'alimentation du processeur. Plus le processeur consomme d'énergie (avec une tension élevée), plus les fréquences peuvent être élevées, mais plus la température peut monter également. En général on utilise le terme Dynamic Voltage Frequency Scaling pour décrire ce mécanisme.

Ce qui est curieux est que lors du démarrage NOR, par défaut, la ROM de Texas Instrument utilise l'OPP100 (celui de base) pour toutes les fréquences... sauf la L3 dont on se sert où c'est un OPP120 qui est employé. Cela n'est pas très cohérent comme choix et c'est ce qui nous a induit en erreur dans les calculs. Dans notre cas, pour éviter d'avoir besoin d'une ventilation active de la chaleur, nous souhaitons avoir une OPP100 durant le fonctionnement de l'appareil.

Pourquoi ce caractère aléatoire ?

Jusqu'ici j'ai expliqué le cadre général, l'origine du bogue a été trouvée, mais je n'ai pas expliqué pourquoi sur certaines cartes cela fonctionne, d'autres pas. Pourtant le code et le problème devrait se manifester partout.

Tout d'abord le démarrage SD fonctionne car dans U-boot, je changeais manuellement la fréquence des différentes horloges pour fixer le tout à l'OPP100 (et pour démarrer certaines horloges pour le processeur multimédia dont j'ai parlé dans le précédent article, chose qui n'est pas fait par le chargeur de démarrage de Texas Instrument). Du coup je supprimais le problème dans ce cas.

Le caractère aléatoire vient des différences minimes entre les différentes cartes. Comme je l'ai dit plus haut, les nouveaux modèles étaient plus sensibles à cause de la longueur des pistes qui avait changé, mais aussi parce que les composants ne sont pas identiques (numéros de série différentes, modèles différents pour les quartz, etc.). Étant donné la différence minime dans les temps d'accès, ces variations mineurs en temps normal peuvent avoir des impacts importants sur la longue.

D'autant que je changeais les fréquences d'horloge peu après la configuration du GPMC. Du coup, certains modèles avaient parfois la possibilité de régler le problème en abaissant la fréquence d'horloge finale en accédant à ces instructions à temps et sans encombre, d'autres pas.

Conclusion

Nous avons pu voir un problème qui survient parfois dans le domaine, des cartes qui se comportent différemment. Cela montre la nécessité de tester chaque modèle même si à priori c'est le même code, le même circuit. Chaque carte est unique. Il est nécessaire de documenter au maximum les petits changements qui peuvent être opérés. une collaboration forte entre l'équipe matérielle et logicielle est également fondamentale, il est probable que la cause n'aurait pas été retrouvée si vite sans cela. Chaque équipe ayant pu apporter des informations cruciales dans la résolution du problème.

Ensuite, bien entendu, la lecture de la documentation est importante, il faut tout vérifier, tout contrôler. Même ce qui paraît évident / logique. Il aurait été aussi appréciable que Texas Instrument choisisse une voie de moindre surprise en adoptant un choix cohérent dans les valeurs initiales de ses fréquences.

Et j'espère que vous aurez appris au sujet du démarrage sur les plateformes ARM et de la gestion des horloges. :)" class="smiley

PHP version 7.0.25RC1 et 7.1.11RC1

Remi Collet

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.1.11RC1 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 24-25 et Enterprise Linux.

Les RPM de PHP version 7.0.25RC1 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 25 ou remi-php70-test pour Fedora 24 et Enterprise Linux.

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

PHP Version 7.2 est en mode développement, la version 7.2.0RC4 est aussi disponible.

emblem-notice-24.pngInstallation : voir la Configuration du dépôt et choisir la version.

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

yum --enablerepo=remi-test install php70

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

yum --enablerepo=remi-test install php71

Mise à jour, de PHP 7.0 :

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

Mise à jour, de PHP 7.1:

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

A noter : la version 7.1.11RC1 est aussi disponible dans Fedora 27 (updates-testing) et la version 7.2.0RC4 dans Fedora rawhide pour la QA.

emblem-notice-24.pngLes paquets pour EL-7 on été construit à partir de RHEL-7.4.

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

Software Collections (php70, php71)

Paquets standards (php)

Participez à la journée de test consacrée à la mise à niveau vers F27

Charles-Antoine Couret

Aujourd'hui, ce mercredi 11 octobre, est une journée dédiée à un test précis : sur la mise à niveau de Fedora vers le futur Fedora 27. 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 Fedora 27 final (prévu pour début novembre). Et pour que ce lancement soit un succès, il est nécessaire de s'assurer que le mécanisme de mise à niveau fonctionne correctement. C'est-à-dire que votre Fedora 25 ou 26 devienne Fedora 27 sans réinstallation, en conservant vos documents, vos paramètres et vos programmes. Une très grosse mise à jour en somme.

Les tests du jour couvrent :

  • Mise à niveau depuis Fedora 25 ou 26, avec un système chiffré ou non ;
  • Même que précédemment mais avec KDE comme environnement ;
  • De même avec la version Server ou Minimal au lieu de Workstation ;
  • En utilisant GNOME Logiciels plutôt que dnf.

En effet, Fedora propose depuis quelques temps déjà la possibilité de faire la mise à niveau graphiquement avec GNOME Logiciels et en ligne de commande avec dnf. Dans les deux cas le téléchargement se fait en utilisation normale de votre ordinateur, une fois que ce sera prêt l'installation se déroulera lors du redémarrage.

Pour ceux qui veulent bénéficier de F27 avant sa sortie officielle, profitez-en pour réaliser ce test, que cette expérience bénéficie à tout le monde. :-)" class="smiley

Personnellement j'ai déjà testé un peu en avance sur ma machine professionnelle et j'ai rapporté mon premier bogue bloquant pour Fedora. En effet, dnf plantait lors du redémarrage pour procéder à l'installation des nouveaux paquets. Mais ayant eu lieu en début de procédure, cela n'a pas d'effet négatif. Bogue très courant apparemment pour l'instant mais dont un correctif est en test.

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

Une erreur… bien cachée

Charles-Antoine Couret

J'avais dit que je parlerais un peu des systèmes embarqués et de mes aventures dans le milieu. Aujourd'hui je voudrais relater un problème que j'avais dû résoudre au travail et qui n'était pas évident. Le prochain article sera plus générique (et celui d'après à propos d'un autre problème au boulot). Je vais essayer de varier un peu. ;-)" class="smiley

Ce sera sûrement un peu long, et je vais donner mon cheminement intellectuel autour de ce problème. Je respecte la chronologie des éléments dont j'avais connaissance à chaque étape.

Présentation du matériel et contexte

Pour situer un peu, je travaillais sur une plateforme Texas Instrument 8148 qui est un processeur ARM Cortex-A8 couplé avec un processeur M3 et des accélérateurs vidéos / DSP en son sein. Cette plateforme exploitait un noyau Linux 2.6.37 patchée à mort par Texas Instrument pour son processeur.

Le but du jour était d'exploiter le composant TVP5158 de… Texas Instrument encore (ce module a été conçu pour ce processeur en même temps). Pour décrire rapidement, ce composant permet de fusionner jusqu'à 4 flux vidéo analogiques (PAL / NTSC principalement) dans un seul numérisé que le processeur peut exploiter.

En soit le composant avait déjà un pilote fonctionnel pour Linux. Mais cela ne nous convenait pas. En effet, nous utilisons le TVP dans une chaîne de traitement vidéo où on faisait des décodages, redimensionnements, des remplacements d'images ou encore des encodages. Pour faire cela, non seulement il faut de la performance mais il faut aussi utiliser une API plutôt unifiée.

La performance est offerte par les accélérateurs vidéos qui sont dans les co-processeurs du système. On peut les exploiter via un firmware (dont le code source est confidentiel, désolé) et on peut communiquer avec ces accélérateurs via le noyau Linux et l'API OpenMax (OMX). Cette API est standard, éditée par le même groupe et dans les mêmes conditions qu'OpenGL, mais plutôt que de s'occuper de la 3D, il s'occupe des codecs vidéos. C'est souvent la référence libre dans ce domaine, avec GStreamer couplé avec libav.

Cette API est disponible dans le firmware de TI, cela tombe bien. Mais là où cela ce corse c'est pour récupérer des informations. En effet, il faut que durant notre traitement vidéo que nous sachions la résolution détectée par TVP du flux vidéo, et s'il existe (sur les 4 flux, des caméras peuvent être en pannes ou absentes pour diverses raisons).

Et TVP se configure via un bus assez standard et typique I2C qui est assez simple à mettre en place et largement suffisant pour lire / écrire des registres sur un composant. Il est par exemple souvent utilisé dans les cartes mères / graphiques de nos ordinateurs pour les capteurs de températures. Le soucis est que ce bus ne peut être géré par le firmware de TI (pour configurer le flux) et par le noyau Linux (pour récupérer les infos sur le flux pour l'application). Si on fait cela, il y aura conflit et le bus sera inutilisable. Modifier le firmware pour renvoyer les informations à l'espace utilisateur ou que le noyau gère la configuration du flux vidéo est plutôt complexe. Le mieux est d'utiliser un canal de communication existant entre le noyau et le firmware pour faire ceci, le firmware a donc la main sur le bus I2C et le noyau fera ses requêtes a travers lui.

On code

Partie intéressant du travail, coder. Et réfléchir à comment faire aller / revenir les informations voulues. Le noyau et le firmware, comme dans la quasi-totalité des systèmes à processeurs asymétriques, communiquent entre eux par mémoire partagée. Une partie de la RAM est allouée pour les messages, une autre pour les buffers vidéos, etc. Ceci est configurable (avec des limites) dans le code des deux côtés. Bien évidemment, les deux doivent être d'accord sur les adresses de base de chaque fonction, sinon ils ne retrouveront plus leurs petits. Cela est plutôt bien pris en charge par l'environnement de compilation fourni par TI. Vous pouvez consulter l'adressage mémoire entre les deux ici.

Dm8148-ezsdk-sw-arch.png

Bon, et le code alors ? La communication entre ces deux modules se faisant par mémoire partagée, il y a un certain protocole qui a été conçu par TI et qui s'exploite à travers une API maison nommée FVID2. Elle est déjà partiellement implémentée mais pas celle concernant le fameux TVP (qui est pourtant décrite dans l'API en question). J'ai donc écrit un pilote Linux pour combler cela. Aspect amusant, TI à la pointe de la technologie fournissait la doc de cette API dans un document .chm, un vieux format propriétaire dont le seul lecteur sous Linux potable est une application de l'ère de KDE3 : Kchmviewer. Quand je vous dis que l'embarqué c'est moderne !

Mais cela reste un peu moche, l'application en espace utilisateur demande au firmware HDVPSS de configurer le TVP. Mais, pour faire cela, il instancie le pilote interne de TVP du firmware qui ne doit pas être instancié deux fois et dont on ne peut récupérer la référence pour notre API FVID2… J'utilise donc une référence d'un autre composant dont le noyau a la référence (car il l'instancie) et j'envoie mes messages avec, le firmware a été modifié pour comprendre la situation et rediriger le message ensuite à bon port. Je n'avais pas trouvé mieux dans le délai imparti.

Et le bogue arrive… parfois

Et après le code, on teste. Après plusieurs essais difficiles, cela fini par passer. Youhou. Champomy dans les bureaux.

Mais, quand mes collègues vont tester leur application avec mon travail, cela ne fonctionne pas toujours. Le module noyau qui fait les échanges avec le coprocesseur nous signifie que certaines requêtes, en quantité variables, mettent trop de temps à revenir. On était à une moyenne de 1 à 10 échecs par minute (pour 24 requêtes). Mais il arrivait malgré tout que sur 30 minutes / 1 heure cela n'arrive pas, avant de revenir. C'est beaucoup trop problématique, et ce qui est étonnant c'est que mes tests ne présentaient aucune erreur.

Du coup, comme pour toute chaine de communication, on va déboguer étape par étape pour identifier où cela coince. Je précise que la seule section dont je pouvais difficilement déboguer c'est l'échange des messages entre Linux et le firmware qui est assez mal documenté et le code assez obscur en plus d'être gros.

Matériel

Le plus simple à tester, c'est le matériel (recompiler le firmware vidéo pour y ajouter du débogue c'est 40 minutes de compilation, c'est pénible et long, on évite au maximum de le faire). Je vérifie donc que le TVP reçoit les bonnes requêtes et y répond. Le bus I2C étant très simple, un petit oscilloscope sur un fil et on peut rapidement conclure que les signaux sont bons dans les deux sens que la requête échoue ou non à la fin.

Mais je me dis que le temps d'attente côté Linux pour recevoir ce message est trop court, je l'allonge volontairement à un délai absurde comme 30 secondes, cela ne change rien. Soit ça réussi vite, soit au bout des 30 secondes j'ai l'erreur. Pas d'entre deux, pas de hausse ou baisse de ces erreurs.

Du coup on sait que la chaîne d'envoi est bonne, et le matériel aussi, le soucis se situe bien au retour.

Firmware vidéo

Donc forcément je remonte un peu la chaîne côté firmware vidéo et à chaque étape en son sein, l'information est correcte à tous les coups. Comme le soucis n'est pas côté Linux après l'API FVID2, le soucis se situe forcément dans le transfert des messages entre les deux mondes comme on dit. Côté retour uniquement.

Plongeons au cœur de la mémoire

À ce stade là, cela devient assez étrange. Comment cela peut planter de cette manière là ? Jémets quelques hypothèses, manque de place pour l'échange de messages (il y a d'autres messages que ceux du TVP là dedans) ou éventuellement un conflit de lecture / écriture simultanée par les deux sur un même message.

Pendant que je cherchais comment l'ensemble fonctionnait, des collègues m'ont rapporté des informations pertinentes (bah oui, ils continuent de testeur leur travail de leur côté et disent ce qui est pertinent quand ils constatent le problème). Il y a une corrélation entre le nombre de caméras branchées au TVP (et exploitées par notre programme) et la fréquence du bogue. Plus il y a avait de caméras, moins cela plantait. Cela paraît contre intuitif.

J'ai maintenant une idée plus claire de ce qui semble être le cas, mais je dois vérifier. J'essaye de voir donc comment l'échange de message fonctionne, et la fonction que j'appelle a quelques lignes intrigantes dont je copie la boucle intéressante :

while (fctrl->fctrlprms->returnvalue == VPS_FVID2_M3_INIT_VALUE) {
       usleep_range(100, 300);
       if (vps_timeout) {
              do_gettimeofday(&etime);
              td = time_diff(stime, etime);
              if (vps_timeout < td) {
                    VPSSERR("contrl event 0x%x timeout\n",  cmd);
                     return -ETIMEDOUT;
               }
        }
}

En gros, Linux initialise une valeur précise à une adresse précise dans la RAM. Quand le firmware a fini son boulot et renvoie les infos demandés, il signifie au noyau qu'il a fini en changeant la valeur initialisée précédemment. Le noyau regarde sa valeur régulièrement par tranches de 100 à 300 microsecondes pendant 2 secondes maximum.

Et comme par hasard, si je mets dans la boucle un printk de débogue (l'équivalent de printf pour le noyau, pour afficher des chaînes de caractères visibles en espace utilisateur, cette fonction est plutôt grosse), le bogue disparaît. Quelques soient les conditions.

Cela me renforce dans mon hypothèse : nous sommes face à un soucis d'accès à la valeur de cette variable. Le noyau Linux relit la variable depuis le cache ou le registre du processeur qui bien sûr ne change pas (car le processeur n'a pas changé cette valeur, c'est au coprocesseur de le faire !), du coup il voit éternellement la variable comme au départ et il croit que le firmware vidéo ne fout rien. Le printk ou l'activité du système (plus il y a de caméras, moins cela arrive, n'oublions pas) permettant à Linux de bien voir la véritable valeur en la rechargeant depuis la RAM.

Le problème vient du fait que ce genre de vérification ne doit pas se faire directement, surtout que la zone mémoire concernée a été allouée avec "ioremap()".

Il suffit donc de remplacer la ligne

 while (fctrl->fctrlprms->returnvalue == VPS_FVID2_M3_INIT_VALUE) {

Par

 while (ioread32(&fctrl->fctrlprms->returnvalue) == VPS_FVID2_M3_INIT_VALUE) {

Les accès par "ioread*()" mettent des barrières mémoires et indiquent que la variable peut être modifiée de l'extérieur. Obligeant donc une nouvelle lecture de la valeur en toute circonstance.

Conclusion

Je suis tombé sur ce bogue après quelques mois dans la vie active seulement. C'était un défi intéressant, je n'avais pas trouvé cela évident. C'est vraiment le genre de choses que l'on a tendance à oublier, on accorde trop de confiances aux couches d'en dessous (matériel / noyau / compilateur / bibliothèque / langage) qu'on en oublie qu'ils peuvent présenter des problèmes et qu'on doit faire attention en les utilisant.

Après, cela met en évidence un énième bogue / oubli stupide de la part de Texas Instrument (ils en font du code horrible, je vous le dis) qui aurait pu être évité s'ils travaillaient un peu plus avec le noyau officiel. Nul doute qu'avec plus de relecteurs de leur code, quelqu'un l'aurait vu. Mais bon, tant pis, je me suis bien amusé. :-)" class="smiley

PHPUnit 6.4

Remi Collet

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

Documentation : PHPUnit 6.4 manual et Release Announcement for PHPUnit 6.4.0 (en anglais)

emblem-notice-24.pngCette nouvelle version nécessite PHP ≥ 7.0 et n'est pas rétro-compatible avec les versions précédentes, donc s'installe en parallèle de la version 5.

Installation, Fedora :

dnf --enablerepo=remi install phpunit6 

Installation, Enterprise Linux :

yum --enablerepo=remi install phpunit6 php-phpunit-dbunit3

Remarque: cet outil est une pièce essentielle de la QA PHP dans Fedora. Je prévois rapidement, une mise à jour dans Fedora.

Red Hat va fournir PHP 7.1 pour RHEL (et CentOS)

Remi Collet

Annonce : Red Hat updates Python, PHP, Node.js, more; supports new arches et RHSCL 3.0 Beta Release Notes.

Que les accrocs de la stabilité se rassurent, PHP 5.3.3 reste la version standard fournit avec RHEL-6 et PHP 5.4.16 celle de RHEL-7.

Nous disposerons donc bientôt d'un moyen officiel et supporté d'installer PHP version 5.6, 7.0 ou 7.1, en parallèle  de la version système, sans affecter les composants standards. L'annonce prévoit un cycle de vie de 3 ans. La version fournit est la 7.1.8.

emblem-important-2-24.png Il s'agit pour l'instant uniquement d'une version Beta destinée à l'évaluation.

Pour plus d'informations sur l'installation et l'utilisation des SCL, vous pouvez consulter les autres billets déjà publiés à ce sujet :

emblem-notice-24.pngPour les utilisateurs des clones de RHEL (CentOS, Oracle, Scientific Linux, ...) vous pouvez utiliser le dépôt centos-sclo-rh-testing (maintenu par le SIG SCLo).

emblem-notice-24.pngPour ceux qui souhaitent plus d'extensions, vous pouvez utiliser la dépôt centos-sclo-sclo-testing.

En dehors de PHP, RHSCL 3.0 senrichit de plusieurs morceaux de choix, je retiendrais Mariadb 10.2, MongoDB 3.4 et PostgreSQL 9.6

Il me semble que c'est une excellent nouvelle qui devrait aider à l'adoption des versions récentes de PHP dans le monde de l'entreprise.

emblem-question-24.pngSi vous avez des questions, j'ai même ouvert un Forum dédié : About PHP SCL.

Fedora 27 Beta est disponible !

Charles-Antoine Couret

C'est ce mardi 3 octobre que les utilisateurs du Projet Fedora seront ravis d'apprendre la disponibilité de la version Beta du futur Fedora 27.

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 27 et réduisez du même coup le risque de retard. Les versions en développements manquent de testeurs et de retours pour mener à bien leurs buts.

Cette version se distingue par l'absence de version Alpha préalable. Un grand effort sur la qualité a été entrepris pour essayer de se dispenser de cette étape intermédiaire. Et la qualité est en effet au rendez-vous.

Bureautique

  • Mise à jour vers GNOME 3.26.
  • Suppression du script 256term.sh qui changeait la valeur de la variable $TERM pour activer les couleurs dans les terminaux. Maintenant ce sont les émulateurs de terminal qui s'en chargent directement.
  • Fedora propose une image unique pour l'architecture AARCH64 (ARM 64 bits) qui prendra en charge les cartes suivantes : Pine64, Raspberry Pi 3 et 96boards.
  • Une meilleure gestion des SoC Intel Bay Trail et Cherry Trail (essentiellement des Pentium, Celeron et Atom sur portables et tablettes) : meilleure surveillance de la batterie, gestion de l'audio, de l'écran tactile et des accéléromètres.
  • La gestion des ordinateurs ayant un UEFI 32 bits mais un CPU 64 bits. Fedora sera ainsi installable sur ces configurations comme Asus Transformer T100TA, HP Stream 7, Dell Venue 8 Pro 5830 et les premiers Macintosh Intel.
  • Mise à jour de libpinyin vers la version 2.1 pour les entrées de saisi en chinois.
  • La mise à disposition de polices de caractères Serif pour le chinois par défaut.

Administration système

  • Activation de l'option TRIM pour les nouvelles partitions chiffrées avec LUKS1, pour accroître les performances des SSD dans le temps.
  • Nouveau système de cache pour les identifiants Kerberos nommé KCM qui améliore l'expérience utilisateur notamment pour les environnements dans un conteneur applicatif.
  • libcurl réutilise OpenSSL pour la cryptographie et le protocole TLS au lieu de NSS.
  • OpenVPN utilise un nouvel algorithme de cryptographie par défaut qui est AES-256-GCM au lieu de BF-128-CBC améliorant la sécurité des connexions.
  • Le serveur OpenSSH rejoint la politique centralisée des mots de passe, comme le client OpenSSH, GnuTLS, NSS et OpenJDK avant lui.
  • Suppression du protocole SSH-1 dans OpenSSH qui n'était plus sécurisée, ni même supportée officiellement par le projet depuis quelques temps.
  • Installer le paquet perl installera l'ensemble des modules core du projet officiel, ce qui est plus conforme vis à vis des autres distributions.
  • Les paquets officiels ayant besoin de Java n'utiliseront plus le $PATH pour retrouver la JVM mais directement la JVM fournie par défaut par Fedora (OpenJDK). Ainsi, les utilisateurs souhaitant exécuter leurs propres applications avec une autre JVM pourront le faire via la variable $JAVA_HOME.
  • Suppression des paquets krb5-appl-clients et krb5-appl-servers qui ne seront bientôt plus maintenus et ne sont plus assez sécurisés aujourd'hui.
  • Remplacement de l'interface graphique de gestion de paquets Yumex par dnfdragora qui propose une interface Qt, GTK+ et ncurses.
  • Ajout de Samba AD pour la gestion des Active Directory.
  • Mise à jour de RPM à la version 4.14.

Développement

  • La bibliothèque standard Glibc progresse à la version 2.26.
  • La bibliothèque majeure du C++ Boost donne un coup de boost à la version 1.64.
  • Le serveur de rendu de JavaScript Node.js s'exécute à la version 8.6 LTS.
  • La boîte à outils Web Ruby on Rails 5.1 est sur les rails.
  • Le langage Go fonce à la version 1.9.
  • Le langage Perl a été poli à la version 5.26.
  • La nouvelle version de la machine virtuelle OpenJDK danse la Java une 9e fois.
  • Make sudo pip safe again! qui propose enfin un meilleur nettoyage lors de la désinstallation d'un module installé via pip. Les modules sont également installés dans /usr/local.
  • Il est possible d'installer les paquets de débogue (les debuginfo) 32 et 64 bits pour une même application en même temps.
  • Les paquets debuginfos sont scindés en debuginfos et debugsources. Le premier contient les binaires et autres bibliothèques avec les symboles de débogage tandis que les seconds contiennent uniquement le code source du paquet.

La modularité

  • Création des outils dans le cadre de la Factory 2.0 pour permettre le découplage entre la version d'un paquet, la version de rattachement dans Fedora et sa fin de vie.
  • Séparation du Base runtime en Plateforme et Hôte, le premier prenant en charge l'espace utilisateur et la base du système quand le second s'occupe uniquement de la gestion du matériel.
  • L'édition Fedora serveur reçoit les premiers travaux officiels pour gérer la modularité, alors qu'elle a été testée par l'édition spéciale Boltron lors de Fedora 26.
  • Le concept du Python système est revisité et devient le Plateforme Python. L'objectif est de fournir un Python pour les applications systèmes de base comme dnf et rpm (/usr/libexec/platform-python) qui puisse différer de celui des autres applications (/usr/bin/python).

Autour de Fedora

  • Comme annoncé, Fedora n'utilisera plus de version Alpha durant son développement grâce à l'amélioration des outils et des procédure de qualité. Cela bénéficie également à la branche Rawhide.
  • L'utilitaire Bodhi, qui sert notamment au déploiement et aux retours (commentaires + bogues) des mises à jours et des ISO de Fedora, peut prendre en charge les applications Flatpak, OStrees, les images Docker, etc. Ce qui peut faciliter l'amélioration de la qualité de ce genre d'images.

La version finale est pour le moment prévue pour le 9 novembre.

Si l'aventure vous intéresse, les images sont disponibles par Torrent.

Vous pouvez également procéder à une mise à niveau depuis votre Fedora existant, ou télécharger l'ISO depuis un 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 !

PHP version 7.0.24 et 7.1.10

Remi Collet

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

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

emblem-important-2-24.pngPHP version 5.5 a atteint sa fin de vie et n'est plus maintenu par le projet.

Ces versions sont aussi disponibles en Software Collections.

Pas de correctifs de sécurité ce mois ci, donc pas de mise à jour de la 5.6.31.

Annonces des versions :

emblem-notice-24.pngInstallation : 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.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

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

yum-config-manager --enable remi-php70
yum update

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

yum install php70

Et bientôt dans les mises à jour officielles:

emblem-important-2-24.pngÀ noter :

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

emblem-notice-24.pngInformations, lire :

Paquets de base (php)

Software Collections (php70 / php71)

Participez à la journée de test consacrée à la version Atomic / Cloud

Charles-Antoine Couret

Aujourd'hui, ce vendredi 29 septembre, 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 Atomic / 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).

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 ;
  • 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.

Si vous êtes intéressés par l'aspect Cloud de cette image, je vous invite à la tester, elle bénéficie en effet de relativement peu de retours. 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é.

Participez à la journée de test consacrée à GNOME 3.26

Charles-Antoine Couret

Aujourd'hui, ce jeudi 29 septembre, 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 27 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é.

Participez à la journée de test consacrée au noyau Linux 4.13

Charles-Antoine Couret

Aujourd'hui, ce mercredi 27 septembre, est une journée dédiée à un test précis : sur lo noyau Linux 4.13. 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 noyau Linux est le cœur du système Fedora (et des autres distributions GNU/Linux). C'est le composant qui fait le lien entre les logiciels et le matériel. C'est lui qui permet aux processus de travailler ensemble sur un même ordinateur et de pouvoir utiliser les périphériques (à travers des pilotes) disponibles sur chaque machine.

C'est donc un composant critique et il est nécessaire de s'assurer qu'il fonctionne.

Les tests du jour couvrent :

  • L'exécution des tests automatisés par défaut et ceux de performances ;
  • Vérifier que la machine démarre correctement ;
  • Vérifier que le matériel est bien exploité (affichage, claviers, souris, imprimantes, scanners, USB, carte graphique, carte son, webcam, réseau filaire et wifi, etc.)

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

RPM Fusion is near 10 years old

Nicolas Chauvet

10 years ago, one of the internal root Certificate Authority was generated for the project. The infra wasn't production ready yet, but few months later there was support for Fedora 8. One of the earlier message from the developers mailing list.

At that time, the idea to form a community shaped against Fedora was to bring people to work together on the same complementary repository for the distribution. Remember how Fedora started ? So this is still one root of the project.

GLPI version 9.2

Remi Collet

GLPI (Gestionnaire Libre de Parc Informatique) version 9.2 est publiée. Les RPM sont disponibles dans le dépôt remi-test pour Fedora ≥ 24 et Enterprise Linux ≥ 6.

Toutes les extensions n'étant pas encore publiées en version stable, c'est donc la version 9.1 qui reste dans le dépôt remi.

Actuellement dans le dépôt :

  • glpi-9.2-1
  • glpi-fusioninventory-9.2.0.1.0-1

Attention Attention: l'assistant d'installation est pour des raisons de sécurité uniquement accessible depuis le serveur sur lequel GLPI est installé. Voir le fichier de configuration (/etc/httpd/conf.d/glpi.conf) pour élargir temporairement cette autorisation si besoin.

Vous êtes invités à tester ces versions sur un environnement spécifique et à remonter vos questions, commentaires ou problèmes sur

Participez à la journée de test consacrée à l'internationalisation

Charles-Antoine Couret

Aujourd'hui, ce mardi 19 septembre, 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 polices Serif chinois par défaut (changement de Fedora 27) ;
  • Test de libpinyin 2.1 pour la saisie rapide du chinois Pinyin (changement de Fedora 27).

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

Bilan mensuel de la documentation francophone de Fedora-fr.org, numéro 2

Charles-Antoine Couret

Pour rappel, vous pouvez consulter l'état du travail en cours sur la documentation.

À cause des vacances et d'autres histoires personnelles, j'ai loupé le bilan d'août et j'ai moins contribué que la période juin-juillet. En cette rentrée, faisons quand même un bilan du travail abattu depuis deux mois.

Les sujets traités ont changé quelque peu. C'est plus centré autours des thématiques :

  • Les dépôts externes ;
  • La création de médias personnels et leur exploitation ;
  • L'usage serveur.

Personnellement je me suis occupé plutôt des deux premiers thèmes. Par exemple le dépôt de RPMFusion et les paquets multimédia qu'il propose sont un incontournable auprès des utilisateurs de Fedora. Il était important de s'y atteler car de nombreux paquets ont évolué, que ce soit des nouveaux venus, des évolutions majeures comme plus de codecs accessibles via mplayer ou GStreamer.

Concernant le deuxième point, il était nécessaire de revoir les procédures pour exploiter kickstart qui a évolué (notamment depuis l'apparition des Spins et des produits Server, Workstation et Cloud). Les moyens de télécharger Fedora ont changé, le Live CD a peu à peu laissé place au Live USB qui a été particulièrement mis en avant avec l'outil Fedora Media Writer. D'ailleurs l'installation d'un dual Boot avec Windows a aussi beaucoup évolué, car GRUB a changé avec sa version 2 ce qui a simplifié la procédure et Windows est aussi plus conciliant sur ce genre de cohabitation.

J'ai également rafraîchi la page d'aide pour contribuer à Fedora, car depuis le temps les sujets ont évolué, de nouvelles ressources ou secteurs ce sont développés comme l'assurance qualité et l'ajout aussi de la documentation francophone jusqu'ici absente.

Le dernier point a été particulièrement étudié par Nicolas, car Fedora a bien entendu un usage serveur important dont le paysage a changé. Outre MySQL devenu MariaDB, de nombreuses commandes ont changé avec lévolution des outils. Si lenvironnement web LAMP est surtout concerné, cela touche également SELinux, le serveur de courriel Dovecot et Openldap. Un énorme travail a été accomplis, donc merci à lui !

Je remercie également les autres contributeurs, relecteurs ou toute autres personnes qui se sont impliquées dans ce processus comme Édouard, Nicolas Chauvet, et d'autres.

Aujourd'hui donc, nous sommes à 42 articles traités, contre 25 au précédent bilan. Je suis satisfait des progrès réalisés sur la documentation. Il y a beaucoup de travail à mener encore, mais il semble possible que la documentation soit dans un état très acceptable d'ici Fedora 27 ou la fin de l'année 2017. Ensuite il faudra veiller à maintenir la documentation à jour continuellement et ajouter des articles suivant les besoins du moment.

Je vous invite en tout cas à nous donner un coup de main, pour cela je vous conseille de suivre la procédure pour contribuer à la documentation et si possible de participer à nos ateliers hebdomadaires tous les lundi soir à partir de 21h (heure de Paris) sur le canal IRC #fedora-doc-fr du serveur Freenode. Rien ne vous empêche de contribuer en dehors du cadre des ateliers, toute l'aide est la bienvenue. Alors, n'hésitez pas !

Petit bilan de Rawhide, épisode 5, septembre 2017

Charles-Antoine Couret

Je n'ai pas écrit de bilan de Rawhide en juin, juillet et août, l'approche de la version finale de Fedora 26 a amené trop peu de changements visibles pour que ce soit pertinent de les noter au départ puis j'ai manqué de temps pour traiter les avancées de Fedora 27.

Fedora 26 étant disponible depuis le 11 juillet, mon ordinateur personnel est repassé aussi tôt sur Fedora Rawhide qui est devenu il y a un mois Fedora 27 en devenir.

Fedora 27 Beta va d'ailleurs bientôt arriver, d'ici quelques semaines. Ce sera une première sans version Alpha préliminaire.

Changements

Dès le début GNOME 3.26 a des changements assez visibles. Je vous invite à lire les notes de versions pour plus de détails (et les illustrations). L'utilitaire gnome-tweak-tool a été remanié, les options sont plus nombreuses et le style de sélection ressemble à l'interface de GNOME Builder. Le centre de contrôle de GNOME a été également très modifié, avec une nouvelle organisation via cette barre latérale permanente et la refonte de nombreuses pages comme ce qui touche à l'affichage ou au réseau.

Je ne sais pas pourquoi mais la police par défaut de GNOME Terminal (police à chasse fixe) est Monospace Regular ce qui change bien entendu le rendu.

Quand les fenêtres dans GNOME sont rétrécies ou agrandies, il y a un nouvel effet visuel. Rien de sensationnel, mais c'est plutôt agréable sans pertes de performance dans la foulée j'ai l'impression. La barre de GNOME devient également transparente s'il n'y a pas de fenêtres maximisées.

Pendant quelques semaines, Empathy a également bénéficié de la refonte de son interface pour être plus homogène avec les autres applications GNOME en adoptant une interface proche de Polari. Mais cela était expérimental et l'interface habituelle a repli place. En espérant qu'il reviendra bientôt.

Et bien d'autres que je n'ai sans doute pas remarqué ou qui sont plus insignifiants.

Problèmes

Rawhide comporte bien évidemment de bogues. Même si des procédures doivent être mises en place durant ce cycle pour améliorer la qualité globale de cette branche de Fedora, des bogues importants resteront probablement présents.

En premier lieu, mon système de fichier /home chiffré avec LUKS n'était plus monté automatiquement. C'est plutôt gênant, on doit le faire à la main mais heureusement sans autres conséquences notamment en terme de cohérence des données. Heureusement corrigé depuis.

Un autre bogue, assez pénible, le sélecteur de fichier de GTK crashe. Donc dès qu'il faut choisir / ajouter un fichier dans un programme, l'application plante. Cela a été corrigé avant que je n'en fasse un rapport.

Firefox 55 a été oublié des mises à jour des paquets, à la base suite à des soucis pour le compiler puis par oubli du mainteneur. :-)" class="smiley

Sinon GNOME est très instable. La session se ferme régulièrement (toutes les heures presque) voire à certains moment comme à l'ouverture d'une machine virtuelle. Beaucoup de rapports de bogues tournent autours de ce sujet. Il semble que le composant gjs soit le fautif et une correction semble en cours. C'est rare que GNOME soit autant en difficulté et étant donné l'importance du sujet Fedora bloque l'évolution du cycle de F27 le temps que cela se calme.

PHP version 7.0.24RC1 et 7.1.10RC1

Remi Collet

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.1.10RC1 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 24-25 et Enterprise Linux.

Les RPM de PHP version 7.0.24RC1 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 25 ou remi-php70-test pour Fedora 24 et Enterprise Linux.

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

PHP Version 7.2 est en mode développement, la version 7.2.0RC2 est aussi disponible.

emblem-notice-24.pngInstallation : voir la Configuration du dépôt et choisir la version.

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

yum --enablerepo=remi-test install php70

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

yum --enablerepo=remi-test install php71

Mise à jour, de PHP 7.0 :

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

Mise à jour, de PHP 7.1:

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

A noter : la version 7.1.10RC1 est aussi disponible dans Fedora rawhide (pour la QA).

emblem-notice-24.pngLes paquets pour EL-7 on été construit à partir de RHEL-7.4.

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

Software Collections (php70, php71)

Paquets standards (php)

PHP version 7.0.23 et 7.1.9

Remi Collet

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

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

emblem-important-2-24.pngPHP version 5.5 a atteint sa fin de vie et n'est plus maintenu par le projet.

Ces versions sont aussi disponibles en Software Collections.

Pas de correctifs de sécurité ce mois ci, donc pas de mise à jour de la 5.6.31.

Annonces des versions :

emblem-notice-24.pngInstallation : 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.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

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

yum-config-manager --enable remi-php70
yum update

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

yum install php70

Et bientôt dans les mises à jour officielles:

emblem-important-2-24.pngÀ noter :

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

emblem-notice-24.pngInformations, lire :

Paquets de base (php)

Software Collections (php70 / php71)

PHP en route vers la sortie de la version 7.2.0

Remi Collet

La version 7.2.0RC1 vient juste d'être publiée. C'est maintenant la phase de stabilisation qui commence pour les développeurs, et de test pour les utilisateurs.

Les RPM sont disponibles dans le dépôt remi-php72 pour Fedora 25 et et Enterprise Linux 6 (RHEL, CentOS) ainsi qu'en Software Collection dans le dépôt remi-safe.

 

emblem-important-4-24.pngLe dépôt contient actuellement des versions en cours de développement qui ne sont pas destinées à être utilisées en production.

Lire aussi : PHP 7.2 en Software Collection

emblem-notice-24.pngInstallation : voir la Configuration du dépôt et choisir 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 php\*

Installation en parallèle, en Software Collection de PHP 7.2 (x86_64 uniquement, recommandée pour les tests) :

yum install php72

emblem-important-2-24.pngÀ noter :

  • la version EL7 est construite avec RHEL-7.3
  • la version EL6 est construite avec RHEL-6.9
  • beaucoup d'extensions sont aussi disponibles, voir la page PECL extension RPM status.
  • suivre les commentaires pour les mise à jour jusqu'à la version finale.

emblem-notice-24.pngInformations, lire :

Paquets de base (php)

Software Collections (php72)

Résultats des élections de Fedora 08/17

Charles-Antoine Couret

Comme je vous le rapportais il y a peu, Fedora a organisé des élections pour renouveler partiellement le collège de ses organes.

Le scrutin est comme toujours un vote par valeurs. Nous pouvons attribuer à chaque candidat un certain nombre de points, dont la valeur maximale est celui du nombre de candidat, et le minimum 0. Cela permet de montrer l'approbation à un candidat et la désapprobation d'un autre sans ambiguïté. Rien n'empêchant de voter pour deux candidats avec la même valeur.

Les résultats pour le Conseil sont (seul le premier est élu) :

  # votes |  noms
- --------+----------------------
     505  | Justin W. Flory (jwf / jflory7)
- --------+----------------------
     492  | Dennis Gilmore (dgilmore / ausil)
     433  | Till Maas (tyll / till)
     354  | Langdon White (langdon)
     320  | Nick Bebout (nb)

À titre indicatif le score maximal possible était de 5 * 178 (pour 178 votants) soit 890.

Les résultats pour le FESCo sont (seuls les quatre premiers sont élus) :

  # votes |  noms
- --------+----------------------
     458  | Dennis Gilmore (dgilmore / ausil)
     438  | Till Maas (tyll / till)
     431  | Stephen Gallagher (sgallagh/sgallagh)
     330  | Randy Barlow (bowlofeggs/bowlofeggs)
- --------+----------------------
     296  | Dominik Mierzejewski (Rathann/rathann)

À titre indicatif le score maximal possible était de 5 * 150 (pour 150 votants) soit 150.

Les résultats pour le FAmSCo sont donc (seuls les trois premiers sont élus) :

  # votes |  noms
- --------+----------------------
     613  | Nick Bebout (nb/nb)
     551  | Itamar Reis Peixoto (itamarjp/itamarjp)
     541  | Sumantro Mukherjee (sumantro / sumantrom)
- --------+----------------------
     523  | Alex Oviedo Solis (alexove/alexove)
     490  | Eduardo Echeverria (echevemaster/echevemaster)
     469  | Daniel Lara (danniel/Danniel)
     467  | Eduard Lucena (x3mboy)
     449  | Ben Williams (Southern_Gentlem/jbwillia)
     445  | Sirko Kemter (gnokii/gnokii)
     443  | Andrew Ward (award3535)

À titre d'indication, la valeur maximale possible est de 10 * 148 (car il y a eu 148 votants) soit 1480.

Nous pouvons noter que globalement le nombre de votants pour chaque scrutin était proche aux alentours de 175-150 votants.. Les scores sont aussi plutôt éparpillés, avec souvent quelques membres assez largement en tête de chaque scrutin.

Bravo aux participants et aux élus, que le projet Fedora avance. :-)" class="smiley

Page générée le 18 mai 2018 à 02:55