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.

Fin de vie de la Fedora 21

Edouard Bourguignon

Un bref rappel concernant la Fedora 21, celle-ci ne sera plus maintenue à partir du 1er décembre 2015. Pensez à migrer vers une Fedora plus récente.

Deuxième version de Mesa 11.2-devel en route

Sylvain Réault

Une nouvelle version des derniers développements de Mesa arrive dans sur le dépôt avec en prime la version RAWHIDE des paquets (actuellement la branche de développement pour Fedora 24).

Beaucoup d'améliorations et pas mal de corrections de bogues en vue. Je ferai un retour d'ici lundi.

N'hésitez pas à faire votre propre retour dans les commentaires.

Forum PHP Paris 2015

Remi Collet

De retour du Forum PHP Paris 2015.

Tout d'abord un grand merci à l'AFUP pour l'organisation de ce grand moment pour la communauté, comme toujours, accueil irréprochable.

Cet événement a été, une nouvelle fois, l'occasion de faire de nombreuses et enrichissantes rencontres avec de nombreux développeurs et utilisateurs de PHP.

Cette année exceptionnelle en raison des 20 ans de PHP, des 15 ans de l'AFUP et bien entendu de la sortie imminente de PHP 7:

22976893670_aa78e7414b_o.jpg 

Sur la photo : (en haut) Derick Rethans, Anatol Belski, moi, Zeev Suraski, (en bas) Pierre Joye, Rasmus Lerdorf, Bob Weinand et Nikita Popov.

Plus de photos sur Flickr.

J'ai eu l'opportunité de donner une conférence sur la collaboration entre upstream (projets) et downstream (distribution) avec un point important sur les tests réalisés par le projet Fedora.

Lire le support de cette présentation: Paris2015.pdf.

Les retours me semblent bons, cf fiche joind.id.

J'attends avec impatience les prochaines conférences.

PHP version 5.6.16

Remi Collet

Les RPM de PHP version 5.6.16 sont disponibles dans le dépôt remi pour Fedora 21 et remi-php56 pour Fedora ≤ 20  et Enterprise Linux (RHEL, CentOS).

Annonces de la version :

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

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

yum-config-manager --enable remi-php56
yum update

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

yum install php56

Et bientôt dans les mises à jour officielles:

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

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

emblem-notice-24.pngInformations, lire :

Paquets de base (php)

Software Collections (php56)

Mesa 11.2.0-devel pour Fedora 23 disponible

Sylvain Réault

La première version de Mesa 11.2-devel est disponible. Les paquets datent de dimanche.

Une refonte du site est aussi en cours, cela devrait être disponible ce week end si tout vas bien. Pour le moment ce ne sera que la migration vers Drupal 8. Par la suite un site complètement refait de font en comble.

La version Rawhide des paquets est en route, cela devrait être bon ce soir ou demain dans la soirée.

Dockerized

Matthieu Saulnier Docker, c'est la grande mode du moment. Ce projet très récent permet de cloisonner facilement n'importe quel processus avec une installation simplifiée. La gestion exceptionnelle du chainage entre les conteneurs tout en restant isolé de l'hôte ouvre des possibilités assez hors-norme. La documentation officielle et de nombreux articles traitent déjà la bonne manière pour installer le moteur Docker, et comment démarrer un nouveau service à partir de rien. La problématique pour les vieux sysadmins est légèrement différente, puisque nous avons déjà un nombre conséquent de services qui tournent sur nos serveurs LAMP traditionnels, et qui ne demandent qu'à être aussi dockerizé. À cette problématique vient s'ajouter celle du backup des données statiques, engendrées par l'utilisation de l'application. La plupart des articles de blogs traitent l'installation des services standards, ici nous allons voir comment exploiter le moteur Docker hors des sentiers battus, parce qu'on est des oufs.

Faites place au porte-container !

Avant même d'attaquer les opérations, vous pouvez ajouter un disque dur supplémentaire et créer un nouveau Volume Logique LVM de 1024Gio pour /var/lib/docker/, le répertoire où seront stocké les images, les conteneurs d'application, et surtout les conteneurs de données qui contiennent toutes vos données statiques. Pour ma part j'estime que 1Tio sera suffisant.

# lvcreate -n lv24 -L 1024G vg_lancaster /dev/sdb1
# mkfs.ext4 /dev/mapper/vg_lancaster-lv24


Dans la première commande, je crée le Volume Logique uniquement sur le disque dur initialisé en Volume Physique /dev/sdb1. En effet, lorsque je concentre toutes mes données dans un seul volume, j'ai pour habitude de répliquer ce volume sur d'autres disques dur. Ce volume sera ultérieurement répliqué sur /dev/sdc1, je ne le fais pas maintenant car ce dd est déjà rempli par les données statiques de mon serveur LAMP traditionnel.

# systemctl stop docker
# mount /dev/mapper/vg_lancaster-lv24 /mnt/lv1
# mv /var/lib/docker/* /mnt/lv1/
<< Ajouter le point de montage /var/lib/docker dans fstab >>
# umount /mnt/lv1
# mount -a
# systemctl start docker


Nous voilà à présent avec suffisament de place pour procéder à la suite des opérations.

Construction des containeurs de données

Commençons par le plus facile, les containeurs de données statique. Ces conteneurs ne contiendrons que les données générées par l'application dockerisée. Son fonctionnement est guère différent des services non-dockerisés sur serveur. Vous avez l'habitude de mettre sur un volume à part et de backuper /var/lib/mysql/ ou /var/www/mon_super_site/, et bien ce containeur ne contiendra que ce type de donnée. Il servira de backend au containeur faisant tourner le processus lui-même.

Pour dockerizer ce blog par exemple, je vais récupérer mes données dans les répertoires /var/lib/mysql et /var/www/dotclear1. Avant de construire ces containers il est nécessaire de stopper les services httpd et mariadb pour éviter de se retrouver avec une base de données corrompu dans le container.

Placer les Dockerfiles dans leurs répertoires de travail respectifs :
docker
├── data
│   ├── Dockerfile
│   └── truc
│       └── trunk
│           └── trac
├── dotclear1
│   └── Dockerfile
├── mariadb
│   ├── Dockerfile
│   └── Dockerfile~


Dockerfile :
FROM scratch

ADD var/lib/mysql /var/lib/mysql

# Execution environement
VOLUME /var/lib/mysql
CMD ''

MAINTAINER fantom at fedoraproject.org


Dockerfile :
FROM scratch

ADD var/www/dotclear1 /var/www/html

# Execution environement
VOLUME /var/www/html
CMD ''

MAINTAINER fantom at fedoraproject.org


Il faut aussi copier les données statiques dans les répertoires de travail :

# systemctl stop httpd
# systemctl stop mariadb
# mkdir -p /home/casper/docker/dotclear1/var/www/
# cp -a /var/www/dotclear1 /home/casper/docker/dotclear1/var/www/
# mkdir -p /home/casper/docker/mariadb/var/lib/
# cp -a /var/lib/mysql /home/casper/docker/mariadb/var/lib/
# systemctl start mariadb
# systemctl start httpd


Puis on construit les images.

# cd /home/casper/docker/dotclear1
# docker build -t web-blog-data:20150926 .
# cd /home/casper/docker/mariadb
# docker build -t database-blog-data:20150926 .

Nos images de données statiques sont prêtes...

De l'arrière vers l'avant

Au niveau applicatif, c'est à dire au niveau des programmes sur lesquels reposent les données statiques que l'on a empaqueté précédemment, il y a une certaine logique à respecter. Avant de dockerizer le serveur web qui fait tourner notre application en PHP, il faut dockeriser le serveur de base de donnée sur lequel s'appuie l'appli PHP. En fait, l'idée est de construire un système, et comme pour tout système il faut commencer par la base, la basse couche invisible pour l'utilisateur. Des serveurs de backend il y en a des tonnes, si vous voulez construire un système avec des bases solides, je vous recommande de commencer par les backends.

Dans le cas de mon petit blog par exemple, mariadb est le serveur le plus en arrière car inaccessible depuis tout Internet.

Pour le démarrage du mariadb cloisonné en conteneur, il n'y a pas de conflits de port d'écoute avec le mariadb sur mon système à craindre. En effet Docker va faire en sorte que son port d'écoute soit injoignable depuis l'interface réseau, et seul les containeurs que j'aurais spécialement configuré pour communiquer avec le containeur mariadb pourront accèder à son port d'écoute. Cet avantage vient du fait que Docker possède sa propre interface réseau pour gérer les communications entre les containeurs et l'hôte.

Attention à la différence de version entre le programme sur le système et le programme cloisonné. La base de donnée fonctionnait avec mariadb-10.0.20-1.fc21.x86_64, il faut donc veiller à réutiliser la même version du mariadb dockerizé soit la 10.0.20.

# docker run --name db-blog-static database-blog-data:20150926
# docker run --name mariadb-blog -d --restart always --volumes-from db-blog-static docker.io/mariadb:10.0.20


Mariadb est désormais opérationnel et attend tout nouveau container pour se plugger dessus. En l'occurence le containeur apache+php.
Voici queques explications sur les deux commandes 'docker run' à rallonge qui peuvent parraître déroutantes. Le container mariadb-blog expose par nature son répertoire /var/lib/mysql, ce qui nous offre la possibilité d'assigner ce répertoire à un répertoire particulier sur l'hôte ou bien de l'assigner au répertoire exposé d'un autre container. Comme vous le voyez avec l'option --volumes-from, son répertoire exposé va être assigné au répertoire exposé du container db-blog-static et le programme pourra accèder aux données que l'on a empaqueté précédemment. L'option --restart always indique que le container du programme doit être démarré si celui-ci crashe ou si l'hôte redémarre. Enfin l'option -d indique de lancer le container en arrière-plan, comme un démon ou service traditionnel.

Images sur mesure

Nous venons de voir comment migrer un service en docker en réutilisant une image toute prête faite, maintenant voyons comment adapter une image pré-existante à nos besoins. On ne change rien sur l'idée d'avoir un container de données statiques pour les backups à froid, sauf que l'on peut se permettre de customiser l'image contenant l'application lorsqu'on en trouve aucune sur la registry Docker répondant à nos besoin. Toujours sur le cas mon petit blog, je cherche une image d'un serveur web (Apache) pouvant exécuter du code en PHP, avec les dépendances PHP spécifiques au moteur de blog Dotclear. Autant vous dire qu'il y en a aucune sur la registry Docker officielle, mais on peut reprendre une images apache simple et lui ajouter les dépendances PHP. Une image ou un container Docker n'est pas une boite noire où l'on peut rien entrevoir à l'intérieur, les sources des images sont libres et accessibles, on peut les lire, les copier, les modifier et les redistribuer.

Je vais donc reprendre les sources de l'image fedora/apache et ajouter la liste des paquets PHP présents sur mon serveur. (Entre parenthèses, mon serveur ne fait tourner qu'une seule application PHP, Dotclear, s'il y avait eu plusieurs applis ça aurait vite compliqué la tâche...).

% git clone https://github.com/fedora-cloud/Fedora-Dockerfiles.git
% cp -a Fedora-Dockerfiles/apache apache-php-dotclear/
<< Éditer le Dockerfile >>


Dockerfile :
FROM fedora:21
MAINTAINER http://fedoraproject.org/wiki/Cloud

RUN yum -y update && yum clean all
RUN yum -y install httpd php-php-gettext php-mysqlnd \
                   php             \
                   php-pdo         \
                   php-imap        \
                   php-simplepie   \
                   php-mbstring    \
                   php-pear        \
                   php-mcrypt      \
                   php-domxml-php4-php5 \
                   php-cli         \
                   php-snmp        \
                   php-ldap        \
                   php-pgsql       \
                   php-process     \
                   php-IDNA_Convert \
                   php-xml         \
                   php-pecl-jsonc  \
                   php-common      \
                   php-gd          \
&& yum clean all

EXPOSE 80

# Simple startup script to avoid some issues observed with container restart
ADD run-apache.sh /run-apache.sh
RUN chmod -v +x /run-apache.sh

VOLUME /var/www/html
CMD ["/run-apache.sh"]


Puis on reconstruit l'image :

# cd /home/casper/docker/apache-php-dotclear/
# docker build -t apache-php-dotclear:2.4.16 .


Notre images Apache + PHP est prête. Attention à ne pas tomber dans l'excès, une image ***doit*** rester minimaliste, il est inconcevable d'avoir Linux + Apache + MySQL + PHP dans la même image. Chaque contener représente un peu une brique LEGO, et c'est de la façon dont on les empile que dépend la fiabilité du système.

# docker run --name web-blog-static web-blog-data:20150926
# docker run --name apache-php-blog -d -p 8082:80 --restart always --link mariadb-blog:mysql --volumes-from web-blog-static apache-php-dotclear:2.4.16


L'Apache de mon blog est désormais opérationnel...

« Euh mais attend Casper, ton Apache il écoute sur le port 8082 là, tu t'es pas un peu gourré ?... »

Un peu de réseau

Revenons en arrière, imaginons que je n'ai pas ajouté l'option -p 8082:80. Docker aurait isolé le container et seul un autre container pourrait spécifiquement se connecter au port 80 du container apache-php-blog. C'est insuffisant. Maintenant imaginons que j'ajoute l'option -p 80:80. L'hôte pourrait se connecter au container en passant par le port 80, sauf que le port 80 est déjà pris sur l'hôte ! Maintenant imaginons que le port 80 est disponible sur l'hôte et que j'associe ce port au port 80 du container. J'ai un second site web avec son container apache+php et son container de données statiques, comment vais-je faire pour que ce nouveau container apache-php-truc écoute lui aussi sur le port 80 ? La solution est de relèguer les containers apache au rand de serveurs backend, ils ne sont là que pour exécuter du code (PHP/Python/whatever). Le container peut continuer à écouter sur le port 80 ce n'est pas un soucis, mais le port de l'hôte associé à ce port sera un port différent, ce qui ne pose aucun soucis également puisque Docker permet une gestion très affinée des linkages de port d'écoute.

Si le container apache-php-blog est un backend, quel serveur HTTP est le frontend ? Il y a deux solutions possible dans ce cas de figure, soit on démarre un nouveau container Apache qui écoute sur les ports 80 et 443 et qui est linké pour pouvoir se connecter aux containers de backend (apache-php-blog et apache-php-truc), soit on utilise l'Apache du système hôte, qui doit pouvoir se connecter au container à travers le port 8082 exposé par Docker.

Le première solution est la meilleure, mais surtout c'est celle qui est mise en place en tout dernier, après avoir dockerizé tous les backends du Apache de l'hôte sans exception.

L'option --link mariadb-blog:mysql entraine deux choses distinctes : Docker autorise la connexion du container apache-php-dotclear au port 3306 (mysql) du container mariadb-blog, plutôt utile pour que l'application puisse se connecter à sa base de données. Mais surtout Docker ajoute dynamiquement une entrée au DNS du container apache. Quelle que soit l'adresse IP du container mariadb, son adresse IP sera automatiquement associée au nom de domaine "mysql". Il faudra penser à mettre à jour le fichier de configuration de l'application et remplacer "localhost" par "mysql" pour joindre le serveur de base de données avant ou après la migration ça n'a pas d'importance.

Un ptit coup de sed :
# docker exec -ti apache-php-blog /bin/bash
bash-4.3# grep -r localhost /var/www/html/*
/var/www/html/inc/config.php.in:// Database hostname (usually "localhost")
/var/www/html/inc/prepend.php:                  ,(DC_DBHOST != '' ? DC_DBHOST : 'localhost')
/var/www/html/inc/config.php:// Database hostname (usually "localhost")
/var/www/html/inc/config.php:define('DC_DBHOST','localhost');


Comme prévu il n'y a qu'un fichier de config à modifier à chaud.

bash-4.3# sed -i s/localhost/mysql/ /var/www/html/inc/config.php


Pas besoin de re-runner le container, l'entrée DNS est déjà là sauf que maintenant l'application pointe vers le bon serveur de base de données.

Troubleshooting

Il se peut que votre application en PHP ne parvienne pas à se connecter à la base de données, vous devriez voir dans le journal du container mariadb-blog une ligne du genre :

# docker logs mariadb-blog
151004 17:57:48 [Warning] Access denied for user 'dotclear1user'@'172.17.0.18' (using password: YES)


En effet, lorsque j'ai initialisé la base de données, j'ai configuré les privilèges pour l'utilisateur 'dotclear1user'@'localhost'. Évidemment avec un nom d'hôte différent, ça marche tout de suite moins bien. La solution la plus simple pour fixer ce problème est de se connecter au serveur de l'hôte puis de reconstruire un container de données statiques :

Se connecter en root :

# mysql -u root -h localhost -p

Ajouter un mot de passe à l'utilisateur :

MariaDB [(none)]> set password for 'dotclear1user'@'%'=password('monsupermotdepasse');

Ajouter les bons privilèges :

MariaDB [(none)]> grant all on dotclear1.* to 'dotclear1user'@'%';

C'est tout !

Rebuild the system

Okay, on a 2 serveurs de backend cloisonnés... il ne reste plus qu'à configurer l'Apache de l'hôte en mode reverse proxy pointant vers localhost:8082... Okay, on a cloisonné 2 services... Regardons maintenant ce qui se passe si on cloisonne d'autres types de programmes.

Casper, tu penses à quoi là ?

Je pense à cloisonner des applications bureautique comme Firefox et Thunderbird, je pense à cloisonner mon porte-feuille Bitcoin, je pense à cloisonner mes routeurs Tor, mais aussi générer des images de backup de mes données personnelles !

À suivre...

Mesa 11.1-0.devel.2.vind_depot Disponible

Sylvain Réault

Voilà, après pas mal de tâtonnements, la version pour Fedora 23 de développement est disponible.

Le fichier du dépôt pour F23 est disponible ici : http://www.vind-depot.fr/depot/
A copier en root dans : /etc/yum.repo.d/

A revoir : J'ai désactivé la signature le temps de vérifier si tout fonctionne. Elle sera de retour normalement d'ici la fin du mois.

La version pour Fedora 22 est toujours en préparation, mais demande beaucoup trop de dépendances en l'état (noyau, LLVM, les pilotes Xorg principalement).
Laissez moi un commentaire si cela vaudrait le coup d'investir du temps sur cette version.

PHP version 5.6.16RC1

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 uniquement fournit en Software Collections, pour une installation en parallèle, solution idéale pour ce type de tests.

Les RPM de PHP version 5.6.16RC1 en SCL sont disponibles dans le dépôt remi-test pour Fedora 19-23 et Enterprise Linux 6-7.

La branche PHP 5.5 étant en mode "maintenance de sécurité"; il n'y a plus de RC.

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

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

yum --enablerepo=remi-test install php56

A noter :

  • la version 5.6.16RC1 est aussi disponible dans Fedora rawhide.
  • la version 7.0.0RC7 est aussi disponible

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 (php56)

Mesa 11.1-devel Fedora 23 En test

Sylvain Réault

Les paquets de la version 11.1-devel pour Fedora 23 viennent de rentrer en test. Ils seront disponible samedi avec la nouvelle version du dépôt.

L'empaquetage est basé sur la dernière version des spécifications pour Fedora 23, disponible sur koji, avec quelques modifications mineurs.

Un test pour les porter sur F22 est aussi en cours, mais il n'y a pas de grandes chances pour que ce soit possible. Il y a une trop grande différences de versions d'autres dépendances qui provoque ce problème.

Les tests seront effectués sur une R9 290x OC de chez Gigabyte, la R9 270x étant en partance sur un autre poste plus modeste.
La différence en terme de performance est vraiment énorme, passant de 46,9 i/s de moyenne à plus de 81 i/s sur le benchmark Uningine Valley.
Le défaut étant que la gestion du refroidissement fait augmenter trop rapidement la vitesse des ventilateurs et donc un bruit assourdissant malgré l'utilisation d'un boitier insonorisé.
La solution est de gérer manuellement les paliers pour garder un bon ratio bruit/refroidissement.

Je fais enfin rentrer, d'ici quelques jours, une Nvidia pour pouvoir avancer sur les tests avec le pilote "nouveau".

Suite ce samedi...

Fedora 23 disponible

Edouard Bourguignon

Je suis en retard mais pour ceux qui auraient loupé ça, la Fedora 23 est disponible (depuis le 3 novembre dernier). Pour la télécharger c'est ici !

Et si vous souhaitez savoir ce qu'il y a de bon dedans: https://linuxfr.org/news/parution-de-fedora-23

Cette version à l'air particulièrement bien soignée, je vous conseille vivement de mettre à jour (via dnf par ex). Je ferais un billet pour la mort (EOL) prochaine de la Fedora 21 (normalement dans 1 mois).

Nouvelles de Muffin

Charles-Antoine Couret

Comme je l'ai expliqué dans un billet précédent, je souhaitais relancer avec d'autres collaborateurs le fameux Magazine des Utilisateurs Francophones de Fedora. Ce projet qui a été très apprécié à son époque est je pense un outil de communication essentielle pour les utilisateurs de Fedora et même un moyen intéressant d'inciter à maitriser sa distribution, à en comprendre son fonctionnement pour ensuite y participer plus activement à son évolution.

Les retours ont été dans l'ensemble très positifs. Voici une petite synthèse de où nous en sommes aujourd'hui.

Le format

Le magazine aurait deux facettes. Tout d'abord il reprendrait en partie le fonctionnement du Fedora Magazine officiel et anglophone. Ce format blog permettrait un rythme de publication plus fréquent et d'avoir un retour des lecteurs pour perfectionner le style, le contenu, le niveau attendu et autres. Puis il y aurait de temps en temps une compilation de ce travail dans un magazine plus « traditionnel » avec potentiellement quelques contenus inédits supplémentaires.

Au sujet du rythme de publication, suivre les versions de Fedora semble satisfaire la communauté, l'objectif est de profiter de la publicité de la sortie d'une nouvelle version pour promouvoir dans le même temps le magazine. Qui sait, cela pourrait devenir la lecture obligatoire le temps que la nouvelle version s'installe ? ;-)" class="smiley Pour la partie blog, cela serait d'un article toutes les deux semaines voire par mois. L'objectif étant d'être régulier. Cela commencerait par un article d'ici un mois à compter d'aujourd'hui.

En terme de public, il est évident que Fedora est une distribution qui est certes accessible mais qui a dans sa communauté une forte expertise. De par les buts du projet Fedora, il semble évident que le magazine doit être un guide pour élever le débutant au rang de contributeur. Il est donc essentiel d'avoir du contenu accessible mais aussi pointu pour satisfaire les différents lecteurs suivant leur niveau.

Pour le format de présentation, nous souhaitons adapter Muffin aux nouveaux moyens de lecture en dehors du blog. Le format PDF est assez contraignant à générer d'une part mais aussi à lire d'autre part sur téléphone par exemple. Pour cela Matthieu Gautier nous a préparé un système de site web léger qui a une plus grande souplesse pour la rédaction mais aussi la lecture. Le contenu des articles seront rédigés au format Markdown qui est très lisible, simple et peu invasif.

L'infrastructure

Dans les avancées de ces derniers mois, le Wiki de Muffin a été remis sur pied, les pages s'affichent correctement maintenant (merci à Guillaume Kulakowski). J'ai également rafraîchi son contenu pour exposer les règles de fonctionnement et guider les contributeurs dans la manière de procéder.

Le dépôt git de Muffin a également été remis sur pied avec une mise à jour pour tenir compte des évolutions dans la façon de faire.

Avec tout ceci sur pied, nous pouvons enfin nous atteler à l'écriture, relecture et mise en page du magazine.

Articles rédigés ou envisagés

Pour le moment nous avons trois rédacteurs déclarés pour ce numéro (vous êtes bien sûr conviés à augmenter ce nombre en nous rejoignant). Voici les sujets mis sur la table actuellement :

  • L'installateur de programme graphique GNOME Logiciels
  • Le lecteur musical Lolyllop
  • Les dépôts communautaires Copr
  • Présentation de Rawhide, son intérêt, son fonctionnement, ses risques
  • Le dépôt update-testing et la remontée des anomalies (dont ABRT, fedora-easy-karma ou Bodhi)
  • Description du cycle de vie d'une version : chaque étape de son élaboration jusqu'à la fin de son support officiel
  • Traduction d'articles concernant systemd

Si un sujet vous intéresse et n'est pas dans la liste vous pouvez nous le communiquer, ou mieux rédiger un article dessus et nous le soumettre.

Ce qu'il y a à faire

Sans doute améliorer encore et toujours la procédure pour contribuer afin de la simplifier au maximum tout en restant efficace. Nous sommes preneur de retours pour améliorer ce point !

Améliorer les pages du Wiki pour lui octroyer un aspect plus vitrine du projet.

Nous sommes également à la recherche d'un designer ou du moins une personne sachant manier le CSS un minimum pour nous en faire un bon rendu final. N'hésitez pas à nous contacter si cela vous intéresse !

Mettre en place le dit blog pour la publication des articles régulièrement.

Et bien sûr rédiger, corriger et valider les articles.

La sortie du numéro de Muffin est espérée pour Mai-Juin 2016 afin de coïncider avec la sortie de Fedora 24. En décembre 2015 le premier article devrait être à disposition sur le blog du projet.

Tests de performance de PHPUnit et couverture de code

Remi Collet

Comme il a déjà été dit de nombreuses fois, PHP 7 est plus rapide que PHP 5.

Depuis PHPUnit 4.8 vous pouvez choisir entre  XDebug et phpdbg comme pilote pour récupérer les données de couverture du code, voir PHPUnit 4.8: Code Coverage Support.

Voici quelques résultats de tests de performance.

Tous les tests utilisent PHPUnit 5.0.8, PHP 5.6.15 en SCL ou PHP 7.0.0RC6 en SCL et XDebug 2.4.0beta1 (récemment publié avec quelques correctifs supplémentaires) sur les tests unitaires de composer.

PHP 5 sans couverture de code

$ php56 vendor/bin/phpunit -v
Runtime:       PHP 5.6.15
Time: 4.78 seconds, Memory: 40.25Mb

PHP 7 sans couverture de code

$ php70 vendor/bin/phpunit -v
Runtime:       PHP 7.0.0RC6
Time: 3.37 seconds, Memory: 22.00Mb

Donc PHP 7 est bien plus rapide et permet de gagner 30% de temps d'exécution et 45% de mémoire.

PHP 5 avec couverture de code

$ php56 vendor/bin/phpunit -v
Runtime:       PHP 5.6.15 with Xdebug 2.4.0beta1
Time: 1.89 minutes, Memory: 90.50Mb

PHP 7 avec couverture de code et XDebug

$ php70 vendor/bin/phpunit -v
Runtime:       PHP 7.0.0RC6 with Xdebug 2.4.0beta1
Time: 39.41 seconds, Memory: 52.00Mb

PHP 7 de nouveau vraiment plus rapide (65% de temps, 43% de mémoire)

PHP 7 avec couverture de code et phpdbg

$ php70-phpdbg -qrr vendor/bin/phpunit -v 
Runtime:       PHPDBG 7.0.0RC6
Time: 13.07 seconds, Memory: 92.00Mb

Terriblement plus rapide :) 66% du temps d'exécution économisé comparé à XDebug, et 89% comparé à PHP 5

J'ai remarqué que beaucoup de développeurs n'était pas au courant de cette dernière solution, quel dommage ! J'espère que ce billet vous encouragera à la tester.

 

Présence de Borsalinux-fr aux JM2L 2015 à Sophia-Antipolis le 28 novembre

Charles-Antoine Couret

Après une année sans édition, les Journées Méditerranéennes du Logiciel Libre reviennent le samedi 28 novembre 2015 à Sophia-Antipolis. Cet évènement majeur local qui se déroule habituellement chaque année change de format. Abandonnant la journée du vendredi dédiée aux élèves de la région, pour se concentrer sur la journée du samedi et l'activité plus communautaire.

Cette édition est toujours animée par l'équipe ensoleillée de Linux-Azur. Elle aura pour thème le Do it Yourself. Cela se déroulera comme d'habitudes avec des conférences liées à la thématique, des ateliers et des stands pour présenter différents projets ou activités. Si vous êtes amateur du Logiciel Libre, simple curieux ou personne désirant assistance, il ne faut pas louper cette occasion.

Pour ma part je serais sur place pour défendre les couleurs de Borsalinux-fr avec un stand afin de présenter Fedora et sa communauté francophone aux visiteurs et assister ceux qui le désirent. Je pourrais fournir des images ISO fraîchement disponibles de Fedora 23 (qui est sorti le 3 novembre dernier), faire une démonstration de certains changements et aussi transformer votre clé USB en média de test et d'installation de Fedora 23.

Je serais également disponible pour toute discussion. Venez nombreux !

Fedora 23 sort des cartons !

Charles-Antoine Couret

En ce mardi 3 novembre 2015, le projet Fedora est fier dannoncer la sortie de la distribution GNU/Linux Fedora 23.

Comme à son habitude, le projet Fedora propose le dernier cru des environnements GNOME 3.18 mais aussi Sugar 0.106 à destination des enfants. Tout comme la sortie de Libreoffice 5, ces programmes améliorent la gestion des écrans à haute-densité de pixels (même en cas de multi-écran avec des densités différentes). L'intégration dans Wayland est également poursuivie.

Les fans de l'environnement de bureau Cinnamon pourront profiter d'un LiveCD officiel pour le tester et l'installer directement.

Cette version de Fedora s'est surtout concentrée sur quatre axes : gestion des paquets, sécurité, Python 3 et cloud computing.

Gestion des paquets

Tout d'abord d'un point de vue graphique, GNOME Logiciels gère mieux la bande passante disponible et peut effectuer les mises à niveau complètes de Fedora. GNOME Logiciels a même la capacité nouvelle de mettre à jour les firmwares UEFI des machine le permettant !

Du côté de la console, les précédentes solutions de mise à niveau comme fedup ou encore preupgrade sont abandonnées. À la place, le gestionnaire de paquets officiel dnf hérite de ce rôle via un plugin. Cela apporte une meilleure fiabilité du processus et une meilleure intégration au système (comme dans GNOME Logiciels par exemple). Utilisateur de Fedora 22 ? Vous pouvez dor et déjà effectuer la procédure en suivant les instructions suivantes :

# dnf install dnf-plugin-system-upgrade
# dnf system-upgrade download --releasever=23
# dnf system-upgrade reboot

Sécurité

Fedora souhaite être une distribution à la pointe de la sécurité. Après les derniers scandales entourant l'usage des vieillissants algorithmes de sécurité RC4 et SSL3, le projet a retiré leur usage dans les programmes les y autorisant encore à l'exception notable des programmes issus de Mozilla, qui ont un calendrier de retrait différent.

Notons encore que les programmes de base ayant des critères d'acceptation de mots de passe voient leurs règles unifiées. Il est possible ainsi d'avoir un mot de passe unique pour anaconda (le programme d'installation), passwd ou encore gnome-control-center ! Changer la politique à l'un d'entre eux se répercute sur les autres, évitant de reproduire la procédure.

Cloud

Une version Cloud de Fedora, à savoir Fedora Atomic, suivra un calendrier de publication différent du reste du projet de Fedora. Plutôt que de sortir tous les 6 mois en moyenne, cela se fera toutes les deux semaines ! L'objectif est de faire avancer le projet rapidement pour satisfaire les besoins des développeurs et des utilisateurs. Un tel changement implique une profonde refonte de la l'assurance qualité mais aussi du site web pour respecter ce rythme effréné. Ce nouveau cycle sera en place très prochainement.

Python 3

Python a effectué il y a 7 ans un changement majeur de son langage de programmation, un changement tel que la compatibilité a été rompue avec la branche précédente. Afin d'accélérer la transition, qui doit être faite avant 2020 d'après les développeurs de Python, Fedora 23 incorpore les aspects suivants :

  • Python 3 est installé par défaut et est la seule version disponible dans les fichiers permettant l'installation de Fedora (à savoir les LiveCD notamment mais aussi les images Atomic ou DVD) ;
  • Python 2 reste disponible dans les dépôts ;
  • Pour les paquets fonctionnels avec les deux versions, Python 3 est désignée comme la version de référence ;
  • /usr/bin/python pour les utilisateurs et développeurs restera Python 2, afin de respecter les recommandations du projet Python.

Et bien entendu d'autres nouveautés sont à découvrir. Vous pourrez profiter d'un article en français plus complet. N'hésitez pas à profiter de cette dernière monture et à en effectuer des retours.

Liens

Script & raccourcis pour désactiver son touchpad sous GNOME

Guillaume Kulakowski

Mon Dell XPS 13 ne possède pas de touche Fn pour désactiver mon touchpad de manière hardware. Je me suis donc fait un petit script shell, permettant de détecter l'état de mon touchpad est de l'inverser.

Il ne restait ensuite plus qu'à associer ce script à un raccourcis clavier via le centre de contrôle GNOME.

gnome-shortcut-settings.png

 

Script & raccourcis pour désactiver son touchpad sous GNOME

Guillaume Kulakowski

Mon Dell XPS 13 ne possède pas de touche Fn pour désactiver mon touchpad de manière hardware. Je me suis donc fait un petit script shell, permettant de détecter l'état de mon touchpad est de l'inverser.

Il ne restait ensuite plus qu'à associer ce script à un raccourcis clavier via le centre de contrôle GNOME.

gnome-shortcut-settings.png

 

PHP version 5.6.15

Remi Collet

Les RPM de PHP version 5.6.15 sont disponibles dans le dépôt remi pour Fedora 21 et remi-php56 pour Fedora ≤ 20  et Enterprise Linux (RHEL, CentOS).

Annonces de la version :

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

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

yum-config-manager --enable remi-php56
yum update

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

yum --enablerepo=remi install php56

Et bientôt dans les mises à jour officielles:

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

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

emblem-notice-24.pngInformations, lire :

Paquets de base (php)

Software Collections (hp56)

Mesa 11.1-devel Fedora 23

Sylvain Réault

Il me reste encore quelques soucis de compilation, mais cela devrait être bon rapidement.

N'ayant pas retrouvé certaines clefs pour transmettre les fichiers ce week end, il en résulte quelques retards. Rien de grave de toute manière les problèmes de compilation des paquets ne me permettent pas de vous les proposer pour le moment.
Du moins principalement sur Fedora 22.

La cause est la version de LLVM qui demande des versions des pilotes (je ne parle pas de la bibliothèque graphique) qui ne fonctionnent pas sans d'autres dépendances. J'ai vu trainer des SPEC pour des paquets pour la version de Fedora 22, je vais voir si je peux travailler avec pour proposer rapidement quelque chose de viable.

C'est bien dommage, mais n'est pas primordiale non plus, fedora étant à support très court. Mais bon ce serait bien de profiter des avancées de la pile graphique au moins pendant toute la durée du support.

Je pense aussi réaliser un paquet pour les volants Logitech sous Linux étant l'heureux propriétaire d'un "Driving Force GT" qui fonctionne en partie (il reste sans doute des réglages, que je n'ai pas eu le temps de tester, à faire). Le pilote existe pour Linux, mais il n'y a pas de paquets pour Fedora d'après mes recherches (mais bon je me trompe peut être...).

J'ai aussi fait l'achat d'un casque micro Logitech G930s (bon par contre je ne sais pas à quoi correspond le "S"...) qui fonctionne très bien sous Linux, sauf le mode surround, du moins pas le bouton (dans les jeux ça le fait bien quand même :)).

Je mets en ce moment à jour le serveur, donc il est possible qu'il soit indisponible par moment. Rien de grave soit dit en passant.

Sinon concernant les jeux, il faut savoir que les avancées de Mesa 11.xx permettent d'avoir accès à des jeux demandant l'OpenGL 4 et +, ce qui fait que le nombre disponible est de plus en plus important. Cela avec en plus un nombre de portage de plus en plus nombreux, nous sommes gâtés.

Je travail aussi sur les tests sur l'OpenCL (GPGPU ou l'utilisation des processeurs graphiques pour faire du calcul), vu les gains que cela apporte dans certains domaine (traitement vidéo/images/audio/3D/calculs en tout genres, etc...), ce n'est pas négligeable que cela fonctionne!

Sachez que l'envoi des paquets sera très rapide, allant aussi vite que permet le serveur (+/- 100Mb/s, ou +/-10->12Mo/s pour celles et ceux qui préfèrent, dans les deux sens). Du coup, comme je l'ai dit dans un sujet précédent, il n'est pas nécessaire de prendre un serveur plus performant.

De retour...

Sylvain Réault

Et bien me revoilà aux affaires.

Donc à venir une nouvelle mise à jour de Mesa pour F22 et F23 (bien que la version 11 soit disponible dessus, il y a des mises à jours dans la branche de développement).

Un tout nouveau site en préparation, même si je ne peux pas vraiment travailler dessus donc ce ne sera pas pour tout de suite.

J'espère pouvoir enfin reprendre des mises à jours régulières rapidement, le script est prêt, la synchronisation vers le serveur est en place, reste à voir comment tout ce comporte.

Je referai des tests avec Mesa 11 et donc l'OpenGL 4.1 pour ce week end, si tout vas bien les nouveaux paquets seront aussi disponible en même temps.
J'en profiterai pour faire des tests avec l'OpenCL et Blender.

PHP version 5.6.15RC1

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 uniquement fournit en Software Collections, pour une installation en parallèle, solution idéale pour ce type de tests.

Les RPM de PHP version 5.6.15RC1 en SCL sont disponibles dans le dépôt remi-test pour Fedora 19-23 et Enterprise Linux 6-7.

La branche PHP 5.5 étant en mode "maintenance de sécurité"; il n'y a plus de RC.

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

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

yum --enablerepo=remi-test install php56

A noter :

  • la version 5.6.15RC1 est aussi disponible dans Fedora rawhide.
  • la version 7.0.0RC5 est aussi disponible

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 (php56)

Page générée le 31 août 2016 à 06:13