Fedora-Fr - Communauté francophone Fedora - Linux

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

Lire l'annonce officielle : Deuxième Release Candidate de GLPI 9.3

Attention: il ne s'agit pas encore d'une version stable, l'utilisation en production est déconseillée.

Attention: cette version nécesiite un version de MySQL ≥ 5.6 ou de MariaDB ≥ 10, et ne fonctionne donc pas avec la version par défaut sour RHEL / CentOS. Je vous recommande d'utiliser la Software Collection rh-mariadb102.

Toutes les extensions ne sont encore publiées en version compatible.

Actuellement dans le dépôt :

• glpi-9.3.0~RC2-1-1
• glpi-data-injection-2.5.2-2
• glpi-reports-1.11.3-2
• glpi-webservices-1.8.0-2

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 devez commencer par installation une version de PHP ≥ 5.6 en suivant les instructions de l'assistant (installation en Single version), puis

Sous RHEL oou CentOS :

yum-config-manager --enable remi-glpi93
yum install glpi

Fedora :

yum-config-manager --enable remi-glpi93
yum install glpi

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

• Forum GLPI
• Forum Assistance utilisateur pour les questions spécifiques aux RPM.

Aujourd'hui, ce mardi 12 juin, est une journée dédiée à un test précis : sur le noyau Linux 4.17. 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é.

Salut.

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

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 28 version 64 bits avec le noyau Fedora 4.13.9-300.fc27.x86_64.
• La machine est placée en niveau 3 (init 3).
• 10 séries de tests avec UnixBench compilé sous Fedora 28 et exécuté sous Fedora 28 (4.16.3-301.fc28.x86_64).
• 10 séries de tests avec UnixBench compilé sous Fedora 27 et exécuté sous Fedora 27 (4.13.9-300.fc27.x86_64).

Résultats :

Pour Fedora 28, on obtient un indice moyen de 636,9 pour UnixBench.
Pour Fedora 27, j'avais obtenu un indice moyen de 990,7 pour UnixBench.


On a donc une baisse de 35,7 % de Fedora 28 64 bits par rapport à Fedora 27 64 bits :

Conclusion :

Au moment de ces tests, le noyau Fedora 28 (basé sur le noyau vanilla 4.16.3) est nettement moins performant que le noyau Fedora 27 (basé sur le noyau vanilla 4.13.9). Si l'on regarde les différences entre les 2 versions, on s'aperçoit que les indices sur les copies de fichier, le débit dans un pipe et l'overhead sur un appel système sont nettement moins bons pour Fedora 28 que Fedora 27. A suivre...

La version 7.3.0 Alpha1 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 de cette  prochaine version de PHP 7.3, sont disponibles dans le dépôt remi pour Fedora 27, 28 et Enterprise Linux 6, 7 (RHEL, CentOS, ...) dans une nouvelle Software Collection (php73) permettant son installation en parallèle de la version système.

Comme je crois fortement au potentiel des SCL pour fournir un moyen simple d'installer plusieurs versions en parallèle, et qu'il me semble utile d'offrir cette possibilité pour PHP 7.3 afin de permettre aux développeurs de tester leur application, aux sysadmin de préparer une migration, ou simplement d'utiliser cette version pour une application spécifique, j'ai décidé de créer cette nouvelle SCL.

Je prévois aussi de proposer cette version pour Fedora 30 (F29 sera publié quelques semaines avant PHP 7.3.0).

Installation :

yum install php73

A noter :

• la SCL est totalement indépendante du système, et ne le modifie pas
• cette SCL est dans le dépôt remi-safe (dans le dépôt remi pour Fedora)
• l'installation est dans le dossier /opt/remi/php73, la configuration dans le dossier /etc/opt/remi/php73
• le module pour Apache, php73-php, est disponible, mais évidement un seul mod_php peut être utiliser (il faudrait donc désactiver ou désinstaller tout autre module afin de l'utiliser, celui fournit par le paquet "php" reste prioritaire)
• le service FPM (php72-php-fpm) est disponible, il écoute par défaut sur le port 9000, il faudrait donc adapter la configuration si vous souhaitez utiliser plusieurs services FPM en même temps.
• la commande php73 permet d'accéder simplement à cette version, cependant l'utilisation de la commande scl reste la meilleure méthode (ou module)
• Il s'agit pour l'instant de la version 7.3.0alpha1, mais les versions alpha/beta/RC devrait être disponibles dans les prochaines semaines.
• quelques extensions PECL seront bientôt disponibles, voir la page status des extensions
• seulement pour  x86_64, pas de plan pour les autres architectures.

Lire aussi les autres articles concernant les SCL, notamment la description de Ma station de travail PHP.

$ module load php72
$ php --version
PHP 7.3.0alpha1 (cli) (built: Jun  6 2018 08:00:17) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.0-dev, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.3.0alpha1, Copyright (c) 1999-2018, by Zend Technologies

Comme d'habitude, vos retours sont les bienvenus, un forum dédié aux SCL est ouvert.

Software Collections (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.2.7RC1 sont disponibles en SCL dans le dépôt remi-test et les paquets de base dans le dépôt remi-php72-test pour Fedora 25-27 et Enterprise Linux.

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

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

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

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

yum --enablerepo=remi-test install php72

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

yum --enablerepo=remi-test install php71

Mise à jour, de PHP 7.2 :

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

Mise à jour, de PHP 7.1:

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

A noter : la version 7.2.7RC1 est aussi disponible dans Fedora rawhide pour la QA.

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

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

Software Collections (php71, php72)

Paquets standards (php)

Après les élections du Mindshare et du Council qui se sont conclues cette nuit, voici le tour du FESCo douvrir sa période de vote aujourdhui pour une semaine aussi.

Chaque candidat a bien sûr un programme et un passif qu'ils souhaitent mettre en avant durant leur mandat pour orienter le projet Fedora dans certaines directions. Je vous invite à étudier les propositions des différents candidats pour cela.

Pour voter, il est nécessaire d'avoir un compte FAS actif et de faire son choix sur le site du scrutin. Vous avez jusqu'au jeudi 13 juin à 2h heure française pour le faire. Donc n'attendez pas trop.

FESCo

Le FESCo (Fedora Engineering Steering Committee) est un conseil entièrement composé de membres élus et totalement dévoués à l'aspect technique du projet Fedora.

Ils vont donc traiter en particulier les points suivants :

• Les nouvelles fonctionnalités de la distribution ;
• Les sponsors pour le rôle d'empaqueteur (ceux qui pourront donc superviser un débutant) ;
• La création et la gestion des SIGs (Special Interest Group) pour organiser des équipes autour de certaines thématiques ;
• La procédure d'empaquetage des paquets.

Le responsable de ce groupe est tournant. Les 9 membres sont élus pour un an, sachant que chaque élection renouvelle la moitié du collège.

Histoire de garder ça sous le coude et de le partager, voici un pense bête sur comment uploader un package sur PyPi.org. Les prérequis Se créer un compte sur PyPi, mais également sur l’index de test. L’index de test permet de tester avant de pousser en production… Personnellement j’y ai le même login mais pas […]

Cet article Uploader un package sur PyPi est apparu en premier sur Guillaume Kulakowski's blog.

Désormais, il existe un dépôt dédié pour chaque version de GLPI

Jusqu'à présent GLPI 9.1 était dans le dépôt "remi" et GLPI 9.2 dans le dépôts "remi-test", ce qui n'a plus de sens, puisque la version 9.2 est stable et que la plupart des plugins sont compatibles.

J'aurais pu déplacer la 9.2 dans "remi" et commencer à pousser les paquets de la prochaine 9.3 dans "remi-test", mais je préfère laisser le choix à l'utilisateur de monter de version à son rythme.

Nous avons donc désormais 3 dépôts

• remi-glpi91 pour GLPI 9.1, l'ancienne version stable (dépréciée)
• remi-glpi92 pour GLPI 9.2, la version stable actuelle (recommandée)
• remi-glpi93 pour GLPI 9.3, la version en cours de développement (vide actuellement)

Il suffit donc d'activer le dépôt correspondant à la version souhaitée

Sous RHEL et Centos

    yum-config-manager --enable remi-glpi92

Sous Fedora

    dnf config-manager --set-enabled remi-glpi92

En espérant que cette amélioration satisfera tout le mode.

Salut.

Voici les résultats comparatifs de Fedora 27 vs Fedora 26.

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 27 version 64 bits avec le noyau Fedora 4.13.9-300.fc27.x86_64.
• La machine est placée en niveau 3 (init 3).
• 10 séries de tests avec UnixBench compilé sous Fedora 27 et exécuté sous Fedora 27 (4.13.9-300.fc27.x86_64).
• 10 séries de tests avec UnixBench compilé sous Fedora 26 et exécuté sous Fedora 26 (4.11.8-300.fc26.x86_64).

Série 2 : 986.1
Série 3 : 886.1
Série 4 : 976.2
Série 5 : 970.3
Série 6 : 982.4
Série 7 : 972.3
Série 8 : 981.0
Série 9 : 998.7
Série 10 : 973.2

Moyenne : 967,8

Résultats :

Pour Fedora 27, on obtient un indice moyen de 990,7 pour UnixBench.
Pour Fedora 26, j'avais obtenu un indice moyen de 967,8 pour UnixBench.


On a donc une augmentation de 2,4 % de Fedora 27 64 bits par rapport à Fedora 26 64 bits :

Conclusion :

Au moment de ces tests, le noyau Fedora 27 (basé sur le noyau vanilla 4.13.9) est un peu plus performant de 2 % que le noyau Fedora 26 (basé sur le noyau vanilla 4.11.8).

Les RPM de PHPUnit version 7.2 sont disponibles dans le dépôt remi pour Fedora ≥ 26.

Documentation :

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

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

Cette nouvelle version n'est disponible que pour Fedora car il faudrait monter la dépendance  global du dépôt de 5.6 vers 7.1, ce que je prévois pour l'an prochain lorsque 5.6 et 7.0 seront en fin de vie.

Installation, Fedora :

dnf --enablerepo=remi install phpunit7

Installation, Enterprise Linux :

yum --enablerepo=remi install phpunit7

Remarque: cet outil est une pièce essentielle de la QA PHP dans Fedora. Cette version sera rapidement disponible dans Fedora 28, dès que la revue #1583468 sera approuvée.

C'est en ce vendredi 1er juin 2018 que Fedora 26 a été déclaré comme en fin de vie.

Qu'est-ce que c'est ?

Un mois après la sortie d'une version de Fedora n, ici Fedora 28, la version n-2 (donc Fedora 26) est déclarée comme en fin de vie. Ce mois sert à donner du temps aux utilisateurs pour faire la mise à niveau. Ce qui fait qu'en moyenne une version est officiellement maintenue pendant 13 mois. Mais comme nous pouvons le voir, cela ne reste qu'une moyenne. Fedora 26 étant sortie tardivement (juillet 2017) il n'aura eu une maintenance que de 10 mois et demi !

En effet, la fin de vie d'une version signifie qu'elle n'aura plus de mises à jour et plus aucun bogue ne sera corrigé. Pour des questions de sécurité, avec des failles non corrigées, il est vivement conseillé aux utilisateurs de Fedora 26 et antérieurs d'effectuer la mise à niveau vers Fedora 28 ou 27.

Que faire ?

Si vous êtes concernés, il est nécessaire de faire la mise à niveau de vos systèmes. Vous pouvez télécharger des images CD ou USB plus récentes.

Il est également possible de faire la mise à niveau sans réinstaller via DNF ou GNOME Logiciels.

GNOME Logiciels a également dû vous prévenir par une pop-up de la disponibilité de Fedora 27 ou 28. N'hésitez pas à lancer la mise à niveau par ce biais.

Mise à jour :

# dnf update auto-multiple-choice

Salut.

Suite à mon billet sur la fin de mes tests de Fedora 32 bits avec la version 25, je repars donc avec les tests de Fedora 26 version 64 bits. Pour cette première fois, il n'y a pas de comparaison avec une autre version de Fedora.

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 26 version 64 bits avec le noyau Fedora 4.11.8-300.fc26.x86_64.
• La machine est placée en niveau 3 (init 3).
• 10 séries de tests avec UnixBench compilé sous Fedora 26 et exécuté sous Fedora 26 (4.11.8-300.fc26.x86_64).

Comme le projet Fedora est communautaire, une partie du collège des organisations suivantes doit être renouvelée : Council et Mindshare. Et ce sont les contributeurs qui décident. Exceptionnellement, le collège du FESCo ne sera pas partiellement renouvelé en même temps, faute de candidatures la fenêtre de dépôts de candidatures a été élargi pour cet organe.

Chaque candidat a bien sûr un programme et un passif qu'ils souhaitent mettre en avant durant leur mandat pour orienter le projet Fedora dans certaines directions. Je vous invite à étudier les propositions des différents candidats pour cela.

Pour voter, il est nécessaire d'avoir un compte FAS actif et de faire son choix sur le site du scrutin. Vous avez jusqu'au mercredi 6 juin à 2h heure française pour le faire. Donc n'attendez pas trop.

Je vais profiter de l'occasion pour résumer le rôle de chacun de ces comités afin de clarifier l'aspect décisionnel du projet Fedora mais aussi visualiser le caractère communautaire de celui-ci.

Council

Le Council est ce qu'on pourrait qualifier le grand conseil du projet. C'est donc l'organe décisionnaire le plus élevé de Fedora. Le conseil définit les objectifs à long terme du projet Fedora et participe à l'organisation de celui-ci pour y parvenir. Cela se fait notamment par le biais de discussions ouvertes et transparentes vis à vis de la communauté.

Mais il gère également l'aspect financier. Cela concerne notamment les budgets alloués pour organiser les évènements, produire les goodies, ou des initiatives permettant de remplir les dits objectifs. Ils ont enfin la charge de régler les conflits personnels importants au sein du projet, tout comme les aspects légaux liés à la marque Fedora.

Les rôles au sein du conseil sont complexes.

Ceux avec droit de vote complet

Tout d'abord il y a le FPL (Fedora Project Leader) qui est le dirigeant du conseil et de facto le représentant du projet. Son rôle est lié à la tenue de l'agenda et des discussions du conseil, mais aussi de représenter le projet Fedora dans son ensemble. Il doit également servir à dégager un consensus au cours des débats. Ce rôle est tenu par un employé de Red Hat et est choisi avec le consentement du conseil en question.

Il y a aussi le FCAIC (Fedora Community Action and Impact Coordinator) qui fait le lien entre la communauté et l'entreprise Red Hat pour faciliter et encourager la coopération. Comme pour le FPL, c'est un employé de Red Hat qui occupe cette position avec l'approbation du conseil.

Il y a deux places destinées à la représentation technique et à la représentation plus marketing / ambassadrice du projet. Ces deux places découlent d'une nomination décidée au sein des organes dédiées à ces activités : le FESCo et le Mindshare. Ces places sont communautaires mais ce sont uniquement ces comités qui décident des attributions.

Il reste deux places communautaires totalement ouvertes et dont tout le monde peut soumettre sa candidature ou voter. Cela permet de représenter les autres secteurs d'activité comme la traduction ou la documentation mais aussi la voix communautaire au sens la plus large possible. C'est pour ces places que le vote est ouvert cette semaine !

Ceux avec le droit de vote partiel

Un conseiller en diversité est nommé par le FPL avec le soutien du conseil pour favoriser l'intégration au sein du projet des populations le plus souvent discriminées. Son objectif est donc de déterminer les programmes pour régler cette problématique et résoudre les conflits associés qui peuvent se présenter.

Un gestionnaire du programme Fedora qui s'occupe du planning des différentes versions de Fedora. Il s'assure du bon respect des délais, du suivi des fonctionnalités et des cycles de tests. Il fait également office de secrétaire du conseil. C'est un employé de Red Hat qui occupe ce rôle toujours avec l'approbation du conseil.

Mindshare

Mindshare est une évolution du FAmSCo (Fedora Ambassadors Steering Committee) qu'il remplace. Il est l'équivalent du FESCo sur l'aspect plus humain du projet. Pendant que le FESCo se préoccupera beaucoup plus des empaqueteurs, la préoccupation de ce conseil est plutôt l'ambassadeur et les nouveaux contributeurs.

Voici un exemple des thèmes dont il a compétence qui viennent du FAmSCo :

• Gérer l'accroissement des ambassadeurs à travers le mentoring ;
• Pousser à la création et au développement des communautés plus locales comme la communauté française par exemple ;
• Réaliser le suivi des évènements auxquels participent les ambassadeurs ;
• Accorder les ressources aux différentes communautés ou activités, en fonction des besoin et de l'intérêt ;
• S'occuper des conflits entre ambassadeurs.

Et ses nouvelles compétences :

• La communication entre les équipes, notamment entre la technique et le marketing ;
• Motiver les contributeurs à s'impliquer dans différents groupes de travail ;
• Gérer l'arrivé de nouveaux contributeurs pour les guider, essayer de favoriser l'inclusion de personnes souvent peu représentées dans Fedora (femmes, personnes non américaines et non européennes, étudiants, etc.) ;
• Gestion de l'équipe marketing.

Il y a 9 membres pour gérer ce nouveau comité. Un gérant, 2 proviennent des ambassadeurs, un du design et web, un de la documentation, un du marketing, un de la commops et les deux derniers sont élus. C'est pour ces deux derniers sièges que les scrutins sont ouverts.