En ce mardi 16 septembre, la communauté du Projet Fedora sera ravie d’apprendre la disponibilité de la version Beta de Fedora Linux 43.

Malgré les risques concernant la stabilité d’une version Beta, il est important de la tester ! En rapportant les bogues maintenant, vous découvrirez les nouveautés avant tout le monde, tout en améliorant la qualité de Fedora Linux 43 et réduisant du même coup le risque de retard. Les versions en développement manquent de testeurs et de retours pour mener à bien leurs buts.

La version finale est pour le moment fixée pour le 21 ou le 28 octobre.

Sommaire

• Expérience utilisateur
• Gestion du matériel
• Internationalisation
• Administration système
• Développement
• Projet Fedora
• Tester

Expérience utilisateur

• L’environnement de bureau GNOME est proposé dans sa version 49 ;
• GNOME fonctionnera uniquement en tant que session Wayland, les paquets liés à GNOME pour session X11 sont supprimés ;
• L’installateur Anaconda utilisera la nouvelle interface basée sur une technologie web sur tous les Spins par défaut ;
• Activation de la mise à jour automatique du système pour la variante Fedora Kinoite ;
• L’installateur Anaconda utilise le gestionnaire de paquet DNF dans sa 5ᵉ version dorénavant ;
• Fin de support de la modularité des paquets RPM dans l’installateur Anaconda ;
• La police d’affichage d’émojis Noto Color Emoji utilise son nouveau format basé sur COLRv1 pour améliorer le rendu ;
• Le fichier initrd utilisé lors du démarrage est compressé avec l’algorithme zstd pour un démarrage plus rapide et une taille d’installation plus petite.

Gestion du matériel

• L’installateur Anaconda ne permettra plus d’installer Fedora sur les machines compatibles UEFI des architectures x86 si le format de partitionnement est basé sur MBR au lieu de GPT ;

Internationalisation

• La police de type monospace aura une police alternative de ce type par défaut en cas de manque dans une langue donnée.

Administration système

• Le gestionnaire de paquets RPM passe à la version 6.0 tours par minute ;
• Les mises à jour de CoreOS se font en tant qu’image OCI sur le dépôt Fedora quay.io au lieu d’utiliser le format OSTree sur ostree.fedoraproject.org ;
• Réduction du nombre de règles dontaudit liés au type unlabeled_t ;
• La bibliothèque de sécurité OpenSSL chargera par défaut une liste hashée de certificats nécessitant la suppression du fichier cert.pem ;
• Le paquet gnupg2 pour fournir l’outil de chiffrement est dorénavant découpé en plusieurs sous paquets ;
• Le gestionnaire de base de données PostgreSQL est mis à jour à sa 18ᵉ version ;
• Le gestionnaire de base de données MySQL passe par défaut à la version 8.4 ;
• Le serveur de courriels Dovecot est mis à jour vers sa version 2.4 ;
• Le projet 389 Directory Server est fourni avec sa version 3.2.0 ;
• Le serveur d’application Tomcat est mis à jour vers sa version 10.1 ;
• Migration de l’utilitaire de journalisation lastlog à lastlog2 ;
• L’information PLATFORM_ID dans os-release est supprimée.

Développement

• La chaine de compilation GNU évolue avec binutils 2.45, glibc 2.41 et gdb 17.1 ;
• L’éditeur de lien Gold du paquet binutils-gold est considéré comme déprécié et sera supprimé dans une version future ;
• Mise à jour de la chaine de compilation LLVM à sa version 21 ;
• Le langage Python mue à sa version 3.14 ;
• Le langage Go passe à la version 1.25 ;
• Le langage Perl fourni une réponse brillante avec sa version 5.42 ;
• La boîte à outils Ruby on Rails démarrera voie 8.0 ;
• La machine virtuelle Java OpenJDK 25 est fournie ;
• L’utilitaire dans l’écosystème Java nommé Maven bénéficie de la version 4 en parallèle de la version 3 ;
• Le compilateur pour le langage Haskell GHC a été mis à jour evrs sa version 9.8 et son écosystème Stackage vers la version 23 ;
• Le langage de programmation fonctionnel Idris dispose d'une mise à jour majeure vers sa 2e version ;
• Le langage de programmation système Hare a été introduit ;
• Le compilateur Free Pascal proposera des versions permettant la compilation croisée avec d’autres architectures ;
• La bibliothèque d’Intel tbb pour paralléliser certaines tâches passe à la version 2022.2.0 ;
• La signature cryptographique des informations de débogage debuginfod est maintenant effectuée automatiquement du côté du client ;
• La bibliothèque Rust async-std est considéré comme déprécié avant une suppression future ;
• La bibliothèque Python python-async-timeout est considéré comme déprécié avant une suppression future ;
• Le paquet python-nose a été retiré ;
• Les paquets concernant d’anciennes versions de GTK pour Rust gtk3-rs, gtk-rs-core version 0.18, et gtk4-rs ont été retirés.

Projet Fedora

• Koji utilise localement au sein du projet Fedora une instance de Red Hat Image Builder pour générer certaines images qui en dépendent ;
• La génération de l’image Core OS reposera sur le fichier de définition de conteneurs Containerfile ;
• Le système d’intégration continue de Fedora ne prend plus en charge le format Standard Test Interface ;
• Les nouveaux paquets recevront automatiquement une nouvelle configuration basée sur Packit pour permettre la gestion automatique de certaines tâches dans le cadre des nouvelles versions de Fedora ;
• Les bibliothèques statiques fournies par les paquets RPM de Fedora conservent les informations de débogage pour permettre de comprendre l’origine des crashes des applications les exploitant ;
• Les macros dédiées pour générer les paquets Python reposant sur setup.py sont dorénavant dépréciés ;
• Les paquets Go sont compilés en utilisant par défaut les dépendances du projet compilé plutôt que d’utiliser systématiquement des dépendances basées sur des RPM gérés par le projet Fedora ;
• Les paquets NodeJS utiliseront un nouveau formalisme pour le chemin de leurs dépendances ;
• Les macros CMake ne fourniront plus de variables d’installation non standards ;
• L’assembleur YASM est considéré comme déprécié pour utiliser NASM à la place ;
• Ajout des nouvelles macros RPM _pkg_extra_***flags pour permettre à chaque paquet d’ajouter des nouvelles options à la compilation à la liste par défaut fournie par le projet Fedora ;
• Certaines limitations de l’outil gpgverify utilisé par les mainteneurs de paquets sont supprimées permettant de supprimer des méthodes de contournement associés.

Tester

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

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

Les tests à effectuer et les rapports sont à faire via la page suivante. J’annonce régulièrement sur mon blog quand une journée de tests est planifiée.

Si l’aventure vous intéresse, les images sont disponibles par Torrent ou via le site officiel.

Si vous avez déjà Fedora Linux 42 ou 41 sur votre machine, vous pouvez faire une mise à niveau vers la Beta. Cela consiste en une grosse mise à jour, vos applications et données sont préservées.

Nous vous recommandons dans les deux cas de procéder à une sauvegarde de vos données au préalable.

En cas de bogue, n’oubliez pas de relire la documentation pour signaler les anomalies sur le BugZilla ou de contribuer à la traduction sur Weblate. N’oubliez pas de consulter les bogues déjà connus pour Fedora 43.

Bons tests à tous !

Dans le cadre des 20 ans de Fedora-fr (et du Projet Fedora en lui-même), Charles-Antoine Couret (Renault) et Nicolas Berrehouc (Nicosss) avons souhaité poser des questions à des contributeurs francophones du projet Fedora et de Fedora-fr.

Grâce à la diversité des profils, cela permet de voir le fonctionnement du projet Fedora sous différents angles pour voir le projet au-delà de la distribution mais aussi comment il est organisé et conçu. Notons que sur certains points, certaines remarques restent d’application pour d’autres distributions.

N’oublions pas que le projet Fedora reste un projet mondial et un travail d’équipe, ce que ces entretiens ne permettent pas forcément de refléter. Mais la communauté francophone a de la chance d’avoir suffisamment de contributeurs et de contributrices de qualité pour permettre d’avoir un aperçu de beaucoup de sous projets de la distribution.

Chaque semaine un nouvel entretien sera publié sur le forum Fedora-fr.org, LinuxFr.org et le blog de Renault.

L’entretien du jour concerne Aurélien Bompard (pseudo abompard), développeur au sein du projet Fedora et employé Red Hat affecté au projet Fedora en particulier dans l’équipe infrastructure.

Sommaire

• Conclusion

Bonjour Aurélien, peux-tu présenter brièvement ton parcours ?

Je m’appelle Aurélien, je suis informaticien, et c’est pendant mon école d’ingé que j’ai découvert le logiciel libre, par le biais d’une association étudiante. J’ai vite accroché et j’ai décidé de travailler autant que possible là-dedans quand j’en suis sorti (en 2003).
J’ai commencé avec Mandrake Linux à l’époque, alors que KDE venait de sortir en version 2.0 (et le kernel en 2.4). Malgré tous les efforts de Mandrakesoft, ce n’était quand même pas évident de tourner sous Linux à l’époque. J’ai mis 2 semaines à faire fonctionner ma carte son (une SoundBlaster pourtant !), il fallait régler les fréquences de rafraîchissement de l’écran soi-même dans le fichier de conf de XFree86, et je n’avais qu’un seul ordinateur ! (et pas de smartphone, lol). Le dual boot et son partitionnement m’a donné quelques sueurs froides, et tout le temps passé sous Linux était du temps coupé du réseau des élèves. Fallait quand même être un peu motivé :-)
Mais j’ai tenu bon, et j’ai installé des applications libres sous Windows aussi : Phoenix (maintenant Firefox), StarOffice (maintenant LibreOffice), etc. Parce que ce qui m’a attiré c’est la philosophie du logiciel libre, et pas seulement la technicité de Linux.

En 2003, j’ai fait mon stage de fin d’études chez Mandrakesoft, mais la société était en redressement judiciaire à l’époque, et ça n’offrait pas des perspectives d’embauche intéressantes.
Après quelques candidatures j’ai été pris à la fin de l’été 2003 dans une SSII en logiciel libre en tant qu’administrateur système pour installer des serveurs Linux chez des PME.
Le contrat qui avait donné lieu à mon embauche s’est arrêté prématurément, et la société ayant aussi une activité de développement autour de Zope/CPS, on m’a proposé de me former à Python (version 2.2 à l’époque si je me souviens bien). J’ai accepté et suis devenu développeur. C’est à cette époque que j’ai quitté Mandrake Linux pour passer sur Red Hat 9, en me disant que c’était plus pertinent de monter en compétences dessus pour le travail. À l’époque il y avait une petite communauté de packageurs qui publiait des RPM supplémentaires pour Red Hat 9, autour du domaine fedora.us.
Début 2004, Red Hat a décidé qu’il y avait trop de confusion entre leurs offres commerciales à destination des entreprises et leur distribution Linux gratuite, et ont décidé de scinder leur distribution en Red Hat Enterprise Linux d’un côté, et une distribution Linux communautaire de l’autre. Ils ont embauché le fondateur de fedora.us, rassemblé les contributeurs et lancé la distribution Fedora Linux.

La communauté a mis pas mal de temps à se former, et c’était passionnant de voir ça en direct. On avait :

• les contributeurs qui disaient « regarde on n’a jamais été aussi libres de faire ce qu’on veut, c’est bien mieux qu’avant avec RH9 qui était poussée hors des murs de Red Hat sans qu’on puisse rien y faire » ;
• les utilisateurs des « autres distribs » (kof kof Debian kof kof) qui disaient « vous êtes exploités par une société, ce sera jamais vraiment communautaire, Red Hat se transforme en Microsoft » ;
• les commerciaux de Red Hat qui disaient « Fedora c’est une version bêta, c’est pas stable, faut surtout pas l’utiliser en entreprise, achetez plutôt RHEL » ;
• la communication Red Hat qui disait "Si si c'est communautaire j'vous assure" Si vous ne l'avez pas lue et que vous lisez l'anglais, cette fausse conversation IRC a fait rire jaune beaucoup de monde à l'époque.

Enfin bref, la communauté a fini par grossir significativement, Fedora Core et Fedora Extras on fusionné, etc. Ma dispo pour contribuer au projet a été assez variable au fil des années, mais j'ai toujours utilisé Fedora.
En 2012, un poste s'est ouvert chez Red Hat dans l'équipe qui s'occupe de l'infrastructure Fedora, j'ai postulé, et j'ai été pris.

Peux-tu présenter brièvement tes contributions au projet Fedora ?

Au début j'empaquetais les logiciels que j'avais à dispo dans Mandrake Linux mais qui n'existaient pas dans Fedora Extras, et tous les logiciels sympas que je voyais passer. J'ai aussi fait beaucoup de revues de fichiers .spec pour leur inclusion dans la distrib.
Après avoir été embauché par Red Hat, j'ai travaillé sur HyperKitty, le logiciel d'archivage / visualisation de Mailman 3. Puis j'ai travaillé sur plein d'autres trucs au sein de l'équipe Fedora Infra, les dernières étant Fedora Messaging, Noggin/FASJSON et FMN. Je suis aujourd'hui responsable technique côté Fedora dans l'équipe (par opposition au côté CentOS) et je travaille surtout sur les applications en tant que dev, beaucoup moins sur la partie sysadmin.

Qu'est-ce qui fait que tu es venu sur Fedora et que tu y es resté ?

J'y suis venu parce que monter en compétences sur une distribution Red Hat me semblait pertinent pour mon métier, en tant que sysadmin Linux.
J'y suis resté parce que Fedora est pour moi le parfait équilibre entre nouveauté et stabilité, tout en étant très ancré dans la défense du logiciel libre, même au prix de quelques complications (le MP3, les pilotes Nvidia, etc.).

Pourquoi contribuer à Fedora en particulier ?

Parce que je l'utilise. Je crois que c'est une constante dans ma vie, c'est rare que je reste uniquement utilisateur/consommateur, je suis souvent amené à contribuer à ce que j'utilise ou aux associations dont je fais partie.

Contribues-tu à d'autres Logiciels Libres ? Si oui, lesquels et comment ?

J'ai été amené à développer sur mon temps libre quelques logiciels pour des associations auxquelles je participe, et c'est toujours en logiciel libre. Le dernier en date c'est Speaking List (licence AGPL).

Est-ce que tes contributions dans Fedora se font entièrement dans le cadre de ton travail ? Si non, pourquoi ?

Avant non, parce que je packageais des outils que j'utilisais personnellement (Grisbi, Amarok, etc.). Maintenant oui :-)

Est-ce que être employé Red Hat te donne d'autres droits ou opportunités au sein du projet Fedora ?

Oui, j'aimerais que ce ne soit pas le cas mais c'est sûr que je suis plus près des prises de décisions, j'ai des accès plus directs aux personnes influentes et aux évolutions. Ce n'est pas un "droit" au sens strict, qui me serait attribué non pas sur la base de mes contributions mais sur celle de mon employeur, heureusement. Mais disons que je baigne toute la journée dedans, je pense que ça ouvre plus d'opportunités que quand j'étais contributeur "externe".

Tu as été membre de Fedora Infrastructure, peux-tu nous expliquer sur l'importance de cette équipe pour la distribution ? Quels services maintenais-tu ?

Cette équipe est totalement indispensable. Il y a en permanence des problèmes qui apparaissent dans la distrib, des choses qui tombent en panne, de nouveaux services à intégrer, d'anciennes applis qui ne marchent plus sur les nouvelles distributions ou les nouveaux services et qu'il faut porter, etc.
J'ai commencé sur Mailman / HyperKitty mais je me suis diversifié depuis, je dirais qu'aujourd'hui je me concentre sur l'aspect applicatif : maintenance de nos applis, portages, adaptations, évolutions, etc. Les dernières applis sur lesquelles j'ai travaillé sont Fedora Messaging, Noggin/IPA (authentification), Datanommer/Datagrepper, FMN (notifications), MirrorManager, et plus récemment Badges.

Tu as notamment beaucoup contribué à mailman et hypperkitty pour les listes de diffusion du projet. Qu'est-ce que tu as fait ? La migration a-t-elle été difficile ? Quelle importance ont encore les listes de diffusion aujourd'hui au sein du projet Fedora ?

C'était mon premier travail lorsque j'ai été embauché par Red Hat, oui. J'ai fait le développement de HyperKitty, en suivant les travaux de conception d'interface réalisés par Mo Duffy. J'ai travaillé aussi sur Mailman 3 lui-même quand c'était son développement qui me bloquait pour HyperKitty ou pour le déploiement du tout. J'ai écrit un script de migration qui a pas trop mal marché je pense, quand on prend en compte la longue historique des listes de diffusion du projet. Il fait partie de HyperKitty et va maintenant être utilisé pour la migration des listes de CentOS.

Le sujet des listes de diffusion a presque toujours été assez conflictuel chez Fedora. Il y a une quinzaine d'années, avant que je sois embauché pour travailler sur HyperKitty, notre communauté était déjà fractionnée entre les contributeurs plutôt réguliers qui utilisaient les listes, et les utilisateurs et contributeurs occasionnels qui étaient plutôt sur des forums web. En effet, utiliser une liste de diffusion est plus engageant qu'un forum, il faut s'y abonner, mettre en place des filtres dans sa messagerie, gérer l'espace de son compte mail en conséquence, c'est impossible de répondre à un message envoyé avant qu'on s'y abonne, on ne peut pas éditer ses messages, etc. Quand on veut juste poser une question rapidement ou répondre rapidement à quelque chose, les forums peuvent être plus pratiques et plus intuitifs. L'utilisation des listes de diffusion peut être intimidant et contre-intuitif : combien de personnes ont envoyé "unsubscribe" à une liste en voulant se désinscrire ?

La promesse d'HyperKitty était d'offrir une interface de type forum aux listes de diffusion, pour faire le pont entre les deux communautés, et permettre plus facilement la conversion d'utilisateurs en contributeurs tout en permettant aux contributeurs d'être plus facilement confrontés aux problèmes rencontrés par les utilisateurs. Ça n'a pas bien fonctionné, mais c'est un sujet qui reste d'actualité aujourd'hui avec l'intégration de Discourse dans le projet. Je crois que le projet essaie de migrer de plus en plus de processus depuis les listes de diffusion vers Discourse, pour que ça atteigne le maximum d'utilisateurs et de contributeurs.

Puis également sur le compte unique au sein du projet Fedora (nommé FAS), quelle est l'importance de ce projet et ce que tu y as fait ?

C'est un projet qu'on a gardé longtemps dans les cartons, peut-être trop longtemps même. L'idée était de remplacer FAS (Fedora Account System), une base de donnée des utilisateurs avec une API maison, par FreeIPA, une intégration de LDAP et Kerberos pour gérer les comptes utilisateurs en entreprise. On utilisait en fait déjà IPA pour la partie Kerberos dans l'infra, mais la base de référence des comptes était FAS. Or, FAS n'était plus maintenu, et sa ré-écriture par un membre de la communauté (un français ! petit clin d'œil à Xavier au passage) prenait un peu trop de temps. FAS tournait sur EL6 et la fin de vie approchait.
Migrer la base de comptes sur IPA a été assez complexe parce que beaucoup d'applications s'intégraient avec, il a donc fallu tout convertir vers le nouveau système. IPA étant prévu pour des entreprises à la base, il n'y a pas de système d'auto-enregistrement et de gestion avancée de son propre compte. Nous avons donc dû développer cette interface, qui s'appelle Noggin. Nous avons aussi écrit une API REST pour IPA, appelée FASJSON. Enfin, il a fallu personnaliser IPA pour qu'il stocke les données dont nous avions besoin dans l'annuaire LDAP.
J'ai été développeur et responsable technique sur ce projet, donc je me suis surtout concentré sur la conception et les points d'implémentation délicats.

Tu fais parti des gros contributeurs du composant Bodhi et même l'infrastructure de la compilation des paquets en général, là encore quel a été ton rôle là dedans et en quoi ces composants sont importants pour le projet ?

Bodhi est vraiment au cœur du cycle de vie d'un paquet RPM dans Fedora. C'est aussi une des seules applications de l'infra qui soit significativement maintenue par un membre de la communauté qui n'est pas un employé de Red Hat (Mattia). Elle permet de proposer une mise à jour des paquets, s'intègre avec les composants de tests de paquets, et permet de commenter une mise à jour.
J'ai travaillé dessus de manière sommaire seulement, depuis le départ de Randy (bowlofeggs) qui la maintenait auparavant. J'ai converti le système d'authentification version OIDC, j'ai écrit les tests d'intégration, j'ai travaillé un peu sur l'intégration continue, mais c'est tout.

Peux-tu expliquer rapidement l'architecture derrière cette mécanique ?

Et bien, disons qu'en résumé quand un packageur veut proposer une mise à jour, il met à jour son fichier spec dans son dépôt, lance une construction du paquet avec fedpkg dans Koji, et doit ensuite déclarer et donner les détails de sa mise à jour dans Bodhi. C'est là que les tests d'intégration des paquets se déclenchent, et au bout d'un certain temps (ou d'un certain nombre de commentaires positifs) la mise à jour arrive sur les miroirs.

Tu as aussi beaucoup travaillé sur Fedora-Hubs, peux-tu revenir sur les ambitions de ce projet ? Pourquoi il n'a finalement pas été adopté et concrétisé comme prévu ?

L'objectif de Fedora Hubs était de centraliser l'information venant de différentes applications Fedora sur une même page, avec une interface qui explique clairement ce que ça veut dire et quelles sont les étapes suivantes. Une sorte de tableau de bord pour contributeur, et pas seulement pour packageur, un peu dans l'esprit de ce que fait aujourd'hui https://packager-dashboard.fedoraproject.org/.
Malheureusement la proposition a été faite à un moment où il y avait d'autres priorités plus urgentes, et vu que c'était quand même pas mal de boulot on a laissé tomber pour s'occuper du reste.

Est-ce qu'il y a des collaborations concernant l'infrastructure entre les projets RHEL, CentOS et Fedora ou même d'autres entités externes ?

Oui, on essaye de partager le maximum ! Le système d'authentification est commun entre CentOS et Fedora, par exemple. On essaie d'échanger sur nos rôles Ansible, sur la surveillance de l'infra, etc.

Si tu avais la possibilité de changer quelque chose dans la distribution Fedora ou dans sa manière de fonctionner, qu'est-ce que ce serait ?

J'adorerais qu'il y ait plus de contributeurs qui participent aussi à l'infrastructure, et notamment à nos applications. À vrai dire je cherche en ce moment des moyens de motiver les gens à venir y mettre les mains. C'est super intéressant, et vous pouvez directement affecter la vie des milliers de contributeurs au projet ! Je suis même prêt à mettre de l'énergie là-dedans si besoin, sous forme de présentations, ateliers, questions/réponses, etc. Et je pose donc la question à tout le monde : si Fedora vous intéresse, si le développement vous intéresse, qu'est-ce qui vous freine pour contribuer aux applis de l'infra ?

À l'inverse, est-ce qu'il y a quelque chose que tu souhaiterais conserver à tout prix dans la distribution ou le projet en lui même ?

Je crois que c'est notre capacité à innover, à proposer les dernières nouveautés du logiciel libre :-)

Que penses-tu de la communauté Fedora-fr que ce soit son évolution et sa situation actuelle ? Qu'est-ce que tu améliorerais si tu en avais la possibilité ?

À vrai dire je n'ai pas suivi de près les évolutions de la communauté française. Mon boulot m'amène à communiquer quasi-exclusivement en anglais, donc j'interagis plus avec la communauté anglophone.

Quelque chose à ajouter ?

Non, rien de spécial, à part revenir sur ma question : si vous avez eu envie d'améliorer l'infra et/ou les applis de l'infra de Fedora, qu'est-ce qui vous a freiné ? Qu'est-ce qui vous freine aujourd'hui ? N'hésitez pas à me contacter sur Matrix (abompard@fedora.im) et sur Discourse.

Merci pour ta contribution !

Merci à vous, et joyeux anniversaire à Fedora-Fr !

Conclusion

Nous espérons que cet entretien vous a permis d'en découvrir un peu plus sur l'infrastructure du projet Fedora.

Si vous avez des questions ou que vous souhaitez participer au projet Fedora ou Fedora-fr, ou simplement l'utiliser et l'installer sur votre machine, n'hésitez pas à en discuter avec nous en commentaire ou sur le forum Fedora-fr.

Et ainsi s'achève notre série d'entretiens. On espère que cela vous aura plus et peut être à dans quelques années pour savoir ce qui a changé. :)