Aujourd'hui, ce vendredi 5 avril, est une journée dédiée à un test précis : sur Silverblue. 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 ?

Silverblue est le nom de code pour Fedora Workstation à la sauce Atomic. Jusque là seulement la variante Cloud en bénificiait.

L'objectif de cette version est de proposer en somme une Fedora Workstation ayant des bases différentes de la version traditionnelle. En effet, l'objectif est que les applications soient dans des conteneurs via Kubertenes, Flatpak ou gérées via rpm-os-tree. Ce dernier permet de versionniser le système lors des installations et mises à jour de paquets. En cas de problème, il est facile de demander un retour en arrière au système pour retrouver un système stable. Le système devient majoritairement en lecture seule également pour améliorer sa fiabilité et sa sécurité. Sécurité qui comme poun une Fedora traditionnelle est supervisée par SELinux.

Les tests à effecuer sont :

• Démarrer et se connecter sans erreurs ;
• Démarrer et arrêter des services comme le serveur SSH ;
• Vérifier que SELinux est bien activé ;
• Vérifier si GNOME Logiciels envoie des notifications de mises à jour ;
• Vérifier si GNOME Logiciels tourne correctement : installer ou supprimer des paquets ;
• Installer un logiciels sous forme de Flatpak.

Des tests qui sont pour le coup assez faciles et rapides à mettre en œuvre.

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 PHP version 7.3.4 sont disponibles dans le dépôt remi pour Fedora 30 et dans le dépôt remi-php73 pour Fedora 27-29 et Enterprise Linux ≥ 6 (RHEL, CentOS).

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

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

PHP version 5.6 et version 7.0 ont atteint leur fin de vie et ne sont plus maintenus par le projet PHP.

Ces versions sont aussi disponibles en Software Collections dans le dépôt remi-safe et en module pour Fedora 29-30 et EL-8-Beta.

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

Annonces des versions :

• PHP 7.3.4 Release Annoucement
• PHP 7.2.17 Release Annoucement
• PHP 7.1.28 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.3 (le plus simple) :

yum-config-manager --enable remi-php73
yum update

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

yum install php73

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 Collections de PHP 7.2 (x86_64 uniquement) :

yum install php72

Et bientôt dans les mises à jour officielles:

• Rawhide fournit désormais PHP 7.3.3
• Fedora 30 - PHP 7.3.4
• Fedora 29 - PHP 7.2.17
• Fedora 28 - PHP 7.2.17

À noter :

• la version EL-7 est construite avec RHEL-7.6
• la version EL-6 est construite avec RHEL-6.10
• la version EL-7 utilise désormais icu version 62.1 (au lieu de 50..1)
• beaucoup de nouvelles extensions sont aussi disponible, voir PECL extension RPM status page

Informations, lire :

• Migration de PHP 7.1.x à PHP 7.2.x
• Migration de PHP 7.2.x à PHP 7.3.x

Paquets de base (php)

Software Collections (php71 / php72 / php73)

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

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

La version finale est pour le moment fixée pour le 30 avril ou le 7 mai.

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

Expérience utilisateur

• Passage à GNOME 3.32 ;
• Les extensions du gestionnaire de fichier Nautilus migrent vers Python 3 ;
• Le bureau léger LxQt bénéficie de la mise à jour vers la version 0.14.0 ;
• Le nouvel environnement de bureau DeepinDE est proposé. Un bureau qui se veut moderne, performant, simple et élégant ;
• Encore un nouvel environnement, Pantheon Desktop qui débarque dans Fedora. C'est celui utilisé par elementaryOS, qui réutilise les technologies de GNOME mais est écrit plutôt en Vala et se veut plus proche de l'expérience utilisateur de macOS.
• GnuGPG 2 devient l'implémentation de GPG par défaut.

Gestion du matériel

• Pour les utilisateurs d'une carte graphique Intel, l'affichage durant le démarrage est continue, sans remise à zéro de ce dernier. Cela rend l'expérience plus fluide et jolie.
• Les architectures ARMv7 disposeront par défaut d'un démarrage en uEFI.

Internationalisation

• Les groupes de composition des langues sont remplacées par les langpacks. Ce dernier était utilisé depuis Fedora 24 pour installer les traductions des paquets nécessaires à l'utilisateur. Maintenant il gère également les entrées de saisie et les polices de caractères pour une expérience plus cohérente.

Administration système

• Mise à jour de Bash à la version 5.0 ;
• Le shell Fish évolue également à la version 3.0 ;
• L'outil Vagrant est à la version 2.2 maintenant ;
• DNF dispose de l'algorithme de compression zchunck en plus de xz ou gzip pour les métadonnées des dépôts ce qui permet la prise en charge des deltas pour optimiser la taille des téléchargements ;
• Par défaut les entrées de démarrage, pour choisir la version du noyau à lancer, va passer au format BootLoaderSpec par défaut. Permettant de ne plus employer grubby pour réaliser cette tâche car il est ancien et peu flexible. Le but est d'uniformiser la manière de représenter les noyaux à démarrer entre les architectures, car ils n'utilisent pas tous GRUB. Seule l'architecture ARMv7 n'est pas encore concernée, car u-boot ne gère pas ce format de représentation.
• cryptsetup utilise dorénavant les métadonnées de LUKS2 par défaut ;
• dbus-broker devient l'implémentation par défaut de DBus ;
• FreeIPA n'est plus utilisable avec Python 2 ;
• Suppression de beaucoup de paquets dépendants ou relatifs à Python 2, la fin approche et devrait se terminer pour Fedora 31 ;
• Le fichier /etc/sysconfig/nfs est maintenant obsolète en faveur de /etc/nfs.conf pour permettre la configuration depuis un point central en étant plus conforme à la manière dont les outils comme Ansible ou systemd traitent ce genre de configuration ;
• De nombreux outils sont dépréciés : Apache Avalon, Apache Jakarta Commons HTTP client, Apache Jakarta ORO and Regexp, Apache Maven branche 2.x et Sonatype OSS Parent. Ils ne sont en effet plus maintenus depuis un moment et cette étape permet la transition pour leur suppression définitive, avec les éventuels paquets qui en dépendent.
• MongoDB est supprimé, la licence nouvellement adoptée SSPL n'étant pas considérée comme libre ;
• En cas de connexion distante via SSH, l'information sur la langue à utiliser est toujours propagée du client vers le serveur pour la session en cours. Maintenant, si le serveur distant ne dispose pas de la langue cible, C.UTF-8 sera demandée.
• krb5 modernise son support des algorithmes crytpographiques en supprimant la gestion de DES, 3DES, crc-32, et MD4 pour les clés de session ou clés à long terme. MD5 et RC4 sont marqués comme obsolètes et dangereux en attendant une suppression ultérieurement.

Développement

• Mise à jour de GCC qui fait du 9 ;
• Glibc n'est pas en reste avec la version 2.29 ;
• Petit coup de Boost à la version 1.69 ;
• Les fonctions obsolètes et non sûres de libcrypt sont supprimées et encrypt, encrypt_r, setkey, setkeyr, and fcryp'' renvoient une erreur systématiquement ;
• Mise à jour de Ruby qui vaut 2.6 carats ;
• Les programmes Java pourront danser dans la machine virtuelle OpenJDK 12 ;
• Le langage de l'éléphant PHP impose sa version 7.3 ;
• Go avance à la version 1.12 ;
• L'environnement d'Erlang passe à la version 21 ;
• Alors que le compilateur Haskell GHC et Stackage LTS passent respectivement à la version 8.4 et 12 ;
• Les shebangs Python ambigües concernant la version de Python à employer génèrent des erreurs, #!/usr/bin/python devant devenir #!/usr/bin/python2 ou #!/usr/bin/python3 ;
• Python progressbar2 devient la version de référence pour le module des bar de progressions.

Projet Fedora

• L'environnement de compilation minimal ne dépend plus du paquet glibc-all-langpacks pour gagner en poids ;
• La compilation de modules Python dans Fedora sera plus proche de ce qui se fait en amont sans nécessiter de recourir à des outils tel que redhat-rpm-macros pour cela ;
• Pour ceux intéressés par le standard SWID, des drapeaux dans les paquets RPM ont été activés pour permettre leur traçabilité et faciliter leur mise en œuvre dans des dépôts ou lister les paquets correspondant à un drapeau par exemple via dnf.
• La compilation des programmes Python est en deuxième phase de réécriture pour reposer sur moins d'hypothèses, et ainsi être plus fiable et plus maintenable.
• Les drapeaux group des paquets sont supprimés pour près de 9600 d'entre eux. Depuis mars 2017 il ne fallait plus les utiliser. Maintenant c'est fait.
• L'édition de lien supprime tous les liens excessifs entre bibliothèques et les exécutables. Seules les fonctions réellement nécessaires sont liées, ce qui améliore les performances au lancement de l'application.
• Les scriptlets qui étaient obsolètes sont supprimés comme ldconfig afin de gagner du temps à l'installation des paquets et une génération des paquets plus rapide.
• Le projet améliore la façon d'avoir des statistiques sur l'utilisation de Fedora. Actuellement le tout reposait sur la collecte de données via les mirroirs pour connaître le nombre d'installation en vigueur ce qui n'était pas fiable. Pour éviter cela, chaque requête tous les 7 jours vers un dépôt officiel sera enregistrée par machine. Cela évitera les problèmes liés à la vie privée.
• Activation de Python Generators par défaut. Ceci est la généralisation de la nouveauté de Fedora 28. Ainsi un empaqueteur n'a plus à spécifier dans le paquet RPM les dépendances Python nécessaires à l'exécution du paquet. Et l'utilisateur ne se retrouvera pas avec une erreur en cas d'oubli de la dite dépendance car résolue en amont.

Tester

Durant le développement d'une nouvelle Fedora, comme cette version Beta, quasiment chaque semaine le projet propose des journées de tests. Le but est pendant une journée de tester une fonctionnalité précise comme le noyau, Fedora Silverblue, la mise à niveau, GNOME, linternationalisation, etc. L'équipe de qualité élabore et propose une série de tests en général simples à exécuter. Suffit de les suivre et indiquer si le résultat est celui indiqué. Dans le cas contraire, un bogue devra être ouvert pour permettre l'élaboration d'un correctif.

C'est très simple à suivre et requiert souvent peu de temps (15 minutes à une heure maximum) si vous avez une Beta exploitable sous la main.

Les tests à effectuer et les rapports sont à faire via la page suivante. https://blog.fedora-fr.org/renault/ J'annonce régulièrement sur mon blog quand une journée de tests est planifiée.

Si l'aventure vous intéresse, les images sont disponibles par Torrent ou via https://getfedora.org/ le site officiel. En cas de bogue, n'oubliez pas de relire la documentation pour signaler les ... ou de https://fedora.zanata.org/?dswid=-957 contribuer à la traduction sur Zanata.

Bons tests à tous !

Aujourd'hui, ce mardi 26 mars 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 comme 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 ;
• Mettre à jour un 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 versions Release Candidate sont disponibles dans le dépôt de 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.3.4RC1 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 30 ou remi-php73-test pour Fedora 27-29 et Enterprise Linux.

Les RPM de PHP version 7.2.17RC1 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 28-29 ou remi-php72-test pour Fedora 27 et Enterprise Linux.

PHP version 7.1 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.3 :

yum --enablerepo=remi-test install php73

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

yum --enablerepo=remi-test install php72

Mise à jour, de PHP 7.3 :

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

Mise à jour, de PHP 7.2:

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

A noter : la version 7.3.4RC1 dans Fedora rawhide pour la QA

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

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

Software Collections (php72, php73)

Paquets standards (php)

Bien que développeur, je passe désormais la majeur partie de mon temps à faire de la QA (assurance qualité) sur les projets autour de PHP.

Voici à travers la sortie des versions 7.2.17RC1 et 7.3.4RC1 un rapport permettant de mieux comprendre cette activité.

1. Présentation

Normalement, les tests sont assurés par les développeurs de PHP, notamment grâce à travis et ensuite pas les utilisateurs qui installeront les versions RC mise à disposition 2 semaines avec la version GA.

Le projet PHP suit un processus de version (cf README.RELEASE_PROCESS) qui prévoit 2 jours entre la préparation de la version, sur git le mardi, et son annonce le jeudi sur les listes de diffusions. Ces 2 jours sont notamment prévus pour permettre de préparer les paquets binaires (surtout Microsoft et souvent mon dépôt) et faire une dernière passe de QA qui peut permettre de détecter un problème tardif.

Dès que la version a été mise à disposition (mardi), j'ai commencé à lancé la construction des paquets pour mon dépôt, ce qui permet de couvrir plus de cas que la configuration actuelle de travis

• Fedora 27 à 31
• RHEL 6, 7 et 8-Beta
• i386 et x86_64
• NTS et ZTS
• nombreuses versions du compilateur (GCC 4 à 9) et des bibliothèques systèmes

J'ai aussi lancé la construction du paquet 7.3.4RC1 dans Fedora rawhide afin de déclencher la reconstruction de toute la pile PHP dans Koschei, un des outils de CI de Fedora.

Note : le temps de construction pour l'ensemble des cibles et d'environ 3h par version !  (j'ai vraiment besoin d'une machine plus puissante)

2. Problèmes découverts

2.1. Tests échoués avec pcre2 version 10.33RC1

Déjà disponible dans rawhide, cette version apporte une modification de certains messages d'erreur, provoquant un échec de 2 tests.

Problème mineur, corrigé dans PHP 7.3+ : changement c421d9a.

2.2. Tests échouées en 32 bits

Suite à la correction du bug #76117 la sortie de var_export a changée, entrainant un echec que 2 tests.

Après confirmation par l'auteur de la modification, les tests ont été corrigés dans PHP 7.2+ : changements a467a89 et 5c8d69b.

2.3. Regression

Koschei a permis de détecter très rapidement une régression important dans lexécution de "make test". Après recherche, cette régression a été introduite par la correction du bug #77609, voir les commentaires sur le changement 3ead672.

Suite à discussion entre les responsables de version (Release Managers) il a été décidé

• de supprimer ce changement pour revenir sur une situation saine
• de relancer le processus de publication (nouveau tag sur git)

Le version qui sera bientôt annoncée ne sera donc pas affectée par cette régression.

3. Conclusion

S'assurer de la qualité de PHP, et de l'absence de régression est un travail complexe, long et sérieux. Grâce à l'ensemble des acteurs, développeurs, équipe QA et utilisateurs cela fonctionne plutôt bien.

Si vous utilisez PHP dans un environnement de développement, il est donc essentiel de penser à installer les versions RC pour nous signaler rapidement tout problème, afin que nous puissions réagir avant la version finale..

Pour les utilisateurs de mon dépôt, les versions RC sont presque toujours disponibles dans les dépôts de test.

Aujourd'hui, ce mardi 19 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 dépendances des paquets de langue pour installer les polices et les entrées de saisie nécessaires.

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

Le samedi 9 février 2019 a eu lieu l'Assemblée Générale de l'association Borsalinux-fr à la Fondation pour le Progrès de l'Homme à Paris.

Les 10 membres présents ou représentés ont approuvé le bilan moral et financier de l'année 2018.

Par la suite, un 7e Conseil d'administration a été élu et est composé de :

-Charles-Antoine Couret (Renault) - Président

-Guillaume Kulakowski (llaumgui) - Vice-président

-Nicolas Chauvet (kwizart) - Trésorier

-Côme Borsoi - Trésorier adjoint

-Kévin Vaufleury - Secrétaire

Ce conseil a un mandat de 2 ans.

Projets pour la suite

Goodies

Charles-Antoine doit passer commande pour les flyers. Il soumettra à nouveau la proposition au nouveau Conseil dAdministration.

Clément a lancé le sujet pour savoir où nous en étions et sur ce quon pourrait faire. Il pense que les clés USB avec une personnalisation visuelle en plus dune image préinstallée dessus serait une bonne idée. Dans lensemble la discussion semblait favorable à lidée, que cela devrait être possible de le faire à coût abordable avec la capacité nécessaire évaluée à 4-8 Gio idéalement. Il prend en charge le dossier pour réaliser prochainement un devis.

Emmanuel a rappelé lexistence du projet Fedorator, porté par des ambassadeurs du projet Fedora à létranger.

Clément a souligné que la Braderie de Lille avait changé ces dernières années et quil était possible que ce soit difficile dy présenter quelque chose.

Association

Lidée de maintenir un inventaire de lensemble du matériel de lassociation, que ce soit les goodies tout comme le matériel de stand, a été remis sur la table. Charles-Antoine sest engagé à prendre le sujet en main.

Emmanuel précise quil a le kakemono chez lui, et que la nappe est probablement à la Cité des sciences et quil ira vérifier prochainement.

Site web

Emmanuel a soumis lidée davoir une carte géographique des membres, sils sont daccord, qui permettrait à des membres du site de plus facilement localiser ceux qui sont proches de chez eux pour se rencontrer. Cela a été accueilli favorablement, Guillaume précise quune changement de linfra du forum sera nécessaire avant.

Guillaume précise son rêve de mettre à jour le forum mais le logiciel adéquat n'est pas encore disponible. Étant donné que la situation perdure, lidée de migrer vers une autre plateforme technique semble envisagé. Dans ce cas il demandera à la communauté une assistance pour cette tâche qui sannoncerait lourde.

Le PV complet de l'Assemblée Générale est disponible ici.

Aujourd'hui, ce mercredi 13 mars est une journée dédiée à un test précis : sur l'édition Internet des objets. 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 ?

L'Internet des objets est un ensemble d'objets connectés qui peuvent servir à collecter et traiter des données sur des appareils très diversifiés, souvent ayant de faibles ressources. L'objectif de cette nouvelle édition de Fedora est de proposer une plateforme libre intégrant les dernières technologies tout en étant un environnement connu de ses utilisateurs.

La particularité de cette édition est qu'elle est en mode rolling release avec de nouvelles images générées chaque mois. Le but étant de favoriser un écosystème qui soit le plus à jour possible.

D'un point de vue technique, cette édition repose sur rpm-ostree pour améliorer la fiabilité du système en cas de mise à jour. Cela rejoint le mécanisme déjà en œuvre pour Fedora Silverblue ou Atomic.

Les tests du jour couvrent :

• L'installation et la mise en route ;
• Le fonctionnement de rpm-ostree ;
• Le déploiement d'images ARM ;
• Le démarrage via PXE ;
• Installation sur un disque dur ou un SSD via SATA ;
• La manipulation des services de base.

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 12 mars, est une journée dédiée à un test précis : sur le noyau Linux 5.0. 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. Notons par ailleurs que l'équipe des mainteneurs du noyau chez Fedora ont décidé de faire une journée de tests systématique après la sortie d'un nouveau noyau !

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

Les RPM de PHP version 7.3.3 sont disponibles dans le dépôt remi pour Fedora 30 et dans le dépôt remi-php73 pour Fedora 27-29 et Enterprise Linux ≥ 6 (RHEL, CentOS).

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

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

PHP version 5.6 et version 7.0 ont atteint leur fin de vie et ne sont plus maintenus par le projet PHP.

Ces versions sont aussi disponibles en Software Collections dans le dépôt remi-safe et en module pour Fedora 29-30 et EL-8-Beta.

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

Annonces des versions :

• PHP 7.3.3 Release Annoucement
• PHP 7.2.16 Release Annoucement
• PHP 7.1.27 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.3 (le plus simple) :

yum-config-manager --enable remi-php73
yum update

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

yum install php73

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 Collections de PHP 7.2 (x86_64 uniquement) :

yum install php72

Et bientôt dans les mises à jour officielles:

• Rawhide fournit désormais PHP 7.3.3
• Fedora 30 - PHP 7.3.3
• Fedora 29 - PHP 7.2.15
• Fedora 28 - PHP 7.2.15

À noter :

• la version EL-7 est construite avec RHEL-7.6
• la version EL-6 est construite avec RHEL-6.10
• la version EL-7 utilise désormais icu version 62.1 (au lieu de 50..1)
• beaucoup de nouvelles extensions sont aussi disponible, voir PECL extension RPM status page

Informations, lire :

• Migration de PHP 7.1.x à PHP 7.2.x
• Migration de PHP 7.2.x à PHP 7.3.x

Paquets de base (php)

Software Collections (php71 / php72 / php73)

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.3.3RC1 sont disponibles en SCL dans le dépôt remi-test et les paquets de base dans le dépôt remi-php73-test pour Fedora 27-29 et Enterprise Linux.

Les RPM de PHP version 7.2.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 28-29 ou remi-php72-test pour Fedora 26-27 et Enterprise Linux.

Sous RHEL / CentOS 7 l'extension intl utilise désormais libicu version 62.1 (au lieu de 50.1). Vos retours sont les bienvenus.

PHP version 7.1 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.3 :

yum --enablerepo=remi-test install php73

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

yum --enablerepo=remi-test install php72

Mise à jour, de PHP 7.3 :

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

Mise à jour, de PHP 7.2:

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

A noter : la version 7.3.2RC1 dans Fedora rawhide pour la QA

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

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

Software Collections (php72, php73)

Paquets standards (php)

Après pas mal d’efforts et surtout de tests, la version 1.2.0 du plugin ZiGate pour Jeedom vient de sortir. Parmi les nombreuses nouveautés, on remarquera : Des corrections de bugs en tout genre. Le support de nouveaux périphériques. L’identifiant unique d’un équipement Jeedom (LogicalId) passe de l’adresse (ADDR) à l’IEEE. L’idée et d’assurer un identifiant […]

Cet article Plugin ZiGate pour Jeedom v1.2.0 est apparu en premier sur Guillaume Kulakowski's blog.

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

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

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

PHP version 5.6 et version 7.0 ont atteint leur fin de vie et ne sont plus maintenus par le projet PHP.

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

Annonces des versions :

• PHP 7.3.2 Release Annoucement
• PHP 7.2.15 Release Annoucement

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.3 (le plus simple) :

yum-config-manager --enable remi-php73
yum update

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

yum install php73

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 Collections de PHP 7.2 (x86_64 uniquement) :

yum install php72

Et bientôt dans les mises à jour officielles:

• Rawhide fournit désormais PHP 7.3.2
• Fedora 29 - PHP 7.2.15
• Fedora 28 - PHP 7.2.15

À noter :

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

Informations, lire :

• Migration de PHP 7.1.x à PHP 7.2.x
• Migration de PHP 7.2.x à PHP 7.3.x

Paquets de base (php)

Software Collections (php72 / php73)

Après PHP 7.0, et comme annoncé, PHP version 5.6.40 était la dernière version officielle de PHP 5.6

Ce qui signifie qu'après la publication des versions 7.2.15, et 7.3.2, quelques failles de sécurité publiques ne sont pas, et ne seront pas corrigées par le projet PHP.

Pour maintenir une installation sécurisée, la mise à jour vers une version maintenue est fortement conseillée :

• PHP 7.2 est en mode maintenance active, et sera maitenu jusqu'en décembre 2019 (2020 pour la sécurité).
• PHP 7.3 est en mode maintenance active, et sera maitenu jusqu'en décembre 2020 (2021 pour la sécurité).

Voir :

• PHP Supported versions
• Guide de Migration de PHP 5.6.x à PHP 7.0.x
• Guide de Migration de PHP 7.0.x à PHP 7.1.x
• Guide de Migration de PHP 7.1.x à PHP 7.2.x
• Guide de Migration de PHP 7.2.x à PHP 7.3.x

Cependant, compte tenu du nombre important de téléchargements par les utilisateurs de mon dépôt (>30%)  la version présente dans le dépôt remi pour Enterprise Linux (RHEL, CentOS...) et Fedora (Software Collections) est conservée et intègrera les derniers correctifs de sécurité.

Attention : il s'agit d'un action réalisée avec la meilleure volonté, en fonction de mon temps disponible, sans aucune garantie, afin de donner plus de temps aux utilisateurs pour migrer. Cela ne peut être que temporaire et la migration doit rester la priorité.

Depuis Fedora 20, la livrée du système par défaut contient quelques fonds d'écrans additionnels. Et comme d'habitude, les contributeurs pouvaient soumettre leurs propres dessins ou photographies pour décorer cette nouvelle version.

Maintenant que la période de soumission s'est achevée, nous passons à la phase de vote. Tout possesseur d'un compte FAS peut en sélectionner 16 parmi les dizaines qui sont disponibles. Les plus populaires seront bien évidemment choisis et disponibles dans la Fedora 30 à sa sortie.

Le vote se déroule dans l'application Nuancier jusqu'au 25 février !

Pour ceux que cela intéresse, le badge associé à cette action nécessite une action manuelle. Il suffit de cliquer sur un lien, proposé sur la page après le vote.

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

Documentation :

• PHPUnit manual
• Release Announcement for version 8 of PHPUnit (en anglais)
• Changes in PHPUnit 8.0 (en anglais)

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

Installation, Fedora :

dnf --enablerepo=remi install phpunit8

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 prochaine disponible dans Fedora, dès que les nouveaux paquets seront approvés (revues #1671662, #1671663 et #1671665).

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.3.2RC1 sont disponibles en SCL dans le dépôt remi-test et les paquets de base dans le dépôt remi-php73-test pour Fedora 27-29 et Enterprise Linux.

Les RPM de PHP version 7.2.15RC1 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 28-29 ou remi-php72-test pour Fedora 26-27 et Enterprise Linux.

PHP version 7.1 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.3 :

yum --enablerepo=remi-test install php73

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

yum --enablerepo=remi-test install php72

Mise à jour, de PHP 7.3 :

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

Mise à jour, de PHP 7.2:

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

A noter : la version 7.3.2RC1 dans Fedora rawhide pour la QA

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

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

Software Collections (php72, php73)

Paquets standards (php)

Salut.

Voici les résultats comparatifs de Fedora 29 vs Fedora 28.

Pour rappel, ma machine est équipée d'un Quad Core Intel Q6600 à 2,4 GHz avec 4 Go de RAM.

Je me suis limité au benchmark UnixBench qui fournit un indice global, ce qui me simplifiera la comparaison. La version UnixBench utilisée est la version 4.1.0.

• Installation de Fedora 29 version 64 bits avec le noyau Fedora  4.18.16-300.fc29.x86_64.
• La machine est placée en niveau 3 (init 3).
• 10 séries de tests avec UnixBench compilé sous Fedora 29 et exécuté sous Fedora 29 (4.18.16-300.fc29.x86_64).
• 10 séries de tests avec UnixBench compilé sous Fedora 28 et exécuté sous Fedora 28 (4.16.3-301.fc28.x86_64).

Résultats :

Pour Fedora 29, on obtient un indice moyen de 622,1 pour UnixBench.
Pour Fedora 28, j'avais obtenu un indice moyen de 636,9 pour UnixBench.


On a donc une baisse de 2,3 % de Fedora 29 64 bits par rapport à Fedora 28 64 bits :

Conclusion :

Au moment de ces tests, le noyau Fedora 29 (basé sur le noyau vanilla 4.18.16) est un peu moins performant de 2 % que le noyau Fedora 28 (basé sur le noyau vanilla 4.16.3).

Installation :

# dnf install perl-Gtk3
# dnf install perl-Clone
# dnf install http://kadionik.vvv.enseirb-matmeca.fr/fedora/eddy33-release-29.rpm
# dnf install auto-multiple-choice