Planet Fedora-Fr http://planet.fedora-fr.org Sélection de blogs autour de Fedora fr-FR Mon, 20 Feb 2017 13:01:33 GMT eZ Systems eZ Publish (leZRSS) http://planet.fedora-fr.org/var/fedora/storage/images/media/images/logos/logo-rss/18149-2-fre-FR/logo-rss_rss.png Planet Fedora-Fr http://planet.fedora-fr.org Fri, 17 Feb 2017 07:22:00 GMT Remi Collet : PHP version 7.0.16 et 7.1.2 https://blog.remirepo.net/post/2017/02/17/PHP-version-7.0.16-et-7.1.2 urn:md5:bc730b81ff49182c44e05180c38a14ac

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

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

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

Ces versions sont aussi disponibles en Software Collections.

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

Annonces des versions :

emblem-notice-24.pngInstallation : voir l'assistant de configuration et choisir la version et le mode d'installation.

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

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

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

yum install php71

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

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

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

yum install php70

Et bientôt dans les mises à jour officielles:

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

  • la version EL7 est construite avec RHEL-7.3
  • la version EL6 est construite avec RHEL-6.8
  • 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 / php70)

]]>
RPM
Wed, 15 Feb 2017 22:34:00 GMT Association Borsalinux-Fr : Compte rendu de l'Assemblée Générale de Borsalinux-fr du 11 février 2017 https://www.borsalinux-fr.org/post/Compte-rendu-de-l-Assembl%C3%A9e-G%C3%A9n%C3%A9rale-de-Borsalinux-fr-du-11-f%C3%A9vrier-2017 urn:md5:8b5bf589dfbdc56597263b4e542c4292

Le samedi 11 février 2017 a eu lieu l'Assemblée Générale de l'association Borsalinux-fr au café des 3 arts à Paris.

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

Par la suite, un 6e 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

-Alexandre Moine (nobraska) - Trésorier adjoint)

-Emmanuel Seyman (eseyman) - Secrétaire

-Aurélien Rivière (?)

Ce conseil a un mandat de 2 ans.

Emmanuel a soutenu lidée dorganiser des rencontres de Fedora de manière plus fixe et prévisible afin de faciliter la venue des sympathisants de loin et en nombre. De manière similaire à ce qui se fait pour Ubuntu-fr.

Les goodies sont revenus au centre de lattention. Manquant toujours de volontaires pour demander les devis, commander et recevoir les colis. Les chiffons microfibre, les webcam ou les dessous de verre ont été suggérés.

Puis Charles-Antoine Couret a demandé des retours concernant la communication effectuée depuis 2 ans par ses soins. Guillaume a conseillé de communiquer plus encore sur et à propos de Fedora-fr.

De même, il a demandé sil y avait des volontaires ou remarques concernant la documentation dont la refonte est en cours. Si globalement plusieurs personnes sont prêts à donner un coup de main, il a été abordé la question du Wiki en lui même. Un chantier a été amorcé pour mettre à jour le Wiki et simplifier les contributions.

Nicolas a suggéré sil nétait pas possible dutiliser le compte FAS pour se connecter sur le Wiki. Daprès Guillaume cela pourrait être un peu compliqué, pour linstant les comptes du Wiki sont liés à ceux du forum, mais il va y réfléchir. Guillaume a proposé un lien pour quon soumette des idées concernant fedora-fr.org et quon suive lavancement des travaux.

]]>
Assemblées Générales
Wed, 08 Feb 2017 14:54:00 GMT Remi Collet : PHPUnit 6.0 https://blog.remirepo.net/post/2017/02/08/PHPUnit-6.0 urn:md5:f07b3b67eddff5168d9d90176aef8f85

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

Documentation : PHPUnit 6.0 manual et Release Announcement for PHPUnit 6.0.0 (en anglais)

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

Installation, Fedora :

dnf --enablerepo=remi install phpunit6 

Installation, Enterprise Linux :

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

Une fonction de compatibilité a été intégrée aux versions 4.8.35 et 5.7 qui permet d'utiliser les nouveaux espaces de nommages, l'adaptation étant simple (examples : fedora/autoloader ou GLPI).

Remarque: cet outil est une pièce essentielle de la QA PHP dans Fedora. Cette version, et ses dépendances sont déjà en attente de revue pour les dépôts officiels de Fedora (revue #1420381). Je prévois aussi une mise à jour dans Fedora 25 prochainement.

]]>
RPM
Mon, 06 Feb 2017 19:27:00 GMT Charles-Antoine Couret : Retour du FOSDEM http://blog.fedora-fr.org/renault/post/Retour-du-FOSDEM urn:md5:90560f219d187a0e02bc62dc5b6e6685

Et voilà, le FOSDEM c'est terminé. Pour une fois que l'occasion se présente d'y assister, il fallait que je vive sur place. :-)" class="smiley

De manière générale c'est un très bel évènement, bravo aux organisateurs car malgré la complexité de l'emploi du temps et du monde présent, cela s'est bien passé selon moi. Pour avoir déjà organisé des évènements de taille modeste en comparaison (maximum 100 visiteurs), j'imagine la quantité de travail nécessaire pour aboutir à ce résultat.

C'est d'ailleurs le caractère frustrant de ce type d'évènements. Trop peu de temps pour tant de choses à faire ou à voir.

Conférences

Pour ma part, le programme des conférences était celui-ci (dans le désordre) :

Dans l'ensemble c'était intéressant, de quoi collecter des noms, liens ou idées pour approfondir ces sujets. Comme cela peut se voir, j'ai plutôt privilégié les systèmes embarqués / systèmes d'exploitation, en lien avec mon travail et ma spécialité. J'ai regretté de ne pas avoir pu assister à celle sur RedoxOS, salle déjà comble à mon arrivée (pourtant j'étais en avance !).

Petit bémol sur la conf pour la modularité (qui provient de Fedora.next avec premier jet pour F26 Server), si cela a bien expliqué l'architecture de la chose, j'ai un peu de mal concrètement à saisir ses répercutions pour l'utilisateur et comment il va l'exploiter. Va falloir que je teste un peu pour l'annonce de F26. :-)" class="smiley

Des rencontres...

Avec un évènement de cette taille, il est évident que l'on retrouve du beau monde et on passe du temps à discuter.

Cela a bien sûr été l'occasion de retrouver la communauté de Fedora-fr : Emmanuel, Haikel, Pierre-Yves, Nicolas, Marianne, Michael dont on a partagé un repas le vendredi soir très agréable. De rencontrer des membres du projet Fedora ou de Red-Hat que je ne connaissais pas personnellement comme spot ou Benjamin Tissoires.

Hélas j'ai manqué Jean-Baptiste (malgré nos tentatives de se fixer un rendez-vous dans la journée) et Kévin dont j'ai appris son passage après l'évènement (via la page des badges de l'évènement pour les contributeurs de Fedora). Mais bon, vu la taille et le monde, c'est difficile de voir tout le monde facilement.

J'ai aussi pu enfin voir un membre de Zeste de Savoir (et du feu Site du Zér0) : Thomas Citharel. Ou encore des membres de la communauté de mon téléphone Jolla et de son système Sailfish OS.

Bien entendu j'ai pu croiser des collègues de ma nouvelle entreprise Essensium - Mind.

Cela a bien sûr été l'occasion de discuter auprès de certains projets ou d'en découvrir. Comme GRUB, OpenAutomotive Linux ou encore Mozilla. Mozilla qui a récupéré gentiment mon ZTE Open C sous Firefox OS qui traînait dans un tiroir. Et me voilà armé pour apprendre Rust, en projet.

... et des bogues !

Et oui, être sous Rawhide réserve son lot de surprises. C'est une aventure constante, même aux moments où on en a le moins envie car on n'a pas le temps ou le matériel pour réparer. Effet démo / loi de Murphy sans doute.

Et cela est arrivé lors de la conf... de la modularité de Fedora. C'est sans doute fait exprès. C'est LUKS qui au lancement de la machine refusait de déchiffrer mes partitions. Pourtant j'ai testé plein de fois le mot de passe, en QWERTY, AZERTY ou BÉPO au cas où, rien n'y faisait. J'ai également essayé avec un noyau plus ancien. Il a fallut un LiveCD (merci Emmanuel) et monter les partitions avec pour que la situation revienne à la normale. Bogue assez gênant dont je ne comprends pas l'origine. Je vais devoir creuser.

Conclusion

Ce fut un week-end très sympathique avec deux amis. Je comprends mieux la réputation de cet évènement, et très clairement j'en serai l'année prochaine.

Peut être que j'irais moins aux conférences cette fois pour plus profiter des gens encore, je ne sais pas. Après tout certaines conférences seront disponibles sur Internet (du moins je l'espère).

]]>
Logiciel Libre
Mon, 06 Feb 2017 19:27:00 GMT Charles-Antoine Couret : Retour du FOSDEM https://blog.fedora-fr.org/renault/post/Retour-du-FOSDEM urn:md5:90560f219d187a0e02bc62dc5b6e6685

Et voilà, le FOSDEM c'est terminé. Pour une fois que l'occasion se présente d'y assister, il fallait que je vive sur place. :-)" class="smiley

De manière générale c'est un très bel évènement, bravo aux organisateurs car malgré la complexité de l'emploi du temps et du monde présent, cela s'est bien passé selon moi. Pour avoir déjà organisé des évènements de taille modeste en comparaison (maximum 100 visiteurs), j'imagine la quantité de travail nécessaire pour aboutir à ce résultat.

C'est d'ailleurs le caractère frustrant de ce type d'évènements. Trop peu de temps pour tant de choses à faire ou à voir.

Conférences

Pour ma part, le programme des conférences était celui-ci (dans le désordre) :

Dans l'ensemble c'était intéressant, de quoi collecter des noms, liens ou idées pour approfondir ces sujets. Comme cela peut se voir, j'ai plutôt privilégié les systèmes embarqués / systèmes d'exploitation, en lien avec mon travail et ma spécialité. J'ai regretté de ne pas avoir pu assister à celle sur RedoxOS, salle déjà comble à mon arrivée (pourtant j'étais en avance !).

Petit bémol sur la conf pour la modularité (qui provient de Fedora.next avec premier jet pour F26 Server), si cela a bien expliqué l'architecture de la chose, j'ai un peu de mal concrètement à saisir ses répercutions pour l'utilisateur et comment il va l'exploiter. Va falloir que je teste un peu pour l'annonce de F26. :-)" class="smiley

Des rencontres...

Avec un évènement de cette taille, il est évident que l'on retrouve du beau monde et on passe du temps à discuter.

Cela a bien sûr été l'occasion de retrouver la communauté de Fedora-fr : Emmanuel, Haikel, Pierre-Yves, Nicolas, Marianne, Michael dont on a partagé un repas le vendredi soir très agréable. De rencontrer des membres du projet Fedora ou de Red-Hat que je ne connaissais pas personnellement comme spot ou Benjamin Tissoires.

Hélas j'ai manqué Jean-Baptiste (malgré nos tentatives de se fixer un rendez-vous dans la journée) et Kévin dont j'ai appris son passage après l'évènement (via la page des badges de l'évènement pour les contributeurs de Fedora). Mais bon, vu la taille et le monde, c'est difficile de voir tout le monde facilement.

J'ai aussi pu enfin voir un membre de Zeste de Savoir (et du feu Site du Zér0) : Thomas Citharel. Ou encore des membres de la communauté de mon téléphone Jolla et de son système Sailfish OS.

Bien entendu j'ai pu croiser des collègues de ma nouvelle entreprise Essensium - Mind.

Cela a bien sûr été l'occasion de discuter auprès de certains projets ou d'en découvrir. Comme GRUB, OpenAutomotive Linux ou encore Mozilla. Mozilla qui a récupéré gentiment mon ZTE Open C sous Firefox OS qui traînait dans un tiroir. Et me voilà armé pour apprendre Rust, en projet.

... et des bogues !

Et oui, être sous Rawhide réserve son lot de surprises. C'est une aventure constante, même aux moments où on en a le moins envie car on n'a pas le temps ou le matériel pour réparer. Effet démo / loi de Murphy sans doute.

Et cela est arrivé lors de la conf... de la modularité de Fedora. C'est sans doute fait exprès. C'est LUKS qui au lancement de la machine refusait de déchiffrer mes partitions. Pourtant j'ai testé plein de fois le mot de passe, en QWERTY, AZERTY ou BÉPO au cas où, rien n'y faisait. J'ai également essayé avec un noyau plus ancien. Il a fallut un LiveCD (merci Emmanuel) et monter les partitions avec pour que la situation revienne à la normale. Bogue assez gênant dont je ne comprends pas l'origine. Je vais devoir creuser.

Conclusion

Ce fut un week-end très sympathique avec deux amis. Je comprends mieux la réputation de cet évènement, et très clairement j'en serai l'année prochaine.

Peut être que j'irais moins aux conférences cette fois pour plus profiter des gens encore, je ne sais pas. Après tout certaines conférences seront disponibles sur Internet (du moins je l'espère).

]]>
Logiciel Libre
Thu, 02 Feb 2017 16:11:00 GMT Remi Collet : PHP version 7.0.16RC1 et 7.1.2RC1 https://blog.remirepo.net/post/2017/02/02/PHP-version-7.0.16RC1-et-7.1.2RC1 urn:md5:4e290859b04ce146b5dbc9f2f03e4a0c

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.0.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 25 ou remi-php70-test pour Fedora 22 et Enterprise Linux6.

Les RPM de PHP version 7.1.2RC1 sont disponibles en SCL dans le dépôt remi-test et les paquets de base dans le dépôt remi-php71-test pour Fedora 22 et Enterprise Linux6.

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

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

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

yum --enablerepo=remi-test install php70

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

yum --enablerepo=remi-test install php71

Mise à jour, de PHP 7.0 :

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

Mise à jour, de PHP 7.1:

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

A noter : la version 7.1.2RC1 est aussi disponible dans Fedora rawhide.

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, php70, php71)

Paquets standards (php)

]]>
RPM
Sun, 29 Jan 2017 22:44:00 GMT Charles-Antoine Couret : Résultats des élections de Fedora http://blog.fedora-fr.org/renault/post/R%C3%A9sultats-des-%C3%A9lections-de-Fedora2 urn:md5:ff4b9a4341a8ab7d5a5051ed860b19a1

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

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

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

  # votes |  noms
- --------+----------------------
     743  | Robert Mayr (robyduck)
- --------+----------------------
     738  | Justin W. Flory (jflory7)
     466  | Giannis Konstantinidis (giannisk)
     413  | Charles Profitt (cprofitt)
     393  | Itamar Reis Peixoto (itamarjp/itamarjp)

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

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

  # votes |  noms
- --------+----------------------
    1401  | Kevin Fenzi (nirik / kevin)
    1075  | Adam Miller (maxamillion / maxamillion)
     988  | Jared Smith (jsmith / jsmith)
     735  | Justin Forbes (jforbes / jforbes)
     691  | Kalev Lember (kalev / kalev)
- --------+----------------------
     558  | Itamar Reis Peixoto (itamarjp / itamarjp)
     539  | Frederico Lima (fredlima / fredlima)

À titre indicatif le score maximal possible était de 7 * 267 (pour 267 votants) soit 1869.

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

  # votes |  noms
- --------+----------------------
    1623  | Robert Mayr (robyduck)
    1576  | Jona Azizaj (jonatoni)
    1274  | Gabriele Trombini (mailga)
    1168  | Giannis Konstantinidis (giannisk)
    1110  | Itamar Reis Peixoto (itamarjp)
    1010  | Frederico Lima (fredlima)
     964  | Sylvia Sanchez (Kohane / lailah)
- --------+----------------------
     944  | Sirko Kemter (gnokii)
     920  | Zacharias Mitzelos (mitzie)
     862  | Marcel Ribeiro Dantas (mribeirodantas)
     856  | Daniel Lara (danniel)
     735  | Lucas Landim (landim)
     731  | Tulio Macedo (_Teseu_ / teseu)

À titre d'indication, la valeur maximale possible est de 13 * 247 (car il y a eu 247 votants) soit 3211.

Nous pouvons noter que globalement le nombre de votants pour chaque scrutin était proche aux alentours de 250 votants.. Les scores sont aussi plutôt éparpillés, avec souvent quelques membres assez largement en tête de chaque scrutin. Kevin a par contre écrasé le vote pour l'accès au FESCo, démontrant la qualité apprécié de son travail depuis des années.

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

]]>
Fedora
Sun, 29 Jan 2017 22:44:00 GMT Charles-Antoine Couret : Résultats des élections de Fedora https://blog.fedora-fr.org/renault/post/R%C3%A9sultats-des-%C3%A9lections-de-Fedora2 urn:md5:ff4b9a4341a8ab7d5a5051ed860b19a1

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

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

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

  # votes |  noms
- --------+----------------------
     743  | Robert Mayr (robyduck)
- --------+----------------------
     738  | Justin W. Flory (jflory7)
     466  | Giannis Konstantinidis (giannisk)
     413  | Charles Profitt (cprofitt)
     393  | Itamar Reis Peixoto (itamarjp/itamarjp)

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

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

  # votes |  noms
- --------+----------------------
    1401  | Kevin Fenzi (nirik / kevin)
    1075  | Adam Miller (maxamillion / maxamillion)
     988  | Jared Smith (jsmith / jsmith)
     735  | Justin Forbes (jforbes / jforbes)
     691  | Kalev Lember (kalev / kalev)
- --------+----------------------
     558  | Itamar Reis Peixoto (itamarjp / itamarjp)
     539  | Frederico Lima (fredlima / fredlima)

À titre indicatif le score maximal possible était de 7 * 267 (pour 267 votants) soit 1869.

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

  # votes |  noms
- --------+----------------------
    1623  | Robert Mayr (robyduck)
    1576  | Jona Azizaj (jonatoni)
    1274  | Gabriele Trombini (mailga)
    1168  | Giannis Konstantinidis (giannisk)
    1110  | Itamar Reis Peixoto (itamarjp)
    1010  | Frederico Lima (fredlima)
     964  | Sylvia Sanchez (Kohane / lailah)
- --------+----------------------
     944  | Sirko Kemter (gnokii)
     920  | Zacharias Mitzelos (mitzie)
     862  | Marcel Ribeiro Dantas (mribeirodantas)
     856  | Daniel Lara (danniel)
     735  | Lucas Landim (landim)
     731  | Tulio Macedo (_Teseu_ / teseu)

À titre d'indication, la valeur maximale possible est de 13 * 247 (car il y a eu 247 votants) soit 3211.

Nous pouvons noter que globalement le nombre de votants pour chaque scrutin était proche aux alentours de 250 votants.. Les scores sont aussi plutôt éparpillés, avec souvent quelques membres assez largement en tête de chaque scrutin. Kevin a par contre écrasé le vote pour l'accès au FESCo, démontrant la qualité apprécié de son travail depuis des années.

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

]]>
Fedora
Sun, 29 Jan 2017 14:18:00 GMT Charles-Antoine Couret : Aidez Firefox à généraliser Electrolysis http://blog.fedora-fr.org/renault/post/Forcez-Electrolysis-dans-Firefox-et-envoyez-vos-retours urn:md5:2529afc11556f1089eebe8a4b3ba4c4d

Et oui, tester Fedora, c'est aussi tester et aider les projets libres qu'il met à disposition afin de rendre le tout meilleur. Or, Mozilla Firefox est le navigateur par défaut de Fedora, l'un des plus utilisés de la communauté et personnellement c'est celui de mon quotidien depuis ses débuts en 2004.

Et actuellement Firefox a besoin d'un petit coup de main pour accélérer le déploiement d'une nouvelle technologie : Electrolysis.

Vous avez 5-10 minutes et vous aimez Firefox ? Cet article est fait pour vous !

Qu'est-ce que Electrolysis ?

Le concept est que Firefox soit multiprocess. Pas un processus par onglet mais dans un premier temps pour séparer la gestion des pages web de l'interface du navigateur. Cela devrait améliorer la fluidité dans un certain nombre de cas, mais aussi améliorer la stabilité de l'ensemble en évitant que le navigateur crash entièrement à cause d'un site web mal conçu.

C'est un projet complexe à mettre en œuvre car remettant en cause l'ancienne architecture du navigateur. Cela fait plusieurs mois voire années que ce chantier est en cours.

Et si Electrolysis se déploie de plus en plus, cela se fait par vagues et il est nécessaire d'aider pour que la diffusion soit totale le plus vite possible. En effet, Firefox n'active pas ce mode si l'utilisateur a au moins une extension dont on ignore la compatibilité avec ce changement. Or, il y a beaucoup d'extensions dont le status n'est pas connu. En plus du fait que Firefox repose aujourd'hui énormément sur sa collection d'extensions.

Vous pouvez voire manuellement sur ce site si vos extensions sont compatibles ou non avec ce mécanisme. Sachant que seuls ceux contenant le champs compatible le sont.

Comment aider ?

Tout d'abord, vérifiez si Electrolysis n'est pas déjà activé. Pour cela saisissez about:support dans la barre d'adresse. Cherchez le champs Fenêtres multi-processus. Si vous avez 1/1, il est déjà activé et vous n'avez rien de spécial à tester. Si c'est 0/1, vous pouvez poursuivre la lecture.

Ensuite, il suffit de forcer Electrolysis, d'utiliser Firefox et de faire un retour plus tard sur si cela s'est bien ou mal passé. Pour aider, il est préférable d'avoir la version 51.0 ou supérieur de Firefox.

Pour forcer Electrolysis, vous devez aller dans le about:config (à saisir dans la base d'adresses). Ensuite un clique droit pour créer une nouvelle valeur booléenne avec pour nom browser.tabs.remote.force-enable. Vous mettrez la valeur à True.

Ensuite, il est nécessaire d'installer l'extension Add-On compatibility reporter. Vous pouvez redémarrer Firefox et le tester.

Soyez naturels, utilisez Firefox normalement pendant quelques heures voire jours. Testez évidemment vos extensions. Si vous le voyez aucun soucis, vous pouvez utiliser l'extension pour déclarer toutes vos extensions comme compatibles. Sinon il faut éventuellement en désactiver certaines pour déceler celle qui pose soucis.

Si une extension pose problème, n'hésitez pas à contacter son auteur pour qu'il soit au courant et qu'il corrige cela.

Vous pouvez désactiver Electrolysis si vous le souhaitez en remettant browser.tabs.remote.force-enable à False.

Et voilà, vous avez fini. Grâce à votre retour, de plus en plus d'extensions seront validées et Electrolys pourra fonctionner sur de plus en plus de machines par défaut, dont vos machines.

]]>
Mozilla
Sun, 29 Jan 2017 14:18:00 GMT Charles-Antoine Couret : Aidez Firefox à généraliser Electrolysis https://blog.fedora-fr.org/renault/post/Forcez-Electrolysis-dans-Firefox-et-envoyez-vos-retours urn:md5:2529afc11556f1089eebe8a4b3ba4c4d

Et oui, tester Fedora, c'est aussi tester et aider les projets libres qu'il met à disposition afin de rendre le tout meilleur. Or, Mozilla Firefox est le navigateur par défaut de Fedora, l'un des plus utilisés de la communauté et personnellement c'est celui de mon quotidien depuis ses débuts en 2004.

Et actuellement Firefox a besoin d'un petit coup de main pour accélérer le déploiement d'une nouvelle technologie : Electrolysis.

Vous avez 5-10 minutes et vous aimez Firefox ? Cet article est fait pour vous !

Qu'est-ce que Electrolysis ?

Le concept est que Firefox soit multiprocess. Pas un processus par onglet mais dans un premier temps pour séparer la gestion des pages web de l'interface du navigateur. Cela devrait améliorer la fluidité dans un certain nombre de cas, mais aussi améliorer la stabilité de l'ensemble en évitant que le navigateur crash entièrement à cause d'un site web mal conçu.

C'est un projet complexe à mettre en œuvre car remettant en cause l'ancienne architecture du navigateur. Cela fait plusieurs mois voire années que ce chantier est en cours.

Et si Electrolysis se déploie de plus en plus, cela se fait par vagues et il est nécessaire d'aider pour que la diffusion soit totale le plus vite possible. En effet, Firefox n'active pas ce mode si l'utilisateur a au moins une extension dont on ignore la compatibilité avec ce changement. Or, il y a beaucoup d'extensions dont le status n'est pas connu. En plus du fait que Firefox repose aujourd'hui énormément sur sa collection d'extensions.

Vous pouvez voire manuellement sur ce site si vos extensions sont compatibles ou non avec ce mécanisme. Sachant que seuls ceux contenant le champs compatible le sont.

Comment aider ?

Tout d'abord, vérifiez si Electrolysis n'est pas déjà activé. Pour cela saisissez about:support dans la barre d'adresse. Cherchez le champs Fenêtres multi-processus. Si vous avez 1/1, il est déjà activé et vous n'avez rien de spécial à tester. Si c'est 0/1, vous pouvez poursuivre la lecture. Notons, si vous utiliser Fedora, normalement ce sera toujours désactivé par défaut pour le moment.

Ensuite, il suffit de forcer Electrolysis, d'utiliser Firefox et de faire un retour plus tard sur si cela s'est bien ou mal passé. Pour aider, il est préférable d'avoir la version 51.0 ou supérieur de Firefox.

Pour forcer Electrolysis, vous devez aller dans le about:config (à saisir dans la base d'adresses). Ensuite un clique droit pour créer une nouvelle valeur booléenne avec pour nom browser.tabs.remote.force-enable. Vous mettrez la valeur à True.

Ensuite, il est nécessaire d'installer l'extension Add-On compatibility reporter. Vous pouvez redémarrer Firefox et le tester.

Soyez naturels, utilisez Firefox normalement pendant quelques heures voire jours. Testez évidemment vos extensions. Si vous le voyez aucun soucis, vous pouvez utiliser l'extension pour déclarer toutes vos extensions comme compatibles. Sinon il faut éventuellement en désactiver certaines pour déceler celle qui pose soucis.

Si une extension pose problème, n'hésitez pas à contacter son auteur pour qu'il soit au courant et qu'il corrige cela.

Vous pouvez désactiver Electrolysis si vous le souhaitez en remettant browser.tabs.remote.force-enable à False.

Et voilà, vous avez fini. Grâce à votre retour, de plus en plus d'extensions seront validées et Electrolys pourra fonctionner sur de plus en plus de machines par défaut, dont vos machines.

]]>
Mozilla
Tue, 24 Jan 2017 22:32:00 GMT Association Borsalinux-Fr : Assemblée Générale Ordinaire le 11 février 2017 à Paris http://www.borsalinux-fr.org/post/Assembl%C3%A9e-G%C3%A9n%C3%A9rale-Ordinaire-le-11-f%C3%A9vrier-2017-%C3%A0-Paris urn:md5:973034985b868d75c3ba5170a3c71101

L'Assemblée Générale Extraordinaire et Ordinaire de l'association a lieu à partir de 14h au café les 3 arts à l'adresse à l'adresse 21, rue des Rigoles 75020 Paris.

L'ordre du jour de l'AG est le suivant :

1- Présentation du bilan moral de l'activité de l'association par le Conseil d'Administration;

2- Présentation du bilan financier de l'activité de l'Association par le Conseil d'Administration et du budget 2017.

3- Élection du Conseil d'Administration pour un mandat de 2 ans ;

4- Élection du Bureau de l'association pour un mandat de 2 ans ;

5- Démission de l'actuel Conseil d'administration et de son bureau ;

6- Présentation des événements et des actions pour l'année 2017.

À qui envoyer sa procuration ?

Pour les procurations vous pouvez vous baser sur ce modèle. Vous pouvez transmettre vos procurations par courrier postale, ou par courrier électronique à condition que celui-ci soit signé.

Attention, un membre actif ne pourra détenir plus de deux procurations, conformément à notre règlement intérieur.

Ci-dessous est la liste des personnes qui ont confirmé leur venue à cette Assemblée Générale du 11 février 2017 et acceptant les procurations :

  • Charles-Antoine Couret (Avenue général Mellier, 40 - 5030 Gembloux - Belgique)
  • Emmanuel Seyman (133 rue de Silly, 92100 Boulogne-Billancourt)
  • Nicolas Chauvet
]]>
Assemblées Générales
Tue, 24 Jan 2017 22:32:00 GMT Association Borsalinux-Fr : Assemblée Générale Ordinaire le 11 février 2017 à Paris https://www.borsalinux-fr.org/post/Assembl%C3%A9e-G%C3%A9n%C3%A9rale-Ordinaire-le-11-f%C3%A9vrier-2017-%C3%A0-Paris urn:md5:973034985b868d75c3ba5170a3c71101

L'Assemblée Générale Extraordinaire et Ordinaire de l'association a lieu à partir de 14h au café les 3 arts à l'adresse à l'adresse 21, rue des Rigoles 75020 Paris.

L'ordre du jour de l'AG est le suivant :

1- Présentation du bilan moral de l'activité de l'association par le Conseil d'Administration;

2- Présentation du bilan financier de l'activité de l'Association par le Conseil d'Administration et du budget 2017.

3- Élection du Conseil d'Administration pour un mandat de 2 ans ;

4- Élection du Bureau de l'association pour un mandat de 2 ans ;

5- Démission de l'actuel Conseil d'administration et de son bureau ;

6- Présentation des événements et des actions pour l'année 2017.

À qui envoyer sa procuration ?

Pour les procurations vous pouvez vous baser sur ce modèle. Vous pouvez transmettre vos procurations par courrier postale, ou par courrier électronique à condition que celui-ci soit signé.

Attention, un membre actif ne pourra détenir plus de deux procurations, conformément à notre règlement intérieur.

Ci-dessous est la liste des personnes qui ont confirmé leur venue à cette Assemblée Générale du 11 février 2017 et acceptant les procurations :

  • Charles-Antoine Couret (Avenue général Mellier, 40 - 5030 Gembloux - Belgique)
  • Emmanuel Seyman (133 rue de Silly, 92100 Boulogne-Billancourt)
]]>
Assemblées Générales
Sat, 21 Jan 2017 16:03:00 GMT Charles-Antoine Couret : Petit bilan de Rawhide, 2 mois après http://blog.fedora-fr.org/renault/post/Petit-bilan-de-Rawhide%2C-2-mois-apr%C3%A8s urn:md5:8261e1484b7d31b934471b408fc4b992

Comme vous le savez, il y a deux mois je suis passé à Rawhide. Pour la première fois je vais vivre entièrement le cycle de développement d'une version de Fedora. L'objectif étant bien entendu de découvrir des choses et d'aider à détecter des problèmes plus tôt. Afin que la Fedora 26 soit la plus stable possible.

Les problèmes rencontrés

Il n'y a pas à dire, à ce stade il y a du boulot ! J'ai rencontré en 2 mois quelques bogues plutôt importants. Je m'y attendais, et il y a eu de grands progrès par rapport à la situation d'il y a quelques années.

En premier lieu, un bogue de Firefox que j'avais peu avant la sortie de F25 qui continue à me poursuivre. Les vidéos sur les pages Web parfois tournent en boucle sur 1 seconde de buffer. Rendant illisible la lecture, obligeant de relancer Firefox.

Ensuite, un bogue qui continue toujours, GNOME Shell a une erreur obligeant à relancer la session, sans raison à son lancement. C'est plutôt aléatoire. Mais si la session se lance bien, ce problème ne surgit plus avant le prochain lancement.

Un bogue apparemment qui a concerné aussi F25 et F24, avec Firefox impossible d'aller sur des sites tels que Google ou Wikipédia. Un problème dû à HTTPS sur HTTP2 apparemment. Cela a été corrigé rapidement, mais pourrait revenir pour Thunderbird et SeaMonkey à l'avenir, à cause de la mise à jour de NSS (la bibliothèque de sécurité de Mozilla) et le manque de correctif pour ces programmes. C'est en discussion sur la manière d'aborder la chose.

Un nouveau bogue apparu hier, qui semble venir du logiciel lui même. Ouvrir des onglets dans Epiphany rend l'écran noir ou gèle le système. Plutôt ennuyeux, mais au moins Epiphany n'est pas mon navigateur principal donc cela ne me gêne pas trop.

Enfin, dernier bogue qui vient d'être résolu. GNOME Shell, GDM et d'autres programmes plantaient, à cause d'un écart de version entre la bibliothèque harfbuzz de Fedora et de FreeType dans RPMFusion. Le mainteneur dans RPMFUsion a rapidement corrigé le tir.

Bref, 5 bogues que je considère comme importants et que j'ai rencontré en 2 mois. Ce n'est pas beaucoup. Dont 2 qui ont touché aussi la version stable de Fedora par ailleurs. Cela demande quand même un peu de patience et de bidouilles pour corriger la situation mais rien d'insurmontable. :-)" class="smiley

Cependant, il y a eu discussion il y a quelques temps sur Rawhide. Un empaqueteur a jugé bon de pousser un paquets qui ne fonctionnait pas sur Rawhide dans les dépôts (car pas testé par ses soins avant). Selon lui Rawhide doit être un dépôt poubelle où la stabilité ne compte pas car cela pourrait ralentir ses développements. Je trouve que de manquer ici de respect aux testeurs est dommageable. Rawhide par définition doit être utilisable et un paquet doit être testé par son mainteneur avant. Cela paraît être le minimum à faire.

Heureusement que cette mentalité a fortement régressé. Il n'y a plus beaucoup d'empaqueteurs qui tiennent encore de tels propos.

Les changements

Forcément l'intérêt de passer à Rawhide ou à une version de tests, c'est aussi découvrir et profiter des changements en avance. Pour l'instant pas de grands bouleversements. GNOME Shell et LibreOffice sont en avance d'une version par rapport à Fedora 25 (mais sont toujours en développement). Comme souvent leurs améliorations sont par petite touche et l'ensemble est plus agréable.

Le plus grand changement visible vient de GNOME Builder je pense, dont une bonne partie de l'interface a été changée. C'est l'IDE que j'utilise depuis une année maintenant et il évolue vraiment dans le bon sens, c'est très appréciable.

Après nous ne sommes qu'au début du développement de ce que deviendra Fedora 26. Les fonctionnalités ne sont pas encore toutes définies, et encore moins mises en place. Et les logiciels upstream aussi ont beaucoup à faire, GNOME n'a pas encore fini de changer (sa sortie étant dans 2 mois) par exemple.

J'espère que ce genre de billets vous plairont, je compte en faire mensuellement. Quand j'aurais des changements plus visibles je ferais des captures d'écran associés. Si cela intéresse les gens d'aller à l'aventure de Rawhide, n'hésitez pas, il y a très peu de testeurs mais beaucoup de besoins ! Et c'est grâce à cette activité que la Fedora stable est stable.

]]>
Fedora
Sat, 21 Jan 2017 16:03:00 GMT Charles-Antoine Couret : Petit bilan de Rawhide, 2 mois après https://blog.fedora-fr.org/renault/post/Petit-bilan-de-Rawhide%2C-2-mois-apr%C3%A8s urn:md5:8261e1484b7d31b934471b408fc4b992

Comme vous le savez, il y a deux mois je suis passé à Rawhide. Pour la première fois je vais vivre entièrement le cycle de développement d'une version de Fedora. L'objectif étant bien entendu de découvrir des choses et d'aider à détecter des problèmes plus tôt. Afin que la Fedora 26 soit la plus stable possible.

Les problèmes rencontrés

Il n'y a pas à dire, à ce stade il y a du boulot ! J'ai rencontré en 2 mois quelques bogues plutôt importants. Je m'y attendais, et il y a eu de grands progrès par rapport à la situation d'il y a quelques années.

En premier lieu, un bogue de Firefox que j'avais peu avant la sortie de F25 qui continue à me poursuivre. Les vidéos sur les pages Web parfois tournent en boucle sur 1 seconde de buffer. Rendant illisible la lecture, obligeant de relancer Firefox.

Ensuite, un bogue qui continue toujours, GNOME Shell a une erreur obligeant à relancer la session, sans raison à son lancement. C'est plutôt aléatoire. Mais si la session se lance bien, ce problème ne surgit plus avant le prochain lancement.

Un bogue apparemment qui a concerné aussi F25 et F24, avec Firefox impossible d'aller sur des sites tels que Google ou Wikipédia. Un problème dû à HTTPS sur HTTP2 apparemment. Cela a été corrigé rapidement, mais pourrait revenir pour Thunderbird et SeaMonkey à l'avenir, à cause de la mise à jour de NSS (la bibliothèque de sécurité de Mozilla) et le manque de correctif pour ces programmes. C'est en discussion sur la manière d'aborder la chose.

Un nouveau bogue apparu hier, qui semble venir du logiciel lui même. Ouvrir des onglets dans Epiphany rend l'écran noir ou gèle le système. Plutôt ennuyeux, mais au moins Epiphany n'est pas mon navigateur principal donc cela ne me gêne pas trop.

Enfin, dernier bogue qui vient d'être résolu. GNOME Shell, GDM et d'autres programmes plantaient, à cause d'un écart de version entre la bibliothèque harfbuzz de Fedora et de FreeType dans RPMFusion. Le mainteneur dans RPMFUsion a rapidement corrigé le tir.

Bref, 5 bogues que je considère comme importants et que j'ai rencontré en 2 mois. Ce n'est pas beaucoup. Dont 2 qui ont touché aussi la version stable de Fedora par ailleurs. Cela demande quand même un peu de patience et de bidouilles pour corriger la situation mais rien d'insurmontable. :-)" class="smiley

Cependant, il y a eu discussion il y a quelques temps sur Rawhide. Un empaqueteur a jugé bon de pousser un paquets qui ne fonctionnait pas sur Rawhide dans les dépôts (car pas testé par ses soins avant). Selon lui Rawhide doit être un dépôt poubelle où la stabilité ne compte pas car cela pourrait ralentir ses développements. Je trouve que de manquer ici de respect aux testeurs est dommageable. Rawhide par définition doit être utilisable et un paquet doit être testé par son mainteneur avant. Cela paraît être le minimum à faire.

Heureusement que cette mentalité a fortement régressé. Il n'y a plus beaucoup d'empaqueteurs qui tiennent encore de tels propos.

Les changements

Forcément l'intérêt de passer à Rawhide ou à une version de tests, c'est aussi découvrir et profiter des changements en avance. Pour l'instant pas de grands bouleversements. GNOME Shell et LibreOffice sont en avance d'une version par rapport à Fedora 25 (mais sont toujours en développement). Comme souvent leurs améliorations sont par petite touche et l'ensemble est plus agréable.

Le plus grand changement visible vient de GNOME Builder je pense, dont une bonne partie de l'interface a été changée. C'est l'IDE que j'utilise depuis une année maintenant et il évolue vraiment dans le bon sens, c'est très appréciable.

Après nous ne sommes qu'au début du développement de ce que deviendra Fedora 26. Les fonctionnalités ne sont pas encore toutes définies, et encore moins mises en place. Et les logiciels upstream aussi ont beaucoup à faire, GNOME n'a pas encore fini de changer (sa sortie étant dans 2 mois) par exemple.

J'espère que ce genre de billets vous plairont, je compte en faire mensuellement. Quand j'aurais des changements plus visibles je ferais des captures d'écran associés. Si cela intéresse les gens d'aller à l'aventure de Rawhide, n'hésitez pas, il y a très peu de testeurs mais beaucoup de besoins ! Et c'est grâce à cette activité que la Fedora stable est stable.

]]>
Fedora
Fri, 20 Jan 2017 05:45:00 GMT Remi Collet : PHP version 5.6.30, 7.0.15 et 7.1.1 https://blog.remirepo.net/post/2017/01/20/PHP-version-5.6.30-7.0.15-et-7.1.1 urn:md5:b46d66fbab88dc60994e18e807bc35b1

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

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

Les RPM de PHP version 5.6.30 sont disponibles dans le dépôt remi pour Fedora 22-24 et remi-php56 pour Enterprise Linux.

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

Ces versions sont aussi disponibles en Software Collections.

security-medium-2-24.pngCes versions corrigent quelques failles de sécurité, la mise à jour est donc vivement recommandée.

Annonces des versions :

emblem-notice-24.pngInstallation : voir l'assistant de configuration et choisir la version et le mode d'installation.

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

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

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

yum install php71

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

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

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

yum install php70

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.3
  • la version EL6 est construite avec RHEL-6.8
  • 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 / php70)

]]>
RPM
Wed, 11 Jan 2017 21:39:00 GMT Charles-Antoine Couret : Élections pour le Conseil, FESCo et FAmSCo cette semaine http://blog.fedora-fr.org/renault/post/%C3%89lections-pour-le-Conseil%2C-FESCo-et-FAmSCo-cette-semaine urn:md5:cd010875708df716bb5b27c183601fbd

Comme le projet Fedora est communautaire, une partie du collège des organisations suivantes doit être renouvelée : Council, FESCo et FAmSCo. Et ce sont les contributeurs qui décident. 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.

J'ai voté

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 mardi 17 janvier à minuit 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 FAmSCo. 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 l'une de 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.

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.

FAmSCo

Le FAmSCo (Fedora Ambassadors Steering Committee) 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.

Voici un exemple des thèmes dont il a compétence :

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

Les 7 membres de cette équipe sont également entièrement élus avec une durée de mandat d'un an. Chaque élection renouvelle le collège par moitié.

]]>
Fedora
Wed, 11 Jan 2017 21:39:00 GMT Charles-Antoine Couret : Élections pour le Conseil, FESCo et FAmSCo cette semaine https://blog.fedora-fr.org/renault/post/%C3%89lections-pour-le-Conseil%2C-FESCo-et-FAmSCo-cette-semaine urn:md5:cd010875708df716bb5b27c183601fbd

Comme le projet Fedora est communautaire, une partie du collège des organisations suivantes doit être renouvelée : Council, FESCo et FAmSCo. Et ce sont les contributeurs qui décident. 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.

J'ai voté

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 mardi 17 janvier à minuit 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 FAmSCo. 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 l'une de 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.

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.

FAmSCo

Le FAmSCo (Fedora Ambassadors Steering Committee) 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.

Voici un exemple des thèmes dont il a compétence :

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

Les 7 membres de cette équipe sont également entièrement élus avec une durée de mandat d'un an. Chaque élection renouvelle le collège par moitié.

]]>
Fedora
Sun, 08 Jan 2017 14:27:00 GMT Patrice Kadionik : AMC version 1.3.0 http://eddy33.eddy33.free.fr/weblog/index.php?post/2017/01/08/AMC-version-1.3.0 urn:md5:a8b783cbcea00f93c50d20a28c334ac6

Les RPM d'AMC (Auto Multiple Choice) version 1.3.0 sont disponibles dans le dépôt eddy33 pour Fedora ≥ 23, versions 32 et 64 bits.


Installation :

# dnf install http://kadionik.vvv.enseirb-matmeca.fr/fedora/repo-eddy33-1.0-1.fc25.noarch.rpm
# dnf install auto-multiple-choice

++
]]>
Fedora
Sun, 08 Jan 2017 11:39:00 GMT Matthieu Saulnier : Persistence des données https://casperlefantom.net/index.php?post/2016/12/25/Persistence-des-donn%C3%A9es urn:md5:46cd906e150d002fd7a3680beb12f565

Salut lecteur,

Oui toi, pas la peine de regarder à gauche ou à droite, il y a absolument personne, je parle bien à toi cher lecteur. Tu as cru que je t'avais oublié, pas vrai ? Du tout, mais comme tu le sais, j'ai eu pas mal de distractions ces derniers temps, j'ai vraiment du mal à trouver du temps pour t'écrire.

En plus, faut vraiment être motivé pour lire un article de plus sur Docker. Oui Docker, au travail j'ai carrément augmenté mon skill à ce sujet, et j'ai grave envie de t'en parler mon lecteur. D'ailleurs si t'as envie de connaitre mon opinion sur ce « truc », Aeris l'exprime parfaitement sur son blog, dans un article purement philosophique comme je les aime.

Au début je m'étais dit exactement comme tout le monde : AWESOME FAUT QUE JE DOCKERISE TOUS MES SERVEURS!!!! et puis je suis redescendu sur terre. Pour donner une proportion, j'en suis à 30% de mes services en container Docker, et ça n'augmentera plus. Pour illustrer pourquoi, je vais juste dire que mes serveurs imap et smtp utilisent les utilisateurs système de l'hôte, et ils doivent rester en correllation avec les utilisateurs SSH. C'est d'ailleurs la définition d'un « système », en fait. Pour le reste, soit.

Et puis vient la question de mettre quoi en container, de cloisonner quoi exactement. Dans un précédent article, je mettais tout en container, vraiment tout, et c'est vraiment pas pratique.

En fait, il m'a fallu un peu de temps avant de maitriser complètement la ligne de commande Docker, je parle de comprendre tous les concepts qu'elle induit, pour au final ne retenir qu'une seule philosophie. C'est le problème typique qu'on rencontre quand un système propose trop de possibilités. Avais-tu remarqué dans l'article précédent que je mettais les données statiques à disposition à travers un container statique ? Que se passerait-t-il si ce container disparaissait ?

Comme la plupart des gens qui font une utilisation intensive du service Docker, j'ai eu à un moment, tôt ou tard, besoin de supprimer /var/lib/docker pour résoudre un gros problème : Le service Docker ne démarrait plus. Inutile de te dire que le container disparait comme par magie, et que j'ai eu très peur pour mes données. Mais, je suis un hébergeur sérieux... j'ai des backups journaliers ^^

Cette mésaventure m'a poussé à repenser mes possiblités avec le service, cette fois-ci en considérant les containers comme non-définitifs. S'ils ne sont plus définitifs, alors ils ne doivent plus démarrer automatiquement au démarrage de l'hôte (virer l'option --restart always), et la "démonification" (option -d) doit être gérée par un gestionnaire de services, prenons Systemd.

Avec systemd, on pourra gérer à la fois le container, mais aussi les inputs passés au processus cloisonné.

L'avantage de passer par un orchestrateur de service est d'enlever au service Docker les rôles qui ne sont pas son point fort, comme le démarrage des containers dans un ordre précis, le redémarrage du container si le processus se termine en erreur (option --restart always), le status du processus cloisonné (le container est signalé comme "Up" alors qu'aucun processus n'est actif), et la gestion des logs du processus directement par Journald.

Pour récupérer la sortie standard et l'erreur, bref le log du processus, il faut que le container ne soit pas spawné avec l'option -d (détacher la tâche) pour ne pas qu'il parte en arrière-plan, c'est Systemd qui gère lui-même la partie « démon ». Du point de vue de Systemd, la commande ne forke pas, et toutes les sorties sont recueillies automatiquement par Journald.

Le second avantage est d'obtenir une meilleure intéraction avec le processus cloisonné. Tous les signaux comme SIGINT, SIGKILL et SIGHUP, envoyés par Systemd au container seront transférés par le service Docker directement au processus principal à l'intérieur du container. L'entrée standard reste ouverte si le container est attaché (à un tty ou à Systemd), mais on peut aussi demander de la laisser ouverte quand le container est détaché avec l'option -i.

Le service Docker ne sert plus d'intermédiaire comme un émulateur de VM qui doit relayer les signaux de fin de tâche à tous ses invités. Je serais tenté de croire qu'il y a un gain de temps non-négligeable dans le temps de réponse des processus, mais je n'ai pas fait de benchmark...

Et puis, les choses intéressantes commencent à arriver, on parle de container non-définitif, on parle de cloisonner seulement le processus, et surtout on parle de terminer le processus, tu as deviné la suite mon lecteur. =)

L'idée c'est de pouvoir perdre les containers, mais pas les données personnelles.

J'ai retourné toutes les pistes à fond, je suis même allé jusqu'au "container-boite-noire" (un trip vraiment obscure), mais aucune d'entre-elles ne répondait correctement à ma problèmatique. Si on perd les containers, il faut maitriser le moment de la perte (il ne faut pas que ce soit à un moment aléatoire). Pire encore, il faut recréer rapidement juste après les nouveaux containers qui doivent remplacer les anciens, et ils doivent être instantannément opérationnels sans avoir besoin de faire un quelconque setup manuel.

Il y a un événement que Systemd maitrise et qui pourrait servir de déclencheur à la destruction de l'ancien container. « Le processus se termine, alors je détruis le container. » Il y a une multitude de scénarios possibles, comme par exemple : « Au démarrage du nouveau processus, je détruis l'ancien container, puis je lance le nouveau » Tu remarqueras cher lecteur que lors du premier démarrage, il y aura des erreurs car aucun ancien container n'existe pas au préalable.

Heureusement, le service Docker gère bien ce point (ouf!), il suffit de passer dans la ligne de commande l'option --rm et lorsque le processus se terminera, son container sera détruit automatiquement. Systemd n'aura qu'à spawner les containers et tuer les processus à l'intérieur. C'est ce qu'on attend d'un gestionnaire de services, en fait.

Et donc, si l'on se dit que les données perso n'ont pas besoin d'être isolées, alors on peut les laisser dans un répertoire quelconque sur le disque dur (avec l'option -v).

Volume de données quelconque, mais pas trop, quand même...

Le service Docker va gérer les modes et ownership des fichiers. Si le processus cloisonné les modifie, alors ils changeront sur le disque dur. Il est question seulement des fichiers à l'intérieur du volume exposé, il ne peut pas altérer les fichiers à l'extérieur. Tu remarqueras cher lecteur, que le processus peut changer lui-même les permissions du répertoire racine (le lien entre le volume sur disque et le volume dans le container). Si tu veux que les autres utilisateurs ne puissent pas regarder dedans, tu peux setter manuellement en root les bonnes permissions sur le répertoire parent.

Dans cet optique de permissions, il vaut mieux regrouper les volumes exposés du container dans un seul répertoire par container, pour pouvoir globalement interdire, ou pas, l'accès aux volumes du container aux utilisateurs système.

Okay on gère les droits linux de base, voyons si on peut pas augmenter le level.

SELinux propose une couche d'abstraction supplémentaire à la gestion des droits linux (jugée imparfaite par la NSA), directement au niveau du noyau Linux... mais je radotte, tu le sais déjà mon vieux lecteur. Le service Docker propose une option intéressante pour les systèmes possèdant SELinux. Oui, toute l'arborescence de répertoires exposée sur disque par le container sera cloisonnée par SELinux. Aucun processus, s'il n'a pas le droit de modifier les fichiers ayant le contexte 'svirt_sandbox_file_t', ne pourra JAMAIS altérer cette arborescence. Je sais pas pour toi, mais moi, perso, ça me fait kiffer. On pourrait aller beaucoup plus loin avec le mode Multi Level Security, malheureusement ce n'est pas le mode courant sur mon serveur.

En ligne de commande ça ressemble à ça :
-v /rep/sur/hote:/rep/dans/container:Z

Cette option exécute automatiquement un change context (commande 'chcon') sur les répertoires du disque. Attention pour que ce soit persistent après un restorecon il faut ajouter la règle avec semanage :
semanage fcontext -a -s system_u -t svirt_sandbox_file_t "/contener/mariadb-casper-im(/.*)?"
Dans tous les cas, il faut user et abuser de la commande restorecon pour bien vérifier ses règles, et je t'invite à lire cet article qui m'a sauvé la vie, d'ailleurs.

Pour terminer en beauté, le service Docker ne supprime pas les volumes exposés sur disque. Que ce soit dans le répertoire par défaut (/var/lib/docker/volumes) ou bien un répertoire assigné avec l'option -v, ce répertoire ne sera pas supprimé si le container est volontairement ou involontairement supprimé.

Voici une unité systemd pour le serveur de base de données de ma messagerie instantannée (Jabber) en guise d'exemple :

[Unit]
Description=Mariadb Server Casper IM
After=docker.service

[Service]
Restart=always
EnvironmentFile=/etc/%p.env
ExecStart=/usr/bin/docker run -i --rm --name %p -p 127.0.0.1:16000:3306 \
          -e MYSQL_USER \
          -e MYSQL_PASSWORD \
          -e MYSQL_DATABASE \
          -e MYSQL_ROOT_PASSWORD \
          -v /contener/%p/var/lib/mysql/data:/var/lib/mysql/data:Z \
          -v /contener/%p/etc/my.cnf.d:/etc/my.cnf.d:Z \
          -v /contener/%p/var/log/mariadb:/var/log/mariadb:Z \
          mariadb:10.1.20-8
ExecReload=/usr/bin/kill -HUP $MAINPID

[Install]
WantedBy=multi-user.target


Le fichier /etc/mariadb-casper-im.env contient les credentials du serveur Mariadb (user mysql, mot de passe, etc...) Il initialise les variables d'environnement MYSQL_USER, MYSQL_PASSWORD, etc... présentes dans l'unité systemd. Il a aussi le mode 400 car il contient des mots de passe. L'image docker est une image custom basée sur celle de Fedora Cloud (le dépôt Git.) Ma seule modification n'est pas vraiment une contribution, j'ai juste ajouté 2 volumes exposés.

VOLUME ["/var/lib/mysql/data", "/etc/my.cnf.d", "/var/log/mariadb"]

Voici quelques conseils de gestion de disque :
  1. Regrouper les volumes exposés dans un répertoire par container
  2. Regrouper les répertoires de container sur une partition montée
  3. Cette partition devrait être un volume LVM de type miroir
  4. Cette configuration ne dispense pas d'avoir des backups journalier (dump de base de données ou autre)
En parlant backup, n'hésitez pas à vous servir de 'docker exec' pour intéragir avec le programme cloisonné, par exemple :

docker exec -i mariadb-casper-blog  mysqldump --opt -u casperlefantom -p$MYSQL_USER_PASSWORD casperlefantom > db-casperlefantom-$(date +%Y%m%d).dump

Magie, le fichier "db-casperlefantom-20161220.dump" est généré à l'extérieur du container. J'ai volontairement utilisé des exemples avec Mariadb car c'est le programme qui m'a donné le plus de fil à retordre, les autres programmes comme apache pour servir des sites statiques étaient bien plus faciles, sans credentials, sans variables d'environnement, etc... Mais toujours avec backup ;)

[Unit]
Description=Apache HTTP Server Vhost onion1
After=docker.service

[Service]
Restart=always
ExecStart=/usr/bin/docker run -i --rm --name %p -p 127.0.0.1:8085:80 \
          -v /contener/%p/var/www/html:/var/www/html:Z \
          -v /contener/%p/etc/httpd/conf.d:/etc/httpd/conf.d:Z \
          -v /contener/%p/etc/pki/tls/private:/etc/pki/tls/private:Z \
          -v /contener/%p/etc/pki/tls/certs:/etc/pki/tls/certs:Z \
          -v /contener/%p/var/log/httpd:/var/log/httpd:Z \
          apache-single:2.4.23-2
ExecReload=/usr/bin/docker exec %p /usr/sbin/httpd -k graceful

[Install]
WantedBy=multi-user.target
Pour ajouter de l'orchestration entre les services, on peut jouer avec les options After et BindTo dans la partie [Service] des unités systemd. Indispensable lorsque l'on utilise du linkage entre 2 containers...
]]>
auto-hébergement
Sat, 07 Jan 2017 16:49:00 GMT Patrice Kadionik : Création du dépôt Fedora eddy33 http://eddy33.eddy33.free.fr/weblog/index.php?post/2017/01/07/Cr%C3%A9ation-du-d%C3%A9p%C3%B4t-eddy33 urn:md5:e42653dcf7d6f16edf22b6e5b3edd4da

Salut.

Cela faisait pas mal de temps que je cherchais l'occasion de créer un dépôt Fedora... C'est fait !

J'utilise le logiciel libre AMC (Auto Multiple Choice) pour créer des QCM avec autocorrection après scan des copies afin d'évaluer certains de mes cours.

AMC est un logiciel plutôt génial pour cela : http://home.gna.org/auto-qcm/

Malheureusement, il n'est plus maintenu sous forme de paquetages RPM pour Fedora depuis la version 21. J'ai ainsi comblé ce vide avec la création du dépôt eddy33. Le dépôt eddy33 propose AMC pour Fedora 23 et supérieur en version 32 et 64 bits. Voici donc le premier paquetage que je maintiens. Il faut bien un début ;-)" class="smiley

L'accès au dépôt eddy33 se fait par la commande :
# dnf install http://kadionik.vvv.enseirb-matmeca.fr/fedora/repo-eddy33-1.0-1.fc25.noarch.rpm

Les paquetages disponibles sont signés.

++
]]>
Fedora